Re: Release!

[Ludovic Courtès]

Hello!

Leo Famulari  skribis:

> On Thu, Nov 30, 2017 at 11:40:16AM +0100, Ludovic Courtès wrote:
>>   1. Do we pre-register berlin’s key on GuixSD?
>
> I vote yes.
>
>>   2. Do we add berlin.guixsd.org to the list of substitute servers on
>>  GuixSD?  On Guix?  The drawback is that ‘guix’ sometimes talks to
>>  both servers when retrieve substitute lists, which can be slightly
>>  slower/annoying, but otherwise I think it’s a win.
>
> I think it's worth the extra source of substitutes. Since adding
> berlin.guixsd.org to my list of substitute URLs, it seems like I need to
> build less often.
>
> In my experience, it's annoying to query multiple servers when my
> network connection is slow or unreliable. But, it's also annoying in
> that situation to need to download source files from a variety of
> upstream sites.

Sounds reasonable.  Let’s wait for a green light from Ricardo.

>> The main GuixSD annoying messages that I think we should address by
>> Tuesday are:
>> 
>>   1. “Error in finalization thread: Bad file descriptor” coming from the
>>  Shepherd;
>
> I'm not sure how to start debugging this :/ If I get some advice, I
> could try to fix it on Sunday and Monday.

I investigated and fixed it yesterday:

  
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=4bd70904c7f555a953808a9a4f892f462ffd352f

The thing is that there’s a separate finalization thread in Guile, which
takes care of finalizing dead objects.  For file ports, finalization
means closing the underlying file descriptor.  As it turns out,
‘close-port’ in Guile 2.0 would ignore EBADF errors, whereas
‘close-port’ in 2.2 reports them, hence the error.

The fix is to take extra care to close ports and not just the underlying
file descriptors.

>>   2. “udevd[304]: RUN{builtin}: 'uaccess' unknown 
>> /gnu/store/q7c8yayywf76ai3sgvz16pmbz07gj4bp-udev-rules/lib/udev/rules.d/73-seat-late.rules:15”
>
> I haven't seen this one before.

I compared the source of eudev and systemd, and indeed, like Maxim
wrote, the issue is that eudev does not support a “uaccess” built-in
tag.  So I pushed a fix that simply comments out that line:

  
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=f8446df663fecb5aa34e5c6dfa477544d3271d1e

There’s still room for improvement, but the console output is less messy
now.  :-)

Thanks,
Ludo’.

Re: Release!

[Ludovic Courtès]

Hello!

Ricardo Wurmus  skribis:

> Leo Famulari  writes:
>
>> On Thu, Nov 30, 2017 at 11:40:16AM +0100, Ludovic Courtès wrote:
>>>   1. Do we pre-register berlin’s key on GuixSD?
>>
>> I vote yes.
>>
>>>   2. Do we add berlin.guixsd.org to the list of substitute servers on
>>>  GuixSD?  On Guix?  The drawback is that ‘guix’ sometimes talks to
>>>  both servers when retrieve substitute lists, which can be slightly
>>>  slower/annoying, but otherwise I think it’s a win.
>>
>> I think it's worth the extra source of substitutes. Since adding
>> berlin.guixsd.org to my list of substitute URLs, it seems like I need to
>> build less often.
>>
>> In my experience, it's annoying to query multiple servers when my
>> network connection is slow or unreliable. But, it's also annoying in
>> that situation to need to download source files from a variety of
>> upstream sites.
>
> I’d like to add berlin.guix.org to the list of default substitute
> servers, but before I can allow this with a good conscience I need to
> increase space on the head node.  We were very busy, so the new head
> node and storage aren’t ready yet, and the old node that’s currently
> coordinating builds on berlin.guix.org has very limited storage.
>
> I’ll try to get the new storage ready on Monday.

Awesome.  Let us know how it goes and what we should do!

Thanks,
Ludo’.

ISO image available for testing!

[Ludovic Courtès]

Hello there!

I’ve uploaded a GuixSD installation ISO image for testing:

  
http://web.fdn.fr/~lcourtes/software/guix/guixsd-install-0.13.0.8d7f1d736.x86_64-linux.iso.xz
  SHA256: 7e04017494c419bb6ca654cff05dc7e5ba4fdfd3c2812fba9ba6d929b319e93b

  
http://web.fdn.fr/~lcourtes/software/guix/guixsd-install-0.13.0.8d7f1d736.x86_64-linux.iso.xz.sig

It was built with “guix system disk-image -t iso9660
gnu/system/install.scm” on commit 8d7f1d736.

Note that it’s 1.1G uncompressed so it won’t fit on a CD.

Feedback welcome!

Ludo’.


signature.asc
Description: PGP signature

Re: fcgiwrap doesn't see gzip

[Ludovic Courtès]

Hi Oleg,

Oleg Pykhalov  skribis:

> strace log from my previous message, apologies.
>
> I guess, the issue is because fcgiwrap process environment PATH only
> contains /gnu/store/…-shadow-4.5/sbin which doesn't include gzip.

There are two possible fixes:

  1. Set PATH in the execution environment of ‘fcgiwrap’, just like the
 ‘mcron-shepherd-services’ procedure does;

  2. Add a build phase for ‘fcgiwrap’ that ensures that it refers to
 ‘gzip’ by its absolute file name.

I have a preference for #2 because it’s more robust.

Could you look into it?

Thanks,
Ludo’.

Re: Installing some packages results in "incomplete deployment"

[Ludovic Courtès]

Hi Chris,

Chris Marusich  skribis:

> Some Guix packages exist which are not intended to be installed into a
> user's profile.  For example, android-udev-rules's description says:
>
> _Simply installing this package will not have any effect._ It is
> meant to be passed to the `udev' service.
>
> Still other packages do not work if they are installed by themselves.
> For example, xscreensaver (and other screen lockers [1]) does not work
> if you just install it into your profile; you need to add an instance of
> the screen-locker-service-type to your operating system declaration to
> ensure that xscreensaver gets installed as a setuid-root program.  Even
> after you do this, to be able to configure xscreensaver using the
> xscreensaver-demo program, you ALSO need to remember to install
> xscreensaver either into the system profile or into your user profile.
>
> Is there anything we can do about this situation?

[...]

> * Document packages like these - like android-udev-rules already does.
>
> * Don't display these packages by default in tools like "guix package
>   --search" (but maybe provide an option for displaying them if needed).
>
> * Don't export packages like these as public variables - hide them in
>   appropriate services.  For example, instead of requiring a user to
>   install both a service of the screen-locker-service-type configured to
>   use xscreensaver and also the xscreensaver package, modify the
>   screen-locker-service-type so that it automatically installs the
>   package into the system profile by extending the profile-service-type.
>   In short, make it impossible to install an xscreensaver screen locker
>   service incorrectly.
>
> What do you think?

I think adding a line in descriptions is often not very helpful—few
people are going to read that line.

Hiding those packages from the UI would be trivial: see ‘hidden-package’
in (guix packages).

We could do that, but it might be confusing: people will have a hard
time finding which screensavers are available, which is problematic.

Perhaps we could offer an option for packages to display hints at
installation time.  Like

  (package
(name "xscreensaver")
;; …
(properties
  `((installation-notice
 . ,(G_ "Please see the documentation of
@code{screen-locker-service-type} in the manual on how to use this
screen saver.")

Or maybe something higher level, like:

  '((use-with-service . screen-locker-service-type))

Thoughts?

Ludo’.

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

[Gábor Boskovits]

This minimal file reproduces the problem in icu4c 60.1 in guix environment
icu4c on current core-updates.

#include 

int main(int argc, char **argv)
{
  std::signbit(1);
  return 0;
}

It seems, that it is some problem with cmath.h

/gnu/store/2wzijwwgpcdb1msmn3wgq9zmrbrkpx2h-gcc-5.5.0/include/c++/cmath:44:0

The definition is in glibc 2.26 math.h, looks like this:

#elif __HAVE_DISTINCT_FLOAT128
# if __HAVE_GENERIC_SELECTION
#  define __MATH_TG(TG_ARG, FUNC, ARGS) \
 _Generic ((TG_ARG),\
   float: FUNC ## f ARGS,   \
   default: FUNC ARGS,  \
   long double: FUNC ## l ARGS, \
   _Float128: FUNC ## f128 ARGS)



2017-12-03 23:25 GMT+01:00 Gábor Boskovits :

> It seems, that the fix is already included in the 60.1 release for the
> xlocal problem. I think we can ignore that.
>
> 2017-12-03 23:20 GMT+01:00 Gábor Boskovits :
>
>> It seems, that they issued that already:
>> http://bugs.icu-project.org/trac/changeset/40603
>>
>> 2017-12-03 23:08 GMT+01:00 Gábor Boskovits :
>>
>>> Ok, I found this one:
>>> https://sourceware.org/glibc/wiki/Release/2.26#Removal_of_.2
>>> 7xlocale.h.27
>>>
>>> It seems, that xlocale.h should not be used as an include, and glibc
>>> removed that.
>>>
>>> So this is ok.
>>>
>>> The question is if this issue was addressed by icu4c, so we can just go
>>> to the next step, or should we do something about this.
>>>
>>>
>>> 2017-12-03 23:04 GMT+01:00 Gábor Boskovits :
>>>
 I've found that simply reverting the update to icu4c 60 commit brings
 up the issue you just mentioned, with missing xlocale.h.
 So it seems, that the one you found introduced the xlocale problem,
 while 4e080fbb0bb73e181599676f4e1ef5fdc2ba introduces the new
 error.
 I think we should deal with the one you find first, the see what's with
 this newer one.

 We also have a long running discussion on a bug introduced by a later
 glibc update, ee3ebf1a357bd4eb36a2fa1790a7b549cffb305a which broke a
 lot of packages. Might these be somehow related?
 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29537



 2017-12-03 22:46 GMT+01:00 Chris Marusich :

> Gábor Boskovits  writes:
>
> > Any news on this icu4c thing?
>
> After about 2 days of running git bisect, my computer has informed me
> that the first bad commit is 67d527e35e367c9e9e89ec01cda2ce32cabd2d89.
> This is the first commit where icu4c fails to build on core-updates.
> The build failure at this commit is as follows:
>
> --8<---cut here---start->8---
>g++   ...  decimfmt.cpp
>g++   ...  decimalformatpattern.cpp
>g++   ...  dcfmtsym.cpp
>g++   ...  digitlst.cpp
>g++   ...  fmtable_cnv.cpp
> digitlst.cpp:67:24: fatal error: xlocale.h: No such file or directory
> compilation terminated.
> *** Failed compilation command follows: --
> 
> g++ -D_REENTRANT -DU_HAVE_ELF_H=1 -DU_HAVE_ATOMIC=1
> -DU_HAVE_STRTOD_L=1 -I. -I../common -DU_ATTRIBUTE_DEPRECATED=
> -DU_I18N_IMPLEMENTATION -O2 -W -Wall -pedantic -Wpointer-arith
> -Wwrite-strings -Wno-long-long --std=c++0x -c -DPIC -fPIC -o digitlst.o
> digitlst.cpp
> --- ( rebuild with "make VERBOSE=1 all" to show all parameters )
> 
> make[1]: *** [../config/mh-linux:51: digitlst.o] Error 1
> make[1]: *** Waiting for unfinished jobs
> make[1]: Leaving directory '/tmp/guix-build-icu4c-58.2.dr
> v-0/icu/source/i18n'
> make: *** [Makefile:143: all-recursive] Error 2
> phase `build' failed after 59.0 seconds
> builder for `/gnu/store/mdd6glhc0dg65y4wd11y0b7sbky9cwv6-icu4c-58.2.drv'
> failed with exit code 1
> @ build-failed /gnu/store/mdd6glhc0dg65y4wd11y0b7sbky9cwv6-icu4c-58.2.drv
> - 1 builder for 
> `/gnu/store/mdd6glhc0dg65y4wd11y0b7sbky9cwv6-icu4c-58.2.drv'
> failed with exit code 1
> guix build: error: build failed: build of
> `/gnu/store/mdd6glhc0dg65y4wd11y0b7sbky9cwv6-icu4c-58.2.drv' failed
> --8<---cut here---end--->8---
>
> Note that this is NOT the same error as the one that occurs at commit
> d6adba786cf2ab1b26ff083928b64262281ff106 (which is the commit on
> core-updates from which Gábor's branch change-default-icedtea-8 branch
> begins).  That error is:
>
> --8<---cut here---start->8---
>g++   ...  number_decimalquantity.cpp
>g++   ...  number_decimfmtprops.cpp
> number_decimalquantity.cpp: In member function
> ‘icu_60::number::impl::DecimalQuantity& icu_60::number::impl::DecimalQ
> uantity::setToDouble(double)’:
> number_decimalquantity.cpp:333:9: error: ‘_Generic’ is not a member
> of ‘std’
>  if (std::signbit(n) != 0) {
>   

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

[Gábor Boskovits]

We have this in cdefs.h:
#if __GNUC_PREREQ (4, 9) \
|| __glibc_clang_has_extension (c_generic_selections) \
|| (!defined __GNUC__ && defined __STDC_VERSION__ \
&& __STDC_VERSION__ >= 201112L)
# define __HAVE_GENERIC_SELECTION 1
#else
# define __HAVE_GENERIC_SELECTION 0
#endif

This does not seem right.

We should not have this defined when compiling c++.
WDYT?

2017-12-04 13:03 GMT+01:00 Gábor Boskovits :

> This minimal file reproduces the problem in icu4c 60.1 in guix environment
> icu4c on current core-updates.
>
> #include 
>
> int main(int argc, char **argv)
> {
>   std::signbit(1);
>   return 0;
> }
>
> It seems, that it is some problem with cmath.h
>
> /gnu/store/2wzijwwgpcdb1msmn3wgq9zmrbrkpx2h-gcc-5.5.0/
> include/c++/cmath:44:0
>
> The definition is in glibc 2.26 math.h, looks like this:
>
> #elif __HAVE_DISTINCT_FLOAT128
> # if __HAVE_GENERIC_SELECTION
> #  define __MATH_TG(TG_ARG, FUNC, ARGS) \
>  _Generic ((TG_ARG),\
>float: FUNC ## f ARGS,   \
>default: FUNC ARGS,  \
>long double: FUNC ## l ARGS, \
>_Float128: FUNC ## f128 ARGS)
>
>
>
> 2017-12-03 23:25 GMT+01:00 Gábor Boskovits :
>
>> It seems, that the fix is already included in the 60.1 release for the
>> xlocal problem. I think we can ignore that.
>>
>> 2017-12-03 23:20 GMT+01:00 Gábor Boskovits :
>>
>>> It seems, that they issued that already:
>>> http://bugs.icu-project.org/trac/changeset/40603
>>>
>>> 2017-12-03 23:08 GMT+01:00 Gábor Boskovits :
>>>
 Ok, I found this one:
 https://sourceware.org/glibc/wiki/Release/2.26#Removal_of_.2
 7xlocale.h.27

 It seems, that xlocale.h should not be used as an include, and glibc
 removed that.

 So this is ok.

 The question is if this issue was addressed by icu4c, so we can just go
 to the next step, or should we do something about this.


 2017-12-03 23:04 GMT+01:00 Gábor Boskovits :

> I've found that simply reverting the update to icu4c 60 commit brings
> up the issue you just mentioned, with missing xlocale.h.
> So it seems, that the one you found introduced the xlocale problem,
> while 4e080fbb0bb73e181599676f4e1ef5fdc2ba introduces the new
> error.
> I think we should deal with the one you find first, the see what's
> with this newer one.
>
> We also have a long running discussion on a bug introduced by a later
> glibc update, ee3ebf1a357bd4eb36a2fa1790a7b549cffb305a which broke a
> lot of packages. Might these be somehow related?
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29537
>
>
>
> 2017-12-03 22:46 GMT+01:00 Chris Marusich :
>
>> Gábor Boskovits  writes:
>>
>> > Any news on this icu4c thing?
>>
>> After about 2 days of running git bisect, my computer has informed me
>> that the first bad commit is 67d527e35e367c9e9e89ec01cda2ce
>> 32cabd2d89.
>> This is the first commit where icu4c fails to build on core-updates.
>> The build failure at this commit is as follows:
>>
>> --8<---cut here---start->8---
>>g++   ...  decimfmt.cpp
>>g++   ...  decimalformatpattern.cpp
>>g++   ...  dcfmtsym.cpp
>>g++   ...  digitlst.cpp
>>g++   ...  fmtable_cnv.cpp
>> digitlst.cpp:67:24: fatal error: xlocale.h: No such file or directory
>> compilation terminated.
>> *** Failed compilation command follows: --
>> 
>> g++ -D_REENTRANT -DU_HAVE_ELF_H=1 -DU_HAVE_ATOMIC=1
>> -DU_HAVE_STRTOD_L=1 -I. -I../common -DU_ATTRIBUTE_DEPRECATED=
>> -DU_I18N_IMPLEMENTATION -O2 -W -Wall -pedantic -Wpointer-arith
>> -Wwrite-strings -Wno-long-long --std=c++0x -c -DPIC -fPIC -o digitlst.o
>> digitlst.cpp
>> --- ( rebuild with "make VERBOSE=1 all" to show all parameters )
>> 
>> make[1]: *** [../config/mh-linux:51: digitlst.o] Error 1
>> make[1]: *** Waiting for unfinished jobs
>> make[1]: Leaving directory '/tmp/guix-build-icu4c-58.2.dr
>> v-0/icu/source/i18n'
>> make: *** [Makefile:143: all-recursive] Error 2
>> phase `build' failed after 59.0 seconds
>> builder for `/gnu/store/mdd6glhc0dg65y4wd11y0b7sbky9cwv6-icu4c-58.2.drv'
>> failed with exit code 1
>> @ build-failed /gnu/store/mdd6glhc0dg65y4wd11y0b7sbky9cwv6-icu4c-58.2.drv
>> - 1 builder for 
>> `/gnu/store/mdd6glhc0dg65y4wd11y0b7sbky9cwv6-icu4c-58.2.drv'
>> failed with exit code 1
>> guix build: error: build failed: build of
>> `/gnu/store/mdd6glhc0dg65y4wd11y0b7sbky9cwv6-icu4c-58.2.drv' failed
>> --8<---cut here---end--->8---
>>
>> Note that this is NOT the same error as the one that occurs at commit
>> d6adba786cf2ab1b26ff083928b64262281ff106 (which is the commit on
>> c

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

[Gábor Boskovits]

We also have this in bits/floatn.h, but this seems right.

#if (defined __x86_64__ \
 ? __GNUC_PREREQ (4, 3) \
 : (defined __GNU__ ? __GNUC_PREREQ (4, 5) : __GNUC_PREREQ (4, 4)))
# define __HAVE_FLOAT128 1
#else
# define __HAVE_FLOAT128 0
#endif

/* Defined to 1 if __HAVE_FLOAT128 is 1 and the type is ABI-distinct


   from the default float, double and long double types in this glibc.  */
#if __HAVE_FLOAT128
# define __HAVE_DISTINCT_FLOAT128 1
#else
# define __HAVE_DISTINCT_FLOAT128 0
#endif

I think the problem is caused by HAVE_GENERIC_SELECTION defined when we are
in C++.


2017-12-04 13:18 GMT+01:00 Gábor Boskovits :

> We have this in cdefs.h:
> #if __GNUC_PREREQ (4, 9) \
> || __glibc_clang_has_extension (c_generic_selections) \
> || (!defined __GNUC__ && defined __STDC_VERSION__ \
> && __STDC_VERSION__ >= 201112L)
> # define __HAVE_GENERIC_SELECTION 1
> #else
> # define __HAVE_GENERIC_SELECTION 0
> #endif
>
> This does not seem right.
>
> We should not have this defined when compiling c++.
> WDYT?
>
> 2017-12-04 13:03 GMT+01:00 Gábor Boskovits :
>
>> This minimal file reproduces the problem in icu4c 60.1 in guix
>> environment icu4c on current core-updates.
>>
>> #include 
>>
>> int main(int argc, char **argv)
>> {
>>   std::signbit(1);
>>   return 0;
>> }
>>
>> It seems, that it is some problem with cmath.h
>>
>> /gnu/store/2wzijwwgpcdb1msmn3wgq9zmrbrkpx2h-gcc-5.5.0/includ
>> e/c++/cmath:44:0
>>
>> The definition is in glibc 2.26 math.h, looks like this:
>>
>> #elif __HAVE_DISTINCT_FLOAT128
>> # if __HAVE_GENERIC_SELECTION
>> #  define __MATH_TG(TG_ARG, FUNC, ARGS) \
>>  _Generic ((TG_ARG),\
>>float: FUNC ## f ARGS,   \
>>default: FUNC ARGS,  \
>>long double: FUNC ## l ARGS, \
>>_Float128: FUNC ## f128 ARGS)
>>
>>
>>
>> 2017-12-03 23:25 GMT+01:00 Gábor Boskovits :
>>
>>> It seems, that the fix is already included in the 60.1 release for the
>>> xlocal problem. I think we can ignore that.
>>>
>>> 2017-12-03 23:20 GMT+01:00 Gábor Boskovits :
>>>
 It seems, that they issued that already:
 http://bugs.icu-project.org/trac/changeset/40603

 2017-12-03 23:08 GMT+01:00 Gábor Boskovits :

> Ok, I found this one:
> https://sourceware.org/glibc/wiki/Release/2.26#Removal_of_.2
> 7xlocale.h.27
>
> It seems, that xlocale.h should not be used as an include, and glibc
> removed that.
>
> So this is ok.
>
> The question is if this issue was addressed by icu4c, so we can just
> go to the next step, or should we do something about this.
>
>
> 2017-12-03 23:04 GMT+01:00 Gábor Boskovits :
>
>> I've found that simply reverting the update to icu4c 60 commit brings
>> up the issue you just mentioned, with missing xlocale.h.
>> So it seems, that the one you found introduced the xlocale problem,
>> while 4e080fbb0bb73e181599676f4e1ef5fdc2ba introduces the new
>> error.
>> I think we should deal with the one you find first, the see what's
>> with this newer one.
>>
>> We also have a long running discussion on a bug introduced by a later
>> glibc update, ee3ebf1a357bd4eb36a2fa1790a7b549cffb305a which broke a
>> lot of packages. Might these be somehow related?
>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29537
>>
>>
>>
>> 2017-12-03 22:46 GMT+01:00 Chris Marusich :
>>
>>> Gábor Boskovits  writes:
>>>
>>> > Any news on this icu4c thing?
>>>
>>> After about 2 days of running git bisect, my computer has informed me
>>> that the first bad commit is 67d527e35e367c9e9e89ec01cda2ce
>>> 32cabd2d89.
>>> This is the first commit where icu4c fails to build on core-updates.
>>> The build failure at this commit is as follows:
>>>
>>> --8<---cut here---start->8---
>>>g++   ...  decimfmt.cpp
>>>g++   ...  decimalformatpattern.cpp
>>>g++   ...  dcfmtsym.cpp
>>>g++   ...  digitlst.cpp
>>>g++   ...  fmtable_cnv.cpp
>>> digitlst.cpp:67:24: fatal error: xlocale.h: No such file or directory
>>> compilation terminated.
>>> *** Failed compilation command follows:
>>> --
>>> g++ -D_REENTRANT -DU_HAVE_ELF_H=1 -DU_HAVE_ATOMIC=1
>>> -DU_HAVE_STRTOD_L=1 -I. -I../common -DU_ATTRIBUTE_DEPRECATED=
>>> -DU_I18N_IMPLEMENTATION -O2 -W -Wall -pedantic -Wpointer-arith
>>> -Wwrite-strings -Wno-long-long --std=c++0x -c -DPIC -fPIC -o digitlst.o
>>> digitlst.cpp
>>> --- ( rebuild with "make VERBOSE=1 all" to show all parameters )
>>> 
>>> make[1]: *** [../config/mh-linux:51: digitlst.o] Error 1
>>> make[1]: *** Waiting for unfinished jobs
>>> m

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

[Gábor Boskovits]

I think it should look like this:

--- cdefs.h 2017-12-04 13:27:55.64000 +0100
+++ cdefs.new.h 2017-12-04 13:31:53.82000 +0100
@@ -1,4 +1,4 @@
-/* Copyright (C) 1992-2017 Free Software Foundation, Inc.
+y/* Copyright (C) 1992-2017 Free Software Foundation, Inc.
This file is part of the GNU C Library.

The GNU C Library is free software; you can redistribute it and/or
@@ -471,10 +471,10 @@
testing __STDC_VERSION__ for generic selection support.
On the other hand, Clang also defines __GNUC__, so a clang-specific
check is required to enable the use of generic selection.  */
-#if __GNUC_PREREQ (4, 9) \
+#if !defined __cplusplus && (__GNUC_PREREQ (4, 9)   \
 || __glibc_clang_has_extension (c_generic_selections) \
 || (!defined __GNUC__ && defined __STDC_VERSION__ \
- && __STDC_VERSION__ >= 201112L)
+ && __STDC_VERSION__ >= 201112L))
 # define __HAVE_GENERIC_SELECTION 1
 #else
 # define __HAVE_GENERIC_SELECTION 0


2017-12-04 13:21 GMT+01:00 Gábor Boskovits :

> We also have this in bits/floatn.h, but this seems right.
>
> #if (defined __x86_64__ \
>  ? __GNUC_PREREQ (4, 3) \
>  : (defined __GNU__ ? __GNUC_PREREQ (4, 5) : __GNUC_PREREQ (4, 4)))
> # define __HAVE_FLOAT128 1
> #else
> # define __HAVE_FLOAT128 0
> #endif
>
> /* Defined to 1 if __HAVE_FLOAT128 is 1 and the type is ABI-distinct
>
>
>from the default float, double and long double types in this glibc.  */
> #if __HAVE_FLOAT128
> # define __HAVE_DISTINCT_FLOAT128 1
> #else
> # define __HAVE_DISTINCT_FLOAT128 0
> #endif
>
> I think the problem is caused by HAVE_GENERIC_SELECTION defined when we
> are in C++.
>
>
> 2017-12-04 13:18 GMT+01:00 Gábor Boskovits :
>
>> We have this in cdefs.h:
>> #if __GNUC_PREREQ (4, 9) \
>> || __glibc_clang_has_extension (c_generic_selections) \
>> || (!defined __GNUC__ && defined __STDC_VERSION__ \
>> && __STDC_VERSION__ >= 201112L)
>> # define __HAVE_GENERIC_SELECTION 1
>> #else
>> # define __HAVE_GENERIC_SELECTION 0
>> #endif
>>
>> This does not seem right.
>>
>> We should not have this defined when compiling c++.
>> WDYT?
>>
>> 2017-12-04 13:03 GMT+01:00 Gábor Boskovits :
>>
>>> This minimal file reproduces the problem in icu4c 60.1 in guix
>>> environment icu4c on current core-updates.
>>>
>>> #include 
>>>
>>> int main(int argc, char **argv)
>>> {
>>>   std::signbit(1);
>>>   return 0;
>>> }
>>>
>>> It seems, that it is some problem with cmath.h
>>>
>>> /gnu/store/2wzijwwgpcdb1msmn3wgq9zmrbrkpx2h-gcc-5.5.0/includ
>>> e/c++/cmath:44:0
>>>
>>> The definition is in glibc 2.26 math.h, looks like this:
>>>
>>> #elif __HAVE_DISTINCT_FLOAT128
>>> # if __HAVE_GENERIC_SELECTION
>>> #  define __MATH_TG(TG_ARG, FUNC, ARGS) \
>>>  _Generic ((TG_ARG),\
>>>float: FUNC ## f ARGS,   \
>>>default: FUNC ARGS,  \
>>>long double: FUNC ## l ARGS, \
>>>_Float128: FUNC ## f128 ARGS)
>>>
>>>
>>>
>>> 2017-12-03 23:25 GMT+01:00 Gábor Boskovits :
>>>
 It seems, that the fix is already included in the 60.1 release for the
 xlocal problem. I think we can ignore that.

 2017-12-03 23:20 GMT+01:00 Gábor Boskovits :

> It seems, that they issued that already:
> http://bugs.icu-project.org/trac/changeset/40603
>
> 2017-12-03 23:08 GMT+01:00 Gábor Boskovits :
>
>> Ok, I found this one:
>> https://sourceware.org/glibc/wiki/Release/2.26#Removal_of_.2
>> 7xlocale.h.27
>>
>> It seems, that xlocale.h should not be used as an include, and glibc
>> removed that.
>>
>> So this is ok.
>>
>> The question is if this issue was addressed by icu4c, so we can just
>> go to the next step, or should we do something about this.
>>
>>
>> 2017-12-03 23:04 GMT+01:00 Gábor Boskovits :
>>
>>> I've found that simply reverting the update to icu4c 60 commit
>>> brings up the issue you just mentioned, with missing xlocale.h.
>>> So it seems, that the one you found introduced the xlocale problem,
>>> while 4e080fbb0bb73e181599676f4e1ef5fdc2ba introduces the new
>>> error.
>>> I think we should deal with the one you find first, the see what's
>>> with this newer one.
>>>
>>> We also have a long running discussion on a bug introduced by a
>>> later glibc update, ee3ebf1a357bd4eb36a2fa1790a7b549cffb305a which
>>> broke a lot of packages. Might these be somehow related?
>>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29537
>>>
>>>
>>>
>>> 2017-12-03 22:46 GMT+01:00 Chris Marusich :
>>>
 Gábor Boskovits  writes:

 > Any news on this icu4c thing?

 After about 2 days of running git bisect, my computer has informed
 me
 that the first bad commit is 67d527e35e367c9e9e89ec01cda2ce
 32cabd

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

[Gábor Boskovits]

Upstream corrected the issue in commit
6913ad65e00bb32417ad39c41d292b976171e27e.

It is not yet included in 2.26.

The patch is basically the same as I proposed.

I think we should get the upstream version.

2017-12-04 13:33 GMT+01:00 Gábor Boskovits :

> I think it should look like this:
>
> --- cdefs.h 2017-12-04 13:27:55.64000 +0100
> +++ cdefs.new.h 2017-12-04 13:31:53.82000 +0100
> @@ -1,4 +1,4 @@
> -/* Copyright (C) 1992-2017 Free Software Foundation, Inc.
> +y/* Copyright (C) 1992-2017 Free Software Foundation, Inc.
> This file is part of the GNU C Library.
>
> The GNU C Library is free software; you can redistribute it and/or
> @@ -471,10 +471,10 @@
> testing __STDC_VERSION__ for generic selection support.
> On the other hand, Clang also defines __GNUC__, so a clang-specific
> check is required to enable the use of generic selection.  */
> -#if __GNUC_PREREQ (4, 9) \
> +#if !defined __cplusplus && (__GNUC_PREREQ (4, 9)   \
>  || __glibc_clang_has_extension (c_generic_selections) \
>  || (!defined __GNUC__ && defined __STDC_VERSION__ \
> - && __STDC_VERSION__ >= 201112L)
> + && __STDC_VERSION__ >= 201112L))
>  # define __HAVE_GENERIC_SELECTION 1
>  #else
>  # define __HAVE_GENERIC_SELECTION 0
>
>
> 2017-12-04 13:21 GMT+01:00 Gábor Boskovits :
>
>> We also have this in bits/floatn.h, but this seems right.
>>
>> #if (defined __x86_64__ \
>>  ? __GNUC_PREREQ (4, 3) \
>>  : (defined __GNU__ ? __GNUC_PREREQ (4, 5) : __GNUC_PREREQ (4, 4)))
>> # define __HAVE_FLOAT128 1
>> #else
>> # define __HAVE_FLOAT128 0
>> #endif
>>
>> /* Defined to 1 if __HAVE_FLOAT128 is 1 and the type is ABI-distinct
>>
>>
>>from the default float, double and long double types in this glibc.  */
>> #if __HAVE_FLOAT128
>> # define __HAVE_DISTINCT_FLOAT128 1
>> #else
>> # define __HAVE_DISTINCT_FLOAT128 0
>> #endif
>>
>> I think the problem is caused by HAVE_GENERIC_SELECTION defined when we
>> are in C++.
>>
>>
>> 2017-12-04 13:18 GMT+01:00 Gábor Boskovits :
>>
>>> We have this in cdefs.h:
>>> #if __GNUC_PREREQ (4, 9) \
>>> || __glibc_clang_has_extension (c_generic_selections) \
>>> || (!defined __GNUC__ && defined __STDC_VERSION__ \
>>> && __STDC_VERSION__ >= 201112L)
>>> # define __HAVE_GENERIC_SELECTION 1
>>> #else
>>> # define __HAVE_GENERIC_SELECTION 0
>>> #endif
>>>
>>> This does not seem right.
>>>
>>> We should not have this defined when compiling c++.
>>> WDYT?
>>>
>>> 2017-12-04 13:03 GMT+01:00 Gábor Boskovits :
>>>
 This minimal file reproduces the problem in icu4c 60.1 in guix
 environment icu4c on current core-updates.

 #include 

 int main(int argc, char **argv)
 {
   std::signbit(1);
   return 0;
 }

 It seems, that it is some problem with cmath.h

 /gnu/store/2wzijwwgpcdb1msmn3wgq9zmrbrkpx2h-gcc-5.5.0/includ
 e/c++/cmath:44:0

 The definition is in glibc 2.26 math.h, looks like this:

 #elif __HAVE_DISTINCT_FLOAT128
 # if __HAVE_GENERIC_SELECTION
 #  define __MATH_TG(TG_ARG, FUNC, ARGS) \
  _Generic ((TG_ARG),\
float: FUNC ## f ARGS,   \
default: FUNC ARGS,  \
long double: FUNC ## l ARGS, \
_Float128: FUNC ## f128 ARGS)



 2017-12-03 23:25 GMT+01:00 Gábor Boskovits :

> It seems, that the fix is already included in the 60.1 release for the
> xlocal problem. I think we can ignore that.
>
> 2017-12-03 23:20 GMT+01:00 Gábor Boskovits :
>
>> It seems, that they issued that already:
>> http://bugs.icu-project.org/trac/changeset/40603
>>
>> 2017-12-03 23:08 GMT+01:00 Gábor Boskovits :
>>
>>> Ok, I found this one:
>>> https://sourceware.org/glibc/wiki/Release/2.26#Removal_of_.2
>>> 7xlocale.h.27
>>>
>>> It seems, that xlocale.h should not be used as an include, and glibc
>>> removed that.
>>>
>>> So this is ok.
>>>
>>> The question is if this issue was addressed by icu4c, so we can just
>>> go to the next step, or should we do something about this.
>>>
>>>
>>> 2017-12-03 23:04 GMT+01:00 Gábor Boskovits :
>>>
 I've found that simply reverting the update to icu4c 60 commit
 brings up the issue you just mentioned, with missing xlocale.h.
 So it seems, that the one you found introduced the xlocale problem,
 while 4e080fbb0bb73e181599676f4e1ef5fdc2ba introduces the new
 error.
 I think we should deal with the one you find first, the see what's
 with this newer one.

 We also have a long running discussion on a bug introduced by a
 later glibc update, ee3ebf1a357bd4eb36a2fa1790a7b549cffb305a which
 broke a lot of packages. Might these be somehow relat

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

[Gábor Boskovits]

Ok, so it seems, that the latest glibc update was made to fix the icu4c
thing.
It just broke the locales.
Fix for that has just been pushed, making core-updates usable again.
I pushed to my icedtea branch also.
I'm now building it to see what we have now.

2017-12-04 13:59 GMT+01:00 Gábor Boskovits :

> Upstream corrected the issue in commit 6913ad65e00bb32417ad39c41d292b
> 976171e27e.
>
> It is not yet included in 2.26.
>
> The patch is basically the same as I proposed.
>
> I think we should get the upstream version.
>
> 2017-12-04 13:33 GMT+01:00 Gábor Boskovits :
>
>> I think it should look like this:
>>
>> --- cdefs.h 2017-12-04 13:27:55.64000 +0100
>> +++ cdefs.new.h 2017-12-04 13:31:53.82000 +0100
>> @@ -1,4 +1,4 @@
>> -/* Copyright (C) 1992-2017 Free Software Foundation, Inc.
>> +y/* Copyright (C) 1992-2017 Free Software Foundation, Inc.
>> This file is part of the GNU C Library.
>>
>> The GNU C Library is free software; you can redistribute it and/or
>> @@ -471,10 +471,10 @@
>> testing __STDC_VERSION__ for generic selection support.
>> On the other hand, Clang also defines __GNUC__, so a clang-specific
>> check is required to enable the use of generic selection.  */
>> -#if __GNUC_PREREQ (4, 9) \
>> +#if !defined __cplusplus && (__GNUC_PREREQ (4, 9)   \
>>  || __glibc_clang_has_extension (c_generic_selections) \
>>  || (!defined __GNUC__ && defined __STDC_VERSION__ \
>> - && __STDC_VERSION__ >= 201112L)
>> + && __STDC_VERSION__ >= 201112L))
>>  # define __HAVE_GENERIC_SELECTION 1
>>  #else
>>  # define __HAVE_GENERIC_SELECTION 0
>>
>>
>> 2017-12-04 13:21 GMT+01:00 Gábor Boskovits :
>>
>>> We also have this in bits/floatn.h, but this seems right.
>>>
>>> #if (defined __x86_64__ \
>>>  ? __GNUC_PREREQ (4, 3) \
>>>  : (defined __GNU__ ? __GNUC_PREREQ (4, 5) : __GNUC_PREREQ (4, 4)))
>>> # define __HAVE_FLOAT128 1
>>> #else
>>> # define __HAVE_FLOAT128 0
>>> #endif
>>>
>>> /* Defined to 1 if __HAVE_FLOAT128 is 1 and the type is ABI-distinct
>>>
>>>
>>>from the default float, double and long double types in this glibc.
>>> */
>>> #if __HAVE_FLOAT128
>>> # define __HAVE_DISTINCT_FLOAT128 1
>>> #else
>>> # define __HAVE_DISTINCT_FLOAT128 0
>>> #endif
>>>
>>> I think the problem is caused by HAVE_GENERIC_SELECTION defined when we
>>> are in C++.
>>>
>>>
>>> 2017-12-04 13:18 GMT+01:00 Gábor Boskovits :
>>>
 We have this in cdefs.h:
 #if __GNUC_PREREQ (4, 9) \
 || __glibc_clang_has_extension (c_generic_selections) \
 || (!defined __GNUC__ && defined __STDC_VERSION__ \
 && __STDC_VERSION__ >= 201112L)
 # define __HAVE_GENERIC_SELECTION 1
 #else
 # define __HAVE_GENERIC_SELECTION 0
 #endif

 This does not seem right.

 We should not have this defined when compiling c++.
 WDYT?

 2017-12-04 13:03 GMT+01:00 Gábor Boskovits :

