Re: Outreachy Applicant: An Introduction

[Magali Lemes]

Hi Aniket and Bonface,
thank you two for the nice suggestions. That was exactly what I
was looking to get started into emacs.

Magali

Em ter., 13 de out. de 2020 às 21:48, Aniket Patil <
aniket112.pa...@gmail.com> escreveu:

> Hi Lemes,
>
> I am also emacs user and Outreachy applicant. I would suggest you to go
> through tutorial of emacs which is inbuilt and then go through this video
> series.
>
> https://www.youtube.com/playlist?list=PL9KxKa8NpFxIcNQa9js7dQQIHc81b0-Xg
>
> I hope you find it helpful.
>
> Aniket.
>
> On Tue, 13 Oct 2020 at 4:38 PM, Magali Lemes 
> wrote:
>
>> Hey,
>> I'm using Ubuntu 20.04.1 LTS. I must say I've never used emacs before, so
>> I'll try to get the hang of it.
>> Sharing my progress: I decided to package the arduino IDE, but it turned
>> out
>> way harder than I expected, due to its many dependencies. I ended up not
>> doing it, but it was a good experience because I could learn about some
>> functions in Scheme - chdir, for example -, some of the phases of
>> building a package - like unpacking, configuring and building - and I
>> could
>> also interact with the community, asking for help, via IRC, which is a
>> very new thing for me.
>> As for today, I will continue trying to package something. I'll probably
>> follow
>> your previous advice and begin with a R package. It seems easier, so
>> hopefully
>> I'll succeed.
>>
>> Cheers,
>> Magali.
>>
>> Em seg., 12 de out. de 2020 às 12:06, zimoun 
>> escreveu:
>>
>>> Hi,
>>>
>>> On Mon, 12 Oct 2020 at 13:00, Magali Lemes 
>>> wrote:
>>>
>>> > Guix was fairly easy to install, I used the shell script to do that.
>>>
>>> Which distribution do you use?
>>>
>>> > I installed emacs using Guix and it worked as expected.
>>>
>>> Nice!
>>> Personally, I manage the Emacs packages with Guix via a manifest.scm
>>> file.  And in a separate profile.  My conf [1] is far from perfect but
>>> if you need inspiration. :-)
>>>
>>> 1: 
>>>
>>> > I'll begin by trying to package something. So, I'll go through the
>>> links you sent
>>> > and see how that goes.
>>>
>>> Cool!
>>> Do not hesitate to ask on help-guix or #guix if you encounter issues
>>> on your path.  And feel free to send your progress, success or
>>> failure.
>>>
>>>
>>> All the best,
>>> simon
>>>
>>

Re: Removing/replacing “Guix in action” video from the home page?

[Bonface M. K.]

Joshua Branson  writes:

> I would describe my video set up as pretty simple:
>
> $ wf-recorder --audio
>

Thanks for sharing!

> If you watch any of my below videos, you'll see me take breaks like, "Oh
> hold on just a second, I think my landlord is knocking at my front
> door. I'll be right back."

I think I saw one of them a while back. I'll try
watching more of them :)

-- 
Bonface M. K. (https://www.bonfacemunyoki.com)
Chief Emacs Mchochezi / Twitter: @BonfaceKilz
GPG key = D4F09EB110177E03C28E2FE1F5BBAE1E0392253F


signature.asc
Description: PGP signature

Re: Did nmap just become non-free?

[Brett Gilio]

Marius Bakke  writes:
>
> ...I'm fairly certain this is not an acceptable license for Guix, or
> free software distributions in general.
>

This is definitely not a consistent license for us.

> So I think we should revert the license change, as well as the update
> to 7.90 which introduced the new license.
>
> Now to read the previous license text, perhaps that will help me sleep..
>


As to how to fix it, I think we will need to revert the change, and also
make note of the FINAL version of nmap that was still compliant with FSDG.


-- 
Brett M. Gilio

https://brettgilio.com

Re: Removing/replacing “Guix in action” video from the home page?

[Luis Felipe]

‐‐‐ Original Message ‐‐‐
On Tuesday, October 13, 2020 8:39 PM, Ludovic Courtès  wrote:

> Hi,
>
> Luis Felipe luis.felipe...@protonmail.com skribis:
>
> > > The home page has a “Guix in action” video that’s becoming outdated. It
> > > would be nice to have an updated version of it using in particular the
> > > short aliases (‘guix search’, ‘guix install’, etc.). Perhaps we could
> > > use ‘emacs-gif-screencast’ to make it hopefully lightweight non-blurry
> > > (and with a larger font size).
> >
> > Or maybe try with asciinema to record video. The problem I see with GIF for 
> > this is that people don't have playback control.
>
> Right. Asciinema is nice but we’d need to serve a whole bunch of JS.
> Perhaps the ideal thing would be to fall back to Webm/GIF when JS is
> unavailable…


JS? Oh no. I thought asciinema generated a video only (I haven't use it 
myself). We only need webm video.

Did nmap just become non-free?

[Marius Bakke]

Hello,

I updated the nmap license in 2323a7120a0f3ed96fedfff42e86c0aee97995c0.
Admittedly I had only skimmed through the text, which is "based on GPL2"
and "believed to be compliant with the 'Open Source Definition'", but
after a closer read of the annotated version:

  https://nmap.org/npsl/npsl-annotated.html

...which states:

  Proprietary vendors: This license does not allow you to redistribute
  Nmap source code or the executable for use with your software (stand
  alone or on an appliance).

...I'm fairly certain this is not an acceptable license for Guix, or
free software distributions in general.

So I think we should revert the license change, as well as the update
to 7.90 which introduced the new license.

Now to read the previous license text, perhaps that will help me sleep..


signature.asc
Description: PGP signature

Re: staging freeze

[Marius Bakke]

Julien Lepiller  writes:

> Le 13 octobre 2020 17:54:16 GMT-04:00, Marius Bakke  a écrit :
>>Hello Guix,
>>
>>I've pushed a set of updates to the long-overdue "staging" branch.
>>
>>Let's get it merged once Cuirass is done building for the various
>>architectures.  Not sure how long that takes now that we no longer use
>>transparent QEMU emulation for AArch64 and armhf.
>
> I have my groovy update ready to push to staging. Can I push it, or should I 
> wait for next time staging is open?

Sure, go ahead!  I suppose we can give people a day or two to brush up
any almost-ready patches.


signature.asc
Description: PGP signature

Re: staging freeze

[Julien Lepiller]

Le 13 octobre 2020 17:54:16 GMT-04:00, Marius Bakke  a écrit :
>Hello Guix,
>
>I've pushed a set of updates to the long-overdue "staging" branch.
>
>Let's get it merged once Cuirass is done building for the various
>architectures.  Not sure how long that takes now that we no longer use
>transparent QEMU emulation for AArch64 and armhf.

I have my groovy update ready to push to staging. Can I push it, or should I 
wait for next time staging is open?

staging freeze

[Marius Bakke]

Hello Guix,

I've pushed a set of updates to the long-overdue "staging" branch.

Let's get it merged once Cuirass is done building for the various
architectures.  Not sure how long that takes now that we no longer use
transparent QEMU emulation for AArch64 and armhf.


signature.asc
Description: PGP signature

Re: Outreachy internship

[Ricardo Wurmus]

Hi Joshua,

> I haven't really followed what others have proposed, but you could
> certainly get some ideas here:
>
> https://libreplanet.org/wiki/Group:Guix/GSoC-2020

It’s a good thought, but that’s not how it works for Outreachy.  We have
a number of Outreachy projects that internship candidates should be able
to see on the Outreachy website.  It’s separate from GSoC and operates
under different rules and guidelines.  However, that page is a good
source of ideas for Outreachy *mentors* in future internship rounds.

Hi Luta,

welcome to Guix!  Independent of the internship project you end up
choosing I recommend starting by installing Guix (as a package manager)
using the installer script at https://guix.gnu.org/install.sh and
familiarizing yourself with it e.g. by installing a package.  Once
you’re comfortable with the features Guix offers I suggest looking at
the Contributing section in the manual to set up an environment to make
your first contribution to Guix.

Be sure to ask for help on #guix whenever you feel something isn’t quite
clear.  At this point you really can’t go wrong by asking for help.
Getting started is the most important part and often the most difficult
hurdle, so we’d like to help you overcome it as quickly as possible.

-- 
Ricardo

Re: Outreachy internship

[zimoun]

Hi Joshua and Brett,

The Outreach proposals are proposal by the project (hence Guix).  And
for this round there are two:

 1. store and IPFS
 2. implement “guix git log“ to browse the local repo.


Well, #1 is the pending patches which need love:

   
   

And the #2 is initially described here:

   


Usually, there is a Call for proposal [3] and then a Call for mentors
[4].  Does it make sense?

Cheers,
simon

3: 
4: 

Re: Shipping more installer images?

[Ludovic Courtès]

Efraim Flashner  skribis:

> On Mon, Oct 12, 2020 at 01:47:25PM +0200, Ludovic Courtès wrote:
>> Hi,
>> 
>> Mathieu Othacehe  skribis:
>> 
>> >> I'm actually not really sure how one would use the installer on one of
>> >> the boards. I think the bare-bones disk-images would be best; just
>> >> download it and flash it onto the board or an SD card and edit
>> >> /etc/config.scm to add your user and services. Or to boot up into the
>> >> installer and overwrite itself.
>> >
>> > The CI is already building substitutes for two images
>> > (hurd-barebones-qcow2-image and pine64-barebones-raw-image). We could
>> > maybe release 1.2 version of those images.
>> 
>> Keep in mind that images use space at ftp.gnu.org and also take time to
>> build (having CI up-to-date helps with that, but it doesn’t not
>> eliminate build times due to the ‘update-guix-package’ dance that takes
>> place during “make release”.)
>
> We could also list out the commands for building the image and have
> "community images" built and tested by people who actually have the
> boards.

Yeah, though “community images” could rhyme with
“we’re-not-sure-what’s-inside images”.  :-)

