bug#53064: Already fixed

[Liliana Marie Prikler]

Am Donnerstag, dem 06.01.2022 um 21:01 -0500 schrieb Stephen Paul
Weber:
> A push to master right after I filed this has fixed it already.
Debbugs allows you to mark your own bugs as done, you don't need to
wait for a committer or someone to acknowledge that.  Simply add "-
done" to the bug number, as I did for this message.

bug#53043: Dash To Dock 71 not working properly with Gnome Shell 41

[raid5atemyhomework via Bug reports for GNU Guix]

Hello,

> Hi,
>
> Am Freitag, dem 07.01.2022 um 03:56 + schrieb raid5atemyhomework:
>
> > Hello Liliana,
> > [...]
> > It may be a related bug, but this may also be unique to how Guix
> > packages both programs. So I want to know if other users on Guix are
> > seeing the same thing as well.
>
> We don't do rigorous integration tests for GNOME Shell extensions and
> to my knowledge you are the first one to report that bug.

It's probably because "Use built-in theme" is default-enabled and this bug 
seems to appear with this setting disabled.  Disabling the setting lets me set 
up some more settings for the dock which is why I prefer this setting disabled.

> > Given the default `(service gnome-desktop-service-type)`, where does
> > `gnome-shell` put its logs?
> > There are no logs for Gnome Shell specifically on `/var/log`, it does
> > not print anything in `/var/log/Xorg.0.log`, and `info guix` does not
> > describe any log output directory for `gnome-desktop-configuration`,
> > so I don't know where Gnome Shell on Guix puts its logs.  Does it
> > just get printed to console?
>
> There's your ~/.local/share/xorg logs that you haven't mentioned yet,
> but I doubt something like an extension misbehaving (i.e. not even
> raising an error that GNOME Shell detects) would end up there. I'm not
> aware of any other GNOME-specific logs and their locations, but since
> it's either /var/log or somewhere in your $HOME/.something, I don't
> think Guix would do anything to manipulate the output path. You could
> try checking for logs in GDM's home as well, which requires sudo to ls.


The github issue you linked to asks for logs as well, so presumably they print 
*something* on the logs that might help them.

Nothing in my normal user `~/.local/share/` has xorg in it, and `root` has no 
`~root/.local`.  My user has `~/.local/share/gnome-shell` but it has no logs 
either.  I also looked into `~/.cache` and `~/.local` for both my user and 
`root` -- no dice.

I don't use GDM since it keeps wanting to suspend the computer, and the 
computer is intended to be a fileserver and printserver, the Gnome Shell is 
just there for ease-of-use since the printer is a scanner/printer and you can't 
really remotely use the scanner usefully since you have to feed the papers to 
scan into it one by one anyway.

Looking at my console, flipping the "Use built-in theme" shows a bunch of error 
messages on the console.  Sigh.  Looks like `gnome-shell` on Guix prints its 
logs to console, which makes it a headache to copy-paste messages off for bug 
reports.

Re:

> but I doubt something like an extension misbehaving (i.e. not even
> raising an error that GNOME Shell detects) would end up there.

It's JavaScript.  If you have a browser and open its console while browsing 
most websites, you'll see a fair number of error messages there, even though 
the site may be operating perfectly well as far as you can tell --- errors 
don't cause a typical JavaScript application to crash because an error will 
just send it back to the event mainloop and it will keep on going on despite 
bunches of JavaScript errors.  That's why logs for `gnome-shell` are fairly 
vital, and it's getting thrown into the console where they are not recorded.  
Sigh.  More coding to do to make Guix useful.

Thanks
raid5atemyhomework

bug#53061: tremc: unable to view torrent's details

[Leo Famulari]

On Thu, Jan 06, 2022 at 09:36:03PM +, Disseminate Dissent via Bug reports 
for GNU Guix wrote:
> Pressing Enter should open up the torrent's details which grants more 
> functionality, instead it crashes back to the terminal.

Thanks for the report! This should be fixed with commit
b4263f12edd11ddc49c509116df11de6ae839ad2:

https://git.savannah.gnu.org/cgit/guix.git/commit/?id=b4263f12edd11ddc49c509116df11de6ae839ad2

bug#53043: Dash To Dock 71 not working properly with Gnome Shell 41

[Liliana Marie Prikler]

Hi,

Am Freitag, dem 07.01.2022 um 03:56 + schrieb raid5atemyhomework:
> Hello Liliana,
> 
> [...]
> 
> 
> It may be a *related* bug, but this may also be unique to how Guix
> packages both programs.  So I want to know if other users on Guix are
> seeing the same thing as well.
We don't do rigorous integration tests for GNOME Shell extensions and
to my knowledge you are the first one to report that bug.

