Bug#545142: coreutils: ls -v sorts foo.z before foo.x-y
I ran into a similar issue with coreutils 8.32-3ubuntu1 amd64:
In a directory containing test cases, I typed
ls test4*.esp | cat | sort
and got the following:
test4a.esp
test4b.esp
test4c.esp
test4d.esp
test4e.esp
test4.esp
test4f.esp
test4g1.esp
test4g2.esp
test4g.esp
test4gL.esp
test4h.esp
test4i.esp
test4j.esp
test4k.esp
Note that test4e.esp appears before test4.esp, which appears before
test4h.esp, and no reasonable lexical ordering would do that.
ls test4*.esp | cat | sort -d
behaves the same way as does
ls test4*.esp | cat
so the issue is most likely in a sort function used by both ls and
sort. I'm submitting this to add what I hope will be a useful test
case.
On Sat, 5 Sep 2009 12:05:07 +0200 Piotr Engelking wrote:
> Package: coreutils
> Version: 7.4-2
> Severity: normal
>
> 'ls -v' sorts some names in a weird order:
>
> $ cd $(mktemp -d)
> $ touch foo.{x,x-y,z}
> $ ls -1
> foo.x
> foo.x-y
> foo.z
> $ ls -v1
> foo.x
> foo.z
> foo.x-y
> $ locale | grep ^LC_COLLATE
> LC_COLLATE="POSIX"
> $
>
> If I understand the documentation correctly, ls should sort names not
> containing numerical components in the same order with and without the '-v'
> option, which isn't the case.
>
> The bug is also present in coreutils 7.5-1.
>
>
> -- System Information:
> Debian Release: squeeze/sid
> APT prefers testing
> APT policy: (500, 'testing'), (400, 'unstable'), (300, 'experimental')
> Architecture: i386 (x86_64)
>
> Kernel: Linux 2.6.30 (SMP w/2 CPU cores)
> Locale: LANG=C, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/bash
>
> Versions of packages coreutils depends on:
> ii libacl1 2.2.48-1 Access control list shared
> library
> ii libattr1 1:2.4.44-1 Extended attribute shared library
> ii libc6 2.9-25 GNU C Library: Shared libraries
> ii libselinux1 2.0.85-2 SELinux shared libraries
>
> coreutils recommends no packages.
>
> coreutils suggests no packages.
>
> -- no debconf information
>
>
>
Bug#944738: jlink: Hash of module differs to expected hash recorded in java.base
I just ran into a similar problem: jlink --add-modules java.desktop --output test fails with this message: Error: Hash of java.xml (19574d688f234255aab0ff4ff8e88ae8190ecd7c8d2c422fbdb31cc10963b383) differs to expected hash (4473ef1f3d22979bd9136b21a520907553e3874435d88321999370312f1a) recorded in java.base jlink --add-modules java.base --output test works as expected. jlink --add-modules java.base,java.desktop --output test fails as well. jlink --add-modules jdk.httpserver -output test fails too, but this time the hash message complains about jdk.httpserver. java -version reports: openjdk version "11.0.8" 2020-07-14 OpenJDK Runtime Environment (build 11.0.8+10-post-Ubuntu-0ubuntu120.04) OpenJDK 64-Bit Server VM (build 11.0.8+10-post-Ubuntu-0ubuntu120.04, mixed mode, sharing) I'm running Pop OS 20.04 on a System-76 Thelio with a 64 bit AMD processor (but I don't see why this bug would be system dependent). It pretty much stops the use of jlink except in the most trivial case. Bill On Mon, 13 Jul 2020 20:24:29 -0700 tmanc...@debian.org wrote: > On Tue, Apr 07, 2020 at 09:40:52AM +0200, masar wrote: > > > > Hi, > > > > the bug is still present in > > > >openjdk-11-jdk 11.0.7+9-1 > > Hi Maurizio, > > In your initial bug report you said that you have a reproducible test > case with docker. Would you mind sharing that with me? > > FWIW, I happened to notice a similar bug reported against AdoptOpenJDK > builds (https://github.com/AdoptOpenJDK/openjdk-build/issues/1214) that > makes we wonder if there a common root cause, perhaps in the toolchains > used by both projects to build OpenJDK. > > Thank you, > tony
Bug#944738: jlink: Hash of module differs to expected hash recorded in java.base
I just ran into a similar problem: jlink --add-modules java.desktop --output test fails with this message: Error: Hash of java.xml (19574d688f234255aab0ff4ff8e88ae8190ecd7c8d2c422fbdb31cc10963b383) differs to expected hash (4473ef1f3d22979bd9136b21a520907553e3874435d88321999370312f1a) recorded in java.base jlink --add-modules java.base --output test works as expected. jlink --add-modules java.base,java.desktop --output test fails as well. jlink --add-modules jdk.httpserver -output test fails too, but this time the hash message complains about jdk.httpserver. java -version reports: openjdk version "11.0.8" 2020-07-14 OpenJDK Runtime Environment (build 11.0.8+10-post-Ubuntu-0ubuntu120.04) OpenJDK 64-Bit Server VM (build 11.0.8+10-post-Ubuntu-0ubuntu120.04, mixed mode, sharing) I'm running Pop OS 20.04 on a System-76 Thelio with a 64 bit AMD processor (but I don't see why this bug would be system dependent). It pretty much stops the use of jlink except in the most trivial case. Bill On Mon, 13 Jul 2020 20:24:29 -0700 tmanc...@debian.org wrote: > On Tue, Apr 07, 2020 at 09:40:52AM +0200, masar wrote: > > > > Hi, > > > > the bug is still present in > > > >openjdk-11-jdk 11.0.7+9-1 > > Hi Maurizio, > > In your initial bug report you said that you have a reproducible test > case with docker. Would you mind sharing that with me? > > FWIW, I happened to notice a similar bug reported against AdoptOpenJDK > builds (https://github.com/AdoptOpenJDK/openjdk-build/issues/1214) that > makes we wonder if there a common root cause, perhaps in the toolchains > used by both projects to build OpenJDK. > > Thank you, > tony
