[00:00] <TheMuso> ah I see.
[00:04]  * TheMuso shudders.
[00:04] <TheMuso> WHy do I hear Windows in this theme?
[00:04] <jono> hey all
[00:06] <LLStarks> themuso, there's a theme ready to go.
[00:06] <LLStarks> people seem to like it
[00:06] <TheMuso> LLStarks: Yes, I saw it in the bug.
[00:06] <TheMuso> LLStarks: Count me out of that group. :)
[00:06] <TheMuso> But it won't be up to me.
[00:06] <LLStarks> mark isn't opposed to the theme
[00:07] <TheMuso> But from that bug, I can't see that he has endorced it either.
[00:07] <RAOF> That's not exactly a ringing endorsement :)
[00:08] <TheMuso> RAOF: Exactly.
[00:11] <elleuca> TheMuso, speaking about FFE, could you please take a look at empathy bug I've linked above?
[00:11] <TheMuso> elleuca: If it needs approval, I can't give it that.
[00:19] <elleuca> TheMuso, it needs some sort of coordination: by now there is a regression in a feature advised by canonical design team. Who can mark a bug as "blocker" for final release?
[00:20] <TheMuso> elleuca: Hrm ok, kenvandine probably is the one who needs to look into it.
[00:21] <bryceh> slangasek, got a sec?
[00:21] <slangasek> bryceh: yep
[00:22] <bryceh> slangasek, we've been debugging 8xx on lucid for a while now
[00:22] <bryceh> we've been able to get it working well for some, but broken for others
[00:22] <bryceh> and are in a situation where it seems fixing it for the latter just ends up breaking it for the former
[00:22] <LLStarks> themuso, who should i speak to regarding the sound theme? who would be responsible for coordinating an implementation?
[00:22] <bryceh> upstream is busily working on the issue but seems pretty insane - see http://cgit.freedesktop.org/~danvet/drm/commit/?h=stuff/i8xx_cache_coherency_for_oga&id=925114122c4bc9864951478e62169e9f34f9d41c
[00:23] <bryceh> slangasek, so at this point we see two choices, and your opinion would be helpful
[00:23] <slangasek> upstream seems pretty insane, or the bug does? ;)
[00:23] <bryceh> a) disable -intel entirely and default to -vesa for this hardware.  People can still opt-into -intel via xorg.conf
[00:24] <bryceh> b) ship the buggy -intel, and releasenote the issues, with a list of workarounds documented
[00:24] <RAOF> slangasek: Have a look at the commit message :)
[00:24] <slangasek> bryceh: how confident are you that VESA won't also break for some as-yet-unidentified subset of users?
[00:25] <bryceh> one factor is when 10.04.1 rolls around, if we went with (a) we could consider turning -intel back on, but at this point it's hard to predict whether upstream will have a 100% working solution for you
[00:25] <bryceh> slangasek, I'm not sure, but in part it's not whether it'll break things but to what degree
[00:26] <bryceh> i.e. they'll lose 3D, proper modesetting, maybe video playback, etc.  Not sure whether suspend/resume works with vesa, etc. etc.
[00:26] <bryceh> so... most likely they'll be able to boot and run Ubuntu enough to look for workarounds
[00:26] <bryceh> enough to open gedit xorg.conf and try switching on intel ;-)
[00:27] <TheMuso> LLStarks: I don't know who is responsible for choosing what goes into the theme, other than Mark. I will likely help with the technical implementation of it though.
[00:27] <slangasek> bryceh: has there been subsequent feedback from users that the git commit you pointed to does *not* solve the problem for them?
[00:28] <bryceh> slangasek, so few people have 8xx that getting solid representative testing has been challenging
[00:28] <RAOF> slangasek: No.  The upstream bug reporters all report that this (finally) fixes it for them.  We haven't tried pulling it into an Ubuntu kernel yet, as far as I'm aware.
[00:28] <bryceh> slangasek, the upstream bug report for this is at https://bugs.freedesktop.org/show_bug.cgi?id=27187 and the tail end of it is *not* filled with happy users saying all is well now
[00:29] <slangasek> bryceh: right, which is one of my concerns with plan a) - if we do try to fix it in SRU, we might not get feedback on the regressions until it's a regression-update bug
[00:30] <bryceh> slangasek, also the description of the patch does not fill me with confidence... he describes it as a hack that "probabilistically" tunes things so it behaves properly according to feedback from the testers so far.
[00:30] <bryceh> slangasek, *nod*
[00:30] <slangasek> bryceh: in which case, I would prefer (by a small margin) to ship it broken in release and release note it so that we can make incremental improvements in SRU with some degree of confidence that we're heading in the right direction
[00:31] <slangasek> oh, though this change means turning DRM back on by default in SRU, doesn't it
[00:31] <bryceh> you mean KMS?  I think that'd be orthogonal
[00:32] <slangasek> er, you're right
[00:32] <slangasek> ok
[00:32] <bryceh> RAOF, your comments?
[00:32] <slangasek> RAOF: and yes, that is a beautiful commit message
[00:33] <bryceh> slangasek, but I think what we'd do is switch DRI back on in the -intel driver (it didn't work around the issues as well as we expected it to, and in fact some people claim it caused further regression for them)
[00:34] <bryceh> with that patch dropped, the user could still toggle it on or off to experiment with if it helps them
[00:34] <RAOF> If you think it'll be better to ship with known issues so it's easier to fix later, then I'll go with that.  We're not *really* sure how widespread this problem is, and it's not a deterministically triggerable bug anyway; getting sufficient testing in -proposed will be difficult if we go with vesa.
[00:34] <slangasek> that's reverting the patch from 2:2.9.1-3ubuntu3 ?
[00:34] <RAOF> Yes.
[00:35] <slangasek> hmm, hate to turn that back on post-RC; also hate to respin all of RC for it
[00:37] <bryceh> well, alternatively we could leave DRI off, and update the patch post-release to allow it to be configurable, although RAOF thought that could be difficult to code
[00:38] <RAOF> Difficult to code without introducing an Ubuntu-specific xorg.conf option, which I didn't want to do in the initial patch.  If we're ok with that, then it won't be too hard.
[00:44] <bryceh> RAOF, I don't have a problem with it
[00:44] <slangasek> bryceh: let me get a feel for where things are with ISO testing; I think we're far enough along that I would prefer to have that DRI reversion made after RC, but still pre-release if we can
[00:44] <bryceh> slangasek, ok
[00:45] <bryceh> RAOF, the one thing would be if we add a parameter we'd need to make sure to include mention of it in the man page
[00:45] <RAOF> bryceh: Right.
[00:46] <bryceh> rickspencer3, ^^ if you're interested, new plan of attack being discussed for 8xx
[00:46] <rickspencer3> I was watching
[00:47] <bryceh> rickspencer3, your thoughts?
[00:47] <rickspencer3> so basically, turn it back to the way it was before, and then let folks having trouble turn it back on?
[00:47] <rickspencer3> well, turn off dri and kms
[00:47] <rickspencer3> am I understanding it?
[00:47] <RAOF> Yes.
[00:47]  * bryceh nods
[00:48] <rickspencer3> so then we ship a cleaner upstream configuration, and then update if there is something we know will help?
[00:48] <rickspencer3> by "cleaner" I mean closer to upstream 2.0
[00:48] <bryceh> basically we'd ship known-buggy 8xx support, with anticipation we may be able to improve things in SRU's and/or .1 updates, and document the heck out of workarounds
[00:48] <rickspencer3> oops 2.9
[00:49] <rickspencer3> bryceh, so, in total, it seems that the mitigations of disabling DRI and KMS made things worse, or at least not better?
[00:49] <rickspencer3> is that your opinion now?
[00:49] <bryceh> well I think we're quite far from "upstream clean" right now
[00:49] <rickspencer3> right, thus the *er*
[00:49] <rickspencer3> ;)
[00:49] <bryceh> rickspencer3, my suspicion is that we shifted the problem rather than reduced it
[00:49] <rickspencer3> like they are testing it with these turned off and such
[00:49] <rickspencer3> ok
[00:49] <RAOF> DRI doesn't seem to have made things significantly better, and also may have regressed things for others.
[00:50] <rickspencer3> so my thoughts are:
[00:50] <rickspencer3> 1. I think slangasek's gut it probably right about this, will take more time that we have to figure out something we *know* will help
[00:51] <rickspencer3> 2. I trust bryceh's judgement about what's help, not helping, and RAOF backs it up
[00:51] <rickspencer3> so, seems like a good plan if we still have time to implement it
[00:51]  * rickspencer3 chalks up lesson of turning knobs, never seems to help xorg-server much
[00:51] <bryceh> heh
[00:51] <elleuca> TheMuso, thanks, I'll poke kenvandine
[00:52] <bryceh> rickspencer3, sometimes it does
[00:52] <slangasek> bryceh: ultimately, are we expecting to turn KMS back on for *all* the intel chips that have been blacklisted in the kernel, or just some of them?
[00:52] <bryceh> rickspencer3, but you're right we're back in a similar situation as we were with -intel in jaunty with all those X freezes, and knob turning ain't doing it for us
[00:52] <rickspencer3> it's like Jaunty, except the scope is *much* smaller
[00:52] <RAOF> I don't think i830 has anything coming along the pipeline that would make us turn KMS back on for it.
[00:53] <bryceh> slangasek, for 8.10 we'll have to.  Either that or stop supporting 8xx with -intel
[00:53] <rickspencer3> and users of 8xx can back up to vesa, and have a respectable level of support consider the vintage of their hardware
[00:53] <rickspencer3> AND there are previous releases that still work well for them
[00:53] <RAOF> slangasek: So, no.  I don't think we'll be unblacklisting all of those cards.
[00:53] <bryceh> rickspencer3, *nod*
[00:54] <RAOF> slangasek: I've obviously interpreted that question differently to bryceh.  I don't think we'll be turning KMS back on *in lucid SRUs*.
[00:54] <slangasek> bryceh, RAOF: ok, if we wouldn't be turning it back on for i830, that means trying to add /etc/modprobe.d/i915-kms.conf back wouldn't be the right solution
[00:55] <slangasek> RAOF: ok - I wasn't sure if re-enabling KMS for i810 was related at all to fixing the problem
[00:56] <bryceh> shall I go ahead and sketch out the release notes entry about this?
[00:56] <RAOF> slangasek: For i855 it's entirely orthogonal.  I'm not sure that it's known what's needed for i845, and I'm not sure that anyone's *working* on i830 :)
[00:56] <slangasek> ok
[00:56] <slangasek> bryceh: written on the assumption that we're keeping intel enabled by default for release, and backing out the DRI patch?
[00:57] <slangasek> (and giving users instructions on how to get to VESA?)
[00:57] <bryceh> RAOF, you seem to already know what to do to add the config option to the dri patch, mind doing that part?
[00:57] <bryceh> slangasek, that's correct
[00:57] <RAOF> bryceh: Certainly.  We're going to keep DRI disabled by default, rather than backing out the patch entirely?
[00:57] <bryceh> either backing out the DRI patch or making it more configurable
[00:58] <slangasek> if we think that's where we're going to end up, I think we should back out the DRI patch rather than adding more knobs
[00:58] <bryceh> RAOF, guess I missed the part of the discussion where we made that decision
[00:58] <bryceh> slangasek, okie
[00:58] <RAOF> bryceh: I did too :)
[00:59] <bryceh> slangasek, ok sounds like a plan
[00:59] <slangasek> it may cause a few more users to regress in final, but we have no idea how many, and it will let us converge more quickly on a resolution in SRU if we don't give them another knob
[00:59] <RAOF> Yes.
[00:59] <slangasek> everyone happy with this plan?
[01:00] <RAOF> I wouldn't go so far as *happy*, but I don't think there is a better one.  +1
[01:01] <bryceh> yeah +1 here too
[01:02] <slangasek> ok
[01:02] <slangasek> thanks, guys :)
[01:03] <RAOF> In a related query - where does checkbox data go?  Could we mine that data to get a better idea of how widespread this problem is?
[01:05] <slangasek> RAOF: if you brought your pickaxe
[01:05] <RAOF> I have a trowel, will that do?
[01:05] <RAOF> :)
[01:05] <slangasek> bdmurray: ^^ who has the access / expertise to help with that?
[01:07] <rickspencer3> oh man
[01:21] <persia> RAOF: You want to catch cr3 to get that data.
[01:24] <persia> slangasek: Are the changes for that likely to result in a new pre-release kernel upload?
[01:35] <slangasek> persia: no
[01:35] <persia> OK.  In that case I won't try to slip anything else in :)
[01:36] <slangasek> I think you just did... :)
[01:37] <bryceh> slangasek: short known-issue blurb added to https://wiki.ubuntu.com/LucidLynx/TechnicalOverview with longer blurb added at https://wiki.ubuntu.com/X/Lucidi8xxFreezes
[01:37] <bryceh> RAOF, please review in case I got something wrong ^^
[01:38] <slangasek> bryceh: could you please add it to https://wiki.ubuntu.com/LucidLynx/ReleaseNotes as well? (Tech Overview stops being used for errata at RC)
[01:39] <bryceh> ok
[01:41] <sbeattie> cjwatson: re bug 558382; it looks like libparted is segv'ing in libparted/label/dos.c on the added DEBUG_CONSTRAINT on the intersection variable.
[01:42] <rafiyr1> General g++ question.  We have a class which appears to have different sizes from the perspective of main and code within inherited classes.  Any thoughts as to why?
[01:44] <RAOF> bryceh: We're not turning KMS back on by default for those cards, are we?
[01:44] <bryceh> RAOF, no
[01:45] <bryceh> RAOF, really it's too late to be making adjustments to the kernel
[01:45] <RAOF> I'll fix up the freezes page, then.
[01:45] <bryceh> thanks
[01:45] <RAOF> (The instructions are currently i915.modeset=0 to turn kms back on ;))
[02:02] <bryceh> slangasek: https://wiki.ubuntu.com/LucidLynx/ReleaseNotes updated
[02:02] <bryceh> RAOF, doh
[02:02] <slangasek> bryceh: thanks!
[02:02] <bryceh> cut-and-paste fail
[02:03] <bryceh> wow, CAB is still listed in the release notes
[02:04] <RAOF> nomodeset no longer does anything, right?
[02:04] <bryceh> RAOF, afaik
[02:04]  * RAOF tests
[02:05] <RAOF> That should be removed from the release notes, then.
[02:05] <slangasek> bryceh: it's new since hardy... :)
[02:05] <slangasek> nomodeset still works
[02:05] <bryceh> slangasek, aha true
[02:06] <slangasek> nomodeset just doesn't override an explicit i915.modeset=1
[02:06] <bryceh> hmm
[02:06] <bryceh> ok, well I should say I've sene people say nomodeset didn't work but i915.modeset=0 did
[02:06] <slangasek> bryceh: that was before I uploaded xserver-xorg-video-{intel,radeon}
[02:08] <bryceh> aha
[02:08] <slangasek> to take out the explicit i915.modeset=1 ;)
[02:08] <sbeattie> cjwatson: ah, yeah, at least the first time through _try_constraint(), ped_constraint_intersect() is returning NULL.
[02:19] <ArneGoetje> bryceh: do you know if there had been any changes regarding i855 chipsets in the latest kernel update? -21 doesn't boot on my machine, while -20 is fine...
[02:21] <RAOF> ArneGoetje: -21 disabled KMS.  Does booting with “i915.modeset=1” on the kernel line help?
[02:21] <ArneGoetje> RAOF: I'll try
[02:21] <bryceh> ArneGoetje, yeah we made some additional changes to try to get things working for more i8xx users
[02:22] <bryceh> we weren't too successful
[02:22] <bryceh> RAOF, ok that's one case so far where KMS actually made it work better
[02:22] <RAOF> :)
[02:25] <ArneGoetje> RAOF, bryceh: yes, turning KMS back on fixes it.
[02:27] <RAOF> Hooray for -intel!
[02:27] <bryceh> *sigh*
[02:27] <bryceh> the -intel merry-go-round
[02:28] <bryceh> ArneGoetje, ok thanks
[02:29] <bryceh> ArneGoetje, not sure if we can update the kernel before release (or if we can, whether we want to) so take that as your workaround for now.  We've documented in the release notes about this.
[02:29] <ArneGoetje> bryceh: ok, noted
[02:45] <bdmurray> slangasek: if there is a hardware database query done for something I'm likely the best person
[02:45] <bdmurray> slangasek: however, I'm heading out the door right now
[03:15] <slangasek> bdmurray: ok - I think RAOF has a question for you about ancient intel chips, then
[03:16] <RAOF> bdmurray: When you get back in :)
[03:18] <ccheney> slangasek: wanted to check on the status of the openoffice.org-dictionaries package waiting?
[03:26] <slangasek> ccheney: the status is "waiting" - is there a particularly urgent fix in there that would justify resetting all the ISO tests for RC?
[03:31] <ccheney> slangasek: no, forgot about us already having spun the discs
[03:32] <slangasek> ccheney: ok.  Do any of these changes affect binary package sizes?
[03:32] <ccheney> heh guess i should have realized that as nothing new downloaded recently
[03:32] <ccheney> slangasek: they shouldn't it just changed some symlinks so possibly a very tiny increase due to that
[03:33] <ccheney> slangasek: seb128 did the actual build so he would be more aware of what the precise difference is
[03:33] <slangasek> ccheney: debian/openoffice.org-thesaurus-fr.install - that doesn't look like symlinks, and seems to be the main fix people are after?
[03:33] <slangasek> ccheney: since seb128 isn't around for several hours yet, would you have time to do a build test of that upload and let me know if openoffice.org-thesaurus-fr changes size and by how much?
[03:33] <ccheney> slangasek: i'll look into it more but i was under the impression from reading what the involved parties said that it was an issue of it being installed with the wrong filenames or something to that effect
[03:33] <ccheney> i can check to see
[03:34] <ccheney> slangasek: is there somewhere i can download his merge from, or i can just redo it, should be fairly trivial
[03:35] <slangasek> ccheney: https://launchpad.net/ubuntu/lucid/+queue?queue_state=1
[03:35] <ccheney> thanks
[03:36] <ccheney> slangasek: alright will let you know what i find out, is deb size the most important thing to check or also installed size, etc?
[03:36] <slangasek> ccheney: both unpacked and packed size are important to know
[03:37] <slangasek> (even though "unpacked size" -> "size on liveCD" is a total fudge factor :/ )
[03:38] <ccheney> ok
[03:43] <un214> About my bug https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/564364
[03:43] <un214> I think I identified a way to know if dpkg "owns" the running kernel
[03:43] <un214> not foolproof, but if our own /sbin/init is pid 1, dpkg probably does
[03:44] <un214> easy to check as root by running stat on /proc/1/fd/exe and /sbin/init
[03:44] <persia> un214: So, how do you know if the currnet /sbin/int is pid 1?  Especially, how can you tell when /sbin/init is binary-identical to /sbin/init outside the chroot?
[03:45] <slangasek> ccheney: oh - it seems openoffice.org-thesaurus-fr doesn't land on any ISOs, so no need to double-check this after all - sorry for taking your time
[03:45] <un214> dev/inode pair of /proc/1/exe will match if true
[03:45] <un214> if not true, then even if binary identical some other dpkg owns kernel
[03:47] <persia> un214: OK.  Now, to ask a more general question, why is this a bug in dpkg?  Why not in update-binfmt?  Should it not detect when the running kernel isn't the filesystem kernel, and perhaps not do something, or do it later?
[03:47] <un214> I listed it as a bug in qemu-kvm
[03:47] <slangasek> right, it's not a bug in "dpkg", it's a bug in the qemu-kvm maintainer script called by dpkg
[03:47] <slangasek> (or, if triggers are involved, then in the package providing the trigger)
[03:48] <un214> I'd be quite glad to provide a /usr/sbin/owns-running-kernel if you wish
[03:48] <persia> Is it?  Or is it a bug in binfmt-support?
[03:48] <un214> (the not foolproof case is a `uname -r` matching kernel with different options on rescue media)
[03:49] <un214> persia: I'm not sure which
[03:49] <slangasek> persia: ah - looking at it, yes, I agree it's binfmt-support
[03:49] <slangasek> (but - most importantly - not dpkg :)
[03:49] <persia> Yeah, dpkg isn't even in control at this point: it doesn't "own" anything.
[03:49] <slangasek> OTOH, qemu-kvm-extras-static has a serious bug in its postinst, it calls 'start procps' :P
[03:50] <un214> I can't even imagine what that would do
[03:50] <slangasek> in a chroot?  it will fail miserably because 'start' tries to talk to a running upstart that it can't reach
[03:51] <un214> in my case it would have found upstart, for the wrong architecture
[03:51] <slangasek> the only stable interface for maintainer scripts to use currently is still 'invoke-rc.d procps start'
[03:51] <slangasek> un214: isn't it running in a chroot?
[03:51] <un214> with most stuff crossmounted
[03:52] <persia> So two bugs: one against binfmt-support (should work in chroot) and the other against qemu-kvm-extras-static (should work in a chroot)
[03:52] <slangasek> I don't think you can crossmount the control socket
[03:52] <un214> mount -bind on the directory works
[03:52] <slangasek> since it's a unix socket that's not exposed in the filesystem :)
[03:52] <persia> At least it's not safe (or sane) to crossmount the control socket
[03:52] <ccheney> slangasek: oh ok
[03:52] <persia> slangasek: You could bind it to a fifo if you *really* wanted :)
[03:53] <un214> if it's not in the filesystem how to programs open it?
[03:53] <persia> un214: unix sockets have their own API
[03:53] <slangasek> persia: hisssss
[03:53] <un214> well if they're not in the filesystem how are they going to respect chroot then
[03:54] <persia> un214: The basic rule is: don't use a socket in a chroot unless it's opened in the chroot.
[03:54] <un214> figured that much
[03:55] <un214> as you know schroot binds /tmp /proc /var/tmp and /home
[03:55] <un214> and /dev
[03:55] <slangasek> un214: they respect the chroot because they have a path which the kernel still interprets *relative* to the current process root, they just don't have paths that are exposed to 'ls' or trivially cross-mountable
[03:55] <un214> hmmm
[03:56] <un214> I'll have to go look up how that works (I'd have guess /proc/1/fd/X) personally
[03:57] <un214> you did know that you can jailbreak if /proc is shared between jails and you have code as same user in both of them right?
[03:58] <persia> That's just one of many ways.  Let's not go over them now :)
[03:58] <un214> ok
[03:58] <persia> But we ought make sure our maintainer scripts work in a way that it's safe to use them in schroot.
[03:59] <un214> I offer the detect program if it would help you any
[03:59] <persia> un214: Actually, what would help best is tracking down unsafe cases (like this one), and adding patches to make them safe to the bugs.
[04:00] <persia> Extra points for getting more involved, and sheparding those patches into the releases, but just finding and fixing them is the key bit.
[04:01] <un214> probably of me finding another is darn low
[04:02] <un214> although I found the grub one awhile back
[04:02] <persia> Most of us only use schroot to build packages, so things not build-dependencies of other things are often missed.
[04:02] <un214> dist-upgrade inside schroot clobbered the system bootloader
[04:02] <persia> grub and qemu-kvm-extras-static both fall into that category.
[04:02] <un214> ah I use it normally
[04:02] <persia> And it shouldn't, especially now that we have decent support for cross-arch schroots.
[04:03] <persia> (at least for armel/powerpc on amd64 guests)
[04:03] <un214> if I get just one more broken driver during apt-get dist-upgrade I'm going to run my whole system in schroot and use core drivers from slackware
[04:05] <un214> I never could figure out any possible fix for the grub one as it actually needs to do that in some cases
[04:22] <un214> incidentally, how to build against klibc?
[04:23] <persia> Set your build depends differently.
[04:23] <un214> ...
[04:30] <un214> apt-get source klibc yielded a GPG error
[04:30] <un214> public key not found
[04:31] <slangasek> a warning, I'm sure
[04:33] <un214> yeah warning
[04:33] <un214> anyway looks like can't link against klibc correctly in the stock packages
[04:34] <un214> or not, just installed funny
[04:35] <un214> ugh too tired making stupid mistakes
[04:35] <un214> good night
[05:41] <Damascene> hi,
[05:42] <Damascene> on offline system there is a need for the software list to be downloaded from ubuntu and then the "generate download script" function of synaptic will do the rest. is it possible to do so?
[05:42] <Damascene> https://bugs.launchpad.net/ubuntu/+source/synaptic/+bug/251378
[05:42] <Damascene> is related
[06:15] <slangasek> robert_ancell: simple-scan> this doesn't look critical for release; I'd like to redirect this to SRU
[06:46] <robert_ancell> slangasek, sure, it is not critical
[06:49] <slangasek> robert_ancell: ok - rejecting, please reupload to -proposed whenever you wish (but please open a bug report about the issue first, and link it in the changelog)
[06:51] <robert_ancell> slangasek, it already is linked to a bug report...
[07:22] <slangasek> robert_ancell: oh, was it?  Hmm, somehow I missed it in the debian/changelog then
[07:24] <Damascene> on offline system there is a need for the software list to be downloaded from ubuntu and then the "generate download script" function of synaptic will do the rest. is it possible to do so?
[07:24] <Damascene> https://bugs.launchpad.net/ubuntu/+source/synaptic/+bug/251378 is related
[07:27] <mdke> pitti: around?
[07:32] <mdke> pitti: nm
[07:37] <pitti> Good morning
[07:37] <pitti> mdke: thanks
[07:37] <pitti> mdke: hello
[07:38] <mdke> pitti: hi :)
[07:38] <baptistemm> hello
[07:38] <baptistemm> good morning
[07:39] <mdke> pitti: I was going to ask you about a bug in pkgbinarymangler but then realised that there is already a report for it
[07:42] <Damascene> hi, I've asked about providing update packages
[07:49] <slangasek> mdke: hey - did you see pitti's question yesterday about disabling the "Report a bug" menu item, and whether this will impact documentation/
[07:49] <slangasek> ?
[07:51] <mdke> slangasek: yes, I said to him that it sounded fine
[07:52] <slangasek> mdke: aha - sorry, was asynchronous so I didn't notice :)
[07:52] <mdke> slangasek: nw. Is this the "Report a problem" help menu item in Gnome applications?
[07:53] <slangasek> mdke: yes
[07:54] <mdke> slangasek: ok, no problem
[07:54] <pitti> mdke: we discussed disabling that on the last UDS, but I totally failed to notice the doc team about that; sorry about this
[07:54] <mdke> pitti: not at all. We don't document bug reporting actually. there is something in the gnome user guide about it but it doesn't mention that menu item
[07:55] <pitti> mdke: right, this is an Ubuntuism anyway
[07:55] <pitti> (launchpad-integration package)
[07:55] <mdke> ah, I see
[07:56] <pitti> mdke: we'll keep the other two (get help online and translate)
[07:56]  * mdke nods
[08:04] <tseliot> pitti: can you approve my nvidia-96, please?
[08:08] <tseliot> the source name is nvidia-graphics-drivers-96A
[08:08] <tseliot> nvidia-graphics-drivers-96
[08:24] <pitti> tseliot: not right now, sorry; this has to wait for post-RC or SRU
[08:25] <joaopinto> good morning
[08:26] <dholbach> good morning
[08:26] <tseliot> pitti: post RC would be better as it's a rather nasty regression that will break at least dist-upgrades
[08:56] <slangasek> tseliot: ah, a fix for that dratted bug that users kept blaming on gdm, excellent... :)  yes, I'll take that post-RC
[08:56] <tseliot> slangasek: yes, that's the bug. Thanks a lot
[08:57] <seb128> slangasek, those my one liner fixes you don't take but other change you do ;-)
[08:57] <seb128> slangasek, hey btw
[08:57] <slangasek> seb128: your one-liners for bugs you yourself marked as 'low'? :-)
[08:57] <seb128> still would avoid me the sru paper work ;-)
[08:58] <seb128> slangasek, btw are lucid-proposed uploads already queued?
[08:58] <slangasek> oh, thanks for pointing out the flaw in our system - I'll design more paperwork for freeze exceptions >:)
[08:58] <seb128> lol
[08:58] <slangasek> AFAIK lucid-proposed is open, yes
[08:58] <seb128> ok thanks
[08:58] <slangasek> if uploading to it doesn't work, let me know
[09:00] <Damascene> I guess you are busy with preparing lucid. so my bug need to wait. right?
[09:05] <slangasek> Damascene: yes, at this time of the cycle most people you find around on IRC have their hands full with other bugs, sorry
[09:06] <Damascene> ok
[09:48] <Koterpillar> How do I make an init script not stop at powering down at all?
[09:56] <pitti> Koterpillar: you mean to not get called on shutdown?
[09:56] <Koterpillar> Yes, not to get called with stop on shutdown
[09:56] <pitti> Koterpillar: do not install symlinks into rc0.d and rc6.d, i. e. do not call update-rc.d with 0 and 6
[09:57] <Koterpillar> They are not there
[09:58] <Koterpillar> In fact, for 0 and 6, there is neither S nor K link
[09:58] <pitti> then the script doesn't get called
[10:01] <Koterpillar> Let me check...
[10:05] <Koterpillar> Well, the script doesn't get called, but someone kills the daemon it starts
[10:09] <slangasek> Koterpillar: sure, /etc/rc6.d/S20sendsigs will
[10:10] <slangasek> there are means for telling sendsigs to skip your process when shutting down, but that's rarely appropriate...
[10:11] <Koterpillar> I want to do exactly that
[10:13] <Koterpillar> So if I'm not an Upstart job, I should register with /lib/init/rw/sendsigs.omit.d/ ?
[10:13] <pitti> slangasek: I uploaded a fixed pkg-create-dbgsym which fixes the missing glib 2.0 dbgsyms (bug 566602); it's all testcase'd, so I'm very confident in that it doesn't cause regressions; the package isn't on any CD/DVD, so it might be okay to accept it? (We'll upload another no-change glib2.0 build after RC then, to get the dbgsyms back)
[10:13] <pitti> Koterpillar: yes, /etc/init.d/sendsigs most probably
[10:13] <pitti> Koterpillar: if you have a daemon which needs to run until the very bitter end, you need to add its pid to /var/run/sendsigs.omit
[10:16] <cjwatson> sbeattie: the segfault itself is information :-)
[10:18] <slangasek> pitti: looking
[10:23] <pitti> slangasek: thanks
[10:33] <cjwatson> sbeattie: actually never mind that comment, the segfault was during initialisation so not so relevant
[10:37]  * hyperair wonders if a kind archive admin could look into syncing nautilus-share (Bug #565418)
[10:42] <pitti> hyperair: not right now, we are frozen for RC
[10:42] <hyperair> pitti: ah. RC.
[10:50] <ogra> mdz, do you still see OOM ? i seem to only get it while rhythmbox plays music here
[10:51]  * ogra had a calm system for the last two days ... just started playing some music and OOM returned
[10:55] <mdz> ogra, I've removed my Google Calendar feed and it seems OK now
[10:55] <ogra> hmm, k, then i probably see a different bug here
[10:56] <ogra> my load bumps above 4 if i change windows ... but i dont see any process consuming a lot of ram
[11:25] <didrocks> I confirm that the google calendar feed is driving evolution nuts here too
[11:26] <seb128> didrocks, what do you call feed in that context?
[11:26] <didrocks> seb128: the calendar account
[11:27] <seb128> didrocks, ok, I've that one configured but I don't notice issues there
[11:27] <seb128> I don't have lot of things in my calendar though
[11:27] <didrocks> seb128: I do have multiple calendars (personel and work one), trying to keep just one.
[12:30]  * ogra dist upgrades to see if rhythmbox stops causing OOM
[12:32] <ogra> seb128, did you hear about any bug relating the above (i havent found the root cause yet, but firing up RB makes it 100% reproducable for me)
[12:32] <seb128> ogra: no, is that armel specific?
[12:32] <ogra> i suspect ubuntuone being at fault
[12:32] <ogra> seb128, nope, its my laptop
[12:32] <seb128> ogra: try turning the store off maybe and see if that's still an issue?
[12:32] <ogra> i commented a lot on bug 563879 to find out its likely a different one
[12:33] <ogra> seb128, will do after the upgrade is run
[12:33] <seb128> don't change to many parameters at one
[12:33] <ogra> the confusing bit is that i cant seem to find anything that actually consumes memory
[12:33] <seb128> ie maybe try without change after upgrade
[12:33] <ogra> but oom clearly kicks in
[12:33] <seb128> then if you still get the issue try without the store
[12:33] <ogra> yes
[12:34] <seb128> do you have free ressources when it kicks in?
[12:34] <ogra> will do it like that and file a new bug if its still there
[12:34] <ogra> yes, htop shows about 800MB being used (from 4G)
[12:34] <ogra> top doesnt show any excerssive ram usage either
[12:35] <ogra> i see my load bumping up between 4 and 5
[12:35] <ogra> but no massive CPU or ram usage ...
[12:35] <seb128> it's weird
[12:35] <ogra> and after a while i see chromium tabs die
[12:35] <ogra> looking at dmesg after that i see they die because of OOM
[12:35] <seb128> do you run package installs during the same time?
[12:35] <ogra> nope
[12:35] <ogra> nothing special
[12:36] <seb128> well that would explain io hits but not ram usage anyway
[12:36] <ogra> i just have three terminals, about ten tabs in chromium, xchat, evo and rb open
[12:36] <ogra> but as soon as rb is playing music my mouse is even hard to move
[12:36] <seb128> weird
[12:36] <ogra> gets jumpy and stuttering
[12:37] <seb128> did you try run iotop to see if it lists something?
[12:37] <ogra> not yet
[12:37] <seb128> try that too
[12:37] <jhernandez1> ogra, i usually have more than 20 tabs in chromium without problems
[12:37] <ogra> i was somewhat on the wrong track looking at mdz's evo bug
[12:37] <ogra> just to find it still happens if i kill all evo processes
[12:38] <seb128> well that happens
[12:38] <ogra> jhernandez1, yes, its not a chromium prob
[12:38] <seb128> let's try to figure what the issue is now
[12:38] <ogra> yeah, i'm waiting for the upgrade to finish
[12:38] <ogra> 10min to go apparently ...
[12:38] <ogra> i wasnt aware there were that many uploads since friday :)
[12:38] <jhernandez1> okok
[12:40] <lamont> so how do I tell whatever gnome is using to authenticate root access to ignore the fact that root has a password, and use sudo anyway?
[12:40] <ogra> lamont, i think you cant do that easily with gksu apps ... policykit might be able to though
[12:41] <ogra> so it depends on the app and whats in the .desktop file
[12:42] <RAOF> ogra: You might be seeing an xorg-server bug where gem objects are leaked; they don't show up in normal memory acccounting.
[12:42] <ogra> RAOF, triggered by what ?
[12:42]  * ogra is curious how RB or pulse or anything in the audio stack could trigger that
[12:43] <RAOF> Triggered by X apps rendering stuff, I think.
[12:43] <ogra> hmm
[12:43] <seb128> ogra: do you have effects on in rhythmbox?
[12:43] <seb128> effects -> visualization
[12:43] <ogra> then RB would have something thats special beyond other apps here
[12:44] <ogra> seb128, i dont think so, and i fear to start it while the upgrade runs
[12:44] <ogra> i'll check asap
[12:44] <seb128> ogra: no hurry, what videocard, driver do you use?
[12:44] <RAOF> ogra: bug #565981 would be what I'm thinking of.
[12:44] <ogra> seb128, intel
[12:44] <lamont> ogra: that makes me very sad
[12:44] <lamont> don't want to give the family the root password, but do want them able to reboot their computer from the gui
[12:44] <seb128> lamont, I don't understand your question
[12:45] <lamont> seb128: sometimes, like say when fsck blows chunks, it's good to have a root password.  so there is one.
[12:45]  * ogra sees vizualizer and art-display being active in gconf 
[12:45] <seb128> right, but that shouldn't change the fact that desktop uses sudo by default
[12:45] <slangasek> lamont: gnome reboots are done via policykit, not asking for a root password, TTBOMK?
[12:45] <lamont> seb128: as a result, many of the gnome apps want the root password, rather than the users password for sudo, for authentication
[12:46] <seb128> no they don't
[12:46] <seb128> we use sudo
[12:46] <lamont> slangasek: if this is fixed in lucid, awesome.  wife has been resisting the move from karmic so far
[12:46] <slangasek> lamont: I think the issue you're seeing is that the user isn't in the admin group, so *their* password doesn't authorize them to policykit
[12:46] <slangasek> oh, or if you're using ancient software, who knows :-)
[12:46] <seb128> lamont, do you have a desktop software example?
[12:46] <ogra> or debian packages in ubuntu :P
[12:47] <lamont> seb128: whatever comes up with the 'machine reboot required'
[12:47] <ogra> they all use su-to-root instead of gksu iirc
[12:47] <lamont> slangasek: and you're right - she's not in admin
[12:47] <lamont> slangasek: OTOH, NFW the kids are going in admin
[12:47] <lamont> slangasek: which means I need to edit which file for policy kit changes on their machines?
[12:47] <slangasek> lamont: policykit is infinitely tuneable; but don't ask me how
[12:47] <lamont> too late
[12:48] <slangasek> take it back, take it back!!
[12:48] <lamont> ogra: you mentioned policy kit first.  ^^
[12:48] <seb128> lamont, what do you want then? not giving them sudo access but still having their password working for admin tasks?
[12:48] <ogra> lamont, there was a gui tool for managing polkit once ... not sure that still exists
[12:48] <slangasek> seb128: for one, *specific* admin task... :)
[12:49] <lamont> sudoers gives them access to the commands in question.  I want it to prompt for their password, not root's
[12:49] <seb128> lamont, what software is that? gksudo prompts for their password I would think
[12:49] <seb128> lamont, but polkit might not
[12:49] <lamont> I'd like to still have them prompted, so they don't fatfinger it and yell at me for _that_
[12:50] <james_w> lamont: the policykit-desktop-privileges might give you some idea of how to use the fine-grained controls to do what you want
[12:50] <seb128> I was going to suggest that
[12:51] <james_w> and pklocalauthority(8)
[12:51]  * lamont gets his wife to get back to the prompt so he can look what's prompting
[12:52] <lamont> meh.  and this time, it rebooted just fine for her from System/shutdown system
[12:52]  * lamont will dig more once she's back in that state
[12:52] <ogra> System/shutdown system ?
[12:52] <seb128> you get asked when an another user is loged in
[12:52] <ogra> heh
[12:53] <seb128> there a known bug where cron tasks count as logged users
[12:53] <ogra> i guess you are missing the right indicator thing here
[12:53] <pitti> re from lunch
[12:53] <seb128> lamont, ^
[12:53] <lamont> well, it doesn't help that I'm generally logged into her computer
[12:53] <ogra> System/shutdown system is the std gnome thing
[12:53] <pitti> lamont: you get asked for auth when shutting down? that's weird
[12:53] <seb128> lamont, well just log 2 users and try to reboot
[12:53] <lamont> ogra: the problem child is the one that handles /var/run/reboot-required, I suspect
[12:53] <pitti> ah, if there's another user logged in, then yes
[12:54] <seb128> lamont, the said dialog is using polkit indeed
[12:54] <lamont> heh.  fsck
[12:54] <pitti> lamont: it's org.freedesktop.consolekit.system.stop-multiple-users privilege, FYI (/usr/share/polkit-1/actions/org.freedesktop.consolekit.policy)
[12:54] <lamont> ok - I'll dig through policykit later then.
[12:54] <pitti> you can allow that to any local user in /etc/polkit-1/localauthority.conf.d/ if you want
[12:54] <seb128> pitti, he wants to allow some users polkit rights without giving them admin rights
[12:57]  * ogra reboots after upgrade
[12:59]  * ogra fires up RB
[13:08] <ttx> ArchiveAdmins: please reject python-rackspace-cloudfiles from New, I'll upload a fixed one
[13:09] <ogra> seb128, so after the update i cant trigger OOM anymore, but that might be because of fresh boot, i'll leave it playing for a while
[13:10] <seb128> ok
[13:10] <ogra> though RAOF seems to be on something here
[13:10] <ogra> ogra@osiris:~$ cat /sys/kernel/debug/dri/0/gem_objects
[13:10] <ogra> 1575 objects
[13:10] <ogra> 623976448 object bytes
[13:10] <ogra> after 10 mins running
[13:10] <ogra> and its rising
[13:16] <seb128> ogra: it could simply be that graphical changes trigger this gem issue and the rhythmbox bar changes every second if you are playing something
[13:17] <ogra> yeah
[13:17] <ogra> ogra@osiris:~$ cat /sys/kernel/debug/dri/0/gem_objects|grep "object bytes"
[13:17] <ogra> 781213696 object bytes
[13:17]  * ogra waits for the system to get choppy
[13:19] <ogra> i think the fact that i dont have swap might also play a role here
[13:22] <mdeslaur> ara: hi! regarding bug #524318, are you getting the en-us keyboard with existing vms or with new ones you create?
[13:22] <ara> mdeslaur, mmm, existing, good point. I will double check with new ones
[13:24] <mdeslaur> ara: cool, thanks!
[13:25] <mdeslaur> ara: you can also simply remove the "Display vnc" component and add it back, and it should default to no keymap
[13:26] <ara> mdeslaur, by the way, I am unable to use network boot in virt-manager now. it always says "no boot device"
[13:26] <mdeslaur> ara: since 0.8.2?
[13:27] <mdeslaur> ara: could you please file a bug with a couple of steps so I can reproduce it?
[13:27] <ara> mdeslaur, I cannot be sure, I hadn't been using virt-manager since I filed that bug
[13:27] <ara> mdeslaur, sure
[13:27] <ara> mdeslaur, will do
[13:28] <mdeslaur> thanks ara
[13:31] <ara> mdeslaur, confirmed that no keymap is forced to en-us on new machines. I will set again to fix released. sorry for the noise
[13:32] <primes2h> ev: mvo: Hello, a fix is available for this bug #535061, are you planning a package update soon by chance so it can be added?
[13:32] <mdeslaur> ara: that's good news, thanks!
[13:32] <mdeslaur> ara: when no keymap is specified, your localized keyboard works 100% in virtual machines, right?
[13:33] <mvo> primes2h: a update to app-install-data-ubuntu?
[13:33] <ara> mdeslaur, trying now
[13:33] <primes2h> mvo: to both app-install-data-ubuntu and usb-creator
[13:33] <ara> ubuntu
[13:34] <primes2h> I mean
[13:34] <mvo> primes2h: hm, usb-creator is more something for ev
[13:34] <primes2h> mvo: you about app-install-data-ubuntu
[13:34] <ara> wrong window :) nice my VM has no sensitive usernames or passwords :D
[13:34] <mvo> primes2h: I plan to do another app-install-data update before -final
[13:34] <mvo> (if the release team lets me :)
[13:35] <ara> mdeslaur, working perfectly fine, thanks
[13:36] <mdeslaur> ara: ok, cool. That was working for me, so I was hoping it was the right approach for all layouts. Thanks!
[13:36] <primes2h> mvo: Ok, thanks! I hope to ;-)
[13:37] <primes2h> mvo: just remember to write that bug down on your todo list ;-)
[13:38] <mvo> primes2h: heh :) will do
[13:42] <primes2h> mvo: btw, do you think that icon needs to be converted in png? it's a svg now
[13:42] <mvo> no, that should be fine
[13:42] <mvo> I think
[13:44] <mvo> yeah, plenty of svg
[13:44] <ev> primes2h: usb-creator> for lucid-updates, definitely.  I don't think it's critical enough to warrant a fix in the lucid release.
[13:49] <ara> mdeslaur, I filed the bug about network booting as bug 567222
[13:50] <primes2h> ev: Sure, I just asked you to know if an update was on the todo list and then save time. ;)
[13:50] <mdeslaur> thanks ara
[14:03] <joaopinto> slangasek, are the "mountall: Plymouth command not found" messages showing up on VT 1 during boot expected ?
[14:05] <slangasek> joaopinto: 'not found', or 'failed'?
[14:05] <joaopinto> ops, sorry, failed
[14:06] <slangasek> joaopinto: probably bug #559761
[14:08] <joaopinto> ok, tks
[14:26] <MacSlow> where's the default locale for gnome/gdm stored?
[14:26] <pitti> MacSlow: /etc/default/locale (that's for everything, not just for GNOME)
[14:26] <pitti> MacSlow: older installations used /etc/environment
[14:27] <MacSlow> pitti, hm... that's stating de and en, which would be ok... but I get "Afghanistan" as the default one... I 'm also not able to login using the root-prompt of grub
[14:27] <MacSlow> pitti, for some reason my locale was changed when I updated my system by console-setup
[14:28] <MacSlow> pitti, I'm trying to fix this since this morning
[14:28] <pitti> MacSlow: are you sure about console-setup?
[14:28] <pitti> recently my /etc/default/console-setup was scrambled by a dist-upgrade, but I haven't found out yet why
[14:28] <MacSlow> pitti, I booted a liveCD to check the usual places... and even there I could ont find any mention of "Afghanistan"
[14:29] <cjwatson> Afghanistan happens to be the first in alphabetical order
[14:29] <pitti> MacSlow: it could just be the alphabetically first entry in the available list
[14:29] <MacSlow> pitti, pure guessing on my side... I didn't pay much attention to the update-process... since I expected by now this would be harmless
[14:29] <MacSlow> cjwatson, pitti: probably
[14:30] <cjwatson> the only recent change in c-s was a translation update, though
[14:30] <pitti> cjwatson: right, that's why I didn't quite believe that this was the culprit
[14:30] <pitti> coudl be the existing magic in the postinst, of course
[14:30] <MacSlow> cjwatson, pitti: I only don't get why even passing locale=de_DE on the kernel boot-options line doesn't even allow me to log in using grub's root-prompt
[14:30] <pitti> I have changed /e/d/console-setup countless times while I was working on the keyboard fixes in gdm/gnome
[14:31] <pitti> since nobody else complained I just scribed it off to my own stupidity
[14:31] <MacSlow> cjwatson, pitti: if you've any trick up your sleeve to work-around this, I'd be more than happy to hear :)
[14:31] <pitti> MacSlow: can you paste your complete /e/d/locale somewhere?
[14:31] <MacSlow> pitti, that's going to take some time
[14:31] <pitti> MacSlow: so your keyboard is fine, it's really your language whic his broken?
[14:31] <MacSlow> pitti, but I can do that
[14:32] <pitti> MacSlow: i. e. your system is in English now? (since I suppose you don't have language-pack-af installed)
[14:32] <MacSlow> pitti, well... e.g. if I boot normally and switch from gdm to a VT... I cannot see anything I typed in at the login-prompt
[14:32] <pitti> MacSlow: or s/paste/tell us how it looks/ -> it should at most have $LANG and $LANGUAGE
[14:33] <cjwatson> MacSlow: I doubt that your login prompt is related to your locale problem
[14:33] <cjwatson> s/prompt/problem/
[14:33]  * MacSlow boots desktop-box via liveCD and mounts root-partition manually to get the /e/d/locale
[14:33] <pitti> MacSlow: ok, where do you actually see "Afghanistan"?
[14:33] <cjwatson> oh, unless you mean that you can't log in because the keyboard is horked
[14:33] <pitti> MacSlow: at this point I think we need some more precise description
[14:33] <MacSlow> pitti, it's written in italics in the language-selection of gdm
[14:33] <cjwatson> MacSlow: "locale" is separate from keyboard layout, that's why that makes no difference
[14:33] <cjwatson> try pressing alt+shift to toggle to US layout
[14:33] <MacSlow> pitti, there's also USA and German
[14:33] <pitti> MacSlow: on the left or middle combobox?
[14:34] <pitti> MacSlow: "USA" is a keyboard layout, not a language
[14:34] <MacSlow> pitti, middle
[14:34] <pitti> MacSlow: ah, that _is_ the keyboard layout
[14:34] <pitti> MacSlow: please check your /etc/default/console-setup
[14:34] <pitti> I ended up with
[14:34] <pitti> XKBLAYOUT="us,de"
[14:34] <pitti> XKBVARIANT="nodeadkeys,nodeadkeys"
[14:34] <MacSlow> cjwatson, pitti: rebooting
[14:34] <pitti> i. e. it somehow duplicated the "nodeadkeys"
[14:34] <cjwatson> unfortunately by the time this happens to somebody (/etc/default/console-setup broken) the evidence of why it happened has usually been erased
[14:34] <pitti> which completely broke the keyboard
[14:35] <pitti> and I'm fairly sure that console-setup's postinst had something to do with it, but I haven't had time since last Friday afternoon to investigate this thoroughly
[14:35] <pitti> but now that it happened to someone else, it's probably time to do so
[14:37] <MacSlow> pitti, cjwatson: pressing Alt
[14:38] <MacSlow> pitti, cjwatson: pressing Alt+Shift at the gdm-screen doesn't seem to change the keyboard-layout (I still see my text-entry cursor on the right side of the GtkEntry)
[14:38] <pitti> on Friday I tried apt-get install --reinstall console-setup a couple of times, but weren't able to replicate the breakage
[14:38] <MacSlow> odd...but logging in worked
[14:38] <MacSlow> phew
[14:38] <MacSlow> at least I'm back at my normal desktop
[14:39] <MacSlow> pitti, cjwatson: now checking things (and pasting) should be a lot easier
[14:39] <pitti> MacSlow: ok, please give output of grep ^X /etc/default/console-setup
[14:41] <MacSlow> pitti, https://pastebin.ubuntu.com/419258
[14:41] <MacSlow> pitti, there's the af
[14:41] <MacSlow> pitti, I guess I change that to de again?!
[14:41] <pitti> eww
[14:41] <pitti> yes
[14:42] <pitti> but this is completely different breakage than what I had
[14:42] <pitti> MacSlow: but regardless of that you should have been able to change the layout in gdm
[14:42] <MacSlow> pitti, anything else?
[14:42] <mdz> ScottK, Riddell: any update on https://wiki.kubuntu.org/Kubuntu/UpdatesPolicy for the TB meeting today?
[14:43] <Riddell> mdz: not as yet I'm afraid
[14:43] <MacSlow> pitti, I could change it... but only the hint regarding Alt+Shift made it possible to login again (although the GtkEntry still rendered text being entered from right-to-left)
[14:43] <pitti> MacSlow: saving your /var/cache/debconf/config.dat could come in handy for post-mortem debugging
[14:43] <mdz> cjwatson, any update on libfaac? does it need action before 10.04?
[14:44] <pitti> MacSlow: and the current (i. e. broken) version of /e/d/console-setup
[14:45] <mdz> cjwatson, ah, just saw your email, never mind
[14:46] <MacSlow> pitti, do you want both files via email?
[14:46] <pitti> uh, I do see a potential gotcha there -- /var/lib/dpkg/info/console-setup.postinst seems to overwrite the default file with values from debconf
[14:46] <mdz> pitti, cjwatson won't make it to TB, and I don't know about Keybuk (he's UTC-7 still). are you planning to attend?
[14:46] <pitti> MacSlow: better attach them to a bug
[14:46] <MacSlow> pitti,
[14:46] <pitti> mdz: I am, yes
[14:46] <MacSlow> ok
[14:47] <MacSlow> pitti, against which package should I file it? console-setup (if that's even a package)?
[14:47] <pitti> MacSlow: that'll do for now, yes
[14:47] <lool> Would someone please sync libhildonhelp from unstable to fix its FTBFS in Ubuntu?  (it's in universe and not on any ISO)
[14:48] <lool> I can't get requestsync to take it from Debian for some reason
[14:48] <MacSlow> pitti, prio: High?
[14:48] <lool> v 2.0.5-4
[14:48] <pitti> MacSlow: I don't know the scope of this yest
[14:48] <pitti> yet
[14:48] <cjwatson> mdz: it's next on my guilt list after this horrible partitioning bug - but I don't see anything in the archive with the prohibited linkage
[14:49] <cjwatson> so since my impression is that it seems to be distributable but not co-linkable with ffmpeg, I think 10.04 is OK.  But I will check
[14:49] <MacSlow> pitti, you can change it later anyway
[14:49] <cjwatson> pitti: overwrite> it's complicated, and has installer tentacles
[14:49] <cjwatson> even if it is broken, if it's more or less a corner case my inclination would be to leave it as it is for 10.04
[14:50] <pitti> cjwatson: yeah, that's why I asked about saving config.dat, so that we keep the traces
[14:50] <pitti> cjwatson: *nod*
[14:50] <cjwatson> mdz: won't make it> sorry again - am buried in thousand-line debug files full of sector numbers :-/
[14:51] <mdz> cjwatson, no worries. there's nothing urgent on the agenda, and we may end up skipping it if we don't get a quorum. 10.04 is higher priority as usual
[14:51] <mdz> cjwatson, let me know if you want another pair of eyes
[14:52] <pitti> cjwatson: I'm still not able to replicate it, though; it by and large seems to work fine
[14:52] <cjwatson> mdz: thanks.  at present, bringing somebody else up to speed would probably lose time but I'll see how it goes
[14:58] <MacSlow> pitti, cjwatson: LP: #567254
[14:59] <MacSlow> pitti, cjwatson: if you need further info about it, just tell me
[14:59] <pitti> MacSlow: thanks for filing
[14:59] <MacSlow> pitti, cjwatson: I'll reboot and see if everything is back to normal (also the input-direction of GtkEntry at the gdm-screen)
[15:02] <seb128> cjwatson, ev: ubiquity used to ask if you really want to continue when typing a weak password and doesn't now, bug or design choice?
[15:02] <ev> seb128: design choice
[15:02] <seb128> ev: thanks
[15:02] <ev> seb128: it now lets you know inline if your password is weak
[15:03] <seb128> right, I'm not sure if it used to do both, I though it was showing the info but still asking for confirmation before so I figured I would ask to check
[15:08] <mdz> directhex, /join #ubuntu-meeting if you're around
[15:22] <ScottK> mdz: Not yet.
[15:23] <alexp_sssup> hi everyone, I'd like to ask if there is any documentation about including new projects in the core ubuntu. I am the maintainer of the lightspark project (which is a modern flash player implementation). In the current status lightspark is good enough to render youtube videos, even the Flash10 version that are totally not supported by gnash. I think my project has a great potential, and I'd...
[15:23] <alexp_sssup> ...like to start working to get it into the next ubuntu release in 6 months.
[15:33] <mdz> directhex, minutes sent to ubuntu-devel and TeamReports
[15:33] <directhex> mdz, okay, ta. btw your latest blog post has a broken <a>
[15:34] <mdz> directhex, another one?  I fixed one already
[15:35] <directhex> ah, planet hasn't noticed
[15:47] <thebishop> https://lists.launchpad.net/asus-ul30/msg00125.html -- is there an official bug for this issue?  I searched and didn't see one
[15:47] <thebishop> can't tell if it's a problem with all Intel 4500MHD, or just the Asus UL line
[15:50] <Ng> thebishop: bug #538648
[15:52] <thebishop> Ng, the symptoms sound very similar, but i can confirm that it happens without compiz
[15:53] <thebishop> Ng, in the list discussion i pasted, they suggest it's a problem with DRM
[15:56] <Ng> thebishop: I'm not sure, I'm just one of the people affected by the bug :)
[16:02] <thebishop> Ng, when it's not happening, this seems like a great release of Ubuntu... haha
[16:02] <thebishop> when it happens in succession, i want to cry
[16:03] <awilkins> Is the DRM a different thing to Digital Rights Management, I'm seeing the acronym a lot in things like kernel logs and not really believing that Linux is in league with the MPAA?
[16:04] <cjwatson> Direct Rendering Manager
[16:04] <cjwatson> http://dri.freedesktop.org/wiki/DRM
[16:04] <cjwatson> the acronym clash is slightly unfortunate
[16:46] <geser> pitti: because it's not very clear for me from the summary about "syncing from testing": how should I set the default in requestsync for maverick: sync from unstable or sync from testing?
[16:47] <pitti> geser: it's not yet clear to me either yet :) there doesn't seem to be a strong preference either way, but I think we should go back to unstable, since (1) maverick is that post-LTS "crack" release, and (2) Debian will freeze soon
[16:56] <barry> james_w: any chance you're around?  i have a question about bzr import-dsc cli options
[16:57] <james_w> hi barry
[17:00] <barry> hi james_w.  i think there's a discrepancy about the --distribution option to import-dsc.  the online docs say 'bzr import-dsc --distribution debian .../scruff.dsc'
[17:01] <barry> james_w: but 'bzr import-dsc --help' does not mention --distribution, and import-dsc doesn't accept that option
[17:01] <barry> james_w: it also doesn't let me say 'debian' as the first arg
[17:01] <barry> james_w: so, is it still necessary to specify the distribution when doing import-dsc?
[17:01] <james_w> barry: I think the docs are out of date
[17:01] <barry> james_w: ftr, i am trying to sync the latest debian package with an ubuntu package
[17:02] <james_w> barry: and the lp:debian/* branch isn't up to date?
[17:02] <pitti> "Accepted tzdata 2010i-1" -- oh no, not again
[17:03] <barry> james_w: ah, it might be
[17:04] <barry> james_w: it is.  i'll merge debian->ubuntu using that.  but just ftr, is the distribution unnecessary for import-dsc now?
[17:05] <james_w> barry: yes
[17:05] <james_w> barry: just committed to correct the docs, thanks
[17:06] <james_w> all that matters now is which branch you commit it on to, if you commit it on to what you consider to be the "debian" branch then you are saying it was an upload to Debian
[17:07] <james_w> it's all in the interpretation though, and there is no data stored about that any more, so we don't need the argument
[17:07] <james_w> I should have deprecated it rather than removing it though, sorry
[17:07] <barry> james_w: no worries, that's fine.  so if i'm working on an ubuntu branch and want to pull in the debian dsc (say, lp:debian isn't updated yet), then it will Just Work?
[17:08] <james_w> you should grab the lp:debian branch, import the package on to that, and then merge the result
[17:08] <james_w> if you import the debian upload on to the ubuntu branch then it won't merge any Ubuntu changes
[17:09] <james_w> shortcuts you may see in that description are there for the taking if you want
[17:10] <barry> james_w: gotcha. thanks.  thanks again for a great tool.  i added a link on the wiki page to the file:/// docs - there's lots of excellent material there. :)
[17:10] <james_w> great, thanks
[17:19] <mkarnicki> I want to file a bug report about Remote desktop settings window. against what package should I file it?
[17:20] <ArneGoetje> slangasek: I'd like to drop the xfonts-wqy dependency from language-support-fonts-zh-han{s|t}, since wqy-microhei and wqy-zenhei are more popular nowadays than the bitmap font. Is it okay to get that change in for Lucid? I would submit it to the queue together with the language-support-fonts-ja update...
[17:22] <nigelb> mkarnicki, Next time, asking #ubuntu-bugs, where you might get a faster response.  the package is vino.
[17:22] <mkarnicki> nigelb: noted. thanks!
[17:29] <slangasek> ArneGoetje: there doesn't seem to be much practical benefit to dropping the dependency for lucid, the packages are only on the DVDs?
[17:30] <ArneGoetje> slangasek: except reducing the amount to download for Chinese users
[17:32] <slangasek> ArneGoetje: hmm, true; though it's a 6MB reduction vs. a 21MB download - if you can download 15MB, is downloading another 6MB that burdensome?
[17:32] <ArneGoetje> slangasek: heh... we can leave it for maverick, no problem
[17:33] <slangasek> ArneGoetje: ok, let's do that :)
[17:33] <ArneGoetje> slangasek: ok, then I'll upload the changes for language-support-fonts-ja now.
[17:33] <slangasek> ArneGoetje: cheers!
[17:34] <ArneGoetje> slangasek: uploaded.
[17:35] <ArneGoetje> slangasek: fontconfig changes in language-selector will follow later tonight
[17:49] <Keybuk> slangasek: too many bugs are fixed/worked around by putting plymouth back into the initramfs :-/
[17:52] <joaopinto> Keybuk, before filing a a wishlist bug, shouldn't initctl have an enable/disable service command, or you don't thin is the proper place to do it ?
[17:54] <Keybuk> yes, it should
[17:54] <cody-somerville> cjwatson, for LP #567270, which seed would I add the package to?
[17:55] <ogra> supported /me thinks
[17:55] <Keybuk> joaopinto: bug #94065
[17:56] <Keybuk> slangasek: oh, wow, I just saw your patch on plymouth@l.fd.o - awesome
[17:56] <Keybuk> slangasek: do the watch-for-keypress stuff still work then if show-splash isn't called first?
[17:59] <joaopinto> Keybuk, ah, great
[17:59] <Keybuk> joaopinto: I'm basically thinking that services can be in one of three modes
[18:00] <Keybuk> automatic
[18:00] <Keybuk> manual
[18:00] <Keybuk> upgrade
[18:00] <Keybuk> in automatic mode, Upstart manages their life time
[18:00] <cjwatson> cody-somerville: supported-installer-common
[18:00] <Keybuk> in manual mode, only "start" and "stop" etc. will work
[18:00] <Keybuk> in upgrade mode, nothing works
[18:00] <joaopinto> upgrade means locked ?
[18:00] <Keybuk> yes, locked out for a package upgrade
[18:00] <Keybuk> "this software is being changed on disk - don't touch it"
[18:00] <cjwatson> ogra: few packages go in supported directly any more
[18:01] <Keybuk> upgrade may mean the service is stopped when you put it in that mode
[18:01] <ogra> cjwatson, yeah, i just noticed that there are more fine grained files now
[18:01] <Keybuk> or may mean that the service is locked (won't respawn, failures not reported) and restarted when unlocked
[18:01] <Keybuk> may offer both
[18:01] <ogra> i havent looked at seeds for a while
[18:01] <cjwatson> it was a nijaba thing for hardy
[18:01] <ogra> ah
[18:02] <ogra> (at least not beyond desktop and netbook files)
[18:02] <joaopinto> Keybuk, is there an option to start a service but blocking it from emitting events ? It could be useful when you want to try a specific job individually
[18:02] <Keybuk> joaopinto: not sure that would work
[18:02] <Keybuk> that would mean, for example, the pre-start and post-stop scripts wouldn't get run
[18:15] <joaopinto> I need to get more familiar with upstart scripts first, but I guess you may want to test a specific job without triggering the subsequent events chain
[18:15] <joaopinto> without having to manually edit the script for that
[19:10] <bladernr> Can anyone tell me if there is a way to determine whether a system has woken from suspend-to-ram via a specific method (either keypress, acpi alarm, or WOL packet received?)
[19:10] <bladernr> hoping -devel is the right place to ask
[19:32] <joaopinto> Keybuk, bug 530179, isn't a bit abusive to set the bug as duplicate when the person clearly reported that mountall failed to mount the filesystem ?
[19:35] <joaopinto> as he commented later, the issue is not only about the missing prompt (the duplicate bug) but the fact that the filesystem was not mounted
[19:43] <joaopinto> Keybuk, do you mind if I set the bug to incomplete and try to reproduce it and collect more data ?
[19:45] <joaopinto> virtualbox is available from the repositories, even if it's not a mountall bug it may apply to a universe package
[20:01] <joaopinto> actually /sbin/mount.vboxsf is available from a package, now let's see if it mounts on boot
[20:37] <adiroiban> bdrung: hi, can you review a MP for ubufox or should I ask asac ? it's regarding bug 564589
[20:38] <genii> Could anyone please tell me what values correspond to what states in /sys/bus/usb/devices/*/power/autosuspend  file? I can't seem to find this info anyplace
[20:39] <bdrung> adiroiban: i think asac is the right person for that, because he is upstream.
[20:41] <adiroiban> bdrung: ok. thanks
[21:04] <crimsun> genii: -kernel, really. Anyhow, static int usb_autosuspend_delay = 2;           /* Default delay value, * in seconds */
[21:04] <crimsun> genii: drivers/usb/core/usb.c
[21:07] <genii> crimsun: OK, thanks
[21:08] <highvoltage> qense: did you perhaps add my name next to debian-installer on https://wiki.ubuntu.com/BugSquad/AdoptPackage#Small%20and%20Medium%20Packages ?
[21:09] <qense> highvoltage: if your name is there it was there already when I pasted the list from the old page
[21:11] <highvoltage> qense: ah ok. I can't remember doing that but I'll subscribe to the bug mail and go through it's list of known bugs, I guess I might as well adopt it fully :)
[21:11] <qense> highvoltage: If you'd want to do that, please do so.!
[21:26] <asac> adiroiban: done
[21:26] <adiroiban> asac: thanks :)
[21:29] <josip> Hello, I am not sure if this is right channel to ask the question, so I hope it won't mind you if it isn't. Is there a nobackfill patch for ubuntu lucid?
[22:19] <Keybuk> joaopinto: sure, if you want to debug it go ahead
[22:19] <Keybuk> though it's definitely not a mountall bug, so change the package to none
[22:19] <joaopinto> Keybuk, already identifyed the problem
[22:19] <Keybuk> what is it?
[22:19] <joaopinto> it depends on a kernel module which is loaded later
[22:19] <joaopinto> which is provided by an univer package
[22:20] <Keybuk> ah, fail
[22:20] <joaopinto> I just left mountall because I am not sure how it should be handled from a packaging perspective, I mean, for the other package
[22:20] <joaopinto> are kernel modules loaded before mountall ?
[22:21] <Keybuk> no
[22:21] <Keybuk> we have no boot phase where "kernel modules are loaded"
[22:22] <joaopinto> ok, so currently there is no support for modular filesystem support ?
[22:22] <joaopinto> ops, redundancy :P
[22:22] <Keybuk> it's up to the module to arrange for itself to be loaded
[22:22] <Keybuk> usually this is something like:
[22:23] <Keybuk>   SUBSYSTEM=="block", ENV{ID_FS_TYPE}="...", RUN+="modprobe ..."
[22:23] <Keybuk> but that only applies where the block device is visible
[22:23] <Keybuk> it may be as simple as the virtualbox stuff needs an upstart job
[22:23] <Keybuk>   start on starting mountall
[22:23] <Keybuk>   exec modprobe vboxsf
[22:23] <joaopinto> ok, I will add that o the bug report and remove mountall
[22:24] <joaopinto> does "starting" guarantee that the job is invoked prior to the mountall start, or is it executed in parallel ?
[22:24] <Keybuk> I've already commented to that effect
[22:25] <Keybuk> guarantees provided it also uses "task"
[22:25] <Keybuk>   start on starting mountall
[22:25] <Keybuk>   task
[22:25] <Keybuk>   exec modprobe vboxsf
[22:25] <Keybuk> is probably more correct ;-)
[22:25] <joaopinto> ok, this is also a good change for my first upstart job :)
[22:25] <joaopinto> chance
[22:27] <joaopinto> is Debian using upstart already ?
[22:29] <ScottK> ccheney: Did you run into something like Bug 567536 before?
[22:30] <ccheney> ScottK: probably haven't looked yet, but mvo is having to work around it in update-manager as it appears to be some sort of really hard to fix bug in apt pre-depends resolving
[22:31] <ccheney> ScottK: and fixing it in OOo is non-trivial, we added one thing to help and then it needed another, etc
[22:31] <ScottK> ccheney: I got that bug using update-manager, so whatever it is, seems to be incomplete.
[22:31] <ccheney> ScottK: i'm not sure if mvo has applied the change yet, aiui he was going to make it uninstall binfilter along with some other bits and then reinstall after the upgrade process
[22:32] <ScottK> THanks.
[22:32] <ccheney> np
[22:32] <ScottK> I'll paste that in the bug then.
[22:35] <trijntje> Hi all, are any empathy developers present? I'm translating empathy but i'm not sure about the meaning of some strings
[22:50] <joaopinto> Keybuk, http://pastebin.com/5tMKVZZz, looks sane ?
[22:53] <Keybuk> yeah though lose the script/end script
[22:53] <Keybuk> also worth adding -b to the modprobe call
[22:53] <Keybuk> so that it can be blacklisted without modifying the job
[23:25] <slangasek> Keybuk: yes, the keypress watches are installed unconditionally already, they don't look for show_splash
[23:25] <Keybuk> slangasek: what's looking for the key presses then?
[23:25] <Keybuk> I thought the terminal and keyboard, input, etc. weren't created until a renderer is loaded
[23:25] <Keybuk> (on show splash)
[23:27] <slangasek> Keybuk: oh, you were asking whether the keypress would be /registered/ before splash was up - no, sorry
[23:28] <slangasek> so /proc/bus/usb is still going to be a problem
[23:31] <svu_> pitti, ping?
[23:33] <Keybuk> *shrug*
[23:33] <Keybuk> either we put plymouth in the initramfs
[23:33] <Keybuk> or just release note that you should check your /etc/fstab
[23:34] <ion> Could we check fstab on upgrade?
[23:36] <joaopinto> a broken fstab resulting in an unbootable system looks really bad
[23:36] <ion> (Re: his quit message) Are getdeb packages still packaged so that maintscripts create and delete stuff in $HOME/Desktop etc? :-P
[23:37] <joaopinto> ion, don't worry, they don't hurt more than a random Ubuntu package
[23:49] <ScottK> If that's true, it's progress.
[23:55] <joaopinto> the "be respectful" is not something that comes easy to everyone
[23:55] <joaopinto> good night
[23:55] <ScottK> joaopinto: You site used to recommend removing all getdeb packages before upgrade.  I didn't check if it still does.
[23:56] <ScottK> So my statement is nothing but factual.