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

[Chris Marusich]

Gábor Boskovits  writes:

> 2018-01-06 21:16 GMT+01:00 Gábor Boskovits :
>
>> It would also be nice, if you could review the patches already sent to
>> guix-patches.
>> They are tagged [PATCH core-updates].

OK, I'll find them and take a look this week.

>> Current issues:
>>
>> https://github.com/Boskovits/guix/issues/61
>> I'm will contact upstream to check if this issue is serious.
>> Will cc to you.

I got the email.  Thank you for Ccing me.  Hopefully upstream will be
able to help.

>> https://github.com/Boskovits/guix/issues/58

You mentioned this is the last build failure (besides issue 61 above).
I'll also take a look at it and see if I can figure anything out.

For now, giving feedback on your patches and taking a look at issue 58
are the best things I can do to help you, right?  I just want to double
check to make sure I understand the situation correctly.

-- 
Chris


signature.asc
Description: PGP signature

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

[Gábor Boskovits]

2018-01-07 18:25 GMT+01:00 Ricardo Wurmus :

>
> Gábor Boskovits  writes:
>
> > https://github.com/Boskovits/guix/issues/58
> …
> > What I don't understand, is why setting source and target to 1.7,
> > like I did on java-aqute-libg did not work.
>
> How did you set it?  Since this is using the package’s own build.xml
> you’d need to patch it.
>
> I tried two things:
1. set in the make-flags like this:
-Dant.build.javac.source=1.7
-Dant.build.javac.target=1.7
this did not work, but complained that the source is 1.7 and no bootstrap
classpath is set, so I guess that these properties are considered.

2. patched the build.xml:
substituted
 --
> Ricardo
>
> GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
> https://elephly.net
>
>
>

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

[Ricardo Wurmus]

Gábor Boskovits  writes:

> https://github.com/Boskovits/guix/issues/58
…
> What I don't understand, is why setting source and target to 1.7,
> like I did on java-aqute-libg did not work.

How did you set it?  Since this is using the package’s own build.xml
you’d need to patch it.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

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

[Gábor Boskovits]

2018-01-06 21:16 GMT+01:00 Gábor Boskovits :

> Actually we still have a couple of build failures, some test failures, and
> the
> commit messages are not conformant to the policy. Currently making the few
> remainig
> failures work should be the primary task. I will check the details.
> I already have an integration branch where I reorder commits and make
> commit messages conform.
> It would also be nice, if you could review the patches already sent to
> guix-patches.
> They are tagged [PATCH core-updates]. I guess we are waiting for the next
> core-updates cycle, until then
> these will not be pushed.
>
> These are the backwards compatible changes collected so far.
> Soon I will add the fix for the antlr3 bootstrap toolchain.
>
> Current issues:
>
> https://github.com/Boskovits/guix/issues/61
> I'm will contact upstream to check if this issue is serious.
> Will cc to you.
>
> https://github.com/Boskovits/guix/issues/58
> I will have a look at this once more.
> I've already solved two similar issues, I guess I can cope with this.
>
> I could not find an good solution to this one. I could make it only with
setting jdk and ant back to java7, and disabling tests.
I've tried several things, but it seems that a java7
bootstrap classpatch is required anyways.

I would recommend for now setting this as java7 build, and remove this
package when beanutils goes to 2.0.0. They've just started this iteration
according to jira, and the first things will be upgrading to collections4.

If you have any idea on how to solve this, please comment.
There are several distro patches, we might adapt one of them, but
this can't be solved in a backwards compatible way.

What I don't understand, is why setting source and target to 1.7,
like I did on java-aqute-libg did not work.


> https://github.com/Boskovits/guix/issues/57
> I'm not sure about this one.
> I can try to check upstream if this is a problem on their site, but it
> seems not.
> It seems that some zeromq calls fail.
> Can this be related to our build container?
>

Fixed this by updating. it turned out to be an upstream bug.

>
> https://github.com/Boskovits/guix/issues/56
> I haven't looked into this one yet.
>
> https://github.com/Boskovits/guix/issues/55
> I intend to remove this package if
> axoloti-patcher works with the current version.
> I did not do this yet, because the
> java-simple-xml issue also blocks axoloti-patcher,
> so I could not check yet if the current version is ok.
>
> The remaining five issues are the packages from
> the covering of icedtea7 that do not build.
> The rest does build.
>
>
java-plexus-default-container now builds.


> I don't know if we have any more issues between the
> marked problems and these five packages.
>
>
>> --
>> Chris
>>
>
>

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

[Ricardo Wurmus]

Gábor Boskovits  writes:

> If I understand well, then the check phase in ant-build-system
> runs without make-flags.
> In the definition of java-asm we configure the build with make-flags, so
> the build system
> does not complain about missing configuration.
> This configuration is still needed for the test target, so building that
> fails.
>
> We could do two things:
> 1. Patch build.xml to not perform these checks. (Then we can also remove
> the make-flags all togethet)
> 2. Do something, so that we can pass make-flags to check phase, maybe by
> introducing test-make-flags, or something like that to
> ant-build-system.

You could also replace the check phase to run ant with the make-flags.

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

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

[Gábor Boskovits]

Actually we still have a couple of build failures, some test failures, and
the
commit messages are not conformant to the policy. Currently making the few
remainig
failures work should be the primary task. I will check the details.
I already have an integration branch where I reorder commits and make
commit messages conform.
It would also be nice, if you could review the patches already sent to
guix-patches.
They are tagged [PATCH core-updates]. I guess we are waiting for the next
core-updates cycle, until then
these will not be pushed.

These are the backwards compatible changes collected so far.
Soon I will add the fix for the antlr3 bootstrap toolchain.

Current issues:

https://github.com/Boskovits/guix/issues/61
I'm will contact upstream to check if this issue is serious.
Will cc to you.

https://github.com/Boskovits/guix/issues/58
I will have a look at this once more.
I've already solved two similar issues, I guess I can cope with this.

https://github.com/Boskovits/guix/issues/57
I'm not sure about this one.
I can try to check upstream if this is a problem on their site, but it
seems not.
It seems that some zeromq calls fail.
Can this be related to our build container?

https://github.com/Boskovits/guix/issues/56
I haven't looked into this one yet.

https://github.com/Boskovits/guix/issues/55
I intend to remove this package if
axoloti-patcher works with the current version.
I did not do this yet, because the
java-simple-xml issue also blocks axoloti-patcher,
so I could not check yet if the current version is ok.

The remaining five issues are the packages from
the covering of icedtea7 that do not build.
The rest does build.

I don't know if we have any more issues between the
marked problems and these five packages.


> --
> Chris
>

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

[Chris Marusich]

Gábor Boskovits  writes:

> 2018-01-05 16:44 GMT+01:00 Ricardo Wurmus :
>
>>
>> Gábor Boskovits  writes:
>>
>> > If I understand well, then the check phase in ant-build-system
>> > runs without make-flags.
>> > In the definition of java-asm we configure the build with make-flags, so
>> > the build system
>> > does not complain about missing configuration.
>> > This configuration is still needed for the test target, so building that
>> > fails.
>> >
>> > We could do two things:
>> > 1. Patch build.xml to not perform these checks. (Then we can also remove
>> > the make-flags all togethet)
>> > 2. Do something, so that we can pass make-flags to check phase, maybe by
>> > introducing test-make-flags, or something like that to
>> > ant-build-system.
>>
>> You could also replace the check phase to run ant with the make-flags.
>>
>> Fine, will do that then. It seems the cleanest solution...
> Thanks

Hi Gábor,

The last couple weeks, I've been very busy.  Now, I have a little more
time.  Is there anything I can do to help finish this up?

Thank you,

-- 
Chris


signature.asc
Description: PGP signature

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

[Gábor Boskovits]

2018-01-05 16:44 GMT+01:00 Ricardo Wurmus :

>
> Gábor Boskovits  writes:
>
> > If I understand well, then the check phase in ant-build-system
> > runs without make-flags.
> > In the definition of java-asm we configure the build with make-flags, so
> > the build system
> > does not complain about missing configuration.
> > This configuration is still needed for the test target, so building that
> > fails.
> >
> > We could do two things:
> > 1. Patch build.xml to not perform these checks. (Then we can also remove
> > the make-flags all togethet)
> > 2. Do something, so that we can pass make-flags to check phase, maybe by
> > introducing test-make-flags, or something like that to
> > ant-build-system.
>
> You could also replace the check phase to run ant with the make-flags.
>
> Fine, will do that then. It seems the cleanest solution...
Thanks


> --
> Ricardo
>
> GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
> https://elephly.net
>
>
>

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

[Gábor Boskovits]

2017-12-21 8:53 GMT+01:00 Gábor Boskovits :

> 2017-12-20 13:29 GMT+01:00 Gábor Boskovits :
>
>> 2017-12-20 11:34 GMT+01:00 Gábor Boskovits :
>>
>>> 2017-12-19 23:11 GMT+01:00 Ricardo Wurmus :
>>>

 Gábor Boskovits  writes:

 > Now I have another blocking issue:
 > https://github.com/Boskovits/guix/issues/24

 > Error message:
 >
 > BUILD FAILED
 > /tmp/guix-build-java-bsh-2.0b6.drv-0/beanshell-2.0b6/build.xml:654:
 > Problem: failed to create task or type junit
 > Cause: the class org.apache.tools.ant.taskdefs.optional.junit.JUnitTask
 was
 > not found.

 Is it not just enough to add junit to the inputs of java-bsh?

 No, unfortunately it seems to affect all packages using junit.
>>> I guess it is because I use ant/java8, and maybe that is more fussy
>>> about this...
>>>
>>> It seems, that we should add the lib flag to the nat commend line, if we
>> have
>> junit as input. However junit has quite a big dependency graph with the
>> new
>> hamcrest-core fix, but that is needed for junit. I think we should
>> discuss our options here,
>> I don't feel comfortable to make such a decision without prior discussion.
>>
>> Regarding this issue, in my opinion we cloud do the following:
> Add two parameters to ant build system:
> junit?
> junit
> If junit? then force use of junit, if not, then force not to use it, if
> unspecified check if we have junit in build.inputs, and use it if it is.
> junit should default to java-junit, like we have for icedtea, and ant.
> Can something like this be done?
> It would be nice if the ant-build-system needed junit only if it is in
> build-inputs, or explicitly requested, so
> that we can still use it while we don't have junit.
> WDYT?
>

Ok, i've settled the issue with junit, it boils down to the following
things:

1. We need to add ant-junit as a native-input to the packages using junit.
2. We need to add ant-junit4.jar to ant-junit, so that junit4 can find the
tests.

Now I have the following problem, it is in java-asm:

If I understand well, then the check phase in ant-build-system
runs without make-flags.
In the definition of java-asm we configure the build with make-flags, so
the build system
does not complain about missing configuration.
This configuration is still needed for the test target, so building that
fails.

We could do two things:
1. Patch build.xml to not perform these checks. (Then we can also remove
the make-flags all togethet)
2. Do something, so that we can pass make-flags to check phase, maybe by
introducing test-make-flags, or something like that to ant-build-system.

For now I will just disable test, so that I can go on, but I would be glad
if you could recommend me an approch on this,
I this that #2 worth it only, if it affects multiple packages. I will have
a look at that.


>
>
>> In the meanwhile I will create an integration branch, and start to create
>> a list of patches that
>> can be merged to core-updates.
>>
>> Where should I send those?
>>
>>
>>>
>>>
 --
 Ricardo

 GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
 https://elephly.net



>>>
>>
>

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

[Gábor Boskovits]

2017-12-20 13:29 GMT+01:00 Gábor Boskovits :

> 2017-12-20 11:34 GMT+01:00 Gábor Boskovits :
>
>> 2017-12-19 23:11 GMT+01:00 Ricardo Wurmus :
>>
>>>
>>> Gábor Boskovits  writes:
>>>
>>> > Now I have another blocking issue:
>>> > https://github.com/Boskovits/guix/issues/24
>>>
>>> > Error message:
>>> >
>>> > BUILD FAILED
>>> > /tmp/guix-build-java-bsh-2.0b6.drv-0/beanshell-2.0b6/build.xml:654:
>>> > Problem: failed to create task or type junit
>>> > Cause: the class org.apache.tools.ant.taskdefs.optional.junit.JUnitTask
>>> was
>>> > not found.
>>>
>>> Is it not just enough to add junit to the inputs of java-bsh?
>>>
>>> No, unfortunately it seems to affect all packages using junit.
>> I guess it is because I use ant/java8, and maybe that is more fussy about
>> this...
>>
>> It seems, that we should add the lib flag to the nat commend line, if we
> have
> junit as input. However junit has quite a big dependency graph with the new
> hamcrest-core fix, but that is needed for junit. I think we should discuss
> our options here,
> I don't feel comfortable to make such a decision without prior discussion.
>
> Regarding this issue, in my opinion we cloud do the following:
Add two parameters to ant build system:
junit?
junit
If junit? then force use of junit, if not, then force not to use it, if
unspecified check if we have junit in build.inputs, and use it if it is.
junit should default to java-junit, like we have for icedtea, and ant.
Can something like this be done?
It would be nice if the ant-build-system needed junit only if it is in
build-inputs, or explicitly requested, so
that we can still use it while we don't have junit.
WDYT?


> In the meanwhile I will create an integration branch, and start to create
> a list of patches that
> can be merged to core-updates.
>
> Where should I send those?
>
>
>>
>>
>>> --
>>> Ricardo
>>>
>>> GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
>>> https://elephly.net
>>>
>>>
>>>
>>
>

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

[Gábor Boskovits]

2017-12-20 11:34 GMT+01:00 Gábor Boskovits :

> 2017-12-19 23:11 GMT+01:00 Ricardo Wurmus :
>
>>
>> Gábor Boskovits  writes:
>>
>> > Now I have another blocking issue:
>> > https://github.com/Boskovits/guix/issues/24
>>
>> > Error message:
>> >
>> > BUILD FAILED
>> > /tmp/guix-build-java-bsh-2.0b6.drv-0/beanshell-2.0b6/build.xml:654:
>> > Problem: failed to create task or type junit
>> > Cause: the class org.apache.tools.ant.taskdefs.optional.junit.JUnitTask
>> was
>> > not found.
>>
>> Is it not just enough to add junit to the inputs of java-bsh?
>>
>> No, unfortunately it seems to affect all packages using junit.
> I guess it is because I use ant/java8, and maybe that is more fussy about
> this...
>
> It seems, that we should add the lib flag to the nat commend line, if we
have
junit as input. However junit has quite a big dependency graph with the new
hamcrest-core fix, but that is needed for junit. I think we should discuss
our options here,
I don't feel comfortable to make such a decision without prior discussion.

In the meanwhile I will create an integration branch, and start to create a
list of patches that
can be merged to core-updates.

Where should I send those?


>
>
>> --
>> Ricardo
>>
>> GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
>> https://elephly.net
>>
>>
>>
>

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

[Gábor Boskovits]

2017-12-19 23:11 GMT+01:00 Ricardo Wurmus :

>
> Gábor Boskovits  writes:
>
> > Now I have another blocking issue:
> > https://github.com/Boskovits/guix/issues/24
>
> > Error message:
> >
> > BUILD FAILED
> > /tmp/guix-build-java-bsh-2.0b6.drv-0/beanshell-2.0b6/build.xml:654:
> > Problem: failed to create task or type junit
> > Cause: the class org.apache.tools.ant.taskdefs.optional.junit.JUnitTask
> was
> > not found.
>
> Is it not just enough to add junit to the inputs of java-bsh?
>
> No, unfortunately it seems to affect all packages using junit.
I guess it is because I use ant/java8, and maybe that is more fussy about
this...



> --
> Ricardo
>
> GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
> https://elephly.net
>
>
>

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

[Ricardo Wurmus]

Gábor Boskovits  writes:

> Now I have another blocking issue:
> https://github.com/Boskovits/guix/issues/24

> Error message:
>
> BUILD FAILED
> /tmp/guix-build-java-bsh-2.0b6.drv-0/beanshell-2.0b6/build.xml:654:
> Problem: failed to create task or type junit
> Cause: the class org.apache.tools.ant.taskdefs.optional.junit.JUnitTask was
> not found.

Is it not just enough to add junit to the inputs of java-bsh?

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

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

[Gábor Boskovits]

2017-12-19 10:11 GMT+01:00 Gábor Boskovits :

>
>
> 2017-12-19 9:07 GMT+01:00 Chris Marusich :
>
>> Hi Gábor and Ricardo,
>>
>> I see that Gábor made this GitHub issue to track their work:
>>
>> https://github.com/Boskovits/guix/issues/16
>>
>> At this point, can I help with anything in particular, or should I wait
>> until after Gábor pushes the fix(es) for java-hamcrest-core, so we can
>> build the covering of icedtea-8 after that and see what still breaks?
>>
>>
> I'm quite near to get a fix for java-hamcrest-core. Only java-jarjar has
> to be modified now, so I think you can wait until I get this done.
>

I have now pushed the fix for java-hamcrest-core to my branch.
Now I have another blocking issue:
https://github.com/Boskovits/guix/issues/24

Error message:

BUILD FAILED
/tmp/guix-build-java-bsh-2.0b6.drv-0/beanshell-2.0b6/build.xml:654:
Problem: failed to create task or type junit
Cause: the class org.apache.tools.ant.taskdefs.optional.junit.JUnitTask was
not found.
This looks like one of Ant's optional components.
Action: Check that the appropriate optional JAR exists in
-/gnu/store/6lzf3cp16m0xgwr00lymqd3v6fgpvzxv-ant-1.10.1/lib
-/.ant/lib
-a directory added on the command line with the -lib argument

Do not panic, this is a common problem.
The commonest cause is a missing JAR.

This is not a bug; it is a configuration problem

End of error message.

It seems that this is an ant configuration issue.
Should we add junit with -lib to the ant command line?


>
>
>> Gábor Boskovits  writes:
>>
>> > I've found the problem with java-hamcrest-core.
>> > The root cause of this is that java-jarjar uses a bundled copy of asm,
>> > version 4.0.
>> > This asm version does not support icedtea8.
>> >
>> > I propose to use java-asm instead of the bundled one.
>> >
>> > In my opinion the best course of action should be:
>> > 1. create a package: java-asm-notest with tests diabled to break the
>> > dependency cycle on java-hamcrest-core
>> > 2. modify java-jarjar to use java-asm-notest instead of the bundled asm.
>> > 3. test if java-hamcrest-core now builds.
>> >
>> > It is a question if we want to iterate this cycle once more, with a
>> > tests-enabled java-asm.
>> > WDYT?
>>
>> Sounds good to me.
>>
>> Gábor Boskovits  writes:
>>
>> > It seems, that it is aslo safe to apply this on master.
>> > This is the patch:
>> >
>> > ...
>> >
>> > Subject: [PATCH] gnu: Clean up depencies of java-asm.
>>
>> This patch seems fine to me.  I briefly looked but could not find it in
>> the Guix Git repo; have you not pushed it yet?
>
> Gábor Boskovits  writes:
>>
>> > We now have an upstream fix for classpathx, it is pushed as revision
>> 1244
>> > to the savannah subversion repo.
>> > May I change the source to use this revision?
>> > Or should I use a patch?
>> >
>> > I think using the upstream revision is a better option.
>> > WDYT?
>>
>> I agree: using the upstream revision sounds like a better plan.  The
>> only reason I can think why we would not want to do that is if it is
>> going to take a long time for it to get released.
>>
>> --
>> Chris
>>
>
>

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

