bug#54690: Cookbook: packagin example is missing use of input or output
Hi,
the extended Packaging example in the Cookbook
https://guix.gnu.org/cookbook/en/html_node/Extended-example.html is
missing examples how to use the inputs and outputs in phases (new style).
Also the example seems to not use g-exps, as it still uses the backquote:
(arguments
`(#:tests? #true ; Run the test suite (this is
the default)
#:configure-flags '("-DUSE_SHA1DC=ON") ; SHA-1 collision detection
#:phases
(modify-phases %standard-phases
(add-after 'unpack 'fix-hardcoded-paths
Also the „Inputs“ and „Outputs“ sections do not show an example. This
could be copied from above. Maybe it is even better to show how to use
inputs and outputs in phases here - and not have it in the example above
- as I did go directly to the „Inputs“ section.
--
Regards
Hartmut Goebel
| Hartmut Goebel | h.goe...@crazy-compilers.com |
| www.crazy-compilers.com | compilers which you thought are impossible |
bug#54820: build-systems: inconsistent use of standard-packages
Build-systems are adding „@(standard-packages)“ inconsistently to
„host-packages“ or „build-packages”. For one developing a new
build-system it is not clear which is the correct form.
Some (e.g. texlive, ruby, python) add it to „host-inputs“)
(host-inputs `(,@(if source
`(("source" ,source))
'())
,@inputs
;; Keep the standard inputs of 'gnu-build-system'.
,@(standard-packages)))
Some add it to „build-inputs (e.g. gnu, cmake, qt):
(build-inputs `(,@(if source
`(("source" ,source))
'())
,@`(("cmake" ,cmake))
,@native-inputs
,@(if target
;; Use the standard cross inputs of
;; 'gnu-build-system'.
(standard-cross-packages target 'host)
'())
;; Keep the standard inputs of 'gnu-build-system'.
,@(standard-packages)))
Expected:
Either
a) review and align the code of all build-systems, or
b) add a comment to every build-system briefly explaining why in host
resp. build-packages here,
c) document how and why to use which form.
Since as far as I've seen there is no detailed „How to write a
build-system“, developers (well, me :-) tend to develop new
build-systems based on existing ones. Thus (a) or (b) seem the easier
and quicker solution.
Reproduce:
grep -A5 -B5 standard-packages guix/build-system/*.scm
--
Regards
Hartmut Goebel
| Hartmut Goebel | h.goe...@crazy-compilers.com |
| www.crazy-compilers.com | compilers which you thought are impossible |
bug#55043: Some packages depend on nss-certs, some bundle it.
Am 20.04.22 um 17:22 schrieb Maxime Devos: (from Hartmut Goebel, at<https://issues.guix.gnu.org/54796#52>) Neither python-certifi nor gocertifi build on nss-cert. Addind some update mechanism into the Guix package is not a good idea IMO: This would make “erlang-certif@2.9.0“ contain different certificates than the release 2.9.0, making debugging a hell. ... but I don't follow, it's just a different set of certificates, could you elaborate? This argument is just about keeping the actual content of a package aligned with the content of the official release. This is a is less impotent argument then what I wrote in <https://issues.guix.gnu.org/54796#52>: All these contain a copy of the/a CA bundle — which is the idea of these packages: „useful for systems that do not have CA bundles“. Anyhow: Your proposal is to make upstream packages get rid of these bundles. Will this being quite some work. An alternative approach could be to patch these packages, much like Liliana suggested („mock“). -- Regards Hartmut Goebel | Hartmut Goebel |h.goe...@crazy-compilers.com| |www.crazy-compilers.com | compilers which you thought are impossible |
bug#56733: Tryton LTS
Follow-up to https://issues.guix.gnu.org/56706 „gnu: Tryton application and framework: Update to 6.2.x.“. Am 23.07.22 um 18:11 schrieb Vinicius Monego: I'd suggest keeping Tryton at 6.0 to retain compatibility with GNU Health, which tracks only the LTS versions of Tryton (minor versions at 0). To clarify a little further, GNU Health [1] (to keep it short, it is a set of health-related tryton modules) is not yet packaged in Guix. I did attempt to package it but got stuck in test errors in the check phase. In general Guix is a rolling release distribution. Thus IMHO tryton should be updated. Anyhow I understand that we need a LTS variant for GNU Health and other conservative users. We could create a „tryton-lts.scm“ which holds the LTS versions, inherited from the current release. Creating such a file is expected be to not much of a problem. WDYT? The Tryton release process is explained in [2]. Normal releases have one year of support, while LTS releases have 5 years. Tryton has a huge package ecosystem and is mostly used in enterprise where LTS is more important. Tracking non-LTS releases would mean huge and breaking upgrades at least every year. Also 6.2 will be EOL in 3 months [2]. [1]https://www.gnuhealth.org/ [2]https://discuss.tryton.org/t/release-process/395 -- Regards Hartmut Goebel | Hartmut Goebel |h.goe...@crazy-compilers.com| |www.crazy-compilers.com | compilers which you thought are impossible |
bug#56733: Tryton LTS
For the records: Tryton 6.0 was available up to at least 2022-08-09 (commit 02de6a59813df9dd839117669535118f1b798ed4). So versions and hashes can be picked from there. Or even the tryton-scm at that version could be used as a base for tryton-lts.scm. Please also note: The packages can be kept up-to-date easily using my tooling at https://codeberg.org/htgoebel/tryton-guix-helpers (and the upcoming “refresh to version“ feature). -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
bug#58146: podman issues
Hi, thanks for packaging podman. Unfortunately I discovered some issues: * no default configuration provided. This makes it hard to use podman :-) * rootlessport is not found: Error: could not find "rootlessport" in one of [/gnu/store/r6yjlvicgz1r9nb1q6zwd79gq 94l34wa-podman-4.2.1/bin /usr/local/lib/podman /usr/libexec/podman /usr/lib/podman]. To resolve this error, set the helper_binaries_dir key in the `[engine]` section o f containers.conf to the directory containing your helper binaries. -- Regards Hartmut Goebel | Hartmut Goebel |h.goe...@crazy-compilers.com| |www.crazy-compilers.com | compilers which you thought are impossible |
bug#58146: podman issues
Another one: * catatonit i not found — this one is used when building pods Error: building local pause image: finding pause binary: exec: "catatonit": executable file not found in $PATH -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
bug#58146: podman issues
For rootlessport: Quick work-around: export CONTAINERS_HELPER_BINARY_DIR=$(realpath $(dirname $(which podman))/../libexec/podman) Proper solution: Add an entry to the config file: // HelperBinariesDir is a list of directories which are used to search for // helper binaries. HelperBinariesDir []string `toml:"helper_binaries_dir"` For catatonit: Patch path in pkg/rootless/rootless_linux.c -- Regards Hartmut Goebel | Hartmut Goebel |h.goe...@crazy-compilers.com| |www.crazy-compilers.com | compilers which you thought are impossible |
bug#58146: Acknowledgement (podman issues)
These are now fixed, see https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63928-- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
bug#23304: import pypi: Option o keep the downloaded file
Hi, when importing packages from pypi I often need to look at the source. Either for checking the license, getting a better description, find out how tests are run or which build system to use. For this I'd appreciate an option to keep the downloaded archive (or even better keep the unpacked archive) for easy access. This option could be called `-K, --keep-downloads=DESTDIR`, where DESTDIR is the destination directory where to download (or unpack) the archive. Maybe this option should be available for all `imports` as it may be useful there, too. -- Schönen Gruß Hartmut Goebel Dipl.-Informatiker (univ), CISSP, CSSLP, ISO 27001 Lead Implementer Information Security Management, Security Governance, Secure Software Development Goebel Consult, Landshut http://www.goebel-consult.de Blog: http://www.goebel-consult.de/blog/ehrlichkeit-made-in-germany Kolumne: http://www.cissp-gefluester.de/2012-02-bring-your-own-life-glosse
bug#20765: Compressed eggs (Python)
Hi,
I support the proposal for switching to pip.
Switching to pip should be save, since this is the proposed standard way
for installing - and thus it should be save in the long run, too.
I suggest calling pip with this options (valid as of pip 8.1.1)
--no-depsDon't install package dependencies.
--no-binary :all:Do not use binary packages.
--no-indexIgnore package index
--disable-pip-version-check
Since in the internet one can find issues with
--single-version-externally-managed I verified that pip will even work
for packages using distutils instead of setuptools. I did a test and
inspecting the software.
Here is what I did: I used a simply Python package which imports
distutils instead of setuptools. Installing the via pip in verbose-mode
shows this line (you do not need to look at the details):
Running command /tmp/myvenv/bin/python2.7 -u -c "import setuptools,
tokenize;__file__='/tmp/pip-Biwi3y-build/setup.py';exec(compile(getattr(tokenize,
'open', open)(__file__).read().replace('\r\n', '\n'), __file__,
'exec'))" install --record /tmp/pip-KcE_9O-record/install-record.txt
--single-version-externally-managed --compile --install-headers
/tmp/myvenv/include/site/python2.7/sample
This basically runs the setup.py “wrapped” into setuptools [1]. The
source code of setuptools reviled that it is monkey-pathing distutils
(esp. distutils.dist.Distribution) to objects from setuptools. So the
more elaborate stuff of setuptools is used even if the setup.py only
import distutils.
Additionally I checked what --single-version-externally-managed does
(since the documentation [2] is not that clear): it simply makes
`install` use the "original" distutils install command, which was/is not
able to create zipped eggs. So here we are on the save side, too.
Tested with pip 8.1.1 and setuptools 20.3, but this same code is in pip
6.0 and setuptools 18.0 already (which are older than what is in guix
0.10.0)
[1] Technically this line is executing a command which import setuptools
and then executes setup.py the it the same scope/context.
[2]
https://pythonhosted.org/setuptools/setuptools.html#install-run-easy-install-or-old-style-installation.
--
Regards
Hartmut Goebel
| Hartmut Goebel | h.goe...@crazy-compilers.com |
| www.crazy-compilers.com | compilers which you thought are impossible |
bug#23304: import pypi: Option o keep the downloaded file
Am 18.04.2016 um 14:15 schrieb Ben Woodcroft: > Are you suggesting something apart from what 'build --source' does e.g. Some kind of :-) 1) From a usability point of view, this should be part of "guix import" since this is what the user does and where she is looking for help. 2) "guix build --source" returns a derivation, whereas "guix import" ought to return the original, unchanged source. (One could argue that on "import", the derivation is the unchanged source depending on nothing) 3) Of course one could use the output of "guix import", pass it to "guix build --source" and get the original source. But a) this would download the source twice b) would intermix phases: the package definition is in early draft, but "build" should return the source. This does not match. 4) In any case, "guix import" should display the name of the downloaded archive. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
bug#24886: Why is die "doc" output downloaded when building this package?
Am 05.11.2016 um 22:53 schrieb Ludovic Courtès: > Most likely this is due to a limitation of the current implementation of > grafts: all the outputs of packages on a “grafting path” need to be > downloaded, even if some of these outputs are unused. IC. Thanks for the explanation. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
bug#15890: Please provide a way to delete old build directories.
Hi, any news on this? Did anybody pass this to the Nix project? Arrange for the ownership of such directories to be changed to the calling user, after the build has finished Would also allow for easily debugging build (by entering the environment and restart the build). -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
bug#25093: Configure file for system-wide substitutes
Hi, when publishing packages in the local network, one wants to use this substitute without passing --substitute-urls on every relevant run on guix. I suggest implementing a config-file for storing the substitute-urls, much like the sources.list on Debian systems. In the long run we'll need this for enterprise setup anyway :-) Enterprises tend to fetch software from their internal repositories only . -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
bug#25094: Add comments to archive keys and acls
Hi, the keys for authenticating an archive currently do not hold any comment. This makes it hard to track acls and remove certain keys if required. Please implement some way to add and change the comment on keys in /etc/guix/ and in /etc/guix/acl. Proposed usage when generating the key: guix archive --generate-key=… --comment "store.example.com" Proposed usage when importing the key and overwriting any existing comment guix archive --authorize --comment "store.example.com" For now, since we have no commands for key management, these would be enough IMO. Existing commenty an easily be changed in the file, so for now we do not need a tool for this. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
bug#25177: Test failures don't cause some Python packages to fail [was Re: [PATCH 05/11] gnu: Add python-pygit2.]
First of all thanks for spotting this bug. >> The bad news is that we have some breakages. >> >> 'python-py' fails with: >> >> TypeError: py.test.__dict__ is not a dictionary >> >> Which seems similar to >> >> https://github.com/NixOS/nixpkgs/issues/12565#issuecomment-174165144 The relevant comment is https://github.com/NixOS/nixpkgs/issues/12565#issuecomment-174196194: Starting with version 18.4, setuptools will always try to execute a test-suite (see https://setuptools.readthedocs.io/en/latest/history.html#id186), which will fail if there is none. So the solution is to disable the test-suite for python-py, as there is no test-suite which can be run via "setup.py test". For testing I added "python-setuptools" (18.3.1) as native input. This made the "check" phase run "0 tests" for python2-py and no tests at al for python-py. (This package includes a test-suite (see tox.ini), but this test-suite requires py.test, with itself requires python-py. So I suggest to disable it.) Our Python (3.5.2) comes with setuptools 20.10.1. > Yikes, I had hoped to avoid addressing that Nix issue and the humongous > "fix" for a while longer: > > https://github.com/NixOS/nixpkgs/pull/12552 This puill-request is huge, but for setuptools, it comes down that they updated from 18.2 to 19.4. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
bug#25177: Test failures don't cause some Python packages to fail
Am 15.12.2016 um 10:26 schrieb Marius Bakke: > @Hartmut, what was your command for building everything python? :-) I have a script for this :-) But maybe there is a more inteligent way like: guix refresh -l python | sed 's/.*: //' | xargs guix build --keep-going -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
bug#25020: guix refresh does not discover updates if URLs are "non-standard"
Am 23.01.2017 um 23:14 schrieb Ludovic Courtès: > > Fixed for oxygen-icons in commit > > 683c5ab70accb909697717bb61741a7692c52c09. For oxygen-icons (those with a number behind the name), refresh works. For "kross" (additional directory level), it does not. Kross is still in my work-pipeline, so here is the WIP (stripped down): (define-public kross (package (name "kross") (version "5.28.0") (source (origin (method url-fetch) (uri (string-append "mirror://kde/stable/frameworks/" (version-major+minor version) "/portingAids/" name "-" version ".tar.xz")) (sha256 (base32 "06qx87v090d5wxbpqj2sgwhpha7gqmamdx4zffdvc0xa6g1mm6x4" (build-system cmake-build-system) (home-page "") (synopsis "") (description "") (license license:lgpl2.0))) -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
bug#26175: guix download fails if filename contains "@"
guix download fails if filename contains "@":invalid character `@' in name $ guix download mirror://kde/stable/applications/16.12.3/src/kde-l10n/kde-l10n...@valencia-16.12.3.tar.xz [...] Starting download of /tmp/guix-file.oVF3qZ From http://mirror.karneval.cz/pub/kde/stable/applications/16.12.3/src/kde-l10n/kde-l10n...@valencia-16.12.3.tar.xz... ...cia-16.12.3.tar.xz 2.0MiB1.4MiB/s 00:01 [] 100.0% guix download: error: build failed: invalid character `@' in name `kde-l10n...@valencia-16.12.3.tar.xz' Guix version: /gnu/store/v83285dvjy923ikq1dddncixb6kfba0k-guix-0.12.0-5.1162/bin/guix -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
bug#26175: guix download fails if filename contains "@"
Am 20.03.2017 um 23:22 schrieb Ludovic Courtès: > To address this we’d need an extra command-line option in ‘guix > download’ to specify the name to use in the store (similar to the > ‘file-name’ field in .) > > So one would type: > > guix download --name=foo.tar.xz > mirror://…/kde-l10n...@valencia-16.12.3.tar.xz IMHO this i not a good solution, since it puts the burden of handling a non-obvious restriction to the user. This makes things complicated and less-skilled discourages people. "guix download" should implement some escape automatic mechanisms. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
bug#27820: guix package -u: order of argument is significant
Hello, I'm try upgrading from guix-0.12.0-10.ba2260d but the profile is not updated. I used "guix pull" to get the latest version. "guix package -u" is loading substitutes, fails with this and recommends using --fallback. "guix package -u --fallback" when run the first time did compile some packages, but did not update the profile. "guix package -u --fallback" when run another time does *nothing*. "guix package -l" still show the old generation. So I updated only guix "guix package -u guix", which gave me guix-0.13.0-4.f1ddfe4. "guix package -u --fallback" when run another time again did nothing. BUT: "guix package --fallback -u" did upgrade the packages. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible | 0xBF773B65.asc Description: application/pgp-keys
bug#27820: guix package -u: order of argument is significant
Am 25.07.2017 um 21:40 schrieb Mark H Weaver:
> That's because "--fallback" was treated as the argument to -u, i.e. the
> regexp specifying which packages to upgrade. The few compiled packages
> were needed to run the profile hooks.
I'm astound about this. Python's argparse library is handling this as
the user expects:
import argparse
parser = argparse.ArgumentParser()
parser.add_argument('-u', '--update', nargs='?', const=42)
parser.add_argument('--fallback', action="store_true")
print(parser.parse_args(['-u', '--fallback']))
print(parser.parse_args(['-u', 'xxx', '--fallback']))
prints
Namespace(fallback=True, update=None)
Namespace(fallback=True, update='xxx')
See https://docs.python.org/3/library/argparse.html#nargs
Isn't there a elaborated scheme/guile argparse library we can you? This
would/shouls/could also solve the issue that in guix we can not shortcut
options.
--
Regards
Hartmut Goebel
| Hartmut Goebel | h.goe...@crazy-compilers.com |
| www.crazy-compilers.com | compilers which you thought are impossible |
bug#28159: Updater needs to support HTTP(S) servers
Hi, our updater currently only supports FTP servers, but more and more projects shutdown the FTP service and provide HTTP(S) servers only (e.g the Linux kernel). For other projects, the main distribution point has changed to HTTP and the mirrors still providing FTP at lagging (e.g. KDE, see [1]). A common case is to simply use Apache to serve the directories, but it will deliver a HTML view on the directory contents (using mod_autoindex [3]). In [2] Ludo wrote: So we need a way to list the latest releases somehow. If they publish JSON, XML, or some other structured info format, that’s fine too. But HTTP alone is not good: we’d have to infer the information from HTML pages, which sounds fragile. IMHO we can not expect project and mirror sites to provide these additional data. Most projects simply will not do since this would require the server to generate some data-files n the fly. OTOH, I assume the delivered directory index pages to be well-formed (X)HTML. Thus parsing the HTML should be quite simple: We only need to pattern-match "" tags, or – if guile has some decent one – a xml/html-parser use this to query the data. Only relative links without slash (except a trailing one) have to be handled. Links with a trailing slash can be assumed to be a directories. (Since auto-index only works if URL is pointing to a directory and the directory is marked by a training slash we can assume the generated links for directories will all have the trailing slash.) At least this would be a good start which could be refined if necessary. Please note tha I'm not suggesting to write a general-purpose parser, but aiming for auto-index html-pages only. Some things I already found out: * Directory-listings generated by mod_autoindex can be provided as a simple list by passing the query-parameter "F=0" in the URL [4]. There are other query parameters for sorting and pattern matching. * nginx's "ngx_http_autoindex_module" [6] seem to not use query parameters, but can be configured (on the server-side) to provide the content as XML or json. The "fancy_index" module [7] si documented to "Allow choosing to sort elements", but [7] does not state how and if "fancy" can be switched off. * Lighttp supports some of these options [5]. [1] http://lists.gnu.org/archive/html/guix-devel/2017-05/msg00237.html [2] http://lists.gnu.org/archive/html/guix-devel/2017-05/msg00292.html [3] https://httpd.apache.org/docs/2.4/mod/mod_autoindex.html [4] https://httpd.apache.org/docs/2.4/mod/mod_autoindex.html#query [5] https://redmine.lighttpd.net/projects/1/wiki/Docs_ModDirlisting#Table-sorting [6] http://nginx.org/en/docs/http/ngx_http_autoindex_module.html [7] https://www.nginx.com/resources/wiki/modules/fancy_index/ -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible | 0xBF773B65.asc Description: application/pgp-keys
bug#28159: Updater needs to support HTTP(S) servers
Am 22.08.2017 um 10:57 schrieb Ludovic Courtès: > So I would suggest picking one updater, say kde, and implementing it > using whatever metadata can be retrieved from kde.org. I'm not sure if I understood what you mean with "whatever metadata can be retrieved from kde.org". By change, download.kde.org indeed provides a "ls-lR" and "ls-lR.bz" file at the top-level. I was not aware of this up to just now. Using this might be an option (It is lagging a bit, though I think this is acceptable. From what I've ssen I guess it is generated each hour if some file changed.) So for kde we might find a simpler solution. But in the long-run IMHO we need a simple html parser. I'm not skilled enough in scheme/guile to write such a parser, sorry. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
bug#28159: Updater needs to support HTTP(S) servers
Hi, > I just learned that ftp://ftp.gnu.org will be retired on Nov. 1st, 2017, > so we’ll have to implement a replacement for the ‘gnu’ updater at least. By change, also this server provides a `ls-lrRt.txt.gz` file. Unfurtunaly is as a slightly different (date-) format than the one at kde.org: kde: drwxr-xr-x 3 ftpadmin packager 6 2000-10-01 14:07 adm gnu: drwxr-xr-x 2 root root 4096 Aug 2 2003 third-party Also by chance ftp.gnu.org also provides a file `find.txt.gz`, listing all files, including the full path: ./video/Stephen_Fry-Happy_Birthday_GNU-nq_600px_425kbit.ogv ./old-gnu/g77/g77-0.5.21.tar.gz ./old-gnu/guile ./old-gnu/guile/guile-www-1.0.1.tar.gz ./old-gnu/guile/guile-1.3.2.tar.gz > At worst, we’ll parse HTML index files like the one at > <https://ftp.gnu.org/gnu/guile/>, This is what Ihis bug is about :-) Please mind the query-parameters one can pass to apache: <https://ftp.gnu.org/gnu/guile/?F=0> is much more terse. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
bug#29071: guix refresh --type=kde does not update all kde packages
The KDE updater does not update all kde-framework packages: - Those residing in mirror://kde/stable/frameworks/$VERSION/ are updated, - Those residing in mirror://kde/stable/frameworks/$VERSION/portingAids/ (mind the additional directory after the version) are *not* updated. How to reproduce git checkout 91496dfc9a4c3a708b5c2604fad3e42e101fea04 # master @ 2017-1019, kde-frameworks 5.37 ./pre-inst-env guix package -A 'attica|kross' # both packages have v 5.37 ./pre-inst-env guix refresh --update --type=kde ./pre-inst-env guix package -A 'attica|kross' # attica is 5.39, while kross is still 5.37 kross is in the portingAids subdirectory, as you can see at <ftp://mirrors.mit.edu/kde/stable/frameworks/5.39/portingAids/> -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible | 0xBF773B65.asc Description: application/pgp-keys
bug#29086: Fwd: Serious regression in Qt 5.9.2 regarding kirigami
Weitergeleitete Nachricht Betreff:Serious regression in Qt 5.9.2 Datum: Thu, 26 Oct 2017 16:28:52 +0200 Von:Marco Martin An: distributi...@kde.org Kopie (CC): kde-distro-packag...@kde.org Hi all, The recent Qt 5.9.2 release, introduces a pretty serious bug which prevents some kirigami applications to start at all. It is described there: https://bugreports.qt.io/browse/QTBUG-64017 reverting the commit 98358715930739ca8de172d88c5ce6941c275ff3 in qtdeclarative seems to fix the problem, so for distributions i recomend to either patch it out or wait on 5.9.2 packaging for now -- Marco Martin
bug#29088: Superseded package is not rebuild if native dependency changes
Hi, the package "gpgmepp" depends on native input "extra-cmake-modules". However if the alter is changed, gpgmepp is not rebuild. How to reproduce git checkout master # important: without http://debbugs.gnu.org/cgi/bugreport.cgi?bug=29087 applied ./pre-inst-env guix build gpgmepp now apply http://debbugs.gnu.org/cgi/bugreport.cgi?bug=29087 ./pre-inst-env guix build extra-cmake-modules # the package changed by patch 29087 ./pre-inst-env guix build gpgmepp guix build: package 'gpgmepp' has been superseded by 'gpgme' /gnu/store/ky8p7lllm9h9sv1zy0f742r1cc6qbd1l-gpgme-1.9.0 This does *not* rebuild gpgmepp, but simply return the old store-path. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
bug#29088: Superseded package is not rebuild if native dependency changes
Am 31.10.2017 um 23:27 schrieb Ludovic Courtès: > Superseded packages cannot be built/installed unwillingly. In the > example above, what you built is “gpgme”, not “gpgmepp”, which is why > any changes to “gpgmepp” had no effect. IC. Indeed I missed that a different package was build. So I agree, this is not a bug. But i suggest to emit a more verbose message in this case, e.g.: guix build: package 'gpgmepp' will not be build, since it <<--- new has been superseded by 'gpgme'. 'gpgme' will be build instead.<<--- new Or (maybe easier to implement: guix build: package 'gpgmepp' has been superseded by 'gpgme'. Thus 'gpgme' will be build instead of 'gpgmepp'.<<--- new -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
bug#29824: Meson 0.44.0 is broken with guix.
We need to have a look at the whole `detect_meson_py_location()`, not only on lines 47 to 51. detect_meson_py_location() assumes the executable to be called "meson" or "meson.py", but in guix it currently is called ".meson-real" (see teh first entry in the trace-back). The solution would be to get rid of the wrapper-scripts, see <https://lists.gnu.org/archive/html/guix-devel/2017-11/msg00041.html> A work-around would be to substitute in file mesonbuild/mesonlib.py meson_command = python_command + [detect_meson_py_location()] by meson_command = python_command + ["$OUT/bin/meson"] (you got the idea, I assume). Of course we should verify detect_meson_py_location() is not used elsewhere and consider renaming that function to "disable" it. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
bug#29824: Meson 0.44.0 is broken with guix.
Am 09.01.2018 um 13:46 schrieb Ludovic Courtès: > Sounds reasonable. Does it work for you? If so, could you provide a > patch? I don't have any cards in this game and not time for working on it ATM, I just did the analysis. @peter: What about you? -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
bug#30345: guix refreh --type=kde does not update all KF5 packages
Hi, I'm again experiencing issues with "guix refresh" and KDE packages: ./pre-inst-env guix refresh --update --type=kde does not update * kirigami: the archive is named "kirigami2-*" For this, I thought there is some way to tweak guix, but I did not find it in the manual. * kdelibs4suport and all other "porting Aids" living in the sub-directory "/portingAids" This is like bugs [25020] and [29071]. 25020 says, 026f6a42b680207a59beadf0b0b9cc1753f55605 should solve part of the issue, but if you look at the second line for the "guix refresh" output in [#31], you can see that it does not handle the sub-directory [25020] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25020 [29071] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29071 [#31] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25020#31 -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
bug#30345: Other KDE updates are not working, too
I jsut discovered that - kpmcore https://download.kde.org/stable/kpmcore/3.3.0/src/kpmcore-3.3.0.tar.xz - libkomparediff2 (even after switching the URL to mirror://kde/ are not updated, too. Running ./pre-inst-env guix refresh -u kpmcore -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
bug#30710: guix graph gives duplicate nodes
Hi, "guix graph" delivers the same package with different IDs. Here is an example with a node delivered twice. (For plasma-workspace, which I'm working on, this package was even listed four times). $ ./pre-inst-env guix graph -t package -b graphviz qtbase | grep autoconf-wrapper "59511552" [label = "autoconf-wrapper-2.69", shape = box, fontname = Helvetica]; "59511744" [label = "autoconf-wrapper-2.69", shape = box, fontname = Helvetica]; -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
bug#30710: guix graph gives duplicate nodes
Hi, > This is expected. Strictly speaking, we’re talking about two different > package objects, hence the different IDs. I wonder a) whether it is useful to have different graph nodes for the same package. This is about usability of the resulting graph, esp. since this is the default graph output format. Does it help *users* for their analysis? Or is this some *expert* insight? b) how there can be different package objects for the same package To my understanding, e.g. (gnu packages base) is loaded once, defining package object abcd once and assigning it to a variable. All packages referring to abcd use the some package object. So there should be only *one* package object. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
bug#30710: guix graph gives duplicate nodes
On Fri, 09 Mar 2018 23:59:26 +0100 l...@gnu.org (Ludovic Courtès) wrote: > >> Good catch! I implemented what you suggest above in commit >> 464f5447396fcec9b43f7eab71d5d42b522a157f. Thanks, this solved the issue only partially: On my "kde-plasma" branch: $ ./pre-inst-env guix graph plasma-workspace | grep autoconf "133094208" [label = "autoconf-wrapper-2.69", shape = box, fontname = Helvetica]; "133094976" [label = "autoconf-2.69", shape = box, fontname = Helvetica]; "152772352" [label = "autoconf-wrapper-2.69", shape = box, fontname = Helvetica]; "152420544" [label = "autoconf-2.69", shape = box, fontname = Helvetica]; There are other packages, which are duplicate but don't have a factory AFAIK: $ ./pre-inst-env guix graph plasma-workspace | grep kbus "130257472" [label = "kdbusaddons-5.42.0", shape = box, fontname = Helvetica]; "148171200" [label = "kdbusaddons-5.42.0", shape = box, fontname = Helvetica]; -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
bug#31611: Add a property in packages to refresh to a specific version
`guix refresh` always fetches the newest version of packages. This might not be desired in all cases. E.g. one might want to keep some still supported "major" upstream-version and not yet update to the next "major" version. Ludo suggested to add a property in packages that would instruct updaters to restrict the version search space to a given regexp. Rational: Example: KDE Plasma 5 has 5.12 as long-term-support (LTS) version, while 5.14 has already being released. Do easy maintenance of dependent packages, sticking to 5.12.x micht be desired. Original discussion: https://lists.gnu.org/archive/html/guix-devel/2018-02/msg00055.html -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
bug#31611: Add a property in packages to refresh to a specific version
Am 29.05.2018 um 01:26 schrieb Marius Bakke: > Can we simply patch the KDE importer to stick with 5.12 for now? Not a good solution IMHO. For now I can also use "guix download"as a work-around This is not comfortable, but avoids having a forgotten "feature" in the code. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
bug#31611: Add a property in packages to refresh to a specific version
Am 19.06.2018 um 16:17 schrieb Marius Bakke: > I'm not convinced that adding a property to some 80 packages is better > than patching the importer. To me this problem seems very > importer-specific (knowing what releases are considered LTS). I disagree this is imported specific. Imagine we would like to provide different still supported versions of e.g. Python (3,.4, 3.5, 3.6, 3.7) or openssl (1.0 and 1.1). > As a middle ground, perhaps we could add a "--select" argument to guix > import, e.g: "--select=REGEXOnly consider versions matching REGEX". This would improve the current situation :-) -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible | signature.asc Description: OpenPGP digital signature
bug#34679: --load-path does not work with guix environment
According to the manual: |--load-path=directory| Add directory *to the front* of the package module search path. This does not work for guix environment (guix 0.16.0-3.6ddc63e): Prepare to reproduce $ git clone https://gnunet.org/git/gnunet.git $ cd gnunet guix package honors --load-path: $ guix package --load-path=$PWD/contrib/guix -A gnunet [...] gnunet v0.11.0pre66-1108-g8bb29d2fb out .../contrib/guix/gnu/packages/gnunet.scm:274:2 [...] guix environment still installs gnunet 0.10.1 (which is defined in guix 0.16): $ guix environment --load-path=$PWD/contrib/guix --ad-hoc gnunet [guix]$ realpath $(which gnunet-arm) /gnu/store/...-gnunet-0.10.1/bin/gnunet-arm Using GUIX_PACKAGE_PATH the correct version of gnunet is installed into the environment: $ export GUIX_PACKAGE_PATH=$PWD/contrib/guix $ guix environment --ad-hoc gnunet [guix]$ realpath $(which gnunet-arm) /gnu/store/...-gnunet-v0.11.0pre66-1108-g8bb29d2fb/bin/gnunet-arm -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
bug#34679: --load-path does not work with guix environment
Am 06.03.19 um 15:05 schrieb Ludovic Courtès: > Could you try to reduce this to a simpler test case and/or post the > files to test it? I will do thus, but in two or three weeks time only. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
bug#40891: import crate: Traceback when package not found
If "import crate" does not find the package, a traceback is shown (see below) I would expect an error message stating that the package was nor found (or whatever crates.io error message is) $ guix import crate non-exeisti[hartmut@lenashee [1] guix (HG-sequoia-as-rust-pkgs)]$ guix import crate non-exeisting-package Backtrace: 4 (primitive-load "/usr/local/bin/guix") In guix/ui.scm: 1936:12 3 (run-guix-command _ . _) In guix/scripts/import.scm: 116:11 2 (guix-import . _) In guix/scripts/import/crate.scm: 104:23 1 (guix-import-crate . _) In guix/import/crate.scm: 205:8 0 (crate->guix-package "non-exeisting-package" _) guix/import/crate.scm:205:8: In procedure crate->guix-package: In procedure struct-vtable: Wrong type argument in position 1 (expecting struct): #f -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
bug#40893: import crate: Recursive importer loops
When running "import crate -r", the same packages get downloaded again and again. Depending on the package to be imported, this looping can take quite some time and the user gets the impression, that the import will recurse endlessly. I would expect the importer to recognize it did already download the package. $ guix pull --commit=ee8de7381 # to be sure the packages are not imported already. $ ./pre-inst-env guix import crate -r h2 ... following redirection to `https://static.crates.io/crates/rustls/rustls-0.17.0.crate'... ... following redirection to `https://static.crates.io/crates/webpki/webpki-0.21.2.crate'... following redirection to `https://static.crates.io/crates/webpki-roots/webpki-roots-0.19.0.crate'... ... following redirection to `https://static.crates.io/crates/webpki/webpki-0.21.2.crate'... following redirection to `https://static.crates.io/crates/webpki-roots/webpki-roots-0.19.0.crate'... ... following redirection to `https://static.crates.io/crates/ring/ring-0.17.0-alpha.1.crate'... following redirection to `https://static.crates.io/crates/ring/ring-0.17.0-alpha.1.crate'... ... following redirection to `https://static.crates.io/crates/webpki/webpki-0.21.2.crate'... ... following redirection to `https://static.crates.io/crates/rustls/rustls-0.17.0.crate'... following redirection to `https://static.crates.io/crates/webpki/webpki-0.21.2.crate'... following redirection to `https://static.crates.io/crates/webpki-roots/webpki-roots-0.19.0.crate'... -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
bug#40894: import crate: Use proper variable names
"import crate -r" shall create and use "proper" variable names for the
package definitions it prints out and for the packages it reference.
If guix commits to use variable names follow the Cargo book (see
<https://lists.gnu.org/archive/html/guix-devel/2020-04/msg00394.html>),
the importer shall create respective variables and use these names. This
would easy importing packages a lot.
Dummy example:
$guix import crate -r h2@0.2.4
…
(define-public rust-h2
…
(arguments
`(#:cargo-inputs
(("rust-bytes" ,rust-bytes)
("rust-fnv" ,rust-fnv)
Shall become
$guix import crate -r h2@0.2.4
…
(define-public rust-h2-0.2
…
(("rust-bytes" ,rust-bytes-0.4)
("rust-fnv" ,rust-fnv-1)
--
Regards
Hartmut Goebel
| Hartmut Goebel | h.goe...@crazy-compilers.com |
| www.crazy-compilers.com | compilers which you thought are impossible |
bug#40895: import crate: Relaxed version selection
If (manually) importing dependencies for some package requiring "other
^0.2", I would like the importer to fetch the newest version of
other-0.2.x automatically.
As it is now, I need to specify the exact version number, e.g. "guix
import crate other@0.2.4" - and the get the version number I need to go
to crates.io, search the package and search the list of available
versions. The importer can do this much more efficient.
This could be implemented like this:
- If the version giben ("@0.2.4") matches an version available, use this
version.
- Otherwise, if the version giben ("@0.2") is a prefix of some available
version, use the highest/newest of these versions
--
Regards
Hartmut Goebel
| Hartmut Goebel | h.goe...@crazy-compilers.com |
| www.crazy-compilers.com | compilers which you thought are impossible |
bug#40893: import crate: Recursive importer loops
This is all about the on currently in Guix master. I've not been aware of the other one. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
bug#40977: --load-path does not honor ~
Specifying the home directory using `~` (tilde) in `--load-path` does not add the proper path to Does not work (not who "mypackage": guix package --load-path=~/path/tp/my/project -A mypackage Using $HOME (which si resolve by the shell works: guix package --load-path=$HOME/path/tp/my/project -A mypackage I would expect ~ and ~username to work, too.
bug#40977: --load-path does not honor ~
Hi, This is not related to #40549. The short option "-L ~/…" works, since thin this case the shell resolves the tilde. Whereas for the long-option the shell does not revolve the tilde, since the tilde is in the middle of the argument. Yu can verify this yourself easily: $ python -c 'import sys; print(sys.argv)' ~ ['-c', '/home/hartmut'] $ python -c 'import sys; print(sys.argv)' -L ~ ['-c', '-L', '/home/hartmut'] $ python -c 'import sys; print(sys.argv)' ---long=~ ['-c', '---long=~'] Proposed solution: After processing options, guix need to "expanduser()" (as it is called in Python) on all arguments which are paths. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
bug#41093: --with-commit only works with git repos
guix build --with-commit only works with git repos I would expect it to work with mercurial repos, too, as basically this is just setting a value in the source definition. (At least this is what I would assume it does.)
bug#34679: --load-path does not work with guix environment
Am 14.05.20 um 07:24 schrieb Ricardo Wurmus: > have you been able to reproduce this with a simpler test case? Or would > you agree to close this issue as unreproducible? I could not reporduce this either when using a current version fo guix. Closing. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
bug#42289: recursive import does not dort alphabetically
In most gnu/packages/*.scm files are (expected to be) sorted alphabetically. Now when importing some packages recursivly, packages are output in order of the dependency graph, thus authors need to sort them manually. Example (requires the hex.pm importer from <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=42180>: $ ./pre-inst-env guix import hexpm -r idna | grep define-public (define-public erlang-unicode-util-compat (define-public erlang-idna $ ./pre-inst-env guix import hexpm -r idna | grep define-public | LC_ALL=C sort --check sort: -:2: disorder: (define-public erlang-idna -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
bug#42290: Support other VCS with "guix build --with-commit"
|Serverity: wishlist| guix build --with-commit only works with git repos. It would be nice if this would also work with mercurial, SVN, Monotone, CVS, etc. repos. Implementing this should not be too hard, as basically this is just setting a value in the source definition. (At least this is what I would assume it does.) -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
bug#42291: data service: Show list of files and allow qeuerying
Serverity: wishlist I often find myself checking the content of a package. For this I would like to be able to inspect the list of files in a package, or even query for a specific file. This is much like Debian does in "list of files" for each package (e.g. <https://packages.debian.org/en/buster/amd64/ejabberd-mod-cron/filelist>) and with "Search the contents of packages" <https://www.debian.org/distrib/packages#search_contents> Many thanks :-) -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
bug#42292: committer.scm: Add support for new package definitions
Serverity: wishlistHi Ricardo, many thanks for the "committer script", which makes packager's live much easier. I'd like committer to be able to also detect and commit new package definitions. As of today, committer will take new packages as an update to the package in front. And if there are several consecutive new package definitions, these will be put into one commit. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
bug#42289: recursive import does not dort alphabetically
Am 09.07.20 um 11:36 schrieb zimoun: > Do you mean the package definitions in gnu/packages/foo.scm? Yes. > Because they are generally not alphabetically sorted. Most file I've been working on ask for sorting alphabetically. (And IMHO this is a good recommendation to follow.) -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
bug#42289: recursive import does not dort alphabetically
Am 09.07.20 um 19:39 schrieb Leo Famulari: > What are the benefits of sorting packages? Many modules are sorted and some packages even contain a comment asking for being sorted. So I had the impression this is good practice. Also scanning through the file is easier for humans if packages are sorted - depends on personal work style. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
bug#44906: Substitute requests fail if URL has trailing slash
If the substitute-URL ends with a slash, api requests fail.
Expected behavior:
Substitute-URLs with and without trailing slash should behave the same.
This is especially true for substitute-URLs with empty path
("http://server";) and path "/" (http://server/";) - for which the RFCs
explicitly state to be equivalent.
According to RFC 7230, sec 2.7.3 "http and https URI Normalization and
Comparison" [1]:
[…] an empty
path component is equivalent to an absolute path of "/", so the
normal form is to provide a path of "/" instead.
[1] https://tools.ietf.org/html/rfc7230#section-2.7.3
How to reproduce:
no trailing slash:
$ guix weather --substitute-urls="https://ci.guix.gnu.org"; gcc-toolchain
…
https://ci.guix.gnu.org
100.0% substitutes available (3 out of 3)
…
Trailing slash:
$ guix weather --substitute-urls="https://ci.guix.gnu.org/"; gcc-toolchain
…
https://ci.guix.gnu.org/
0.0% substitutes available (0 out of 3)
…
'https://ci.guix.gnu.org//api/queue?nr=1000' returned 400 ("Bad Request")
--
Regards
Hartmut Goebel
| Hartmut Goebel | h.goe...@crazy-compilers.com |
| www.crazy-compilers.com | compilers which you thought are impossible |
bug#44906: Substitute requests fail if URL has trailing slash
Am 28.11.20 um 00:37 schrieb zimoun: Now, the question is where should the fix go? “guix publish” exposing the narinfos or “guix weather“? Or both? I propose fixing all places where string-append is used to join URLs, since joining URLs is not the same as string concatenation. We might restrict our algorithm to only joining a path. <https://tools.ietf.org/html/rfc3986#section-5.2.2> shows the complete algorithm, where this is the relevant part for only joining a path (R.path) to a base URL's path (T.path). if (R.path starts-with "/") then T.path = remove_dot_segments(R.path); else T.path = merge(Base.path, R.path); T.path = remove_dot_segments(T.path); (Side-node: guile module (web uri) <https://www.gnu.org/software/guile/manual/html_node/URIs.html> seems to lack respective, easy to use functions.) -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
bug#40895: Should be solved by new importer
This issue is solved by the new importer. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
bug#25327: cargo build-system should be able to filter out target.cfg(windows) dependencies
Am 18.12.20 um 20:56 schrieb zimoun: Is it still relevant with the recent additions? I just checked this with sequoia 0.20.0: The package "winapi" is still downloaded and compiled - even if obviously not used sicne on Linux. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
bug#45193: Wrapper of Qt programs doesn't extend existing environment variable
Zhu Zihao wrote When building QT program, Guix builder populates qt related environmentvariable, and wrap-qt-program just record it into wrapper. However, the wrap behaviour in qt-build-system is quite different, itsearch all inputs and mark them should be included in envvar definitionif correspond directory exists. This will have the same result in must cases: The environment variables used in qt-utils are defined as "native-search-paths" by some package. So these variables will be set when creating the build environment, based in the inputs. So if the package does not touch these variables, the output should be the same (beside perhaps the order). When using the environment-variables, this would allow the package definition to remove unwanted parts. Nevertheless this is cumbersome (fetching the input, string-append, manipulating the variable value). And AFAIS none of the pacakges using wrap-qt-program does this. I agree that leaking the environments variables from the build environment to the package is not a good idea. Also we might want to add some filters to avoid all imports (including cmake) are going into the wrapping variables - which is much easier when dealing with inputs nor strings. Another difference is, wrap-qt-program will include the directory ofoutput in envvar but qt-build-system won't do. If I understand the code correctly, line 103 of qt-build-system also handle the output directories (append (list directory) input-directories and the qt-build-system should even handle different outputs (while qt-tuils does not): (for-each handle-output outputs) (I may be wrong on this, please double check. -- Regards Hartmut Goebel | Hartmut Goebel |h.goe...@crazy-compilers.com| |www.crazy-compilers.com | compilers which you thought are impossible |
bug#45193: Wrapper of Qt programs doesn't extend existing environment variable
Am 19.12.20 um 19:20 schrieb Zhu Zihao: BTW, would you like to use prefix wrap for wrap-qt-program in qt-utils.scm? I would support your proposal of unifying both wrappers. (Which way round is a matter of closure-size. I assume moving the code to qt-util.scm is the smaller solution.) -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
bug#37523: Print hint if build fails due to invalid character in package source base name
Hi,, thanks for picking this up. Therefore, I am missing if this message “invalid character” should be improved or if the check of the name should be done before on the Scheme side. Well, I am missing what could be the path to improve the situation, if it needs. Since this check is done also for other store-items, I assume it does not make much sense to change the message in the C-code. So I assume the patch to improve this is to check the name on the Scheme side. (Or to make the da)emon return some meaningful error object. Anyhow I assume this is much more complicated and not a solution for now. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
bug#45436: dino translations are not used
in dino@0.2.0 translations are not used. While the package contains translations for quite some languages, these are not used. When running dino under strace control I could not even spot any access to any "locale" directory Expected: Translated strings are used Reproduce: 1. Install dino@0.2.0 (which is the current version as of this writing) 2. Ensure you have LANG, LC_ALL, LC_MESSAGES and LANUAGE set to an non-Englich locale 3. Start dino under strace control: strace -f -e trace=file -o /tmp/trace.txt dino 4. Open the menu (left "hamburger") 5. All texts are still English 6. Inspect /tmp/trace.txt -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
bug#45615: Wrong type argument in "guix lint -c archival"
When running "guix lint -c archival ugrep" I get this backtrace show below. Expected behavior: No crash, but a useful error message. Reproduce: * Guix 947aed127a48ef41bab3bdbb4252eb2a56dafc10 (2021-01-01 13:55:11) * ugrep (new package) see http://debbugs.gnu.org/cgi/bugreport.cgi?bug=45614 $ ./pre-inst-env guix lint ugrep -c archival … Backtrace:grep@3.1.1 [archival]... In ice-9/boot-9.scm: 1736:10 15 (with-exception-handler _ _ #:unwind? _ # _) In unknown file: 14 (apply-smob/0 #) In ice-9/boot-9.scm: 718:2 13 (call-with-prompt _ _ #) In ice-9/eval.scm: 619:8 12 (_ #(#(#))) In guix/ui.scm: 2127:12 11 (run-guix-command _ . _) In ice-9/boot-9.scm: 1736:10 10 (with-exception-handler _ _ #:unwind? _ # _) 1731:15 9 (with-exception-handler # ?) In srfi/srfi-1.scm: 634:9 8 (for-each # ?) In guix/scripts/lint.scm: 65:4 7 (run-checkers # ?) In srfi/srfi-1.scm: 634:9 6 (for-each # ?) In guix/scripts/lint.scm: 74:21 5 (_ _) In guix/lint.scm: 1225:4 4 (check-archival _) 1092:2 3 (call-with-networking-fail-safe _ _ _) In ice-9/boot-9.scm: 1736:10 2 (with-exception-handler _ _ #:unwind? _ # _) 1669:16 1 (raise-exception _ #:continuable? _) 1667:16 0 (raise-exception _ #:continuable? _) ice-9/boot-9.scm:1667:16: In procedure raise-exception: In procedure string-prefix?: Wrong type argument in position 2 (expecting string): # -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
bug#45436: Status: dino translations are not used
I'm closing this issue, since I can no reproduce this issue.
bug#45193: Wrapper of Qt programs doesn't extend existing environment variable
Patches are almost done. Expect the within thee next few days. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
bug#45193: [PATCH 3/4] build-system: qt: Exclude useless inputs from wrapped variables.
From: Jakub Kądziołka
* guix/build-system/qt.scm (qt-build)[qt-wrap-excluded-inputs]: New argument.
* guix/build/qt-utils.scm (%qt-wrap-excluded-inputs): New variable.
(wrap-qt-program*)[qt-wrap-excluded-inputs]: New argument. Filter excluded
inputs.
(wrap-qt-program)[qt-wrap-excluded-inputs]: New argument.
(wrap-all-qt-programs)[qt-wrap-excluded-inputs]: New argument.
Co-authored-by: Hartmut Goebel
---
guix/build-system/qt.scm | 5 +
guix/build/qt-utils.scm | 29 -
2 files changed, 25 insertions(+), 9 deletions(-)
diff --git a/guix/build-system/qt.scm b/guix/build-system/qt.scm
index 1bd89bfa4d..e1368db1d9 100644
--- a/guix/build-system/qt.scm
+++ b/guix/build-system/qt.scm
@@ -3,6 +3,7 @@
;;; Copyright © 2013 Cyril Roelandt
;;; Copyright © 2017 Ricardo Wurmus
;;; Copyright © 2019 Hartmut Goebel
+;;; Copyright © 2020 Jakub Kądziołka
;;;
;;; This file is part of GNU Guix.
;;;
@@ -22,6 +23,8 @@
(define-module (guix build-system qt)
#:use-module (guix store)
#:use-module (guix utils)
+ #:use-module ((guix build qt-utils)
+#:select (%qt-wrap-excluded-inputs))
#:use-module (guix derivations)
#:use-module (guix search-paths)
#:use-module (guix build-system)
@@ -125,6 +128,7 @@
(phases '(@ (guix build qt-build-system)
%standard-phases))
(qt-wrap-excluded-outputs ''())
+ (qt-wrap-excluded-inputs %qt-wrap-excluded-inputs)
(system (%current-system))
(imported-modules %qt-build-system-modules)
(modules '((guix build qt-build-system)
@@ -148,6 +152,7 @@ provides a 'CMakeLists.txt' file as its build system."
search-paths)
#:phases ,phases
#:qt-wrap-excluded-outputs ,qt-wrap-excluded-outputs
+ #:qt-wrap-excluded-inputs ,qt-wrap-excluded-inputs
#:configure-flags ,configure-flags
#:make-flags ,make-flags
#:out-of-source? ,out-of-source?
diff --git a/guix/build/qt-utils.scm b/guix/build/qt-utils.scm
index 030059522d..a03b09f05e 100644
--- a/guix/build/qt-utils.scm
+++ b/guix/build/qt-utils.scm
@@ -1,6 +1,7 @@
;;; GNU Guix --- Functional package management for GNU
;;; Copyright © 2016 David Craven
;;; Copyright © 2019, 2020, 2021 Hartmut Goebel
+;;; Copyright © 2020 Jakub Kądziołka
;;;
;;; This file is part of GNU Guix.
;;;
@@ -23,8 +24,11 @@
#:use-module (srfi srfi-1)
#:use-module (srfi srfi-26)
#:export (wrap-qt-program
-wrap-all-qt-programs))
+wrap-all-qt-programs
+%qt-wrap-excluded-inputs))
+(define %qt-wrap-excluded-inputs
+ '(list "cmake" "extra-cmake-modules" "qttools"))
(define (variables-for-wrapping base-directories)
@@ -50,13 +54,16 @@
'("QML2_IMPORT_PATH" prefix "/lib/qt5/qml")
-(define* (wrap-qt-program* program #:key inputs output-dir)
+(define* (wrap-qt-program* program #:key inputs output-dir
+ qt-wrap-excluded-inputs)
(define input-directories
-;; FIXME: Filter out unwanted inputs, e.g. cmake
-(match inputs
- (((_ . dir) ...)
-dir)))
+(filter-map
+ (match-lambda
+ ((label . directory)
+ (and (not (member label qt-wrap-excluded-inputs))
+directory)))
+ inputs))
(let ((vars-to-wrap (variables-for-wrapping
(cons output-dir input-directories
@@ -64,18 +71,21 @@
(apply wrap-program program vars-to-wrap
-(define* (wrap-qt-program program-name #:key inputs output)
+(define* (wrap-qt-program program-name #:key inputs output
+ (qt-wrap-excluded-inputs %qt-wrap-excluded-inputs))
"Wrap the specified programm (which must reside in the OUTPUT's \"/bin\"
directory) with suitably set environment variables.
This is like qt-build-systems's phase \"qt-wrap\", but only the named program
is wrapped."
(wrap-qt-program* (string-append output "/bin/" program-name)
-#:output-dir output #:inputs inputs))
+#:output-dir output #:inputs inputs
+#:qt-wrap-excluded-inputs qt-wrap-excluded-inputs))
(define* (wrap-all-qt-programs #:key inputs outputs
(qt-wrap-excluded-outputs '())
+ (qt-wrap-excluded-inputs
%qt-wrap-excluded-inputs)
#:allow-other-keys)
"Implement qt-build-systems's phase \"qt-wrap\": look for executables in
\"bin\", \"sbin\" and \"libexec\" of all outputs and create wrappers with
@@ -99,7 +109,8 @@ add a dependency of that output
bug#45193: [PATCH 2/4] guix: qt-utils: Wrapped executables honor user's envvars.
Prior to this change, wrappers did set the specified environment variables to
a fixed value, overwriting any user settings. This inhibited propagating
e.g. XDG_DATA_DIRS from a profile to the application.
Now user environment variables are prefixed (if the variable defines some
"binary" search path, e.g. QT_PLUGIN_PATH) or suffixed (if the variable
defines some config or data search path, e.g. XDG_DATA_DIRS). The code could
also allow to overwrite, anyhow currently no variable is defined like this.
* guix/build/qt-utils.scm (variables-for-wrapping): For each env-var to
be wrapped, specify whether it should prefix, suffix or overwrite the
user's variable.
---
guix/build/qt-utils.scm | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/guix/build/qt-utils.scm b/guix/build/qt-utils.scm
index 3fbdb6be61..030059522d 100644
--- a/guix/build/qt-utils.scm
+++ b/guix/build/qt-utils.scm
@@ -39,14 +39,15 @@
(lambda (var-to-wrap) (not (null? (last var-to-wrap
(map
(lambda (var-spec)
- `(,(first var-spec) = ,(collect-sub-dirs base-directories (last
var-spec
+ (list (first var-spec) (second var-spec)
+(collect-sub-dirs base-directories (third var-spec
(list
;; these shall match the search-path-specification for Qt and KDE
;; libraries
- '("XDG_DATA_DIRS" "/share")
- '("XDG_CONFIG_DIRS" "/etc/xdg")
- '("QT_PLUGIN_PATH" "/lib/qt5/plugins")
- '("QML2_IMPORT_PATH" "/lib/qt5/qml")
+ '("XDG_DATA_DIRS" suffix "/share")
+ '("XDG_CONFIG_DIRS" suffix "/etc/xdg")
+ '("QT_PLUGIN_PATH" prefix "/lib/qt5/plugins")
+ '("QML2_IMPORT_PATH" prefix "/lib/qt5/qml")
(define* (wrap-qt-program* program #:key inputs output-dir)
--
2.21.3
bug#45193: [PATCH 1/4] guix: qt-build-system, qt-utils: Unify wrapping of qt-programs.
Unify (guix qt-build-system wrap-all-programs) and
(guix qt-utils wrap-qt-program), so both behave the same.
The functions now reside in qt-utils to make them easily available for
packages not using the qt-build-system.
* guix/build/qt-build-system.scm (variables-for-wrapping, wrap-all-programs):
Move from here ...
* guix/build/qt-utils.scm (variables-for-wrapping, wrap-all-qt-programs):
... to here. Base the later on
(wrap-qt-program*): New function, carved out from old wrap-all-programs.
(wrap-qt-program): Base on wrap-qt-program*, change arguments in an
incompatible way.
* gnu/packages/bittorrent.scm (qbittorrent)[arguments]{wrap-qt}:
Adjust to new interface of wrap-qt-program.
* gnu/packages/finance.scm (electron-cash): Likewise.
* gnu/packages/geo.scm (qgis): Likewise.
* gnu/packages/password-utils.scm (qtpass): Likewise.
* gnu/packages/video.scm (openshot): Likewise.
* gnu/packages/web-browsers.scm (kristall): Likewise.
---
gnu/packages/bittorrent.scm | 6 +-
gnu/packages/finance.scm| 8 ++-
gnu/packages/geo.scm| 7 ++-
gnu/packages/password-utils.scm | 6 +-
gnu/packages/video.scm | 6 +-
gnu/packages/web-browsers.scm | 5 +-
guix/build-system/qt.scm| 1 +
guix/build/qt-build-system.scm | 68 +
guix/build/qt-utils.scm | 105 ++--
9 files changed, 113 insertions(+), 99 deletions(-)
diff --git a/gnu/packages/bittorrent.scm b/gnu/packages/bittorrent.scm
index 08e61d7ba2..6967eccec4 100644
--- a/gnu/packages/bittorrent.scm
+++ b/gnu/packages/bittorrent.scm
@@ -10,6 +10,7 @@
;;; Copyright © 2018 Nam Nguyen
;;; Copyright © 2018 Ricardo Wurmus
;;; Copyright © 2019, 2020 Brett Gilio
+;;; Copyright © 2020 Hartmut Goebel
;;;
;;; This file is part of GNU Guix.
;;;
@@ -447,8 +448,9 @@ desktops.")
#:phases
(modify-phases %standard-phases
(add-after 'install 'wrap-qt
- (lambda* (#:key outputs #:allow-other-keys)
- (wrap-qt-program (assoc-ref outputs "out") "qbittorrent")
+ (lambda* (#:key outputs inputs #:allow-other-keys)
+ (let ((out (assoc-ref outputs "out")))
+ (wrap-qt-program "qbittorrent" #:output out #:inputs inputs))
#t)
(native-inputs
`(("pkg-config" ,pkg-config)
diff --git a/gnu/packages/finance.scm b/gnu/packages/finance.scm
index e7d58bbcc0..d71df60740 100644
--- a/gnu/packages/finance.scm
+++ b/gnu/packages/finance.scm
@@ -2,7 +2,7 @@
;;; Copyright © 2015, 2016 Andreas Enge
;;; Copyright © 2016, 2017, 2018 Efraim Flashner
;;; Copyright © 2016 Alex Griffin
-;;; Copyright © 2016 Hartmut Goebel
+;;; Copyright © 2016, 2020 Hartmut Goebel
;;; Copyright © 2017 Carlo Zancanaro
;;; Copyright © 2017 Theodoros Foradis
;;; Copyright © 2017 Vasile Dumitrascu
@@ -611,8 +611,10 @@ other machines/servers. Electrum does not download the
Bitcoin blockchain.")
(assoc-ref inputs "libsecp256k1")
"/lib/libsecp256k1.so.0'")
(add-after 'install 'wrap-qt
- (lambda* (#:key outputs #:allow-other-keys)
- (wrap-qt-program (assoc-ref outputs "out") "electron-cash"))
+ (lambda* (#:key outputs inputs #:allow-other-keys)
+ (let ((out (assoc-ref outputs "out")))
+ (wrap-qt-program "electron-cash" #:output out #:inputs inputs))
+ #t)
(home-page "https://electroncash.org/";)
(synopsis "Bitcoin Cash wallet")
(description
diff --git a/gnu/packages/geo.scm b/gnu/packages/geo.scm
index c682613ff1..a90db90084 100644
--- a/gnu/packages/geo.scm
+++ b/gnu/packages/geo.scm
@@ -10,7 +10,7 @@
;;; Copyright © 2019, 2020 Guillaume Le Vaillant
;;; Copyright © 2019, 2020 Efraim Flashner
;;; Copyright © 2019 Wiktor Żelazny
-;;; Copyright © 2019 Hartmut Goebel
+;;; Copyright © 2019, 2020 Hartmut Goebel
;;; Copyright © 2020 Marius Bakke
;;; Copyright © 2020 Christopher Baines
;;; Copyright © 2020 Felix Gruber
@@ -2121,8 +2121,9 @@ growing set of geoscientific methods.")
(add-after 'install 'wrap-python
(assoc-ref python:%standard-phases 'wrap))
(add-after 'wrap-python 'wrap-qt
- (lambda* (#:key outputs #:allow-other-keys)
- (wrap-qt-program (assoc-ref outputs "out") "qgis")
+ (lambda* (#:key outputs inputs #:allow-other-keys)
+ (let ((out (assoc-ref outputs "out")))
+ (wrap-qt-program "qgis" #:output out #:inputs inputs))
#t))
(add-after 'wrap-qt 'wrap-gis
(lambda* (#:key inputs outputs #:allow-other-keys)
diff --git a/gnu/packages/password-
bug#45193: [PATCH 4/4] guix: qt-utils: Don't include useless inputs in wrapped variables.
From: Jakub Kądziołka
Include only those inputs into XDG_DATA_DIRS having
some subdirectory of /share which is typically used by Qt.
* guix/build/qt-utils.scm (variables-for-wrapping): Take the
output directory as an argument for special handling. Check for
subdirectories of /share used by Qt before including inputs in
XDG_DATA_DIRS.
(wrap-qt-program*): Pass the output directory to variables-for-wrapping.
Co-authored-by: Hartmut Goebel
---
guix/build/qt-utils.scm | 36 +++-
1 file changed, 27 insertions(+), 9 deletions(-)
diff --git a/guix/build/qt-utils.scm b/guix/build/qt-utils.scm
index a03b09f05e..8e6db10ca1 100644
--- a/guix/build/qt-utils.scm
+++ b/guix/build/qt-utils.scm
@@ -30,25 +30,42 @@
(define %qt-wrap-excluded-inputs
'(list "cmake" "extra-cmake-modules" "qttools"))
-(define (variables-for-wrapping base-directories)
+;; NOTE: Apart from standard subdirectories of /share, Qt also provides
+;; facilities for per-application data directories, such as
+;; /share/quassel. Thus, we include the output directory even if it doesn't
+;; contain any of the standard subdirectories.
+(define (variables-for-wrapping base-directories output-directory)
- (define (collect-sub-dirs base-directories subdirectory)
+ (define (collect-sub-dirs base-directories subdirectory-spec)
(filter-map
(lambda (dir)
- (let ((directory (string-append dir subdirectory)))
- (if (directory-exists? directory) directory #f)))
+ (match
+subdirectory-spec
+((subdir)
+ (and (directory-exists? (string-append dir subdir))
+ (string-append dir (car subdirectory-spec
+((subdir children)
+ (and
+ (or
+ (and (string=? dir output-directory)
+(directory-exists? (string-append dir subdir)))
+ (or-map
+(lambda (kid) (directory-exists? (string-append dir subdir kid)))
+children))
+ (string-append dir subdir)
base-directories))
(filter
(lambda (var-to-wrap) (not (null? (last var-to-wrap
(map
-(lambda (var-spec)
- (list (first var-spec) (second var-spec)
-(collect-sub-dirs base-directories (third var-spec
+(match-lambda
+ ((var kind . subdir-spec)
+ `(,var ,kind ,(collect-sub-dirs base-directories subdir-spec
(list
;; these shall match the search-path-specification for Qt and KDE
;; libraries
- '("XDG_DATA_DIRS" suffix "/share")
+ '("XDG_DATA_DIRS" suffix "/share" ("/applications" "/fonts"
+"/icons" "/mime"))
'("XDG_CONFIG_DIRS" suffix "/etc/xdg")
'("QT_PLUGIN_PATH" prefix "/lib/qt5/plugins")
'("QML2_IMPORT_PATH" prefix "/lib/qt5/qml")
@@ -66,7 +83,8 @@
inputs))
(let ((vars-to-wrap (variables-for-wrapping
- (cons output-dir input-directories
+ (cons output-dir input-directories)
+ output-dir)))
(when (not (null? vars-to-wrap))
(apply wrap-program program vars-to-wrap
--
2.21.3
bug#43446: [PATCH] guix: qt-build-system: Wrapped executables honor user's envvars.
This should be fixed by http://issues.guix.gnu.org/45784 and following, esp. http://issues.guix.gnu.org/45785
bug#46191: Add option to make "guix refresh" keep the downloaded files
When running "guix refresh -u some-package" downloads the package to update the hash. But the source is not added to the store, Thus when running "guix build some-package", the source will be downloaded again. I'd like to have an option to make "guix refresh" add teh source to the store, so it is already available for "guix build". -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
bug#44906: [PATCH 0/3] Properly construct URLs if base-url has trailing slash
Here is now an attempt to solve the issue. It had to be fixed in guix/substitutes.scm and guix/ci.scm only. In guix/scripts/publish.scm I did not spot any place where wrong URLs are constructed. Many thanks to Mark for pointing to 'resolve-uri-reference'. Regarding CI: I did some tests, so these should work. Anyhow, I did not find a tests-suite for fully testing this part. Hartmut Goebel (3): substitute: Fix handling of short option "-h". substitutes: Properly construct URLs. ci: Properly construct URLs. guix/ci.scm | 79 + guix/scripts/substitute.scm | 2 +- guix/substitutes.scm| 13 +++--- 3 files changed, 55 insertions(+), 39 deletions(-) -- 2.30.2
bug#44906: [PATCH 1/3] substitute: Fix handling of short option "-h".
The short option was listed in the help-text, but not recognized.
---
guix/scripts/substitute.scm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/guix/scripts/substitute.scm b/guix/scripts/substitute.scm
index 03115ffe44..c044e1d47a 100755
--- a/guix/scripts/substitute.scm
+++ b/guix/scripts/substitute.scm
@@ -777,7 +777,7 @@ default value."
(loop))
((or ("-V") ("--version"))
(show-version-and-exit "guix substitute"))
- (("--help")
+ ((or ("-h") ("--help"))
(show-help))
(opts
(leave (G_ "~a: unrecognized options~%") opts))
--
2.30.2
bug#44906: [PATCH 2/3] substitutes: Properly construct URLs.
Use relative URIs and "resolve-uri-reference" (which implements the algorithm specified in RFC 3986 section 5.2.2) for building the URL, instead of just appending strings. This avoids issued if the cache-url ends with a slash. * guix/substitutes.scm (narinfo-request): Use resolve-uri-reference for constructing the url. --- guix/substitutes.scm | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/guix/substitutes.scm b/guix/substitutes.scm index 4987cda165..a5c554acff 100644 --- a/guix/substitutes.scm +++ b/guix/substitutes.scm @@ -37,7 +37,8 @@ #:use-module ((guix build utils) #:select (mkdir-p dump-port)) #:use-module ((guix build download) #:select ((open-connection-for-uri - . guix:open-connection-for-uri))) + . guix:open-connection-for-uri) + resolve-uri-reference)) #:use-module (guix progress) #:use-module (ice-9 rdelim) #:use-module (ice-9 regex) @@ -155,10 +156,12 @@ indicates that PATH is unavailable at CACHE-URL." (define (narinfo-request cache-url path) "Return an HTTP request for the narinfo of PATH at CACHE-URL." - (let ((url (string-append cache-url "/" (store-path-hash-part path) -".narinfo")) -(headers '((User-Agent . "GNU Guile" -(build-request (string->uri url) #:method 'GET #:headers headers))) + (let* ((base (string->uri cache-url)) + (ref (build-relative-ref + #:path (string-append (store-path-hash-part path) ".narinfo"))) + (url (resolve-uri-reference ref base)) + (headers '((User-Agent . "GNU Guile" +(build-request url #:method 'GET #:headers headers))) (define (narinfo-from-file file url) "Attempt to read a narinfo from FILE, using URL as the cache URL. Return #f -- 2.30.2
bug#44906: [PATCH 3/3] ci: Properly construct URLs.
Implement a new function "api-url", which constructs URLs using relative URI
and "resolve-uri-reference" (which implements the algorithm specified in RFC
3986 section 5.2.2) for building the URL, instead of just appending
strings. This avoids issued if the server-url ends with a slash.
Since "api-url" uses URI-objects, it makes sense to also construct the
query-part of the URL here. For this "api-url" accepts optional
key-value-pairs.
New function "json-api-fetch" is a wrapper using "api-url".
* guix/ci.scm (api-url): New function. (build): Use it.
(json-api-fetch): New function. (queued-builds, latest-builds,
evaluation, latest-evaluations, evaluation-jobs: Use it.
---
guix/ci.scm | 79 +++--
1 file changed, 46 insertions(+), 33 deletions(-)
diff --git a/guix/ci.scm b/guix/ci.scm
index dde93bbd53..cf39744567 100644
--- a/guix/ci.scm
+++ b/guix/ci.scm
@@ -20,9 +20,12 @@
(define-module (guix ci)
#:use-module (guix http-client)
#:use-module (guix utils)
+ #:use-module ((guix build download)
+#:select (resolve-uri-reference))
#:use-module (json)
#:use-module (srfi srfi-1)
#:use-module (ice-9 match)
+ #:use-module (web uri)
#:use-module (guix i18n)
#:use-module (guix diagnostics)
#:autoload (guix channels) (channel)
@@ -146,16 +149,41 @@
;; Max number of builds requested in queries.
1000)
+(define* (api-url base-url path #:rest query)
+ "Build a proper API url, taking into account BASE_URL's trailing slashes."
+
+ (define (build-query-string query)
+(let lp ((query (or (reverse query) '())) (acc '()))
+ (match query
+(() (string-concatenate acc))
+(((_ #f) . rest) (lp rest acc))
+(((name val) . rest)
+ (lp rest (cons*
+ name "="
+ (if (string? val) (uri-encode val) (number->string val))
+ (if (null? acc) "" "&")
+ acc))
+
+ (let* ((query-string (build-query-string query))
+ (base (string->uri base-url))
+ (ref (build-relative-ref #:path path #:query query-string)))
+(resolve-uri-reference ref base)))
+
+
(define (json-fetch url)
(let* ((port (http-fetch url))
(json (json->scm port)))
(close-port port)
json))
+(define* (json-api-fetch base-url path #:rest query)
+ (json-fetch (apply api-url base-url path query)))
+
+
(define* (queued-builds url #:optional (limit %query-limit))
"Return the list of queued derivations on URL."
- (let ((queue (json-fetch (string-append url "/api/queue?nr="
- (number->string limit)
+ (let ((queue
+ (json-api-fetch url "/api/queue" `("nr" ,limit
(map json->build (vector->list queue
(define* (latest-builds url #:optional (limit %query-limit)
@@ -163,28 +191,21 @@
"Return the latest builds performed by the CI server at URL. If EVALUATION
is an integer, restrict to builds of EVALUATION. If SYSTEM is true (a system
string such as \"x86_64-linux\"), restrict to builds for SYSTEM."
- (define* (option name value #:optional (->string identity))
-(if value
-(string-append "&" name "=" (->string value))
-""))
-
- (let ((latest (json-fetch (string-append url "/api/latestbuilds?nr="
- (number->string limit)
- (option "evaluation" evaluation
- number->string)
- (option "system" system)
- (option "job" job)
- (option "status" status
- number->string)
+ (let ((latest (json-api-fetch
+ url "/api/latestbuilds"
+ `("nr" ,limit)
+ `("evaluation" ,evaluation)
+ `("system" ,system)
+ `("job" ,job)
+ `("status" ,status
;; Note: Hydra does not provide a "derivation" field for entries in
;; 'latestbuilds', but Cuirass does.
(map json->build (vector->list latest
(define (evaluation url evaluation)
"Return the given EVALUATION performed by the CI server at URL."
- (let ((evaluation (json-fetch
- (string-append url "/api/evaluation?id="
-(number->string evaluation)
+ (let ((evaluation
+ (json-api-fetch url "/api/evaluation" `("id" ,evaluation
(json->evaluation evaluation)))
(define* (latest-evaluations url
@@ -192,16 +213,10 @@ string such as \"x86_64-linux\"), restrict to builds for
SYSTEM."
#:key spec)
"Return the latest evaluations performed by the CI server at URL. If SPEC
is passed, only consider the evaluations for the given SPEC specification."
- (let ((spec (if spec
-
bug#44906: [bug#49482] [PATCH 3/3] ci: Properly construct URLs.
Hi Mathieu, thanks for the review. I updated the doc-string, fixed the other parts and pushed as 3ee0f170c8bd883728d8abb2c2e00f445c13f17d. What about booleans? False is filtered above but true will throw an exception. False is used to omit elements from the query-string. Booleans and other types are not handled, since this low-level function doesn't know how to convert them into a string to be put into the query. #t could be "1", "t", "true", depending on the API used. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
bug#52244: commiter.scm: backtrace if commit fails
When commiting the change fails, committer.scm outputs a backtrace. While one can packagers be experienced enough to understand the error even if it is garbled by the backtrace, I propose suppressing it for two reasons: 1. The backtrace makes it harder to spot the actual error (since one needs to "parse" more text) 2. I often have issues with my guix development environment being instable. So when I see a backtrace from commiter.scm, I think about issues with my environment first - and not about an issue with git :-) Expected No backtrace, but a concise error message, like here: $ ./pre-inst-env guile ./etc/committer.scm gnu: python-stdnum: Update to 1.17. * gnu/packages/finance.scm (python-stdnum): Update to 1.17. error: gpg beim Signieren der Daten fehlgeschlagen fatal: Fehler beim Schreiben des Commit-Objektes. etc/committer.scm:399:24: Cannot commit Reproduce = There might be other ways to trigger a failing "git commit". For me it occured when using an outdated PGPG key for signing: 1. Configure git to use the outdated GPG key for signing, e.g. git config --get user.signingkey 634A8DFFD3F631DF 2. use committer.scm to commit some changes: $ ./pre-inst-env guile ./etc/committer.scm gnu: python-stdnum: Update to 1.17. * gnu/packages/finance.scm (python-stdnum): Update to 1.17. error: gpg beim Signieren der Daten fehlgeschlagen fatal: Fehler beim Schreiben des Commit-Objektes. Backtrace: In ice-9/boot-9.scm: 1752:10 7 (with-exception-handler _ _ #:unwind? _ # _) In unknown file: 6 (apply-smob/0 #) In ice-9/boot-9.scm: 724:2 5 (call-with-prompt _ _ #) In ice-9/eval.scm: 619:8 4 (_ #(#(#))) In ice-9/boot-9.scm: 2835:4 3 (save-module-excursion _) 4380:12 2 (_) In srfi/srfi-1.scm: 634:9 1 (for-each # …) In etc/committer.scm: 399:24 0 (_ _) etc/committer.scm:399:24: Cannot commit -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
bug#52834: sanity-check fails with namespace packages
Hi,
I just investigated some failing python packages
<https://ci.guix.gnu.org/eval/16105/dashboard> and found that
"python2-zppe-*" packages fail. (Most due to a dependency failing ,
though. Actually failing are python2-zope-testing and python2-zope-event).
These fail due to sanity-check not being able to import "zope" - which
is a namespace package. Both use the "src directory layout" (source is
contained in a sub-directory "src").
This could be solved by fetching a list og namespace-packages and
checking whether a fails import is a namespace-package. Maybe there are
other solution.
try:
nspkgs = set(dist.get_metadata_lines('namespace_packages.txt'))
except:
nspkgs = set()
Anyhow, since Python2 is EOL since long, I'm not sure whether it's worth
the effort.
WDYT?
--
Regards
Hartmut Goebel
| Hartmut Goebel | h.goe...@crazy-compilers.com |
| www.crazy-compilers.com | compilers which you thought are impossible |
bug#53309: Newly-added python-piexif fails to patch source due to CRLF(?)
Hi, Am 16.01.22 um 23:44 schrieb Tobias Geerinckx-Rice: This is worrying since I'd expect all this to be 100% reproducible, and it seems to work fine for both you & Ludo'… I have to admit that I did not test the patch again after converting the line-endings - which Ludo asked for. Changing the line-endings was too simple FMPOV - I trusted Ludo's recommendation. I'll fix this. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
bug#53309: Newly-added python-piexif fails to patch source due to CRLF(?)
Fixed in af47145e995c9d3d116a60053648b4f35e2ed125 -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
bug#36938: Website: Package list is not updated
The package list at http://guix.gnu.org/packages/ is not updated. It still says: […] provides 9,789 packages […] (updated July 19, 2019). -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
bug#26175: [bug#36976] [PATCH 1/1] download: Map file-name characters not allowed in store.
Hi Ludo, while http://issues.guix.gnu.org/issue/36976 is going to solve the issue for "guix download", I found that there are other cases where invalid characters in store names appear. Thus we need a more elaborate solution - or several solutions. Any suggestions which cases to check and how to fix them? E.g. "@" and "%" are not allowed in package source base names: When building the package below, which used the "offending URL, yields an error: guix build: error: invalid character `@' in name `kde-l10n...@valencia-14.11.80.tar.xz.drv' Same when trying to work around this be using "…%40…". (use-modules (guix packages) (guix download) (guix build-system gnu)) (package (name "kde-l10n-ca-valencia") (version "14.11.80") (source (origin (method url-fetch) (uri (string-append "mirror://kde//Attic/applications/" version "/src/kde-l10n/" "kde-l10n-ca@valencia-" version ".tar.xz")) (sha256 (base32 "1mqadassxcm0m9r1l02m5vr4bbandn48xz8gifvxmb4wiz8i8d0w")))) (build-system gnu-build-system) (synopsis "") (description "") (license "") (home-page "")) -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
bug#26175: [bug#36976] [PATCH 1/1] download: Map file-name characters not allowed in store.
Am 04.09.19 um 12:32 schrieb Ludovic Courtès: > Hi, > > Hartmut Goebel skribis: > >> (origin >> (method url-fetch) >> (uri (string-append "mirror://kde//Attic/applications/" >> version "/src/kde-l10n/" >> "kde-l10n-ca@valencia-" version ".tar.xz")) > In this case just add a ‘file-name’ field. I think that’s a reasonable > expectation. > > Thanks, > Ludo’. Agreed. WDYT about adding this as a hint when the error shows up? How can I catch the "error: invalid character `@' in name" in guix build? -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
bug#30345: Acknowledgement (guix refreh --type=kde does not update all KF5 packages)
Closed by http://debbugs.gnu.org/cgi/bugreport.cgi?bug=36919 commit 4eb69bf0d33810886ee118f38989cef696e4c868 -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
bug#25020: Finally fixed
Finally fixed by by http://debbugs.gnu.org/cgi/bugreport.cgi?bug=36919 commit 4eb69bf0d33810886ee118f38989cef696e4c868 -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
bug#29071: Acknowledgement (guix refresh --type=kde does not update all kde packages)
Finally fixed by by http://debbugs.gnu.org/cgi/bugreport.cgi?bug=36919 commit 4eb69bf0d33810886ee118f38989cef696e4c868 -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
bug#28159: Updater needs to support HTTP(S) servers
Am 22.08.17 um 10:57 schrieb Ludovic Courtès: > More precisely, several updaters rely on FTP (gnu, kernel.org, kde, > etc. see (guix gnu-maintenance)), but others rely on structured data > retrieved over HTTP(S) (pypi, cran, elpa, etc.) For the records: KDE no longer relies on FTP access. It now fetches the ls-lR.bz2 file list using HTTPS from download.kde.org, converts it into a list of file paths and caches the list. See http://debbugs.gnu.org/cgi/bugreport.cgi?bug=36919 commit 4eb69bf0d33810886ee118f38989cef696e4c868 -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
bug#26175: [bug#36976] [PATCH 1/1] download: Map file-name characters not allowed in store.
Done, see dec845606d2d184da31065fa26cd951b84b3ce2d and <http://issues.guix.gnu.org/issue/36976#5> -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
bug#37523: Print hint if build fails due to invalid character in package source base name
Followup to <http://issues.guix.gnu.org/issue/26175#4>: guix shall print a hint if building fails due to the package source base name containing a character invalid in a store filename (e.g. "@" or "%"). Currently, when building such a package, one gets an error message like: guix build: error: invalid character `@' in name `kde-l10n...@valencia-14.11.80.tar.xz.drv' guix build should catch this error and print a hint like: You may add a ‘file-name’ field to the package source to work around this. Ludovic Courtès wrote on Sun Sep 08 22:07:10+0200 2019 > Unfortunately it cannot really be caught. I mean, you could catch > ‘&store-protocol-error’ error conditions, but then the error message is > just a string, there’s no error code you can compare against. Example package raising this error: (use-modules (guix packages) (guix download) (guix build-system gnu)) (package (name "kde-l10n-ca-valencia") (version "14.11.80") (source (origin (method url-fetch) (uri (string-append "mirror://kde//Attic/applications/" version "/src/kde-l10n/" "kde-l10n-ca@valencia-" version ".tar.xz")) (sha256 (base32 "1mqadassxcm0m9r1l02m5vr4bbandn48xz8gifvxmb4wiz8i8d0w")))) (build-system gnu-build-system) (synopsis "") (description "") (license "") (home-page "")) -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
bug#37606: CI reports "failed" even if build succeeds
Hi, I just stepped over <https://ci.guix.gnu.org/build/1781422/details>, which i reported as "failed". But wen looking at the log-file, this says: "@ build-succeeded /gnu/store/a8hakfaf7a41ywxrssqlscqgcn642lhc-python-django-allauth-0.39.1.drv". Maybe someone knowledgeable micht want to have a look. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
bug#37616: Libgcrypt warning: missing initialization
Hi, the system logs for guix show this error: guile: Libgcrypt warning: missing initialization - please fix the application Full log: systemd[1]: Started Build daemon for GNU Guix. guix-daemon[28968]: accepted connection from pid 28973, user nobody guix-daemon[28968]: accepted connection from pid 28990, user hartmut guix-daemon[28968]: spurious SIGPOLL guile[28999]: Libgcrypt warning: missing initialization - please fix the application guix-daemon[28968]: SIGPOLL guix-daemon[28968]: unexpected build daemon error: interrupted by the user Build like this: $ su - # guix environment guix # guix pull -commit=ccbc1c5eb2 # guix package --fallback -u # grep ExecStart= /etc/systemd/system/guix-daemon.service ExecStart=/usr/local/sbin/guix-daemon --build-users-group=guixbuild --substitute-urls="https://ci.guix.gnu.org"; # /usr/local/sbin/guix-daemon --version guix-daemon (GNU Guix) 1.0.1-6.0ed97e6 -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
bug#38926: pcmanfm-qt unable to open files by double click
Am 05.01.20 um 23:37 schrieb Danny Milosavljevic: Re. <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38926> > No idea how to do that with Qt programs. Hartmut? For Qt/KDE I did not actually address this topic yet. I tend to handle this case-by-case: If the coupling is "tight" and if this is a hard requirement (or a small dependency) I'd substitute the paths was you suggested. Otherwise I rely on the required package to be installed my the user or some service definition. In this special case: To avoid installing all of glib:bin (and thus glib), we could create a new package "gio-launch-desktop", containing only this binary. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible | signature.asc Description: OpenPGP digital signature
bug#39996: foreign distro: QT5 loads/searchs plugins from wrong location
I just packages a simple GUI application using pythonqt5 and
python-poppler-qt. When running it fails with:
Could not load the Qt platform plugin "xcb" in "" even though it was
found.
When running with QT_DEBUG_PLUGINS=1 it reveals the cause:
QFactoryLoader::QFactoryLoader() checking directory path
"/usr/lib64/qt5/plugins/platforms" ...
QFactoryLoader::QFactoryLoader() looking at
"/usr/lib64/qt5/plugins/platforms/KWinQpaPlugin.so"
Found metadata in lib
/usr/lib64/qt5/plugins/platforms/KWinQpaPlugin.so, metadata=
[… many lines skipped …]
Got keys from plugin meta data ("xcb")
QFactoryLoader::QFactoryLoader() checking directory path
"/gnu/store/608bvypsh90c58apvd2cgg3m9l2pwjqn-python-3.7.4/bin/platforms"
...
Cannot load library /usr/lib64/qt5/plugins/platforms/libqxcb.so:
(libQt5XcbQpa.so.5: cannot open shared object file: No such file or
directory)
QLibraryPrivate::loadPlugin failed on
"/usr/lib64/qt5/plugins/platforms/libqxcb.so" : "Cannot load library
/usr/lib64/qt5/plugins/platforms/libqxcb.so: (libQt5XcbQpa.so.5:
cannot open shared object file: No such file or directory)"
Looks like the plugin is search in the wrong location and also the list
of plgins.
--
Regards
Hartmut Goebel
| Hartmut Goebel | h.goe...@crazy-compilers.com |
| www.crazy-compilers.com | compilers which you thought are impossible |
signature.asc
Description: OpenPGP digital signature
bug#39996: foreign distro: QT5 loads/searchs plugins from wrong location
Hi Marius, > Does it help if you wrap it with QT_PLUGIN_PATH, as we do with some > other KDE applications? I was able to work-around this by setting QT_PLUGIN_PATH. (Installing qtbase has worked, too, btw) Nevertheless I which this would not be necessary. I'd expect the qtbase to find the plugins and platform-plugins coming with itself. (As far as I've seen from the Nixpkg, nix has the same issues, so no solution to copy from there.) -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible | signature.asc Description: OpenPGP digital signature