> This minimal file reproduces the problem in icu4c 60.1 in guix
> environment icu4c on current core-updates.
>
> #include 
>
> int main(int argc, char **argv)
> {
>   std::signbit(1);
>   return 0;
> }
>
> It seems, that it is some problem with cmath.h
>
> /gnu/store/2wzijwwgpcdb1msmn3wgq9zmrbrkpx2h-gcc-5.5.0/includ
> e/c++/cmath:44:0
>
> The definition is in glibc 2.26 math.h, looks like this:
>
> #elif __HAVE_DISTINCT_FLOAT128
> # if __HAVE_GENERIC_SELECTION
> #  define __MATH_TG(TG_ARG, FUNC, ARGS) \
>  _Generic ((TG_ARG),\
>float: FUNC ## f ARGS,   \
>default: FUNC ARGS,  \
>long double: FUNC ## l ARGS, \
>_Float128: FUNC ## f128 ARGS)
>
>
>
> 2017-12-03 23:25 GMT+01:00 Gábor Boskovits :
>
>> It seems, that the fix is already included in the 60.1 release for
>> the xlocal problem. I think we can ignore that.
>>
>> 2017-12-03 23:20 GMT+01:00 Gábor Boskovits :
>>
>>> It seems, that they issued that already:
>>> http://bugs.icu-project.org/trac/changeset/40603
>>>
>>> 2017-12-03 23:08 GMT+01:00 Gábor Boskovits :
>>>
 Ok, I found this one:
 https://sourceware.org/glibc/wiki/Release/2.26#Removal_of_.2
 7xlocale.h.27

 It seems, that xlocale.h should not be used as an include, and
 glibc removed that.

 So this is ok.

 The question is if this issue was addressed by icu4c, so we can
 just go to the next step, or should we do something about this.


 2017-12-03 23:04 GMT+01:00 Gábor Boskovits :

> I've found that simply reverting the update to icu4c 60 commit
> brings up the issue you just mentioned, with missing xlocale.h.
> So it seems, that the one you fo

Re: Problems with setting up prosody with IPv6 and certbot

[Clément Lassieur]

Hi nee,

Thank you for the report!

nee  writes:

> Proper fix:
> Build prosody with luasocket 3.0rc1 which introduced ipv6 support and is
> recommended on http://prosody.im/doc/ipv6
> Currently we only have luasocket 2.0.2 packaged.

I sent a patch that updates lua5.1-socket, see
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29562.

> I packaged luasocket 3.0-ac3201d in my package path. 3.0-ac3201d is the
> version which is used by Debian and Arch, it fixed some build system
> bugs that are in the 3.0rc1 version that hasn't been updated since 2013.

Debian and Arch use different versions.  The one used by Debian seems to
introduce other bugs, so they added extra patches to fix them, see
https://groups.google.com/forum/#!topic/linux.debian.bugs.rc/Kt84Dq4iFwI.
I believe it's safer to stick with 3.0-rc1, which is recommended by
Prosody anyway.

Clément

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

[Gábor Boskovits]

Now that this problem around glibc is resolved, I think I will do some
history rewrite, so that these reverts, reverting the revert does not
show up.
I 'm also willing to rename the branch to have wip in the name, as this
seems to be standard for longer runnig parts. WDYT?

2017-12-04 15:19 GMT+01:00 Gábor Boskovits :

> Ok, so it seems, that the latest glibc update was made to fix the icu4c
> thing.
> It just broke the locales.
> Fix for that has just been pushed, making core-updates usable again.
> I pushed to my icedtea branch also.
> I'm now building it to see what we have now.
>
> 2017-12-04 13:59 GMT+01:00 Gábor Boskovits :
>
>> Upstream corrected the issue in commit 6913ad65e00bb32417ad39c41d292b
>> 976171e27e.
>>
>> It is not yet included in 2.26.
>>
>> The patch is basically the same as I proposed.
>>
>> I think we should get the upstream version.
>>
>> 2017-12-04 13:33 GMT+01:00 Gábor Boskovits :
>>
>>> I think it should look like this:
>>>
>>> --- cdefs.h 2017-12-04 13:27:55.64000 +0100
>>> +++ cdefs.new.h 2017-12-04 13:31:53.82000 +0100
>>> @@ -1,4 +1,4 @@
>>> -/* Copyright (C) 1992-2017 Free Software Foundation, Inc.
>>> +y/* Copyright (C) 1992-2017 Free Software Foundation, Inc.
>>> This file is part of the GNU C Library.
>>>
>>> The GNU C Library is free software; you can redistribute it and/or
>>> @@ -471,10 +471,10 @@
>>> testing __STDC_VERSION__ for generic selection support.
>>> On the other hand, Clang also defines __GNUC__, so a clang-specific
>>> check is required to enable the use of generic selection.  */
>>> -#if __GNUC_PREREQ (4, 9) \
>>> +#if !defined __cplusplus && (__GNUC_PREREQ (4, 9)   \
>>>  || __glibc_clang_has_extension (c_generic_selections) \
>>>  || (!defined __GNUC__ && defined __STDC_VERSION__ \
>>> - && __STDC_VERSION__ >= 201112L)
>>> + && __STDC_VERSION__ >= 201112L))
>>>  # define __HAVE_GENERIC_SELECTION 1
>>>  #else
>>>  # define __HAVE_GENERIC_SELECTION 0
>>>
>>>
>>> 2017-12-04 13:21 GMT+01:00 Gábor Boskovits :
>>>
 We also have this in bits/floatn.h, but this seems right.

 #if (defined __x86_64__
  \
  ? __GNUC_PREREQ (4, 3)
  \
  : (defined __GNU__ ? __GNUC_PREREQ (4, 5) : __GNUC_PREREQ (4, 4)))
 # define __HAVE_FLOAT128 1
 #else
 # define __HAVE_FLOAT128 0
 #endif

 /* Defined to 1 if __HAVE_FLOAT128 is 1 and the type is ABI-distinct


from the default float, double and long double types in this glibc.
 */
 #if __HAVE_FLOAT128
 # define __HAVE_DISTINCT_FLOAT128 1
 #else
 # define __HAVE_DISTINCT_FLOAT128 0
 #endif

 I think the problem is caused by HAVE_GENERIC_SELECTION defined when we
 are in C++.


 2017-12-04 13:18 GMT+01:00 Gábor Boskovits :

