12:44:19 . 12:44:20 `. 12:44:44 damned. it should have been enter-tilda-^b :-) 12:47:36 would you like to tell about your cat walking over the keyboard? :) 13:01:09 denk: the only cat i have is /bin/cat :-D 13:03:20 * yuripv feels sorry for otis 13:09:12 yuripv: but i've got some Big Scary Daemons here. :-) 13:27:03 I was trying to find out why ioctl fails in format I have this https://termbin.com/cwif that traces ioctl return values; and the function where it's called https://termbin.com/hy6d 13:28:06 but now I'm searching what the return values means for the ioctl, or I'm missing something? . Basically I'm trying to find out why a disk appears as unformatted in oracle cloud. 13:35:16 arg1 should be an errno (arg0 is an offset into the function where the return occured) 13:35:40 So that one that returns 25 is ENOTTY 25 /* Inappropriate ioctl for device */ 13:36:21 and scsi_rdwr is returning -1 13:37:17 that is reading the input though, so unlikely to be interesting 13:37:52 the only one that makes sense is at the bottom, is in the is_efi_type() 13:43:25 andyf where did you find the ENOTTY value ?, is odd that returns 25 as that scsi_rdwr tries to write 4 bytes to check if the disk is formatted 13:43:40 /usr/include/sys/errno.h 13:48:26 But as yuripv notes, is_efi_type() is returning EIO 13:52:39 Have you tried `format -e` at all and tried to write a fresh EFI label? 14:05:37 andyf with format -e returns the following https://termbin.com/z49w3 14:06:04 yuripv I'll check is_efi_type 14:27:28 yuripv is_efi_type returns 0 checking it with dtrace, is that correct for virtioscsi ?https://src.illumos.org/source/xref/illumos-gate/usr/src/cmd/format/startup.c?r=dcc43656#1796 14:55:55 Here is the output for scsi option in format, maybe someone more knowledgeable sees something strange https://termbin.com/ncyob 15:28:29 andyf format -e then label returns Current Disk is unformatted. 15:31:32 https://www.openssl.org/blog/blog/2023/03/28/1.1.1-EOL/ 15:37:09 neirac what device is behind that disk? 15:38:54 tsoome is a virtioscsi AFAIK c1t0d1 15:40:49 oh ok, its cloud, so you have no idea what is back end (silly me) 15:41:52 so, what does format -> format tell?:) 15:47:29 tsoome https://termbin.com/uxcu 15:48:12 sort of makes sense. 15:50:35 that scsi_rdwr() returns -1, but I guess you figured that already 15:53:37 tsoome and is_efi returns 0 15:54:44 is_efi() only can return 2 values, and if you look into it, you can see the problem there.... 15:56:10 if there was issue with transport, you can not trust the return value from is_efi 15:57:38 tsoome I also tried hardcoding is_efi return value to see how far it got, but I see no changes on the situation 15:59:13 well of course - if you are getting scsi IO failures, you would need to find out the cause for that first 19:16:37 danmcd, andyf: apparently apple are rolling out 2023b (staged), and 2023c isn't out yet 19:17:05 also apparently 2023c makes lebanese daylight savings start on wednesday, not sunday when it originally did, or in april when they tried to. 19:17:19 so that might be a rush job with little notice _as well_ depending on how the tz people do it 19:17:52 Officially I'm not rolling out anything until next week Thursday 0000GMT. But good to know Apple is working with 2023b. 19:18:13 Keeps us on our toes! 19:46:32 I was under the impression that 2023c is a rollback to 2023a 19:47:09 sommerfeld: I thought so too, but I read on the list that what the cabinet actually said was that it starts wednesday now, I didn't know whether eggert was going to keep the few days in the interim for historical purposes 19:47:20 or if it's all such a mess they aren't bothering. 19:48:16 I also love both the whackiness of the "maximum of one release a month" person, and the "We can't possibly choose our timezone with more than 4 weeks notice!" replies. 20:06:20 we had already integrated 2023b before we knew about the coming reversion, but won't have the bits shipped for weeks anyway, so it won't matter much 20:31:25 alanc, sommerfeld: actually, since you're both around and have a lot of historical wisdom: Do you know why we never just put .KEEP_STATE: in Makefile.master? 20:31:41 does it not do what you'd think through inclusion? is there some place we _intentionally_ don't keep state? 20:38:01 I don't understand why we all hold to noon has to be 12ish 20:38:15 One time for everyone and just live at offsets 20:38:29 * sjorge crawls back under his blanket 20:38:33 sjorge: it's because of railways 20:38:45 before then, noon was when the sun was at its highest locally. 20:39:05 but once you get railways, you need everyone to basically agree on what time it is, and everything sucks. 20:46:54 The information super railway 20:47:52 I have an `sdate` program that shows me _actual_ local time 20:47:59 but I always forget it by definition leaks my precise location :) 20:49:18 Ba 20:49:21 *Ha 21:03:15 richlowe: does it take into account the day-to-day variation in local solar noon over the course of the year, or is it just based on local mean solar time? 21:04:59 i'm using a rPI2 with 2 GPS' for time fix and one of them has a PPS source 🤓 cant get more better than that without throwing money at it 😅 21:05:25 richlowe: only half of it 21:06:49 sjorge: I would prefer just switching to TAI all the time 21:08:14 I'd just prefer the clocks to go forward at 4pm on a Friday, if they're going to, not 1am on Sunday. 21:13:42 sommerfeld: I think I did as fully as I could understand the calculations for, but it's been a while 21:13:48 and now I'm worried it's less precise than it could be! 22:29:43 and 2023c is out... 22:33:16 richlowe: I don't know about .KEEP_STATE 22:56:57 richlowe: oh, sorry, I missed the Q about .KEEP_STATE. Not sure about that, either. Worth an experiment but I wouldn't be surprised if there were unintended consequences (additional build churn or racy behavior in parallel builds)