Re: "guix pull" expiry channels

[zimoun]

Hi,

On Fri, 11 Jun 2021 at 23:32, Ludovic Courtès  wrote:

> The code in (guix git) determines expiration based on the mtime of
> sub-directories in ~/.cache/guix/checkouts.  But that’s bogus, no?
>
> Yes, and the Internet confirms: a directory’s mtime is only changed when
> a file inside it is renamed, added, or deleted.)  Oops!  So it would
> depend on how frequently you pull, and perhaps on the file system you
> use, go figure.

Hehe! :-)

> diff --git a/guix/git.scm b/guix/git.scm
> index 57fa2ca1ee..9c6f326c36 100644
> --- a/guix/git.scm
> +++ b/guix/git.scm
> @@ -424,6 +424,14 @@ it unchanged."
> ;; REPOSITORY as soon as possible.
> (repository-close! repository)
>  
> +   ;; Update CACHE-DIRECTORY's mtime to so the cache logic sees it.
> +   (match (gettimeofday)
> + ((seconds . microseconds)
> +  (let ((nanoseconds (* 1000 microseconds)))
> +(utime cache-directory
> +   seconds seconds
> +   nanoseconds nanoseconds
> +
> ;; When CACHE-DIRECTORY is a sub-directory of the default cache
> ;; directory, remove expired checkouts that are next to it.
> (let ((parent (dirname cache-directory)))

LGTM.

Thanks for the quick fix. :-)

Cheers,
simon

Re: Telemetry on by default kitty

[Jack Hill]

On Tue, 15 Jun 2021, Mark H Weaver wrote:

[…]


However, I strongly believe that each Guix user should be given the
opportunity to make that decision for themselves, i.e. that telemetry,
auto-update checks, and more generally unsolicited network traffic
should be disabled until the user has given informed consent.

What do other people think?


I'm not sure I have too much to add to the discussion, but since I once 
submitted a patch to disable this type of telemetry⁰, I support the notion 
that programs should not generate network traffic unless they are asked to 
do so. As Mark says, it's more than just the two endpoints that can 
observe the traffic. Even encrypted traffic provides some information.


Perhaps opting-in can be another use case for parameterized packages. We 
could have our cake and still allow folks to opt-in without having to 
tediously configure or modify their packages.


On the note of trusting software authors, for me a lot of it is 
understanding the development process and analyzing if my interests are 
aligned with those the authors. However, that can be a complicated thing. 
In general, I'm much more trusting of community projects than ones with 
corporate sponsors. Track record also counts too, so I'm glad that Bone 
referred us to the upstream discussion. I'll probably spend more of my 
time looking for problems in future releases of projects like kitty and 
audacity¹ than more trusted (to me) projects like goffice.


Even if we're not able to catch everything, auditing source can still be 
useful. I found an information leak in innernet (not packaged for Guix 
yet) in part because the authors where kind enough to point it out in a 
comment². Perhaps auditing/patching is a test that is well suited to 
combining efforts with folks beyond Guix. That can be either in dedicated 
projects like Icecat or ungoogled-chromium, or simply by looking at what 
patches and configuration options other package distributions apply. Of 
course we can also share anything that we learn.


⁰ https://issues.guix.gnu.org/40360
¹ https://www.theregister.com/2021/05/14/audacity_telemetry/
² 
https://github.com/tonarino/innernet/blob/46d97831094d04fe3ad802a4bf2ac645e09d568c/publicip/src/lib.rs#L3-L4

Well, I guess I ended up adding more comments than I thought I would. Hope 
they're helpful!


Jack

Re: Freezing ‘core-updates’ soon?

[zimoun]

Hi Ludo,

On Tue, 15 Jun 2021 at 10:52, Ludovic Courtès  wrote:

> What about finally merging that ‘core-updates’ branch?  :-)

Cool! :-)

> Anything else?  Any patches pending review?

The Julia v1.6 update introduce a tweak to master: utf8proc-2.6.1 [1]
and pcre2-10.36 [2] to avoid a world rebuild.  AFAIK, their update in
core-updates branch is not done.  At least, I have never sent the patch.

The package Julia v1.6 depends on these 2 packages.  The question
becomes if the Julia v1.6 is merged before and after the freeze?

Could you give an input about the location of patches?  See [3].  Thanks
in advance.

1: 
2: 
3: 

Cheers,
simon

PS: On a side note, I will be offline until the end of the next week.

Re: Telemetry on by default kitty

[Mark H Weaver]

Hi Leo,

Leo Famulari  writes:
> I feel that, ultimately, we already trust most software authors
> implicitly and totally, because we are not auditing their programs.

Agreed.

> So, I am personally happy to enable the telemetry for most software I
> use — especially if it is free software and especially for software
> that deals with the network.

That's your personal decision, and I agree that telemetry functionality
should be permissible in Guix, as long as it's opt-in.

> I don't personally see the point of treating telemetry as a special
> case in terms of trust or consent.

One problem is that telemetry involves trusting more than just the
developer.  Telemetry also reveals information to the user's internet
service provider, the network operators between user and the server, the
company that controls the hardware that the server runs on, and any
intelligence agencies or other hostile actors that have infiltrated
those networks or servers.  Moreover, if the server keeps logs,
governments may coerce the developer into surrendering those logs.

Therefore, when a program generates unsolicited and unexpected network
traffic -- and I certainly do *not* expect a terminal program to
generate network traffic -- it is effectively leaking some of your
private information to all of those other actors.  That, in itself, is
arguably a breach of trust, regardless of the developer's presumably
good intentions.

I understand that many people have given up on protecting their privacy,
or simply don't care.  Kitty's developer seems to be of that mindset.

However, I strongly believe that each Guix user should be given the
opportunity to make that decision for themselves, i.e. that telemetry,
auto-update checks, and more generally unsolicited network traffic
should be disabled until the user has given informed consent.

What do other people think?

  Regards,
Mark

-- 
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about .

Re: Telemetry on by default kitty

[Leo Prikler]

Am Dienstag, den 15.06.2021, 19:24 +0200 schrieb Giovanni Biscuolo:
> Hi Leo and Guix,
Wrong Leo here, I hope you don't mind me responding.

> sorry for this long message but I would like to add my point of view
> to
> the discussion about telemetry.
> 
> I apreciated the laconic statement by Tobias Geerinckx-Rice on Sat,
> 12
> Jun 2021 22:35:40 +0200 [1]:
> 
> --8<---cut here---start->8---
> 
>  This is not a point of discussion.  Telemetry or ‘phoning home’ 
>  for updates must be opt-in if possible or disabled entirely 
>  otherwise.  Would you care to submit a patch?
> 
> --8<---cut here---end--->8---
> 
> AFAIU there is a general consensus above all GNU Guix maintainers
> (and all FSDG compliant distros) on the above statement: am I wrong?
This depends on how you interpret "The distro must contain no DRM, no
back doors, and no spyware.".  The consensus (at least among Guix and
also when we consider EU law) is that you need to opt in to any
collection of data.

> I'm using Guix (and other distributions) primarily for this very
> reason, for me this is the most important *feature* of a free
> software distribution: no spyware ALSO means no opt-out telemetry.
> 
> To be clear: if Guix "only" had the fantastic features it has but was
> not FSDG compliant, I'd use something else (and be very very sad).
> 
> Leo Famulari  writes:
> 
> > On Sun, Jun 13, 2021 at 08:35:18PM +0200, Leo Prikler wrote:
> > > Perhaps it's valuable for developers, but as a user I often have
> > > next
> > > to no information about what data gets collected and for which
> > > purpose,
> > > both of which are important for *informed consent*.
> 
> [...]
> 
> > Yeah, I agree that telemetry is a problem in addition to being
> > valuable
> > for developers.
> 
> No, telemetry is not just "a problem", it's A HUGE legal issue.
> 
> I don't want to have a too long privacy related discussion here, but
> please consider in EU (I live in Italy) we have the GDPR [2] and we
> had
> a LOT of issues with the "Privacy Shield", now invalidated by the
> Schrems II [3] EU Court of Justice judgement, meaning that data
> transfers abroad are... VERY problematic :-D
Legally speaking, you might be able to claim legitimate interest
according to §6.1.f for your telemetry (I really hate that one).  It'd
be interesting to see what happens in court if you do, but it's out
there.  As a EU citizen myself, I really wish the GDPR was stricter in
statements.

> Just to give you one recent example, in Italy we have a public
> service
> app called "IO App" (processing a lot of very sensitive data) that
> was
> recently surveied by the italian Privacy Authority and it was a
> *disaster* [4]:
> 
> --8<---cut here---start->8---
> 
>  the Authority, on general criticisms on the functioning of the IO
> App,
>  has ordered, with a urgent measure, to PagoPA to temporally block
> the
>  personal data processing by this App which require the interaction
> with
>  Google’s services and Mixpanel, and which involve a transference to
>  third countries (for example: USA, India, Australia) of personal
>  sensitive data (like: cash back transactions, payments instruments,
>  holydays bonus), carried out without the consent of the users.
> 
> --8<---cut here---end--->8---
> 
> So, the italian goverment is (still) tranfering a lot of personal
> data
> to NOT (equivalent) GDPR compliant nations.
> 
> Please consider that much, if not all, of the personal data
> transferred
> (and it's LOT of data) was allegedly for "telemetry" and "issue
> tracking" purposes.
Which is exactly why I said what I said about informed consent.

> We are talking about this.  This is not for sure a kitty issue, but
> it
> is a telemetry issue.
> 
> > I think that making it opt-in doesn't really help very much. People
> > use
> > defaults. I read that Firefox struggles with software quality on
> > GNU/Linux because almost nobody enables the telemetry.
> 
> This is freedom n. 0 :-D
You could equivalently say, that freedom 0 is guaranteed through an
opt-out mechanism.  Opt-in vs. opt-out is a different ethical
conundrum, I fear.

> > I feel that, ultimately, we already trust most software authors
> > implicitly and totally, because we are not auditing their
> > programs. So, I am personally happy to enable the telemetry for
> > most
> > software I use — especially if it is free software and especially
> > for
> > software that deals with the network. I don't personally see the
> > point
> > of treating telemetry as a special case in terms of trust or
> > consent.
> 
> I'm sorry you don't see the point, but 
Might be just me, but this phrasing appears a little aggressive given
the overall tone of the message being… a little less so.

> Please remember that in some countries providing personal data to
> data processors needs informed consent on what, why, by whom and
> 

Re: Freezing ‘core-updates’ soon?

[Efraim Flashner]

On Tue, Jun 15, 2021 at 10:52:51AM +0200, Ludovic Courtès wrote:
> Hello Guix!
> 
> What about finally merging that ‘core-updates’ branch?  :-)
> 
> The main things to decide on are:
> 
>   • Upgrading to GCC 10?  I know Marius has spent time looking at it and
> fixing build failures caused by the upgrade.  Can we do it?

gcc was updated to 10 on the 1st

> Anything else?  Any patches pending review?
> 
> It would be great to freeze within a week (that is, stop world-rebuild
> changes) with the goal of merging within a six weeks (end of July).
> 
> Thoughts?
> 
> Ludo’.
> 

ant-bootstrap FTBFS, and I haven't been able to compile rust on aarch64.
`guix build xz --system=i686-linux' fails to use the correct i686
inputs.

-- 
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

Re: Telemetry on by default kitty

[Giovanni Biscuolo]

Hi Leo and Guix,

sorry for this long message but I would like to add my point of view to
the discussion about telemetry.

I apreciated the laconic statement by Tobias Geerinckx-Rice on Sat, 12
Jun 2021 22:35:40 +0200 [1]:

--8<---cut here---start->8---

 This is not a point of discussion.  Telemetry or ‘phoning home’ 
 for updates must be opt-in if possible or disabled entirely 
 otherwise.  Would you care to submit a patch?

--8<---cut here---end--->8---

AFAIU there is a general consensus above all GNU Guix maintainers (and
all FSDG compliant distros) on the above statement: am I wrong?

I'm using Guix (and other ditributions) primarily for this very reason,
for me this is the most important *feature* of a free software
distribution: no spyware ALSO means no opt-out telemetry.

To be clear: if Guix "only" had the fantastic features it has but was
not FSDG compliant, I'd use something else (and be very very sad).

Leo Famulari  writes:

> On Sun, Jun 13, 2021 at 08:35:18PM +0200, Leo Prikler wrote:
>> Perhaps it's valuable for developers, but as a user I often have next
>> to no information about what data gets collected and for which purpose,
>> both of which are important for *informed consent*.

[...]

> Yeah, I agree that telemetry is a problem in addition to being valuable
> for developers.

No, telemetry is not just "a problem", it's A HUGE legal issue.

I don't want to have a too long privacy related discussion here, but
please consider in EU (I live in Italy) we have the GDPR [2] and we had
a LOT of issues with the "Privacy Shield", now invalidated by the
Schrems II [3] EU Court of Justice judgement, meaning that data
transfers abroad are... VERY problematic :-D

Just to give you one recent example, in Italy we have a public service
app called "IO App" (processing a lot of very sensitive data) that was
recently surveied by the italian Privacy Authority and it was a
*disaster* [4]:

--8<---cut here---start->8---

 the Authority, on general criticisms on the functioning of the IO App,
 has ordered, with a urgent measure, to PagoPA to temporally block the
 personal data processing by this App which require the interaction with
 Google’s services and Mixpanel, and which involve a transference to
 third countries (for example: USA, India, Australia) of personal
 sensitive data (like: cash back transactions, payments instruments,
 holydays bonus), carried out without the consent of the users.

--8<---cut here---end--->8---

So, the italian goverment is (still) tranfering a lot of personal data
to NOT (equivalent) GDPR compliant nations.

Please consider that much, if not all, of the personal data transferred
(and it's LOT of data) was allegedly for "telemetry" and "issue
tracking" purposes.

We are talking about this.  This is not for sure a kitty issue, but it
is a telemetry issue.

> I think that making it opt-in doesn't really help very much. People use
> defaults. I read that Firefox struggles with software quality on
> GNU/Linux because almost nobody enables the telemetry.

This is freedom n. 0 :-D

> I feel that, ultimately, we already trust most software authors
> implicitly and totally, because we are not auditing their
> programs. So, I am personally happy to enable the telemetry for most
> software I use — especially if it is free software and especially for
> software that deals with the network. I don't personally see the point
> of treating telemetry as a special case in terms of trust or consent.

I'm sorry you don't see the point, but please remember that in some
countries providing personal data to data processors needs informed
consent on what, why, by whom and where the data is processed (please
consider this as an executive-summary, it's a complex matter).

Please also consider I'm not willing to provide data to the developers
of software I use simply because I don't want to exchange data for the
permission to use the software... and I'm not the only one: this is the
most important reason telemetry must be disabled by default (opt-in) if
possible or completely disabled otherwhise.

Privacy is valuable, developers must respect their users.

Thank you! Giovanni.


[1] Message-Id:87eed695yb.fsf@nckx

[2] https://en.wikipedia.org/wiki/GDPR

[3] https://en.wikipedia.org/wiki/Max_Schrems#Schrems_II

[4] 
https://www.privacy365.eu/en/by-the-italian-data-protection-authority-green-certification-the-green-light-of-the-authority-but-with-specific-guarantees-it-has-been-disposed-the-block-of-io-app/

https://www.privacy365.eu/en/by-the-italian-data-protection-authority-app-io-the-authority-implements-the-technical-relation/
(unfortunately the relation is in italian only, it's very very interesting!)

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature

Re: problem with ruby-taskjuggler packaging and timezone

[Giovanni Biscuolo]

Joshua Branson  writes:

> Giovanni Biscuolo  writes:
>
>> Hi Guix!
>>
>> I'm packaging ruby-taskjuggler (I'll provide a patch series as soon as I
>> get to fix this bug), this is the package definition:
>
> Hey Giovanni!  I invite you to send this email to guix-patc...@gnu.org
> as well!  That way we can create an issue number in the bug tracker!
> And not lose this important contribution!

Done, issue #49042

Thanks! Giovanni

[...]

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature

Re: Rust freedom issue claim

[Bone Baboon]

Leo Famulari writes:

> On Sat, Jun 12, 2021 at 02:49:21PM -0400, Bone Baboon wrote:
>> Contents:
>> * Passive Approaches
>
> I definitely think a passive approach is best, unless the owners of the
> Rust trademark are taking actions that preclude it. Have they given us
> any reason to think that we need to do something about this issue? Many
> times, the best course of action is to do nothing.

What makes it timely to be talking about the Rust trademark policy is
that the Rust Foundation was recently created.


says "The Rust Foundation will be the home of the popular Rust
programming language that began within Mozilla.".

 says
"Mozilla, the original home of the Rust project, has transferred all
trademark ... to the Rust Foundation.".

As the Rust Foundation is new there is the potential that they will be
open to changing the trademark policy.  This would make them look good
in free libre open source software communities.  It would also allow
them to demonstrate their independence from the Mozilla Foundation.

I am not currently aware of any actions being taken by the Rust
Foundation to enforce it's trademarks.

Re: RISCV porting effort

[Efraim Flashner]

On Mon, Jun 14, 2021 at 06:00:21PM -0700, Vagrant Cascadian wrote:
> On 2021-06-14, Efraim Flashner wrote:
> > On Sun, Jun 13, 2021 at 10:24:13AM -0700, Vagrant Cascadian wrote:
> >> On 2021-06-07, Efraim Flashner wrote:
> >> > Last week my HiFive Umatched¹ board came
> >> ...
> >> > Ubuntu has an image for the board² which booted up just fine and I'm
> >> > using, since I didn't want to spend too long getting Debian to run on
> >> > the board.
> >> 
> >> I, on the other hand, went straight for Debian, of course! I stole the
> >> vendor kernel and u-boot and built a Debian rootfs... and after a few
> >> tries got it running.
> >> 
> >> live well,
> >>   vagrant
> >
> > Do you have notes on what you did? Right now I was thinking of taking
> > the Ubuntu image, keeping /boot with their kernel and u-boot and
> > replacing the rest of it with Debian. (And copying the device-tree dtb
> > files to /boot/firmware/kernel-version)
> 
> I didn't take notes, but off the top of my head something like this:
> 
>   Booted the OE image that shipped with it on the microSD
> 
>   add partition for new rootfs (cfdisk /dev/mmcblk?)

Not a bad idea. I tried flashing a new SD card with their 2021.05 image
but it gave me kernel panics over the serial console so I reflashed it
with 2021.03. Actually, after flashing it I deleted everything in
/dev/sda4 and did debootstrap there and left extlinux setup as-is.

>   mkfs.ext4 /dev/mmcblkXpY
>   mount -o noatime /dev/mmcblkXpY /mnt
> 
>   git clone https://salsa.debian.org/installer-team/debootstrap
>   cd deboostrap
>   sudo DEBOOTSTRAP_DIR=$(pwd) ./deboostrap --arch=riscv64 sid /mnt 
> http://deb.debian.org/debian-ports

I added --include=openssh-server,sudo

>   echo 'UUID=...  / ext4 errors=remount-ro 0 1' > /mnt/etc/fstab
>   echo 'tmpfs /tmp tmpfs defaults,nosuid,nodev 0 0' >> /mnt/etc/fstab
> 
>   sudo chroot /mnt adduser vagrant --gecos ,,,
>   sudo chroot /mnt adduser vagrant sudo
>   sudo chroot /mnt passwd vagrant
> 
>   add another entry to /boot/extlinux/extlinux.conf using the
>   appropriate root=/dev/mmcblkXpY and/or root=UUID=...
> 
> Probably missed something, but that's the jist.

You forgot to mention what password you used ;P jkjk

echo "unmatched" > /etc/hostname
cat >>/etc/network/interfaces < Then, to build guix...
> 
>   git clone https://salsa.debian.org/debian/guix/
>   cd guix
>   git remote add originguix https://git.savannah.gnu.org/git/guix.git
>   git fetch
>   git format-patch -o debian/patches originguix/master..originguix/wip-riscv
>   # add new patches to debian/patches/series
>   
>   # adjust debian/rules and debian/control to use guile-3.0...
> 
>   # build the package!
>   DEB_BUILD_OPTIONS='nocheck parallel=5' sbuild --chroot-mode=unshare -d 
> UNRELEASED -c sid 
> 
> Upgrading to use guile-3.0 required a manually rebuilt guile-gnutls
> against guile-3.0 as well...
> 
> Just pushed debian/wip-riscv64 to https://salsa.debian.org/debian/guix/
> if you want to look at my most recent attempt.
> 
> Notably, this is just the wip-riscv patches applied against guix 1.3.0;
> maybe building against guix master will be more successful?
> 
> 
> live well,
>   vagrant

I'm actually thinking of moving my reprepro setup off my g4 and hosting
it on my desktop (where I can get my gpg key more easily) and then
rsyncing it up to my server. If I setup pbuilder on the hifive unmatched
then I'll add those packages to the ones I already have online.



-- 
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

New signing key

[Eric Bavier]

Hello Guix,

I've updated my GPG key on Savannah with a new signing subkey and uid.
Could a maintainer do the necessary repo updates?

Thanks,
`~Eric


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

Re: Freezing ‘core-updates’ soon?

[Maxime Devos]

Ludovic Courtès schreef op di 15-06-2021 om 10:52 [+0200]:
> Hello Guix!
> 
> What about finally merging that ‘core-updates’ branch?  :-)
> 
> The main things to decide on are: [...]
>
> Anything else?  Any patches pending review?