>> Likewise, if we ship more images, we should update the “System
>> Installation” section accordingly and be clear about what users can
>> expect.
>
> My slightly more featureful pine64plus image I built for myself came out
> to 1.5 GiB and 291 MiB with bzip2. I don't know how much space the other
> images or x86* images are.

Cool.

> We could also build and test them on a different schedule and upload
> them at a later date as they're shown to be working.

Hmm, tricky, security-wise.

Anyway, let’s work on that for 1.3!

Ludo’.

Re: Shipping more installer images?

[Ludovic Courtès]

Hi,

Mathieu Othacehe  skribis:

>> So that’s 3 more 1 GiB installer images, right?  If we target Oct. 29th,
>> how are we going to test them in the meantime?  How long will it take to
>> build them, even assuming we build on an OverDrive?
>
> I plan to provide compressed disk images for those boards so it's more
> around 400MB. Anyway, compression patches are not available yet and I
> don't even own one of those boards.
>
> So, while we can provide latest images for those boards, having them in
> a stable image will wait 1.3 I guess.

OK, sounds like a more reasonable plan to me!  :-)

Ludo’.

Re: File search progress: database review and question on triggers

[Ludovic Courtès]

Pierre Neidhardt  skribis:

>> “Something” needs to build the file-to-package database (which is what
>> you’re working on), and then there needs to be a way for users to fetch
>> that database.  This is all orthogonal to substitutes, as I see it,
>> which is why I think we need to think about integrating it maybe with
>> ‘guix publish’ on the server side and (guix channels) on the client
>> side.
>
> If the database is filled on =guix build=, then the substitute server
> would automatically have a filesearch database.
>
> Question: How do I hook onto =guix build=?

You would need a build-completion hook in the daemon, which doesn’t
exist (yet!).  Note also that at this level we only see derivations, not
packages.

>> Ah got it; having a database known to correspond to a specific commit is
>> even better.
>>
>> However, note that it could take time for the server to provide the
>> complete database for a commit (the time for as many packages as
>> possible to be built), so clients may want to refresh it anyway, or even
>> perhaps to use an older database.
>
> Indeed, and that's why I think we need to include a timestamp: if the
> client's database timestamp is older than that of the substitute server
> database, then we re-fetch it.

Yeah, maybe that can work.

Thanks,
Ludo’.

Re: Outreachy internship

[zimoun]

Hi!

Welcome!
And thank you for your interest in Guix.

Are you currently running Guix?

If no, the easiest is to start with the package manager [1] using the
shell script installer (first Red note in [1] :-)).  The package manager
works on any GNU/linux distribution and is not in conflict with the
distro package manager.  Do not hesitate to ask on help-g...@gnu.org or
#guix if you hit any problem, the Guix folks are prompt for
answering. :-) Once you can run "guix " [2], you can read how
to define a package [3].  BTW, give a look to the Perfect Setup [4] and
here [5] my config files if you need inspiration. ;-)

Well, if you have already used –– or currently using –– you can try
"guix import" or "guix refresh"; i.e., write your first package
contribution.  Therefore, you need to read [6].  Again, do not hesitate
to ask on help-g...@gnu.org or #guix if you hit any problem.

To be concrete, I suggest reading [3, 7, 8, 9, 10, 11, 12] and try to
package something.  Easy and good candidates for first packages are CRAN
or BioConductor packages:

   guix import cran 
   guix import cran -a bioconductor 

