[00:03] <cjwatson> kwwii: bug 286677, FYI
[00:04] <cjwatson> (might not be as high as Medium, I don't know if it has other consequences)
[00:06] <kwwii> cjwatson: dooh, another stupid mistake
[00:07] <kwwii> cjwatson: easy to fix, silly to make, I made the source package from the wrong dir
[00:07] <kwwii> cjwatson: fixed first thing tomorrow
[00:07] <kwwii> and I am kicking myself in the butt for not noticing
[00:07] <cjwatson> kwwii: thanks
[00:08] <cjwatson> kwwii: might not make RC at this point, what's the consequence of that?
[00:08] <cjwatson> we could probably slip it into final if the change is really easily reviewable
[00:08] <kwwii> cjwatson: if it causes a noticeable error somewhere it is worth fixing
[00:08] <cjwatson> oh, I agree
[00:09] <kwwii> and the fix is really easy, just remove the crap I added trying to work around the panel background stuff
[00:09] <cjwatson> I was just wondering if it would cause the desktop to visibly explode or anything
[00:09] <kwwii> I know exactly what I did, I just made the source package from the wrong dir
[00:09] <kwwii> really, really dumb on my part
[00:09] <cjwatson> mkdir empty && cd empty && dh_make? ;-)
[00:10] <cjwatson> anyway, bed
[00:10] <lamont> superm1: ~/WHAT?
[00:10] <kwwii> cjwatson: well, I did change things after that change...more like re-applying the changes I added today to the bzr repo and making new source packages
[00:11] <kwwii> this really makes me sorry for the work pitti did including it...he trusted me (I did not notice any problems but my system is so messed up in the meantime I doubt it notices anything)
[00:11] <kwwii> I hope he is has as much patience as I do time to make mistakes
[00:12] <kwwii> cjwatson: thanks very much for noticing this and bringing it to my attention
[00:12] <kwwii> I will fix it asap
[00:20] <kwwii> cjwatson: here is a new source package which fixes my (stupid) mistake:
[00:20] <kwwii> http://sinecera.de/human-theme_0.28.4_source.changes
[00:22] <StevenK> kwwii: A debdiff with the changes would help a lot
[00:24] <kwwii> StevenK: the only difference is that I removed one definition of the panel bg (which I also forgot to add to bzr and therefor the problem)
[00:25] <kwwii> I can recreate the old stuff (already changed it locally and added it to bzr)
[00:25] <kwwii> if it is really important
[00:26] <kwwii> I'll take care of this first thing tomorrow
[00:26] <kwwii> in fact, I noticed I made the same mistake twcie
[00:26] <kwwii> twice
[00:27] <kwwii> ignore that url, I will fix it tomorrow and include a debdiff
[00:27] <kwwii> sorry for the wasted time
[00:31] <superm1> lamont, ah sorry :) ~/.asoundrc
[00:31] <lamont> ta
[00:32] <superm1> slangasek, i'm not convinced debian/shlibs.local will resolve this, as indicated by: http://paste.ubuntu.com/60304/plain/
[00:33] <NCommander> ah, superm1
[00:34] <NCommander> ugh
[00:34]  * NCommander twichs
[00:35]  * NCommander checks the libstdc++ source package
[00:35] <superm1> well it provides the appropriate shlibs
[00:35] <superm1> but it's in universe and wont be available at package build time
[00:35] <superm1> so debian/shlibs.local was hopefully going to work around as necessary
[00:36] <NCommander> superm1, why do you need such an old libstdc++ ?
[00:37] <superm1> i dont, but AMD seems to think their library does
[00:37] <superm1> gotta work around their mess unfortunately
[00:37] <NCommander> Is this a multiverse package we're talking about?
[00:37] <superm1> it's multiverse, but should be in restricted
[00:37] <NCommander> I assume no source
[00:37] <superm1> once this is sorted out, the source package will be restricted
[00:37] <superm1> and the binary will be multiverse
[00:38] <superm1> yeah no source :(
[00:38] <NCommander> (why is it in multiverse?)
[00:38] <NCommander> Argh
[00:38] <NCommander> What is it specifically?
[00:38] <superm1> graphics driver and some acceleration libraries
[00:38] <NCommander> Oh
[00:38] <NCommander> More ick
[00:38] <superm1> the driver will be in restricted, the libraries in multiverse
[00:39] <NCommander> If its just premade binaries, why does it need to build depend, you can explicately set the depends if shlibs can't find it for some reason
[00:39] <NCommander> or is it half source available, half no-source?
[00:40] <kwwii> StevenK: the debdiff does not offer anything..the only change is two lines in two gtkrc's
[00:40] <NCommander> ^- superm1
[00:41] <superm1> NCommander, well it doesn't need build depends, but the shlibs should be checked dynamically because they can change release to release
[00:41] <superm1> NCommander, (and actually have in the past)
[00:41] <superm1> but i'm not sure why shlibs.local isn't overriding like it should be in this case
[00:42] <NCommander> Simply build-dep on the non-dev package
[00:42] <NCommander> That will get the .shlib file installed from libstdc++3, but prevent gcc 3.3 from being pulled in
[00:43] <NCommander> Its probably the sanest solution of the bunch
[00:43] <superm1> NCommander, well the problem is that all of gcc-3.3 is in universe
[00:44] <NCommander> OH!
[00:44] <NCommander> The restricted package is the one tha thas the issue
[00:44] <NCommander> The only sane thing you can do is to promote libstdc++3 by itself. If the driver depends on it, I don't think you can work around that
[00:45] <superm1> well the idea was that the "source" package would live in restricted, and its binary graphics driver would too.  this library would be in multiverse and thus allowing libstdc++5 to be in universe still
[00:46] <kwwii> StevenK, cjwatson: debdiff is apparently supposed to be run on the dsc files? I tried it with the debs but that spits out nothing
[00:46] <NCommander> superm1, *twich*
[00:48] <superm1> NCommander, yeah.  but this shlib-deps problem aside, it'd be a "functional" solution
[00:48] <kwwii> StevenK, cjwatson: whereas the debdiff for the dsc files is this: http://sinecera.de/human_theme.debdiff
[00:48] <kwwii> which shows the necessary changes
[00:48] <bryce> superm1: tjaalton reviewed it; I think it needs tested/validated first to make sure it does indeed fix the issue
[00:48] <NCommander> Can a package from main/restricted create binaries in universe/multiverse?
[00:48] <NCommander> superm1, thats against Debian policy for instance ...
[00:48] <bryce> superm1: if you could test it and report that it does solve the issue, that would help
[00:49] <NCommander> (well, main/non-free, you can do main/contrib)
[00:49] <superm1> bryce, would you mind pushing it to a PPA?
[00:49] <bryce> superm1: there was a small alteration timo suggested, to make it only pick -vesa on non-ppc, etc. that should be easy enough to add
[00:49] <superm1> NCommander, well slangasek said that would be okay to do.
[00:50] <superm1> NCommander, and actually i know of a package i already touch that does something like that
[00:50] <superm1> NCommander, the lirc source package is in main, and has a library in main.  it has a few binary packages in universe however
[00:50] <NCommander> point taken
[00:51] <ScottK> NCommander: If any binary is in Main, the source needs to be in Main, but unneeded binaries can and should be in Universe.
[00:51] <superm1> NCommander, so these points aside, that error i posted, do you see anything blatant that stands out about what's wrong with that method of working around this?
[00:51] <ScottK> NCommander: See the Sendmail package for an example.
[00:51] <NCommander> superm1, give me a minute
[00:52] <NCommander> I normall have issues groking shlibs files in general
[00:52]  * NCommander whacks superm1
[00:52] <NCommander> wait
[00:52]  * NCommander unwhacks
[00:56] <kwwii> StevenK: is that debdiff good enough? (/me is just learning deb packaging, it is an honest question)
[01:04] <superm1> NCommander, so perplexing eh?
[01:05] <NCommander> superm1, what happens when you add -v to dpkg-shlibsdeps?
[01:05] <superm1> http://paste.ubuntu.com/60316/
[01:05] <NCommander> Uh
[01:06]  * NCommander figured it out and promptly smacks superm1
[01:06] <NCommander> shlibs.local requires the library to be installed
[01:06] <superm1> gah.
[01:06] <NCommander> It won't work if libstdc++5 isn't installed
[01:06] <superm1> well that's counterproductive then
[01:07] <NCommander> shlibs.local is designed to solve a very specific problem :-)
[01:07] <superm1> NCommander, okay well then I think the only solution is to hardcode the shlib dependencies, and -xlibAMD when running dpkg-shlibdeps
[01:07] <superm1> agreed?
[01:45] <slangasek> superm1: -Ldebian/shlibs.local should be unnecessary and may be confusing it
[01:46] <superm1> slangasek, i added that because it wasn't working
[01:46] <superm1> slangasek, but it's the same behavior without it there
[01:47] <slangasek> superm1: hmm.  ok, then it's failing because it wants to find the library first before honoring the shlibs; grr, I don't think it did that before buxy rewrote it
[01:47] <superm1> slangasek, well in any case, this library only has two shlibdeps anyhow, libc6 and libstdc++5.  will just have to watch in the future if that changes
[01:48] <slangasek> ok
[01:48] <superm1> i caught another problem with ia32-libs similar by messing with this though, so it was a good exercise
[01:48] <superm1> i'll push it up
[01:48] <slangasek> sounds good
[01:48] <kirkland> anyone know why the manpages-posix-dev package is in multiverse?  <- cjwatson ?
[01:50] <slangasek> kirkland: it's in non-free in Debian and probably wasn't revisited?
[01:50] <kirkland> slangasek: yeah, hasn't been touched in ~3 years
[01:51] <kirkland> okay, it's not hurting anything ...  just dealing with some wonkiness for the manpage repository
[02:56] <ScottK> lool: Did you see there's a gedit-plugins upload pending?  Is it one we want?
[04:32] <rascov> If I want to send a patch of GNU screen to Ubuntu official package, what should I do? (just porting new function from FreeBSD)
[04:42] <persia> rascov, https://wiki.ubuntu.com/Bugs/HowToFix might be a good place to start.
[04:44] <Chipzz> rascov: also, #ubuntu-motu (cfr topic) ;)
[04:45] <rascov> persia Chipzz: thanks :)
[04:48] <Chipzz> rascov: though the changelog mentions CVS head was merged at Jun 02, 2008
[04:49] <Chipzz> dunnow how recent that new function is
[04:52] <rascov> In Ubuntu, is there a person like port maintainer or commiter in FreeBSD ?
[04:55] <ScottK> rascov: In Ubuntu it's mostly done on a team basis rather than specific people for specific packages.
[04:59] <rascov> Should I contact the team if I wish to add a new function ?
[04:59] <ScottK> rascov: Generally the best thing is to file a bug against the package with your patch.
[05:03] <RAOF> Hey, has nvidia-glx-96 been updated to actually work with Xserver 1.5?
[05:05] <RAOF> It seems jockey is recommending nvidia-glx-96 to someone, and I thought we'd stopped doing that on the basis that it won't work.
[05:09] <rascov> ScottK: I see, thanks
[05:15] <tjaalton> superm1, bryce: also, the patch should be verified to not force vesa when not using an xorg.conf
[05:15] <RAOF> In fact, why are the nvidia-glx-{96,78} in the archives at all?
[05:16] <RAOF> Are we hoping nvidia will release a drivers that support 7.4 and we can push them in?
[05:18] <tjaalton> "they are working on it"
[05:18] <tjaalton> or something like that
[05:19] <tjaalton> correct quote would be; aaronp: "I'm working on it"
[05:19] <tjaalton> but who knows when that happens
[05:21] <RAOF> Indeed.  What do we _do_ about this?
[05:22]  * tjaalton twiddles thumbs
[05:22] <RAOF> There are currently two large packages in the archives which do nothing but break 3d.
[05:22] <tjaalton> I think they are waiting there for an SRU
[05:25] <ScottK> RAOF: xserver-xorg-video-radeonhd isn't one of those packages is it?
[05:26] <superm1> just like fglrx was going to wait for an SRU if it ever came
[05:26] <RAOF> ScottK: No; that can only break 3d for people with ATI cards; nvidia-glx breaks it for _everyone_ :P
[05:26] <ScottK> Ah.
[05:27] <RAOF> And that driver also has the advantage of a possibility of working.
[05:27] <ScottK> Because there was a user, who I generally consider reliable, who reported 1.2.3 working with 3D
[05:28] <RAOF> I don't know if our mesa is new enough for that, but I believe the very latest radeonhd _
[05:28] <RAOF> + mesa + drm _does_ do 3d.
[05:41] <tjaalton> radeon/radeonhd for r5xx has had 3d since mesa-7.1, and we have 7.2
[05:49] <dholbach> good morning
[05:52] <RAOF> tjaalton: Really?  Cool.  You learn something new everyday :)
[05:53] <RAOF> And forget it just as quickly, sadly.
[05:58] <dholbach> doko: do you haven an idea about this:
 Setting up five-a-day (0.58~hardy1) ...
