00:17:14 Unstable branch on cbro.berotato.org updated to: 0.35-a0-46-ga667b5b5df (34) 00:56:02 Monster database of master branch on crawl.develz.org updated to: 0.35-a0-46-ga667b5b5df 01:11:45 Stable (0.34) branch on cbro.berotato.org updated to: 0.34-b1-46-g4715434a6a 01:13:43 Stable (0.34) branch on underhound.eu updated to: 0.34-b1-46-g4715434a6a 04:34:22 Experimental (bcrawl) branch on underhound.eu updated to: 0.23-a0-5261-gd9800d219b 05:14:46 Unstable branch on crawl.akrasiac.org updated to: 0.35-a0-46-ga667b5b (34) 08:40:06 <09g​ammafunk> %git stone_soup-0.34 08:40:07 <04C​erebot> DracoOmega * 0.34-b1-46-g4715434a6a: Print more useful error messages when a ghost fails validation (18 hours ago, 3 files, 78+ 11-) https://github.com/crawl/crawl/commit/4715434a6aec 08:40:12 <09g​ammafunk> uh oh 08:40:59 <09g​ammafunk> sigh 08:41:08 <09g​ammafunk> I hadn't pushed that commit 08:41:16 <09g​ammafunk> %git 08:41:17 <04C​erebot> DracoOmega * 0.35-a0-46-ga667b5b5df: Print more useful error messages when a ghost fails validation (18 hours ago, 3 files, 78+ 11-) https://github.com/crawl/crawl/commit/a667b5b5df5c 08:41:23 <09g​ammafunk> that is quite annoying 08:41:44 03gammafunk02 07[stone_soup-0.34] * 0.34.0: Final changelog updates for 0.34.0 10(14 hours ago, 2 files, 7+ 2-) 13https://github.com/crawl/crawl/commit/19cb0921cbcb 08:41:51 <09g​ammafunk> I've made that mistake twice now I think 08:41:53 <09g​ammafunk> %git 08:41:54 <04C​erebot> DracoOmega * 0.35-a0-46-ga667b5b5df: Print more useful error messages when a ghost fails validation (18 hours ago, 3 files, 78+ 11-) https://github.com/crawl/crawl/commit/a667b5b5df5c 08:42:02 <09g​ammafunk> %git stone_soup-0.34 08:42:03 <04C​erebot> gammafunk * 0.34.0: Final changelog updates for 0.34.0 (14 hours ago, 2 files, 7+ 2-) https://github.com/crawl/crawl/commit/19cb0921cbcb 08:42:14 <09g​ammafunk> oh well, we'll do a point release after tournament 08:42:28 <09g​ammafunk> but it does mean that the version reported in the packages for 0.34.0 will be off 08:43:13 <09g​ammafunk> git letting you push a tag off a ref you haven't pushed seems kind of bad 08:43:54 <04d​racoomega> Dangit 08:44:08 <09g​ammafunk> it shouldn't cause any practical issues, at least 08:44:23 <04d​racoomega> Yeah, it's just that one commit, right? 08:44:38 <09g​ammafunk> well, it's that, yes, but it's also the reported version 08:44:59 <09g​ammafunk> I think 0.34.0 builds without that commit won't report themselves as just 0.34.0 08:45:00 <09g​ammafunk> but will use that -b1 vlong etc 08:45:13 <04d​racoomega> Oh =/ 08:45:27 <09g​ammafunk> but again we are releasing a point release after t, so 08:46:39 <09g​ammafunk> in my defense, I'm the only one doing release tagging and no one else is really looking at this 08:47:08 <04d​racoomega> Yeah, certainly no blame from me. Just mildly unfortunate. 08:47:14 <09g​ammafunk> I just have to remember to get out of that habit of "just" pushing the tag that I seemed to have developed 08:50:47 <09g​ammafunk> rebuilding 0.34 on cao and cdi right now 08:56:11 Stable (0.34) branch on crawl.akrasiac.org updated to: 0.34.0-0-g19cb0921cb 09:01:37 <09g​ammafunk> I wonder if I could like delete that release and remake it to trigger package rebuilds 09:01:41 <09g​ammafunk> seems like it should work 09:01:56 <09g​ammafunk> I'll try that in a bit 09:10:11 <09g​ammafunk> interesting, the linux appimage does report its version correctly and even has the final updated changelog 09:10:17 <09g​ammafunk> %git 0.34.0 09:10:17 <04C​erebot> gammafunk * 0.34.0: Final changelog updates for 0.34.0 (15 hours ago, 2 files, 7+ 2-) https://github.com/crawl/crawl/commit/19cb0921cbcb 09:10:37 <09g​ammafunk> I'm slightly confused as to how that could be 09:11:17 <09g​ammafunk> perhaps the annotated commit somehow did cause the ref to be uploaded by git in some sense? 09:25:36 probably has to, since the tag is attached to the commit 09:26:16 <08o​____0> !versions cv<0.35-a 09:26:16 a tag is a pointer/ref to a commit, so the commit must be present 09:26:18 <04C​erebot> Latest versions seen in milestones this week (cv<0.35-a): [CNC] => 0.34-b1-24-g2e2e019, [CDI LLD] => 0.34-b1-41-gfa6b30b, [CBR2 CPO CUE CXC] => 0.34-b1-46-g4715434, [CAO] => 0.34.0, [CDO] => None 09:26:41 (aiui) 09:30:33 <09g​ammafunk> well this wasn't a light tag but an annotated one, though 09:30:56 <09g​ammafunk> which as I understand things live as refs in their own right 09:31:40 <09g​ammafunk> I haven't checked the debs or other builds, but the appimage does appear to have everything, so I guess re-release is (at least partially) not necessary 09:34:40 hm. it should still reference (depend on) the tagged commit, though, which means pushing it too 09:43:54 <08o​____0> (it does look correct in the debian build) 10:06:58 <09g​ammafunk> geekosaur: yeah, but that commit 0.34.0 was tagged off of clearly wasn't pushed (github shows this), and the dgl online builds also clearly were mis-versioned 10:07:52 <09g​ammafunk> in any case, I just need to remember to push the branch and then push the tag. I was so worried about the tag that I forgot the commit it was based on 10:11:06 <09g​ammafunk> !versions cv<0.35-a 10:11:10 <04C​erebot> Latest versions seen in milestones this week (cv<0.35-a): [CNC] => 0.34-b1-24-g2e2e019, [CDI LLD] => 0.34-b1-41-gfa6b30b, [CBR2 CPO CUE CXC] => 0.34-b1-46-g4715434, [CAO] => 0.34.0, [CDO] => None 10:11:19 <09g​ammafunk> hrm 10:11:50 <09g​ammafunk> uh oh 10:23:32 <09g​ammafunk> well, I managed to break 0.34 on cdi via the rebuild script 10:24:41 <09g​ammafunk> turns out if it loses or you break http connection during the install phase it can install the binary before it's made all the data dirs and then you have a problem because subsequent rebuilds won't try to do anything 10:25:26 <09g​ammafunk> but deleting the binary and re-running does fix that, so we're good now 10:25:47 <08o​____0> stressful 11:24:09 Stable (0.34) branch on cbro.berotato.org updated to: 0.34.0-0-g19cb0921cb 13:09:53 03gammafunk02 07* 0.35-a0-47-g35ae254118: Add the 0.34 tournament trunk reminder 10(69 seconds ago, 1 file, 1+ 1-) 13https://github.com/crawl/crawl/commit/35ae254118ef 13:26:50 In case anyone is curious about the answer to the question I asked yesterday (i.e. "how do you spawn a specific unrand item"), you can do so with a call like this: 13:26:51 items(true, OBJ_RANDOM, OBJ_RANDOM, 50, -unrand_id_of_your_choosing); 13:26:51 I think the only param there that matters is the last one, which is the unrand_type of the item you want to spawn multiplied by -1, or made negative. That is passed into the force_ego param, and when that's detected as negative it's made positive again and then that unrand is generated, overriding the type and subtype of the item (and everything 13:26:52 else that needs overriding), which is why the earlier params don't actually matter, since they specify that stuff. 13:26:52 This is very strange to me, and seems maybe like a leftover hack, but it does work and seems to be intended to work that way. It's also very fast and easy. 13:26:53 Anyway, thanks to all the folks who helped point me in the right direction! 14:01:47 I think it's rare (never?) that it's done other than by vault or mon-gear.cc 14:40:40 Makes sense. Well, if people like this concept maybe it becomes less rare, and if not then it's fine to use for a local idea. Either way, it's nice to have the idea working so I can finally test it. 16:46:16 Unstable branch on underhound.eu updated to: 0.35-a0-47-g35ae254118 (34) 17:39:13 Stable (0.34) branch on underhound.eu updated to: 0.34.0-0-g19cb0921cb 23:35:46 Unstable branch on crawl.develz.org updated to: 0.35-a0-47-g35ae254118 (34) 23:59:27 Windows builds of master branch on crawl.develz.org updated to: 0.35-a0-47-g35ae254118