GHC 8.4.3

[Timothy Sample]

Hi all,

Some of you may recall that I started work on updating all of our
Haskell packages to their LTS 12 versions, and making sure they all
build with GHC 8.4.3.  I think this work is ready to be included now (on
a WIP branch, at least).  The commits exist at
 under the
“wip-haskell” branch.  There are 258 commits, and they have been rebased
on master (although that was a few days ago, but it should be fine
because the Haskell packages have been relatively stable).  I figure
that 258 commits is too many for guix-patches, so I’m hoping that
someone (Ricardo?) can take them from the repo linked above.  There are
about 450 packages that need to be rebuilt.

Here are some notes that you might find interesting if you rely on our
Haskell infrastructure.

  • There are 21 failing packages.  They are agda, beast, corrode,
git-annex, ghc-aws, ghc-gnuplot, ghc-haddock-test,
ghc-hashable-bootstrap, ghc-indents, ghc-monadplus,
ghc-nats-bootstrap, ghc-packedstring, ghc-regex, ghc-regex-tdfa-rc,
ghc-statistics, ghc-vector-builder, ghc-wave, ghc-xmonad-contrib,
raincat, rapicorn, and shellcheck.  Some of these are abandoned
upstream, but most of them just need some extra attention.  I will
look through them (especially git-annex), but I would like the
stability of the build farm as I do it.  (Also, help wanted!)

  • The new Haskell no longer supports the “--allow-newer” flag, so it
has to be worked around with phases and “substitute*”.  However, I
have introduced a “#:cabal-revision” keyword that tells the build
system to patch in newer revisions of the package’s Cabal file from
Hackage.  This means that we can use this mechanism whenever
upstream has updated the dependency constraints (which is the main
reason we made so much use of “--allow-newer” in the first place).

  • I removed “ghc-mtl” since it is now included in GHC.

If you review the patches (thanks!) you might want to know:

  • I went through all of them carefully and I sincerely hope the error
and typo count is low!  Also, most of them are machine generated, so
those are probably fine.

  • There are a few more interesting commits that deserve special
attention.  There are (minor) changes to the Stackage importer,
there’s the “#:cabal-revision” stuff, and there are some
old/unneeded packages that I deleted.

Let me know if there is anything I can do to make these changes easier
to work with.


-- Tim

Re: FSDG status of chromium

[bill-auger]

On Wed, 26 Sep 2018 03:23:51 +0200 Marius wrote:
> Can you point out which part of the upstream bug that is relevant?
> 
>  https://bugs.chromium.org/p/chromium/issues/detail?id=28291

the fact that it is still open after 10 years is relevance enough -
IMHO i would want to see that bug closed as [FIXED] before any FSDG
distro packages chromium or any of it's de


On Wed, 26 Sep 2018 03:23:51 +0200 Marius wrote:
> AFAICT it's about bundled software, and in our case there are only 379
> files that need auditing.  Am I missing something?

if that is the extent of it, that would actually be within the scope of
feasibility


On Wed, 26 Sep 2018 03:23:51 +0200 Marius wrote:
> bill-auger  writes:
> > On Tue, 25 Sep 2018 21:08:42 +0200 Marius wrote:  
> > > It seems to me using "Ungoogled-Chromium" remediates Lukes
> > > concerns  
> >
> > yes most people agree that the ungoogled patches would be necessary
> > but not sufficient for any FSDG compliant build of chromium  
> 
> What else is remaining?

sorting out the licensing, and the other issues that luke wrote about -
also this i have not looked into but someone on IRC wanted to point out
yesterday

> Since people were wondering about the status of Chromium it should be
> noted that it's getting worse to clean the stinking pile up:
> https://news.ycombinator.com/item?id=18065856
> https://www.reddit.com/r/programming/comments/9irevi/chrome_69_clear_all_cookies_doesnt_delete_google/
> https://news.softpedia.com/news/chrome-69-does-not-delete-google-cookies-when-clearing-all-website-data-522884.shtml


On Wed, 26 Sep 2018 03:23:51 +0200 Marius wrote:
>  Their Chromium directory is 1,5 GiB uncompressed compared
> to 2.2 GiB for the Guix package and 4.5 GiB for the upstream tarball.

not for nothing, but does that seem reasonable to you? - a tiny bit
excessive perhaps? - IMHO the sheer magnitude of this software should
frighten anyone


