bug#32840: linux-libre 4.18.9: shpchp is no longer a module (now: built-in)

[Nils Gillmann]

Ricardo Wurmus transcribed 808 bytes:
> 
> Mark H Weaver  writes:
> 
> > Nils Gillmann  writes:
> >
> >> at taler we need shpchp as a module in the initrd.
> >>
> >> Before version 4.18.x, shpchp was a module we've build in guix' 
> >> linux-libre,
> >> you were able to just specify it for the initrd.
> >>
> >> With 4.18.9, this module became a compile-in/built-in (see linux
> >> commit log).  I want to avoid maintaining yet another kernel
> >> definition for future complications if I can.  Can we get this module
> >> built in by default?
> >
> > Done in commit fe73352e8073ea0a0e6f6b5591f24395671998ab on master.
> > Closing this bug now, but please reopen if appropriate.

Thanks! I'll get back if this didn't fix upgrading the server.

> I don’t understand why building it as a module is needed when upstream
> decided to turn it into a built-in feature.
> 
> Could you please explain?

There are modules [M] and boolean y/n "builtins" in Linux. We don't need
to build it as a module now, since upstream changed it to be a builtin.
It is not covered by whatever selection we have in the kernel config as
builtins. Since the module disappeared, users of the module were left
with the choice to remove it and either build their own kernel variation
or ask for it as a feature.

I asked for it, since Taler wanted as little reliance on third-party
repositories as possible, no matter how reliable the repositories are.

> -- 
> Ricardo
> 
> 
> 
> 

bug#32836: emacs-magit is broken (and probably others) due to package renaming

[Nils Gillmann]

Alex Kost transcribed 331 bytes:
> Pierre Neidhardt (2018-09-25 17:04 +0200) wrote:
> 
> > Oopsy, missed that indeed! xD
> > Sorry for the trouble, will fix as soon as possible.
> >
> > By the way, I think using "name" for URLs is a bad practice, we only need
> > "version" there.  What do you people think?
> 
> I totally agree!  I don't like this practice very much.
> 
> -- 
> Alex
> 
> 
> 

Very often the name we use, except for language specific packages, is the same
as upstream uses. "name" can be shorter than "whatever-long-name".

bug#32840: linux-libre 4.18.9: shpchp is no longer a module (now: built-in)

[Nils Gillmann]

Hi,

at taler we need shpchp as a module in the initrd.

Before version 4.18.x, shpchp was a module we've build in guix' linux-libre,
you were able to just specify it for the initrd.

With 4.18.9, this module became a compile-in/built-in (see linux
commit log).  I want to avoid maintaining yet another kernel
definition for future complications if I can.  Can we get this module
built in by default?

I consider it a bug as the functionality was given before and
disappeared now, leaving our system unable to upgrade unless I write
some code around it.

Thanks.

bug#30680: [racket-users] Using Racket's raco on on Guix(SD)

[Nils Gillmann]

