Re: issues.guix.gnu.org seems stop updating

[Development of GNU Guix and the GNU System distribution.]

Hi,

On Fri, Dec 08 2023, Maxim Cournoyer wrote:

> We still don't have a service for it (bug #59180).

The sync is working now. Also, I have a service for my equipment. [1]
Feel free to lift as needed.

Please have a good weekend,
Felix

[1] 
https://codeberg.org/lechner/system-config/src/commit/b566b08a982a12f896cd6ef7849dbac0ce2e/host/wallace-server/operating-system.scm#L640-L658

Re: issues.guix.gnu.org seems stop updating

[Maxim Cournoyer]

Hello,

Andy Tai  writes:

> https://issues.guix.gnu.org/recent, for example, only shows issues up to Dec 
> 6.
>
> Not sure if this is due to some data services stopping running or such...

Perhaps the machine was restarted and the manual rsync job not
restarted?  We still don't have a service for it (bug #59180).

CC'ing Ricardo, who is typically the person restarting that job
manually.

-- 
Thanks,
Maxim

Re: issues.guix.gnu.org seems stop updating

[Development of GNU Guix and the GNU System distribution.]

Hi,

On Fri, Dec 08 2023, Andy Tai wrote:

> https://issues.guix.gnu.org/recent, for example, only shows issues up
> to Dec 6.

This is an rsync problem:

2023-12-08 09:46:00 14696 Rsync debbugs data: rsync: [Receiver] failed to 
connect to debbugs.gnu.org (209.51.188.43): Connection refused (111)

I believe the FSF folks are working on it.

Kind regards
Felix

issues.guix.gnu.org seems stop updating

[Andy Tai]

https://issues.guix.gnu.org/recent, for example, only shows issues up to Dec 6.

Not sure if this is due to some data services stopping running or such...

Re: problems installing on LUKS2 encrypted device

[Kaelyn]

Hi Gio,

On Friday, December 8th, 2023 at 9:34 AM, Giovanni Biscuolo  
wrote:

> 
> Hello,
> 
> I've noticed that the last released system installer [1], when using the
> guided install workflow, is using a LUKS1 encryption; since I would like
> to install on a LUKS2 encrypted root filesystem I tried to "manually"
> install following the instructions in the manual [2].
> 
> When using a LUKS2 encryption format [3], completing the installation
> and rebooting, I get an error from Grub: it cannot find the encrypted
> volume, it's trying to open the /unencrypted/ volume instead (via UUID),
> child of the LUKS2 encrypted one.
> 
> If I just change the type of encryption to "luks1" in [3], the booting
> of the installed machine works as expected.
> 
> Since I know that the LUKS2 support in Grub was not available when Guix
> 1.4 was released, I also tried to "guix pull && hash guix" /before/
> installing with "guix system init /mnt/etc/config.scm /mnt", but the
> error was the same.
> 
> I still have not tried to build an updated system installation image to
> see if it is working.
> 
> Since the (stable) manual provides instructions on how to install Guix
> System on a LUKS2 encrypted partition [4], I'd like to understand if I'm
> doing something wrong or there is a bug, at least in the manual.

About halfway through the email, your use of LUKS2 with Grub was tickling my 
brain about what I remembered reading regarding Grub's LUKS2 support being 
limited. While searching for references for that--and subsequently seeing that 
you were already using PBKDF2--I came across 
https://savannah.gnu.org/bugs/?55093 which seems to hold the answer. According 
to the newest comment, Grub 2.06 has a seemingly-undocumented additional 
requirement for working with LUKS2 of needing to use sha256 as the keyslot hash.

Additionally, https://wiki.archlinux.org/title/GRUB#LUKS2 suggests that Grub 
2.06 requires manually creating an EFI binary using grub-mkimage (with 
grub-install once again being sufficient in 2.12rc1), though I don't know if 
the Guix bootloader machinery addresses that shortcoming or not.

