Removal of Python 2?
Am 06.06.21 um 21:44 schrieb Lars-Dominik Braun: 3) Determine the fate of Python 2, which is probably broken through this patch set. Shall we remove it entirely? Is it worth to keep support? Python 2 is dead, dead, dead like the parrot and end-of-prolonged life as of more than 1 1/2 years. Anyhow, there might still be quite some software not ported to Python 3 after 10 years. So I'm afraid we need to keep Python 2. Other opinions? -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: [core-updates] texlive 2021 bootstrap problem
Hello, Em terça-feira, 15 de junho de 2021, às 16:00:51 -03, Thiago Jung Bauermann escreveu: > Does anyone have an idea how to break this dependency loop? Do we need to > have a package definition for a pre-2019-10 version of LaTeX just to > build texlive-latex-l3kernel, and then use that as a dependency for the > actual texlive-latex-base package? I’m pursuing this option. I took the definition of texlive-latex-base from the master branch (which doesn’t depend on LaTeX3) and added it to my branch as texlive-latex-no-l3 (with a few minor changes to get it to build with texlive 2021), and used it as a dependency to build texlive-latex- l3kernel. This worked! Now texlive-latex-l3kernel builds correctly, and the build of texlive-latex-base is attempted (instead of just causing Guix to max out its heap while trying to process a dependency loop, as it was doing before). But the build fails when generating some latex formats – a problem I’m still investigating. But this is progress nevertheless. :-) > If anyone wants to have a look at what I have so far, I pushed my patch > to branch “bug-48064-texlive-2021” at https://gitlab.com/bauermann/guix I just force-pushed this branch with my current version of the patches. -- Thanks, Thiago
Re: Crystal Bootstrapping Journey
Hi jgarte et al.
Am Montag, den 21.06.2021, 16:33 + schrieb jgart:
> Hi Guix,
>
> We've (Ryan, David, Raghav, and others) started packaging crystal for
> guix: https://crystal-lang.org/
>
> See 49142 and 49158 in the issue tracker.
>
> Here are some notes, questions, and a list of dependencies regarding
> what is needed to finish a properly bootstraped crystal package:
>
> https://github.com/ryanprior/guix-packages/blob/master/testing/crystal.org
>
> We are trying to recreate this bootstrapping process:
>
> https://github.com/crystal-lang/bootstrap-script
>
> There are 160 stages!
>
> A few questions extracted from the notes follow:
>
> Is it preferable to have 160 bootstrap packages, one for each stage,
> or one big bootstrap package with 160 build-* stages, or somewhere
> inbetween?
I second Maxime's reply on 49158. 159 hidden packages, plus a final
exported one.
> Each stage needs a different checkout of the git repository - can we
> preserve info in .git such that we can checkout again during the
> build, or do we want to have each checkout be an independent input to
> the package?
Given that we want 160 packages, maybe, but actually no.
> How best can we use Guile macros to clean up the large amount of code
> implied by executing 160 stages of bootstrap logic?
Note how many of the stages (particularly later ones) manage to
bootstrap one version from the previous. You might therefore want to
make a "one-liner" package
(define crystal-stage-N (bootstrap-crystal "version@N" crystal-stage-
{N-1}))
Then use Emacs macros to generate 160 lines ;P
It's not quite as simple, because the arguments to crystal change at
some point, but you could spawn off several "phases" from a relative
generic boostrap-crystal procedure. E.g. the final phase would have
#:crystal-args '("build" "--stats" "-Dwithout_openssl" "-Dwithout_zlib"
"-Di_know_what_im_doing")
Regards,
Leo
Re: bug#47867: [1.2.1 pre-release testing] substitute downloading and TLS errors
Hi, Ludovic Courtès skribis: >>> I double-checked and the GnuTLS Guile bindings already >>> handle GNUTLS_E_AGAIN and GNUTLS_E_INTERRUPTED, so my guess is that this >>> was just a side effect of dealing with stale TLS sessions: >>> https://gitlab.com/gnutls/gnutls/-/blob/master/guile/src/core.c#L1042 >> >> Strange,. > > My bad: I was looking at ‘read_from_session_record_port’, but the > problem is in ‘write_to_session_record_port’. All is clear now. > > I’ve pushed these as two separate patches: > > c50db7156d http-client: Remove exception mishandling in 'http-multiple-get'. > 02d62978f4 http-client, substitute: Gracefully handle GnuTLS EAGAIN/EINTR. > > This bug should be gone now. > > I’ll go ahead and fix ‘write_to_session_record_port’ in GnuTLS. It took a while but this is now fixed in GnuTLS: https://gitlab.com/gnutls/gnutls/-/merge_requests/1417 I *think* the fix will be included in 3.7.3 (it’s not in 3.7.2, released a couple of weeks ago). Ludo’.
Crystal Bootstrapping Journey
Hi Guix, We've (Ryan, David, Raghav, and others) started packaging crystal for guix: https://crystal-lang.org/ See 49142 and 49158 in the issue tracker. Here are some notes, questions, and a list of dependencies regarding what is needed to finish a properly bootstraped crystal package: https://github.com/ryanprior/guix-packages/blob/master/testing/crystal.org We are trying to recreate this bootstrapping process: https://github.com/crystal-lang/bootstrap-script There are 160 stages! A few questions extracted from the notes follow: Is it preferable to have 160 bootstrap packages, one for each stage, or one big bootstrap package with 160 build-* stages, or somewhere inbetween? Each stage needs a different checkout of the git repository - can we preserve info in .git such that we can checkout again during the build, or do we want to have each checkout be an independent input to the package? How best can we use Guile macros to clean up the large amount of code implied by executing 160 stages of bootstrap logic? best regards, jgart ps If you'd like to discuss more and help us in this effort reply here and/or come join us this Saturday for another guix packaging meetup: https://events.nixnet.services/events/11610807-dd89-47e7-bd6c-64429e48e338
Re: python-distlib vs python-distlib/next
Hi, Am Montag, den 21.06.2021, 12:32 +0200 schrieb Ricardo Wurmus: > Hi, > > commit ce6efff6eca0ed88cb9538803f5d1252c91a3b5e updated > virtualenv. As part of this change python-distlib was replaced > with python-distlib/next. > > This broke the *installation* (not the build) of other packages > such as python-pygenometracks. The reason is that the closure of > python-pygenometracks would include both python-distlib and > python-distlib/next. Guix would then prevent the installation of > python-pygenometracks into user profiles: > > > guix package: error: profile contains conflicting entries for > > python-distlib > > guix package: error: first entry: python-distlib@0.3.1 > > /gnu/store/mypg42bass5n61liwyq7llrwla4w8bny-python-distlib-0.3.1 > > guix package: error:... propagated from > > python-virtualenv@20.2.1 > > guix package: error:... propagated from python-tox@3.20.0 > > guix package: error:... propagated from > > python-argh@0.26.2-1.dcd3253 > > guix package: error:... propagated from > > python-gffutils@0.9-1.4034c54 > > guix package: error:... propagated from > > python-pygenometracks@3.3 > > guix package: error: second entry: python-distlib@0.3.0 > > /gnu/store/fwya18dazamh2cjdkgh5wpxi7lqn4fcm-python-distlib-0.3.0 > > guix package: error:... propagated from > > python-sortedcontainers@2.1.0 > > guix package: error:... propagated from > > python-intervaltree@3.0.2 > > guix package: error:... propagated from > > python-pygenometracks@3.3 > > We can’t easily detect these problems because they only strike at > installation time. This means that we may not do partial upgrades > in the Python world due to the quirks of propagation. There may > be other packages that are broken in a similar fashion right now. > > How can we make this more robust and avoid problems like this in > the future? I think we can detect this and similar breakages through the use of graph algorithms. Start with all versions of your input package as nodes and no edges. For all packages P, add packages P' that immediately propagate P as nodes to G and PP' as edge. Repeat this until closure is reached. Your closure should now have as many components as you had versions. If not, then by the pigeonhole principle you have a propagation conflict. If you want to be eager, you can also try to colour your graph, such that each component gets a unique colour, which is assigned to the initial P a priori (use BFS to propagate colours). If a package would receive two colours from that operation, you again have a propagation conflict, but you also know which packages cause it. I think we should be able to implement one of those algorithms in `guix graph`. Then people could check whether their change to a propagated input breaks anything, whether in Python or elsewhere. Regards, Leo
python-distlib vs python-distlib/next
Hi, commit ce6efff6eca0ed88cb9538803f5d1252c91a3b5e updated virtualenv. As part of this change python-distlib was replaced with python-distlib/next. This broke the *installation* (not the build) of other packages such as python-pygenometracks. The reason is that the closure of python-pygenometracks would include both python-distlib and python-distlib/next. Guix would then prevent the installation of python-pygenometracks into user profiles: guix package: error: profile contains conflicting entries for python-distlib guix package: error: first entry: python-distlib@0.3.1 /gnu/store/mypg42bass5n61liwyq7llrwla4w8bny-python-distlib-0.3.1 guix package: error:... propagated from python-virtualenv@20.2.1 guix package: error:... propagated from python-tox@3.20.0 guix package: error:... propagated from python-argh@0.26.2-1.dcd3253 guix package: error:... propagated from python-gffutils@0.9-1.4034c54 guix package: error:... propagated from python-pygenometracks@3.3 guix package: error: second entry: python-distlib@0.3.0 /gnu/store/fwya18dazamh2cjdkgh5wpxi7lqn4fcm-python-distlib-0.3.0 guix package: error:... propagated from python-sortedcontainers@2.1.0 guix package: error:... propagated from python-intervaltree@3.0.2 guix package: error:... propagated from python-pygenometracks@3.3 We can’t easily detect these problems because they only strike at installation time. This means that we may not do partial upgrades in the Python world due to the quirks of propagation. There may be other packages that are broken in a similar fashion right now. How can we make this more robust and avoid problems like this in the future? (I worked around this problem for pygenometracks by removing python-tox from the propagated inputs of python-argh.) -- Ricardo
