bug#37378: python-apache-libcloud fails its test suite

[Maxim Cournoyer]

This is happening on master.

The tests results are reported as:

== 14 failed, 9148 passed, 24 skipped, 532 warnings in 173.14 seconds ==

And here's a sample of a failure output:

--8<---cut here---start->8---
self = , url = 'https://ecs.%s.amazonaws.com/'
params = OrderedDict()

def prepare_url(self, url, params):
"""Prepares the given HTTP URL."""
#: Accept objects that have string representations.
#: We're unable to blindly call unicode/str functions
#: as this will include the bytestring indicator (b'')
#: on python 3.x.
#: https://github.com/requests/requests/pull/2238
if isinstance(url, bytes):
url = url.decode('utf8')
else:
url = unicode(url) if is_py2 else str(url)

# Remove leading whitespaces from url
url = url.lstrip()

# Don't do any URL preparation for non-HTTP schemes like `mailto`,
# `data` etc to work around exceptions from `url_parse`, which
# handles RFC 3986 only.
if ':' in url and not url.lower().startswith('http'):
self.url = url
return

# Support for unicode domain names and paths.
try:
scheme, auth, host, port, path, query, fragment = parse_url(url)
except LocationParseError as e:
>   raise InvalidURL(*e.args)
E   requests.exceptions.InvalidURL: Failed to parse: 
https://ecs.%s.amazonaws.com/

/gnu/store/6bqv37089mz5a227c008smpl6vks3cf8-python-requests-2.22.0/lib/python3.7/site-packages/requests/models.py:381:
 InvalidURL
__ ElasticContainerDriverTestCase.test_stop_container __

self = , url = 'https://ecs.%s.amazonaws.com/'
params = OrderedDict()

def prepare_url(self, url, params):
"""Prepares the given HTTP URL."""
#: Accept objects that have string representations.
#: We're unable to blindly call unicode/str functions
#: as this will include the bytestring indicator (b'')
#: on python 3.x.
#: https://github.com/requests/requests/pull/2238
--8<---cut here---end--->8---

Perhaps an upgrade of python-requests could be at cause.  Needs
investigation.

Maxim

bug#37363: emacs and other programs do not display special characters

[Bengt Richter]

On +2019-09-09 19:13:08 -0500, quil...@riseup.net wrote:
> As per nckx's question on IRC, this is the output to locale on both Emacs
> shell and BASh:
> 
> quiliro@GSD3 ~/magit/prueba0$ locale
> LANG=es_EC.UTF-8
> LC_CTYPE="es_EC.UTF-8"
> LC_NUMERIC="es_EC.UTF-8"
> LC_TIME="es_EC.UTF-8"
> LC_COLLATE="es_EC.UTF-8"
> LC_MONETARY="es_EC.UTF-8"
> LC_MESSAGES="es_EC.UTF-8"
> LC_PAPER="es_EC.UTF-8"
> LC_NAME="es_EC.UTF-8"
> LC_ADDRESS="es_EC.UTF-8"
> LC_TELEPHONE="es_EC.UTF-8"
> LC_MEASUREMENT="es_EC.UTF-8"
> LC_IDENTIFICATION="es_EC.UTF-8"
> LC_ALL=
> 
> 
Hi,
I have been having locale-related problems too,
so maybe we can bounce enough clues around that
we can advance a little.

[ later ... I'll have to come back to locale per se,
  but hope the following is useful for poking around
  with fonts and unicode character and their glyphs ]

[ To the advanced, please don't be insulted by my posting
  obvious stuff, as if you didn't know how to use grep and sed
  and especially guix better than my examples show --
  it is motivated by wanting to exchange helpful methods and info
  with others also coming to guix, who might benefit from my recent
  newbie experiences trying to find my way into guix city, in the
  Commonwealth of FOSS :)

  Hm, I wonder if we could use postgresql plus postgis to do
  an openstreetmap map of guix city stores and pubs
  -- and potholes and contruction blockages ;-)
]
  