You can pick unpackaged one from the list [12].  Do not hesitate to ask
if you do not find an obvious one –– it should a good occasion to show
you “guix repl”. :-)


[1] 
http://guix.gnu.org/manual/devel/en/html_node/Binary-Installation.html#Binary-Installation
[2] 
http://guix.gnu.org/manual/devel/en/html_node/Getting-Started.html#Getting-Started
[3] 
http://guix.gnu.org/cookbook/en/html_node/Packaging-Tutorial.html#Packaging-Tutorial
[4] 
http://guix.gnu.org/manual/devel/en/html_node/The-Perfect-Setup.html#The-Perfect-Setup
[5] https://github.com/zimoun/my-conf
[6] http://guix.gnu.org/manual/devel/en/html_node/Contributing.html

7 : https://guix.gnu.org/manual/devel/en/guix.html#Defining-Packages
8 : https://guix.gnu.org/manual/devel/en/guix.html#Packaging-Guidelines
9 : https://guix.gnu.org/manual/devel/en/guix.html#Invoking-guix-import
10: https://guix.gnu.org/manual/devel/en/guix.html#Invoking-guix-refresh
11: https://guix.gnu.org/manual/devel/en/guix.html#Building-from-Git
12: https://bioconductor.org/packages/release/bioc/


There are two other different possible next steps then packaging,
depending on your interest.  In random order:

 + See if you want to contribute to the translation effort.  If you
are native of one of these languages:



help is welcome!  For example, my first contribution to Guix was to read
cover-to-cover the Guix manual and proofread the French translation.
Doing so is an unusual way to be familiar with the Guix ecosystem but
really interesting.  Note that it would be part of this effort:



 + Tweak the source of Guix.

  git clone https://git.savannah.gnu.org/git/guix.git
  cd guix
  guix environment guix --pure
  ./bootstrap
  ./configure --localstatedir=/var/
   make -j 8 # adapt
   make check
   ./pre-inst-env guix help # the fresh compiled 'guix' ;-)

You could be interested by
.

Well, then you can try to fix a bug  and I
recommend one with the tag easy:




And in any case, feel free to ask _any_ question on help-g...@gnu.org or
IRC #guix.


Keep in touch.
Cheers,
simon

Re: Outreachy internship

[Brett Gilio]

Joshua Branson  writes:

>
> I personally think it would be great to see some improvement to the GNU
> Shepherd.  It could use some love.  :)
>

+1

-- 
Brett M. Gilio

https://brettgilio.com

Re: Outreachy internship

[Joshua Branson]

I haven't really followed what others have proposed, but you could
certainly get some ideas here:

https://libreplanet.org/wiki/Group:Guix/GSoC-2020

I personally think it would be great to see some improvement to the GNU
Shepherd.  It could use some love.  :)

--
Joshua Branson
Sent from Emacs and Gnus
https://gnucode.me
https://video.hardlimit.com/accounts/joshua_branson/video-channels
"You can have whatever you want, as long as you help enough other people get 
what they want." - Zig Ziglar

Re: Removing/replacing “Guix in action” video from the home page?

[Joshua Branson]

I would describe my video set up as pretty simple:

$ wf-recorder --audio

If you watch any of my below videos, you'll see me take breaks like, "Oh
hold on just a second, I think my landlord is knocking at my front
door. I'll be right back."

-- 
Joshua Branson
Sent from Emacs and Gnus
https://gnucode.me
https://video.hardlimit.com/accounts/joshua_branson/video-channels
"You can have whatever you want, as long as you help enough other people get 
what they want." - Zig Ziglar

Re: Removing/replacing “Guix in action” video from the home page?

[Ludovic Courtès]

Hi,

Luis Felipe  skribis:

>> The home page has a “Guix in action” video that’s becoming outdated. It
>> would be nice to have an updated version of it using in particular the
>> short aliases (‘guix search’, ‘guix install’, etc.). Perhaps we could
>> use ‘emacs-gif-screencast’ to make it hopefully lightweight non-blurry
>> (and with a larger font size).
>
> Or maybe try with asciinema to record video. The problem I see with GIF for 
> this is that people don't have playback control.

Right.  Asciinema is nice but we’d need to serve a whole bunch of JS.
Perhaps the ideal thing would be to fall back to Webm/GIF when JS is
unavailable…

Ludo’.

Re: raise(-1) succeeds for programs linked against libpthread

[Ludovic Courtès]

Samuel Thibault  skribis:

> Ludovic Courtès, le mar. 13 oct. 2020 15:41:37 +0200, a ecrit:
>> ‘pthread_kill’ passes the signal number to ‘_hurd_raise_signal’, which
>> assumes it is valid:
> [...]
>> I suppose that before calling ‘sigaddset’, it should check whether SIGNO
>> is within bounds, along the lines of:
>> 
>>   if (signo < 2 || signo >= _NSIG)
>> return EINVAL;
>> 
>> Does that make sense?
>
> Probably, yes. Why excluding SIGHUP?

Oops, an oversight: I was looking at ‘signum-generic.h’ and the first
definition is SIGINT (2).  :-)

Ludo’.

Re: Reproductibility, Data Services, guix weather

[Christopher Baines]

zimoun  writes:

> The issue is to be able to find them.  I proposed (below) to run cron
> task doing ’--check’ on the build farms and then report by email the
> failure.  Chris indicated me the work they is doing [3] and instead of a
> cron task, they is proposing to parse the JSON.  That’s what the tiny
> script attached is doing.
>
>guix repl -L . -- weather-repro.scm
>
> For example, I run:
>
>guix repl -L . -- weather-repro.scm | sort | grep ghc
>
> to list (almost) all the unreproducible Haskell packages.  What I would
> like is to be able to filter by build system for example.
>
>
> First, Chris could you add the fields package name and version?  Because
> it is hard to automatically reconstruct them by parsing the output-path.

Done in [1], and I've updated data.guix-patches.cbaines.net.

1: 
https://git.savannah.gnu.org/cgit/guix/data-service.git/commit/?id=f15dc5ab0b48f4228a3c545052a1e4daf3e80f15

> Second, the revision of 
> does not match the Guix commit.  Is it possible to have a bridge?  Other
> said, how is computed this revision hash?
>
> (A working revision is 6cf35799dec60723f37d83a559429aa8b90482d5 which
> does not seems founding in Guix repo.)

So, that particular commit is just some revision of Guix with some
patches applied. I picked it because it was the most recent
data. There's now recent commits for the master branch itself [2] like
[3].

