Source tarballs from PyPI versus tarballs from the individual project websites

[Arun Isaac]

When packaging python packages, why are we using the source tarballs
hosted on PyPI, rather than using the source tarballs hosted on the
websites of the individual projects?

For example, for the package python-pycrypto, why are we using the
tarball from PyPI
https://pypi.python.org/packages/source/p/pycrypto/pycrypto-2.6.1.tar.gz
instead of the tarball from the pycrypto project website
https://ftp.dlitz.net/pub/dlitz/crypto/pycrypto/pycrypto-2.6.1.tar.gz ?

Using the PyPI tarball seems to make Guix dependent on another package
repository -- namely, PyPI. That seems to me a bad thing.

I have packaged a few python packages using the tarballs from their
respective project websites. Should I change them to use the PyPI
tarballs before contributing the package definitions to Guix? Which
tarball should I prefer?

Regards,
Arun


signature.asc
Description: PGP signature

GNU IceCat 45 beta now available in Guix

[Mark H Weaver]

Hello Guix,

I'm pleased to announce the availability of GNU IceCat 45.3.0-gnu1-beta
with selected fixes cherry-picked from upstream, including all security
fixes introduced in Firefox ESR 45.4.0, specifically:

  CVE-2016-5250 - Resource Timing API is storing resources sent by
  the previous page
  CVE-2016-5257 - Memory safety bugs fixed in Firefox 49 and Firefox ESR 45.4
  CVE-2016-5261 - Integer overflow and memory corruption in WebSocketChannel
  CVE-2016-5270 - Heap-buffer-overflow in
  nsCaseTransformTextRunFactory::TransformString
  CVE-2016-5272 - Bad cast in nsImageGeometryMixin
  CVE-2016-5274 - use-after-free in nsFrameManager::CaptureFrameState
  CVE-2016-5276 - Heap-use-after-free in
  mozilla::a11y::DocAccessible::ProcessInvalidationList
  CVE-2016-5277 - Heap-use-after-free in nsRefreshDriver::Tick
  CVE-2016-5278 - Heap-buffer-overflow in nsBMPEncoder::AddImageFrame
  CVE-2016-5280 - Use-after-free in
  mozilla::nsTextNodeDirectionalityMap::RemoveElementFromMap
  CVE-2016-5281 - use-after-free in DOMSVGLength
  CVE-2016-5284 - Add-on update site certificate pin expiration

   Mark

Re: CPU-specific builds

[Ludovic Courtès]

Ben Woodcroft  skribis:

> On 02/10/16 23:33, Ludovic Courtès wrote:

[...]

>>> So I'm wondering if there is some way to specify a system more
>>> specific than 'X86_64'? I tried simply adding '--with-arch=haswell' as
>>> a configure argument in gcc-4.9 so that flag became the default for
>>> gcc usage and saw some performance improvements, though I did have to
>>> disable tests in gnutls.
>> Do you have performance figures for some CPU-intensive applications?
>>
>> What software are you most interested in?
> We tend to run software whose runtime is dependent on the input data,
> so it is hard to say. But up to days or weeks of walltime in some
> cases. It takes a lot of power researching climate change..
>
> As an anecdote, adding "-march=haswell" shaved 13% off the runtime of
> diamond, ~20% if the CPUs were contended.

That’s more than I expected.  It’d be useful to have a way to specify
this.

>> Ideally, software for which using these CPU extensions makes a
>> significant difference would do what glibc does, which is to provide
>> several implementations of the relevant functions (one for SSE2, one for
>> AVX, etc.) and have the right one be selected at load time via an IFUNC
>> or similar mechanism.
> That sounds useful in some cases, but it is probably too much of a
> stretch for most bioinformatics packages.

Yeah.

> In the end I think I'll just compile the specific packages we are
> specifically interested in. I attached some example code in case
> anyone is interested. But this brought up a few questions:
>
> 1) I also tried using --expression e.g. guix build --expression '(@@
> (my packages cpu-specific) diamond-cpu-specific)' but that fails to
> compile as if the GUIX_PACKAGE_PATH is ignored, is that unexpected?

What error did you get?

> 2) Is something amiss with gcc-toolchain-6? Compiling with it, diamond
> complains of a missing stdlib.h.

Everything’s fine AFAICS.  However, note that ‘gnu-build-system’ pulls
in GCC 4.9, glibc, etc.  If you add ‘gcc-toolchain’ to the inputs, that
surely conflicts, but I’m unsure which one “wins”; could you check the
‘environment-variables’ file in a build tree?

