Re: [PATCH] scripts: hash: Add --git option. WIP

[Andy Wingo]

On Thu 23 Nov 2017 04:54, Jan Nieuwenhuizen  writes:

> Hi!
>
> Attached is a patch to get the hash of a git archive without having to
> clean the tree or do a clean checkout.
>
> Using
>
> guix hash -gr .
>
> procudes the same hash as doing something like
>
> git clone . tmp && guix hash -rx tmp && rm -r tmp
>
> I marked it as WIP because while it is already "handy" as it is, I
> consider adding a commit argument and imply --recursive, like so
>
>guix hash --git HEAD
>guix hash --git v0.13
>
> WDYT?

Weird that we have done the same thing :)

https://git.savannah.gnu.org/gitweb/?p=guix.git;a=commit;h=572907daff98a77a4215861a88b81d2f30542c09

Andy

MIME database

[Ludovic Courtès]

Hello,

(Moving the discussions to guix-devel.)

brendan.tildes...@openmailbox.org skribis:

> I was wondering why my pdf documents were getting opened in Gimp by default 
> instead of Evince, so I investigated xdg-open and found it uses mimeopen as a 
> fallback, and packaged it. Turns out it didn't make a difference and the 
> issue was simply that the generated mimedata.cache in xdg-mime-database had 
> Gimp listed before Evince.

Oh, good catch.  Profile generation is sensitive to package order; so
indeed, if GIMP comes first, it “wins.”

> I was also I little confused that xdg-mime-database produces so many 
> conflicts with shared-mime-info. It's role appears to be to update the data 
> in shared-mime-data and have it overshadow the original data when  conflicts 
> are resolved during profile generation. Looks ugly seeing all those conflicts 
> though.

I guess it’s OK in that users normally don’t want to install these
packages at all, let alone installing both in the same profile.

> I had a look at Fedora's version. They just have a single shared-mime-data 
> package that runs update-mime-database, but also they add a few changes to 
> make Evince open pdf's instead of Gimp, among other changes.
>
> This makes me feel that it's desirable for us to also tweak mimedata to make 
> it more sensible -- Pdf's should open in a pdf reader before it opens in an 
> image editor. It seems unrealistic to only tweak upstream projects to make 
> all this mimedata mesh together perfectly to produce ideal default behaviour.

Right, so I think the immediate course of action here would be to patch
GIMP’s MIME data so that it does not register as a PDF viewer.

If we stumble upon other issues like that, we can fix them similarly.

How does that sound?

Thanks for investigating!

Ludo’.

Re: MIME database

[julien lepiller]

Le 2017-11-28 10:24, l...@gnu.org a écrit :

Hello,

(Moving the discussions to guix-devel.)

brendan.tildes...@openmailbox.org skribis:

I was wondering why my pdf documents were getting opened in Gimp by 
default instead of Evince, so I investigated xdg-open and found it 
uses mimeopen as a fallback, and packaged it. Turns out it didn't make 
a difference and the issue was simply that the generated 
mimedata.cache in xdg-mime-database had Gimp listed before Evince.


Oh, good catch.  Profile generation is sensitive to package order; so
indeed, if GIMP comes first, it “wins.”

I was also I little confused that xdg-mime-database produces so many 
conflicts with shared-mime-info. It's role appears to be to update the 
data in shared-mime-data and have it overshadow the original data when 
 conflicts are resolved during profile generation. Looks ugly seeing 
all those conflicts though.


I guess it’s OK in that users normally don’t want to install these
packages at all, let alone installing both in the same profile.

I had a look at Fedora's version. They just have a single 
shared-mime-data package that runs update-mime-database, but also they 
add a few changes to make Evince open pdf's instead of Gimp, among 
other changes.


This makes me feel that it's desirable for us to also tweak mimedata 
to make it more sensible -- Pdf's should open in a pdf reader before 
it opens in an image editor. It seems unrealistic to only tweak 
upstream projects to make all this mimedata mesh together perfectly to 
produce ideal default behaviour.


Right, so I think the immediate course of action here would be to patch
GIMP’s MIME data so that it does not register as a PDF viewer.

If we stumble upon other issues like that, we can fix them similarly.


Thanks for investigating that.

Inkscape also wants to open pdf files ;)



How does that sound?

Thanks for investigating!

Ludo’.

Re: MIME database

[Andy Wingo]

On Tue 28 Nov 2017 10:24, l...@gnu.org (Ludovic Courtès) writes:

> Hello,
>
> (Moving the discussions to guix-devel.)
>
> brendan.tildes...@openmailbox.org skribis:
>
>> I was wondering why my pdf documents were getting opened in Gimp by
>> default instead of Evince, so I investigated xdg-open and found it
>> uses mimeopen as a fallback, and packaged it. Turns out it didn't make
>> a difference and the issue was simply that the generated
>> mimedata.cache in xdg-mime-database had Gimp listed before Evince.
>
> Oh, good catch.  Profile generation is sensitive to package order; so
> indeed, if GIMP comes first, it “wins.”

I had this problem with e.g. Nautilus vs Baobab on directories.
Apparently the right solution is to install a desktop-specific package
that manually does "tie-breaking" for MIME types that have multiple
handlers.  See 96d36f385cb1de83f95dd0404dc2166d6f877389.  You might try
just installing gnome-default-applications, or we might have a similar
package.