> We have this in cdefs.h:
> #if __GNUC_PREREQ (4, 9) \
> || __glibc_clang_has_extension (c_generic_selections) \
> || (!defined __GNUC__ && defined __STDC_VERSION__ \
> && __STDC_VERSION__ >= 201112L)
> # define __HAVE_GENERIC_SELECTION 1
> #else
> # define __HAVE_GENERIC_SELECTION 0
> #endif
>
> This does not seem right.
>
> We should not have this defined when compiling c++.
> WDYT?
>
> 2017-12-04 13:03 GMT+01:00 Gábor Boskovits :
>
>> This minimal file reproduces the problem in icu4c 60.1 in guix
>> environment icu4c on current core-updates.
>>
>> #include 
>>
>> int main(int argc, char **argv)
>> {
>>   std::signbit(1);
>>   return 0;
>> }
>>
>> It seems, that it is some problem with cmath.h
>>
>> /gnu/store/2wzijwwgpcdb1msmn3wgq9zmrbrkpx2h-gcc-5.5.0/includ
>> e/c++/cmath:44:0
>>
>> The definition is in glibc 2.26 math.h, looks like this:
>>
>> #elif __HAVE_DISTINCT_FLOAT128
>> # if __HAVE_GENERIC_SELECTION
>> #  define __MATH_TG(TG_ARG, FUNC, ARGS) \
>>  _Generic ((TG_ARG),\
>>float: FUNC ## f ARGS,   \
>>default: FUNC ARGS,  \
>>long double: FUNC ## l ARGS, \
>>_Float128: FUNC ## f128 ARGS)
>>
>>
>>
>> 2017-12-03 23:25 GMT+01:00 Gábor Boskovits :
>>
>>> It seems, that the fix is already included in the 60.1 release for
>>> the xlocal problem. I think we can ignore that.
>>>
>>> 2017-12-03 23:20 GMT+01:00 Gábor Boskovits :
>>>
 It seems, that they issued that already:
 http://bugs.icu-project.org/trac/changeset/40603

 2017-12-03 23:08 GMT+01:00 Gábor Boskovits :

> Ok, I found this one:
> https://sourceware.org/glibc/wiki/Release/2.26#Removal_of_.2
> 7xlocale.h.27
>
> It seems, that xlocale.h should not be used as an include, and
> glibc removed that.
>
> So this is ok.
>
> The question 

Re: [bug#29528] Add blacknurse

[ng0]

Ludovic Courtès transcribed 1.4K bytes:
> Hi,
> 
> Ricardo Wurmus  skribis:
> 
> >> +  (home-page "https://github.com/jedisct1/blacknurse";)
> >> +  (synopsis "Proof of Concept for the Blacknurse attack")
> >> +  (description
> >> +   "Simple Proof of Concept for the Blacknurse attack.
> >> +Blacknurse is a low bandwidth ICMP attack that is capable of doing denial
> >> +of service to well known firewalls.")
> >
> > The first fragment is not a full sentence.
> >
> > Looking at this package I wonder why it should be part of Guix as it is
> > merely malware.  I don’t see any reason why this should be installable
> > through Guix.  We are not in the habit of providing packages for
> > exploits.  Putting it in “networking” makes it seem like this would be a
> > useful networking application, but it really is not.  It just
> > demonstrates a bug in networked devices.
> >
> > @Ludo: what do you think?
> 
> Indeed.  I see two issues here:
> 
>   1. a “proof of concept” is typically something for experts of the
>  field to study, rather than generally useful software;

Hm... We have some proof of work implementations of software in Guix
I think. In addition I'd think that there are many more professionals
only software. So PoC as an issues is a non-issue to me as long as it
works.

>   2. it’s a tool whose purpose is to perform DoS attacks on routers, and
>  I find it questionable to provide it in Guix (not to mention that
>  there’s no shortage of such programs that we could add!).

And this is the real issue. I fully agree with the statements and
views on this software made by Ricardo and yourself.
I'm taking most of these software from BlackArch, Kali and
other distro-builder distros targeted at pen-testing professionals
in addition to the commercial solutions.
Some of these don't even have license statements, I had chats with
BlackArch to correct a large batch of their own script'ish software.

> So overall I’m reluctant to including it in Guix.
> 
> Thoughts?
> 
> Ludo’.

I haven't read the Documentation in a while, but do we define anything
besides the requirement that a software needs to fit into the GNU FSDG?
I mean more specifically, do we want to come up with a definition for
software (such as this) that won't be included at all, or do we decide
individually per case?
I myself now know what we have agreed upon here, I just don't know if
it would make more sense to define it in the Handbook.
There's a whole lot of software similar to this out there.
For example:
I have a collection of isolated viruses somewhere that is intended for
study only. Of course I know this is definitely not something we should
distribute in master, but there are certain cases where people wouldn't
know wether this is okay to distribute from the official side or not.

In addition to my main projects I'm lowkey working on some kind of
pen-testing repository, so that it can serve as a base for a flavor
of my mechanism for custom distro building automation. Based on the
general mechanism of creating official flavors I could test the ability
to extend on this with for example the theme of pen-testing.
Some of the software can find it way into Guix (some already has),
a large amount of it won't (for obvious reasons).

I'm CC'ing devel and closing this bug, so that we can discuss - if
necessary - the problem of pointing out software like this in and their
restriction in the Handbook.

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


signature.asc
Description: PGP signature

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

[Gábor Boskovits]

New branch name is: change-default-icedtea-8-wip

I left the original intact, but that does not have the needed fixes.

Guix refresh shows the following on current core updates:
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-osgi-service-jdbc@1.0.0
java-plexus-interpolation@1.23 java-commons-cli@1.2 f-seq@1.1-1.6ccded3
java-commons-net@3.6 java-commons-lang@2.6 tuxguitar@1.4 antlr3@3.5.2
java-commons-daemon@1.0.15 java-jdom@1.1.3 java-commons-beanutils@1.9.3
java-httpcomponents-httpcore-ab@4.4.6 java-httpcomponents-httpcore-nio@4.4.6
java-commons-collections4@4.1 java-jgit@4.7.0.201704051617-r java-jmh@1.17.5
java-javax-mail@1.5.6 clojure@1.8.0 java-osgi-service-resolver@1.0.1
java-osgi-service-packageadmin@1.2.0 java-osgi-util-tracker@1.5.1
java-osgi-service-cm@1.5.0 java-httpcomponents-httpmime@4.5.3
java-eclipse-team-core@3.8.0 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 icedtea-web@1.6.2 java-guice-servlet@4.1
java-eclipse-jetty-servlet@9.2.22 java-eclipse-jetty-servlet@9.4.6
axoloti-patcher@1.0.12


2017-12-04 16:44 GMT+01:00 Gábor Boskovits :

> Now that this problem around glibc is resolved, I think I will do some
> history rewrite, so that these reverts, reverting the revert does not
> show up.
> I 'm also willing to rename the branch to have wip in the name, as this
> seems to be standard for longer runnig parts. WDYT?
>
> 2017-12-04 15:19 GMT+01:00 Gábor Boskovits :
>
>> Ok, so it seems, that the latest glibc update was made to fix the icu4c
>> thing.
>> It just broke the locales.
>> Fix for that has just been pushed, making core-updates usable again.
>> I pushed to my icedtea branch also.
>> I'm now building it to see what we have now.
>>
>> 2017-12-04 13:59 GMT+01:00 Gábor Boskovits :
>>
>>> Upstream corrected the issue in commit 6913ad65e00bb32417ad39c41d292b
>>> 976171e27e.
>>>
>>> It is not yet included in 2.26.
>>>
>>> The patch is basically the same as I proposed.
>>>
>>> I think we should get the upstream version.
>>>
>>> 2017-12-04 13:33 GMT+01:00 Gábor Boskovits :
>>>
 I think it should look like this:

 --- cdefs.h 2017-12-04 13:27:55.64000 +0100
 +++ cdefs.new.h 2017-12-04 13:31:53.82000 +0100
 @@ -1,4 +1,4 @@
 -/* Copyright (C) 1992-2017 Free Software Foundation, Inc.
 +y/* Copyright (C) 1992-2017 Free Software Foundation, Inc.
 This file is part of the GNU C Library.

 The GNU C Library is free software; you can redistribute it and/or
 @@ -471,10 +471,10 @@
 testing __STDC_VERSION__ for generic selection support.
 On the other hand, Clang also defines __GNUC__, so a clang-specific
 check is required to enable the use of generic selection.  */
 -#if __GNUC_PREREQ (4, 9) \
 +#if !defined __cplusplus && (__GNUC_PREREQ (4, 9)   \
  || __glibc_clang_has_extension (c_generic_selections) \
  || (!defined __GNUC__ && defined __STDC_VERSION__ \
 - && __STDC_VERSION__ >= 201112L)
 + && __STDC_VERSION__ >= 201112L))
  # define __HAVE_GENERIC_SELECTION 1
  #else
  # define __HAVE_GENERIC_SELECTION 0


 2017-12-04 13:21 GMT+01:00 Gábor Boskovits :

> We also have this in bits/floatn.h, but this seems right.
>
> #if (defined __x86_64__
>  \
>  ? __GNUC_PREREQ (4, 3)
>  \
>  : (defined __GNU__ ? __GNUC_PREREQ (4, 5) : __GNUC_PREREQ (4, 4)))
> # define __HAVE_FLOAT128 1
> #else
> # define __HAVE_FLOAT128 0
> #endif
>
> /* Defined to 1 if __HAVE_FLOAT128 is 1 and the type is ABI-distinct
>
>
>from the default float, double and long double types in this
> glibc.  */
> #if __HAVE_FLOAT128
> # define __HAVE_DISTINCT_FLOAT128 1
> #else
> # define __HAVE_DISTINCT_FLOAT128 0
> #endif
>
> I think the problem is caused by HAVE_GENERIC_SELECTION defined when
> we are in C++.
>
>
> 2017-12-04 13:18 GMT+01:00 Gábor Boskovits :
>
>> We have this in cdefs.h:
>> #if __GNUC_PREREQ (4, 9) \
>> || __glibc_clang_has_extension (c_generic_selections) \
>> || (!defined __GNUC__ && defined __STDC_VERSION__ \
>> && __STDC_VERSION__ >= 201112L)
>> # define __HAVE_GENERIC_SELECTION 1
>> #else
>> # define __HAVE_GENERIC_SELECTION 0
>> #endif
>>
>> This does not seem right.
>>
>> We should not have this defined when compiling c++.
>> WDYT?
>>
>> 2017-12-04 13:03 GMT+01:00 Gábor Boskovits :
>>
>>> This minimal file reproduces the problem in icu4c 60.1 in guix
>>> environment icu4c on current core-updates.
>>>
>>> #include 
>>>
>>> int main(int argc, char **argv)
>>> {
>>>   

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

[Gábor Boskovits]

now I'm trying to build sra-tools.

2017-12-04 17:34 GMT+01:00 Gábor Boskovits :

> New branch name is: change-default-icedtea-8-wip
> 
> I left the original intact, but that does not have the needed fixes.
>
> Guix refresh shows the following on current core updates:
> 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-osgi-service-jdbc@1.0.0
> java-plexus-interpolation@1.23 java-commons-cli@1.2 f-seq@1.1-1.6ccded3
> java-commons-net@3.6 java-commons-lang@2.6 tuxguitar@1.4 antlr3@3.5.2
> java-commons-daemon@1.0.15 java-jdom@1.1.3 java-commons-beanutils@1.9.3
> java-httpcomponents-httpcore-ab@4.4.6 java-httpcomponents-httpcore-
> nio@4.4.6 java-commons-collections4@4.1 java-jgit@4.7.0.201704051617-r
> java-jmh@1.17.5 java-javax-mail@1.5.6 clojure@1.8.0
> java-osgi-service-resolver@1.0.1 java-osgi-service-packageadmin@1.2.0
> java-osgi-util-tracker@1.5.1 java-osgi-service-cm@1.5.0
> java-httpcomponents-httpmime@4.5.3 java-eclipse-team-core@3.8.0
> 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 icedtea-web@1.6.2
> java-guice-servlet@4.1 java-eclipse-jetty-servlet@9.2.22
> java-eclipse-jetty-servlet@9.4.6 axoloti-patcher@1.0.12
>
>
> 2017-12-04 16:44 GMT+01:00 Gábor Boskovits :
>
>> Now that this problem around glibc is resolved, I think I will do some
>> history rewrite, so that these reverts, reverting the revert does not
>> show up.
>> I 'm also willing to rename the branch to have wip in the name, as this
>> seems to be standard for longer runnig parts. WDYT?
>>
>> 2017-12-04 15:19 GMT+01:00 Gábor Boskovits :
>>
>>> Ok, so it seems, that the latest glibc update was made to fix the icu4c
>>> thing.
>>> It just broke the locales.
>>> Fix for that has just been pushed, making core-updates usable again.
>>> I pushed to my icedtea branch also.
>>> I'm now building it to see what we have now.
>>>
>>> 2017-12-04 13:59 GMT+01:00 Gábor Boskovits :
>>>
 Upstream corrected the issue in commit 6913ad65e00bb32417ad39c41d292b
 976171e27e.

 It is not yet included in 2.26.

 The patch is basically the same as I proposed.

 I think we should get the upstream version.

 2017-12-04 13:33 GMT+01:00 Gábor Boskovits :

> I think it should look like this:
>
> --- cdefs.h 2017-12-04 13:27:55.64000 +0100
> +++ cdefs.new.h 2017-12-04 13:31:53.82000 +0100
> @@ -1,4 +1,4 @@
> -/* Copyright (C) 1992-2017 Free Software Foundation, Inc.
> +y/* Copyright (C) 1992-2017 Free Software Foundation, Inc.
> This file is part of the GNU C Library.
>
> The GNU C Library is free software; you can redistribute it and/or
> @@ -471,10 +471,10 @@
> testing __STDC_VERSION__ for generic selection support.
> On the other hand, Clang also defines __GNUC__, so a clang-specific
> check is required to enable the use of generic selection.  */
> -#if __GNUC_PREREQ (4, 9) \
> +#if !defined __cplusplus && (__GNUC_PREREQ (4, 9)   \
>  || __glibc_clang_has_extension (c_generic_selections) \
>  || (!defined __GNUC__ && defined __STDC_VERSION__ \
> - && __STDC_VERSION__ >= 201112L)
> + && __STDC_VERSION__ >= 201112L))
>  # define __HAVE_GENERIC_SELECTION 1
>  #else
>  # define __HAVE_GENERIC_SELECTION 0
>
>
> 2017-12-04 13:21 GMT+01:00 Gábor Boskovits :
>
>> We also have this in bits/floatn.h, but this seems right.
>>
>> #if (defined __x86_64__
>>\
>>  ? __GNUC_PREREQ (4, 3)
>>\
>>  : (defined __GNU__ ? __GNUC_PREREQ (4, 5) : __GNUC_PREREQ (4,
>> 4)))
>> # define __HAVE_FLOAT128 1
>> #else
>> # define __HAVE_FLOAT128 0
>> #endif
>>
>> /* Defined to 1 if __HAVE_FLOAT128 is 1 and the type is ABI-distinct
>>
>>
>>from the default float, double and long double types in this
>> glibc.  */
>> #if __HAVE_FLOAT128
>> # define __HAVE_DISTINCT_FLOAT128 1
>> #else
>> # define __HAVE_DISTINCT_FLOAT128 0
>> #endif
>>
>> I think the problem is caused by HAVE_GENERIC_SELECTION defined when
>> we are in C++.
>>
>>
>> 2017-12-04 13:18 GMT+01:00 Gábor Boskovits :
>>
>>> We have this in cdefs.h:
>>> #if __GNUC_PREREQ (4, 9) \
>>> || __glibc_clang_has_extension (c_generic_selections) \
>>> || (!defined __GNUC__ && defined __STDC_VERSION__ \
>>> && __STDC_VERSION__ >= 201112L)
>>> # define __HAVE_GENERIC_SELECTION 1
>>> #else
>>> # define __HAVE_GENERIC_SELECTION 0
>>> #endif
>>>
>>> This does not seem right.
>>>
>>> We should not have this defined when compiling c++.
>>> WDYT?
>>>
>>> 2017-12-04 13:03 GMT+01:00 G