> (define-public gcc-cpu-specific
>   (let ((base gcc-5)) ; gcc-6 does not seem to work.
> (package
>  (inherit base)
>  (name "gcc-cpu-specific")
>  (arguments
>   (substitute-keyword-arguments (package-arguments base)
> ((#:configure-flags configure-flags)
>  `(append ,configure-flags
>   (list (string-append
>  "--with-arch=" ,cpu)
>
> (define-public (cpu-specific-package base-package)
>   (package
> (inherit base-package)
> (name (package-name base-package))
> ;; We must set a higher package version so this package is used instead of
> ;; the package in Guix proper.
> (version (string-append (package-version base-package) "-cpu-specific"))
> (inputs
>  `(,@(package-inputs base-package)
>("gcc" ,((@@ (gnu packages commencement)
> gcc-toolchain) gcc-cpu-specific))
>
> (define-public diamond-cpu-specific (cpu-specific-package diamond))
> (define-public fasttree-cpu-specific (cpu-specific-package fasttree))
> (define-public blast+-cpu-specific (cpu-specific-package blast+))
> (define-public bwa-cpu-specific (cpu-specific-package bwa))
> (define-public metabat-cpu-specific (cpu-specific-package metabat))

Looks like the right way to start.

We should start thinking about what the ideal interface would look like,
though.  At the highest level, I imagine we’d want something like:

  guix package --tune=haswell -i diamond

Under the hood that could work by having an arbitrary list of key/value
options passed to build systems, rather than just the system type and
cross-compilation target as is currently the case.

Food for thought…

Ludo’.

Re: Patches to implement system roll-back and switch-generation

[Ludovic Courtès]

Hello,

Chris Marusich  skribis:

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

[...]

>> Sorry about that!  Hopefully we can work around the conflicts.
>
> I think we can.  But I think it will require backwards incompatible
> changes to the boot parameters file.  Here's why:
>
> Many of the existing procedures in (gnu system grub) take a "file
> system" object as input (e.g. the 'grub-configuration-file' procedure).
> However, the boot parameters file does not currently contain all the
> information that a "file system" object contains.

Good point.  This ‘store-fs’ argument was added in response to
.

> Here's an example of what it contains today:
>
> (boot-parameters
>   (version 0)
>   (label "GNU with Linux-Libre 4.1.20 (beta)")
>   (root-device "root")
>   (kernel
> "/gnu/store/zygby8db0adcyj3m6rjflr80jarfy9b5-linux-libre-4.1.20")
>   (kernel-arguments ())
>   (initrd
> (string-append
>   "/gnu/store/hlra3a0g3a14bjvdn3vbagwfvy4nmhn8-base-initrd"
>   "/initrd")))
>
> To avoid backwards-incompatible changes to the structure of the boot
> parameters file, I had originally planned to refactor the procedures in
> (gnu system grub) so that I could use them with the limited information
> that is contained in the version 0 boot parameters file.  However,
> commit 0f65f54e has modified these procedures in a way that makes it
> very awkward to refactor the "file system" object out of them.  Now, to
> re-use the existing procedures, I believe I will need to add this
> missing information (i.e., the information contained in a file system
> object) to the boot parameters file, so that I can construct a "file
> system" object to pass to those procedures.  Does that sound right to
> you?

Yes, I think so.

More precisely, I think we need to add a ‘device’ field to ,
which could be the UUID or label of the device where the kernel and
initrd are to be found, or #f, in which case grub.cfg would contain a
“search --file” command (instead of “search --label” or “search
--fs-uuid”).

Correspondingly, we’d add a ‘device’ (or ‘boot-device’?) field to
.  The key is that ‘device’ can be different from
‘root-device’ because the store and root devices can be different from
one another.

That way we could remove the ‘store-fs’ parameter of
‘grub-configuration-file’ since that information would now be contained
in each .

> If I do that, then it will probably be a backwards-incompatible change,
> so I will do it in the following way.  I will simply store an entire
> "file system" object in the boot parameters file.  I will bump the
> version of the boot parameters file from 0 to 1.  To ensure that all new
> system generations use version 1, I will update commands like
> "reconfigure" to always create a version 1 boot parameters file.  I will
> make the new commands (roll-back and switch-generation) refuse to switch
> to any system generation which uses version 0 (because it isn't possible
> to construct a complete "file system" object from a version 0 boot
> parameters file).  I will also update existing commands like
> 'list-generations' so that they will gracefully handle both versions.
>
> Does this sound like the right approach to you?

I think we don’t need to bump the version number: ‘read-boot-parameters’
can simply do what it currently does for ‘initrd’ and
‘kernel-arguments’, which is to provide a default value when they’re
missing.  Here the default value could be ‘root-device’.

> I've tried using 'git send-email' on GuixSD before, and it didn't work
> for me (because a mail transfer agent is not running on my GuixSD
> system).  When the new patches are ready, I'll try once more to get it
> working.

AFAICT an MTA is not needed.

>>> -  "Return the GRUB configuration file corresponding to CONFIG, a
>>> - object, and where the store is available at STORE-FS, 
>>> a
>>> - object.  OLD-ENTRIES is taken to be a list of menu entries
>>> -corresponding to old generations of the system."
>>> +  "Return a derivation which builds the GRUB configuration file 
>>> corresponding
>>> +to CONFIG, a  object, and where the store is available 
>>> at
>>> +STORE-FS, a  object.  OLD-ENTRIES is taken to be a list of 
>>> menu
>>> +entries corresponding to old generations of the system."
>>
>> OK, although I often write “Return something” when that really means
>> “Return a derivation that builds something”.
>
> Upon closer inspection, it looks like this procedure,
> 'grub-configuration-file', actually returns a monadic value (in the
> store monad), which "contains" a derivation, which in turn builds the
> grub configuration file.  Even in a case like this, where there is so
> much indirection, is it appropriate to elide all those details?
>
> If this is the style we should consistently use in our documentation,
> then that's fine, and I will happily follow suit in the name of
> consistency.  However, as a newcomer to this code base, to gexps, to
> derivations, and to monads, in the beginning I was v

Re: [PATCH (4)] gnu: Add NFS related services. (minor improvements to documentation; Added test to ensure that pipefs mount/umount succeeded()

[Ludovic Courtès]

Hi,

John Darrington  skribis:

> Yet another patch.  Here I check that the mount/umount succeeds by testing 
> that 
> /var/lib/nfs/pipefs is a member of the list returned by (mount-points).

OK.

> Regarding Ludo's suggestion to use a filesystem extention a la elogind - I 
> have
> looked into that possibility, but so far as I can see using a service 
> extension 
> does not allow a "provision" field, so I don't know how to make the other 
> services
> dependent upon it.  Also I don't see from the elogind example how to specify 
> an 
> alternative mount point and then to pass that mount point to dependent 
> services.
> (I cannot imagine why anyone would want to do that, but hey - guix is 
> supposed to
> be hackable!)   I'd be happy to change it later if someone can explain how to 
> do it.

Yes, let’s keep it for later.

For future reference, as I wrote in
,
the Shepherd service corresponding to the file system object would be
called ‘file-system-/var/lib/nfs/pipefs’.  This is the name you would
write in ‘requirement’.

>
>
>
>
> * gnu/services/nfs.scm (pipefs-service-type): New Variable,
> (gss-service-type): New Variable, (idmap-service-type) New Variable.
>
> * doc/guix.texi (Network File system): New Node.

No need to capitalize “node” and “variable.”

OK with this patch, thank you!

Ludo’.

Re: [PATCH 2/5] gnu: python-pytest-xdist: Remove python byte-code files from source.

[Danny Milosavljevic]

On Mon, 10 Oct 2016 15:10:00 +0200
Hartmut Goebel  wrote:

> +'(begin
> +   ;; Source archive contains .pyc files
> +   (for-each delete-file-recursively
> + (find-files "." "__pychache__" #:directories? #t))

 ^^ should this be 
"__pycache__" ?

Re: Contents of /etc/hosts

[Ludovic Courtès]

Hello!

John Darrington  skribis:

> On Wed, Oct 05, 2016 at 10:17:14PM +0200, Ludovic Court??s wrote:
>  Hi!
>  
>  John Darrington  skribis:
>  
>  > So ... my recommendations:
>  >
>  > 1. We change /etc/hosts to read
>  >
>  >
>  >  127.0.0.1 localhost.localdomain localhost 
>  >  ::1   localhost.localdomain localhost
>  >
>  >  127.0.0.2 gambrinus
>  
>  It???s not very useful to have ???localhost.localdomain???, is it?  
>
> Try doing this:  Put just a single line in your /etc/hosts: 
> 127.0.0.1 localhost
> then run "hostname -d"
>
> You will get the answer "(none)"

Right.

But “localhost.localdomain” is kinda pointless no?  I’ve checked a few
systems and I’ve never seen that.  Typical desktop GNU/Linux installs
don’t have an FQDN and “hostname -d” doesn’t return one; that’s fine.

I think the current default is OK, but we should allow people to specify
an FQDN when there’s a meaningful one.

Thoughts?

Ludo’.

Re: [PATCH v2 0/4] Add GCC cross compiler for arm-none-eabi.

[theodoros . for]

Hi Ricardo,

diff --git a/gnu/packages/patches/gcc-6-arm-none-eabi-multilib.patch 
b/gnu/packages/patches/gcc-6-arm-none-eabi-multilib.patch

new file mode 100644
index 000..442f52b
--- /dev/null
+++ b/gnu/packages/patches/gcc-6-arm-none-eabi-multilib.patch
@@ -0,0 +1,201 @@
+From Anatol Pomozov 
+Taken from Arch Linux arm-none-eabi-gcc package.
+
+Modified version of ARM patch 
https://gcc.gnu.org/ml/gcc-patches/2012-05/msg00083/enable-with-multilib-list-for-arm.patch

+


I’m not sure I understand what this patch does.  Could you please
provide an explanation why this patch is needed?  We usually add short
explanations to the top of each patch.


This patch enables the use of --with-multilib-list flag, when
configuring gcc 6.2. It makes gcc-6 compatible with the configure-flags
of gcc-arm-none-eabi-4.9.

Re: [PATCH] gnu: Build and install xonsh docs.

[Danny Milosavljevic]

Hi Ludo,

On Sun, 09 Oct 2016 23:59:15 +0200
l...@gnu.org (Ludovic Courtès) wrote:

> Is the URL change intended?  Is it needed?  If so, please add a comment
> above as to why the github.com tarball is preferred.

Yes. The github URL contains the docs, the other doesn't.

> Am I missing another patch that adds this package?

Yeah, see "gnu: Update Sphinx to 1.4.6."

> > +  ;; TODO jupyter distro
> > + `(("python-ply" ,python-ply)
> > +   ("python-prompt-toolkit" ,python-prompt-toolkit)))  
> 
> I’m not sure what the comment means.  Maybe remove it?

It has further optional dependencies that we haven't packaged yet - and that's 
how they are called.

Re: [PATCH 2/2] gnu: Add bluefish.

[rennes]

Hello,

some help to check my procedure is correct?.


If you do not have a branch, do the follwoing:

git checkout -b gnome-bluefish
# search for your two patches, e.g using "git reflog | grep gunimap"
and "git reflog | grep bluefish"
git cherry-pick abcdefg  # use commit-id of gunimap patch
git cherry-pick abcdefg  # use commit-id of bluefish patch


^
In this way it does not work for me.

$ git checkout -b gnome-blue
 Switched to a new branch 'gnome-blue'
$ git add gnu/packages/gnome.scm
$ git commit -m 'gnu: Add gucharmap.'
 [gnome-blue 8291bac] gnu: Add gucharmap.
  1 file changed, 33 insertions(+)
$ git add gnu/packages/gnome.scm
$ git commit -m 'gnu: Add bluefish.'
 [gnome-blue a9c8770] gnu: Add bluefish.
  1 file changed, 31 insertions(+)
$ git rebase master
 Current branch gnome-blue is up to date.
$ git format-patch master
 0001-gnu-Add-gucharmap.patch
 0002-gnu-Add-bluefish.patch

Then this produces two patches!, I attach to both?

Thanks.

Redis security fix release 3.2.4 now available

[Thompson, David]

I just pushed an update to our Redis package (commit
5f4194f68728531f09596bb359c58addf86efc5e) to address a security
vulnerability which has been out for 16 days:


https://github.com/antirez/redis/commit/6d9f8e2462fc2c426d48c941edeb78e5df7d2977

The set of people using Redis provided by Guix on production servers
is probably 0 at this time, but letting the list know just in case. ;)

- Dave

[PATCH] gnu: Add mlmmj.

[ng0]

* gnu/packages/mail.scm (mlmmj): New variable.
---
 gnu/packages/mail.scm | 52 +++
 1 file changed, 52 insertions(+)

diff --git a/gnu/packages/mail.scm b/gnu/packages/mail.scm
index baa5a96..fc0d8e5 100644
--- a/gnu/packages/mail.scm
+++ b/gnu/packages/mail.scm
@@ -1493,3 +1493,55 @@ transfer protocols.")
 (license (non-copyleft "file://LICENSE"
"See LICENSE in the distribution."
 
+(define-public mlmmj
+  (package
+(name "mlmmj")
+(version "1.2.19.0")
+(source
+ (origin
+   (method url-fetch)
+   (uri (string-append "http://mlmmj.org/releases/mlmmj-"; version 
".tar.bz2"))
+   (sha256
+(base32
+ "1piwvcxkqadjwk5x8jicaiyz9nngmaj3w13ghdqgaki32xd7zk9v"
+(build-system gnu-build-system)
+(inputs
+ `(("perl" ,perl))) ; "contrib/web/"
+(native-inputs
+ `(("pkg-config" ,pkg-config)))
+(arguments
+ `(#:configure-flags
+   ;; mlmmj-receive-strip is a replacement for mlmmj-receive
+   ;; It opens the files control/mimedeny and control/mimestrip to get a 
list
+   ;; of mimetypes for parts of multipart/mime messages that should be 
denied
+   ;; or stripped. The parts then get stripped directly when the mail is
+   ;; received. mlmmj-receive-strip also appends an extra header
+   ;; X-ThisMailContainsUnwantedMimeParts: Y when the mail contains 
unwanted
+   ;; mime parts
+   (list "--enable-receive-strip")
+   #:phases
+   (modify-phases %standard-phases
+ (add-before 'install 'install-contrib
+   (lambda* (#:key outputs #:allow-other-keys)
+ (let* ((out (assoc-ref outputs "out"))
+(share (string-append out "/share/mlmmj")))
+   (copy-recursively "contrib/web/" share)))
+(home-page "http://mlmmj.org";)
+(synopsis "Mailing list managing made joyful")
+(description
+ "Mlmmj is a simple and slim mailing list manager (MLM) inspired by ezmlm.
+It works with many different Mail Transport Agents (MTAs) and is simple for a
+system adminstrator to install, configure and integrate with other software.
+As it uses very few resources, and requires no daemons, it is ideal for
+installation on systems where resources are limited.  Its features include:
+@enumerate
+@item Archive, Custom headers / footer,
+@item Fully automated bounce handling (similar to ezmlm),
+@item Complete requeueing functionality, Moderation functionality, Subject 
prefix,
+@item Subscribers only posting, Regular expression access control,
+@item Functionality to retrieve old posts, Web interface, Digests,
+@item No-mail subscription, VERP support,
+@item Delivery Status Notification (RFC1891) support,
+@item Rich and customisable texts for automated operations.
+@end enumerate\n")
+(license license:expat)))
-- 
2.10.1

[PATCH] gnu: Add mlmmj.

[ng0]

* gnu/packages/mail.scm (mlmmj): New variable.
---
 gnu/packages/mail.scm | 52 +++
 1 file changed, 52 insertions(+)

diff --git a/gnu/packages/mail.scm b/gnu/packages/mail.scm
index baa5a96..1d732f5 100644
--- a/gnu/packages/mail.scm
+++ b/gnu/packages/mail.scm
@@ -1493,3 +1493,55 @@ transfer protocols.")
 (license (non-copyleft "file://LICENSE"
"See LICENSE in the distribution."
 
+(define-public mlmmj
+  (package
+(name "mlmmj")
+(version "1.2.19.0")
+(source
+ (origin
+   (method url-fetch)
+   (uri (string-append "http://mlmmj.org/releases/mlmmj-"; version 
".tar.bz2"))
+   (sha256
+(base32
+ "1piwvcxkqadjwk5x8jicaiyz9nngmaj3w13ghdqgaki32xd7zk9v"
+(build-system gnu-build-system)
+(inputs
+ `(("perl" ,perl))) ; "contrib/web/"
+(native-inputs
+ `(("pkg-config" ,pkg-config)))
+(arguments
+ `(#:configure-flags
+   ;; mlmmj-receive-strip is a replacement for mlmmj-receive
+   ;; It opens the files control/mimedeny and control/mimestrip to get a 
list
+   ;; of mimetypes for parts of multipart/mime messages that should be 
denied
+   ;; or stripped. The parts then get stripped directly when the mail is
+   ;; received. mlmmj-receive-strip also appends an extra header
+   ;; X-ThisMailContainsUnwantedMimeParts: Y when the mail contains 
unwanted
+   ;; mime parts
+   (list "--enable-receive-strip")
+   #:phases
+   (modify-phases %standard-phases
+ (add-before 'install 'install-contrib
+   (lambda* (#:key outputs #:allow-other-keys)
+ (let* ((out (assoc-ref outputs "out"))
+(share (string-append out "/share/mlmmj")))
+   (copy-recursively "contrib/web/" share)))
+(home-page "http://mlmmj.org";)
+(synopsis "Mailing list managing made joyful")
+(description
+ "Mlmmj is a simple and slim mailing list manager (MLM) inspired by ezmlm.
+It works with many different Mail Transport Agents (MTAs) and is simple for a
+system adminstrator to install, configure and integrate with other software.
+As it uses very few resources, and requires no daemons, it is ideal for
+installation on systems where resources are limited. Its features include:
+@enumerate
+@item Archive, Custom headers / footer,
+@item Fully automated bounce handling (similar to ezmlm),
+@item Complete requeueing functionality, Moderation functionality, Subject 
prefix,
+@item Subscribers only posting, Regular expression access control,
+@item Functionality to retrieve old posts, Web interface, Digests,
+@item No-mail subscription, VERP support,
+@item Delivery Status Notification (RFC1891) support,
+@item Rich and customisable texts for automated operations.
+@end enumerate\n")
+(license license:expat)))
-- 
2.10.1

[PATCH] Add mlmmj (Mlmmj — Mailing List Management Made Joyful)

[ng0]

In the absence of a functional environment this is assumed to work when one of 
us will create a service which populates /var/ etc accordingly OR if the bash 
scripts for list creation just work.
I would test it myself, but right now I can only testify that the build works. 
Setting it up on a server will be delayed until I have taken the time to 
assemble a GuixSD server with a static IP.

Read the README file to see why and where the default locations are.

Re: [PATCH] Add scheme-bytestructures

[Taylan Ulrich Bayırlı/Kammer]

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

> Hi Amirouche,
>
> Some comments to complement Kei’s.
>
> Kei Kebreau  skribis:
>
>> Amirouche Boubekki  writes:
>>
>>> Warning: scheme-bytestructures works on various implementation of Scheme 
>>> but this patch adds
>>> it only for guile-2.0.
>>>
>>> This is a pure scheme package there is no autotools that's why I use the 
>>> trivial-build-system.
>>>
>>> This doesn't run the test suite, yet.
>>>
>>> From fb2eb7ffd88ec4fba09411195a54b59d67d9c137 Mon Sep 17 00:00:00 2001
>>> From: Amirouche 
>>> Date: Sun, 9 Oct 2016 12:31:20 +0200
>>> Subject: [PATCH] gnu: Add scheme-bytestructures
>>>
>>> * gnu/packages/guile.scm (scheme-bytestructures): New variable.
>>>
>>> diff --git a/gnu/packages/guile.scm b/gnu/packages/guile.scm
>>> index 0890f19..383990e 100644
>>> --- a/gnu/packages/guile.scm
>>> +++ b/gnu/packages/guile.scm
>>> @@ -1265,4 +1265,105 @@ is no support for parsing block and inline level 
>>> HTML.")
>>>  (define-public guile2.2-commonmark
>>>(package-for-guile-2.2 guile-commonmark))
>>>  
>>> +(define-public scheme-bytestructures
>>> +  (package
>>> +(name "scheme-bytestructures")
>
> I would suggest calling it “guile-scheme-bytestructures” (or
> “guile-bytestructures”?) to distinguish this package from the same one
> built for another implementation.

FWIW, second option sounds good to me (guile-bytestructures), speaking
as bytestructures author.

>>> +(license gpl3)))
>
> Probably ‘gpl3+’; could you check?

The intention is gpl3+ so if any file implies otherwise that's an error
on my end.  I'm pretty sure I've used standard gpl3+ boilerplate
everywhere though.

Thanks all for doing this. :-)

Taylan

Re: Security updates (was Re: texmaker, Qt and Chromium)

[ng0]

Leo Famulari  writes:

> On Sat, Oct 08, 2016 at 10:55:45AM +0200, Danny Milosavljevic wrote:
>> One of the reasons I'm using distributions rather than just
>> ./configure ; make ; make install is that distributors stay on top of
>> security problems and disable and/or patch packages as problems arise.
>> I think many others also mainly use distributions because of that.
>
> I'm going off-topic here, but... Please Help :)
>
> Right now there are only a few of us paying attention to security bug
> disclosures and, in my opinion, that's not enough.
>
> If you are interested in keeping Guix secure, try subscribing to the
> oss-sec mailing list. If you use Guix on a foreign distro, you can
> subscribe to that distro's security announcement list. If you are the de
> facto maintainer of some Guix packages, or if you run your business on
> some Guix packages, follow the upstream bug reports.
>
> And then, patch bugs in our packages. If you aren't sure how to fix the
> bugs, it's still helpful to present them on guix-devel and ask for
> advice.
>
> Help Wanted!
>
> [0]
> http://seclists.org/oss-sec/
>
> [1] For example:
> https://lists.debian.org/debian-security-announce/
>
>

I can second this help request. It's hard to keep track of the
vulnerabilities. Because I maintain packages for Gentoo I find the
frequently released GLSAs of Gentoo very useful too. They are Gentoo
specific, but Gentoo has a good amount of packages to keep track of.
It can be subscribed via Email or feed reader here:
https://www.gentoo.org/support/security/

-- ng0

Re: [PATCH] Update e-mail address for ng0.

[Alex Kost]

ng0 (2016-10-10 15:03 +) wrote:

> Alex Kost  writes:
>
>> ng0 (2016-10-10 12:31 +) wrote:
[...]
>>> Additional question: is this incomplete? Do I have to add
>>> ng0 
>>> to this list aswell?
>>
>> You can check with "git --no-pager shortlog -nse".  I'm not sure I
>> follow the changes with your emails, but if you are satisfied with the
>> output of that shortlog command after this patch, I will gladly apply
>> it, thanks.
>
> Okay, I've just checked it and no old names / emails are displayed
> on their own. Works for me.

OK, the patch applied, thanks.

-- 
Alex

[PATCH] gnu: Add hdf4

[Thomas Danckaert]

Hi Guix,

this patch continues the work done by Jeremy Robst to package HDF4

(https://lists.gnu.org/archive/html/guix-devel/2016-06/msg00069.html)

 - Back then, people reported occasional build failures. I've disabled
   parallel tests and don't have any problems on my system anymore
   (maybe someone else can test?).

 - I've added a patch to allow a shared build with Fortran interface,
   and some substitutions to remove bogus RPATH settings from the
   Makefiles (otherwise, build directories are included in the RPATH).

 - I've also added a variant “hdf4-alt”: by default, HDF4 includes a
   netCDF API to access HDF4 files, which clashes with the symbols in
   the real netCDF library when you try to use both libraries in your
   program.  This variant uses the “--disable-netcdf” configure flag
   to avoid this.  We could call it “hdf4-nonetcdf”, but the name
   “hdf4-alt” is used by Debian, so maybe it's good to use the same?

best,

Thomas
>From dd7eca9a3cfec364a05aa0f52b941f09b4dea039 Mon Sep 17 00:00:00 2001
From: Thomas Danckaert 
Date: Wed, 28 Sep 2016 10:34:58 +0200
Subject: [PATCH] gnu: Add hdf4

* gnu/packages/maths.scm (hdf4, hdf4-alt): New variables.
* gnu/packages/patches/hdf4-reproducibility.patch: New file.
* gnu/packages/patches/hdf4-shared-fortran.patch: New file.
* gnu/local.mk (dist_patch_DATA): Add patches.
---
 gnu/local.mk|  2 +
 gnu/packages/maths.scm  | 65 +
 gnu/packages/patches/hdf4-reproducibility.patch | 47 ++
 gnu/packages/patches/hdf4-shared-fortran.patch  | 25 ++
 4 files changed, 139 insertions(+)
 create mode 100644 gnu/packages/patches/hdf4-reproducibility.patch
 create mode 100644 gnu/packages/patches/hdf4-shared-fortran.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index 1ce95f2..1b65e74 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -570,6 +570,8 @@ dist_patch_DATA =		\
   %D%/packages/patches/gtk3-respect-GUIX_GTK3_PATH.patch	\
   %D%/packages/patches/gtk3-respect-GUIX_GTK3_IM_MODULE_FILE.patch \
   %D%/packages/patches/gtkglext-disable-disable-deprecated.patch \
+  %D%/packages/patches/hdf4-shared-fortran.patch 		\
+  %D%/packages/patches/hdf4-reproducibility.patch 		\
   %D%/packages/patches/hdf5-config-date.patch			\
   %D%/packages/patches/hdf-eos5-build-shared.patch 		\
   %D%/packages/patches/hdf-eos5-remove-gctp.patch		\
diff --git a/gnu/packages/maths.scm b/gnu/packages/maths.scm
index d5e82bb..72abe58 100644
--- a/gnu/packages/maths.scm
+++ b/gnu/packages/maths.scm
@@ -445,6 +445,71 @@ computations.")
 (home-page "https://github.com/OkoSanto/GCTP";)
 (license license:public-domain))) ;https://www2.usgs.gov/laws/info_policies.html
 
+(define-public hdf4
+  (package
+(name "hdf4")
+(version "4.2.11")
+(source
+ (origin
+   (method url-fetch)
+   (uri (string-append "https://support.hdfgroup.org/ftp/HDF/releases/HDF";
+   version "/src/hdf-" version ".tar.bz2"))
+   (sha256
+(base32 "16yr50j845zlfx20skmw3y75ww77akk9gg0affjqkg66ih5r03mv"))
+   (patches (search-patches "hdf4-reproducibility.patch"
+"hdf4-shared-fortran.patch"
+(build-system gnu-build-system)
+(native-inputs
+ `(("gfortran" ,gfortran)
+   ("bison" ,bison)
+   ("flex" ,flex)))
+(inputs
+ `(("zlib" ,zlib)
+   ("libjpeg" ,libjpeg)))
+(arguments
+ `(#:parallel-tests? #f
+   #:configure-flags '("--enable-shared")
+   #:phases
+   (modify-phases %standard-phases
+ (add-before 'configure 'patchbuild
+   (lambda _
+ (substitute*
+ '("mfhdf/hdfimport/testutil.sh.in" "hdf/util/testutil.sh.in")
+   (("/bin/rm") "rm")
+   (("/bin/mkdir") "mkdir"))
+ (substitute*
+ (map (lambda (dir) (string-append dir "/Makefile.in"))
+  '("hdf" "hdf/examples" "hdf/fortran" "hdf/src"
+"hdf/test" "hdf/util" "mfhdf" "mfhdf/dumper"
+"mfhdf/examples" "mfhdf/fortran" "mfhdf/hdfimport"
+"mfhdf/hdiff" "mfhdf/hrepack" "mfhdf/libsrc"
+"mfhdf/ncgen" "mfhdf/ncdump" "mfhdf/nctest"
+"mfhdf/test" "mfhdf/xdr"))
+   (("@HDF_BUILD_XDR_TRUE@XDR_ADD = \
+-R\\$\\(abs_top_builddir\\)/mfhdf/xdr/\\.libs") "")
+   (("@HDF_BUILD_SHARED_TRUE@AM_LDFLAGS = \
+-R\\$\\(abs_top_builddir\\)/mfhdf/libsrc/\\.libs \
+-R\\$\\(abs_top_builddir\\)/hdf/src/\\.libs \\$\\(XDR_ADD\\)") "")))
+(home-page "https://www.hdfgroup.org/products/hdf4/";)
+(synopsis
+ "Library and multi-object file format for storing and managing data")
+(description "HDF4 is a library and multi-object file format for storing
+and managing data between machines.  HDF4 is an older hierarchical data format,
+incompatible with HDF5.")
+(license
+ 

Re: [WIP 0/9] python-build-system set 1: please review

[Hartmut Goebel]

Am 10.10.2016 um 16:57 schrieb Hartmut Goebel:
> If you want to test
> the complet patch set, please use the branch at
> https://gitlab.com/htgoebel/guix/tree/python-build-system.

Please note that this branch *may* change frequently if I update clean
up commits.

-- 
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: [WIP 0/9] python-build-system set 1: please review

[Hartmut Goebel]

Hi,
> this is the first set of patches for the changed python-build-system.

I was asked about the big plan on these commits.


The original proposal to this changes can be found at
.
And this change sets implement

*A1) Change the Python 2 to include pip and setuptools (build using
--with-ensurepip=install).
**B) Install Python packages using **--single-version-externally-managed
C) Strip **python-setuptools and ***python2-setuptools* from all
native-inputs defined in packages.*

And additionally - since it showed up to be required:
*NEW: D) Change inputs into propagated resp. native-inputs where required.*


About the planed patch sets:

Set 1 are the changes to the build system

Set 2 will be the removal of obviously now unused inputs, namely setuptools

These will be straight forward.

Set 3 will be the straight forward changes to inputs (change to
propagated resp.native)

Set 4 will be the fixes and clean ups required to some packages after
the these changes.

I'm not sure whether I should split set 3 and set 4 nor have I
decided yet whether set 3 should only contain those packages which
will not be changed in set 4. But this makes updating the patches
quite complicated (even when using git rebase).

-- 
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: Display diffs between generations.

[Roel Janssen]

Ludovic Courtès writes:

> Hi Roel!
>
> I realized we have not applied this --list-generations patch of yours,
> which is a pity.  So…
>
> Roel Janssen  skribis:
>
>> Vincent Legoll writes:
>>
>>> On Thu, Sep 1, 2016 at 2:12 PM, Ludovic Courtès  wrote:
   --list-generations=full
>
> I think keeping a way to see all generations in one go would be cool

 --list-generations would still display all the generations.  Or did you
 mean “a way to see *the content* of each generation”?
>>>
>>> I'm not sure to understand what you mean by "the content", what I meant
>>> was to keep what current guix package -l shows us, i.e. do not alter current
>>> UI, only add new things, but do not break existing practices when not 
>>> mandated.
>>
>> What about adding a `--no-diff-format' or a `--diff-format' argument to
>> `--list-generations'?
>>
>> We could then make two choices:  Default to the proposed diff format, or
>> default to the full format (what we have now).  Depending on what we
>> choose as default, we can implement the appropriate negating argument.
>>
>> I would prefer defaulting to the diff format..
>
> In the discussion that ensued, it seems there was a consensus to provide
> only the diff format:
>
>   https://lists.gnu.org/archive/html/guix-devel/2016-09/msg00385.html
>
> So it seems all the lights are green.  :-)  Let me know if there’s
> anything we should do to help!

Thanks for the reminder.  I seem to have a lot to finish up :-).  I will
work out the arguments and post a new version of the patch for final review.

Kind regards,
Roel Janssen