Re: Icecat 52 crashing in file dialogues

[Pjotr Prins]

On Fri, Apr 21, 2017 at 08:03:51PM +0200, Clément Lassieur wrote:
> ng0  writes:
> 
> > Hi,
> >
> > has someone else experienced crashes since the icecat update?
> >
> > My system state isn't that old, but a week older than my profile state.
> > File dialgues (save file) cause random crashes, Open file dialogues (change 
> > profile picture, etc) cause reproducible crashes all the time.
> 
> Yes, I did experience the same thing.  I wrote a small patch that fixes
> it, see https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26593.
> 
> I'm not a GTK expert, there might be a cleaner way deal with
> XDG_DATA_DIRS.

Looks like we can use similar wrappers for all GTK tools, including
gnumeric, geeqie, gnucash etc. Those are the ones that crash on me
without XDG_DATA_DIRS. At this point I use alias on my Debian based
system:

alias gnucash='env XDG_DATA_DIRS=/usr/local/share:/usr/share gnucash'
alias gnumeric='env XDG_DATA_DIRS=/usr/local/share:/usr/share gnumeric'


-- 

We need an RFC procedure [Re: Services can now have a default value]

[ng0]

Carlo Zancanaro transcribed 2.2K bytes:
> On Fri, Apr 21 2017, Ludovic Courtès wrote:
> > A ‘define-service-type’ macro or similar could generate either code the
> > current framework (with  and  and
> > ) or for SRFI-99-style records if we later to go that
> > route.
> >
> > So I think we should start by designing this macro.
> >
> > How does that sound?
> 
> Great! I think that it's sensible to not break things for now, and we
> should be able to design the macro to do that.
> 
> I'll have a go at it later today and see what I can come up with. (I'm
> not very familiar with guile/scheme libraries, but I have played around
> a fair bit with macros.)
> 
> > Well I don’t know, perhaps in some cases it might make sense to
> > automatically instantiate things depended on.  The advantage is that as
> > a user of the service (exim for instance) you don’t have to be aware of
> > the services it expects (improves separation of concern).
> >
> > So you could blissfully write just:
> >
> >   (cons (service mediagoblin-service-type)
> > %base-services)
> >
> > and behind the scenes it would add an nginx instance, an mcron instance
> > with a couple of jobs, a rottlog instance, and so on.
> >
> > WDYT?
> 
> My main concern would be making sure that all of our services have safe
> defaults that can be extended. It may lead to surprising outcomes if we
> have services spun up which do more than you expect. As an example, if
> someone requests exim to start as a dependency, we should make sure it
> doesn't turn you into an open relay by default.
> 
> Carlo

On the matter of 'not breaking things':

I want an formal, publicly tracked (not *just* on the mailinglist) RFC (like in 
Rust or similar projects) procedure for all things which
can break currently existing configurations. Introducing these changes would
require to document properly what needs to changed so that people can read
about how to fix the mistakes.
Right now to me it seems as if people are mostly talking about such development 
on IRC or
offlist and then the changes are applied after a QA which sometimes takes a bit 
of
"don't break stuff" in consideration but is never able to grasp the full effect 
of
breakage.

The current error output of Guix is not enough if you simply want to do
an update of a system.
If you take a look from the perspective of someone who just wants to
administrate a mailserver, and we break their config by a simple change
of how things are written, the resulting error when you run guix system 
reconfigure
requires some understanding of Guix and Guile.

And please don't derail this by saying that it's currently beta status. If we 
are
aiming for general purpose and server adoption, we should look at problems and
solutions from all perspectives.
-- 
PGP and more: https://people.pragmatique.xyz/ng0/

Re: Services can now have a default value

[Carlo Zancanaro]

On Fri, Apr 21 2017, Ludovic Courtès wrote:
> A ‘define-service-type’ macro or similar could generate either code the
> current framework (with  and  and
> ) or for SRFI-99-style records if we later to go that
> route.
>
> So I think we should start by designing this macro.
>
> How does that sound?

Great! I think that it's sensible to not break things for now, and we
should be able to design the macro to do that.

I'll have a go at it later today and see what I can come up with. (I'm
not very familiar with guile/scheme libraries, but I have played around
a fair bit with macros.)

> Well I don’t know, perhaps in some cases it might make sense to
> automatically instantiate things depended on.  The advantage is that as
> a user of the service (exim for instance) you don’t have to be aware of
> the services it expects (improves separation of concern).
>
> So you could blissfully write just:
>
>   (cons (service mediagoblin-service-type)
> %base-services)
>
> and behind the scenes it would add an nginx instance, an mcron instance
> with a couple of jobs, a rottlog instance, and so on.
>
> WDYT?

My main concern would be making sure that all of our services have safe
defaults that can be extended. It may lead to surprising outcomes if we
have services spun up which do more than you expect. As an example, if
someone requests exim to start as a dependency, we should make sure it
doesn't turn you into an open relay by default.

Carlo


signature.asc
Description: PGP signature

Re: Icecat 52 crashing in file dialogues

[Clément Lassieur]

Mark H Weaver  writes:

> Clément Lassieur  writes:
>
>> ng0  writes:
>>
>>> Hi,
>>>
>>> has someone else experienced crashes since the icecat update?
>>>
>>> My system state isn't that old, but a week older than my profile state.
>>> File dialgues (save file) cause random crashes, Open file dialogues (change 
>>> profile picture, etc) cause reproducible crashes all the time.
>>
>> Yes, I did experience the same thing.  I wrote a small patch that fixes
>> it, see https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26593.
>
> Thank you!  For now, please push your patch.  (I would reply to the bug
> report, but it hasn't yet been delivered to me.)

Ok, pushed!

>> I'm not a GTK expert, there might be a cleaner way deal with
>> XDG_DATA_DIRS.
>
> Perhaps, but if so we can fix it up later.  For now, it's important to
> have a usable browser, and your approach is the one that has been
> tested.
>
>  Thanks!
>Mark

Re: Planning for the next release

[Leo Famulari]

On Sat, Apr 22, 2017 at 12:27:11AM +0200, Ludovic Courtès wrote:
> I’m going to be mostly away for a week, but it would be nice if we could
> release after that, wouldn’t it?
> 
> I think we’ll have to postpone work on the installer though since that
> would leave too little time now.
> 
> WDYT?

Sounds good to me!


signature.asc
Description: PGP signature

Re: Planning for the next release

[Ludovic Courtès]

Hello Guix!

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

>1. ‘core-updates’ merged.  We’re almost there!
>
>2. ‘wip-installer’ retested, and probably merged.
>
>   I think the prerequisite for it would be to do some more testing.
>   Last time people reported glitches here and there but John has
>   done quite a bit of work since then.  John: what about doing
>   another round of tests?
>
>   In the installation image, we should probably make the installer
>   optional and mark it as “beta” or something like that.  That will
>   leave us time to iron out remaining issues, and will avoid having
>   people expect a rock-solid Debian-style installer.
>
>   As far as review is concerned, we can probably do a quick and
>   lightweight review process since that’s quite a big chunk of code
>   and we don’t want the branch to block indefinitely.  So we can do
>   that quick process, and then incrementally improve it if needed.
>   I think it’s a reasonable approach given that the installer is
>   mostly an independent component.
>
>   John, everyone: thoughts?
>
>3. UEFI support documented and possibly improved.
>
>   We can certainly document the UEFI setup and add the /boot/efi
>   partition in some of the ‘operating-system’ examples.
>
>   The more difficult part is the installation: do we need to make a
>   second, UEFI-specific, installation image?  When I installed
>   GuixSD on UEFI, I booted our installation image as “legacy”, but
>   then GRUB would default to a legacy install, not a UEFI install:
>
> https://lists.gnu.org/archive/html/guix-devel/2016-12/msg00799.html
>
>   I’m not sure exactly what needs to be done.  Thoughts?
>
>4. Fix low-hanging fruits at ; your help
>   welcome!

I’m going to be mostly away for a week, but it would be nice if we could
release after that, wouldn’t it?

I think we’ll have to postpone work on the installer though since that
would leave too little time now.

WDYT?

Thanks,
Ludo’.

Re: Services can now have a default value

[Ludovic Courtès]

Hello,

Carlo Zancanaro  skribis:

> On Thu, Apr 20 2017, Ludovic Courtès wrote:
>> There must be some sort of a mapping between service types and
>> configuration types, indeed, but I’m not sure how to achieve it.
>>
>> One solution would be to have all the  records
>> inherit (in the OO sense) from , or something along these
>> lines.
>
> This was my first thought. I couldn't see how to do OO-style inheritance
> with the SRFI-9 API, though. I'm not very experienced with Guile (or
> scheme generally), so I might do some more reading about that.

SRFI-99 supports inheritance, though there’s currently no SRFI-99 module
in Guile proper:

  https://srfi.schemers.org/srfi-99/srfi-99.html

Oh and there’s also R6RS records, SRFI-35… no shortage of record APIs!
:-)