Please take the above with a grain of salt, as I have only ever used LUKS1 with 
Grub (and I've recently started moving away from Grub). HTH!

Cheers,
Kaelyn

> I'm attaching the script I'm using for the "manual" installation: if I
> set "luks2" in the "cryptsetup luksFormat..." command /and/ uncomment
> the "guix pull && hash guix" commands, the installation provides an
> unbootable system.
> 
> Sorry for the "short story made long" but my script it's a proof of
> concept to allow installing a Guix System starting from any (recent)
> rescue system (tested only with a Guix install image and a systemd
> rescue system, grml), that's why is so "long":
> 
> 
> 
> Thanks! Gio'
> 
> [1] https://ftp.gnu.org/gnu/guix/guix-system-install-1.4.0.-linux.iso
> 
> 
> [2] https://guix.gnu.org/en/manual/en/html_node/Manual-Installation.html
> 
> [3] cryptsetup luksFormat --type luks2 --pbkdf pbkdf2 /dev/sdaX
> 
> [4] 
> https://guix.gnu.org/en/manual/en/html_node/Keyboard-Layout-and-Networking-and-Partitioning.html
> 
> --
> Giovanni Biscuolo
> 
> Xelera IT Infrastructures

Re: RFI: Guix XMPP service.

[MSavoritias]

On 12/8/23 20:43, Vivien Kraus wrote:

Hello Guix!

Le vendredi 08 décembre 2023 à 19:22 +0200, MSavoritias a écrit :

I propose to host an xmpp instance with a room/or some rooms under
the
guix domain. Something like xmpp.guix.gnu.org

Are there options for guests?

I don’t know how XMPP or Prosody or cheogram.com may handle this, but
the way I imagine it, we could have an array of guest accounts and
reserve one for anyone that would ask for it, for something like a
week. The guest accounts need not communicate with another server, so
we wouldn’t relay spam.

Maybe there’s something more convenient or more standard though. What
do you think?

Best regards,

Vivien



yes it does. from the page I linked it says:

Once configuration is complete, your chatroom will be accessible to 
anyone on the XMPP federation, as well as on the web via 
anonymous.cheogram.com .


You basically enter the address of the group chat you want and a 
nickname and you chat without an account. but only in the rooms in the 
guix server of course. same as IRC.



MSavoritias

Re: RFI: Guix XMPP service.

[Vivien Kraus]

Hello Guix!

Le vendredi 08 décembre 2023 à 19:22 +0200, MSavoritias a écrit :
> I propose to host an xmpp instance with a room/or some rooms under
> the 
> guix domain. Something like xmpp.guix.gnu.org

Are there options for guests? 

I don’t know how XMPP or Prosody or cheogram.com may handle this, but
the way I imagine it, we could have an array of guest accounts and
reserve one for anyone that would ask for it, for something like a
week. The guest accounts need not communicate with another server, so
we wouldn’t relay spam.

Maybe there’s something more convenient or more standard though. What
do you think?

Best regards,

Vivien

Re: Moment de convivialité Guix@Paris en nov… euh… décembre

[Simon Tournier]

salut,

On Fri, 08 Dec 2023 at 08:45, Tanguy LE CARROUR  wrote:

> Rendez-vous début janvier (sûrement le 11, à confirmer) pour la
> prochaine !

Avec des stickers si je ne les oublie pas à nouveau. ;-)

Chouette soirée !

à tantôt,
simon

Re: Doing away with CentOS 6 support (Linux faux-2.6)?

[Simon Tournier]

Hi,

On Thu, 07 Dec 2023 at 23:46, Ludovic Courtès  wrote:

> Back in 2018, this was deemed important for HPC clusters, where CentOS 6
> was then relatively common, as Ricardo explained:

Héhé!  A colleague re-installed CentOS 6 this week; for testing
purpose.  Hum… :-)

> Five years later, it seems reasonable to drop the patch (which is likely
> untested these days).  If you disagree, now’s the time to make your
> voice heard!