On Wed, 26 Sep 2018 03:23:51 +0200 Marius wrote:
> As far as I can tell, both packages are eligible for free
> distributions, assuming proper caretaking is in place

again, the best place to discuss this is on the FSDG mailing list[1] - i
personally do not care whether this program is or is not available in
any distro - my only stake in this is that i want to see all of the
FSDG distro present themselves uniformly regarding concerns that are
uniformly applicable to them all - this chromium/webengine issue is one
of the most visible and out-standing of any such issues

please do join that mailing list and start a thread announcing your
intentions and your findings - there are people there who are
interested in this topic, those who have already looked into it more
than i have, and those such as adfeno who may even be willing to help
resolve this issue once and for all - but above all, to let everyone
reach a consensus, with the guidance of the FSF, as to whether or not
*any* FSDG distro should be distributing chromium - as of today, the
consensus is that none of them should because there no known and
documented liberation procedure


[1]: https://lists.nongnu.org/mailman/listinfo/gnu-linux-libre

Re: FSDG status of chromium

[bill-auger]

On Wed, 26 Sep 2018 10:11:50 +0200 Andy wrote:
> Are you aware of any concrete issue that has been raised

look no further than the original 10 year old bug report that was never
closed - that is enough "concrete" for my sensibilities - it plainly
demonstrates that even the chromium developers are not certain whether
or not it is 100% freely distributable


On Wed, 26 Sep 2018 10:11:50 +0200 Andy wrote:
> Any non-free file or incompatible in our distribution?

no - and that is exactly the core problem - AFAIK no person on this
planet knows the definitive answer to that question, including the
upstream developers themselves, as demonstrated by the 10 year old bug
report that was never closed

from around 2009-2012 it actively addressed several such files then
activity just petered out - perhaps those because more tedious to
locate because of the overwhelming size of the code-base



let me underline again, that this is not a new issue nor a guix issue -
this is a long-standing issue that affects all FSDG distros equally -
the most appropriate and helpful venue to discuss this is the FSDG
mailing list - i started this thread only because it is apparent that
no one from guixsd is currently participating in those discussions; and
so to invite you to do so for the benefit of the wider free software
community

Re: Guix Outreachy project looking for co-mentor

[Ricardo Wurmus]

Ludovic Courtès  writes:

> Hello!
>
> Gábor Boskovits  skribis:
>
>> we are looking for co-mentors to the 2018 December round of the Outreachy
>> project.
>>
>> We have one project proposal approved:
>> Create user video documentation for GNU Guix.
>
> Nice!
>
> I encourage people on this list to volunteer to co-mentor this project:
> increasing our bus factor¹ is important (really!) and so is bringing
> people from diverse backgrounds to the project, and this is a nice
> project that can make a big difference for Guix.

I agree.  This video documentation project is very different from other
GSoC or Outreachy projects of the past in that they don’t really require
programming skills.  This makes it easier for mentors as well.

If you are a contributor to Guix and you are familiar with how to use
Guix and what sets it apart from related systems you might be able to
co-mentor this project.  If you aren’t sure feel free to get in touch
with Gábor and me (even off-list).

> Among the other ideas that were thrown on IRC was that of a GNOME
> Software backend.  If people have an interest in this, we can still dig
> a bit and formalize it.  Thoughts?

For that project I think it would be advisable to get in touch with the
maintainers of GNOME Software to better understand what would need to be
done on their side.  I’d feel uncomfortable starting a project for
Outreachy unilaterally without having a liaison on the GNOME side.

For internships we need to make sure that we control enough of the
variables that could lead to failure.  I think this may not be possible
if the work happens on a foreign code base with a developer community
that we aren’t yet part of.

This is doable, but it requires more than the usual preparation by a
potential mentor.

--
Ricardo

Re: SeaGL 2018 Accepts Guix-Themed Talk: "Everyday Use of GNU Guix"

[Christopher Lemmer Webber]

Chris Marusich writes:

> Hi Guix!
>
> I recently submitted a Guix-themed talk proposal for SeaGL 2018 [1], a
> local GNU/Linux conference that takes place in November here in Seattle,
> and I'm happy to report that it was accepted!  Here's the link:
>
> "Everyday Use of GNU Guix"
> https://osem.seagl.org/conferences/seagl2018/program/proposals/526
>
> I'm very excited about it!  I've been to SeaGL before as an attendee,
> but this is the first time I'll try my hand as a presenter.  It's a
> great opportunity to promote and share Guix within my local community.
>
> I'll do my best to introduce Guix to the attendees!  If even one person
> from Seattle decides to give Guix or GuixSD a try, I'll consider that a
> success!  I need more Guix here on my home turf.  :-)
>
> Footnotes: 
> [1]  http://seagl.org/

Hey this is great news!  I've been to SeaGL before and it was great.

Enjoy your talk!  I'm sure it'll go great.

Re: GNU Shepherd 0.5.0 released

[Pjotr Prins]

On Wed, Sep 26, 2018 at 03:07:46PM +0200, Ludovic Courtès wrote:
> We are pleased to announce the GNU Shepherd version 0.5.0, a release
> containing new features and bug fixes.

kudos!

>   used as the init system of GuixSD, GNU’s advanced GNU/Linux distribution.

I like the: GNU's advanced GNU/Linux distribution

How about using that throughout? Also

  GNU Guix: GNU's advanced package manager

Pj.

GNU Shepherd 0.5.0 released

[Ludovic Courtès]

We are pleased to announce the GNU Shepherd version 0.5.0, a release
containing new features and bug fixes.

• About

  The GNU Daemon Shepherd or GNU Shepherd is a service manager written
  in Guile that looks after the herd of system services.  It provides a
  replacement for the service-managing capabilities of SysV-init (or any
  other init) with a dependency-based system with a convenient
  interface.  The GNU Shepherd may also be used by unprivileged users to
  manage per-user daemons (e.g., tor, privoxy, mcron, etc.)  It is
  written in Guile Scheme, and is configured and extended using Guile.

  The GNU Shepherd is developed jointly with the GNU Guix project; it is
  used as the init system of GuixSD, GNU’s advanced GNU/Linux distribution.

  https://www.gnu.org/software/shepherd/


• Download

  Here are the compressed sources and a GPG detached signature[*]:
https://alpha.gnu.org/gnu/shepherd/shepherd-0.5.0.tar.gz
https://alpha.gnu.org/gnu/shepherd/shepherd-0.5.0.tar.gz.sig

  Use a mirror for higher download bandwidth:
https://www.gnu.org/order/ftp.html

  Here are the SHA1 and SHA256 hashes:

  ff864ff254644c72abae8fc720c38f6086b74b19  shepherd-0.5.0.tar.gz
  e84a31b9d287b826a4bcfb69965736607a1c1f00d67aa243b7f4fa442b8eacf2  
shepherd-0.5.0.tar.gz

  [*] Use a .sig file to verify that the corresponding file (without the
  .sig suffix) is intact.  First, be sure to download both the .sig file
  and the corresponding tarball.  Then, run a command like this:

gpg --verify shepherd-0.5.0.tar.gz.sig

  If that command fails because you don't have the required public key,
  then run this command to import it:

gpg --keyserver keys.gnupg.net --recv-keys 
3CE464558A84FDC69DB40CFB090B11993D9AEBB5

  and rerun the 'gpg --verify' command.

  This release was bootstrapped with the following tools:
Autoconf 2.69
Automake 1.16.1
Makeinfo 6.5
Help2man 1.47.6


• Changes since version 0.4.0 (excerpt from the NEWS file)

  ** Services now have a ‘replacement’ slot
  ** Restarting a service now restarts its dependent services as well
  ** Gracefully halt upon ctrl-alt-del when running as PID 1 on GNU/Linux
  ** Actions can now be invoked on services not currently running
  ** Guile >= 2.0.13 is now required; Guile 3.0 is supported
  ** Unused runlevel code has been removed
  ** Updated translations: es, fr, pt_BR, sv


Please report bugs to bug-g...@gnu.org.
Join guix-devel@gnu.org and gnu-system-disc...@gnu.org for discussions.

Ludovic, on behalf of the Shepherd herd.


signature.asc
Description: PGP signature

Re: Guix Outreachy project looking for co-mentor

[Ludovic Courtès]

Hello!

Gábor Boskovits  skribis:

> we are looking for co-mentors to the 2018 December round of the Outreachy
> project.
>
> We have one project proposal approved:
> Create user video documentation for GNU Guix.

Nice!

