Re: boot multiple Gnu/Linux Distributions from one USB key

[gnuforever]

On 12.03.2019 11:34, Tobias Geerinckx-Rice wrote:
You'll also note that Debian-based distributions use a completely 
different magic word:


 linux … iso-scan/filename=$isofile …


Indeed. For Trisquel, libreboot, I have this:

   ## TRISQUEL
   menuentry "Trisquel 7.0 - Gnu/Linux" {
   set isofile="/boot-isos/trisquel_7.0_amd64.iso"
   loopback loop (usb0,msdos1)$isofile
   linux (loop)/casper/vmlinuz boot=casper 
iso-scan/filename=$isofile noprompt noeject timezone=Europe/Brussels

   initrd (loop)/casper/initrd
   }

I wonder if MAPPED-DEVICES could be a solution here, with a bit (heh) 
of extra code…


Unfortunately, I am not a lisp programmer. Not a programmer at all :-)
I do some lisp in my emacs config files but just for emacs 
customization.
Code I found from other emacs users or sometimes with the emacs 
customization wizard.



TL;DR: there is no one reliable way, only distro-specific support.
Does this mean that ,for the moment, I can not add Guix to my multiple 
boot usb key?



On 12.03.2019 14:05, Ricardo Wurmus wrote:

Does a partition with this label exist?


Yes, it exists. If I dd the guix install iso into a usb and boot from 
it, the /dev/sr0 which is the is it booted from has "GUIXSD_IMAGE" as 
label
In fact, the default embeded grub.cfg in the guix iso looks like this, 
but it uses uuid


search --fs-uuid --set 1970-01-01-19-16-18-78
linux 
/gnu/store/0zajbn9q39yva4l0zzrcshlll8qikzba-linux-libre-4.19.6/bzImage9 
--system=/gnu/store/l4hgd4l7acrqwi3imav9akcvv4sbj85j-system 
--load=/gnu/store/l4hgd4l7acrqwi3imav9akcvv4sbj85j-system/boot
initrd 
/gnu/store/9nqaksx40zh5d6cg5rim3f3spy56bfb9-raw-initrd/initrd.cpio.gz



On 12.03.2019 19:56, Vagrant Cascadian wrote:

From the Guix initramfs you would need to run:

  losetup /path/to/file

If the image was in a partitioned loopback file:

  losetup --partscan /path/to/file

Then I suspect the labels would get populated. You may also need to add
losetup to the initramfs, since it probably isn't yet present.

I'm guessing you would also remove the (loop) from these arguments,
which are passed to the Guix initramfs, not loaded from grub:

  --system=/gnu/store...-system
  --load=/gnu/store...-boot


I will give a try.

Happy Gnu!
gnuforever

Re: create a symlink

[Rene]

Hi,

Danny Milosavljevic  writes:

>
> But as far as I understand, you boot Debian/Hurd or something and then
> it loads Guix, right?
>

Yes, I use Guix as package manager like another linux distro.

I currently use `./pre-inst-env guix system init doc/os-config-hurd.scm
/guix`, where /guix is an empty partition to populate GuixSD os.

>
> It should be easy to adapt gnu/bootloader/grub.scm's grub-configuration-file
> to emit those and then reconfigure.
>
> (Later, we could add "multiboot" and "modules" to  in
> gnu/bootloader.scm)
>
> However, it's a dangerous part to modify since this part cannot be rolled
> back easily.  So don't make a typo ;)
>

I get It.

I found a conversation in bug-hurd, maybe it will work to avoid links like 
/hurd.
http://lists.gnu.org/archive/html/bug-hurd/2015-07/msg2.html

How I can change "/hurd/" by "/gnu/store/abc..-hurd-0.9/hurd/" in
 through Guix?

--8<---cut here---start->8---
/* Hurd servers are specified by symbols _HURD_FOO,
   the canonical pathname being /hurd/foo.  */

#define   _HURD   "/hurd/"
#define _HURD_STARTUP   _HURD "startup"
#define _HURD_PROC   _HURD "proc"
#define _HURD_AUTH  _HURD "auth"
--8<---cut here---end--->8---


-- 

Rene

Re: CDN Test Results - Should We Continue Using a CDN?

[Maxim Cournoyer]

Hello Ludovic!

Ludovic Courtès  writes:

> Hi Maxim,
>
> Maxim Cournoyer  skribis:
>
>> Pardon me for asking, but how does using a CDN frees up resources?
>> Aren't the usual infrastructure preserved (e.g., ci.guix.info)? It
>> seems it'd be an extra layer to maintain?
>
> One of the motivations for this is that berlin.guixsd.org
> aka. ci.guix.info is a single machine, the head of our main build farm.
> If that machine goes down, we have no substitutes.  Having a cache like
> a CDN provides some redundancy: if the build farm goes down, we’ll at
> least still have cached substitutes, which leaves us time to fix the
> build farm.

I see. I understand that having the service continue running smoothly
while fixing ci.guix.info must be a good stress reliever.

[...]

>> I'd rather see this (even modest) amount put into the hands of a
>> motivated hacker to work on a distributed solution instead of
>> encouraging a company which do not share our free software ideals.
>
> As discussed before, I definitely sympathize with this.  Heck, if
> someone had told me I’d argue in favor of a CDN after all this time
> spent filling in CloudFare CAPTCHAs just because CloudFare decided that
> user privacy doesn’t matter and that Tor users should be penalized, I’d
> have laughed.  ;-)
>
> So it’s definitely not an easy decision.  Nevertheless, we have to
> acknowledge the fact that our current substitute delivery infrastructure
> is fragile.  If people volunteer to maintain a set of mirrors with some
> load balancing, that’s great, I’m all for it.  But for now, we don’t
> have that at all, hence the CDN.

Right. I understand better the motivation behind the CDN now, thank you
for taking the time to explain. Resiliency is indeed welcome and maybe
even necessary until better things come.

Maxim

Re: Missed testing

[Jeremiah]

> Also, that doesn't help on initial installation which should be made
> much more user-friendly.

Fault tolerant is far more important than user-friendly because a
reliable system is far easier to make user-friendly than it is to make a
user-friendly system fault tolerant.

> That sounds very strange and would be a very bad bug.

It is a very easy to reproduce bug, simply copy the text and paste it
into the example config above the user field.

> I'm using luks home with current guix master and it prompts for my
> password.

Here is the complete procedure I followed to hit the bug:

# Steps for creating a guix vm image using qemu and guix bootstrap Image
GUIX_VERSION=0.16.0