Yeah, let drop this patch.  Well, CentOS 7 will be soon end of life so
it seems very reasonable to drop patches for CentOS 6 only.

Cheers,
simon

Re: Moment de convivialité Guix@Paris en nov… euh… décembre

[Simon Tournier]

salut Édouard,

Chouette présentation !  Je pense que cela pourrait sympa de partager
ton canal. :-)

à tantôt,
simon

Re: GNU Mes 0.26 released

[Simon Tournier]

Hi Janneke,

On Sun, 03 Dec 2023 at 13:50, Janneke Nieuwenhuizen  wrote:

> We are happy to announce the release of GNU Mes 0.26.

Cool!

A naive question. :-)  I was randomly roaming and I have seen, for
example, in file module/mescc/x86_64/as.scm:

--8<---cut here---start->8---
;; AMD
(define (x86_64:function-preamble info . rest)
  `(("push___%rbp")
("mov%rsp,%rbp")
("sub$i32,%rbp" "%0x80")
,@(list-head
   '(("mov%rdi,0x8(%rbp)" "!0x10")
 ("mov%rsi,0x8(%rbp)" "!0x18")
 ("mov%rdx,0x8(%rbp)" "!0x20")
 ("mov%rcx,0x8(%rbp)" "!0x28")
 ("mov%r8,0x8(%rbp)" "!0x30")
 ("mov%r9,0x8(%rbp)" "!0x38"))
   (length (car rest)

;; traditional
(define (x86_64:function-preamble info . rest)
  `(("push___%rbp")
("mov%rsp,%rbp")))
--8<---cut here---end--->8---

And my question is: the procedure name is exactly the same therefore how
is the correct one picked?


Thanks for all this!

Cheers,
simon

Re: What's the difference between a shell environment and a profile?

[Simon Tournier]

Hi Konrad,

On Fri, 08 Dec 2023 at 17:24, Konrad Hinsen  wrote:

> First, I tested some Python 2 scripts in a shell environment:
>
> guix time-machine -C ./channels.scm \
> -- shell --container \
>python2 python2-mmtk python2-matplotlib \
>--with-input=python2-numpy=python2-numpy@1.8.2 \
>-- python
>
> Works fine. Next, I wanted to create a Guix profile with the same
> software, mainly to keep it in the store for long-term future use,
> surviving garbage collection:
>
> guix time-machine -C ./channels.scm \
> -- package -p ./python2-profile \
>-i python2 python2-mmtk python2-matplotlib \
>--with-input=python2-numpy=python2-numpy@1.8.2
>
> Guix wasn't happy at all with this:

Guix is not happy with ’shell’ but pass silently the collision; from my
understanding.

Somehow, then the Python script works but by chance, I guess.


