bug#52051: [core-updates-frozen] cannot login ('org.freedesktop.login1' service times out)

[Maxim Cournoyer]

Hello,

I'm not 100% sure this is the cause, but these are the last messages I
have before I rebooted:

--8<---cut here---start->8---
Nov 23 01:09:14 localhost dbus-daemon[383]: [system] Activating service 
name='org.freedesktop.login1' requested by ':1.17' (uid=0 pid=370
comm="/gnu/store/ximad0zvg12r4x0x80mvym8hzg0n33jl-shadow") (using 
servicehelper)
Nov 23 01:09:14 localhost elogind[1189]: elogind is already running as PID 390
Nov 23 01:09:20 localhost shepherd[1]: Respawning term-tty1. 
Nov 23 01:09:20 localhost shepherd[1]: Service host-name has been started. 
Nov 23 01:09:20 localhost shepherd[1]: Service term-tty1 has been started.
Nov 23 01:09:39 localhost dbus-daemon[383]: [system] Failed to activate service 
'org.freedesktop.login1': timed out (service_start_timeout=25000ms)
--8<---cut here---end--->8---

I don't remember if I saw the slim login screen; but in any case I
couldn't successfully login even via a ptty.

It may have to do with polkit.

To be investigated.

This happened on a system *not* using gdm (it uses slim) and with
ratpoison as the WM, on commit f42bc604547d9ee8e35fcd66d5db7786954cfac3
of the core-updates-frozen branch.

To be investigated.

Thanks,

Maxim

bug#51252: [core-updates-frozen] lualatex needs additional setup

[Thiago Jung Bauermann via Bug reports for GNU Guix]

Hello,

I did some investigation about this problem today. Sorry for the trouble.

Em quarta-feira, 20 de outubro de 2021, às 18:45:35 -03, Ricardo Wurmus 
escreveu:
> “texlive-latex-base” provides that file.  We disable a whole bunch
> of formats that we cannot build that early in the process, and
> then we run fmtutil-sys on the patched file.
> The cause for trouble lies in texlive-kpathsea, which provides
> share/texmf-dist/web2c/fmtutil.cnf
> .  That file states how to build the various fmt files.
> 
> The file in the earlier version of Tex Live contains this line for the
> lualatex format:
> 
> lualatex luatex language.dat,language.dat.lua lualatex.ini
> 
> the new file (on core-updates-frozen) says this:
> 
> lualatex luahbtex language.dat,language.dat.lua lualatex.ini
> 
> i.e. it will try to build the lualatex fmt file with luahbtex
> instead of luatex.

Thank you for this analysis!

> I suppose at this point in the build we don’t
> actually have a working luahbtex, so fmtutil-sys doesn’t generate
> the correct lualatex.fmt.

Looking at the build log of ‘texlive-latex-base’ from the core-updates-
frozen branch, LuaHBTeX seems to be functional at the time it is used to 
generate ‘lualatex.fmt’. Comparing it to the build log of the same package 
on master, there are some differences though:

• core-updates-frozen shows the following messages:
  • “No file TS1lmr.fd.”
  • “No file latex2e-first-aid-for-external-files.ltx.”
• core-updates-frozen lists some fonts with strange names and sizes:
  • \font\c__fp_exp_intarray=cmr10 at 0.2pt
  • \font\c__fp_trig_intarray=cmr10 at 0.3pt
  • \font\g__regex_state_active_intarray=cmr10 at 0.5pt
  • \font\g__regex_thread_info_intarray=cmr10 at 0.6pt
  • \font\g__regex_submatch_prev_intarray=cmr10 at 0.8pt
  • \font\g__regex_submatch_begin_intarray=cmr10 at 0.9pt
  • \font\g__regex_submatch_end_intarray=cmr10 at 0.0001pt
  • \font\g__regex_balance_intarray=cmr10 at 0.00012pt
• master instals file at web2c/luatex/lualatex.fmt, while
  core-updates-frozen installs it at web2c/luahbtex/lualatex.fmt.

This last difference coupled with the following excerpt from the TexLive 
news section¹:

  “LuaTeX: Integration with HarfBuzz library, available as new engines 
   luahbtex (used for lualatex) and luajithbtex.”

suggests that the command ‘lualatex’ is supposed to invoke the LuaHBTeX
engine rather than the LuaTeX engine. Indeed, when using LuaHBTeX
explicitly, there’s no error about the format file. Unfortunately, there’s an
error about font loading:

--8<---cut here---start->8---
popigai ⸤env⸥: luahbtex '' hello.tex
This is LuaHBTeX, Version 1.13.0 (TeX Live 2021/GNU Guix) 
 restricted system commands enabled.
(./hello.tex
LaTeX2e <2020-10-01> patch level 4
 L3 programming layer <2021-02-18> 
(/gnu/store/nx4jih5xnm6hzfgvi04w4wkp4pbma8bm-profile/share/texmf-dist/tex/latex/base/article.cls
Document Class: article 2020/04/10 v1.4m Standard LaTeX document class
(/gnu/store/nx4jih5xnm6hzfgvi04w4wkp4pbma8bm-profile/share/texmf-dist/tex/latex/base/size10.clo
luaotfload | db : Font names database not found, generating new one.
luaotfload | db : This can take several minutes; please be patient.
luaotfload | db : Reload initiated (formats: otf,ttf,ttc); reason: File not 
found: "lmroman10-regular".
! Font \TU/lmr/m/n/10=[lmroman10-regular]:+tlig; at 10pt not loadable: metric 
data not found or bad.
 
relax 
l.54 \normalsize
  
? 
--8<---cut here---end--->8---

I tried running `luaotfload-tool --update` as suggested on the interwebs
for a similar problem, but I ran into a separate issue with that tool:

--8<---cut here---start->8---
popigai ⸤env⸥: luaotfload-tool --update
...ih5xnm6hzfgvi04w4wkp4pbma8bm-profile/bin/luaotfload-tool:183: module 
'alt_getopt' not found:
no field package.preload['alt_getopt']
[kpse lua searcher] file not found: 'alt_getopt'
[kpse C searcher] file not found: 'alt_getopt'
popigai ⸤env⸥: 
--8<---cut here---end--->8---

-- 
Thanks,
Thiago

¹ https://tug.org/texlive/doc/texlive-en/texlive-en.html#news

bug#51696: (no subject)

[jgart]

I primarily access #guix on irc.libera.chat from gajim (xmpp client) over a 
bridge. 

I think Raghav Gururajan mostly uses xmpp bridges also for irc last time we 
chatted.

Regarding matrix clients,

Arun Isaac packaged weechat-matrix for guix recently:

see the following commit on master: 7ebed0cdc8043852bed7f5ca639f16bac30cc124

gomuks is a nice tui matrix client that I use daily when element takes forever 
to load in my browser:

https://maunium.net/go/gomuks/

I'm hoping to package it at some point. I currently install gomuks with nix...

It would be cool to self-host a Guix System deployed matrix home server at some 
point in the future.

Ideally, the server is implemented in guile instead of python (default 
homeserver), of course :).

There are matrix servers implemented in python, elixir, rust, go, ...

* https://matrix.org/docs/projects/server/synapse
* https://matrix.org/docs/projects/server/dendrite
* https://matrix.org/docs/projects/server/conduit
* https://matrix.org/docs/projects/server/construct
* https://matrix.org/docs/projects/server/ligase
* https://matrix.org/docs/projects/server/maelstrom
* https://github.com/bismark/matrex

Matrix has a specification:

https://spec.matrix.org/latest/

List of matrix servers:

https://tatsumoto-ren.github.io/blog/list-of-matrix-servers.html

all best,

jgart

bug#52047: praat install non-gui binary

[jgart via Bug reports for GNU Guix]

Praat has a binary that can be installed for non-gui mode.

I think it would be cool to add it.

https://github.com/void-linux/void-packages/blob/1ec0a967598e7d5c62500b5f2f4d546a29cb6277/srcpkgs/praat/template#L64

bug#52046: [core-updates-frozen] vtk-8 fails to build

[Ricardo Wurmus]

VTK 8 fails to build on core-updates-frozen.  This blocks freecad. 
It looks like libraries aren’t properly linked with other VTK 
libraries.  The build log is littered with output like this:


--8<---cut here---start->8---
cd /tmp/guix-build-vtk-8.2.0.drv-0/build/Rendering/Context2D && 
/gnu/store/vakvgvrb839igv16jkif4lmx11d25jqb-gcc-10.3.0/bin/c++ 
-DVTK_IN_VTK -DvtkRenderingContext2D_EXPORTS 
-I/tmp/guix-build-vtk-8.2.0.drv-0/build/Rendering/Context2D 
-I/tmp/guix-build-vtk-8.2.0.drv-0/VTK-8.2.0/Rendering/Context2D 
-I/tmp/guix-build-vtk-8.2.0.drv-0/build/Common/Core 
-I/tmp/guix-build-vtk-8.2.0.drv-0/VTK-8.2.0/Common/Core 
-I/tmp/guix-build-vtk-8.2.0.drv-0/build/Utilities/KWIML 
-I/tmp/guix-build-vtk-8.2.0.drv-0/VTK-8.2.0/Utilities/KWIML 
-I/tmp/guix-build-vtk-8.2.0.drv-0/build/Utilities/KWSys 
-I/tmp/guix-build-vtk-8.2.0.drv-0/VTK-8.2.0/Utilities/KWSys 
-I/tmp/guix-build-vtk-8.2.0.drv-0/build/ThirdParty/utf8 
-I/tmp/guix-build-vtk-8.2.0.drv-0/VTK-8.2.0/ThirdParty/utf8 
-I/tmp/guix-build-vtk-8.2.0.drv-0/build/Common/DataModel 
-I/tmp/guix-build-vtk-8.2.0.drv-0/VTK-8.2.0/Common/DataModel 
-I/tmp/guix-build-vtk-8.2.0.drv-0/build/Common/Math 
-I/tmp/guix-build-vtk-8.2.0.drv-0/VTK-8.2.0/Common/Math 
-I/tmp/guix-build-vtk-8.2.0.drv-0/build/Common/Misc 
-I/tmp/guix-build-vtk-8.2.0.drv-0/VTK-8.2.0/Common/Misc 
-I/tmp/guix-build-vtk-8.2.0.drv-0/build/Common/System 
-I/tmp/guix-build-vtk-8.2.0.drv-0/VTK-8.2.0/Common/System 
-I/tmp/guix-build-vtk-8.2.0.drv-0/build/Common/Transforms 
-I/tmp/guix-build-vtk-8.2.0.drv-0/VTK-8.2.0/Common/Transforms 
-I/tmp/guix-build-vtk-8.2.0.drv-0/build/Common/ExecutionModel 
-I/tmp/guix-build-vtk-8.2.0.drv-0/VTK-8.2.0/Common/ExecutionModel 
-I/tmp/guix-build-vtk-8.2.0.drv-0/build/Filters/General 
-I/tmp/guix-build-vtk-8.2.0.drv-0/VTK-8.2.0/Filters/General 
-I/tmp/guix-build-vtk-8.2.0.drv-0/build/Common/ComputationalGeometry 
-I/tmp/guix-build-vtk-8.2.0.drv-0/VTK-8.2.0/Common/ComputationalGeometry 
-I/tmp/guix-build-vtk-8.2.0.drv-0/build/Filters/Core 
-I/tmp/guix-build-vtk-8.2.0.drv-0/VTK-8.2.0/Filters/Core 
-I/tmp/guix-build-vtk-8.2.0.drv-0/build/Rendering/Core 
-I/tmp/guix-build-vtk-8.2.0.drv-0/VTK-8.2.0/Rendering/Core 
-I/tmp/guix-build-vtk-8.2.0.drv-0/build/Common/Color 
-I/tmp/guix-build-vtk-8.2.0.drv-0/VTK-8.2.0/Common/Color 
-I/tmp/guix-build-vtk-8.2.0.drv-0/build/Filters/Geometry 
-I/tmp/guix-build-vtk-8.2.0.drv-0/VTK-8.2.0/Filters/Geometry 
-I/tmp/guix-build-vtk-8.2.0.drv-0/build/Filters/Sources 
-I/tmp/guix-build-vtk-8.2.0.drv-0/VTK-8.2.0/Filters/Sources 
-I/tmp/guix-build-vtk-8.2.0.drv-0/build/Rendering/FreeType 
-I/tmp/guix-build-vtk-8.2.0.drv-0/VTK-8.2.0/Rendering/FreeType 
-I/tmp/guix-build-vtk-8.2.0.drv-0/build/ThirdParty/freetype 
-I/tmp/guix-build-vtk-8.2.0.drv-0/VTK-8.2.0/ThirdParty/freetype 
-I/gnu/store/375858dr3cqbwry58xcgc0776205p0mf-freetype-2.10.4/include/freetype2 
-I/tmp/guix-build-vtk-8.2.0.drv-0/build/ThirdParty/zlib 
-I/tmp/guix-build-vtk-8.2.0.drv-0/VTK-8.2.0/ThirdParty/zlib -O3 
-DNDEBUG -fPIC -fvisibility=hidden -std=c++11 -MD -MT 
Rendering/Context2D/CMakeFiles/vtkRenderingContext2D.dir/vtkPolyDataItem.cxx.o 
-MF CMakeFiles/vtkRenderingContext2D.dir/vtkPolyDataItem.cxx.o.d 
-o CMakeFiles/vtkRenderingContext2D.dir/vtkPolyDataItem.cxx.o -c 
/tmp/guix-build-vtk-8.2.0.drv-0/VTK-8.2.0/Rendering/Context2D/vtkPolyDataItem.cxx
ld: 
/tmp/guix-build-vtk-8.2.0.drv-0/build/lib/libvtkFiltersGeneral-8.2.so.1: 
undefined reference to `vtkStreamerBase::~vtkStreamerBase()'
ld: ../../lib/libvtkCommonDataModel-8.2.so.1: undefined reference 
to `vtkPoints::SetDataType(int)'
ld: ../../lib/libvtkRenderingOpenGL2-8.2.so.1: undefined reference 
to 
`vtkCompositeDataDisplayAttributes::RemoveBlockVisibility(vtkDataObject*)'
ld: ../../lib/libvtkCommonTransforms-8.2.so.1: undefined reference 
to `vtkMath::LinearSolve3x3(float const (*) [3], float const*, 
float*)'
ld: ../../lib/libvtkFiltersCore-8.2.so.1: undefined reference to 
`vtkFunctionParser::SetFunction(char const*)'
ld: ../../lib/libvtkFiltersCore-8.2.so.1: undefined reference to 
`vtkIdListCollection::New()'
ld: ../../lib/libvtkRenderingOpenGL2-8.2.so.1: undefined reference 
to `vtkRenderWindowInteractor::KeyPressEvent()'
ld: ../../lib/libvtkRenderingOpenGL2-8.2.so.1: undefined reference 
to `vtkActor2D::GetActors2D(vtkPropCollection*)'
ld: 
/tmp/guix-build-vtk-8.2.0.drv-0/build/lib/libvtkFiltersGeneral-8.2.so.1: 
undefined reference to `vtkLine::Intersection3D(double*, double*, 
double*, double*, double&, double&)'
ld: ../../lib/libvtkRenderingCore-8.2.so.1: undefined reference to 
`vtkUnicodeString::vtkUnicodeString()'
ld: ../../lib/libvtkRenderingOpenGL2-8.2.so.1: undefined reference 
to `vtkProp::Pick()'
ld: ../../lib/libvtkFiltersCore-8.2.so.1: undefined reference to 
`vtkMoleculeAlgorithm::vtkMoleculeAlgorithm()'
ld: 
/tmp/guix-build-vtk-8.2.0.drv-0/build/lib/libvtkFiltersGeometry-8.2.so.1: 
undefined reference to `vtkStructuredGrid::GetCellDims(int*)'
ld: 

bug#50243: [core-updates-frozen] "multiple definition of..." build failures

[Ricardo Wurmus]

More fixes:

a24b83d7ff gnu: uget: Add -fcommon to CFLAGS.
eceecd8ab4 gnu: transmission-remote-gtk: Update to 1.4.2.
92deae62c1 gnu: jumpnbump: Remove trailing #T.
02296cb0c8 gnu: jumpnbump: Add -fcommon to CFLAGS.
3e678de04c gnu: mupen64plus-core: Add -fcommon to CFLAGS.

This leaves pcsxr and ocaml4.07-lablgtk.  I wasn’t able to fix 
pcsxr and there’s no more recent tagged version to test.  I don’t 
really want to touch ocaml4.07-lablgtk, because it’s probably 
going to fail in ways I don’t understand.


Any takers for the remaining two packages?

--
Ricardo

bug#52031: gnome-terminal fails to start under sway on core-updates-frozen

[Jack Hill]

On Mon, 22 Nov 2021, Jack Hill wrote:


Hi Guix,

With core-updates-frozen commit b033079e47357dcf77ebeeb52b0a5306cd6aa982 
gnome-terminal fails to start under sway either as launched from gdm or 
directly from a vt with `dbus-run-session sway`.


```
$ gnome-terminal
# Error constructing proxy for 
org.gnome.Terminal:/org/gnome/Terminal/Factory0: Error calling 
StartServiceByName for org.gnome.Terminal: Process org.gnome.Terminal exited 
with status 10

```

It works correctly in a gnome session.


Josselin Poiret determined [0] that the root cause of this behavior is 
that gnome-terminal is being launched via dbus, but the bus doesn't know 
about the wayland display, so can't start graphical applications. 
Everything works as expected if dbus is told about the display, which can 
be done by adding the following like to the sway configuration:


```
exec dbus-update-activation-environment WAYLAND_DISPLAY
```

In my judgment, this issue shouldn't hold up the core-updates-frozen 
merge, but it would be nice to improve the out-of-the-box sway experience 
in the future. A possible way I see is a sway service type that puts the 
necessary configuration in /etc/sway/conf.d or otherwise installs a 
session .desktop file that performs the necessary setup.


[0] https://logs.guix.gnu.org/guix/2021-11-22.log#172513

Thoughts?
Jack

bug#39885: Bioconductor URI, fallback and time-machine

[zimoun]

Hi,

On Tue, 03 Mar 2020 at 16:59, zimoun  wrote:

> Currently, the URI scheme (see 'bioconductor-uri' in
> guix/build-system/r.scm) is:
>
>  
> https://bioconductor.org/packages/release/data//src/contrib/-.tar.gz
>
> which leads to 2 issues:
>
>  1. when Bioconductor updates their release, some package versions are
> updated too, and so, the upstream return 404.
>  2. for this reason 1., the "guix time-machine" is broken for all the
> Bioconductor packages, at least if Berlin or SWH does not have a
> substitute; which is not expected for 'annotation' packages.
>
> However, the Bioconductor archive still serves the old release, i.e.,
>
> https://bioconductor.org/packages/3.x/data//src/contrib/-.tar.gz

It is still the case and for concrete breakage, see [1].  I will not
detail but each time Guix lags behind Bioconductor new release, it is
broken.  For sure, Guix upgrades more or less quickly.  Each time
Bioconductor remove a package, it is broken.  Well, because a lot
of care about R packages, the forward breakages happen barely. :-)  But
backward breakages are not negligible, IMHO.


Well, this URL choice is not The Right Thing and somehow broken by design.

1: 


> The ways to fix the both issues are:
>
>  a) Add the Bioconductor release (known at packaging time) to all the
> packages; provide as argument to 'bioconductor-uri'.
>  b) Add more URLs to fallback.
>
> As discussed on IRC, Tobias seems more inclined with the option a) and
> I am more in favour of option b.
>
> Attached, a quick patch showing the option b).

We are now 1.5 years after.  And we did nothing; well we did other
things instead. ;-).  Now, I have an strong opinion that option a) is
not doable: I speak using my janitor moves of Bioconductor packages.

Instead, something along the proposed patch below half-fixes the issue
now.  We just have to append the releases and let the fallback mechanism
takes care.  It reduces the maintenance burden, IMHO.

For sure, it is not perfect but it appears to me a pragmatical fix
waiting something better.


This better is unknown (at least from me :-)).  On one hand Disarchive
would improve the situation for tarballs… but some work remains (check
that SWH ingestion and rebuild is bullet-proof).  On the other hand,
Bioconductor uses Git, for instance:

git clone https://git.bioconductor.org/packages/CATALYST



And Bioconductor uses ’origin/RELEASE_3.14’ as Git tag.  Based on this,
it would avoid the eternal inplace-change fixes.

For instance, the package tximeta [2], recently updated by Ricardo.
Well, from their Bioconductor Git repo,

git clone https://git.bioconductor.org/packages/tximeta

it is not clear that the current version is at 1.12.3.  And it is not
clear either if they tagged origin/RELEASE_3_14 at 1.12.0 and did
something ugly to then get 1.12.3.  Anyway, switch from url-fetch to
git-fetch is an option.  However, it is as option a) and I am not
convinced it is doable with the resource at hand.

2: 


What could a plan to have a bullet-proof “guix time-machine” for
Bioconductor?


Cheers,
simon


> From 87e73e02202fe5e342d68f1fb17efdd4425737cd Mon Sep 17 00:00:00 2001
> From: zimoun 
> Date: Tue, 3 Mar 2020 16:53:39 +0100
> Subject: [PATCH] build-system: r: Use Bioconductor old releases to fallback.
>
> * guix/build-system/r.scm (bioconductor-uri): Extend the fallback list.
> ---
>  guix/build-system/r.scm | 21 -
>  1 file changed, 12 insertions(+), 9 deletions(-)
>
> diff --git a/guix/build-system/r.scm b/guix/build-system/r.scm
> index 2d328764b0..8638e1b888 100644
> --- a/guix/build-system/r.scm
> +++ b/guix/build-system/r.scm
> @@ -54,15 +54,18 @@ release corresponding to NAME and VERSION."
>   ('annotation "/data/annotation")
>   ('experiment "/data/experiment")
>   (_ "/bioc"
> -(list (string-append "https://bioconductor.org/packages/release;
> - type-url-part
> - "/src/contrib/"
> - name "_" version ".tar.gz")
> -  ;; TODO: use %bioconductor-version from (guix import cran)
> -  (string-append "https://bioconductor.org/packages/3.10;
> - type-url-part
> - "/src/contrib/Archive/"
> - name "_" version ".tar.gz"
> +(append (list (string-append "https://bioconductor.org/packages/release;
> + type-url-part
> + "/src/contrib/"
> + name "_" version ".tar.gz"))
> +(map (lambda (release)
> +   (string-append "https://bioconductor.org/packages/;
> +  release
> +  

bug#50243: [core-updates-frozen] "multiple definition of..." build failures

[Ricardo Wurmus]

More fixes:

3d109b0306 gnu: uim-qt: Pass -fcommon to compiler.
108b923d92 gnu: uim-gtk: Pass -fcommon to compiler.
1882282843 gnu: megaglest: Pass -fcommon to compiler.

(Note that uim-qt still fails to install, because it attempts to 
install its library into the prefix directory of qtbase:


--8<---cut here---start->8---
make[3]: Entering directory 
'/tmp/guix-build-uim-qt-1.8.8.drv-0/uim-1.8.8/qt5/immodule'
/gnu/store/fildpz4qc0llifg8si9s7ag0vwlq1r2z-qtbase-5.15.2/bin/qmake 
-install qinstall -exe libuimplatforminputcontextplugin.so 
/gnu/store/fildpz4qc0llifg8si9s7ag0vwlq1r2z-qtbase-5.15.2/lib/qt5/plugins/platforminputcontexts/libuimplatforminputcontextplugin.so
Error copying libuimplatforminputcontextplugin.so to 
/gnu/store/fildpz4qc0llifg8si9s7ag0vwlq1r2z-qtbase-5.15.2/lib/qt5/plugins/platforminputcontexts/libuimplatforminputcontextplugin.so: 
Cannot create 
/gnu/store/fildpz4qc0llifg8si9s7ag0vwlq1r2z-qtbase-5.15.2/lib/qt5/plugins/platforminputcontexts/libuimplatforminputcontextplugin.so 
for output

--8<---cut here---end--->8---


--
Ricardo

bug#46016: broken Proof-General (emacs front-end to Coq)

[zimoun]

Hi,

On Wed, 10 Nov 2021 at 20:38, zimoun  wrote:

> 1: 

Done with cb296dfa2e2938d18ae0ee347bed0cc94bc79cf8.

Cheers,
simon

bug#50243: [core-updates-frozen] "multiple definition of..." build failures

[Ricardo Wurmus]

linsmith is now fixed with commit 3d32fd1a6e.

--
Ricardo

bug#52040: opam importer: unexpected “available: arch != "x86_32"“

[zimoun]

Hi,

--8<---cut here---start->8---
$ guix import opam biocaml
guix import: error: failed to download meta-data for package 'biocaml'
--8<---cut here---end--->8---

This package is defined on OPAM [1].  The issue is the field:

Available   arch != "x86_32" & arch != "arm32"

format known by the importer/parser but unexpected.  Therefore, it
raises an error and fails.

1: 


Cheers,
simon

bug#51848: `make && make check` fails

[Andrew Tropin]

On 2021-11-15 17:01, zimoun wrote:

> Hi,
>
> On dim., 14 nov. 2021 at 15:50, Rostislav Svoboda 
>  wrote:
>
>>   FAIL: tests/home-import.scm
>>   FAIL: tests/guix-home.sh
>
> I confirm the failures using Guix ce9b9e7cba.
>
>
> --8<---cut here---start->8---
> ;;; (fail (begin (use-modules (gnu home) (gnu packages) (gnu services) (guix 
> gexp) (gnu home services shells)) (home-environment (packages (map 
> specification->package (list))) (services (list (service 
> home-bash-service-type (home-bash-configuration (aliases (quote ())) (bashrc 
> (list (local-file "/tmp/guix-config/.bashrc" "bashrc") #f)
> test-name: manifest->code: Bash service
> location: /home/sitour/src/guix/wk/remove-python2/tests/home-import.scm:181
> source:
> + (test-assert
> +   "manifest->code: Bash service"
> +   (eval-test-with-home-environment
> + '((".bashrc" . "echo 'hello guix'"))
> + (make-manifest '())
> + match-home-environment-bash-service))
> actual-value: #f
> result: FAIL
> --8<---cut here---end--->8---
https://issues.guix.gnu.org/51918 may be related
>
> --8<---cut here---start->8---
> + set -e
> + guix home --version
> guix show (GNU Guix) 1.3.0.8404-ce9b9
> Copyright (C) 2021 the Guix authors
> License GPLv3+: GNU GPL version 3 or later 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> ++ guile -c '(use-modules (guix config))(display %storedir)'
> + NIX_STORE_DIR=/gnu/store
> ++ guile -c '(use-modules (guix config))(display %localstatedir)'
> + localstatedir=/var
> + GUIX_DAEMON_SOCKET=/var/guix/daemon-socket/socket
> + export NIX_STORE_DIR GUIX_DAEMON_SOCKET
> + guile -c '(use-modules (guix)) (exit (false-if-exception 
> (open-connection)))'
> ++ dirname /gnu/store
> + STORE_PARENT=/gnu
> + export STORE_PARENT
> + test /gnu = /
> ++ mktemp -d
> + test_directory=/tmp/tmp.ScA50H2Z6n
> + trap 'chmod -Rf +w "$test_directory"; rm -rf "$test_directory"' EXIT
> + cd /tmp/tmp.ScA50H2Z6n
> + HOME=/tmp/tmp.ScA50H2Z6n
> + export HOME
> + printf '# dot-bashrc test file for guix home'
> + cat
> + guix home reconfigure /tmp/tmp.ScA50H2Z6n/home.scm
> guix home: error: reference to invalid output 'out' of derivation 
> '/gnu/store/a6cwlz5yibi7w3pfm60j26inf434ard2-on-first-login.drv'
This one was fixed in e5d8302b2ce596a0518ea5bd79b338f68a3246eb.
https://issues.guix.gnu.org/51915
> + chmod -Rf +w /tmp/tmp.ScA50H2Z6n
> + rm -rf /tmp/tmp.ScA50H2Z6n
> FAIL tests/guix-home.sh (exit status: 1)
> --8<---cut here---end--->8---
>
>
> Cheers,
> simon

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

bug#51787: GC takes more than 9 hours on berlin

[zimoun]

Hi,

On Fri, 12 Nov 2021 at 12:51, Mathieu Othacehe  wrote:

> On berlin, the daily GC command is still running whereas it was started
> 9 hours ago.
>
> --8<---cut here---start->8---
> guix processes
> [...]
> SessionPID: 37231
> ClientPID: 37195
> ClientCommand: 
> /gnu/store/49vfv8l1j96bbd73ssbqanpnjz83arss-guix-1.3.0-11.014f1b6/libexec/guix/guile
>  \ /gnu/store/49vfv8l1j96bbd73ssbqanpnjz83arss-guix-1.3.0-11.014f1b6/bin/guix 
> gc -F10995116277760
> --8<---cut here---end--->8---
>
> and
>
> --8<---cut here---start->8---
> mathieu@berlin ~$ ps auxww|grep 37195
> root  37195  0.0  0.0 183260 33440 ?Sl   03:59   0:00 
> /gnu/store/49vfv8l1j96bbd73ssbqanpnjz83arss-guix-1.3.0-11.014f1b6/libexec/guix/guile
>  \ /gnu/store/49vfv8l1j96bbd73ssbqanpnjz83arss-guix-1.3.0-11.014f1b6/bin/guix 
> gc -F10995116277760
> --8<---cut here---end--->8---
>
> That's really problematic as it is blocking some other berlin services
> such as Cuirass, which has 4564 packages in its fetch queue:
>
> --8<---cut here---start->8---
> mathieu@berlin ~$ less /var/log/cuirass-remote-server.log
> [...]
> 2021-11-12T12:47:01 period update: 0 resumable, 0 failed builds.
> 2021-11-12T12:47:01 period update: 4564 items in the fetch queue.
> --8<---cut here---end--->8---

How is it possible to investigate?

Cheers,
simon

bug#44030: guix import pypi foo@1.2.3 breaks

[zimoun]

Hi Maxim,

On Sun, 21 Nov 2021 at 07:14, Maxim Cournoyer  wrote:
> zimoun  writes:

>> The syntax across the different importers are not uniform.  Especially,
>> compare:
>>
>>guix import hackage mtl@2.1.3.1
>>guix import pypi itsdangerous@1.1.0
>>
>> and worse, the option ’--recursive’ leads to an error for the latter.

Yes, this is indeed fixed.


> > Note that instead:
> >
> >guix import pypi itsdangerous/1.1.0
> >
> > perfectly works, even the option ’--recursive’.

Not this one.  Well, except if we consider it is a feature. ;-)



Cheers,
simon

bug#51848: `make && make check` fails

[zimoun]

Hi,

On dim., 14 nov. 2021 at 15:50, Rostislav Svoboda  
wrote:

>   FAIL: tests/home-import.scm
>   FAIL: tests/guix-home.sh

I confirm the failures using Guix ce9b9e7cba.


--8<---cut here---start->8---
;;; (fail (begin (use-modules (gnu home) (gnu packages) (gnu services) (guix 
gexp) (gnu home services shells)) (home-environment (packages (map 
specification->package (list))) (services (list (service home-bash-service-type 
(home-bash-configuration (aliases (quote ())) (bashrc (list (local-file 
"/tmp/guix-config/.bashrc" "bashrc") #f)
test-name: manifest->code: Bash service
location: /home/sitour/src/guix/wk/remove-python2/tests/home-import.scm:181
source:
+ (test-assert
+   "manifest->code: Bash service"
+   (eval-test-with-home-environment
+ '((".bashrc" . "echo 'hello guix'"))
+ (make-manifest '())
+ match-home-environment-bash-service))
actual-value: #f
result: FAIL
--8<---cut here---end--->8---

--8<---cut here---start->8---
+ set -e
+ guix home --version
guix show (GNU Guix) 1.3.0.8404-ce9b9
Copyright (C) 2021 the Guix authors
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
++ guile -c '(use-modules (guix config))(display %storedir)'
+ NIX_STORE_DIR=/gnu/store
++ guile -c '(use-modules (guix config))(display %localstatedir)'
+ localstatedir=/var
+ GUIX_DAEMON_SOCKET=/var/guix/daemon-socket/socket
+ export NIX_STORE_DIR GUIX_DAEMON_SOCKET
+ guile -c '(use-modules (guix)) (exit (false-if-exception (open-connection)))'
++ dirname /gnu/store
+ STORE_PARENT=/gnu
+ export STORE_PARENT
+ test /gnu = /
++ mktemp -d
+ test_directory=/tmp/tmp.ScA50H2Z6n
+ trap 'chmod -Rf +w "$test_directory"; rm -rf "$test_directory"' EXIT
+ cd /tmp/tmp.ScA50H2Z6n
+ HOME=/tmp/tmp.ScA50H2Z6n
+ export HOME
+ printf '# dot-bashrc test file for guix home'
+ cat
+ guix home reconfigure /tmp/tmp.ScA50H2Z6n/home.scm
guix home: error: reference to invalid output 'out' of derivation 
'/gnu/store/a6cwlz5yibi7w3pfm60j26inf434ard2-on-first-login.drv'
+ chmod -Rf +w /tmp/tmp.ScA50H2Z6n
+ rm -rf /tmp/tmp.ScA50H2Z6n
FAIL tests/guix-home.sh (exit status: 1)
--8<---cut here---end--->8---


Cheers,
simon