From: J William Piggott <elseifthen@gmx.com>
To: Karel Zak <kzak@redhat.com>
Cc: Carlos Santos <unixmania@gmail.com>, util-linux@vger.kernel.org
Subject: Re: [ANNOUNCE] util-linux v2.35
Date: Sun, 26 Jan 2020 11:59:59 -0500 (EST) [thread overview]
Message-ID: <nycvar.YAK.7.76.2001261131130.3053@zhn.tzk.pbz> (raw)
In-Reply-To: <20200125105126.xaopgydc7dlrpztt@x2.net.home>
On Sat, 25 Jan 2020, Karel Zak wrote:
> On Fri, Jan 24, 2020 at 04:16:47PM -0300, Carlos Santos wrote:
>
>> That's a problem. It makes hwclock hard to include in embedded systems
>> due to the GPLv3 restrictions.
>>
>> I noticed that it comes due to sys-utils/hwclock-parse-date.y, which
>> was taken from gnulib. Would it be possible to take the file from an
>> previous version of gnulib that was still under GPLv2?
>>
>> An alternative approach would be porting a similar code using a more
>> liberal license, e.g. BSD.
>>
>> What do you think?
>
> I have tried to export it from gnulib with v2, but it was impossible
> by official gnulib tools. Maybe do it manually from some old
> tarball. I'll accept a patch for this if you have time do it.
You do realize that I had to heavily modify that file to remove its
gnulib dependencies (because you said no to gnulib). If I recall
correctly I had newer and older versions to chose from and picked that
one due to it having the most bugs fixed while still being practical to
strip its gnulib dependence.
The reasons for making the change were:
* remove hwclock's dependence on date(1)
* remove an insecure call to date(1)
* I thought there would be to many complaints if the accepted input
date formats were changed
As to the last bullet point; personally I think having the --date option
accept every date syntax know to history is nonsense. A fixed format
would be fine with me. Since we switched hwclock's output to ISO 8601
that seems like a good choice for its input. Or you could just use the
existing utillinux date parser.
The question is, do you want to deal with any pushback for
changing the long established accepted --date formats?
>
> I'll like to release 2.35.1 ASAP (due to bug in sfdisk --move-data),
> so we can add this license change too.
>
> Karel
>
> --
> Karel Zak <kzak@redhat.com>
> http://karelzak.blogspot.com
>
>
next prev parent reply other threads:[~2020-01-26 17:00 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-21 10:57 [ANNOUNCE] util-linux v2.35 Karel Zak
2020-01-24 19:16 ` Carlos Santos
2020-01-25 10:51 ` Karel Zak
2020-01-25 11:19 ` Carlos Santos
2020-01-26 16:59 ` J William Piggott [this message]
2020-01-26 17:50 ` Carlos Santos
2020-01-27 16:13 ` Karel Zak
2020-01-27 16:38 ` Carlos Santos
2020-01-27 20:18 ` Karel Zak
2020-01-27 13:34 ` Karel Zak
2020-01-27 13:40 ` Karel Zak
2020-01-27 15:25 ` Karel Zak
2020-01-27 16:29 ` Carlos Santos
2020-01-27 20:21 ` Karel Zak
2020-01-28 19:24 ` Sami Kerola
2020-01-30 11:17 ` Karel Zak
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=nycvar.YAK.7.76.2001261131130.3053@zhn.tzk.pbz \
--to=elseifthen@gmx.com \
--cc=kzak@redhat.com \
--cc=unixmania@gmail.com \
--cc=util-linux@vger.kernel.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).