RE: good practices in science

[Konrad Hinsen]

bijan ghavami-kia  writes:

> It’s an interesting prospect, shouldn’t we be working towards this
> fantastical goal?

We (Guix) are already working towards the abstract goal of this project,
because what Guix does is effectively provenance tracking for
computations. Guix' package dependency graph is part of the public
knowledge graph.

If and how we could collaborate with the Underlay in a more
institutional and technical sense is an interesting question to think
about. One ingredient mentioned by Underlay is IPFS, with which Guix has
already made contact. And IPFS is looking into including git
repositories by providing CIDs for Git commits (though this doesn't seem
high-priority task). Guix is already connected to the Software Heritage
archive (two ways: Guix is archived there, and it can work with source
code from the archive), which is basically Git scaled up massively.

All that means that hooking up Guix with the Underlay is a pretty
straightforward endeavor from a technical point of view. It's mainly a
question of all interested parties agreeing on some form of
collaboration. So we are back to politics! Personally I'd love to see
this happen, and I'd definitely be willing to participate actively.

Cheers,
  Konrad

New Russian PO file for 'guix-manual' (version 1.1.0-pre1)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'guix-manual' has been submitted
by the Russian team of translators.  The file is available at:

https://translationproject.org/latest/guix-manual/ru.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

https://translationproject.org/latest/guix-manual/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

https://translationproject.org/domain/guix-manual.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Re: Syntax errors in latest guix-manual ru.po

[Pavlo Marianov]

I understood about @ref, @xref, etc.
So I fixed all those wrongly translated strings and uploaded to TP.

ср, 8 квіт. 2020 о 02:40 Julien Lepiller  пише:

> Le 7 avril 2020 16:17:49 GMT-04:00, "Ludovic Courtès"  a
> écrit :
> >Hi,
> >
> >Pavlo Marianov  skribis:
> >
> >>> doc/contributing.ru.texi:365: @url missing closing brace
> >
> >This one is:
> >
> >  CI-системой @url{@value{SUBSTITUTE-SERVER}.
> >   ^
> >Julien, do we need to do anything for the non-existent node names or is
> >there “something” that’ll take care of it?  (Somehow I can never
> >remember how that works.)
> >
> >Ludo’.
>
> You translate the menu and @node. You don't need to translate references
> like @ref, @xref or @pxref. The xref_command takes care of that (guix self)
> uses its own parser too. For references outside the guix manual, I use the
> English name too because they were not translated. It's ok to translate
> URLs to point to translated resources.
>

Re: Proxy settings wrt guix daemon

[Mathieu Othacehe]

Hello,

> BTW, if we agree, could you change these strings so we can do a last
> round through the TP and release Thursday/Friday?

Yes, I applied those changes and added proxy support. I'll try to see
how connman is behaving now.

Thanks,

Mathieu

Re: Syntax errors in latest guix-manual ru.po

[Ludovic Courtès]

Hi,

Pavlo Marianov  skribis:

> So I fixed all those wrongly translated strings and uploaded to TP.

The problem is still there:

--8<---cut here---start->8---
$ wget -qO - https://translationproject.org/latest/guix-manual/ru.po |grep 
'^msgstr.*@url{@value'
msgstr "Если ваш пакет собирается без ошибок, пришлите нам свой патч 
(@pxref{Submitting Patches}). Если вам нужна помощь, мы будем рады помочь вам 
со своей стороны. После фиксации патча в репозитории Guix новый пакет будет 
автоматически собран для всех поддерживаемых платформ нашей CI-системой 
@url{@value{SUBSTITUTE-SERVER}."
--8<---cut here---end--->8---

Or maybe there’s some delay somewhere?

Thanks,
Ludo’.

Re: Proxy settings wrt guix daemon

[Ludovic Courtès]

Hi Mathieu,

Mathieu Othacehe  skribis:

>> BTW, if we agree, could you change these strings so we can do a last
>> round through the TP and release Thursday/Friday?
>
> Yes, I applied those changes and added proxy support. I'll try to see
> how connman is behaving now.

That was fast!  It looks really good, this new parameters menu comes in
handy!

Ludo’.

New Russian PO file for 'guix-manual' (version 1.1.0-pre1)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'guix-manual' has been submitted
by the Russian team of translators.  The file is available at:

https://translationproject.org/latest/guix-manual/ru.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

https://translationproject.org/latest/guix-manual/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

https://translationproject.org/domain/guix-manual.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Re: Syntax errors in latest guix-manual ru.po

[Pavlo Marianov]

Ah, saw that problem. One '}' was missed.

ср, 8 квіт. 2020 о 13:35 Ludovic Courtès  пише:

> Hi,
>
> Pavlo Marianov  skribis:
>
> > So I fixed all those wrongly translated strings and uploaded to TP.
>
> The problem is still there:
>
> --8<---cut here---start->8---
> $ wget -qO - https://translationproject.org/latest/guix-manual/ru.po
> |grep '^msgstr.*@url{@value'
> msgstr "Если ваш пакет собирается без ошибок, пришлите нам свой патч
> (@pxref{Submitting Patches}). Если вам нужна помощь, мы будем рады помочь
> вам со своей стороны. После фиксации патча в репозитории Guix новый пакет
> будет автоматически собран для всех поддерживаемых платформ нашей
> CI-системой @url{@value{SUBSTITUTE-SERVER}."
> --8<---cut here---end--->8---
>
> Or maybe there’s some delay somewhere?
>
> Thanks,
> Ludo’.
>

Re: Guix System on a GCE VM -- Success

[Jelle Licht]

Hey there,

elaexuo...@wilsonb.com writes:

> To simplify the process I created a script capable of setting up a GCE 
> instance
> from a local qcow2 image, which I am also attaching. The script is intentially
> not a simple turnkey solution, since you should be somewhat familiar with the
> GCE infrastructure before using it. However, feel free to ask questions if
> anything is unclear.

This all looks pretty nifty! Just to be clear, under which license did
you make this script available?

Thanks!
- Jelle

Re: Guix System on a GCE VM -- Success

[Jonathan Brielmaier]

On 08.04.20 05:16, elaexuo...@wilsonb.com wrote:
> The boot problem fix boils down to this:
>
> (initrd-modules (cons "virtio_scsi" %base-initrd-modules))
>
> Referencing Google's documentation on operating system requirements [2], we 
> see
> that their VMs run with Virtio-SCSI controllers; however, it just so happens
> that the corresponding kernel module, virtio_scsi, is not included in the
> initrd by default. Would it make sense to change this default?

This had to been done on Hetzner Cloud as well. I wonder if its not
fixed already on master. Need to check that...

Re: Unencrypted boot with encrypted root

[Alex Griffin]

On Wed, Apr 8, 2020, at 7:57 AM, Pierre Neidhardt wrote:
> Do you have a working example of this for Guix?

Unfortunately not. I do have an old NixOS config[1] where I set things up like 
this, if what you're looking for is a proof-of-concept.

-- 
Alex Griffin

[1]: 
https://gitlab.com/ajgrf/dotfiles/-/blob/1e17dac3cda00af68772dc22731ac0880d280b9c/.nixpkgs/antares.nix

Re: Unencrypted boot with encrypted root

[Ellen Papsch]

Hi,

Am Dienstag, den 07.04.2020, 09:47 -0700 schrieb Vagrant Cascadian:
> On 2020-04-07, Alex Griffin wrote:
> > So we can put the key in its own initrd (outside of the store)
> > 
> 
> I believe it's also possible for grub to provide the key
> derived/decrypted from the passphrase entered at run-time
> 

These may be dangerous waters. The key file in initrd is like a house
key under the mattress. A malicious process could look in the well
defined place and exfiltrate the key. Think state trojan horses. A
random name would not suffice, because other characteristics may help
identifying the file (i.e. size).

Regarding passing on the key, you mean the master key? I don't know if
it's possible. If it's documented and recommended, I'd say go for it.
But keep in mind this is crypto we are talking about. If it's something
hacky we're straying from the path and may be inadvertently opening up
security holes. A security guru analysis would help.

I think* Guix would burden itself too much with secrets. It's something
for the user and the installer should just make it more convenient,
with a nudge to a more secure setup. The key file should be stored in a
user specified location, preferably a pen drive (which is otherwise not
used). It can be removed, so no read can occur by arbitrary processes.
A passphrase should be added as backup.

(*) as non-guru

With or without key on a drive, passing on the master key would help
avoiding waiting a second time for decryption. It would certainly be
nice if it's feasible.

Best regards

Re: Unencrypted boot with encrypted root

[Ellen Papsch]

Am Dienstag, den 07.04.2020, 22:19 +0200 schrieb Ludovic Courtès:
> Ellen Papsch  skribis:
> 
> 
> Sure, but what happens when you reconfigure?  You still need to have
> that file around so it can be added to the initrd.
> 

Does it really have to be added to initrd? From my other reply:

> These may be dangerous waters. The key file in initrd is like a house
> key under the mattress. A malicious process could look in the well
> defined place and exfiltrate the key. Think state trojan horses. A
> random name would not suffice, because other characteristics may help
> identifying the file (i.e. size).

> I think* Guix would burden itself too much with secrets. It's
> something for the user and the installer should just make it more
> convenient, with a nudge to a more secure setup. The key file should
> be stored in a user specified location, preferably a pen drive (which
> is otherwise not used). It can be removed, so no read can occur by
> arbitrary processes. A passphrase should be added as backup.
> 
> (*) as non-guru

reconfigure would not have to touch the file at all, if it were a user
supplied file name. I'm aware other files are often put in the store by
references in operating-system (or inlined). The secrets file on the
other hand should just be assumed to be there. Initrd should try to
mount the drive.

Best regards

Re: 01/02: services: Allow modprobe to use "/etc/modprobe.d".

[Brice Waegeneire]

Hello Bengt,

On 2020-04-06 09:29, Bengt Richter wrote:

On +2020-04-06 07:54:47 +, Brice Waegeneire wrote:

What's the issue with using /etc/modrpobe.d?


I would think the fundamental issue is pure vs impure dependencies:
i.e., /gnu/... vs /var/guix vs /elsewhere/...

IIUC, the consequence of using /etc/... or ~/... or other non-/gnu/...
is that if you want to run something in a container with chrooted root,
you have to cow-fake /etc and all the rest of non-/gnu/... environment,
so your executable is not as generally usable as possible if
nuisance adjustments were not necessary.

People who might want to use it anyway have to think about a bunch
of stuff not relevant to what they actually want to do -- they
will wind up debugging functionally-irrelevant implementation stuff.

Maybe I misunderstand, but are you and Ludo on the same page
re the fundamental concept of guix and how it plays in various 
contexts?
(allowing for "practicality beats purity"[1] when absolutely necessary 
;-)


Yes, only the reason why to do it was eluding me. I'll keep in mind your 
rule

thumb.

- Brice

Re: 01/02: services: Allow modprobe to use "/etc/modprobe.d".

[Brice Waegeneire]

Hello,

On 2020-04-07 09:35, Ludovic Courtès wrote:

Brice Waegeneire  skribis:

On 2020-04-05 21:15, Ludovic Courtès wrote:

guix-comm...@gnu.org skribis:
Looking at this, I was wondering if it would be possible to not use
/etc/modprobe.d and instead have a way to tell the modprobe wrapper 
to
pass “-C /gnu/store/…-modprobe.d”, which would contain the right 
thing.


Thoughts?


What's the issue with using /etc/modrpobe.d?


In general, use of the global file system name space isn’t great: it’s
ambiguous (compare to a /gnu/store reference) and doesn’t work well 
upon

rollback or reconfigure (things that refer to /etc end up referring to
the “new” /etc after reconfigure, even though that might not actually
work.)

Conversely, “-C /gnu/store/…-modprobe.d” unambiguously refers to the
intended directory.

WDYT?


It's good with me, I'll do as suggested -using the environment variable-
when implementing “kernel-module-configuratuion-service-type”.

- Brice

Re: Unencrypted boot with encrypted root

[Alex Griffin]

On Wed, Apr 8, 2020, at 12:25 PM, Ellen Papsch wrote:
> These may be dangerous waters. The key file in initrd is like a house
> key under the mattress. A malicious process could look in the well
> defined place and exfiltrate the key. Think state trojan horses. A
> random name would not suffice, because other characteristics may help
> identifying the file (i.e. size).

What's the threat model here? For me, an encrypted disk is only meant to 
protect my data at rest. If a malicious process is already running on my system 
as root, then I don't care if they can exfiltrate the key.

-- 
Alex Griffin

Re: Unencrypted boot with encrypted root

[Vagrant Cascadian]

On 2020-04-08, Ellen Papsch wrote:
> Am Dienstag, den 07.04.2020, 09:47 -0700 schrieb Vagrant Cascadian:
>> On 2020-04-07, Alex Griffin wrote:
>> > So we can put the key in its own initrd (outside of the store)
>> > 
>> 
>> I believe it's also possible for grub to provide the key
>> derived/decrypted from the passphrase entered at run-time
>> 
>
> These may be dangerous waters. The key file in initrd is like a house
> key under the mattress. A malicious process could look in the well
> defined place and exfiltrate the key. Think state trojan horses. A
> random name would not suffice, because other characteristics may help
> identifying the file (i.e. size).

The key for a LUKs volume is exposed in the running kernel and a
compromised root account can exfiltrate it... 


> Regarding passing on the key, you mean the master key? I don't know if
> it's possible. If it's documented and recommended, I'd say go for it.
> But keep in mind this is crypto we are talking about. If it's something
> hacky we're straying from the path and may be inadvertently opening up
> security holes. A security guru analysis would help.

It would reduce the attack surface by not asking for the passphrase
twice. You *have* to to it once from grub (presuming encrypted /boot),
so it's simply re-using the unlocked key...


> I think* Guix would burden itself too much with secrets. It's something
> for the user and the installer should just make it more convenient,
> with a nudge to a more secure setup. The key file should be stored in a
> user specified location, preferably a pen drive (which is otherwise not
> used). It can be removed, so no read can occur by arbitrary processes.
> A passphrase should be added as backup.

No need to store the key file in anything but ephemeral ram, ideally
where it wouldn't be swapped to disk, in the running kernel...


I'll look into the actual implementation of what I'm talking about
rather than rambling on further about theoretical possibilities.


live well,
  vagrant


signature.asc
Description: PGP signature

MIPS support

[Christopher Baines]

Hey,

I was wondering about MIPS support, mainly because the Guix Data Service
uses QEMU to emulate different systems so that the channel instance
derivations can be computed (like [1]). I'm not sure if the emulation is
really necessary, but that's how it works at the moment.

1: 
http://data.guix.gnu.org/revision/198571b264547f800803e554c8f21a9c95be959c/channel-instances

I've not enabled the QEMU emulation for MIPS on data.guix.gnu.org,
because I've never managed to get it working locally. Computing the
channel derivation starts building lots of things, but something always
fails.

I've looked in to this a bit more. On master, the bison-boot0 package
tries to do the build and tests in parallel, and
fails. This is fixed on core-updates. If you work around the bison-boot0
issue on master, then I get a segfault during gcc-cross-boot0-7.4.0:

g++ -fno-PIE -c  -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -g -O2 -DIN_GCC  
-DCROSS_DIRECTORY_STRUCTURE   -fno-exceptions -fno-rtti 
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings 
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic 
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H 
-I. -Ic-family -I../../gcc-7.4.0/gcc -I../../gcc-7.4.0/gcc/c-family 
-I../../gcc-7.4.0/gcc/../include -I../../gcc-7.4.0/gcc/../libcpp/include 
-I/tmp/guix-build-gcc-cross-boot0-7.4.0.drv-0/build/./gmp 
-I/tmp/guix-build-gcc-cross-boot0-7.4.0.drv-0/gcc-7.4.0/gmp 
-I/tmp/guix-build-gcc-cross-boot0-7.4.0.drv-0/build/./mpfr/src 
-I/tmp/guix-build-gcc-cross-boot0-7.4.0.drv-0/gcc-7.4.0/mpfr/src 
-I/tmp/guix-build-gcc-cross-boot0-7.4.0.drv-0/gcc-7.4.0/mpc/src  
-I../../gcc-7.4.0/gcc/../libdecnumber -I../../gcc-7.4.0/gcc/../libdecnumber/dpd 
-I../libdecnumber -I../../gcc-7.4.0/gcc/../libbacktrace   -o 
c-family/c-common.o -MT c-family/c-common.o -MMD -MP -MF 
c-family/.deps/c-common.TPo ../../gcc-7.4.0/gcc/c-family/c-common.c
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
g++: internal compiler error: Segmentation fault (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[2]: *** [Makefile:1099: c-family/c-common.o] Error 4
make[2]: Leaving directory 
'/tmp/guix-build-gcc-cross-boot0-7.4.0.drv-0/build/gcc'
make[1]: *** [Makefile:4215: all-gcc] Error 2
make[1]: Leaving directory '/tmp/guix-build-gcc-cross-boot0-7.4.0.drv-0/build'
make: *** [Makefile:881: all] Error 2
command "make" "-j" "1" 
"LDFLAGS=-Wl,-rpath=/gnu/store/z2i5vj66b6y23v8fywsf7bwnppyhssks-glibc-bootstrap-0/lib
 -Wl,-dynamic-linker 
-Wl,/gnu/store/z2i5vj66b6y23v8fywsf7bwnppyhssks-glibc-bootstrap-0/lib/ld.so.1" 
failed with status 2
builder for 
`/gnu/store/dzgvjam38vn7i7d1iml2a34p5h3lyggd-gcc-cross-boot0-7.4.0.drv' failed 
with exit code 1
build of /gnu/store/dzgvjam38vn7i7d1iml2a34p5h3lyggd-gcc-cross-boot0-7.4.0.drv 
failed


On core-updates, it's pretty similar. The gcc-cross-boot0-7.5.0
derivation seems to hang at the same point the gcc-cross-boot0-7.4.0
derivation segfaulted:

g++ -fno-PIE -c  -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -g -O2 -DIN_GCC  
-DCROSS_DIRECTORY_STRUCTURE   -fno-exceptions -fno-rtti 
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings 
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic 
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H 
-I. -Ic-family -I../../gcc-7.5.0/gcc -I../../gcc-7.5.0/gcc/c-family 
-I../../gcc-7.5.0/gcc/../include -I../../gcc-7.5.0/gcc/../libcpp/include 
-I/tmp/guix-build-gcc-cross-boot0-7.5.0.drv-0/build/./gmp 
-I/tmp/guix-build-gcc-cross-boot0-7.5.0.drv-0/gcc-7.5.0/gmp 
-I/tmp/guix-build-gcc-cross-boot0-7.5.0.drv-0/build/./mpfr/src 
-I/tmp/guix-build-gcc-cross-boot0-7.5.0.drv-0/gcc-7.5.0/mpfr/src 
-I/tmp/guix-build-gcc-cross-boot0-7.5.0.drv-0/gcc-7.5.0/mpc/src  
-I../../gcc-7.5.0/gcc/../libdecnumber -I../../gcc-7.5.0/gcc/../libdecnumber/dpd 
-I../libdecnumber -I../../gcc-7.5.0/gcc/../libbacktrace   -o 
c-family/c-common.o -MT c-family/c-common.o -MMD -MP -MF 
c-family/.deps/c-common.TPo ../../gcc-7.5.0/gcc/c-family/c-common.c


From htop, I can see the QEMU emulated g++ with a QEMU emulated cc1plus
subprocess, but nothing is happening.

Any ideas?

Thanks,

Chris


signature.asc
Description: PGP signature

[BLOG] A "Hello World" VM running the Hurd!

[Jan Nieuwenhuizen]

Hi!

We have just published a new blog post---a follow-up, in a way to last
week's April 1 post---about some real achievement: Using Guix we have
cross-built a VM image for the Hurd.  Read more...


https://guix.gnu.org/blog/2020/a-hello-world-virtual-machine-running-the-hurd/

Enjoy!
Janneke & Ludovic

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

Re: [BLOG] A "Hello World" VM running the Hurd!

[Samuel Thibault]

Jan Nieuwenhuizen, le mer. 08 avril 2020 22:02:25 +0200, a ecrit:
> We have just published a new blog post---a follow-up, in a way to last
> week's April 1 post---about some real achievement: Using Guix we have
> cross-built a VM image for the Hurd.  Read more...
> 
> 
> https://guix.gnu.org/blog/2020/a-hello-world-virtual-machine-running-the-hurd/

Nice!!

Samuel

Re: [BLOG] A "Hello World" VM running the Hurd!

[Arne Babenhauserheide]

Jan Nieuwenhuizen  writes:

> We have just published a new blog post---a follow-up, in a way to last
> week's April 1 post---about some real achievement: Using Guix we have
> cross-built a VM image for the Hurd.  Read more...
>
> 
> https://guix.gnu.org/blog/2020/a-hello-world-virtual-machine-running-the-hurd/

Wow, that’s awesome!

Thank you!

Best wishes,
Arne

PS: typo: fine-grain → fine-grained
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken

Re: [BLOG] A "Hello World" VM running the Hurd!

[Samuel Thibault]

Jan Nieuwenhuizen, le mer. 08 avril 2020 22:02:25 +0200, a ecrit:
> Using Guix we have cross-built a VM image for the Hurd.  Read more...
> 
> 
> https://guix.gnu.org/blog/2020/a-hello-world-virtual-machine-running-the-hurd/

It would be nice to have this in a CI, and report when it breaks, so we
catch that as early as possible when pushing stuff upstream :)

Samuel

Re: MIPS support

[Leo Famulari]

On Wed, Apr 08, 2020 at 08:32:00PM +0100, Christopher Baines wrote:
> I was wondering about MIPS support, mainly because the Guix Data Service
> uses QEMU to emulate different systems so that the channel instance
> derivations can be computed (like [1]). I'm not sure if the emulation is
> really necessary, but that's how it works at the moment.

I'm not sure if the MIPS port ever resumed after being suspended:

https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00790.html

Jami: Bug source investigation

[Jan]

Hello,

so I tested Jami on core-updates and it didn't fix the bug
(https://git.jami.net/savoirfairelinux/jami-packaging/issues/63)

Here's my work up to now, it is on wip-jami branch:
https://gitlab.com/kromka_chleba/jami-package-and-other-things-for-guix/-/tree/wip-jami
https://gitlab.com/kromka_chleba/jami-package-and-other-things-for-guix.git

What happens is when making an audio call and then pressing the red
"disconnect" button, Jami daemon (dring) stops with the following
message:

dring: ../src/pjsip-ua/sip_inv.c:246: pjsip_inv_dec_ref: Assertion `inv
&& inv->ref_cnt' failed.

This issue is related to pjproject (https://www.pjsip.org/) - the
library implementing SIP, and patches Jami developers apply to it,
which can be found in ring-project/daemon/contrib/src/pjproject/.

I need help of someone experienced to investigate what is the
difference that makes our package crash, that doesn't occur on other
distributions. If we find out, we will hand it to Jami developers
so they can fix it.

Running daemon in the debugging mode:

/lib/ring/dring -pcd

Jami is built on debian 10, fedora 31, ubuntu 19.10 using GCC with
scripts written in python and bash located in ring-project/make-ring.py
and ring-project/scripts.

The source packages are available here:
https://dl.jami.net/release/tarballs/

And the binaries that don't suffer from the bug are here:
https://dl.jami.net/nightly/



Jan Wielkiewicz

Re: Guix System on a GCE VM -- Success

[Development of GNU Guix and the GNU System distribution.]

> This all looks pretty nifty! Just to be clear, under which license did
> you make this script available?

Ouch. That was a major oversight. Thanks for bringing this up!
I went ahead and put it under the BSD-3-CLAUSE. Attached is the same source
with a copyright notice and license header.



signature.asc
Description: PGP signature

Re: Guix System on a GCE VM -- Success

[elaexuotee]

elaexuotee--- via "Development of GNU Guix and the GNU System distribution." 
 wrote:
> > This all looks pretty nifty! Just to be clear, under which license did
> > you make this script available?
> 
> Ouch. That was a major oversight. Thanks for bringing this up!
> I went ahead and put it under the BSD-3-CLAUSE. Attached is the same source
> with a copyright notice and license header.


It looks like I messed up the attachment. Trying again.

#!/usr/bin/env sh
set -o errexit -o noclobber -o nounset

# Copyright (c) 2020 elaexuo...@wilsonb.com. All rights reserved.
#
# Licensed under 
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions are met:
#
# 1. Redistributions of source code must retain the above copyright notice,
#this list of conditions and the following disclaimer.
#
# 2. Redistributions in binary form must reproduce the above copyright notice,
#this list of conditions and the following disclaimer in the documentation
#and/or other materials provided with the distribution.
#
# 3. Neither the name of the copyright holder nor the names of its contributors
#may be used to endorse or promote products derived from this software
#without specific prior written permission.
#
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
# CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
# POSSIBILITY OF SUCH DAMAGE.


## GCE Custom Image
#
# This script intends to be "executable documention" for the process of setting
# up a Google Compute Engine (GCE) virtual machine from a custom image.


usage() {
cat <<-USAGE
Usage: $(basename "${0}") [options]  [ [..]]

This script aids in setting up Google Compute Engine with an instance
running a custom image.

Execute commands in order provided at the command line. The procedure
for a fresh setup follows the order listed below in Status Commands.

Setup Commands:
  mkconf  Configure files on raw image partition
  mkraw   Convert image to raw format
  mksize  Grow image to integer multiple of GBs
  mktar   Archive raw image
  mkgsb   Create GS bucket

  togsa   Upload archive to GS bucket
  togci   Create GCE image from GS archive
  togvm   Create GCE instance from GCE image

Status Commands:
  ckconf  Check contents of qcow2 image
  ckraw   Check integrity of raw image
  cksize  Check size of raw image
  cktar   Check contents of tar archive
  ckgsb   Check existence of GS bucket
  ckgsa   Check existence of tar archive in GS bucket
  ckgci   Check existence of GCE image
  ckgvm   Check status of GCE instance

  ttysro  View GCE instance's serial output
  ttysrw  Connect to instance serial port

Removal Commands:
  rmgvm   Remove GCE instance
  rmgci   Remove GCE image
  rmgsa   Remove archive from GS bucket
  rmgsb   Remove GS bucket

Metainfo Commands:
  helpShow this help message
  varsPrint value of configuration variables

Options:
  -f  Family name for GCE image
  -v Version string of GCE image
  -nName of GCE image

  -NName of GCE instance
  -s  Subnet name of GCE instance
  -mMachine type of GCE instance

  -B URI of GS bucket
  -A URI of GS tar file

  -p  Partition of image on which / resides
  -S  Serial port of GCE instance

  -bCommon path base for files and names
  -gPath on image of grub.cfg
  -iLocal path of source image file
  -rLocal path of raw image file
  -aLocal path of tar file

  -h  Show this help message
USAGE
}

fail() {
msg=${1}; errno=${2-1}

>&2 printf 'Error: %s\n' "${msg}"
>&2 usage
exit "${errno}"
}

show_vars()