Re: GSoC 2024

[Gábor Boskovits]

Hello,

Ekaitz Zarraga  ezt írta (időpont: 2024. márc. 7., Cs
15:16):

> I have an idea too, but I don't have the knowledge to mentor it.
>
> guix pack support for AppImages.
>

Good idea. I also don't have the technical for this. Could you add it to
the ideas page as draft and without mentor, so that we can track it?

Should you need any help feel free to contact me.

Regards,
g_bor

GSoC 2024

[Gábor Boskovits]

Hello guix,

I coordinated with the GNU org admins, and we can still do this round,
but we have to go fast to make this happen. I have already taken the
initiative to try to get an ideas page up, now I would like to confirm
if the mentors from last year are still available, and that the ideas
are still valid.

Hereby I quickly collected the projects with the respective mentors,
please pm me your availability:

Decentralized substitute distribution
pukkamustard (pukkamustard [at] posteo [dot] net)
attila.lendvai (ethswarm.org, scheme)

Robustify long-term support for Reproducible Research
Simon Tournier (zimoun)

Develop a Web interface to configure Guix System
Ludovic Courtès (civodul)

Trusted computing: Goblins for GNU Guix
Christopher Webber, Ludovic Courtès and Pjotr Prins

Guix Data Service revision processing instrumentation and performance
Christopher Baines

Guile based build-tool
Pjotr Prins

GNU Guix system monitor
Pjotr Prins

Booting via network
Danny Milosavljevic

Syntax and semantics of systemd units in the Shepherd
Ludovic Courtès (civodul)

GNUnet integration
no mentor available

Adding modules in support of continuous integration to cuirass
Ludovic Courtès (civodul)

Continue rewrite build daemon in Guile Scheme
Ludovic Courtès (civodul)

I myself am available to co-mentor, and also to be the formal mentor
in case someone does not feel like doing the official dance with
Google. Currently I can commit to devoting two hours a week to this.

Regards,
g_bor

Guix days - Newbie session discussion

[Gábor Boskovits]

I have identified three significantly different categories of newcomers:
1. coming from a nix background, having guix already installed and
experimented with it a bit
2. well aware of the involved concepts, looking into adopting guix for a
particular usecase, if guix is not installed they can do it themselves in a
few minutes without much handholding
3. total newcomers, maybe with some vaugh ideas about guix, possibly
without a device where they could install it

I believe that these groups have different expectations regarding the
session.

Also we should arrange that te newcomer session is somewhere in the
beginning of guix days, so that
1. they don't feel excluded
2. we can leverage the potential brought to the community by their new
perspective for the rest of the event already

Regards,
g_bor

Guix days guix home discussion

[Gábor Boskovits]

On guix days in the guix home discussion the following observations were
made:
1. It is rare that guix home import does the right thing (it is usually
removing some startup file customizations, does not seem to arrange to pick
up profiles, not even its own). Either we should improve it, or document
that it only gives a skeleton configuration and add some guidance on the
steps needed to get a working one.
2. The user default profile and the home package profile being separate is
causing some issues. It might be enough to document all the special
profiles somewhere (which as of now include at least system profile, user
profile, pull profile and home profile), but we can also think about a bit
more general solution, along the lines of a home service that ensures that
a given profile matches the supplied manifest, and have variables for the
special profiles. (These could then provide extensions to the shell
services which could arrange to pick them up)
3. Sometime on home reconfigure the shell prompt customizations seem to get
lost. Sourcing the shell startup file fixes it. I will have to look into
this more to file a proper bug report.
4. Creating a guix development environment service would be beneficial, to
showcase the possibilities and to simplify onboarding. On top of there
could be an additional service that adds emacs integration to this
development environment.
5. There was a recommendation to relax the expectations on the home
services merged. Right now a lot of people are just writing services for
private use. Most probably such a single usecase service would already be
beneficial to multiple people. The idea is the following: make it easy for
an initial home service to be merged. (Example: do not ask to implement
options that the submitter is not using). Then take care that if there is
an addition to the service that it really gets merged with what we already
have. This needs a bit of up front design, we have to make sure that the
services can be extended while maintaining backwards compatibility.

Creating 2024 internship page

[Gábor Boskovits]

Hello guix,

I had a look at the libreplanet today and tried to add an internship page
for 2024, but it look like I have no permission to create a page in the
guix group. It also shows me the group main page as protected. Can someone
arrange access for me or create the page and send me the link. It looks
like I can edit pages without any issue once they are created.

Regads,
g_bor

Re: Discontinuing data.guix.gnu.org?

[Gábor Boskovits]

Hello,

Julien Lepiller  ezt írta (időpont: 2024. jan. 9., K
19:33):

> In terms of finance, our last blocker is that I still don't have access to
> the account, but Andreas does, so we should be able to take responsibility
> for the cost relatively easily.
>
> Ideally, we would take ownership of the machine(s), so we don't
> overcomplicate our finances by having to reimburse someone regularly.
>
> Le 9 janvier 2024 19:12:44 GMT+01:00, "Ludovic Courtès"  a
> écrit :
> >Hello Christopher,
> >
> >Christopher Baines  skribis:
> >
> >> Ludovic Courtès  writes:
> >
> >[...]
> >
> >>> Christopher Baines  skribis:
> >>>
>  As previously set out, I'm planning to stop hosting the data service
>  instances this year. While I would like to stop hosting the server for
>  data.guix.gnu.org,
> >>>
> >>> I forgot the outcome of previous discussions, but it seems to me that
> >>> the service itself and all the data it accumulated over the years are
> >>> super valuable.  I would be sad to see it go!
> >>
> >> There was a discussion back in April, but no action came directly from
> >> it.
> >>
> >> Just having data.qa.guix.gnu.org was discussed, and at least
> >> concentrating on getting to a sustainable hosting situation there seemed
> >> like a sensible priority. The longer history provided by
> >> data.guix.gnu.org does have value though in my view.
> >>
> >>> Is there something we can do to not lose it all?  It could be
> >>> distributing responsibility, reducing the scope, ensuring hosting is
> >>> managed collectively by the project, etc.  WDYT?
> >>
> >> Since that discussion, I have disabled the database dumps and backups,
> >> which has reduced (to 62€ per month) the hosting costs (although
> >> obviously not having backups isn't ideal). It's possible to further
> >> reduce the hosting costs as well by switching away from a VM to a
> >> physical machine at Hetzner.
>

If we decide to go down this path what would be a reasonable hardware
specification for the physical machines (I guess we are talking about at
least two, because of backup). Also in this case it might make sense to see
what else we could run on them. I don't want to hijack the thread, feel
free to start a new one for this line of conversation.

Regards, g_bor

> >>
> >> But yeah, given that having at least one data service instance is a key
> >> part of keeping the bordeaux build farm running, managing the hosting
> >> through the project seems to be the way to go. I'm just not sure how we
> >> can get there, or what I can do to move things in that direction.
> >
> >Like you, I would have hoped for more reactions.  Unfortunately, I’m not
> >offering to help here because I have more than enough on my plate and
> >even a 1+ month backlog on guix-devel…
> >
> >Maintainers, what’s your take on this?
> >
> >Guix Foundation, is there any blocker to taking responsibility for
> >covering hosting expenses, possibly rediscussing the scope and cost?
> >
> >Let 2024 be a thriving Guix year! :-)
> >
> >Ludo’.
> >
>
>

GSoC news

[Gábor Boskovits]

Hello guix,

We have some news about GSoC, the community is accepting a new intern,
Sarthak. The agreed on internship project title is Parameterized Packages
for GNU Guix. Welcome on board, and we are looking forward to working
together.

As there was quite a lot of competition for places this year we only got
one internship slot assigned, but we are encouraging all prospective
interns to stay around, and try again in the next round. The distributed
substitutes proposals are still on the radar, and  it would be nice to keep
interested people around.

Regards,
g_bor

Re: [internship]GSoC proposal review period begins today

[Gábor Boskovits]

Hello,

Simon Tournier  ezt írta (időpont: 2023. ápr. 4.,
K 13:51):

> Hi Gábor,
>
> On Mon, 20 Mar 2023 at 20:47, Gábor Boskovits 
> wrote:
>
> > the proposal submission deadline, which is 4th April, 1800 UTC. This is a
> > hard deadline, contributors not submitting a proposal by this deadline
> are
> > ineligible to participate in this round of GSoC.
>
> Ouch!  Well, I was in holidays and fully offline these past weeks.
> Therefore, I probably missed it.  What is the status?  Any proposal
> around?
>
Don't worry, we have some. I am going to have a look now, as it should now
be final.

Regards,
g_bor

>
>
> Cheers,
> simon
>
>

GSoC Application deadline today

[Gábor Boskovits]

Hello guix,

This is a reminder that the GSoC application deadline is today, 1800 UTC.
All applicants should have their appliactions uploaded to the GSoC
organization before the deadline.

Regards,
g_bor

[internship]GSoC proposal review period begins today

[Gábor Boskovits]

Hello guix,

and especially prospective GSoC mentors.

I am send this as a remainder that the proposal review period has just
begun. Please coordinate with the candidates. Also please remind them about
the proposal submission deadline, which is 4th April, 1800 UTC. This is a
hard deadline, contributors not submitting a proposal by this deadline are
ineligible to participate in this round of GSoC. Please also check your
organization dashboard, and see if you can access it and see your projects.
In case you have any problem related to that contact Jose.

Regards,
g_bor

[Internship] Fwd: [gnu-soc] [IMPORTANT] Mentors please ask for an invitation into the org

[Gábor Boskovits]

Hello guix,

The following information was sent to the summer of code list, and hereby I
forward it to the list,
as it contains information for prospective mentors:

-- Forwarded message -
Feladó: Jose E. Marchesi 
Date: 2023. márc. 4., Szo, 17:32
Subject: [gnu-soc] [IMPORTANT] Mentors please ask for an invitation into
the org
To: 



Hello people.

We need to add the different prospective mentors in the GNU organization
in the GSOC website [1].

For that, we need an email address that we can use to issue an
invitation.

Regardless of whether the mentor eventually mentors a contributor or
not, we need to fill them in the system.

So please send me an email, either privately or in the list, specifying
the email addresses of the mentors so I can add them in the system.

Thanks!

So, people willing to mentor on this round GSoC please contact Jose.

Thanks.

Regards,
g_bor

Re: ’inherit’ and list-dependent (was Re: branch master updated: gnu: emacs: Add TREE_SITTER_GRAMMAR_PATH support.)

[Gábor Boskovits]

Hello,

Ludovic Courtès  ezt írta (időpont: 2023. febr. 25., Szo
19:10):

> Simon Tournier  skribis:
>
> > On Tue, 21 Feb 2023 at 23:55, Ludovic Courtès  wrote:
> >
> >>> However, we could imagine to use ’package/inherit’ or another variant
> >>> instead of plain ’inherit’ for creating these inherited packages.
> Doing
> >>> so, we could collect some information, e.g., in the field ’properties’,
> >>> which could be used then by --list-dependent.
> >>
> >> In effect that means keeping back the chain of inherited objects, which
> >> would lead to space leaks.
> >
> > [...]
> >
> >> I agree it’d be nice to solve.  I can’t think of a good way to do that
> >> though.
> >
> > What do you mean by “space leaks”?
>
> Unbounded memory usage: each copy of an object is linked back to its
> “parent” (“previous generation”).
>
How much heavier is this than the links to inputs?

Regards, g_bor

>
> Ludo’.
>
>

Internship coordination status report

[Gábor Boskovits]

Hello Guix,

Here follows a short summary on where we are regarding the internship
programs.

GSoC:

This year the GNU Project was applying again for GSoC, and
we got the word yesterday that the GNU Project was accepted.

Thanks to Jose E. Marches for taking care of this.

This basically means that we should have a look at our ideas page,
and run a quick health check on the proposals, enriching them with
the following information where needed:

(quoted from the mail on the summer of code list)
  + Title, and description.
  + Skills required.
  + A mentor with an email address.
  + Whether it is a 175 hour or a 350 hour project.
  + Difficulty: easy, medium or hard.
  + CLEAR contact method for interested students.




>From now to March 19, be ready to be contacted by contributors, in
whatever contact means you specified in your ideas page.  Starting in
March 20, contributors will start submitting their proposals through the
program website.
(end quote)

Next week I am on holiday, so I asked Pjotr Prins to take over the initial
coordination tasks until I am back on 6th of March, 2023.
Outreachy:

Coming up with a working solution for funding here is far from trivial.
Thanks to Andreas Enge and Simon Touriner now all stakeholders are involved
and
we are working on a solution. I don't want to bore the list with the details
here, and I will send an update once we have an agreement on how to
handle it.

Thanks to everyone who is helping this effort.

Best regards,
g_bor

Re: ’inherit’ and list-dependent (was Re: branch master updated: gnu: emacs: Add TREE_SITTER_GRAMMAR_PATH support.)

[Gábor Boskovits]

Hello,

Simon Tournier  ezt írta (időpont: 2023. febr.
14., K 13:25):

> Hi,
>
> On dim., 12 févr. 2023 at 01:14, Ludovic Courtès  wrote:
>
> >> There is an idea to update guix refresh --list-dependent to handle the
> >> case with inherited packages as well.  WDYT?
> >
> > Unfortunately, it’s not possible because inheritance info isn’t
> > available at run time.
>

My idea here was to rescan the source with a minimal scanner and build up
an inheritance aware dependency graph. We could then make this information
available in some way, but about that part I did not think about too much
yet.

Another thing that could possibly work is to enrich the package with
inheritance information, but I am not sure that this can be done in a
backwards compatible way. Wdyt?

>
> Well, with the current implementation of ’inherit’, which is just
> copy/paste at the record level, indeed it is not possible to detect some
> relationship.
>
> However, we could imagine to use ’package/inherit’ or another variant
> instead of plain ’inherit’ for creating these inherited packages.  Doing
> so, we could collect some information, e.g., in the field ’properties’,
> which could be used then by --list-dependent.
>
> Many of us are bitten by this.  I remember a recent update of Git which
> also missed the dependency of git-minimal. :-)
>
> For sure, QA helps a lot.  Somehow, braces and belt. ;-)
>
>
> Cheers,
> simon
>
Regards,
g_bor

>
>
>
>

Re: [Internship][Discussion] Do we want to run our own internship program?

[Gábor Boskovits]

Hello,

Simon Tournier  ezt írta (időpont: 2023. febr.
14., K 13:24):

> Hi Gábor,
>
> On lun., 13 févr. 2023 at 21:13, Gábor Boskovits 
> wrote:
>
> > So, the question is: do we want to run our own?
>
> By “our own”, do you mean something like “Guix Summer of Code”?  Or
> whatever other season. :-)
>

Yes, exactly.


> Similar to:
>
> https://summer.nixos.org/
> https://summer.haskell.org/news/2017-04-05-getting-ready.html
>
>
> If yes, doing that under the French law is not straightforward and it
> would require some paperwork.  Well, maybe not.
>

Yes, that is part of the know-how I referred to.


> Cheers,
> simon
>

Regards,
g_bor

>

[Internship] I contacted the Outreachy organizers

[Gábor Boskovits]

Hello Guix,

I have contacted the Outreachy organizers to clarify if we need an
alternative funding arrangement. I will keep you updated.

Regards,
g_bor

[Internship][Discussion] How we want to arrange the mentoring of internships?

[Gábor Boskovits]

Hello Guix,

This is a kickoff message to start the discussion on how we can arrange
that community members who are willing to help in mentoring can
meaningfully participate if they can not commit to being a full time
primary mentor.

So the question is: How do we imagine a co-mentor?

Regards,
g_bor

[Internship][Discussion] Do we want to run our own internship program?

[Gábor Boskovits]

Hello Guix,

This is a kickoff message to start the discussion if we want to run our own
internship program as the Guix community.

We discussed this idea on the Guix Days, and came to the conclusion that
this is financially feasible, but needs effort and maybe also some know-how
from the community members.

So, the question is: do we want to run our own?

Regards,
g_bor

[gnu-soc] Guix internship ideas page

[Gábor Boskovits]

Hello Jose and all,

The GNU Guix community would be happy to participate.

We have a generic internship ideas page on libreplanet:
https://libreplanet.org/wiki/Group:Guix/GSoC-2023

Please also let us know if we can help in any way.

Regards,
g_bor

Fwd: Google Summer of Code?