>> Or we could have a ‘define-service’ macro that defines both the
>>  and the , and defines a ‘foo-service’
>> macro equivalent to (service foo-service-type (foo-configuration …)).
>>
>>   (define-service-type openssh-service-type
>> openssh-service
>> (extensions …)
>> (configuration
>>   (port openssh-service-port (default 22))
>>   (use-pam? openssh-service-use-pam? (default #t
>>
>> and then:
>>
>>(operating-system
>>  ;; …
>>  (services (cons (openssh-service (port )) %base-services)))
>
> I also thought about this, but I was concerned about things like
> dovecot-service, where there are two configuration objects. I wouldn't
> want to force us to duplicate code, and create two different service
> types, if we wanted services like that in future.
>
> Although, maybe we would actually rather enforce a "one configuration
> type per service type" rule, for the sake of modifying services? It's
> hard to modify a service if you can't be sure of what the type of the
> configuration will be.

Right, I would prefer one type per service.  I didn’t know dovecot was
different.

> Do you have a preference for what approach to use? If we use a macro to
> generate things then we retain the same flexibility as the current
> approach which removing a bunch of boilerplate, but I'm not sure I have
> the best view of the trade-offs involved.

A ‘define-service-type’ macro or similar could generate either code the
current framework (with  and  and
) or for SRFI-99-style records if we later to go that
route.

So I think we should start by designing this macro.

How does that sound?

>> I’m not sure what you mean.  Is it something like what ‘simple-service’
>> does?
>
> I meant something more like what I did with exim-service-type, where I
> extend a service just to ensure its presence, then I had to document
> you have to have a mail-aliases-service-type in order to use exim. With
> a default configuration the mail-aliases-service-type could be
> automatically instantiated if it doesn't exist.

Oh right.

Well I don’t know, perhaps in some cases it might make sense to
automatically instantiate things depended on.  The advantage is that as
a user of the service (exim for instance) you don’t have to be aware of
the services it expects (improves separation of concern).

So you could blissfully write just:

  (cons (service mediagoblin-service-type)
%base-services)

and behind the scenes it would add an nginx instance, an mcron instance
with a couple of jobs, a rottlog instance, and so on.

WDYT?

Thanks,
Ludo’.

Re: Extending the mysql configuration

[Ludovic Courtès]

Andy Wingo  skribis:

> On Wed 19 Apr 2017 19:45, Christopher Baines  writes:
>
>> I also spotted the define-configuration syntax, which looks like it
>> might work well, but I wanted to check if this was definitely a
>> direction more services were heading before attempting to write out a
>> large part of the supported configuration options.
>
> MHO is this is the direction we should go in.  Having a configuration
> defined in a data type that Guix can understand makes it easier to
> operate on the system as a whole -- the system can see your mysql
> configuration and introspect on it, it's easy to define extension
> points, etc.  There are a few services that use this approach and I
> expect the number to grow over time.  At the same time many of these
> services have the option to fall back on an opaque configuration when
> you have special needs or a different workflow -- see dovecot for a very
> long example.

I agree.

Record types defined with ‘define-configuration’ or similar are
preferable to using an alist or another dictionary type also because of
the set of fields is checked at macro-expansion time (eventually I’d
like to have some static type checks in there too).

Ludo’.

Re: [sr #109299] Creating a 'cuirass' Git repository for Guix

[Ludovic Courtès]

Hello Guix,

Assaf Gordon  skribis:

> Anonymous git access:
>   git clone git://git.sv.nongnu.org/guix/guix-cuirass.git
>
> Read/Write Access:
>   git clone @git.sv.nongnu.org:/srv/git/guix/guix-cuirass.git
>
> Web Access:
>   http://git.sv.nongnu.org/cgit/guix/guix-cuirass.git
>   http://git.sv.nongnu.org/gitweb/?p=guix/guix-cuirass.git
>
> sub-repository 'guix-cuirass.git' created.
>
> Anonymous git access:
>   git clone git://git.sv.nongnu.org/guix/guix-cuirass.git
>
> Read/Write Access:
>   git clone @git.sv.nongnu.org:/srv/git/guix/guix-cuirass.git
>
> Web Access:
>   http://git.sv.nongnu.org/cgit/guix/guix-cuirass.git
>   http://git.sv.nongnu.org/gitweb/?p=guix/guix-cuirass.git

For the record, this repo will contain a copy of Cuirass.  We encourage
people willing to work on Cuirass to discuss changes with Mathieu Lirzin
on the bug-cuirass mailing list¹, to the extent possible².  Please keep
guix-devel Cc’d as much as possible because bug-cuirass archives are
visible only to subscribers.

Happy hacking!

Ludo’.

¹ https://framalistes.org/sympa/info/bug-cuirass

² Mathieu wants Cuirass development to happen “outside of Guix
  infrastructure”.  I think it makes little sense because Cuirass is
  meant to be a continuous integration tool for Guix and is really part
  of Guix as a project (see
  ).

‘guix’ commands can talk to remote daemons

[Ludovic Courtès]

Hello Guix!

With what I committed today, it is possible to make ‘guix’ commands talk
to remote daemons, either using the raw protocol (unencrypted,
unauthenticated) or over SSH:

  GUIX_DAEMON_SOCKET=guix://guix.example.org:1234 guix build foo

  GUIX_DAEMON_SOCKET=ssh://al...@guix.example.org guix gc

It’s pretty fun but there’s a couple of caveats:

  1. It’s slow.  This is because the protocol with the daemon currently
 incurs a lot of round trips.  We should probably redesign some of
 the RPCs to be more efficient and pipelinable.

  2. (guix derivations) may try to access .drv files in the local store
 when it should really be accessing files from the remote store.
 The store abstraction on the client side may have to be extended to
 address this.

That’s it.

Feedback welcome!

Ludo’.

[sr #109299] Creating a 'cuirass' Git repository for Guix

[Ludovic Courtès]

Follow-up Comment #2, sr #109299 (project administration):

Thanks, Assaf!

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Re: guix pull: cannot allocate memory

[Ludovic Courtès]

ng0  skribis:

> Is this exactly what Guile is telling me, "get more RAM / SWAP whatever"?
>
> ng0@sharknado9001:~$ guix pull; guix package -i rxvt-unicode
>
> Starting download of /tmp/guix-file.O9FRJW
> From https://git.savannah.gnu.org/cgit/guix.git/snapshot/master.tar.gz...
>  ….tar.gz   981KiB/s 00:14 | 13.0MiB 
> transferred
> unpacking '/gnu/store/lqpb6cppk3h65q5y29dxrj060idqj60b-guix-latest.tar.gz'...
> substitute: updating list of substitutes from 
> 'https://mirror.hydra.gnu.org'... substitute: updating list of substitutes 
> from 'https://mirror.hydra.gnu.org'... 100.0%
> The following derivation will be built:
>/gnu/store/pg93cl2f7pynqz3rxmvg77226y79lhhi-guix-latest.drv
> building path(s) `/gnu/store/5x386gcp93f3ms33s60d7q1ijmnllbml-guix-latest'
> copying and compiling to 
> '/gnu/store/5x386gcp93f3ms33s60d7q1ijmnllbml-guix-latest'...
> loading... 24.5% of 587 filesrandom seed for tests: 1492717246
> loading... 98.8% of 587 filesBacktrace:
> In unknown file:
>?: 19 [primitive-load-path "gnu/tests/install" ...]
> In ice-9/eval.scm:
>  453: 18 [eval # ()]
>  411: 17 [eval # #]
>  387: 16 [eval # #]
>  373: 15 [run-install # #]

[...]

> In ice-9/popen.scm:
>   64: 1 [open-pipe* "r" "git" "ls-files"]
> In unknown file:
>?: 0 [open-process "r" "git" "ls-files"]
>
> ERROR: In procedure open-process:
> ERROR: In procedure open-process: Cannot allocate memory
> builder for `/gnu/store/pg93cl2f7pynqz3rxmvg77226y79lhhi-guix-latest.drv' 
> failed with exit code 1

I think it’s fork(2) returning ENOMEM.  Perhaps ‘dmesg’ would show more
details?  It could be that there were too many processes running or
something along these lines.

It’s “interesting” to see that we try to spawn Git while evaluating the
top level of (gnu tests install), I had never thought about it.  Not
great.

Ludo’.

Re: Ready for Guile 2.2!

[Ludovic Courtès]

Andy Wingo  skribis:

> On Thu 20 Apr 2017 14:35, l...@gnu.org (Ludovic Courtès) writes:
>
>> l...@gnu.org (Ludovic Courtès) skribis:
>>
>>> ;; 2.724686s real time, 3.117062s run time.  0.880827s spent in GC.
>>> scheme@(guile-user)> (version)
>>> $1 = "2.0.13"
>>>
>> scheme@(guile-user)> ,use(guix scripts build)
>> scheme@(guile-user)> ,time (guix-build "libreoffice" "certbot" "xmonad" "-n" 
>> "--no-substitutes" "--no-build-hook")
>>
>> [...]
>>
>> ;; 1.826528s real time, 1.994426s run time.  0.382750s spent in GC.
>> scheme@(guile-user)> (version)
>> $1 = "2.2.1"
>>
>> That’s a 33% speedup compared to 2.0.
>
> That is a 50% speedup compared to 2.0 :)  If we consider its speed as
> being how many times you could do this per second, then 2.0 speed is
> 1/2.72, and 2.2.1 speed is 1/1.82.  Speed ratio is then
> 2.72/1.82=1.4945.  So 2.2.1 is 1.5x the speed of 2.0, or 50% faster :)

Right!  What I meant to say is that:

  2.72 - 0.33×2.72 = 1.82

But maybe that’s not the preferred way to present things?

Anyway, it’s _way faster_.  :-)

Ludo’.

Re: Ready for Guile 2.2!

[Ludovic Courtès]

Maxim Cournoyer  skribis:

> Andy Wingo  writes:
>
>> On Thu 20 Apr 2017 14:35, l...@gnu.org (Ludovic Courtès) writes:
>>
>>> l...@gnu.org (Ludovic Courtès) skribis:
>>>
 ;; 2.724686s real time, 3.117062s run time.  0.880827s spent in GC.
 scheme@(guile-user)> (version)
 $1 = "2.0.13"

>>> scheme@(guile-user)> ,use(guix scripts build)
>>> scheme@(guile-user)> ,time (guix-build "libreoffice" "certbot" "xmonad" 
>>> "-n" "--no-substitutes" "--no-build-hook")
>>>
>>> [...]
>>>
>>> ;; 1.826528s real time, 1.994426s run time.  0.382750s spent in GC.
>>> scheme@(guile-user)> (version)
>>> $1 = "2.2.1"
>>>
>>> That’s a 33% speedup compared to 2.0.
>>
>> That is a 50% speedup compared to 2.0 :)  If we consider its speed as
>> being how many times you could do this per second, then 2.0 speed is
>> 1/2.72, and 2.2.1 speed is 1/1.82.  Speed ratio is then
>> 2.72/1.82=1.4945.  So 2.2.1 is 1.5x the speed of 2.0, or 50% faster :)
>>
>> Andy, who is not looking for praise, but who likes perf numbers :)
>
> Impressive :). Is there a blog post/article/information somewhere about
> what went in Guile to make it that faster?

