[00:02] <Sarvatt> sorry, didnt read the full bug and thought you were the person still having a problem with it :D
[00:03] <Sarvatt> well thats new, gdm didnt start and dropped me to a login prompt at boot but i got a message that it terminated with exit status 1 this time
[00:03] <Sarvatt> usually just silently drops me to login most boots
[00:03] <Sarvatt> no logs of course
[00:10] <bryyce> hrm
[00:11] <bryyce> used to be it'd at least left an error msg in the gdm log file
[00:11] <bryyce> does it not do this anymore?
[00:13] <tjaalton> mine didn't get that far
[00:13] <bryyce> xterm merged
[00:16] <Sarvatt> it touches the /var/log/gdm/:0.log but doesnt update it at all
[00:16] <Sarvatt> the timestamp is right but the contents are from last boot
[00:16] <Sarvatt> *when it happens
[00:20] <slangasek> Sarvatt: g-p-m is configured to 'blank screen' (i.e., 'lock screen'0
[00:20] <bryyce> heh go figure, I have three test machines, and at the moment none of the 3 are booting
[00:20] <bryyce> * and I don't remember why
[00:21] <bryyce> * and vt switching is not working on any of them
[00:22] <Sarvatt> there was a nasty bug for awhile where dpms off would crash intel with multiple screens and dpms off was getting called in some tricky places, changing those options fixed it for some people back then
[00:22] <tjaalton> bryyce: if they use kms it's because of failsafe the vt change doesn't work
[00:23] <bryyce> well I likely was testing kms on them
[00:23] <Sarvatt> i still have wacky vt switching, alt+fkey works but control+alt+fkey doesnt work to go back to X from a vt
[00:23] <bryyce> but that was back before holidays
[00:23] <bryyce> so they've not been updated in a while, maybe I ought to do fresh reinstalls
[00:23] <bryyce> hm one boots it just shows nothing on the screen
[00:24] <slangasek> "back before holidays" - so gdm was even more likely to fail on boot-up then :)
[00:24] <bryyce> indeed
[00:25] <bryyce> in fact, debugging that problem was the last time I remember having all three systems in use
[00:26] <Sarvatt> yeah no fedora patch to -nv to work on G80+ of course because they use nouveau for that, and thats the only place mvo's patches are fixing I think
[00:27] <tjaalton> Sarvatt: the patch for the server?
[00:31] <bryyce> aha sure enough
[00:33] <Sarvatt> yeah, -nv just had a fix that stopped the crash on boot but still had the color problems and isnt supposed to work on 1.7 yet, went looking at fedora cvs to see if they were patching it but then i saw it was only a problem on G80 and newer and of course they didnt patch it because they use nouveau :D
[00:33] <tjaalton> Sarvatt: that one is from upstream .16
[00:33] <Sarvatt> yeah
[00:33] <tjaalton> and only the xserver patch was enough to make it work
[00:33] <tjaalton> but no reason to drop the -nv one since it's upstream anyway
[00:34] <Sarvatt> the xserver patch doesnt work with nv .16, that commit  breaks it
[00:34] <tjaalton> so mandriva ships a forked -sis with a 1,4MB patch on top of it, and calls the result sisimedia
[00:35] <Sarvatt> yeah I have sis in one of my servers I messed around with that on
[00:35] <tjaalton> too bad that it's the only driver supporting 671/771 chips
[00:35] <Sarvatt> some sis employee leaked an internal blob
[00:35] <bryyce> heh
[00:35] <tjaalton> it's not a blob, but a diff
[00:35] <Sarvatt> i couldnt even get it working with xserver 1.6 though :(
[00:36] <Sarvatt> they leaked it as a blob i mean, was blob only for years
[00:36] <tjaalton> ok
[00:37] <Sarvatt> intrepid was the last release i could use it under
[00:37] <Sarvatt> http://ncc-1701a.homelinux.net/~linux-sis/index.php?page=FrontPage
[00:37] <Sarvatt> backstory on it there
[00:37] <tjaalton> woohoo, we are again under 2800 bugs
[00:38] <bryyce> seriously?
[00:39] <tjaalton> yes, filed some dupes
[00:39] <bryyce> oh, I read the 8 as a 0
[00:39] <tjaalton> Sarvatt: uh, what a mess
[00:39] <tjaalton> bryyce: hah, in your dreams :)
[00:39] <bryyce> yeah saw you've been busy in the tracker timo :-)
[00:39] <tjaalton> a drop in the ocean though
[00:39] <bryyce> tjaalton, yeah I gotta bump up the y-axis on my graphs again :-(
[00:39] <bryyce> tjaalton, I just closed half the xterm bug reports :-)
[00:40] <tjaalton> hehe, I noticed that the total count went down ~25 bugs
[00:41] <bryyce> well I can claim responsibility only for maybe 7 ;-)
[00:41] <tjaalton> there were several dupes about that sis chip
[00:42] <tjaalton> 25 bugs is almost 1%
[00:42] <bryyce> tjaalton, btw, I dunno if I mentioned this but I set up a new report at http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/high-karma-bugs.html
[00:42] <bryyce> it shows bugs reported by people with over 10k karma
[00:42] <Sarvatt> oh its the 3D driver that was the blob
[00:42] <tjaalton> ooh, so few
[00:44] <JontheEchidna> hi, any clue what would cause the following? http://launchpadlibrarian.net/37629930/buildlog_ubuntu-lucid-i386.kdebase-workspace_4:4.3.90-0ubuntu1_FAILEDTOBUILD.txt.gz
[00:44] <JontheEchidna> (it built fine in pbuilder yesterday)
[00:44] <bryyce> JontheEchidna, wrong channel, this is just for X.org packaging discussion
[00:44] <tjaalton> make[3]: *** No rule to make target `/usr/lib/libGL.so', needed by `lib/libkwineffects.so.1.0.0'.  Stop.
[00:44] <JontheEchidna> well, it seems to be an X related failure :)
[00:44] <tjaalton> likely due to the mesa change
[00:45] <bryyce> tjaalton, yeah I have been thinking that looking at *all* bugs is too overwhelming, so looking to slice out saner subsets to focus on more realistic goals
[00:49] <JontheEchidna> looks like there's a new mesa waiting to be built
[00:49] <tjaalton> JontheEchidna: that doesn't change anything
[00:49] <JontheEchidna> ah, right: https://edge.launchpad.net/ubuntu/+source/mesa/7.6.1~rc3-1ubuntu2
[00:49] <tjaalton> maybe gl.pc needs to be changed
[00:49] <tjaalton> libdir=/usr/lib
[00:49] <tjaalton> while it's /usr/lib/mesa now..
[01:01] <tjaalton> oh well, anything build-depending on libgl1-mesa-dev fails to build now
[01:01] <tjaalton> including the xserver
[01:01] <tjaalton> because /usr/lib/libGL.so points nowhere
[01:01] <bryyce> bugger
[01:02] <Sarvatt> well good news and bad news and more bad news
[01:02] <Sarvatt> execbuff while wedged after about an hour uptime with a newer intel :(
[01:03] <Sarvatt> gl is all kinds of messed up right now until mesa gets published
[01:03] <Sarvatt> but I think I found why intel isnt booting into gdm
[01:04] <Sarvatt> i moved /lib/udev/rules.d/40-xserver-xorg-video-intel.rules out of the way and it booted into my desk 6 times in a row
[01:04] <Sarvatt> desktop*
[01:05] <bryyce> what's in that file?
[01:05] <Sarvatt> DRIVER=="i915, "ACTION=="change", ENV{ERROR}==1, PROGRAM="/usr/share/apport/apport-gpu-error-intel.py"
[01:05] <bryyce> aha yes
[01:05] <bryyce> ooh maybe this will explain why that's not been working
[01:06] <Sarvatt> i dont even have that file
[01:06] <bryyce> I thought that file sounded familiar :-)
[01:06] <bryyce> hmm, neither do I
[01:06] <bryyce> however my intel box is booting ok
[01:07] <bryyce> that file should be provided by xserver-xorg-video-intel
[01:08] <tjaalton> I do
[01:08] <bryyce> debian/rules has the command to install it
[01:08] <bryyce> rules:	install -m 755 debian/apport-gpu-error-intel.py $(CURDIR)/debian/tmp/usr/share/apport
[01:09] <tjaalton> oh the apport file
[01:09] <tjaalton> don't have that one
[01:09] <bryyce> how about /usr/bin/intel_reg_dumper ?
[01:10] <bryyce> I'm missing that as well
[01:10] <tjaalton> intel-dbg installs that one
[01:11] <bryyce> perhaps the apport script just needs added to xserver-xorg-video-intel.install?
[01:12] <bryyce> I suppose if we do this then intel_reg_dumper ought to move into that as well
[01:12] <tjaalton> yeah
[01:12] <Sarvatt> that python script should be installed with intel-gpu-tools shouldnt it? it calls intel_gpu_dump from that package
[01:12] <bryyce> yeah they definitely go together
[01:13] <bryyce> what do you guys think, should they be in the -dbg or the normal package?
[01:15] <tjaalton> -dbg is not on a stock install
[01:15] <tjaalton> while -intel and i-g-t are
[01:15] <Sarvatt> wish intel_gpu_dump was always installed for intel since its doesnt gain anything from being in the dbg package
[01:16] <bryyce> I tend to agree
[01:16] <tjaalton> it's in i-g-t, not -dbg
[01:16] <bryyce> ok, I'll add to my todo list to fix this up and move the dump tool into the regular package
[01:17] <tjaalton> it's installed already, by intel-gpu-tools
[01:17] <bryyce> what's i-g-t?
[01:17] <tjaalton> -dbg has intel_reg_dumper
[01:17] <bryyce> oh right, this got split out
[01:17] <Sarvatt> i mean intel_gpu_dump doesnt need anything from -dbg, and moving the apport script to dbg wouldnt get much use
[01:17] <Sarvatt> in intel 2.10 reg_dumper is in i-g-t now too yeah
[01:18] <tjaalton> hmm? they are separate sources
[01:18] <bryyce> yeah
[01:18] <tjaalton> or do you mean 2.10 dropped reg_dumper?
[01:18] <Sarvatt> wonder why that udev rule is dropping me to a login prompt on boot most times though if thats what it is, would be interested if it fixes it for you tjaalton
[01:19] <bryyce> so make the driver depend on i-g-t now, and then put the apport script into the base .install?
[01:19] <Sarvatt> yeah 2.10 dropped intel_reg_dumper from the intel source
[01:19] <tjaalton> bryyce: it already Recommends it
[01:19] <bryyce> tjaalton, ok great
[01:19] <tjaalton> Sarvatt: so gpu_dump replaces it?
[01:20] <tjaalton> no wait
[01:20] <tjaalton> it's in i-g-t now
[01:20] <Sarvatt> yep
[01:21] <tjaalton> but master, not 1.0.2
[01:21] <Sarvatt> we'll need to change i-g-t to install it whenever we update intel
[01:21] <Sarvatt> hmm thought it moved to i-g-t in the one we have and just wasnt getting installed last i checked
[01:22] <Sarvatt> nope!
[01:22] <Sarvatt> not in tools/
[01:22] <tjaalton> the commit was right after the tag
[01:24] <tjaalton> hmm, mesa glx libdir is /usr/lib/glx, but nothing gets installed there
[01:26] <tjaalton> changing it to /usr/lib/mesa seems to have helped somewhat
[01:26] <tjaalton> but gl.pc didn't change
[01:26] <tjaalton> oh well, too late anyway
[01:32] <Sarvatt> wonder how much longer mesa is going to take to go out, takes about 45 minutes to build on this thing but I'd like GL back :D
[01:33] <Sarvatt> compiz starts up and takes control as window manager but doesn't work right now
[01:33] <Sarvatt> had to vt switch and DISPLAY=:0 metacity --replace
[01:33] <bryyce> usually takes a couple hours plus or minus a bit
[01:44] <Sarvatt> maybe libgl1-mesa-swx11 should be updated for /usr/lib/mesa as well?
[01:52] <Sarvatt> looks like mandriva has hit some bugs with the setup we're moving to where some binaries had RPATH hardcoded
[01:54] <Sarvatt> http://lists.freedesktop.org/archives/compiz/2008-March/003067.html
[02:39] <bryyce> x11-xserver-utils merged
[02:55] <ScottK> Is anyone looking into the current mesa breakage?
[02:55] <superm1> w/ tseliot's new stuff?
[03:12] <Sarvatt> it's just broken until its published
[03:13] <ScottK> So 7.7-0ubuntu1 is the fix?
[03:13] <Sarvatt> yeah
[03:13] <ScottK> OK.  That's not so bad.
[03:30] <Sarvatt> still 30 minutes till amd64 even starts to build :(
[03:31] <ScottK> Probably worth trying to poke a buildd admin to rescore it.
[03:42] <Sarvatt> hmm didnt we used to not build libgl1-mesa-swx11-i686 with mesa?
[03:52] <bryyce> libgl1-mesa-glx-i686 was commented out, is that what you were thinking of?
[03:53] <bryyce> or libgl1-mesa-dri-i686, that's commented out too
[04:04] <Sarvatt> yeah must be thinking of those, packages.ubuntu.com says I'm really wrong :)
[04:21] <Sarvatt> just noticed the intel packaging i do on edgers doesn't have that udev rule in it, but i still had the udev rule hanging around from the ubuntu one
[04:30] <Sarvatt> oops, didn't think about how I cant use origin/ubuntu for karmic anymore and almost uploaded a new mesa :D
[04:36] <JontheEchidna> builds still fail with latest mesa: http://launchpadlibrarian.net/37635550/buildlog_ubuntu-lucid-i386.kdebase-runtime_4:4.3.90-0ubuntu2_FAILEDTOBUILD.txt.
[04:46] <Sarvatt> ScottK: I'm sorry, by "breakage" I didn't know you meant this build breakage, gl was broken everywhere for a few hours there if someone updated in the middle (like I did)
[05:51] <ScottK> Sarvatt: OK, so waht's the solution?
[07:36] <tjaalton> Sarvatt: 7.7 is _not_ the solution
[08:04] <tjaalton> tseliot: hey, the mesa change breaks any build that needs /usr/lib/libGL.so (or gl.pc)
[08:08] <tseliot> tjaalton: ???
[08:08] <tseliot> ldconfig should know where libGL.so* is
[08:09] <tjaalton> but libGL.so points nowhere
[08:10] <tseliot> let me check
[08:10] <tjaalton> 06:36 < JontheEchidna> builds still fail with latest mesa:
[08:10] <tjaalton> http://launchpadlibrarian.net/37635550/buildlog_ubuntu-lucid-i386.kdebase-runtime_4:4.3.90-0ubuntu2_FAILEDTOBUILD.txt.
[08:12] <tseliot> the link appears to be brokeni
[08:12] <tseliot> broken
[08:12] <tjaalton> yes, because libdir wasn't changed
[08:12] <tjaalton> but that's not enough
[08:13] <tseliot> no, I mean the URL
[08:13] <tjaalton> and I said the reason for that
[08:15]  * tseliot slept less than 5 hours
[08:16] <tseliot> tjaalton: there's no trace of libGL.so here, only libGL.so.1
[08:17] <tjaalton> libgl1-mesa-glx-dev
[08:17] <alkisg> Hi, are the proprietary nvidia drivers currently working for Lucid? I see 185 in jockey, should I go ahead and install it? I have 8600M GT.
[08:17] <tjaalton> anything that build-depends on that will fail
[08:17] <tjaalton> or mesa-common-dev, which has the gl.pc
[08:17] <tjaalton> testing the mesa build again..
[08:18] <tseliot> tjaalton: so it's just a matter of adding a link, right?
[08:18] <tseliot> in /usr/lib/mesa
[08:18] <tseliot> libGL.so -> libGL.so.1
[08:19] <tjaalton> no links, fixing the config options
[08:20] <tjaalton> +but rather
[08:26]  * alkisg tries to install the 185 drivers...
[08:27] <tseliot> alkisg: no, 185 won't work
[08:27] <tseliot> nvidia-current should
[08:27] <tseliot> and please don't use jockey. It doesn't support the new drivers yet
[08:30] <alkisg> tseliot, I don't see nvidia-current in synaptic... /me googles...
[08:31] <tjaalton> your mirror doesn't have it yet
[08:31] <tseliot> alkisg: then I guess you'll have to wait until your mirror gets it
[08:31] <alkisg> tseliot: ah, thank you, that's it (I'm in Greece)
[08:31] <alkisg> (and tjaalton :))
[08:31] <tseliot> tjaalton: $(LIB_DIR) is what we need to set, right?
[08:33] <tjaalton> tseliot: well, --libdir
[08:35] <tjaalton> but setting that would install gl{,u}.pc in /usr/lib/mesa/pkgconfig, which is wrong
[08:42] <tjaalton> that can be fixed in *.install
[08:44] <tjaalton> but practically, everything libGL* needs to be moved to /usr/lib/mesa
[08:44] <tseliot> tjaalton: libgl1-mesa-dev.install
[08:44] <tjaalton> so the changes are not that small in the end
[08:45] <tjaalton> wonder how many places hardcode /usr/lib/libGL*
[08:45] <tjaalton> in proprietary apps etc
[08:45] <tseliot> they can call dlopen() but the Mandriva developer told me that it works
[08:45] <tjaalton> tseliot: libgl*.install
[08:45] <tjaalton> but they don't install these in a subdir, right?
[08:46] <tjaalton> so we are deviating from them
[08:48] <tseliot> tjaalton: they will install libGL* in a subdir. It's only by chance that things work there
[08:48] <tseliot> as they didn't enable tls
[08:50] <tjaalton> http://pastebin.ubuntu.com/353841
[08:51]  * tseliot reads the diff
[08:53] <tseliot> tjaalton: it looks good
[09:12] <tjaalton> tseliot: what package installs the ld.so.conf.d/gl.conf or what's that called?
[09:14] <tseliot> tjaalton: the xserver installs the /usr/lib/standard-x11/ld.so.conf
[09:14] <tjaalton> no I mean the one with the libGL path
[09:14] <tseliot> and /etc/ld.so.conf.d/GL.conf points to it
[09:15] <tseliot> tjaalton: ldconfig reads /etc/ld.so.conf.d/GL.conf and knows where to find libGL.so
[09:16] <tjaalton> ok
[09:16] <tseliot> when you switch to nvidia, GL.conf points to a different conf file which tells ldconfig where it can find the nvidia libGL stuff
[09:26] <tjaalton> xserver build still failed
[09:26] <tjaalton> dpkg-shlibdeps: error: couldn't find library libGL.so.1 needed by debian/xserver-xephyr/usr/bin/Xephyr (ELF format: 'elf32-i386'; RPATH: '').
[09:29] <tseliot> tjaalton: did you do an ldconfig?
[09:29] <tseliot> or is it still a matter of .pc files?
[09:31] <tseliot> as I assume that you're testing locally
[09:31] <tjaalton> I would've thought installing the packages ran ldconfig
[09:32] <tseliot> tjaalton: yes, but what packages are we talking about?
[09:32] <tjaalton> the mesa ones
[09:32] <tseliot> X and nvidia do it
[09:32] <tjaalton> built locally, installed them and built xserver
[09:32] <tseliot> maybe should call ldconfig in mesa too
[09:32] <tseliot> we should
[09:32] <tjaalton> though I didn't have the newer xserver
[09:33] <tseliot> tjaalton: what does ldconfig --print | grep GL say?
[09:34] <tjaalton> installing the xserver didn't run ldconfig
[09:34] <tjaalton> I have libGL now that I ran ldconfig manually
[09:34] <tseliot> aah
[09:36] <tjaalton> so the xserver build should pass now
[09:36] <tseliot> hopefully ;)
[09:36] <tseliot> BTW thanks for working on this
[09:36] <tjaalton> np
[09:46] <Duke`> I wonder why on my lucid box, when I boot Xorg fails, but when I just restart gdm service, it works well.
[09:47] <knittl> good morning
[09:47] <tseliot> my X seems to make the system freeze...
[09:48] <tseliot> Duke`: that might be a racing problem between KMS and gdm
[09:55] <tjaalton> I can't get dri working
[09:55] <tjaalton> anymore
[09:56] <tseliot> tjaalton: was it really necessary to change --libdir for confflags-dri ?
[09:56] <knittl> so, i want to give nvidia drivers another try
[09:56] <knittl> i purged nvidia* yesterday
[09:56] <tjaalton> tseliot: yes, that's where libGL is built
[09:57] <knittl> what do i need to install for jockey to work?
[09:57] <tseliot> knittl: you can't right now. I haven't uploaded the new jockey yet
[09:57] <knittl> tseliot: ok, so i'll wait
[09:58] <knittl> but i could install the necessary packages anyway
[09:58] <knittl> nvidia-common i think it was
[09:58] <tseliot> tjaalton: can you show me the X log and the output of update-alternatives --display gl_conf please?
[09:59] <tseliot> knittl: I haven't uploaded the new nvidia-common either
[09:59] <knittl> ok, then i wait :D
[09:59] <tseliot> knittl: if you need to install the latest driver, this should work:
[09:59] <tseliot> install nvidia-current and then type sudo nvidia-xconfig
[10:00] <knittl> i thought this will not work because of update-alternatives-something jockey does behind the scenes
[10:00] <knittl> at least i remember bugabandoo saying something about it
[10:01] <tseliot> knittl: yes as alternatives work in automatic mode without it. And in automatic mode the latest nvidia driver always wins
[10:01] <tseliot> if you want to install -173 or -96 some manual configuration is required
[10:01] <knittl> i have a quadro fx 360m here, it uses the latest driver
[10:02] <tseliot> ok then
[10:05] <tjaalton> tseliot: that looks normal
[10:06] <tjaalton> and the x log shows that dri is fine
[10:07] <tseliot> tjaalton: what does the other command say?
[10:09] <tseliot> did you upload something that could break evdev recently?
[10:09] <tseliot> it seems to segfault here
[10:11] <tjaalton> no
[10:11] <tjaalton> what hw?
[10:11] <tseliot> radeon
[10:11] <tjaalton> I mean input hw
[10:11] <tseliot> a usb keyboard
[10:11] <tseliot> and a usb mouse
[10:11] <tjaalton> put the logfile somewhere
[10:12] <tseliot> I wish I could enter Recovery mode again
[10:12] <tseliot> or even ssh into my testing box
[10:12] <tseliot> :-/
[10:12] <tjaalton> how do you know it's evdev then?
[10:12] <tseliot> I managed to boot in Recovery mode before
[10:13] <tjaalton> kms ftw
[10:13] <tjaalton> +vesa
[10:13] <tseliot> now grub starts and ignores my keyboard (i.e. doesn't offer me a menu)
[10:14] <tseliot> shall I use fbdev if/when I can?
[10:14] <tjaalton> there's a bug open about that
[10:14] <tjaalton> fbdev failsafe with kms
[10:15] <tjaalton> so no dri with the mesa changes
[10:15] <tjaalton> and I don't really have time for this :)
[10:15] <tseliot> tjaalton: you didn't give me the output of that command though
[10:15] <geser> Hi, is it expected that libgl1-mesa-glx in lucid puts their libs in /usr/lib/mesa? as this leaves libgl1-mesa-dev with a broken /usr/lib/libGL.so link
[10:15] <tjaalton> alternatives? I said it looked ok
[10:16] <tseliot> tjaalton: and what do you mean by no dri, exactly?
[10:16] <tjaalton> not completely true though, glxgears seems to be accelerated
[10:17] <tseliot> geser: tjaalton wrote a fix for that. But yes, the change is intended
[10:18] <geser> so only the -dev package is currently broken?
[10:18] <tseliot> tjaalton: are you referring to glxinfo |grep direct?
[10:18] <tjaalton> tseliot: yes
[10:18] <tjaalton> and the logfile says DRI is on
[10:19] <tseliot> tjaalton: anything interesting in dmesg?
[10:19] <tjaalton> no
[10:23] <tseliot> tjaalton: did dri work before your last change?
[10:23] <tjaalton> it works with stock packages
[10:24] <superm1> tjaalton, how founded is your worry about apps hardcoding to /usr/lib/libGL.so.1 (do you have examples?)?
[10:25] <tjaalton> superm1: none
[10:27] <tseliot> tjaalton: stock being 7.7-1ubuntu1 ?
[10:27] <tjaalton> the one from the archive
[10:27] <tseliot> ok
[10:27] <tjaalton> tried a dist-upgrade and stuff works then
[10:28] <superm1> tseliot, i dont think you can recommend people install from the archive still even before jockey stuff is in place, nvidia-current is still in NEW: https://edge.launchpad.net/ubuntu/lucid/+queue
[10:32] <tjaalton> tseliot: I don't know, feel free to mess with the links, I've spent too much time on this already
[10:32] <tseliot> tjaalton: ok
[10:34] <tseliot> superm1: slangasek told me that he approved them
[10:34] <superm1> tseliot, oh he only approved the source packages then, still has to approve binaries
[10:34] <tseliot> d'oh
[10:39] <tseliot> tjaalton: my filesystem was broken. X starts now
[10:41] <knittl> ok, x won't start—i guess this is still related to -nv drivers? am i correct?
[10:42] <tseliot> tjaalton: radeon still seems to fail though (with stock X and mesa). fbdev works
[10:44] <tjaalton> tseliot: it's a pretty old snapshot
[10:45] <knittl> how can i use vesa or nouveau?
[10:53] <tseliot> tjaalton: which used to work with the old mesa and drm. Downgrading mesa didn't help. I'll try downgrading libdrm
[10:54] <tjaalton> tseliot: the api changed
[10:54] <tjaalton> so we really need a new snapshot
[10:54] <tjaalton> tseliot: but, compiz works here again with the new stuff
[10:55] <tjaalton> double-checked that the -dev packages were correct
[10:55] <tjaalton> and rebuilt xserver, and works now
[10:56] <tseliot> tjaalton: what driver are you using? Intel?
[10:56] <tseliot> tjaalton: also, did you upload your fix?
[10:56] <tjaalton> intel yes, and didn't upload anything yet
[10:57] <knittl> The following packages have unmet dependencies: xserver-xorg-video-nouveau: Depends: xserver-xorg-core (>= 2:1.6.2) but it is
[10:57] <knittl> not going to be installed
[10:57] <tjaalton> knittl: would need a new snapshot
[10:57] <knittl> tjaalton: ok, so the only way is to use vesa for now?
[10:57] <tjaalton> or -nv?
[10:57] <tseliot> tjaalton: please upload the fixes if they work correctly
[10:58] <tseliot> or push them to git and I'll upload them if you prefer
[10:58] <knittl> tjaalton: gdm/X won't start, tells me to run in low graphics mode
[10:58] <tseliot> knittl: try fbdev
[10:58] <tjaalton> tseliot: I'm just trying to figure out if the xserver needs to be rebuilt or not
[10:58] <knittl> i nuked my xorg.conf
[10:58] <tjaalton> knittl: so you're using vesa then
[10:58] <knittl> tjaalton: but vesa should work?
[10:58] <tseliot> if that's what you're using
[10:58] <knittl> how can i find out?
[10:59] <knittl> or, what is the default without an xorg.conf?
[10:59] <tjaalton> you are running failsafe == vesa
[10:59] <knittl> i'm not running anything atm
[10:59] <tseliot> tjaalton: if Xephyr depended on mesa, then I guess we need to rebuild X against the new mesa
[10:59] <knittl> i exited to console
[11:01] <tjaalton> tseliot: uh wait, I didn't have the new glx installed, so no, it doesn't work
[11:03] <tseliot> tjaalton: do we have a new snapshot of radeon in xorg-edgers with the new api?
[11:03] <tjaalton> tseliot: I don't know, probably
[11:04] <tseliot> shipping the alpha in this state wouldn't be ideal
[11:05] <tjaalton> really? :)
[11:05] <tseliot> I'll try intel here
[11:05] <tjaalton> only the radeon api changed
[11:05] <tjaalton> in libdrm/mesa/ddx
[11:07]  * tseliot hates grub 2
[11:15] <tjaalton> ok, signing off.. need to start reading asap ->
[11:29] <sebner> tseliot: Building gnome-shell gives me: checking for glXCreateContext in -lGL... no   ---> internet tells me (old gnome-games bug): The libglx.so from nvidia binary
[11:29] <sebner> driver was replaced by xserver upgrade. That was causing this problem.
[11:32] <tseliot> sebner: we need the fix that tjaalton wrote for that
[11:32] <tseliot> I'll test things here now
[11:33] <sebner> tseliot: cool, /me is afraid of rebooting right now so sebner keeps his 3d for now :P
[11:47] <geser> sebner: libgl1-mesa-dev is currently broken in lucid, so everything which tries to link with -lGL will currently fail
[11:47] <tseliot> right
[11:49] <sebner> geser: oh ho! good to know, thx
[11:50] <tseliot> the fix that I mentioned is supposed to solve that
[11:52] <sebner> :)
[11:59] <tseliot> tjaalton: if I try to build with your patch I get this: dh_install: libgl1-mesa-swx11 missing files (usr/lib/mesa/libGL.so.*), aborting
[11:59]  * tseliot -> lunch
[12:51] <tseliot> never mind
[14:42] <wind-rider> tjaalton: ping
[14:53] <wind-rider> tjaalton: after updating libdrm, X segfaults when using the radeon driver (https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/505112)
[14:53] <tseliot> wind-rider: the API changed. I'm working on it
[14:54] <wind-rider> tseliot: ok, great, thx :) i saw tjaalton updated the package at https://lists.ubuntu.com/archives/lucid-changes/2010-January/003025.html
[14:54] <tseliot> you might want /me nods
[14:54] <wind-rider> tseliot: so i thought he might know more
[14:54] <tseliot> stupid keyboard..
[14:54] <tseliot> wind-rider: thanks for filing the bug report
[14:55] <tseliot> oh, it's a duplicate
[14:55] <wind-rider> tseliot: oh, that's fine :) i just confirmed it
[14:55] <tseliot> ok
[14:55] <wind-rider> tseliot: and marked a duplicate
[14:56] <wind-rider> tseliot: it is assigned now at the xserver-xorg-video-ati package, should it be changed?
[14:56]  * tseliot nods
[14:56] <tseliot> no
[14:56] <tseliot> I'll take care of the bug report
[14:56] <tseliot> thanks
[14:56] <wind-rider> great :) thx to you!
[14:58] <sebner> tseliot: my Xserver segfault after reboot ^^
[14:58] <tseliot> aah, so it was that
[15:03] <sebner> tseliot: that means?
[15:03] <tseliot> sebner: never mind I confused you with someone else
[15:03] <sebner> ah
[15:04] <sebner> tseliot: me blames the xorg update :P want to see nvida bugreport?
[15:04] <tseliot> sebner: the above mentioned crash is about radeon
[15:05] <sebner> tseliot: nvidia blob ~o~
[15:33] <Duke`> wtf, left computer for 2 hours and found it in kernel panic mode when back
[15:58] <ScottK> tseliot: What's the plan on mesa?  In Kubuntu we are broken and will stay broken (as in no Alpha 2) until it's fixed.
[15:59] <tseliot> ScottK: I'm working on it
[16:00] <sebner> tseliot: nvida blob working again. it's like using windows. doing reboots fixes stuff ^^
[16:00] <ScottK> tseliot: OK.  Are we talking minutes, hours, or days until it's fixed?
[16:01] <Sarvatt> ahhah its a race between gdm starting up which needs dbus ready and dbus starting at the same time so its not always ready -- https://bugs.edge.launchpad.net/ubuntu/+source/gdm/+bug/502838
[16:02] <tseliot> ScottK: I've been working on it today. The fact that the other upload of mesa (7.7) broke radeon slowed me down a bit
[16:02] <tseliot> ASAP is my answer
[16:02] <tseliot> hopefully today
[16:03] <ScottK> tseliot: I understand.  Thanks.
[16:14] <ScottK> tseliot: Based on that, I just sent a status to kubuntu-devel letting people know it may be a while.  I'll quit bugging you and let you focus on getting it fixed ....
[16:15] <tseliot> ScottK: ah, thanks for sending that email. It was a good idea
[16:15] <ScottK> That's why I was asking for an estimate.
[16:44] <tjaalton> tseliot: having problems with -ati?
[16:44] <tseliot> tjaalton: it looks like the new driver works only with nomodeset
[16:44] <tjaalton> tseliot: oh
[16:44] <tseliot> also the patch that you gave me for mesa seems to be wrongly formatted (I guess it's pastebin/browser's fault)
[16:45] <tjaalton> could be
[16:45] <tseliot> I changed things manually and I'm building now
[16:50] <Sarvatt> yeah ati needs updating due to the libdrm-radeon1 api change http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=4b05c47ac657f9a93d76221269761ed64c81f716
[16:51] <tjaalton> tseliot: try pulling just that commit on top of the current driver
[16:52] <tseliot> tjaalton: I had taken what's in master but sure I can try that
[16:53] <tjaalton> maybe the displayport stuff broke something
[16:57] <tjaalton> btw, add DEB_BUILD_OPTIONS="parallel=2" or such to your session, speeds up the builds a lot
[16:57] <tjaalton> if you have a multicore cpu
[16:57] <tjaalton> mesa builds in 15min on my laptop
[16:59] <Sarvatt> yay this fixes the gdm startup problem here -- http://bazaar.launchpad.net/~ubuntu-desktop/gdm/ubuntu/revision/186
[16:59] <tjaalton> wow
[17:00] <Sarvatt> just a little one liner in /etc/init/gdm.conf
[17:02] <tjaalton> with the config_init fix from debian there should be even less problems booting up :)
[17:03] <jcristau> there's still some weird stuff going on, but yes.
[17:03] <wind-rider> i had some problems before the radeon driver was broken
[17:04] <wind-rider> kdm or the X server did not start automatically
[17:04] <wind-rider> i had to log in on a console and run startx
[17:04] <wind-rider> is that a known problem?
[17:05] <knittl> wind-rider: yes, it's known
[17:05] <tjaalton> hard to say without the error msg
[17:05] <wind-rider> tjaalton: there was no error message
[17:06] <tjaalton> does kdm use upstart?
[17:06] <jcristau> in other news, http://ftp-master.debian.org/new/xf86-input-wacom_0.10.3+20100109-1.html
[17:06] <tjaalton> jcristau: wow!
[17:06] <wind-rider> i have no idea if kdm uses upstart
[17:07] <tjaalton> is there a job script in /etc/init ?
[17:07] <Sarvatt> eww, grabbing the source for kdm pulls in a 70mb package :D
[17:07] <tseliot> tjaalton: oh, thanks, I have an icore7
[17:07] <ScottK> tjaalton: kdm does use upstart in Karmic and later.
[17:08] <tseliot> tjaalton: with your patch: cp: cannot stat `debian/tmp/usr/lib/glx/pkgconfig/dri.pc': No such file or directory
[17:08] <tseliot> dh_install: cp -a debian/tmp/usr/lib/glx/pkgconfig/dri.pc debian/mesa-common-dev/usr/lib/pkgconfig// returned exit code 1
[17:08]  * Sarvatt cheers at wacom
[17:08] <tjaalton> ScottK: so maybe it needs a similar fix as gdm added in the latest upload?
[17:08] <ScottK> Sigh.  Of course the package that it's part of is currently unbuildable due to mesa ...
[17:08] <ScottK> tjaalton: Where's the patch?
[17:09] <Sarvatt>  http://bazaar.launchpad.net/~ubuntu-desktop/gdm/ubuntu/revision/186
[17:09] <ScottK> Thanks.
[17:11] <ScottK> Sarvatt and tjaalton: Looks like it does.  Thanks.
[17:11] <tjaalton> ScottK: ncie
[17:11] <tjaalton> *nice
[17:11] <tjaalton> tseliot: ok, that was an old one then, let me give you the full diff..
[17:12] <tjaalton> tseliot: http://users.tkk.fi/~tjaalton/foo/mesa.diff
[17:14] <Sarvatt> where can I get the source for that wacom upload? don't see it on ftp.debian.org
[17:14] <tjaalton> tseliot: that variable works with most, if not all xorg modules
[17:15] <Sarvatt> ah got it ftp-master.debian.org, slow today :D
[17:17] <tjaalton> tseliot: http://users.tkk.fi/~tjaalton/foo/mesa.diff
[17:17] <tjaalton> but.. installing the resulting libgl1-mesa-glx breaks things
[17:17] <tjaalton> glxinfo says DRI is used etc, ldconfig finds the libs but apps still fall back to software rendering
[17:18] <tjaalton> we could sort this out later, and just link whatever is necessary to get the builds rolling again
[17:18] <tjaalton> ugly, yes..
[17:18] <tseliot> yes, I know
[17:19] <tseliot> is that a different patch?
[17:19] <tseliot> in the same place?
[17:19] <tjaalton> that's the current git diff
[17:19] <tjaalton> which builds fine
[17:19] <tseliot> aah
[17:19] <ScottK> Sarvatt and tjaalton: It's actually not an immediat problem for kdm, because we still use hal, but I added it anyway as it doesn't hurt to be explicit.
[17:19] <tseliot> ok
[17:19] <tjaalton> ScottK: ok
[17:19] <tseliot> tjaalton: I would like to see what it builds exactly
[17:20]  * tseliot is building mesa again
[17:20] <tjaalton> hmm
[17:20] <tjaalton> oh crap
[17:20] <tjaalton> I know what's wrong
[17:20] <wind-rider> ScottK: so it does not solve the problem having to run startx manually?
[17:20] <ScottK> wind-rider: I don't know for sure.
[17:20] <ScottK> I doubt it.
[17:21] <wind-rider> ok
[17:21] <wind-rider> just to have it clear
[17:21] <tjaalton> libgl1-mesa-glx has the swx11 version of libGL
[17:21] <wind-rider> knittl: is it already at launchpad?
[17:21] <tjaalton> because they are installed in the same prefix
[17:21] <tjaalton> normally the dri version would be in lib/glx
[17:22] <tjaalton> tseliot: so, only changing the libdir for swx11 should be enough
[17:24] <tjaalton> I'll wrap up a new diff
[17:24] <knittl> wind-rider: yes, but i can't find it right now
[17:25] <knittl> https://bugs.edge.launchpad.net/ubuntu/+source/gdm/+bug/502838
[17:25] <knittl> found it :D
[17:25] <wind-rider> knittl: ok, i saw that one earlier today :) but it is for gdm
[17:26] <knittl> oh, are you using kde?
[17:26] <knittl> but it's probably the same cause
[17:26] <tseliot> tjaalton: that would make sense ;)
[17:26] <tseliot> I'm building ati with only the API patch
[17:27] <tjaalton> so I found out the reason for the different libdir for the dri target :)
[17:27] <wind-rider> knittl: ScottK changed it in kdm but he thought it would not solve the problem as he says kdm still uses hal there
[17:27] <knittl> ok, i don't know about kdm. thought it might be helpful anyway
[17:27] <wind-rider> knittl: ok
[17:30] <tseliot> tjaalton: -ati is not maintained in git, is it?
[17:31] <tseliot> as getting only that patch makes it work again with KMS
[17:31]  * tseliot wonders if the master branch requires a kernel update
[17:32] <tseliot> or if they just broke the code
[17:32] <tjaalton> tseliot: no it's not
[17:33] <tjaalton> great that it works
[17:33] <tjaalton> cherry-picked the config_init fix
[17:35] <tseliot> tjaalton: this one? http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=36bd69affc996c92c40b7360a7fbaa1a3a46abfd
[17:35] <tseliot> or are you referring to mesa now?
[17:35] <tjaalton> no, xserver :)
[17:35] <Sarvatt> its the libdrm interface to -ati that changed and broke it, no worries about the kernel
[17:36] <tjaalton> maybe ati master needs libdrm master
[17:36] <tseliot> tjaalton: ok, I just wanted to make sure that my upload of -ati could begin without problems
[17:36] <tjaalton> it should
[17:36] <tseliot> ok
[17:37] <tjaalton> libdrm doesn't seem to have much ati related post .17
[17:38] <tseliot> Sarvatt: I know. I was wondering if drm in the kernel had something that we're missing
[17:40] <Sarvatt> oh shoot, apw was asking if it was ok to turn on radeon KMS by default for a2 and it probably would have been good to mention that ati kms was broken on r600+ with 2.6.32.2 and fixed in 2.6.32.3
[17:40] <jcristau> Sarvatt: i think they have the fix in the lucid kernel?
[17:40]  * tseliot has an r600 card and KMS works
[17:40] <jcristau> Sarvatt: https://lists.ubuntu.com/archives/lucid-changes/2010-January/002876.html seems to have it (the airlied patch)
[17:41] <tjaalton> yep
[17:41] <Sarvatt> no linux-meta for that kernel yet but good to see its in there now
[17:42] <tjaalton> probably not even published yet
[17:42] <tjaalton> those need to be pushed through the new queue every time
[17:42] <tjaalton> ah, -10 is published
[17:46] <tseliot> ok, -ati uploaded
[17:46] <tseliot> tjaalton: did you upload mesa?
[17:49] <tjaalton> tseliot: no, still need to test
[17:49] <tseliot> ok
[17:52]  * tjaalton does the dri-dance
[17:52] <tjaalton> works
[17:53] <tseliot> \o/
[17:54] <tjaalton> *phew*...
[17:54] <tseliot> hey we're risking to have an actually functioning alpha 2
[17:54] <tseliot> :-P
[17:54] <tjaalton> I need to break it when I get back from the party ;)
[17:54] <tjaalton> (not)
[17:55] <tjaalton> keyboards should have breathalysers
[17:55] <tjaalton> "did I write _that_?"
[17:55] <tseliot> hey if you don't have time to break it, I definitely can do it for you ;)
[17:55] <tseliot> :-D
[17:56] <tjaalton> facebook/putty on a Series60 phone is a killer, literally
[17:56] <jcristau> hmm i guess i'd need 10 days to break it.  need to have stuff transition to squeeze before it gets autosynced :/
[17:57] <tseliot> tjaalton: on the e71 ?
[17:57] <tjaalton> tseliot: yes
[17:57] <tseliot> oh
[17:57]  * tseliot wants it on his e71 too
[17:57] <tjaalton> it's not a good idea to check facebook on the taxi when getting back home :P
[17:57] <tseliot> heh
[17:57] <tjaalton> just google, it works very well
[17:57] <tjaalton> putty that is
[17:58] <tseliot> will do
[17:59] <tjaalton> jcristau: I doubt there'll be much stuff to autosync that might risk breaking anything :)
[17:59] <tjaalton> mesa uploading
[18:00] <tseliot> :-)
[18:01] <wind-rider> tjaalton: if mesa and -ati are uploaded, will my X server work again?
[18:01] <jcristau> tjaalton: i don't think x11-xkb-utils is forked?  so i could break xkbcomp, but people won't let it move to testing if i do that :/
[18:02] <tseliot> wind-rider: -ati alone should do it. The problem with mesa was visible only if you tried to build something
[18:02] <wind-rider> tseliot: ok, great :) i
[18:02] <wind-rider> 'll try it
[18:03] <wind-rider> tjaalton, tseliot: thx for your work
[18:03] <tseliot> jcristau: break xkbcomp? Why? Did they change anything interesting?
[18:03] <tseliot> hey, we break it, we fix it ;)
[18:03] <tseliot> (and break it again)
[18:03] <jcristau> tseliot: no.  it was just me trying to see how i could break alpha2
[18:04] <tseliot> jcristau: too bad. That could have broken the xkbcomp patch that we use to reduce boot time
[18:04] <wind-rider> bye
[18:04] <tseliot> oh, well, we'll think of something else
[18:05] <tjaalton> jcristau: right, x11-xkb-utils is the same in both
[19:26] <Sarvatt> hmm not having any luck searching launchpad for pixman bugs with asserts that would be fixed by upgrading to pixman 0.16.14. only getting the one result with pixman assert in the title
[20:49] <wind-rider> ScottK: do you know if one can see a package's build status?
[20:50] <wind-rider> ScottK: is it somewhere on launchpad?
[20:52] <ScottK> wind-rider: Yes.  What are you looking for?
[20:53] <ScottK> tjaalton: mesa FTBFS: https://launchpad.net/ubuntu/+source/mesa/7.7-0ubuntu2/+build/1438098
[20:55] <dhillon-v10> ScottK, hi, now that I am working on X what would be the first place to get started, triaging some bugs, I read the wiki page so
[20:56] <ScottK> dhillon-v10: I know very little about X.  I'm the wrong one to ask.
[20:56] <wind-rider> ScottK: at https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/505095 is stated that the fix has been committed, but that the package will be only in the repo when it is built
[20:57] <wind-rider> ScottK: i found https://launchpad.net/ubuntu/+source/xserver-xorg-video-ati/1:6.12.99+git20091125.0061c4db-0ubuntu2
[20:57] <ScottK> That shows you the build status
[20:57] <wind-rider> ScottK: and there is stated that the i386 build succeeded, but when trying to upgrade apt-get did not find the new package
[20:58] <ScottK> Accepted means it's built, but not in the archive.
[20:58] <ScottK> The archive publisher run starts at :03 each hour and finishes ~:45.
[20:59] <wind-rider> ok, that clarifies it :) thx
[20:59] <ScottK> So it should be available in about 45 minutes.
[20:59] <ScottK> That assumes you pull from archive.ubuntu.com directly.
[20:59] <ScottK> If you pull from a mirror, then there's additional delay.
[21:08] <sistpoty> tjaalton, tseliot: aware of the build failure for mesa?
[21:08] <sistpoty> if so, and you need some help, feel free to ping me
[21:08] <jcristau> yay hacks for closed drivers.
[21:09] <sistpoty> jcristau: then make my ati card work with gl :P
[21:20] <sistpoty> (just kidding, have seen the diff between ubuntu taking the snapshot from svn and debian... didn't find a trivial patch for the texture problem)
[21:21] <tjaalton> sistpoty, ScottK: sorry, I'm on my phone now, so can't help until tomorrow. if you can come up with a fix, feel free to upload.. :/
[21:21] <sistpoty> tjaalton: ok, will try
[22:06] <sistpoty> tjaalton: I'm not too sure if my mesa patch will fix the build failure, but if it does, pretty please clean it up, it's the ugliest patch I ever did for ubuntu, and I'm extremely ashamed of it (just overriding LD_LIBRARY_PATH in debian/rules in a completely nonsense manner)
[22:08] <sistpoty> oh, no it bails out somewhere else, yuck
[22:10]  * albert23 just finished a mesa build successfully
[22:10] <albert23> dh_shlibdeps -s -l/usr/lib/mesa did the trick
[22:12] <jcristau> albert23: yep, that sounds like it should work
[22:14] <sistpoty> albert23: I got errors for the r200 driver somewhere (but thanks for the trick, much better than the evil hack I've got)
[22:14] <sistpoty> radeon_common_context.h:405: error: array type has incomplete element type
[22:18] <sistpoty> albert23: I'm actuallly inclined to just upload your fix. test-building seems underrated for mesa, I guess
[22:18] <albert23> That radeon error was fatal for you?
[22:18] <sistpoty> yes
[22:18] <albert23> I didn't get that
[22:19] <sistpoty> (amd64)
[22:19] <jcristau> old libdrm?
[22:19] <albert23> so am I
[22:19] <sistpoty> hm, german mirror problem? (which is not a mirror problem, but a lack of constraints on b-d's)
[22:20] <jcristau> new mesa should probably build-dep on libdrm-dev >= 2.4.17
[22:20] <albert23> I have 2.4.17 in the pbuilder
[22:22] <sistpoty> 2.4.17-0ubuntu1 for libdrm2
[22:22] <sistpoty> same for libdrm-dev
[22:24] <sistpoty> interesting, I believe it builds further now... mesa is getting more and more obscure to me :)
[22:24] <albert23> I have r200 and r300_dri.so in -dri, so the build went ok here
[22:25] <sistpoty> I'll just wait and see what happnes ;)
[22:29] <sistpoty> no, still the same error :(
[22:30]  * sistpoty updates pbuilder (again)
[22:32] <albert23> given the buildd reached the install target in the previous build, we can assume that error will not happen on the buildd?
[22:46] <sistpoty> albert23: are you suggesting to just upload the fix from you? (though it still doesn't build for me)?
[22:47] <albert23> sistpoty: that's up to you. But I think it means the radeon failure is something local for you
[22:47] <sistpoty> albert23: I doubt it's local but a bug somewhere (however not trivial to investigate)... 
[22:48] <sistpoty> slangasek: ok with replacing a broken version with a probably broken version?
[22:51] <sistpoty> albert23: I think I'll just upload it as is, hoping that tjaalton will fix it up tomorrow if it breaks.
[22:52] <sistpoty> albert23: as the change is really from you, currently I've put "* debian/rules: Fix dh_shlibdeps as proposed by albert32 to fix FTBFS." into changelog
[22:52] <sistpoty> albert23: anything you'd like to see changed there?
[22:53] <albert23> sistpoty: my name is Albert Damen, maybe better then an irc nick
[22:53] <sistpoty> albert23: ok, thanks, couldn't figure this on first glance
[22:57] <sistpoty> albert23: just uploaded, thanks againg... let's just cross fingers!
[22:57]  * sistpoty feels dirty though
[22:58] <albert23> We will know in an hour
[22:58] <albert23> Armel failed in the same way, so I have some hopes
[23:32] <sistpoty> hm... mesa should be accepted at least now, very strange
[23:37] <sistpoty> albert23: case solved, I fetched an outdated source