# Step 0 get, verify and unpack guix bootstrap image
wget 
"https://alpha.gnu.org/gnu/guix/guixsd-install-$GUIX_VERSION.x86_64-linux.iso.xz";
wget 
"https://alpha.gnu.org/gnu/guix/guixsd-install-$GUIX_VERSION.x86_64-linux.iso.xz.sig";
gpg --verify "guixsd-install-$GUIX_VERSION.x86_64-linux.iso.xz.sig"
unxz -k "guixsd-usb-install-$GUIX_VERSION.x86_64-linux.xz"

# Step 1 create and starta vm disk image of appropriate format and size
qemu-img create prototype.qcow2 20G -f qcow2

# start qemu
qemu-system-x86_64 -m 1024 -smp 1 -boot menu=on -enable-kvm -drive
file=prototype.qcow2 -drive
file=guixsd-usb-install-$GUIX_VERSION.x86_64-linux

# Step 2 setup disk partitions
# Format virtual drive to have 1 large primary partition and mark it as
# bootable
echo -e "o\nn\np\n1\n\n\na\nw" | fdisk /dev/sda

# Setup encrypted volume
cryptsetup -v --cipher aes-xts-plain64 --key-size 512 --hash sha512 --iter-time 
5 --use-random --verify-passphrase luksFormat /dev/sda1
# or if that takes too long to type:
cryptsetup -v -c aes-xts-plain64 -s 512 -h sha512 -i 5 --use-random -y 
luksFormat /dev/sda1
cryptsetup open /dev/sda1 root

# Format drive to allow its use
mkfs.ext4 /dev/mapper/root

# Label the volume for guix
e2label /dev/mapper/root root

# Mount the drive
mount /dev/mapper/root /mnt

# Step 3 setup network for download of packages and source code
# turn on networking
# vmware:: eno1636
ifconfig ens3 up
dhclient ens3

# Step 4 add tools required to make setup easier
# Set the default storage space for the setup on the drive itself
herd start cow-store /mnt/

# Step 5 replace the uuid with "/dev/sda1" and set bootloader to grub-bootloader
zile /etc/configuration/desktop.scm

# Step 6 Apply the configuration to the disk
guix system init /etc/configuration/desktop.scm /mnt --fallback

Please note the important difference that the entire drive is fully
encrypted (even grub will prompt for password to decrypt /boot)

> The installer can and should be made to automatically amend the system
> config by mptspi etc.
To the examples, that would be fine but I have concerns about guix
silently fixing configuration files.

-Jeremiah

Re: Request for commit access

[Ricardo Wurmus]

Hi,

> This access would be primarily for maintaining and addding packages in
> the (gnu packages maths/engineering/simulation) modules.

Neat!

Welcome, Paul!

-- 
Ricardo

Re: boot multiple Gnu/Linux Distributions from one USB key

[Vagrant Cascadian]

On 2019-03-12, Ricardo Wurmus wrote:
> gnuforever  writes:
>> For GuixSD, I came up with this configuration:
>> I used label instead of uuid.
>>
>> ## GUIXSD
>> menuentry "GUIXSD - Gnu/Linux" {
>> set isofile="/boot-isos/guixsd-install-0.16.0.x86_64-linux.iso"
>> loopback loop (hd0,1)$isofile
>> search --label --set GUIXSD_IMAGE
>> linux
>> (loop)/gnu/store/0zajbn9q39yva4l0zzrcshlll8qikzba-linux-libre-4.19.6/bzImage9
>> --root=GUIXSD_IMAGE
>> --system=(loop)/gnu/store/l4hgd4l7acrqwi3imav9akcvv4sbj85j-system
>> --load=(loop)/gnu/store/l4hgd4l7acrqwi3imav9akcvv4sbj85j-system/boot
>> initrd
>> (loop)/gnu/store/9nqaksx40zh5d6cg5rim3f3spy56bfb9-raw-initrd/initrd.cpio.gz
>> }
>>
>> It doesn't work. I get the following error message:
>>
>> waiting for partition 'GUIXSD_IMAGE' to appear...
>
> Does a partition with this label exist?

>From the Guix initramfs you would need to run:

  losetup /path/to/file

If the image was in a partitioned loopback file:

  losetup --partscan /path/to/file

Then I suspect the labels would get populated. You may also need to add
losetup to the initramfs, since it probably isn't yet present.

I'm guessing you would also remove the (loop) from these arguments,
which are passed to the Guix initramfs, not loaded from grub:

  --system=/gnu/store...-system
  --load=/gnu/store...-boot


live well,
  vagrant

Re: Request for commit access

[Ludovic Courtès]

Hi Paul,

Paul Garlick  skribis:

> May I request commit access for the Guix repositories?
>
> This access would be primarily for maintaining and addding packages in
> the (gnu packages maths/engineering/simulation) modules.
>
> Also, I am preparing to do the narration for the Guix videos.  With
> commit access, I will be able to push the audio files directly to
> videos.git.
>
> I  have an account on Savannah and have uploaded my OpenPGP key.

Great, that makes sense to me.

I’ve added you as a committer.  Could you please reply to this message
signed with the OpenPGP key that you’ll use to sign commits?

Please make sure to read ‘HACKING’ for the rules for commit access.  Do
not hesitate to ask if you have any questions about Git, the workflow,
or anything like that.

Thank you for your work on these modules, and welcome aboard!  :-)

Ludo’.


signature.asc
Description: PGP signature

Re: bug#25453: Keyboard layout configuration

[Taylan Kammer]

nee  wrote:
> Am 13.01.19 um 22:36 schrieb Ludovic Courtès:
>>> 1) grub
>>> 2) linux's initrd
>>> 3) console
>>> 4) X/wayland's layout
>>> 5) How to do the above
>> 
>
> Hello, I was working on this recently and made a patch for X11 that
> fixes the layout in the slim login and when you login into gnome3 or
> whatever desktop environment.
>
> I also made a patch for grub that fixes the layout when you edit the
> boot command for a menu entry, but not for the luks prompt. I think that
> might require installing a custom grub image (grub-mkimage) with
> grub-bios-setup instead of using grub-install (I saw some posts on the
> archlinux forum I don't have a link to right now). But this patch should
> lay the groundwork for it, as it can generate grub keyboard config files.
>
> The patches are pretty dirty, but I might not have that much time in the
> next few weeks to work on this, and since is hot on the mailing list
> right now, I'm sending them here now.

Heya, just wanted to give my personal thanks for working on this. :-) As
a user of an unusual keyboard layout (Colemak), this is one of my main
pet annoyances with Guix.


And by the way, an unpleasent off-topic issue:

After getting curious and visiting the homepage of your email domain
'cock.li' I was at first amused to see Chen from Touhou, but then pretty
sad to see a frivolous use of racist and sexist slurs and what I guess
is supposed to be "humorously meant hate speech" (thinking of the domain
name "nuke.africa" for instance).  I understand that this is probably
supposed to be a kind of childish black humor (I spent a lot of time on
4chan back in my time) but let's not forget that we're not, in fact,
children anymore, and that stuff like this can be quite seriously
upsetting to some people.  Imagine that we have, say, a middle-aged
African computer scientist in our community, who isn't familiar with
such "humor", or a young female college student with a background in a
conservative family with rigid gender roles, and consider how they might
feel after seeing domain names like "getbackinthe.kitchen", "nigge.rs",
and the like.  I'd urge you to use another address for correspondence
with an open community like this one, given that anyone could get
curious like me and visit the homepage of your domain.

- Taylan

Re: Regarding freedom issues

[swedebugia]

Ricardo Wurmus  skrev: (12 mars 2019 13:32:26 CET)
>
>swedebugia  writes:
>> The idea is to add to guix a way to inform the user that the package
>> they just searched for is not included in guix because of freedom
>> issues.
>>
>> The idea is that when we refuse a package to be included we add it
>> with a short reason to this list.
>>
>> Something like this
>> (issues
>>   (package odoo
>>   (reason "trapping users by withholding update scripts, see
>gnu.org/link.to.article"
>>   (alternatives '(dolibarr tryton smbledger ledger hledger gnucash)))
>
>I don’t think it’s a good idea to clutter Guix with packages that we
>won’t add.  There’s already a lot in Guix to provide free software
>packages; I don’t think we should add “negative packages”.
>
>That’s out of scope for Guix and could be handled by some other GNU
>resource instead.
>
>--
>Ricardo

Ok. I understand. 
-- 
Sent from my k-9 mail for Android.

Re: Packaging FreeCAD

[John Soo]

Thanks Efraim!

That helped a lot. I Switched to version 5.11.3 and swapped qt for qtbase
and some extra qt libraries and that moved me past the one blocker. Now I
am faced with another challenge. I packaged Shiboken 1 previously when I
did not realize freecad moved to pyside2; in that process I followed the
nix packaging strategy of building all the bundled libraries separately.  I
am now running into the same issues I had prior to splitting up Shiboken 1
while building pyside2. The python build system in pyside2 shells out to
cmake for most of the build process.  That means it does not use
cmake-build-system. Does pyside2 need to be split into parts now? It is
more challenging for pyside2 that Shiboken 1 because the sources for all
the libraries are shipped together.  Here's the source, for reference:
https://code.qt.io/cgit/pyside/pyside-setup.git/

Thank you all,

John

On Sun, Mar 10, 2019 at 7:25 AM Efraim Flashner 
wrote:

> On Sun, Mar 10, 2019 at 02:14:15AM +, John Soo wrote:
> > Hi guix,
> >
> > Just a quick update. I have little to report on freecad. I am still stuck
> > packaging pyside2. I have looked over the debian packaging rules but I am
> > unfamiliar with their packaging process. I did some research and it looks
> > as though they are using the normal pybuild process with some alterations
> > to some paths afterward.  The package completely fails to compile for me
> > and I am no expert on python build tooling. Here's what I have tried so
> far
> > and the error: https://paste.debian.net/1072533. Any help would be very
> > appreciated.
> >
> > Thanks,
> >
> > John
> >
> > On Fri, Feb 15, 2019 at 6:33 PM John Soo  wrote:
> >
> > > Thanks so much Paul! This is really helpful!
> > >
> > > > On Feb 15, 2019, at 9:20 AM, Paul Garlick <
> > > pgarl...@tourbillion-technology.com> wrote:
> > > >
> > > > Hi John,
> > > >
> > > >> I have been getting a little stuck building the pyside2 dependencies
> > > >
> > > > There has been an effort to package pyside2 for Debian.  This has
> been
> > > > completed in the last six months.
> > > >
> > > > A good place to look for information is
> > > > https://tracker.debian.org/pkg/pyside2
> > > >
> > > > You can browse the source code and follow the links to the 'debian'
> > > > directory, which contains the files that govern the packaging
> process.
> > > > In general for Debian packages, the 'rules' file is worth reading and
> > > > the 'patches' directory has the changes to the upstream code.
> > > >
> > > > One element that could be important in Guix is an update of patchelf
> to
> > > > a recent commit (see 'update-patchelf.patch' in the patches
> directory).
> > > >
> > > > Best regards,
> > > >
> > > > Paul.
> > > >
> > >
>
> I haven't tried building it myself yet, but two things come to mind:
> Try using qtbase instead of qt, it has a much smaller footprint and will
> likely be requested when it's time to include the package in Guix.
>
> You're using version 5.12.1, and in Guix we have qt 5.11.3. It's likely
> the errors you're getting are because the version of Qt is different.
>
> --
> Efraim Flashner  אפרים פלשנר
> GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
> Confidentiality cannot be guaranteed on emails sent or received unencrypted
>

Re: Patch adding POWER9 cross compile support

[Ludovic Courtès]

Hi!

Efraim Flashner  skribis:

> On Sun, Mar 10, 2019 at 09:20:04PM +0100, Tobias Platen wrote:
>> I ran configure on my Talos II, and got the following error message.
>> 
>> checking for the Guix system type... powerpc64le-linux

Sure but that’s the next step.  My question was about the triplet you
passed to ‘--target’ when cross-compiling from your Intel(?) machine,
but I think I can derive the answer now:

  guix build --target=powerpc64le-linux-gnu …

>> Guix already knows about this architecture, but building glibc will fail if
>> gcc does not have the float128 datatype. Once I saw this link[1] on the guix
>> mailing list, I knew how to solve the build error.
>> 
>> For the second question I could not find an answer.
>> 
>> [1] http://lists.busybox.net/pipermail/buildroot/2017-September/201379.html

Alright.

Thanks for the info.

> In the off chance we ever wish to support powerpc64 big endian, I
> suggest instead using (string-prefix? "powerpc64*-" target)

Yes.

Unfortunately, with just this extra --with-long-double-128, this:

  guix build sed --target=powerpc64le-linux-gnu

eventually leads to a glibc build failure:

--8<---cut here---start->8---
running configure fragment for sysdeps/unix/sysv/linux/powerpc
checking whether powerpc64le-linux-gnu-gcc -g -O2 -mlong-double-128 uses IBM 
extended format... yes
running configure fragment for sysdeps/unix/sysv/linux
checking installed Linux kernel header files... 3.2.0 or later
configure: WARNING: minimum kernel version reset to 3.10.0
checking for kernel header at least 3.10.0... ok
running configure fragment for sysdeps/gnu
running configure fragment for sysdeps/powerpc/powerpc64/le
checking if powerpc64le-linux-gnu-gcc supports binary128 floating point type... 
no
checking if the target machine is at least POWER8... yes
configure: error: ***  binary128 floating point type (GCC >= 6.2) is required 
on powerpc64le.
--8<---cut here---end--->8---

See ‘config.log’ excerpt below.  Do you happen to have an additional
change needed?

Thanks,
Ludo’.

--8<---cut here---start->8---
configure:6698: result: running configure fragment for 
sysdeps/powerpc/powerpc64/le
configure:5: checking if powerpc64le-linux-gnu-gcc supports binary128 floating 
point type
configure:31: powerpc64le-linux-gnu-gcc -c -g -O2 -Werror -mfloat128  
conftest.c >&5
powerpc64le-linux-gnu-gcc: error: unrecognized command line option '-mfloat128'
configure:31: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "GNU C Library"
| #define PACKAGE_TARNAME "glibc"
| #define PACKAGE_VERSION "(see version.h)"
| #define PACKAGE_STRING "GNU C Library (see version.h)"
| #define PACKAGE_BUGREPORT "https://sourceware.org/bugzilla/";
| #define PACKAGE_URL "http://www.gnu.org/software/glibc/";
| #define PKGVERSION "(GNU libc) "
| #define REPORT_BUGS_TO ""
| #define HAVE_TUNABLES 1
| #define HAVE_CC_NO_STACK_PROTECTOR 1
| #define STACK_PROTECTOR_LEVEL 0
| #define USE_MULTIARCH 1
| #define HAVE_ASM_SET_DIRECTIVE 1
| #define HAVE_SDATA_SECTION 1
| #define NO_CTORS_DTORS_SECTIONS 1
| #define HAVE_Z_COMBRELOC 1
| #define HAVE_CC_INHIBIT_LOOP_TO_LIBCALL 1

| #define HAVE_EHDR_START 1
| #define HAVE_BUILTIN_TRAP 1
| #define HAVE_ELFV2_ABI 1
| #define __LINUX_KERNEL_VERSION (3 * 65536 + 10 * 256 + 0)
| #define __ABI_TAG_VERSION 2,6,32
| #define HAVE_INLINED_SYSCALLS 1
| /* end confdefs.h.  */
| 
| __float128 a, b, c, d, e;
| int i;
| 
| __float128
| foobar (__float128 x)
| {
|   a = __builtin_nansq ("0");
|   b = __builtin_huge_valq ();
|   c = __builtin_infq ();
|   d = __builtin_fabsq (x);
|   e = __builtin_nanq ("0");
|   i = __builtin_signbit (x);
|   return __builtin_copysignq (x, x);
| }
| 
configure:39: result: no
configure:47: checking if the target machine is at least POWER8
configure:61: powerpc64le-linux-gnu-gcc -c -g -O2   conftest.c >&5
configure:61: $? = 0
configure:68: result: yes
configure:75: error: ***  binary128 floating point type (GCC >= 6.2) is 
required on powerpc64le.
--8<---cut here---end--->8---

Re: Patch adding POWER9 cross compile support

[Ludovic Courtès]

Hi!

Efraim Flashner  skribis:

> On Sun, Mar 10, 2019 at 09:20:04PM +0100, Tobias Platen wrote:
>> I ran configure on my Talos II, and got the following error message.
>> 
>> checking for the Guix system type... powerpc64le-linux

Sure but that’s the next step.  My question was about the triplet you
passed to ‘--target’ when cross-compiling from your Intel(?) machine,
but I think I can derive the answer now:

  guix build --target=powerpc64le-linux-gnu …

>> Guix already knows about this architecture, but building glibc will fail if
>> gcc does not have the float128 datatype. Once I saw this link[1] on the guix
>> mailing list, I knew how to solve the build error.
>> 
>> For the second question I could not find an answer.
>> 
>> [1] http://lists.busybox.net/pipermail/buildroot/2017-September/201379.html

Alright.

Thanks for the info.

> In the off chance we ever wish to support powerpc64 big endian, I
> suggest instead using (string-prefix? "powerpc64*-" target)

Yes.

Unfortunately, with just this extra --with-long-double-128, this:

  guix build sed --target=powerpc64le-linux-gnu

eventually leads to a glibc build failure:

--8<---cut here---start->8---
running configure fragment for sysdeps/unix/sysv/linux/powerpc
checking whether powerpc64le-linux-gnu-gcc -g -O2 -mlong-double-128 uses IBM 
extended format... yes
running configure fragment for sysdeps/unix/sysv/linux
checking installed Linux kernel header files... 3.2.0 or later
configure: WARNING: minimum kernel version reset to 3.10.0
checking for kernel header at least 3.10.0... ok
running configure fragment for sysdeps/gnu
running configure fragment for sysdeps/powerpc/powerpc64/le
checking if powerpc64le-linux-gnu-gcc supports binary128 floating point type... 
no
checking if the target machine is at least POWER8... yes
configure: error: ***  binary128 floating point type (GCC >= 6.2) is required 
on powerpc64le.
--8<---cut here---end--->8---

See ‘config.log’ excerpt below.  Do you happen to have an additional
change needed?

Thanks,
Ludo’.

--8<---cut here---start->8---
configure:6698: result: running configure fragment for 
sysdeps/powerpc/powerpc64/le
configure:5: checking if powerpc64le-linux-gnu-gcc supports binary128 floating 
point type
configure:31: powerpc64le-linux-gnu-gcc -c -g -O2 -Werror -mfloat128  
conftest.c >&5
powerpc64le-linux-gnu-gcc: error: unrecognized command line option '-mfloat128'
configure:31: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "GNU C Library"
| #define PACKAGE_TARNAME "glibc"
| #define PACKAGE_VERSION "(see version.h)"
| #define PACKAGE_STRING "GNU C Library (see version.h)"
| #define PACKAGE_BUGREPORT "https://sourceware.org/bugzilla/";
| #define PACKAGE_URL "http://www.gnu.org/software/glibc/";
| #define PKGVERSION "(GNU libc) "
| #define REPORT_BUGS_TO ""
| #define HAVE_TUNABLES 1
| #define HAVE_CC_NO_STACK_PROTECTOR 1
| #define STACK_PROTECTOR_LEVEL 0
| #define USE_MULTIARCH 1
| #define HAVE_ASM_SET_DIRECTIVE 1
| #define HAVE_SDATA_SECTION 1
| #define NO_CTORS_DTORS_SECTIONS 1
| #define HAVE_Z_COMBRELOC 1
| #define HAVE_CC_INHIBIT_LOOP_TO_LIBCALL 1

| #define HAVE_EHDR_START 1
| #define HAVE_BUILTIN_TRAP 1
| #define HAVE_ELFV2_ABI 1
| #define __LINUX_KERNEL_VERSION (3 * 65536 + 10 * 256 + 0)
| #define __ABI_TAG_VERSION 2,6,32
| #define HAVE_INLINED_SYSCALLS 1
| /* end confdefs.h.  */
| 
| __float128 a, b, c, d, e;
| int i;
| 
| __float128
| foobar (__float128 x)
| {
|   a = __builtin_nansq ("0");
|   b = __builtin_huge_valq ();
|   c = __builtin_infq ();
|   d = __builtin_fabsq (x);
|   e = __builtin_nanq ("0");
|   i = __builtin_signbit (x);
|   return __builtin_copysignq (x, x);
| }
| 
configure:39: result: no
configure:47: checking if the target machine is at least POWER8
configure:61: powerpc64le-linux-gnu-gcc -c -g -O2   conftest.c >&5
configure:61: $? = 0
configure:68: result: yes
configure:75: error: ***  binary128 floating point type (GCC >= 6.2) is 
required on powerpc64le.
--8<---cut here---end--->8---

Re: CDN Test Results - Should We Continue Using a CDN?

[Ludovic Courtès]

Hi Maxim,

Maxim Cournoyer  skribis:

> Pardon me for asking, but how does using a CDN frees up resources?
> Aren't the usual infrastructure preserved (e.g., ci.guix.info)? It
> seems it'd be an extra layer to maintain?

One of the motivations for this is that berlin.guixsd.org
aka. ci.guix.info is a single machine, the head of our main build farm.
If that machine goes down, we have no substitutes.  Having a cache like
a CDN provides some redundancy: if the build farm goes down, we’ll at
least still have cached substitutes, which leaves us time to fix the
build farm.

We can have a cache that’s not a CDN, like we did with
mirror.hydra.gnu.org, which runs an nginx caching proxy for
hydra.gnu.org.  However, that’s another machine to take care of (that’s
not much work in practice, but still, we must be able to quickly respond
to outages), and another single point of failure.

> The heaviest bandwith usage appear to originate from areas already well
> served by the current infrastructure (mirror.hydra.gnu.org -> North
> America, ci.guix.info -> Europe), so I'm not sure spending resources on
> a CDN is worthwhile in this context.

I think the good bandwidth is the second motivation for the CDN, but
it’s true that it still benefits the same groups of people; in
particular we know that Cloudfront is unavailable in China.

Nevertheless the extra performance is welcome IMO.  I think substitute
delivery plays an important role in the user experience so if we can
improve it, the better.

> I'd rather see this (even modest) amount put into the hands of a
> motivated hacker to work on a distributed solution instead of
> encouraging a company which do not share our free software ideals.

As discussed before, I definitely sympathize with this.  Heck, if
someone had told me I’d argue in favor of a CDN after all this time
spent filling in CloudFare CAPTCHAs just because CloudFare decided that
user privacy doesn’t matter and that Tor users should be penalized, I’d
have laughed.  ;-)

So it’s definitely not an easy decision.  Nevertheless, we have to
acknowledge the fact that our current substitute delivery infrastructure
is fragile.  If people volunteer to maintain a set of mirrors with some
load balancing, that’s great, I’m all for it.  But for now, we don’t
have that at all, hence the CDN.

Longer term, I do hope for IPFS to become our main delivery mechanism.
I’ve posted a proof-of-concept that I think should allow us to get
started, play with the idea, and find out how that works in practice.

Thanks,
Ludo’.

Re: Publishing with Lzip

[Pierre Neidhardt]

> I can give it a spin.

Thanks!

> It’d be great to gain some confidence about these things.  :-) I haven’t
> looked at the patch yet, but if you haven’t done it yet, I’d suggest
> having tests like the one in tests/zlib.scm (compress and decompress a
> bytevector of a random size with random contents), and you could
> possibly perform more “stressful” tests manually as well (try to
> compress/decompress tarballs, etc.)

I've copied your test for zlib, it passes! :)

> I’d also recommend to re-read the API doc in the headers or whatever.
> IME these APIs are very tricky to use and one has to pay attention to
> every small detail.

I read the manual too many times.  The headers are not documented.  The examples
don't tell us more about the API.

I might be too inexperienced in the area, so maybe you or someone else could
have a look at the manual.

Else we could contact the maintainer and ask directly :D

> According to the C standard an enum is an ‘int’.  So mapping them is
> just a matter of producing/consuming ints.  The values of the enum start
> from 0 and are incremented by 1 from then on, unless specific values are
> provided.

My question was whether it's possible to have the mapping done "symbolically."
In C, you would match error values again the symbols of the enum, not against
the number.  So if we map the error numbers manually in Guile, it would break
whenever the API updates the enum.

Maybe I'm just being overly picky here :p

Cheers!

-- 
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Description: PGP signature

Re: Publishing with Lzip

[Ludovic Courtès]

Hi Pierre,

Pierre Neidhardt  skribis:

> I've just sent a patch of a first draft for the Lzip bindings:
>
>   http://debbugs.gnu.org/cgi/bugreport.cgi?bug=34807
>
> Switching from Gzip (Zlib) to Lzip would save up to some 50% disk usage
> for substitutes which would greatly benefit the servers and help
> reducing the bandwidth usage.

Woohoo, awesome!

> A few things are missing in the patch and I would probably need some help:
>
> - The %liblz variable in guix/config.scm.in is not set dynamically by
>   autoconf.
>   This is because lzlib does not have a pkg-config entry.  I don't know
>   much about autoconf, so if someone knows how to do this properly...

I can give it a spin.

> - I'm still a bit confused about how the API is supposed to work.  There
>   is a lz-(de)compress-finish function which is supposed to be called
>   according to the examples but the manual does not really says why.  If
>   I call it, the tests fail.
>
> - I'm also not 100% I'm doing the right thing with the encoder/decoder:
>   should we write everything first, then read as much as we can?  Or
>   chain write-read calls like in bbexample.c?
>
> - I'm not 100% sure either that the terminating chunk will always be
>   compressed / decompressed.  (It works in the test though.)  I don't
>   really understand how Lzlib handles that part.

It’d be great to gain some confidence about these things.  :-) I haven’t
looked at the patch yet, but if you haven’t done it yet, I’d suggest
having tests like the one in tests/zlib.scm (compress and decompress a
bytevector of a random size with random contents), and you could
possibly perform more “stressful” tests manually as well (try to
compress/decompress tarballs, etc.)

I’d also recommend to re-read the API doc in the headers or whatever.
IME these APIs are very tricky to use and one has to pay attention to
every small detail.

> - How can I map between C enums and Guile with dynamic FFI?  This would
>   be useful to have improve error messages.

According to the C standard an enum is an ‘int’.  So mapping them is
just a matter of producing/consuming ints.  The values of the enum start
from 0 and are incremented by 1 from then on, unless specific values are
provided.

> - lzlib.scm is not used for publishing in the patch.  Will do that
>   later.  What are the strategies for transitioning from .gz to .lz?  I
>   suggest the following:
>
>   - On publishing, replace .gz with .lz compression.
>   - When extracting, check the type and call the appropriate format 
> decompressor.

The strategy I think would be to first have the complete tool chain in
Guix, that is support in ‘guix substitute’ and ‘guix publish’.

We won’t be able to change our servers to produce lzip overnight,
because old instances of ‘guix substitute’ wouldn’t be able to consume
it.

Perhaps one option would be to allow ‘guix publish’ to produce both gzip
and lzip, which we’d use during some transition period.  The difficulty
would be that narinfos currently provide just one URL for the nar, so
we’d need to either provide several URLs, or provide the right URL based
on some appropriate HTTP request header.  Let’s focus on the rest for
now.  :-)