>   guix package: error: profile contains conflicting entries for glib
>   guix package: error:   first entry: glib@2.70.2 
> /gnu/store/64bdjb3nwdkadmy5z2wph9cgqr0bwijm-glib-2.70.2
>   guix package: error:... propagated from cairo@1.16.0
>   guix package: error:... propagated from python2-pycairo@1.18.2
>   guix package: error:... propagated from python2-matplotlib@2.2.5
>   guix package: error:   second entry: glib@2.73.3 
> /gnu/store/kf488k7v0lc48ylbs4xxpam0dbl3r4jl-glib-2.73.3
>   guix package: error:... propagated from gobject-introspection@1.73.1
>   guix package: error:... propagated from python2-matplotlib@2.2.5
>   hint: You cannot have two different versions or variants of 
> `python2-matplotlib' in
> the same profile.
>
> In the end I did:
>
> guix time-machine -C ./channels.scm \
> -- shell --container -r ./python2-profile \
>python2 python2-mmtk python2-matplotlib \
>--with-input=python2-numpy=python2-numpy@1.8.2 \
>-- python
>
> which should have the effect I am looking for, but I don't understand
> how this differs from the "guix package" attempt that failed. The
> difference seems to be related to the –with-input transform, because
> I don't see what else could cause the "two different versions of
> python2-matplotlib" to be around.

It does not differ.  What differs is that “guix shell” raises nothing
for the collision – maybe “guix shell” does not check the collision, I
do not remember – when “guix package” raises an error for the same
collision.

Well, since it is a past Guix revision provided by the file
channels.scm, I do not know if this collision could now be fixed.

Cheers,
simon

problems installing on LUKS2 encrypted device

[Giovanni Biscuolo]

Hello,

I've noticed that the last released system installer [1], when using the
guided install workflow, is using a LUKS1 encryption; since I would like
to install on a LUKS2 encrypted root filesystem I tried to "manually"
install following the instructions in the manual [2].

When using a LUKS2 encryption format [3], completing the installation
and rebooting, I get an error from Grub: it cannot find the encrypted
volume, it's trying to open the /unencrypted/ volume instead (via UUID),
child of the LUKS2 encrypted one.

If I just change the type of encryption to "luks1" in [3], the booting
of the installed machine works as expected.

Since I know that the LUKS2 support in Grub was not available when Guix
1.4 was released, I also tried to "guix pull && hash guix" /before/
installing with "guix system init /mnt/etc/config.scm /mnt", but the
error was the same.

I still have not tried to build an updated system installation image to
see if it is working.

Since the (stable) manual provides instructions on how to install Guix
System on a LUKS2 encrypted partition [4], I'd like to understand if I'm
doing something wrong or there is a bug, at least in the manual.

I'm attaching the script I'm using for the "manual" installation: if I
set "luks2" in the "cryptsetup luksFormat..." command /and/ uncomment
the "guix pull && hash guix" commands, the installation provides an
unbootable system.

Sorry for the "short story made long" but my script it's a proof of
concept to allow installing a Guix System starting from any (recent)
rescue system (tested only with a Guix install image and a systemd
rescue system, grml), that's why is so "long":

#!/bin/sh
# Copyright © 2023 Giovanni Biscuolo 
#
# bootstrap-guix.sh is free software; you can redistribute it and/or
# modify it under the terms of the GNU General Public License as
# published by the Free Software Foundation; either version 3 of the
# License, or (at your option) any later version.
#
# bootstrap-guix.sh is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
# General Public License for more details.
#
# A copy of the GNU General Public License is available at
# .

# bootstrap-guix.sh is a very opinionated script to install Guix
# System on a host booted in "rescue" mode.
#
# The system is installed on a single disk BTRFS filesystem on a LUKS
# encrypted partition.

# -
# Variables

# Disks
# TODO: transform this in array TARGET_DISKS[TARGET_NUMDISKS], for multi disk setups
export TARGET_NUMDISKS=1
export TARGET_DISK_PART_SUFFIX=""
export TARGET_DISK1="/dev/sda"
export TARGET_SWAP_SIZE="16GB"

# Hostname
export TARGET_HOSTNAME="pioche"

# User and pub key (only one admin user for basic installation)
export TARGET_USERNAME="g"
export TARGET_USERGECOS="Giovanni Biscuolo"
export TARGET_USERKEY="ssh-ed25519 C3NzaC1lZDI1NTE5ICqpr0unFxPo2PnQTmmO2dIUEECsCL3vVvjhk5Dx80Yb g...@xelera.eu"

# ###
# DO NOT EDIT this variables
# unless for debugging

# (minimal) OS configuration file name
export OS_CONFIG_FILE="bootstrap-config.scm"

# Target OS mount point
export TARGET_MOUNTPOINT="/mnt/guix"

# Source os-release information
test -e /etc/os-release && os_release='/etc/os-release' || os_release='/usr/lib/os-release'
. "${os_release}"
echo "### INFO - Detected GNU/Linux distribution: ${PRETTY_NAME}."

# -
# Prepare the target system filesystem

# Wipe the disks
# TODO: use the array TARGET_DISKS[]
echo "### START - Wiping disks."
wipefs -af ${TARGET_DISK1}*
echo "### STOP - Wiping disks."

# Partition the disks
# FIXME: detect if on EFI platform looking at /sys/firmware/efi and
# perform disk partitioning and filesystem formatting accordingly

## Disk 1
echo "### START - partitioning ${TARGET_DISK1}."
parted ${TARGET_DISK1} --align=opt -s -m -- mklabel gpt
# BIOS grub system partition
parted ${TARGET_DISK1} --align=opt -s -m -- \
   mkpart grub 1MiB 5MiB \
   name 1 grub-1 \
   set 1 bios_grub on
# partition p2 will be swap
parted ${TARGET_DISK1} --align=opt -s -m -- \
   mkpart linux-swap 5MiB ${TARGET_SWAP_SIZE} \
   name 2 swap-1
# partition p3 will be LUKS encrypted device
parted ${TARGET_DISK1} --align=opt -s -m -- \
   mkpart ext4 ${TARGET_SWAP_SIZE} 100% \
   name 3 luks-1
echo "### END - partitioning ${TARGET_DISK1}."

# Create LUKS device on encrypted partition, backup LUKS header and open it
echo "### START - Making encrypted ${TARGET_DISK1}${TARGET_DISK_PART_SUFFIX}3."
# FIXME: LUKS2 non supported?
# cryptsetup luksFormat --type luks2 --pbkdf pbkdf2 ${TARGET_DISK1}${TARGET_DISK_PART_SUFFIX}3
cryptsetup luksFormat --type luks1 ${TARGET_DISK1}${TARGET_DISK_PART_SUFFIX}3
cryptsetup luksHeaderBackup 

RFI: Guix XMPP service.

[MSavoritias]

Hello o/


I would like to do a formal proposal to make an official Guix XMPP instance.


Background:

I asked a couple of days ago if it would be possible to have an XMPP 
room listed on the Guix site next to the IRC. I also asked in IRC and 
shared it on ActivityPub.


The response was very enthusiastic, thank you everyone for joining and 
spreading the message. ^^


It was said though that listing it on the website would make it 
official, plus some other concerns around log retention. Hence this 
proposal here. :)


For those that do not know XMPP is a protocol for many things, one of 
them being messaging. It has been active for more than 20 years now and 
is still being developed.



Who am I:

I have been around Guix for a bit in IRC and the email lists. I also do 
some small advocacy for Guix in ActivityPub federation (Mastodon, 
Peertube, etc.).


I am maintaining the infrastructure for https://joinjabber.org/ which is 
moving to Guix currently -> https://codeberg.org/joinjabber/Infra :) and 
I am a member of XSF.


I also do a lot of advocacy for xmpp in activitypub and handle the 
activitypub presence of joinjabber. -> @joinjabber@indieweb.social



What is being proposed:

I propose to host an xmpp instance with a room/or some rooms under the 
guix domain. Something like xmpp.guix.gnu.org


This can be done in one of two ways:

1. There is a service here -> https://cheogram.com/freedomware-muc/ 
hosted by https://soprani.ca/


 We can just setup our DNS to point to the service and sopranica will 
take care of the xmpp server.


I have talked with them and they do have unlimited retention of past 
messages plus they can also setup a log viewing thing just like IRC has.


Its a sustainable free software business and the hosting will be free. :)

2. We can self host our own prosody instance. It has minimal 
maintenance, and its very lightweight.


I can maintain the instance as it is done for joinjabber and we already 
have a guix service for prosody.



Why / What does Guix get from this:

Right now guix has email lists and IRC. What XMPP can give on top of 
that is:


1. XMPP is more approachable for people used to Matrix or Discord (for 
multiple reasons). While still being very lightweight and free software.


2. It is federated and easily self hosted. Which makes Guix more 
independent in case something like Freenode ever happens to Libera chat 
or in case people want to have their own server to connect to the guix 
rooms.



Personally I am in favor of option 1. We can host it in the cheogram 
service to test things out and if we need to we can self host it later. 
Since It will point to the same domain it shouldn't be a problem.


All we would need to do is change where our DNS points to and that's it.


MSavoritias

Re: Should commits rather be buildable or small

[Development of GNU Guix and the GNU System distribution.]

Hi,

On Fri, Dec 08 2023, Lars-Dominik Braun wrote:

> I’ve been updating Haskell packages in bulk in a single commit.

Making logically related commits was always my custom before arriving at
Guix. I still do so in all of my own projects.

The preference at Guix, however, is to split even mundane changes into
the tiniest parts possible---each affecting ideally only a single file.

The custom seems to be driven by concerns for the GNU ChangeLog, which
is generated automatically from the Git commit messages.

Kind regards
Felix

What's the difference between a shell environment and a profile?

[Konrad Hinsen]

Hi Guix experts,

While doing some software archeology, I ran into a behavior that I don't
quit understand.

First, I tested some Python 2 scripts in a shell environment:

guix time-machine -C ./channels.scm \
-- shell --container \
   python2 python2-mmtk python2-matplotlib \
   --with-input=python2-numpy=python2-numpy@1.8.2 \
   -- python

Works fine. Next, I wanted to create a Guix profile with the same
software, mainly to keep it in the store for long-term future use,
surviving garbage collection:

guix time-machine -C ./channels.scm \
-- package -p ./python2-profile \
   -i python2 python2-mmtk python2-matplotlib \
   --with-input=python2-numpy=python2-numpy@1.8.2

Guix wasn't happy at all with this:

  guix package: warning: Consider running 'guix pull' followed by
  'guix package -u' to get up-to-date packages and security updates.

  The following packages will be installed:
 python22.7.18
 python2-matplotlib 2.2.5
 python2-mmtk   2.7.13

  guix package: error: profile contains conflicting entries for glib
  guix package: error:   first entry: glib@2.70.2 
/gnu/store/64bdjb3nwdkadmy5z2wph9cgqr0bwijm-glib-2.70.2
  guix package: error:... propagated from cairo@1.16.0
  guix package: error:... propagated from python2-pycairo@1.18.2
  guix package: error:... propagated from python2-matplotlib@2.2.5
  guix package: error:   second entry: glib@2.73.3 
/gnu/store/kf488k7v0lc48ylbs4xxpam0dbl3r4jl-glib-2.73.3
  guix package: error:... propagated from gobject-introspection@1.73.1
  guix package: error:... propagated from python2-matplotlib@2.2.5
  hint: You cannot have two different versions or variants of 
`python2-matplotlib' in
the same profile.