Re: A few thing we might consider hosting

[Leo Famulari]

On Sun, Dec 03, 2017 at 08:21:35AM +0100, Gábor Boskovits wrote:
> I was aware of the discussion thread, however I could not find out what the
> current state is? Do we plan to modify this behaviour in the next release?

I think the current state is "awaiting feedback" :)

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

[Leo Famulari]

On Mon, Dec 04, 2017 at 04:44:00PM +0100, Gábor Boskovits wrote:
> Now that this problem around glibc is resolved, I think I will do some
> history rewrite, so that these reverts, reverting the revert does not
> show up.
> I 'm also willing to rename the branch to have wip in the name, as this
> seems to be standard for longer runnig parts. WDYT?

In general, we don't rewrite history of any public branches on our
Savannah instance, except for branches whose name starts with "wip-".
That, is "work in progress".

But of course we can all follow our own rules on our own Git servers :)


signature.asc
Description: PGP signature

Rust bootstraps via i686?

[Adam Van Ymeren]

Does anyone know why rust bootstraps itself from the i686 version of the
binaries even if you're running on x86_64?

This results in having to download a build a lot of packages to build
rust on x86_64.

If I can make it bootstrap though the current system in use would that
be a useful patch or is there some problem with bootstraping from x86_64
that I'm unaware of?

