[03:32] <poolie> bryceh: don't suppose you're here?
[04:00] <RAOF> poolie: Could a fellow Xer help instead?
[04:45] <poolie> hi
[04:45] <poolie> RAOF: i'm trying to localize the change that fixes bug 745112
[04:46] <poolie> i was hitting a snag that there is no single git revision chain between the natty and oneiric kernels
[04:46] <poolie> afaics
[04:46] <poolie> so you can't bisect between them and build packages all the way
[04:46] <poolie> i was just going to go back to building with a plain 'make'
[04:47] <TheMuso> /c/c
[04:47] <RAOF> Yeah.  That's one of the awkwardnesses of the kernel team's git usage.
[04:48] <RAOF> I'd do what you're doing; nab the upstream kernels, build with the oneiric configuration, and run a “git bisect drivers/gpu/drm”
[04:51] <RAOF> If Sarvatt were up you could possibly farm the job of building kernels off to him, what with his 10 minute kernel build machine and all :)
[04:51] <poolie> something seems sad with ecryptfs on my laptop now anyhow
[04:52] <poolie> so you're pretty sure bisecting just the changes on that directory will be enough?
[04:56] <RAOF> That's where all the GPU driver code is; it's where all the modeswitching code is.
[04:57] <RAOF> It's possible that the code was broken by an change elsewhere in the tree, but drm is moderately well isolated from the rest of the kernel.
[05:13] <LLStarks> siretart, what's the best way to request packaging updates that full under your jurisdiction for both ubuntu and debian?
[05:13] <LLStarks> *fall
[05:25] <LaserJock> anybody know a wiki page or something that describes how to get a bzr branch of debian packages?
[05:26] <StevenK> LaserJock: bzr branch lp:debian/<sourcepackage> ?
[05:26] <LaserJock> ah, that would maybe work :-)
[05:27] <LaserJock> I tried lp:debian/unstable/<sourcepackage> and that didn't work
[05:27] <StevenK> debian/sid/<sourcepackage>
[05:28] <LaserJock> ahhh
[05:28] <LaserJock> I thought there was a way to do it, but I'm a bit rusty
[06:35] <pitti> Good morning
[06:38] <poolie> hi pitti
[06:38] <StevenK> Hai pitti
[06:40]  * pitti waves to Australia, how are you?
[06:40] <StevenK> Cold! Send warmth!
[06:41] <RAOF> StevenK: Hah!  *You* think you're cold? :)
[06:43] <StevenK> RAOF: But 14 is cold!
[06:43] <RAOF> You and your double digit centigrade temperatures
[06:44] <StevenK> RAOF: It's what, 7, down there?
[06:44] <RAOF> My phone thinks it's 9.
[06:51] <bryceh> poolie, heya
[06:52] <bryceh> it got suddenly too hot here today.  I'll box some heat up and send down to you StevenK
[06:52] <StevenK> bryceh: <3
[06:54] <poolie> hi bryceh
[06:54] <poolie> bryceh: i'm trying to  narrow down that bug
[06:55] <poolie> i hit bug 793367 on the way, which was a bit distressing
[06:56] <bryceh> poolie, icky
[06:56] <bryceh> poolie, RAOF's advice is pretty much what I'd suggest.  git bisects are sometimes quite a slog, sorry
[06:56] <poolie> is bisecting just on that directory pretty sure to find the problem?
[06:57] <poolie> at the moment i'm doing it over the whole tree which is obviously going to be longer
[06:58] <RAOF> I, obviously, think it's quite likely to find the problem; it'll probably save you 2 or 3 kernel builds, too.
[06:58] <bryceh> I would agree; these types of bugs are generally drm
[06:59] <bryceh> or I should say, I don't think I've ever seen one that was in some area of the kernel other than drm
[07:00] <slangasek> bryceh: nooo I was using that heat
[07:00] <RAOF> Oh, yeah.  The problem of ‘my monitor turns black when trying to attach the second display’ is certainly drm.  The only concern is whether it's drm+some change outside there, like to the VM code or acpi.
[07:02] <poolie> you know the last time i rebuilt a kernel to try to get hardware working was probably before i installed warty
[07:03] <poolie> in fact that was the main reason i did install warty
[07:05]  * slangasek chuckles
[07:07] <bryceh> yeah, when do we teach Launchpad how to do bisection searches for us?
[07:07] <poolie> wow
[07:07] <poolie> you know, if it could populate a ppa-like thing with the relevant packages
[07:07] <poolie> and collect the feedback
[07:07] <bryceh> yep
[07:07] <poolie> that would be pretty cool
[07:07] <bryceh> poolie, ppa's can only have one version of a package though
[07:08] <StevenK> So you create multiple PPAs and switch between them
[07:08] <poolie> well
[07:08] <RAOF> That's not strictly speaking true.
[07:08] <StevenK> It would be messy, but doable
[07:08] <poolie> i think the limitation to a single version is an implementation limit, not an essential limit
[07:08] <RAOF> You *can* have multiple versions of a package, they'll just get pruned after a while.
[07:08] <poolie> deb archives can have multiple versions
[07:08] <poolie> i think ppas prune a bit too aggressively
[07:08] <poolie> there is a bug about this
[07:09] <poolie> it would be useful if people could get old versions, either to satisfy dependencies or by explicitly asking
[07:09] <bryceh> poolie, it'd be way awesome
[07:09] <lifeless> so does the primary archive
[07:09] <lifeless> anyhow, there are bugs
[07:09] <lifeless> and it would be nice to permit select ppas to be more flexible
[07:09] <bryceh> I did a prototype a while ago, just for xserver, and had users use it to bisect things.  Didn't solve many bugs but the users found it real keen
[07:10] <bryceh> I just pre-built .debs for every version in git and tossed it in a web directory; was pretty easy
[07:10] <bryceh> but git history can be non-linear, which tripped me up at transition points.  Someone better versed in VCS logic could probably do something cleaner
[07:11] <poolie> it's especially nonlinear here because, in line with typical git rebasing practice, there is no real relation between the natty and oneiric kernels
[07:11] <bryceh> right
[07:13] <poolie> oh thanks for being the lp stakeholder btw
[07:17] <bryceh> poolie, sure thing
[07:24] <bryceh> aha there's the scripts http://people.canonical.com/~bryce/xorg-bisect/
[07:28] <bryceh> lifeless, what are "select ppas"?
[07:30] <tjaalton> poolie: you could just try the mainline kernels, there are builds for all the rc-versions too
[07:30] <tjaalton> and "bisect" using them first
[07:33] <poolie> bryceh: that's an idea
[07:33] <poolie> bryceh: my first build of it has hung with a flashing caps lock
[07:33] <poolie> should i just skip that one?
[07:33] <bryceh> yep
[07:33] <poolie> tjaalton: from http://kernel.ubuntu.com/~kernel-ppa/mainline/ ?
[07:34] <StevenK> That's a panic, isn't it?
[07:34] <bryceh> poolie, yep
[07:34] <tjaalton> poolie: yep
[07:34] <bryceh> yes, it's a panic
[07:34] <poolie> well
[07:34] <poolie> i suppose i'm wondering if it's likely to be actually broken, or misinstalled/misconfigured
[07:34] <bryceh> unfortunately not uncommon when bisecting
[07:34] <Sarvatt> it sure was nice having months of daily mainline builds available to "bisect" with
[07:34] <tjaalton> poolie: though .39-rc2 failed to build, but the diff between it and rc3 was small, drm-wise
[07:36] <bryceh> poolie, it's not unlikely that you just lucked out on picking a git version that was severely broken
[07:36] <bryceh> RAOF, would he need to rebuild initrd?
[07:37] <StevenK> Yes, the modules would have changed
[07:37] <RAOF> Yes.
[07:37] <poolie> i did do update-initramfs and modules_install
[07:37] <bryceh> ah ok
[07:37] <StevenK> In that order?
[07:37] <poolie> no :)
[07:37] <StevenK> Right :-)
[07:37] <poolie> hm, i think no
[07:37] <siretart> LLStarks: I'd prefer a wishlist bug in debian, but launchpad would work equally well.
[07:37] <poolie> i'll try some of the builds timo suggested
[07:38] <tjaalton> poolie: so the bug is fixed in some known version?
[07:38] <LLStarks> siretart, gotcha
[07:38] <poolie> yes it seems fixed in 2.6.39-3
[07:39] <tjaalton> try .39-rc1 first, it got >80 commits to gpu/drm/i915..
[07:39] <poolie> k
[07:46] <poolie> ok, rc1 works better but not completely
[07:46] <poolie> rc4 seems to work completely
[07:51] <lifeless> bryceh: as opposed to all ppas
[07:54] <bryceh> lifeless, ah gotcha.  yes agreed.
[07:54] <poolie> and rc3 also seems ok, hooray
[07:55] <poolie> bryceh: so eventually is this going to need to come down to one patch(set) to be backported into 2.6.38?
[07:57] <bryceh> poolie, ideally yes
[07:57] <RAOF> That's the plan.  If you can find a single patch, hurray!  It sounds like it might require a bunch, though, which is less hurray.
[07:57] <poolie> ftr yes, i did modules_install before building the initramfs
[07:57] <poolie> so now git bisect skip?
[07:57] <bryceh> sometimes though you will get it down to some odd revision number that seemingly has nothing to do with your problem, but then we tell one of the upstream devs and it gives them a clue into what's really wrong
[07:58] <RAOF> If that one's panicking, yeah.
[07:59] <bryceh> or, like RAOF says, it'll point to one of a set of patches that'd all need backported, which can get messy
[07:59] <bryceh> but the kernel team usually can help us out if that happens
[08:00] <tjaalton> there are already eight patches for sandybridge under evaluation, but looks like they are not quite enough
[08:00] <tjaalton> from .39
[08:03] <lifeless> how good/bad is sandybridge in natty?
[08:03] <lifeless> (I have a new sandybridge desktop coming...)
[08:04] <RAOF> I understand that it's pretty good, generally.
[08:04] <RAOF> Better in many respects than arandale in Natty.
[08:04] <StevenK> Which one is Arandale?
[08:04] <bryceh> i'm on sandybridge (but with ati gfx) for my main desktop.  has been pretty solid
[08:04] <RAOF> (Suggesting that it is perhaps better to skip on the first generation of any intel hardware)
[08:05] <RAOF> Arandale is the GPU on the first Core iX chips.
[08:05] <RAOF> So, like lifeless' x201.
[08:05] <lifeless> bryceh: cool; I've ordered an nvidia card, will see how it goes
[08:05] <bryceh> lifeless, sandybridge gfx seems to be a little hit or miss; there's upstream fixes that seem important but came out too late for natty inclusion
[08:05] <tjaalton> with .39 it's better
[08:05] <tjaalton> as always
[08:06] <bryceh> yeah
[08:06] <cdbs> Did someone mention SandiBridge
[08:06] <cdbs> *Sandy
[08:06] <cdbs> I'm running X from xorg-edgers on Oneiric, and the SandyBridge GPU issues are fixed
[08:06] <cdbs> bryceh: ^
[08:07] <cdbs> lifeless: ^
[08:07] <lifeless> thanks guys
[08:07] <cdbs> lifeless: Well with the X in Natty, its nearly perfect
[08:07] <lifeless> I shall wait with bated breath to nuke the windows install and drop on natty ;)
[08:07] <cdbs> lifeless: there's some lag when you type in OpenGL text fields
[08:07] <cdbs> lifeless: but if you use xorg-edgers all those are fixes
[08:08] <cdbs> *fixed
[08:08] <lifeless> cdbs: thats with the onboard graphics option though, right ? which I won't be using.
[08:08] <poolie> lifeless: what did you buy?
[08:08] <cdbs> lifeless: hmm yeah, that's with the integrated thing
[08:08] <cdbs> and I'm unlucky enough to have an nvidia card in my laptop but being unable to use it
[08:08] <lifeless> poolie: a dell desktop, i7-2600, 16GB, couple of disks for mirroring
[08:09] <cdbs> because of the optimus switching thing which works only on windows, and gives ubuntu only the integrated sandybridge GPU
[08:09] <cdbs> lifeless: So make sure you don't end up with an Optimus configuration, in case :)
[08:09] <lifeless> poolie: so 2GB of ram per hardware thread, and 8 threads.
[08:10] <RAOF> cdbs: You can't get an optimus desktop :).  Or, rather, I don't believe the windows drivers will let you optimus-ify a nvidia+intel desktop; it'd be entirely possible to do, though.
[08:11] <cdbs> RAOF: Ah yeah, he said *desktop*. Okay then. But still, Optimus is a hell to play with
[08:11] <RAOF> cdbs: The switcheroo code can't turn on your nvidia chip?  Sucks.  Hybrid graphics is a swamp of per-laptop madness.
[08:11] <cdbs> RAOF: Its a mess because in Linux, the nvidia card is on, draws power from the battery, but can't be used, not even with the official drivers
[08:11] <cdbs> RAOF: switcheroo does work, but the end result is a dark screen. Why? lemme tell
[08:12] <RAOF> If switcheroo works it should at least be able to power *off* your discrete card.  Maybe :)
[08:13] <cdbs> RAOF: In an Optimus configuration, the GPUs are arranged like: nVidia -> Intel -> Monitor. The nvidia card doesnt have a graphics controller. If you use switcheroo, the driver talks to the nvidia card, writes to the intel card, which gets turned off by switcheroo, hence resulting in nothing coming to the monitor, except for a black screen
[08:13] <cdbs> RAOF: yes, I'm able to power off, that's all that can be done.
[08:13] <RAOF> cdbs: Correction: in *your* Optimus configuration :)
[08:13] <RAOF> Other laptops differ :)
[08:13] <cdbs> RAOF: Nope. in *AN* optimus configuration
[08:14] <cdbs> RAOF: Its common amongst all optimus laptops. If its in some other way, its other hybrid technology and not Optimus. there's an article on the nouveau wiki about this
[08:14] <cdbs> RAOF: http://nouveau.freedesktop.org/wiki/Optimus
[08:15] <RAOF> cdbs: Well, there are some optimus laptops where the nvidia is hooked up to HDMI out & the intel is hooked up to the internal display; there are others where both the intel & nvidia card can drive any display, and there's a hardware mux between them.
[08:16] <RAOF> If you're lucky enough to have a hardware mux, then switcheroo will actually be able to switch between your graphics cards.  As long as you kill X in between.
[08:16] <RAOF> If you don't have a hardware mux, sucks to be you.
[08:16] <cdbs> Or switch to Wayland and avoid all the X switching trouble :)
[08:16] <RAOF> Laptops are made of madness.
[08:16] <cdbs> RAOF: no, there's no mux here :(
[08:18] <RAOF> Yeah.  You're outta luck.  Although switcheroo *should* be able to turn off the nvidia card, leaving your intel card to do the output.  That's probably worth a bug report if it doesn't work.
[08:18] <StevenK> RAOF: But usually, the madness is so little and cute.
[08:18] <cdbs> "the madness is so little and Qt" :D
[08:19] <StevenK> RARGH, I forbid my quotes to be twisted that way.
[08:21] <dholbach> good morning
[08:44] <LLStarks> morning.
[08:46] <LLStarks> does the desktop team have any recommendations for how the x team should handle fallback? i'm wondering about the appropriateness of uniy2d for failsafex sessions as well using gnome-panel as a user-chosen fallback.
[08:49] <RAOF> What's the problem with unity2d for fallback?
[08:54] <didrocks> LLStarks: FYI, I answered to your email on the desktop ML
[09:18] <seb128> hum, libcanberra depending on the fdo sound theme, that seems wrong
[09:18] <pitti> and a + .5 MB CD hit :/
[09:19] <Daviey> mvo: What is the correct way to add a package to Unattended-Upgrade::Package-Blacklist ?
[09:24] <poolie> RAOF, bryceh, rc4 shows some visual corruption coming out of suspend, but switching to vt1 and back fixes it
[09:24] <mvo> Daviey: just on a local system? or as part of a package install (if part of a packages its best to add via e.g. /etc/apt/apt.conf.d/75_blacklist_foo
[09:24] <poolie> so, what's next?
[09:24] <poolie> if bisecting will help you a lot i can do it
[09:25] <ohsix> poolie: intel?
[09:25] <poolie> yes
[09:25] <mvo> Daviey: depending on what package I can also add to unattended-upgrades itself (if its a package that is known to be problematic)
[09:25] <Daviey> mvo: a package asks for confirmation via debconf before removing via prerm, and blocks u-u.
[09:25] <RAOF> poolie: corruption out of suspend sounds likely to be a different problem.
[09:25] <RAOF> poolie: So, the bisection thus far has said “somewhere between -rc3 and -rc4 is where it starts working reliably”?
[09:25] <Daviey> mvo: bug 791522
[09:26] <mvo> Daviey: hrm, what package is that? u-n sets the debconf frontend to noninteractive
[09:26] <poolie> no, between rc1 and rc3
[09:26] <mvo> Daviey: ok, thanks, let me have a look
[09:26] <Daviey> mvo: thanks!
[09:28] <RAOF> poolie: With rc2 failing to build.  Ok.  rc1-rc3 should be enough to narrow commits down a bit.  If you *want* to bisect that would be useful, but this might be the point where some patches could be plausibly implicated by inspection.
[09:29] <poolie> can you tell me which repo has the source most closely corresponding to them?
[09:29] <poolie> repo and or tags
[09:31] <RAOF> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git , sadly.
[09:31] <RAOF> I believe the kernel mainline builds are built from throw-away git branches, which are then promptly thrown away.
[09:32] <poolie> hm
[09:32] <poolie> and i could just copy their config into .config?
[09:32] <RAOF> Yeah.
[09:33] <pitti> tkamppeter: FYI, rejecting your two cups uploads to natty-proposed; please merge them into one upload or use -v to include the topmost two changelogs
[09:33] <RAOF> I think Andy's awake, and hasn't had his mouth filled with bees yet.  You could probably ask him in #ubuntu-kernel whether he can spin up some builds for you.
[09:34] <pitti> SpamapS: would you have time for some SRU processing today? I'm doing some as well, but I put a hard stop after 90 minutes to not eat up too much of my daily time
[09:35] <poolie> RAOF: how do i bring the tags from that into my existing git repo?
[09:35] <poolie> i thought git fetch would do it
[09:35] <poolie> but no?
[09:35] <poolie> oh nm
[09:36] <RAOF> You need to “git fetch -t”?
[09:36] <RAOF> *may* need to.
[09:44] <poolie> so for this i should mark the ones that _do_ show the bug as 'good', and the working ones as bad?
[09:44] <poolie> since 'good' is really hardcoded to mean 'too early'?
[09:45] <TLE> pitti: hey, my apologies for not notifying you last week when we decided to postpone the lang pack update, I forgot :(
[09:45] <pitti> maco: rejecting your mini-dinstall natty-proposed upload; can you please reupload with proper LP: #XXXX syntax?
[09:45] <pitti> TLE: which update?
[09:46] <TLE> pitti: the second natty lang pack update
[09:46] <pitti> TLE: we need one now, for the firefox update
[09:47] <TLE> yeah, so it turned out all right anyway. We pushed the update that was supposed to start last week to start this week
[09:50] <cjwatson> kees: I updated ubuntu-meta to match your platform.oneiric/standard change
[09:51] <cjwatson> smoser: merging rsyslog> my thoughts are that somebody who iss't me should do it, carefully
[09:51] <cjwatson> *isn't
[09:51] <infinity> cjwatson: There are a whole lot of people who aren't you.
[09:51] <RAOF> poolie: Yup.
[09:53] <soren> sed -e 's/Dave Chapelle/Colin Watson/' http://www.thebestpageintheuniverse.net/images/chappelle_graph2.gif
[09:53] <soren> infinity: Can't argue with graphs.
[09:53] <poolie> RAOF: should i clean between builds, or can i count on the makefile deps being safe enough?
[09:54] <cjwatson> micahg: MoM disregards blacklisted packages; but if a package was previously in MoM, then blacklisted, MoM won't remove it.  ask me or file a bug on merge-o-matic if you have a package that's stale in that way
[09:54] <RAOF> poolie: I believe that kernel developers bisect enough to make not-cleaning a safe operation :)
[09:54] <infinity> soren: The Internet scares me.
[09:57] <geser> more scaring is that soren has found such a graph
[09:58] <cjwatson> soren: hah
[10:03] <pitti> cjwatson, soren: rsyslog> ah, this version is still utterly broken :/
[10:04] <pitti> I know I have a bug assigned to it, I didn't get to doing this yet, sorry
[10:05] <debfx> cjwatson: would it be possible to change ownership of the kubuntu seed branches from core-dev to kubuntu-dev?
[10:09] <jfi> Hello, the package sync from debian is not automatic except for the first version? or it takes more than 2 weeks? I wonder if this is normal that a package has not been synced since the 22may or if there is an issue
[10:13] <cjwatson> debfx: when I last asked about that, the consensus was that core-dev was still more appropriate; if that's changed, I'd like confirmation from a couple of other Kubuntu people (ScottK, Riddell?)
[10:13] <cjwatson> jfi: it's generally automatic, but it depends slightly; what package are you talking about?
[10:13] <tkamppeter> pitti, I will continue collecting CUPS SRUs, bringing it on par with Oneiric, then add a comment to all four bugs telling that the SRU is for all these four bugs. I have also found that one bug is still not completely fixed. When I have found this remaining fix I will add it to the BZR and ask you to upload it. After that I will put up the collected SRU.
[10:14] <jfi> cjwatson, package in LP: https://launchpad.net/ubuntu/oneiric/+source/psensor
[10:14] <jfi> cjwatson, package in debian: http://packages.qa.debian.org/p/psensor.html
[10:14] <cjwatson> jfi: it's been modified in Ubuntu, and therefore needs to be merged manually
[10:14] <jfi> cjwatson, yes, I need a specific build-dep for ubuntu
[10:14] <cjwatson> jfi: in fact, it looks like you modified it?
[10:14] <cjwatson> jfi: I'm not sure what you expect to happen automatically, then
[10:15] <cjwatson> the automatic systems aren't artificially intelligent - once stuff has been changed intentionally on both sides, they defer to human judgement
[10:15] <jfi> cjwatson, well it could be merged
[10:15] <cjwatson> you'll find https://merges.ubuntu.com/universe.html lists psensor as an action for you to merge
[10:16] <cjwatson> https://wiki.ubuntu.com/UbuntuDevelopment/Merging
[10:16] <jfi> cjwatson, ok, so for each version, I open a bug and request the sync and the merge of the control file?
[10:16] <cjwatson> syncing and merging are two different things - you only do one
[10:17] <infinity> jfi: No bugs or syncing required, you just merge the new version with the changes and upload.
[10:17] <cjwatson> syncing is for when you want to throw away Ubuntu changes and use the Debian change - https://wiki.ubuntu.com/SyncRequestProcess
[10:17] <cjwatson> I don't think jfi has upload privileges
[10:17] <jfi> infinity, unfortunely I cannot upload, I need to request it
[10:18] <cjwatson> in which case you need to open a bug, yes.  https://wiki.ubuntu.com/UbuntuDevelopment/Merging has details
[10:18] <tkamppeter> Any Avahi expert here?
[10:18] <jfi> cjwatson, ok thanks for the hint, I am going to read
[10:21] <debfx> cjwatson: aha, I didn't know about that. I'll discuss it with the other kubuntu devs
[10:33] <tkamppeter> Anyone knows how to check whether a DNS-SD service emits a service subtype?
[10:48] <pitti> tkamppeter: sounds good
[10:53] <pitti> hmm, I thought last week's desktop dailies were at 715 MB
[10:53] <pitti> now it's back to 722 :/
[10:56] <pitti> ah, we added libwebkitgtk-3.0-0
[10:56] <pitti> (7.1 MB)
[10:57] <seb128> pitti, joy of a dual gtk stack...
[10:59] <pitti> seb128: rsyncing today's CDs to check the remaining rdepends of libwebkitgtk-1.0-0
[10:59] <pitti>  
[10:59] <seb128> pitti, libubuntuone for the music store, shotwell
[11:00] <seb128> shotwell will not likely go to gtk3 this cycle
[11:00] <seb128> pitti, software-center as well I guess
[11:00] <pitti> and webkit 3.0 for empathy apparently?
[11:00] <seb128> yes
[11:01] <seb128> will be used in yelp as well once we build it with gtk3
[11:01] <pitti> I have no idea at all how to free yet another 7 MB :-(
[11:01] <seb128> drop spanish from the CD...
[11:01] <pitti> we could perhaps build empathy with gtk2 as well
[11:01] <infinity> I was going to suggest English...
[11:01] <janimo> is there a wikipage with which shipped apps still need to transition to gtk3 ?
[11:02] <seb128> pitti, no way
[11:02] <seb128> pitti, the nautilus-sendto integration needs to be on the same version that nautilus
[11:03] <janimo> pitti, would building empathy with gtk2 result in smaller footprint?
[11:03] <seb128> pitti, we are trying to move things away from gtk2 not to go backward
[11:03] <seb128> janimo, well it mean it would not break a second webkitgtk on the CD
[11:03] <janimo> ouch
[11:03] <seb128> break->bring
[11:03] <janimo> did not realize both webkits are there too
[11:03] <seb128> that's what bring <pitti> ah, we added libwebkitgtk-3.0-0
[11:03] <seb128>  (7.1 MB)
[11:04] <janimo> right, I did not know webkit-2 was there
[11:04] <pitti> we have had webkit/gtk2 for quite a while (lucid or so?)
[11:04] <seb128> webkit is used by the music store (libubuntuone), the software-center, yelp
[11:04] <seb128> empathy
[11:04] <seb128> shotwell
[11:05] <seb128> gwibber (but that will be fixed)
[11:05] <seb128> ubuntu-sso-client
[11:05] <pitti> apturl
[11:05] <janimo> I did not realize those were not ported to a newer one. Seems very much work. Is Fedora and other GNOME 3 shipping distro in this same position?
[11:05] <seb128> yes
[11:06] <seb128> pitti, realistically we will need to have both versions on the CD, the rdepends will not be all ported this cycle
[11:07] <pitti> ok
[11:07] <seb128> downporting empathy would be quite some work and it would hit issues for desktop integration parts like nautilus
[11:08] <pitti> so our remaining fallback is to drop Spanish and Portugese, and just keep English and Simplified Chinese
[11:08] <janimo> seb128, porting an app to gtk3 and webkit 3 must happen in a single step ?
[11:09] <seb128> janimo, there is no webkit-3 there, it's webkit-gtk2 or webkit-gtk3
[11:09] <seb128> i.e same code but built with different gtk version
[11:09] <janimo> ok
[11:09] <seb128> you can't use 2 gtk version sin the same process
[11:09] <seb128> so the webkit version you use needs to be using the gtk that your application
[11:18] <tkamppeter> pitti, I have found the solution for the remaining problem. I will do another commit to the CUPS BZR later today and after that prepare one SRU (with one version number advance) for all outstanding bugs.
[11:19] <tkamppeter> pitti, is there a CUPS still in the -proposed queue? If yes, which version? So that I know the next free one.
[11:20] <pitti> tkamppeter: I rejected them all; you can use 1.4.6-5ubuntu1.2
[11:20] <pitti> tkamppeter: as 1.4.6-5ubuntu1.1 is in natty-updates at the momemt
[11:24] <tkamppeter> pitti, thanks.
[11:32] <tkamppeter> pitti, Oneiric part done, you can upload the CUPS package from the Debian BZR.
[11:38] <Laney> could someone please score haskell-quickcheck up?
[11:39] <Laney> I may have accidently uploaded some stuff which depends on it being built
[11:42] <infinity> Laney: Done.
[11:42] <Laney> cheers
[11:50] <tumbleweed> any archive admins planning to look at new packages from Debian any time soon? Someone was asking me when golang will appear (there isn't an explicit sync request)
[11:52] <pitti> tumbleweed: golang is sync-blacklisted, it won't appear
[11:53] <pitti> tumbleweed: Gustavo said that the Debian package should not be released, as it's contrary to how upstream would like to ship this
[11:53] <tumbleweed> pitti: ah, thanks
[11:55]  * tumbleweed wishes blacklisting was more visible on LP
[11:56] <pitti> tumbleweed: http://people.canonical.com/~ubuntu-archive/sync-blacklist.txt
[11:56] <tumbleweed> yes, I know, but I can't keep its contents in my brain :)
[12:02] <ScottK> debfx: I don't recall why Kubuntu branches are owned by core-dev.  I think it would be good if you could start a thread on kubuntu-devel so we can discuss this if you want it changed.
[12:03] <debfx> ScottK: I've added it to the meeting agenda
[12:03] <ScottK> debfx: I think it's more of a kubuntu-dev question than a kubuntu-council question, so I think some advance discussion would still be good.
[12:04]  * cjwatson wonders if he can find IRC logs about that discussion
[12:06] <ScottK> That would be useful.
[12:07] <cjwatson> hmm, discussion from #ubuntu-devel on 2009-12-10 seems to indicate that you guys already said you wanted the seeds to be owned by kubuntu-dev, and I acknowledged
[12:08]  * cjwatson tries to see if there was something later that countermanded that
[12:14] <cjwatson> ScottK: http://irclogs.ubuntu.com/2009/12/10/%23ubuntu-devel.html#t21:17
[12:15] <cjwatson> ScottK: should I consider that an old todo item and Just Do It?
[12:15]  * ScottK reads
[12:16] <cjwatson> the bit about LP was a red herring
[12:16] <ScottK> cjwatson: I think so.
[12:17] <ScottK> debfx: ^^^ Looks like you can take it off the agenda.
[12:17] <ScottK> No wonder I couldn't remember a reason why it should stay core-dev.
[12:18] <cjwatson> I think my memory may have been from the predecessor to kubuntu-dev
[12:18] <cjwatson> which was sort of a general packagers team rather than an upload-privileges team
[12:19] <ScottK> Makes sense as we have one of those.
[12:24] <cjwatson> ScottK,debfx: pushed lp:~kubuntu-dev/ubuntu-seeds/kubuntu.oneiric - can you let committers know to start using that instead?
[12:24] <ScottK> cjwatson: Thanks.
[12:25]  * cjwatson goes round updating references
[12:25] <ScottK> debfx: Would you please mail kubuntu-dev about this?
[12:26] <cjwatson> how about kubuntu-mobile?
[12:26] <ScottK> Yes.  That one too.
[12:26] <debfx> ScottK: can do
[12:27] <cjwatson> ScottK: kubuntu-dev as well, or some other team?
[12:27] <ScottK> I think kubuntu-dev.
[12:29] <chrisccoulson> @pilot in
[12:31] <cjwatson> pushed, will update references to that too
[12:31] <cjwatson> ScottK,debfx: ^-
[12:31] <ScottK> Thanks again.
[12:32] <cjwatson> FWIW, the references I know about are in the cron job on people.canonical.com that updates the seeds mirrors (~ubuntu-archive/bin/update-seeds), cdimage/bin/run-germinate, and tasksel/ubuntu-seeds.pl
[13:03] <cjwatson> ScottK,debfx: should be all done now
[13:08] <apw> pitti, something is odd with lucid and maverick proposed for linux
[13:08] <apw>      linux | 2.6.38-10.44 | lucid-proposed | source
[13:08] <apw>      linux | 2.6.38-10.44 | maverick-proposed | source
[13:08] <apw>      linux | 2.6.38-10.44 | natty-proposed | source
[13:09] <apw> and linux-meta for that matter
[13:18] <pitti> apw: err, WTF
[13:21] <pitti> hmm hardy seems to have worked
[13:22] <smb> pitti, Question is whether it is unf**ble
[13:24] <pitti> we can (and should) certainly remove the faulty 2.6.38 versions from  l/m-proposed, doing now
[13:24] <pitti> question is, how did that happen in the first place
[13:25] <smb> pitti, Good that it can be undone. Then investigation can be done a bit more relaxed
[13:25] <apw> pitti, you might want to check the linux-meta on maverick and natty as well
[13:25] <pitti> apw: you mean s/natty/lucid/?
[13:25] <apw>      linux | 2.6.38.10.24 | maverick-proposed | amd64, i386
[13:25] <apw>      linux | 2.6.38.10.24 | natty-proposed | amd64, i386
[13:25] <apw> pitti, i mean those two they look wrong in rmadison output
[13:27] <pitti> apw: isn't 2.6.38.10.24 what is meant to be in natty? *confused*
[13:27] <smb> pitti, Just checked at least for lucid and there is only a 2.6.32 package of linux there
[13:27] <apw> pitti, heh yes probabally sorry getting jumpy :)
[13:28] <smb> pitti, I mean checked in the canonical-kernel-team ppa
[13:29] <pitti> yes, it was the copying which went wrong, not the PPA
[13:29] <smb> pitti, Right, it seemed unlikely but I wanted to make sure
[13:30] <pitti> l-b-m looks ok
[13:31] <pitti> linux-ports-meta is wrong in lucid
[13:32] <pitti> oh, I bet it's how copy-proposed-kernel.py calls syncSources
[13:33] <pitti> https://launchpad.net/ubuntu/+source/linux looks better now
[13:33] <tkamppeter> pitti, the SRU (5 at a time) is ready now.
[13:34] <tkamppeter> pitti, bug 711779, bug 782309, bug 790378, bug 792309, bug 793265.
[13:34] <pitti> tkamppeter: thanks
[13:34] <pitti> https://launchpad.net/ubuntu/+source/linux-meta cleaned up
[13:34] <pitti> https://launchpad.net/ubuntu/+source/linux-ports-meta cleaned up
[13:35] <pitti> smb, apw: ^ I think all faulty versions are removed nwo
[13:35]  * pitti now goes to copy the correct versions and fix copy-proposed-kernel.py
[13:36] <cjwatson> can it actually be undone properly?  wouldn't we need LP assistance to wind versions backwards later?
[13:36] <smb> pitti, Thanks. Right and find out whether you are allowed to do those copies now
[13:36] <cjwatson> (which, for the record, I'd approve of doing in -proposed)
[13:36] <pitti> that's what I'm afraid of as well; let's check
[13:37] <pitti> copy-package.py for lucid linux succeeded, anyway
[13:37] <pitti> https://launchpad.net/ubuntu/+source/linux will take some 20 minutes to actually make it appear, though (it only shows published versions)
[13:38] <smb> So we'll look back in 20min or so
[13:44] <ScottK> Shows right away on https://launchpad.net/ubuntu/+source/linux/+publishinghistory
[13:47] <pitti> ah, nice
[13:48] <zyga> is there a way to have per-dist .pbuilderc?
[13:49] <zyga> I'd like to have a feedback loop where I can feed my repository with new packages
[13:49] <zyga> and do this per-distribution with pbuilder-dist
[13:50] <zyga> or should I scrap the concept and script this with pbuilder + custom configs + appropriate options to load them
[13:53] <ScottK> siretart: If you have a moment, would you please have a look at https://bugs.kde.org/show_bug.cgi?id=274666 - We're suffering from this problem in Ubuntu as well and could use a bit of help with porting to the current libav.
[13:55] <pitti> apw, smb: all copies done; https://launchpad.net/ubuntu/+source/linux/+publishinghistory etc. look good now
[13:56] <apw> pitti, do you think we'll have problems uploading to the PPA now with a 'lower' version number or is that ok
[13:57] <pitti> apw: none of this affected the PPA at all, so no
[13:57] <pitti> the problem was that the PPA's natty versions accidentally got copied to lucid-/maverick-proposed
[13:57] <smb> Looks good so far. Thanks.
[13:57] <pitti> I fixed copy-proposed-kernel.py now, my bad *brown paperbag*
[13:58] <pitti> so far this apparently worked because we had one release staged up only
[13:58] <apw> pitti, thanks sounds good
[14:08] <pitti> I sent a mail to u-d-announce@ about that (how to check and recover from the situation)
[14:15] <stgraber> bdrung, cody-somerville, persia, geser: ping (DMB meeting in #ubuntu-meeting)
[14:23] <siretart> ScottK: that enum has been renamed. use AVMEDIA_TYPE_VIDEO instead of CODEC_TYPE_VIDEO
[14:24] <ScottK> siretart: Thanks.  I'll try that.
[14:25] <siretart> ScottK: in 0.6, the type CodecType was already deprecated. 0.7 now removes quite a number of types that were already deprecated in 0.6. The AVMediaType seems to be the most often used one
[14:26] <ScottK> siretart: Is there some handy list I can look at if we hit other issues?
[14:27] <siretart> ScottK: http://anonscm.debian.org/gitweb/?p=pkg-multimedia/libav.git;a=blob;f=doc/APIchanges - that files is also installed in the libavcodec53 package in usr/share/doc...
[14:28] <ScottK> siretart: Thanks.
[14:29] <siretart> ScottK: if you find some other API breakage that was not deprecated in 0.6, then I'd cosider it as a bug in libav and would fix that in the 0.7 series
[14:29] <ScottK> siretart: I'll let you know.
[14:29] <siretart> thanks
[15:33] <didrocks> doko: hey, it seems that we have an issue with Qt and gcc 4.6 making unity-2d crashing at when showing an expose-like event (places, scale, worspace switcher…): https://bugs.launchpad.net/ubuntu/oneiric/+source/qt4-x11/+bug/791213 do you have any idea how we can help debugging that?
[15:33] <hallyn> question on ubuntu's gcc and FORTIFY_SOURCE.  The manpage says that to disable the default (=2), use -D_FORTIFY_SOURCE=0.  But when I (or actually, configure) do that, gcc complains that it is redefined.
[15:33] <saamm> hello, I am having a weird problem in Ubuntu 11.04. I disabled Automatic login and now 'Ubuntu' logs me into classic gnome. Earlier I was getting Unity interface.
[15:34] <hallyn> saamm: after choosing a username you should be able to select the window manager at the bottom
[15:34] <hallyn> saamm: after you choose 'Ubuntu' once, it'll redefault to that
[15:35] <saamm> hallyn, you mean at gdm?
[15:35] <hallyn> yes
[15:35] <cjwatson> hallyn: -U_FORTIFY_SOURCE
[15:35] <hallyn> kees: ^ (re FORTIFY_SOURCE)
[15:36] <saamm> hallyn, I did that, but it always logs in to classic mode. I must have tired it 10 times. Also ccsm shows unity plugin enabled
[15:36] <hallyn> cjwatson: yes, that's listed as another option.  lemme try that, but manpage claims both should work?
[15:36] <hallyn> cjwatson: thanks, and welcome back :)
[15:37] <smoser> someone is reporting to me that 'apt-get upgrade' failed for them on 11.04.  What is the best way to collect more infomration?  (I think there is a way to get dpkg failure logs, right?)
[15:37] <smoser> user said the 'apt-get update' then 'apt-get upgrade'
[15:38] <saamm> hallyn, also doing a --compiz replace gets me unity but then both top and bottom panels from classic gnome stays as well
[15:38] <hallyn> saamm: i used to just to "unity --reset' when that happened to me
[15:39] <doko> didrocks: looking ...
[15:40] <saamm> hallyn, yep I also did that, same thing happens --top and bottom panel stays. Also when I logout and come back, I again get classic mode :(
[15:40] <hallyn> saamm: think you'll want to ask on #ubuntu-desktop
[15:40] <saamm> ok
[15:51] <hallyn> why is configure trying to use '-Rlib' ?
[16:04] <dholbach> micahg, regarding bug 793567: do you think anarcat tried to subscribe ubuntu-sponsors?
[16:04] <tumbleweed> dholbach: we were discussing this in #ubuntu-motu
[16:04] <dholbach> ah ok
[16:04] <dholbach> nm then
[16:04] <dholbach> I just saw it pop up on the sponsors mailing list
[16:05] <micahg> dholbach: it's already been removed from Ubuntu, so we're good
[16:05] <tumbleweed> yeah, package is already removed in oneiric. He wants removal in stable releases, though...
[16:05] <dholbach> yoohoo
[16:05] <dholbach> oh ok
[16:06] <ScottK> siretart: That fixed it and seems to be the only issue in kdemultimedia.
[16:06] <ScottK> Thanks again.
[16:06] <micahg> tumbleweed: are you sure, it wasn't removed from squeeze, it just doesn't exist in squeeze
[16:07] <tumbleweed> micahg: it was removed from testing before squeeze froze
[16:07] <micahg> tumbleweed: exactly
[16:07] <micahg> so, I guess it never was in a stable release in Debian :-/
[16:08] <tumbleweed> sucks to be us :)
[16:08] <micahg> unfortunately, I'm sure we have 100s of apps like that
[16:09] <siretart> ScottK: Cool! Great to hear
[16:09] <ScottK> I sent the patch upstream too.
[16:09] <tumbleweed> micahg: yeah, the corner of the archive that rots quitely. Unless this thing causes real damage, that's the best answer
[16:09] <tumbleweed> *quitely
[16:09] <tumbleweed> gr@sp twice
[16:17] <mateusz> HI
[16:17] <mateusz> apt-build is not respecting my optimization parameters
[16:17] <mateusz> what's wrong ?
[16:17] <mateusz> I seleted O3 and core2 while it does -O2 in compilation process
[16:53] <maco> pitti: fixed
[16:58] <seb128> kees, jdstrand, mdeslaur: hey, could somebody from the security team review the accountsservice mir (and maybe the apg one as well) some day, it's required for the new gnome-control-center user account dialog
[16:59] <jdstrand> seb128: sure
[16:59] <seb128> jdstrand, thanks
[17:00] <seb128> jdstrand, the bugs are assigned to the security team (bug #785680, #785682)
[17:17] <SpamapS> pitti: yes I had some other pressing matters last week, I'll get through some SRU's today for sure.
[17:50] <kees> chrisccoulson, kirkland: did you mean to be expired from ubuntu-sponsors?
[17:50] <chrisccoulson> kees, no, i just never asked anyone to renew my membership ;)
[17:51] <chrisccoulson> kees, can you do that?
[17:51] <kees> yup
[17:52] <kees> chrisccoulson: done!
[17:53] <chrisccoulson> kees, thanks :)
[17:53] <kees> np :)
[17:56] <cjwatson> jelmer: do you think switching to samba4 (at least the clients) in oneiric is likely to be feasible?
[17:59] <jelmer> cjwatson: hmm, that's a tough call
[18:00] <jelmer> the clients are in relatively good shape compared to the server (which is nowhere ready yet in terms of file serving in samba 4)
[18:00] <cjwatson> I'm mostly just comparing the enormous size of smbclient with the tiny size of samba4-clients
[18:00] <jelmer> however, there are still inconsistencies in the options in the configuration file that is used by both samba 3 and samba 4 (/etc/samba/smb.conf) - and these configuration files are used by both the clients and the servers
[18:00] <cjwatson> and wondering what I'm missing :)
[18:02] <jelmer> cjwatson: samba 4 uses shared libraries, samba 3 doesn't (and links pretty much everything into every binary)
[18:02] <bdrung> lool: please unsubscribe ubuntu-sponsors once you sponsored a bug
[18:03] <cjwatson> jelmer: is that at all fixable in samba 3?
[18:03] <kees> chrisccoulson: btw, why is 784542  a dup of 548866 ?  548866 is about "on update", and 784542 is about "on firefox restart"
[18:03] <chrisccoulson> kees, it's all part of the same problem
[18:03] <kees> okay
[18:04] <jelmer> cjwatson: in practice, it's very hard (requires moving code around, changing function signatures, etc). upstream everybody is focussing on getting samba 4 to rock - we've betted on two horses for way too long already.
[18:04] <kees> is there hope to get the on-restart part fixed? it's very annoying. :)
[18:04] <jelmer> (betted? bet? bat?)
[18:05] <chrisccoulson> kees, i'm not sure. it's a pretty hard problem to solve properly (in a way that doesn't break the preferences system)
[18:05] <chrisccoulson> perhaps we could stop setting default preferences in an extension ;)
[18:05] <chrisccoulson> that would work around it
[18:05] <jelmer> cjwatson: is this about the cd size?
[18:06] <cjwatson> jelmer: yeah, I was hoping that some of that juicy 14MB might be recoverable
[18:06] <cjwatson> though I understand if it's infeasible for now
[18:09] <jelmer> cjwatson: is there a list of packages that are meant to be included in the cd image somewhere?
[18:09] <cjwatson> http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.oneiric/{required,minimal,standard,desktop-common,desktop,live}
[18:09] <cjwatson> oh and ship-live
[18:10] <jelmer> thanks
[18:10] <cjwatson> eek, why is build-essential in ship-live?
[18:10] <kees> chrisccoulson: well, I don't understand the details of it. why is the "middle" pref reset at all?
[18:11]  * cjwatson nukes that
[18:12] <micahg> cjwatson: is that what pulls in the compiler or is that in separately?
[18:12] <cjwatson> micahg: partially - see the seeds, there's a comment
[18:14] <jelmer> cjwatson: my guess is that we might be able to make samba4's smbclient ready for inclusion (a bit of work to finish the reconciliation of the configuration files). However, I'm not sure if fixing a mix of samba3 and samba4 will actually help. samba4-clients has a couple of shared library packages it depends on; unless the other samba packages use that (or if we start including evolution-mapi on the main cd) I don't think it will make a significant
[18:14] <jelmer>  difference.
[18:14] <cjwatson> ok
[18:18] <ScottK> cjwatson: Don't we need build-essential for building restricted drivers?
[18:19] <infinity> ScottK: No.
[18:19] <ScottK> OK.  We need something.
[18:19] <infinity> ScottK: Notably, build-essential pulls in dpkg-dev, which you don't need for compiling.
[18:20] <stgraber> the drivers seem to depend on both make and dkms, dkms has "gcc, make | build-essential | dpkg-dev" in its Depends, so we should only end up with drivers + make + gcc on the CDs
[18:21] <infinity> Which seems reasonable.
[18:23] <ScottK> stgraber: Thanks.
[18:24] <jelmer> cjwatson: actually, related to this; I was wondering if it was possible to have ubuntu-desktop depend on "smbclient | samba4-clients" but I can't figure out how to do that in ubuntu-meta. Is that possible?
[18:35] <infinity> jelmer: See xubuntu-meta from hardy, notably the "s/gnumeric-gtk/gnumeric-gtk | gnumeric/" on debian/xubuntu-desktop.substvars in debian/rules.
[18:36] <infinity> jelmer: Basically, you can't make the task have ORed depends (cause tasks don't work that way), but that's fine, cause we only use tasks for the initial install, but you can make the metapackages have ORed depends to give users post-install flexibility.
[18:37] <jelmer> infinity: that's the sort of thing I was looking for - thanks!
[18:44] <cjwatson> ScottK: gcc is in desktop for that; build-essential was annotated with a comment saying that it was for building packages
[18:44] <micahg> cjwatson: Ubuntu Installer no longer seems to show up in the -changes mailing list as the from for syncs, is this a permanent change?
[18:45] <ScottK> cjwatson: OK.  stgraber's explanation cleared it up for me.
[18:45] <cjwatson> micahg: that only ever happened when the sync requestor didn't have a public e-mail address on lp
[18:46] <micahg> cjwatson: istr mine showing up as Ubuntu Installer as From with my address in the e-mail
[18:47] <micahg> cjwatson: https://lists.ubuntu.com/archives/oneiric-changes/2011-May/001686.html
[18:47] <slangasek> jelmer: fwiw, one reason samba4-clients might help despite the added sharedlib dependencies is that there are more programs in the clients package than there are shared libraries...
[18:47] <cjwatson> micahg: not aware of anything having changed there
[18:48] <micahg> cjwatson: ok, is there someone I should poke or somewhere to file a bug?
[18:48] <cjwatson> jelmer: also, the point of the metapackages is to pick preferred alternatives for things; all the business with putting ored deps in them kind of misses the point IMO
[18:48] <infinity> micahg: Is it a bug?
[18:48] <cjwatson> micahg: if it's showing up with your name now, that's intended behaviour
[18:49] <micahg> cjwatson: well, it was showing before that it was sync'd vs looking like I uploaded it
[18:49] <infinity> micahg: It just depends on how the person driving the sync does it.  If they give your LP username as an argument, it comes "from you", if they give none, it comes from archive@
[18:50] <infinity> micahg: Coming from archive@ just means "sync with no one to blame".  Syncs *should* ideally all look like they were uploads from the requestors.
[18:50] <micahg> oh, hmm, it showing up differently in LP now, maybe that explains it
[18:51] <micahg> infinity: before in LP ISTR it showing up like a sponsored upload
[18:51] <jelmer> slangasek: that's a good point
[18:52] <jelmer> cjwatson: the main reason for this is that smbclient and samba4-clients conflict - I currently can't have ubuntu-desktop installed because it explicitly requires smbclient
[18:52] <slangasek> why does it do that, anyway? :)
[18:52] <slangasek> smbclient isn't the sort of thing the desktop should depend on directly
[18:53] <infinity> slangasek: I suspect it's because some nautilus feature depends (or depended?) on it, but not strongly enough to justify a recommends, but we wanted it functional out of the box.
[18:54] <slangasek> nope
[18:54] <infinity> slangasek: And that's my recollection from, like, 5 years ago.
[18:54] <slangasek> nautilus always used libsmbclient
[18:54] <infinity> Something called smbclient in ugly ways.  But danged if I recall what.
[18:54] <jelmer> slangasek: didn't some gnomevfs thing once use smbclient, for licensing reasons?
[18:54] <infinity> ^
[18:55] <slangasek> I really don't think so
[18:55] <infinity> If that's no longer the case, and provably so, you'd make a lot of people happy by removing it from the CDs. ;)
[18:55] <slangasek> I recall that it always used libsmbclient, and gnomevfs integration was one of the problem areas identified when Samba was relicensing to GPLv3
[18:56] <jelmer> maybe it's that cups uses smbspool from the smbclient package for smb printing?
[18:56] <infinity> jelmer: Possibly.
[18:56] <slangasek> well, that would make me sad then
[18:56] <infinity> I could have sworn it was something related to gnome filesystemy stuff though.
[18:56] <slangasek> in actual fact, the /reason/ for the dependency on smbclient is "hysterical raisins"
[18:57] <slangasek> because it's in version 1 of the seed
[18:57] <ohsix> hi, where should i, or who should i talk to to make a suggestion for a test to be added to fwts
[18:58] <infinity> slangasek: I imagine doing a reverse-suggests search on all of ship-live and lesser would get you a good hint at what package might want it?
[18:58] <infinity> (And if that comes up empty, let it burn?) :P
[18:59] <micahg> ohsix: I think you can just file a bug, I think cking looks at those
[18:59] <slangasek> infinity: cups-client does Recommend smbclient, so ultimately I guess we have to keep it for this
[18:59] <slangasek> but I still don't think it belongs directly seeded in platform/desktop-common
[18:59] <ohsix> micahg: okie dokie
[18:59] <infinity> If it's recommended, I see no reason to seed it at all.
[18:59] <slangasek> and that would fix jelmer's conflicts problem
[19:00] <ohsix> micahg: it's the lack of data from /sys/class/power_supply/*/current_now if you're curious; leads to the ui for the battery never showing an estimate (upower no longer calculates it when energy-rate/current_now is 0, hal did)
[19:00] <infinity> I suspect that recommend probably used to be a suggests, hence the seed kludge.
[19:01] <slangasek> the comment in the seed suggests printing wasn't even on the radar at the time it was added :)
[19:01] <infinity> (Or, rather, seeds pre-date install-recommends-by-default, which would be the real issue)
[19:01] <slangasek> anyway, excising it
[19:01] <infinity> But I *still* seem to recall it being gnome-network-filesystem-related.  So, I'm probably reaching that part of old age where you just start randomly making up history.
[19:01] <jelmer> slangasek: that indeed seems like a better solution; thanks!
[19:04] <slangasek> seed changed
[19:33] <lool> bdrung: I couldn't unsubscribe ~ubuntu-sponsors as I am not a member -- I got poked directly to sponsor this because I had touched the package in the past
[19:34] <bdrung> lool: then i invite you to join the sponsors team
[19:34] <bdrung> :)
[19:35] <lool> bdrung: Eh I was a member in the past
[19:35] <lool> I think I expired and opted not to renew as I wasn't really doing much sponsoring  :-/
[19:36] <bdrung> lool: the correct fix is to do more sponsoring instead of expiring ;)
[19:36] <lool> Eh
[20:27] <bryceh> @pilot in
[20:46] <broder> could someone accept the sru nomination for bug 778615 for me please?
[21:09] <hallyn> pitti: hey, is there a particular reason why ubuntu's udev doesn't do 'modprobe scsi_wait_scan'' in extra/initramfs.top like debian's does?
[21:09] <hallyn> (i assume there is, and vaguely recall asking you before, but maybe it wasn't you I asked)
[21:10] <SpamapS> hallyn: probably to avoid a delay when there aren't any scsi devs?
[21:11] <SpamapS> hallyn: anyway, I'm satisfied having taken a look at what scsiwait_scan does ... I'm going to accept the upload
[21:11] <hallyn> SpamapS: ok, thanks
[21:11] <hallyn> SpamapS: maybe i should have mentioned redhat does it in multipath-tools pkg
[21:12] <hallyn> pretty sure ppetraki pointing out that rh does it is what led me to try it
[21:12] <SpamapS> hallyn: initramfs is special.. kind of like the kernel.. sometimes we have to do stuff that looks a bit daft on the surface
[21:12] <hallyn> yup
[21:16] <SpamapS> hallyn: so the versions for the lucid/maverick updates are really, really close.. 0.4.8-14ubuntu11.2 and 0.4.8-14ubuntu11.2   ... I'm concerned because the next update will then require ~'s to keep them in the appropriate sequence.
[21:16] <SpamapS> err
[21:16] <SpamapS> 0.4.8-14ubuntu11.1 for lucid
[21:18] <SpamapS> hallyn: In this case I'd change the maverick upload to 0.4.8-14ubuntu11.10.10 .. this way it will always be higher than any lucid updates
[21:20] <hallyn> what happens if a lucid update has higher version?
[21:20] <SpamapS> on upgrade to maverick, the new package isn't installed
[21:20] <hallyn> i thought that didn't matter - that it only mattered that it be higher than any previous upload for that version
[21:20] <SpamapS> no you always have to be superceded by the next release's packages
[21:21] <SpamapS> superseded even
[21:21] <hallyn> ok, is that something you can change in-flight?
[21:21] <SpamapS> no I'd need to reject and then re-upload
[21:21] <hallyn> all right
[21:21] <micahg> SpamapS: hallyn, here's the guide we in the security team use for versioning in these situations: https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update%20the%20packaging
[21:21] <hallyn> you want me to re-upload, or were you going to?
[21:22] <hallyn> micahg: yeah, i *thought* i was following that guide...
[21:22] <SpamapS> yeah, the sec team has it down to a science. :)
[21:22] <hallyn> maybe i should re-read
[21:22] <SpamapS> 2.0-2 in two releases         2.0-2ubuntu0.5.04.1 and 2.0-2ubuntu0.5.10.1
[21:23] <hallyn> yeah i see, bc i'm rereading
[21:23] <hallyn> :)
[21:23] <SpamapS> hallyn: do you have upl rights for m-t ?
[21:23] <hallyn> yeah
[21:24] <SpamapS> ok cool.. I'll reject and you can upload again with 0.4.8-14ubuntu11.10.10.1
[21:25] <SpamapS> that way we can make the next lucid update (if there is one) 0.4.8-14ubuntu11.10.04.1 and all will be in line with those guidelines.
[21:25] <SpamapS> BTW, somebody should really build this into dch
[21:25] <hallyn> true
[21:25] <SpamapS> and maybe even into lintian
[21:25] <SpamapS> or dpkg-buildpackage
[21:26] <SpamapS> hallyn: otherwise it looks good for maverick too so I'll accept the new version as soon as you upload it.
[21:26] <hallyn> have you rejected already?  (haven't gotten the email)
[21:27] <SpamapS> just did
[21:29] <hallyn> SpamapS: dput'ed
[21:30] <hallyn> and NOW I think I"ll go look at kernel  (though i've got some blogging to do, too,  hmm)
[21:30] <hallyn> oh,
[21:39] <micahg> SpamapS: hallyn, that's not good, that version in lucid-proposed is now ahead of natty
[21:39] <micahg> and oneiric for that matter
[21:46] <micahg> SpamapS: hallyn, for oneiric, you can just merge from Debian, but for maverick/natty, you'll need a new version in proposed and updates before the lucid one can go out
[22:03] <micahg> SpamapS: hallyn: the correct way to have done that if all those changes are SRU worthy was to either collapse all the changes under a single changelog targeted to $RELEASE-proposed or to add a changelog on top of all the changes targeted to $RELEASE-proposed with a proper -proposed version, changing all the changelog entries to $RELEASE-proposed is wrong
[22:05] <SpamapS> hm
[22:06] <SpamapS> damn
[22:08] <SpamapS> hallyn: ok, so can you please a) upload the fixes to oneiric as 0.4.8-14ubuntu13 (or as micahg suggests, merge from debian) .. then upload to natty-proposed as 0.4.8-14ubuntu12.11.04.1
[22:08] <SpamapS> I'll go flog myself with 20 lashes
[22:09] <SpamapS> This is the one step I think is most frustrating about preparing SRU's.. checking the published versions
[22:09] <micahg> SpamapS: rmadison is your friend :)
[22:11] <micahg> SpamapS: at this point, I'd just suggest making sure everythings in the proper succession by the time that the -proposed uploads hit -updates
[22:12] <SpamapS> micahg: you know.. I've known about it for a while.. why don't I use it more? :-P
[22:12] <cody-somerville> Whats the bug # for this SRU?
[22:12] <SpamapS> there are 6 bug #'s ...
[22:12] <SpamapS> 488285 644481 660597 686832 713237 789229
[22:12] <micahg> cody-somerville: https://launchpad.net/ubuntu/lucid/+source/multipath-tools/0.4.8-14ubuntu11.1
[22:19] <hallyn> 'or merge from debian' -> just cause i f'd up doesn't mean i woudln't punch you if you were in range
[22:20] <micahg> hallyn: ?
[22:21] <hallyn> micahg: (that was at SpamapS :)  i've had a few attempts at debian merge already, and one is awaiting test
[22:21] <micahg> hallyn: ah, ok :)
[22:21] <hallyn> but not having the hardware makes it always, in teh end, too scary to upload
[22:21] <hallyn> micahg: thanks for the tips.  I gather you're saying do an empty version bump for natty and oneiric, right?
[22:22] <SpamapS> hallyn: that should be fine yes
[22:22] <micahg> hallyn: well, natty is missing the ubuntu11 change, so idk if it needs it
[22:22] <hallyn> eh what?
[22:22] <SpamapS> it does and should get it.. as 0.4.8-14ubuntu11.11.04.1
[22:23] <micahg> hallyn: for oneiric, if you can't merge from Debian before the natty upload hits updates, then yeah, an empty version bump would be good
[22:23] <hallyn> ok, i'll put a note in my tickler for next week to
[22:23] <hallyn> haha
[22:23] <hallyn> that won't work
[22:24] <hallyn> i'll just bump the oneric one now, else it won't likely happen for > 2 weeks
[22:24] <SpamapS> yes please do that. :)
[22:24] <hallyn> SpamapS: yo'ure saying i never pushed a natty fix?
[22:24] <SpamapS> hallyn: you did, w/ the wrong version
[22:24] <hallyn> ok
[22:24] <SpamapS> which I'm rejecting right now. ;)
[22:25] <hallyn> right-y-o
[22:26] <hallyn> should i then collapse the changelog entries while i'm at it, or leave it as is for symmetry with the other releases?
[22:26] <SpamapS> hallyn: meanwhile the maverick one looks fine, but I'm holding off until the natty/oneiric bumps are done
[22:26] <SpamapS> I personally don't see a problem with multiple unreleased versions.. but maybe wiser people do.
[22:27] <SpamapS> In this case, I'd say maintaining symmetry w/ the update is probably better.
[22:28] <cody-somerville> SpamapS, Have you already accepted all the uploads or can you still reject some of the incorrectly versioned uploads to -proposed?
[22:29] <micahg> SpamapS: the maverick one should be rejected I think and the non-maverick changelog entries restored to what they should be IMHO
[22:30] <micahg> cody-somerville: only one accepted w/the bad version so far is lucid-proposed
[22:30] <micahg> cody-somerville: you have an idea?
[22:31] <cody-somerville> So basically whats happened here is that the version currently in oneiric was 'backported', correct?
[22:31] <micahg> cody-somerville: yep
[22:31] <hallyn> minus one intermediate change, yes
[22:33] <ohsix> uhohbig problem with 2.6.38-10, picture forthcoming
[22:33] <ohsix> (same problem i was getting with mainline .39 a week ago)
[22:36] <ohsix> http://img847.imageshack.us/img847/2017/dscn0955v.jpg
[22:36] <ohsix> er wrong chanel :O
[22:37] <micahg> hallyn: if something's been removed, you might want to collapse all the included entries into one changelog crediting the appropriate individuals since it's not a true backport
[22:37] <cody-somerville> indeed.
[22:38] <cody-somerville> Lets reject the uploads to maverick and natty.
[22:43] <cody-somerville> It doesn't look like multipath-tools has made it into http://archive.ubuntu.com/ubuntu/dists/lucid-proposed/main/binary-i386/Packages.bz2 yet. If you hurry, you might be able to delete the bad versioned upload and then we could do things correctly for lucid
[22:44] <cody-somerville> SpamapS, ^^
[22:49] <cjwatson> broder: nomination> done
[22:49] <broder> thanks
[22:49] <hallyn> micahg: and if SpamapS catches that soon enough, then i should call the lucid version 0.4.8-14ubuntu4.10.04.1 with a single collapsed changelog entry?
[22:49] <micahg> hallyn: yep
[22:49] <broder> cjwatson: although apparently i might have imagined gfxpayload=keep not working, or maybe it got fixed since the last time i tested...
[22:50] <SpamapS> cody-somerville: I've not done anything like that before. How does one delete an upload that has been accepted and built?
[22:50] <cody-somerville> cjwatson, Can you advise how to best resolve this situation? An SRU has been uploaded and accepted into lucid-proposed whose version is greater than maverick, natty, and oneirc.
[22:51] <sbeattie> hallyn: even 0.4.8-14ubuntu4.1 would be fine, you'd only need the release version embedded if the version strings up to that point would be the same (e.g. 0.4.8-14ubuntu11)
[22:52] <micahg> sbeattie: no, maverick has the same version
[22:52] <cody-somerville> cjwatson, there are also similarly versioned SRUs in the queue not yet accepted for maverick-proposed and natty-proposed.
[22:53] <sbeattie> micahg|hallyn: ah, right, I missed that, sorry. micahg is correct.
[22:53] <cjwatson> cody-somerville: ask #soyuz or #launchpad-ops or something for help - I'm too tired to make judgements, and I still have a washing machine to fix before I go to sleep
[22:54] <cjwatson> in principle, winding versions backwards in -proposed for this kind of situation has my approval providing that some kind of message goes out to users about it
[22:54] <cody-somerville> cjwatson, Thanks. Thats what I was looking for.
[22:55] <ScottK> See pitti's u-d-a message about the kernel from earlier today for a template.
[22:55] <micahg> it just hit archive.u.c
[22:56] <micahg> for some reason, I thought this stuff hit almost right away...
[22:56] <SpamapS> At this point, isn't the simplest solution to just update natty/maverick/oneiric to also be higher than this proposed update?
[22:57] <cjwatson> micahg: takes until the publisher runs, which starts at :03 and takes a substantial fraction of the hour to complete
[22:57] <SpamapS> The *only* reason this is troublesome is for upgrades. This will not be troublesome on upgrade if the updates are available on those releases.
[22:57] <cody-somerville> SpamapS, No. The more changes we make, the greater the risk. Its safer to just delete this package from -proposed all together and halt processing this SRU.
[22:58] <micahg> cody-somerville: I think an update was planed for all the releases anyways, the only problem is the versioning
[22:58] <SpamapS> The risk right now, is that a lucid -> maverick upgrade will not regress
[22:58] <SpamapS> that seems like a risk we should be comfortable with
[23:00] <SpamapS> The risk becomes zero if we accept the maverick/natty updates and serge bumps oneiric.
[23:00] <Laney> are users required to continue having -proposed/-updates enabled when they upgrade?
[23:00] <micahg> SpamapS: well, the changelogs should be fixed for maverick/natty
[23:00] <SpamapS> Laney: that I don't know.
[23:00] <cody-somerville> Nothing has made it to -updates
[23:00] <SpamapS> micahg: "fixed" or "done the way we prefer" .. ?
[23:01] <cody-somerville> We should remove the version currently in -proposed
[23:01] <SpamapS> To avert what risk?
[23:01] <cody-somerville> send an e-mail out to let folks know what to do if they happened to grab that update
[23:01] <micahg> SpamapS: it's disingenious at the moment sincce it's not really a backport, also, changing the release target for previous entries is just bad
[23:03] <SpamapS> cody-somerville: I'm sorry if I'm being obtuse here.. but I still fail to see the danger.
[23:03] <Laney> it ties all of the SRUs together
[23:06] <SpamapS> checking now, so far all symbols are the same on all dependent libraries
[23:07] <cody-somerville> SpamapS, Every update has risk. Every change made has a risk. Introducing more changes now hastily to work around mistakes and lack of adherence to the SRU policy introduces additional risk whereas deleting an update from -proposed is bringing us back to where we were before and acceptable for -proposed.
[23:07] <micahg> Laney: it would make sense that if you have updates enabled, the only upgrade path is with updates enabled
[23:07] <micahg> cody-somerville: the only change that shouldn't have been in the upload was a bad changelog AFAIK
[23:09] <SpamapS> cody-somerville: I see your point. To bring a counterpoint to bear, the change thats in lucid, is going into maverick, and natty as well, and the source packages in maverick and lucid release pockets are identical ... so.. this is just changelogs and builds as micahg suggests..
[23:11] <SpamapS> cody-somerville: to me, if we fix the versions in the later -proposed and -updates to be after this one, we leave any users who might have been exposed to this problematic version in a better place... we kind of have to do this anyway.
[23:12] <sbeattie> micahg: I think Laney's point is that it now ties the promotion from proposed to updates of all the SRUs together, in that in order for lucid's version to be published, all the newer releases have to have already been verified and published first (or at the same time).
[23:13] <Laney> right, you get the exact same problem at -updates time again
[23:13] <cody-somerville> I want to fix the versioning. The current versioning in lucid is misleading and wrong. Not fixing it could impact future SRUs we do for this package. Reverting and following the established policies and practices is safer in my opinion then just trying to massage the mistake into working.
[23:13] <Laney> whereas with the proper versioning it can be done independently
[23:14] <micahg> cody-somerville: all versions were being SRUd already
[23:14] <sbeattie> micahg: given that multipath is a bit special (see hallyn's comments about not wanting to publish the merge due to not having the hardware to test) means that it's going to be hard to dredge up testers for these SRUs.
[23:14] <Laney> also, ahem, don't we have to get the update blocked before the mirror push?
[23:14] <sbeattie> and so it's very likely that we might get someone willing to test on lucid, but not on a non-LTS release.
[23:14] <cody-somerville> Furthermore, I have concerns about if some of the changes qualify under the SRU policy.
[23:15] <cody-somerville> sbeattie, great point.
[23:15] <cody-somerville> Lots of uncertainty here.
[23:15] <cody-somerville> Which is why I think we should delete the upload to -proposed so that we have time to make sure we do this right.
[23:15] <SpamapS> cody-somerville: 50% of the changes that go into our SRU's do not qualify under the strictest letter of the SRU policy. Anything below High really shouldn't be SRU'd.
[23:15]  * micahg is beginning to agree with cody-somerville 
[23:16] <micahg> SpamapS: core packages should be held to a different standard than most
[23:16] <SpamapS> I agree with cody too. I only bring up the alternative because it seems that we have to update the later releases anyway.

[23:17] <SpamapS> I am sorry for the mistake guys. If you need me to do anything ping me. Otherwise I think I'll just step back from the discussion.
[23:17] <ScottK> SpamapS: You're the one with the access needed for fixing, whatever that turns out to be, so don't step too far back.
[23:18] <SpamapS> I may not be able to do that, as I don't have direct queue access, only LP queue access.
[23:18] <SpamapS> But understood.
[23:18] <hallyn> SpamapS: no no, *I*'m sorry for the mistake.  let's follow cjwatson's advice about where to go ask
[23:20] <cody-somerville> lamont, Are you around?/Have the necessary permission bits to remove a package from lucid-proposed?
[23:21] <SpamapS> Laney: there's no commandline option to disable carrying them forward in do-release-upgrade
[23:21] <SpamapS> Laney: since you asked earlier. :P
[23:21] <Laney> I wonder what it actually does in its sources.list munging
[23:22] <Laney> anyway, shawshank redemption time
[23:22]  * Laney waves
[23:22]  * cody-somerville waves back to Laney.
[23:25] <SpamapS> cody-somerville: I don't want to duplicate effort. Are you asking around in #launchpad-xxx channels?
[23:25] <cody-somerville> SpamapS, Just pinged the LOSA team. No response as of yet.
[23:25] <cody-somerville> oh, there we go
[23:26] <SpamapS> ok, I'll be around for the next 90 minutes if you need me for anything
[23:26] <cjwatson> I tend to agree with Cody here, I must say - let's not hack around later releases to cope with an SRU mistake that hasn't been released to -updates yet
[23:26] <ScottK> SpamapS: Oh.  I thought you had shell access.  You'll want to look north for a archive admin in your TZ that has shell access.
[23:26] <cody-somerville> Chex, Hi. An incorrectly versioned SRU was uploaded and accepted to lucid-proposed. The consensus is that the package should be removed.
[23:26] <cody-somerville> Chex, Are LOSAs able to help with that?
[23:28] <lamont> cody-somerville: the power, probably.  the knowledge?  I'd be flying blind
[23:29] <Chex> lamont: ah ok, I wasn't sure myself
[23:30] <sbeattie> pitti periodically deletes packages from -proposed that haven't received testing/feedback in a reasonable; I'm not sure where/how he does this.
[23:31] <sbeattie> s/reasonable/reasonable amount of time/
[23:31] <SpamapS> Heh.. it usually has instructions on http://people.canonical.com/~ubuntu-archive/pending-sru.html but there are no packages to clean up ATM
[23:31] <broder> slangasek: out of curiosity, how far are we from being able to install a 64-bit kernel on a 32-bit userland with multiarch?
[23:31]  * SpamapS digs in the tools
[23:33] <micahg> broder: umm, don't you mean the other way around?
[23:33] <slangasek> broder: well, wasabi popped into #multiarch the other day and worked through the necessary package changes to do so... libbz2 -> Multi-Arch: same, and three other util packages Multi-Arch: foreign, and you're there :)
[23:33] <SpamapS>             print 'lp-remove-package.py -y -u $SUDO_USER -m "moved to -updates" -s %s-proposed %s' % (
[23:33] <lamont> micahg: a 32-bit kernel won't support 64-bit userspace
[23:34] <micahg> lamont: oh, I guess this is assuming 64 bit hardware...
[23:34] <SpamapS> I believe that has to be done w/ shell access
[23:34] <lamont> micahg: what else is there?
[23:34] <slangasek> broder: frankly I completely forgot about that use case because I've been running 64-bit for so long, else I would've done it in natty
[23:35] <cjwatson> SpamapS: what's the package name?
[23:35] <SpamapS> cjwatson: multipath-tools
[23:35] <broder> slangasek: every once and a while i want to do it for random small things. at the moment, i'm screwing around with a bitcoin miner for random entertainment value, but it only runs on 32-bit
[23:36] <slangasek> broder: well, it's straightforward for you to make these changes in oneiric now if you want to do it
[23:37] <cjwatson> SpamapS: removed, pending the next publisher run
[23:38] <cjwatson> SpamapS: whether this will let you later upload a lower version, I don't know
[23:38] <cjwatson> that may or may not require assistance from a Soyuz expert
[23:38] <SpamapS> cjwatson: thanks very much. I'll send out the "oops" email once the archive is updated.
[23:39] <cjwatson> at least it wasn't there for very long
[23:39] <ohsix> how do these numbers map to something i can read the changelog of in git? 2.6.38-9.43
[23:39] <cody-somerville> cjwatson, Kudos for your help.
[23:39] <ohsix> (the next is -10.44)
[23:39] <micahg> ohsix: you might want to ask in #ubuntu-kernel
[23:39] <SpamapS> indeed, and in fact, I've tested the binaries on maverick and natty VM's, they actually work fine... its not the end of the world if somebody with -proposed enabled accidentally keeps them.
[23:40] <ohsix> micahg: ok, a bit dead, thought someone might know offhand
[23:40] <micahg> ohsix: yeah, it's EOD in half the US and Eurpoe
[23:40] <broder> slangasek: do i just need to change all of linux-image-`uname -r`'s dependencies to be multi-arch: foreign?
[23:40] <SpamapS> Hopefully with the reverted messages that I'll post in the bug reports, and a message to u-d-a .. it should be enough for users to find and respond accordingly.
[23:42] <ohsix> micahg: i see things in the changelog for .4 to .6, that might be enough
[23:44] <hallyn> SpamapS: what is u-d-a?
[23:44] <EagleScreen> should new users in admin be able to install updates with packagekit and polycikit?
[23:45] <ohsix> micahg: just to be sure this channel is for packaging and other development right?
[23:45] <SpamapS> hallyn: ubuntu-devel-announce .. or maybe its just ubuntu-devel.. I haven't looked again at the earlier mail from pitti
[23:47] <micahg> ohsix: for stuff in main for the archive, yes
[23:47] <slangasek> broder: the ones that provide only interfaces in /usr/bin to their revdeps, yes
[23:47] <micahg> SpamapS: he sent it to u-d-a
[23:48] <ohsix> micahg: ok thanks
[23:49] <slangasek> broder: oh, the bzip2 thing didn't apply to the kernel at all, that was when wasabi decided to cross-grade his system from i386 to amd64 for kicks :P
[23:49] <broder> slangasek: and bzip2 was the only unconverted library blocking it?
[23:49]  * broder boggles
[23:49] <slangasek> yep
[23:49] <slangasek> at least for changing dpkg itself :)
[23:50] <broder> crazy
[23:53] <hallyn> SpamapS: thanks.  guess i'm not on that list!
[23:54] <hallyn> oh.  no.  now i remmeber the msg
[23:55] <EagleScreen> new created useres in admin group cannot use policykit, it ask for root password instead of user password, is this behavior a bug??