I encourage people on this list to volunteer to co-mentor this project:
increasing our bus factor¹ is important (really!) and so is bringing
people from diverse backgrounds to the project, and this is a nice
project that can make a big difference for Guix.

¹ https://en.wikipedia.org/wiki/Bus_factor

> Oct. 16, 2018 is the deadline to submit new projects, and also to apply as
> a co-mentor.

Among the other ideas that were thrown on IRC was that of a GNOME
Software backend.  If people have an interest in this, we can still dig
a bit and formalize it.  Thoughts?

Thanks,
Ludo’.

Re: Blog: Guix packaging tutorial

[Pierre Neidhardt]

My understanding it that

  %output = (assoc-ref "out" %outputs)

Is this correct?

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


signature.asc
Description: PGP signature

Re: ~/.guix-profile/manifest usage with "guix package -m [manifest]" / "guix pack -m [manifest]" etc..

[Ludovic Courtès]

Hello,

YOANN P  skribis:

> I was thinking than "~/.guix-profile/manifest" was a valid manifest file due 
> to his name, but it seems not that is the case from the error i've got
>
> https://pastebin.com/Z7h2t5mL
>
> After some search , i've finally understand that the instantiated profile 
> couldn't be used as source profile for "guix package -m" etc... due to the 
> same words despite use case and is a bit confusing

I agree it’s a bit confusing.  The manual does make it clear that -m
expects source code that evaluates to a manifest object, though.

> https://gnunet.org/bot/log/guix/2016-05-27#T1040380
>
> It will be really convenient to only have the instantiate profile to easily 
> maintain it in a vcs system.
>
> Despite what ludo said in 2016 on IRC, i didn't see those options yet.
> Did i missed them ?
> If not implemented yet, any news about this feature ? :)

No news I’m afraid :-) but I’ve opened an issue so we keep track of it:

  https://issues.guix.info/issue/32844

Maybe you can help?

Thanks,
Ludo’.

Re: SeaGL 2018 Accepts Guix-Themed Talk: "Everyday Use of GNU Guix"

[Ludovic Courtès]

Hi Chris!

Chris Marusich  skribis:

> I recently submitted a Guix-themed talk proposal for SeaGL 2018 [1], a
> local GNU/Linux conference that takes place in November here in Seattle,
> and I'm happy to report that it was accepted!  Here's the link:
>
> "Everyday Use of GNU Guix"
> https://osem.seagl.org/conferences/seagl2018/program/proposals/526

Awesome!  If you want we can post a brief on the blog so people from
the area interested in Guix get another incentive to go to SeaGL.  :-)

Ludo’.

Re: Blog: Guix packaging tutorial

[Ludovic Courtès]

Pierre Neidhardt  skribis:

> Err... Actually I see that a few packages like "mg" uses %output and not
> %outputs.  What's the difference?

‘%outputs’ is the recommended way, ‘%output’ is not.  :-)

Ludo’.

Re: FSDG status of chromium

[Clément Lassieur]

Andy Wingo  writes:

> On Tue 25 Sep 2018 21:36, Clément Lassieur  writes:
>
>> Thank you very much for letting us know about these issues!  I'm glad
>> Marius put it in a channel then, it was a wise decision.  I hope we'll
>> make it free at some point, so that it can be integrated into Guix.  But
>> there is Icecat 60 now (thanks to everyone involved!), so it's not that
>> urgent anymore.
>
> Unless I misunderstand, we have only been notified about the history of
> a discussion.  Are you aware of any concrete issue that has been raised?
> Any non-free file or incompatible in our distribution?

I believe the serious issue that has been raised is that we don't
communicate well with other FSDG distributions.  There are discussions
and bugs reported about the fact that Chromium might be non-free, and
while we may have fixed those issues, we didn't notify the other people
in the community who have the exact same issues.  Plus, we may have
missed problems that have been raised there.

Re: FSDG status of chromium

[Andy Wingo]

On Tue 25 Sep 2018 21:36, Clément Lassieur  writes:

> Thank you very much for letting us know about these issues!  I'm glad
> Marius put it in a channel then, it was a wise decision.  I hope we'll
> make it free at some point, so that it can be integrated into Guix.  But
> there is Icecat 60 now (thanks to everyone involved!), so it's not that
> urgent anymore.

Unless I misunderstand, we have only been notified about the history of
a discussion.  Are you aware of any concrete issue that has been raised?
Any non-free file or incompatible in our distribution?

Andy