Thanks!
-Adam

Re: ISO image available for testing!

[Christopher Baines]

Ludovic Courtès writes:

> Hello there!
>
> I’ve uploaded a GuixSD installation ISO image for testing:
>
>   
> http://web.fdn.fr/~lcourtes/software/guix/guixsd-install-0.13.0.8d7f1d736.x86_64-linux.iso.xz
>   SHA256: 7e04017494c419bb6ca654cff05dc7e5ba4fdfd3c2812fba9ba6d929b319e93b
>
>   
> http://web.fdn.fr/~lcourtes/software/guix/guixsd-install-0.13.0.8d7f1d736.x86_64-linux.iso.xz.sig
>
> It was built with “guix system disk-image -t iso9660
> gnu/system/install.scm” on commit 8d7f1d736.
>
> Note that it’s 1.1G uncompressed so it won’t fit on a CD.
>
> Feedback welcome!

Hey,

I've attempted to use this to install GuixSD on a Bytemark
VM. Unfortunately I haven't succeeded yet. I managed to get as far as
running guix system init, but when I did, it started downloading the
bootstrap binaries, and then building binutils.

When I run guix system build, or guix build with the --dry-run options,
it says that it will download, rather than building, but it doesn't.

I also made a few other notes during the installation process:

 - The documentation mentions ipconfig to get the wired interface up,
   but it isn't available in the image. I had to run ip link set eth0
   up.
 - The documentation says that the ssh server needs to be started, but
   it was running without me starting it.

