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 g
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