[06:46] <cbx33> is it right that my laptop fan is running at a higher rpm in low latency kernel?
[07:11] <ailo-w> cbx33: Could be.
[07:11] <cbx33> i guess cos the higher "load" on the system to be low latency
[07:11] <cbx33> :)
[07:11] <ailo-w> It uses a bit more cpu, but I don't think it's too much
[07:12] <ailo-w> We haven't done any tests on that yet
[07:12] <cbx33> ahh
[07:12] <ailo-w> Don't know if anyone has
[07:12] <cbx33> ailo-w, thanks
[07:12] <cbx33> just comparing to me standard build
[07:12] <cbx33> I bought an AudioBox USB yesterday and was playing with it with Ardour 3 Beta
[07:12] <cbx33> suffered from a few xruns
[07:13] <cbx33> and actually a rather unstable system - thought it may have been because my frames/period was too low
[07:13] <ailo-w> cbx33: At which frames/period? And are you using the pulseaudio bridge?
[07:14] <cbx33> i was using JACK with 128
[07:14] <ailo-w> Ubuntu Studio is set to use the bridge by default
[07:14] <cbx33> ahh maybe that's it
[07:14] <ailo-w> Also, some usb devices don't work well at lower latencies
[07:14] <cbx33> ok
[07:14] <ailo-w> cbx33: How is the performance with your internal card, in comparison?
[07:14] <cbx33> I installed xubuntu and then a load of packages - if I install ubuntu-studio package will it set that up for me?
[07:14] <ailo-w> cbx33: To remove the PA bridge, uninstall pulseaudio-module-jack, and restart pulseaudio
[07:15] <cbx33> ailo, in all honesty I never did any real recording with Ardour on 128
[07:15] <cbx33> I used 128 for linux sampler
[07:15] <cbx33> as I found the keyboard too delayed with 20ms
[07:15] <ailo-w> cbx33: Usually, with the low latency kernel, you can get a pretty stable performance at 64, depending on your HW
[07:15] <cbx33> it's an i5 - laptop
[07:15] <ailo-w> integrated grahpics
[07:16] <ailo-w> Never tried one of those yet
[07:16] <cbx33> unfortunately
[07:16] <cbx33> :)
[07:16] <cbx33> it's ok
[07:16] <cbx33> a few little quirks here and there
[07:16] <cbx33> so what does the bridge do ?
[07:17] <ailo-w> It makes PA connect to jack, when you start jack
[07:17] <ailo-w> Or, rather, jackdbus
[07:17] <ailo-w> cbx33: Did you set up realtime privilege?
[07:17] <ailo-w> cbx33: Installing packages is not enough
[07:17] <cbx33> i get the flashing RT - so i think it's working
[07:18] <ailo-w> cbx33: See the log
[07:18] <ailo-w> cbx33: To get realtime privilege, say yes when asked while installing jackd
[07:19] <ailo-w> The file should be /etc/security/limits.d/audio.conf and not audio.conf.disabled
[07:19] <cbx33> lemme check
[07:19] <ailo-w> cbx33: Also, add yourself to audio group
[07:19] <ailo-w> sudo usermod -a -G audio $USER
[07:19] <cbx33> @audio   -  rtprio     95
[07:19] <cbx33> @audio   -  memlock    unlimited
[07:19] <cbx33> #@audio   -  nice      -19
[07:19] <ailo-w> If you didnt' do those things, you don't have realtime privilege
[07:19] <cbx33> i am in the audio group
[07:19] <ailo-w> Ok, so you're all set up
[07:20] <cbx33> JACK server starting in realtime mode with priority 10
[07:20] <ailo-w> cbx33: I'd remove the bridge. Do testing with both the internal card and the usb for comparison
[07:20] <cbx33> ok
[07:21] <cbx33> so what does the bridge affect
[07:21] <cbx33> does it just make JACK do more work than it has to?
[07:21] <ailo-w> It usually gives you an occasional xrun at lower latencies
[07:21] <ailo-w> I don't know why
[07:22] <ailo-w> Maybe it just needs to be improved
[07:22] <cbx33> ok
[07:23] <cbx33> The following packages will be REMOVED
[07:23] <cbx33>   pulseaudio-module-jack ubuntustudio-recording
[07:23] <cbx33> ailo-w, that implies that the pulse module is included with ubuntustudio-recording right?
[07:25] <ailo-w> cbx33: Seems like it. Removing the meta will not affect anything
[07:25] <cbx33> no i know :)
[07:29] <cbx33> will try that later
[07:29] <cbx33> it's removed
[07:30] <ailo-w> Going to try performance on this old P4 just for fun.
[07:30] <cbx33> hehehe
[07:30] <cbx33> the audiobox has a resolution of 24bit
[07:30] <cbx33> what does jack support?
[07:36] <ailo-w> I'm on a lxde desktop right now actually. Installed ubuntu onto a usb stick
[07:38] <ailo-w> Pretty stable at 64 frames/period
[07:38] <ailo-w> Using the internal card
[07:38] <ailo-w> no xruns yet
[07:43] <ailo-w> cbx33: If you find that the usb device is less stable than your internal, try using the rtirq script to your benefit
[07:43] <ailo-w> The package is called rtirq-init, and I believe it comes with the kernel
[07:43] <ailo-w> -lowlatency that is
[07:43] <ailo-w> But, you might need to adjust it
[07:44] <cbx33> wow
[07:44] <cbx33> ok thanks
[07:44] <cbx33> lemme copy that
[07:45] <cbx33> be back later
[07:45] <ailo-w> cbx33: To see how your realtime prios are, use the command: ps -eo comm,rtprio
[07:50] <ailo-w> I do get an occasional xrun.
[07:51] <ailo-w> Even without the bridge. But this device isn't exactly pro audio
[10:58] <akhila> hi there! anyone willing to give out some info please??
[11:03] <ailo> akhila: Just ask
[11:04] <ailo> akhila: Usually if one has a question, you just ask and wait for someone to respond. Takes a while sometimes
[11:06] <akhila> okay. thanks.
[11:06] <akhila> Testing Ubuntu Studio. I'm actually new to it. Opened Orage. and then Globaltime
[11:07] <akhila> The window has two buttons which appear very much merged.
[11:07] <akhila> and it actually shows anly local time.
[11:07] <akhila> is it how it should be??
[11:07] <akhila> Running studios on VirtualBox
[11:12] <ailo> akhila: I guess so
[11:12] <ailo> akhila: Most of the desktop related stuff come directly from Xubuntu/XFCE
[11:13] <ailo> So, you might find more detailed answers on their channel
[11:13] <ailo> channels*
[11:13] <akhila> okay. thank you :)
[11:14] <ailo> akhila: If you rather have multimedia type of questions, this is a good place for that
[11:18] <akhila> Actually I was directed to you to ask these very questions. Anyways, thank you for the information and your valuable time.
[13:29] <chimbo> hi all
[13:29] <smartboyhw> Hi chimbo, how can we help ya?
[13:30] <cbx33> sorry wrong nick
[13:30] <smartboyhw> Oh OK
[13:30] <cbx33> ailo helped me a bit earlier
[13:30] <cbx33> had a question regarding the rt irq stuff for USB
[13:30] <smartboyhw> Uh huh
[13:30] <smartboyhw> ailo: Help cbx33:)
[13:30] <cbx33> haha
[13:30] <cbx33> also just popped in to say hi
[13:31] <cbx33> I bought a Presonus AudioBox and used it on JACK last night
[13:31] <cbx33> worked very well indeed
[13:31] <cbx33> tried to use it with it's own DAW on windows 7 early this morning.....and the whole thing just froze
[13:31] <cbx33> makes me laugh
[13:31] <smartboyhw> LOL
[13:31] <cbx33> no exageration
[13:32] <cbx33> i had a few issues last night but I think that's because I was being cheeky with my frames/period
[13:32] <holstein> could be the settings... i find linux can be more graceful at failing
[13:32] <cbx33> i had a few xruns
[13:33] <cbx33> then i loaded audacity and got a never ending stream of xruns and everything just froze
[13:33] <cbx33> ardour didn't seem to like it much
[13:33] <cbx33> but then I am running SVN ardour3
[13:33] <cbx33> so i guess I should expect oddities
[13:33] <holstein> audacity really doesnt work well with JACK
[13:33] <cbx33> no
[13:33] <cbx33> I won't be trying that again
[13:33] <holstein> its not something anyone really works at making stable
[13:34] <ailo-w> cbx33: ardour aught to be quite reliable.
[13:34] <cbx33> the presonus is nice - i hooked up my guitar and used guitarix
[13:34] <ailo-w> cbx33: How's your performance now? And did you compare with your internal yet?
[13:34] <cbx33> ailo-w: even the SVN build?
[13:34] <cbx33> ailo-w: not yet, in the UK...lunch hour :)
[13:34] <cbx33> will have to wait till i get home
[13:34] <ailo-w> cbx33: At least when it comes to the jack part of it. The same guy behind ardour and jack
[13:35] <cbx33> ailo-w: of course
[13:35] <cbx33> I get a strange race condition too when using positional in ardour
[13:35] <cbx33> the first time i click on a position in ardour....both Jack and Ardour try to play catch up and get it wrong
[13:35] <cbx33> the second time i click it's ok
[13:36] <cbx33> so i just double click on the timeline now :)
[13:36] <ailo-w> That sounds terrible
[13:36] <cbx33> maybe that was frame related too....but i seem to recall i tried it last night and it was still bad even on a higher frame seeting
[13:36] <ailo-w> cbx33: You should report it
[13:36] <cbx33> well the playhead moved...but you got zero audio
[13:36] <cbx33> then o nthe second click, the audio returned
[13:37] <cbx33> gonna try the low latency kernel tonight.....except I don't like that my fan speed is higher with it
[13:38] <ailo-w> cbx33: One thing you could try is to lock the cpu to a lower speed
[13:38] <ailo-w> cbx33: You might not need it to be at full
[13:38] <cbx33> true
[13:38] <cbx33> this was when it was idling though
[13:38] <cbx33> maybe it's because the lowlatency kernel is further behind
[13:40] <cbx33> ie...powermanagement may have changed
[13:40] <cbx33> maybe i should install 64bit ubuntu
[13:41] <ailo-w> time to go home..
[13:53] <len-dt> cbx33, I haven't had that experience. The fan doesn't run that much for me till the cpu speed ramps up to full
[13:55] <cbx33> hmmm
[13:56] <cbx33> mine is definitely faster on low-latency
[13:56] <cbx33> which bugs me
[13:56] <len-dt> It could be that mine is a low power atom.
[13:56] <cbx33> is preempt still around?
[13:56] <cbx33> ahh
[13:56] <cbx33> yeh mine is an i5
[13:56] <smartboyhw> i5 here
[13:56] <cbx33> gee you can do recording on an atom?
[13:57] <cbx33> thinking of getting an SSD for this bad boy
[13:57] <smartboyhw> cbx33: Why not?
[13:57] <len-dt> yes, even at half speed (800 Mhz)
[13:58] <cbx33> wow
[13:58] <cbx33> len-dt: that's awesome
[13:58] <cbx33> I think my frames/period was too low
[13:59] <cbx33> 128
[13:59] <cbx33> or maybe I just have too much crap installed on my system :)
[13:59] <cbx33> gonna take a look at processes tonight and see what I can clean up
[14:00] <len-dt> 128 for live use (guitarix for example) is about the highest you want to go. For recording 1024 is pretty normal
[14:00] <cbx33> yeh that's what I thought
[14:00] <cbx33> guitarix is nice!
[14:00] <cbx33> i was playing my Ibanez through it last night
[14:01] <cbx33> very impressed
[14:01] <cbx33> my problem is with linux sampler - playing piano, I really need 128, as higher than that, I can feel the latency - and sometimes you want to "play" with the full multitrack
[14:01] <len-dt> cbx33, I like it too. I haven't had a real guitar amp in ages.
[14:01] <cbx33> if that makes sense
[14:01] <cbx33> it's a shame yo ucan't change them realtime
[14:02] <cbx33> len-dt: care to share any good setups - would be greatly appreciated sometime
[14:03] <len-dt> That makes sense. I would try using an external sound module (in my case whatever is in the synth I use for a KB) to get the midi into the computer when recording.
[14:03] <len-dt> then just use the sampler for play back.
[14:04] <cbx33> len-dt: yeh I could do that
[14:04] <cbx33> I have a Korg X5D
[14:04] <cbx33> I could also just use a GM midi
[14:04]  * len-dt uses an old dx7
[14:04] <cbx33> and as you say pipe it through linux sampler for playback
[14:04] <cbx33> but now I use an Alesis QX49
[14:05] <cbx33> anyone want an RM1x?
[14:05] <cbx33> Yamaha
[14:05] <cbx33> :)
[14:05] <len-dt> I'm not really a KB player... so the model names don't mean anything to me.
[14:05] <cbx33> Yamaha RM1x is a dance music thingy
[14:05] <len-dt> I can't play piano, but can add string pad kinds of things
[14:06] <cbx33> bought it because I wanted to do midi loop programming
[14:06] <cbx33> but never really used it much
[14:06] <cbx33> found it listed o na site as vintage the other day
[14:06] <len-dt> That happens
[14:06] <len-dt> my DX7 is from 1982 or so
[14:07] <len-dt> I like the feel of it
[14:07] <ailo> cbx33: You can change latency on the fly with ardour, or any other application with jack control that allows it
[14:07] <ailo> qjackctl doesn't do that
[14:08] <cbx33> ailo you got home quick
[14:08] <smartboyhw> That's quick ailo really
[14:09] <ailo> It's not far. I have a fast bike :)
[14:09] <cbx33> motorbike?
[14:10] <ailo> No, a racer bike. I don't know the right term. For regular roads
[14:10] <smartboyhw> Yay
[14:10] <ailo> A bicycle anyway
[14:10] <cbx33> yeh i cycle too
[14:10] <cbx33> about 3.6 miles each way
[14:12] <ailo> http://www.youtube.com/watch?v=2CTPLUcQAjk
[14:13] <ailo> I picked it up this summer
[14:13] <ailo> It's fun
[14:13] <smartboyhw> LOL
[14:16] <ailo> cbx33: Wait, is this your device? http://wiki.linuxmusicians.com/doku.php?id=presounus_audiobox_1818vsl
[14:16] <smartboyhw> Hmm I will go and join linuxmusicians forums now:)
[14:17] <ailo> cbx33: Another thing you might want to check is whether changing usb port makes a difference. Check the IRQ's with: cat /proc/interrupts
[14:17] <cbx33> ailo: nooooooooooooooooooo not an 1818
[14:17] <cbx33> just 2in2out
[14:17] <ailo> too bad
[14:18] <cbx33> i have an maudio delta 1010lt though
[14:18] <len-dt> cbx33, same machine?
[14:18] <ailo> cbx33: That'll at least serve great for comparison
[14:20] <cbx33> no
[14:21] <cbx33> delta1010 in a laptop :p
[14:22] <cbx33> I would love an 1818VSL though :p
[14:23] <ailo> I'm thinking of trading my focusrite sapphire pro 40 for it
[14:23] <ailo> It's great, but it's firewire. Which kind of limits the options
[14:23] <cbx33> well all i will say is my presonus sounded amazing
[14:23] <cbx33> ahh yeh
[14:23] <cbx33> they did a tudio bundle wit hthe presonus firewire - which i got very excited about
[14:23] <cbx33> until i realised i didn't have firewire
[14:24] <cbx33> can someone do me a favour - google for presonus m7
[14:24] <cbx33> and go to images....
[14:24] <cbx33> I'm a little new to condenser mics
[14:24] <cbx33> it has a grill on front and back
[14:24] <cbx33> and sounds different if you sing into the front or the back
[14:25] <cbx33> is it a cardioid response?
[14:25] <ailo> cbx33: Yea
[14:25] <cbx33> and you can choose which side to use for different applications?
[14:25] <cbx33> or would you only ever use one side
[14:25] <ailo> cbx33: With cardoid, you can only use the one side
[14:26] <cbx33> ok
[14:26] <cbx33> it still sounded nice on the other side - but a bit more bass heavy
[14:27] <cbx33> you'd never believe I have a degree in acoustical engineering would you :p
[14:27] <ailo> cbx33: The other side should sound like someone talking with their back turned towards you
[14:28] <ailo> Depends a bit on the room acoustics, whether you get a lot of high frequency into the mic that way
[14:28] <cbx33> yeh
[14:28] <cbx33> ahh room acoustics - that was a fun lecture
[14:28] <cbx33> or series - the wave equation in 3D space - derivation
[14:29] <cbx33> http://www.presonus.com/community/Learn/Equalizer-Terms-and-Tips - found this yesterday looks quite useful
[14:30] <ailo> I had once opened my mic, and screwed the actual microhpone the wrong way. I friend borrowed it and said the sound sucked, and that even his low value mic was sounding better
[14:30] <cbx33> hahaha
[14:30] <ailo> I came to check. Turned it around, and suddenly the vocals started to sound really sharp
[14:30] <cbx33> hahah
[14:31] <cbx33> well ailo, I've only done limited recording with the presonus, like only got it yesterday, but have been exceedingly happy with it's performance and sound quality
[14:31] <cbx33> oh a question guys....the USB should act almost like a decoupler shouldn't it?
[14:32] <cbx33> I have a dynamic mic, AKG D69S and it was picking up the fan hum rom the laptop
[14:32] <cbx33> that must have been some kind of electromagnetic effect right
[14:32] <cbx33> i mean the is no way noise could have gotten from the laptop to the USB in/outs as that would have been a digital signal right?
[14:33] <len-dt> cbx33, that should be... but if you are using power from the usb there may be some noise transfer
[14:33] <cbx33> ahh I am
[14:33] <cbx33> :(
[14:33] <len-dt> The box has to power it's pre amp from something.
[14:33] <cbx33> need to buy a USB hub and an optoisolator maybe :p
[14:33] <ailo> cbx33: Depends. Some combination of laptops and devices will introduce ground hum, if the laptop is connected to an electrical outlet
[14:33] <cbx33> the M7 didn't suffer the same
[14:34] <cbx33> no it was not 50Hz
[14:34] <cbx33> it was much higher
[14:34] <cbx33> a whine
[14:34] <len-dt> Does your interface have a power plug on it?
[14:34] <ailo> The M7 should be a lot less forgiving when it comes to general noise in the room
[14:34] <cbx33> len-dt: no
[14:34] <ailo> Usually, any computer will be too noisy for a condenser
[14:34] <cbx33> powered through USB
[14:35] <len-dt> Ya, some are either or, thought I would ask.
[14:35] <len-dt> Mine has its own PS because it has tubes in it.
[14:35] <cbx33> ahh
[14:35] <cbx33> ailo - I had a little "noise" but only white
[14:36] <ailo> I once got clicking noise in some dynamic mics
[14:36] <ailo> Took us a while to figure out what it was. There was a vacuum cleaner next to the drums
[14:36] <ailo> Something about magnetism
[14:37] <ailo> It sounded like audio dropouts, which of course made me think it was the computer first, but since it only happened to some mics, it really bothered us for a while
[14:39] <cbx33> hahaah
[14:40] <cbx33> i had a nasty earth loop 10 years ago
[14:40] <cbx33> :)
[15:01] <cbx33> sorted it by twisting a paperclip around the rack ears of the behringer and the lexicon
[15:10] <cbx33> ailo: I used to run Logic on an AMD K6-2 500 Mhz
[15:10] <cbx33> heh
[15:10] <cbx33> didn't get a whole lot of love fro mthat
[15:15] <ailo> Logic? Was that the old Windows version?
[15:15] <ailo> It had it's own sound, thanks to it's builtin plugins
[15:25] <cbx33> yes
[15:25] <cbx33> 4.5
[15:25] <cbx33> Gold
[15:25] <cbx33> I was furious when they went mac only
[15:25] <cbx33> but i did love the midi raouting and patching it did
[15:26] <ailo> I never got the logic of it. I much preferred cubase. Been a few years since I had Windows now though
[15:26] <cbx33> yeh
[15:26] <cbx33> i would love a better midi "munger"
[15:26] <cbx33> mididings is nice - but with a gui it would be killer
[15:27] <cbx33> the fade in/out on ardour - is there a way to "curve" rather than linear?
[15:27] <ailo> Haven't done much with it. But, I bet the boys at #ardour would know
[15:27] <cbx33> yeh - it's a little too early in there atm :)
[15:27] <smartboyhw> ailo: I will go sleep now
[15:35] <cbx33> ailo do you use a multitracker?
[15:41] <ailo> cbx33: You mean, like Ardour? I don't use DAWs that much these days. Mostly puredata
[15:45] <cbx33> ahh
[15:46] <cbx33> http://en.wikipedia.org/wiki/Pure_Data?
[15:47] <cbx33> JACK capable?
[15:50] <cbx33> bbl
[18:47] <cbx33> hey all
[18:47] <cbx33> guitarix has a head that brings my machine to a crawl
[18:48] <cbx33> sends JACK to 100%
[18:48] <holstein> it happens.. you tried the support channel?
[18:48] <cbx33> no
[18:49] <holstein> i would guess they will askk if you are running the lastest from them, and you probably arent
[18:49] <holstein> cbx33: if youd like to file a bug report though... go for it
[18:49] <cbx33> hmmm
[18:49] <cbx33> must be my USB device related
[18:49] <holstein> could be
[18:50] <cbx33> damn
[18:50] <cbx33> ailo, you around?
[18:50] <cbx33> with XRUNS.....what does count and notifications mean
[18:50] <cbx33> what's the difference?
[18:50] <cbx33> 1(14)
[18:50] <cbx33> 1(140)
[18:50] <cbx33> what does that mean?
[18:51] <holstein> cbx33: i could look that up, but i would try and catch las in #ubuntu
[18:51] <holstein> he wrote it, and would know
[18:52] <cbx33> yeh
[18:52] <cbx33> lemme rtfm
[18:52] <holstein> i remember the (*)'s being not as important though
[18:52] <holstein> cbx33: i like to see none there though
[18:52] <cbx33> i know
[18:52] <holstein> cbx33: i dont think las would mind you asking
[18:52] <cbx33> i talk to las a fair amount
[18:52] <cbx33> i think i should try to low latency kernel
[18:53] <holstein> cbx33: yeah, if you arent, thats first thing
[18:53] <cbx33> does anyone know does rtirq work with lowlatency kernel
[18:53] <cbx33> or just RT kernel
[18:54] <holstein> cbx33: i know we didnt get the message about rt privs not being possible when testing the lowlatency kernel
[18:54] <holstein> i would try lowlatency, then RT
[18:54] <holstein> i actually have a USB device that works much better with the generic
[18:54] <cbx33> really?
[18:55] <cbx33> well this one doesn't apparently
[18:55] <cbx33> i know people ate using the 18in18out version in linux
[18:55] <cbx33> and it works well
[18:55] <cbx33> mines just a 2in2out
[18:55] <cbx33> guess i just need to get the settings right
[18:55] <holstein> cbx33: its just one random device.. i just happend to test it that way
[18:57] <cbx33> weird
[19:00] <cbx33> guitarix -> funkmuscle -> jazz
[19:00] <cbx33> ruins my machine
[19:00] <cbx33> both on internal and external audio device
[19:02] <len-dt> cbx33, that does seem to be fixed in the new version. I had a few that really slowed my machine down too.
[19:02] <cbx33> oh
[19:02] <cbx33> new version as in?
[19:03] <cbx33> I mean I'm getting 100% DSP here :)
[19:03] <len-dt> But if you are running 12.04 you should have something pretty new
[19:03] <holstein> thats something we should look at and maybe backport
[19:03] <cbx33> the thing that is funny is that though I hit 100% DSP, my CPU fan doesn't spin up
[19:04] <len-dt> it seems to say it is 0.24.0
[19:06] <cbx33> 0.20.2
[19:06] <cbx33> maybe that's it then
[19:10] <cbx33> len-dt, which version has the fix
[19:10] <cbx33> 0.24.0?
[19:12] <cbx33> it's the push-pull ones that do it
[19:28] <len-dt> I had the one with the sort of gold/bronze color GUI where the main heqad would come up and the rack was separate. the new one has everything in the rack and by default comes up grey with presets at the bottom.
[19:29] <len-dt> the old one had about half of the presets did bad things.
[19:29] <len-dt> I think there may even be a newer one, but I am not sure.
[19:31] <len-dt> His web page says 0.24.0
[19:39] <len-dt> cbx33, I have found the ladspa guitarix plugins a pain. any time there is no track where it is active strange things happen.
[19:40] <len-dt> for example if a cut out a portion of a track becasue of background noise (or my bad playing) the guitarix plugin doesn't like that.
[19:41] <len-dt> however, my machine is a 10 year old P4 and can only handle so much.
[19:42] <cbx33> heheh I can't believe you're able to do anything on that
[19:43] <len-dt> I had 5 or 6 tracks playing by then with other effects on abnout 2/3 of them.
[19:43] <holstein> audio is not that big a deal
[19:44] <holstein> its video that is pretty hard to handle with an old system
[19:44] <len-dt> I recorded without effects at a lower latency and added effects after at a higher one.
[19:44] <holstein> len-dt: i do that just for good measure on my dual core :)
[19:45] <cbx33> len-dt, good job
[19:46] <len-dt> The only xruns I seem to get are when I hit the |< to go back to the track start.
[19:47] <len-dt> dual monitors seems to be pretty common for audio work.
[19:47] <cbx33> yeh
[19:47] <cbx33> that's true
[19:48] <cbx33> len-dt, is guitarix hard to build?
[19:48] <len-dt> I just downloaded the package from the ubuntu repos with synaptic
[19:49] <cbx33> oh
[19:49] <cbx33> so you're running 12.04
[19:49] <len-dt> ya
[19:49] <cbx33> so how come we got different versions?
[19:49] <cbx33> 0.20.2 here
[19:50] <len-dt> have you run the upgrade
[19:50] <cbx33> i'm up to date as far as i know
[19:51] <len-dt> open synaptic and see if it will let you install a newer one
[19:51] <cbx33> ok
[19:52] <cbx33> mine says 0.20.2-3ubuntu1
[19:52] <len-dt> if you scroll over it should say installed and latest version
[19:53] <cbx33> yup
[19:53] <cbx33> latest = installed
[19:53] <cbx33> what sources are you using
[19:54] <cbx33> some ppa or something?
[19:54] <len-dt> while I do have kzstudio, that particular package doesn't seem to have come from there.
[19:55] <cbx33> hmmm
[19:56] <len-dt> The section says Multimedia(universe) the maintainer says Roland Stigge
[19:56] <cbx33> apt-cache madison guitarix
[19:57] <len-dt> If you right click on the guitarix entry in synaptic and select properties in common it gives some info
[19:57] <cbx33>   guitarix | 0.20.2-3ubuntu1 | http://gb.archive.ubuntu.com/ubuntu/ precise/universe i386 Packages
[19:57] <cbx33>   guitarix | 0.20.2-3ubuntu1 | http://gb.archive.ubuntu.com/ubuntu/ precise/universe Sources
[19:58] <len-dt> Let me check my netbook which is more stock.
[19:59] <cbx33> ko
[19:59] <cbx33> apt-cache madison will give you the source of the package
[20:04] <len-dt> Well, it apears you are right. I must be getting this from kxstudio. The one on my netbook is the old one
[20:04] <cbx33> ahhh
[20:04] <cbx33> ok - ty len-dt
[20:04] <cbx33> hopefuly it'll be updated in the next ubu release
[20:05] <len-dt> I will have to check 12.10 (on the other drive right now) and see what that has.
[20:05] <cbx33> is kx a direct competitor to ubustudio?
[20:05] <cbx33> how is 12.10 shaping up?
[20:05] <len-dt> kxstudio is a group of apps meant to sit on top of ubuntu.
[20:05] <len-dt> 12.10 seem pretty good mostly UI improvements though
[20:06] <cbx33> ahh
[20:06] <cbx33> ko
[20:06] <len-dt> kxstudio is actually on the ubuntu servers I think
[20:07] <cbx33> oh
[20:07] <len-dt> Ya ppa.launchpad.net/kxstudio-team/ppa/ubuntu precice
[20:07] <cbx33> cool
[20:08] <len-dt> holstein, It seems you are right about backporting guitarix.
[20:11] <cbx33> do people ever change the periods/buffer setting in JACK?
[20:14] <len-dt> 12.10 has guitarix 0.22.4
[20:14] <cbx33> ok that's better
[20:14] <len-dt>  yes people change that
[20:14] <cbx33> what effect does it have
[20:15] <len-dt> It effects latency along with frames/period. I have heard that 3 is better for USB IFs
[20:16] <cbx33> hmm
[20:16] <len-dt> I have not tried that though.
[20:16] <cbx33> I will try that
[20:17] <len-dt> anyway, I need lunch then I have some papers to do. Bye now.
[20:18] <cbx33> laters len-dt
[20:18] <cbx33> thanks for the help
[20:41] <cbx33> do people here get xruns when they open/close apps
[22:15] <livingdaylight> greetings