In the end I did:

guix time-machine -C ./channels.scm \
-- shell --container -r ./python2-profile \
   python2 python2-mmtk python2-matplotlib \
   --with-input=python2-numpy=python2-numpy@1.8.2 \
   -- python

which should have the effect I am looking for, but I don't understand
how this differs from the "guix package" attempt that failed. The
difference seems to be related to the –with-input transform, because
I don't see what else could cause the "two different versions of
python2-matplotlib" to be around.

Any ideas?

Cheers,
  Konrad

Re: Should commits rather be buildable or small

[Liliana Marie Prikler]

Hi Saku,

Am Freitag, dem 08.12.2023 um 10:42 +0200 schrieb Saku Laesvuori:
> Hi,
> 
> I'm planning on refreshing Guix's haskell packages as my fix for
> https://issues.guix.gnu.org/66347 requires rebuilding all of them
> anyway. Should I try to keep commits small with only one update per
> commit (which is more work but managable if I don't care about the
> commits being buildable) or should I try to keep them buildable (i.e.
> update everything in one commit)? It is quite certain that most of
> them will not build after updating ghc or a subset of their
> dependencies, so making many small commits would cause nearly all of
> them to be unbuildable.
Define "buildable" and "unbuildable".  Depending on the context, it may
be fine or even required to break dependant packages for a short while
and update them along a longer series.  However, in each commit at
least the package touched in that commit ought to build.