[Gábor Boskovits]

2017-12-19 9:07 GMT+01:00 Chris Marusich :

> Hi Gábor and Ricardo,
>
> I see that Gábor made this GitHub issue to track their work:
>
> https://github.com/Boskovits/guix/issues/16
>
> At this point, can I help with anything in particular, or should I wait
> until after Gábor pushes the fix(es) for java-hamcrest-core, so we can
> build the covering of icedtea-8 after that and see what still breaks?
>
>
I'm quite near to get a fix for java-hamcrest-core. Only java-jarjar has to
be modified now, so I think you can wait until I get this done.


> Gábor Boskovits  writes:
>
> > I've found the problem with java-hamcrest-core.
> > The root cause of this is that java-jarjar uses a bundled copy of asm,
> > version 4.0.
> > This asm version does not support icedtea8.
> >
> > I propose to use java-asm instead of the bundled one.
> >
> > In my opinion the best course of action should be:
> > 1. create a package: java-asm-notest with tests diabled to break the
> > dependency cycle on java-hamcrest-core
> > 2. modify java-jarjar to use java-asm-notest instead of the bundled asm.
> > 3. test if java-hamcrest-core now builds.
> >
> > It is a question if we want to iterate this cycle once more, with a
> > tests-enabled java-asm.
> > WDYT?
>
> Sounds good to me.
>
> Gábor Boskovits  writes:
>
> > It seems, that it is aslo safe to apply this on master.
> > This is the patch:
> >
> > ...
> >
> > Subject: [PATCH] gnu: Clean up depencies of java-asm.
>
> This patch seems fine to me.  I briefly looked but could not find it in
> the Guix Git repo; have you not pushed it yet?

Gábor Boskovits  writes:
>
> > We now have an upstream fix for classpathx, it is pushed as revision 1244
> > to the savannah subversion repo.
> > May I change the source to use this revision?
> > Or should I use a patch?
> >
> > I think using the upstream revision is a better option.
> > WDYT?
>
> I agree: using the upstream revision sounds like a better plan.  The
> only reason I can think why we would not want to do that is if it is
> going to take a long time for it to get released.
>
> --
> Chris
>

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

[Chris Marusich]

Hi Gábor and Ricardo,

I see that Gábor made this GitHub issue to track their work:

https://github.com/Boskovits/guix/issues/16

At this point, can I help with anything in particular, or should I wait
until after Gábor pushes the fix(es) for java-hamcrest-core, so we can
build the covering of icedtea-8 after that and see what still breaks?

Gábor Boskovits  writes:

> I've found the problem with java-hamcrest-core.
> The root cause of this is that java-jarjar uses a bundled copy of asm,
> version 4.0.
> This asm version does not support icedtea8.
>
> I propose to use java-asm instead of the bundled one.
>
> In my opinion the best course of action should be:
> 1. create a package: java-asm-notest with tests diabled to break the
> dependency cycle on java-hamcrest-core
> 2. modify java-jarjar to use java-asm-notest instead of the bundled asm.
> 3. test if java-hamcrest-core now builds.
>
> It is a question if we want to iterate this cycle once more, with a
> tests-enabled java-asm.
> WDYT?

Sounds good to me.

Gábor Boskovits  writes:

> It seems, that it is aslo safe to apply this on master.
> This is the patch:
>
> ...
>
> Subject: [PATCH] gnu: Clean up depencies of java-asm.

This patch seems fine to me.  I briefly looked but could not find it in
the Guix Git repo; have you not pushed it yet?

Gábor Boskovits  writes:

> We now have an upstream fix for classpathx, it is pushed as revision 1244
> to the savannah subversion repo.
> May I change the source to use this revision?
> Or should I use a patch?
>
> I think using the upstream revision is a better option.
> WDYT?

I agree: using the upstream revision sounds like a better plan.  The
only reason I can think why we would not want to do that is if it is
going to take a long time for it to get released.

-- 
Chris


signature.asc
Description: PGP signature

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

[Ricardo Wurmus]

Hi Gábor,

> We now have an upstream fix for classpathx, it is pushed as revision 1244
> to the savannah subversion repo.
> May I change the source to use this revision?

Yes, this should be fine.  Thanks!

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

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

[Gábor Boskovits]

2017-12-17 19:59 GMT+01:00 Gábor Boskovits :

> Yes, we could do that, however, I would prefer to fix these if we can.
>
>
> 2017-12-17 15:26 GMT+01:00 Ricardo Wurmus :
>
>>
>> Gábor Boskovits  writes:
>>
>> > Currently I cannot compile java-aqute-bndlib,
>> > because java-classpathx-servletapi-3.0 does not work with java8.
>> > This is a known incompatibility between java7 and java8 definition of
>> Map,
>> > affecting multiple projects.
>> > I will focus on fixing that for now, and file a bug upstream.
>>
>> If a package does not build with Java 8 this does not mean that we
>> cannot use the latest JDK to build it.  For those packages we might have
>> to patch the build.xml to ensure that the JDK considers the source to be
>> of a different version.
>>
>> javac supports the “-target” and “-source” options.  This might be
>> helpful in situations like this.
>>
>> --
>> Ricardo
>>
>> GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
>> https://elephly.net
>>
>>
>>
> We now have an upstream fix for classpathx, it is pushed as revision 1244
to the savannah subversion repo.
May I change the source to use this revision?
Or should I use a patch?

I think using the upstream revision is a better option.
WDYT?

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

[Gábor Boskovits]

Yes, we could do that, however, I would prefer to fix these if we can.


2017-12-17 15:26 GMT+01:00 Ricardo Wurmus :

>
> Gábor Boskovits  writes:
>
> > Currently I cannot compile java-aqute-bndlib,
> > because java-classpathx-servletapi-3.0 does not work with java8.
> > This is a known incompatibility between java7 and java8 definition of
> Map,
> > affecting multiple projects.
> > I will focus on fixing that for now, and file a bug upstream.
>
> If a package does not build with Java 8 this does not mean that we
> cannot use the latest JDK to build it.  For those packages we might have
> to patch the build.xml to ensure that the JDK considers the source to be
> of a different version.
>
> javac supports the “-target” and “-source” options.  This might be
> helpful in situations like this.
>
> --
> Ricardo
>
> GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
> https://elephly.net
>
>
>

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

[Ricardo Wurmus]

Gábor Boskovits  writes:

> Currently I cannot compile java-aqute-bndlib,
> because java-classpathx-servletapi-3.0 does not work with java8.
> This is a known incompatibility between java7 and java8 definition of Map,
> affecting multiple projects.
> I will focus on fixing that for now, and file a bug upstream.

If a package does not build with Java 8 this does not mean that we
cannot use the latest JDK to build it.  For those packages we might have
to patch the build.xml to ensure that the JDK considers the source to be
of a different version.

javac supports the “-target” and “-source” options.  This might be
helpful in situations like this.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

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

[Gábor Boskovits]

Yesterday I investigated upgrading java-asm to version 6.0.
It pulls in bnd as a dependency. I've not yet checked if we have a new
dependecy cycle here...
Currently I cannot compile java-aqute-bndlib,
because java-classpathx-servletapi-3.0 does not work with java8.
This is a known incompatibility between java7 and java8 definition of Map,
affecting multiple projects.
I will focus on fixing that for now, and file a bug upstream.

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

