Github messages for voidlinux
 help / color / mirror / Atom feed
From: ericonr <ericonr@users.noreply.github.com>
To: ml@inbox.vuxu.org
Subject: [PR PATCH] busybox: fix time64 patch.
Date: Tue, 09 Feb 2021 14:53:39 +0100	[thread overview]
Message-ID: <gh-mailinglist-notifications-41a7ca26-5023-4802-975b-f1789d68868e-void-packages-28607@inbox.vuxu.org> (raw)

[-- Attachment #1: Type: text/plain, Size: 1984 bytes --]

There is a new pull request by ericonr against master on the void-packages repository

https://github.com/ericonr/void-packages busy
https://github.com/void-linux/void-packages/pull/28607

busybox: fix time64 patch.
The syscall name was changed explicitly so compilation broke instead of
allowing programs using the raw syscall to use the time64 struct
timespec with a syscall expecting the old one.

Since we have modern glibc and musl, we can just force clock_gettime
usage.

The previous patch also broke y2038 support.

Not revbumping, since c085deae94a6fbd3d113eaceaaee4f0f947e091d didn't
either.

<!-- Mark items with [x] where applicable -->

#### General
- [ ] This is a new package and it conforms to the [quality requirements](https://github.com/void-linux/void-packages/blob/master/Manual.md#quality-requirements)

#### Have the results of the proposed changes been tested?
- [ ] I use the packages affected by the proposed changes on a regular basis and confirm this PR works for me
- [ ] I generally don't use the affected packages but briefly tested this PR

<!--
If GitHub CI cannot be used to validate the build result (for example, if the
build is likely to take several hours), make sure to
[skip CI](https://github.com/void-linux/void-packages/blob/master/CONTRIBUTING.md#continuous-integration).
When skipping CI, uncomment and fill out the following section.
Note: for builds that are likely to complete in less than 2 hours, it is not
acceptable to skip CI.
-->
<!-- 
#### Does it build and run successfully? 
(Please choose at least one native build and, if supported, at least one cross build. More are better.)
- [ ] I built this PR locally for my native architecture, (ARCH-LIBC)
- [ ] I built this PR locally for these architectures (if supported. mark crossbuilds):
  - [ ] aarch64-musl
  - [ ] armv7l
  - [ ] armv6l-musl
-->


A patch file from https://github.com/void-linux/void-packages/pull/28607.patch is attached

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: github-pr-busy-28607.patch --]
[-- Type: text/x-diff, Size: 3048 bytes --]

From d9df5aede027943443d4c30953d6de34b636bf97 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=C3=89rico=20Rolim?= <erico.erc@gmail.com>
Date: Tue, 9 Feb 2021 10:50:01 -0300
Subject: [PATCH] busybox: fix time64 patch.

The syscall name was changed explicitly so compilation broke instead of
allowing programs using the raw syscall to use the time64 struct
timespec with a syscall expecting the old one.

Since we have modern glibc and musl, we can just force clock_gettime
usage.

The previous patch also broke y2038 support.

Not revbumping, since c085deae94a6fbd3d113eaceaaee4f0f947e091d didn't
either.
---
 srcpkgs/busybox/patches/time64.patch | 48 +++++++++++++++++-----------
 1 file changed, 29 insertions(+), 19 deletions(-)

diff --git a/srcpkgs/busybox/patches/time64.patch b/srcpkgs/busybox/patches/time64.patch
index b38f4dcb97e..fc6531e85b0 100644
--- a/srcpkgs/busybox/patches/time64.patch
+++ b/srcpkgs/busybox/patches/time64.patch
@@ -1,28 +1,38 @@
---- coreutils/date.c	2019-06-10 12:50:53.000000000 +0200
-+++ coreutils/date.c	2021-02-09 12:39:19.127054192 +0100
-@@ -274,7 +274,11 @@
+diff --git coreutils/date.c coreutils/date.c
+index 3414d38..6e12f36 100644
+--- coreutils/date.c
++++ coreutils/date.c
+@@ -272,9 +272,7 @@ int date_main(int argc UNUSED_PARAM, char **argv)
+ #endif
+ 	} else {
  #if ENABLE_FEATURE_DATE_NANO
- 		/* libc has incredibly messy way of doing this,
- 		 * typically requiring -lrt. We just skip all this mess */
-+#if defined(__NR_clock_gettime32)
-+		syscall(__NR_clock_gettime32, CLOCK_REALTIME, &ts);
-+#else
- 		syscall(__NR_clock_gettime, CLOCK_REALTIME, &ts);
-+#endif
+-		/* libc has incredibly messy way of doing this,
+-		 * typically requiring -lrt. We just skip all this mess */
+-		syscall(__NR_clock_gettime, CLOCK_REALTIME, &ts);
++		clock_gettime(CLOCK_REALTIME, &ts);
  #else
  		time(&ts.tv_sec);
  #endif
---- libbb/time.c	2019-06-10 12:50:53.000000000 +0200
-+++ libbb/time.c	2021-02-09 12:35:35.125037118 +0100
-@@ -257,7 +257,11 @@
-  * typically requiring -lrt. We just skip all this mess */
+diff --git libbb/time.c libbb/time.c
+index f9b8da0..600b60b 100644
+--- libbb/time.c
++++ libbb/time.c
+@@ -247,17 +247,10 @@ char* FAST_FUNC strftime_YYYYMMDDHHMMSS(char *buf, unsigned len, time_t *tp)
+ #if ENABLE_MONOTONIC_SYSCALL
+ 
+ #include <sys/syscall.h>
+-/* Old glibc (< 2.3.4) does not provide this constant. We use syscall
+- * directly so this definition is safe. */
+-#ifndef CLOCK_MONOTONIC
+-#define CLOCK_MONOTONIC 1
+-#endif
+ 
+-/* libc has incredibly messy way of doing this,
+- * typically requiring -lrt. We just skip all this mess */
  static void get_mono(struct timespec *ts)
  {
-+#if defined(__NR_clock_gettime32)
-+	if (syscall(__NR_clock_gettime32, CLOCK_MONOTONIC, ts))
-+#else
- 	if (syscall(__NR_clock_gettime, CLOCK_MONOTONIC, ts))
-+#endif
+-	if (syscall(__NR_clock_gettime, CLOCK_MONOTONIC, ts))
++	if (clock_gettime(CLOCK_MONOTONIC, ts))
  		bb_error_msg_and_die("clock_gettime(MONOTONIC) failed");
  }
  unsigned long long FAST_FUNC monotonic_ns(void)

             reply	other threads:[~2021-02-09 13:53 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-09 13:53 ericonr [this message]
2021-02-09 15:31 ` ericonr
2021-02-09 15:31 ` [PR PATCH] [Merged]: " ericonr

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=gh-mailinglist-notifications-41a7ca26-5023-4802-975b-f1789d68868e-void-packages-28607@inbox.vuxu.org \
    --to=ericonr@users.noreply.github.com \
    --cc=ml@inbox.vuxu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).