[08:07] <mdke> TrAndy: that sounds like a good idea - you could make a new page which is linked here - https://help.ubuntu.com/community/InputDevices
[08:40] <Rocket2DMn> mdke, starting to delete pages?
[08:41] <ruiboon> hi. may i know if there is any policy re spam attachment in wiki? is it to delete them?
[08:41] <Rocket2DMn> ruiboon, do you have a link?
[08:42] <ruiboon> Rocket2DMn: one such page is at https://wiki.ubuntu.com/Fra67ysi?action=AttachFile
[08:44] <Rocket2DMn> that is weird, i see .bin files when i try to see them
[08:45] <Rocket2DMn> yes, the spam will need to be deleted, but i dont think it will let you do that
[08:45] <ruiboon> Rocket2DMn: that is a spammer account
[08:45] <Rocket2DMn> ok, give me a minute so we can file a report in the correct place
[08:46] <ruiboon> Rocket2DMn: if you search for "site:wiki.ubuntu.com iPhone" in google, you will see all the links pointing to this account attachment page
[08:46] <ruiboon> Rocket2DMn: i think it has been filled in bug 224971
[08:47] <Rocket2DMn> ah yes there it is
[08:47] <Rocket2DMn> you can add the link to that bug report
[08:47] <Rocket2DMn> Phil or Matthew will be able to delete that stuff
[08:48] <ruiboon> Rocket2DMn: ok. thanks
[08:49] <Rocket2DMn> no, thank you.
[16:14] <vbabiy> Hey Any one around?
[19:33] <EagleScreen> hi all
[19:34] <EagleScreen> i need help for validate my GPG on Launchpad
[19:34] <EagleScreen> i ma reading this howto: https://help.ubuntu.com/community/GnuPrivacyGuardHowto
[19:34] <tormod> EagleScreen: I am just fixing up that linl
[19:35] <tormod> *link
[19:35] <EagleScreen> thanks you
[19:36] <tormod> EagleScreen: you probably understand that you should replace <username> by your LP username?
[19:36] <EagleScreen> i think it autologin me... how can I be sure?
[19:38] <tormod> well go to your LP homepage and click "Update OpenPGP keys"
[19:39] <EagleScreen> i go to https://launchpad.net/ and i am already logged in
[19:39] <EagleScreen> what to do now?
[19:42] <tormod> what I said?
[19:42] <tormod> see also https://help.launchpad.net/ImportingYourOpenPGPKey
[19:42] <EagleScreen> I do not find Update OpenPGP keys at launchpad home page
[19:45] <EagleScreen> ok, thanks you very much, i did it
[19:50] <tormod> EagleScreen: thanks for reporting that broken link
[20:18] <vbabiy> Hey guys is this the correct room to ask about how to write docs for devhelp
[20:21] <Old_Soldier> vbabiy: someone might be able to answer that but mostly we are involved in patching the existing docs
[20:22] <vbabiy> Old_Soldier: okay any idea where I should to help. I Want to help out pygtk with docs but they are in opposite timezones so impossible to catch them.
[20:23] <Old_Soldier> vbabiy: sorry , i have no idea
[20:23] <vbabiy> Thanks
[22:05]  * bimberi finishes doing a few HelpWiki deletions, leaving the easy ones for mdke :P
[23:55] <EagleScreen> hello
[23:56] <EagleScreen> i think an ubuntu documentation may be wrong


[11:33] <seb128> hum, does anyone here has experience migration a vcs from bzr to git which has tag names including '~' and ':' which are invalid to git and any hint how to deal with those?
[11:56] <ginggs> seb128: fwiw, the convention in debian is to transform ~ to _ and : to %
[11:59] <Unit193> Last time I did conversions, I used bzr-fastimport or whatnot, but a patched version or else bad things would happen.  It had an option to rewrite tag names I believe.  brz is the python3 version, but I don't believe those bugs were ever fixed...
[12:04] <bdrung> seb128, I converted a lot of bzr repositories to git recently.
[12:04] <bdrung> https://github.com/bdrung/bdrung-scripts/#bzr2git
[12:11] <rbasak> seb128: more details on the standard escaping scheme: https://dep-team.pages.debian.net/deps/dep14/
[12:29] <seb128> bdrung, ginggs, rbasak, thanks!
[12:48] <seb128> Unit193, I guess I will need to try that
[12:48] <seb128> bzr2git doesn't seem to handle the tags issue
[12:49] <seb128> WARNING: not creating tag b'refs/tags/1:102.9.0+build1-0ubuntu1' as its name would not be valid in git.
[12:50] <bdrung> seb128, maybe as workaround: add tags in bzr with the renamed charaters. Then convert.
[12:51] <seb128> bdrung, bzr fast-export has a '--rewrite-tag-names', I'm trying that
[12:52] <seb128> WARNING: tag b'refs/tags/1:102.9.0+build1-0ubuntu1' is exported as b'refs/tags/1_102.9.0+build1-0ubuntu1' to be valid in git.
[12:52] <seb128> better
[12:53] <Unit193> https://bazaar.launchpad.net/~unit193/bzr-fastimport/deletion-fixes/revision/361
[12:53] <bdrung> seb128, great!
[13:03] <seb128> Unit193, thanks, you don't have an updated version that applies to the current version by any chance? ;)
[13:04] <Unit193> Thankfully I haven't had to touch bzr in a few years.
[13:04] <seb128> :p
[14:37] <seb128> Unit193, the issue was fixed in the bazaar ubuntu package but seems to have regresser in breezy, I ended up doing the import in a bionic container...
[14:39] <seb128> bdrung, bzr2git worked fine at the end, I just added --rewrite-tag-names to l115 of the script, I don't know if it's right in every case but it worked for thunderbird
[15:02] <bdrung> seb128, it's probably a good default for importing it into git
[15:30] <vorlon> rbasak: out of curiousity, what does git-ubuntu do if an initial upload of a package has its Vcs-Git* fields in .changes?
[15:30] <vorlon> *curiosity
[15:31] <vorlon> rbasak: if I'm uploading a new package, maybe I want the rich history to be present from the beginning :-)
[15:39] <rbasak> I think it'll ignore it. I hadn't really covered that edge case, sorry.
[15:40] <rbasak> Also, there's a bug that the import fails to push if there's only one upload. Sorry!
[15:40] <rbasak> https://bugs.launchpad.net/git-ubuntu/+bug/2012626
[15:40] -ubottu:#ubuntu-devel- Launchpad bug 2012626 in git-ubuntu "Importer fails to push when there's only one upload" [High, Triaged]
[15:40] <rbasak> It's because then the changelog notes ref doesn't exist, because that's based on diff to previous.
[15:40] <rbasak> It is definitely a bug that I need to fix, but a bit of a low priority.
[16:25] <vorlon> rbasak: ack :)
[16:39] <bdrung> rbasak, is that answer https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/2012599/comments/36 sufficient?
[16:39] -ubottu:#ubuntu-devel- Launchpad bug 2012599 in tzdata (Ubuntu Kinetic) "tzdata 2023a/2023b/2023c release - Egypt restoring DST" [Critical, Triaged]
[16:48] <rbasak> bdrung: the issue is that you're bundling changes in SRUs which, while they may be correct and appropriate to make in an SRU, effectively attempts to bypass SRU review because they're bundled as part of other changes, instead of having the opportunity for proper review, justification, and planning for QA as they would do in separate SRU bugs.
[16:49] <rbasak> eg. if the translations are wrong and you decided to fix them, then great, but then "Update debconf template and translations to 2023c-2" is *not* the appropriate way to describe that.
[16:51] <bdrung> rbasak, valid point that the explanation of the change isn't that well formulated.
[16:52] <rbasak> bdrung: every deliberate change that is visible to users should have its own referenced SRU bug with an SRU justification
[16:52] <bdrung> rbasak, and I should have put those in two lines. The "Update debconf template" is just by running the build.
[16:54] <rbasak> (but just running debconf-updatepo is fine without its own SRU bug of course. Just a note in debian/changelog as you did is fine)
[16:55] <rbasak> I'm sorry if that seems like a lot of work. But I don't think it's appropriate to make changes to stable releases without careful consideration of each change being reviewed by the SRU team. Using documentation in individual bugs is how we do that. That's how the policy stands today.
[16:56] <rbasak> We do not try to fix every single bug in SRUs either - because it's a lot of work for two competent to have confidence and take reasonable steps to ensure we won't regress users. I think that's a reasonable position for us to take.
[16:56] <rbasak> for two competent developers
[16:58] <rbasak> I have to EOD now. But I did just accept python-tz to Jammy and Kinetic - thank you for that!
[17:00] <bdrung> rbasak, would you be okay if I would open two more bug reports with the reasoning and reference them in the changelog or do you prefer to defer those regression fixed for another round of SRUs?
[17:01] <bdrung> since these are IMO regression fixes of previous updates/SRUs.
[18:14] <rbasak> bdrung: I think that's up to you. It depends on SRU review of the justification of those separate fixes as to how long they'll take, I think.
[18:14] <rbasak> bdrung: I think SRU policy/procedure _requires_ separate bugs for separate fixes. But it's up to you what fixes you want to propose.
[18:15] <rbasak> bdrung: if you propose them, then we might discuss the details after review. But without seeing the justification and any discussion, the SRU team isn't in a position to make a decision.
[18:25] <rbasak> bdrung: I suppose if we want the SRU to land quickly, then it be better to defer them to a future round.
[18:25] <rbasak> And I need to spend more time on other things :-/
[21:29] <Unit193> seb128: Yeah, it was in universe so I had access to it. :D


