[17:39] <gaurangt> what's the procedure to delete a network space in juju?
[17:39] <gaurangt> or can we move the subnet from one space to other?
[17:41] <xarses_> is there a useful way to get a log of the actions a unit may have been performing at a specific time from the juju cli?
[18:21] <rick_h> xarses_: not from the CLI. I guess you could look for action results that occurred around the timeline? but you'd need to check the logs to get specific
[18:22] <rick_h> xarses_: turning on the audit log would make it cleaner/easier a bit but it's still in a log
[18:22] <xarses_> urgh, too many signals to just sift in every damned log
[18:23] <xarses_> on a related subject, is there a way to disable the local haproxy in the openstack api charms?
[18:25] <xarses_> something is raising 503's on me randomly, and that guy has like no log
[18:25] <xarses_> and I have a balancer elsewhere
[18:26] <rick_h> xarses_: do you know what action you're looking for? I'm curious what the log | grep action might be or the name of the action
[18:26] <xarses_> nope, no clue what so ever
[18:27] <xarses_> we run (openstack) rally against the cloud to detect failures, and have noticed recently that we are getting random failures on endpoints that are nearly always 503's
[18:27] <rick_h> xarses_: so not sure what's actually erroring in the stack?
[18:27] <xarses_> but calls prior and after, that in many even include said api pass
[18:31] <xarses_> yep, no clue what's causing the errors
[18:34] <xarses_> oh, the one I'm looking at currently isn't 503, its 502 (incomplete or invalid response)
[18:34] <xarses_> bad gateway
[18:50] <xarses_> argh, found it
[18:50] <xarses_> this thing, it ruffles my feathers soo much
[18:53] <xarses_> something like this happens https://gist.github.com/xarses/5a7beb4cc856588c3f91ce0b094b4f28
[18:54] <xarses_> and then anything to look at is SIGTERM and restarted
[18:54] <xarses_> apache, npre, the python wsgi's
[18:54] <xarses_> memcache
[20:19] <xarses_> ugrh, so the systemd thing is probably just annoying
[20:19] <xarses_> there is a session into the host before that, and then a bunch of things related to the charm reload, I'd guess that its the culprit as I originally suspected
[20:20] <xarses_> so I'm back to, something in the charm allows for concurrent modification of members and ends up causing an outage
[21:41] <xarses_> so `juju debug-log` doesn't seem to work
[21:44] <xarses_> among it not having any logs for the units I'm looking for
[21:44] <xarses_> --lines isn't respected
[21:45] <xarses_> > juju debug-log --no-tail --include unit-percona-cluster-0 --lines=1 --replay | wc -l
[21:45] <xarses_> > 4489
[21:45] <xarses_> and the example in --help has a `-T` flag which doesn't exist
[22:43] <skay> I just ran in to a VersionConflict with requests when trying to create a new charm using charmtools. https://paste.ubuntu.com/25486709/
[22:45] <skay> grar
[23:23] <thumper> xarses: hey
[23:23] <thumper> xarses: which juju version?
[23:25] <thumper> xarses: also, thanks for pointing out the -T problem, we'll get that fixed
[23:25] <thumper> xarses: are you able to file a bug? if not we could add one
[23:28] <xarses> 2.2
[23:28] <xarses> probably 2.2.2
[23:28] <xarses> we where updating some of the controllers not sure which that was on
[23:29] <xarses> for which -T or the lines not being respected, or nothing from the unit im looking for?
[23:29] <thumper> xarses: we did update the include option so you should just be able to specify the unit like normal, so 'percona-cluster/0'
[23:29] <thumper> -T doesn't appear to be an option in the code
[23:29] <thumper> I'm kinda surprised it isn't complaining
[23:29] <xarses> oh, it complains of the invalid option
[23:30] <thumper> oh, good
[23:30] <xarses> its just in --help long description of examples
[23:30] <thumper> yeah, that needs to be fixed
[23:30] <thumper> also the examples should just specify the machine ids and unit ids rather than the unit- and machine- strings
[23:30] <xarses> I was looking initially for unit-neutron-0, which has one entry in the uncompressed log file, it never gave that back
[23:31] <xarses> also tried neutron/0
[23:31] <thumper> ok...
[23:31] <thumper> it is possible that there are lines in the local file that never make it to the server
[23:31] <xarses> only switched to percona-cluster because it was spewing warnings and not respecting --lines
[23:31] <thumper> for debug-log to pick up
[23:31] <thumper> the local log files are written as things happen
[23:31] <xarses> no there is one line in the /var/lib/juju thingy on the controller
[23:32] <thumper> but debug-log only works on the logs that ended up in the controller
[23:32] <thumper> oh...
[23:32] <thumper> hmm...
[23:32] <xarses> that grep found
[23:32] <thumper> if it made it into logsink.log then it should be in the db
[23:32] <thumper> unless it was removed due to pruning
[23:32] <xarses> ya that one
[23:32] <xarses> so long story with debug-log aside
[23:33] <xarses> shouldn't it have logged actions like applying charm updates and restarting services?
[23:33] <xarses> they wheren't logged on either the controller or the unit
[23:33] <xarses> they don't emit a syslog
[23:33] <xarses> and are driving my troubleshooting crazy
[23:34] <thumper> you mean the charm actions?
[23:34] <thumper> as in the charm is restarting an openstack service
[23:34] <thumper> ?
[23:34] <thumper> or the restarting of juju agents?
[23:35] <xarses> well as in freaking out and causing an outage on all of my neutron (api) servers at the same time during a charm upgrade
[23:35] <xarses> I can only prove my issue is due to the charm upgrade, because less than a minute prior memcached is started for the first time ever
[23:35] <xarses> there are no other logs that I can find that show that juju intended to or was actively taking actions on the unit
[23:36] <thumper> what is the logging config set to?
[23:36] <xarses> who's config?
[23:36] <thumper> juju model-config logging-config
[23:36] <thumper> for the model in question
[23:39] <xarses> looks like a default of warning
[23:39] <thumper> in which case, you will only get told of things not working
[23:40] <thumper> juju model-config logging-config=juju=info
[23:40] <xarses_> $ juju model-config logging-config
=WARNING;unit=WARNING
[23:40] <thumper> juju model-config "logging-config=juju=info;unit=warning"
[23:41] <thumper> xarses: that would then tell you more about what juju is doing for that model
[23:41] <xarses> le sigh, google didn't give me any information like this about levels
[23:41] <thumper> we are trying to make sure that INFO level logging is useful and not too verbose
[23:41] <xarses_> all I could ever find was https://jujucharms.com/docs/2.2/troubleshooting-logs
[23:42] <thumper> xarses: I'll make sure that we get the docs updated to talk about the log levels
[23:43] <thumper> xarses: I'm going to relocate back home, should be back online in ~20 minutes
[23:44] <xarses> k
[23:44] <xarses> thanks this was insightful