2: https://data.guix-patches.cbaines.net/repository/2/branch/master
3: 
https://data.guix-patches.cbaines.net/revision/ec82d58526c27a9ca26f6c5e39cec90a48cbc1cc


signature.asc
Description: PGP signature

Re: [PATCH] installer: Add Emacs EXWM desktop environment. [WAS Re: Call for 1.2 installer testing.]

[Jan Nieuwenhuizen]

Mathieu Othacehe writes:

Hi Mathieu,

>> It works for me; I found Emacs EXWM missing however.  After zenny also
>> asked about that this morning, I decided to create a patch.
>
> Thanks for testing

Using it is real easy, pleasant, and fast.  One thing that I got wrong a
couple of times is to actually select a suggested option while
partitioning, I pressed TAB and RET (like in previous screens), then
selecting the button that is clearly marked EXIT.  Then it tries to
continue with a non-partitioned or badly partitioned drive, which then
may give an unexpected error.

Clearly a user error, not a problem and I also do not have a better
suggestion.  Also, my mistake was very obvious to me later.

> and for the patch!  I think it might be necessary to
> add "emacs-exwm" to "installation-target-os-for-gui-tests" in (gnu tests
> install) module.

Good call.  I verified that the test fails without it..

> To make sure that it's working fine you can run:
>
> make check-system TESTS="gui-installed-os gui-installed-os-encrypted
> gui-installed-desktop-os-encrypted"

--8<---cut here---start->8---
cannot build derivation 
`/gnu/store/7xnhrap7xsv2x717yn9wrgisxpppxrmy-emacs-27.1.drv': 1 dependencies 
couldn't be built
cannot build derivation 
`/gnu/store/kkfdhpc81h0f0sz0mj1ayin0sxy7vkmq-emacs-desktop-environment-0.3.0.drv':
 1 dependencies couldn't be built