[00:08] <eric_> testing a shutdown for 1/2 hr to see if helps
[16:56] <studio-user283> Hallo
[20:31] <dontogueli> Spanish or French language? I can with English but , in technical key I am too poor...
[20:32] <Unit193> That'd be #ubuntu-es or #ubuntu-fr
[20:40] <dontogueli> Thank you men


[14:52] <RikMills> Eickmeyer & @all : if possible, please test merged sddm in https://launchpad.net/~rikmills/+archive/ubuntu/sddm-merge
[14:53] <RikMills> seems ok on kubuntu
[15:44] <Eickmeyer[m]> RikMills: I'll see what I can do, but it might be a while.
[15:46] <RikMills> lubuntu just reported it seems ok, so I may just upload at my EOD
[15:46] <RikMills> if you can do an extra test before then, then great
[16:38] <Eickmeyer[m]> RikMills: If it works for Kubuntu then it should work for us. We use a slightly different sddm theme, but at the end of the day it's mostly symlinks to Breeze, so it should just work (tm).
[16:38] <Eickmeyer[m]> My hands are a bit tied today with stuff.
[17:32] <RikMills> yeah, that is what I figured, but thought I would ask anyway


[00:05] <ubotu> New bug: #217002 in xserver-xorg-video-via (main) "Xserver crashes with VIA chipset" [Undecided,New] https://launchpad.net/bugs/217002
[05:00] <ubotu> New bug: #217092 in linux-restricted-modules-2.6.24 (restricted) "nvidia-glx-new 169.12+<IP_ADDRESS>0-500.23~envy fails to start" [Undecided,New] https://launchpad.net/bugs/217092
[05:09] <ubotu> New bug: #216667 in xserver-xorg-input-vmmouse (main) "[hardy] USB mouse does not work on PowerPC live cd (20080413)." [Undecided,Confirmed] https://launchpad.net/bugs/216667
[09:56] <james_w> seb128: does http://paste.ubuntu.com/6973/ correctly preserve translations?
[09:57] <seb128> james_w: hum, was it translatable before? it's not between _()
[09:57] <james_w> oh yeah, I didn't notice that.
[09:57] <seb128> james_w: and I would rather use 2 times the same strings rather than introduce a variable, especially than we will be wanting to change one variant next cycle
[09:57] <james_w> ah, ok
[09:58] <james_w> should I mark them translatable?
[09:58] <seb128> yes please
[09:59] <seb128> the string is already in the translations apparently
[09:59] <seb128> that was the one used by the upstream variant
[10:12] <james_w> seb128: any better?
[10:12] <james_w> http://paste.ubuntu.com/6977/
[10:13] <james_w> the rest of the file uses gettext() rather than _()
[10:13] <james_w> I haven't tested the localisation though.
[10:14] <seb128> hum, using gettext
[10:20] <seb128> james_w: seems to be alright
[11:06] <ubotu> New bug: #217182 in xorg (main) "Rotate Screen in TabletPC stylus and pointer mouse not coincidence" [Undecided,New] https://launchpad.net/bugs/217182
[11:39] <ubotu> New bug: #217189 in xserver-xorg-video-intel (main) "Rotating screen does not flip X/Y dimensions" [Undecided,New] https://launchpad.net/bugs/217189
[11:44] <james_w> I'm not very familiar with debugging this type of segfault, if we have
[11:44] <james_w> rw_mode_get_width (mode=0x3) at randrwrap.c:1104
[11:44] <james_w> where mode is a pointer, and then a valgrind with
[11:44] <james_w> Invalid read of size 4
[11:44] <james_w> Address 0xf is not stack'd, malloc'd or (recently) free'd
[11:45] <james_w> from that function does that indicate that the pointer is being overwritten somewhere
[11:45] <james_w> following the flow of the code I can't see anything wrong in the logic yet
[11:45] <seb128> james_w: that means the code access a non valid memory address
[11:46] <seb128> james_w: usually that's something used after being freed for example
[11:46] <seb128> james_w: or a pointer being overwritten
[11:47] <james_w> ok, it's not obvious to me where this could be happening.
[11:48] <james_w> the stacktrace omits some functions, would this be due to optimisations?
[11:52] <seb128> james_w: yes, likely
[11:55] <seb128> james_w: looking to the code
[11:58] <james_w> there are a bunch of code paths that call that function, so I'm not sure exactly which is being taken to trigger this, I've tried to follow them all, and haven't seen anything yet
[12:00] <seb128> ==11339== Use of uninitialised value of size 4
[12:00] <seb128> ==11339==    at 0x4073179: rw_mode_get_height (randrwrap.c:1118)
[12:00] <seb128> ==11339==    by 0x804D636: rebuild_gui (xrandr-capplet.c:526)
[12:00] <seb128> ==11339==    by 0x804F1AD: run_application (xrandr-capplet.c:1755)
[12:00] <seb128> ==11339==    by 0x804F83B: main (xrandr-capplet.c:1799)
[12:00] <jcristau> gdb doesn't tell you that?
[12:01] <seb128> jcristau: there is a lot of static functions in this source and I think that the -O2 builds don't list those
[12:01] <jcristau> gdb should be able to handle them
[12:01] <seb128> well, -O2 stacktrace are not accurate for sure, I'm not sure to what it's due
[12:02] <ubotu> New bug: #213295 in ubuntu "Shutdown does not take place (dup-of: 118605)" [Undecided,New] https://launchpad.net/bugs/213295
[12:02] <seb128> optimization makes some call being not listed
[12:02] <jcristau> inlining maybe
[12:02] <seb128> could be yes
[12:02] <seb128> james_w: do you get the issue?
[12:03] <james_w> no, I haven't been able to reproduce
[12:04] <ubotu> New bug: #217004 in xorg (main) "[hardy beta] install failure (regression) with ProSavageDDR graphics chipset" [Undecided,New] https://launchpad.net/bugs/217004
[12:05] <seb128> james_w: I'll copy -O0 deb onlines and ask him to get a new valgrind log
[12:06] <james_w> seb128: great, thanks
[12:06] <james_w> a stacktrace may be useful as well
[12:06] <seb128> james_w:
[12:06] <seb128> list_clone_modes (Configuration *config, RWScreen *screen)
[12:06] <seb128>     RWMode **modes;
[12:07] <seb128>     for (i = 0; config->outputs[i] != NULL; ++i)
[12:07] <seb128>     {
[12:07] <seb128> 	if (config->outputs[i]->connected)
[12:07] <seb128> ...
[12:07] <seb128>     if (!modes)
[12:07] <seb128> 	return NULL;
[12:07] <seb128>
[12:07] <seb128> and
[12:07] <seb128> ==11339== Conditional jump or move depends on uninitialised value(s)
[12:07] <seb128> ==11339==11339== Conditional jump or move depends on uninitialised value(s)
[12:07] <seb128> ==11339==    at 0x804CF64: get_current_modes (xrandr-capplet.c:336)
[12:07] <seb128> ==11339==    by 0x804D601: rebuild_gui (xrandr-capplet.c:516)
[12:07] <seb128> ==    at 0x804CF64: get_current_modes (xrandr-capplet.c:336)
[12:07] <seb128> ==11339==    by 0x804D601: rebuild_gui (xrandr-capplet.c:516)
[12:07] <seb128>
[12:07] <seb128> james_w: that seems to indicate that the if condition in the loop is never true and it uses an uninitialised value
[12:07] <seb128> james_w: using
[12:07] <seb128> - RWMode **modes;
[12:08] <seb128> + RWMode **modes = NULL;
[12:08] <seb128> might be enough
[12:08] <james_w> yeah, that sounds sensible
[12:09] <seb128> l336 is the "if (!modes)" one
[12:09] <tjaalton> (II) SAVAGE(0): Configured Monitor: Using hsync value of 0.00 kHz
[12:09] <tjaalton> (II) SAVAGE(0): Configured Monitor: Using vrefresh value of 0.00 Hz
[12:09] <tjaalton> great
[12:09] <james_w> and that function calls the one at the top of the stacktrace eventually, with an item from the **modes
[12:09] <tjaalton> quality there, no DDC info -> use 0 by default
[12:10] <james_w> seb128: shall I prepare a debdiff of that change for upload, or would you like me to work with submitter first to test it?
[12:10] <seb128> james_w: I've no clue if that's enough to fix the issue of will just forward the bug to some other place, would be nice to get him testing the change
[12:11] <james_w> sure, I can do that.
[12:11] <seb128> thanks
[12:12] <seb128> james_w: https://bugs.edge.launchpad.net/ubuntu/+source/gnome-control-center/+bug/215396 too btw
[12:12] <ubotu> Launchpad bug 215396 in gnome-control-center "gnome-display-properties crashed with SIGSEGV in _start() [when running xgl]" [Medium,New]
[12:12] <seb128> james_w: could be the same bug
[12:12] <seb128> james_w: did you try to run the capplet under valgrind using xgl?
[12:15] <james_w> no, I didn't
[12:16] <james_w> that one has "on_screen_changed (scr=0x0", which is probably the cause
[12:24] <seb128> right
[13:17] <seb128> james_w: ok, so your packages work but you built using -O0 right?
[13:17] <james_w> yes, noopt,nostrip
[13:18] <seb128> ok, so it doesn't tell us if the fix is enough
[13:18] <seb128> I've asked for a new valgrind log
[13:18] <seb128> noopt will do -O0 and variables will be initialized
[13:18] <seb128> which will hide the non-initialized issues
[13:18] <james_w> ah, ok, shall I build some packages with the patch but normal build options?
[13:19] <seb128> you have other pending changes right? I would say to just upload the patch from this morning and this init now
[13:19] <seb128> or maybe try to fix the other crasher under xgl
[13:20] <james_w> it sounds like he is suffering from an issue that would trigger this, i.e. (config->outputs[i]->connected) is probably never true for him
[13:20] <seb128> right
[13:20] <james_w> yeah, I'll look in to the other one that you pointed me to and see if we can roll in that fix as well.
[13:20] <seb128> cool, thanks
[13:21] <james_w> I don't think I can't reproduce any of these Xgl bugs anymore though unfortunately, it fails so early for me that it barely covers any of the code.
[13:22] <james_w> this other one looks pretty straightforward though.
[13:24] <seb128> right
[14:31] <tjaalton> soren: please push your fix for mdetect, I'll change the vmmouse-handling..  I wonder if Recommends should suffice
[14:58] <soren> tjaalton: I don't.
[14:58] <tjaalton> ok, so it needs to be bumped
[15:02] <tjaalton> soren: what do you think of bug 216276?
[15:02] <ubotu> Launchpad bug 216276 in kvm "Regression: mouse support stopped working" [Undecided,New] https://launchpad.net/bugs/216276
[15:03] <tjaalton> (EE) xf86OpenSerial: No Device specified.
[15:03] <soren> tjaalton: Er, yeah, vmmouse requires a device to be set.
[15:04]  * soren hasn't read the bug, but from the context, I guess that's the issue.
[15:04]  * soren reads the bug
[15:04] <tjaalton> soren: ah, ok.
[15:04] <soren> Well, just /dev/input/mice works fine.
[15:04] <soren> AFAIR.
[15:04] <soren> Is that so bad?
[15:04] <tjaalton> soren: no, if it doesn't change :)
[15:05] <soren> What? The presence of /dev/input/mice? Why would that change?
[15:05] <tjaalton> it shouldnt
[15:06] <tjaalton> anyway, I'll add a check to add the device if it's a virtual setup
[15:06] <soren> Ok, cool. We should check that it works, though, but I belive it does.
[15:07] <soren> tjaalton: Ok. It should be almost functionally equivalent, but if you're more comfortable that way, that's cool.
[15:09] <soren> "almost" because in case we're converting a physical install to a virtual install (something I intend to work on a bit for intrepid), it'll need config changes.
[15:09] <seb128> james_w: how is the update going?
[15:13] <james_w> I'm hainvg trouble tracking this other one down
[15:13] <james_w> the NULL parameter isn't used.
[15:13] <james_w> it also reports that config is NULL, but there is a check for that in the function
[15:13] <seb128> how used?
[15:13] <seb128> hum
[15:14] <seb128> let me have a look
[15:18] <seb128> james_w: on what line is the check?
[15:19] <james_w> 122 here
[15:19] <james_w>     g_return_val_if_fail (current != NULL, NULL);
[15:19] <seb128> no
[15:19] <seb128> your version has not been uploaded
[15:19] <seb128> current is 0ubuntu5
[15:19] <seb128> and it has
[15:19] <seb128>     current = configuration_new_current (app->screen);
[15:19] <seb128>     if (app->current_configuration)
[15:19] <seb128> 	configuration_free (app->current_configuration);
[15:19] <james_w> current, not config sorry
[15:19] <seb128> 122 is the if line
[15:19] <james_w> ah, did I add that?
[15:20] <seb128> yes
[15:20] <seb128> is there an update pending upload?
[15:20] <seb128> I'm not sure if your debdiff were work on progress or sponsoring request, maybe there was some misunderstanding and something should have been uploaded but has not been yet?
[15:21] <james_w> no, it's fine, I just didn't remember adding that line
[15:21] <seb128> your check is weird
[15:22] <james_w> it's fine, I was just confused about what was uploaded and what wasn't/
[15:22] <seb128> static void
[15:22] <seb128> on_screen_changed
[15:22] <seb128> if should return
[15:22] <seb128> and not return value, no?
[15:23] <james_w> yeah, I thought it was odd as I was doing it, but didn't think to check.
[15:23] <james_w> I've been in python land for too long.
[15:23] <seb128> ;-)
[15:23] <seb128> ok, anyway
[15:23] <seb128> let's change that one to just return and get the 3 changes uploaded?
[15:24] <james_w> yeah, I'll do that.
[15:24] <seb128> the xgl error dialog, the init we added this morning and this check?
[15:24] <seb128> ok, good, thanks
[15:24] <seb128> we are getting better at each iteration ;-)
[15:24] <james_w> should I disable the help button as well?
[15:25] <james_w> s/disable/remove/
[15:37] <ubotu> New bug: #216276 in xorg (main) "Regression: mouse support stopped working" [Undecided,Fix committed] https://launchpad.net/bugs/216276
[15:38] <seb128> james_w: yes please
[15:50] <seb128> james_w: other requests came my way meanwhile ;-)
[15:52] <seb128> james_w: could you also change 01_debian_ubuntu.patch (you can rename it) to remove the debian specific choices rather, those are confusing for desktop users apparently
[15:53] <seb128> james_w: and the firefox entry in capplets/default-applications/gnome-default-applications.xml.in needs to be updated for use firefox-3.0 as icon name
[15:58] <james_w> sure, any bug numbers you want closing for these changes?
[16:03] <seb128> let me look
[16:03] <seb128> mpt mentionned those on #ubuntu-desktop, not sure if they are in launchpad
[16:05] <james_w> ok
[16:08] <seb128> james_w: no bugs apparently
[16:13] <james_w> seb128: http://paste.ubuntu.com/7005/
[16:13] <james_w> how's that?
[16:19] <seb128> james_w: looking
[16:31] <seb128> james_w: loosk good to me, I'll sponsor the upload, thanks
[16:34] <james_w> thanks
[16:35] <james_w> and huge thanks for actually finding the bugs :-)
[16:36] <seb128> and thank you for working on those ;-)
[17:13] <Q-FUNK> bryce: ?
[17:34] <Q-FUNK> anyone?
[17:34] <Q-FUNK> any news on sync'ing -geode from debian?
[18:14] <bryce> tjaalton: do you really think we should disable atieventsd?  I noticed a lot of bug reports on it crashing.  What does it do exactly?  Just a manager for multi-head or something?
[19:39] <tjaalton> bryce: yep, something to do with multi-head.. and it seems rather unstable
[19:40] <tjaalton> ..if it crashes when updating some libs for example
[19:43] <bryce> hmm, well if it's not strictly required for basic use of fglrx, then I'd also favor disabling it.
[19:44] <bryce> people will be upset at not being able to configure multiscreen, but hey, only so much crashy proprietary software we can reasonably support ;-)
[19:44] <bryce> fwiw, I raised that issue with ATI and am awaiting their feedback on it.
[19:44] <bryce> I will also let them know we plan to disable that tool due to crashes in it
[19:44] <tjaalton> ok cool. it was enabled in December I think
[19:45] <tjaalton> so it's not a regression to turn it off by default
[20:08] <ubotu> New bug: #213753 in xserver-xorg-video-ati (main) "Cannot get normal graphical session running after install" [High,Incomplete] https://launchpad.net/bugs/213753
[20:19] <bryce> tjaalton: btw, any reservations if I push the xserver patch for the firefox XAA offscreenpixmaps issue?  (bug #182038).  Basically it inverts the logic for that option, setting XAAOffscreenPixmaps False by default
[20:19] <ubotu> Launchpad bug 182038 in xorg-server "Black rectangle instead of image in FF3 [Hardy]" [Medium,Confirmed] https://launchpad.net/bugs/182038
[20:21] <tjaalton> bryce: nope, I guess we'll hear if it causes trouble ;)
[20:21] <bryce> (er, True by default??  Anyway, inverts it.)
[20:21] <tjaalton> but as fedora has done the same, it's probably not that bad
[20:41] <bryce> ...uploading...
[21:17] <bryce> ...awaiting approval... ;-)
[22:23] <ubotu> New bug: #217396 in xorg (main) "Hard lockup in X about once a week" [Undecided,Incomplete] https://launchpad.net/bugs/217396
[22:56] <ubotu> New bug: #99898 in linux-restricted-modules-2.6.24 (restricted) "kdevelop make X crash" [Undecided,Confirmed] https://launchpad.net/bugs/99898
[23:12] <ubotu> New bug: #215689 in xorg (main) "Wacom tablet is not supported anymore" [Undecided,Confirmed] https://launchpad.net/bugs/215689