[00:08] <NCommander> Bug #272576
[00:55] <calc> grr seems like launchpad is always going down for maintainance
[00:56]  * calc thought he was going to be doing bug triage but apparently not
[00:56]  * NCommander watches REVU die
[00:57] <NCommander> I can understand shutting down edge for maintance, but is it really necessary to completely kill everything?
[00:57] <kwwii> calc: did you get the updated icons and license info into OOo?
[00:58] <ogra> kwwii, what are yu doing up at 2am ?
[00:58] <TheMuso> calc: I know what you mean, as it generally lands smack bang in the middle of my work day, so I have to find other things to do.
[00:58]  * ogra can blame the glenvilet and RichEd but whats your excuse :P
[00:59] <ajmitch> NCommander: did that kill revu due to the openid hooks?
[00:59] <crimsun> TheMuso: hey, no boogs!
[00:59] <directhex> zaroo boogs.
[00:59] <ajmitch> iz gtk boog?
[00:59] <TheMuso> crimsun: heh
[00:59] <NCommander> ajmitch, yup
[01:01] <kwwii> ogra: waiting to come kassel for release :)
[01:01] <ogra> hehe
[01:02] <ogra> feel free
[01:02] <kwwii> hehe
[01:03] <kwwii> time for sleep here
[01:03] <ogra> yeah
[01:03]  * ogra did his final upload ...
[01:04] <TheMuso> crimsun: Any luck with that pulse sink stuff? I'm going to start again in a bit since LP is down. Am happy to go from where you have left off.
[01:05] <slangasek> kirkland: still around?
[01:05] <kirkland> slangasek: yessir
[01:05] <crimsun> TheMuso: been chasing ALSA and PA stuff concurrently, and honestly, didn't have time to look at the latter.  Sorry.
[01:05] <TheMuso> crimsun: np
[01:05] <calc> gar when lp goes down all hosted things go with it
[01:05] <slangasek> kirkland: hmmm.  are you going to be around until the end of the LP maintenance window? :-)
[01:06] <calc> they really need to make lp more robust if they are going to keep bringing it down (what seems like) every week for several hours
[01:06] <kirkland> slangasek: :-)  probably, how much longer is that?
[01:06] <slangasek> I just got done smoke-testing my pam fix, and there goes LP, whoops :)
[01:06] <slangasek> kirkland: up to but not to exceed 2 hours
[01:06]  * calc can't even run bzr log on one of his checkouts
[01:06] <kirkland> slangasek: i'll probably have my laptop with me, watching the debate
[01:06] <slangasek> ok
[01:11] <calc> oh well as long as i can't get anything done right now i might as well upgrade to intrepid, lol
[01:15]  * NCommander sleeps soundly waiting for LP to return :-)
[01:16] <StevenK> calc: Unbind it
[01:17] <cjwatson> yeah, bzr unbind
[01:17] <ogra> grmbl
[01:17] <StevenK> calc: Maybe 'bzr log --local' works too
[01:17] <cjwatson> you can bzr push and bzr bind again later
[01:17] <ogra> i uploaded at 23:52 UTC ... no trace that LP got it in time
[01:18] <cjwatson> it won't have vanished, it'll be in the queue
[01:18] <ogra> yeah, indeed
[01:18] <cjwatson> even if you had got an acceptance it wouldn't have been published anyway
[01:18] <ogra> but i wont know if it built
[01:18] <StevenK> ogra: If you're worried, one of us can poke on cocoplum
[01:18] <cjwatson> I imagine they'd just taken the cron jobs down in preparation
[01:18] <ogra> yeah
[01:19]  * StevenK runs to the doctors
[01:19]  * ogra watxhes "blow up" on tv ...
[01:19] <calc> ah ok
[01:20] <calc> bzr log --local doesn't seem to work for me, maybe after i finish upgrade to intrepid though
[01:21] <kirkland> slangasek: launchpad just started responding for me, fwiw
[01:21] <slangasek> kirkland: ok, please test lp:~ubuntu-core-dev/pam/ubuntu :)
[01:22] <TheMuso> yeah working here too.
[01:22] <calc> yipee it works for me again too :)
[01:22] <TheMuso> edge is at least.
[01:24] <NCommander> Lauchpad returns
[01:24] <NCommander> SHort downtime
[01:25] <bryce> NCommander: wow that was impressive
[01:25] <NCommander> bryce, what is?
[01:26] <bryce> NCommander: the shortness
[01:26] <calc> its always good to be early ;)
[01:26] <slangasek> augh, why did cracklib break
[01:26]  * slangasek shoots the cracklib packges
[01:30]  * directhex offers a convenient c# version of cracklib
[01:31]  * NCommander shoots C#
[01:32]  * directhex hands NCommander vb.net instead
[01:32]  * NCommander bursts into flames
[01:37] <slangasek> oh, geez; this is the worst bashism I've ever seen
[01:37] <slangasek> [ /usr/share/dict/words -nt non-existent-file ]
[01:37] <slangasek> true in bash and false in dash \o/
[01:38] <directhex> with #!/bin/sh ?
[01:38] <TheMuso> ew
[01:38] <cjwatson> add it to DashAsBinSh?
[01:39] <directhex> i thought intel were bad. do they still "support" ubuntu for their compilers as long as you replace the /bin/sh symlink?
[01:42] <slangasek> cjwatson: adding, thanks
[01:47] <bryce> ogra: what do you think of the patch in bug #222164?  Looks simple enough to me but I'm not sure what its implications are so have held off applying it
[01:49] <kirkland> slangasek: hmm
[01:49] <slangasek> ?
[01:50] <kirkland> slangasek: i pulled that tree, did a build, installed the debs, but I'm still getting the 'success' messages
[01:50] <kirkland> slangasek: is that supposed to be fixed?
[01:50] <slangasek> kirkland: post me your /etc/pam.d/common-password, please
[01:51] <kirkland> slangasek: http://pastebin.com/f7ea2568d
[01:52] <slangasek> kirkland: hmm
[01:52] <slangasek> kirkland: please run grep -vE 'pam_unix.so|pam_ecryptfs.so' /etc/pam.d/common-password | md5sum for me
[01:54] <kirkland> slangasek: 86180c1552203d9b58582cf547309d01
[01:55] <slangasek> kirkland: you built with -b and installed libpam-runtime, right?
[01:55]  * TheMuso grumbles at being pointed to an ubunt forums thread in a bug, and not being told on which page at the very least may be helpful.
[01:55] <slangasek> that md5sum matches the one I have listed
[01:55] <kirkland> slangasek: i just did "debuild" (no -b)
[01:56] <kirkland> slangasek: libpam-runtime 1.0.1-4ubuntu5
[01:56] <slangasek> kirkland: can you confirm that you see 86180c1552203d9b58582cf547309d01 in /usr/sbin/pam-auth-update?
[01:57] <kirkland> slangasek: negative
[01:57] <kirkland> hmm
[01:57] <slangasek> kirkland: what bzr revision do you have?
[01:57] <kirkland> let me check my bzr branch
[01:58] <kirkland> slangasek:  -- Steve Langasek <steve.langasek@ubuntu.com>  Thu, 09 Oct 2008 16:35:46 -0700
[01:58] <kirkland> slangasek: Tree is up to date at revision 760.
[01:59] <slangasek> I have revision 763 here
[02:00] <kirkland> slangasek: have you pushed?
[02:00] <slangasek> yes
[02:00] <calc> "This bug doesn't affect me (change)" what does that mean?
[02:00] <calc> i don't think i have seen that before on a bug page
[02:00] <kirkland> slangasek: let me try pulling again
[02:00] <slangasek> kirkland: checking whether I can pull it here as well
[02:00] <kirkland> slangasek: i did "bzr branch lp:~ubuntu-core-dev/pam/ubuntu"
[02:01] <slangasek> kirkland: right. I see revision 763 when I pull here, so perhaps we had a race condition there :)
[02:01] <kirkland> slangasek: i blew away my copy, pulling again now
[02:03] <kirkland> slangasek: okay, now i got 763 revisions
[02:05] <stgraber> calc: it's the new "me too" feature of LP, you probably are on edge
[02:06] <Hobbsee> greetings
[02:07] <calc> stgraber: ok
[02:07] <nxvl> hi Hobbsee
[02:07] <Hobbsee> hey nxvl!
[02:07]  * Hobbsee celebrates that the uni has unblocked some of their ports again
[02:07] <nxvl> i saw you are going to UDS this time!
[02:07] <stgraber> Hobbsee: oh, as in 6667 ? :)
[02:08]  * nxvl is at the university using an open 21 for ssh connections and ssh tunnels
[02:08] <Hobbsee> stgraber: nah.  993, etc.
[02:08] <Hobbsee> stgraber: i have an irc proxy, so don't use 6667 from my laptop.
[02:08] <slangasek> kirkland: ok, let me know how that goes :)
[02:08] <stgraber> ok
[02:09] <Hobbsee> nxvl: indeed!
[02:09] <stgraber> nxvl: oh, they let ftp go through their firewalls, that's good :) (for you)
[02:10] <kirkland> slangasek: aha!
[02:10] <kirkland> slangasek: that's looking together
[02:10] <slangasek> @yay
[02:10] <kirkland> slangasek: looking better
[02:10] <stgraber> nxvl: I used to connect on a Windows network with everything blocked except the proxy server ... so I had to use ntlmaps to connect to the ISA proxy (using NTLM), then use ssh over https on port 443 and finally openvpn over tcp going through a ssh tunnel to get complete internet access :)
[02:11] <stgraber> (all that scripted, it's not that difficult to setup and quite fast actually)
[02:11] <nxvl> yeah
[02:11] <kirkland> slangasek: but now quite there yet
[02:11] <kirkland> slangasek: checking the current password now does the right thing
[02:11] <nxvl> i have no proxy, just port blocking, so it's some steps less
[02:12] <kirkland> slangasek: it fails immediately, with the wrong password
[02:12] <slangasek> huzzah
[02:12] <kirkland> slangasek: but hit <enter> 6 times for the new password
[02:12] <kirkland> "No password supplied" x 3
[02:12] <nxvl> i just need an ssh running on 21, 80 or 443, and a lot of tunnels (on my .ssh/config)
[02:12] <kirkland> then "password updated successfully"
[02:12] <Hobbsee> stgraber: these guys were allowing 22, 443, and 80 for a while.  Only.
[02:12] <nxvl> and i'm done
[02:13] <kirkland> emma: :-)
[02:13] <TheMuso> crimsun: Did you try my interim Xsession.d fix to reduce the race condition's possibility?
[02:13] <kirkland> emma: $1000 says he lives on "Main Street"
[02:13] <kirkland> emma: "Not Wall Street"
[02:13] <crimsun> TheMuso: yes, and it helps.  I haven't been able to trigger the race yet.
[02:13] <nxvl> Hobbsee: for a geek it's only needed some imagination and patience
[02:14] <TheMuso> crimsun: Ok.
[02:14] <Hobbsee> nxvl: that's true.
[02:14] <nxvl> Hobbsee: there is no no-geek sysadmin that can make us be quiet
[02:14] <Hobbsee> hehe
[02:14] <nxvl> and even some geek sysadmins that can't
[02:15] <crimsun> TheMuso: OTOH, with current pulseaudio packages (i.e., no interim Xsession.d fix), the race on my machine is, at best, very difficult to trigger.  Seems it nondeterministically triggers once every twenty or so logins.
[02:15] <TheMuso> crimsun: Right.
[02:15] <TheMuso> crimsun: I am the same, but I can never trigger it.
[02:15] <slangasek> kirkland: ok, wheels turning in the noggin'; I may have to wait until after dinner to fix that
[02:15] <slangasek> (if I'm right about how to fix it at all, that is)
[02:16] <kirkland> slangasek: k
[02:16] <crimsun> Laney: how many audio devices are in your computer (experiencing the pulseaudio race on session login)?
[02:18] <stgraber> nxvl: well, the only thing that could have stopped my hack is some packet analysing (basicalling detecting that I'm not sending http over SSL but something else) that needs quite a powerful firewall to do and a lot of tweaking
[02:18] <stgraber> nxvl: so not really an option on a big network :)
[02:20] <ScottK> slangasek: It's been a couple of hours, so I'm asking again about kdepim in hardy-backports.
[02:20] <nxvl> stgraber: or a real proxy rejecting non http traffic, but for that we have http tunneling :P
[02:20] <slangasek> ScottK: right, looking :)
[02:21] <nxvl> stgraber: or a traffic analyzer and someone reading the logs and seeing what's going on and rejecting that connection, which is hard for any network
[02:21] <ScottK> slangasek: Thanks.
[02:23] <stgraber> nxvl: well, I was over HTTPS so the "rejecting non http traffic" is not possible as it only sees HTTPS (and the purpose of https is to not have man in the middle thing possible) :)
[02:23] <NCommander> So Canonical loves REVU
[02:23] <stgraber> nxvl: so a very well configured traffic analyser can detect that from the packet size and some other parameters (I remember reading about that) but it's not that easy to do and a real wast of CPU in most case
[02:23] <NCommander> http://revu.ubuntuwire.com/ - try logging in and look at the login page
[02:24] <slangasek> ScottK: accepted
[02:24] <nxvl> stgraber: that's why you need a real geeky sysadmin
[02:24] <ScottK> slangasek: Thanks.
[02:24] <stgraber> NCommander: :)
[02:30] <calc> crimsun: ping
[02:30] <crimsun> calc: pong
[02:31] <calc> crimsun: i see you followed up to 77435 but wasn't quite sure what you meant by 0.6/0.7/0.8 and another user claims it works fine
[02:31] <StevenK> nxvl: Looks fine to me
[02:32] <crimsun> calc: sorry, I should have been more specific; those versions refer to xmonad.
[02:32] <nxvl> StevenK: what did i did now/
[02:32] <nxvl> ?
[02:32] <StevenK> Er. NCommander, rather than nxvl
[02:32] <nxvl> oh
[02:32] <StevenK> nxvl: Sorry :-)
[02:32] <NCommander> StevenK, look closely at the text
[02:32] <NCommander> There is a thankyou on behalf of Canonical
[02:32] <calc> crimsun: oh ok
[02:32] <NCommander> (and the new working men image)
[02:33] <StevenK> Oooh, I see that
[02:33] <NCommander> It was an added bonus when I got REVU added to the trustroot so we can get full openid support
[02:33] <NCommander> which lead to this: https://bugs.edge.launchpad.net/launchpad/+bug/284133
[02:45] <nxvl> cody-somerville: the xubuntu instaler is livecd too?
[02:45] <cody-somerville> yes
[02:46] <nxvl> cody-somerville: just as the ubuntu installer?
[02:46] <cody-somerville> Right
[02:46] <nxvl> cody-somerville: so i can run the livecd and install from there
[02:46] <cody-somerville> yes
[02:46] <nxvl> awesome
[02:46] <nxvl> thanks
[02:51] <cody-somerville> no problem
[02:56] <kirkland> slangasek: another pam question for you when you come back from dinner
[02:58] <kirkland> slangasek: i have some people complaining that their ~/Private directories are being unmounted by their cronjobs
[02:59] <kirkland> slangasek: pam_ecryptfs is in the common-session stack, and cron opens/closes a session
[02:59] <kirkland> slangasek: the close session unmounts ~/Private
[03:01] <kirkland> slangasek: the current work-around is for those users to rm ~/.ecryptfs/auto-umount, which umount.ecryptfs_private checks for
[03:01] <kirkland> slangasek: but that disables automatic unmounting across the board
[03:03] <kirkland> slangasek: that's not ideal
[03:04] <kirkland> slangasek: a counter, has been suggested, but i'm not sure that's the best approach
[03:29] <calc> crap my upgrade to intrepid now won't boot
[03:30] <mrooney> calc: no more bugs, then!
[03:33] <calc> mrooney: yea sorta
[03:35] <calc> looks like i will need to download and completely reinstall
[03:40] <cjwatson> calc: :-(
[03:40] <cjwatson> try the live CD just as a checkpoint?
[03:41] <cjwatson> it'd be odd if a boot failure was due to upgrade vs. fresh install, though it's not unheard of
[03:41] <kirkland> slangasek: actually, i'm wondering, perhaps we should drop pam_ecryptfs from common-session?  would common-auth and common-password suffice?
[03:41] <cjwatson> though if it is due to upgrade vs. fresh install, then it should be rectifiable in-place
[03:42] <MacSlow> I'm trying to get a custom kernel going and currently hang at the initrd-creation-step ...
[03:43] <MacSlow> yaird gives me an error like: "yaird error: bad device link in /sys/block/sda (fatal)"
[03:43] <MacSlow> yaird -vd --output=initrd.img-2.6.27-rc9 2.6.27-rc9
[03:43] <MacSlow> is the command I use
[03:44] <MacSlow> but neither the "verboseness" nor the debug-output of yaird help me getting further clues what might be the cause of the error
[03:46] <DrPepperKid> but neither the "verboseness" nor the debug-output of yaird help me getting further clues what might be the cause of the error
[03:46] <DrPepperKid> hm... my connection crapped out
[04:01] <crimsun> TheMuso: have you settled on patching pulseaudio instead of libcanberra0.6?  I'm wondering if it doesn't make sense to touch the latter instead for intrepid...
[04:01] <calc> i managed to revive it
[04:01] <calc> i booted off 8.04 cd and remade the initramfs and that seemed to fix it
[04:01] <TheMuso> crimsun: I am unsure as to what we could do with libcanberra.
[04:01] <calc> it originally had hung right after loading the wifi driver (3945 card)
[04:01] <StevenK> libcanberra as in the city?
[04:02] <StevenK> calc: iwl3945?
[04:02] <calc> StevenK: yea
[04:02] <Hobbsee> calc: known bug.  just kepe trying tob oot
[04:02] <Hobbsee> calc: https://bugs.launchpad.net/bugs/263059
[04:02] <calc> Hobbsee: oh lovely
[04:02] <StevenK> calc: davidm has been having problems with it too
[04:02] <calc> StevenK: ok
[04:03] <Hobbsee> i thought it was a more local problem.  apaprently not.
[04:03] <calc> so maybe the initramfs did nothing then, just trying to reboot probably fixed it
[04:03] <crimsun> TheMuso: perhaps I'm hitting a different bug, but all of my crashes have been with "GNOME Login", which would be from libcanberra-login-sound.desktop's canberra-gtk-play invocation
[04:03] <TheMuso> crimsun: crash as in segfault?
[04:04] <crimsun> TheMuso: apparently, and it seems to be caused by the same race
[04:04] <TheMuso> crimsun: Right, I am not sure how to solve that, there is a bug filed about it. Let me dig it up.
[04:04] <TheMuso> crimsun: 275233
[04:05] <calc> how do you see the me-too status of a bug?
[04:06] <calc> or is it just a feel good button? :)
[04:06] <Hobbsee> calc: you can't.
[04:06] <Hobbsee> calc: eventually, they say they'll do something with it - but not actually let you see the raw numbers.
[04:06] <calc> hmm ok, so its turned on but of no use at all
[04:07] <calc> lol
[04:08] <Hobbsee> it has the aim of making people not write "me too" and such in bug reports.
[04:09] <calc> Hobbsee: and instead since no one can see the stats a developer has no idea how widespread the bug is
[04:09] <calc> especially if users actually start using this placebo button ;-)
[04:10] <slangasek> kirkland: I have no idea whether pam_ecryptfs should be dropped from common-session; it would have no effect on this bug, and I don't think it's a great idea to make changes there at this point if we don't have a specific bug in mind
[04:10] <slangasek> kirkland: oh, you said that earlier, sorry :) - I don't know if it should be dropped from common-session, then
[04:11] <calc> Hobbsee: the main usefulness of such a button would be to get the info out of the comment log, it is still very useful to know their launchpad id's and the overall number (raw number whatever)
[04:11] <Hobbsee> calc: you'd have thought so, but...
[04:11] <Hobbsee> calc: i just heard this.  I don't have much to do in LP development.
[04:12] <calc> doing it the way it currently is useful to no one really at all
[04:12] <calc> less comments in a bug without any way to see its due to this button is actually worse than before
[04:15] <Hobbsee> calc: you could try to get that POV across to #lp, in a few hours, if you wanted.  No guesses on your chance of success, though
[04:17] <TheMuso> crimsun: do you get that crash even with the pulse Xsession.d fix?
[04:17] <calc> Hobbsee: probably would be easier to just do it at UDS
[04:18] <calc> its only about 6 weeks from now
[04:19] <kirkland> slangasek: okay, i need to think more about this later
[04:23] <ScottK> calc: This button got discussed at the last UDS.  They seem to have proceeded anyway.
[04:24] <ScottK> calc: Currently it's pre-production.  If you wait until UDS it'll be "Everyone is used to it now, we can't change it".
[04:25] <slangasek> kirkland: ok, I don't seem to be able to reproduce the earlier bug with other optional modules besides ecryptfs, testing now with ecryptfs
[04:25] <calc> ScottK: a button that does nothing or a button that can collect data?
[04:25] <calc> ScottK: i don't recall them planning on a useless button at the last UDS
[04:26] <beuno> calc, ScottK, it should soon start showing up in listings as an icon, for the most user-affected bugs. I don't know what the exact status of that branch is. I also know there are plans to figure out what the best way to provide that information for bug triagers is, probably through the API.
[04:26] <kirkland> slangasek: it also works with current = (correct), new1 = foo, new2 = bar
[04:26] <beuno> please, file bugs with what would make it more useful for you guys  :)
[04:26] <slangasek> kirkland: "works", or "triggers the bug"?
[04:27] <ScottK> calc: Trying to have a 'me too' button instead of having people comment.  Next step in the master plan is to have Confirmed disappear as a status.
[04:27] <kirkland> slangasek: triggers the "password updated successfully" report
[04:27] <Hobbsee> beuno: will the bugs be looked at promptly?
[04:27] <Hobbsee> beuno: or will they wait 6+ months?
[04:28] <beuno> Hobbsee, don't be mean!  they will be looked at soon, and something will be done to make the feature more useful for you guys, which is why it was done in the first place
[04:28] <beuno> the implementation is just being made in smaller steps
[04:28] <calc> beuno: ok, it would be very useful to have some way to get at the names/total number from the page as well
[04:28] <Hobbsee> beuno: right.  And i'm not being mean, i'm more just used to reality.  I'm pleased to see the bug I filed in sevilla (april 07, iirc) about an implemented feature has finally been triaged.
[04:29] <calc> ScottK: then just get rid of bug reporting entirely :)
[04:29] <ScottK> calc: That's the best way to get the count to zero.
[04:29] <calc> ScottK: heh
[04:29] <slangasek> kirkland: ok - it seems to be pam_ecryptfs specifically that returns PAM_SUCCESS in this case when no password token has been set
[04:29] <beuno> calc, right, there are some concerns that the feature may be used to blackmail developers into fixing certain bugs, so we want to be careful with it
[04:29] <slangasek> kirkland: why doesn't pam_ecryptfs return PAM_IGNORE?
[04:29] <ScottK> beuno: In most projects 'having something useful' is something you do before fielding it.
[04:30] <kirkland> slangasek: ignorance on our (ecryptfs-devel) part, probably
[04:30] <beuno> calc, so, we want to make it useful, but be careful not to shoot ourselves in the foot
[04:30] <kirkland> slangasek: i'll look at that tomorrow
[04:30] <beuno> ScottK, sure. I guess this isn't most projects
[04:30] <calc> beuno: blackmail?
[04:30] <ScottK> That's for sure.
[04:30] <calc> beuno: ah you mean vote stuffing, i guess?
[04:30]  * RAOF presumes "blackmail" means "gaming the system for fun and profit"
[04:31] <beuno> calc, yes. "1103 users voted for this, you should fix it!"
[04:31] <calc> heh
[04:32] <Hobbsee> beuno: now that sounds like brainstorm.
[04:32] <calc> i'm sure large numbers of users would vote for put OOo 3.0 in intrepid, but its not happening :)
[04:32] <beuno> right, so, I think the proposed solution is to show in the listings, with an icon, the top 5% or so
[04:32] <calc> beuno: could make the number only visible by bug squad or something if that is a concern
[04:32] <beuno> and maybe provide actual counts or something similar through the API
[04:33] <tedg> calc: Is there a PPA for OO.o 3?
[04:33] <beuno> but, please, take with a grain of salt, I'm not 100% sure where the discussion is
[04:33] <calc> tedg: yes ~openoffice-pkgs
[04:33] <ScottK> beuno: It sounds like a very elaborate attempt to hide information that's actually useful.
[04:33] <tedg> calc: Cool, thanks.
[04:33] <calc> tedg: will most likely go into backports around the beginning of Dec
[04:33] <tedg> calc: I'm working on making my system unstable before the jaunty archive opens ;)
[04:34] <beuno> ScottK, I'm with you in the elaborate part
[04:34] <beuno> there's a lot of things to consider
[04:34] <beuno> I'm sure we'll work out something
[04:34] <calc> tedg: heh :)
[04:35] <slangasek> kirkland: ok.  I think that's the reason for this behavior; I'm going to have a closer look at pam_ecryptfs code, and if that conclusion stands, I'll go ahead and upload these pam changes and we can look at ecryptfs tomorrow
[04:36] <beuno> calc, Hobbsee, so, if you guys can file bugs with your concerns, or even ideas, it would be great, and I promise to chase up answers for them if you don't get any soon
[04:36] <Hobbsee> beuno: ok, cool.
[04:36] <beuno> we have a big 2 week sprint coming up from next week on
[04:37] <beuno> so response times may vary a bit
[04:37] <ajmitch> beuno: another long flight for you? :)
[04:37] <beuno> but I'll keep an eye out for bugs on this, feel free to subscribe me
[04:37] <beuno> ajmitch, heh, yeah. But it's only 16hs this time!
[04:37] <calc> beuno: is it possible to make something only visible on a bug page by a certain group?
[04:38] <calc> beuno: so we could have the stat there but only by eg bug squad or something like that, then have it available via api for whoever wants it there as well
[04:39] <beuno> calc, I suspect that it would involve special-casing a team in LP, and would be very hard to convince anyone to do something like that. APIs are less user-visible, so it's less of a risk.
[04:39] <beuno> I'm not saying no
[04:39] <beuno> and, in no way do I decide any of this
[04:39] <beuno> so give it shot
[04:39] <calc> beuno: ok
[04:39] <ajmitch> there's already special-casing on changing bugs
[04:39] <ScottK> beuno: I already gave my feedback at UDS.  No reason to waste time on it now.
[04:40] <calc> beuno: oh another feature i want is the ability to delete packages from a bug
[04:40] <calc> :)
[04:40] <beuno> is it christmas already?  :p
[04:40] <Hobbsee> oh, now there's an idea...
[04:40] <calc> well i found a real bug that could be fixed by allowing that
[04:40] <Hobbsee> calc: you can already do that, though.  entirely obtuse, though
[04:40] <beuno> I know that's a common headache, not sure why it's still there
[04:41] <beuno> or if there's a bug open for it, which I suspect it is
[04:41] <calc> for eg openoffice.org any bug assigned to openoffice.org2 gets autoreassigned to openoffice.org but it fails if it already is assigned to openoffice.org as well via a separate package entry
[04:41] <calc> Hobbsee: how do you delete it?
[04:42] <Hobbsee> calc: edit it, take out the package field.  then it just gets assigned to ubuntu.
[04:42] <calc> Hobbsee: ugh that isn't a real solution
[04:43] <calc> Hobbsee: i'm sure bdmurray would like to remind you about that ;-)
[04:43] <Hobbsee> calc: it's a workaround :)
[04:43] <Hobbsee> calc: ah well.  Maybe he needs more agressive mail filtering :P
[04:43] <calc> in this particular case it caused a hardy task to get opened and i couldn't even mark it invalid becaue it would try to rename the package entry which won't work
[04:44] <Hobbsee> ah yes, there's no way back from nominate for release.
[04:45] <calc> i didn't even nominate it for openoffice.org2, i nominated it on the other package entry for openoffice.org
[04:46] <calc> and i wasn't trying to remove it, i can't even mark the bug as invalid under openoffice.org2 because it tries to rename it to openoffice.org and fails
[04:46] <calc> er i mean remove it from nomination
[04:46]  * calc can't recall the bug number atm but i mentioned the number earlier today
[04:46] <calc> bug 173090
[04:47] <calc> thats it
[04:47] <calc> and is the reason why i think we should be able to delete package entries, or at have the option via restricted access (bug squad?)
[04:48]  * beuno agrees
[04:48] <calc> i have quite a few bugs that are screwed up like that overall
[04:48] <calc> or at least used to
[04:48] <calc> actually in this case i can't even close the bug entirely, lol
[04:51]  * calc headed for bed, bbl
[05:22] <StevenK> Hmmm. What's the graphical tool that give you a device-manager-esque thing from HAL?
[05:22] <TheMuso> hal-device-manager?
[05:24] <wgrant> It's actually gnome-device-manager these days.
[05:25] <wgrant> And is apparently no longer installed by default.
[05:25]  * StevenK is trying to track down the wireless device in this device
[05:27] <wgrant> Can I please attack forum users if they suggest to alter /var/lib/dpkg/status and the local Packages files in order to resolve dependency issues?
[05:29] <TheMuso> wgrant: I'd say yes go ahead. :p
[05:30] <RAOF> Wow.  That's a disturbing concoction of cluelessness and knowledge.
[05:30] <wgrant> Exactly.
[05:30] <wgrant> If they know enough to be able to do that, they should know enough to realise that's its stupid and wrong.
[05:31] <StevenK> Hmph. Can't find the network device or the touchscreen in hal-device
[05:34] <TheMuso> StevenK: what about lshal?
[05:35] <ScottK> wgrant: Either that our they're Automatix devs and it's the way things are done.
[05:35] <StevenK> lshal for 'touch' gives nothing, and 'network' only the shows the USB Ethernet I plugged in
[05:37] <wgrant> ScottK: Indeed, that's a good theory.
[06:03] <r_rehashed> hi all. any idea when mono 2.0 will be released for hardy?
[06:03] <slangasek> kirkland: ok, pinned down the ecryptfs issue; yeah, it's an ecryptfs bug
[06:04] <Burgundavia> r_rehashed: it might be backported, but that is a huge amount of work, given all the mono apps that would require rebuilding and testing
[06:06] <r_rehashed> since hardy is an LTS release i thought it will be backported. but i hope ibex uses 2.0 instead of 1.9
[06:07] <wgrant> LTS also means "don't break everybody's systems"
[06:07] <wgrant> And backporting mono is a sure way to do that.
[06:12] <RAOF> r_rehashed: Intrepid won't have 2.0
[06:12] <r_rehashed> :-/
[06:12] <RAOF> On the basis that there aren't actually any packages available yet, despite the work of the Debian mono team.
[06:13] <r_rehashed> i see
[06:13] <RAOF> And also the horrible risk of regressions in the tiny, tiny time available to test.
[06:13] <r_rehashed> yes, i understand
[06:58] <dholbach> good morning
[06:58] <Burgundavia> morning dholbach
[06:58] <MacSlow> dholbach, hi here too
[06:58] <MacSlow> hey Burgundavia
[06:58] <dholbach> hiya Burgundavia
[06:58] <MacSlow> any yaird expert here?
[06:59] <Burgundavia> MacSlow: how goes the banging at GDM?
[07:00] <MacSlow> I get the error "bad device link in /sys/block/sda (fatal)" when trying to execute "yaird --output=initrd.img-2.6.27-rc9 2.6.27-rc9"
[07:00] <MacSlow> Burgundavia, coming along
[07:02] <MacSlow> There are three symlinks in /sys/block/sda all of which seem to be find (I can "cd" to them)
[07:02] <kagou> good morning
[07:04] <MacSlow> Is there any other way/tool to create a initrd.img under intrepid? The old mkinitrd seems to be gone.
[07:05] <StevenK> MacSlow: mkinitrd is long dead. "update-initramfs -u"
[07:05] <MacSlow> StevenK, that'll work with a self-compiled kernel?
[07:06] <StevenK> MacSlow: update-initramfs -u -k <version>
[07:06]  * MacSlow assumes that uses some assumptions regarding special ubuntu package actions done before it
[07:07] <MacSlow> StevenK, does that do anything besides creating /boot/initrd.img-version.bla ?
[07:07] <MacSlow> StevenK, it's not touching any of /boot/grub/menu.lst or the like?
[07:07] <StevenK> MacSlow: None, just creates the initramfs
[07:08] <MacSlow> StevenK, ok ... seems to work sofar
[07:42] <dholbach> Riddell: do you have the source of example-content/kubuntu-leaflet.png somewhere? It still mentions powerpc
[08:01] <slangasek> pitti, doko: could you take a look at the cssutils MIR, please?  elisa is currently uninstallable in main without it
[08:01] <doko> looking ...
[08:06] <sbeattie> slangasek: system-cleaner passed its MIR, but python-fstab needs to go along with it.
[08:06] <slangasek> sbeattie: is there a separate MIR for python-fstab?
[08:07] <sbeattie> slangasek: no, liw included it in his system cleaner MIR: https://wiki.ubuntu.com/MainInclusionSystemCleaner
[08:08] <sbeattie> bug 279554 is the tracking bug
[08:09] <slangasek> hmm, the MIR team expanded when I wasn't looking :)
[08:11] <sbeattie> heh
[08:11] <pitti> slangasek: cssutils mir> will do
[08:11] <slangasek> vorian: kdiamond-kde4 is uninstallable because it depends on a package that conflicts with it; please drop the kdiamond Conflicts: on kdiamond-kde4 and make the Replaces: versioned
[08:11] <slangasek> pitti: doko is already looking
[08:12] <slangasek> python-fstab promoted
[08:13] <pitti> Good morning
[08:13] <Hobbsee> slangasek: alreadyknown,#kubuntu-develwasdiscussing itearlier.
[08:14] <slangasek> Hobbsee: great, will be fixed soon?
[08:14] <Hobbsee> ithink so
[08:14] <slangasek> \o/
[08:15] <sbeattie> Hobbsee: ScottK got tired before he could take care of it, not sure anyone else picked it up.
[08:15] <Hobbsee> sbeattie: yeah,isaw.  don'tthink anyone has so far.
[08:16] <doko> slangasek: done
[08:16] <slangasek> doko: thanks
[08:17]  * Hobbsee sighs.  to all:  apologies: it looks like part of my spacebar has kicked the bucket.
[08:30] <tkamppeter> pitti, hi
[08:31] <pitti> tkamppeter: good morning; just saw your mails, many thanks!
[08:31] <tkamppeter> pitti, now it is all perfect with the PPD package on OpenPrinting.
[08:32] <tkamppeter> pitti, I have already successfully installed the package with s-c-p, by doing a small modification on s-c-p that it even does the look-up when there is a local driver (this mosification I only do for debugging, not for upload).
[08:33] <mdke> pitti: thanks for the ubuntu-docs upload yesterday
[08:34] <pitti> tkamppeter: nice, my test suite succeeds now \o/
[08:34] <mdke> pitti: any idea when it will be available in hardy-proposed for testing?
[08:35] <pitti> mdke: let me just process it right now
[08:36] <mdke> pitti: yay!
[08:37] <pitti> mdke: bug 153124 and bug 220889 are still open in intrepid; can you please check if they are fixed?
[08:38] <pitti> mdke: I added hardy tasks to all bugs now (please do that next time, too)
[08:39] <tkamppeter> pitti, I have done the first test with UNMODIFIED s-c-p and an actual printer, but I had to remove a lot of packages to pretend that the HP LaserJet P3005 is not supported locally:
[08:40] <pitti> tkamppeter: heh; Ubuntu printer support is *too* good :-P
[08:40] <tkamppeter> sudo dpkg -P --force-depends openprinting-ppds-postscript-hp openprinting-ppds hpijs foomatic-db cups-driver-gutenprint
[08:42] <mdke> pitti: bug 153124, to the extent that it is valid at all, is probably not fixed in either hardy or intrepid; bug 220889 should be fixed in both
[08:42] <mdke> pitti: so should we be adding distro tasks to all of our bugs now?
[08:42] <pitti> mdke: already done for those 5
[08:43] <mdke> i mean, as a matter of common practice?
[08:43] <pitti> mdke: but general rule is that a bug needs to be fixed in intrepid (well, the current dev release) until it is fixed in stables
[08:43] <pitti> mdke: right
[08:43] <mdke> yes, we generally treat a bug as fixed if it is fixed in intrepid
[08:44] <mdke> it's only in the case of important bugs that we would consider fixing it in hardy
[08:44] <mdke> but generally, most of our bugs (there are about 40 open) don't have specific distro tasks on them
[08:45] <stefanlsd> Does anyone know how i get the download link for flash player?
[08:47] <pitti> mdke: that's fine; I mean "the bug needs a hardy task if it gets an SRU for hardy"
[08:47] <pitti> mdke: it doesn't mean that all bugs that you fix need intrepid tasks, or so
[08:48] <mdke> pitti: got it, ok thanks
[08:48] <pitti> mdke: please close the intrepid tasks in those two then; thanks
[08:49] <pitti> mdke: btw, I recently filed bug 281143 with "almost" a patch (proposed text really); should I create a branch with it, or supply a diff, or how is that generally handled?
[08:51] <doko> slangasek: I would like to get python-reportlab (2.2) into intrepid. the only use in main is the fax cover sheet generation in hplip, which tkamppeter did test with the new python-reportlab
[08:51] <doko> any chance?
[08:52] <slangasek> doko: what does an updated python-reportlab give us?
[08:53] <slangasek> (bugfixes and or risks of regression^W^W^W features ;)
[08:53] <doko> slangasek: for me, maintainance in one package (reportlab-accel and renderpm are built out of one source)
[08:54] <slangasek> doko: but these don't seem like packages that should need SRUs for intrepid...?
[08:54] <doko> well, I'll start writing a FF exception
[08:54] <slangasek> ok
[08:57] <lool> pitti: Can you promote python-fstab as well?  it's a dep of systme-cleaner
[08:57] <lool> It was discussed shortly in the MIR IIRC
[08:58] <tkamppeter> pitti, what about bug #271286, can you fix it in the Intrepid package?
[08:58] <pitti> lool: did you review it?
[08:59] <lool> Yeah
[08:59] <pitti> tkamppeter: yes, I have that prepared, I'll upload it today
[08:59] <lool> as part of reviewing system-cleaner
[08:59] <pitti> promoted
[08:59] <lool> "From security and maintenance povs, python-fstab and system-cleaner seem ok for inclusion in main,[...]" when I did the initial review of both
[09:00] <lool> I only required i18n for main promotion of system-cleaner (as it's in the menus when installed) and liw also fixed the 3 other bugs which I raised :)
[09:00] <mdke> pitti: yeah I saw the bug; if you'd like to send a bundle or diff, that would be fine, otherwise one of the team will get to it after intrepid is released. It wasn't early enough for us to include it in intrepid, I'm afraid
[09:01] <pitti> mdke: ok, I'll see what I can do
[09:01] <mdke> pitti: thanks!
[09:03] <davmor2> mvo: ping
[09:04] <mvo> hi davmor2
[09:05] <davmor2> mvo: alt cd upgrade has some issues
[09:07] <mvo> davmor2: oh, what is wrong with it?
[09:08] <lool> Hmm is there a way we can ask an arch: all package to be built on another arch than i386?
[09:08] <slangasek> pitti, lool: python-fstab was already promoted :)
[09:08] <slangasek> lool: nope
[09:08] <lool> openhackware is ppc specific assembly, and produces an arch: all binary for use as a BIOS in qemu
[09:09] <tkamppeter> pitti, if you get any ugly display when fixing bug 271286, note that the short discription can contain simple HTML formatting. This can be rendered correctly with the markup functionality of GTK. License texts are foreseen to be plain text though.
[09:09] <lool> Perhaps I should request a way to do this as a wishlist against soyuz?
[09:09] <davmor2> mvo: I don't think it's major but I get an error window pop-up that reads "subprocess post-install script returned error exit staus 1" on package rarian-compat
[09:09] <lool> We do have ppc, would be kind of sad to not have ppc qemu support here
[09:10] <davmor2> mvo: also there is a polite pop-up informing me that my evo-alarm-notify might not work
[09:10] <davmor2> mvo: other than that seems fine
[09:10] <mvo> davmor2: riight, the rariant is a known issue, pitti has a fix
[09:11] <mvo> davmor2: I have seen the evo thing too before - if its otherwise ok, I'm quite happy, then we are on a good way :)
[09:11] <davmor2> mvo: I selected not to get update from the internet too so we knew it was all from the cd
[09:11] <pitti> mdke: so can those two be closed?
[09:11] <mvo> davmor2: thanks for that, that was what I wanted to have tested :)
[09:12] <davmor2> mvo: about a minute left
[09:12] <pitti> tkamppeter: I hope HTML works in treeviews too, I'll check
[09:13] <lool> eh already reported as 217427
[09:15] <davmor2> mvo: lastly it's thrown up a complaint that n-m could find all it's resources
[09:16] <lool> Oh yeah, got that too
[09:16] <davmor2> s/could/couldn't
[09:16] <mvo> davmor2: thanks, I think asac was working on the "n-m could find all it's resources" bug (he said he has a fix ready
[09:16] <lool> davmor2: I think it's because it needs new icons and they weren't gtk-update-icon-cached
[09:16] <davmor2> okay well rebooting now
[09:17] <tkamppeter> pitti, if needed replace the treeview by something else, I think it is more important to have the "This driver is a development version" in bold than having a treeview.
[09:20] <pitti> tkamppeter: well, it's the only GTK widget which provides lists or trees :)
[09:21] <pitti> tkamppeter: anyway, I'll figure it out
[09:21] <davmor2> mvo: something isn't right but I need to go now.  I rebooted now I get no bars even in failsafe mode I think it maybe an nvidia thing but can debug when I get back
[09:21] <mvo> davmor2: thanks, see you
[09:29] <ogra> bryce, i cant imagine that fix in bug 222164 works without restarting X
[09:29] <asac> mvo: isnt that fixed?
[09:29] <asac> err. i mean i think i uploaded the fix yesterday ;)
[09:29] <asac> let me check
[09:30] <mvo> asac: might be that it was just not on the CD that davmor2 tested yet
[09:30] <mvo> thanks a lot for the fix asac!
[09:30] <asac> mvo:  0.7~~svn20081015t194645-0ubuntu1
[09:30] <asac> Published in intrepid-release 9 hours ago
[09:31] <asac> fix LP: #277084 - ...
[09:31] <asac> ;)
[09:31] <mvo> excellent
[09:31]  * mvo hugs asac
[09:33] <asac> mvo: well ... dont hug before its confirmed ;)
[09:34]  * mvo unhugs asac
[09:41]  * asac hugs mvo 
[09:41] <ogra> lol
[09:43] <slangasek> StevenK: you appear to have uploaded libruby-extras recently, probably as part of NBS processing, but libruby1.8-extras still depends on libgems-ruby1.8; oversight?
[09:56] <Nafallo> Keybuk: hey. you're aware pam-thinkfinger requires enter presses after the swipping in intrepid and that it is a regression from hardy, right? :-)
[10:07] <Koon> mvo: apparently the sledgehammer patch for bug 278112 introduces at least as many regressions as it fixes things... so I'll let a compiz expert properly solve this one :)
[10:09] <mvo> Koon: hmm, thanks. I had hoped it would be a usable fallback if no better solution can be found.
[10:10] <mvo> Koon: thanks for your work on this!
[10:10] <Koon> I seem to have a variation from the common case, black screen instead of the unlock password box
[10:10] <Koon> mvo: I need to debug that first before I can be of any help in testing fixes
[10:13] <slangasek> ogra: hmm, so linux-lpia is FTBFS?  This holds up NBSing of linux-headers-2.6.27-3 currently
[10:14] <ogra> slangasek, amitk is on it
[10:15]  * directhex hands slangasek cake, begins on work for mono 2.0 in jaunty
[10:16] <slangasek> wheee
[10:16] <slangasek> ogra: ok, great
[10:17] <slangasek> directhex: cake at 2am is not a good plan, I'll just put that in the fridge for the morning :)
[10:19]  * ogra gets his coat
[10:19] <ogra> gotten cold in here
[10:24] <tkamppeter_> pitti, as license texts are given as plain text, can you display them with a fixed-width font and in a window which is wide enough for 80 characters of the fixed width font? Thanks.
[10:26] <tkamppeter> pitti, and in the main description display, can you let the items about supplier and support come at first and the functionality as the last? This makes the case that the driver comes from the manufacturer more visible.
[10:27] <pitti> tkamppeter: I shouldn't change the UI much any more; we just froze...
[10:27] <pitti> (I hoped we'd freeze on Steve's Thursday...)
[10:28] <pitti> tkamppeter: but I can change it in trunk, so that it'll be fixed in the future; maybe you ca report bugs about that?
[10:28] <slangasek> pitti: it's been Thursday here for 2 hours
[10:28] <pitti> tkamppeter: fixed font? for multi-paragraph text?  that looks pretty ugly?
[10:28] <slangasek> FYI :)
[10:28] <StevenK> Haha
[10:29] <pitti> slangasek: yeah yeah, I'm just looking for more time to fix bugs :)
[10:29] <slangasek> pitti: /you/ can have more time to fix bugs, that's fine :)
[10:29] <StevenK> slangasek: Just him?
[10:29] <slangasek> just him
[10:29] <StevenK> Haha
[10:30]  * ogra reassigns all his bugs to pitti
[10:31] <pitti> slangasek: oh, btw, in the next days I planned to do some component-mismatches fixes; can I have a blanket approval to shove through things which just fixes depends/recommends and the like?
[10:31] <slangasek> pitti: yes
[10:31] <pitti> slangasek: since these packages are generally not ones I particularly care about, I don't think that there is a conflict of interest
[10:31] <pitti> ok
[10:32] <Laney> crimsun: Just the one audio device
[10:33] <tkamppeter> pitti, if you display such a license with "less" in a terminal, it shows nicely, and it should show the same way in Jockey.
[10:34] <tkamppeter> pitti, all lines in the paragraph end with newlines and at the end of the paragraphs there are two newlines (=1 empty line).
[10:34] <tkamppeter> pitti, this should show perfectly with a fixed-width font like Courier.
[10:35] <ogra> kwwii, !!!!! where is my wallpaper ?
[10:35]  * ogra shrieks
[10:35] <StevenK> ogra: I think your theme no longer exists
[10:36] <tkamppeter> pitti, and this UI change does not break any freeze criteria, as it does not change the logic (for the documentation) nor the text content (for the translations).
[10:36] <ogra> StevenK, apparently, ubuntu-mobile is without wallpaper now :/
[10:37] <ogra> slangasek, seems i need a freeze exception for ubuntu-mobile-default-settings and add the wallapaer back :/
[10:37] <kwwii> ogra: ???
[10:37] <ogra> kwwii, mobile used the elephant skin as default wallapaer
[10:37] <StevenK> ogra: That's a guess, though
[10:37] <ogra> kwwii, its gone it seems
[10:38] <ogra> with my last update here
[10:38] <kwwii> ogra: it is sitll there, just as a jpg now
[10:38] <kwwii> and under a different name
[10:39] <kwwii> simple-ubuntu.jpg
[10:39] <ogra> ah, k, then i only need to change the gconf key
[10:39] <kwwii> :-)
[10:40] <slangasek> ogra: ubuntu-mobile-default-settings seems to be in universe, so you don't need a freeze exception from me in any case
[10:41] <ogra> slangasek, heh, yeah, sorry forgot about that .... i'm not used to ll that freedom yet :)
[10:42] <ogra> hrm, the fusa message doesnt really make sense if you dont have any logout item on your panel
[10:42] <slangasek> oh, I don't know about freedom, I'm just saying you don't need a freeze exception from /me/ ;)  the motu-release team's freeze guidelines, TTBOMK, are at https://lists.ubuntu.com/archives/ubuntu-devel/2008-April/025259.html
[10:42] <slangasek> but they may want to do some delegation for mobile as well
[10:42] <ogra> slangasek, i'm the release manager for mobile :)
[10:42] <sistpoty|work> ogra: you'd need one from yourself :P
[10:43] <directhex> bribe yourself with cake.
[10:43] <ogra> sistpoty|work, yeah, already mailing me :P
[10:43] <sistpoty|work> heh
[10:44] <ogra> hmm, all my menu items i had manually enabled on my desktop are hidden again ?
[10:44] <ogra> do we muck about with user settings now ?
[10:45] <seb128> no
[10:45] <seb128> and GNOME packages didn't change recently
[10:45] <ogra> weird
[10:45] <sistpoty|work> slangasek: FYI current delegates are listed in https://lists.ubuntu.com/archives/ubuntu-devel/2008-September/026306.html
[10:45] <seb128> indeed
[10:45] <ogra> i definately enabled gconf-editor on that device
[10:46] <ogra> but had to re-renable it now
[10:46] <slangasek> sistpoty|work: ok; perhaps I should've referenced that page in the freeze announcement, ohwell :/
[10:46] <slangasek> sistpoty|work: but I assume most of the affected people already know who they need to go to :)
[10:46] <ogra> seb128, could it be that fusa runs something to restore defaults in its postinst ?
[10:46] <sistpoty|work> slangasek: yes, I assume so as well
[10:46] <ogra> because i also had the fusa logout change message
[10:47] <ogra> (without having a logout item in the panel on mobile)
[10:48] <seb128> ogra: no
[10:48] <seb128> ogra: and menus items are in .local not in gconf anyway
[10:49] <ogra> seb128, i used gconf-editor before the reboot from the menu ....
[10:49] <seb128> ogra: do you have a gconf-editor item in .local?
[10:49] <StevenK> ogra: Oh, what is happening with libflashsupport?
[10:49] <seb128> .local/share/applications
[10:49] <ogra> after reboot i had the fusa message, when i went to the menu then the editor was gone
[10:50] <ogra> seb128, well, i enabled it again, so indeed there is a .desktop file now
[10:50] <seb128> ogra: way to go for debugging ...
[10:50] <ogra> seb128, but i'm pretty sure i had more items customized, gconf-editor is the only thing in that dir now
[10:51] <seb128> ogra: you should try to figure what was wrong before workarounding the bug
[10:51] <seb128> ogra: ok, so something cleaned your .local
[10:51] <ogra> seems like
[10:51] <seb128> ogra: the layout migration does only very selective gconf changes so that's doubtfully it
[10:52] <ogra> and i assume update-gconf-defaults is safe and doesnt do such stuff either
[10:52] <seb128> ogra: it touchs only system gconf locations
[10:52] <seb128> there is no packaging tools changing .local in any way
[10:53] <mvo> ogra: if you just saw the message and did not click on "update" then nothing happend to your gconf, its just a message. if you did click, then not a lot happend either :)
[10:53] <ogra> yeah
[10:53] <cjwatson> liw: ooh, system-cleaner promoted. Now where are we seeding it?
[10:53] <ogra> mvo, i sadly didnt click, i should have to see what happens on mobile
[10:53] <ogra> since we dont have any logout item on the panel
[10:53] <mvo> ogra: it would have told you "no logout button found, please update manually"
[10:54] <ogra> ah, good
[10:54] <mvo> ogra: no worries, defensive code
[10:54] <ogra> wouldnt affect new installs anyway, but i was slightly worried about the handfull of testers getting their panel setup trashed :)
[10:55] <mvo> ogra: the migrate-fusa-config.py would not do that, run the trash-panel-setup.py instead
[10:55] <ogra> though that gconf thing is pretty weird ... and i dont really see a way to reproduce it
[10:55] <ogra> haha
[10:55] <mvo> ogra: seriously, we had oddness with gconf defualts in the past
[10:55] <ogra> right, i remember that
[10:55] <mvo> but we never managed to reproduce it or get any clue why some defaults would not update
[10:55] <ogra> though i wouldnt know why anything would touch .local
[10:56] <seb128> in this case that's not a gconf issue
[10:56] <seb128> but local datas which vanished
[10:56] <mvo> stuff in ~ should really be safe
[10:56] <seb128> are you sure you didn't clean those?
[10:56] <ogra> seb128, well, as i said, i looked at the gconf key for the wallapaper using gconf-editor from the menu
[10:57] <seb128> I don't deny that
[10:57] <ogra> then i rebooted and my menu missed the systemtools category
[10:57] <seb128> but there is nothing touching .local
[10:57] <seb128> so it's weird that it got changed
[10:57] <seb128> did you get a fsck running?
[10:57] <ogra> the only thing i did before looking at the menu was confirming the fusa question
[10:57] <ogra> nope
[10:58] <seb128> either that's a local issue
[10:58] <ogra> i'll watch for it on other upgrades
[10:59] <seb128> or ted added some code to clean your menus because you were complaining about fusa yesterday ;-)
[10:59] <ogra> gconf-editor is enabled on all my systems usually, i will notice if it goes away
[10:59] <dholbach> argh, my machine just froze
[10:59] <ogra> seb128, ah, indeed, that would be it
[10:59] <dholbach> no, magic sysrq, nothing
[10:59] <mvo> dholbach: which one?
[10:59] <dholbach> amd64, intrepid
[11:00] <mvo> video card?
[11:00] <dholbach> nv
[11:00] <mvo> hmmm
[11:00] <ogra> call the vendor
[11:00]  * dholbach slaps ogra
[11:00] <ogra> :)
[11:00] <mvo> I had a freeze yesterday with compiz/r500/ati :/
[11:01] <dholbach> . o O { free software shit }
[11:01]  * dholbach takes a look at the logs
[11:02]  * ogra logs out of dholbach's machine again
[11:02] <mvo> dholbach: CoC!
[11:02]  * mvo hugs dholbach
[11:02] <kwwii> seb128, mvo, pitti: did you get and email from me about the gnome-themes stuff? (Not to mention the FUSA situation)
[11:02] <persia> Hrm?  That's not a CoC issue.  It's only.
[11:02] <persia> !ohmy
[11:02] <kwwii> mvo: it is these aggresive community people
[11:02]  * mvo sticks his head in the sand
[11:02] <dholbach> -- MARK --
[11:02] <dholbach> nice
[11:03] <StevenK> dholbach: -- MARK -- is useful
[11:03] <ogra> oh, he ws logged in as well ?
[11:03] <mvo> aha! I suspected it might be HIM
[11:03] <lool> mvo: Oh you're running ati compiz now?  I'm really happy we have free 3D on r500 now
[11:03] <persia> dholbach, Well, when it freezes, it's frozen.  You probably want a serial console to chase it.
[11:03] <lool> mvo: I couldn't suspend / resume with it though
[11:03] <mvo> lool: yes, it just tends to freeze
[11:03] <mvo> lool: but I suspect that is a thermal problem of the laptop its pretty bad with it
[11:03] <dholbach> I just thought I'd might find something somewhere
[11:04] <mvo> lool: hm, I think that worked, but I'm not 100% positive
[11:04] <lool> I didn't get freezes when using xorg with ati yet; I had various issues with intrepid in general, or when doign specific things, but not just using compiz
[11:09] <ogra> Keybuk, i'm waiting to be able to test fusa before i close the ldm task on the bug
[11:09] <ogra> for some reason it wasnt available yet for my vbox ltsp install
[11:09] <ogra> hmm, it still isnt
[11:17] <pitti> kwwii: answered
[11:18] <kwwii> pitti: and I already sent a reply :-) Thanks!
[11:19] <ogra> can some archive admin let my ubuntu-mobile-default-settings through ?
[11:34] <liw> cjwatson, re seeding of system-clenaer: I would suggest system-cleaner in the standard seed, and system-cleaner-gtk in the desktop seed; does that sound reasonable?
[11:34] <pitti> ogra: done
[11:34] <ogra> mvo, hmm, my ltsp testserver in vbox still has xscreensaver installed and i didnt get any dist upgrade option, isnt that supposed to go away on one of the upgrades ?
[11:34] <pitti> liw: -gtk in deskto, and system-cleaner in server perhaps?
[11:34] <ogra> pitti, merci
[11:35] <mvo> ogra: yes - what version of ubuntu does it run?
[11:35] <ogra> intrepid
[11:35] <mvo> ogra: and it was upgraded from what version?
[11:35] <ogra> xss was installed at some point from recommends
[11:35] <ogra> it was intrepid all the time
[11:37] <cjwatson> liw: either that or pitti's suggestion is fine by me
[11:42] <liw> cjwatson, pitti: server instead of standard is very much ok with me
[11:50] <emgent> heya
[11:51] <Riddell> anyone know about libcap?
[11:53] <ScottK> slangasek: motu-release has concluded that it does not want to start approving every Universe/Multiverse upload until after the RC is released (i.e. a week from now).  For now it should be the same as the Beta freeze.
[11:54] <Riddell> ScottK: what was beta freeze?
[11:55] <mvo> Riddell: a bit, what the issue?
[11:55] <ScottK> Riddell: Unless it needs and FFe, ubuntu-release just shoves Universe/Multiverse stuff through.
[11:55] <ScottK> and/an
[11:55] <Riddell> mvo: bug 248577 has been assigned to me, but I really don't know what it's about
[11:56] <Riddell> mvo: or whether it's something we should care about now we're frozen
[12:04] <mvo> Riddell: uhh, I can have a look after lunch
[12:28] <liw> cjwatson, ok, I've figured out how to add things to seeds, I think, but I can't bzr push since I am not core-dev; should I give you a patch/bundle or something?
[13:00] <liw> stdin, ping
[13:05] <cjwatson> liw: either push to lp:~liw/ubuntu-seeds/some-name and mention the branch name for merging, or send an ordinary patch
[13:07] <liw> cjwatson, ack, sent
[13:11] <liw> stdin, I got the fridge bot's date parsing code to run, at least (it crashed on my laptop on an unknown WKST keyword arg, fixed that)
[13:13] <persia> liw, So it understands recurrance now (or could if your changes were merged)?
[13:13] <liw> persia, I don't know yet, but at least it doesn't crash
[13:13] <persia> That's a start :)
[13:20] <liw> persia, would you happen to know what the exact problem is?
[13:21] <persia> liw, Precisely, when there is a recurring scheduled meeting, the bot only sees the first occurrence, and doesn't report repeats.
[13:21] <persia> As a result, the #ubuntu-meeting schedule is a bit funny.
[13:21] <persia> There's a human trying to copy stuff, but that's suboptimal.
[13:26] <jdstrand> mdz_: hi! so I have been watching bug #263059 with interest because I see these hangs too, but I have an ipw2200 in my t42 laptop. as the bug is so iwl3945-centric, I didn't want to cloud the issue.
[13:26] <jdstrand> mdz_: should I add my dmesg, photo and lspci to that bug or another?
[13:31]  * directhex awaits jaunty for his new laptop, intrepid is too ooooold
[13:32] <mdz> jdstrand: please open a separate bug, we can always dupe it if appropriate
[13:33] <mdz> jdstrand: please try DebuggingSystemCrash, it may not be the same bug
[13:33] <jdstrand> mdz: ok, I'll add a 'could be related to...' note to it. thanks
[13:33] <dholbach> why was example-content 34 rejected?
[13:33] <mdz> jdstrand: and report it with "ubuntu-bug linux"
[13:33] <Riddell> dholbach: I got the kubuntu-flyer source from kwwii so I'll reject your example-content upload and add the source and reupload based on that version 34
[13:34] <dholbach> Riddell: ok
[13:41] <dholbach> Riddell: let me know when you've accepted it, so I can add the changes to bzr
[13:42] <Riddell> dholbach: there's a bzr?  I looked but didn't see one
[13:42] <Riddell> oh, debian/control knows it
[13:42] <dholbach> no, that needs changing too
[13:42] <dholbach> lp:example-content
[13:43] <dholbach> it's ubuntu-core-dev now, not ubuntu-art-pkg
[13:43] <liw> stdin, I can't seem to figure out the real problem in an hour, but http://paste.ubuntu.com/58326/ should be a necessary fix anyway
[13:43] <dholbach> the core-dev branch was marked as 'merged' instead of 'mature' - that's why it probably didn't show up
[13:43] <dholbach> I just changed that
[13:43] <Riddell> dholbach: accepted, I can put it in bzr if that's easier
[13:44] <dholbach> as you like it, I can do it too
[13:47] <dholbach> Riddell: but right now it does not get installed - what's your plan?
[13:48] <dholbach> ah, you updated the kubuntu-leaflet.jpg too - nevermind
[13:48] <dholbach> Riddell: pushing to branch - thanks
[13:49] <Riddell> dholbach: I've already committed, I win!
[13:49] <siretart> asac: I've added your last vlc upload to our bzr branch.
[13:49] <Riddell> dholbach: I don't want the .svg installed, it's just the source
[13:49] <dholbach> alright :)
[13:51] <asac> siretart: sorry
[13:51] <asac> siretart: didnt notice apparently
[13:51] <siretart> no problem
[13:51] <asac> siretart: do you have a EAP setup somewhere?
[13:52] <siretart> asac: but perhaps you can explain me what's the deal with these UUIDs in debian/control
[13:52] <siretart> asac: do we want them in debian as well?
[13:52] <asac> siretart: its for the plugin finder service. the uuids indicate which application this plugin works on
[13:53] <siretart> asac: what is the 'plugin finder service'? isn't that in debian as well?
[13:53] <asac> siretart: the new fields are required for advanced features
[13:53] <asac> siretart: http://people.ubuntu.com/~asac/tmp/pfs1.png
[13:54] <asac> siretart: http://people.ubuntu.com/~asac/tmp/alt1.png
[13:54] <siretart> my university is doing TTLS with PAP as inner authentication. so no EAP
[13:54] <siretart> asac: so that's only for firefox? no epiphany, konqueror etc love at all?
[13:55] <siretart> asac: and do you plan to port that plugin finder to iceweasel as well?
[13:55] <asac> siretart: it doesnt need to be ported. it just needs to be uploaded and the database needs to also provide info for etch/lenny/sid etc.
[13:56] <asac> siretart: i suggested that to debian mozilla maintainers at some point and they didnt really cheer for it.
[13:56] <asac> siretart: but we can retry ;)
[13:56] <asac> or just do
[13:56] <siretart> asac: do you have a bug number were I can read their response?
[13:57] <asac> siretart: someone would need to write a wizard for epiphany and konqueror
[13:57] <siretart> asac: I'm wondering if it is worth to push these changes to debian as well. that's why I'm asking
[13:57] <asac> siretart: hmm. i am not sure where that happened. i can look that up asap
[13:57] <asac> siretart: imo its worth it.
[13:58] <asac> siretart: for instance: gnuzilla tries to provide a plugin finder service with just free plugins
[13:58] <siretart> asac: I'd think a bug in debbugs would be useful in any case. that way we can at least point people if they are wondering what these ids are about
[13:58] <asac> but that doesnt work because there  are no binaries available on the net
[13:58] <asac> but debian can do that by just including main plugins
[13:58] <siretart> asac: what package in ubuntu implements that 'plugin finder'?
[13:58] <asac> ubufox
[13:58] <siretart> aah, so that's what this ubufox is about
[13:59] <asac> mostly yes.
[14:00] <siretart> ok. thanks for clarification
[14:02] <ogra> pitti, can you approve linux-lpia ?
[14:09] <torkel> asac: is TLS with client certificates supposed to be working in n-m (intrepid)?
[14:10] <asac> torkel: well. i guess it doesnt work for you?
[14:10] <asac> of course its supposed to work ;)
[14:10] <asac> torkel: do you see anything in syslog?
[14:10] <torkel> asac: thought so. So it must be DBTK :-)
[14:11] <asac> torkel: i think there might be a bug as we also have issues with WPA-EAP
[14:11] <asac> torkel: whats the exact problem?
[14:12] <torkel> asac: it seems it succeeds with authentication, but fails with association (association with AP XX:XX:XX:.. timed out)
[14:13] <asac> torkel: could you please open a bug and attach your complete syslog there and then point me to it?
[14:13] <asac> torkel: i would like to test then something ;)
[14:13] <torkel> on the other hand the wpa_supplicant log complains that it fails to verify the certificate, so that may very well be the problem
[14:14] <asac> oh
[14:14] <asac> torkel: yes. please do the above. i will give you instructions what exactly to test then
[14:15] <torkel> asac: sure. Not sure I will have time to it today though. I'm off in about 45 minutes
[14:15] <asac> torkel: please today ;)
[14:16] <asac> torkel: if not, just file the bug and lets continue asasp
[14:16] <torkel> asac: sure
[14:36] <torkel> asac: bug 284409
[14:37] <jdstrand> mdz: fyi-- filed my t42 boot hang (non-iwl3945) as instructed as bug #284406
[14:40] <asac> jdstrand: what is non-iwl3945? ath8k?
[14:40] <jdstrand> asac: ipw2200
[14:41] <asac> oh
[14:41] <asac> jdstrand: is it broken now?
[14:41] <jdstrand> so, still intel
[14:41] <asac> (after the associate= fix)?
[14:41] <jdstrand> asac: it shows just like bug #263059
[14:42] <jdstrand> asac: but I filed separately per mdz's instructions
[14:42] <asac> jdstrand: did this start with the last upload?
[14:44] <jdstrand> asac: no, I don't think so. the problem is, I don't use this system that much... I know I got occasionaly boot hangs during intrepid, but haven't tried to troubleshoot until today
[14:44] <jdstrand> :(
[14:44] <asac> torkel: self-signed cert. is that what you are using?
[14:45] <asac> siretart: any idea if we can make wpasupplicant accept self-signed certs? or whether thats an issue at all? 284409
[14:45] <torkel> asac: no. It shouldn't be
[14:46] <asac> torkel: thats what i see in the log you posted
[14:46] <asac> torkel: TLS: Certificate verification failed, error 19 (self signed certificate in certificate chain) depth 2
[14:46] <asac> torkel: SSL: SSL3 alert: write (local SSL3 detected an error):fatal:unknown CA
[14:46] <asac> so your CA appears to be not known
[14:48] <asac> torkel: http://www.madboa.com/geek/openssl/#verify-standard
[14:48] <asac> torkel: can you try that?
[14:56] <torkel> asac: seems to be working if I drop the CA certificate from the connections editor
[14:58] <asac> torkel: well. then you dont use tls?
[14:58] <torkel> but the certificate verfied OK (with openssl verify)
[15:00] <torkel> and now I get "Updating connection failed: client cert", when trying to readd the CA cert
[15:00] <siretart> bug 284409
[15:01] <torkel> asac: should't I be able to specify as CA path instead of a CA certificate?
[15:01] <tedg> kwwii: Is this one in your theme update?  bug 278006
[15:02] <siretart> asac: you need to specify a root certificate in any case. so it doesn't matter
[15:03] <torkel> or does N-M/wpa_supplicant search in /etc/ssl/certs by default?
[15:03] <siretart> asac: TBH, that bug looks to me like an invalid certificate, or the root certificate was not specified
[15:03] <siretart> torkel: no. you need to add the root CA to your config
[15:05] <asac> siretart: oh ... that explains it
[15:05] <geser> what's the current process to get a security fix synced from Debian? ask first the release-team for an ack and then subscribe u-m-s or vice versa?
[15:05] <asac> siretart: why would we need to add the root cert if the root CA is a well known one?
[15:08] <siretart> asac: err, please rethink about that
[15:10] <siretart> asac: the root CA cannot be a well known one. it needs to be site specific so that you get any security benefit
[15:12] <jdstrand> geser: I followed SyncRequestProcess recently and it went fine
[15:14] <jdstrand> geser: eg bug #281456
[15:15] <nazgul> hi asac . I believe the prio of launchpad Bug #259214 should be raised as it severely cripples static network config. My comment is the last one on this bug.
[15:27] <jdong> is it a known bug that if the magical logout button starts before g-p-m (which always seems to be the case) the suspend/hibernate buttons don't show up?
[15:28] <Keybuk> no
[15:28] <Keybuk> please file that
[15:28] <cjwatson> TheMuso: FYI I've targeted bug 275233 since heno flagged it
[15:28] <Keybuk> tedg: ^^
[15:30] <jdong> Keybuk: what package is the logout applet in?
[15:30] <Keybuk> jdong: fast-user-switch-applet
[15:31] <jdong> Keybuk: thanks
[15:31] <tedg> jdong: Send me the bug number.
[15:32] <jdong> already filed; bug 278810, tedg
[15:33] <tedg> Keybuk: what do you think about the change on that bug?
[15:34] <jdong> does g-p-m correctly show up in the panel if it starts before the panel does?
[15:34] <Keybuk> tedg: -v
[15:35] <jdong> Keybuk: proposed X-GNOME-Autostart-Phase=Windowmanager for g-p-m's xdg entry
[15:35] <tedg> Keybuk: It basically changes GPM to start up with the window manager.
[15:36] <tedg> jdong: Could you try setting the phase to "Panel" to see if that works?  I'd be happier with that.
[15:36] <Keybuk> isn't that just leaning the race in one direction?
[15:36] <Keybuk> g-p-m may still not be on the bus in time
[15:36]  * jdong agrees with Keybuk 
[15:37] <jdong> can f-u-s-a poll for g-p-m if it's not immediately available?
[15:37] <jdong> I know the p-word is bad these days too :)
[15:37] <tedg> Not really leaning, I believe that gnome-session completes phases before continuing on.
[15:37] <Keybuk> tedg: how does it know that g-p-m is on the bus?
[15:37] <jdong> tedg: I think Keybuk is saying g-p-m started doesn't imply it's on the bus
[15:37] <kwwii> tedg: I looked into that...the icon is 24x24 (and 22x22) so I cannot figure out where that comes from
[15:38] <asac> nazgul: you cannot save a auto generated connection. so you either have to rename it or to create a new one
[15:38] <asac> nazgul: then it should work
[15:38] <kwwii> tedg: my update only kills the little green man (and adds an svg for the computer icon)
[15:39] <tedg> Keybuk, jdong: Yes, I guess it doesn't guarantee, but man, it works for most users in the Application phase now.  I imagine changing to Desktop would fix it, much less Panel or WindowManager.
[15:39] <Keybuk> it's not a fix, the race is still there
[15:39] <jdong> well it's a tmporary workaround
[15:40] <tedg> kwwii: Okay, well what is the size of the icon when it's an IM status one?  Perhaps it needs 18px or 16px?
[15:41] <RicardoPerez> mvo: ping
[15:41] <tedg> Keybuk: correct, not a fix, but a one line change to a desktop file.
[15:41] <mvo> RicardoPerez: pong
[15:41] <Keybuk> which doesn't fix the problem, just reduces it
[15:41] <RicardoPerez> mvo: Hi, Michael. Can you tell me if the packages description translations are up to date into Intrepid?
[15:42] <RicardoPerez> I can see translations done on 2008-08-14 which aren't in Intrepid's Translation-es
[15:42] <jdong> tedg: is it prohibitively difficult to have the applet check occasionally for the presence of g-p-m?
[15:42] <mvo> RicardoPerez: not currently, I want to that this week. I had hoped to be able to merge from debian but debian does currently not export them
[15:43] <mvo> RicardoPerez: the lastest upload if from ~20080812 - high time for a new one
[15:44] <mvo> RicardoPerez: do you know about  http://people.ubuntu.com/~mvo/nightmonkey/ btw?
[15:44] <RicardoPerez> mvo: oh, great
[15:44] <RicardoPerez> mvo: mmmm sorry, I didn't knew. What's that?
[15:44] <tedg> jdong: No, it is not.  But it'll be a larger code change.  If you can convince the release team to accept it, I'll code it :)
[15:44] <mvo> RicardoPerez: it make  finding the right strings in the translations in rosetta easier for the descriptions
[15:45] <kwwii> tedg: 16x16
[15:45] <mvo> RicardoPerez: I request a export now, it usually takes a bit until its done (some hours)
[15:45] <RicardoPerez> mvo: Oh, sounds great!
[15:45] <RicardoPerez> mvo: I'll take a look, but sounds very interesting :)
[15:45] <kwwii> tedg: but that icon does not exist at that size
[15:46] <RicardoPerez> mvo: Thank you very much for the update request!
[15:46] <kwwii> tedg: and the svg is also square so it cannot come from that either
[15:46] <tedg> kwwii: So that's probably why it's getting cropped.  Pulling in a larger one and trying to make it 16px
[15:46] <mvo> RicardoPerez: I need to write something about it, it was done Nyitrai and should really make the translation work for the package descriptions easier
[15:46] <mvo> (hopefully :)
[15:46] <mvo> thank RicardoPerez
[15:46] <kwwii> tedg: yeah, could be
[15:46] <RicardoPerez> mvo: "ok" means "translated"?
[15:47] <mvo> RicardoPerez: yes
[15:47] <RicardoPerez> mvo: great, it's a very useful tool!
[15:47] <Riddell> persia: you uploaded casper?  editing ubiquity-gtkui.desktop at the end of that script won't help for the copy in ~/Desktop
[15:48] <RicardoPerez> well, thanks again, bye!
[15:48] <jdong> Riddell: while you're here, can you comment on tedg and my discussion regarding GNOME's fast user switching applet?
[15:48] <RicardoPerez> mvo: btw, are you into Compiz developing, too?
[15:48] <persia> Riddell, Yeah, but nothing in ~/Desktop is visible in Ubuntu MID, so I don't really care.
[15:48] <RicardoPerez> s/developing/development/g
[15:48] <mvo> RicardoPerez: I maintain the packages
[15:49] <mvo> (well, with the compiz team)
[15:49] <RicardoPerez> mvo: I've found that compiz takes too much time to start during GNOME startup... Makes GNOME idles for about 4-5 seconds
[15:50] <RicardoPerez> what can be done with that bugreport?
[15:50] <Riddell> persia: ok, accepting
[15:50] <jdong> RicardoPerez: I've always wondered what that lag is, too.
[15:50] <jdong> it's not really an idle as much as it is a UI hang
[15:50] <persia> Riddell, Thanks.
[15:50] <RicardoPerez> https://bugs.edge.launchpad.net/ubuntu/+source/gnome-session/+bug/284366
[15:50] <mvo> RicardoPerez: I have not profiled it, but I strongly suspect its the xml parsing it does on startup
[15:50] <Riddell> jdong: seems like a gnomey change, what do you want me to add?
[15:51] <RicardoPerez> jdong: so you've see that issue, right?
[15:51] <jdong> Riddell: something along the lines that if tedg takes the time to code up that, then release team will allow the upload
[15:51] <RicardoPerez> mvo: great, I don't know if that bugreport should be redirected from gnome-session to compiz...
[15:51] <ScottK> jdong: Can you go ahead and get intrepid-backports set up?  asac is interested in pushing Firefox-3.1 packages there ASAP after release.
[15:51] <jdong> RicardoPerez: yes. on all of my systems. I think it's something related with AIGLX
[15:51] <jdong> ScottK: ok. That's probably an infinity job, right?
[15:52] <RicardoPerez> jdong: but I'm not using AIGLX, but NVIDIA
[15:52] <ScottK> jdong: Dunno.  You're Mr. Backports.
[15:53] <jdong> RicardoPerez: I haven't looked at the code yet for compiz. it for me happens after compiz takes over the UI, hanging all of the windows for some time
[15:53] <jdong> RicardoPerez: you can see that from running compiz --replace
[15:53] <RicardoPerez> jdong: "compiz --replace" from metacity, right?
[15:53] <jdong> RicardoPerez: or from compiz itself.
[15:53] <RicardoPerez> jdong: mmm, ok, let's see
[15:54] <jdong> RicardoPerez: for me it takes about 2.5secs of fidgeting around before it settles
[15:54] <jdong> similar to what's done on login
[15:54] <Riddell> jdong, tedg: having g-p-m check for dbus periodically seems the sensible thing to do, I expect it would get accepted if it was suitably tested, ScottK just did a similar fix in our g-p-m
[15:55] <ScottK> I extracted the interval of 30 seconds from the usual place and used that.
[15:55] <tedg> Riddell: It doesn't need to poll, just listen to DBus namechange requests.
[15:55] <tedg> Riddell: You guys have a copy of gpm that's different?
[15:55] <ScottK> We have Guidance Power Manager
[15:55] <ScottK> Totally different beast with an unfortunately similar arcroynm
[15:56] <RicardoPerez> wow. sorry. crash after compiz --replace
[15:56] <tedg> ScottK: Ah, okay.  How confusing.
[15:56] <tedg> It was kinda like them replacing gnome-vfs with gvfs.
[15:56] <RicardoPerez> well, not exactly a crash, but renders all the windows unusable
[15:56] <jdong> RicardoPerez: sounds like a bug :)
[15:57] <RicardoPerez> jdong: I've done "compiz --replace", but it isn't take 5 seconds, but < 2
[15:57] <jdong> RicardoPerez: right, but that's after startup with no activity
[15:58] <RicardoPerez> however, the bug I reported appears even when you log out & log in then...
[15:58] <RicardoPerez> jdong: I've just done "compiz --replace" again, and all works OK, without idle
[15:59] <RicardoPerez> jdong: I just repeated "compiz --replace" one more time, and again I had no idle
[15:59] <RicardoPerez> jdong: however, If I log out and log in again, I have a ~5 seconds idle...
[16:04] <cjwatson> RicardoPerez: the translations import queue is only up to 2008-10-08 right now, so some things are still behind
[16:05] <cjwatson> RicardoPerez: (even aside from any manual exports that are needeD)
[16:05] <cjwatson> s/D/d/
[16:05] <cjwatson> RicardoPerez: the good news is that it is catching up
[16:06] <RicardoPerez> cjwatson: great, thanks a lot for the news. It could be great if the queue were reduced ;)
[16:06] <cjwatson> RicardoPerez: yeah, it's getting there; it was only up to, er, something like 2008-10-03 this time yesterday
[16:07] <RicardoPerez> cjwatson: ok, thank you very much again for your i18n efforts ;)
[16:28] <mdz> bryce: bug 275285 and bug 274045 are the last remaining Intrepid targeted bugs in main without an importance set.  could you evaluate their importance?
[16:32] <ogra> seb128, hmm, my evo has some folders again where it doesnt clean out the status
[16:34] <seb128> ogra: what do you mean?
[16:34] <ogra> seb128, showing unread mails where there are none
[16:35] <james_w> archive admins: libruby1.8-extras just built, so libgems-ruby1.8 should be possible to clear from NBS
[16:35] <ogra> s/where/while/
[16:36] <ogra> seb128, gdmsetup has the old bug of taking a century to come up again it seems
[16:37] <seb128> ogra: nobody else complained about either of those
[16:37] <ogra> seb128, i just noticed them, sorry
[16:37] <seb128> ogra: are you sure that evo is just not updating the count but not the list? ie switching to an another box and back to this one
[16:38] <ogra> tried already
[16:38] <ogra> i'll close and open it again, lets see what it does then
[16:39] <ogra> ok, closing it fixed that
[16:39] <ogra> might be becase i rebooted after the upgrade
[16:40] <ogra> i should probably close it first after upgrades before rebooting
[16:42] <ogra> could some archive admin process linux-lpia please ? i pinged pitti before but seems that was swallowed by his outages
[16:45] <calc> does transmission no longer minimize to notification area?
[16:46] <sebner> calc: asking myself the same
[16:55] <kirkland> slangasek: ping
[16:55] <kirkland> slangasek: hey, i'd like to fix pam_ecryptfs now, if possible
[16:55] <kirkland> slangasek: i'm looking at pam_sm_chauthtok()
[16:57] <calc> ugh, nautilus displays the full mimetype name in the properties next to the human description
[16:57] <calc> this makes nautilus properties window REALLY wide for some file types
[16:57] <ogra> not here
[16:57] <ogra> did you play with the options ?
[16:58] <calc> ogra: i don't think so, hmm i'll look for the option to fix it
[16:58] <calc> ogra: i didn't do a fresh install so maybe its some old setting i forgot about
[16:58] <calc> i don't see an option in nautilus to adjust that
[16:59] <calc> eg i get: "PowerPoint 2007 slideshow with macros enabled (application/vnd.ms-powerpoint.slideshow.macroEnabled.12)"
[16:59] <calc> all on one line
[16:59] <calc> which makes a 918x433 nautilus property window
[17:00] <ogra> hmm, there is a mime type checkbox in the settings for listview
[17:00] <ogra> but thats unchecked by default
[17:00] <calc> ah, looking now
[17:00] <calc> ogra: is that in nautilus or gconf?
[17:00] <ogra> nautilus
[17:00] <ogra> third tab in the settings
[17:01] <ogra> err
[17:01] <ogra> fourth, sorry
[17:01] <calc> well this is in properties not in the nautilus list view
[17:01] <calc> and that option is disabled for me
[17:02] <calc> the properties view (right click on file) is where i am seeing it
[17:02] <kirkland> slangasek: ah, i see now you have an almost-working patch;  i'll take it from there
[17:04] <calc> hmm i need to determine how to make these icons look better as well, they are just plain paper icons for the Office 2007 files :\
[17:04] <calc> is that something set in the shared-mime-info files or something else?
[17:07] <calc> hmm i see the mimetype name for the icon file
[17:10] <kirkland> slangasek: i do need you to explain one thing to me...
[17:10] <kirkland> slangasek: if the two new passwords DON'T match, why do we even get to pam_ecryptfs in the stack?
[17:10] <kirkland> slangasek: why doesn't pam just bomb out at that point
[17:11] <kirkland> slangasek: like it does when you give a "wrong" current password
[17:13] <kirkland> slangasek: ohhhhhhhh
[17:13] <kirkland> slangasek: see /etc/pam.d/common-password
[17:13] <kirkland> slangasek: pam_ecryptfs.so is just below pam_permit
[17:14] <kirkland> slangasek: which, according to the inline comments, "primes" the stack with a positive return value
[17:17] <ogra> mdz, amitk has a Q1 and knows the problem, do i really need to put the info on the bug ?
[17:18] <ogra> (its just the paperwork to a probelm we already worked out the solution for on irc)
[17:18] <cjwatson> ogra,amitk: linux-lpia accepted
[17:18] <ogra> cjwatson, merci :)
[17:19]  * ogra has lrm and -meta sitting on the disk waiting for the build to be done :)
[17:21]  * ogra needs to go help moving some furniture around, back later
[17:23] <mdz> ogra: if you've already agreed with Amit what needs to be done, please document that in the bug
[17:24] <mdz> ogra: I've never heard of a PCI quirk controlling which driver is selected...
[17:26] <nazgul> asac: ok thanks. I will file an upstream bug then.
[17:27] <asac> nazgul: if you do, please post the bug in launchpad bug too
[17:27] <asac> nazgul: or add it as upstream task. thanks
[17:27] <asac> nazgul: (and set ubuntu status to triaged)
[17:29] <jdstrand> jdong: ping re jhead
[17:30] <jdong> jdstrand: sup?
[17:30] <jdstrand> jdong: can you respond to Steven M Christey's questions-- he CC'd you on your @ubuntu address
[17:31] <jdong> jdstrand: yeah let me grab a diff of jhead and see exactly what the author fixed
[17:31] <jdstrand> jdong: cool, thanks!
[17:35] <pitti> I can haz an interweb plz??
[17:37] <amitk> mdz: i didn't suggest a quirk to select the driver. I suggested removing certain PCI IDs from the driver if they didn't work. But for the ath5k this is moot until rtg rolls out the wireless backports. ath5k has known issues in 2.6.27.
[17:37] <Treenaks> pitti: Even more interwebs?!
[17:38] <cjwatson> mdz: the lbm bug is done now FYI (once the binaries get through new anyway0
[17:38] <pitti> Treenaks: the one which just started working again is quite alright
[17:38] <cjwatson> )
[17:39] <pitti> ogra: someone beat me to it
[17:39] <mdz> cjwatson: is the bug number in .changes so I can forget about it?
[17:40] <mdz> amitk: that makes more sense. the bug report says a quirk.
[17:43] <cjwatson> mdz: yes
[17:45] <asac> amitk: whats the idea of these "backports" driver packages. i understand that everything that comes late goes there, but how does this fix normal users? is there an easy mechanism so users that have issues can switch to the backport modules?
[17:47] <amitk> asac: backports will not be a default install. Users experiencing problems with the in-kernel drivers can choose to try out new drivers from backports. But they are not heavily tested. We've used backports to supply users with latest alsa and wireless bits before.
[17:48] <asac> amitk: ok. so backport modules are not something that help the normal user experience.
[17:49] <amitk> asac: not out of the box.
[17:49] <asac> i understood that. just wondered why we ship them or if there is a way we communicate to the user "hey, your current card doesnt work, but you could try the backports"
[17:51] <amitk> asac: i don't know of any formal communication about it. So these suggestions are made or IRC/Mailing lists/Forums, etc. No jockey-like interface.
[17:51] <asac> i see
[17:51] <amitk> hope that answers your question...
[17:52] <asac> amitk: its just that it sometimes feels a bit like: "well, some chipsets just dont work. as long as we have backports this isnt really release critical"
[17:53] <asac> of course thats an exaggeration ... so excuse that ;)
[17:54] <asac> it just means that for an "outsider" like me its not really obvious when wireless breakage is considered release critical and when a fix in backports is enough
[17:55] <amitk> asac: if a 'few' patches fixed a driver to make it work we would apply it to the ubuntu tree. Backports are usually done when there are significant changes to the underlying subsystem so that while fixing newer chipsets it also introduces regressions.
[17:56] <amitk> asac: in the above case, rtg is planning to just grab upstream wireless.git (that will probably be merged in 2.6.28) and compile it against 2.6.27.
[17:56] <asac> amitk: ok thats understood
[17:56] <asac> amitk: but when does the kernel team consider a problem critical enough to do a proper fix in the current stable tree
[17:56] <asac> even if it might not be trivial?
[17:57] <sharms_> are there any downsides if I run intrepid using ld.so.nohwcap?
[17:57] <asac> a problem == a problem in wireless
[17:58] <asac> amitk: sorry, i guess you are actually the wrong one to talk about that ;)
[17:58] <asac> lets carry that somewhere else ;)
[17:58] <asac> and discuss during UDS ;)
[17:59] <ogra> amitk, so ath5k wil be removed from -generic as well ?
[17:59] <amitk> asac: alright :)
[18:00] <amitk> ogra: no. In case of the Q1 I only intended to remove the pci id for that particular chip in the Q1.
[18:01] <ogra> ok
[18:01] <asac> amitk: and go for ndiswrapper instead? (when the driver isnt loaded)
[18:01] <asac> or what is the other option for ath5k users?
[18:02] <amitk> asac: madwifi?
[18:02] <ogra> asac, ath_pci works fine on the Q1 ...
[18:02] <asac> amitk: err. and what about wpasupplicant?
[18:02] <asac> there is no madwifi module for that anymore
[18:03] <asac> hmm
[18:03] <asac> ogra: on intrepid. good to hear then
[18:03] <ogra> yes
[18:04] <asac> ok thanks. i guess thats good enough then
[18:04] <asac> wasnt aware that ath_pci now properly supports wext
[18:04] <ogra> well, i havent heard any bad reports so far
[18:05] <ogra> i only use WEP myself here
[18:05] <asac> ogra: where is the last image?
[18:05] <asac> latest i mean ;)
[18:06] <ogra> http://cdimage.ubuntu.com/ubuntu-mobile/intrepid/current
[18:06] <asac> ok easy enough
[18:06] <asac> now you should add instruction sin that directory too ;)
[18:06] <asac> ogra: ^
[18:06] <ogra> ??
[18:06] <ogra> for what ?
[18:07] <asac> how do i use this image ;)
[18:07] <asac> for beginners
[18:07] <ogra> https://wiki.ubuntu.com/MobileTeam/Mobile/HowTo
[18:07] <slytheri1> Can any archive admin please process bug 267816. The last time it was processed only source was moved to universe.
[18:07] <amitk> asac: WPA will have to wait till we can fix ath5k i guess.
[18:07] <ogra> asac, its all pointed out in the #ubuntu-mobile topic
[18:08] <asac> ogra: hehe. yeah. whatever, having those in the directory would be helpful ;)
[18:08] <ogra> yeah, i'll consider that for final
[18:09] <ogra> ayway
[18:09]  * ogra actually goes to do what he said before and moves some furniture now 
[18:16] <slytheri1> slangasek: now that cglib2.1 is in universe, can you please also take care of libxstream-java? bug #268538. Or do I need a new ack?
[18:19] <tkamppeter> pitti, I have installed the newest Jockey and want to test the situation when there are two drivers for one printer. How can I switch Jockey to also idownload and install real binary packages (I also need it for general testing)?
[18:20] <pitti> tkamppeter: /usr/lib/python2.5/site-packages/jockey/detection.py, line 562; remove the 'architectures': 'noarch'
[18:22] <tkamppeter> pitti, I have done so and do not get any answer on printer_deviceid:MFG:Samsung;MDL:ML-1610;CMD:GDI;, nor on printer_deviceid:MFG:Epson;MDL:Stylus Photo 1290;
[18:22] <tkamppeter> pitti, with the second I tried to trigger Gutenprint
[18:22] <pitti> tkamppeter: did you sudo killall jockey-backend? it only times out after 10 minutes
[18:24] <tkamppeter> Thank you, pitti, now it works (the 10 minutes passed).
[18:24] <pitti> tkamppeter: you can use above killall, too, then the GUI will just start a new backend
[18:25] <tkamppeter> pitti, I have done so and it told that the process has already gone away.
[18:25] <pitti> ah :)
[18:26] <pitti> tkamppeter: in future versions I want to make this configurable, but right now jockey doesn't have a configuration thingy so far
[18:26] <tkamppeter> pitti, now I have requested printer_deviceid:MFG:Samsung;MDL:ML-1610;CMD:GDI; and I get only one entry, not two (aplix, splix2).
[18:26] <tkamppeter> s/aplix/splix/
[18:26] <pitti> tkamppeter: right, that's because they both have the same package name (the bug I mentioned as "disambiguate")
[18:27] <pitti> I have a rough idea how to fix this, but didn't yet
[18:27] <tkamppeter> pitti, so I have to rename them on the server at first?
[18:28] <pitti> tkamppeter: that would work (splix-snapshot?), but I'd also like to fix it more generally in jockey
[18:28] <cjwatson> acpi-support (0.114) intrepid; urgency=low
[18:28] <cjwatson>   * The rfkill interface has changed again in the 2.6.27 release(!), so
[18:28] <cjwatson>     play catch-up once more.
[18:28] <cjwatson>  -- Steve Langasek <steve.langasek@ubuntu.com>  Wed, 15 Oct 2008 03:08:58 +0000
[18:28] <cjwatson> mdz: ^- do you have that installed?
[18:29] <tkamppeter> pitti, it would be great if you could fix that, because released versions and development snapshots of the same driver usually have the same package name but only a different version number.
[18:29] <cjwatson> just happened to notice it in an upgrade
[18:29] <pitti> tkamppeter: right, that's my plan (disambiguate by version number)
[18:31] <tkamppeter> pitti, for the test case of two drivers I have requested an HP now, as they are supported by HP's PPDs and by Gutenprint.
[18:31] <pitti> that should work, yes
[18:36] <tkamppeter> pitti, some small details:
[18:37] <tkamppeter> 1. If one of the multiple drivers is recommended, the selection should be on that driver, either by positioning it or by putting the recommended driver to the top.
[18:37] <tkamppeter> 2. Can you simply change the font of the license window to Courier and make it so wide that 89 characters per line fit into it?
[18:38] <tkamppeter> If you cannot change the font, Make it simply much wider, so that the probability of too long lines gets negligible.
[18:38] <tkamppeter> s/89/80/
[18:41] <tkamppeter> 3. If I switch forth and back between the two drivers the line with the driver description at the top of the lower big box (gray part, over "Not tested by Ubuntu developers") does not change. It simply stays one of the two.
[18:43] <pitti> tkamppeter: what dbus-send command did you use? I'll try to reproduce 3
[18:47] <tkamppeter> dbus-send --print-reply --dest=com.ubuntu.DeviceDriver /GUI com.ubuntu.DeviceDriver.search_driver string:"printer_deviceid:MFG:Hewlett-Packard;MDL:HP LaserJet 3020;CMD:PJL,MLC,PCL,POSTSCRIPT,PCLXL"
[18:48] <tkamppeter> pitti, it is the command which you gave me earlier.
[18:48] <pitti> ah, that one
[18:49] <slangasek> kirkland: mmm, no; you get to pam_ecryptfs because the way pam_chauthtok() works is to make two passes through the password stack, once with PAM_PRELIM_CHECK set and once with PAM_UPDATE_AUTHTOK set
[18:50] <kirkland> slangasek: k
[18:50] <kirkland> slangasek: i'm looking at pam's modules/pam_cracklib/pam_cracklib.c
[18:51] <slangasek> kirkland: and one of the things Linux-PAM does, that's not in the original spec, is to "freeze" the module stack for the second run so that it always matches what was done in the first run; that means any module that was seen on the first pass will also be seen on the second pass, regardless of return codes
[18:51] <cjwatson> lool: re xorg 1:7.4~5: FWIW debconf doesn't care if you output random junk to stderr
[18:51] <kirkland> slangasek: nice, handles racey config changes
[18:51] <slangasek> kirkland: however, I think it's because pam_ecryptfs doesn't give different return codes for the two passes that the stack winds up returning success as a whole
[18:51] <cjwatson> lool: IME you should usually use rmdir --ignore-fail-on-non-empty rather than 2>/dev/null
[18:52] <kirkland> slangasek: but i'm having this problem without pam_ecryptfs in the stack
[18:52] <kirkland> slangasek: you indicated that you were not able to reproduce it in that case?
[18:52] <slangasek> ah, it's not for racey config changes; it's more difficult to explain, and I suspect that there are actually some subtle bugs there which I've never pinned down, but it's what we have to work with
[18:52] <pitti> tkamppeter: ah, I get it, too; weird, I never saw this before, looking
[18:53] <slangasek> slytheri1: libxstream-java appears to already be half in universe for some reason; I'll clean that up
[18:53] <kirkland> slangasek: see modules/pam_cracklib/pam_cracklib.c, the block that handles MISTYPED_PASS
[18:53] <kirkland> slangasek: i see retval = PAM_AUTHTOK_RECOVERY_ERR, and then continue (rather than return)
[18:53] <Mirv> mvo: with nonlanguagepacktranslationfreeze, would there be time to a) sync from Debian to Ubuntu DDTP, this time from Debian main servers (or actually not ftp.debian.org but eg. ftp.de.debian.org), b) sync from there to Ubuntu repositories?
[18:53] <pitti> tkamppeter: might be because of the <br> in the text or so; I guess I shuold just filter that out
[18:53] <kirkland> slangasek: it looks to me like the continue is to allow the user to try again
[18:53] <kirkland> slangasek: but that's not what's executing for me
[18:54] <Mirv> mvo: (ddtp.debian.net does not host the translations any more since they are nowadays properly mirrored)
[18:54] <kirkland> slangasek: i changed it to return PAM_AUTHTOK_RECOVERY_ERR
[18:55] <kirkland> slangasek: but that didn't quite fix it alone; so I'm recompiling shadow against the updated pam library
[18:55] <slangasek> kirkland: right, if I don't have pam_ecrytpfs in the stack, I'm not getting this bug.  You're reproducing it with cracklib, now?  I was leaving cracklib out, fo the sake of simplicity
[18:56] <slangasek> what does the full stack look like on the system where you're reproducing this without ecryptfs?
[18:56] <kirkland> slangasek: hrm, i was grepping for "password updated successfully", and that sent me to cracklib
[18:56] <kirkland> slangasek: though i do see another hit in unix
[18:58] <kirkland> slangasek: http://people.ubuntu.com/~kirkland/pam.d
[18:58] <tkamppeter> pitti, if there is no easy way of GTK rendering the tags correctly, filter them out, as they also look ugly when they do not get rendered.
[18:59] <pitti> tkamppeter: that's what I did now, and it fixes 3); committed to trunk
[18:59] <slangasek> kirkland: how are you reproducing it with this stack?  pam_unix is the only module listed
[18:59] <kirkland> slangasek: sorry, i was grepping for "Sorry, passwords do not match"
[19:00] <kirkland> slangasek: passwd.  correct password.  enter first password.  enter different password
[19:00] <kirkland> slangasek: passwords do not match (which I thought was cracklib, but perhaps it's unix), then passwd says "updated successfully"
[19:00] <slangasek> ok
[19:01] <kirkland> slangasek: okay, so i should be looking around MISTYPED_PASS in modules/pam_unix/support.c
[19:02] <slangasek> hmm, I think this would be one of the subtle bugs with the PAM chain freezing I mentioned :P
[19:02] <kirkland> slangasek: :-)
[19:02] <slangasek> pam_unix isn't doing anything wrong; it's the stack itself that does it
[19:02] <tkamppeter> pitti, great, and 1 and 2 should also be easy and as they do not change text content or UI logic it is also no problem after the freeze.
[19:02] <tkamppeter> And for 3 make sure that you filter the tags not only for the big box but also for the small box where one chooses the driver.
[19:03] <slangasek> kirkland: I think this part of the bug is intractable for intrepid; but I think we can still fix the ecryptfs case, which adds its own wrinkle
[19:04] <kirkland> slangasek: okay, i'm all ears;  though i'm surprised to hear you call the pam part "intractable" :-)
[19:04] <slytheri1> slangasek: thanks.
[19:06] <slangasek> kirkland: well, here are the constraints that we have to work with: we want a completely stackable system where no package's profile accidentally short-circuits the stack on either success or failure; that means that we avoid setting the stack's return value from any of the password-changing modules; so something has to set the return value, and that's pam_permit at the end
[19:07] <pitti> tkamppeter: yes, already done
[19:07] <pitti> tkamppeter: looking at 2 and 1 now
[19:07] <slangasek> kirkland: and pam_permit will /always/ return success, so when it returns it on the first pass, the PAM stack says "ok, this module matters and we should pay attention to it on the second pass", so it always sets the return value to success
[19:08] <slangasek> kirkland: correcting that means deep changes to how PAM handles the chain freezing for pam_chauthtok()'s two passes
[19:08] <kirkland> slangasek: okay; so from the pam_ecryptfs perspective, was that under no circumstances, prevent the rest of the PAM stack from operating as expected
[19:09] <slangasek> and I think I can give you that :)
[19:09] <kirkland> slangasek: and i think the PAM_SUCCESS we return was in the interest of that :-)
[19:09] <slangasek> it'll take me a couple of hours, though
[19:10] <kirkland> slangasek: the oneliner you posted isn't enough, then
[19:10] <slangasek> correct
[19:10] <slangasek> but I have a sense of what it needs to be instead
[19:10] <kirkland> slangasek: okay.  i expected you to levy that one on me ;-)
[19:12] <kirkland> slangasek: i'll gladly step aside and go try to fix https://bugs.edge.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/259293
[19:12] <kirkland> slangasek: that's the one that cron is causing
[19:13] <kirkland> slangasek:  is there any way for pam_ecryptfs to "not" execute as when it's cron that's opening/closing the session?
[19:13] <slangasek> kirkland: mumble need split configs for interactive vs. non-interactive sessions mutter
[19:14] <kirkland> slangasek: and determine interactive/non-interactive based on .... ?
[19:14] <slangasek> kirkland: I think you really want the counter, honestly; what if a user ssh's in to their system to try to troubleshoot something?
[19:14] <slangasek> kirkland: X and ssh and login are interactive, cron and http are not? :)
[19:14] <kirkland> slangasek: :-)
[19:15] <kirkland> slangasek: for the counter, jdstrand suggested something in /tmp/USERNAME-ecryptfs/
[19:15] <slangasek> kirkland: interactive vs. noninteractive session handling is a longstanding request, I've acknowledged that the current setup is deficient here; it's just not bubbled up the priority list yet
[19:15] <slangasek> why in /tmp, instead of in the user's homedir?
[19:15] <jdstrand> actually, I suggested /tmp/ecryptfs-USERNAME/ :P
[19:15] <kirkland> slangasek: okay
[19:16] <kirkland> jdstrand: :-)  thanks for keeping me honest
[19:16] <slangasek> hmm, I guess if the homedir is NFS-mounted, the counter would easily be wrong
[19:16] <kirkland> slangasek: i think it was mostly about guranteeing a reset on reboot
[19:16] <slangasek> ok
[19:16] <kirkland> slangasek: we started out thinking /var/run
[19:16] <kirkland> slangasek: but that requires priv's
[19:16] <kirkland> slangasek: and while mount.ecryptfs_private is setuid, bumping the counter shouldn't really need to be priv'd
[19:18] <slangasek> yep
[19:20] <zul> slangasek: if possible can you kick ec2-ami-tools out of NEW and into multiverse please
[19:21] <slangasek> zul: not at the moment; maybe there's another archive admin you could grab?
[19:21] <zul> slangasek: sure
[19:21] <crimsun> TheMuso: regarding the pa_*unref() crash - I have not experienced it yet with the Xsession.d workaround
[19:25] <zul> Riddell: ping
[19:57]  * mpt is momentarily confused by http://www.intrepidmuseum.org/About-Us/Press-Room/Press-Releases/Intrepid-Returns-RELEASE-and-CALENDAR.aspx
[19:58] <pwnguin> the most inspiring adventure in america!
[19:58] <mpt> I should have included "ubuntu" in my search terms
[20:01] <mpt> but the New York LoCo should totally have their release party on an aircraft carrier
[20:07] <pwnguin> heh
[20:07] <pwnguin> air drop ubuntu software aid on the people
[20:10] <cjwatson> kees,lool: what's the state of the remaining gspca milestoned bugs?
[20:10] <cjwatson> s/milestoned/targeted/
[20:21] <pitti> tkamppeter: splix vs. splix2 conflict fixed in bzr now, too
[20:21] <bryce> mvo: there is a patch now for compiz on bug #269904.  Have you had a chance to look at it?
[20:23] <bryce> mvo: I don't see anything wrong with the patch, but it alters a realloc call and switches from use of single variables to arrays, which makes it hard to say just by eyeballing that the patch is safe
[20:23] <torkel> siretart: why shouldn't you be able to use a well know root CA? It should only be used to establish/verify the certificate chain, not authorize you. Right? (Re 284409)
[20:25] <pitti> tkamppeter: and finally, (1) (show recommended drivers first) fixed in bzr as well; I think I addressed all your points now, and will do another intrepid upload
[20:25] <mdz> cjwatson: I don't know if I did when I last tested, will retest
[20:25] <psusi> is there an archive admin around who can help me figure out why the defrag package appears to have been dropped from the archive in hardy and later?  lp says it was superseded, but there is no newer version and it is no longer in the archive
[20:26] <cjwatson> psusi: it was removed using the old removal tool which didn't leave a very clear record in LP
[20:26] <psusi> cjwatson: why was it removed?
[20:26] <Keybuk> mdz: typically I now can't seem to replicate the iwl3945 problem
[20:26] <cjwatson> psusi: the log of its operation is here: http://people.ubuntu.com/~ubuntu-archive/removals.txt
[20:27] <cjwatson> ------------------- Reason -------------------
[20:27] <cjwatson> (From Debian) RoM; orphaned upstream and out of sync with common ext2/3 features
[20:27] <cjwatson> date was Fri, 30 Nov 2007 12:13:52 +0000
[20:27] <psusi> it seemed to be in good working order the last time I updated it...
[20:27] <cjwatson> so presumably as part of the initial sync passs
[20:27] <cjwatson> pass
[20:27] <cjwatson> psusi: might depend on what features you have on your filesystems ...
[20:27] <cjwatson> at a guess, perhaps it doesn't handle resize_inode?
[20:27] <cjwatson> libparted has that failing too
[20:27] <psusi> I think I fixed that...
[20:28] <cjwatson> feel free to reintroduce it (in jaunty) if you think it should be, but it might be a good idea to track down the people who asked for it to be removed from Debian and debate it with them,
[20:28] <cjwatson> s/,$//
[20:29] <psusi> oh wow... it WAS removed from debian.... hrm...
[20:30] <psusi> well, I know it had issues with the ext3 jornal, and something else... might have been the resize inode... I forget now... I fixed it up 2 years ago and I think I filed the patch with a bug report in debian but I don't think anyone there ever applied it so their version was still broken
[20:31] <liw> hmm. is it possible for a graphics card to break in such a way that it seems to work quite well, but occasionally freezes and colors go quite strange (as if it didn't produce green anymore)?
[20:32] <psusi> liw: if one of the colors goes out and you have a CRT, it is usually just a loose connection to the monitor
[20:32] <psusi> but yea, it's possible
[20:32] <liw> it's a tft, and the connectors are tightly screwed, I check that twice
[20:32] <cjwatson> psusi: Debian bugs #396449 and #401622 seem particularly relevant
[20:32] <liw> (tft with vga, though)
[20:33] <cjwatson> psusi: the first of those is an explicit request from the e2fsprogs maintainer to remove defrag
[20:33] <cjwatson> psusi: so I suggest you argue with him :)
[20:34] <cjwatson> psusi: your changelog in https://launchpad.net/ubuntu/+source/defrag doesn't mention resize_inode at all, which is a critical thing to support nowadays
[20:34] <cjwatson> so I stand by the removal
[20:35] <cjwatson> (though I don't think I was the admin who did it)
[20:35] <psusi> cjwatson: hehe, I guess I will... first I guess I need to rebuild it and do some more testing to make sure it still works... if it does, then I just need to point out to them that I did fix those issues and they just never applied them to debian
[20:36] <psusi> it is likely that it was just the generic issue of defrag not working properly with ANY reserved inodes, which I fixed
[20:36] <psusi> which was also why it clobbered the journal inode
[20:37] <psusi> but I'll make sure to make a test filesystem with resize support, then actually resize it, stress the hell out of it, and make sure defrag doesn't break it... then proceed from there
[20:40] <lool> cjwatson: I'm not working on gspca/libv4l; just helped getting the libv4l ready and in the archives
[20:41] <lool> cjwatson: If the bugs need help though, I have such a webcam and can help
[20:43] <cjwatson> psusi: I don't see the patch from you in the Debian BTS, but feel free to demonstrate that I'm wrong ...
[20:45] <bryce> cjwatson: heya
[20:45] <liw> hey, bryce, second upgrade test still running, fyi
[20:45] <liw> (5+ hours remaining)
[20:45] <bryce> cjwatson: we've got one fglrx issue to consider still
[20:45] <bryce> liw: excellent :-)
[20:46] <bryce> cjwatson: currently due to its libsigc++-5 dependency (iirc), it's stuck in multiverse
[20:46] <liw> bryce, of course, I'm now suspicous of my card since my colors are all wrong :)
[20:47]  * lool waves
[20:47] <bryce> er, libstdc++5
[20:47] <bryce> cjwatson: bug #271794
[20:47] <pitti> oh argh, there is again a new tzdata
[20:47] <psusi> cjwatson: it tells me there are NO bugs of any kind filed against it
[20:47] <liw> pitti, which country this time?
[20:48] <cjwatson> psusi: there's a thing at the bottom to get archived bugs
[20:48] <pitti> liw: haven't checked yet
[20:48] <cjwatson> psusi: RTFM
[20:48] <psusi> ahh ;)
[20:48] <cjwatson> the drop-down that says "Unarchived"
[20:48] <cjwatson> bryce: oh god, um
[20:48] <cjwatson> pitti,doko: ^- fglrx/gcc-3.3 help?
[20:48] <crimsun> cjwatson: I think he's referring to his most recent debdiff at https://bugs.edge.launchpad.net/ubuntu/+source/defrag/+bug/6546
[20:49] <pitti> cjwatson: oh, the "needs gcc-3.3" thing?
[20:49] <cjwatson> crimsun: yes, that doesn't exactly count as something that Debian can be blamed for missing if it was never sent to them
[20:50] <pitti> cjwatson, superm1, bryce: what's actually the pressing reason to have it in restricted and not in multiverse?
[20:50] <cjwatson> crimsun: he said "I think I filed the patch with a bug report in debian but I don't think anyone there ever applied it so their version was still broken" above
[20:50] <bryce> pitti, the specific issue is that this prevents it from being on the DVD
[20:50] <doko> ohh crap, is this a binary only, or is this a dependency of the driver package as well?
[20:50] <pitti> bryce: ah, good point
[20:50] <superm1> pitti, <putting on dell hat> It significantly simplifies factory installation
[20:50] <superm1> being able to have it on the DVD
[20:51]  * pitti doesn't understand how AMD can still use such an ancient libc++ for their current builds *sigh*
[20:51] <superm1> pitti, from what i understand, it's a single library in there that is used for it, not the whole thing
[20:51] <pitti> it would essentially force us to support gcc-3.3 ad infinitum
[20:51] <pitti> superm1: is it actually the X driver, or just some shiny GUI configuration thingy?
[20:51] <bryce> pitti: yeah we raised the issue a while back, but this was a minor issue compared with the Xorg 1.5 issue so didn't get priority
[20:51] <superm1> so I was saying perhaps if that single library can be split out to it's own package in multiverse
[20:51] <psusi> cjwatson: well... I can't find it either... odd... I could have sworn I put it in there and bumped it one or twice in the subsequent 6 months... oh well
[20:52] <superm1> pitti, its the library that provides XvMC acceleration I believe
[20:52] <pitti> superm1: right, if it's some setup tool, it could be split out, or libstc++5 could become a suggests or so
[20:52] <bryce> superm1: I wouldn't have a problem seeing that slipt out
[20:52] <pitti> bryce: what is XvMC? Xv is kind of important for watching videos..
[20:53] <cjwatson> bryce: do we have to build-dep on it in order to build it, or do they ship a binary application?
[20:53] <superm1> pitti, so would the archive allow for that put source package and most binary packages in restricted,  a workaround in debian/rules for dpkg-shlibdeps complaining, and then another binary package in multiverse?
[20:53] <bryce> pitti: X-video Motion Compensation
[20:53] <cjwatson> superm1: yes, that's possible as long as it doesn't need to build-dep on libstdc++5
[20:53] <superm1> it does currently have a  build-dep only because dpkg-shlibdeps looks for it
[20:53] <pitti> superm1: yes, if it's just a binary dependency and not a build dep
[20:53] <cjwatson> (transitively or otherwise)
[20:54] <superm1> surely something can be added to not bail out when it complains about it not being around
[20:54] <bryce> I don't know a lot about it but I gather it's a performance enhancing thing, rather than a hard prerequisite for video playback
[20:54] <cjwatson> --ignore-missing-info I believe
[20:54]  * pitti still remembers the time when he symlinked libc.so.6 to libc.so.5 just to get some old binary crap running
[20:55] <amitk> Keybuk: if you are still available can you join #ubuntu-kernel
[20:55] <superm1> bryce, i'll scrap the library out and see if I can still do video playback with some basic files
[20:56] <superm1> bryce, i'm pretty sure it's only necessary when you are doing accelerated playback
[20:56] <bryce> superm1: great
[20:56] <pitti> so if we can split out just that one lib into an extra package, or just drop it, that WFM
[20:59] <tedg> jdong: bug 278810 has a fix attached to it.
[21:02] <mvo> bryce: I have the patch on my radar, but I haven't tested/reviewed it yet
[21:03] <bryce> mvo, great thanks
[21:24] <badp> Hello. I found a broken package in the Ubuntu repos. Who do I bother?
[21:25] <badp> The problem's with libffi4.
[21:26] <tkamppeter> pitti, great, thank you very much.
[21:35] <wgrant> badp: What's wrong with it?
[21:36] <wgrant> Apart from not existing in Intrepid.
[21:37] <badp> Hmm, I was pretty sure it existed before I reloaded again the repos and before I added the source packages.
[21:38] <badp> In that case the ball passes to the miro devs including that package as a dependency since 1.2.7 I guess.
[21:38] <badp> Well, thank you anyway.
[21:38] <wgrant> https://edge.launchpad.net/ubuntu/intrepid/amd64/libffi4 suggests that it was removed 1.5 months ago.
[21:38] <wgrant> Same on i386.
[21:40] <badp> I guess I'll grab the .deb file from launchpad then
[21:41] <badp> erm, except it's not for my architecture.
[21:41] <badp> Well, anyway, thank you for the pointer.
[21:41] <wgrant> badp: We have a libffi5 from a separate source package.
[21:42] <badp> Yep, but it doesn't satisfy the miro requirement =/
[21:42] <badp> I know it isn't your fault
[21:42] <badp> external packages and all.
[21:42] <cjwatson> argh, cdimage got stuck on a lock AGAIN
[21:42] <cjwatson> screw this, I'm going to write a wrapper that kills that process if it takes too long
[21:48] <kirkland> jdstrand: hey, ecryptfs counter design question for you
[21:48] <jdstrand> ok
[21:48] <kirkland> jdstrand: i'm leaning toward making the counter only increment/decrement when called from PAM
[21:48] <kirkland> jdstrand: ie, not when called from the command line
[21:48] <kirkland> jdstrand: or, rather......
[21:49] <kirkland> jdstrand: that wasn't put very clearly
[21:49] <kirkland> jdstrand: okay, start over :-)
[21:49] <kirkland> jdstrand: i have the increment/decrement code mostly working, incrementing when mounting, decrementing when umounting
[21:50]  * jdstrand nods
[21:50] <kirkland> jdstrand: now i'm thinking about the logic for "when to refuse to unmount based on counter value"
[21:50] <kirkland> jdstrand: i will want a "force" method, whereby it's unmounted and the counter zero'd out
[21:51] <kirkland> jdstrand: so i'm thinking ....
[21:52] <kirkland> jdstrand: should that "force" be the default (which is basically the current methodology), or the exeception (with some new --force option)
[21:52] <doko> ubuntu-archive: pleae could somebody accept sun-java6 (multiverse)
[21:52] <kirkland> jdstrand: if the former, I add some new option (--counter), and tack that onto the PAM call
[21:54] <jdstrand> kirkland: I think it needs to be a simple and straightforward as possible for now. also, I'm not sure I understand the need for pam to know about the counter stuff
[21:54] <kirkland> jdstrand: pam = automated call
[21:54] <kirkland> jdstrand: manually calling mount.ecryptfs_private, versus happening automatically
[21:54] <jdstrand> kirkland: what is the advantage of it in pam? (esp considering that other upstream people will likely have objections)
[21:55] <kirkland> jdstrand: ?  having what
[21:55] <jdstrand> kirkland: maybe I am still confused by your previous comments...
[21:55] <kirkland> jdstrand: can we chat on the phone briefly?
[21:57] <pitti> slangasek: ok for me to sync http://packages.qa.debian.org/t/tzdata/news/20081015T091712Z.html ?
[21:57] <slangasek> pitti: yes
[21:58] <slangasek> kirkland: ok, got a patch now
[22:01] <slangasek> kirkland: posted to the bug; see if that takes care of the symptoms you see
[22:02] <kirkland> slangasek: k, nearly done with the ecryptfs counter patch
[22:04] <pitti> liw: tzdata country> syria; it's pretty much the only change between 2008g and h
[22:14] <calc> when is jaunty going to open?
[22:15] <sebner> calc: usually some weeks (1-2) after release ;)
[22:15] <calc> cjwatson: could we get a jaunty-alpha-1 milestone target?
[22:16] <calc> would be useful for my 3.0 targeted bugs
[22:18] <slangasek> no, it's not possible
[22:18] <slangasek> use the 'later' target
[22:18] <calc> slangasek: oh that can't happen until its opened?
[22:18] <slangasek> yes, because milestones are attached to series
[22:18] <calc> ok i'll just use that
[22:18] <calc> ah i see
[22:19] <cjwatson> calc: what he said, also we can't open jaunty until intrepid's done because it screws with LP's internal idea of package ancestry
[22:19] <calc> cjwatson: oh ok
[22:20] <cjwatson> calc: the series is usually opened in LP within a day of the release though
[22:20] <calc> ok
[22:20] <cjwatson> sebner is a little pessimistic :)
[22:20] <cjwatson> it may take a week or so before you can actually *upload* to it ...
[22:20] <calc> i'll just stick this all as later then reassign it after release
[22:20] <cjwatson> yeah, that's pretty much what later's for
[22:20] <calc> ok
[22:20] <cjwatson> silly hack, but ...
[22:20] <calc> hehe
[22:21] <calc> oh yea the jaunty page has a link to the release schedule but its not there yet, is that something that doesn't get put up until after UDS?
[22:21] <slangasek> that'll get put up this week
[22:21] <slangasek> (I'm hoping)
[22:23] <calc> ok
[22:23] <calc> looks like the cycle will start dec 18(?)
[22:23] <slangasek> the cycle "starts" Oct 31, surely? :)
[22:24] <cjwatson> oh, don't pay any attention to where the IntrepidReleaseSchedule calendar ends
[22:25] <calc> oh ok
[22:25] <calc> i was getting really confused as to when that would put jaunty releasing
[22:25] <calc> 27-28 weeks out from there would have been june
[22:26] <calc> looks like we are targeting ~ april 30 then for the release
[22:27] <slangasek> April 23
[22:28] <calc> ok
[22:34] <mdke> pitti: when you uploaded ubuntu-docs, did you apply the debdiff or do a fresh checkout from the bzr branch?
[22:34] <pitti> mdke: the attached debdiff
[22:36] <mdke> pitti: rats. Say I wanted to do an upload from the bzr branch, would the best idea be to do a fresh SRU and new changelog entry?
[22:36] <mdke> pitti: there are a couple of revisions which aren't included in the debdiff which would be good to get
[22:36] <pitti> mdke: yes, that's necessary, since it needs a new version number
[22:39] <mdke> pitti: ah, ok. Sorry about that inconvenience. Ok, I'll get the other revisions in at a later stage when doing another translation update or something
[22:39] <mdke> pitti: anyway, I've tested the package and it works fine
[22:39]  * lamont wonders  why the current hardy network mangler(?) keeps disconnecting him from a perfectly good access point
[22:40] <lamont> OTOH, I "fixed" it with a little judicial kill -9 love, applied to nm-applet
[22:41] <ScottK> lamont: When did you update the box last?
[22:41] <lamont> last night
[22:42] <ScottK> I was having trouble like that yesterday, but not last night or today.
[22:42] <lamont> the current update list is just cups
[22:42] <Riddell> zul: you pinged?
[22:42] <TheMuso> cjwatson: well I only have a work-around since the crash is part of the whole race condition stuff I've been talkign with slangasek and crimsun about.
[22:43] <cjwatson> lool: what's the status of xvfb on hppa/powerpc/sparc/
[22:43] <cjwatson> ?
[22:43] <bryce> pitti, slangasect: I've reviewed and cleaned up the patch for targeted lp #274045 to apply to our version of -intel.  Should I upload the package?
[22:43] <lamont> OTOH, I am running a -19 kernel, now that I htink about it
[22:43] <cjwatson> TheMuso: ah, ok
[22:43] <TheMuso> I'll ask the users in the bug to try it, pointing out that it is only a work-around.
[22:43] <cjwatson> lool: if that isn't easily fixed we should disable pygtk's test suites on those architectures so that we can build everything else
[22:43] <lamont> ScottK: I'll reboot here and see if that helps any
[22:43] <TheMuso> slangasek: Upon further thought and digging, to get pulseaudio to try and reconnect to a device requires unloading, and reloading the hal module, which has to then detect everything over again. While this is probably possible, I still need to work out where that has to be done.
[22:47] <slangasek> TheMuso: that sounds... like a bad design.
[22:48] <cjwatson> StevenK: could you please stop NBSing kernel udebs before the new ones are in the archive? :)
[22:48] <TheMuso> slangasek: Yeah, well thats what I've come up with anyway from investigating.
[22:48] <slangasek> bryce: 274045> yes, please
[22:48] <bryce> slangasek: thanks, uploaded.
[22:48] <cjwatson> StevenK: (assuming it was you ...)
[22:48] <slangasek> cjwatson: if that was lpia, that might've been me
[22:48] <cjwatson> lpia, yeah
[22:49] <cjwatson> StevenK: ah, sorry, I just know your deep abiding love for NBS ;-)
[22:49] <slangasek> yeah, sorry, I didn't notice that linux-lpia was completely FTBFS when I did it
[22:49] <TheMuso> slangasek: I'm going to get wider testing of my workaround, but I fear its our best option at this point. I can then talk with upstream as to how we could possibly solve this better for a future release of pulseaudio.
[22:49] <cjwatson> I'm pushing the new one through now
[22:49] <slangasek> TheMuso: oh, I agree, we need to stick with the workaround
[22:49] <slangasek> I think I expressed that a couple days ago :)
[22:50] <TheMuso> slangasek: Yes, but then we weren't sure as to how it could have been done in pulse to reload the alsa module.
[22:50] <mathiaz> Riddell: 14:20 < zul> slangasek: if possible can you kick ec2-ami-tools out of NEW and into multiverse please
[22:50] <mathiaz> Riddell: zul was looking for an archive admin to do that ^^
[22:50] <slangasek> TheMuso: I asked you if you could have it done before the freeze; you said no, so I said no
[22:51] <slangasek> doko: hrm, this sun-java6 upload shows a changelog branched from before the last intrepid upload
[22:51] <TheMuso> yeah but I wanted to be sure that it wasn't as easy as thought, which it doesn't appear to be.
[22:51] <TheMuso> anyway, will get more testing from affected users.
[22:51] <Riddell> mathiaz, zul: that ec2-ami-tools looks fine for universe, why multiverse?
[22:52] <mathiaz> Riddell: I don't know. I heard there was some licensing issues.
[22:53] <doko> slangasek: looking ...
[22:54] <cjwatson> Riddell: is that the one with the licence that says "The Work and any derivative works thereof only may be used or intended for use with the web services, computing platforms or applications provided by Amazon.com, Inc. or its affiliates, including Amazon Web Services LLC."?
[22:54] <cjwatson> Riddell: that's non-free if so
[22:56] <Riddell> cjwatson: so it is, that's a perfectly nice licence apart from that paragraph
[22:56] <cjwatson> Riddell: yeah, otherwise it's basically just BSD
[22:57] <cjwatson> Riddell: although I'm not entirely sure about the patent termination clause - it's quite broad
[22:57] <cjwatson> but given the use restriction I didn't bother to investigate that
[22:57] <doko> slangasek: all changes are merged, just the changelog entries are missing. I'll add these for the next upload
[22:58] <Riddell> mm right.  multiverse it is
[22:58] <slangasek> doko: ok
[22:59] <slangasek> doko: hmm, there seems to be a large delta under debian/ though, which seems like it might be the result of not having the latest Debian merge in?
[23:00] <slangasek> ah, no, because 6-07-4 is a parent of both
[23:02] <doko> diff -Nru sun-java6-6-07/jdk-6u10-dlj-linux-amd64.bin sun-java6-6-10/jdk-6u10-dlj-linux-amd64.bin
[23:02] <doko> --- sun-java6-6-07/jdk-6u10-dlj-linux-amd64.bin 1970-01-01 01:00:00.000000000 +0100
[23:02] <doko> +++ sun-java6-6-10/jdk-6u10-dlj-linux-amd64.bin 2008-10-16 19:19:56.000000000 +0200
[23:02] <doko> do you mean this?
[23:02] <doko> that's the upstream blob
[23:03] <slangasek> no
[23:04] <doko> all ok from my point of view. the last upload to ubuntu had a few *.log files left
[23:04] <slangasek> the debian/ delta turned out to be mostly debhelper log files
[23:07] <cjwatson> slangasek: cdimage shouldn't get stuck if britney happens to hang on a futex now
[23:07] <cjwatson> workarounds 'r' us
[23:07] <slangasek> ok
[23:14] <cjwatson> superm1: rebuilding mythbuntu for you now since that was a casualty of the above
[23:14] <cjwatson> (probably others too, that's just how I spotted it)
[23:38] <slangasek> ScottK: this new kdvi upload ships a /usr/lib/libdjvu.so that doesn't seem to have been in the hardy version of the package
[23:39] <slangasek> ScottK: (and a lot of other files)
[23:40] <ogra> slangasek, there is an lpia-linux-restricted-modules awaiting your gentle approval
[23:41] <slangasek> ogra: I'm aware, thanks
[23:41] <ogra> oh, sorry, didnt want to be pushy ... ;) (meta following as well then)
[23:42] <ogra> just wanted to do my duty before leaving for the evening
[23:43] <slangasek> things you don't want to see in a "security fix":
[23:43] <slangasek> -       if (length_of_file(MINDI_CACHE"/changed.files") > 2) {
[23:43] <slangasek> +
[23:43] <slangasek> +       if (length_of_file("/tmp/changed.files") > 2) {
[23:44] <lifeless> slangasek: well, that looks like its no worse :P
[23:45] <lifeless> slangasek: though the leading whitespace might be a problem :>
[23:45] <slangasek> lifeless: except that now it's been published as part of a CVE so everybody knows it's there :(
[23:45] <lifeless> slangasek: yay
[23:45] <lifeless> slangasek: /sarcasm
[23:47] <TheMuso> 8/c
[23:51] <slangasek> lifeless: bug #216601, if you'd like more entertainment
[23:52] <lifeless> slangasek: OMFG
[23:52] <lifeless> slangasek: all software sucks; some programmers suck more
[23:53] <elmo> wow, that is special
[23:54] <elmo> and not in a good way
[23:57] <StevenK> cjwatson: Yup, it wasn't me this time. :-)
[23:59] <slangasek> kees: who's working on getting the remainder of the v4l transition done?