00:47pmoreau: RSpliet: Eh eh, ok. I'll just give it pfb directly then. ;)
06:34bauerbob: hi, i’m using ubuntu 15.04 and removed all the nvidia drivers, installed nouveau, but X.org says “no screens found(EE)”
06:34bauerbob: some lines above this error i see some infos about nouveau
06:34bauerbob: [ 15.796] (II) NOUVEAU driver for NVIDIA chipset families :
06:34mwk: hakzsam: umm, not PM_SETTINGS?
06:34bauerbob: and the NV50 is NOT in this list
06:35bauerbob: so is NV50 not supported? the feature matrix says it is supported
06:36bauerbob: i even tried upgrading the nouveau driver by activating the xorg-edgers repo, but vivid seems to ship the latest package already
06:37hakzsam: mwk, I just named it like NVIDIA does, and I'm not sure if this reg is only related to PM
06:38hakzsam: btw, NVIDIA uses SM for local counters (MPs) and PM for global counters (PCOUNTER), it would be good for us to use the same convention, what do you think?
06:40mwk: hakzsam: uses where?
06:40mwk: SM is just nv's name for MP
06:40mwk: AFAIK they just always use PM
06:40hakzsam: in the cupti API/documentation for example
06:41prg_: bauerbob, nv50 is certainly supported, just might be called G80 or something
06:41prg_: bauerbob, is nouveau blacklisted maybe? the nvidia driver likes to do that i think
06:42bauerbob: i grepped for nouveau in /etc/modules.d (or was it /etc/modprobe.d?) and found nothing
06:42prg_: so is the module loaded? pastebin dmesg
06:53prg_: and what exactly does the xorg log say?
06:54Karlton: bauerbob: did you remove the /etc/x11/xorg.conf that nvidia makes?
06:55bauerbob: yes …actually nvidia had none, either
06:55bauerbob: i tried nouveau without xorg.conf first
06:55bauerbob: but since it didn’t work i created the minimal xorg.conf given in the FAQ
06:55bauerbob: but still no luck
06:56bauerbob: here’s the Xorg.0.log: http://pastebin.com/cbZVD38r
06:57prg_: that's... short
06:58bauerbob: uhm… yes… just a sec
06:59bauerbob: should’t “Initialized nouveau 1.2.1 20120801” be more recent?
06:59bauerbob: 2012 seems to be pretty old
07:00bauerbob: so here’s the full Xorg.0.log: http://pastebin.com/vgdqxYaH
07:00prg_: i think that's when some api last changed or something, should be fine
07:05prg_: hmm, not sure what's wrong there. some systemd thing where x runs as user and you need to be in a special group so it can talk to the hardware?
07:05prg_: but no idea
07:07bauerbob: ok. i guess i’ll open a bug report for ubuntu
07:09prg_: not sure it's a bug, probably some misconfiguration
07:09prg_: isn't there some wiki or something?
07:09prg_: oh well, no idea about ubuntu
07:12bauerbob: well, there’s http://wiki.ubuntuusers.de/Grafikkarten/Nvidia/nouveau - but it doesn’t contain a troubleshooting section
07:12Karlton: there is the video group, but I don't think nvidia would work either if you are not in the group
07:27imirkin: bauerbob: ls -l /dev/dri
07:34bauerbob: @imirkin: $ ls -l dri
07:34bauerbob: crw-rw----+ 1 root video 226, 0 Apr 28 16:21 card0
07:34bauerbob: crw-rw---- 1 root video 226, 64 Apr 28 16:21 controlD64
07:34bauerbob: crw-rw----+ 1 root video 226, 128 Apr 28 16:21 renderD128
07:35imirkin: bauerbob: your X log is very weird. it sees the device, but nouveau never actually picks it up...
07:36imirkin: is there something like selinux in the mix messing things up?
07:37bauerbob: uhm… i never really changed anything related to selinux, so it should be configured with ubuntu’s default settings
07:39bauerbob: i think Xorg initializing goes wrong as of this line “Falling back to old probe method for modesetting”
07:39imirkin: but that just means that nouveau doesn't see any devices
07:39imirkin: even though it should :)
07:40imirkin: are you perhaps running X as yourself and aren't in the video group?
07:41bauerbob: no, it’s being started from gdm
07:42imirkin: do you have an xorg.conf? if so, remove it
07:42imirkin: and pastebin the xorg log that happens when you do that
07:43bauerbob: i already removed xorg.conf
07:45imirkin: can you pastebin the xorg log that results from that?
07:45bauerbob: yes, but it really looks like the one that is already in pastebin
07:46imirkin: i'm sure, but mind pasting it anyways?
07:49bauerbob: just a sec
08:14bauerbob: @imirkin: http://pastebin.com/uh5A75QJ
08:32imirkin: bauerbob: that's incredibly weird... i've never seen this issue
08:32bauerbob: yay, i’m special :-/
08:32imirkin: (and adding to the oddness is the fact that i've seen a _ton_ of issues)
08:37bauerbob: oh my… i guess i’m screwed
08:38bauerbob: what i tried meanwhile: shutting down gdm and calling startx as user (who is in the video group) - same error
08:39bauerbob: and i installed this kernel: http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-next/current
08:39bauerbob: it says: [ 653.345] (II) [drm] nouveau interface version: 1.2.2
08:39imirkin: you're getting a KMS terminal and everything right?
08:39bauerbob: but still the same error
08:40imirkin: i.e. high-resolution term, not the VGA 80x25 one
08:40bauerbob: let me check…
08:40bauerbob: yes, it’s definetly > 80x25
08:41imirkin: something in your X setup then, but ... no idea what
08:42imirkin: if this were happening to me, i'd trace through the nouveau ddx's init code and see why it's bailing out
08:45bauerbob: thank you so far, maybe i come back later this evening
11:06imirkin_: anyone around with a pre-gk110 kepler? (i.e. gk10x) and can do a mesa build + test a piglit for me?
11:07imirkin_: i'm looking for someone to build https://github.com/imirkin/mesa/commits/gl4-integration and then run 'bin/shader_runner tests/spec/arb_tessellation_shader/execution/quads.shader_test -fbo -auto' and tell me if you get a memory out of bounds error in dmesg as a result
11:12mupuf: imirkin_: I could certainly do that
11:12imirkin_: i get that error on a gk208 but not a gf108
11:14imirkin_: curiously i don't get it with nop.shader_test, so i think it must be something relating to the fact that quads.shader_test takes in 4 control points but outputs 9
11:15imirkin_: and i should stop being so lazy and just trace the damn thing
11:25mupuf: imirkin_: nve6 is fine?
11:27imirkin_: mupuf: to test with? yeah
11:27mupuf: will try it then :)
11:27imirkin_: if you've brought your nuclear power plant along to power it on :p
11:28mupuf: the nve6 consumes no more than 120W
11:28mupuf: only when running heaven though
11:28mupuf: xonotic peaks at 90W
11:29mupuf: even on the blob
11:30imirkin_: oh, while you're at it, could you also apply http://patchwork.freedesktop.org/patch/48063/ (to that tree) and run heaven?
11:48tobijk: do we rally have a fully GL4.1 set now? :O
11:49imirkin_: with that branch it'll report GL 4.1
11:49imirkin_: i wouldn't say it's fully conformant... the tess stuff has *tons* of issues
11:50imirkin_: but at a high level, all the GL 4.1 features are supported in that branch
11:51tobijk: that branch? it looks like master to me :-)
11:51imirkin_: the branch i mentioned above
11:51imirkin_: master still reports gl 3.3
11:51imirkin_: i just upped the feature level reported for my personal convenience
11:51tobijk: i have joined recentyl
11:54tobijk: dont know if intended but that commit is in master as well: http://cgit.freedesktop.org/mesa/mesa/commit/?id=e312a6995850e78b3b9e2cbe4713928bc9cc386d
11:55imirkin_: yep, intended
11:55imirkin_: like i said, it's to make my life easier
11:56tobijk: are there thnigs to test with the gl4-integration branch? i can do that next to my work :)
11:58imirkin_: tobijk: do you have any games that require GL4?
11:58imirkin_: iirc metro redux and bioshock infinity
11:59tobijk: not that i'm aware of, nor do i have the a full valve account
11:59imirkin_: well, i was able to get the valve thing, but that's just valve games
11:59imirkin_: i.e. not any of those :)
11:59tobijk: yeah dont they have some GL4 ones?
12:00imirkin_: didn't think so, but maybe some games they have will take advantage of GL4 features?
12:00imirkin_: anyways... tess has known serious issues
12:00imirkin_: so that branch is more of a joke than anything else
12:00tobijk: everything has to start somewhere...
12:01imirkin_: i.e. "ha ha, nouveau has GL 4.1 and your driver which is backed by full time staff doesn't". even while knowing full-well that the support is nowhere releasable due to tess fail.
12:02imirkin_: and the fail is at all levels, which is nice... mesa core, st/mesa, *and* nouveau. neat, huh?
12:02tobijk: y a y
12:04tobijk: imirkin_: btw you happen to know if there is something going on concerning the libdrm .60 failure?
12:04imirkin_: yeah, downgrade to .59 :)
12:04tobijk: meh :/
12:04imirkin_: i'm really hoping skeggsb_ will take a look
12:08imirkin_: but he's been quiet for a while
12:08tobijk: coding the all solving patch :)
12:19mupuf: imirkin_: do I need a git version of llvm?
12:20mupuf: gallivm/lp_bld_init.c:437:4: error: implicit declaration of function ‘LLVMLinkInJIT’ [-Werror=implicit-function-declaration]
12:20imirkin_: you don't need llvm at all
12:20imirkin_: just don't build swrast...
13:03mupuf: imirkin_: back!
13:03mupuf: heaven looks quite hilarious
13:03mupuf: especially without the patch you linked me to in patchwork
13:03mupuf: will try the piglit test
13:10jay3d: I have a question: What it takes to port nouveau driver set to OS X?
13:14mupuf: imirkin_: yes, I get a memory out of bounds
13:14imirkin_: mupuf: ok thanks
13:14mupuf: and the test fails
13:15imirkin_: and you get the funny blue triangles with tess in heaven?
13:15imirkin_: i get those on both gk208 and gf108
13:16imirkin_: mupuf: could i trouble you to leave the GK106 in reator tonight? i want to do some tracing
13:16pmoreau: RSpliet: Let's get this thing compiling and running. :-)
13:16mupuf: imirkin_: sure
13:16pmoreau: RSpliet: Do you have some new patches I could test?
13:16mupuf: imirkin_: I do not get any weird triangles no
13:16mupuf: just ... nothing at all on the surfaces that are supposed to be tesselated
13:17mupuf: [ 5229.650623] nouveau E[ PGR][0000:01:00.0] GPC0/TPC0/MP trap: MULTIPLE_WARP_ERRORS MEM_OUT_OF_BOUNDS
13:17mupuf: I get a ton of those too, for heaven
13:17mupuf: and GL errors too
13:17imirkin_: mupuf: yeah, that's what i see on GK208 as well
13:18mupuf: you mean in drirc?
13:18imirkin_: or in the environment
13:18mupuf:still needs to finish his patches to fix the older unigine benchmarks
13:18imirkin_: to override the stupid thing in drirc
13:19mupuf: I indeed get the weird triangles
13:20mupuf: there are some z-ordering issues too
13:21RSpliet: jay3d: if you were hoping for a more explicit answer: the whole nvkm half of the nouveau kernel-module can be re-used, but it needs to be glued to a different interface (namely, whatever the Mac OS X kernel implements). Then you need to write a new "libdrm" that communicates not with drm but with whatever Mac interface there is
13:21mupuf: wow, nouveau makes the GPU consume 29W :D
13:21mupuf: we are so damn power efficient!
13:22mupuf: hmm hmm
13:22RSpliet: after that I suspect you could re-use Mesa, but not the xf86 component (since it's solely for X.org), so you'd still have to port that to whatever compositor Mac uses
13:23RSpliet: pmoreau: nope, nothing new
13:23RSpliet: didn't have the time/energy for it
13:23pmoreau: I understand :-)
13:24imirkin_: mupuf: oh? i didn't see any z-ordering issues...
13:25mupuf: only for one scene
13:25imirkin_: mupuf: just the unfilled tris that tess produces...
13:25mupuf: and one particular item
13:25imirkin_: oh hm. maybe i just didn't notice it.
13:25imirkin_: btw, F3 to enable/disable tess
13:25imirkin_: (don't try to enable wireframe, that won't work)
13:26imirkin_: as for power consumption... try clocking that board up, you might see it increase :p
13:26mupuf: seriously? Can't believe you :D
13:27mupuf: speaking about that though
13:27mupuf: since we are not going to use our own pdaemon, I guess that I should just implement a kernel-space driver that would not be based on hwmon (since they still don't have an in-kernel API)
13:28mupuf: unless ...
13:28imirkin_: hm? why wouldn't we have a pdaemon?
13:28imirkin_: [other than laziness]
13:28mupuf: not on all GPUs
13:28imirkin_: well, not all gpu's _have_ a pdaemon :p
13:28mupuf: because of maxwell's signature thing
13:28imirkin_: yeah, maxwell is a bit of a fly in the ointment
13:28mupuf: older GPUs do not have a power sensor anyway
13:29mupuf: I keep using my user-space programs for power monitoring
13:29mupuf: would be good to have them in nouveau
13:29mupuf: the driver is trivial anyway
13:54pmoreau: RSpliet: Youhou! It did crashed, and pstate reports that the clock changed. :-)
13:55pmoreau: Waiting for Mesa to compile to test in-game and see if FPS change
13:55RSpliet: it didn't crash?
13:56pmoreau: Oh right
13:56pmoreau: Didn't thought I was that tired... --"
13:58imirkin_: in case anyone's curious about tess, here's a pair of screenshots from heaven with/without tess for the same scene: http://imgur.com/Ffyf3xa,qaeXYmY#1
13:59RSpliet: imirkin_: Interesting... you can certainly see it adds depth!
13:59RSpliet: if you look through the obvious misrenders :-P
14:00imirkin_: yeah, i geuss it just gives fairly rough control surfaces
14:00imirkin_: which it then expects get tessellated
14:00imirkin_: (and transformed via hull shader)
14:00RSpliet: the bit on the wall of the house on the left is interesting
14:01RSpliet: you can see the texture following the wooden bar rather than the wall surface
14:01imirkin_: could well be a bug somewhere
14:02RSpliet: pmoreau: I'm still in anticipation of any performance data... but I guess it's so awesome you got sucked into the game and forgot all about IRC? :-P
14:02RSpliet: imirkin_: btw, a 14% decrease in framerate? :-D
14:02pmoreau: RSpliet: Recompiling Mesa takes some time ;)
14:02imirkin_: RSpliet: probably more
14:02imirkin_: feels a lot snappier without tess
14:02pmoreau: It's an old core 2du I have
14:03RSpliet: pmoreau: why recompiling Mesa? or did you have some debug symbols in? :-P
14:03imirkin_: although... it's funny... in earlier tess attempts, i don't remember those blue things
14:04imirkin_: i'm actually guessing someone broke something in one of the higher layers
14:04pmoreau: RSpliet: I don't have stock Mesa installed as I installed the blob, and I erase my custom install by trying to build a 32-bit version of Mesa. But ready to test now
14:04RSpliet: haha, take your time
14:04imirkin_: no! now!
14:05RSpliet: oh... you heard the man^
14:05pmoreau: Grrr... "Error: couldn't find RGB GLX visual or fbconfig"
14:07imirkin_: calim: any opinion on http://patchwork.freedesktop.org/patch/48063/ ? (there's an additional if (dnz) bail case i had to add)
14:12pmoreau: Meh... What's wrong with my installation... It used to work...
14:13calim: imirkin: yes - unigine is an idiot
14:13imirkin_: calim: duly noted ;) any harm in sticking ftz all over the place though?
14:14calim: hm, I think compute shaders shouldn't use ftz
14:14imirkin_: yeah, i had that thought as well
14:14imirkin_: however that's not very well expressed right now, and as compute isn't actually supported...
14:14imirkin_: i can condition it on a stage != compute thing though
14:15calim: hm, why don't you need ftz if the source instruction already had one ?
14:15imirkin_: then the value can't be a denorm?
14:15calim: hm, does it flush the result, too ?
14:15imirkin_: well non-denorm op non-denorm -> non-denorm
14:15imirkin_: at least for those ops...
14:16imirkin_: add, mul, cov...
14:16calim: wasn't denorm something like very small ?
14:16imirkin_: i actually have no real idea what it is ;)
14:16calim: so, mul small * small can be very small
14:16imirkin_: there's also a "dnz"
14:16imirkin_: i thought denorm was "non-normalized floating point value"
14:16calim: dnz treats inf and nan as 0 I think
14:17calim: I think it's floats where the implicit bit is not 1
14:17imirkin_: right... and can that ever happen as a result of an op?
14:18calim: usually, a float is 1.m * 2^e
14:18calim: and then denormal floats are those with leading zeroes, 0.m * 2^e
14:18calim: which is used for e = small
14:18imirkin_: which is illegal, no?
14:19calim: err, e = the smallest
14:19calim: i.e. 0 - bias
14:20imirkin_: but can an operation actually produce such a thing?
14:20calim: which actually means 1 - bias, but the value is 0 to indicate leading zeros
14:20imirkin_: without bit manipulation
14:20imirkin_: or other shenanigans
14:20calim: 1*2^-127 * 1*2^-2 ?
14:20imirkin_: that won't just return 0?
14:20calim: no, 0.01*2^-127
14:21imirkin_: huh, ok. and so then... why would you want to flush that to 0?
14:21calim: 0.01 being 1/4
14:21calim: to match behaviour of old GPUs that didn't do denormals
14:22calim: as to why this leads to bugs is, however, the dumb thing
14:22imirkin_: well, the issue here seemed to be much more of one where these things polluted the whole image
14:22imirkin_: it'd be solid white or solid black
14:22calim: perhaps someone compares something with 0
14:22imirkin_: so i thought it was some sort of illegality
14:22calim: and relies on very-small numbers bein g 0
14:22calim: hence, unigine being stupid
14:23imirkin_: so... is this safe to do in all non-compute shaders?
14:23imirkin_: i guess i'll drop the op check
14:23calim: my preferred reaction is "fuck unigine, I shall pretend my card doesn't have ftz"
14:24imirkin_: fwiw nvidia sticks ftz all over the place
14:24calim: I know, they can't afford being assholes
14:25calim: hm, wait ... hehe
14:25imirkin_: well, i don't like having random bugs in games either
14:25imirkin_: despite those games being the ones who are assholes
14:25imirkin_: like michael bolton :)
14:26imirkin_: why should i change? he's the asshole!
14:26calim: yes, yes ... we want to make users happy
14:26calim: so we should add all sorts of hacks to make stuff work
14:27mupuf: calim: speaking of this, the option parsing in drirc really needs to be re-worked
14:28mupuf: I should get back to it, hopefully before the summer :)
14:28imirkin_: calim: anyways, thanks for the insight
14:28imirkin_: i'll simplify it to always drop the ftz in and forget about it
14:30pmoreau: RSpliet: Finally got the userspace to work again, gonna test Portal now :)
14:31RSpliet: oh good!
14:35pmoreau: Now it's Steam that doesn't find my installed games... :(
14:43pmoreau: RSpliet: Up from 10fps at level 03, to 20fps at level 05. :-)
14:43RSpliet: that's a start
14:43pmoreau: But trying level 0e just caused a hard lockup and a strange pattern on screen
14:44imirkin_: that's a finish
14:44RSpliet: apparently Mupuf is (a) Fin(n)ish now too
14:44imirkin_: "strange pattern on screen" == "link training fail"
14:44RSpliet: imirkin_: to the best of my knowledge there is no link training
14:44imirkin_: did i say "link training"?
14:44imirkin_: i geuss so
14:44imirkin_: what i really meant was
14:45imirkin_: "memory timing/etc configuration fail"
14:45RSpliet: "some random parameter fail" yes :-P
14:45RSpliet: pmoreau: not entirely unexpected though... but too bad :-)
14:45imirkin_: well... specifically memory
14:45pmoreau: I have the debug messages you're outputing if you want
14:45imirkin_: as opposed to, say, engine
14:47pmoreau: Ah, no, it's from the previous level change :/
14:49RSpliet: don't worry about it
14:51pmoreau: Interesting, moving from level 05 to 03 only yields a 6min bonus in battery life Oo
14:54pmoreau: And with level 0f I get a black screen, but no lockup, and switching back to level 03 the screen is back
14:55pmoreau: (I had Portal running while I changed the values previously, now I'm just running in console mode)
14:57mupuf: pmoreau: the power consumption is cubic with the voltage and cubic with frequency on nvidia cards
14:58mupuf: so, at some point, the difference is only worth it when truly idle
14:58mupuf: power gating would help a lot in this scenario
14:58mupuf: and it is overly complicated :s
14:58imirkin_: we don't enable clock gating by default iirc...
14:59mupuf: well, it is whatever state the bios left it
14:59mupuf: there is still something I am missing for clock gating
14:59mupuf: as for power gating, I would need to have a look at what pdaemon does
15:00mupuf: anyway, time to sleep
15:00mupuf: see you!
15:01imirkin_: no pdaemon on G96
15:01mupuf: imirkin_: right, this one may be easy to RE
15:01mupuf: looking at traces
15:02pmoreau: There should be a trace in mmio.dumps if you have time to look at it
15:03hakzsam: mupuf, don't forget to plug the c8 before going to sleep, please :)
15:03mupuf: hakzsam: done
15:03hakzsam: nice, thanks!
15:04mupuf: imirkin_: sorry, can't plug the e6 and c8 at the same time
15:05mupuf: hakzsam: tell me when you are done. If i am still awake, I will plug back the e6
15:08imirkin_: hehe ok
15:13hakzsam: mupuf, done
15:28mupuf: hakzsam: ok, changing it
15:29imirkin_: mupuf: awesome. will do some tracing tonight to see what buffer i'm forgetting to set/allocate/whatever
15:29mupuf: imirkin_: great, plugged
15:29mupuf: I will set the boot to the normal distro
15:30imirkin_: i just need nvidia to load
15:30imirkin_: i guess you reinstalled the box btw? my user was gone
15:30imirkin_: (but you kept my dir -- thanks)
15:30mupuf: nope, it was just the blob distro
15:30mupuf: the other is in /dev/sda2
15:31mupuf: I made it boot to this distro for hakzsam
15:39mupuf: imirkin_: and the home is shared, hence why your data was still there
15:40imirkin_: ah :)
15:43hakzsam: imirkin_, mupuf could you show me the output of nvascan 120074 and 408850 on the e6?
15:43imirkin_: hakzsam: i can do GK208 if you want
15:44hakzsam: yes, please
15:44imirkin_: doesn't scan take 2 args?
15:44hakzsam: not sure
15:44hakzsam: the second arg is the size I guess
15:44imirkin_: GK208: 120074: 00000001 00000001 00000001
15:45imirkin_: GK208: 408850: 00000004 0000000f 00000000 *
15:46imirkin_: (this is with nouveau btw, in case it matters)
15:47hakzsam: it doesn't matter :)
15:48hakzsam: well, time to sleep for me too, see you
15:49imirkin_: see ya
16:33a1fa: imirkin_: yellow
16:34a1fa: just saying hi
16:34a1fa: saw your comment on phoronix this afternoon...
16:34imirkin_: ah. hi.
16:34a1fa: in re to gtx750
16:38a1fa: im yet to pstate=1 on that old acer aspire revo
16:38imirkin_: your call :)
16:39a1fa: its cold out there :)
16:39a1fa: 60F at the moment
16:39a1fa: if not less
16:41imirkin_: i won't bother asking why a computer you want to play videos on is in the garage
16:41a1fa: youtube has got a bunch of good wrenching turtorial video
16:42imirkin_: ah :)
16:42a1fa: and its got a good selection of music
16:43imirkin_: mupuf: hmmm.... actually that mem_out_of_bounds thing appears to happen in the exact same way as some of the non-tess-related things... when you try to read an input you're not supposed to
16:44imirkin_: mupuf: probably some linkage fail between tcs and tess... might explain the blue things. and we don't get that error on fermi for the other shaders either
23:18pmoreau: RSpliet: Btw, here is the patch I applied to get it compiling: https://phabricator.pmoreau.org/F5736
23:20imirkin: why did you need pfb so badly?
23:21imirkin: oh, for nvkm_gpio?
23:25pmoreau: I couldn't find a way to access gpio solely from hwseq
23:26imirkin: it didn't work with just passing it in? maybe it's not an object...
23:27imirkin: i.e. nvkm_gpio(hwsq)
23:28mupuf: imirkin: good to know :)
23:29imirkin: mupuf: i didn't end up tracing on the e6
23:29mupuf: well, I'm not going to touch reator in the next few days
23:29mupuf: Finland is going to be partying waaaaayyyy too much
23:31pmoreau: What for? 1 May?
23:33mupuf: pmoreau: yep, the day before and the day after too
23:34pmoreau: Ok. Are the universities doing some cortèges on Thursay?
23:38hakzsam: pmoreau, it's the national day :)
23:39pmoreau: hakzsam: Oh really, I didn't know!
23:46mupuf: pmoreau: actually, it is not
23:46mupuf: hakzsam: sorry for misleading you
23:48pmoreau: Oh well, the important thing to remember is that they're partying ;)