Anyway, I have a little script which may be helpful
in generating utf8 characters for display in your
various contexts (what this (emacs) context is I'll show below):

$ uchr 229 10
å
$ which -a uchr
/home/bokr/bin/uchr
$ cat ~/bin/uchr
#!/home/bokr/.guix-profile/bin/bash
# 2019-08-19 22:25:34 ## was: #!/usr/bin/bash
# ~/bin/uchr -- print unicode characters from numeric args
# uchr 65 67 10 | od -a -t x1
# 000   A   C  nl
#  41  43  0a
# 003
cc="$( printf '\\u%x' "$@" )"
echo -en "$cc"

Those last two lines do all the work ;-)
(printf is a bash built-in -- type -"help printf"
at the bash command line.

(By -"foo" I mean "foo" minus the quotes :)

printf re-uses its format for each arg it encounters, so it
converts all the integers according to '\\u%x' above in uchr.

$ uchr {192..255} 10
ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞßàáâãäåæçèéêëìíîïðñòóôõö÷øùúûüýþÿ
$
What do you get if you try that from your login console, not gnome?

To make various fonts available to the console, you should be
able to use setfont from console bash -- see -"man setfont"
(remembering my minus-the-quotes notation :)

The {FIRST_INTEGER..LAST_INTEGER} of course generates individual
integer arguments including first and last. The 10 is a newline.

I'm pretty sure I did -"setfont sun12x22" from the console bash,
which gives you most of the 12x22 font built into the kernel.

It's got 256 character cells for its 12x22 pixel glyphs, each
represented by 22 16-bit integers using the ms12 bits with 1
as foreground, IIRC.

The sun12x22 font is pretty good, with box-drawing characters
as well most things you need in European languages (I'm familiar
with it because I wrote a little script to display the glyphs
on the frame buffer, in the pursuit of independence from huge
blobs of gooey GUI software :)

After having done -"setfont sun12x22" you can do
-"setfont -ou glyph-code-to-unicodepoint.txt" which will
give you a tab-delimited table starting ... ending like:

0x00U+
0x20U+0020
0x21U+0021
0x22U+0022
0x23U+0023
0x24U+0024
0x25U+0025
...
0xdfU+2580
0xdcU+2584
0xdbU+2588
0xddU+258c
0xdeU+2590
0xb0U+2591
0xb1U+2592
0xb2U+2593
0x01U+263a
0x5fU+f804

(BTW, this would be really easy to snarf and convert to
an assoc list mapping unicode code points to glyph indices)

That glyph 0x01 has a unicode we can discover, even though
the console font you get from -"setfont sun12x22" does not
have the glyph that is in the kernel version's glyph table:

$ 
$ unicode-info "$(uchr 0x263a)"

"☺":
glyph  codepoint .int  name...
_☺_ +U00263a 9786  WHITE SMILING FACE  
$ 

The glyph is in the kernel's 256-glyph bit-map for
sun12x22 though, and it should be visible in a gui browser
with good unicode coverage.

You can find the kernel's bitfont defined in kernel sources
.../linux-4.14.3/lib/fonts/font_sun12x22.c (or change
the kernel version -- 4.14.3 is the last one I grop^H^Hepped around in
looking for stuff to "steal" :)

Ok, back to
$ uchr {192..255} 10
ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞßàáâãäåæçèéêëìíîïðñòóôõö÷øùúûüýþÿ
$

The first four A's above are really not As, as another little script
of mine that shows unicode information will show:

(you can find the source archived in a recent post of mine
https://lists.gnu.org/archive/html/guix-devel/2019-09/msg00115.html
if curious)

$ uchr {192..202} | unicode-info

"ÀÁÂÃÄÅÆÇÈÉÊ":
glyph  codepoint .int  name...
_À_ +Uc0  192  LATIN CAPITAL LETTER A WITH GRAVE  
_Á_ +Uc1  193  LATIN CAPITAL 

bug#37377: python-matplotlib-documentation build fails on master

[Maxim Cournoyer]

As of commit 83aa6562173e06e8fafd4857a2e708feabfe56f8:

--8<---cut here---start->8---
starting phase `build'
Running Sphinx v2.1.2
WARNING: while setting up extension matplotlib.sphinxext.mathmpl: directive 
'math' is already registered, it will be overridden
/gnu/store/2lc31q0b7kk21s6c1qln5gx6i090bbq5-python-sphinx-2.1.2/lib/python3.7/site-packages/sphinx/util/docutils.py:311:
 RemovedInSphinx30Warning: function based directive support is now deprecated. 
Use class based directive instead.
  RemovedInSphinx30Warning)
/gnu/store/2lc31q0b7kk21s6c1qln5gx6i090bbq5-python-sphinx-2.1.2/lib/python3.7/site-packages/sphinx/util/docutils.py:311:
 RemovedInSphinx30Warning: function based directive support is now deprecated. 
Use class based directive instead.
  RemovedInSphinx30Warning)

Exception occurred:
  File 
"/tmp/guix-build-python-matplotlib-documentation-2.2.3.drv-0/matplotlib-2.2.3/doc/sphinxext/github.py",
 line 149, in setup
app.info('Initializing GitHub plugin')
AttributeError: 'Sphinx' object has no attribute 'info'
The full traceback has been saved in 
/tmp/guix-build-python-matplotlib-documentation-2.2.3.drv-0/sphinx-err-n9mt2cr6.log,
 if you want to report the issue to the developers.
Please also report this if it was a user error, so that a better error message 
can be provided next time.
A bug report can be filed in the tracker at 
. Thanks!
make: *** [Makefile:20: html] Error 2
Backtrace:
   4 (primitive-load "/gnu/store/ksj56pxrr1plazg6nrppi1r4hz6…")
In ice-9/eval.scm:
   191:35  3 (_ _)
In srfi/srfi-1.scm:
   863:16  2 (every1 # …)
In 
/gnu/store/4r04fsfcryy5h4v2h3g6lzlibafmmdjm-module-import/guix/build/gnu-build-system.scm:
   799:28  1 (_ _)
In 
/gnu/store/4r04fsfcryy5h4v2h3g6lzlibafmmdjm-module-import/guix/build/utils.scm:
616:6  0 (invoke _ . _)

/gnu/store/4r04fsfcryy5h4v2h3g6lzlibafmmdjm-module-import/guix/build/utils.scm:616:6:
 In procedure invoke:
Throw to key `srfi-34' with args `(#)'.
note: keeping build directory 
`/tmp/guix-build-python-matplotlib-documentation-2.2.3.drv-1'
builder for 
`/gnu/store/dwrp4g4ajqd8szxr93id0pwqimf0bafg-python-matplotlib-documentation-2.2.3.drv'
 failed with exit code 1
--8<---cut here---end--->8---

bug#37374: "Guix is too old and cannot be upgraded" (guix package -u)

[Jesse Gibbons]

On Tue, 2019-09-10 at 17:37 -0600, melon wrote:
> I was attempting to upgrade my Guix (binary, on Linux Mint)
> installation
> today using the 'guix package pull && guix package -u' commands, and
> Guix outputted the following error:
> 
> ERROR: In procedure raise:
> Wrong type (expecting exact integer): # "Guix is too old and cannot be upgraded"] 7528ac0>
> guix pull: error: You found a bug: the program
> '/gnu/store/y1kqj5ikxx9niyz2zx1gbikspi2xfmi4-compute-guix-derivation'
> failed to compute the derivation for Guix (version:
> "7e143375d3649f3c0bd4c13958b26c086f364647"; system: "x86_64-linux";
> host version: "aa4818c33b6b2fd8d602ee93a2f53005d9472f41"; pull-
> version: 0).
> Please report it by email to .
> 
> I searched the Web and mailing list archives for this error but could
> not find anything. Maybe I used the wrong keywords.
> 
> Is there any way I can perform a "manual upgrade" to a newer Guix
> version?
> 

Wow, now I want to keep guix up-to-date all the time. How long has it
been since you pulled/upgraded guix?

The first thing I thought of is manually remove the guix binary run
install script. But that might get complicated.

I think you can look at the git repo on savannah and pull a few commits
after your current commit (run "guix describe" to get the commit, then
"guix pull --commit=COMMIT" where COMMIT is about a hundred commits
after your current commit), repeating until "guix pull" brings guix
fully up-to-date.

bug#37089: texlive-union includes log files with timestamps

[Maxim Cournoyer]

Here's an actual example of the problem:

diffoscope --exclude-command stat 
/gnu/store/igc79crx5ya5vwyzkd2l95nlpbk647in-texlive-union-49435{,-check}
--- /gnu/store/igc79crx5ya5vwyzkd2l95nlpbk647in-texlive-union-49435
+++ /gnu/store/igc79crx5ya5vwyzkd2l95nlpbk647in-texlive-union-49435-check
├── share
│ ├── texmf-var
│ │ ├── web2c
│ │ │ ├── updmap.log
│ │ │ │ @@ -1,9 +1,9 @@
│ │ │ │  updmap version r44331 (2017-05-14 02:15:43 +)
│ │ │ │ -Wed Sep 11 01:17:36 2019
│ │ │ │ +Wed Sep 11 01:17:33 2019
│ │ │ │  
│ │ │ │  Using the following config files:
│ │ │ │  
│ │ │ │  updmap is creating new map files
│ │ │ │  using the following configuration:
│ │ │ │LW35 font names  : URWkb (default)
│ │ │ │prefer outlines  : true (default)
│ │ │ │ @@ -795,26 +795,26 @@
│ │ │ │  tmro108r
│ │ │ │  tmui108r
│ │ │ │  zd
│ │ │ │  zpzdr-reversed
│ │ │ │  
│ │ │ │  Files generated:
│ │ │ │
/gnu/store/igc79crx5ya5vwyzkd2l95nlpbk647in-texlive-union-49435/share/texmf-var/fonts/map/dvips/updmap:
│ │ │ │ -   15888 2019-09-11 01:17:36 builtin35.map
│ │ │ │ -   21361 2019-09-11 01:17:36 download35.map
│ │ │ │ -   21361 2019-09-11 01:17:36 psfonts_pk.map
│ │ │ │ -   21361 2019-09-11 01:17:36 psfonts_t1.map
│ │ │ │ -   21356 2019-09-11 01:17:36 ps2pk.map
│ │ │ │ -  14 2019-09-11 01:17:36 psfonts.map -> psfonts_t1.map
│ │ │ │ +   15888 2019-09-11 01:17:33 builtin35.map
│ │ │ │ +   21361 2019-09-11 01:17:33 download35.map
│ │ │ │ +   21361 2019-09-11 01:17:33 psfonts_pk.map
│ │ │ │ +   21361 2019-09-11 01:17:33 psfonts_t1.map
│ │ │ │ +   21356 2019-09-11 01:17:33 ps2pk.map
│ │ │ │ +  14 2019-09-11 01:17:33 psfonts.map -> psfonts_t1.map
│ │ │ │
/gnu/store/igc79crx5ya5vwyzkd2l95nlpbk647in-texlive-union-49435/share/texmf-var/fonts/map/pdftex/updmap:
│ │ │ │ -   21363 2019-09-11 01:17:36 pdftex_dl14.map
│ │ │ │ -   19698 2019-09-11 01:17:36 pdftex_ndl14.map
│ │ │ │ -  15 2019-09-11 01:17:36 pdftex.map -> pdftex_dl14.map
│ │ │ │ +   21363 2019-09-11 01:17:33 pdftex_dl14.map
│ │ │ │ +   19698 2019-09-11 01:17:33 pdftex_ndl14.map
│ │ │ │ +  15 2019-09-11 01:17:33 pdftex.map -> pdftex_dl14.map
│ │ │ │
/gnu/store/igc79crx5ya5vwyzkd2l95nlpbk647in-texlive-union-49435/share/texmf-var/fonts/map/dvipdfmx/updmap:
│ │ │ │ - 411 2019-09-11 01:17:36 kanjix.map
│ │ │ │ + 411 2019-09-11 01:17:33 kanjix.map
│ │ │ │  
│ │ │ │  WARNING: updmap has found mismatched files!
│ │ │ │  
│ │ │ │  The following files have been generated as listed above,
│ │ │ │  but will not be found because overriding files exist, listed below.
│ │ │ │   builtin35.map: 
│ │ │ │   download35.map:

bug#37376: python-rpy2 is not reproducible [awaiting fix from core-updates]

[Maxim Cournoyer]

See the output of diffoscope below:

diffoscope --exclude-command stat 
/gnu/store/lvmrrr9a5hr0xj26snygszlmgrdv6nma-python-rpy2-3.0.4-1.19868a8{,-check}
--- /gnu/store/lvmrrr9a5hr0xj26snygszlmgrdv6nma-python-rpy2-3.0.4-1.19868a8
+++ 
/gnu/store/lvmrrr9a5hr0xj26snygszlmgrdv6nma-python-rpy2-3.0.4-1.19868a8-check
├── lib
│ ├── python3.7
│ │ ├── site-packages
│ │ │ ├── __pycache__
│ │ │ │ ├── _rinterface_cffi.cpython-37.pyc
│ │ │ │ │┄ xxd not available in path. Falling back to Python hexlify.
│ │ │ │ │ @@ -1,8 +1,8 @@
│ │ │ │ │ -420d0d0a3e42785d403ee309
│ │ │ │ │ +420d0d0a1342785d403ee309
│ │ │ │ │  004000732400640064016c005a0065006a0164026403640464056406
│ │ │ │ │  6407640864098d075a0264015300290ae94eda105f72696e74657266
│ │ │ │ │  6163655f636969012673c8041d0d000f400d0001
│ │ │ │ │  1003000f00010f0d0311000f590d03111b01
│ │ │ │ │  000f600d0311000f240d0311000f0001150d
│ │ │ │ │  0311000f680d03111b01000f930d0311
│ │ │ │ │  000f290d0001090300010d0300010e031e111f11000f

This is fixed on core-update by commit 6bbb37a5459.

Maxim

bug#37374: "Guix is too old and cannot be upgraded" (guix package -u)

[melon]

I was attempting to upgrade my Guix (binary, on Linux Mint) installation
today using the 'guix package pull && guix package -u' commands, and Guix 
outputted the following error:

ERROR: In procedure raise:
Wrong type (expecting exact integer): #
guix pull: error: You found a bug: the program 
'/gnu/store/y1kqj5ikxx9niyz2zx1gbikspi2xfmi4-compute-guix-derivation'
failed to compute the derivation for Guix (version: 
"7e143375d3649f3c0bd4c13958b26c086f364647"; system: "x86_64-linux";
host version: "aa4818c33b6b2fd8d602ee93a2f53005d9472f41"; pull-version: 0).
Please report it by email to .

I searched the Web and mailing list archives for this error but could
not find anything. Maybe I used the wrong keywords.

Is there any way I can perform a "manual upgrade" to a newer Guix
version?

bug#37373: python-ipython-documentation build is not reproducible

[Maxim Cournoyer]

Here's the diff produced by diffoscope:

--- 
/gnu/store/crwhhm91cgms8fnydvqkmbqbjrypqv48-python-ipython-documentation-7.5.0
+++ 
/gnu/store/crwhhm91cgms8fnydvqkmbqbjrypqv48-python-ipython-documentation-7.5.0-check
├── share
│ ├── doc
│ │ ├── python-ipython-documentation-7.5.0
│ │ │ ├── html
│ │ │ │ ├── sphinxext.html
│ │ │ │ │┄ xxd not available in path. Falling back to Python hexlify.
│ │ │ │ │ @@ -1182,29 +1182,29 @@
│ │ │ │ │  3d226e223e6461746574696d653c2f7370616e3e3c7370616e20636c6173733d
│ │ │ │ │  226f223e2e3c2f7370616e3e3c7370616e20636c6173733d226e223e64617465
│ │ │ │ │  74696d653c2f7370616e3e3c7370616e20636c6173733d226f223e2e3c2f7370
│ │ │ │ │  616e3e3c7370616e20636c6173733d226e223e6e6f773c2f7370616e3e3c7370
│ │ │ │ │  616e20636c6173733d2270223e28293c2f7370616e3e0a3c7370616e20636c61
│ │ │ │ │  73733d226770223e2020202e2e2e3a203c2f7370616e3e0a3c7370616e20636c
│ │ │ │ │  6173733d22676f223e4f75745b325d3a206461746574
│ │ │ │ │ -696d652e6461746574696d6528323031392c20392c2031312c20302c2031362c
│ │ │ │ │ -2033372c20363833363634293c2f7370616e3e0a3c2f7072653e3c2f6469763e
│ │ │ │ │ +696d652e6461746574696d6528323031392c20392c2031312c20302c2032312c
│ │ │ │ │ +2031322c20353230363534293c2f7370616e3e0a3c2f7072653e3c2f6469763e
│ │ │ │ │  0a3c2f6469763e0a3c703e497420737570706f7274732049507974686f6e2063
│ │ │ │ │  6f6e737472756374207468617420706c61696e0a507974686f6e20646f657320
│ │ │ │ │  6e6f7420756e6465727374616e6420286c696b65206d6167696373293a3c2f70
│ │ │ │ │  3e0a3c64697620636c6173733d22686967686c696768742d69707974686f6e20
│ │ │ │ │  6e6f7472616e736c617465223e3c64697620636c6173733d22686967686c6967
│ │ │ │ │  6874223e3c7072653e3c7370616e3e3c2f7370616e3e3c7370616e20636c6173
│ │ │ │ │  733d226770223e496e205b335d3a203c2f7370616e3e3c7370616e20636c6173
│ │ │ │ │  733d226b6e223e696d706f72743c2f7370616e3e203c7370616e20636c617373
│ │ │ │ │  3d226e6e223e74696d653c2f7370616e3e0a0a3c7370616e20636c6173733d22
│ │ │ │ │  6770223e496e205b345d3a203c2f7370616e3e3c7370616e20636c6173733d22
│ │ │ │ │  6f223e253c2f7370616e3e3c7370616e20636c6173733d226b223e74696d6569
│ │ │ │ │  743c2f7370616e3e2074696d652e736c65657028302e3035290a3c7370616e20
│ │ │ │ │ -636c6173733d22676f223e35302e31206d73202b2d20322e3331207573207065
│ │ │ │ │ +636c6173733d22676f223e35302e31206d73202b2d20322e3135207573207065
│ │ │ │ │  72206c6f6f7020286d65616e202b2d207374642e206465762e206f6620372072
│ │ │ │ │  756e732c203130206c6f6f70732065616368293c2f7370616e3e0a3c2f707265
│ │ │ │ │  3e3c2f6469763e0a3c2f6469763e0a3c703e546869732077696c6c20616c736f
│ │ │ │ │  20737570706f727420746f702d6c6576656c206173796e63207768656e207573
│ │ │ │ │  696e672049507974686f6e20372e302b3c2f703e0a3c64697620636c6173733d
│ │ │ │ │  22686967686c696768742d69707974686f6e206e6f7472616e736c617465223e
│ │ │ │ │  3c64697620636c6173733d22686967686c69676874223e3c7072653e3c737061

bug#37371: CMake’s “ctest” doesn’t know about X.509 certificates

[Ludovic Courtès]

Hello,

Tobias Geerinckx-Rice  skribis:

> Ricardo Wurmus 写道：
>> This is the correct way, in my opinion.  The user of libcurl is
>> supposed
>> to handle environment variable lookup.
>
> I'm aware of this, but it seems like some users don't do this.

I’ve pushed this as 489d16577e4a6ccc30f3719d9263900089edd842.

We can revisit the libcurl issue later on (as we regularly do :-)).

