Debbugs user tags

[Ludovic Courtès]

Hi Chris,

Chris Marusich  skribis:

> Anyone who wants to help with powerpc64le-linux is, of course, more than
> welcome to coordinate and lend a hand!  I will be tagging bug reports
> specific to powerpc64le-linux with the "powerpc64le-linux" usertag, for
> the user "guix-devel@gnu.org".  You can see the open bugs tagged thusly
> here:
>
> https://debbugs.gnu.org/cgi-bin/pkgreport.cgi?tag=powerpc64le-linux;users=guix-devel@gnu.org
>
> For details on usertags, start here:
>
> https://lwn.net/Articles/150658/

Should we add some text (and conventions?) to “Tracking Bugs and
Patches” in the manual about usertags?  Sounds like it could be useful.

Thanks,
Ludo’.

Re: Authenticating maintenance.git

[Ludovic Courtès]

Hi Chris,

Chris Marusich  skribis:

> Ludovic Courtès  writes:
>
>> Hello Guix!
>>
>> I’ve added a ‘.guix-authorizations’ file in maintenance.git, at last!

[...]

> I'm late to the party, but I notice that when I run this in
> guix-maintenance, I get an error:
>
> $ guix git authenticate 8a7e10b447b574279a7016ae6ea15bc7bcd46253 "3CE4 6455 
> 8A84 FDC6 9DB4  0CFB 090B 1199 3D9A EBB5"
> guix git: error: Git error: cannot locate remote-tracking branch 'keyring'
>
> Am I doing something wrong?

It looks like you’re missing a local ‘keyring’ branch for that repo, no?

I think you need to run:

  git fetch
  git branch --track keyring

HTH,
Ludo’.

Re: Freezing ‘core-updates’ soon?

[Ludovic Courtès]

Hello!

Jan Nieuwenhuizen  skribis:

> Ludovic Courtès writes:

[...]

>>   • Reduced binary seeds—anything new?  My understanding is that the
>> reduced binary seed bootstrap now works on ARM, but that we were
>> waiting on a Mes release to merge those bits.  Janneke, Danny?
>
> Sadly, we are not there yet.  The gcc/glibc build is still not done.
>
> The full source bootstrap is "almost ready" and is waiting for a GNU Mes
> release.  It was wating for an M2-Planet release but that happened last
> week!  I'm not sure about a time frame here though.  A week, hmm?

Alright.  Well no rush, that can also happen on the next cycle, and we
can also work to make it shorter.  :-)

>>   • Simplified package inputs—I’ll keep working on that, and most of the
>> work can be done without a world rebuild, so it’s not a blocker IMO.
>
> I haven't really caught-up here and am still wondering here about things
> like
>
>("foo-for-build" ,foo)
>("patch-bar" ,(search-patch ...))
>
> but that's prolly addressed.  I'll look into this.

Good points.  We’d have to look at specific examples.

In the first case, perhaps it’s enough to add ‘foo’ in ‘native-inputs’.

