01:03:24 <Gretell> Stable branch on crawl.develz.org updated to: 0.25.0-8-gfd19cd77bd (34)
02:12:22 <Cheibriados> 03gammafunk02 07* 0.26-a0-84-g8c18429: Update the Debian dependency list 10(9 minutes ago, 1 file, 1+ 1-) 13https://github.com/crawl/crawl/commit/8c1842921107
02:13:05 <Cheibriados> 03gammafunk02 07[stone_soup-0.25] * 0.25.0-9-g26727b6: Update the Debian dependency list 10(10 minutes ago, 1 file, 1+ 1-) 13https://github.com/crawl/crawl/commit/26727b657af8
02:13:46 <PleasingFungus> wow
02:13:49 <PleasingFungus> crawl has finally been ruined
02:16:27 <Kelbell> Unstable branch on crawl.kelbi.org updated to: 0.26-a0-84-g8c18429211 (34)
02:19:22 <alexjurkiewicz> that is going to need some changes to the build process -- util/species-gen.py explicitly references `/usr/bin/env python` -- and on debian `python` will only ever mean Python 2
02:21:39 <aidanh> isn't /usr/bin/env python3 the way to fix that?
02:22:15 <gammafunk> alexjurkiewicz: not to the build process; this is only for debian
02:22:24 <gammafunk> we don't build the debs as part of the build process
02:22:48 <gammafunk> depend on what you're referring to by build process
02:24:28 <gammafunk> this should have no effect on anything we do via github actions presently
02:24:57 <gammafunk> perhaps I should have said "Debian package dependency list" in that commit title
02:25:57 <gammafunk> it would be nice to add building the debs to said actions, but there is an issue of what to do with those debs; I'm not sure we can realisticaly build them on github yet host our special repo on CDO
02:27:23 <gammafunk> and if we don't host a repo on CDO, how do people install the debs?
02:27:36 <gammafunk> other projects just provide a single .deb file for download, but our package has been structured the way debian likes packages to be made, with console and tiles split into packages and with a common package and a data package (for tiles data)
02:36:13 <gammafunk> I've updated the CDO repo to have 0.25 and have updated the download page accordingly
02:36:37 <gammafunk> now we just have to wait for random debian-based distro X user to complain that the dependencies are too recent
02:36:43 <Chousuke> Is there anything like Fedora COPR for Debian packages?
02:58:21 -!- amalloy_ is now known as amalloy
03:05:18 <alexjurkiewicz> what is that? it sounds like canonical launchpad
03:30:41 <Kelbell> Stable (0.25) branch on crawl.kelbi.org updated to: 0.25.0-9-g26727b657a
03:31:13 <Kelbell> Fork (bcrawl) on crawl.kelbi.org updated to: 0.23-a0-3252-g98d61c7ed1
03:33:41 <Kelbell> Fork (bcadrencrawl) on crawl.kelbi.org updated to: 0.22.1-2792-g831048675f
05:11:33 -!- bh is now known as Guest9235
05:24:42 -!- amalloy is now known as amalloy_
06:33:44 -!- amalloy_ is now known as amalloy
06:37:50 -!- amalloy is now known as amalloy_
10:15:02 -!- amalloy- is now known as amalloy
10:16:07 -!- robertmeta_ is now known as robertmeta
12:19:51 <Bcadren> This mostly only affects a few vaults and therefore could be fixed with just a no monster placement mask...but it's super awkward that monster placement can place things in spots where they die without waking up. IE: Slimehenge slime entry can place normal lair monsters next to slimy walls; the damage doesn't wake them up and they just die without
12:19:51 <Bcadren> player involvement...similar with flamethrower and similar fire cloud vaults, though the fire clouds do wake things up the damage amount is often enough to kill outright when they are placed in the D.
12:45:13 -!- amalloy is now known as amalloy_
13:01:59 <Henzell> Stable (0.25) branch on crawl.akrasiac.org updated to: 0.25.0-9-g26727b6
13:07:29 <Henzell> Unstable branch on crawl.akrasiac.org updated to: 0.26-a0-84-g8c18429 (34)
13:36:10 <advil> floraline report that spectating ssh players via webtiles doesn't work on cko (e.g. https://crawl.kelbi.org/#watch-Nomi right now)
14:55:43 -!- ProzacElf_ is now known as ProzacElf
15:31:28 -!- aidanh_ is now known as aidanh
15:39:05 <rchandra> %git ^{/Ilsiuw}
15:39:05 <Cheibriados> Could not find commit ^{/Ilsiuw} (git returned 128)
17:00:30 <advil> gammafunk are you sure your response about xenial is right?
17:01:07 <advil> travis is still testing on xenial
17:01:34 <gammafunk> advil: just judging by their reported requirements and what oldstable reports
17:01:58 <gammafunk> oldstable is perhaps just a bit more current than xenial?
17:02:12 <gammafunk> e.g. a debian vs ubuntu thing
17:02:22 <advil> oh, I do have vague memories of this now
17:04:23 <advil> though I do think they are right that we produced a 0.24 deb that worked for xenial?
17:04:39 <gammafunk> yeah we probably did
17:05:05 <gammafunk> but that's sort of going to happen unless we pin our builds to a specific debian as long as we can
17:05:16 <gammafunk> as opposed to just using stable or  oldstable each time
17:05:28 <advil> could it have just been that we rebuilt against oldoldstable or something?
17:05:44 <gammafunk> you did those debs, so I'm not sure
17:05:51 <advil> yeah
17:06:00 <advil> I'm having trouble finding whatever discussion there was
17:06:20 <gammafunk> I can certainly rebuild them to an older debian (assuming that it works), but it would be good to agree upon a procedure
17:07:51 <gammafunk> always oldoldstable or always oldest lts version that's not EOL
17:08:06 <gammafunk> oh looks like debian 8 reaches EOL this month
17:09:16 <gammafunk> I actually upgraded my aws instance because my cowbuilder failed to create the COW
17:11:22 <advil> it looks like last time there was discussion about this it was a mismatch with stable (around sdl version) and I rebuilt them against oldstable, which at the time was stretch
17:11:33 <advil> though is stretch still oldstable?
17:12:42 <gammafunk> stretch does appear to be oldstable
17:12:44 <advil> the sticking point last time was sdl, not libc (wish I could find the issue)
17:13:36 <gammafunk> hrm, well libc6 on stretch 2.24-11
17:13:42 <gammafunk> https://packages.debian.org/stretch/libc6
17:13:45 <advil> yeah, I see that
17:13:54 <gammafunk> would their ubuntu libc6 be ok with that?
17:14:26 <gammafunk> I assumed it wouldn't by the version their system reported
17:14:26 <advil> very weird, I'm pretty sure it was this exact mismatch last time, so I don't know why that would work
17:15:33 <gammafunk> also wondering if we'd run into sdl issues since we did upgrade our dependencies at some point; I guess that was all pre 0.24 though
17:16:21 <advil> and stretch has had 2.24-11 since Feb 2019
17:17:43 <advil> yeah, sdl should be ok
17:18:14 <advil> I remember at the time thinking that stable was surprisingly ambitious to be requiring sdl 2.8
17:18:37 <advil> er, 2.0.9
17:19:55 <advil> whereas oldstable is 2.0.5
17:31:51 <advil> oh haha
17:32:20 <advil> I'm misreading this dpkg output
17:32:34 <advil> our debs somehow required only libc 2.4
17:34:08 <advil> is it possible that that won't track exactly the version that it is built against?
17:37:22 <gammafunk> required that for 0.25?
17:37:57 <advil> for 0.24
17:38:00 <advil> the ones I rebuild
17:38:01 <gammafunk> ah
17:38:18 <advil> even though stretch appears to have a much later version (and debian hasn't had a version of libc that old in like 10 years)
17:38:35 <AJTJ> looking for some low-hanging fruit tasks to do for crawl
17:38:37 <gammafunk> you're positive you built those against stretch?
17:38:51 <gammafunk> oh, in 10 years you said, heh, yeah no idea
17:39:14 <advil> not sure, just going by what I said in channel here
17:39:21 <advil> do you know if there's a way to tell from the deb?
17:39:25 <advil> I still have the docker image too
17:39:33 <AJTJ> anyone have a list of tasks I can jump into with the engine? Interested in digging into some C++
17:41:06 <gammafunk> advil: is ~/upload/0.24.0/deb/crawl_0.24.0-1_amd64.buildinfo helpful? that might have just been my stuff
17:41:54 <gammafunk> I see a deb-old folder as well though
17:44:06 <gammafunk> sorry, I should specify that this is on CDO
17:45:07 <gammafunk> AJTJ: well, you could ask aidanh if you're specifically interested in graphics projects or modularization (as aidanh had started that as one of his project)
17:45:21 <gammafunk> you could of course track down and fix outstanding bugs that seem interesting
17:46:28 <gammafunk> as far as the "engine" goes though, depends on what you mean by that; there are some general areas like monster AI that need reworking, but I don't think anyone has put together a plan of attack for that
17:47:42 <advil> just says "Build-Origin: Debian"
17:47:56 <advil> hmm
17:48:07 <advil> maybe libc version is not what we think it is
17:48:12 <advil> libc6 (= 2.24-11+deb9u4),
17:48:24 <advil> which is exactly what is in stretch
17:49:20 <advil> or it doesn't impose that version is a requirement absolutely
17:52:53 <advil> so I suspect doing this would fix the debs for xenial
17:53:02 <advil> to the larger topic, "oldest lts version that's not EOL"... and that works, seems good to me
17:53:11 <advil> 95% debian oldoldstable will not work right now
17:53:33 <advil> *95% sure
17:55:57 <advil> just using "oldstable" also seems reasonable, though if we're considering rebuilding for this case we apparently have 14 days to be following the process :D
17:57:10 <advil> well, I guess oldoldstable eol does not actually coincide with a release
17:58:23 <gammafunk> coincide with a release?
17:58:41 <gammafunk> a release of crawl you mean?
17:59:50 <gammafunk> and to make sure I understand what you're saying, if we tried to use debian 8 jessie (currently oldoldstable), those packages wouldn't build?
18:00:59 <gammafunk> oh I think I see what you're saying
18:01:12 <gammafunk> re: coinciding with a release
18:01:34 <gammafunk> yes, that's just the timing of the EOL, not the timing of when stable becomes oldstable etc
18:01:44 <gammafunk> buster was release in may iirc
18:01:52 <gammafunk> yeah May 9th
18:02:44 <gammafunk> we would need to act soon if we wanted to follow the "use oldest lts that still has support" rule, but it sounds like you're saying we can't use that rule since the packages aren't viable
18:04:24 <gammafunk> I can go ahead and rebuild to stretch
18:07:14 <advil> yeah, if you have time...I could probably do it if not
18:07:29 <advil> right, I don't think jessie is viable
18:07:50 <advil> at least not for the tiles build
18:08:33 <advil> iirc we had to update travis to xenial manually at some point because of jessie issues
18:09:22 <gammafunk> sure, I'll rebuild the packages
18:09:29 <gammafunk> I guess we can go with the "oldstable" rule then and just hope that works out
18:10:22 <gammafunk> then wait for the report from a linux mint user who refuses to upgrade their installation from 2010
18:12:10 <advil> heh
18:12:10 <advil> apparently I actually did some editing of the release docs when this came up, what I wrote then was "We build the debs against either debian stable, or debian oldstable. Debian
18:12:10 <advil> stable is preferred, except for scenarios where that might break compatibility
18:12:10 <advil> with currently common Ubuntu LTS versions, in which case you should use
18:12:10 <advil> oldstable."
18:16:19 <AJTJ> gammafunk: thanks, I'll reach out soon to jump into something
18:17:29 <AJTJ> gammafunk: is anyone using rust in this project? Would anyone be opposed to it?
18:17:49 <gammafunk> AJTJ: probably we wouldn't want to introduce any new language requirements
18:18:23 <gammafunk> we use C++ and lua for the game itself, python for the webtiles server and some code generation, as well as perl for code generation (although we'd like to convert that to python)
18:19:53 <Cheibriados> Uskayaw forgets piety-based abilities after crash 13https://crawl.develz.org/mantis/view.php?id=12283 by Tenaya
18:25:02 <AJTJ> aidanh: I'm interested in talking to you about the projects you're working on
18:26:30 <Lantell> Unstable branch on underhound.eu updated to: 0.26-a0-84-g8c18429211 (34)
18:31:21 <AJTJ> gammafunk: why use python for the webtiles? Wouldn't that be an ideal React application?
18:31:42 <AJTJ> ah, it's for the server
18:31:49 <AJTJ> interesting
18:31:54 <gammafunk> yeah, we use jquery for the front end
18:32:01 <AJTJ> dang
18:32:06 <AJTJ> old school haha
18:32:08 <gammafunk> well, a pretty old version of jquery with other old stuff hacked together, I guess
18:32:23 <gammafunk> I am no javascript expert nor even an approximation of one
18:32:54 <gammafunk> there was a project to move front end to jsx/react, but the original webtiles developer (who was an expert in this sort of thing) has since moved on
18:33:18 <AJTJ> is the old FE code bad?
18:47:52 -!- jfcaron_ is now known as jfcaron
18:55:59 -!- ProzacElf_ is now known as ProzacElf
19:09:55 <alexjurkiewicz> it's quite idiomatic ES5 circa 2015. The codebase has aged but it is straight forward and relatively easy to understand
19:11:01 * gammafunk goes to look up what ES5 means
19:11:02 <alexjurkiewicz> the frontend code is very tightly coupled to the backend crawl version, for example many enums are duplicated in C++ and JS, as well as much display logic relying on implicit ordering
19:11:50 <gammafunk> well, I'm not sure you can just decouple that without likewise doing so for e.g. SDL and console rendering
19:12:21 <alexjurkiewicz> yeah. It is what it is, really
19:12:33 <gammafunk> I mean, I guess you have said enums in C++ itself for those rendering systems as they're coded in C++, but I'm not sure how you'd redesign that aspect for JS
19:12:45 <gammafunk> but yeah I'm just very ignorant of JS technology still
19:13:03 <gammafunk> it was kind of fun learning enough of JSX/react to make a local server score page though!
19:13:15 <gammafunk> in retrospect it's a terrible idea since it directly reads the score file in realtime
19:13:39 <gammafunk> would be a nice little project to have though; per-server rending of scores
19:13:47 <gammafunk> at least as long as we still have that idea at all, I gess
19:14:02 <gammafunk> maybe if we got SSO working we'd not need the idea
19:14:11 <alexjurkiewicz> I think ideally there would be a more symbolic intermediate layer in the same way there is mon_info between the dcss core and display code
19:15:20 <alexjurkiewicz> instead of passing ENCH_WATERLOGGED to webtiles, you'd pass "waterlogged"
19:26:53 <gammafunk> guess we've really ironed out all the major tournament script bugs as have had no exceptions/crashes for several days now
19:26:56 <gammafunk> well done team tourney
19:56:18 <alexjurkiewicz> well done to those who swooped in after I vanished to pick up strange code and fix bugs in it
19:57:13 <alexjurkiewicz> I guess without sequell it's hard to tell how popular this tourney is compared to previous ones
20:04:55 <gammafunk> alexjurkiewicz: actually we can check the CDO db for some basics
20:05:20 <gammafunk> 1951 players so far
20:06:57 <gammafunk> 87 teams I think
20:07:38 <gammafunk> hrm
20:07:48 <gammafunk> wonder why that disagrees with the list on the tournament page
20:08:13 <gammafunk> that says 141
20:08:28 <gammafunk> oh
20:08:33 <gammafunk> maybe that was due to a db update
20:08:38 <gammafunk> so rows were locked
20:08:41 <gammafunk> it says 141 now
20:08:49 <gammafunk> so looks like 1951 players, 141 teams so far
20:09:04 <gammafunk> play time stats will probably be a lot more difficult
20:09:11 <gammafunk> not sure we record game duration in the db
20:12:51 <gammafunk> yeah so I guess we can get the stats we need from the db
20:12:59 <gammafunk> including play time etc
20:22:52 <Lantell> Stable (0.25) branch on underhound.eu updated to: 0.25.0-9-g26727b657a
20:27:53 <rchandra> alexjurkiewicz: is sequell ever returning?
20:29:10 <alexjurkiewicz> i'm not the right person to ask
20:33:58 <gammafunk> rchandra: yes, it is returning
20:34:12 <gammafunk> we don't have a good ETA yet though
20:34:55 <rchandra> glad to hear
20:35:22 <rchandra> it's amazing how much of the crawl (and especially tournament) experience is carried by that bot
20:49:58 <gammafunk> ^status
21:26:06 -!- raskol_ is now known as raskol
23:10:41 -!- amalloy_ is now known as amalloy
23:14:27 <Henzell> svendre (L16 FeIE) Crash caused by signal #6: Aborted (Elf:1)
23:25:45 -!- muffindrake1 is now known as muffindrake