Thanks for your feedback,
Ludo’.

bug#28159: Updater needs to support HTTP(S) servers

[Hartmut Goebel]

Am 22.08.17 um 10:57 schrieb Ludovic Courtès:
> More precisely, several updaters rely on FTP (gnu, kernel.org, kde,
> etc. see (guix gnu-maintenance)), but others rely on structured data
> retrieved over HTTP(S) (pypi, cran, elpa, etc.)

For the records: KDE no longer relies on FTP access. It now fetches the
ls-lR.bz2 file list using HTTPS from download.kde.org, converts it into
a list of file paths and caches the list.

See http://debbugs.gnu.org/cgi/bugreport.cgi?bug=36919
commit 4eb69bf0d33810886ee118f38989cef696e4c868

-- 
Regards
Hartmut Goebel

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

bug#29071: Acknowledgement (guix refresh --type=kde does not update all kde packages)

[Hartmut Goebel]

Finally fixed by by http://debbugs.gnu.org/cgi/bugreport.cgi?bug=36919
commit 4eb69bf0d33810886ee118f38989cef696e4c868

-- 
Regards
Hartmut Goebel

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

bug#25020: Finally fixed

[Hartmut Goebel]

Finally fixed by by http://debbugs.gnu.org/cgi/bugreport.cgi?bug=36919
commit 4eb69bf0d33810886ee118f38989cef696e4c868

