bug#55707: bug#55488: GDM, GNOME: Can't start desktop session after upgrade

[Luis Felipe via Bug reports for GNU Guix]

Salut,

On Thursday, June 2nd, 2022 at 21:02, Ludovic Courtès  wrote:

> In the meantime, could you try the following config, which disables
> logging on tty12, to see if it boots quicker? The config changes is
> twofold; first, after the ‘use-modules’ form of your OS config, add:
> 

> [...]
> 

> Dunno if it’s silly, but at least it’ll allow us to check whether it’s
> just the framebuffer that’s slowing things down or if it’s something
> else.

It seems nothing changed. I'm still unable to start a GNOME session, and 
booting time is about the same. I recorded a new video:

https://luis-felipe.gitlab.io/media/2022/06/guix-system-ab98b51e-boot-TTY12-less.webm

publickey - luis.felipe.la@protonmail.com - 0x12DE1598.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

bug#55488: GDM, GNOME: Can't start desktop session after upgrade

[Ludovic Courtès]

Hola,

Luis Felipe  skribis:

>> Could it be https://issues.guix.gnu.org/55707? At boot time, if you
>> switch to tty12 (by pressing alt-f12) as soon as it’s available, do you
>> see messages that get printed pretty slowly, like 4–5 lines per second?
>
> Maybe? I recorded a video. Image is low quality, but speed is accurate (I 
> changed to tty12 at second 33):
>
> https://luis-felipe.gitlab.io/media/2022/06/guix-system-ab98b51e-boot-TTY12.webm

Oh yes, that’s exactly what I observed on another machine recently.
I’ll trace to investigate further when I can access it.

In the meantime, could you try the following config, which disables
logging on tty12, to see if it boots quicker?  The config changes is
twofold; first, after the ‘use-modules’ form of your OS config, add:

--8<---cut here---start->8---
(define %syslog.conf
  ;; Custom syslog.conf without /dev/tty12 logging.
  (plain-file "custom-syslog.conf"
  (let loop ((lines (string-split (plain-file-content 
%default-syslog.conf)
  #\newline))
 (result '()))
(match lines
  (()
   (string-join (reverse result) "\n"))
  ((head . tail)
   (if (string-contains head "/dev/tty12")
   (loop tail result) ;drop this line
   (loop tail (cons head result
--8<---cut here---end--->8---

Second, in the ‘services’ field of your config, replace
‘%desktop-services’ with:

--8<---cut here---start->8---
(modify-services %desktop-services
  (syslog-service-type
   _ => (syslog-configuration
 (config-file %syslog.conf
--8<---cut here---end--->8---

Dunno if it’s silly, but at least it’ll allow us to check whether it’s
just the framebuffer that’s slowing things down or if it’s something
else.

Thanks for your help!

Ludo’.

bug#54786: Installation tests are failing

[Ludovic Courtès]

Howdy!

Maxim Cournoyer  skribis:

> I tried capturing the issue in the commit message, but I'll provide
> another more hands-on view: the Jami service was broken due to changes
> in Shepherd 0.9.0 that caused the blocking sleeps + concurrent
> make+forkexec-constructor/container and fork+exec-command combination
> used to not work anymore.

OK.  Thanks for sharing the strace log; at first sight I don’t see any
clear clue, but hey, maybe it’s fine to leave that as a mystery since
there’s another solution.

[...]

>> Longer-term I think this should go in Jami proper though.  It’s great
>> that Guix has an edge over the competition :-), but having to maintain
>> it is less nice.
>
> Perhaps with the Scheme bindings introduced by Olivier for the Jami
> tests (that work via an embedded libguile), it could be possible to add
> the ability to pass an init script to 'jamid' at launch time, which
> would automate importing the account.  Proper 'Scheme' bindings would be
> nice though, and I'd like to look into the feasibility to add these via
> Swig.  Food for thought.

Sounds fun.  (BTW, I’d recommend against SWIG: it’s not “pretty”, leaves
a lot of work to do, including wrapping the generated wrappers and
debugging memory management issue.  Using the FFI provides more
flexibility and is much more fun IMO.)

>> Also, in more concrete terms: one goal of the least-authority work at
>>  is to remove
>> ‘make-forkexec-constructor/container’ and the whole (gnu build shepherd)
>> module.  Jami is one of its last remaining users (adjusting it felt like
>> beyond my abilities, precisely because it’s much more complex than the
>> other services I adjusted).
>>
>> Could you take a look at that eventually, once this patch has been
>> reviewed?
>
> I reviewed how that works, and it'd be easy; I just didn't see the
> incentive yet (there's no composition needed for the service, and it'd
> make the definition slightly less readable).  If you tell me
> mark+forkexec-constructor/container is going the way of the Dodo though,
> that's a good enough incentive :-).

Awesome.  :-)

Thanks for explaining!

Ludo’.

bug#55488: GDM, GNOME: Can't start desktop session after upgrade

[Luis Felipe via Bug reports for GNU Guix]

Hello again,

On Wednesday, June 1st, 2022 at 19:55, Ludovic Courtès  wrote:

> So it has to do with elogind taking too long to start. Same with
> polkit:

Timeouts are common here...


> --8<---cut here---start->8---
> 

> 854:May 31 12:24:10 localhost polkitd[426]: Started polkitd version 0.120
> 925:May 31 12:24:31 localhost shepherd[1]: [dbus-daemon] ** 
> (accounts-daemon:421): CRITICAL **: 12:24:28.105: error getting polkit 
> authority: Error initializing authority: Error calling StartServiceByName for 
> org.freedesktop.PolicyKit1: Timeout was reached
> --8<---cut here---end--->8---
> 

> Now, something’s wrong with those timestamps, where shepherd’s message,
> which came first, has a timestamp in the future.

Ooh...

> Could it be https://issues.guix.gnu.org/55707? At boot time, if you
> switch to tty12 (by pressing alt-f12) as soon as it’s available, do you
> see messages that get printed pretty slowly, like 4–5 lines per second?

Maybe? I recorded a video. Image is low quality, but speed is accurate (I 
changed to tty12 at second 33):

https://luis-felipe.gitlab.io/media/2022/06/guix-system-ab98b51e-boot-TTY12.webm

At 01:57, it takes a while to start GDM session (that's common; always been 
like that, I think).


> Sorry for not having clearer ideas, but maybe we have a lead…

No worries, thanks again for taking a look at it.

publickey - luis.felipe.la@protonmail.com - 0x12DE1598.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

bug#54786: Installation tests are failing

[Maxim Cournoyer]

Hi Ludovic,

Ludovic Courtès  writes:

> Hi Maxim,
>
> Maxim Cournoyer  skribis:
>
>> Ludovic Courtès  writes:
>
> [...]
>
>>> Before going further, I’d like to understand: this does more than just
>>> fix the Jami system tests, right?
>>>
>>> It would have been nice to have surgical changes to “just” fix the
>>> tests, along the lines of ,
>>> possibly followed by a rework of the whole machinery, if that’s
>>> possible.
>>
>> It's not really possible unfortunately, because the rework from talking
>> to the D-Bus API via the 'dbus-send' binary to using Guile AC/D-bus was
>> needed or at least simplified fixing the issues.
>
> So am I right that the “issues” were not specifically related to the
> Shepherd 0.9.0 switch, or at least not just to that?  (Just to make sure
> I understand the context.)

I tried capturing the issue in the commit message, but I'll provide
another more hands-on view: the Jami service was broken due to changes
in Shepherd 0.9.0 that caused the blocking sleeps + concurrent
make+forkexec-constructor/container and fork+exec-command combination
used to not work anymore.

This problem can be manually observed by spawning a VM with the Jami
service:

$(guix system vm --no-graphic -e '(@@ (gnu tests telephony) %jami-os)') -m 512

Then you'll see the service doesn't even start:

--8<---cut here---start->8---
root@jami ~# herd status
[...]
Stopped:
 - jami
[...]

root@jami ~# pgrep jamid
192

root@jami ~# killall jamid

root@jami ~# herd start jami
Jami Daemon 11.0.0, by Savoir-faire Linux 2004-2019
https://jami.net/
[Video support enabled]
[Plugins support enabled]

12:53:47.144 os_core_unix.c !pjlib 2.11 for POSIX initialized

herd: exception caught while executing 'start' on service 'jami':
Throw to key `match-error' with args `("match" "no matching pattern" #f)'.
--8<---cut here---end--->8---

I've ran this: herd start jami& strace -p1 -f -s800 -o strace.out

Attached is the last 10% of the gzip'd file.  I couldn't explain this
failure very clearly, but when I tried investigating it was failing on
the '(dbus-service-available? "cx.ring.Ring")' call, if I recall
correctly.



strace.out.gz
Description: shepherd pid1 strace

[...]

>>> What do you think is missing upstream so that starting Jami is
>>> simpler?
>>
>> 1) Lack of D-Bus support in Shepherd to easily start D-Bus services.
>> The upstream systemd service definition for the Jami daemon (jamid) is
>> this:
>>
>> # net.jami.daemon.service
>> [D-BUS Service]
>> Name=cx.ring.Ring
>> Exec=@LIBDIR@/jamid
>>
>> But that's nearly not where the complexity of our jami-service-type
>> lies.
>
> But that should be fine: we have dozens of D-Bus services that happily
> get started by dbus-daemon.

I guess that works (minus races like we've had with elogind) if the
other services are also D-Bus services sharing the same bus.  But here
the code talking with Jami are in the Shepherd service actions and more
critically in the start slot itself -- so it's important the D-Bus
service has been acquired and ready to service D-Bus calls otherwise
they'd fail (that's what the loop polling for (jami-service-available?)
ensures).

>> Rather, it's in the following:
>>
>> 2) The lack of a way to declaratively configure Jami and the need to use
>> D-Bus API to issue commands to Jami non-interactively.  For example, to
>> have Jami import an account it's necessary to go via either
>>
>> a) the GUI or
>> b) the D-Bus API
>>
>> The Jami service in Guix makes use of b), which introduces the need for
>> some Scheme bindings wrapping the low-level D-Bus interface.  Perhaps
>> such bindings could live in Jami itself.
>>
>> The second point (2) could be addressed upstream, but since it's a
>> rather niche use case (the common use case is simply running the client
>> GUI), is already achievable via D-Bus, and would probably require a
>> considerable amount of work in Jami itself, I think we can keep it as is
>> for now, as a Guix System exclusive feature ;-).  Note that even if Jami
>> could be configured via configuration files, we'd still want to be able
>> to communicate with it via D-Bus to maintain the possible actions
>> currently available in our Shepherd service (listing/enabling/disable
>> accounts, etc.), so it'd only really help to reduce the start slot, and
>> that's it.  We'd still need most of the D-Bus bindings, so it wouldn't
>> help that much anyway.
>
> Ah I see.
>
>> I hope that clarifies how our jami-service-type is both complex but also
>> unique.
>
> Sure, the ability to configure Jami in a declarative and stateless
> fashion is a plus, that’s really cool.
>
> Longer-term I think this should go in Jami proper though.  It’s great
> that Guix has an edge over the competition :-), but having to maintain
> it is less nice.

Perhaps with the Scheme bindings introduced by Olivier for the Jami
tests (that work via an embedded libguile), 

bug#55765: [mumi] Xapian SWIGy issue

[Ludovic Courtès]

Hello,

Arun Isaac  skribis:

> That doesn't immediately ring a bell, but I could investigate. Do you
> have any way to reproduce this issue?

Of course not, it’d be too easy.  :-)

> Also, which version of mumi and guile-xapian is this?

It’s this one:

--8<---cut here---start->8---
ludo@berlin ~$ guix gc --references 
/gnu/store/dx753xnrzx2fsscryv9lc647nc5w637v-mumi-0.0.1-7.f5232c4/
/gnu/store/09b6hpmpnipvp3yxxvbnz40xzpig7ypz-guile-syntax-highlight-0.1
/gnu/store/3fa1s3ckzca1c9bqr7ylrhg7r7lb8rfw-guile-kolam-0.1.0
/gnu/store/4y5m9lb8k3qkb1y9m02sw9w9a6hacd16-bash-minimal-5.1.8
/gnu/store/60jl4xry9c93j9l0rr7nkvbw7dihjz4k-guile-gcrypt-0.3.0
/gnu/store/8403wphsahjviq4p4ryqfb7sindgg3nq-guile-irregex-0.9.6
/gnu/store/9l5rjl30b5p9qig9nj2xs9wwsp54ypkd-guile-webutils-0.1-0.8541904
/gnu/store/cnfsv9ywaacyafkqdqsv2ry8f01yr7a9-guile-3.0.7
/gnu/store/d5mcny1w7l8s7jv94ys2arg2qa39y8ha-guile-redis-2.2.0
/gnu/store/dx753xnrzx2fsscryv9lc647nc5w637v-mumi-0.0.1-7.f5232c4
/gnu/store/grjvqx3xfjlczak7j3gsdf0q4wf7fnw6-guile-json-4.5.2
/gnu/store/is9f6ki7i2f6qk80ivvz7q1vvlibb96l-guile-fibers-1.0.0
/gnu/store/xnp2h5zp9k05vd9r0j24a07175llsc33-guile-xapian-0.1.0
/gnu/store/xqb5spzkaxc5ayfv5xcw6gqyfh9dn3xl-mailutils-3.15
/gnu/store/z8wwwpnh1i97fm27xqqq5d4aaf5v8a5q-guile-email-latest-0.2.2-2.ea60bb9
ludo@berlin ~$ guix system describe
Generation 577  May 26 2022 16:49:25(current)
  file name: /var/guix/profiles/system-577-link
  canonical file name: /gnu/store/2bfdwvc6iyaj7m58szhxnd56p41s6q68-system
  label: GNU with Linux-Libre 5.17.9
  bootloader: grub
  root device: label: "my-root"
  kernel: /gnu/store/si7fz3pxwq5aiqpdwkw0qs4jmsqh89n5-linux-libre-5.17.9/bzImage
  channels:
guix:
  repository URL: https://git.savannah.gnu.org/git/guix.git
  branch: master
  commit: 0dc63ce519c5f98b2186d1871176e2fac3a6926b
  configuration file: 
/gnu/store/sd59z8h741jilaa3cdf16441f84xghil-configuration.scm
--8<---cut here---end--->8---

Thanks!

Ludo’.

bug#55552: frama-c should probably be wrapped

[raingloom]

On Thu, 2 Jun 2022 07:57:19 +0200
Julien Lepiller  wrote:

> Le Fri, 20 May 2022 13:36:54 +0200,
> raingloom  a écrit :
> 
> > Sorry, can't debug this further right now.
> > 
> > ```
> > $(guix build frama-c)/bin/frama-c
> > [kernel] User Error: [findlib] package 'ocamlgraph' not found
> > (required by `frama-c.kernel') [kernel] User Error: Deferred error
> > message was emitted during execution. See above messages for more
> > information. [kernel] Frama-C aborted: invalid user input. ```
> > 
> > Running it with `guix shell frama-c -- frama-c` just makes it exit
> > without any output.
> > 
> > 
> >   
> 
> Hi, I think it's a duplicate of https://issues.guix.gnu.org/54094 ?
> I think it's just a matter of defining OCAMLPATH. Do you think you
> could come up with a patch?

Oh, I totally forgot about that. Well, I'll try to write something, but
it'll probably have to wait until my exams are over.

bug#55765: [mumi] Xapian SWIGy issue

[Arun Isaac]

Hi Ludo,

> --8<---cut here---start->8---
> 2022-06-02 15:04:45 GET /issue/54065/raw/12
> 2022-06-02 15:04:45 GET /issue/43096/raw/2
> 2022-06-02 15:04:45 GET /issue/45676/raw/10
> 2022-06-02 15:09:09 GET In procedure delete-Database: Wrong type argument in 
> position 1: #
> 2022-06-02 15:09:21 In procedure delete-Database: Wrong type argument in 
> position 1: #
> --8<---cut here---end--->8---
>
> Does that ring a bell, Arun?

That doesn't immediately ring a bell, but I could investigate. Do you
have any way to reproduce this issue? Also, which version of mumi and
guile-xapian is this?

Thanks!
Arun

bug#55765: [mumi] Xapian SWIGy issue

[Ludovic Courtès]

Hello!

Earlier today, I caught mumi in the middle of what I think we can call:
a bug.  Specifically, a Xapian or SWIG bug.

--8<---cut here---start->8---
2022-06-02 15:04:45 GET /issue/54065/raw/12
2022-06-02 15:04:45 GET /issue/43096/raw/2
2022-06-02 15:04:45 GET /issue/45676/raw/10
2022-06-02 15:09:09 GET In procedure delete-Database: Wrong type argument in 
position 1: #
2022-06-02 15:09:21 In procedure delete-Database: Wrong type argument in 
position 1: #
--8<---cut here---end--->8---

Does that ring a bell, Arun?

Ludo’.

bug#55723: Full disk encryption with grub-efi and LUKS2

[Giovanni Biscuolo]

Hello Josselin and Lars-Dominik

Josselin Poiret via Bug reports for GNU Guix  writes:

[...]

>> Supposedly there are also patches for grub-mkimage, but maybe we can
>> include a workaround like the above by default until then or remove the
>> section about LUKS2 entirely?
>
> Thank you for posting this bug and sorry for taking so long with this.
> I'd suggest that we instead add a warning that `/boot/` must be
> unencrypted for LUKS2+GRUB to work for now, possibly pointing to this
> bug.

As Josselin wrote in the proposed patch, actually /boot/ on LUKS1 is
working well

In case it is helpful, it's possible to "Downgrade" a LUKS2 volume to
LUKS1, I found this guide useful:
https://cryptsetup-team.pages.debian.net/cryptsetup/encrypted-boot.html

[...]

> to include.  My approach at [1] is to ask device-mapper directly, but
> there are also other patches trying various other methods, and the
> consensus now seems to be that each patch does one thing well and that
> we should combine all of the good parts.

Thank you very much for the update and the work on GRUB!

Please is there any upstream (GRUB) bug report we can point to in this
one so we can follow the situation and know when upsstream will release
the patch?

[...]

Happy hacking! Gio'

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature

bug#55709: R texinfo documents are not showing up for me

[Ludovic Courtès]

Hi,

Kyle Andrews  skribis:

> For me it gave:
>
> 0   
> /gnu/store/vncwfb53kbnyflyc1jyd2xv9sifpw202-gtk+-3.24.30/lib/libgdk-3.so.0
>
> Does this mean I have some store corruption as Maxime suggested?

Yes, that sounds likely.

Ludo’.

bug#53225: shepherd freezes if wireguard is started with dns config enabled

[Ludovic Courtès]

Hi Nathan,

Nathan Dehnel  skribis:

> Just tested and Shepherd 0.9 does not fix this issue.

Could you be more specific?  Specifically, could you share
/var/log/messages for the parts related to Wireguard?

> On Mon, Jan 17, 2022 at 7:48 AM Ludovic Courtès  wrote:

[...]

>> One command sent to shepherd by ‘herd …’ must have completed before the
>> next one is processed.
>>
>> You can experience it like this:
>>
>>   sudo herd eval root '(sleep 3)' & echo status && sudo herd status
>>
>> Here the first ‘herd’ command has shepherd block for 3 seconds, so the
>> second ‘herd’ command won’t print anything until 3 seconds have passed.

This is actually still the case with 0.9, because here we’re calling
(@ (guile) sleep), which blocks.  So… not a good example.

The short story is: it is still possible to write code that blocks
shepherd, as with the ‘sleep’ example above.  However, the standard
service constructors/destructors no longer block, and shepherd can serve
multiple clients concurrently.

Ludo’.

bug#54786: Installation tests are failing

[Ludovic Courtès]

Hi Maxim,

Maxim Cournoyer  skribis:

> Ludovic Courtès  writes:

[...]

>> Before going further, I’d like to understand: this does more than just
>> fix the Jami system tests, right?
>>
>> It would have been nice to have surgical changes to “just” fix the
>> tests, along the lines of ,
>> possibly followed by a rework of the whole machinery, if that’s
>> possible.
>
> It's not really possible unfortunately, because the rework from talking
> to the D-Bus API via the 'dbus-send' binary to using Guile AC/D-bus was
> needed or at least simplified fixing the issues.

So am I right that the “issues” were not specifically related to the
Shepherd 0.9.0 switch, or at least not just to that?  (Just to make sure
I understand the context.)

>> Besides, I think we should talk to Jami upstream (which shouldn’t be too
>> hard :-)).  It doesn’t seem reasonable to me to have 800+ lines of code
>> in the distro to start one service.  Usually the ‘start’ and ‘stop’
>> methods are between 2 and 10 lines of code.
>>
>> What do you think is missing upstream so that starting Jami is
>> simpler?
>
> 1) Lack of D-Bus support in Shepherd to easily start D-Bus services.
> The upstream systemd service definition for the Jami daemon (jamid) is
> this:
>
> # net.jami.daemon.service
> [D-BUS Service]
> Name=cx.ring.Ring
> Exec=@LIBDIR@/jamid
>
> But that's nearly not where the complexity of our jami-service-type
> lies.

But that should be fine: we have dozens of D-Bus services that happily
get started by dbus-daemon.

> Rather, it's in the following:
>
> 2) The lack of a way to declaratively configure Jami and the need to use
> D-Bus API to issue commands to Jami non-interactively.  For example, to
> have Jami import an account it's necessary to go via either
>
> a) the GUI or
> b) the D-Bus API
>
> The Jami service in Guix makes use of b), which introduces the need for
> some Scheme bindings wrapping the low-level D-Bus interface.  Perhaps
> such bindings could live in Jami itself.
>
> The second point (2) could be addressed upstream, but since it's a
> rather niche use case (the common use case is simply running the client
> GUI), is already achievable via D-Bus, and would probably require a
> considerable amount of work in Jami itself, I think we can keep it as is
> for now, as a Guix System exclusive feature ;-).  Note that even if Jami
> could be configured via configuration files, we'd still want to be able
> to communicate with it via D-Bus to maintain the possible actions
> currently available in our Shepherd service (listing/enabling/disable
> accounts, etc.), so it'd only really help to reduce the start slot, and
> that's it.  We'd still need most of the D-Bus bindings, so it wouldn't
> help that much anyway.

Ah I see.

> I hope that clarifies how our jami-service-type is both complex but also
> unique.

Sure, the ability to configure Jami in a declarative and stateless
fashion is a plus, that’s really cool.

Longer-term I think this should go in Jami proper though.  It’s great
that Guix has an edge over the competition :-), but having to maintain
it is less nice.

Also, in more concrete terms: one goal of the least-authority work at
 is to remove
‘make-forkexec-constructor/container’ and the whole (gnu build shepherd)
module.  Jami is one of its last remaining users (adjusting it felt like
beyond my abilities, precisely because it’s much more complex than the
other services I adjusted).

Could you take a look at that eventually, once this patch has been
reviewed?

Thanks,
Ludo’.

bug#54760: import: hackage: Internal libraries are not filtered out of dependency list

[Philip Munksgaard]

Hi again,

On Thu, 2 Jun 2022, at 13:57, Lars-Dominik Braun wrote:
> Hey,
>
>> Indeed, that seems to work for those packages, but it still doesn't seem to 
>> work for OneTuple, as mentioned here:
> I’m attaching a patch for that, please have a look. I’ll merge these
> into master, since they don’t change any builds.

That works, thanks!

>> Aha! The upgrade to GHC 9.0.0 caused ghc-hashable to break. I suppose many 
>> other packages could be broken as well.
> I didn’t actually upgrade any packages on wip-haskell yet, so it’s
> likely they fail with a newer GHC than 8.10.

Aha. Let me know if there's anything I can do to help.

bug#54760: import: hackage: Internal libraries are not filtered out of dependency list

[Lars-Dominik Braun]

Hey,

> Indeed, that seems to work for those packages, but it still doesn't seem to 
> work for OneTuple, as mentioned here:
I’m attaching a patch for that, please have a look. I’ll merge these
into master, since they don’t change any builds.

> Aha! The upgrade to GHC 9.0.0 caused ghc-hashable to break. I suppose many 
> other packages could be broken as well.
I didn’t actually upgrade any packages on wip-haskell yet, so it’s
likely they fail with a newer GHC than 8.10.

Cheers,
Lars

>From 261736187d51c85c203ad08fbc1ae89340256a8c Mon Sep 17 00:00:00 2001
From: Lars-Dominik Braun 
Date: Thu, 2 Jun 2022 13:52:08 +0200
Subject: [PATCH] import: hackage: Filter upper/mixed case dependencies too.

* guix/import/hackage.scm (filter-dependencies): Convert OWN-NAMES
to lowercase before filtering.
(hackage-module->sexp): Remove #f from OWN-NAMES, which is used for
unnamed (default) libraries.
* tests/hackage.scm (test-cabal-internal-library-ignored): Add mismatched
uppercase letters.
---
 guix/import/hackage.scm | 8 +---
 tests/hackage.scm   | 7 ---
 2 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/guix/import/hackage.scm b/guix/import/hackage.scm
index 6e982366cf..878a7d2f9c 100644
--- a/guix/import/hackage.scm
+++ b/guix/import/hackage.scm
@@ -227,9 +227,10 @@ (define (filter-dependencies dependencies own-names)
 list with the names of dependencies.  OWN-NAMES is the name of the Cabal
 package being processed and its internal libaries and is used to filter
 references to itself."
-  (filter (lambda (d) (not (member (string-downcase d)
+  (let ((ignored-dependencies (map string-downcase
(append own-names ghc-standard-libraries
-  dependencies))
+(filter (lambda (d) (not (member (string-downcase d) 
ignored-dependencies)))
+dependencies)))
 
 (define* (hackage-module->sexp cabal cabal-hash
#:key (include-test-dependencies? #t))
@@ -250,7 +251,8 @@ (define source-url
 (hackage-source-url name version))
 
   (define own-names (cons (cabal-package-name cabal)
-  (map cabal-library-name (cabal-package-library 
cabal
+  (filter (lambda (x) (not (eqv? x #f)))
+(map cabal-library-name (cabal-package-library 
cabal)
 
   (define hackage-dependencies
 (filter-dependencies (cabal-dependencies->names cabal) own-names))
diff --git a/tests/hackage.scm b/tests/hackage.scm
index a11dd14846..ad2ee4b7f9 100644
--- a/tests/hackage.scm
+++ b/tests/hackage.scm
@@ -368,7 +368,8 @@ (define test-cabal-no-final-newline
 (test-assert "hackage->guix-package test without final newline"
   (eval-test-with-cabal test-cabal-no-final-newline match-ghc-foo))
 
-;; Make sure internal libraries will not be part of the dependencies.
+;; Make sure internal libraries will not be part of the dependencies,
+;; ignore case.
 (define test-cabal-internal-library-ignored
   "name: foo
 version: 1.0.0
@@ -379,8 +380,8 @@ (define test-cabal-internal-library-ignored
 executable cabal
   build-depends:
 HTTP   >= 4000.2.5 && < 4000.3,
-internal
-library internal
+internAl
+library internaL
   build-depends: mtl>= 2.0  && < 3
 ")
 
-- 
2.35.1

bug#54760: import: hackage: Internal libraries are not filtered out of dependency list

[Philip Munksgaard]

On Thu, 2 Jun 2022, at 11:59, Philip Munksgaard wrote:
> On Thu, 2 Jun 2022, at 11:53, Philip Munksgaard wrote:
>> Also, attoparsec still won't build with result of the import, but for 
>> different reasons.
>
> Actually, that's weird. Didn't attoparsec used to build?

Aha! The upgrade to GHC 9.0.0 caused ghc-hashable to break. I suppose many 
other packages could be broken as well.

bug#54760: import: hackage: Internal libraries are not filtered out of dependency list

[Philip Munksgaard]

On Thu, 2 Jun 2022, at 11:53, Philip Munksgaard wrote:
> Also, attoparsec still won't build with result of the import, but for 
> different reasons.

Actually, that's weird. Didn't attoparsec used to build?

bug#54752: import: hackage: `elif` conditionals not supported

[Philip Munksgaard]

On Sun, 22 May 2022, at 11:55, Lars-Dominik Braun wrote:
> Hi Philip,
>
> thank you!
>
>> Unfortunately, building raaz still fails (first because of the description, 
>> then because some internal libraries are added as external dependencies, and 
>> then for... other reasons I haven't figured out. But all of those are 
>> separate issues.
>
> You’re right, it fails with this error for me, which indicates 
> haskell-build-system has a bug _somewhere_.
>

Yes, I don't think that should hold back these patches from going into 
wip-haskell.

bug#54760: import: hackage: Internal libraries are not filtered out of dependency list

[Philip Munksgaard]

Hi Lars,

On Sun, 22 May 2022, at 11:37, Lars-Dominik Braun wrote:
>> The attoparsec package on hackage defines multiple internal libraries inside 
>> one package, named "attoparsec" and "attoparsec-internal", with the first 
>> depending on the latter. Importing attoparsec using `guix import hackage 
>> attoparsec` therefore yields the following erroneous package definition: […]
>
> attached patches should fix this. I tried them with both, attoparsec and
> raaz, and internal libraries appear neither in inputs nor native inputs
> any more.
>

Indeed, that seems to work for those packages, but it still doesn't seem to 
work for OneTuple, as mentioned here: https://issues.guix.gnu.org/52152#3

Also, attoparsec still won't build with result of the import, but for different 
reasons.

bug#55709: R texinfo documents are not showing up for me

[Liliana Marie Prikler]

Am Dienstag, dem 31.05.2022 um 10:37 +0200 schrieb Maxime Devos:
> (Is there a method to verify and repair a _single_ store item instead
> of the whole store?).
I think the syntax for that'd be ‘[sudo] guix build --repair
STORE_ITEM’.

Cheers