> Given the default `(service gnome-desktop-service-type)`, where does
> `gnome-shell` put its logs?
> There are no logs for Gnome Shell specifically on `/var/log`, it does
> not print anything in `/var/log/Xorg.0.log`, and `info guix` does not
> describe any log output directory for `gnome-desktop-configuration`,
> so I don't know where Gnome Shell on Guix puts its logs.  Does it
> just get printed to console?
There's your ~/.local/share/xorg logs that you haven't mentioned yet,
but I doubt something like an extension misbehaving (i.e. not even
raising an error that GNOME Shell detects) would end up there.  I'm not
aware of any other GNOME-specific logs and their locations, but since
it's either /var/log or somewhere in your $HOME/.something, I don't
think Guix would do anything to manipulate the output path.  You could
try checking for logs in GDM's home as well, which requires sudo to ls.

Cheers

bug#52908: 'tests/guix-system.sh' fails on aarch64-linux

[Chris Marusich]

Hi Ludo and Aiko,

Ludovic Courtès  writes:

> I’d rather not move things and fix the bug in the same commit.  (I’m not
> even convinced sddm needs to leave its own module, plus it would break
> the API, which is not something to do lightly.)

You're right!  I was able to avoid moving the (gnu services sddm) module
by autoloading it from (gnu services xorg).  I've committed the fix as
79260c8695cc5e3cd64f5b01e262369d5a67f141, along with two commits that
update the guix package.

> Thanks for fixing it!
>
> And yes, we’ll need to update the ‘guix’ package once this fix is in.

Thank you for the review!

Aiko, can you confirm that after running "guix pull" the issue is
resolved on your end, too?

-- 
Chris

PGP: https://savannah.gnu.org/people/viewgpg.php?user_id=106836
From 79260c8695cc5e3cd64f5b01e262369d5a67f141 Mon Sep 17 00:00:00 2001
From: Chris Marusich 
Date: Thu, 6 Jan 2022 18:43:47 -0800
Subject: [PATCH] services: Consistently use SDDM rather than GDM on
 non-x86_64.

This is a follow-up to 49599fab564f203b8e92d32e9b28c99e99849bfb.

Fixes: .

* gnu/services/xorg.scm (set-xorg-configuration)[login-manager-service-type]:
When the current system or target system begins with the string "x86_64", use
gdm-service-type as before; otherwise, use sddm-service-type.
* gnu/system/examples/vm-image.tmpl (services): Add sddm-service-type to the
list of service types to remove.
---
 gnu/services/xorg.scm | 11 ++-
 gnu/system/examples/vm-image.tmpl |  6 +++---
 2 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/gnu/services/xorg.scm b/gnu/services/xorg.scm
index 82a7d25602..35f8dbc5f8 100644
--- a/gnu/services/xorg.scm
+++ b/gnu/services/xorg.scm
@@ -11,6 +11,7 @@
 ;;; Copyright © 2021 Brice Waegeneire 
 ;;; Copyright © 2021 Oleg Pykhalov 
 ;;; Copyright © 2021 Josselin Poiret 
+;;; Copyright © 2022 Chris Marusich 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -28,6 +29,7 @@
 ;;; along with GNU Guix.  If not, see .
 
 (define-module (gnu services xorg)
+  #:autoload   (gnu services sddm) (sddm-service-type)
   #:use-module (gnu artwork)
   #:use-module (gnu services)
   #:use-module (gnu services shepherd)
@@ -1040,10 +1042,17 @@ the GNOME desktop environment.")
"Run the GNOME Desktop Manager (GDM), a program that allows
 you to log in in a graphical session, whether or not you use GNOME."
 
+;; Since GDM depends on Rust (gdm -> gnome-shell -> gjs -> mozjs -> rust)
+;; and Rust is currently unavailable on non-x86_64 platforms, default to
+;; SDDM there (FIXME).
 (define* (set-xorg-configuration config
  #:optional
  (login-manager-service-type
-  gdm-service-type))
+  (let ((system (or (%current-target-system)
+(%current-system
+(if (string-prefix? "x86_64" system)
+gdm-service-type
+sddm-service-type
   "Tell the log-in manager (of type @var{login-manager-service-type}) to use
 @var{config}, an  record."
   (simple-service 'set-xorg-configuration
diff --git a/gnu/system/examples/vm-image.tmpl b/gnu/system/examples/vm-image.tmpl
index a59d91587b..ccb0b045db 100644
--- a/gnu/system/examples/vm-image.tmpl
+++ b/gnu/system/examples/vm-image.tmpl
@@ -5,7 +5,7 @@
 ;;
 
 (use-modules (gnu) (guix) (srfi srfi-1))
-(use-service-modules desktop mcron networking spice ssh xorg)
+(use-service-modules desktop mcron networking spice ssh xorg sddm)
 (use-package-modules bootloaders certs fonts nvi
  package-management wget xorg)
 
@@ -107,12 +107,12 @@ root ALL=(ALL) ALL
  ;; Use the DHCP client service rather than NetworkManager.
  (service dhcp-client-service-type))
 
-   ;; Remove GDM, ModemManager, NetworkManager, and wpa-supplicant,
-   ;; which don't make sense in a VM.
+   ;; Remove some services that don't make sense in a VM.
(remove (lambda (service)
  (let ((type (service-kind service)))
(or (memq type
  (list gdm-service-type
+   sddm-service-type
wpa-supplicant-service-type
cups-pk-helper-service-type
network-manager-service-type

base-commit: c4240dfdb433239108edaf12acb5c51138f9dc74
-- 
2.30.2



signature.asc
Description: PGP signature

bug#53043: Dash To Dock 71 not working properly with Gnome Shell 41

[raid5atemyhomework via Bug reports for GNU Guix]

Hello Liliana,


> Hi,
>
> Am Donnerstag, dem 06.01.2022 um 04:35 + schrieb
> raid5atemyhomework:
>
> > I recently upgraded, and on reboot found that the Gnome Shell extension
> > Dash to Dock was no longer working properly.
> > Instead of displaying my favorite applications on the bottom dock, it
> > only displays the "applications" icon.  Running applications are also
> > not displayed.
> > I found a solution:
> >
> > -   In the Gnome activities search bar, look for "Extensions" and run it.
> > -   Select the gear icon / settings for Dash to Dock.
> > -   Select tab "Appearance".
> > -   Enable "Use built-in theme".
> >
> > It seems the details of the theming engine were changed in recent Gnome
> > and you now have no choice but "Use built-in theme".
>
> I'm not sure how this is a bug in Guix. Dash-to-dock 71 is the latest
> release from upstream taking extensions.gnome.org as the source of
> truth [1]. There appears to be a related issue upstream [2], perhaps
> you're encountering that?


The solution found there (disable Ubuntu Dock) does not work for me --- there 
is no Ubuntu Dock in Guix, LOL.

It may be a *related* bug, but this may also be unique to how Guix packages 
both programs.
So I want to know if other users on Guix are seeing the same thing as well.
Guix version is e675030fba924a1aef2677f8ab912eaa3c46403c.

Given the default `(service gnome-desktop-service-type)`, where does 
`gnome-shell` put its logs?
There are no logs for Gnome Shell specifically on `/var/log`, it does not print 
anything in `/var/log/Xorg.0.log`, and `info guix` does not describe any log 
output directory for `gnome-desktop-configuration`, so I don't know where Gnome 
Shell on Guix puts its logs.  Does it just get printed to console?

Thanks
raid5atemyhomework

bug#53064: Already fixed

[Stephen Paul Weber]

A push to master right after I filed this has fixed it already.


signature.asc
Description: PGP signature

bug#53064: pioneer FTBFS

[Stephen Paul Weber]

Hello,

Today I tried to `guix install pioneer` and it seems there is no substitute.  It
very quickly fails to build from source with this error in log:

-- Checking for module 'sigc++-2.0'
--   No package 'sigc++-2.0' found
CMake Error at 
/gnu/store/aain9m7r37jlzd21kvgvrkhc2pm7mk1w-cmake-minimal-3.21.3/share/cmake-3.21/Modules/FindPkgConfig.cmake:562
 (message):
  A required package was not found


signature.asc
Description: PGP signature

bug#34170: bitcoin-core bundles leveldb

[Carl Dong]

> If desired, it would also be possible to do something in-between
> unbundling and using bitcoin's leveldb: define a 'leveldb/bitcoin'
> variant of the 'leveldb' package (using package/inherit or (package
> (inherit ...) ...)), add it as input to the 'bitcoin' package and tell
> and/or patch bitcoin's buid scripts to use that leveldb.
Yes I think that would be a splendid idea! With regards to patching bitcoin’s 
builds scripts, Bitcoin Knots follows Bitcoin Core closely, but has a bunch of 
patches which allow for using system libs, so that might be good to reference: 
https://github.com/bitcoin/bitcoin/compare/master...bitcoinknots:21.x-syslibs 


> As source code, use an appropriate commit from
>  (and add a comment
> to the definition of bitcoin-core to keep leveldb/bitcoin in-sync).

FYI, according to https://github.com/bitcoin/bitcoin/pull/17398 
, we are currently using the 
upstream LevelDB commit 0c40829872a9f00f38e11dc370ff8adb3e19f25b

Cheers,
Carl Dong


> On Jan 5, 2022, at 2:13 PM, Maxime Devos  wrote:
> 
> Hi,
> 
> Carl Dong schreef op wo 05-01-2022 om 12:40 [-0500]:
>> Simon, Maxime, Danny,
>> 
>> Thanks for CCing me on this message! The rationale for bundling
>> leveldb in Bitcoin Core goes a bit beyond convenience, it is several
>> things:
>> 
>> 1. The original reason for sub-treeing is that Bitcoin Core used to
>> maintain its own version of leveldb with its own fixes
>> here: https://github.com/bitcoin-core/leveldb-subtree, since then
>> most of these fixes have been upstreamed as
>> of: https://github.com/bitcoin/bitcoin/pull/17398
> 
> Seems reasonable to me, but the bitcoin project is upstreaming the
> changes it made and most are already upstream, so I would prefer
> to use upstream's leveldb.
> 
>> 2. We also used to support using an external leveldb, however, it
>> seems that it was fragile to rely on external projects to maintain
>> ABI compatibility, see the quoted IRC bug report
>> here: https://github.com/bitcoin/bitcoin/pull/23282. Reasonable minds
>> may disagree on this point, especially coming from Guix where
>> patching is convenient.
> 
> The quoted ABI incompatibility
> 
> bitcoind fails to start with undefined symbol:
> _ZTIN7leveldb6LoggerE in Debian Sid after leveldb upgraded from 1.22 to
> 1.23: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996486
> 
> doesn't apply in Guix, because guix uses RUNPATH and multiple library
> versions can exist in the same store (in different directories in the
> store).
> 
>> In addition to the above, Bitcoin Core experienced a hard fork in
>> 2013 due to database incompatibilities, which has predisposed
>> maintainers towards a more stringent approach with pinning
>> dependencies and their configure/build-time flags.
>> See: https://blog.bitmex.com/bitcoins-consensus-forks/#was-the-2013-
>> incident-a-hardfork
> 
> I doubt that Guix has sufficient Bitcoin Core users to cause
> a hard fork, but yes, this is an understandable reason to bundle
> things.  But any such problem seems easy to resolve (at the guix side):
> we could simply temporarily switch to an older version of leveldb.
> 
> If desired, it would also be possible to do something in-between
> unbundling and using bitcoin's leveldb: define a 'leveldb/bitcoin'
> variant of the 'leveldb' package (using package/inherit or (package
> (inherit ...) ...)), add it as input to the 'bitcoin' package and tell
> and/or patch bitcoin's buid scripts to use that leveldb.
> 
> As source code, use an appropriate commit from
>  (and add a comment
> to the definition of bitcoin-core to keep leveldb/bitcoin in-sync).
> 
> A benefit of this approach (if done properly, with (origin (inherit
> ...) ...) such that patches of 'leveldb' are inherited) above the
> status quo, is that is that if for some reason 'leveldb' is patched in
> Guix, then 'leveldb/bitcoin' receives the patch as well. Another
> benefit is that the dependency 'googletest' and 'benchmark' of leveldb
> would remain unbundled.
> 
> Greetings,
> Maxime.
> 



signature.asc
Description: Message signed with OpenPGP

bug#49029: ungoogled-chromium failed to disable malware extension The Great Suspender

[Jorge P . de Morais Neto via Bug reports for GNU Guix]

Hi,

Em [2022-01-06 qui 08:46:43-0500], Maxim Cournoyer escreveu:

> You could find one of the project maintainers email address in the git
> history of the project and send them a private email with your
> suggestion.

I have just emailed Eloston.  I will inform here if he replies.

Kind regards

-- 
- Please adopt free/libre formats like PDF, Org, LaTeX, ODF, Opus, WebM and 7z.
- Libre apps for AOSP (Replicant, LineageOS, etc.) and Android: F-Droid
- https://www.gnu.org/philosophy/free-sw.html "What is free software?"

bug#53061: tremc: unable to view torrent's details

[Disseminate Dissent via Bug reports for GNU Guix]

Pressing Enter should open up the torrent's details which grants more 
functionality, instead it crashes back to the terminal.

Disseminate,
Peace

bug#29736: i686: webkit not usable

[Leo Famulari]

On Thu, Jan 06, 2022 at 09:59:24AM +0100, Konrad Hinsen wrote:
> Leo Famulari  writes:
> 
> > We can use the gst-plugins/selection procedure to avoid propagating all
> > of gst-plugins-bad.
> 
> That sounds interesting. But we'd first have to know which plugins are
> actually important to have. Is there a way to trace plugin loading?

That, I don't know. But I just wanted to point out that there is a
tool available for avoiding the entire gst-plugins-bad in cases like
this.

bug#53027: Backtrace with `guix pull --debug=2`

[Ludovic Courtès]

Hi,

Maxime Devos  skribis:

> Oskar Berndal schreef op wo 05-01-2022 om 16:19 [+0100]:
>>    179:23  2 (update-build #< building: () downloadin…> …)
>> In ice-9/boot-9.scm:
>>   1685:16  1 (raise-exception _ #:continuable? _)
>>   1685:16  0 (raise-exception _ #:continuable? _)
>> 
>> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
>> In procedure struct-vtable: Wrong type argument in position 1
>> (expecting struct): #f
>
> Seems like the issue is that 'find-build' returns #false
> and 'update' doesn't expect that. So apparently a progress spinner
> appears for a build that (guix status) doesn't know about?
> I don't know how that can happen.
>
> It's easy to address though (do nothing when no build was found),
> but possibly that would only paper over the real issue.

Yeah.  This looks like .

Ludo’.

bug#52982: `guix home reconfigure` not installing packages in configuration file.

[Ludovic Courtès]

Hi,

Ry Pemberton  skribis:

> I've run into a strange issue where `guix home reconfigure` does not install 
> the packages listed in the (home-environment(packages(append))) block.
>
> It isn't throwing any errors except for a warning:
> WARNING: Use of `load' in declarative module (#{ g56}#). Add #:declarative? 
> #f to your define-module invocation. unbound-variable(#f "Unbound variable: 
> ~S" (make-system-contructor) #f)

Most of the paste.debian.net links are already unavailable.

Could you paste the config file and command output in-line?

Thanks in advance,
Ludo’.

bug#52908: 'tests/guix-system.sh' fails on aarch64-linux

[Ludovic Courtès]

Hi,

Chris Marusich  skribis:

> I've attached a different patch that attempts to fix the issue without
> requiring callers of set-xorg-configuration to update their code.  I
> believe this is more consistent with the intent of Ludo's original
> change in commit 49599fab564f203b8e92d32e9b28c99e99849bfb.

[...]

> From 09091cc8495e0b4c302a58961e79ac8455ecd208 Mon Sep 17 00:00:00 2001
> From: Chris Marusich 
> Date: Mon, 3 Jan 2022 14:59:35 -0800
> Subject: [PATCH] services: Consistently use SDDM rather than GDM on
>  non-x86_64.
>
> This is a follow-up to 49599fab564f203b8e92d32e9b28c99e99849bfb.  Notably, it
> also deprecates (gnu services sddm) and moves what was there into (gnu
> services xorg).
>
> Fixes: .

I’d rather not move things and fix the bug in the same commit.  (I’m not
even convinced sddm needs to leave its own module, plus it would break
the API, which is not something to do lightly.)

[...]

>  (define* (set-xorg-configuration config
>   #:optional
>   (login-manager-service-type
> -  gdm-service-type))
> +  (let ((system (or (%current-target-system)
> +(%current-system
> +(if (string-prefix? "x86_64" system)
> +gdm-service-type
> +sddm-service-type

[...]

> --- a/gnu/system/examples/vm-image.tmpl
> +++ b/gnu/system/examples/vm-image.tmpl
> @@ -107,12 +107,12 @@ root ALL=(ALL) ALL
>   ;; Use the DHCP client service rather than NetworkManager.
>   (service dhcp-client-service-type))
>  
> -   ;; Remove GDM, ModemManager, NetworkManager, and wpa-supplicant,
> -   ;; which don't make sense in a VM.
> +   ;; Remove some services that don't make sense in a VM.
> (remove (lambda (service)
>   (let ((type (service-kind service)))
> (or (memq type
>   (list gdm-service-type
> +   sddm-service-type

These bits LGTM.

Thanks for fixing it!

And yes, we’ll need to update the ‘guix’ package once this fix is in.

Ludo’.

bug#49029: ungoogled-chromium failed to disable malware extension The Great Suspender

[Maxim Cournoyer]

Hi,

Jorge P. de Morais Neto  writes:

> Hello!
>
> Em [2022-01-03 seg 23:55:59-0500], Maxim Cournoyer escreveu:
>
>> With close to 1500 bugs open, we need *your* help :-).  If you think
>> this issue is worthy of bringing upstream, please see to it!
>
> Do you know of a way of bringing this issue upstream without a GitHub
> account?  I could not find one.

You could find one of the project maintainers email address in the git
history of the project and send them a private email with your
suggestion.

Thanks,

Maxim

bug#22952: MacBook2, 1 brightness control requires root privileges

[pelzflorian (Florian Pelz)]

On Wed, Jan 05, 2022 at 12:46:54AM +0100, zimoun wrote:
> I am doing triage of old bug and I hit this one [1].  Is it still happening?

Thank you for asking again.  All is fixed and no password gets asked
when using brightness keys on my same Macbook on GNOME/GDM nor
MATE/SDDM.  I cannot test the original poster’s Redshift even after
adding it to the geoclue-service-type applications because I lack WiFi
hardware.

Closing.

Regards,
Florian

bug#49029: ungoogled-chromium failed to disable malware extension The Great Suspender

[Jorge P . de Morais Neto via Bug reports for GNU Guix]

Hello!

Em [2022-01-03 seg 23:55:59-0500], Maxim Cournoyer escreveu:

> With close to 1500 bugs open, we need *your* help :-).  If you think
> this issue is worthy of bringing upstream, please see to it!

Do you know of a way of bringing this issue upstream without a GitHub
account?  I could not find one.

Kind regards

-- 
- Many people hate injustice but few check the facts; this causes more
  injustice.  Ask me about 
- I am Brazilian.  I hope my English is correct and I welcome feedback.
- Free Software Supporter: https://www.fsf.org/free-software-supporter
- If an email of mine arrives at your spam box, please notify me.

bug#53028: (nextcloud client segfaults)

[Γυψ]

The problem is related to this known issue:

https://github.com/NixOS/nixpkgs/issues/119029

which is fixed in version 3.3 of the client.

Removing the directories

~/.local/share/Nextcloud
~/.cache/Nextcloud

resolved the issue (at least temporarily).

-- Alex

On Thu, Jan 06 2022, 11:03:48, Γυψ  wrote:

> I looked at the difference between the last generation nextcloud-client
> worked and the first it segfaults and the list of differences is shown
> below [1].
>
> Since nextcloud is a QT application not even gtk+ should make the
> difference. Therefore I suspect that it is in the nextcloud-client@3.2
> source where the reason for the error is located.
>
> I tried to switch back to 3.1.3 but there doesn't seem to be an older
> version for nextcloud-client any more.
>
>> $ guix install nextcloud-client@3.1.3
>> guix install: error: nextcloud-client: package not found for version 3.1.3
>
> -- Alex
>
>
> [1] different packages between working and non-working generation (only
>  packages with different versions are shown, versions, not hashes are
>  considered):
>  
>  + python-jupyterlab  3.2.5   out 
> /gnu/store/hsm2xijmav64liaay6ph2zyi0vx2mi4a-python-jupyterlab-3.2.5
>  - python-jupyterlab  2.2.9   out 
> /gnu/store/fsqv8wajabyk7dn11pcqwsdb81rcnv00-python-jupyterlab-2.2.9
>  + ungoogled-chromium 96.0.4664.110-1 out 
> /gnu/store/pa3k6j8i17bdhz4yw62n5pwg1ca4c1gi-ungoogled-chromium-96.0.4664.110-1
>  - ungoogled-chromium 96.0.4664.93-1  out 
> /gnu/store/h74xpji0j9kck4lwlrvc02vjc04rbajr-ungoogled-chromium-96.0.4664.93-1
>  + nextcloud-client   3.2.0   out 
> /gnu/store/9lqfvn04fsr5npr9glx4ikygdynxqwy1-nextcloud-client-3.2.0
>  - nextcloud-client   3.1.3   out 
> /gnu/store/964z4rjzg8236wcf7v24048gvcqm71lh-nextcloud-client-3.1.3
>  + flameshot  0.10.2  out 
> /gnu/store/gzkz2ycwpza4vv76zh0i3vwzblpl0kkm-flameshot-0.10.2
>  - flameshot  0.8.5   out 
> /gnu/store/8s055qi18q8awrwji13ym5l27kcavmb1-flameshot-0.8.5
>  + cups   2.3.3op2out 
> /gnu/store/1id6r895258wj44wl75zf51c8igq8vmg-cups-2.3.3op2
>  - cups   2.3.3   out 
> /gnu/store/bi9p7zj8jjbwxlgah91pqjxypywgaxvq-cups-2.3.3
>  + evince 40.2out 
> /gnu/store/n9pkb1145b9wd3l43ccxm241c29nlb6f-evince-40.2
>  - evince 3.36.5  out 
> /gnu/store/kkxnc1qcvlaqhwyqzn7ix75v19zwkzy1-evince-3.36.5
>  + rofi   1.7.2   out 
> /gnu/store/klq61hm4h97j11kczm7vlnfsrmwnf9s8-rofi-1.7.2
>  - rofi   1.7.0   out 
> /gnu/store/x5rwxpy2w6a0s19yl52x2pir5xm9c75i-rofi-1.7.0
>  + gtk+   3.24.30 out 
> /gnu/store/p1x3p9x0x5g5m22dwzi7iw87bpxmb2sz-gtk+-3.24.30
>  - gtk+   3.24.24 out 
> /gnu/store/1dswfgvhwykglwkdfzvkypj5zjxicn96-gtk+-3.24.24
>  + poppler21.07.0 out 
> /gnu/store/gkiwa70z1w32xj51fyq9ya95famrh51q-poppler-21.07.0
>  - poppler0.86.1  out 
> /gnu/store/dyiipg5pd852zjwz2j1gd5s0zlxi3gyq-poppler-0.86.1
>  + pulseaudio 15.0out 
> /gnu/store/2ycq2ihp8zqg1687qd9k67xyzc4n0s42-pulseaudio-15.0
>  - pulseaudio 14.0out 
> /gnu/store/jjdrqjy4ns8arqdz37wi0qh43lc2z7d1-pulseaudio-14.0
>  + texlive20210325out 
> /gnu/store/35xph93135j3l3l856b2504j1hll53vr-texlive-20210325
>  - texlive20190410out 
> /gnu/store/c1ch558dhj4fh9d30lqb2nyqsrj0cfk1-texlive-20190410
>  + cmake  3.21.3  out 
> /gnu/store/wxfx09c113lghn6axwa7gk4cb74ld9cp-cmake-3.21.3
>  - cmake  3.21.1  out 
> /gnu/store/vfbw5h12hqg23bagnzgrmclds2vrky3q-cmake-3.21.1
>  + weechat3.4 out 
> /gnu/store/mnra0cii4br3731zjgbsivdpz7vknbc9-weechat-3.4
>  - weechat3.3 out 
> /gnu/store/9isbc51mvjidbrcpcwc8idkifn40jb1n-weechat-3.3
>  + gnupg  2.2.32  out 
> /gnu/store/75122spwjdkxxgd32gkkil3n7ifax8i5-gnupg-2.2.32
>  - gnupg  2.2.29  out 
> /gnu/store/cc0r4spdjr25pisaj4fs7pcyb62v1r2x-gnupg-2.2.29
>  + file   5.41out 
> /gnu/store/x6jwiap9rgdk6zkrp2ccwamw5qkrz92v-file-5.41
>  - file   5.38out 
> /gnu/store/h43rhpn3x2aifkk3sqhaaf6ia7hkqyhp-file-5.38
>
>
>
> On Wed, Jan 05 2022, 16:22:01, help-debb...@gnu.org (GNU bug Tracking System) 
> wrote:
>
>> Thank you for filing a new bug report with debbugs.gnu.org.
>>
>> This is an automatically generated reply to let you know your message
>> has been received.
>>
>> Your message is being forwarded to the package maintainers and other
>> 

bug#53047: qBittorrent or libtorrent-rasterbar doesn't connect post c-u-f merge

[Attila Lendvai]

dear Guixers,

qBittorrent stopped working around the time when i reconfigured after the 
core-updates-frozen merge.

the new behavior is that it can connect to trackers, it gets the peer list, but 
when i switch to the peer list tab of a specific torrent, what i see is that 
peers keeps showing up and then immediately disappear.

the number of DHT connections also remain at zero.

on my router i can see UPNP opening the relevant tcp and udp ports, and there's 
no firewall on the computer itself.

nothing else seems to have changed in the environment, and qBittorrent on a 
windows machine works on the same network.

- attila
PGP: 5D5F 45C7 DFCD 0A39

bug#53028: Acknowledgement (nextcloud client segfaults)

[Γυψ]

I looked at the difference between the last generation nextcloud-client
worked and the first it segfaults and the list of differences is shown
below [1].

Since nextcloud is a QT application not even gtk+ should make the
difference. Therefore I suspect that it is in the nextcloud-client@3.2
source where the reason for the error is located.

I tried to switch back to 3.1.3 but there doesn't seem to be an older
version for nextcloud-client any more.

> $ guix install nextcloud-client@3.1.3
> guix install: error: nextcloud-client: package not found for version 3.1.3

-- Alex


[1] different packages between working and non-working generation (only
 packages with different versions are shown, versions, not hashes are
 considered):
 
 + python-jupyterlab3.2.5   out 
/gnu/store/hsm2xijmav64liaay6ph2zyi0vx2mi4a-python-jupyterlab-3.2.5
 - python-jupyterlab2.2.9   out 
/gnu/store/fsqv8wajabyk7dn11pcqwsdb81rcnv00-python-jupyterlab-2.2.9
 + ungoogled-chromium   96.0.4664.110-1 out 
/gnu/store/pa3k6j8i17bdhz4yw62n5pwg1ca4c1gi-ungoogled-chromium-96.0.4664.110-1
 - ungoogled-chromium   96.0.4664.93-1  out 
/gnu/store/h74xpji0j9kck4lwlrvc02vjc04rbajr-ungoogled-chromium-96.0.4664.93-1
 + nextcloud-client 3.2.0   out 
/gnu/store/9lqfvn04fsr5npr9glx4ikygdynxqwy1-nextcloud-client-3.2.0
 - nextcloud-client 3.1.3   out 
/gnu/store/964z4rjzg8236wcf7v24048gvcqm71lh-nextcloud-client-3.1.3
 + flameshot0.10.2  out 
/gnu/store/gzkz2ycwpza4vv76zh0i3vwzblpl0kkm-flameshot-0.10.2
 - flameshot0.8.5   out 
/gnu/store/8s055qi18q8awrwji13ym5l27kcavmb1-flameshot-0.8.5
 + cups 2.3.3op2out 
/gnu/store/1id6r895258wj44wl75zf51c8igq8vmg-cups-2.3.3op2
 - cups 2.3.3   out 
/gnu/store/bi9p7zj8jjbwxlgah91pqjxypywgaxvq-cups-2.3.3
 + evince   40.2out 
/gnu/store/n9pkb1145b9wd3l43ccxm241c29nlb6f-evince-40.2
 - evince   3.36.5  out 
/gnu/store/kkxnc1qcvlaqhwyqzn7ix75v19zwkzy1-evince-3.36.5
 + rofi 1.7.2   out 
/gnu/store/klq61hm4h97j11kczm7vlnfsrmwnf9s8-rofi-1.7.2
 - rofi 1.7.0   out 
/gnu/store/x5rwxpy2w6a0s19yl52x2pir5xm9c75i-rofi-1.7.0
 + gtk+ 3.24.30 out 
/gnu/store/p1x3p9x0x5g5m22dwzi7iw87bpxmb2sz-gtk+-3.24.30
 - gtk+ 3.24.24 out 
/gnu/store/1dswfgvhwykglwkdfzvkypj5zjxicn96-gtk+-3.24.24
 + poppler  21.07.0 out 
/gnu/store/gkiwa70z1w32xj51fyq9ya95famrh51q-poppler-21.07.0
 - poppler  0.86.1  out 
/gnu/store/dyiipg5pd852zjwz2j1gd5s0zlxi3gyq-poppler-0.86.1
 + pulseaudio   15.0out 
/gnu/store/2ycq2ihp8zqg1687qd9k67xyzc4n0s42-pulseaudio-15.0
 - pulseaudio   14.0out 
/gnu/store/jjdrqjy4ns8arqdz37wi0qh43lc2z7d1-pulseaudio-14.0
 + texlive  20210325out 
/gnu/store/35xph93135j3l3l856b2504j1hll53vr-texlive-20210325
 - texlive  20190410out 
/gnu/store/c1ch558dhj4fh9d30lqb2nyqsrj0cfk1-texlive-20190410
 + cmake3.21.3  out 
/gnu/store/wxfx09c113lghn6axwa7gk4cb74ld9cp-cmake-3.21.3
 - cmake3.21.1  out 
/gnu/store/vfbw5h12hqg23bagnzgrmclds2vrky3q-cmake-3.21.1
 + weechat  3.4 out 
/gnu/store/mnra0cii4br3731zjgbsivdpz7vknbc9-weechat-3.4
 - weechat  3.3 out 
/gnu/store/9isbc51mvjidbrcpcwc8idkifn40jb1n-weechat-3.3
 + gnupg2.2.32  out 
/gnu/store/75122spwjdkxxgd32gkkil3n7ifax8i5-gnupg-2.2.32
 - gnupg2.2.29  out 
/gnu/store/cc0r4spdjr25pisaj4fs7pcyb62v1r2x-gnupg-2.2.29
 + file 5.41out 
/gnu/store/x6jwiap9rgdk6zkrp2ccwamw5qkrz92v-file-5.41
 - file 5.38out 
/gnu/store/h43rhpn3x2aifkk3sqhaaf6ia7hkqyhp-file-5.38



On Wed, Jan 05 2022, 16:22:01, help-debb...@gnu.org (GNU bug Tracking System) 
wrote:

> Thank you for filing a new bug report with debbugs.gnu.org.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  bug-guix@gnu.org
>
> If you wish to submit further information on this problem, please
> send it to 53...@debbugs.gnu.org.
>
> Please do not send mail to help-debb...@gnu.org unless you wish
> to report a problem with the Bug-tracking system.



signature.asc
Description: PGP 

bug#53044: (wishlist) time-machine and ambiguous prefix SHA-1

[zimoun]

Hi,

Now the repo is becoming large, the short prefix using 6 character can
be refer to 2 Git objects.  For instance,

--8<---cut here---start->8---
$ git show 7022eb6
error: short object ID 7022eb6 is ambiguous
hint: The candidates are:
hint:   7022eb6ea0 commit 2021-12-07 - gnu: Add notcurses.
hint:   7022eb6c9a blob
[..]
--8<---cut here---end--->8---

The issue is the error report by “guix time-machine” (or guix pull), for
instance,

--8<---cut here---start->8---
$ guix time-machine --commit=7022eb6 -- help
guix time-machine: error: Git error: ambiguous SHA1 prefix - found multiple 
pack entries
--8<---cut here---end--->8---

It could be nice that, when short prefix is ambiguous:

   1) try the commit object candidate if only one
   2) show a hint for the possible candidates


Cheers,
simon

bug#29736: i686: webkit not usable

[Konrad Hinsen]

Leo Famulari  writes:

> We can use the gst-plugins/selection procedure to avoid propagating all
> of gst-plugins-bad.

That sounds interesting. But we'd first have to know which plugins are
actually important to have. Is there a way to trace plugin loading?

Konrad

bug#52829: GNOME Bluetooth integration is broken

[Mathieu Othacehe]

> It installs an udev rule to add an uaccess tag to the /dev/rfkill
> device. Then elogind takes care of modifying the file ACL accordingly.

Pushed, thanks!

Mathieu