bug#69129: sbcl-mcclim broke on upgrade to sbcl@2.4.0
Christopher Howard skribis: > Hi, to reproduce, run demodemo as you have done, and then click/tap the > Stream test button. When the new window appears, start to move your graphical > cursor > over it and it will throw the error. > > I observed that this is now happening with at least several other of the > demodemo test applications, and it was happening in my private application as > well, > which I have not yet released, on multiple computers. I haven't done much > research into the exact cause of the problem, as in my mind it was more of an > excuse > to request an update to the latest release of mcclim. Hi. I tried updating mcclim to 0.9.8, but it didn't make any difference. I also tried updating some dependencies, like clx or cl-freetype2, but it still didn't make a difference. I guess some debugging is going to be necessary... signature.asc Description: PGP signature
bug#59489: bug#57292: GDM accessibility menu buttons don't do anything
Hi Liliana, Dariqq,
[...]
>> What would you think of the wrap-program solution which would avoid
>> propagating pacakges?
>>
>> I currently have something like
>>
>> #+BEGIN_SRC scheme
>> (add-after 'install 'wrap-gdm
>> (lambda* (#:key inputs outputs #:allow-other-keys)
>> (wrap-program (string-append #$output "/bin/gdm")
>> `("XDG_DATA_DIRS" ":" prefix
>> #$(map (lambda (input)
>> (file-append (this-package-input input)
>> "/share"))
>> '("at-spi2-core"
>> "dconf"
>> "gnome-control-center"))
>> #+END_SRC
>>
>> Also this way the assets (adwaita and cantarell) should be kept in
>> the gdm-configuration as when I tested this I had a white box as a
>> cursor.
> That SGTM, but we do need a more descriptive phase name. The question
> is whether we should inline the gnome-shell assets this way as well or
> not.
As Dariqq tried to inline the assets in the wrap phase and that did
*not* immediately, work, and since in theory a user could configure GDM
to use different assets, I think the art assets can stay where they
currently are, and the above patch merged to master to fix this
longstanding issue. Perhaps the phase name could be
'wrap-accessibility-dependencies'.
Dariqq, if you send an updated patch along these lines, I think we can
finally get it merged.
--
Thanks,
Maxim
bug#69138: guile-cv does not load
I am failing to load guile-cv: $ guix shell -C guile guile-cv -- guile -q GNU Guile 3.0.9 Copyright (C) 1995-2023 Free Software Foundation, Inc. Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'. This program is free software, and you are welcome to redistribute it under certain conditions; type `,show c' for details. Enter `,help' for help. scheme@(guile-user)> ,use (cv) While executing meta-command: no code for module (cv) scheme@(guile-user)> The Guix channel commit is ffc7650c11fd7c4b9f7b4894f8e0a451e0e49063 installed on a PureOS, a Debian based distribution.
bug#39885: Bioconductor tarballs are not archived
Simon Tournier writes: > Cool! > > Can we consider that this report is now done? Because: > > 1. SWH supports ExtID and nar hash lookup. > > 2. Missing origins are currently ingested by SWH. >(via specific sources.json) I think that would be jumping the gun a little bit. In some sense, the report is only *done* when “stored” hits 100% (or close to it, with the remainder being stuff we are pretty sure no longer exists). This won’t happen just because of your second point there. When the historical “sources.json” is loaded, things will be much, much, better, sure. Sources will still be missing, though. To me, this is an invitation to more subtle analysis, like weighing sources by their “importance” in the package graph. Then there’s still shortcomings with Disarchive that have to be resolved (which is work best guided by numbers in the report). Also, it will always be a good idea to verify that things are working. Ideally this could be simpler (leveraging ExtID lookup) and continuous. -- Tim
