Re: Thank you for participating in the Guix Day!

[Andreas Enge]

Hello,

On Tue, Nov 24, 2020 at 09:13:38PM +0530, Arun Isaac wrote:
> Guix Day was wonderful. Thank you very much for organizing it! More than
> anything, I attended just to see people's faces, and put faces to
> names. Seeing smiling faces is surprisingly motivating, especially in
> lockdown times. :-)

I can only second that - it is even nicer to meet in person, but this
was a really social event online.

> I'm happy it was an online event and I could participate. I live in
> India and travelling to Europe is a bank-breaking endeavour that is
> normally out of the question. I think even future offline Guix Days,
> after the pandemic, should have an online component so that a wide
> audience can participate easily. It's not the same as an actual offline
> presence, but it's better than nothing at all.

Hybrid events are probably quite difficult to organise, but others with
more knowledge on the topic have already spoken up. What we could do in
any case, lockdown or not, is provide for *both* online events such as
this one and, once it is possible again, offline/hybrid events.

Thanks to Julien and Simon for all the work they have invested and to
Fosshost for hosting the videoconference.

Andreas

Re: Thank you for participating in the Guix Day!

[Leo Famulari]

On Thu, Nov 26, 2020 at 03:42:02PM +0100, raingloom wrote:
> Since people reported everyone turning their cameras on significantly
> degrading performance, that is unlikely to be an accurate analogy.
> My guess is that it's more similar to watching N simultaneous streams,
> where N is the number of people with active webcams.

Again, I don't know the architecture of BBB, but the "right way" to
handle multiple streams is for the server to reduce the bitrate of each
stream so that the overall bitrate is constant.

I recommend checking if IceCat is using hardware accelerated encoding.

Re: Why is BigBlueButton slow on GuixSystem (was: Re: Thank you for participating in the Guix Day!)

[Leo Famulari]

On Thu, Nov 26, 2020 at 12:32:07PM +0100, Jonathan Brielmaier wrote:
> In video conferencing clients need to do video encoding (when they use
> their webcam) as well as video decoding in real time. This can be pretty
> resource hungry (CPU) especially when there is no proper HW acceleration
> by the GPU.

Right, hardware accelerated codecs are assumed in 2020. Even the
cheapest mobile phone can do it. It'simply not practical to do in
software real-time without very powerful computers and efficient
implementations.

Re: Thank you for participating in the Guix Day!

[raingloom]

On Wed, 25 Nov 2020 23:17:57 -0500
Leo Famulari  wrote:

> On Wed, Nov 25, 2020 at 11:31:53PM +0100, raingloom wrote:
> > Oh yea, regarding that, I really think it would have made a whole
> > lot more sense if people just sent in a photo, instead of DDoS-ing
> > the network.  
> 
> I don't know how BBB works nor did I measure it, but one can expect a
> videochat feed to require basically the same amount of bandwidth as
> watching a Youtube video.

Since people reported everyone turning their cameras on significantly
degrading performance, that is unlikely to be an accurate analogy.
My guess is that it's more similar to watching N simultaneous streams,
where N is the number of people with active webcams.

Re: Xen hypervisor

[Jan Nieuwenhuizen]

Danny Milosavljevic writes:

> Hi Janneke,
>
> with our (gnu bootloader grub) already supporting multiboot, it would be easy
> for us to add official support for the Xen hypervisor & Linux.
>
> I've already packaged xen and it's ready to be used.
>
> In order to boot Xen, the grub config should read something like this:

Nice; this could help a lot with hurd work, notably 64bit/x86_64 and SMP
work, IIUC.

> Note especially that "multiboot" is "/xen-4.1-amd64.gz", and that "module"
> statements are used for the linux kernel and for the initrd.

OK.

> The work you have been doing for the Hurd already fetches both the "multiboot"
> and the "module" parameters from the boot-parameters via
> boot-parameters->menu-entry.
>
> But I can't find how I can set the multiboot-modules in my operating-system
> definition.

Yes,..currently, you only can if you're "hurd":