-- 
Regards
Hartmut Goebel

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

bug#30345: Acknowledgement (guix refreh --type=kde does not update all KF5 packages)

[Hartmut Goebel]

Closed by http://debbugs.gnu.org/cgi/bugreport.cgi?bug=36919
commit 4eb69bf0d33810886ee118f38989cef696e4c868

-- 
Regards
Hartmut Goebel

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

bug#37371: CMake’s “ctest” doesn’t know about X.509 certificates

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Ricardo,

Ricardo Wurmus 写道：
This is the correct way, in my opinion.  The user of libcurl is 
supposed

to handle environment variable lookup.


I'm aware of this, but it seems like some users don't do this.

On #guix, Tobias also rightfully suggested adding a ‘getenv’ 
call
directly in libcurl, which may be the better long-term solution 
(though
it’s unclear whether that could interfere with application 
logic.)


This idea has been around for a pretty long time.  I don’t 
really like
it, but it would solve so many problems where users of libcurl 
don’t do
env var lookups and fall back to the default, which is not 
guaranteed to

exist when using Guix on foreign distros or even on Guix System.


Yeah, I explicitly said it was evil ;-)

I don't ‘like’ it either, but don't know enough about libcurl to 
think of a better solution.


Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#37363: emacs and other programs do not display special characters