* Fixing cross-compilation

I sent a patch series fixing some cross-compilation build failures
I discovered when trying to cross-compile glib
(, also implements cross-compilation
for meson-build-system). These could in principle be done on 'master' using
,@(if (%current-target-system) ...) though.

However, most of the causes of the cross-build failures is %build-inputs
not being defined anymore on core-updates when cross-compiling, but
apparently %build-inputs is still defined on master, so I just targetted
core-updates.

I would prefer to not have to add to the next release notes that
cross-compiling isn't supported anymore, so I'd like to have the
cross-compilation fixes on core-updates before the freeze.

* Fixing failed evaluations of core-updates 
(https://ci.guix.gnu.org/jobset/core-updates)

See https://issues.guix.gnu.org/49025#29 for a corresponding patch.

Greetings,
Maxime.


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

Re: Freezing ‘core-updates’ soon?

[Jan Nieuwenhuizen]

Ludovic Courtès writes:

Hello!

> What about finally merging that ‘core-updates’ branch?  :-)
>
> The main things to decide on are:
>
>   • Upgrading to GCC 10?  I know Marius has spent time looking at it and
> fixing build failures caused by the upgrade.  Can we do it?
>
>   • Reduced binary seeds—anything new?  My understanding is that the
> reduced binary seed bootstrap now works on ARM, but that we were
> waiting on a Mes release to merge those bits.  Janneke, Danny?

