From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id 8573C2113E for ; Sun, 7 Apr 2024 21:50:29 +0200 (CEST) Received: (qmail 13673 invoked by uid 550); 7 Apr 2024 19:50:23 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 13629 invoked from network); 7 Apr 2024 19:50:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.net; s=s31663417; t=1712519414; x=1713124214; i=nullplan@gmx.net; bh=8N0JKoX0bTlZUPl9tqxf1Eh7Rh70gaxjxgDXIlkNF9w=; h=X-UI-Sender-Class:Date:From:To:Cc:Subject:References: In-Reply-To; b=dtjvwjYHP4f2BOIM0fEZIlZ/YA2qIJaE7X/jXYWP9/mysyjsDF7IVc6sr6d4P4iC eBJLtdlnQbywldmUb6r5DlnLjl3rxxzwW+DTHpvHHI4bi7koR3fACwS5/z7LOo2ug E2d8WZYrtzn+dQd9fLoKOfbGvMPiN0JlDmz3a3l72l68hO8ldCtZCtUHpUVwubzn4 oy5yy0qZJsCAKKQSuZWeCOUx+XrVDdJi9onpbr1r3auggwWprv3Vot2ooOBSw3R+Z pPCKGFt1BJYGc2eS8QTIF1VgqBnljzwQjh1hYUoKIUHyNrdEUlgL+U71ibDU80DDf lEDJhWaR+b9NzzbWew== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Date: Sun, 7 Apr 2024 21:50:13 +0200 From: Markus Wichmann To: Thomas Petazzoni Cc: Waldemar Brodkorb , musl@lists.openwall.com Message-ID: References: <20240407191848.5c811765@windsurf> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Provags-ID: V03:K1:inVqz7kDxbCupqhyRQoU9PdR2TgwpLV9dxeCKTv1hTqW88Ldenf LKm0qpxoM7gQI6P8HrujQPSS+1a2NrzZSjUoJj+qvy/txVagCxx+KyZumXLiIX33eWdheWg St0l3EqYUADoNYbLlj/C2OZrjtmX0rcZ/bcAAiBm+6kmdAN3jwaNAUBbwqVH6HrQkArn+R/ 2Ar8ryF/PB10eUVwaalFw== UI-OutboundReport: notjunk:1;M01:P0:n4dt4VKls84=;+Y+1ESMOwnQKXui8yMByeS6dSst vPklvsU59YS/S+NcuEvvtH0fsLq3bcK/9I3jCQgZTsZ3ufCsTeDmj1Zv7gGiXSlw/w0xJMftR RT3eDxrAakATN+bzb4HXpHF/5VRifC5V1IBfdirAwXRxSFt3WTt4C0xTEzOIqvH1RCJKYF1n4 iQIcnRvjKP8miHQG0EzAh+/ENe0Zg8XK8I78+XB11oTiFL7HkPkvfi/y5hJPwS6Kyk66wrg76 +w/mkMeiQ6SrryUa1whA8kZ2KduRPMT+bVntSW9i6VQF/GATRzSJHa6UxDWdO1EAXvinQ5Lzx OD9CSdpy3BNnyCkkYifymNM6sOdwNnmcQSoDrgjQH8naaIPLQ9+4V0xaSYLoDvdqS/d5Jydgc DDhNFA81e8dGiyF72v9BNLTQNNZzc134ldk5Kg2uyruu8K3gas+oXzFGIY3Fo/GAuNJoo0Fq0 49c+t85PsH6eU57hO1bdjpoVHAjOzbt2HnoMLzmkqHQJ7VpoEgW4DKmgAxwy9C4xuEa8WGRby oi3f+J9UK5DyAbB4g48gia5d4fuhdjdQywr6hpWQ0OvtMnfxDQdbQeKD8HkqR6DPF2FCLXimU II4FMz05UE5aysQdDERPqgssuSyVH4oG12tp0ah9aUzP+ATOeDlFZFKo3wzAqt0SjG0ZMJprM B3PItuFmgdgyE78B/mAIR2x8gJeY2rwTTWykg7oTQme8ZmDZcj/4WEt+rwWfE7g1nfTRz/o/6 ptP68GvrW2d7Rtzcg6QvdcducyjHnpe/mB0h5p92KvqQQo7L7SMwdS9QrazvNXIDFgKtheBGQ fAuBpMkLizd5QH+29ipNc+T6WfHceEY4t1lzixHmH/bKM= Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] Busybox hwclock failing to build with musl RISC-V 32-bit: SYS_settimeofday undefined Am Sun, Apr 07, 2024 at 07:37:03PM +0200 schrieb Markus Wichmann: > Hi, > > this is a very much a Busybox problem. musl does provide settimeofday(), > but it doesn't send the time zone to the kernel. This is because the > kernel time zone has some hardcoded unexpected uses, to be nice about > it. > > The Busybox maintainers don't like that musl doesn't do this, and so > call the syscall directly. And this fails for RISC-V, which doesn't have > a SYS_settimeofday. I mean, it also fails for all the 32-bit > architectures which do have a SYS_settimeofday but with a different > timeval structure. But maybe the timezone structure is correct there. > > Busybox is trying to do the wrong thing here, simple as. The reasoning > for not doing the right thing I have read is spurious at best. If the > hwclock time is in local time, then /etc/localtime should be the correct > time zone, and mktime() will provide the closest you are going to get to > a "right" system time. > > Note that we recently had a thread about the perils of local time, and > it is simply a mess, and sometimes libc has no good choices. > > Ciao, > Markus On an unrelated note, you may need to quote the entire message I sent before because the Busybox mailing list refused my message since I am not subscribed to it. And nor do I want to be. Ciao, Markus