Christopher Lemmer Webber transcribed 3.3K bytes:
> Timothy Sample writes:
> 
> > Christopher Lemmer Webber  writes:
> >
> >> Konrad Hinsen writes:
> >>
> >>> In my tests, all packages ended up working, but performance is indeed
> >>> worse than with a Racket installation outside of Guix.
> >>>
> >>> It would be nice if someone with more knowledge of Racket internals
> >>> could give a hint or two for debugging this issue!
> >>>
> >>> Konrad.
> >>
> >> I'm posting a bug bounty on this issue: if someone can fix this I will
> >> pay them $250 USD.  I don't have the time or knowledge enough of Racket
> >> internals to do so myself.
> >
> > I have discovered a few things, but I’m not sure how to fix the
> > underlying problem(s).
> >
> > The reason Racket is trying to recompile the OpenSSL files is because of
> > a hash mismatch.  This can be seen by enabling debugging output:
> >
> > $ PLTSTDERR=debug raco setup openssl
> >
> > Which says a lot of things, but most interestingly it says:
> >
> > 
> > ...
> > compiler/cm: checking: 
> > /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/openssl/libcrypto.rkt
> > compiler/cm: different src hash... 
> > (5d9ca57f3e267d956c7b5e62578467beb8ccc1d2 
> > 4d21ac412723fbf33f97669c2f73f0e9367f4510)
> > compiler/cm: maybe-compile-zo starting 
> > /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/openssl/libcrypto.rkt
> > compiler/cm:   start-compile: 
> > /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/openssl/libcrypto.rkt
> > compiler/cm:   compiling 
> > /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/openssl/libcrypto.rkt
> > open-output-file: cannot open output file
> >   path: 
> > /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/openssl/compiled/tmp15340167971534016797570
> >   system error: Read-only file system; errno=30
> >   context...:
> > ...
> > 
> >
> > This hash mismatch is caused by grafting.  When the package is built,
> > the path to OpenSSL gets hard-coded in a source file.  The SHA-1 hash
> > for this file is stored in its “.dep” file.  When the output is
> > grafted, the source file gets updated with a new OpenSSL path, but the
> > hash does not get updated.  This makes Racket think that the cached
> > bytecode file is incorrect (even though it was likely grafted too),
> > and it tries to recompile it.  It fails because it tries to write this
> > new bytecode file to the store.
> 
> Interesting... I hadn't even considered grafting.  (I still wonder why
> it's even trying to open *any* file in the store for output though...)
> 
> > I double checked this by trying with an ungrafted Racket, and got better
> > results.  (There was still a warning about writing to the store, but it
> > seemed less significant.)
> 
> Cool!
> 
> > The only thing I can think of for a fix would be to patch Racket to be
> > more lenient with bytecode files in the store.  That is, ignore hash
> > mismatches in store-files.  I might give this a try later tonight if
> > nobody has any better ideas.
> >
> > -- Tim
> 
> BTW, some examples of packages where I've had trouble, in case it helps
> with testing:
> 
>  - Raart
>  - Gregor
>  - crypto (seemed to work last time, not sure why it wasn't working before)
> 
> Though at this point I also can't do just "raco setup" on a local
> package either, but maybe resolving this issue will fix that.
> 
From what I've learned in the last couple of hours, the last problem could
be due to leftovers in your raco / dotRacket folder from an older installation.

bug#32339: "nix import" fails

[Nils Gillmann]

Hooray, a bad subject line!

* nixpkgs is on commit d817ccbf832419abdd82bc617e058b8a196f6e98
* guix is on commit 6915d20f05363f61cef9c4ed7ebda3fe5a19325d
* GUIX_PACKAGE_PATH is unset

FWIW, this was while running the Nix daemon with my "service", but it
is not required for the imports.


abyayala$ guix import nix ~/re-src/nixpkgs curl
;;; SSAX warning: Skipping PI: xml

trace: stdenv.isArm is deprecated after 18.03
trace: lib.zip is deprecated, use lib.zipAttrsWith instead
trace: Warning: `showVal` is deprecated and will be removed in the next 
release, please use `traceSeqN`
trace: `mkStrict' is obsolete; use `mkOverride 0' instead.
trace: `lib.nixpkgsVersion` is deprecated, use `lib.version` instead!
error: stack overflow (possible infinite recursion)
Backtrace:
In guix/import/snix.scm:
191:9 19 (loop # () #f _)
191:9 18 (loop # () #f _)
191:9 17 (loop # () #f _)
191:9 16 (loop # () #f _)
191:9 15 (loop # () #f _)
191:9 14 (loop # () #f _)
191:9 13 (loop # () #f _)
191:9 12 (loop # () #f _)
191:9 11 (loop # () #f _)
191:9 10 (loop # () #f _)
191:9  9 (loop # () #f _)
191:9  8 (loop # () #f _)
191:9  7 (loop # () #f _)
191:9  6 (loop # () #f _)
191:9  5 (loop # () #f _)
191:9  4 (loop # () #f _)
191:9  3 (loop # () #f _)
191:9  2 (loop # () #f _)
191:9  1 (loop # () #f _)
In sxml/upstream/SSAX.scm:
  1896:21  0 (_ # #f # …)

sxml/upstream/SSAX.scm:1896:21: Throw to key `parser-error' with args 
`(# "EOF while 
reading a token " "reading char data")'.

bug#32310: [Fwd: Re: bug#32310: Not having much luck with running guix of phone and limbo emulator.]

[Nils Gillmann]

- Forwarded message from Gary Hayes -

> Date: Tue, 31 Jul 2018 12:11:11 +1000
> From: Gary Hayes
> To: Nils Gillmann
> Subject: Re: bug#32310: Not having much luck with running guix of phone and 
> limbo emulator.
> 
> Had issues getting the vm file working in a qemu program limbo.
> Decided to give up at moment and deleted the vm files.  Have been
> experementing with damn small linux now.  Which kind of works but not quite
> well enough yet, but i still need to practice more.
> I am only running qemu on a 1.3ghz 4 core samsung phone so i dont expect
> much to run quickly.
> Best to simulate low end pentiums and 486 machines i think.  Not sure.
> Maybe incompatibilities between programs.  Also tried to find your help
> files on vm files being run and had difficulties geting enough info.
> 
> On 30 Jul 2018 7:49 pm, "Nils Gillmann" wrote:
> 
> Gary Hayes transcribed 509 bytes:
> > Tried to run vm of guix in limbo but did not work.  Now deleted.  May have
> > to stick with iso image live boots in future.
> 
> Hi Gary,
> 
> I'm sorry for your bad experiences. Can you tell us a bit more about
> your problems?
> 
> Thanks

- End forwarded message -

bug#32310: Not having much luck with running guix of phone and limbo emulator.

[Nils Gillmann]

Gary Hayes transcribed 509 bytes:
> Tried to run vm of guix in limbo but did not work.  Now deleted.  May have
> to stick with iso image live boots in future.

Hi Gary,

I'm sorry for your bad experiences. Can you tell us a bit more about
your problems?

Thanks

bug#32261: guix packages website: add mechanism to link to individual packages

[Nils Gillmann]

Paul Wise transcribed 1.8K bytes:
> Hi all,
> 
> It used to be possible to link to individual Guix packages like this:
> 
> https://www.gnu.org/software/guix/packages/m.html#myrepos
> 
> Since the recent change to the packages website the packages pages are
> paginated and have no anchors, which means they will break as more
> packages are added and also I cannot link directly to a package,
> only to a location that contains lots of other packages too.
> 
> https://www.gnu.org/software/guix/packages/M/page/3/
> 
> Fixing this would be useful for the Repology support of GNU Guix,
> which currently cannot link to GNU Guix packages:
> 
> https://repology.org/repository/gnuguix
> https://repology.org/metapackage/myrepos/versions
> 
> -- 
> bye,
> pabs
> 
> https://bonedaddy.net/pabs3/

It is not just repology, but easy linking to details for external
parties/downstreams we need to point to somewhere.

I think there were some remaining ideas for the new websites,
where a package gets detail page on its own.


The pages are statically generated, the old "useful" page format
was taking a very long time to load, with each release and increase
of package count we got k more seconds. Nothing I'd like to go back
to.

bug#32167: Kernel 'build' directory in the store is a broken symbolic link

[Nils Gillmann]

pki...@runbox.com transcribed 94 bytes:
> /run/booted-system/kernel/lib/modules//build is a broken 
> symbolic link.

Yep. This is not a bug until it comes to what you are possibly trying to 
attempt,
build a software which relies on your *current* kernel sources.

For a solution I can point to the Nix package for linux, where they deal with 
this
within the kernel package, for firmware and more. Because I'm short on time 
these
days I haven't sent a patch yet but I can confirm the issues you probably ran 
into
as I had them many months back already.

Mark, you are mostly responsible for the linux module in Guix.

Besides my own notes, this was relevant:
https://github.com/NixOS/nixpkgs/blob/master/pkgs/os-specific/linux/kernel/manual-config.nix#L161

bug#32067: Doc issue

[Nils Gillmann]

Hi Oleg,

Oleg.bocharov transcribed 2.7K bytes:
> Hi,
> 
> Link in documentation is not valid, not pointing to actual image

This is correct, as it is meant to be an example, system should
be substituted by hand.
But the fact that you report it as a problem shows that maybe we
should insert links to correct download locations.

> Does not work:
> "ftp://alpha.gnu.org/guix/guixsd-vm-image-0.14.0.system.tar.xz;
> 
> Works:
> ftp://alpha.gnu.org/gnu/guix/guixsd-vm-image-0.14.0.x86_64-linux.xz
> 
> Prefix:
> [ftp://alpha.gnu.org/gnu/guix/](ftp://alpha.gnu.org/gnu/guix/guixsd-vm-image-0.14.0.x86_64-linux.xz)
> 
> Link to documentation page
> https://www.gnu.org/software/guix/manual/html_node/Running-GuixSD-in-a-VM.html
> 
> Regards,
> Oleg
> 
> Sent with [ProtonMail](https://protonmail.com) Secure Email.

bug#32058: mysql build fails on d88b29d6b78482cdb05ac714984f6a27195e3d37

[Nils Gillmann]

Ricardo Wurmus transcribed 1.7K bytes:
> 
> Nils Gillmann  writes:
> 
> > Tobias Geerinckx-Rice transcribed 5.0K bytes:
> >> ng0,
> >>
> >> Thanks!
> >>
> >> Nils Gillmann wrote:
> >> > Since I do not have the time to work on this, but there seems to be no
> >> > open bug:
> >> >
> >> > mysql started a couple of commits ago (since last core-updates merge?)
> >> > to fail
> >> > its build.
> >>
> >> I noticed this yesterday, too. In the meantime, I've tried updating MySQL 
> >> to
> >> 5.7.22 (one never knows) and poking at some random bits but that didn't
> >> help.
> >>
> >> > [build output snipped]
> >>
> >> There's actually an error message[0]. Did it not show up in your logs? I'd
> >> consider that a bug too.
> >
> > Odd. I think this was by accident. Here it is:
> 
> This happens when building in parallel; the actual error that caused the
> build to terminate could have occurred hundreds of lines earlier when
> another independent make processes is still running.
> 
> Anyway, thanks for providing the error message.
> 
> > /tmp/guix-build-mysql-5.7.21.drv-0/mysql-5.7.21/sql/item_geofunc_internal.cc:
> >  In function ‘void
> > handle_gis_exception(const char*)’:
> > /tmp/guix-build-mysql-5.7.21.drv-0/mysql-5.7.21/sql/item_geofunc_internal.cc:37:81:
> >  error: expected
> > unqualified-id before ‘&’ token
> >catch (const 
> > boost::geometry::detail::self_get_turn_points::self_ip_exception &)
> 
> The Internet tells me that mysql is very picky about which versions of
> boost it build with.  We use boost 1.66.0 now.
> 
> The mysql package definition contains this comment:
> 
>;; Mysql wants boost-1.59.0 specifically
> 
> and then we proceed to just replace 59 for whatever minor version it is
> we are using.
> 
> Should we just upgrade to the latest version 8.0.11?

It's worth a try. Given that we just have 4 dependent packages for mysql
it could simply be applied.
Since mariadb usually just works in place of
mysql (https://mariadb.com/kb/en/library/mariadb-vs-mysql-compatibility/),
could we attempt to replace and support mysql in kodi with mariadb?

They seem to support mariadb (https://kodi.wiki/view/MySQL):

  MySQL Protocol & MariaDB
  When setting up shared Library databases either MySQL or Maria DB can be used 
as they both use the same MySQL protocol. Since many Linux distributions have 
dropped including MySQL and now instead now ship MariaDB it is being more 
common to use MariaDB for shared Library databases.

> --
> Ricardo
> 

bug#32058: mysql build fails on d88b29d6b78482cdb05ac714984f6a27195e3d37

[Nils Gillmann]

Tobias Geerinckx-Rice transcribed 5.0K bytes:
> ng0,
> 
> Thanks!
> 
> Nils Gillmann wrote:
> > Since I do not have the time to work on this, but there seems to be no
> > open bug:
> > 
> > mysql started a couple of commits ago (since last core-updates merge?)
> > to fail
> > its build.
> 
> I noticed this yesterday, too. In the meantime, I've tried updating MySQL to
> 5.7.22 (one never knows) and poking at some random bits but that didn't
> help.
> 
> > [build output snipped]
> 
> There's actually an error message[0]. Did it not show up in your logs? I'd
> consider that a bug too.

Odd. I think this was by accident. Here it is:

[ 72%] Building CXX object 
rapid/plugin/x/CMakeFiles/mysqlx.dir/src/expr_generator.cc.o


cd /tmp/guix-build-mysql-5.7.21.drv-0/build/rapid/plugin/x && 
/gnu/store/zrhwhlqqk51qslbddk4cip2z2p3fpvxd-gcc-5.5.0/bin/c++  
-DBOOST_ALL_NO_LIB -DBOOST_NO_AUTO_PTR 
-DHAVE_CONFIG_H -DHAVE_LIBEVENT1 -DHAVE_OPENSSL -DMYSQL_DYNAMIC_PLUGIN -DXP
LUGIN_LOG_PROTOBUF -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -Dmysqlx_EXPORTS 
-I/tmp/guix-build-mysql-5.7.21.drv-0/build/include 
-I/tmp/guix-build-mysql-5.7.21.drv-0/mysql-5.7.21/extra/rapidjson/include 
-I/tmp/guix-build-mysql-5.7.21.drv-0/buil
d/libbinlogevents/include 
-I/tmp/guix-build-mysql-5.7.21.drv-0/mysql-5.7.21/libbinlogevents/export 
-isystem 
/tmp/guix-build-mysql-5.7.21.drv-0/mysql-5.7.21/extra/protobuf/protobuf-2.6.1/src
 
-I/tmp/guix-build-mysql-5.7.21.drv-0/build/rapid/
plugin/x 
-I/tmp/guix-build-mysql-5.7.21.drv-0/mysql-5.7.21/rapid/plugin/x/protocol/errors
 
-I/tmp/guix-build-mysql-5.7.21.drv-0/mysql-5.7.21/rapid/plugin/x/src 
-I/tmp/guix-build-mysql-5.7.21.drv-0/mysql-5.7.21/rapid/plugin/x -I/tmp/guix-bui
ld-mysql-5.7.21.drv-0/mysql-5.7.21/rapid/plugin/x/ngs/include 
-I/tmp/guix-build-mysql-5.7.21.drv-0/mysql-5.7.21/include 
-I/tmp/guix-build-mysql-5.7.21.drv-0/mysql-5.7.21/rapid/plugin/x/include/mysql 
-I/tmp/guix-build-mysql-5.7.21.drv-0/bui
ld/rapid/plugin/x/generated 
-I/gnu/store/4n6v2zp5mslq2784j878dmfzzj4vvmza-openssl-1.0.2o/include 
-I/gnu/store/fxiwj2wpp11sif613axdax7gmwzsg6kp-zlib-1.2.11/include -isystem 
/gnu/store/l6hqfwr1hcbn9rg56bwn2d41g2ai36h2-boost-1.66.0/include -i
system /tmp/guix-build-mysql-5.7.21.drv-0/mysql-5.7.21/libevent 
-I/tmp/guix-build-mysql-5.7.21.drv-0/mysql-5.7.21/sql 
-I/tmp/guix-build-mysql-5.7.21.drv-0/mysql-5.7.21/libbinlogevents/include 
-I/tmp/guix-build-mysql-5.7.21.drv-0/mysql-5.7.
21/sql/auth -I/tmp/guix-build-mysql-5.7.21.drv-0/mysql-5.7.21/regex 
-I/tmp/guix-build-mysql-5.7.21.drv-0/mysql-5.7.21/rapid/plugin/x/mysqlxtest_src/common
  -fPIC -Wall -Wextra 
-Wformat-security -Wvla -Woverloaded-virtual -Wno-unused-parame
ter -O3 -g -fabi-version=2 -fno-omit-frame-pointer -fno-strict-aliasing 
-DDBUG_OFF -fPIC   
-I/tmp/guix-build-mysql-5.7.21.drv-0/build/rapid/plugin/x/generated/protobuf_lite
 -o 
CMakeFiles/mysqlx.dir/src/expr_generator.cc.o -c /tmp/guix-buil
d-mysql-5.7.21.drv-0/mysql-5.7.21/rapid/plugin/x/src/expr_generator.cc  

   
/tmp/guix-build-mysql-5.7.21.drv-0/mysql-5.7.21/sql/item_geofunc_internal.cc: 
In function ‘void 
handle_gis_exception(const char*)’: 
   
/tmp/guix-build-mysql-5.7.21.drv-0/mysql-5.7.21/sql/item_geofunc_internal.cc:37:81:
 error: expected 
unqualified-id before ‘&’ token 
   
   catch (const 
boost::geometry::detail::self_get_turn_points::self_ip_exception &) 

   

 ^  
   
/tmp/guix-build-mysql-5.7.21.drv-0/mysql-5.7.21/sql/item_geofunc_internal.cc:37:81:
 error: expected ‘)’ before 
‘&’ token   

/tmp/guix-build-mysql-5.7.21.drv-0/mysql-5.7.21/sql/item_geofunc_internal.cc:37:81:
 error: expected ‘{’ before 
‘&’ token   

/tmp/guix-build-mysql-5.7.21.drv

bug#32058: mysql build fails on d88b29d6b78482cdb05ac714984f6a27195e3d37

[Nils Gillmann]

Since I do not have the time to work on this, but there seems to be no open bug:

mysql started a couple of commits ago (since last core-updates merge?) to fail
its build.

[ 62%] Linking CXX shared module group_replication.so
cd /tmp/guix-build-mysql-5.7.21.drv-0/build/rapid/plugin/group_replication && 
/gnu/store/g85ikfjxs2d7aydvg5w06jn2h9xrjmpc-cmake-3.11.0/bin/cmake -E 
cmake_link_script CMakeFiles/group_replication.dir/link.txt --verbose=1
/gnu/store/zrhwhlqqk51qslbddk4cip2z2p3fpvxd-gcc-5.5.0/bin/c++ -fPIC  -fPIC 
-Wall -Wextra -Wformat-security -Wvla -Woverloaded-virtual 
-Wno-unused-parameter -O3 -g -fabi-version=2 -fno-omit-frame-pointer 
-fno-strict-aliasing -DDBUG_OFF -fPIC   -shared  -o group_replication.so 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/xcom/pax_msg.c.o 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/xcom/xcom_base.c.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/xcom/xcom_memory.c.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/xcom/xcom_vp_str.c.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/xcom/xcom_cfg.c.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/xcom/xcom_cache.c.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/xcom/xcom_transport.c.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/xcom/node_address.c.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/xcom/xcom_msg_queue.c.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/xcom/xcom_statistics.c.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/xcom/app_data.c.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/xcom/site_def.c.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/xcom/xcom_ssl_transport.c.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/xcom/xcom_recover.c.o
 CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/xcom/task.c.o 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/xcom/bitset.c.o 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/xcom/simset.c.o 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/xcom/node_set.c.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/xcom/xcom_interface.c.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/xcom/node_list.c.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/xcom/task_debug.c.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/xcom/sock_probe.c.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/xcom/task_net.c.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/xcom/synode_no.c.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/xcom/xcom_detector.c.o
 CMakeFiles/group_replication.dir/xdr_gen/xcom_vp_xdr.c.o 
CMakeFiles/group_replication.dir/libmysqlgcs/src/interface/gcs_logging.cc.o 
CMakeFiles/group_replication.dir/libmysqlgcs/src/interface/xplatform/my_xp_cond.cc.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/interface/xplatform/my_xp_thread.cc.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/interface/xplatform/my_xp_mutex.cc.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/interface/xplatform/my_xp_util.cc.o
 CMakeFiles/group_replication.dir/libmysqlgcs/src/interface/gcs_view.cc.o 
CMakeFiles/group_replication.dir/libmysqlgcs/src/interface/gcs_types.cc.o 
CMakeFiles/group_replication.dir/libmysqlgcs/src/interface/gcs_message.cc.o 
CMakeFiles/group_replication.dir/libmysqlgcs/src/interface/gcs_member_identifier.cc.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/interface/gcs_group_identifier.cc.o
 CMakeFiles/group_replication.dir/libmysqlgcs/src/gcs_interface_factory.cc.o 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/gcs_xcom_communication_interface.cc.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/gcs_xcom_control_interface.cc.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/gcs_xcom_group_management.cc.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/gcs_internal_message.cc.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/gcs_xcom_networking.cc.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/gcs_xcom_utils.cc.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/gcs_xcom_state_exchange.cc.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/gcs_xcom_group_member_information.cc.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/gcs_message_stages.cc.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/gcs_xcom_view_identifier.cc.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/gcs_xcom_interface.cc.o
 
CMakeFiles/group_replication.dir/libmysqlgcs/src/bindings/xcom/gcs_xcom_notification.cc.o
 

bug#32057: gnucash on d88b29d6b78482cdb05ac714984f6a27195e3d37 fails its testsuite

[Nils Gillmann]

gnucash with guix version d88b29d6b78482cdb05ac714984f6a27195e3d37
fails its testsuite. On the record since this version, off the record
for at least a couple of weeks.

last (relevant) part of the log appended.
 85/102 Test  #85: test-tokenizer ...***Failed
0.06 sec
Running main() from gtest_main.cc
[==] Running 7 tests from 1 test case.
[--] Global test environment set-up.
[--] 7 tests from GncTokenizerTest
[ RUN  ] GncTokenizerTest.load_file_nonexisting
/tmp/guix-build-gnucash-3.0.drv-0/gnucash-3.0/gnucash/import-export/csv-imp/test/test-tokenizer.cpp:93:
 Failure
Expected: fw_tok->load_file (file1) throws an exception of type 
std::ios_base::failure.
  Actual: it throws a different type.
/tmp/guix-build-gnucash-3.0.drv-0/gnucash-3.0/gnucash/import-export/csv-imp/test/test-tokenizer.cpp:94:
 Failure
Expected: csv_tok->load_file (file1) throws an exception of type 
std::ios_base::failure.
  Actual: it throws a different type.
[  FAILED  ] GncTokenizerTest.load_file_nonexisting (0 ms)
[ RUN  ] GncTokenizerTest.load_file_existing
[   OK ] GncTokenizerTest.load_file_existing (5 ms)
[ RUN  ] GncTokenizerTest.tokenize_from_csv_file
[   OK ] GncTokenizerTest.tokenize_from_csv_file (0 ms)
[ RUN  ] GncTokenizerTest.tokenize_binary_data
[   OK ] GncTokenizerTest.tokenize_binary_data (1 ms)
[ RUN  ] GncTokenizerTest.tokenize_comma_sep
[   OK ] GncTokenizerTest.tokenize_comma_sep (0 ms)
[ RUN  ] GncTokenizerTest.tokenize_semicolon_sep
[   OK ] GncTokenizerTest.tokenize_semicolon_sep (0 ms)
[ RUN  ] GncTokenizerTest.tokenize_fw
[   OK ] GncTokenizerTest.tokenize_fw (0 ms)
[--] 7 tests from GncTokenizerTest (6 ms total)

[--] Global test environment tear-down
[==] 7 tests from 1 test case ran. (6 ms total)
[  PASSED  ] 6 tests.
[  FAILED  ] 1 test, listed below:
[  FAILED  ] GncTokenizerTest.load_file_nonexisting

 1 FAILED TEST

Start  86: test-tx_import
 86/102 Test  #86: test-tx_import ...   Passed
0.03 sec
Start  87: test-link-qif-imp
 87/102 Test  #87: test-link-qif-imp    Passed
0.00 sec
Start  88: test-link-module-ledger-core
 88/102 Test  #88: test-link-module-ledger-core .   Passed
0.00 sec
Start  89: test-link-module-register-core
 89/102 Test  #89: test-link-module-register-core ...   Passed
0.00 sec
Start  90: test-link-module-register-gnome
 90/102 Test  #90: test-link-module-register-gnome ..   Passed
0.00 sec
Start  91: test-link-module-report-locale-specific-us
 91/102 Test  #91: test-link-module-report-locale-specific-us ...   Passed
0.00 sec
Start  92: test-link-module-report-gnome
 92/102 Test  #92: test-link-module-report-gnome    Passed
4.88 sec
Start  93: test-load-report-gnome-module
 93/102 Test  #93: test-load-report-gnome-module    Passed
4.72 sec
Start  94: test-link-module-report-system
 94/102 Test  #94: test-link-module-report-system ...   Passed
0.83 sec
Start  95: test-load-report-system-module
 95/102 Test  #95: test-load-report-system-module ...   Passed
0.81 sec
Start  96: test-transaction
 96/102 Test  #96: test-transaction .   Passed
5.12 sec
Start  97: test-cash-flow
 97/102 Test  #97: test-cash-flow ...   Passed
0.86 sec
Start  98: test-cashflow-barchart
 98/102 Test  #98: test-cashflow-barchart ...   Passed
1.78 sec
Start  99: test-standard-category-report
 99/102 Test  #99: test-standard-category-report    Passed
2.20 sec
Start 100: test-standard-net-barchart
100/102 Test #100: test-standard-net-barchart ...   Passed
1.73 sec
Start 101: test-standard-net-linechart
101/102 Test #101: test-standard-net-linechart ..   Passed
1.47 sec
Start 102: test-load-report-stylesheets-module
102/102 Test #102: test-load-report-stylesheets-module ..   Passed
1.48 sec

96% tests passed, 4 tests failed out of 102

Total Test time (real) =  77.33 sec

The following tests FAILED:
 22 - test-real-data (Failed)
 34 - test-qof (Child aborted)
 58 - test-gnc-timezone (Failed)
 85 - test-tokenizer (Failed)
Errors while running CTest
make[3]: *** [CMakeFiles/check.dir/build.make:60: CMakeFiles/check] Error 8
make[3]: Leaving directory '/tmp/guix-build-gnucash-3.0.drv-0/build'
make[2]: *** [CMakeFiles/Makefile2:242: CMakeFiles/check.dir/all] Error 2
make[2]: Leaving directory '/tmp/guix-build-gnucash-3.0.drv-0/build'
make[1]: *** [CMakeFiles/Makefile2:249: CMakeFiles/check.dir/rule] Error 2
make[1]: Leaving directory '/tmp/guix-build-gnucash-3.0.drv-0/build'

bug#26353: GuixSD /tmp cleaner fails to clean when Umlauts like "ä" are used in filenames

[Nils Gillmann]

Danny Milosavljevic transcribed 249 bytes:
> > The problem of how to deal with file name encoding has been discussed on
> > the Guile side so hopefully the next release in the 2.2 series will have
> > a solution for this.
> 
> Hmm, any news on this?  I've again got some immortal files in /tmp ...

Did it ever work for you? I can't recall a single time in my years with
GuixSD when /tmp was cleaned. It was only when I started reading more
system specific code that I found out that the lack of /tmp cleaning
on shutdown is not a default.

bug#31786: 'pre-inst-env guix --version' is not updated by new commits"

[Nils Gillmann]

George Clemmer transcribed 3.9K bytes:
> 
> Ludovic Courtès  writes:
> 
> > Hi George,
> >
> > George Clemmer  skribis:
> >
> >> Leo Famulari  writes:
> >>
> >>> On Wed, Jun 13, 2018 at 08:54:49AM +0200, Ludovic Courtès wrote:
>  The other aspect, from a maintenance and readability viewpoint, is that
>  we could quickly add up lots of explanations that we’ll have to keep
>  up-to-date and that may make more important information harder to find.
> >>>
> >>> Yeah, I'm worried about this too. It's tough to strike the correct
> >>> balance.
> >>
> >> IMO Guix is great for hackers, maintainers and sysops. The doc is
> >> appropriate for such users, well done, spare, and already voluminous.
> >>
> >> This footnote suggestion, and others rejected in the past, are motivated
> >> by my assumption that you will want to make Guix attractive to less
> >> sophisticated users.
> >>
> >> Maybe my assumption is wrong? Maybe you want only "elite" users?
> >
> > No, definitely not; I’m sorry if this is the impression this gave.
> >
> > Like I wrote, my main concern is about keeping the documentation focused
> > and maintainable.  Sometimes we have to document things that are
> > technically outside of Guix because there’s no real canonical
> > documentation and because users would be impaired without it—I’m
> > thinking for instance of bits in the “Preparing for Installation”
> > section.
> >
> > In this case, we’d be documenting something that’s both outside of Guix
> > and not vital for routine usage, and that’s mostly covered by the
> > Autoconf manual.  Hence my reluctance.
> >
> > I hope that makes sense.
> 
> Hi Ludo’,
> 
> I see the situation this way:
> 
> The current doc reflects the needs and sensibilities of the hackers,
> maintainers, and sysops that have built Guix. These "elite" users have
> different needs and judge what is important quite differently from end
> users. This guarantees that the current doc is inadequate for end users.
> So, if, as you say, you want to make Guix accessible to end users, you
> need to make changes in the doc.  The questions: How? What?

I understand where you are coming from, and I understand the trouble Ludovic
(probably) has to find the right balance of content.
Before I comment more below: I'm trying to adjust to a wide range of
people with the least possible knowledge too in the new GNUnet documentation.
Some documentations I looked at had this introductionary style for elements
when they were first used. Texinfo has this element which seems to be less
used because it renders terrible (or did not try with custom output definitions
so far). It's sort of a box element. It would be good to extend this, at least
that's my current idea, to eventually contribute to Texinfo when I have a better
view on what we want.
Long text short nonsense: you end up with lots of work and long books if you
do it right. It should be done this way. Maybe if not directly applied we
could collect the proposals somewhere in the repository? I've recently
started to strip out a whole chapter with repetive installation instructions
in GNUnet. A while back I would've argued for keeping it, that we really
need to cover and guide every case.
Some projects have written "An introduction to..." books to lead up to
the manual.
In my opinion access to knowledge should be easy and without much 'rough
edges' to get it.
Do we keep it selfcontained? Reference other books? A middle path? It's
difficult to get it right if you don't have the time to think about this
as a fulltime job.

> May I suggest ...
> 
> a) Adopt a less defensive posture when responding to user questions,
>comments, and bug reports.
> 
> b) Be pro-active about capturing support resolutions in the doc.
> 
> This thread presents a nice example of what I am talking about. To
> recap:
> 
> I said: I use 'pre-inst-env guix' this way and this is a bug.
> 
> You said: Developers expect this, so it's not a bug.
> 
> A less defensive response: Hmm, You are using 'pre-inst-env guix' in a
> way we didn't anticipate. What are the benefits of using it this way? I
> see how this is a bug for your use case.
> 
> We discussed a workaround. I suggested adding it to the doc.
> 
> You said: I’m not comfortable documenting this because it’s nothing
> specific to Guix.
> 
> I said: I urge you to reconsider.
> 
> You said: This part of the manual targets developers... they know where
> to look things up. [The more we write the more we have to maintain.]

Do we really have to assume that everyone has the same skilset who wants
to get involved? Not about this topic, but in general? I think the assumption
that we share the same knowledge is difficult. Part of the excercise is to
reach out, actively, in person. Another part is to try and do it in text (be
it on a website or a (new) chapter in a manual).

> And Clément Lassieur  added:
> 
> > But non-hacker users can use Guix pull!  Running Guix before it is
> > installed (with pre-inst-env) is described 

bug#31356: Some videos don't work with recent Icecat

[Nils Gillmann]

Clément Lassieur transcribed 409 bytes:
> Hi,
> 
> Recent Icecat can't play some videos, like this one:
> 
> https://www.radioradicale.it/scheda/540252/operazione-black-job-illustrazione-dei-dettagli-del-blitz-contro-la-corruzione
> (thank you catonano for the link and for reporting it on IRC).
> 
> Whereas an older one (say,
> /gnu/store/s85ykg7ggz8vlc0rf7ccjyz1af9n1q73-icecat-52.3.0-gnu1/bin/icecat)
> can play them.
> 
> It should be bisectable.
> 
> Cheers,
> Clément
> 

Hi, thanks for reporting it.

This is not a bug, however it has been reported multiple times in the past.
This is a not so obvious reminder that you need to install the some of the
codecs into your global or user profile.

bug#31337: Unable to use gnuk usb smartcard token on GuixSD

[Nils Gillmann]

Vagrant Cascadian transcribed 3.3K bytes:
> I've been unable to use my gnuk usb smartcard token with gnupg on
> GuixSD, and it appears this is because scdaemon is built without libusb
> support:
> 
>   $ gpg --card-status
>   gpg: selecting openpgp failed: No such device
>   gpg: OpenPGP card not available: No such device
> 
> Attached is a patch that gets scdaemon working for me and a gnuk...
> 
> Unfortunately, enabling libusb causes one of the tets to hang
> indefinitely:
> 
>   PASS: tests/openpgp/decrypt-session-key.scm
>   Checking unwrapping the encryption.
>   > encsig-2-keys-3 encsig-2-keys-4 <
>   PASS: tests/openpgp/decrypt-unwrap-verify.scm
>   Checking signing with the default hash algorithm
>   >

There should be a test-suite.log in some location in the build chroot,
have you checked that? You might need to build with -K.

> So far, I've only been able to get it to work by disabling the
> tests... so it's obviously not a good idea to enable without further
> troubleshooting.
> 
> Another option might be to use pcsc-lite and ccid, but I had even less
> luck getting that to work.
> 
> 
> live well,
>   vagrant
> 
> 
> diff --git a/gnu/packages/gnupg.scm b/gnu/packages/gnupg.scm
> index f397482ab..0e9e72784 100644
> --- a/gnu/packages/gnupg.scm
> +++ b/gnu/packages/gnupg.scm
> @@ -39,6 +39,7 @@
>#:use-module (gnu packages curl)
>#:use-module (gnu packages crypto)
>#:use-module (gnu packages emacs)
> +  #:use-module (gnu packages libusb)
>#:use-module (gnu packages openldap)
>#:use-module (gnu packages perl)
>#:use-module (gnu packages perl-check)
> @@ -232,6 +233,7 @@ compatible to GNU Pth.")
> ("libgcrypt" ,libgcrypt)
> ("libgpg-error" ,libgpg-error)
> ("libksba" ,libksba)
> +   ("libusb" ,libusb)
> ("npth" ,npth)
> ("openldap" ,openldap)
> ("pcsc-lite" ,pcsc-lite)
> @@ -246,12 +248,17 @@ compatible to GNU Pth.")
>"--enable-all-tests")
>#:phases
>(modify-phases %standard-phases
> + ;; (delete 'check)
>  (add-before 'configure 'patch-paths
>(lambda* (#:key inputs #:allow-other-keys)
>  (substitute* "scd/scdaemon.c"
>(("\"(libpcsclite\\.so[^\"]*)\"" _ name)
> (string-append "\"" (assoc-ref inputs "pcsc-lite")
>"/lib/" name "\"")))
> +(substitute* "configure"
> +  (("/usr/include/libusb-1.0")
> +   (string-append (assoc-ref inputs "libusb")
> +  "/include/libusb-1.0")))
>  #t))
>  (add-after 'build 'patch-scheme-tests
>(lambda _

bug#22629: Towards a new 'guix pull'

[Nils Gillmann]

Ludovic Courtès transcribed 2.0K bytes:
> Hello Guix!
> 
> l...@gnu.org (Ludovic Courtès) skribis:
> 
> > Here’s a series of improvements that I think we should make in ‘guix
> > pull’:
> >
> >   • Use Git instead of downloading a whole snapshot every time.  The Git
> > checkout would be kept in ~/.cache/guix/pull/checkouts, say.
> 
> That was done a while back.   :-)
> 
> >   • Build & install not only Scheme code, but also locales and the Info
> > manual.
> 
> … and also the C++ bits.
> 
> With the work done in , we can build all of
> Guix and its dependencies when doing ‘guix pull’, which brings us closer
> to what the ‘guix’ package provides.
> 
> Thus we can at least partly address the issue described in
> , i.e., have
> ‘guix pull’ install not just a bunch of .go files but also guile-git,
> guile-ssh, gnutls, and Guile itself.
> 
> To do that, we need a “paradigm shift” (sounds cute, no? :-)).
> Currently, ‘scripts/guix’ fiddles with its %load-path and adds
> ~/.config/guix/latest if it exists.  The new ‘guix pull’ should provide
> not just .go files but also a ‘guix’ command referring to the latest
> Guile, Guile-Git, etc.
> 
> To achieve this, I think the new approach would be to have:
> 
>   export PATH=$HOME/.config/guix/current/bin:$PATH
>   export INFOPATH=$HOME/.config/guix/current/share/info:$INFOPATH
>   …
> 
> ‘guix pull’ would update ~/.config/guix/current, which would contain the
> ‘guix’ command, all the .go files, locales, the Info manual, and ideally
> ‘guix-daemon’ as well.
> 
> ~/.config/guix/current could be a profile, or something that resembles a
> profile.
> 
> For a while ‘guix pull’ will have to keep updating ~/.config/guix/latest
> as well, for users running an old ‘guix’ command.
> 
> Thoughts?

First thought: Woo! Good progress!
On your propossed steps, sounds good to me.

> Ludo’.
> 
> 
> 

bug#27284: ‘guix pull’ builds using multiple derivations

[Nils Gillmann]

Awesome news!

Ludovic Courtès transcribed 3.1K bytes:
> Hello Guix!
> 
> News from the front!  I’ve pushed a new ‘wip-pull-multiple-derivations’
> branch that keeps the same approach as previously proposed (building
> Guix using multiple derivation, one for each group of modules: core,
> CLI, packages, etc.), but does not attempt to reload modules in the
> running Guile process, which proved to be too tricky.
> 
> You can already test with:
> 
>   guix pull --branch=wip-pull-multiple-derivations
>
> Feedback welcome!

I think you forgot to push it or you are on a very slow connection :)
 
> This patch set actually addresses a bootstrapping issue: you need Guix
> to build Guix.  So far ‘guix pull’ would sidestep the bootstrapping
> issue by building Guix with whatever is available in the currently
> deployed Guix; for instance, it would use the ‘guile’, ‘guile-json’,
> etc. packages from the current Guix.  The problem of that approach was
> that it’s stateful: the result depends on what you currently have.
> Sometimes what you have is too old, or lacks some package definition,
> and you can’t really go forward.
> 
> The code in ‘wip-pull-multiple-derivations’ works like this:
> 
>   1. Assume we have Guile and Guix already installed, but not
>  necessarily the latest versions thereof.
> 
>   2. Using the (guix …) modules that we have, build a program—a
>  “trampoline”—that will use the modules of the target Guix (the
>  commit we want to pull) to compute the derivation of that Guix.
> 
>   3. Run that trampoline, which returns /gnu/store/…-guix.drv.  The
>  result should be the same regardless of the initial Guix because
>  the trampoline uses exclusively modules from the target Guix.
> 
>   4. ‘guix pull’ builds that derivation (actually the branch does not
>  modify (guix scripts pull) at all; everything is in
>  build-aux/build-self.scm.)
> 
> In step #4, we should be able to get substitutes for at least some of
> the derivations.
> 
> To build the trampoline in step #2, we first need to build a bunch of
> modules from the target Guix.  Hopefully you don’t have to rebuild them
> at each pull, but it can take a minute or so, and you may not have
> substitutes for that (because this part is stateful.)
> 
> In step #3, the trampoline has compiled code for the core modules, but
> it still has to interpret (gnu packages guile) and related modules,
> because these are not compiled.  The program runs in ~40s on my laptop.
> To make it faster, we could reduce the closure of (gnu packages guile)¹,
> but that can be tricky.  Or we could optimize Guile itself; I’m sure the
> compiler and/or interpreter could do better.
> 
> In that branch, you can also run:
> 
>   make as-derivation
> 
> and it will build Guix from $srcdir in the way described above.
> 
> To summarize, performance is not great, but hopefully it’ll be slightly
> better than what we have now, especially with substitutes.
> Correctness/reproducibility are greatly improved.
> 
> Ludo’.
> 
> ¹ The closure of (gnu packages guile) contains python, haskell-check,
>   music, and many other surprising things:
>   .
> 
> 
> 

bug#23106: rxvt-unicode is missing .desktop file(s)

[Nils Gillmann]

urxvt / rxvt-unicode has no .desktop files in Guix and therefore
does not show up in application menus like GNOME provides.


Whoever wants to fix it faster than I do (currently occupied with
psyced related packages), here is my work in progress part of the
rxvt-unicode package.

.desktop files can be found in the source dir of gentoo and
archlinux
(https://projects.archlinux.org/svntogit/community.git/tree/trunk?h=packages/rxvt-unicode)

Code below has not been tested, it may need some fixes, and we
need at least 3 like in archlinux.

(arguments
 ;; This sets the destination when installing the necessary terminal
 ;; capability data, which are not provided by 'ncurses'.  See
 ;; https://lists.gnu.org/archive/html/bug-ncurses/2009-10/msg00031.html
 '(#:make-flags
   (list (string-append "TERMINFO="
(assoc-ref %outputs "out")
"/share/terminfo"))
   #:phases
   (modify-phases %standard-phases
 (add-after
 'install 'install-desktop
   (lambda _
 (let ((desktop (string-append %output "/share/applications")))
   (mkdir-p desktop)
   (call-with-output-file
   (string-append desktop "/urxvt.desktop")
 (lambda (port)
   (format port "~
 [Desktop Entry]~@
 Name=~a~@
 Comment=~a~@
 TryExec=~a/bin/urxvt~@
 Exec=~a/bin/urxvt~@
 Icon=terminal~@
 Type=Application~@
 Categories=GNOME;GTK;Utility;TerminalEmulator;System;~@
 StartupNotify=true~%" ,name ,synopsis %output)

-- 
ng
personal contact: http://krosos.sdf.org
EDN: https://wiki.c3d2.de/EDN

bug#22985: using gnune-gtk with ratpoison (gnunet-fs in -gtk nonfunctional) -> needs participation and input

[Nils Gillmann]

Leo Famulari <l...@famulari.name> writes:

> On Sun, Mar 20, 2016 at 03:05:25PM +0100, Nils Gillmann wrote:
>> Previously reported GNOME bug solved after reconfiguring the
>> system with (services (gnome-desktop-service)).
>
> Okay, so the problem is solved then?

No, please read the full initial bug.

It is not a GNOME bug, it is a bug where I need input from other
people about issues with the gnunet.scm I did send in and
eventually with the 0.10.1 gnunet as well.
And also somebody to apply the gnunet.scm patchset to master, but
I give it one more day until I try to draw attention to that
patch again.

I don't have the resources to figure out every possible
windows/desktop manager issues, which is what the initial bug
report said.

-- 
ng
personal contact: http://krosos.sdf.org
EDN: https://wiki.c3d2.de/EDN

bug#22985: using gnune-gtk with ratpoison (gnunet-fs in -gtk nonfunctional) -> needs participation and input

[Nils Gillmann]

Previously reported GNOME bug solved after reconfiguring the
system with (services (gnome-desktop-service)).

-- 
ng
personal contact: http://krosos.sdf.org
EDN: https://wiki.c3d2.de/EDN

bug#22985: using gnune-gtk with ratpoison (gnunet-fs in -gtk nonfunctional) -> needs participation and input

[Nils Gillmann]

Experienced same behavior when I added gnome to my profile and
launched it today, steps to replicate:

gnunet-arm -s &
gnunet-gtk

expected error:

(gnunet-fs-gtk:32585): GLib-GIO-ERROR **: Settings schema 
'org.gtk.Settings.FileChooser' is not installed

in terminal, and gnunet-fs tab is black.

-- 
ng
personal contact: http://krosos.sdf.org
EDN: https://wiki.c3d2.de/EDN

bug#22985: using gnune-gtk with ratpoison (gnunet-fs in -gtk nonfunctional) -> needs participation and input

[Nils Gillmann]

This describes a bug with our gnunet-gtk package I am tracking
now in gnu/packages/gnunet.scm and will include it to refer to in
the patch I will send in as soon as I have enough time on this
conference to rebase my (big) patch of gnunet.scm

Description/Problem:

- Using ratpoison as WM, running gnunet-gtk (svn) gives GSettings
  related errors when opening gnunet-fs (filesharing) tab.
  The error gets more specific when installing gsettings into
  your profile (see irc log, 10.03.2016, grep for "gnunet"
  "gsettings"). I can't be more precise at the moment due to the
  lack of time. I provided some details on IRC on thursday, if I
  have the time this weekend I'll add the exact error messages
  you'll experience, though they are obvious in the terminal
  output.

- Reconfiguring the system with xfce in the desktop profile seems
  to provide more than ratpoison, the bug is gone. I have to
  assume that xfce provides gsettings on its own, and that this
  error is specific to minimal window managers without certain
  X11/gtk profiles or otherwise configuration settings which get
  delivered with xfce and the like.

The output (from memory) is visible when you kill/close
gnunet-gtk, look for something related to gnunet-fs ... GIO
 GSettings  and later: org.gtk.FileChooser (or something
like that), also in relation to gnunet-fs.

I want people to do the following:
- Install gnunet and gnunet-gtk (both 0.10.1), skip over
  gnunet-setup, and see in gnunet-gtk after running "gnunet-arm
  --start" if the tab for filesharing / publishing is just
  black. In either case of positive or negative confirmation I
  want to know about the used desktop/window manager and
  environment variables to nail down the problem.
- Do the exact same for gnunet-gtk-svn + gnunet-svn.


This bug is published before gnunet-svn, gnunet-gtk-svn and other
changes to gnu/packages/gnunet.scm are send in as patches. I am
currently not in reach of a permanent connection and will provide
rebase and create a patch as soon as I can. Time and too much
input in talks is another factor keeping me from currently
rebasing the patch against master.
Just know that the patch is functional and this bug is considered
something people using windowmanagers equal to ratposion should
help me in solving, as this is caused by an external factor I
have to pin and optimize the gnunet package on or provide a note
for certain environments. In itself, based on a work I
co-authored with Jookia, it is functional.


Sorry if this might read verbose or confusing but I write this
based on something I have written between yesterday, this morning
and in between rushing to the next talk :)

Thanks for your patience,
-- 
ng
personal contact: http://krosos.sdf.org
EDN: https://wiki.c3d2.de/Echt_Dezentrales_Netz/en

bug#22908: guix download choices (unfonts -> upstream, archive.org bugged) and my alternatives.

[Nils Gillmann]

l...@gnu.org (Ludovic Courtès) writes:

> retitle 22908 HTTP client rejects invalid 'Content-Type' headers
> thanks

I can retitle open bugs? If so, how? Or is there a "help"
function of the debuggs?

> (Please make sure the title of your messages to bug-guix clearly
> describes the problem with phrases like “Guix fails to …”, “Failure to
> download from …”, etc.)
>
> Nils Gillmann <niaster...@grrlz.net> skribis:
>
>> Long story short, I try to package un-fonts, which sits on a
>> server which is configured in a way that it gives us a mime type
>> for the package which is invalid (.gz).
>
> As Ricardo noted in
> <https://lists.gnu.org/archive/html/guix-devel/2016-02/msg01359.html>,
> the problem is that Guile’s HTTP client is (too) strict and rejects this
> invalid ‘Content-Type’ header from kldp.net:
>
>   Content-Type: .gz

I noticed, that's why I packaged and submitted (see more recent
version of the patch, new thread) the font with a location on
sdf.org. I commented inside why and what I intend to do.

> There are two courses of actions that can be taken in parallel:
>
>   1. Get the kldp.net admins to adjust the Web server.  Did you get
>  feedback from them?

Not yet. They are behind a privacywhois, I am not sure how long
reaction will get delayed due to that factor. The bug has been
reported to them, now it's just waiting and maybe getting a
response later this year.

>   2. Make Guile’s HTTP client more permissive.

I vote against that, because it is just one package so far. Let's
say we package KDE Plasma and there are more than 1 package which
is not a font, that is a reason to make changes to the http client.

> In the meantime, we could work around the issue by using a copy hosted
> on another server, if possible, such as archive.org or sdf.org as you
> note, or fossies.org (it mirrors a number of things.)
>
> Thoughts?

Archive.org replicates every wrong and right including mime
types. -> same issue, different domain.

I did not upload the font itself to archive.org but to sdf.org ,
I should also get a reply from in-berlin.org (an ISP, fast
datacenters) if they have a public download host and would like
to host this font outside of the kldp.net domain, explaining the
reasons etc.


> Thanks,
> Ludo’.

thanks,
-- 
ng
irc://loupsycedyglgamf.onion:67/~NiAsterisk
https://psyced.org:34443/NiAsterisk/
EDN: https://wiki.c3d2.de/Echt_Dezentrales_Netz/en

bug#22907: `guix package -u` fails

[Nils Gillmann]

niasterisk@khazad-dum ~$ time guix package --substitute-urls=hydra.gnu.org 
--dry-run -u *.*

real0m1.779s
user0m1.824s
sys 0m0.060s
niasterisk@khazad-dum ~$ time guix package --substitute-urls=hydra.gnunet.org 
--dry-run -u *.*

real0m1.763s
user0m1.808s
sys 0m0.056s
niasterisk@khazad-dum ~$ guix package --substitute-urls=hydra.gnunet.org 
--dry-run -u *.*
niasterisk@khazad-dum ~$ guix package --substitute-urls=hydra.gnunet.org -u *.*
niasterisk@khazad-dum ~$ 

so yes, it works but still nothing happens. Could be that there's
just no updates, but I should not have to provide *.* as it
worked before with just `guix package -u`

Although... does graffting after guix pull rebuild and update the
packages in the profile? current gen is after the update:

Generation 85   Mar 04 2016 12:30:38(current)

-- 
ng
irc://loupsycedyglgamf.onion:67/~NiAsterisk
https://psyced.org:34443/NiAsterisk/
EDN: https://wiki.c3d2.de/Echt_Dezentrales_Netz/en

bug#22908: guix download choices (unfonts -> upstream, archive.org bugged) and my alternatives.

[Nils Gillmann]

This references thread
"fonts.scm -> packaging "un-fonts", download isses"
on guix-devel and it classifies as a bug.
It's a bug upstream, replicated by archive.org and preventing me
from finishing my work.

Long story short, I try to package un-fonts, which sits on a
server which is configured in a way that it gives us a mime type
for the package which is invalid (.gz). Now somebody could make
guix download function to simply ignore that, but as I don't like
to do that with only this one known case at hand, my ideas are:

- download the file to sdf.org where it will sit until something
  happens to the entire internet and sdf.org disappears (they
  have been around since 84/87).
- upload the individual file to archive.org as the simple
  waybackmachine is not smart enough to fix the mime issue of the
  original server.

This is a bug, because it prevents me from using guix download,
and guix download from functioning in a way where it must be
altered to adopt to the incompetence of some domain/server
admin.


what do you think?
-- 
ng
irc://loupsycedyglgamf.onion:67/~NiAsterisk
https://psyced.org:34443/NiAsterisk/
EDN: https://wiki.c3d2.de/Echt_Dezentrales_Netz/en

bug#22848: xrandr installation (probably) stales with ftp downloads

[Nils Gillmann]

It's possible that I just ran into a temporary problem.
I got these errors, I changed location that day (another ISP,
another city) and the error while trying to install xrandr was
gone.
Bad closing description, but that's as detailed as it can get
this time.
-- 
ng
irc://loupsycedyglgamf.onion:67/~NiAsterisk
https://psyced.org:34443/NiAsterisk/
EDN: https://wiki.c3d2.de/Echt_Dezentrales_Netz/en

bug#22848: xrandr installation (probably) stales with ftp downloads

[Nils Gillmann]

This can be closed, or will be closed by myself in the next 2
days when I remember to check how to close it.



thanks,
-- 
ng
irc://loupsycedyglgamf.onion:67/~NiAsterisk
https://psyced.org:34443/NiAsterisk/
EDN: https://wiki.c3d2.de/Echt_Dezentrales_Netz/en

bug#22732: lispf4: broken

[Nils Gillmann]

I packaged lispf4 for Guix, tried to debug it alone for a while
now, got other peoples input, tested different GNU systems, still
can't reproduce the errors I get on Guix and other GNU systems.

This is a bit vague but the actual error output is just too long
for this email.
TL;DR is SYSATOMS even when in the same directory with any
permission I tried fails to get opened. SYSATOMS is essential for
lispf4 to work.

I contacted the author of the port (Blake McBride), it will take
some weeks until he can help, but he'll definitely help to
debug the issue.
I will update and later close this issue as soon as we are done
fixing it.

thanks,
-- 
ng

bug#22543: 404 in Manualpage

[Nils Gillmann]

Leo Famulari <l...@famulari.name> writes:

> On Wed, Feb 03, 2016 at 02:41:04PM +0100, Nils Gillmann wrote:
>> The manual page
>> https://www.gnu.org/software/guix/manual/html_node/Requirements.html#Requirements
>> 
>> contains a link to
>> 
>> https://www.gnu.org/software/guix/manual/gnutls-guile/Guile-Preparations.html#Guile-Preparations
>> 
>> which give a 404. I am not familiar with what's supposed to be there, a
>> quick search for "gnutls-guile/Guile-Preparations.html" in duckduckgo gives 
>> me
>> http://www.gnutls.org/manual/gnutls-guile/Guile-Preparations.html as one
>> of 2 results.
>> 
>> Should I fix the link to this one and send in a patch?
>
> Yes, please!

So you think I should (and can?) fix it, while alex replies:

>> I don't think you can send a patch for this.  According to
>> <https://www.gnu.org/software/guix/manual/>:
>>
>>  (This page generated by the gendocs.sh¹ script.)

>> This "gendocs.sh" uses "texi2html" to convert our texinfo documentation
>> (see "doc/guix.texi" in the guix git repo) to the html page.  In
>> "guix.texi" the link you are talking about is a usual link to the
>> "gnutls-guile" manual.  I didn't look at "texi2html" but I believe by
>> default it just assumes that all the manuals are placed at
>> "www.gnu.org/software//manual/", so for "external" manuals the
>> generated links are false.  For example, there are also wrong links to
>> Geiser and Magit-Popup manuals.
>>
>> So I think it's a general thing for all generated manuals that are
>> placed on "gnu.org".
>>
>> ¹ http://git.savannah.gnu.org/cgit/gnulib.git/plain/build-aux/gendocs.sh
>>
>> -- 
>> Alex

Okay, so I guess it's related to #22651 and it#s not fixable the
way I want to (edit the source), or at least what I would want to
do is not optimal and it should be fixed in some other way.

Didn't look into it yet, but should we follow #22651 for the 404s?
-- 
ng

bug#22546: Download-Page is "hiding" what the options actually are

[Nils Gillmann]

l...@gnu.org (Ludovic Courtès) writes:

> Robin Vobruba  skribis:
>
>> Being new to Guix, i went to the Download page:
>> https://www.gnu.org/software/guix/download/
>>
>> immediately saw the 3 big options
>> read their title/names
>> was confused what the difference might be between "GuixSD" and "Guix Binary"
>> could not find anything inside these 3 option's boxes that would help me
>> read the text below them
>> read the text above them
>> finally understood that the first option is the OS, and the second is only
>> the packag-manager
>
> I think I’ll have to disagree.  :-)
>
> For each option there’s a line right below the title saying what this
> is.  I’m no expert in “information architecture” but I’m under the
> impression that there’s little margin for improvement.
>

SD has a different Symbol than Guix, which works okay for me with
no colorblindness and no other visual problems.
But maybe it could help to highlight the 'System Distribution'
and to visually (with colors in accordance to w3 disability
standards) set apart GUIX from GUIXSD boxes?
Or, like fr example TAILS who now have some kind of questionaire
tour to the right download.

There are some things I am collection thoughts on, where the
actual output of them is slowed down by working on too many texts
at the same time.

> More importantly, I think that someone who cannot be bothered to read
> this will not install the thing at all since installing requires you to
> read the much longer installation instructions.  Of course we want them
> to be as small as possible, but I don’t think that’ll be a single line
> anytime soon.
>
> I hope this makes sense!
>
> Thanks for your feedback,
> Ludo’.
>
>
>

-- 
ng

bug#22573: critical error during 'guix pull'

[Nils Gillmann]

Leo Famulari <l...@famulari.name> writes:

> On Sat, Feb 06, 2016 at 03:33:56PM +0100, Nils Gillmann wrote:
>> Hi, today 15:30 EU/Berlin Timezone I started guix pull and got this output:
>> 
>> Starting download of /tmp/guix-file.bHtiW7
>> From http://git.savannah.gnu.org/cgit/guix.git/snapshot/master.tar.gz...
>>  master.tar.gz  1KiB2.5MiB/s 00:00 [] 
>> 100.0%
>> unpacking '/gnu/store/ig37bb33y7vnpay722b541ljlqvmyjbm-guix-latest.tar.gz'...
>> 
>> gzip: stdin: not in gzip format
>> /gnu/store/9m8jg38cy0j95cb1gmi784ms85nn68vr-tar-1.28/bin/tar: Child returned 
>> status 1
>> /gnu/store/9m8jg38cy0j95cb1gmi784ms85nn68vr-tar-1.28/bin/tar: Error is not 
>> recoverable: exiting now
>> guix pull: error: failed to unpack source code
>
> Since the capabilities of hydra.gnu.org are sometimes outstripped by
> user demand, users sometimes experience repeatable network failures
> while downloading. We have raised the funds to buy a more powerful
> machine for hydra.gnu.org and to host it.
>

I tend to forget this, thanks for the reminder.

> Do you know if this succeeded for you during the period while the Guix
> git repository's HEAD was unchanged? Althought, I don't see how state of
> HEAD could make a difference to whether or not the gzip encoding was
> successful.
>

I'm not sure, and maybe I should raise my personal level for reporting
things hydra related. I tried 5-8 times with failures, and minutes later
it succeeded. I can't point anymore what was going on, the logs tell me
the only commit ~7 hours ago was icecat.

As this is not really a bug it could be closed if there's nothing more I
could provide?

-- 
ng/ni*
vcard: http://krosos.sdf.org

bug#22573: closed

[Nils Gillmann]

Problem solved,
problem wasn't really a problem and details couldn't be provided.

-- 
ng/ni*
vcard: http://krosos.sdf.org

bug#22573: critical error during 'guix pull'

[Nils Gillmann]

Hi, today 15:30 EU/Berlin Timezone I started guix pull and got this output:

Starting download of /tmp/guix-file.bHtiW7
>From http://git.savannah.gnu.org/cgit/guix.git/snapshot/master.tar.gz...
 master.tar.gz  1KiB2.5MiB/s 00:00 [] 100.0%
unpacking '/gnu/store/ig37bb33y7vnpay722b541ljlqvmyjbm-guix-latest.tar.gz'...

gzip: stdin: not in gzip format
/gnu/store/9m8jg38cy0j95cb1gmi784ms85nn68vr-tar-1.28/bin/tar: Child returned 
status 1
/gnu/store/9m8jg38cy0j95cb1gmi784ms85nn68vr-tar-1.28/bin/tar: Error is not 
recoverable: exiting now
guix pull: error: failed to unpack source code

-- 
ng/ni*
vcard: http://krosos.sdf.org