IRC logs for #openttd on OFTC at 2008-07-24
⏴ go to previous day
00:15:41 <nicfer> that opengfxpack only has got 10 files
00:33:59 *** Eddi|zuHause3 has joined #openttd
00:40:51 *** Osai is now known as Osai^zZz
00:44:21 <nicfer> any chances to split newterrain into normal opengfx and opengfx+?
00:49:28 <Eddi|zuHause3> i have absolutely no clue what any of your questions mean...
00:49:57 <Yexo> nicfer: As I said before, you're better of asking those question in the openttd graphic sections of tt-forums.net
01:04:29 <nicfer> why openttd forums doesn't load for me?
01:04:29 <glx> btw terrain will never be an opengfx+ as it doesn't need more than action A
01:07:23 <glx> but they still can be used as static newgrf
01:08:20 <nicfer> that page is about opengfx+
01:08:40 <nicfer> newterrain is in it, so it's opengfx+
01:22:23 <nicfer> newbuildings.grf was detected as unsafe for newgrf-static
01:33:27 <glx> that's ok as it's not a simple replacement
01:35:18 <Lakie> shore lines would be an action5, nicfer?
01:49:33 <nicfer> shore lines not, but that's on newterrain AFAIK
01:50:30 <Lakie> Action 5 type 0D " Coast Tile graphics"
01:50:53 <Lakie> I should know, I designed diagonal flooding
01:51:04 <Eddi|zuHause3> there are different methods for shore graphics replacement
01:51:15 <Lakie> Aye, but for the ones in OpenGFX
01:51:34 <Lakie> Its the action5 as they use lakku's curvy style last I checked
01:53:07 <nicfer> but the one that doesn't load as static is newbuildings
01:53:31 <Lakie> As glx said they aren't simple replacements.
01:53:43 <Lakie> You could replace the graphics with an actionA surely though?
01:54:13 <Lakie> (Assuming you are changing only the graphics)?
02:06:14 <nicfer> but it's mentionated on the opengfx page, not opengfx+'s
02:06:54 <Lakie> I don't know, to be honest.
02:18:34 *** fmauNeko is now known as fmauNekAway
04:42:50 *** gregor_ has joined #openttd
05:31:58 *** bilbous has joined #openttd
05:33:40 <bilbous> hi all, quick question: why do all the transfered product I take to the end destination wind up losing money?
05:35:27 <Ammler> bilbous: with transfer?
05:35:43 <bilbous> ya secondary carrier always is in the red
05:35:48 <Ammler> you got too much for the other transport
05:35:57 <Ammler> so you have to payback a bit :-)
05:36:16 <bilbous> because the first hop is longer?
05:37:02 <bilbous> THat doesn't seem to make sense ;)
05:37:25 <bilbous> Mak more money just sending the cargo to a dead end
05:39:12 <bilbous> Well thanks for the answer Ammler
05:59:25 *** einKarl has joined #openttd
05:59:43 *** [Nemesis] has joined #openttd
06:22:00 *** TiberiusTeng has joined #openttd
06:22:36 <TiberiusTeng> r13810 will trigger access violation in a VC build.
06:23:56 <TiberiusTeng> TarListEntry needs a copy constructor that strdup(filename) ...
06:24:35 <TiberiusTeng> or it will free itself up after being inserted into the map<string,TarListEntry>
06:25:47 <TiberiusTeng> and triggers AV when it tries to access the (now freed) string by a bitwise-copied dangling pointer
06:28:44 *** einKarl_ has joined #openttd
06:42:04 *** Doorslammer has joined #openttd
07:07:47 *** ArmEagle is now known as ArmEagle|CZ
07:13:23 *** wolfy is now known as Wolfensteijn
07:24:22 *** GoneWacko has joined #openttd
07:27:48 *** flowOver has joined #openttd
07:55:40 *** De_Ghost has joined #openttd
07:59:42 *** Osai^zZz is now known as Osai
08:06:11 *** LilDood has joined #openttd
08:07:20 <Rubidium> TiberiusTeng: it shouldn't be copied around anymore; I see no reason why it would need to do it
08:07:59 <Rubidium> and a copy operator doesn't solve the problem anyways; it'll only move it slightly
08:08:48 <TiberiusTeng> typedef std::map<std::string, TarFileListEntry> TarFileList;
08:09:01 <TiberiusTeng> when you insert a TarFileListEntry into TarFileList, it'll be copied ...
08:10:06 <TiberiusTeng> I believe that's why it was TarListEntry *, not TarListEntry
08:11:31 <Rubidium> but... we don't insert a TarListEntry
08:12:02 <Rubidium> or at least, only after the insert the tarlist entry is actually set
08:15:14 <TiberiusTeng> anyway it's triggering Access Violation here on VC2005
08:16:03 <Rubidium> and when the constructor sets the pointer to NULL by default?
08:16:25 <TiberiusTeng> and ... is the original AI broke in recent revisions ? I see them only terraforming around, but not building anything meaningful ...
08:16:59 <Rubidium> it's just enormously stupid that it needs to keep copying it around for absolutely no reason
08:17:41 <Rubidium> TiberiusTeng: the original AI still builds vehicles here
08:19:27 <TiberiusTeng> C++ standard's sometimes strange on these aspects, but it do specify how object instances should be copied on assignment operator, parameter passing etc ...
08:21:44 <Rubidium> TiberiusTeng, the whole problem is: there is NO assignment, there is NO parameter passing, ...
08:22:33 *** Vikthor has joined #openttd
08:23:47 <Rubidium> and the copy operator can't do much good either cause there's no way to tell whether it should free the pointer it contains or not
08:23:54 <TiberiusTeng> the TarList should std::map<std::string, std::string> IMO
08:25:56 <Rubidium> TiberiusTeng: but then the string pointer value changes
08:26:12 <Rubidium> which makes it break on all platforms
08:27:14 <TiberiusTeng> looks like it's just a 'seen list'
08:27:29 <TiberiusTeng> and we should leave all memory managing stuff to std::string ?
08:27:57 <Rubidium> TiberiusTeng: yeah, with other structs having pointers to the strdup-allocated filename
08:28:37 <Rubidium> and if MSVC's map keeps copying stuff around, that strdup-allocated pointer will be long gone before it even is inserted
08:28:54 <TiberiusTeng> it's on the progress of moving to C++ if I get it right
08:33:49 <TiberiusTeng> or you want to stick with good old char * ? Frankly I don't have anything to say about this ...
08:34:32 <Rubidium> well, the piece of code is messy, tried to stop it leaking and apparantly it worked, only MSVC (as usual) can't handle it
08:39:07 <TiberiusTeng> ok I ran it through debugger again
08:39:43 <TiberiusTeng> it AV'd on the way while inserting a new empty TarListEntry into the list
08:40:04 <TiberiusTeng> and apparently the copy operation occured there didn't get optimized out in a debugging build ...
08:40:43 <Rubidium> so it's copying a garbage pointer and then it frees the garbage pointer?
08:40:56 <TiberiusTeng> _Where = this->insert(_Where, value_type(_Keyval, mapped_type()));
08:41:16 <Rubidium> and only after that the pointer is set correctly (which you can't see as it's already crashed)
08:41:31 <TiberiusTeng> the line's in VC STL map, here mapped_type() is TarListEntry
08:41:35 <Rubidium> but that'd mean that adding a default constructor that NULLs the pointer should fix it
08:41:44 <TiberiusTeng> it'll get constructed, passed to insert (a copy operation here) ...
08:41:55 <TiberiusTeng> looks so, I'm trying it now
08:42:44 <TiberiusTeng> yeah, it worked.
08:46:53 <CIA-3> OpenTTD: rubidium * r13814 /trunk/src/tar_type.h:
08:46:53 <CIA-3> OpenTTD: -Fix (r13810): MSVC (as usual) does stupid things. This time it is copying
08:46:53 <CIA-3> OpenTTD: around a struct it created itself, causing bad things to happen if you don't
08:46:53 <CIA-3> OpenTTD: explicitly set all variables to something remotely sane in the constructor.
08:48:56 <TiberiusTeng> but actually I rally think gcc -O0 will crash too
08:53:54 <Rubidium> gcc -O0 without even inlining doesn't crash
09:16:54 *** tom0004 has joined #openttd
09:17:13 *** ChanServ sets mode: +v tokai
09:30:45 <DorpsGek> ln: Bjarni was last seen in #openttd 3 weeks, 0 days, 13 hours, 22 minutes, and 52 seconds ago: <Bjarni> I didn't have any
09:32:07 *** Brianetta has joined #openttd
09:33:18 <ln> ok, i want ferries that can carry trains.
09:33:41 <ln> any questions? good, start coding.
09:39:34 <TiberiusTeng> ahh, NewGRF GUI has added the preset function. another update ~_~
09:40:32 <Ammler> TiberiusTeng: maybe you should make the reset economy optionally then :-)
09:41:33 <TiberiusTeng> I'll try to remember that :P
09:41:55 <ln> where are my train-carrying ferries?
09:42:05 <Ammler> Eddi|zuHause3: would like it that way ;-)
09:49:25 *** lobster_MB has joined #openttd
09:50:40 *** fmauNekAway is now known as fmauNeko
10:00:00 *** stillunknown has joined #openttd
10:28:11 *** Progman has joined #openttd
10:28:47 *** fmauNeko has joined #openttd
10:37:44 <guru3> anyone recon it'd be possible to make a version of openttd that ran entirely in the browser?
10:38:15 <Yorick> but most likely slow as hell
10:38:24 <guru3> ive seen 3d games in the browser
10:38:43 <Rubidium> 3d games are relatively simple
10:39:07 <guru3> still, i twould be cool
10:39:11 <guru3> i could play openttd at work then
10:39:13 <Rubidium> they for sure don't push data around at the rate OpenTTD does, except for the drawing
10:39:29 <Rubidium> why wouldn't you be able to play at work then?
10:39:42 <guru3> tcp connections have a way of mysteriously closing
10:39:55 <guru3> i'm having to ssh via a webapp called anyterm as it is
10:40:13 <guru3> and so i toccured to me that if you can put a 25x80 terminal in a browser, why not openttd
10:40:42 <blathijs> guru3: Running an app in a browser doesn't magically make it use a different protocol
10:41:02 <Yorick> because the terminals are slightly more UFT-8 based and openttd somewhat sprite-based?
10:41:06 <blathijs> guru3: I would say that that browser ssh terminal still uses ssh to communicate
10:41:13 <guru3> no, but i just thought running it win a browser would be cool, portable, and wasy to use
10:41:30 <Yorick> there are some remote-desktop java clients...
10:41:32 <Rubidium> blathijs: it looks like it actually doesn't
10:41:53 <blathijs> guru3: No, to make openttd run in a browser, we would need to make it portable, it wouldn't magically become portable
10:42:06 <blathijs> guru3: Yipes, that's scary
10:42:15 <guru3> i didn't mean portable as in portable to a different platform porting
10:42:16 <blathijs> OTOH, perhaps not as scary as TCP-over-DNS :-)
10:42:19 <guru3> i meant portable as in easy to take a long
10:42:35 <guru3> you wouldn't need to install it
10:42:42 <guru3> you'd just need to open the page to your install of it
10:43:24 <blathijs> guru3: If you put openttd on an USB stick, you can probably get the same result
10:43:48 <Rubidium> TCP-over-DNS is just an awfully brilliant idea ;)
10:43:51 <guru3> i'd need to carry a usb stick
10:44:20 <guru3> arghm can't you just let me enjoy my cool idea
10:46:13 <Yorick> argh...who got the idea of the onunload event
10:46:22 <Yorick> in conjunction with opening the same page again
10:51:43 <blathijs> guru3: Sorry, didn't mean to block your brainstorm :-p
10:53:02 <guru3> np, i can forsee massive technical difficulties, but if we always let those get in our way... i'm sure you can imagine the technilogical level we'd all be at
10:54:36 <guru3> that line needs a ;) after it...
10:57:55 *** Dred_furst has joined #openttd
11:06:05 *** stillunknown has joined #openttd
11:15:34 *** LilDood has joined #openttd
11:19:29 <Yorick> how about sending the framecounter with the game_info packet?
11:20:28 <Rubidium> and the usefullness of that?
11:21:16 <blathijs> game_info packet is de UDP response?
11:21:52 <Yorick> it would be helpful on a correct estimation of the game date
11:22:16 <Rubidium> and how would that algorithm work?
11:22:55 <Yorick> game_date + (framecounter - game_info_framecounter) / 74
11:23:59 <Yorick> the openttd gamedate counts in days, right?
11:24:20 <Yorick> one game day is 74 frames
11:24:43 <Yorick> I could use that to calculate the game days at all times...
11:25:04 <Rubidium> not correctly at least
11:25:08 <Yorick> assuming I have a start-position and take pauses into account
11:26:00 <Rubidium> framecounter can start at any moment in a day
11:26:20 <Rubidium> so if you get the game info in the half of a day, it's already 37 too much (or too few)
11:29:20 <Rubidium> and how do you count the framecounter for the "correct" game date?
11:33:14 <Yorick> Rubidium: hmm...I think I'll request the date as soon as I'm in the game
11:33:37 <Yorick> and use the PACKET_SERVER_FRAME for the frame-counting
11:34:08 <Yorick> also...I'll use something to floor it
11:34:39 <ln> Yorick: do grfs have ferries that can carry trains and road vehicles?
11:35:25 <Rubidium> it does if you do s/mail/road vehicle/g;s/passenger/train/g
11:56:30 <Progman> you are an interpreted programming language? ;)
11:58:19 <dih> i thought bots were more intelligent than that :-P
12:11:37 *** Zealotus has joined #openttd
12:17:08 <SmatZ> any native English spearker here for a little question? :)
12:18:22 <SmatZ> my question is not about "wagon" x "waggon"
12:18:57 <SmatZ> is it allowed to say "Your behaviour is likely to cause problems" ?
12:19:57 <DorpsGek> SmatZ: Bloody was last seen in #openttd 1 week, 0 days, 21 hours, 38 minutes, and 2 seconds ago: <Bloody> :(
12:20:25 <ln> syntactically: yes, semantically: yes, pragmatically: unknown
12:22:00 <planetmaker> [14:18] <SmatZ> is it allowed to say "Your behaviour is likely to cause problems" ? <-- though not native speaker, it looks to me like a correct sentence by all means.
12:22:24 <SmatZ> ln: planetmaker: ok thanks :)
12:23:37 <Yorick> depends on who you are speaking to, if the content is also correct
12:24:29 <planetmaker> which depends heavily upon the definition of "problem".
12:27:30 <Yorick> "/* Converted from an ingame table by WizKid */" <-- now is it converted by WizKid, or is the ingame table made by WIzKid?
12:29:14 <Yorick> it's the OTTD_month_date_from_year_day table, btw
12:30:01 *** Singaporekid has joined #openttd
12:31:46 <rortom> also 120 seconds are too long
12:32:29 <rortom> the bot desyncs if the net_freq_value is changed
12:32:43 <rortom> stats update interval now 90 sec
12:32:53 <Yorick> 1.you're talking in #openttd, 2. the bot can't desync, I think
12:46:48 *** grumbel has joined #openttd
12:57:47 *** Klanticus has joined #openttd
12:59:06 *** DJNekkid has joined #openttd
13:38:44 <CIA-3> OpenTTD: truebrain * r13815 /branches/noai/src/ai/api/ai_controller.cpp: [NoAI] -Fix: minor corrections in AIController (Yexo)
14:25:10 *** LilDood has joined #openttd
14:52:51 <Yorick> hmm, is ● a real *, or is it a part of my password?
14:53:42 *** Dred_furst has joined #openttd
14:56:31 <Eddi|zuHause3> SmatZ: does your client also mask your passwords with ● when you type it?
14:56:47 <Eddi|zuHause3> like when i type ●●●●●● it comes out as ●●●●●●?
14:58:14 <SmatZ> [16:57:33] <Yorick> SmatZ>●●●●●●●
14:58:26 <Yorick> ah, because it's your password :)
15:06:32 *** frosch123 has joined #openttd
15:11:44 <planetmaker> lol. People reading too mach bash.org :P
15:12:29 <planetmaker> :) I was only told ;)
15:16:12 *** planetmaker is now known as pm|away
15:17:06 *** pm|away is now known as planetmaker
15:19:39 <CIA-3> OpenTTD: smatz * r13816 /trunk/ (12 files in 3 dirs): -Fix [FS#2150]: check for vehicle length changes outside a depot (callback 0x11) and give a warning about that
15:21:18 *** Progman has joined #openttd
16:11:02 *** plakkertjes has joined #openttd
16:15:03 <dyzdyz> i don't know how to compile openttd with copy-paste patch under Debian
16:15:27 <dyzdyz> i can compile it without patch with no problems
16:15:57 <dyzdyz> where should *.patch file be located?
16:15:58 <Yorick> what don't you know then?
16:16:10 <Yorick> just in the directory you're compiling it in
16:16:17 <glx> put .patch where you want
16:16:34 <glx> you just need to apply it before compiling
16:16:40 <Yorick> patch -p0 -i "/dir/to/your/patch/file.patch"
16:16:59 <dyzdyz> oh, i didn't know that
16:21:45 <Eddi|zuHause3> <Ammler> Eddi|zuHause3: would like it that way ;-) <- ???
16:21:59 <Eddi|zuHause3> what do i have to do with ferries?
16:23:14 <dyzdyz> ok, i've got it compiled
16:23:37 <dyzdyz> how to check it? is there anything i neet to change in openttd.cfg?
16:24:08 <CIA-3> OpenTTD: smatz * r13817 /trunk/src/train_cmd.cpp: -Cleanup (r13816): no need to check for ENABLE_NETWORK, _networking is defined anyway
16:24:08 <dyzdyz> can i use my saved game?
16:27:40 <dyzdyz> no such file... but when i just run "openttd" game starts, but i think it's version from "deb" package
16:28:01 <Eddi|zuHause3> "make run" is the command ;)
16:28:13 <Yorick> how exactly are you compiling?
16:28:23 <nicfer> hmmm could I make an update to the opengfx all in one pak+
16:28:42 <dyzdyz> 1. patch -p0 -i "copypaste.patch"
16:29:21 <Yorick> leave the make install
16:29:29 <Yorick> I don't think you need it
16:30:02 <Yorick> ./configure && make && cd bin && ./openttd
16:30:15 <Rubidium> ./configure && make run
16:30:54 <dyzdyz> ok, just need to copy "sample.cat" & others
16:31:57 <Eddi|zuHause3> dyzdyz: put them in ~/.openttd/data
16:31:59 <nicfer> could I zip my updated opengfx files and post it in the forums so people can download it faster?
16:32:11 <Eddi|zuHause3> dyzdyz: then they can be used by every openttd installation
16:37:36 <Eddi|zuHause3> limitation disturbs me very sprites. goes it throw out limitation?
16:43:20 <dyzdyz> i copied files into the "data" dirctory
16:43:58 <dyzdyz> and it look like gameserver starts...
16:44:28 <Yorick> you have SDL installed?
16:45:01 <Eddi|zuHause3> configure will cry if you don't
16:46:16 <Yorick> could you paste the configure and make output to paste.openttd.org?
16:47:41 <Eddi|zuHause3> dyzdyz: no, you need the development version of sdl
16:47:47 <Eddi|zuHause3> not just the runtime version
16:49:34 *** |Jeroen| has joined #openttd
16:49:39 <dyzdyz> another try goes on :-)
16:49:40 <Eddi|zuHause3> now ./configure again
16:50:10 <dyzdyz> checking SDL... found :-)
16:50:59 <Eddi|zuHause3> you should also install the dev versions of the other libraries used... png, freetype, fontconfig...
16:52:17 <dyzdyz> ok, libtmidity is for music?
16:53:00 <dyzdyz> ok, i don't need music
16:53:25 <Yorick> zlib is for savegame compression
16:53:30 <Yorick> you need it to join network games
16:53:54 <dyzdyz> i've got zlib, libpng12-dev...
16:54:01 <dyzdyz> freetype and fontconfig now
16:56:10 <dyzdyz> checking zlib... found... checking libpng... found... checking libfreetype... not found... checking libfontconfig... not found
16:57:21 <dyzdyz> ok, got everything - now compilig
16:58:06 <dyzdyz> i love playing at work :-)
17:01:21 <dyzdyz> now i need to copy my savegames and .cfg
17:01:40 <dyzdyz> are *.grf configuration saved in openttd.cfg?
17:02:28 <nicfer> could I zip my updated opengfx files and post it in the forums so people can download it faster?
17:05:04 <dyzdyz> how to tell my new version of openttd that my saves and cfg are in ~/.openttd ?
17:06:30 <Noldo> there is propably command line option for the config
17:06:33 *** einKarl has joined #openttd
17:07:25 <dyzdyz> i can overwrite it, but where is the new cfg located?
17:08:30 <dyzdyz> i just tried to run it as root
17:08:57 <dyzdyz> thanks for help everyone
17:09:54 *** LilDood has joined #openttd
17:29:38 <glx> nicfer: I think you should ask on the forum as nobody here works won opengfx
17:44:24 <blathijs> glx: Silly graphic artists that don't use IRC :-p
17:45:16 <rortom> also, sneak preview :)
17:46:12 <rortom> its not perfect or anything...
17:47:58 <blathijs> rortom: It generates its own API docs? :-)
17:48:07 <blathijs> rortom: Or just serves them?
18:17:57 *** einKarl has joined #openttd
18:28:28 <jordi> blathijs: I uploaded 0.6.2rc1 to experiemntal
18:29:06 <jordi> blathijs: if 0.6.2 is released during the week, I'm confident it'll be able to slip in, and later on we'll have to fight for 0.6.3
18:29:14 <CIA-3> OpenTTD: peter1138 * r13818 /trunk/src/newgrf_gui.cpp: -Fix [FS#2157]: Deselect currently selected NewGRF when changing GRF preset.
18:29:27 <jordi> which again, will have better chances the sooner it's released the better.
18:30:27 <peter1138> That was the wrong TASK
18:34:18 *** GoneWacko has joined #openttd
18:48:56 *** svippery has joined #openttd
18:51:29 <peter1138> Hmm, autoreplace didn't refit my aRVs :o
18:51:54 <Lakie> I suppose that could be a minor issue, Peter.
18:52:08 <Lakie> Such as them just loading (nothing) for a long time...
18:57:15 <DorpsGek> peter1138: bjarni was last seen in #openttd 3 weeks, 0 days, 22 hours, 49 minutes, and 21 seconds ago: <Bjarni> I didn't have any
18:58:08 <hylje> he still doesn't have any
19:14:27 *** Wezz6400 has joined #openttd
19:19:48 <jordi> blathijs: release people are saying the freeze starts this weekend
19:19:55 <jordi> I don't know when exactly
19:20:04 <jordi> so, let's count on our good luck
19:23:30 <valhallasw> yeah, stable branch, probably
19:23:33 <Rubidium> jordi: but openttd 0.6.x is already in feature freeze for a long time
19:24:23 <jordi> Rubidium: I know, but try to tell the Debian release team.
19:24:44 <jordi> a Debian freeze is really a serious freeze, you need to fight every update
19:25:06 <jordi> although I hope they'll be flexible due to the "network protocol compatibility" argument
19:25:22 <Rubidium> 0.6.2 should be fairly easy to get in
19:25:24 <Prof_Frink> jordi: That's what's powering the LHC cooldown
19:25:34 <Rubidium> due to the nature of the bugs that are fixed
19:25:41 <valhallasw> large hadron collider?
19:25:42 <Prof_Frink> Large Hadron Collider
19:26:00 *** grumbel has joined #openttd
19:26:03 <Prof_Frink> It's within about 3K of absolute zero
19:26:17 <Prof_Frink> And still losing heat the the Debian Freeze
19:27:44 <blathijs> jordi: We'll try to do the release tomorrow
19:28:13 <jordi> blathijs: sounds very convenient
19:28:37 <jordi> I'll see if any autobuilder picks openttd and unveils any build problem
19:28:43 <jordi> in experiemntal, that is
19:29:29 *** lobster_MB has joined #openttd
19:31:52 <jordi> still no experiemntal builds
19:34:20 <Rubidium> it's just that everyone wants his/her packets in right now ;)
19:35:33 *** fmauNeko was kicked by DorpsGek (Wrong channel. Retry in #openttdcoop.)
19:35:45 *** fmauNeko has joined #openttd
19:40:03 <jordi> Rubidium: the release team is being drowned in exception requests already
19:40:47 <jordi> part of Debian was already frozen (toolchain, base system, etc) but tomorrow every other package will enter the freeze and everyone is scrambling to get their latest bits in
19:41:16 <Rubidium> just mail secunia and you'll get a higher place on the list
19:41:28 <jordi> I'm seeing many new versions being uploaded, I suspect it's the same case as this one, Debian maintainers asking their upstream authors to "flush" their SVN changes to a tarball
19:42:58 <Rubidium> the ability to crash servers remotely should be enough to get past the freeze I reckon
19:44:06 <jordi> that's some info I had no news about yet
19:44:10 <jordi> is there a CVE for that?
19:44:28 <Rubidium> not that I'm aware of
19:44:41 <jordi> I guess mitre should be informed
19:45:07 <jordi> also, if that's a vulnerability present in past versions of openttd, a CVE is good so distros patch it
19:45:18 <jordi> it happens with freeciv frequently
19:48:35 <jordi> ah, all previous to Debian inclusion
19:51:20 <rortom> mh RoR has also a debian package laying around somewhere :/
19:54:50 <jordi> rortom: a debian package for what?
20:00:01 <peter1138> Bah, stupid monitor.
20:00:55 <peter1138> It seemed to be non-linear in the X-dimension.
20:01:05 <peter1138> However it has an adjustment for that :o
20:01:27 <peter1138> Unfortunately RoR is not open source :(
20:01:39 <peter1138> And there's no 64 bit Linux version either.
20:02:01 <rortom> we are working on both topics :)
20:02:13 <peter1138> 64 bit support is easy: let me build it ;)
20:02:46 <rortom> my 64 bit buildchain failed under gentoo :(
20:03:47 <peter1138> Oh bollocks, my libasound2-plugins package got updated :(
20:05:46 <jordi> oh I had assumed it was fre
20:06:04 <jordi> peter1138: tell me more about that -plugins package of yours?
20:06:20 <jordi> I'm currently talking about a 1.0.17 update in Debian with another DD on jabber :)
20:06:27 <peter1138> Ubuntu, I'm afraid.
20:06:36 <peter1138> I just compiled it with jackd support...
20:06:49 <peter1138> I don't know if Debian has the same issue.
20:08:07 <jordi> peter1138: arey ou a MOTU?
20:08:25 <jordi> peter1138: we are *very* open to patches of this nature in Debian. Ubuntu will get them for free. :)
20:09:02 <peter1138> The support is there by default, it's just built without the jack dependency.
20:09:38 <peter1138> Annoying as the plugins are built as individual shared libraries, so in theory it could be a separate package.
20:09:40 <jordi> Depends: libasound2 (>> 1.0.16), libavcodec51 (>= 0.svn20080206), libc6 (>= 2.7-1), libdbus-1-3 (>= 1.0.2), libjack0 (>= 0.109.2), libpulse0 (>= 0.9.8), libsamplerate0
20:10:13 <jordi> Build-Depends: autotools-dev, debhelper (>= 6), libasound2-dev (>= 1.0.12), libavcodec-dev, libjack-dev, libpulse-dev, libsamplerate0-dev | libsamplerate-dev, quilt (>= 0.40)
20:10:22 <jordi> yeah, I explicitly build-dep on libjack-dev
20:10:39 <peter1138> Depends: libasound2 (>> 1.0.14), libc6 (>= 2.7-1), libdbus-1-3 (>= 1.1.1), libpulse0 (>= 0.9.8), libsamplerate0
20:10:50 <peter1138> Ubuntu doesn't want any jack dependencies by default, I believe.
20:11:09 <Eddi|zuHause3> wasn't TRT some polish TV channel?
20:11:23 <Rubidium> Eddi|zuHause3: turkish IIRC
20:11:23 <blathijs> Probably because jack isn't in main and libasound is
20:11:44 <Eddi|zuHause3> could be turkish, yes
20:11:54 <peter1138> blathijs: libasound2-plugins *could* technically be split up.
20:12:02 <peter1138> libasound2-plugins-jackd, for instance.
20:12:30 <peter1138> Apparently the build system does not support bits of a package in different sections.
20:12:43 <blathijs> That might be the problem, indeed
20:13:07 <jordi> splitting it is trivial
20:13:19 <blathijs> I never really managed to understand all those *verses in Ubuntu, I like Debian's way better
20:13:30 <blathijs> Then again, never really tried
20:13:32 <peter1138> Yeah, I'm tempted to switch back ;)
20:13:33 <jordi> just put + * Merge from debian unstable, remaining changes:
20:13:34 <jordi> + - Do not build-depend on libjack-dev and libavcodec-dev.
20:15:50 <peter1138> And I need jack to run all the synths for my keyboard ;)
20:16:37 <jordi> no build-deps from universe is a real problem
20:16:55 <jordi> Debian separates only due to licensing, not to support or not support :)
20:17:56 * peter1138 considers the difficulty in switch to Unstable...
20:18:19 <jordi> peter1138: testing is often a good choice too
20:18:31 <Rubidium> testing usually lacks security updates
20:18:32 <peter1138> But I like bleeding edge :)
20:18:40 <jordi> peter1138: up to date, no bad surprises after an upgrade
20:18:56 <jordi> Rubidium: afaik, there is testing security coverage except for the kernel
20:19:53 <blathijs> testing-security is indeed in place since a month or so
20:21:52 <Rubidium> ofcourse being near a release is a good reason to get the security team on it, but when lenny's out the security team won't touch testing till just before the near release
20:23:12 <Rubidium> never had any major issues with SID since I installed my laptop
20:24:12 <jordi> Rubidium: I've been a sid user for more than 10 years now
20:24:16 <jordi> and I've seen scary shit
20:24:31 <blathijs> Seems that that page is a bit outdated, testing has almost full security support
20:25:21 <jordi> pam (0.76-6) unstable; urgency=low
20:25:25 <jordi> * The "No, I don't think I actually want any of what upstream is
20:25:32 <jordi> * If this were already in testing, this would be an severity emergency
20:25:45 <jordi> * pam_unix currently treats * in shadow file as no password not
20:25:46 <jordi> disabled; major security issue; fixed in upstream CVS, (patch 035) Closes: #164659
20:26:17 <jordi> so, for 4 days, disabled accounts were accessible without a password
20:26:25 *** stillunknown has joined #openttd
20:26:50 * Rubidium likes the excessive valgrinding too
20:27:18 <jordi> actually, make that nearly one month
20:27:27 <jordi> Rubidium: that was LEGENDARY ;)
20:27:56 <jordi> that made me waste *a lot* of free time to fix
20:28:03 <jordi> and days of paid work at office
20:28:31 <blathijs> excessive valgrinding?
20:29:09 <jordi> like removing two lines of code, one of which makes openssl's entropy pool a joke ;)
20:29:53 <CIA-3> OpenTTD: glx * r13819 /trunk/config.lib: -Fix (r13801): --man-dir=xxx was 'ignored'
20:30:18 <Eddi|zuHause3> i don't understand it...
20:30:47 <Rubidium> blathijs: finding a 'reading uninitialized' variable in valgrind and then trying to fix it at all costs
20:31:04 <Rubidium> when it's used for entropy of ssl key generation
20:32:59 <Rubidium> if only X, SDL and alsa would do that ;)
20:42:26 <blathijs> Rubidium: AH, that valgrind :-)
20:49:01 <peter1138> SmatZ, why did you add that comment to callback 11?
20:50:10 <peter1138> In the GRF wiki, that is.
20:50:29 <SpComb> ugh, photoshop -> HTML web design is a bad idea in my mind
20:51:58 <SpComb> but wasn't really interested in implementing it
20:53:32 <peter1138> Holy crap 13816 is a massive load of pointless ness!
20:54:25 <Eddi|zuHause3> SpComb: iirc someone did that already like 2 years ago...
21:03:56 <peter1138> Hmm, last.fm's all changed :o
21:11:17 <Eddi|zuHause3> hm... one of these tiny black insects crawled under the surface of my display...
21:11:42 <Prof_Frink> It'll crawl about a bit, then die and not move.
21:11:59 <Eddi|zuHause3> yeah... die where i cannot ever remove it...
21:14:38 <Eddi|zuHause3> i'd make a screenshot... but ... :p
21:22:20 <Eddi|zuHause3> "Fransenflügler beschädigt Monitore [Bearbeiten]
21:22:20 <Eddi|zuHause3> Dieses Insekt ist zu einer Plage für Besitzer von TFT-Monitoren geworden. Vom Licht des Monitors angezogen, fliegt es durch die Lüftungsschlitze in den Flachbildschirm hinein und befindet sich dann hinter Panelglas und Diffusorfolie. Das Insekt stirbt und ist daraufhin im Monitorbild sichtbar. Garantieansprüche werden von den Herstellern unterschiedlich gehandhabt. Samsung bestätigt beispielsweise, dass "zwischen Diffusorfolie und
21:22:20 <Eddi|zuHause3> TFT-Panel weder Staub, noch Tiere oder Fremdkörper gelangen dürften".[1]" [wikipedia]
21:25:59 <ln> Eddi|zuHause3: you have no problem having a dead body on your screen every day?
22:18:48 *** lobster_MB has joined #openttd
22:20:32 <Eddi|zuHause3> hm... i had my monitor off for an hour, and i don't see it anymore...
22:21:35 *** Dred_furst has joined #openttd
22:45:33 *** Prof_Frink is now known as BRIAN_BLESSED
22:46:18 *** BRIAN_BLESSED is now known as Prof_Frink
22:59:44 <CIA-3> OpenTTD: miham * r13820 /trunk/src/lang/ (13 files): (log message trimmed)
22:59:44 <CIA-3> OpenTTD: -Update: WebTranslator2 update to 2008-07-25 00:59:06
22:59:44 <CIA-3> OpenTTD: brazilian_portuguese - 3 fixed by tucalipe (3)
22:59:44 <CIA-3> OpenTTD: catalan - 10 fixed by arnaullv (10)
22:59:44 <CIA-3> OpenTTD: czech - 12 fixed, 3 changed by Hadez (15)
22:59:46 <CIA-3> OpenTTD: danish - 21 fixed by ThomasA (21)
22:59:46 <CIA-3> OpenTTD: dutch - 16 fixed by habell (16)
23:34:02 *** Osai is now known as Osai^zZz
23:34:44 <ln> now that we know aliens exist, what next?
23:38:26 <Eddi|zuHause3> i have one of two question: a) do we? b) is this new?, please choose ;)
23:43:08 <ln> if an apollo astronaut says they do exist, who are we to say no?
23:43:19 <Blam> people with common sense
23:44:45 *** Marduuhin has joined #openttd
23:44:47 <Blam> right pals, if anyone is about
23:45:04 <Blam> i can't seem to grasp the concept of how i should place the signals in a simple roro system
23:47:53 *** stillunknown has joined #openttd
23:59:17 <Blam> alright, i had a look around but didn't have much luck, thanks
continue to next day ⏵