Use nix for reproducible build env #1269

mmlb · 2023-01-05T22:18:17Z

Use nix for the build environment. This gives us a reproducible build environment. Use it by entering a "pure" nix shell so only what is specified in the shell.nix is available by running nix-shell --pure.

mmlb · 2023-01-05T22:22:37Z

@tlaurion here's my branch.... finally! I ended up going with good old nix-shell w/ buildFHSUserEnv so we can have executables in /usr/bin/. I just gave it a go and it got much further than I've had so far but its stuck building coreboot-4.13/crossgcc/GCC:

      |   ^~
In file included from ../../gcc-8.3.0/gcc/backend.h:30,
                 from ../../gcc-8.3.0/gcc/lra-constraints.c:112:
../../gcc-8.3.0/gcc/bitmap.h:771:3: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the 'if'
  771 |   for (bmp_iter_set_init (&(ITER), (BITMAP), (MIN), &(BITNUM));         \
      |   ^~~
../../gcc-8.3.0/gcc/lra-constraints.c:4579:5: note: in expansion of macro 'EXECUTE_IF_SET_IN_BITMAP'
 4579 |     EXECUTE_IF_SET_IN_BITMAP (&lra_reg_info[regno].insn_bitmap, 0, uid, bi)
      |     ^~~~~~~~~~~~~~~~~~~~~~~~
../../gcc-8.3.0/gcc/lto-compress.c:34:10: fatal error: zlib.h: No such file or directory
   34 | #include <zlib.h>
      |          ^~~~~~~~
compilation terminated.
g++ -fno-PIE -c   -O2  -fomit-frame-pointer -m64  -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE   -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H -I. -I. -I../../gcc-8.3.0/gcc -I../../gcc-8.3.0/gcc/. -I../../gcc-8.3.0/gcc/../include -I../../gcc-8.3.0/gcc/../libcpp/include -I/home/manny/projects/github.com/osresearch/heads/build/x86/coreboot-4.13/util/crossgcc/xgcc/include -I/home/manny/projects/github.com/osresearch/heads/build/x86/coreboot-4.13/util/crossgcc/xgcc/include -I/home/manny/projects/github.com/osresearch/heads/build/x86/coreboot-4.13/util/crossgcc/xgcc/include  -I../../gcc-8.3.0/gcc/../libdecnumber -I../../gcc-8.3.0/gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc-8.3.0/gcc/../libbacktrace   -o omp-offload.o -MT omp-offload.o -MMD -MP -MF ./.deps/omp-offload.TPo ../../gcc-8.3.0/gcc/omp-offload.c
make[1]: *** [Makefile:1110: lto-compress.o] Error 1
make[1]: *** Waiting for unfinished jobs....
sh ../../gcc-8.3.0/gcc/../move-if-change tmp-attrtab.c    insn-attrtab.c
sh ../../gcc-8.3.0/gcc/../move-if-change tmp-dfatab.c     insn-dfatab.c
sh ../../gcc-8.3.0/gcc/../move-if-change tmp-latencytab.c insn-latencytab.c
echo timestamp > s-attrtab
sh ../../gcc-8.3.0/gcc/../move-if-change tmp-automata.c insn-automata.c
echo timestamp > s-automata
rm gcc.pod
make[1]: Leaving directory '/home/manny/projects/github.com/osresearch/heads/build/x86/coreboot-4.13/util/crossgcc/build-i386-elf-GCC/gcc'
make: *** [Makefile:4244: all-gcc] Error 2

You can give it a go by running nix-shell --pure and then make.

mmlb · 2023-01-06T16:40:36Z

Ok made a little more progress, got past the zlib.h issue and added a few more package after trying from scratch with nix-shell --pure. But now we're running into build errors build GCC.

g++ -fno-PIE -c  -I../../gcc-8.3.0/gcc/../libgcc -DEH_MECHANISM_gcc -DIN_GCC_FRONTEND -O2  -fomit-frame-pointer -m64  -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE   -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual  -Wmissing-format-attribute -Woverloaded-virtual -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H -I. -Iada -I../../gcc-8.3.0/gcc -I../../gcc-8.3.0/gcc/ada -I../../gcc-8.3.0/gcc/../include -I../../gcc-8.3.0/gcc/../libcpp/include -I/home/manny/projects/github.com/osresearch/heads/build/x86/coreboot-4.13/util/crossgcc/xgcc/include -I/home/manny/projects/github.com/osresearch/heads/build/x86/coreboot-4.13/util/crossgcc/xgcc/include -I/home/manny/projects/github.com/osresearch/heads/build/x86/coreboot-4.13/util/crossgcc/xgcc/include  -I../../gcc-8.3.0/gcc/../libdecnumber -I../../gcc-8.3.0/gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc-8.3.0/gcc/../libbacktrace   -o ada/raise-gcc.o -MT ada/raise-gcc.o -MMD -MP -MF ada/.deps/raise-gcc.TPo ../../gcc-8.3.0/gcc/ada/raise-gcc.c
In file included from /nix/store/mmmjp0xcmr0dm307jv1l34hvi95z6d8s-glibc-2.35-224-dev/include/signal.h:328,
                 from /nix/store/mmmjp0xcmr0dm307jv1l34hvi95z6d8s-glibc-2.35-224-dev/include/sys/param.h:28,
                 from ../../gcc-8.3.0/gcc/system.h:298,
                 from ../../gcc-8.3.0/gcc/ada/init.c:65:
../../gcc-8.3.0/gcc/ada/init.c:575:18: error: missing binary operator before token "("
  575 | # if 16 * 1024 < MINSIGSTKSZ
      |                  ^~~~~~~~~~~

Next step is to try with an older gcc instead, currently its at 11.3.

tlaurion · 2023-01-06T22:36:22Z

@mmlb : Issues are opened upstream (nixos) for GCC and Ada.

General idea (fixed for la test ada) seems to always try to bootstrap ADA from an older version to build newer versions. Haven't checked progression of issues but important as part of coreboot builder project as well

Edit

NixOS/nixpkgs#174982

So I guess target would be gnat6 to obtain both older GCC and ada to build musl-cross-make and each coreboot's dependent version buildstack?

mmlb · 2023-01-10T02:29:04Z

@mmlb : Issues are opened upstream (nixos) for GCC and Ada.

General idea (fixed for la test ada) seems to always try to bootstrap ADA from an older version to build newer versions. Haven't checked progression of issues but important as part of coreboot builder project as well

Edit

NixOS/nixpkgs#174982

So I guess target would be gnat6 to obtain both older GCC and ada to build musl-cross-make and each coreboot's dependent version buildstack?

Yep I'm trying that now locally. Looks like its going to build gcc/gnat for the nixpkgs revision I pinned to. Now I remember why the initial flake had the old gnat, I had a hunch that newer gcc/gnat would fail to build old one and went back and found out I was right :D. I'll see if gnat builds now and also check around to see if there's a revision that has gnat built by hydra so users won't have to rebuild gnat/gcc.

mmlb · 2023-01-11T04:18:24Z

Ok back to nix flakes. The nice thing about flakes is that its easy to manage the pinned versions as flakes locks the inputs and knows how to update them. Also makes it really easy to add new inputs of nixpkgs at specific commits for example.

So I've switched back over to the flake so that I can grab the last "known good" version of gnat6 (from an old nixpkgs commit), latest nixpkgs gnat6 still doesn't build for me. Unfortunately the old gnat6 + buildFHSUserEnv don't seem to play well because I'm now getting:

error while loading shared libraries: __vdso_gettimeofday: invalid mode for dlopen(): Invalid argument

I'm going to go back to nixpkgs and see whats up with gnat6 on master and if there's anything to be done about vdso.

--- edit

Also, the coreboot patch is so coreboot will accept gnatbind over just gnat. Not sure if thats alright or not, will have to see once vdso is issue is figured out.

tlaurion · 2023-01-13T16:40:00Z

@osresearch @mmlb Have you fell upon https://git.sr.ht/~amjoseph/ownerboot ?
Fascinating food for thought.

mmlb · 2023-01-23T16:43:55Z

@tlaurion I had not see that no, thanks. All of the successful things I've seen so far are building coreboot with nix and nix built toolchains, which is not the route I thought we wanted to be going initially. I think we might want to reconsider that, maybe we build coreboot with make but with nix's gcc as the initial stab instead?

tlaurion · 2023-01-23T18:29:36Z

@mmlb

Well, depending of how incremental we want changes to Heads to happen (Makefile)

If gnat6 and GCC are provided in earlier versions enough to build coreboot 4.11, nix toolchain can be used to bootstrap coreboot per version buildstack, otherwise we won't be able to build kgpe-d16 and librem server (based on coreboot 4.11).
As of now, everything else Heads uses musl-cross-make to build modules.

So to go the route of using coreboot buildstack under heads, nix would either have to also support older versions of coreboot (not the case right now, I think that 4.16+ are supported under nix).

Otherwise, we could switch things around and get rid of musl-cross-make and use coreboots buoldstack, but I'm worried that would increase maintainsership cost. What is interesting about ownerboot is that they are building initrd tools directly from nix buikdstack as well to be packed. This is neat, but we would need to use something stable as a buildstack there. That would be better then using per version coreboot buildstaxk to build everything inside of heads, which would also augment cahce differences we would need to keep since they won't be shareable between different board's coreboot version depending buildstack.

So my thoughts on previous comment of yours is that:

best avenue would be to have earlier version of gnat and GCC to bootstrap coreboot's buildstack. That seems to be the best avenue, but would require upstream nixos work and bugfixes I guess.

mmlb · 2023-01-23T22:06:36Z

@mmlb

Well, depending of how incremental we want changes to Heads to happen (Makefile)
* If gnat6 and GCC are provided in earlier versions enough to build coreboot 4.11, nix toolchain can be used to bootstrap coreboot per version buildstack, otherwise we won't be able to build kgpe-d16 and librem server (based on coreboot 4.11).

* As of now, everything else Heads uses musl-cross-make to build modules.
So to go the route of using coreboot buildstack under heads, nix would either have to also support older versions of coreboot (not the case right now, I think that 4.16+ are supported under nix).

I don't think I follow here. Are you suggesting to use coreboot's build of gcc stack for the rest of heads instead of just for coreboot? Thats not exactly what I was suggesting earlier. I was suggesting we use the same gcc setup for both coreboot and rest of heads. (I wasn't aware of usage of musl-cross-make, I assumed heads used the same compilers coreboot builds/uses. I'm not sure what it would take to replace musl-cross-make if wanted.

Otherwise, we could switch things around and get rid of musl-cross-make and use coreboots buoldstack, but I'm worried that would increase maintainsership cost. What is interesting about ownerboot is that they are building initrd tools directly from nix buikdstack as well to be packed. This is neat, but we would need to use something stable as a buildstack there. That would be better then using per version coreboot buildstaxk to build everything inside of heads, which would also augment cahce differences we would need to keep since they won't be shareable between different board's coreboot version depending buildstack.

Yep this is what I was suggesting too. You mention:

This is neat, but we would need to use something stable as a buildstack there.

What do you mean when you say "stable"? Why isn't nix's gcc+ada considered stable for this purpose?

So my thoughts on previous comment of yours is that:

* best avenue would be to have earlier version of gnat and GCC to bootstrap coreboot's buildstack. That seems to be the best avenue, but would require upstream nixos work and bugfixes I guess.

So I took a look at fixing gnat6 in latest nixpkgs instead of relying on an old one which should get past the gettimeofday vdso issue I think. This isn't currently working due to bootstrapping issues. nixpkgs uses binary builds of gnat from https://github.com/alire-project/GNAT-FSF-builds to build nixpkg's gcc+ada. Both nixpkgs and alire-project only actually go back to v11 :(. So this needs to be figured out somehow 🤔.

tlaurion · 2023-01-23T23:01:06Z

don't think I follow here. Are you suggesting to use coreboot's build of gcc stack for the rest of heads instead of just for coreboot? Thats not exactly what I was suggesting earlier. I was suggesting we use the same gcc setup for both coreboot and rest of heads. (I wasn't aware of usage of musl-cross-make, I assumed heads used the same compilers coreboot builds/uses. I'm not sure what it would take to replace musl-cross-make if wanted.

As of now:

host GCC and gnat under debian-10-11 are used to compile musl-cross-make and each versions of compiled board defined coreboot version's buildstack
musl-cross-make is used to build all modules/* defined under board config and their dependencies outsider of coreboot
coreboot is finally built using board's defined coreboot's version buildstack

So following your comment:

musl-cross-make could probably be replaced by nix's reproducible toolstack, but that would require changes to heads Make file to start transition.

I thought the first step would be to have nix have an earlier version if the toolstack (mostly for gnat) to be able to compile coreboot 4.11 and later buildstack AND musl-cross-make.

If we can also use Nix's musl-cross-make builds: awesome. There will just need to have some adaptation to Heads makefile, since first thing built is musl-cross-make here.

@mmlb makes sense?

tlaurion · 2023-04-04T20:11:32Z

So I took a look at fixing gnat6 in latest nixpkgs instead of relying on an old one which should get past the gettimeofday vdso issue I think. This isn't currently working due to bootstrapping issues. nixpkgs uses binary builds of gnat from https://github.com/alire-project/GNAT-FSF-builds to build nixpkg's gcc+ada. Both nixpkgs and alire-project only actually go back to v11 :(. So this needs to be figured out somehow thinking.

@mmlb any news? :/

mmlb · 2023-04-04T20:28:44Z

@tlaurion nope sorry I got pulled off into other things at work and at home. I was actually thinking about this earlier today. I tried out https://github.com/alire-project/GNAT-FSF-builds on my own but got no where. I think its way past time I solicit the help of others. I'll ask around in nix's matrix to see how we can get gnat6.

mmlb · 2023-04-07T16:44:17Z

[12:45:20]-[~/c/g/N/nixpkgs]-[manny@c3mnix]                                                                                                                                  
nix-build -A gnatboot4 -o gnatboot4; and echo gnatboot4:; and ./gnatboot4/bin/gcc --version; and nix-build -A gnat6 -o gnat6; and echo gnat6:; and ./gnat6/bin/gnat -v       
/nix/store/f1f7zij1f8njddwcgig9idh0mwxg8211-gnatboot-wrapper-4.1                                                                                                             
gnatboot4:                                                                                                                                                                   
gcc (GCC) 4.1.0                                                                                                                                                              
Copyright (C) 2006 Free Software Foundation, Inc.                                                                                                                            
This is free software; see the source for copying conditions.  There is NO                                                                                                   
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.           

/nix/store/iz40d67dkvyfk4yd0pz5kkfyv8p0fqq6-gnat-wrapper-6.5.0
gnat6:
GNAT 6.5.0
Copyright 1996-2016, Free Software Foundation, Inc.

List of available commands

gnat bind               gnatbind
gnat chop               gnatchop
gnat clean              gnatclean
gnat compile            gnatmake -f -u -c
gnat check              gnatcheck
gnat elim               gnatelim
gnat find               gnatfind
gnat krunch             gnatkr
gnat link               gnatlink
gnat list               gnatls
gnat make               gnatmake
gnat metric             gnatmetric
gnat name               gnatname
gnat preprocess         gnatprep
gnat pretty             gnatpp
gnat stack              gnatstack
gnat stub               gnatstub
gnat test               gnattest
gnat xref               gnatxref

Commands bind, find, link, list and xref accept project file switches -vPx, -Pprj, -Xnam=val,--subdirs= and -eL

🎉

Now to open up a PR to nixpkgs.

tlaurion · 2023-04-07T16:50:22Z

@mmlb Fan-Tas-Tic!

mmlb · 2023-04-07T17:56:22Z

NixOS/nixpkgs#225191

tlaurion · 2023-05-06T16:30:12Z

@mmlb

In parallel, trying to make boards not depend on ada by removing libgfx support on all boards, explicitly relying on board config's kernel configs to provide fb through drm that will either work by abusing kernel fb exposition (no compression of fb, exposing fb address new config options that taint Heads on 5.x kernel for i915 driver), hacking kexec to provide exposed flat fb address in kexec call (whitelisting approch under kexec patch in master) or require that the next kexec'ed kernel provides DRM+GPU in initrd so there is fb avail when asking for LUKS decryption key passphrase.

First results shows that most boards did not really need coreboot libgfx for all non-dgpu enabled boards.
(See recent master changes for librem boards).

If tests with dgpu vbios provided blobs also confirms non requirement of libgfx (they shouldn't, only doubt is for EDP variant of x230 which provides modified vbt which seems to be relaying on libgfx at least in doc, but a quick test by board owners should validate/invalidate this.) Then ada requirement to libgfxiniy will be gone for Heads.

Long story short, we might not need ada altogether. History will tell soon enough.

Crossposting here from NixOS/nixpkgs#225191 (comment)

… configs without libgfxinit linuxboot#1269 Modified with limited understanding absolute local builds to reuse Nix cache of already confirmed reproducible stuff Removed gnat6/ada, added swtpm, texinfo and rsync for which otherwise there was local failings

tlaurion · 2023-05-07T17:55:40Z

@mmlb well some progress, but as of 6423000 on CircleCI:

https://app.circleci.com/pipelines/github/tlaurion/heads/1683/workflows/97b36967-28ba-47be-8fe9-24714bd81ab1/jobs/22773/parallel-runs/0/steps/0-102

Builds ends with

** Message: 17:51:51.400: Requires Linux version >= 3.19 built with CONFIG_USER_NS
** Message: 17:51:51.402: Run: sudo sysctl -w kernel.unprivileged_userns_clone=1

** (process:582): ERROR **: 17:51:51.402: main: unshare: Operation not permitted

Exited with code exit status 133

… configs without libgfxinit linuxboot#1269 Modified with limited understanding absolute local builds to reuse Nix cache of already confirmed reproducible stuff Removed gnat6/ada, added swtpm, texinfo and rsync for which otherwise there was local failings

aluciani · 2024-03-28T15:29:59Z

Hello there, I follow this PR, and saw that some work has been done.
Thanks a lot !
I m trying to test it on my side but I encounter some issues.
Could you confirm me that all I have to do is

Get a linux system (I m on debian 12)
Install nix package manager (setup the ~/.config/nix/nix.conf with experimental-features = nix-command flakes)
do a nix develop in heads repo
then a make BOARD=whatever

right ?

mmlb · 2024-03-28T16:02:57Z

Hello there, I follow this PR, and saw that some work has been done. Thanks a lot ! I m trying to test it on my side but I encounter some issues. Could you confirm me that all I have to do is
1. Get a linux system (I m on debian 12)

2. Install nix package manager (setup the `~/.config/nix/nix.conf with` `experimental-features = nix-command flakes`)

3. do a `nix develop` in heads repo

4. then a `make BOARD=`whatever
right ?

Yep thats more or less what I do. Ping me on the matrix channel so we can avoid a tangent here.

mmlb · 2024-03-28T23:10:12Z

I'm confused how the boards the want the [tw]530 roms are passing in CI since I skipped the neutering done in prep_env.

tlaurion · 2024-03-29T00:25:20Z

[tw]230 me blobs: Boards are dealing with blobs download directly now. We add it under CirecleCI to download once on clean builds only Ex: https://github.com/linuxboot/heads/blob/master/boards%2Fw530-maximized%2Fw530-maximized.config#L71-L72 Includes https://github.com/linuxboot/heads/blob/master/targets%2Fxx30_me_blobs.mk

…

On Thu, Mar 28, 2024, 7:10 PM Manuel Mendez ***@***.***> wrote: I'm confused how the boards the want the [tw]530 roms are passing in CI since I skipped the neutering done in prep_env. — Reply to this email directly, view it on GitHub <#1269 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGKBMUIMRYMG4PKIW6ZUH3Y2SPOVAVCNFSM6AAAAAATSODU6GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMRWGI4TIOBRGY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

tlaurion · 2024-03-31T23:19:02Z

[tw]230 me blobs: Boards are dealing with blobs download directly now. We add it under CirecleCI to download once on clean builds only Ex: https://github.com/linuxboot/heads/blob/master/boards%2Fw530-maximized%2Fw530-maximized.config#L71-L72 Includes https://github.com/linuxboot/heads/blob/master/targets%2Fxx30_me_blobs.mk
…
On Thu, Mar 28, 2024, 7:10 PM Manuel Mendez @.> wrote: I'm confused how the boards the want the [tw]530 roms are passing in CI since I skipped the neutering done in prep_env. — Reply to this email directly, view it on GitHub <#1269 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGKBMUIMRYMG4PKIW6ZUH3Y2SPOVAVCNFSM6AAAAAATSODU6GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMRWGI4TIOBRGY . You are receiving this because you were mentioned.Message ID: @.>

@mmlb I saw CircleCi empty steps for vbios download. Well, the boards that were depending on vbios have been moved to unmaintained directories since nobody having the hardware tested them in the last PRs. First they were moved to untested but still built, then moved to unmaitained_boards. There is no way I can maintain boards that are not officially used by anybody. When somebody interested to at least testing the ROMs with and external reprogrammer to revert back to working state in case of bricking, those will be brought back to being built by CricleCI.

tlaurion · 2024-03-31T23:25:54Z

Discussion continued over matrix over thread https://matrix.to/#/!pAlHOfxQNPXOgFGTmo:matrix.org/$4OPI4He9fhXYWtGUrpJyAMWjvOPHZ9iD0S7WQyRQBhw?via=matrix.org&via=nitro.chat&via=fairydust.space

The current state is that I pushed docker counterpart of this current PR state over https://github.com/tlaurion/heads/tree/nix_with_develop_created_container and https://github.com/tlaurion/heads/tree/nix_with_develop_created_container-updated_flake_lock but the currently produced docker image doesn't expose env iwht proper PATH, which I think is the source of the builds failing using pushed dockerhub images.

You can test in a branch of yours and if registered on CircleCI and Github having your ssh public key, you will be able to relunch builds and give ssh access. When you will land in the docker, you will see that env doesn't show the same as in local docker launched environements.

You can also see at https://matrix.to/#/!pAlHOfxQNPXOgFGTmo:matrix.org/$mGsDZ0Bzvt0SyE6i_GPGFBVLxnvtQwfvn8BSIPZ2QmQ?via=matrix.org&via=nitro.chat&via=fairydust.space the commands I used to build docker and run locally, which also fails loclly, but not for coreboot crossgcc, but when comes the time to build tpm2-tools where PATH doesn't include sbin where addgroup/groupadd is found. That will need fixing somehow as well.

Signed-off-by: Manuel Mendez <[email protected]>

Until nix PR is merged to not interfere with master/other pr caches Signed-off-by: Manuel Mendez <[email protected]>

tlaurion · 2024-04-09T19:22:39Z

#1630 should be ready for merge. Rebase/merge this and retest needed

tlaurion · 2024-04-24T00:40:18Z

@mmlb I spent the day on https://github.com/tlaurion/heads/tree/wip-nix-for-build and made it work rebased/fixed from #1630

#1630 cannot be used as is for whatever reason, sys-root needs to be there still under tpm2* modules, couldnt get rid of that one and haven't figure out why still.

CircleCI builds can be observed and dived in under https://app.circleci.com/pipelines/github/tlaurion/heads?branch=wip-nix-for-build

I was able to build local without nix, with nix layer and from CircleCI.
Docker layer next...

Notes:

Don't forget to change CircleCI project's variable CACHE_VERSION to something new if you want to skip reusing CircleCI caches layers defined under .CircleCI, or change the prefix inside of CircleCI.

The docker is next to be tested
Made notes under NIX_REPRO_NOTES to be aimed at doc when things are final and reusable in the 3 contexts.

Let me know what's next

h2dden · 2024-06-15T06:22:27Z

handover holiday

mmlb force-pushed the wip-nix-for-build branch from 5bd03a2 to d8b5671 Compare January 6, 2023 16:32

mmlb force-pushed the wip-nix-for-build branch 2 times, most recently from c65ae3a to 02f1fa6 Compare January 6, 2023 17:09

mmlb force-pushed the wip-nix-for-build branch from 02f1fa6 to 53e869f Compare January 11, 2023 04:20

tlaurion mentioned this pull request Jan 25, 2023

gnat10, gnat9, gnat6: drop the packages NixOS/nixpkgs#210564

Merged

tlaurion mentioned this pull request Apr 4, 2023

Fail to build binary under Debian 12 (Bookworm) #1364

Closed

15 tasks

mmlb mentioned this pull request Apr 7, 2023

Bring gnat6 back NixOS/nixpkgs#225191

Closed

12 tasks

tlaurion mentioned this pull request Apr 21, 2023

Fix kexec framebuffer graphics for 5.10 kernel #1378

Merged

5 tasks

mmlb force-pushed the wip-nix-for-build branch 10 times, most recently from be1393c to ea3e7a2 Compare March 27, 2024 21:45

mmlb force-pushed the wip-nix-for-build branch from ea3e7a2 to d787306 Compare March 28, 2024 22:32

tlaurion mentioned this pull request Apr 1, 2024

Reproducibility problems with libcrypto and libtss2 #1616

Closed

mmlb and others added 3 commits April 1, 2024 21:54

Add nix files

9843483

Signed-off-by: Manuel Mendez <[email protected]>

ci: Switch image from debian to nix

98fc6cb

Signed-off-by: Manuel Mendez <[email protected]>

ci: Prepend nix- to save and restore cache statements

c4c365c

Until nix PR is merged to not interfere with master/other pr caches Signed-off-by: Manuel Mendez <[email protected]>

mmlb force-pushed the wip-nix-for-build branch from d787306 to c4c365c Compare April 2, 2024 01:54

This was referenced May 2, 2024

Move to nix buildstack (and nix develop produced docker image used under CircleCI) #1660

Closed

Move to nix buildstack (and nix develop produced docker image used under CircleCI) #1661

Merged

This was referenced May 25, 2024

Discussion: Implementation of a Docker based build system #1190

Closed

Build Error on Raspbian x64 #1548

Closed

mmlb closed this Jun 15, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Use nix for reproducible build env #1269

Use nix for reproducible build env #1269

mmlb commented Jan 5, 2023 •

edited

Loading

mmlb commented Jan 5, 2023 •

edited

Loading

mmlb commented Jan 6, 2023 •

edited

Loading

tlaurion commented Jan 6, 2023 •

edited

Loading

mmlb commented Jan 10, 2023

mmlb commented Jan 11, 2023 •

edited

Loading

tlaurion commented Jan 13, 2023 •

edited

Loading

mmlb commented Jan 23, 2023

tlaurion commented Jan 23, 2023

mmlb commented Jan 23, 2023

tlaurion commented Jan 23, 2023 •

edited

Loading

tlaurion commented Apr 4, 2023 •

edited

Loading

mmlb commented Apr 4, 2023

mmlb commented Apr 7, 2023 •

edited

Loading

tlaurion commented Apr 7, 2023

mmlb commented Apr 7, 2023

tlaurion commented May 6, 2023 •

edited

Loading

tlaurion commented May 7, 2023

aluciani commented Mar 28, 2024 •

edited

Loading

mmlb commented Mar 28, 2024

mmlb commented Mar 28, 2024

tlaurion commented Mar 29, 2024 via email •

edited

Loading

tlaurion commented Mar 31, 2024

tlaurion commented Mar 31, 2024

tlaurion commented Apr 9, 2024

tlaurion commented Apr 24, 2024 •

edited

Loading

h2dden commented Jun 15, 2024 via email

Use nix for reproducible build env #1269

Use nix for reproducible build env #1269

Conversation

mmlb commented Jan 5, 2023 • edited Loading

mmlb commented Jan 5, 2023 • edited Loading

mmlb commented Jan 6, 2023 • edited Loading

tlaurion commented Jan 6, 2023 • edited Loading

mmlb commented Jan 10, 2023

mmlb commented Jan 11, 2023 • edited Loading

tlaurion commented Jan 13, 2023 • edited Loading

mmlb commented Jan 23, 2023

tlaurion commented Jan 23, 2023

mmlb commented Jan 23, 2023

tlaurion commented Jan 23, 2023 • edited Loading

tlaurion commented Apr 4, 2023 • edited Loading

mmlb commented Apr 4, 2023

mmlb commented Apr 7, 2023 • edited Loading

tlaurion commented Apr 7, 2023

mmlb commented Apr 7, 2023

tlaurion commented May 6, 2023 • edited Loading

tlaurion commented May 7, 2023

aluciani commented Mar 28, 2024 • edited Loading

mmlb commented Mar 28, 2024

mmlb commented Mar 28, 2024

tlaurion commented Mar 29, 2024 via email • edited Loading

tlaurion commented Mar 31, 2024

tlaurion commented Mar 31, 2024

tlaurion commented Apr 9, 2024

tlaurion commented Apr 24, 2024 • edited Loading

h2dden commented Jun 15, 2024 via email

mmlb commented Jan 5, 2023 •

edited

Loading

mmlb commented Jan 5, 2023 •

edited

Loading

mmlb commented Jan 6, 2023 •

edited

Loading

tlaurion commented Jan 6, 2023 •

edited

Loading

mmlb commented Jan 11, 2023 •

edited

Loading

tlaurion commented Jan 13, 2023 •

edited

Loading

tlaurion commented Jan 23, 2023 •

edited

Loading

tlaurion commented Apr 4, 2023 •

edited

Loading

mmlb commented Apr 7, 2023 •

edited

Loading

tlaurion commented May 6, 2023 •

edited

Loading

aluciani commented Mar 28, 2024 •

edited

Loading

tlaurion commented Mar 29, 2024 via email •

edited

Loading

tlaurion commented Apr 24, 2024 •

edited

Loading