Andy

Re: MIME database

[Alex Vong]

julien lepiller  writes:

> Le 2017-11-28 10:24, l...@gnu.org a écrit :
>> Hello,
>>
>> (Moving the discussions to guix-devel.)
>>
>> brendan.tildes...@openmailbox.org skribis:
>>
>>> I was wondering why my pdf documents were getting opened in Gimp by
>>> default instead of Evince, so I investigated xdg-open and found it
>>> uses mimeopen as a fallback, and packaged it. Turns out it didn't
>>> make a difference and the issue was simply that the generated
>>> mimedata.cache in xdg-mime-database had Gimp listed before Evince.
>>
>> Oh, good catch.  Profile generation is sensitive to package order; so
>> indeed, if GIMP comes first, it “wins.”
>>
>>> I was also I little confused that xdg-mime-database produces so
>>> many conflicts with shared-mime-info. It's role appears to be to
>>> update the data in shared-mime-data and have it overshadow the
>>> original data when  conflicts are resolved during profile
>>> generation. Looks ugly seeing all those conflicts though.
>>
>> I guess it’s OK in that users normally don’t want to install these
>> packages at all, let alone installing both in the same profile.
>>
>>> I had a look at Fedora's version. They just have a single
>>> shared-mime-data package that runs update-mime-database, but also
>>> they add a few changes to make Evince open pdf's instead of Gimp,
>>> among other changes.
>>>
>>> This makes me feel that it's desirable for us to also tweak
>>> mimedata to make it more sensible -- Pdf's should open in a pdf
>>> reader before it opens in an image editor. It seems unrealistic to
>>> only tweak upstream projects to make all this mimedata mesh
>>> together perfectly to produce ideal default behaviour.
>>
>> Right, so I think the immediate course of action here would be to patch
>> GIMP’s MIME data so that it does not register as a PDF viewer.
>>
>> If we stumble upon other issues like that, we can fix them similarly.
>
> Thanks for investigating that.
>
> Inkscape also wants to open pdf files ;)
>
On my laptop, the recommended programs include evince, libreoffice draw,
gimp, inkscape, imagemagick and winebrowser. I am not running guixsd
though.

>>
>> How does that sound?
>>
>> Thanks for investigating!
>>
>> Ludo’.


signature.asc
Description: PGP signature

Re: MIME database

[Andy Wingo]

On Tue 28 Nov 2017 12:23, Alex Vong  writes:

> julien lepiller  writes:
>
>> Le 2017-11-28 10:24, l...@gnu.org a écrit :
>>> brendan.tildes...@openmailbox.org skribis:
>>>
>>> Right, so I think the immediate course of action here would be to patch
>>> GIMP’s MIME data so that it does not register as a PDF viewer.
>>>
>>> If we stumble upon other issues like that, we can fix them similarly.
>>
>> Thanks for investigating that.
>>
>> Inkscape also wants to open pdf files ;)
>>
> On my laptop, the recommended programs include evince, libreoffice draw,
> gimp, inkscape, imagemagick and winebrowser. I am not running guixsd
> though.

I think it's reasonable to want to be able to open PDFs in inkscape or
GIMP (e.g. via the "Open With" menu in a file browser like Nautilus),
just that they shouldn't be the default option.  I think removing the
association would be a not-so-good option; the blessed way to fix this
is apparently to install a set of defaults.

Specifically we should add to this package from gnome.scm to include the
PDF -> evince association:

(define-public gnome-default-applications
  (package
(name "gnome-default-applications")
(version "0")
(build-system trivial-build-system)
(source #f)
(propagated-inputs
 `(("nautilus" ,nautilus)))
(arguments
 `(#:modules ((guix build utils))
   #:builder
   (begin
 (use-modules (guix build utils))
 (let* ((out (assoc-ref %outputs "out"))
(apps (string-append out "/share/applications")))
   (mkdir-p apps)
   (call-with-output-file (string-append apps "/defaults.list")
 (lambda (port)
   (format port "[Default Applications]\n")
   (format port 
"inode/directory=org.gnome.Nautilus.desktop\n")))
   #t
(synopsis "Default MIME type associations for the GNOME desktop")
(description
 "Given many installed packages which might handle a given MIME type, a
user running the GNOME desktop probably has some preferences: for example,
that folders be opened by default by the Nautilus file manager, not the 
Baobab
disk usage analyzer.  This package establishes that set of default MIME type
associations for GNOME.")
(license license:gpl3+)
(home-page #f)))

Possibly we could have a set of defaults for XFCE as well.  See also
https://wiki.archlinux.org/index.php/default_applications#XDG_standard.

Andy

Re: boot the Hurd with Guix

[Daniel Pimentel]

Cool! Thanks,

---
Daniel Pimentel (d4n1)

Em 2017-11-27 22:16, ren...@openmailbox.org escreveu:

Hello,

I update the download link:

https://ombx.io/ipoWt9uK

Re: Cross-compilation, Guix "system", and GNU "triplet"

[Ludovic Courtès]

Chris Marusich  skribis:

> l...@gnu.org (Ludovic Courtès) writes:
>
>> The ABI and file format are entirely (or almost entirely) the
>> responsibility of user-land software (how you configure the toolchain
>> determines what ABI you use, for instance.)  Thus they’re necessarily
>> captured by the dependency graph; no need to store that information
>> elsewhere.
>>
>> ...
>> 
>> It’s the toolchain that shows up in the graph that determines what ABI
>> is targeted.
>
> The Guix manual makes it sound like the Guix system string can identify
> more than just the CPU architecture and kernel.  Specifically, in the
> section titled "GNU Distribution", it says the following:
>
> ‘armhf-linux’
>  ARMv7-A architecture with hard float, Thumb-2 and NEON, using the
>  EABI hard-float application binary interface (ABI), and Linux-Libre
>  kernel.
>
> ‘aarch64-linux’
>  little-endian 64-bit ARMv8-A processors, Linux-Libre kernel.  This
>  is currently in an experimental stage, with limited support.  *Note
>  Contributing::, for how to help!
>
> ‘mips64el-linux’
>  little-endian 64-bit MIPS processors, specifically the Loongson
>  series, n32 ABI, and Linux-Libre kernel.
>
>
> Is this langugae too specific?

I think so, yes.

Then again we could use different system strings to different ABIs, but
we don’t have to.

Ludo’.

Re: Idea: Install script to better support improving contributor-friendliness of projects

[Ludovic Courtès]

Hello,

Mark H Weaver  skribis:

> Никита Чураев  writes:
>
>> Here's how I want to use Guix and it is to increase
>> contributor-friendliness of a project, so that the user can simply run
>> a distribution-independent command to install all dependencies without
>> having to hunt for them with `apt` and `dnf` manually.
>>
>> Unfortunately, Guix itself is not very easy to install, and the
>> instructions are full of rather technical stuff like 'systemd' and
>> 'upstart'.
>>
>> https://www.gnu.org/software/guix/manual/html_node/Binary-Installation.html
>>
>> There should be a script like the one Haskell Stack uses:
>>
>> |curl -sSL https://get.haskellstack.org/ | sh|
>
> I can understand the appeal of such a convenient approach.  However,
> this practice of downloading a script via HTTPS and immediately running
> it as root without inspection puts you at considerable risk.  A
> man-in-the-middle with the resources to compromise or bribe *any*
> certificate authority in your trust store (the attacker could choose
> which one) could acquire a fraudulent certificate to impersonate our
> site, and then substitute in a different script than the one we
> provided.  Quite a few organizations are capable of such an attack
> today.
>
> Therefore, I believe it would be irresponsible for us to promote this
> style of installation.

Seconded.

> However, if there's sufficient interest, and if we could produce a
> sufficiently robust "auto-install" script, we could perhaps do something
> close to what you suggested.  We could provide a script along with a
> GnuPG digital signature.  We could ask the user to download the script,
> acquire our signing key, verify the signature on the script, and then
> run the script as root.

I while back Chris Baines and someone else (?) had worked on such a
script, but I’m not sure what happened.

Chris, does that ring a bell?

It would be nice to have it in time for the new release.

Ludo’.

Re: WIP gnu social package

[Ludovic Courtès]

Hello,

nee  skribis:

> Am 05.10.2017 um 17:00 schrieb Ludovic Courtès:
>> For this particular case, I would do nothing: the first time, the
>> service wouldn’t start (I guess).  Users would have to explicitly set
>> the passwords on the command line, and then run “herd start gnu-social”.
>> 
> The advantage of using a service is the easy setup with mysql and the
> gnu-social-cli-installer, otherwise people could just run nginx and
> clone gnu social to /srv/gnu-social/ and manually create the database
> like you would on Debian.
>
> I saw that NixOS has something called passwordFile.
> https://github.com/NixOS/nixpkgs/issues/24288
> I haven't found any details about it, but it seems like a text file from
> which passwords can be read during `system reconfigure`.
>
> As a start I could add a password-file field to the configuration of
> gnu-social and read an alist of passwords from it during initialization.
> That could later be extended by generating it with randomized passwords
> if it doesn't exist to maximize the ease of installation.
>
>>> - The password of the database-user ends up in the config.php which is
>>>   generated by mixed-text-file. This file can be read by everyone. Can I
>>>   somehow set the owner on it and remove the reading rights from other
>>>   users?
>> 
>> No, the store is world-readable.  If there are secrets, they should be
>> stored elsewhere, but there’s currently no standard way to do that in
>> Guix.
>> 
> Could a function in guix/gexp.scm be modified to generate a file outside
> of the store?

We could use Guile’s standard I/O primitives to create files wherever we
like:

  https://www.gnu.org/software/guile/manual/html_node/Input-and-Output.html

and/or simply refer to a non-store file; if that file exists,
everything’s fine, and if it does not, the service might fail to start
or print an error.

Ludo’.

Re: GeoIP database redistribution?

[ng0]

Hi!

It's better to reply late than never. My latency on some tasks
is high.
For anyone reading the old thread and wondering WTF happened,
I've just re-read the thread and giving it shot soon as I want
to analyze some logs and we already have a Perl module that
wants this DB. I prefer Guix supplied solutions when I can make
use of it, so long text short nonsense: I'll package it.
Thanks for the provided feedback everyone.

And Pjotr, the mentioning of TB's without any reference to an
external project really threw me off. Just specify the "We" next time ;)

ng0 transcribed 2.4K bytes:
> Efraim Flashner  writes:
> 
> > On Tue, Jan 24, 2017 at 06:06:21AM +, Pjotr Prins wrote:
> >> On Mon, Jan 23, 2017 at 07:17:12PM +0100, Marius Bakke wrote:
> >> > ng0  writes:
> >> > 
> >> > > I want to slowly package OONI (https://ooni.torproject.org/).
> >> > > One of its dependencies, txtorcon, requires python-geoip which
> >> > > depends on geoip-c-api. I've got both covered, but both of them
> >> > > want (either to download or to be present) for tests (a/the)
> >> > > legacy database file of maxmind.
> >> > >
> >> > > Question 1: Can we distribute the database in a source? I can't
> >> > > access the homepage of maxmind for cloudflare reasons.
> >> > 
> >> > The database is distributed freely under cc-by-sa4.0:
> >> > 
> >> > https://dev.maxmind.com/geoip/legacy/geolite/#License
> >> > 
> >> > So packaging it should be fine. :)
> >> 
> >> This actually raises the issue of packaging large data files (we are
> >> getting into TB's). Could there be a way Guix fetches external
> >> datasets as part of the distribution? I think that if it is not
> >> executable code and SHA values/pfff values match it would be safe to
> >> do.
> >> 
> >
> > The other thing is that guix downloads the files into ram and then
> > writes them into the store, which can be a problem if the source is
> > larger than the available memory.
> >
> > -- 
> > Efraim Flashner  אפרים פלשנר
> > GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
> > Confidentiality cannot be guaranteed on emails sent or received unencrypted
> 
> TB? Oh. Due to cloudflare I had no clue how big this is. In this
> case, for the current state of the way we distribute packages is
> not itself using a distributed network (if just keeping the space
> on hydra is the problem?), I would suggest that I package the
> updater I mentioned and mention it in the description for other
> MaxMind software.
> 
> This database is also an optional dependency for tor and not just
> ooni if I understand it correctly, so even if it's not 100%
> accurate (their commercial solution claims to be more accurate)
> it would be nice to find a way to include it.
> But I think size is really an issue, for example Gentoo dropped
> the database from their source distribution network and points
> users to the updater I mentioned (that's how I learned about the
> updater).
> -- 
> ♥Ⓐ  ng0 -- https://www.inventati.org/patternsinthechaos/
> 

-- 
GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
GnuPG: https://c.n0.is/ng0_pubkeys/tree/keys
  WWW: https://n0.is


signature.asc
Description: PGP signature

Re: 01/02: gnu: openssl@1.0: Replace with 1.0.2m [fixes CVE-2017-3735, CVE-2017-2736].

[Ludovic Courtès]

Leo Famulari  skribis:

> On Thu, Nov 02, 2017 at 05:22:34PM -0400, Marius Bakke wrote:
>> commit 1df4f5c919937b60bfb21ac2a60d8f0a6737c421
>> Author: Marius Bakke 
>> Date:   Thu Nov 2 22:11:25 2017 +0100
>> 
>> gnu: openssl@1.0: Replace with 1.0.2m [fixes CVE-2017-3735, 
>> CVE-2017-2736].
>> 
>> * gnu/packages/tls.scm (openssl)[replacement]: New field.
>> (openssl-1.0.2m): New public variable.
>
> [...]
>
>> +;; Fixes CVE-2017-3735 and CVE-2017-3736.
>> +;; See .
>> +(define-public openssl-1.0.2m
>
> In the early days of recursive grafts, Mark replaced libgcrypt with a
> public variable, and it was resolved non-deterministically. We ended up
> having to make the replacement private:
>
> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=69aa6e0995b55a38d5ce174602a107645be726d5
>
> I remember doing something like this and getting different results
> randomly:
>
> $ while true; do guix build --source openssl@1.0.2 ;done
> guix build: warning: ambiguous package specification `openssl@1.0.2'
> guix build: warning: choosing openssl@1.0.2m from gnu/packages/tls.scm:402:2
> /gnu/store/3hsffv38zzn3pafzr3g4x6mwqmxcmnr5-openssl-1.0.2m.tar.xz
> [...]
>
> But now it seems to consistently pick the correct package.
>
> Did the implementation change to ensure that it does the right thing?

Under the hood package lookup in this case uses ‘find-packages-by-name’
from (gnu packages).

That thing builds a lookup table (a vhash) by iterating over the
packages with ‘fold-packages’; in turn it uses ‘all-modules’, which is
deterministic (thanks to ‘scandir*’), and
‘fold-module-public-variables’, which *could* be non-deterministic due
to ‘module-map’ I think (because it iterates over a hash table.)

However, ‘find-packages-by-name’ sorts entries by version, so in this
specific case, we’ll always pick 1.0.2m over 1.0.2l.

Non-determinism can occur if we have two or more packages with the exact
same version string.

Thanks,
Ludo’.

Re: boot the Hurd with Guix

[ranvijay vijay]

Keep up the good work! 😊

On Tuesday, November 28, 2017, Daniel Pimentel  wrote:

> Cool! Thanks,
>
> ---
> Daniel Pimentel (d4n1)
>
> Em 2017-11-27 22:16, ren...@openmailbox.org escreveu:
>
>> Hello,
>>
>> I update the download link:
>>
>> https://ombx.io/ipoWt9uK
>>
>
>

Re: Idea: Install script to better support improving contributor-friendliness of projects

[myglc2]

On 11/26/2017 at 15:35 Mark H Weaver writes:

> Hi,
>
> Никита Чураев  writes:
>
>> Here's how I want to use Guix and it is to increase
>> contributor-friendliness of a project, so that the user can simply run
>> a distribution-independent command to install all dependencies without
>> having to hunt for them with `apt` and `dnf` manually.
>>
>> Unfortunately, Guix itself is not very easy to install, and the
>> instructions are full of rather technical stuff like 'systemd' and
>> 'upstart'.
>>
>> https://www.gnu.org/software/guix/manual/html_node/Binary-Installation.html
>>
>> There should be a script like the one Haskell Stack uses:
>>
>> |curl -sSL https://get.haskellstack.org/ | sh|

Agreed, thank you for raising these issues.

As you point out, the current manual binary install imposes a minimum
bound on the technical sophistication and determination of Guix
"triers". The absence of an automated install effectively filters out
"less sophisticated" users. It no doubt strongly limits the rate of
adoption and size of the user base.

Something like you have suggested is a must to reach a larger audience.
Not having it is like an exclusionary fence around Guix.  If we are
committed to usability and availability of Guix for anyone, we should
provide an automated install. Why haven't we done this yet?  Probably
because no Guix developer has to in/uninstalled Guix on multiple
GNU/Linux distributions every day ;-)

> I can understand the appeal of such a convenient approach.  However,
> this practice of downloading a script via HTTPS and immediately running
> it as root without inspection puts you at considerable risk.  A
> man-in-the-middle with the resources to compromise or bribe *any*
> certificate authority in your trust store (the attacker could choose
> which one) could acquire a fraudulent certificate to impersonate our
> site, and then substitute in a different script than the one we
> provided.  Quite a few organizations are capable of such an attack
> today.
>
> Therefore, I believe it would be irresponsible for us to promote this
> style of installation.
>
> However, if there's sufficient interest, and if we could produce a
> sufficiently robust "auto-install" script, we could perhaps do something
> close to what you suggested.  We could provide a script along with a
> GnuPG digital signature.  We could ask the user to download the script,
> acquire our signing key, verify the signature on the script, and then
> run the script as root.

+1

WRT "sufficient interest", script users will be the prospective Guix
users that today hit a wall on the manual install.  This number no doubt
exceeds all Guix users today ;-)

ISTM, these are the downsides to releasing such a script:

1) increased "less sophisticated" Guix noob support load

2) stress-tests of Guix package management usability

3) increased hydra etal loads

Re: GeoIP database redistribution?

[Pjotr Prins]

On Tue, Nov 28, 2017 at 04:19:37PM +, ng0 wrote:
> And Pjotr, the mentioning of TB's without any reference to an
> external project really threw me off. Just specify the "We" next
> time ;)

Sorry. I am talking biological data ;).

Pj.

Re: [PATCH] scripts: hash: Add --git option. WIP

[Jan Nieuwenhuizen]

Andy Wingo writes:

>>guix hash --git HEAD
>>guix hash --git v0.13
>>
>> WDYT?
>
> Weird that we have done the same thing :)
>
> https://git.savannah.gnu.org/gitweb/?p=guix.git;a=commit;h=572907daff98a77a4215861a88b81d2f30542c09

:-) Nice!...on what branch is that?  You did see Ludo's suggestions?  I like
them and planned to look at them when my mind is less occupied with
bootstrapping.

janneke

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

Re: [PATCH] scripts: hash: Add --git option. WIP

[Leo Famulari]

On Tue, Nov 28, 2017 at 07:57:32PM +0100, Jan Nieuwenhuizen wrote:
> Andy Wingo writes:
> > Weird that we have done the same thing :)
> >
> > https://git.savannah.gnu.org/gitweb/?p=guix.git;a=commit;h=572907daff98a77a4215861a88b81d2f30542c09
> 
> :-) Nice!...on what branch is that?  You did see Ludo's suggestions?  I like
> them and planned to look at them when my mind is less occupied with
> bootstrapping.

I wasn't sure how to figure this out, so here's how to do it:

$ git branch --remote --contains 572907daff98a77a4215861a88b81d2f30
  origin/wip-potluck


signature.asc
Description: PGP signature

Re: Idea: Install script to better support improving contributor-friendliness of projects

[lamefun . x0r]

Another question, is Guix ever going to ship NVIDIA OpenGL libraries,
considering that this is a GNU project? Flatpak for example ships them
to support NVIDIA GPUs. The project I want to make contributor-friendly 
with help of Guix is a 3D game, so without them Guix is essentially
useless as a dependency installer for many of the potential
contributors.

I managed to launch SuperTux, by forcing it to use system libraries:

LD_PRELOAD="/usr/lib64/libGL.so.1 /usr/lib64/libGLX.so.0 \
/usr/lib64/libX11.so.6 /usr/lib64/libXext.so.6 \
/usr/lib64/libGLdispatch.so.0 /usr/lib64/libxcb.so.1 \
/usr/lib64/libXau.so.6" supertux2

This probably not possible to reliably automate and certainly is
segfault-prone though...

New template for 'guix' made available

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.  (If you have
any questions, send them to .)

A new POT file for textual domain 'guix' has been made available
to the language teams for translation.  It is archived as:

http://translationproject.org/POT-files/guix-0.14.0.pot

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

Below is the URL which has been provided to the translators of your
package.  Please inform the translation coordinator, at the address
at the bottom, if this information is not current:

http://www.fdn.fr/~lcourtes/tmp/guix-0.14.0tp.tar.gz

We can arrange things so that translated PO files are automatically e-mailed
to you when they arrive.  Ask at the address below if you want this.

Thank you for all your work,

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

New template for 'guix-packages' made available

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.  (If you have
any questions, send them to .)

A new POT file for textual domain 'guix-packages' has been made available
to the language teams for translation.  It is archived as:

http://translationproject.org/POT-files/guix-packages-0.14.0.pot

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

Below is the URL which has been provided to the translators of your
package.  Please inform the translation coordinator, at the address
at the bottom, if this information is not current:

http://www.fdn.fr/~lcourtes/tmp/guix-0.14.0tp.tar.gz

We can arrange things so that translated PO files are automatically e-mailed
to you when they arrive.  Ask at the address below if you want this.

Thank you for all your work,

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

Re: Idea: Install script to better support improving contributor-friendliness of projects

[Leo Famulari]

On Tue, Nov 28, 2017 at 10:43:49PM +0300, lamefun@gmail.com wrote:
> Another question, is Guix ever going to ship NVIDIA OpenGL libraries,
> considering that this is a GNU project? Flatpak for example ships them
> to support NVIDIA GPUs. The project I want to make contributor-friendly 
> with help of Guix is a 3D game, so without them Guix is essentially
> useless as a dependency installer for many of the potential
> contributors.

Are those libraries free software?

If not, no, we'll never include them in GNU Guix.

But Guix is free software, which means one can use it however they like.
So there is nothing stopping someone from packaging nonfree software and
distributing the packages on their own.


signature.asc
Description: PGP signature

Re: Idea: Install script to better support improving contributor-friendliness of projects

[Adonay Felipe Nogueira]

Contributing to what Leo Famulari said:

Guix already allows you to setup a repository yourself for all of those
who use GNU Guix package manager. I think the command was `guix
publish'?

>From there on, unless the repository maintainers are commited to follow
the GNU FSDG, the official GNU Guix community will not be able to
recommend it to the general public.

2017-11-28T22:43:49+0300 lamefun@gmail.com wrote:
> Another question, is Guix ever going to ship NVIDIA OpenGL libraries,
> considering that this is a GNU project? Flatpak for example ships them
> to support NVIDIA GPUs. The project I want to make contributor-friendly 
> with help of Guix is a 3D game, so without them Guix is essentially
> useless as a dependency installer for many of the potential
> contributors.
>
> I managed to launch SuperTux, by forcing it to use system libraries:
>
> LD_PRELOAD="/usr/lib64/libGL.so.1 /usr/lib64/libGLX.so.0 \
> /usr/lib64/libX11.so.6 /usr/lib64/libXext.so.6 \
> /usr/lib64/libGLdispatch.so.0 /usr/lib64/libxcb.so.1 \
> /usr/lib64/libXau.so.6" supertux2
>
> This probably not possible to reliably automate and certainly is
> segfault-prone though...
>
>

-- 
- https://libreplanet.org/wiki/User:Adfeno
- Palestrante e consultor sobre /software/ livre (não confundir com
  gratis).
- "WhatsApp"? Ele não é livre. Por favor, veja formas de se comunicar
  instantaneamente comigo no endereço abaixo.
- Contato: https://libreplanet.org/wiki/User:Adfeno#vCard
- Arquivos comuns aceitos (apenas sem DRM): Corel Draw, Microsoft
  Office, MP3, MP4, WMA, WMV.
- Arquivos comuns aceitos e enviados: CSV, GNU Dia, GNU Emacs Org, GNU
  GIMP, Inkscape SVG, JPG, LibreOffice (padrão ODF), OGG, OPUS, PDF
  (apenas sem DRM), PNG, TXT, WEBM.

Re: 01/05: gnu: guix: Provide the correct version string.

[Mark H Weaver]

l...@gnu.org (Ludovic Courtès) writes:

> civodul pushed a commit to branch master
> in repository guix.
>
> commit 91c619ebdfd065f0becbbcc742dc412dc41e77a1
> Author: Ludovic Courtès 
> Date:   Tue Nov 28 13:25:04 2017 +0100
>
> gnu: guix: Provide the correct version string.
> 
> Fixes .
> Reported by Arun Isaac .
> 
> * gnu/packages/package-management.scm (guix)[arguments]: Move
> 'bootstrap' phase before 'configure'.  Create '.tarball-version' file.
> ---
>  gnu/packages/package-management.scm | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/gnu/packages/package-management.scm 
> b/gnu/packages/package-management.scm
> index 15c310d..6d18fa0 100644
> --- a/gnu/packages/package-management.scm
> +++ b/gnu/packages/package-management.scm
> @@ -136,13 +136,17 @@
>  (ice-9 rdelim))
>  
>   #:phases (modify-phases %standard-phases
> -(add-after 'unpack 'bootstrap
> +(add-before 'configure 'bootstrap

This change works directly against my efforts to move all of these
'bootstrap' phases after 'unpack' instead of before 'configure'.  This
ordering is important because on some systems, e.g. mips64el-linux, it's
important for the 'patch-usr-bin-file' phase to fix the generated
autoconf scripts.  As I vaguely recall, on some systems, autoconf
generates calls to '/usr/bin/file' to determine the ABI of compiled
binaries.

Can we fix this issue in another way?

  Mark

Re: Idea: Install script to better support improving contributor-friendliness of projects

[Pjotr Prins]

On Tue, Nov 28, 2017 at 10:43:49PM +0300, lamefun@gmail.com wrote:
> Another question, is Guix ever going to ship NVIDIA OpenGL libraries,
> considering that this is a GNU project? Flatpak for example ships them
> to support NVIDIA GPUs. The project I want to make contributor-friendly 
> with help of Guix is a 3D game, so without them Guix is essentially
> useless as a dependency installer for many of the potential
> contributors.

OpenGL is free software though possibly underlying CUDA is not. We
started work on it here:

  
https://github.com/Brainiarc7/guix-bioinformatics/blob/master/gn/packages/cl.scm

but never got it to work properly.

> I managed to launch SuperTux, by forcing it to use system libraries:
> 
> LD_PRELOAD="/usr/lib64/libGL.so.1 /usr/lib64/libGLX.so.0 \
> /usr/lib64/libX11.so.6 /usr/lib64/libXext.so.6 \
> /usr/lib64/libGLdispatch.so.0 /usr/lib64/libxcb.so.1 \
> /usr/lib64/libXau.so.6" supertux2
> 
> This probably not possible to reliably automate and certainly is
> segfault-prone though...

Yes, and worse, there is no guarantee that they are the same on a
user's system. What you want is a reproducible setup.

I think packaging your game with OpenCL is possible with GNU Guix. You
can ask people here how they are deploying their software.

Distributing the game is possible too. Even installing user land
directories - using my installer

  https://gitlab.com/pjotrp/guix-relocatable-binary-packages

would be straightforward to accomplish.

Pj.

-- 

Re: java: switch to icedtea-8 as default JDK

[Chris Marusich]

Gábor Boskovits  writes:

> Hello!
>
> I just run a quick grep to see which files might be interesting.
>
> We use ant-build-system in:
> axoloti.scm *
> bioinformatics.scm *
> compression.scm *
> icu4c.scm
> java.scm *
> libusb.scm *
> music.scm *
> textutlis.scm
> uml.scm *
> version-control.scm *
> web.scm *
> xml.scm
>
> Only the ant-build system uses icedtea among build systems.
>
> Icedtea is explicitly metioned in the ones maked with *, and:
> kodi.scm
> math.scm
> ruby.scm
>
> We have a definition in place where currently icedtea is defined to be
> icedtea-7.
> I guess we could just flip that to icedtea-8, and check what still works.
> That would flip the version in the build system also, as it uses "icedtea".
>
> Should I check which packages are affected in advance, or just go with the
> build and see what does not work?

Another way to check what packages we'll need to try to build is to use
"guix refresh", which uses some features of (guix graph) to display
information about dependent packages.  Here's what we get for icedtea-7:

--8<---cut here---start->8---
[0] marusich@garuda.local:~/guix
$ ./pre-inst-env guix refresh -l -e '(@ (gnu packages java) icedtea-7)'
Building the following 39 packages would ensure 202 dependent packages are 
rebuilt: sra-tools@2.8.2-1 minced@0.2.0 r-seurat@1.4.0.12-1.fccb77d ant@1.10.1 
java-htsjdk@1.129 java-jdom@1.1.3 clojure@1.8.0 java-osgi-service-jdbc@1.0.0 
java-plexus-interpolation@1.23 java-commons-daemon@1.0.15 java-commons-net@3.6 
java-commons-cli@1.2 java-commons-lang@2.6 java-jmh@1.17.5 tuxguitar@1.4 
java-commons-collections4@4.1 java-javax-mail@1.5.6 f-seq@1.1-1.6ccded3 
java-commons-beanutils@1.9.3 java-jgit@4.7.0.201704051617-r 
java-osgi-service-resolver@1.0.1 java-osgi-service-packageadmin@1.2.0 
java-osgi-service-cm@1.5.0 java-osgi-util-tracker@1.5.1 antlr3@3.5.2 
java-eclipse-team-core@3.8.0 java-httpcomponents-httpcore-ab@4.4.6 
java-httpcomponents-httpmime@4.5.3 java-httpcomponents-httpcore-nio@4.4.6 
java-plexus-container-default@1.7.1 kodi@18.0_alpha-6-f22d62d hdf-java@3.3.2 
ruby-atoulme-antwrap@0.7.5 plantuml@8048 java-guice-servlet@4.1 
java-eclipse-jetty-servlet@9.4.6 java-eclipse-jetty-servlet@9.2.22 
icedtea-web@1.6.2 axoloti-patcher@1.0.12
--8<---cut here---end--->8---

So, I think we should probably do the following:

1) Confirm that these packages build before making changes.  If any
fail, fix them first if possible.

2) As you suggested, flip the icedtea variable to point to icedtea-8
instead of icedtea-7.

3) Repeat the builds, and see what fails.  Fix any new breakage.

And of course, we should opportunistically clean up package definitions
as we go.

I'm going to try step (1) tonight on my laptop.  Is there a way to check
their build status on Hydra, I wonder?  I'm planning to just do it in a
simple shell one-liner like the following:

--8<---cut here---start->8---
for pkg in $(> /tmp/log; else echo failure: $pkg >> /tmp/log; fi; done
--8<---cut here---end--->8---

...but I'm sure there is probably a more elegant way to accomplish the
same task.  Anyway, I'll let you know how it goes.

> As first step it is not needed to remove #:jdk icedtea-8 references,
> because I think that simply becomes a noop. Am I right here?
> That can be done as the last step before merging, I guess.

I think that's right, but I haven't looked closely yet, and Ricardo may
know more.

-- 
Chris


signature.asc
Description: PGP signature

Re: java: switch to icedtea-8 as default JDK

[Chris Marusich]

Chris Marusich  writes:

> Gábor Boskovits  writes:
>
>> Hello!
>>
>> I just run a quick grep to see which files might be interesting.
>>
>> We use ant-build-system in:
>> axoloti.scm *
>> bioinformatics.scm *
>> compression.scm *
>> icu4c.scm
>> java.scm *
>> libusb.scm *
>> music.scm *
>> textutlis.scm
>> uml.scm *
>> version-control.scm *
>> web.scm *
>> xml.scm
>>
>> Only the ant-build system uses icedtea among build systems.
>>
>> Icedtea is explicitly metioned in the ones maked with *, and:
>> kodi.scm
>> math.scm
>> ruby.scm
>>
>> We have a definition in place where currently icedtea is defined to be
>> icedtea-7.
>> I guess we could just flip that to icedtea-8, and check what still works.
>> That would flip the version in the build system also, as it uses "icedtea".
>>
>> Should I check which packages are affected in advance, or just go with the
>> build and see what does not work?
>
> Another way to check what packages we'll need to try to build is to use
> "guix refresh", which uses some features of (guix graph) to display
> information about dependent packages.  Here's what we get for icedtea-7:
>
> [0] marusich@garuda.local:~/guix
> $ ./pre-inst-env guix refresh -l -e '(@ (gnu packages java) icedtea-7)'
> Building the following 39 packages would ensure 202 dependent packages are 
> rebuilt: sra-tools@2.8.2-1 minced@0.2.0 r-seurat@1.4.0.12-1.fccb77d 
> ant@1.10.1 java-htsjdk@1.129 java-jdom@1.1.3 clojure@1.8.0 
> java-osgi-service-jdbc@1.0.0 java-plexus-interpolation@1.23 
> java-commons-daemon@1.0.15 java-commons-net@3.6 java-commons-cli@1.2 
> java-commons-lang@2.6 java-jmh@1.17.5 tuxguitar@1.4 
> java-commons-collections4@4.1 java-javax-mail@1.5.6 f-seq@1.1-1.6ccded3 
> java-commons-beanutils@1.9.3 java-jgit@4.7.0.201704051617-r 
> java-osgi-service-resolver@1.0.1 java-osgi-service-packageadmin@1.2.0 
> java-osgi-service-cm@1.5.0 java-osgi-util-tracker@1.5.1 antlr3@3.5.2 
> java-eclipse-team-core@3.8.0 java-httpcomponents-httpcore-ab@4.4.6 
> java-httpcomponents-httpmime@4.5.3 java-httpcomponents-httpcore-nio@4.4.6 
> java-plexus-container-default@1.7.1 kodi@18.0_alpha-6-f22d62d hdf-java@3.3.2 
> ruby-atoulme-antwrap@0.7.5 plantuml@8048 java-guice-servlet@4.1 
> java-eclipse-jetty-servlet@9.4.6 java-eclipse-jetty-servlet@9.2.22 
> icedtea-web@1.6.2 axoloti-patcher@1.0.12
>
>
> So, I think we should probably do the following:
>
> 1) Confirm that these packages build before making changes.  If any
> fail, fix them first if possible.
>
> 2) As you suggested, flip the icedtea variable to point to icedtea-8
> instead of icedtea-7.
>
> 3) Repeat the builds, and see what fails.  Fix any new breakage.
>
> And of course, we should opportunistically clean up package definitions
> as we go.
>
> I'm going to try step (1) tonight on my laptop.  Is there a way to check
> their build status on Hydra, I wonder?  I'm planning to just do it in a
> simple shell one-liner like the following:
>
> for pkg in $( success: $pkg >> /tmp/log; else echo failure: $pkg >> /tmp/log; fi; done
>
> ...but I'm sure there is probably a more elegant way to accomplish the
> same task.  Anyway, I'll let you know how it goes.
>
>> As first step it is not needed to remove #:jdk icedtea-8 references,
>> because I think that simply becomes a noop. Am I right here?
>> That can be done as the last step before merging, I guess.
>
> I think that's right, but I haven't looked closely yet, and Ricardo may
> know more.

Whoops!  I forgot to include Gábor on my last email, so I've included
Gábor on this one.  Sorry about that.

-- 
Chris


signature.asc
Description: PGP signature