Hi,
> To avoid problems, I suggest you send your account name as a public
> reply to this message, in a signed message.
https://codeberg.org/ldb
Thanks,
Lars
signature.asc
Description: PGP signature
Hi,
> As last time, I found what is probably another unhandled case in the
> toml parser, while trying to build python-scikit-learn@1.6.1.
> It fails to parse:
sorry about that, a patch is available in #78013, but beware that it’s
a world rebuild.
Cheers,
Lars
Hi,
> Interesting! So, there would be like a 'guix-history' channel that one
> could use with time-machine?
either that or just keep the current repo at the current location and
start fresh at a new location.
Lars
Hi,
> I'm not sure this is worth it, but maybe we can do better! If we were to
> prune the repo in this way, it would break `guix time-machine`, which is
> a nice selling point of Guix and really valuable.
I doubt this would cause much breakage. As long as we keep the old
repository in place exis
Hi,
> ## Repository Migration Path
do we want to take this opportunity to start off fresh without migrating
the main repository’s history? It looks like we have accumulated more
than 500MB of commit data so far and everyone who runs `guix pull` the
first time has to download all of that and authe
Hi,
> Would it be helpful to open a bug about this?
there is https://issues.guix.gnu.org/69997, which includes patches to
add initial pyproject.toml support to `guix import pypi`.
Lars
Hi Ian,
> Since this merge landed, the builds for several Python packages in my
> personal channel broke. Any package using pyproject-build-system for a
> Python project using setuptools seems to be affected.
as Sharlatan Hellseher wrote in https://issues.guix.gnu.org/issue/74715#4,
you need t
Hi,
> Yes. There are some packages where this change was not trivial, though.
do you have examples? Maybe we have to improve pyproject-build-system?
Lars
Hi,
> Is there a specific reason why we’re following the Stackage releases?
> Stackage is one step slower in getting the updates. The current Stackage
> Nightly is 9.8.2, while Hackage has 9.10.1. Is this due to some stability
> issues with Hackage?
Stackage’s package collection is coherent an
Hi,
> > Also, is the process of adding a GHC release, or any Haskell package
> > any different from the typical procedure to add a package? I'd like
> > some introductory guidance/resources to learn that.
>
> Not really, but this specific update (GHC 9.4 to 9.6) is quite tricky
> because GHC chan
Hi,
> so, i think a lot of packages should be in channels. probably everything that
> is not essential for a minimally functional system that can bootstrap itself.
> part of python could be in the main guix repo, but whatever is not tightly
> needed could go into a channel with its own access c
Hi,
> I'd like to check who is working on python-team branch to prepare it for
> the merge?
I don’t think anyone is actively working on it right now. #71408 is
the place where any updates should be if there were any. CC’ing a few
people who have contributed to the branch or stated they have inter
Hi,
I received a TLS client certificate for ci.guix.gnu.org about a year ago,
but it expired in June. Unfortunately I cannot figure out who created
it back then. Can someone renew the certificate?
Thanks,
Lars
Hi Christopher,
> The following branches all seem to have commits that haven't made it to
> master yet, although I haven't checked if the changes were applied but
> just with different commit ids.
>
> - haskell-team
I will open a request to merge this branch after I updated to the latest
possib
Hi Ludo,
> This has been running for ~4 days now; the number of pending builds has
> significantly decreased (in particular, you’ll be delighted to get
> substitutes for ‘core-updates’!):
excellent, thank you very much!
Lars
Hi Ricardo,
> * maintenance of R, as well as CRAN and Bioconductor packages.
is there anyone who will look after the automated channels
guix-cran/guix-bioc (and possibly guix-science)?
> * Finishing the python-team branch.
>
> We wanted to merge the "python-team" branch soon, which contains
>
Hi,
I’d like to merge the haskell-team branch. Changes are rather small
this time, but I still need CI to build the branch to be able to assess
the damage done. Unfortunately Cuirass has not been processing scheduled
jobs of this evaluation[1] for about a week now. What can we do about
that?
Than
Hey,
> I have heard folks in the Guix maintenance sphere claim that we never rewrite
> git history in Guix, as a matter of policy. I believe we should revisit that
> policy (is it actually written anywhere?) with an eye towards possible
> exceptions, and develop a mechanism for securely maintai
Hi,
> I'm planning on refreshing Guix's haskell packages as my fix for
> https://issues.guix.gnu.org/66347 requires rebuilding all of them
> anyway. Should I try to keep commits small with only one update per
> commit (which is more work but managable if I don't care about the
> commits being buil
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 htt
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 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 python-t
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 availab
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 Andreas,
> I wanted to set up automatic building on cuirass for the Python updates
> branch, but was not sure which one it is:
> $ git branch -a | grep python
> remotes/origin/python-updates
> remotes/origin/wip-python-graphviz
> remotes/origin/wip-python-mne
> remotes/origin/wip-python
Hi,
> Gtk:ERROR:gtkiconhelper.c:494:ensure_surface_for_gicon: assertion failed
> (error == NULL): Failed to load
> /gnu/store/vkcl29s7qcfgqz1cs6lab98fyxsxyczx-adwaita-icon-theme-43/share/icons/Adwaita/48x48/status/image-missing.png:
> Unrecognized image file format (gdk-pixbuf-error-quark, 3)
>
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 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 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
th
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,
> 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?
la
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 tes
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
bui
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 me
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,
> 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 fo
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:
https://github.com/kurtmckee/feedp
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 python-co
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 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 ec79901a33b6463ad77dcaf4c37e538
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.
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
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 i
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,
> 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 modules
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] https://ci.guix.gnu.org/eval/230900?
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,
> 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 f
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 close
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 versi
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
witho
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 pha
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 world-rebuildi
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 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 F
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 time-consu
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 rea
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 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
/gnu/stor
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 wip-pytho
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?
>
> No
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] https://github.c
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 comm
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
> input
Hi,
> Sounds good, thanks for the fix!
d921516f50a946e92f9d5dc6d3bd49aca9788ac2 services: greetd: Remove unnecessary
user groups.
Cheers,
Lars
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,
> 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,
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, becau
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
> (/gnu/store/mxkp1zl64cd3i247shp7njkxad8v13x9-python-pyflakes-2.4.0/lib/pyth
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 jgart,
> ==
> FAIL: test_search_submodule (ropetest.contrib.autoimporttest.AutoImportTest)
> --
> Traceback (most recent call last):
> File
> "/tmp/guix-bui
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 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 importer,
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 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
+++ b/we
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'
> (/gnu/store/b11zrncrhbpslivk5qpzxsy36b6hsfpw-python-sqlalchemy-1.4.27/lib/python3.9/site-packages/sqlalchemy
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 – especia
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 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 depend
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,
> 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 k
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
python-jupyter-packagin
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 document
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, %current-target-syst
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 b
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 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,
> 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
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 Inst
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 that
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
0a379de3249d5e9ff66fb404
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,
> 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 if
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 an
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 pa
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 g
1 - 100 of 121 matches
Mail list logo
