[00:33] <kees> mvo: say, I was just doing a gutsy->hardy upgrade (in kvm) and didn't have enough disk space.  each time I made enough room, the next run of update-manager claimed to need more space than before.  I've since started tracking the log output, and I'll file a bug report for it, but was curious if you'd seen anything like that before?
[00:35] <mvo> kees: no, suprisingly little bugreport from the space calculator (I guess everybody has 750gb hdds there days :P) - how much do you free? is that a complicated setup with lots of partions?
[00:36] <kees> mvo: nope, just 1 partition for everything.  I think the issue is that it aborts immediately, rather than finishing all the calculations?
[00:36] <mvo> kees: that sounds plausible
[00:38] <kees> mvo: yeah, that seems to be it.  in the fail-cases, it would examine /var/cache/... then /usr and fail with an ever-growing "need" value.  in the final success case checks /var/cache/..., /usr, /usr again (?), /boot, and /
[00:39] <mvo> kees: right, makes sense. please file a bug and tag it later, I will try to attack it early. or do you think we should fix it for hardy?
[00:39] <mvo> kees: it checks /usr twice for simplicity reasons (once for real, once with some safety buffer)
[00:40] <kees> mvo: it's not a show-stopper, but it was a bit of a head-scratcher.  "what? you need MORE space now?" after I cleaned up how much it wanted.  ;)
[00:40] <kees> I'll tag it later.  :)
[00:41] <mvo> kees: ok, I'm too tired to look into it now, but if its a one-liner patch, we can try to sneak it past
[00:41] <kees> mvo: sure, no problem.  I wasn't actually expecting you to answer right now.  :)
[00:42] <mvo> kees: still some loose ends that needs attention here and there, but I should go to bed soonish
[01:34] <crimsun> asac: I believe https://bugs.launchpad.net/ubuntu/hardy/+source/libflashsupport/+bug/192888/comments/75 addresses your rationale question.
[01:46] <Caesar> Umm, so it seems that update-manager-core is at 1:0.87.21 but update-manager is at 1:0.87.18
[01:46] <Caesar> How does that even happen?
[01:46]  * Caesar pokes at Launchpad
[01:47] <slangasek> Caesar: 1) upload 500 arch: all langpacks for rebuild, swamping the i386 buildd; 2) upload update-manager, which builds arch: any and arch: all packages; 3) run amd64
[01:48] <Caesar> That'll do it
[01:49] <Caesar> slangasek: packages will go in with unmet dependencies post-build though?
[01:50] <slangasek> yes
[01:50] <slangasek> there's no check for installability at binary accept time
[01:51] <Caesar> slangasek: that seems like a bug to me
[01:52] <slangasek> well, enforcing installability at binary accept time would be a good way to deadlock development
[01:52] <Fujitsu> It'd make transitions completely impossible.
[01:52] <slangasek> it's annoying that we have langpacks ahead of update-manager in the build queue, and that's certainly a bug
[01:55] <slangasek> (doubly annoying that it's been done right after RC, so people are going to see partial-upgrade issues until it clears)
[01:56] <Caesar> We were just questioning the whole point of a RC that then subsequently gets upgraded
[01:56] <Caesar> It makes all milestones very ephemeral
[01:56] <Fujitsu> Aren't langpacks meant to be built on PPAs.
[01:56] <Fujitsu> *?
[01:56] <Fujitsu> Caesar: You haven't seen an RC that isn't an RC until you've seen MPlayer RCs.
[01:57] <slangasek> Fujitsu: langpacks are part of the archive, so no?
[01:57] <Fujitsu> slangasek: They're built in PPAs and binary-copied for every other release - why not Hardy?
[01:57] <slangasek> they are?
[01:57] <Fujitsu> They are.
[01:57] <Fujitsu> Or we'd be utterly screwed.
[01:58] <Caesar> Fujitsu: but a RC for a single piece of software is versioned and static, whereas a milestone for Ubuntu is only current until someone makes an upload, or you don't point it at an external repository
[01:58] <slangasek> Fujitsu: well, this must be a fairly new innovation, seeing how PPAs have only been around for about a release cycle
[01:59] <Fujitsu> slangasek: Correct.
[01:59] <Caesar> slangasek: could the building of arch: all packages be load-balanced across all architecture buildds?
[02:00] <Fujitsu> I think you just gave cprov a heart attack.
[02:02] <slangasek> Caesar: in theory it could; you would basically have to set up a whole set of secondary queues though, to tell the buildds whether or not they're expected to build with -B or -b
[02:02] <slangasek> Caesar: and then you have the fun of finding out at random which arch: all packages are only buildable on i386
[02:02] <Caesar> slangasek: that'd help flush out some bugs wouldn't it?
[02:04] <slangasek> nah, it would just cause more build failures of the sort plaguing openhackware; there are packages that need to build as arch: all, but simply require a toolchain for one particular arch to do their building
[02:04] <slangasek> and up to now, it's been safe to assume that this will work when that "one particular arch" is i386
[02:06] <slangasek> anyway - it wouldn't be impossible to load balance them better, but giving langpacks a lower build priority would seem to address the issue more directly
[02:07] <slangasek> since it's the only thing we have that causes a batch of arch: all packages to flood the buildds and cause vastly disparate times-to-build between different archs
[02:09] <Fujitsu> Except for the initial autosync, but only a few people use it in the first couple of weeks of the cycle.
[02:09] <slangasek> sure
[02:40] <nxvl> bdmurray: around?
[02:50] <TheMuso> crimsun: I thought pulseaudio_dmix == bad;
[02:50] <TheMuso> s/pulseaudio_dmix/pulseaudio + dmix/
[04:24] <bdmurray> nxvl: I am now
[04:38] <crimsun> TheMuso: well, yes, it certainly isn't optimal.  However, is having it grab the raw hardware worth the regressions?
[04:39] <TheMuso> crimsun: Thats what I've started thinking lately myself.
[04:55] <lamont> interestingly, hardy does _OK_ on a P2-233 with 192MB of RAMand a 6GB HDD
[04:55] <jdong> lamont: not too surprised
[04:55] <jdong> I'm playing FreeBSD BDSM right now
[04:55] <jdong> with a 48MiB RAM VM
[04:55] <lamont> it's the print server for the house
[05:21] <tuntun> Why on earth do I have do a search for file 'foo' before I get the chance to configure the search?!?!
[05:28] <tuntun> Main-menu > Accessories > Tracker-Search-Tool   ...Who the hell thought that It would be a good idea to only let the user configure the search after having done a first search?!?!
[05:30] <beuno> why am I seing double?
[05:34] <tuntun> Main-menu > Accessories > Tracker-Search-Tool   ...Oh great... And it it only searches within the home dir...without even telling you!!! This is turning into a farce...
[05:38]  * lamont looks around for someone who loves hacking on compiz
[05:51]  * lamont is reminded of just how thoroughly he hates quilt and all of its ilk
[08:49] <salty-horse> bryce, here?
[11:40] <jpatrick> elmo: I think a bit got cut off at the end
[11:49] <elmo> jpatrick: it did, but my bit is at the front ;-)
[11:49] <elmo> jpatrick: I'll restore the end when I take it out
[12:19] <Idan> Hey all, God a question about version numbers... If I recall correctly older version of Ubuntu (5.04, 5.10) wouldn't change the version numbers of software after release, I noticed that in 7.10 (can't remember other ones), the version numbers did change, for example Firefox 2.0.x
[12:19] <Idan> God=Got
[12:20] <Idan> Anyone here?
[12:21] <jpatrick> elmo: yes, yours is far more important ;)
[12:21] <Fujitsu> Idan: In very few circumstances will new versions be uploaded.
[12:21] <Fujitsu> Firefox is one of those.
[12:30] <asac> crimsun: so if i understand this correct, this pulseaudio change should have been done right from the beginning?
[12:38] <asac> TheMuso: could you please look at the latest patch in bug 192888?
[12:38] <ubotu> Launchpad bug 192888 in libflashsupport "firefox crashes on flash contents" [High,Confirmed] https://launchpad.net/bugs/192888
[12:39] <ogra> asac, i'm running it like that since last night (when i saw crimsuns ping)
[12:39] <asac> ogra: where is that config file? i don't have that ;)
[12:39] <ogra> sound seems to be good here but it will likely not work on all non dmix capable cards
[12:40] <ogra> and somehow fullscreen mode for flash movies flips immediately back to win mode now (might not be related)
[12:40] <asac> ogra: "Applying it makes pulseaudio use the 'default' ALSA virtual device, which is dmixed and dsnooped for nearly all audio cards"
[12:40] <ogra> aa/etc/pulse/default.pa
[12:40] <ogra> oops
[12:40] <ogra>  /etc/pulse/default.pa
[12:40] <asac> ogra: i see that path, but i don't have it ;)
[12:41] <ogra> but you have pulse installed ?
[12:41] <asac> i only have client.conf in there
[12:41] <ogra> th epulse server package creates it iirc
[12:41] <ogra> ogra@osiris:~$ dpkg -S /etc/pulse/default.pa
[12:41] <ogra> pulseaudio: /etc/pulse/default.pa
[12:42] <ogra> the fulscreen thing is worrying
[12:42] <asac> oh i think on this machine really removed it at some point ;)
[12:44] <asac> ogra: so why would a virtual also device break anywhere?
[12:44] <ogra> ??
[12:44] <ogra> why should it ?
[12:44] <ogra> you mean dmix
[12:44] <ogra> i think
[12:47] <asac> ogra: what does dmix do?
[12:47] <ogra> err, why doesnt FF allow me to put search termes into the url field ??
[12:47] <asac> isn't that a software layer?
[12:47] <ogra> XML-Verarbeitungsfehler: Fehler beim Verarbeiten einer Referenz auf eine externe Entität
[12:47] <ogra> Adresse: jar:file:///usr/lib/xulrunner-1.9b5/chrome/toolkit.jar!/content/global/netError.xhtml
[12:47] <ogra> Zeile Nr. 10, Spalte 3:  %netErrorDTD;
[12:47] <ogra> --^
[12:47] <ogra> meh
[12:47] <ogra> grr
[12:47] <asac> ogra: yeah langpack bustage
[12:48] <ogra> ah
[12:48] <asac> error page is currently broken
[12:48] <ogra> afaik older cards (typically sb driver) dont support it
[12:49] <asac> so dmix does hardware mixing?
[12:49] <ogra> http://alsa.opensrc.org/index.php/FAQ#What.27s_all_this_dmix.2Fdshare.2Fdsnoop.2Fasym_stuff.3F_How_does_it_work.3F
[12:49] <ogra> no
[12:50] <ogra> but afaik you need a certain amount of channels to plug dmix on top
[12:51] <asac> crimsun: ^^ could you comment on this?
[12:51] <ogra> and things like esd apps will be able to hog the device directly
[12:51] <ogra> or libesd
[12:52] <ogra> i know pitti did some deep research some releases ago
[12:52] <asac> yeah, but maybe thats outdated now
[12:52] <asac> at least the tiny details :)
[12:53] <ogra> well, we're discussing principles and processes, not details atm :)
[12:54] <asac> ogra: NOTE: For ALSA 1.0.9rc2 and higher you don't need to setup dmix. Dmix is enabled as default for soundcards which don't support hw mixing.
[12:54] <asac>  * requires creation of a virtual slave device
[12:54] <asac> http://alsa.opensrc.org/index.php/Dmix
[12:54]  * ogra reads
[12:55] <asac> for me this sounds like dmix was created for devices that are dump :)
[12:55] <asac> dumb
[12:55] <ogra> right
[12:56] <asac> yeah ... so why would this "new" virtual alsa device break for some cards?
[12:56] <ogra> so you want to default to asoundrc for that ?
[12:57] <ogra> as i understood it in the past you need a certain amount of channels to have a dmix capable card which isnt the case for very old HW
[12:57] <ogra> (soundblaster 16capable cards)
[12:58] <ogra> but that might be outdated info
[12:58] <asac> ogra: yes right, but i don't see that anywhere on that dmix page :(
[12:58] <ogra> i'm probably behind wih my knowledge
[12:58] <ogra> but even then that looks quite horrible to get right in the asoundrc
[12:59] <asac> ogra: i don't want users to be required to edit their own asoundrc ... thats for sure
[13:00] <ogra> especully tha "KDE - Still Hearing Stuttering? " part
[13:00] <ogra> i'm a bit scared
[13:00] <ogra> there are o many options and it doesnt look like there is a common reciepe that works with all aps and in all cases
[13:01] <ogra> *apps
[13:01] <ogra> we only have until wednesday
[13:02] <laga> what was the situation regarding dmix before pulseaudio?
[13:02] <laga> eg in 7.10
[13:02] <asac> i don't know ... actually i don't think that its a regression that sound is not working :)
[13:02] <ogra> its enabled by default in the modules, i think that wasnt different in gutsy
[13:02] <ogra> the configuration is the prob
[13:02] <asac> i never could play multiple streams from multiple apps out of the box here at least
[13:02] <ogra> sound is working everywhere
[13:03] <laga> asac: oh, that's sad. that has always worked for me
[13:03] <ogra> apart from flash under certain circumstances
[13:03] <asac> well, in the past i had to disable ESD because soudn wasn't working properly.
[13:03] <ogra> asac, upgraded or plain hardy install ?
[13:03] <laga> sound servers are evil anyways. (imho)
[13:03] <ogra> my laptop has a two week old install and worked just fine from the beginning
[13:04] <asac> ogra: read above ... i talked about regressions ;)
[13:04] <ogra> (apart from teh flash issue)
[13:04] <asac> before hardy it was always not really working here
[13:04] <ogra> well, pulse is classes better indeed
[13:05] <asac> right, but we need to care for apps that don't use pulse as well
[13:05] <ogra> but imho we should revert to gutsy setup
[13:05] <ogra> the puse setup we have atm wasnt really deeply looked at
[13:05] <ogra> *nobody* during this cycle did *any* sound research
[13:06] <ogra> we just blindly dumped in pulse as replacemet for esd
[13:06] <asac> yeah ... and we got plenty of changed software
[13:06] <ogra> gutsy is known to work ....
[13:06] <ogra> or at least has *known* bugs
[13:07] <asac> ogra: known to work for whom? for me it didn't work well ... but thats what i say, if really dumb cards stop working that didn't work in gutsy, then its not a regression IMO
[13:07] <asac> but making flash have no sound for setups that previously had sound is pretty bad :/
[13:08] <ogra> well, for me it always worked, ,i never had sound probs on any HW with an ubuntu over here ... but then i only use default apps
[13:08] <ogra> *any Ubuntu
[13:08] <ogra> (and pulse on my ltsp terminals)
[13:08] <ogra> (since edgy)
[13:09] <ogra> with a virtual asla device on top
[13:09] <ogra> *alsa
[13:09] <ogra> which i would suggest for us here as well, but that brings libflashsupport back into the loop
[13:09] <asac> ogra: but isn't that exactly what crimsun suggests?
[13:09] <ogra> which we dont want
[13:10] <ogra> no
[13:10] <asac> no we cannot use libflashsupport, please scratch that
[13:10] <ogra> my setup is the other way round (and pulse isnt running in the user session)
[13:11] <ogra> pulse is just providin the network port on my clients, in the session there is an asoundrc that defines a virtual alsa device connecting to the network port pulse offers on the client
[13:12] <ogra> asac, everything wil work fie without any soundserver .... apart fro login and logout sounds
[13:13] <ogra> and gnome event sounds (which we dont enable at all)
[13:14] <ogra> pitti had a hack to gnome_sound_play in the past that made it use alsa in the back
[13:15] <ogra> which worked fine for only login/out sounds but started to stutter if other sounds are played
[13:15] <asac> ogra: yeah so lets kick pulse :)
[13:15] <ogra> and lose login/out sounds ?
[13:16] <asac> use gnome_sound_play hack?
[13:16] <ogra> ask pitti about it how sane it is
[13:16] <jeromeg> asac: that would be funny as pulseaudio has been advertised as one of the major new feautres of hardy
[13:17] <ogra> in any case we need a spec for intrepid
[13:17] <ogra> jeromeg, and ?
[13:17] <ogra> we can change that
[13:17] <laga> change it 5 days before release?
[13:18] <ogra> laga, vs releasing with boken sound and no flash sound support ?
[13:18] <jeromeg> ogra: I personally don't care, but changing things that have been planned for 6 monthes 5 days before the release looks weird to me
[13:18] <ogra> jeromeg, the pro is that it wasnt planned
[13:18] <ogra> we blindly followed upstream
[13:18] <jeromeg> upstream ?
[13:18] <asac> gnome
[13:18] <ogra> relying on the fact that they know what they do and that it just works
[13:18] <jeromeg> ok
[13:19] <ogra> which it doesnt
[13:19] <asac> ogra: so whats bad about crimsums suggestion? that it breaks old cards? whatelse? is there stuttering?
[13:19] <ogra> no here, no
[13:20] <ogra> i dont know where that fullscreen issue comes from
[13:20] <ogra> i discovered it before going to bed last night, need to check that more
[13:20] <ogra> s*not here
[13:21] <ogra> it might break ltsp if we go with a per user asoundrc
[13:21] <ogra> so that must be a global setup
[13:23] <ogra> asac, given that crimsun is the most knowledgeable person here i tend to trus his expertise
[13:23] <ogra> especially with the coments about the upgrade scenarios
[13:25] <asac> ogra: fulll screen issue?
[13:25] <ogra> i cant switch flash videos to fullscreen
[13:26] <ogra> they snap back after a second
[13:26] <asac> ogra: i am currently testing that setup and what i see is that videos dont run as swift as they should when i play flash in the background
[13:26] <laga> i wonder why a change in sound setup would break fullscreen mode of adobe's crapware. ogra, steps to reproduce?
[13:27] <asac> i doubt it does
[13:27] <ogra> laga, apply the pulse change (i rebooted then to make sure to have a clean system) swithca flesh movie in youtube to fullscreen while playing
[13:27] <ogra> asac, well, it started to show up after i made the pulse change to test it
[13:27] <asac> ogra: works here :)
[13:28] <asac> and i have a huge screen here ;)
[13:28] <ogra> weird
[13:29] <ogra> works here as well now
[13:29] <asac> good :)
[13:31] <ogra> i wonder wat that was
[13:31] <ogra> it flipped back immediately after the "perss esc to leave fullscreen" mgs disapeared
[13:32] <ogra> *press
[13:33] <ogra> asac, upload it then
[13:34]  * ogra is hoping for a fixed libflashsupport for 8.04.1 anyway .... 
[13:34] <ogra> ltsp doesnt leave me a big choice here
[13:34] <laga> why does http://www.ubuntu.com/community/ubuntustory/components say that main contains non-free components? does that make sense when they could just be shoved into restricted?
[13:35] <ogra> laga, firmware
[13:35] <laga> ogra: isn't that usually in l-r-m?
[13:36] <ogra> The licences for software applications in main must be free, but main may also may contain binary firmware and selected fonts that cannot be modified without permission from their authors. In all cases redistribution is unencumbered.
[13:37] <ogra> intel drivers are 100% free but the firmware still eeds to be a binary blob
[13:37] <ogra> for example
[13:38] <laga> ogra: i've always thought of main as a set of software i can modify the way i want and redistribute them freely, w/o having to be careful with the license. i guess i was wrong
[13:38] <laga> oh well, i'm not going to do modify firmware anyways
[13:38] <ogra> laga, thats gobuntu :)
[13:39] <laga> heh
[13:39] <ogra> ubuntu has the commitment to make HW work where possible ....
[13:40] <laga> ogra: yes, and l-r-m plays an important role there. looking at l-r-m, it also contains a lot of firmware for DVB devices (where the drivers are free), so i don't see why some firmware gets the special 'main' treatment. are there some substantial differences in the license of those blobs?
[13:41] <ogra> i'd guess so
[13:41] <ogra> i'm by no means a licensing expert :) i trust our archive admins here
[13:43] <laga> neither am i.
[13:43] <laga> i talked to the gobuntu guys once  and they even removed init routines in some dvb drivers which upload a few bytes of binary stuff
[13:45] <ogra> yeah
[13:46] <ogra> asac, oh, btw did you test sound recording and input methods with the change ? would be odd if microphones stopped working
[13:46] <ogra> (hardy is teh first time i had a working mic out of teh box right after install on any of my ubuntu machines)
[13:47] <asac> ogra: i am completely the wrong person to deal with this i guess :) .. i don't even have a microphone ;)
[13:47] <ogra> you have a laptop
[13:47] <asac> hmm ... the old one i had never had working sound (except with debian etch)
[13:47] <ogra> perfect
[13:47] <asac> the new one ... no idea if it has a mic ;)
[13:48] <asac> ogra: ?
[13:48] <ogra> test the old one :)
[13:48] <asac> well i tested it recently ... hardy still doesn't help
[13:48] <ogra> if that works the fix *must* be safe :P
[13:48] <asac> hehe
[13:48] <asac> yeah, but i guess sound is still not working
[13:49] <ogra> sound recorder seems to work for me
[13:50] <asac> ogra: i am now tuning alsamixer tMic channel ... where can i see if i get any signal?
[13:50] <ogra> asac, oh, btw if ou find a chance to test the last classmate image before release that would be very appreciated (especially suspend/resume)
[13:50] <asac> ah sound recorder
[13:50] <ogra> you probably need to unmute the mic input
[13:50] <asac> yeah did that in alsamixer
[13:50] <ogra> in volume control
[13:51] <ogra> and select the right input source in sound recorder
[13:51] <ogra> the default often doesnt work i found
[13:51] <asac> ok
[13:52] <asac> no luck ;)
[13:52] <asac> tried all suggested inputs
[13:52] <asac> and have microphone unmuted and boosted
[13:53] <asac> but thats without the changed pulseaudio thing
[13:53] <ogra> check the setup in your volume control
[13:53] <ogra> it often has recording sources disable you need to swithc or unmute
[13:54] <asac> well. i unmuted the mic there and boosted it ... no other device offers microphone so it should be right
[13:54] <ogra> i have about 10 different input devices i can enable in the voume control settings
[13:55] <ogra> and i need to unmute aux alongside the mic on this machine
[13:55] <asac> uaa ... i got "rueckkopplung" :)
[13:55] <ogra> yay
[13:55] <ogra> turn it down a bit :)
[13:55] <asac> i better leave that alone :(
[13:55] <laga> 'feedback loop'?
[13:55] <ogra> yeah
[13:55] <ogra> that means its working :)
[13:56] <ogra> just to sensitive
[13:56] <laga> ah, just 'feedback'
[13:56] <ogra> getting that configured right will be a challenge in next ltsp release  :)
[13:57] <ogra> localapps and sound capture are on my list of desired things to have for intrepid
[14:18] <Hobbsee> yay, power outage.
[14:19] <laga> yay, no backup generators (?)
[14:19] <Hobbsee> jcastro: got time for a chat, at some point?  (not overly time critical - after release is fine)
[14:19] <Hobbsee> laga: fairly safe to say that some of the machines are on
[14:19] <stgraber> laga: 1/3 of the builders are still up
[14:20] <laga> okay, s/no/&t enough/ ;)
[14:32] <crimsun> asac: the default pulseaudio config (that grabs raw hardware directly) is preferable with the intent of having libflashsupport pulled in directly with flashplugin-nonfree
[14:33] <crimsun> asac: in light of that latter change to flashplugin-nonfree, not changing the pulseaudio config to match does break existing setups
[14:33] <crimsun> asac: so, no, the pulseaudio change I mentioned earlier should not have been implemented right from the start
[14:34] <crimsun> asac: it is only a stop-gap measure to prevent further regressions from dapper(, edgy, feisty,) and gutsy
[14:36] <Whoopie> mjg59: Hi, I have a question with ejecting the bay on my thinkpad. your implementation is now used with ata_piix and not the bay kernel module. How can I call a script to unmount the drive (hdd/cd) before ejecting?
[14:56] <asac> crimsun: i tested this setup and now i have problems like the second application that uses sound stutters. do we need to tune anything else to make this behave better?
[14:56] <asac> like buffers or something?
[14:57] <crimsun> asac: what are the first and second applications?
[14:57] <asac> crimsun: doesn't matter.. i tried 1st RB and 2nd flash ... and vice-versa
[14:57] <asac> also tried totem + flash
[14:58] <asac> and flash + totem :)
[14:58] <crimsun> asac: well, that symptom can be worked around by manually creating an asoundrc, and it's one reason the default for PA was not to use dmix/dsnoop
[14:59] <crimsun> asac: the problem is that we can't create an asoundrc for all users that will work for all audio cards
[14:59] <asac> so its not buffer related?
[14:59] <crimsun> asac: not necessarily buffer-related, no.
[15:00] <crimsun> asac: so now that you've established that, on your setup, native ALSA and native PulseAudio stutter, can you establish that concurrent native ALSA and/or concurrent native PulseAudio also stutter?
[15:01] <crimsun> (e.g., multiple instances of `aplay /usr/share/sounds/*up.wav' for the former, multiple instances of `paplay /usr/share/sounds/*up.wav' for the latter)
[15:01] <asac> crimsun: can't i set alsa as output in gstreamer-properties?
[15:01] <asac> and start multiple totems?
[15:02] <crimsun> asac: sure, although I was attempting to eliminate the GSt layer directly for that test
[15:03] <asac> ok
[15:04] <asac> crimsun: multiple aplay worked fine
[15:04] <asac> crimsun: actually i am not sure that the sound stuttered ... it was rather that the video got stuck
[15:04] <asac> except for flash which halted completely temporarily
[15:05] <asac> multiple paplay and aplay appear to work properly
[15:07] <crimsun> ok, so the next step would be to use multiple gst-launch-0.10es with alsasink and pulsesink
[15:14] <asac> crimsun: for pulsesink i get bad pipeline error
[15:14] <asac> gst-launch-0.10 audiotestsrc ! audioconvert ! audioresample ! pulsesink
[15:16] <asac> strange that it worked at all ... gstreamer pulse wasn't installed
[15:21] <highvoltage> http://www.zoitz.com/archives/35
[15:57] <bigon> infinity: are you around? bug 217432 has been approuved by motu-release, will you build the pkg?
[15:57] <bigon> bug #217432
[15:57] <ubotu> Launchpad bug 217432 in openhackware "Please sync openhackware 0.4.1-3 from debian unstable" [Undecided,Confirmed] https://launchpad.net/bugs/217432
[16:01] <crimsun> asac: looks like we need to pass device explicitly for module-alsa-{sink,source} in /etc/pulse/default.pa
[18:14] <asac> crimsun: which device?
[18:51] <ScottK> If there are any buildd admins about ...  clamav in dapper backports just failed with "ntpdate[4480]: no server suitable for synchronization found" for powerpc, ia64, sparc, and hppa.
[18:51] <ScottK> I'd appreciate a giveback or fixing the problem + a giveback as needed.
[18:53] <ScottK> Looks like the same problem for Hardy too, which makes it a little more urgent ...
[18:54] <laga> maybe related to the buildd outdate?
[18:54] <laga> outagE*
[18:54] <james_w> ScottK: it seems to be many packages then.
[18:54] <ScottK> Yes.  Same 4 archs.
[18:54] <ScottK> laga: What buildd outage?
[18:54] <laga> Reduced buildd service till 3pm UTC due to power outage
[18:54] <laga>  /topic
[18:55] <ScottK> OK, except that would have been over 3 hours ago.
[18:55] <laga> yeah, but i wonder why nobody reset the topic
[18:55] <laga> ok, ok.
[18:55] <elmo> ScottK: link to the failed build?
[18:56] <ScottK> elmo: here's one; http://launchpadlibrarian.net/13579444/buildlog_ubuntu-dapper-hppa.clamav_0.92.1%7Edfsg2-1.1%7Edapper1_CHROOTWAIT.txt.gz
[18:56] <elmo> ScottK: at the LP level, if you have it
[18:56] <ScottK> elmo: How about https://launchpad.net/ubuntu/+source/clamav/0.92.1~dfsg2-1.1/+build/566097
[18:58] <ScottK> elmo: I can give you 8 if you want it (same package on hardy and dapper-backports for 4 archs each release.
[18:58] <elmo> it's fine, I'll go through the buildd history
[19:07] <elmo> right, I think I've reset them all
[19:07] <elmo> but I'm trying to do it through the web ui and that's pretty painful
[19:07] <elmo> if I missed anything, feel free to yell
[19:07] <ScottK> Thanks.
[19:08] <ScottK> elmo: kde-guidance on powerpc looks to have the same problem.
[19:08] <james_w> elmo: does that include other packages?
[19:08] <elmo> all == all packages on all buildds
[19:08] <elmo> that got bitten by the ntpdate thing
[19:09] <james_w> great, thanks.
[19:10] <ScottK> elmo: Great.  I'll wait a bit then and see if anything looks to be left hanging.
[19:12] <ScottK> lamont: Would you have a moment to look at an hppa specific build failure?
[19:12] <lamont> sure
[19:13] <ScottK> It's devscripts.
[19:13] <ScottK> I'm getting the build log link.
[19:13] <lamont> np
[19:13] <ScottK> lamont: https://launchpad.net/ubuntu/+source/devscripts/2.10.11ubuntu5/+build/564980
[19:14] <lamont> ScottK: either ntp yanked time forward 2.5ish hours (doubtful), or the kernel is being pissy (quite possible), or there's a bug (not so likely)
[19:15]  * lamont gives it back to see how well it does in the chompers this tiem
[19:15] <ScottK> lamont: Sounds good.  The area where it failed wasn't changed in this revision.
[19:15] <ScottK> Thanksd.
[19:15] <ScottK> Thanks even
[19:15] <lamont> and I gave it a high score, so it should be next up
[19:15] <ScottK> Cool.
[19:15] <lamont> if it dies again, pls tell me?
[19:16] <ScottK> Will do.
[19:16] <lamont> dear launchpad, why is the number of waiting builds not a link?  everything else seems to be.  kthx.
[19:18] <lamont> ScottK: btw, have you run across anything that could generate realtime-ish numbers of the number of queuefiles, recipients, successes and failures on a running postfix instance?
[19:19] <ScottK> lamont: No, but I haven't looked either.
[19:20] <lamont> me neither
[19:20] <lamont> nao I wantses one.
[19:26] <mjg59> Whoopie: There'll still be an ACPI event
[19:26] <mjg59> Uh. Or possibly just a uevent
[19:28] <ScottK> lamont: devscripts built this time.  Thanks.
[19:40] <lamont> ScottK: it may have just been ntp-pain then
[19:47] <crimsun> asac: device=default
[19:48] <crimsun> asac: I attached a newer patch to that bug
[19:58] <infinity> bigon: Get it synced, and I'll build it on Monday.
[20:05] <bigon> infinity: ok thx
[20:07] <ScottK> elmo: kde-guidance 0.8.0svn20080103-0ubuntu16 in hardy on powerpc and clamav 0.92.1~dfsg2-1.1 in hardy on powerpc and ia64 are still saying chroot problem.  I don't think they got retried.
[20:19] <infinity> ScottK: Given bank...
[20:19] <infinity> ScottK: back, too.
[20:19] <ScottK> infinity: Thanks.
[20:20] <lamont> ScottK: from the "hrm... these bear looking beyond one-liners" department:
[20:20] <lamont> % apt-cache search postfix| grep stat
[20:20] <lamont> mailgraph - Mail statistics RRDtool frontend for Postfix
[20:20] <lamont> queuegraph - a RRDtool frontend for Postfix queue-statistics
[20:22] <lamont> both of which claim to do "daily, weekly, monthly, and yearly"  but I want 5 minute samples and hourly graphs as well
[20:22] <lamont> SMOP
[20:22] <ScottK> ? SMOP
[20:23] <lamont> simple matter of programming
[20:23] <infinity> Simple Matter of ...
[20:23] <infinity> Yeah.
[20:24] <ScottK> Yeah.
[20:35] <ScottK> infinity: That got it.  They all built.  Thanks again.
[21:28] <kommander> hi all :-)
[21:29] <sistpoty> infinity: if you've got time for some buildd fiddling, haskell-haskell-src would need the same timout adjustments on sparc like ghc6 (it's basically the same source)... however it's imo low priority
[21:30] <kommander> got a silly question ... I want to make a custom initramfs with a boot script mounting root partition as read only, then creating an union with a tmpfs and these partition which will be /
[21:30] <kommander> but ... to mount a partition, I need a / which is writable ?
[21:31] <kommander> this is like chicken and eggs problem
[21:31] <laga> kommander: mount -n?
[21:32] <kommander> hum ... interesting !
[21:32] <kommander> :-)
[22:17] <madmetal_spyros> hello
[22:17] <madmetal_spyros> anybody to talk about hardy upgrade problems?
[22:18] <ScottK> madmetal_spyros: Try #ubuntu+1
[22:18] <madmetal_spyros> oke thanks ScottK !
[23:55] <james_w> those with buildd powers: lvm2 on powerpc was hit by the ntpdate problem and is still in chroot wait state, could someone poke it please? https://edge.launchpad.net/ubuntu/+source/lvm2/2.02.26-1ubuntu9/+build/566009