[00:47] <acheronuk> jbicha: seems field3d and pink-pony still depend on libilmbase12
[01:00] <tsimonq2> pink-pony lol
[01:17] <acheronuk> pink-pony: 3D racing game with ponies
[01:18] <acheronuk> always more weird stuff to find in the archive I never knew about!#
[01:24] <sarnold> watch out bzflag looks like there's a new linux game
[02:23] -queuebot:#ubuntu-release- New: accepted qgis [amd64] (cosmic-proposed) [2.18.20+dfsg-1]
[02:23] -queuebot:#ubuntu-release- New: accepted qgis [armhf] (cosmic-proposed) [2.18.20+dfsg-1]
[02:23] -queuebot:#ubuntu-release- New: accepted qgis [ppc64el] (cosmic-proposed) [2.18.20+dfsg-1]
[02:23] -queuebot:#ubuntu-release- New: accepted spirv-headers [amd64] (cosmic-proposed) [1.3-1]
[02:23] -queuebot:#ubuntu-release- New: accepted qgis [arm64] (cosmic-proposed) [2.18.20+dfsg-1]
[02:23] -queuebot:#ubuntu-release- New: accepted qgis [s390x] (cosmic-proposed) [2.18.20+dfsg-1]
[02:23] -queuebot:#ubuntu-release- New: accepted qgis [i386] (cosmic-proposed) [2.18.20+dfsg-1]
[03:19] -queuebot:#ubuntu-release- Unapproved: plasma-discover (bionic-proposed/universe) [5.12.5-0ubuntu0.1 => <IP_ADDRESS>-0ubuntu0.1] (kubuntu)
[08:48] <LocutusOfBorg> ginggs, stuff retried, I'm doing gdal rebuilds too, because vtk is entangled
[08:51] <ginggs> LocutusOfBorg: ok
[10:43] -queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (bionic-proposed/main) [4.15.0-1013.13] (kernel)
[10:52] -queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (bionic-proposed) [4.15.0-1013.13]
[11:43] -queuebot:#ubuntu-release- Unapproved: gnome-calendar (bionic-proposed/main) [3.28.1-1ubuntu2 => 3.28.2-0ubuntu<IP_ADDRESS>] (desktop-extra, ubuntu-desktop)
[12:14] -queuebot:#ubuntu-release- Unapproved: opencryptoki (bionic-proposed/universe) [3.9.0+dfsg-0ubuntu1 => 3.9.0+dfsg-0ubuntu1.1] (no packageset)
[12:17] -queuebot:#ubuntu-release- Unapproved: opencryptoki (artful-proposed/universe) [3.7.0+dfsg-4 => 3.7.0+dfsg-4ubuntu1] (no packageset)
[12:43] <teward> apw: ack, I will just disregard it since it shows as 'valid candidate' now.  Just have to wait on Perl heh
[12:49] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (trusty-proposed/main) [3.13.0-150.200] (core, kernel)
[13:22] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (trusty-proposed) [3.13.0-150.200]
[13:22] <acheronuk> bdmurray sil2100 - can you please continue phasing of ksysguard and plasma-workspace in bionic updates? considering the previous error report history for both, I can see no causal relationship between them and the latest update
[13:23] <acheronuk> plasma-discover has a fix in the unapproved queue
[13:37] <rbalint> doko, i prepared a merge for procps which involves a small transition (4 rdeps) that's going on in Debian already, should i coordinate about the upload and no change rebuilds or i can go ahead in the next days with it?
[13:38] <doko> just go ahead, I don't think that you need any kind of approval for that
[13:38] <rbalint> doko, i just don't want to mess up other transitions, thanks
[13:43] -queuebot:#ubuntu-release- New binary: rustc [s390x] (cosmic-proposed/universe) [1.26.0+dfsg0+llvm-0ubuntu2] (no packageset)
[14:09] -queuebot:#ubuntu-release- Unapproved: bolt (bionic-proposed/main) [0.2-0ubuntu1 => 0.3-0ubuntu0.1] (ubuntu-desktop)
[14:25] -queuebot:#ubuntu-release- Unapproved: gnome-control-center (bionic-proposed/main) [1:3.28.1-0ubuntu1 => 1:3.28.1-0ubuntu<IP_ADDRESS>] (ubuntu-desktop)
[14:27] -queuebot:#ubuntu-release- New binary: rustc [ppc64el] (cosmic-proposed/universe) [1.26.0+dfsg0+llvm-0ubuntu2] (no packageset)
[14:55] <bdmurray> acheronuk: looking
[14:57] -queuebot:#ubuntu-release- New binary: rustc [i386] (cosmic-proposed/universe) [1.26.0+dfsg0+llvm-0ubuntu2] (no packageset)
[15:01] -queuebot:#ubuntu-release- Unapproved: accepted plasma-discover [source] (bionic-proposed) [<IP_ADDRESS>-0ubuntu0.1]
[15:04] <cascardo> https://bugs.launchpad.net/ubuntu/cosmic/+source/nbd/+bug/1772024
[15:05] <cascardo> can anyone review/sponsor my debdiff for nbd? target is cosmic
[15:06] <bdmurray> Did you try ubuntu-devel? There should be more developers there.
[15:07] <cascardo> will try that, thanks
[17:23] -queuebot:#ubuntu-release- New binary: rustc [armhf] (cosmic-proposed/universe) [1.26.0+dfsg0+llvm-0ubuntu2] (no packageset)
[17:29] -queuebot:#ubuntu-release- New binary: rustc [arm64] (cosmic-proposed/universe) [1.26.0+dfsg0+llvm-0ubuntu2] (no packageset)
[21:29] -queuebot:#ubuntu-release- Unapproved: wireless-regdb (xenial-proposed/main) [2015.07.20-1ubuntu1 => 2018.05.09-0ubuntu1~16.04.1] (core)
[21:30] -queuebot:#ubuntu-release- Unapproved: wireless-regdb (bionic-proposed/main) [2016.06.10-0ubuntu1 => 2018.05.09-0ubuntu1~18.04.1] (core)


