Re: bug#48941: [powerpc64le-linux] libfaketime CLOCK_MONOTONIC test hangs

[Chris Marusich]

Hi,

I need a little help figuring out how to use gdb in Guix for bug 48941:

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=48941

Here's the situation.  A libfaketime test hangs forever.  Upstream
suggested I debug it.  I'm trying to, but gdb errors out.  What am I
doing wrong?  It's probably something simple, but I can't see what.

I'll describe what I've done.  First, I started a build like so:

  ./pre-inst-env guix build --keep-failed libfaketime

While the problematic test hung, I found the PID of the test and killed
it.  This caused the build to fail, leaving the build environment for me
to play around in.

I entered a pure environment that contains all the things I need to
debug the test (gcc 10.3.0 is currently the default gcc on
core-updates):

  ./pre-inst-env guix environment --pure libfaketime --ad-hoc 
gcc-toolchain@10.3.0 gcc-toolchain@10.3.0:debug gdb

In the pure environment, I confirmed I can build and run the hanging
test via the following commands (I added -g in order to get debug
symbols):

  make FAKETIME_COMPILE_CFLAGS='-DFORCE_MONOTONIC_FIX -g' CC=gcc 
PREFIX=/tmp/guix-build-libfaketime-0.9.9.drv-0/myprefix
  make FAKETIME_COMPILE_CFLAGS='-DFORCE_MONOTONIC_FIX -g' CC=gcc 
PREFIX=/tmp/guix-build-libfaketime-0.9.9.drv-0/myprefix test

OK, so I can trigger the hang.  Great!  Next step, fire up GDB:

--8<---cut here---start->8---
[0] [env] marusich@suzaku:/tmp/guix-build-libfaketime-0.9.9.drv-0/source/test
$ gdb ./timetest
GNU gdb (GDB) 10.2
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "powerpc64le-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./timetest...
(gdb) 
--8<---cut here---end--->8---

The debug symbols provided by gcc-toolchain@10.3.0:debug are under
$GUIX_ENVIRONMENT/lib/debug.  This is the value of GUIX_ENVIRONMENT:

--8<---cut here---start->8---
$ echo $GUIX_ENVIRONMENT
/gnu/store/32fjhp30k34fh0g9f1gmgcj8pc5wldq6-profile
--8<---cut here---end--->8---

By the way, this directory corresponds to glibc 2.33:

--8<---cut here---start->8---
$ realpath /gnu/store/32fjhp30k34fh0g9f1gmgcj8pc5wldq6-profile/lib/debug
/gnu/store/8akrlhc25d7xvi85gzvginw0vdi4zyg4-glibc-2.33-debug/lib/debug
--8<---cut here---end--->8---

Let's tell GDB where to find those debug symbols:

  (gdb) set debug-file-directory 
/gnu/store/32fjhp30k34fh0g9f1gmgcj8pc5wldq6-profile/lib/debug

Let's also tell GDB to set the environment variables that upstream
recommended when running the test program:

--8<---cut here---start->8---
(gdb) set environment LD_PRELOAD=../src/libfaketime.so.1
(gdb) set environment FAKETIME=-10d
(gdb) set environment NO_FAKE_STAT=1
--8<---cut here---end--->8---

Now run it:

--8<---cut here---start->8---
(gdb) run
Starting program: /tmp/guix-build-libfaketime-0.9.9.drv-0/source/test/timetest 
/bin/sh: /lib/powerpc64le-linux-gnu/libc.so.6: version `GLIBC_2.33' not found 
(required by ../src/libfaketime.so.1)
/bin/sh: /lib/powerpc64le-linux-gnu/libc.so.6: version `GLIBC_2.32' not found 
(required by 
/gnu/store/kmblbljiygayhlc5gb02an9imhy90ws9-glibc-2.33/lib/libpthread.so.0)
/bin/sh: /lib/powerpc64le-linux-gnu/libc.so.6: version `GLIBC_2.32' not found 
(required by 
/gnu/store/kmblbljiygayhlc5gb02an9imhy90ws9-glibc-2.33/lib/libdl.so.2)
/bin/sh: /lib/powerpc64le-linux-gnu/libc.so.6: version `GLIBC_2.32' not found 
(required by 
/gnu/store/kmblbljiygayhlc5gb02an9imhy90ws9-glibc-2.33/lib/librt.so.1)
During startup program exited with code 1.
(gdb) 
--8<---cut here---end--->8---