I highly recommend posts from the last couple of years (or more!) at
.  :-)

 has pointers to
the most important bits.

Ludo’.

Re: [PATCH] gnu: graphite2: Add fixes for CVE-2017-5436 and other bugs

[Ludovic Courtès]

Mark H Weaver  skribis:

> This adds selected fixes for graphite2 from the upstream repository,
> including a fix for CVE-2017-5436.  I intend to push it soon, after some
> light testing on my system.

Great, thank you.

Ludo’.

Re: Build-side code with non-ASCII failing to build on Hydra

[Ludovic Courtès]

Hi Mark,

Mark H Weaver  skribis:

> On the security-updates jobset on Hydra, I'm seeing several new build
> failures due to non-ASCII characters within build-side code being
> misread:
>
>   https://hydra.gnu.org/build/2003897
>   https://hydra.gnu.org/build/2001256
>   https://hydra.gnu.org/build/2013954
>   https://hydra.gnu.org/build/2006487
>   https://hydra.gnu.org/eval/109617?compare=109613#tabs-now-fail
>
> Has something changed recently that might explain this?

That’s surprising.  On current master, on my laptop, utf8proc fails
exactly as shown in :

--8<---cut here---start->8---
starting phase `check-data'

[...]

In 
/gnu/store/a42pfdz8w5qxdkp6xz8783ydywmp0p8p-module-import/guix/build/utils.scm:
 612: 1 [# #]
In unknown file:
   ?: 0 [make-regexp "?" 1]

ERROR: In procedure make-regexp:
ERROR: In procedure make-regexp: Invalid preceding regular expression
--8<---cut here---end--->8---

Yet Hydra says it succeeded on ‘master’:

  https://hydra.gnu.org/job/gnu/master/utf8proc-2.1.0.x86_64-linux

Indeed, the latest one that succeeded on x86_64 also works for me:

  $ guix build /gnu/store/cxwa18q2sa69i08982rb0dd73lph2spz-utf8proc-2.1.0.drv
  /gnu/store/mf2bby0nzzsq2x5m654g89yxd3l9h6v8-utf8proc-2.1.0

The one in current master is different:

  $ ./pre-inst-env guix build utf8proc -d --no-grafts
  /gnu/store/133cl1mzwa3dzy5s3ihr90qspp7l6g96-utf8proc-2.1.0.drv
  ludo@ribbon ~/src/guix$ git describe
  v0.12.0-3158-g285f63e80

The difference is that one of the builders is UTF-8-encoded whereas the
other is Latin-1:

  $ diffoscope 
"/gnu/store/msbh42cr1f48z6hc24h5v9vpl18l5hhz-utf8proc-2.1.0-guile-builder" 
"/gnu/store/r9y6fma06w4ghz00nws372iqxcszpv25-utf8proc-2.1.0-guile-builder"
  --- /gnu/store/msbh42cr1f48z6hc24h5v9vpl18l5hhz-utf8proc-2.1.0-guile-builder
  +++ /gnu/store/r9y6fma06w4ghz00nws372iqxcszpv25-utf8proc-2.1.0-guile-builder
  ├── encoding
  │ @@ -1 +1 @@
  │ -iso-8859-1
  │ +utf-8

This is fixed by commit 9231ef12f2a595b8f1e677dbe50cc499555302b6 in
‘master’.

Thanks for the heads-up, and sorry for the breakage!

Ludo’.

Re: Help needed from Java developer to finish maven

[Björn Höfling]

On Fri, 21 Apr 2017 12:46:40 +0200
Hartmut Goebel  wrote:

> Hi,
> 
> I'm seeking for help from some skilled Java developer. I nearly
> finished bootstrapping maven: I made it to start up, but now fails
> with this error message:
> 
> org.apache.maven.InternalErrorException: Internal error:
> com.google.inject.ProvisionException: Unable to provision, see the
> following errors:
> 
> 1) null returned by binding at org.eclipse.sisu.wire.LocatorWiring
>  but parameter 1 of
> org.eclipse.aether.transport.wagon.WagonTransporterFactory.() is
> not @Nullable
>   while locating org.eclipse.aether.transport.wagon.WagonConfigurator
> for parameter 1 at
> org.eclipse.aether.transport.wagon.WagonTransporterFactory.(Unknown
> Source) while locating
> org.eclipse.aether.transport.wagon.WagonTransporterFactory while
> locating java.lang.Object annotated with *
> 
> I assume this means some meta-date file is missing in one of the jars
> (like plexus/components.xml or sisu/javax.inject.Named), but I was not
> able to find any missing file or data. may.
> 
> Any tipps?
> 

1. Is this already the output of "mvn -X" and/or "mvn -e"?
2. Some posts suggest that this could be caused because of wrong
version of dependencies? I.e. API and thus number of parameters changed:

https://issues.apache.org/jira/browse/MNG-5919
http://maven.40175.n5.nabble.com/Maven-wagon-http-Issue-td5806465.html

3. Do you have a WIP branch and instructions on how to reproduce this?


Björn

Re: Staging

[Leo Famulari]

On Fri, Apr 21, 2017 at 02:59:23PM -0400, Mark H Weaver wrote:
> Yes, I cancelled the builds in 'staging' so that Hydra would focus on
> rebuilding 'security-updates', whose patches have since been applied to
> master.
> 
> Unfortunately, the recent 'imlib2' update rendered most of that
> rebuilding obsolete, and now we need to rebuild the web browsers,
> libreoffice, and Qt/KDE all over again.  Oh well.

Bah... libreoffice is especially annoying since it's very expensive to
build but also has a huge dependency graph.

> Anyway, here's what I'd recommend: after the most important packages are
> rebuilt on 'master', let's merge 'master' into 'staging' and start
> another evaluation of 'staging'.
> 
> What do you think?

Sure, hopefully it will be ready later today; I'll pay attention.


signature.asc
Description: PGP signature

Re: 01/02: gnu: qemu: Update to 2.9.0 [security fixes].

[Leo Famulari]

On Fri, Apr 21, 2017 at 02:31:44PM -0400, Mark H Weaver wrote:
> Leo Famulari  writes:
> > On Thu, Apr 20, 2017 at 09:06:51PM -0400, Mark H Weaver wrote:
> >>   FAIL: grub_cmd_set_date
> >>   ===
> >
> >> Has anyone else seen this?
> >
> > I just ran the build 5 times on my x86_64 machine, and it failed this
> > test 1/5 times.
> >
> > We could try patching the test file with 'set -x' to trace the execution
> > of the script and see exactly what goes wrong.
> 
> Of course it would be good to investigate, but for now, here is the
> patch that I used to disable that one test.

> From 3ea154ed0dff96c348a0ee5a3a45678fc8a1dfb5 Mon Sep 17 00:00:00 2001
> From: Mark H Weaver 
> Date: Thu, 20 Apr 2017 21:14:45 -0400
> Subject: [PATCH] DRAFT: gnu: grub: Disable failing test.
> 
> * gnu/packages/bootloaders.scm (grub)[arguments]: Add 'disable-failing-test'
> phase.

Okay, sounds good. Can you forward this report to ?

By the way, I'm testing the latest release of grub, 2.02~rc2, and this
test is flaky there, too.


signature.asc
Description: PGP signature

Re: Staging

[Mark H Weaver]

Leo Famulari  writes:

> On Fri, Apr 21, 2017 at 03:57:41PM +0200, Marius Bakke wrote:
>> Looks like the queue was cancelled.
>> 
>> https://hydra.gnu.org/eval/109614?compare=master
>> 
>> Should we try to build out the remaining packages? There have been a few
>> large updates in 'master', might be useful to merge that first. Or just
>> go the other way around.. ;-)
>
> Most likely the queue was paused to make way for the security-updates
> jobset:
>
> https://hydra.gnu.org/jobset/gnu/security-updates

Yes, I cancelled the builds in 'staging' so that Hydra would focus on
rebuilding 'security-updates', whose patches have since been applied to
master.

Unfortunately, the recent 'imlib2' update rendered most of that
rebuilding obsolete, and now we need to rebuild the web browsers,
libreoffice, and Qt/KDE all over again.  Oh well.

Anyway, here's what I'd recommend: after the most important packages are
rebuilt on 'master', let's merge 'master' into 'staging' and start
another evaluation of 'staging'.

What do you think?

  Mark

Re: 01/02: gnu: qemu: Update to 2.9.0 [security fixes].

[Mark H Weaver]

Leo Famulari  writes:

> On Thu, Apr 20, 2017 at 09:06:51PM -0400, Mark H Weaver wrote:
>> l...@famulari.name (Leo Famulari) writes:
>> > gnu: qemu: Update to 2.9.0 [security fixes].
>> 
>> Thanks for this!  Obviously it's an important security update, but:
>> 
>> On my x86_64 system running GuixSD, 'grub' now fails to build from
>> source.  Three times in a row, the 'grub_cmd_set_date' has failed.
>> Here's the relevant excerpt from test-suite.log (lightly formatted):
>> 
>>   FAIL: grub_cmd_set_date
>>   ===
>
>> Has anyone else seen this?
>
> I just ran the build 5 times on my x86_64 machine, and it failed this
> test 1/5 times.
>
> We could try patching the test file with 'set -x' to trace the execution
> of the script and see exactly what goes wrong.

Of course it would be good to investigate, but for now, here is the
patch that I used to disable that one test.

   Mark


>From 3ea154ed0dff96c348a0ee5a3a45678fc8a1dfb5 Mon Sep 17 00:00:00 2001
From: Mark H Weaver 
Date: Thu, 20 Apr 2017 21:14:45 -0400
Subject: [PATCH] DRAFT: gnu: grub: Disable failing test.

* gnu/packages/bootloaders.scm (grub)[arguments]: Add 'disable-failing-test'
phase.
---
 gnu/packages/bootloaders.scm | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/bootloaders.scm b/gnu/packages/bootloaders.scm
index 98afc6a7c..f495c39d7 100644
--- a/gnu/packages/bootloaders.scm
+++ b/gnu/packages/bootloaders.scm
@@ -1,6 +1,6 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2013, 2014, 2015, 2016, 2017 Ludovic Courtès 
-;;; Copyright © 2015 Mark H Weaver 
+;;; Copyright © 2015, 2017 Mark H Weaver 
 ;;; Copyright © 2015 Leo Famulari 
 ;;; Copyright © 2016 Jan Nieuwenhuizen 
 ;;; Copyright © 2016, 2017 Marius Bakke 
@@ -95,7 +95,12 @@
  ;; Make the font visible.
  (copy-file (assoc-ref inputs "unifont") "unifont.bdf.gz")
  (system* "gunzip" "unifont.bdf.gz")
- #t)
+ #t))
+  (add-before 'check 'disable-failing-test
+(lambda _
+  (substitute* "Makefile"
+((" grub_cmd_set_date ") " "))
+  #t)
 (inputs
  `(("gettext" ,gettext-minimal)
 
-- 
2.12.2

Re: Icecat 52 crashing in file dialogues

[Mark H Weaver]

Clément Lassieur  writes:

> ng0  writes:
>
>> Hi,
>>
>> has someone else experienced crashes since the icecat update?
>>
>> My system state isn't that old, but a week older than my profile state.
>> File dialgues (save file) cause random crashes, Open file dialogues (change 
>> profile picture, etc) cause reproducible crashes all the time.
>
> Yes, I did experience the same thing.  I wrote a small patch that fixes
> it, see https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26593.

Thank you!  For now, please push your patch.  (I would reply to the bug
report, but it hasn't yet been delivered to me.)

> I'm not a GTK expert, there might be a cleaner way deal with
> XDG_DATA_DIRS.

Perhaps, but if so we can fix it up later.  For now, it's important to
have a usable browser, and your approach is the one that has been
tested.

 Thanks!
   Mark

Re: 04/04: offload: Avoid using '_' as a 'match' pattern.

[Mark H Weaver]

l...@gnu.org (Ludovic Courtès) writes:
> In hindsight, it would have been wiser to just rename ‘_’ in (guix ui)
> to something else, like ‘G_’.  Well, it’s not too late.  Should we do
> that?  Thoughts?

I agree that renaming '_' in (guix ui) is the better approach.

  Mark

Re: Icecat 52 crashing in file dialogues

[Clément Lassieur]

ng0  writes:

> Hi,
>
> has someone else experienced crashes since the icecat update?
>
> My system state isn't that old, but a week older than my profile state.
> File dialgues (save file) cause random crashes, Open file dialogues (change 
> profile picture, etc) cause reproducible crashes all the time.

Yes, I did experience the same thing.  I wrote a small patch that fixes
it, see https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26593.

I'm not a GTK expert, there might be a cleaner way deal with
XDG_DATA_DIRS.

Re: [PATCHES] gnu: nss: Update to 3.30.2 [fixes CVE-2017-5461].

[Mark H Weaver]

Mark H Weaver  writes:

> These patches update nss to 3.30.2 and disable long b64 tests which fail
> on some systems including armhf.  I'll push them soon after some light
> testing.

Unfortunately, even with "nss-increase-test-timeout.patch" and
"nss-disable-long-b64-tests.patch", the build still failed on armhf:

  https://hydra.gnu.org/build/2010324

It would be good to find a way to fix or work around this issue without
forcing rebuilds on other platforms.  Also, I feel it's important to
always run tests on NSS on all platforms.

  Mark

Re: guix pull: cannot allocate memory

[ng0]

Leo Famulari transcribed 0.7K bytes:
> On Thu, Apr 20, 2017 at 08:03:08PM +, ng0 wrote:
> > ng0 transcribed 3.0K bytes:
> > > Is this exactly what Guile is telling me, "get more RAM / SWAP whatever"?
> > > 
> > > ERROR: In procedure open-process:
> > > ERROR: In procedure open-process: Cannot allocate memory
> > > builder for `/gnu/store/pg93cl2f7pynqz3rxmvg77226y79lhhi-guix-latest.drv' 
> > > failed with exit code 1
> > > guix pull: error: build failed: build of 
> > > `/gnu/store/pg93cl2f7pynqz3rxmvg77226y79lhhi-guix-latest.drv' failed
> > 
> > Okay, I added a swap, and this time guix pull as unprivileged user succeded.
> > As root I had no problems before, same before the conversion to GuixSD.
> 
> I'm curious, how much memory does the system have?
> 

Smallest configuration at that host, 1024MB
-- 
PGP and more: https://people.pragmatique.xyz/ng0/

Re: Staging

[Leo Famulari]

On Fri, Apr 21, 2017 at 03:57:41PM +0200, Marius Bakke wrote:
> Looks like the queue was cancelled.
> 
> https://hydra.gnu.org/eval/109614?compare=master
> 
> Should we try to build out the remaining packages? There have been a few
> large updates in 'master', might be useful to merge that first. Or just
> go the other way around.. ;-)

Most likely the queue was paused to make way for the security-updates
jobset:

https://hydra.gnu.org/jobset/gnu/security-updates


signature.asc
Description: PGP signature

Re: guix pull: cannot allocate memory

[Leo Famulari]

On Thu, Apr 20, 2017 at 08:03:08PM +, ng0 wrote:
> ng0 transcribed 3.0K bytes:
> > Is this exactly what Guile is telling me, "get more RAM / SWAP whatever"?
> > 
> > ERROR: In procedure open-process:
> > ERROR: In procedure open-process: Cannot allocate memory
> > builder for `/gnu/store/pg93cl2f7pynqz3rxmvg77226y79lhhi-guix-latest.drv' 
> > failed with exit code 1
> > guix pull: error: build failed: build of 
> > `/gnu/store/pg93cl2f7pynqz3rxmvg77226y79lhhi-guix-latest.drv' failed
> 
> Okay, I added a swap, and this time guix pull as unprivileged user succeded.
> As root I had no problems before, same before the conversion to GuixSD.

I'm curious, how much memory does the system have?

Re: [PATCH] Makefile.am: add a target that lists patches no longer used

[Leo Famulari]

On Thu, Apr 20, 2017 at 11:20:23PM -0500, Eric Bavier wrote:
> Attached is my own shot at this.  It does not make use of git, so
> should be fine as a regular test.  It doesn't check whether the files
> listed in dist_patch_DATA actually exist, because `make dist` already
> checks that.  I suppose it might be nice, if git a git checkout, to
> check whether the used patches are all known to git...

I do think it's better to avoid depending on Git here.

> ---BEGIN test-suite.log
> FAIL: tests/patches
> ===
> 
> test-name: distributed patches are used
> location: /home/bavier/projects/guix/tests/patches.scm:50
> source:
> + (test-equal
> +   "distributed patches are used"
> +   '()
> +   (lset-difference
> + string=?
> + distributed-patches
> + used-patches))
> expected-value: ()
> actual-value: 
> ("/home/bavier/projects/guix/gnu/packages/patches/ath9k-htc-firmware-binutils.patch"
>  
> "/home/bavier/projects/guix/gnu/packages/patches/ath9k-htc-firmware-gcc.patch"
>  
> "/home/bavier/projects/guix/gnu/packages/patches/coreutils-cut-huge-range-test.patch"
>  "/home/bavier/projects/guix/gnu/packages/patches/gawk-shell.patch" 
> "/home/bavier/projects/guix/gnu/packages/patches/gcc-libiberty-printf-decl.patch"
>  
> "/home/bavier/projects/guix/gnu/packages/patches/gcc-4.9.3-mingw-gthr-default.patch"
>  "/home/bavier/projects/guix/gnu/packages/patches/gcj-arm-mode.patch" 
> "/home/bavier/projects/guix/gnu/packages/patches/glibc-bootstrap-system.patch"
>  "/home/bavier/projects/guix/gnu/packages/patches/grub-CVE-2015-8370.patch" 
> "/home/bavier/projects/guix/gnu/packages/patches/grub-gets-undeclared.patch" 
> "/home/bavier/projects/guix/gnu/packages/patches/grub-freetype.patch" 
> "/home/bavier/projects/guix/gnu/packages/patches/guile-arm-fixes.patch" 
> "/home/bavier/projects/guix/gnu/packages/patches/icu4c-CVE-2017-7867-CVE-2017-7868.patch"
>  
> "/home/bavier/projects/guix/gnu/packages/patches/icu4c-reset-keyword-list-iterator.patch"
>  "/home/bavier/projects/guix/gnu/packages/patches/ldc-disable-tests.patch" 
> "/home/bavier/projects/guix/gnu/packages/patches/ldc-1.1.0-disable-dmd-tests.patch"
>  
> "/home/bavier/projects/guix/gnu/packages/patches/ldc-1.1.0-disable-phobos-tests.patch"
>  
> "/home/bavier/projects/guix/gnu/packages/patches/libgit2-use-after-free.patch"
>  
> "/home/bavier/projects/guix/gnu/packages/patches/libxslt-CVE-2016-4738.patch" 
> "/home/bavier/projects/guix/gnu/packages/patches/mplayer2-theora-fix.patch" 
> "/home/bavier/projects/guix/gnu/packages/patches/patchelf-rework-for-arm.patch"
>  "/home/bavier/projects/guix/gnu/packages/patches/pcre-CVE-2017-7186.patch" 
> "/home/bavier/projects/guix/gnu/packages/patches/perl-net-ssleay-disable-ede-test.patch"
>  "/home/bavier/projects/guix/gnu/packages/patches/readline-7.0-mingw.patch" 
> "/home/bavier/projects/guix/gnu/packages/patches/soprano-find-clucene.patch" 
> "/home/bavier/projects/guix/gnu/packages/patches/texlive-texmf-CVE-2016-10243.patch"
>  
> "/home/bavier/projects/guix/gnu/packages/patches/util-linux-CVE-2017-2616.patch"
>  
> "/home/bavier/projects/guix/gnu/packages/patches/xf86-video-ast-remove-mibstore.patch"
>  
> "/home/bavier/projects/guix/gnu/packages/patches/xf86-video-intel-compat-api.patch"
>  
> "/home/bavier/projects/guix/gnu/packages/patches/xf86-video-intel-glibc-2.20.patch")

At least one of these is a false positive:
icu4c-CVE-2017-7867-CVE-2017-7868.patch

It's used in a grafted package.


signature.asc
Description: PGP signature

Re: 01/02: gnu: qemu: Update to 2.9.0 [security fixes].

[Leo Famulari]

On Thu, Apr 20, 2017 at 09:06:51PM -0400, Mark H Weaver wrote:
> l...@famulari.name (Leo Famulari) writes:
> > gnu: qemu: Update to 2.9.0 [security fixes].
> 
> Thanks for this!  Obviously it's an important security update, but:
> 
> On my x86_64 system running GuixSD, 'grub' now fails to build from
> source.  Three times in a row, the 'grub_cmd_set_date' has failed.
> Here's the relevant excerpt from test-suite.log (lightly formatted):
> 
>   FAIL: grub_cmd_set_date
>   ===

> Has anyone else seen this?

I just ran the build 5 times on my x86_64 machine, and it failed this
test 1/5 times.

We could try patching the test file with 'set -x' to trace the execution
of the script and see exactly what goes wrong.


signature.asc
Description: PGP signature

Re: [PATCH] gnu: graphite2: Add fixes for CVE-2017-5436 and other bugs

[Leo Famulari]

On Thu, Apr 20, 2017 at 06:26:32PM -0400, Mark H Weaver wrote:
> This adds selected fixes for graphite2 from the upstream repository,
> including a fix for CVE-2017-5436.  I intend to push it soon, after some
> light testing on my system.

Thank you, Mark!


signature.asc
Description: PGP signature

Icecat 52 crashing in file dialogues

[ng0]

Hi,

has someone else experienced crashes since the icecat update?

My system state isn't that old, but a week older than my profile state.
File dialgues (save file) cause random crashes, Open file dialogues (change 
profile picture, etc) cause reproducible crashes all the time.
-- 
PGP and more: https://people.pragmatique.xyz/ng0/

Re: 04/04: offload: Avoid using '_' as a 'match' pattern.

[Ludovic Courtès]

Hi,

Tobias Geerinckx-Rice  skribis:

> On 21/04/17 17:24, Ludovic Court�s wrote:
>> commit ba97e454bfbc168098212b37881b50b4fe6e1eb2 Author: Ludovic
>> Courtès  Date:   Fri Apr 21 17:18:54 2017
>> +0200
>> 
>> offload: Avoid using '_' as a 'match' pattern.
>> 
>> * guix/scripts/offload.scm (host-key->type+key, machine-load) 
>> (process-request, guix-offload): Do not use '_' as a 'match'
>> pattern.
>
> Is this something that should now be avoided in general, i.e. when
> writing packages/..., or only in specific circumstances?

Only in modules that import (guix ui).

This is due to the fact that macros in Guile 2.2 match “literals”
differently: normal bindings (like ‘_’ from (guix ui)) can shadow
literals.  The ‘NEWS’ file of Guile 2.2 puts it this way:

  ** Fix literal matching for module-bound literals

  `syntax-rules' and `syntax-case' macros can take a set of "literals":
  bound or unbound keywords that the syntax matcher treats specially.
  Before, literals were always matched symbolically (by name).  Now they
  are matched by binding.  This allows literals to be reliably bound to
  values, renamed by imports or exports, et cetera.  See "Syntax-rules
  Macros" in the manual for more on literals.

In hindsight, it would have been wiser to just rename ‘_’ in (guix ui)
to something else, like ‘G_’.  Well, it’s not too late.  Should we do
that?  Thoughts?

Ludo’.

Re: [PATCH] DRAFT: gnu: icecat: Update to 52.0.2-gnu1; add fixes from ESR 52.1.

[Kei Kebreau]

Mark H Weaver  writes:

> Hello Guix,
>
> Here's a draft patch to update GNU IceCat to 52.0.2-gnu1, with
> additional fixes cherry-picked from upstream ESR 52.1.  It seems to work
> well on my system, except that my GNOME 3 session has locked up a couple
> of times while testing it[*].  I'm not yet sure whether the problem is
> caused by IceCat or something else.  I'd appreciate it if other people
> could try it out.
>
> [*] The mouse cursor still moves, and I can switch to text VTs, but
> otherwise the GUI is unresponsive.  Killing icecat is not sufficient
> to unfreeze the graphical session, but I'm able to restart the X
> server without rebooting.

I haven't tried this patch with GNOME 3, but I'm having no problems with
IceCat 52 on Window Maker.


signature.asc
Description: PGP signature

Re: 04/04: offload: Avoid using '_' as a 'match' pattern.

[Tobias Geerinckx-Rice]

Ludo',

On 21/04/17 17:24, Ludovic Court�s wrote:
> commit ba97e454bfbc168098212b37881b50b4fe6e1eb2 Author: Ludovic
> Courtès  Date:   Fri Apr 21 17:18:54 2017
> +0200
> 
> offload: Avoid using '_' as a 'match' pattern.
> 
> * guix/scripts/offload.scm (host-key->type+key, machine-load) 
> (process-request, guix-offload): Do not use '_' as a 'match'
> pattern.

Is this something that should now be avoided in general, i.e. when
writing packages/..., or only in specific circumstances?

(Apologies if I missed a thread about this somewhere. I suspect this
 has something to do with Guile 2.2, but could use some help finding
 out what to search for.)

Kind regards,

T G-R



signature.asc
Description: OpenPGP digital signature

Re: Staging

[Marius Bakke]

Looks like the queue was cancelled.

https://hydra.gnu.org/eval/109614?compare=master

Should we try to build out the remaining packages? There have been a few
large updates in 'master', might be useful to merge that first. Or just
go the other way around.. ;-)


