GNU bug report logs -
#77756
[PATCH] gnu: utf8proc: add version 2.10.0
Previous Next
To reply to this bug, email your comments to 77756 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
guix-patches <at> gnu.org
:
bug#77756
; Package
guix-patches
.
(Sat, 12 Apr 2025 07:11:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Luis Pereira <luispereira.tkd <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
guix-patches <at> gnu.org
.
(Sat, 12 Apr 2025 07:11:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
I have successfully build neovim <at> 0.11.0 and want to submit the pat ches
that make it available for everyone.
As this is my first contribution, I'm submitting this update first, as
it is required to accomplish that build, hopping for feedback on
improving my contributions to follow guidelines.
I opted to create a new version of the package, like the previous
approach for 2.7.0, to avoid depency conflicts. Is this the preferable
approach?
Thanks
* gnu/packages/textutils.scm (utf8proc): Add version 2.10.0
Change-Id: I56646a37f7029bba4974b85e5cb593f798d0bfe0
---
gnu/packages/textutils.scm | 50 ++++++++++++++++++++++++++++++++++++++
1 file changed, 50 insertions(+)
diff --git a/gnu/packages/textutils.scm b/gnu/packages/textutils.scm
index c886b009be..428366b890 100644
--- a/gnu/packages/textutils.scm
+++ b/gnu/packages/textutils.scm
@@ -76,6 +76,7 @@ (define-module (gnu packages textutils)
#:use-module (gnu packages golang-crypto)
#:use-module (gnu packages golang-xyz)
#:use-module (gnu packages java)
+ #:use-module (gnu packages julia)
#:use-module (gnu packages ncurses)
#:use-module (gnu packages pcre)
#:use-module (gnu packages perl)
@@ -269,6 +270,55 @@ (define-public utf8proc-2.7.0
;; For tests
("ruby" ,ruby-2.7)))))))
+(define-public utf8proc-2.10.0
+ (package
+ (inherit utf8proc-2.7.0)
+ (name "utf8proc")
+ (version "2.10.0")
+ (source
+ (origin
+ (method git-fetch)
+ (uri (git-reference
+ (url "https://github.com/JuliaStrings/utf8proc")
+ (commit (string-append "v" version))))
+ (file-name (git-file-name name version))
+ (sha256
+ (base32 "1n1k67x39sk8xnza4w1xkbgbvgb1g7w2a7j2qrqzqaw1lyilqsy2"))))
+ (native-inputs (let ((UNICODE_VERSION "16.0.0"))
+ `(,(origin
+ (method url-fetch)
+ (uri (string-append
+ "https://www.unicode.org/Public/"
+ UNICODE_VERSION
+ "/ucd/DerivedCoreProperties.txt"))
+ (sha256 (base32
+ "1gfsq4vdmzi803i2s8ih7mm4fgs907kvkg88kvv9fi4my9hm3lrr"))) ,(origin
+
+ (method
+ url-fetch)
+
+ (uri
+ (string-append
+ "https://www.unicode.org/Public/"
+ UNICODE_VERSION
+ "/ucd/NormalizationTest.txt"))
+
+ (sha256
+ (base32
+ "1cffwlxgn6sawxb627xqaw3shnnfxq0v7cbgsld5w1z7aca9f4fq")))
+ ,(origin
+ (method url-fetch)
+ (uri (string-append
+ "https://www.unicode.org/Public/"
+ UNICODE_VERSION
+ "/ucd/auxiliary/GraphemeBreakTest.txt"))
+ (sha256 (base32
+ "1d9w6vdfxakjpp38qjvhgvbl2qx0zv5655ph54dhdb3hs9a96azf")))
+ ;; For tests
+ ,perl
+ ,ruby
+ ,julia)))))
+
(define-public libconfuse
(package
(name "libconfuse")
base-commit: f7c41ab31f5023023385500f6eb9083d23dd1ccb
--
2.49.0
Information forwarded
to
guix-patches <at> gnu.org
:
bug#77756
; Package
guix-patches
.
(Tue, 17 Jun 2025 15:20:03 GMT)
Full text and
rfc822 format available.
Message #8 received at 77756 <at> debbugs.gnu.org (full text, mbox):
Hello Luis,
thanks for your patch, which I notice now since it has bubbled up in QA.
Personally, I am not a fan of multiplying versions "to avoid dependency
conflicts". The first question is, are there any? Then, could they be easily
repaired, for instance by updating the corresponding packages?
So I would first try to simply update the utf8proc <at> 2.7 package to 2.10.
Then "guix build -P 1 utf8proc" tries to build all directly dependent
packages. Right now, this succeeds. If not, the command would stop at
the first failed package. You can also do
guix build -P 1 --keep-going utf8proc
which tries them all, even when there are failures; then a second
guix build -P 1 --dry-run utf8proc
will give you the list of all that still need to be built, otherwise
said, those that failed in the first run.
If some dependent packages fail and cannot easily be repaired, then
I would reintroduce the old one @2.7 (and move over as many dependent
packages as possible to the new one; which means, I would rather call
the new one utf8proc and the old one utf8proc-2.7, unlike what has been
done). In this way, only the packages that really need it still remain
on the old dependency.
Well, all this comes from a rather abstract perspective, without knowing
whether in the utf8proc case we expect the new version to be compatible
with the old one or rather not. But I think this is a good strategy of
moving forward with a better chance of one day removing the old library
versions.
If you report back on your findings, please keep me in cc, as with
debbugs I will not be automatically in copy.
Thanks again,
Andreas
This bug report was last modified 19 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.