[02:24] <niberius> hola, como  me reconoce mi presonus firebox firiwire
[02:24] <holstein> !es
[02:24] <holstein> niberius: i have a firepod
[02:24] <holstein> niberius: try starting jack as root, temporarily to test
[02:24] <holstein> gksudo qjackctl
[02:25] <holstein> open "setup" and make sure you have the firewire driver
[02:25] <holstein> press "start" and see if it starts and share error messages at ..
[02:25] <holstein> !paste
[02:25] <holstein> if it starts as root, try as normal user
[02:26] <holstein> if it starts as normal user, enjoy.. if not, try adding your user to the audio group
[02:27] <holstein> sudo adduser 'username' audio
[02:27] <holstein> ^ this wont hurt to run, just as a test..
[02:27] <holstein> !proaudio
[02:28] <niberius> ok
[05:07] <Guest99606> hola
[07:28] <rock_star14> Hey there im new here, I am curious if studio hardware such as digidesign 002 & 003 and focusrite octopre ADAT racks are compatible with this OS and DAWS that are available on this OS cheers
[07:28] <rock_star14> like has anyone tried hardware such as these on ubuntu studio?
[14:43] <IotaSpencer> how do I stop the buzzing after pulseaudio and jack start fighting each other
[14:47] <IotaSpencer> hello?
[15:16] <IotaSpencer> alright, what happens is, I install ubuntu studio, i install the updates from apt-get upgrade for the first time, then after that restart, I get buzzing when system sounds come on, including skype, and any sound that comes through is garbled
[15:17] <IotaSpencer> without the updates its fine, once I get the updates it shits the bed
[15:25] <holstein> !language | IotaSpencer
[15:25] <holstein> IotaSpencer: will you try using the older kernel? and test?
[15:26] <holstein> IotaSpencer: if you are not using jack, then its *not* jack and pulse audio "Fighting each other"
[15:27] <IotaSpencer> well, I have jack and pulse audio installed
[15:27] <IotaSpencer> and it only happened after pulse was installed
[15:27] <IotaSpencer> and how do you try an older kernel ._.
[15:27] <IotaSpencer> I've always updated kernels, not downgraded
[15:28] <holstein> IotaSpencer: pulse was installed by default
[15:28] <holstein> IotaSpencer: so, pulse installation did *not* trigger this
[15:29] <IotaSpencer> Then what did
[15:29] <holstein> IotaSpencer: you stated you updated.. so, im suggesting test with the older kernel first, and see if its the kernel update
[15:30] <IotaSpencer> alright, then how do I choose an older kernel
[15:31] <holstein> IotaSpencer: at boot, from grub
[15:32] <holstein> IotaSpencer: if grub is hidden, you can use shift at boot.. you'll see your currect kernel and previous kernels.. go into the previous menu, and see if there are any older kernels
[15:32] <holstein> IotaSpencer: please dont spend much time looking for them, or waste more than about 8 minutes trying to do this
[15:32] <holstein> IotaSpencer: this is *not* a fix, but a troubleshooting step..
[15:33] <IotaSpencer> well, rebooting now
[15:33] <holstein> IotaSpencer: i do not konw if you have older kernels, nor if this is the issue. its just something that can cause the issue you state, if, indeed,  everything was OK prior to updating
[15:42] <IotaSpencer> kernels aren't the issue
[15:42] <holstein> IotaSpencer: if i may, please tell me how you determined that..
[15:42] <IotaSpencer> tried both that I had and neither fixed the problem
[15:42] <holstein> IotaSpencer: sure. what exactly is the problem?
[15:43] <IotaSpencer> >_<
[15:43] <holstein> IotaSpencer: please tell me exactly the issue
[15:43] <holstein> IotaSpencer: do you even start JACK? no? correct?
[15:43] <IotaSpencer> that systems sounds buzz + skype sounds are garbled
[15:43] <holstein> IotaSpencer:  you just boot the system, and hear buzz?
[15:43] <holstein> IotaSpencer: sure.. but, you are not using JACK, correct?
[15:43] <IotaSpencer> the bloop on skype turns into a buzz
[15:43] <holstein> you never start jack? and you never added any PPA's?
[15:44] <IotaSpencer> only ppa i have is weechat
[15:44] <holstein> IotaSpencer: and, you never start jack, correct?
[15:44] <IotaSpencer> i thought it started itself
[15:44] <holstein> IotaSpencer: no
[15:44] <holstein> IotaSpencer: jack is not something that when installed, is running
[15:45] <holstein> IotaSpencer: so, you are not using jack, correct?
[15:45] <IotaSpencer> alright then how do i start it to see if it helps it
[15:45] <IotaSpencer> jack is installed
[15:45] <holstein> IotaSpencer: no.. jack wont "help" this
[15:45] <IotaSpencer> >_<
[15:45] <holstein> IotaSpencer: jack is not for casual audio like that
[15:45] <holstein> IotaSpencer: its a professional audio sound server.. meant to do advanced routing, and provide lower latency
[15:46] <holstein> IotaSpencer: please do *not* throw a new issue into the mix at this point. i am only collecting facts and details
[15:46] <IotaSpencer> alright then what other facts do you need
[15:46] <holstein> IotaSpencer: please confirm you are not using JACK by running "ps aux | grep jack" in a terminal.. you can use a pastebin
[15:47] <IotaSpencer> the grep is all that shows up
[15:47] <holstein> while in the terminal run "aplay -l" and "arecord -l" and share those via pastebin
[15:47] <holstein> IotaSpencer: so, jack is not running.. and is not able to be causing the issue here
[15:48] <holstein> IotaSpencer: there is no fight between pulse and jack going on.. jack is out of the equation.. for future reference
[15:55] <IotaSpencer> http://paste.ubuntu.com/7387417/
[15:56] <IotaSpencer> @ holstein
[16:04]  * IotaSpencer waits
[16:04] <holstein> IotaSpencer: ok.. if it were me, i would pull up the live CD again, and test that no issues have occured that have caused my hardware to break
[16:04] <IotaSpencer> o
[16:04] <holstein> IotaSpencer: then, i would look into (while the live CD is up) what version of alsa is there,.. and step my installed version back down to that version if its not the same
[16:05] <holstein> i would then run pavucontrol and alsamixer and tweak *everything* not trusting the lables
[16:05] <holstein> labels*
[16:15] <Iota[web]> ok and how do I check which version of alsa each uses?
[16:16] <holstein> Iota[web]: i use a package manger.. i like synaptic as a GUI
[16:23] <Iota[web]> hmm
[16:24] <Iota[web]> Alright the one installed to the live usb is the same as the one in the repo
[16:30] <holstein> Iota[web]: ok.. so, its not alsa, nor the kernel, it seems
[16:30] <holstein> Iota[web]: what else is there? your user config? you can try the guest account and test audio
[16:31] <holstein> test known-good simple audio files.. not 3rd party applications like skype
[16:31] <Iota[web]> so like any of my music you mean?
[16:32] <holstein> Iota[web]: no.. i mean specifically what i said.. a known-good simple audio file.. a well supported oog file that you know plays
[16:32] <Iota[web]> well I don't
[16:32] <Iota[web]> lol
[16:32] <holstein> not sykpe, or a downloaded mp3 that requires a codec
[16:32] <Iota[web]> I don't have any oogs
[16:32] <holstein> something you *know* plays, and is supported, and doesnt require anything outside the repos
[16:33] <Iota[web]> I don't know what is supported and whats not
[16:33] <holstein> Iota[web]: there should be many sounds included in the system, but, again, dont overthink this.. its a troubleshooting step, not a fix
[16:33] <holstein> Iota[web]: ogg is open and supported by default, which is why i use, and suggest it for testing purposes
[16:34] <Iota[web]> alright, and where would I find the sounds, because I've never actually looked for sounds other than the mp3's I listen to
[16:34] <holstein> Iota[web]: i would use one that i konw works.. use what works on the live CD without issue
[16:34] <holstein> Iota[web]: anything you have that you know works well, in the default player
[16:34] <Iota[web]> =_=
[16:35] <holstein> Iota[web]: i dont understand what that is
[16:35] <Iota[web]> I don't have anything readily accessible except for mp3s
[16:35] <holstein> Iota[web]: then, use them, friend.. just keep in mind, you are assuming mp3 support is not the issue
[16:35] <holstein> Iota[web]: so, if you like, somewhere down the line, remove mp3 support from this test equation
[16:36] <holstein> Iota[web]: test audio as the guest user.. is it broken as the guest user as well?
[16:36] <Iota[web]> i'm on the live usb user
[16:37] <Iota[web]> 'Live session user'
[16:37] <holstein> Iota[web]: ok
[16:37] <Iota[web]> everything works
[16:37] <Iota[web]> no ifs ans or butts
[16:37] <holstein> Iota[web]: then, test an audio file, keep that audio file in mind. and reboot your "broken" system, and test the *exact* *same* *file* the *exact* *same* way* in the guest user account
[16:40] <Iota[web]> alright the music file works, now to switch to the computer part and try
[16:46] <Iota[web]> ok, mp3 plays fine both places
[16:46] <holstein> Iota[web]: as guest user?
[16:46] <Iota[web]> yep
[16:46] <Iota[web]> 'Guest' is my user
[16:47] <holstein> Iota[web]: ok.. so try again as your normal user, the *same* file the same way
[16:47] <Iota[web]> ok
[16:48] <IotaSpencer> file could not be opened wut
[16:49] <holstein> IotaSpencer: im not following..
[16:49] <IotaSpencer> oh, it was still connected as guest, had to remount it as mine
[16:50] <IotaSpencer> and the file still work
[16:50] <IotaSpencer> s
[16:50] <holstein> IotaSpencer: ok, so your system wide audio is *not* broken.. what is not working?
[16:50] <IotaSpencer> skype calls are garbled, and skype sounds make the sound buzz till I close skype
[16:51] <IotaSpencer> or until I restart pulseaudio
[16:51] <holstein> sure, but that is an issue with skype not your system sound, as you previously stated
[16:51] <holstein> there is no system wide audio issue
[16:51] <holstein> just skype, correct?
[16:52] <holstein> IotaSpencer: where did you get skype? the resos?
[16:52] <IotaSpencer> right, but it only happens after the first apt-get update + upgrade after the install
[16:52] <holstein> repos*
[16:52] <holstein> IotaSpencer: no.. it just happened now, friend
[16:52] <holstein> IotaSpencer: its happening from skype.. now
[16:52] <holstein> IotaSpencer: regardless.. where did you get skype?
[16:52] <IotaSpencer> yes, after the apt-get update + upgrade till I uninstall everything
[16:52] <IotaSpencer> skype.com
[16:53] <IotaSpencer> whereelse
[16:53] <holstein> IotaSpencer: the partner repo
[16:53] <IotaSpencer> ??
[16:53] <holstein> IotaSpencer: please try removing that skype, and installing the partner repo version
[16:53] <IotaSpencer> whats the partner repo ppa or whatever
[16:54] <holstein> IotaSpencer: the partner repo *is* the repo
[16:54] <holstein> IotaSpencer: please relax.. i am finding resources for you
[16:56] <holstein> IotaSpencer: this looks OK.. http://www.noobslab.com/2014/01/skype-released-new-version-install-in.html though, i would consider not installing skype-wrapper
[16:56] <holstein> regardless, now you know where the issue is.. and its not with the system, or any ubuntu or linux packages
[16:56] <holstein> IotaSpencer: remove the version you have installed first
[17:03] <IotaSpencer> o_O
[17:03] <IotaSpencer> that fixed it
[17:03]  * IotaSpencer is confoozed
[17:06] <IotaSpencer> I'm guessing I should just accept it and get on with my life
[17:10] <holstein> IotaSpencer: let skype know you had an issue with their product
[17:11] <holstein> IotaSpencer: the biggest issue with this is tracking it down, and not assuming anything
[17:11] <holstein> IotaSpencer: we are not allowed to know what skype is doing, so, we cant support it, but they are always welcome to.. they = skype maintainers
[17:14] <IotaSpencer> and its back, I restarted and the buzzing is back
[17:14] <holstein> IotaSpencer: the buzzing in skype?
[17:14] <IotaSpencer> yep
[17:14] <holstein> IotaSpencer: make certain skype is causing the issue, and let them know
[17:14] <holstein> you can file bugs against it..
[17:15] <holstein> !bug
[17:15] <holstein> but, upstream would really be the "best" way to deal with it
[17:15] <IotaSpencer> it worked for a bit when I installed it like you said, but once I restarted it started buzzing
[17:15] <holstein> IotaSpencer: restarted what?
[17:15] <IotaSpencer> my computer
[17:16] <holstein> IotaSpencer: ok.. let the skype maintainers know you have an issue with their product
[17:25] <IotaSpencer> o,o
[17:25] <IotaSpencer> If I reinstall it works again
[17:26] <holstein> IotaSpencer: sure.. let them know
[17:35] <OvenWerk1> I found when I first started skype that my speaker volume was too high and I had noise. Once I lowered it a funny thing happend and skype took over controling the level.
[17:38] <holstein> IotaSpencer: yeah, that is true ^
[17:38] <holstein> try setting control for skype to manual
[17:38] <holstein> could be just overblowing the settings
[17:39] <IotaSpencer> I never set skype to manage my sound though lol
[17:39] <holstein> IotaSpencer: you dont have to
[17:39] <OvenWerk1> I didn't either it just did
[17:39] <IotaSpencer> unticked it
[17:39] <holstein> IotaSpencer: you can confirm those settings to be sure. because that is the default setup
[20:05] <wickedheadache> so i should stop updateing the general kernal and start the rt update at 13.10?
[20:06] <holstein> wickedheadache: 13.10 is nearly EOL
[20:06] <holstein> there is no rt kernel. just the lowlatency one.. if thats what you are referencing
[20:11] <wickedheadache> nope referenceing the realtime kernal
[20:11] <wickedheadache> i know it's ot supported
[20:11] <holstein> wickedheadache: there is no RT kernel, so you are probably using it from a PPA?
[20:11] <wickedheadache> but its what i need
[20:12] <wickedheadache> not sing it yet
[20:12] <wickedheadache> afaik 12.04 was last rt kernal
[20:13] <holstein> wickedheadache: you can always make whatever kernel you like
[20:13] <holstein> you should try the lowlatency kernel, and the generic ones
[20:13] <wickedheadache> correct
[20:13] <holstein> i have hardware that actually gets lower latency do to better hardware support in the generic kernels of late
[20:14] <wickedheadache> but i don't want to g past a version where work had ended on rt
[20:14] <holstein> wickedheadache: they are labeled
[20:14] <holstein> wickedheadache: you should try the lowlatency ones
[20:14] <wickedheadache> not from where i've been looking
[20:14] <holstein> wickedheadache: there is really no need anymore for hard coded rt kernels like that
[20:14] <holstein> wickedheadache: look in your actual system and setup with the actual kernel running
[20:14] <holstein> wickedheadache: test first hand
[20:15] <wickedheadache> that what they said about 64.bit systems
[20:15] <holstein> wickedheadache: they?
[20:15] <holstein> wickedheadache: *you* try it, friend.. you can try it with the live CD
[20:15] <wickedheadache> yes they the speculators
[20:15] <wickedheadache> i have tried it
[20:15] <holstein> otherwise, there are many PPA's with rt kernels.. and other ways to run whatever kernel you like
[20:15] <wickedheadache> and i will again
[20:15] <wickedheadache> xD
[20:16] <holstein> 14.04 and 12.04 are soon to be the only  supported versions
[20:16] <holstein> neither have rt kernels
[20:16] <wickedheadache> it is likely i'll have both an rt and general "low latency" just for hw support and fixes etc
[20:16] <holstein> have what you like..
[20:17] <holstein> if your question is, should i stop upating the rt kernel, my answer is, use a supported kernel
[20:17] <holstein> kxstudio ppa's are well trusted and supported..
[20:18] <wickedheadache> so stop at 12.04 and update from there, maintain that rt kernal...and use a supported kernal for general use ty
[20:18] <wickedheadache> hmm
[20:19] <holstein> wickedheadache: 12.04 has no rt kernel
[20:19] <holstein> wickedheadache: run 14.04 with whatever kernel you like, if you are comfortable supporting them on your own
[20:19] <holstein> wickedheadache: 14.04 is what is suggested to be using
[20:19] <holstein> wickedheadache: you likely dont need an RT kernel anymore.. i find, first hand, on *all* my gear, i dont need it anymore
[20:20] <holstein> if you find you want, or need RT kernel, use one.. there are ppa's
[20:20] <holstein> you should be using 14.04.. but, 12.04 is still supported if you prefer
[20:20] <holstein> neither provide out of the box rt kernels
[20:20] <wickedheadache> nor does kxstudio?
[20:21] <holstein> wickedheadache: kxstudio provides a PPA that many use in ubuntustuduio
[20:21] <holstein> wickedheadache: you can ask kxstudio if they have an rt kernel
[20:21] <wickedheadache> it really never was supported
[20:21] <holstein> wickedheadache: what really never was?
[20:21] <holstein> wickedheadache: there was an officially supported rt kernel in 9.10.. that kernel was pulled forward to 10.04
[20:21] <wickedheadache> rt kernals...well les then others
[20:21] <holstein> wickedheadache: then, we added the officially supported lowlatency kernel
[20:21] <wickedheadache> i'm glad it hung on for so long
[20:22] <holstein> wickedheadache: there is no need for RT kernels. you should test first hand and see for yourself
[20:22] <wickedheadache> i wonder why you say tere is o need?
[20:22] <wickedheadache> what do you do with your pc?
[20:22] <holstein> wickedheadache: our upstream https://wiki.debian.org/DebianMultimedia#Realtime_kernel
[20:22] <holstein> "The Debian Multimedia team is not working on including a kernel image with the realtime-patches applied in Debian. Much of the realtime-patches have been accepted in the mainline kernel, to the point that for most purposes the stock Debian kernel is suitable even for realtime-like work."
[20:23] <holstein> wickedheadache: i work on what i need to work on
[20:23] <holstein> wickedheadache: i can facilitate realtime effects processing, and software synths live in realtime with the lowlatency kerne
[20:23] <holstein> kernel*
[20:23] <holstein> that is all RT is needed for
[20:23] <wickedheadache> nice link xD
[20:24] <wickedheadache> i think it gets confusing what happens between low lateny and real time...quick doesn't mean everything asap
[20:24] <holstein> wickedheadache: ubuntu is not working on one either.. but, we provide a lowlatency one that is an nice "balance" as more and more of the generic kernel becomes appropriate
[20:25] <holstein> wickedheadache: do you do realtime effects processing?
[20:25] <wickedheadache> uh yea you could say that
[20:25] <holstein> wickedheadache: ?
[20:25] <holstein> wickedheadache: do you?
[20:26] <holstein> wickedheadache: do you use the machine to provide effects such as distortion for a guitar in realtime?
[20:26] <wickedheadache> if softwae needs it then yes
[20:26] <holstein> wickedheadache: software doenst
[20:26] <holstein> wickedheadache: do you?
[20:26] <wickedheadache> uh ok
[20:26] <holstein> wickedheadache: do you use the computer for realtime effects processing?
[20:26] <holstein> wickedheadache: like a stompbox emulator for a real time performance on the guitar?
[20:27] <wickedheadache> see this is what people don't seem to understand
[20:27] <holstein> wickedheadache: correct, thats why im asking..
[20:27] <holstein> wickedheadache: if you dont do it live, you dont need lower latency settings
[20:27] <holstein> wickedheadache: do you do software synths live, as an instrument?
[20:27] <wickedheadache> real time applies to many things
[20:27] <holstein> wickedheadache: not really
[20:27] <holstein> wickedheadache: it applies specifically to needing sound to happen in "realtime"
[20:28] <wickedheadache> its not simply, will someone use thi or that
[20:28] <wickedheadache> and not for just audio
[20:28] <holstein> wickedheadache: you play the guitar, and the affected sound happens in relative realtime, so you can use it, like a stompbox
[20:28] <wickedheadache> i get that
[20:28] <holstein> wickedheadache: or, when you play a MIDI keyboard, you want the synth sound to occur relatively in sync with pushing the keys
[20:29] <holstein> not 30 miliseconds later
[20:29] <wickedheadache> low latency may stil not be able to multi task in real time?
[20:29] <holstein> if not doing those 2 things, then, 30 miliseconds doesnt matter
[20:29] <wickedheadache> hehe
[20:29] <holstein> wickedheadache: correct, RT is *not* relating to multitasking, or a "better" system. or "more performance"
[20:29] <holstein> wickedheadache: its specificialy only for that.. lower latency
[20:29] <wickedheadache> timing is everything in music particulrly live
[20:30] <wickedheadache> wow
[20:30] <holstein> wickedheadache: sure.. and im specificallly referencing live as the use case
[20:30] <holstein> wickedheadache: *only* live
[20:30] <holstein> wickedheadache: otherwise, it dosnt matter if, for example, you have a session loading in ardour, and you press play, and 40 miliseconds later is plays back
[20:30] <wickedheadache> so this is what happened to the rt kernal? it was taken over by pro audio?
[20:30] <holstein> the time there is irrelevant, and doesnt effect the quality of the work
[20:30] <holstein> wickedheadache: the RT kernel is gone, friend
[20:31] <holstein> wickedheadache: the patches were mostly integrated, as the link states, into the generic kernels
[20:31] <wickedheadache> it will be back i get the feeling low lat will not suit my needs
[20:31] <wickedheadache> but i will ty it
[20:31] <holstein> wickedheadache: if you need lower latency, you may
[20:31] <holstein> but the kernel is only one part of it
[20:32] <holstein> the driver support is more important to facilitating lower latency
[20:32] <wickedheadache> latency is not my only concern
[20:32] <holstein> as i stated above, i can get lower latency with a generic kernel with a particular USB device
[20:32] <wickedheadache> that it is driver and hw support is vital
[20:32] <holstein> that is not related to the RT patch, but the driver support
[20:32] <holstein> so, if you want lower latency, or need it, which im still not sure you do.. the kernel patch is only one part of it
[20:33] <wickedheadache> so how woul an ha enviroment play into Low lat systems?
[20:33] <holstein> wickedheadache: a "ha environment" ?
[20:33] <wickedheadache> do i get similar things going down the ha path?
[20:34] <holstein> wickedheadache: either you need higher priority or not
[20:34] <holstein> wickedheadache: you determine if you do, then do what needs to be done
[20:34] <wickedheadache> or both
[20:34] <holstein> wickedheadache: not following
[20:34] <holstein> wickedheadache: as i said, these patched kernels are just part of the equation
[20:35] <holstein> wickedheadache: driver suppport is much more crucial. and a patched kernel will likely not "Fix" that in any way
[20:35] <wickedheadache> in an ha / cloud enviromeny many cpus hd's etc will be used at once
[20:35] <holstein> wickedheadache: for proaudio, you would want to track to a different drive than the OS is on, ideally
[20:36] <wickedheadache> the general 14 version supports much of the ground work for a cloud or share resouces
[20:36] <holstein> wickedheadache: otherwise, no such ha patches will really do much to facilitate an audio production enviroment
[20:36] <holstein> wickedheadache: sure.. and thats nothing to do with audio
[20:36] <wickedheadache> correct
[20:36] <holstein> wickedheadache: or video
[20:36] <holstein> wickedheadache: if you want or need waht it provides, use it
[20:36] <holstein> wickedheadache: if the question is, will ha help me in audio.. i dont see anything that suggests that
[20:37] <wickedheadache> much of the performane increase woon't be noticable if the pc is not setup correctly anyway
[20:37] <holstein> hard drive access will not facilitate or improve driver support
[20:37] <holstein> wickedheadache: is your hard drive the bottleneck for your audio production? for me, its not
[20:37] <wickedheadache> it always is xD
[20:37] <holstein> so, im not looking for kernel patches to address an issue i dont have
[20:37] <holstein> wickedheadache: i doubt that it is
[20:38] <wickedheadache> but i guess i won't know how well low lat supports clouds until its tried
[20:38] <holstein> but again, if you want/need it, make it happen
[20:38] <holstein> wickedheadache: clouds?
[20:38] <holstein> wickedheadache: servers?
[20:38] <holstein> wickedheadache: you should use the generic on a server.. its what the server OS ships with
[20:38] <wickedheadache> right i will i just want some idea of future conflicts and bugs i guess
[20:38] <holstein> wickedheadache: you dont want an audio specific rt or lowlatency for a server machine
[20:39] <holstein> wickedheadache: if you are not doing audio production, you are not in the correct zone
[20:39] <wickedheadache> audio is part of it
[20:40] <holstein> wickedheadache: sure.. and its not going to help you on a server like that
[20:40] <wickedheadache> it sure would
[20:40] <holstein> wickedheadache: you are in the wrong place.. and neither an rt or lowlatency kernel is correct for a server
[20:40] <holstein> wickedheadache: if you think it would, feel free to try it
[20:40] <holstein> wickedheadache: its not intended for what you are talking about
[20:40] <wickedheadache> there is no right place for this stuff xD
[20:40] <holstein> wickedheadache: yes.. a server channel
[20:40] <wickedheadache> intentions are relevent
[20:40] <holstein> wickedheadache: the kernel the server version ships with will be appropriate
[20:41] <wickedheadache> right unless you built the server
[20:41] <holstein> wickedheadache: use what you like, friend. the lowlatency and rt kernels are not for yout task
[20:41] <wickedheadache> it seems they are by our discussion so far
[20:41] <holstein> wickedheadache: ?
[20:42] <wickedheadache> i'm glad your around to chat about stuff
[20:42] <holstein> anyways.. good luck and try a server community. cheers@
[20:42] <wickedheadache> ty


