=== _thumper_ is now known as thumper === yofel_ is now known as yofel [13:25] anyone on bugsquad / bugcontrol alive here and not busy at the moment? [13:32] when you all aren't busy... https://lists.ubuntu.com/archives/ubuntu-bugsquad/2012-August/003870.html i'd like to finalize this if we can, just need the wording :P [13:32] Planning on hosting a Jam for the Global Jam - mainly focusing on bugs. There will be some people there who aren't bugsquad - do I need to get them to sign up before they can actually do anythign ? [13:33] Mez: nope [13:33] anyone can help with bugs :) [13:33] Mez: but... [13:33] certain changes to bugs require bug control [13:33] so it might help to keep a bug control member on call [13:33] either on IRC or in person [13:33] (setting statuses to "Triaged" or "Won't Fix", and setting importance, for example, require bug control) [13:34] i assume you read this though, right? https://wiki.ubuntu.com/Jams/Bugs [13:35] Mez: mind a /query? === tremolux_ is now known as tremolux [14:13] TheLordOfTime: no I don't [14:14] (mind a /query) [14:15] TheLordOfTime: also, I'm bug-control (and running the jam) [14:47] https://wiki.ubuntu.com/UbuntuDeveloperWeek last day starting in 13 minutes in #ubuntu-classroom [16:28] Mez: ah, no worries then :) [16:28] Mez: just wanted to make sure ;) [16:28] * TheLordOfTime doesnt bother checking LP profiles, with the exception of the people who are on the Server Team, the Sponsors team, and the SRU team :P [16:29] Mez: i dont think they need to be on bugsquad to help with bugs :) === hjd_ is now known as hjd [19:38] shutdown -rF isn't forcing a fsck.. where would i file this bug? [19:44] kanliot: afaics there's no -F flag to shutdown [19:45] kanliot: try touch /forcefsck or touch /whatever/filesystem/forcefsck [19:45] lol [19:46] thanks royk. [19:46] saved me from filing a stupid bug, although it is documented [19:46] but not on the wiki [19:46] saved you to RTFM ;) [19:47] http://manpages.ubuntu.com/manpages/dapper/man8/shutdown.8.html [19:48] it's on that page [19:48] the dapper man page [19:48] anyhow you are 100% right [19:48] doesn't show up on lucid/precise [19:49] * RoyK has both [19:49] maybe 100.1% [19:49] dapper isn't very recent, though ;) [19:50] they should throw an error for the -rF option. [19:50] i'm gonna file a bug anyhow [19:50] return -EREJECTED [19:51] i don't understand [19:51] according to the docs on not-six-year-old-ubuntu-versions, there's no such flag as -F [19:52] well then it should give "no f parameter" error [19:52] file it against upstart or shutdown? [19:52] never mind, just fix the box [19:52] i don't understnd [19:55] just read that friendly manual [19:55] there's no -F argument any longer [19:56] dapper is >6YO and no longer supported [19:59] https://bugs.launchpad.net/upstart/+bug/1044041 [19:59] Ubuntu bug 1044041 in upstart "shutdown script happily accepts "shutdown -rF now" without warning me that the -F option is depreciated" [Undecided,New] [20:00] * RoyK wants to test a wee thing [20:01] http://getfreeporn.wtf.wherever.com/+bug/1044041 [20:01] ok, ubot2` wasn't that stupid ;) [20:01] server not found [20:01] no, it was a test [20:01] well i tested it :) [20:02] typical url you should not test [20:23] I would like to submit a bug, however reading the bug etiquette I understand I should specify the buggy package. I do not know which package is the cause of my problem... [20:23] xtalmath, what is the problem? [20:26] it is tearing (horizontal lines, which can occur anywhere on the screen but most often near the top, they seem static but really move a bit up and down, above the line is image from the older frame, and below the line of the newer frame) [20:26] xorg-xserver [20:27] I am running 12.04, up to date. happens both in normal unity (compiz) and unity-2d [20:27] I should execute that command or that is the package I should mention? [20:27] possibly linux would be better [20:27] 'ubuntu-bug linux' [20:28] you are probably right, but I was doubting, because in my view it could be any piece of software from application till screen. It could be the compositing manager,... [20:28] linux has little to do with display bugs [20:29] also of note, is that my applications report 60Hz framerate, while xrandr shows 50 [20:29] xorg is more likely related to the issue [20:29] the EDID information is not rejected by the nvidia driver [20:29] so I should file it under xorg? [20:30] also I am unable to take screenshots of the tearing, the screens negationistically show perfect frames without tearing [20:33] xtalmath, is this a regression after a recent update? [20:34] xtalmath, or you installed precise and it was always like that [20:34] I recently upgraded from 10.04 LTS to 12.04 LTS. I did not notice any tearing in 10.04. I noticed in 12.04. [20:35] jtaylor, the kernel has everything to do with graphics [20:35] I am uncertain that there was no tearing in 10.04, but I was running it for a long time and never noticed the tearing, whereas I quickly noticed in 12 [20:35] brendand: no, xorg and the drivers do [20:35] I seem to remember I had found a better modeline a few years ago, but that could easily have been another computer [20:37] jtaylor, e.g. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/918769 [20:37] Ubuntu bug 918769 in xserver-xorg-video-intel "X blink with Vostro 360 and Ubuntu Oneiric and Precise" [Medium,Fix released] [20:37] jtaylor, problem solved by new kernel. not new X server [20:37] or any driver changes [20:38] I have the impression that 50Hz is an unrealistic framerate for my pretty recent laptop (few years old, but was hi spec back then) [20:39] plus filing against linux gives more and better hw info [20:40] so I file under linux or xorg? [20:40] or unity? [20:43] i'd say linux [20:49] Im just going to try a few things with xrandr first. However it needs an output (VGA, LDVS,...) but I dont know which one my laptop uses internally [20:58] now I remember, its the proprietary nvidia driver which doesnt implement xrandr [20:58] I did indeed solve this with a modeline or xrandr command [20:58] while still using the proprietary driver === sebdebug is now known as seb128 [21:04] I am running nvidia driver version 295.33 and I read here http://phoronix.com/forums/showthread.php?70722-NVIDIA-s-302-Linux-Driver-Finally-Has-RandR-1-2-1-3 that 302.xx has finally implemented support for randr 1.2 and 1.3! how long till this makes it in ubuntu update? [21:05] I might ignore the tearing for a while, if there is substantial hope that this will fix my problem in near future... [21:10] xtalmath: nvidia 304.xx is in propsed, but it failed to build -> http://people.canonical.com/~ubuntu-archive/pending-sru.html [21:13] xtalmath: This PPA should have the new driver -> https://launchpad.net/~ubuntu-x-swat/+archive/x-updates/?field.series_filter=precise [21:17] how would I install this? and will it prevent me from following the official update stream after it surpasses this version? [21:17] add PPA, then through package manager? [21:20] xtalmath: https://help.launchpad.net/Packaging/PPA/InstallingSoftware is the doku [21:22] xtalmath: ppa-purge is a package to uninstall PPAs [21:22] would I have to uninstall the current nvidia driver first? [21:22] xtalmath: no [21:24] I added the ppa, now how I know what to install? [21:24] xtalmath: start the update-manager and install the update [21:25] xtalmath: or sudo apt-get update && sudo apt-get upgrade [21:27] I guess I do not need xserver-xorg-video-intel while I need the 2 nvidia ones, but should I leave xdiagnosis checked or uncheck it? [21:28] xtalmath: you only need the packages with nvidia in the name [21:28] ok, so Ill install them, and restart right? [21:28] xtalmath: yes [21:28] ill come back later [21:42] OK, the tearing did not yet disappear, but xrandr is giving more informations now! [21:43] also xrandr reports the right frame rate now [21:44] xtalmath: is the tearing present if you use nouveau? [21:45] I dont know, but I am kind of afraid of nouveau, since power management and fan control are done in nvidia driver, Im not yet sure how well I can trust nouveau. Everything may seem ok, but then later perhaps the fan bearings lubricating fluid evaporated from overuse, or the graphics card burns my house down [21:46] xtalmath: i don [21:46] 't think that nouveau will burn your card if you test it 10 minuets [21:46] ok [21:46] let me check [21:48] btw, xrandr --verbose gives some info about the current monitor mode, among which this line: [21:48] 1366x768 (0x24a) 72.3MHz -HSync -VSync *current +preferred [21:48] How should I interpret the - and * and + signs? is it saying without H nor V Sync ? [21:50] xtalmath: im don't know man xrandr should help you [21:50] of course, ill track that path after giving nouveau a chance for 5 minutes [21:53] uhm how do I install nouveau? libdrm-nouveau1a and xserver-xorg-video-nouveau were already installed according to package manager [21:53] xtalmath: and for me is it time to go i think if nouveau does not help you you should file it against xorg you can also test mainline kernels to test if the kernel cause your problem... [22:01] I am starting to believe the problem could be with unity itself, in which case it would not be a regression. I am running unity-2d, but I find no way to ensure that unity-2d / Qt are configured for vsync / doublebuffering... [22:03] if I understand correctly one needs both vsync and double buffering to eliminate tearing. [22:05] the problem is also present in Compiz unity though... hmm [22:26] Where can I find the unity-2d source code for my up to date precise configuration? [22:26] I would like to browse through it a bit to check if I can find a vsync or double buffer mistake in there... [23:12] OK, so I was thinking about how one requires Vsync and double buffering or buffer swapping at the same time to prevent tearing. I gave unity (compiz) another try, and went through its settings, disabling most obvious eye candy (since its feels like quite a burden, more about that later). I found the setting to force buffer swaps. The tearing was gone, the frame rate of the application was right! If only unity-2d would have a setting [23:13] that probably didnt make through completely [23:16] so although tearing was gone, and the frames per second was right, I get the impression that the application is "slow", it is not slow, it is merely one frame behind... i.e. the compositing manager waits for vsync and swaps its last frame to gpu, then swaps application frame and tells application it can render a new frame. [23:16] by positioning itself between applications and gpu in the graphics pipeline, the compositing manager delays the frames of the applications... [23:17] this delay is less noticeable if you allow tearing :) which is probably why tearing is "enabled" by default [23:18] more drastically, since the unity-2d shell is much lighter and more responsive, it should also have the setting to force buffer swapping... [23:19] also my compiz unity crashed into infinite loop, but I dont really care about it