Re: Advice about GuixSD on Serveraptor?
From: Leo Famulari Subject: Re: Advice about GuixSD on Serveraptor? Date: Tue, 21 Mar 2017 16:53:35 -0400 On Tue, Mar 21, 2017 at 04:46:20PM -0400, Leo Famulari wrote: So what I'm doing here is trying to provide Serveraptor with a GuixSD image that they'd offer to users. People could regenerate the image themselves, but it would be difficult to verify that it matches what is offered by Serveraptor. And to clarify my previous question: Should this QEMU image be created by me, or should it be created by a Guix maintainer as part of the Guix release process? Hi, to add my 2 cents: I think it would be fine if you provided the image, if you are confident that it works. When GuixSD becomes widely available on various hosting providers, the Guix maintainers cannot provide all those images (or guarantee their correctness) anyway (I imagine that typically an employee of such a service would create the image?). Even now, when you provide an image to Serveraptor, you have no way to verify if Serveraptor provides the same image to their users (I think?). Once Serveraptor provides the image you created (or any other GuixSD image) to its users, the responsibility lies with them. Serveraptor's users will have to trust Serveraptor (and, if they use your image, Serveraptor has to trust you, but it sounds like they already do :-) ). Thomas
Re: Introducing ‘guix pack’
Andy Wingo writes: > On Mon 20 Mar 2017 15:14, l...@gnu.org (Ludovic Courtès) writes: > >> Federico Beffa skribis: >> >>> If you provide an archive such as >>> 'guile-2.2.0-pack-x86_64-linux-gnu.tar.lz' reachable from the main >>> project page (especially without any warning about its intended >>> purpose), I bet that many peoples will install it and keep it. If more >>> projects follow this example, we land to the above scenario where "rm >>> -rf /gnu" is not practical at all. > > Replying to Federico: These are the same considerations as with Guix > fwiw, unless you remove old profiles and "guix gc". There is a very big difference. The Guix binary installation pack does include the 'guix' command which allows you to remove stuff from the store. Any other pack not including 'guix' does not. Suppose that Guix pack bundles become popular and compare them to, say, Mac style archives. Let's go through Ludovic's analysis: 1. Composability: With Mac bundles you extract the archive in a directory. With Guix packs it's essentially the same. i. Sharing of store items: What are the chances that two independent projects will generate packs from the same git checkout (or guix pull)? Pretty low. Therefore the amount of sharing between different packs will be pretty negligible. ii. Adding a program. Mac style: you just extract it. With Guix pack it's essentially the same, but it creates a manually unmanageable network of links which entangle all packs. iii. Remove an item: Mac style: delete a directory. With Guix pack the choice is: delete everything or keep everything. That is, you keep obsolete programs/libraries with security holes on your system ready for exploitation and unnecessarily filling your disk, or ... start from scratch. Is this composability? 2. Security: Mac style bundles are problematic, but at least you can easily delete old stuff and replace them with updated versions. Guix packs are worse: delete everything or keep it all. 3. Reproducibility: As long as you carefully take note from which git checkout you generate a Guix pack, Guix packs seems to be superior. Oh, don't you also depend on upsteam published archives of every single package in Guix? They sometimes disappear or are replaced in place with different archives and so, after some time, your carefully noted git checkout will not build anymore. 4. Experimentation: Guix is great for that, but packs? Are they useful for testing on other GNU/Linux systems? Maybe. But aren't all Guix packages built in isolated environments anyway? So, do you really need packs to test on other systems? Maybe, but probably not. Don't get me wrong, I find that Guix proper has many great features, but pack is not one of them. I find very disturbing when peoples advertise things hiding half of the story to make them appear better than what they really are. Fede
Re: Advice about GuixSD on Serveraptor?
Leo Famulari writes: > On Tue, Mar 21, 2017 at 04:46:20PM -0400, Leo Famulari wrote: >> So what I'm doing here is trying to provide Serveraptor with a GuixSD >> image that they'd offer to users. >> >> People could regenerate the image themselves, but it would be difficult >> to verify that it matches what is offered by Serveraptor. > > And to clarify my previous question: Should this QEMU image be created > by me, or should it be created by a Guix maintainer as part of the Guix > release process? I’m not sure. I guess it would be better for users if it was signed by a maintainer key, but on the other hand I don’t know if we can commit to publishing QEMU images with every release. Could we build an image with Hydra instead and just provide the latest build to Serveraptor? How would updates to the image be handled? Do they offer some sort of API to upload new images or is this a process that depends on humans making decisions? -- Ricardo GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC https://elephly.net
Re: [GSoC] Development of Cuirass.
Hi Mathieu, > A majority of people in this community seems to adhere to political > ideas related to feminism and LGBT causes and are very vocal about it. > While I respect people having such conviction, the fact that those > ideas/values are repeatedly presented as if every one should adhere to > them is not welcoming for those who disagree. > > As a consequence I would rather spend my time working on Free Software > projects that I consider more tolerant. I find it sad that we have different interpretations of what it means for projects to be tolerant, and I’m disappointed to see you leave like that. Like Ludo said: there’s nothing for any of us to lose in trying what we can to make this project more welcoming than what is sadly the norm in many software project. A practical question: Will you continue to work on and maintain Cuirass at your notabug repository or should someone here take over maintenance of this project? I was about to work on some patches and would like to know if you decided to abandon Cuirass. Thank you for you past contributions. -- Ricardo GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC https://elephly.net
Re: Advice about GuixSD on Serveraptor?
On Tue, Mar 21, 2017 at 09:06:09PM +, ng0 wrote: > IN-Berlin wants a raw image (they have read our documentation). > The way their system works is that you sent > them your ssh pubkey, they initialize a basic Debian system depending on > the size you chose, and you can login once you get the hostname etc. > They have an out-of-band consoleserver where the ssh key is placed > aswell for the machine. > I don't work with this non-profit organization, but having a way to > define ssh pubkeys in the system config would be super useful for this. > Right now I'm about to create my own system and just sent it to them as > soon as I feel up to it. > If they could simply create the system in their infrastructure, that > would be an incredible speedup and reproducible. > I don't know much about the out of band consoleserver, I have to ask > if that's somehow relevant or if it simply needs some initrd settings to > expose it to the server. Interesting! I'll probably take a look at this when I got some free time. signature.asc Description: PGP signature
Re: Advice about GuixSD on Serveraptor?
On Wed, Mar 22, 2017 at 08:36:19AM +0100, Thomas Danckaert wrote: [...] > the image?). Even now, when you provide an image to Serveraptor, you have > no way to verify if Serveraptor provides the same image to their users (I > think?). The "best" idea I had was to use a tool like mtree to hash every file on the filesystem, and then compare it to the booted system. "Best" because I think it's impractical :) signature.asc Description: PGP signature
Re: Advice about GuixSD on Serveraptor?
On Wed, Mar 22, 2017 at 01:04:46PM +0100, Ricardo Wurmus wrote: > Leo Famulari writes: > > And to clarify my previous question: Should this QEMU image be created > > by me, or should it be created by a Guix maintainer as part of the Guix > > release process? > > I’m not sure. I guess it would be better for users if it was signed by > a maintainer key, but on the other hand I don’t know if we can commit to > publishing QEMU images with every release. Okay. > Could we build an image with Hydra instead and just provide the latest > build to Serveraptor? How would updates to the image be handled? Do > they offer some sort of API to upload new images or is this a process > that depends on humans making decisions? It's not a bad idea to build it on Hydra. Hydra already builds a usb-image / disk-image job [0], so we could add a qemu-image job, too. I think that updates to the image would have to be handled manually. One of us could send them a link to the new image and they'd make it available to their users. My expectation is that Serveraptor would offer our latest release, and users would be expected to update their systems, as on bare-metal. [0] https://hydra.gnu.org/job/gnu/core-updates/usb-image.x86_64-linux
Re: Advice about GuixSD on Serveraptor?
On Wed, Mar 22, 2017 at 01:20:53PM -0400, Leo Famulari wrote: > It's not a bad idea to build it on Hydra. Hydra already builds a > usb-image / disk-image job [0], so we could add a qemu-image job, too. Actually, we used to build a qemu-image on Hydra, but we removed because it was troublesome and unused. https://git.savannah.gnu.org/cgit/guix.git/commit/?id=a3a27745013f3e5a287de3bf0187b2f72beb6965 Maybe we should try again :) signature.asc Description: PGP signature
Re: Advice about GuixSD on Serveraptor?
Leo Famulari transcribed 2.0K bytes: > On Tue, Mar 21, 2017 at 09:06:09PM +, ng0 wrote: > > IN-Berlin wants a raw image (they have read our documentation). > > The way their system works is that you sent > > them your ssh pubkey, they initialize a basic Debian system depending on > > the size you chose, and you can login once you get the hostname etc. > > They have an out-of-band consoleserver where the ssh key is placed > > aswell for the machine. > > I don't work with this non-profit organization, but having a way to > > define ssh pubkeys in the system config would be super useful for this. > > Right now I'm about to create my own system and just sent it to them as > > soon as I feel up to it. > > If they could simply create the system in their infrastructure, that > > would be an incredible speedup and reproducible. > > I don't know much about the out of band consoleserver, I have to ask > > if that's somehow relevant or if it simply needs some initrd settings to > > expose it to the server. > > Interesting! I'll probably take a look at this when I got some free > time. I'll write an email to IN-Berlin asking about the consoleserver this week. If it's nothing special, we could provide this bare image, and people could download it as the GuixSD with ssh + whatever is needed for it to work out in server context as a start.
Re: Continuing the work on the recipes related to GNU Ring
Today, I bring you some good and bad news! :)
* The good news
I'm attaching an improved version of my previous set of recipes.
This should allow *GuixSD* users to use GNU Ring straight away.
However, both Guix users (in foreign distributions) and GuixSD users,
must be advised that this is a work-in-progress, and there are still
untested parts, or parts that were overlooked due to my lack of
experience as developer and all things related to "ld"-stuff and with
other build and developer tools and practices.
If you really want to help out, even if just for testing, please read
on.
* The bad news
After installing at least ring-client-gnome, Guix now suggests the user
to add a custom XDG_DATA_DIRS variable to his "~/.profile" file. For
Guix users in foreign distributions, this might cause an unwanted log-in
loop, described in Guix bug #26202
([[http://lists.gnu.org/archive/html/bug-guix/2017-03/msg00200.html]] or
[[https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26202]]).
* What was not tested
- Everything, including integration with GNOME Evolution data server
(for contact list and management), both for GNOME Evolution comming
from Guix, from GuixSD, or from a foreign distribution (because I
don't use GNOME Evolution, although it comes by default in Trisquel
7).
* What might need improvement
- Convince Ring to send their patches to their respective upstreams! :D
- Talk to Ring project to see if so much customization is really
needed. Perhaps they have patches and "rules.mak" files only so that
their work "gets lighter", but that might not be a requirement.
- For some reason, the Ring daemon (that is provided by "libring"
package) doesn't come installed with Ring GNOME client (provided by
"ring-client-gnome").
- Even after installed, the Ring daemon is actually located at
"${HOME}/.guix-profile/lib/ring/dring". I guess this deosn't sound
right for an executable.
- Look in the source code of the newly added packages for things I have
missed, that might need to be corrected, like bundled stuff, or paths
that should be pointing to store references.
- See section "What was not tested".
- Split the Ring tarball (ring[something].tar.gz) into useful separated
ones.
- Or find a way to get each part separatedly from their git
repositories, making sure that we are indeed getting the code
corresponding to beta 2.
- For more things to do, read the attached package definitions file.
* Notes for package maintainers
- All the packages are either new or heavily modified to follow patches
and "rules.mak" files present inside
"ring[something].tar.gz/ring-project/daemon/contrib/src".
- The only packages that are upgrades to existing ones (but still
heavily modified) are argon2 and opendht.
* Notes for testers
- When installing:
- Disable grafts (use `--no-grafts` option), otherwise you might be
getting the original argon2 and opendht recipes.
- Install "libring" and "ring-client-gnome".
- After installing:
- If Guix tells you to change XDG_DATA_DIRS in your "~/.profile",
don't do it, instead copy what is suggested to be done, and write it
as a comment (prefixed with "#") to that file, and see the links I
referenced so far. You'll still need what was suggested by Guix, so
commenting it is an useful way to save it for later.
- Before using (each time):
- In a new terminal, do:
1. Take the line Guix suggested, and paste it (remove the "#" prefix,
of course), and press Return (or Enter) to use it as command.
2. Now run: ".guix-profile/lib/ring/dring" -p
- This will start the Ring daemon in persistent mode, and make the
current terminal busy (unresponsible, ignoring almost all
input). It'll only exit if you press Ctrl + C (or force it to
terminate.
4. Do step 1 again in another terminal.
5. Finally, in this other terminal, run "gnome-ring" client.
--
- [[https://libreplanet.org/wiki/User:Adfeno]]
- Palestrante e consultor sobre /software/ livre (não confundir com
gratis).
- "WhatsApp"? Ele não é livre, por isso não uso. Iguais a ele prefiro
Ring, ou Tox. Quer outras formas de contato? Adicione o vCard que
está no endereço acima aos teus contatos.
- Pretende me enviar arquivos .doc, .ppt, .cdr, ou .mp3? OK, eu
aceito, mas não repasso. Entrego apenas em formatos favoráveis ao
/software/ livre. Favor entrar em contato em caso de dúvida.
- "People said I should accept the world. Bullshit! I don't accept the
world."
--- Richard Stallman
ring.scm
Description: Binary data
Re: Continuing the work on the recipes related to GNU Ring
On Wed, Mar 22, 2017 at 04:20:02PM -0300, Adonay Felipe Nogueira wrote: > * Notes for testers > > - When installing: > > - Disable grafts (use `--no-grafts` option), otherwise you might be > getting the original argon2 and opendht recipes. Can you clarify this? Not using grafts will mean that testers will lack a large number of security fixes applied to the Ring dependency graph. signature.asc Description: PGP signature
Re: Continuing the work on the recipes related to GNU Ring
Oh... So perhaps I misunderstood what "grafts" mean. The first time I tested my custom argon2 and opendht recipes, they where built so quickly that I thought it was using the "old" recipes. Please ignore my suggestion for using `--no-grafts`. :)
Re: Advice about GuixSD on Serveraptor?
ng0 transcribed 1.3K bytes: > Leo Famulari transcribed 2.0K bytes: > > On Tue, Mar 21, 2017 at 09:06:09PM +, ng0 wrote: > > > IN-Berlin wants a raw image (they have read our documentation). > > > The way their system works is that you sent > > > them your ssh pubkey, they initialize a basic Debian system depending on > > > the size you chose, and you can login once you get the hostname etc. > > > They have an out-of-band consoleserver where the ssh key is placed > > > aswell for the machine. > > > I don't work with this non-profit organization, but having a way to > > > define ssh pubkeys in the system config would be super useful for this. > > > Right now I'm about to create my own system and just sent it to them as > > > soon as I feel up to it. > > > If they could simply create the system in their infrastructure, that > > > would be an incredible speedup and reproducible. > > > I don't know much about the out of band consoleserver, I have to ask > > > if that's somehow relevant or if it simply needs some initrd settings to > > > expose it to the server. > > > > Interesting! I'll probably take a look at this when I got some free > > time. > > I'll write an email to IN-Berlin asking about the consoleserver this > week. > If it's nothing special, we could provide this bare image, and people > could download it as the GuixSD with ssh + whatever is needed for it to > work out in server context as a start. > I just realized the last sentence is not good. Correction: If IN-Berlin uses (or needs) nothing special for the consoleserver to make use of the virtual servers within IN-Berlin infrastructure, I think it would be best if we (as Guix) could provide an extended bare image for servers which would include ssh-daemon on default port with password login enabled, where the password is not empty. That's a workaround I can imagine to be generic enough for all use cases. For the one of IN-Berlin and maybe similar hosters who use ssh pubkeys, it would be great to document for them how to recreate this image in easy steps and insert the clients ssh pubkey for the root account (or an named user) on the system. What do you think about this?
[PATCH] gnu: ustr: Fix build with GCC 5.
Hello, This patch allows to compile the 'ustr' package with gcc-5. The 'ustr' project hasn't been active since 2008, then I've taken the Debian project patch. The patch is for core-updates branch!.From 9d78ea64c037d2eea10d81093a3f8caae8d6d2e5 Mon Sep 17 00:00:00 2001 From: rennes Date: Wed, 22 Mar 2017 14:41:40 -0600 Subject: [PATCH] gnu: ustr: Fix build with GCC 5. * gnu/packages/patches/ustr-fix-build-with-gcc-5.patch: New file. * gnu/local.mk (dist_patch_DATA): Add it. * gnu/packages/textutils.scm (ustr)[source]: Add patch. --- gnu/local.mk | 1 + .../patches/ustr-fix-build-with-gcc-5.patch| 881 + gnu/packages/textutils.scm | 4 +- 3 files changed, 885 insertions(+), 1 deletion(-) create mode 100644 gnu/packages/patches/ustr-fix-build-with-gcc-5.patch diff --git a/gnu/local.mk b/gnu/local.mk index 4d85f15a0..f6c71f4c1 100644 --- a/gnu/local.mk +++ b/gnu/local.mk @@ -960,6 +960,7 @@ dist_patch_DATA = \ %D%/packages/patches/unzip-initialize-symlink-flag.patch \ %D%/packages/patches/unzip-overflow-long-fsize.patch \ %D%/packages/patches/unzip-remove-build-date.patch \ + %D%/packages/patches/ustr-fix-build-with-gcc-5.patch \ %D%/packages/patches/util-linux-tests.patch \ %D%/packages/patches/util-linux-CVE-2017-2616.patch \ %D%/packages/patches/upower-builddir.patch \ diff --git a/gnu/packages/patches/ustr-fix-build-with-gcc-5.patch b/gnu/packages/patches/ustr-fix-build-with-gcc-5.patch new file mode 100644 index 0..0bb22d8dd --- /dev/null +++ b/gnu/packages/patches/ustr-fix-build-with-gcc-5.patch @@ -0,0 +1,881 @@ +This patch allows to compile the 'ustr' package with gcc-5. + +The 'ustr' project hasn't been active since 2008. + +The patch was made by the Debian project: +https://packages.debian.org/stretch/libustr-1.0-1 + +From: Václav OvsÃk +Subject: [PATCH] fixes/gnu-inline + +This patch adds `__attribute__ ((gnu_inline))' into prototype macros +before `inline' to force GNU89 behaviour of inline functions +in C99 mode. +See http://www.gnu.org/software/gcc/gcc-5/porting_to.html + +Signed-off-by: Václav OvsÃk + +--- + ustr-b-dbg-code.c | 8 + ustr-b-opt-code.c | 8 + ustr-cmp-dbg-code.c | 8 + ustr-cmp-opt-code.c | 8 + ustr-compiler.h | 4 ++-- + ustr-fmt-dbg-code.c | 8 + ustr-fmt-opt-code.c | 8 + ustr-ins-dbg-code.c | 8 + ustr-ins-opt-code.c | 8 + ustr-io-dbg-code.c | 8 + ustr-io-opt-code.c | 8 + ustr-main-dbg-code.c| 2 +- + ustr-main-opt-code.c| 2 +- + ustr-parse-dbg-code.c | 8 + ustr-parse-opt-code.c | 8 + ustr-pool-dbg-code.c| 8 + ustr-pool-opt-code.c| 8 + ustr-replace-dbg-code.c | 8 + ustr-replace-opt-code.c | 8 + ustr-sc-dbg-code.c | 8 + ustr-sc-opt-code.c | 8 + ustr-set-dbg-code.c | 8 + ustr-set-opt-code.c | 8 + ustr-split-dbg-code.c | 8 + ustr-split-opt-code.c | 8 + ustr-spn-dbg-code.c | 8 + ustr-spn-opt-code.c | 8 + ustr-srch-dbg-code.c| 8 + ustr-srch-opt-code.c| 8 + ustr-sub-dbg-code.c | 8 + ustr-sub-opt-code.c | 8 + ustr-utf8-dbg-code.c| 8 + ustr-utf8-opt-code.c| 8 + 33 files changed, 124 insertions(+), 124 deletions(-) + +diff --git a/ustr-b-dbg-code.c b/ustr-b-dbg-code.c +index 4a7fdac..60e383e 100644 +--- a/ustr-b-dbg-code.c b/ustr-b-dbg-code.c +@@ -3,11 +3,11 @@ + #include "ustr-conf-debug.h" + #define USTR_CONF_USE_DYNAMIC_CONF USTR_CONF_HAVE_DYNAMIC_CONF + #define USTR_CONF_e_PROTO extern +-#define USTR_CONF_i_PROTO extern inline ++#define USTR_CONF_i_PROTO extern __attribute__ ((gnu_inline)) inline + #define USTR_CONF_E_PROTO extern +-#define USTR_CONF_I_PROTO extern inline ++#define USTR_CONF_I_PROTO extern __attribute__ ((gnu_inline)) inline + #define USTR_CONF_EI_PROTO extern +-#define USTR_CONF_II_PROTO extern inline ++#define USTR_CONF_II_PROTO extern __attribute__ ((gnu_inline)) inline + #include "ustr-main.h" + #undef USTR_CONF_INCLUDE_CODEONLY_HEADERS + #define USTR_CONF_INCLUDE_CODEONLY_HEADERS 1 +@@ -16,5 +16,5 @@ + #undef USTR_CONF_I_PROTO + #define USTR_CONF_I_PROTO + #undef USTR_CONF_II_PROTO +-#define USTR_CONF_II_PROTO inline ++#define USTR_CONF_II_PROTO __attribute__ ((gnu_inline)) inline + #include "ustr-b.h" +diff --git a/ustr-b-opt-code.c b/ustr-b-opt-code.c +index 45e9e87..4011898 100644 +--- a/ustr-b-opt-code.c b/ustr-b-opt-code.c +@@ -3,11 +3,11 @@ + #include "ustr-conf.h" + #define USTR_CONF_USE_DYNAMIC_CONF USTR_CONF_HAVE_DYNAMIC_CONF + #define USTR_CONF_e_PROTO extern +-#define USTR_CONF_i_PROTO extern inline ++#define USTR_CONF_i_PROTO extern __attribute__ ((gnu_inline)) inline + #define USTR_CONF_E_PROT