[03:04] <Fudge> probably ubiquity paddy
[03:18] <gnomguy> I just had a continuous noise... any report of something like this?
[03:18] <gnomguy> I had to reboot... nothing stopped it... it was ongoing
[03:31] <Hydr0p0nX> not sure if this is a pre-release question or not but, i'd like to install the saucy hwe on 12.04, I don't see the Xorg portion in the repositories though, just the kernel... Is there another repository I should be looking at ?
[07:21] <ThomasB> rhythmbox on 14.04 needs my last.fm integration asap
[07:21] <ThomasB> can't scrobble :(
[07:43] <randomcpp> is there anything wrong if I set a daily cron job for fstrim in trusty? I know trim is enabled in trusty, but as weekly job IIRC
[07:44] <lotuspsychje> randomcpp: TRIM should be enabled by default cron job
[07:44] <lotuspsychje> having it daily is not bad
[07:44] <lotuspsychje> you can manually TRIM every day aswell
[07:44] <lotuspsychje> man fstrim
[07:47] <lotuspsychje> randomcpp: pm me for other ssd tweaks mate
[07:47] <randomcpp> lotuspsychje, I know that, but I'm new to SSD I wanted to know if there were some contraindications
[08:53] <sandGorgon> lotuspsychje, can you send me your SSD tweaks as well? or pastebin it and post here. would really appreciate it
[08:54] <lotuspsychje> sandGorgon: see pm :p
[11:20] <cortez> so trusty is running xorg server 1.14, right?
[11:22] <bazhang> !find xorg-server
[11:23] <bazhang> !info xserver-xorg-dev
[11:23] <bazhang> yep
[11:24] <cortez> thanks, bazhang. now how do i make ubottu tell us the rationale for that? ;)
[11:25] <cortez> i.e. i've seen 1.15 in the wild on other distros
[11:25] <bazhang> cortez, I'd try the mailing lists for that
[11:25] <cortez> at least i think i have...
[11:25] <bazhang> !lists
[11:25] <cortez> ok
[12:47] <BluesKaj> Hiyas all
[16:55] <alnr> after upgrade to 14.04, my system boots to grub rescue, file not found. solved by F12 boot menu, boot from 2nd hard drive. what should I do to repair the boot process (tried to install boot-repair from ppa but not found)
[17:29] <alnr> i'm guessing boot-repair isnt available yet for 14.04
[17:31] <holstein> alnr: you can run it from a live CD
[17:36] <Allison43> alnr, boot repair is it's own OS not a package in ubuntu
[17:37] <Allison43> use on alive media, cd or usb
[17:37] <alnr> Allison43: oh, becuase i have seen a boot-repair package in ppa yannubuntu
[17:38] <alnr> Allison43: ok usb would be a lot less pain than cd, thanks
[17:39] <holstein> alnr: you can run the software from a liveCD.. it will pick up os's, such as 14.04, or windows, or whatever
[17:39] <Allison43> http://sourceforge.net/p/boot-repair-cd/home/Home/
[17:39] <Allison43> alnr,^
[17:40] <holstein> or, just add it to whatever live CD you have handy... https://help.ubuntu.com/community/Boot-Repair
[17:40] <alnr> Allison43: thanks a lot. i'll have to brush off my usb-key making skills.
[17:42] <Allison43> well, if you can buirn a cd it's abit easier
[18:28] <roothorick> the wifi picker in the installer is broken. Clicking "Connect" does absolutely nothing. I can connect to networks just fine via the gnome-shell bar so it's not a driver issue
[20:09] <Gilligan94> Hi I intend to chuck the 14.04 dailies on a spare drive to watch it's progress, I'll be dual booting it with Windows 8.1, what do I need to do to get it to boot the USB in UEFI mode so that the bootloader installs correctly?
[20:28] <Allison43> !UEFI
[20:28] <Allison43> Gilligan94,^
[20:37] <roothorick> sigh. powernow-k8 managed to creep back into the kernel
[20:38] <bekks> Kill it with fire.
[20:39] <roothorick> Is there a way to disable powernow-k8 with it builtin as it is in the normal kernels, or do I have to build my own kernel?
[20:40] <bekks> Blacklist the module.
[20:40] <roothorick> it's not a module.
[20:40] <bekks> It doubt it is compiled into the kernel.
[20:40] <roothorick> it is, in fact, compiled into the kernel
[20:41] <roothorick> config-3.12.0-7-generic: CONFIG_X86_POWERNOW_K8=y
[20:42] <roothorick> I want to use phc-k8 so this is a problem
[20:47] <bekks> Then you have to recompile the kernel.
[20:51] <roothorick> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/355232
[20:53] <roothorick> this is actually a BFD for me as HP in their infinite wisdom designed this laptop in such a way that the CPU can't be run at full power and voltage for an extended period of time without overheating
[20:54] <roothorick> but I can safely undervolt the proc A LOT, and it reduces the heat enough to maintain full load at the full 2.0Ghz indefinitely
[21:03] <roothorick> what the... why are you building the deprecated SpeedStep driver at all!?
[22:32] <roothorick> thermal-throttled kernel compile. Truly, this is hell.