In both cases, you can always use gexps, like:

  (arguments
(list #:configure-flags
  #~(list (string-append "FOO_FOR_BUILD=" #$foo

… though the ‘foo’ here won’t show up in the inputs fields, which is not
great because then ‘guix graph’ and related tools won’t “see” this
reference, and you can’t easily override it via inheritance.

A better approach is to still add ‘foo’ to ‘native-inputs’ but to write
something like:

  (arguments
(list #:configure-flags
  #~(list (string-append "FOO_FOR_BUILD="
 #$(lookup-package-input
(package-inputs this-package)
"foo")

In the second example you give, you could have build-side code that
does, say:

  (lambda* (inputs #:allow-other-keys)
(invoke "patch" "-p1" "-i"
(find (cut string-suffix? ".patch") inputs)))

At any rate, I agree we need to find good idioms for these corner cases.

Thoughts?

Thanks,
Ludo’.

Re: Telemetry on by default kitty

[Ludovic Courtès]

Hi,

Giovanni Biscuolo  skribis:

> I apreciated the laconic statement by Tobias Geerinckx-Rice on Sat, 12
> Jun 2021 22:35:40 +0200 [1]:
>
>
>  This is not a point of discussion.  Telemetry or ‘phoning home’ 
>  for updates must be opt-in if possible or disabled entirely 
>  otherwise.  Would you care to submit a patch?
>
>
> AFAIU there is a general consensus above all GNU Guix maintainers (and
> all FSDG compliant distros) on the above statement: am I wrong?

I think you’re right; I think phoning home should be either disabled
opt-in.

As Leo Prikler wrote, it’s arguably a legal obligation in some
jurisdictions.

Ludo’.

Re: Idea: a meta language for (language) build systems - npm, Racket, Rust cargo

[Ludovic Courtès]

Hi!

Pjotr Prins  skribis:

> If you strip out dependency management and cross-platform compiling
> there is not much left to do for cmake, autotools, cargo etc.
> Everything Guix is good at. Ninja resolves the build graph, you only
> need something to generate the build graph for source files. A
> mini-Guix of sorts for source files. Eelco, at the time, wrote Maak -
> a builder that would work on NixOS. He wrote it in Haskell, but it is
> similar thinking.
>
>   https://en.wikipedia.org/wiki/Maak

It is an inspiration for hacks like
.
This is the kind of thing you’d typically do using Make, but where using
Guix is advantageous.

Now, as for Maak, it needs a library of helpers to be readily
usable—“rules” to build .o from .c, libraries, etc.

Is that the kind of thing you have in mind?

Then again, once you have that, you’re still very far from replacing or
integrating with tools like Cargo.

I guess it’s all about finding the right spot where things can be
usefully glued together!

Ludo’.

Re: RISCV porting effort

[Ludovic Courtès]

Christopher Baines  skribis:

> I also recently received a HiFive Umatched board which I ordered months
> ago.

Nice!

> While I don't really have the time right at the moment to actually do
> much with it, I've got it connected to the internet and can consider
> offering SSH access to anyone who could make use of it for porting Guix
> to RISCV.
>
> I brought it with building things for Guix in mind, if people would
> prefer it being owned by guix-europe, I'm open to selling it.

Something to discuss with guix-sysadmin, but why not!

I think in general it’s best to have collective control over project
assets such as hardware and domain names, for the sake of clarity and
transparency, which in turns implies project ownership.

Thanks,
Ludo’.

Re: Substitutes from bordeaux.guix.gnu.org

[Ludovic Courtès]

Hi!

Tobias Geerinckx-Rice  skribis:

> Christopher Baines 写道：
>> Would trying to acquire a 2U rack mount server, and host it in a
>> proper
>> data centre be feasible? Because of both electricity usage and heat
>> generation, it's going to be more difficult to host residentially I
>> think.
>
> I thought Bayfront was hosted here[0], but we still pay €75 instead of
> the €100 mentioned.  Perhaps Andreas has an understanding with them or
> was grandfathered in?

Yes, we could do the same.

Does anyone have cheaper (or gratis? :-)) hosting options in mind?

Ludo’.

Re: Substitutes from bordeaux.guix.gnu.org

[Ludovic Courtès]

Hi!

Christopher Baines  skribis:

> These changes are now in master, and I've published the blog post!
>
>   
> https://guix.gnu.org/en/blog/2021/substitutes-now-also-available-from-bordeauxguixgnuorg/
>
> As said in the blog post, I regard this as an important milestone. As a
> change goes, the impact will be gradual, but I'm hoping in hindsight it
> will be a step forward.

Thanks for doing this work and bringing it to completion!

I think a second independent build farm is a good thing to have—for
redundancy, availability, and to challenge package reproducibility.

Ludo’.

Re: Supporting *multiple* bootloaders for arm64 on a single install?

[Stefan]

Hi Bengt!

> What form would a "firmware field" take?

In principle a gexp, which installs a firmware package, or #f. On x86 only #f 
is needed – unless you want Guix to install e.g. coreboot as your firmware.

> On principle, I am against boundless _incorporation_ of new dangerous 
> capabilities into a piece of software, as opposed
> to incoporating the ability to chain-load or otherwise encapsulate execution 
> of a single-purpose,
> minimal-source-for-better-inspection-and-exclusion-of-attacks-piece-of-software
>  that does something dangerous.

Well, GRUB has some nice features, which e.g. U-Boot hasn’t. It would be 
comfortable to use these features on other architectures than x86, too, e.g. 
graphics, modifying the kernel arguments, LUKS. Treating U-Boot as firmware 
makes GRUB the de-facto bootloader and brings ARM and other architectures on 
par with x86.

> ISTM UEFI is way more complicated than booting needs to be. What does the 
> boot process need to do besides
> (after post) identify a series of untrusted(!) block stream sources to try, 
> load the first image whose secure hash either matches
> a white list -- or securely display the hash of the unrecognized image and 
> ask authorized operator for ok + hash nickname
> for inclusion in the whitelist or reject? If ok, jump into boot image as 
> normal.
> 
> If a developer I trust says (in a securely communicated way) that I can 
> safely load something with a hash of whatever,
> I think that is more trustworthy than pretty much anything else I can think 
> of. And on a forum, someone else can say,
> "Don't trust that thing with hash xxx...zzz, it blew up for me," and I can 
> hold off until there's a consensus.
> 
> WDYT?

Chain loading U-Boot, iPXE and GRUB offers iSCSI capabilities, using the 
network driver from U-Boot, the TCP and iSCSI stack from iPXE, GRUB as the 
front-end¹ and iSCSI as block device for the OS. This enables possibilities you 
otherwise would not have. But of course this is not against your argument, that 
it gets more complex. But it offers new possibilities, which were not possible 
otherwise.

Anyway, I do not suggest to degrade U-Boot to be a firmware only, it can be a 
bootloader. But offering U-Boot as a firmware makes other architectures similar 
to x86, offering the same possibilities.

Actually I think any firmware to make GRUB usable is a good fit for a firmware. 
Using coreboot as firmware and GRUB as its payload is a good fit. If your 
system has a firmware capable to start GRUB, fine as well, nothing to do. If 
Guix needs to install a firmware first, before GRUB becomes usable, then I 
think there is a need for a firmware field. If you want to treat U-Boot as a 
firmware-and-bootloader, then use it as bootloader and omit the firmware field.

> BTW, why not build multiple installer ISOs targeted for different 
> architectures, and specialized needs?
> (for smaller ISOs and other benefits). I assume one could already do this 
> with guix, but why not leave the
> whole ball-of-wax to git clone, and let people with common architectures have 
> less to download and less
> irrelevant-to-them choices?

I think I don't understand what you are talking about here.


Bye

Stefan


¹ 

 page 22

Re: Supporting *multiple* bootloaders for arm64 on a single install?

[Bengt Richter]

Hi Stefan, et al,

On +2021-06-19 17:11:45 +0200, Stefan wrote:
> Hi!
> 
> >> But as I understand it, guix only supports a single bootloader entry. 
> > 
> > That is correct.
> > 
> >> To support all of the above, I would need three separate bootloader
> >> instances... one for Pinebook, one for Pinebook Pro, and lastly a
> >> grub-efi bootloader.
> > 
> > Stefan wrote a Guix chain bootloader that is in master--but it's meant
> > to be only used for bootloaders where there is a primary "bare-metal-loaded"
> > bootloader and the others are chain-loaded one-after-another from ONE 
> > filesystem
> > (for example Raspberry Pi and/or EFI bootloaders).
> > 
> > (It's currently used in order to use an EFI bootloader hosted on NFS--which
> > is an awesome way to manage embedded boards)
> > 
> > The chain bootloader itself is one Guix bootloader.
> > 
> > I advise you to search for mails by Stefan on the guix-devel mailing 
> > list--those
> > are very illuminating.
> 
> By the way, there is  
> since a month meanwhile, which now makes the support for the Raspberry Pi 
> complete. The same bootloader can be used for an NFS root installation and an 
> installation on micro SD card or an USB drive by just changing the mount 
> point of the root file-system.
> 
> Danny, I’d appreciate your review very much. This time you can apply the 
> patches and just use the gnu/system/examples/raspberry-pi-64.tmpl with guix 
> system init. :-) 
> 
> >> And somewhere along the way I've lost track of how we get to
> >> install-pinebook-pro-rk3399-u-boot…
> 
> The same happened to me. I’ll first wait for the patch #48314 to be accepted, 
> before I’ll look again into creating a disk image for the Raspberry Pi.
> 
> > If you do want to chainload grub-efi eventually, that's supported in Guix 
> > master,
> > see "efi-bootloader-chain".  It's meant for the end user to be able to use.
> 
> Referring to the patch #48314, the efi-bootloader-chain got simplified. It 
> basically prepares a profile with all files to be copied as is, no special 
> “collection” folder any more. And the installer of the 
> grub-efi-netboot-(removable-)bootloader is now merely a simple 
> “(copy-recursively bootloader-profile)“ procedure.
> 
> >> A related idea would be to generate an EFI bootable image with
> >> sufficient emtpy space before the first partition (16MB) and then one
> >> could manually install the appropriate u-boot, maybe with some helper
> >> scripts to avoid having to do it completely manually...
> > 
> > Yeah, that's possible right now.  After all, you don't have to load the 
> > generated
> > guix system disk image on bare metal.  Just boot it in qemu and install 
> > u-boot
> > there for example.  Or even edit the image manually by using dd.  
> > (unfortunately,
> > on almost every ARM system I set up Guix on so far, one or both of those 
> > were
> > necessary)
> 
> I believe that the ARM future is UEFI, like on PCs. A lot of distributions 
> already chainload U-Boot and GRUB an arm systems. There is a specification 
> for ARM servers which demands UEFI¹. And there is even the choice between 
> U-Boot and TianoCore/EDK II.
> 
> I think meanwhile that it would be beneficial, if, beside a bootloader field, 
> Guix would accept an optional firmware field. Then the U-Boot or 
> TianoCore/EDK II (or coreboot) could become some board specific firmware, and 
> the actual bootloader would be grub-efi installed on an EFI System Partition. 
> For systems like the Raspberry, which require their firmware on a FAT 
> partition, there is the already working efi-bootloader-chain solution.
> 
> The firmware could only be installed on explicit request. It's not expected 
> to see frequent changes – every re-installation is a risk to brick the 
> system. (For my taste the bootloader is re-installed too often already.)
>

What form would a "firmware field" take?

On principle, I am against boundless _incorporation_ of new dangerous 
capabilities into a piece of software, as opposed
to incoporating the ability to chain-load or otherwise encapsulate execution of 
a single-purpose,
minimal-source-for-better-inspection-and-exclusion-of-attacks-piece-of-software 
that does something dangerous.

ISTM UEFI is way more complicated than booting needs to be. What does the boot 
process need to do besides
(after post) identify a series of untrusted(!) block stream sources to try, 
load the first image whose secure hash either matches
a white list -- or securely display the hash of the unrecognized image and ask 
authorized operator for ok + hash nickname
for inclusion in the whitelist or reject? If ok, jump into boot image as normal.

If a developer I trust says (in a securely communicated way) that I can safely 
load something with a hash of whatever,
I think that is more trustworthy than pretty much anything else I can think of. 
And on a forum, someone else can say,
"Don't trust that thing with hash xxx...zzz,