[08:01] <poningru> @schedule eST
[08:01] <Ubugtu> Schedule for EST: 23 Nov 12:00: Ubuntu Development Team | 25 Nov 13:00: Xubuntu | 28 Nov 11:00: LoCo Team | 29 Nov 07:00: Edubuntu
[08:33] <Hobbsee> @schedule sydney
[08:33] <Ubugtu> Schedule for Australia/Sydney: 24 Nov 04:00: Ubuntu Development Team | 26 Nov 05:00: Xubuntu | 29 Nov 03:00: LoCo Team | 29 Nov 23:00: Edubuntu
[05:27] <lotusleaf> BenC: feathers and all? :P
[05:44] <sladen> mmm, continental time
[05:53] <thom> ubugtu seems a little premature
[05:53] <nixternal> @schedule chicago
[05:53] <Ubugtu> Schedule for America/Chicago: Current meeting: Ubuntu Development Team | 25 Nov 12:00: Xubuntu | 28 Nov 10:00: LoCo Team | 29 Nov 06:00: Edubuntu
[05:54] <fabbione> pre-emptive strike!
[05:54] <nixternal> hehe
[05:54] <rodarvus> actually ubugtu always change the topic 10 minutes before the start of the next meeting
[05:54] <rodarvus> (and does it again, afair, 2 or 3 hours after the meeting has started)
[05:54] <rodarvus> s/afair/iirc/
[05:55] <rodarvus> hey pitti
[05:55] <cjwatson> I've created https://wiki.ubuntu.com/DevelTeamMeeting20061123
[05:55] <cjwatson> mdz will not be here due to thanksgiving, so I'll chair
[05:56] <cjwatson> anyone desperate to go first? otherwise I'll just run through in the order of the above wiki page
[05:56] <fabbione> cjwatson: does the first one get a pony?
[05:59] <Riddell> hi all
[06:00] <BenC> cjwatson: Can I go first so I can get to the turkey?
[06:00] <cjwatson> BenC: you're second in the list anyway :)
[06:00] <fabbione> BenC: you are second anyway
[06:00] <BenC> ok, I can wait :)
[06:00] <lotusleaf> in soviet russia, turkey goes first
[06:02] <zul> hi everybody
[06:03] <fabbione> should we get started guys?
[06:03] <cjwatson> I'm just going through the list to figure out whom to ping
[06:03] <cjwatson> I assume Kees is off due to Thanksgiving as well
[06:04] <cjwatson> doko is on holiday
[06:04] <cjwatson> ogra is in Poland somewhere
[06:04] <pitti> Kees is there
[06:04] <cjwatson> seb128 has an appointment
[06:05] <Mithrandir> mvo: yarr!
[06:05] <cjwatson> ok, we'll see if Adam and Kees turn up later
[06:06] <cjwatson> general idea of this meeting is to go through specs and figure out which ones are on track for approval by next Thursday
[06:06] <cjwatson> or, more importantly, which ones aren't and may need to be rescued
[06:06] <pitti> @all: since Kees officially reports to elmo now, mdz said that Kees is not officially required for distro team meeting
[06:06] <cjwatson> pitti: aha, thanks
[06:06] <cjwatson> BenC: could you start? I have a phone call, brb
[06:06] <Mithrandir> cjwatson: given that it's 0400 in Adam's TZ, I suspect he might just have crashed.
[06:06] <BenC> * driver-device-manager: Drafting: will have this finished and approved by Nov 30th. Actually started on writing this already.
[06:06] <BenC> * retire-optimized-kernels: Retroactive spec, need to draft it.
[06:06] <BenC> * linux-kernel-crash-dump: Retargetted to feisty. Few small bits still to implement.
[06:06] <BenC> * libata-for-all-ata-disks: Retargetted to feisty. Have switched a few drivers to pata in 2.6.19. Ran into some issues with initramfs-tools not including them in the initrd, but fixed as of yesterday. Still some issues to figure out with regard to generic/ide-generic and ata_generic/pata_legacy migration.
[06:07] <cjwatson> (back)
[06:07] <Keybuk> BenC: we really really should talk about d-d-m given #u-k today.  let's schedule that for when you're less turkey-centric
[06:07] <pitti> BenC: do you really need to invest much effort for retire-optimized-kernels if it's done already anyway?
[06:07] <BenC> Keybuk: definitely
[06:07] <Keybuk> can we make kylem our bitch to write the kernel patches?
[06:07] <BenC> pitti: It's just a spec to record what we did
[06:07] <pitti> ah
[06:07] <BenC> I only mention it because it's assigned to me :)
[06:08] <cjwatson> (Adam's moving to elmo's team as well, AFAIK, so ...)
[06:08] <cjwatson> BenC: ok, you seem to have an easy time :)
[06:08] <BenC> cjwatson: I'm willing to take on some other stuff if need be
[06:08] <cjwatson> which of course makes you a prime target for rescuing other people's stuff ...
[06:09] <BenC> I can delegate
[06:09] <cjwatson>   feisty-ubiquity: Approved. I should do some of this, but some would make good bite-size tasks for new developers. Should I be the assignee anyway?
[06:09] <cjwatson>   increase-hwdb-participation: Approved. None of this is actually going to happeen in the installer, so I'd appreciate somebody else volunteering as the assigneee here.
[06:09] <kylem> heh
[06:09] <Keybuk> . o O { can I be on elmo's team too? :p }
[06:09] <cjwatson>   intel-mac-support: Did not get discussion at UDS or allhands. I know roughly what needs to be done, so I intend to draft it anyway and we can at least make the situation a lot better than it is now.
[06:09] <cjwatson>   setup-console-under-usplash: Approved; working my way through the merge pile before uploading; unfortunately we have to merge xkeyboard-config first.
[06:09] <cjwatson>   simplify-oem-installation: Still in requirements gathering. There are some fairly obvious things we can do listed at the bottom of the brain-dump, but I don't know how far we can take this without better commercial input.
[06:09] <cjwatson>   ubiquity-advanced-partitioner: No more work done since just before UDS, but it's still just as approved as it was before.
[06:09] <cjwatson>   ubiquity-automation: Approved. We went for a fairly conservative set of options which should be a quick win.
[06:09] <cjwatson>   ubiquity-driver-updates: Drafting. We loosely agreed the business side at allhands, so I just need to put the pieces together and get it approved now.
[06:09] <cjwatson>   ubiquity-more-user-config: Discussion. We still need to talk to Launchpad developers about account creation; I didn't manage this at allhands ...
[06:09] <cjwatson>   ubiquity-oem: Not really started. Doesn't need significant discussion, but Maria indicated at allhands that this wasn't a priority for the Canonical OEM team, so I'll only complete it if I have time.
[06:09] <cjwatson>   ubiquity-release-notes: Approved. Should be easy.
[06:09] <cjwatson>   ubiquity-slideshow: Approved. Installer side should be straightforward, but it also needs artwork. Who should be the assignee?
[06:09] <cjwatson> note in case it's lost: looking for volunteers to implement increase-hwdb-participation
[06:09] <cjwatson> I suspect I'll need to ask mdz later about the who-should-be-assignee questions
[06:10] <cjwatson> ubiquity-more-user-config is really the one in most trouble, so I'll try to get that rescued somewhat tomorroow
[06:10] <cjwatson> -o
[06:10] <Keybuk> I still want ubiquity-sudoku
[06:10] <fabbione> Keybuk++
[06:11] <Mithrandir> Keybuk: that should be easy enough to do..
[06:11] <pitti> Keybuk: Apps -> Games -> Sudoku :)
[06:11] <cjwatson> seriously tempted to ignore the oem stuff as I doubt I'm going to get clear enough requirements
[06:11] <pitti> cjwatson: will that replace the current oem-config package? or will both be supported?
[06:12] <pitti> (I'm asking because oem-config seems to have quite a number of hiccups)
[06:12] <cjwatson> pitti: the plans in simplify-oem-installation were to improve oem-config; one of my suggestions in there was to build it from ubiquity, since internally they're similar
[06:12] <pitti> ah, that's great
[06:12] <cjwatson> I suspect regardless of spec approval I'll at least try to fix bugs *shrug*
[06:13] <Mithrandir> cjwatson: is increase-hwdb-participation as simple as it looks?
[06:13] <mvo> I would be interessted in increase-hwdb-participation but I supsect that I will not have time because of my specs
[06:13] <cjwatson> Mithrandir: as specced, I think so
[06:13] <cjwatson> anyway, we can talk about it later
[06:14] <cjwatson> is dholbach around anywhere, or on holiday?
[06:14] <Mithrandir> cjwatson: if so, I can probably do it.  It _looks_ like an hour or so of work, mostly in casper.
[06:14] <Mithrandir> he was around earlier today.
[06:14] <cjwatson> Mithrandir: needs to be outside casper I think, due to the after-first-reboot requirement
[06:14] <cjwatson> anyway, later :)
[06:14] <cjwatson> fabbione: next
[06:14] <fabbione> Done
[06:14] <fabbione>  * clean up a couple of specs.
[06:14] <fabbione>  * merges.
[06:14] <fabbione>  * extra bug fixing in mdadm to have bootable feisty.
[06:14] <fabbione>  * SRU for lvm2 (dapper and edgy).
[06:14] <fabbione>  * debugging pata_via init race.
[06:14] <fabbione>  * update some other packages (ocfs2-tools, openais, redhat-cluster-suite).
[06:14] <cjwatson> (later => #ubuntu-devel)
[06:14] <fabbione>  * wrote metacode for MAU support in the kernel.
[06:14] <fabbione>  * recovering from jetlag (on going).
[06:14] <fabbione> To do
[06:14] <cjwatson> fabbione: EXPN MAU?
[06:14] <fabbione>  * start working specs implementations.
[06:14] <fabbione>  * get last specs approved.
[06:14] <fabbione>  * change meeting report layout to match specs status.
[06:15] <fabbione> cjwatson: it's a math unit optimized to do some mul for sll
[06:15] <fabbione> s/sll/ssl
[06:15] <cjwatson> mvo: talk with ogra about that when he's around
[06:15] <mvo> cjwatson: dholbach is on the road, he send his meeting notes to mdz AFAIK
[06:16] <fabbione> cjwatson:  i am deliberatly avoiding SSL accelerator because it's like a dedicated FPU that does only 3 things
[06:16] <fabbione> cjwatson: and *casually* they are very often used in SSL operations
[06:16] <cjwatson> fabbione: is that for sparc64-niagara-ssl-accelerator?
[06:17] <fabbione> cjwatson: yes
[06:17] <fabbione> cjwatson: yes sorry.. if forgot the spec format for this meeting
  * update some other packages (ocfs2-tools, openais, redhat-cluster-suite). -> feisty-ha-clusters
[06:17] <cjwatson> so you have ubuntu-feisty-ha-clusters (low), integrity-check (low) to get approved as well as s-n-s-a
[06:18] <fabbione> i have more but they are pending approval orhave been excluded from discussion at uds
[06:18] <cjwatson> but they're pending-approval so presumably those are not too badly off
[06:18] <fabbione> exactly
[06:18] <cjwatson> ok, thanks
[06:18] <cjwatson> heno: next
[06:19] <heno> * access-gdm - Should be simple enough with upstream doing work on it. Our default GDM theme is not a11y-capable yet though -- need to look into that.
[06:19] <heno> * braille-support - Pending Review. cjwatson and Keybuk should have another look at it.
[06:19] <heno> * color-filters - Spec still needs completing. Libs vare available for testing from upstream but no config GUI has been made AFAIK.
[06:19] <heno> * common-at-conf -- spec needs to be tightened and recent upstream work needs taking into account.
[06:19] <heno> * multilingual-speech - Should be split up into a Fiesty and a Fiesty+1 spec, with the former adding more language files to our repos (universe and multiverse) and the later would include UI and Just Works stuff.
[06:19] <heno> * orca-laptop-support - Approved. good progress -- laptop layout now available for testing from upstream.
[06:19] <heno> * atspi-testing-by-default -- I'd like feedback from the team on this. It is already implemented in test builds of Gnome; does that mean we get it automatically? Are there any major objections to this? ... it will slow systems down a bit.
[06:19] <cjwatson> heno: most of your specs still seem to be in New. Is that an accurate reflection?
[06:20] <cjwatson> mouse-tweaks, onboard-desktop-control, onboard-switching?
[06:20] <heno> cjwatson: some will not be going forward due to general lack of community support, what should be done with those?
[06:21] <heno> Yes, I posted several such specs before UDS but they don't have steam ATM
[06:21] <cjwatson> if they're just a bad idea, there's an Obsolete status or similar, and use the status whiteboard; if they won't happen *yet*, I think Deferred
[06:21] <heno> the onboard stuff needs time from chris, etc
[06:22] <cjwatson> but at any rate note the status in the whiteboard
[06:22] <heno> ok, I'm drafter, registrant, but was not planning to have them assigned to me
[06:22] <heno> esp. the onboard ones
[06:22] <heno> ok, will do
[06:23] <Keybuk> who were you planning them to be assigned to?
[06:23] <cjwatson> my main concerns about atspi-testing-by-default are (a) if it's *too* broken it could seriously impede development, (b) how do we arrange to turn it off again for people who install milestone releases of feisty and then upgrae?
[06:23] <cjwatson> upgrade
[06:23] <heno> community members
[06:24] <heno> cjwatson: I agree on both of those. I can research (b) a bit
[06:24] <cjwatson> if they're understood but just lack implementation time, please try to get them drafted so that people can pick them up even if there's nobody available right now
[06:25] <heno> Chris Jones may still work on onboard stuff
[06:25] <heno> cjwatson: right, ok
[06:25] <heno> some might be suitable for next years GSoC
[06:26] <cjwatson> ok, thanks heno; we can discuss further later
[06:26] <cjwatson> iwj: next
[06:26] <heno> we are planning a joint pool of specs/candidates across several FOSS projects
[06:26] <iwj> automated-testing-deployment: Approved, implementation Deferred from edgy.  Work will continue.
[06:26] <iwj> udev-lvm: Pending Approval by mdz.
[06:26] <iwj> gnome-app-install-codecs: Drafting.  Awaiting final details of the codec specifier string; apparently gstreamer folks are working on this.
[06:26] <iwj> winmodem-support: New.  Spec is unclear and I think needs discussion, I suggest deferring to feisty+1.
[06:26] <iwj> package-dependency-field-breaks: Approved / Beta Available.  Should be ready for full deployment now; I will rerun my search-for-candidates.
[06:26] <iwj> usb-adsl-modems: Approved / Unknown.  Lacking an Assignee.  It would be nice to assign this to someone who understands the subject.
[06:27] <iwj> consistent-login-screen: Review.  There seems to be a shortage of reviewers today.  It seemed odd to review my own spec, so I didn't.
[06:27] <iwj> dbus-restarts: Drafting.  This needs discussion I think.  Why was it declined for uds-mtv ?
[06:27] <iwj> edgy-fontconfig: New.  There is no spec and the subject needs discussion.  I suggest deferring (or rejecting).
[06:28] <rodarvus> iwj, edgy-fontconfig is a good spec. the real problem is that we basically got no one with deep fontconfig knowledge at UDS MTV
[06:28] <cjwatson> I think dbus-restarts was declined because it was controversial and properly belonged upstream (note: just the messenger)
[06:29] <cjwatson> rodarvus: err, we had Keith Packard - how much more knowledgeable do you want? :P
[06:29] <iwj> cjwatson: Um.
[06:29] <Keybuk> actually it was declined because nobody subscribed to it
[06:29] <iwj> Keybuk: That's fair enough.
[06:29] <Keybuk> mdz only wanted things to be on the schedule if there were multiple people to discuss it
[06:29] <rodarvus> cjwatson, keithp was there for one morning, and had specs during all the time he was there :)
[06:29] <iwj> cjwatson: dbus-restarts really needs to be done and every one of us knows that upstream are on crack.
[06:29] <Keybuk> where only the assignee/drafter was there, they may as well just draft it themselves and get it approved as a release goal directly
[06:29] <cjwatson> iwj: I agree
[06:29] <rodarvus> but you're right, of course
[06:30] <iwj> So it's not controversial here and we should just do it.  But I can't draft it because I don't know dbus quite well enough.
[06:30] <cjwatson> iwj: gnome-app-install-codecs> do we have a timescale for gstreamer feedback?
[06:30] <iwj> Ryan Lortie says `actively being worked on'.
[06:30] <cjwatson> any volunteers for usb-adsl-modems? I have some experience with one of the models in question, but no time
[06:30] <pitti> iwj: dbus-restart doesn't seem painfully urgent; and it is yet to be seen whether it's a good idea for a package to restart a daemon in the user's session
[06:30] <iwj> Mail yesterday at 1700Z.  No reply from the people who are `actively [working] ' on it ...
[06:31] <cjwatson> I've made a note to review consistent-login-screen
[06:31] <iwj> pitti: uh ?  That's not the suggestion.  But let's not have the bof now.
[06:31] <iwj> cjwatson: Thanks.
[06:31] <cjwatson> perhaps you two can discuss it in #ubuntu-devel later
[06:31] <pitti> right
[06:31] <iwj> Right.
[06:32] <cjwatson> also to talk to mdz about edgy-fontconfig
[06:32] <iwj> Anyway, I'll chase the codec thing.
[06:32] <iwj> It does seem to have momentum, we just need to make sure the communication is working.
[06:32] <cjwatson> winmodem-support is annoying but if we do usb-adsl-support at least we'll improve the most common modern class of dialup
[06:32] <cjwatson> er, dialup-a-like
[06:32] <iwj> *snort*
[06:33] <cjwatson> and there is not a lot of developer traction, unfortunately
[06:33] <iwj> Yes.
[06:33] <cjwatson> ok, thanks, I have copious notes now :)
[06:33] <iwj> It's a shame that towsonu2003 couldn't make it to uds to explain it to us.
[06:33] <cjwatson> I'll have another read through it and see if there's low-hanging fruit
[06:33] <cjwatson> Riddell: next
[06:34] <Riddell> done:
[06:34] <Riddell>  * all of KDE main merged and updated, send patches upstream, packaging koffice 1.6.1, and security fun with
[06:34] <Riddell> todo:
[06:34] <Riddell>  * merge rest of Kubuntu packages and others with my name on them
[06:34] <Riddell>  * on holiday next week
[06:34] <Riddell> specs:
[06:34] <Riddell> 1 being reviewed:
[06:34] <Riddell>   kubuntu-ubiquity-migration-assistant
[06:34] <Riddell> bunch needing approval:
[06:34] <Riddell>   (community) kubuntu-multimedia-simplification, kubuntu-samba-integration, kubuntu-feisty-laptop, kubuntu-feisty-networking
[06:34] <Riddell>   (artwork) kubuntu-feisty-artwork*
[06:34] <Riddell>   (mine) kubuntu-feisty-adept-changes, kubuntu-ubiquity-migration-assistant
[06:34] <Riddell> approved specs:
[06:34] <Riddell>   kubuntu-feisty-kde4-plan, would be a good task for an abitious MOTU
[06:34] <Riddell>   kubuntu-update-manager, most important one, still trying to contact upstream with questions about embedded konsole
[06:34] <Riddell>   kubuntu-feisty-language-selector, approved and qt 4 port already done by josef
[06:34] <Riddell>   kubuntu-feisty-ubiquity, sebas volunteered to help with qt 4 port
[06:34] <Riddell> fabbione: iwj was good enough to review kubuntu-ubiquity-migration-assistant, so hopefully that'll need approval soon too
[06:35] <fabbione> Riddell: ok
[06:35] <cjwatson> I'll try to pick up approvals tomorrow/Monday once I'm done with my own specs
[06:35] <cjwatson> what's the * beside kubuntu-feisty-artwork?
[06:36] <Riddell> cjwatson: it's about 5 specs for each of the artwork parts
[06:36] <Riddell> the specs themselves are very short
[06:36] <cjwatson> oh I see, a wildcard
[06:37] <cjwatson> kubuntu-gdebi, kubuntu-hwdb-usability, kubuntu-feisty-hal-device-manager, kubuntu-onboard?
[06:37] <Riddell> all deferred
[06:38] <cjwatson> ok, can you mark them as such?
[06:38] <Riddell> sure
[06:39] <cjwatson> thanks
[06:40] <cjwatson> kylem: anything from you? I know you probably don't have much in the way of specs (yet) ...
[06:40] <kylem> moo.
[06:40] <kylem> done:
[06:40] <kylem>  * ubuntu-dapper-updates.git up to date with patches from community
[06:40] <kylem>  * ubuntu-edgy-updates.git up to date with backports/patches from dapper-updates
[06:40] <kylem>  * both trees built on i386/generic
[06:40] <kylem>  * pushed to kernel.org
[06:40] <kylem> todo:
[06:40] <kylem>  * receive more marching orders
[06:40] <kylem>  * figure out why git on rookery hates me
[06:40] <kylem> specs:
[06:40] <kylem>  * none assigned
[06:41] <cjwatson> there's a kernel in dapper-proposed (IIRC) that I need to figure out what to do with
[06:41] <pitti> kylem: we need a kernel security update soon; I would like to talk to you about that
[06:41] <cjwatson> it's like ten weeks old, but we should probably talk through it at some point
[06:41] <kylem> ok.
[06:42] <cjwatson> right, I assume Ben will take care of most of your marching orders for now. Are you taking primary responsibility for stable release maintenance?
[06:42] <kylem> you'd have to ask Ben :)
[06:43] <pitti> alright, let's talk about this in #u-k tomorrow
[06:44] <kylem> sure.
[06:44] <cjwatson> ok, thanks
[06:44] <cjwatson> pitti: next
[06:44] <pitti> Done:
[06:44] <pitti>  * vacation until yesterday
[06:44] <pitti>  * caught up with email backlog, security review, and kernel security issues
[06:44] <pitti> Todo:
[06:44] <pitti>  * find a spare month to catch up with my fat bugs inbox, which I didn't dare to open in the last two weeks
[06:44] <pitti>  * start implementing cleanup-audio-jumble and zero-configuration-networking, since these are most urgent and block other specs
[06:44] <pitti> My feisty goals:
[06:44] <pitti>  * zero-configuration-networking: approved, did not start any implementation yet; played around with the stuff locally, avahi-autoipd works nicely, current libnss-mdns does not work at all for me, needs more work; approx. 2 days work
[06:44] <pitti>  * cleanup-audio-jumble: pending approval; didn't have an assignee yet, I signed up for this one; did some initial tests, looks good; required code changes will take about a day, changing the system to use pulse consistently another day
[06:44] <pitti>  * gnome-mount: approved, and used by default in feisty; still needed: security overhaul of hal backend, and de-gnome-ification of password dialog to make it appropriate for XFCE; approx. 3 days work
[06:44] <pitti>  * mount-all-local-filesystems: approved, not started yet; shoulnd't take more than one or two days to get it working
[06:44] <pitti>  * apport-improvements: not discussed at UDS; did some talks to kylem and BenC for getting the kernel side right, and talked to lifeless about python crash interception and general code structure cleanup; a lot of work to implement all improvements, but not scheduled for feisty, so low-prio
[06:44] <pitti>  * crash-reporting: not discussed at UDS, got an ad-hoc session on allhands; client/apport side isn't too complicated, but writing the server side is a considerable amount of work; needs more discussion with stub and LP team
[06:45] <pitti>  * bug-reporting-tool: pending approval, current assignee is sfllaw, but since most of this spec deals with apport changes, I'll probably end up doing the client side (I estimate 1-2 days); I have no idea how much work the Malone side is (cloakroom and linking submitted stuff to bug)
[06:45] <pitti>  * malone-cve-tracking: only got a private ad-hoc session with keescook; not a high-pri
[06:45] <cjwatson> bug mailbox> I feel your pain
[06:45] <pitti> *shudder*
[06:45] <Keybuk> I've actually caught up on my bugs
[06:45] <Keybuk> I spend most of today on it
[06:45] <Mithrandir> pitti: hmm, how does zero-configuration-networking hook into network-roaming?
[06:46] <kylem> bug mailbox? you mean you don't use inbox?
[06:46] <Keybuk> Mithrandir: requires n-m to start avahi-autoipd for "create/join other network"
[06:46] <pitti> Mithrandir: the spec talks about the things that n-m needs to learn
[06:46] <iwj> pitti: mount-all-local-filesystems> what about the mad journal replay problem ?
[06:46] <pitti> Mithrandir: like invoking avahi-autoipd, etc.
[06:46] <cjwatson> kylem: I did until it crushed me
[06:46] <Mithrandir> pitti: ok.  Can we talk about this later or tomorrow?
[06:46] <pitti> Mithrandir: sure
[06:46] <pitti> this certainly requires some coordination
[06:46] <rodarvus> kylem, I suppose you subscribe to kernel bugs, right?
[06:46] <cjwatson> pitti: automatic-printer-conf?
[06:46] <kylem> rodarvus, indeed.
[06:47] <pitti> iwj: no clue, can we discuss this in #u-d?
[06:47] <iwj> Sure.
[06:47] <pitti> cjwatson: not scheduled for feisty, and I'm afraid I won't have time for that
[06:47] <pitti> cjwatson: however, when we get printerdrake this will mostly implement itself
[06:48] <cjwatson> pitti: apport-improvements is currently medium; we should probably talk about how much is possible
[06:48] <pitti> I'd really like to use the new kernel's 'pipes in core patterns' approach
[06:49] <pitti> but that requires a kernel fix
[06:49] <cjwatson> it would be nice to get that one at least drafted so that others can be found to help out
[06:49] <tkamppeter> printerdrake is an approved spec, and pitti told me on the UDS that he wanted to download my tarball and start a first adaptation to Ubuntu around two weeks after the UDS.
[06:49] <pitti> right, I'm trying to do that ^
[06:49] <pitti> cjwatson: I'll draft a subset of the improvements then
[06:49] <tkamppeter> https://blueprints.launchpad.net/distros/ubuntu/+spec/printerdrake
[06:49] <cjwatson> pitti: ok, thanks
[06:50] <cjwatson> mvo: next
[06:50] <mvo> Approved specs:
[06:50] <mvo> - auto-dist-upgrade-testing
[06:50] <mvo> - binary-driver-education
[06:50] <mvo> - common-customizations
[06:50] <mvo> - enabling-additional-components
[06:50] <mvo> - server-upgrade-tool
[06:51] <mvo> Pending approval:
[06:51] <mvo> - dist-upgrader-fixes
[06:51] <mvo> Drafting:
[06:51] <mvo> - dynamic-mirror-decisions: I need to add input from James that I got during AllHands
[06:51] <mvo> - apt-sha256: not sure it needs a full spec, its straightforward to implement
[06:51] <mvo> - apt-sync: work on integrating the SoC work on incremental updates into apt
[06:51] <mvo> - dist-upgrader-arch-any: make sure the upgrader can use binary-any components (e.g. backports). Its pretty clear how to implement it, not sure it needs a full spec
[06:52] <cjwatson> incremental updates> not pdiffs, right? does that require LP integration?
[06:53] <mvo> cjwatson: no, zsync/rsync based updates. it would require apt-ftparchive/soyuz integration, but its all pretty experimental currently, not sure it can be done in feisty timeframe
[06:53] <mvo> I have a test repository working on people
[06:53] <cjwatson> I'm not concerned about apt-sha256 or dist-upgrader-arch-any from the sound of things
[06:53] <Keybuk> given the size of the soyuz team, I'd imagine it'd be hard finding the resources
[06:53] <Keybuk> unless you want to hack on LP
[06:53] <cjwatson> well, except that apt-sha256 probably needs a soyuz change
[06:53] <cjwatson> yes, anything that needs LP integration needs to be done massively far in advance
[06:54] <mvo> cjwatson: right, but the apt-sha256 change should be small, it only writes the Release file itself, the rest is done via apt-ftparchive
[06:54] <cjwatson> mvo: dependency-removal?
[06:54] <cjwatson> mvo: ... assuming that soyuz keeps on using apt-ftparchive, which doesn't seem entirely definite
[06:55] <mvo> cjwatson: I'm not sure why it is in NEW. it was fully speced and approved. and its in edgy. its just not turned on by default (it just prints)
[06:55] <mvo> cjwatson: oh? it seems to me that if the soyuz team is very small and has trouble keeping up that rewriting apt-ftparchive might not be the best thing to do
[06:56] <cjwatson> mvo: feel free to draft whatever's still needed and move it out of new (possibly pointing it at a different wiki page or something)
[06:56] <mvo> cjwatson: thanks, I will
[06:56] <cjwatson> mvo: well, I agree, but they've always had performance concerns with apt-ftparchive and want to just dump the data out of the database
[06:56] <cjwatson> anyway, later
[06:57] <mvo> *nod*
[06:57] <cjwatson> mvo: dynamic-mirror-decisions does not seem to address automatic selection at all yet - is that planned?
[06:57] <mvo> cjwatson: yes, it was unclear to me what is really needed. but I talked to James during allhands and have a pretty good idea now
[06:57] <mvo> I need to add it to the spec though
[06:57] <cjwatson> ok, please do
[06:57] <cjwatson> thanks
[06:58] <cjwatson> rodarvus: next
[06:58] <rodarvus> - accelerated-x: under review. I asked Scott to hold the Approval of this spec until we received release notes from Christina. This is well underway, so please feel free to Review it now
[06:58] <rodarvus> - composite-by-default: drafting. Scope has changed since last BoF meeting on UDS MTV. Was "composite *not* really by default, but easily enabled", now became "composite by default". The three remaining focal points of the drafting are:
[06:58] <rodarvus>   - Making a table, with an in depth comparison of Beryl and Compiz, plus features that need to be met by both of them, so the Technical Board can make the decision when the time comes (Feature Freeze, I suppose?). This comparison is underway, I expect to have it ready tomorrow
[06:58] <rodarvus>   - Inheriting stuff from 'desktop-effects' package into a semi-novelty design, to accomodate the fact that we'll be the first distro using composite by default. This information will also be added to the spec
[06:58] <rodarvus>   - Researching graceful fallback of Beryl/Compiz to Metacity (and how to store that into the config file).
[06:58] <rodarvus> - bullet-proof-x: needs to be drafted, but is blocked by 'composite-by-default', which is of higher priority
[06:58] <rodarvus> - simple-x-mode-selection: likewise
[06:58] <rodarvus> - maemo-on-ubuntu: we had almost a day of discussion at UDS MTV for this spec, but it needs legal feedback from Nokia, before I can actually draft it. (so problems are not of technical nature, and I'm not sure if it will happen for feisty)
[06:58] <rodarvus> - I also have two other edubuntu-related specs, which I plan to talk to ogra about, when he is here (but they are already approved)
[06:58] <rodarvus> Remarks:
[06:58] <rodarvus> - I expect composite-by-default to be ready for the first round of Review tomorrow. Hopefully the first two remaining items will be addressed. 'graceful fallback' is not quite there, unfortunately
[06:58] <rodarvus> - the two specs *will* be ready before Nov 30th. I'll finish them on Monday, even if composite-by-default is not there yet
[06:59] <Keybuk> rodarvus: Feature Freeze is the plan
[06:59] <rodarvus> *nods*
[06:59] <cjwatson> or distro sprint?
[06:59] <cjwatson> pitti: fallback to metacity
[06:59] <rodarvus> heh
[06:59] <Keybuk> that way teams can coalesce around both projects, and we can evaluate how much support we're likely to get, as well as what shape they're both in
[07:00] <rodarvus> pitti, the challenge of having good hardware support, with composite window manager is the biggest challenge of accelerated-x and composite-by-default
[07:01] <cjwatson> how is simple-x-mode-selection blocked by composite-by-default?
[07:01] <rodarvus> and the reason why these two specs are hard to get approved and implemented right
[07:01] <pitti> rodarvus: (just bitching that feisty breaks both my computers ATM, but nevermind)
[07:01] <zul> is there going to be a way of manually turning off compiz?
[07:01] <rodarvus> cjwatson, just time constraints
[07:01] <rodarvus> as mentioned above, I'll draft the two remaining specs monday, regardless if I have composite-by-default ready for review by the
[07:02] <rodarvus> then
[07:02] <cjwatson> rodarvus: ah, I misunderstood "likewise"
[07:02] <cjwatson> ok, thanks, let me know when I can look over bullet-proof-x
[07:02] <rodarvus> -EBADGRAMMAR
[07:02] <cjwatson> Keybuk: next
[07:02] <rodarvus> cjwatson, sure
[07:03] <rodarvus> Keybuk, please take a look at accelerated-x when you can. I hope it won't need another round of drafting, but you never know
[07:03] <Keybuk> Spec Status
[07:03] <Keybuk> udev specs: these are only a few hours work each, yet eliminate a major source of race conditions and problems that we have.  My plan is to implement these as a set once the upstart changes have been done.
[07:03] <Keybuk>  - udev-device-mapper: [approved]
[07:03] <Keybuk>  - udev-mdadm: [implemented]  with fabbione's merge of mdadm, and my upload of udev, this should be working
[07:03] <Keybuk>  - udev-evms: [pending approval - mdz]
[07:03] <Keybuk>  - udev-lvm: [pending approval - mdz]
[07:03] <Keybuk>    + I don't believe there were major concerns with the above two specs, just drafting issues.
[07:03] <Keybuk> slick boot specs: one of Mark's goals for feisty.  Fortunately there's not much "real work" here.
[07:04] <Keybuk>  - slick-boot: [pending approval  - sabdfl]  this mostly ended up as a todo list spec
[07:04] <Keybuk>  - setup-console-under-usplash: [really cjwatson's]  almost done?
[07:04] <Keybuk>  - usplash-fsck-progress: [drafting]  not yet started on this one, it's one of those things that's probably more effort to draft than it is to implement.
[07:04] <Keybuk>  - boot-messages: [drafting]  coupled with above really, needs some discussion and decisions how to implement - will land quite late in the cycle; if it misses, the edgy stuff is "good enough"
[07:04] <Keybuk>  - no-usplash-timeout: [review - cjwatson]  trivial spec just to make things more seamless
[07:04] <Keybuk>  - usplash-until-desktop: [blocked and declined]  it turns out that this isn't possible; most X drivers need to start in a text mode, otherwise they can't set the mode back when you Ctrl-Alt-F1 back later.
[07:04] <cjwatson> Keybuk: slick-boot depends on usplash-until-desktop, which can't happen, doesn't it?
[07:04] <Keybuk> replacement-initscripts: [drafting]  Spec has a draft brain storm, this one will be in flux until it's actually implemented.  Basically like streamlined-boot before; the spec will document what happened, not what's planned.
[07:04] <Keybuk> automake-transition: [deferred from edgy - implemented!]  Debian have almost finished this transition, marked it implemented as it's only half a dozen unmaintained packages that haven't been transitioned now.  Automake 1.10 FTW!
[07:04] <Keybuk> techboard-2006: [pending approval - sabdfl]  Can mdz poke him? :p
[07:04] <Keybuk> new-pci-ids: [new]  someone (mdz!) stuffed this in my queue.  the summary is bogus, it's practically impossi
[07:04] <Keybuk>  impossible to do today.  we could do this properly with some heavy kernel hackery that would give us lots and lots of wins.
[07:04] <cjwatson> Keybuk: new-pci-ids is supposed to use the new_id thing in /sys
[07:04] <Keybuk> cjwatson: I could rename it to "slickish-boot", but I can't be arsed :p  the other gains are worthwhile
[07:04] <Keybuk> cjwatson: which doesn't work
[07:04] <cjwatson> uh?
[07:05] <cjwatson> #ubuntu-devel
[07:05] <Keybuk> indeed, or read the #ubuntu-kernel log from today
[07:05] <Keybuk> this dovetails nicely with BenC's device-driver-manager thing
[07:05] <Keybuk> we both want to do the same evil thing to the kernel
[07:05] <Mithrandir> Keybuk: usplash-until-desktop> too hard to save the mode in the initramfs?
[07:05] <cjwatson> setup-console-under-usplash should land tomorrowish at which point testing would be very nice
[07:06] <cjwatson> I'll go and read up on the kernel stuff later
[07:06] <Keybuk> Mithrandir: it's an X driver thing apparently, mjg59 knows more
[07:07] <cjwatson> I think the X driver saves the registers

[07:07] <cjwatson> I browsed through replacement-initscripts briefly; the big graph melted my eyes but didn't make me scream too badly
[07:08] <cjwatson> will look again later
[07:08] <Mithrandir> cjwatson: yes, and we should (COUGH) be able to save that when usplash starts.  Might be bloody painful, though.
[07:08] <cjwatson> Keybuk: syslog-improvements?
[07:08] <Keybuk> cjwatson: not accepted for feisty
[07:08] <Keybuk> I doubt I'll have time
[07:08] <cjwatson> Keybuk: how come all the obsolete upstart specs?
[07:09] <Keybuk> not accepted for feisty
[07:09] <cjwatson> that seems like Deferred not Obsolete
[07:09] <Keybuk> and some of them make more sense under /products/upstart
[07:09] <mjg59> There's no practical way to avoid a switch to text mode before a switch to X
[07:10] <mjg59> Since otherwise X has no idea what mode to switch back to
[07:10] <cjwatson> Keybuk: thanks
[07:10] <cjwatson> I have seb128's update
[07:11] <cjwatson> specs:
[07:11] <cjwatson> * https://blueprints.launchpad.net/distros/ubuntu/+spec/easy-codec-installation: spec approved, first version of the library packaged (not uploaded yet, should be soon). Next step is waiting for gstreamer upstream
[07:11] <Mithrandir> mjg59: as I've said earlier; assuming we can easily grab that bit of code out of X, usplash could grab it and save it somewhere and X could be taught to use that.
[07:11] <cjwatson> * https://blueprints.launchpad.net/distros/ubuntu/+spec/tab-consistency:
[07:11] <cjwatson> pending approval, not started yet
[07:11] <cjwatson> * https://blueprints.launchpad.net/distros/ubuntu/+spec/desktop-slab:
[07:11] <cjwatson> pending review, package available to universe
[07:11] <cjwatson> .
[07:11] <mjg59> Mithrandir: "that bit of code" is per-driver
[07:11] <cjwatson> Done:
[07:11] <cjwatson> * started catching up on mails backlog
[07:11] <cjwatson> * got debug backtraces for a stack of edgy crashers before updating to
[07:11] <cjwatson> feisty
[07:11] <cjwatson> * started cleaning up the bugs backlog
[07:11] <cjwatson> * started on GNOME 2.17 packaging
[07:11] <cjwatson> .
[07:11] <cjwatson> To do:
[07:11] <cjwatson> * syncs with Debian
[07:11] <cjwatson> * keep catching up with bugs and mails backlog
[07:12] <rodarvus> mjg59, until we have randr 1.2, I suppose?
[07:12] <cjwatson> seb seems well enough sorted, once review happens
[07:12] <rodarvus> (which should be 7.3)
[07:12] <mjg59> rodarvus: 7.2.1 with luck, but still, no
[07:12] <cjwatson> sfllaw just got back from interviewing, and will be along in a minute
[07:12] <cjwatson> Mithrandir: next
[07:12] <Mithrandir> misc: learning the ropes as an archive team member.  Doing a few merges, been feeling ill-ish since I got home, so trying to recover.  Discussion with mdke about how to handle string changes post-stringfreeze (and in SRUs).
[07:12] <Mithrandir> specs: no progress; I haven't started working on those.
[07:12] <Mithrandir> next week: Herd 1
[07:13] <rodarvus> I thought this bit was about to be generalized into randr 1.2
[07:13] <cjwatson> installer is about two-thirds merged, but ubiquity is going to need some substantial changes for the new partman-auto, so we'll see how well things work for next week
[07:13] <cjwatson> going as fast as I can on that
[07:14] <Riddell> Mithrandir: I'm on holiday next week, I'll ask the other kubuntu developers to help with herd 1, but it may not happen for kubuntu
[07:14] <Mithrandir> Riddell: ok
[07:14] <Mithrandir> cjwatson: I'd be somewhat surprised if we manage to release on time, but I'll try.
[07:15] <cjwatson> Mithrandir: all your specs are approved with the exception of get-rid-of-etc-resolv-conf (not happening?) and grub2 (mostly there last time I checked)
[07:15] <Mithrandir> cjwatson: g-r-o-e-r-c might not be happening; I'd like to discuss it a bit in-person
[07:15] <Keybuk> Mithrandir: that name still scares the willies out of me every time I see it
[07:15] <cjwatson> might make more sense for feisty+1
[07:15] <Keybuk> Ubuntu Herd CD 1
[07:16] <Keybuk> SO WRONG
[07:16] <Mithrandir> grub2 is pending approval, I think it should be fine.
[07:16] <Mithrandir> Keybuk: you read it as Hurd?
[07:16] <Keybuk> Mithrandir: exactly
[07:16] <rodarvus> Mithrandir, FeistyReleaseSchedule doesn't mentions which day the archive will be frozen. Do you have any specific day in mind?
[07:16] <cjwatson> rodarvus: particularly with early releases, it inevitably depends on whether stuff actually works
[07:17] <cjwatson> there's no real point freezing until the installer is in place and the system at least kind of boots sometimes
[07:17] <Mithrandir> rodarvus: usually the day or two days before, but that's a per-release thing.
[07:17] <cjwatson> which I hear has been a bit rocky to date in feisty ;)
[07:17] <cjwatson> ok, thanks Mithrandir
[07:17] <rodarvus> *nods*, I was assuming "if all goes well", of course
[07:17] <rodarvus> thanks
[07:17] <cjwatson> tkamppeter: do you have anything?
[07:17] <tkamppeter> Yes.\
[07:18] <tkamppeter> Report Nov  3 - Nov 23, 2006
[07:18] <tkamppeter> FEATURES WITH ME INVOLVED:
[07:18] <tkamppeter> https://blueprints.launchpad.net/people/till-kamppeter/+specs
[07:18] <tkamppeter> UDS outcomes:
[07:18] <tkamppeter> - "Easy configuration of printer sharing" -> Accepted
[07:18] <tkamppeter> - "Replace gnome-cups-manager by printerdrake" -> Accepted
[07:18] <tkamppeter> - "Automatic download of printer drivers through the internet" -> Pending
[07:18] <tkamppeter>   Approval
[07:18] <tkamppeter> - "Automatic hotplug printer configuration" -> Waits for draft by pitti
[07:18] <tkamppeter> Had no sessions on UDS:
[07:18] <tkamppeter> - "PPDFileStructureSpecification" -> Fixes on Foomatic done to avoid
[07:18] <tkamppeter>   duplicate or unusable entries, new FHS extension for printer drivers
[07:18] <tkamppeter>   and PPDs (in LSB 3.2) assures that also third-party drivers and PPDs
[07:18] <tkamppeter>   integrate well
[07:18] <tkamppeter> - "applications-printing" -> Common printing dialogs and interfaces are
[07:18] <tkamppeter>   worked out by Portland and OpenUsability projects, so no application
[07:18] <tkamppeter>   hacking for Ubuntu recommended, will appear at the earliest in Feisty+1.
[07:18] <tkamppeter> - "Make PDF "Printer" functionality for CUPS as default" -> Not much missing
[07:18] <tkamppeter>   for implementing it, best is to report appropriate bugs against the
[07:18] <tkamppeter>   cups-pdf package.
[07:18] <tkamppeter> DONE:
[07:18] <tkamppeter> - Submitted foomatic-db_20061122-0ubuntu1: Fixes bug 19437, bug 39847,
[07:18] <Ubugtu> Malone bug 19437 in foomatic-db "OKIPage 4W printer problems" [Medium,Fix released]  http://launchpad.net/bugs/19437
[07:18] <Ubugtu> Malone bug 39847 in ubuntu-meta "ubuntu-desktop should depend on linuxprinting.org-ppds for PostScript PPDs" [Medium,Fix committed]  http://launchpad.net/bugs/39847
[07:18] <tkamppeter>   bug 49805, bug 51944, bug 64238, bug 70425, bug 71871, and several bugs
[07:18] <Ubugtu> Malone bug 49805 in foomatic-db "PPD for LaserJet 6MP does not have an option for auto tray selection" [Medium,Fix released]  http://launchpad.net/bugs/49805
[07:18] <Ubugtu> Malone bug 51944 in foomatic-db "Brother MFD8820 driver is not present" [Low,Fix released]  http://launchpad.net/bugs/51944
[07:18] <tkamppeter>   reported on http://forums.linuxprinting.org/
[07:18] <Ubugtu> Malone bug 64238 in foomatic-db "HP 4240 and 4250 ppd files appear to have syntax errors" [Low,Fix released]  http://launchpad.net/bugs/64238
[07:18] <Ubugtu> Malone bug 70425 in foomatic-db "Default driver for Samsung ML-1750 is not "perfect"" [Low,Fix released]  http://launchpad.net/bugs/70425
[07:18] <tkamppeter>   In addition, printer setup tools with direct CUPS support (KDE Printing
[07:18] <Ubugtu> Malone bug 71871 in foomatic-db "Kyocera Mita FS-1010 driver is perhaps incorrect" [Medium,In progress]  http://launchpad.net/bugs/71871
[07:18] <tkamppeter>   Manager, foomatic-gui, and system-config-printer AFAIR) will not show
[07:19] <tkamppeter>   entries for drivers with empty command line prototype.
[07:19] <tkamppeter> - Submitted foo2zjs_20060625dfsg-4ubuntu1: Fixes bug 65618
[07:19] <Ubugtu> Malone bug 65618 in foo2zjs "Firmware upload to LJ 1000/1005/1008/1020 broken (fix to be proposed as Edgy update)" [Medium,Fix committed]  http://launchpad.net/bugs/65618
[07:19] <tkamppeter> - Submitted foo2zjs_20060625dfsg-2ubuntu2: Fixes bug 65618 in Edgy
[07:19] <tkamppeter> - Answered to bug reports
[07:19] <tkamppeter> Ubugtu? Where are you?
[07:19] <tkamppeter> linuxprinting.org-ppds is split into linuxprinting.org-ppds (3.5 MB) and linuxprinting.org-ppds-extra (10MB) now, so the most important manufacturer PPDs can go onto the Feisty desktop CDs as linuxprinting.org-ppds. Ready for assessing size increase and putting into the appropriate seeds.
[07:20] <pitti> yay PPD file split :)
[07:20] <cjwatson> pitti is unlikely to have time to work on automatic-printer-conf, from the sounds of things earlier
[07:20] <pitti> tkamppeter: for the record, the package is uploaded, should sit in NEW now
[07:20] <pitti> cjwatson: well, I won't have much time to work on printerdrake code/gui, and we need that for automatic-printer-conf
[07:21] <pitti> a-p-c itself is not much work then (just some g-v-m integration)
[07:22] <pitti> for printerdrake, I have some community members in mind which might want to help
[07:22] <pitti> (ivoks, Kagou)
[07:22] <cjwatson> tkamppeter: re 65618, I think it would be useful if you could please try not to use "tested in Mandriva 2007" as a justification - it doesn't correlate well with working in Ubuntu, particularly in areas like udev that differ a fair bit between distributions
[07:22] <tkamppeter> pitti, I have seen that foomatic-db is uploaded, therefore I have closed the bugs. What is missing is that a person with appropriate rights adds linuxprinting.org-ppds to the seeds for the desktop CDs.
[07:22] <Ubugtu> Mandriva bug 2007 in Installation "Switching to alternate screens during install crashes X" [Normal,Resolved: fixed]  http://qa.mandriva.com/show_bug.cgi?id=2007
[07:23] <pitti> tkamppeter: I thought that was already shipped?
[07:23] <cjwatson> tkamppeter: 65618> note that you must upload to edgy-proposed, not edgy
[07:23] <cjwatson> see http://wiki.ubuntu.com/StableReleaseUpdates
[07:24] <tkamppeter> pitti, unfortunately, the PPDs did not make it onto the Edgy desktop CDs, there was some confusion.
[07:24] <cjwatson> tkamppeter: "appropriate rights" => ubuntu-core-dev
[07:24] <sfllaw> tkamppeter: I think we had a discussion about this during UDS.
[07:24] <sfllaw> tkamppeter: Please follow StableReleaseUpdates and all will be good.
[07:24] <cjwatson> ok, we're running short on time; further printing discussion => #ubuntu-devel
[07:24] <cjwatson> sfllaw: anything from you?
[07:24] <sfllaw> Done:
[07:24] <sfllaw>  * Specs:
[07:24] <sfllaw>   - bug-workflow: Done with input from mpt and bjorn and sabdfl
[07:24] <sfllaw>   - scalable-installation-testing: Worked with pitti.  Need to spec out UI bits, but that's something I can do this weekend.
[07:24] <sfllaw>  * Verification
[07:24] <sfllaw>   - xorg: Done
[07:25] <sfllaw>   - vino: Doing it now
[07:25] <sfllaw>  * Interviewed intern candidates.
[07:25] <sfllaw> To do:
[07:25] <sfllaw>  * More verification, since -proposed has stuff waiting.
[07:25] <sfllaw>  * Review interviewees and pick [0-2] .
[07:25] <sfllaw>  * Bug triage
[07:25] <fabbione> sfllaw: did you get my mail about lvm2/clvm?
[07:25] <fabbione> (SRU dapper/edgy)
[07:25] <sfllaw> fabbione: I didn't specifically notice it.  Is it tagged verification-needed?
[07:25] <sfllaw> If so, it will show up on my todo list.
[07:25] <sfllaw> Is it also a priority?
[07:25] <fabbione> sfllaw: yes the bug is
[07:25] <cjwatson> sfllaw: sorry about the vast influx into *-proposed
[07:26] <sfllaw> Well, it could have been worse.
[07:26] <fabbione> sfllaw: i followe SRU and mailed you
[07:26] <cjwatson> I think I've largely cleared the queue now, with the exception of a few more recent requests
[07:26] <sfllaw> Then I will get to it in order.
[07:26] <sfllaw> Important things I will do first, if you ping me about them.
[07:26] <cjwatson> although I haven't yet gone through everything that the SRU team is subscribed to, and there's openoffice.org coming next week
[07:27] <sfllaw> That's going to be a fun one.
[07:27] <sfllaw> Any other questions?
[07:27] <cjwatson> I've been telling all submitters to contact you after accepting their uploads
[07:27] <cjwatson> ok, thanks
[07:27] <cjwatson> zul: anything from you?
[07:28] <zul> this week:
[07:28] <zul> - amd64 xen fixing
[07:28] <zul> - porting paravirt-ops
[07:28] <zul> - kernel monkey collecting patches
[07:28] <zul> next week:
[07:28] <zul> - merges
[07:28] <zul> - testing paravirt-ops
[07:28] <zul> - kernel monkey
[07:28] <zul> specs:
[07:28] <zul> * xen-fiesty - pending approval - need to update spec to mention paravirt-ops
[07:28] <cjwatson> porting paravirt-ops> does that assume that we're going with 2.6.19 rather than 2.6.20? I understood that if we went with 2.6.20 we got it for free
[07:29] <zul> yes 2.6.20 should have it
[07:29] <zul> 2.6.19 is for me to test it and get acquainted with it
[07:29] <cjwatson> ok
[07:30] <cjwatson> right, any other business?
[07:30] <zul> also if something breaks on the xen side the theorty is we can get it fixed quite quickly
[07:30] <cjwatson> going once
[07:30] <cjwatson> going twice
[07:31] <Keybuk> WAIT!
[07:31] <Keybuk> just kidding
[07:31] <cjwatson> adjourned. Remember everyone, all specs for feisty to be approved by next Thursday.
[07:31] <pitti> thanks all!
[07:31] <mvo> thanks everyone
[07:32] <fabbione> thanks *