cannot build derivation 
`/gnu/store/3amvkhwa4jv8fghljgkcvlkpg4mpwc8v-emacs-exwm-0.24.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/q4pxd90hb9mah7cs9r1cjyb2pif1ixmz-emacs-xelb-0.18.drv': 1 
dependencies couldn't be built
--8<---cut here---end--->8---

and veried that it passes when I adding them.

> Otherwise, it looks fine.

Thanks, pushed to master as 1197b8b20f4fca4ce03bbc5fa75e18d54e3717c0.

Greetings,
Janneke

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

New Esperanto PO file for 'guix' (version 1.2.0-pre1)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

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

https://translationproject.org/latest/guix/eo.po

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

All other PO files for your package are available in:

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

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

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

The following HTML page has been updated:

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

If any question arises, please contact the translation coordinator.

Thank you for all your work,

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

New Esperanto PO file for 'guix-packages' (version 1.2.0-pre1)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

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

https://translationproject.org/latest/guix-packages/eo.po

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

All other PO files for your package are available in:

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

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

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

The following HTML page has been updated:

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

If any question arises, please contact the translation coordinator.

Thank you for all your work,

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

Re: Removing/replacing “Guix in action” video from the home page?

[Bonface M. K.]

Joshua Branson  writes:

> I send a ton of time making videos online, so I can probably spare some
> time to do this.  I'll have a video posted in a day or two.
>
> Thanks,
>
> Joshua
>

What's your video setup look like? Moreso [free]
tools that you'd use to cut, splice and clean
audio.

> --
> Joshua Branson
> Sent from Emacs and Gnus
> https://gnucode.me
> https://video.hardlimit.com/accounts/joshua_branson/video-channels
> "You can have whatever you want, as long as you help enough other people get 
> what they want." - Zig Ziglar
>
>

-- 
Bonface M. K. (https://www.bonfacemunyoki.com)
Chief Emacs Mchochezi / Twitter: @BonfaceKilz
GPG key = D4F09EB110177E03C28E2FE1F5BBAE1E0392253F


signature.asc
Description: PGP signature

Re: Outreachy Applicant: An Introduction

[Bonface M. K.]

Hi!

Magali Lemes  writes:

> Hey,
> I'm using Ubuntu 20.04.1 LTS. I must say I've
> never used emacs before, so 
> I'll try to get the hang of it.

Welcome to the club(of Emacsen users)! You'll get
used it to it ;). Here's a good channel that shows
you some cool things that you can get done in
Emacs:
https://www.youtube.com/channel/UC0uTPqBCFIpZxlz_Lv1tk_g. I'd
recommend the magit video; it comes in really
handy IMHO.

> Sharing my progress: I decided to package the
> arduino IDE, but it turned out
> way harder than I expected, due to its many
> dependencies. I ended up not
> doing it, but it was a good experience because I
> could learn about some
> functions in Scheme - chdir, for example -, some
> of the phases of
> building a package - like unpacking, configuring
> and building - and I could
> also interact with the community, asking for
> help, via IRC, which is a 
> very new thing for me.
> As for today, I will continue trying to package
> something. I'll probably follow 
> your previous advice and begin with a R package.
> It seems easier, so hopefully
> I'll succeed.
>
> Cheers,
> Magali.
>
> Em seg., 12 de out. de 2020 às 12:06, zimoun <
> zimon.touto...@gmail.com> escreveu:
>
> Hi,
>
> On Mon, 12 Oct 2020 at 13:00, Magali Lemes <
> magalileme...@gmail.com> wrote:
>
> > Guix was fairly easy to install, I used the
> shell script to do that.
>
> Which distribution do you use?
>
> > I installed emacs using Guix and it worked
> as expected.
>
> Nice!
> Personally, I manage the Emacs packages with
> Guix via a manifest.scm
> file.  And in a separate profile.  My conf
> [1] is far from perfect but
> if you need inspiration. :-)
>
> 1: 
>
> > I'll begin by trying to package something.
> So, I'll go through the links you sent
> > and see how that goes.
>
> Cool!
> Do not hesitate to ask on help-guix or #guix
> if you encounter issues
> on your path.  And feel free to send your
> progress, success or
> failure.
>
> All the best,
> simon

-- 
Bonface M. K. (https://www.bonfacemunyoki.com)
Chief Emacs Mchochezi / Twitter: @BonfaceKilz
GPG key = D4F09EB110177E03C28E2FE1F5BBAE1E0392253F


signature.asc
Description: PGP signature

Outreachy internship

[Luta Kalina]

Hello there!

I'm Jade (lost_enchanter at IRC), I came from Outreachy and I'd like to try
contributing even though there are two proposals already! I'd like to hear
what I can do to help.

Re: Call for 1.2 installer testing.

[Alex Sassmannshausen]

Hello,

Here a positive installation experience:

I did my usual bare metal installation of the image linked below on a
ThinkPenguin laptop that has always worked pretty well with Guix.

Ran through the graphical installation, going through configuration
options that have caused problems in the past (Esperanto locale, based
in Brussels, with Neo2 keyboard layout, fully encrypted disk).

The installation proceeded like a charm. Perhaps partly to do with me
now being used to the installer, and having hardware that "just works"
with libre software, but this was super user friendly. And actually also
super fast!

Congratulations and a massive thanks to everyone who's put time and
energy into this!

I can honestly say, with the current state, I would absolutely try a
guix system deployment in the first instance on any laptop I might
consider a GNU\Linux install, and only falling back to Debian if there
are hardware issues.

Very impressed.

Best wishes,

Alex

Mathieu Othacehe  writes:

> Hello,
>
> The 1.2 release is on its way. So here's the traditional call for
> installer testing. This time, the CI is building latest installer
> images, which should ease testing.
>
> I propose that we first concentrate our efforts on this image:
> https://ci.guix.gnu.org/download/654 which corresponds to commit
> 29a2eb3.
>
> Testing different partitioning schemes on different hardware is really
> important to spot issues that our virtualized automated installer tests
> would be missing.
>
> Thanks for your help,
>
> Mathieu



signature.asc
Description: PGP signature

Re: Shipping more installer images?

[Danny Milosavljevic]

Hi Ludo,

On Tue, 13 Oct 2020 15:51:19 +0200
Ludovic Courtès  wrote:

> > IMO there are only very few RYF-worthy ARM devices--and we should support
> > at least those, if we support any ARM devices at all.  That includes
> > providing images for those few (at least A20-EOMA68, A?0*Olinuxino*, and
> > Novena).  
> 
> So that’s 3 more 1 GiB installer images, right?  If we target Oct. 29th,
> how are we going to test them in the meantime?  How long will it take to
> build them, even assuming we build on an OverDrive?

Sure, I didn't mean "provide them in this release".

I meant: eventually.


pgpluc_OUmEP7.pgp
Description: OpenPGP digital signature

Re: [PATCH] installer: Add Emacs EXWM desktop environment. [WAS Re: Call for 1.2 installer testing.]

[Mathieu Othacehe]

Hey janneke,

> It works for me; I found Emacs EXWM missing however.  After zenny also
> asked about that this morning, I decided to create a patch.

Thanks for testing and for the patch!  I think it might be necessary to
add "emacs-exwm" to "installation-target-os-for-gui-tests" in (gnu tests
install) module.

To make sure that it's working fine you can run:

--8<---cut here---start->8---
make check-system TESTS="gui-installed-os gui-installed-os-encrypted
gui-installed-desktop-os-encrypted"
--8<---cut here---end--->8---

Otherwise, it looks fine.

Thanks,

Mathieu

Re: Shipping more installer images?

[Efraim Flashner]

On Mon, Oct 12, 2020 at 01:47:25PM +0200, Ludovic Courtès wrote:
> Hi,
> 
> Mathieu Othacehe  skribis:
> 
> >> I'm actually not really sure how one would use the installer on one of
> >> the boards. I think the bare-bones disk-images would be best; just
> >> download it and flash it onto the board or an SD card and edit
> >> /etc/config.scm to add your user and services. Or to boot up into the
> >> installer and overwrite itself.
> >
> > The CI is already building substitutes for two images
> > (hurd-barebones-qcow2-image and pine64-barebones-raw-image). We could
> > maybe release 1.2 version of those images.
> 
> Keep in mind that images use space at ftp.gnu.org and also take time to
> build (having CI up-to-date helps with that, but it doesn’t not
> eliminate build times due to the ‘update-guix-package’ dance that takes
> place during “make release”.)

We could also list out the commands for building the image and have
"community images" built and tested by people who actually have the
boards.

> Likewise, if we ship more images, we should update the “System
> Installation” section accordingly and be clear about what users can
> expect.

My slightly more featureful pine64plus image I built for myself came out
to 1.5 GiB and 291 MiB with bzip2. I don't know how much space the other
images or x86* images are.

We could also build and test them on a different schedule and upload
them at a later date as they're shown to be working.

> I guess all I’m saying is that we should not make such decisions lightly
> and be sure to examine all the consequences.
> 
> Thanks,
> Ludo’.

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Re: Shipping more installer images?

[Mathieu Othacehe]

Hey Ludo,

> So that’s 3 more 1 GiB installer images, right?  If we target Oct. 29th,
> how are we going to test them in the meantime?  How long will it take to
> build them, even assuming we build on an OverDrive?

I plan to provide compressed disk images for those boards so it's more
around 400MB. Anyway, compression patches are not available yet and I
don't even own one of those boards.

So, while we can provide latest images for those boards, having them in
a stable image will wait 1.3 I guess.

Thanks,

Mathieu

Re: Continuous integration - automatic EMAIL

[Ludovic Courtès]

Hi!

zimoun  skribis:

> If "guix weather -m" is improved, does it fill the gap?

I think it helps, but it’s not the same as getting a notification for a
commit you’ve just made.

> Because it is exactly doing what is required, isn't?  But it is not
> suitable for this purpose because of UI.  I mean:
>
> $ cat /tmp/spec.scm
> (specifications->manifest (list "emacs" "gcc-toolchain" "python-umap-learn"))
>
> $ guix weather -m /tmp/spec.scm
> computing 49 package derivations for x86_64-linux...
> looking for 66 store items on https://ci.guix.gnu.org...
> https://ci.guix.gnu.org
>   97.0% substitutes available (64 out of 66)
>   at least 340.7 MiB of nars (compressed)
>   534.1 MiB on disk (uncompressed)
>   0.001 seconds per request (0.0 seconds in total)
>   1,768.0 requests per second
>   'https://ci.guix.gnu.org/api/queue?nr=1000' returned 504 ("Gateway 
> Time-out")
>
> The information is here but I do not know which ones are fine and
> which ones are failing.  If an option like "--raw" (or "--plain" or
> "--exhaustive" or "--name-it" :-)) could display the status of all the
> 66 packages, then I think it would ease the detection of the
> regresion.  For example,

You can use ‘--display-missing’:

--8<---cut here---start->8---
$ guix weather --display-missing $(guix package -I |cut -f1)
computing 295 package derivations for x86_64-linux...
looking for 365 store items on https://ci.guix.gnu.org...
updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
https://ci.guix.gnu.org
  95.6% substitutes available (349 out of 365)
  at least 2,341.0 MiB of nars (compressed)
  3,865.8 MiB on disk (uncompressed)
  0.061 seconds per request (22.3 seconds in total)
  16.3 requests per second
  'https://ci.guix.gnu.org/api/queue?nr=1000' returned 504 ("Gateway Time-out")

Substitutes are missing for the following items:
  /gnu/store/0yjlganb3rw7jp1vw8hbpbbqf1myhmr2-sysstat-12.4.0
  /gnu/store/qnqny5gj6qrg5z1sa4wkcs6858mysvn4-emacs-strace-mode-0.0.2-1.6a69b4b
  /gnu/store/dnlli1380xpz0n939qhfn0kydm2sfpmc-emacs-gitpatch-0.5.1
  /gnu/store/h47f9hrg0d0dshqhk6s3nha0bzy0ihvd-emacs-recutils-1.8
  […]
--8<---cut here---end--->8---

But then that doesn’t allow you to distinguish between failed builds,
things that are not built yet, and “dependency-failed” builds.

‘guix publish’ could perhaps somehow expose failed builds.  And then we
could improve ‘guix weather’ to find about failed dependencies (sort of
like ‘-c’ does actually).

> then it is doable to have a shell script parsing this output and I can
> feed "git bisect".  Somehow.

Yeah, somehow.  :-)

Ludo’.

Re: raise(-1) succeeds for programs linked against libpthread

[Samuel Thibault]

Ludovic Courtès, le mar. 13 oct. 2020 15:41:37 +0200, a ecrit:
> ‘pthread_kill’ passes the signal number to ‘_hurd_raise_signal’, which
> assumes it is valid:
[...]
> I suppose that before calling ‘sigaddset’, it should check whether SIGNO
> is within bounds, along the lines of:
> 
>   if (signo < 2 || signo >= _NSIG)
> return EINVAL;
> 
> Does that make sense?

Probably, yes. Why excluding SIGHUP?

Samuel

Re: 32-bit builds on 64-bit hardware/VMs

[Ludovic Courtès]

Hi,

Andreas Enge  skribis:

> On Mon, Oct 12, 2020 at 01:52:18PM +0200, Ludovic Courtès wrote:
>> As a start, could you comment out in ‘machines-for-berlin.scm’ the
>> machines that need to be removed in order to not run 32-bit builds in
>> potentially buggy environments?
>
> already done by Danny in commit 81b5eab1a85196725895502637e2540a1535ce8b
> of the maintenance repository.

Great.

> However, that leaves only two machines for armhf. If we had an image
> for the Novena board, I could set up one or two more :) In any case,
> it will not be enough to keep up with the architecture.

Indeed, at this stage we’re almost giving up on ARMv7 substitutes.  :-/

If you feel like fiddling with the Novenas, I’m sure you could ‘guix
system init /’ them.  You need to be very careful about the bootloader
choice and all, but that should be feasible.

Thanks,
Ludo’.

Re: Shipping more installer images?

[Ludovic Courtès]

Hi,

Danny Milosavljevic  skribis:

> On Mon, 12 Oct 2020 13:47:25 +0200
> Ludovic Courtès  wrote:
>
>> Mathieu Othacehe  skribis:
>> 
>> Keep in mind that images use space at ftp.gnu.org and also take time to
>> build (having CI up-to-date helps with that, but it doesn’t not
>> eliminate build times due to the ‘update-guix-package’ dance that takes
>> place during “make release”.)
>> 
>> Likewise, if we ship more images, we should update the “System
>> Installation” section accordingly and be clear about what users can
>> expect.
>> 
>> I guess all I’m saying is that we should not make such decisions lightly
>> and be sure to examine all the consequences.
>
> I agree.
>
> IMO there are only very few RYF-worthy ARM devices--and we should support
> at least those, if we support any ARM devices at all.  That includes
> providing images for those few (at least A20-EOMA68, A?0*Olinuxino*, and
> Novena).

So that’s 3 more 1 GiB installer images, right?  If we target Oct. 29th,
how are we going to test them in the meantime?  How long will it take to
build them, even assuming we build on an OverDrive?

I don’t want to spoil the party, I think it’d be great to better support
those devices, but it seems to me that there’s still quite a lot to be
done before we can offer that with reasonable confidence.

Thanks,
Ludo’.

Re: File search progress: database review and question on triggers

[Ludovic Courtès]

Pierre Neidhardt  skribis:

> Ludovic Courtès  writes:
>
>> I would lean towards keeping it separate, so that it’s an optional
>> feature (given that it relies on downloading an external database).
>
> I was leaning towards downloading the database with "guix pull", so that
> the "filesearch" subcommand would not download anything.

Like substitutes, it should be an optional feature IMO, which means we
need to keep clear boundaries.

There’s also the question of whether we should have a system-wide
database so that each user doesn’t have to download it, especially if
it’s relatively big.

Apologies for throwing more questions than answers into the mix.  :-)

Ludo’.

Re: File search progress: database review and question on triggers

[Ludovic Courtès]

Hi Pierre,

Pierre Neidhardt  skribis:

> Ludovic Courtès  writes:

[...]

>> It would be nice to see whether/how this could be integrated with
>> third-party channels.  Of course it’s not a priority, but while
>> designing this feature, we should keep in mind that we might want
>> third-party channel authors to be able to offer such a database for
>> their packages.
>
> Wouldn't it work automatically for any substitute server?

“Something” needs to build the file-to-package database (which is what
you’re working on), and then there needs to be a way for users to fetch
that database.  This is all orthogonal to substitutes, as I see it,
which is why I think we need to think about integrating it maybe with
‘guix publish’ on the server side and (guix channels) on the client
side.

>>> - Find a way to garbage-collect the database(s).  My intuition is that
>>>   we should have 1 database per Guix checkout and when we `guix gc` a
>>>   Guix checkout we collect the corresponding database.
>>
>> If we download a fresh database every time, we might as well simply
>> overwrite the one we have?
>
> But then we would miss the database when switching Guix generation.

Ah got it; having a database known to correspond to a specific commit is
even better.

However, note that it could take time for the server to provide the
complete database for a commit (the time for as many packages as
possible to be built), so clients may want to refresh it anyway, or even
perhaps to use an older database.

Thanks,
Ludo’.

raise(-1) succeeds for programs linked against libpthread

[Ludovic Courtès]

Hi!

(Cc: bug-hurd.)

Jan Nieuwenhuizen  skribis:

>>> #include 
>>>
>>> int
>>> main (void)
>>> {
>>>   if (!raise (-1))
>>> return 1;
>>>   
>>>   return 0;
>>> }
>>
>> I don’t know if it’s relevant here, but you should always use ‘-pthread’
>> both at compile time and link time:
>>
>>   gcc raise.c -pthread
>>
>> That typically defines a few macros that may or may not have an effect
>> on the code at hand.
>
> Ah...right.  Makes no difference, though:
>
> root@childhurd ~# guix environment --bootstrap --ad-hoc gcc-toolchain@7
> root@childhurd ~ [env]# gcc raise.c
> root@childhurd ~ [env]# ./a.out
> root@childhurd ~ [env]# echo $?
> 0
> root@childhurd ~ [env]# gcc raise.c -pthread
> root@childhurd ~ [env]# ./a.out
> User defined signal 2

Interesting!  In the second case, we’re using ‘__pthread_kill’ from
‘pt-kill.c’ (instead of ‘kill’).

The expected behavior is that ‘raise’ should return non-zero and EINVAL.

‘pthread_kill’ passes the signal number to ‘_hurd_raise_signal’, which
assumes it is valid:

--8<---cut here---start->8---
int
_hurd_raise_signal (struct hurd_sigstate *ss,
int signo, const struct hurd_signal_detail *detail)
{
  if (ss == NULL)
{
  ss = _hurd_self_sigstate ();
  __spin_lock (>lock);
}

  /* Mark SIGNO as pending to be delivered.  */
  __sigaddset (>pending, signo);
  ss->pending_data[signo] = *detail;
--8<---cut here---end--->8---

I suppose that before calling ‘sigaddset’, it should check whether SIGNO
is within bounds, along the lines of:

  if (signo < 2 || signo >= _NSIG)
return EINVAL;

Does that make sense?

Thanks,
Ludo’.

Re: bug#24066: icecat "mailto" handler does not work - and cannot be reconfigured by user

[Maxim Cournoyer]

Hello Danny,

Danny Milosavljevic  writes:

[...]

> Checking the application preferences of icecat, it only gives "always
> ask" (note: it doesn't ask) and not an application for "mailto". (in
> GuixSD)

Testing in latest IceCat, there's a 'Use other...' entry in the mailto
applications configuration.  I also saw 'Emacs' in the list of potential
applications to open mailto URIs, tried it and it opened Emacs.

Does that work for you?

To get the applications recognized as supporting this URI scheme, they
must provide a .desktop file which mentions support for it, for example
via a MimeType=x-scheme-handler entry:

--8<---cut here---start->8---
$ grep -rin 'x-scheme-handler' $(guix build weechat)
/gnu/store/...-weechat-2.9/share/applications/weechat.desktop:17:MimeType=x-scheme-handler/irc;x-scheme-handler/ircs;--8<---cut
 here---end--->8---

This information gets compiled into a MIME database by a profile hook
under:

--8<---cut here---start->8---
$ grep 'x-scheme-handler/ircs' 
~/.guix-profile/share/applications/mimeinfo.cache 
x-scheme-handler/ircs=weechat.desktop;
--8<---cut here---end--->8---

And Icecat picks its up to show ircs:// URIs and shows the application
as registered for this type in its Applications settings view.

Maxim

Re: Translating the web site

[Ludovic Courtès]

PS: Please avoid top-posting.  :-)

Ludo’.

Sure, I don’t mind translating everything through Weblate eventually.
However, in the short term, could we simply push the web site POT files
to that repo on Savannah, so we can start getting translations for it?

It would be great to have more web site translations done by the time of
the release.

Julien Lepiller  skribis:

> Yes, I think the goal is to translate everything through weblate, right?
>
> Le 12 octobre 2020 08:29:32 GMT-04:00, "Ludovic Courtès"  a 
> écrit :
>>Hi again,
>>
>>Julien Lepiller  skribis:
>>
>>> Le 5 octobre 2020 08:17:59 GMT-04:00, "Ludovic Courtès"
>> a écrit :
>>
>>[...]
>>
My understanding is that we need:

  1. A public Git repo with all the POT files.  We can file a support
 request at Savannah to get that under the ‘guix’ project.
>>>
>>> Done, they're waiting for the copyright fixes.
>>
>>Something I must have misunderstood: this repo will contain all the POT
>>files, not just those for the web site?
>>
>>Ludo’.

Re: Problem bootstrapping Guix - "make update-guix-package" result: no code for module (gcrypt hash)

[Ludovic Courtès]

Hi Danny,

Danny Milosavljevic  skribis:

> I'm doing a project for Heads where we are trying to switch over their build
> system to something that makes their builds more reproducible (for example
> Guix).
>
> They are using github and gitlab test runners for a lot of things, so one of
> the ways we are trying to do continuous integration is to do the following:
>
> (1) Have guix-the-package-manager be built and published on
> repository.gitlab.com.  It eventually does "./pre-inst-env guix pack guix"
> and then puts the result into a new docker container.  I can't see how to do 
> that
> after a guix pull.  Note that I don't want to also carry garbage (this entire
> thing has to be verified for security eventually, so...).  Currently, guix
> is being bootstrapped from Alpine, and I don't want Alpine to remain in there.

Why not just run “guix pack guix” with a “guix pull”-provided Guix?
You’d benefit from transparency and provenance tracking, the reduced
binary seeds, etc., which is very different from what you get by
building on top of Alpine.

If you need a specific Guix commit, you can also run:

  guix pack guix \
--with-commit=guix=a2ed00f79fd5bf69c6cca3fa7bdc62726bf848fa \
--with-git-url=guix=https://git.savannah.gnu.org/git/guix.git

You can still get test failures if there’s a problem on that commit, as
we’ve seen before, but apart from that it looks like what you need no?

(The ‘--with-git-url’ is only necessary because the default URL uses the
“dumb” transparent, which libgit2 apparently dislikes.)

> (2) Use the result in order to build boards using tiny Dockerfiles
> which would just say
>
>   FROM repository.gitlab.com/guix-on-docker
>   RUN guix build heads-kgpe-d16
>
> and throw away the derivation (or publish it, too?)--but keep the log file
> and exit status.

Then again, why even go through Docker?  You could just as well in one
go do:

  guix time-machine --commit=a2ed00f79fd5bf69c6cca3fa7bdc62726bf848fa -- \
build heads-kgpe-d16

I’ve used Guix with GitLab-CI for instance, and it makes absolutely no
sense to me to resort to Docker if you already have Guix running.

> Note that (1) should pin a specific Guix commit for a long time since Heads
> does not want to build on a moving target since they do hash verification
> on bootup, and firmware is hard to keep working (i.e. someone has to
> manually verify, on real hardware, whether stuff still works after an
> update of the toolchain).  And Heads basically is ONLY security-relevant
> stuff.

An additional reason to avoid hopping through Alpine…

HTH!

Ludo’.

Re: Guix Deploy Hacking

[Julien Lepiller]

Le 12 octobre 2020 22:08:44 GMT-04:00, Kurt I  a écrit 
:
>Greetings,
>
>I am attempting to use "Guix Deploy" as a replacement for Norton
>Ghost/SCCM, imaging type software.
>
>There are 2 tasks I'm working on:
>
>1) Using deploy to update a machine
>   - I don't understand the point of pushing packages to a system
>that disappear if you do a "guix system reconfigure" on that machine.
>
>To deal with this I have this code in my deploy file:
>
>;; This will locate where the system config file is
>(define this-file
>  (local-file (basename (assoc-ref (current-source-location) 'filename)
>   "config.scm")))
>
>;; This replaces or creates a new system config file
>   (simple-service 'config-file etc-service-type
>   `(("lr.scm" ,this-file)))
>
>Perhaps an argument to "Guix Deploy" to optionally save the file you
>are pushing on the remote machine could be added?