Thank you!

Ludo’.

Re: Guix pronunciation

[Laura Lazzati]

> Now I'm wondering how to pronounce Guile... :D
Don't know if you are kidding ;), but even not being a native English
speaker  it was quite obvious for me :) Or I ponounce it badly, don't
know.

Regards :)

Re: Regarding freedom issues

[Dimakakos Dimos]

swedebugia  writes:

> Hi.
> I had the idea of integrating guix more with GNU when it comes to packages 
> with freedom issues.
>
> The idea is to add to guix a way to inform the user that the package they 
> just searched for is not included in guix because of freedom issues.
>
> The idea is that when we refuse a package to be included we add it with a 
> short reason to this list.
>
> Something like this
> (issues
>   (package odoo
>   (reason "trapping users by withholding update scripts, see 
> gnu.org/link.to.article"
>   (alternatives '(dolibarr tryton smbledger ledger hledger gnucash)))
>
> This makes it clear to the user that they can scratch the itch and fix the 
> problems by contacting upstream, fork or whatever or choose a better 
> alternative. 
>
> What do you think?
> -- 
> Sent from my k-9 mail for Android.

I like this as well. We could then make lists of alternatives, so they
could be resusable in similar contexts.

The thing is this seems quite a bit of work, but I think it's in the
right direction. Maybe reuse some catalogs of "non-freedom respecting"
software is doable.

Re: Regarding freedom issues

[Boris A. Dekshteyn]

Hello,

swedebugia  writes:

> or choose a better alternative. 

Debian?

> What do you think?

I mean, from a marketing point of view, this is just a terrible
idea. imo of course.

---
 WBR, Boris Dekshteyn

Re: building "guix deploy"

[Ludovic Courtès]

Howdy!

Christopher Lemmer Webber  skribis:

> Ludovic Courtès writes:

[...]

>> Error reporting in (guix ssh) is, ahem, not as good as it could be.
>>
>> Apparently the SSH channel was closed prematurely, which could be due to
>> a number of things:
>>
>>   1. Are ‘guix’ and ‘guile’ in $PATH on the remote machine, for
>>  non-interactive shells?
>>
>>   2. Is ‘guix repl’ available in the remote machine?
>>
>> You can test this with:
>>
>>   ssh HOST guile --version
>>   ssh HOST guix repl --version
>
> Yep, both respond with
>   guile (GNU Guile) 2.2.4
> and
>   guix (GNU Guix) 0.16.0-10.2637cfd
> respectively.
>
>> Also, does ‘guix copy’ fail similarly when sending files to that host?
>
> It seems it does:
>
> cwebber@jasmine:~/devel/librelounge-audio$ guix copy 
> --to=test.activitypub.rocks pidgin
> guile: warning: failed to install locale
> sending 37 store items (336 MiB) to 'test.activitypub.rocks'...
> ;;; [2019/03/11 10:39:25.573104, 0] write_to_channel_port: [GSSH ERROR] 
> Remote channel is closed: #
> Backtrace:
>   11 (primitive-load "/home/cwebber/.config/guix/current/bin…")
> In guix/ui.scm:
>   1654:12 10 (run-guix-command _ . _)
> In ice-9/boot-9.scm:
> 829:9  9 (catch _ _ # …)
> 829:9  8 (catch _ _ # …)
> In guix/status.scm:
> 810:4  7 (call-with-status-report _ _)
> In guix/scripts/copy.scm:
> 81:27  6 (send-to-remote-host _ _)
> In guix/ssh.scm:
> 313:4  5 (send-files # _ _ # _ # …)
> In guix/store.scm:
>   1505:12  4 (export-paths # _ # …)
>   1485:22  3 (export-path # _ # …)
>683:13  2 (process-stderr _ _)
>646:10  1 (dump-port # # …)
> In unknown file:
>0 (put-bytevector # …)
>
> ERROR: In procedure put-bytevector:
> Throw to key `guile-ssh-error' with args `("write_to_channel_port" "Remote 
> channel is closed" # #f)'.
>
> I wonder what got screwed up!

Could you, on test.activitypub.rocks, do something along these lines:

  sudo strace -p PID -s 300 -o log -f

where PID is the PID of the main ‘sshd’ process.

And after that, re-run ‘guix copy’, and grab the ‘log’.

Thanks,
Ludo’.

Re: Guix pronunciation

[Laura Lazzati]

Hi again!
Yes someone misses her community ;)

> As for those wondering why: “Guix” is initially just the contraction of
> Guile + Nix.
Thank you for the explanation. The person I met interested in at least
playing whith Guix told me that was thinking of both Guix and Nix, and
I was asked before about the differences. Is it in the manual? Because
I don't remember reading it.  Maybe it could be added, before the
pronunciation, WDYT?

Regards with mate :)
Laura

Re: boot multiple Gnu/Linux Distributions from one USB key

[Ricardo Wurmus]

gnuforever  writes:

> I configured a usb stick to boot multiple Gnu/Linux Distributions by
> following this tutorial:
> https://community.linuxmint.com/tutorial/view/1846
> It works for Tails, PureOS, Trisquel and Parabola
>
> I am trying to add GuixSD.
>
> For the menuentry, I always start from the grub.cfg embedded in the
> iso file.
> I add or remove options if needed.
>
> For GuixSD, I came up with this configuration:
> I used label instead of uuid.
>
> ## GUIXSD
> menuentry "GUIXSD - Gnu/Linux" {
> set isofile="/boot-isos/guixsd-install-0.16.0.x86_64-linux.iso"
> loopback loop (hd0,1)$isofile
> search --label --set GUIXSD_IMAGE
> linux
> (loop)/gnu/store/0zajbn9q39yva4l0zzrcshlll8qikzba-linux-libre-4.19.6/bzImage9
> --root=GUIXSD_IMAGE
> --system=(loop)/gnu/store/l4hgd4l7acrqwi3imav9akcvv4sbj85j-system
> --load=(loop)/gnu/store/l4hgd4l7acrqwi3imav9akcvv4sbj85j-system/boot
> initrd
> (loop)/gnu/store/9nqaksx40zh5d6cg5rim3f3spy56bfb9-raw-initrd/initrd.cpio.gz
> }
>
> It doesn't work. I get the following error message:
>
> waiting for partition 'GUIXSD_IMAGE' to appear...

Does a partition with this label exist?


-- 
Ricardo

Re: Config files without corresponding program

[Ludovic Courtès]

Hi mikadoZero,

mikadoZero  skribis:

> Tobias Geerinckx-Rice writes:
>
>> mikadoZero wrote:
>>> When I first installed Guix SD I followed the instructions in the
>>> manual.  I modeled my system off of the example system configuration
>>> template 'for a "bare bones" setup, with no X11 display server' from
>>> "8.1 Using the Configuration System" of the manual.
>>>
>>> In the home directories for both root and another user there where
>>> configuration files that did not have a corresponding program
>>> installed.
>>> The configuration files in question were:
>>>
>>> guile-wm - guile-wm
>>> gdbinit - gdb
>>> Xdefaults - xorg
>>> zprofile - zsh
>>>
>>> Is there a reason why does installing Guix SD leave these
>>> configuration
>>> files in the home directories?
>>
>> These files are created by DEFAULT-SKELETONS in (gnu system shadow) to
>> make those programmes play well with Guix, because there's no way to
>> tell when or if the user will use them.  So everything is fine.
>
> What about the scenario where someone deletes these seemingly unneeded
> configuration files because they are not using the program?

That’s fine, you can delete them or modify them at will.  There are
meant mostly to help people get started.  For instance, figuring out the
right line in ~/.gdbinit to have GDB find debugging symbols would take
some reading, while here you’ll just have it work out of the box.

HTH,
Ludo’.

Re: Regarding freedom issues

[Ricardo Wurmus]

swedebugia  writes:
> The idea is to add to guix a way to inform the user that the package
> they just searched for is not included in guix because of freedom
> issues.
>
> The idea is that when we refuse a package to be included we add it
> with a short reason to this list.
>
> Something like this
> (issues
>   (package odoo
>   (reason "trapping users by withholding update scripts, see 
> gnu.org/link.to.article"
>   (alternatives '(dolibarr tryton smbledger ledger hledger gnucash)))

I don’t think it’s a good idea to clutter Guix with packages that we
won’t add.  There’s already a lot in Guix to provide free software
packages; I don’t think we should add “negative packages”.

That’s out of scope for Guix and could be handled by some other GNU
resource instead.

--
Ricardo

Re: Guix pronunciation

[Ludovic Courtès]

Hi,

Tobias Geerinckx-Rice 
skribis:

> mikadoZero wrote:
>> Doing this duckduckgo site search:  `geeks
>> site:https://www.gnu.org/software/guix/` gives me only one match.
>> Which
>> is footnote 1 of section 1 Introduction of the manual.  I do not
>> know of
>> anywhere else where the pronunciation of Guix is explicitly stated.
>>
>> I would like to know what other think about making the pronunciation
>> of
>> Guix obvious to anyone who visits the website.
>
> I think this is a good idea!

Yup, why not!

Though I think it’s no big deal: people who’ve seen talks or have read
the manual know how to pronounce it, others may pronounce it in their
own way, but that’s fine.  (Think of all those who pronounce TeX like
“teks” after all those years.  :-))

As for those wondering why: “Guix” is initially just the contraction of
Guile + Nix.

Ludo’.

Re: Missed testing

[Danny Milosavljevic]

FWIW, I agree that error handling when booting the Guix system leaves a lot to
be desired.

Because of the system rollback feature it's not so bad, but we should advertise
that feature, and that ",bournish" works, before dropping into the repl.

Also, that doesn't help on initial installation which should be made much more
user-friendly.

> Still not addressed is why users section stops being defined when one
> copy and pastes that example text onto the configuration.

That sounds very strange and would be a very bad bug.

> Nor the fact that luks boot with that example configuration never
> prompts for the luks password and just goes to a very unhappy place and
> drops the user in a guile shell to sort things out and we lack
> documentation with how to deal with that case.

I'm using luks home with current guix master and it prompts for my password.

(define dayas-home (mapped-device
 (source (uuid "531005b3-71a1-4784-aa2a-11f68682c6da"))
 (target "dayas-home")
 (type luks-device-mapping)))

(operating-system
  (mapped-devices (list dayas-home))
  (file-systems ...
   (file-system
(device "/dev/mapper/dayas-home")
(mount-point "/home")
(type "btrfs")
(needed-for-boot? #f)
(mount? #t)
(check? #t)
(dependencies (list dayas-home)

> Users are going to hit edge cases, when we write them; we really don't
> want the users to have to read 100,000+ lines of code to try to
> figureout how to deal with them.

I agree.  These kind of bug reports are very useful.

I've learned to not step on the mines, but better would be to have nicer
failure modes.

I'll be so happy when the TUI installer is the default way to install Guix.
Installing Guix manually is not fun.

The installer can and should be made to automatically amend the system
config by mptspi etc.


pgpBKvLcirYF6.pgp
Description: OpenPGP digital signature

Re: Missed testing

[Jeremiah]

> This depends on your hardware and the modules that the kernel loaded in
> response upon booting.  There is no way to have a static resource as the
> example configuration reflect the modules that can be automatically
> loaded by the kernel on all hardware configurations out there.
Ok, that is fine. Now why isn't there commented out code in the example
with comments saying that?

Still not addressed is why users section stops being defined when one
copy and pastes that example text onto the configuration.

Nor the fact that luks boot with that example configuration never
prompts for the luks password and just goes to a very unhappy place and
drops the user in a guile shell to sort things out and we lack
documentation with how to deal with that case.

Users are going to hit edge cases, when we write them; we really don't
want the users to have to read 100,000+ lines of code to try to
figureout how to deal with them.

-Jeremiah

Re: boot multiple Gnu/Linux Distributions from one USB key

[Tobias Geerinckx-Rice]

gnuforever (yay!),

gnuforever wrote:
I configured a usb stick to boot multiple Gnu/Linux 
Distributions by

following this tutorial:
https://community.linuxmint.com/tutorial/view/1846
It works for Tails, PureOS, Trisquel and Parabola


It works because these distributions have specific support for 
loopback booting, which is a non-trivial amount of work.  You'll 
note the following in the GRUB menu entry for ‘pclinuxos’:


 linux … bootfromiso=/boot-isos/pclinuxos64-kde-2014.05.iso …

This tells the pclinuxos early user space (initramfs) that it 
should do some loop mounting and other magic before mounting the 
root partition.  You'll also note that Debian-based distributions 
use a completely different magic word:


 linux … iso-scan/filename=$isofile …

because none of this is standardised or transparent.  It's an 
explicit distro feature that needs to be implemented somewhere in 
the init code.



I am trying to add GuixSD.


Unfortunately, the Guix System doesn't implement anything like 
that yet.


For the menuentry, I always start from the grub.cfg embedded in 
the

iso file.
I add or remove options if needed.

For GuixSD, I came up with this configuration:
I used label instead of uuid.

## GUIXSD
menuentry "GUIXSD - Gnu/Linux" {
set 
isofile="/boot-isos/guixsd-install-0.16.0.x86_64-linux.iso"

loopback loop (hd0,1)$isofile
search --label --set GUIXSD_IMAGE
linux
(loop)/gnu/store/0zajbn9q39yva4l0zzrcshlll8qikzba-linux-libre-4.19.6/bzImage9
--root=GUIXSD_IMAGE
--system=(loop)/gnu/store/l4hgd4l7acrqwi3imav9akcvv4sbj85j-system
--load=(loop)/gnu/store/l4hgd4l7acrqwi3imav9akcvv4sbj85j-system/boot
initrd
(loop)/gnu/store/9nqaksx40zh5d6cg5rim3f3spy56bfb9-raw-initrd/initrd.cpio.gz
}

It doesn't work.


Well, it works up to and including booting the kernel, which is 
still pretty cool when you think about it :-)


Unfortunately, all off GRUB's loopback magic is local to GRUB. 
You can't use it to make virtual drives appear in other operating 
systems.  (Well, maybe DOS, but that's more D than OS anyway.)



I get the following error message:

waiting for partition 'GUIXSD_IMAGE' to appear...


Once the kernel boots, Guix's early userspace only looks for real 
partititions.  It won't peek inside random files to see if they 
contain a file system.  And there's currently no way to tell it 
to.


I wonder if MAPPED-DEVICES could be a solution here, with a bit 
(heh) of extra code…


Is there any other way to configure multiple Gnu/Linux distros 
to boot

from one usb?


TL;DR: there is no one reliable way, only distro-specific support.

Kind regards,

T G-R

Re: Guix trademarked by Express Logic

[ng0]

Leo Famulari transcribed 1.5K bytes:
> On Mon, Mar 11, 2019 at 08:31:40PM -0400, mikadoZero wrote:
> > Reading the recent press release linked it is clear that Express Logic
> > is continuing to invest more in their Guix trademarked product over
> > time.  As a result of this it is increasing likely that Express Logic
> > could request that the Guix free software project stop using it's
> > trademark.  Correspondingly it looks less likely that it will just go
> > away.
> 
> We will cross this bridge when we come to it.

Oh this was in 2019. Right. I noticed this earlier this
year but somehow dismissed the year.


signature.asc
Description: PGP signature

Re: Express Logic claims GUIX trademark

[Tobias Geerinckx-Rice]

Hullo,

Hartmut Goebel wrote:

Am 11.03.19 um 20:00 schrieb Tobias Geerinckx-Rice:

It took me all of 20 seconds to find the actual GUIX trademark
registration[1], so we can stop basing this discussion on 
regrettable

typographical choices in press releases.

It's 4 months old. 


As Pjotr already stated: we should get in touch with the FSF to 
make

them file a case against this trademark.


Well, I wasn't talking about my own lawyer :-p

There's also the Free Software Conservancy (sfconservancy.org) but 
I agree that, as a part of GNU, we should deal with this through 
the FSF.  That's up to the maintainers to decide.



Also this might to so easy:


‘not be’?

- The registration says: "First use 2014" and "Use in Commerce 
2014".
Thus we need to proof we used "guix" earlier, e.g. using 
archive.org [1]


Good, that's trivial.  Cue legal bikeshedding over the meaning of 
‘commerce’, I guess.


- We should also check for trademark registrations in other 
areas, e.g.

Europe, India, China.


AFAICT the mark is not registered in Europe.  The question is 
whether it needs to be to be ‘enforced’ by EL.


- It might even be useful to invest ~300 € for registering GUIX 
as a

trademark in Europe.


It's nice™ that we already have a legal entity named ‘Guix Europe’ 
ready to do so if necessary.


Kind regards,

T G-R

Re: Express Logic claims GUIX trademark

[Hartmut Goebel]

Am 11.03.19 um 20:00 schrieb Tobias Geerinckx-Rice:
> It took me all of 20 seconds to find the actual GUIX trademark
> registration[1], so we can stop basing this discussion on regrettable
> typographical choices in press releases.
>
> It's 4 months old. 


As Pjotr already stated: we should get in touch with the FSF to make
them file a case against this trademark. Also this might to so easy:

- Unfortunately we missed the opposition period (which is only 30 days
in the US, while in 3 Month Europa), which stated in November.

- The registration says: "First use 2014" and "Use in Commerce 2014".
Thus we need to proof we used "guix" earlier, e.g. using archive.org [1]

- We should also check for trademark registrations in other areas, e.g.
Europe, India, China.

- It might even be useful to invest ~300 € for registering GUIX as a
trademark in Europe.

[1]

archived 2012-12-25


-- 

Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: Regarding freedom issues

[Pierre Neidhardt]

Interesting, I like it!

-- 
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Description: PGP signature

Regarding freedom issues

[swedebugia]

Hi.
I had the idea of integrating guix more with GNU when it comes to packages with 
freedom issues.

The idea is to add to guix a way to inform the user that the package they just 
searched for is not included in guix because of freedom issues.

The idea is that when we refuse a package to be included we add it with a short 
reason to this list.

Something like this
(issues
  (package odoo
  (reason "trapping users by withholding update scripts, see 
gnu.org/link.to.article"
  (alternatives '(dolibarr tryton smbledger ledger hledger gnucash)))

This makes it clear to the user that they can scratch the itch and fix the 
problems by contacting upstream, fork or whatever or choose a better 
alternative. 

What do you think?
-- 
Sent from my k-9 mail for Android.