Re: time-machine broken from 2019-04-07 to 2019-05-04

[Konrad Hinsen]

zimoun  writes:

> What should be the fix?
> Because it is annoying to be dependent of upstream bad practise.
>
> Well, is it fixable?

The root cause of the problem is the mutability of URLs. The solution is
to move on to immutable references. Such as git commits.

My impression is that tarballs are the preferred source code reference
used in Guix today, with git commits used only when there is no release
tarball. Is that an official policy, or just historical accident?
If a policy, what's the reason for it?

Cheers,
  Konrad.

Re: time-machine broken from 2019-04-07 to 2019-05-04

[zimoun]

Hi Konrad,

On Mon, 17 Feb 2020 at 10:48, Konrad Hinsen  wrote:
>
> zimoun  writes:
>
> > What should be the fix?
> > Because it is annoying to be dependent of upstream bad practise.
> >
> > Well, is it fixable?
>
> The root cause of the problem is the mutability of URLs. The solution is
> to move on to immutable references. Such as git commits.

I agree. It is more or less an implicit rule in Guix: 'git-fetch' is
preferable than 'url-fetch' when possible.
Moreover, by using "git" origin, it is easier to archive in SWH; "guix
lint" does that. :-)


> My impression is that tarballs are the preferred source code reference
> used in Guix today, with git commits used only when there is no release
> tarball. Is that an official policy, or just historical accident?
> If a policy, what's the reason for it?

The current fix is to have the correct copy on ci.guix.gnu.org.

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39575#32


Well, Guix will export soon all the sources ('origin') of its packages
in JSON file (the patch still needs minor tweaks), then SWH could
ingest and archive. It is a join task with Nix: the SWH crawler is
written by lewo and it already seems working for the type 'url'; soon
the type 'git' (or 'svn', 'hg', etc.).

Therefore, the future should be fixed. ;-)
The past is not yet... because there is no guarantee that all the
upstreams are still reachable... and/or archived. Probably a TODO item
for the Guix Data Service. ;-)

https://lists.gnu.org/archive/html/guix-devel/2020-02/msg00233.html


Cheers,
simon

Re: Notes from the Guix Days

[Pierre Neidhardt]

I've pushed notes on the perfect setup.
Lots of work to do there, contributions to Geiser and a non-Emacsy setup
are welcome! :)

-- 
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Description: PGP signature

Re: Port Guix to my Apple Aluminum PowerBook G4

[Scott C. MacCallum]

Wow! Great work.

Sent from ProtonMail mobile

 Original Message 
On Feb 17, 2020, 2:07 AM, Efraim Flashner wrote:

> I've done a bit of work on the port and my two branches live here¹ and here². 
> On master I get as far as gcc-cross-boot0. Core-updates does much better, 
> getting to glibc-intermediate, where it fails to build since it says it can't 
> find nptl. Searching the Guix tree I see that there's some references to nptl 
> in (gnu packages commencement) and in a glibc-2.29-git-updates.patch, so I'll 
> take a look at that. ¹ https://gitlab.com/Efraim/guix/-/tree/ppc-master ² 
> https://gitlab.com/Efraim/guix/-/tree/ppc-core-updates -- Efraim Flashner  
> אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 
> Confidentiality cannot be guaranteed on emails sent or received unencrypted

Guix-HPC Activity Report, 2018–2019

[Ludovic Courtès]

Hello!

On behalf of the whole team of Guix folks doing HPC, I’m happy to
announce our annual report:

  https://hpc.guix.info/blog/2020/02/guix-hpc-activity-report-2019/

Spread the word!  :-)

Ludo’.


signature.asc
Description: PGP signature

Using the Hetzner Cloud

[Jonathan Brielmaier]

Hi folks,

as promised on the Guix Days in Bruxelles I asked Hetzner[0] if they
could provide us some free VMs in their cloud[1].

A few days ago they came back go to me. Sadly they can't provide us free
VMs, but they will give us 30 EUR credit for the first month.