Any tips on debugging the building from source issue?

Thanks,

Chris


signature.asc
Description: PGP signature

Re: ISO image available for testing!

[Ludovic Courtès]

Hello,

Christopher Baines  skribis:

> I've attempted to use this to install GuixSD on a Bytemark
> VM. Unfortunately I haven't succeeded yet. I managed to get as far as
> running guix system init, but when I did, it started downloading the
> bootstrap binaries, and then building binutils.
>
> When I run guix system build, or guix build with the --dry-run options,
> it says that it will download, rather than building, but it doesn't.

I’m pretty sure the building-from-source comes from grafts where the
package replacements, for some reason, are not getting built by Hydra.
I thought this had been fixed by
b574cee361bdabf21f5506252b6a183dcfcd028d, but clearly it hasn’t.

I’ll investigate tomorrow.

> I also made a few other notes during the installation process:
>
>  - The documentation mentions ipconfig to get the wired interface up,
>but it isn't available in the image. I had to run ip link set eth0
>up.

It mentions “ifconfig” (with an “f”) and that one is present.  Or am I
missing something?

>  - The documentation says that the ssh server needs to be started, but
>it was running without me starting it.

Indeed.  I’ve pushed a fix as aab322d909c0b4abec132ef7aff31c31a1208841
in the new ‘version-0.14.0’ branch (note that it changes the ABI of (gnu
services ssh)).

Thanks,
Ludo’.

[PATCH] Include Krita

[Mark Meyer]

Hi,
please find attached a patch to include Krita in Guix.

Please CC me, as I'm not a list member.

Cheers, Mark

-- 
  Mark Meyer
  m...@ofosos.org
From 319fd4fb9d2b11d09a6122476b779f625c5fa8ea Mon Sep 17 00:00:00 2001
From: Mark Meyer 
Date: Tue, 5 Dec 2017 00:52:42 +0100
Subject: [PATCH] * gnu/packages/kde.scm (krita): Add new variable.

---
 gnu/packages/kde.scm | 88 +++-
 1 file changed, 87 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/kde.scm b/gnu/packages/kde.scm
index 59271ebee..79edd5c81 100644
--- a/gnu/packages/kde.scm
+++ b/gnu/packages/kde.scm
@@ -1,6 +1,7 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2016, 2017 Efraim Flashner 
 ;;; Copyright © 2016, 2017 Thomas Danckaert 
+;;; Copyright © 2017 Mark Meyer 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -23,18 +24,29 @@
   #:use-module ((guix licenses) #:prefix license:)
   #:use-module (guix packages)
   #:use-module (guix utils)
+  #:use-module (gnu packages algebra)
   #:use-module (gnu packages apr)
   #:use-module (gnu packages boost)
   #:use-module (gnu packages compression)
+  #:use-module (gnu packages curl)
   #:use-module (gnu packages documentation)
+  #:use-module (gnu packages gettext)
+  #:use-module (gnu packages ghostscript)
   #:use-module (gnu packages gl)
   #:use-module (gnu packages gnome)
+  #:use-module (gnu packages graphics)
+  #:use-module (gnu packages image)
   #:use-module (gnu packages kde-frameworks)
   #:use-module (gnu packages llvm)
+  #:use-module (gnu packages maths)
+  #:use-module (gnu packages pdf)
+  #:use-module (gnu packages perl)
+  #:use-module (gnu packages photo)
   #:use-module (gnu packages pkg-config)
   #:use-module (gnu packages tls)
   #:use-module (gnu packages qt)
-  #:use-module (gnu packages version-control))
+  #:use-module (gnu packages version-control)
+  #:use-module (gnu packages xorg))
 
 (define-public kdevelop
   (package
@@ -220,6 +232,80 @@ for some KDevelop language plugins (Ruby, PHP, CSS...).")
 plugins, as well as code to create plugins, or complete applications.")
 (license license:gpl3+)))
 
