[00:09] <cjwatson> slangasek: I'd like to upload http://paste.ubuntu.com/47604/ to ubiquity (plus changelog etc.) in response to the GtkAdjustment item in the GTK release notes; I haven't yet done a bug trawl but I think this should be RC because it probably results in partitions always being resized a little bit smaller when you edit them in the manual partitioner
[00:15] <cjwatson> at least bug 264599 appears to be due to this
[01:08] <TheMuso> /c/c
[01:26] <ScottK-laptop> slangasek: Emergency MIR for libnetaddr-ip-perl to make libmail-spf-perl installable: Bug 271124
[01:34] <bryce> cjwatson: have you seen https://bugs.edge.launchpad.net/ubuntu/+source/acpi/+bug/267682/comments/37 ?
[01:35] <bryce> cjwatson: the commenter says the root cause of this problem is that the kernel rejects keys from acpi-fakekey now, and that we should no longer be using acpi-fakekey for forwarding hotkey presses
[01:37] <bryce> cjwatson: looking in the acpi package it seems there's tons of similarly titled bugs.  "Sony FN keys don't work", "Hot keys not detected", etc.
[01:39] <bryce> some of those bugs are fairly old -- see lp #64290 as an example that's 2 years old but seems to describe the same symptoms as mdz, et al
[01:39] <bryce> well, _similar_ symptoms anyway
[01:43] <ScottK-laptop> slangasek: For the kdesdk problem cvsservice needs to get promoted to Main.  Source package is already in Main.
[01:45] <ScottK-laptop> slangasek: That's it off of http://people.ubuntu.com/~ubuntu-archive/testing/intrepid_probs.html that I'm working on.
[01:50] <bryce> bdmurray: btw, I notice there are a lot of bugs (>100) filed against 'acpi' which probably really belong to 'acpi-support' or other packages
[01:51] <bryce> bdmurray: 'acpi' is a simple command line tool that just displays the battery usage.  Most of the bugs filed against acpi are about deeper issues.
[01:52] <bryce> bdmurray: it might be worth a script to move them?
[01:55] <bryce> bdmurray: I suspect they were mis-triaged.  The bugs definitely sound like ACPI issues, but I'm figuring the triager mistakenly assumed package 'acpi' was for general acpi issues.  But actually I only see a tiny handful that actually are about the acpi cmdline tool.
[01:56] <bryce> bdmurray: also probably it would be worth a bug day to clean this up, and also maybe do some work on acpi-support
[02:42] <cjwatson> bryce: I keep being told that acpi-support is supposed to go away for this cycle, and that everything should end up using pm-utils
[02:43] <slangasek> until pm-utils handles the wireless hotkey on my thinkpad, the people who say this are lying
[02:44] <thom> i love that acpi-support is still used :)
[02:44] <slangasek> cjwatson: ubiquity> yes, go ahead
[02:45] <slangasek> ScottK-laptop: hmm, I don't believe I have emergency MIR powers, and both the MIR team are off today
[02:45] <cjwatson> bryce: cf. bug 217504 if you haven't seen it already
[02:45] <slangasek> ScottK-laptop: will look at cvsservice later this eve
[02:45] <cjwatson> has a lot more detail and a patch that reverts to the old behaviour (although also a contention that acpi-fakekey shouldn't be relying on this ...)
[02:46] <cjwatson> slangasek: ta
[02:48] <stgraber> hey bryce, any idea when we'll get a new driver from ati (fglrx) ? (if possible one that's compiled for the new Xorg)
[02:51] <ScottK-laptop> slangasek: OK.  I guess I'll ping pitti tomorrow then.
[02:51] <ScottK-laptop> (for the MIR).
[02:51] <cjwatson> ScottK-laptop: libnetaddr-ip-perl promoted; I don't think pitti and doko will mind if I borrow the MIR hat
[02:51] <ScottK-laptop> cjwatson: Thanks.
[02:52] <ScottK-laptop> slangasek: Then that just leaves cvsservice for you and I'm done ...
[03:13] <StevenK> slangasek: I did.
[04:23]  * kirkland superm1 ping
[05:07] <ScottK-laptop> LaserJock: You around?
[05:07] <LaserJock> yeah
[05:08] <ScottK-laptop> LaserJock: edbuntu-kde is on on the uninstallable list: http://people.ubuntu.com/~ubuntu-archive/testing/intrepid_probs.html
[05:08] <ScottK-laptop> LaserJock: I have the solution for it.
[05:08] <ScottK-laptop> Are you still the right person to run it past?
[05:08] <LaserJock> yeah
[05:08] <ScottK-laptop> OK, it just needs khelpcenter/khelpcenter4 throughout.
[05:09] <ScottK-laptop> LaserJock: I can upload it if you're OK with that.
[05:19] <ScottK-laptop> LaserJock: ??
[05:31] <ScottK-laptop> LaserJock: I've tested this a couple of times in a clean chroot (including one with no Universe), so I think I'm ready to upload.  What do you think?
[05:44] <TheMuso> 5~/c
[05:50]  * ScottK-laptop waits for an ugh.
[05:50] <ScottK-laptop> Heya TheMuso.
[05:51] <TheMuso> ScottK-laptop: hehe. Not quite, I've slightly adjusted the way I have my IRC and other terminal windows/tabs set up, and its still taking a little bit of incorrect key presses to adjust.
[05:52] <ScottK-laptop> Actually it's been a long time since I've seen an ugh, so I guess it's all working better than it used to.
[05:52] <TheMuso> Yeah it is.
[05:52] <TheMuso> And I keep the ugh to myself now. :p
[05:52] <TheMuso> should there be one
[06:09] <anilg> A question related to the graphviz package that i'm porting.. is it fine to add d-shlib overrides to successfully run the d-devlibdeps in debian/rules?
[06:10] <anilg> details at http://lists.sonic.net/pipermail/gnusol-devel/2008-September/001151.html
[06:33] <slangasek> StevenK: really?  then perhaps -S is broken, hmm :/
[06:33] <slangasek> ScottK-laptop: cvsservice promoted
[06:33] <slangasek> \o/
[06:33] <StevenK> slangasek: The command said "There are no binaries published, oh well"
[06:34] <StevenK> slangasek: I'm more inclined to blame Soyuz
[06:34] <slangasek> hmmm
[06:35] <persia> I suspect it was that there was a placeholder for the binaries, but no actual binaries (FTBFS due to ogre-model, and never built in main)
[06:38] <ScottK-laptop> slangasek: Great.  The only remaining kde related thing was edubuntu-kde and laserjock said he'd fix their seeds tomorrow.
[06:38] <slangasek> spiff
[07:07] <slangasek> superm1: latest DVD livefs build fails because of nvidia-related deps: http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/intrepid/ubuntu-dvd/20080916/livecd-20080916-amd64.out
[07:10] <Adri2000> slangasek: could you take a look at the vsftpd FFe request please?
[07:12] <slangasek> Adri2000: not currently; fixing up alpha-6 takes precedence.  I'll revisit the list of FFes as soon as I can.
[07:13] <Adri2000> slangasek: ie. after alpha 6 is released?
[07:13] <slangasek> well, no, hopefully I'll get a chance to look at them tomorrow
[07:14] <Adri2000> ok
[09:08] <slangasek> lool: is there an MIR pending for python-dateutil, which python-elisa now depends on?
[09:11] <slangasek> asac: what are the odds of an upload for bug #269010 today?
[09:37]  * wgrant clears throat.
[09:38] <wgrant> slangasek: "BY USING THE MOZILLA FIREFOX BROWSER, YOU ARE CONSENTING TO BE BOUND BY THE AGREEMENT. IF YOU DO NOT AGREE TO THE TERMS AND CONDITIONS OF THIS AGREEMENT, DO NOT USE THE MOZILLA FIREFOX BROWSER."
[09:38] <asac> slangasek: great that you are here
[09:38] <asac> slangasek: i wanted to ask you for permission to upload the latest NM branch - which includes this fix
[09:39] <asac> slangasek: let me give the info for you
[09:39] <slangasek> asac: ok
[09:39] <asac> slangasek: http://bazaar.launchpad.net/~network-manager/network-manager/ubuntu.0.7/annotate/2895?file_id=changelog-20070529224034-rodq6xuj4xbig4cr-3
[09:39] <slangasek> wgrant: perhaps that's what it says.  I don't know, I haven't read it!
[09:40] <wgrant> slangasek: Unwise to agree to something that you haven't read.
[09:40] <wgrant> Though I fail to see how that statement can be even slightly legal.
[09:40] <asac> slangasek: bug 269010 is your bug; the other is #269755 which is a RC regression from a RC bug 259503
[09:41] <asac> slangasek: the other bug is also more or less RC: #268095
[09:41] <asac> RC for final -> 100% ... alpha-6 == more or less ;)
[09:41] <asac> but we have those bits in the branch and i have received good feedback on them
[09:42] <asac> and getting those on a CD is helpful for my final round of gathering hal fdi tweaking before beta
[09:42] <slangasek> wgrant: I haven't agreed to it, have I?
[09:43] <asac> slangasek: so. not really a choice. unless you have questions I'd like to upload that now
[09:43] <wgrant> slangasek: Oh, but it asserts that you have by using the browser. I'm not sure how it can possibly say that.
[09:43] <slangasek> wgrant: even if I were to have read that in my browser, (which I haven't, I've only had it second-hand from you), I don't recognize that this has any power to bind me
[09:44] <wgrant> slangasek: Neither. It's a very strange EULA.
[09:46] <slangasek> asac: yes, please upload
[09:46] <asac> thanks
[09:48] <asac> slangasek: done.
[09:48] <slangasek> ya
[09:48] <slangasek> yay
[09:49]  * TheMuso catches up on conversation. Was actually about to check whether nm asking for a wireless passphrase all the time was a known bug. :)
[09:49] <StevenK> I saw that back in ... Feisty?
[09:49] <TheMuso> Yeah but network manager wasn't as mature I would think.
[09:49] <slangasek> TheMuso: I don't think that's fixed yet, given my experience testing so far
[09:50] <slangasek> I've just fixed the bug that caused the system backend to crash; it still flakes out on me when it comes to actually giving up the passphrases :P
[09:50] <TheMuso> Right.
[09:51] <wgrant> Does it cache networks overzealously for others? Whenever I resume it attempts to connect to the last network, asks for a passphrase when it can't get DHCP, and thus crashes.
[09:51] <slangasek> (I mean, clearly this iteration of the system backend wasn't tested at all, it segfaulted every time; so I'm not surprised that it still doesn't work after fixing the crasher bug :/)
[09:52] <slangasek> wgrant: "thus" -> it crashes because it asks for a passphrase?
[09:52] <wgrant> slangasek: When I click "Connect" on the auth dialog it crashes, yes. I've been meaning to get apport to file it, but on the network I'm on when it occurs I don't have appropriate access.
[09:53] <slangasek> heh
[09:54] <asac> wgrant: is that WPA-EAP?
[09:55] <asac> wgrant: the resume fix is now fixed
[09:55] <asac> err: resume crash
[09:56] <wgrant> It's WPA Enteprise of some variety.
[09:56] <wgrant> I'll check once the connection editor unhangs.
[09:56] <wgrant> WPA-EAP with CHAPv2.
[09:56] <asac> yeah
[09:57] <asac> thats strange. we have fixed a bug caused by in appropriate use of NSS ... which should have been responsible for that
[09:57] <asac> let me check if we actually have that or if we landed that upstream only
[09:57] <wgrant> I last upgraded about 36 hours ago.
[09:58] <asac> wgrant: yeah. the resume crash is fixed by the upload i did 5 minutes ago
[09:58] <wgrant> asac: Great! Thanks.
[09:58] <asac> wgrant: the NSS fix should be fixed. but most likely upstream only
[09:58] <asac> if so its my fault because i submitted it there directly assuming that i would merge from upstream soon.
[10:00] <asac> wgrant: hmm. so we have that patch
[10:01] <asac> wgrant: have you filed the NSS crash report?
[10:01] <wgrant> asac: No, they always happen on the network where I'm horribly proxied.
[10:02] <wgrant> And by the time I get to a good network I've inevitably got some out of date packages which apport objects to.
[10:11] <asac> wgrant: there are two options: 1. you install -dbgsym packages up front and run NM in gdb until it crashes
[10:11] <asac> 2. you could also do a -O0 -g build locally and run that in gdb
[10:12] <wgrant> asac: I'll try those tomorrow when I can see the network. Thanks.
[10:52] <slangasek> asac: n-m build regression on !x86?
[10:53] <asac> slangasek: yes. investigating
[10:53] <asac> from what we currently see its a glib problem in gbacktrace.h
[10:53] <slangasek> ok
[10:53] <asac> i am checking whether we can remove the code part triggering this
[10:55] <asac> slangasek: http://paste.ubuntu.com/47719/
[10:55] <asac> seb128: ^^
[10:56] <slangasek> yes, sounds correct
[10:57] <asac> seb128: nm fails like http://paste.ubuntu.com/47720/ on all not amd64 or i386 when using G_BREAKPOINT
[10:58] <seb128> asac: http://svn.gnome.org/viewvc/glib?view=revision&revision=7495 ?
[10:58] <asac> seb128: slangasek: we probably can comment this out in nm to unblock alpha 6 and then fix that in glib right after that. or do we want to try to fix glib directly for alpha 6?
[10:59] <seb128> asac: would that fix it?
[10:59] <slangasek> I don't think it's critical to fix this for the ports before alpha-6, is it?
[10:59] <\sh> asac: what does that say? do we need another lib in ia32?/usr/lib/nspluginwrapper/i386/linux/npviewer.bin: error while loading shared libraries: libxcb-render-util.so.0: cannot open shared object file: No such file or directory
[10:59] <asac> seb128: hmm
[10:59] <asac> seb128: _MSC_VER?
[10:59] <\sh> asac: this is the cli output when running ff3 + flash + some random app ;)
[10:59] <seb128> asac: ok, probably not the same issue ;-)
[11:00] <asac> isnt that windows code? or am i just confused?
[11:00] <asac> seb128: from our current evaluation its a missing signal.h in gbreakpoint.h :/
[11:01] <asac> slangasek: you are RM ... i can live without those archs ;)
[11:01] <seb128> asac: gbreakpoint.h didn't change for ages, that's weird
[11:01] <asac> hmm ... then probably libc?
[11:01] <asac> like an implicit include?
[11:01] <slangasek> asac: rather, I think these archs can live without the latest bugfixes for alpha-6
[11:01] <asac> that doesnt exist anymore?
[11:01] <asac> slangasek: thanks.
[11:01] <slangasek> asac: since there, um, aren't a whole lot of hppa users who need WPA support
[11:02] <slangasek> anywho, off to bed for a few hours
[11:02] <asac> seb128: but maybe they dont want crashes on resume ;)
[11:02] <asac> err
[11:02] <asac> slangasek: ^^ ;)
[11:02] <seb128> asac: anyway including signal.h in gbreakpoint.h looks like a correct thing to do yes
[11:03]  * ogra grumbles about evil firefox
[11:03] <ogra> it used to tell me the amount of open tabs when i hit the close button
[11:03] <ogra> now it only asks if it should close them :(
[11:03] <asac> seb128: you want a bug or can you directly file upstream? or maybe ask your glib contact frirst?
[11:03] <seb128> asac: I'll file it upstream now
[11:04] <asac> seb128: thanks. http://launchpadlibrarian.net/17689412/buildlog_ubuntu-intrepid-sparc.network-manager_0.7~~svn20080908t183521%2Beni0-0ubuntu3_FAILEDTOBUILD.txt.gz thats the full log of a failed build if the pastes above arent enough
[11:05] <asac> those were: http://paste.ubuntu.com/47719/ and http://paste.ubuntu.com/47720/
[11:09] <asac> ogra: maybe too many tabs?
[11:09] <asac> or too few?
[11:10] <ogra> asac, surely over 50
[11:10] <ogra> i just wanted to know the number ... i used to hit the window close button and got an accurate number by that before
[11:11] <ogra> though its a while ago that i did that last time ... might have been hardys ff2
[11:25] <bigon> infinity, are you around?
[11:32] <asac> \sh: looks like
[11:32] <asac> \sh: wierd that i dont see it. let me retry
[11:34] <asac> \sh: hmm. i am not seeing this on the console. how do you trigger it?
[11:35] <cody-somerville> Someone told me that recommends were no longer being pulled into the cd builds. Is that correct?
[11:36] <cody-somerville> Because I'm seeing some strange behaviour : (
[11:39] <cjwatson> cody-somerville: you were misinformed
[11:39]  * cody-somerville peers at NCommander.
[11:39] <cjwatson> cody-somerville: what's the strange behaviour?
[11:39] <cody-somerville> cjwatson, Well, it isn't strange if recommends are being pulled in
[11:39] <cjwatson> OK
[11:40] <cjwatson> I don't know where NCommander got that from
[11:42] <cody-somerville> Actually, there is some strange behaviour
[11:42] <cody-somerville> cjwatson, http://people.ubuntu.com/~ubuntu-archive/germinate-output/xubuntu.intrepid/desktop
[11:42] <cody-somerville> IF you search for "xscreensaver", you'll see for example:
[11:42] <cody-somerville> xscreensaver-data            | xscreensaver                | Xubuntu.Intrepid desktop seed          ...
[11:42] <cody-somerville> However, xscreensaver *isn't* in the Xubuntu.Intrepid desktop seeds.
[11:43] <cody-somerville> xscreensaver-data and xscreensaver-gl are on the other hand.
[11:44] <ogra> xscreensaver-gl : Recommends: xscreensaver | gnome-screensaver
[11:44] <ogra> i guess that needs to be reordered
[11:44] <ogra> xscreensaver-data doesnt have recommends
[11:45] <davmor2> guys Firefox is nolonger displaying the startpage.html even after a restart is this known?
[11:46] <jordi> TheMuso: hey
[11:47] <cody-somerville> ogra: Yes, and the Recommends for usplash need to be reordered as well.
[11:48] <jordi> TheMuso: I think it's time to revisit our "try to merge Debian and Ubuntu's ALSA teams" plan. :)
[11:48] <TheMuso> jordi: SOunds good to me.
[11:49] <cjwatson> ogra: that shouldn't make the reason show up as "Xubuntu.Intrepid desktop seed"; that should make the reason show up as "xscreensaver-gl"
[11:49] <ogra> yeah, thats a bit weird
[11:50] <cody-somerville> ogra, If I switch changes Recommends: usplash-theme-ubuntu | usplash-theme to Recommends: usplash-theme | usplash-theme-ubuntu, will that have the desired effect of usplash-ubuntu-theme not being installed because I have xubuntu-artwork-usplash seeded?
[11:50] <cjwatson> ah, that germinate output is using the wrong seeds
[11:50] <cody-somerville> doh : (
[11:50] <ogra> cody-somerville, if xubuntu-artwork-usplash provides usplash-theme, yes
[11:50] <cjwatson> cody-somerville: no, please don't do that, the real alternative should come first
[11:50] <cjwatson> cody-somerville: seeding xubuntu-artwork-usplash before usplash should be sufficient
[11:50] <cjwatson> actually the order shouldn't even really matter
[11:50] <cjwatson> leave the Recommends order alone
[11:51] <ogra> cody-somerville, do you ship gnome-screensaver ?
[11:51] <cody-somerville> Yes.
[11:51] <ogra> hmm
[11:51] <cody-somerville> but if xscreensaver is installed, we use that instead
[11:51] <cody-somerville> so I don't want xscreensaver installed by default
[11:51] <ogra> well, lets see what the germinate change does then :)
[11:51] <TheMuso> jordi: Is there an alsa channel for debian? if so, I'll join there and discuss further.
[11:52] <jordi> TheMuso: sorry, was afk
[11:52] <cody-somerville> xscreensaver and usplash-ubuntu-theme are two packages that are getting pulled into Xubuntu builds currently that I don't want. I'm pretty sure both are via recommends.
[11:52] <jordi> TheMuso: no, there was back in the day, #debian-alsa, but we mostly work via the mailing list
[11:52] <cjwatson> cody-somerville: oh, for the output above, I misread and it looks like you did too
[11:52] <ogra> cody-somerville, no, because germinate uses the wrong seeds
[11:52] <jordi> TheMuso: you should be added to the alioth project and get svn rights
[11:52] <cjwatson> cody-somerville: the columns are binary | source | reason, so xscreensaver-data is the binary and xscreensaver is the source package. That output isn't saying that xscreensaver is pulled in
[11:52] <jordi> TheMuso: do you have an alioth login?
[11:53] <ogra> but the order in the seeds could be wrong "<cjwatson> cody-somerville: seeding xubuntu-artwork-usplash before usplash should be sufficient"
[11:53] <TheMuso> jordi: I have an alioth account, however when trying to recover my password, I get told the username doesn't exist, however when I attempt to create an account with the same username, I'm told it already exists...
[11:53] <cjwatson> ogra: I corrected myself immediately afterwards
[11:53] <ogra> ah, k
[11:54] <cjwatson> germinate sets all directly seeded entries before resolving dependencies
[11:54] <ogra> weird then
[11:54] <cody-somerville> cjwatson, ah, right.
[11:54] <cjwatson> I'm regenerating that germinate output
[11:54] <cody-somerville> Okay, that should give us some answers :)
[11:54] <cjwatson> oh, meh, cdimage needs to be pointed at the new seeds too
[11:55] <cjwatson> this is ridiculous
[11:55] <TheMuso> jordi: I guess I need to contact the alioth admins about that one...
[11:56] <cody-somerville> Okay, I just looked at the manifest for today anyhow
[11:56] <cody-somerville> xscreensaver isn't getting pulled in anymore
[11:56] <cody-somerville> So usplash-theme-ubuntu is the big issue atm
[11:57] <cjwatson> this might be a germinate bug. Give me a while to look at it
[11:58] <jordi> TheMuso: #alioth tends to be very responsive
[11:58] <TheMuso> jordi: Ok I'll try again, and if I still have the issu, I
[11:58] <TheMuso> jordi: Ok I'll try again, and if I still have the issu, I'll contact the admins.
[11:58] <cody-somerville> cjwatson, thanks :)
[11:58] <cjwatson> eep, I never pulled the fix for bug 254042 onto antimony
[11:59]  * cjwatson fixes
[12:00]  * ogra wonders how we could even build working CDs with that 
[12:00] <cjwatson> ogra: it just means some priorities come out wrong
[12:00] <cjwatson> the CDs have all those packages on anyway
[12:00] <cjwatson> cody-somerville: yes, I think this is a germinate bug. It fails to consider Provides when looking for packages to promote from lesser seeds to satisfy dependencies
[12:00] <ogra> ah, ubuntu-desktop had the mentioned special casing ?
[12:01] <cjwatson> ogra: no?
[12:01] <cjwatson> this has nothing to do with desktop - it's purely about the allocation of packages between required and build-essential
[12:01] <ogra>  ? "* Add support for setting per-seed features, so that following Recommend can be disabled for some seeds but not others "
[12:01] <ogra> ah
[12:02] <cjwatson> ogra: which we did only for the required seed, and all the packages pulled in that way are on the CD for some other reason anyway
[12:02] <cjwatson> the only difference is their Priority field
[12:02] <ogra> yeah, understood now
[12:04] <cjwatson> cody-somerville: this isn't Xubuntu-specific either, as you can see from 'apt-cache show usplash-theme-ubuntu | grep ^Task:'
[12:07] <cjwatson> cody-somerville: bug 271309
[12:36] <superm1> slangasek, is that because nvidia-settings is in universe then?
[12:36] <superm1> slangasek, and if that's the only problem, then tseliot can you do a MIR for it?
[12:41] <cjwatson> cody-somerville: damn you, this is viciously complicated. :)
[12:43]  * davmor2 is sorry he located the xubuntu usplash issue
[12:45] <cjwatson> I think it wants to look something like http://paste.ubuntu.com/47748/, but argh melty brain
[12:46] <jordi> TheMuso: after that, we can discuss changes in ubuntu that we obviously want to have in Debian
[12:47] <davmor2> Who deals with Jockey?
[12:47] <cjwatson> davmor2: pitti
[12:47] <davmor2> cjwatson: ta
[12:49] <TheMuso> jordi: Yes.
[13:14] <luisbg> cjwatson: james_w: the package worked with no problem in hardy, but I have been testing in intrepid and it does
[13:14] <luisbg> I did follow the policy and it should work ok, but it doesnt
[13:14] <luisbg> so I feel forced to change the approach to what Edubuntu does, eventhough I don't like having to change XDG configurations
[13:19] <cjwatson> Riddell: sorry about the Kubuntu CD build noise, fixed now
[13:34] <tseliot> superm1: what should I do for slangasek? What's the problem?
[13:52] <fta> bryce, i'm experiencing some image corruptions in firefox. looking at https://launchpadlibrarian.net/7592385/breezy_cof-mugshot.png (from https://edge.launchpad.net/~ubuntumembers), i get weird stuff like http://www.sofaraway.org/ubuntu/tmp/corrupted2.png or http://www.sofaraway.org/ubuntu/tmp/corrupted3.png. This is with nvidia-glx-177
[13:53] <tjaalton> fta: not much we can do about nvidia
[13:54] <tseliot> fta: what does this command say? sudo aptitude show nvidia-glx-177 | grep Version
[13:54] <jcristau> tseliot: you know, you don't need root for dpkg -s
[13:54] <fta> tseliot, 177.70-0ubuntu2
[13:55] <tseliot> jcristau: I like to do things my way ;)
[13:56] <tseliot> fta: can you report the problem here? http://www.nvnews.net/vbulletin/forumdisplay.php?f=14
[13:56] <tseliot> only NVIDIA can fix it
[14:02] <asac> fta: could you try if that problem goes away when using nv ?
[14:02] <fta> nv is unusable
[14:02] <asac> so you cant even start X and see if that same pic is corrupted too?
[14:05] <fta> i'm not sure it's nvidia's fault here
[14:05] <asac> fta: thats why i asked you to test the free driver ;)
[14:05] <jcristau> so try with another driver. if it works, it was nvidia's fault
[14:05] <fta> i can't reproduce with ff3.0, just ff3.1
[14:05] <jcristau> if it doesn't, it may still be nvidia's fault, but at least you have somewhere to start
[14:06] <asac> fta: thats only for pngs or jpegs or for all images?
[14:06] <fta> just this png so far, but 100% reproducible in ff3.1
[14:06] <fta> could be cairo too
[14:07] <asac> fta: is it system-cairo we are using?
[14:07] <fta> yes
[14:09] <asac> fta: i think if its in upstream builds too, we would need to ask vlad
[14:18] <fta> asac, latest upstream build impacted too, using a copy of my ff3.1 profile (so reusing my session)
[14:31] <cjwatson> -* Chose usplash-theme-ubuntu to satisfy usplash
[14:31] <cjwatson> +! Promoted xubuntu-artwork-usplash from desktop to desktop-common to satisfy usplash
[14:31] <cjwatson> +* Chose usplash-theme to satisfy usplash
[14:31] <cjwatson> this is looking more sensible now
[14:32] <cjwatson> cody-somerville: if you don't mind, I'm going to defer this patch until after alpha-6 - it's big and scary
[14:33] <ogra> would put some extra excitement into alpha6 though
[14:33] <ogra> :)
[14:34] <cody-somerville> so should I just modify the priority of the xubuntu's splash alternative?
[14:34] <cjwatson> can you just live with the bug for now?
[14:34] <cjwatson> I don't think we should be mucking around with packages for a germinate bug
[14:35] <ogra> might be problematic for people to get rid of the ubuntu usplash later though
[14:35] <ogra> unless you tel the to manullay remove
[14:35] <ogra> *tell them to manually
[14:36] <cjwatson> you'll have to do that from alpha-5 anyway
[14:36] <cjwatson> this isn't a new bug, AFAICS
[14:37] <cody-somerville> I don't think Xubuntu shipping with Ubuntu's artwork would go over well.
[14:38] <cjwatson> cody-somerville: alpha 5 did; why is alpha 6 much worse?
[14:38] <cody-somerville> oh, for alpha 6
[14:38] <cody-somerville> sorry, I misread you.
[14:38] <cjwatson> we won't ship the beta this way - I have the bug fixed, I just don't think it's safe for alpha 6
[14:38]  * cody-somerville nods.
[14:38] <cjwatson> because it's a honking big complicated patch
[14:39] <cjwatson> and involves heuristics
[14:39] <cody-somerville> I agree.
[14:39] <cody-somerville> No problem :)
[14:40] <cjwatson> ok, great, that's a relief :)
[14:40]  * cjwatson didn't want to explain to slangasek why he broke germinate
[14:42] <cjwatson> I've marked the bug as beta-critical so we don't forget
[14:43] <cjwatson> slangasek: if you find you need to pull that ^-- germinate fix in, then just run 'bzr pull' in antimony:cdimage/germinate/
[14:45] <superm1> tseliot, well so i believe the issue is that the dvds won't build because nvidia-settings is in universe and a Recommends for nvidia-glx-*
[14:45] <ScottK-laptop> lool: elisa and python-elisa are currently uninstallable in Main because python-dateutil is in Universe.  Since you show up in debian/changelog, I figured you'd be the most likely interested party.
[14:46] <ogra> ScottK-laptop, he's at a summit in berlin, dont expect immediate reply
[14:46] <davmor2> Jockey doesn't offer the option to reboot your machine once you have installed a driver :(
[14:47] <ogra> ScottK-laptop, i dont think they are used anywhere on CDs so i guess it can wait until monday
[14:47] <tseliot> davmor2: don't worry, we'll fix it
[14:47] <ScottK-laptop> OK.  I guess up to slangasek how much he cares for the Alpha 6 milestone.
[14:48] <tseliot> superm1: ah, so the Recommends breaks the DVD, very interesting...
[14:49] <superm1> tseliot, well that's what i gather from looking at the DVD build log
[14:49] <superm1> tseliot, http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/intrepid/ubuntu-dvd/20080916/livecd-20080916-amd64.out
[14:50] <superm1> tseliot, but i'm not sure if perhaps the conflicts is what's throwing it too
[14:50]  * tseliot has a look at the log
[14:51] <ogra> ScottK-laptop, well, nobody apart from loic really knows these packages i think ... better to wait for him to return
[14:52] <ScottK-laptop> OK.  I was interested enough to find the problem, but not interested enough to write another MIR.
[14:53] <tseliot> superm1: ok, maybe nvidia-settings should be in main
[14:54] <tseliot> superm1: it would be interesting to know why it says that "nvidia-177-kernel-source: Conflicts: nvidia-kernel-source"
[14:54] <tseliot> when it shouldn't be a problem
[14:55] <superm1> tseliot, perhaps is that happening because they're all providing nvidia-kernel-source?
[14:55] <superm1> and then causing a handful of conflicts and not wanting to be on the DVD for that reason?
[14:56] <tseliot> superm1: ok but conflict, replace, provide should be ok. Those packages replace each other
[14:57] <tseliot> NOTE: I have no idea of how Ubuntu CD/DVDs are created
[14:58] <superm1> cjwatson, perhaps can you look at this error a bit? I wouldn't think that conflicts/replaces would prevent packages from ending up in the archive on the CD, is it just nvidia-settings thowing it off, or the conflicts/replaces too?
[15:08] <cjwatson> superm1: if packages in the relevant tasks (ubuntu-dvd-live in this case) conflict, then they can't all be installed at the same time, which is what we're asking for by having them all in the dvd-live task
[15:09] <cjwatson> dvd-live means that they're actually on the live filesystem not simply available as .debs on the CD
[15:09] <cjwatson> you are correct that if they were in the dvd seed then conflicts wouldn't be a problem - but they aren't
[15:09] <superm1> cjwatson, ah well that's a mistake then in that commit.  they should be available as debs on the DVD
[15:09] <superm1> cjwatson, would you be able to correct the seed?
[15:09] <cjwatson> sure
[15:10] <superm1> cjwatson, thanks.  will it still be troublesome that nvidia-settings is in universe then too, or will that be silently ignored?
[15:11] <cjwatson> I think that should be silently ignored
[15:11] <superm1> okay that's good then
[15:11] <tseliot> ok, great
[15:12] <cjwatson> should be sorted now
[15:12] <cjwatson> except you'll have to wait for the next publisher run where a package is actually published (the condition there is due to a Soyuz bug) before you can rebuild livefses
[15:12] <cjwatson> slangasek: ^- note caveat
[15:13] <lool> slangasek, ScottK-laptop: ack, python-dateutil and  python-cssutil will need MIRs
[15:14] <lool> slangasek, ScottK-laptop: I'm at a conference this week, may it wait til next week?
[15:15]  * ScottK looks at slangasek
[15:19] <lool> slangasek: Also, there's a new pigment with new SONAME and corresponding new elisa which came out yesterday or today lalala
[15:20] <lool> slangasek: There isn't much risk in going to these, pigment-python is the only rdep of the new libpigment
[15:20] <lool> slangasek: But I'd understand if you consider it's too late for such things
[15:23] <lool> slangasek: In fact, it's probably a better choice to defer the new elisa and pigment to next cycle as they play with new UI concepts, and these specific parts might not be ready
[15:32] <fta> bryce, tjaalton, tseliot: nm my image corruption issue, it is caused by the new color management feature in firefox 3.1, see http://mozillalinks.org/wp/2008/09/color-profiles-turned-on-for-firefox-31/ (i'm using 1=full, not 2=partial)
[15:35] <psyke83> asac: no news re: the pa alsa plugins, but ia32-libs has been updated, so flashplugin-nonfree can be updated as well. The debdiff is in bug #257403
[15:38] <asac> psyke83: i have the latest, but still have /usr/lib32/libflashsupport.so
[15:38] <asac> e.g. i have ia32-libs 2.2ubuntu12
[15:38] <asac> \sh: ^^
[15:38] <asac> $ dpkg -L ia32-libs | grep libflashsupport
[15:38] <asac> /usr/lib32/libflashsupport.so
[15:39] <asac> \sh: you missed the most important part for flash ;) ^^
[15:40] <asac> \sh: can you do ubuntu13?
[15:40] <tseliot> fta: ah, ok
[15:40] <asac> yeah. but its a driver bug
[15:40] <asac> i dont see it anyway with any color management option
[15:40] <asac> (using ati)
[15:41] <psyke83> asac: yes, it ideally needs to be removed. On the other hand, 64bit users won't note so many crashes due to nspluginwrapper. The worst that happens is that flash content will "turn grey" on web pages (i.e. npviewer.bin segfaults, but firefox doesn't)
[15:41] <asac> fta: we really need nv tested. otherwise that  will surely be the first question asked
[15:41] <asac> psyke83: it _has_ to be removed
[15:41] <asac> no matter what
[15:41] <psyke83> yep :). I just don't care as much, I'm stuck with 32 bit... hehe
[15:41] <asac> psyke83: it got worse and sometimes crashes flash while playing
[15:42] <psyke83> I see
[15:42] <asac> previously it only crashed flash when leaving the site
[15:42] <asac> or switching to a new film
[15:42] <asac> now it crashes it right up-front
[15:42] <asac> for a bunch of cases at least
[15:42] <asac> psyke83: all the other changes didnt block flash 10
[15:42] <asac> at least not the packaged flash 10
[15:43] <psyke83> asac: if it crashes like that, it's highly likely to be a windowless mode bug. That's bug #239182, and also see http://blogs.adobe.com/penguin.swf/2008/07/addessing_wmode_crashes.html
[15:44] <asac> psyke83: well. lots of these crashes go away with removing libflashsupport
[15:44] <psyke83> though my understanding of the upstream report is that 3.0.2 has it fixed
[15:44] <asac> i know that there are other issues with windowless mode
[15:44] <psyke83> asac: yep, and I'm not disagreeing re: libflashsupport - it definitely needs to be removed
[15:50] <TheMuso> c
[15:51] <TheMuso> psyke83, asac re alsa apps going via pulse only for when pulse is running, I know what to do to make it happen, I just have to do it, and test it. I will be doing that tomorrow.
[15:52] <asac> TheMuso: ok. any insight about what we plan to do?
[15:52] <psyke83> TheMuso: thanks, I'll be happy to help test whatever ends up in your PPA. Just note that asac is eager to push that fix in Intrepid, but not necessarily PA 0.9.12 (though it would be nice)
[15:54] <TheMuso>  asac We firstly adjust alsa-lib to look for an extra asoundconf file, one which will be shipped with pulseaudio. If this file is not present, it won't break anything. This file will have definitions to check if pulseaudio is running, and if so, it will send all alsa apps via pulseaudio. Otherwise, the audio will be sent to alsa. Pulseaudio depends on alsa-plugins to make this happen.
[15:54] <TheMuso> So for desktops not using pulse, i.e KDE, nothing will be any different, except for alsa-lib searching for a non-existant configuration file.
[15:55] <TheMuso> psyke83: I think we wil stick with 0.9.10, but I am going to make a few tweaks, such as the resampler used, etc.
[15:55] <TheMuso> Mandriva have some nice patches that I will be using to fix up a few bits as well.
[15:55] <asac> TheMuso: ok thanks for clarifying
[15:55] <asac> TheMuso: once you have fixed that in intrepid we should talk about hardy
[15:55] <asac> ;)
[15:56] <TheMuso> asac: Yeah. Unfortunately that may be difficult to push out in an SRU, but we will see how we go.
[15:56] <psyke83> TheMuso: thanks, but please don't use the speex-float-0 method. It introduces a lot of distortion in high-range sounds (e.g. explosions). I've tested, and speex-float-1 doesn't have any issues
[15:57] <asac> TheMuso: yes. we should look into ... but not as long as the theory isnt tested. thanks for your work.
[15:57] <TheMuso> asac: The changes to alsa-lib are trivial, so that shouldn't be a problem.
[15:57] <psyke83> and the trivial resample method is terrible
[15:57] <TheMuso> psyke83: ?
[15:57] <psyke83> TheMuso: talking about the resample methods. By default it uses speex-float-3
[15:57] <asac> TheMuso: yeah. i assume the pulse plugin for alsa is more what troubles us. but lets see when we get to that
[15:57] <TheMuso> psyke83: Oh right. Let me check to see what Mandriva uses.
[15:59] <TheMuso> psyke83: mandriva uses speex fixed 0
[16:00] <psyke83> TheMuso: yes, I linked to that report in our bug. I've tested all the methods - all the fixed methods have distortion, and so does speex-float-0. The best compromise was speex-float-1. You may want to test it thoroughly before making changes (and find a good quality audio sample to test)
[16:01] <TheMuso> psyke83: Ok, the prblem is, all my hardware appears to perform without issue on the pulseaudio default.
[16:01] <TheMuso> psyke83: So I fear that whatever I test should e ok.
[16:01] <psyke83> IMHO, the resampler isn't the source of stutter. On all my systems, changing the fragment sizes/amounts is always what eliminated stutter
[16:01] <TheMuso> will be ok even
[16:01] <TheMuso> c
[16:02] <psyke83> TheMuso: ok, have you been testing with VLC and SDL applications? They tend to stutter a lot
[16:02] <psyke83> GStreamer apps don't stutter at all with the default settings, on my systems - but SDL apps, Skype, VLC, do
[16:02] <TheMuso> psyke83: No, because they are not accessible.
[16:03] <TheMuso> However I will make an effort to test with those apps tomorrow when I am doing more work on all this stuff.
[16:04] <psyke83> cool
[16:07] <slangasek> superm1: it looks like nvidia-settings not being in main (... restricted?) is part of it, but also that we're trying to install all of the packages at the same time in the livefs, and they conflict?
[16:10] <slangasek> cjwatson: hrm, so that germinate fix isn't related to the kubuntu liveCD build failure? :/
[16:10] <tseliot> slangasek: nvidia-settings is GPL v.2, therefore it could be moved to main. Those packages cannot be installed at the same time but this shouldn't be a problem, right?
[16:10] <slangasek> tseliot: it's a problem for trying to put them in the livefs!
[16:11] <cjwatson> slangasek: I fixed the Kubuntu live CD build failure, I believe
[16:11] <cjwatson> sorry about the noise; it was due to a regression in germinate that I incautiously pulled ...
[16:11] <tseliot> slangasek: yes, I know
[16:11] <NCommander> wooo, I got access to a HPPA box. Time to fix some FTBFS :-)
[16:12] <Riddell> cjwatson: kubuntu livefs hasn't built today as far as I can see
[16:13] <Riddell> the CDs themselves work fine
[16:14] <cjwatson> Riddell: so do you actually want landscape-client in your desktop seed? we took it out of Ubuntu
[16:14] <Riddell> not if ubuntu doesn't
[16:14] <Riddell> I'll remove it
[16:16] <slangasek> lool: yes, python-dateutil MIR appears to be able to wait until next week
[16:16] <cjwatson> <cjwatson@sarantium ~/src/ubuntu/seeds/kubuntu.intrepid>$ grep landscape *
[16:16] <cjwatson> <cjwatson@sarantium ~/src/ubuntu/seeds/kubuntu.intrepid>$
[16:16] <cjwatson> hmm
[16:16] <cjwatson> am I missing something?
[16:16] <slangasek> lool: pigment-python> if that's an FFe request, please file it via LP :)
[16:16] <Riddell> cjwatson: oh, it was in platform
[16:16] <Riddell> cjwatson: so it just needs a meta package rebuild I expect
[16:17] <cjwatson> ah, ok; sounds like an obvious soft-freeze exception :)
[16:17] <cjwatson> "make it work"
[16:18] <slangasek> tseliot: ok, I see this was discussed in bits of the scrollback that didn't highlight me, and is now resolved :)
[16:18] <Riddell> infact slangasek has already done kubuntu-meta
[16:18] <slangasek> cjwatson, Riddell: I already did a kubuntu-meta rebuild to drop landscape-client for the nonce ?
[16:18] <slangasek> yes
[16:19] <superm1> slangasek, none of those should have been installed in the livefs that was an oversight when it was committed to the wrong seed earlier, cjwatson committed a fix so that they're shipped as debs on the DVD instead
[16:20] <Riddell> slangasek: so do you know why the livefs still wants it installed?  was it just run too soon?
[16:20] <slangasek> Riddell: apparently so; I set up the build to trigger on the appearance of kubuntu-meta 1.90 on antimony, that seems to have not been enough for the livefs buildds
[16:21] <slangasek> so I'm respinning now
[16:21] <Riddell> slangasek: thanks
[16:23] <Riddell> slangasek: I see the kubuntu alternate CDs also have landscape and old kubuntu-desktop on them, could you rebuild them?
[16:23] <slangasek> Riddell: hrm, I did... wonder what's going on then :/
[16:25] <slangasek> oh, perhaps the .deb synced over before the Packages file or something
[16:25] <slangasek> which doesn't sound right, but bleh, rebuilding anyway
[16:55] <slangasek> superm1: btw, I never heard back about pushing a mythbuntu alpha-5 image set; I've respun now for alpha-6, can someone vet these in the next day or so?
[16:55] <superm1> slangasek, yeah we had issues with alpha5 disks so we never acked them
[16:55] <superm1> hopefully these are better now
[16:56] <slangasek> superm1: ah; an explicit nack would've gotten you daily images going again sooner :)
[16:56] <superm1> slangasek, sorry, we were focusing on "bigger" issues in the live images so the extra spins probably wouldn't have been tested for a few days.  i'll make sure you get an ack/nack on these images
[16:58] <Riddell> slangasek: kubuntu alternate looks good this time
[16:58] <ldp> no
[16:58] <ldp> wrong tab, sorry
[16:58] <slangasek> Riddell: yep - livefs build is also fixed, will post as soon as it's available
[17:09] <davmor2> Should log out still be on the task bar or should it be shutdown now?
[17:12] <persia> cjwatson: When creating the mobile.intrepid seeds, the entire contents of the ubuntu.intrepid seeds were copied in order to better preserve earlier history.  Is there any benefit to preserving seeds there that are not specific to any of the mobile flavours?
[17:12] <cjwatson> persia: no
[17:13] <persia> Great.  That will reduce merging efforts then :)
[17:13] <cjwatson> persia: are you actually using the mobile.intrepid seeds yet?
[17:13] <cjwatson> I mean, ubuntu-mobile is still built out of ubuntu.intrepid, I thought
[17:13] <cjwatson> generally people should not need to do seed merging any more
[17:13] <cjwatson> there are some exceptions but half the point of the split was to avoid the merge-o-rama
[17:14] <persia> cjwatson: Certainly.  They are the basis of the mobile-meta package.  It's still based on lp:~ubuntu-core-dev/ubuntu-seeds/mobile.intrepid, rather than somewhere under ~ubuntu-mobile-dev
[17:14] <cjwatson> oh, we did hoik ubuntu-mobile out of ubuntu-meta, OK
[17:14] <cjwatson> in that case we should stop ubuntu-meta building from universe ...
[17:15] <persia> Yes, probably :)
[17:15] <cjwatson> are you intending to switch to ~ubuntu-mobile-dev, and are you blocked on anything for that? last time I asked your team about that I think you were uncertain
[17:16] <persia> It's really pending some further activity or guidance on ArchiveReorganisation.  Until there is a firm plan for reorganisation, ubuntu-mobile-dev is only a placeholder group.
[17:16] <\sh> asac: yes...
[17:16] <persia> I'd personally be happy to move the seeds, but it's not blocking anything to keep them where they are.
[17:17] <\sh> asac: btw...libxcb-render-util0 is also used by nspluginwrapper somehow
[17:18] <asac> \sh: yeah. i also get that when running the adobe air installer:
[17:18] <asac> ./adobeair_linux_b1_091508.bin
[17:18] <asac> Error loading the runtime (libxcb-render-util.so.0
[17:18] <\sh> asac: I'll add the lib too...
[17:18] <persia> cjwatson: Another, only slightly related, question: from which seed is the list of packages for the alternate CD generated?  Is that the same as for the live CD, but just a different process of collecting the packages?
[17:18] <asac> \sh: can you try to run that installer before uploading? maybe we miss something else :/
[17:19] <cjwatson> persia: from the graph starting from ship
[17:19] <\sh> asac: I'll try :) it's a bit difficult, because source package is in company...and build machine is at home with less bandwidth ,->
[17:19] <cjwatson> persia: in the case of the server CD, from the graph starting from server-ship
[17:19] <\sh> asac: flashsupport is in
[17:20] <cjwatson> persia: the live CD works differently because we need to install lots of packages with apt, and then stick a little archive on the top that's composed of the stuff in ship-live
[17:20] <cjwatson> so we have to punt everything back through the archive via metapackages and tasks
[17:20] <\sh> asac: or did I miss something..libflashsupport.so is in /usr/lib32/ (at least in my build of the package)
[17:21] <persia> So live is more closely controlled by livecd-rootfs than from the seeds directly, and then extra stuffing comes from ship-live?
[17:21] <cjwatson> with the alternate/server CD, it's really simple 'cos you just run germinate, assemble a big list, and copy all those packages onto the CD. In theory anyway ...
[17:21] <cjwatson> persia: right, although most of the stuff that livecd-rootfs installs still ultimately comes from seeds
[17:21] <cjwatson> it's just that sometimes it's mediated either by developers uploading metapackages or by the archive synthesising Task fields
[17:21] <persia> But through meta packages, so it needs refreshed uploads to take effect?
[17:22] <persia> Ah.  Right.  Thank you.
[17:22] <cjwatson> not everything requires an upload, although it takes some experience to remember which is which
[17:22] <cjwatson> unfortunately, the archive currently won't regenerate Task fields unless the relevant pocket (e.g. intrepid RELEASE) is "dirty", which can only be done by uploading something to it
[17:22] <persia> What sort of seed changes would affect a liveCD without an upload of -meta (aside from the ship-live seed)?
[17:23] <cjwatson> this is usually not relevant since churn is so high, but is an occasional gotcha during freezes; it's a bug
[17:23] <cjwatson> adding anything (and waiting for the publisher to fill in Task fields, prodding it if necessary) would affect a live CD without an upload of -meta
[17:23] <asac> \sh: yes. but _thats_ the problem :)
[17:23] <asac> \sh: it has to go away -> remove it from there please
[17:23] <cjwatson> although if you're adding a package to a seed that has a corresponding metapackage, then you *should* upload -meta
[17:23] <\sh> asac: oh you mean, you want that go away ;)
[17:24] <asac> \sh: yes ... desperately ;)
[17:24] <asac> make it disappear forever :/
[17:24] <cjwatson> if you're removing a package from a seed with a corresponding metapackage, then -meta *has* to be uploaded for that to take effect, because otherwise germinate will see the dependency from the metapackage itself and fill that in when expanding dependencies :)
[17:25] <cjwatson> removals from seeds without metapackages (e.g. live) are just like adds
[17:25] <persia> OK.  That makes sense.  I'll have to learn more about Tasks before I've grasped it completely, but thank you for the explanation.
[17:28] <asac> \sh: its #192888 if you want to close it in changelog
[17:28] <\sh> asac: thx
[17:30] <asac> \sh: the summary is quite good if you dont mind a read ;)
[17:30] <psyke83> asac & \sh: it seems flash 10 may depend on additional libraries, so perhaps let's stall the ia32-libs update (so we can remove libflashsupport and add the new libs at once)
[17:30] <\sh> psyke83: you mean  #246911)
[17:30] <asac> psyke83: i want it to be removed independent of all the other issues
[17:30] <\sh> bug  #246911
[17:31] <\sh> libcurl3 nspr4 nss3 and ssh2 are already in for flash10
[17:31] <psyke83> \sh, yep, it seems that libxcb-render-util0 is also needed, and possibly others. I'll try to find out exactly what's missing for flash 10
[17:31] <asac> psyke83: ... without that we dont get real exposure for the pulse plugin in alsa on 64bit
[17:32] <\sh> psyke83: xcb isnow in too, but that's an issue with the new X it seems...finally flash10 doesn't work as expected...I can run our flash application but not our flex app with flash10..but with flash9 it works perfectly...
[17:33] <psyke83> asac: sure, I thought that \sh would want to address these concerns together, as ia32-libs is a >450mb source package :)
[17:33] <bryce> cjwatson: btw, timo says there's 8 revisions to acpi-support on top of what we have, including one change that mentions thinkpad X60 hotkey support
[17:33] <\sh> psyke83: that's not the problem right now :) 100MBit/s upload bandwidth is enough..if this is not enough I'll go to our GBit links
[17:33] <asac> i can certainly wait a day or two. but i just want to see this fixed. its been open for far too long. ill leave it to \sh to decide when to do it ;)
[17:34]  * \sh declares, that \sh is not Pitti - NG ;)
[17:36]  * \sh needs to fetch some intrepid archive mirrors for i386 and amd64 now...ia32-libs needs a while until upload
[17:39] <psyke83> \sh: I've already built an updated flash 10 deb, and nspluginwrapper now works on i386. Will I post the output of "/var/lib/flashplugin-nonfree/npwrapper.libflashplayer.so" in bug #246911, so you can determine missing libraries?
[17:39] <psyke83> \sh er, "ldd /var/lib/flashplugin-nonfree/npwrapper.libflashplayer.so"
[17:40] <asac> \sh: i certainly owe you a beer for removing that from that package ;) ... thanks
[17:41] <asac> psyke83: does nspluginwrapper (i386) work more or less well with latest flash?
[17:42] <psyke83> asac: no, unfortunately. For some reason, npviewer.bin seems to randomly segfault, e.g. when switching firefox tabs. I'll check it more thoroughly today (and flash is 100% stable without nspluginwrapper)
[17:42] <asac> psyke83: ok.
[17:43] <asac> psyke83: what we could try is to disable windowless mode in nspluginwrapper to see if its that code part (which is quite new) that causes the issues
[17:45] <psyke83> asac: I'm checking the source and don't see an obvious compile-time option. Do you mean to disable wmode in flash itself? (/etc/adobe/mms.cfg)?
[17:46] <psyke83> I'll try that anyway
[17:50] <asac> psyke83: err. no. i mean wmode in nspluginwrapper. you need to hack that out of it ;)
[17:50] <psyke83> ok
[17:50] <asac> there is no flag
[17:50] <asac> let me see
[17:51] <\sh> psyke83: yes sure :)
[17:51] <psyke83> ALLOW_WINDOWLESS_PLUGINS macro in npw-viewer.c
[17:52] <\sh> btw...if anyone has a good string to adobe, please tell them they should fix the proxy rtmpt bug
[17:54] <\sh> asac: http://bugs.adobe.com/jira/browse/FP-519 <- ;) that's why flashplugin is not usable in most of the corporate environments when using livecasting ,-)
[18:19] <tedg> slangasek: Where were those ical files you posted of the release schedule?  I can't seem to find the e-mail now.
[18:22] <cjwatson> tedg: http://people.ubuntu.com/~vorlon/IntrepidReleaseSchedule.ics http://people.ubuntu.com/~vorlon/UbuntuReleaseSchedule.ics
[18:23] <tedg> cjwatson: Thanks.
[18:26] <psyke83> \sh: more fun with ia32-libs, yay! See bug #246911 ;)
[18:31] <psyke83> \sh, I'm downloading ia32-libs source to see what needs to be added for flash 10. At the moment, we need libxcb-render-util0 and libxcb-render0. I'll add another comment when I've checked everything
[18:33] <\sh> psyke83: libxcb-render0 just added..
[18:33] <psyke83> the -util0 is necessary too, a user seems to have confirmed it in a duplicate
[18:34] <\sh> psyke83: already added ;) because I saw that this morning :)
[18:34] <psyke83> I'm afraid my bandwidth doesn't quite compare to yours... *sniff* :(
[18:34] <psyke83> cool
[18:35] <\sh> psyke83: please open a new bug for that...I can't change the status anymore (bug somehow in lp) and assign me pls
[18:36] <psyke83> \sh, sure. There was a duplicate, I'll unmark it
[18:36] <\sh> grmpf...never work with two browsers at the same time...untilboth have cookies
[18:39] <\sh> psyke83: in one of the last flashplugin installations I saw a libcurl3.so (I thought it was the last beta or the one release before) (on amd64) looks like that's gone now completly?
[18:40] <psyke83> \sh: yes, I noticed that too...
[18:40] <psyke83> would it be bad to keep libcurl in ia32-libs, in case the dependency re-emerges later on?
[18:41] <\sh> psyke83: no...I'll leave that in just to be safe
[18:43] <psyke83> \sh: bug #271392 is the new task, I have to wait for ia32-libs to download before I can double-check we have all the new required libs, but the ldd output is in the report if you want to check first
[18:45] <\sh> psyke83: I think tomorrow morning I'm able to upload again...Ihave to wait for my local intrepid archive mirror :)
[18:46] <lool> slangasek: After discussion with people here, I'm convinced we don't want to go with the new pigment/elisa; the current ones are the ones we want
[18:46] <psyke83> \sh: cool. It's asac that care, I don't even have 64bit hardware to test on ;)
[18:46] <psyke83> *cares
[18:47] <\sh> psyke83: /me cares too...that' s why I'm dealing with it now...I need a working flashplayer for work on amd64 ;)
[18:49] <asac> \sh: thank you!
[18:50] <psyke83> yeah, thanks!
[18:51] <psyke83> \sh, and to keep your blood pressure low, maybe you could consider getting rid of ia32-libs entirely for intrepid+1, and hook getlibs into packages instead: http://ubuntuforums.org/showthread.php?t=474790
[18:51] <psyke83> ;)
[18:53] <psyke83> \sh & asac: damn, I just remembered. If we switch to the PA ALSA plugins, that means that ia32-libs will need libasound2-plugins available too. Is that already part of ia32-libs?
[18:53] <\sh> psyke83: the real fun would be to have multi-arch-lib packages like lib32asound or something like this...that would help
[18:53] <persia> psyke83: Is that the best way to do it?  Previous discussion on the topic seemed to indicate that it might make sense to create special 32-bit libraries in the individual library packages where needed.
[18:54] <psyke83> persia, that means that maintainers for all packages would have to get involved in fixing 64bit bugs... not that I'm using that as an argument, but it could cause problems
[18:54] <\sh> CCFLAGS="-m32" is not a problem on amd64 ;)
[18:54] <persia> psyke83: That's true today: there are two supported 64-bit architectures for every library.
[18:55] <\sh> persia: that we need to do anyways.
[18:55] <psyke83> persia: sure, but the maintainers of the libraries can handle the problems, but maintainers of applications may not
[18:55] <psyke83> well maybe not, but it just crossed my mind
[18:55] <persia> \sh: Right, so adding -m32 for a special additional build for some libraries to kill ia32-libs wouldn't be that bad.
[18:56] <persia> The problem is it's never something anyone decides to do at the *beginning* of a release cycle.
[18:56] <\sh> persia: the problem is just time to fix the debian/control and the debian/rules file...
[18:56] <persia> \sh: Yep.
[18:56] <persia> \sh: And then we don't need ia32-libs anymore.
[18:56] <\sh> I did that some time ago for sles9
[18:57] <\sh> psyke83: you want libasound2-plugins as well in the ia32-libs ?
[18:57] <jdong> how does Redhat's multiarch yum system work?
[18:57] <\sh> jdong: yum can multiarch?
[18:57] <jdong> it just allows installing 32-bit distro's .rpm's on the 64-bit distro, right?
[18:57] <jdong> \sh: yeah, like yum install firefox.i386 is valid on AMD64
[18:58] <psyke83> \sh: yes... do you want me to open a new bug? It should be part of the task for bug #192888, though.
[18:58] <jdong> at least that's how I understand it
[18:58] <\sh> psyke83: just add it to #192888
[18:59] <psyke83> \sh, unfortunately I'm not sure what else may be necessary to ensure PulseAudio works for 32 bit application. I do know that libasound2-plugins *must* be included, though
[18:59] <jdong> I just feel a double-build for amd64 packages sounds a bit redundant when we already have 32-bit debs available for the i386 distribution :-/
[18:59] <jdong> it would be nice if there were some way of utilizing them
[18:59] <psyke83> jdong, yes, which is what makes getlibs useful - it grabs the actual 32bit debs and extracts the necessary libs, as far as I know
[19:00] <jdong> psyke83: yeah, but that sounds a bit hackish to me
[19:00] <jdong> I'd rather have dpkg -i some_32_bit_lib.deb do the "right thing"
[19:00] <\sh> jdong: when I read all the crap about the ia32-libs correctly, there were more problems then just i386 libs...the search for 32bit libs in apps is one of them
[19:00] <\sh> I mean libs are one thing, 32bit apps another
[19:01] <jdong> long-term is there some kernel-level magic we can do to make the system look 32-bit to 32-bit apps and 64-bit to 64-bit apps?
[19:01] <jdong> (this is really far fetched now :D)
[19:02] <persia> psyke83: getlibs uses --force-all which is almost always not what you actually want to do.
[19:02] <\sh> jdong: ms doesn't make it different...(only the weired namespace...32bit libs are now under system64 or so, and the 64bit libs under system32 to be backward compatible, afaik)
[19:02] <jdong> \sh: right
[19:02] <jdong> \sh: it doesn't sound like a very unreasonable idea.
[19:03] <jdong> \sh: MS does kernel magic when 32-bit apps run, right? They look around and see everything as 32-bit with the WOW64 system, right?
[19:03] <jdong> I was thinking it'd help if when a 32-bit app looks at /usr/lib it sees 32-bit binaries, but a 64-bit app looking there would see 64-bit binaries.
[19:03] <jdong> would require some evil magic lower-level though
[19:04] <\sh> jdong: I don't know actually...I just overheard some windows devs here...they are doomed sometimes because of that
[19:04]  * \sh is one of two people here in the office, who are using only ubuntu :) 
[19:05] <jdong> cool :)
[19:05] <jdong> often times I find myself having a 32-bit chroot that I have dchroot wrappers to go into
[19:05] <jdong> would be nice if that's automatically transparent
[19:06] <\sh> that makes me think: I'm the only one who got new hardware for the DC...and all the hardware (ok, not on the ciscos) is running on ubuntu hardy server
[19:07] <cathya> whats the topic about ms 32 bit
[19:07] <\sh> cathya: multi arch ;)
[19:07] <jdong> cathya: I walked in late, seems liek just how to handle multiarch
[19:08] <jdong> basically a manly whose-hack-is-less-hideous competition :)
[19:08] <cathya> ohh
[19:08] <cathya> ok
[19:08] <cathya> heh
[19:08] <hoonteke> What kind of testing framework do y'all have for the Ubuntu Desktop?
[19:09] <pwnguin> hoonteke: there was an IRC session during DeveloperWeek about that subject
[19:10] <hoonteke> pwnguin: okay, since I'm not a regular Ubuntu dev, is that irc session recorded somewhere?
[19:10] <pwnguin> yea
[19:10] <hoonteke> you have a link handy to which to pointer me?
[19:11] <pwnguin> https://wiki.ubuntu.com/MeetingLogs/devweek0809/AutoTests
[19:11] <hoonteke> brilliant, thanks.
[19:12] <persia> hoonteke: You may also be interested in discussions in #ubuntu-testing.
[19:12] <hoonteke> ooh, even more rooms to learn about.  hehe thanks
[19:13] <psyke83> \sh: I added a comment to #192888. I would recommend that you test it on your system - when you have a functioning Flash 10 (without libflashsupport), set PulseAudio as the default ALSA device (asoundconf set-pulseaudio). Then you'll see what libraries are necessary
[19:16] <\sh> psyke83: will do
[19:17] <psyke83> \sh, thanks for all this, I'm sure many people will appreciate your effort (if it works.. fingers crossed, heh)
[20:09] <pitti> hi
[20:09] <pitti> kirkland: got a minute to talk about update-motd?
[20:18]  * pitti hugs superm1; thanks for DKMSifying virtualbox!
[20:22] <ara> hey pitti
[20:22] <kirkland> pitti: please!
[20:23] <kirkland> pitti: what can I do for you?
[20:23] <pitti> kirkland: ah, was just typing a comment
[20:23] <kirkland> pitti: i've uploaded a couple of changes, hopefully addressing your concerns
[20:23] <kirkland> pitti: i see your point
[20:23] <kirkland> pitti: but i realy want to be able to start/stop/restart update-motd itself
[20:24] <kirkland> pitti: and running as a cronjob, not a daemon presents a unique challenge
[20:32] <alex-weej> during the Hardy dev cycle there was news about KVM becoming the "official" virtualisation tool of Ubuntu
[20:33] <alex-weej> i'm not exactly sure what tools I'm missing, but I install virt-manager, and it's quite buggy.
[20:33] <liw> alex-weej, buggy in what way?
[20:33] <alex-weej> well networking doesn't work properly unless you run it as root
[20:34] <alex-weej> and you can't add an SDL output, which means you're stuck with very bad graphical performance via VNC
[20:34] <alex-weej> VirtualBox OSE has SDL and it's very fast
[20:34] <alex-weej> (if you try and add an SDL display it throws exceptions)
[20:35] <alex-weej> these have both been problems since Hardy and through current Intrepid
[20:35] <alex-weej> i was wondering if i was actually missing something and was supposed to be using other tools
[20:36] <mathiaz> slangasek: https://wiki.ubuntu.com/IntrepidIbex/TechnicalOverview <- is the page tracking the release notes for alpha6 ?
[20:38] <liw> alex-weej, the #ubuntu-virt channel should be able to give you good answers, but let me point out that the virt-manager and virsh tools are just management layers, and the underlying kvm can do things the management tools don't want to do (at least currently); for example, you don't need VNC and can use SDL if you run kvm directly
[20:39] <alex-weej> liw: thanks, and good point. though for some reason I had assumed that the announcement of official support would come hand-in-hand with first-class configuration tools.
[20:40] <liw> alex-weej, they're... not so bad, when you run servers in your virtual machines :)  but yeah, I am not terribly happy with virt-manager myself, all the time
[20:41] <alex-weej> ok then i guess we should fix up virt-manager
[20:41] <alex-weej> i was just wondering if there was some secret program i didn't know about
[20:42] <liw> alex-weej, there may be, I am a novice with this stuff :)
[20:45] <slangasek> mathiaz: yes (now doing a slightly better job of it)
[20:46] <Riddell> cjwatson: does this look like something a recent upload might have caused? https://bugs.edge.launchpad.net/ubuntu/+source/ubiquity/+bug/271467
[20:46] <mathiaz> slangasek: ok - I'll a section about samba2.
[20:46] <slangasek> mathiaz: ok, thanks :)
[20:46] <mathiaz> slangasek: *samba3.2*
[20:49] <tkamppeter> pitti, hi
[21:11] <superm1> pitti, it's been on the TODO for a while, now i really hope that debian picks up dkms, the delta was huge to add in dkms support.
[21:12] <superm1> pitti, are there any other pending packages that should be DKMSified while i'm at it that you can think of off hand?
[21:12] <pitti> superm1: at least that's the only one which regularly causes trouble in kernel SRus
[21:12] <pitti> and I don't know any other important out of tree driver
[21:12] <pitti> (which we have packaged in the archive0
[21:14] <superm1> pitti, okay well if you think of any others, let me know.  ideally would like to have no necessity for additional SRU's beyond kernel itself and LRM for intrepid when there are kernel uploads :)
[21:15] <pitti> right, me too
[21:16] <ScottK> superm1: You might want to put out a request for inputs on ubuntu-devel.
[21:59] <cjwatson> Riddell: blink, nothing I did
[22:00] <kirkland> Ampelbein: ping
[22:00] <Ampelbein> kirkland: pong
[22:00] <Ampelbein> ?
[22:00] <kirkland> Ampelbein: hi, i see you registered an ecryptfs project on launchpad
[22:00] <kirkland> Ampelbein: and that you're listed as the maintainer?
[22:00] <davmor2> Riddell: no it's evands fault ;)
[22:01] <kirkland> Ampelbein: i'm co-maintaining ecryptfs-utils upstream, and we're looking at moving some of the functionality that was being provided by SourceForge to Launchpad (mailing lists, bugs, etc)
[22:01] <Ampelbein> kirkland: i just registered the project to have easier access when reporting bugs upstream
[22:02] <evand> Riddell: I just uploaded a fix.  I'm waiting on a Kubuntu CD download to fully test it.  Sorry about that.
[22:03] <kirkland> Ampelbein: would you be opposed to transferring ownership to me?  :-)
[22:03] <Ampelbein> not at all ;-)
[22:03] <Ampelbein> i did not want to make a hostile takeover
[22:04] <Riddell> evand: ah, sorted
[22:04] <Ampelbein> kirkland: done
[22:04] <kirkland> Ampelbein: you da man!  thanks a bunch...
[22:52] <slangasek> hmm, is ichthux actively maintained?
[22:52] <slangasek> (ichthux-desktop has deps on NBS kde packages, and the seeds are maintained outside of lp)
[22:52] <ScottK-laptop> slangasek: When I pointed out stuff that needs to be updated, they fixed it.
[22:53] <slangasek> ScottK-laptop: what's the most effective way to point this out?  The maintainer field on the package points to a single individual; email him?
[22:55] <cjwatson> slangasek: I seem to remember the maintainer is raphink, who's here
[22:55] <slangasek> oh
[22:55] <slangasek> yes, I was looking for a "txwikinger", ok :)
[22:55] <ScottK-laptop> Yes
[22:56] <slangasek> raphink: ping; can ichthux-meta be updated to migrate the deps on kghostview and khelpcenter to something suitably kde4-ish, please?
[22:56] <slangasek> cjwatson: thanks
[22:56] <ScottK-laptop> He's usually on kubuntu-devel
[22:56] <ScottK-laptop> slangasek: nixternal has also been involved in that one (at least sponsored there stuff).
[22:57] <ScottK-laptop> there/their
[23:23] <slangasek> calc: have you seen that the ooo-l10n build appears to be trying to create the libuno-cli-basetypes1.0-cil binary package in debian/rules? http://launchpadlibrarian.net/17420202/buildlog_ubuntu-intrepid-i386.openoffice.org-l10n_1%3A2.4.1-8ubuntu1_FAILEDTOBUILD.txt.gz
[23:41] <calc> slangasek: yes, i will be uploading a 9ubuntu1 soon and will fix that along with some other issues
[23:41] <slangasek> ok
[23:41] <calc> slangasek: didn't want to do it during freeze ;-)
[23:41]  * slangasek makes vague hand gestures
[23:48] <wgrant> jcastro: I can use ALLCAPS to complain against an ALLCAPS EULA if I feel like it, TYVM.
[23:49] <jcastro> whatever floats your boat
[23:50] <wgrant> They deserved a taste of their own medicine.
[23:50] <slangasek> "they"?
[23:51] <wgrant> Good point.
[23:51] <slangasek> awesome, I'm making points without knowing it
[23:52] <wgrant> That's the best way to do it.