Sadly, we are not there yet.  The gcc/glibc build is still not done.

The full source bootstrap is "almost ready" and is waiting for a GNU Mes
release.  It was wating for an M2-Planet release but that happened last
week!  I'm not sure about a time frame here though.  A week, hmm?

>   • Simplified package inputs—I’ll keep working on that, and most of the
> work can be done without a world rebuild, so it’s not a blocker IMO.

I haven't really caught-up here and am still wondering here about things
like

   ("foo-for-build" ,foo)
   ("patch-bar" ,(search-patch ...))

but that's prolly addressed.  I'll look into this.

Greetings,
Janneke

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

Re: Idea: a meta language for (language) build systems - npm, Racket, Rust cargo

[Ricardo Wurmus]

Leo Prikler  writes:

Guix as a build system, with or without GWL, is fine as long as 
it's

just fun and games […]


I keep seeing GWL in unexpected places, so I feel the need to 
state that the GWL is not meant to help anyone *build* software. 
It’s meant to let you *combine* applications and *run* them on an 
HPC cluster (or on a bunch of physical or virtual machines) to 
process raw data.  The intended use case is scientific workflows.


Don’t try to use the GWL as a build system; it will end in tears.

--
Ricardo

Freezing ‘core-updates’ soon?

[Ludovic Courtès]