+(define-public krita
+  (package
+(name "krita")
+(version "3.3.2.1")
+(source (origin
+  (method url-fetch)
+  (uri (string-append
+"mirror://kde/stable/krita/"
+"3.3.2/" name "-" version ".tar.xz"))
+  (sha256
+   (base32
+"0i3l27cfi1h486m74xf4ynk0pwx32xaqraa91a0g1bpj1jxf2mg5"
+(build-system cmake-build-system)
+(arguments
+ `(#:configure-flags
+   (list (string-append "-DWITH_FFTW3="
+(assoc-ref %build-inputs "fftw"))
+ (string-append "-DWITH_GSL="
+(assoc-ref %build-inputs "gsl"))
+ (string-append "-DWITH_LibRaw="
+(assoc-ref %build-inputs "libraw"))
+ (string-append "-DWITH_JPEG="
+(assoc-ref %build-inputs "openjpeg"))
+ (string-append "-DWITH_Poppler="
+(assoc-ref %build-inputs "poppler"))
+ (string-append "-DWITH_TIFF="
+(assoc-ref %build-inputs "libtiff")
+(native-inputs
+ `(("extra-cmake-modules" ,extra-cmake-modules)))
+(inputs
+ `(("qtbase" ,qtbase)
+   ("qtdeclarative" ,qtdeclarative)
+   ("qtmultimedia" ,qtmultimedia)
+   ("qtx11extras" ,qtx11extras)
+   ("qtsvg" ,qtsvg)
+   ("qwt" ,qwt)
+   ("karchive" ,karchive)
+   ("kcompletion" ,kcompletion)
+   ("kconfig" ,kconfig)
+   ("kcoreaddons" ,kcoreaddons)
+   ("kcrash" ,kcrash)
+   ("kguiaddons" ,kguiaddons)
+   ("ki18n" ,ki18n)
+   ("kiconthemes" ,kiconthemes)
+   ("kio" ,kio)
+   ("kitemmodels" ,kitemmodels)
+   ("kitemviews" ,kitemviews)
+   ("kwidgetsaddons" ,kwidgetsaddons)
+   ("kwindowsystem" ,kwindowsystem)
+   ("kxmlgui" ,kxmlgui)
+   ("boost" ,boost)
+   ("exiv2" ,exiv2)
+   ("lcms" ,lcms)
+   ("libpng" ,libpng)
+   ("curl" ,curl)
+   ("zlib" ,zlib)
+   ("libx11" ,libx11)
+   ("libxcb" ,libxcb)
+   ("libxi" ,libxi)
+   ("fftw" ,fftw)
+   ("gsl" ,gsl)
+   ("openjpeg" ,openjpeg)
+   ("poppler" ,poppler)
+   ("libraw" ,libraw)
+   ("libtiff" ,libtiff)
+   ("eigen" ,eigen)
+   ("perl" ,perl)
+   ("gettext-minimal" ,gettext-minimal)))
+(home-page "https://krita.org";)
+(synopsis "Digital painting application")
+(description
+ "A digital image editor, primarily aimed at digital painting and animation.")
+(license license:gpl2+)))
+
 (define-public libkomparediff2
   (package
 (name "libkomparediff2")
-- 
2.15.0

Re: [PATCH] Include Krita

[Mark Meyer]

I retract this patch, it is buggy :( Be right back.

On Tue, Dec 5, 2017, at 00:55, Mark Meyer wrote:
> Hi,
> please find attached a patch to include Krita in Guix.
> 
> Please CC me, as I'm not a list member.
> 
> Cheers, Mark
> 
> -- 
>   Mark Meyer
>   m...@ofosos.org
> Email had 1 attachment:
> + 0001-gnu-packages-kde.scm-krita-Add-new-variable.patch
>   7k (text/x-patch)


-- 
  Mark Meyer
  m...@ofosos.org

Re: [PATCH] Include Krita

[Kei Kebreau]

Mark Meyer  writes:

> I retract this patch, it is buggy :( Be right back.
>
> On Tue, Dec 5, 2017, at 00:55, Mark Meyer wrote:
>> Hi,
>> please find attached a patch to include Krita in Guix.
>> 
>> Please CC me, as I'm not a list member.
>> 
>> Cheers, Mark
>> 
>> -- 
>>   Mark Meyer
>>   m...@ofosos.org
>> Email had 1 attachment:
>> + 0001-gnu-packages-kde.scm-krita-Add-new-variable.patch
>>   7k (text/x-patch)

Hi Mark!

Thank you for your work on this patch. I ask that when you finish fixing
the bugs you found in it, please send the patch to guix-patc...@gnu.org
so patch reviewers are less likely to lose track of it.

Thanks again,
Kei


signature.asc
Description: PGP signature

Re: Release!

[Maxim Cournoyer]

Hi!

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

[...] (Great fix! :)

>>>   2. “udevd[304]: RUN{builtin}: 'uaccess' unknown 
>>> /gnu/store/q7c8yayywf76ai3sgvz16pmbz07gj4bp-udev-rules/lib/udev/rules.d/73-seat-late.rules:15”
>>
>> I haven't seen this one before.
>
> I compared the source of eudev and systemd, and indeed, like Maxim
> wrote, the issue is that eudev does not support a “uaccess” built-in
> tag.  So I pushed a fix that simply comments out that line:
>
>   
> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=f8446df663fecb5aa34e5c6dfa477544d3271d1e

Nitpick: Maybe we could reference to the issue so that a maintainer can
decide to remove that alteration after the "uaccess" issue gets properly
fixed (implemented).

> There’s still room for improvement, but the console output is less messy
> now.  :-)

Thank you for it!

Maxim

[PATCH] Add Krita to guix

[Mark Meyer]

Second  try.

I disabled all tests, since these required an X11 display to be present.
It's running now. I created a new file and saved the output. Looks good.

Please find the patch attached.

Lints fine, but I didn't test if this is reproducible, since the build
is taking a very long time (even with all tests disabled).

Cheers, Mark

-- 
  Mark Meyer
  m...@ofosos.org
From ed263ddc7b084c362165688bc1d1012e3978d9b8 Mon Sep 17 00:00:00 2001
From: Mark Meyer 
Date: Tue, 5 Dec 2017 00:52:42 +0100
Subject: [PATCH] * gnu/packages/kde.scm (krita): Add new variable.

---
 gnu/packages/kde.scm | 90 +++-
 1 file changed, 89 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/kde.scm b/gnu/packages/kde.scm
index 59271ebee..af182a033 100644
--- a/gnu/packages/kde.scm
+++ b/gnu/packages/kde.scm
@@ -1,6 +1,7 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2016, 2017 Efraim Flashner 
 ;;; Copyright © 2016, 2017 Thomas Danckaert 
+;;; Copyright © 2017 Mark Meyer 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -23,18 +24,29 @@
   #:use-module ((guix licenses) #:prefix license:)
   #:use-module (guix packages)
   #:use-module (guix utils)
+  #:use-module (gnu packages algebra)
   #:use-module (gnu packages apr)
   #:use-module (gnu packages boost)
   #:use-module (gnu packages compression)
+  #:use-module (gnu packages curl)
   #:use-module (gnu packages documentation)
+  #:use-module (gnu packages gettext)
+  #:use-module (gnu packages ghostscript)
   #:use-module (gnu packages gl)
   #:use-module (gnu packages gnome)
+  #:use-module (gnu packages graphics)
+  #:use-module (gnu packages image)
   #:use-module (gnu packages kde-frameworks)
   #:use-module (gnu packages llvm)
+  #:use-module (gnu packages maths)
+  #:use-module (gnu packages pdf)
+  #:use-module (gnu packages perl)
+  #:use-module (gnu packages photo)
   #:use-module (gnu packages pkg-config)
   #:use-module (gnu packages tls)
   #:use-module (gnu packages qt)
-  #:use-module (gnu packages version-control))
+  #:use-module (gnu packages version-control)
+  #:use-module (gnu packages xorg))
 
 (define-public kdevelop
   (package
@@ -220,6 +232,82 @@ for some KDevelop language plugins (Ruby, PHP, CSS...).")
 plugins, as well as code to create plugins, or complete applications.")
 (license license:gpl3+)))
 
+(define-public krita
+  (package
+(name "krita")
+(version "3.3.2.1")
+(source (origin
+  (method url-fetch)
+  (uri (string-append
+"mirror://kde/stable/krita/"
+"3.3.2/" name "-" version ".tar.xz"))
+  (sha256
+   (base32
+"0i3l27cfi1h486m74xf4ynk0pwx32xaqraa91a0g1bpj1jxf2mg5"
+(build-system cmake-build-system)
+(arguments
+ `(#:tests? #f
+   #:configure-flags
+   (list "-DBUILD_TESTING=OFF" "-DKDE4_BUILD_TESTS=OFF"
+ (string-append "-DWITH_FFTW3="
+(assoc-ref %build-inputs "fftw"))
+ (string-append "-DWITH_GSL="
+(assoc-ref %build-inputs "gsl"))
+ (string-append "-DWITH_LibRaw="
+(assoc-ref %build-inputs "libraw"))
+ (string-append "-DWITH_JPEG="
+(assoc-ref %build-inputs "openjpeg"))
+ (string-append "-DWITH_Poppler="
+(assoc-ref %build-inputs "poppler"))
+ (string-append "-DWITH_TIFF="
+(assoc-ref %build-inputs "libtiff")
+(native-inputs
+ `(("extra-cmake-modules" ,extra-cmake-modules)))
+(inputs
+ `(("qtbase" ,qtbase)
+   ("qtdeclarative" ,qtdeclarative)
+   ("qtmultimedia" ,qtmultimedia)
+   ("qtx11extras" ,qtx11extras)
+   ("qtsvg" ,qtsvg)
+   ("qwt" ,qwt)
+   ("karchive" ,karchive)
+   ("kcompletion" ,kcompletion)
+   ("kconfig" ,kconfig)
+   ("kcoreaddons" ,kcoreaddons)
+   ("kcrash" ,kcrash)
+   ("kguiaddons" ,kguiaddons)
+   ("ki18n" ,ki18n)
+   ("kiconthemes" ,kiconthemes)
+   ("kio" ,kio)
+   ("kitemmodels" ,kitemmodels)
+   ("kitemviews" ,kitemviews)
+   ("kwidgetsaddons" ,kwidgetsaddons)
+   ("kwindowsystem" ,kwindowsystem)
+   ("kxmlgui" ,kxmlgui)
+   ("boost" ,boost)
+   ("exiv2" ,exiv2)
+   ("lcms" ,lcms)
+   ("libpng" ,libpng)
+   ("curl" ,curl)
+   ("zlib" ,zlib)
+   ("libx11" ,libx11)
+   ("libxcb" ,libxcb)
+   ("libxi" ,libxi)
+   ("fftw" ,fftw)
+   ("gsl" ,gsl)
+   ("openjpeg" ,openjpeg)
+   ("poppler" ,poppler)
+   ("libraw" ,libraw)
+   ("libtiff" ,libtiff)
+   ("eigen" ,eigen)
+   ("perl" ,perl)
+   ("gettext-minimal" ,gettext-minimal)))
+(home-page "https://krita.org";)
+(synopsis "Digital painting application")
+(description
+ "A digital image editor, primarily aimed at digital paintin

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

[Gábor Boskovits]

FAIL: abicheck.sh
PASS: pltcheck.sh

Testsuite summary for gtk+ 2.24.31

# TOTAL: 3
# PASS:  2
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

See gtk/test-suite.log
Please report to http://bugzilla.gnome.org/enter_bug.cgi?product=gtk%2B


This is what I have now.

FAIL: abicheck.sh
=

--- expected-abi2017-12-05 05:45:34.47200 +
+++ actual-abi  2017-12-05 05:45:34.50800 +
@@ -1,3 +1,4 @@
+g_cclosure_marshal_BOOLEAN__BOXED_BOXED
 gtk_about_dialog_get_artists
 gtk_about_dialog_get_authors
 gtk_about_dialog_get_comments
FAIL abicheck.sh (exit status: 1

This is the log.



2017-12-04 20:15 GMT+01:00 Leo Famulari :

> On Mon, Dec 04, 2017 at 04:44:00PM +0100, Gábor Boskovits wrote:
> > Now that this problem around glibc is resolved, I think I will do some
> > history rewrite, so that these reverts, reverting the revert does not
> > show up.
> > I 'm also willing to rename the branch to have wip in the name, as this
> > seems to be standard for longer runnig parts. WDYT?
>
> In general, we don't rewrite history of any public branches on our
> Savannah instance, except for branches whose name starts with "wip-".
> That, is "work in progress".
>
> But of course we can all follow our own rules on our own Git servers :)
>