Cheers

shepherd: hardening error handling

[Attila Lendvai]

dear Guix,

i'm working on hardening shepherd's error handling and logging to debug an 
issue that i'm facing. these changes escalated quickly, so i'm writing to 
clarify a few things before i shape the codebase into a direction that the 
maintainers will not accept.

the codebase seems to use catch/throw, and at some places with comments like 
"for Guile 2.2". what is the minimum guile version that the shepherd codebase 
wants to support? the README says "GNU Guile 3.0.x or 2.2.x". is this still 
intended? or can i assume guile 3? i.e. use with-exception-handler, 
raise-exception, guard,  instead of catch/throw with key and args?

some WIP commits are available at:

https://codeberg.org/attila-lendvai-patches/shepherd/commits/branch/attila

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“It is only when the people become ignorant and corrupt, when they degenerate 
into a populace, that they are incapable of exercising the sovereignty. 
Usurpation is then an easy attainment, and an usurper soon found. The people 
themselves become the willing instruments of their own debasement and ruin.”
— James Monroe (1758–1831), 5th president of the USA

Re: Should commits rather be buildable or small

[Lars-Dominik Braun]

Hi,

> I'm planning on refreshing Guix's haskell packages as my fix for
> https://issues.guix.gnu.org/66347 requires rebuilding all of them
> anyway. Should I try to keep commits small with only one update per
> commit (which is more work but managable if I don't care about the
> commits being buildable) or should I try to keep them buildable (i.e.
> update everything in one commit)?

