bug#47648: cc-for-target makes --with-c-toolchain unusable for some packages

[raingloom]

I tried compiling lua with clang on a whim and found out about
cc-for-target. Not sure if that's the only instance of hardcoded gcc,
but it's certainly a prominent one.

What would be the idiomatic way to fix it? Detect clang dynamically? Or
move cc-for-target inside the build system module and make it available
at build time?

bug#47645: Feature Request: Add Simple Firewall by default

[bo0od]

Hi There,

It would be nice too see simple FW within Guix, Most common one used in 
GNU distros is Gufw used in ubuntu,mint..etc


This is essential for end users to have control on opening/closing ports 
and/or control on income/outcome traffics.. by using either GUI or 
simple CLI commands. (iptables is for surely not simple)


ThX!

bug#47569: ‘qt-build-system’ retains too many references via wrappers

[Maxim Cournoyer]

Maxim Cournoyer  writes:

> Seeing a growing number of packages require a custom wrap phase for
> qtwebengine, I think the following additions could make sense to be
> incorporated as part as this Qt-world rebuild:
>
> 2 files changed, 5 insertions(+), 1 deletion(-)
> gnu/packages/qt.scm| 3 +++
> guix/build/qt-build-system.scm | 3 ++-
>
> modified   gnu/packages/qt.scm
> @@ -538,6 +538,9 @@ system, and the core design of Django is reused in 
> Grantlee.")
> (search-path-specification
>  (variable "QT_PLUGIN_PATH")
>  (files '("lib/qt5/plugins")))
> +   (search-path-specification
> +(variable "QTWEBENGINEPROCESS_PATH")
> +(files '("lib/qt5/libexec/QtWebEngineProcess")))
> (search-path-specification
>  (variable "XDG_DATA_DIRS")
>  (files '("share")))

Actually, scratch that part above, as there's already a search path
defined on the qtwebengine package, and it's more correctly defined as:

(native-search-paths
 (list (search-path-specification
(file-type 'regular)
(separator #f)
(variable "QTWEBENGINEPROCESS_PATH")
(files '("lib/qt5/libexec/QtWebEngineProcess")

So what I proposed above is not needed.

> modified   guix/build/qt-build-system.scm
> @@ -86,7 +86,8 @@
> "/cursors" "/wallpapers" "/icons" "/mime")
>   '("XDG_CONFIG_DIRS" "/etc/xdg")
>   '("QT_PLUGIN_PATH" "/lib/qt5/plugins")
> - '("QML2_IMPORT_PATH" "/lib/qt5/qml"
> + '("QML2_IMPORT_PATH" "/lib/qt5/qml")
> + '("QTWEBENGINEPROCESS_PATH" "lib/qt5/libexec/QtWebEngineProcess"
>
>  (define* (wrap-all-programs #:key inputs outputs
>  (qt-wrap-excluded-outputs '())

Still is still useful I think, but I noticed now it needs a leading
slash in from of the lib/qt5/libexec above.

Thanks,

Maxim

bug#47569: ‘qt-build-system’ retains too many references via wrappers

[Maxim Cournoyer]

Hi Ludo,

I just had another thought on this!

Ludovic Courtès  writes:

[...]

> -  (filter
> -   (lambda (var-to-wrap) (not (null? (last var-to-wrap
> -   (map
> -(lambda (var-spec)
> -  `(,(first var-spec) = ,(collect-sub-dirs base-directories (last 
> var-spec
> -(list
> - ;; these shall match the search-path-specification for Qt and KDE
> - ;; libraries
> - '("XDG_DATA_DIRS" "/share")
> - '("XDG_CONFIG_DIRS" "/etc/xdg")
> - '("QT_PLUGIN_PATH" "/lib/qt5/plugins")
> - '("QML2_IMPORT_PATH" "/lib/qt5/qml")
> +  (filter-map
> +   (match-lambda
> + ((variable directory selectors ...)
> +  (match (collect-sub-dirs base-directories directory
> +   selectors)
> +(()
> + #f)
> +(directories
> + `(,variable = ,directories)
> +
> +   ;; These shall match the search-path-specification for Qt and KDE
> +   ;; libraries.
> +   (list '("XDG_DATA_DIRS" "/share"
> +
> +   ;; These are "selectors": consider /share if and only if these
> +   ;; sub-directories exist.  This avoids adding irrelevant packages
> +   ;; to XDG_DATA_DIRS just because they have a /share sub-directory.
> +   "/glib-2.0/schemas" "/sounds" "/themes"
> +   "/cursors" "/wallpapers" "/icons" "/mime")
> + '("XDG_CONFIG_DIRS" "/etc/xdg")
> + '("QT_PLUGIN_PATH" "/lib/qt5/plugins")
> + '("QML2_IMPORT_PATH" "/lib/qt5/qml"
>
>  (define* (wrap-all-programs #:key inputs outputs
>  (qt-wrap-excluded-outputs '())


Seeing a growing number of packages require a custom wrap phase for
qtwebengine, I think the following additions could make sense to be
incorporated as part as this Qt-world rebuild:

2 files changed, 5 insertions(+), 1 deletion(-)
gnu/packages/qt.scm| 3 +++
guix/build/qt-build-system.scm | 3 ++-

modified   gnu/packages/qt.scm
@@ -538,6 +538,9 @@ system, and the core design of Django is reused in 
Grantlee.")
(search-path-specification
 (variable "QT_PLUGIN_PATH")
 (files '("lib/qt5/plugins")))
+   (search-path-specification
+(variable "QTWEBENGINEPROCESS_PATH")
+(files '("lib/qt5/libexec/QtWebEngineProcess")))
(search-path-specification
 (variable "XDG_DATA_DIRS")
 (files '("share")))
modified   guix/build/qt-build-system.scm
@@ -86,7 +86,8 @@
"/cursors" "/wallpapers" "/icons" "/mime")
  '("XDG_CONFIG_DIRS" "/etc/xdg")
  '("QT_PLUGIN_PATH" "/lib/qt5/plugins")
- '("QML2_IMPORT_PATH" "/lib/qt5/qml"
+ '("QML2_IMPORT_PATH" "/lib/qt5/qml")
+ '("QTWEBENGINEPROCESS_PATH" "lib/qt5/libexec/QtWebEngineProcess"

 (define* (wrap-all-programs #:key inputs outputs
 (qt-wrap-excluded-outputs '())

Thanks,

Maxim

bug#47644: guix on foreign distro won't upgrade, stuck on old commits

[Brian Zwahr]

Hi! It was suggested I email this in by someone in the IRC channel. I'm 
having an issue where guix always tells me it is "X days old" and that 
I should run guix pull/guix upgrade. However, running these commands 
does not fix the issue.


guix describe shows:

```
$ guix describe
Generation 9Mar 25 2021 08:36:11(current)
 guix 3f1b2bd
   repository URL: 
   branch: master
   commit: 3f1b2bd322b6cdba99a43d08e5e8464f7424cbc5
```

Which is, indeed, out of date. IRC folks recommended checking the git 
status, so I did:


```
~/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq 
(master) $ git status

On branch master
Your branch is behind 'origin/master' by 474 commits, and can be 
fast-forwarded.

 (use "git pull" to update your local branch)

nothing to commit, working tree clean
```

It is, indeed, out of date, but after a guix pull:

```
$ guix pull
Updating channel 'guix' from Git repository at 
''...

Building from this channel:
 guix  3f1b2bd
Computing Guix derivation for 'x86_64-linux'... |
nothing to be done
```

It doesn't update and still tells me I'm out of date:

```
$ guix upgrade
guix upgrade: warning: Your Guix installation is 13 days old.
guix upgrade: warning: Consider running 'guix pull' followed by
'guix package -u' to get up-to-date packages and security updates.
```

It was suggested that I should run this command:

```
guix pull --commit=02297d3fe680371a4b97b9c1b770932cbdd55615
```

and after doing so, I was then only 1 commit behind instead:

```
~/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq 
(master) $ git status

On branch master
Your branch is behind 'origin/master' by 1 commit, and can be 
fast-forwarded.

 (use "git pull" to update your local branch)

nothing to commit, working tree clean
```

However, `guix pull` now gives me a new error about needing to 
downgrade:


```
$ guix pull
Updating channel 'guix' from Git repository at 
''...
guix pull: error: aborting update of channel 'guix' to commit 
3f1b2bd322b6cdba99a43d08e5e8464f7424cbc5, which is not a descendant of 
02297d3fe680371a4b97b9c1b770932cbdd55615

hint: Use `--allow-downgrades' to force this downgrade.
```

and for some reason, I'm back to being almost 500 commits behind again:

```
~/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq 
(master) $ git status

On branch master
Your branch is behind 'origin/master' by 477 commits, and can be 
fast-forwarded.

 (use "git pull" to update your local branch)

nothing to commit, working tree clean
```

even though `guix describe` now seems to be more up-to-date (apr 7 
instead or mar 25)


```
$ guix describe
Generation 10   Apr 07 2021 14:38:16(current)
 guix 02297d3
   repository URL: 
   commit: 02297d3fe680371a4b97b9c1b770932cbdd55615
```

As a final attempt to solve this, it was suggested that I run `guix 
pull -l 2>&1 | tee pull-generations.log` and email it to this list. I'm 
attaching that file here.


Also, after running that command, I'm back to being only 1 commit 
behind and still get the downgrade error from `guix pull`:


```
~/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq 
(master) $ git status

On branch master
Your branch is behind 'origin/master' by 1 commit, and can be 
fast-forwarded.

 (use "git pull" to update your local branch)

nothing to commit, working tree clean
```

```
$ guix pull
Updating channel 'guix' from Git repository at 
''...
guix pull: error: aborting update of channel 'guix' to commit 
3f1b2bd322b6cdba99a43d08e5e8464f7424cbc5, which is not a descendant of 
02297d3fe680371a4b97b9c1b770932cbdd55615

hint: Use `--allow-downgrades' to force this downgrade.
```

For now, I'm trying to avoid doing anything else guix-related, so that 
my system is in the same state and can hopefully be diagnosed and fixed.



Generation 1	Mar 16 2021 14:50:54
  guix 109f584
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 109f58444beecd1b9b7c502f2a687a6b91c62dc0
Generation 2	Mar 16 2021 15:14:10
  guix 109f584
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 109f58444beecd1b9b7c502f2a687a6b91c62dc0
Generation 3	Mar 17 2021 09:24:14
  guix d79d63e
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: d79d63e7829d53f6a501d8df7e264ff70033abca
  1 new package: lolcode-lci
  5 packages upgraded: emacs-marginalia@0.4, gnome-autoar@0.3.1,
komikku@0.27.0, meson@0.57.1, tig@2.5.3
Generation 4	Mar 19 2021 13:05:15
  guix 1ab03fb
repository URL: https://git.savannah.gnu.org/git/guix.git
commit: 1ab03fb74505458e7754dce338a5da29dc754d80
  5 new packages: 

bug#47569: ‘qt-build-system’ retains too many references via wrappers

[Maxim Cournoyer]

Hi Ludovic,

Ludovic Courtès  writes:

> Hi again!
>
> The attached patch fixes this problem AFAICS by filtering out of
> XDG_DATA_DIRS directories that are unlikely to be of any use.  It
> follows the same strategy as ‘glib-or-gtk-build-system’, which is to
> only include share/ sub-directories that also contain one of the given
> “selectors”: /glib-2.0/schemas, /sounds, /themes, etc.
>
> It gives me a working ktouch, with a wrapper sets a much shorter
> XDG_DATA_DIR:
>
> $ head -2 $(./pre-inst-env guix build --no-grafts ktouch)/bin/ktouch
> #!/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/bash
> export 
> XDG_DATA_DIRS="/gnu/store/mgzijzw7yn03pbk54zy0f81gyph9jh3k-ktouch-20.12.1/share:/gnu/store/5g95qdh0p46qszv199rmdd2lx4mninm7-kcoreaddons-5.70.0/share"
> $ head -2 $(guix build --no-grafts ktouch)/bin/ktouch
> #!/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/bash
> export 
> 

bug#47458: Terrible UX upgrading Emacs in Guix

[Maxim Cournoyer]

Hi Leo!

Leo Prikler  writes:

> Hi Maxim!
>
> Am Dienstag, den 06.04.2021, 08:09 -0400 schrieb Maxim Cournoyer:
>> Hi Leo!
>>
>> Leo Prikler  writes:
>>
>> [...]
>>
>> > > Shouldn't we wrap all the binaries to be on the safe
>> > > side?  Things
>> > > such
>> > > as emacsclient probably ought to have EMACSLOADPATH set
>> > > correctly,
>> > > no?
>> > The remaining binaries are
>> > - emacsclient, which inherits its EMACSLOADPATH from the server it
>> > connects to
>> > - ctags, ebrowse and etags, which are helper binaries, that don't
>> > seem
>> > to rely on EMACSLOADPATH at all.  (Or is there an indicator, that
>> > they
>> > do?)
>> > - .-real binaries, that should only be wrapped once.
>> > We could relax the regex to include the upper two, but I don't
>> > think
>> > it's necessary to do so.
>>
>> OK, thanks for the explanation, it makes sense.
>>
> Should I also document that (as a comment in the code) or is it
> somewhat intuitive, that only Emacs is interested in these variables
> (just EMACSLOADPATH currently, maybe also PATH later)?

It wouldn't hurt!  It was not obvious to me that emacsclient didn't need
it (I have no knowledge of emacsclient's internals).

>> > I'd like to avoid pushing this to master just yet, because we also
>> > have
>> > changes in the Emacs build system to discuss and I don't want to
>> > cause
>> > an "Emacs world" rebuild twice in a row.  That said, I'm including
>> > this
>> > patch in wip-emacs with the plan to push to master or staging once
>> > everything there is resolved.
>>
>> Sure!  Which changes do you have in mind?  Are they already on the
>> tracker for review?
>>
>
> I've sent some of the changes for emacs-build-system to 45316.  The
> rest only lives on wip-emacs as of yet.  The first 5 patches on that
> branch are the ones that include the big changes (well, four of them
> anyway), one of which is not yet up to review as it results from the
> combined fixes to 45316 and 47458, the rest are mostly small "fixup"
> commits.

OK.  I'll have a look.

Maxim

bug#47584: Race condition in ‘copy-account-skeletons’: possible privilege escalation.

[Maxime Devos]

On Tue, 2021-04-06 at 13:57 +0200, Ludovic Courtès wrote:
> [...]
> 
> The blog post and info-guix messages are the highest levels of
> visibility we can give, roughly.  So I think we have to think twice
> before doing that or truly important issues will eventually go
> unnoticed.
> 
> The risk with this issue seems much lower than that of the keep-failed
> issue, it even looks super low.
> 
> WDYT?

That is a good point, but I still wonder if there's *somewhere* this
can be posted.

I was going to start a thread at guix-devel about
blog posts in general (categories, what can be posted as a ‘official’
blog post on guix.gnu.org, any maximal frequencies ...) but I ended up
being busy with other things.

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

bug#42250: offload test failure: guile bug?

[Christopher Howard]

bug#47225: QEMU warning about performance

[Leo Famulari]

On Tue, Apr 06, 2021 at 08:42:38PM -0400, Maxim Cournoyer wrote:
> I hope I'm timely; I've made a revised version of the patch, that should
> cover more cases (and actually uses 100 MiB rather than 1 MiB :-)).

Yes, you're in time :) Thanks for the revised patch.


signature.asc
Description: PGP signature

bug#47641: Ongoing difficulities after linphoneqt -> linphone-desktop transition

[Christopher Howard]

My system information:

christopher@theoden ~$ neofetch --stdout
christopher@theoden 
--- 
OS: Guix System 079a7f2c65c51da7b53b0e5ef44c516dc8eaab6e x86_64 
Host: OptiPlex 9020 00 
Kernel: 5.11.11-gnu 
Uptime: 1 day, 20 hours, 39 mins 
Packages: 92 (guix-system), 102 (guix-user) 
Shell: bash 5.0.16 
Resolution: 1920x1080 
DE: GNOME 
Theme: Adwaita [GTK2/3] 
Icons: Adwaita [GTK2/3] 
Terminal: kitty 
CPU: Intel i5-4570 (4) @ 3.600GHz 
GPU: Intel HD Graphics 
GPU: AMD ATI Radeon HD 8490 / R5 235X OEM 
Memory: 3393MiB / 7871MiB

--
Christopher Howard

bug#47641: Ongoing difficulities after linphoneqt -> linphone-desktop transition

[Christopher Howard]

Hi, I've been having difficulties since the the recent linphone
updates. I know some work has been done on the package in recent
commits, so just a few minutes ago I ran

guix time-machine -- environment --ad-hoc linphone-desktop

christopher@theoden ~ [env]$ guix describe
Generation 14   Apr 01 2021 13:21:37(current)
  guix 079a7f2
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 079a7f2c65c51da7b53b0e5ef44c516dc8eaab6e

The two problems I get running the program are:

(1) I get non-descript error icons when I send messages to contacts
(though the messages seem to get through)

(2) old messages do not appear when I start the application

(3) messages from others appear in notifications window but not in the
app screen

(4) sometimes get a segfault upon replying to a message

Ideally I should test with a clean linphone profile but haven't gotten
to it yet due to being busy.

For now I am using an inferior to run linphoneqt from commit
3f1b2bd322b6cdba99a43d08e5e8464f7424cbc5, which still works great.

--
Christopher Howard

bug#38764: emacs-darkroom: buggy display behavior and errors

[Christopher Howard]

Attempting to close bug.

Christopher H

bug#47260: Package GNU MediaGoblin as a Guix service

[Ben Sturmfels via Bug reports for GNU Guix]

On Tue, 06 Apr 2021, Ben Sturmfels wrote:

> On Thu, 01 Apr 2021, Ben Sturmfels wrote:
>
>> 5. Get a basic Guix service working, with sqlite3 and without the
>> offloaded media transcoding currently using Celery task queue with a
>> Redis broker.
>
> Woo! After a lot of trial and error, I finally have a basic MediaGoblin
> running entirely under Guix with no virtualenv trickery!
>
> After applying the attached patch to my guix repo...

Even simpler, I've now created a Guix channel for our work-in-progress
MediaGoblin package/service. See the README for instructions on enabling
the channel and installing MediaGoblin:

https://gitlab.com/BenSturmfels/mediagoblin-guix/-/blob/master/README.md

Once the channel is enabled, you can `guix install mediagoblin` and run
`gmg` commands and the web interface. All documented in the above README.

Regards,
Ben

bug#47638: [Emacs-Guix] build-farm-url.el refers to former URLs

[Ludovic Courtès]

Hi!

I just noticed that build-farm-url.el refers to deprecated/outdated
URLs: hydra.gnu.org, ci.guix.info, etc.

As I’m writing this :-), I also notice that build-farm.el is technically
not part of Emacs-Guix (and it supports Hydra too), but perhaps it
should?  The Cuirass JSON API is being expanded these days so it may be
useful to revive this code.

Ludo’.

bug#47629: Manual Installation: /grub/i386-pc/modinfo.sh doesn't exist. Please Specify --target or --directory

[bo0od]

Hi There,

Im trying to install guix manually but i always end up with this error. 
Please check the uploaded images.


ThX!

bug#47632: Extracting guix.iso.xz with Xarchiver will give damaged .iso

[bo0od]

Hi There,

I have just tested to extract guix.iso.xz using Xarchiver and tried to 
install guix.iso on a vbox, The image wont be readable/identified for 
installation.


Only way to make it work is by using unxz command.

bug#47634: Accompany .asc and .DIGESTS keys for the ISO

[bo0od]

Hi There,

I see there is only .sig provided:

https://guix.gnu.org/en/download/

Its better to provide more than one way of verification e.g:

Qubes: https://www.qubes-os.org/downloads/
Whonix: https://www.whonix.org/wiki/VirtualBox/XFCE
...etc

ThX!

bug#47633: Provide direct download to .iso

[bo0od]

Hi There,

I see that guix compress its image here:

https://guix.gnu.org/en/download/

Which im not sure why (I dont see any known project doing that), But 
regardless to the reason behind it this is actually give some problems 
to users who want to use Guix on outside server, Many host providers 
nowadays they give the opportunity to install whatever the user want 
from distros according to his wish from outside source but one thing 
needed for that is the URL to the .iso , And the host gonna 
download/run/import the .iso for the user.


This is cant be achieved because there is no direct URL to the .iso, And 
it causes some problems as well check #47632


ThX!

bug#47631: Add graphical installation and solve tons of headache

[bo0od]

Hi There,

According to my communications on IRC i see that guix doesnt want to 
have an offline installation, Which mean it need internet connection 
available at the installation process.


This is fine except when user having either static-ip or using VM which 
doesnt give readable network interface to the distro inside it (falling 
into same category of static-ip).


solving/giving:

- Adding static IP and so as manually installing is not well documented 
and need knowledge and skills (very faraway to be handled by new 
users)check #47630


- Easiness of modifying things e.g instead of using tens of commands it 
will be replaced with couple of clicks and for surely less typing 
(compare gparted vs parted steps or network-manager vs ip commands and 
so on). You can checkout many distros whos giving this opportunity like 
nixos, trisquel/triskel, mint...etc


- Give trial usage of the distro for the user before installing it

...etc

And any user who doesnt want GUI he can switch to tty for commands or 
textual installation. (The image of the guix will be bigger for surely, 
But as they say the bigger the better)


ThX!

bug#47451: closed (Re: bug#47451: Guix pull building lz4-1.9.3 fails)

[Bone Baboon]

I am no longer having this error.  This error was part of a unsuccessful
attempt to install a previous version of a package.

I am using a different approach to install a previous version of a
package which is working and is detailed here:
https://lists.gnu.org/archive/html/help-guix/2021-04/msg6.html

bug#47636: building for foreign arches produces native code on core-updates

[Efraim Flashner]

$ ./pre-inst-env guix build hello --system=i686-linux
/gnu/store/j8kszh3mgi2f9k3vy8kl5mk0lgsp9qdf-hello-2.10
$ file /gnu/store/j8kszh3mgi2f9k3vy8kl5mk0lgsp9qdf-hello-2.10/bin/hello
/gnu/store/j8kszh3mgi2f9k3vy8kl5mk0lgsp9qdf-hello-2.10/bin/hello: ELF 64-bit 
LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter 
/gnu/store/z543b5csaras5lhb5d4j3v3dl26i3dxm-glibc-2.32/lib/ld-linux-x86-64.so.2,
 stripped
$ ./pre-inst-env guix build hello --system=aarch64-linux
/gnu/store/6s01jscrc1p0hb2v0h1csjmichyk9w3l-hello-2.10
$ file /gnu/store/6s01jscrc1p0hb2v0h1csjmichyk9w3l-hello-2.10/bin/hello
/gnu/store/6s01jscrc1p0hb2v0h1csjmichyk9w3l-hello-2.10/bin/hello: ELF 64-bit 
LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter 
/gnu/store/z543b5csaras5lhb5d4j3v3dl26i3dxm-glibc-2.32/lib/ld-linux-x86-64.so.2,
 stripped

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


signature.asc
Description: PGP signature

bug#45179: qutebrowser stuck at Cloudflare 'browser checks'

[Michael Rohleder]

"bdju"  writes:
> On Tue Apr 6, 2021 at 4:41 PM CDT, bdju wrote:
>> While I was able to bypass the cloudflare checks in IceCat with that
>> User Agent Switcher addon, I found I so far haven't been able to get
>> past them in qutebrowser by changing my useragent. I tried both your
>> example and copying one of the useragents generated by UAS in IceCat.
>> Still caught in a loop. (and I am using --temp-basedir as you said, so
>> shouldn't be my config)
> I was too hasty! I both had to change my useragent and wait a long time!
> I didn't measure the time, but I'd guess over 10 minutes for Gitlab to
> work. Livechart took even longer. Thanks so much for this workaround.
> Oh, and this works without --temp-basedir, by the way. I should be able
> to actually use these sites in my normal session now I think!

Yay!  That's great to hear, so let's close this ;)

-- 
Practical people would be more practical if they would take a little
more time for dreaming.   -   J. P. McEvoy


signature.asc
Description: PGP signature

bug#46212: ci.guix.gnu.org narinfos with excessive NarSize

[Brendan Tildesley via Bug reports for GNU Guix]

I just had the same bug with flightgear as Ludo.

Running `guix build flightgear', guix showed it was downloading substitute 
information, and then errored with

guix build: error: integer expected from stream

Possibly helpful strace info:

write(14, 
"\36\0\0\0\0\0\0\0\3\0\0\0\0\0\0\0?\0\0\0\0\0\0\0/gnu/store/ssdka48kwx9f2z54j63mjxvn6bg502mm-flightgear-2018.3.5\0@\0\0\0\0\0\0\0/gnu/store/pr6xy604hg7yhcinnlymrkc958kl0bnn-openscenegraph-3.4.1<\0\0\0\0\0\0\0/gnu/store/g8g4paw3q3z8hkl441ddhdn0in54gi3f-simgear-2018.3.5\0\0\0\0",
 232) = 232
read(14, "ptxc\0\0\0\0", 8) = 8
read(14, "\34\0\0\0\0\0\0\0", 8)= 8
read(14, "integer expected from stream\0\0\0\0", 32) = 32
read(14, "\1", 1)   = 1
read(14, "\0\0\0\0\0\0\0", 7)   = 7
close(14)

bug#47628: webkitgtk-2.32.0 is broken on my system

[Guillaume Le Vaillant]

Mark H Weaver  skribis:

> retitle 47628 webkitgtk-2.32.0 is broken on my system
> thanks
>
> Mark H Weaver  writes:
>
>> FYI, since updating to webkitgtk-2.32.0 (commit
>> 3c5e1412e3ef769df8e4826d0aedabaa3aa0d631), epiphany fails to launch: no
>> window appears, although GNOME Shell shows an empty outline in overview
>> mode, as if there's a window but it has never been painted.
>>
>> When running 'epiphany' from the command line, I see the followin
>> warning from 'bwrap', which indicates that it's looking in /usr/bin:
>
> I see exactly the same behavior with 'eolie': the window never appears,
> (except for an outline in GNOME Shell's overview mode), and I see the
> same warning:
>
>   "bwrap: Can't find source path /usr/bin: No such file or directory"
>
> In both cases, if I try to close the phantom window from overview mode,
> it informs me that the application is not responding, and I have to
> force quit to make the phantom window go away.
>
>Mark

On my Guix system, epiphany with webkitgtk-2.32.0 seems to work fine
(with Guix at commit 14392c77896561c5846c0f3a0588720792d61e95).
The window appears and I can browse websites, and it doesn't print any
error about 'bwrap'.
I'm using StumpWM and not Gnome Shell; I don't know if it has an impact
on epiphany's behavior.


signature.asc
Description: PGP signature

bug#45571: Support stable uids and gids for system accounts in a container

[Brendan Tildesley via Bug reports for GNU Guix]

It may be useful to see what Nix does.

Nix has many static id, with the comment:

# IMPORTANT!
# We only add static uids and gids for services where it is not feasible
# to change uids/gids on service start, in example a service with a lot of
# files. Please also check if the service is applicable for systemd's

https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/misc/ids.nix