Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1577872 - Apply upstream fixes for "ls" and "date"
Summary: Apply upstream fixes for "ls" and "date"
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: coreutils
Version: 28
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kamil Dudka
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 1546484
TreeView+ depends on / blocked
 
Reported: 2018-05-14 10:19 UTC by Rafal Luzynski
Modified: 2018-06-06 08:54 UTC (History)
11 users (show)

Fixed In Version: coreutils-8.29-11.fc29 coreutils-8.29-7.fc28
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-06-04 13:16:53 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)

Description Rafal Luzynski 2018-05-14 10:19:33 UTC 
Description of problem:

TLDR: It would be nice if upstream made a new release of coreutils 8.30 which fixes some bugs but while it is not available it would be nice to backport some upstream patches.

Long description:

Some issues related with the changes in date formats have been recently fixed upstream:

1. https://debbugs.gnu.org/cgi/bugreport.cgi?bug=19856 Bad month translation printed with date command in Greek locale

Actually caused by https://sourceware.org/bugzilla/show_bug.cgi?id=10871 (lack of support of multiple grammar cases for month names) and affects more languages than just Greek. This is fixed, new glibc is distributed by Fedora. What is missing is the lack of support of the new format specifiers: %OB, %Ob, and %Oh in date command line utility. Currently only %B, %b, %h are supported which is usually correct but custom formats should be supported for those who need them.

Fixed by the commit: http://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=b1fa4aa (later overridden by http://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=ad9b283 and http://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=3299901)

2. https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30814 Increase the value of MAX_MON_WIDTH in ls.c

As a consequence of the changes in dates the date column in "ls -l" is too narrow to fit the month name in several languages, for example in Catalan. Now March and May are both displayed as "de ma"; June and July both displayed as "de ju".


Version-Release number of selected component (if applicable): 8.29


How reproducible: always ("ls -l" issue depending on locale)


Steps to Reproduce:
1. Open a text console (Terminal, xterm, konsole, text mode)
2. Execute the command:

LC_ALL=ca_ES.utf8 ls -l

3. Execute the command:

date "+%OB"


Actual results:

If the current directory contains files last updated in March, May, June or July (any year) then "ls -l" in Catalan displays the month name as "de ma" which is ambiguous. The same problem may also appear in other languages.

The date command displays:

%OB


Expected results:

ls -l should have enough space to display the full abbreviated month name: "de març", "de maig", "de juny", "de jul." (yes, if the name of a month is short it is not abbreviated).

date should display the name of the current month, in all languages. If a language needs multiple grammar forms of a month name then the form appropriate when displaying a month standalone should be used (this usually means a nominative case)


Additional info:

See also my article, scroll down to Catalan: http://lingonborough.com/fedora-28-updates-for-czech-catalan-greek-and-lithuanian-users
Comment 1 Kamil Dudka 2018-05-14 16:14:55 UTC 
We can certainly pick the fixes from upstream.  Do you know which gnulib commits exactly are needed to fix this?

The coreutils commits you refer to just make coreutils pull a new gnulib snapshot while building coreutils from git.  This would have too many side effects to go to a stable release of Fedora.  We recently updated just a single gnulib module (fts) to the latest upstream snapshot and it triggered regressions in find and du (see bug #1558249).  So we need to be careful...
Comment 2 Rafal Luzynski 2018-05-14 21:17:01 UTC 
(In reply to Kamil Dudka from comment #1)
> We can certainly pick the fixes from upstream.  Do you know which gnulib
> commits exactly are needed to fix this?

Are you sure you want to fix gnulib which is a git submodule? OK, if you want, please start with this one which may be sufficient:

http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=4a236f1

If not then also those two:

http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=b5d3175
http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=703dcf1

Also worth looking:

http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=646a44e
http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=88cfbe6

> The coreutils commits you refer to just make coreutils pull a new gnulib
> snapshot while building coreutils from git.

I thought it would be easier. But:

> This would have too many side
> effects to go to a stable release of Fedora.  We recently updated just a
> single gnulib module (fts) to the latest upstream snapshot and it triggered
> regressions in find and du (see bug #1558249).  So we need to be careful...

... I see, OK.

Also, I forgot to say: the gnulib updates should be helpful to add %OB/%Ob/%Oh support to date command. Regarding "ls -l" probably the only patch required is this one:

http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=5ed2018

Kamil, I don't know what is your relationship with the upstream. Would it be easier if 8.30 was officially released? Do you participate in making this decision?
Comment 3 Kamil Dudka 2018-05-14 21:40:21 UTC 
(In reply to Rafal Luzynski from comment #2)
> Are you sure you want to fix gnulib which is a git submodule?

It is a git submodule if you build coreutils from the upstream git repository.  However, if you build coreutils from a release tarball, you simply have to patch gnulib source code directly because there is no git submodule to update and no script to re-import the selected gnulib snapshot into the source tree.

> Also, I forgot to say: the gnulib updates should be helpful to add
> %OB/%Ob/%Oh support to date command. Regarding "ls -l" probably the only
> patch required is this one:
> 
> http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=5ed2018

Thanks for all the references!  I will give it a try.

> Kamil, I don't know what is your relationship with the upstream. Would it be
> easier if 8.30 was officially released?

Unless the release is properly tested by upstream/downstream consumers (usually as in advance announced pre-releases), the resulting package will not be more stable than if we just built the latest upstream snapshot from git HEAD.

> Do you participate in making this decision?

Not really.  I can tell them my opinion on the upstream mailing list, similarly as you ;-)
Comment 4 Fedora Update System 2018-05-29 21:00:53 UTC 
coreutils-8.29-7.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-07e4af6bcf
Comment 5 Fedora Update System 2018-05-30 16:56:16 UTC 
coreutils-8.29-7.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-07e4af6bcf
Comment 6 Fedora Update System 2018-06-04 13:16:53 UTC 
coreutils-8.29-7.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.
Comment 8 Rafal Luzynski 2018-06-05 21:19:05 UTC 
Thank you for providing this fix to Fedora 28. Looks correct!
Comment 9 Kamil Dudka 2018-06-06 08:54:50 UTC 
Perfect.  Thanks for confirmation!
Note You need to log in before you can comment on or make changes to this bug.