[01:52] <EphraimMB> How do I start contributing by developing and improving Ubuntu on Windows 10?
[04:22] <pitti> Good morning
[05:51]  * Laney is in pitti time
[05:52] <pitti> hey Laney, how are you?
[05:52] <pitti> Laney: almost, I've been up since 6 already :)
[05:54] <Laney> pitti: I was up at 0545 but had to cycle to the 0630 train ;-)
[05:54] <Laney> it was still dark at that time, scary
[05:54] <pitti> wow
[05:54] <Laney> feeling surprisingly ok so far though!
[05:54] <pitti> yeah, no nice long summer evenings/early mornings any more :(
[05:55] <pitti> Laney: it gets much easier after some time -- I never actually use an alarm clock, I just wake up at 6
[05:59] <Laney> I'd probably do it if Rosie was on an early schedule
[05:59]  * Laney zones out until arriving at London
[06:01] <didrocks> good morning
[06:08] <Laney> hey didrocks!
[06:09] <didrocks> good morning early Laney :)
[06:09] <didrocks> in the train ?
[06:09] <Laney> yeah
[06:09] <didrocks> nice! Say hi to everyone I know in Bluefinn :)
[06:11] <Laney> surrounded by suits
[06:12] <didrocks> ahah, London man, London…
[06:12] <didrocks> hide hide
[06:23] <pitti> bonjour didrocks ! autant tard aujourd'hui ?
[06:23] <pitti> es-tu allé courier le matin ?
[06:23] <pitti> "tant tard"?
[06:23] <darkxst> hey pitti Laney didrocks
[06:28] <didrocks> pitti: oui, j'ai eu u npeu de mal à me réveiller :)
[06:28] <didrocks> pitti: "si tard"
[06:28] <didrocks> un peu*
[06:28] <didrocks> good evening darkxst
[06:28] <didrocks> pitti: pas encore allé courir, je vais essayer avant midi :)
[06:29] <pitti> didrocks: I wanted to say "so late"; "si tard" -> "if late"?
[06:29] <didrocks> pitti: so late -> si tard ;)
[06:29] <didrocks> si can be "tellement"
[06:29] <pitti> didrocks: uh, get well soon! debflu?
[06:30] <didrocks> pitti: hum, wrong channel? never told I was sick :)
[06:30] <didrocks> pitti: for instance "tu es si maigre"
[06:31] <darkxst> I seem to have ozflu ;(
[06:32] <didrocks> darkxst: how many people to such events?
[06:32] <didrocks> darkxst: get better ;)
[06:33] <darkxst> I suppose I caught it at my shed party friday night, but there was only a dozen people there!
[06:34] <pitti> didrocks: maigre> oui, je sais, mais je ne peux pas obtenier plus lourd :)
[06:34] <didrocks> :)
[06:34] <didrocks> darkxst: that's even still to get sick :p
[06:37] <darkxst> yeh, and I suppose it was worth it, even if it was just to see our crazy dogs that hate every stranger loving the party, and going to strangers for pats!
[06:38] <didrocks> heh
[06:39] <darkxst> now onto making them like the chickens, but was too sick to get them this week
[06:44] <didrocks> pitti: any idea to do some effective file replacement? (without copying the whole file, but with inline?) I have a big file (1G), and I want to strip anything before a certain tag.
[06:44] <didrocks> pitti: so doing somthing similar to awk '/^__ARCHIVE_BEGINS_HERE__/ {print NR + 1; exit 0; }'
[06:45] <didrocks> and then tail -n+${ARCHIVE}
[06:45] <pitti> didrocks: hm, stripping anything after is a simple truncate(), but for "before" you need to rewrite the file anyway
[06:45] <didrocks> (with that result)
[06:45] <pitti> i. e. I don't think you can do it inline
[06:45] <didrocks> so I guess the magic fileinput?
[06:45] <pitti> didrocks: in python or shell?
[06:46] <didrocks> pitti: preferably in python
[06:46] <pitti> didrocks: grep -A100000000000000000 '/^__ARCHIVE_BEGINS_HERE__/' file > file.new; mv file.new file
[06:46] <darkxst> didrocks, python is crap with big files!
[06:46] <pitti> didrocks: I suppose the __ARCHIVE_BEGINS_HERE__/ tag isn't too deep into the file?
[06:47] <pitti> didrocks: so yeah, I'd open the file, iterate over lines until you find the tag (line.startswith()), then move to reading/writing ~ 1 MB blocks with plain .read()/.write()
[06:47] <didrocks> pitti: yeah, it's at less than an hundred line
[06:47] <pitti> that should be reasonably efficient, and avoid reading/writing tons of lines (which is horribly expensive)
[06:48] <pitti> didrocks: oh wait, lines -- you really want binary mode there
[06:49] <pitti> ah, that's fine, "for line in f:" works with binary files too (you get lines as bytearrays)
[06:49] <pitti> just use "if line.startswith(b'foo')) then
[06:49] <pitti> darkxst: really? that should be pretty much I/O bound
[06:49] <didrocks> so, opening it in binary mode, starting to read the tag (line.startswith(b'tag')) and once found, just switch to read/write by 1MB size?
[06:49] <pitti> didrocks: yeah, or 4 MB even
[06:50] <pitti> didrocks: or even easier -- shutil.copyfileobj() :)
[06:52] <didrocks> seriously? shutil really has a tool for everything :)
[06:52]  * didrocks looks
[06:52] <pitti> which probably isn't much more than just a read/write loop :)
[06:52] <didrocks> yep
[06:53] <darkxst> pitti, maybe it was matplotlib bound in my case, could be better just streaming strings
[06:53] <didrocks> ok, and seems the length parameter isn't really needed by default, it will read in chunks as suited
[06:53] <pitti> time python3 -c 'import shutil, sys; f = open(sys.argv[1], "rb"); g = open(sys.argv[1] + ".new", "wb"); shutil.copyfileobj(f, g, 1048576)' bigfile
[06:53] <pitti> versus
[06:53] <pitti> cp bigfile bigfile.new
[06:53] <pitti> python took 16.5 s, cp 15.2 s, both after echo 3 | sudo tee /proc/sys/vm/drop_caches
[06:53] <pitti> not much difference
[06:54] <pitti> didrocks: what's teh default length?
[06:54] <didrocks> pitti: ahah you're right copyfileobj() is really just a read/write with a "if not buf" protection
[06:54] <didrocks> pitti: 16*1024
[06:54] <pitti> didrocks: ah, 16 kB is pretty small
[06:55] <didrocks> yeah, should probably do 4M
[06:55] <pitti> KiB even
[06:55] <didrocks> ok, let's give it a spin and see the speed here
[06:55] <didrocks> thanks a lot pitti :)
[06:55] <pitti> de rien :)
[06:56] <pitti> didrocks: using 4 MiB of RAM for that doesn't sound unreasonable these days
[06:56] <larsu> good morning!
[06:56] <pitti> larsu: guten Morgen! alles senkrecht?
[06:57] <larsu> pitti, klar! Gestern nem Kumpel geholfen, nach HH umzuziehen. Bei dir?
[06:57] <didrocks> good morning larsu
[06:57] <larsu> hi didrocks! How are you?
[06:58] <pitti> larsu: oh, wow; lots of carrying furniture then? everything fine here, thanks
[06:58] <larsu> pitti, ya. And a looooong drive
[06:58] <pitti> larsu: oh? isn't that just 1.5 hours or so?
[06:59] <larsu> pitti, no, more like 3-3.5
[06:59] <didrocks> larsu: I'm great, thanks, yourself?
[07:00] <larsu> didrocks, great as well. A bit tired from the long drive and move yesterday
[07:00]  * larsu is running gedit 3.16
[07:01] <larsu> I guess I should start using it a bit
[07:01] <didrocks> larsu: nothing broken?
[07:01] <larsu> didrocks, with the move or gedit?
[07:02] <didrocks> larsu: the move ;)
[07:03] <larsu> didrocks, ya, all good :)
[07:03] <larsu> was very smooth
[07:04] <didrocks> pitti: oh, I have another option, I can decompress on the fly just giving the fd (forgot I implemented that in Ubuntu Make), so I can actually avoid the copy, just giving the opened fd (after reading the header) to my decompressor
[07:04] <didrocks> larsu: nice to hear :)
[07:54] <willcooke> Hey cyphermox, how are you?  System76 have asked if we can help them with this:  https://bugs.launchpad.net/system76/+bug/1465396
[07:54] <ubot5> Ubuntu bug 1465396 in syslinux (Ubuntu) "Please provide a signed syslinux-efi for secure-boot enabled systems" [Undecided,New]
[07:55] <willcooke> cyphermox, any ideas on that?  Should I speak to Steve L?
[07:56] <didrocks> morning willcooke
[07:57] <larsu> hi willcooke
[07:57] <willcooke> hey didrocks, ca va?
[07:57] <willcooke> what up larsu
[07:57] <didrocks> willcooke: implementing the Unity 3D support in Make as experimental
[07:58] <seb128> good morning desktopers
[07:58] <willcooke> didrocks, woot!!  Should we have a chat with them as well?  So we're all in sync?
[07:59] <didrocks> willcooke: waiting for having the first prototype, and then, yeah, poking popey :)
[08:02] <larsu> willcooke, good good, thanks. You?
[08:02] <larsu> hi seb128!
[08:02] <larsu> did you give gedit a spin?
[08:02] <seb128> hey larsu
[08:02]  * larsu is about to upload a version with a menubar
[08:03] <seb128> yes, seems to work fine
[08:03] <seb128> did you notice that the win is black for a second before displaying content?
[08:03] <seb128> I wonder if that has to do with csd as well
[08:04] <larsu> seb128, indeed. Not sure
[08:04] <larsu> it's only a very short flash for me
[08:05] <larsu> update pushed
[08:06] <popey> didrocks: \o/
[08:11] <Laney> PHEW
[08:11] <Laney> I MADE IT
[08:11] <seb128> larsu, your box is a new one, I'm on the the slow inspiron testbox
[08:11] <seb128> hey Laney :-)
[08:12] <larsu> Laney!
[08:12] <larsu> how was the trip?
[08:12] <Laney> suitful
[08:12] <larsu> haha
[08:12] <larsu> seb128, I blame compiz
[08:12] <larsu> (for no reason)
[08:12] <seb128> :-)
[08:13] <Laney> but I took a bike from the train station
[08:13] <seb128> when in doubt, blame compiz?
[08:13] <Laney> which was...
[08:13] <Laney> ya
[08:13] <seb128> we can't do that anymore, we own compiz now :p
[08:13] <larsu> let's wait for mark's ok before landing this
[08:13] <seb128> Trreeeviiinho
[08:15] <didrocks> argh, failure from tarfile python stdlib
[08:15] <didrocks> If fileobj is specified, it is used as an alternative to a file object opened for name. It is supposed to be at position 0.
[08:15] <didrocks> I don't want it to be at position 0 :/
[08:15] <didrocks> pitti: so I guess I'll have to copy in a new file ^ :/
[08:15] <didrocks> (sad face)
[08:16] <pitti> didrocks: meh :(
[08:16] <pitti> didrocks: I thought you needed to uncompress it first
[08:17] <didrocks> pitti: tarfile would uncompress it
[08:17] <didrocks> and my internal API accepts a fd, so I was just thinking:
[08:17] <pitti> didrocks: i. e. if you hand over the (non-zero) fd to GZipFile  first, and then the gzip fd to tarfile it might work?
[08:17] <didrocks> "skip the head", give the opened fd to tarfile
[08:17] <didrocks> pitti: I'm using tarfile to directly, which uncompress
[08:17] <pitti> i. e. the analog of "tar xz -" → "gzip -cd - | tar x -"
[08:18] <didrocks> I can maybe try to do GZipFile first, then tarfile
[08:18] <pitti> didrocks: right, but you could let gzip do that separately
[08:20] <didrocks> pitti: but, then, I'll get a bytearray loaded in memory of my program of the unzipped content tar?
[08:21] <pitti> didrocks: no, gzip also decompresses in chunks
[08:21] <pitti> i. e. it lazily reads from the compressed fd as you read() from the gzip object
[08:21] <pitti> this is python, pretty much everything fits together well :)
[08:22]  * didrocks gives a try
[08:23] <pitti> didrocks: I mean "gzip" the py module, although it's of course equally true for the program
[08:24] <pitti> didrocks: if all else fails, just determine the offset and systemd.check_call('dd ofs=NNNN bs=4M %(file)s | tar -C %(destdir)s -x -', shell=True) or something such :)
[08:24] <pitti> didrocks: sorry, ifs= of course
[08:24] <pitti> but the above should actually pretty much do the same
[08:27] <didrocks> pitti: argh, tarinfo tries to look at the file format, see that it's supposed to be a gziped file and bail out
[08:28] <didrocks> pitti: just got something like that: http://paste.ubuntu.com/12204312/
[08:28] <didrocks> annoying that it's doing that check, and seek(0) for direct usage I guess :/
[08:29] <pitti> didrocks: why, can't you open it in "r:" mode to avoid the transparent compression check?
[08:29] <pitti> didrocks: ah yes, mode "r" (auto-detect) is the default -- use r:
[08:30] <pitti> didrocks: maybe 'r:gz' even works without the seek / "be at pos 0" requirement?
[08:30] <didrocks> pitti: I'm sending different kinds of file generically to this class, let me try that for prototyping still :)
[08:31] <pitti> didrocks: "fd = new_fd": I'd seriously recommend using gz_fd and tar_fd to avoid confusion
[08:31] <didrocks> interesting, mode "r:" still does this check
[08:31] <pitti> and also to avoid premature auto-closing
[08:31] <didrocks> pitti: it's just for testing, of course I would use with context and such in real code :p
[08:32] <didrocks> (the real code is in between multiple try/exec)
[08:33] <didrocks> yeah, so mode="r:" really insist in the gzip format
[08:34] <pitti> 'r: 'Open for reading exclusively without compression.
[08:34] <pitti> didrocks: wow, so you found a bug in tarfile
[08:34] <didrocks> pitti: second one for the record :)
[08:34] <didrocks> the first one is still "fix in progress" for a year or so
[08:35] <pitti> didrocks: did you try the "r|" mode? ("For special purposes, there is a second format for mode...")
[08:35] <pitti> I've never tried that
[08:35] <pitti> but it doesn't seek and stuff
[08:36] <pitti> "Use this variant in combination with e.g. sys.stdin, a socket file object or a tape device."
[08:37] <didrocks> pitti: ahah, good catch!
[08:37]  * didrocks looks first with a traditional .gz file
[08:37] <pitti> didrocks: right, "r|gz" sounds promising too
[08:38] <didrocks> or even "r|*"
[08:38] <didrocks> so that I don't regress existing behavior :)
[08:38] <pitti> *nod*
[08:38] <pitti> so | vs. : is mostly just "don't seek dammit, I know what I'm doing"
[08:38] <pitti> and I suppose pretty much the only thing that works is extractall(), no individual .extract()
[08:39] <pitti> but one really doesn't want to seek() in a gzipped file anyway, it'll kill you
[08:40] <didrocks> pitti: \o/
[08:40]  * didrocks hugs pitti
[08:40]  * pitti te donne une accolade en retour
[08:40] <didrocks> works perfectly and avoided a 1GiB copy!
[08:41] <didrocks> and still backward compatible with my other frameworks ;)
[08:44] <didrocks> should I exit or quit? http://people.canonical.com/~didrocks/tmp/exitquit.png
[08:44] <didrocks> popey: you maybe want to bring that to our unity3d friends :)
[08:45] <pitti> didrocks: choose wisely!
[08:45] <didrocks> heh
[08:45] <pitti> didrocks: but please don't quit!
[08:45] <didrocks> heh
[08:45] <didrocks> pitti: I tried both, no cookies or surprises saddly :p
[08:45] <popey> there is a bug reporting process for unity3d
[08:46] <popey> http://unity3d.com/unity/qa/bug-reporting
[08:46] <didrocks> popey: let me look at what they want for the linux version, I guess there is a tag
[08:46] <popey> they have a tool which catches crashes too
[08:46] <popey> (used it this morning)
[08:59] <darkxst> Laney, how does spam get though devel-permissions list?
[09:05] <Laney> darkxst: it's an open list
[09:05] <Laney> report it to rt@ubuntu.com (or whatever it is) and ask them to remove/improve the filter
[09:06] <Laney> lots of stuff gets moderated and I kill it then
[09:18] <Fudge> evening folks
[09:27] <darkxst> Laney, too sick for that, will try eat dinner and then sleep
[09:27] <Laney> try Debian lists if you like spam :P
[09:28] <darkxst> I have them off to their own folder, but more for the debian spam
[09:28] <darkxst> pkg-gnome gets all of it
[09:37] <mpt> larsu, “goes all mpt on them”? *blush*
[09:37] <larsu> mpt, I only found 4 apps or so. Sure you would have made a list of 20 ;)
[09:38] <mpt> Calling a saved document “Unsaved Document” is like opening a second document window in exactly the same place on screen as the first one
[09:38] <mpt> Incredibly easy for the developer to do, and also THE WORST POSSIBLE CHOICE
[09:39] <larsu> ya... I said as much on the original bug report
[09:39] <larsu> and in fact, changing it to "Untitled Document" is very easy for the developer as well
[09:39] <mpt> (Well, maybe “This Document Will Self-Destruct in Ten Seconds” would be slightly worse)
[09:39] <larsu> (and a bit harder for translators)
[09:39] <larsu> haha
[09:40] <larsu> mpt, for the record, it hasn't been like this in ubuntu since 2009
[09:40] <larsu> it's "Untitled Document"
[09:40] <mpt> Yes, I read the upstream bug report :-)
[09:41] <larsu> of course you did :)
[09:41] <larsu> feel free to weigh in if you have more arguments
[09:41] <larsu> but really, this should be a no-brainer
[09:41] <larsu> srsly
[09:43] <Laney> push it!
[09:43]  * larsu has bad experience with just pushing stuff
[09:43] <Laney> also, go reply to $gnome_sysadmin_whose_name_i_forgot and vouch for me
[09:43] <Laney> please :)
[09:44] <larsu> Laney, nobody asked me?!
[09:44] <Laney> he said he did
[09:44] <larsu> andrea probably?
[09:44] <larsu> nope
[09:44] <larsu> I would have answered immediately!
[09:44] <larsu> FROM HOLIDAYS
[09:44] <larsu> FROM THE BEACH
[09:44] <larsu> you know?!
[09:44] <Laney> yeah
[09:44] <Laney> fwding
[09:44] <Laney> DONE
[09:45] <larsu> didn't get a mail from him
[09:46] <Laney> well maybe you can reply to this one or something :/
[09:48] <larsu> pinged him
[09:48] <Laney> ♥
[09:49] <larsu> ➹
[10:37] <larsu> Trevinho, hey! Where do the designs for your scrollbars come from?
[10:37] <larsu> Trevinho, thanks for working on this
[10:38] <Trevinho> larsu: hey
[10:38] <Trevinho> larsu: well... my head :P
[10:39] <Trevinho> larsu: no, joking... I just tried to make them look more like the old ones
[10:40] <larsu> Trevinho, ah - the description sounds like there's a new design
[10:40] <seb128> florian just said he got the new scrollbar design I think, need to ask him for details
[10:40] <Trevinho> larsu: I tried to get the slider track to show only when needed (https://transfer.sh/YLymC/out-19.ogv), but at part it needs a change in gtk, I'm not sure I like it in this way (at least it would need some transitions, which - for some reason -doesn't work)
[10:40] <seb128> well that's for unity8/uitk
[10:40] <larsu> Trevinho, I think there's one coming up. Can you follow up with design please?
[10:40] <seb128> but I guess that could help for unity7 as well
[10:41] <Trevinho> ah, ok... well I'm not sure we want to implement the new design in u7, just keeping the old one
[10:41] <larsu> Trevinho, yeah I tried it as well with the same conclusion :)
[10:41] <larsu> seb128, we want something similar no? Convergence in all dimensions!
[10:41] <Trevinho> larsu: I can send the patch however...
[10:41] <seb128> larsu, right
[10:41] <larsu> Trevinho, send which patch to where?
[10:42] <Trevinho> larsu: not sure. ask willcooke also. We had a similar discussion for the launcher look
[10:42] <Trevinho> larsu: to allow to theme the track independently from the slider when on-hover...
[10:43] <larsu> Trevinho, let's only do that if we actually end up needing it
[10:43] <Trevinho> larsu: also, wondering why most of the numbers in gtkscrolledwindow are hardcoded (such as the proximity)... And probably even with hidpi in mind.
[10:43] <Trevinho> without*
[10:43] <larsu> Trevinho, they're logical pixel values, which work in hidpi as well
[10:43] <larsu> Trevinho, what else? A setting?
[10:44] <larsu> I don't think that's the kind of thing people want to change
[10:44] <Trevinho> larsu: yeah, at theme level
[10:44] <Trevinho> Or disable the fact they are hidden/shown... Or the fade-in/out timings
[10:44] <Trevinho> all these things should be themable imho
[10:46] <larsu> Trevinho, could be, yeah :)
[10:54] <willcooke> larsu, Trevinho - Just spoke to Design, they will have some visuals for us next week
[10:54] <larsu> nice! Thanks willcooke
[10:54] <Trevinho> Mh, ok
[10:55] <willcooke> The new U8 scroll bars look similar, but are not functionally the same - so we'll need to style ours to look close to what they have in U8 so that Gtk apps in U8 look the same.
[10:56] <willcooke> *the same as the Gtk ones
[10:56] <Trevinho> mh
[10:56] <willcooke> urgh that was a mess, let me try again...
[10:56] <willcooke> Design will give us some visuals for the new overlay scroll bars in U7 desktop.
[10:56] <willcooke> Trevinho, what's the issue?
[10:56] <Trevinho> the fact is that even dash scrollbars should match these, so... I would love to avoid to redo stuff :)
[10:57] <Trevinho> Anyway, I guess that gtk apps in u8 would need a new theme anyway, isnt' it?
[10:59] <larsu> yes, they will
[10:59] <Trevinho> So, if we keep the X11 desktop with a slightly different look (as it used to be + some improvements), we can still try to emulate the old designs as much as we can
[10:59] <larsu> and really I'd like to move towards that in unity7 and all
[10:59] <larsu> so that we have *some* new stuff on the desktop the coming cycles
[11:00] <larsu> Trevinho, why? Let's show that we're working towards the new stuff
[11:00] <Trevinho> larsu: yeah, it's just that if they're also functionally different, maybe there's something more to do
[11:01] <larsu> Trevinho, I don't expect them to be tbh
[11:01] <willcooke> right
[11:01] <willcooke> Trevinho, yeah, we will need to make the dash scroll bars look like these new ones, but there won't be a lot of difference between this and what you have already done
[11:02] <Trevinho> ok good
[11:04] <seb128> robert_ancell, https://bugs.launchpad.net/ubuntu/+source/cairo/+bug/595845
[11:04] <ubot5> Ubuntu bug 595845 in cairo (Ubuntu) "libcairo2 1.9.10 makes Ubuntu 10.10 slow" [Medium,Fix released]
=== MacSlow is now known as MacSlow|lunch
=== alan_g is now known as alan_g|lunch
[12:35] <cyphermox> willcooke: you should talk to slangasek about it
[12:41] <willcooke> thx cyphermox
[13:04] <seb128> attente, https://bugs.freedesktop.org/show_bug.cgi?id=88584
[13:04] <ubot5> Freedesktop bug 88584 in Driver/intel "[ilk] Font and screen corruption in GTK+ applications" [Major,New]
=== alan_g|lunch is now known as alan_g
[13:25] <pitti> Laney: do you plan to update dbus to 1.10.0 to get to the stable release?
[13:26] <pitti> Laney: (also, selfish reason: this allegedly allows shipping d-bus policies in /usr/share, getting rid of these pesky conffiles in /etc/)
[13:27] <Laney> pitti: yes
[13:27] <pitti> nice
[13:27] <Laney> 1.9.x should already have this
[13:27] <Laney> feel free to do the merge if you want
[13:28] <pitti> Laney: ah, does it? no /usr/share/dbus-1/system.d/ yet
[13:28] <Laney> I guess we don't ship anything there
[13:29] <Laney> the package doesn't make the directories
[13:29] <pitti> Laney: well, we need to wait until it comes out of experimental anyway
[13:29] <pitti> not going to introduce ubuntu deltas for removing conffiles, but I was curious whether we'll get this <= Debian
[13:29] <pitti> but if we already have it, cool
[13:30] <Laney> we should be able to start doing this for Ubuntu stuff already
[13:30] <pitti> yes
=== MacSlow|lunch is now known as MacSlow
[14:20]  * didrocks relocating to a train, bbl!
[14:20]  * ogra_ wonders if thats a CI train ... and if didier also has a biletto :)
[14:36] <Laney> biltong
[15:40]  * didrocks smells that we are in the train for a long time
[15:40] <didrocks> collision in the train in front of us
[15:40] <didrocks> so, stuck
[15:43] <pitti> didrocks: meh :(
[15:44] <seb128> didrocks, rage quit the train!
[15:50] <didrocks> seb128: well, can't really exit on rails :p
[15:50] <Trevinho> about to leave... China is waiting me
[15:52] <seb128> Trevinho, safe trip!
[15:56] <Trevinho> seb128: thanks
[16:28]  * didrocks will save battery by not thethering, still stuck in the train, we'll see! Anyway, have a good week-end everyone!
=== alan_g is now known as alan_g|EOD
[19:01] <mdeslaur> How do I turn off gtk overlay scrollbars for a particular window?
[19:03] <mdeslaur> I tried gtk_scrolled_window_set_overlay_scrolling () but it just makes the scrollbars go away completely
[19:35] <hikiko> hello from paris
[19:48] <qengho> salut
=== howefield_afk is now known as howefield
=== howefield is now known as howefield_afk