Hello Guix!

What about finally merging that ‘core-updates’ branch?  :-)

The main things to decide on are:

  • Upgrading to GCC 10?  I know Marius has spent time looking at it and
fixing build failures caused by the upgrade.  Can we do it?

  • Reduced binary seeds—anything new?  My understanding is that the
reduced binary seed bootstrap now works on ARM, but that we were
waiting on a Mes release to merge those bits.  Janneke, Danny?

  • Simplified package inputs—I’ll keep working on that, and most of the
work can be done without a world rebuild, so it’s not a blocker IMO.

Anything else?  Any patches pending review?

It would be great to freeze within a week (that is, stop world-rebuild
changes) with the goal of merging within a six weeks (end of July).

Thoughts?

Ludo’.

Re: Idea: a meta language for (language) build systems - npm, Racket, Rust cargo

[Pjotr Prins]

On Tue, Jun 15, 2021 at 12:04:59AM +0200, Leo Prikler wrote:
> Soon: There are 15 competing build systems

Very true ;)

> Guix as a build system, with or without GWL, is fine as long as it's
> just fun and games, but it comes with the serious downside of not being
> compatible with any other distro out there.  Perhaps that works out for

Maybe. I can still support cargo - just don't want to deal with it...
A Debian target would not be too hard.

> What we need in order to make packages written in Rust less of a PITA
> is more widespread usage of generic build systems like make or meson. 
> We won't get there with cargo cult programming.  On a somewhat related
> note, I find it amusing, that Rust folk dread the usage of Rust without
> cargo, as if the Rust standard library on its own was somehow worthless
> or something :P

Meson may be good enough (indeed). I have one project that uses meson
effectively and it is not bad. But I had to look up a lot of things -
it is sometimes counterintuitive and hardly simple. Sure beats cmake
and autotools. Still, it could be simpler.

Pj.