License Problem and Other Questions defining new package Geant4 from CERN for Partical Physcis Simulation
Dear developers at Guix, I am a physics student willing to use the Geant4 simulation toolkit from the European Organization for Nuclear Research (CERN). https://geant4.web.cern.ch/ The Geant4 code is distributied under its own licence, Geant4 Software License Version 1.0. https://geant4.web.cern.ch/license/LICENSE.html Let's call this license G4SL1.0. After some searching, finding it is NOT listed by FSF or GNU in their license list. https://www.gnu.org/licenses/license-list.html But from a personal perspective, G4SL1.0 do seems like a free software license. So, may it be included into the Guix proper (gnu packages)? I am currently testing the package under a custom channel,using cmake-build-system. https://git.nju.edu.cn/nju/chngix/-/blob/master/gix/packages/geant4.scm Here is another problem: during configuring command "cmake" on a non-Guix system, -- Geant4 has been pre-configured to look for datasets in the directory: -- /usr/local/share/Geant4-10.7.1/data the user needs to download datasets and unpack them under that directory. https://geant4.web.cern.ch/support/download Or, set flag -DGEANT4_INSTALL_DATA=ON to automatically download the datasets during building. On Guix however, -- Geant4 has been pre-configured to look for datasets in the directory: -- /gnu/store/byprhqa1qq6s0ksgdpjgwv58ak25kprd-geant4-10.07.p01/share/Geant4-10.7.1/data the building process is sandboxed, and does not allow download during building that causing non-repuduciable build result. Cmake flag GEANT4_INSTALL_DATADIR defaults to "share", a path relative to CMAKE_INSTALL_PREFIX, and it can be set to define the directory storing datasets other than ../share, but datastes should always be under "GEANT4_INSTALL_DATADIR/Geant4-10.7.1/data". https://geant4-userdoc.web.cern.ch/UsersGuides/InstallationGuide/html/installguide.html#geant4buildoptions But the (source origin) denotes "a file" only, https://guix.gnu.org/manual/en/html_node/package-Reference.html is it possible to define a package fetching multiple files and extracts them into the desired directory, using the Guix package definition? I am not familiar with trivial-build-system. The build and install of the geant4 without datasets using cmake-build-system seems to be successful. Your help would be much appreciated. With best regards, Sebastian
Bad GPG sig on guix .16.0x86_64
Hello, Developer. I was intreged by the OS and decided to try it. I noticed that the GPG sig was bad and thought I should let you know. (or perhaps I did something wrong, let me know.) Terminal: seb@seb-pc ~/Downloads> gpg --verify guixsd-install-0.16.0.x86_64-li gpg: no signed data gpg: can't hash datafile: No data seb@seb-pc ~/Downloads> gpg --verify guixsd-install-0.16.0.x86_64-li0.x86_64-linux.iso gpg: Signature made Thu 06 Dec 2018 09:32:25 AM MST gpg:using RSA key 3CE464558A84FDC69DB40CFB090B11993D gpg: Can't check signature: No public key seb@seb-pc ~/Downloads> gpg --keyserver pool.sks-keyservers.net \ --recv-keys 3CE464558A84FDC69DB40CFB09 gpg: key 090B11993D9AEBB5: 124 signatures not checked due to missing gpg: key 090B11993D9AEBB5: public key "Ludovic Courtès gpg --verify guixsd-install-0.16.0.x86_64-li0.x86_64-linux.iso gpg: Signature made Thu 06 Dec 2018 09:32:25 AM MST gpg:using RSA key 3CE464558A84FDC69DB40CFB090B11993D gpg: BAD signature from "Ludovic Courtès " [unknown]
Expat 2.4.9 released, includes security fixes
Hello everyone! Expat 2.4.9 has just been released. Most importantly this release fixes CVE-2022-40674. There will be a summary blog post at [1] soon and the change log is at [2] with more details already. If you have patches for Expat that are still required with version 2.4.9, please send them my way. Thank you! Best Sebastian [1] https://blog.hartwork.org/posts/expat-2-4-9-released/ [2] https://github.com/libexpat/libexpat/blob/R_2_4_9/expat/Changes
Format specification issue in the translations...
Hi! I'm involved in the translation of Shepherd to Swedish, and poedit complains that the format specifications for the singular and plural forms of one of the strings are not the same: https://git.savannah.gnu.org/cgit/shepherd.git/tree/modules/shepherd/service.scm#n1107 Later on in the source there is another string where the format specifications appear to be identical: https://git.savannah.gnu.org/cgit/shepherd.git/tree/modules/shepherd/service.scm#n1221 If this is not a bug, please help me understand what can be done to make the translation tools not complain (even translationproject.org complains when I submit the .po-file). If this is indeed a bug in the source, do you mind fixing it? I'm not sure how your development process works, but if it helps I can fix it in a clone of the repo and post a link here..? / Sebastian
Re: Format specification issue in the translations...
Hi Florian!
> in German I have translated in this way and it got
> accepted.
Yes, my fellow Swedish translator pointed that out to me! :)
I will contribute a similar translation in Swedish, but I also
want the bug in the original code fixed.
I have attached my attempt at a patch to this mail.
Maybe someone can review it and help push it to git HEAD?
> Although, I have not actually tested if it displays
> correctly. I assume Guile formatting is tolerant.
I have no means to easily test this either.
/ Sebastian
On Tue, May 23, 2023 at 12:44 PM pelzflorian (Florian Pelz)
wrote:
>
>
> #: modules/shepherd/service.scm:1087
> #, scheme-format
> msgid "Cannot unregister service ~a, which is still running"
> msgid_plural "Cannot unregister services~{ ~a,~} which are still running"
> msgstr[0] "Der Dienst~{ ~a,~} bleibt registriert, weil er noch läuft"
> msgstr[1] "Die Dienste~{ ~a,~} bleiben registriert, weil sie noch laufen"
>
> Regards,
> Florian
From a7964514651c4f7852d930e6c0e38d06583fcd15 Mon Sep 17 00:00:00 2001
From: Sebastian Rasmussen
Date: Tue, 23 May 2023 12:52:36 +0200
Subject: [PATCH] service: Fix localization string formatting.
* modules/shepherd/service.scm: Change the singular/plural formatting
to be the same in order to avoid translation tool warnings.
---
modules/shepherd/service.scm | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/modules/shepherd/service.scm b/modules/shepherd/service.scm
index e3ca910..c501a68 100644
--- a/modules/shepherd/service.scm
+++ b/modules/shepherd/service.scm
@@ -1104,8 +1104,8 @@ requests arriving on @var{channel}."
(loop (unregister services)))
(lst ;
(local-output
- (l10n "Cannot unregister service ~a, which is still running"
- "Cannot unregister services~{ ~a,~} which are still running"
+ (l10n "Cannot unregister service ~{ ~a,~} which is still running"
+ "Cannot unregister services ~{ ~a,~} which are still running"
(length lst))
(map service-canonical-name lst))
(loop registered
--
2.39.2
Expat 2.2.10 has been released
Hello everyone! Simplified, Expat 2.2.10 comes with bugfixes and with improvements to the build system, mostly the secondary CMake one. The change log with details is up at [1]. If you happen to using CMake in packaging Expat already, please share any pain points and issues with me so that things improve further by the next release. If you happen to have patches for Expat that are still required with 2.2.10, please send them my way. Thanks and best Sebastian [1] https://github.com/libexpat/libexpat/blob/R_2_2_10/expat/Changes
Expat 2.3.0 has been released
Hello everyone! Expat 2.3.0 — simplified — brings… - bugfixes, - improvements to both build systems, and - improvements to xmlwf usability. Please see the changelog at [1] for more details. If you have patches for Expat that are still required with version 2.3.0, please send them my way. Thank you! Best Sebastian [1] https://github.com/libexpat/libexpat/blob/R_2_3_0/expat/Changes
Expat 2.2.6 released
Hi everyone! I would like to let you know that Expat 2.2.6 has just been released. Besides improvements to the build system, 2.2.6 is a bugfix release. For more details please check the change log at [1]. If you happen to have patches for Expat that are still required with 2.2.6, please send them my way. Thanks and best Sebastian [1] https://github.com/libexpat/libexpat/blob/R_2_2_6/expat/Changes
Expat 2.2.1 with security fixes has been released
Hi! I'm contacting you because Expat 2.2.1 -- containing security fixes -- has just been released. For details please check the change log, online at https://github.com/libexpat/libexpat/blob/master/expat/Changes . Best Sebastian
Expat in GuixSD, please update
Hi GuixSD team, from looking at [1] and [2] my impression is that GuixSD is still at version 2.2.2 with Expat, while there is version 2.2.4 with bugfixes upstream. Is there anything blocking an update on your side that needs fixing upstream? Best Sebastian [1] https://repology.org/metapackage/expat/versions [2] https://www.gnu.org/software/guix/packages/e.html
Re: Expat in GuixSD, please update
Sorry, no time. On 25.10.2017 16:05, Vincent Legoll wrote: > Hello, > > maybe you can try to submit a patch for review... > > That ought to be fairly easy >
Re: Expat 2.3.0 has been released
Hello everyone, just a quick heads up that there will be a new release of libexpat with security fix in a few weeks. Unless I looked in the wrong place, I noticed that your distro has not updated to libexpat 2.3.0 as of today. If you ran into any issues with packaging 2.3.0, please let me know now so that I can fix things upstream for you and everyone while there is still a window before next releases to do so. Thank you! Best Sebastian On 25.03.21 21:27, Sebastian Pipping wrote: > Hello everyone! > > > Expat 2.3.0 — simplified — brings… > > - bugfixes, > > - improvements to both build systems, and > > - improvements to xmlwf usability. > > Please see the changelog at [1] for more details. > > > If you have patches for Expat that are still required > with version 2.3.0, please send them my way. Thank you! > > Best > > > > Sebastian > > > [1] https://github.com/libexpat/libexpat/blob/R_2_3_0/expat/Changes >
Re: Expat 2.3.0 has been released
Hi Maxime, On 09.05.21 11:17, Maxime Devos wrote: > I see Leo Prikler has already sent a patch (48...@debbugs.gnu.org). yes, thanks for you interest in the topic. On 09.05.21 11:12, Maxime Devos wrote: > According to "guix refresh -l", simply updating expat would entail rebuilding > 6031 > packages. This can be avoided is v2.4.0 is binary compatible with v2.2.9. > Is this the case? The short answer is: there is no break of ABI. A longer answer would include that the next release will also be hiding a previously exposed internal symbol by the name "_INTERNAL_trim_to_complete_utf8_characters". I don't consider that an ABI break but we'll probably find someone who does, on a technical level. The related soversions are: 2.2. 9 = 7:11:6 -> libexpatso.1.6.11 (GUIX today) 2.2.10 = 7:12:6 -> libexpatso.1.6.12 2.3. 0 = 8: 0:7 -> libexpatso.1.7.0 (GUIX W.I.P.) 2.4. 0 = 9: 0:8 -> libexpatso.1.8.0 (upcoming) I wish related tool https://verbump.de/ was more widely known. Best Sebastian
Re: Expat 2.3.0 has been released
On 09.05.21 16:07, Leo Famulari wrote: > On Sun, May 09, 2021 at 02:53:09PM +0200, Sebastian Pipping wrote: >> The related soversions are: >> >> 2.2. 9 = 7:11:6 -> libexpatso.1.6.11 (GUIX today) >> 2.2.10 = 7:12:6 -> libexpatso.1.6.12 >> 2.3. 0 = 8: 0:7 -> libexpatso.1.7.0 (GUIX W.I.P.) >> 2.4. 0 = 9: 0:8 -> libexpatso.1.8.0 (upcoming) > > Alright, in this case we'll need to cherry-pick the relevant bug fixes. > > See the manual section Security Updates for this note: > > "Other restrictions may apply: for instance, when adding a graft to a > package providing a shared library, the original shared library and its > replacement must have the same SONAME and be binary-compatible." The soname is the same: it's libexpatso.1 for all of them — no? # objdump -p libexpat.so.1.7.0 | grep SONAME SONAME libexpat.so.1 They are binary-compatible. So I think there may be a misunderstanding here.
Re: Expat 2.3.0 has been released
Hi Marius, On 10.05.21 00:07, Marius Bakke wrote: > Sebastian Pipping skriver: > >> Hello everyone, >> >> >> just a quick heads up that there will be a new release of libexpat with >> security fix in a few weeks. Unless I looked in the wrong place, I >> noticed that your distro has not updated to libexpat 2.3.0 as of today. >> If you ran into any issues with packaging 2.3.0, please let me know now >> so that I can fix things upstream for you and everyone while there is >> still a window before next releases to do so. Thank you! > > Hi Sebastian, > > I have updated expat on our "core-updates" branch, since it entails a > full rebuild: > > > https://git.savannah.gnu.org/cgit/guix.git/commit/?h=core-updates&id=831c6d84e1bcff4b68dfd0f6e299f2c0bb60d0b8 > > I notice 2.3.0 does not have any ABI changes from 2.2.9. In that case > the security fix/version can be "grafted" in place without rebuilding > the world. So count us ready, we'll test 2.3.0 meanwhile. :-) Thank you! Best Sebastian
Expat 2.4.0 (and 2.4.1) with security fixes released
Hello everyone! Expat 2.4.0 (and 2.4.1) most importantly brings protection against Billion Laughs Attacks (CVE-2013-0340). There is a blog post [1] and the change log with more details. If you have patches for Expat that are still required with version 2.4.1, please send them my way. Thank you! Best Sebastian [1] https://blog.hartwork.org/posts/cve-2013-0340-billion-laughs-fixed-in-expat-2-4-0/ [2] https://github.com/libexpat/libexpat/blob/R_2_4_1/expat/Changes
Re: Expat 2.4.0 (and 2.4.1) with security fixes released
Hi everyone, more than half of you have updated to 2.4.1 already [1], very nice. Please let me know if you need any help with updating or backporting or something like that. Thanks and best Sebastian [1] https://repology.org/project/expat/information On 24.05.21 01:01, Sebastian Pipping wrote: > Hello everyone! > > > Expat 2.4.0 (and 2.4.1) most importantly brings protection against > Billion Laughs Attacks (CVE-2013-0340). There is a blog post [1] and > the change log with more details. > > If you have patches for Expat that are still required with version > 2.4.1, please send them my way. Thank you! > > Best > > > > Sebastian > > > [1] > https://blog.hartwork.org/posts/cve-2013-0340-billion-laughs-fixed-in-expat-2-4-0/ > [2] https://github.com/libexpat/libexpat/blob/R_2_4_1/expat/Changes >
Expat 2.4.3 with security fixes released
Hello everyone! Expat 2.4.3 with security fixes has been released. There is a summary blog post [1] and the change log [2] with more details. If you have patches for Expat that are still required with version 2.4.3, please send them my way. Thank you! Best Sebastian [1] https://blog.hartwork.org/posts/expat-2-4-3-released/ [2] https://github.com/libexpat/libexpat/blob/R_2_4_3/expat/Changes
Expat 2.4.4 with security fixes released
Hello everyone! Expat 2.4.4 with security fixes has been released. There is a summary blog post [1] and the change log [2] with more details. If you have patches for Expat that are still required with version 2.4.4, please send them my way. Thank you! Best Sebastian [1] https://blog.hartwork.org/posts/expat-2-4-4-released/ [2] https://github.com/libexpat/libexpat/blob/R_2_4_4/expat/Changes
Expat 2.4.5 with security fixes released
Hello everyone! Expat 2.4.5 with security fixes has been released. Please note that different people evaluate the impact of security issues differently: 2 of those 5 vulnerability allow proven code execution not within Expat but in (some) applications using Expat, and hence they are "critical" on my personal scale while e.g. Ubuntu considers these two as "low" and "medium" respectively, only. I have contacted Ubuntu security about that earlier today but have yet to hear back. There will be a summary blog post at [1] and the change log is at [2] with more details already. If you have patches for Expat that are still required with version 2.4.5, please send them my way. Thank you! Best Sebastian [1] https://blog.hartwork.org/posts/expat-2-4-5-released/ [2] https://github.com/libexpat/libexpat/blob/R_2_4_5/expat/Changes
Expat 2.4.7 released
Hello everyone! Expat 2.4.7 has just been released. Most importantly this release relaxes the fix to CVE-2022-25236 (introduced with release 2.4.5) which some of your you have been waiting for. There will be a summary blog post at [1] soon and the change log is at [2] with more details already. If you have patches for Expat that are still required with version 2.4.7, please send them my way. Thank you! Best Sebastian [1] https://blog.hartwork.org/posts/expat-2-4-7-released/ [2] https://github.com/libexpat/libexpat/blob/R_2_4_7/expat/Changes
Expat 2.2.7 with security fixes has been released / CVE-2018-20843
Hello everyone! Sorry for the noise if you heard about the release of 2.2.7 about a week ago through some other channel and maybe even took action, already! To be quick, there is one DoS fix — for CVE-2018-20843 [1] — and misc build system fixes. The change log with details is up at [2]. If you happen to have patches for Expat that are still required with 2.2.7, please send them my way. Thanks and best Sebastian [1] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20843 [2] https://github.com/libexpat/libexpat/blob/R_2_2_7/expat/Changes
Re: Expat 2.2.7 with security fixes has been released / CVE-2018-20843
Hi Jack, On 12.07.19 01:17, Jack Hill wrote: > I'm pleased to let you know that we've applied the fix for > CVE-2018-20843 in GNU Guix as of > 5a836ce38c9c29e9c2bd306007347486b90c5064 [0]. We elected to backport the > patch that fixed the problem instead of upgrading due to a change in the > expat abi with 2.2.7 [1]. > > Many thanks to Marius Bakke for advice and patience while reviewing the > patches. > > [0] > http://git.savannah.gnu.org/cgit/guix.git/commit/?id=5a836ce38c9c29e9c2bd306007347486b90c5064 > > [1] https://issues.guix.gnu.org/issue/36424#2 thanks for the update on that matter! Regarding the removed API symbols, those were never part of the public API so whoever used them needed to have copied prototypes for those into his own code base and be aware that using internal API is asking for trouble — the opposite of something to rely on. They made that choice, it should be their cost. openSuse started using -fvisibility=hidden with their expat package way before Expat itself and they seem fine. I discussed with senior Linux distro developers how hiding those symbols should affect Expat's .so versioning, if it should be an incompatible bump or not. There was no demand for doing an incompatible bump because all related symbols were never exposed by headers. If you don't upgrade to 2.2.7, are you going to backport all bugfixes to 2.2.6 from now on? I maintain a few distro packages myself and I would consider that a big pain point and waste of time. I know of at least to parties how went with modifying a fork in the past and they are not in a good place with their fork regarding effort, bugfix, and security. Please don't add to that list, just please don't :-) Is there anything I can do to make you reconsider? Is there something that I can do upstream in the Expat code base to smooth your path to Expat 2.2.8/2.3.0? Thanks and best Sebastian
Re: Expat 2.2.7 with security fixes has been released / CVE-2018-20843
Hi Jack and Marius, glad to hear that GUIX saying "no" to 2.2.7 in general was a misunderstanding on my side. Thanks for the clarification! Best Sebastian
Google Summer of Code Inquiry
Hello Zachary, just wanted to chime in. Since last week I have some working code to generate AppImages with guix pack. I was planning on tidying this up for submission over the next weeks. There is still work to do regarding documentation, adding options specific to the AppImage format, building the AppImageKit runtime from source and a lot of testing. However, I believe that the remaining effort is around 8-10 hours. I am happy to hand the code over to you to finish up and co-mentor (though this patch would be my first contribution to guix) if you think this is appropriate. I do not wish to discourage from contribtuting to the project, just hoping to avoid duplicated efforts Best Sebastian PS: this is also my first message sent to a mailing list, hope it makes it through ok. Please point out any errors or breackes in netiquette
Re: Google Summer of Code Inquiry
Morning all, thanks for the push ;) Last months life got busy and I could not wrap this up but it is on my TODO list for this month. @Noé: I would love some help in testing. I try to send you a patch soon (i.e. end of next week) (never used git send-mail before). Best Sebastian On 6/12/24 08:44, Ada Stevenson wrote: Hi all, On 10/04/2024 6:33 am, Efraim Flashner wrote: On Tue, Apr 09, 2024 at 05:25:35PM +0200, Ludovic Courtès wrote: Hi Sebastian, Sebastian Dümcke skribis: just wanted to chime in. Since last week I have some working code to generate AppImages with guix pack. I was planning on tidying this up for submission over the next weeks. There is still work to do regarding documentation, adding options specific to the AppImage format, building the AppImageKit runtime from source and a lot of testing. This is great news! Looking forward to incorporating those changes. However, I believe that the remaining effort is around 8-10 hours. I am happy to hand the code over to you to finish up and co-mentor (though this patch would be my first contribution to guix) if you think this is appropriate. It does sound like it jeopardizes this specific project. In a way, that’s a good problem to have as a project, but it does mean that Zachary would need to look for another project (which could still be related to ‘guix pack’). Thoughts? There's always the option of trying to create flatpaks using Guix. I'd love this feature! It would probably more useful than making AppImages too. Warmly, Ada
Re: chez scheme can't load system shared library
Dear André, yours and Pan message suggest you are using guix on a foreign distro. That would also mean, that the libraries you find in /usr/lib are the ones from the foreign system. As such, these libraries will have been compiled+linked with different tools/versions than the ones in guix. I believe this makes them incompatible and leads to the dreaded "Segmentation fault" error. I know no solution to mix+match libraries from guix with those of your distro. It seems really all or nothing. Hope this clears things up, Sebastian On 3/26/25 10:51, guix-devel-requ...@gnu.org wrote: Date: Wed, 26 Mar 2025 10:23:19 +0200 From: André A. Gomes To: Pan Xie Cc: Felix Lechner,help-g...@gnu.org, guix-devel@gnu.org Subject: Re: chez scheme can't load system shared library Message-ID:<871pukurns@gmail.com> Content-Type: text/plain; charset=utf-8 Pan Xie writes: Thanks for your response. Unfortunately, it does not work: `LD_LIBRARY_PATH' is empty in my shell: $ echo $LD_LIBRARY_PATH scheme can't start up with LD_LIBRARY_PATH set: $ LD_LIBRARY_PATH=/usr/lib:$LD_LIBRARY_PATH scheme Segmentation fault (core dumped) $ LD_LIBRARY_PATH='/usr/lib' scheme Segmentation fault (core dumped) The question by Pan has been answered but I have questions on this topic: What's the cause of this segmentation fault on Guix? Is there a way to use chez scheme installed via Guix to see the shared library at /usr/lib (instead of installing the package that provides it it via Guix)? Thanks. -- André A. Gomes "You cannot even find the ruins..."
Re: chez scheme can't load system shared library
Not sure how to answer to a particular meesage from the digest emals I am receiving. Hope this finds the right person and thus not upset anyone. Hi Pan, you need to set LD_LIBRARY_PATH to your profile library path (and then load without absolute path in chez). The following works for me: > guix shell -CP coreutils-minimal chez-scheme openssl > ls ~/.guix-profile/lib csv10.1.0 engines-3 libcrypto.so libcrypto.so.3 libssl.so libssl.so.3 ossl-modules pkgconfig > LD_LIBRARY_PATH=~/.guix-profile/lib scheme (load-shared-object "libssl.so") Best Sebastian