As they bill hour-wise and offer a serial console over HTTPS, you can do
tests for stuff like the installer for 2 or 3 cents :)

What do you think about it?

~Jonathan

P.S: I encourage you to ask your local/well-known hosting provider for
some support in any way for Guix. It's not so much effort.

[0] https://www.hetzner.de/ big German hosting company
[1] https://www.hetzner.de/cloud

Re: patch-shebang and Rust - Change on core-updates?

[Danny Milosavljevic]

Hi,

okay, I've done that in guix in branch core-updates,
commit 88f85494491a0cd4d4262c97860f01e99c2bc313.


pgpGjnB8VKAIk.pgp
Description: OpenPGP digital signature

Maintaining Jami #4

[Jan]

Hello,
Sorry for the delay with Jami, but I lost access to my repository and
must make a new one. I'm also waiting for the developer responsible
for updating pjproject in Jami to update pjproject - he's on holidays
till the end of Feb. Waiting for core-updates to be merged too, in order
to check if the outdated glibc is a problem with one crash.
When will be the 1.1.0 version of Guix released?
The good news is pjproject 2.10 is out fixing many crashes.

Anyone knows how to upload git repository with Guix to Gitlab?


Jan Wielkiewicz

Re: Maintaining Jami #4

[Pierre Neidhardt]

Jan  writes:

> Anyone knows how to upload git repository with Guix to Gitlab?

What do you mean?  Can you provide an example?

-- 
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Description: PGP signature

Re: New build system: copy-build-system

[Jesse Gibbons]

On Mon, 2020-02-17 at 08:56 +0100, Pierre Neidhardt wrote:
>   Error verifying signature: Failed to execute gpg.
> Hi Jesse,
> 
> thanks for sharing, I'll include it with the patch then.
> 
> > Since I'm patching one of the scripts to play better with guix, the
> > source will become a tarball. I would rather not worry about
> > extracting
> > everything, moving some things, and deleting what is not used.
> 
> What do you mean with this?
> 
Sorry if I confused you.

The package I shared will need to be adjusted because I'm not sure how
to configure the copy-build-system. It was also in an early stage, and
the source itself will need some changes for the package to work. I
only sent it to help you test copy-build-system, since you asked for
suggestions.

The package as I sent it, even if changed to use the copy-build-system, 
is not ready to be sent to to guix because it will not find java or the
clojure jar built by guix. I already have a patch to correct this, and
intend to send it with the rest of the package when I can call
"clojure" from bash in an pure environment with the clojure package and
enter a clojure repl.

IIUC, copy-build-system is based on gnu-build-system, so it should work
the same with tarballs and directories. That means it should be a time
saver; I won't need to worry about changing things if I need to add a
patch to make a package work with what guix does. Thank you so much for
this build system :)

-Jesse

Re: Using the Hetzner Cloud

[Ellen Papsch]

Hi,

Am Montag, den 17.02.2020, 14:47 +0100 schrieb Jonathan Brielmaier:
> Hi folks,
> 
> as promised on the Guix Days in Bruxelles I asked Hetzner[0] if they
> could provide us some free VMs in their cloud[1].
> 
> A few days ago they came back go to me. Sadly they can't provide us
> free
> VMs, but they will give us 30 EUR credit for the first month.
> 
> As they bill hour-wise and offer a serial console over HTTPS, you can
> do
> tests for stuff like the installer for 2 or 3 cents :)
> 
> What do you think about it?
> 
> ~Jonathan
> 

a few days ago I requested the Guix installer from Hetzner as well. I
gave them the ISO URL from Guix website. They mounted it without
modification, which prevented boot due to the image being compressed. I
had to supply the uncompressed image, which booted fine.

The installer was not able to install right away. I could complete all
the GUI steps. When it came to guix system init, it bailed with the
message that an initrd-module may be missing. System init (and the
subsequent boot) worked fine with:

(initrd-modules (append (list "virtio_pci"
  "virtio_scsi")
%base-initrd-modules))

BTW, the VGA console is very limited, you can't select text or send
special key strokes, e.g. control keys. It suffices for activating SSH
though :-)

Hetzner added the image only for me, which is a hindrance for Guix
adoption. Another limitation is that I can't create new servers right
away without going through installation. I can dance around it by
creating a snapshot of a template server and creating the new server
from that snapshot, then reconfiguring the system (or doing a deploy, I
want to try that yet).

So, doing Guix is a little more inconvenient than a simple, plain
Debian. I can still recommend it, though you may find Hetzner not
meeting your demands in general: The cloud offerings have a rather low
cpu/memory ratio (0.25 cpu/1G RAM) and it's not configurable.

Best regards
Ellen

Re: Maintaining Jami #4

[Jan Wielkiewicz]

On Mon, 17 Feb 2020 17:46:39 +0100
Pierre Neidhardt  wrote:

> What do you mean?  Can you provide an example?
> 
For example on notabug there was an option to make a mirror of existing
repository, so I just pasted there:
"https://git.savannah.gnu.org/git/guix.git"; 
and it made a mirror I could work with.
On gitlab I didn't see such an option, so I just initialized a fresh
git repository and I would like to replace this repository with my
clone of Guix with Jami changes.


Jan Wielkiewicz

Re: Using the Hetzner Cloud

[Alex Sassmannshausen]

Hello,

Ellen Papsch  writes:

> Hi,
>
> Am Montag, den 17.02.2020, 14:47 +0100 schrieb Jonathan Brielmaier:
>> Hi folks,
>> 
>> as promised on the Guix Days in Bruxelles I asked Hetzner[0] if they
>> could provide us some free VMs in their cloud[1].
>>
>> […]
>> 
>> What do you think about it?
>> 
>> ~Jonathan
>> 
>
> a few days ago I requested the Guix installer from Hetzner as well. I
> […]
> cpu/memory ratio (0.25 cpu/1G RAM) and it's not configurable.
>
> Best regards
> Ellen

Figured I might as well add my experiences.

I originally have done the same thing as you did Ellen.  This was a bit
of a slow process for deploying Guix to Hetzner servers though.

Now I use a different approach: deploy a debian server then use a
guix-infect style script (gleaned from the guix deploy code for digital
ocean).

So I deploy debian, then copy across a script and run that.  This takes
care of turning the debian machine into a guix machine and deploys my
sys config immediately.

This is by far the fastest way of deploying to Hetzner VMs I've found
yet.

It also means you can use Hetzner's CLI for creating and managing your
VMs.

It's on my to do list to create a solid guix deploy server creation
module for guix.

Hth,

Alex

Re: Maintaining Jami #4

[Pierre Neidhardt]

What you need to do is the following:

- Create an empty repo on GitLab.
- In your local checkout of Guix, add your GitLab repository as a Git
  remote.
- Push to your GitLab repository.
- Create a wip-jami branch and commit your changes there.
- Whenever you want to update "master", simply "git fetch --all" then
  rebase your wip-jami onto origin/master.

Let me know if you want more details.

-- 
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Description: PGP signature

Re: Maintaining Jami #4

[Jan]

On Mon, 17 Feb 2020 18:42:05 +0100
Pierre Neidhardt  wrote:

> What you need to do is the following:
> 
> - Create an empty repo on GitLab.
> - In your local checkout of Guix, add your GitLab repository as a Git
>   remote.
> - Push to your GitLab repository.
> - Create a wip-jami branch and commit your changes there.
> - Whenever you want to update "master", simply "git fetch --all" then
>   rebase your wip-jami onto origin/master.
> 
> Let me know if you want more details.
> 

Nope, that'll do, did something similar already. Thanks!


Jan Wielkiewicz

Re: Guix search, colors and INSIDE_EMACS

[zimoun]

On Mon, 17 Feb 2020 at 14:42, Pierre Neidhardt  wrote:

