[00:02] thought the process still seems rather nebulous to me, i'll call that a result [00:03] (-t, agh) [00:14] cjwatson, no, since that is a private unreleased version of -fglrx the issues mostly are just email, no bug #'s unfortunately [00:14] bryceh: OK - is it urgent for beta? [00:14] bryceh: (I may have another upload coming anyway, and I've queued it up) [00:15] cjwatson, it depends on whether we get -fglrx in time for beta, which is uncertain (no eta's given) [00:15] ok, well let me know as early as you can if it looks like we're going to be out of sync [00:15] it's in lp:~ubuntu-core-dev/ubuntu/natty/grub2/natty [00:20] oh boy, my logoff dialogue and some polictkit windows earlier were showing broken font unicode boxes, i fear a reboot [00:24] who keeps changing the wifi icon D: the elements are almost too small to resolve now, and the bottom looks misshappen === dendrobates is now known as dendro-afk [00:53] ohsix, which bug was it that you were hitting? [00:54] cnd: the 2 finger gestures on SemiMultitouch (well put) devices [00:54] though it appears to still be doing it [00:54] ohsix, do you have the bug link? [00:54] I just want to make sure everything is as expected [00:56] 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] Ubuntu bug 739916 in gnome-control-center (Ubuntu) "gnome-mouse-properties doesn't offer touchpad options for 2 finger clicks" [Undecided,New] [00:56] Ubuntu bug 739922 in xserver-xorg-input-synaptics (Ubuntu) "touchpad disable key does not work (acts as if no key was pressed, no event in xev)" [Undecided,New] [00:56] Ubuntu bug 739924 in xserver-xorg-input-synaptics (Ubuntu) "device acceleration profile incorrect for synaptics touchpad in natty" [Undecided,New] [00:56] 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] oh yeah, ok [00:57] I work on so many bugs I just forget what is what [00:57] alright [00:57] ohsix, I don't really think the change should have had any effect [00:58] so I'm not sure what to think :) [00:58] it didn't, i just read a little into it [00:58] ahh [00:58] ok [00:58] i thought it'd disable the 2 finger gestures when the touchpad only fakes it [00:58] sorry... [00:58] not a problem [00:59] ohsix, I don't think the scroll issue is going to be fixed for natty [00:59] that's fine, it can be disabeld in gnome-mouse-properties [00:59] the reason i filed the bug that way was to get something like that for the 2 finger right click [01:00] 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] yeah [01:00] that should be fixed, but probably won't be for natty either... [01:00] agh [01:00] it would require too big of a change at this point [01:01] can you pin it disabled then, if theres no ui to do it [01:01] well, some people may like it, and it may work well for them [01:01] so we can't really make that kind of a change either at this point [01:01] it could [01:01] because we don't really know how well it works for everyone [01:02] except on these touchpads where it's almost assuredly wrong, without being able to adjust the threshold for it [01:02] we don't really know which touchpads it's definitely wrong though [01:02] 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] it may work fine for some people who have the "fake it" kind of touchpads [01:02] well, you do; i could tell you too, they have different protocols [01:03] yeah, we can tell the two device types apart [01:03] 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] the ones with heuristics need extra input that there isn't ui for either; to make it work well [01:04] 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] i could enable it manually before natty as well; it did not work well then, and i had no desire to [01:04] ohsix, I do agree with you in that it probably should be disabled by default [01:05] and it's something we probably want to attack upstream [01:05] in the X community [01:05] 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] where the driver is setting it on by default [01:05] probably [01:05] ohsix, this is a change in behavior from maverick? [01:05] yes [01:05] are we in freeze for beta? do I need to get a freeze exception for an xserver bug fix? [01:05] (if you already said that, sorry) [01:06] 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] 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] when mav was in alpha/beta the sensitivy stuff changed as well; but by the time it was released it was fixed [01:06] bryceh, I don't know if you've kept up with the issue [01:07] cnd, I haven't, no [01:07] bryceh, I'll try to summarize [01:07] there's two types of synaptics trackpads that are concerned here [01:07] multifinger trackpads and trackpads that just give you some touch area size [01:08] in natty, the default of x synaptics is to enable right click on two finger taps [01:08] including a heuristic to enable right click on non-multi-finger trackpads when the touch size looks like two fingers [01:08] maverick didn't default to this [01:09] and according to ohsix, the touch size heuristic just doesn't work well for all trackpads when set to the default thresholds [01:09] (and there is no ui to adjust the thresholds either) [01:09] ok [01:09] so I wonder if we shouldn't leave two tap for right click disabled for the touch size type trackpads [01:10] 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] ohsix, the one thing I would note is that I'm very resource stretched myself [01:11] so although I agree with you [01:11] 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] right [01:11] I may not be able to fix the bug in time for natty release [01:12] it all comes down to setting properties with xinput; which is what i'll have to do manually in either case [01:12] I may not be able to fix it myself that is [01:13] but if you or someone else has a patch, I'd be happy to review it [01:17] hm [01:18] i wouldn't know where to start [01:19] apt-get source xserver-xorg-input-synaptics ;-) [01:19] yea i'm reading it now [01:19] $ bzr branch lp:ubuntu/xserver-xorg-input-synaptics [01:19] if you like bzr [01:19] even better [01:20] should i be looking through ubuntu's version of it? or is upstream enough for the likes of natty [01:21] 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] cnd, so it'll give them the option of including the fix in beta without forcing it [01:22] bryceh, that's fine [01:22] I don't think the release team likes me right now though... [01:22] :| [01:22] 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] cnd, oops, did you break something? [01:23] bryceh, no, I never break anything! [01:23] though that's not the issue :) [01:23] hehe [01:25] uploaded [01:26] awesome, just about everything has changed since i last looked [01:27] heh [01:30] http://cgit.freedesktop.org/xorg/driver/xf86-input-synaptics/commit/?id=ee99d4f7bc3374e8bac083ac4ea159f5da43db06 huhu, not it, but related [01:34] [ubuntu/natty] xorg-server 2:1.10.0-0ubuntu2 (Accepted) [01:34] cnd: http://cgit.freedesktop.org/xorg/driver/xf86-input-synaptics/commit/?id=ffa6dc2809734a6aaa690e9133d6761480603a68 [01:34] interesting; perhaps beta is not quite frozen yet? [01:35] bryceh, I blame you if xserver is broken :) [01:35] 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] (from commit message) [01:35] that min z is the threshold used in the heuristic i was talking about [01:36] 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] in any case, can't be any worse than what happened this morning [01:37] (huge leak in water main due to tree roots breaking a pipe in my front yard) [01:37] ((fun)) [01:37] cnd: i cheated and asked the guy who did it :D [01:37] bryceh: Ouch that is certainly not fun. [01:38] bryceh, oh man, not fun! [01:38] ohsix, hmmm, we could reverse patch that [01:38] bryceh, check out the commit ohsix pasted ^^ [01:39] cnd, reverse patching that is certainly doable [01:39] will that solve it? [01:39] ohsix, do you know how to add that as a reverse patch to a debian package? [01:40] generate the reverse patch, stuff it into debian/patches/ [01:40] and add it to debian/patches/series [01:40] yea, but it probably wouldn't hurt to go over it again [01:40] yeah, then you would build and test it :) [01:40] and then you can post a debdiff in the bug or a merge request [01:43] apparently EmulateTwoFingerMinW can be changed as well, rather than reverting it [01:46] ohsix, if you have something you want me to review, please subscribe me to the bug [01:46] my lp id is chasedouglas [01:46] that way I'll see it :) [01:46] eventually.. [01:48] what's the kung fu to generate a patch to revert automatically? i've always just edited the patches [01:48] (mind you, not large patches) [01:51] nm [01:55] 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] rezbit, I'm not familiar with libsdl, but in general you can 'apt-get source ' and then look in that package's debian/control to see what flags get passed to configure [01:59] ok remind me how to build a package, fakeroot debian/rules or something? :D [02:00] 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] ohsix, did you use apt-get source? [02:00] or bzr? [02:01] apt-get [02:01] YokoZar: Because cdbs has symlinked it to one of its dependencies? [02:01] ohsix, ok, I'd suggest using debuild [02:01] RAOF: debhelper in this case [02:01] ohsix, just running debuild should do it [02:01] ok [02:02] 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] RAOF: yup, no copyright in the .deb...nor a symlink [02:06] does whatever that applies patches not like diff --git format patches? [02:07] ohsix, it should work [02:08] I usually use diff -Nurp fwiw [02:08] Nurp derp, herp [02:09] YokoZar: Well, then it would appear to be not what I'm thiking of. [02:09] RAOF: and thus stumps me too :( [02:09] YokoZar: cdbs package? [02:09] micahg: debhelper [02:10] no idea then [02:10] maybe it would help if i checked out the right version ubuntu uses instead of using HEAD :D [02:11] micahg: Yeah, we've covered that :) [02:11] ohsix, that would help :) [02:11] ohsix, if you'd rather, the real ubuntu packaging branch is kept in git [02:12] I forgot to mention that [02:14] barry: reminder: https://bugs.launchpad.net/launchpad/+bug/608173 [02:14] Ubuntu bug 608173 in Launchpad itself "View all (or more) PPA package build statuses" [Undecided,Expired] === slangasek changed the topic of #ubuntu-devel to: Archive: beta freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: smoser [02:18] 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] ohsix, have you tried applying it manually? [02:20] to check that it will work [02:22] 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] This is what caused me to look around for SSP in the first place. Apparently this isn't upstream yet. [02:28] i cant figure this out D: [02:28] ohsix, I can try to help you out later [02:28] k [02:28] i'm gonna check out the bzr thing and try there [02:29] hm... well it is in upstream SVN fwiw, but it's not in 1.2.14 [02:31] ohsix, just to be clear, my definition of later is sometime next week [02:31] i'll have it ready soon [02:31] I didn't want you waiting around for me in a few hours [02:31] :) [02:31] cause I'll be asleep [02:32] 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] ok [02:34] patch applies [02:34] cool [02:36] i just copied the file to a .new and edited it D: [02:36] http://paste.ubuntu.com/585159/ looks pretty much the same to me, brb testing it [02:38] 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] The bug exists in upstream 1.2.13-14 [02:39] yay, works [02:39] great [02:39] ohsix, do you know how to propose it using bzr and lp? [02:41] 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] cnd: nope [02:41] ohsix, ok, push to lp: [02:42] with what credentials [02:42] bzr push lp:~/ubuntu/natty/xserver-xorg-input-synaptics/ [02:42] the branch name could be lp [02:42] or something descriptive [02:42] does bzr have changesets, do i need to apply it there then push; i've never used bzr [02:42] like "no-touch-size-emulation" [02:42] bzr, oh, you need to commit locally [02:43] bzr commit [02:43] holy crap! multiarch support has arrived? I thought that was given up on years ago! [02:43] psusi: you didn't notice all those FFe's for multiarch? :D [02:43] psusi: No; like a peat fire it merely simmered underground :) [02:44] ohsix, feature freeze exceptions? where would I have seen those? [02:44] psusi: in changelogs for package updates in natty === asac_ is now known as asac [02:44] ohsix, I've actually not switched to running natty yet.. still on maverick with just a few packages upgraded to natty versions [02:44] i see [02:45] given up, hah [02:46] slangasek, is this revenge after being the release manager for previous releases? [02:46] 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] 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] then I wondered off and got sucked into an MMO for a few years... [02:47] cnd: hmm? I hope no one finds it vengeful :) [02:47] heh [02:47] 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] ohsix, just need the bug # and patch [02:47] bryceh: that would be great [02:47] bryceh, I'd like to take one last review of that block of code [02:48] 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] 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] Ubuntu bug 739916 in gnome-control-center (Ubuntu) "gnome-mouse-properties doesn't offer touchpad options for 2 finger clicks" [Undecided,New] [02:48] 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] ohsix, I think we should open a different bug then [02:48] psusi: there are lots of little reasons to want multiarch, flash is just one of them [02:49] (and no, I wouldn't say 64-bit flash has been "worked out") [02:49] 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] flash... argh [02:50] i'll file another [02:50] cnd, ok [02:50] ohsix, cnd, agreed that a new bug for this specific issue would be best; ohsix would you mind filing one? [02:50] should i put like, caused by git commit hash, or just propose the patch [02:51] ohsix, it would be a good idea to reference the git commit [02:51] but attaching the patch would also help [02:51] since you've got it handy [02:51] * lamont wonders why cups is asking for a root password when shadow has root:!:... [02:51] does lp detect comments made as patches as patches, or do i need to attach a file [02:52] 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] ohsix, attach file [02:52] ohsix, when you make the new bug report, subscribe me to it [02:52] ok [02:53] thanks [02:53] and thanks for testing the change out :) [02:55] 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] all done https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/742213 [02:56] Ubuntu bug 742213 in xserver-xorg-input-synaptics (Ubuntu) "spurious right click events" [Undecided,New] [02:56] 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] no, the *main* problem is the many libraries that load plugins from a predetermined path [02:57] 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] oops. well he's not back from the netsplit yet. [02:57] ohh... isn't that a big no-no to begin with? it's supposed to let ldconfig resolve paths [02:58] psusi: not in the least. ldconfig is for resolving library paths, it doesn't help for plugins [02:58] not when you want them in per-application directories [02:58] plugins are libraries [02:58] no, they aren't [02:58] they're dynamic shared objects [02:58] dso = library by another name? [02:59] a library is a specific kind of dynamic shared object - one with an soname, that you link against [02:59] psusi: e.g., how would you propose libpam manage to use ld.so to look up the modules in /lib/security? [03:01] slangasek, readdir() or a config file and then ldopen()? [03:01] ld.so doesn't implement either of those things for you [03:01] and where do you put the config file so that it's unique on a per-architecture basis? [03:01] 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] you've just moved the pieces around, you haven't solved the problem of conflicting paths built into the binaries [03:03] 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] 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] slangasek, so basically, plugins need to be loaded from /lib32 or /lib64 explicitly, rather than /lib? [03:05] though I thought dlopen() was going to be patched to automatically rewrite /lib to the appropriate one [03:06] er, I don't know who proposed doing /that/, but it wasn't me :) [03:07] 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] I understand the idea, but that's not what's been agreed and implemented [03:08] ohh... why is that? [03:09] It would seem pretty magical. [03:09] for one thing, having ld.so doing magic to rewrite paths out from under you is horribly ugly [03:09] for another, there are other kinds of architecture-dependent files besides DSOs at issue [03:14] 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] two years old* [03:51] RAOF: Did you end up looking at Quod Libet? [03:51] Oh! *That's* why I've got the software centre open! [03:51] (You may take that as a “not yet”) [03:51] heh [03:54] you know the quod libet guy can't ride a bike or swim [03:54] What does the have to do with the price of fish? [03:54] and started the ill fated dx11 on xp project :D [03:54] it's a fun anecdote :D [03:54] he worked for linspire & theres a video floating around of him trying to ride a bike [03:54] You know, mesa could probably provide dx11 on XP reasonably easily. [03:55] it's not just adapting the rendering api though; there are places where it leaks into windows implimentation [03:56] Hands up all those who can't right click on anything in the launcher without compiz crashing! o/ [03:56] s/dx11/dx10 [03:57] it was only a sideshow until he started charging people to get releases that didn't do anything D: [03:57] Well, there's a dx11 state tracker in mesa at least. [03:58] Heh. [03:59] The nux crash in GrabPointer has been fixed… and replaced by a crash in GrabKeyboard! [03:59] drag & drop on the panel is also broken, though how; i have no idea [03:59] RAOF: Does that mean it's installed now? :-) [04:00] StevenK: Indeed it is. [04:00] RAOF: apologies for have the old kernel....REALLY weird...apt-get dist-upgrade won't budge on it [04:00] 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] yeah...but I don't [04:01] I checked [04:01] Oh. [04:01] system is confused [04:01] You've got nvidia-current built against it, though :) [04:01] robbiew: You have the headers, but not the kernel itself? [04:02] hmm...maybe [04:02] yep [04:02] * StevenK wins. [04:02] but how the hell did I get the headers only [04:02] not having the virtual that pulls them all in? [04:02] robbiew: /var/log/dpkg.log might help tell you. [04:04] 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] RAOF: I can't see a mpris plugin for Quod, either. [04:07] RAOF: Pity I don't know C# :-) [04:07] You could try an IronPython plugin :) [04:07] Or IronRuby. How about F#? :) [04:08] * StevenK books a flight so he can stand over RAOF until he writes it. :-P [04:16] RAOF: http://code.google.com/p/quodlibet/source/browse/plugins/events/mpris.py?spec=svn06b6519551f11dc084e7465cde47b8e520837c74&r=06b6519551f11dc084e7465cde47b8e520837c74 [04:18] StevenK: Ah, sweet. I'll just go and write an mpris-control plugin then. [04:18] RAOF: Is that even easier? [04:18] No, but it'll work for more players. [04:19] It's almost exactly as easy, but more general. [05:08] @pilot on [05:08] (pilot (in|out)) -- Set yourself an in or out of patch pilot. [05:08] @pilot in === udevbot changed the topic of #ubuntu-devel to: Archive: beta freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: NCommander, smoser [05:12] evening all === _LibertyZero is now known as LibertyZero === Claudinux_ is now known as Claudinux [06:46] hmm, newest pulse in natty has pulseaudio-module-raop as hard dependency [06:46] which in turn depends on zeroconf [06:46] and this then brings in all the avahi shit [06:46] is this getting fixed? [06:48] 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] !ohmy > phsi [06:48] phsi, please see my private message [07:05] Good morning [07:06] Guten Morgen pitti :) [07:23] heh [07:23] !ohmy > bryceh [07:23] bryceh, please see my private message [07:23] kewl [07:23] !msgthebot > bryceh [07:23] :) [07:24] micahg, what you don't like me playing with my bots in public? ;-) [07:24] micahg: It creates unnecessary backlog [07:24] oops [07:24] bryceh: ^ [07:24] as does this whole conversation ;) [07:24] bryceh: When you can !msgthebot its better, and cleaner [07:40] good morning [08:29] good morning [08:33] 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 === khrm_ is now known as khrm [09:25] 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] kklimonda: it does not much matter, no :) === diwic is now known as diwic_afk [10:27] tseliot: oh, so can we remove displaydepth for 96 and 173 as well? that would indeed make xorg.conf a lot simpler [10:28] 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] tseliot: ok, thanks; it at least was confirmed that it works for -current [10:41] @pilot out === udevbot changed the topic of #ubuntu-devel to: Archive: beta freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: smoser [10:48] How is component-mismatches generated? [10:50] 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] 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] 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] cjwatson: Perhaps I could borrow your brain for a couple of minutes? Pretty please? :) [11:03] soren: you can tell germinate which components to look at - it's a command-line option [11:03] so you run germinate against all components, and then compare against what's currently in main [11:03] the rest is basically bookkeeping [11:03] cjwatson: Indeed. [11:04] cjwatson: How does component-mismatches do it? [11:04] surely not like this? [11:04] why not? [11:04] Does it? [11:04] (actually, Launchpad has already run germinate for it; it just uses the output.) [11:05] But for germinate to consider stuff in universe at all.. Err.. [11:05] it's perfectly reasonable if you're asking conditional questions [11:05] Does Launchpad run germinage with universe "enabled"? [11:05] yep [11:05] Oh. [11:05] Oh, ok. [11:06] ..and then component-mismatches compares with Packages (and Sources, I suppose)? [11:07] http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/view/head:/cronscripts/publishing/cron.germinate <- how LP runs germinate [11:08] I'll mail you the dire hacky scripts that do c-m [11:08] I doubt they'll be runnable directly out of context [11:09] cjwatson: Thanks very much. [11:09] When I do MIR work to see what needs to be promoted, I do it all by hand. :-/ [11:09] 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] StevenK: That's very useful info. Thanks. [11:10] it's not in LP [11:10] well, cron.germinate is, the other bits aren't [11:10] ~launchpad-pqm/launchpad/devel looks very.. [11:10] Ah, right. [11:10] And yes, that's LP main trunk. [11:11] Exactly, hence my confusion about "it's not in LP" :) === MacSlow is now known as MacSlow|lunch [11:55] @pilot in === udevbot changed the topic of #ubuntu-devel to: Archive: beta freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: mdeslaur, smoser [11:57] * dholbach hugs mdeslaur [11:57]