[18:27] <Eickmeyer> Still getting build failures for Ubuntu Studio images. Has any progress been made on these build failures? Seems to be an issue with a lack of internal URLs?


[12:55] <BluesKaj> Hi all
[20:42] <blaze> can not upload to LP right now, getting 550 status code. can be my local problem
[20:54] <tsimonq2> blaze: https://lists.ubuntu.com/archives/ubuntu-devel/2023-November/042843.html
[21:01] <blaze> worked like a charm
[21:01] <blaze> thanks
[21:04] <tsimonq2> Of course. :)
[21:05] <tsimonq2> blaze: Subscribe to ubuntu-devel, silly.


[00:15] <cjwatson> kees: I wonder why he still has a mountall process running
[00:16] <cjwatson> oh, heck, Ubuntu 9.10
[00:18] <kees> yeah, I was going to try to spin that up on a more modern system.
[00:33] <ScottK> cjwatson: re maintainer lock and Ubuntu - Maintainer is Ubuntu developers, so perhaps that means non-developers shouldn't be invalidating bugs?
[00:40] <RoAkSoAx> sud/win 9
[00:40] <RoAkSoAx> pff
[00:57] <charlie-tca> We did get 'won't fix' and 'fix-released' locked now. anything is possible
[01:11] <ScottK> charlie-tca: We were rather discussing the opposite problem of people deciding that there was some age that magically made bugs bad.
[01:12] <charlie-tca> yup
[01:12] <charlie-tca> I read the backlogs. That was a comment on the "non-developers shouldn't be invalidating bugs"
[01:12] <charlie-tca> Might help to lock down more statuses
[01:13] <charlie-tca> It is hard sometimes to know what to do with bugs, but most developers will tell you if asked.
[01:37] <cjwatson> psusi: BTW, I'm sorry we didn't meet up at UDS (did you make it?  I saw scrollback suggesting you were thinking about going); this conversation would probably have been friendlier over a beer :-)
[01:37] <psusi> indeed, I knew I should have run over there damnit... I didn't realize it was in town until it had started already
[01:39] <psusi> I hopped in the irc channel for a meeting I saw scheduled about grub but nobody seemed to say anything
[01:39] <cjwatson> I didn't hear about that
[01:40] <cjwatson> was that a bugsquad meeting?
[01:40] <psusi> I think it was to do with leaving the graphics mode on with the graphics payload option so plymouth could take over the screen without switching back and forth to text mode
[01:41] <cjwatson> oh, you mean the UDS IRC channel
[01:41] <cjwatson> most of the conversations were audio-streamed - there was only IRC conversation if people were participating via IRC
[01:42] <psusi> your comment about service ticket vs. bug report resonated with me... it seems like a number of bug reports are really service requests rather than describing a defect.. what is the proper way to handle those?
[01:42] <cjwatson> anyway, most of that was about organising the kernel bug triage work so that we can actually leave the grub switch on this time round; the bulk of the work has already been done there (although ebroder is doing some extra stuff to let us handle a blacklist/whitelist at boot time)
[01:43] <psusi> that's what I figured... and I was at work at the time so couldn't get the audio streaming
[01:43] <cjwatson> service requests should often be converted to questions (though ask somebody to double-check if you're going to do that in bulk)
[01:44] <cjwatson> mostly crash reports should be left where they are, though.  it would be nice if we had a separate crash database that was better optimised for that work, but we don't
[01:45] <lifeless> cjwatson: we're happy to optimise things in lp
[01:45] <lifeless> cjwatson: if you can tell us what you want (or even supply patches ;))
[01:47] <cjwatson> well, TBH I think crashes should be entirely separate from bugs, and promotable to bugs once the crash has been analysed
[01:48] <cjwatson> this seems a tad out of scope for the sort of thing I'm likely to be able to patch in a spare afternoon
[01:48] <lifeless> cjwatson: that would make sense to me
[01:49] <psusi> I'm looking at bug #668595 at the moment... I'm sure you can see that the description is not a useful bug report... converting it to a question though eh?  I'm not even sure I can frame it as a useful question...
[01:49] <cjwatson> not a new idea, though; see https://wiki.ubuntu.com/CrashReporting for instance
[01:51] <cjwatson> psusi: I agree that that isn't a useful bug, and it would be best to convert it to a question.  Doing so doesn't require you to do any framing at all - questions are generally in that kind of phrasing, and the workflow is that helpers work through the problem back and forth with the asker
[01:52] <cjwatson> (whether anyone will be able to help him, I'm not sure; but the good thing about converting that way is that the message sent to the reporter isn't that their bug has been invalidated, but that it's been moved)
[01:52] <psusi> hrm... ok...
[01:52] <cjwatson> of course there are certainly other forums, e.g. askubuntu.com seems popular lately
[01:54] <cjwatson> I mostly only invalidate bugs on the spot when somebody just banged a few random words into the web form, which seems to happen occasionally for installer bugs for some reason
[01:57] <psusi> heh... yea.. saw that one you had touched because ubiquity crashed trying to install grub and the guy said the problem was something about graphics settings... graphics?  what?!
[01:58]  * ajmitch is reluctant to file bugs when it was something along the lines of 'laptop randomly crashed, apport has detected a kernel dump'
[01:58] <ajmitch> also because apport was taking 3GB of RAM when trying to file it, it never succeeded unfortunately
[02:01] <cjwatson> sometimes the weirdest things turn out to be relevant though.  although it isn't the case right now, you might imagine that grub was looking at the X display resolution at install time in order to construct a splash image, and in that case graphics could well be relevant
[02:02] <psusi> ok... what if a bug does not apply to the current release, but is confirmed and triaged for a previous one?  it should be tracked in that release right?  but it seems like to get that to happen, you have to nominate it for that release and make a compelling case for an SRU... what if it fails to meet the criteria for an SRU?
[02:03] <ebroder> psusi: No, nominating a bug for a release and arguing for an SRU are two different steps
[02:03] <lifeless> nomination is a release-manager task
[02:03] <lifeless> its going to be locked down soon
[02:04] <lifeless> nomination is 'this bug is needed to do that release'
[02:04] <psusi> I thought that was milestone?
[02:04] <psusi> and tracking in a release was to track SRUs?
[02:04] <cjwatson> I think the proposal was to lock down nominations to developers
[02:05] <cjwatson> that was what I read at least, and makes a little bit more sense to me than restricting to release managers (since only release managers can *accept* nominations)
[02:05]  * ajmitch thought that core devs could accept nominations, was that changed?
[02:05] <psusi> right... but don't they only accept a nomination as part of approving an SRU?
[02:06] <cjwatson> ajmitch: oh, maybe
[02:06] <cjwatson> psusi: the problem is that the nomination queue is unusable because people see the button and go "ooh, yeah, I'd like that fixed in lucid please"
[02:06] <psusi> exactly
[02:06] <cjwatson> so it does need to be locked down more than it currently is
[02:07] <cjwatson> anyway, to answer your question, if the bug is already targeted and fails to meet SRU criteria, then Won't Fix is appropriate, but IMO that action should normally be taken by the body responsible for deciding whether bugs meet SRU criteria, i.e. the ubuntu-sru team
[02:07] <psusi> sure... but is my understanding of the purpose incorrect?  isn't it to track an SRU?  so if a case can not be made for an SRU, it should not even be nominated?
[02:09] <psusi> hrm... then perhaps a triager should nominate it for the release and note to the sru team that a compelling SRU case can not be made, so it should probably just be set as WONTFIX, but none the less does exist in that release so its status should be tracked there to differentiate it from the development release where it isn't an issue?
[02:09] <cjwatson> if it doesn't have the faintest hope of meeting SRU criteria, or if developers aren't interested in proposing it, and it isn't already nominated, then the right thing to do is normally to simply set the status according to its status in the development release; that is, if it's fixed there, it should be Fix Released, etc.
[02:09] <cjwatson> there's no point in shovelling stuff through the nomination queue when we already know the answer is no
[02:10] <cjwatson> a very large number of bugs exist in stable releases, but we need to be able to do effective stable release management without drowning in them
[02:10] <cjwatson> effective stable release management includes fixing the right bugs, of course, not just saying no all the time :-)
[02:11] <psusi> so then as a general rule, if a bug is reported in an older release, and they try a new release and find the problem has gone away, it should be marked as fix released rather than targeted to the version where it is known to still be broken?
[02:12] <maco> ajmitch: motu can accept nominations for universe bugs..
[02:12] <ajmitch> maco: ah right, I was probably just asked to accept nominations for things I could upload to :)
[02:12] <cjwatson> roughly, yes, though I would recommend attempting to understand the problem too.  for example I often see people closing bugs for that kind of reason when the problem isn't fixed at all - usually because either the triager didn't have a setup suitable for reproducing the bug in the first place, or because the scope of the problem got more limited
[02:13] <maco> i believe the lp blog said they were being locked to the bug driver (is that the term?) which in ubuntu's case is Bug Control
[02:13] <cjwatson> it's normally easy if the reporter says it's gone away; otherwise it's a good idea to make a bit more of an effort
[02:13] <cjwatson> maco: ah, right, that sounds like what I was misquoting, though
[02:13] <cjwatson> s/though/thanks/
[02:19] <micahg> still on this tpoic?
[02:19] <micahg> *topic
[02:21] <highvoltage> micahg: it's obviously important :)
[02:22] <micahg> indeed
[02:24] <ScottK> micahg: I believe it is.  Figuring out how to better integrate bug triage efforts and development is an important topic for Ubuntu Development.
[02:24]  * micahg will review the logs a little later
[02:36] <gbillings> I have a wireless card that does not currently work in Ubuntu (any release) "Out of Box." It works by simply running a script, which I uploaded here https://launchpad.net/dell1450usb . How would I make it so that is supported out of box in Ubuntu (hopefully by Natty)?
[02:45] <ScottK> Sigh.
[02:45] <ajmitch> ScottK: ?
[02:45] <ScottK> lifeless: ^^^ includes a binary blob, so I don't think it's appropriate for LP.  Is there a process for that?
[02:46] <ScottK> ajmitch: ^^^
[02:46] <lifeless> ScottK: context?
[02:46] <ScottK> lifeless: The branch that gbillings referred to there has a binary blob of some kind in it.
[02:46] <ScottK> https://launchpad.net/dell1450usb
[02:47]  * ScottK didn't think such things were allowed on the public launchpad.
[02:47] <lifeless> ScottK: its CC licensed
[02:48]  * ScottK looks again
[02:48] <gbillings> ok what did I miss?
[02:48] <lifeless> ScottK: according to the front page that is
[02:48] <slangasek> lifeless: doubtful; it looks to me like a binary blob from somewhere upstream (contains a "created 2006" string in it) that's been mislabeled as CC
[02:50] <lifeless> grah
[02:50] <lifeless> gbillings: do you have redistribution rights for what you've uploaded there?
[02:50] <slangasek> gbillings: you didn't upload just a script, you also uploaded a firmware blob - where did this blob come from?
[02:50] <ajmitch> debian wiki seems to indicate it's non-free firmware from prism54.org
[02:52] <slangasek> gbillings: the right way to get such a bug fixed for natty is to file a bug on the linux source package by running 'ubuntu-bug linux'; it's an open question whether we'll be able to use this firmware blob as part of the solution, but when filing the bug please include a pointer to whatever your source for it is
[02:55] <RoAkSoAx> slangasek: howdy!! By any chance do you have the time to review a couple of library splits (cluster-glue / pacemaker )?
[02:56] <gbillings> Okay, so file a bug on the "linux" source package, and include a link to where I got the firmware? right?
[02:59] <lifeless> gbillings: I'm disabling the project
[02:59] <lifeless> gbillings: because we can't redistribute it
[02:59] <gbillings> lifeless, what?
[02:59] <gbillings> oh, ok
[02:59] <gbillings> so do you wish for me to link to it?
[03:00] <lifeless> gbillings: huh?
[03:00] <gbillings> i am so confused
[03:01] <gbillings> my package is gone
[03:01] <highvoltage> gbillings: file a bug and explain what you did to get it working on your system. the script that you had in that bzr branch didn't fix the problem in the right place and the right way, so it couldn't be included in ubuntu as it existed there
[03:01] <lifeless> yes, it was against the launchpad terms of service because of the firmware blob
[03:03] <gbillings> ok I understand both your points. Thanks for saving me the legal trouble! I didnt realize that it was illegal
[03:04] <gbillings> I found the firmware here: http://daemonizer.de/prism54/prism54-fw/ ; and wrote the script using information here: http://ubuntuforums.org/showpost.php?p=9304551&postcount=4
[03:05] <YokoZar> Are the plenary talks online yet?
[03:05] <YokoZar> jcastro: ^^^ or will it take weeks like last time?
[03:05] <stgraber> YokoZar: AFAIK they're on blip.tv
[03:11] <YokoZar> stgraber: found it, "Ubuntu Developers" channel
[03:14] <gbillings> filing the bug as I speak
[03:18] <ScottK> lifeless: The file is still available through the branch? http://bazaar.launchpad.net/~lymera1n/dell1450usb/trunk/annotate/head:/isl3887usb
[03:19] <lifeless> ScottK: yes
[03:19] <lifeless> ScottK: https://bugs.launchpad.net/launchpad-code/+bug/669750
[03:19] <ScottK> Lovely.
[03:20] <ScottK> Thanks.
[03:20] <lifeless> filed it earlier when I noticed
[03:22] <gbillings> I could have removed it, but it was deactivated
[03:24] <gbillings> ScottK, how did u even find that?
[03:24] <ScottK> gbillings: I still had the page open from before it was deactivated.
[03:25] <gbillings> ScottK, oh, that makes sense
[03:26] <gbillings> ok, well sorry for the confusion, and I will be sure not to upload fw blobs again to launchpad. night
[05:47] <micahg> maco:  Ubuntu's bug driver isn't bug control, bug control is the bug supervisor
[05:47] <maco> micahg: there's more than one bug management thingy?
[05:48] <micahg> maco: yes, bug supervisor can set the statuses, bug driver will soon be the ones to accept nominations and bug supervisor will be the one to nominate
[05:48] <maco> confusing
[05:55] <hyperair> micahg: anyone can nominate afaik.
[05:55] <micahg> hyperair: ATM, but that will change soon
[05:57] <hyperair> micahg: ah, okay. but what about contributors who want to prepare SRUs?
[05:58] <micahg> hyperair: good question :), we'll have to have them subscribe sponsors or something to do it I guess, I'll bring it up at the bugsquad meeting if the agenda isn;t that long
[05:58] <maco> you dont need to nominate to prepare an sru...
[05:58] <micahg> maco: it's currently part of the process
[05:58] <maco> subscribing sponsors is how youd currently get hte debdiff looked at
[05:59] <hyperair> and to get the SRU acked, you'd nominate and then subscribe -sru
[05:59] <maco> no...
[05:59] <hyperair> maybe we should chaneg that process a bit. it's kinda weird
[05:59] <maco> pre-upload ACK is no longer needed
[05:59] <hyperair> we can just upload directly to the -proposed pocket.
[05:59] <hyperair> yeah
[05:59] <maco> the sponsor uploads it, and when the sru team sees something in teh queue for a stable release, they go look at hte bug
[05:59] <micahg> hyperair: currently, it's nominate then subscribe sponsors
[06:00] <maco> as long as you remember to put the LP: # in the changelog, they can find it
[06:00] <micahg> maco: the sponsor should subscribe --sru
[06:00] <hyperair> maco: right. so we need to change the process in wiki.
[06:00] <maco> i wonder how much sru team actually pays attention to subscriptions...
[06:00] <ebroder> the rules say they should, sure, but as i understand it it's not actually necessary for the normal sru processing procedure
[06:00] <hyperair> iirc it still asked you to nominate or whatever.
[06:01] <maco> they're subscribed to a MASSIVE number of bug reports
[06:01] <maco> of /open/ bug reports
[06:01] <hyperair> heh
[06:01] <micahg> maco: yes, but they have scripts to help them
[06:02] <ebroder> the sponsorship queue doesn't see bugs that are FIX RELEASED and not accepted for a stable release, right?
[06:02] <micahg> ebroder: I would think it should
[06:02]  * micahg sees SRUs in the queue
[06:03] <ebroder> but are those cases where stable release nominations have been accepted?
[06:03] <micahg> ebroder: yes, I think so, I'm starting to see the problem :)
[06:05] <ebroder> hmm...looks like merge proposals stay open. i guess that's another point for udd
[06:40] <dholbach> good morning!
[08:10] <persia> highvoltage, Thanks for the pointer, although I believe the derivation happened the other way in this case, as we had flavours long before Debian had pure blends.
[08:13]  * Hobbsee flushes the ubuntu-devel ML queue
[08:13] <Hobbsee> there was mail from april there :(
[09:32] <Laney> :(
[09:32] <nigelb> ?
[09:49] <geser> cjwatson: as you TIL gparted last, can you look at bug 669826 (sync for natty) and bug 617885 (maverick SRU candidate) please
[11:03] <sladen> who's a good contact for "The Ubuntu Solutions" group within C. ?
[12:27] <TheMuso> c
[12:27] <Pici> python
[12:34] <directhex> c#!
[12:38] <nigelb> perl
[12:44] <bilalakhtar> Removed the phrase about the UDS channel from the topic
[12:59] <pitti> Good morning
[13:09] <cjwatson> geser: ok
[13:09]  * cjwatson adds to growing queue :-(
[13:11] <bilalakhtar> Do packages that have passed Debian NEW also need to go through Ubuntu NEW?
[13:11] <seb128> did somebody start doing an autosync run?
[13:11] <seb128> cjwatson, pitti: ^?
[13:11] <seb128> seems the queue has an half done run
[13:11] <pitti> not me
[13:12] <pitti> bilalakhtar: formally yes, but we fast-pace them
[13:12] <seb128> bilalakhtar, somewhat, they go through new but get accepted without checking
[13:12] <pitti> i. e. usually when an archive admin syncs new pakcages from Debian, he would make a list of them and accept them wholesale
[13:14] <cjwatson> seb128: it's me
[13:14] <cjwatson> please hold
[13:14] <cjwatson> not an autosync, I was processing new-source and didn't finish
[13:15] <seb128> cjwatson, ok
[13:15] <cjwatson> keeps falling over
[13:43] <cjwatson> seb128: all yours
[13:43] <seb128> cjwatson, thank you!
[13:59] <kees> pitti: tb meeting shortly
[13:59] <pitti> kees: oh, right; that timezone
[14:00] <kees> pitti: oh, did it move?
[14:01] <pitti> kees: no, I did :)
[14:01] <kees> heh, okay.
[14:01] <pitti> kees: but due to the different DST in Europe and US I'm not actually sure whether it's now or in 1 h
[14:01] <pitti> my calendar shows it both times
[14:02] <kees> yeah. fridge says "3pm", but I don't think it's right
[14:15] <bilalakhtar> Did an aytosync take place recently?
[14:15] <bilalakhtar> *autosync
[14:16] <Laney> at least new-source did, from backscroll
[14:28] <mathiaz> BlackZ: yes - the package set for ubuntu-server exists
[14:28] <BlackZ> mathiaz: what packages are part of it?
[14:29] <Laney> BlackZ: edit_acl.py -P ubuntu-server -S natty query using lp:ubuntu-archive-tools
[14:30] <BlackZ> Laney: oh, yes, this is a way to know that, thanks!
[14:31] <dholbach> or check out http://people.canonical.com/~cjwatson/packagesets
[14:32] <Laney> hmm, that doesn't appear to show all sets
[14:32] <Laney> does have server though
[14:33] <RoAkSoAx> BlackZ: please before working on any package related to the HA team let me know!! :)
[14:33] <persia> Laney, I think that shows sets that are related to flavours, and so therefore more interesting for ogre-model, release-tracking, etc.
[14:34] <persia> RoAkSoAx, Careful: always good to offer support, but we don't have maintainers in Ubuntu, and don't block.
[14:34] <Laney> persia: OK, so I won't bother committing this to memory, and will remember the more general method instead.
[14:34] <RoAkSoAx> BlackZ: that is all the ha clustering related packages (DRBD, keepalived, RHCS, pacemaker, heartbeat, corosync, cluster-agents, cluster-glue, etc :))
[14:35] <RoAkSoAx> persia: That's why I'm saying he should le me know before working on them becuase I care for those packages and we are wroking on them as part of the Cluster Stack Blueprint
[14:36] <RoAkSoAx> persia: and I might not always want to merge/sync a package sometimes because I have changes to apply and so on...
[14:37] <persia> RoAkSoAx, I understand, and that's why I'm saying be careful.  If you want to maintain stuff in Ubuntu, you have to be quick enough that nobody else has any pending changes without your responses.  We frown strongly on anyone who blocks others work, even for packages they tend to upload.
[14:38] <persia> The one exception is that we discourage random folk from processing merges prior to DIF unless they touched it last *OR* really, really want it because it blocks other work.
[14:39] <RoAkSoAx> persia: indeed, and again that's why I recommended him to let me know before working on them so that if he does, we can work together :)
[14:39] <persia> And that's good :)  This is why I said "be careful" rather than "we don't do that", because I couldn't quite tell which way you meant it :)
[14:39] <RoAkSoAx> persia: :)
[14:40] <RoAkSoAx> persia: language barrier :)
[14:40] <BlackZ> RoAkSoAx: sure, will do
[14:41] <ion> roaksoax: a.k.a. IRC as usual :-)
[14:41] <persia> RoAkSoAx, Yeah, probably.  I just want to be careful, as we had some talks around "maintainers" and "ubuntu doesn't have maintainers" at UDS, and consensus appeared to be to push with not having maintainers harder (unless I missed something).
[14:43] <Laney> We are moving towards having smaller teams of people maintain certain packages though
[14:44] <persia> Laney, Um, sorta, for values of "maintain".  We strive to avoid any maintainer block, except in terms of reducing size of groups as we dig deeper in the ogre-model.
[14:46] <RoAkSoAx> persia: I wonder in what session I was during that talk.. :) And yes I do understand your point and that's how's always been (not having "pkg maintainers"), but in our particular case those packages are undergoing changes that are being worked out with upstream/Debian becuase of the MIR blockers, so we are currently working on them to get them in shape for Main
[14:47] <persia> Yeah, well, I'm still trying to stuff *every* package in main by fiat without any more MIRs, but it will take another couple cycles.
[14:47] <persia> Well, not *every* package, but at least all of universe.
[14:48] <RoAkSoAx> lol :)
[14:49] <cjwatson> persia: *cough* I think that's more "replace MIRs with some other review process"?
[14:49] <RoAkSoAx> we've been trying to get the cluster-stack into main the past 2 releases though :)
[14:51] <persia> cjwatson, No.  That said, we *will* need ways to indicate that various packages have undergone security review, code review, etc.  I don't think that will have anything to do with the presence/absence in the "main" component.
[14:57] <cjwatson> persia: I didn't say it would have anything to do with presence/absence in the main component.  But saying that MIRs go away is wrong - we need to have some kind of review process
[14:58] <cjwatson> I suspect that the two of us are agreeing, but I'm trying to make sure other people are not misled
[14:58] <persia> Oh, certainly.  I'm hoping you (and several others) will attend my spec on "package review types and reporting" at next UDS.
[14:58] <persia> And I think we do agree in general, although the specifics need more discussion.
[15:01] <cjwatson> feel free to subscribe me so I notice
[15:01] <pitti> persia: me as well, please
[15:01] <persia> Sure, although it will be another 4-5 months before I write it up.
[15:03] <ebroder> cyphermox__: thanks for the super quick review
[15:06] <cyphermox__> ebroder, np. if you have time to apply it to the other branch, then go ahead, otherwise I'll get around to it later ;)
[15:06] <ebroder> cyphermox__: i just submitted a new merge proposal. i'm not in any rush; just wanted this done by release :)
[15:07] <cyphermox__> ebroder, alright, thanks!
[15:19] <barry> hi folks, now that pysupport for python 2.7 has landed for natty, i need to get the python-cheetah package rebuilt.  2.4.3-0ubuntu1 is published but ftbfs because pysupport was out of date.  now that the latter is fixed, i think we just need a rebuild but i don't seem to be able to (or maybe know how) to request that from launchpad.  does an archive admin need to do that?
[15:20] <cjwatson> barry: no, any uploader
[15:20] <cjwatson> we don't have binary-only rebuilds in LP yet, so you have to bump the changelog and reupload
[15:20] <cjwatson> oh, wait
[15:20] <cjwatson> did it build to start wth?
[15:21] <cjwatson>    cheetah | 2.4.3-0ubuntu1 |         natty | source
[15:21] <cjwatson> python-cheetah | 2.0.1-2ubuntu7 |         natty | amd64, armel, i386, powerpc
[15:21] <barry> cjwatson: we sync'd 2.4.3 from debian but that build failed
[15:21] <cjwatson> looks like not
[15:21] <cjwatson> $ ubuntu-build --batch --retry cheetah
[15:21] <cjwatson> done
[15:21] <barry> cjwatson: it should build now that pysupport is updated (it builds in my chroot just fine now)
[15:22] <barry> cjwatson: awesome, thanks!
[15:22] <cjwatson> the script's in ubuntu-dev-tools and anyone with upload access can use that.  alternatively it's in the web UI for each build page, though that takes longer
[15:23] <barry> cjwatson: yep, that's why i can see the ui widget for my ppas but not (yet <wink>) for the cheetah page
[15:24] <persia> The conventional way for non-uploaders to request rebuilds for which no binaries exist is "Could someone please give-back foo on arch bar?", which almost always results in someone pressing the button within 10-15 minutes for me.
[15:27] <barry> persia: "give-back"?
[15:27] <persia> barry, Yeah.  Historical terminology from the Debian wanna-build infrastructure.
[15:27] <tumbleweed> barry: give back to the buildd
[15:27] <barry> ah, thanks
[15:28]  * barry thought it was something like "pay it forward" :)
[15:28] <tumbleweed> we really should have a glossary of debian terms somewhere
[15:31] <barry> tumbleweed: dholbach is working on that i think!
[15:32] <dholbach> errrrrrrrrrrr
[15:32] <dholbach> guys, I don't own the wiki :-P
[15:32] <dholbach> for now, there's https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/glossary?action=show&redirect=UbuntuDevelopment/Abbreviations :)
[15:34] <dholbach> barry, tumbleweed: for now, there's https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/glossary?action=show&redirect=UbuntuDevelopment/Abbreviations :)
[15:34] <dholbach> it should be linked form UbuntuDevelopment/KnowledgeBases afaik
[15:34] <dholbach> but yeah, there should be some better "introductory docs" at the end of this cycle
[15:34] <barry> dholbach: i was thinking about your documentation ideas at uds-n, specifically the idea (maybe only in my own head) about a reference manual and glossary
[15:36] <dholbach> the one I had in mind doesn't have the spec written yet, but it was the one about having introductory test/ presentation /etc. that in a way that's easy to understand at least mentions all the big topics and explain how they fit together plus a few nice diagrams
[15:36] <dholbach> it's not going to replace a glossary
[15:36]  * barry nods
[15:37] <dholbach> but we should make sure to get a few nice articles together for the other spec - I hope that'll make it easier to bring all the buzzwords in context :)
[16:32] <SpamapS> so, is there a reason some packages have Vcs-Bzr: renamed to Xs-Debian-Vcs-Bzr: ? is that an anachronism that can be removed?
[16:33] <ebroder> SpamapS: Vcs-Bzr: is canonical according to http://www.debian.org/doc/developers-reference/best-pkging-practices.html#bpp-vcs
[16:33] <Laney> SpamapS: Does this package have another Vcs-Bzr in place? There's sometimes Ubuntu branches.
[16:34] <soren> SpamapS: When I've done it, it's been intentional.
[16:34] <Laney> it would be nice if this were standardised so that tools can make use of it
[16:34] <soren> SpamapS: If a package isn't synced directly from Debian, claiming that its packaging is kept in the same vcs as Debian is a lie.
[16:35] <soren> SpamapS: So I change it to Xs-Debian-Vcs-Bzr.
[16:35] <soren> SpamapS: And put a new Vcs-Bzr header there if there's a better, Ubuntu-specific place for the packaging branch.
[16:39] <SpamapS> The package is merged from Debian
[16:40] <SpamapS> the package in question is cheetah btw
[16:40] <SpamapS> and the weird thing there is, basically all Ubuntu packages have a place where their uploaded versions live. Its only the WIP versions that are missing.. and according to somebody at UDS (forgetting who now) that can be resolved.
[16:50] <RoAkSoAx> pitti: howdy, when using pmutils, pm-powersave is there a tool that will list which scripts are enabled/disabled? No right?
[16:51] <mdeslaur> pitti: I seem to recall a discussion at a previous UDS where we talked about executable bit on windows files when mounting a cdrom...did that ever get done? Is bug 561479 the only one for that?
[16:52] <seb128> mdeslaur, https://launchpad.net/ubuntu/maverick/+source/udisks/1.0.1-2
[16:52] <seb128> we had this patch last cycle
[16:53] <seb128> but I guess it's a different issue now reading your bug
[16:53] <mdeslaur> seb128: oh, curious...it doesn't work for me
[16:53] <mdeslaur> seb128: oh, well, cdroms aren't vfat
[16:53] <mdeslaur> seb128: so it wouldn't be that patch
[16:54] <seb128> right
[17:10] <pitti> RoAkSoAx: how do you mean? They are all enabled
[17:11] <pitti> mdeslaur: exe bit? that got fixed for vfat
[17:12] <pitti> mdeslaur: not sure what happens with iso9660 these days
[17:12] <mdeslaur> pitti: yes, but unfortunately not for iso9660 cdroms
[17:12] <RoAkSoAx> pitti: for example, when we were discussing powernap scripts before UDS with kirkland, we decided that we needed to know which power saving scripts are enabled and which are disabled. So I created a tool to enable/disable and list all the scripts with its status. Now, I'd like to keep that functionality
[17:12] <mdeslaur> pitti: so people using wine can't install windows programs from cdrom
[17:13] <RoAkSoAx> pitti: however, since we are now gonna use pm-powersave for such purpose, I was just wondering :)
[17:13] <pitti> RoAkSoAx: in /etc/ you can rename the files
[17:13] <mdeslaur> pitti: on lucid and maverick, if the cdrom device is listed in fstab, it gets mounted with the executable bit everywhere. If it's not listed in fstab, it gets mounted with read permissions only.
[17:13] <pitti> RoAkSoAx: but /usr/lib/pm-utils/power.d/ will always run (unless these scripts have a way to disable themselves by reading a file in /etc)
[17:14] <ebroder> mdeslaur: maybe we need a showexec option for iso9660 that only takes effect if the cd doesn't use rock ridge?
[17:15] <pitti> mdeslaur: I see; seems iso9660 doesn't have a "showexec" equivalent :(
[17:15] <mdeslaur> ebroder: yeah, I think that would be the best approach
[17:15]  * pitti agrees
[17:15] <RoAkSoAx> pitti: yeah jsut saw the manpage. I guess that the best thing to do in this case would be to adapt the tool I wrote to work with those two directories.
[17:16]  * pitti lunch &
[17:16] <lifeless> kees: hey
[17:16] <lifeless> kees: so, was the token based thing faster ?
[17:17] <kees> lifeless: since I can't reproduce the 503s with bug attachments, I won't know until I can test against soyuz output
[17:17] <lifeless> kees: ah, its just big files right...
[17:17] <lifeless> I think it will be :)
[17:18] <kees> lifeless: I have faith :)
[17:55] <jdstrand> pitti: I just uploaded a new apparmor to maverick-proposed to fix that ftbfs and a missed patch. please see bug #660077
[17:55] <jdstrand> pitti: I am going through the lucid one next to answer all your questions, etc
[17:56] <pitti> kees: thanks for quick MIR review, appreciated
[17:56] <kees> pitti: np
[17:57] <jdstrand> pitti: I took the liberty of rejecting the lucid one, since it will need the same changes as the one I just uploaded to maverick
[17:57] <pitti> jdstrand: thanks for the heads-up
[17:58] <jdstrand> pitti: for clarity, I did not accept the maverick-proposed one, since I uploaded it
[18:04] <SpamapS> Has anyone attempted to make mk-sbuild use btrfs instead of lvm snapshotting? What better way is there to get heavy testing of btrfs than start doing all of our local test builds on btrfs?
[18:04] <ebroder> SpamapS: has sbuild grown btrfs support yet? last time i checked i thought it didn't have it yet
[18:04] <ebroder> (it already uses aufs by default now)
[18:09] <SpamapS> well I guess I meant sbuild. ;)
[18:09] <ebroder> err, actually, i think i mean schroot, not sbuild, but you know...
[18:10]  * ebroder goes and looks around
[18:11] <ebroder> aha. yeah, (experimental) btrfs support has been in schroot since 1.4.5-1. so mk-sbuild just needs to be changed to set the appropriate options in schroot.conf
[18:23] <SpamapS> ebroder: cool
[18:23]  * SpamapS adds a personal todo to try that out
[18:45] <kirkland> hallyn: okay, so qemu-kvm-0.13 built and is in natty;  any others waiting on sponsoring by me?  fwiw, I usually do [qemu-kvm, vgabios, seabios, etherboot] all at roughly the same time
[18:46] <kirkland> hallyn: and will help jdstrand with [libvirt] if necessary
[18:47] <hallyn> kirkland: i think jdstrand is ready for me to just take over libvirt :)
[18:47] <hallyn> kirkland: etherboot doesn't need an update.  you already did seabios i believe, and i'm not sure about vgabios (or vice versa on the last two)
[18:47] <jdstrand> I don't mind doing the apparmor bits, but it is difficult for me to maintain all the other bits
[18:47] <kirkland> hallyn: heh :-)
[18:47] <kirkland> hallyn: cool
[18:48] <hallyn> jdstrand: np, i'll do it as of natty?
[18:48] <hallyn> jdstrand: shall i put you down as reviewer for merge request?
[18:48] <kirkland> hallyn: well, for all of the bios packages [seabios, vgabios, etherboot], i only merge to fix bugs and stay in sync with qemu;  they are not exactly "feature driven" projects at this point
[18:48] <jdstrand> hallyn: that sounds excellent (if slightly surprising based on our last conversation)
[18:48] <kirkland> hallyn: so there's nothing wrong with holding steady there
[18:48] <jdstrand> hallyn: yes please
[18:49] <YokoZar> slangasek: Just FYI if I don't get multiarch by 11.04 I'm gonna add all the gstreamer codecs and their dependencies to ia32-libs
[18:49] <hallyn> jdstrand: cool, then let's do that
[18:49] <jdstrand> \o/
[18:49] <kirkland> hallyn: as for libvirt, I just try to make sure that we have roughly the same libvirt/qemu-kvm combination as Fedora, if possible;  tends to minimize the maintenance
[18:50] <hallyn> kirkland: uh, ...  so i shouldn't just take the lastest (0.8.5) release for natty you think?
[18:52] <jdstrand> hallyn: my vote is for 0.8.5 as early as possible, that way there won't be any surprises later in the release (especially since Debian is trying to get squeeze released)
[18:52] <kirkland> hallyn: well, yeah, it's probably good at this point to just take that as soon as possible
[18:52] <kirkland> hallyn: right, what jdstrand said
[18:52] <hallyn> ok
[18:53] <kirkland> hallyn: as it gets closer to FF and Beta, that's when, if possible, I try to make sure that we have something close to what Fedora has
[18:53] <hallyn> makes sense
[18:54] <kirkland> hallyn: and hopefull we'll get a few good qemu-kvm 0.13.x updates in the next 4-5 months too
[18:54] <kirkland> hallyn: those have been *really* good for the project, IMHO
[18:55] <hallyn> kirkland: well i guess i'll need to update a laptop to natty so i can actually test it
[18:55] <hallyn> suppose to do that i just tweak sources.list and do it by hand?
[18:55] <hallyn> (and pray)
[18:56] <kirkland> hallyn: or do-release-upgrade -d
[18:59] <hallyn> kirkland: not in THIS laptop tyvm  :)
[18:59] <hallyn> kirkland: thanks, i didn't think that would work  yet, will do
[19:00]  * stgraber upgraded his x201s yesterday. It actually seems to work better since then ;)
[19:00] <hallyn> hm, maybe nouveau will be more stable :)
[19:00] <stgraber> 2.6.36 helped for a few stuff
[19:01] <stgraber> like I can get X applications working in a LXC container as containers can now access unix sockets if the container has access to the file system
[19:04] <hallyn> stgraber: hm, i can't think what kernel patch that would have ben
[19:06] <stgraber> hallyn: http://marc.info/?l=linux-netdev&m=127132268217222&w=2 ?
[19:06] <stgraber> hallyn: not sure that's the one but it seems to match the description dlezcano gave me at uds
[19:07] <bilalakhtar> Wierd, package liboauth has cleared the Ubuntu NEW queue by the autosyncer but another copy of it is still in the queue!
[19:08] <hallyn> stgraber: oh, cool.   more corner cases
[19:08] <bilalakhtar> Can someone delete the queue copy? I uploaded it myself a few hours ago, didnt know the autosyncer would run today itself
[19:29] <pitti> bilalakhtar: which queue copy? natty isn't frozen
[19:29] <pitti> unless it was a pakcage in main?
[19:29] <bilalakhtar> pitti: NEW queue
[19:29] <pitti> sorry, s/main/new/
[19:31] <pitti> bilalakhtar: why would I remove the binaries? I should accept them..
[19:31] <pitti> oh, sourc
[19:31] <bilalakhtar> pitti: I mean the source
[19:31] <pitti> done
[19:31] <bilalakhtar> thanks pitti
[19:33] <mgunes> f
[20:18] <geser> cjwatson: re gparted: should I ask someone else for sponsoring both bugs? (both bugs are also in the sponsoring queue)
[21:02] <hallyn> jdstrand: hey, now i can't recall what soren (was it soren?) was admonishing you for - does he want the quitl patches APPLIED or NOT APPLIED in the bzr tree?
[21:02] <persia> both are accepted models: check the status of other patches in the package.
[21:02] <jdstrand> hallyn: 09:11 < soren> jdstrand: The quilt source packages are special. When I add a  patch, I need to add it both to debian/patches /and/ apply it to  the source tree.
[21:03] <jdstrand> hallyn: ie, 'quilt push -a ; bzr add' before committing
[21:03] <hallyn> thanks
[21:04] <pitti> dpkg-buildpackage usually applies them for you if you build the source
[21:04] <hallyn> jdstrand: one more q - do you have a process all figured out for how you set up the gnulib/ directory?
[21:04] <hallyn> or do you do it ad-hoc?
[21:06] <jdstrand> hallyn: I would hope that upstream already did that in their upstream tarball. did they not?
[21:06] <hallyn> oh.  i was going to take from git :)
[21:06] <jdstrand> 0.8.5 is released. I recommend that
[21:06] <hallyn> yes,
[21:07] <hallyn> i was doing 'git reset --hard' to that commit-id :)
[21:07] <hallyn> so you do a 'uscan' and then copy that back into the bzr tree?
[21:08] <jdstrand> hallyn: well, I haven't done a source merge since soren requested we use this method
[21:09] <jdstrand> hallyn: there are prbably better ways to do it, but I personally would delete everything out of the directory except .bzr*, then untar into it. then 'bzr add'
[21:09] <hallyn> all right, will do.
[21:09] <hallyn> jdstrand: thanks
[21:09] <jdstrand> that will definitely get you the upstream source
[21:09] <jdstrand> hallyn: sure thing
[21:09] <persia> Isn't there a merge-upstream function to bzr-buildpackage that is intended to handle this case?
[21:10] <persia> (and it might even do the right thing WRT patch application, or need a bug filed)
[21:11] <hallyn> persia: well, i don't know, but i already know there are lots of patches in debian/patches which will no longer apply, so somethign more manual will be less painful anyway
[21:11] <hallyn> i though, i see the help page...
[21:11] <persia> If you're going to be using bzr, I'll recommend using bzr-buildpackage, as I know a few folks have put a lot of effort into trying to make it just work.
[21:12] <hallyn> persia: yeah, i do use bzr bd
[21:12] <hallyn> persia: hm, sure, i'll try bzr mu - might be nice
[21:13] <persia> You probably still have to semi-manually reconcile/merge the patches (although `bzr patch` can help) but you may not have to deal with completely raw integration.
[21:14] <hallyn> persia: doh!  bzr: ERROR: Unknown target distribution: natty
[21:14] <hallyn> tsk tsk :)
[21:14]  * hallyn will fix that up by hand later i guess
[21:14] <persia> heh.  That needs a bug :)
[21:15] <jelmer> hallyn, persia: There is a bug fix for that in bzr-builddeb trunk.
[21:15] <hallyn> jelmer: ah, ok, thx
[21:15] <jelmer> I believe there were also folks looking at backporting it to maverick, but I'm not sure what the status of that is.
[21:16] <persia> jelmer, What is usually done with other tools is to update it just before release.  Question being whether it's intended for Ubuntu Developers or for folk wishing to work with the packages they have installed.
[22:01] <cjwatson> geser: no, it's OK, I'll take care of them
[22:14] <emgent> hello
[22:15] <emgent> jdstrand: ping ?
[22:17] <emgent> pitti: around ?
[22:17]  * persia notes that asking for functions instead of people is frequently more powerful
[22:18] <emgent> lol, heya persia! how goes?
[22:18] <persia> Fairly well, although UDS leaves me tired.  For you?
[22:19] <emgent> really fine, checking someone from secteam for talk about proftpd 0day security issue.
[22:19] <persia> Nobody is in -hardened today?
[22:19] <emgent> seems that idle win today
[22:20] <emgent> have you saw http://bugs.proftpd.org/show_bug.cgi?id=3521 ?
[22:20] <emgent> tring to exploit it, but seems up a stack protection.
[22:20] <emgent> the issue was found for sure via code review
[22:24] <persia> Probably worth pushing a patch to ubuntu-security-sponsors and keeping chasing folk on -hardened.
[22:24] <persia> Most 0-day stuff doesn't hit the embargoed queue, so less likely to be duplicate effort.
[22:24] <emgent> for now seems that patch is not needed, i'm hardly testing the stuff but seems up a stack protection
[22:24] <jdstrand> emgent: well, you only asked for kees in #ubuntu-hardened
[22:25] <emgent> heya jdstrand, nice to see you
[22:25] <jdstrand> emgent: anyhoo, hi! if you have a patch, please submit following https://wiki.ubuntu.com/SecurityTeam/UpdateProcedures#Preparing%20an%20update
[22:25] <jdstrand> emgent: you too
[22:25] <emgent> jdstrand: have you some min for talk about it? maybe we can move in -hardened
[22:25] <jdstrand> k
[22:25] <emgent> thanks
[22:34] <ari-tczew> can we remove packages from archive, if there is only one binary - sparc ?
[22:35] <persia> ari-tczew, That's not a good reason, but we can remove stuff.  Which package?
[22:36] <ari-tczew> persia: xserver-xorg-video-sunleo
[22:36] <cjwatson> I've generally not found it worth the effort to do so
[22:37] <cjwatson> it's easier to just sync all those source packages and have them do nothing, rather than go to the effort of maintaining entries in the sync-blacklist for everything that generates only binaries for architectures not in Ubuntu
[22:37] <persia> We could remove that (use "Unbuildable in Ubuntu" as the reason, and blacklist), but yeah, I don't see the point.
[22:37] <cjwatson> (and keep track of when source packages add new architectures and remove them from the blacklist, and ...)
[23:05] <RoAkSoAx> slangasek: howdy... by any chance do you have a bit of time to review couple of debdiffs for library split in cluster-glue and pacemaker?


