[12:07] <kylem> tepsipakki, looked over the xserver debdiff, looks good.
[12:08] <tepsipakki> thanks!
[12:09] <tepsipakki> it's not that big either
[12:09] <tepsipakki> but the xorg.debdiff is huge because of po/*
[12:11] <kylem> indeed.
[12:12] <tepsipakki> maybe I should filter that out to make reviewing easier..
[12:12] <kylem> s'ok, i can filterdiff
[12:12] <kylem> :)
[12:13] <tepsipakki> filterdiff.. now there's a tool I've missed
[12:13] <tepsipakki> and didn't know about :P
[12:13] <tepsipakki> sheesh
[12:15] <kylem> :)
[12:15] <kylem> makes life easy
[12:19] <tepsipakki> slightly, yes
[12:26] <kylem> will take me a while to look over xorg debdiff.
[12:27] <tepsipakki> of course
[12:31] <tepsipakki> put a new diff without the po-stuff
[12:31] <tepsipakki> for other potential reviewers
[12:33] <tepsipakki> but now it's time to hit the sack
[12:33] <tepsipakki> night and happy reviewing :)
=== cjwatson_ [n=cjwatson@82-69-40-219.dsl.in-addr.zen.co.uk]  has joined #ubuntu-x
[03:12] <kylem> xorg packages looks fine as well.
[05:21] <Ubugtu> New bug: #87245 in libx11 (main) "upgrade in libX11 causes azureus crash" [Undecided,Unconfirmed]  https://launchpad.net/bugs/87245
[06:36] <Ubugtu> New bug: #51991 in xorg (main) "Xorg process freezes, uses 100% of CPU. Can be killed by remote terminal." [Undecided,Confirmed]  https://launchpad.net/bugs/51991
[07:46] <tepsipakki> kylem: whoa, thanks!
=== mvo [n=egon@p54A65801.dip.t-dialin.net]  has joined #ubuntu-x
=== cjwatson [n=cjwatson@82-69-40-219.dsl.in-addr.zen.co.uk]  has joined #ubuntu-x
=== seb128 [n=seb128@ubuntu/member/seb128]  has joined #ubuntu-x
[10:13] <tepsipakki> hey seb128 
[10:13] <tepsipakki> kylem reviewed both xorg-server and xorg last night
[10:13] <seb128> hi
[10:13] <seb128> excellent
[10:14] <seb128> and what did he say? ready to go? did he upload?
[10:14] <tepsipakki> didn't upload, said they looked fine
[10:15] <seb128> ok, good
[10:16] <seb128> did you ask him to upload?
[10:16] <seb128> kylem: ping? (he's probably sleep atm)
[10:16] <tepsipakki> no, since I went to bed :)
[10:16] <seb128> k, I'll have an another look on the server and upload then
[10:16] <tepsipakki> I need to make a final version of xorg so it can be uploaded
[10:16] <jcristau> seb128: you can sync libxrandr from experimental again :)
[10:17] <tepsipakki> ah, indedd
[10:17] <tepsipakki> s/ed/ee/
[10:17] <tepsipakki> thogh pitti said that the new version wasn't on the mirror he syncs from
[10:17] <tepsipakki> and, we already have a version with the patch :) (or part of it)
[10:17] <jcristau> ah, ok
[10:18] <jcristau> I didn't know that
[10:18] <tepsipakki> it was uploaded last night
[10:18] <tepsipakki> by someone
[10:18] <jcristau> yeah, he sent a mail to debian-x too
[10:18] <seb128> jcristau: good
[10:19] <tepsipakki> seb128: where do you pull your syncs from?
[10:19] <seb128> tepsipakki: Debian
[10:20] <seb128> we might want to have at look at that libxrender patch: https://bugs.freedesktop.org/show_bug.cgi?id=9526
[10:20] <Ubugtu> Freedesktop bug 9526 in Lib/Xrender "Length field in create gradient requests is not set correctly" [Major,New]  
[10:20] <seb128> pointed by somebody working on compiz
[10:21] <tepsipakki> seb128: from ftp.debian.org?
[10:21] <tepsipakki> the new version is there, don't know where pitti looked
[11:07] <seb128> tepsipakki: 
[11:07] <seb128> ../../randr/randr.c: In function 'ProcRRQueryVersion':
[11:07] <seb128> ../../randr/randr.c:482: error: 'SERVER_RANDR_MAJOR' undeclared (first use in this function)
[11:07] <seb128> ../../randr/randr.c:482: error: (Each undeclared identifier is reported only once
[11:07] <seb128> ../../randr/randr.c:482: error: for each function it appears in.)
[11:07] <seb128> ../../randr/randr.c:483: error: 'SERVER_RANDR_MINOR' undeclared (first use in this function)
[11:07] <seb128> 
[11:07] <seb128> while trying to build the new xorg-server on my feisty desktop
[11:08] <jcristau> replace them with 1 and 1 :)
[11:08] <seb128> ?
[11:08] <seb128> should they be declared by libxrandr?
[11:09] <jcristau> no
[11:09] <jcristau> that's only in the server
[11:09] <seb128> tepsipakki: how come it built for you?
[11:09] <seb128> or you didn't try to build it? ;)
[11:31] <tepsipakki> hmm
[11:31] <tepsipakki> I'll check in a moment
[11:32] <tepsipakki> haha
[11:32] <tepsipakki> I suck
[11:33] <tepsipakki> I was being too clever with the patch
[11:34] <tepsipakki> ..which was copypasted from the damage-patch
[11:34] <tepsipakki> partly
[11:34] <tepsipakki> so SERVER_RANDR_{MAJOR,MINOR} were not declared, insted *DAMAGE* :)
[11:34] <seb128> you didn't even try to build the package then? ;)
[11:35] <Ubugtu> New bug: #44878 in linux-restricted-modules-2.6.15 (restricted) "firefox & epiphany restart gdm" [Medium,Unconfirmed]  https://launchpad.net/bugs/44878
[11:35] <tepsipakki> no, since that was the only change after my builds..
[11:35] <tepsipakki> I'll roll up a new one
[11:35] <seb128> ok, thank you
[11:38] <tepsipakki> it's there
[11:40] <seb128> tepsipakki: building
[11:44] <tepsipakki> it took 17min on my laptop
[11:56] <seb128> tepsipakki: updating the server alone is fine, right?
[11:56] <seb128> no need to update xorg in the same time?
[11:57] <tepsipakki> well, there is the fontpath issue
[11:58] <seb128> what fontpath?
[11:58] <tepsipakki> at least binary nvidia can't cope with the old config unless we provide a symlink to the new location
[11:58] <tepsipakki> and xorg has that (xserver-xorg)
[11:58] <seb128> oh, that's not good
[11:59] <tepsipakki>   * debian/xserver-xorg.links:
[11:59] <tepsipakki>     - ship a symlink "usr/share/X11/fonts -> usr/share/fonts/X11".
[11:59] <tepsipakki> I think the right place for it is in xorg
[11:59] <tepsipakki> so, maybe xorg should go _before_
[11:59] <seb128> can we get a minor revision update doing just that first?
[11:59] <seb128> then update the server
[11:59] <seb128> and then look at the xorg merge
[11:59] <tepsipakki> yes, that would be fine
=== pitti [n=pitti@ubuntu/member/pitti]  has joined #ubuntu-x
[12:00] <pitti> hi
[12:00] <seb128> hi pitti
[12:00] <seb128> <tepsipakki>   * debian/xserver-xorg.links:
[12:00] <seb128>      - ship a symlink "usr/share/X11/fonts -> usr/share/fonts/X11".
[12:00] <seb128>  I think the right place for it is in xorg
[12:00] <seb128>  so, maybe xorg should go _before_
[12:00] <seb128> 
[12:00] <seb128> we are discussing that
[12:01] <seb128> that symlinks needs to go before the server update
[12:01] <seb128> so
[12:01] <seb128> - either we upload xorg first and then the server
[12:01] <seb128> - or we do a minor xorg revision just for that symlink, then update the server and deal with the xorg then
[12:02] <seb128> any opinion?
[12:02] <pitti> seb128: if it is beneficial to test the new xorg-server without the new xorg, then a separate upload would indeed make sense
[12:02] <seb128> the 1st option might be the efficient one, I'm not that comfortable doing the xorg update though, that looks like the tricky part
[12:03] <pitti> seb128: but do you really think it is hard to tell apart bugs in xorg from those in the new server?
[12:03] <seb128> let me have a look at the xorg changes
[12:03] <pitti> ah, I see
[12:03] <seb128> I'm just scared by it
[12:03] <pitti> well, option 2 can't hurt
[12:03] <tepsipakki> actually xorg is tricky mostly for new installations or reconfigurations, shouldn't do much on updates AIUI
[12:04] <seb128> if somebody else is wanting to have an another look on xorg we can probably go forward and that one done
[12:04] <pitti> we should just make sure then that the new server conflicts to the older xorgs
[12:04] <tepsipakki> seb128: I'm just about to do -0ubuntu1 of it
[12:04] <seb128> tepsipakki: xorg?
[12:04] <tepsipakki> which only has a reorganized changelog
[12:04] <tepsipakki> yes
[12:04] <pitti> as I already said, I doubt that xorg can be verified just by eyeballing
[12:05] <pitti> maybe we should just do it ASAP and invest more time in testing the daily ISOs
[12:05] <seb128> should we just try it on a few boxes and go ahead then?
[12:05] <pitti> that might in fact make more sense
[12:05] <pitti> seb128: I'm happy to test an xorg upgrade right now; I just can't test a server upgrade, because I'm on ISDN
[12:05] <seb128> I would like to hear from cjwatson before going on with that one though
[12:06] <pitti> seb128: right, or Tollef as RM
[12:06] <seb128> pitti: ok, let's do that then
[12:06] <seb128> cjwatson: around?
[12:07] <pitti> seb128, tepsipakki: do we have a debdiff between current and new xorg somewhere?
[12:07] <tepsipakki> pitti: not yet, I'll generate one in a minute
[12:08] <cjwatson> seb128: yes - but from the sound of things, I'd say go for it; I'm not hearing anything that suggests we should be *particularly* concerned, nor that we couldn't fix it up after the fact
[12:08] <pitti> tepsipakki: I'm happy to eyeball that diff for any obvious things that jump on me; that's the one that will show us what changes
[12:09] <seb128> cjwatson: ok, so let's start with the xorg update, I'll test it and pitti is wanting to give it a try as well
[12:09] <seb128> kylem had a look as well
[12:09] <seb128> if there is no major problem let's upload it
[12:11] <tepsipakki> give me 5min to finalize the changelog :)
[12:16] <tepsipakki> hm, now I get gettext errors from debconf-updatepo
[12:16] <tepsipakki> while building the source
[12:17] <tepsipakki> this is a dapper box where I'm building it
[12:24] <cjwatson> you probably want to build on something more current, as the line numbers generated by po-debconf have changed since then, and you'll end up with a huge diff
[12:24] <cjwatson> (ideally, avoid running debconf-updatepo at all, though ...)
[12:25] <tepsipakki> yep, I'll copy it to a feisty box
[12:30] <tepsipakki> hrmh
[12:31] <tepsipakki> now it expects to find an .orig.tar.gz
[12:31] <tepsipakki> on feisty
[12:32] <tepsipakki> and gettext complains as on dapper
[12:32] <tepsipakki> /usr/bin/xgettext: warning: file `at' extension `' is unknown; will try C
[12:32] <tepsipakki> /usr/bin/xgettext: error while opening "at" for reading: No such file or directory
[12:53] <tepsipakki> thank god I had old version available..
[12:53] <tepsipakki> a rollback solved it
[12:56] <tepsipakki> ha
[12:56] <tepsipakki> changing the maintainer-fields is what broke it
[01:02] <tepsipakki> and if I put '@' instead of 'at' it stops complaining, how logical
[01:02] <tepsipakki> so, which is it, do I ignore the error or change the email address to a valid one
[01:02] <tepsipakki> ?
[01:04] <tepsipakki> I'll just ignore it for now
[01:06] <cjwatson> as in Maintainer vs. XSBC-Original-Maintainer in debian/control?
[01:07] <tepsipakki> yes, "ubuntu-devel-discuss at lists.ubuntu.com" doesn't work right
[01:07] <tepsipakki> xgettext doesn't like 'at'
[01:07] <cjwatson> you definitely mustn't spam-obfuscate Maintainer in debian/control.
[01:08] <cjwatson> yes, use @
[01:08] <tepsipakki> ok, it's just used already :)
[01:08] <tepsipakki> oh wait
[01:08] <tepsipakki> maybe I copied it from an email
[01:08] <tepsipakki> duh
[01:11] <tepsipakki> ok, new and hopefully final version of xorg now at the same place as usual
[01:11] <tepsipakki> with debdiffs
[01:12] <tepsipakki> against debian and current ubuntu
[01:15] <tepsipakki> I have a birthday party to attend to (on a ferry :), so I won't be around much longer..
[01:19] <tepsipakki> so if xorg/xorg-server are going to be pushed today, I won't be online to work on the bugs until Saturday evening
[01:19] <tepsipakki> not that there should be any, of course :)
[01:46] <seb128> tepsipakki: ok, thank you for your work, I'll have a look on xorg now and upload if it looks fine
[01:47] <tepsipakki> great, thanks!
[01:47] <tepsipakki> I'm off now ->
[01:47] <seb128> have fun
[01:47] <tepsipakki> I sure will ;)
[01:47] <seb128> I'll probably not do IRC during the WE but I read mails every now and then
[01:47] <seb128> feel free to drop a mail if anything should be fixed
[01:48] <tepsipakki> ok
[02:01] <seb128> tepsipakki: still around?
[02:02] <seb128> xserver-xorg Depends: xserver-xorg-core (>= 2:1.1.1-11)
[02:02] <seb128> +# versioned dependency on xserver-xorg-core needed because xserver-xorg
[02:02] <seb128> +# contains a symlink to the reportbug script shipped in that package starting
[02:02] <seb128> +# with 2:1.1.1-11
[02:02] <seb128> 
[02:02] <seb128> that can probably be relaxed
=== mvo_ [n=egon@p54A64C2D.dip.t-dialin.net]  has joined #ubuntu-x
[03:32] <cjwatson> seb128: oh, there's one other bug fix I'd like to slot into xorg, if I have time
[03:32] <cjwatson> just a keyboard map thing
[03:33] <seb128> cjwatson: sure
[03:33] <seb128> I've just installed the xorg update on my desktop (without type-handling)
[03:33] <seb128> I'll do some testing with it now and then ask to pitti and other guys who wants to give it a try before upload
[03:34] <seb128> let me know if you have a patch, I'll update my build (which is on http://people.ubuntu.com/~seb128/xorg) with it
[03:35] <cjwatson> seb128: http://paste.ubuntu-nl.org/7210/
[03:36] <cjwatson> I've a corresponding console-setup update on my disk, but it's not critical that they match up exactly
[03:36] <kylem> how close are we to drivers? i can pretty easily review a few of those.
[03:37] <seb128> kylem: drivers for next week probably
[03:37] <kylem> ok.
[03:37] <seb128> we are very close for xorg
[03:37] <seb128> maybe server today
[03:38] <kylem> (i have a selfish interest, -i810 isn't working horribly well on my crestline, need newer drivers.)
[03:38] <seb128> you can probably start on driver after the server update if you want
[03:38] <kylem> ok.
[03:38] <seb128> kylem: how much did you review xorg and xorg-server yesterday?
[03:39] <kylem> i looked over the debdiff rather thoroughly (i thought) but i didn't get an opportunity to test them. can do that this morning if you'd like
[03:40] <seb128> testing is welcome
[03:41] <seb128> http://people.ubuntu.com/~seb128/xorg
[03:41] <seb128> xorg upload candidate, source and i386 binaries
[03:42] <seb128> if you want to give it a try
[03:42] <kylem> ok, i'll have to rebuild for amd64.
[03:42] <kylem> i'll kick that off in a few mins.
[03:42] <seb128> it's like 40 seconds to build
[03:42] <kylem> hehe.
[03:43] <cjwatson> the hardest test will be whether the installer still works :)
[03:43] <seb128> right
[03:43] <cjwatson> but it's too painful to try to test that before upload with something this size
[03:44] <seb128> brb, trying the update
=== seb128 [n=seb128@ubuntu/member/seb128]  has joined #ubuntu-x
[04:03] <seb128> ok, looks like the update doesn't break the world on update
[04:03] <seb128> somebody else wants to test the update?
[04:10] <Ubugtu> New bug: #21817 in xorg-server (main) "xnest: can't type control characters in Xnest clients" [Low,Unconfirmed]  https://launchpad.net/bugs/21817
[04:29] <seb128> ok
[04:29] <seb128> xorg update works fine for me and dholbach and not real reason to break upgrades and we can sort new install when people send bugs about them
[04:30] <seb128> anybody has a reason to not upload it? otherwise I'll do that now ;)
[04:37] <seb128> ok, uploading
[04:44] <seb128> hum
[04:44] <seb128> the xorg-server update is weird
[04:45] <seb128> there is a bunch of binaries like scanpci not installed to any deb
[04:47] <Ubugtu> New bug: #87244 in xorg (main) "ati driver crashes X on MacBook Pro" [Undecided,Needs info]  https://launchpad.net/bugs/87244
[06:00] <Ubugtu> New bug: #38939 in xorg (main) "MPlayer receives BadAlloc when playing very large movies using Xv" [Medium,Confirmed]  https://launchpad.net/bugs/38939
[06:00] <Ubugtu> New bug: #49360 in xserver-xorg-video-i810 (main) "BadAlloc error when playing a video with xv" [Low,Confirmed]  https://launchpad.net/bugs/49360
[06:00] <Ubugtu> New bug: #52490 in xorg (main) "Xorg can't handle large XV buffers  (badalloc) (dup-of: 49360)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/52490
[06:00] <Ubugtu> New bug: #86340 in mplayer (multiverse) "Mplayer crash when opening a file (dup-of: 49360)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/86340
=== dholbach [n=daniel@ubuntu/member/dholbach]  has joined #ubuntu-x
[06:28] <dholbach> hey guys
[06:29] <dholbach> <dholbach> seb128: no xorg, does not load /usr/lib/xorg/modules/libint10.so
[06:29] <dholbach>  "no screens"
[06:29] <dholbach> dholbach it also complained about wacom and dri, so I disabled those, but still no love
[06:29] <seb128> hi dholbach
[06:29] <dholbach> does the new xorg-server work for all of you?
[06:30] <dholbach> i can try on my amd64 too
=== dholbach prepares for the worst ;)
[06:31] <seb128> I'm going to try it now, brb
[06:32] <dholbach> strange
[06:32] <dholbach> the amd64 (with nvidia) is happy
=== pochu [n=pochu@38.Red-88-7-170.staticIP.rima-tde.net]  has joined #ubuntu-x
=== seb128 [n=seb128@ubuntu/member/seb128]  has joined #ubuntu-x
[06:42] <dholbach> hey seb128
[06:42] <dholbach> how did it go?
[06:44] <seb128> not really good
[06:44] <seb128> xorg starts
[06:44] <seb128> compiz says there is no composite extension though
[06:44] <seb128> and with standard GNOME switching windows take like 10 seconds
[06:44] <seb128> with xorg using 99% CPU
[06:45] <dholbach> urg, so you get that bug now too :-/
[06:46] <seb128> "too"? I thought it was not starting for you
[06:47] <dholbach> yeah, but pitti and mvo had the "takes like 10 seconds" problem
[06:47] <seb128> ho
[06:47] <seb128> that's not an update bug then?
[06:47] <seb128> hum
[06:47] <seb128> how did they fix it?
[06:47] <dholbach> I think they both used nvidia instead of nv
[06:47] <dholbach> but there was also slomo having problems
[06:48] <dholbach> and I think glatzor too
[06:48] <seb128> I'm using ati
[06:48] <dholbach> but I might be mistaken
[06:48] <dholbach> i remember somebody complained about other drivers too
[06:48] <seb128> nice to see that somebody tried to report or fix the problem :p
[06:48] <dholbach> :-/
[06:49] <dholbach> do you need any other info for that i810 does not start problem?
[06:49] <dholbach> anything I could try to make it work?
[06:49] <seb128> (II) Loading /usr/lib/xorg/modules//libint10.so
[06:49] <seb128> dlopen: /usr/lib/xorg/modules//libint10.so: undefined symbol: Int10Current
[06:49] <seb128> (EE) Failed to load /usr/lib/xorg/modules//libint10.so
[06:49] <seb128> dholbach: not really, I just know now than the server is no-go today
[06:50] <dholbach> alright
[06:50] <dholbach> that's the message I get too
[06:50] <seb128> the libint10 is not what breaks it though
[06:50] <seb128> yeah, but it starts for me
[06:50] <dholbach> weird
[06:50] <seb128>  you copy you /var/log/Xorg.0.log on p.u.c/~dholbach?
[06:50] <seb128> in case somebody wants to look at it
[06:52] <dholbach> http://daniel.holba.ch/temp/Xorg.{,2}0.log.old
[07:00] <seb128> 96.43% of the time spent to memcpy according to sysprof
[07:00] <dholbach> weird
[07:01] <seb128> called by exaCopyDirtyToSys called by exaMoveOutPixmap
[07:01] <seb128> looks like an EXA problem, I'll try without it
[07:03] <seb128> brb
=== seb128 [n=seb128@ubuntu/member/seb128]  has joined #ubuntu-x
[07:04] <seb128> ok
[07:04] <seb128> iz EXA bog
[07:04] <seb128> works fine without it
[07:04] <dholbach> what is EXA?
[07:04] <dholbach> apart from buggy? :)
[07:05] <seb128> and option for the ati driver, I used it because without it compiz had that refreshing problem
[07:06] <dholbach> hopefully the driver updates will fix that
[07:06] <seb128> http://en.wikipedia.org/wiki/EXA
[07:07] <dholbach> aha
[07:10] <Ubugtu> New bug: #87351 in xorg (main) "Xorg uses 100% CPU" [Undecided,Unconfirmed]  https://launchpad.net/bugs/87351
[07:12] <dholbach> interesting did we ever ship a kernel named 2.6.18.2?
[07:16] <seb128> dholbach: no
[07:16] <dholbach> what I thought - suspicious ;)
[07:22] <seb128> where did you read about that?
[07:22] <dholbach> in the bug report that Ubugtu mentioned
[08:21] <seb128> I call it a week, see you on monday
[08:28] <pochu> dholbach: aren't you going to reject that bug?
[08:28] <pochu> hello :)
[08:28] <dholbach> hi pochu
[08:28] <dholbach> no, it still might be valid
[08:28] <dholbach> even if he compiled his own kernel
[08:28] <pochu> oh, ok
[08:28] <pochu> I say it because we reject bugs when the user is running beryl :)
[08:29] <pochu> even if the crash isn't in beryl...
[08:29] <dholbach> right
[08:29] <pochu> dholbach: just a little question if you know it: about the current policy, when rejecting a bug, should I also change its importance field, or, as I'm rejecting it, I shouldn't?
[08:30] <dholbach> it doesn't really matter
[08:30] <dholbach> you can do as you like
[08:30] <pochu> dholbach: ok, ty!
[08:41] <Ubugtu> New bug: #87385 in xorg (main) "xserver-xorg-7.2-0ubuntu1 upgrade causes apps to hang in fontconfig" [Undecided,Unconfirmed]  https://launchpad.net/bugs/87385
[08:42] <pochu>  Topic: Ubuntu X Development channel only | bug report to LP or ban | request for help in #ubuntu or ban | please drive trough if you are not dealing to help. No we are not nice people here
[08:42] <pochu> lol
[08:43] <pochu> nice topic :D
[08:50] <Ubugtu> New bug: #87390 in libx11 (main) "c->xlib.lock" [Undecided,Unconfirmed]  https://launchpad.net/bugs/87390
[09:55] <Ubugtu> New bug: #87384 in xorg (main) "3d acceleration does not work on ATI Mobility 9000" [Undecided,Unconfirmed]  https://launchpad.net/bugs/87384
=== seb128 [n=seb128@ubuntu/member/seb128]  has joined #ubuntu-x