[00:16] does this make sense to anyone ? "GdkPixBufLoader *loader = gdk_pixbuf_loader_new()" [00:17] #pidgin devs think its actually a GDK bug [00:17] or it could be kklimonda fault :) [00:17] downgrading to archive version [00:19] it may be [00:19] Anyone have any good idea what the when/if you set the status Confirmed on a Wishlist-bug? If you happen to agree with it? [00:19] kklimonda: I have no idea what GDK is [00:21] BUGabundo: a library ;) [00:22] andol: if it's not silly, and if it's not already implemented would be a good lower bar [00:23] james_w: Makes sense, thanks. [00:42] kklimonda: a pidgin dev fixed it [00:43] how? [00:43] $ export MALLOC_CHECK_=2 [00:43] $ export MALLOC_PERTURB_=254 [00:44] ugh.. [00:51] humm seb128 is not here [00:51] its is bug now [00:51] what do those variables do? [00:52] its on libgtk2.0-0, according to darkrain42 [00:52] kklimonda: no idea! kill the world? [00:52] heh ;) [00:57] BUGabundo, that's libc [00:57] http://www.gnu.org/software/hello/manual/libc/Heap-Consistency-Checking.html [00:57] hggdh: gtk+2.0 [00:58] Another possibility to check for and guard against bugs in the use of malloc, realloc and free is to set the environment variable MALLOC_CHECK_. When MALLOC_CHECK_ is set, a special (less efficient) implementation is used which is designed to be tolerant against simple errors, such as double calls of free with the same argument, or overruns of a single byte (off-by-one bugs). Not all such errors can be protected against, how [00:58] ever, and memory leaks can result. If MALLOC_CHECK_ is set to 0, any detected heap corruption is silently ignored; if set to 1, a diagnostic is printed on stderr; if set to 2, abort is called immediately. This can be useful because otherwise a crash may happen much later, and the true cause for the problem is then very hard to track down. [00:59] wait... are you telling me I need to valgring pidgin ? [00:59] oh damn [00:59] hggdh: but a bug is somewhere higher and MALLOC_CHECK_ is just working around it.. [00:59] good luck ;) [00:59] yes [01:01] valgrind running [01:01] we will wait ;-) [01:01] you better [01:02] still waiting here too [01:02] heh. Go get a coffee. You will have time ;-) [01:02] who ever though of valgrid gdb [01:02] that's just crazy [01:02] humm memory spike [01:02] the weird is that it worked with malloc_check_=2 [01:03] yes. It will be quite a memory usage, due to valgrind [01:03] done [01:03] didn't take all that long actually [01:04] _int_malloc (av=0x7f075a176a00, bytes=32) at malloc.c:4171 [01:04] 4171 malloc.c: No such file or directory. [01:04] in malloc.c [01:04] this is new [01:04] what happened? [01:04] crash [01:04] it coredumped? [01:04] but a new one [01:04] what signal? 6? [01:06] http://paste.ubuntu.com/164566/ [01:06] crash and valgring log [01:07] i'm not sure if you should use both gdb and valgrind at the same time.. [01:07] I doubt it would help... [01:07] cuz the valgrind is for gdb [01:07] kklimonda: hehe just hear that on #pidgin too [01:09] re running [01:09] but the coredump is on pidgin, which is good [01:10] but not with an SIGABRT, which is what I would expect from MALLOC_CHECK_=2 [01:12] it worked the 1st time.... and a 2nd with a large image. on a new profile, running on valgring [01:12] race condicion ? [01:13] might be [01:13] take out valgrind, just ru with GDB (and the malloc settings) [01:15] http://paste.ubuntu.com/164569/ [01:15] that's Plain valgrind === StooJ|Away is now known as StooJ [01:22] yes, there are some entries there that show errors dealing with (possibly) icons [01:22] so for the untrained eye is there a mm leak there? [01:23] mm? [01:23] you ran it very briefly, did you not? [01:23] I did [01:24] yes, there are leaks, and some of them suggest issues with icon handling [01:25] but only thepidgin developers can say. [01:25] but we are still missing symbols [01:25] BUGabundo, do you have a crash file under /var/crash? [01:27] checking [01:27] $ ls /var/crash/ [01:27] total 8.0K [01:27] drwxrwxrwt 2 root root 4.0K 2009-04-19 11:33 . [01:27] drwxr-xr-x 17 root root 4.0K 2008-05-13 14:53 .. [01:27] you'd probably have to restart apport with force_start=1 [01:28] i don't understand why is it completely disabled in releases.. [01:28] not sure if KK already has it ON [01:28] kklimonda: to not scare users [01:28] BUGabundo: it could just keep logs in /var/crash/ and do nothing [01:28] and clean up it every now and then [01:28] bug pitti about ot [01:29] BUGabundo, change /etc/default/apport [01:29] https://bugs.staging.launchpad.net/ubuntu/+bug/1 is timeing out [01:29] can't show you my spam [01:29] BUGabundo: Error: Could not parse data returned by Launchpad: The read operation timed out [01:29] orly? ;) [01:30] (Error ID: OOPS-1221EA4) [01:30] great even edge [01:35] BUGabundo, whats up [01:36] jtholmes: hey [01:37] BUGabundo, took you advice and send a canned form to about 10-12 bug reports and found out there is a mix of laptops and desktops more laptops, but probably only because more are using laptops [01:37] mix of those that are locking up taht is [01:37] I got it [01:37] so nothing clear? [01:38] however one person upgraded to 2.6.28.-12.43 and the problem went away [01:38] ah [01:38] so linux ? [01:39] for that person he said he did heavy loading and never had a problem and asked to have bug closed [01:39] bug 363787 [01:39] Launchpad bug 363787 in ubuntu "laptop locks up, appears to be at random" [Undecided,Fix released] https://launchpad.net/bugs/363787 [01:39] thats the one [01:41] jtholmes, the other bugs also show a "stuck for nn" message? [01:41] hggdh, "stuck for nn" pls clarify [01:42] hggdh: those "stuck" are usually Intel drivers [01:42] asac keeps beaching about it [01:42] Apr 19 09:10:58 user-laptop kernel: [ 2943.128506] BUG: soft lockup - CPU#1 stuck for 61s! [Xorg:2966] [01:42] 61s ??? [01:42] that's bad [01:42] hggdh, yes i say a few of those but concentrated on those that said solid lockup, no console access [01:42] it will vary, but I also had these some time ago [01:44] i never had any but upgraded to 2.6.28-12.43 just to check it out, actually i can boot from either 11.42 or 12.43 att [01:45] tomorrow I am going to ask one or two savvy users to try the 12.43 proposed kernel to see if the problem goes away, one person reported having the problem with the live cd so that person can do anything with the live cd [01:47] the line I showed above also suggests something to do with xorg, so it might be related to video. It would be nice to check what video card & xorg driver they are using [01:48] jtholmes: or even mailine kernels [01:49] ?? [01:50] i.e. use standard kernel (without the Ubuntu changes) and try it [01:51] from kernel.org [01:52] no, from the ubuntu kernel PPA [01:52] hggdh: and it works okay? [01:52] http://kernel.ubuntu.com/~kernel-ppa/mainline/ [01:52] why do you run that? [01:53] was just going to ask, sorry still learning but i keep notes on everything thx will poke there [01:53] sometimes I run the mainline kernel (like right now, on 2.26.30). In terms of triaging, it is good to discard the possibility of an Ubuntu change causing the issue (if it *is* a kernel issue, of course) [01:54] yes good it idea found it, excellent [01:55] usually you just need the image; if you are working with kernel drivers, you will need the headers. But I do not think there is support for restricted drivers [01:55] 2.26.30 is real close to the bleeding edge [01:56] it is pretty much there. It may cause bleeding, perhaps massive hemorrhage [01:56] bed time [01:56] so... caveat emptor! [01:56] see you tommorow [01:57] I did know about mainline, yes user beware!! === ejat is now known as e-jat [04:49] There is a bug in the 2.6.28.11.15 kernel, which ships with Ubuntu 9.04, that causes xorg to freeze on a black screen, at startup, for those using the intel driver, unless the "nopat" kernel option is added in grub. I understand that this bug has been fixed in newer versions of the kernel; however, I am concerned that Ubuntu 9.04 ships with this bug. Should this be filed in Launchpad; and if... [04:49] ...so, what is the typical solution--an update, a backport, or something else? [04:54] Squideshi, Firstly, that's not universally true. I don't have such a lockup. [04:54] Secondly, the bug has been filed in LP, but there's no easy way to change the images that have already circulated. [04:59] persia: I have been looking for an existing bug in Launchpad, but I haven't found one. Can you point me in the right direction? === MTeck is now known as MTecknology [05:02] I found the following bug in Launchpad; but it does not appear to be exactly the same: [05:02] https://bugs.launchpad.net/ubuntu/jaunty/+source/compiz/+bug/359392 [05:02] Launchpad bug 359392 in compiz "[i965] X freezes starting on April 3rd" [Undecided,In progress] [05:03] With that bug, xorg starts but freezes later. In my example, xorg freezes consistently during startup. [05:03] Unless, of course, I add the "nopat" kernel option in grub. [05:05] Also, that bug affects i965 chipsets; and I am running a G845. [05:07] Maybe bug #327844 ? [05:07] Launchpad bug 327844 in xserver-xorg-video-intel "[G45] X freezes about 1-5 min after switching compiz on" [High,Incomplete] https://launchpad.net/bugs/327844 [05:10] persia: I don't think so. That one also talks about freezes AFTER xorg startup. With this issue, xorg does not start--on a consistent basis, it immediately freezes before displaying any output (Giving a plain black screen, without the ability to switch between virtual terminals.) [05:10] persia: It looks like the "nopat" kernel option is a workaround, but I don't see that mentioned in any of these bugs. [05:11] persia: The intel developers say it's a pat bug in certain versions of the kernel. [05:12] Right. I think you have a new bug. The important thing is that it's not "xorg freezing on boot when using the intel driver", it's "G845 device freezing the kernel when run without nopat at X startup". [05:13] persia: "Some Linux kernel versions (such as 2.6.29) are known to have broken PAT code that causes recent versions of this driver to fail, (which can manifest as the X server simply not starting). This can be verified by adding the "nopat" option to the kernel command-line and seeing the failure go away. We hope that newer kernels in the 2.6.29.x as well as 2.6.30 and above will have working... [05:13] ...PAT code." [05:14] persia: That's from the release notes of the newest intel driver. [05:14] Hrm. I'm confused, as Ubuntu never shipped 2.6.29. [05:15] I think it's worth a bug, but I *know* that it doesn't affect all intel chipsets. [05:15] persia: Mine has 2.6.28.11.15. [05:15] persia: I think they were just giving 2.6.29 as an example, of the "some." [05:15] Right. I'm unsure. [05:16] persia: It is my understanding that this has been fixed in newer kernels; but I'm new to the project, so I don't know how Ubuntu addresses issues like this. [05:16] persia: Ubuntu will keep the same kernel version for 6 months, no matter what, correct? [05:18] Well, patches can be applied for critical issues, but full upgrades won't be done. [05:19] persia: Is that an "upgrade" or a "backport"? [05:19] The idea is to get more stable, rather than accepting the total mix of what upstream has done. [05:19] Neither. It's an "update". [05:19] persia: Oh, right. That's what I meant. [05:19] "Upgrades" usually refer to changes between releases (e.g. intrepid -> jaunty). [05:19] OK. Cool, so it could possibly become an update. [05:19] "Backports" usually refer to versions unsuitable for "update" being made available to work with previous releases. [05:20] Right. Needs the bug filed (with fair precision so others can replicate), and there needs to be a patch, and the patch has to work for those that have the problem and not break for those that don't have the problem. [05:21] What does "fix committed" or "fix released" mean? [05:21] I mean, how does this translate to packages/updates? [05:22] "fix released" means that it was fixed in *some* release. Whether the fix is avialable as an update, or only as an upgrade is not specified (although you can look at package history to determine which is required) [05:22] please see https://wiki.ubuntu.com/Bugs/Status [05:22] "fix committed" means different things to different people in Ubuntu, so it's hard to rely on it having a static meaning. [05:23] But it's generally related to there being a known fix somewhere that ought end up in the repositories soon. [05:24] * hggdh likes the "generally related" piece [05:25] hggdh, I've seen it used to mean that there was a patch mailed to an upstream mailing list, which is why I'm extra vague about it. [05:28] yes. I have seen it used to mean upstream has a fix (which I personally like) [05:28] (slready committed, I mean) [05:31] See, I don't like that use, because sometimes it takes *years* to get such a commit into Ubuntu. [05:32] I'd prefer "Fix Committed" to mean "The patch has been uploaded to Ubuntu". [05:32] But with changelog-closes-bugs, the semantics changed so that bugs were closed when the source fix was available, rather than when the binary fix was available. [05:32] Which, to me, made Fix Committed useless for Ubuntu. [05:33] this is a discussion still going on [05:33] With the work being done to expose Ubuntu packages as bzr branches, I'd believe it had meaning again when changes were committed to those bzr branches. [05:33] Well, yeah. Fix Committed is *incredibly* useful for most projects on LP, so it's not going away. [05:34] While I think it's useless for Ubuntu today, it used to be useful, and it may be useful in the future (in my mind). [05:34] What's the difference between the "linux" and "linux-generic" packages? [05:34] the problem is the amount of different uses LP has, and too few differentials [05:34] I seem to have the "linux-generic" installed, but they're both the kernel, right? [05:34] yes [05:35] "linux" is the source, linux-generic a specific build off the source [05:35] i.e., a binary package [05:35] So, I should report the bug as for linux-generic? [05:35] no, as linux [05:36] Even if I don't have that package installed? [05:36] sorry? [05:36] Synaptic doesn't show "linux" package as being installed--only "linux-generic". [05:36] hggdh, confusingly, there is also a binary package named "linux" (which isn't provided by the "linux" source package) [05:37] ah, OK. Yes, indeed, synaptic will only show you *binary* packages [05:37] Squideshi, Don't worry about it. If you try to report against linux-generic, it will automatically switch to linux, and if you install linux, it will just depend on linux-generic. [05:37] persia, is there indeed? And not related to the kernel? [05:37] Oh wait, I ALSO have "linux-image-generic" installed. [05:38] My head is spinning. :) [05:38] oh yes. the complete kernel package [05:38] hggdh, very much related to the lernel. It's a metapackage that depends on linux-image, which is a metapackage that depends on linux-image-generic, which is a metapackage that depends on the correct kernel. [05:39] easy and simple, just like what I should expect ;-) [05:39] Of course, for those not happy with those names, there's also a binary linux-generic that depends on linux-image-generic... [05:39] And since so many metapacakges are confusing, and to better handle coordination of upgrades between the kernel and modules, these are part of the linux-meta source package. [05:40] (which is why apt-get source linux never does the right thing) [05:40] one day I will stop and make a graph of them all... [05:40] Anyway, there's been some bugs about that, and some UDS sessions, and it ought be solved in a few more cycles. [05:40] and, eventually, then, linux-source will go away? [05:41] One of the problem is that legacy names need to be supported for upgrades, so there needs to be a coherent plan to detangle involving dummy packages that can be dropped after an LTS. [05:41] No, linux-source is completely different. [05:41] linux-source *doesn't* get the source code for the linux package, it's a binary package that contains the linux source code. [05:42] This is extremely useful for other kernel packages that just want to apply patches (e.g. linux-ports or linux-rt). [05:42] oh, yes, of course. Sorry [05:42] Heh. It took me a couple days to figure it out once, and now it's stuck. [05:43] hggdh: are you awake enough to help me with a couple of bugs? [05:43] But linux-source is useful because one source package can't build-depend on another source package, so by posting the source code as a binary package, we can have derivative kernels without having to either duplicate the source or make the "linux" source package even more complicated. [05:43] makes sense [05:44] micahg, I can try ;-) [05:44] can I mark bug 349970 and bug 329604 as dupes? [05:44] Launchpad bug 349970 in firefox-3.0 "no minimize maximize or exit in ff" [Undecided,New] https://launchpad.net/bugs/349970 [05:44] Launchpad bug 329604 in firefox-3.0 "It will automatically maximize when it open, and the close column can not be find. Required by F11 twice before returning to normal" [Undecided,New] https://launchpad.net/bugs/329604 [05:45] micahg, dups of which bug? [05:46] each other [05:46] there's probably more [05:47] micahg, for 349970 -- I have had this (any application), but it ended up being a metacity issue (restarting metacity with --no-composite solved) [05:48] so it would be interesting to ask the reporter (1) what happens with other applications, and (2) please, a screenshot) [05:48] and we would go from there [05:48] now, for 329604... [05:49] I am not sure I understand it [05:49] (but they do sound similar) [05:50] yeah, I thought it was the same issue [05:52] and then I just found this: bug 331890 [05:52] Launchpad bug 331890 in firefox-3.0 "FireFox starts in fullscreen mode automatically." [Undecided,Confirmed] https://launchpad.net/bugs/331890 [05:53] NOW we have a base bug, it seems [05:53] 329604 fits perfectly in [05:54] so I should mark that as dupe? [05:55] yes, mark 329604 as a dup of 331890 [05:55] ok [05:57] and ask 349970 if this is the same thing. Additionally, note that 331890 has what seems to be a workaround (disabling Legacy Fullscreen Support in Compiz' workaround). You could go ahead and ask on 331890 is this is indeed true [05:57] ah, I think I found the master [05:57] bug 99740 [05:57] Launchpad bug 99740 in firefox-3.1 "[MASTER] Firefox problems with desktop-effects" [Undecided,Fix released] https://launchpad.net/bugs/99740 [05:58] if it is indeed true, we should adjust the description of the bug as requested in https://wiki.ubuntu.com/Bugs/Description [05:58] if 99740 is the master, then this is a regression [05:59] it only says FF3 is traiged [05:59] upstream knows about it [05:59] https://bugzilla.mozilla.org/show_bug.cgi?id=465880 [05:59] Mozilla bug 465880 in DOM "Firefox lets javascript trick it into triggering "legacy fullscreen support" in compiz and other WMs" [Normal,New] [06:01] so it seems to be fixed in FF3.5, but no one's sure [06:01] yes, and our bug states ff3.1 resolved it [06:01] yes, but the comments show that people anren't sure [06:02] it is still the master bug [06:02] ok [06:02] micahg, you are in for a bit of work, if you do not mind... [06:02] well [06:02] how long? [06:02] I can deal with about a half hour right now [06:02] just a few minutes [06:02] ok [06:02] np [06:02] set me up [06:03] what we have now (and good work, BTW) is that bug 329604 (and *all* of its dups) are actually dup(s) of 99740 [06:03] Launchpad bug 329604 in firefox-3.0 "It will automatically maximize when it open, and the close column can not be find. Required by F11 twice before returning to normal" [Undecided,New] https://launchpad.net/bugs/329604 [06:04] so we should reset all dups on it to point to 99740, and then dup 329604 and 331890 to 99740 [06:05] oops, I meant 331890 (and *all* of its dups) [06:05] LP won't do that automatically? [06:05] nope [06:05] even the new version? [06:05] and I am pretty sure there is a bug opened against LP on that [06:05] if the new version does it, it did not do it to me yesterday [06:05] can I mark the new one first? [06:06] of course. Any order is good [06:06] I mean, the old master first? [06:06] There's been a bug opened about that since before Ubuntu swtched to LP for bug reporting. It's complicated. [06:07] ok [06:07] micahg, no, you cannot. You first have to take out all dups [06:07] so the old fashioned way then [06:07] do I need to comment on all of them? [06:08] no, I do not believe you need. It would just create spam mail for all subscribers [06:08] ok [06:08] new ajax makes it nicer [06:08] OK, so here's the new bug I just filed. I hope I did it correctly: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/372028 [06:08] Launchpad bug 372028 in linux "broken PAT code in kernel causes consistent xorg freeze at startup for some users of intel driver" [Undecided,New] [06:09] brb [06:14] So, how did I do with my very first bug report? :) [06:14] Squideshi, looks good [06:15] hggdh: all moved [06:15] Squideshi, it is still a kernel bug, so you should collect the data the kernel people ask for [06:15] micahg, thank you [06:15] and good work [06:15] oops [06:16] just added the other one [06:16] bug 349970 [06:16] Launchpad bug 349970 in firefox-3.0 "no minimize maximize or exit in ff (dup-of: 99740)" [Undecided,New] https://launchpad.net/bugs/349970 [06:16] Launchpad bug 99740 in firefox-3.1 "[MASTER] Firefox problems with desktop-effects" [Undecided,Fix released] https://launchpad.net/bugs/99740 [06:17] hggdh: What data do the kernel people ask for? [06:17] Squideshi, you can do that by running, from a command line, 'apport-collect'. Please see https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies [06:17] hggdh: you mentioned updating the desscription for bug 99740 [06:17] Launchpad bug 99740 in firefox-3.1 "[MASTER] Firefox problems with desktop-effects" [Undecided,Fix released] https://launchpad.net/bugs/99740 [06:18] micahg, yes, following https://wiki.ubuntu.com/Bugs/Description [06:18] with the workaround [06:19] I thought it was already there [06:19] **Workaround : Install compizconfig-settings-manager , start ccsm, click on "Workarounds" plugin in the "Utility" section and uncheck "Legacy Fullscreen Support". [06:20] darn! I *am* tired [06:20] sorry [06:20] there were a few workarounds though [06:21] I'm gonna see if I can dig up any more related to it [06:21] thank you [06:22] found one :D [06:22] oh, do I mark as a dupe first or comment first [06:24] if the bug is new, then yes, add the usual blurb "thank you, etc, etc, this is a duplicate of bug xxxxx, etc, etc", and then dup it [06:24] yes, but which one do I do first? [06:25] either should work [06:26] good morning [06:26] morning [06:26] YoBoY, bons dias [06:27] bonjour hggdh :) [06:27] hi micahg [06:27] bonjour, ça va bien? [06:27] très bien merci, et vous? [06:27] ça va, merci [06:28] hggdh: bug 322903 looks like more of the same [06:28] Launchpad bug 322903 in firefox-3.0 "firefox window obscures ubuntu desktop toolbars--have to toggle F11 or close firefox window." [Undecided,New] https://launchpad.net/bugs/322903 [06:28] heh, dup the beast.., [06:31] hggdh: how about bug 308897 [06:31] Launchpad bug 308897 in compiz "new firefox windows take up entire screen" [Undecided,New] https://launchpad.net/bugs/308897 [06:32] sounds the same, micahg [06:32] ok, do I need to change the package to ff3? [06:32] no, not when dupping [06:34] found another one [06:34] it's up to 30 dupes :) [06:35] a sac will be happy, I guess [06:35] hopefully, otherwise, I'm going to need to go hide for a while :) [06:36] well, there is that... [06:37] now that I know what to look for, it's easier to find the dupes [06:39] and... this is it, for me. I am off to bed [06:39] If I think a bug is like this one, shoudl I jsut ask? [06:39] g'night to all [06:39] night hggdh [07:07] good morning [07:28] good morning bugsquad [07:38] hi dholbach, hi thekorn [07:38] dholbach: can i ask you something about 5 a day? [07:38] hi YoBoY, hi thekorn [07:38] sure [07:44] hello dholbach and YoBoY === StooJ is now known as StooJ|Away === mkorn is now known as thekorn_ === thekorn_ is now known as thekorn === StooJ|Away is now known as StooJ [09:55] is there a bug that randomly freezes the pc? [12:26] how does it take for a bug which has the status "new" to be looked at ...? [12:26] +long [12:26] Baum: what bug number? [12:26] 367918 [12:26] bug 367918 [12:26] Launchpad bug 367918 in libpam-mount "sshd cannot mount cifs shares" [Undecided,New] https://launchpad.net/bugs/367918 [12:27] well i must say before that i had to support novell and redhat and had someone who looked at the stuff im submitting. === dmesg is now known as edsoncanto [12:30] the bug is verified on a number of workstations [12:30] or maybe my missconfiguration [12:31] Baum: why didn't you update pam files? [12:32] kklimonda i tried that too.. merging the files with the options. afterwards on another workstation and i got the same result. so something must have changed [12:33] Baum: I'd try first with pam configuration which is shipped with ubuntu [12:34] to make sure that the problem doesn't lay in your changes [12:37] ok what i did was purge the pam-mount stuff. install the new package. and i added my common stuff. that didnt work [12:37] but i can try again when i have time [12:39] and i gotta say. changing such things in a release version is generally bad. to put new pam-mount packages in jaunty ok.. but changing something elementary with a normal update package is just mad [12:39] it shouldn't happen [12:40] right. u know how it is. its fun and play as long as you have such problems at home. [12:40] it still shouldn't happen [12:40] it's a regression [12:41] it was just simple apt-get upgrade in intrepid? [12:43] i guess that libpam-mount isn't the right package then [12:43] because it wasn't changed in -updates nor -security [12:43] it may be libpam-runtime [12:44] as it was changed in -updates [12:45] and it was updates recently (21.04.09) [12:45] updates* [12:45] erm.. [12:45] updated* [12:46] Baum: so, was it normal upgrade of intrepid? === thekorn_ is now known as thekorn [13:43] Hi BugSquad ! [14:58] mnemo, i've upgraded to xorg-edgers ppa and the bug seems fixed [14:58] nanomad: bug number? [14:58] #3360 [14:58] ops [14:59] #336320 [14:59] ah cool [14:59] did you upgrade all packages to xorg-edgers? I mean both -ati and mesa? [14:59] yes [14:59] let me check tho [14:59] im guessing from the stack that the bug is in mesa [15:01] nanomad: that's good news... now we just need to git bisect mesa to find which specific patch fixes it [15:01] mnemo, no ati-related packages where upgraded (except for libgl1-mesa-dri that contains r300_dri.so) [15:01] ok [15:01]