[23:53] <tgm4883> The contract has been fulfilled  http://www.mashos.com/2015/09/to-victor-go-spoils.html


[07:10] <smb> morning .+
[07:12] <abogani> morning
[07:33] <jk-> hey smb, abogani.
[07:33] <smb> jk-, dude! :)
[07:33] <jk-> dhuuuuude
[07:34] <smb> White Russian?
[07:34] <_ruben> jk-: thanks for the tip on posting my ataX -> sdY issue on askubuntu.com .. it got a decent looking response, havent had a chance to verify it yet tho ;)
[07:35] <jk-> _ruben: oh, no problem. Sorry I couldn't help directly.
[07:35] <jk-> _ruben: got a URL?
[07:35] <apw> bug #818177
[07:35] <ubot2> Launchpad bug 818177 in udev "boot failures caused by udev race" [High,Confirmed] https://launchpad.net/bugs/818177
[07:36] <_ruben> jk-: http://askubuntu.com/questions/64351/how-to-match-ata4-00-to-the-apropriate-dev-sdx-or-actual-physical-disk
[07:36] <jk-> _ruben: thanks
[07:37] <jk-> looks sensible
[07:38] <_ruben> indeed
[10:46] <apw> cyphermox, ogasawara, isn't there a fix in the batch on stable 3.0.6 something to do with failing to load builtin firmware on resume an ordering issue
[11:41] <bullgard4> What is the function of the process »netns«? http://lxr.linux.no/#linux+v<IP_ADDRESS>/Documentation/ :Filename search: netns did not enlighten me.
[12:19] <smb> bullgard4, I think that is related to cleaning up network namespaces. Since that is time consuming it is done by a helper in batches.
[12:19] <brendand> sconklin, bjf - is there a tag i can rely on to find bugs that were regressions caused by -proposed kernels?
[12:23] <bullgard4> smb: Thank you very much for explaining.
[12:24] <smb> bullgard4, glad if it helps
[12:24] <bullgard4> Yes, it does.
[12:32] <herton> brendand: regressions in -proposed should be tagged as regression-proposed, not sure everything is being tagged correctly though
[12:38] <brendand> herton - yeah, i got some though now. thanks
[13:18] <smoser> is anyone able to tell me i'm a complete moron, and this is not possible https://bugs.launchpad.net/ubuntu/+source/linux/+bug/845864
[13:18] <ubot2> Launchpad bug 845864 in linux "painfully slow recharge time" [Undecided,Confirmed]
[13:18] <smoser> or at least that it could not be kernel related.
[13:19] <smoser> i would not have thought it could be, but I utlemming and both noticed this on our laptops during oneiric.
[13:22] <tgardner> smoser, perhaps its a good question for cking
[13:24] <smoser> if someone else had not started seeing the same thing, i would hvae thought that my battery was just beginning to fail.
[13:24] <tgardner> smoser, I wonder what role the EC has in charging your battery?
[13:25] <smoser> EC ?
[13:25]  * cking looks at the bug
[13:25] <tgardner> smoser, its an embedded controller that does a lot of stuff behind the scenes.
[13:27] <cking> I'd suggest recharging it when the machine is off and seeing what happens - if it still charges slowly it's a battery problem
[13:29] <cking> otherwise, if it's running and slowly charges I expect some process or kernel power management feature is sucking power causing the recharge to take forever
[13:29] <tgardner> cking, that would explain the differences between kernel versions
[13:30] <smoser> cking, well, 'top' doesn't show anything, and the system does not otherwise appear heavily loaded at all.
[13:30] <cking> the other option is to boot with an older kernel and use the oneiric user space to factor out if it's a kernel issue or not
[13:30] <smoser> yeah.
[13:30] <smoser> cking, thanks.
[13:31] <cking> but first I'd see how long it takes to charge when not running - that's an easy test and will show you if it's H/W related
[13:31] <smoser> well, yeah, except turning it off means i can't use it for work.
[13:31] <smoser> but it is a nice day here, and golf could fill that time :)
[13:31] <cking> :-)
[13:32] <cking> see how it charges at the end of the working day ;-)
[13:34] <cking> smoser, the data from /proc/acpi/battery/ comes from the ACPI _BST, _BIX and _BIF methods and these basically read the battery status via the EC, so I doubt that this is broken
[13:35] <cking> ..it's fairly straight forward code in the kernel. The only explanation is the either something is chewing up the power or the EC is doing the wrong thing
[13:35] <cking> ..or the battery is not happy
[13:37] <smoser> cking, yeah. i would have assumed bad battery. but utlemming complained about this to me right after he upgraded to oneiric without me leading him at all.
[13:37] <smoser> but, i'll check when power off and such.
[13:37] <smoser> thanks for your  help.
[13:54] <cking> hrm, gitweb is sucky and slow today on zinc
[13:55] <cking> swapping like crazy
[13:56] <tgardner> cking, yeah, zinc is kinda under powered for some things
[13:57] <cking> well, it's all blocked in I/O and swapping like mad, so more memory would be handy for it
[13:58] <tgardner> cking, indeed
[14:10]  * ogasawara back in 20
[14:52] <bjf> brendand: no, at this time there really isn't
[15:02] <ogasawara> apw, smb: have either of you tried installing this linux-image-extra virtual package?
[15:02] <apw> not since you integrated it, no, whats up
[15:02] <smb> ogasawara, Not yet
[15:02] <ogasawara> seems to have dependency issues
[15:02] <smb> ogasawara, But it should be a relative quick exercise to try
[15:03] <apw> ogasawara, what happens
[15:03] <apw> luckily its an opt in package, so even if its bust it can wait till the first SRU upload
[15:03] <ogasawara> $ sudo apt-get install linux-image-extra-3.0.0-12-virtual
[15:03] <ogasawara> Reading package lists... Done
[15:03] <ogasawara> Building dependency tree
[15:03] <ogasawara> Reading state information... Done
[15:03] <ogasawara> Some packages could not be installed. This may mean that you have
[15:03] <ogasawara> requested an impossible situation or if you are using the unstable
[15:03] <ogasawara> distribution that some required packages have not yet been created
[15:03] <ogasawara> or been moved out of Incoming.
[15:03] <ogasawara> The following information may help to resolve the situation:
[15:03] <ogasawara> The following packages have unmet dependencies:
[15:03] <ogasawara>  linux-image-extra-3.0.0-12-virtual : Depends: linux-image-3.0.0-12-virtual (= 3.0.0) but 3.0.0-12.19 is to be installed
[15:04] <ogasawara> em: Unable to correct problems, you have held broken packages.
[15:04] <ogasawara> only discovered it cuz I was trying to test out a meta package for it
[15:04] <smb> Hm, linux-image shoudl exist...
[15:05] <apw> ogasawara, i am unsure how that didn't happen to me, but it looks plain wrong
[15:05] <apw> it should be the other version in teh control.in
[15:06] <apw> ogasawara, you gonna look at it or should i
[15:06] <ogasawara> apw: I can investigate
[15:06] <smb> ogasawara, ok get the same here
[15:07] <apw> i think its a single line change to control.stub.in or stub.d/virtual
[15:07] <ogasawara> apw: am also gonna send out a patch for an -extra's meta package
[15:07] <apw> to switch the version number round
[15:09] <smb> apw, So to get the -12.19 added?
[15:09] <apw> yeah, it must mention the wrong version variable there
[15:11] <smb> probably adding ABINUM helps
[15:11] <smb> hm no
[15:11] <smb> would only be 12...
[15:11] <ogasawara> it looks right to me
[15:11] <ogasawara> I'm missing something
[15:11] <apw> there is a proper
[15:12] <apw> there is a proper longer version number isn't there?
[15:12] <ogasawara> apw: must be, now to find the variable name for it
[15:13] <herton> bjf: well, https://wiki.ubuntu.com/Kernel/BugFocus bugs says regressions in -proposed should be tagged as regression-proposed
[15:13] <herton> (refering to brendand's question)
[15:18] <apw> ogasawara, doesn't look like we have the specific version as a variable, only PKGVER and ABINUM
[15:18] <apw> ogasawara, the headers depedancy is just to the unversions package name, we could do the same i suspect and be fine
[15:19] <apw> Depends: ${misc:Depends}, coreutils | fileutils (>= 4.0), SRCPKGNAME-headers-PKGVER-ABINUM, ${shlibs:Depends}
[15:19] <ogasawara> apw: ack, I'll try that and test
[15:19] <smb> apw, Its likely new that you need to be in lockstep with a specific kernel version...
[15:19] <apw> smb, likely though its officially abi compliant, so it shouldn't matter in theory
[15:20] <bjf> herton: that may be, but who has been doing the tagging?
[15:20] <smb> apw, Probably loadable. Though it may have strange behaviour as they are really tightly coupled
[15:20] <smb> apw, On the other hand every build will produce both anyway
[15:23] <herton> bjf: no one that I know, that's why I told probably not everything is tagged correctly. I guess we should be doing it when we identify a regression
[15:24] <apw> ogasawara, it wouldn't be hard to add a variable too
[15:25] <bjf> herton, and that's why i replied that at this time there isn't one, no one is applying it
[15:26] <herton> bjf: shouldn't we be applying it anyway?
[15:28]  * smb detects major water damage...
[15:28] <smb> -> security shutdown
[15:28] <apw> smb !?!
[15:29]  * ogasawara guesses a split beer
[15:29] <apw> heh
[15:29] <tgardner> where one half is split onto his keyboard
[15:33] <brendand> bjf, herton - does regression-proposed get added by apport if a user is running the -proposed kernel?
[15:35] <bjf> brendand: i don't think so, http://people.canonical.com/~kernel/reports/regressions-proposed-report.html shows bugs marked regression-proposed
[15:35] <bjf> brendand: there just aren't enough on that list for it to be accurate
[15:36] <brendand> bjf - true, there's only 39 there last time i checked
[15:44] <apw> ok not beer, but an actual waterfall coming through his fuse box!!!  so i think smb will be away for some time
[15:44] <apw> ogasawara, tgardner ^^
[15:45] <ogasawara> whoa, that's not good
[15:45] <brendand> bjf - btw, we have a session at UDS about improving coverage of certification testing for SRUs. Your feedback is welcome : https://blueprints.launchpad.net/certify-planning/+spec/hardware-p-cert-sru-coverage
[15:46] <brendand> sconklin too ^
[15:46] <tgardner> apw, did local construction efforts redirect a local river into his house ?
[15:46] <brendand> bjf - i got your feedback on the wiki page
[15:47] <sconklin> brendand, thanks, subscribed
[15:49] <bjf> brendand: subscribed
[15:49] <brendand> sconklin, bjf - do you guys have some time for a brainstorm about where our efforts might be best focused?
[15:50] <brendand> sconklin, bjf - we're already sort of set on improving wireless, video and audio coverage so we'd be focusing on identifying use-cases within those areas
[15:50] <bjf> brendand: the three areas users have the most issues with: wireless, audio, graphics
[15:51] <brendand> bjf - agreed then
[15:51] <sconklin> +1
[15:52] <bjf> brendand: you should be working with QA, they should be hitting the same areas, i'd expect the two teams to be able to share tests, they may be focused on depth while your focus is breadth
[15:53] <brendand> bjf - yes, fewer tests but on a broader variety of hardware
[15:54] <brendand> sconklin, bjf - are you guys ok with taking some time tomorrow afternoon to discuss this then? we'll engage with QA, but also looking for your input
[15:55] <bjf> brendand: i'm pretty much always available to talk about testing the kernel
[15:56] <bjf> brendand: are you thinking mumble, irc or email ?
[15:56] <bjf> brendand: i personally like a "paper" trail
[15:57] <sconklin> what he said
[15:57] <brendand> bjf - i'd go for IRC
[15:59] <sconklin> brendand, how about in the #ubuntu-kernel channel
[16:00] <brendand> sconklin - no reason not to keep it public
[16:01] <brendand> bjf, sconklin - i'll schedule something tomorrow just to make sure everyone's in the same place at the same time (there are other folks from my team interested in participating)
[16:01] <bjf> brendand: sounds good, should be able to pop in here and start anytime, unless there's some hot discussion raging :-)
[16:02] <sconklin> sounds great, looking forward to it.
[18:01]  * tgardner -> lunch
[19:48]  * jjohansen -> lunch
[20:20] <ogasawara> GrueMaster: Do you care if I just close bug 758486 rather than leaving it in Incomplete.  You can always re-open it should it re-appear.
[20:20] <ubot2> Launchpad bug 758486 in linux-ti-omap4 "omapdss DISPC error on Panda platform" [Medium,Confirmed] https://launchpad.net/bugs/758486
[20:24] <ogasawara> GrueMaster: eh, I've closed it and posted it a comment.
[21:21] <GrueMaster> ogasawara: Works for me.
[21:54] <Linkmaster> I had a kernel panic using both ubuntu and kubuntu 11.04amd64-bit on an x120e thinkpad machine. it froze, so I'm going to have to power it off, but I want to know if you can derive anything useful before I do so