[Ricardo Wurmus]

quil...@riseup.net writes:

> Also with (locale "es_ES.utf8"), the system is all in English and Gnome
> Terminal will not start:
> quiliro@GSD3 ~$ gnome-terminal
> # Locale not supported by C library.
> # Using the fallback 'C' locale.

Do you have “glibc-locales” installed?
Is GUIX_LOCPATH set?

-- 
Ricardo

bug#37371: CMake’s “ctest” doesn’t know about X.509 certificates

[Ricardo Wurmus]

Ludovic Courtès  writes:

> The ‘ctest’ command uses libcurl to submit reports to CDash servers.
> However, it does not “getenv” anything related to CA certs, and it does
> not either look at /etc/ssl/certs.
[…]
>
> For now I propose to provide a patched ‘cmake’ package that does the
> right thing.

This is the correct way, in my opinion.  The user of libcurl is supposed
to handle environment variable lookup.

> On #guix, Tobias also rightfully suggested adding a ‘getenv’ call
> directly in libcurl, which may be the better long-term solution (though
> it’s unclear whether that could interfere with application logic.)

This idea has been around for a pretty long time.  I don’t really like
it, but it would solve so many problems where users of libcurl don’t do
env var lookups and fall back to the default, which is not guaranteed to
exist when using Guix on foreign distros or even on Guix System.