gnu/system.scm has:
--8<---cut here---start->8---
(define (boot-parameters->menu-entry conf)
  (let* ((kernel (boot-parameters-kernel conf))
 (multiboot-modules (boot-parameters-multiboot-modules conf))
 (multiboot? (pair? multiboot-modules)))
--8<---cut here---end--->8---

and

--8<---cut here---start->8---
(define (operating-system-multiboot-modules os)
  (if (operating-system-hurd os) (hurd-multiboot-modules os) '()))
--8<---cut here---end--->8---

> Like,
>
> (operating-system
>   (kernel (file-append xen "/boot/xen.gz"))
>   (multiboot-modules (list linux-libre initrd)))

Yes, we need some an indirection.  There already is

--8<---cut here---start->8---
(define (hurd-multiboot-modules os)
  (let* ((hurd (operating-system-hurd os))
 (root-file-system-command
  (list (file-append hurd "/hurd/ext2fs.static")
"ext2fs"
"--multiboot-command-line='${kernel-command-line}'"
"--host-priv-port='${host-port}'"
"--device-master-port='${device-port}'"
"--exec-server-task='${exec-task}'"
"--store-type=typed"
"--x-xattr-translator-records"
"'${root}'" "'$(task-create)'" "'$(task-resume)'"))
...
--8<---cut here---end--->8---

> Also, how do I get guix's usual initrd into that multiboot-modules list ?

Yes, that's another thing that would need to change, if you look at

gnu/bootloader/grub.scm has:
--8<---cut here---start->8---
(define* (grub-configuration-file config entries
...
  (if linux
  (let ((arguments (menu-entry-linux-arguments entry))
  ...
  (let ((kernel (menu-entry-multiboot-kernel entry))
  ...
--8<---cut here---end--->8---

we don't do multiboot when we're doing linux.

> Do you think it would make sense to adapt boot-parameters->menu-entry
> slightly so one could specify both a multiboot kernel and a linux kernel
> at the same time?  Or would that be too magical?

Hmm, I'd have to see the patch ;-)  We need a parameterisation, not sure
if splitting case LINUX in two is preferrable over a third flavor.

HTH!

Greetings,
Janneke

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Xen hypervisor

[Danny Milosavljevic]

Hi Janneke,

with our (gnu bootloader grub) already supporting multiboot, it would be easy
for us to add official support for the Xen hypervisor & Linux.

I've already packaged xen and it's ready to be used.

In order to boot Xen, the grub config should read something like this:

menuentry 'Guix with Xen Hypervisor' --class gnu-linux --class gnu --class os 
--class xen {
insmod part_msdos
insmod ext2
set root='(hd0,msdos1)'
search --no-floppy --fs-uuid --set=root 
c4291ab1-d3ad-4c70-ab97-e6c8cca0af2b
echo'Loading Xen 4.1-amd64 ...'
multiboot   /xen-4.1-amd64.gz placeholder  
echo'Loading Linux 3.10-3-amd64 ...'
module  /vmlinuz-3.10-3-amd64 placeholder root=/dev/mapper/disks-root 
ro resume=/dev/mapper/disks-swap quiet
echo'Loading initial ramdisk ...'
module  /initrd.img-3.10-3-amd64
}

Note especially that "multiboot" is "/xen-4.1-amd64.gz", and that "module"
statements are used for the linux kernel and for the initrd.

The work you have been doing for the Hurd already fetches both the "multiboot"
and the "module" parameters from the boot-parameters via
boot-parameters->menu-entry.

But I can't find how I can set the multiboot-modules in my operating-system
definition.

Like,

(operating-system
  (kernel (file-append xen "/boot/xen.gz"))
  (multiboot-modules (list linux-libre initrd)))

(Or find where it is set for the Hurd in the first place)

Also, how do I get guix's usual initrd into that multiboot-modules list ?

Do you think it would make sense to adapt boot-parameters->menu-entry
slightly so one could specify both a multiboot kernel and a linux kernel
at the same time?  Or would that be too magical?


pgpt98dAuBgGF.pgp
Description: OpenPGP digital signature

Why is BigBlueButton slow on GuixSystem (was: Re: Thank you for participating in the Guix Day!)

[Jonathan Brielmaier]

On 25.11.20 19:24, Leo Famulari wrote> On Wed, Nov 25, 2020 at
06:50:41PM +0100, Michael Rohleder wrote>> Browser is icecat
78.5.0-guix0-preview1 with all extensions disabled,>> except
"Surfingkeys". Computer is something like this (neofetch):> > [...]>
> Hm... it seems unlikely that this computer, which is relatively>
powerful, couldn't handle it. I suspect a bug in the browser.
My educated guess would go more into the decoding with/without hardware
acceleration topic.

In video conferencing clients need to do video encoding (when they use
their webcam) as well as video decoding in real time. This can be pretty
resource hungry (CPU) especially when there is no proper HW acceleration
by the GPU.

Don't make the mistake to compare to YouTube. It's a different situation
because Google does (almost) everything possible to make the decoding
less demanding for the clients. That's not so easy when you do real time
encode+decode.

According to their FAQ[0] 1Mbit/s download and 0,5Mbit/s upload are
recommended.

For audio they seem to use OPUS and VP8 for video with fallback on h264
(not sure if enabled by default).

BBB uses WebRTC quite heavily, maybe that is the key problem. It can be
tested via [1][2].

On Guix System my Firefox has set following params in about:config:
```
gfx.blacklist.webrtc.hw.acceleration.decode.failureid ->
FEATURE_FAILURE_GLXTEST_FAILED
gfx.blacklist.webrtc.hw.acceleration.encode.failureid -> FEATURE...
gfx.blacklist.webrtc.hw.acceleration.h264.failureid -> FEATURE...
```

Maybe VA-API can help[3]...

So far from me
Jonathan

[0]
https://docs.bigbluebutton.org/support/faq.html#what-are-the-minimum-requirements-for-the-bigbluebutton-client
[1] https://test.webrtc.org.
[2] https://networktest.twilio.com/
[3]
https://mastransky.wordpress.com/2020/09/29/firefox-81-on-fedora-with-va-api-webrtc-and-x11/

Re: Building the web site is slow

[pelzflorian (Florian Pelz)]

On Mon, Nov 23, 2020 at 11:46:08PM +0100, pelzflorian (Florian Pelz) wrote:
> It is funny, when I try to profile via
> 
> cd ~/src/guix-artwork/website
> guix install -p haunt-profile guile-syntax-highlight guile-commonmark haunt
> LC_ALL=en_US.utf8 \
>  GUILE_LOAD_PATH=haunt-profile/share/guile/site/3.0:$GUILE_LOAD_PATH \
>  /gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2/bin/guile
> scheme@(guile-user)> ,profile ((@ (haunt ui) haunt-main) "haunt" "build")
> 
> it crashes, but only when using ,profile.  I will investigate
> tomorrow.

The crash is prevented by deleting ~/.cache/guile and additionally
launching guile with --no-auto-compile.  I wonder if a compiled file
even had the right translation or if the macro-expanded translation
would be part of the compiled file.

The profile log is attached.  I will investigate next week.

Regards,
Florian
build completed successfully
% cumulative   self 
time   seconds seconds  procedure
  8.75 59.50 54.85  anon #x85c3d0
  6.54 41.02 40.98  anon #x863de0
  6.22 38.97 38.97  ice-9/eval.scm:123:11
  4.71 29.55 29.52  ice-9/eval.scm:333:13
  3.03 19.02 19.02  ice-9/eval.scm:182:7
  3.00 18.86 18.79  anon #x861cb8
  2.52   8908.74 15.76  ice-9/eval.scm:292:11
  2.31 14.49 14.49  ice-9/eval.scm:604:6
  2.26 15.57 14.18  anon #x862858
  2.16 13.60 13.56  anon #x85d560
  1.97 84.71 12.36  ice-9/format.scm:39:0:format
  1.82 58.99 11.39  ice-9/format.scm:113:2:format:format-work
  1.67   1186.44 10.46  ice-9/eval.scm:159:9
  1.58  9.88  9.88  anon #x866cf4
  1.43  8.95  8.95  ice-9/eval.scm:124:11
  1.37  8.56  8.56  anon #x85d978
  1.34  8.41  8.41  ice-9/eval.scm:273:7
  1.34  8.75  8.37  ice-9/psyntax.scm:749:8:search
  1.34  8.37  8.37  anon #x85bbb8
  1.32  8.29  8.29  ice-9/eval.scm:125:11
  1.30  8.13  8.13  anon #x863e88
  1.23941.87  7.71  ice-9/eval.scm:155:9
  1.13  7.09  7.09  ice-9/eval.scm:226:7
  1.11  6.97  6.97  anon #x85eef8
  1.05  7.32  6.58  ice-9/popen.scm:145:0:reap-pipes
  1.04  6.51  6.51  anon #x85d590
  0.99 15.46  6.20  ice-9/boot-9.scm:3128:0:module-gensym
  0.94  5.97  5.89  ice-9/eval.scm:339:13
  0.83  5.27  5.23  anon #x85e550
  0.79  4.92  4.92  anon #x85f8e8
  0.75  4.69  4.69  ice-9/eval.scm:282:4
  0.70 57.64  4.42  ice-9/eval.scm:259:9
  0.66  4.14  4.14  anon #x867250
  0.64   8397.56  3.99  ice-9/eval.scm:40:0:primitive-eval
  0.60  3.76  3.76  anon #x866590
  0.58  3.68  3.64  anon #x8661a0
  0.57  3.60  3.60  ice-9/eval.scm:222:7
  0.56191.31  3.52  ice-9/eval.scm:202:12
  0.56 10.42  3.49  ice-9/eval.scm:278:9
  0.53  3.29  3.29  anon #x862828
  0.51  3.18  3.18  ice-9/eval.scm:224:11
  0.49 22.12  3.10  ice-9/eval.scm:263:9
  0.49  3.06  3.06  anon #x85e520
  0.46  3.87  2.91  texinfo/string-utils.scm:98:5
  0.46  2.91  2.91  anon #x863f5c
  0.45  2.79  2.79  anon #x85bd88
  0.44 21.07  2.75  ice-9/psyntax.scm:855:4:resolve-identifier
  0.44  2.75  2.75  anon #x8670e8
  0.41  2.56  2.56  ice-9/eval.scm:126:12
  0.40  2.48  2.48  anon #x85d788
  0.39  2.44  2.44  anon #x85c91c
  0.38  2.36  2.36  anon #x8665c0
  0.38  2.36  2.36  anon #x8652d0
  0.37 35.75  2.32  ice-9/format.scm:759:2:format:out-obj-padded
  0.36208.28  2.25  ice-9/psyntax.scm:1527:8:rebuild-macro-output
  0.36  2.25  2.25  anon #x8665f0
  0.34  6.66  2.13  ice-9/eval.scm:159:9
  0.33  2.32  2.09  ice-9/eval.scm:417:6
  0.33  2.09  2.09  anon #x85e7c8
  0.32   2822.35  1.98  ice-9/eval.scm:618:6
  0.32  3.52  1.98  ice-9/eval.scm:259:9
  0.30  1.90  1.90  ice-9/eval.scm:329:11
  0.30  1.86  1.86  ice-9/boot-9.scm:1738:4:throw
  0.29  16781.40  1.82  ice-9/threads.scm:388:4
  0.29 63.45  1.82  ice-9/eval.scm:586:29
  0.29  1.82  1.82  anon #x866620
  0.28  1.74  1.74  anon #x85e798
  0.27  1.67  1.67  anon #x861978
  0.26 98.15  1.63  ice-9/psyntax.scm:1319:4:syntax-type
  0.26  5.11  1.63  ice-9/psyntax.scm:3001:6:match
  0.25  1.63  1.59  ice-9/eval.scm:336:13
  0.25  1.59  1.59  anon #x85c8b8
  0.25  1.55  1.55  anon #x866a78
  0.25  1.55  1.55  ice-9/eval.scm:590:16
  0.24 29.75  1.51  ice-9/psyntax.scm:2964:6:match*
  0.24  2.25  1.51  ice-9/eval.scm:263:9
  0.22  1.39  1.39  anon #x867780
  0.22  1.39  1.36  ice-9/boot-9.scm:3209:4
  0.22  1.36  1.36  srfi/srfi-1.scm:912:15
  0.21 10.73  1.32  ice-9/eval.scm:297:11
  0.20   2052.46  1.28  ice-9/boot-9.scm:253:2:for-each
  0.20  1.24  1.24  

[sr #110376] Creating an Emacs-Guix Git repository for Guix

[Ineiev]

Update of sr #110376 (project administration):

  Status:None => Need Info  
 Assigned to:None => ineiev 

___

Follow-up Comment #1:

What should be the description of the new repository?

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.nongnu.org/

Re: npm global prefix needs to be a writeable directory

[Jelle Licht]

Ryan Prior  writes:

> On November 26, 2020, Jelle Licht  wrote:
>> On other distros it defaults to a location that is not writable by
>> normal users either;
>
> Indeed I can confirm that Ubuntu node also has this problem.
>
>> Another way folks solved this problem has been using "nvm" which in
>> practice boiled down to [setting a
>> custom global prefix, just managed by nvm now].
>
> I think Guix should work more like nvm than like other distros in this
> case. If this is something we could handle automatically per-profile,
> then that gives us the opportunity to do the right thing and save the
> user some hassle.

As long as we don't change existing behaviour by ignoring custom global
prefixes explicitly requested by the user, this seems fine to me.

Do other language-specific package managers packaged in guix not run
into similar issues?

- Jelle