Re: Guix-devel Digest, Vol 109, Issue 56
On 22-07-2022 19:12, kiasoc5 wrote: We could have packages recommend other packages to make this discovery easier for users, like Arch's opt-depends. This sounds like my previous proposal to me: Alternatively, packages could have an additional set of inputs (development-inputs?) for this use case, only added for "guix shell -D" and "guix environment", though then the build environment and "guix shell -D the-package" would diverge further. except it has a more precise semantics than Arch's, or did you have something different in mind? Greetings, Maxime. OpenPGP_0x49E3EE22191725EE.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Guix-devel Digest, Vol 109, Issue 56
Date: Thu, 21 Jul 2022 18:34:58 +0200 From: zimoun To: Hartmut Goebel , Guix-devel Subject: Re: native-inputs: Go for completeness or minimalism? Message-ID: <86o7xi4e6l@gmail.com> Content-Type: text/plain; charset=utf-8 Hi simon, > On Wed, 20 Jul 2022 at 10:33, Hartmut Goebel > wrote: > > > Personally I tend to minimal. > > Me too. Being minimal is better on all aspects, IMHO. > > The only drawback is indeed “guix shell -D”. But, people developing > can add the missing or extra packages. To me, Guix provides the > minimal environment for building and running one package. > > Otherwise, we could imagine to create two packages. > > However, there is no consensus about this “minimalism”. For instance, > some packages have multi-outputs which implies that “guix shell -D” is > not minimal. > We could have packages recommend other packages to make this discovery easier for users, like Arch's opt-depends. > Cheers, > simon
Re: Is Guix suitable for large monorepos?
jgart writes: > Is Guix suitable for large monorepos? I use Guix against a large mono-repo, and there are a few difficulties. I should mention that I am not using Guix in the typical fashion with fixed commits (packages are pointed at HEAD and I don't use checksums). For my purposes, it's useful for me to build HEAD, although sometimes I use transformation options if I'm interested in a specific branch or commit. I've defined a package for the entire repo and then individual packages for the constituent projects which inherit from the repo package. For new commits: - Updating the source take a long time. - Indexing the entire repo takes a long time. - Copying over the entire tree to the build directory is unnecessary and takes time. Sometimes I want to build a local change I haven't committed anywhere, so I use the --with-source option. The problems are the same, but they're exacerbated. A happy medium I've landed on is to build some binaries outside of Guix and then use packages that are defined in terms of the binaries. These packages use patchelf to get everything linked correctly. This allows me to reify these packages into Guix while keeping the standard workflow from a programming language. I've also considered a phase that, after checkout, deletes all files not relevant to the project to lessen the burden of copying things over for building. So, in my opinion, these issues are not really Guix's fault, and it does a pretty good job all things considered. I think Guix used in a CI/CD pipeline (which I guess means cuirass) would handle mono-repositories wonderfully and do exactly what I want: reproducible, verifiable, builds. Guix as a development tool in these situations is still useful, but has some things that make it a little difficult to work with. Maybe someone has some ideas to improve things? -- Katherine
Re: Translating news on weblate?
Hi Julien, > I was thinking we could have our news file translated at weblate, which > would help having more people translate it. Attached is a script that > is able to generate a pot file from the news.scm file and a translated > news.scm file from the existing news.scm and a directory that contains > the po files and a LINGUAS file. Would be nice if we could translate at Weblate. Weblate allows people who have never contributed to Guix before to do so. We do not have any Japanese entries yet, but we would like to cooperate as much as possible. Thanks, -- Taiju
Re: Is Guix suitable for large monorepos?
Am Freitag, dem 22.07.2022 um 11:14 +0200 schrieb Maxime Devos: > On 22-07-2022 08:58, Liliana Marie Prikler wrote: > > > 15:10 "An engineering organization is not a bottom-up kind of > > thing" > > (X) Doubt. > > 15:18 "In a well functioning engineering team, priorities and > > decisions > > and effort allocation flow top-down" > > (X) Doubt. > > 15:24 "Some sort of top-down organization is required" > > (X) Doubt. > > It's a bit of a stretch, but in a sense Guix is a bit top down, if > you count Guix itself (and the reviewers, committeres, etc. as a > while) as 'top' and individual patch submitters as 'down'. OTOH with > Guix doesn't make decisions on what individual people should work on, > only on the rules that the results should follow and there is no > effort allocation, so possibly this is not the kind of 'top-down' > that the video was referring to. To expand on this a little, there are about two important layers here: committers and non-committers. Within the review process both are the same, except for the fact that only committers can actually push changes to the repo (signing with their name and key). Also, thanks to channels, packages can really flow from the bottom up – someone who wants to submit a package can first check it locally, and even while the review is ongoing already use it on their machine. Now there are maintainers, who are even more powerful than committers and recently also teams, but for better or worse neither of those matter too much in your day to day operations. In the context of the monorepo debate, I think it is also important to distinguish between Guix, the package manager, and Guix, the channel. Governance decisions regarding the latter can largely be ignored if you're working for MonoRepoCorp™. Cheers
Re: Is Guix suitable for large monorepos?
On 22-07-2022 08:58, Liliana Marie Prikler wrote: 13:43 "... if you are scrupulous about running tests ..." Are you really going to run all the tests from hex0 to node whenever you flip a bit? Chances are no. Also, with some exceptions (e.g. emacs packages and texlive), tests are run by default in Guix -- you'll have to disable them explicitly for them not to be run, and if you try to submit it without tests, reviewers will ask why. Greetings, Maxime. OpenPGP_0x49E3EE22191725EE.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: emacs-flymake-collection fails at install phase
On Wed, Jul 13, 2022 at 09:33:43PM -0500, jgart wrote:
> Hi Guixers,
>
> I'm trying to package this emacs package but it fails at the install phase:
> https://github.com/mohkale/flymake-collection
>
> ```
> starting phase `make-autoloads'
> Debugger entered--Lisp error: (file-missing "Opening directory" "No such file
> or directory" "/gnu/store/p5vsnlhrqph2sl3r7q8c0h970rp8hv0q-emacs-...")
> directory-files("/gnu/store/p5vsnlhrqph2sl3r7q8c0h970rp8hv0q-emacs-..." t
> "\\`[^=.].*\\(\\.el\\(?:\\.gz\\)?\\)\\'")
> #f(compiled-function (d) # 0x4123d5312041b5e>)("/gnu/store/p5vsnlhrqph2sl3r7q8c0h970rp8hv0q-emacs-...")
> mapcar(#f(compiled-function (d) #)
> ("/gnu/store/p5vsnlhrqph2sl3r7q8c0h970rp8hv0q-emacs-..."))
>
> make-directory-autoloads(("/gnu/store/p5vsnlhrqph2sl3r7q8c0h970rp8hv0q-emacs-...")
> "/gnu/store/p5vsnlhrqph2sl3r7q8c0h970rp8hv0q-emacs-...")
>
> update-directory-autoloads("/gnu/store/p5vsnlhrqph2sl3r7q8c0h970rp8hv0q-emacs-...")
> (let ((backup-inhibited t) (generated-autoload-file
> "/gnu/store/p5vsnlhrqph2sl3r7q8c0h970rp8hv0q-emacs-..."))
> (update-directory-autoloads
> "/gnu/store/p5vsnlhrqph2sl3r7q8c0h970rp8hv0q-emacs-..."))
> eval((let ((backup-inhibited t) (generated-autoload-file
> "/gnu/store/p5vsnlhrqph2sl3r7q8c0h970rp8hv0q-emacs-..."))
> (update-directory-autoloads
> "/gnu/store/p5vsnlhrqph2sl3r7q8c0h970rp8hv0q-emacs-...")) nil)
> eval((eval '(let ((backup-inhibited t) (generated-autoload-file
> "/gnu/store/p5vsnlhrqph2sl3r7q8c0h970rp8hv0q-emacs-..."))
> (update-directory-autoloads
> "/gnu/store/p5vsnlhrqph2sl3r7q8c0h970rp8hv0q-emacs-...")) nil) t)
> command-line-1(("--eval=(eval '(let ((backup-inhibited t) (generate..."))
> command-line()
> normal-top-level()
>
> error: in phase 'make-autoloads': uncaught exception:
> %exception #< program:
> "/gnu/store/v2lzdj04qgl8419zca74s5ligkwbinaw-emacs-minimal-28.1/bin/emacs"
> arguments: ("--quick" "--batch" "--eval=(eval '(let ((backup-inhibited t)
> (generated-autoload-file
> \"/gnu/store/p5vsnlhrqph2sl3r7q8c0h970rp8hv0q-emacs-flymake-collection-2.0.0-0.cd25745/share/emacs/site-lisp/flymake-collection-2.0.0-0.cd25745/flymake-collection-autoloads.el\"))
> (update-directory-autoloads
> \"/gnu/store/p5vsnlhrqph2sl3r7q8c0h970rp8hv0q-emacs-flymake-collection-2.0.0-0.cd25745/share/emacs/site-lisp/flymake-collection-2.0.0-0.cd25745\"))
> nil)") exit-status: 255 term-signal: #f stop-signal: #f>
> phase `make-autoloads' failed after 0.1 seconds
> command
> "/gnu/store/v2lzdj04qgl8419zca74s5ligkwbinaw-emacs-minimal-28.1/bin/emacs"
> "--quick" "--batch" "--eval=(eval '(let ((backup-inhibited t)
> (generated-autoload-file
> \"/gnu/store/p5vsnlhrqph2sl3r7q8c0h970rp8hv0q-emacs-flymake-collection-2.0.0-0.cd25745/share/emacs/site-lisp/flymake-collection-2.0.0-0.cd25745/flymake-collection-autoloads.el\"))
> (update-directory-autoloads
> \"/gnu/store/p5vsnlhrqph2sl3r7q8c0h970rp8hv0q-emacs-flymake-collection-2.0.0-0.cd25745/share/emacs/site-lisp/flymake-collection-2.0.0-0.cd25745\"))
> nil)" failed with status 255
> note: keeping build directory
> `/tmp/guix-build-emacs-flymake-collection-2.0.0-0.cd25745.drv-0'
> builder for
> `/gnu/store/w3jmmgw1z6ggqfg0pbjjwxi5givhwxvy-emacs-flymake-collection-2.0.0-0.cd25745.drv'
> failed with exit code 1
> build of
> /gnu/store/w3jmmgw1z6ggqfg0pbjjwxi5givhwxvy-emacs-flymake-collection-2.0.0-0.cd25745.drv
> failed
> View build log at
> '/var/log/guix/drvs/w3/jmmgw1z6ggqfg0pbjjwxi5givhwxvy-emacs-flymake-collection-2.0.0-0.cd25745.drv.bz2'.
> guix build: error: build of
> `/gnu/store/w3jmmgw1z6ggqfg0pbjjwxi5givhwxvy-emacs-flymake-collection-2.0.0-0.cd25745.drv'
> failed
> ```
>
> -- guix package
>
> ```
> (define-public emacs-flymake-collection
> (let ((commit "cd2574574bda1f3d94007cdc3b7e0f8007d69716")
> (revision "0"))
> (package
> (name "emacs-flymake-collection")
> (version (git-version "2.0.0" revision commit))
> (source
>(origin
> (method git-fetch)
> (uri
> (git-reference
>(url "https://github.com/mohkale/flymake-collection;)
>(commit commit)))
> (file-name (git-file-name name version))
> (sha256
> (base32 "0js7y1ph6r1xgaziggbx7v8jimxyz29fvlzgaq5rbd6ni332jrn5"
> (build-system emacs-build-system)
> (home-page "https://github.com/mohkale/flymake-collection;)
> (synopsis "")
> (description "")
> (license #f
> ```
Error 255 is "file missing". Normally it means that it tries to call a
program that doesn't exist, but I'm guessing that the 'install phase
isn't actually installing the package, so 'make-autoloads says that the
directory (is it %output?) doesn't exist.
--
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: glibc-2.33 fails to build on POWER9
On Thu, Jul 14, 2022 at 06:06:51PM +0200, Tobias Platen wrote: > I tried to build glibc-2.33 on my Talos II (no cross compile here), > it fails because the compiler is likely outdated. > > checking if the target machine is at least POWER8... yes > checking if the compiler supports -mno-gnu-attribute... yes > checking if gcc compiles signbit with 128-bit floating point type... > yes > checking if gcc compiles with -mabi=ieeelongdouble and -mlong-double- > 128... no > checking for objcopy... objcopy > checking version of objcopy... 2.37, ok > configure: error: *** The compiler must support -mabi=ieeelongdouble > and -mlongdouble simultaneously. > > guix --version shows > guix (GNU Guix) 7c9ad54b0616112c7eea6dd02379616aef206490 > Copyright (C) 2022 the Guix authors (ins)[efraim@pbp guix]$ git show 7c9ad54b0616112c7eea6dd02379616aef206490 commit 7c9ad54b0616112c7eea6dd02379616aef206490 Author: Efraim Flashner Date: Sun Feb 6 10:09:14 2022 +0200 Can you try with a more recent version of Guix? Is this for building glibc@2.33 or as part of the packages in commencement.scm? -- 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: Is Guix suitable for large monorepos?
On 22-07-2022 08:58, Liliana Marie Prikler wrote: 15:10 "An engineering organization is not a bottom-up kind of thing" (X) Doubt. 15:18 "In a well functioning engineering team, priorities and decisions and effort allocation flow top-down" (X) Doubt. 15:24 "Some sort of top-down organization is required" (X) Doubt. It's a bit of a stretch, but in a sense Guix is a bit top down, if you count Guix itself (and the reviewers, committeres, etc. as a while) as 'top' and individual patch submitters as 'down'. OTOH with Guix doesn't make decisions on what individual people should work on, only on the rules that the results should follow and there is no effort allocation, so possibly this is not the kind of 'top-down' that the video was referring to. Greetings, Maxime. OpenPGP_0x49E3EE22191725EE.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: lagrange install japanese fonts and other fonts?
Am Mittwoch, dem 20.07.2022 um 00:35 -0500 schrieb jgart: > Just wanted to add a packaging TODO for lagrange for when we get > around to it: > > https://github.com/skyjake/lagrange/issues/526 > > Should I send issues like this to guix-patc...@gnu.org instead? This is not an issue in lagrange. Rather, I'd be surprised if you managed to display Kanji in *any* application without CJK fonts installed.
Re: Is Guix suitable for large monorepos?
Am Donnerstag, dem 21.07.2022 um 23:55 -0500 schrieb jgart: > Is Guix suitable for large monorepos? > > How does Guix compare to pants in the python arena? > > https://yewtu.be/watch?v=p4stnR1gCR4 > https://www.pantsbuild.org/ In my humble opinion, Guix is somewhat antithetical to monorepos. At the very least, the repo containing all your guix recipes is probably distinct from the (many) repo(s) you pull your code form. That said, Guix can handle monorepos in multiple ways. You can split the monorepo into its constituent parts and build the individual packages. Examples, where this is "natively" supported include GStreamer and clang, which also ship as separate tarballs. An example, where we do this from hand would be TeXLive. You can also build the entire monorepo if your monorepo supports that (just because you have a monorepo doesn't mean that it actually builds). Again, TeXLive is an example where we can do that. Some comments to the video you've posted. 10:33 "How do you know who all the consumers of repo A even are?" Well, if you have a working package manager (like Guix), you can recursively check dependencies, e.g. using `guix refresh -l A'. 10:53 "How do I test the change?" `guix build' already does the entire build for you. Now granted, that takes longer than checking the repo out yourself and running configure, make, etc., but it'll work. 11:34 "Do the whole thing over again." Well, Guix can help that with CI, but more importantly, there is nothing you can do to not do the whole thing over again, even in a monorepo. No matter what Benjy claims to the contrary, he's either wrong or (intentionally or otherwise) misrepresenting the cascade. 12:03 "This isn't very nice." That's why you write ChangeLogs and guidelines for changing stuff? 13:36 "Breakages are immediately visible." Breakages in Guix are visible once you (or CI) builds all the dependant packages. 13:43 "... if you are scrupulous about running tests ..." Are you really going to run all the tests from hex0 to node whenever you flip a bit? Chances are no. 13:55 "Codebase architecture enforces good teamwork and responsibility" Probably maybe. But rather than having "good teamwork" (a social problem) and "responsibility" (a social problem) forced upon my team, I'd rather have the team arrive at good teamwork without a monorepo overlord. 14:09 "Monorepos can often be more flexible" Flexibility is not inherently good. 14:49 "I have found, I have seen from experience without naming names, that the codebase architecture is often a reflection of the structure and function of your organization" Don't tell him about Conway's Law. 15:10 "An engineering organization is not a bottom-up kind of thing" (X) Doubt. 15:18 "In a well functioning engineering team, priorities and decisions and effort allocation flow top-down" (X) Doubt. 15:24 "Some sort of top-down organization is required" (X) Doubt. 15:34 "... and I think this is why many large companies [...] have adopted this monorepo architecture" No, it's not. It's because they are large, hierarchically structured, top-down companies. See Conway's Law. 17:38 "One is do less of it, and the other is do more of it concurrently." Good thing that Guix does both. For pants themselves, I don't think I can take them seriously. Not just because I prefer skirts, but because merely looking at their repo, I see a corporate hellhole with at least 4 kinds of lockfiles. Are these the people who you would trust to have valuable takes on dependency management? Cheers
Re: Is Guix suitable for large monorepos?
Hi jgart, I find that Guix works well with a (source) pointing to local directories in a monorepo configuration. (hash) values are ignored for (local-files) in package sources, which has some benefits for a monorepo setup. It also works just as well, if not better, to help break up monorepos by using a separate git project for every code base, as one typically would, while keeping the high level coordination of all the packages in one big super-repo (using Guile+Guix). -- Sincerely, Ryan Sundberg On 7/21/22 9:55 PM, jgart wrote: > Is Guix suitable for large monorepos? > > How does Guix compare to pants in the python arena? > > https://yewtu.be/watch?v=p4stnR1gCR4 > https://www.pantsbuild.org/ OpenPGP_signature Description: OpenPGP digital signature
