Hi,
in light of bug#38576 I filed, I’d like to get some guidance on when to pull in
dependencies. The package in question is r-irkernel, which is essentially an R
package bridging between Jupyter and R. However, it would never be “imported”
by the user like other R packages. Instead Jupyter
Hi,
> Hello Braun, I have pushed the previous 4 patches into master, thank you!
thanks.
> This is not a small change for me, as 'guix refresh -l python-cryptography'
> says:
> Building the following 167 packages would ensure 367 dependent packages are
> rebuilt...
True, I did not check that,
,
Lars
[1] https://legacy.python.org/dev/peps/pep-0394/
>From 66e5568885199a734fda7946a6cbe32a09218dee Mon Sep 17 00:00:00 2001
From: Lars-Dominik Braun
Date: Fri, 10 Jul 2020 14:12:36 +0200
Subject: [PATCH] WIP: Proper pypy3 support
---
gnu/packages/check.scm|
Hi simon,
> Does it make sense to have something like "package-with-pypy" using
> "package-with-explicit-python"? Because it would be easy to rebuild
> all the pure Python packages with PyPy instead of CPython.
that’s what I am proposing with my patch, however due to different
search paths
Hi,
> pypy3 works somewhat well for me already in this regard:
indeed, you’re right.
This will probably break for some packages, because python provides
Python 3.8 whereas pypy3 provides Python 3.6. (They’ve always lagged
behind and given that we’re going towards 3.10, well…) One example are
Hi,
> > Also, what about .pyc files? Does pypy create compatible .pyc files?
> Well, the .pyc generated by CPython should be compatible with the ones
> generated by Pypy, both VM targeting say Python 3.6.
> But there is no necessary compatibility between .pyc of Python 3.6 and
> Python 3.8, at
Hi,
> […] from my point of view, the good direction would be a “web-app frontend”,
> similarly to git-annex-assistant [1]. This design is more flexible because
> it could be used locally *and* could also be the front-end of some servers
> (e.g., build farms).
I have something like this on my
Hi Tanguy,
> So, I've tried packaging `python-keyring` with those two…
>
> `pep517` keeps on trying to download dependencies, which won't work.
>
> `build` crashes with "ZIP does not support timestamps before 1980",
> which, I guess is related to the fact that everything in the store is
>
Hi Hartmut,
> this is a good idea. (Since you where mentioning setuptools, I first was
> afraid your solution would be tightened to setuptools, but it is not.
> Well done!)
afaik pkg_resources is technically a part of setuptools, although it is
distributed with Python.
> This comment should go
Hi Vincent,
> I like the idea of better testing for our python packages, but would it be
> possible to avoid embedding the python code as scheme strings ?
> Like in a separate pure-python file.
I don’t know how unfortunately. Any ideas?
I moved it into a separate top-level variable now and
Hi Tanguy,
> Done! :-)
> I've eventually succeeded in ("properly") packaging a software managed
> with Poetry. And I've learned quite a lot on the way!
oh, I see. I’ve actually been trying to replace python-build-system with
a python-build based build. Attached is my current work in progress. I
Hi Ryan,
> I think if we do that then Python will need a treatment similar to GCC,
> where we don't expose the package and instead offer a compound package
> (could be called "python-toolchain" or just "python") which includes pip
> and setuptools. The last decades of python packaging have
* Python
packages broken by this new phase. I’m also aware this change needs to
go to core-updates.
Cheers,
Lars
>From 919fd78b1aff6c277baca396ef962a5dcd4e23ae Mon Sep 17 00:00:00 2001
From: Lars-Dominik Braun
Date: Sun, 3 Jan 2021 10:30:29 +0100
Subject: [PATCH] [WIP] build-system/python: Valid
Hi,
for reference, the patchset is now tracked by issue 45712
(http://issues.guix.gnu.org/45712)
Cheers,
Lars
Hi everyone,
just a quick reminder that an updated version (includes
python-toolchain) of this proposal is still looking for a code review or
further discussion. So if you feel confident about touching
python-build-system, please have a look at
https://issues.guix.gnu.org/46848#1
I’d be nice to
Hi Tanguy,
(cross-posting this to the issue itself too)
> Sorry if I'm (very) late, but apprently this hasn't made it to master
> yet, so… What the status? Do you still need a willing-but-maybe-not-qualified
> person to review or discuss your patch?
the patch set works, I can build many Python
packages so far.
Cheers,
Lars
>From a7c6750917f5dc2e1eaf34520f7e6b0e3d5e0d3c Mon Sep 17 00:00:00 2001
From: Lars-Dominik Braun
Date: Tue, 6 Jul 2021 14:13:51 +0200
Subject: [PATCH 1/2] dirty: build: Build Python packages using pip.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Conten
Hi Hartmut,
> sorry for being late for commenting on this (the time I can spend on
> guix is rather limited atm).
no problem, same thing on my side.
> *
>
> Not installing pip by default might break some user's environments.
> Anyhow, since using pip in guix is not such a good idea
Hi Hartmut,
> What should be the use of having a package without pip? Anything else
> than saving a few KB?
saving some space and unvendoring components that we also have separate
packages for. (As I understand it, ensurepip, which installs both pip and
setuptools, is merely a convenience tool
Hi,
very interesting read.
> However, I'm still thinking about how to attack Guix users. Somebody who
> adds an internal channel for their own packages could still be
> vulnerable to a dependency confusion attack via a compromised or
> manipulated Guix maintainer. The target of the attack could
Hi Pierre,
> Instead, I'd like the following behaviour:
> […]
hm, I feel that’s unnecessarly complex with lots of if’s and else’s. If
I could design the frontend from scratch, I’d have one command that does
profile/environment manipulation (because they’re essentially the same)
and one that can
Hi Pierre,
> My only complaint is that it's still a bit slow:
> Is there anything we can do to speed this up?
yeah, true. I’m think it’s still computing and building derivations, for
example using manifest->derivation for `prof-drv` and then again
built-derivations for `prof-drv`. Maybe if we
Hi everyone,
today I’m joining the Guix family as a new committer. Some of you might
know me already from guix-patc...@gnu.org or the last Guix Days in
Brussels, which I also attended.
I’m mainly working on Python and R packaging as part of my job at
leibniz-psychology.org. Apart from that I’ll
Hi Pierre,
> Do you have a link?
sorry, I meant, I wrote the patch that added the --profile switch, see
https://issues.guix.gnu.org/46291
> I'd love to see this merged! :)
The patch above is already merged.
Cheers,
Lars
signature.asc
Description: PGP signature
Hi,
> guix environment doesn't allow --ad-hoc to be used when --profile is
> set. I propose to have --ad-hoc add more packages to the container when
> using it with --profile.
I wrote the patch that adds this feature to `guix environment`. The idea
was to have a way to turn an existing profile
Hi Ricardo,
> Is there a way we can improve the quality of those Python packages that
> have tests disabled? I’d like to gain more confidence in these packages
> and be sure that at least all dependencies are among the inputs.
there is a new sanity check phase on core-updates, which should solve
lash.
See attached patch for a fix.
Can I simply push that to core-updates-frozen or is there anything else I
should do?
Lars
--
Lars-Dominik Braun
Wissenschaftlicher Mitarbeiter/Research Associate
www.leibniz-psychology.org
ZPID - Leibniz-Institut für Psychologie /
ZPID - Leibniz
Hi,
> From my point of view, yes you can push because it is a fix.
pushed as bac072e09bb80c172672e13782e1ed25ce04d6d5. Please don’t
hesitate to ping me if there’s any other issuse with the sanity check
phase.
Cheers,
Lars
Hi everyone,
it looks like eudev, which we heavily rely on, is dead upstream:
https://github.com/gentoo/eudev/issues/199
Looking at Gentoo’s ebuilds it should be possible to “extract”
and build udev from systemd’s sources.
Cheers,
Lars
Hi Christopher,
> Anyway, I wouldn't like for this change to lower the standard though,
> it's currently the only package in Guix with an invalid description (as
> far as I'm aware), is there some reason why it doesn't have one?
it simply fell through the cracks[1]. Commit
Hi Chris,
> So, I think I've recently switched to thinking about the problem as one
> of testing changes, rather than just testing patches. Since both patch
> series, and branches are used to propose changes, I think this makes
> sense.
I agree with this analysis and this was always something
Hi Maxim,
> I've grown to like our apparent lack of structure; we interact globally
> on any topic of interest and the discussions all happen in a shared
> space, which makes it easy to stay informed with everything that's going
> on (do we really need more mailing lists to follow? I don't think
Hi Ricardo,
> FWIW, mumi also lets you search patches as all contents are indexed:
>
> https://issues.guix.gnu.org/search?query=%22%28gnu+packages+python-web%29%22+is%3Aopen+tag%3Apatch
thanks, I didn’t think about that. I tried searching
for python-build-system, but not all patches –
Hello Ricardo,
> So… since numpy 1.20 is the exception here, could we perhaps …
> rename it? And then have python-numba import that renamed module
> “totally-not-numpy” instead of “numpy”? Could we thus avoid this
> conflict? If renaming is an option — how would it be done? Is it
> enough
Hi Théo,
> I don’t understand how this could happen though since the definition of
> python-setuptools seems just fine in python-xyz.scm ...
unfortunately our python package bundles setuptools 41.2.0, which will
collide with python-setuptools. I ran into the same issue with
Hi Théo,
> Ok I see, it makes more sense now. But then I wonder why I could package
> "python-ipydatawidgets" with "python-setuptools" and
> "python-jupyter-packaging" as native-inputs. I had no collision warning
> but didn’t change anything in "python-jupyter-packaging" or anything.
as far as I
Hi Ludo’,
> Right. PyPI/setup.py/.whl doesn’t contain info as to how to run tests,
> right?
technically setup.py has a standard test target, but it’s been
deprecated for years and it must be enabled manually by the project. I’m
not aware of any standard pyproject.toml approach to this. It might
Hi Ludo’,
> My understanding is that most of them require manual intervention—i.e.,
> one has to tweak what ‘guix import’ produces, even if we ignore
> synopsis/description/license, to set the right inputs, etc. If we were
> to estimate the fraction of imported packages for which manual changes
Hi Maxime,
> Currently, non-Linux is not supported by the GHC package. However,
> people learn how to package things by example (and by reading
> documentation, etc.), so I'd prefer to avoid (accidentally) teaching
> people to make their package definitions Linux-specific.
do we have any
Hi Maxime,
> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=89de1924cb535fc2c97d3654e21badaebd43518e
>
> > + ,@(if (string=? "i686-linux" (%current-system))
> […]
>
> Barring any reports of the contrary, I'd presume the same would
> apply for the Hurd. Also,
Hi Hartmut,
> ...checking requirements: ERROR: trytond-party==6.0.2 (python-stdnum
> 1.14 (/gnu/
> store/04i1p7rw5583g0la8d66qwzwlfs9rvhg-python-stdnum-1.14/lib/python3.9/site-pac
> kages), Requirement.parse('python-stdnum>=1.15'), {'trytond-party'})
it means that the package trytond-party
Hi,
> I just wanted to mention that python-sqlalchemy-utils sanity-check phase
> is broken.
> […]
> ImportError: cannot import name '_literal_as_text' from
> 'sqlalchemy.sql.expression'
>
Hi Guix,
and a warm welcome to Efraim!
Maybe update the about part of the website too? (See attached patch.)
Cheers,
Lars
diff --git a/website/apps/base/templates/about.scm b/website/apps/base/templates/about.scm
index 427b908..3d72adf 100644
--- a/website/apps/base/templates/about.scm
+++
Hi Chris,
> The Fedora document explains that at least the hosts cache will be
> handled by systemd-resolved. Can I expect Guix-built programs to "try
> to use systemd" when resolving host names, or is additional
> configuration likely to be required?
as far as I know systemd also plugs into the
Hi,
> […] or is it just a matter of successfully building all dependents that you
> are introducing against master?
basically this and running the system tests.
Lars
Hi,
> What is the cadence for merging the python-team branch into master?
> Should you do it, me, or someone else?
there’s no timeline or schedule. It happens when someone does the
integration and testing work. I don’t have the time to do this right
now, so please go ahead.
Note there’s also
Hi,
> What is the git approach for keeping the Python branch up to date? 閭
> Should I be rebasing off of master or something else?
yeah, that’s generally what I would do before working on it. Note that
you cannot force-push into Savannah. You have to remove the remote branch
and create it again.
Hi everyone,
it’s time to update our Haskell environment – again. GHC 9.0 has been
out for a while and Stackage updated its LTS distribution to version 19
recently, providing a new set of packages for GHC 9.0.
Additionally there some issues/patches regarding haskell-build-system
and the
Hi jgart,
> ==
> FAIL: test_search_submodule (ropetest.contrib.autoimporttest.AutoImportTest)
> --
> Traceback (most recent call last):
> File
>
Hi,
> Only root can write to /var/log, so wheel is irrelevant. And, indeed, greetd
> logs are being written as root:
oh, I guess they are written by greetd, not the greeter itself. Does
greetd work without the groups in questions? (I don’t have access to
a powerful machine right now to test it.)
Hi,
> Since greetd is currently being run as root, it doesn't need any
> extra group membership.
indeed, agreety works fine with that patch. I’d still keep the video
supplementary group, so one can run gtkgreet/wlgreet (if they ever pop
up in Guix). Any objections?
Cheers,
Lars
Hi,
I merged greetd.
> (group "wheel")
> (supplementary-groups '("users" "tty" "input" "video"
> "audio"))
> […]
> I can understand the need for tty and input, but why does the
> greeter user need the wheel and audio?
I believe wheel is necessary to write logs to /var/log,
Hi jgart,
> validating 'flake8'
> /gnu/store/zaw5z708sldm6v3qxjczcia7gl65dw5x-python-flake8-3.9.2/lib/python3.9/site-packages
> ...checking requirements: ERROR: flake8==3.9.2
> ContextualVersionConflict(pyflakes 2.4.0
>
Hi Ricardo,
> As a first step I’d suggest collecting teams, setting up the email
> aliases, and updating the website to show the existing teams. Here’s
> a draft of three teams:
* Python Team
Lars-Dominik Braun
* Haskell Team
Lars-Dominik Braun
Anyone interested to join these with me
Hi,
> It should, but sometimes there are bugs in the package definition or
> build system, in this case causing python-rdflib to refer to the
> native-input python-pytest. Likely it's the 'add-install-to-path' phase
> adding too much, a known issue, which could be solved by separating
>
Hi,
> Sounds good, thanks for the fix!
d921516f50a946e92f9d5dc6d3bd49aca9788ac2 services: greetd: Remove unnecessary
user groups.
Cheers,
Lars
Hi zimoun,
> In the light of «‘staging’ branch is open!» [1], it could be nice! :-)
there’s no way we’ll get this done by your proposed date May 8th. Last
time it took me two weeks full time to update everything. I don’t want
to delay the merge of staging for this.
> About the importer, I do not
Hi zimoun,
> Maybe it could be better to move the ’cabal-revision’ from the
> ’arguments’ field to the ’origin’ field.
> Perhaps, we could have a ’cabal-revision’ procedure returning a G-exp
> and put it under the ’snippet’ field.
> WDYT?
it would be awesome to have that functionality and I agree
Hi zimoun,
> Is it a manual in-place replacement? Or is it an automatic in-place
> update by Hackage infrastructure? Or do I miss a point?
>
> In all cases, these revised Cabal files are not archived elsewhere than
> in Hackage, right? The question is thus, where could we archive them?
>
>
Hi jgart,
> Hi, what's the status on packaging GHC >= 9.0?
> Is anyone working on that?
there is commit 7a9350c208be14484d4fa6d90c0169f40fcf500e on wip-haskell,
which adds GHC 9.0.2. No further work has been done to update the Haskell
ecosystem. Help is welcome though, because it’s very
Hi Marius,
> I expect many Python packages need to be updated for 3.10. To ease this
> process it would be great to get the revamped build system from
> 'wip-python-pep517' merged. I plan to look at it "soon", but volunteers
> welcome. :-)
not to discourage you from taking a look, but
Hi Mathieu,
> I noticed that while the "samba" test
> works fine on my machine, it fails on the CI:
> https://ci.guix.gnu.org/build/1495525/log/raw
> any idea why?
it works on my machine too. The log above says
---snip---
This is the GNU system. Welcome.
komputilo login: In execvp of
Hi Mathieu,
> 1. Defining your team scope, if you are already part of a team
I pushed scopes for the Haskell and Python teams, but especially for the
latter packages are all over the place and barely covered by file-based
scopes unfortunately.
Cheers,
Lars
Hi Maxim,
> commit 6a2e303d3a49baf7c222a70b91f453e9efd456c6
> Author: Maxim Cournoyer
> AuthorDate: Wed Oct 5 21:48:25 2022 -0400
>
> guix-install.sh: Improve prompt_yes_no procedure.
>
> * etc/guix-install.sh (_flush): New function.
> (prompt_yes_no): Clear input, then only
Hello Andrew,
> The Guix Maintainer Collective (tm) would like to welcome Andrew Tropin,
> aka abcdw, as our newest committer! I'm sure many of you recognize them
> from their work on Guix Home and their regular videos hacking on Guix,
> among other things.
welcome! Good to have you here as a
Hi,
> Thanks :-) Keeps the PRs away, or at least you can't prove
> otherwise.
you could also enable “temporary interaction limits”[1] in your org
account, which applies to all of its repositories. It’s only valid up
to 6 months, but maybe better than nothing…?
Cheers,
Lars
[1]
Hi Ludo,
> Please take a look and send patches if needed! If someone can come up
> with some kind of a logo for the Guix Days, that’d be great; otherwise
> we’ll just reuse the one from last year.
note that the Guix Days take place on February *2nd and 3rd* (correctly
identified as Thursday and
Hello Felix,
> I see build failures [1] for Ghc 9.2.5 in the Cuirass job set [2] for
> my own feature branch. [3] They are caused by a one-hour timeout. Did
> you folks figure out how to extend the timeout limit on Cuirass when
> working on your own branch? Thanks!
I don’t see GHC being rebuild
Hello Andreas,
> Maybe you had a transient test failure? "async" sounds like the kind of
> tests that could fail randomly...
unfortunately it is not a transient failure. I can reproduce it every
time I try to build python2 on core-updates, even with `--cores=1`.
And it also reproduces on master.
Hi Andreas,
> But I confirm that ghc@9.2.5 now fails its tests, it has happened a second
> time for me. Nothing in the recent commits to core-updates since I tried
> the last time springs to mind as obviously having a connection to these
> failures.
fixed by commit
Hello Andreas,
> excellent! It contradicts the feedparser author's statement that everything
> works well, so if you have the courage, maybe you could report the issue
> upstream.
I just saw it was fixed on the develop branch already, but there’s no
new release:
Hello Andreas,
> This one is used for python-feedparser, used for calibre and quodlibet.
> The feedparser author is not enclined to work on it:
>https://github.com/kurtmckee/feedparser/issues/328
> I would suggest to try compiling python-sgmllib3k (and potentially
> python-feedparser) without
Hi again,
> > > Right now I am left with a number of test failures that look real and
> > > cannot
> > > easily be solved by an upgrade (either because we are already on the
> > > latest
> > > version or because the tests still fail): python-sgmllib3k,
> > > python-typeguard
> > > and
Hello Andreas,
> the latest trial to compile ghc@9.2.5 resulted in many test errors,
> see below.
I tried to compile GHC on core-updates recently, but didn’t even get
to GHC 9.2.5, because python2 failed to build (test test_asyncore failed,
without any further information). Do you have any extra
Hi Andreas,
> This version requires python-importlib-metadata; not its latest version 6,
> but something at least 5 and less than 6. We were still at 4.something.
> So I have just updated it to 5.2.0, the latest version 5 from last December.
> This gives me python-json-spec, so I am one step
Hi,
> Right now I am left with a number of test failures that look real and cannot
> easily be solved by an upgrade (either because we are already on the latest
> version or because the tests still fail): python-sgmllib3k, python-typeguard
> and python-coveralls. See messages below.
I don’t know
Hi,
> just a heads-up: The long overdue Haskell update is finally rolling in,
> bumping our packages to Stackage release 20.5 and the compiler to 9.2. The
> corresponding issue is #61420.
the branch has been merged into master.
Lars
Hi,
> > the branch has been merged into master.
> \o/ Nice, thank you!
well, GHC fails a single testcase on i686 (which we did not test for
wip-haskell) right now[1], but it’ll take some rounds of building it
locally until I have this sorted out too.
Lars
[1]
Hi Andreas,
> *** File
> "/gnu/store/5i3yqwaqd8mayl2vr9lmrihxwv8203b1-python-pycrypto-2.6.1/lib/python3.10/site-packages/Crypto/Util/number.py",
> line 139
> value |= 2L ** (N-1)# Ensure high bit is set
> ^
> SyntaxError: invalid decimal literal
> error: in
Hi,
> Except that we have to decide what to do about its dependents...
upgrade or drop if not possible. pycryptodome does not provide an entirely
compatible interface (see https://www.pycryptodome.org/src/vs_pycrypto),
so we cannot simply switch existing packages from pycrypto to pycryptdome
Hi,
> Do we have a list of packages in the python importer that can be removed
> from inputs? Like already exists for hackage (and maybe others)?
I’m not aware of any list like that and to compile it we’d probably
have to build all python-* packages and check whether any of their
installed
Hi,
> I updated it to its latest version under its current name python-cheetah,
> but would suggest to rename it to python-ct3. What do you think?
I don’t think we should follow PyPi’s names strictly. python-cheetah3
makes much more sense than python-ct3. That’s what upstream-name is for.
Lars
Hi Andreas,
sorry, I can’t quite keep up with the Python issues on core-updates
right now :(
> Yet another python failure: python-pathlib
this is a backport of Python’s built-in pathlib library. It should be
dropped as a dependency for all of these packages, since our Python is >=
3.4 – the
Hi Andreas,
> This also did not work - timeout after 3600 seconds of silence,
> the property is overwritten by the guix daemon, I think.
> Anyway, as said before, I rather think this is a real problem with
> the tests (maybe depending on some special situation on berlin if you
> could build it on
Hi Simon,
> and instead we could try this shorter one:
>
>7.8.4
> -> 8.0.2 (needs >= 7.10)
> -> 8.4.4 (needs >= 8.0)
> -> 8.8.4 (needs >= 8.4)
> -> 9.2.5 (needs >= 8.6)
>
> WDYT? If no objection, I will give a try.
note that the information on haskell.org is not always accurate and thus
Hi Andreas,
> Well, I would see this as rather an action for a later feature branch.
> Except for removing 9.0 by building 9.4 with 9.2, since 9.0 does not
> build now anyway.
shouldn’t this snippet from 8.10 also work for 9.0?
(modules '((guix build utils)))
(snippet
Hi Andreas,
> Probably so! I will let you decide whether to apply it or to drop the 9.0
> version, both are fine from the core-updates point of view.
I fixed 9.0 in commit dc9c09023a5258de035424169b8e804acfd38cb2, but 9.4
still fails :( Will investigate.
Lars
Hi Simon,
> Thanks for checking. It also builds for me locally. So I guess,
>
> +(properties
> + ;; 3 hours to avoid time-out in the check phase.
> + `((max-silent-time . 10800)))
>
> would be helpful. And it should be inherited by 9.2.5 so it should
> also build on CI. WDYT?
Hi again,
> I just updated python-ipython to the first version that passes all tests
> without any change, in the hope that this would have the least impact on
> its dependents. Without luck, now python-trio fails. Updating this to the
> latest version 0.22 does not help. I copy-paste the error
Hello Andreas,
> I looked at it and it seems that python-sip and python-pyqt-builder need a
> version bump and we should maybe switch to pyproject-build-system. However
> python-sip does not expose any switches to specify a different path for
> .sip file includes. That requires custom patches for
Hi Andreas,
> I have just fixed calibre. It failed to build because .sip fails are
> now in a subdirectory /lib/python3.10/site-packages/PyQt5/bindings
> instead of /share/sip (or maybe before, they were in both directories).
no, it was definitely in /share/sip before, but the pyproject-based
Hi,
> Well, there is pyqt as written elsewhere, but this is not only python.
I looked at it and it seems that python-sip and python-pyqt-builder need a
version bump and we should maybe switch to pyproject-build-system. However
python-sip does not expose any switches to specify a different path
Hi,
> Simon, what do you think about emailing the authors of the “10 years of
> stories” post asking if they agree with the licensing? :-) No rush,
> though the sooner the more likely we are to get an answer.
I’m also fine with the terms proposed here.
Lars
Hi Andreas,
> I do not think we should coordinate, this was part of the motivation for
> considering feature branches in the first place, to avoid entanglement
> with different updates.
ah, alright. I’ll give everyone more time for reviews and then just
merge it.
> However, QA has not run yet:
>
Hi,
just a heads-up: The long overdue Haskell update is finally rolling in,
bumping our packages to Stackage release 20.5 and the compiler to 9.2. The
corresponding issue is #61420.
Is there anything preventing a merge into currently? Can we coordinate
the merge with some other big
Hi Simon,
> About GHC, I am trying to build ghc-8.10.7 on core-updates for i686. It
> could be nice to fix it. Well, I will be happy if someone™ beats me. ;-)
GHC 8.10.7 on i686 built fine for me locally with all timeouts
disabled. 9.2.5 is not done yet, but is slowly processing through the
Hi,
> a less frequent drop in substitute availability on master would considerably
> elevate my satisfaction with guix as a user. and in my reading that is the
> cost that Christopher talks about here.
I was also unhappy enough to pull after the change was made, but
substitutes were not
Hi,
> Everything looks great, except that GHC failed to build from source
> locally. (I know GHC bootstraps separately.) I don't think my code
> caused the failure, but it's possible. Looks like it failed in the
> tests.
could you share your changes? The logs are rather unhelpful.
Cheers,
Lars
Hi Andy,
> curious poetry is not named python-poetry in Guix as following
> convention of most python packages
packages providing a binary instead of a library usually skip the
language-specific prefix, because the programming language does
not matter in that case.
Lars
Hi Reza,
> Poetry is not building on ci.guix.gnu.org [1]. There is a pending patch
> [2] on the issue tracker. What is missing to apply this patch and how
> can I help?
both contributors to that issue – John and me – are busy with other
things right now. That’s all.
My proposal in the
1 - 100 of 108 matches
Mail list logo