Huh?  What happened?  I've double checked that I'm using gdb provided by
Guix:

--8<---cut here---start->8---
$ type -P gdb
/gnu/store/32fjhp30k34fh0g9f1gmgcj8pc5wldq6-profile/bin/gdb
--8<---cut here---end--->8---

I also tried running gdb by invoking it via that absolute file name, and
it still errored out in the same way.

I'm operating in a --pure environment.  All the tools are provided by
Guix.  I'm surprised that /bin/sh and /lib are even mentioned above.

If anyone can 

Re: Create branch for Haskell build changes and updates?

[Ricardo Wurmus]

Xinglu Chen  writes:

Thank you for bringing this up!  I posted a WIP patch for adding 
GHC

8.10 a while ago, but nobody showed any interest[1].

I don’t have any experience with updating the Haskell toolchain 
in Guix,
but I think it would be great to have a separate branch for 
updating the

haskell-build-system and Haskell packages.  :)

[1]: https://yhetil.org/guix-devel/87o8cgfbg1@yoctocell.xyz/


It would be good to send this to guix-patc...@gnu.org instead of 
guix-devel.  Please also see the Contributing section in the 
manual.


--
Ricardo

Re: Create branch for Haskell build changes and updates?

[Philip Munksgaard]

On Tue, 20 Jul 2021, at 18:49, Ricardo Wurmus wrote:
> 
> Philip Munksgaard  writes:
> 
> > Who do we talk to to get this in place?
> 
> Me, for example.
> 
> Sorry, I got sick and haven’t been doing anything towards getting 
> wip-haskell started.
> 
> I’ll try to do this tonight:
> 
> - branch off wip-haskell from core-updates
> - apply https://issues.guix.gnu.org/49199
> - create a new job set for wip-haskell
> 

Sounds great! Who gets commit access to that branch?

I'm new to guix (and mail-based development in general), so I'm sorry if that's 
a stupid question.

Re: Early feedback on Guix Home

[Andrew Tropin]

Ludovic Courtès  writes:

> Hi,
>
> (Sorry for the late reply…)
>
> Andrew Tropin  skribis:
>
>> Ludovic Courtès  writes:
>
> [...]
>
> Possible action:
>
>   1. Change config records to accept file-like objects instead of
>  strings.  That way, users can choose to have snippets inlined (in a
>  ‘plain-file’ object) or separate (via ‘local-file’).  See for
>  example how ‘tor-configuration->torrc’ does it.

 Yeah, there is a ‘slurp-file-gexp’ procedure that let’s one read an
 extenal file, but using existing APIs like ‘local-file’ is probably a
 better idea.
>>>
>>> Yes, it feels more natural.  Also, ‘slurp-file-gexp’ returns a gexp (a
>>> code snippet), but as a user you don’t know where that snippet is going
>>> to be inserted; it may not work in some contexts.
>>
>> Acually, the idea behind `slurp-file-gexp` is that you always know where
>> it will be inserted, because it will be inside the specific section of
>> the configuration.  Take a look at emacs home-service example:
>> https://git.sr.ht/~abcdw/rde/tree/master/item/gnu/home-services/emacs.scm#L91
>
> What I mean is that, in a general sense, one cannot know whether the
> gexp will be inserted in a place where it’s “valid”.  Consider the
> following examples, where the gexp is meant to be inserted in lieu of
> “PLACEHOLDER”:
>
>   #~(list '(#$PLACEHOLDER))  ;it’s quoted
>
>   #~(let ((call-with-input-file (const #f)))
>   #$PLACEHOLDER)
>
> These are “hygiene” problems discussed in the “Code Staging in GNU Guix”
> paper.
>
> All this to say that, from an API viewpoint, I think it’s (1) more
> robust, as I wrote, and (2) clearer to expect file-like objects in such
> places.  It’s clearer because users can be expected to have an
> understanding of what ‘local-file’ does, whereas ‘slurp-file-gexp’ is
> more involved.
>
> I hope this clarifies what I had in mind!
>
> Ludo’.