so far I’ve been updating Haskell packages in bulk in a
single commit. See 49a320aaa6fb4c20d6b30c56c35a8c7ffceed822 or
b97f549b14402421fcfb360ddd4cff7de93b9af0 for example. I also used custom
scripts last time, because `guix refresh` was not sufficient to update
all fields required (arguments, inputs, …). This is hopefully different
this time.

Cheers,
Lars

Re: Should commits rather be buildable or small

[Tomas Volf]

On 2023-12-08 10:42:07 +0200, Saku Laesvuori wrote:
> Hi,
>
> I'm planning on refreshing Guix's haskell packages as my fix for
> https://issues.guix.gnu.org/66347 requires rebuilding all of them
> anyway. Should I try to keep commits small with only one update per
> commit (which is more work but managable if I don't care about the
> commits being buildable) or should I try to keep them buildable (i.e.
> update everything in one commit)? It is quite certain that most of them
> will not build after updating ghc or a subset of their dependencies, so
> making many small commits would cause nearly all of them to be
> unbuildable.

If for not other reason then to make git history bisectable, I think each commit
should be buildable.  But this is just a opinion from the peanut gallery.

Tomas

--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.


signature.asc
Description: PGP signature

Re: Moment de convivialité Guix@Paris en nov… euh… décembre

[Edouard Klein]

Merci d'avoir organisé tout ça :)
Tanguy LE CARROUR  writes:

> Bonjour Guix,
>
> Merci à ceux qui ont bravé les intempéries et les transports parisiens
> pour venir hier soir ! Et, surtout merci à ceux qui, présents ou à
> distance, on partagé leur travail, leurs découvertes ou leurs problèmes,
> et ont contribué à faire de cette soirée un moment très… convivial ! 
>
> Rendez-vous début janvier (sûrement le 11, à confirmer) pour la
> prochaine !
>
> En attendant, je vous souhaite à tou·tes une excellente journée, fin de
> semaine et… fin d'année !

Should commits rather be buildable or small

[Saku Laesvuori]

Hi,

I'm planning on refreshing Guix's haskell packages as my fix for
https://issues.guix.gnu.org/66347 requires rebuilding all of them
anyway. Should I try to keep commits small with only one update per
commit (which is more work but managable if I don't care about the
commits being buildable) or should I try to keep them buildable (i.e.
update everything in one commit)? It is quite certain that most of them
will not build after updating ghc or a subset of their dependencies, so
making many small commits would cause nearly all of them to be
unbuildable.


signature.asc
Description: PGP signature