> Patch sent: #39642.

Nice! :-)

February update on data.guix.gnu.org and the Guix Data Service

[Christopher Baines]

Hey,

Another update on the Guix Data Service, I sent out the last update on
the 5th of January [1].

1: https://lists.gnu.org/archive/html/guix-devel/2020-01/msg00073.html

Derivations for system tests [3], as well as channel instances [4]
(which relate to guix pull) are now captured. This is still a work in
progress, I think only the x86_64-linux derivations for the system tests
are captured, and the systems for the channel instances are limited by
what's available in the qemu-binfmt service.

3: 
http://data.guix.gnu.org/revision/3dd311e3a059131ef245417106d4fb659222ef3c/system-tests
4: 
http://data.guix.gnu.org/revision/3dd311e3a059131ef245417106d4fb659222ef3c/channel-instances

The way cross-built derivations are handled has changed. Previously the
system values were used, but I've now tried to move in the direction of
using GNU triplets. This can be seen on the revision pages in the
derivations table [5].

5: http://data.guix.gnu.org/revision/3dd311e3a059131ef245417106d4fb659222ef3c

It's now possible to configure the Guix Data Service to only process
certain branches by listing branches to explicitly include or
exclude. Using this feature, I've configured data.guix.gnu.org to only
look at master as this is what I want this instance of the Guix Data
Service to focus on. Previously, the jobs for core-updates, staging and
other branches could block processing revisions on the master branch, as
often they would take longer to process due to having to build lots of
packages just to build Guix. This issue would have only been amplified
now that data.guix.gnu.org is emulating other architectures and building
Guix for those as well.

Related to this, I've also added some code to enable removing data for a
branch, and removing unreferenced derivations. This is both for cleaning
up the data.guix.gnu.org database now I only want data for master, but
it should also be useful when using the Guix Data Service in an
environment where branches come and go, or be the basis of setting a
retention period for the data.

I forget exactly when, but recently I've been trying to revive the patch
review setup I was working on around a year ago [6]. I've setup an
instance of the Guix Data Service for this [7] (separate to the
data.guix.gnu.org one). I might try and have that instance of the Guix
Data Service process all the branches in the Guix git repository, now
that data.guix.gnu.org doesn't do that.

6: https://lists.gnu.org/archive/html/guix-devel/2019-02/msg00089.html
7: https://guix-patches-data.cbaines.net/

Back to features though, the output from inferior processes used when
loading data for a revision is now captured and stored in the
database. This means you can see more of what's going on, like the
building of libgit2 here for example [8]. Previously you got less
information [9].

8: http://data.guix.gnu.org/job/14657
9: http://data.guix.gnu.org/job/14610

As always, let me know if you have any comments or questions!

Thanks,

Chris


signature.asc
Description: PGP signature

Re: Using the Hetzner Cloud

[Christopher Baines]

Jonathan Brielmaier  writes:

> as promised on the Guix Days in Bruxelles I asked Hetzner[0] if they
> could provide us some free VMs in their cloud[1].
>
> A few days ago they came back go to me. Sadly they can't provide us free
> VMs, but they will give us 30 EUR credit for the first month.
>
> As they bill hour-wise and offer a serial console over HTTPS, you can do
> tests for stuff like the installer for 2 or 3 cents :)
>
> What do you think about it?

Thanks for looking in to the Jonathan, that's really useful.

I've been using Hetzner for hosting data.guix.gnu.org for at least the
last few months now. I've been paying for it so far, but ideally it
wouldn't depend on me personally paying for it in the long term.

Coupled with this, I think there are some services (hpc.guix.info, ...)
it would be nice to move off bayfront (a machine in Bordeaux) to
somewhere that's more reliable/remotely accessible, mostly to avoid the
risk of me breaking them again when attempting to reconfigure bayfront.

