Re: Welcome to Jorge Gomez (jgart) as a new Guix committer
> I'd like to welcome Jorge as a new Guix committer! Jorge has been > around for some time already, and is always very active around the Guix > community; I'm sure they'll know to use their new privilege in a way > that benefits the Guix community! Hi Maxim, Thanks for the warm welcome. It is much appreciated. I look forward to continuing to push our efforts forward as a group. I also want to thank everyone who has reviewed and merged my patches in the past and I look forward to now returning the help to others. all best, jgart ps I also made a statement about my commit access grant here: https://lists.gnu.org/archive/html/guix-devel/2023-05/msg00202.html
Commit Access: jgart
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Guixers, Thanks for granting me commit access. I'm looking forward to helping out with patch review, with a particular focus on moving patches along for the Python team. I also intend to continue contributing more packages, updates, and improvements. Thanks again for granting me the privilege of commit access and I am looking forward to continuing our collaborations. all best, jgart (Jorge Gomez) -BEGIN PGP SIGNATURE- Version: OpenPGP.js v2.6.2 Comment: https://openpgpjs.org wsFcBAEBCAAQBQJkYunxCRClKqK0d7bdNQAAyVYQALssKAaeBc5flQqs2IA0 3a/+014O15GvwceZXx+eoPjO6yNwouHQ8h8zZmCLZIcjVLfTEQci6NVpDJhR 0sZ4dYV7Glncv2KcFGqucTEoHmmzEQbCOaUjT2fH0j+eTadOdgzIMuhqbLAH /DNUzjlzEkIaDoyuSZodOZC3EMs1fiZaNqn70BJ/Ticl3NntB5OIWDUdiaeu ZHb0O8iaqJM0lniyYBAwVtLXXNIoVYmU0TkXp8sQtrj6bwXPcBD+PMv4YrxH 8PpKfy6/sDAsNQyy4hnRADAIAGhbGFfCzpDFtfJWWcIQpGiGO00XyD2Zjbtw icKBAx+VI6T8b48K+9rcoUngL/X8r+PoH8bFuf+rUKq4wbNdI0638pB78TUt okWhWAiR/DWMv3VTafFBkU8D4uL1Xto1vYAuuSfXJ/Ze2p/VLCKyp5cOE4o3 il7Lc+Fjcmoq1ptZ2rsp1EmdvQWROSLBcxt2mBsLhMa3v5mP//yFuLaOkMEe /IAHdpfrggwZWdayZQL06V3g3H/K37rpW1R/wZa5CdS2X6WHtkqFeJl02FIT x0cJAZdRi6tA2Hhr/qgsFaMoXvbBml8S50F7WT+UxyUiaoo2wtI69At/w0P1 MIVlEu19U1cmidjA9D4du/g5T+X7DZgRwl4BhucHNq5GGhSduASXZGOask+Y Q6FL =Mfmz -END PGP SIGNATURE-
Welcome to Jorge Gomez (jgart) as a new Guix committer
Hi Guix, I'd like to welcome Jorge as a new Guix committer! Jorge has been around for some time already, and is always very active around the Guix community; I'm sure they'll know to use their new privilege in a way that benefits the Guix community! Cheers! -- Maxim
Re: Search box on packages.g.g.o
Felix Lechner via "Development of GNU Guix and the GNU System distribution." writes: > Typing "smart" into the search box on packages.guix.gnu.org does not > find 'smartmontools'. Why might that be, please? The packages.guix.gnu.org search uses the data service search as a backend (this is the page [1]), and this is the relevant bit of the data service code for searching packages [2]. Since it doesn't show up in the results, the where condition isn't selecting it. 1: https://data.guix.gnu.org/repository/1/branch/master/latest-processed-revision/packages 2: https://git.savannah.gnu.org/cgit/guix/data-service.git/tree/guix-data-service/model/package.scm#n144 signature.asc Description: PGP signature
Search box on packages.g.g.o
Hi, Typing "smart" into the search box on packages.guix.gnu.org does not find 'smartmontools'. Why might that be, please? I'd like to send in a patch. Thanks for that great website! Kind regards Felix
Re: Housekeeping for disk-related packaging
Pursuant to private encouragement, I went ahead and filed https://issues.guix.gnu.org/63525 Thanks!
Re: What's needed to get things building for i586-gnu (the hurd) post core-updates?
On Mon, May 15, 2023 at 06:46:17PM +0200, Josselin Poiret wrote:
> Hi Efraim,
>
> Efraim Flashner writes:
> > If all you need is to remove coreutils-boot0 from the origin then you
> > could create a similar boot0 package specifically for the hurd and make
> > the fix there, and then use the current package or your new one as an
> > input in later packages based on the architecture.
>
> Unfortunately, it is used in an origin snippet, and there you can't
> really case over the target system.
>
Let me clarify a bit:
Add gcc-boot0-hurd, but with the snippet using guile instead of
coreutils-boot0. Then in (%boot1-inputs) the code gets changed from
("gcc" ,gcc-boot0) to (untested)
("gcc" ,(if (target-hurd?)
gcc-boot0-hurd
gcc-boot0))
And then similarly through the rest of gnu/packages/commencement.
--
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: What's needed to get things building for i586-gnu (the hurd) post core-updates?
Hi Efraim, Efraim Flashner writes: > If all you need is to remove coreutils-boot0 from the origin then you > could create a similar boot0 package specifically for the hurd and make > the fix there, and then use the current package or your new one as an > input in later packages based on the architecture. Unfortunately, it is used in an origin snippet, and there you can't really case over the target system. Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: Defaulting to MAC-based names for network interfaces
On Sun, May 14, 2023 at 02:52:26PM -0700, Felix Lechner via Development of GNU
Guix and the GNU System distribution. wrote:
> Hi everyone,
>
> Upon personal reflection, a declarative operating system like Guix probably
> ought to use only predictable interface names.
>
> More details about this proposal, including the text below, are
> available in Bug#63508.
>
> While shorter names like 'eno1' offer an indisputable convenience and beauty
> when typing on the command line, administrators in Guix are unlikely to do so
> due to the declarative configuration system.
>
> Some system services may explicitly refer to interface names in their
> configuration. They would also benefit from the predictable and constant
> nature of MAC-based names.
>
> The latter is particularly relevant on multi-homed machines, i.e. those with
> more than one network connection.
>
> A MAC-based interface name as issued by 'eudev' looks like this:
>
> enx0123456789af (fictitious)
>
> The commit in Bug#63508 was deployed on two production machines. The
> migration to MAC-based interface names took place without issues. A
> second reconfiguration was used to add the new interface name in
> services tha needed it. The second step can be skipped, since the name
> is known with certainty in advance.
>
> The current naming scheme is less desirable because some services may silently
> refuse to start after equipment was added or removed. A removal may take
> place, for example, when something broke or when equipment was sold.
>
> The device enumeration may also change when a CMOS battery fails and system
> options are lost. In the author's option, Guix should not depend on BIOS
> enumeration for device names.
>
> In the author's case, the name of the sole network interface changed from
> enp3s0 to enp4s0 when a PCIe disk controller (a SAS host-based adapter) was
> installed. As a result, OpenSMTPd silently failed to start.
>
> This commit switches 'eudev' from the standard naming order
>
> ID_NET_NAME_ONBOARD
> ID_NET_NAME_SLOT
> ID_NET_NAME_PATH
>
> to ID_NET_NAME_MAC, which is always available. [1]
>
> The author initially attempted to achieve the same result via
>
> (udev-rules-service 'net-name-mac
> (udev-rule
> "01-net-name-mac.rules"
> "SUBSYSTEM==\"net\", ACTION==\"add\", NAME=\"$env{ID_NET_NAME_MAC}\"
> ")))
> but that did not work. While the situation was not examined exhaustively, it
> was not clear that udevadm can currently work because the standard command to
> test udev setups: [2]
>
> $ udevadm --debug test /sys/class/net/*
>
> did not find the script installed via the 'udev-service-type'.
I was curious about this, since I've been using a udev rule for quite a
while to setup zram swap. I definitely have my zram swap enabled and
working, but 'udevadm --debug test /dev/zram0' didn't find any rule for
zram.
> A review of the 'eudev' sources indicated that the path to find rules [3] is
> hard-coded to the store location during installation. An attempt to set the
> path to /etc/udev/rules.d yielded a build error because that target folder
> outside the store was understandably not writable.
>
> The manual page for udevadm did not offer a way to select the runtime location
> of the udev/rules.d folder via environment variables or a command-line option.
>
> Anyone for whom such a setup is working properly should please contact the
> author. Thank you!
/etc/udev points to /etc/static/udev, which itself is a symlink to a
combined udev item in the store, made up of all the udev rules installed
in the current system.
> This commit may result in some loss of privacy, although it is presently not
> clear how meaningful that is. With this commit, anyone using privacy-enhanced
> IPv6 addresses risks having their MAC exposed when they publish their
> configuration files in Git or post a well-meant sample in a chat rooms,
> because that configuration may mention the MAC address.
>
> Moreover, the compatibility with schemes to generate fake one-time MAC
> addresses upon boot should be evaluated. One concern is that the explicit
> reference to a network interface in a configuration file would likely force
> the use of a single and constant MAC address for that interface.
>
> This commit was tested in production and is currently being used.
>
> The change here resulted in the recompilation of several seemingly unrelated
> packages such as Emacs and GTK. Perhaps those dependency relationships should
> be examined.
>
> [1]
> https://wiki.debian.org/NetworkInterfaceNames#How_to_migrate_to_this_scheme_on_upgraded_systems
> [2] https://wiki.archlinux.org/title/Udev#Testing_rules_before_loading
> [3]
> https://github.com/eudev-project/eudev/blob/39979ddf46e75d1b75bf381e1c73914c226c4302/configure.ac#L180
> [4] https://en.wikipedia.org/wiki/IPv6_address#Temporary_addresses
>
--
Efraim Flashner רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be
Re: Discussion on Parameterized Packages
Hi, On jeu., 11 mai 2023 at 20:38, Sarthak Shah wrote: > https://blog.lispy.tech/2023/05/parameterized-packages.html > > I would really appreciate feedback on > (1) parameters you'd like to see in Guix > (2) the user interface for searching/installing/packaging with > parameters Just a quick remark. You are proposing something like: --8<---cut here---start->8--- 1 (define-public emacs 2(package 3 (parameters (and 4(optional jit^ png^ alsa^) 5(one-of motif gtk^ x11!*))) 6 (parameter-transforms 7((x11!) 8 (changes-to-be-made-to-the-package) --8<---cut here---end--->8--- or other variants. Well, I am a bit afraid by the maintenance of such packages. The combinatorial complexity will be exploding and it will be harder to update such packages, IMHO. Instead, I would go with something similar as ’package/inherit’. For instance, something like that: --8<---cut here---start->8--- (define-public emacs-params (package/parametrized emacs (parameters (and (optional jit^ png^ alsa^) (one-of motif gtk^ x11!*))) (parameter-transforms ((x11!) (changes-to-be-made-to-the-package) --8<---cut here---end--->8--- Well, from my point of view, these parametrized packages could go to specific modules (or channels). And keeping them separate would avoid nightmares about maintenance – it is already enough complex without parameters. :-) Cheers, simon
Re: Guidelines for pre-trained ML model weight binaries (Was re: Where should we put machine learning model parameters?)
Hi, On sam., 13 mai 2023 at 12:13, 宋文武 wrote: > Hello, zamfofex submited a package 'lc0', Leela Chess Zero” (a chess > engine) with ML model, also it turn out that we already had 'stockfish' > a similiar one with pre-trained model packaged. Does we reached a > conclusion (so lc0 can also be accepted)? Or should we remove 'stockfish'? Well, I do not know if we have reached a conclusion. From my point of view, both can be included *if* their licenses are compatible with Free Software – included the weights (pre-trained model) as licensed data. Cheers, simon