[Gábor Boskovits]

Hello,

Sorry, guix-devel was left off CC.

-- Forwarded message -
Feladó: Gábor Boskovits 
Date: 2023. febr. 10., P 9:02
Subject: Re: Google Summer of Code?
To: Simon Tournier 


Hello,

Simon Tournier  ezt írta (időpont: 2023. febr.
8., Sze 12:32):

> Hi,
>
> On mer., 08 févr. 2023 at 10:03, Ludovic Courtès  wrote:
>
> > Jose Marchesi applied to have GNU participate as an umbrella
> > organization in GSoC:
> >
> >
> https://lists.gnu.org/archive/html/summer-of-code/2023-02/msg0.html
>
> The deadline for applying as our own* organization is over (February 7,
> 2023).  Therefore, if we want to be, maybe?, part of the GSoc this
> summer 2023, our best option is to feed ideas as suggested. ;-)
>
Yes, this might be a good idea. I am actually curious if this time around
GNU can get in again, but collecting the ideas in itself seems to be a
valuable contribution in itself. Maybe we can rename the libreplanet page
to something like Internship Project Ideas, or something like that. It also
now has a categorization and a proposal time based subsectioning, we might
think about a bit how to reorganize this content so that it is more useful.
( I think maybe the proposal time is not the default trait that should be
the most prominent.) I will have a look at this.


> > I think we could submit project ideas as Jose outlines in the message
> > above, possibly starting by collecting them on a wiki page as we did in
> > the past.  For reference, this is what we had in previous years:
>
> >   https://libreplanet.org/wiki/Group:Guix/GSoC-2021
> >   https://libreplanet.org/wiki/Group:Guix/GSoC-2020
>
> Please provide any ideas, even ones which could look at first totally
> crazy. :-)
>
> Cheers,
> simon
>
> *run as our own organization: as GCC, GNU Radio, GNU Octave or GIMP.
>
>
> https://summerofcode.withgoogle.com/archive/2022/organizations/gnu-compiler-collection-gcc
>
> https://summerofcode.withgoogle.com/archive/2022/organizations/gnu-image-manipulation-program
> https://summerofcode.withgoogle.com/archive/2022/organizations/gnu-radio
> https://summerofcode.withgoogle.com/archive/2022/organizations/gnu-octave
>
>

Re: Google Summer of Code?

[Gábor Boskovits]

Hello,

Ludovic Courtès  ezt írta (időpont: 2023. febr. 8., Sze
10:03):

> Hello Guix!
>
> Jose Marchesi applied to have GNU participate as an umbrella
> organization in GSoC:
>
>   https://lists.gnu.org/archive/html/summer-of-code/2023-02/msg0.html
>
> Participation in internship programs was discussed at the Guix Days and
> quite a few people were enthusiastic about resuming participation in
> these programs.
>
> I think we could submit project ideas as Jose outlines in the message
> above, possibly starting by collecting them on a wiki page as we did in
> the past.  For reference, this is what we had in previous years:
>
>   https://libreplanet.org/wiki/Group:Guix/GSoC-2021
>   https://libreplanet.org/wiki/Group:Guix/GSoC-2020
>
> Who would like to coordinate that effort and/or offer to mentor a
> specific project
>
I will contact Jose, pass a link to the ideas side and check how to proceed
and if we can help somehow.

>
> (I am not offering to do any of these :-) but I’m happy to provide
> feedback or share my experience regarding mentoring.)
>
> Ludo’.
>
>

Re: Welcome to our new committer!

[Gábor Boskovits]

Welcome!

Efraim Flashner  ezt írta (időpont: 2022. aug. 5.,
P, 17:59):

> The Guix Maintainer Collective (tm) would like to welcome Andrew Tropin,
> aka abcdw, as our newest committer! I'm sure many of you recognize them
> from their work on Guix Home and their regular videos hacking on Guix,
> among other things.
>
> So join us in welcoming them!
>
> --
> Efraim Flashner  אפרים פלשנר
> GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
> Confidentiality cannot be guaranteed on emails sent or received unencrypted
>

Re: maradns reproducibility fixes and the merits of picking a random number

[Gábor Boskovits]

Hi,

Tobias Geerinckx-Rice  ezt írta (időpont: 2022. jún. 28., K
18:07):

> Hi,
>
> Vagrant said:
> > It is expensive to generate the random prime on some hardware, so doing
> > so at runtime might not be feasible in some cases...
>
> But in the same reply you're paraphrasing, upstream also says:
>
> > In 2010, I updated that homegrown hash compression
> > algorithm to also add a random number when compressing
> > the input, and calculating another 32-bit random number
> > when Deadwood starts.
> ^^^
>
> and
>
> > I believe the hash compression algorithm is protected from hash
> > bucket collision attacks, even if Deadwood is patched to make
> > MUL_CONSTANT a constant number, since the add constant
> > remains random.
>
> so their 'too computationally expensive' does not make sense to me.  Do
> they bail out if generating the truly random part 'takes too long'?  Surely
> not.
>
> Neither does the 'ah, but your urandom might be broken' argument for
> silently substituting a still less random number.
>
> I don't think this alone justifies the scheme, or disabling substitutes.
>
I tend to agree.
Afaics this can be solved in a workaround way. I don't think this random
number is picked up by the build in any way. Upstream could just provide it
as an optional config value. That would be better in every respect.  Then
they could just give a build flag to move to the new model. Do you think
such a proposal would be accepted upstream?

>
> Kind regards,
>
> T G-R
>
> Sent on the go.  Excuse or enjoy my brevity.
>
>

Re: Release v1.4?

[Gábor Boskovits]

Hello,

Ludovic Courtès  ezt írta (időpont: 2022. jún. 15., Sze
11:12):

> Hello!
>
> Josselin Poiret  skribis:
>
> > Should we also make use of the point release to remove some deprecated
> > things/switch some defaults?  I'm thinking of:
> > * removing the swap-devices deprecation warning and compatibility code;
> > * removing the bootloader-configuration-target warning and compatibility
> > code;
>
> I don’t think we can do that because there hasn’t been any new release
> in the meantime, unfortunately.  Better wait for a few months after 1.4.
>
> > * switching gdm-configuration-wayland? to #t, so that the OOB experience
> > with Wayland sessions is better.
>
> Perhaps I’m biased because I use Xorg, but I wonder how good a default
> that is?  To put it differently, what fraction of the user base uses
> Wayland?
>

Do you think we can use download statistics to estimate this?
>

Regards,
g_bor

>
> Thanks,
> Ludo’.
>
>

Re: proposal: guix-ment...@gnu.org list/alias

[Gábor Boskovits]

zimoun  ezt írta (időpont: 2022. jún. 2., Cs
0:13):

> Hi,
>
> On Wed, 01 Jun 2022 at 22:17, Ricardo Wurmus  wrote:
>
> > What do you think about this?
>
> This is a great idea!
>

I agree. Having this would be nice.

>
>
> > 3. update the Contributing section in the manual (and the website) to
> > suggest Cc-ing guix-ment...@gnu.org for a first contribution.
>
> Maybe instead of manually CC-ing guix-men...@gnu.org, we could have a
> tiny script on the top of git-send-email which would add X-Debbugs-CC.
>
>
> Cheers,
> simon
>
>
>

Re: Faster "guix pull" by incremental compilation and non-circular modules?

[Gábor Boskovits]

Hello Maxime,

Maxime Devos  ezt írta (időpont: 2022. febr. 28.,
H, 19:51):

> Ludovic Courtès schreef op ma 28-02-2022 om 14:17 [+0100]:
> > Hi,
> >
> > Maxime Devos  skribis:
> >
> > >   2. Instead of building all of Guix as a single derivation,
> > >  create a DAG of derivations.  More concretely:
> > >
> > >  First read the *.scm files to determine which module imports
> > >  which modules. Then to compile, say, (gnu packages acl),
> > >  a derivation taking gnu/packages/acl.scm and its dependencies
> > >  gnu/packages/attr.go, gnu/packages/base.go, ... is made
> > >  compiling gnu/packages/acl.scm to a gnu/packages/acl.go.
> > >
> > >  Then to build all of Guix, 'union-build' or 'file-union' is used.
> >
> > This is what (guix self), used by ‘guix pull’, is already doing.
> >
> > However, currently, package modules are split in just two groups: the
> > “base” group is the closure of (guix packages base), and the second
> > group has all the rest:
> >
> > [...]
>
> Looking at (guix self), it also has a few groups for non-package
> modules (system tests, scripts, ...).
>
> > At its core though, the situation pretty much reflects the free software
> > situation: there are low-level packages (glibc, GCC, GTK, etc.) that
> > might depend on high-level packages (Python, Pandoc, Rust, etc.).
> >
> > It’s not easy to split this spaghetti ball in smaller groups.
>
> It's not easy to manually split the spaghetti, but we don't have
> to, we could let the computer split the spaghetti for us (at least
> partially, because of the circular imports), by computing the graph of
> strongly-connected components and considering each SCC to be a ‘group’,
> some of which depend on other groups, forming a DAG.
>

I was thinking about a bit of a different structure that can also be
automated. My original idea was to use the already existing tree structure
of the derivations, and split it based on depth. I think that gives a bit
more structure, but might require splitting things that now are together
(for example iirc sometimes we are defining bootstrap packages inheriting
from the fully fledged ones, which introduces a syntactic dependency on
something that is  higher up the tree). Wdyt?

Regards,
g_bor


> I believe Ricardo Wurmus has some script for computing the SCC?
>
> Splitting large SCC in smaller parts can be left as an exercise
> for later, it's a somewhat orthogonal concern.
>
> > Thoughts?
>
> I think it would be nice to let (guix self) automatically determine the
> DAG of groups.  It would reduce the ad-hocness of the *...-modules*
> variables (some care required for patches, guix/man-db.scm, .js ...).
>
> It would also make the node tree wide, which could reduce memory usage
> (which might help with the ‘guix pull segfaults on i686-linux’
> reports).  In case of a crash (*), "guix pull" does not have to start
> over from scratch, which would also help with those reports.
>
> (*) This does not help with "failed to compute the derivation of Guix".
>
> Some work would be required, but I think it will be worth it, and it
> only has to be done once.
>
> TBC, this was just an idea I wanted to share, I won't be working on it
> in the forseeable future.
>
> Greetings,
> Maxime.
>

Re: Dropping gzip-compressed substitutes

[Gábor Boskovits]

Hello,

Ricardo Wurmus  ezt írta (időpont: 2022. febr. 21., H
12:34):

>
> Maxim Cournoyer  writes:
>
> > This week, I'd like to try the following to see if we could get past
> > this:
> >
> > 1. Do the experiment again, now a 'rootdelay=20' kernel parameter was
> > added to Berlin's config.  This may well be enough.
> >
> > 2. In case mounting the RAID 10 Btrfs root partition still fails with
> > missing drive errors, try the following workaround suggested in the
> > #btrfs channel, which forces a 'btrfs device scan' on each device of the
> > array, with the following mount option:
> >
> > "device=/dev/sda3,/dev/sdb3,/dev/sdc3,/dev/sdd3,/dev/sde3,/dev/sdf3"
> >
> > To make it more convenient to experiment with different values for the
> > rootdelay or add the device option above, I'm planning to 'guix system
> init'
> > with the following patch applied: https://issues.guix.gnu.org/40998,
> > which allows providing 'rootflags' directly from the kernel command line
> > (thus by editing the GRUB config at boot).
>
> Good work, Maxim!  Your persistence is admirable.
>
> > I'll try to synchronize with Ricardo in the channel and hope they
> > weren't too frightened by our last experiment to not shy away from
> > trying again :-).
>
> We can make another attempt this week.  Do we need to sync anything
> before trying again?  Also: would be nice if we could do “guix system
> init” without copying everything again and again whenever we try again…
>
> My toddler has been pretty sick for the past couple of days, and I
> haven’t slept enough to be using my brain without hand-holding :) I’ll
> try to be around long enough in the eaerly evenings to see to it that
> the server reboots fine, but if things go awfully sideways I just cannot
> commit to riding the bike to the data centre.  Let’s hope it will just
> work fine with your changes to the initrd.
>

Sorry to hear that, hope they get better soon. I there is anything I can
help, besides taking the the bike to the dc which is a bit far from here
feel free to contact me.

Regards, g_bor

>
> See you later on IRC — I gotta have a nap :)
>
> --
> Ricardo
>
>

Re: Clarifying blog post licensing

[Gábor Boskovits]

I agree.

pelzflorian (Florian Pelz)  ezt írta (időpont:
2022. jan. 27., Cs 18:35):

> I agree.
>
> On Wed, Jan 26, 2022 at 10:24:11AM +0100, Ludovic Courtès wrote:
> > Hello Guix!
> >
> > With a few exceptions, our blog posts do not have a license, which is
> > not great as it prevents sharing and reuse, at least by those outside
> > Guix circles (we discussed it in the past but never got around to fixing
> > it).
> >
> > I’d like us to clarify that, with a footer on blog posts saying that,
> > unless otherwise stated, posts are dual-licensed under CC-BY-SA 4.0 and
> > GFDL 1.3+ (the latter so we can reuse material in the cookbook and in
> > the manual).  Patch below.
> >
> > What do people think?
> >
> > If maintainers and everyone agrees, I’d like to publicly email all the
> > authors asking them whether they agree with the proposed licensing
> > terms, or whether they’d like a different free license.  The script
> > below enumerates blog post authors (the list needs a bit of cleanup
> > still):
>
>

Outreachy

[Gábor Boskovits]

Hello guix,

Outreachy mentor applications for the nextr round opened on 1st January. I
have two quetions regarding that.

Q1: Are there any project proposals?

Prospective mentors please feel free to propose your projects, so that we
can discuss.

Q2: Have the situation regarding the funding of these interships been
settled?

Regards,
g_bor

Re: Organising Guix Days

[Gábor Boskovits]

Hello Julien,

Julien Lepiller  ezt írta (időpont: 2021. dec. 11.,
Szo, 2:37):

> Hi Guix!
>
> I think it's time to start organising the Guix Days, traditionally held
> around Fosdem.
>

Super good initiative.


> During our guix-europe assembly, we discussed some options and everyone
> agreed they wanted a two-day event, online just as Fosdem. I attached a
> proposed blog post that we should put on the website as soon as we
> agree on the first details.
>
> I suggest that we have these days right after Fosdem, Monday and
> Tuesday. This should give us just a few more days to prepare, as I think
> we're starting pretty late already. If you prefer to have them before
> fosdem, I can change the blog post of course.
>

Sounds good to me.


> As for how it'll be organised. I propose to do something similar to
> what we need in November 2020. I'd love to get some talks from people
> outside the usual maintainers and commiters, to have an overview of the
> diversity of people and usage around Guix.
>
> Last year, we asked speakers to prepare a video in advance, and they
> would only have an extended Q/discussion session. I think this year
> we should have the same process, but ask for a short (3-5 minutes) talk
> at the start of the session to refresh our minds on the main points of
> the presentation before discussions start.
>
> Of course, one of our co-maintainers should have a session on a
> retrospective (what happened last year in Guix) and lead discussions on
> the future of Guix. We should reserve plenty of time for this session.
>
> In addition, I'd like to invite people to submit discussion ideas and
> be free of having to make a presentation if they prefer (BoF). I'd also
> like to "innovate" and have a session of lightning talks, where people
> would only have to give a short, live presentation on any topic related
> to Guix (I'm thinking short presentation of a project where you use
> guix, of something you're doing with guix, how you found guix, a story
> of your first days with guix, ...). We can also replace that with a
> presentation round at the beginning of the conference if we don't have
> enough lightning talks.
>
> The Guix Days have never been a "real" conference, and always had a lot
> of room for discussions that start on the spot. I'd like to emulate
> this by keeping a lot of time out of the talk sessions to discuss
> whatever comes up naturally during our discussions.
>
> Also, we need to secure a BBB instance :)
>

Should you need any help in organizing, feel free to reach out to me, I
will try to do my best.


> WDYT?
>

Thanks for the effort that went into this so far,
I am looking forward to participating.

Best regards,
g_bor

IT jobs in Switzerland

[Gábor Boskovits]

Hello guix,

The firm where I am working now is hiring.

Location: Zug, Switzerland. People willing to work in office will be
preferred. The firm helps with relocation if needed.

Profile: HFT crypto startup