Maybe Guix Europe (a legal entity in Europe) could have a Hetzner
account that could be used at the discretion of those involved in Guix
Europe? I think Hetzner support billing by SEPA direct debit, which
might work, otherwise I can probably pay the bill and then be
reimbursed.

Thanks again for following up talking to Hetzner Jonathan!

Chris


signature.asc
Description: PGP signature

Re: Using the Hetzner Cloud

[Christopher Baines]

Ellen Papsch  writes:

> a few days ago I requested the Guix installer from Hetzner as well. I
> gave them the ISO URL from Guix website. They mounted it without
> modification, which prevented boot due to the image being compressed. I
> had to supply the uncompressed image, which booted fine.

I had exactly the same experience, I've had this with other services as
well. For the next release at least, providing there are no big
technical blockers, it would be good to publish an uncompressed ISO
image, as well as a compressed one.

> Hetzner added the image only for me, which is a hindrance for Guix
> adoption. Another limitation is that I can't create new servers right
> away without going through installation. I can dance around it by
> creating a snapshot of a template server and creating the new server
> from that snapshot, then reconfiguring the system (or doing a deploy, I
> want to try that yet).

Hopefully if enough people ask them, they might include it in the ISO
images they provide to everyone.

Thanks for sharing your experiences,

Chris


signature.asc
Description: PGP signature

Re: Using the Hetzner Cloud

[Ricardo Wurmus]

Christopher Baines  writes:

> Coupled with this, I think there are some services (hpc.guix.info, ...)
> it would be nice to move off bayfront (a machine in Bordeaux) to
> somewhere that's more reliable/remotely accessible, mostly to avoid the
> risk of me breaking them again when attempting to reconfigure bayfront.

That’s unfortunate.  Why is bayfront less reliable than we want it to
be?  Surely that’s not because it’s using Guix System, because
{berlin,ci}.guix.gnu.org also runs Guix System and has been reliably
hosting services for us.

I would not mind hosting services on one of the 30 new servers the MDC
bought for ci.guix.gnu.org, but I’d be happier if we figured out what’s
wrong with bayfront instead of centralizing all services in Berlin…

-- 
Ricardo

Re: Maintaining Jami #4

[Jan Wielkiewicz]

Dnia 2020-02-17, o godz. 18:42:05
Pierre Neidhardt  napisał(a):

> What you need to do is the following:
> 
> - Create an empty repo on GitLab.
> - In your local checkout of Guix, add your GitLab repository as a Git
>   remote.
> - Push to your GitLab repository.
> - Create a wip-jami branch and commit your changes there.
> - Whenever you want to update "master", simply "git fetch --all" then
>   rebase your wip-jami onto origin/master.
> 
> Let me know if you want more details.
> 

I guess that's it, here's my most up-to-date work:
https://gitlab.com/kromka_chleba/jami-package-and-other-things-for-guix/

Now I must set up a channel and check how it behaves.


Jan Wielkiewicz

Re: Using the Hetzner Cloud

[Christopher Baines]

Ricardo Wurmus  writes:

> Christopher Baines  writes:
>
>> Coupled with this, I think there are some services (hpc.guix.info, ...)
>> it would be nice to move off bayfront (a machine in Bordeaux) to
>> somewhere that's more reliable/remotely accessible, mostly to avoid the
>> risk of me breaking them again when attempting to reconfigure bayfront.
>
> That’s unfortunate.  Why is bayfront less reliable than we want it to
> be?  Surely that’s not because it’s using Guix System, because
> {berlin,ci}.guix.gnu.org also runs Guix System and has been reliably
> hosting services for us.

I guess having access to recover from issues is the primary concern, and
reliability relates to that.

Around FOSDEM, I think I caused Bayfront to restart while attempting to
restart cuirass. I'm not sure exactly what happened, as my SSH
connection just dropped, and the machine became inaccessible (including
Cuirass, hpc.guix.info, ...).

Luckily, some time later Ludovic and Andreas were available to remotely
access the power supply, and turn the machine off and on, this did seem
to bring the machine back.

