Re: GNU Guix 1.2.0rc2 available for testing!
On November 19, 2020, Pierre Neidhardt wrote: > [--without-tests] would encourage untested builds if I > recall correctly That may have been a concern (I wasn't part of the conversation) but I don't see how the current implementation could do that. If a normal "guix build foo" fails, then it's a busted package period. I'm glad for the "without-tests" option because when I'm working on packages with a test suite that takes more than a few seconds, I like to make sure that the rest of everything is working before I start running the tests. Another thing I'd like is an option to build a package reusing the state from a previous build. If a package I'm working on takes a minute or longer to build and I'm having some sort of difficulty, it's obnoxious to wait for that to complete again after every cycle. It could be near instantaneous if I could re-use a cached build, which is doable in Docker, Earthly, and other containerized build systems.
New French PO file for 'guix-manual' (version 1.2.0-pre3)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'guix-manual' has been submitted by the French team of translators. The file is available at: https://translationproject.org/latest/guix-manual/fr.po (We can arrange things so that in the future such files are automatically e-mailed to you when they arrive. Ask at the address below if you want this.) All other PO files for your package are available in: https://translationproject.org/latest/guix-manual/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: https://translationproject.org/domain/guix-manual.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
Re: Updating to latest Bioconductor release
Hi, >> > http://logs.guix.gnu.org/guix/2020-11-19.log#182349 > >> Right, so I shouldn't have pushed to "wip-r" in the first place. > > Well, I think it is a lack of synchronisation between all of 3; > especially with this work around via external GitHub upstream. Yeah, sorry. I didn’t realize wip-r was worked on by any one other than simon and myself. The commits are still there, they just don’t have a named pointer (= branch) to them any longer: https://git.savannah.gnu.org/cgit/guix.git/log/?id=8ed6a08a998d4abd58eb67c85699f38f87f76d05 If that’s the last commit (or if you have another one that was pushed) I can simply reset the branch pointer to it and then stay out of it :) > >> Perhaps I should do it "the old way" and base my patches on the master >> branch and send the gazillion patches to the mailing list. :) > > What Ricardo did previously (my rewrite of history on Nov. 10 on > GitHub, and then pushed by Ricardo to Savannah today), quoting their > word: "delete origin/wip-r, reset my local copy to zimoun/wip-r, > rebased on top of origin/master, and pushed origin/wip-r". Maybe you > could do the same. > > Or if you have the super power to do that: you can delete the branch > and re-push. Deleting the branch is “git push -d origin wip-r”. >> Then we can discuss each line of the commit messages separately before >> pushing to the master branch. > > Well, I do not know what Ricardo thinks, but personally I would prefer > first a wip-r branch then merge. It will avoid avoid annoyance of > possible broken packages, I mean we could detect them. Same. I prefer having a branch so ci.guix.gnu.org can build things and we can keep an eye on the fall-out (if any). Sorry again for making this harder than it should be! -- Ricardo
Re: Updating to latest Bioconductor release
Hi Roel, On Thu, 19 Nov 2020 at 20:03, Roel Janssen wrote: > > http://logs.guix.gnu.org/guix/2020-11-19.log#182349 > Right, so I shouldn't have pushed to "wip-r" in the first place. Well, I think it is a lack of synchronisation between all of 3; especially with this work around via external GitHub upstream. > Perhaps I should do it "the old way" and base my patches on the master > branch and send the gazillion patches to the mailing list. :) What Ricardo did previously (my rewrite of history on Nov. 10 on GitHub, and then pushed by Ricardo to Savannah today), quoting their word: "delete origin/wip-r, reset my local copy to zimoun/wip-r, rebased on top of origin/master, and pushed origin/wip-r". Maybe you could do the same. Or if you have the super power to do that: you can delete the branch and re-push. > Then we can discuss each line of the commit messages separately before > pushing to the master branch. Well, I do not know what Ricardo thinks, but personally I would prefer first a wip-r branch then merge. It will avoid avoid annoyance of possible broken packages, I mean we could detect them. All the best, simon
Re: Updating to latest Bioconductor release
Hi Simon, On Thu, 2020-11-19 at 18:27 +0100, zimoun wrote: > Hi Roel, > > Quick heads up of Ricardo from IRC. > > On Thu, 19 Nov 2020 at 17:25, Roel Janssen wrote: > > > Well, they got removed from Savannah. Now I get this when I try to > > push: > > http://logs.guix.gnu.org/guix/2020-11-19.log#182429 > > > $ git push -f origin wip-r > > Enumerating objects: 1599, done. > > Counting objects: 100% (1599/1599), done. > > Delta compression using up to 4 threads > > Compressing objects: 100% (362/362), done. > > Writing objects: 100% (1590/1590), 359.31 KiB | 14.37 MiB/s, done. > > Total 1590 (delta 1271), reused 1545 (delta 1228), pack-reused 0 > > remote: error: denying non-fast-forward refs/heads/wip-r (you > > should > > pull first) > > To git.savannah.gnu.org:/srv/git/guix.git > > ! [remote rejected] wip-r -> wip-r (non-fast-forward) > > error: failed to push some refs to > > 'git.savannah.gnu.org:/srv/git/guix.git' > > > > So, that's not going to work. > > Perhaps @Ricardo knows more about the setup of the "wip-r" branch. > > http://logs.guix.gnu.org/guix/2020-11-19.log#182349 > > Hope that helps, > Right, so I shouldn't have pushed to "wip-r" in the first place. Perhaps I should do it "the old way" and base my patches on the master branch and send the gazillion patches to the mailing list. :) Then we can discuss each line of the commit messages separately before pushing to the master branch. I can prepare it this evening and tomorrow evening. Kind regards, Roel Janssen
Re: Updating to latest Bioconductor release
Hi Roel, Quick heads up of Ricardo from IRC. On Thu, 19 Nov 2020 at 17:25, Roel Janssen wrote: > Well, they got removed from Savannah. Now I get this when I try to > push: http://logs.guix.gnu.org/guix/2020-11-19.log#182429 > $ git push -f origin wip-r > Enumerating objects: 1599, done. > Counting objects: 100% (1599/1599), done. > Delta compression using up to 4 threads > Compressing objects: 100% (362/362), done. > Writing objects: 100% (1590/1590), 359.31 KiB | 14.37 MiB/s, done. > Total 1590 (delta 1271), reused 1545 (delta 1228), pack-reused 0 > remote: error: denying non-fast-forward refs/heads/wip-r (you should > pull first) > To git.savannah.gnu.org:/srv/git/guix.git > ! [remote rejected] wip-r -> wip-r (non-fast-forward) > error: failed to push some refs to > 'git.savannah.gnu.org:/srv/git/guix.git' > > So, that's not going to work. > Perhaps @Ricardo knows more about the setup of the "wip-r" branch. http://logs.guix.gnu.org/guix/2020-11-19.log#182349 Hope that helps, All the best, simon
Re: guix depends on openldap?
Hi, On Thu, 19 Nov 2020 at 17:46, Julien Lepiller wrote: > >I am still confused. Why cmake-minimal needs all the protocols that > >curl supports? What I was expecting is that cmake-minimal depends on > >curl-minimal and that both packages are minimal. :-) > > >Because all in all, we end with a chubby Guix; which matters when > >packing it (Docker or system). > > I don't think it matters: no reference is retained from guix to openldap, so > it won't be added to the pack or docker image. It's only required at build > time. So each time I run "guix environment guix", I potentially download it. It is annoying when it is not possible to keep the store (for example, the storage for the store is small or some CI external automation build, etc.) or when the substitutes of dependencies are not available (burn CPU) or when the bandwidth is not cheap, etc. Maybe "packing it" is not the good terminology, but remove unnecessary dependencies matters. IMHO. All the best, simon
Re: guix depends on openldap?
Le 19 novembre 2020 10:33:10 GMT-05:00, zimoun a écrit : >Hi, > >On Thu, 19 Nov 2020 at 15:32, Efraim Flashner >wrote: > >> > > > --8<---cut >here---start->8--- >> > > > $ guix graph -t bag --path guix openldap >> > > > guix@1.1.0-29.4e3ed9b >> > > > guile-ssh@0.13.1 >> > > > libssh@0.9.5 >> > > > cmake-minimal@3.16.5 >> > > > curl@7.69.1 >> > > > openldap@2.4.49 >> > > > --8<---cut >here---end--->8--- >> > > > >> > > > Why does curl need an "Implementation of the Lightweight >Directory >> > > > Access Protocol"? >> > > >> > > I think a better question is can cmake-minimal depend on a new >> > > curl-minimal, or does it even need curl at all? >> > >> > Looks like I was wrong, there is a curl-minimal afterall >> > >> > guix size cmake-bootstrap 199.1 MiB >> > guix size cmake-minimal >> > with curl-minimal 198.7 MiB >> > guix size cmake-minimal 214.9 MiB >> >> HOWEVER, anything else that also depends on curl could depend on curl >> and on curl-minimal, which would be worse than what we have now. So >I'd >> leave cmake-minimal with curl and remove the extra bits outlined >below. > >I am still confused. Why cmake-minimal needs all the protocols that >curl supports? What I was expecting is that cmake-minimal depends on >curl-minimal and that both packages are minimal. :-) >Because all in all, we end with a chubby Guix; which matters when >packing it (Docker or system). I don't think it matters: no reference is retained from guix to openldap, so it won't be added to the pack or docker image. It's only required at build time. > >All the best, >simon
Re: Updating to latest Bioconductor release
Hi, > > To be concrete, the last commit on my branch is 9 days ago. And the > > last commit on Savannah wip-r is 30th Otc. > > Yeah, because mine got removed. Yeah, sorry. I think Ricardo pushed. The history is: - I pushed on Tue Nov 10 16:31:17 to GitHub rewriting the history - Ricardo pushed that on Nov 19 13:33:49 to Savannah, rewriting the history too. Sorry for the mess. And the annoyance. > Well, they got removed from Savannah. Now I get this when I try to > push: > $ git push -f origin wip-r [...] > remote: error: denying non-fast-forward refs/heads/wip-r (you should > pull first) > To git.savannah.gnu.org:/srv/git/guix.git > ! [remote rejected] wip-r -> wip-r (non-fast-forward) > error: failed to push some refs to > 'git.savannah.gnu.org:/srv/git/guix.git' > > So, that's not going to work. > Perhaps @Ricardo knows more about the setup of the "wip-r" branch. I do not know. Weird. All the best, simon
Re: Updating to latest Bioconductor release
On Thu, 2020-11-19 at 17:18 +0100, zimoun wrote: > On Thu, 19 Nov 2020 at 16:57, Roel Janssen wrote: > > > My bad, I jumped to a conclusion too quickly. :) > > No worries. :-) > > > > So, *something* removed my commits to the wip-r branch. Is it some > > kind > > of automation that syncs the Github and the Savannah branches? > > Which upstream? > I have no access on Savannah. And I think you could should there. > My wip-r branch on my personal GitHub account, no automation. > Ricardo > did couple of days ago: fetch my branch and push it to Savannah. > Then > they reported a tiny mistake that I corrected on my branch, by > rewriting the history since it is WIP. It was before you have > started > to work on, I guess. > > To be concrete, the last commit on my branch is 9 days ago. And the > last commit on Savannah wip-r is 30th Otc. Yeah, because mine got removed. > > The good news is that in my local checkout I've fixed the build > > problem > > with r-rhdf5lib, so I should be able to build the remaining > > packages > > this evening. > > Really cool! Thank you. > > > > I am hesitant to push it to the "wip-r" branch, because it seems > > pointless. :) So where can I push my updates to? > > Please push your changes to wip-r on Savannah, rewriting the history > is fine with me. Then Cuirass will rebuild everything, check. Then > we can merge to master. Well, they got removed from Savannah. Now I get this when I try to push: $ git push -f origin wip-r Enumerating objects: 1599, done. Counting objects: 100% (1599/1599), done. Delta compression using up to 4 threads Compressing objects: 100% (362/362), done. Writing objects: 100% (1590/1590), 359.31 KiB | 14.37 MiB/s, done. Total 1590 (delta 1271), reused 1545 (delta 1228), pack-reused 0 remote: error: denying non-fast-forward refs/heads/wip-r (you should pull first) To git.savannah.gnu.org:/srv/git/guix.git ! [remote rejected] wip-r -> wip-r (non-fast-forward) error: failed to push some refs to 'git.savannah.gnu.org:/srv/git/guix.git' So, that's not going to work. Perhaps @Ricardo knows more about the setup of the "wip-r" branch. Kind regards, Roel Janssen
Re: Updating to latest Bioconductor release
On Thu, 19 Nov 2020 at 16:57, Roel Janssen wrote: > My bad, I jumped to a conclusion too quickly. :) No worries. :-) > So, *something* removed my commits to the wip-r branch. Is it some kind > of automation that syncs the Github and the Savannah branches? Which upstream? I have no access on Savannah. And I think you could should there. My wip-r branch on my personal GitHub account, no automation. Ricardo did couple of days ago: fetch my branch and push it to Savannah. Then they reported a tiny mistake that I corrected on my branch, by rewriting the history since it is WIP. It was before you have started to work on, I guess. To be concrete, the last commit on my branch is 9 days ago. And the last commit on Savannah wip-r is 30th Otc. > The good news is that in my local checkout I've fixed the build problem > with r-rhdf5lib, so I should be able to build the remaining packages > this evening. Really cool! Thank you. > I am hesitant to push it to the "wip-r" branch, because it seems > pointless. :) So where can I push my updates to? Please push your changes to wip-r on Savannah, rewriting the history is fine with me. Then Cuirass will rebuild everything, check. Then we can merge to master. All the best, simon
Re: guix depends on openldap?
Hi Efraim,
On Thu, 19 Nov 2020 15:56:34 +0200
Efraim Flashner wrote:
> I think a better question is can cmake-minimal depend on a new
> curl-minimal, or does it even need curl at all?
In the course of debugging the "32 bit ARM on 64 bit host can't read
directories"
problem ("json-c") and starting to fix it, I had also asked myself that
question.
I've researched back then why cmake needs curl in the first place and it turned
out it is in order to contact a CI dashboard server when tests run in ctest.
They do not support removing the library, but they do support disabling the
(or setting another) dashboard server to contact.
pgpRdGWAJmRS0.pgp
Description: OpenPGP digital signature
Re: Updating to latest Bioconductor release
On Thu, 2020-11-19 at 16:36 +0100, zimoun wrote: > Hi, > > On Thu, 19 Nov 2020 at 16:31, Roel Janssen wrote: > > > I fixed the build of r-rhfd5lib. > > Cool! > > > It seems, however, that you removed all of my changes to the wip-r > > branch. Why? > > Who is "you"? ;-) > Personally, I did nothing; or I have nights that I am not aware. :-) > (Even, I do not have commit access.) > So if I did something wrong, I am sorry and could you point me to > what? > My bad, I jumped to a conclusion too quickly. :) So, *something* removed my commits to the wip-r branch. Is it some kind of automation that syncs the Github and the Savannah branches? The good news is that in my local checkout I've fixed the build problem with r-rhdf5lib, so I should be able to build the remaining packages this evening. I am hesitant to push it to the "wip-r" branch, because it seems pointless. :) So where can I push my updates to? Kind regards, Roel Janssen
Re: Updating to latest Bioconductor release
Hi, On Thu, 19 Nov 2020 at 16:31, Roel Janssen wrote: > I fixed the build of r-rhfd5lib. Cool! > It seems, however, that you removed all of my changes to the wip-r > branch. Why? Who is "you"? ;-) Personally, I did nothing; or I have nights that I am not aware. :-) (Even, I do not have commit access.) So if I did something wrong, I am sorry and could you point me to what? All the best, simon
Re: guix depends on openldap?
Hi, On Thu, 19 Nov 2020 at 15:32, Efraim Flashner wrote: > > > > --8<---cut here---start->8--- > > > > $ guix graph -t bag --path guix openldap > > > > guix@1.1.0-29.4e3ed9b > > > > guile-ssh@0.13.1 > > > > libssh@0.9.5 > > > > cmake-minimal@3.16.5 > > > > curl@7.69.1 > > > > openldap@2.4.49 > > > > --8<---cut here---end--->8--- > > > > > > > > Why does curl need an "Implementation of the Lightweight Directory > > > > Access Protocol"? > > > > > > I think a better question is can cmake-minimal depend on a new > > > curl-minimal, or does it even need curl at all? > > > > Looks like I was wrong, there is a curl-minimal afterall > > > > guix size cmake-bootstrap 199.1 MiB > > guix size cmake-minimal > > with curl-minimal 198.7 MiB > > guix size cmake-minimal 214.9 MiB > > HOWEVER, anything else that also depends on curl could depend on curl > and on curl-minimal, which would be worse than what we have now. So I'd > leave cmake-minimal with curl and remove the extra bits outlined below. I am still confused. Why cmake-minimal needs all the protocols that curl supports? What I was expecting is that cmake-minimal depends on curl-minimal and that both packages are minimal. :-) Because all in all, we end with a chubby Guix; which matters when packing it (Docker or system). All the best, simon
Re: Updating to latest Bioconductor release
On Wed, 2020-11-18 at 17:59 +0100, zimoun wrote: > On Wed, 18 Nov 2020 at 17:33, Roel Janssen wrote: > > > Okay. Then I'll look into it. I currently have only these left as > > changed in my tree: > > - r-atacseqqc: Needs r-rhdf5lib. > > - r-cytoml: Needs r-rhdf5lib. > > - r-scater: Needs r-rhdf5lib. > > - r-scuttle (new package for r-scran): Needs r-rhdf5lib. > > - r-scran: Needs r-scuttle. > > Now it rings a bell and I think you missed this email (and I forgot > to > point you, sorry): > > # NOT DONE > r-rhdf5lib: consider removing this native input: hdf5-source > r-rhdf5lib: consider removing this propagated input: hdf5 > > https://lists.gnu.org/archive/html/guix-devel/2020-11/msg00047.html > I fixed the build of r-rhfd5lib. It seems, however, that you removed all of my changes to the wip-r branch. Why? Kind regards, Roel Janssen
Re: guix depends on openldap?
On Thu, Nov 19, 2020 at 04:18:32PM +0200, Efraim Flashner wrote: > On Thu, Nov 19, 2020 at 03:56:34PM +0200, Efraim Flashner wrote: > > On Thu, Nov 19, 2020 at 02:41:51PM +0100, zimoun wrote: > > > Dear, > > > > > > This morning I garbage-collected some old items and pulled. Well, I > > > was then surprised that "guix environment guix" fetches 'openldap'. > > > Is it expected? > > > > > > --8<---cut here---start->8--- > > > $ guix graph -t bag --path guix openldap > > > guix@1.1.0-29.4e3ed9b > > > guile-ssh@0.13.1 > > > libssh@0.9.5 > > > cmake-minimal@3.16.5 > > > curl@7.69.1 > > > openldap@2.4.49 > > > --8<---cut here---end--->8--- > > > > > > Why does curl need an "Implementation of the Lightweight Directory > > > Access Protocol"? > > > > I think a better question is can cmake-minimal depend on a new > > curl-minimal, or does it even need curl at all? > > > > Looks like I was wrong, there is a curl-minimal afterall > > guix size cmake-bootstrap 199.1 MiB > guix size cmake-minimal > with curl-minimal 198.7 MiB > guix size cmake-minimal 214.9 MiB HOWEVER, anything else that also depends on curl could depend on curl and on curl-minimal, which would be worse than what we have now. So I'd leave cmake-minimal with curl and remove the extra bits outlined below. > > (ins)efraim@bayfront ~/workspace/guix$ du -sch > /gnu/store/rjplfbrlais3gs9p0667d2l7x3d2q44j-cmake-minimal-3.16.5/* > 27M /gnu/store/rjplfbrlais3gs9p0667d2l7x3d2q44j-cmake-minimal-3.16.5/bin > 15M /gnu/store/rjplfbrlais3gs9p0667d2l7x3d2q44j-cmake-minimal-3.16.5/share > 42M total > (ins)efraim@bayfront ~/workspace/guix$ du -sch > /gnu/store/rjplfbrlais3gs9p0667d2l7x3d2q44j-cmake-minimal-3.16.5/bin/* > 6.2M > /gnu/store/rjplfbrlais3gs9p0667d2l7x3d2q44j-cmake-minimal-3.16.5/bin/ccmake > 6.6M > /gnu/store/rjplfbrlais3gs9p0667d2l7x3d2q44j-cmake-minimal-3.16.5/bin/cmake > 6.7M > /gnu/store/rjplfbrlais3gs9p0667d2l7x3d2q44j-cmake-minimal-3.16.5/bin/cpack > 7.7M > /gnu/store/rjplfbrlais3gs9p0667d2l7x3d2q44j-cmake-minimal-3.16.5/bin/ctest > 27M total > (ins)efraim@bayfront ~/workspace/guix$ du -sch > /gnu/store/rjplfbrlais3gs9p0667d2l7x3d2q44j-cmake-minimal-3.16.5/share/* > 8.0K > /gnu/store/rjplfbrlais3gs9p0667d2l7x3d2q44j-cmake-minimal-3.16.5/share/aclocal > 15M > /gnu/store/rjplfbrlais3gs9p0667d2l7x3d2q44j-cmake-minimal-3.16.5/share/cmake-3.16 > 68K > /gnu/store/rjplfbrlais3gs9p0667d2l7x3d2q44j-cmake-minimal-3.16.5/share/doc > 15M total > > We could probably remove ccmake and the share/cmake- and drop > the size from 42M to about 21M. > -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: guix depends on openldap?
On Thu, Nov 19, 2020 at 03:56:34PM +0200, Efraim Flashner wrote: > On Thu, Nov 19, 2020 at 02:41:51PM +0100, zimoun wrote: > > Dear, > > > > This morning I garbage-collected some old items and pulled. Well, I > > was then surprised that "guix environment guix" fetches 'openldap'. > > Is it expected? > > > > --8<---cut here---start->8--- > > $ guix graph -t bag --path guix openldap > > guix@1.1.0-29.4e3ed9b > > guile-ssh@0.13.1 > > libssh@0.9.5 > > cmake-minimal@3.16.5 > > curl@7.69.1 > > openldap@2.4.49 > > --8<---cut here---end--->8--- > > > > Why does curl need an "Implementation of the Lightweight Directory > > Access Protocol"? > > I think a better question is can cmake-minimal depend on a new > curl-minimal, or does it even need curl at all? > Looks like I was wrong, there is a curl-minimal afterall guix size cmake-bootstrap 199.1 MiB guix size cmake-minimal with curl-minimal 198.7 MiB guix size cmake-minimal 214.9 MiB (ins)efraim@bayfront ~/workspace/guix$ du -sch /gnu/store/rjplfbrlais3gs9p0667d2l7x3d2q44j-cmake-minimal-3.16.5/* 27M /gnu/store/rjplfbrlais3gs9p0667d2l7x3d2q44j-cmake-minimal-3.16.5/bin 15M /gnu/store/rjplfbrlais3gs9p0667d2l7x3d2q44j-cmake-minimal-3.16.5/share 42M total (ins)efraim@bayfront ~/workspace/guix$ du -sch /gnu/store/rjplfbrlais3gs9p0667d2l7x3d2q44j-cmake-minimal-3.16.5/bin/* 6.2M /gnu/store/rjplfbrlais3gs9p0667d2l7x3d2q44j-cmake-minimal-3.16.5/bin/ccmake 6.6M /gnu/store/rjplfbrlais3gs9p0667d2l7x3d2q44j-cmake-minimal-3.16.5/bin/cmake 6.7M /gnu/store/rjplfbrlais3gs9p0667d2l7x3d2q44j-cmake-minimal-3.16.5/bin/cpack 7.7M /gnu/store/rjplfbrlais3gs9p0667d2l7x3d2q44j-cmake-minimal-3.16.5/bin/ctest 27M total (ins)efraim@bayfront ~/workspace/guix$ du -sch /gnu/store/rjplfbrlais3gs9p0667d2l7x3d2q44j-cmake-minimal-3.16.5/share/* 8.0K /gnu/store/rjplfbrlais3gs9p0667d2l7x3d2q44j-cmake-minimal-3.16.5/share/aclocal 15M /gnu/store/rjplfbrlais3gs9p0667d2l7x3d2q44j-cmake-minimal-3.16.5/share/cmake-3.16 68K /gnu/store/rjplfbrlais3gs9p0667d2l7x3d2q44j-cmake-minimal-3.16.5/share/doc 15M total We could probably remove ccmake and the share/cmake- and drop the size from 42M to about 21M. -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: guix depends on openldap?
On Thu, Nov 19, 2020 at 02:41:51PM +0100, zimoun wrote: > Dear, > > This morning I garbage-collected some old items and pulled. Well, I > was then surprised that "guix environment guix" fetches 'openldap'. > Is it expected? > > --8<---cut here---start->8--- > $ guix graph -t bag --path guix openldap > guix@1.1.0-29.4e3ed9b > guile-ssh@0.13.1 > libssh@0.9.5 > cmake-minimal@3.16.5 > curl@7.69.1 > openldap@2.4.49 > --8<---cut here---end--->8--- > > Why does curl need an "Implementation of the Lightweight Directory > Access Protocol"? I think a better question is can cmake-minimal depend on a new curl-minimal, or does it even need curl at all? -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: A plan for parameterized packages
On Sun, 15 Nov 2020 22:24:29 +0100 raingloom wrote: > Alpine already achieves an incredibly tiny install size by splitting > packages into many outputs. We could and should do the same. > As far as I know, they do not have parameterized packages. That also depends on how far you want to go. Last time I looked into how LibreCMC/OpenWRT did that, they had much more optimization than that. If I recall well, they use at least: - sstrip to strip binaries as much as they could. sstrip produces smaller binaries than with strip. - compilation flags like -Os - a read-only compressed filesystem with an overlay to store the changes The issue is that despite all that, the size of the images tend to increase too rapidly over time[1]. If we manage to shrink Guix enough, it might be possible to use it on way more devices, including RYF compliant devices or potentially certifiable devices: - The Talos II BMC has 32M according to both the wiki[2] and the image sizes[4]. Its architecture is ARM. So once we have the PPC64 architecture working, it would be great to be able to run Guix both in the BMC and on the PowerPC CPU. That BMC is also available on other mainboards like the D16 which is supported by Libreboot, but the flash size is probably even smaller there. - Many WiFi access point have very few flash space. It can boils down to as low as 16M for LibreCMC/OpenWRT compatible devices, or even 8M for older devices. However they typically use the MIPS architecture which isn't supported yet in Guix. - There is a GNU/Linux distribution[6] that runs inside the flash chip where Libreboot or Coreboot typically runs. The goal is to enable more flexible and/or secure booting by using GNU/Linux to boot GNU/Linux. Here too the flash chip of computers supported by Libreboot can be quite small, like 8M for Thinkpads with GM45 chipsets. In some case it might be possible to increase the flash chip size (sometimes you don't need soldering for that), but at least with x86 mainboards, the chipset has limits on the size of the flash chip that it can see. And the size cannot be increased that much: The biggest flash chip that flashrom supports is 256M. References: --- [1]https://openwrt.org/supported_devices/864_warning [2]The wiki[3] mention a MX25L25635F/MX25L25645E/MX25L25665E flash chip which is 32M according to flashrom -L [3]https://wiki.raptorcs.com/wiki/Debricking_the_BMC#Flash_new_BMC_firmware_via_serial_port_.28Open_Source_Method.29 [4]Once uncompressed the image[5] size (for installation through the shell) is 32M. [5]https://wiki.raptorcs.com/wiki/File:Talos-ii-openbmc-v2.00-bundle.tar [6]https://github.com/osresearch/heads/ [7]https://github.com/osresearch/heads/tree/master/config Denis. pgpoPCdagb2In.pgp Description: OpenPGP digital signature
guix depends on openldap?
Dear, This morning I garbage-collected some old items and pulled. Well, I was then surprised that "guix environment guix" fetches 'openldap'. Is it expected? --8<---cut here---start->8--- $ guix graph -t bag --path guix openldap guix@1.1.0-29.4e3ed9b guile-ssh@0.13.1 libssh@0.9.5 cmake-minimal@3.16.5 curl@7.69.1 openldap@2.4.49 --8<---cut here---end--->8--- Why does curl need an "Implementation of the Lightweight Directory Access Protocol"? All the best, simon
Re: Release: Docker Image? DockerHub? skopeo?
Hi zimoun, On Thu, 19 Nov 2020 10:21:16 +0100 zimoun wrote: > Let’s postpone this Docker image work and start a new fresh thread once > v1.2.0 is published and the goal to have something for v1.3.0, well > that’s my point of view. After Ryan Prior's E-Mail I'm pretty sure my workaround of creating /tmp, /etc/passwd, /etc/group etc is what Docker actually expects one to do. So we can just create those--either at runtime, or maybe even have guix system docker-image do it at build time (if it doesn't already). I have no opinion on when we should do that (at this release or the next one), except to state that I am certain that it works (and pretty easily), because guix-on-docker does that already and guix works just fine there. That still leaves to explain how to prevent Docker from keeping older layers when it doesn't need to. In guix-on-docker I have a Dockerfile like this FROM alpine:3.12 AS bootstrap-guix-on-alpine [...] FROM scratch AS guix-on-docker COPY --from=bootstrap-guix-on-alpine /etc/guix /etc/guix COPY --from=bootstrap-guix-on-alpine /var/guix /var/guix COPY --from=bootstrap-guix-on-alpine /gnu /gnu COPY --from=bootstrap-guix-on-alpine /usr/local /usr/local COPY --from=bootstrap-guix-on-alpine /root/.config/guix /root/.config/guix ADD set-mtimes.scm / ADD etc/passwd /etc ADD etc/group /etc ADD etc/services /etc ADD with-guix-daemon.scm / RUN ["/usr/local/bin/guix", "repl", "/set-mtimes.scm"] in order to prevent Docker from keeping older layers[1]. The "set-times.scm" invocation there is in order to fix the timestamps. "COPY --from=" does not preserve timestamps. Then guile is very annoyed because it can't use any of the ".go" files--because they are older than the respective ".scm" files. Using set-times.scm means it will create yet another layer where the only difference is the timestamps--so it doubles the size of the resulting image. But then it works. [1] https://docs.docker.com/develop/develop-images/multistage-build/ pgpRHSyXoKbMP.pgp Description: OpenPGP digital signature
Re: Release: Docker Image? DockerHub? skopeo?
Hi Danny, Thank you for the explanations. Make sense. :-) On Tue, 17 Nov 2020 at 20:23, Danny Milosavljevic wrote: > No, I don't use docker that much--and when I do, it's to run simple images > others have created. So I just really don't know how this is supposed to > be set up. I mean there has to be a way to set this up--that is one of the > first things anyone would need--shared /tmp, /etc/passwd, /etc/group, > /etc/services and so on. The parts that are composed together by Docker have > to negotiate a common version of those, right? I don’t use Docker that much neither–and when I do it’s to create somehow Docker images via “guix pack -f docker” and run somehow this simple image. Well, I have never read cover-to-cover the Docker doc, for example. :-) > I hope that others will chime in explaining what the standard way to do this > is. The workaround above *does* work, though (and is the wrong thing to do). Let’s postpone this Docker image work and start a new fresh thread once v1.2.0 is published and the goal to have something for v1.3.0, well that’s my point of view. Cheers, simon
Re: GNU Guix 1.2.0rc2 available for testing!
Hi! zimoun writes: > +`--with-c-toolchain`, and `--without-tests`. Consider this example: Oh, I didn't notice we had a --without-tests now, good to know! I remember asking about such an option a while back, but this was refused on the ground that it would encourage untested builds if I recall correctly (I can look up the email again if you insist ;p). So what's the rationale behind this change of position? -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