This was not the case with 1.1.0, but now we register the file that generated 
your system as /run/current-system/config.scm, with provenance information.

Re: Outreachy Applicant: An Introduction

[Magali Lemes]

Hey,
I'm using Ubuntu 20.04.1 LTS. I must say I've never used emacs before, so
I'll try to get the hang of it.
Sharing my progress: I decided to package the arduino IDE, but it turned out
way harder than I expected, due to its many dependencies. I ended up not
doing it, but it was a good experience because I could learn about some
functions in Scheme - chdir, for example -, some of the phases of
building a package - like unpacking, configuring and building - and I could
also interact with the community, asking for help, via IRC, which is a
very new thing for me.
As for today, I will continue trying to package something. I'll probably
follow
your previous advice and begin with a R package. It seems easier, so
hopefully
I'll succeed.

Cheers,
Magali.

Em seg., 12 de out. de 2020 às 12:06, zimoun 
escreveu:

> Hi,
>
> On Mon, 12 Oct 2020 at 13:00, Magali Lemes 
> wrote:
>
> > Guix was fairly easy to install, I used the shell script to do that.
>
> Which distribution do you use?
>
> > I installed emacs using Guix and it worked as expected.
>
> Nice!
> Personally, I manage the Emacs packages with Guix via a manifest.scm
> file.  And in a separate profile.  My conf [1] is far from perfect but
> if you need inspiration. :-)
>
> 1: 
>
> > I'll begin by trying to package something. So, I'll go through the links
> you sent
> > and see how that goes.
>
> Cool!
> Do not hesitate to ask on help-guix or #guix if you encounter issues
> on your path.  And feel free to send your progress, success or
> failure.
>
>
> All the best,
> simon
>