[05:58] <dholbach>  pycentral: pycentral pkginstall: not overwriting local files
[05:58] <dholbach>  pycentral pkginstall: not overwriting local files
[06:25] <StevenK> dholbach: "not overwriting local files" is a hint
[06:28] <dholbach> StevenK: maco was having these problems in #ubuntu-bugs
[06:28] <StevenK> five-a-day is trying to install files that already exist
[06:30] <dholbach> StevenK: it was an upgrade :)
[06:31] <StevenK> Hum
[06:51] <StevenK> Argh, libcamel in NBS again?
[07:20] <fabbione> kees: ping?
[07:22] <slangasek> StevenK: upload the reverse-deps and we can make it go away? :)
[07:24] <fabbione> kees: please let me know (via email.. i guess you are deeply asleep) if you need patches for CVE-2008-4192, CVE-2008-4579 and CVE-2008-4580
[07:25] <fabbione> kees: the fixes upstream are extremely simple but i just don't have time to look into all the packages in Ubuntu
[07:28] <StevenK> slangasek: Plotting to
[07:48] <pitti> Good morning
[07:48] <\sh> moins pitti :)
[07:48] <StevenK> Morning pitti
[07:49] <lool> morning
[07:49] <lool> ScottK: I have no idea about gedit-plugins; I saw some discussion around it on #ubuntu-desktop yesterday
[07:51] <lool> ScottK: http://paste.ubuntu.com/60403/
[07:51] <lool> Now you know as much as I do
[07:53] <StevenK> pitti: Could you be tempted to approve my linux-lpia upload? :-)
[07:55] <pitti> kirkland: ok, I'll reply in the bug
[08:01] <pitti> kirkland: done
[08:01] <pitti> StevenK: why doesn't linux-lpia simply depend on linux-firmware instead of shipping a copy?
[08:01] <slangasek> isn't that exactly what it does?
[08:01] <StevenK> pitti: It does
[08:02] <slangasek> pitti: sorry, just accepted linux-lpia-meta
[08:02] <pitti> StevenK: ah, then the changelog is confusing
[08:02] <pitti> slangasek: no problem, I was just curious about what it actually does
[08:02] <StevenK> It meant the binary packages linux-lpia{,compat}
[08:03]  * StevenK looks at the NBS list for libcamel
[08:03] <pitti> StevenK: you mean you moved the dependency to another package?
[08:03] <StevenK> pitti: It moved from linux-lpia to linux-image-lpia, to mirror what linux-meta does
[08:04] <pitti> StevenK: right, that makes sense
[08:05] <pitti> lool: libvisual-plugins pulls in jack, that needs to be dropped when moving it to main
[08:06] <mdke> if someone could sponsor an upload for bug 286829 I'd be grateful
[08:06] <pitti> kwwii: no problem; well, I didn't upload it completely blindly, I built, installed, and restarted my session, and it still looked okay :)
[08:07] <pitti> kwwii: anyway, you need to tell me what this bug is actually all about; to me, it just looks like if someone used the temporarily broken package with the wrong file name "Darkroom", he'd get that on upgrade
[08:07] <lool> pitti: Ok
[08:07] <pitti> kwwii: looking at your new package now
[08:08] <pitti> StevenK: libcamel NBS> eww GNOME 2.24.1
[08:08] <StevenK> pitti: Yes.
[08:09] <pitti> StevenK: libtotem-parser is part of gnome, so seb128 will do that himself
[08:09] <slangasek> it's already done
[08:09] <pitti> but we should do that evolution-jescs thing
[08:09] <pitti> slangasek: oh, great
[08:09]  * StevenK removes totem from his list
[08:10] <StevenK> My no-change rebuild of evolution-jescs builds
[08:11] <StevenK> Just waiting for mail-notification and I can upload them
[08:11] <slangasek> though it was done a bit later than the rest of the stuff in main, so there was an intervening CD run that's oversized because it has two copies of libcamel on it :-P
[08:11] <StevenK> Hah
[08:12] <pitti> kwwii: I added (LP: #286677) to the changelog, please do in bzr, too; before I upload this, can you please explain why the bg_pixmap definition was introduced, and why removing it is the right thing?
[08:13] <mdke> slangasek: how tight is CD space at the moment? the recent build i did of the new version of ubuntu-docs is 1.7MB bigger than the version in the archive
[08:15] <mdke> slangasek: if that's a problem, we'd have to look at reducing the package
[08:15] <StevenK> pitti, slangasek: Both my no-change rebuilds build locally, uploading them.
[08:17] <slangasek> mdke: we have approximately zero space for new stuff - why are the docs so much bigger suddenly?
[08:17] <mdke> slangasek: basically, ubuntu-docs ships translations which are 40% translated or more, that means that in the import of translations I did from Rosetta, people have made a lot of progress on translation
[08:17] <mdke> slangasek: we can try adjusting the figure of 40% upwards in order to reduce the package
[08:18] <slangasek> mdke: and they're not shipped in separate binary packages?
[08:18] <mdke> slangasek: no, it's all in ubuntu-docs
[08:18] <slangasek> mdke: what this comes down to is that in order to find you 1.7MB of free space on the CDs for the doc translations, I would have to drop langpacks
[08:19] <slangasek> that doesn't sound like a winning trade to me
[08:19] <StevenK> pitti: How can I debug why CK run in Xsession.d doesn't set DISPLAY or active?
[08:19] <mdke> slangasek: I guess we should try and see how big ubuntu-docs works out with shipping translations which are 50% complete, rather than 40%
[08:20] <pitti> reallistically, a 40% complete documentation pretty much requires the reader to understand English anyway..
[08:20] <mdke> yes, I wouldn't have a problem with going up, even to 60%
[08:20] <pitti> I thought for that reason we set the bar to like 70% earlier?
[08:20] <pitti> but yeah, I'm fine with adjusting it to min(sanity,cd space)
[08:21] <mdke> it's always been 40% in previous releases, mainly to encourage translations, but if there is an issue with disk space, it makes sense to increase it
[08:21] <pitti> StevenK: is $DISPLAY actually set in 90consolekit?
[08:21] <mdke> slangasek: unfortunately, ubuntu-docs takes about an hour to build and I have to go to work, but I will leave it running a couple of test builds at 50, 60, and 70%
[08:22] <StevenK> pitti: Lemme check
[08:24] <mdke> slangasek, pitti: I guess I'll drop the request for sponsoring until that further investigation is done
[08:25] <StevenK> pitti: Yes, it is set
[08:25] <StevenK> pitti: As in, stuffing a echo "$DISPLAY" > /tmp/foo in 90consolekit results in :0
[08:27] <emgent> morning people
[08:56] <pitti> james_w: the CK fix sounds like an excellent SRU candidate
[08:56] <pitti> StevenK: hm; then I'm afraid this needs a gdb session
[08:57] <pitti> StevenK: let me try it here with the Xsession.d script
[08:57] <james_w> pitti: if it's not RC material then I agree.
[08:57] <StevenK> pitti: Bug 285054 updated
[08:57] <pitti> james_w: we could upload it right after RC, too
[08:58] <seb128> hey james_w pitti
[08:58]  * pitti hugs seb128, great GNOME marathon yesterday!
[08:58]  * seb128 hugs pitti, thanks
[08:59] <pitti> StevenK: a-haa! XDG_SESSION_COOKIE is already set
[08:59] <james_w> pitti: that's your call. I would appreciate review and testing, as I'm not completely confident
[08:59] <seb128> pitti: we still have some slots for non-CD updates today?
[08:59] <james_w> hey seb128
[08:59] <james_w> great work on .1 :-)
[08:59] <pitti> seb128: -> slangasek; but since most of main is on the DVD, the answer might be "no"
[08:59] <seb128> ah DVD
[08:59] <StevenK> pitti: Right
[08:59] <StevenK> pitti: Now to figure out why it's set
[09:00] <slangasek> yes, those big evil fat CD things
[09:00] <seb128> slangasek: hey
[09:00]  * slangasek waves
[09:00] <seb128> so I'm not clear what we should do from now
[09:00] <pitti> StevenK: how do you start X?
[09:00] <StevenK> pitti: Via startx
[09:01] <pitti> StevenK: from an init script?
[09:01] <lool> pitti: I'm pretty sure it's the xinit support i'm pointing at in the bug report
[09:01] <StevenK> pitti: An upstart script
[09:01] <lool> StevenK: Check out xinit from git and see whether they merged support for CK
[09:01] <lool> it should be reverted from xinit, it can not work from there
[09:01] <pitti> StevenK: the only other thing that creates sessions I'm aware of is libpam-ck-connector
[09:01] <seb128> slangasek: will some updates be accepted after rc and should we work on SRUing now?
[09:01] <pitti> lool: yes, I agree; wasn't aware of that
[09:02] <pitti> but there shouldn't be a PAM session in upstart scripts or init scripts, so that wouldn't be it
[09:02] <lool> I commented as such in the upstream bug, but I bet they merged the patch nevertheless
[09:02] <seb128> slangasek: the new pidgin (changelog on http://developer.pidgin.im/wiki/ChangeLog) for example
[09:02] <slangasek> seb128: some will be accepted after RC, to be sure; including the bits of GNOME that haven't made it through yet
[09:02] <lool> pitti: Actually we use "su"
[09:02] <seb128> slangasek: ok thanks
[09:02] <pitti> lool: !
[09:02] <lool> So there might be a pam session
[09:02] <pitti> lool: that uses PAM
[09:02] <StevenK> Maybe we want to use su - -l
[09:03] <lool> No
[09:03] <lool> pitti: is pam-ck the default nowadays?
[09:03] <pitti> lool: yes
[09:04] <lool> ohh
[09:04] <lool> that's probably the issue then
[09:04] <pitti> /etc/pam.d/common-session
[09:04] <pitti> sessionoptionalpam_ck_connector.so nox11
[09:04] <pitti> eww, seems weechat doesn't like tabs
[09:04] <lool> Then we can simply clear the CK session when launching startx; env ignore or seomthing
[09:05] <lool> StevenK: Try with env -u XDG_SESSION_COOKIE in the upstart job
[09:05] <pitti> lool: that would be a working hack, I just wonder why ck-connector should be made more clever
[09:05] <StevenK> lool: Geh? In which bit?
[09:05] <lool> pitti: Hmm what we would need is for the Xsession.d script to check whether there's a running CK session and provision the DISPLAY info in it
[09:06] <lool> Instead of just considering presence/abscence of a running session
[09:06] <pitti> right
[09:06] <pitti> since we're going to start a new one for a different tty
[09:06] <lool> StevenK: /etc/event.d/session; use env -u XDB... between su and startx
[09:08] <StevenK> Hm. That didn't seem to help, and I still have XDG_SESSION_COOKIE in the env dump
[09:08]  * StevenK forcibly restarts the job
[09:12] <StevenK> lool: "env -u XDG_SESSION_COOKIE; startx -- -br" doesn't look to help
[09:13] <lool> StevenK: Without ;
[09:14] <StevenK> That seems to give me a session that sets x11-display
[09:14] <lool> StevenK: is it active?
[09:15] <StevenK> Yes
[09:15]  * StevenK checks if he can mount a USB key
[09:16] <StevenK> I can! \o/
[09:16] <StevenK> pitti: Does that hack not make you ill?
[09:18] <pitti> StevenK: It's not exactly aesthetically pleasing, but *shrug*, if it works :)
[09:19] <pitti> StevenK: my preferred solution would be to fix 90consolekit to call ck-launch-session if there's an existing cookie which does not belong to an X11 one
[09:19] <pitti> but mapping cookies to sessions isn't possible as normal user
[09:20] <pitti> so we'd need some proper support for this in CK itself
[09:20] <pitti> james_w: ah, that CK test case works tremendously well
[09:21] <StevenK> pitti: Sure, so this is a last-minute OMG-it-works-ship-it hack
[09:22] <pitti> StevenK: absolutely fine for me
[09:28] <lool> StevenK: Hmm where do you say you get this?  in mid?
[09:28] <lool> StevenK: it's not supposed to pull libpam-ck-connector
[09:28] <lool> It's derived from minimal, not desktop-common
[09:28] <StevenK> lool: Yes
[09:28] <lool> StevenK: Is this a recent install, or an upgraded system?
[09:28] <StevenK> lool: This is the most recent daily
[09:29] <lool> I think it's worth fixing it for systems with libpam-ck-connector (like mine, I use startx!)
[09:29] <StevenK> libpam-ck-connector is installed
[09:29] <lool> StevenK: Weird, any rdeps?
[09:29] <lool> Oh consolekit
[09:29] <StevenK> Yup
[09:30] <StevenK> We probably shouldn't fiddle with that
[09:30] <lool> Well I seriously think we don't need it in mid/mobile
[09:31] <lool> But that's not a fix, and it's late to drop it in this cycle anyway
[09:31] <pitti> StevenK, lool: FWIW, I'm fine to drop the Recommends: libpam-ck-connector from consolekit
[09:31] <lool> pitti: I think it should be downgraded in next cycle
[09:31] <lool> As to allow us not to pull it
[09:32] <pitti> lool: *-desktop pulls it in already anyway
[09:32] <lool> Yup
[09:32] <pitti> lool: depends; if we upload james_w's patch soon, we can as well drop it
[09:32] <lool> pitti: what's the patch?  bug #?
[09:33] <pitti> lool: bug 269651
[09:37] <lool> Nice one
[09:50] <StevenK> pitti: Could you be convinced to accept ubuntu-mid-default-settings and contacts in unapproved?
[10:06] <pitti> StevenK: done
[10:09] <StevenK> pitti: Danke
[10:11] <tjaalton> pitti: hey, I'm having second thoughts about not installing the wacom.fdi by default.. people seem to be more upset about not being able to use their stylus OOTB than making it more complicated to get the full functionality working (eraser/cursor etc). So reverting the change would fix bug 282203, ok to upload?
[10:20] <pitti> StevenK: please close bug 285054 manually, it didn't have a package attached
[10:21] <pitti> tjaalton: you can upload, but I can't accept it right now; this needs to wait until after RC
[10:21] <pitti> tjaalton: also, I'm not sure whther this kind of change is appropriate now; we had the current setup for quite a while, so changing it now might introduce other regressinos?
[10:22]  * pitti actually likes the term "regressino" as a "small regression"
[10:22] <tjaalton> pitti: it was changed since beta
[10:23] <tjaalton> pitti: also, bug 261977 is reviewed and fix committed
[10:23] <tjaalton> but post-RC is fine
[10:24] <pitti> tjaalton: ok, ok; worth discussing then, can you please upload and subscribe ubuntu-release?
[10:24] <pitti> tjaalton: 261977> nice, thanks; will go in post-RC, too
[10:25] <tjaalton> pitti: sure, will do
[10:29] <persia> pitti, abogani asked me if http://paste.ubuntu.com/60432/ would be an acceptable debian/copyright for l-r-m-rt.  WOuld you accept that, or do you want something more traditional?
[10:30] <pitti> persia: ah, it has the madwifi license/copyright now, good; WDYM with "more traditional"?
[10:31] <pitti> persia: the ltmodem copyright isn't entirely clear, but then again our main l-r-m isn't either
[10:31] <pitti> so, good enough for me
[10:31] <persia> pitti, I can't find any license reading the source for ltmodem.  In good news, AnAnt is finalising a dkmx+modass compatible multiverse package to let us drop that for jaunty.
[10:32] <persia> Thanks.  I'll upload.  For reference "more traditional" would be something following http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html
[10:33] <pitti> persia: ah, ok; let's not be too fussy about it
[10:34] <persia> uploaded.
[10:51] <pitti> mvo: does the screensaver now actually work for you? I just get a black screen
[10:54] <mvo> pitti: it did in my tests, let me double check
[10:57] <mvo> pitti: what screensaver is checked in your screensaver preferences?
[10:57] <mvo> pitti: what card/driver?
[10:57] <pitti> mvo: "Weltraum"
[10:57] <pitti> mvo: 945GM/intel
[10:58] <pitti> mvo: in the screensaver prefs, the preview works fine, but ctrl+alt+l or gnome-screensaver-command -a just give me a black screen
[10:58] <pitti> mvo: it doesn't immediately return any more, so the "does not activate" part is indeed fixed
[11:15] <mvo> pitti: I just tested on my nvidia system and it seems to be ok. but I'm upgrading my intel system as we speak
[11:28] <StevenK> pitti: Sure, closing
[11:30] <mvo> pitti: hm, seems to work for my intel system, strange
[11:30] <mvo> pitti: I keep a open eye on the bugreports
[11:32] <pitti> mvo: ok, thanks for testing
[11:35] <mvo> pitti: could you please run "gnome-screensaver --debug --no-daemon" and sent me the output ? that might give me a clue
[11:35] <mvo> (you probably have to kill the running one fist)
[11:36] <pitti> mvo: http://paste.ubuntu.com/60453/ is after killing, starting in debugging, and gnome-screensaver-command -a
[11:37] <pitti> mvo: oh, maybe it's because my original CK session was ruined (I did some CK debugging and killed it several times)
[11:38] <pitti> mvo: I'll try it again with a good session in a bit
[11:40] <mvo> pitti: thanks! the line "[gs_job_start] gs-job.c:446 (12:35:58):	 No command set for job." looks a bit supicious
[11:40] <mvo> pitti: that looks like for some reason g-s-s thinks that it does not need to start a screensaver (or can not?)
[11:45] <alex-weej> where has the bluetooth services control gone?
[11:46] <alex-weej> the new bluetooth preferences from bluez 1.8 is missing the services tab
[11:46] <alex-weej> and there's no discoverable way to enable file transfers now
[11:47] <persia> alex-weej, Which flavour?
[11:47] <alex-weej> 8.10
[11:47] <persia> alex-weej, Flavour, not release.
[11:47] <alex-weej> Ubuntu
[11:47] <persia> e.g. Mythbuntu, Xubuntu
[11:47] <alex-weej> Ubuntu Original, Organic, Full Fat
[11:49] <Ng> alex-weej: I see that too
[11:49] <persia> Oh.  RIght.  I suspect that's bug #283064.
[11:49] <alex-weej> persia: but also things like i can't set up input devices or anything
[11:50] <persia> alex-weej, That's surprising.  Try clicking the bluetooth applet : it should open the device wizard.
[11:51] <alex-weej> i have already "set up" the weejPhone
[11:51] <alex-weej> so it doesn't show up in the list
[11:52] <alex-weej> setting it up again just says it was successfulyl set up
[11:52] <alex-weej> no way to configure anything
[11:52] <alex-weej> as an input device, audio device, network device
[11:52] <persia> What are you trying to configure?
[11:52] <alex-weej> anything. like an input device.
[11:52] <persia> Ah, it is supposed to auto-detect that from the capabilities available.  If your device supports multiple capabilities, and it doesn't work, file a bug.
[11:53] <alex-weej> hm, i can start the remote control on my device and use it fine
[11:54] <alex-weej> it just seems weird that there is no way to configure any of this
[11:54] <alex-weej> it's all-or-nothing
[11:56] <persia> It's supposed to just work.
[13:00]  * StevenK selectively empties
[13:00] <StevenK> Err
[13:00]  * StevenK selectively empties NBS
[13:01] <NCommander> morning StevenK
[13:01]  * StevenK waves
[13:21] <pitti> mvo: still no screensaver love with a fresh session
[13:21] <mvo> pitti: could you give me the gconftool-2 -dump /apps/gnome-screensaver/ please?
[13:21] <mvo> pitti: does it work without compiz?
[13:21] <Mirv> asac: hi. I attached a patch to bug #286421, could you see about it soon. it's the only visible menu i18n problem in default installation at the moment.
[13:22] <Mirv> asac: the deadline for translations is on Thursday, so before that it should get uploaded, imported to Rosetta (hopefully fast now) and translated by people
[13:22] <pitti> mvo: http://paste.ubuntu.com/60492/
[13:24] <pitti> mvo: works in guest session with metacity
[13:26] <asac> Mirv: hmm. i will see what i can do
[13:26] <asac> have to do a few things. then will look
[13:29] <Mirv> asac: ok.
[13:29] <pitti> does anyone else have two "Screen saver" entries in system -> prefs? I just noticed that xscreensaver also has an entry there
[13:30] <Mirv> (the patch fixes the problem for me, I build packages at PPA)
[13:30] <StevenK> pitti: There's a bug about it
[13:30] <persia> pitti, I have two.
[13:32] <StevenK> Which was dealt with by slangasek
[13:34] <pitti> StevenK: seed change?
[13:34] <StevenK> pitti: 5.07-0ubuntu2 upload of xscreensaver.
[13:35] <pitti> hm, which I have
[13:35] <Riddell> evand, cjwatson: looks like ubiquity still doesn't work on the post-wubi install stage, it just shows a blank block
[13:35] <pitti> StevenK: ah, that won't work for updates
[13:35]  * pitti purges xscreensaver
[13:36] <cjwatson> Riddell: sounds like bug 285626, which we have been unable to reproduce directly?
[13:36] <cjwatson> Riddell: do you have a kwin crash in /var/log/installer/dm?
[13:36] <cjwatson> or indeed /var/crash
[13:36] <StevenK> pitti: Is there something to be done for updates?
[13:36] <Riddell> cjwatson: mm, yes
[13:37] <pitti> StevenK: I don't think we can; conflicting to it would be wrong
[13:37] <wgrant> pitti: I advise caution when responding to that guy on launchpad-users. He's the one who writes bug reports with 2000 word paragraphs while drunk, and insists that people keep breaking into his computer before he finishes the installation.
[13:38] <tjaalton> pitti: albert damen found out why evdev stole the joysticks on 64bit systems: https://bugs.freedesktop.org/show_bug.cgi?id=18150
[13:38] <wgrant> pitti: He's also grand master of filing bugs which mention at least 12 different things that might be bugs, but are too vague and separate for it to be clear.
[13:38] <pitti> wgrant: I had my reply halfway typed before I realized that it was utter <censored>, so then I just finished it quickly
[13:38] <pitti> wgrant: thanks for the warning
[13:38] <pitti> tjaalton: ooh
[13:39] <tjaalton> pitti: so applying it to the driver should fix joysticks (but not x-x-i-j though, but it's not that important IMHO)
[13:40] <tjaalton> I didn't realize it was an amd64-only problem..
[13:40] <pitti> tjaalton: hah! nice catch
[13:41] <pitti> so it rotated 1 << something into oblivion before casting it to 64 bit
[13:41] <wgrant> pitti: He might also send some OpenDocument presentations to you soon, most of which reference screenshots in /tmp, and apparently prove the problems which he has so far failed to describe.
[13:41] <persia> pitti, Nice find.  THanks.
[13:42] <tjaalton> pitti: ok to milestone this?
[13:42] <wgrant> And he keeps accusing eBay people of tampering with his RAM.
[13:42] <pitti> tjaalton: please do; feel free to upload, so that it's ready in the queue right after RC
[13:42] <tjaalton> pitti: yep
[13:52] <stefanlsd> wgrant: do you still have the bzr mplayer hardy source?
[13:54] <persia> stefanlsd, Isn't it still in bzr history on LP?
[13:55] <cjwatson> seb128: can you remind me how I run the retracer on a .crash file by hand?
[13:55] <cjwatson> the maze of twisty scripts on ronne is confusing me
[13:55] <stefanlsd> persia: somehow the hardy branch got messed up and couldnt be synced, and consequently was deleted.  so wanted someone with it to repush it
[13:56] <seb128> cjwatson: there is no easy way I think, usually that's 'log into the retracer, copy the cookie, use apport-retrace there'
[13:56] <persia> stefanlsd, Ah.  I see.  Never mind.
[13:56] <cjwatson> I've already downloaded the .crash file and copied it onto ronne; do I have to have it talk to LP?
[13:57] <cjwatson> alternatively I suppose I could arrange for the retracer to attack the bug
[13:57] <seb128> cjwatson: do you try to get a stacktrace or do you try to get it retraced the standard way?
[13:57] <persia> cjwatson, If you have a local .crash file, just call apport-retrace foo.crash with the right dbgsym packages installed.
[13:57] <seb128> cjwatson: ie do you debug why a retracing is not working or do you just want a stacktrace?
[13:57] <cjwatson> well, the latter is fine but the former is what I actually want :)
[13:58] <cjwatson> persia: I don't really feel like installing all of KDE in order to get a stacktrace
[13:58] <cjwatson> it's from somebody else's system, not mine
[13:58] <persia> cjwatson, "local" to ronne, I was guessing.
[13:58] <seb128> cjwatson: log into the corresponding retracer and use apport-retrace there
[13:59] <cjwatson> the tools seem to be out of date - they run dchroot -c gutsy ... /hardy.tar.gz
[13:59] <seb128> cjwatson: ie, apport-chroot login chroots/intrepid.tar.gz
[13:59] <seb128> apt-get install wget
[13:59] <seb128> wget your .crash
[13:59] <seb128> apport-retrace .crash
[13:59] <cjwatson> apport-chroot isn't installed in the base
[13:59] <seb128> just screen -r
[13:59] <seb128> and attach whatever retracer you need
[13:59] <cjwatson> nor in the intrepid chroot
[14:00] <seb128> you can ctrl-C a running instance
[14:00] <cjwatson> err, screen -r what?
[14:00] <seb128> screen -r on ronne
[14:00] <seb128> it'll list the retracers availables
[14:00] <cjwatson> There is no screen to be resumed.
[14:01] <seb128> ssh<EMAIL_ADDRESS>[14:01] <NCommander> Its offical
[14:01] <cjwatson> oh, ubuntu-archive
[14:01] <NCommander> My flight is booked for UDS Jaunty
[14:03]  * ogra curses the new panel sliders ... why did they decide that using cursor keys for brightness and volume shouldnt work anymore
[14:09] <amitk> pitti: we have a problem where ath5k works on some machines (eeepc) and madwifi on others (samsung q1) with same pci id. Can jockey handle a case of platform specific quirks on what module to blacklist based on platform being loaded on?
[14:11] <tseliot> amitk: is there a way to tell one arch from the other?
[14:11] <tseliot> (for jockey)
[14:12] <tseliot> amitk: e.g. telling lpia from 386
[14:12] <persia> tseliot, Except that it's not arch-specific.  The same problem happens on different i386 installs with different devices with the same pci id.
[14:13] <tseliot> persia: ok, is there a way to tell one device from the other then? (e.g. with lspci)
[14:14] <persia> tseliot, Well, I suppose one could look for textual clues in the strings, but with an identical pci id, I wouldn't be surprised if those matched mostly.
[14:14]  * persia doesn't have an affected device, but has seen lots of discussion
[14:20] <amitk> tseliot: dmidecode info perhaps
[14:22] <tseliot> persia, amitk: ok, maybe dmidecode could do it (it has to be run as root though). Any links to bug reports related to this problem?
[14:23] <persia> ogra, Did you file a bug about this already?
[14:23] <ogra> persia, ?
[14:23]  * ogra reads backlog
[14:23] <persia> Q1 wireless
[14:23] <ogra> persia, yes
[14:24] <tseliot> ogra: link?
[14:24] <ogra> persia, bug 284354
[14:24] <heno> *** RC candidate images are up - http://iso.qa.ubuntu.com - please help test. coordination in #ubuntu-testing ***
[14:25] <amitk> tseliot: bug #182489 for the eee pc
[14:25] <ogra> hmm
[14:25]  * tseliot has a look at the bug reports
[14:26]  * ogra would know which driver is used now ...
[14:26]  * ogra blacklists ath_pci
[14:27]  * amitk ships ogra with every ubuntu-mobile download
[14:27] <ogra> err ...
[14:27] <ogra> s/would know/would like to know/
[14:28] <ogra> :)
[14:28] <ogra> ... rebooting
[14:32] <ogra> amitk, ok, usual prob, with ath_pci blacklisted NM doesnt see any network, iwlist doesnt see any network ... creating one manually pointing to my essid just ends in NM not being able to connect
[14:33] <ogra> lsmod shows: ath5k, mac80211m led_class and cfg80211 being loaded atm
[14:34] <ogra> *mac80211
[14:34] <ogra> i have a wlan0 interface though
[14:34] <ogra> switching that now and will then install lbm
[14:35] <amitk> ogra: ack. let me know if lbm improves things.
[14:35] <kirkland> pitti: you around?
[14:37] <ogra> amitk, what would be the sideeffect of lbm being in the image in case that works ? any negatives you could imagine ?
[14:38] <amitk> ogra: it isn't 'supported'
[14:38] <ogra> amitk, well, -mobile and -mid are built from universe :)
[14:40] <amitk> ogra: also, sometimes it can contain updates for other modules that might not be desired for a particular device
[14:40] <tseliot> ogra: do lshal and lshw show anything about the network device(s)?
[14:40] <ogra> hmm
[14:40] <ogra> tseliot, the ids that are in the bug
[14:42] <zul> pitti: I uploaded bacula which drops mt-st to a suggests since Im pretty sure no one has a tape drive on the server team however I should be getting one eventually
[14:42] <ogra> amitk, hmm, apt doesnt seem to know linux backport modules
[14:42] <amitk> interesting... atleast it is found on the q1
[14:44] <cjwatson> Riddell: I don't suppose you could get me the kwin crash file?
[14:44] <cjwatson> Riddell: the one in the bug is with a slightly older version and I don't seem to be able to retrace it
[14:44] <ogra> amitk, not for me
[14:45] <amitk>  ogra: apt-cache search linux-backports-modules
[14:45] <amitk> WFM
[14:45] <Riddell> cjwatson: ok, give me a minute or four
[14:45] <cjwatson> ta
[14:45] <Riddell> cjwatson: but do you think the kwin crash is the cause?  kwin recovers and the window manager crashing shouldn't affect the applications
[14:46] <ogra> amitk, ah, udate helped :)
[14:46] <ogra> *update
[14:46] <pitti> kirkland: back from lunch, hey!
[14:46] <kirkland> pitti: heya, so i was posting about the ecryptfs/gdm issue
[14:47] <kirkland> pitti: as far as the installer goes, ecryptfs-setup-private is only in the server installer (as far as i understand)
[14:48] <pitti> kirkland: and in the alternate one
[14:48] <kirkland> pitti: right, i mean "not the graphical ones"
[14:48] <kirkland> pitti: and i couldn't find a particular package to "conflict" with...
[14:48] <pitti> kirkland: right, ubiquity only offers autologin, not ecryptfs setup
[14:49] <pitti> kirkland: no, it shouldn't conflict package-wise, but option-wise
[14:49] <pitti> kirkland: I thought d-i would offer autologin
[14:49] <ogra> ok, lbm installed, blacklisting ath_pci again
[14:49] <kirkland> pitti: hmm, not that i've ever seen
[14:51] <cjwatson> Riddell: I'm not sure, it's just the obvious difference between non-working and working ...
[14:51] <pitti> kirkland: hm, so this issue seems to be pretty moot then
[14:52] <cjwatson> d-i doesn't offer autologin right now
[14:52] <kirkland> pitti: i agree... i was "passing the buck" to you :-)
[14:52] <ogra> amitk, success !
[14:52] <kirkland> pitti: i can add a one-liner to the command line dialog
[14:52] <kirkland> pitti: that says that it won't work with auto-logins
[14:52] <pitti> kirkland: well, it's still an issue when you manually set up ecryptfs with an autologin system
[14:52] <kirkland> pitti: but that seems pretty friggin obvious to me
[14:52] <amitk> ogra: \o/
[14:53] <pitti> kirkland: but I really don't think we can solve this principal difference
[14:53] <kirkland> pitti: i'm hoping to have a python-gtk gui for Jaunty
[14:53] <pitti> s/difference/conflict/
[14:53] <ogra> amitk, loaded are: ath5k, lbm_cw_mac80211, lbm_cw_cfg80211 and led_class
[14:53] <kirkland> pitti: there's some community contributed code to that effect
[14:53] <pitti> kirkland: actually
[14:53] <pitti> kirkland: is there anything in ~/Private if it's not mounted?
[14:54] <kirkland> pitti: a symlink
[14:54] <pitti> kirkland: it would be nice to have  README.txt there which says "If you can see this, run this command" kind of explanation
[14:54] <pitti> kirkland: and that file could also point out things like automount
[14:54] <amitk> ogra: sounds like lbm should be installed by default in the -mobile image
[14:54] <kirkland> pitti: actually, that's pretty much what's there
[14:54] <kirkland> pitti: ln -s /sbin/mount.ecryptfs_private "$MOUNTPOINT"/"THIS DIRECTORY HAS BEEN UNMOUNTED TO PROTECT YOUR DATA --  Run mount.ecryptfs_private to mount again"
[14:54] <Keybuk> kwwii: when I select the Darkroom (he he) theme, the panel doesn't change background colour?
[14:54] <ogra> amitk, i'm a bit scared about the modules you mentioned that might come in additionally
[14:54] <pitti> kirkland: hm, so how about adding the autologin explanation there?
[14:55] <kirkland> pitti: i think you're right...  replace that symlink with a small readme of FAQ
[14:56] <amitk> ogra: it is usually for new hw enablement. We used it to provide alsa backports for Hardy. No plans to do that for intrepid yet.
[14:56] <pitti> kirkland: oh, the symlink idea is nice as well, though
[14:56] <kirkland> pitti: right now, it's just an "informatively named" symlink to the binary that will try to mount your data again
[14:56] <ogra> amitk, *yet* :)
[14:56] <kirkland> pitti: it doesn't work in the autologin case, though
[14:56] <pitti> kirkland: hm, that provides clickable mounting which is nice indeed
[14:56] <ogra> thats the scary part :)
[14:56] <kirkland> pitti: that's the idea ;-)
[14:57] <amitk> ogra: i know. lbm will never have guarantees. But lets see if this motivates rtg to backport all this into the kernel by default
[14:57] <kirkland> pitti: because your login passphrase never made it into your keyring, the clicky after autologin doesn't work
[14:57] <pitti> kirkland: ah, it uses gnome-keyring?
[14:57] <kirkland> pitti: no
[14:57] <ogra> amitk, is there a kernel update planned before release ?
[14:57] <kirkland> pitti: the kernel keyring
[14:57] <pitti> oh, that keyring, sure
[14:57]  * ogra wouldnt have thought so
[14:58] <Riddell> cjwatson: http://muse.19inch.net/~jr/tmp/_usr_bin_kwin.999.crash
[14:58] <amitk> ogra: yes
[14:58] <cjwatson> thanks
[14:58] <kirkland> pitti: the pam_ecryptfs module takes your login passphrase, decrypts ~/.ecryptfs/wrapped-passphrase, and adds the decrypted key to your kernel keyring, which is used to mount
[14:58]  * ogra prepares boxes of german beer to send to rtg to bribe
[14:59] <ogra> or even to BenC1 :)
[14:59] <BenC1> ??
[14:59] <ogra>  ogra prepares boxes of german beer to send to rtg to bribe
[14:59] <ogra> :)
[14:59] <kirkland> BenC1: something about sending free beer your way ... nothing important ;-)
[15:00] <BenC1> ogra: I'm not sure what you're asking for, but for boxes of german beer, I'll do just about anything
[15:00] <pitti> kirkland: so the GTKish solution would then detect that and ask you for your password?
[15:00] <ogra> BenC1, apparetnly the lbm ath5k solves all our probs in mobile and amitk told me there is another kernel upload planned before release :)
[15:00] <BenC1> There is?
[15:00] <kirkland> pitti: well, my 2 cents are "Hell no!  There's no good reason why you'd want to have encrypted data, that automatically gets decrypted if you login"
[15:00] <ogra> so i was hoping german beer could get it in :)
[15:01] <kirkland> pitti: sorry, "if you auto login without a password"
[15:01]  * BenC1 is surprised to hear another kernel upload is planned for RC
[15:01] <pitti> kirkland: hm, maybe you misunderstood me
[15:01] <ogra> BenC1, RC != release
[15:01] <ogra> i just want it fixed in final
[15:01] <kirkland> pitti: oh, my bad...
[15:01] <ogra> and adding lbm to the seed smells a bit risky
[15:01] <BenC1> ogra: I would suspect that it would be post release then :)
[15:02] <ogra> though that would be my fallback for mobile
[15:02] <ogra> oh
[15:02] <ogra> well, that leaves me with lbm then
[15:02] <kirkland> pitti: basically, someone filed a bug and submitted some decent, beta code that would act as a python-gtk front end for ecryptfs-setup-private
[15:02] <kwwii> Keybuk: nope, setting a panel bg just causes a bug in the about panel and stuff so although we include a bg I did not set it in the theme itself
[15:03] <pitti> kirkland: if clicking on that magic symlink would pop up a dialog which explains what's going on and asks me for my password, and then mounts ~/Private, why whould that be bad?
[15:03] <kirkland> pitti: ooooooh.....
[15:03] <pitti> kirkland: leaving aside security aspects of how to design the dialog, and how to implement it in general
[15:03] <kirkland> pitti: sure, that sounds find
[15:03] <kirkland> fine, even
[15:03] <pitti> kirkland: just how it would loook to the user
[15:04] <kirkland> pitti: the user could do it, by running ecryptfs-insert-wrapped-passphrase-into-keyring, and then mount.ecryptfs_private
[15:05] <kirkland> pitti: but those are both CLI's, no GUI (yet)
[15:06] <pitti> kirkland: wrap it into gnome-terminal -e :-P
[15:06] <pitti> TEH ULTIMATE GUI
[15:06] <kirkland> pitti: cool....  how well does that work for KDE?
[15:06] <kirkland> :-P
[15:06] <pitti> kirkland: x-terminal-emulator
[15:09] <ScottK> kirkland: Thanks for thinking of us.
[15:10] <Keybuk> kwwii: that's a shame
[15:10] <Keybuk> it makes setting the theme kinda ugly
[15:10] <kirkland> ScottK: :-)
[15:10] <lool> pgraner: Around?
[15:10] <lool> pgraner: When is the first intrepid-updates kernel?
[15:11] <lool> pgraner: We're basically stuck for the ath5k/madwifi situation with some hardware, and lbm isn't an option
[15:11] <pgraner> lool: talk to amitk he is working on that issue
[15:13] <amitk> pgraner: but you know about updates schedule :)
[15:13] <lool> pgraner: nice try
[15:13] <lool> pgraner: 16:07 < amitk> lool: dunno. ask pete
[15:13] <lool> stack overflow people
[15:13] <kirkland> pitti: is there something simple that i can use to prompt for a password?
[15:13] <kirkland> pitti: graphically?
[15:14] <pitti> kirkland: you can probably abuse gksu, or at least libgksu
[15:14] <pgraner> amitk: I thought you were going to get that fixed up for release, no? I haven't looked at updates yet...
[15:14] <kirkland> pitti: i thought about gksu, but i'd need it to feed me the password
[15:14] <tseliot> kirkland: what about zenity?
[15:14] <kirkland> pitti: oh, wait
[15:14] <kirkland> --print-pass,
[15:14] <pitti> kirkland: gksu --print-pass
[15:15] <kirkland> tseliot: is zenity better across gnome/kde/xfce?
[15:15] <amitk> pgraner: it works with lbm. I am currently diffing the in-kernel ath5k code with lbm ath5k to see how big
[15:15] <lool> pgraner: I understand we don't have any new kernel upload anymore
[15:15] <tseliot> kirkland: no, I guess not. There's a kde equivalent too
[15:15] <amitk> lool: we DO have a kernel upload, maybe not before RC
[15:15] <lool> amitk: Ok; good news then
[15:16] <pitti> kirkland: gksu -p -m "Foobarize your system" works quite well indeed
[15:16] <kirkland> tseliot: pitti: okay, i'm straying much further away from the server, and from intrepid responsibilities, i fear ;-)
[15:16] <ogra> pgraner, the question is simply will we have another kernel upload before final
[15:16] <pitti> kirkland: heh, yes; let's keep all this for jaunty
[15:16] <ogra> pgraner, where the fixed ath5k could be included
[15:16] <kirkland> pitti: i'll revisit then
[15:16] <pitti> kirkland: sounds like these desktop guys should handle that
[15:16] <pitti> oh, wait...
[15:16] <kirkland> pitti: :-)
[15:17] <pgraner> ogra, lool, amitk: I'll know more later today
[15:17] <lool> amitk: The solution of pushing an ath5k update in the RC is good for me; otherwise, I recommend disabling ath5k for everybody until it works for everybody; I'm not sure the claims that it worked for some eeepc users in some network configs are enough to have preference for athh5k and break wifi for others
[15:17] <mvo> Riddell: what can/should we do about virtualbox-ose and kde upgrades? my suggestion would be to have "virtualbox-ose-legacy" that can read the old snapshots and make the default of the debconf question to not fail
[15:17] <lool> s/in the RC/after RC
[15:17] <lool> Otherwise, I can also imaging including a fixed ath5k in the first intrepid-updates kernel if taht's early enough
[15:17] <lool> *imagine damn
[15:17] <amitk> lool: NAK. madwifi _doesn't_ work for some people, but ath5k works. So disabling it is not an option.
[15:18] <ogra> lool, hard to upgrade on mobile devices that *only* have wlan though
[15:18] <lool> amitk: I'm only suggesting to disable it for some PCI ids
[15:18] <ogra> amitk, mdwifi only doesnt work if *both* modues are loaded
[15:18] <lool> Did you get reports that madwifi wouldn't work on these PCI ids?
[15:18] <lool> I know madwifi regressed in terms of hardware support, but I have yet to read that it affected the Q1U's PCI ids or, the eepc's
[15:18] <amitk> lool: bug 182489
[15:19] <lool> *eeepc
[15:19] <ogra> the real prob is that one doesnt replace the other apparently and you need to manually have to maintain a blacklist file
[15:19] <ogra> but if we have the fix and another kernel upload will happen it should definately go in
[15:20] <lool> amitk: not the same pci ids
[15:21] <lool> amitk: Anyway, let's first exhaust the option of updating ath5k post RC which might make everybody happy and is probably one of the options requiring the least amount of work
[15:21] <pitti> tjaalton: oh, is bug 271138 really that easy?
[15:22] <amitk> lool: ack, looking at the ath5k diff now
[15:22] <lool> Thanks :-)
[15:22] <tjaalton> pitti: for some it is
[15:23] <tjaalton> pitti: but the other bug is just weird
[15:24] <pitti> tjaalton: libhal_ctx_init() failure is weird anyway and a bug by itself, but I hope it's just a followup effect of having all these bogus input.keymap properties
[15:27] <tjaalton> pitti: right, it's a likely candidate
[15:30] <pitti> liw: the RC images still have systme cleaner in apps -> system tools; are you aware of that? would be really good to fix that for the final
[15:34] <rtg> why is the spell checker in Thunderbird lobotomized? It redlines all kinds of stuff that is obviously correct. Is it because the language selected is en_ZA?
[15:34] <liw> pitti, I know, I'm working on an update
[15:35] <kwwii> TheMuso: which package is the ubuntu-studio gtk theme in?
[15:36] <kwwii> erm, skip that I found it
[15:44] <Riddell> mvo: will that work?  it sounds like hassle
[15:44] <Riddell> kirkland: kde has kdialog
[15:44] <kirkland> Riddell: cool, thanks :-)
[15:45] <Riddell> pitti: jockey-kde doesn't seem to do very much for this broadcom wifi
[15:46] <pitti> Riddell: it doesn't show any drivers, or enabling them doesn't work?
[15:46] <Riddell> pitti: it shows a driver but clicking Activate just results in it being greyed out and nothing else apparantly happening
[15:46] <tedg1> Okay, I'm taking the bait.  rtg: Why are you en_ZA?
[15:47] <pitti> hey tedg1
[15:47] <pitti> Riddell: hm, can you please start it from a terminal? does it throw an exception?
[15:47] <tedg1> Good morning pitti
[15:47] <rtg> tedg1: dunno, but I switched it to en_GB as soon as I noticed. This was a clean install, and I chose Boise as my timezone.
[15:48] <Riddell> pitti: no nothing on stdout
[15:48] <Riddell> (or stderr)
[15:48] <tedg1> rtg: Exactly, because en_GB make so much more sense for Boise.  :)
[15:49] <pitti> Riddell: ok; does it show b43 or wl?
[15:49] <pitti> Riddell: and do you get a progress bar at all?
[15:49] <rtg> tedg1: well, its not like there are a wealth of choices.
[15:50] <rtg> though, there is an option to download more dictionaries.
[15:50] <Riddell> pitti: it says "Broadcom STA wireless driver"
[15:50] <Riddell> pitti: no progress bar
[15:52] <davmor2> Riddell: there is no progress bar it should just work after a reboot.  Did for me anyway.
[15:53] <mvo> Riddell: it is hassle :/
[15:53] <rtg> slangasek: disabling FTRACE is gonna cause an ABI bump. Are you OK with that?
[15:53] <davmor2> Riddell: is this on kubuntu?
[15:54] <liw> interesting. I have a possibly broken usb memory stick that when inserted kills compiz, gnome panel, and possibly more
[15:55] <liw> or else my desktop machine is acting weirdly for other reasons
[15:56] <Riddell> davmor2: yes
[15:56] <Riddell> mvo: I'd be tempted just to release note it if it's trouble
[15:56] <davmor2> give me a few minutes I'll see if I can reproduce it on my laptop
[15:57] <tseliot> Riddell: does jockey-gtk work for you?
[15:58] <Riddell> tseliot: that was my next idea
[15:59] <tseliot> Riddell: if it does, then I'll see if I can find the problem in the kde ui and possibly fix it
[16:02] <liw> perfectly repeatable: insert key, system goes haywire. oh well, I'll debug that later
[16:08] <Riddell> tseliot: jockey-gtk works fine
[16:09] <tseliot> Riddell: ok, I'll have a look at the code and see what I can do
[16:09] <Riddell> tseliot: good luck
[16:12] <tseliot> Riddell: does Jockey work for you with other drivers (if you use other proprietary drivers)?
[16:12] <davmor2> Riddell: try it once close jockey then open jockey and try it again
[16:13] <Riddell> tseliot: I don't use other proprietry drivers
[16:13] <Riddell> davmor2: doesn't help
[16:14] <tseliot> ok
[16:14] <davmor2> worked on live like that for me.
[16:14] <davmor2> tseliot: I'm installing it I got nvidia gfx and broadcom wifi
[16:15] <tseliot> davmor2: and sometimes you don't get any progress dialog, right?
[16:16] <davmor2> tseliot: not with the wifi I think is installed to quickly and I don't think it downloads the driver I always do with nvidia
[16:17] <tseliot> davmor2: aah, maybe the driver is already available in the linux-restricted-modules
[16:18] <davmor2> tseliot: it's the broadcom sta (dell/canonical) driver iirc
[16:18] <pitti> ogra, cjwatson: as for bug 276317, should there even be something like "edubuntu netboot"? I thuoght edubuntu was just an addon CD nowadays?
[16:19] <tseliot> davmor2: ok, this should help me track down the problem.
[16:19] <cjwatson> I've commented on the bug
[16:19] <cjwatson> there's no intrinsic reason not to test it using netboot but it's not all that valuable
[16:19] <pitti> tseliot: ah, I just discussed it with Riddell in /query; seems we should be able to reproduce this wiht a fake modalias, since it seems to be a problem of -kde, not with particular hardware
[16:19] <ogra> pitti, i havent touched edubuntu since hardy, but edubuntu-desktop clearly depends on ubuntu-desktop so it should be installed
[16:19] <cjwatson> edubuntu-desktop does not in fact Depends: ubuntu-desktop
[16:19] <cjwatson> although you should certainly install it
[16:20] <ogra> Depends: ubuntu-desktop, atomix, edubuntu-artwork, edubuntu-artwork-usplash, gcompris, gcompris-data, gnome-icon-theme-gartoon, gpaint, kalgebra, kalzium, kanagram, kbruch, khangman, khelpcenter4, kig, kmplot, kpercentage, kstars, ktouch, ktuberling, kturtle, kwordquiz, libpcre3, marble, parley, step, tuxmath, tuxpaint, tuxpaint-data, tuxpaint-stamps-default, tuxtype, xaos
[16:20] <cjwatson> oh, sorry, yes
[16:20] <ogra> thats what i get from apt-cache show edubuntu-desktop
[16:20] <cjwatson> I assumed it was in alphabetical order and only looked at the end ;-)
[16:20] <ogra> ah :)
[16:20] <tseliot> pitti: yes, I was thinking of adding some new test to the test suite
[16:20] <cjwatson> I suppose it's possible that Recommends aren't getting pulled in
[16:20] <ogra> mvo, why was the "compiz doesnt blank screen" bug closed ? i still see it on all devices
[16:20] <pitti> tseliot: once we figure out where the problem is, that would be great, yes
[16:21] <davmor2> pitti: tseliot: I just tried on live cd I got it to go green but if memory serves you need a full reboot for it to activate completely
[16:21] <pitti> davmor2: for wl? yes
[16:21] <pitti> davmor2: alternatively, some rmmoding of all b43 and ssb stuff, and modprobing wl
[16:21] <davmor2> pitti: well broadcom sta :)
[16:21] <pitti> davmor2: yes, that's the "wl" kernel module
[16:22] <ogra> mvo, fully upgraded
[16:22] <cjwatson> davmor2: where's the edubuntu netboot test procedure?
[16:22] <ogra> but it doesnt show up on https://bugs.launchpad.net/ubuntu/intrepid/+bugs so i assume its been closed ?
[16:23] <davmor2> works fine on Ubuntu just waiting for the kubuntu install to finish so I can try it there shouldn't be long
[16:23] <davmor2> cjwatson: http://iso.qa.ubuntu.com/qatracker/result/2054/170 is the tracker details
[16:23] <cjwatson> heno: I think we should take edubuntu netboot off the tracker. Do you agree?
[16:24] <ogra> ++
[16:24] <cjwatson> davmor2: doesn't exactly go into much detail on "select a distro flavour to install" - that isn't a canned selection in the installer
[16:24] <davmor2> cjwatson: https://wiki.ubuntu.com/Testing/Cases/NetbootInstall is the test case
[16:24] <heno> cjwatson: agree
[16:24] <ogra> tough it would be intresting to know why the dependency isnt properly fulfilled
[16:25] <heno> ogra: should d-i install recommends?
[16:25] <ogra> heno, afaik
[16:25] <cjwatson> davmor2: how did you select it?
[16:25] <heno> it's only the recommended packages of ubuntu-desktop dropping out
[16:25] <cjwatson> yes, d-i should install recommends
[16:26] <cjwatson> the edubuntu-desktop-addon task doesn't include the edubuntu-desktop metapackage
[16:26] <cjwatson> that might be relevant
[16:26] <davmor2> cjwatson: standard install until it gets to selection and it is in the list along with edubuntu-kde desktop
[16:27] <cjwatson> davmor2: you need to select Ubuntu desktop too
[16:27] <calc> when is iso.qa going to get openid?
[16:28] <cjwatson> davmor2: this is sort of a bug and it ought to work without that, but it isn't worth spending time testing it
[16:28] <davmor2> cjwatson: but it pulls in the majority of gnome correctly it's only certain packages that are missing
[16:28] <cjwatson> davmor2: yes, I know.
[16:28] <cjwatson> davmor2: really isn't worth our time working on it at this point
[16:28] <davmor2> :)
[16:29] <davmor2> I just test it ;)
[16:29] <cjwatson> heno and I agree that you should stop :)
[16:29]  * heno nods
[16:29] <cjwatson> it's an interesting bug and there's clearly something wrong in the internals, but the actual use case isn't one we care deeply about
[16:30] <cjwatson> ah, the bug is that tasksel invokes apt-get with --no-install-recommends
[16:30] <cjwatson> it almost always doesn't matter because the tasks are generated with recommends included
[16:31] <davmor2> np's
[16:31] <cjwatson> but it happens to matter in this case
[16:32] <Caesar> pitti: I don't think #214041 has been fixed in hardy-updates, as the worklog on the bug suggests
[16:32] <Caesar> Could you take a look please?
[16:33] <cjwatson> davmor2: ok, committed a fix for post-intrepid just for the hell of it
[16:33] <davmor2> :)
[16:33] <cjwatson> thanks
[16:33] <davmor2> tseliot: right kubuntu installed now
[16:34] <tseliot> good
[16:35] <ogra> mvo, bug 278112 is clearly not fixed for me anywhere
[16:35] <ogra> mvo, and amitk just reorted the same
[16:35] <ogra> *reported
[16:36] <cjwatson> Riddell: http://muse.19inch.net/~jr/tmp/_usr_bin_kwin.999.crash is 403
[16:36] <cjwatson> Riddell: could I have it back? :)
[16:36] <jdong> mvo, ogra: Confirm here too. The screen starts nodding off to blankness and comes right back. kinda like me during class, but that's a different concern :)
[16:37] <ogra> jdong, lol
[16:37] <ogra> jdong, please comment that on the bug so mvo is aware
[16:37] <ogra> (not about your shool habits but about the non fixage :) )
[16:41] <davmor2> tseliot: I think it might be the trigger for policykit
[16:41] <tseliot> davmor2: why do you think so?
[16:41] <davmor2> i'll paste the output it's been called but I get not window
[16:42] <tseliot> ok
[16:42] <hwilde> is there any way to really debug why livecd dumps to busybox initramfs ?
[16:42] <\sh> pitti: do you have a moment?
[16:44] <\sh> zul: ping you were the last one who touched mysql-server in hardy...for updates
[16:44] <\sh> zul: I think I found a serious regression
[16:44] <zul> \sh: ??/
[16:45] <davmor2> tseliot: http://paste.ubuntu.com/60569/
[16:45] <\sh> zul: check this out :)
[16:45] <\sh> zul: http://paste.ubuntu.com/60570/
[16:46] <\sh> zul: paste number one of mysql-server 5.0.51a-3ubuntu5 (before applying 5.0.51a-3ubuntu5.1)
[16:46] <davmor2> tseliot: I'll double check it with nvidia
[16:46] <tseliot> davmor2: ok, thanks
[16:47] <pitti> mvooooooooooo
[16:47] <pitti> mvo: http://people.ubuntu.com/~pitti/tmp/upgrade-note-description.png :(
[16:47] <\sh> zul: http://paste.ubuntu.com/60571/
[16:47] <pitti> \sh: just ask, please, busy with dozens of things ATM
[16:47] <cjwatson> meeeeep
[16:47] <cjwatson> I wonder if that was my fault
[16:47] <davmor2> tseliot: same thing
[16:47] <\sh> zul: paste number two with mysql-server 5.0.51a-3ubuntu5.1 applied...same database structure, different data inside, but you get the point
[16:47] <Keybuk> cjwatson: it's all your fault
[16:48] <cjwatson> Keybuk: thpppppppppt
[16:48] <\sh> pitti: I'll  work with zul on it, because he touched it last , thx anyways :)
[16:48] <Keybuk> oh, wait, you're not a manager now :p
[16:48] <hwilde> plz I am stuck in busybox initramfs :/
[16:48] <pitti> Caesar: it was supposed to, but of course you could experience a different bug
[16:48] <pitti> \sh: okay, danke
[16:49] <\sh> zul: the result is totally different...first paste is correct, second not, but second is in -updates ,-)
[16:49] <tseliot> davmor2: can you install policykit-gnome and try again?
[16:49] <davmor2> np's
[16:50] <tseliot> davmor2: ?
[16:50] <davmor2> no probs
[16:50] <tseliot> ah, the apostrophe confused me a bit
[16:50] <cjwatson> pitti: I'm sort of inclined to blame intltool ...
[16:51] <pitti> mvo: filed as bug 287046, for tracking
[16:53] <Caesar> pitti: I mean in terms of package versions
[16:53] <Caesar> Did the right version actually get in?
[16:53] <davmor2> tseliot: that worked but it looks ugly as hell :)
[16:54] <tseliot> pitti: ^^
[16:54] <pitti> Caesar: yes, but ages ago
[16:54] <Caesar> pitti: hmm
[16:54] <pitti> davmor2, Riddell: argh, it seems that the kde .desktop file doesn't actually start it as root
[16:55] <pitti> davmor2, Riddell: (no policykit in KDE); can you try to start it as root?
[16:55] <davmor2> pitti: policykit is installed I just installed policykit-gnome
[16:55] <pitti> I mean a PK auth agent
[16:56] <davmor2> pitti: I'll try it now
[16:57] <davmor2> looks like it might work pitti need to reboot first 2 ticks
[16:58] <Caesar> pitti: don't mind me, I can't read diffs properly
[16:58] <pitti> Caesar: ah, *phew* :)
[17:01] <Caesar> We've got another issue we'll try to get fixed upstream
[17:02] <davmor2> pitti: Riddell: kdesudo jockey-kde seems to work fine
[17:02] <Riddell> I was using sudo
[17:04] <davmor2> Riddell: I just installed the nvidia driver with no issues :(
[17:04] <tseliot> Riddell: does it work if you install policykit-gnome and launch jockey-kde without sudo?
[17:04] <Riddell> davmor2: that's a happy face sentence :)
[17:05] <Riddell> tseliot: dunno that computer is in the middle of an upgrade test just now
[17:05] <Riddell> will need to wait ten minutes
[17:05] <cjwatson> looks like single-line translated strings in intltool-merge are just screwed
[17:05] <davmor2> Riddell: it was meant to be a confused face but I hit the wrong button :)
[17:05] <tseliot> Riddell: ok, let me know
[17:05] <cjwatson> intltool-debian handles that file slightly better but not by a whole lot (it at least manages to translate Description but still screws up Name)
[17:06] <davmor2> tseliot: did for me :)
[17:07] <tseliot> davmor2: thanks to you we have found a bug. Maybe Riddell is affected by a different bug? We'll see
[17:07] <Riddell> what bug did davmor2 find?
[17:07] <cjwatson> this is all rather confusing because po-debconf gets it riight
[17:07] <cjwatson> right
[17:08] <davmor2> tseliot: Riddell found it I was just confirming it :)
[17:08] <ogra> pitti, was cups in hardy recently updated ? i have ltsp users complaining it broke jetdirect printing
[17:08] <mathiaz> james_w: I think it's a matter of policies
[17:09] <mathiaz> james_w: we have a bunch of other programs that listen on localhost by default
[17:09]  * RainCT wonders if anyone here happens to know how .desktop and similar files are translated
[17:10] <mvo> ogra: could you please attach the log from "gnome-screensaver --debug --no-daemon" ? and attach the version of xserver-xorg-core? and ensure that the xserver got restarted?
[17:10] <seb128> RainCT: usually they have a .in which has _Name= and _Comment=
[17:10] <james_w> mathiaz: sure, I understand and probably agree with the policy, just given the reporter I just wanted to make sure it was given some attention.
[17:10] <seb128> RainCT: intltool understand those correctly
[17:10] <mvo> jdong: could you please do the same please as the stuff that I just asked ogra about? (two lines above)?
[17:11] <mathiaz> james_w: right - I think I'll post a quick answer to state that we've heard their concerns
[17:11] <ogra> mvo, yes, i can, but as i i said before it behaves the same if i purge gss
[17:11] <mvo> ogra: hm, that sounds like its a different issue then
[17:11] <mathiaz> james_w: and given the current position in the release cycle, we won't look into the issue within the next two weeks
[17:11] <RainCT> seb128: Do you happen to have some example of how to get the strings from there into the POT and how to generate the final files (not involving Makefiles :))?
[17:11] <ogra> mvo, it works if i xset -dpms or disable gpm
[17:11] <mvo> ogra: and without compiz its all good?
[17:11] <ogra> or disable compiz, right
[17:12] <mvo> ogra: or the same with/without compiz?
[17:12] <mvo> hmmmm
[17:12] <seb128> RainCT: list the source in the potfiles and run intltool-update
[17:12] <ogra> mvo, it goes away if i uncheck the gconf option mentioned in the bug though
[17:12] <mvo> ogra: the unredirect fullscreen wndow?
[17:13] <mvo> ogra: what video card/driver?
[17:13] <pitti> ogra: see https://edge.launchpad.net/ubuntu/+source/cupsys; there was a security update
[17:13] <ogra> mvo, intel 945GM on my lappie ...
[17:14] <mvo> jdong: is that a intel card for you too?
[17:14] <ogra> mvo, same on the Q1
[17:14] <mvo> ogra: thanks, I have a intel system here (i965) I can try wit hthat
[17:14] <mvo> ogra: could you do a recursive gconf unset for g-p-m and see if that helps?
[17:14] <ogra> nope, not yet
[17:15] <ogra> pitti, hmm, nothing strikes me as jetdircet related
[17:15] <pitti> ogra: no, it isn't; they are all pretty low-profile
[17:15] <ogra> yeah
[17:15] <kirkland> is there something i can use in ecryptfs-setup-private to validate a user's login password?  something that they can run as themself
[17:15] <mvo> ogra: ok, thanks. I check it out after dinner
[17:16] <jdstrand> kirkland: unix_chkpwd may do the trick
[17:16] <kirkland> jdstrand: awesome, thanks
[17:17] <pitti> lool: so, for elisa -bad, we'd need to drop the recommends on -ugly and libvisual-plugins; any alternatives to that?
[17:17] <jdstrand> kirkland: you plan to call it from within ecryptfs-setup-private?
[17:18] <kirkland> jdstrand: yes.
[17:18] <kirkland> jdstrand: see bug #259631
[17:18] <jdstrand> kirkland: ok-- check gnome-screensaver for an example of how to use it
[17:18] <kirkland> jdstrand: users are entering their login password (twice, mind you) incorrectly
[17:19] <kirkland> jdstrand: and moaning about encrypted private not being mountable
[17:19] <jdstrand> heh
[17:25] <kirkland> jdstrand: grep -r unix_chkpwd on the gnome-screensaver source doesn't turn up any hits
[17:25] <kirkland> jdstrand: nor does pam_unix
[17:28] <jdstrand> kirkland: src/gs-auth-helper.c
[17:29]  * calc wishes he had a faster connection
[17:29] <calc> downloading isos takes a long time :\
[17:29] <jdstrand> kirkland: ext_run()
[17:30] <jdstrand> kirkland: the source has 'PASSWD_HELPER_PROGRAM' which ends up being unix_chkpwd for us
[17:30] <kirkland> jdstrand: hmm
[17:30] <jdstrand> kirkland: you'd likely want to do the same since you're an upstream
[17:30] <kirkland> jdstrand: can i do something like this in shell?
[17:30] <kirkland> jdstrand: sure
[17:30] <kirkland> jdstrand: but ecryptfs-setup-private is shell code
[17:31] <kirkland> jdstrand: running unix_chkpwd from the command line get's a slap on the wrist
[17:31] <jdstrand> kirkland: oh yeah (I keep forgetting which is shell and which is C)
[17:32] <jdstrand> kirkland: it has to be invoked correctly, and is careful not to put the password on the command line
[17:32] <jdstrand> (which ends up in proc)
[17:32] <kirkland> jdstrand: right
[17:33] <jdstrand> kirkland: I messed with that from shell a while ago, and ended up writing a small C program for it
[17:34] <cr3> is there some command line utility to manage /etc/gdm/gdm.conf
[17:34] <ogra> cody-somerville, does /cdrom/dists/intrepid/universe exist on xubuntu CDs ?
[17:34] <ogra> (or rather dists/intrepid/universe)
[17:35] <cody-somerville> ogra, for live or alternat?
[17:35] <ogra> cody-somerville, alternate, i'm trying to fix a ltsp build failure without breaking xubuntu :)
[17:35] <ogra> since i need universe in xubuntu but dont have it on ubuntu CDs
[17:45] <jdstrand> kirkland: one option for you is to write a small C wrapper for unix_chkpwd and accept input from stdin, then you could do 'echo pass | wrapper ...'. this is safe for us because 'echo' is a shell builtin for dash and bash
[17:45] <kirkland> jdstrand: k
[17:45] <kirkland> jdstrand: i'll have a look at that
[17:46] <jdstrand> kirkland: beyond that, I don't have anything otoh
[17:46] <kirkland> jdstrand: thanks, this helps
[17:49] <NCommander> ScottK & StevenK ping
[17:55] <superm1> pitti / slangasek, tjaalton mentioned that the nv chosen when it shouldn't be bug was going to be a post-rc fix.  is there anything that i'd be able to do in helping test the fix or verify it's not breaking that would allow it to go in at RC instead?
[17:56] <cjwatson> mvo: are the language-selector changes I just committed OK, do you think?
[18:07] <calc> can you do an inverted status search?
[18:07] <calc> eg -TRIAGED to get all but triaged bugs?
[18:08] <james_w> calc: advanced search has a checkbox for each status
[18:08] <pitti> superm1: it's not a matter of testing, it's a matter of respinning CDs
[18:08] <calc> oh ok so i just have to check each one except for what i want to leave out?
[18:08] <superm1> pitti, ah, that's too bad then.
[18:09] <calc> well inverting wouldn't really work well anyway because it would show closed bugs, heh
[18:10] <pitti> cjwatson: do you know why c-m insists on guile-1.6? I don't see why autogen would pull it in, it b-deps on guile-1.8 only
[18:10] <lool> pitti: As I was saying, we need to promote libvisual-plugins
[18:10] <lool> Will file a MIR for it and review it
[18:11] <lool> You already hinted we need to change it first
[18:11] <pitti> lool: right, if it drops jack, all is well
[18:11] <pitti> lool: is dropping the -ugly recommends ok?
[18:14] <mvo> cjwatson: ooh, you attacked #287046 already? wonderful!
[18:14] <kirkland> dendrobates: i have confirmed slangasek's grub fixes....  install to LVM works fine in today's server ISO
[18:14] <mvo> l
[18:14] <mvo> cjwatson: looks perfect, thanks a lot for looking into it!
[18:14] <ScottK-palm> NCommander: pong
[18:16] <cjwatson> pitti: autogen/ia64 only
[18:16] <cjwatson> pitti: (dependency, not build-dep)
[18:16] <pitti> cjwatson: ah, ok; so I'll just ignore it
[18:16] <cjwatson> mvo: should I upload this, or is there likely to be more language-selector stuff to come?
[18:17] <mvo> cjwatson: please upload it, I have nothing for language-selector pending right now
[18:19] <pitti> cjwatson: do you have any idea why po-debconf should recommend: libmail-sendmail-perl ?
[18:20]  * pitti just went through all the perl stuff in c-m and boiled it down to four anchors
[18:20] <cjwatson> $ dpkg -L po-debconf | xargs grep Mail::Sendmail
[18:20] <cjwatson> /usr/bin/podebconf-report-po:eval q{use Mail::Sendmail;};
[18:20] <cjwatson> podebconf-report-po pulls in a few bits
[18:20] <cjwatson> libmail-box-perl too
[18:21] <pitti> oh, podebconf-report-po; I didn't really see a link between debconf i18n and mailing, that's id
[18:21] <pitti> s/id/it
[18:21] <cjwatson> I couldn't really decide what to do with those myself
[18:23] <ogra> who can approve uploads for CD fixes ?
[18:23] <ogra> (whom do i have to talk to for an ltsp-client-builder fix that breaks alternate ?)
[18:23] <pitti> ogra: is it OMGbreakingeverything?
[18:24] <ogra> pitti, it is "breaks ltsp builds completely"
[18:24] <pitti> ogra: respinning is *very* expensive, so everything which isn't essential for installation -> post-RC
[18:24] <ogra> hmm
[18:24] <ogra> that wont get us any ltsp tests though
[18:24] <ogra> fix is trivial http://paste.ubuntu.com/60602/
[18:24] <pitti> hm, argh
[18:24] <ogra> but i suppose its fine after RC worst case
[18:24] <pitti> ogra: that affects kubuntu alternates, too?
[18:25] <ogra> can it be let through so that it gets in in case another respin reason shws up ?
[18:25] <ogra> all alternates apart from xubuntu
[18:25] <ogra> the original fix went in to support xubuntu-artwork-usplash on non CD builds
[18:26] <pitti> I don't see it in the queue
[18:26] <ogra> its not uploaded yet
[18:26] <ogra> i wanted to ask first :)
[18:26] <pitti> ogra: it should be uploaded either way
[18:26] <ogra> oki
[18:26]  * ogra does
[18:27] <ogra> did anyone else note weird focus behavior with alt-tab ?
[18:28] <ogra> i often end up having the focus on a different window than the one in front after alt tabbing
[18:28] <pitti> ogra: ok, let's do it then
[18:28]  * pitti disables alternates in tracker
[18:30] <mvo> pitti: is the retracer working? it looks like bug 286915 has no symbolic trace yet
[18:30] <mvo> (6h old)
[18:31] <pitti> ogra: ubuntustudio is not affected either, I suppose?
[18:31] <ogra> pitti, i dont think they have ltsp
[18:31] <ogra> pitti, and mythbuntu uses universe
[18:31] <pitti> ogra: ok, just ubuntu and kubuntu then
[18:32] <ogra> right
[18:33] <pitti> ogra: hm, how did that change since beta?
[18:33] <ogra> pitti, it was fixed after beta
[18:35] <pitti> ogra: apparently not then?
[18:35] <ogra> 5.1.28-0ubuntu1
[18:35] <ogra> had the fix, it regressed in beta
[18:35] <pitti> ogra: I mean the fix you just uploaded, http://launchpadlibrarian.net/18772938/ltsp_5.1.29-0ubuntu3_source.changes
[18:36] <ogra> it was working in beta (due to being regressed from hardy for teh whole cycle), the fix was uploaded on oct 11th (sfter beta)
[18:36] <ogra> *after
[18:37] <ogra> that was bug 281196
[18:38] <ogra> pitti, between the upload and today nobody tested ltsp builds from CD
[18:38] <pitti> ogra: ok, you are 100% sure about the fix?
[18:39] <ogra> it works fine for non CD builds but due to the fact of universe not being on ubuntu CDs it breaks there
[18:40] <ogra> pitti, i havent tested it myself, i'm up to my ears in -mobile tests but i'm sure the --components main,restricted sets the right options for ltsp-build-client
[18:40] <ogra> since that was the default until we added the xubuntu fix
[18:40] <stgraber> pitti: I also had a look at the debdiff and I'm pretty sure it'll fix bug 287098
[18:40] <stgraber> ogra: is there an easy way to test it ? (other than rebuilding a cdimage)
[18:41] <pitti> oh, this bug shuold have been mentioned in the changelog
[18:41] <ogra> pitti, it was filed after my upload :)
[18:41] <stgraber> pitti: I opened the bug after ogra uploaded the fix
[18:41] <pitti> ogra: accepted, please close the bug manually then
[18:41] <pitti> ah, heh
[18:41] <ogra> will do, thanks
[18:46] <stgraber> ogra: I closed the bug
[18:47] <ogra> thanks :)
[18:48] <davmor2> Riddell: did you get the jockey thing sorted?
[18:48] <kees> lool, seb128: something broke in libv4l/cheese -- gstreamer v4l doesn't seem to work any more.
[18:54] <pitti> cjwatson: ah, libmail-sendmail-perl has no further dependencies and 0 bugs, I'll just review and promote it
[19:01] <superm1> pitti, given the RC DVD hasn't been created yet (AFAIK), will it be possible to adjust the components for the pieces of fglrx pre-rc so that it can now get included on that RC DVD, or will that need to be post-rc too?
[19:01] <pitti> superm1: that should be possible, since it will be a while until we can actually build DVDs
[19:01] <pitti> slangasek: ^ ok for you, too?
[19:02] <slangasek> yes, that's ok with me
[19:02] <slangasek> that needs to be re-seeded somewhere?
[19:02] <pitti> superm1: is it already seeded?
[19:02] <superm1> pitti, no it's not seeded yet. we were waiting for it to be in the right component before breaking the DVD again
[19:06] <pitti> superm1, slangasek: moved to restricted
[19:07] <pitti> erm, hang on
[19:07] <pitti> 2008-10-21 18:07:06 WARNING 'fglrx-installer' has no binaries published in intrepid
[19:07] <pitti> WTH?
[19:07] <superm1> check NEW
[19:07] <pitti> oh, NEW
[19:07] <superm1> the library was moved into it's own binary package
[19:07] <pitti> right, that
[19:08] <pitti> NEWed to multiverse
[19:09] <NCommander> superm1, I see you resolved your library issues
[19:09] <superm1> NCommander, well just the workaround that you and I discussed yesterday to not use dpkg-shlibdeps
[19:10] <NCommander> superm1, its an ugly situation
[19:10] <pitti> superm1: ok, I think I sorted out the remaining overrides (fglrx-modaliases -> main, libamdxvba1 -> multiverse, rest -> restricted)
[19:10] <superm1> pitti, well fglrx-amdcccle doesn't need to be restricted i dont think.  it's equivalent for nvidia (nvidia-settings), where's that live?
[19:11] <pitti> superm1: main :)
[19:11] <superm1> pitti, ah okay :)
[19:11] <pitti> superm1: it's GPL and needed for both universe and restricted pacakges
[19:12] <pitti> superm1: so what should we seed? jockey-common already pulls fglrx-modaliases
[19:12] <pitti> so just fglrx-kernel-source and xorg-driver-fglrx ?
[19:12] <pitti> do we need xorg-driver-fglrx-dev ?
[19:12] <pitti> tseliot: ^
[19:12] <superm1> pitti, i think just xorg-driver-fglrx
[19:12] <superm1> that will pull in fglrx-kernel-source
[19:12] <superm1> the -dev doesnt need to be seeded
[19:13] <pitti> ah, indeed
[19:13] <pitti> and it Recommends: fglrx-amdcccle
[19:13] <pitti> so that needs to be in restricted, too
[19:14] <pitti> ok, seeding done
[19:15] <superm1> okay thanks
[19:34] <liw> mvo, I fear I don't know python-apt (libapt?) well enough to understand how your suggestion on dealing with the Synaptic pin settings ("lock package") should be done; do you have further advice?
[19:35] <cpufreak> top
[19:35] <cpufreak> ww.
[19:41] <pitti> infinity: do you have a magical stick to tell king and terranova "nah, I don't actually want this DVD livevs any more" and cancel it?
[19:44] <lool> kees: Weird, I tested yesterday and it worked
[19:44] <slangasek> ogra, tjaalton: I'm skeptical of accepting the fix for bug #282203 at this stage; it's my understanding that hotplug doesn't work well for tablets no matter what you do, and it sounds like re-adding the fdi will cause regressions for users on upgrade
[19:44] <lool> kees: both with cheese 2.24.0 and 2.24.1
[19:44] <lool> kees: It breaks for you?
[19:44] <slangasek> tjaalton: so I don't think that really qualifies for a two-days-before-RC accept
[19:45] <lool> kees: Works just fine here
[19:48] <tjaalton> slangasek: well, regression when upgrading from hardy, yes
[19:49] <tjaalton> slangasek: if they use more than just the stylus
[19:49] <slangasek> tjaalton: which I understand the kind of users who have tablets tend to do :-)
[19:50] <mvo> liw: did my snippet not work?
[19:50] <liw> mvo, cache._depcache.ReadPinFile("/var/lib/synaptic/preferences")
[19:50] <liw> mvo, that works, but what do I do next?
[19:50] <tjaalton> slangasek: yeah, your call :)
[19:51] <mvo> liw: that should be all required, no?
[19:53] <liw> mvo, my code (based on your initial code) checks for isInstalled, installedDownloadable, candidateDownloadable, and _pkg.VersionList -- based on those, it still determines that the package is cruft
[19:53] <lool> kees: Could you check your upgrade logs and see which package regressed here?  I'm using libv4l 0.5.1 BTW
[19:57] <kees> lool: hrm, after a full update and reboot, it seems fine.
[19:57] <kees> lool: I must have seen some kind of intermediate breakage.
[19:57] <lool> pitti: Supposedly, gstreamer-plugins-ugly is just to play the format supported only by plugins in this package; I'm downgrading to suggests as well
[19:57] <kees> lool: sorry for the false alarm  :P
[19:58] <tseliot> pitti: yes, we don't need the fglrx -dev package
[19:58] <tseliot> superm1, pitti: from what I remember amdcccle is proprietary
[19:58] <liw> if I want to programmatically sort a list of kernel packages into order by version number, and they follow the linux-image-$VERSION pattern, I can just sort the package names, right?
[19:58] <pitti> tseliot: yes, the question was just about restricted vs. multiverse
[19:58] <lool> kees: Some people seemed to say that the cam would only work once
[19:59] <lool> kees: I suspect it needs clean shutdown or something
[19:59] <pitti> tseliot: it's in restricted now, since xorg-driver-fglrx recommends it
[19:59] <pitti> lool: ok, thanks; so that, promote libvisual-plugins, and drop jack from the latter is the way to go now?
[19:59] <lool> pitti: jack is shlibs borkeness I think
[20:00] <tseliot> pitti: yes, it should stay in restricted
[20:01] <mvo> liw: hm
[20:01] <mvo> liw: let me update the code
[20:01] <tseliot> pitti: I mean, good choice
[20:01] <lool> pitti: What's the path between libvisual and jack?  bdeps?
[20:02] <lool> I don't like removing jack this late, it could break ubuntu studio or something
[20:03] <lool> Actually the bdep is suspicious, I see references to jack in the upstream code, but no dep
[20:03] <pitti> lool: yes, it b-deps on it; curiously enough it doesn't seem to *binary*-depend on jack
[20:04] <lool> Yeah, I suspect the configure check fails for some reason
[20:04] <lool> looking at build log
[20:04] <kees> lool: works multiple times for me, even after a -9 kill.
[20:04] <lool> checking for LIBJACK... yes
[20:05] <lool> pitti: I think it simply isn't installed
[20:05] <lool> drwxr-xr-x root/root         0 2007-11-26 11:44:10 ./usr/lib/libvisual-0.4/input/ => no jack
[20:06] <pitti> lool: ah; so removing the b-dep now wouldn't actually change anything
[20:06] <ia> hello, everybody. I've found out some intresting bug and will be very appreciate, if someone else check it, because i'm not sure, that someone else have this issue - http://bugs.launchpad.net/ubuntu/+bug/287134 :-)
[20:06] <lool> pitti: it never goes into input/jack for some reason
[20:07] <lool> SUBDIRS = $(build_input_plugins)
[20:07] <mvo> hm, who can prod the retracer? bug #286915 has no backtrace and it would be nice to have one
[20:07] <lool> Input plugins            : alsa mplayer => no jack
[20:08] <liw> ia, I cannot reproduce that
[20:08] <bryce> I got to run a friend to the train station; be back after lunch
[20:08] <lool> pitti: I'm kind of WTF, build_input_plugins="" is reset in configure.ac for no apparent reason
[20:08] <lool> pitti: Anyway, will report to Debian and will remove bdep
[20:08] <pitti> lool: splendid, thanks
[20:09] <pitti> lool: I'm somewhat grateful about this bug, though, since it allows us to drop it without changing runtime behaviour :)
[20:09] <pitti> lool: I'll review libvisual-plugins for MIR after dinner
[20:10] <lool> pitti: Yeah, incredible coincidence :)
[20:10] <lool> pitti: I'm dropping libesd0-dev bdep for the same bug...
[20:11] <superm1> pitti, post rc, i'm going to have an extra hook to add for bluetooth stuff that's used in pm-suspend.  would you rather see it land in the bluez package for now as a patch, or in the pm-utils package as a patch?  I'm been waiting for the pm-utils maintainer to ack it before i brought it up, but it's looking like that might not happen in time
[20:29] <lool> pitti: Frankly libvisual-plugins is not the cleanest; I got lintian errors and last upload in Debian was a year ago (albeit there's no reported bugs and it's the latest upstream version), the upstream site is more or less broken
[20:30] <dashua> mvo: Synaptic Quick Search is fixed.  Thank you :)
[20:30] <mvo> dashua: excellent, thanks for testing it :)
[20:30] <dashua> Np
[20:34] <sleon> i have a problem, that after i hibernated my computer, it stopped starting with acpi mode on
[20:47] <ogra> slangasek, well, its a "at least something that works" approach i'd say
[20:48] <slangasek> ogra: you're saying that it's better to handle it through evdev?
[20:48] <slangasek> er, s/evdev/hotplug/
[20:48] <ogra> well, hal-input is the future
[20:48] <ogra> so you would have at least something that works with the desired model
[20:49] <slangasek> but it would still be a regression for hardy users; there's no reason we need to ship every available bit of the "future" in a release, if it gives an inferior user experience
[20:49] <ogra> i plan to put up a howto for touchscreen users for which i havent gotten evtouch data yet to create .fdi files, i assume that could be extended for wacom users and how to set up your device
[20:50] <ogra> though for touchscreens *everything* is an improvement to the former situation ...
[20:50] <ogra> the prob is that the actual regression is between gutsy and hardy
[20:51] <ogra> for wacom
[20:51] <slangasek> howso?
[20:51] <ogra> we shipped all the tablet default sections in gutsy, they were dropped because users without wacom devices complained about the warnings in the xorg logs
[20:52] <ogra> so hardy didnt ship any default sections for wacom users and they had to set them up theirselves
[20:52] <slangasek> ok, but anyone who had configured their tablet manually in X for hardy is now going to have it broken again if we enable this fdi file
[20:52] <ogra> right
[20:52] <RainCT> wb seb128
[20:53] <ogra> which imho wuld be ok if we offer a way to show them how to adapt to the new config
[20:53] <pgraner> slangasek: ping
[20:53] <slangasek> ogra: "offer" how?  release notes?
[20:53] <slangasek> we might as well leave the package as it is and release note everything, I think
[20:53] <slangasek> pgraner: moo
[20:53] <ogra> release notes pointing to a howto that explains how to create a fdi file
[20:53] <seb128> hi RainCT
[20:54] <ogra> well, the trasition will have to happen anyway, we just postpone the prob
[20:54] <pgraner> slangasek: we need to upload one more kernel to address some last min issues, rtg is ready any time, wanted to make sure it was cool with you before we proceeded
[20:54] <ogra> and with the request to users to file their created .fdi files jaunty would have all data available early
[20:55] <pgraner> slangasek: not an abi bumper, just some regression cherry picks and a few device enablers that are isolated and not a big risk
[20:55] <slangasek> ogra: the problem only exists because we have incomplete support for these devices via hotplug, and should be resolved for jaunty; we can do that just as well without breaking the hardy->upgrade path for users...
[20:55] <slangasek> pgraner: which last-minute issues?
[20:55] <ogra> slangasek, well, currently all i hear is that it doesnt work on upgrades either
[20:56] <RainCT> seb128: I've added .ephy-extension.in to po/POTFILES.in but running "intltools-update -p" doesn't include the strings for _Name nor _Description from it into the .pot. Any idea what could be wrong? (It's up on lp:epiphany-extensions-extra, if you want to look).
[20:56] <ogra> juliux is a typical candidate here btw
[20:56] <slangasek> ogra: I'd like some solid confirmation of that in the form of a bug report
[20:56] <slangasek> ogra: I'm not going to risk breaking the upgrade path based on hearsay
[20:56] <ogra> juliux ^^^ mind adding info to the bug ?
[20:56] <mdke> pitti, slangasek: on ubuntu-docs, shipping translations with 70% translation or more results in a package size of 2.9MB (as against 2.3MB the current archive version). How does that sound?
[20:56] <pgraner> slangasek: XFS barrier support, intel G45 motherboard support
[20:57] <seb128> RainCT: I'm not a libtool wizard and I've other things to debug but it might use the filename, you said that was a .desktop before
[20:57] <juliux> hm?
[20:57] <ogra> slangasek, i personally wasnt involved in tablets at all i only looked after touchscreens, i'm wiling to do so for jaunty though but wasnt aware o wacom probs until very recently
[20:57] <slangasek> pgraner: do you have a bug number for that latter issue?  Anyway we are at this point not going to be able to get it in for RC without a lot of pain; I'm not happy with the idea of pushing a new kernel between RC and final either, but probably will if that's what we have to work with
[20:58] <slangasek> pgraner: there are also a number of other targeted and milestoned linux bugs, such as bug #259157 and bug #284354 - are those in progress somewhere?
[20:58] <RainCT> seb128: I said ".desktop and similar files" :)
[20:58] <ogra> slangasek, at least the second one ws discussed in the kernel team meeting today
[20:59] <seb128> RainCT: dunno what is similar to a .desktop, what I said was for a desktop before
[20:59] <pgraner> slangasek: 259157 won't happen before RC ath5k is a mess upstream and we don't have good answer other than it is going to go as is and we'll hopefully get it cleaned up in a update
[21:00] <RainCT> seb128: that it also has Name and Description entries, and epiphany-extensions is doing it like that too (but using autotools)
[21:00]  * ogra likes to note that he is massively unhappy about that we wont release ubuntu-mobile with working wireless for most mobile users that way
[21:00] <slangasek> pgraner: will 259157 happen /after/ RC, then?  if so, I think we're better off with a single kernel upload for the lot, instead of breaking our necks to get one in pre-RC and then having another post-RC
[21:00] <pgraner> slangasek: 284354, amitk is working on it
[21:00] <RainCT> seb128: uhm, renaming it to .desktop.in works
[21:00] <RainCT> *it works
[21:01] <pgraner> slangasek: not for awhile, thats why we wanted to get these in before
[21:01] <RainCT> seb128: well, go debug your stuff, I'll see if I get it working :)
[21:01] <RainCT> seb128: thanks
[21:02] <slangasek> mdke: I believe all the images can spare 600k at this point, yes
[21:03] <lamont> Function `cairo_pdf_surface_create_for_stream' implicitly converted to pointer at /build/buildd/gtk+2.0-2.14.4/modules/printbackends/lpr/gtkprintbackendlpr.c:212
[21:03] <lamont> stupid gtk2.0
[21:03] <mdke> slangasek: I'm trying 75% to see if that will squeeze a bit more out, I think that's a fair percentage to go up to
[21:03] <lamont> gtk+2.0, that is
[21:03] <slangasek> mdke: feel free, but I think 600k is already something we can live with (after the last round of pruning that pitti had to do :/)
[21:04] <slangasek> pgraner: "not for a while" as in, you believe 259157 is now SRU material?
[21:04] <mdke> slangasek: thanks very much. I'll give 75% a try and then re-ask for sponsoring of the upload
[21:05] <pgraner> slangasek: yep, there is not a solution upstream or much we can do ATM. rtg wants to hold off until a better solution develops
[21:05] <lool> pitti: I pushed a bunch of libvisual-plugins uploads, as I got hooked into fixing it's packaging; I think the package is quiet upstream and in Debian, working decently in its current version, and not risky security wise, so I think we can promote it as being relatively pure logic; the two inputs currently enabled are alsa and mplayer, so I think there's no high risk here
[21:07] <tseliot> slangasek: I showed my (3 lines) changes to the release notes to pitti and he said that they looked good. The grammar should be ok too: https://wiki.ubuntu.com/IntrepidReleaseNotes#nVidia%20%22legacy%22%20video%20support
[21:12] <[diablo]> good evening #ubuntu-devel
[21:12] <[diablo]> guys, could anyone please tell me the name of the script that is (iirc) from Dell for rebuild nvidia drivers
[21:12] <pgraner> slangasek: for the Intel G45 https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/285572
[21:13] <RainCT> [diablo]: hi, there's #ubuntu for support
[21:13] <pgraner> slangasek: this is a two part patch one goes in X, that bryce has put in X, the other is needed in the kernel
[21:13] <robertj> is there a VM somewhere that runs the automated unit tests nightly?
[21:13] <tseliot> [diablo]: it's DKMS
[21:13] <[diablo]> RainCT, nod...
[21:13] <pgraner> bryce: can you confirm pls?
[21:13] <[diablo]> sorry
[21:14] <[diablo]> thanks tseliot ! cheers dude
[21:18] <slangasek> tseliot: I'm not keen on suggesting in the release notes that users should run grep commands to find out if their system supports SSE
[21:19] <slangasek> tseliot: isn't it possible to enumerate the systems that don't support SSE?
[21:19] <tseliot> slangasek: what do you mean by enumerate?
[21:19] <slangasek> tseliot: list
[21:20] <pgraner> ogra: did you see amitk's comments in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/284354/comments/7
[21:20] <tseliot> slangasek: aah, writing a list of all the CPUs which don't support SSE
[21:20] <slangasek> tseliot: i.e., "486, Pentium, Pentium Pro, and AMD-whatsit", or similar
[21:20] <ogra> pgraner, that has a lot of potential for post release breakage in it
[21:20] <slangasek> the list of SSE-less CPUs that work with Ubuntu is fairly short, isn't it?
[21:21] <pgraner> rtg: ping
[21:21] <rtg> hmm?
[21:21] <ogra> pgraner, i'd like to avoid shipping lbm as a default package if possible
[21:22] <amitk> so here is the issue for bug #284354
[21:22] <tseliot> slangasek: ok, I think it can be done. I'll let you know when it's ready
[21:22] <amitk> mobile wants to blacklist ath5k
[21:22] <TheFiller> Are the ISO images of the alternate CD of the stable version (8.04) updated regularely?
[21:22] <amitk> but same pci id is working with ath5k for eee pc users
[21:22] <pgraner> rtg: 259157.... slangasek was asking on timeframe, I told him after GA due to upstream issues, sound right?
[21:23] <ogra> amitk, well, correctly said, mobile would like the driver from lbm in the default kernel image
[21:23] <slangasek> pgraner: the X fix for 285572 is in the unapproved queue, yes
[21:23] <slangasek> TheFiller: they're updated as part of point releases, on an approximately 6-month cycle
[21:23] <rtg> amitk: what will they use for their WPA solution?
[21:23] <rtg> pgraner: yes
[21:23] <amitk> ogra: that can't happen the diff is too big
[21:23] <pgraner> slangasek: not sure I was told that bryce was adding it in via amitk
[21:23] <amitk> rtg: nothing, since there is no madwifi module in wpasupplicant
[21:24] <slangasek> TheFiller: this applies to 8.04 because it's an LTS (long-term support) release, it's not true of other Ubuntu releases
[21:24] <TheFiller> slangasek: Thank you. Does this also hold true for the 'normal' desktop CD? Or is this updated more often?
[21:24] <slangasek> pgraner: that was a statement, not a question :-)
[21:24] <slangasek> TheFiller: the same.
[21:24] <rtg> amitk: which means LBM (if they want WPA)
[21:24] <TheFiller> slangasek: Thank you
[21:24] <amitk> pgraner: slangasek: so we are good for the 285572 then
[21:25] <pgraner> slangasek: sorry my bad then
[21:25] <amitk> rtg: correct
[21:25] <RainCT> seb128: about bug #285695, I guess the change he did is that one you suggested to him (rename ~/.local)
[21:25] <amitk> ogra: seriously, why would you want to default to supporting only wep?
[21:25] <ogra> amitk, ??
[21:25] <slangasek> amitk: well, I haven't agreed to accept the changes yet before RC; I'm not keen on having to reroll all the CDs /again/ for this
[21:26] <ogra> amitk, with the ath5k from lbm everything works flawless
[21:26] <seb128> RainCT: rigjht, I was just asking in case he had a look to what setting exactly there is creating the issue
[21:26] <ogra> amitk, currently by default two drivers are loaded for the same device
[21:27] <amitk> ogra: ath5k in lbm is ok. but it is _NOT_ going to be integrated into the kernel
[21:27] <ogra> amitk, right, but i dont see a sane way of intregrating lbm in the default seeds
[21:27] <slangasek> amitk: btw, an 'ubuntu-8.10-beta' milestone for this bug is definitely unrealistic at this point :-)
[21:27] <amitk> so going by that assumption, your only choice is madwifi
[21:27] <amitk> slangasek: oops.
[21:27] <ogra> which is the current default
[21:28] <ogra> slangasek, modprobe timeshift :)
[21:28] <ogra> its the kernel team you deal with ;)
[21:29] <pitti> rtg, BenC1: hm, CDROM_DRIVE_STATUS is evil in the intrepid kernel (bug 283316); you don't happen to know about this, and whether this is considered a bug or a feature?
[21:30] <ogra> amitk, i'll discuss it with lool but i think we agree that we would be unhappy of carrying lbm as a dep of any of the meta packages
[21:30] <ogra> the change wouldnt happen before RC anyway
[21:31] <rtg> pitti: I noticed you have to be pretty quick.
[21:31] <slangasek> amitk, pgraner: when was the decision made to target this bug to intrepid?  it looks like the first follow-up from the kernel team was about 10 hours ago; if this had been discussed with the release team sooner we could have planned to include it in the CD pulse that we're halfway through at the moment, now I instead have to evaluate whether this change alone justifies rerolling everything or else waiting to batch it with other pending fixes
[21:31] <amitk> ogra: noted. And kernel team agrees that shipping a new ath5k at this stage is not a option because all the drivers will have to be bumped up to match the headers required by new ath5k
[21:31] <ogra> all solutions apart from getting teh working driver from lbm into mainline are resulting in releasing a broken wlan support for final
[21:31] <pitti> rtg: I was just told about it today; my laptop's external CD drive can't mechanically close, so I never noticed myself so far
[21:32] <ogra> which is very odd as it will lose us people from the community which was our (or rather my) main focus for this release with the mobile image
[21:32] <slangasek> amitk, pgraner: also, is EXA default on this hardware?
[21:32] <slangasek> s/on this hardware/with this driver/
[21:32] <rtg> pitti: same here (no mechanical door)
[21:32] <amitk> slangasek: it was brought to my attention a few hours ago. So not a long time has passed. And the patch seemed fairly simple and straight-forward
[21:33] <amitk> slangasek: but I would be willing to pull it from the kernel release if it is causing major headaches.
[21:33] <pitti> rtg: so given that the documentation says that there is a possible CDS_TRAY_OPEN, I'd consider this a bug
[21:33] <slangasek> amitk: the question isn't whether the patch is straightforward; there's a larger picture here
[21:33] <rtg> pitti: I do have a couple with drive motors somewhere. I'll test it.
[21:34] <amitk> slangasek: agreed. I didn't see that picture and stand rebuked.
[21:34] <slangasek> amitk: re-rolling all the CDs for a kernel fix is costly when we're this close to RC; it costs us time for the actual builds, and it also costs us testing resources
[21:35] <rtg> pitti: I remember a patch to the eject package awhile back. I wonder if that messed something up.
[21:35] <pitti> rtg: no, it's not related to that
[21:36] <jcristau> slangasek: yes, exa is the default. i'm not sure it's relevant to the bug though.
[21:36] <pitti> rtg: I updated the bug title and added a comment
[21:36] <pitti> rtg: I'm looking for an upstream bug now, and try to find the commit that changed it
[21:40] <pitti> rtg, BenC: oh, do we use a different kernel driver for CD-ROMs in intrepid? ide-cd vs. some SCSI emulation thingy?
[21:41] <rtg> pitti: its possible, I haven't followed the SCSI layer very closely.
[21:42] <BenC> pitti: there's ide-cd and sr_mod, but they both use cdrom.ko for low level, IIRC
[21:42] <pitti> ide-cd.ko exists in hardy, but not in intrepid
[21:42] <slangasek> amitk, pgraner: ok, please go ahead with the linux upload with those two fixes (285779 and 285572); I haven't decided yet whether to accept those packages before RC, but I will definitely try to if the opportunity presents iself
[21:42] <slangasek> itself
[21:42] <cody-somerville> slangasek, btw, if you're considering rerolling the rc, I'm in favour.
[21:43] <cody-somerville> We forgot to update our docs so everything still says 8.04
[21:43] <cody-somerville> Well, we didn't forget, we were waiting on someone but they didn't come through
[21:43] <slangasek> cody-somerville: I assume you mean xubuntu?  We can do individual rerolls with much less pain
[21:43] <pitti> BenC: there is a related commit (not for this bug, though) which seems to indicate that ide-cd and SCSI use different ioctl implementations: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=210ba1d1724f5c4ed87a2ab1a21ca861a915f734
[21:43] <cody-somerville> slangasek, aye
[21:44] <slangasek> BenC: is there an update to linux-firmware in the pipe for the copyright problem?
[21:44] <slangasek> cody-somerville: are the fixed docs uploaded? :)
[21:44] <cody-somerville> slangasek, Okay. I'm going to sponsor NCommander's upload once it is ready and then I'd like to reroll Xubuntu.
[21:44] <BenC> pitti: hmm...well, unless something changed in sr_mod between hardy and intrepid, nothing should be different
[21:44] <slangasek> cody-somerville: ok - the actual reroll will probably be held until we have a decision on the kernel stuff
[21:45] <BenC> pitti: I doubt many people were using ide-cd in hardy
[21:45] <pgraner> slangasek: ack
[21:45] <BenC> slangasek: I might have something partial done...tracking down all this firmware is difficult
[21:45] <rtg> slangasek: you'll get some other baggage in the kernel upload for free. I pulled in the stable tree updates from <IP_ADDRESS> a couple of days ago.
[21:45] <pitti> BenC: ah, so we were using sr_mod in hardy, too? that's a good data point
[21:46] <slangasek> BenC: understood... :)  Even if you don't think you'll have it all tracked down for final, please plan to upload at least a partial fix
[21:46] <BenC> pitti: Oh yeah, most ATA controllers were handled by libata and not ide.ko as far back as feisty
[21:46] <BenC> slangasek: deadline?
[21:47] <slangasek> BenC: Sunday, for best results
[21:47] <BenC> slangasek: No problem then
[21:53] <pitti> BenC: hm, I'm a bit lost then; above git commit was actually the last change to sr_ioctl.c, and it happened in January (thus hardy should have it)
[22:00] <pitti> superm1: having the patch in pm-utils is fine, at least for intrepid (if upstream refuses it, we have to re-negotiate  it)
[22:02] <superm1> pitti, okay, i've put the debdiff on a bug and subscribed ubuntu-release for now then, and i'll plan to upload after rc and someone on release looks at it
[22:10] <[Relic]> What do you do if a fix has been submitted but seems only to work in 32bit versions and not 64bit version of 8.04 (an LTS fix)?
[22:18] <RainCT> [Relic]: complain about it on the bug report
[22:27] <ryu2> j #ubuntu-de-offtopic-offtopic
[22:27] <ryu2> sorry :/
[22:32] <Riddell> cjwatson: ubiquity changelog is still UNRELEASED for the version uploaded yesterday, I'll change that to intrepid and assume there's no other changes that havn't been committed
[22:32] <cjwatson> Riddell: who uploaded it?
[22:32] <cjwatson> Riddell: please get them to commit
[22:33] <slangasek> asac: since the kernel team says their side of 259157 is not fixable prior to release, is it possible to get the driver tweaks back into NM in that same timeframe?
[22:34] <TheMuso> kwwii: ubuntustudio-look is the source package.
[22:34] <Riddell> cjwatson: you're in the changelog line
[22:34] <cjwatson> Riddell: surely not. https://lists.ubuntu.com/archives/intrepid-changes/2008-October/009050.html says Evan uploaded it
[22:34] <Riddell> ah, but it was evand indeed
[22:34] <cjwatson> Riddell: besides I bind all my bzr checkouts so I don't generally have this problem ;-)
[22:36] <cjwatson> Riddell: in future I really prefer it if commits don't happen until after this is done properly so that tags are accurate
[22:36] <cjwatson> call me anal if you wish :)
[22:36] <cjwatson> but the way you did it means that there is no possible correct location for the tag
[22:36] <Riddell> cjwatson: I didn't know ubiquity had tags
[22:37] <cjwatson> Riddell: debcommit -r sets them automatically
[22:37] <asac> slangasek: no ... there are no driver tweaks for atheros
[22:37] <asac> in NM
[22:39] <slangasek> asac: so without the kernel fix available, our only other option is release notes?
[22:39] <asac> slangasek: i lengthy explained that in the kernel team meeting
[22:40] <slangasek> asac: sorry, I need the less-lengthy explanation for RMs that are juggling very sharp CDs :-)
[22:41] <cjwatson> Riddell: can I uncommit this, tag it properly, and put your change back at the end?
[22:41] <asac> slangasek: short version: for ath NM tweaks cannot be added back in a reasonable time.
[22:41] <slangasek> asac: ok - release-noting then, thanks
[22:41] <Riddell> cjwatson: sure
[22:42] <asac> slangasek: i suggested to the kernel team to gather feedback and blacklisting ath5k for those that we know that work with ath_pci in a SRU
[22:42] <slangasek> ok
[22:42] <asac> for those == pci ids
[22:42] <asac> unfortunatley we have no detailed infos what ids those are
[22:44] <slangasek> cjwatson: bug #204272> my investigations lead me to believe we have a horrible, horrible thread race somewhere in gstreamer/pulse, I haven't updated the bug at all because I don't have anything conclusive and am not even sure my crash is the same one
[22:48] <rtg> slangasek: uploaded linux_2.6.27-7.13
[22:49] <rtg> I'm fleeing for awhile. I'll check back in a few hours.
[22:49] <slangasek> rtg: thanks
[23:04] <cjwatson> Riddell: done (you'll need bzr pull --overwrite if you're branched, though I think if you're using a checkout then bzr up should be enough)
[23:05] <cjwatson> Riddell: I used arcane trickery to uncommit but then merge back the uncommitted change, so it shows as a branch
[23:05] <cjwatson> well, I suppose I could just have done branch+uncommit+commit+merge but I didn't ;-)
[23:06] <Riddell> cjwatson: thanks, hope that didn't cause you too much trouble
[23:06] <cjwatson> no trouble
[23:07] <cjwatson> I just find it useful to have all the "i"s dotted close to release so that we can do accurate archaeology if need be :)
[23:11] <slangasek> kirkland: have you seen bug #285269?
[23:13] <cjwatson> slangasek: that definitely seems like a bug
[23:13] <cjwatson> evand: ^-
[23:13] <cjwatson> the code below handles boot_device that way ...
[23:14] <kirkland> slangasek: cjwatson: Hauke  wrote 17 minutes ago that it's fixed for him in 20081021.3
[23:14] <slangasek> er
[23:14] <slangasek> how did that happen? :)
[23:14] <cjwatson> kirkland: he's describing a different problem
[23:14] <cjwatson> silly people conflating bugs
[23:14] <slangasek> right
[23:14] <kirkland> erg
[23:15] <cjwatson> I've cranked the bug up to triaged/high/ubuntu-8.10
[23:15] <slangasek> ah, is that why my attempt to approve the nomination is hanging
[23:15] <cjwatson> could be :)
[23:16] <cjwatson> I'll see if I can reproduce
[23:16] <kirkland> cjwatson: i'm trying here
[23:17] <kirkland> slangasek: cjwatson: the beta iso's were busted for me too...  i reported and fixed that last week
[23:17] <cjwatson> busted how?
[23:17] <cjwatson> anyway, the convert_to_uuid stuff wasn't added until somewhat post-beta
[23:17] <kirkland> cjwatson: see the last couple of grub/mdadm patches you sponsored for me
[23:17] <cjwatson> ok
[23:18] <cjwatson> but forget about LVM/md, that isn't what this bug is describing
[23:18] <kirkland> cjwatson: okay, i'm testing now
[23:18] <cjwatson> if you read the description
[23:18] <cjwatson> it's talking about perfectly ordinary block devices, but you just happen to have a separate /boot
[23:19] <cjwatson> slangasek: is this "release-note for RC, fix for final" territory or will you want to squeeze a fix into RC somehow?
[23:19] <slangasek> cjwatson: the former
[23:20] <cjwatson> thought so
[23:21] <Riddell> tseliot, pitti: girlfriends laptop now reinstalled with a hardy->intrepid upgrade and jockey-kde is working better, it offers me broadcom STA and b43 and ATI drivers
[23:22] <Riddell> tseliot, pitti: ATI and b43 resulted in a blank warning dialog, STA installed and is working well
[23:22] <pitti> Riddell: you ran jockey-kde through sudo? we still need to fix the .desktop file to make it work through the menu
[23:22] <slangasek> evand, cjwatson: bug #280515 was fixed in grub-installer, wasn't it?
[23:22] <tseliot> Riddell: blank??? With some button?
[23:22] <pitti> Riddell: blank warning dialog? that sounds bad
[23:23] <Riddell> pitti: I ran it through the systray icon
[23:23] <pitti> Riddell: yes, that works (I fixed that recently to go through kdesudo)
[23:24] <jarnos> Why is mapivi 0.9.1 rather than mapivi 0.9.7 is added to the universe repository of intrepid? They differ a lot: http://mapivi.sourceforge.net/mapivi.shtml#news
[23:24] <Riddell> the .desktop file needs vmvmvmvmvmvmvmvm
[23:24] <Riddell> no, it doesn't
[23:24] <Riddell> it needs X-KDE-SubstituteUID=true
[23:25] <tseliot> Riddell: did you try installing policykit-gnome?
[23:26] <cjwatson> slangasek: sounds like 282037
[23:26] <cjwatson> slangasek: oh, it's only bug 282037 if the install was *from* a flash drive
[23:26] <cjwatson> slangasek: it ought to have been fixed by the addition of UUIDs
[23:27] <kirkland> cjwatson: i have reproduced the problem here
[23:28] <Riddell> tseliot: yes
[23:28] <kirkland> cjwatson: slangasek: shall I test the proposed fix?  http://launchpadlibrarian.net/18655689/xxxx
[23:28] <Riddell> tseliot: currently it says I should restart for the ATI driver, so I guess I'll do that
[23:28] <kirkland> looks reasonable ^
[23:28] <tseliot> Riddell: and are you getting a blank dialog with some button or what?
[23:29] <tseliot> Riddell: e.g. a blank progress dialog
[23:30] <slangasek> cjwatson: I thought that's what the "not CD image" comment meant, but it's of course ambiguous
[23:30] <slangasek> kirkland: yes, please test && commit
[23:31] <kirkland> slangasek: commit?
[23:31] <slangasek> kirkland: to the grub bzr tree?
[23:31]  * kirkland doesn't have commit access, but i'll put it somewhere mergable
[23:33] <slangasek> oh, right
[23:33] <slangasek> do that then :)
[23:33] <Riddell> tseliot: I rebooted, now I have both broadcom STA and ATI drivers enabled (it no longer offers me b43)
[23:33] <Riddell> tseliot: if I click to disable ATI driver it just disabled the top listwidget and nothing much happens
[23:33] <Riddell> tseliot: I suspect the blank error dialogue was from when i had no network
[23:34] <tseliot> Riddell: yes, that's likely to be the cause but the dialog shouldn't have been blank
[23:35] <tseliot> Riddell: and you should've seen a progress dialog when removing the driver too. Have you ever seen a progress dialog in jockey-kde (in intrepid)?
[23:35] <Riddell> tseliot: yes, when installing broadcom STA
[23:37] <tseliot> Riddell: hmm... ok I'll do some testing tomorrow so as to see if I can reproduce the problem. Thanks for your feedback
[23:37] <cjwatson> kirkland: the comment change in http://launchpadlibrarian.net/18655689/xxxx is bogus; the rest should be OK
[23:39] <kirkland> cjwatson: i'm trying to figure out the best way to test this, since this is in a deb, not a udeb
[23:40] <pitti> BenC: I reported the CD-ROM ioctl bug upstream, let's see whether someone finds something
[23:40] <kirkland> cjwatson: i'm not sure you've shown me that -fu yet
[23:40] <cjwatson> kirkland: 'sleep 3600 || true' after the apt-install block in /usr/bin/grub-installer, then edit the code in /target/usr/sbin/update-grub, then kill the sleep process
[23:40] <slangasek> kirkland: install; mv /boot/grub/menu.lst{,.bak}; update-grub -y?
[23:40] <slangasek> or that
[23:40] <cjwatson> s/then edit/wait for the installer to reach the sleep, then edit/ of course
[23:41] <kirkland> cjwatson: slangasek: thanks, i'm on it
[23:52] <NCommander> ScottK, I did plan to become a formal backporter. jdong already said yes, pending MOTUship
[23:58] <kirkland> cjwatson: slangasek: test successful
[23:58] <kirkland> cjwatson: slangasek: regression testing required?
[23:59] <slangasek> kirkland: regression-testing> test that it also DTRT with a single-partition install? :)
[23:59] <kirkland> slangasek: let me push a bzr branch, and then i'll test that