[00:02] <ohsix> thought the process still seems rather nebulous to me, i'll call that a result
[00:03] <ohsix> (-t, agh)
[00:14] <bryceh> cjwatson, no, since that is a private unreleased version of -fglrx the issues mostly are just email, no bug #'s unfortunately
[00:14] <cjwatson> bryceh: OK - is it urgent for beta?
[00:14] <cjwatson> bryceh: (I may have another upload coming anyway, and I've queued it up)
[00:15] <bryceh> cjwatson, it depends on whether we get -fglrx in time for beta, which is uncertain (no eta's given)
[00:15] <cjwatson> ok, well let me know as early as you can if it looks like we're going to be out of sync
[00:15] <cjwatson> it's in lp:~ubuntu-core-dev/ubuntu/natty/grub2/natty
[00:20] <ohsix> oh boy, my logoff dialogue and some polictkit windows earlier were showing broken font unicode boxes, i fear a reboot
[00:24] <ohsix> who keeps changing the wifi icon D: the elements are almost too small to resolve now, and the bottom looks misshappen
[00:53] <cnd> ohsix, which bug was it that you were hitting?
[00:54] <ohsix> cnd: the 2 finger gestures on SemiMultitouch (well put) devices
[00:54] <ohsix> though it appears to still be doing it
[00:54] <cnd> ohsix, do you have the bug link?
[00:54] <cnd> I just want to make sure everything is as expected
[00:56] <ohsix> these are the bugs i posted yesterday after our discussion, https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/739916 https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/739922 https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/739924
[00:56] <ohsix> the one related to 2 finger clicks is the first, guess i assumed a bit that it was desired, but didn't have configuration
[00:57] <cnd> oh yeah, ok
[00:57] <cnd> I work on so many bugs I just forget what is what
[00:57] <ohsix> alright
[00:57] <cnd> ohsix, I don't really think the change should have had any effect
[00:58] <cnd> so I'm not sure what to think :)
[00:58] <ohsix> it didn't, i just read a little into it
[00:58] <cnd> ahh
[00:58] <cnd> ok
[00:58] <ohsix> i thought it'd disable the 2 finger gestures when the touchpad only fakes it
[00:58] <cnd> sorry...
[00:58] <ohsix> not a problem
[00:59] <cnd> ohsix, I don't think the scroll issue is going to be fixed for natty
[00:59] <ohsix> that's fine, it can be disabeld in gnome-mouse-properties
[00:59] <ohsix> the reason i filed the bug that way was to get something like that for the 2 finger right click
[01:00] <ohsix> since it's probably desirable for someone, but it happens way too often with one finger for me; and i'd rather it disabled
[01:00] <cnd> yeah
[01:00] <cnd> that should be fixed, but probably won't be for natty either...
[01:00] <ohsix> agh
[01:00] <cnd> it would require too big of a change at this point
[01:01] <ohsix> can you pin it disabled then, if theres no ui to do it
[01:01] <cnd> well, some people may like it, and it may work well for them
[01:01] <cnd> so we can't really make that kind of a change either at this point
[01:01] <ohsix> it could
[01:01] <cnd> because we don't really know how well it works for everyone
[01:02] <ohsix> except on these touchpads where it's almost assuredly wrong, without being able to adjust the threshold for it
[01:02] <cnd> we don't really know which touchpads it's definitely wrong though
[01:02] <ohsix> there are 2 very clear classes of synaptics touchpads, ones that fake it and ones that don't; the ones that fake it use heuristics that aren't always correct (can change with temperature and humidity even)
[01:02] <cnd> it may work fine for some people who have the "fake it" kind of touchpads
[01:02] <ohsix> well, you do; i could tell you too, they have different protocols
[01:03] <cnd> yeah, we can tell the two device types apart
[01:03] <cnd> but perhaps it works great for some of the "fake it" kinds, and it doesn't work for some other "fake it" kinds
[01:03] <ohsix> the ones with heuristics need extra input that there isn't ui for either; to make it work well
[01:04] <ohsix> i get your position but i can't help but think it's arguing against changing it, it personally annoys me and does not work well; it may work well for some unknown mass of people,  but i'm at least here telling you it doesn't
[01:04] <ohsix> i could enable it manually before natty as well; it did not work well then, and i had no desire to
[01:04] <cnd> ohsix, I do agree with you in that it probably should be disabled by default
[01:05] <cnd> and it's something we probably want to attack upstream
[01:05] <cnd> in the X community
[01:05] <ohsix> but now it's on by default and theres no ui for the sensitivity so it can't even be made to work sort of well
[01:05] <cnd> where the driver is setting it on by default
[01:05] <ohsix> probably
[01:05] <cnd> ohsix, this is a change in behavior from maverick?
[01:05] <ohsix> yes
[01:05] <bryceh> are we in freeze for beta?  do I need to get a freeze exception for an xserver bug fix?
[01:05] <cnd> (if you already said that, sorry)
[01:06] <ohsix> along with the acceleration profiles being wrong (takes 4 swipes to get to the other side of a small screen with sens/accel all the way up)
[01:06] <cnd> bryceh, we might want to patch out auto-enabling two finger tap for right click when only touch size is available (for ohsix's issue)
[01:06] <ohsix> when mav was in alpha/beta the sensitivy stuff changed as well; but by the time it was released it was fixed
[01:06] <cnd> bryceh, I don't know if you've kept up with the issue
[01:07] <bryceh> cnd, I haven't, no
[01:07] <cnd> bryceh, I'll try to summarize
[01:07] <cnd> there's two types of synaptics trackpads that are concerned here
[01:07] <cnd> multifinger trackpads and trackpads that just give you some touch area size
[01:08] <cnd> in natty, the default of x synaptics is to enable right click on two finger taps
[01:08] <cnd> including a heuristic to enable right click on non-multi-finger trackpads when the touch size looks like two fingers
[01:08] <cnd> maverick didn't default to this
[01:09] <cnd> and according to ohsix, the touch size heuristic just doesn't work well for all trackpads when set to the default thresholds
[01:09] <ohsix> (and there is no ui to adjust the thresholds either)
[01:09] <bryceh> ok
[01:09] <cnd> so I wonder if we shouldn't leave two tap for right click disabled for the touch size type trackpads
[01:10] <ohsix> since ui cant be added to enable/disable it like the 2 finger scroll, it would be best to disable it on the one type of touchpad until there is, so i can turn it off like the 2 finger scroll, and fwiw, if i could adjust the threshold that applies to both (click and scroll) i could probably use 2finger scroll as well
[01:11] <cnd> ohsix, the one thing I would note is that I'm very resource stretched myself
[01:11] <cnd> so although I agree with you
[01:11] <bryceh> ohsix, yeah ui for configuration would be nice.  Might be hard given the various interrelating drivers though, plus some of this is a moving target.  In any case don't think we have people on hand to write gtk config stuff presently
[01:11] <ohsix> right
[01:11] <cnd> I may not be able to fix the bug in time for natty release
[01:12] <ohsix> it all comes down to setting properties with xinput; which is what i'll have to do manually in either case
[01:12] <cnd> I may not be able to fix it myself that is
[01:13] <cnd> but if you or someone else has a patch, I'd be happy to review it
[01:17] <ohsix> hm
[01:18] <ohsix> i wouldn't know where to start
[01:19] <bryceh> apt-get source xserver-xorg-input-synaptics   ;-)
[01:19] <ohsix> yea i'm reading it now
[01:19] <cnd> $ bzr branch lp:ubuntu/xserver-xorg-input-synaptics
[01:19] <cnd> if you like bzr
[01:19] <bryceh> even better
[01:20] <ohsix> should i be looking through ubuntu's version of it? or is upstream enough for the likes of natty
[01:21] <bryceh> cnd, I'm going to go ahead and upload the xserver package with that fix you put in from earlier.  My reading of beta devel policy is that once freeze is in effect changes are held for review, so it'll automatically fall to the release team to allow targeted fixes through
[01:21] <bryceh> cnd, so it'll give them the option of including the fix in beta without forcing it
[01:22] <cnd> bryceh, that's fine
[01:22] <cnd> I don't think the release team likes me right now though...
[01:22] <cnd> :|
[01:22] <bryceh> ohsix, either one should be fine (they should be fairly close to the same code, and we can take care of porting fixes one way or the other once there is a validated/reviewed fix)
[01:22] <bryceh> cnd, oops, did you break something?
[01:23] <cnd> bryceh, no, I never break anything!
[01:23] <cnd> though that's not the issue :)
[01:23] <bryceh> hehe
[01:25] <bryceh> uploaded
[01:26] <ohsix> awesome, just about everything has changed since i last looked
[01:27] <cnd> heh
[01:30] <ohsix> http://cgit.freedesktop.org/xorg/driver/xf86-input-synaptics/commit/?id=ee99d4f7bc3374e8bac083ac4ea159f5da43db06 huhu, not it, but related
[01:34] <bryceh> [ubuntu/natty] xorg-server 2:1.10.0-0ubuntu2 (Accepted)
[01:34] <ohsix> cnd: http://cgit.freedesktop.org/xorg/driver/xf86-input-synaptics/commit/?id=ffa6dc2809734a6aaa690e9133d6761480603a68
[01:34] <bryceh> interesting; perhaps beta is not quite frozen yet?
[01:35] <cnd> bryceh, I blame you if xserver is broken :)
[01:35] <ohsix> emulateTwoFingerMinZ defaulted to a really high value so never let Synaptics devices to emulate 2-fingers by default. Changed default to a low value (same as FingerHigh)
[01:35] <ohsix> (from commit message)
[01:35] <ohsix> that min z is the threshold used in the heuristic i was talking about
[01:36] <bryceh> cnd, heh.  Well, I installed the debs on my desktop here and have been running it no prob, but this has a mouse not a touchpad so ymmv
[01:37] <bryceh> in any case, can't be any worse than what happened this morning
[01:37] <bryceh> (huge leak in water main due to tree roots breaking a pipe in my front yard)
[01:37] <bryceh> ((fun))
[01:37] <ohsix> cnd: i cheated and asked the guy who did it :D
[01:37] <TheMuso> bryceh: Ouch that is certainly not fun.
[01:38] <cnd> bryceh, oh man, not fun!
[01:38] <cnd> ohsix, hmmm, we could reverse patch that
[01:38] <cnd> bryceh, check out the commit ohsix pasted ^^
[01:39] <bryceh> cnd, reverse patching that is certainly doable
[01:39] <bryceh> will that solve it?
[01:39] <cnd> ohsix, do you know how to add that as a reverse patch to a debian package?
[01:40] <cnd> generate the reverse patch, stuff it into debian/patches/
[01:40] <cnd> and add it to debian/patches/series
[01:40] <ohsix> yea, but it probably wouldn't hurt to go over it again
[01:40] <cnd> yeah, then you would build and test it :)
[01:40] <cnd> and then you can post a debdiff in the bug or a merge request
[01:43] <ohsix> apparently EmulateTwoFingerMinW can be changed as well, rather than reverting it
[01:46] <cnd> ohsix, if you have something you want me to review, please subscribe me to the bug
[01:46] <cnd> my lp id is chasedouglas
[01:46] <cnd> that way I'll see it :)
[01:46] <cnd> eventually..
[01:48] <ohsix> what's the kung fu to generate a patch to revert automatically? i've always just edited the patches
[01:48] <ohsix> (mind you, not large patches)
[01:51] <ohsix> nm
[01:55] <rezbit> Quick question: I am interested to know if libsdl is compiled with GCC SSP and I don't know where in the documentation to find such information. https://wiki.ubuntu.com/GccSsp lists a few specific packages with problems.
[01:59] <bryceh> rezbit, I'm not familiar with libsdl, but in general you can 'apt-get source <package>' and then look in that package's debian/control to see what flags get passed to configure
[01:59] <ohsix> ok remind me how to build a package, fakeroot debian/rules or something? :D
[02:00] <YokoZar> hmm, why would one of the binary packages (of a multi-binary source package) not have a copyright file while the others would?
[02:00] <cnd> ohsix, did you use apt-get source?
[02:00] <cnd> or bzr?
[02:01] <ohsix> apt-get
[02:01] <RAOF> YokoZar: Because cdbs has symlinked it to one of its dependencies?
[02:01] <cnd> ohsix, ok, I'd suggest using debuild
[02:01] <YokoZar> RAOF: debhelper in this case
[02:01] <cnd> ohsix, just running debuild should do it
[02:01] <ohsix> ok
[02:02] <RAOF> YokoZar: I'm not entirely sure at what level the hoovering is done; it could be further down.  When you install the package is the copyright missing?
[02:03] <YokoZar> RAOF: yup, no copyright in the .deb...nor a symlink
[02:06] <ohsix> does whatever that applies patches not like diff --git format patches?
[02:07] <cnd> ohsix, it should work
[02:08] <bryceh> I usually use diff -Nurp fwiw
[02:08] <ion> Nurp derp, herp
[02:09] <RAOF> YokoZar: Well, then it would appear to be not what I'm thiking of.
[02:09] <YokoZar> RAOF: and thus stumps me too :(
[02:09] <micahg> YokoZar: cdbs package?
[02:09] <YokoZar> micahg: debhelper
[02:10] <micahg> no idea then
[02:10] <ohsix> maybe it would help if i checked out the right version ubuntu uses instead of using HEAD :D
[02:11] <RAOF> micahg: Yeah, we've covered that :)
[02:11] <cnd> ohsix, that would help :)
[02:11] <cnd> ohsix, if you'd rather, the real ubuntu packaging branch is kept in git
[02:12] <cnd> I forgot to mention that
[02:14] <lifeless> barry: reminder: https://bugs.launchpad.net/launchpad/+bug/608173
[02:18] <ohsix> well i checked out the right version & i'm probably doing other things wrong, but it doesn't apply when i run debuild, http://paste.ubuntu.com/585153/
[02:20] <cnd> ohsix, have you tried applying it manually?
[02:20] <cnd> to check that it will work
[02:22] <rezbit> bryceh: heh... http://svn.debian.org/wsvn/pkg-sdl/unstable/libsdl1.2/debian/patches/222_joystick_crash.diff?op=blame&rev=0&sc=0
[02:23] <rezbit> This is what caused me to look around for SSP in the first place. Apparently this isn't upstream yet.
[02:28] <ohsix> i cant figure this out D:
[02:28] <cnd> ohsix, I can try to help you out later
[02:28] <ohsix> k
[02:28] <ohsix> i'm gonna check out the bzr thing and try there
[02:29] <rezbit> hm... well it is in upstream SVN fwiw, but it's not in 1.2.14
[02:31] <cnd> ohsix, just to be clear, my definition of later is sometime next week
[02:31] <ohsix> i'll have it ready soon
[02:31] <cnd> I didn't want you waiting around for me in a few hours
[02:31] <cnd> :)
[02:31] <cnd> cause I'll be asleep
[02:32] <bryceh> rezbit, typically you can put in a bug to request the patch be backported.  If you don't get a response on it within a week (i.e. after beta is out) feel free to sub me to the bug and I'll sponsor
[02:34] <ohsix> ok
[02:34] <ohsix> patch applies
[02:34] <cnd> cool
[02:36] <ohsix> i just copied the file to a .new and edited it D:
[02:36] <ohsix> http://paste.ubuntu.com/585159/ looks pretty much the same to me, brb testing it
[02:38] <rezbit> bryceh: Well I don't have Ubuntu and gentoo doesn't have aptitude either. http://packages.ubuntu.com/source/maverick/libsdl1.2 is the closest I've seen to getting the source for the currently shipping libsdl1.2
[02:38] <rezbit> The bug exists in upstream 1.2.13-14
[02:39] <ohsix> yay, works
[02:39] <cnd> great
[02:39] <cnd> ohsix, do you know how to propose it using bzr and lp?
[02:41] <psusi> cjwatson, oh crap, beta freeze.. does that mean my dmraid/parted fixes didn't make the cut, or can you still sneak that through?
[02:41] <ohsix> cnd: nope
[02:41] <cnd> ohsix, ok, push to lp:
[02:42] <ohsix> with what credentials
[02:42] <cnd> bzr push lp:~<your lp id>/ubuntu/natty/xserver-xorg-input-synaptics/<some branch name>
[02:42] <cnd> the branch name could be lp<bug number>
[02:42] <cnd> or something descriptive
[02:42] <ohsix> does bzr have changesets, do i need to apply it there then push; i've never used bzr
[02:42] <cnd> like "no-touch-size-emulation"
[02:42] <cnd> bzr, oh, you need to commit locally
[02:43] <cnd> bzr commit
[02:43] <psusi> holy crap! multiarch support has arrived?  I thought that was given up on years ago!
[02:43] <ohsix> psusi: you didn't notice all those FFe's for multiarch? :D
[02:43] <RAOF> psusi: No; like a peat fire it merely simmered underground :)
[02:44] <psusi> ohsix, feature freeze exceptions?  where would I have seen those?
[02:44] <ohsix> psusi: in changelogs for package updates in natty
[02:44] <psusi> ohsix, I've actually not switched to running natty yet.. still on maverick with just a few packages upgraded to natty versions
[02:44] <ohsix> i see
[02:45] <slangasek> given up, hah
[02:46] <cnd> slangasek, is this revenge after being the release manager for previous releases?
[02:46] <psusi> it didn't seem stable enough yet and then a bug cropped up in partman-auto that hangs the installer for me a few weeks ago... I guess I need to just take a dump and dist-upgrade
[02:46] <psusi> slangasek, I remember being very interested in that and discussing it a good bit with some people I think are no longer around back in like, 2005
[02:46] <psusi> then I wondered off and got sucked into an MMO for a few years...
[02:47] <slangasek> cnd: hmm?  I hope no one finds it vengeful :)
[02:47] <cnd> heh
[02:47] <bryceh> ohsix, for -synaptics if you have tested the patch and verified it works, and gotten a thumb's up from cnd, I can take it the rest of the way in for you if you'd like
[02:47] <bryceh> ohsix, just need the bug # and patch
[02:47] <ohsix> bryceh: that would be great
[02:47] <cnd> bryceh, I'd like to take one last review of that block of code
[02:48] <psusi> I didn't think it was really even very desirable anymore... haven't all of the issues been worked out?  64 bit flash support and such?
[02:48] <ohsix> the bug isn't exactly apropos, it was about asking for ui to change it, not disable it https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/739916
[02:48] <ohsix> i could add a comment about the ui not being able to be changed, and the patch to disable it if it's needed
[02:48] <cnd> ohsix, I think we should open a different bug then
[02:48] <slangasek> psusi: there are lots of little reasons to want multiarch, flash is just one of them
[02:49] <slangasek> (and no, I wouldn't say 64-bit flash has been "worked out")
[02:49] <ohsix> cnd: the reason i filed that way is i can't think of a good way to file the other bug, spurious right click events? i know too much! :D
[02:50]  * psusi pours gasoline on flash and lights it on fire, then does the same for pdf
[02:50] <rezbit> flash... argh
[02:50] <ohsix> i'll file another
[02:50] <bryceh> cnd, ok
[02:50] <bryceh> ohsix, cnd, agreed that a new bug for this specific issue would be best; ohsix would you mind filing one?
[02:50] <ohsix> should i put like, caused by git commit hash, or just propose the patch
[02:51] <cnd> ohsix, it would be a good idea to reference the git commit
[02:51] <cnd> but attaching the patch would also help
[02:51] <cnd> since you've got it handy
[02:51]  * lamont wonders why cups is asking for a root password when shadow has root:!:...
[02:51] <ohsix> does lp detect comments made as patches as patches, or do i need to attach a file
[02:52] <psusi> wait, what about the libraries needs "transitioned" to multiarch?  I thought the whole point was to take an unmodified i386 package and install it on amd64, moving things to the correct 32bit directories in the process?
[02:52] <psusi> ohsix, attach file
[02:52] <cnd> ohsix, when you make the new bug report, subscribe me to it
[02:52] <ohsix> ok
[02:53] <cnd> thanks
[02:53] <cnd> and thanks for testing the change out :)
[02:55] <slangasek> psusi: no, the point of multiarch is to fix the packages so that there's no "moving" things upon installation, since that breaks compile-time path references
[02:56] <ohsix> all done https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/742213
[02:56] <psusi> slangasek, what do you mean?  I thought the main problem was dynamic linking.. and the 32 bit dynamic linker looks in /lib32 instead of /lib or /lib64, and when installing an i386 package, anything that says /lib got redirected to /lib32?
[02:57] <slangasek> no, the *main* problem is the many libraries that load plugins from a predetermined path
[02:57] <rezbit> bryceh: I The fact that this bug is two years leads me to speculate that it's triggered by SSP and silently corrupts information otherwise. Maybe I am jumping to conclusions?
[02:57] <rezbit> oops. well he's not back from the netsplit yet.
[02:57] <psusi> ohh... isn't that a big no-no to begin with?  it's supposed to let ldconfig resolve paths
[02:58] <slangasek> psusi: not in the least.  ldconfig is for resolving library paths, it doesn't help for plugins
[02:58] <slangasek> not when you want them in per-application directories
[02:58] <psusi> plugins are libraries
[02:58] <slangasek> no, they aren't
[02:58] <slangasek> they're dynamic shared objects
[02:58] <psusi> dso = library by another name?
[02:59] <slangasek> a library is a specific kind of dynamic shared object - one with an soname, that you link against
[02:59] <slangasek> psusi: e.g., how would you propose libpam manage to use ld.so to look up the modules in /lib/security?
[03:01] <psusi> slangasek, readdir() or a config file and then ldopen()?
[03:01] <slangasek> ld.so doesn't implement either of those things for you
[03:01] <slangasek> and where do you put the config file so that it's unique on a per-architecture basis?
[03:01] <psusi> by the time Linux started really adopting shared libs, I had already gotten used to dlls on windows, so my understanding of shared libs quite likely makes some assumptions that things are the same as a dll when they aren't
[03:01] <slangasek> you've just moved the pieces around, you haven't solved the problem of conflicting paths built into the binaries
[03:03] <psusi> slangasek, I see... so the config file says load foo.so, which is assumed to be in /some/path, and so it calls ldopen() on that path, which bypasses ldconfig?  ldconfig is only used for libraries that were linked at compile time?
[03:05] <slangasek> dlopen() can resolve relative paths for you by searching the system path, and the system path can vary by architecture, but almost no upstreams do it that way in practice
[03:05] <psusi> slangasek, so basically, plugins need to be loaded from /lib32 or /lib64 explicitly, rather than /lib?
[03:05] <psusi> though I thought dlopen() was going to be patched to automatically rewrite /lib to the appropriate one
[03:06] <slangasek> er, I don't know who proposed doing /that/, but it wasn't me :)
[03:07] <psusi> iirc, the idea was that since a different ld.so is run by the kernel depending on if the executable is 32bit or 64bit, it would know whether references to /lib ( or /usr/lib, etc ) should really be 32 or 64
[03:08] <slangasek> I understand the idea, but that's not what's been agreed and implemented
[03:08] <psusi> ohh... why is that?
[03:09] <RAOF> It would seem pretty magical.
[03:09] <slangasek> for one thing, having ld.so doing magic to rewrite paths out from under you is horribly ugly
[03:09] <slangasek> for another, there are other kinds of architecture-dependent files besides DSOs at issue
[03:14] <rezbit> bryceh: Nevermind, this is fixed in maverick release. The fact that this bug is two years with no issues on gentoo leads me to speculate that it's triggered by SSP and silently corrupts information otherwise. Thanks for your help anyway.
[03:15] <rezbit> two years old*
[03:51] <StevenK> RAOF: Did you end up looking at Quod Libet?
[03:51] <RAOF> Oh!  *That's* why I've got the software centre open!
[03:51] <RAOF> (You may take that as a “not yet”)
[03:51] <TheMuso> heh
[03:54] <ohsix> you know the quod libet guy can't ride a bike or swim
[03:54] <StevenK> What does the have to do with the price of fish?
[03:54] <ohsix> and started the ill fated dx11 on xp project :D
[03:54] <ohsix> it's a fun anecdote :D
[03:54] <ohsix> he worked for linspire & theres a video floating around of him trying to ride a bike
[03:54] <RAOF> You know, mesa could probably provide dx11 on XP reasonably easily.
[03:55] <ohsix> it's not just adapting the rendering api though; there are places where it leaks into windows implimentation
[03:56] <RAOF> Hands up all those who can't right click on anything in the launcher without compiz crashing! o/
[03:56] <ohsix> s/dx11/dx10
[03:57] <ohsix> it was only a sideshow until he started charging people to get releases that didn't do anything D:
[03:57] <RAOF> Well, there's a dx11 state tracker in mesa at least.
[03:58] <RAOF> Heh.
[03:59] <RAOF> The nux crash in GrabPointer has been fixed… and replaced by a crash in GrabKeyboard!
[03:59] <ohsix> drag & drop on the panel is also broken, though how; i have no idea
[03:59] <StevenK> RAOF: Does that mean it's installed now? :-)
[04:00] <RAOF> StevenK: Indeed it is.
[04:00] <robbiew> RAOF: apologies for have the old kernel....REALLY weird...apt-get dist-upgrade won't budge on it
[04:00] <RAOF> robbiew: The other logs attached to that bug suggest that you've actually *got* the 2.6.38-7-generic kernel installed, you're just not using it.
[04:01] <robbiew> yeah...but I don't
[04:01] <robbiew> I checked
[04:01] <RAOF> Oh.
[04:01] <robbiew> system is confused
[04:01] <RAOF> You've got nvidia-current built against it, though :)
[04:01] <StevenK> robbiew: You have the headers, but not the kernel itself?
[04:02] <robbiew> hmm...maybe
[04:02] <robbiew> yep
[04:02]  * StevenK wins.
[04:02] <robbiew> but how the hell did I get the headers only
[04:02] <ohsix> not having the virtual that pulls them all in?
[04:02] <StevenK> robbiew: /var/log/dpkg.log might help tell you.
[04:04] <RAOF> StevenK: Booo.  Quod Libet doesn't mpris it up.  That said, it's got a simple dbus interface, so it'd be the work of ½ an hour to whip a plugin up.
[04:06] <StevenK> RAOF: I can't see a mpris plugin for Quod, either.
[04:07] <StevenK> RAOF: Pity I don't know C# :-)
[04:07] <RAOF> You could try an IronPython plugin :)
[04:07] <RAOF> Or IronRuby.  How about F#? :)
[04:08]  * StevenK books a flight so he can stand over RAOF until he writes it. :-P
[04:16] <StevenK> RAOF: http://code.google.com/p/quodlibet/source/browse/plugins/events/mpris.py?spec=svn06b6519551f11dc084e7465cde47b8e520837c74&r=06b6519551f11dc084e7465cde47b8e520837c74
[04:18] <RAOF> StevenK: Ah, sweet.  I'll just go and write an mpris-control plugin then.
[04:18] <StevenK> RAOF: Is that even easier?
[04:18] <RAOF> No, but it'll work for more players.
[04:19] <RAOF> It's almost exactly as easy, but more general.
[05:08] <NCommander> @pilot on
[05:08] <udevbot> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
[05:08] <NCommander> @pilot in
[05:12] <NCommander> evening all
[06:46] <phsi> hmm, newest pulse in natty has pulseaudio-module-raop as hard dependency
[06:46] <phsi> which in turn depends on zeroconf
[06:46] <phsi> and this then brings in all the avahi shit
[06:46] <phsi> is this getting fixed?
[06:48] <RAOF> Is there a bug filed?  I'm not sure if there's some reason why -raop can't be Recommended rather than Depended on.   Also:
[06:48] <RAOF> !ohmy > phsi
[07:05] <pitti> Good morning
[07:06] <nigelb> Guten Morgen pitti :)
[07:23] <bryceh> heh
[07:23] <bryceh> !ohmy > bryceh
[07:23] <bryceh> kewl
[07:23] <micahg> !msgthebot > bryceh
[07:23] <micahg> :)
[07:24] <bryceh> micahg, what you don't like me playing with my bots in public?  ;-)
[07:24] <cdbs> micahg: It creates unnecessary backlog
[07:24] <cdbs> oops
[07:24] <cdbs> bryceh: ^
[07:24] <micahg> as does this whole conversation ;)
[07:24] <cdbs> bryceh: When you can !msgthebot its better, and cleaner
[07:40] <dholbach> good morning
[08:29] <didrocks> good morning
[08:33] <mvo> kklimonda: hi, I just looked at your pangomm (and friends) branches, thanks for them! it appears Murray has a new tarball without the need for mm-common
[09:25] <kklimonda> mvo: does it really matter? mm-common already got a MIR, so I've assumed it's only a matter of uploading packages that depend on it to pull it to main? I've not yet read email, so I may be missing something :)
[09:26] <mvo> kklimonda: it does not much matter, no :)
[10:27] <pitti> tseliot: oh, so can we remove displaydepth for 96 and 173 as well? that would indeed make xorg.conf a lot simpler
[10:28] <tseliot> pitti: I'm not sure as to whether that option is automatically applied if a xorg.conf exists. Sarvatt should know more about this
[10:29] <pitti> tseliot: ok, thanks; it at least was confirmed that it works for -current
[10:41] <NCommander> @pilot out
[10:48] <soren> How is component-mismatches generated?
[10:50] <soren> I'm trying to generate a list of packages that would need an MIR if a particular package were to be seeded. I'm not sure if the tool that generates component-mismatches might be of use.
[10:52] <soren> So far I'm using germinate, but by default it only looks at main, and just refuses to add packages that have dependencies in universe, so there must be something else that can help me out.
[10:53] <soren> Hmm... Or perhaps it's refusing to add the package because it itself is in universe, but it seems to me the result is the same.
[11:00] <soren> cjwatson: Perhaps I could borrow your brain for a couple of minutes? Pretty please? :)
[11:03] <cjwatson> soren: you can tell germinate which components to look at - it's a command-line option
[11:03] <cjwatson> so you run germinate against all components, and then compare against what's currently in main
[11:03] <cjwatson> the rest is basically bookkeeping
[11:03] <soren> cjwatson: Indeed.
[11:04] <soren> cjwatson: How does component-mismatches do it?
[11:04] <soren> surely not like this?
[11:04] <cjwatson> why not?
[11:04] <soren> Does it?
[11:04] <cjwatson> (actually, Launchpad has already run germinate for it; it just uses the output.)
[11:05] <soren> But for germinate to consider stuff in universe at all.. Err..
[11:05] <cjwatson> it's perfectly reasonable if you're asking conditional questions
[11:05] <soren> Does Launchpad run germinage with universe "enabled"?
[11:05] <cjwatson> yep
[11:05] <soren> Oh.
[11:05] <soren> Oh, ok.
[11:06] <soren> ..and then component-mismatches compares with Packages (and Sources, I suppose)?
[11:07] <cjwatson> http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/view/head:/cronscripts/publishing/cron.germinate <- how LP runs germinate
[11:08] <cjwatson> I'll mail you the dire hacky scripts that do c-m
[11:08] <cjwatson> I doubt they'll be runnable directly out of context
[11:09] <soren> cjwatson: Thanks very much.
[11:09] <StevenK> When I do MIR work to see what needs to be promoted, I do it all by hand. :-/
[11:09] <soren> cjwatson: I tried to find that cron thing, but I don't have an lp checkout handy and I'm working out of a coffee shop today.. Checking out lp would take days :)
[11:10] <soren> StevenK: That's very useful info. Thanks.
[11:10] <cjwatson> it's not in LP
[11:10] <cjwatson> well, cron.germinate is, the other bits aren't
[11:10] <soren> ~launchpad-pqm/launchpad/devel looks very..
[11:10] <soren> Ah, right.
[11:10] <StevenK> And yes, that's LP main trunk.
[11:11] <soren> Exactly, hence my confusion about "it's not in LP" :)
[11:55] <mdeslaur> @pilot in
[11:57]  * dholbach hugs mdeslaur
[11:57] <dholbach> smoser, you might want to unpilot yourself :)
[11:58] <MadRobot> Hi all.
[11:58] <MadRobot> May make a small suggestion?
[11:59]  * mdeslaur hugs dholbach 
[11:59] <MadRobot> Why don't you replace the default media player "Mplayer" with another one such as VLC?
[12:00] <directhex> mplayer isn't the default media player.
[12:00] <MadRobot> directhex, what is?
[12:00] <Pici> Totem.
[12:00] <directhex> totem
[12:00] <MadRobot> I see.
[12:01] <MadRobot> lol, I thought they were the same thing. :P
[12:01] <directhex> vlc plays more or less anything. which is good. but there are two downsides.
[12:02] <directhex> first, it's not possible to split vlc's codec support up. totem uses the gstreamer framework to install codecs on demand. this is important from a legal standpoint, since the mp3 patent holders demand a license fee for preinstalled mp3 players - and other codecs may suffer similar issues. codecs are a patent minefield, and gstreamer makes it easier to ship only a subset by default
[12:03] <directhex> secondly, it's a usability disaster. although i wish totem were more configurable, vlc goes waaaaaay too far
[12:03] <MadRobot> directhex, I see.
[12:04] <directhex> MadRobot, i don't think anyone's opposed to a better media file player if one comes along, but i don't think vlc is a possible move
[12:04] <MadRobot> Anyways, I guess you're right. Totem can stick around, and if I'm not  comfortable with it, I can simply use something else. :)
[12:04] <MadRobot> directhex, I agree.
[12:05] <MadRobot> Or, there's another option, that Totem receives some more polishing and improvements.
[12:06] <directhex> yes, that's a good option
[12:07] <MadRobot> The fellows at the Totem project need to put some more effort at making Totem a little less buggy, imho. -_-
[12:08] <directhex> MadRobot, if you have specific issues, you should file bugs about them
[12:09] <MadRobot> directhex, yeah, but the problem is that I'm not sure how to write and document these bugs.
[12:09] <MadRobot> They have to do with it
[12:09] <MadRobot> streaming .avi videos.
[12:10] <MadRobot> It some times slows down, or even crashes.
[12:19] <mdeslaur> pitti: what's your opinion on the patch in #711549?
[12:29] <pitti> mdeslaur: ah, I think I saw these fly by
[12:29] <pitti> mdeslaur: back then I thought kay wanted to use the in-kernel polling (which is really the right way to fix this)
[12:30] <mdeslaur> pitti: yes, but meanwhile it's a big user-visible bug
[12:30] <mdeslaur> pitti: (and one of my personal pet-peeves for the past couple of releases...)
[12:31] <pitti> mdeslaur: yeah, I guess we need to revisit applying it until the in-kernel stuff gets used
[12:32] <mdeslaur> pitti: should I ask for a freeze exception and push it to natty?
[12:32] <pitti> mdeslaur: I don't think it's urgent enough to squeeze into beta-1
[12:33] <pitti> mdeslaur: I'd really like to avoid distro-patching; I'd prefer pushing it upstream and then applying in Debian and syncing
[12:33] <pitti> we've been through this in hal
[12:33] <mdeslaur> pitti: ok, I'll leave it be. thanks
[12:33] <pitti> mdeslaur: so feel free to discuss with kay or davidz in #udev, otherwise I'll add it to my queue
[12:34] <ari-tczew> wgrant: are you going to upload a fix for loggerhead for natty?
[12:35] <pitti> mdeslaur: the spirit of the patch seems fine, but the implementation should be improved IMHO
[12:36] <pitti> mdeslaur: e. g. udisks already knows whether a device is mounted, no need to parse /proc/mounts etc.
[12:37] <mdeslaur> pitti: ah, ok....I'll let you handle the bug then since you're familiar with udisks
[12:37] <pitti> mdeslaur: I'll keep the tab open; doing HR stuff and release meeting today, but something nice to hack on next week
[12:39] <mdeslaur> pitti: cool, thanks
[12:39] <hallyn> jbernard: so, to do a libcgroup sync request we first need the fix in debian unstable, right?
[12:39] <mdeslaur> patch piloting during freeze isn't very productive :)
[12:39] <pitti> mdeslaur: yeah :(
[12:39] <wgrant> ari-tczew: We'll sync it from Debian in a day or two.
[12:39] <pitti> mdeslaur: well, universe isn't frozen
[12:40] <ari-tczew> pitti: but new features needs FFe right?
[12:41] <ari-tczew> wgrant: so can I unsubscribe sponsors from bug?
[12:41] <wgrant> ari-tczew: Indeed.
[12:42] <hallyn> is there a workaround for using apport-collect to an existing bug from a console (which fails due ot no launchpad login)?
[12:43] <hallyn> or, if it failed at that stage, is the data cached somewhere so the user can later log in and manually post the files collected by apport?
[12:45] <pitti> ari-tczew: right
[12:51] <jdstrand> didrocks: hey, would you mind milestoning bug #741942 (the one I reported yesterday)?
[12:52] <didrocks> jdstrand: hum, seems launchpad timeouted, I milestoned it already as well send it in the priority list for dx
[12:52] <didrocks> jdstrand: done :)
[12:53] <jdstrand> didrocks: thanks! :)
[12:53] <didrocks> jdstrand: you can thank me and dx once it's fixed ;-)
[12:53] <jdstrand> didrocks: you can bet I will. I miss my unity :)
[12:53] <didrocks> heh ;)
[12:54] <didrocks> jdstrand: if we get some fixes that can't go into beta, I'll maybe setup a backported version in a ppa so that you can test it
[12:54] <jdstrand> didrocks: I'd be happy to
[13:08] <mterry> Heyo, general announcement: I'm considering applying for core-dev and would appreciate comments/endorsements if anybody has any https://wiki.ubuntu.com/mterry/CoreDev
[13:12] <smoser> @pilot out
[13:13] <cjwatson> jibel: can you confirm whether the Asus U3SG system you had where Plymouth failed to cope with the framebuffer switch (https://wiki.ubuntu.com/FoundationsTeam/Grub2BootFramebuffer/Whiteboard) is now working more smoothly?  I believe that it should, now that we don't do the vesafb->KMS dance any longer
[13:15] <jibel> cjwatson, I haven't rebooted it for quite some time. I'm trying that right now, brb
[13:26] <jibel_> cjwatson, not back as fast as I expected, but well I'm here.
[13:27] <jibel_> cjwatson, first there is something strange, the grub background is a debian background
[13:28] <jibel_> cjwatson, then the screen becomes black for 4s, then ubuntu log + dots, then quick flicker and the logo is back but the dots are not blinking anymore and finally it switch to X
[13:30] <cjwatson> jibel_: you probably have desktop-base installed
[13:31] <cjwatson> jibel_: the rest of it sounds largely as expected for the moment - thanks!
[13:35] <jibel_> cjwatson, okay, desktop-base is installed because of the dependencies: gnome-accessibility -> gnome-core -> desktop-base
[13:36] <kirkland> does anyone here have a thinkpad x201 working with a docking station and external video in Natty?
[13:37] <kirkland> bryceh: ^
[13:38] <cjwatson> jibel_: that issue is on https://wiki.ubuntu.com/FoundationsTeam/Grub2BootFramebuffer/Whiteboard though
[13:38] <cjwatson> it's the last one that has known specifics
[14:06] <ari-tczew> vish, cdbs: I'm looking on amule package and it seems to be fine for me for sync. However, there is your delta to fix description in d/control. Debian didn't accept it. What's next?
[14:10] <ari-tczew> mvo: what do you think, should do we keep delta in Ubuntu for improve description? bug 602717
[14:11] <jbernard> hallyn: yep, im working on a new upstream release now
[14:11] <hallyn> jbernard: awesome, thx
[14:11] <jbernard> hallyn: i should have some time this weekend to finish it up
[14:13] <cdbs> ari-tczew: Merge then
[14:15] <ari-tczew> cdbs: my question is whether it's really necessary to store in ubuntu
[14:16] <zul> pitti: i just uploaded landscape-client for maverick-proposed can you reject it please?
[14:17] <mvo> ari-tczew: ideally we would have a overwrite mechanism via LP, but that is not done yet
[14:17] <pitti> zul: not in the queue yet
[14:18] <zul> pitti: ok nm then
[14:18] <zul> pitti: just a preemptive strike but its not needed
[14:18] <pitti> zul: how so?
[14:18] <zul> pitti: it got rejected before it hit the queue thanks anyways
[14:19] <cdbs> ari-tczew: It very much is
[14:20] <pitti> zul: ah, heh :)
[14:20] <cdbs> ari-tczew: We have sometimes diverged from Debian just for that
[14:20] <cdbs> ari-tczew: Its an Ubuntu effort. If debian rejects, we keep the delta
[14:20] <ari-tczew> mvo: ok but what's your decision - keep it and merge or drop it and sync?
[14:21] <pitti> jdstrand, kees: releasing the missing linux-restricted-modules-2.6.15 for dapper; not sure whether that needs an USN?
[14:21] <ScottK> cdbs: Not always.  You have to ask if it's worth the effort of merging all the time to keep the benefit of the change.
[14:22] <ScottK> For small edits in the package description my answer is usually no.
[14:23] <ari-tczew> +1 ^^
[14:23] <vish> ScottK: then what is the use of actually fixing issues, if we are going to revert them later?
[14:23] <cdbs> ScottK: Well, I heard jcastro did ask the DDs about it, who had a mixed opinion on the description changes. So we decided to keep it when we can
[14:23] <mvo> ari-tczew: I look after the call
[14:23] <vish> we could just as well say we dont want to fix such bugs in Ubuntu
[14:23] <cdbs> +1 ^
[14:24] <cdbs> ari-tczew, ScottK: We are building up a system aimed at newcomers, not geeks
[14:24] <cdbs> ari-tczew, ScottK: Let me give you an example:
[14:25] <jdstrand> pitti: ack. I'll review it, thanks
[14:25] <cjwatson> we also have finite resources which should be spent carefully
[14:25] <cjwatson> (not that I feel strongly one way or the other in this case, but it's not true that one consideration uniformly outweighs the other)
[14:25] <cdbs> Package frozen-bubble had a description containing information about some rumour which blamed the package frozen-bubble responsible for the delay of Debian Woody release
[14:26] <cdbs> ari-tczew, ScottK: Such a description won't be relevant for display in something like software center
[14:26]  * ari-tczew is off for lunch. afk.
[14:26] <ScottK> I'm not saying there aren't cases where maintaining such a diff is inappropriate, I'm just saying usually not.
[14:27] <pitti> ScottK +1
[14:27] <vish> cjwatson: ACK, but we need to be clear with what we want to do. We are requesting people to file bugs, then we have people reviewing those bugs and later we have people actually writing a new description for those packages and finally someone fixes it … why all this work when we are going to revert later?
[14:27] <pitti> and less so for a rather harmless joke like in f-b IMHO
[14:28] <pitti> vish: IMHO the correct course of action for this is to forward the patches to the Debian BTS, and declare it done on our end
[14:28] <cjwatson> vish: this just means that it's also worth spending effort in persuading people upstream of us to accept the change
[14:28] <pitti> (if that would be the only delta we have)
[14:28] <cjwatson> rather than considering the job done when it's in Ubuntu
[14:28] <vish> pitti: we do forward,, but debian rejected.. saying it is not an issue
[14:28] <vish> for them*
[14:28] <cjwatson> and that will happen occasionally, but it doesn't mean it isn't worth trying to minimise our delta in general
[14:28] <cdbs> Because Debian has its own guiding principles which clash with ours at times
[14:29] <cjwatson> it's just the same for code changes - occasionally we have to decide whether keeping a delta is worth it, and sometimes the answer is yes and sometimes no
[14:29] <cdbs> Well, I fixed the bug. At a time when I wasn't MOTU. At that time even a small upload in my name made a huge difference.
[14:29] <Sarvatt> hello libx11 klingon.. :P
[14:29] <pitti> Sarvatt: nuQneH?
[14:30]  * cdbs g2g
[14:31] <Sarvatt> that's one delta we'll carry forever because noone wants it :)
[14:31]  * vish just a middleman stuck between the design team and MOTU :D
[14:34] <cjwatson> mvo: are you ready to upload that sudo change?
[14:34] <cjwatson> mvo: oh, never mind, I see it in the queue
[14:34] <mvo> cjwatson: its uploaded, waiting for review
[14:36]  * cjwatson reviews and accepts
[14:40] <cjwatson> mterry,TheMuso: any further progress on deciding on bug 730759?
[14:43] <mterry> TheMuso, cjwatson: putting dbus-c++ back in libffado is sort of sleight of hand.  It's still arguably unmaintained code.  But it does highlight the fact that we've had this chunk of unmaintained code already in main...  I remember that the Debian folks wanted it to remain a separate lib
[14:44] <cjwatson> yeah, I don't see shoving it back into libffado as being a particular improvement
[14:44] <mterry> TheMuso, so I'm not clear on the end result of the offer to co-maintain it?
[14:44] <cjwatson> I don't know much about it, I'm just conscious of its continued presence on c-m
[14:48] <superm1> mtaylor, it's a bit unclear to me why this MIR needs to happen though; ubuntu studio can build from universe, no?
[14:51] <mterry> superm1, was that to me?
[14:51] <superm1> you were the one approving the MIR on libffado right?
[14:51] <mterry> superm1, sure, you just asked mtaylor is all
[14:51] <superm1> oh yeah, oops, tab completion :)
[14:52] <mterry> superm1, I don't know about studio building from universe.  I thought it didn't.  I guess the question is who rdepends on libffado
[14:53] <superm1> well originally it was a set of packages common to ubuntu studio and mythbuntu; jack
[14:53] <superm1> mythbuntu dropped all the jack depends to get out of this mess
[14:53] <superm1> clearly mythbuntu can build from universe/multiverse, so i had *thought* ubuntu studio could too
[14:53] <holstein> hello
[14:54] <holstein> im noticing some ubuntustudio talk
[14:54]  * holstein reading scrollback
[14:54] <mterry> superm1, what's the rule for that?  I assume officially supported flavors must build from main only, others whatever?
[14:54] <cjwatson> superm1: libffado is in main because jack uses it
[14:54] <mterry> cjwatson, sure, but question was then why is jack in main?
[14:54] <cjwatson> its (build-)dependencies need to be in main, regardless of what mythbuntu/studio use
[14:54] <holstein> and having it in main means as an end user, we can have JACK support out of the box
[14:55] <cjwatson> pulseaudio and a bunch of other things build-dep on jack
[14:55] <holstein> in most aps
[14:55] <cjwatson> alsa-plugins, gst-plugins-good0.10, portaudio19, xine-lib
[14:55] <cjwatson> so it has to be in main for those
[14:55] <mterry> k
[14:55] <superm1> ok that's clearer to me
[14:56] <cjwatson> barry: are the recent comments on bug 711225 enlightening?  Martin seems to need interpreter help at this point
[14:56] <cjwatson> barry: also, can you update me briefly on the state of bug 724327?
[14:57] <cjwatson> ISTR some MIR activity there ...
[14:58] <barry> cjwatson: looking...
[14:58] <cjwatson> hmm, python-launchpadlib seems to depend on python-keyring now
[14:58] <ari-tczew> pitti, cjwatson: so do you confirm that we can drop this one change in description?
[14:58] <barry> cjwatson: yes, i think that's been so for several weeks now
[14:58] <cjwatson> ah, dup bug - I'll close that
[15:00] <pitti> ari-tczew: for frozen-bubble? sure
[15:00] <ari-tczew> pitti: no, for amule - discussion with vish and cdbs
[15:01] <ari-tczew> from other hand they see a problem in workflow in Ubuntu - community give patches which will be dropped in future
[15:01] <ari-tczew> but that's the system - if Debian rejects patch, we're dropping it
[15:01] <barry> cjwatson: re: bug 711225.  no, the comments just add to the confusion. ;)  but pitti provided a way to reproduce it so i'll investigate that today.
[15:02] <vish> ari-tczew:  then why even have a system that supports uploading a patch in Launchpad :)
[15:02] <ari-tczew> vish: uploading? do you mean attaching to bug?
[15:03] <vish> i like Kubuntu workflow, they are clear where the bug and issues need to be fixed
[15:03] <vish> this is like flip-flopping, if some MOTU later doesnt have time to merge, we will drop your earlier effort
[15:04] <vish> ari-tczew: yea, i meant attaching …
[15:04] <pitti> barry: I really can't make head and tail of that one :/ I started at the python code for quite some time, but I don't see anything wrong with it
[15:05] <ari-tczew> vish: I think the best way to resolve this issue (in general, not in this case) is send an e-mail to TB.
[15:06] <vish> probably.. but I'm not sure this is such a huge issue to poke TB
[15:06] <barry> pitti: indeed, the description is pretty confusing!  i'll probably need to gdb the python process to dig deeper.  sounds like a fun one for a friday :)
[15:06] <vish> ari-tczew: what happens if we dont sync/merge?
[15:07] <cjwatson> barry: thanks
[15:07] <barry> cjwatson: should i assign it to myself?
[15:07] <cjwatson> barry: if you could, please
[15:07] <ari-tczew> vish: then we won't get news in amule in Debian
[15:07] <cjwatson> vish: as I say, this underlines that the job is not done when the patch is in Ubuntu - there is still care and feeding involved as long as there's a delta, and I think some of that should be on the shoulders of the people who incorporated the patch into Ubuntu
[15:08] <vish> right, then we could wait for cdbs to do a merge
[15:08] <tumbleweed> vish: (sorry haven't been following this from the start, but here goes) why not push these to Debian as soon as possible? I don't want to create a delta in ubuntu for just a description change, I'd rather push it to Debian first
[15:08] <ari-tczew> tumbleweed: Debian has rejected patch
[15:08] <vish> tumbleweed: Debian rejected the patch
[15:08] <tumbleweed> ari-tczew: aah
[15:08] <vish> yea
[15:08] <pitti> barry: may the source be with you! yes, it looks like a "fun" one..
[15:09] <tumbleweed> I guess if we really want it we have to do the work then
[15:09] <barry> pitti: hopefully it will result in a blog post a little less fascinating and frightening as cjwatson's on the wubi bug :)
[15:09] <vish> IMO, if no one has the time to merge, let's just not have the new package, if someone feels strongly about having the new package, they could do the merge
[15:10] <tumbleweed> generally we try to encourage the person who made the change to do future merging
[15:10] <vish> yea, thats why i mentioned, we could just wait for cdbs to get to a merge
[15:10] <ari-tczew> vish: look, when you want to keep this small change you have to spend a time on merging package every time when Debian has released new reiviosn
[15:10] <ari-tczew> revision
[15:11] <ari-tczew> there is a question whether the time which has spent on merging is worth?
[15:11] <ari-tczew> because it won't be one time on merging
[15:11] <ari-tczew> every time
[15:11] <cjwatson> vish: Ubuntu policy is to merge globally; while there are exceptions where it's hard, any case where we aren't keeping up to date is a problem
[15:11] <vish> ari-tczew: why not wait for cdbs ? has cdbs refused to merge? he is a MOTU too
[15:12] <Riddell> jdstrand: I think it's your archive admin day, bug 742377 has an upload in hardy-backports -Q unapproved
[15:12] <cjwatson> (that said, we are in feature freeze.  there should be no reason to worry about merging now - the merge push is in the first part of the release cycle)
[15:12] <vish> if the previous uploader doesnt care about his effort, then dropping seems reasonable. but why just not let the MOTU do his work
[15:12] <tumbleweed> vish: I think this is being morphed into a more general question: is keeping a patch like that worth the effort for the MOTUs in general
[15:12] <vish> tumbleweed: yup. :)
[15:12] <jdstrand> Riddell: ok, thanks
[15:13] <ari-tczew> for me it's not worth
[15:13] <ari-tczew> and cjwatson has got a good point, ATM merge is not really needed
[15:13] <ari-tczew> however, they added some small fixes
[15:15] <ari-tczew> vish: feel free to merge it, this is your time
[15:15] <ari-tczew> personally I wouldn't spend time on that small change
[15:16] <vish> ari-tczew: previous uploader is cdbs :) , I'm not MOTU, lets just wait for him
[15:16] <ari-tczew> vish: no, it's not cdbs
[15:16] <ari-tczew> it's shankhao and tumbleweed has sponsored this one
[15:17] <vish> hmm..
[15:18] <vish> oh well, this is my opinion:  "<vish> IMO, if no one has the time to merge, let's just not have the new package, if someone feels strongly about having the new package, they could do the merge."  I'm not a MOTU, so i dont really have much say in this do I? ;p
[15:18] <cjwatson> I'm afraid standing policy is otherwise
[15:19] <cjwatson> I mean, obviously it's reality that somebody has to have the time to deal with it, but the policy of the development community as a whole is that somebody should make time. :-)
[15:19] <vish> :-)
[15:19] <cjwatson> (either for a merge or a sync, one way or the other)
[15:19] <tumbleweed> vish: you do. All that's needed here is a sponsor. You can request a sync or a merge and if the sponsor agrees that it looks like a good idea, it'll happen
[15:20] <vish> tumbleweed: it would be like me chasing my tail, next cycle again this same question will arise..
[15:20] <vish> however, I'm all for cloning mvo , if we have more of him we might have less of this problem ;)
[15:21] <tumbleweed> hah. indeed, which is why syncing might not be a bad idea (I don't know what package this is, so I haven't looked at the change)
[15:22] <ari-tczew> right, we still don't have mvo's feedbach. the change is related to be useful for software center.
[15:22] <ari-tczew> tumbleweed: amule
[15:23] <vish> ari-tczew: there is a roadmap to allow user-generated descriptions, but mvo is stretched too thin :)
[15:23] <vish> *LP roadmap
[15:24] <tumbleweed> aah. It doesn't look like a particularly important description change, I'd have no objection to reverting it. Not all patches are accepted upstream, sometimes we need to throw away work
[15:25] <mvo> ari-tczew, vish, tumbleweed: sorry, was distracted. I think ideally we add a additional layer so that we can have chnages to the presentation (desktop file or even package description) without the need to touch the package itself. but we are not there yet. in the meantime I think we need to decide case-by-case
[15:25] <mvo> if its not a terrible important changes, we can throw it away, but it slightly worries me that a simple merge like this is difficult to find people for :/
[15:26] <ari-tczew> mvo: probably vish and cdbs love to merge it
[15:28] <mvo> I'm happy to sponsor a merge (if that helps)
[15:29] <ari-tczew> vish: btw. I don't agree with you that this case is too small to be discussed by TB. I was a witness in case when one small patch was discussed by TB. (w3m or something IIRC)
[15:30] <vish> yea, maybe, I think I was just being frightened of "talking to the TB" .. :)
[15:32] <cjwatson> I don't think any of this should involve talking to the TB
[15:48] <vish> i still believe, that if someone feels they definitely want to get the new version into Ubuntu, they could try to make some extra effort and do the merge. right now this discussion seems more like my time is more precious than the previous person's,  so I'm just going to drop it.
[15:48] <vish> (this is cause an upload that has already been done)
[15:49] <vish> s/that//
[15:50] <vish> if we dont want to have such changes, we should not even upload such patches
[15:52] <seb128> the issue is that having to merge a package rather than to sync means extra efforts are required and that the package tends to stay behind in versions and bug fixes because often there is no enough manpower to keep up with debian updates
[15:52] <seb128> where sync are just flowing in
[15:52] <seb128> well at least during the first part of the cycle
[15:52] <seb128> it's ok for one source
[15:53] <seb128> but if you start updating random source for description update that will be an issue
[15:53] <vish> seb128: ACK, then we should just not allow any such patches in Ubuntu
[15:53] <vish> we should be like Kubuntu
[15:53] <vish> they are very clear, they just close the bugs in LP if it is not their issue
[15:54] <seb128> we had this discussion before but you and design said we should take it at least for some popular packages
[15:54] <vish> :-)
[15:54] <seb128> which seems a fine tradeoff for a few source
[15:55] <Laney> didn't we agree to try to start (revive? was there one before?) a Debian initiative for descriptions?
[15:56] <vish>  i think we might have only a handful 10-20 max packages with such description changes.. which does not seem to huge
[15:56] <vish> Laney: we did, and the person incharge of starting the discussion retired from Ubuntu, :(
[15:56] <Laney> Someone else who cares about the project could do it instead. :-)
[15:57] <vish> yea, i know! ;p
[15:57] <Laney> btw, I imagine it would carry more weight were Debian to have the software centre too (so maintainers can see their descriptions being presented up front)
[15:58] <seb128> the descriptions are also in update-manager etc
[15:58] <seb128> not discussing having it in debian but fixing description is not only useful for it
[15:59] <Laney> I just mean that they aren't so prominent in Debian so it could be hard to convince maintainers of the need for a campaign
[15:59] <mdeslaur> @pilot out
[16:07] <cjwatson> doko_,ScottK: http://qa.ubuntuwire.com/ftbfs/ certainly shows several not-current failures
[16:07] <cjwatson> e.g. randomly https://launchpad.net/ubuntu/+source/collectd/4.10.1-2.1/+buildjob/2101837
[16:07] <ScottK> Agreed.
[16:07] <ScottK> I found some that failed on 3/8.
[16:07] <ScottK> Certainly not "this week".
[16:08] <doko_> hmm, lamont ^^^
[16:09] <cjwatson> I was going to craft an LP-API-based mass-give-back script if lamont didn't already have one ...
[16:09] <cjwatson> it's irritatingly not quite as easy as it ought to be
[16:12] <ScottK> "Ask lamont to do it" is hard?
[16:12] <ScottK> ;-)
[16:14] <cjwatson> lamont is great, but I'd like us to be able to do it independently
[16:15] <ScottK> I told lamont recently his mantra ought to be "lamont doesn't scale".
[16:18] <lamont> ScottK: I totally do not scale
 cjwatson: the buildds get disabled because the packages they're being asked to build so massively overtax the buildd that either (1) it falls over dead, or (2) launchpad decides it has, even though it hasn't.  in either case, launchpad then moves the build onto the next buildd and we knock that one over in turn
 and since gcc, gcj, openjdk, and such are (1) examples, (2) needs-build/building, and(3) in main, it really really sucks to be a universe package
