--- Log opened Wed Dec 20 00:00:08 2017
20171220 00:06:31-!- irker034 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20171220 00:15:15-!- Appleman1234 [~quassel@124x38x163x22.ap124.ftth.ucom.ne.jp] has joined #wesnoth-dev
20171220 00:24:35-!- Bonobo [~Bonobo@110-175-146-248.tpgi.com.au] has joined #wesnoth-dev
20171220 00:49:27-!- irker519 [~irker@109.237.213.40] has joined #wesnoth-dev
20171220 00:49:27< irker519> wesnoth/wesnoth:master Gregory A Lundberg 38e31aa61f Do not access non-existent unit AppVeyor: All builds passed
20171220 02:03:27-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20171220 02:13:02-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20171220 02:27:23-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20171220 02:28:02-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20171220 02:32:48-!- vultraz [uid24821@wesnoth/developer/vultraz] has quit [Quit: Connection closed for inactivity]
20171220 03:03:24-!- vultraz [uid24821@wesnoth/developer/vultraz] has joined #wesnoth-dev
20171220 03:50:02-!- irker519 [~irker@109.237.213.40] has quit [Quit: transmission timeout]
20171220 04:39:49-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20171220 04:40:15-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20171220 05:18:56-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: KABOOM! It seems that I have exploded. Please wait while I reinstall the universe.]
20171220 05:28:50-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20171220 05:28:59-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20171220 06:10:29-!- JyrkiVesterinen [~JyrkiVest@85-23-197-3.bb.dnainternet.fi] has joined #wesnoth-dev
20171220 06:34:41-!- JyrkiVesterinen [~JyrkiVest@85-23-197-3.bb.dnainternet.fi] has quit [Quit: .]
20171220 07:42:12-!- JyrkiVesterinen [~JyrkiVest@195-192-251-124.s1networks.fi] has joined #wesnoth-dev
20171220 09:12:48-!- vultraz [uid24821@wesnoth/developer/vultraz] has quit [Quit: Connection closed for inactivity]
20171220 09:35:32< vn971> ha.
20171220 09:36:38< vn971> fuck-up detected.
20171220 09:36:51< vn971> where should I properly disclose security issues?
20171220 09:47:02< Soliton> i think currently we unfortunately don't really have a way via bug reports. you could describe it in #wesnoth-dev-nonpublic.
20171220 10:12:00-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20171220 12:27:46< JyrkiVesterinen> Update: the "issue" that vn971 found turned out to be expected behavior. No vulnerabilities here.
20171220 12:28:59< vn971> yeah, confirming that. My bad, so nvm.
20171220 13:25:05< vn971> Soliton: btw, does wesnoth_addon_manager work for you with --upload? On my computer, it works fine with commands like --list, but when I try to upload I get this: https://gist.github.com/vn971/85b730314699874c2fb9977c884149e8
20171220 13:28:32< vn971> Also, it hangs on the last step and doesn't do anything for a very long time. I waited for 5 minutes already, and it's still stuck. I think it's stuck forever.
20171220 13:29:29< Soliton> perhaps try with python2? i can't really test right now.
20171220 13:29:58< Soliton> i'm guessing it might not have been completely/properly ported to python3.
20171220 13:30:28< Soliton> elias: ^
20171220 13:36:19< vn971> doesn't work with an altered shebang, too (python2). In case of python2 it says "Incorrect syntax" for  `def __init__(self, data : bytes):`
20171220 13:38:14< Soliton> yeah, i guess it's not a backwards compatible thing. i guess we switched everything to python3 a while ago. i'm not too familiar with python...
20171220 13:39:13< vn971> sometimes it's compatible, but generally not compat, yes.
20171220 13:39:15< Soliton> either try to figure it out yourself or find someone that understands python. elias is the original author IIRC but there are others that know python.
20171220 13:41:08< vn971> I do actually know a bit of python, at newbie level. Will take a look then. (It would be a different story if you'd use `--upload` every other day and it'd work fine.)
20171220 13:41:12< Soliton> opening an issue for it would be good so it's not forgotten.
20171220 13:41:41< vn971> Soliton: or a PR ;-)
20171220 13:44:22< Soliton> there are probably not that many people that use it regularly. we do use it for some stuff on wesnoth.org but only downloading add-ons, i think.
20171220 14:22:38-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20171220 14:23:20< Ravana_> I believe if you change that insert to append it will work, but based on its commend, that line should not be called in the first place
20171220 14:30:16< vn971> Ravana_: insert to append? The line in question seems to be   `dataNode = append_tag("dir")`   isn't it?
20171220 14:31:34< vn971> I tried changing it to `dataNode = append_tag(None, "dir")`   but the client says then   "Invalid WML received: attributes not in order"
20171220 14:31:58< JyrkiVesterinen> The line is this: https://github.com/wesnoth/wesnoth/blob/master/data/tools/wesnoth/campaignserver_client.py#L328
20171220 14:35:15< vn971> JyrkiVesterinen: It the says  "NameError: name 'file' is not defined"   , pointing the the same line. BTW, if I specify the directory, not the _server.pbl file, the error is different.
20171220 14:36:52< JyrkiVesterinen> That appears to be caused by the Python 3 upgrade.
20171220 14:36:53< JyrkiVesterinen> https://docs.python.org/2.7/library/functions.html#file
20171220 14:36:56< vn971> using the `--upload directory` form and the current upstream python code, I get this: https://gist.github.com/vn971/9e9089552ad3ee56b4dd04105d8e9eb6
20171220 14:37:01< JyrkiVesterinen> That function is gone in Python 3.
20171220 14:40:51< vn971> JyrkiVesterinen: now it says  "FileNotFoundError: [Errno 2] No such file or directory: '/home/vasya/.local/share/wesnoth/1.13/data/add-ons/Creep_War_Dev/_server.cfg'"    well this is true, I have _server.pbl,  not _server.cfg.  So this line indeed shouldn't have been invoked.
20171220 14:45:27< vn971> in wesnoth_addon_manager:290 , it is assumed that using `--upload DIR`   syntax means the addon has the new form _server.pbl, while the syntax  `--upload FILE`  means the addon uses _server.cfg
20171220 14:46:28< vn971> I wonder if I over-use this channel. Maybe I should start moving the discussion to the bug tracker.
20171220 14:53:11-!- irker749 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20171220 14:53:11< irker749> wesnoth/wesnoth:master Rikard Falkeborn c90e8b200b Make some functions static in display.{c AppVeyor: vs2017/Release Failed
20171220 14:53:11< irker749> Details: https://ci.appveyor.com/project/wesnoth/wesnoth-605wt/build/Wesnoth-VS2017-master-658
20171220 15:03:02-!- Oebele [~quassel@143.177.58.202] has joined #wesnoth-dev
20171220 15:06:23< vn971> If I use the "directory" syntax (--upload DIR), then there is an error with `append_tag` usage. It seems to be pretty simple, just a typo, I believe. It probably should be `dataNode = append_tag(None, "dir")`  (The first argument None is inserted.)  Now with `None`, I get the following error:   "Invalid WML received: attributes not in order"
20171220 15:07:00< JyrkiVesterinen> Sounds believable. Can you make a pull request?
20171220 15:07:39< vn971> JyrkiVesterinen: the problem is that there's still the error, "Invalid WML ... attributes not in order".
20171220 15:08:32< JyrkiVesterinen> IIRC, campaignd uses simple_wml and therefore indeed requires WML attributes to be in order.
20171220 15:08:55< JyrkiVesterinen> The built-in addon client reorders them for you, but apparently wesnoth_addon_manager doesn't.
20171220 15:08:59< vn971> which seems to come from simple_wml.cpp, which I'm currently trying to understand.
20171220 15:09:28< JyrkiVesterinen> Simple_wml requiring the correct order is a fundamental design decision. Not going to change.
20171220 15:09:49< vn971> JyrkiVesterinen: aha, OK. So maybe I should check out the word "order" in the /tools/  package. I wonder what order is desired though.
20171220 15:10:52< JyrkiVesterinen> Alphabetical order.
20171220 15:12:44< vn971> wow. Pity the client doesn't output the WML. Need to hack into that.
20171220 15:20:08-!- atarocch [~atarocch@93.56.164.28] has quit [Read error: Connection reset by peer]
20171220 15:21:38-!- atarocch [~atarocch@93.56.164.28] has joined #wesnoth-dev
20171220 15:24:06< vn971> OK, I've got the WML. As I might have expected beforehand, that's a VERY huge chunk of text. And of course it's not ordered at all.
20171220 15:24:06< vn971> The problem now is to find a way to order it. As I understood, all tags and all their subtags should be ordered. Grep-ping the python source code for "order" only gave me `@total_ordering`, but I'm not sure this is it. No other interesting usages that I could find.
20171220 15:30:57< Soliton> unlikely there is anything about ordering in there at all.
20171220 15:31:19< Soliton> campaignd is using simple_wml only somewhat recently.
20171220 15:32:50< vn971> OK, so I should make a PR with the simple mistake first, and then raise a bug and/or think what to do with ordering, right?
20171220 15:33:00< Soliton> sounds good.
20171220 15:33:02< vn971> *with the simple mistake fix first
20171220 15:35:04-!- Bonobo [~Bonobo@110-175-146-248.tpgi.com.au] has quit [Ping timeout: 272 seconds]
20171220 15:37:33-!- JyrkiVesterinen [~JyrkiVest@195-192-251-124.s1networks.fi] has quit [Quit: .]
20171220 15:39:12< vn971> https://github.com/wesnoth/wesnoth/pull/2305
20171220 16:00:06-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Read error: Connection reset by peer]
20171220 16:00:12-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20171220 16:02:31-!- vslavik [vslavik@nat/redhat/x-ksfzrsycksgysxeb] has quit [Quit: Leaving]
20171220 16:42:47-!- stikonas_ is now known as stikonas
20171220 16:54:23-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20171220 16:55:13-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20171220 17:08:39-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20171220 17:08:53-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20171220 17:18:06-!- mjs-de [~mjs-de@x55b639ce.dyn.telefonica.de] has joined #wesnoth-dev
20171220 17:48:42-!- Oebele [~quassel@143.177.58.202] has quit [Remote host closed the connection]
20171220 17:53:41-!- irker749 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20171220 18:18:45-!- JyrkiVesterinen [~JyrkiVest@85-23-197-3.bb.dnainternet.fi] has joined #wesnoth-dev
20171220 18:54:03-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20171220 19:39:40-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 255 seconds]
20171220 19:44:35-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20171220 19:48:55< vn971> hmm, I don't get it. How does preprocessor work inside macros? Like
20171220 19:48:55< vn971> #define SOME_TEST
20171220 19:48:55< vn971> {./what-is-this-relative-to???}#enddef
20171220 19:48:55< vn971> {SOME_TEST}
20171220 19:50:58< zookeeper> most likely includes are handled when the macro definition is read, not delayed.
20171220 19:51:40-!- irker792 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20171220 19:51:40< irker792> wesnoth/wesnoth:master Rikard Falkeborn f6314156c6 Make some functions static in display.{c AppVeyor: All builds passed
20171220 19:52:20< vn971> zookeeper: problem is, I define all those 3 lines in one file, and it's not relative to that file for sure. So if I have a file that does exist {./good_file}  and move it inside the macro and out, I get different results. Even if "out" of the macro is just the next line of macro definition, and this macro is used just like I wrote.
20171220 19:53:04< irker792> wesnoth/wesnoth:master Rikard Falkeborn c90e8b200b Make some functions static in display.{c AppVeyor: 1/2 builds failed
20171220 19:53:05< irker792> Details vs2017/Release: https://ci.appveyor.com/project/wesnoth/wesnoth-605wt/build/Wesnoth-VS2017-master-658
20171220 19:54:01< zookeeper> ok, well, doesn't that then mean that the include is resolved relative to the file where you call the macro from, not relative to the file where the macro definition is?
20171220 19:55:22< vn971> zookeeper: but I call the macro from the same file it's defined in! That's what I'm trying to tell.
20171220 19:55:31< zookeeper> oh, right.
20171220 19:56:20< zookeeper> what exactly are these different results you're getting, then?
20171220 19:56:46< vn971> zookeeper: in fact, I even reduced the test to use _main.cfg specifically. It still reproduces. Moving an inclusion {./data} inside the macro and out changes stuff.
20171220 19:58:05< vn971> when I include the file without macro, it just works. When I move preprocessor inclusion {./data} inside the macro, wesnoth says "Macro/file './data' is missing"
20171220 19:58:58< vn971> I'm beginning to suspect that preprocessor inclusions inside macros just have no meaningful relative at all (which would be sad).
20171220 19:59:52< zookeeper> why are you using ./ anyway?
20171220 20:00:38< zookeeper> or was that actually the only way to have a relative include path?
20171220 20:01:11< irker792> wesnoth: Vasya Novikov wesnoth:master 6a1a91cd7c4e / data/core/images/units/ (34 files in 2 dirs): make images not executable https://github.com/wesnoth/wesnoth/commit/6a1a91cd7c4e89be01ca4f12a56a7c55f2531e08
20171220 20:01:13< irker792> wesnoth: Gunter Labes wesnoth:master 0c4ee56eaced / data/core/images/units/ (34 files in 2 dirs): Merge pull request #2307 from vn971/not_executable_images https://github.com/wesnoth/wesnoth/commit/0c4ee56eaced19bf2c96c55cf02bf60222c01708
20171220 20:01:27< matthiaskrgr> lol
20171220 20:03:09< vn971> zookeeper: hm? I use relative.. well, because I can.:D And because I want to. I mean, if the file I want to include lives in the same dir or a child one, why would I use anything else?
20171220 20:03:49< vn971> zookeeper: actually, I'd like NOT to hardcode directory name in a million of places. That feels sane to me.
20171220 20:04:23< zookeeper> sure, makes sense, it's just not something that's used for example in mainline... almost anywhere, really, so i'm not familiar with where it might not work.
20171220 20:04:42< zookeeper> but what you describe sounds like a bug to me, not sure if there's some unobvious reason for it.
20171220 20:05:28< vn971> And I'd even want to use different directory name to publish for wesnoth-1.14. Because I'm forking "Creep_War", and I've already started to use "Creep_War_Dev" as directory name. Now that's a bit ugly and I wannt use "Creep_Wars" for wesnoth-1.14. Anyway, these are my particular reasons, I guess others may have other reasons.
20171220 20:10:25< vn971> zookeeper: I tried to find an answer on the wiki, but nothing macro-related was found in the preprocessor page.
20171220 20:23:56< irker792> wesnoth: Vasya Novikov wesnoth:master 7be364f3b598 / data/tools/wesnoth/campaignserver_client.py: addon_manager: fix append_tag usage https://github.com/wesnoth/wesnoth/commit/7be364f3b5985979a6647cda13cc2ad00b948261
20171220 20:29:15< Soliton> https://wiki.wesnoth.org/PreprocessorRef#Macro_inclusions
20171220 20:48:14-!- JyrkiVesterinen [~JyrkiVest@85-23-197-3.bb.dnainternet.fi] has quit [Quit: .]
20171220 21:12:19-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20171220 21:34:57-!- mjs-de [~mjs-de@x55b639ce.dyn.telefonica.de] has quit [Remote host closed the connection]
20171220 21:35:52-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20171220 21:37:19-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20171220 21:48:09< irker792> wesnoth/wesnoth:master Vasya Novikov 0ec45feb9a addon_manager: fix append_tag usage AppVeyor: All builds passed
20171220 21:56:28-!- travis-ci [~travis-ci@ec2-184-73-44-241.compute-1.amazonaws.com] has joined #wesnoth-dev
20171220 21:56:29< travis-ci> wesnoth/wesnoth#16025 (master - 0c4ee56 : Gunter Labes): The build is still failing.
20171220 21:56:29< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/319352275
20171220 21:56:29-!- travis-ci [~travis-ci@ec2-184-73-44-241.compute-1.amazonaws.com] has left #wesnoth-dev []
20171220 22:06:58-!- vultraz [uid24821@wesnoth/developer/vultraz] has joined #wesnoth-dev
20171220 22:17:58-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20171220 22:29:59-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20171220 22:34:14-!- wedge010 [~Thunderbi@60.241.236.92] has joined #wesnoth-dev
20171220 22:35:45-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 256 seconds]
20171220 22:35:45-!- wedge010 is now known as wedge009
20171220 22:51:16-!- travis-ci [~travis-ci@ec2-184-73-44-241.compute-1.amazonaws.com] has joined #wesnoth-dev
20171220 22:51:17< travis-ci> wesnoth/wesnoth#16026 (master - 7be364f : Vasya Novikov): The build is still failing.
20171220 22:51:18< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/319362039
20171220 22:51:18-!- travis-ci [~travis-ci@ec2-184-73-44-241.compute-1.amazonaws.com] has left #wesnoth-dev []
20171220 23:02:45-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 264 seconds]
20171220 23:12:55< irker792> wesnoth/wesnoth:master Vasya Novikov 986c9db613 addon_manager: fix append_tag usage AppVeyor: All builds passed
20171220 23:16:48-!- Bonobo [~Bonobo@110-175-146-248.tpgi.com.au] has joined #wesnoth-dev
20171220 23:21:29-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
--- Log closed Thu Dec 21 00:00:09 2017