signature.asc
Description: PGP signature

[PATCH] gnu: Add Xfce Notification Daemon.

[Petter]

Hi Guix,

Be extra critical while reviewing this patch, I'm not good at this.

(Today I learned that a provided DBus service file first takes effect
after installing. I wasn't having any luck testing directly from
store. Thanks again wingo!)

Best,
PetterFrom 4cf9acab0817d2898772830f27c1a11c15926b98 Mon Sep 17 00:00:00 2001
From: Petter 
Date: Fri, 21 Apr 2017 15:33:22 +0200
Subject: [PATCH] gnu: Add Xfce Notification Daemon.

* gnu/packages/xfce.scm (xfce4-notifyd): New variable.
---
 gnu/packages/xfce.scm | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/gnu/packages/xfce.scm b/gnu/packages/xfce.scm
index fce47d93c..f0e671259 100644
--- a/gnu/packages/xfce.scm
+++ b/gnu/packages/xfce.scm
@@ -5,6 +5,7 @@
 ;;; Copyright © 2016 Florian Paul Schmidt 
 ;;; Copyright © 2016 Kei Kebreau 
 ;;; Copyright © 2017 Ricardo Wurmus 
+;;; Copyright © 2017 Petter 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -850,3 +851,41 @@ calendar applications.  It also includes a panel clock plugin and an
 international clock application capable of simultaneously showing clocks from
 several different time zones.")
 (license gpl2+)))