[01:39] <j1mc> hey all
[01:40] <j1mc> hey jjesse
[20:35] <achiang> hello, i'm looking for a pointer on how to properly modify the help displayed by yelp (on an older version, lucid). specifically, i'd like to add a link to a PDF installed somewhere on the system.
[20:35] <achiang> i'm getting lost in all the XML
[20:40]  * achiang wonders if j1mc might have any clues. micahg said you might...
[20:42] <j1mc> hi achiang
[20:42] <achiang> hi
[20:43] <j1mc> achiang: you want the ubuntu help to open a pdf for all ubuntu users, or you just want it on your own system?
[20:44] <achiang> j1mc: well, we can assume it's just for me right now, that it's not really an upstreamable change.
[20:45] <achiang> j1mc: but to talk in terms of code and patches, i'm looking at 04_new_ubuntu_layout.patch in yelp_2.30.0-0ubuntu2, and not seeing how to extend the examples there to add an extra link to a PDF file
[20:46] <achiang> j1mc: i don't want to completely replace the help, actually. just add a new link that says, "hey, check this PDF out for more info"
[20:47] <j1mc> achiang: well, we are really only doing bug-fixes on older releases... but... as for how to do it, i'd need to take a look at the file.
[20:47] <j1mc> could you give me the file name?
[20:48] <achiang> j1mc: right, so like i said, this isn't suitable for upstream...
[20:50] <achiang> j1mc: i guess i don't really have a file name right now, just trying to understand the general technique. i guess we could assume /usr/share/doc/achiang/foo.pdf
[20:50] <j1mc> still, the file name would be helpful
[20:51] <achiang> ah, interesting, there is a file named /usr/share/gnome/help/system-admin-guide/C/system-admin-guide.pdf
[20:51] <achiang> j1mc: we can use the above as an example?
[20:52] <j1mc> achiang: i'm looking... thanks for your patience
[20:53] <achiang> j1mc: i appreciate any help you can offer, so thank you!
[20:56] <j1mc> achiang: if you want to include your link in the help browser, you'd want to do something like this:
[20:57] <j1mc> <ulink url="file://path/to/file.pdf">open the file</ulink>
[20:57] <j1mc> in the native docbook of the ubuntu help
[20:58] <j1mc> but yelp isn't set up to look at your home directory by default
[20:58] <j1mc> ... so ... i'd be wary of making changes to any text in your /usr directory
[20:58] <j1mc> are you doing this just for yourself?
[21:00] <achiang> j1mc: i think i understand what you are saying -- if i change the text in the /usr directory, and point it to a path in my home directory, the link won't work for other users?
[21:00] <j1mc> well, that's one thing, but it's also just not recommended to modify content in the /usr directory
[21:01] <j1mc> i mean, for a user to modify content in the /usr directory
[21:01] <achiang> j1mc: right, got it
[21:02] <achiang> j1mc: thank you for your help
[21:02] <j1mc> do you know how to get the latest docbook sources for what you want to do? are you trying to build this out for other users?
[21:03] <achiang> j1mc: well, i'm kinda working on a derivative distribution of sorts, so... it would be for other users eventually, but not via a PPA or a web page or anything like that
[21:04] <j1mc> ok
[21:05] <achiang> j1mc: i'm actually staring at the yelp package, but not entirely sure what to modify. it sounds like there is separate docbook source i could modify?
[21:05] <j1mc> you can use that ulink feature to link to any file, though. you'd need to modify the docbook to do what you want to do, though.
[21:05] <j1mc> best of luck... let us know if you have more questions
[21:33] <j1mc> hi glatzor
[21:33] <j1mc> hi MrChrisDruif
[21:33] <MrChrisDruif> Aloha j1mc :)
[21:34] <MrChrisDruif> How's it going?
[21:34] <j1mc> :)
[21:37] <MrChrisDruif> Well?
[21:38] <j1mc> just saying hello
[21:38] <MrChrisDruif> xD
[21:38] <MrChrisDruif> And I'm just asking how it goes :P
[21:39] <j1mc> oh, it is going fine, thanks. :)
[21:39] <j1mc> you?
[21:40] <MrChrisDruif> Pretty good :D


