00:11:09 Stable (0.30) branch on cbro.berotato.org updated to: 0.30.0-3-ga4e48a9924 00:31:16 Stable (0.30) branch on crawl.kelbi.org updated to: 0.30.0-3-ga4e48a9924 00:32:09 Fork (bcrawl) on crawl.kelbi.org updated to: 0.23-a0-4917-g3c53b74d1c 01:01:40 Fork (bcadrencrawl) on crawl.kelbi.org updated to: 0.03-1710-gb0f99b5b02 03:24:37 Experimental (bcrawl) branch on underhound.eu updated to: 0.23-a0-4917-g3c53b74d1c 05:01:40 Stable (0.30) branch on crawl.akrasiac.org updated to: 0.30.0-3-ga4e48a9 05:08:14 Unstable branch on crawl.akrasiac.org updated to: 0.31-a0-14-gc80a10f (34) 07:06:41 WasteTime5 (L27 GrFi) ERROR in 'mon-util.cc' at line 681: bogus mc (no monster data): invalid monster_type 1000 (1000) (Tomb:1) 07:08:05 WasteTime5 (L27 GrFi) ERROR in 'mon-util.cc' at line 681: bogus mc (no monster data): invalid monster_type 1000 (1000) (Tomb:1) 07:48:02 Inkenn (L11 GrBe) ASSERT(desc_tgt) in 'item-use.cc' at line 767 failed. (D:10) 08:14:36 <03robertxgray> stone_soup-0.30.0-nodeps.tar.xz. Does anybody know how is this included in the release? I can't find any related github actions workflows 08:17:16 gammafunk said something a few days ago about uploading source packages, I think 08:17:53 [05 16:48:22] awesome, release files generated (finally!). Now I can upload the source packages and then make the post 08:19:54 more to the point `[05 16:17:15] the only thing I can think of is my uploading of the source files caused it to skip the action?` implies the upload was to the release and not to e.g. CDO 08:21:10 <03robertxgray> thank you! then I'm going to add a workflow for them 08:30:47 !crashlog Inkenn 08:30:48 1. Inkenn, XL11 GrBe, T:7862 (milestone): https://cbro.berotato.org/morgue/Inkenn/crash-Inkenn-20230507-144802.txt 08:31:23 07gammafunk02 * 0.30.0: doc: Update the debian changelog for 0.30 10(2 days ago, 1 file, 5+ 0-) 13https://github.com/crawl/crawl/commit/0735c779e89d 08:31:23 %git 0.30.0 08:31:38 07gammafunk02 * 0.30.0-3-ga4e48a9924: doc: Add a missing debian changelog entry 10(13 hours ago, 1 file, 5+ 0-) 13https://github.com/crawl/crawl/commit/a4e48a9924b9 08:31:38 %git stone_soup-0.30 08:35:58 <09gammafunk> yeah, thanks for including those. We may have some redundancies in terms of source packages we put in the release/workflow at this point, but the package with deps is needed for full compilation on windows (which always needs to compile contribs) or mac (which may or may not need to compile contribs), and the nodeps is for people on linux who should never need the contribs, as they should install the relevant packages for their system 08:38:20 <03robertxgray> can you think of anything else that could be automated in the release? 08:39:13 <06advil> that file is actually in the deb but renamed 08:39:24 <06advil> would be good to have in the regular release on that name though 08:39:50 <06advil> ugh, I guess I forgot to push which will mess up the commit hashes in messages probably 08:41:15 <06advil> specifically I think (maybe wrong) that https://github.com/crawl/crawl/releases/download/0.30.0-debian/crawl_0.30.0.orig.tar.xz is actually the same as the nodeps tarbell 08:41:15 <09gammafunk> yeah, and that file must necessarilly have that name in order for the deb build process to work. I'm not sure if installing the packages in the repo also requires the source file (with that name), I seem to recall that it does 08:41:40 <09gammafunk> that should be the same is the same as nodeps from what I remember of the debian process 08:41:56 <09gammafunk> that is, I take one of those two files (the nodeps one I believe), and rename it to a file with that name format 08:42:18 <09gammafunk> it must be one level above the debian directory (copied from the source tree) iirc 08:44:20 <09gammafunk> in terms of the files we put as artifacts on the release, we shouldn't need both the stone_soup... one and the debian one, so I guess the debian one could be removed post debian package build before zipping up the debian files, to save space 08:44:57 <09gammafunk> if it's needed on cdo to install the debs, trivial to grab a copy from the right release artifact url 08:46:47 <09gammafunk> probably we could in theory automate installing the debs on cdo, but I'm not sure we want to go down that route. likewise there are a couple other cdo-related tasks where I'm not sure we'd want to connect them to github 08:48:20 <09gammafunk> yeah confirmed it's actually the same file, per debian instructions: > mkdir -p ~/crawl-deb > cp stone_soup-0.17.0-nodeps.tar.xz ~/crawl-deb > cd ~/crawl-deb > tar Jxf stone_soup-0.17.0-nodeps.tar.xz > mv stone_soup-0.17.0 crawl-0.17.0 > mv stone_soup-0.17.0-nodeps.tar.xz crawl_0.17.0.orig.tar.xz 08:49:38 <09gammafunk> so crawl_0.N.0.orig.tar.xz could be excluded from the zip of debian stuff, as it's just a copy of a file we'll be shipping 08:50:22 <09gammafunk> but for the debian package making process itself, that file needs to exist 08:52:12 <03robertxgray> please have a look at this test release and tell me if it needs more changes: https://github.com/robertxgray/crawl/releases/tag/0.0-b1 08:53:14 <09gammafunk> I'm wondering what the difference is between the full deps zip we make and the github zip 08:53:29 <09gammafunk> I guess the filename is sort of relevant 08:54:21 <09gammafunk> specifically these two files 08:54:21 <09gammafunk> https://cdn.discordapp.com/attachments/747522859361894521/1104798383291498637/image.png 08:56:34 <09gammafunk> looks good to me aside from possibly redundant source files, and not fully clear we want to remove those yet 08:57:09 <09gammafunk> our stone_soup...zip file is pretty big and may be identical to the github source zip...oh, isn't one difference the .git dir 08:58:12 <09gammafunk> oh I see, the github source is basically nodeps 08:59:56 <09gammafunk> and they have a different directory structure, and neither has .git directories so neither could really be used for compilation anyhow??? 09:00:38 <09gammafunk> I guess you just have to check out the repository to build, so these source packages we're making are sort of useless in practice? 09:01:01 <09gammafunk> aside from just having an archive of the source for posterity 09:01:32 I thought git was only needed for non-release builds, the release is supposed to have a version stamp of some kind? 09:01:43 <09gammafunk> ah 09:02:51 <09gammafunk> well, I get an error about missing .git when I attempt compilation from the stone_soup... zip 09:03:09 <09gammafunk> maybe what geekosaur said used to work but no longer does? 09:03:25 <09gammafunk> I do vaguely recall something like that 09:04:36 <09gammafunk> ...oh 09:04:47 <09gammafunk> a debug build fails, but a non-debug build seems to be succeeding 09:05:13 <09gammafunk> ok, so this is a (potentially legit way to build from the source 09:08:55 <03robertxgray> yes, in source/util/release_ver 09:09:20 <09gammafunk> yep, looks like that mechanism is still working 09:10:17 <09gammafunk> But yes, sorry for the rambling about source packages that may or may not be functionally irrelevant these days. Everything looks good, and I imagine we can somewhat easilly adjust workflows at some point in the future to cull any files we feel we no longer need to ship, if we decide that. 09:10:59 <09gammafunk> advil may weigh in with his own thoughts, but not having the debian stuff as its own release is great as is having one file for me to retrieve from cdo 09:12:15 <03robertxgray> okay, I just need to finish testing the source release, then I'll open a PR 09:13:19 I'm looking at the Makefile, looks like: 09:13:49 (1) `ifdef USE_MERGE_BASE` is there, but nothing seems to set it 09:14:09 (2) the code attempts to use `util/release_ver` if there's no git 09:15:28 (3) `RECENT_TAG` assumes both `USE_MERGE_BASE` and `git describe` work, but appears not to actually be used anywhere 09:16:40 there's also code which tries git and assumes a release if it doesn't work, but I think it's defeated by (3) 09:17:58 <09gammafunk> my debug build failed in util, weirdly it seemed to start a build just fine after I had successfully made a non-debug tiles build, presumably because the target in this error message got made by that build: > fatal: not a git repository (or any of the parent directories): .git > make: [Makefile:1343: webserver/webtiles/version.txt] Error 128 > make: Waiting for unfinished jobs.... > make[1]: Leaving directory 09:17:59 '/home/gammafunk/Downloads/stone_soup-0.0-b1/source/util' 09:18:37 <09gammafunk> looks like something related to the version functionality advil added for webtiles 09:19:07 <06advil> I think github's auto-generated "source code" is just a snapshot of the branch HEAD with no git stuff 09:19:43 <06advil> so it's pretty useless for us as it doesn't have version info, and also it does have non-submodule deps e.g. for webtiles (which the linux people don't want) 09:20:54 <06advil> iirc it's generated for any release with no actions needed 09:21:16 <09gammafunk> yeah, I guess the people (on linux) using these source packages are probably package makers themselves? Like you need that relevant source package to make debian packages 09:21:29 <06advil> yeah 09:21:35 <09gammafunk> whereas a typical linux/unix user would use a git checkout 09:21:52 <06advil> also I think nodeps does remove some minified js where the gpl compatibility is iffy 09:22:12 <09gammafunk> oh, right 09:22:51 <09gammafunk> obviously we need to make a crawl-webtiles debian package so we can wade into fun issues like that 09:22:59 <06advil> lol 09:23:16 <06advil> not volunteering to interact with 1kb over that 09:31:19 <06advil> what is this building from exactly? 09:32:37 <06advil> it makes sense that that step should fail because it calls git describe directly 09:32:56 <09gammafunk> unzipped stone_soup-0.0-b1.zip (i.e. not the nodeps zip), from source directory 09:33:03 <06advil> I would specifically expect any webtiles build without a repo to fail 09:33:15 <06advil> so if that was not a WEBTILES=y build then it's a bug 09:33:23 <09gammafunk> it was a webtiles build yeah 09:37:28 <06advil> I guess you are doing this on linux, on mac it's already broken by lack of deps 09:38:39 <06advil> I'm surprised a non-debug tiles build would work though? 09:53:36 <09gammafunk> but with that util/release_ver functionality in the makefile, shoudln't a tiles (i.e. non-webtiles) build work, at least for linux? 09:54:26 <09gammafunk> perhaps adding further mystery: if I do my tiles non-debug build first, I can then do my webtiles debug build 09:56:34 <09gammafunk> my make command for the non-debug tiles build was just based on the example in the install file: make -j3 TILES=y 09:56:43 it's created if .ver exists, which is probably left around from the earlier build 09:57:06 <09gammafunk> makes sense 10:00:58 <06advil> ah, so what's happening is that the build rule for webserver/webtiles/version.txt will still generate a blank file on an error 10:01:03 <06advil> it's just implemented with a simple > 10:01:20 <06advil> so it's really the prior attempt to build webtiles that's causing it to work I think 10:02:58 <06advil> hm, I suppose if we wanted a git-free build to work from this file, in principle we could try to get the version from the path, since github does guarantee it to be there 10:03:30 <09gammafunk> essentially the tag name, I assume? 10:04:03 <06advil> yeah 10:04:17 <06advil> though if you download via the "code" button, it just is the branch name 10:59:38 req: glaive of the prune makes you see purple during berserk 11:10:00 <10PleasingFungus> lol 11:48:42 New branch created: pull/3123 (3 commits) 13https://github.com/crawl/crawl/pull/3123 11:48:43 03Medrano8302 07https://github.com/crawl/crawl/pull/3123 * 0.31-a0-9-g6607838146: Allow any version format in debian packages 10(23 hours ago, 1 file, 0+ 2-) 13https://github.com/crawl/crawl/commit/6607838146df 11:48:43 03Medrano8302 07https://github.com/crawl/crawl/pull/3123 * 0.31-a0-10-g58df0d9c70: Debian release rework 10(22 hours ago, 1 file, 15+ 15-) 13https://github.com/crawl/crawl/commit/58df0d9c7086 11:48:43 03Medrano8302 07https://github.com/crawl/crawl/pull/3123 * 0.31-a0-11-gb9fe1d8419: Add CI workflow for source packages 10(3 hours ago, 1 file, 24+ 0-) 13https://github.com/crawl/crawl/commit/b9fe1d84190e 12:04:28 Inkenn (L4 DsFi) ASSERT(desc_tgt) in 'item-use.cc' at line 767 failed. (D:3) 14:45:08 <10PleasingFungus> does anyone object to me changing the definition of the kills milestone field to exclude firewood? (plants, fungi, toadstools etc.) it's a bit unfair to anyone who's already run pacifist in the first two days of the tournament, but it seems more fun to compete on for the remaining 14 days 14:50:31 <09gammafunk> hrm, yeah, can't really think of any problems that would cause. I suppose it's useful to somehow list the amount of firewood destroyed, but maybe that's not too important? I assume one just wouldn't have that info in the morgue if we excluded them from kills 14:50:55 <09gammafunk> right now the pacifist chars in the top ranking aren't really pacifist 14:51:08 <09gammafunk> so probably minimal harm to tournament scoring if you make that change 14:53:56 <08Implojin> not sure that knocing the exact amount of firewood killed was ever super relevant 14:53:58 <10PleasingFungus> my plan was to keep that info in the morgue but not include it in milestones, but i don't feel strongly 14:54:04 <10PleasingFungus> happy to remove it from morgues too 14:55:26 <09gammafunk> it's possibly useful for debugging purposes, but yeah probably not for players 14:56:28 <09gammafunk> if it is useful for debugging, probably there are other types of summaries you'd rather see 14:57:08 <10PleasingFungus> think i'm sold on excluding em generally 15:01:29 03PleasingFungus02 07* 0.31-a0-15-g1fe5e1216f: Don't count firewood as kills (CarefulOdds) 10(68 seconds ago, 1 file, 6+ 1-) 13https://github.com/crawl/crawl/commit/1fe5e1216f2a 15:02:32 03PleasingFungus02 07[stone_soup-0.30] * 0.30.0-4-gf1e46c7d8c: Don't count firewood as kills (CarefulOdds) 10(2 minutes ago, 1 file, 6+ 1-) 13https://github.com/crawl/crawl/commit/f1e46c7d8cde 15:10:57 04Build failed for 08master @ 1fe5e121 06https://github.com/crawl/crawl/actions/runs/4909492629 15:19:41 Unstable branch on crawl.kelbi.org updated to: 0.31-a0-15-g1fe5e1216f (34) 15:20:04 not sure what's up with that build failure 15:25:14 Unstable branch on underhound.eu updated to: 0.31-a0-14-gc80a10f4b6 (34) 15:28:45 03PleasingFungus02 07* 0.31-a0-16-g6d2539766c: Prevent more duplicate artps 10(82 seconds ago, 1 file, 14+ 6-) 13https://github.com/crawl/crawl/commit/6d2539766c52 15:28:46 03PleasingFungus02 07[stone_soup-0.30] * 0.30.0-5-g1a98f26d00: Prevent more duplicate artps 10(83 seconds ago, 1 file, 14+ 6-) 13https://github.com/crawl/crawl/commit/1a98f26d005f 15:34:07 Unstable branch on crawl.kelbi.org updated to: 0.31-a0-16-g6d2539766c (34) 15:37:44 04Build failed for 08master @ 6d253976 06https://github.com/crawl/crawl/actions/runs/4909619210 16:24:46 Stable (0.30) branch on underhound.eu updated to: 0.30.0-5-g1a98f26d00 18:47:36 <06advil> Can't get version information: `git describe` failed (no git, no repository, or shallow clone), and util/release_ver doesn't exist. (been doing this for a few days) 18:55:01 <06advil> hm 18:55:08 <06advil> fatal: No annotated tags can describe 'd14b0f4ee22f9d1b00a3534f8e9ca280991fdedc'. However, there were unannotated tags: try --tags. 20:43:39 particleface (L15 KoAE) ERROR in 'mon-util.cc' at line 681: bogus mc (no monster data): invalid monster_type 1000 (1000) (Orc:2) 22:34:53 Unstable branch on crawl.develz.org updated to: 0.31-a0-16-g6d2539766c (34) 22:57:09 Windows builds of master branch on crawl.develz.org updated to: 0.31-a0-16-g6d2539766c 23:14:55 Unstable branch on cbro.berotato.org updated to: 0.31-a0-16-g6d2539766c (34) 23:54:15 Monster database of master branch on crawl.develz.org updated to: 0.31-a0-16-g6d2539766c