+
+(define-public xfce4-notifyd
+  (package
+(name "xfce4-notifyd")
+(version "0.3.6")
+(source (origin
+  (method url-fetch)
+  (uri (string-append "http://archive.xfce.org/src/apps/;
+  name "/" (version-major+minor version) "/"
+  name "-" version ".tar.bz2"))
+  (sha256
+   (base32
+"1ybcfqfynr33g5hp2lgq17s8qyx7rq6fd2iwrpwcvm6kml6prjpl"
+(build-system gnu-build-system)
+(arguments
+ `(#:configure-flags
+   (list (string-append "--prefix=" %output
+(native-inputs
+ `(("intltool" ,intltool)
+   ("pkg-config" ,pkg-config)))
+(propagated-inputs
+ `(("glib:bin" ,glib "bin")))
+(inputs
+ `(("gtk+" ,gtk+)
+   ("libxfce4util" ,libxfce4util)
+   ("libxfce4ui" ,libxfce4ui)
+   ("xfconf" ,xfconf)
+   ("libnotify" ,libnotify)))
+(home-page "https://goodies.xfce.org/projects/applications/xfce4-notifyd;)
+(synopsis "Lets applications pop up a notification bubble")
+(description
+ "The Xfce Notify Daemon (xfce4-notifyd for short) is a smallish program
+that implements the “server-side” portion of the Freedesktop desktop
+notifications specification. Applications that wish to pop up a notification
+bubble in a standard way can implicitly make use of xfce4-notifyd to do so by
+sending standard messages over D-Bus using the org.freedesktop.Notifications
+interface.")
+(license gpl2)))
-- 
2.12.2

From 4cf9acab0817d2898772830f27c1a11c15926b98 Mon Sep 17 00:00:00 2001
From: Petter 
Date: Fri, 21 Apr 2017 15:33:22 +0200
Subject: [PATCH] gnu: Add Xfce Notification Daemon.

* gnu/packages/xfce.scm (xfce4-notifyd): New variable.
---
 gnu/packages/xfce.scm | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/gnu/packages/xfce.scm b/gnu/packages/xfce.scm
index fce47d93c..f0e671259 100644
--- a/gnu/packages/xfce.scm
+++ b/gnu/packages/xfce.scm
@@ -5,6 +5,7 @@
 ;;; Copyright © 2016 Florian Paul Schmidt 
 ;;; Copyright © 2016 Kei Kebreau 
 ;;; Copyright © 2017 Ricardo Wurmus 
+;;; Copyright © 2017 Petter 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -850,3 +851,41 @@ calendar applications.  It also includes a panel clock plugin and an
 international clock application capable of simultaneously showing clocks from
 several different time zones.")
 (license gpl2+)))
+
+(define-public xfce4-notifyd
+  (package
+(name "xfce4-notifyd")
+(version "0.3.6")
+(source (origin
+  (method url-fetch)
+  (uri (string-append "http://archive.xfce.org/src/apps/;
+  name "/" (version-major+minor version) "/"
+  name "-" version ".tar.bz2"))
+  (sha256
+   (base32
+"1ybcfqfynr33g5hp2lgq17s8qyx7rq6fd2iwrpwcvm6kml6prjpl"
+(build-system gnu-build-system)
+(arguments
+ `(#:configure-flags
+   (list (string-append "--prefix=" %output
+(native-inputs
+ `(("intltool" ,intltool)
+   ("pkg-config" ,pkg-config)))
+(propagated-inputs
+ `(("glib:bin" ,glib "bin")))
+(inputs
+ `(("gtk+" ,gtk+)
+   ("libxfce4util" ,libxfce4util)
+   ("libxfce4ui" ,libxfce4ui)
+   ("xfconf" ,xfconf)
+   ("libnotify" ,libnotify)))
+(home-page "https://goodies.xfce.org/projects/applications/xfce4-notifyd;)
+(synopsis "Lets applications pop up a notification bubble")
+(description
+ "The Xfce Notify Daemon (xfce4-notifyd for 

Help needed from Java developer to finish maven

[Hartmut Goebel]

Hi,

I'm seeking for help from some skilled Java developer. I nearly finished
bootstrapping maven: I made it to start up, but now fails with this
error message:

org.apache.maven.InternalErrorException: Internal error:
com.google.inject.ProvisionException: Unable to provision, see the
following errors:

1) null returned by binding at org.eclipse.sisu.wire.LocatorWiring
 but parameter 1 of
org.eclipse.aether.transport.wagon.WagonTransporterFactory.() is
not @Nullable
  while locating org.eclipse.aether.transport.wagon.WagonConfigurator
for parameter 1 at
org.eclipse.aether.transport.wagon.WagonTransporterFactory.(Unknown 
Source)
  while locating org.eclipse.aether.transport.wagon.WagonTransporterFactory
  while locating java.lang.Object annotated with *

I assume this means some meta-date file is missing in one of the jars
(like plexus/components.xml or sisu/javax.inject.Named), but I was not
able to find any missing file or data. may.

Any tipps?

-- 
Regards
Hartmut Goebel

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

Funding Guix development esp. maven?

[Hartmut Goebel]

Hi,

Ludo suggested me to ask on the mailing-list:

I'm seeking for some funding for working on Guix. Project-based this
could be bringing maven into guix.

Working on Guix is a lot of fun, but I'm a freelancer, so I need to make
my living somehow.  Currently I'm spending too much time on guix which
is missing on the income side. Unfortunately I have no contacts into the
software-development scene, since my business is quite different: I'm a
Consultant it Information Security Management (ISO 270001 and that
like). If I'd have software-development customers, of course I'd ask
them for funding.

If somebody has ideas how to fund working on Guix, please drop me a note
off-list.

-- 
Regards
Hartmut Goebel

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

Build-side code with non-ASCII failing to build on Hydra

[Mark H Weaver]

On the security-updates jobset on Hydra, I'm seeing several new build
failures due to non-ASCII characters within build-side code being
misread:

  https://hydra.gnu.org/build/2003897
  https://hydra.gnu.org/build/2001256
  https://hydra.gnu.org/build/2013954
  https://hydra.gnu.org/build/2006487
  https://hydra.gnu.org/eval/109617?compare=109613#tabs-now-fail

Has something changed recently that might explain this?

  Mark