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: 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: 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: 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’.
>
>

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

[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

[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

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

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

>

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

>
>
>
>

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,

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

[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

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

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 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: [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: 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: 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: [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: 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] 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: 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: 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: 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

>

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

>

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: 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: 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: 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: 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"
>  "niu_NU"

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: 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=&linter=inputs-should-be-native&message_query=&field=linter&field=message&field=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

>

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

[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

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

>

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

>
>

[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

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

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

>

[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

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

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

>
>

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 m

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

>
>

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

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

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

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

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

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: [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,

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] 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: [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] 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]

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

[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

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

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

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: 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: Talk about Guix and GuixSD at FSF Hungary

[Gábor Boskovits]

2018-02-20 9:37 GMT+01:00 Gábor Boskovits :

> 2018-02-18 14:22 GMT+01:00 Ricardo Wurmus :
>
>>
>> Hi Gábor,
>>
>> > On february the 20. at 18:00 local time I will give a talk about Guix
>> and
>> > GuixSD for the Hungarian FSF community.
>>
>> That’s great!
>>
>> > I based the style of my talk on one given by Ludo. I Left the copyright
>> > notices intact, only adding my name. I hope this is the right thing to
>> do,
>> > but I would like to hear your opinon.
>>
>> This seems to be the correct way to do this.
>>
>> > One more thing, I am willing to add the source of this talk to the
>> > maintainers repo. What is the right way to do that? Who should I
>> contact?
>>
>> The repository is here:
>>
>> http://git.savannah.gnu.org/cgit/guix/maintenance.git/
>>
>> Usually, it’s just a matter of adding a new directory containing the
>> sources.  You can send a URL to the sources (e.g. as a tarball) to
>> guix-devel; we would download them from there and add the sources to the
>> maintenance repo.
>>
>>
> Thanks for the information. I uploaded the tarball to here:
> https://ufile.io/hsft0
>

Thanks for all your help. The talk went well, they asked me to repeat it on
the Free Software Conference on the 12. of May.


>
>
>> --
>> Ricardo
>>
>> GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
>> https://elephly.net
>>
>>
>>
>

Re: Staging

[Gábor Boskovits]

2018-02-22 18:09 GMT+01:00 Ricardo Wurmus :

>
> Marius Bakke  writes:
>
> > Yes, let's start this in a few days, when Hydra calms down.  Perhaps we
> > can include the Java updates discussed in
> >  as
> > well.  Ricardo, WDYT?
>
> I didn’t have any time yet to check the Java updates, but they don’t
> really affect many packages anyway (other than Java packages), so I
> don’t think they’re all that critical.
>
>
I tend to agree. The whole jdk closure is about 200 packages.
Packages patched to work with java8 is on the order of 50, or so.

Even if 200 is too much, we can delay flipping the defaults. Then the
50 in need of individual patches can go in. WDYT?


> --
> Ricardo
>
> GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
> https://elephly.net
>
>
>
>

Re: broken references in jar manifests

[Gábor Boskovits]

2018-03-01 18:11 GMT+01:00 Ricardo Wurmus :

> Hi Guix,
>
> we have a problem with jar manifests.  When we use the Class-Path
> property to ensure that an executable can find its dependencies on the
> class path at run-time, we end up with a manifest like this:
>
> --8<---cut here---start->8---
> Manifest-Version: 1.0
> Class-Path: /gnu/store/i28vi94r8z9f0x02zgkrv87w16ibmqkw-java-htsjdk-2.
>  10.1/share/java/htsjdk.jar
> Created-By: 1.8.0_151 (Oracle Corporation)
> Main-Class: picard.cmdline.PicardCommandLine
> --8<---cut here---end--->8---
>
> Note that the Class-Path property is broken into two lines.  This means
> that the reference scanner will miss it and grafting will fail.
>
>
Could we modify the reference scanner to find these lines?
Would there be any serious drawback to that?


> Breaking up lines longer than 70 characters is according to the manifest
> specification, see
> https://docs.oracle.com/javase/7/docs/technotes/guides/jar/jar.html
>
> We cannot just use a wrapper that sets CLASSPATH, because it appears to
> be ignored when using a manifest with “Main-Class”.  “Main-Class” is
> required for executables that can be run like this:
>
> java -jar whatever.jar
>
> A possible work-around might be to patch the class loader of our JDKs to
> look at a custom Guix-specific file, which we will include in each jar.
> That file would be allowed to have longer lines.
>
> There are two disadvantages:
>
> 1) we need to patch the JDK
> 2) the jars would not do the right thing when executed with a different
> JDK (e.g. on a foreign distro).
>
> What do you think?
>
> --
> Ricardo
>
>

Re: broken references in jar manifests

[Gábor Boskovits]

2018-03-01 19:54 GMT+01:00 Ricardo Wurmus :

>
> Gábor Boskovits  writes:
>
> > 2018-03-01 18:11 GMT+01:00 Ricardo Wurmus 
> :
> >
> >> Hi Guix,
> >>
> >> we have a problem with jar manifests.  When we use the Class-Path
> >> property to ensure that an executable can find its dependencies on the
> >> class path at run-time, we end up with a manifest like this:
> >>
> >> --8<---cut here---start->8---
> >> Manifest-Version: 1.0
> >> Class-Path: /gnu/store/i28vi94r8z9f0x02zgkrv87w16ibmqkw-java-htsjdk-2.
> >>  10.1/share/java/htsjdk.jar
> >> Created-By: 1.8.0_151 (Oracle Corporation)
> >> Main-Class: picard.cmdline.PicardCommandLine
> >> --8<---cut here---end--->8---
> >>
> >> Note that the Class-Path property is broken into two lines.  This means
> >> that the reference scanner will miss it and grafting will fail.
> >>
> >>
> > Could we modify the reference scanner to find these lines?
> > Would there be any serious drawback to that?
>
> The reference scanner needs to be fast.  The scheme version is heavily
> optimized to do quickly replace references for the purpose of grafting.
> The C++ version will eventually be replaced with the Scheme version as
> the daemon gets replaced.
>
> An alternative to recording full references in the manifest file is to
> install a “lib” directory that contains symlinks to dependencies.  The
> manifest can then contain relative paths to these symlinks.
>
>
I guess I would prefer to do this instead.


> That’s what I did in the package definition for dropseq-tools.
>
>
Unfortunately I cannot find this package. Where should I look for it?


> --
> Ricardo
>
> GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
> https://elephly.net
>
>
>

Re: [WIP]: localize guix.texi

[Gábor Boskovits]

2018-03-02 14:31 GMT+01:00 Ludovic Courtès :

> Hi Julien,
>
> Thanks a lot for taking this initiative.  To me localization is super
> important if we are to make free software a viable option for everyone.
>
> Julien Lepiller  skribis:
>
> >> here is my first attempt at localizing guix.texi. This patch adds
> >> guix.fr.texi, a localized version of the manual. It uses po4a to
> >> generate the .po file and use that same file to generate the localized
> >> manual.
>
> From the patch I can’t really see how translation works.  Do translators
> get a list of msgids to translate?
>
> >> I had to include the guix.fr.texi in the commit because it is
> >> necessary that it exists in order to add it to info_TEXINFOS. This
> >> means that this version of guix now requires po4a and will always
> >> build the localized manuals in every available language. I don't
> >> really like that though.
>
> What about doing what we do for man pages?  We include generated man
> pages in the distributed tarball (that’s what the ‘dist_’ prefix in
> ‘dist_man1_MANS’ means, in doc/local.mk).  Thus help2man is needed only
> if you’re building from a checkout.  Furthermore, we use AM_MISSING_PROG
> so that users get a helpful message if they end up in a situation where
> they would need help2man.
>
> > From 7443ce7407a7194a9d9487f95f940b4b9adf5d82 Mon Sep 17 00:00:00 2001
> > From: Julien Lepiller 
> > Date: Mon, 19 Feb 2018 23:24:30 +0100
> > Subject: [PATCH] doc: Allow documentation to be translated.
> >
> > po/doc/local.mk: New file.
> > Makefile.am: Include it.
> > doc/local.mk (info_TEXINFOS, BUILT_SOURCES, EXTRA_DIST,
> MAINTAINERCLEANFILES):
> > Add guix.fr.texi
> > (rules): New rule to build localized texi files
> > .gitignore: Ignore doc/version.*.texi
>
> You’re missing bullets for each item here.  :-)
>
> > +PO4A_PARAMS:=-M UTF-8 -L UTF-8 #master and localized encoding
> > +PO4A_PARAMS+=-k 0 # produce an output even if the translation is not
> complete
> > +PO4A_PARAMS+=-f texinfo # texinfo format
>
> Nitpick: leave spaces around assignment operators.
>
> > +$(srcdir)/%D%/guix.%.texi: %D%/guix.texi po/doc/%.po
> > + po4a-translate $(PO4A_PARAMS) -m $< -p $(word 2,$^) -l $@.tmp
> > + sed -i 's|guix\.info|guix.fr.info|' $@.tmp
> > + mv $@.tmp $@
>
> [...]
>
> > +$(srcdir)/po/doc/%.po: doc/guix.texi
> > + po4a-updatepo -M UTF-8 -f texinfo -m $< -p $@
>
> If you use AM_MISSING_PROG, then you can use $(PO4A_TRANSLATE) and
> $(PO4A_UPDATEPO) instead of directly using the program names here.
>
> Last thing: please enclose file names in double quotes: "$@", "$<", etc.
>
> With these changes, I’m all for applying the patch to master.
>
>
Once this is in master I'm also willing to do this for my language. I'm
waiting for
the final style to settle. Thanks for the initiative!


> Thank you!
>
> Ludo’.
>
>

Re: Posts in languages other than English on help-guix?

[Gábor Boskovits]

2018-03-02 21:03 GMT+01:00 Andreas Enge :

> Hello!
>
> On Fri, Mar 02, 2018 at 05:02:40PM +0100, Ludovic Courtès wrote:
> > What about allowing posts on help-guix in one of the languages that
> > regular contributors know, in addition to English?
>
> That sounds like a good idea. However, in the text, I would still say that
> English is the preferred language, or the language in which one is most
> likely to get a useful reply.
>
> > The alternative would be to create separate language-specific lists, but
> > some (rightfully) think there’s a risk of a disconnect with actual
> > developers.
>
> Indeed, unless we get a lot of multilingual traffic, at which point we can
> still create separate lists.
>
> > +   "Subscribe to the Help mailing list to get support from the
> GuixSD
> > +and GNU Guix community via email.  You can post messages in English
> though we
> > +also accept other languages.")
> > +  ("eo"
> > +   "Subskribu al la retmesaĝolisto \"Help\" por demandi helpon pri
> > +GuixSD kaj GNU Guix al la grupo.  Vi povas skribi esperantlingve.")
> > +  ("fr"
> > +   "Abonnez-vous à la liste de diffusion « Help » pour obtenir
> l'aide
> > +de la communauté sur GuixSD et GNU Guix par courrier électronique.  Vous
> > +pouvez envoyer des messages en Français."))
>
> ("de"
>  "Melden Sie sich bei der „Help“-Mailingliste an, um per E-Mail Hilfe von
> anderen
> GuixSD- und Guix-Nutzern zu bekommen.  Sie können Nachrichten auch auf
> deutsch
> schicken.")
>
(Zur Frage, ob es "auf deutsch" oder "auf Deutsch" heißt, siehe
>http://www.belleslettres.eu/content/rechtschreibung/auf-
> deutsch-rechtschreibung.php .)
>
> Andreas
>
>
>
("hu"
 "Iratkozzon fel a „Help“ levelezőlistára, hogy segítséget kaphasson
e-mailben a GuixSD
és a GNU Guix közösségtől. Magyarul is küldhet üzeneteket.")

Statistics and --rounds

[Gábor Boskovits]

I will write here a short notice of the statistical implications of
building software multiple times in general. I hope you will find this
information useful.

Hypothesis: the probability of successfully building the software is
greater than or equal to p.

This hypothesis can be accepted with a confidence level c=1-p^(k+1), where
k is the number of rounds the software was built, and all the builds were
succcesful.

Re: [PATCH] Ruby on Rails (web-application framework)

[Gábor Boskovits]

2018-03-03 21:55 GMT+01:00 Christopher Baines :

> Tags: moreinfo
>
> Let's use this bug to track the process of packaging Ruby on Rails.
>
> My current plan is to take chunks of the packages from the wip-rails-2
> [1] branch here, check them over, and then send them up for review.
>
> If anyone else wants to join in, that would be great.
>
>
This would be great! Actually I would really like to see redmine on GuixSD
:)
Please keep me in line. I'm willing to help. Should I join in taking the
packages
or just the review?


> 1: http://git.cbaines.net/guix/log/?h=wip-rails-2
>
>
> Ben Woodcroft (115):
>   gnu: Add ruby-asciimath.
>   gnu: Add ruby-asciidoctor.
>   gnu: Add ruby-rack-test.
>   gnu: Add ruby-rack-protection.
>   gnu: Add ruby-contest.
>   gnu: Add ruby-creole.
>   gnu: Add ruby-sporkmonger-rack-mount.
>   gnu: Add ruby-erubis.
>   gnu: Add ruby-rake.
>   gnu: Add ruby-ruby-engine.
>   gnu: Add ruby-sass-spec.
>   gnu: Add ruby-multi-test.
>   gnu: Add ruby-yajl-ruby.
>   gnu: Add ruby-oj.
>   gnu: Add ruby-multi-json.
>   gnu: Add ruby-cucumber-wire.
>   gnu: Add ruby-cucumber.
>   gnu: Add ruby-cucumber*.
>   gnu: Add ruby-rspec-its.
>   gnu: Add ruby-addressable.
>   gnu: Add ruby-bzip2-ruby.
>   gnu: Add ruby-aruba.
>   gnu: Add ruby-aruba*.
>   gnu: Add ruby-fuubar.
>   gnu: Add ruby-contracts.
>   gnu: Add ruby-event-bus.
>   gnu: Add ruby-childprocess.
>   gnu: Add ruby-sinatra.
>   gnu: Add ruby-tilt.
>   gnu: Add ruby-radius.
>   gnu: Add ruby-coveralls.
>   gnu: Add ruby-truthy.
>   gnu: Add ruby-rest-client.
>   gnu: Add ruby-webmock.
>   gnu: Add ruby-crack.
>   gnu: Add ruby-safe-yaml
>   gnu: Add ruby-hashie.
>   gnu: Add ruby-rspec-pending-for.
>   gnu: Add ruby_version.
>   gnu: Add ruby-appraisal.
>   gnu: Add ruby-kramdown..
>   gnu: Add ruby-prawn.
>   gnu: Add ruby-pdf-core.
>   gnu: Add ruby-pdf-reader.
>   gnu: Add ruby-cane.
>   gnu: Add ruby-parallel.
>   gnu: Add ruby-coffee-script.
>   gnu: Add ruby-coffee-script-source.
>   gnu: Add ruby-execjs.
>   gnu: Add duktape.
>   gnu: Add ruby-duktape.
>   gnu: Add ruby-therubyracer.
>   gnu: Add ruby-libv8-3.16.14.
>   gnu: Add ruby-haml.
>   gnu: Add ruby-haml-3.
>   gnu: Add ruby-backports.
>   gnu: Add ruby-faraday.
>   gnu: Add ruby-faraday-middleware.
>   gnu: Add ruby-gh.
>   gnu: Add ruby-highline.
>   gnu: Add ruby-launchy.
>   gnu: Add ruby-travis.
>   gnu: Add ruby-actioncable.
>   gnu: Add ruby-actionmailer.
>   gnu: Add ruby-actionpack.
>   gnu: Add ruby-actionview.
>   gnu: Add ruby-activejob.
>   gnu: Add ruby-activemodel.
>   gnu: Add ruby-activerecord.
>   gnu: Add ruby-railties.
>   gnu: Add ruby-sprockets-rails.
>   gnu: Add ruby-nio4r.
>   gnu: Add ruby-websocket-driver.
>   gnu: Add ruby-mail.
>   gnu: Add ruby-rails-dom-testing.
>   gnu: Add ruby-rails-html-sanitizer.
>   gnu: Add ruby-globalid.
>   gnu: Add ruby-sprockets.
>   gnu: Add ruby-websocket-extensions.
>   gnu: Add ruby-loofah.
>   gnu: Add ruby-rr.
>   gnu: Add ruby-rubocop.
>   gnu: Add ruby-parser.
>   gnu: Add ruby-powerpack.
>   gnu: Add ruby-rainbow.
>   gnu: Add ruby-thread-order.
>   gnu: Add ruby-ruby-progressbar.
>   gnu: Add ruby-unicode-display-width.
>   gnu: Add ruby-ast.
>   gnu: Add ruby-racc.
>   gnu: Add ruby-sass-rails.
>   gnu: Add ruby-uglifier.
>   gnu: Add ruby-sourcemap.
>   gnu: Add ruby-coffee-rails.
>   gnu: Add ruby-jquery-rails.
>   gnu: Add ruby-turbolinks.
>   gnu: Add ruby-jbuilder.
>   gnu: Add ruby-web-console.
>   gnu: Add ruby-rails.
>   gnu: Add ruby-sass.
>   gnu: Add ruby-turbolinks-source.
>   gnu: Add ruby-ref.
>   gnu: Add ruby-redjs.
>   gnu: Add ruby-rubygems.
>   gnu: Add ruby-heredoc-unindent.
>   gnu: Add ruby-hashdiff.
>   gnu: Add ruby-vcr.
>   gnu: Add ruby-listen.
>   gnu: Add ruby-listen-3.0.
>   gnu: Add ruby-ruby-dep.
>   gnu: Add ruby-rb-inotify.
>   gnu: Add ruby-guard-rspec.
>   gnu: Add ruby-guard-compat.
>   gnu: Add ruby-spring-watcher-listen.
>   gnu: Add ruby-rspec-spies.
>
> Christopher Baines (17):
>   gnu: Add ruby-erubi.
>   gnu: Add ruby-open4.
>   gnu: Add ruby-hamster.
>   gnu: Add ruby-lino.
>   gnu: Add ruby-terraform.
>   gnu: Add ruby-sucker-punch.
>   gnu: Add ruby-que.
>   gnu: Add ruby-autoprefixer-rails.
>   gnu: Add ruby-bootstrap-sass.
>   gnu: Add ruby-multi-xml.
>   gnu: Add ruby-omniauth-oauth2.
>   gnu: Add ruby-jwt.
>   gnu: Add ruby-oauth2.
>   gnu: Add ruby-omniauth.
>   gnu: Add ruby-warden.
>   gnu: Add ruby-warden-oauth2.
>   gnu: Add ruby-rerun.
>
>  gnu/packages/javascript.scm|   37 +
>  gnu/packages/maths.scm |   34 +
>  .../patches/ruby-coffee-rails-fix-rakefile.patch   |   20 +
>  .../patches/ruby-listen-3.0.8-patch-gemspec.patch  |   16 +
>  .../patches/ruby-listen-patch-gemspec.patch|   16 +
>  .../ruby-rspec-its-remove-rspec-gemspec.patch  |   22 +
>  .../patches/ruby-therubyracer-fix-gemspec.patch|   16 +
>  gnu/packages/rails.scm |  500 +++
>  gnu/packag

Re: Statistics and --rounds

[Gábor Boskovits]

2018-03-03 14:17 GMT+01:00 Gábor Boskovits :

> I will write here a short notice of the statistical implications of
> building software multiple times in general. I hope you will find this
> information useful.
>
> Hypothesis: the probability of successfully building the software is
> greater than or equal to p.
>
> This hypothesis can be accepted with a confidence level c=1-p^(k+1), where
> k is the number of rounds the software was built, and all the builds were
> succcesful.
>

Here is a spreadsheet that shows this in a more useful form. In the
spreadsheet you can see, that what is the probability of a successful build
give that a rounds n build succeeds and given the confidence level. I used
two of the most commonly use confidence levels, but this can be extended if
needed.


Build success probabilities.ods
Description: application/vnd.oasis.opendocument.spreadsheet

Re: npm (Rollup)

[Gábor Boskovits]

2018-03-05 11:34 GMT+01:00 Catonano :

> Hello list
>
> there's this project
> https://github.com/rollup/rollup
>
> I don't understand what it does, maybe because I don't know the first
> thing about javascript
>

You can think about this as a module system for javascript. Much like our
use-module and
export... This support is not yet available in most javascript engines, and
the javascript
community uses tools to get the support now, removing the tools, when
support becomes
available.


>
> I was wondering if that changes the situation with regard to porting npm
> based software in Guix
>
> Comments appreciated
>

I believe that this doesn't change the situation much. The problem is a
more generic one, though.
Actually the problem is not that we can't get npm based software working,
as it is quite possible to
package these. The problem is that npm fixes the versions, and this causes
a version explosion
in our repository. Most of those version requirements can be liberally
relaxed, so that we don't need
all those package versions. One of the things that could be done, is to try
to find out the real version
requirements of the software, and then, when the relaxed requirements of
all packages involved
get known optimize for the lowest number of packages required. This seems
to be hard.
We also have this kind of problem with virtually all language specific
package managers.

Re: Regarding Outreachy round 16

[Gábor Boskovits]

2018-03-06 17:03 GMT+01:00 Aakanksha Jain :

> Hi I'm Aakanksha, currently a B.tech  2nd-year student,
> I'm interested in working on the project "*Improve the user experience
> for Guix package*". I know C/C++ fair enough, I have experience working
> with GIT too.
>
> Can anyone tell me how do I begin contributing?
>
>
>
We usually recommend to install guix first, then build hello, and add a
package.
You can get the guix manual at https://www.gnu.org/software/guix/manual/.
The is a section on contributing:
https://www.gnu.org/software/guix/manual/html_node/Contributing.html#Contributing
.

Should you have any questions, don't hesitate to contact us here, on the
mailing list, or on the #guix IRC channel on Freenode.

Re: Regarding Outreachy round 16

[Gábor Boskovits]

2018-03-06 20:24 GMT+01:00 Gábor Boskovits :

> 2018-03-06 17:03 GMT+01:00 Aakanksha Jain :
>
>> Hi I'm Aakanksha, currently a B.tech <http://b.tech/> 2nd-year student,
>> I'm interested in working on the project "*Improve the user experience
>> for Guix package*". I know C/C++ fair enough, I have experience working
>> with GIT too.
>>
>> Can anyone tell me how do I begin contributing?
>>
>>
>>
> We usually recommend to install guix first, then build hello, and add a
> package.
> You can get the guix manual at https://www.gnu.org/software/guix/manual/.
> The is a section on contributing: https://www.gnu.
> org/software/guix/manual/html_node/Contributing.html#Contributing.
>
> Should you have any questions, don't hesitate to contact us here, on the
> mailing list, or on the #guix IRC channel on Freenode.
>

Finally some practical advice: once you have guix, you can build guix from
source in a "guix environment guix".
You can edit a package receipt with "guix edit pkgname", and search the
packages with "guix package -s pkgname".

You can install guix on a foreign distro, so you don't need to set up
GuixSD if you want to work on guix. However, if
you would like, then you are welcome to do so. We also provide a virtual
machine image with GuixSD, but my last
experience with that it needs resizing to do anything useful (not enough
disk space there).

This section will be very useful if you like to learn by examples:
https://www.gnu.org/software/guix/manual/html_node/Defining-Packages.html#Defining-Packages
.
You can easily expand from there, and looking at package receipes
containing similar to software to the one you are willing to package.

You can have a look at:
https://debbugs.gnu.org/cgi/pkgreport.cgi?package=guix, the guix bug
tracker, and
https://debbugs.gnu.org/cgi/pkgreport.cgi?package=guix-patches, this is for
tracking patches. New packages, and updates get listed here after mailing
to guix-patches.

You can find contact information on our home-page:
https://www.gnu.org/software/guix/.

Thank you for your interest :)

Re: Outreachy'18

[Gábor Boskovits]

2018-03-06 21:32 GMT+01:00 Ricardo Wurmus :

>
> Hi Reshu,
>
> > I am trying to install GUIX for ubuntu using sh script. I have named the
> > script "guix-install.sh".I created the sh file in nano and ran using bash
> > guix-install.sh Encountering an error "guix-install.sh: line 249:
> > /home/reshu/.guix-profile/etc/profile: No such file or directory".
>
> You need to run the script as the root user.  It seems to not like to
> run with sudo, so you would need to do “sudo su -” first to switch to
> the root account.
>
> (I’m not sure if the root account is usable on Ubuntu.)
>
>
Yes, the root account is usable on Ubunt, but I did not try the script yet.


> If the script doesn’t work for you, I’m afraid you’d have to follow the
> installation steps manually.  As Konrad explained, the procedure is
> described in the manual at
>
>   https://www.gnu.org/software/guix/manual/guix.html#Binary-
> Installation
>
> The script merely tries to automate these steps.
>
> Sorry for the bumpy ride!
>
> --
> Ricardo
>
> GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
> https://elephly.net
>
>
>
>

Re: extract tools from guix scripts

[Gábor Boskovits]

2018-03-08 21:15 GMT+01:00 Ricardo Wurmus :

>
> Gábor Boskovits  writes:
>
> > 2018-03-08 20:01 GMT+01:00 Ricardo Wurmus :
> >
> >> Hi Guix,
> >>
> >> under “guix/scripts” there are a couple of tools that are really useful,
> >> such as “guix challenge”.  While they are great for the command line,
> >> I’d really like to use them from within Guile.
> >>
> >> Using “(guix-challenge)” directly is cumbersome, because I need to
> >> provide an argument list “args”, which is then parsed internally.
> >> Instead, I’d like to be able to say
> >>
> >>(challenge #:urls (list "a" "b")
> >>   #:packages (list foo bar baz))
> >>
> >> and have it produce some report values.  Then “guix-challenge” could be
> >> implemented in terms of “challenge”.
> >>
> >> The same might be useful for “guix-build” or “guix-environment”.
> >>
> >>
> > I agree. This would also enable more flexible cli possibilities, and
> > would be really useful for scripting. Does this idea fit to the
> > improve command line tools outreachy idea?
>
> The outreachy project is about making the *output* of Guix prettier and
> less cluttered, so this would not be part of that project.
>
>
I see, then I'm willing to help you out with this, if we decide to
implement it.
I would wait for some more opinions thou.


> --
> Ricardo
>
> GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
> https://elephly.net
>
>
>

Re: extract tools from guix scripts

[Gábor Boskovits]

2018-03-08 20:01 GMT+01:00 Ricardo Wurmus :

> Hi Guix,
>
> under “guix/scripts” there are a couple of tools that are really useful,
> such as “guix challenge”.  While they are great for the command line,
> I’d really like to use them from within Guile.
>
> Using “(guix-challenge)” directly is cumbersome, because I need to
> provide an argument list “args”, which is then parsed internally.
> Instead, I’d like to be able to say
>
>(challenge #:urls (list "a" "b")
>   #:packages (list foo bar baz))
>
> and have it produce some report values.  Then “guix-challenge” could be
> implemented in terms of “challenge”.
>
> The same might be useful for “guix-build” or “guix-environment”.
>
>
I agree. This would also enable more flexible cli possibilities, and
would be really useful for scripting. Does this idea fit to the
improve command line tools outreachy idea?


> What do you think?
>
> --
> Ricardo
>
> GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
> https://elephly.net
>
>
>
>

Re: Half a success with chroot

[Gábor Boskovits]

2018-03-12 22:10 GMT+01:00 Thorsten Wilms :

> On 12.03.2018 20:17, Gábor Boskovits wrote:
>
> Hello! It would be nice to know the error code returned by the pivot_root
>> syscall. It might point to the reason of the failure.
>> Most probably you can get that using strace. Stracing the daemon is
>> possible using strace -fp pid_of_daemon.
>>
>
> Result of `strace -fp 3364 &> strace_guix-daemon.txt &` attached.
>
> grep -b4 -a4 pivot strace_guix-daemon.txt
> 5208309-[pid  3421] mount("none", "/gnu/store/4vgn265kihmk1aayy3
> rg5h4z00dvlfmy-emacs-bash-completion-2.0.0.drv.chroot/dev/shm", "tmpfs",
> 0, NULL) = 0
> 5208451-[pid  3421] lstat("/dev/pts/ptmx", 0x7fff0a3217a0) = -1 ENOENT (No
> such file or directory)
> 5208542-[pid  3421] chdir("/gnu/store/4vgn265kihmk
> 1aayy3rg5h4z00dvlfmy-emacs-bash-completion-2.0.0.drv.chroot") = 0
> 5208650-[pid  3421] mkdir("real-root", 000) = 0
> 5208694:[pid  3421] pivot_root(".", "real-root") = -1 EINVAL (Invalid
> argument)
> 5208766-[pid  3421] write(2, "while setting up the build envir"..., 190) =
> 190
> 5208837-[pid  3411] <... read resumed> "w", 1)  = 1
> 5208881-[pid  3421] exit_group(1 
> 5208923-[pid  3411] read(15,  
>
>
> Context:
> ---
> root@charly # guix-daemon --build-users-group=guixbuild &
> [1] 3364
> root@charly /# strace -fp 3364 &> strace_guix-daemon.txt &
> [2] 3395
> root@charly /# su thorwil
> thorwil@charly /$ source /etc/profile
> thorwil@charly /$ guix package -i emacs-bash-completion
> guile: warning: failed to install locale
> warning: failed to install locale: Invalid argument
> accepted connection from pid 3407, user thorwil
> spurious SIGPOLL
> The following package will be installed:
>emacs-bash-completion2.0.0 /gnu/store/7irxjifw4m8sj0if2nj
> 0r26vf0n0imsj-emacs-bash-completion-2.0.0
>
> substitute: guile: warning: failed to install locale
> substitute: warning: failed to install locale: Invalid argument
> substitute: updating list of substitutes from '
> https://mirror.hydra.gnu.org'... 100.0%
> The following derivations will be built:
>/gnu/store/gdihnrv0zykypajy7p94k9qzpmgqbkvz-profile.drv
>/gnu/store/xlyyh54y77nm8gzm81rckkcvzaihn7dh-fonts-dir.drv
>/gnu/store/pm80lbbbx2xhvnfb838zn90bwwcw2818-xdg-desktop-database.drv
>/gnu/store/nkcspwxnd7hmf144krxzv1clq4gch6ms-ca-certificate-bundle.drv
>/gnu/store/n72ahz242h07dz32g2fkpr308a6cwdb6-xdg-mime-database.drv
>/gnu/store/fw9k5rg7p6czcp4bnnqkr57gv1qcyg78-gtk-im-modules.drv
>/gnu/store/856smz8kn9l2gq2b6qcykv6aa06c3qv7-info-dir.drv
>/gnu/store/1bybb1dnry03qwkr2d2888xi2z0hb6y7-gtk-icon-themes.drv
>
> /gnu/store/4vgn265kihmk1aayy3rg5h4z00dvlfmy-emacs-bash-
> completion-2.0.0.drv
>/gnu/store/gwlj87yvqfsrv6lzcphfm65ndwpar0df-manual-database.drv
> guix package: error: build failed: while setting up the build environment:
> cannot pivot old root directory onto '/gnu/store/4vgn265kihmk1aayy3
> rg5h4z00dvlfmy-emacs-bash-completion-2.0.0.drv.chroot/real-root': Invalid
> argument
> ---
>
>
>
Could you please check, if the solution mentioned here works for you:
https://bugzilla.redhat.com/show_bug.cgi?id=1361043

A short summary: Similar error can be caused by shared mounts.

This way you can check if this applies.

Note 'shared' in the output:

grep -iP '/ /\s' /proc/$$/mountinfo
...
25 0 252:1 / / rw,relatime shared:1 - ext4 /dev/mapper/my--vg-root
rw,errors=remount-ro,data=ordered
...

This is usual in systemd systems, and Ubuntu is one of them.

Calling unshare -m within the process context helps this.

I'm forwarding this also to devel, so that we can discuss, if doing this is
advisable in
general. WDYT?


>
> --
> Thorsten Wilms
>
> thorwil's design for free software:
> http://thorwil.wordpress.com/
>

Re: Help needed: Unable to run Guix after installation

[Gábor Boskovits]

2018-03-12 21:25 GMT+01:00 Aakanksha Jain :

> I have completed the GNU Guix installation using this script
> https://git.savannah.gnu.org/cgit/guix.git/tree/etc/guix-install.sh
>
> But while trying to run hello package, I get following error(image
> attached)
>
> Someone on irc suggested installing nscd package. But its still not
> working.
>
> What can be the resolve for this?
>
>
Hello could you please check if the group guixbuild really exists?


>
>
>
>
>
>

Re: Internship on Improve the user experience for the "guix package" command line tool (Outreachy)

[Gábor Boskovits]

2018-03-21 18:03 GMT+01:00 Vijayalakshmi Vedantham :

> Thank you so much to everyone who replied. This project truly has the
> kindest and most polite people.
>
> I wanted to know what kind of system most people work on. My ubuntu is
> giving me Locale errors so I was thinking of creating a virtual environment
> and working on that. Do you think that will work out?
>
>
Most of the time I use a laptop with Ubuntu as a host system, and GuixSD
running in a KVM/qemu virtual machine. It works fine for me.


> Also, has the patch been applied yet?
>
>
Yes, I see that the patch has been applied already.


> Thanks,
> Vijayalakshmi
>
> On Wed, Mar 21, 2018 at 2:05 PM, Efraim Flashner 
> wrote:
>
>> On Tue, Mar 20, 2018 at 08:45:02PM +0530, Vijayalakshmi Vedantham wrote:
>> > Hi,
>> >
>> > I'm really sorry about the effort you had to put into this patch. I'll
>> try
>> > not to do it again.
>> >
>> > I had to append “.zip” because Pypi didn’t have a “.tar.gz” file for the
>> > > sources, so the uri
>> > > field now is:
>> > >
>> > >(pypi-uri "logwrap" version ".zip")
>> > >
>> >
>> > Did you do this because only .zip is available here (
>> > https://pypi.python.org/pypi/logwrap#downloads)?
>> >
>>
>> $ guix import pypi logwrap
>>
>> Starting download of /tmp/guix-file.BdwXcD
>> From https://pypi.python.org/packages/b3/17/c7d450ce6a1ce82e14585
>> 2895509fddc9468225d2aa312a772bb9c188a73/logwrap-3.2.1.zip...
>>  …3.2.1.zip  241KiB   869KiB/s 00:00 [##]
>> 100.0%
>>
>> In this case the importer grabbed a zip file, so I guess it falls into
>> tribal knowledge, definately something that should be documented better.
>>
>> >
>> > >
>> > > I also noticed that the sources include files that were generated with
>> > > Cython.  Instead of reusing those, we build them from source.  Luckily
>> > > all we have to do in this case is to add “python-cython” to the
>> > > native-inputs field.
>> > >
>> >
>> > Can I know how you knew this?
>>
>> For files that are generated by Cython they generally have a line at the
>> top that reads: "Generated by Cython 0.x.y" or something along those
>> lines. If you unzip the downloaded source and run 'grep Cython . -R'
>> inside the folder it'll show any files generated by Cython.
>>
>> >
>> >
>> > > Finally, the tests. At first the tests wouldn’t run.  So I looked up
>> the
>> > > error message online and found that I need to use
>> “python-pytest-runner”
>> > > in addition to “python-pytest”.  This allows the tests to run up to a
>> > > point until it wants to do coverage tests.  For those I needed to add
>> > > “python-pytest-cov”.
>> > >
>> > > I changed the description, because I think it wasn’t quite correct.
>> > >
>> >
>> > Again, I'm sorry.
>>
>> No worries, the test suite wasn't so easy. The release tarball/zip
>> didn't include good directions for running the test suite, I had to go
>> to the actual repository and see how the tests were run with 'tox' and
>> then try recreating the commands; I wasn't successful.
>>
>> As far as the description goes, it's my least favorite part :).
>>
>> >
>> >
>> >  Have you been able to build Guix already and try building the
>> package
>> > using “./pre-inst-env guix build”?
>> >
>> > No, I tried last night but I faced some issues, I'll try again tonight.
>> >
>> > Thanks,
>> > Vijayalakshmi
>>
>> --
>> 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: Modification for guix installation script.

[Gábor Boskovits]

2018-03-26 11:11 GMT+02:00 Ricardo Wurmus :

>
> Hi Clément,
>
> > As I said to Chris (Cc'ed), I don't think it's a good idea to install
> > Guix in root's home directory.  Instead, we should probably honor the
> > USER and HOME environment variables, so that the command can be run as a
> > non-root user (with sudo) in a consistent way.  What do you think?
>
> The script should be run as root as it follows the manual’s
> instructions, which tell people to install Guix for the root user and
> then make it available system-wide.
>
> This is why I think that it would be correct to install it to the root’s
> home directory and not to the sudoing user’s HOME.
>
> Or am I missing something?
>
>
I think Ricardo is right on this one. I would also recommend installing in
root's home directory. Ibelieve, that installing in a user home would make
sense only with a big amount of additional instrumentation and
documentation changes, along with arrangements to allow guix in
userspace. This is a straightforward way to make the script do what it's
purpose is.


> --
> Ricardo
>
> GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
> https://elephly.net
>
>
>
>

Re: 'core-updates' spring 2018

[Gábor Boskovits]

2018-03-26 20:34 GMT+02:00 Ricardo Wurmus :

>
> Hi Marius,
>
> > 'core-updates' has seen a lot of changes recently.  Some of the goodies
> > include […] glibc 2.27 […]
> >
> > Are there other things that should go in?
>
> I would really like to see a patch applied to glibc that ensures that
> the “prlimit64” syscall is not used when running on the RHEL 6 kernel
> (2.6.32).  The lack of this syscall on that kernel means that getrlimits
> fails, which makes it impossible to start the JVM.
>
>
Hello!
We already talked about this on #guix, and the patch removing code to
check for prlimit64 not implemented is a quite self contained commit on
the glibc tree. It is not a trivial one, and I did not try to revert that
yet, but
it might worth looking at.


> This problem appeared with the upgrade to glibc 2.26 already, and ever
> since I’ve been trying to minimize the damage for RHEL 6 systems where
> Guix is used as a package manager (such as the MDC).
>
> A work-around for glibc 2.27 that makes things work fine with the RHEL 6
> kernel would be very welcome!  I’ve started a branch “rhel6” where the
> default glibc has been bumped back to version 2.25 but I really don’t
> want it to be a long-lived branch; one of the reasons is that building
> all packages for this old glibc version (even just on x86_64) puts our
> build farms under extra stress that I would like to avoid.
>
> Another thing that could go in is the new Guile wrapper for wrapped
> scripts that I proposed a few months ago.  It requires a change in
> build-side code to provide a “wrap-script” procedure (it wouldn’t be
> used just yet).
>
> --
> Ricardo
>
> GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
> https://elephly.net
>
>
>
>

Re: Treating tests as special case

[Gábor Boskovits]

2018-04-05 7:24 GMT+02:00 Pjotr Prins :

> Last night I was watching Rich Hickey's on Specs and deployment. It is
> a very interesting talk in many ways, recommended. He talks about
> tests at 1:02 into the talk:
>
>   https://www.youtube.com/watch?v=oyLBGkS5ICk
>
> and he gave me a new insight which rang immediately true. He said:
> what is the point of running tests everywhere? If two people test the
> same thing, what is the added value of that? (I paraphrase)


Actually running tests test the behaviour of a software. Unfortunately
reproducible build does not guarantee reproducible behaviour.
Furthermore there are still cases, where the environment is
not the same around these running software, like hardware or
kernel configuration settings leaking into the environment.
These can be spotted by running tests. Nondeterministic
failures can also be spotted more easily. There are a lot of
packages where pulling tests can be done, I guess, but probably not
for all of them. WDYT?

>
>
With Guix a reproducibly building package generates the same Hash on
> all dependencies. Running the same tests every time on that makes no
> sense.
>
> And this hooks in with my main peeve about building from source. The
> building takes long enough. Testing takes incredibly long with many
> packages (especially language related) and are usually single core
> (unlike the build). It is also bad for our carbon foot print. Assuming
> everyone uses Guix on the planet, is that where we want to end up?
>
> Burning down the house.
>
> Like we pull substitutes we could pull a list of hashes of test cases
> that are known to work (on Hydra or elsewhere). This is much lighter
> than storing substitutes, so when the binaries get removed we can
> still retain the test hashes and have fast builds. Also true for guix
> repo itself.
>
> I know there are two 'inputs' I am not accounting for: (1) hardware
> variants and (2) the Linux kernel. But, honestly, I do not think we
> are in the business of testing those. We can assume these work. If
> not, any issues will be found in other ways (typically a segfault ;).
> Our tests are generally meaningless when it comes to (1) and (2). And
> packages that build differently on different platforms, like openblas,
> we should opt out on.
>
> I think this would be a cool innovation (in more ways than one).
>
> Pj.
>
>

Re: Introducing myself as an Outreachy Intern

[Gábor Boskovits]

2018-04-25 21:07 GMT+02:00 Gábor Boskovits :

> 2018-04-25 17:38 GMT+02:00 Ricardo Wurmus :
>
>>
>> Welcome Sahithi!
>>
>> > I Sahithi Yarlagadda, a Free Software enthusiast. I am from India,
>> > pursuing my under graduation final semester in Computer Science. I will
>> > be working as an Outreachy Intern for May-August 2018. I am glad to be
>> > part of Guix Community. I have been working with Ricardo Wurmus during
>> > the application process. He helped me in understanding and working with
>> > Guix. Community has given a great support, expecting the same till the
>> end.
>>
>> In my experience, this community is very supportive, patient, and
>> friendly.  I’m sure you will find the same.  I’m looking forward to
>> working with you and hope you’ll enjoy the experience.  Feel free to ask
>> questions by sending email to guix-devel@gnu.org — chances are that
>> someone else has the same question but didn’t dare to ask.
>>
>> To the rest of the Guix community: please welcome Sahithi and support
>> this project by answering questions on IRC or here on the list.
>>
>> I should add that Sahithi will be working on the project “Improve the
>> user experience for the "guix package" command line tool”, which will
>> address some of the major and minor problems that the command line
>> interface currently has.  I’m the primary mentor for this project, and
>> Gábor has volunteered to be co-mentor.  Thank you, Gábor!
>>
>>
> Welcome Sahithi!
>
> I'm looking forward to working with you. I'm Gábor, and I am
> co-mentoring the project. My IRC username is g_bor.
>
>> --
>> Ricardo
>>
>>
>>
>

Re: Introducing myself as an Outreachy Intern

[Gábor Boskovits]

2018-04-25 17:38 GMT+02:00 Ricardo Wurmus :

>
> Welcome Sahithi!
>
> > I Sahithi Yarlagadda, a Free Software enthusiast. I am from India,
> > pursuing my under graduation final semester in Computer Science. I will
> > be working as an Outreachy Intern for May-August 2018. I am glad to be
> > part of Guix Community. I have been working with Ricardo Wurmus during
> > the application process. He helped me in understanding and working with
> > Guix. Community has given a great support, expecting the same till the
> end.
>
> In my experience, this community is very supportive, patient, and
> friendly.  I’m sure you will find the same.  I’m looking forward to
> working with you and hope you’ll enjoy the experience.  Feel free to ask
> questions by sending email to guix-devel@gnu.org — chances are that
> someone else has the same question but didn’t dare to ask.
>
> To the rest of the Guix community: please welcome Sahithi and support
> this project by answering questions on IRC or here on the list.
>
> I should add that Sahithi will be working on the project “Improve the
> user experience for the "guix package" command line tool”, which will
> address some of the major and minor problems that the command line
> interface currently has.  I’m the primary mentor for this project, and
> Gábor has volunteered to be co-mentor.  Thank you, Gábor!
>
>
Welcome Sahithi!

I'm looking forward to working with you. I'm Gábor, and I am
co-mentoring the project. My ICR

> --
> Ricardo
>
>
>

Re: GSoC: Adding a web interface similar to the Hydra web interface

[Gábor Boskovits]

2018-05-13 20:45 GMT+02:00 Tatiana Sholokhova :

> Hi all,
>
> Thank you for your help and the provided resources which are very useful
> for me at the first stage of the project.
>
> I have built Cuirass on my local computer but I have encountered a few
> problems while doing it. It turned out that I had an old version of
> guile-sqlite3 installed by guix. I have spent some time discovering this
> issue. Eventually, I've found that all I had to do is to update guix
> packages list invoking "guix pull" and then update the packages.
>
> Unfortunately, I have no experience of IRC usage and I'm not sure how to
> do in a proper way. Of course, I would like to communicate with the
> community, but I'm not sure which discussions are relevant in the IRC. For
> instance, could I ask questions on building issues similar to ones I've
> encountered?
>
> I have taken a look at Danny's Cuirass frontend application. Now I try to
> run it locally. I have already figured out that I need to change URLPREFIX
> and name of the repository and the branch in the code. But I still can't
> get it working. According to the browser console, all the queries to
> localhost sent by js receive following error:
>
> "No 'Access-Control-Allow-Origin' header is present on the requested
> resource. Origin 'null' is therefore not allowed access."
>
> But similar queries work well if I enter them manually via the browser or
> curl. Could you give me any hints on that?
>
>
Hello Tatiana,

by any chance do you run this code through a file:///... url? Origin null
usually means that. If so, it would be better to test in a locally
installed webserver.


> Best regards,
> Tatiana
>
> 2018-05-09 20:21 GMT+03:00 Ricardo Wurmus :
>
>> Hi Tatiana,
>>
>> we haven’t heard from you since about a week, nor have I seen you on
>> IRC.  (Granted, I was offline for some time, so I probably just missed
>> your introduction.)
>>
>> The official so-called “community bonding period” of GSoC is soon coming
>> to an end, and it would be advisable to use the remaining time before
>> coding begins for some community bonding :)
>>
>> I’d like to repeat that frequent communication is the key to a
>> successful GSoC project.  If you have any questions about the project,
>> the code, or how to proceed, please don’t hesitate to let us know.
>>
>> Thanks!
>>
>> --
>> Ricardo
>>
>>
>

Re: Packaging a free Firefox

[Gábor Boskovits]

2018-05-15 10:57 GMT+02:00 Ludovic Courtès :

> Hi Pjotr,
>
> Pjotr Prins  skribis:
>
> > So I have been using Icecate for 10 days. It is frustrating because it
> > does crash every other hour on some JS load. The error always looks like
> >
> > Extension error: SyntaxError: in strict mode code, functions may be
> declared only at top level or immediately within another function
> resource://gre/modules/ExtensionUtils.jsm ->
> moz-extension://73353d04-3869-453b-8b9b-f71ceaae6e26/polyfill.js 63
> > [[Exception stack
> > Current stack
> > runSafeSyncWithoutClone@resource://gre/modules/ExtensionUtils.jsm:25:110
> > tryInject@resource://gre/modules/ExtensionContent.jsm:197:9
> > execute@resource://gre/modules/ExtensionContent.jsm:273:5
> > trigger@resource://gre/modules/ExtensionContent.jsm:463:11
> > DocumentManager.observe@resource://gre/modules/
> ExtensionContent.jsm:342:7
> > ]]
> >
> > I only have noscript and adblock plus installed and running. Any ideas?
>
> Did you check on the “about:home” page whether other things were
> enabled?  Also, is the JS error above fatal?  JS is designed to keep
> going in spite of errors (really!), so it could be that the thing above
> doesn’t matter.
>
> FWIW, I’ve been using IceCat (actually mostly Conkeror, but it’s the
> same thing) for a long time and I’ve rarely experienced crashes.  I’m
> surprised the experience is that bad for you.  Is this on GuixSD?
>
> > I think I'll go to FF again if this persists.
>
> IceCat is essentially the same code as FireFox modulo branding, add-ons,
> and a few trivial things.  I don’t see how IceCat itself could be
> blamed—the add-ons maybe, the way it is packaged in Guix perhaps, but
> IceCat?…
>
> Ludo’.
>
> There was  a bug in earlier Firefox, might that be that IceCat doesn't have
the fix for that yet? I don't know how much IceCat is delayed to Firefox.
https://stackoverflow.com/questions/24573061/uncaught-syntaxerror-in-strict-mode-code-functions-can-only-be-declared-at-top,
see the last comment.

Re: Status of Submitted Patches

[Gábor Boskovits]

2018-05-20 11:40 GMT+02:00 Ricardo Wurmus :

>
> Hi Sahithi,
>
> >> While this achieves the goal for a single character it does not
> >> constitute a custom port.  Have you read the documentation for
> >> “make-custom-port” in the Guile manual?
> >
> > I have tried with the following code for, Gábor helped me in process […]
>
> Oh, I haven’t seen those emails on the mailing list.  Please keep the
> discussion on the mailing list so that all mentors and the community can
> comment.
>
>
The discussion was on IRC in a 1:1 conversation. The task Sahitihi wanted
to achieve was to create a soft-port capitalizing all text sent to it. I
helped her
to achieve that. I was thinking about mailing you the details, but it was
only a
few lines of code. I will also make sure to keep you in the circuit in the
future.


> > the description for that goes this way
> >
> > The input taken from input port is read and stored in variable "s".
> > This variable is passed to make-soft-port. The variable s is
> > capitalized by locale conversion then binded with color. the result is
> > displayed when called.
>
> Please try to be a little more precise with the descriptions.  You
> defined a new port with “make-soft-port”.  The new port has two
> important procedures: one that takes a single character, and another
> that takes a string.  In the case of a single character you just pass it
> through to the current output port.  In the case of a string, you
> colorize it first and then write it to the output port.
>
> The result is a port that will print a coloured string whenever you pass
> it a string.
>
> How would you use this in “(guix store)”?  Note that we don’t want to
> apply colour to any and all strings there.  We want only certain
> messages to be coloured.  Can you please prepare a patch to “(guix
> store)” that shows us how you would use this new port?
>
> As a first change, could you please add the relevant parts of “(ice-9
> colorized)” to a module in Guix?  We probably don’t want to depend on
> having users install this module separately.  We also don’t need all of
> it.  Please prepare a patch that adds only the relevant parts to “(guix
> ui)” and update the copyright headers.
>
> > I have tried the other process using escape codes however failed with
> > the result i will come with this implementation and procedure in my next
> > mail
>
> I have not received this email.  Have you worked on this yet?
>
> When you have problems with code please always provide the relevant
> parts of your code with the error messages, so that we can help you.
>
> I think that we need to start moving forward at a slighter higher
> speed.  Thanks!
>
> --
> Ricardo
>
>
>

Re: Patch file for colorize module

[Gábor Boskovits]

2018-05-26 23:20 GMT+02:00 Ricardo Wurmus :

>
> Hi Sahithi,
>
> > I went wrong in squashing. Please check the current attachment.
>
> Thank you.
>
> I’ve made a couple of minor changes and pushed it to the branch
> “wip-sahithi”.


Nice, so now here is a branch where we can see this work. Thanks!

I am happy that Sahithi is making progress.


> These are some of the changes:
>
> * Removed whitespace changes and trailing whitespace.
> * Moved the docstring of “colorize-string” to the correct position.
> * Changed the author of the commit from “root” to you.
>
> You can run “git fetch origin” and then base your next work on
> “origin/wip-sahithi”.
>
> If you have any questions about the next steps please feel free to ask
> us.
>
> --
> Ricardo
>
>
>

Re: GSoC: Adding a web interface similar to the Hydra web interface

[Gábor Boskovits]

2018-05-29 18:07 GMT+02:00 Ludovic Courtès :

> Hello Tatiana & all,
>
> Ricardo Wurmus  skribis:
>
> >> I am a bit confused about the database structure. As far as I
> understand,
> >> there are project_name (project) and branch_name (jobset) properties,
> but
> >> project_name is a primary key, so a project can't have several branches?
> >
> > I share your confusion.  Maybe Ludovic or Mathieu can shed some more
> > light on this.
>
> It’s confusing indeed, I think it’s a mistake that has yet to be fixed.
> Basically what we do now is that we use a different ‘repo_name’ when we
> just want to add a branch…
>
> We should fix it at some point.  Suggestions welcome!
>
>
I believe the confusion arises from the fact, that there is a naming
inconsistency.
If we could come up with good names to the things involved, then that might
suggest a clean solution. It seems that the problem is caused by a project
and
a repository is somehow intermixed. That might suggest a solution to keep
project-name as is, as primary key, and add a separate repository field...
or not.
Does that make sense?


> I would encourage you to write commits in a way to minimize friction
> when we are to merge them—that is, following the conventions that
> Ricardo outlined.  That way Mathieu, Ricardo, or myself can take a look
> and quickly cherry-pick to master.
>
> Anyway, kudos on what you’ve already achieved!  Getting started on an
> existing code base is never easy, so I think you’ve done a good job.
>
> Thank you,
> Ludo’.
>
>

Re: Cleaning up make clean's behavior

[Gábor Boskovits]

2018-06-02 18:46 GMT+02:00 Nils Gillmann :

> Hi Jeremiah,
>
> jerem...@pdp10.guru transcribed 946 bytes:
> > As running make clean breaks the bootstrap script.
> > I propose we leverage git's shallow clones (git clone --depth 1 $URL)
> > and include the .git directory with the repo such that we could simply
> > have make clean check for git and if it exists run git clean -xdf and
> > then only if git fails to exist, fallback to the existing broken form;
> > which needs to be corrected.
> >
> > per discussion with g_bor[m] about the default automake clean rules
> > being used currently; and per their suggestion bringing this question to
> > this distribution list for further discussion.
>
> Where did this discussion take place? Would be good to read some
> details if possible.
>
> ng0
>
> > Additional wouldn't one want to pack the .git in the tarball to enable a
> > simplified update method.
> >
> > jlicht pointed out that this would not be a problem yet for guix, but it
> >  does seem unconventional. It would not make sense for some bigger-repo
> projects (e.g. emacs) for sure though
> >
> > Given that discussion background does anyone have any problems, concerns
> > or issues with the change proposed?
> >
>
> It was on #guix. Currently I have found what causes the problem with make
clean. I'm working on an alternative fix, but the idea outlined here seems
to worth discussing.

Re: 2 ideas

[Gábor Boskovits]

2018-06-10 13:26 GMT+02:00 Thorsten Wilms :

> On 10.06.2018 11:54, Pierre Neidhardt wrote:
>
>> Then intention of the Arch post-install script is good (that is,
>> informing the user) but I find the implementation brittle: if the
>> messages are too many or too long, it can be very easy to miss a
>> message.
>>
>> Furthermore, the script cannot be triggered out-of-install, which means
>> that once the shell session is gone, the information is gone.  (It's
>> still in the log but it's not so convenient to read and you must know
>> what you are looking for in advance.)
>>
>
>
> What if each package with such a message would install it as a text-file
> in a specific directory? With a separate mechanism to bring each new
> message file to the user's attention, plus a means of stepping through all
> of them.
>
>
>
I think it might be nice to have something like --show-post-install-doc in
guix package, if we decide to implement this.++


> --
> Thorsten Wilms
>
> thorwil's design for free software:
> http://thorwil.wordpress.com/
>
>

Re: my latest blog post [everyone, please take a cooldown break]

[Gábor Boskovits]

+1

2018-06-10 15:33 GMT+02:00 Christopher Lemmer Webber :

> Nils Gillmann writes:
>
> > Hi,
> >
> > I think it would be best if everyone involved would cool down for a
> couple of
> > days, restructure their thoughts and reflect on this thread. Look at what
> > they are doing, and at how they are reacting to other peoples reaction.
> > This topic is getting quiet heated, and other than the maintainers we
> > do not have established some kind of mderation. It can be hard to discuss
> > some topics online.
> > Text can sometimes fail to transport what we attampt to express, and
> > I have seen people step away from projects because of this.
>
> +1000
>
>