Codebase: c++, python
Tooling: k8s, gitlab

Positions: quantitative trader, quantitative researcher, c++ developer,
devops

Experience with AWS is a plus.

If someone is willing to give this a try, please come back to me and I can
provide more details.

Regards,
g_bor

Re: Building Guile with ‘-j1’?

[Gábor Boskovits]

Hello,

Ludovic Courtès  ezt írta (időpont: 2021. jan. 20., Sze, 9:42):
>
> Hi!
>
> As the saying goes, “the cobbler’s children go barefoot”.  Guile/Guix
> are no exception since Guile builds are non-reproducible, despite work
> done a few years ago:
>
>   https://issues.guix.gnu.org/20272
>
> Until it’s fixed in Guile proper, what do you think of building Guile
> 2.0/2.2/3.0 with #:parallel-build? #f ?  We could do that in
> ‘core-updates’ now.
>
> That would work around the problem for Guile itself.  It would increase
> build times, but probably not that much since the most expensive part
> (compiling the first few files) is sequential anyway.  IIRC this is what
> Vagrant did for the Debian packages.
>
> We could also disable parallel builds in ‘guile-build-system’.  It’s
> only used for small packages so the extra build time is probably OK.
>
> Thoughts?

Let's go for it.

>
> Ludo’.
>

Regards,
g_bor
-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

Re: [Outreachy] Strategy to implement guix git log --pretty=

[Gábor Boskovits]

Hello,

Magali  ezt írta (időpont: 2021. jan. 6., Sze, 5:35):
>
> Hello Guix,
>
> As you might know, as part of my Outreachy internship I'm currently
> working on implementing the subcommand 'guix git log', for browsing the
> history of all packages. So far, it works with '--oneline' and
> '--format=', and FORMAT can be 'oneline', 'medium' or 'full'. If
> you want to see it, the code can be found at
> https://gitlab.com/magalilemes/guix
>
> On the road to adding another option to the subcommand,
> '--pretty=' arose as an idea. With git log, you can do something
> like
> git log pretty=
> And this string can have placeholders, such as %h for showing the short
> hash of a commit, and %s for showing the commit subject. For instance,
> you could have git log --pretty="%h %s" and this would display the
> commit history log with the short hash and subject of commits.
>
> So, in order to implement 'guix git log --pretty=', I'd like
> help with a strategy to parse the string. Any examples, ideas and tips
> would be really appreciated.
>

>From the top of my head two things come to mind, you could either
tokenize the string and handle it as a list,
or you could do a regex matching. I don't think anything more
complicated is needed to handle this.

You can find the relevant docs here:
https://www.gnu.org/software/guile/manual/html_node/Strings.html
https://www.gnu.org/software/guile/manual/html_node/Regular-Expressions.html




> Cheers,
>
> Magali
>
>

Regards,
g_bor
-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

Re: Hello from new Outreachy applicant

[Gábor Boskovits]

Hello Lulu,

Lulu  ezt írta (időpont: 2020. okt. 9., P, 8:00):
>
> Hi Simon,
>
> > Have you already tried GNU Guix?  The package manager on foreign
> > distro?  The full Guix System?
> > If yes, are you comfortable with?  Feedback is very welcome. :-)
>
> I tried Guix on a foreign distro but ran into some problems with
> SELinux and locales. Do you recommend using GuixSD on a virtual
> machine, or do you think a foreign installation would be easier for
> development? I reckon a setup for internal development wouldn't be
> the same as a setup for the end-user. I think I might need to work
> directly from the trunk, so maybe I need to get familiar with
> `guix environment' for testing? I'd appreciate some tips on this.
>

I have always used a Gnu System VM or bare machine for development. It was
easy to set up, and made it easy to work also on services and system stuff.
The foreign distro way might be more lightweight, but if you can afford a VM I
would recommend it.

> > Well, last but not least, what topic you may be interested in to work on?
>
> I decided on the task to add a `guix git log' subcommand, out of the
> two tasks on the Outreachy page. :-) [1]

Nice, thanks for looking at it. It looks like a really good
improvement, but Simon
will have more info on that.

>
> Aside from that, can you tell me more about how this mentorship
> process works? Is there a regular schedule with meetings or progress
> reports or such?

No, actually nothing compulsory. We usually come to an informal agreement on
the meetings. I believe that communication is important and like to
have a longer discussion
(an hour or so) in the internship period. Other than that, I would
like to see two things:
1. some form of communication from the applicants every two/three
days: this should even come, if everything is going as expected, like:
"Everything is going as expected, right now I am working on..."
2. if there is a blocker of any kind, and you cannot make progress for
more than two hours: "Hello, there is a blocker, I can't make
progress, the problem is: ... Please contact me."
These should preferably be public communications, so that the
community as a whole can see the progress, and help in case of a
problem.
Just two notes for that:
1. two hours might seem a bit short, but the thing here is that we
would like to know about these, so that only a little time is wasted.
If you don't need help, or want to spend some more time on the problem
we won't stop you, but might give some directions to make this more
efficient.
2. It might feel awkward at first to communicate blockers publicly,
but it might shortcut a bunch of communication roundtrips. Guix is a
quite big place, sometimes I don't know how to tackle a problem, and
will need to turn to the community anyways. Thus making things public
will allow you to not block on my response.
One more final thought:
Don't get too stressed, there is nothing set in stone, and we can be
quite flexible, as long as we see progress, but please communicate
often, so that we know what's going on.

>
> [1]: 
> https://www.outreachy.org/outreachy-december-2020-internship-round/communities/gnu-guix/#add-a-subcommand-showing-gnu-guix-history-of-all-p
>
> --
> Lulu
>

Regards,
g_bor
-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

[OUTREACHY] Proposal submission deadline extended

[Gábor Boskovits]

Hello guix,

The Outreachy proposal submission deadline has been extended, the new
deadline is
Sept. 29, 2020 at 4pm UTC.

Best regards,
g_bor
-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

[OUTREACHY] Added a submitting a proposal doc to maintenance

[Gábor Boskovits]

Hello guix,
I added a submitting a proposal file to maintenance, that
describes what the community specific fields should look like,
and also some recommendations on the rest. The project specific fields
and the mentor specific fields can't be filled in form these, but I
still
believe this can help to shorten this process.

Best regards,
g_bor
-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

[OUTREACHY][IPFS] The comentor link ot the IPFS proposal

[Gábor Boskovits]

Here is the comentor link to the IPFS proposal:
https://www.outreachy.org/outreachy-december-2020-internship-round/communities/gnu-guix/distributing-substitutes-over-ipfs/cfp/mentor/submit/

-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

Re: [OUTREACHY] toward a proposal?

[Gábor Boskovits]

Helllo,

zimoun  ezt írta (időpont: 2020. szept. 17.,
Cs, 13:26):
>
> On Thu, 17 Sep 2020 at 13:16, Gábor Boskovits  wrote:
>
> > > Do you know if the past submissions have been publicly archived somewhere?
> >
> > I am not sure if these are available publicly, but you should be able
> > to see this for example:
> > https://www.outreachy.org/outreachy-may-2020-internship-round/communities/gnu-guix/create-netlink-bindings-in-guile/cfp/
>
> Seeing nothing, just the title.

Even when you are logged in to outreachy?
That is strange

I will copy it then to somewhere in maintenance later...

>
> Cheers,
> simon


Regards,
g_bor
-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

Re: [OUTREACHY] toward a proposal?

[Gábor Boskovits]

Hello,

zimoun  ezt írta (időpont: 2020. szept. 17.,
Cs, 12:01):
>
> Hi Gábor,
>
> On Thu, 17 Sep 2020 at 10:12, Gábor Boskovits  wrote:
>
> > I have read the proposal. All in all it looks good to me. One section
> > that could be
> > improved is the requirement on the setup. We usually state having guix
> > installed as
> > a requirement, even maybe a development setup. As initial contribution
> > we usually
> > ask for packaging something simple. We should also have a look at the 
> > community
> > details, like the communication channels, and try to uniformize them
> > across the proposals.
> > I will check how it was phrased in the past, see if there is any new
> > info now, and try to
> > come up with something.
>
> Thank you.
> Do you know if the past submissions have been publicly archived somewhere?

I am not sure if these are available publicly, but you should be able
to see this for example:
https://www.outreachy.org/outreachy-may-2020-internship-round/communities/gnu-guix/create-netlink-bindings-in-guile/cfp/
>
>
> Cheers,
> simon

Best regards,
g_bor


-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

Re: [OUTREACHY] toward a proposal?

[Gábor Boskovits]

Hello,

Ricardo Wurmus  ezt írta (időpont: 2020. szept.
16., Sze, 20:44):
>
>
> zimoun  writes:
>
> > On Wed, 16 Sep 2020 at 19:21, Ricardo Wurmus  wrote:
> >
> >> Yes.  The idea is that there will be a large number of proposals but
> >> only enough funding for one or two interns.  IIRC internship candidates
> >> then pick a project they’d like to work on and eventually we decide
> >> together with the mentors whom to accept for the internships.  So it
> >> could be that there will only be one suitable internship candidate who
> >> picked another project — in that case the IPFS project would not go
> >> forward as an Outreachy internship.  If we’re lucky, though, we’ll get
> >> enough suitable candidates so that all proposed projects can go forward.
> >
> > I committed something.

I have read the proposal. All in all it looks good to me. One section
that could be
improved is the requirement on the setup. We usually state having guix
installed as
a requirement, even maybe a development setup. As initial contribution
we usually
ask for packaging something simple. We should also have a look at the community
details, like the communication channels, and try to uniformize them
across the proposals.
I will check how it was phrased in the past, see if there is any new
info now, and try to
come up with something.

>
> Thank you, I’ll try to read it tomorrow.
>
> > Well, the GNU Guix has one intern founded for this round, if I read
> > correctly.  Obviously, I can withdraw the proposal if it can help IPFS
> > to reach master.
>
> There is the possibility to get extra funding from Outreachy when there
> are more suitable candidates than funded projects.  It’s an exceptional
> case, but you won’t have to withdraw proposals.  In the worst case we
> can carry the proposal to the next round of internships.
>
> --
> Ricardo

Best regards,
g_bor
-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

Re: [OUTREACHY] Proposal: substitutes over IPFS

[Gábor Boskovits]

Hello Konrad,

Konrad Hinsen  ezt írta (időpont: 2020.
szept. 16., Sze, 16:28):
>
> Hi Ludo,
>
> > I prefer not to volunteer to mentor it, but I’m happy to contribute to
> > discussions and code review.
> >
> > Who’d be willing to mentor it?
>
> I don't know what exactly that implies, so all I say for now is that I'd
> be happy to participate in this project. I know the IPFS side rather
> well, but have only a user-level knowledge of how Guix handles
> substitutes.
>
> Does Outreachy call for a single mentor, or can it be a team?

I believe it is better if  it's a team. How it worked in the past was
that we usually designated one person to be the primary mentor,
and have others help out when they were unavailable. Also we usually
had one hour weekly where there was live discussion,
where all the mentors were participating. Outreachy asks for a 5 hour
per week commitment from the team per intern.
Usually there are peeks when this can be more, but there are periods
when this is just too much. It all boils down to good communication
though.
I would be happy to co-mentor this, although I do not have too much
hands on knowledge about substitute handling code either.

>
> Konrad.

Best regards,
g_bor

-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

Re: Setuid programs

[Gábor Boskovits]

Hello,

Ludovic Courtès  ezt írta (időpont: 2020. szept. 16., Sze, 15:25):
>
> Hi,
>
> Gábor Boskovits  skribis:
>
> > I have two reasons for that: backwards compatibility is really
> > important, so we should not break it, and I believe this would not be
> > hard to do.
> > On the other hand it would be nice to have a more integrated backend,
> > and move as many things into the services infrastructure as practical,
> > and I think this is a good candidate for that. Wdyt?
>
> There’s already ‘setuid-program-service-type’.  I think the way forward
> would be to:
>
>   1. Define the  record type you propose.
>
>   2. Have ‘setuid-program-service-type’ accept that through its
>  extensions.  When it receives something else, it should
>  transparently turn it into a  record, for backward
>  compatibility, and emit a deprecation warning.
>
>   3. Document the OS ‘setuid-programs’ field as taking a list of such
>  records.
>
> How does that sound?

Sounds good to me. I will have a look.

>
> Thanks,
> Ludo’.

Best regards,
g_bor
-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

Re: [OUTREACHY] toward a proposal?

[Gábor Boskovits]

Thanks,

zimoun  ezt írta (időpont: 2020. szept. 12.,
Szo, 16:00):
>
> Dear,
>
> The command “guix time-machine” is really cool but today it is not easy
> to find the commit corresponding to one specific version.  For example,
> try to install the version 1.6.8 of the package ’msmtp’.
>
> A concrete example is described here [1].  And when reproducing
> scientific papers, the versions are not always provided but instead the
> dates are.  How to install the same ’msmtp’ as in 2018-12-08?
>
>
> The Guix Data Service helps for such situation:
>
> https://data.guix.gnu.org/repository/1/branch/master/package/msmtp/output-history
>
> but its database starts on 2019-01-01 (if I have correct).  It is an
> external service and will never collect data from all specifics channels
> (guix-past, your-name-it, etc.).  Well, it is a good complement and all
> the JSON files are under used, for example, to know if the package
> builds or not.  Another story.
>
>
> Today, the 2 previous use-cases are usually solved by cloning the
> repository from Savannah and then by invoking Git commands.  It is not
> fully satisfactory since this repository is already checked out, by
> default:
>
> ~/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq/
>
> Let this path affected to the environment variable $SRC. Then, to find
> the 2 commits, the user can run:
>
> --8<---cut here---start->8---
> $ git -C $SRC --date=short --format="%h  %cd  %s" | grep msmtp
> 5d2b9b0749  2020-08-26  gnu: msmtp: Update to 1.8.12.
> 56e1cc0c34  2020-06-10  gnu: msmtp: Update to 1.8.11.
> 70ebab5aa7  2020-05-09  gnu: msmtp: Update to 1.8.10.
> b93b7b2585  2020-03-29  gnu: msmtp: Don't rely on netcat to send
> queued messages.
> a4fd9423b0  2019-12-30  gnu: msmtp: Update to 1.8.7.
> 58da4b0a84  2019-10-02  gnu: msmtp: Update to 1.8.6.
> 214cbec2cf  2019-07-16  gnu: msmtp: Update to 1.8.5.
> 34e549d813  2019-07-11  gnu: msmtp: Install additional files.
> 06c86f166d  2019-04-29  gnu: msmtp: Update to 1.8.4.
> ce53048fb8  2019-02-14  gnu: msmtp: Update to 1.8.3.
> b8c0b9c1a3  2019-01-31  gnu: msmtp: Update to 1.8.2.
> 1460e77abf  2018-12-10  gnu: msmtp: Update to 1.8.1.
> 91b3a6d4db  2018-09-09  gnu: msmtp: Remove unneeded input.
> 37f9cfae43  2018-09-09  gnu: msmtp: Update to 1.8.0.
> 1a80f1a9e3  2018-07-11  gnu: msmtp: Update to 1.6.8.
> 899358d18a  2016-12-20  gnu: msmtp: Update to 1.6.6.
> d23d1ddf6e  2016-07-21  gnu: msmtp: Update to 1.6.5.
> 70dced54ed  2016-05-06  gnu: msmtp: Update to 1.6.4.
> 823e2ed4b3  2016-02-28  gnu: msmtp: Install msmtpq.
> 72d8b5baf4  2015-12-21  gnu: msmtp: Update to 1.6.3.
> 4c60ce4a6b  2015-11-06  gnu: msmtp: Update to 1.6.2.
> 0704788109  2015-03-19  gnu: msmtp: Use mirror:// URI.
> d6e941bc95  2014-12-09  gnu: add msmtp
> --8<---cut here---end--->8---
>
>
> The proposal is to implement the same result hiding all the plumbing
> details, i.e.,
>
>   guix git log --oneline | grep msmtp
>

This is very interesting. We should wait a bit for others to reply,
and evaluate if this proposal
can fill a full internship, or if it can be complemented with
something. I am all for improving user experience though.

