Re: GNU Guix & GuixSD 0.16.0 released
Everyone, Ludovic Courtès wrote: We are pleased to announce the release of GNU Guix & GuixSD 0.16.0, representing 4,515 commits by 95 people over 5 months. Thank you, all 94 of you wonderful people, and all who commited other things than code. T G-R
Re: GuixSD on librem phone?
Hi Leo, Leo Famulari writes: [...] >> this also means we will _never_ be able to trust communications via >> baseband (2G, 3G... 5G), fortunately this can be fixed using a trusted >> _separated_ SoC and the very good work coming from the vast and smart >> FLOSS community [2] :-) > > ... but we can trust communications over cellular baseband. Already, we > have built many trustable communication systems over untrusted mediums > like the internet. This is the role of things like TLS, the Signal > double-ratchet, and PGP. you are right, I was a little bit cryptic but that was what I meant with "the very good work coming..." :-) and much more trustable communication is around the corner, soon on GNUnet :-D happy hacking! Giovanni -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
Re: GuixSD on librem phone?
On Thu, Dec 06, 2018 at 04:24:38PM +0100, Giovanni Biscuolo wrote: > callular (baseband) merits a dedicated chapter, since it seems > practically impossible *forever* to trust that chips... and that chips > are an important attack vector (Purism will use USB bus to separate > baseband from CPU) I agree, the situation is depressing... > this also means we will _never_ be able to trust communications via > baseband (2G, 3G... 5G), fortunately this can be fixed using a trusted > _separated_ SoC and the very good work coming from the vast and smart > FLOSS community [2] :-) ... but we can trust communications over cellular baseband. Already, we have built many trustable communication systems over untrusted mediums like the internet. This is the role of things like TLS, the Signal double-ratchet, and PGP. signature.asc Description: PGP signature
Re: Octave & QtOctave
Kei Kebreau writes:
> Alex Vong writes:
>
>> Kei Kebreau writes:
>>
>>> Alex Vong writes:
>>>
Hello Kei,
Kei Kebreau writes:
[...]
>
> Here are two tentative patches that make the changes we've discussed.
> Also, should we make a deprecated-package definition for qtoctave?
I think some additional changes related to "(assoc-ref inputs ..."
needed to be made. Otherwise, looks good to me! Here is a patch I made
earlier but it was not tested, feel free to cherry-pick what is needed:
From 2b04caa66c17da257dfb4f4ccb94e8d629b95e53 Mon Sep 17 00:00:00 2001
From: Alex Vong
Date: Mon, 3 Dec 2018 03:39:40 +0800
Subject: [PATCH] gnu: Rename "octave" to "octave-cli" and "qtoctave" to
"octave".
* gnu/packages/maths.scm (octave): Rename to octave-cli.
[name]: Change to "octave-cli".
(qtoctave): Rename to octave.
[name]: Change to "octave".
[inherit]: Inherit from octave-cli.
[source]: Likewise.
[inputs]: Likewise.
[native-inputs]: Likewise.
[arguments]: Likewise.
(flann): Update accordingly.
* gnu/packages/engineering.scm (qucs): Likewise.
(qucs-s): Likewise.
* gnu/packages/machine-learning.scm (shogun): Likewise.
>>>
>>> ...
>>>
- ("octave" ,octave)
+ ("octave-cli" ,octave-cli)
>>>
>>> I see the main difference is that you've replace the package's
>>> associated string to "octave-cli" as well as the name, whereas I've only
>>> replaced the package name. Should I replace the associated package
>>> string, too?
>>
>> According to the manual "6.7.2 Package Naming", the associated string is
>> used for package management commands such as 'guix package' and 'guix
>> build'. Therefore, I think we should change them as well, so that the
>> users can install the packages using the command
>> "guix package -i octave-cli" and "guix package -i octave"
>> respectively. What do you think?
>
> Maybe this is true when manipulating the package definition, but that
> doesn't seem to be the case in general. When I run
> "./pre-inst-env guix package --show=shogun", for example,
> "octave-cli@4.4.1" is listed as a dependency, even though "octave" is
> the associated name in shogun's input list.
>
> To be clear, I've changed the string for octave's and octave-cli's
> package name in their respective package definitions, but I haven't
> changed the string in the input lists of octave-cli's dependent
> packages.
>
> I'm inclined to follow convention when it comes to this, and other
> packages in input lists seem to omit extensions to the base name of the
> package in their assoc-lists. For example, ("gettext", gettext-minimal)
> and ("python", python-minimal-wrapper) are common inputs for packages.
I think you are right! This was a misunderstanding on my part. I thought
the association string in the input lists must be the same as the
package name, but appraently this is not the case.
Take gettext-minimal as an example,
its variable name is 'gettext-minimal',
its package name is "gettext-minimal",
but its input name is "gettext".
signature.asc
Description: PGP signature
Re: GNU Guix & GuixSD 0.16.0 released
Fantastic!!! -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
GNU Guix & GuixSD 0.16.0 released
We are pleased to announce the release of GNU Guix & GuixSD 0.16.0, representing 4,515 commits by 95 people over 5 months. This is hopefully the last release before 1.0. • About GNU Guix is a transactional package manager for the GNU system. The Guix System Distribution, GuixSD, is an advanced distribution of the GNU system. In addition to standard package management features, Guix supports transactional upgrades and roll-backs, unprivileged package management, and per-user profiles. GuixSD offers a declarative approach to operating system configuration management and is highly hackable. Guix uses low-level mechanisms from the Nix package manager, except that packages are defined as native Guile modules, using extensions to the Scheme language. GuixSD uses the Linux-Libre kernel and the GNU Shepherd init system. It can be used on an i686, x86_64, armv7, or aarch64 machine. It is also possible to use Guix on top of an already installed GNU/Linux system, including on armv7, aarch64, and mips64el. https://www.gnu.org/software/guix/ • Download Here are the compressed sources and a GPG detached signature[*]: https://alpha.gnu.org/gnu/guix/guix-0.16.0.tar.gz https://alpha.gnu.org/gnu/guix/guix-0.16.0.tar.gz.sig Here are the bootable USB installation images and their signatures[*]: https://alpha.gnu.org/gnu/guix/guixsd-install-0.16.0.i686-linux.iso.xz https://alpha.gnu.org/gnu/guix/guixsd-install-0.16.0.i686-linux.iso.xz.sig https://alpha.gnu.org/gnu/guix/guixsd-install-0.16.0.x86_64-linux.iso.xz https://alpha.gnu.org/gnu/guix/guixsd-install-0.16.0.x86_64-linux.iso.xz.sig Here is the QCOW2 virtual machine (VM) image and its signature: https://alpha.gnu.org/gnu/guix/guixsd-vm-image-0.16.0.x86_64-linux.xz https://alpha.gnu.org/gnu/guix/guixsd-vm-image-0.16.0.x86_64-linux.xz.sig Here are the binary tarballs and their signatures[*]: https://alpha.gnu.org/gnu/guix/guix-binary-0.16.0.i686-linux.tar.xz https://alpha.gnu.org/gnu/guix/guix-binary-0.16.0.i686-linux.tar.xz.sig https://alpha.gnu.org/gnu/guix/guix-binary-0.16.0.x86_64-linux.tar.xz https://alpha.gnu.org/gnu/guix/guix-binary-0.16.0.x86_64-linux.tar.xz.sig https://alpha.gnu.org/gnu/guix/guix-binary-0.16.0.armhf-linux.tar.xz https://alpha.gnu.org/gnu/guix/guix-binary-0.16.0.armhf-linux.tar.xz.sig https://alpha.gnu.org/gnu/guix/guix-binary-0.16.0.aarch64-linux.tar.xz https://alpha.gnu.org/gnu/guix/guix-binary-0.16.0.aarch64-linux.tar.xz.sig Use a mirror for higher download bandwidth: http://www.gnu.org/order/ftp.html Here are the SHA1 checksums: 62f665dc02ea4c575f75b6728d6ec62875206846 guix-0.16.0.tar.gz ae4ded76633ff0d37c5297f457542cee2e6ee205 guix-0.16.0.tar.gz.sig e035d1f977d8d5fc12f405efaadfca88d8c6cb14 guix-binary-0.16.0.aarch64-linux.tar.xz a6edd77819695afe86d9c4c82bd4cba676bc3677 guix-binary-0.16.0.aarch64-linux.tar.xz.sig 99ac67458c91859fdfe7b74c7ef23abd9c735c9b guix-binary-0.16.0.armhf-linux.tar.xz b03daba12302e0af19375c99734dd9bbd560616c guix-binary-0.16.0.armhf-linux.tar.xz.sig bc6bee2f3bbeb36e70a61fb0666bd06112fe5554 guix-binary-0.16.0.i686-linux.tar.xz 0d9f39dc060098784c1c3a77cce1c81c0474f473 guix-binary-0.16.0.i686-linux.tar.xz.sig 144a6e7d94552566fe0bf1dc9235ce8e723135b3 guix-binary-0.16.0.x86_64-linux.tar.xz a5bee7f04d2b4c95f5a9fa3dbea8af57d8b3515c guix-binary-0.16.0.x86_64-linux.tar.xz.sig ee9c380e2dfde7eb14423f0769c01c0f2c572791 guixsd-install-0.16.0.i686-linux.iso.xz 6a0666abdeb1a55ca4aedbcf969cc135fc0bf7ba guixsd-install-0.16.0.i686-linux.iso.xz.sig fa88f9c595b8ecfc5b63427bbf193014434e9865 guixsd-install-0.16.0.x86_64-linux.iso.xz a4c67a86f322e8845d23b17274d31df97f7ce035 guixsd-install-0.16.0.x86_64-linux.iso.xz.sig 5e0fa514a5362e1874affe8165dd76e02d515da4 guixsd-vm-image-0.16.0.x86_64-linux.xz ecfbe5db25aff2c6dbc62b7372afb7452f940d57 guixsd-vm-image-0.16.0.x86_64-linux.xz.sig [*] Use a .sig file to verify that the corresponding file (without the .sig suffix) is intact. First, be sure to download both the .sig file and the corresponding tarball. Then, run a command like this: gpg --verify guix-0.16.0.tar.gz.sig If that command fails because you don't have the required public key, then run this command to import it: gpg --keyserver pool.sks-keyservers.net \ --recv-keys 3CE464558A84FDC69DB40CFB090B11993D9AEBB5 and rerun the 'gpg --verify' command. This release was bootstrapped with the following tools: Autoconf 2.69 Automake 1.16.1 Makeinfo 6.5 Help2man 1.47.8 To install the Guix System Distribution, please see “System Installation” in the manual. To install Guix on a running system, see “Installation” in the manual. • Changes since version 0.15.0 (excerpt from the NEWS file) ** Package management *** Default substitute URL changed to https://ci.guix.info *** ‘guix pull -l’ list
Re: GuixSD on librem phone?
> I would like to know if there is any interest in this? I'm interested! janneke
Re: Octave & QtOctave
Alex Vong writes:
> Kei Kebreau writes:
>
>> Alex Vong writes:
>>
>>> Hello Kei,
>>>
>>> Kei Kebreau writes:
>>>
>>> [...]
Here are two tentative patches that make the changes we've discussed.
Also, should we make a deprecated-package definition for qtoctave?
>>>
>>> I think some additional changes related to "(assoc-ref inputs ..."
>>> needed to be made. Otherwise, looks good to me! Here is a patch I made
>>> earlier but it was not tested, feel free to cherry-pick what is needed:
>>>
>>> From 2b04caa66c17da257dfb4f4ccb94e8d629b95e53 Mon Sep 17 00:00:00 2001
>>> From: Alex Vong
>>> Date: Mon, 3 Dec 2018 03:39:40 +0800
>>> Subject: [PATCH] gnu: Rename "octave" to "octave-cli" and "qtoctave" to
>>> "octave".
>>>
>>> * gnu/packages/maths.scm (octave): Rename to octave-cli.
>>> [name]: Change to "octave-cli".
>>> (qtoctave): Rename to octave.
>>> [name]: Change to "octave".
>>> [inherit]: Inherit from octave-cli.
>>> [source]: Likewise.
>>> [inputs]: Likewise.
>>> [native-inputs]: Likewise.
>>> [arguments]: Likewise.
>>> (flann): Update accordingly.
>>> * gnu/packages/engineering.scm (qucs): Likewise.
>>> (qucs-s): Likewise.
>>> * gnu/packages/machine-learning.scm (shogun): Likewise.
>>
>> ...
>>
>>> - ("octave" ,octave)
>>> + ("octave-cli" ,octave-cli)
>>
>> I see the main difference is that you've replace the package's
>> associated string to "octave-cli" as well as the name, whereas I've only
>> replaced the package name. Should I replace the associated package
>> string, too?
>
> According to the manual "6.7.2 Package Naming", the associated string is
> used for package management commands such as 'guix package' and 'guix
> build'. Therefore, I think we should change them as well, so that the
> users can install the packages using the command
> "guix package -i octave-cli" and "guix package -i octave"
> respectively. What do you think?
Maybe this is true when manipulating the package definition, but that
doesn't seem to be the case in general. When I run
"./pre-inst-env guix package --show=shogun", for example,
"octave-cli@4.4.1" is listed as a dependency, even though "octave" is
the associated name in shogun's input list.
To be clear, I've changed the string for octave's and octave-cli's
package name in their respective package definitions, but I haven't
changed the string in the input lists of octave-cli's dependent
packages.
I'm inclined to follow convention when it comes to this, and other
packages in input lists seem to omit extensions to the base name of the
package in their assoc-lists. For example, ("gettext", gettext-minimal)
and ("python", python-minimal-wrapper) are common inputs for packages.
signature.asc
Description: PGP signature
Re: GuixSD on librem phone?
Hi! sorry for going little bit OT I'm *desperately* looking forward for hardware I can trust, so librem5 is giving me *some* hope, but... Vagrant Cascadian writes: [...] > https://puri.sm/posts/librem5-2018-09-hardware-report/ > > Apparently they will use wifi/bluetooth/cellular that has proprietary > firmware, but burned into the hardware, which is compliant with the RYF > guidelines... still in 2018 the hardware landscape is so sad that a quite "freedom committed" vendor [1] cannot find a better alternative than to use a proprietary wifi and bluetooth stack: OK, RFY compliant but what _when_ (not if) a serious bug will be found on that firmware? are we sure wifi/bluetooth cannot be used as "side channel" vector attacks? callular (baseband) merits a dedicated chapter, since it seems practically impossible *forever* to trust that chips... and that chips are an important attack vector (Purism will use USB bus to separate baseband from CPU) this also means we will _never_ be able to trust communications via baseband (2G, 3G... 5G), fortunately this can be fixed using a trusted _separated_ SoC and the very good work coming from the vast and smart FLOSS community [2] :-) [...] Ciao Giovanni [1] citing from the above mentioned article: «This is highlighting the fact that Purism, as a social purpose corporation, will push our strict agenda of software and user freedoms upstream into the supply chain.» [2] looking at you, secushare https://secushare.org/ -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
Re: GuixSD on librem phone?
On 2018-12-06, Vagrant Cascadian wrote: > On 2018-12-06, swedebu...@riseup.net wrote: >> What about blobs? Any news? (see below) > > Not sure. For their laptops, they use blob-free wireless, at least. > > The chipset proposed for the librem-5 (imx8*) has a GPU that works with > etnaviv and so I don't *think* it requires binary blobs. > > I'm not sure what wireless chipset or cellular modem it's using, or any > other hardware that might need a binary blob. https://puri.sm/posts/librem5-2018-09-hardware-report/ Apparently they will use wifi/bluetooth/cellular that has proprietary firmware, but burned into the hardware, which is compliant with the RYF guidelines... live well, vagrant signature.asc Description: PGP signature
Re: GuixSD on librem phone?
On 2018-12-06, swedebu...@riseup.net wrote: > I would like to know if there is any interest in this? I've got my eyes on the librem-5 too... > What processor architecture is it using? aarch64 > What about blobs? Any news? (see below) Not sure. For their laptops, they use blob-free wireless, at least. The chipset proposed for the librem-5 (imx8*) has a GPU that works with etnaviv and so I don't *think* it requires binary blobs. I'm not sure what wireless chipset or cellular modem it's using, or any other hardware that might need a binary blob. live well, vagrant signature.asc Description: PGP signature
'GNU Guix' book (Was: Re: Book idea and Guix items in the FSF(E) shops)
On 2018-12-06 11:52, Pjotr Prins wrote: > On Thu, Dec 06, 2018 at 01:14:49AM -0800, swedebu...@riseup.net wrote: >> What about a book "Introduction to Guile Scheme" modeled after the emacs >> lisp one but with Guix in locus instead of emacs? >> >> Thinking further I'm guessing we could use some of the newly donated >> funds to give incentitive for write such a book ourselves. E.g. by >> defining resonable chapters and establish clearly defined bounties. >> >> I for one would like to contribute to such a book. We could work in >> wikibooks or in our own place somewhere but it should be easy to edit >> (easier than a git repo/patch by email). > > That is a very good idea. I think, however, the demand will be much > higher for a 'GNU Guix' book which teaches scheme implicitly. It will > also make GNU Guix a first rate item in the shop. Grow a Scheme on > Guix ;) Deal! :) > > I am happy to contribute a chapter on 'GNU Guix for science' and > perhaps a chapter on 'Writing software using Guix containers'. > > Both topics make my daily work a joy :). Can't do without it. Fantastic! I can write some of the basics. An introduction and a couple of examples of use to the higher-order functions like fold-packages would be nice I think. Also a chapter on befriending with the guix repl would be nice. I had some eh, troubles with it in the beginning (and sometimes now) because it is not clear to me when the earlier loaded procedures are cleared. ATM my workflow is like this: inside screen open emacs with the scheme file i'm working on m-x 3 m-x shell enter code in the scheme file m-x o run $guile in the dir of the file (load "file.scm") (test-some-proc) m-x o enter code in the scheme file m-x o run $guile in the dir of the file (load "file.scm") (test-some-proc) ... Sometimes I have to quit guile and reenter to get it to work right (if I change some names of procedures and forget to call the new ones. (this happened 2 times during devel of guile-wikidata) Also I found 2 bugs I think (I have yet to report them). 1 where paredit-mode would not move the last parens of a proc when commennting aout sub-parts of that proc. 1 where run-guile -> geiser-eval-buffer fails to eval the buffer (resulting in me resorting to the suboptimal IDE above). -- Cheers Swedebugia
Re: First outreachy day :)
> I wish you good luck with your project/assignments. Thank you too :) Regards! Laura
Re: First outreachy day :)
> Welcome. Thanks :) > I think we are from everywhere on earth. It's OK to live in a different > timezone. And most hackers tend to prefer working at night. We don't > have a strict time table like a company. hahaha :) Yes, I was concerned mostly for reaching my mentors/coordinators but they are always there, and I am also very happy to have the IRC channel and having almost anyone anwering my questions :) I really like this community.
Re: qemu command line for installation
Hi! I am opening this thread again to mention some few things. I had to add one last line to the qemu command: (First ran : qemu-img create hda.img 50G) qemu-system-x86_64 \ -m 1024 \ -nodefaults \ -drive file=hda.img,format=raw,if=none,id=drive-ide0-0-0 \ -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 \ -drive file=guixsd-install-0.15.0.x86_64-linux.iso,format=raw,if=none,id=drive-ide0-0-1,readonly=on \ -device ide-cd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1,bootindex=2 \ -device qxl-vga \ -net user -net nic,model=virtio Because I had no eth0 interface. I also got gábor's warning. Everything worked fine, except the part of being able to switch ttys (ie open tty2 to see the documentation). And I could not use the mouse to copy text. I added the -show-cursor but that did not solve the problem. Since this machine is not my retroPC, and also wanted to learn more, instead of using the bare_bone.scm I used the lightweight, one, replacing the bootloader type, deleting the mapped devices stuff, and adding just xfce GUI. While doing guix init ... I fell asleep with my machine unplugged, and today when I opened qemu, however, it showed the GUI. But weird things happened, like the mouse kind of alive moving without control over the VM, and I saw when loading everything before showing the GUI, that it showed something about the wireless connection (I did not want that). I started again with the installation - i amost remember all the steps without having to take a look at the documentation - just adding more memory and using desktop.scm template, just changing username, timezone, and bootloader , and see what happens. Regards, Laura
GuixSD on librem phone?
Hi I would like to know if there is any interest in this? What processor architecture is it using? What about blobs? Any news? (see below) Could we pre-order one or two librem phones owned by the foundation to be used to to hack on this? I am looking forward the Here is a note from the high-priority-projects-2017-progress-report 2017-12-22: "Purism Librem 5 phones, now available for pre-order, will run a GNU/Linux-based operating system called PureOS by default, and will allow users to install a different GNU/Linux distribution if they choose, potentially making this the first phone on the market with fully libre userspace. Purism emphasizes privacy and security, with features that include encrypted text and email support, hardware kill switches, and more. They've already overshot their fundraising goal, indicating that there is a serious audience for a fully free phone. Unfortunately, at the time of this writing, Purism has not committed to avoid nonfree blobs – please help us encourage them to do so." https://www.fsf.org/bulletin/2017/fall/high-priority-projects-2017-progress-report -- Cheers Swedebugia
Re: Book idea and Guix items in the FSF(E) shops
On Thu, Dec 06, 2018 at 01:14:49AM -0800, swedebu...@riseup.net wrote: > What about a book "Introduction to Guile Scheme" modeled after the emacs > lisp one but with Guix in locus instead of emacs? > > Thinking further I'm guessing we could use some of the newly donated > funds to give incentitive for write such a book ourselves. E.g. by > defining resonable chapters and establish clearly defined bounties. > > I for one would like to contribute to such a book. We could work in > wikibooks or in our own place somewhere but it should be easy to edit > (easier than a git repo/patch by email). That is a very good idea. I think, however, the demand will be much higher for a 'GNU Guix' book which teaches scheme implicitly. It will also make GNU Guix a first rate item in the shop. Grow a Scheme on Guix ;) I am happy to contribute a chapter on 'GNU Guix for science' and perhaps a chapter on 'Writing software using Guix containers'. Both topics make my daily work a joy :). Can't do without it. Pj.
Book idea and Guix items in the FSF(E) shops
Hi I took a look in the shop https://shop.fsf.org/ and https://fsfe.org/order/order.sv.html. I was wondering if anyone have thought of suggesting Guix/GuixSD items to the people managing the stores? I would definately like to see/buy a mug or a t-shirt with the logo and a sticker for my laptop. What about a book "Introduction to Guile Scheme" modeled after the emacs lisp one but with Guix in locus instead of emacs? Thinking further I'm guessing we could use some of the newly donated funds to give incentitive for write such a book ourselves. E.g. by defining resonable chapters and establish clearly defined bounties. I for one would like to contribute to such a book. We could work in wikibooks or in our own place somewhere but it should be easy to edit (easier than a git repo/patch by email). -- Cheers Swedebugia
Re: FOSDEM 2019 (ACTION: please register or mail)
The announcement page is updated to the latest: https://libreplanet.org/wiki/Group:Guix/FOSDEM2019 Do register if you intend to come to the GNU Guix days. We will limit the audience to 40 persons. For those of you travelling from far away, there are many places you can stay in Brussels. There are also rooms at the ICAB where we are hosting the two day event. Some of us will stay there again and even though it is not luxurious it is decent and pretty convenient. Pj.