--
Ricardo

bug#37371: CMake’s “ctest” doesn’t know about X.509 certificates

[Ludovic Courtès]

Hello,

The ‘ctest’ command uses libcurl to submit reports to CDash servers.
However, it does not “getenv” anything related to CA certs, and it does
not either look at /etc/ssl/certs.

The culprit is this function:

--8<---cut here---start->8---
std::string cmCurlSetCAInfo(::CURL* curl, const char* cafile)
{
  std::string e;
  if (cafile && *cafile) {
::CURLcode res = ::curl_easy_setopt(curl, CURLOPT_CAINFO, cafile);
check_curl_result(res, "Unable to set TLS/SSL Verify CAINFO: ");
  }
#ifdef CMAKE_FIND_CAFILE
#  define CMAKE_CAFILE_FEDORA "/etc/pki/tls/certs/ca-bundle.crt"
  else if (cmSystemTools::FileExists(CMAKE_CAFILE_FEDORA, true)) {
::CURLcode res =
  ::curl_easy_setopt(curl, CURLOPT_CAINFO, CMAKE_CAFILE_FEDORA);
check_curl_result(res, "Unable to set TLS/SSL Verify CAINFO: ");
  }
#  undef CMAKE_CAFILE_FEDORA
  else {
#  define CMAKE_CAFILE_COMMON "/etc/ssl/certs/ca-certificates.crt"
if (cmSystemTools::FileExists(CMAKE_CAFILE_COMMON, true)) {
  ::CURLcode res =
::curl_easy_setopt(curl, CURLOPT_CAINFO, CMAKE_CAFILE_COMMON);
  check_curl_result(res, "Unable to set TLS/SSL Verify CAINFO: ");
}
#  undef CMAKE_CAFILE_COMMON
#  define CMAKE_CAPATH_COMMON "/etc/ssl/certs"
if (cmSystemTools::FileIsDirectory(CMAKE_CAPATH_COMMON)) {
  ::CURLcode res =
::curl_easy_setopt(curl, CURLOPT_CAPATH, CMAKE_CAPATH_COMMON);
  check_curl_result(res, "Unable to set TLS/SSL Verify CAPATH: ");
}
#  undef CMAKE_CAPATH_COMMON
  }
#endif
  return e;
}
--8<---cut here---end--->8---

The problem is that ‘CMAKE_FIND_CAFILE’ is undefined in our case:

--8<---cut here---start->8---
#if !defined(CMAKE_USE_SYSTEM_CURL) && !defined(_WIN32) &&\
  !defined(__APPLE__) && !defined(CURL_CA_BUNDLE) && !defined(CURL_CA_PATH)
#  define CMAKE_FIND_CAFILE
#  include "cmSystemTools.h"
#endif
--8<---cut here---end--->8---

Thus it doesn’t look for certificates *at all*, and eventually fails
with:

--8<---cut here---start->8---
   Error when uploading file: …
   Error message was: server certificate verification failed. CAfile: none 