Re: Data Services: use cases

[Pierre Neidhardt]

Hi!

Sorry if I'm stating the obvious, but ideally it'd be nice if the
interface would be so straightforward it didn't need any instructions to
use :)

In particular, the "Version From To" table is hard to grasp to a
newcomer.

During the Guix Days we talked about how to make it a bit more
approachable.  From what I recall:

- Maybe make the timeline bars more visible.

- The timeline is not usable and does not convey much information beside
  an approximate lifespan of versions, which I'm not sure many users
  need.  Consider removing it, or displaying it in a separate graph?

  Ultimately, we need a list of versions with their Guix builds.  

- "From" and "To" should probably be renamed "From Guix build" and "To
  Guix build" respectively.

- (More information) should be renamed to something like "Package
  information".

There are probably a few more adjustments we could make.  Any idea?

Cheers!

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


signature.asc
Description: PGP signature

Guix Deploy Hacking

[Kurt I]

Greetings,

I am attempting to use "Guix Deploy" as a replacement for Norton
Ghost/SCCM, imaging type software.

There are 2 tasks I'm working on:

1) Using deploy to update a machine
- I don't understand the point of pushing packages to a system
that disappear if you do a "guix system reconfigure" on that machine.

To deal with this I have this code in my deploy file:

;; This will locate where the system config file is
(define this-file
  (local-file (basename (assoc-ref (current-source-location) 'filename)
"config.scm")))

;; This replaces or creates a new system config file
(simple-service 'config-file etc-service-type
`(("lr.scm" ,this-file)))

Perhaps an argument to "Guix Deploy" to optionally save the file you
are pushing on the remote machine could be added?

2) I am trying to deploy a machine that is running the guix installer
in cli mode off the USB key. I have done the following steps:

1) ifconfig  up
2) passwd root 
3) guix install guile-ssh
4) herd start ssh-daemon
5) I then have a script I run on the target machine:

umount -a
parted /dev/sda set 1 esp on
mkfs.fat -F32 -n GUIX-BOOT /dev/sda1
mkswap --label=guix-swap /dev/sda2
swapon LABEL=guix-swap
mkfs.ext4 -L guix-root /dev/sda3 

mount --label=guix-root /mnt
mkdir -p /mnt/etc
mkdir -p /mnt/etc/guix/
mkdir -p /mnt/boot/efi
mount --label=GUIX-BOOT /mnt/boot/efi

sudo guix archive --authorize < key-publish.pub
mkdir -p ~/.ssh/
cat key-ssh.pub > ~/.ssh/authorized_keys

herd start cow-store /mnt
echo "Ready for deploy!"

6) I then start the deploy process with "Guix Deploy" and it works for
some of the process:

guix deploy: deploying to lr...
guix deploy: sending 9 store items (5 MiB) to '10.0.0.6'...
guix deploy: sending 805 store items (4,269 MiB) to '10.0.0.6'...

once it's done the big file transfer, I run into this:

guix deploy: error: failed to deploy lr: build daemon handshake failed

Is this an error I can get around or fix? or is "Guix Deploy" not meant
for using on a machine that hasn't done "Guix System Init" yet?

Thank you,
Kurt

Re: Call for 1.2 installer testing.

[Brendan Tildesley]

Actually never mind, you did mention it underneath that, I should have 
kept reading!!

Re: Call for 1.2 installer testing.

[Brendan Tildesley]

On 12/10/20 6:32 am, pelzflorian (Florian Pelz) wrote:

On Sun, Oct 11, 2020 at 05:23:30PM +1100, Brendan Tildesley wrote:

Hi, I went through the installer looking for anything negative I could say
about it :) hope there is something helpful here:

Thank you for testing!



Unrelated driver bug: installer was just a black screen until I rebooted
with nomodeset:  https://paste.debian.net/1166581/
Even with nomodeset, I get an error about no UMS supported in radeon, but it
doesn't stop anything.

This black screen regression should be “fixed” now (commit
34d436a4082b5c5f23b00e13eb8e5a92d957d704) by passing a kernel argument
“modprobe.blacklist=radeon” which disables the radeon driver.


I think you copy-pasted the wrong link in to that commit. it links to a 
thread about the translation stuff i mentioned below, not about the 
radeon driver.


- https://lists.gnu.org/archive/html/guix-devel/2019-03/msg00441.html