[04:56] <tux2bsd> xfce + xfce4-screensaver, it stopped locking
[04:56] <tux2bsd> it used to be fine (20.04)
[04:57] <tux2bsd> but I recently noticed it doesn't lock, or even blank the screen
[04:57] <tux2bsd> (haven't touched that config in over a year)
[04:59] <tux2bsd> searching says replace xfce4-screensaver with light-locker
[04:59] <tux2bsd> anyone here had to unbreak whatever broke this?
[10:08] <jarnos> Hello. Is xscreensaver started differently in latest Xubuntu with 5.45? In Fedora Linux xscreensaver is not started, if certain other screensaver(s) are installed: https://gitlab.xfce.org/xfce/xfce4-session/-/issues/115#note_43144
[10:29] <jarnos> Hello. I would like to know how xfce4-screensaver is working in latest Xubuntu. I use 20.04 myself and here it works so that it will be started on session start even if not selected in autostart dialog and it will be used with suspend even if the daemon is not running before suspending and even if another screensaver is configured to be used.
[10:31] <jarnos> Only good option to use another screensaver is to uninstall xfce4-screensaver. Even if there is xflock4 script that supports using user configurable screensaver/locker for locking.
[10:35] <jarnos> I am also interested in how xscreensaver (5.45) is working in the latest Xubuntu. The latest version upstream is 6.02.
[10:36] <jarnos> But even 5.45 has systemd integration.
[10:37] <jarnos> Will xscreensaver refuse to start, if xfce4-screensaver is installel like in Fedora? https://gitlab.xfce.org/xfce/xfce4-session/-/issues/115#note_43144
[10:38] <jarnos> I think it should be possible for a user to choose a screensaver he/she uses even if there is another one installed.
[10:42] <jarnos> I think it would be better not to have xfce4-screensaver as recommended package of xfce4-desktop because it is not even maintained currently.
[13:31] <jarnos_> https://gitlab.xfce.org/xfce/xfce4-power-manager/-/issues/127
[22:54] <bilgehan> hi


[09:24] <soren> Erm... I get a white screen when I log into GNOME in Intrepid. What am I doing wrong?
[09:24] <soren> GDM looks fine.
[09:25] <tjaalton> disable compiz
[09:25] <tjaalton> it's broken on intel
[09:25] <soren> :(
[09:25] <tjaalton> 965 at least
[09:25] <soren> Ok.
[09:25] <soren> Thanks.
[09:25] <soren> This will be fixed at some point, I presume?
[09:25]  * soren kinds of likes compiz.
[09:26] <tjaalton> there are two bugs and they were marked as blockers for mesa 7.1 yesterday, so yes they'll get fixed soon :)
[09:26] <soren> Fantastic. Thanks.
[09:26]  * soren hugs tjaalton
[09:26] <tjaalton> the white screen one already has a fix, but then you'd end up with a black screen with some corrupt graphics :)
[09:26]  * tjaalton hugs soren back
[09:28]  * soren ponders the semantics of "fix" :)
[09:29] <tjaalton> ok, patch :)
[09:29] <tjaalton> two, actually
[09:36] <bryce> tjaalton: I heard back from Intel on this
[09:36] <bryce> Yong:
[09:36] <bryce> I just reproduced #14441 on 965G with tip of xserver1.5, mesa, drm, xf86-video-intel.  A quick way to resolve it is commenting out
[09:36] <bryce>     if (pI830->useEXA)
[09:36] <bryce>         pDRIInfo->texOffsetStart = I830TexOffsetStart;
[09:36] <bryce> in xf86-video-intel/src/i830_dri.c. Then compiz works.  You can ask Ubuntu guys for more test.
[09:36] <bryce> For #15477, It doesn't happen on G965. We may need to find a 945 box to look at it.
[09:37] <bryce> - Peng
[09:37] <bryce> night.
[09:37] <tjaalton> commenting that out breaks other setups
[09:37] <tjaalton> the workaround is already mentioned on the bug
[09:39] <tjaalton> 15477 does happen on 965
[09:39] <tjaalton> but for that bug there already are patches
[09:41] <tjaalton> oh, night :)
[14:10] <pwnguin> heh
[14:10] <pwnguin> i filled up my / partition
[14:10] <pwnguin> oops
[14:10] <pwnguin> fun finding random crap on cleanup
[14:10] <pwnguin> XFree86.0.log
[19:58] <tjaalton> now, let's clear all l-r-m* from nvidia/fglrx bugs and let tseliot and superm1 have some fun :P
[20:02] <tjaalton> a great way to boost my lp karma
[20:03] <pwnguin> man, if you just mark them all invalid
[20:04] <pwnguin> you will earn a new top score on the "people pwnguin is angry at" table
[20:05] <tjaalton> hah
[20:05] <pwnguin> pvalli does that and it ticks me off
[20:05] <pwnguin> i just love getting told my bug is a dupe, but if i want to know WHICH one, i should just go look it up myself
[20:09] <tseliot> tjaalton: I'll have a lot of fun then ;)
[20:10] <pwnguin> btw
[20:10] <pwnguin> this might be a good time to point out that there is an upstream bug tracker email address
[20:10] <pwnguin> and that launchpad apparently supports this
[20:12] <tjaalton> pwnguin: what benefit does it give?
[20:12] <pwnguin> a feeling that at least we tried?
[20:13] <pwnguin> plus, if we used it there might be an incentive to use something smarter on their end
[20:13] <tjaalton> ok, so does bugzilla have such a feature (email)?
[20:13] <pwnguin> I dont understand the motivation of the question
[20:14] <tjaalton> upstreams tend to use bugzilla
[20:14] <pwnguin> nvidia is upstream
[20:14] <tjaalton> so where to send the bug
[20:14] <tjaalton> ah
[20:14] <pwnguin> you've got this backwards i think
[20:14] <tjaalton> yeah, but they want that people run their script
[20:14] <tjaalton> hehe
[20:14] <pwnguin> LP does have an email, but that wasnt the point
[20:15] <pwnguin> tjaalton: the installer script or some crazy bug report script?
[20:15] <tjaalton> some crazy ..
[20:15] <pwnguin> fun
[20:15] <tjaalton> nvidia-bug-report.sh
[20:18] <tjaalton> tseliot: yes, you'll have a party of the century ;)
[20:18] <tjaalton> it never ends
[20:36] <bryce> tjaalton: does the patch on 15477 look ok for inclusion in our packages?
[20:37] <bryce> (good morning btw!)
[20:40] <tjaalton> bryce: morning bryce! yes, it does, but it's pointless without a fix for 14441 :)
[20:44] <tseliot> bryce: you're going on a vacation soon, right? May I ask how long it will last? (so that I know when I can bug you again about phase 1)
[20:46] <bryce> tjaalton: ok, I highlighted the 14441 issues back to them
[20:46] <bryce> tseliot: next week will be the distro sprint in London, then I'll be on vacation the week after that
[20:47] <tseliot> ok, thanks
[20:47] <bryce> I can't promise I'll get anything useful done during the sprint; most of the time is meetings and talking with other devs about bugs and such
[20:48] <tseliot> bryce: no problem, in the meantime I'll do my part ;)
[20:49] <bryce> awesome
[20:49] <bryce> tjaalton: btw, do you have any ideas on #246585?  I was trying to help mdz on it yesterday
[20:50] <bryce> tjaalton: it appears the new -vesa doesn't report its screens correctly to gdk.  I've dug through the code from the gdk side of things yesterday, but am thinking to look at it from the -vesa side, but am not sure what angle to approach it
[20:51] <tjaalton> bryce: the driver is very simple.. I believe the client code is doing something wrong here
[20:51] <bryce> jcristau observed it seems that vesa seems to be using xinerama or thinking its using xinerama
[20:51] <tjaalton> hmm
[20:51] <tjaalton> I bet fedora is seeing something similar then
[20:52] <bryce> yeah I've been through the driver source; I doubt the bug is there, but I also dug down pretty deep in gdk and didn't spot it
[21:02] <tjaalton> compared vesa logs from hardy with the one from that bug.. nothing apparent in sight
[21:14] <tjaalton> I'll subscribe ubuntu-x to fglrx-installer/nvidia* bugmail
[21:17] <mario_limonciell> tseliot, hum are you seeing seg faults starting X now on intrepid w/ nvidia too?
[21:18] <mario_limonciell> fglrx most definitely broke in the last day or two (bug 247376)
[21:18] <tjaalton> so fglrx doesn't work with xserver 1.5
[21:18] <tjaalton> either
[21:18] <tjaalton> nvidia -173 and -177 work
[21:19] <tjaalton> but -71 and -96 don't
[21:19] <mario_limonciell> well i wonder why i'm segfaulting then on this box w/ 177
[21:19] <mario_limonciell> i see the splash screen and then the X server dies
[21:19] <tjaalton> splash screen of what?
[21:19] <tjaalton> usplash?
[21:19] <mario_limonciell> nvidia splash screen
[21:19] <tjaalton> ok, so it's not the same then
[21:19] <tjaalton> maybe -177 is just buggy ;)
[21:19] <mario_limonciell> but yeah usplash is a mess on a bunch of boxes too
[21:20] <tjaalton> right...
[21:20] <tjaalton> let's get plymouth!
[21:20] <mario_limonciell> the weird thing with the nvidia segfault, there are no errors in the log except not being able to load dri2
[21:21] <tjaalton> (plymouth == the new boot-candy for fedora10, using kernel modesetting)
[21:21] <mario_limonciell> i only know it's a segfault from starting X on it's own
[21:21] <mario_limonciell> ah
[21:21] <mario_limonciell> and that's what's breaking usplash?
[21:21] <tjaalton> no, it's not in ubuntu :)
[21:21] <mario_limonciell> oh phew.
[21:22] <tjaalton> possibly some framebuffer madness
[21:38] <tseliot> mario_limonciell: sorry, I haven't updated my Intrepid system yet. I'll do it tomorrow
[21:39] <mario_limonciell> tseliot, yeah hopefully it's easily resolvable.  i've only got one intrepid nvidia system up and running.  unfortunately all the other ones i have still are fglrx
[21:39] <mario_limonciell> so SOL for a bit there
[21:39] <tseliot> tjaalton: plymouth == works only with Intel?
[21:40] <bryce> *sigh* ETOOMANYBUGS
[21:43] <tjaalton> tseliot: yes, currently
[21:43] <tjaalton> http://katzj.livejournal.com/432586.html
[21:43] <tseliot> mario_limonciell: did you try with Disable "dri2" in the Module section of your xorg.conf?
[21:43] <mario_limonciell> i didn't know disable was a valid keyword
[21:43] <tjaalton> the warning is harmless
[21:43] <mario_limonciell> i'll give that a shot
[21:45] <tseliot> mario_limonciell: it's in man xorg.conf
[21:45] <tjaalton> oh, that screencast is using vesafb, not modesetting
[21:45] <tjaalton> so it has multiple fallbacks
[21:45] <tseliot> mario_limonciell: let me know how it goes
[21:46] <tseliot> tjaalton: ok, it's a sensible idea then
[21:46] <tjaalton> bryce: i'm with you man..
[21:47] <mario_limonciell> tseliot, well no more dri2 error (duh), but still segfaulting
[21:47] <tjaalton> mario_limonciell: have you tried -173?
[21:48] <mario_limonciell> yeah i just rolled back to it fearing something in 177 went wacky
[21:49] <tjaalton> what the hell to do with nvidia/fglrx bugs that are a) old b) have no logs c) no idea what chip the user has
[21:49] <tjaalton> going through lrm-2.6.15
[21:50] <mario_limonciell> apport is off by default now...
[21:50] <mario_limonciell> so no logs via apport
[21:50] <bryce> tjaalton: have xserver upgrades always been this rough?  I don't recall the 1.4 update triggering this many serious issues
[21:50] <pwnguin> didnt everything dangerous fall out of 1.4?
[21:51] <tjaalton> bryce: nah, the vendors are just lazy
[21:52] <tseliot> mario_limonciell: does it help if you do startx -- -ignoreABI ?
[21:52] <bryce> tjaalton: for old lrm bugs, I'd just let them know the bug's out of date and won't be further investigated here, and kindly ask that they re-test with hardy and report against $package if it still occurs
[21:52] <tjaalton> "kindly".. forget about it then :)
[21:52] <bryce> *short*
[21:52] <bryce> s/h/n/
[21:52] <tjaalton> ah, monty python on the telly
[21:52] <tjaalton> hehe
[21:52] <bryce> on the plus side, I'm finding myself getting pretty good at gdb
[21:53] <tseliot> tjaalton: I receive a lot of emails which say only "I used Envy and now my card doesn't work" :-P
[21:53] <bryce> tseliot: all of our Xorg bugs go that way :-)
[21:53] <bryce> except s/Envy/<$package>/
[21:53] <bryce> fun fun
[21:54] <mario_limonciell> tseliot, well very odd, but i reinstalled 177 again (after downgrading to 173) and it appears to be working now?
[21:54] <tseliot> bryce: we should just learn how to read our users' thought, that's all...
[21:55] <bryce> I dream about making a web interface with some regex's to detect if they've included Xorg.0.log, mentioned a crash but not included a backtrace, etc. etc. and have some nice checkboxes (and 'check-all') so us triagers can process those stub bug reports faster
[21:55] <mario_limonciell> tjaalton, well i don't know that i would say they are lazy, but there was no predictable release date for xorg 1.5
[21:55] <tseliot> mario_limonciell: did you do rmmod and modprobe before restarting the Xserver?
[21:55] <mario_limonciell> tseliot, yeah i did
[21:55] <mario_limonciell> so it's very hard to get your schedule together when you don't have a stable list of changes for the ABI and such
[21:55] <tjaalton> mario_limonciell: and there still isn't but yeah
[21:55] <tseliot> mario_limonciell: ok, naive question
[21:55] <bryce> btw, I talked with AMD yesterday.
[21:55] <mario_limonciell> about xorg 1.5 support?
[21:55] <tjaalton> but fedora9 has been out two months, so either they have no fedora users or something is really wrong
[21:56] <bryce> they're working on implementing xrandr 1.2 for fgrx 8.53, which is slated to be released in Sept
[21:56] <tjaalton> sweet
[21:56] <bryce> betas will be released to testers next month
[21:56] <mario_limonciell> bryce, er well i'm not sure you should be mentioning that with ubuntulog sitting around...
[21:56] <tjaalton> sssh
[21:57] <tjaalton> :)
[21:57]  * bryce shushes up
[21:57] <bryce> actually I'm not sure it's private.  maybe you know differently though
[21:57] <mario_limonciell> well it's not been announced anywhere in the past
[21:57] <tseliot> mario_limonciell: we are the ones who signed an NDA, not Bryce
[21:58] <mario_limonciell> tseliot, it's not been announced to the beta list either
[21:59] <mario_limonciell> but I had thought there was a 3 way NDA via AMD/Canonical/Dell as well
[21:59] <mario_limonciell> anyhow though.  did they talk about xorg 1.5 support?  randr 1.2 is kinda useless without xorg 1.5 :)
[22:00] <bryce> heh, I'm saying no more without a go-ahead ;-)
[22:00] <tjaalton> works just fine from 1.3 onwards :)
[22:00] <bryce> but I've requested clarification on it
[22:00] <mario_limonciell> haha okay
[22:01] <bryce> have I ever mentioned how much I hate secrets?
[22:02] <tseliot> :-)
[22:02] <mario_limonciell> yeah i wish that they would publicly comment on this kind of stuff
[22:02] <mario_limonciell> what would you call the "contours" that are showing in this image: http://imagebin.org/22276 ?
[22:03] <bryce> banding
[22:03] <mario_limonciell> because that only happens with the 'ati' driver
[22:03] <mario_limonciell> not with the fglrx
[22:03] <bryce> yeah we used to have that in inkscape with gradient patterns
[22:03] <mario_limonciell> what causes it?
[22:04] <bryce> color interpolation bugs,
[22:04] <bryce> numerical issues in gradient printing code
[22:04] <bryce> btw, is that background a png or a svg?
[22:05] <mario_limonciell> its the default ubuntu one
[22:05] <bryce> ok so a png
[22:05] <mario_limonciell> this was a hardy install upgraded to intrepid (before fglrx broke)
[22:05] <bryce> see if you can reproduce it in inkscape - draw a circle and color it with a gradient
[22:09] <mario_limonciell> er well i crashed inkscape trying to fill it with a gradient :)
[22:09] <mario_limonciell> ill try again
[22:09] <bryce> could also try gimp
[22:10] <bryce> inkscape crashes are quite rare though; I'll bet backtracing that crash would give some handy info
[22:10] <mario_limonciell> yeah inkscape definitely does it too
[22:10] <mario_limonciell> i did it with a big red circle gradienting to white
[22:11] <mario_limonciell> theoretically linearly
[22:11] <bryce> ok, that rules out it being just a png issue then
[22:11] <mario_limonciell> i'll put all this info into a bug then
[22:12] <mario_limonciell> its in bug 243372 now
[22:12] <mario_limonciell> bah
[22:12] <mario_limonciell> okay it shouldnt be private :)
[22:13] <mario_limonciell> bug 243372
[23:16] <tjaalton> there, lrm-2.6.15 cleared and unsubscribed
[23:17] <tjaalton> ~45 bugs less to worry about
[23:18] <Awsoonn> thought you might be in here Bryce :)
[23:18] <Awsoonn>  bug #242990
[23:19] <Awsoonn> I can't tell if it is my monitors ghosting or if I really do see what he sees, but what say you an that bug?
[23:19] <bryce> looking
[23:19] <Awsoonn> domo
[23:20] <bryce> Awsoonn: does it make a difference if compiz is enabled/disabled?
[23:20] <Awsoonn> let me disable and see
[23:21] <Awsoonn> more noticeable when disabled
[23:22] <bryce> hmm, well without seeing a screenshot it sounds like https://bugs.launchpad.net/ubuntu/+bug/96991, but that should go away with compiz is disabled
[23:22] <Awsoonn> oh! here we go!
[23:22] <Awsoonn> I took a screenshot of it
[23:23] <Awsoonn> I can't believe that worked. :) let me attach it
[23:29] <Awsoonn> *posted*
[23:33] <bryce> hmm
[23:34] <Awsoonn> Is there somewhere that I should tell xorg to use vsync?
[23:36] <bryce> well, you can specify it in xorg.conf
[23:36] <bryce> what you might want to do is compare your monitor's documented rates against what's listed in Xorg.0.log to see if something's misdetected
[23:36] <bryce> or try swapping monitors, if that's easier
[23:37] <bryce> I notice in the Xorg.0.log there's some warnings about pipe-A issues, so you could setting that option (google launchpad for 'Pipe-A' quirk)
[23:37] <bryce> however that usually exhibits itself as a crash on lid close, not like this
[23:37] <bryce> I'd encourage you to post your Xorg.0.log, for comparison against the original reporter's
[23:38] <bryce> also, it couldn't hurt to test booting Intrepid alpha-1 or alpha-2 when it's out, just in case this issue's already fixed upstream
[23:39] <bryce> if it's a mis-detection of sync rate, you could also try the NoDDC option
[23:39] <Awsoonn> my Section "Monitor" contains nothing for a refresh rate, is that anything?
[23:39] <bryce> that just means you're letting xserver autodetect it
[23:39] <bryce> which works 99% of the time :-)
[23:40] <Awsoonn> Screen resolution settings window shows that it is set at..... 50Hz
[23:40] <bryce> oh, also another approach if you suspect modeline issues, is to try alternate resolutions and refresh rates
[23:41] <bryce> modeline bugs tend to be specific to one particular setting
[23:41] <Awsoonn> interesting that the nvidia settings tool says I'm at 60 Hz
[23:42] <bryce> you can also use 'ddcprobe' and 'get-edid | parse-edid' to check things
[23:42] <bryce> oh you're using nvidia?  the log shows intel...
[23:42] <bryce> yeah there's a known bug with -nvidia where it reports wrong refresh rates
[23:42] <Awsoonn> my montiors report 60Hz as well
[23:43] <Awsoonn> those logs are the OP's
[23:43] <bryce> nVidia knows about the bug (I think it's in their release note and/or faq), but I don't know of any plans they have to fix it
[23:44] <Awsoonn> so MY issue is nvidia, but his is something else you think?
[23:59] <bryce> it's quite possible
[23:59] <bryce> it's very typical for unrelated bugs to have similar symptoms
[23:59] <bryce> and this gets confusing especially when the symptoms are described in text, rather than screenshots