CRLfile: none
   Problems when submitting via HTTP
Errors while running CTest
--8<---cut here---end--->8---

For now I propose to provide a patched ‘cmake’ package that does the
right thing.

On #guix, Tobias also rightfully suggested adding a ‘getenv’ call
directly in libcurl, which may be the better long-term solution (though
it’s unclear whether that could interfere with application logic.)

Ludo’.

bug#37357: Guix gc removes next-gtk-webkit input with next installed

[Dimakakos Dimos]

Ricardo Wurmus writes:

> Can you tell us what version of Guix you used to install Next?  There
> was a short period during which the Next executable was compressed,
> which effectively hid references from the garbage collector.

OK, so I checked and it seems that I installed next while there was the
patch for the executable compression, particularly commit 79c6d8781b, in
master. I will try again to rebuild and then gc to check if it works as
intended and then close this bug.  Thanks!

bug#36896: [PATCH] added gsettings-desktop-schema to progragated inputs

[Martin Becze]

ping :P

> ---
>
>  gnu/packages/gnome.scm | 19 ++-
>  1 file changed, 10 insertions(+), 9 deletions(-)
>
> diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm
> index 1a091de938..ef6d78bb5a 100644
> --- a/gnu/packages/gnome.scm
> +++ b/gnu/packages/gnome.scm
> @@ -8105,19 +8105,20 @@ generic enough to work for everyone.")
> #:phases
> (modify-phases %standard-phases
>   (add-after
> -  'install 'wrap-program
> -  (lambda* (#:key inputs outputs #:allow-other-keys)
> -   (let ((out (assoc-ref outputs "out")))
> - (wrap-program (string-append out "/bin/evolution")
> -`("GSETTINGS_SCHEMA_DIR" = (,(string-append out 
> "/share/glib-2.0/schemas/")))
> -`("XDG_DATA_DIRS" = (,(getenv "XDG_DATA_DIRS")
> -   #t)))
> + 'install 'wrap-program
> +   (lambda* (#:key inputs outputs #:allow-other-keys)
> + (let ((out (assoc-ref outputs "out")))
> +   (wrap-program (string-append out "/bin/evolution")
> + `("XDG_DATA_DIRS" prefix (,(getenv "XDG_DATA_DIRS")))
> + `("GSETTINGS_SCHEMA_DIR" =
> +   (,(string-append out "/share/glib-2.0/schemas/")
> + #t)))
> #:configure-flags
> (list "-DENABLE_PST_IMPORT=OFF"; libpst is not packaged
>   "-DENABLE_LIBCRYPTUI=OFF"))) ; libcryptui hasn't seen a release
> -  ; in four years and cannot be 
> built.
> +; in four years and cannot be built.
>  (native-inputs
> - `(("glib" ,glib "bin")   ; glib-mkenums
> + `(("glib" ,glib "bin") ; glib-mkenums
> ("pkg-config" ,pkg-config)
> ("intltool" ,intltool)
> ("itstool" ,itstool)))
> -- 
> 2.23.0

On 9/6/19 1:49 PM, Martin Becze wrote:
> Yeah I don't know. I just used prefix in the latest patch. Let me know
> if the other method is preferred.
>
> On 9/6/19 12:30 PM, Tobias Geerinckx-Rice wrote:
>> Martin,
>>
>> Martin Becze 写道：
>>> Prefix appends ${MY_VAR:+:}$MY_VAR to the env var, so that seems nice.
>> Sure, that's what I'd expect, but why is it preferred over keeping any
>> user-defined entries first?
>>
>> Kind regards,
>>
>> T G-R


signature.asc
Description: OpenPGP digital signature

bug#37369: Getting network-manager-openconnect to work

[pelzflorian (Florian Pelz)]

On Tue, Sep 10, 2019 at 11:57:11AM +0200, Divan Santana wrote:
> Hi Guix,
> 
> I'm glad openconnect and network-manager-openconnect are now in Guix!
> 
> It would be nice to get it to work via network-manager, though I suppose
> it's not essential.
> 
> Using openconnect directly works for me.
> 
> $ sudo openconnect vpn.somewhere.com
> 
> Trying to get it work via network-manager gives an error like so:
> 
> $ sudo nmcli con up vpn-fnb --ask
> Error: openconnect failed: Could not find "openconnect" binary
> A password is required to connect to 'vpn-fnb'.
> Gateway (vpn.secrets.gateway):
> 
> Even though my services configuration has this vpn-plugins set.
> 
> (modify-services %desktop-services
>  (network-manager-service-type
>   config => (network-manager-configuration
>  (inherit config)
>  (dns "dnsmasq")
>  (vpn-plugins (list network-manager-openconnect))
>  ))
> 
> Anyone else seen this?

Cc’ing bug-guix@gnu.org

I suspect something like the attached patch would help (and expand the
closure of network-manager to always include openconnect).

To test, follow section “Building from Git” from the manual or Laura’s
video 04-packaging-part-one.webm from
,
but after the initial clone command, do

  git apply the-attached.patch

Then after make, do

  sudo -E ./pre-inst-env guix system reconfigure /etc/config.scm

(or whatever your configuration file is called).  I cannot test right
now and have never used openconnect.  It is quite possible I made a
mistake.

Regards,
Florian
>From 8de7675a2dc2c1385d312e35136f8fa9eb4f9825 Mon Sep 17 00:00:00 2001
From: Florian Pelz 
Date: Tue, 10 Sep 2019 12:59:19 +0200
Subject: [PATCH] gnu: network-manager: Enable openconnect helper.

* gnu/packages/gnome.scm (network-manager): Add openconnect input.
Patch source to use it instead of searching /usr/bin.
---
 gnu/packages/gnome.scm | 8 
 1 file changed, 8 insertions(+)

diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm
index efe5206e53..a6ea09d8f6 100644
--- a/gnu/packages/gnome.scm
+++ b/gnu/packages/gnome.scm
@@ -5372,6 +5372,13 @@ users.")
(("src/devices/tests/test-lldp") " ")
(("src/tests/test-route-manager-linux") " "))
  #t))
+ (add-after 'unpack 'patch-source
+   (lambda* (#:key inputs #:allow-other-keys)
+ (begin
+   (substitute* "clients/common/nm-vpn-helpers.c"
+ (("\\\"/usr/sbin/openconnect\\\"")
+  (string-append openconnect "\"/bin/openconnect\"")))
+   #t)))
  (add-after 'unpack 'delete-failing-tests
(lambda _
  ;; FIXME: These four tests fail for unknown reasons.
@@ -5434,6 +5441,7 @@ users.")
("libsoup" ,libsoup)
("modem-manager" ,modem-manager)
("newt" ,newt)   ;for the 'nmtui' console interface
+   ("openconnect" ,openconnect)
("polkit" ,polkit)
("ppp" ,ppp)
("readline" ,readline)
-- 
2.23.0

bug#37363: emacs and other programs do not display special characters

[quiliro]

On M-x shell with (locale "es_ES.utf8"):
quiliro@GSD3 ~$ ñ
bash: $'quiliro@GSD3 ~$ ñ
bash: $'\361': command not found\361': command not found
quiliro@GSD3 ~$

Also with (locale "es_ES.utf8"), the system is all in English and Gnome
Terminal will not start:
quiliro@GSD3 ~$ gnome-terminal
# Locale not supported by C library.
#   Using the fallback 'C' locale.
# Error constructing proxy for
org.gnome.Terminal:/org/gnome/Terminal/Factory0: Error calling
StartServiceByName for org.gnome.Terminal:
GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Process
org.gnome.Terminal exited with status 9
quiliro@GSD3 ~$

I have also tested unknown command error output. On Emacs' M-x shell with
(locale "es_EC.UTF-8"):
quiliro@GSD3 ~$ ñ
bash: $'\361': no se encontró la orden
quiliro@GSD3 ~$

On BASh with (locale "es_EC.UTF-8"):
quiliro@GSD3 ~$ ñ
bash: ñ: no se encontró la orden
quiliro@GSD3 ~$

I have tested this with:
guix (GNU Guix) 1d03a9198db6f3656a34d62eb89e5f7d5a99e76a
and with:
guix (GNU Guix) 83aa6562173e06e8fafd4857a2e708feabfe56f8

bug#37366: ghci can't find System.IO

[P via Bug reports for GNU Guix]

with the latest ghc (qhws2nyqmjansrnqf78mz87l74v01mfx-ghc-8.6.5) i cannot start 
ghci, due to the following error[1]

I do not have any other Haskell package in my profile


[1]:
```
GHCi, version 8.6.5: http://www.haskell.org/ghc/  :? for help

:1:6: error:
Not in scope: ‘System.IO.hSetBuffering’
No module named ‘System.IO’ is imported.

:1:30: error:
Not in scope: ‘System.IO.stdin’
No module named ‘System.IO’ is imported.

:1:46: error:
Not in scope: data constructor ‘System.IO.NoBuffering’
No module named ‘System.IO’ is imported.

:1:70: error:
Not in scope: ‘System.IO.hSetBuffering’
No module named ‘System.IO’ is imported.

:1:94: error:
Not in scope: ‘System.IO.stdout’
No module named ‘System.IO’ is imported.

:1:111: error:
Not in scope: data constructor ‘System.IO.NoBuffering’
No module named ‘System.IO’ is imported.

:1:135: error:
Not in scope: ‘System.IO.hSetBuffering’
No module named ‘System.IO’ is imported.

:1:159: error:
Not in scope: ‘System.IO.stderr’
No module named ‘System.IO’ is imported.

:1:176: error:
Not in scope: data constructor ‘System.IO.NoBuffering’
No module named ‘System.IO’ is imported.
```

bug#37249: console shell upon login is not ~/.guix-profile/bash -- is this always/never ok?

[Efraim Flashner]

This is something I'm also interested in. Something I've found while
looking around online is checking 'ssh server env | grep PATH', and on
my Guix System machines I see it is PATH=/run/current-system/profile/bin.
It seems that playing with ~/.ssh/environment and/or ~/.ssh/rc might
yield changes, but the real question IMO is if you can change things
without changing sshd_config.

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature