Fwd: Greens/EFA internship

[Alex Sassmannshausen]

Hello,

Sorry for cross-posting, and I hope this is an appropriate use of the mailing
lists.

As part of my work I have the exciting opportunity to organise a paid
internship. The details are in the email below.

Please feel free to advertise this far and wide, and on socials. The deadline 
is fairly short
unfortunately.

Best wishes,

Alex


SASSMANNSHAUSEN Alexander-Carlos 
writes:

> The Greens/EFA in the European Parliament are looking for a paid intern to 
> work with the IT Project Manager of the group.
>
> The intern will work in the office of the project manager and data analyst of
> the group. The project manager’s office places a strong emphasis on practical 
> IT
> skills as well as project management. In addition the office is committed to
> using Free Software in its toolchain where possible.
>
> Potential tasks for the intern might be:
>
> *   Free Software community participation in the form of triage, patching, 
> documentation writing or other forms of engagement;
> *   Internal toolchain development, debugging or maintenance, using Guile 
> Scheme, Guix, PHP (Drupal / CiviCRM), bash, postgres, sqlite and similar 
> technologies
> *   VPS server administration, including software deployment, CI, system 
> upgrades, network management, using Hetzner Cloud provided VPSs
> *   Project management activities such as liaising with end-users, organising 
> user testing and QA sessions, working with contractors to resolve issues.
> *   Some data entry work, though where possible these tasks should be 
> automated using APIs
>
> The particular tasks the intern will be performing will depend strongly on 
> the intern’s particular interests.
>
> We welcome applications from anyone excited about Free Software  green 
> values such as inclusion or diversity. We particularly welcome applications 
> from underrepresented people in politics or tech.
>
> ## What we can offer you
>
> The aim of this internship is to provide a space for a person who is excited
> about working in a progressive political environment at the European level to
> further the use of Free Software for the green group. You will have the
> opportunity to:
>
> *   work in a large multilingual organisation
> *   participate in Free Software communities in a self-directed way
> *   flex your tech muscles, or to develop them in a new direction, in a 
> supportive environment
> *   work with a project manager to develop project management skills
> *   develop personal IT practices that minimise service disruption and 
> maximise reproducability of systems
>
> The precise nature of the work you will carry out will be very much tailored 
> to the interests and skill level of the successful applicant.
>
> ## Practical matters
>
> *   The internship will take place in Brussels, in the European parliament 
> buildings
> *   The compensation for the position is 1500 EUR per month
> *   The duration of the internship is 5 months
> *   The application process will be through the standard internship program 
> of the group; this is the first time we are recruiting an intern in this 
> office, so the recruitment process is not adapted to this position
> *   Please follow the instructions detailed at 
> [<https://www.greens-efa.eu/en/get-involved/work-with-us>](<https://www.greens-efa.eu/en/get-involved/work-with-us>)
> *   In the webform used for applications, please select Central 
> Secretariat as your first choice for the department in which you would 
> like to work
> *   Do feel free to mention any particular experience you have of working 
> with or as part of Free Software communities
>
> Alex Sassmannshausen
>
>
> www.greens-efa.eu
>
>
>
>
> Alex Sassmannshausen (he/him)
> IT Project Manager
> alexander.sassmannshau...@europarl.europa.eu
> Phone: + 32 228 32860
>
> PHS02C027
> Rue Wiertz 60
> B-1047 Bruxelles

Re: New backward incompatible version of Guile Config

[Alex Sassmannshausen]

Hi Ludo,

Hope you're good :-)

Ludovic Courtès  writes:

> Hi Alex!
>
> Alex Sassmannshausen  skribis:
>
>> To this end, in the attached patch, I add a new variable for 0.5. My
>> intention is to have 0.4.2 and 0.5 coexist for a while and then to
>> switch fully to 0.5 in due course.
>>
>>
>> Is this an acceptable way of doing a gradual transition to a backwards
>> incompatible version of the library?
>
> Definitely!  We’ve done that in the past for Guile-JSON, among others.
>
> Should we commit it on your behalf?

Yes indeed, please go ahead! Cheers :)

Alex

>
> Thanks,
> Ludo’.



signature.asc
Description: PGP signature

New backward incompatible version of Guile Config

[Alex Sassmannshausen]

Hello,

I'm in the process of releasing guile-config 0.5, which unfortunately is
backward incompatible in some ways.

As a result I want to give developers who are using it a chance to
upgrade gradually.

To this end, in the attached patch, I add a new variable for 0.5. My
intention is to have 0.4.2 and 0.5 coexist for a while and then to
switch fully to 0.5 in due course.


Is this an acceptable way of doing a gradual transition to a backwards
incompatible version of the library?

Best wishes,

Alex

From fadba5c1c27d96b8e49dcf987eb3c09a2bbb0776 Mon Sep 17 00:00:00 2001
From: Alex Sassmannshausen 
Date: Wed, 17 Feb 2021 16:48:39 +0100
Subject: [PATCH] gnu: Add guile-config-0.5.

* gnu/packages/guile-xyz.scm (guile-config-0.5): New variable.
---
 gnu/packages/guile-xyz.scm | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/gnu/packages/guile-xyz.scm b/gnu/packages/guile-xyz.scm
index 984c2b1109..b62dbe20d5 100644
--- a/gnu/packages/guile-xyz.scm
+++ b/gnu/packages/guile-xyz.scm
@@ -1582,6 +1582,21 @@ above command-line parameters.")
 (define-public guile3.0-config
   (deprecated-package "guile3.0-config" guile-config))
 
+(define-public guile-config-0.5
+  (package
+(inherit guile-config)
+(name "guile-config-0.5")
+(version "0.5.0")
+(source
+ (origin
+   (method git-fetch)
+   (uri (git-reference
+ (url "https://gitlab.com/a-sassmannshausen/guile-config;)
+ (commit version)))
+   (file-name (git-file-name name version))
+   (sha256 (base32
+"1xrl8bdcvvvbsrms0s3pp3d698541fv5b5kyy1z2kwli7akvdiph"))
+
 (define-public guile-hall
   (package
 (name "guile-hall")
-- 
2.28.0



signature.asc
Description: PGP signature

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: Running service migrations during upgrades

[Alex Sassmannshausen]

Hi Marius,

Your work and thoughts on the SQL upgrades are very interesting.

After the last FOSDEM I wrote up some thoughts about service states and
their backups that you may find interesting.

https://lists.nongnu.org/archive/html/guix-devel/2020-02/msg2.html

Unfortunately I have not found the time to work on any of this
since. But feel free to steal freely any content that proves useful!

Best wishes,

Alex

Marius Bakke  writes:

> Hello Guix,
>
> Some services require administrator interaction when they are updated.
> The most prominent examples here are MySQL/MariaDB and PostgresQL.
>
> For the former, running 'mysql_upgrade' in-place is generally sufficient
> and fairly safe.
>
> For the latter, the procedure is more involved, and requires making a
> full backup, as well as access to the old _and_ new PostgreSQL
> packages.
>
> There is a patch to update MariaDB here:
>
>   https://issues.guix.gnu.org/43355
>
> Users of mysql-service-type will need to run 'mysql_upgrade' afterwards.
>
> I have been considering adding an AUTO-UPGRADE? parameter of
> mysql-service-type that runs 'mysql_upgrade' as part of the activation
> script.
>
> Another approach is adding a 'herd upgrade' Shepherd action along with a
> news entry describing what to do.  Of course it is possible to do both,
> having 'auto-upgrade?' _and_ a Shepherd action for manual upgrades.
>
> Thoughts?
>
> While that works for MariaDB, I'm not sure what to do about Postgres.
> For those unfamiliar, the procedure for upgrading from PostgreSQL 10
> (current default) to 11 (available in Guix) is roughly:
>
>   sudo cp -a /var/lib/postgresql/data /var/lib/postgresql/data10
>   sudo -u postgres $(guix build postgresql)/bin/pg_upgrade \
> --old-bindir=$(guix build postgresql@10)/bin \
> --new-bindir=$(guix build postgresql)/bin \
> --old-datadir=/var/lib/postgresql/data10 \
> --new-datadir=/var/lib/postgresql/data
>
> In order to automate it, we need to somehow preserve the "previous"
> version of PostgreSQL so that we can reach it when the major version
> changes.  Or add an 'upgrade-from' parameter to
> postgresql-service-type.
>
> How do other distros deal with this?
>
> On a related note, a 'herd backup' action might be a prerequisite for
> doing such potentially dangerous operations...
>
> I will try to add a 'mysql_upgrade' pass to 'mysql-service-type' in time
> for the MariaDB upgrade, but tips regarding backups, potential pitfalls,
> and especially Postgres welcome.
>
> PS: I'm mostly busy for some time still, but can be reached on #guix or
> by private email if you want my feedback on something.  :-)



signature.asc
Description: PGP signature

Re: generate commit messages for package updates

[Alex Sassmannshausen]

Hi Ricardo,

Just used your committer tool for the first time and it's bloody lovely.

Thank you for sharing it :-)

Alex

Ricardo Wurmus  writes:

> Hi Guix,
>
> I’m currently working on upgrading all Bioconductor packages to the 3.11
> release.  The hardest work here is to write commit messages for the 200+
> packages that have changed.  Even with the “update” yasnippet and magit
> this takes a very long time.
>
> I wrote a little tool to reduce the amount of time needed to create
> commits.  It is not fully automatic yet as it requires my input to stage
> hunks, but the commit messages it produces take all input changes into
> account, which is something the “update” yasnippet does not do.
>
> After “guix refresh -t bioconductor -u”, manually verifying and
> implementing the suggested changes, and building all packages, I run
> “git add -p” to stage hunks that belong to the same package definition.
> Then I run the attached tool to make a commit:
>
> ./committer.scm | git commit -F -
>
> The tool works by looking at the unified diff in the staging area and
> generating two S-expressions corresponding to the original package
> definition and the changed package definition, respectively.  It then
> looks at the inputs, propagated-inputs, and native-inputs fields and
> generates a GNU ChangeLog-style commit message describing the changes.
>
> Here’s an example diff:
>
> --8<---cut here---start->8---
> modified   gnu/packages/bioconductor.scm
> @@ -2701,29 +2701,32 @@ gene and isoform level using RNA-seq data")
>  (define-public r-karyoploter
>(package
>  (name "r-karyoploter")
> -(version "1.12.4")
> +(version "1.14.0")
>  (source (origin
>(method url-fetch)
>(uri (bioconductor-uri "karyoploteR" version))
>(sha256
> (base32
> -"03jmfgmw35hrgn3pc5lq6pblzhfx9fp4l6dx50rp303lr7kjxp9v"
> +"0h0gk4xd95k5phy6qcsv7j931d7gk3p24i2fg4mz5dsk110lpifs"
>  (build-system r-build-system)
>  (propagated-inputs
> - `(("r-regioner" ,r-regioner)
> + `(("r-annotationdbi" ,r-annotationdbi)
> +   ("r-bamsignals" ,r-bamsignals)
> +   ("r-bezier" ,r-bezier)
> +   ("r-biovizbase" ,r-biovizbase)
> +   ("r-digest" ,r-digest)
> +   ("r-genomeinfodb" ,r-genomeinfodb)
> +   ("r-genomicfeatures" ,r-genomicfeatures)
> ("r-genomicranges" ,r-genomicranges)
> ("r-iranges" ,r-iranges)
> -   ("r-rsamtools" ,r-rsamtools)
> ("r-memoise" ,r-memoise)
> +   ("r-regioner" ,r-regioner)
> +   ("r-rsamtools" ,r-rsamtools)
> ("r-rtracklayer" ,r-rtracklayer)
> -   ("r-genomeinfodb" ,r-genomeinfodb)
> ("r-s4vectors" ,r-s4vectors)
> -   ("r-biovizbase" ,r-biovizbase)
> -   ("r-digest" ,r-digest)
> -   ("r-bezier" ,r-bezier)
> -   ("r-bamsignals" ,r-bamsignals)
> -   ("r-annotationdbi" ,r-annotationdbi)
> ("r-variantannotation" ,r-variantannotation)))
> +(native-inputs
> + `(("r-knitr" ,r-knitr)))
>  (home-page "https://bioconductor.org/packages/karyoploteR/;)
>  (synopsis "Plot customizable linear genomes displaying arbitrary data")
>  (description "This package creates karyotype plots of arbitrary genomes 
> and
> --8<---cut here---end--->8---
>
> …and this is the generated commit message:
>
> --8<---cut here---start->8---
> gnu: r-karyoploter: Update to 1.14.0.
>
> * gnu/packages/bioconductor.scm (r-karyoploter): Update to 1.14.0.
> [propagated-inputs]: Add r-genomicfeatures.
> [native-inputs]: Add r-knitr.
> --8<---cut here---end--->8---
>
> Obviously, this can be improved by avoiding the staging area and
> operating on all hunks in all selected files, so that more than one
> commit can be made at a time.  But I thought I’d share this hack anyway,
> crude as it is.

Re: 1.1.0rc1 available for test!

[alex sassmannshausen]

Heya

On Sat, 11 Apr 2020, 00:38 Ludovic Courtès,  wrote:

> Hi Alex,
>
> Alex Sassmannshausen  skribis:
>
> > After successfully completing system setup from the ISO using that
> > selection, rebooting the system launches GDM OK.  Signing in to GDM
> > however causes the system to loop back to GDM, instead of starting a
> > ratpoison session.  It is not clear to me what causes the issue, but I'm
> > happy to help debug if someone can provide me with pointers on doing so.
> >
> > Intuitively, I would hazard a guess that the initialisation of ratpoison
> > fails and the session is aborted, at which point GDM is restarted.
>
> Isn’t it just that GDM defaults to GNOME (not ratpoison), but since
> GNOME isn’t available, it loops back?
>
> What if you click on the small gear and select ratpoison?
>

You are 100% correct! Thanks for that pointer - I hadn't considered it
would still default to gnome! :)

Cheers,

Alex



> Thanks for your feedback!
>
> Ludo’.
>

Re: 1.1.0rc1 available for test!

[Alex Sassmannshausen]

Heya

Ludovic Courtès  writes:

> Hi!
>
> Mathieu Othacehe  skribis:
>
>>> * Esperanto language/layout crashes the installer.
>>
>> Fixed by 1a24df44347629cd67821d672edad7636404f293 on master.
>>
>> Ludo, you may want to cherry-pick it to 1.1.0 branch :)
>
> Done!
>
> Thanks for testing & fixing, comrades!
>
> Ludo’.

This is amazing — really cool to see how quickly this was resolved!  Now
to learning Esperanto by using it on my spare computer… ;-)

Alex

Re: 1.1.0rc1 available for test!

[Alex Sassmannshausen]

Hello,

A minor useability issue:

At the end of installation, a prompt suggests installation is complete
and that the system is ready for reboot.

However, it suggests one can remove the installation medium before
hitting return to restart.

For me at least, removing the pendrive prior to reboot caused the system
to hang.  Only a hard power off got me out of that hang.  The system
seems to work fine aftarwards.

Perhaps the message could be improved by reversing the order of
restarting and removing boot media?

Best wishes,

Alex

Ludovic Courtès  writes:

> Hello Guix!
>
> I’ve run “make release” from the new ‘version-1.1.0’ branch and uploaded
> the result:
>
>   https://web.fdn.fr/~lcourtes/software/guix/1.1.0rc1
>
> Alternately (and preferably), you can get it over IPFS:
>
>   guix install ipfs
>   ipfs daemon &
>   ipfs ls QmXpSUnppJgf23LpaKJzRWJbQxwEfybJy9VxF79iTLSXqa
>   ipfs get …
>
> All the files are signed with my key, also used to sign this message.
>
> Please test things as much as you can, be it the binary installation
> tarball on a “foreign” distro or the ISO image.  Once you’ve downloaded,
> just follow the same instructions as before (if you want to use
> ‘guix-install.sh’, you’ll have to adjust it to use the right tarball):
>
>   https://guix.gnu.org/download/
>
> If you encounter an issue, please report it to bug-g...@gnu.org,
> explaining what you did and what you observed.
>
> Notice that there’s no i686-linux installation image and no VM image,
> because of  but i can provide
> those later.
>
> If everything goes well, we can publish the release on Monday, 13th,
> with few or no changes beyond translation updates on the ‘version-1.1.0’
> branch.
>
> Thanks in advance!  :-)
>
> Ludo’.

Re: 1.1.0rc1 available for test!

[Alex Sassmannshausen]

Hello!

I have spotted a further issue — though I'm not sure whether this thread
is the right place to report it:

One is able to select ratpoison as the only option in the desktop
environment options in the installer.

After successfully completing system setup from the ISO using that
selection, rebooting the system launches GDM OK.  Signing in to GDM
however causes the system to loop back to GDM, instead of starting a
ratpoison session.  It is not clear to me what causes the issue, but I'm
happy to help debug if someone can provide me with pointers on doing so.

Intuitively, I would hazard a guess that the initialisation of ratpoison
fails and the session is aborted, at which point GDM is restarted.

Best wishes,

Alex

Ludovic Courtès  writes:

> Hello Guix!
>
> I’ve run “make release” from the new ‘version-1.1.0’ branch and uploaded
> the result:
>
>   https://web.fdn.fr/~lcourtes/software/guix/1.1.0rc1
>
> Alternately (and preferably), you can get it over IPFS:
>
>   guix install ipfs
>   ipfs daemon &
>   ipfs ls QmXpSUnppJgf23LpaKJzRWJbQxwEfybJy9VxF79iTLSXqa
>   ipfs get …
>
> All the files are signed with my key, also used to sign this message.
>
> Please test things as much as you can, be it the binary installation
> tarball on a “foreign” distro or the ISO image.  Once you’ve downloaded,
> just follow the same instructions as before (if you want to use
> ‘guix-install.sh’, you’ll have to adjust it to use the right tarball):
>
>   https://guix.gnu.org/download/
>
> If you encounter an issue, please report it to bug-g...@gnu.org,
> explaining what you did and what you observed.
>
> Notice that there’s no i686-linux installation image and no VM image,
> because of  but i can provide
> those later.
>
> If everything goes well, we can publish the release on Monday, 13th,
> with few or no changes beyond translation updates on the ‘version-1.1.0’
> branch.
>
> Thanks in advance!  :-)
>
> Ludo’.

Re: 1.1.0rc1 available for test!

[Alex Sassmannshausen]

Great, thank you for that summary, I think that is right.

I've noticed a further (small?) error:

On installation completion an error flashes up.  When I checked
/var/log/debug, the message is:
…localhost shepherd[1]: system-error("rmdir" "~A" ("Directory not empty") (39))

Best wishes,

Alex


Mathieu Othacehe  writes:

>> As the system language & locale rather than 
>> - Esperanto
>
> I can reproduce it in QEMU. So there are two issues here:
>
> * Esperanto language/layout crashes the installer.
>
> * When the installer crashes, `umount-cow-store' is not called and the next
> installation is bound to fail because some mounted partitions are still 
> around.
>
> Maybe we need to call this procedure at installer start, in case the
> previous installation has crashed.
>
> Thanks for reporting!
>
> Mathieu

Re: 1.1.0rc1 available for test!

[Alex Sassmannshausen]

Hi Mathieu,

Thanks for getting back to me!

Mathieu Othacehe  writes:

> Hello Alex,
>
> Thanks for your feedback!
>
>> Then the screen flashes back to the beginning of the installer.  Running
>> through the process again results in the disk drive not being available
>> for partitioning.
>
> Are you running the installer on a VM or on real hardware?

Real hardware.

> Could you try the following steps:
>
> * Run the installation until it fails and restart.
> * Press Ctrl-Alt-2.
> * Type "sendkey ctrl-alt-f3".
> * Then press Ctrl-Alt-1 and Enter.
> * Check if there is a /tmp/last-installer-error file and, if yes, report
> its content.

This I could not do: Ctrl-Alt-2 doesn't do anything, but I imagine you
meant Ctrl-Alt-f2?  That takes me to the manual.

However, once the installer reloads, I can hit Ctrl-Alt-f3 and Enter to
get to a prompt.

There is no /tmp/last-installer-error file :-(

I did check /var/log/debug.  There I can trace the configuration
process.

After "running form # ("Configuration file") with 0
clients" I get:
…Service cow-store has been started.
…Service cow-store has been stopped.
…Service guix-daemon has been stopped.
…Service guix-daemon has been started.
…Umounted /remove successfully.
…unmounting "/mnt"
…closing LUKS entry "cryptroot"
…running step 'locale'

The last presumably is the installer restarting.

Hth,

Alex

>
> Thanks,
>
> Mathieu

Re: 1.1.0rc1 available for test!

[Alex Sassmannshausen]

I have been able to avoid this error by selecting:
- English
- United Kingdom

As the system language & locale rather than 
- Esperanto

which I had previously selected.

I tried a great number of combinations of configurations, and this seems
to have been the one thing that reliably crashed (when choosing
Esperanto) or fixed (when Choosing English/UK).

After this the installation seems to be going swimmingly.

Hth,

Alex


Alex Sassmannshausen  writes:

> Hello,
>
> Running the graphical installer from the installation image hosted
> through IPFS, I can report the following experience:
>
> The guidance, keyboard configuration & partitioning works well.  In fact
> all goes charmingly until the stage where the sysconf is shown.  That
> looks correct too.
>
> Hitting continue at that point switches to a terminal wher I briefly see
> cow-store being started.
>
> Then the screen flashes back to the beginning of the installer.  Running
> through the process again results in the disk drive not being available
> for partitioning.
>
> I cannot see any error messages in the brief time I see the terminal and
> am not sure how to get an error log.
>
> Happy to run some more commands to get additional information.
>
> Best wishes,
>
> Alex
>
> Ludovic Courtès  writes:
>
>> Hello Guix!
>>
>> I’ve run “make release” from the new ‘version-1.1.0’ branch and uploaded
>> the result:
>>
>>   https://web.fdn.fr/~lcourtes/software/guix/1.1.0rc1
>>
>> Alternately (and preferably), you can get it over IPFS:
>>
>>   guix install ipfs
>>   ipfs daemon &
>>   ipfs ls QmXpSUnppJgf23LpaKJzRWJbQxwEfybJy9VxF79iTLSXqa
>>   ipfs get …
>>
>> All the files are signed with my key, also used to sign this message.
>>
>> Please test things as much as you can, be it the binary installation
>> tarball on a “foreign” distro or the ISO image.  Once you’ve downloaded,
>> just follow the same instructions as before (if you want to use
>> ‘guix-install.sh’, you’ll have to adjust it to use the right tarball):
>>
>>   https://guix.gnu.org/download/
>>
>> If you encounter an issue, please report it to bug-g...@gnu.org,
>> explaining what you did and what you observed.
>>
>> Notice that there’s no i686-linux installation image and no VM image,
>> because of <https://issues.guix.gnu.org/issue/40527> but i can provide
>> those later.
>>
>> If everything goes well, we can publish the release on Monday, 13th,
>> with few or no changes beyond translation updates on the ‘version-1.1.0’
>> branch.
>>
>> Thanks in advance!  :-)
>>
>> Ludo’.

Re: 1.1.0rc1 available for test!

[Alex Sassmannshausen]

Hello,

Running the graphical installer from the installation image hosted
through IPFS, I can report the following experience:

The guidance, keyboard configuration & partitioning works well.  In fact
all goes charmingly until the stage where the sysconf is shown.  That
looks correct too.

Hitting continue at that point switches to a terminal wher I briefly see
cow-store being started.

Then the screen flashes back to the beginning of the installer.  Running
through the process again results in the disk drive not being available
for partitioning.

I cannot see any error messages in the brief time I see the terminal and
am not sure how to get an error log.

Happy to run some more commands to get additional information.

Best wishes,

Alex

Ludovic Courtès  writes:

> Hello Guix!
>
> I’ve run “make release” from the new ‘version-1.1.0’ branch and uploaded
> the result:
>
>   https://web.fdn.fr/~lcourtes/software/guix/1.1.0rc1
>
> Alternately (and preferably), you can get it over IPFS:
>
>   guix install ipfs
>   ipfs daemon &
>   ipfs ls QmXpSUnppJgf23LpaKJzRWJbQxwEfybJy9VxF79iTLSXqa
>   ipfs get …
>
> All the files are signed with my key, also used to sign this message.
>
> Please test things as much as you can, be it the binary installation
> tarball on a “foreign” distro or the ISO image.  Once you’ve downloaded,
> just follow the same instructions as before (if you want to use
> ‘guix-install.sh’, you’ll have to adjust it to use the right tarball):
>
>   https://guix.gnu.org/download/
>
> If you encounter an issue, please report it to bug-g...@gnu.org,
> explaining what you did and what you observed.
>
> Notice that there’s no i686-linux installation image and no VM image,
> because of  but i can provide
> those later.
>
> If everything goes well, we can publish the release on Monday, 13th,
> with few or no changes beyond translation updates on the ‘version-1.1.0’
> branch.
>
> Thanks in advance!  :-)
>
> Ludo’.

Re: Using the Hetzner Cloud

[Alex Sassmannshausen]

Heya,

Giovanni Biscuolo  writes:

> Hello Alex,
>
> Alex Sassmannshausen  writes:
>
>> Giovanni Biscuolo  writes:
>
> [...]
>
>>> could you please share that "guix-infect" script?
>>
>> Sure, please see attached.  This one here is a bash script that works
>> with a system config that is specified as part of a here-doc in the bash
>> script.
>
> Cool, thanks!
>
> [...]
>
>> — primarily to encourage myself to keep automating further by
>> integrating this in Guix deploy. Where does all the time go!!!
>
> I'd like to help but still need to enhance my guile-foo
>
>> Happy to help if you run into problems or have questions.
>
> maybe when guix will be in Debian [1] your script could be simpified in
> the first steps... but I hope we'll have a proper guix-deploy way for
> many many providers before :-)
>
> just one more question:
>
> [...]
>
>> #!/bin/bash
>>
>> e2label /dev/sda1 root
>
> [...]
>
>> guix system build /etc/bootstrap-config.scm
>> guix system reconfigure /etc/bootstrap-config.scm
>> mv /etc /old-etc
>> mkdir /etc
>> cp -r /old-etc/{passwd,group,shadow,gshadow,mtab,guix,bootstrap-config.scm} 
>> /etc/
>> guix system reconfigure /etc/bootstrap-config.scm
>
> why two "guix system reconfigure"?

Tbh, not 100% sure.  This script is heavily copypasta.  It looks like
there is an element of transferring debian files away over the course of
the 2, so perhaps it's to fully transition.

But, tbh, not really investigated it, as the second reconfigure is dirt
cheap, and the script just works (tm).

Feel free to experiment!  If you find it's unnecessary, I'd be happy to
hear about it!

Cheers,

Alex

Re: Using the Hetzner Cloud

[Alex Sassmannshausen]

Heya,

Giovanni Biscuolo  writes:

> Hello Alex,
>
> Alex Sassmannshausen  writes:
>
> [...]
>
>> Now I use a different approach: deploy a debian server then use a
>> guix-infect style script (gleaned from the guix deploy code for digital
>> ocean).
>
> could you please share that "guix-infect" script?

Sure, please see attached.  This one here is a bash script that works
with a system config that is specified as part of a here-doc in the bash
script.

It's all a bit gaffer tape & macgyver — primarily to encourage myself to
keep automating further by integrating this in Guix deploy. Where does
all the time go!!!

Happy to help if you run into problems or have questions.

> I think this could/should become an entry in our cookbook, in a similar
> way NixOS does here:
> https://nixos.wiki/wiki/NixOS_friendly_hosters#Hoster-agnostic_means_of_installation

Agreed, a cookbook recipe that summarises the existing ways of deploying
would be cool.  I'd be happy to read over and give feedback on any
proposed articles.

Ellen Papsch  writes:

> […]
> mv var/guix /var/ && mv gnu /
>
> there seems to be a complete takeover, even better than a FrankenDebian
> :-)

Agreed — it's testament to the versatility of Guix that it can literally
do this hostile take-over.  Very cool :-)

Cheers,

Alex
#!/bin/bash

e2label /dev/sda1 root
apt-get update
apt-get install xz-utils -y
wget https://ftp.gnu.org/gnu/guix/guix-binary-1.0.1.x86_64-linux.tar.xz
cd /tmp
tar --warning=no-timestamp -xf ~/guix-binary-1.0.1.x86_64-linux.tar.xz
mv var/guix /var/ && mv gnu /
mkdir -p ~root/.config/guix
ln -sf /var/guix/profiles/per-user/root/current-guix ~root/.config/guix/current
export GUIX_PROFILE="`echo ~root`/.config/guix/current" ;
source $GUIX_PROFILE/etc/profile
groupadd --system guixbuild
for i in `seq -w 1 10`; do
   useradd -g guixbuild -G guixbuild-d /var/empty -s `which nologin` -c "Guix build user $i" --system guixbuilder$i;
done;
cp ~root/.config/guix/current/lib/systemd/system/guix-daemon.service /etc/systemd/system/
systemctl start guix-daemon && systemctl enable guix-daemon
mkdir -p /usr/local/bin
cd /usr/local/bin
ln -s /var/guix/profiles/per-user/root/current-guix/bin/guix
mkdir -p /usr/local/share/info
cd /usr/local/share/info
for i in /var/guix/profiles/per-user/root/current-guix/share/info/*; do
ln -s $i;
done
guix archive --authorize < ~root/.config/guix/current/share/guix/ci.guix.gnu.org.pub
# FIXME: I'm pulling a commit that fixes some issues.  When there is a new
# guix release this can be removed.
guix pull --commit=3a695c01d7ee18f30f22df53f3c44dfac04017f1
guix package -i openssl
# FIXME: Just loading the default example from the guix manual here.  This can
# be adapted to whatever base guix deployment you want.
cat > /etc/bootstrap-config.scm << EOF
 ;; This is an operating system configuration template
 ;; for a "bare bones" setup, with no X11 display server.

 (use-modules (gnu))
 (use-service-modules networking ssh)
 (use-package-modules screen)

 (operating-system
   (host-name "komputilo")
   (timezone "Europe/Berlin")
   (locale "en_US.utf8")

   ;; Boot in "legacy" BIOS mode, assuming /dev/sdX is the
   ;; target hard disk, and "my-root" is the label of the target
   ;; root file system.
   (bootloader (bootloader-configuration
 (bootloader grub-bootloader)
 (target "/dev/sdX")))
   (file-systems (cons (file-system
 (device (file-system-label "my-root"))
 (mount-point "/")
 (type "ext4"))
   %base-file-systems))

   ;; This is where user accounts are specified.  The "root"
   ;; account is implicit, and is initially created with the
   ;; empty password.
   (users (cons (user-account
 (name "alice")
 (comment "Bob's sister")
 (group "users")

 ;; Adding the account to the "wheel" group
 ;; makes it a sudoer.  Adding it to "audio"
 ;; and "video" allows the user to play sound
 ;; and access the webcam.
 (supplementary-groups '("wheel"
 "audio" "video")))
%base-user-accounts))

   ;; Globally-installed packages.
   (packages (cons screen %base-packages))

   ;; Add services to the baseline: a DHCP client and
   ;; an SSH server.
   (services (append (list (service dhcp-client-servi

Re: Using the Hetzner Cloud

[Alex Sassmannshausen]

Hello,

Ellen Papsch  writes:

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

Figured I might as well add my experiences.

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

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

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

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

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

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

Hth,

Alex

Thoughts on stateful services in Guix

[Alex Sassmannshausen]

Hello,

As a result of FOSDEM conversations today I felt inspired to put some
thoughts on paper about an area where I think we currently run into
complications.

Not sure if it is appropriate to write this blog-post-ish contribution
here, but as I don't have a blog, and it's about Guix development, I
figured it might be OK.

Best wishes,

Alex

1 Introduction
══

  Guix is amazing.  A large part of why it continues to be amazing is
  because it provides strong guarantees to the end-user and developer.
  As such it makes reasoning about packages and deployments relatively
  straight-forward.

  The functional paradigm cleary works fantastically for packages.
  Unfortunately it is not quite clear that it works just as well for
  services.  The reason for this is that too many useful services are
  inherently stateful.  Their statefulness means they have side-effects,
  which in turn cause issues when relying on Guix features such as
  roll-back or automated deployment & guaranteed reproducability.

  Disciplined developers can implement many services in such a way that
  their statefulness is delegated to other dedicated services.  In this
  way the problem of statefulness can be isolated.  However, many
  existing useful services /have not/ been implemented in such a way.

  These notes are an attempt to think through ways of formalising how we
  mitigate stateful services in Guix.

  The notes below are organised around the example of a popular PHP
  content management system, Drupal.  Similar problems will apply to
  many other end-user services.

  My intent here is to communicate my thinking in the hopes that others
  can point to obvious flaws in my reasoning — or to stimulate
  conversation about the topic.  I hope at the very least that it is an
  interesting read!


2 Learning by Doing: Packaging & Deploying Drupal
═

2.1 Problem (1): the Drupal tarball is a binary blob!
─

  Released Drupal tarballs are shipped with a bunch of PHP dependencies,
  as well as compiled JS files.  A fully source-distributed installation
  of Drupal would:
  1) delete all shipped PHP dependencies
  2) independently build all PHP dependencies and make them available to
 Drupal (through it's vendor directory as symlinks?)
  3) delete all compiled JS files & libraries
  4) independently build the JS dependencies and make them avalable to
 Drupal.


2.2 Packages must always be stateless!
──

  What does this mean in practice?  Let's look at Drupal again.  When
  you download Drupal, the resulting tarball contains the source code,
  and an empty sites/ folder.  The sites folder is intended to contain
  /state/ files.  The normal installation procedure is to simply drop
  the drupal distribution in your web root directory, and for state
  files to live underneath sites/ within your webroot.

  In Guix, Drupal is packaged so that it is installed in the store.

  The store is read-only and hence no /state/ files can live under the
  sites/ directory in the store.

  How do we get around this?
  1) either we patch drupal to expect the sites/ directory outside of
 its own folder tree.
  2) or we symlink /gnu/store/…drupal…/sites/ to a different location on
 the filesystem (e.g. /var/lib/drupal/sites/)

  The latter solution, while easy, means that a *successful*
  installation of the package Drupal in Guix results in an installation
  in the store with a *broken symlink* pointing outside the store.

  But the package itself has been rendered stateless!


2.3 Drupal: a stateful service
──

  Services in Guix are rich and multidimensional entities.  At core they
  are promises of things that will have happened when a system is up and
  running.  These promises can be arbitrary, like generating a
  configuration file every boot; or they can be an extension of other,
  already existing services.

  A particularly popular service to extend is the shepherd service,
  which ensures that particular daemons are started as soon as possible
  after the system has started.

  What would a Drupal service look like?  Essentially the software is
  just a bunch of files in a webroot — so at it's heart it simply
  extends a web service (e.g. nginx) with new location directives.

  On the other hand it also requires that tha web server, a sql backend
  and php-fpm are running, so that drupal can actually function.

  These two requirements are easily met with the usual service
  infrastructure: simply extend nginx with a location definition
  pointing to the Drupal folder in the store as the webroot and extend
  shepherd to require mysql, nginx and php-fpm.


2.3.1 Enter the state dragon


  But hang-on… if Mysql service is a dependency, and we store state in a
  Mysql DB, what happens when we upgrade to a newer version of Drupal,

Re: Maintainer (no longer) needed for Linux-libre and IceCat packages

[Alex Sassmannshausen]

Hi Mark,

Mark H Weaver  writes:

> Hi Ludovic,
>
> Ludovic Courtès  writes:
>> Thanks for your message.  As discussed privately, I’m sad to see you go,
>> and as co-maintainer I can only say you’re welcome back anytime you want.
>
> Thank you Ludovic, and thanks to all for the kind words.  In light of
> recent events at the FSF, I've had a change of heart and have decided to
> return to the Guix project.  Although I welcome more help with these
> packages, I will resume my previous role, doing what I can to keep our
> Linux-libre and IceCat packages up-to-date, as soon as my commit rights
> on Savannah are restored.
>
>   Regards,
> Mark

This is excellent news — welcome back! \o/

Alex

Re: Guix Data Service - September update

[Alex Sassmannshausen]

Christopher Baines  writes:

> Ludovic Courtès  writes:
>
>> That would be great.  In the end, it seems to be that there are quite a
>> few services we could build around the Data Service.  I’m not sure how
>> they should interact.
>>
>> For instance, Mumi could talk to data.guix.gnu.org over an HTTP API, or
>> should we replicate the database at issues.guix.gnu.org so that Mumi can
>> tap directly into it?
>>
>> Likewise, how should something like hpcguix-web (the package browser at
>> ) exploit available data, for instance to
>> show the history of package versions?
>
> So I've got an initial thing working for the version histories now. You
> can construct a URL like [1], which will show a table about the known
> versions of the package (icecat in this case) on the master branch.
>
> 1: http://data.guix.gnu.org/repository/1/branch/master/package/icecat
>
> The same data is available in JSON [2], and that might work for getting
> the data in the hpcguix-web service.
>
> 2: http://data.guix.gnu.org/repository/1/branch/master/package/icecat.json

This is incredibly cool.

Suddenly I understand how useful the Data Service could turn out to be!

Alex

Re: GSoC 2019 Recap

[Alex Sassmannshausen]

Christopher Lemmer Webber  writes:

> Hi Jakob,
>
> I've already said this off-list, but I feel it's worth repeating
> on-list: thank you for making "guix deploy" a reality.  So many of us
> have wanted it for so long, but you did the really important thing: you
> put in the work, and clearly with great care.  We're glad to have you as
> part of our community; please do stick around! :)
>
>  - Chris

+1 to this!

Alex

Re: Inscrutable error when using “guix deploy”

[alex sassmannshausen]

Hi Ricardo, as no one has responded yet, I'd figure I'd share my 2¢.



On Thu, 22 Aug 2019, 16:23 Ricardo Wurmus,  wrote:

> Hi,
>
> I’m using this deployment file:
>
> --8<---cut here---start->8---
> (use-modules (sysadmin build-machines)
>  (sysadmin people))
>
> (define %ids (list 25))
> (define (system-for id)
>   (berlin-build-machine-os id))
> (define (id->ip id)
>   (format #f "141.80.167.~d" (+ 131 id)))
> (map (lambda (id)
>   (machine
>(operating-system (system-for id))
>(environment managed-host-environment-type)
>(configuration (machine-ssh-configuration
>(system "x86_64-linux")
>(host-name (id->ip id))
>(identity "./id_rsa")
>(port 22)
>  %ids)
> --8<---cut here---end--->8---
>
> And get an error that I don’t understand:
>
> --8<---cut here---start->8---
> root@berlin ~/maintenance/hydra# ~/.config/guix/current/bin/guix deploy
> -L modules deploy-berlin-node.scm
> guix deploy: deploying to hydra-guix-25...
> ERROR: In procedure read:
> In procedure scm_lreadr: #:11:103: Unknown # object: #\<
> --8<---cut here---end--->8---
>
> Any ideas?  Am I doing something wrong?
>

This error, in general shape, looks very much like an error I kept getting
when first "deploying" to a guix server. I found that doing a pull on the
server, followed by a system reconfigure then allowed me to actually
successfully run deploy afterwards.

I'm not sure what causes that, but thought perhaps it was to do with
running an older version of guix on the target server before pulling?

This might be way off the mark, but as I said, just in case it helps!

Alex




> --
> Ricardo
>
>
>

Re: bug#36878: guix system reconfigure broken

[Alex Sassmannshausen]

Thanks for reporting this, I experienced the same issue but blamed it on
my own infrastructure instead!

Good to hear it's resolved now.

Alex

Robert Vollmert  writes:

> Hi,
>
> it appears that commit 5c8c8c455420af27189d6045b3599fe6e27ad012
>
>   guix system: Reimplement 'reconfigure’.
>
> breaks guix system reconfigure. In particular, after reconfiguring,
> shepherd doesn’t know about the updated versions of services.
>
> The usual output below is missing; after reverting the commit it’s
> fine again.
>
> guix system: loading new services: …
> To complete the upgrade, run 'herd restart SERVICE' to stop,
> upgrade, and restart each service that was not automatically restarted.
> shepherd: Evaluating user expression (let* ((services (map primitive-load 
> (?))) # ?) ?).
> shepherd: Service user-homes has been started.
> shepherd: Service term-auto could not be started.
> bootloader successfully installed on '/dev/sda’
>
> I see that some system tests for “guix system reconfigure” were added
> after this change. Might I suggest adding them before the change next
> time around, and making sure they pass both before and after?
>
> Cheers
> Robert

Re: “Towards Guix for DevOps”

[Alex Sassmannshausen]

Hello,

I just wanted to drop a quick note on the guix deploy work carried out
by Jakob.

I've started using it to manage servers, and it seems to work an
absolute charm.  Congratulations to all involved.

I did hit the following small stumbling blocks:

- When first running guix deploy it complained about a missing
  /etc/guix/signing-key.sec.  I fairly quickly realised that deploy
  probably used archive infrastructure, so figured out how to generate
  the keys.  But maybe the manual should contain a line about this?

- The machine-ssh-configuration allows for the specification of users
  other than root, but my understanding is that only root will allow for
  a successful deployment (because root is required to actually
  reconfigure the target system).  I don't know what conclusions to draw
  from this, as I'm not 100% on the roadmap for development.  But maybe
  for now, this could be a gotcha for new users.

Best wishes,

Alex

Ludovic Courtès  writes:

> Hello Guix!
>
> Jakob wrote a lovely post about the ongoing work implementing ‘guix
> deploy’ as part of GSoC:
>
>   https://gnu.org/s/guix/blog/2019/towards-guix-for-devops/
>
> Check it out!
>
> Ludo’.

Re: GNU Guix 1.0.0 released

[Alex Sassmannshausen]

宋文武 writes:

> Ludovic Courtès  writes:
>
>> We are thrilled to announce the release of GNU Guix 1.0.0!
>>
>> This 1.0 release is a major milestone for Guix.  It represents 7 years
>> of hard work with more than 40,000 commits by 260 people, 19 releases,
>> and an equally amazing amount of work on documentation, translation,
>> artwork, web design, mentoring, outreach, and many other activities that
>> together have made it a thriving project.
>>
>> Read more about today’s announcement at:
>>
>>   https://gnu.org/software/guix/blog/2019/gnu-guix-1.0.0-released
>>
>> Whether you’re a software developer, a user, or a free software
>> enthusiast, we hope GNU Guix will provide you with the tools to deploy
>> and manage software with confidence and ease, qualities that are not
>> usually associated with software deployment.  We’d love to hear from you!
>>
>
> Congratulations for the great 1.0.0 release, and thank you very much!!
>
> And for all ones that sending/reviewing/applying patches, packaging
> softwares, making system services, writing and translating
> documentations, helping each other, hacking for the good, so anyone
> involved, thank you!
>
> GNU Guix is such an excellent project and community, I learned a lot and
> gain much satisfactions with it, and will continue to.

Beautifully said and I could not agree more.

Thanks so much to everyone who's put such hard work into this!

Alex

Re: New library: guile-wikidata

[Alex Sassmannshausen]

Hi Swedebugia,

This looks pretty cool! Congrats on getting this far :-)

I would love to be able to have a nice high-level library to introduce
Wikipedia info in my programs, so please continue!

Alex

swedebu...@riseup.net writes:

> Hi
>
> I worked hard for a few hours playing with guile and came up with this.
>
> Next step is to implement looking up the entities for the result and
> filter on instance of (the properties). E.g. software.
>
> :D
>
> What do you think?
> I tried reuse code and abstract away in a a la Guile. This is my first
> program so feel free to give it a review and ideas for improvement.
>
> It depends on (guix import json) right now and I think we should
> upstream those two json-to-alist functions to guile-json.
>
> Example output:
>
> scheme@(guile-user) [25]> (show-first-result "gcc")
> 1.: Q178940: GNU Compiler Collection: compiler system with support for
> various programming languages
>
> scheme@(guile-user) [25]> (show-first-result "emacs")
> 1.: Q189722: Emacs: family of text editors
>
> scheme@(guile-user) [25]> (show-first-result "guile")
> 1.: Q601244: Guile: character from the Street Fighter fighting game
> series
>
> scheme@(guile-user) [25]> (show-first-result "openssh")
> 1.: Q847062: OpenSSH: set of computer programs providing encrypted
> communication sessions
>
> scheme@(guile-user) [25]> (show-first-result "automake")
> 1.: Q1324275: Automake: tool for generating GNU Standards-compliant
> Makefiles
>
>
> Not so reliable output for bioinformatics packages:
>
> scheme@(guile-user) [25]> (show-first-result "aragorn")
> 1.: Q180322: Aragorn: character from the Lord of the Rings
> $19 = #t
> scheme@(guile-user) [25]> (show-first-result "bamm")
> 1.: Q12819323: Bamm: Uzbek name of deep and dark sounds of stringed
> instruments
> $20 = #t
> scheme@(guile-user) [25]> (show-first-result "bamtools")
> 1.: Q30426432: BamTools: a C++ API and toolkit for analyzing and
> managing BAM files.: scientific article
> $21 = #t
> scheme@(guile-user) [25]> (show-first-result "bcftools")
> 1.: Q31041251: BCFtools/RoH: a hidden Markov model approach for
> detecting autozygosity from next-generation sequencing data.:\
>  scientific article
> $22 = #t
> scheme@(guile-user) [25]> (show-first-result "bedops")
> 1.: Q36076319: BEDOPS: high-performance genomic feature operations.:
> scientific article
> $23 = #t
> scheme@(guile-user) [25]> (show-first-result "blast+")
> 1.: Q179057: explosion: sudden release of energy through high
> temperatures and gas expansion
> $24 = #t

Re: New detailed troubleshooting section in the manual

[alex sassmannshausen]

Good to hear it wasn't just use then... I guess maybe we should clarify the
documentation.

Alex

On Sat, 10 Nov 2018, 15:48 Laura Lazzati  It worked :)
> Thank you!
>
> Regards!
> Laura
>
>
>

Re: New detailed troubleshooting section in the manual

[alex sassmannshausen]

Hello,

On Thu, 8 Nov 2018, 20:54 Laura Lazzati  Hi Ludo
>
> Following these instructions should make the warnings go away,
>> doesn’t it?
>>
> No they don't. I installed the package, exported the path, added it to my
> .profile file but the message still appears.
> And if I check `env | sort`, even after rebooting or shutting down, the
> GUIX_LOCPATH is set.
> I also tried installing glibc-locales but the same happens.
>

I may have missed this earlier, but have you tried installing glibc-locales
in the root profile too?

I've found in the past that I needed the full glibc-locales, in root and
user profile. I also needed the path configuration in both. You may need to
restart the deamon after... I don't remember.

If I only did the user install, then the locpath warning message disappears
for the user side, but not for the deamon side.

Hope this is helpful!

Alex


> Regards!
> Laura
>
>

Re: Patch submission should not imply agreement to policy (was Re: Promoting the GNU Kind Communication Guidelines?)

[Alex Sassmannshausen]

Thanks for your answers.  I'm glad to hear that there might be room for
some form of dialogue on wording.

Cheers!

Alex

Thorsten Wilms writes:

> On 31/10/2018 09.58, Alex Sassmannshausen wrote:
>> Out of curiosity, would you personally feel better about the CoC if it
>> used terms such as "This community commits to" or "This community
>> pledges to" insteead of "We as contributors commit to"?
>
> In as far as contributing doesn't make one part of the community
> ... it would be a slight improvement. On the other hand, it's just
> vaguer about whom it puts words into their mouths.
>
>
>> I ask because one of the positives about the CC wording from my
>> perspective is that it specifically makes it a collective responsibility
>> to uphold certain norms, and not just the responsibility of the
>> "projec authorities".  It is understood that there are specific channels
>> for dealing with violations of those norms, but the community as a whole
>> stands behind that.
>
> Yeah, that's the positive reading. A negative is that it is an attempt
> to push people to declare a mixed bag as their own, with no voice in
> the process (other than take it or leave it). One that contains
> hard-to-argue-with aspects, but also questionable and vague parts.

Re: Promoting the GNU Kind Communication Guidelines?

[Alex Sassmannshausen]

After this email I'm done with the conversation.  I have tried to
provide you with evidence.  You make it clear you have a bone to pick
with people concerned with gender equality.  This will go around in
circles.

HiPhish writes:

> There is a common pattern in all the links you provided: 1) only feminists are
> seeing this supposed issue, 2) it does not go into the exact nature of the
> supposed harassment.

The TUC is the trade union congress.  They are not a feminist
organisation.  The Belgian government is not a feminist organization.
The Guardian is a newspaper and the EEOC is a US government office.

> With regards to the first point: Feminist group have vested interests in
> furthering conflicts. Even if there is no conflict they will try to create one
> and then sell you the solution, so please excuse my scepticism. Feminists are
> proven to keep fabricating issues, like the supposed wage gap. So yes, I am
> really doubting the veracity of those claims.

Pff.  I won't even engage with this horse crap.

> You know what? When you go into a field filled with awkward nerds
> that's you occupational hazard.

My line of argument above was precisely that this does not only happen
in a field with "awkward nerds".  Also I find your assertion that
"nerds" are unable to behave decently to other people an insult to
myself and "nerds" as a whole.

> So please excuse me when I don't fall for the crocodile tears. We are
> talking about grown-up women here, not children.

I find it shocking you are basically telling people who are being
mis-treated by others to just suck it up.

It's because of these attitudes I'm glad we have a code of conduct.

>> According to a TUC/Everyday Sexism study on sexual harassment, 52% of
>> women have experienced sexual harassment in the workplace and 80% did
>> not report it to their employer.
> I am singling out this one as an example of data manipulation. Let's for the
> sake of simplicity assume that the data is 100% correct and has not been
> tampered with. Put yourself now in the shoes of an average woman: The question
> is "Have you experienced instances of sexual harassment in the workplace in
> the past?". You think a bit and remember Steve who made a dumb joke about your
> breasts during coffee break last month. So you answer with yes of course. Then
> the second question is "If so, did you report the incident to your employer?".
> Considering Steve is a shy guy, it was during coffee break, no one else joined
> in and after you gave him a stern look he got the message, you of course
> didn't consider it worth anyone's time to start office drama over pretty much
> nothing. So you answer with "no". And now your answer gets twisted into "Don't
> you see all these serious issues going unreported out of fear? You should hire
> our advocacy agency for sensibility training and diversity counseling. You
> have a nice business going here, it would be a shame is someone were to call
> it sexist".

Here's the problem with your argument.  These findings are reproduced
over and over: women are disproportionately affected by harassment,
especially of a gendered kind.  Even if you find an issue with a
specific study, the consensus of virtually all these studies find the
same thing.

You might have better results if you actually pointed to studies that
overturned the consensus.  Good luck with that.

>> In 2012, in Belgium, the film Femme de la Rue directly influenced the
>> passing of legislation to make street harassment
>> illegal.
>> [https://www.theguardian.com/world/2012/aug/03/belgium-film-street-harassme
>> nt-sofie-peeters] It also helped kick-start movements in Belgium and France
>> where street harassment is fairly common.  In london, UK, 4 in 10 women
>> between ages of 18 and 34 experienced street harassment in 2011 alone
>> [https://www.theguardian.com/lifeandstyle/2012/may/25/four-10-women-sexually
>> -harassed].
> Don't you consider it kind of... problematic that the video only shows people
> from a, let's call it "diverse" background? Why doesn't she show us all the
> serial catcallers in the less diverse parts of Belgium? It couldn't be that
> she intentionally picked the bad part of town, now could it? I feel deeply
> offended by the implication of this video that people of colour are the
> primary source of sexual harassment.

Come on.  Get out of here with your manufactured concern.  Whatever the
specific cases in this video were, the overall point, and the conclusion
of the overall debate is that street harassment is a widespread issue,
wherever you go.  It disproportinately affects women and is
disproportinately carried out by men.

I'm done here. Have a nice day.

Alex

Re: Promoting the GNU Kind Communication Guidelines?

[Alex Sassmannshausen]

Hello,

I agree with Ricardo's email that really we should be discussing the CoC
in relation to specific patches against it, to avoid circular debate.
So I will only respond to the specific bit directly asking me to provide
evidence.

HiPhish writes:

> On Monday, 29 October 2018 12:08:56 CET you wrote:
>> I think you a have burden of proof here, given that our culture at large
>> has serious issues with harassment.  Why would you think FLOSS community
>> is somehow different from the wider community?
> No, you have a burden of proof that "our" culture (whatever this "our" is
> supposed to mean, I have no idea where you live and you have no idea where I
> live) has a serious issue with harassment.

[I apologise for the narrow focus on sexual / gender / sex based focus
of the stats below; it's what I'm most familiar with.]

"According to a TUC/Everyday Sexism study on sexual harassment, 52% of
women have experienced sexual harassment in the workplace and 80% did
not report it to their employer."
[https://www.fawcettsociety.org.uk/Handlers/Download.ashx?IDMF=9127932a-455f-4d0c-909d-3563c17dc7c5,
available from
https://www.fawcettsociety.org.uk/sexual-harassment-in-the-workplace]

"In 2014, SSH commissioned a 2,000-person national survey in the USA with
surveying firm GfK. The survey found that 65% of all women had
experienced street harassment. Among all women, 23% had been sexually
touched, 20% had been followed, and 9% had been forced to do something
sexual. Among men, 25% had been street harassed (a higher percentage of
LGBT-identified men than heterosexual men reported this) and their most
common form of harassment was homophobic or transphobic slurs (9%)."
http://www.stopstreetharassment.org/resources/statistics/

"Almost fully one third of the approximately 90,000 charges received by
EEOC in fiscal year 2015 included an allegation of workplace
harassment. This includes, among other things, charges of unlawful
harassment on the basis of sex (including sexual orientation, gender
identity, and pregnancy), race, disability, age, ethnicity/national
origin, color, and religion." and "Roughly three out of four individuals
who experienced harassment never even talked to a supervisor, manager,
or union representative about the harassing conduct."
[from https://www.eeoc.gov/eeoc/task_force/harassment/report_summary.cfm]

In 2012, in Belgium, the film Femme de la Rue directly influenced the
passing of legislation to make street harassment
illegal. 
[https://www.theguardian.com/world/2012/aug/03/belgium-film-street-harassment-sofie-peeters]
It also helped kick-start movements in Belgium and France where street
harassment is fairly common.  In london, UK, 4 in 10 women between ages
of 18 and 34 experienced street harassment in 2011 alone
[https://www.theguardian.com/lifeandstyle/2012/may/25/four-10-women-sexually-harassed].

"54% (272) had experienced some form of workplace sexual harassment."
This is from a 2008 study in Singapore
[http://www.aware.org.sg/training/wsh-site/14-statistics/].

The stats bear out 2 things: a) harassment is very prevalent; b) if
anything, harassment is underreported, not overreported.

Of course the above are all related to a relatively narrow geographic
domain.  I would be very surprised indeed if there was a place that
conducted similar studies, where the picture would not be roughly the
same or worse.

You are correct that I don't know where you're from, but it kind of
doesn't matter, because harassment, especially that on the basis of
gender, sex or sexuality, is a global phenomenon.

Best wishes,

Alex

Re: Patch submission should not imply agreement to policy (was Re: Promoting the GNU Kind Communication Guidelines?)

[Alex Sassmannshausen]

Hi Thorsten,

Thorsten Wilms writes:
> [...]
>
> Likewise, contributing to Guix is apparently meant to imply that one
> makes the pledge as outlined in that CoC.
>
> In both cases, you are meant to not get one without the other. It
> happened that one could not read the EULA in advance and it happened
> that I contributed before reading the CoC carefully. I distrust it's
> origin and I'm not happy about a few details, though they most likely
> will never matter. So I could almost, but not quite make such a
> promise, but I cannot be made to make such a promise. Especially
> retroactively. Even less can I be made to make a promise that might
> change:
>
> I assume that Ricardo and Ludovic want to have the option of editing
> the CoC without asking every single contributor. Well, people should
> better know what the current state of their pledge is.
>
> Not that I think the two would introduce a nasty surprise, it's just
> that the "covenant" and "we as contributors ... pledge" language is
> dishonest.

Out of curiosity, would you personally feel better about the CoC if it
used terms such as "This community commits to" or "This community
pledges to" insteead of "We as contributors commit to"?

I ask because one of the positives about the CC wording from my
perspective is that it specifically makes it a collective responsibility
to uphold certain norms, and not just the responsibility of the
"projec authorities".  It is understood that there are specific channels
for dealing with violations of those norms, but the community as a whole
stands behind that.

Alex

Re: Promoting the GNU Kind Communication Guidelines? (-> convivenza)

[Alex Sassmannshausen]

Hello,

Nils Gillmann writes:

> I have followed most of the breaking threads, and I will keep
> my contribution to simply stating what a friend wrote:
>
> https://mobile.twitter.com/lynXintl/status/1055146900100390913
>
> In essence this refers to convivenza, which in my opinion
> is a much better suited framework for this than what
> has been brought up so far:
> https://structure.pages.de/convivenza
>
> Interested groups can contract the structure work group
> (https://structure.pages.de/) and work out implementations.
>
> I don't want any follow-ups directed at myself, I don't
> have the time to deal with circular discussions wrt this.
> Take it as a statement of recommendation.

I found this a very interesting text, thanks for sharing.

Personally I will be thinking about it for a while :-)

Alex

Re: Promoting the GNU Kind Communication Guidelines?

[Alex Sassmannshausen]

Hello,

Gábor Boskovits writes:

> I have a feeling that I might confuse some things, as this thread is
> getting rather long, so let me summarize what I have on my mind so
> far:
>
> 1. There is general consensus that having both CoC and GKCG is pointless.
> 2. CoC is not welcome by all, mainly because they feel that it
> discourages contributions.
> 3. GKCG seems to be inadequate in the opinion of the maintainers, as:
> a. it does not define acceptable behaviour, and
> b. it does not define processes.
>
> My conclusion is that neither document really cuts the bill.
>
> I proposed to try to roll our own, essentially based on GKCG,
> but have the acceptable behaviour and the processes defined.
>
> Do you think this can/should be done?
> Do you think that this could result in a better situation overall?

I appreciate the motivation behind this effort.  Personally I think it
is better to stick with a widely used, and fairly robust policy.  In
addition, rolling our own will be a very long, exhausting process, and
we'll likely end up with a document that still doesn't please everyone.

Just my 2¢.

Alex

>
> Best regards,
> g_bor

Re: Promoting the GNU Kind Communication Guidelines?

[Alex Sassmannshausen]

Thorsten Wilms writes:

> On 28/10/2018 13.33, Gábor Boskovits wrote:
>> 1. There is general consensus that having both CoC and GKCG is pointless.
>
> ACK
>
>> 2. CoC is not welcome by all, mainly because they feel that it
>> discourages contributions.
>
> That's a somewhat limited and tame take on it ;)
> You may count me as having contributed (little as it was) despite of
> the CC, definitively not because of it.

I for one am very glad you decided to contribute!

> The association with the primary author makes some people think of the
> ... fighting stance of her, the anti-meritocracy thing and her use of
> 2nd-hand "quotes" to get people into trouble (trying to keep it short
> here, thus far from exact).

I think if you make these assertions you might want to bring context.
As it stands it reads a little like "poisoning the well": you seem to
imply the CC is bad because allegedly the author has done bad things in
the past.

> While one may say that the CC can and should be seen on its own, this
> background does turn it into ... unwelcoming language to some.
>
> I take it for some it reads like an invitation to those with little to
> nothing better to do, to report perceived or even made-up misbehavior.

And that assumption by those people would be, to the best of my
knowledge of the actual facts, incorrect.

> It has run-on sentences and ridiculous lists. Compare, and I can't
> even bring myself to quote from the start of the sentence in the far
> distance:
>
> "... regardless of age, body size, disability, ethnicity, gender
> identity and expression, level of experience, education,
> socio-economic status, nationality, personal appearance, race,
> religion, or sexual identity and orientation."
>
> With Debian's:
>
> "No matter how you identify yourself or how others perceive you: we
> welcome you. We welcome contributions from everyone as long as they
> interact constructively with our community."
>
>
> How does one manage to separate gender identity and expression from
> sexual identity and orientation? Maybe one must take gender studies
> ...

Just to clarify, gender identity and expression refers to who you (feel
like you) are.  Sexual identity & orientation is about who you are
attracted to.

> and biology? Disability is listed, not (level of) ability. Body size
> couldn't be be subsumed by (personal (what other kind could it be?))
> appearance?  Trying so hard to be political correct, but than using
> the loaded term "race".
>
>
> This one is too "funny":
> "The project team is obligated to maintain confidentiality with regard
> to the reporter of an incident."

This is not uncommon in the context of harassment cases.

> So if Jim reports that Jane threatened him to foobar his baz, then the
> project team has to contact Jane, but must keep it secret that Jim
> reported the issue? While being fair to Jane? Maybe such threats are
> illegal in the countries of both, maybe it's actually one country and
> police and the judicature might get involved?
>
> If the reporter is a 3rd party, sure, but even then an accused person
> may express anger towards the potential victim, via assuming that the
> potential victim reported personally.
>
> Now there may be cases where protecting a reporter is important and
> just, but this "protecting any accuser, always" stance seems
> problematic.

This reads like hyperbole.  If somenoe makes a complaint about me, I
will be contacted by the maintainers.  They will discuss the nature of
the allegation with me, and hopefully I will be able to say "Shit, I had
no idea what I did had this impact on someone else in the community.
Thanks for bringing this to me.  Any idea how I can avoid this in
future?".

I don't see where the problem is there?

>> 3. GKCG seems to be inadequate in the opinion of the maintainers, as:
>> a. it does not define acceptable behaviour, and
>> b. it does not define processes.
>>
>> My conclusion is that neither document really cuts the bill.
>>
>> I proposed to try to roll our own, essentially based on GKCG,
>> but have the acceptable behaviour and the processes defined.
>>
>> Do you think this can/should be done?
>> Do you think that this could result in a better situation overall?
>
> Yes and yes, though I'm not sure how much of a GKCG-alike it should
> become, as I think it's important to have something short that people
> can read and agree with (or not).

Alex

Re: Promoting the GNU Kind Communication Guidelines?

[Alex Sassmannshausen]

Hi Thorsten,

Thorsten Wilms writes:

> On 29/10/2018 09.23, Björn Höfling wrote:
>> Example: Sage Sharp left the kernel development:
>>
>> https://sage.thesharps.us/2015/10/05/closing-a-door/
>>
>> How good would have been the USB 3.0 driver now, or the
>> community documentation, when he would have continued his work with
>> passion in a respectful community?
>
> Sage may feel you mis-gendered them, as they prefer they/them. Please
> be respectful ;)

Thank you for letting us know; I certainly would aim want to respect
their preference.

> Sage advocates the CoC and called an opponent a "rape apologist",
> based on not just a mean spirited interpretation, but rather factually
> wrong. I think this qualifies as slander.
>
> https://twitter.com/_sagesharp_/status/1042769399596437504
> using as reference:
> http://geekfeminism.wikia.com/wiki/Rape_apology_on_LCA_mailing_list

I'm sorry, I'm not clear on where the factual incorrectness was in the
things you linked to above.  I did not follow the original debate in
detail so am going on the links you provide.

> This is a prime example of what may make one suspicious of CoCs and
> the Covenant in particular, when people who want them do things like
> that. It looks like war, with the usual effects on truth and fairness.

I'm not seeing this from what you linked to.

Best wishes,

Alex

Re: Promoting the GNU Kind Communication Guidelines?

[Alex Sassmannshausen]

Hello,

I strongly support the CC and a specific CoC. Just to put my cards on
the table.

HiPhish writes:

> I have had two packages merged, which I guess that makes me technically a
> contributor, so here is my takes on the issue.
>
> In my opinion Codes of Conduct (or CoCs in short) are one of the worst things
> that have happened in recent years to Free and Open Source projects (hold that
> though, I will address it soon enough), and the Contributor Covenant (CC in
> short) is the worst offender. I will explain shortly why this is, but please
> allow me to elaborate first.
>
> There is no problem of harassment in FLOSS, there is a problem of socially
> awkward nerds in FLOSS.

I think you a have burden of proof here, given that our culture at large
has serious issues with harassment.  Why would you think FLOSS community
is somehow different from the wider community?

> Harassment presupposes malice, i.e. that the offending person is
> intentionally being abusive.

You can harass someone whilst believing your acting positively.  E.g. an
ex-partner that "just wants to show how much they love the person that
spurned them".  And ends up stalking them.

> If you have never said anything that made you want to vanish into the
> ground the moment it came out of your mouth you are not human. Some
> people will slip up more often than others, and let's face it: the
> people who are more likely to slip up are also more often the ones who
> are good at programming. Why is it this way? I don't know, I'm not a
> psychologist or anthropologist, I just need to know that this is the
> way things are.
>
> Now here is the important part: for an offensive act to be committed it takes
> two sides, the offender and the offended. Part of social competence is knowing
> not to slip up, but part of it is also knowing to just let it slide when
> someone else slips up.

You're conflating harassment and offense here.  It is one thing to be
offended by individuals using the wrong cutlery for the entrée; it is
another entirely for someone to, e.g. use crass racist caricatures.

> Again, I'm not talking just about online discourse, but social
> interaction in general. When someone says something stupid just ignore
> that person, and if it keeps happening try to correct them in a
> friendly manner. This is how we grow as humans.
>
> This leads me into why the CC is a harmful CoC. The CC presupposes malice by
> default, more than half of its content is focused on punitive measures, not on
> helping each other. In contrast, the GNU Kind Communications Guidelines (GKCG
> in short) explicitly promotes a cooperative two-sided perspective:
>
>> Please assume other participants are posting in good faith, even if you
>> disagree with what they say. When people present code or text as their own
>> work, please accept it as their work. Please do not criticize people for
>> wrongs that you only speculate they may have done; stick to what they
>> actually say and actually do.
>>
>> Please do not take a harsh tone towards other participants, and especially
>> don't make personal attacks against them. Go out of your way to show that
> you
>> are criticizing a statement, not a person.
>>
>> Please recognize that criticism of your statements is not a personal attack
>> on you. If you feel that someone has attacked you, or offended your personal
>> dignity, please don't “hit back” with another personal attack. That tends to
>> start a vicious circle of escalating verbal aggression. A private response,
>> politely stating your feelings as feelings, and asking for peace, may calm
>> things down. Write it, set it aside for hours or a day, revise it to remove
>> the anger, and only then send it.
>
> There is nothing like this in the CC, but there is this:
>
>> Instances of abusive, harassing, or otherwise unacceptable behavior may be
>> reported by contacting the project team at [INSERT EMAIL ADDRESS]. All
>> complaints will be reviewed and investigated and will result in a response
>> that is deemed necessary and appropriate to the circumstances. The project
>> team is obligated to maintain confidentiality with regard to the reporter of
>> an incident. Further details of specific enforcement policies may be posted
>> separately.
>>
>> Project maintainers who do not follow or enforce the Code of Conduct in good
>> faith may face temporary or permanent repercussions as determined by other
>> members of the project’s leadership.
>
> The CC is claiming to foster "an open and welcoming environment" while at the
> same time holding a gun to every maintainer's head. The accused is not even
> allowed to know what the accusation is about (confidentiality clause), so how
> are they supposed to know what they did was wrong? There is no clause that
> allows the accused to defend their position, only punishment is defined. This
> applies even to the maintainer, so if they maintainer wants to protect an
> unjustly accused person, the maintainer will be on the chopping 

Re: Regards from Outreachy applicant

[alex sassmannshausen]

On Sun, 7 Oct 2018, 21:50 Laura Lazzati,  wrote:

> Hi everyone,
>
> My name is Laura and I am applying for the outreachy program.
>
> I have already introduced myself in the IRC channel, but I am also
> doing so here.
>
> I'm an Information Systems Engineer from Argentina, who graduated with
> honors. I liked really much your project. I worked in two HPC
> supercomputer centers last year, but unluckily I had a bad experience,
> so that's why I am applying to outreachy. I even took two Latin
> American courses, one of them even abroad.
> In spite of everything, I don't deserve to give up and I do not want to.
>
> Thanks for being a supporting community.
>
> Regards!
>
> Laura
>

Welcome to the community and good luck with the project!

Always a joy to see new people :)

Alex

My compliments to the chef…

[Alex Sassmannshausen]

Heya,

I just wanted to, as an end user, say that the new colourful & more
silent output of Guix is amazing.

It looks so much less stressful! :D

Well done to all involved for getting this in!

Cheers,

Alex

Re: FOSDEM 2019 (ACTION: please register or mail)

[alex sassmannshausen]

I'm in.

On Fri, 24 Aug 2018, 11:23 Pjotr Prins,  wrote:

> Who wants to come to a separate 2 day GNU Guix event?
>
> That is the Thursday Jan 31st and/or Friday Feb 1st right before
> FOSDEM. I.e., 4 days of hacker nirvana.
>
> FOSDEM is really great. Look at last year's schedule for Saturday
>
>   https://archive.fosdem.org/2018/schedule/day/saturday/
>
> Last year we had a 1 day event with about 25 people before FOSDEM.
> See
>
>   https://libreplanet.org/wiki/Group:Guix/FOSDEM2018
>
> If you intend to come and/or want to speak please add your name and
> proposed title to the new page at
>
>   https://libreplanet.org/wiki/Group:Guix/FOSDEM2018
>
> Alternatively, reply here or mail me privately so we can keep a tally.
>
> Please do so because we need to find a venue again on a first come
> first go basis if we run out of seats.
>
> Pj.
>
> On Tue, Aug 21, 2018 at 04:33:53PM +0300, Manolis Ragkousis wrote:
> > Hello everyone,
> >
> > It's that time of the year again we need to start organizing about
> > FOSDEM. We have a deadline for the 20th of September[1] to apply for a
> > devroom. We also need to start looking for a place for this year's
> > fringe event!
>

Re: Web interface pushed

[Alex Sassmannshausen]

Wow, that looks beautiful! Congratulations to all involved, and
especially Tatiana :D

Alex


Clément Lassieur writes:

> Hi,
>
> amirou...@hypermove.net  writes:
>
>> Hi
>>
>> How can I test?
>
> On https://cuirass.lassieur.org:8081/ for now, and on
> https://berlin.guixsd.org/ when Ricardo guix pulls and guix reconfigures
> it :-)
>
> Clément

Re: FOSDEM 2018 and announcing a GNU Guix/Guile day! After getting home...

[Alex Sassmannshausen]

Hello,

It sounds like the event was absolutely amazing — I'm well jealous of
everyone who was able to go!

Ludovic Courtès writes:

> That alone could justify pursuing the same approach in the coming
> years, IMO.  At the same time, a devroom at FOSDEM proper is a good
> way to reach out to new people, which is also a good thing.  Maybe we
> could do both?  :-)

Yes please! That would give me another chance to participate :D

Alex

Re: Dinner in Brussels?

[Alex Sassmannshausen]

Unfortunately I won't be able to make it and won't be able to help
organize either.  It sounds like a great crowd though, so I'm jealous
I'll be missing it!

Alex

Ludovic Courtès writes:

> Hello Guix!
>
> To those going to the Guix workshop in Brussels this Friday: who’s in
> for dinner (+ drink) on Friday evening?
>
> Even better: who would like to book something (I’m looking at you,
> Brusselers ;-))?
>
> Actually I’m arriving on Thursday afternoon, so if people are around,
> I’d be happy to have dinner on Thursday evening too!  :-) Let’s arrange
> something.
>
> Ludo’.

Cancellation for Friday's event

[Alex Sassmannshausen]

Hello,

Unfortunately due to unforeseen work pressures I won't be in Brussels
over the Fosdem weekend.

I'm gutted, but I'll have to miss the first ever Guix fringe conference
too!

I hope you all have an amazing time!

Best wishes,

Alex

Re: Call for project proposals: Guix and Outreachy

[Alex Sassmannshausen]

Hey,

Ricardo Wurmus writes:

> Hi Alex,
>
>> I have read through the documentation and I believe I would be able to
>> commit to the duties of being a mentor / co-mentor.
>
> Wonderful!
>
>> I would be happy to send more details of where I believe my relative
>> strengths and weaknesses in this project would be.  I couldn't see an
>> appropriate place for that on the outreachy website — would it be best
>> to discuss this by email with you two?  Or on list?
>
> Either way is fine.  You’re welcome to send me email off-list if you
> think it shouldn’t be public.

OK, will do!

>>> Feel free to discuss project ideas right here before submitting an
>>> official proposal.  Project ideas for the Google Summer of Code are
>>> equally valid for an Outreachy internship.
>>
>> Wrt to project ideas, if I understand the target audience right, I would
>> propose perhaps as one project a strengthening of the Guile tooling
>> around Guix.
>>
>> Starter tasks could be helping to package and review existing packages
>> of Guile software for Guix.
>>
>> Actual project tasks could revolve around developing a nice Guile build
>> system for Guix.
>
> Thank you for this proposal.
>
> I wonder if that’s a project that would be big enough for a three month
> internship.  Adding support for existing build systems in Guix usually
> isn’t very difficult, because much of the work has already been done in
> the form of the gnu-build-system.
>
> I worry that the actual implementation would be little more than walking
> down the directory tree, compiling every Scheme file, and then copying
> files over to a target location.
>
> On the other hand, this project could become more comprehensive if we
> looked at the earlier potluck proposal and adopted a few more tasks from
> there.  What do you think?

I like this idea.  It feels like we'd have a nice learning curve here,
that also touches a significant chunk of guix build tooling here.

So:
- pre-project tasks: package Guile (and other) packages, to get familiar
  with problems around packaging, and basic concepts.
- project 1): extend gnu-build-system for a guile-build-system that
  "does the right thing", when full autotools support is present in the
  project. [difficulty: easy: just customise/add gnu-build-system
  phase].
- project 2): simple-guile-build-system that installs guile only modules
  without autotools present. [difficulty: medium: write a build-system
  from scratch]
- project 3) and onward: potluck.  This project would take the candidate
  beyond the confines of Guile projects specifically, focusing on the
  user journey of "new contributors" to Guix in general.  The work
  optimising for Guile, and their own user journey, should be
  informative for this. [difficulty: ?]

The latter will need to be broken down further: ideally we want to be
able to present a well-defined project with discrete steps that could be
added to Guix incrementally to avoid a large chunk of code outside
master to be merged "at some point…"

>> First steps would be perhaps to enhance the gnu-build-system with
>> additional phases for Guile specific tasks (setting the Guile site path
>> correctly, ensuring guile dependencies are propagated inputs…)
>>
>> A second step might be a simplified Guile build system, which does not
>> rely on autotools infrastructure.  I believe this was discussed in the
>> past: it would be a "beginners build system" for *Guile only* packages
>> for quick and easy sharing in the Guix community.
>
> These seem like reasonable steps.  What are the assumptions that we
> would make about Guile-only projects?  It might help to have a list of
> Guile packages that don’t use a proper build system and compare their
> file layout to figure out the kind of work the build system would have
> to perform.

Agreed.  I think the following assumptions are fairly uncontroversial:
- a guile project has at least one source file
- but no more than one source file in the "root" of the modules
  directory layout
- if the project has more than one source file, these are located in
  subdirectories of the "root" of the modules directory layout
- there should be a directory of .scm files that contains tests,
  generally called "tests"
- there could be a directory containing .texi files, generally called
  "doc"

e.g.
foo-project/foo.scm
foo-project/foo/bar.scm
foo-project/foo/baz.scm
foo-project/fan/bot.scm
foo-project/tests/scm
foo-project/doc/texi

But as you say, it probably makes more sense looking at existing
Guile-only projects to confirm/falsify this.

>> Finally we might look at first steps to generate guix package recipes
>> from guile projects.  A first step might be a well-defined script that
>> generates a new project filetree, and writes a guix.scm file within it
>> that contains a Guix recipe using the beginners guile build system.
>
> Would this still be needed even if the guile-build-system were robust
> enough to deal with different kinds of file layouts?

You are 

Re: Call for project proposals: Guix and Outreachy

[Alex Sassmannshausen]

Hi

pelzflorian (Florian Pelz) writes:

> Hello,
>
> On Fri, Jan 26, 2018 at 12:53:37PM +0100, Alex Sassmannshausen wrote:
>> A second step might be a simplified Guile build system, which does not
>> rely on autotools infrastructure.  I believe this was discussed in the
>> past: it would be a "beginners build system" for *Guile only* packages
>> for quick and easy sharing in the Guix community.
>
> By beginners build system, do you mean a Guix build system that just
> copies the modules directory and compiles?

Yes — it would just carry out the steps so that if the Guile package is
a propagated input to anything else, or if it is installed directly, the
Guile package would be available to the Guile executable in that
context.

So the files would simply be installed in the ACTUAL_GUILE_VERSION site
dir & ccache dir.

> Forgive my ignorance as someone who has no deep understanding of
> Guile/Guix, but I think it would be better if even simple Guile only
> packages used a build system like Meson or Autotools.  Even Guile only
> packages should not need Guix or manual copying.  The syntax of
> Autotools is too complicated IMHO, but using a general purpose build
> system like Meson for simple C projects is no more work than listing
> the source files and data files like pkg-config and this should apply
> to Guile projects as well.

I sympathise with your perspective, but this proposed second step would
be quite "selfish" from the perspective of Guix and Guile: it would be a
strong improvement in comparison to what we have now (no widely used
package manager, or project bootstrapping system for Guile), whilst not
committing to infrastructure behind it.

As such it doesn't aim to "care" about non-guix use-cases.  To phrase it
strongly I think Guix is the de-facto Guile package manager, so a good
first step is a simple build environment for that specific package
manager.

We could then gradually build on the tooling to allow a migration path
to autotools.

> That said, a beginners Guix build system for pure Guile projects is
> done much more easily than making simple general purpose build systems
> support Guile.  I’d like to take a look at Meson support for Guile and
> Guile implementations of Ninja and Meson, but I probably can’t/won’t
> commit the time…  Well maybe…

I would be very interested to hear about your further research into this
area for sure! The above stuff is just my opinion so far :-)

Cheers,
Alex

Re: Call for project proposals: Guix and Outreachy

[Alex Sassmannshausen]

Hi Ricardo,

Ricardo Wurmus writes:

> on behalf of the Guix community I submitted an application for this
> project to participate in Outreachy, an internship project for people
> from sections of the population that are commonly underrepresented in
> the world of free software development.
>
> Our application is currently undergoing review.  If accepted we will
> fund one intern for the upcoming internship period between May and
> August.

This is great news — well done for taking the initiative.

> The Guix community already has a landing page on the Outreachy website:
>
> https://www.outreachy.org/communities/cfp/gnu-guix/
>
> You can already submit project proposals on this page, which Ludo and I
> would review and approve.  Please consider becoming a co-mentor for a
> project to make our ongoing participation in Outreachy a success.

I have read through the documentation and I believe I would be able to
commit to the duties of being a mentor / co-mentor.

I would be happy to send more details of where I believe my relative
strengths and weaknesses in this project would be.  I couldn't see an
appropriate place for that on the outreachy website — would it be best
to discuss this by email with you two?  Or on list?

> Feel free to discuss project ideas right here before submitting an
> official proposal.  Project ideas for the Google Summer of Code are
> equally valid for an Outreachy internship.

Wrt to project ideas, if I understand the target audience right, I would
propose perhaps as one project a strengthening of the Guile tooling
around Guix.

Starter tasks could be helping to package and review existing packages
of Guile software for Guix.

Actual project tasks could revolve around developing a nice Guile build
system for Guix.

First steps would be perhaps to enhance the gnu-build-system with
additional phases for Guile specific tasks (setting the Guile site path
correctly, ensuring guile dependencies are propagated inputs…)

A second step might be a simplified Guile build system, which does not
rely on autotools infrastructure.  I believe this was discussed in the
past: it would be a "beginners build system" for *Guile only* packages
for quick and easy sharing in the Guix community.

Finally we might look at first steps to generate guix package recipes
from guile projects.  A first step might be a well-defined script that
generates a new project filetree, and writes a guix.scm file within it
that contains a Guix recipe using the beginners guile build system.

What do you think?

Alex

Re: 01/01: gnu: Add guile-dsv.

[Alex Sassmannshausen]

Hi Mark,

Mark H Weaver writes:

> alex.sassmannshau...@gmail.com (Alex Sassmannshausen) writes:
>
>> atheia pushed a commit to branch master
>> in repository guix.
>>
>> commit e9291eaa427066e5c8e531acc79f34d93dc845f0
>> Author: Alex Sassmannshausen <a...@pompo.co>
>> Date:   Fri Nov 24 11:51:19 2017 +0100
>>
>> gnu: Add guile-dsv.
>> 
>> * gnu/packages/guile.scm (guile-dsv): New variable.
>
> Hydra failed to build the 'source' derivation of this package:
>
>   https://hydra.gnu.org/build/2360613
>   https://hydra.gnu.org/build/2360613/nixlog/1/raw
>
> It's a bit puzzling though.  The only error message I see is this:
>
>   environment variable `PATH' unset
>
> I'm not sure what's going on here.  Any ideas?

The first link contains an error message:

"Failed: r:sha256 hash mismatch for output path
`/gnu/store/yk01c0qbww324hrqck1kmx695cx1f1rs-guile-dsv-0.2.0-checkout'"

I take it that that might mean the sha256 in the recipe is incorrect.

In any case Artyom released a new version,  so I bumped it up, and
rebuild it locally — this new version seems to work fine.

I have pushed this and hopefully hydra will find it more appetizing this
time too!

Thanks for letting me know!

Alex

Re: [PATCH] gnu: Add guile-dsv.

[Alex Sassmannshausen]

Hi Ludo,

Thanks for the review, I've pushed it with the changes you proposed.

Cheers,

Alex

Ludovic Courtès writes:

> Hi Alex,
>
> Alex Sassmannshausen <alex.sassmannshau...@gmail.com> skribis:
>
>> * gnu/packages/guile.scm (guile-dsv): New variable.
>
> [...]
>
>> +(inputs `(("guile" ,guile-2.2)))
>> +(propagated-inputs `(("guile-lib" ,guile2.2-lib)))
>
> Should be ‘guile-lib’ instead of ‘guile2.2-lib’ (the latter is a
> deprecated alias.)
>
>> +(synopsis "DSV module for Guile")
>> +(description
>> + "Guile-DSV is a GNU Guile module for working with the
>> +delimiter-separated values (DSV) data format.
>> +
>> +Guile-DSV supports the Unix-style DSV format and RFC 4180 format.
>> +")
>
> I think you can remove the extra newlines.
>
>> +(license license:gpl3)))
>
> ‘gpl3+’ I guess?
>
> OK with these changes, thank you!
>
> Ludo’.

[PATCH] gnu: Add guile-dsv.

[Alex Sassmannshausen]

* gnu/packages/guile.scm (guile-dsv): New variable.
---
 gnu/packages/guile.scm | 51 ++
 1 file changed, 51 insertions(+)

diff --git a/gnu/packages/guile.scm b/gnu/packages/guile.scm
index abcefd32e..b94ffa754 100644
--- a/gnu/packages/guile.scm
+++ b/gnu/packages/guile.scm
@@ -1492,6 +1492,57 @@ It currently supports MySQL, Postgres and SQLite3.")
 SQL databases.  This package implements the interface for SQLite.")
 (license license:gpl2+)))
 
+(define-public guile-dsv
+  (package
+(name "guile-dsv")
+(version "0.2.0")
+(source (origin
+  (method git-fetch)
+  (uri (git-reference
+(url "https://github.com/artyom-poptsov/guile-dsv;)
+(commit "7d2e06a15e1d8478cd0e8fb4c79aec519dc4cfd0")))
+  (file-name (string-append name "-" version "-checkout"))
+  (sha256
+   (base32
+"0ywb0hdbs4lcjag8b3id43fpyn5s6gscg7dk0n9ryigyvch80wxj"
+(build-system gnu-build-system)
+(native-inputs
+ `(("autoconf" ,autoconf)
+   ("automake" ,automake)
+   ("pkg-config" ,pkg-config)
+   ("texinfo" ,texinfo)))
+(inputs `(("guile" ,guile-2.2)))
+(propagated-inputs `(("guile-lib" ,guile2.2-lib)))
+(arguments
+ '(#:phases (modify-phases %standard-phases
+  (add-before 'configure 'set-guilesitedir
+(lambda _
+  (substitute* "Makefile.in"
+(("^guilesitedir =.*$")
+ "guilesitedir = \
+$(datadir)/guile/site/$(GUILE_EFFECTIVE_VERSION)\n"))
+  (substitute* "modules/Makefile.in"
+(("^guilesitedir =.*$")
+ "guilesitedir = \
+$(datadir)/guile/site/$(GUILE_EFFECTIVE_VERSION)\n"))
+  (substitute* "modules/dsv/Makefile.in"
+(("^guilesitedir =.*$")
+ "guilesitedir = \
+$(datadir)/guile/site/$(GUILE_EFFECTIVE_VERSION)\n"))
+  #t))
+  (add-after 'unpack 'autoreconf
+(lambda _
+  (zero? (system* "autoreconf" "-vfi")))
+(home-page "https://github.com/artyom-poptsov/guile-dsv;)
+(synopsis "DSV module for Guile")
+(description
+ "Guile-DSV is a GNU Guile module for working with the
+delimiter-separated values (DSV) data format.
+
+Guile-DSV supports the Unix-style DSV format and RFC 4180 format.
+")
+(license license:gpl3)))
+
 (define-public guile-xosd
   (package
 (name "guile-xosd")
-- 
2.15.0

Re: Using IPFS to host mirrors of source packages

[Alex Sassmannshausen]

Pjotr Prins writes:

> By hosting source packages on IPFS they become content addressable and
> should scale for downloads. It would also become a safe way of
> distributing data. 
>
> https://github.com/ipfs/ipfs
>
> Essentially the interplanetary file system allows for distributed
> storage servers and a distributed DNS style resolution for finding
> files. It allows people to share storage and by pooling storage we
> can provide resilient access to all source packages. Especially the
> ones that prove dodgy now.
>
> This should be fairly trivial to implement as long as some of us can
> commit some storage. We could use the build farm. 
>
> Next we can do the same for binary Guix packages. It would make for
> way faster downloads when the Guix-deamon supports the protocol.
>
> Can we look into this? Who of us can host IPFS and expose port 4001? I
> can put in some.

I would be willing to dedicate (part of the) resources on a UK based
(small) VPS for an initiative of this type (doesn't necessarily have to
be IPFS, but this sounds good so far :-) ).

Best wishes,

Alex

Re: Trouble with circular module dependencies (Re: 01/02: gnu: Add ncurses-with-gpm.)

[Alex Sassmannshausen]

Ricardo Wurmus writes:

> Ludovic Courtès  skribis:
>
>> Mark H Weaver  skribis:
>>
>>> FWIW, I would like to see us work to eliminate all cyclic module
>>> dependencies in Guix, by splitting up our package modules as needed so
>>> that they form a directed acyclic graph.
>>
>> This seems hard to achieve, unless we use one file per package.
>
> Are there drawbacks to using one file per package other than it’s a bit
> “heavy” due to all the boilerplate of license headers and module
> definitions?

I have two thoughts that are related to this:
- languages like Perl, which have tons of modules on CPAN, a great
  number of which are incredibly simple and small: we are literally
  talking about adding 100s of files. This is quite different from
  adding a "program", such as Emacs, a larger, well-defined definition.
  I don't think the Perl example is a stopper, but perhaps something to
  consider in terms of performance/implementation.

- If we take this direction, perhaps we should aim to have a helper
  commandline script to which you can pass the dependencies, and which
  takes care of writing the boilerplate as well as importing the
  appropriate modules?

Alex

Re: Unprivileged /gnu/store with PRoot

[Alex Sassmannshausen]

Ludovic Courtès writes:

> Hello Guix!
>
> In hostile environments (read: machines that lack Guix and where you’re
> [...]
>
> Pretty cool no?  :-)

… Very cool! I once again stand gob-smacked :-D

Alex

Re: backup w/ duplicity borg attic bup?

[Alex Sassmannshausen]

Hello,

myglc2 writes:

> I am looking for a command line de-duplicating backup tool. I will be
> using it between GuixSD, Guix/GNU/Linux, and MacOS.
>
> Based on what I see in gnu/packages/backup.scm and in https://brew.sh,
> duplicity, borg and attic seem like they could be good choices.
>
> I am also intrigued by bup (https://github.com/bup/bup), for which we
> don't have a package (yet).
>
> I would like to avoid python, but all of the above seem to use it ;-(
>
> Does anyone out have suggestions?

I've gone through obnam, duplicity and am now using borg.  For various
reasons the former two ended up not working for my needs.  Suffice to
say borg is working great for me now.

HTH,

Alex

GNU Hackers Meeting 2017 call for presentations!

[Alex Sassmannshausen]

Hello!

The GNU Hackers Meeting is looking for presentations for this years
programme!

Find out all you need to know, and/or submit your proposal at
https://www.gnu.org/ghm/programme.html .

The deadline for submissions is 4 June 2017.

The meeting will take place 24 - 27 August in Germany.  The meeting is
on the smaller end of conferences, which creates a lovely, open and
welcoming atmosphere.

You're interested in Free Software development or activism?  Join us, we
want you there!

Please boost this message far and wide, to mailing lists you are on,
to your IRC communities or via other channels of social media.

Outside of this email, I have put out messages at
https://octodon.social/web/statuses/1284133 and
https://twitter.com/_atheia_/status/857895331673059328 .  Feel free to
repeat, adapt, augment :-)

Happy hacking,

Alex

Re: GuixSD on servers… has someone used Hetzner dedicated servers before?

[Alex Sassmannshausen]

ng0 writes:

> "We are the Guix. Your biological and technological distinctiveness will
> be added to our own. Resistance is futile."

Excellent… :-)

Re: [PATCH 01/26] gnu: Add perl-file-pushd.

[Alex Sassmannshausen]

Heya,

Thank you all for your advice!

I can confirm that the builds were successful locally.

On the back of this I will push to master later this evening.

Cheers,

Alex

Kei Kebreau writes:

> Alex Sassmannshausen <alex.sassmannshau...@gmail.com> writes:
>
>> Hi Ben,
>>
>> Ben Woodcroft writes:
>>
>>> Hi,
>>>
>>>
>>> On 24/03/17 18:13, Alex Sassmannshausen wrote:
>>>> Hi Kei,
>>>>
>>>> Kei Kebreau writes:
>>>>
>>>>> This series of packages builds and lints fine for me. There are over 200
>>>>> dependent packages that would have to be rebuilt though, and
>>>>> core-updates is frozen to my knowledge. We can save this for the next
>>>>> core-updates cycle, though!
>>>>>
>>>>> Other Guix users, please correct me if I'm wrong.
>>> According to the established guidelines, this should be OK for master
>>> since it affects <300 packages, so if all dependent packages build then
>>> I don't see why we shouldn't do that.
>>>
>>> https://lists.gnu.org/archive/html/guix-devel/2016-10/msg00933.html
>>
>> Cheers for your comments, very enlightening!  I'm afraid I'm out of my
>> depth making this decision here.  I'm happy to let my computer rebuild
>> those 200 packages to see whether the dependent packages build — but
>> I'm not sure how I would go about testing that.  See below for a theory…?
>>
>>>> Thanks for the review!
>>>>
>>>> What command do you use to check the number of packages that would have
>>>> to be rebuilt?  I'm asking, because if they are mainly perl libraries
>>>> then that figure of 200 really isn't that big of a deal: most perl libs
>>>> build super fast.
>>> To check the number of packages use "guix refresh -l"
>>
>> Interesting… so to establish the packages to be rebuilt as a result of
>> my patch series, would that be:
>>
>> guix refresh -l perl-scalar-list-utils perl-parse-cpan-meta  \
>> perl-cpan-meta-requirements perl-yaml perl-variable-magic\
>> perl-time-duration-parse perl-test-warnings perl-test-simple \
>> perl-test-exception perl-test-cleannamespaces perl-sub-name  \
>> perl-params-validate perl-package-deprecationmanager perl-moose  \
>> perl-module-runtime-conflicts perl-devel-partialdump \
>> perl-devel-overloadinfo perl-cpan-meta-check perl-common-sense   \
>> perl-clone perl-class-load perl-capture-tiny perl-b-hooks-endofscope
>>
>> Building the following 24 packages would ensure 248 dependent packages
>> are rebuilt: edirect-4.10 perl-modern-perl-1.20150127
>> perl-text-neattemplate-0.1101 perl-encode-detect-1.01
>> perl-list-someutils-0.52 perl-db-file-1.838 pam-krb5-4.7
>> perl-test-trailingspace-0.0300 sslh-1.18 perl-mail-spf-v2.9.0
>> gerbv-2.6.1 netsurf-3.6 perl-config-ini-0.025 perl-anyevent-i3-0.16
>> tophat-2.1.0 perl-test-class-most-0.08 gnucash-2.6.15 surfraw-2.2.9
>> biber-2.5 biber-next-2.6 stow-2.2.2 perl-x11-xcb-0.16 roary-3.7.0
>> hydra-20151030.1ff48da
>>
>> Does this mean, that in order to test this I would now simply try to
>> rebuild the 24 listed packages?
>
> Yes. Just make sure you use `./pre-inst-env guix build` so that you're
> testing the updated perl packages. Thanks!
>
>>
>> Cheers,
>>
>> Alex

Re: [PATCH 01/26] gnu: Add perl-file-pushd.

[Alex Sassmannshausen]

Hi Ben,

Ben Woodcroft writes:

> Hi,
>
>
> On 24/03/17 18:13, Alex Sassmannshausen wrote:
>> Hi Kei,
>>
>> Kei Kebreau writes:
>>
>>> This series of packages builds and lints fine for me. There are over 200
>>> dependent packages that would have to be rebuilt though, and
>>> core-updates is frozen to my knowledge. We can save this for the next
>>> core-updates cycle, though!
>>>
>>> Other Guix users, please correct me if I'm wrong.
> According to the established guidelines, this should be OK for master
> since it affects <300 packages, so if all dependent packages build then
> I don't see why we shouldn't do that.
>
> https://lists.gnu.org/archive/html/guix-devel/2016-10/msg00933.html

Cheers for your comments, very enlightening!  I'm afraid I'm out of my
depth making this decision here.  I'm happy to let my computer rebuild
those 200 packages to see whether the dependent packages build — but
I'm not sure how I would go about testing that.  See below for a theory…?

>> Thanks for the review!
>>
>> What command do you use to check the number of packages that would have
>> to be rebuilt?  I'm asking, because if they are mainly perl libraries
>> then that figure of 200 really isn't that big of a deal: most perl libs
>> build super fast.
> To check the number of packages use "guix refresh -l"

Interesting… so to establish the packages to be rebuilt as a result of
my patch series, would that be:

guix refresh -l perl-scalar-list-utils perl-parse-cpan-meta  \
perl-cpan-meta-requirements perl-yaml perl-variable-magic\
perl-time-duration-parse perl-test-warnings perl-test-simple \
perl-test-exception perl-test-cleannamespaces perl-sub-name  \
perl-params-validate perl-package-deprecationmanager perl-moose  \
perl-module-runtime-conflicts perl-devel-partialdump \
perl-devel-overloadinfo perl-cpan-meta-check perl-common-sense   \
perl-clone perl-class-load perl-capture-tiny perl-b-hooks-endofscope

Building the following 24 packages would ensure 248 dependent packages
are rebuilt: edirect-4.10 perl-modern-perl-1.20150127
perl-text-neattemplate-0.1101 perl-encode-detect-1.01
perl-list-someutils-0.52 perl-db-file-1.838 pam-krb5-4.7
perl-test-trailingspace-0.0300 sslh-1.18 perl-mail-spf-v2.9.0
gerbv-2.6.1 netsurf-3.6 perl-config-ini-0.025 perl-anyevent-i3-0.16
tophat-2.1.0 perl-test-class-most-0.08 gnucash-2.6.15 surfraw-2.2.9
biber-2.5 biber-next-2.6 stow-2.2.2 perl-x11-xcb-0.16 roary-3.7.0
hydra-20151030.1ff48da

Does this mean, that in order to test this I would now simply try to
rebuild the 24 listed packages?

Cheers,

Alex

Re: [PATCH 01/26] gnu: Add perl-file-pushd.

[Alex Sassmannshausen]

Hi Kei,

Kei Kebreau writes:

> Alex Sassmannshausen <alex.sassmannshau...@gmail.com> writes:
>
>> * gnu/packages/perl.scm (perl-file-pushd): New variable
>> ---
>>  gnu/packages/perl.scm | 28 
>>  1 file changed, 28 insertions(+)
>>
>> diff --git a/gnu/packages/perl.scm b/gnu/packages/perl.scm
>> index 086e1fae0..4944ceb2a 100644
>> --- a/gnu/packages/perl.scm
>> +++ b/gnu/packages/perl.scm
>> @@ -3002,6 +3002,34 @@ of arbitrary depth and to delete an entire directory 
>> subtree from the
>>  file system.")
>>  (license (package-license perl
>>  
>> +(define-public perl-file-pushd
>> +  (package
>> +(name "perl-file-pushd")
>> +(version "1.014")
>> +(source
>> + (origin
>> +   (method url-fetch)
>> +   (uri (string-append
>> + "mirror://cpan/authors/id/D/DA/DAGOLDEN/File-pushd-"
>> + version
>> + ".tar.gz"))
>> +   (sha256
>> +(base32
>> + "02rlqvyy7gly3dsqwaa81aisyy9c791b8xvwzczcbgmcwgzkgaxm"
>> +(build-system perl-build-system)
>> +(home-page
>> + "http://search.cpan.org/dist/File-pushd;)
>> +(synopsis
>> + "Change directory temporarily for a limited scope")
>> +(description "@code{File::pushd} does a temporary @code{chdir} that is
>> +easily and automatically reverted, similar to @code{pushd} in some Unix
>> +command shells.  It works by creating an object that caches the original
>> +working directory.  When the object is destroyed, the destructor calls
>> +@code{chdir} to revert to the original working directory.  By storing the
>> +object in a lexical variable with a limited scope, this happens 
>> automatically
>> +at the end of the scope.")
>> +(license asl2.0)))
>> +
>>  (define-public perl-file-list
>>(package
>>  (name "perl-file-list")
>
> This series of packages builds and lints fine for me. There are over 200
> dependent packages that would have to be rebuilt though, and
> core-updates is frozen to my knowledge. We can save this for the next
> core-updates cycle, though!
>
> Other Guix users, please correct me if I'm wrong.

Thanks for the review!

What command do you use to check the number of packages that would have
to be rebuilt?  I'm asking, because if they are mainly perl libraries
then that figure of 200 really isn't that big of a deal: most perl libs
build super fast.

Ta,

Alex

[PATCH 18/26] gnu: perl-test-simple: Update to 1.302078.

[Alex Sassmannshausen]

* gnu/packages/perl.scm (perl-test-simple): Update to 1.302078.
---
 gnu/packages/perl.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/perl.scm b/gnu/packages/perl.scm
index c0ae3ea2c..e007f0cac 100644
--- a/gnu/packages/perl.scm
+++ b/gnu/packages/perl.scm
@@ -6973,14 +6973,14 @@ makes fork(2) safe to use in test cases.")
 (define-public perl-test-simple
   (package
 (name "perl-test-simple")
-(version "1.302062")
+(version "1.302078")
 (source (origin
   (method url-fetch)
   (uri (string-append "mirror://cpan/authors/id/E/EX/EXODIST/"
   "Test-Simple-" version ".tar.gz"))
   (sha256
(base32
-"1sjny65iwnin35lvc203pb07gyx9wrp3gmn6lfrjsbmi986hcab7"
+"05acl24kmz3dgr2nayy162yaf0kz92h1j5vkiavyv6mdh2lz6ixb"
 (build-system perl-build-system)
 (synopsis "Basic utilities for writing tests")
 (description
-- 
2.11.1

[PATCH 21/26] gnu: perl-variable-magic: Update to 0.61.

[Alex Sassmannshausen]

* gnu/packages/perl.scm (perl-variable-magic): Update to 0.61.
---
 gnu/packages/perl.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/perl.scm b/gnu/packages/perl.scm
index 5eb5e8992..3752f5679 100644
--- a/gnu/packages/perl.scm
+++ b/gnu/packages/perl.scm
@@ -7841,7 +7841,7 @@ UNIVERSAL::isa as a function.")
 (define-public perl-variable-magic
   (package
 (name "perl-variable-magic")
-(version "0.55")
+(version "0.61")
 (source
  (origin
(method url-fetch)
@@ -7849,7 +7849,7 @@ UNIVERSAL::isa as a function.")
"Variable-Magic-" version ".tar.gz"))
(sha256
 (base32
- "0xzh2vy45ph80bp09j5fcjy8ydgn8yaxsa0fj831q6p1spvyniwg"
+ "1mx6z36c3wk61x6lag6kyws5g1cba68cw20vrb92wan7ahpfkbxq"
 (build-system perl-build-system)
 (home-page "http://search.cpan.org/dist/Variable-Magic;)
 (synopsis "Associate user-defined magic to variables from Perl")
-- 
2.11.1

[PATCH 20/26] gnu: perl-time-duration-parse: Update to 0.13.

[Alex Sassmannshausen]

* gnu/packages/perl.scm (perl-time-duration-parse): Update to 0.13.
---
 gnu/packages/perl.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/perl.scm b/gnu/packages/perl.scm
index 5c6525c22..5eb5e8992 100644
--- a/gnu/packages/perl.scm
+++ b/gnu/packages/perl.scm
@@ -7538,7 +7538,7 @@ rounded or exact terms.")
 (define-public perl-time-duration-parse
   (package
 (name "perl-time-duration-parse")
-(version "0.11")
+(version "0.13")
 (source
  (origin
(method url-fetch)
@@ -7546,7 +7546,7 @@ rounded or exact terms.")
"Time-Duration-Parse-" version ".tar.gz"))
(sha256
 (base32
- "1yk4cqkldwzkfy9y9ngqrj7p7sbsrsfa26mrm8f70z5n5m8q31x0"
+ "0affdzhsiy7dr6dzj2p6m9lynmjh53k31bprfsfa21pz8551hjj1"
 (build-system perl-build-system)
 (native-inputs
  `(("perl-time-duration" ,perl-time-duration)))
-- 
2.11.1

[PATCH 12/26] gnu: perl-moose: Update to 2.2004.

[Alex Sassmannshausen]

* gnu/packages/perl.scm (perl-moose): Update to 2.2004.
---
 gnu/packages/perl.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/perl.scm b/gnu/packages/perl.scm
index f702dff73..fd8a66d4c 100644
--- a/gnu/packages/perl.scm
+++ b/gnu/packages/perl.scm
@@ -4446,14 +4446,14 @@ Moose and is optimised for rapid startup.")
 (define-public perl-moose
   (package
 (name "perl-moose")
-(version "2.1403")
+(version "2.2004")
 (source (origin
   (method url-fetch)
   (uri (string-append "mirror://cpan/authors/id/E/ET/ETHER/"
   "Moose-" version ".tar.gz"))
   (sha256
(base32
-"16iaazikbnq2jjjac84jrdpfzm4qwqg1nbfgs11jlwn84q4jp1n3"
+"1c6jx2lnrh2mi9wlj2c0sirj6345xmbpr34ax8d85mcginzq3j74"
 (build-system perl-build-system)
 (native-inputs
  `(("perl-cpan-meta-check" ,perl-cpan-meta-check)
-- 
2.11.1

[PATCH 09/26] gnu: perl-devel-overloadinfo: Update to 0.004.

[Alex Sassmannshausen]

* gnu/packages/perl.scm (perl-devel-overloadinfo): Update to 0.004.
---
 gnu/packages/perl.scm | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/perl.scm b/gnu/packages/perl.scm
index 7cdb610c0..0a8359729 100644
--- a/gnu/packages/perl.scm
+++ b/gnu/packages/perl.scm
@@ -2285,7 +2285,7 @@ variable in a subroutines scope to one of your choosing.")
 (define-public perl-devel-overloadinfo
   (package
 (name "perl-devel-overloadinfo")
-(version "0.002")
+(version "0.004")
 (source
  (origin
(method url-fetch)
@@ -2293,8 +2293,10 @@ variable in a subroutines scope to one of your 
choosing.")
"Devel-OverloadInfo-" version ".tar.gz"))
(sha256
 (base32
- "14gzjlsqhypqp0szqj6152qfn69snzydgk1yk6bji5zimzv86qyy"
+ "0zckjhzdqa6smpp98y15mqafsyzwjxwrvk10snzhn2sb0r889s43"
 (build-system perl-build-system)
+(native-inputs
+ `(("perl-test-fatal" ,perl-test-fatal)))
 (propagated-inputs
  `(("perl-package-stash" ,perl-package-stash)
("perl-sub-identify" ,perl-sub-identify)
-- 
2.11.1

[PATCH 24/26] gnu: perl-cpan-meta-yaml: Update to 0.018.

[Alex Sassmannshausen]

* gnu/packages/perl.scm (perl-cpan-meta-yaml): Update to 0.018.
---
 gnu/packages/perl.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/perl.scm b/gnu/packages/perl.scm
index c6c3a9f06..235bafc32 100644
--- a/gnu/packages/perl.scm
+++ b/gnu/packages/perl.scm
@@ -8035,7 +8035,7 @@ representation.")
 (define-public perl-cpan-meta-yaml
   (package
 (name "perl-cpan-meta-yaml")
-(version "0.012")
+(version "0.018")
 (source
  (origin
(method url-fetch)
@@ -8043,7 +8043,7 @@ representation.")
"CPAN-Meta-YAML-" version ".tar.gz"))
(sha256
 (base32
- "0a0d62w8d81kkas4j1h48znk0f0vrpibl31gvz9r8hm77dbqqwkw"
+ "150jh9l7baddl2587m23qs2l0pb395qsx9bhsgdsnn6y9k4zgjik"
 (build-system perl-build-system)
 (arguments
  `(#:tests? #f));Tests require Test::More >= 0.99
-- 
2.11.1

[PATCH 26/26] gnu: perl-scalar-list-utils: Update to 1.47.

[Alex Sassmannshausen]

* gnu/packages/perl.scm (perl-scalar-list-utils): Update to 1.47.
---
 gnu/packages/perl.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/perl.scm b/gnu/packages/perl.scm
index 1882ececa..82c4ef5d1 100644
--- a/gnu/packages/perl.scm
+++ b/gnu/packages/perl.scm
@@ -8105,7 +8105,7 @@ files, using JSON::PP and/or CPAN::Meta::YAML.")
 (define-public perl-scalar-list-utils
   (package
 (name "perl-scalar-list-utils")
-(version "1.41")
+(version "1.47")
 (source
  (origin
(method url-fetch)
@@ -8113,7 +8113,7 @@ files, using JSON::PP and/or CPAN::Meta::YAML.")
"Scalar-List-Utils-" version ".tar.gz"))
(sha256
 (base32
- "04l1q4hps9n8b1hk9kpgpc1cryim7pl9sfdyb7fz5nq4gmz307j7"
+ "1qgg6zxqwziva5j1k5gjks4xmhmgklm551ni3zb74sd9f9rk90y4"
 (build-system perl-build-system)
 (home-page "http://search.cpan.org/dist/Scalar-List-Utils;)
 (synopsis "Common Scalar and List utility subroutines")
-- 
2.11.1

[PATCH 10/26] gnu: perl-devel-partialdump: Update to 0.18.

[Alex Sassmannshausen]

* gnu/packages/perl.scm (perl-devel-partialdump): Update to 0.18.
---
 gnu/packages/perl.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/perl.scm b/gnu/packages/perl.scm
index 0a8359729..d3f14a8a0 100644
--- a/gnu/packages/perl.scm
+++ b/gnu/packages/perl.scm
@@ -2311,7 +2311,7 @@ hierarchy the overloads are declared and where the code 
implementing it is.")
 (define-public perl-devel-partialdump
   (package
 (name "perl-devel-partialdump")
-(version "0.17")
+(version "0.18")
 (source
  (origin
(method url-fetch)
@@ -2319,7 +2319,7 @@ hierarchy the overloads are declared and where the code 
implementing it is.")
"Devel-PartialDump-" version ".tar.gz"))
(sha256
 (base32
- "0nr3qa68x4yp219kd17j1ks9c95qc9agfvz7ddnpn8p78f3kgwfn"
+ "0i1khiyi4h4h8vfwn7xip5c53z2hb2rk6407f3csvrdsiibvy53q"
 (build-system perl-build-system)
 (native-inputs
  `(("perl-module-build-tiny" ,perl-module-build-tiny)
-- 
2.11.1

[PATCH 22/26] gnu: perl-yaml: Update to 1.23.

[Alex Sassmannshausen]

* gnu/packages/perl.scm (perl-yaml): Update to 1.23.
---
 gnu/packages/perl.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/perl.scm b/gnu/packages/perl.scm
index 3752f5679..5ffe6d48a 100644
--- a/gnu/packages/perl.scm
+++ b/gnu/packages/perl.scm
@@ -7914,7 +7914,7 @@ neither visible nor modifiable from Perl space).")
 (define-public perl-yaml
   (package
 (name "perl-yaml")
-(version "1.14")
+(version "1.23")
 (source
  (origin
(method url-fetch)
@@ -7922,7 +7922,7 @@ neither visible nor modifiable from Perl space).")
"YAML-" version ".tar.gz"))
(sha256
 (base32
- "0sswbkyisgny7ksw34n7zdaxrhsbbn7dgjb9gjybpzhcnml476kc"
+ "0kf8mllrgnrmlvjijxc6srjj1y9i8rik5jpjvm8jh4yx70h9gn1a"
 (build-system perl-build-system)
 (native-inputs
  `(("perl-test-yaml" ,perl-test-yaml)))
-- 
2.11.1

[PATCH 25/26] gnu: perl-parse-cpan-meta: Update to 2.150010.

[Alex Sassmannshausen]

* gnu/packages/perl.scm (perl-parse-cpan-meta): Update to 2.150010.
---
 gnu/packages/perl.scm | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/gnu/packages/perl.scm b/gnu/packages/perl.scm
index 235bafc32..1882ececa 100644
--- a/gnu/packages/perl.scm
+++ b/gnu/packages/perl.scm
@@ -8083,15 +8083,16 @@ system---most of the @code{Module::Build} code is 
pure-Perl.")
 (define-public perl-parse-cpan-meta
   (package
 (name "perl-parse-cpan-meta")
-(version "1.4414")
+(version "2.150010")
 (source
  (origin
(method url-fetch)
+   ;; This module is now known as CPAN::Meta on CPAN.
(uri (string-append "mirror://cpan/authors/id/D/DA/DAGOLDEN/"
-   "Parse-CPAN-Meta-" version ".tar.gz"))
+   "CPAN-Meta-" version ".tar.gz"))
(sha256
 (base32
- "06ya2rg599qanqb1fxiyrd489mvmdgzbw4ph23hwjwpv9lahhxnd"
+ "1mm3dfw3ffyzb2ikpqn9l6zyqrxijb4vyywmbx2l21ryqwp0zy74"
 (build-system perl-build-system)
 (propagated-inputs
  `(("perl-cpan-meta-yaml" ,perl-cpan-meta-yaml)))
-- 
2.11.1

[PATCH 19/26] gnu: perl-test-warnings: Update to 0.026.

[Alex Sassmannshausen]

* gnu/packages/perl.scm (perl-test-warnings): Update to 0.026.
---
 gnu/packages/perl.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/perl.scm b/gnu/packages/perl.scm
index e007f0cac..5c6525c22 100644
--- a/gnu/packages/perl.scm
+++ b/gnu/packages/perl.scm
@@ -7081,7 +7081,7 @@ warning based code.")
 (define-public perl-test-warnings
   (package
 (name "perl-test-warnings")
-(version "0.020")
+(version "0.026")
 (source
  (origin
(method url-fetch)
@@ -7089,7 +7089,7 @@ warning based code.")
"Test-Warnings-" version ".tar.gz"))
(sha256
 (base32
- "1x262kybrdnbiiw53m1axp4zyh4lsfb9mm2shmpm8lwf7sp30isi"
+ "024srkwjckp15dxkni9lb1hc8bg4xwc52zz0iich8rv1nnqnhaxf"
 (build-system perl-build-system)
 (home-page "http://search.cpan.org/dist/Test-Warnings;)
 (synopsis "Test for warnings and the lack of them")
-- 
2.11.1

[PATCH 13/26] gnu: perl-package-deprecationmanager: Update to 0.17.

[Alex Sassmannshausen]

* gnu/packages/perl.scm (perl-package-deprecationmanager): Update to 0.17.
---
 gnu/packages/perl.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/perl.scm b/gnu/packages/perl.scm
index fd8a66d4c..418a25e7c 100644
--- a/gnu/packages/perl.scm
+++ b/gnu/packages/perl.scm
@@ -5257,7 +5257,7 @@ instance, not by name.")
 (define-public perl-package-deprecationmanager
   (package
 (name "perl-package-deprecationmanager")
-(version "0.13")
+(version "0.17")
 (source
  (origin
(method url-fetch)
@@ -5265,7 +5265,7 @@ instance, not by name.")
"Package-DeprecationManager-" version ".tar.gz"))
(sha256
 (base32
- "0fkvq3xxwc3l5hg64dr9sj3l12dl59i44cg407qx9sd6r51j3qfi"
+ "0jv8svfh1c1q4vxlkf8vjfbdq3n2sj3nx5llv1qrhp1b93d3lx0x"
 (build-system perl-build-system)
 (native-inputs
  `(("perl-test-fatal" ,perl-test-fatal)
-- 
2.11.1

[PATCH 23/26] gnu: perl-cpan-meta-requirements: Update to 2.140.

[Alex Sassmannshausen]

* gnu/packages/perl.scm (perl-cpan-meta-requirements): Update to 2.140.
---
 gnu/packages/perl.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/perl.scm b/gnu/packages/perl.scm
index 5ffe6d48a..c6c3a9f06 100644
--- a/gnu/packages/perl.scm
+++ b/gnu/packages/perl.scm
@@ -8013,7 +8013,7 @@ methods for interrogating that data.")
 (define-public perl-cpan-meta-requirements
   (package
 (name "perl-cpan-meta-requirements")
-(version "2.131")
+(version "2.140")
 (source
  (origin
(method url-fetch)
@@ -8021,7 +8021,7 @@ methods for interrogating that data.")
"CPAN-Meta-Requirements-" version ".tar.gz"))
(sha256
 (base32
- "12p5s7w3cwcrbpcrxzanvpr0syswhwlqzbaki6m044c45jix2fss"
+ "1a8zflgaayycmn3zvd3n64yypa4jyl1va0h51wpr5w46irg69608"
 (build-system perl-build-system)
 (home-page "http://search.cpan.org/dist/CPAN-Meta-Requirements;)
 (synopsis "Set of version requirements for a CPAN dist")
-- 
2.11.1

[PATCH 05/26] gnu: perl-class-load: Update to 0.23.

[Alex Sassmannshausen]

* gnu/packages/perl.scm (perl-class-load): Update to 0.23.
---
 gnu/packages/perl.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/perl.scm b/gnu/packages/perl.scm
index fef17bbd0..179e3d1f1 100644
--- a/gnu/packages/perl.scm
+++ b/gnu/packages/perl.scm
@@ -973,7 +973,7 @@ loaded class.")
 (define-public perl-class-load
   (package
 (name "perl-class-load")
-(version "0.22")
+(version "0.23")
 (source
  (origin
(method url-fetch)
@@ -981,7 +981,7 @@ loaded class.")
"Class-Load-" version ".tar.gz"))
(sha256
 (base32
- "049i285yj8hwgzj7nncjbs2bhxvpdk88wmx1d0nh0rdmh5hdnlmy"
+ "13xjfh4fadq4pkq7fcj42b26544jl7gqdg2y3imnra9fwxwsbg7j"
 (build-system perl-build-system)
 (native-inputs
  `(("perl-module-build-tiny" ,perl-module-build-tiny)
-- 
2.11.1

[PATCH 17/26] gnu: perl-test-exception: Update to 0.43.

[Alex Sassmannshausen]

* gnu/packages/perl.scm (perl-test-exception): Update to 0.43.
---
 gnu/packages/perl.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/perl.scm b/gnu/packages/perl.scm
index cf02cad66..c0ae3ea2c 100644
--- a/gnu/packages/perl.scm
+++ b/gnu/packages/perl.scm
@@ -6528,7 +6528,7 @@ files, as well as to verify that there are no missing or 
unknown files.")
 (define-public perl-test-exception
   (package
 (name "perl-test-exception")
-(version "0.36")
+(version "0.43")
 (source
  (origin
(method url-fetch)
@@ -6536,7 +6536,7 @@ files, as well as to verify that there are no missing or 
unknown files.")
"Test-Exception-" version ".tar.gz"))
(sha256
 (base32
- "1zpwimspbq11wjrli481qk17aabzxab15cnnryflx45nzn3za2xk"
+ "0cxm7s4bg0xpxa6l6996a6iq3brr4j7p4hssnkc6dxv4fzq16sqm"
 (build-system perl-build-system)
 (native-inputs
  `(("perl-module-build" ,perl-module-build)))
-- 
2.11.1

[PATCH 16/26] gnu: perl-test-cleannamespaces: Update to 0.22.

[Alex Sassmannshausen]

* gnu/packages/perl.scm (perl-test-cleannamespaces): Update to 0.22.
---
 gnu/packages/perl.scm | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/gnu/packages/perl.scm b/gnu/packages/perl.scm
index 90f0d386c..cf02cad66 100644
--- a/gnu/packages/perl.scm
+++ b/gnu/packages/perl.scm
@@ -6420,7 +6420,7 @@ using @code{Test::Class}.")
 (define-public perl-test-cleannamespaces
   (package
 (name "perl-test-cleannamespaces")
-(version "0.16")
+(version "0.22")
 (source
  (origin
(method url-fetch)
@@ -6428,13 +6428,15 @@ using @code{Test::Class}.")
"Test-CleanNamespaces-" version ".tar.gz"))
(sha256
 (base32
- "1ynrds515gcq954z34zm03rgcx0dskiaz7qj0k7k5gmrjj1kfycp"
+ "1jma95agqqy7iwdcl6jbg1waqz7mjqng4l046lpknhfxjhcj4al6"
 (build-system perl-build-system)
 (native-inputs
- `(("perl-test-requires" ,perl-test-requires)
+ `(("perl-file-pushd" ,perl-file-pushd)
+   ("perl-test-requires" ,perl-test-requires)
("perl-test-deep" ,perl-test-deep)
("perl-test-warnings" ,perl-test-warnings)
-   ("perl-test-tester" ,perl-test-tester)))
+   ("perl-test-tester" ,perl-test-tester)
+   ("perl-test-needs" ,perl-test-needs)))
 (propagated-inputs
  `(("perl-namespace-clean" ,perl-namespace-clean)
("perl-package-stash" ,perl-package-stash)
-- 
2.11.1

[PATCH 14/26] gnu: perl-params-validate: Update to 1.26.

[Alex Sassmannshausen]

* gnu/packages/perl.scm (perl-params-validate): Update to 1.26.
---
 gnu/packages/perl.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/perl.scm b/gnu/packages/perl.scm
index 418a25e7c..f77d7a297 100644
--- a/gnu/packages/perl.scm
+++ b/gnu/packages/perl.scm
@@ -5405,7 +5405,7 @@ checking parameters easier.")
 (define-public perl-params-validate
   (package
 (name "perl-params-validate")
-(version "1.17")
+(version "1.26")
 (source
  (origin
(method url-fetch)
@@ -5413,7 +5413,7 @@ checking parameters easier.")
"Params-Validate-" version ".tar.gz"))
(sha256
 (base32
- "1wh23i9kkma6493c0q1kvy6wmahd6spg6xm3xbp2ar1iy1xhks5l"
+ "1vbj78qd46ip09i06dsbb62jfwpzp4bg7yi617v98nvim77w66l2"
 (build-system perl-build-system)
 (native-inputs
  `(("perl-module-build" ,perl-module-build)
-- 
2.11.1

[PATCH 06/26] gnu: perl-clone: Update to 0.38.

[Alex Sassmannshausen]

* gnu/packages/perl.scm (perl-clone): Update to 0.38.
---
 gnu/packages/perl.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/perl.scm b/gnu/packages/perl.scm
index 179e3d1f1..16b53adef 100644
--- a/gnu/packages/perl.scm
+++ b/gnu/packages/perl.scm
@@ -1154,14 +1154,14 @@ arrays for their internal representation.")
 (define-public perl-clone
   (package
 (name "perl-clone")
-(version "0.37")
+(version "0.38")
 (source (origin
   (method url-fetch)
   (uri (string-append "mirror://cpan/authors/id/G/GA/GARU/"
   "Clone-" version ".tar.gz"))
   (sha256
(base32
-"17fdhxpzrq2nwim3zkcrz4m9gjixp0i886yz54ysrshxy3k53wnr"
+"1s5xrv9zlckqqzyhxi0l9lwj9m6na2bz5hqxrkva2v7gnx5m7c4z"
 (build-system perl-build-system)
 (synopsis "Recursively copy Perl datatypes")
 (description
-- 
2.11.1

[PATCH 07/26] gnu: perl-common-sense: Update to 3.74.

[Alex Sassmannshausen]

* gnu/packages/perl.scm (perl-common-sense): Update to 3.74.
---
 gnu/packages/perl.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/perl.scm b/gnu/packages/perl.scm
index 16b53adef..d63614e2a 100644
--- a/gnu/packages/perl.scm
+++ b/gnu/packages/perl.scm
@@ -1175,7 +1175,7 @@ objects.")
 (define-public perl-common-sense
   (package
 (name "perl-common-sense")
-(version "3.73")
+(version "3.74")
 (source
  (origin
(method url-fetch)
@@ -1183,7 +1183,7 @@ objects.")
"common-sense-" version ".tar.gz"))
(sha256
 (base32
- "047xwgpn5611zrhk4c8vk9pzcbk1q7n3q0lfiwhhq7k4fbjca441"
+ "1wxv2s0hbjkrnssvxvsds0k213awg5pgdlrpkr6xkpnimc17s7vp"
 (build-system perl-build-system)
 (home-page "http://search.cpan.org/dist/common-sense;)
 (synopsis "Sane defaults for Perl programs")
-- 
2.11.1

[PATCH 08/26] gnu: perl-cpan-meta-check: Update to 0.011.

[Alex Sassmannshausen]

* gnu/packages/perl.scm (perl-cpan-meta-check): Update to 0.011.
---
 gnu/packages/perl.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/perl.scm b/gnu/packages/perl.scm
index d63614e2a..7cdb610c0 100644
--- a/gnu/packages/perl.scm
+++ b/gnu/packages/perl.scm
@@ -1307,7 +1307,7 @@ the caller.")
 (define-public perl-cpan-meta-check
   (package
 (name "perl-cpan-meta-check")
-(version "0.009")
+(version "0.011")
 (source
  (origin
(method url-fetch)
@@ -1315,7 +1315,7 @@ the caller.")
"CPAN-Meta-Check-" version ".tar.gz"))
(sha256
 (base32
- "0qbk5dwvhd78qgq5x6nim2n0l78pylvlklpbrm56w9yss6pl6bgb"
+ "0nxi0xhhd3dwhgri3l8z8gpz2ibvhm5k7jjls8xmnlh0v84p04kh"
 (build-system perl-build-system)
 (native-inputs `(("perl-test-deep" ,perl-test-deep)))
 (propagated-inputs `(("perl-cpan-meta" ,perl-cpan-meta)))
-- 
2.11.1

[PATCH 11/26] gnu: perl-module-runtime-conflicts: Update to 0.003.

[Alex Sassmannshausen]

* gnu/packages/perl.scm (perl-module-runtime-conflicts): Update to 0.003.
---
 gnu/packages/perl.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/perl.scm b/gnu/packages/perl.scm
index d3f14a8a0..f702dff73 100644
--- a/gnu/packages/perl.scm
+++ b/gnu/packages/perl.scm
@@ -4346,7 +4346,7 @@ handling of Perl modules, which are normally handled at 
compile time.")
 (define-public perl-module-runtime-conflicts
   (package
 (name "perl-module-runtime-conflicts")
-(version "0.001")
+(version "0.003")
 (source
  (origin
(method url-fetch)
@@ -4354,7 +4354,7 @@ handling of Perl modules, which are normally handled at 
compile time.")
"Module-Runtime-Conflicts-" version ".tar.gz"))
(sha256
 (base32
- "0pz23ch78lbpn4kdbm04icgsmbr7jvmxwq1p5m4x2pap8qwd0wqg"
+ "0x9qfg4pq70v1rl9dfk775fmca7ia308m24vfy8zww4c0dsxqz3h"
 (build-system perl-build-system)
 (native-inputs
  `(("perl-module-build" ,perl-module-build)))
-- 
2.11.1

[PATCH 15/26] gnu: perl-sub-name: Update to 0.21.

[Alex Sassmannshausen]

* gnu/packages/perl.scm (perl-sub-name): Update to 0.21.
---
 gnu/packages/perl.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/perl.scm b/gnu/packages/perl.scm
index f77d7a297..90f0d386c 100644
--- a/gnu/packages/perl.scm
+++ b/gnu/packages/perl.scm
@@ -6027,7 +6027,7 @@ can see them.")
 (define-public perl-sub-name
   (package
 (name "perl-sub-name")
-(version "0.12")
+(version "0.21")
 (source
  (origin
(method url-fetch)
@@ -6035,7 +6035,7 @@ can see them.")
"Sub-Name-" version ".tar.gz"))
(sha256
 (base32
- "1sdlc8pv7vyyc48gzh70hbwzn0hzwl3zbcy2dkmfw8vjzgya5i06"
+ "05viq8scqk29g964fsfvls2rhvlb8myz3jblwh5c2ivhw3gfjcmx"
 (build-system perl-build-system)
 (native-inputs
  `(("perl-devel-checkbin" ,perl-devel-checkbin)))
-- 
2.11.1

[PATCH 01/26] gnu: Add perl-file-pushd.

[Alex Sassmannshausen]

* gnu/packages/perl.scm (perl-file-pushd): New variable
---
 gnu/packages/perl.scm | 28 
 1 file changed, 28 insertions(+)

diff --git a/gnu/packages/perl.scm b/gnu/packages/perl.scm
index 086e1fae0..4944ceb2a 100644
--- a/gnu/packages/perl.scm
+++ b/gnu/packages/perl.scm
@@ -3002,6 +3002,34 @@ of arbitrary depth and to delete an entire directory 
subtree from the
 file system.")
 (license (package-license perl
 
+(define-public perl-file-pushd
+  (package
+(name "perl-file-pushd")
+(version "1.014")
+(source
+ (origin
+   (method url-fetch)
+   (uri (string-append
+ "mirror://cpan/authors/id/D/DA/DAGOLDEN/File-pushd-"
+ version
+ ".tar.gz"))
+   (sha256
+(base32
+ "02rlqvyy7gly3dsqwaa81aisyy9c791b8xvwzczcbgmcwgzkgaxm"
+(build-system perl-build-system)
+(home-page
+ "http://search.cpan.org/dist/File-pushd;)
+(synopsis
+ "Change directory temporarily for a limited scope")
+(description "@code{File::pushd} does a temporary @code{chdir} that is
+easily and automatically reverted, similar to @code{pushd} in some Unix
+command shells.  It works by creating an object that caches the original
+working directory.  When the object is destroyed, the destructor calls
+@code{chdir} to revert to the original working directory.  By storing the
+object in a lexical variable with a limited scope, this happens automatically
+at the end of the scope.")
+(license asl2.0)))
+
 (define-public perl-file-list
   (package
 (name "perl-file-list")
-- 
2.11.1

[PATCH 04/26] gnu: perl-capture-tiny: Update to 0.46.

[Alex Sassmannshausen]

* gnu/packages/perl.scm (perl-capture-tiny): Update to 0.46.
---
 gnu/packages/perl.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/perl.scm b/gnu/packages/perl.scm
index 97655a646..fef17bbd0 100644
--- a/gnu/packages/perl.scm
+++ b/gnu/packages/perl.scm
@@ -603,7 +603,7 @@ algorithm to keep the most used entries in the cache.")
 (define-public perl-capture-tiny
   (package
 (name "perl-capture-tiny")
-(version "0.28")
+(version "0.46")
 (source
  (origin
(method url-fetch)
@@ -612,7 +612,7 @@ algorithm to keep the most used entries in the cache.")
  version ".tar.gz"))
(sha256
 (base32
- "117gmwipql1y5xnw9jil3lhdsrf2wsm9wjdzqj66x971n3fwm573"
+ "05bhlx6d4nzamhkkh0pkckg7wlvaq6mazf7q1fbb5wpp1j1nlyjx"
 (build-system perl-build-system)
 (home-page "http://search.cpan.org/dist/Capture-Tiny;)
 (synopsis "Capture STDOUT and STDERR from Perl, XS or external programs")
-- 
2.11.1

[PATCH 03/26] gnu: perl-b-hooks-endofscope: Update to 0.21.

[Alex Sassmannshausen]

* gnu/packages/perl.scm (perl-b-hooks-endofscope): Update to 0.21.
---
 gnu/packages/perl.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/perl.scm b/gnu/packages/perl.scm
index ce2c59e4c..97655a646 100644
--- a/gnu/packages/perl.scm
+++ b/gnu/packages/perl.scm
@@ -380,7 +380,7 @@ parent.")
 (define-public perl-b-hooks-endofscope
   (package
 (name "perl-b-hooks-endofscope")
-(version "0.13")
+(version "0.21")
 (source
  (origin
(method url-fetch)
@@ -388,7 +388,7 @@ parent.")
"B-Hooks-EndOfScope-" version ".tar.gz"))
(sha256
 (base32
- "1f5d0lbkwf23dfjn60g6fynmjhy5rxdyxcpdfb07srm73qpg2zpi"
+ "0b70vbpabsy9ia366k330cz1zbdyb1pwhb0l7j28pmpih045iwwh"
 (build-system perl-build-system)
 (propagated-inputs
  `(("perl-module-runtime" ,perl-module-runtime)
-- 
2.11.1

[PATCH 02/26] gnu: Add perl-test-needs.

[Alex Sassmannshausen]

* gnu/packages/perl.scm (perl-test-needs): New variable.
---
 gnu/packages/perl.scm | 28 
 1 file changed, 28 insertions(+)

diff --git a/gnu/packages/perl.scm b/gnu/packages/perl.scm
index 4944ceb2a..ce2c59e4c 100644
--- a/gnu/packages/perl.scm
+++ b/gnu/packages/perl.scm
@@ -6761,6 +6761,34 @@ functions, along with automatically turning on strict 
and warning and gives a
 bit more fine-grained control over test suites.")
 (license (package-license perl
 
+(define-public perl-test-needs
+  (package
+(name "perl-test-needs")
+(version "0.002005")
+(source
+ (origin
+   (method url-fetch)
+   (uri (string-append
+ "mirror://cpan/authors/id/H/HA/HAARG/Test-Needs-"
+ version
+ ".tar.gz"))
+   (sha256
+(base32
+ "16gkgpmr9hvkz382iaqd3500269lk2d44fqaw3dsrvc66nc36kss"
+(build-system perl-build-system)
+(home-page
+ "http://search.cpan.org/dist/Test-Needs;)
+(synopsis
+ "Skip tests when modules not available")
+(description "@code{Test::Needs} allows you to skip test scripts if
+modules are not available.  The requested modules will be loaded, and
+optionally have their versions checked.  If the module is missing, the test
+script will be skipped.  Modules that are found but fail to compile will exit
+with an error rather than skip.
+
+If used in a subtest, the remainder of the subtest will be skipped.")
+(license (package-license perl
+
 (define-public perl-test-nowarnings
   (package
 (name "perl-test-nowarnings")
-- 
2.11.1

Re: Being excellent to one another

[Alex Sassmannshausen]

Hello,

I'm trying to draw this thread to a close as I genuinely believe that
neither side intends malice:
- John genuinely does not see how his statements can very easily be
interpreted as highly disrespectful and even mocking
- myself and others genuinely do not want to bear down on individuals by
virtue of simple miscommunication.

John, I would suggest to you that when at least three independent
individuals read your paragraph in which you (as you confirmed to me) in
good faith tried to create an extreme example to confirm that you would
respect (though fallibly) other people's rights to define their own
identity, then that paragraph was perhaps unfortunately formulated.

An apology and clarification would resolve that matter.

By way of clarification from my side, the paragraph reads like you're
creating a ("humourous") hyperbolic example that is only tangentially
related to the real discussion at hand to begrudgingly admit that you
would be willing to respect other people's identities.

Perhaps in that light you can see how that statement might have
trivialised other people's experiences and have come across as
insulting?

It simply wasn't necessary to employ that rhetorical device — just
acknowledging that you might slip up at times, would have been
sufficient.  The rhetorical device turned your genuine sentiment into a
statement in which you seemed to accede and simultaniously implicitly
ridiculed those whom you were acceding to.

I also believe it is within this context that Ludo considered that you
were in breach of the code of conduct. Specifically the example related
to "Trolling or insulting/derogatory comments".

As I say, I do not believe you intended to troll.  I hope we can move on
from this thread now by way of agreeing concrete steps for the future.

I would request the following moving forward:
- That we respect people's self-identification (which includes
respecting their pronouns)
- That we accept the "Singular They" as a valid form of non-gendered
language in formal and informal communication (this does not mean *you*
have to use it if you don't want to, but at least don't derail other
people's advice that it is a valid form)

Could we leave it at this for now?

It would be cool if we could get explicit or at least silent agreement
(by no longer responding to the thread) on this thread from those
primarily involved.

Best wishes,

Alex

PS: As Ricardo points out in his email to this thread, the issues of
gender/sex, and more widely, identity are enormously complex & I agree
that we cannot resolve them here.  But we can come to a situation where
we treat each other in a way that is non-exclusionary.  Part of this
means that we will have conversations like these at irregular intervals
— precisely because these issues are not resolved in society at large,
they will bubble up here.

In the meantime I would encourage people who care about these subjects
to read up on feminist theory, trans politics & intersectional
politics.  These are big, complex topics — and no-one agrees with all
that is written, but I believe that we as a community would support most
of the issues raised in those contexts.

John Darrington writes:

> On Mon, Mar 20, 2017 at 04:49:13PM +0100, Ludovic Court??s wrote:
>
>  John, people have explained things at length already; you can re-read
>  the project???s code of conduct if in doubt.  This isn???t up for debate.
>  Please stop playing this game right now.
>
> Ludo,
>
> * I am not playing a game - I think this is very serious.
> * I have not breached the code of conduct (at your request I have just read
>   it again).
> * I am trying my *utmost* to act with restraint and consideration in the face
>   of persistent provocation.
> * I have said on several occasions that we should all agree to live with
>   our differences and let this thread stop.
>
> John

Re: Introducing ‘guix pack’

[Alex Sassmannshausen]

Excellent article, thanks for writing and sharing!

Alex


Ludovic Courtès writes:

> Hi again!
>
> I’ve written about ‘guix pack’ here:
>
>   https://gnu.org/s/guix/news/creating-bundles-with-guix-pack.html
>
> Thanks to rekado & jonsger on IRC for the quick review!
>
> Ludo’.

Re: Being excellent to one another

[Alex Sassmannshausen]

John Darrington writes:

> On Mon, Mar 20, 2017 at 11:17:28AM +0100, Alex Sassmannshausen wrote:
>
>  Perhaps we have to agree to disagree on singular they, but I hope we can
>  still agree on the following statements from my earlier email:
>
> I agree to a slightly edited version:
>
>  -
>  [...] sometimes there is not a simple solution, however :
>  - if you know someone has a preference for particular pronouns, use 
> those when
>refering to that person.
>  - don't use pronouns when *you know* the other person does not identify
>with them.
>  - if unsure, ask the person how he or she would like to be referenced.
>
>  If you make a mistake, an apology will show your intention was not 
> malicious.
>
>  In manuals we can just use "singular they",  or another non-gender 
> specific
>  form of reference.
>  -

In the end, when you communicate informally, there is no arbiter of what
you write, so, to be clear, the first part above is not some form of
official guideline — just thinking out loud of what it means to engage
respectfully in a public, anonymous space.  I believe you approach in a
similar vein, which I appreciate.

The problem with your above suggestion is that it leaves out the default
case:
How will you write emails to the list?  Will you assume a default "he"?
Or a default "she"?  And what about non-binary identifying people?   We
don't know who's sitting at the other end.

Also, in the context of a default "he" usage (which you may not do, you
mentioned in the past that you sometimes default to "she"), I'm
concerned that emails are archived: they become a written representation
of what our community is like — and I do not want our community to
reinforce in a written form, that "only boys hang out around Guix / are
geeks".

>  Alternatively it would be incumbent on you to provide an
>  alternative that is not just "I will bloody-mindedly stick to
>  gendering people when I don't know anything about them".
>
> It is this tendency to call any difference of opinion by terms such as
> "bloody-minded" which offends me  - I try not to take offence - but I find
> hard not to.  I'm sorry.

My intention was to call-back to my impression of other parts of this
conversation where it seemed you were point-blank refusing to
acknowledge ng0's request.

But I can accept that you may find that an unfair characterisation, and
I phrased my sentiment too sharply in this case. My apologies for this.

> To answer your question:  How about saying "he or she" or "the person".

As mentioned above, the first renders non-binary identifying people
invisible.  For the second, if you can write a section of a manual using
"the person" in such a way that it won't sound clumsy, then by all
means.

Personally I would still suggest that "they/them/their" is wonderfully
short, to the point and unambiguous.  Also, it's a wheel that was
already invented: it has widespread usage outside of our community.

>  In the formal context, well??? I think there is broad consensus that
>  "singular they" is awesome.
>
> There is a broad concensus that Donald Trump, Rodrigo Duterte and
> Recep Erdogan are awesome.However I do not agree.

Say whaat?  Way to blow our discussion out of proportion.  Are you
seriously suggesting the consensus established through conversation and
convention in a small community is in any way comparable to the pile of
dung that is the contemporary ridiculously complex and terrifyingly
non-egalitarian state of global authoritarian politics?

>  > People having been talking about being "welcoming".  Well, I beleive 
> the way
>  > to achieve that is threefold:
>  >
>  > 1. Try not to offend.
>  > 2. Try not to be offended.
>  > 3. Recognise that diversity is an asset.
>
>  Absolutely, wonderful sentiment.  To that I would add:
>
>  4. Respect the integrity and right to self-definition of all participants
>
> I agree.  Put that one in too.

Nice :-)

>From my perspective, I'm probably done with this conversation for now,
though will respond if specific queries are addressed at me.

Alex

Re: Being excellent to one another

[Alex Sassmannshausen]

John Darrington writes:

> On Mon, Mar 20, 2017 at 09:57:04AM +0100, Alex Sassmannshausen wrote:
>  >
>  > ... and yes.  If an individual specifically requests to be referred to 
> by
>  > a partcular set of pronouns I will attempt to do so, but may 
> occasionally
>  > forget if that person wants feminine pronouns and is 6'4" and has an 
> enormous
>  > black wiry beard.
>  
>  [I really don't know what your intention is with that last paragraph ??? 
> I
>  will just ignore it, as I wouldn't want to ascribe malice???]
>
> OMG! What is wrong here?  Why would you (or anyone) think this is malicious?  
> The 
> intention, which I thought was clear, is that if people make unusual requests
> we should try to accommodate those requests, but the requestor should not be
> suprised or offended if people don't always remember.  Surely that was 
> obvious?

Not obvious at all, thanks for the clarification.

> [...]
>
> Regarding your other comments,  as we have discussed before, we will have to
> agree to disagree about singular they.   I have not the benefit of ever 
> having learned English as a foreign language.  But I do remember in my 
> elementary
> school being taught NOT to use it *especially* not in written text.  And - 
> perhaps because of this early tuition - it still sounds clumsy and confusing 
> to 
> me.

Perhaps we have to agree to disagree on singular they, but I hope we can
still agree on the following statements from my earlier email:

-
[...] it's super easy:
- if you're not sure (or have forgotten), use "singular they", or ask
- if you know someone has a preference for pronouns, use those
- don't use pronouns when *you know* the other person does not identify
  with them.

If you make a mistake, no-one will tear your head off — it may well feel
like an awkward social faux pas to you, but, c'est la vie! And an
apology will show your intention was not malicious.

In manuals we can just use "singular they", because it is a well
established convention and does not cause confusion.
-

I think if you agree with the sentiment, but dislike singular they as
the "general fall-back" then the above approach provides an inherent
method for you not to have to use that ("just ask") in the informal
context.

Alternatively it would be incumbent on you to provide an
alternative that is not just "I will bloody-mindedly stick to
gendering people when I don't know anything about them".

In the formal context, well… I think there is broad consensus that
"singular they" is awesome.

> People having been talking about being "welcoming".  Well, I beleive the way
> to achieve that is threefold:
>
> 1. Try not to offend.
> 2. Try not to be offended.
> 3. Recognise that diversity is an asset.

Absolutely, wonderful sentiment.  To that I would add:

4. Respect the integrity and right to self-definition of all participants

Ta,

Alex

Re: Being excellent to one another

[Alex Sassmannshausen]

John Darrington writes:

> On Sun, Mar 19, 2017 at 07:57:07PM -0700, dian_ce...@zoho.com wrote:
>  On Sun, 19 Mar 2017 17:40:27 -0500
>  Christopher Allan Webber  wrote:
>  > The important thing is to not assume someone's preferred pronouns
>  > without knowing them.  Singular they isn't your only option; I also
>  > happen to like Spivak pronouns:
>  >
>  >   https://en.wikipedia.org/wiki/Spivak_pronoun
>
>  The problem here is that I'd be suprised if many people have even heard
>  about these. I used to play MUDs quite a bit and have /never/ heard any
>  of those. They are certainly not a part of common usage, and I'd say
>  should be avoided for something more standard (them et al). It's a nice
>  idea, but overall seems like it would cause confusion, and probably
>  more than a few "Hey, there is a typo in the manual"-type bugs than
>  anything.
>
>  At least, if I picked up a random bit of documentation and saw things
>  like "e" used constantly, I'd assume it was a typo and not some archaic
>  gender-neutral pronoun.
>
> [...]

> When writing texts, such as this email, and absolutely  *have* to use a 
> personal
> definite pronoun, I default to "she" because whereas vigilantes will pounce 
> upon
> you whenever they see "he" (ironically those people are invariably male), I've
> never had anyone complain when "she" occurs where the gender of the subject
> might well be masculine.
>
>
> ... and yes.  If an individual specifically requests to be referred to by
> a partcular set of pronouns I will attempt to do so, but may occasionally
> forget if that person wants feminine pronouns and is 6'4" and has an enormous
> black wiry beard.

[I really don't know what your intention is with that last paragraph — I
will just ignore it, as I wouldn't want to ascribe malice…]

John, really, it's super easy:
- if you're not sure (or have forgotten), use "singular they", or ask
- if you know someone has a preference for pronouns, use those
- don't use pronouns when *you know* the other person does not identify
  with them.

If you make a mistake, no-one will tear your head off — it may well feel
like an awkward social faux pas to you, but, c'est la vie! And an
apology will show your intention was not malicious.

In manuals we can just use "singular they", because it is a well
established convention and does not cause confusion.

Someone who's learning English as a second language would hopefully have
been exposed to "singular they" in their class.  If not, they should ask
for their money back.

Regardless, it would be great for our manual to introduce them to
this lovely convention that is so widely used.

Cheers,

Alex

Re: FOSDEM social dinner

[Alex Sassmannshausen]

Hi Benz,

Sure — welcome :-)

Alex
Benz Schenk writes:

> Hi
>
> I'm somewhat late to the party as I wasn't sure whether I could make it
> to FOSDEM this year, but aparently I will.
>
> If it's still ok, I'd love to join ^^
>
> Best regards
>
> Benz
>
> On Fri, 20 Jan 2017 14:27:11 +0100
> Alex Sassmannshausen <alex.sassmannshau...@gmail.com> wrote:
>
>> Hello,
>> 
>> To confirm, I've now placed a reservation for Saturday 4 February at
>> 19:30 at a Lebanese restaurant called Al Jannah.  I haven't been there
>> before, but the menu looks diverse, the prices good and the location
>> relatively central.
>> 
>> https://www.tripadvisor.com/Restaurant_Review-g188644-d2039550-Reviews-Al_Jannah-Brussels.html
>> 
>> Address:
>> Rue Blaes 59, Brussels 1000, Belgium
>> 
>> There is a direct tram line from ULB to Louise, and then it's a 5-10 min
>> walk.  From there it's probably around 15 min walk to the central
>> station where there are trains to Antwerp.
>> 
>> List of attendees:
>> Leo, Catonano, Amirouche, Efraim, Tomáš, Thomas, Tobias, Christopher
>> Baines, Manolis, Ludo, Ricardo, Matias and myself.
>> 
>> Let me know if I missed you, or if you have questions!
>> 
>> For now, until then :-)
>> 
>> Alex
>> 
>> 
>> Alex Sassmannshausen writes:
>> 
>> > Hello,
>> >
>> > Guile has a dev room at FOSDEM this year — for a whole day!  The dev
>> > room will be on Sunday.
>> >
>> > Whilst organising it, we had the idea that it would be fun to have a
>> > Guile/Guix user & dev dinner on the Saturday evening.  I'm hereby
>> > officially opening registration for that :-D
>> >
>> > I have not chosen a restaurant yet, but it will be something that
>> > provides a varietary of dietary options (omnivore, veggie, vegan).  If
>> > you are interested in coming along, just drop me a line to confirm.
>> >
>> > So — who's in for Guile social dinner on Saturday 4 February 2017 in
>> > Brussels?
>> >
>> > Best wishes,
>> >
>> > Alex  
>> 
>> 

Re: FOSDEM social dinner

[Alex Sassmannshausen]

Hello,

To confirm, I've now placed a reservation for Saturday 4 February at
19:30 at a Lebanese restaurant called Al Jannah.  I haven't been there
before, but the menu looks diverse, the prices good and the location
relatively central.

https://www.tripadvisor.com/Restaurant_Review-g188644-d2039550-Reviews-Al_Jannah-Brussels.html

Address:
Rue Blaes 59, Brussels 1000, Belgium

There is a direct tram line from ULB to Louise, and then it's a 5-10 min
walk.  From there it's probably around 15 min walk to the central
station where there are trains to Antwerp.

List of attendees:
Leo, Catonano, Amirouche, Efraim, Tomáš, Thomas, Tobias, Christopher
Baines, Manolis, Ludo, Ricardo, Matias and myself.

Let me know if I missed you, or if you have questions!

For now, until then :-)

Alex


Alex Sassmannshausen writes:

> Hello,
>
> Guile has a dev room at FOSDEM this year — for a whole day!  The dev
> room will be on Sunday.
>
> Whilst organising it, we had the idea that it would be fun to have a
> Guile/Guix user & dev dinner on the Saturday evening.  I'm hereby
> officially opening registration for that :-D
>
> I have not chosen a restaurant yet, but it will be something that
> provides a varietary of dietary options (omnivore, veggie, vegan).  If
> you are interested in coming along, just drop me a line to confirm.
>
> So — who's in for Guile social dinner on Saturday 4 February 2017 in
> Brussels?
>
> Best wishes,
>
> Alex

Re: It’s building!

[Alex Sassmannshausen]

Kei Kebreau writes:

> l...@gnu.org (Ludovic Courtès) writes:
>
>> Hello Guix!
>>
>> Good news: the new machine, bayfront.guixsd.org, is building Guix master
>> for x86_64/i686 with Cuirass⁰!
>>
>> You can get substitutes from https://bayfront.guixsd.org; just authorize
>> its key (with ‘guix archive --authorize’), which is:
>>
>>   (public-key 
>>(ecc 
>> (curve Ed25519)
>> (q #8D156F295D24B0D9A86FA5741A840FF2D24F60F7B6C4134814AD55625971B394#)))
>>
>> The machine was initially installed using substitutes from
>> hydra.gnu.org, but ever since it has been building stuff on its own (it
>> does not offload to any other machine at this point).  Thus it can be
>> used to check for reproducibility issues:
>>
>>   guix challenge gdk-pixbuf \
>> --substitute-urls="https://mirror.hydra.gnu.org 
>> https://bayfront.guixsd.org;
>>
>> The machine runs GuixSD and its config is under version control:
>>
>>   
>> http://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/bayfront.scm
>>
>> Currently Cuirass doesn’t expose much over HTTP¹ but hopefully we can
>> incrementally add the URLs that guix-hydra.el expects.
>>
>> There are a few glitches to address, such as the fact that it builds
>> with max-jobs = 1 due to , but we’ll get
>> there.
>>
>> Woohoo!  :-)
>>
>> Ludo’.
>>
>> ⁰ See  
>> and
>>    if
>>   you missed the previous episodes.
>>
>> ¹ https://notabug.org/mthl/cuirass/src/master/src/cuirass/http.scm
>
> Wow, this is cool! Thanks to everyone who was/is/will be working on this!

I can only concur with this!

Great work :-D

Alex

[PATCH 0/1] Add Guile-ICS

[Alex Sassmannshausen]

Hello,

This patch adds Guile-ICS, a newly released Guile library to interact with ICS
calendar files.

As it stands the code works, tests pass and the bundled cli application works.

The only problem is that I'm getting some odd error messages here, which I'm
not sure whether they are due to my setup or the compilation procedure…

Alex

PS: Error examples:
;;; WARNING: loading compiled file 
/home/alex/.guix-profile/lib/guile/2.0/site-ccache/ics.go failed:
;;; ERROR: In procedure make_objcode_from_file: bad header on object file: 
"GOOFLE-8-2.0"
;;; WARNING: loading compiled file 
/home/alex/.guix-profile/lib/guile/2.0/site-ccache/ics.go failed:
;;; ERROR: In procedure make_objcode_from_file: bad header on object file: 
"GOOFLE-8-2.0"
;;; WARNING: loading compiled file 
/home/alex/.guix-profile/lib/guile/2.0/site-ccache/ics/common.go failed:
;;; ERROR: In procedure make_objcode_from_file: bad header on object file: 
"GOOFLE-8-2.0"
;;; WARNING: loading compiled file 
/home/alex/.guix-profile/lib/guile/2.0/site-ccache/ics/common.go failed:
;;; ERROR: In procedure make_objcode_from_file: bad header on object file: 
"GOOFLE-8-2.0"
;;; WARNING: loading compiled file 
/home/alex/.guix-profile/lib/guile/2.0/site-ccache/ics/fsm.go failed:
;;; ERROR: In procedure make_objcode_from_file: bad header on object file: 
"GOOFLE-8-2.0"
;;; WARNING: loading compiled file 
/home/alex/.guix-profile/lib/guile/2.0/site-ccache/ics/fsm.go failed:
;;; ERROR: In procedure make_objcode_from_file: bad header on object file: 
"GOOFLE-8-2.0"
;;; WARNING: loading compiled file 
/home/alex/.guix-profile/lib/guile/2.0/site-ccache/ics/ical-object.go failed:
;;; ERROR: In procedure make_objcode_from_file: bad header on object file: 
"GOOFLE-8-2.0"
;;; WARNING: loading compiled file 
/home/alex/.guix-profile/lib/guile/2.0/site-ccache/ics/ical-object.go failed:
;;; ERROR: In procedure make_objcode_from_file: bad header on object file: 
"GOOFLE-8-2.0"
;;; WARNING: loading compiled file 
/home/alex/.guix-profile/lib/guile/2.0/site-ccache/ics/parser.go failed:
;;; ERROR: In procedure make_objcode_from_file: bad header on object file: 
"GOOFLE-8-2.0"
;;; WARNING: loading compiled file 
/home/alex/.guix-profile/lib/guile/2.0/site-ccache/ics/parser.go failed:
;;; ERROR: In procedure make_objcode_from_file: bad header on object file: 
"GOOFLE-8-2.0"
;;; WARNING: loading compiled file 
/home/alex/.guix-profile/lib/guile/2.0/site-ccache/ics/streams.go failed:
;;; ERROR: In procedure make_objcode_from_file: bad header on object file: 
"GOOFLE-8-2.0"
;;; WARNING: loading compiled file 
/home/alex/.guix-profile/lib/guile/2.0/site-ccache/ics/streams.go failed:
;;; ERROR: In procedure make_objcode_from_file: bad header on object file: 
"GOOFLE-8-2.0"
Subject: [PATCH 0/1] *** SUBJECT HERE ***

Alex Sassmannshausen (1):
  gnu: Add Guile-ICS.

 gnu/packages/guile.scm | 28 
 1 file changed, 28 insertions(+)

-- 
2.11.0

[PATCH 1/1] gnu: Add Guile-ICS.

[Alex Sassmannshausen]

* gnu/packages/guile.scm (guile-ics): New variable.
---
 gnu/packages/guile.scm | 28 
 1 file changed, 28 insertions(+)

diff --git a/gnu/packages/guile.scm b/gnu/packages/guile.scm
index 9458ab714..c6d8fd8e8 100644
--- a/gnu/packages/guile.scm
+++ b/gnu/packages/guile.scm
@@ -525,6 +525,34 @@ format is also supported.")
(,modules)))
#t
 
+(define-public guile-ics
+  (package
+(name "guile-ics")
+(version "0.1.1-rc1")
+(source (origin
+  (method url-fetch)
+  (uri (string-append "ftp://memory-heap.org/software/; name "/"
+  name "-" version ".tar.gz"))
+  (sha256
+   (base32
+"01bl8c0wqkndnf2hnlvm2lj1rhh33szsblcmjbnyl6vyhnlm4lf5"
+(build-system gnu-build-system)
+(arguments
+ '(#:configure-flags
+   (list (string-append
+  "--with-guile-site-dir=" %output "/share/guile/site/2.0"
+(native-inputs `(("pkg-config" ,pkg-config)))
+(inputs `(("guile" ,guile-2.0)))
+(propagated-inputs `(("guile-lib" ,guile-lib)))
+(home-page "https://github.com/artyom-poptsov/guile-ics;)
+(synopsis "An iCalendar parser library for Guile")
+(description
+ "Guile-ICS is an iCalendar (RFC5545) format parser library written in
+pure Scheme.  The library can be used to read and write iCalendar data.
+
+The library is shipped with documentation in Info format and usage examples.")
+(license gpl3)))
+
 (define-public guile-lib
   (package
 (name "guile-lib")
-- 
2.11.0

FOSDEM social dinner

[Alex Sassmannshausen]

Hello,

Guile has a dev room at FOSDEM this year — for a whole day!  The dev
room will be on Sunday.

Whilst organising it, we had the idea that it would be fun to have a
Guile/Guix user & dev dinner on the Saturday evening.  I'm hereby
officially opening registration for that :-D

I have not chosen a restaurant yet, but it will be something that
provides a varietary of dietary options (omnivore, veggie, vegan).  If
you are interested in coming along, just drop me a line to confirm.

So — who's in for Guile social dinner on Saturday 4 February 2017 in
Brussels?

Best wishes,

Alex

Re: Remove duplicates in AUTHORS file before the release

[Alex Sassmannshausen]

Alex Kost writes:

> Hello, if it's not too late for the release, I think it would be good to
> adjust ".mailmap" to avoid duplicates in the generated AUTHORS file (if
> it's too late, it would be good anyway).
>
> As you can check with "git --no-pager shortlog -nse", there are some
> duplicates in the output (double names or emails for the same person).
> This output is used to generate AUTHORS file in release tarballs.  So to
> disambiguate this, I would like to ask the people what are their
> preference:
>
> - Alex:  or ?

I'm using a...@pompo.co .

Thank you for doing this!

Alex

Re: [PATCH] doc: Mention "guix pull" during installation.

[Alex Sassmannshausen]

Ludovic Courtès writes:

> Hello!
>
> Leo Famulari  skribis:
>
>> I've recently gave an explanation of why I think using `guix pull`
>> before installing GuixSD should not be recommended unconditionally:
>>
>> http://lists.gnu.org/archive/html/bug-guix/2016-11/msg00047.html
>>
>> In the specific case of installing GuixSD 0.11.0 today, `guix pull` is
>> necessary, because we lack the substitutes, and some packages can't be
>> built at all now [1]. But, adding these lines to the manual now won't
>> make it show up in the 0.11.0 installer manual.
>>
>> I think we should work on improving our infrastructure in the next
>> release cycle, and revisit this change to the manual if we are still
>> having problems before the 0.13.0 release.
>>
>> What does everyone think?
>
> I agree with everything you wrote here.
>
> Ludo’.

I think I too agree here.  Especially as my experience (running GuixSD
on i686 bare metal) suggests that `guix pull` can actually result in
packages that do not quite build reliably.  There currently seems to be
a `guix pull` sweet spot when the substitutes are not too old yet the
recipes not too new…

I think the best solution would definitely be guaranteed availability of
substitutes for releases until at least the next release — so I greatly
appreciate the work that is being done to on the infrastructure side.

My 2¢,

Alex

Re: FOSDEM 2017 Schedule is there!

[Alex Sassmannshausen]

Pjotr Prins writes:

> Check it out K.3.201 - looks awesome!
>
> https://fosdem.org/2017/schedule/day/saturday/

Indeed, most excellent!  Looking forward to this greatly :-)

Alex

Re: [PATCH] Generate multiple paginated packages pages.

[Alex Sassmannshausen]

Heya

John Darrington writes:

> On Thu, Dec 08, 2016 at 12:29:22PM +0100, Alex Sassmannshausen wrote:
>  
>  > Note that I removed the all-in-one package page because the poor CVS
>  > server at gnu.org simply can???t handle it.
>  
>  Sure ??? I figure this way of browsing is more user friendly anyway???
>  
> Well yes and no.
>
> It's more friendly in the respect that it no longer takes 2 minutes to load.
>
> But the down side is that I can no longer load the page and then use my 
> browser's "Find in Page" button to search for a package---Now I have to
> know what the package is called before I can search for it.

Fair point!  I think Luis Felipe is thinking of a more comprehensive
approach to the package pages — mine was more of a quick fix to solve an
urgent problem.

> Maybe sometime in the future a "browse by category" or "search for packages"
> feature will be available?
>
> J'