> I would not mind hosting services on one of the 30 new servers the MDC
> bought for ci.guix.gnu.org, but I’d be happier if we figured out what’s
> wrong with bayfront instead of centralizing all services in Berlin…

I'm definitely not saying anything is wrong with Bayfront, just that it
would be good to maybe check what the expectations are with the services
it hosts. Given that the remote access only allows power cycling the
machine, if that doesn't work, there's the potential for downtime for
those services to last until someone physically goes to the machine to
fix it, if SSH access can't be restored by turning it off and on again.


signature.asc
Description: PGP signature

Re: importing/refreshing Go packages

[Jack Hill]

On Fri, 14 Feb 2020, Leo Famulari wrote:


On Fri, Feb 14, 2020 at 12:08:08PM -0500, Jack Hill wrote:

Leo and Guix,

I noticed that you recently updated syncthing and many of its dependencies.
Did you do this by hand? I'm wondering if it would make things easier if we
had a recursive importer.


Yes, I did it by hand. I look at the history of Syncthings 'go.mod' file
(and sometimes 'go.sum'). It's tedious but not too bad...

An importer / updater would be very welcome. I feel like it should be
easy with 'go.mod'.


Leo,

Thanks for your reply. I, too, am hopeful that go.mod will be helpful.

Best,
Jack

New committer

[Amin Bandali]

Hello Guix,

You may have seen me post on the Guix lists, chat in #guix on freenode
(as bandali), or know me from my involvement with other areas of GNU.
I've been a happy user and occasional contributor to GNU Guix for some
time now.  As my contributions recently became more frequent, and since
I'd also like to help out with reviewing and merging patches, I decided
to apply for commit access to Guix, which I was kindly granted by the
Guix maintainers.

I'll be signing my commits with the GPG key I'm signing this email with,
with the fingerprint BE62 7373 8E61 6D6D 1B3A  08E8 A21A 0202 4881 6103.
You can get a copy of my key from my Savannah profile [0], or from the
GNU maintainers keyring [1].

[0]: https://savannah.gnu.org/users/mab
[1]: https://ftp.gnu.org/gnu/gnu-keyring.gpg

It's been very exciting seeing how far along GNU Guix has come so far,
and how it continues to grow even further.  Kudos to everyone involved
for their hard work, and I look forward to working with y'all on this
excellent GNU system.

Happy Hacking,

-mab


signature.asc
Description: PGP signature

Re: [bug#38390] [core-updates] Scheme-only bootstrap: merge wip-bootstrap / Starting `core-updates'

[Jan Nieuwenhuizen]

Marius Bakke writes:

> Jan Nieuwenhuizen  writes:
>
>> Marius Bakke writes:
>>
>> Hello Marius,
>>
>>> The 'core-updates' branch is starting to look pretty good, and I am
>>> happy to report that it "works for me".  :-)
>>>
>>> Some of the big changes include:
>>
>>> I suggest that we set a "freeze" date shortly after FOSDEM to start
>>> integrating it.  Are there other branches that should be included?
>>
>>> Maybe wip-bootstrap
>>
>> Definately maybe!  I think that Timothy, Ludo and I have finally done
>> what set out to do (see https://bugs.gnu.org/38390).
>>
>> I have squashed the remaining squash-commits and freshly rebased
>> `wip-bootstrap' on core-updates, so I think that from our point of view
>> we are ready for merge.  WYDT?
>
> Excellent, really looking forward to seeing this merged!  Cutting the
> bootstrap seed down to ~60 MiB is nothing short of amazing.

Thank you!!  Pushed as e157ed72ec7b673b4204c84a7bf74f13afb44dc7
to core-updates.

And a very big thank you to Ludo' and Timothy: let's keep pushing this
bootstrapping thing forward!

> I think that with this branch merged as well as the glibc&binutils
> update from  we are ready to
> start the 'core-updates' branch.  \o/

\o/

Greetings,
janneke

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