[16:18] <lamont> bah.  just to make sure it's in an actually-relevant channel
[16:21] <cjwatson> http://paste.ubuntu.com/585462/ is (a) horrible (b) wrong and (c) running
[16:22] <cjwatson> (and I'll be unimpressed if people run that casually without agreement and DoS the builders ...)
[16:23] <pitti> cjwatson: OOI, what's wrong about it?
[16:23] <pitti> (aside from the DoSing part)
[16:23] <cjwatson> it has to iterate over lots of old builds because I couldn't see an interface which returns only the current ones
[16:24] <cjwatson> so it's harder on LP than it ought to be
[16:24] <pitti> I though that was the (a) horrible part
[16:25] <cjwatson> (d) hyperbole
[16:25] <nigelb> kirkland: ping
[16:25] <kirkland> nigelb: on the phone for the next 35 minutes
[16:25] <kirkland> nigelb: ping me after that
[16:25] <nigelb> kirkland: sure, thanks :)
[16:28] <cjwatson> OK.  Mass give-back done.
[16:29] <cjwatson> 78 packages retried
[16:29] <cjwatson> s/packages/builds/
[16:29] <cjwatson> (fewer than I expected, but looks right-ish from http://qa.ubuntuwire.com/ftbfs/)
[16:30] <cjwatson> builders say the queue time is 23m (amd64), 10h (armel), 2h20m (i386), 14h (powerpc), which looks pretty tolerable
[16:54] <jcastro> mvo: would you recommend people using the deb mirror line in sources.list if behind a squid-deb-proxy? I imagine the download URL changing each time wouldn't cache?
[17:07] <tgardner> slangasek, how does one deal with conf files when upgrading to the next release if the options in the conf file are no longer correct (or just plain wrong). For example, module-init-tools-3.12/debian/modprobe.d/intel-5300-iwlagn-disable11n.conf
[17:07] <tgardner> just release note it?
[17:16] <mvo> jcastro: yeah, its not necessarly a good idea behind squid-deb-proxy, I will investigate if there can be done anything to teach squid that certain curls are mirrors and actually the same resource
[17:16] <mvo> jcastro: but I have n oclue if that is possible or not
[17:18] <bdrung> doko_: i fixed lintian \o/
[17:21] <pitti> cjwatson: nice, the rebuilds are already by and large done
[17:22] <psusi> cjwatson: since beta freeze went into affect, does that mean my dmraid/parted fixes missed the window, or do you think you can still merge them?
[17:24] <slangasek> tgardner: there's 'dpkg-maintscript-helper', a tool that you can use in the next version of the package to cleanly handle removal of the conffile on upgrade
[17:25] <slangasek> tgardner: dpkg-maintscript-helper rm_conffile /etc/modprobe.d/intel-5300-iwlagn-disable11n.conf module-init-tools 3.12-1ubuntu4 <-- called from the maintainer script; the manpage has more details
[17:25] <slangasek> sorry, reverse those last two options
[17:30] <cjwatson> psusi: I'll have a look at them
[17:36] <ricotz> cyphermox_, hello :), if it is possible it would be great if you could look into syncing wpasupplicant from debian/experimental 0.7.3-1 was finally release there
[17:37] <cyphermox_> ricotz, I opened a bug about it, hold on
[17:38] <cyphermox_> ricotz, bug 740164  -- if someone could ack/ process it it would be cool ;)
[17:39] <ricotz> cyphermox_, great
[17:43] <cjwatson> psusi: uploaded, though it will need somebody else to approve it from the queue; sorry for the delay
[17:50] <tgardner> slangasek, cool. thanks for the advice.
[17:51] <slangasek> tgardner: no problem - I'm also happy to review once you have a prelim package fix
[17:51] <tgardner> slangasek, k, gimme a bit.
[18:07] <doko_> bdrung: thanks!
[18:16] <pitti> bdmurray: hm, is the truncation on http://reports.qa.ubuntu.com/reports/bug-fixing/natty-fixes-report.html (and also per-team pages) known?
[18:18] <bdmurray> pitti: it is now, thanks
[18:18] <pitti> bdmurray: ah, thanks
[18:18] <pitti> bdmurray: want a bug report somewhere?
[18:19] <bdmurray> pitti: the ubuntu-qa-tools project would be great
[18:22] <pitti> bdmurray: done (bug 742675(
[18:22]  * pitti appends )) to bring the universe's parentheses parser back into balance
[18:25] <tgardner> slangasek, chinstrap.canonical.com:~rtg/module-init-tools
[18:54] <seb128> slangasek, hey
[18:55] <slangasek> seb128: hey there
[18:56] <seb128> slangasek, I think you didn't notice, but http://launchpadlibrarian.net/67265214/pango1.0_1.28.3-4ubuntu2_1.28.3-4ubuntu3.diff.gz
[18:56] <seb128> slangasek, your commit in the autoimport vcs conflicts with the upload mvo did today which is waiting in the queue
[18:57] <slangasek> seb128: this is why everyone should use the bzr branches! ;)
[18:57] <slangasek> seb128: ok, will have a look at his upload and readjust, thanks
[18:57] <seb128> slangasek, yw
[18:57] <seb128> slangasek, well to be fair the vcs is lp:~ubuntu-desktop/pango/ubuntu
[18:58] <seb128> but we got in sync so the info got dropped from the control ;-)
[18:59] <slangasek> seb128: heh
[18:59] <seb128> don't bother about the vcs
[18:59] <slangasek> yes, those are not the bzr branches I meant ;)
[18:59] <seb128> we should get back in sync next cycle
[19:01] <mvo> slangasek: I used the bzr branch first (the debcheckout one) but it was out of date and I dod not sync it up, my mistake
[19:01] <slangasek> mvo: debcheckout wouldn't have pointed to a bzr branch, afaics
[19:01] <slangasek> anyway, don't worry about it
[19:02] <slangasek> it all just means you get me to process the queue for you :)
[19:05] <mvo> slangasek: indeed, its not recorded in the src record, I probably had a local checkout or something. but yeah, the current situation is a bit of mess, ++ for unification
[19:06] <slangasek> unification doesn't solve the problem of where to commit when we /do/ need to upload to Ubuntu
[21:00] <bdrung> doko_: strange. it fails again: http://launchpadlibrarian.net/67283011/buildlog_ubuntu-natty-i386.lintian_2.5.0~rc1ubuntu3_FAILEDTOBUILD.txt.gz and i have no clue why.
[21:04] <hallyn> zul: hey, so if I did 'debcommit -r -R'; 'bzr push';  'bzr uncommit'; (make a change);  'debcommit -r -R';  'bzr push'
[21:05] <hallyn> zul: will the tag in the end be ok?  :)
[21:08] <cjwatson> no, you'll get an error from debcommit because the tag already exists
[21:08] <cjwatson> however you can manually do 'bzr tag -f' and that should work
[21:08] <cjwatson> sorry, --force not -f
[21:09] <cjwatson> and you would need bzr push --overwrite
[21:10] <hallyn> cjwatson: i went ahead and re-uncommited and did 'bzr tag --delete' then redid the debcommit,
[21:10] <hallyn> which seems to be working so far
[21:10] <hallyn> ah, there's the error you predicted pushing :)
[21:10] <hallyn> cjwatson: thanks, --overwrite did the trick for that
[21:14] <hallyn> cjwatson: oh, hey, zul mentioned on ubuntu-cloud you'd fixed some bug with the amd64 cd image perhaps relating to kim0 finding that 'debootstrap' is not installing netbase when it is on 'Depends:' for one of the packages he'as asking for with --include?
[21:49] <james_w> https://bugs.launchpad.net/ubuntu/+source/davfs2/+bug/459998
[21:49] <james_w> the kerneloops user has a silly homedir of /
[21:49] <james_w> changing the postinst will fix it for new users, but what should be done for existing users
[21:50] <james_w> is it ok to delete and then re-add the user?
[21:51] <ScottK> I don't think there's a guarantee it will get the same UID.
[21:51] <ScottK> If it owns any files on disk, that would be problematic.
[21:52] <james_w> hmm, yeah
[21:52] <james_w> I don't think it should in this case, but I'm not 100% sure
[21:52] <james_w> is there a command to alter a homedir after the user is created?
[21:54] <james_w> usermod -d looks likely
[21:54] <james_w> definitely without the -m option in this case :-)
[23:16] <bdrung> doko_: fyi bug #742832