> Well, naming is hard. :-)  Therefore, the subcommand could have another
> name (bikeshedding, bikeshedding :-)).
>
>
> The next steps could be:
>
> - take in account the channels, and maybe sort all the commits by dates
> - have an --format option
> - have an --grep option
> - etc.
>
> depending on the progress of the student.  IMHO, there are small
> actionable steps that fit how Outreachy program works (at least how I
> understand it works).
>
>
> Does it make sense?
> If yes, I volunteer to co-mentor, even if I am not sure to be enough
> qualified to do so.  BTW, co-mentoring is good.

I believe that you will make a good co-mentor, and thanks for volunteering.

>
> What do you think?
>
>
> [1] https://lists.gnu.org/archive/html/help-guix/2019-06/msg00098.html
>
>
> All the best,
> simon

Best regards,
g_bor

-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

Re: Setuid programs

[Gábor Boskovits]

Hello,

Christopher Lemmer Webber  ezt írta (időpont:
2020. szept. 10., Cs, 0:52):
>
> Christopher Lemmer Webber writes:
>
> > Gábor Boskovits writes:
> >
> >> Hello,
> >>
> >> Christopher Lemmer Webber  ezt írta (időpont:
> >> 2020. szept. 9., Sze, 21:00):
> >>>
> >>> Maxim Cournoyer writes:
> >>>
> >>> > Hello Gabor!
> >>> >
> >>> > Gábor Boskovits  writes:
> >>> >
> >>> >> Hello guix,
> >>> >>
> >>> >> I would like to propose an extension to how setuid programs are
> >>> >> currently handled. The last time I checked it could only do setuid and
> >>> >> setgid root. Some services, such as postfix need a more fine grained
> >>> >> setuid setup. I would propose a record type, such as:
> >>> >> (setuid
> >>> >> (program setuid-program)
> >>> >> (setuid setuid-setuid)
> >>> >> (setgid setuid-setgid)
> >>> >> (user setuid-user)
> >>> >> (group setuid-group))
> >>> >>
> >>> >> So that there is more fine grained control.
> >>> >>
> >>> >> I would also propose to move this to the services framework, so that
> >>> >> services could extend this field on demand.
> >>> >>
> >>> >> Wdyt?
> >>> >
> >>> > This sounds great!  I also encountered such limitation and tried to
> >>> > fixing it in https://issues.guix.info/41763, with some success (and an
> >>> > unresolved limitation pointed by Chriistopher) but I agree that using a
> >>> > record makes more sense and is more future proof.
> >>> >
> >>> > Maxim
> >>>
> >>> I'm eager to use Postfix on Guix (maybe it's me, but I just can't make
> >>> sense of the weird DSL that opensmtpd uses) so I guess if that's what's
> >>> necessary it already makes it a good idea.
> >>>
> >>> However I don't fully understand the syntax of what you proposed.  Let's
> >>> see if I can guess with a fake entry
> >>>
> >>> #~(setuid
> >>>;; The program to run, from the shady package
> >>>(program (string-append #$shady "/bin/scaryfoo")
> >>>;; Would this be a boolean?  If so should it be `setuid?`
> >> yes, this should be a bool, studi? looks good to me.
> >>>(setuid setuid-setuid)
> >>>;; Likewise?
> >>>(setgid setuid-setgid)
> >> yes, the same thing applies here.
> >>>;; Presumably the use we want to set this to
> >>>(user setuid-user)
> >> yes, this should just be the uid of the owner
> >>>;; Presumably the group we want to se this to
> >> this should be the gid.
> >>>(group setuid-group))
> >>>
> >>> ... right?
> >>>
> >>> I guess this could be done in a backwards compatible way;
> >>> %setuid-programs could either evaluate to strings or records, so the
> >>> "simpler" version can remain an option?
> >> Yes, it can be done this way. Actually I had a bit more general
> >> solution in mind,
> >> I feel there should be service to install a file from a store to a
> >> given place, and with all the access control available,
> >> like acl-s, if supported. And then provide the whole setuid thing as a
> >> backwards compatibility layer, somehow like you described.
> >> For now I guess creating this record type and implementing the
> >> extended setuid functionality would be a good first step.
> >
> > A service seems like a really good idea to me in that it feels the most
> > composable with how Guix currently approaches things.
>
> I feel like this one needs more "Guix maintainer" overview.
I agree, this would be nice.

  The current
> setuid-programs could be kept as legacy behavior that installs an
> additional service.  Thoughts?

I believe it should be kept and install an additional service.

I have two reasons for that: backwards compatibility is really
important, so we should not break it, and I believe this would not be
hard to do.
On the other hand it would be nice to have a more integrated backend,
and move as many things into the services infrastructure as practical,
and I think this is a good candidate for that. Wdyt?

Best regards,
g_bor
-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

Re: Setuid programs

[Gábor Boskovits]

Hello,

Christopher Lemmer Webber  ezt írta (időpont:
2020. szept. 9., Sze, 21:00):
>
> Maxim Cournoyer writes:
>
> > Hello Gabor!
> >
> > Gábor Boskovits  writes:
> >
> >> Hello guix,
> >>
> >> I would like to propose an extension to how setuid programs are
> >> currently handled. The last time I checked it could only do setuid and
> >> setgid root. Some services, such as postfix need a more fine grained
> >> setuid setup. I would propose a record type, such as:
> >> (setuid
> >> (program setuid-program)
> >> (setuid setuid-setuid)
> >> (setgid setuid-setgid)
> >> (user setuid-user)
> >> (group setuid-group))
> >>
> >> So that there is more fine grained control.
> >>
> >> I would also propose to move this to the services framework, so that
> >> services could extend this field on demand.
> >>
> >> Wdyt?
> >
> > This sounds great!  I also encountered such limitation and tried to
> > fixing it in https://issues.guix.info/41763, with some success (and an
> > unresolved limitation pointed by Chriistopher) but I agree that using a
> > record makes more sense and is more future proof.
> >
> > Maxim
>
> I'm eager to use Postfix on Guix (maybe it's me, but I just can't make
> sense of the weird DSL that opensmtpd uses) so I guess if that's what's
> necessary it already makes it a good idea.
>
> However I don't fully understand the syntax of what you proposed.  Let's
> see if I can guess with a fake entry
>
> #~(setuid
>;; The program to run, from the shady package
>(program (string-append #$shady "/bin/scaryfoo")
>;; Would this be a boolean?  If so should it be `setuid?`
yes, this should be a bool, studi? looks good to me.
>(setuid setuid-setuid)
>;; Likewise?
>(setgid setuid-setgid)
yes, the same thing applies here.
>;; Presumably the use we want to set this to
>(user setuid-user)
yes, this should just be the uid of the owner
>;; Presumably the group we want to se this to
this should be the gid.
>(group setuid-group))
>
> ... right?
>
> I guess this could be done in a backwards compatible way;
> %setuid-programs could either evaluate to strings or records, so the
> "simpler" version can remain an option?
Yes, it can be done this way. Actually I had a bit more general
solution in mind,
I feel there should be service to install a file from a store to a
given place, and with all the access control available,
like acl-s, if supported. And then provide the whole setuid thing as a
backwards compatibility layer, somehow like you described.
For now I guess creating this record type and implementing the
extended setuid functionality would be a good first step.
>
>  - Chris
Best regards,
g_bor
-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

[OUTREACHY] Call for mentors

[Gábor Boskovits]

Hello guix,

This is a call for mentors for the 2020-2021 Outreachy Round:

There are some ideas that were brought up earlier, for example the
list of ideas for GSoC 2020:
https://libreplanet.org/wiki/Group:Guix/GSoC-2020, except the network
booting project.

And the previous round proposal for creating a netlink binding for guile:
https://www.outreachy.org/outreachy-may-2020-internship-round/communities/gnu-guix/create-netlink-bindings-in-guile/cfp/

Also if you should have any new ideas feel free to start discussion
threads on the guix-devel mailing list, tagged with [OUTREACHY].

The proposal submission deadline is 24th of September. Please keep in mind that
creating a proposal that can be approved might require several
iterations, so new proposals should aim for the 17th of September, or
before, so that we have time to refine them.

You can submit your internship proposals through this link:
https://www.outreachy.org/communities/cfp/gnu-guix/

Should you have any questions, please feel free to contact me.

Best regards,
g_bor
-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

[OUTREACHY] TParticipation of Guix for the 2020-2021 round

[Gábor Boskovits]

Hello guix,

The participation request has been approved by the Outreachy
Organizers for this round.

Best regards,
g_bor
-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

Outreachy 2020-2021 round participation

[Gábor Boskovits]

Guix is now signed up to participate in this round of Outreachy.

Important information for prospective applicants: initial application
deadline is 20th Sept. 2020 at 1600UTC.

Important information for prospective mentors: the proposal submission
deadline is 24th Sept. 2020 at 1600UTC. If you submitted a proposal for a
previous round, and no intern was accepted for the proposal and you are
still willing to mentor that project, then the proposal should be
resubmitted for this round. If you have a new idea, please feel free to
start a discussion thread on guix-devel, so that we can find out if that is
a good candidate for Outreachy and we can refine the proposal. Please tag
discussion threads with [OUTREACHY] on the subject line, so that my mail
filters can pick them up. Thanks.

Best regards,
g_bor

Setuid programs

[Gábor Boskovits]

Hello guix,

I would like to propose an extension to how setuid programs are
currently handled. The last time I checked it could only do setuid and
setgid root. Some services, such as postfix need a more fine grained
setuid setup. I would propose a record type, such as:
(setuid
(program setuid-program)
(setuid setuid-setuid)
(setgid setuid-setgid)
(user setuid-user)
(group setuid-group))

So that there is more fine grained control.

I would also propose to move this to the services framework, so that
services could extend this field on demand.

Wdyt?

Best regards,
g_bor
-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

Re: wip-postfix

[Gábor Boskovits]

Hello Jan,

Jan Nieuwenhuizen  ezt írta (időpont: 2020. aug. 10., Hét
8:50):

> Gábor Boskovits writes:
>
> Hello!
>
> >> Jan Nieuwenhuizen  ezt írta (időpont: 2020. márc.
> 17., Ke 9:02):
> >
> >  Gábor Boskovits writes:
>
> I took the liberty of rebasing wip-postfix on latest master and
> found it does not compile
>
> --8<---cut here---start->8---
> gcc -fPIC -I. -I../../include -DNO_EAI -DDEF_SMTPUTF8_ENABLE=\"no\"
> -DHAS_DEV_URANDOM
> -DDEF_SHLIB_DIR=\"/gnu/store/hbdrbb84krvjvw58vmr1pvzb6l3gbmyv-postfix-minimal-3.4.8\"
> -DUSE_DYNAMIC_LIBS -DUSE_DYNAMIC_MAPS -Wmissing-prototypes -Wformat
> -Wno-comment -fPIC -g -O -I. -I../../include -DLINUX5 -c dns_str_resflags.c
> dns_str_resflags.c:55:13: warning: RES_AAONLY is deprecated
>  "RES_AAONLY", RES_AAONLY,
>  ^
> dns_str_resflags.c:57:13: warning: RES_PRIMARY is deprecated
>  "RES_PRIMARY", RES_PRIMARY,
>  ^~~
> dns_str_resflags.c:63:22: error: ‘RES_INSECURE1’ undeclared here (not in a
> function); did you mean ‘RES_RECURSE’?
>  "RES_INSECURE1", RES_INSECURE1,
>   ^
>   RES_RECURSE
> --8<---cut here---end--->8---
>
> Luckily, that was easily fixed by updating postfix to 3.5.0.
>

Thanks for having a look.

>
> >>  When I hack around and create /etc/ailases.db, it works.
> > I would like to add a service config for this.
>
> I found we already have mail-aliases-service-type, so I used that,
> together with running postalias.  Now, queuing mail works ootb...but
> delivery seems not to work: it remains queued.
>
> I rebased wip-postfix and added a couple of patches for this.  Please
> feel free to revert them if you don't like it :-)
>
> When starting postfix like so
>
> --8<---cut here---start->8---
> ./pre-inst-env guix system vm gnu/system/examples/postfix.tmpl`\
>--nographic -m 1G\
>--nic
> user,model=virtio-net-pci,hostfwd=tcp::12025-:25,hostfwd=tcp:127.0.0.1:12022
> -:
> --8<---cut here---end--->8---
>
> I'm seeing
>
> --8<---cut here---start->8---
> 07:39:18 janneke@dundal:~/src/guix/wip-postfix [env]
> $ telnet localhost 12025
> Trying 127.0.0.1...
> Connected to localhost.
> Escape character is '^]'.
> 220 komputilo.localdomain ESMTP Postfix
> mail from: root
> mail from: root
> 250 2.1.0 Ok
> rcpt to: alice
> rcpt to: alice
> 250 2.1.5 Ok
> data
> data
> 354 End data with .
> hello Alice!
> hello Alice!
> .
> .
> 250 2.0.0 Ok: queued as E26BA3116
> quit
> quit
> 221 2.0.0 Bye
> Connection closed by foreign host.
> 08:03:53 janneke@dundal:~/src/guix/wip-postfix [env]
> $ ssh -p 12022 root@localhost
> /gnu/store/mydn0wr0bs7mz3rx9fwihpma26r0dpqq-postfix-minimal-3.5.0/mailq -C
> /gnu/store/nj5pa9l9zy6vx5484pbdsqnilva8bivc-postfix-config-dir
> -Queue ID-  --Size-- Arrival Time -Sender/Recipient---
> E26BA3116*  175 Mon Aug 10 08:00:50  root@komputilo.localdomain
>  alice@komputilo.localdomain
>
> -- 0 Kbytes in 1 Request.
> --8<---cut here---end--->8---
>
> Ideas?
>

I will have a look early next week. Most probably the setuid stuff is
missing, and access is denied to something.

>
> >>  It looks like most everything is installed in a single, flat directory
> >>
> >>  /gnu/store/pyv0rpd6zs0m2i482cb8qxd6mhf5b47z-postfix-minimal-3.4.8
> >>
> >>  executables, copies of readmes, (unused?) config files (main.cf,
> >>  aliases)?
> >
> > Yes, but can be easily separated. The config files are installer
> > generated, and not used.
>
> Ok => TODO :-)
>
> >> Anyhow, this is a great start; next Mailman?
> >
> > One thing that blocks me from finishing this is that the setuid
> > programs in the os declatation should be extended, so that we can use
> > the privilege separation of postfix. I would like to propose a patch
> > later this week.
>
> Any insight here, something blocking maybe?
>

Nothing in particular. I had little time recently. I just finished a bigger
project, and I was on holiday. I will try to propose an interface for this
next week.


> Greetings,
> Janneke
>

Regards,
g_bor

>
> Jan (janneke) Nieuwenhuizen (5):
>   gnu: postfix-minimal: Updato to 3.5.0.
>   system: examples: Add postfix.tmpl.
>   gnu: postfi

Re: [OUTREACHY]: Integration of desktop environments into GNU Guix

[Gábor Boskovits]

Hello,

Ludovic Courtès  ezt írta (időpont: 2020. máj. 6., Sze 16:19):

> Hi!
>
> Raghav Gururajan  skribis:
>
> > I would like to thank Guix Maintainers, Gábor Boskovits and Danny
> > Milosavljevic; for selecting me as an intern for this project. I am gald
> to be
> > part of Guix and excited to get started. :-)
>
> Yay, great that you made it!  Welcome again!  :-)
>
> > I am opening this email thread for communication, discussion and
> progression
> > regarding this project. I request everyone participating in this thread
> to
> > always CC: Gábor Boskovits (Co-Ordinator), Danny Milosavljevic (Mentor),
> Tobias
> > Geerinckx-Rice (Co-Mentor) and myself (Intern).
>
> Thanks a lot to Gábor, Danny, and Tobias for coordinating and mentoring.
>
> We could publish a blog post in the coming days to introduce the
> Outreachy (and GSoC?) interns and what they’ll be working on.
>

I have already created a draft, and sent it to the blog alias for review.


> I guess you’re used to it now, but don’t hesitate to ask for guidance
> and feedback on IRC and the mailing lists in addition to/instead of
> bugging your mentors!
>
> Ludo’.
>

Best regards,
g_bor

>
>

Outreachy

[Gábor Boskovits]

Hello,

On the Outreachy ML the following was communicated:

The new Outreachy intern announcement date is May 4.

They apologize for the inconvenience, and thank for patience.

This is to keep in sync with GSoC.

Mentors, please keep in mind not communicate the selections before the
announcement.

Applicants, I am sorry about this confusion and thanks for your understanding.

Best regards,
g_bor

-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

Re: core-updates call for testing

[Gábor Boskovits]

Hello,

Marius Bakke  ezt írta (időpont: 2020. ápr. 24., Pén
18:25):

> sirgazil  writes:
>
> >   On Fri, 24 Apr 2020 03:20:41 + sirgazil 
> wrote 
> >  >   On Thu, 23 Apr 2020 23:24:23 + Marius Bakke <
> mba...@fastmail.com> wrote 
> >  >  > Hello Guix!
> >  >  >
> >  >  > The "core-updates" branch is ready for testing!  According to 'guix
> >  >  > weather', the substitute coverage is slightly better than on
> "master"
> >  >  > for x86_64.  You can get it by running:
> >  >  >
> >  >  >   guix pull --branch=core-updates
> >  >  >
> >  >  > Please try upgrading your profiles and systems and file bugs for
> >  >  > anything that does not work for you.  GNOME users in particular are
> >  >  > encouraged to try the new GNOME 3.34 and report any regressions.
> >  >
> >  > I pulled from core-updates without problems, but "guix upgrade"
> failed.
> >  >
> >  > First, when running "guix upgrade", I got the following message,
> which I think is confusing because I use GNU, not Guix on a foreign distro:
> >  >
> >  > $ guix upgrade
> >  > guile: warning: failed to install locale
> >  > hint: Consider installing the `glibc-utf8-locales' or
> `glibc-locales' package and defining `GUIX_LOCPATH', along these lines:
> >  >
> >  >  guix package -i glibc-utf8-locales
> >  >  export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale"
> >  >
> >  > See the "Application Setup" section in the manual, for more info.
> >  >
> >  > Then, everything was going alright, until building emacs-guix
> derivation failed:
> >  >
> >  > building
> /gnu/store/6kdl0pyv7i571d6b4vcxskr75ffqw1mk-emacs-guix-0.5.2.drv...
> >  > \ 'configure' phasebuilder for
> `/gnu/store/6kdl0pyv7i571d6b4vcxskr75ffqw1mk-emacs-guix-0.5.2.drv' failed
> with exit code 1
> >  > build of
> /gnu/store/6kdl0pyv7i571d6b4vcxskr75ffqw1mk-emacs-guix-0.5.2.drv failed
> >  > View build log at
> '/var/log/guix/drvs/6k/dl0pyv7i571d6b4vcxskr75ffqw1mk-emacs-guix-0.5.2.drv.bz2'.
> >  > guix upgrade: error: build of
> `/gnu/store/6kdl0pyv7i571d6b4vcxskr75ffqw1mk-emacs-guix-0.5.2.drv' failed
> >  >
> >  >
> >  > The build log said:
> >  >
> >  > starting phase `configure'
> >  > source directory:
> "/tmp/guix-build-emacs-guix-0.5.2.drv-0/emacs-guix-0.5.2" (relative from
> build: ".")
> >  > build directory:
> "/tmp/guix-build-emacs-guix-0.5.2.drv-0/emacs-guix-0.5.2"
> >  > configure flags:
> ("CONFIG_SHELL=/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/bash"
> "SHELL=/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/bash"
> "--prefix=/gnu/store/bqplgazij77awh62579p56wbnxdb1c2l-emacs-guix-0.5.2"
> "--enable-fast-install" "--build=x86_64-unknown-linux-gnu")
> >  > configure: WARNING: unrecognized options: --enable-fast-install
> >  > checking for a BSD-compatible install...
> /gnu/store/57xj5gcy1jbl9ai2lnrqnpr0dald9i65-coreutils-8.32/bin/install -c
> >  > checking whether build environment is sane... yes
> >  > checking for a thread-safe mkdir -p...
> /gnu/store/57xj5gcy1jbl9ai2lnrqnpr0dald9i65-coreutils-8.32/bin/mkdir -p
> >  > checking for gawk... gawk
> >  > checking whether make sets $(MAKE)... no
> >  > checking whether make supports nested variables... yes
> >  > checking whether make supports nested variables... (cached) yes
> >  > checking for pkg-config...
> /gnu/store/krpyb0zi700dcrg9cc8932w4v0qivdg9-pkg-config-0.29.2/bin/pkg-config
> >  > checking pkg-config is at least version 0.9.0... yes
> >  > configure: checking for guile 2.2
> >  > configure: checking for guile 2.0
> >  > configure: error:
> >  > No Guile development packages were found.
> >  >
> >  > Please verify that you have Guile installed.  If you installed
> Guile
> >  > from a binary distribution, please verify that you have also
> installed
> >  > the development packages.  If you installed it yourself, you
> might need
> >  > to adjust your PKG_CONFIG_PATH; see the pkg-config man page for
> more.
> >  >
> >  > command
> "/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/bash"
> "./configure"
> "CONFIG_SHELL=/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/bash"
> "SHELL=/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/bash"
> "--prefix=/gnu/store/bqplgazij77awh62579p56wbnxdb1c2l-emacs-guix-0.5.2"
> "--enable-fast-install" "--build=x86_64-unknown-linux-gnu" failed with
> status 1
> >  >
> >  >
> >
> >
> > Then, I decided to remove emacs-guix, and try again to upgrade. This
> time, one of my packages in a custom channel failed with "no code for (term
> ansi-color)" (the package definition:
> https://gitlab.com/sirgazil/guix-channel-x/-/blob/master/sirgazil-x/packages/guile.scm#L13).
> This is not a new package in my profile, I've been using it for a long
> time. Since both error seemed to be related to Guile, I removed all
> Guile-related packages from 

Re: Reflections on the release process

[Gábor Boskovits]

Hello Ludo,

Ludovic Courtès  ezt írta (időpont: 2020. ápr. 22., Sze
22:09):

> Hi!
>
> zimoun  skribis:
>
> > On Wed, 15 Apr 2020 at 22:18, Ludovic Courtès  wrote:
> >
> >> 4. We lack a clear way to mark bugs as release-critical.  I’m really
> >> happy Florian, Mathieu, and I have been able to work together and squash
> >> bugs one by one (thank you!).  Still, it would have been better if we
> >> could have tagged which is release-critical and which is not, to prevent
> >> misunderstandings such as regarding the NVMe bug:
> >> .  Can Debbugs help?  The GCC
> >> folks have a system that sends email with an update on the number of
> >> release-critical bugs.  I’m sure we can learn from how others deal with
> >> that.
> >
> > The first easy step seems to tag the relevant bug as release-critical
> > or simply rc.
> > Currently, the tags nomal, security, serious, moreinfo, important,
> > unreproducible are used in Debbugs.
>
> Yes, but how do we do that?  I don’t think Debbugs supports a
> “release-critical” tag, does it?  Or perhaps we could take advantage of
> Mumi to add special tags or something?
>

Actually the description of the severity level serious says its intended
meaning is making a bug release critical. I believe we could simply use
that.


> > Then a second step could be to collect these release critical bugs and
> > display them on issues.guix.gnu.org (or data.guix.gnu.org) for example
> > remplacing the circle exclamation mark by a red triangle exclamation
> > mark (or any really visible symbol). And because the "recent
> > activities" is already sorted, it becomes easier to point the
> > remaining release critical bugs, the ones stuck, etc.
>
> Agreed.
>
> >> For the other issues, I’m interested in any ideas you may have!
> >
> > About the "frozen" window, does it make to schedule it in advance? For
> > example a couple of months before.
> > And for example, does it make sense to say: at least one release each
> > year on the March 14th (Pi day ;-) or approximately.
> > Because in general FOSDEM is at the beginning of February and it is a
> > big party where some of us come then back home refill of energy, we
> > could agree around this date (beginning of Feb.) on the frozen window
> > date (say end of February) and then release around middle of March.
> > From my point of view, using the Guix Days as catalyst for releasing
> > should help the process.
>
> I think there’s no question we want more than one release per year.  For
> that to happen, we should make sure the process is well documented, as
> smooth as possible, largely automated, and not tied to a single person
> (ahem…).
>
> Once we have that, plus some planning such as marking RC-critical bugs,
> it’ll be easier to make releases IMO.
>
> Thanks,
> Ludo’.
>

Best regards,
g_bor

>
>

GSoC and Outreachy intern selection communication

[Gábor Boskovits]

To: GSoC and Outreachy mentors

First of all, I would like to thank all mentors for the work done so far.

I would also like to remind you to not communicate your intern
selection before the official
announcement.

Best regards,
g_bor
-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

Fwd: [Outreachy] Intern selections due tomorrow, April 17

[Gábor Boskovits]

To: Outreachy mentors

I have received the following communication from the Outreachy organizers:

Should you need assistance, please contact me.

-- Forwarded message -
Feladó: Sage Sharp - Outreachy Organizer 
Date: 2020. ápr. 16., Csü 23:01
Subject: [Outreachy] Intern selections due tomorrow, April 17
To: 


Hi mentors,

Please submit your intern selections ASAP. Outreachy organizers need to
follow up with applicants who may have time commitment changes. We can
only do that once mentors have picked their interns.

April 17 is the deadline for intern selections. Outreachy organizers
will be following up with applicants about changed time commitments and
finalizing intern selections next week.

Some communities have more strong applicants than they have funding. In
that case, communities can ask for interns to be sponsored through the
Outreachy general fund.

Please note that we cannot make decisions about Outreachy general
funding request until we review requests across all communities. Please
submit your intern selections ASAP.

We will update communities with general funding decisions after Tuesday.

Again, the deadline for intern selection is Friday, April 17.

Sage Sharp, Outreachy Organizer
___
Mentors mailing list
ment...@lists.outreachy.org
https://lists.outreachy.org/cgi-bin/mailman/listinfo/mentors

[GSoC ACTION REQUIRED] Send me the number of slots requested

[Gábor Boskovits]

To: GSoC mentors

I feel that my previous communication regarding this matter was not clear,
so I am try to rephrase this:
Please send the number of slot requests with the name of the subproject to
me, so that I can pass the overall number to the GNU org admins.

It also seems that the previous communication regarding the mentor
information needed fell through the cracks.

So if you wish to mentor, but you do not have your invitation yet, then you
should send the following information in private mail to the GNU org admins
to receive your invitation:

Name
Email
AltEmail
Phone
Project: guix

Best regards,
g_bor

Re: [gnu-soc] [IMPORTANT] Next steps for participating projects and mentors

[Gábor Boskovits]

Hello Danny,

Danny Milosavljevic  ezt írta (időpont: 2020. ápr.
14., Ke 19:45):

> Hi Gabor,
>
> when I try to log in at https://summerofcode.withgoogle.com I get:
>
> >403
> >Ruh roh. Something went wrong here.
> >Current Google account: danny.m...@gmail.com
> >
> >You don't have a GSoC account.
> >[Get Started]
>
> When I try to create an account using [Get Started], there are only the
> choices "organization" and "student"--both of which I don't want.
>

That is correct, you can't use that ui.

>
> Also, I'm pretty sure I am on the GSoC Mentors mailing list so I should
> still have an account from last year, right?
>

Unfortunately that is not so. Registration is needed every year. You should
have received an invitation from the GNU org admins when you provided them
with you mentor information. That invitation should ensure that you account
gets registered and activated. If you did not receive your invitation, then
you should contact the GNU org admins on the gnu-soc mailing list, as only
they can invite you. If needed I can dig up the earlier communication, so
that you know what information they need.


> (I'd like to mentor the PXE thing)
>

Thanks, that is so nice.

Best regards,
g_bor

>

Fwd: [gnu-soc] [IMPORTANT] Next steps for participating projects and mentors

[Gábor Boskovits]

To GSoC mentors:

I have received the following communication from the GNU coordinators:


-- Forwarded message -
Feladó: Jose E. Marchesi 
Date: 2020. ápr. 14., Ke 9:54
Subject: [gnu-soc] [IMPORTANT] Next steps for participating projects and
mentors
To: 



Hi people!

At this point students have sent proposals that can be reviewed in the
GSOC page [1].  By now you should have a good idea of how many proposals
you can/want to mentor.

So, we are asking you mentors to do the following this week, before
Saturday 18 April:

1) For each proposal you want to accept, please make sure there is at
   least one mentor in the "Want to mentor list".  Having a backup
   mentor is highly desirable.

2) Please send to this list the number of "essential slots" and "desired
   slots" for your GNU program.  As always we will be using these
   numbers to determine how many slots we will ask Google for, and to
   decide how to distribute the number of slots we get allocated.

Also note that we are still in time to register more mentors.
Thanks!

[1] https://summerofcode.withgoogle.com

Please make our internal deadline April 16th, 1600 UTC, so that I have time
to collect the responses, and to send out a draft to the ml, so anyone
missing can chime in.

Thanks

Best regards,
g_bor

[URGENT ACTION REQUIRED OUTREACHY] Otreachy final application deadline

[Gábor Boskovits]

To: All Outreacy Applicants

The Outreachy final application deadline for this round is
April 7, 2020
at 4pm UTC

Please make sure to submit your final application before the deadline,
otherwise we won't be able to select you as an intern.

Best regards,
g_bor
-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

Re: Adding a %desktop-packages

[Gábor Boskovits]

Hello,

Ludovic Courtès  ezt írta (időpont: 2020. ápr. 6., Hét 10:02):

> Hi Joshua,
>
> Joshua Branson  skribis:
>
> > This is slightly unrelated, but your email reminded me.
> >
> > How about we add a %desktop-packages variable?  I remember reading a bug
> > report about possibly ungoogled-chromium or some package not working
> > properly, because the user did not install a font.  Perhaps if people
> > are using a %desktop, there should be some %desktop-packages that most
> > users will want installed by default.  Packages would include a web
> > browser, one system font, etc.
>
> I think we should address the font issue.  A ‘%desktop-packages’ is
> bound to never be satisfactory for anyone because it’s so subjective.
>

Yes, this will not be statisfactory. However I believe that doing something
like this would be great:
define icecat-recommended
define browser-recommended icecat-recommended
define desktop-recommended (append desktop-recommended base-packages) with
deduplication.
I believe this approach has two merits:
We can provide an easy setup for those interested, and inspectable for
those who would like a working system, but want to configure certain aspects
And we can state the officially recommended software for a given task, so
that it is possible to focus efforts on these.

>
> Thanks,
> Ludo’.
>

Best regards,
g_bor

>
>

Re: Adding a %desktop-packages

[Gábor Boskovits]

Hello,

John Soo  ezt írta (időpont: 2020. ápr. 4., Szo 2:23):

> Hi there,
>
> I am on board with providing some predefined lists of packages.
>
> I raised the idea of providing smaller lists of packages that might go
> well together instead of one large %desktop-packages. One reason to do
> this, for instance, might be to not make someone who wants to use btrfs
> always import the ext4 packages. Or not lock someone into using nettools
> if they are using iproute2, etc.
>
> Similarly, I think that many users, myself included, use a manifest file
> to manage user packages. It would help to have finer grained
> package lists so that the manifests could reuse them and not be
> requiring system basics along with it.
>
> What do you think?
>

This is more in line with my thoughts. Also, if we have some of these fine
grained lists, it would be easy to provide collections of these, so we can
do both things, but in a more useful way.

>
> - John
>

Best regards,
g_bor

>

[URGENT, ACTION REQUIRED] GSoC final proposal submission deadline

[Gábor Boskovits]

To all GSoC applicants:

According to the GSoC 2020 timeline the final deadline for submitting a proposal
is:
March 31 18:00 UTC

You can find further information here:
https://google.github.io/gsocguides/student/writing-a-proposal

Please make sure that your final PDF proposal is submitted on the GSoC site
before the deadline, otherwise we will not be able to select you.

Thank you for all the work done so far.

Best regards,
g_bor
-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

Grafting segfault

[Gábor Boskovits]

Hello Guix,

Pulling from an older guix version yesterday, I have noticed that on
system reconfigure the grafting sometimes failed with sigsegv.

After several retries, segfaulting always on different packages, the
system build finished successfully. I do not have a way to reliable
trigger this problem. It is definitely indeterministic. As it happens
in the build phase, it does not cause real problem when it is noticed,
and retried. This is all the information I have on the issue so far.

Best regards,
g_bor
-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

Re: Guix master: Lint warnings: inputs which should be native-inputs etc

[Gábor Boskovits]

Hello,

Danny Milosavljevic  ezt írta (időpont: 2020. márc.
23., Hét 11:02):

> Hi,
>
> so I've been using the Guix Data Service and it found a whole load of
> linter
> warnings.  150 warnings for inputs that should probably be native inputs:
>
>
> http://data.guix.gnu.org/revision/d4842a7c478230b7c12e65d04106db1e14c98cac/lint-warnings?package_query==inputs-should-be-native_query==linter=message=location

This is just a related question: do we have a way to tell the linter that
this should be ignored, and to tell it that this package is affected by
something that the linter can not see.
One example is when something usually is a native input, but for the
package considered it really should be input.
Another example is security fixing. We might fix something by a patch, and
mark the package not affected, and conversely, we might have to carry a
vulnerable patch to a version otherwise not affected. Wdyt?

>
>
> It also found some more:
>
> http://data.guix.gnu.org/revision/d4842a7c478230b7c12e65d04106db1e14c98cac
>
> For example 176 unstable tarballs.
>
> And 7 inputs should not be inputs, all of them python-setuptools, in:
>
> python2-virtualenv
> python-get-version
> python-jaraco-packaging
> python-legacy-api-wrap
> python-sphinx-copybutton
> python-virtualenv
> tensorflow
>
Best regards,
g_bor

>

Fwd: [gnu-soc] [IMPORTANT] Mentors invitations sent!

[Gábor Boskovits]

Hello,

I have received the following communication from the GNU GSoC admins.
Please contact them if you have problems on the gnu-soc list.

-- Forwarded message -
Feladó: Jose E. Marchesi 
Date: 2020. márc. 23., Hét 10:10
Subject: [gnu-soc] [IMPORTANT] Mentors invitations sent!
To: 



Hi people.

We just sent invitations for everyone that sent us their mentor details.
At this point, you should receive an invitation from Google.  Please let
us know in this list if you don't receive it today.

Salud!

Re: Frequent locales problems for new users

[Gábor Boskovits]

Hello,

Ludovic Courtès  ezt írta (időpont: 2020. márc. 21., Szo
16:37):

> Hi Leo,
>
> Leo Famulari  skribis:
>
> > On Wed, Mar 18, 2020 at 04:07:22PM +0100, Ludovic Courtès wrote:
> >> As for ‘glibc-utf8-locales’ vs. ‘glibc-locales’: the reason for choosing
> >> the former by default over the latter is size (14 MiB vs. 917 MiB).
> >
> > Oof! I was going by the manual, which says 110 MiB. That does change
> > things...
>
> Yes, I was also surprised.
>
> The patch below produces a package that includes all the UTF-8 locales
> (actually I had written that patch long ago, it feels like we’re running
> in circles :-)).
>
> It takes ages to build, and when it’s finally done:
>
> --8<---cut here---start->8---
> $ ./pre-inst-env guix build -e '((@@ (gnu packages base)
> make-glibc-utf8-locales/full))'
> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
> substituting /gnu/store/jdfs3xvlnj272475yja6bjrprfsgnkdd-glibc-2.29...
> downloading from
> https://ci.guix.gnu.org/nar/lzip/jdfs3xvlnj272475yja6bjrprfsgnkdd-glibc-2.29.
> ..
>  glibc-2.29  8.2MiB
>  1.8MiB/s 00:05 [##] 100.0%
>
> building
> /gnu/store/w08zi9vnkd7bxpfvm5lgjyb30i7k7sw4-glibc-supported-utf8-locales.scm.drv...
> successfully built
> /gnu/store/w08zi9vnkd7bxpfvm5lgjyb30i7k7sw4-glibc-supported-utf8-locales.scm.drv
> building
> /gnu/store/ps6wh05pwjp5b0l9rh2yglv3sggpgcw4-glibc-utf8-locales-2.29.drv...
> successfully built
> /gnu/store/ps6wh05pwjp5b0l9rh2yglv3sggpgcw4-glibc-utf8-locales-2.29.drv
> /gnu/store/p0knl9ggxk91x87ww702g2x78jxy1vgf-glibc-utf8-locales-2.29
> ludo@ribbon ~/src/guix$ guix size
> /gnu/store/p0knl9ggxk91x87ww702g2x78jxy1vgf-glibc-utf8-locales-2.29 | tail
> -1
> total: 855.7 MiB
> --8<---cut here---end--->8---
>
> So I think that’s when we reached the conclusion that we needed
> parameterized packages to allow users to choose the locale(s) they need
> or special support in ‘guix package’.
>

I believe we could also add individual locales as outputs. Then we just
have to make sure that they are included to the LOCPATH. I believe we could
do this to the frequently used locales, and direct users to only install
out when they don't find an output with their locale. Wdyt?

>
> :-/
>
> Attached is the list of supported UTF-8 locales, 312 in total.
>
> Thoughts?  How do other distros deal with this?  Are we missing some
> trick to compress locale data?
>
> Ludo’.
>
g_bor

>
> ("aa_DJ"
>  "aa_ER"
>  "aa_ER@saaho"
>  "aa_ET"
>  "af_ZA"
>  "agr_PE"
>  "ak_GH"
>  "am_ET"
>  "an_ES"
>  "anp_IN"
>  "ar_AE"
>  "ar_BH"
>  "ar_DZ"
>  "ar_EG"
>  "ar_IN"
>  "ar_IQ"
>  "ar_JO"
>  "ar_KW"
>  "ar_LB"
>  "ar_LY"
>  "ar_MA"
>  "ar_OM"
>  "ar_QA"
>  "ar_SA"
>  "ar_SD"
>  "ar_SS"
>  "ar_SY"
>  "ar_TN"
>  "ar_YE"
>  "ayc_PE"
>  "az_AZ"
>  "az_IR"
>  "as_IN"
>  "ast_ES"
>  "be_BY"
>  "be_BY@latin"
>  "bem_ZM"
>  "ber_DZ"
>  "ber_MA"
>  "bg_BG"
>  "bhb_IN"
>  "bho_IN"
>  "bho_NP"
>  "bi_VU"
>  "bn_BD"
>  "bn_IN"
>  "bo_CN"
>  "bo_IN"
>  "br_FR"
>  "brx_IN"
>  "bs_BA"
>  "byn_ER"
>  "ca_AD"
>  "ca_ES"
>  "ca_ES@valencia"
>  "ca_FR"
>  "ca_IT"
>  "ce_RU"
>  "chr_US"
>  "cmn_TW"
>  "crh_UA"
>  "cs_CZ"
>  "csb_PL"
>  "cv_RU"
>  "cy_GB"
>  "da_DK"
>  "de_AT"
>  "de_BE"
>  "de_CH"
>  "de_DE"
>  "de_IT"
>  "de_LI"
>  "de_LU"
>  "doi_IN"
>  "dsb_DE"
>  "dv_MV"
>  "dz_BT"
>  "el_GR"
>  "el_CY"
>  "en_AG"
>  "en_AU"
>  "en_BW"
>  "en_CA"
>  "en_DK"
>  "en_GB"
>  "en_HK"
>  "en_IE"
>  "en_IL"
>  "en_IN"
>  "en_NG"
>  "en_NZ"
>  "en_PH"
>  "en_SC"
>  "en_SG"
>  "en_US"
>  "en_ZA"
>  "en_ZM"
>  "en_ZW"
>  "eo"
>  "es_AR"
>  "es_BO"
>  "es_CL"
>  "es_CO"
>  "es_CR"
>  "es_CU"
>  "es_DO"
>  "es_EC"
>  "es_ES"
>  "es_GT"
>  "es_HN"
>  "es_MX"
>  "es_NI"
>  "es_PA"
>  "es_PE"
>  "es_PR"
>  "es_PY"
>  "es_SV"
>  "es_US"
>  "es_UY"
>  "es_VE"
>  "et_EE"
>  "eu_ES"
>  "fa_IR"
>  "ff_SN"
>  "fi_FI"
>  "fil_PH"
>  "fo_FO"
>  "fr_BE"
>  "fr_CA"
>  "fr_CH"
>  "fr_FR"
>  "fr_LU"
>  "fur_IT"
>  "fy_NL"
>  "fy_DE"
>  "ga_IE"
>  "gd_GB"
>  "gez_ER"
>  "gez_ER@abegede"
>  "gez_ET"
>  "gez_ET@abegede"
>  "gl_ES"
>  "gu_IN"
>  "gv_GB"
>  "ha_NG"
>  "hak_TW"
>  "he_IL"
>  "hi_IN"
>  "hif_FJ"
>  "hne_IN"
>  "hr_HR"
>  "hsb_DE"
>  "ht_HT"
>  "hu_HU"
>  "hy_AM"
>  "ia_FR"
>  "id_ID"
>  "ig_NG"
>  "ik_CA"
>  "is_IS"
>  "it_CH"
>  "it_IT"
>  "iu_CA"
>  "ja_JP"
>  "ka_GE"
>  "kab_DZ"
>  "kk_KZ"
>  "kl_GL"
>  "km_KH"
>  "kn_IN"
>  "ko_KR"
>  "kok_IN"
>  "ks_IN"
>  "ks_IN@devanagari"
>  "ku_TR"
>  "kw_GB"
>  "ky_KG"
>  "lb_LU"
>  "lg_UG"
>  "li_BE"
>  "li_NL"
>  "lij_IT"
>  "ln_CD"
>  "lo_LA"
>  "lt_LT"
>  "lv_LV"
>  "lzh_TW"
>  "mag_IN"
>  "mai_IN"
>  "mai_NP"
>  "mfe_MU"
>  "mg_MG"
>  "mhr_RU"
>  "mi_NZ"
>  "miq_NI"
>  "mjw_IN"
>  "mk_MK"
>  "ml_IN"
>  "mn_MN"
>  "mni_IN"
>  "mr_IN"
>  "ms_MY"
>  "mt_MT"
>  "my_MM"
>  "nan_TW"
>  "nan_TW@latin"
>  "nb_NO"
>  "nds_DE"
>  "nds_NL"
>  "ne_NP"
>  "nhn_MX"
>  

Re: Plan for a release!

[Gábor Boskovits]

Hello,

Mathieu Othacehe  ezt írta (időpont: 2020. márc. 20.,
Pén 11:52):

>
> Hey,
>
> >> Done, but it’d be nice to add more test of the installer!
> >
> > I can help on that. Maybe adding:
> >
> > * More partitioning patterns
> > * More DE & services
>
> Turns out, when selecting GNOME in choose-services call of (gnu tests
> install), it triggers downloads during "guix system init ..." call.
>
> I guess it's normal because the installer image does not contain those
> packages. However, as there's no connection, it fails.
>
> Not sure, we can go further?
>

I believe what could be done is to create and extended installer image with
the packages need for testing available.
It could work similarly to how the barebones closure is included right now.
These images would be quite big, and impractical for anything but testing.
I believe that having a simple very big image is better than having
separate smaller ones for testing. This would also allow us to create a
selection of images with different de/service options for direct download
if the need arises, by expanding the list of configuration templates, and
the test image can be simply created by including the closure of all the
template configs. Wdyt?

>
> In the meantime, here's a patch that helps dealing with installation
> failures.
>
> Thanks,
>
> Mathieu
>
Best regards,
g_bor

>

Re: Review of my patch and Suggestions for Next Steps

[Gábor Boskovits]

Hello,

Naga Malleswari  ezt írta (időpont: 2020. márc. 17.,
Ke 4:12):

> Hi
>
> I am introducing myself as Outreachy Applicant for May 2020. I have been
> in touch with my Mentor Danny and working on R Packages.
>
> I received a reply that #40064 and #40040 are merged. I am waiting for
> response and the next task to go ahead.
>

I am sure that Danny will come back to you soon. In the meanwhile feel free
to have a look at the easy bugs in the issue tracker, you can find them at
issues.guix.gnu.org/easy

>
> --
> Regards
> NagaMalli
>
Best regards,
g_bor

>
>
>

Re: wip-postfix

[Gábor Boskovits]

Hello,

Jan Nieuwenhuizen  ezt írta (időpont: 2020. márc. 17., Ke
9:02):

> Gábor Boskovits writes:
>
> Hello Gábor,
>
> > I've just pushed my work on postfix as a new wip-postfix branch.
>
> That's great!  Yesterday I finally found some time to look at it.
>
Thanks for the feedback.

>
> > Current status:
> > Service starts fine. Some warnings are sent on startup, telling that
> > some coreutils stuff is not found. No testing was done as of now.
>
> I fixed that, see attched patch.
>
> > Feedback welcome.
>
> I found mail delivery not to work, out of the box (using attached
> config).
>
> When I start a vm like so:
>
> sed -e 's,-append ",-append "console=ttyS0 ,' $(./pre-inst-env guix
> system vm gnu/system/examples/postfix.tmpl) > rvm.shn
> sh rvm.sh -nographic -m 2G -net nic -net
> user,hostfwd=tcp::10022-:,hostfwd=tcp::10025-:25
>
> it does not work for me; I get
>
> --8<---cut here---start->8---
> $ telnet localhost 10025
> Trying 127.0.0.1...
> Connected to localhost.
> Escape character is '^]'.
> 220 komputilo.localdomain ESMTP Postfix
> mail from: root
> mail from: root
> 250 2.1.0 Ok
> rcpt to: alice
> rcpt to: alice
> 451 4.3.0 : Temporary lookup failure
> data
> data
> 554 5.5.1 Error: no valid recipients
> --8<---cut here---end--->8---
>
> When I hack around and create /etc/ailases.db, it works.
>
I would like to add a service config for this.

>
> It looks like most everything is installed in a single, flat directory
>
> /gnu/store/pyv0rpd6zs0m2i482cb8qxd6mhf5b47z-postfix-minimal-3.4.8
>
> executables, copies of readmes, (unused?) config files (main.cf,
> aliases)?
>
Yes, but can be easily separated. The config files are installer generated,
and not used.

>
> Anyhow, this is a great start; next Mailman?
>

One thing that blocks me from finishing this is that the setuid programs in
the os declatation should be extended, so that we can use the privilege
separation of postfix. I would like to propose a patch later this week.

>
> Greetings,
> janneke
>
Best regards,
g_bor

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

Re: Hi, I am R Veera Kumar - Current Outreachy selected Applicant

[Gábor Boskovits]

Hello,

R Veera Kumar  ezt írta (időpont: 2020. márc. 11., Sze
17:51):

> On Wed, Mar 11, 2020 at 11:03:00AM +0100, Gábor Boskovits wrote:
> > Hello,
> >
> > Veera  ezt írta (időpont: 2020. márc. 11., Sze 1:31):
> >
> > > On Tue, Mar 10, 2020 at 08:48:05AM +0100, Gábor Boskovits wrote:
> > > >Hello,
> > > >Veera <[1]v...@vkten.in> ezt írta (időpont: 2020. márc. 8., Vas
> > > 8:41):
> > > >
> > > >  On Sat, Mar 07, 2020 at 09:31:32PM +0100, Gábor Boskovits wrote:
> > > >  >
> > > >  > To get started you should install guix. For this project it
> might
> > > >  make
> > > >  > sense to install guix system also. You should also set up a
> guix
> > > >  > development environment, by checking out the source code, and
> > > >  building it.
> > > >  >
> > > >  I am installing GuixSD.
> > > >
> > > >How did the install go?
> > > >Could you do it? Please feel free to reach out to me should you
> have
> > > >any questions.
> > > >
> > >
> > > Install from ISO did not go well. Could not complete install.
> > >
> >
> > What went wrong with the iso?
> > Did you try the guided on the manual install?
> > Was this on a VM or in bare metal?
> >
>
> oops in bochs_drm video module actually some depended bo_ttm module.
> There were kernel trap faults occurred as seen in dmesg.
>
> >
> > > So I tried VM img install and it is successfull.
> > >
> >
> > I am glad that you have a working system. Please check if you have enough
> > disk space, as the default VM image is small. It should be extended
> before
> > use.
> >
> > Now I am reading docs about guix. And how to get my way around.
> > >
> >
> > Great. The next step to contribute would be to build an unmodified guix
> > from source.
> >
> > Try to find out how to do that, the manual has great instructions. Should
> > you have any questions feel free to reach out to us.
> >
>
> Yes. Would that require huge internet bandwidth? I mean downloading all
> the package sources. And then building it. As in other distros is it
> possible to just install binary buildtools and only download the source
> for needed pkgs and install them?
>

No. You will get binary substitutes for the build tools, and you will only
need the guix source repository from git.


> > >
> > > >  > The usual first time contribution we recommend is to package
> an R
> > > >  package
> > > >  > from cran that has all its dependencies in guix using the
> > > >  importer.
> > > >  >
> > > >
> > > >Best regards,
> > > >G_bor
> > > >
> > > > References
> > > >
> > > >1. mailto:v...@vkten.in
> > > >3. http://issues.guix.gnu.org/easy
> > >
> > Best regards,
> > g_bor
> >
>
>
> Regards,
> Veera
>
Best regards,
g_bor

>

Re: Guix Data Services - Outreachy Applicant

[Gábor Boskovits]

Hello Daniela,

Daniela Lura  ezt írta (időpont: 2020. márc. 11.,
Sze 0:19):

> Hello,
>
> This is Danjela, an outreachy applicant and a second year computer science
> student.
> How is everyone doing?
>
Fine so far.
And you?

>
> I am trying to build the Guix Data Service project locally and it prompts
> me to install Guile-Squee. I tried to install Squee but I am running into
> other build problems when I run 'make'. Apparently it can't find libpq,
> which I checked and is downloaded.
> Here is the error message:
> ```
> ice-9/boot-9.scm:752:25: In procedure dispatch-exception:
> In procedure dynamic-link: file: "libpq", message: "file not found"
> make[1]: *** [Makefile:968: squee.go] Error 1
> make[1]: Leaving directory '/home/daniela/Downloads/guile-squee'
> make: *** [Makefile:543: all-recursive] Error 1
>
> ```
>
I can't help with this particular issue right now, except that you can
check if it has a guix file inside that can be passed to guix build -f you
can try that.

> I really want to start making some meaningful contributions to the project
> but don't know where to start or what sources to use in order to do so.
> I have to note that I am not using Gnu/Guix, but I do have the Guix
> package manager installed as well as a Gnu/Linux distro. (OpenSuse
> Tumbleweed)
> Any suggestion or help would be greatly appreciated by my side.
>
You could try to package something for guix in the meanwhile, that is
always a great contribution. I believe you mentor will reach out to you
soon.

>
> Please don't hesitate to ask me further details if the description of the
> problem was to vague.
>
> Thank you,
>
Best regards,
g_bor

>

Fwd: [gnu-soc] GSoC-2010: Call for Mentors

[Gábor Boskovits]

To prospective GSoC mentors for GSoC 2020:

The GNU coordinators reached out to me with the following communication.
Please register yourselves as advised.
Also, if ,you have not done so, please subscribe to summer-of-c...@gnu.org
mailing list.

-- Forwarded message -
Feladó: Darshit Shah 
Date: 2020. márc. 11., Sze 10:57
Subject: [gnu-soc] GSoC-2010: Call for Mentors
To: 


Hi,

now we can register mentors for the Summer of Code.

As usual, please send to us (off-list), the following information:

Name:
Email:
AltEmail:
Phone:
Project:

P.S.: Please Cc the email to jemarch, giuseppe and me

Thanks,
Darshit

Best regards,
g_bor

Re: Hi, I am R Veera Kumar - Current Outreachy selected Applicant

[Gábor Boskovits]

Hello,

Veera  ezt írta (időpont: 2020. márc. 11., Sze 1:31):

> On Tue, Mar 10, 2020 at 08:48:05AM +0100, Gábor Boskovits wrote:
> >Hello,
> >Veera <[1]v...@vkten.in> ezt írta (időpont: 2020. márc. 8., Vas
> 8:41):
> >
> >  On Sat, Mar 07, 2020 at 09:31:32PM +0100, Gábor Boskovits wrote:
> >  >
> >  > To get started you should install guix. For this project it might
> >  make
> >  > sense to install guix system also. You should also set up a guix
> >  > development environment, by checking out the source code, and
> >  building it.
> >  >
> >  I am installing GuixSD.
> >
> >How did the install go?
> >Could you do it? Please feel free to reach out to me should you have
> >any questions.
> >
>
> Install from ISO did not go well. Could not complete install.
>

What went wrong with the iso?
Did you try the guided on the manual install?
Was this on a VM or in bare metal?


> So I tried VM img install and it is successfull.
>

I am glad that you have a working system. Please check if you have enough
disk space, as the default VM image is small. It should be extended before
use.

Now I am reading docs about guix. And how to get my way around.
>

Great. The next step to contribute would be to build an unmodified guix
from source.

Try to find out how to do that, the manual has great instructions. Should
you have any questions feel free to reach out to us.

>
> >  > The usual first time contribution we recommend is to package an R
> >  package
> >  > from cran that has all its dependencies in guix using the
> >  importer.
> >  >
> >
> >Best regards,
> >G_bor
> >
> > References
> >
> >1. mailto:v...@vkten.in
> >3. http://issues.guix.gnu.org/easy
>
> Regards,
> Veera
>
Best regards,
g_bor

>

Re: Hi, I am R Veera Kumar - Current Outreachy selected Applicant

[Gábor Boskovits]

Hello,

Veera  ezt írta (időpont: 2020. márc. 8., Vas 8:41):

> On Sat, Mar 07, 2020 at 09:31:32PM +0100, Gábor Boskovits wrote:
> > Hello Veera,
> >
> > Veera  ezt írta (időpont: 2020. márc. 7., Szo 16:05):
> >
> > > Hi,
> > >
> > > I am R Veera Kumar from India. I have been selected as Outreachy
> applicant
> > > for May 2020 round.
> > >
> > Nice to see you around.
> >
>
> Thanks!
>
> >
> > >
> > > I have heard about Guix from news and have checked about it a little
> > > before.
> > > I do not know Scheme/Guile Language.
> > >
> > This is not a problem. I believe it can be picked up easily. This won't
> be
> > the biggest burden in the project.
> >
>
> Oh well.
>
> > >
> > > How do I get started?
> > > What contributions can I make?
> > >
> >
> > To get started you should install guix. For this project it might make
> > sense to install guix system also. You should also set up a guix
> > development environment, by checking out the source code, and building
> it.
> >
>
> I am installing GuixSD.
>

How did the install go?

Could you do it? Please feel free to reach out to me should you have any
questions.

>
> > The usual first time contribution we recommend is to package an R package
> > from cran that has all its dependencies in guix using the importer.
> >
> > You can also check out http://issues.guix.gnu.org/easy and work on some
> > easy bugs.
> >
>
> Yes. I checked that.
>
> > Thanks for your interest. I hope that I could give you useful
> information.
> >
> > Best regards,
> > g_bor
> >
>
> Thanks for the welcome!
>
> Regards,
> Veera
>
Best regards,
G_bor

>

Re: Thoughts on making Guix even better

[Gábor Boskovits]

Hello,

Ludovic Courtès  ezt írta (időpont: 2020. márc. 8., Vas
21:54):

> Hi,
>
> "Raghav Gururajan"  skribis:
>
> > The guix system transactions are NON-MODULAR. That is, you cannot
> selectively reconfigure certain parts of the system. For example, you
> either reconfigure the system as a whole (or) you do not reconfigure the
> system at all.
> >
> > IMPLICATIONS:
> >
> > Lets assume we have 5 packages in profile. Package 1, 3 and 5 has
> non-critical updates. Package 4 has non-critical update but it breaks.
> Package 2 has critical update (CVE). We can either upgrade all packages
> except package 4 (or) we can upgrade only package 2.
> >
> > Lets assume we have 5 services/packages in system. Package/Service 1, 3
> and 5 has non-critical updates. Package/Service 4 has non-critical update
> but it breaks. Package/Service 2 has critical update (CVE). Now, when we
> reconfigure the system, all packages/services will upgrade, package/service
> 4 will break the system. We can of course do '--roll-back' and take the
> system to previous working state. But that will leave the system with
> critical vulnerability. Therefore, we cannot reconfigure package/service 2
> or any other parts of the system, until the package/service 4 is fixed.
> This window/gap puts guix system at great risk and instability.
>
> On one hand, I agree that it’d be nice to be able to update just parts
> of the system, like you explain.
>
> On the other hand, that would lead to an unknown and possibly
> unreproducible system state, which defeats what declarative
> (“non-modular”) system upgrades bring.
>
> Besides, I don’t see how one could introduce this “imperative” approach
> at the system level, technically.
>
> All in all, it would be best if the situations that make “modular system
> upgrades” appear necessary didn’t occur in the first place.
>
> Thoughts?
>

I believe that there are two points where it would be possible to improve
the situation.
1. Improve tooling to modularize the  configurations: like allowing an
inferior like feature for services, and adding tests to this (this is a way
of service versioning), or even setting up a convention to include scheme
files from a location, like ./services.d files get included, and the
expression they evaluated to are added to the services field if something
like this makes sense.
Make it possible for services to specify upgrade actions to run when the
version changes, or to fail when manual intervention is needed for a
correct upgrade.
2. Allow post install action configuration, for example stating that this
list of services should be restarted. Also allow to guess the right post
install action if none specified, and allow the services to add features to
this guessing mechanism, like which configuration changes require restart.
Make it possible to reload services by arranging their configs in a way
that reloads work.

In both of these cases it might be needed to inspect the previous system,
but the system provision information should be enough for that. Wdyt?

>
> Ludo’.
>
Best regards,
g_bor

>
>

Re: [GSOC 2020] Guix Deploy, round 2!

[Gábor Boskovits]

Hello,

Ludovic Courtès  ezt írta (időpont: 2020. márc. 8., Vas
23:10):

> Hi Chris!
>
> Christopher Lemmer Webber  skribis:
>
> > Let me also put out a goal for the Guix community: I think we'll see
> > Guix Deploy as a success if a bunch of us can switch over to using it on
> > our own servers (that includes me).  To that end, I'd love to know, how
> > many people are doing so, or have attempted to do so?  What features
> > would you like/need?
>
> We’re using it for the build farm, and I’m also using it for a couple of
> single servers.  It’s great!  :-)
>
> What I miss the most, especially on the build farm, is the ability to
> tell ‘guix deploy’ which services to restart upon completion.
> Currently, like ‘guix system reconfigure’, it conservatively doesn’t
> restart any running services.  However, often, you’d like it to run
> “herd restart X” upon completion.
>
> Another thing discussed at the Guix Days, but more relevant to more
> advanced use cases, is the ability to define “roles”: often you’d rather
> want to think in terms of the services machines offer and abstract over
> the actual machines.
>

These are both great ideas. It would be also nice to access these in a
single machine setup. I don't know where to implement this, it might make
sense to add these to the common part of deploy and reconfigure. IIRC we
also discussed the idea of a local deployer to be able handle the deploy
node the same way as the rest. Regarding the roles thing it would be nice
to get a discussion going regarding the interface, so that we have an idea
how it should look like. Wdyt?

>
> Ludo’.
>
Best regards,
g_bor

>
>

Re: Hi, I am R Veera Kumar - Current Outreachy selected Applicant

[Gábor Boskovits]

Hello Veera,

Veera  ezt írta (időpont: 2020. márc. 7., Szo 16:05):

> Hi,
>
> I am R Veera Kumar from India. I have been selected as Outreachy applicant
> for May 2020 round.
>
Nice to see you around.

>
> I like to work with Danny Milosavljevic, the mentor of the project:
>  Guix Integration of desktop environments into GNU Guix
>
> I am a self taught computer and software user. I am a Linux user for 15
> years.
> I have used Redhat, Fedora, Debian and others. I have built
> Linuxfromscratch
> and Beyond LFS and used them for a custom distro for myself. I know some C,
> Shell, awk, Perl, Python, Lua and basic system administration.
>
That is impressive. It looks like we can also learn from you.

>
> I have heard about Guix from news and have checked about it a little
> before.
> I do not know Scheme/Guile Language.
>
This is not a problem. I believe it can be picked up easily. This won't be
the biggest burden in the project.

>
> How do I get started?
> What contributions can I make?
>

To get started you should install guix. For this project it might make
sense to install guix system also. You should also set up a guix
development environment, by checking out the source code, and building it.

The usual first time contribution we recommend is to package an R package
from cran that has all its dependencies in guix using the importer.

You can also check out http://issues.guix.gnu.org/easy and work on some
easy bugs.


> Thanks,
> R Veera Kumar
> mail: v...@vkten.in, veerakuma...@gmail.com
> India
>

Thanks for your interest. I hope that I could give you useful information.

Best regards,
g_bor

>
>

Re: [GSOC 2020] Discussing GNU Guix project ideas?

[Gábor Boskovits]

Hello Leandro,

Leandro Doctors  ezt írta (időpont: 2020. márc. 3., Ke
23:45):

> On Tue, 3 Mar 2020 at 19:32, zimoun  wrote:
> > Based on your interests (Clojure, Leiningen, etc.), you should
> > consider something around a Clojure "importer". (Note that I am
> > ignorant about the Java ecosystem.)
>
> Thanks for the idea, Simon!
>
>
> > Currently, it is possible to import Python packages from PyPI, or
> > Haskell packages from Hackage, or etc. see [1] and something about
> > Clojure seems missing. I am quoting Ludo from [2]:
>
> Thanks for the pointers!
> I will check these projects and let you know.
>
>
> On another side, I will be offline for a fer days, so I expect to
> start working on my proposal draft from March 16th onwards.
> Would it be OK if I publish a project draft on
> GoogleDocs/GitHub/GitLab in (let's say) MarkDown by March 20th, so
> people can easily comment on it? I think getting feedback on a
> document via email may be quite difficult...
> Please, state your preference.
>

Another option would be to add it to the ideas page in a comment. When it
is ready, it would be easy to publish it by uncommenting. That way the
ideas would stay om the same place.

Best regards,
g_bor

>
> Best,
> Leandro
>
>

Re: Missing substitutes and TIMEOUT property (Racket, MAME)

[Gábor Boskovits]

Hello Tobias,

Tobias Geerinckx-Rice  ezt írta (időpont: 2020. márc. 3., Ke
15:35):

> Tobias Geerinckx-Rice 写道：
> > Since these builds were never attempted, they never produced any
> > logs.
>
> Not the same architecture, but here's a staging MAME that was
> built and killed without explanation after a non-magical-looking
> number of seconds:
>
> http://ci.guix.gnu.org/build/2337230/details
>
> I don't understand.  There has to be a better way to query Cuirass
> than endlessly clicking ‘Next’…  :-
>
You can try to get failing dependency information from the guix data
service. Last time I checked that did work. It should list all the failed
dependencies that failed directly.

>
> T G-R
>

Re: returning a store directory

[Gábor Boskovits]

Hello,

Efraim Flashner  ezt írta (időpont: 2020. márc. 2.,
Hét 12:54):

> I'm working on some user shepherd services and I want to make use of the
> #:directory option. The directory keyword clearly takes a string but
> guix-build from (guix scripts build) outputs a path and returns
> unspecified. The other things I've tried haven't worked as well.
>

Would ungexping the package from a gexp work for you?


> I'm looking to run a service from the store path of a package.
>
> --
> Efraim Flashner  אפרים פלשנר
> GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
> Confidentiality cannot be guaranteed on emails sent or received unencrypted
>

Re: [GSOC 2020] Guix Deploy, round 2!

[Gábor Boskovits]

Hello Chris,

Christopher Lemmer Webber  ezt írta (időpont: 2020.
febr. 29., Szo 17:55):

> Hello,
>
> I'd be interested in doing a round 2 of mentoring for Guix Deploy.
> The previous student (Jakob L. Kreuze) will not be a GSoC student this
> year but is willing to co-mentor.  (Maybe David Thompson is as well but
> I won't speak for him since we haven't discussed it yet.)
>

Wonderful idea, please add it to the GSoC 2020 ideas page if you haven't
done so.


> I don't know what the situation with Outreachy slots are, but I'd also
> be happy to mentor this for there as well, obviously.
>

The proposal deadline for this round has passed, so we can't do that right
now. If we still have work to do in this area ( I believe we will) when the
next round comes around, I will be happy to help in forming the proposal. I
will soon publish a blog post with the relevant deadlines for both program.


> I think there's probably more that can be done to improve environments.
> This includes initial bootstrapping of environments, making more
> environments available, etc.
>
> Let me also put out a goal for the Guix community: I think we'll see
> Guix Deploy as a success if a bunch of us can switch over to using it on
> our own servers (that includes me).  To that end, I'd love to know, how
> many people are doing so, or have attempted to do so?  What features
> would you like/need?
>

I believe this is a great initiative. Thanks for bringing this up.

>
>  - Chris
>

Best regards,
g_bor

>
>

Re: Extending Guix without using the Guile load path

[Gábor Boskovits]

This looks interesting.

Ricardo Wurmus  ezt írta (időpont: 2020. febr. 19., Sze
16:37):

> Hi Guix,
>
> I think it’s a bit difficult to install the Guix Workflow Language at
> this point and I’d like to change that.
>
> Currently, new sub-commands for Guix are looked up by module name on the
> Guile load path.  When installing the “gwl” package, though, the Guile
> load path is not automatically altered, so users need to set it up by
> themselves.  The load path is only altered automatically when users
> install the “guile” package.  This is not a good recommendation because
> users may have Guile 2.2 in their profile, and not Guile 3.0 or whatever
> version may be needed by the extension.
>
> I wonder if we can make this a little nicer by letting Guix look for
> sub-command scripts in directories that are listed in an environment
> variable, such as GUIX_EXTENSIONS_PATH.  The “guix” package would set
> this search path and packages wanting to provide a sub-command (such as
> “guix workflow” or “guix home”) would arrange to have their scripts
> placed in that sub-directory of their outputs.
>

I have encountered this with guix home, and one of my first setups was to
adjust the path.


> What do you think?
>

I believe this is a good idea. I also think there is an open bug already
for the home thing.


> --
> Ricardo
>

Best regards,
g_bor

>
>

Outreachy funding

[Gábor Boskovits]

Hello Guix,

This is my second letter on this subject. My question is still the
same, are we willing to provide funding for more than one Outreachy
intern?

Additional information:
1. We have 3 proposals listed.
2. We confirmed funding for 1 intern.
3. Funding per intern is 6500 USD.
4. I am aware that at least two people are interested in applying.

Should you need any more information please let me know.

Best regards,
g_bor
-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

Re: [gnu-soc] [VERY URGENT] GNU ideas for GSOC 2020

[Gábor Boskovits]

Hello Jose,

Jose E. Marchesi  ezt írta (időpont: 2020. febr. 12.,
Sze, 19:51):
>
>
> Hi people!
>
> Once again, we are applying as a mentoring organization for GSOC 2020.
> At this point, we need to populate our ideas page with projects [1].
>
> This should be done before this Thursday (yes tomorrow).  So, if you
> want your GNU package to participate in GSOC, please send us your ideas
> to summer-of-c...@gnu.org ASAP!

Thanks for the notice.

>
> For each project idea, we need:
>
> - Name of the GNU program.
>   Example: GNU poke.
>
> - Summary of the project/idea.
>   Example: DWARF to Poke translator
>
> - Little paragraph explaining the project/idea.
>
> - Skills required.
>   Example: Good knowledge of DWARF, C programming.
>
> - Contact address for interested students.
>   Example: poke-de...@gnu.org
>
> If you have an external page where you are documenting your ideas, then
> please send us the URL so we can list it in the main page.

The URL for Guix ideas page is:
https://libreplanet.org/wiki/Group:Guix/GSoC-2020

>
> Sorry for the late notice!
> And thanks! :)
>
> [1] https://www.gnu.org/software/soc-projects/ideas.html
>

Thanks for organizing this!

Best regards,
g_bor
-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

Re: Outreachy finance

[Gábor Boskovits]

Hello,

Ricardo Wurmus  ezt írta (időpont: 2020. febr. 11., Ke
23:42):

>
> Tobias Geerinckx-Rice  writes:
>
> > Gábor,
> > On Tue, Feb 11, 2020 at 8:39 PM, =?iso-8859-1?b?R+Fib3I=?= Boskovits
> >  wrote:
> >> I was convenient to add funding for one itern on my own, as it is a
> >> prerequisite of community application.
> >
> > I'm afraid I don't understand this sentence.  Could you rephrase?
>
> When applying on behalf of the Guix community to participate in
> Outreachy, the community coordinator (this time this is Gábor) needs to
> confirm that there are funds for at least one intern.
>
> The community coordinator can declare that funding for more interns is
> available, which would permit the Outreachy organizers to accept more
> interns, which could then be accepted (or rejected) by the project
> mentors.
>
> We currently have two projects registered with Outreachy, IIUC, but we
> have declared to only have funds for one intern.
>
> The question is now, whether we can up that number by committing another
> 6,500 USD (?) to Outreachy.  The actual fee paid depends on how many
> interns are accepted by us and how many of them finish their internship.
>
> Gábor, please correct me if I wrote something wrong or misleading.
>

Thanks for the clarification, that is exactly what I ment. Everything above
is correct, except that we have 3 projects listed, but we declared funds
for only one intern.


> --
> Ricardo
>

Best regards,
g_bor

>

Outreachy finance

[Gábor Boskovits]

Hello,

Today on Outreachy Chat I was asked if we are willing to raise the number
of interns, should there be more than one good candidate. I believe we
could do that, but would not like to decide on this. I was convenient to
add funding for one itern on my own, as it is a prerequisite of community
application. Do you think we could approve the funding for more interns?

Best regards,
g_bor

Re: Outreachy blogpost

[Gábor Boskovits]

Hello,

Ludovic Courtès  ezt írta (időpont: 2020. febr. 11., Ke
15:46):

> Hi Gábor,
>
> Gábor Boskovits  skribis:
>
> > I have pushed a blog post today that gives a status report on the current
> > Outreachy round preparations:
> >
> >
> http://guix.gnu.org/blog/2020/outreachy-may-2020-to-august-2020-status-report-i/


I intend to follow it up with a series on progress, and could not come up
with a better title for that. If you have a better idea, then feel free to
update it accordingly.


>
> Great, thank you!
>
> At first I was surprised by the title (a status report about what we
> _will_ do from May to August?!), but hopefully that’s clearer to others.
>
> Everyone: please help spread the word!
>
> Ludo’.
>
Best regards,
g_bor

>

Outreachy blogpost

[Gábor Boskovits]

Hello,

I have pushed a blog post today that gives a status report on the current
Outreachy round preparations:

http://guix.gnu.org/blog/2020/outreachy-may-2020-to-august-2020-status-report-i/

Please feel free to comment, and help to spread the word.

Best regards,
g_bor

Re: Guix size reduction work group

[Gábor Boskovits]

Hello Ludo,

Ludovic Courtès  ezt írta (időpont: 2020. febr. 7., Pén
22:36):

> Hi,
>
> zimoun  skribis:
>
> >> The thing is, I think it’s something that requires constant care, every
> >> time we add a package or modify an existing one.  It’s very easy to lose
> >> benefits that had been previously obtained through hard work!
> >
> > I have never thought, neither tried but is it possible to find and/or
> > build all the packages that 'inherit' from a specific one?
>
> Nope (‘inherit’ is purely syntactic, it doesn’t “live on” at run time.)
> What would it buy you, though?
>

It is currently easy to break packages by updating a package that is
inherited from. You have no way to know about that relationship by simple
inspection, and is not discoverable by current tooling either. So I also
believe that it would be useful to at least be able to list them. One place
where this becomes painful is in bootstrap chains.

Do you think this can be achieved somehow without complicating
implementation?


> Ludo’.
>

Best regards,
g_bor

>

Re: Outreachy timeline and status report

[Gábor Boskovits]

Hello,

Ludovic Courtès  ezt írta (időpont: 2020. febr. 7., Pén
22:06):

> Hi Gábor,
>
> Gábor Boskovits  skribis:
>
> > The timeline is available here:
> > https://www.outreachy.org/apply/project-selection/
> >
> > Every date refers to 4 p.m. UTC that day.
> >
> > We kindly request proposals to be available by the 11th of February,
> > so that it will be possible to promote them on the Outreachy Twitter
> > chat.
> >
> > Please remind prospective applicants, that the initial application
> > deadline is the 25th of February.
>
> Thanks for sharing.  If you want we can add another post on the web site
> by then to publicize the offer.  WDYT?  Any other ways we could spread
> the news?
>

I intend to write up a blogpost and publish it on Monday. We also have the
twitter chat.


> BTW, i18n for the Guix Data Service is no longer listed as a project.
> Is that intentional?
>

It got in not long ago. It was already approved. At the time on the first
writing the proposal was not uploaded yet.


> Thank you!
>
> Ludo’.
>

Best regards,
g_bor

>

wip-postfix

[Gábor Boskovits]

Hello Guix,

I've just pushed my work on postfix as a new wip-postfix branch.
There are currently two commits, one for the package and one for the service.

I adjust them in tandem.

Current status:
Service starts fine. Some warnings are sent on startup, telling that
some coreutils stuff is not found. No testing was done as of now.
Feedback welcome.

Best regards,
g_bor
-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

Outreachy timeline and status report

[Gábor Boskovits]

The timeline is available here:
https://www.outreachy.org/apply/project-selection/

Every date refers to 4 p.m. UTC that day.

We kindly request proposals to be available by the 11th of February,
so that it will be possible to promote them on the Outreachy Twitter
chat.

Please remind prospective applicants, that the initial application
deadline is the 25th of February.

The contribution period is between March 5, April 7. Please note that
registering a contribution is a mandatory requirement for an applicant
to be selected as an intern.
Reminder to mentors: the contribution period is usually the most busy
period of the mentoring activity, as handling multiple contribution
request at the same time might be necessary.
Including information in patches that they are related to outreachy
might help reviewers to give these some priority. You can use the
--subject-prefix option of git-format-patch for that.

Please do not notify interns about the selection result before the
official announcement, as this is forbidden by Outreachy policy.
Announcement expected at April 27.

Current status:

There are currently two proposals:

2020 May to 2020 August round - GNU Guix - Integration of desktop
environments into GNU Guix

Mentoring: Danny Milosavljevic

You can co-mentor using:
https://www.outreachy.org/outreachy-may-2020-internship-round/communities/gnu-guix/integration-of-desktop-environments-into-gnu-guix//cfp/mentor/submit/

and

2020 May to 2020 August round - GNU Guix - Create Netlink bindings in Guile

Mentoring: Gábor Boskovits

You can co-mentor using:
https://www.outreachy.org/outreachy-may-2020-internship-round/communities/gnu-guix/create-netlink-bindings-in-guile/cfp/mentor/submit/

You can add new proposals using
https://www.outreachy.org/outreachy-may-2020-internship-round/communities/gnu-guix/submit-project/

Best regards,
g_bor
-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

Re: WIP gnu: poetry: Update to 1.0.3.

[Gábor Boskovits]

Hello,

Tanguy Le Carrour  ezt írta (időpont: 2020.
febr. 3., H, 16:31):
>
> Dear Guix,
>
> I'm working on updating Poetry to version 1.0.3 and I have a problem
> with the version of a dependency.
>
> Poetry now depends on python-keyring >=20.0.0,<21.0.0. In Guix we
> have python-keyring 21.0.0, so it does not work once installed!
>
> What am I supposed to do?
>
> I see 3 different ways out of this:
> - patch the package to make it use our version (I tried but failed [1]);
> - ask upstream to update dependencies;
> - declare a new package python-keyring-20.0.0 and use it as an input.

Asking upstream to update would be great.

>
> [1]: attempt to patch setup.py
> -(arguments `(#:tests? #f)); tests depend on dbus 
> service
> +(arguments
> + `(#:tests? #f ;; Pypi does not have tests.
> +   #:phases
> +   (modify-phases %standard-phases
> + (add-after 'unpack 'change-dependencies
> +   (lambda _
> + ;; Guix has version 21.0.0 of python-keyring
> + (invoke "sed" "-i" "-e"
> + "s/keyring>=20.0.1,<21.0.0/keyring>=20.0.1,<22.0.0/"
> + "setup.py")
> + #t)
>

What did not work in this case?
Also, do you think that you could replace invoke sed with substitute*?

> Any help welcome!
>
> --
> Tanguy
>

Best regards,
g_bor
-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

Re: nesting with-imported-modules

[Gábor Boskovits]

Hello,

Ricardo Wurmus  ezt írta (időpont: 2020. febr. 1., Szo
23:23):

> Hi Guix,
>
> it seems that it is impossible to nest with-imported-modules.  A gexp
> that is wrapped in multiple layers of with-imported-modules won’t depend
> on the list of all mentioned modules but only on the outermost.
>
> This is because with-imported-modules sets the current-imported-modules
> parameter without checking if the parameter already has a value.
>
> Should nesting be supported?  It seems useful.
>

Looks useful to me. Also, it seems to me that with-imported-modules work in
unexpected ways when wrapped inside with-extensions.
What I observed was that adding a with-imported-modules some-guix-module
inside a with-extensions guix broke patch file search. Can that be related?

>
> --
> Ricardo
>
>

Re: Testing the installer

[Gábor Boskovits]

Hello,

Bengt Richter  ezt írta (időpont: 2020. jan. 24., P, 0:08):
>
> Hello Gábor,
>
> On +2020-01-23 12:21:27 +0100, Gábor Boskovits wrote:
> [...]
>
> > This is a bit off topic, but I am about to create an automatic
> > installer, that is
> > a candidate for a new backend. It currently works by providing a 
> > configuration
> > record, and then executes a few things from the installer.
> >
> > (It does a lookup for a candidate installation target disk, autopartitions 
> > it,
> > then injects the bootloader and file-system fields into an operating-system
> > template, and finally does a system installation.)
> >
>
> Will your installer be able to create /boot and / images that will
> work with Coreboot/SeaBios/grub legacy-only (not UEFI) bootable systems
> (like PureOS)?

It is based on the current installation image, and it accepts a Guix
System configuration
template, so it works on systems that Guix System can currently operate on.
Right now the bootloader configuration is limited to that what the
autopartitoning in the
installer does for the option 'All in one partiton', which means that
UEFI or legacy is
autodetected, and installed accordingly. Does that answer you question?

>
> IOW, what kind of BIOS systems is it dependent on?
>
> > I will have a look at the new protocol soon, to see if this project
> > can benefit from that.
> [...]
>
> >
> > Best regards,
> > g_bor
> > --
> > OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21
> >
>
> --
> Regards,
> Bengt Richter


Best regards,
g_bor
-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

Re: Testing the installer

[Gábor Boskovits]

Hello Mathieu,

Mathieu Othacehe  ezt írta (időpont: 2020. jan.
23., Cs, 10:42):
>
>
> Hey!
>
> > I’ve pushed ‘wip-installer-test’, which implements said protocol.  See
> > screenshot below!  :-)
>
> Woow, that's impressive :)
>
> I just gave you access to Guile-newt repository so that you can
> integrate your changes. I will create a new release once its done.
>
> In the future, I would have liked to keep open the possibility of having
> one installer with multiple graphical backends (newt, gtk, cli). That
> would mean that we would need to factorize the protocol part in the
> backend agnostic part of the installer.
>
> Anyway, for now it would be completely over-engineered, as we don't know
> yet if a new backend will come one day.

This is a bit off topic, but I am about to create an automatic
installer, that is
a candidate for a new backend. It currently works by providing a configuration
record, and then executes a few things from the installer.

(It does a lookup for a candidate installation target disk, autopartitions it,
then injects the bootloader and file-system fields into an operating-system
template, and finally does a system installation.)

I will have a look at the new protocol soon, to see if this project
can benefit from that.

>
> Please let me know if you want help on some point but, I think that I'll
> try to tackle the "installer cannot restart issue".
>
> Thanks,
>
> Mathieu
>

Best regards,
g_bor
-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

GSoC status

[Gábor Boskovits]

Hello Guix,

I have received the information from the GNU org admins that they
submitted GNU for participation in GSoC 2020. They are waiting for
feedback, I will keep you updated.

In the meantime I created this page:
https://libreplanet.org/wiki/Group:Guix/GSoC-2020
based roughly on last year.

Please check if you are still willing to mentor the projects you listed.

I also have some questions, embedded as comments, so if you have
insight on those, then feel free to contact me  or simply edit the
page accordingly.

Best regards,
g_bor

-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

Outreachy Internationalization for Guix Data Service

[Gábor Boskovits]

Hello Christopher,

Could you resubmit the proposal for this round?

I believe we left it off in a good state, so you could just copy it verbatim.

Best regards,
g_bor

-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

Outreachy project for netlink bindings

[Gábor Boskovits]

Hello Julien,

Last round you were interested in mentoring this project.

I have sent the previous proposal with slight modifications for this round.
You can add yourself as a comentor to it now.

Best regards,
g_bor
-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21