> It seems, that it is aslo safe to apply this on master.
> This is the patch:
>
> From 8a4f7bcbbbefe282c15447907a67f81c5bb60aae Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?G=C3=A1bor=20Boskovits?= 
> Date: Fri, 15 Dec 2017 15:22:03 +0100
> Subject: [PATCH] gnu: Clean up depencies of java-asm.
>
> * gnu/packages/java.scm(java-asm)[native-inputs]: Remove java-junit. (Not 
> used)
> * gnu/packages/java.scm(java-asm): Remove native-inputs: became empty.
> ---
>  gnu/packages/java.scm | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/gnu/packages/java.scm b/gnu/packages/java.scm
> index 547cc2dc1..6317d21e8 100644
> --- a/gnu/packages/java.scm
> +++ b/gnu/packages/java.scm
> @@ -2696,8 +2696,6 @@ archives (jar).")
>   "-C" "output/build/tmp" "."
>   (replace 'install
> (install-jars "dist")
> -(native-inputs
> - `(("java-junit" ,java-junit)))
>  (home-page "http://asm.ow2.org/";)
>  (synopsis "Very small and fast Java bytecode manipulation framework")
>  (description "ASM is an all purpose Java bytecode manipulation and
>
>
> 2017-12-15 15:21 GMT+01:00 Gábor Boskovits :
>
>> Ok, it seems, that java-asm does not currently uses test anyway, so I can
>> remove the junit native input.
>> Will check if it is also true on master...
>>
>> 2017-12-15 14:52 GMT+01:00 Gábor Boskovits :
>>
>>> I've found the problem with java-hamcrest-core.
>>> The root cause of this is that java-jarjar uses a bundled copy of asm,
>>> version 4.0.
>>> This asm version does not support icedtea8.
>>>
>>> I propose to use java-asm instead of the bundled one.
>>>
>>> In my opinion the best course of action should be:
>>> 1. create a package: java-asm-notest with tests diabled to break the
>>> dependency cycle on java-hamcrest-core
>>> 2. modify java-jarjar to use java-asm-notest instead of the bundled asm.
>>> 3. test if java-hamcrest-core now builds.
>>>
>>> It is a question if we want to iterate this cycle once more, with a
>>> tests-enabled java-asm.
>>> WDYT?
>>>
>>>
>>> 2017-12-13 23:50 GMT+01:00 Gábor Boskovits :
>>>
 I've built the whole covering on my wip-change-default-java8 branch.
 The covering is 42 packages.
 19 builds fine.
 19 does not build because java-hamcrest-core does not build.
 I'll have a look at this first, this is the most critical.
 This is the issue link for reference:
 https://github.com/Boskovits/guix/issues/16

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

> The patches I made:
>
> This is the trivial:
>
> From f53ad84059786e0769a21a3a90a15189bcf2d61f Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?G=C3=A1bor=20Boskovits?= 
> Date: Mon, 11 Dec 2017 21:18:37 +0100
> Subject: [PATCH] Change java toolchain defaults to use java8.
>
> * gnu/packages/java.scm(icedtea): Point to icedtea-8.
> * gnu/packages/java.scm(ant): Point to ant/java8.
> ---
>  gnu/packages/java.scm | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/gnu/packages/java.scm b/gnu/packages/java.scm
> index 6dfe554f3..547cc2dc1 100644
> --- a/gnu/packages/java.scm
> +++ b/gnu/packages/java.scm
> @@ -1691,7 +1691,7 @@ IcedTea build harness.")
>   '("jdk" "openjdk-src" "corba-drop" "jaxp-drop" 
> "jaxws-drop"
> "jdk-drop" "langtools-drop" "hotspot-drop")))
>
> -(define-public icedtea icedtea-7)
> +(define-public icedtea icedtea-8)
>
>  
>  (define-public ant/java8
> @@ -1754,7 +1754,7 @@ IcedTea build harness.")
>  (native-inputs
>   `(("jdk" ,icedtea-7 "jdk")
>
> -(define-public ant ant/java7)
> +(define-public ant ant/java8)
>
>  (define-public ant-apache-bcel
>(package
>
>
> This is what I'd like to have your opinions on, is it ok to do it this 
> way, or should I rethink it
>
> (I like this, because this way we can leave ant-build-system alone, and 
> handling of
>
> default version in java.scm became consistent):
>
> From 1629a53ac5122d229b157a33806264772f18f6bc Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?G=C3=A1bor=20Boskovits?= 
> Date: Mon, 11 Dec 2017 21:13:58 +0100
> Subject: [PATCH] gnu:add ant/java7.
>
> * gnu/packages/java.scm(ant/java7): New variable.
> * gnu/packages/java.scm(ant): Changed variable semantics to point to 
> default ant.
> ---
>  

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

[Gábor Boskovits]

It seems, that it is aslo safe to apply this on master.
This is the patch:

>From 8a4f7bcbbbefe282c15447907a67f81c5bb60aae Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?G=C3=A1bor=20Boskovits?= 
Date: Fri, 15 Dec 2017 15:22:03 +0100
Subject: [PATCH] gnu: Clean up depencies of java-asm.

* gnu/packages/java.scm(java-asm)[native-inputs]: Remove java-junit. (Not used)
* gnu/packages/java.scm(java-asm): Remove native-inputs: became empty.
---
 gnu/packages/java.scm | 2 --
 1 file changed, 2 deletions(-)

diff --git a/gnu/packages/java.scm b/gnu/packages/java.scm
index 547cc2dc1..6317d21e8 100644
--- a/gnu/packages/java.scm
+++ b/gnu/packages/java.scm
@@ -2696,8 +2696,6 @@ archives (jar).")
  "-C" "output/build/tmp" "."
  (replace 'install
(install-jars "dist")
-(native-inputs
- `(("java-junit" ,java-junit)))
 (home-page "http://asm.ow2.org/";)
 (synopsis "Very small and fast Java bytecode manipulation framework")
 (description "ASM is an all purpose Java bytecode manipulation and


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

> Ok, it seems, that java-asm does not currently uses test anyway, so I can
> remove the junit native input.
> Will check if it is also true on master...
>
> 2017-12-15 14:52 GMT+01:00 Gábor Boskovits :
>
>> I've found the problem with java-hamcrest-core.
>> The root cause of this is that java-jarjar uses a bundled copy of asm,
>> version 4.0.
>> This asm version does not support icedtea8.
>>
>> I propose to use java-asm instead of the bundled one.
>>
>> In my opinion the best course of action should be:
>> 1. create a package: java-asm-notest with tests diabled to break the
>> dependency cycle on java-hamcrest-core
>> 2. modify java-jarjar to use java-asm-notest instead of the bundled asm.
>> 3. test if java-hamcrest-core now builds.
>>
>> It is a question if we want to iterate this cycle once more, with a
>> tests-enabled java-asm.
>> WDYT?
>>
>>
>> 2017-12-13 23:50 GMT+01:00 Gábor Boskovits :
>>
>>> I've built the whole covering on my wip-change-default-java8 branch.
>>> The covering is 42 packages.
>>> 19 builds fine.
>>> 19 does not build because java-hamcrest-core does not build.
>>> I'll have a look at this first, this is the most critical.
>>> This is the issue link for reference:
>>> https://github.com/Boskovits/guix/issues/16
>>>
>>> 2017-12-13 19:04 GMT+01:00 Gábor Boskovits :
>>>
 The patches I made:

 This is the trivial:

 From f53ad84059786e0769a21a3a90a15189bcf2d61f Mon Sep 17 00:00:00 2001
 From: =?UTF-8?q?G=C3=A1bor=20Boskovits?= 
 Date: Mon, 11 Dec 2017 21:18:37 +0100
 Subject: [PATCH] Change java toolchain defaults to use java8.

 * gnu/packages/java.scm(icedtea): Point to icedtea-8.
 * gnu/packages/java.scm(ant): Point to ant/java8.
 ---
  gnu/packages/java.scm | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

 diff --git a/gnu/packages/java.scm b/gnu/packages/java.scm
 index 6dfe554f3..547cc2dc1 100644
 --- a/gnu/packages/java.scm
 +++ b/gnu/packages/java.scm
 @@ -1691,7 +1691,7 @@ IcedTea build harness.")
   '("jdk" "openjdk-src" "corba-drop" "jaxp-drop" 
 "jaxws-drop"
 "jdk-drop" "langtools-drop" "hotspot-drop")))

 -(define-public icedtea icedtea-7)
 +(define-public icedtea icedtea-8)

  
  (define-public ant/java8
 @@ -1754,7 +1754,7 @@ IcedTea build harness.")
  (native-inputs
   `(("jdk" ,icedtea-7 "jdk")

 -(define-public ant ant/java7)
 +(define-public ant ant/java8)

  (define-public ant-apache-bcel
(package


 This is what I'd like to have your opinions on, is it ok to do it this 
 way, or should I rethink it

 (I like this, because this way we can leave ant-build-system alone, and 
 handling of

 default version in java.scm became consistent):

 From 1629a53ac5122d229b157a33806264772f18f6bc Mon Sep 17 00:00:00 2001
 From: =?UTF-8?q?G=C3=A1bor=20Boskovits?= 
 Date: Mon, 11 Dec 2017 21:13:58 +0100
 Subject: [PATCH] gnu:add ant/java7.

 * gnu/packages/java.scm(ant/java7): New variable.
 * gnu/packages/java.scm(ant): Changed variable semantics to point to 
 default ant.
 ---
  gnu/packages/java.scm | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

 diff --git a/gnu/packages/java.scm b/gnu/packages/java.scm
 index 0be488dec..6dfe554f3 100644
 --- a/gnu/packages/java.scm
 +++ b/gnu/packages/java.scm
 @@ -1741,7 +1741,7 @@ IcedTea build harness.")

  ;; The 1.9.x series is the last that can be built with GCJ.  The 1.10.x 
 series
  ;; requires Java 8.
 -(define-public ant
 +(define-public ant/java7
(package (inherit ant/java8)
  (version "1.9.9")
  (source (origin
 @@ -1754,6 +1754,8 @@ IcedTea build harness.")

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

[Gábor Boskovits]

Ok, it seems, that java-asm does not currently uses test anyway, so I can
remove the junit native input.
Will check if it is also true on master...

2017-12-15 14:52 GMT+01:00 Gábor Boskovits :

> I've found the problem with java-hamcrest-core.
> The root cause of this is that java-jarjar uses a bundled copy of asm,
> version 4.0.
> This asm version does not support icedtea8.
>
> I propose to use java-asm instead of the bundled one.
>
> In my opinion the best course of action should be:
> 1. create a package: java-asm-notest with tests diabled to break the
> dependency cycle on java-hamcrest-core
> 2. modify java-jarjar to use java-asm-notest instead of the bundled asm.
> 3. test if java-hamcrest-core now builds.
>
> It is a question if we want to iterate this cycle once more, with a
> tests-enabled java-asm.
> WDYT?
>
>
> 2017-12-13 23:50 GMT+01:00 Gábor Boskovits :
>
>> I've built the whole covering on my wip-change-default-java8 branch.
>> The covering is 42 packages.
>> 19 builds fine.
>> 19 does not build because java-hamcrest-core does not build.
>> I'll have a look at this first, this is the most critical.
>> This is the issue link for reference:
>> https://github.com/Boskovits/guix/issues/16
>>
>> 2017-12-13 19:04 GMT+01:00 Gábor Boskovits :
>>
>>> The patches I made:
>>>
>>> This is the trivial:
>>>
>>> From f53ad84059786e0769a21a3a90a15189bcf2d61f Mon Sep 17 00:00:00 2001
>>> From: =?UTF-8?q?G=C3=A1bor=20Boskovits?= 
>>> Date: Mon, 11 Dec 2017 21:18:37 +0100
>>> Subject: [PATCH] Change java toolchain defaults to use java8.
>>>
>>> * gnu/packages/java.scm(icedtea): Point to icedtea-8.
>>> * gnu/packages/java.scm(ant): Point to ant/java8.
>>> ---
>>>  gnu/packages/java.scm | 4 ++--
>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/gnu/packages/java.scm b/gnu/packages/java.scm
>>> index 6dfe554f3..547cc2dc1 100644
>>> --- a/gnu/packages/java.scm
>>> +++ b/gnu/packages/java.scm
>>> @@ -1691,7 +1691,7 @@ IcedTea build harness.")
>>>   '("jdk" "openjdk-src" "corba-drop" "jaxp-drop" 
>>> "jaxws-drop"
>>> "jdk-drop" "langtools-drop" "hotspot-drop")))
>>>
>>> -(define-public icedtea icedtea-7)
>>> +(define-public icedtea icedtea-8)
>>>
>>>  
>>>  (define-public ant/java8
>>> @@ -1754,7 +1754,7 @@ IcedTea build harness.")
>>>  (native-inputs
>>>   `(("jdk" ,icedtea-7 "jdk")
>>>
>>> -(define-public ant ant/java7)
>>> +(define-public ant ant/java8)
>>>
>>>  (define-public ant-apache-bcel
>>>(package
>>>
>>>
>>> This is what I'd like to have your opinions on, is it ok to do it this way, 
>>> or should I rethink it
>>>
>>> (I like this, because this way we can leave ant-build-system alone, and 
>>> handling of
>>>
>>> default version in java.scm became consistent):
>>>
>>> From 1629a53ac5122d229b157a33806264772f18f6bc Mon Sep 17 00:00:00 2001
>>> From: =?UTF-8?q?G=C3=A1bor=20Boskovits?= 
>>> Date: Mon, 11 Dec 2017 21:13:58 +0100
>>> Subject: [PATCH] gnu:add ant/java7.
>>>
>>> * gnu/packages/java.scm(ant/java7): New variable.
>>> * gnu/packages/java.scm(ant): Changed variable semantics to point to 
>>> default ant.
>>> ---
>>>  gnu/packages/java.scm | 4 +++-
>>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/gnu/packages/java.scm b/gnu/packages/java.scm
>>> index 0be488dec..6dfe554f3 100644
>>> --- a/gnu/packages/java.scm
>>> +++ b/gnu/packages/java.scm
>>> @@ -1741,7 +1741,7 @@ IcedTea build harness.")
>>>
>>>  ;; The 1.9.x series is the last that can be built with GCJ.  The 1.10.x 
>>> series
>>>  ;; requires Java 8.
>>> -(define-public ant
>>> +(define-public ant/java7
>>>(package (inherit ant/java8)
>>>  (version "1.9.9")
>>>  (source (origin
>>> @@ -1754,6 +1754,8 @@ IcedTea build harness.")
>>>  (native-inputs
>>>   `(("jdk" ,icedtea-7 "jdk")
>>>
>>> +(define-public ant ant/java7)
>>> +
>>>  (define-public ant-apache-bcel
>>>(package
>>>  (inherit ant/java8)
>>>
>>>
>>> 2017-12-13 12:07 GMT+01:00 Gábor Boskovits :
>>>
 Hello!

 It was getting quite intractable to see what I was doing, so I started
 to fill my github issue tracker. Issues are labeled with
 change-default-java8.


 2017-12-13 11:32 GMT+01:00 Efraim Flashner :

> On Tue, Dec 12, 2017 at 06:06:52PM -0800, Chris Marusich wrote:
> > Gábor Boskovits  writes:
> >
> > > I will wait for your results for now...
> >
> 
> >
> > * kodi@18.0_alpha-7-67fd70f: failed because of "potential infinite
> >   recursion"; also it seems that it's looking for a DTD on the
> Internet
> >   when instead it should be looking to find it in the inputs.
> >
> > --8<---cut here---start->8---
> > [3684/3799] Linking default/source3/modules/libvfs_module_worm.so
> > [3685/3799] Linking default/source3/modules/libvfs
> _module_crossrename.so
> > [3686/3799] Linking default/source3/modules/libvfs_modu

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

[Gábor Boskovits]

I've found the problem with java-hamcrest-core.
The root cause of this is that java-jarjar uses a bundled copy of asm,
version 4.0.
This asm version does not support icedtea8.

I propose to use java-asm instead of the bundled one.

In my opinion the best course of action should be:
1. create a package: java-asm-notest with tests diabled to break the
dependency cycle on java-hamcrest-core
2. modify java-jarjar to use java-asm-notest instead of the bundled asm.
3. test if java-hamcrest-core now builds.

It is a question if we want to iterate this cycle once more, with a
tests-enabled java-asm.
WDYT?


2017-12-13 23:50 GMT+01:00 Gábor Boskovits :

> I've built the whole covering on my wip-change-default-java8 branch.
> The covering is 42 packages.
> 19 builds fine.
> 19 does not build because java-hamcrest-core does not build.
> I'll have a look at this first, this is the most critical.
> This is the issue link for reference:
> https://github.com/Boskovits/guix/issues/16
>
> 2017-12-13 19:04 GMT+01:00 Gábor Boskovits :
>
>> The patches I made:
>>
>> This is the trivial:
>>
>> From f53ad84059786e0769a21a3a90a15189bcf2d61f Mon Sep 17 00:00:00 2001
>> From: =?UTF-8?q?G=C3=A1bor=20Boskovits?= 
>> Date: Mon, 11 Dec 2017 21:18:37 +0100
>> Subject: [PATCH] Change java toolchain defaults to use java8.
>>
>> * gnu/packages/java.scm(icedtea): Point to icedtea-8.
>> * gnu/packages/java.scm(ant): Point to ant/java8.
>> ---
>>  gnu/packages/java.scm | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/gnu/packages/java.scm b/gnu/packages/java.scm
>> index 6dfe554f3..547cc2dc1 100644
>> --- a/gnu/packages/java.scm
>> +++ b/gnu/packages/java.scm
>> @@ -1691,7 +1691,7 @@ IcedTea build harness.")
>>   '("jdk" "openjdk-src" "corba-drop" "jaxp-drop" "jaxws-drop"
>> "jdk-drop" "langtools-drop" "hotspot-drop")))
>>
>> -(define-public icedtea icedtea-7)
>> +(define-public icedtea icedtea-8)
>>
>>  
>>  (define-public ant/java8
>> @@ -1754,7 +1754,7 @@ IcedTea build harness.")
>>  (native-inputs
>>   `(("jdk" ,icedtea-7 "jdk")
>>
>> -(define-public ant ant/java7)
>> +(define-public ant ant/java8)
>>
>>  (define-public ant-apache-bcel
>>(package
>>
>>
>> This is what I'd like to have your opinions on, is it ok to do it this way, 
>> or should I rethink it
>>
>> (I like this, because this way we can leave ant-build-system alone, and 
>> handling of
>>
>> default version in java.scm became consistent):
>>
>> From 1629a53ac5122d229b157a33806264772f18f6bc Mon Sep 17 00:00:00 2001
>> From: =?UTF-8?q?G=C3=A1bor=20Boskovits?= 
>> Date: Mon, 11 Dec 2017 21:13:58 +0100
>> Subject: [PATCH] gnu:add ant/java7.
>>
>> * gnu/packages/java.scm(ant/java7): New variable.
>> * gnu/packages/java.scm(ant): Changed variable semantics to point to default 
>> ant.
>> ---
>>  gnu/packages/java.scm | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/gnu/packages/java.scm b/gnu/packages/java.scm
>> index 0be488dec..6dfe554f3 100644
>> --- a/gnu/packages/java.scm
>> +++ b/gnu/packages/java.scm
>> @@ -1741,7 +1741,7 @@ IcedTea build harness.")
>>
>>  ;; The 1.9.x series is the last that can be built with GCJ.  The 1.10.x 
>> series
>>  ;; requires Java 8.
>> -(define-public ant
>> +(define-public ant/java7
>>(package (inherit ant/java8)
>>  (version "1.9.9")
>>  (source (origin
>> @@ -1754,6 +1754,8 @@ IcedTea build harness.")
>>  (native-inputs
>>   `(("jdk" ,icedtea-7 "jdk")
>>
>> +(define-public ant ant/java7)
>> +
>>  (define-public ant-apache-bcel
>>(package
>>  (inherit ant/java8)
>>
>>
>> 2017-12-13 12:07 GMT+01:00 Gábor Boskovits :
>>
>>> Hello!
>>>
>>> It was getting quite intractable to see what I was doing, so I started
>>> to fill my github issue tracker. Issues are labeled with
>>> change-default-java8.
>>>
>>>
>>> 2017-12-13 11:32 GMT+01:00 Efraim Flashner :
>>>
 On Tue, Dec 12, 2017 at 06:06:52PM -0800, Chris Marusich wrote:
 > Gábor Boskovits  writes:
 >
 > > I will wait for your results for now...
 >
 
 >
 > * kodi@18.0_alpha-7-67fd70f: failed because of "potential infinite
 >   recursion"; also it seems that it's looking for a DTD on the
 Internet
 >   when instead it should be looking to find it in the inputs.
 >
 > --8<---cut here---start->8---
 > [3684/3799] Linking default/source3/modules/libvfs_module_worm.so
 > [3685/3799] Linking default/source3/modules/libvfs
 _module_crossrename.so
 > [3686/3799] Linking default/source3/modules/libvfs_module_cap.so
 > [3687/3799] Linking default/source3/modules/libvfs_module_catia.so
 > [3688/3799] pidl.1: pidl/pidl -> bin/default/pidl/pidl.1
 > [3689/3799] Parse::Pidl::Dump.3: pidl/lib/Parse/Pidl/Dump.pm ->
 bin/default/pidl/Parse::Pidl::Dump.3
 > [3690/3799] Parse::Pidl::Wireshark::Conformance.3:
 pidl/lib/Parse/Pidl/Wireshark/Co

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

[Gábor Boskovits]

I've built the whole covering on my wip-change-default-java8 branch.
The covering is 42 packages.
19 builds fine.
19 does not build because java-hamcrest-core does not build.
I'll have a look at this first, this is the most critical.
This is the issue link for reference:
https://github.com/Boskovits/guix/issues/16

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

> The patches I made:
>
> This is the trivial:
>
> From f53ad84059786e0769a21a3a90a15189bcf2d61f Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?G=C3=A1bor=20Boskovits?= 
> Date: Mon, 11 Dec 2017 21:18:37 +0100
> Subject: [PATCH] Change java toolchain defaults to use java8.
>
> * gnu/packages/java.scm(icedtea): Point to icedtea-8.
> * gnu/packages/java.scm(ant): Point to ant/java8.
> ---
>  gnu/packages/java.scm | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/gnu/packages/java.scm b/gnu/packages/java.scm
> index 6dfe554f3..547cc2dc1 100644
> --- a/gnu/packages/java.scm
> +++ b/gnu/packages/java.scm
> @@ -1691,7 +1691,7 @@ IcedTea build harness.")
>   '("jdk" "openjdk-src" "corba-drop" "jaxp-drop" "jaxws-drop"
> "jdk-drop" "langtools-drop" "hotspot-drop")))
>
> -(define-public icedtea icedtea-7)
> +(define-public icedtea icedtea-8)
>
>  
>  (define-public ant/java8
> @@ -1754,7 +1754,7 @@ IcedTea build harness.")
>  (native-inputs
>   `(("jdk" ,icedtea-7 "jdk")
>
> -(define-public ant ant/java7)
> +(define-public ant ant/java8)
>
>  (define-public ant-apache-bcel
>(package
>
>
> This is what I'd like to have your opinions on, is it ok to do it this way, 
> or should I rethink it
>
> (I like this, because this way we can leave ant-build-system alone, and 
> handling of
>
> default version in java.scm became consistent):
>
> From 1629a53ac5122d229b157a33806264772f18f6bc Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?G=C3=A1bor=20Boskovits?= 
> Date: Mon, 11 Dec 2017 21:13:58 +0100
> Subject: [PATCH] gnu:add ant/java7.
>
> * gnu/packages/java.scm(ant/java7): New variable.
> * gnu/packages/java.scm(ant): Changed variable semantics to point to default 
> ant.
> ---
>  gnu/packages/java.scm | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/gnu/packages/java.scm b/gnu/packages/java.scm
> index 0be488dec..6dfe554f3 100644
> --- a/gnu/packages/java.scm
> +++ b/gnu/packages/java.scm
> @@ -1741,7 +1741,7 @@ IcedTea build harness.")
>
>  ;; The 1.9.x series is the last that can be built with GCJ.  The 1.10.x 
> series
>  ;; requires Java 8.
> -(define-public ant
> +(define-public ant/java7
>(package (inherit ant/java8)
>  (version "1.9.9")
>  (source (origin
> @@ -1754,6 +1754,8 @@ IcedTea build harness.")
>  (native-inputs
>   `(("jdk" ,icedtea-7 "jdk")
>
> +(define-public ant ant/java7)
> +
>  (define-public ant-apache-bcel
>(package
>  (inherit ant/java8)
>
>
> 2017-12-13 12:07 GMT+01:00 Gábor Boskovits :
>
>> Hello!
>>
>> It was getting quite intractable to see what I was doing, so I started to
>> fill my github issue tracker. Issues are labeled with change-default-java8.
>>
>>
>> 2017-12-13 11:32 GMT+01:00 Efraim Flashner :
>>
>>> On Tue, Dec 12, 2017 at 06:06:52PM -0800, Chris Marusich wrote:
>>> > Gábor Boskovits  writes:
>>> >
>>> > > I will wait for your results for now...
>>> >
>>> 
>>> >
>>> > * kodi@18.0_alpha-7-67fd70f: failed because of "potential infinite
>>> >   recursion"; also it seems that it's looking for a DTD on the Internet
>>> >   when instead it should be looking to find it in the inputs.
>>> >
>>> > --8<---cut here---start->8---
>>> > [3684/3799] Linking default/source3/modules/libvfs_module_worm.so
>>> > [3685/3799] Linking default/source3/modules/libvfs
>>> _module_crossrename.so
>>> > [3686/3799] Linking default/source3/modules/libvfs_module_cap.so
>>> > [3687/3799] Linking default/source3/modules/libvfs_module_catia.so
>>> > [3688/3799] pidl.1: pidl/pidl -> bin/default/pidl/pidl.1
>>> > [3689/3799] Parse::Pidl::Dump.3: pidl/lib/Parse/Pidl/Dump.pm ->
>>> bin/default/pidl/Parse::Pidl::Dump.3
>>> > [3690/3799] Parse::Pidl::Wireshark::Conformance.3:
>>> pidl/lib/Parse/Pidl/Wireshark/Conformance.pm ->
>>> bin/default/pidl/Parse::Pidl::Wireshark::Conformance.3
>>> > [3691/3799] Parse::Pidl::Util.3: pidl/lib/Parse/Pidl/Util.pm ->
>>> bin/default/pidl/Parse::Pidl::Util.3
>>> > [3692/3799] Parse::Pidl::NDR.3: pidl/lib/Parse/Pidl/NDR.pm ->
>>> bin/default/pidl/Parse::Pidl::NDR.3
>>> > [3693/3799] Parse::Pidl::Wireshark::NDR.3:
>>> pidl/lib/Parse/Pidl/Wireshark/NDR.pm -> bin/default/pidl/Parse::Pidl::
>>> Wireshark::NDR.3
>>> > [3694/3799] Generating manpages/smb.conf.5
>>> > I/O error : Attempt to load network entity
>>> http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd
>>> > default/docs-xml/manpages/smb.conf.5.xml:2: warning: failed to load
>>> external entity "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd";
>>> > D DocBook XML V4.2//EN" "http://www.oasis-

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

[Gábor Boskovits]

The patches I made:

This is the trivial:

>From f53ad84059786e0769a21a3a90a15189bcf2d61f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?G=C3=A1bor=20Boskovits?= 
Date: Mon, 11 Dec 2017 21:18:37 +0100
Subject: [PATCH] Change java toolchain defaults to use java8.

* gnu/packages/java.scm(icedtea): Point to icedtea-8.
* gnu/packages/java.scm(ant): Point to ant/java8.
---
 gnu/packages/java.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/java.scm b/gnu/packages/java.scm
index 6dfe554f3..547cc2dc1 100644
--- a/gnu/packages/java.scm
+++ b/gnu/packages/java.scm
@@ -1691,7 +1691,7 @@ IcedTea build harness.")
  '("jdk" "openjdk-src" "corba-drop" "jaxp-drop" "jaxws-drop"
"jdk-drop" "langtools-drop" "hotspot-drop")))

-(define-public icedtea icedtea-7)
+(define-public icedtea icedtea-8)

 
 (define-public ant/java8
@@ -1754,7 +1754,7 @@ IcedTea build harness.")
 (native-inputs
  `(("jdk" ,icedtea-7 "jdk")

-(define-public ant ant/java7)
+(define-public ant ant/java8)

 (define-public ant-apache-bcel
   (package


This is what I'd like to have your opinions on, is it ok to do it this
way, or should I rethink it

(I like this, because this way we can leave ant-build-system alone,
and handling of

default version in java.scm became consistent):

>From 1629a53ac5122d229b157a33806264772f18f6bc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?G=C3=A1bor=20Boskovits?= 
Date: Mon, 11 Dec 2017 21:13:58 +0100
Subject: [PATCH] gnu:add ant/java7.

* gnu/packages/java.scm(ant/java7): New variable.
* gnu/packages/java.scm(ant): Changed variable semantics to point to
default ant.
---
 gnu/packages/java.scm | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/java.scm b/gnu/packages/java.scm
index 0be488dec..6dfe554f3 100644
--- a/gnu/packages/java.scm
+++ b/gnu/packages/java.scm
@@ -1741,7 +1741,7 @@ IcedTea build harness.")

 ;; The 1.9.x series is the last that can be built with GCJ.  The 1.10.x series
 ;; requires Java 8.
-(define-public ant
+(define-public ant/java7
   (package (inherit ant/java8)
 (version "1.9.9")
 (source (origin
@@ -1754,6 +1754,8 @@ IcedTea build harness.")
 (native-inputs
  `(("jdk" ,icedtea-7 "jdk")

+(define-public ant ant/java7)
+
 (define-public ant-apache-bcel
   (package
 (inherit ant/java8)


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

> Hello!
>
> It was getting quite intractable to see what I was doing, so I started to
> fill my github issue tracker. Issues are labeled with change-default-java8.
>
>
> 2017-12-13 11:32 GMT+01:00 Efraim Flashner :
>
>> On Tue, Dec 12, 2017 at 06:06:52PM -0800, Chris Marusich wrote:
>> > Gábor Boskovits  writes:
>> >
>> > > I will wait for your results for now...
>> >
>> 
>> >
>> > * kodi@18.0_alpha-7-67fd70f: failed because of "potential infinite
>> >   recursion"; also it seems that it's looking for a DTD on the Internet
>> >   when instead it should be looking to find it in the inputs.
>> >
>> > --8<---cut here---start->8---
>> > [3684/3799] Linking default/source3/modules/libvfs_module_worm.so
>> > [3685/3799] Linking default/source3/modules/libvfs
>> _module_crossrename.so
>> > [3686/3799] Linking default/source3/modules/libvfs_module_cap.so
>> > [3687/3799] Linking default/source3/modules/libvfs_module_catia.so
>> > [3688/3799] pidl.1: pidl/pidl -> bin/default/pidl/pidl.1
>> > [3689/3799] Parse::Pidl::Dump.3: pidl/lib/Parse/Pidl/Dump.pm ->
>> bin/default/pidl/Parse::Pidl::Dump.3
>> > [3690/3799] Parse::Pidl::Wireshark::Conformance.3:
>> pidl/lib/Parse/Pidl/Wireshark/Conformance.pm ->
>> bin/default/pidl/Parse::Pidl::Wireshark::Conformance.3
>> > [3691/3799] Parse::Pidl::Util.3: pidl/lib/Parse/Pidl/Util.pm ->
>> bin/default/pidl/Parse::Pidl::Util.3
>> > [3692/3799] Parse::Pidl::NDR.3: pidl/lib/Parse/Pidl/NDR.pm ->
>> bin/default/pidl/Parse::Pidl::NDR.3
>> > [3693/3799] Parse::Pidl::Wireshark::NDR.3:
>> pidl/lib/Parse/Pidl/Wireshark/NDR.pm -> bin/default/pidl/Parse::Pidl::
>> Wireshark::NDR.3
>> > [3694/3799] Generating manpages/smb.conf.5
>> > I/O error : Attempt to load network entity
>> http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd
>> > default/docs-xml/manpages/smb.conf.5.xml:2: warning: failed to load
>> external entity "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd";
>> > D DocBook XML V4.2//EN" "http://www.oasis-open.org/doc
>> book/xml/4.2/docbookx.dtd"
>> >
>> ^
>> > runtime error: file /gnu/store/q0irgfv31s8m9s54zrc
>> 908qb4cim08cg-docbook-xsl-1.79.1/xml/xsl/docbook-xsl-1.79.1/lib/lib.xsl
>> line 58 element choose
>> > xsltApplySequenceConstructor: A potential infinite template recursion
>> was detected.
>> > You can adjust xsltMaxDepth (--maxdepth) in order to raise the maximum
>> number of nested template calls and variables/params (currently set to
>> 3000).
>> > Templates:
>> > #0 name string.subst
>> > #1 name string.subst
>> > #2 name string.sub

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

[Gábor Boskovits]

Hello!

It was getting quite intractable to see what I was doing, so I started to
fill my github issue tracker. Issues are labeled with change-default-java8.


2017-12-13 11:32 GMT+01:00 Efraim Flashner :

> On Tue, Dec 12, 2017 at 06:06:52PM -0800, Chris Marusich wrote:
> > Gábor Boskovits  writes:
> >
> > > I will wait for your results for now...
> >
> 
> >
> > * kodi@18.0_alpha-7-67fd70f: failed because of "potential infinite
> >   recursion"; also it seems that it's looking for a DTD on the Internet
> >   when instead it should be looking to find it in the inputs.
> >
> > --8<---cut here---start->8---
> > [3684/3799] Linking default/source3/modules/libvfs_module_worm.so
> > [3685/3799] Linking default/source3/modules/libvfs_module_crossrename.so
> > [3686/3799] Linking default/source3/modules/libvfs_module_cap.so
> > [3687/3799] Linking default/source3/modules/libvfs_module_catia.so
> > [3688/3799] pidl.1: pidl/pidl -> bin/default/pidl/pidl.1
> > [3689/3799] Parse::Pidl::Dump.3: pidl/lib/Parse/Pidl/Dump.pm ->
> bin/default/pidl/Parse::Pidl::Dump.3
> > [3690/3799] Parse::Pidl::Wireshark::Conformance.3:
> pidl/lib/Parse/Pidl/Wireshark/Conformance.pm ->
> bin/default/pidl/Parse::Pidl::Wireshark::Conformance.3
> > [3691/3799] Parse::Pidl::Util.3: pidl/lib/Parse/Pidl/Util.pm ->
> bin/default/pidl/Parse::Pidl::Util.3
> > [3692/3799] Parse::Pidl::NDR.3: pidl/lib/Parse/Pidl/NDR.pm ->
> bin/default/pidl/Parse::Pidl::NDR.3
> > [3693/3799] Parse::Pidl::Wireshark::NDR.3: 
> > pidl/lib/Parse/Pidl/Wireshark/NDR.pm
> -> bin/default/pidl/Parse::Pidl::Wireshark::NDR.3
> > [3694/3799] Generating manpages/smb.conf.5
> > I/O error : Attempt to load network entity http://www.oasis-open.org/
> docbook/xml/4.2/docbookx.dtd
> > default/docs-xml/manpages/smb.conf.5.xml:2: warning: failed to load
> external entity "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd";
> > D DocBook XML V4.2//EN" "http://www.oasis-open.org/
> docbook/xml/4.2/docbookx.dtd"
> >
>   ^
> > runtime error: file /gnu/store/q0irgfv31s8m9s54zrc908qb4cim08
> cg-docbook-xsl-1.79.1/xml/xsl/docbook-xsl-1.79.1/lib/lib.xsl line 58
> element choose
> > xsltApplySequenceConstructor: A potential infinite template recursion
> was detected.
> > You can adjust xsltMaxDepth (--maxdepth) in order to raise the maximum
> number of nested template calls and variables/params (currently set to
> 3000).
> > Templates:
> > #0 name string.subst
> > #1 name string.subst
> > #2 name string.subst
> > #3 name string.subst
> > #4 name string.subst
> > #5 name string.subst
> > #6 name string.subst
> > #7 name string.subst
> > #8 name string.subst
> > #9 name string.subst
> > #10 name string.subst
> > #11 name string.subst
> > #12 name string.subst
> > #13 name string.subst
> > #14 name string.subst
> > Variables:
> > #0
> > replacement
> > target
> > string
> > #1
> > target
> > string
> > #2
> > string
> > #3
> > replacement
> > target
> > string
> > #4
> > target
> > string
> > #5
> > string
> > #6
> > replacement
> > target
> > string
> > #7
> > target
> > string
> > #8
> > string
> > #9
> > replacement
> > target
> > string
> > #10
> > target
> > string
> > #11
> > string
> > #12
> > replacement
> > target
> > string
> > #13
> > target
> > string
> > #14
> > string
> > error: file default/docs-xml/manpages/smb.conf.5.xml
> > xsltRunStylesheet : run failed
> > Waf: Leaving directory `/tmp/guix-build-samba-4.7.3.
> drv-0/samba-4.7.3/bin'
> > Build failed:  -> task failed (err #11):
> >   {task: manpages/smb.conf.5 smb.conf.5.xml,parameters.all.xml ->
> smb.conf.5}
> > make: *** [Makefile:8: all] Error 1
> > phase `build' failed after 1063.6 seconds
> > note: keeping build directory `/tmp/guix-build-samba-4.7.3.drv-0'
> > builder for `/gnu/store/k3ykppkqdw6gyj115qjhbi50fa6hx317-samba-4.7.3.drv'
> failed with exit code 1
> > @ build-failed /gnu/store/k3ykppkqdw6gyj115qjhbi50fa6hx317-samba-4.7.3.drv
> - 1 builder for `/gnu/store/k3ykppkqdw6gyj115qjhbi50fa6hx317-samba-4.7.3.drv'
> failed with exit code 1
> > --8<---cut here---end--->8---
> >
> > I have not begun troubleshooting any of these existing issues yet.
> >
> > --
> > Chris
>
> I tested building samba on aarch64 on core-updates and it failed in the
> same manner. For the purposes of updating the default JRE I would ignore
> it and the resulting not being able to build kodi.
>
>
> --
> Efraim Flashner  אפרים פלשנר
> GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
> Confidentiality cannot be guaranteed on emails sent or received unencrypted
>

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

[Efraim Flashner]

On Tue, Dec 12, 2017 at 06:06:52PM -0800, Chris Marusich wrote:
> Gábor Boskovits  writes:
> 
> > I will wait for your results for now...
> 

> 
> * kodi@18.0_alpha-7-67fd70f: failed because of "potential infinite
>   recursion"; also it seems that it's looking for a DTD on the Internet
>   when instead it should be looking to find it in the inputs.
> 
> --8<---cut here---start->8---
> [3684/3799] Linking default/source3/modules/libvfs_module_worm.so
> [3685/3799] Linking default/source3/modules/libvfs_module_crossrename.so
> [3686/3799] Linking default/source3/modules/libvfs_module_cap.so
> [3687/3799] Linking default/source3/modules/libvfs_module_catia.so
> [3688/3799] pidl.1: pidl/pidl -> bin/default/pidl/pidl.1
> [3689/3799] Parse::Pidl::Dump.3: pidl/lib/Parse/Pidl/Dump.pm -> 
> bin/default/pidl/Parse::Pidl::Dump.3
> [3690/3799] Parse::Pidl::Wireshark::Conformance.3: 
> pidl/lib/Parse/Pidl/Wireshark/Conformance.pm -> 
> bin/default/pidl/Parse::Pidl::Wireshark::Conformance.3
> [3691/3799] Parse::Pidl::Util.3: pidl/lib/Parse/Pidl/Util.pm -> 
> bin/default/pidl/Parse::Pidl::Util.3
> [3692/3799] Parse::Pidl::NDR.3: pidl/lib/Parse/Pidl/NDR.pm -> 
> bin/default/pidl/Parse::Pidl::NDR.3
> [3693/3799] Parse::Pidl::Wireshark::NDR.3: 
> pidl/lib/Parse/Pidl/Wireshark/NDR.pm -> 
> bin/default/pidl/Parse::Pidl::Wireshark::NDR.3
> [3694/3799] Generating manpages/smb.conf.5
> I/O error : Attempt to load network entity 
> http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd
> default/docs-xml/manpages/smb.conf.5.xml:2: warning: failed to load external 
> entity "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd";
> D DocBook XML V4.2//EN" 
> "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd";
>   
>  ^
> runtime error: file 
> /gnu/store/q0irgfv31s8m9s54zrc908qb4cim08cg-docbook-xsl-1.79.1/xml/xsl/docbook-xsl-1.79.1/lib/lib.xsl
>  line 58 element choose
> xsltApplySequenceConstructor: A potential infinite template recursion was 
> detected.
> You can adjust xsltMaxDepth (--maxdepth) in order to raise the maximum number 
> of nested template calls and variables/params (currently set to 3000).
> Templates:
> #0 name string.subst 
> #1 name string.subst 
> #2 name string.subst 
> #3 name string.subst 
> #4 name string.subst 
> #5 name string.subst 
> #6 name string.subst 
> #7 name string.subst 
> #8 name string.subst 
> #9 name string.subst 
> #10 name string.subst 
> #11 name string.subst 
> #12 name string.subst 
> #13 name string.subst 
> #14 name string.subst 
> Variables:
> #0
> replacement 
> target 
> string 
> #1
> target 
> string 
> #2
> string 
> #3
> replacement 
> target 
> string 
> #4
> target 
> string 
> #5
> string 
> #6
> replacement 
> target 
> string 
> #7
> target 
> string 
> #8
> string 
> #9
> replacement 
> target 
> string 
> #10
> target 
> string 
> #11
> string 
> #12
> replacement 
> target 
> string 
> #13
> target 
> string 
> #14
> string 
> error: file default/docs-xml/manpages/smb.conf.5.xml
> xsltRunStylesheet : run failed
> Waf: Leaving directory `/tmp/guix-build-samba-4.7.3.drv-0/samba-4.7.3/bin'
> Build failed:  -> task failed (err #11): 
>   {task: manpages/smb.conf.5 smb.conf.5.xml,parameters.all.xml -> 
> smb.conf.5}
> make: *** [Makefile:8: all] Error 1
> phase `build' failed after 1063.6 seconds
> note: keeping build directory `/tmp/guix-build-samba-4.7.3.drv-0'
> builder for `/gnu/store/k3ykppkqdw6gyj115qjhbi50fa6hx317-samba-4.7.3.drv' 
> failed with exit code 1
> @ build-failed /gnu/store/k3ykppkqdw6gyj115qjhbi50fa6hx317-samba-4.7.3.drv - 
> 1 builder for `/gnu/store/k3ykppkqdw6gyj115qjhbi50fa6hx317-samba-4.7.3.drv' 
> failed with exit code 1
> --8<---cut here---end--->8---
> 
> I have not begun troubleshooting any of these existing issues yet.
> 
> -- 
> Chris

I tested building samba on aarch64 on core-updates and it failed in the
same manner. For the purposes of updating the default JRE I would ignore
it and the resulting not being able to build kodi.


-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

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

[Gábor Boskovits]

error: download from '
https://mirror.hydra.gnu.org/guix/nar/2i6pbhjlwzjcjpfd1jjv67hwg98ms6nw-java-testng-6.12.tar.gz'
failed: 504, "Gateway Time-out"
I get this for java-testng.
It seems reproducible.

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

> java-osgi-service-jdbc ok
>
> 2017-12-13 10:54 GMT+01:00 Gábor Boskovits :
>
>> clojure ok
>>
>> 2017-12-13 9:53 GMT+01:00 Gábor Boskovits :
>>
>>> I'll have a look at testng.
>>>
>>> 2017-12-13 3:06 GMT+01:00 Chris Marusich :
>>>
 Gábor Boskovits  writes:

 > I will wait for your results for now...

 I apologize for the delay.  It took 20 hours to build the "covering" of
 icedtea on my laptop, and I've been preoccupied with personal matters.
 I built commit 9e111db4535b3cd5729e37294ae51d95240334b4, which at the
 time was the tip of the core-updates branch.  I wonder if there is a way
 to check the build status of core-updates on Hydra instead?  My laptop
 has only 2 cores, so it's quite slow.  Anyway, the results are below.
 To troubleshoot locally, check out the above commit (or a more recent
 one, if you're feeling brave) and try to build one of the packages that
 failed.

 Successfully built:

 ant@1.10.1
 antlr3@3.5.2
 axoloti-patcher@1.0.12
 clojure@1.8.0
 f-seq@1.1-1.6ccded3
 hdf-java@3.3.2
 icedtea-web@1.6.2
 java-commons-beanutils@1.9.3
 java-commons-cli@1.2
 java-commons-collections4@4.1
 java-commons-daemon@1.0.15
 java-commons-lang@2.6
 java-commons-net@3.6
 java-eclipse-jetty-servlet@9.4.6
 java-eclipse-team-core@3.8.0
 java-guice-servlet@4.1
 java-httpcomponents-httpcore-ab@4.4.6
 java-httpcomponents-httpcore-nio@4.4.6
 java-httpcomponents-httpmime@4.5.3
 java-javax-mail@1.5.6
 java-jbzip2@0.9.1
 java-jdom@1.1.3
 java-jgit@4.7.0.201704051617-r
 java-jmh@1.17.5
 java-osgi-service-cm@1.5.0
 java-osgi-service-jdbc@1.0.0
 java-osgi-service-packageadmin@1.2.0
 java-osgi-service-resolver@1.0.1
 java-osgi-util-tracker@1.5.1
 java-plexus-interpolation@1.23
 javacc@7.0.3
 minced@0.2.0
 plantuml@8048
 r-seurat@1.4.0.12-1.fccb77d
 ruby-atoulme-antwrap@0.7.5
 sra-tools@2.8.2-1
 tuxguitar@1.4

 Failed to build:

 java-eclipse-jetty-servlet@9.2.22
 java-picard@1.113
 java-picard@2.3.0
 java-plexus-container-default@1.7.1
 kodi@18.0_alpha-7-67fd70f

 The failure causes were as follows:

 * java-eclipse-jetty-servlet@9.2.22:

 --8<---cut here---start->8---
 ...
 starting phase `check'
 Buildfile: /tmp/guix-build-java-eclipse-jetty-security-9.2.22.drv-0/jet
 ty.project-jetty-9.2.22.v20170606/jetty-security/build.xml

 compile-tests:
 [mkdir] Created dir: /tmp/guix-build-java-eclipse-j
 etty-security-9.2.22.drv-0/jetty.project-jetty-9.2.22.v20170
 606/jetty-security/build/test-classesCompiling 5 source files to
 /tmp/guix-build-java-eclipse-jetty-security-9.2.22.drv-0/jet
 ty.project-jetty-9.2.22.v20170606/jetty-security/build/test-classes
 check:
 [mkdir] Created dir: /tmp/guix-build-java-eclipse-j
 etty-security-9.2.22.drv-0/jetty.project-jetty-9.2.22.v20170
 606/jetty-security/src/test/test-reportsning
 org.eclipse.jetty.security.AliasedConstraintTest
 [junit] SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBi
 nder".
 [junit] SLF4J: Defaulting to no-operation (NOP) logger
 implementation
 [junit] SLF4J: See http://www.slf4j.org/codes.htm
 l#StaticLoggerBinder for further details.
 [junit] Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time
 elapsed: 0.439 sec
 [junit] Running org.eclipse.jetty.security.ConstraintTest
 [junit] SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBi
 nder".
 [junit] SLF4J: Defaulting to no-operation (NOP) logger
 implementation
 [junit] SLF4J: See http://www.slf4j.org/codes.htm
 l#StaticLoggerBinder for further details.
 [junit] Tests run: 22, Failures: 1, Errors: 0, Skipped: 0, Time
 elapsed: 0.682 sec
 [junit] HTTP/1.1 302 Found
 [junit] Date: Sun, 10 Dec 2017 05:32:20 GMT
 [junit] Location: https://wobble.com/ctx/data/info
 [junit] Content-Length: 0
 [junit] Server: Jetty(9.2.z-SNAPSHOT)
 [junit]
 [junit]

 BUILD FAILED
 /tmp/guix-build-java-eclipse-jetty-security-9.2.22.drv-0/jet
 ty.project-jetty-9.2.22.v20170606/jetty-security/build.xml:1: Test
 org.eclipse.jetty.security.ConstraintTest failed
 --8<---cut here---end--->8---

 * java-picard@1.113: Failed because testng failed to build:

 --8<---cut here---start->8---
 ===
 

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

[Gábor Boskovits]

java-osgi-service-jdbc ok

2017-12-13 10:54 GMT+01:00 Gábor Boskovits :

> clojure ok
>
> 2017-12-13 9:53 GMT+01:00 Gábor Boskovits :
>
>> I'll have a look at testng.
>>
>> 2017-12-13 3:06 GMT+01:00 Chris Marusich :
>>
>>> Gábor Boskovits  writes:
>>>
>>> > I will wait for your results for now...
>>>
>>> I apologize for the delay.  It took 20 hours to build the "covering" of
>>> icedtea on my laptop, and I've been preoccupied with personal matters.
>>> I built commit 9e111db4535b3cd5729e37294ae51d95240334b4, which at the
>>> time was the tip of the core-updates branch.  I wonder if there is a way
>>> to check the build status of core-updates on Hydra instead?  My laptop
>>> has only 2 cores, so it's quite slow.  Anyway, the results are below.
>>> To troubleshoot locally, check out the above commit (or a more recent
>>> one, if you're feeling brave) and try to build one of the packages that
>>> failed.
>>>
>>> Successfully built:
>>>
>>> ant@1.10.1
>>> antlr3@3.5.2
>>> axoloti-patcher@1.0.12
>>> clojure@1.8.0
>>> f-seq@1.1-1.6ccded3
>>> hdf-java@3.3.2
>>> icedtea-web@1.6.2
>>> java-commons-beanutils@1.9.3
>>> java-commons-cli@1.2
>>> java-commons-collections4@4.1
>>> java-commons-daemon@1.0.15
>>> java-commons-lang@2.6
>>> java-commons-net@3.6
>>> java-eclipse-jetty-servlet@9.4.6
>>> java-eclipse-team-core@3.8.0
>>> java-guice-servlet@4.1
>>> java-httpcomponents-httpcore-ab@4.4.6
>>> java-httpcomponents-httpcore-nio@4.4.6
>>> java-httpcomponents-httpmime@4.5.3
>>> java-javax-mail@1.5.6
>>> java-jbzip2@0.9.1
>>> java-jdom@1.1.3
>>> java-jgit@4.7.0.201704051617-r
>>> java-jmh@1.17.5
>>> java-osgi-service-cm@1.5.0
>>> java-osgi-service-jdbc@1.0.0
>>> java-osgi-service-packageadmin@1.2.0
>>> java-osgi-service-resolver@1.0.1
>>> java-osgi-util-tracker@1.5.1
>>> java-plexus-interpolation@1.23
>>> javacc@7.0.3
>>> minced@0.2.0
>>> plantuml@8048
>>> r-seurat@1.4.0.12-1.fccb77d
>>> ruby-atoulme-antwrap@0.7.5
>>> sra-tools@2.8.2-1
>>> tuxguitar@1.4
>>>
>>> Failed to build:
>>>
>>> java-eclipse-jetty-servlet@9.2.22
>>> java-picard@1.113
>>> java-picard@2.3.0
>>> java-plexus-container-default@1.7.1
>>> kodi@18.0_alpha-7-67fd70f
>>>
>>> The failure causes were as follows:
>>>
>>> * java-eclipse-jetty-servlet@9.2.22:
>>>
>>> --8<---cut here---start->8---
>>> ...
>>> starting phase `check'
>>> Buildfile: /tmp/guix-build-java-eclipse-jetty-security-9.2.22.drv-0/jet
>>> ty.project-jetty-9.2.22.v20170606/jetty-security/build.xml
>>>
>>> compile-tests:
>>> [mkdir] Created dir: /tmp/guix-build-java-eclipse-j
>>> etty-security-9.2.22.drv-0/jetty.project-jetty-9.2.22.v20170
>>> 606/jetty-security/build/test-classesCompiling 5 source files to
>>> /tmp/guix-build-java-eclipse-jetty-security-9.2.22.drv-0/jet
>>> ty.project-jetty-9.2.22.v20170606/jetty-security/build/test-classes
>>> check:
>>> [mkdir] Created dir: /tmp/guix-build-java-eclipse-j
>>> etty-security-9.2.22.drv-0/jetty.project-jetty-9.2.22.v20170
>>> 606/jetty-security/src/test/test-reportsning
>>> org.eclipse.jetty.security.AliasedConstraintTest
>>> [junit] SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBi
>>> nder".
>>> [junit] SLF4J: Defaulting to no-operation (NOP) logger implementation
>>> [junit] SLF4J: See http://www.slf4j.org/codes.htm
>>> l#StaticLoggerBinder for further details.
>>> [junit] Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time
>>> elapsed: 0.439 sec
>>> [junit] Running org.eclipse.jetty.security.ConstraintTest
>>> [junit] SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBi
>>> nder".
>>> [junit] SLF4J: Defaulting to no-operation (NOP) logger implementation
>>> [junit] SLF4J: See http://www.slf4j.org/codes.htm
>>> l#StaticLoggerBinder for further details.
>>> [junit] Tests run: 22, Failures: 1, Errors: 0, Skipped: 0, Time
>>> elapsed: 0.682 sec
>>> [junit] HTTP/1.1 302 Found
>>> [junit] Date: Sun, 10 Dec 2017 05:32:20 GMT
>>> [junit] Location: https://wobble.com/ctx/data/info
>>> [junit] Content-Length: 0
>>> [junit] Server: Jetty(9.2.z-SNAPSHOT)
>>> [junit]
>>> [junit]
>>>
>>> BUILD FAILED
>>> /tmp/guix-build-java-eclipse-jetty-security-9.2.22.drv-0/jet
>>> ty.project-jetty-9.2.22.v20170606/jetty-security/build.xml:1: Test
>>> org.eclipse.jetty.security.ConstraintTest failed
>>> --8<---cut here---end--->8---
>>>
>>> * java-picard@1.113: Failed because testng failed to build:
>>>
>>> --8<---cut here---start->8---
>>> ===
>>> TestNG
>>> Total tests run: 1517, Failures: 1, Skips: 0
>>> ===
>>>
>>> Failures in  :TestNG,  :Parallelization
>>> test.thread.parallelization.ParallelByMethodsTestCase7Scenar
>>> io2.verifyThatTestMethodsRunInParallelThreads()
>>> StackTrace:
>>>  java.lang.AssertionError: Expected 25 test method execution event logs
>>> to be in a block of m

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

[Gábor Boskovits]

clojure ok

2017-12-13 9:53 GMT+01:00 Gábor Boskovits :

> I'll have a look at testng.
>
> 2017-12-13 3:06 GMT+01:00 Chris Marusich :
>
>> Gábor Boskovits  writes:
>>
>> > I will wait for your results for now...
>>
>> I apologize for the delay.  It took 20 hours to build the "covering" of
>> icedtea on my laptop, and I've been preoccupied with personal matters.
>> I built commit 9e111db4535b3cd5729e37294ae51d95240334b4, which at the
>> time was the tip of the core-updates branch.  I wonder if there is a way
>> to check the build status of core-updates on Hydra instead?  My laptop
>> has only 2 cores, so it's quite slow.  Anyway, the results are below.
>> To troubleshoot locally, check out the above commit (or a more recent
>> one, if you're feeling brave) and try to build one of the packages that
>> failed.
>>
>> Successfully built:
>>
>> ant@1.10.1
>> antlr3@3.5.2
>> axoloti-patcher@1.0.12
>> clojure@1.8.0
>> f-seq@1.1-1.6ccded3
>> hdf-java@3.3.2
>> icedtea-web@1.6.2
>> java-commons-beanutils@1.9.3
>> java-commons-cli@1.2
>> java-commons-collections4@4.1
>> java-commons-daemon@1.0.15
>> java-commons-lang@2.6
>> java-commons-net@3.6
>> java-eclipse-jetty-servlet@9.4.6
>> java-eclipse-team-core@3.8.0
>> java-guice-servlet@4.1
>> java-httpcomponents-httpcore-ab@4.4.6
>> java-httpcomponents-httpcore-nio@4.4.6
>> java-httpcomponents-httpmime@4.5.3
>> java-javax-mail@1.5.6
>> java-jbzip2@0.9.1
>> java-jdom@1.1.3
>> java-jgit@4.7.0.201704051617-r
>> java-jmh@1.17.5
>> java-osgi-service-cm@1.5.0
>> java-osgi-service-jdbc@1.0.0
>> java-osgi-service-packageadmin@1.2.0
>> java-osgi-service-resolver@1.0.1
>> java-osgi-util-tracker@1.5.1
>> java-plexus-interpolation@1.23
>> javacc@7.0.3
>> minced@0.2.0
>> plantuml@8048
>> r-seurat@1.4.0.12-1.fccb77d
>> ruby-atoulme-antwrap@0.7.5
>> sra-tools@2.8.2-1
>> tuxguitar@1.4
>>
>> Failed to build:
>>
>> java-eclipse-jetty-servlet@9.2.22
>> java-picard@1.113
>> java-picard@2.3.0
>> java-plexus-container-default@1.7.1
>> kodi@18.0_alpha-7-67fd70f
>>
>> The failure causes were as follows:
>>
>> * java-eclipse-jetty-servlet@9.2.22:
>>
>> --8<---cut here---start->8---
>> ...
>> starting phase `check'
>> Buildfile: /tmp/guix-build-java-eclipse-jetty-security-9.2.22.drv-0/jet
>> ty.project-jetty-9.2.22.v20170606/jetty-security/build.xml
>>
>> compile-tests:
>> [mkdir] Created dir: /tmp/guix-build-java-eclipse-j
>> etty-security-9.2.22.drv-0/jetty.project-jetty-9.2.22.v20170
>> 606/jetty-security/build/test-classesCompiling 5 source files to
>> /tmp/guix-build-java-eclipse-jetty-security-9.2.22.drv-0/jet
>> ty.project-jetty-9.2.22.v20170606/jetty-security/build/test-classes
>> check:
>> [mkdir] Created dir: /tmp/guix-build-java-eclipse-j
>> etty-security-9.2.22.drv-0/jetty.project-jetty-9.2.22.v20170
>> 606/jetty-security/src/test/test-reportsning
>> org.eclipse.jetty.security.AliasedConstraintTest
>> [junit] SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBi
>> nder".
>> [junit] SLF4J: Defaulting to no-operation (NOP) logger implementation
>> [junit] SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder
>> for further details.
>> [junit] Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time
>> elapsed: 0.439 sec
>> [junit] Running org.eclipse.jetty.security.ConstraintTest
>> [junit] SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBi
>> nder".
>> [junit] SLF4J: Defaulting to no-operation (NOP) logger implementation
>> [junit] SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder
>> for further details.
>> [junit] Tests run: 22, Failures: 1, Errors: 0, Skipped: 0, Time
>> elapsed: 0.682 sec
>> [junit] HTTP/1.1 302 Found
>> [junit] Date: Sun, 10 Dec 2017 05:32:20 GMT
>> [junit] Location: https://wobble.com/ctx/data/info
>> [junit] Content-Length: 0
>> [junit] Server: Jetty(9.2.z-SNAPSHOT)
>> [junit]
>> [junit]
>>
>> BUILD FAILED
>> /tmp/guix-build-java-eclipse-jetty-security-9.2.22.drv-0/jet
>> ty.project-jetty-9.2.22.v20170606/jetty-security/build.xml:1: Test
>> org.eclipse.jetty.security.ConstraintTest failed
>> --8<---cut here---end--->8---
>>
>> * java-picard@1.113: Failed because testng failed to build:
>>
>> --8<---cut here---start->8---
>> ===
>> TestNG
>> Total tests run: 1517, Failures: 1, Skips: 0
>> ===
>>
>> Failures in  :TestNG,  :Parallelization
>> test.thread.parallelization.ParallelByMethodsTestCase7Scenar
>> io2.verifyThatTestMethodsRunInParallelThreads()
>> StackTrace:
>>  java.lang.AssertionError: Expected 25 test method execution event logs
>> to be in a block of methods executing in parallel. Found an event log of a
>> different type in the block being processed: [EventLog{Event:
>> TEST_METHOD_EXECUTION, Suite: TestSuiteA, Test:
>> TestSuiteA-TwoTestClassTest, Class: te

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

[Gábor Boskovits]

I'll have a look at testng.

2017-12-13 3:06 GMT+01:00 Chris Marusich :

> Gábor Boskovits  writes:
>
> > I will wait for your results for now...
>
> I apologize for the delay.  It took 20 hours to build the "covering" of
> icedtea on my laptop, and I've been preoccupied with personal matters.
> I built commit 9e111db4535b3cd5729e37294ae51d95240334b4, which at the
> time was the tip of the core-updates branch.  I wonder if there is a way
> to check the build status of core-updates on Hydra instead?  My laptop
> has only 2 cores, so it's quite slow.  Anyway, the results are below.
> To troubleshoot locally, check out the above commit (or a more recent
> one, if you're feeling brave) and try to build one of the packages that
> failed.
>
> Successfully built:
>
> ant@1.10.1
> antlr3@3.5.2
> axoloti-patcher@1.0.12
> clojure@1.8.0
> f-seq@1.1-1.6ccded3
> hdf-java@3.3.2
> icedtea-web@1.6.2
> java-commons-beanutils@1.9.3
> java-commons-cli@1.2
> java-commons-collections4@4.1
> java-commons-daemon@1.0.15
> java-commons-lang@2.6
> java-commons-net@3.6
> java-eclipse-jetty-servlet@9.4.6
> java-eclipse-team-core@3.8.0
> java-guice-servlet@4.1
> java-httpcomponents-httpcore-ab@4.4.6
> java-httpcomponents-httpcore-nio@4.4.6
> java-httpcomponents-httpmime@4.5.3
> java-javax-mail@1.5.6
> java-jbzip2@0.9.1
> java-jdom@1.1.3
> java-jgit@4.7.0.201704051617-r
> java-jmh@1.17.5
> java-osgi-service-cm@1.5.0
> java-osgi-service-jdbc@1.0.0
> java-osgi-service-packageadmin@1.2.0
> java-osgi-service-resolver@1.0.1
> java-osgi-util-tracker@1.5.1
> java-plexus-interpolation@1.23
> javacc@7.0.3
> minced@0.2.0
> plantuml@8048
> r-seurat@1.4.0.12-1.fccb77d
> ruby-atoulme-antwrap@0.7.5
> sra-tools@2.8.2-1
> tuxguitar@1.4
>
> Failed to build:
>
> java-eclipse-jetty-servlet@9.2.22
> java-picard@1.113
> java-picard@2.3.0
> java-plexus-container-default@1.7.1
> kodi@18.0_alpha-7-67fd70f
>
> The failure causes were as follows:
>
> * java-eclipse-jetty-servlet@9.2.22:
>
> --8<---cut here---start->8---
> ...
> starting phase `check'
> Buildfile: /tmp/guix-build-java-eclipse-jetty-security-9.2.22.drv-0/
> jetty.project-jetty-9.2.22.v20170606/jetty-security/build.xml
>
> compile-tests:
> [mkdir] Created dir: /tmp/guix-build-java-eclipse-
> jetty-security-9.2.22.drv-0/jetty.project-jetty-9.2.22.
> v20170606/jetty-security/build/test-classesCompiling 5 source files to
> /tmp/guix-build-java-eclipse-jetty-security-9.2.22.drv-0/
> jetty.project-jetty-9.2.22.v20170606/jetty-security/build/test-classes
> check:
> [mkdir] Created dir: /tmp/guix-build-java-eclipse-
> jetty-security-9.2.22.drv-0/jetty.project-jetty-9.2.22.
> v20170606/jetty-security/src/test/test-reportsning
> org.eclipse.jetty.security.AliasedConstraintTest
> [junit] SLF4J: Failed to load class "org.slf4j.impl.
> StaticLoggerBinder".
> [junit] SLF4J: Defaulting to no-operation (NOP) logger implementation
> [junit] SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder
> for further details.
> [junit] Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time
> elapsed: 0.439 sec
> [junit] Running org.eclipse.jetty.security.ConstraintTest
> [junit] SLF4J: Failed to load class "org.slf4j.impl.
> StaticLoggerBinder".
> [junit] SLF4J: Defaulting to no-operation (NOP) logger implementation
> [junit] SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder
> for further details.
> [junit] Tests run: 22, Failures: 1, Errors: 0, Skipped: 0, Time
> elapsed: 0.682 sec
> [junit] HTTP/1.1 302 Found
> [junit] Date: Sun, 10 Dec 2017 05:32:20 GMT
> [junit] Location: https://wobble.com/ctx/data/info
> [junit] Content-Length: 0
> [junit] Server: Jetty(9.2.z-SNAPSHOT)
> [junit]
> [junit]
>
> BUILD FAILED
> /tmp/guix-build-java-eclipse-jetty-security-9.2.22.drv-0/
> jetty.project-jetty-9.2.22.v20170606/jetty-security/build.xml:1: Test
> org.eclipse.jetty.security.ConstraintTest failed
> --8<---cut here---end--->8---
>
> * java-picard@1.113: Failed because testng failed to build:
>
> --8<---cut here---start->8---
> ===
> TestNG
> Total tests run: 1517, Failures: 1, Skips: 0
> ===
>
> Failures in  :TestNG,  :Parallelization
> test.thread.parallelization.ParallelByMethodsTestCase7Scenario2.
> verifyThatTestMethodsRunInParallelThreads()
> StackTrace:
>  java.lang.AssertionError: Expected 25 test method execution event logs to
> be in a block of methods executing in parallel. Found an event log of a
> different type in the block being processed: [EventLog{Event:
> TEST_METHOD_EXECUTION, Suite: TestSuiteA, Test:
> TestSuiteA-TwoTestClassTest, Class: test.thread.parallelization.sample.
> TestClassAFiveMethodsWithFactoryUsingDataProviderAndNoDepsSample, Class
> instance hash code: 1380194466, Method name: testMethodA, Data provider
> param: p

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

[Chris Marusich]

Gábor Boskovits  writes:

> I will wait for your results for now...

I apologize for the delay.  It took 20 hours to build the "covering" of
icedtea on my laptop, and I've been preoccupied with personal matters.
I built commit 9e111db4535b3cd5729e37294ae51d95240334b4, which at the
time was the tip of the core-updates branch.  I wonder if there is a way
to check the build status of core-updates on Hydra instead?  My laptop
has only 2 cores, so it's quite slow.  Anyway, the results are below.
To troubleshoot locally, check out the above commit (or a more recent
one, if you're feeling brave) and try to build one of the packages that
failed.

Successfully built:

ant@1.10.1
antlr3@3.5.2
axoloti-patcher@1.0.12
clojure@1.8.0
f-seq@1.1-1.6ccded3
hdf-java@3.3.2
icedtea-web@1.6.2
java-commons-beanutils@1.9.3
java-commons-cli@1.2
java-commons-collections4@4.1
java-commons-daemon@1.0.15
java-commons-lang@2.6
java-commons-net@3.6
java-eclipse-jetty-servlet@9.4.6
java-eclipse-team-core@3.8.0
java-guice-servlet@4.1
java-httpcomponents-httpcore-ab@4.4.6
java-httpcomponents-httpcore-nio@4.4.6
java-httpcomponents-httpmime@4.5.3
java-javax-mail@1.5.6
java-jbzip2@0.9.1
java-jdom@1.1.3
java-jgit@4.7.0.201704051617-r
java-jmh@1.17.5
java-osgi-service-cm@1.5.0
java-osgi-service-jdbc@1.0.0
java-osgi-service-packageadmin@1.2.0
java-osgi-service-resolver@1.0.1
java-osgi-util-tracker@1.5.1
java-plexus-interpolation@1.23
javacc@7.0.3
minced@0.2.0
plantuml@8048
r-seurat@1.4.0.12-1.fccb77d
ruby-atoulme-antwrap@0.7.5
sra-tools@2.8.2-1
tuxguitar@1.4

Failed to build:

java-eclipse-jetty-servlet@9.2.22
java-picard@1.113
java-picard@2.3.0
java-plexus-container-default@1.7.1
kodi@18.0_alpha-7-67fd70f

The failure causes were as follows:

* java-eclipse-jetty-servlet@9.2.22:

--8<---cut here---start->8---
...
starting phase `check'
Buildfile: 
/tmp/guix-build-java-eclipse-jetty-security-9.2.22.drv-0/jetty.project-jetty-9.2.22.v20170606/jetty-security/build.xml

compile-tests:
[mkdir] Created dir: 
/tmp/guix-build-java-eclipse-jetty-security-9.2.22.drv-0/jetty.project-jetty-9.2.22.v20170606/jetty-security/build/test-classesCompiling
 5 source files to 
/tmp/guix-build-java-eclipse-jetty-security-9.2.22.drv-0/jetty.project-jetty-9.2.22.v20170606/jetty-security/build/test-classes
check:
[mkdir] Created dir: 
/tmp/guix-build-java-eclipse-jetty-security-9.2.22.drv-0/jetty.project-jetty-9.2.22.v20170606/jetty-security/src/test/test-reportsning
 org.eclipse.jetty.security.AliasedConstraintTest
[junit] SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
[junit] SLF4J: Defaulting to no-operation (NOP) logger implementation
[junit] SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for 
further details.
[junit] Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
0.439 sec
[junit] Running org.eclipse.jetty.security.ConstraintTest
[junit] SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
[junit] SLF4J: Defaulting to no-operation (NOP) logger implementation
[junit] SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for 
further details.
[junit] Tests run: 22, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 
0.682 sec
[junit] HTTP/1.1 302 Found
[junit] Date: Sun, 10 Dec 2017 05:32:20 GMT
[junit] Location: https://wobble.com/ctx/data/info
[junit] Content-Length: 0
[junit] Server: Jetty(9.2.z-SNAPSHOT)
[junit] 
[junit] 

BUILD FAILED
/tmp/guix-build-java-eclipse-jetty-security-9.2.22.drv-0/jetty.project-jetty-9.2.22.v20170606/jetty-security/build.xml:1:
 Test org.eclipse.jetty.security.ConstraintTest failed
--8<---cut here---end--->8---

* java-picard@1.113: Failed because testng failed to build:

--8<---cut here---start->8---
===
TestNG
Total tests run: 1517, Failures: 1, Skips: 0
===

Failures in  :TestNG,  :Parallelization
test.thread.parallelization.ParallelByMethodsTestCase7Scenario2.verifyThatTestMethodsRunInParallelThreads()
StackTrace:
 java.lang.AssertionError: Expected 25 test method execution event logs to be 
in a block of methods executing in parallel. Found an event log of a different 
type in the block being processed: [EventLog{Event: TEST_METHOD_EXECUTION, 
Suite: TestSuiteA, Test: TestSuiteA-TwoTestClassTest, Class: 
test.thread.parallelization.sample.TestClassAFiveMethodsWithFactoryUsingDataProviderAndNoDepsSample,
 Class instance hash code: 1380194466, Method name: testMethodA, Data provider 
param: paramOne, Time of event: 1512869923380, Thread ID: 5561}, 
EventLog{Event: TEST_METHOD_EXECUTION, Suite: TestSuiteA, Test: 
TestSuiteA-TwoTestClassTest, Class: 
test.thread.parallelization.sample.TestClassAFiveMethodsWithFactoryUsingDataProviderAndNoDepsSample,
 Class instance hash code: 841323501, Method name: tes

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

[Gábor Boskovits]

hamcrest-core 1.3 fails.
 Exception in thread "main" java.lang.NoClassDefFoundError:
org/hamcrest/generator/qdox/JavaDocBuilder

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

> r-seurat is ok.
>
> 2017-12-12 17:57 GMT+01:00 Chris Marusich :
>
>> Chris Marusich  writes:
>>
>> > Now that things are hopefully fixed up a bit more in core-updates I am
>> > trying again to build the "covering" of icedtea to see what still needs
>> > to be fixed.  I'll let you know how that goes.
>>
>> It took a long time to build (about 20 hours), and I was busy with other
>> things, so I just got time now to send the info.  Most of the packages
>> build on core-updates (I tested using commit
>> 9e111db4535b3cd5729e37294ae51d95240334b4), but there are some existing
>> failures.  Please see the attached file for details.
>>
>> For reference, I've also attached the two scripts I used to build the
>> packages - note that they won't work for you unless you update some
>> paths hard-coded in the scripts.
>>
>> Isn't there a way to outsource this "does it build?" sort of testing to
>> Hydra?  I thought that's what it was there for.
>>
>> --
>> Chris
>>
>
>

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

[Gábor Boskovits]

r-seurat is ok.

2017-12-12 17:57 GMT+01:00 Chris Marusich :

> Chris Marusich  writes:
>
> > Now that things are hopefully fixed up a bit more in core-updates I am
> > trying again to build the "covering" of icedtea to see what still needs
> > to be fixed.  I'll let you know how that goes.
>
> It took a long time to build (about 20 hours), and I was busy with other
> things, so I just got time now to send the info.  Most of the packages
> build on core-updates (I tested using commit
> 9e111db4535b3cd5729e37294ae51d95240334b4), but there are some existing
> failures.  Please see the attached file for details.
>
> For reference, I've also attached the two scripts I used to build the
> packages - note that they won't work for you unless you update some
> paths hard-coded in the scripts.
>
> Isn't there a way to outsource this "does it build?" sort of testing to
> Hydra?  I thought that's what it was there for.
>
> --
> Chris
>

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

[Gábor Boskovits]

minced is ok.

2017-12-12 12:30 GMT+01:00 Gábor Boskovits :

> Ok I've built ant 1.9.9 with ant/java8 and icedtea8. It is ok.
>
> 2017-12-10 16:56 GMT+01:00 Gábor Boskovits :
>
>> I've seen package:
>> java-jgit-4.2 explicitly depending on icedtea-7
>> other explicit dependencies are for:
>> icedtea-7
>> ant
>>
>> These are ok, I believe.
>>
>> We have ant/java8.
>>
>> What is the current status of these two:
>> ant vs ant/java8, is ant/java8 the default?
>> Should we do something with these?
>>
>>
>>
>> 2017-12-08 8:01 GMT+01:00 Gábor Boskovits :
>>
>>> Ok, hopefully that will work out. However there was a hint yesterday,
>>> that newest core-updates is broken again after a recent merge...
>>> It might worth to have a look around to see if it's woth to do on an
>>> older revision...
>>>
>>> I will wait for your results for now...
>>>
>>> Maybe later this weekend I can start up a few vm-s with guixsd, and have
>>> those involved in rebuilding if needed...
>>>
>>> 2017-12-08 7:55 GMT+01:00 Chris Marusich :
>>>
 Gábor Boskovits  writes:

 > sra-tools2.8.2-1 builds with no problem.

 Now that things are hopefully fixed up a bit more in core-updates I am
 trying again to build the "covering" of icedtea to see what still needs
 to be fixed.  I'll let you know how that goes.

 --
 Chris

>>>
>>>
>>
>

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

[Gábor Boskovits]

Ok I've built ant 1.9.9 with ant/java8 and icedtea8. It is ok.

2017-12-10 16:56 GMT+01:00 Gábor Boskovits :

> I've seen package:
> java-jgit-4.2 explicitly depending on icedtea-7
> other explicit dependencies are for:
> icedtea-7
> ant
>
> These are ok, I believe.
>
> We have ant/java8.
>
> What is the current status of these two:
> ant vs ant/java8, is ant/java8 the default?
> Should we do something with these?
>
>
>
> 2017-12-08 8:01 GMT+01:00 Gábor Boskovits :
>
>> Ok, hopefully that will work out. However there was a hint yesterday,
>> that newest core-updates is broken again after a recent merge...
>> It might worth to have a look around to see if it's woth to do on an
>> older revision...
>>
>> I will wait for your results for now...
>>
>> Maybe later this weekend I can start up a few vm-s with guixsd, and have
>> those involved in rebuilding if needed...
>>
>> 2017-12-08 7:55 GMT+01:00 Chris Marusich :
>>
>>> Gábor Boskovits  writes:
>>>
>>> > sra-tools2.8.2-1 builds with no problem.
>>>
>>> Now that things are hopefully fixed up a bit more in core-updates I am
>>> trying again to build the "covering" of icedtea to see what still needs
>>> to be fixed.  I'll let you know how that goes.
>>>
>>> --
>>> Chris
>>>
>>
>>
>

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

[Gábor Boskovits]

I've seen package:
java-jgit-4.2 explicitly depending on icedtea-7
other explicit dependencies are for:
icedtea-7
ant

These are ok, I believe.

We have ant/java8.

What is the current status of these two:
ant vs ant/java8, is ant/java8 the default?
Should we do something with these?



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

> Ok, hopefully that will work out. However there was a hint yesterday, that
> newest core-updates is broken again after a recent merge...
> It might worth to have a look around to see if it's woth to do on an older
> revision...
>
> I will wait for your results for now...
>
> Maybe later this weekend I can start up a few vm-s with guixsd, and have
> those involved in rebuilding if needed...
>
> 2017-12-08 7:55 GMT+01:00 Chris Marusich :
>
>> Gábor Boskovits  writes:
>>
>> > sra-tools2.8.2-1 builds with no problem.
>>
>> Now that things are hopefully fixed up a bit more in core-updates I am
>> trying again to build the "covering" of icedtea to see what still needs
>> to be fixed.  I'll let you know how that goes.
>>
>> --
>> Chris
>>
>
>

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

[Gábor Boskovits]

Ok, hopefully that will work out. However there was a hint yesterday, that
newest core-updates is broken again after a recent merge...
It might worth to have a look around to see if it's woth to do on an older
revision...

I will wait for your results for now...

Maybe later this weekend I can start up a few vm-s with guixsd, and have
those involved in rebuilding if needed...

2017-12-08 7:55 GMT+01:00 Chris Marusich :

> Gábor Boskovits  writes:
>
> > sra-tools2.8.2-1 builds with no problem.
>
> Now that things are hopefully fixed up a bit more in core-updates I am
> trying again to build the "covering" of icedtea to see what still needs
> to be fixed.  I'll let you know how that goes.
>
> --
> Chris
>

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

[Chris Marusich]

Gábor Boskovits  writes:

> sra-tools2.8.2-1 builds with no problem.

Now that things are hopefully fixed up a bit more in core-updates I am
trying again to build the "covering" of icedtea to see what still needs
to be fixed.  I'll let you know how that goes.

-- 
Chris


signature.asc
Description: PGP signature

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

[Gábor Boskovits]

sra-tools2.8.2-1 builds with no problem.


2017-12-07 18:50 GMT+01:00 Gábor Boskovits :

> Hello!
>
> The gtk+ patch is now in core-updates.
>
>
> 2017-12-05 8:07 GMT+01:00 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 :)
>>>
>>
>>
>

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

[Gábor Boskovits]

Hello!

The gtk+ patch is now in core-updates.


2017-12-05 8:07 GMT+01:00 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 :)
>>
>
>

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 :)
>

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

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: 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 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: 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: 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]

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]

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]

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]

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]

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_.27xlocale.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) {
  ^
 In file included from /gnu/store/nz2m4gdvgzcrkqa4xwv
 360iskh7syj7i-gcc-5.5.0/include/c++/cmath:44:0,
  from number_decimalquantity.cpp:9:
 number_decimalquantity.cpp:333:14: error: expected primary-expression
 before ‘float’
  if (std::signbit(n) != 0) {
   ^
 number_decimalquantity.cpp:333:14: error: expected primary-expression
 before ‘default’
  if (std::signbit(n) != 0) {
   ^
 number_decimalquantity.cpp:333:14: error: expected primary-expression
 before ‘long’
  if (std::signbit(n) != 0) {
   ^
 number_decimalquantity.cpp:333:14: error: expected primary-expression
 before ‘:’ token
  if (std::signbit(n) != 0) {
   ^
 number_decimalquantity.cpp:337:9: error: ‘__builtin_isnan’ is not a
 me

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

[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_.27xlocale.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) {
>>>  ^
>>> In file included from /gnu/store/nz2m4gdvgzcrkqa4xwv
>>> 360iskh7syj7i-gcc-5.5.0/include/c++/cmath:44:0,
>>>  from number_decimalquantity.cpp:9:
>>> number_decimalquantity.cpp:333:14: error: expected primary-expression
>>> before ‘float’
>>>  if (std::signbit(n) != 0) {
>>>   ^
>>> number_decimalquantity.cpp:333:14: error: expected primary-expression
>>> before ‘default’
>>>  if (std::signbit(n) != 0) {
>>>   ^
>>> number_decimalquantity.cpp:333:14: error: expected primary-expression
>>> before ‘long’
>>>  if (std::signbit(n) != 0) {
>>>   ^
>>> number_decimalquantity.cpp:333:14: error: expected primary-expression
>>> before ‘:’ token
>>>  if (std::signbit(n) != 0) {
>>>   ^
>>> number_decimalquantity.cpp:337:9: error: ‘__builtin_isnan’ is not a
>>> member of ‘std’
>>>  if (std::isnan(n) != 0) {
>>>  ^
>>> number_decimalquantity.cpp:337:9: note: suggested alternative:
>>> : note:   ‘__builtin_isnan’
>>> number_decimalquantity.cpp:339:16: error: ‘__builtin_isfinite’ is not a
>>> member of ‘std’
>>>  } else if (std::isf

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

[Gábor Boskovits]

Ok, I found this one:
https://sourceware.org/glibc/wiki/Release/2.26#Removal_of_.27xlocale.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) {
>>  ^
>> In file included from /gnu/store/nz2m4gdvgzcrkqa4xwv
>> 360iskh7syj7i-gcc-5.5.0/include/c++/cmath:44:0,
>>  from number_decimalquantity.cpp:9:
>> number_decimalquantity.cpp:333:14: error: expected primary-expression
>> before ‘float’
>>  if (std::signbit(n) != 0) {
>>   ^
>> number_decimalquantity.cpp:333:14: error: expected primary-expression
>> before ‘default’
>>  if (std::signbit(n) != 0) {
>>   ^
>> number_decimalquantity.cpp:333:14: error: expected primary-expression
>> before ‘long’
>>  if (std::signbit(n) != 0) {
>>   ^
>> number_decimalquantity.cpp:333:14: error: expected primary-expression
>> before ‘:’ token
>>  if (std::signbit(n) != 0) {
>>   ^
>> number_decimalquantity.cpp:337:9: error: ‘__builtin_isnan’ is not a
>> member of ‘std’
>>  if (std::isnan(n) != 0) {
>>  ^
>> number_decimalquantity.cpp:337:9: note: suggested alternative:
>> : note:   ‘__builtin_isnan’
>> number_decimalquantity.cpp:339:16: error: ‘__builtin_isfinite’ is not a
>> member of ‘std’
>>  } else if (std::isfinite(n) == 0) {
>> ^
>> number_decimalquantity.cpp:339:16: note: suggested alternative:
>> : note:   ‘__builtin_isfinite’
>> *** Failed compilation command follows: --
>> 
>> g++ -D_REE

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

[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.
> drv-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::DecimalQuantity::setToDouble(double)’:
> number_decimalquantity.cpp:333:9: error: ‘_Generic’ is not a member of
> ‘std’
>  if (std::signbit(n) != 0) {
>  ^
> In file included from /gnu/store/nz2m4gdvgzcrkqa4xwv360iskh7syj
> 7i-gcc-5.5.0/include/c++/cmath:44:0,
>  from number_decimalquantity.cpp:9:
> number_decimalquantity.cpp:333:14: error: expected primary-expression
> before ‘float’
>  if (std::signbit(n) != 0) {
>   ^
> number_decimalquantity.cpp:333:14: error: expected primary-expression
> before ‘default’
>  if (std::signbit(n) != 0) {
>   ^
> number_decimalquantity.cpp:333:14: error: expected primary-expression
> before ‘long’
>  if (std::signbit(n) != 0) {
>   ^
> number_decimalquantity.cpp:333:14: error: expected primary-expression
> before ‘:’ token
>  if (std::signbit(n) != 0) {
>   ^
> number_decimalquantity.cpp:337:9: error: ‘__builtin_isnan’ is not a
> member of ‘std’
>  if (std::isnan(n) != 0) {
>  ^
> number_decimalquantity.cpp:337:9: note: suggested alternative:
> : note:   ‘__builtin_isnan’
> number_decimalquantity.cpp:339:16: error: ‘__builtin_isfinite’ is not a
> member of ‘std’
>  } else if (std::isfinite(n) == 0) {
> ^
> number_decimalquantity.cpp:339:16: note: suggested alternative:
> : note:   ‘__builtin_isfinite’
> *** Failed compilation command follows: --
> 
> g++ -D_REENTRANT -DU_HAVE_ELF_H=1 -DU_HAVE_ATOMIC=1 -DU_HAVE_STRTOD_L=1
> -DU_HAVE_XLOCALE_H=0 -I. -I../common -DU_ATTRIBUTE_DEPRECATED=
> -DU_I18N_IMPLEMENTATION -O2 -W -Wall -pedantic -Wpointer-arith
> -Wwrite-strings -Wno-long-long -std=c++11 -c -DPIC -fPIC -o
> number_decimalquantity.o number_decimalquantity.cpp
> --- ( rebuild with "make VERBOSE=1 all" to show all parameters ) 
> make[1]: *** [../config/mh-linux:51: number_decimalquantity.o] Error 1
> make[1]: *** Waiting for unfinis

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

[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.drv-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::DecimalQuantity::setToDouble(double)’:
number_decimalquantity.cpp:333:9: error: ‘_Generic’ is not a member of ‘std’
 if (std::signbit(n) != 0) {
 ^
In file included from 
/gnu/store/nz2m4gdvgzcrkqa4xwv360iskh7syj7i-gcc-5.5.0/include/c++/cmath:44:0,
 from number_decimalquantity.cpp:9:
number_decimalquantity.cpp:333:14: error: expected primary-expression before 
‘float’
 if (std::signbit(n) != 0) {
  ^
number_decimalquantity.cpp:333:14: error: expected primary-expression before 
‘default’
 if (std::signbit(n) != 0) {
  ^
number_decimalquantity.cpp:333:14: error: expected primary-expression before 
‘long’
 if (std::signbit(n) != 0) {
  ^
number_decimalquantity.cpp:333:14: error: expected primary-expression before 
‘:’ token
 if (std::signbit(n) != 0) {
  ^
number_decimalquantity.cpp:337:9: error: ‘__builtin_isnan’ is not a member of 
‘std’
 if (std::isnan(n) != 0) {
 ^
number_decimalquantity.cpp:337:9: note: suggested alternative:
: note:   ‘__builtin_isnan’
number_decimalquantity.cpp:339:16: error: ‘__builtin_isfinite’ is not a member 
of ‘std’
 } else if (std::isfinite(n) == 0) {
^
number_decimalquantity.cpp:339:16: note: suggested alternative:
: note:   ‘__builtin_isfinite’
*** Failed compilation command follows: 
--
g++ -D_REENTRANT -DU_HAVE_ELF_H=1 -DU_HAVE_ATOMIC=1 -DU_HAVE_STRTOD_L=1 
-DU_HAVE_XLOCALE_H=0 -I. -I../common -DU_ATTRIBUTE_DEPRECATED= 
-DU_I18N_IMPLEMENTATION -O2 -W -Wall -pedantic -Wpointer-arith -Wwrite-strings 
-Wno-long-long -std=c++11 -c -DPIC -fPIC -o number_decimalquantity.o 
number_decimalquantity.cpp
--- ( rebuild with "make VERBOSE=1 all" to show all parameters ) 
make[1]: *** [../config/mh-linux:51: number_decimalquantity.o] Error 1
make[1]: *** Waiting for unfinished jobs
make[1]: Leaving directory '/tmp/guix-build-icu4c-60.1.drv-0/icu/source/i18n'
make: *** [Makefile:149: all-recursive] Error 2
phase `build' failed after 122.2 seconds
builder for `/gnu/store/8s6q5cll4knh7y0wfrbjqs2dai0x4sm2-icu4c-60.1.drv' failed 
with exit code 1
@ build-failed /gnu/store/8s6q5cll4knh7y0wfrbjqs2dai0x4sm2-icu4c-60.1.drv - 1 
builder for `/gnu/store/8s6q5cll4knh7y0wfrbjqs2dai0x4sm2-icu4c-60.1.drv' failed 
with exit code 1
guix build: error: build failed: build of 
`/gnu/store/8s6q5cll4knh7y0wfrbjqs2dai0x4sm2-icu4c-60.1.drv' failed
--8<---cut here---end--->8---

The fact that these errors are different suggests that more than one
problem may have been introduced...

I haven't tried any more recent commits on core-updates.  I am not sure
wha

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

[Gábor Boskovits]

java-testng also dies on icu4c.
It seems like we will have to fix that first to do anything else.


2017-12-03 10:58 GMT+01:00 Gábor Boskovits :

> Any news on this icu4c thing?
>
> We had a problem on core-updates, reverting 
> ee3ebf1a357bd4eb36a2fa1790a7b549cffb305a
> makes it usable, it is not the best thing we can do, but in case you meet
> with encoding related errors after rebase this is a quick fix.
> I will have a look at this java-testng failure in the meanwhile. I'll
> report back if I find something.
>
> 2017-12-02 8:06 GMT+01:00 Chris Marusich :
>
>> Gábor Boskovits  writes:
>>
>> > Hello!
>> >
>> > I've just checked the current build status of packages on hyrda. I could
>> > filter out a few that currently seems not to build anyway, we might try
>> to
>> > fix those first.
>> >
>> > I'll send a quick list:
>> >
>> > *java-htsjdk@1.129 -> newer version (2.3.0) in master, does not build;
>> > java-testng@6.12
>> > *java-plexus-container-default@1.7.1 -> does not build;
>> java-testng@6.12
>> > *kodi@18.0_alpha-6-f22d62d -> does not build; unbound 1.6.7
>> > *java-eclipse-jetty-servlet@9.4.6 -> does not build;
>> > java-eclipse-jetty-security-9.2.22
>> > *java-eclipse-jetty-servlet@9.2.22 -> does not build;
>> > java-eclipse-jetty-security-9.4.6
>> >
>> > The first one with the specific version does build, to be clear, but the
>> > newer version does not.
>> > I've extracted the log segment of those failures:
>> >
>> > 
>> 
>> 
>> 
>> > java-testng@6.12 - log extract:
>> > TestNG
>> > Total tests run: 1517, Failures: 1, Skips: 0
>> > ===
>> >
>> > Failures in  :TestNG,  :Parallelization
>> > test.thread.parallelization.ParallelByMethodsTestCase4Scenar
>> io1.verifyThatTestMethodsRunInParallelThreads()
>> > StackTrace:
>> >  java.lang.AssertionError: Expected 6 test method start event logs to
>> be in
>> > a block of methods executing in parallel. Found an event log of a
>> different
>> > type in the block being processed: [EventLog{Event:
>> > LISTENER_TEST_METHOD_START, Suite: TestSuiteC, Test:
>> > TestSuiteC-FourTestClassTest, Class:
>> > test.thread.parallelization.sample.TestClassBSixMethodsWithD
>> ataProviderOnAllMethodsAndNoDepsSample,
>> > Class instance hash code: 2118912967, Method name: testMethodB, Time of
>> > event: 1511159025654, Thread ID: 5556}, EventLog{Event:
>> > TEST_METHOD_EXECUTION, Suite: TestSuiteC, Test:
>> > TestSuiteC-FourTestClassTest, Class:
>> > test.thread.parallelization.sample.TestClassBSixMethodsWithD
>> ataProviderOnAllMethodsAndNoDepsSample,
>> > Class instance hash code: 2118912967, Method name: testMethodB, Data
>> > provider param: paramThree, Time of event: 1511159026154, Thread ID:
>> 5556},
>> > EventLog{Event: LISTENER_TEST_METHOD_START, Suite: TestSuiteC, Test:
>> > TestSuiteC-FourTestClassTest, Class:
>> > test.thread.parallelization.sample.TestClassBSixMethodsWithD
>> ataProviderOnAllMethodsAndNoDepsSample,
>> > Class instance hash code: 2118912967, Method name: testMethodA, Time of
>> > event: 1511159026244, Thread ID: 5550}, EventLog{Event:
>> > LISTENER_TEST_METHOD_START, Suite: TestSuiteC, Test:
>> > TestSuiteC-FourTestClassTest, Class:
>> > test.thread.parallelization.sample.TestClassBSixMethodsWithD
>> ataProviderOnAllMethodsAndNoDepsSample,
>> > Class instance hash code: 2118912967, Method name: testMethodF, Time of
>> > event: 1511159026244, Thread ID: 5560}, EventLog{Event:
>> > LISTENER_TEST_METHOD_START, Suite: TestSuiteC, Test:
>> > TestSuiteC-FourTestClassTest, Class:
>> > test.thread.parallelization.sample.TestClassBSixMethodsWithD
>> ataProviderOnAllMethodsAndNoDepsSample,
>> > Class instance hash code: 2118912967, Method name: testMethodC, Time of
>> > event: 1511159026244, Thread ID: 5552}, EventLog{Event:
>> > LISTENER_TEST_METHOD_START, Suite: TestSuiteC, Test:
>> > TestSuiteC-FourTestClassTest, Class:
>> > test.thread.parallelization.sample.TestClassBSixMethodsWithD
>> ataProviderOnAllMethodsAndNoDepsSample,
>> > Class instance hash code: 2118912967, Method name: testMethodE, Time of
>> > event: 1511159026244, Thread ID: 5558}] expected [true] but found
>> [false]
>> > at
>> > test.thread.parallelization.BaseParallelizationTest.verifyEv
>> entTypeForEventsLogs(Unknown
>> > Source)
>> > at
>> > test.thread.parallelization.BaseParallelizationTest.verifySi
>> multaneousTestMethodListenerStartEvents(Unknown
>> > Source)
>> > at
>> > test.thread.parallelization.BaseParallelizationTest.verifySi
>> multaneousTestMethodListenerStartEvents(Unknown
>> > Source)
>> > at
>> > test.thread.parallelization.BaseParallelizationTest.verifyPa
>> rallelTestMethodsWithNonParallelDataProvider(Unknown
>> > Source)
>> > at
>> > test.thread.parallelization.ParallelByMethodsTestCase4Scenar
>> io

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

[Gábor Boskovits]

Any news on this icu4c thing?

We had a problem on core-updates,
reverting ee3ebf1a357bd4eb36a2fa1790a7b549cffb305a makes it usable, it is
not the best thing we can do, but in case you meet with encoding related
errors after rebase this is a quick fix.
I will have a look at this java-testng failure in the meanwhile. I'll
report back if I find something.

2017-12-02 8:06 GMT+01:00 Chris Marusich :

> Gábor Boskovits  writes:
>
> > Hello!
> >
> > I've just checked the current build status of packages on hyrda. I could
> > filter out a few that currently seems not to build anyway, we might try
> to
> > fix those first.
> >
> > I'll send a quick list:
> >
> > *java-htsjdk@1.129 -> newer version (2.3.0) in master, does not build;
> > java-testng@6.12
> > *java-plexus-container-default@1.7.1 -> does not build; java-testng@6.12
> > *kodi@18.0_alpha-6-f22d62d -> does not build; unbound 1.6.7
> > *java-eclipse-jetty-servlet@9.4.6 -> does not build;
> > java-eclipse-jetty-security-9.2.22
> > *java-eclipse-jetty-servlet@9.2.22 -> does not build;
> > java-eclipse-jetty-security-9.4.6
> >
> > The first one with the specific version does build, to be clear, but the
> > newer version does not.
> > I've extracted the log segment of those failures:
> >
> > 
> 
> 
> 
> > java-testng@6.12 - log extract:
> > TestNG
> > Total tests run: 1517, Failures: 1, Skips: 0
> > ===
> >
> > Failures in  :TestNG,  :Parallelization
> > test.thread.parallelization.ParallelByMethodsTestCase4Scenario1.
> verifyThatTestMethodsRunInParallelThreads()
> > StackTrace:
> >  java.lang.AssertionError: Expected 6 test method start event logs to be
> in
> > a block of methods executing in parallel. Found an event log of a
> different
> > type in the block being processed: [EventLog{Event:
> > LISTENER_TEST_METHOD_START, Suite: TestSuiteC, Test:
> > TestSuiteC-FourTestClassTest, Class:
> > test.thread.parallelization.sample.TestClassBSixMethodsWithDataPr
> oviderOnAllMethodsAndNoDepsSample,
> > Class instance hash code: 2118912967, Method name: testMethodB, Time of
> > event: 1511159025654, Thread ID: 5556}, EventLog{Event:
> > TEST_METHOD_EXECUTION, Suite: TestSuiteC, Test:
> > TestSuiteC-FourTestClassTest, Class:
> > test.thread.parallelization.sample.TestClassBSixMethodsWithDataPr
> oviderOnAllMethodsAndNoDepsSample,
> > Class instance hash code: 2118912967, Method name: testMethodB, Data
> > provider param: paramThree, Time of event: 1511159026154, Thread ID:
> 5556},
> > EventLog{Event: LISTENER_TEST_METHOD_START, Suite: TestSuiteC, Test:
> > TestSuiteC-FourTestClassTest, Class:
> > test.thread.parallelization.sample.TestClassBSixMethodsWithDataPr
> oviderOnAllMethodsAndNoDepsSample,
> > Class instance hash code: 2118912967, Method name: testMethodA, Time of
> > event: 1511159026244, Thread ID: 5550}, EventLog{Event:
> > LISTENER_TEST_METHOD_START, Suite: TestSuiteC, Test:
> > TestSuiteC-FourTestClassTest, Class:
> > test.thread.parallelization.sample.TestClassBSixMethodsWithDataPr
> oviderOnAllMethodsAndNoDepsSample,
> > Class instance hash code: 2118912967, Method name: testMethodF, Time of
> > event: 1511159026244, Thread ID: 5560}, EventLog{Event:
> > LISTENER_TEST_METHOD_START, Suite: TestSuiteC, Test:
> > TestSuiteC-FourTestClassTest, Class:
> > test.thread.parallelization.sample.TestClassBSixMethodsWithDataPr
> oviderOnAllMethodsAndNoDepsSample,
> > Class instance hash code: 2118912967, Method name: testMethodC, Time of
> > event: 1511159026244, Thread ID: 5552}, EventLog{Event:
> > LISTENER_TEST_METHOD_START, Suite: TestSuiteC, Test:
> > TestSuiteC-FourTestClassTest, Class:
> > test.thread.parallelization.sample.TestClassBSixMethodsWithDataPr
> oviderOnAllMethodsAndNoDepsSample,
> > Class instance hash code: 2118912967, Method name: testMethodE, Time of
> > event: 1511159026244, Thread ID: 5558}] expected [true] but found [false]
> > at
> > test.thread.parallelization.BaseParallelizationTest.
> verifyEventTypeForEventsLogs(Unknown
> > Source)
> > at
> > test.thread.parallelization.BaseParallelizationTest.
> verifySimultaneousTestMethodListenerStartEvents(Unknown
> > Source)
> > at
> > test.thread.parallelization.BaseParallelizationTest.
> verifySimultaneousTestMethodListenerStartEvents(Unknown
> > Source)
> > at
> > test.thread.parallelization.BaseParallelizationTest.
> verifyParallelTestMethodsWithNonParallelDataProvider(Unknown
> > Source)
> > at
> > test.thread.parallelization.ParallelByMethodsTestCase4Scenario1.
> verifyThatTestMethodsRunInParallelThreads(Unknown
> > Source)
> > ... Removed 27 stack frames
> >
> > phase `check' failed after 282.9 seconds
> >
> > Requires further investigation.
> >
> > 
> --

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

[Chris Marusich]

Gábor Boskovits  writes:

> Hello!
>
> I've just checked the current build status of packages on hyrda. I could
> filter out a few that currently seems not to build anyway, we might try to
> fix those first.
>
> I'll send a quick list:
>
> *java-htsjdk@1.129 -> newer version (2.3.0) in master, does not build;
> java-testng@6.12
> *java-plexus-container-default@1.7.1 -> does not build; java-testng@6.12
> *kodi@18.0_alpha-6-f22d62d -> does not build; unbound 1.6.7
> *java-eclipse-jetty-servlet@9.4.6 -> does not build;
> java-eclipse-jetty-security-9.2.22
> *java-eclipse-jetty-servlet@9.2.22 -> does not build;
> java-eclipse-jetty-security-9.4.6
>
> The first one with the specific version does build, to be clear, but the
> newer version does not.
> I've extracted the log segment of those failures:
>
> 
> java-testng@6.12 - log extract:
> TestNG
> Total tests run: 1517, Failures: 1, Skips: 0
> ===
>
> Failures in  :TestNG,  :Parallelization
> test.thread.parallelization.ParallelByMethodsTestCase4Scenario1.verifyThatTestMethodsRunInParallelThreads()
> StackTrace:
>  java.lang.AssertionError: Expected 6 test method start event logs to be in
> a block of methods executing in parallel. Found an event log of a different
> type in the block being processed: [EventLog{Event:
> LISTENER_TEST_METHOD_START, Suite: TestSuiteC, Test:
> TestSuiteC-FourTestClassTest, Class:
> test.thread.parallelization.sample.TestClassBSixMethodsWithDataProviderOnAllMethodsAndNoDepsSample,
> Class instance hash code: 2118912967, Method name: testMethodB, Time of
> event: 1511159025654, Thread ID: 5556}, EventLog{Event:
> TEST_METHOD_EXECUTION, Suite: TestSuiteC, Test:
> TestSuiteC-FourTestClassTest, Class:
> test.thread.parallelization.sample.TestClassBSixMethodsWithDataProviderOnAllMethodsAndNoDepsSample,
> Class instance hash code: 2118912967, Method name: testMethodB, Data
> provider param: paramThree, Time of event: 1511159026154, Thread ID: 5556},
> EventLog{Event: LISTENER_TEST_METHOD_START, Suite: TestSuiteC, Test:
> TestSuiteC-FourTestClassTest, Class:
> test.thread.parallelization.sample.TestClassBSixMethodsWithDataProviderOnAllMethodsAndNoDepsSample,
> Class instance hash code: 2118912967, Method name: testMethodA, Time of
> event: 1511159026244, Thread ID: 5550}, EventLog{Event:
> LISTENER_TEST_METHOD_START, Suite: TestSuiteC, Test:
> TestSuiteC-FourTestClassTest, Class:
> test.thread.parallelization.sample.TestClassBSixMethodsWithDataProviderOnAllMethodsAndNoDepsSample,
> Class instance hash code: 2118912967, Method name: testMethodF, Time of
> event: 1511159026244, Thread ID: 5560}, EventLog{Event:
> LISTENER_TEST_METHOD_START, Suite: TestSuiteC, Test:
> TestSuiteC-FourTestClassTest, Class:
> test.thread.parallelization.sample.TestClassBSixMethodsWithDataProviderOnAllMethodsAndNoDepsSample,
> Class instance hash code: 2118912967, Method name: testMethodC, Time of
> event: 1511159026244, Thread ID: 5552}, EventLog{Event:
> LISTENER_TEST_METHOD_START, Suite: TestSuiteC, Test:
> TestSuiteC-FourTestClassTest, Class:
> test.thread.parallelization.sample.TestClassBSixMethodsWithDataProviderOnAllMethodsAndNoDepsSample,
> Class instance hash code: 2118912967, Method name: testMethodE, Time of
> event: 1511159026244, Thread ID: 5558}] expected [true] but found [false]
> at
> test.thread.parallelization.BaseParallelizationTest.verifyEventTypeForEventsLogs(Unknown
> Source)
> at
> test.thread.parallelization.BaseParallelizationTest.verifySimultaneousTestMethodListenerStartEvents(Unknown
> Source)
> at
> test.thread.parallelization.BaseParallelizationTest.verifySimultaneousTestMethodListenerStartEvents(Unknown
> Source)
> at
> test.thread.parallelization.BaseParallelizationTest.verifyParallelTestMethodsWithNonParallelDataProvider(Unknown
> Source)
> at
> test.thread.parallelization.ParallelByMethodsTestCase4Scenario1.verifyThatTestMethodsRunInParallelThreads(Unknown
> Source)
> ... Removed 27 stack frames
>
> phase `check' failed after 282.9 seconds
>
> Requires further investigation.
>
> -
>
> unbound@1.6.7 - log extract
> libtool: link: gcc -I.
> -I/gnu/store/ks27x0mf95gir0cdgb9h573xbava6v1k-python-3.5.3/include/python3.5m
> -I/gnu/store/m0m6bwzi8lx7kv8zbn3hjrim6flmgnf4-openssl-1.0.2l/include
> -I/gnu/store/ldkwm8hwhknpx6651yjgc1231nh8234d-libevent-2.1.8/include
> -I/gnu/store/wdlhrg370gm42s7ggyhnvnb4xrzpls1x-expat-2.2.1/include -g -O2
> -flto -pthread -o testbound .libs/testbound.o .libs/replay.o
> .libs/fake_event.o .libs/testpkts.o .libs/worker.o .libs/acl_li

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

[Gábor Boskovits]

Hello!

I've just checked the current build status of packages on hyrda. I could
filter out a few that currently seems not to build anyway, we might try to
fix those first.

I'll send a quick list:

*java-htsjdk@1.129 -> newer version (2.3.0) in master, does not build;
java-testng@6.12
*java-plexus-container-default@1.7.1 -> does not build; java-testng@6.12
*kodi@18.0_alpha-6-f22d62d -> does not build; unbound 1.6.7
*java-eclipse-jetty-servlet@9.4.6 -> does not build;
java-eclipse-jetty-security-9.2.22
*java-eclipse-jetty-servlet@9.2.22 -> does not build;
java-eclipse-jetty-security-9.4.6

The first one with the specific version does build, to be clear, but the
newer version does not.
I've extracted the log segment of those failures:


java-testng@6.12 - log extract:
TestNG
Total tests run: 1517, Failures: 1, Skips: 0
===

Failures in  :TestNG,  :Parallelization
test.thread.parallelization.ParallelByMethodsTestCase4Scenario1.verifyThatTestMethodsRunInParallelThreads()
StackTrace:
 java.lang.AssertionError: Expected 6 test method start event logs to be in
a block of methods executing in parallel. Found an event log of a different
type in the block being processed: [EventLog{Event:
LISTENER_TEST_METHOD_START, Suite: TestSuiteC, Test:
TestSuiteC-FourTestClassTest, Class:
test.thread.parallelization.sample.TestClassBSixMethodsWithDataProviderOnAllMethodsAndNoDepsSample,
Class instance hash code: 2118912967, Method name: testMethodB, Time of
event: 1511159025654, Thread ID: 5556}, EventLog{Event:
TEST_METHOD_EXECUTION, Suite: TestSuiteC, Test:
TestSuiteC-FourTestClassTest, Class:
test.thread.parallelization.sample.TestClassBSixMethodsWithDataProviderOnAllMethodsAndNoDepsSample,
Class instance hash code: 2118912967, Method name: testMethodB, Data
provider param: paramThree, Time of event: 1511159026154, Thread ID: 5556},
EventLog{Event: LISTENER_TEST_METHOD_START, Suite: TestSuiteC, Test:
TestSuiteC-FourTestClassTest, Class:
test.thread.parallelization.sample.TestClassBSixMethodsWithDataProviderOnAllMethodsAndNoDepsSample,
Class instance hash code: 2118912967, Method name: testMethodA, Time of
event: 1511159026244, Thread ID: 5550}, EventLog{Event:
LISTENER_TEST_METHOD_START, Suite: TestSuiteC, Test:
TestSuiteC-FourTestClassTest, Class:
test.thread.parallelization.sample.TestClassBSixMethodsWithDataProviderOnAllMethodsAndNoDepsSample,
Class instance hash code: 2118912967, Method name: testMethodF, Time of
event: 1511159026244, Thread ID: 5560}, EventLog{Event:
LISTENER_TEST_METHOD_START, Suite: TestSuiteC, Test:
TestSuiteC-FourTestClassTest, Class:
test.thread.parallelization.sample.TestClassBSixMethodsWithDataProviderOnAllMethodsAndNoDepsSample,
Class instance hash code: 2118912967, Method name: testMethodC, Time of
event: 1511159026244, Thread ID: 5552}, EventLog{Event:
LISTENER_TEST_METHOD_START, Suite: TestSuiteC, Test:
TestSuiteC-FourTestClassTest, Class:
test.thread.parallelization.sample.TestClassBSixMethodsWithDataProviderOnAllMethodsAndNoDepsSample,
Class instance hash code: 2118912967, Method name: testMethodE, Time of
event: 1511159026244, Thread ID: 5558}] expected [true] but found [false]
at
test.thread.parallelization.BaseParallelizationTest.verifyEventTypeForEventsLogs(Unknown
Source)
at
test.thread.parallelization.BaseParallelizationTest.verifySimultaneousTestMethodListenerStartEvents(Unknown
Source)
at
test.thread.parallelization.BaseParallelizationTest.verifySimultaneousTestMethodListenerStartEvents(Unknown
Source)
at
test.thread.parallelization.BaseParallelizationTest.verifyParallelTestMethodsWithNonParallelDataProvider(Unknown
Source)
at
test.thread.parallelization.ParallelByMethodsTestCase4Scenario1.verifyThatTestMethodsRunInParallelThreads(Unknown
Source)
... Removed 27 stack frames

phase `check' failed after 282.9 seconds

Requires further investigation.

-

unbound@1.6.7 - log extract
libtool: link: gcc -I.
-I/gnu/store/ks27x0mf95gir0cdgb9h573xbava6v1k-python-3.5.3/include/python3.5m
-I/gnu/store/m0m6bwzi8lx7kv8zbn3hjrim6flmgnf4-openssl-1.0.2l/include
-I/gnu/store/ldkwm8hwhknpx6651yjgc1231nh8234d-libevent-2.1.8/include
-I/gnu/store/wdlhrg370gm42s7ggyhnvnb4xrzpls1x-expat-2.2.1/include -g -O2
-flto -pthread -o testbound .libs/testbound.o .libs/replay.o
.libs/fake_event.o .libs/testpkts.o .libs/worker.o .libs/acl_list.o
.libs/daemon.o .libs/stats.o .libs/shm_main.o .libs/dns.o .libs/infra.o
.libs/rrset.o .libs/dname.o .libs/msgencode.o .libs/as112.o
.libs/msgparse.o .libs/msgreply.o .libs/packed_rrset.o .libs/iterat

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

[Efraim Flashner]

On Wed, Nov 29, 2017 at 10:58:48PM -0800, Chris Marusich wrote:
> Chris Marusich  writes:
> 
> >> 1) Confirm that these packages build before making changes.  If any
> >> fail, fix them first if possible.
> >> 
> >> ...
> >> 
> >> I'm going to try step (1) tonight on my laptop.  Is there a way to check
> >> their build status on Hydra, I wonder?  I'm planning to just do it in a
> >> simple shell one-liner like the following:
> >>
> >> for pkg in $( >> success: $pkg >> /tmp/log; else echo failure: $pkg >> /tmp/log; fi; done
> 
> I tried something like this, and GuixSD crashed while it was building
> the packages...  Specifically, the following morning, I checked my
> computer and found that the screen remained blank, the HDD I/O LED was
> constantly on (as if tons of disk access was taking place), and not even
> pressing the capslock key would turn on the capslock key LED.  I decided
> to let the computer sit for the day, but when I got home 8 hours later,
> nothing had changed.  I power cycled my machine, and after it booted, I
> found that during the night, my kernel had logged an Oops along with a
> BUG in /var/log/messages, but I don't really know why it occurred.
> 
> So, I don't know if any of the packages built successfully or not.  I'll
> try again tonight, and this time I'll store the results somewhere where
> I'll (hopefully) be able to see how far it got before crashing.
> Hopefully it won't crash this time...  If you know of an easier way to
> check the build status of packages that will be impacted by an icedtea
> change, please let me know.
> 
> -- 
> Chris

my build script is a little different:
guix package -A | cut -f1,2 | sed -e 's/\t/@/' | parallel --bar --shuf --jobs 1 
guix build --no-grafts --fallback

and you could have "guix refresh -l -e '(@ (gnu packages java) icedtea-7)'"
in place of 'guix package -A'. Mine doesn't take into account packages
that are already built or dependencies which have already failed, but it
could be loading all the packages into memory at once is too much. If it
isn't then perhaps:
guix build --no-grafts --keep-going < $(guix refresh ... | cut -f1,2 | sed -e 
's/\t/@/' )
would also work.


-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

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

[Chris Marusich]

Chris Marusich  writes:

>> 1) Confirm that these packages build before making changes.  If any
>> fail, fix them first if possible.
>> 
>> ...
>> 
>> I'm going to try step (1) tonight on my laptop.  Is there a way to check
>> their build status on Hydra, I wonder?  I'm planning to just do it in a
>> simple shell one-liner like the following:
>>
>> for pkg in $(> success: $pkg >> /tmp/log; else echo failure: $pkg >> /tmp/log; fi; done

I tried something like this, and GuixSD crashed while it was building
the packages...  Specifically, the following morning, I checked my
computer and found that the screen remained blank, the HDD I/O LED was
constantly on (as if tons of disk access was taking place), and not even
pressing the capslock key would turn on the capslock key LED.  I decided
to let the computer sit for the day, but when I got home 8 hours later,
nothing had changed.  I power cycled my machine, and after it booted, I
found that during the night, my kernel had logged an Oops along with a
BUG in /var/log/messages, but I don't really know why it occurred.

So, I don't know if any of the packages built successfully or not.  I'll
try again tonight, and this time I'll store the results somewhere where
I'll (hopefully) be able to see how far it got before crashing.
Hopefully it won't crash this time...  If you know of an easier way to
check the build status of packages that will be impacted by an icedtea
change, please let me know.

-- 
Chris


signature.asc
Description: PGP signature

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

[Ricardo Wurmus]

Chris Marusich  writes:

>> As first step it is not needed to remove #:jdk icedtea-8 references,
>> because I think that simply becomes a noop. Am I right here?
>> That can be done as the last step before merging, I guess.
>
> I think that's right, but I haven't looked closely yet, and Ricardo may
> know more.

Yes, that’s correct.  I’m just thinking that it would be more elegant to
remove them in the same commit that changes the defaults.

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

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

[Ricardo Wurmus]

Hi Gábor,

> We could split the bootsrap part out of java.scm, to something like
> java-bootstrap.scm.

I agree that it would be good to separate the language bootstrap from
all other packages.

> The have a file like java-checkpoint.scm only with definitions like (define
> idectea8 icedtea8-bootstrap).
> This would make the checkpoints we discussed on  the Reproducible Build
> Summit more visible, and explicitly declare which packages are the real
> base of java. We do not allow using java-bootstrap from anywhere else, but
> from the checkpoint.

I don’t know if using a separate module would be necessary here.  The
primary checkpoint for Java is the JDK and Ant, and all that the
bootstrap module would have to provide is these two packages.

> Another thing we could is have something like java-defaults.scm with
> definitions like (define icedtea icedtea8). This would make default
> settings more visible, and might server as the basis of an alternatives
> like system.

I’d rather not start a new module just for that, to be honest.  We
already have these definitions for the default GCCs and fortran compilers.

> Also with java9 coming we should be prepared to do another iteration on
> this, and a cleaner sturcture might make that easier.

This would merely add one additional step to the bootstrap chain.  Once
we decide to switch to that version, we just update the defaults again.

But I agree that a cleaner module structure could help.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

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

[Gábor Boskovits]

Hello!

I have a few idea, which could be done in parallel with this.

I don't know if they worth considering, but here they are anyways.

We could split the bootsrap part out of java.scm, to something like
java-bootstrap.scm.
We should stick here to specify versions used and not allow defaults.
We could name packages which will be used by the final consumer like
foo-bootstrap.
The have a file like java-checkpoint.scm only with definitions like (define
idectea8 icedtea8-bootstrap).
This would make the checkpoints we discussed on  the Reproducible Build
Summit more visible, and explicitly declare which packages are the real
base of java. We do not allow using java-bootstrap from anywhere else, but
from the checkpoint.

Another thing we could is have something like java-defaults.scm with
definitions like (define icedtea icedtea8). This would make default
settings more visible, and might server as the basis of an alternatives
like system.

Later these steps could be done on other languages, making the trust base
more explicit, showing where we need bootstrapping done, and which pacakges
should be bootstrapped.

For organizational purposes whe might create a directory for defaults,
checkpoints and bootstraps.

Also with java9 coming we should be prepared to do another iteration on
this, and a cleaner sturcture might make that easier.


2017-11-29 8:12 GMT+01:00 Chris Marusich :

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

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

[Chris Marusich]

Chris Marusich  writes:

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

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

-- 
Chris


signature.asc
Description: PGP signature

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

[Chris Marusich]

Gábor Boskovits  writes:

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

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

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

So, I think we should probably do the following:

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

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

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

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

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

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

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

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

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

-- 
Chris


signature.asc
Description: PGP signature

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

[Gábor Boskovits]

Ok, I just made a branch, basically only changing that single line in
java.scm.
It's base on current core-updates.

You can clone from: https://github.com/Boskovits/guix.git
branch: change-default-icedtea-8.

How do we know where you need further assistance with that?

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

2017-11-24 11:15 GMT+01:00 Ricardo Wurmus :

>
> Hi Gábor,
>
> > I guess we could just flip that to icedtea-8, and check what still works.
> > That would flip the version in the build system also, as it uses
> "icedtea".
>
> Exactly.  The call for help is really about dealing with the fallout
> from this change.  I’ve attempted this some time ago when we still had
> a much smaller set of Java packages, but it’s too much to check all of
> the packages by myself.
>
> > Should I check which packages are affected in advance, or just go with
> the
> > build and see what does not work?
>
> For some packages it’s feasible to do this immediately before pushing.
> It’s also good to review the weird hacks that were sometimes necessary,
> and check if they are still needed.
>
> We also need to confirm that the generated build.xml files have the
> appropriate “source” and “target” version specifiers.
>
> But mostly we can just change the default “icedtea” and remove “#:jdk
> ,icedtea-8” from all packages.  I’d like to avoid having to add “#:jdk
> ,icedtea-7” to any of the packages; finding fixes would be preferrable.
>
> --
> Ricardo
>
> GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
> https://elephly.net
>
>
>

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

[Ricardo Wurmus]

Hi Gábor,

> I guess we could just flip that to icedtea-8, and check what still works.
> That would flip the version in the build system also, as it uses "icedtea".

Exactly.  The call for help is really about dealing with the fallout
from this change.  I’ve attempted this some time ago when we still had
a much smaller set of Java packages, but it’s too much to check all of
the packages by myself.

> Should I check which packages are affected in advance, or just go with the
> build and see what does not work?

For some packages it’s feasible to do this immediately before pushing.
It’s also good to review the weird hacks that were sometimes necessary,
and check if they are still needed.

We also need to confirm that the generated build.xml files have the
appropriate “source” and “target” version specifiers.

But mostly we can just change the default “icedtea” and remove “#:jdk
,icedtea-8” from all packages.  I’d like to avoid having to add “#:jdk
,icedtea-7” to any of the packages; finding fixes would be preferrable.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

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

[Gábor Boskovits]

Hello!

I just run a quick grep to see which files might be interesting.

We use ant-build-system in:
axoloti.scm *
bioinformatics.scm *
compression.scm *
icu4c.scm
java.scm *
libusb.scm *
music.scm *
textutlis.scm
uml.scm *
version-control.scm *
web.scm *
xml.scm

Only the ant-build system uses icedtea among build systems.

Icedtea is explicitly metioned in the ones maked with *, and:
kodi.scm
math.scm
ruby.scm

We have a definition in place where currently icedtea is defined to be
icedtea-7.
I guess we could just flip that to icedtea-8, and check what still works.
That would flip the version in the build system also, as it uses "icedtea".

Should I check which packages are affected in advance, or just go with the
build and see what does not work?


2017-11-22 18:03 GMT+01:00 Chris Marusich :

> Ricardo Wurmus  writes:
>
> > Chris Marusich  writes:
> >
> >> Ricardo Wurmus  writes:
> >>
> >>> Hi Guix,
> >>>
> >>> some of our Java packages now only build with icedtea-8.  To avoid
> >>> incompatibilities we should make icedtea-8 the default and make sure
> >>> that all packages still build with that version.
> >>>
> >>> Who would like to help with this?  We can do this in a separate branch
> >>> and build it on berlin.guixsd.org.
> > […]
> >>
> >> I'd like to help with this.  Do we just need to update various java
> >> package definitions to use the most recent icedtea-8, and debug any
> >> issues that might arise?  Or did you mean something else?
> >
> > Yes, that’s pretty much it.  I remember that some of the early Java
> > packages I added could not be built with icedtea-8.  In those cases it
> > may be sufficient to set the compiler source version to 1.7 while still
> > using icedtea-8.
> >
> > I’d be happy if you could give this a try in a new branch.  Once we have
> > a branch we can build I’ll update the Cuirass specs on berlin.guixsd.org
> > to build the Java packages and their dependencies from the new branch.
> > Let’s base this on core-updates.
>
> OK, I'll find some time to work on this in the coming days.  I'll send
> you an update by the end of this month at the latest.
>
> --
> Chris
>

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

[Chris Marusich]

Ricardo Wurmus  writes:

> Chris Marusich  writes:
>
>> Ricardo Wurmus  writes:
>>
>>> Hi Guix,
>>>
>>> some of our Java packages now only build with icedtea-8.  To avoid
>>> incompatibilities we should make icedtea-8 the default and make sure
>>> that all packages still build with that version.
>>>
>>> Who would like to help with this?  We can do this in a separate branch
>>> and build it on berlin.guixsd.org.
> […]
>>
>> I'd like to help with this.  Do we just need to update various java
>> package definitions to use the most recent icedtea-8, and debug any
>> issues that might arise?  Or did you mean something else?
>
> Yes, that’s pretty much it.  I remember that some of the early Java
> packages I added could not be built with icedtea-8.  In those cases it
> may be sufficient to set the compiler source version to 1.7 while still
> using icedtea-8.
>
> I’d be happy if you could give this a try in a new branch.  Once we have
> a branch we can build I’ll update the Cuirass specs on berlin.guixsd.org
> to build the Java packages and their dependencies from the new branch.
> Let’s base this on core-updates.

OK, I'll find some time to work on this in the coming days.  I'll send
you an update by the end of this month at the latest.

-- 
Chris


signature.asc
Description: PGP signature

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

[Ricardo Wurmus]

Chris Marusich  writes:

> Ricardo Wurmus  writes:
>
>> Hi Guix,
>>
>> some of our Java packages now only build with icedtea-8.  To avoid
>> incompatibilities we should make icedtea-8 the default and make sure
>> that all packages still build with that version.
>>
>> Who would like to help with this?  We can do this in a separate branch
>> and build it on berlin.guixsd.org.
[…]
>
> I'd like to help with this.  Do we just need to update various java
> package definitions to use the most recent icedtea-8, and debug any
> issues that might arise?  Or did you mean something else?

Yes, that’s pretty much it.  I remember that some of the early Java
packages I added could not be built with icedtea-8.  In those cases it
may be sufficient to set the compiler source version to 1.7 while still
using icedtea-8.

I’d be happy if you could give this a try in a new branch.  Once we have
a branch we can build I’ll update the Cuirass specs on berlin.guixsd.org
to build the Java packages and their dependencies from the new branch.
Let’s base this on core-updates.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

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

[Chris Marusich]

Ricardo Wurmus  writes:

> Hi Guix,
>
> some of our Java packages now only build with icedtea-8.  To avoid
> incompatibilities we should make icedtea-8 the default and make sure
> that all packages still build with that version.
>
> Who would like to help with this?  We can do this in a separate branch
> and build it on berlin.guixsd.org.
>
> --
> Ricardo
>

I'd like to help with this.  Do we just need to update various java
package definitions to use the most recent icedtea-8, and debug any
issues that might arise?  Or did you mean something else?

-- 
Chris


signature.asc
Description: PGP signature

java: switch to icedtea-8 as default JDK

[Ricardo Wurmus]

Hi Guix,

some of our Java packages now only build with icedtea-8.  To avoid
incompatibilities we should make icedtea-8 the default and make sure
that all packages still build with that version.

Who would like to help with this?  We can do this in a separate branch
and build it on berlin.guixsd.org.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net