Got the problem.  Will take a closer look, when will be preparing this
code for upstreaming and maybe will reconsider the approach or will rise
another discussion on that.  Also, need to schedule a reading of your
paper on gexps)

Thank you for clarification!)


signature.asc
Description: PGP signature

Re: Create branch for Haskell build changes and updates?

[Ricardo Wurmus]

Philip Munksgaard  writes:


Who do we talk to to get this in place?


Me, for example.

Sorry, I got sick and haven’t been doing anything towards getting 
wip-haskell started.


I’ll try to do this tonight:

- branch off wip-haskell from core-updates
- apply https://issues.guix.gnu.org/49199
- create a new job set for wip-haskell

--
Ricardo

Re: Create branch for Haskell build changes and updates?

[Philip Munksgaard]

Any updates on this? Who do we talk to to get this in place?

Best,
Philip

Re: Audacity has new administration

[Chris Lemmer-Webber]

Mark H Weaver writes:

> Hi,
>
> Bone Baboon  writes:
>
>> My initial message in this email tread did not clearly communicate what
>> the issues with Muse Group's new privacy policy for Audacity are.
>>
>> The two main issues are the on by default telemetry and that Audacity
>> can no longer be used for any purpose contradicting freedom 0.
>>
>> # On by default telemetry
>>
>> On by default telemetry is being introduced to Audacity.  This does not
>> comply with the No Malware section of the FSDG.
>> 
>>
>> The on by default telemetry collects IP address information, system
>> information and Audacity version information.
>> 
>> 
>> 
>
> Thanks for letting us know about this.  When the telemetry functionality
> was first added a few months ago, they emphasized that it was disabled
> by default.  Now it seems that they have changed their minds and intend
> to enable some telemetry by default.
>
> We'll need to keep an eye on this, to ensure that all telemetry is
> disabled by default in Guix.
>
>> # Freedom 0
>>
>> Audacity can no longer be used for any purpose.  Section 3 of the Muse
>> Group's new privacy policy for Audacity
>>  says:
>>
>>> 3 Minors
>>>
>>> 1 The App we provide is not intended for individuals below the age
>>> of 13. If you are under 13 years old, please do not use the App.
>
> I'm not a lawyer, but nonetheless I'm _highly_ confident that this
> language in their (draft) privacy policy has no binding force.  By
> publishing Audacity's source code under a free software license, they
> have irrevocably granted the four freedoms to anyone who has a copy.
> Any license that would allow the copyright owner(s) to restrict the four
> freedoms is not a free software license.
>
> Moreover, their privacy policy is irrelevant if they aren't able to
> collect any information about us.  By disabling telemetry, we ensure
> that their privacy policy is irrelevant to Guix users who do not
> "opt-in".

I think that seems right.  Also there's a fork of Audacity in progress
called "Tenacity", but it seems early days.  It might be worth
considering that.

I have to say that initially I was unsure how well to interpret the Muse
Group acquisition in terms of with good or bad faith... maybe these were
just blunders.  Well, I've been fully corrected of that by this recent
post:

  
https://web.archive.org/web/20210719115639if_/https://github.com/Xmader/musescore-downloader/issues/5#issuecomment-882450335

Basically the person in charge of that takeover trying to perform an
aggressive takedown of a download tool, resorting to direct threats
about using an alleged copyright infringement to get someone to be
deported to their allged country of origin, and directly stating that
the person should consider that since they performed some actions of
political criticism against that country, they could be tortured or
killed if not complying with that takedown.

We should assume that the current copyright holder / maintainer is not
going to behave in a user freedom friendly way at all based on that
information.

 - Chris