Bug#945961: xz-utils: FTBFS: cannot stat 'debian/tmp/usr/lib/x86_64-linux-gnu/liblzma.so.*'

[Tiago Daitx]

On Thu, 9 Apr 2020 16:35:13 +0200 Sebastian Andrzej Siewior
 wrote:
> I suggested already something in [0]. Back then we were hoping for some
> feedback from the debhelper team.
> Now I was just asking if Jonathan is handling this and/or if we could
> also bump to current upstream version while at it.
>
> [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945961#10

As Dimitri pointed out we have also been affected by this but in
Ubuntu - we found it out recently when doing archive rebuilds on
Focal. The proposed fix in #10 does workaround the issue and it is not
necessary to change the build-arch rules as Dimitri suggested.

I do wonder if this is in fact a regression in debhelper. I tracked it
down to debhelper 12.4 to 12.5 and while I haven't been able to
pinpoint exactly what particular change there is causing it I believe
it is in how double colon rules are being interpreted. It seems the
debhelper changes somehow fail to detect the build-arch rules.

Unless someone knows enough perl to dig into debhelper changes between
12.4 and 12.5 and check if that is in fact a regression, I would
suggest to simply apply the proposed change in comment #10.

Thanks for your help =)

Tiago Daitx

Bug#926180: scilab: FTBFS on all - New trouble

[Tiago Daitx]

On Tue, 14 May 2019 00:39:07 +0200 Alexis Murzeau  wrote:
> Le 13/05/2019 à 08:08, Sylvestre Ledru a écrit :
> >
> > On 12/05/2019 22:10, Julien Puydt wrote:
> >> Hi,
> >>
> >> On 12/05/2019 11:46, Alexis Murzeau wrote:
> >>
> >>> I saw that there is a bugfix release 6.0.2 with many fixes [0].
> >> I had started to package 6.0.2 on salsa already in february. I removed
> >> the patch about Linenum as that was supposed to have been reworked and
> >> fixed, and it now fails with :
> >>
> >> ocamlopt -o XML2Modelica -I ./src/modelica_compiler -I
> >> ./src/xml2modelica  nums.cmxa ./src/xml2modelica/xMLTree.ml
> >> ./src/xml2modelica/linenum.ml ./src/xml2modelica/stringParser.ml
> >> ./src/xml2modelica/stringLexer.ml ./src/xml2modelica/xMLParser.ml
> >> ./src/xml2modelica/xMLLexer.ml
> >> ./src/xml2modelica/modelicaCodeGenerator.ml
> >> ./src/xml2modelica/xML2Modelica.ml
> >> File "./src/xml2modelica/xML2Modelica.ml", line 1:
> >> Error: Files ./src/xml2modelica/xMLParser.cmx
> >>and ./src/xml2modelica/linenum.cmx
> >>make inconsistent assumptions over implementation Linenum
> >>
> >> ie : it looks like upstream's fix isn't correct.
> >
> > + upstream
> >
> > S
> >
> >
>
> Reversing the order of the includes parameters when compiling
> XML2Modelica fix the build for me, ie. including xml2modelica first:
> `-I ./src/xml2modelica -I ./src/modelica_compiler`
>
> I think ocamlopt prefer to use a part of Linenum from
> ./src/modelica_compiler and the other one from ./src/xml2modelica which
> lead to the error.
>
> But I'm not sure this is the way to handle it cleanly.
> The files "linenum.mll" are almost the same between both directories.
> The only difference is the comment at the beginning of the file.
>
> Maybe some of these "linenum.mll" file can be removed to keep only one ?

Ubuntu has packaged 6.0.2 for Disco and Eoan, please see
https://launchpad.net/ubuntu/+source/scilab
or fetch the DSC directly from
https://launchpad.net/ubuntu/+archive/primary/+sourcefiles/scilab/6.0.2-0ubuntu2/scilab_6.0.2-0ubuntu2.dsc

>
> --
> Alexis Murzeau
> PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F
>
>

Bug#906411:

[Tiago Daitx]

The underlying cause seems to be a fix in maven-shared-utils 3.2,
which was uploaded recently. The fix MSHARED-610 [1] seems to have
exposed IOException that were previously being ignored, so surefire
now needs to be updated to handle those.

I have opened a bug report upstream (SUREFIRE-1558 [2]) to let them
know about it.

References:
[1] https://issues.apache.org/jira/browse/MSHARED-610
[2] https://issues.apache.org/jira/browse/SUREFIRE-1558

-- 
Tiago Stürmer Daitx
Software Engineer
tiago.da...@canonical.com

PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com)
Fingerprint = 45D0 FE5A 8109 1E91 866E  8CA4 1931 8D5E F5B2 13BE

Bug#900912: Incident Report 9127367 : Java atk wrapper does not load any more

[Tiago Daitx]

On Thu, Jul 19, 2018 at 6:22 PM Samuel Thibault  wrote:
>
> Samuel Thibault, le jeu. 19 juil. 2018 23:13:26 +0200, a ecrit:
> > Samuel Thibault, le jeu. 19 juil. 2018 23:00:04 +0200, a ecrit:
> > > What I think is still missing is "to be loaded by
> > > java.util.ServiceLoader".  How is that supposed to happen?
> > >
> > > To make it work, Fridrich Strba says in
> > > http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2017-November/038927.html
> > > that he is apparently relinking jdk itself to include
> > > java-atk-wrapper.jar as a module. Are we really supposed to be doing
> > > that in Debian?  That's mean a circular dependency between openjdk
> > > and java-atk-wrapper... But otherwise, how are we supposed to make
> > > the jvm know that for that accessibility provider it should load
> > > java-atk-wrapper.jar?
> >
> > Or put another way: how are we supposed to make the
> > module contained in java-atk-wrapper.jar ("provides
> > javax.accessibility.AccessibilityProvider with
> > org.GNOME.Accessibility.AtkProvider;") visible to the JVM?  Is there a
> > directory where it looks for them?
>
> Of course there is the -p option and alike, but the goal is that it just
> works without the user having to specify anything. Or should Debian
> define a module path were the java-atk-wrapper package should put its
> module?  I'd be surprised that openjdk doesn't already define one, just
> like it used to define the ext/ directory for the older mechanism.
>
> Samuel

Hi Samuel,

Thanks for the quick work on this! I have seen the changes in the git
repo [1] and will build the package to see if I can get it to work
with openjdk like it used to with older ext mechanism - for now all
module examples I have seem need to be directly loaded with -p as you
stated.

It is just a guess at this time, but we might need to patch openjdk to
load mods from other locations so debian packages can use that. I
report back after doing some testing.

I'm still working on the openjdk security updates, so might take a
while to get my hands down on this.

Regards,
Tiago

[1] https://salsa.debian.org/a11y-team/java-atk-wrapper/commits/master

-- 
Tiago Stürmer Daitx
Software Engineer
tiago.da...@canonical.com

PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com)
Fingerprint = 45D0 FE5A 8109 1E91 866E  8CA4 1931 8D5E F5B2 13BE

Bug#900912: [Openjdk] Bug#900912: openjdk-10: Accessibility does not get loaded

[Tiago Daitx]

The ATK was updated to use the new interface last year by Fridrich
Strba [1,2], but it seems that upstream never updated it to include
those patches - the bugs he reported and attached patches remain open.

Might be worth to check if we can apply these to our packages.

[1] 
http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2017-November/038927.html
[2] http://mail.openjdk.java.net/pipermail/awt-dev/2017-November/013344.html

On Mon, Jul 16, 2018 at 10:15 AM Matthias Klose  wrote:
>
> On 13.07.2018 12:39, Samuel Thibault wrote:
> > Hello,
> >
> > Matthias Klose, le ven. 13 juil. 2018 12:04:42 +0200, a ecrit:
> >> this issue now has two patches, one to install the properties file, and the
> >> other to extend the class path.  Are both needed?
> >
> > Yes.
> >
> >> Can you see any compatibility issues when the accessibility stuff
> >> isn't used?
> >
> > I didn't see any.
>
> hmm, I'm not sure. the upstream issue asks instead about
>
> """
> This is a consequence of the JPMS. ATK will need to be reimplemented as a
> Service Provider, to be
> loaded by java.util.ServiceLoader. In order to do this it must provide an SPI
> which extends
> javax.accessibility.AccessibilityProvider
> See
> https://docs.oracle.com/javase/10/docs/api/java/awt/Toolkit.html#getDefaultToolkit()
> and
> https://docs.oracle.com/javase/10/docs/api/javax/accessibility/AccessibilityProvider.html
> """
>
> ___
> Mailing list: https://launchpad.net/~openjdk
> Post to : open...@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openjdk
> More help   : https://help.launchpad.net/ListHelp



--
Tiago Stürmer Daitx
Software Engineer
tiago.da...@canonical.com

PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com)
Fingerprint = 45D0 FE5A 8109 1E91 866E  8CA4 1931 8D5E F5B2 13BE

Bug#875336: FTBFS with Java 9: _ as identifier

[Tiago Daitx]

On Tue, 20 Mar 2018 23:07:13 +0800
=?UTF-8?B?5q635ZWf6IGwIHwgS2FpLUNodW5nIFlhbg==?= 
wrote:
> I just tried building it and Groovy was fine enough, but now Gradle 
> complains
>
> Theoretically, ALL Gradle packages FTBFS since the current version is too old 
> to play with Java 9's fancy version number.

Please take a look at the debdiff I attached to #873227 [1]. I would
like to get some feedback if it fixes these additional FTBFS.

[1] https://bugs.debian.org/873227

Bug#873227: Please upgrade to 4.1: Java 9 support

[Tiago Daitx]

Please see the attached debdiff to enable some basic OpenJDK 9 support
for gradle 3.4.1. The patches were downloaded from gradle upstream to
prevent the dreadful "Could not determine java version from '9.0.x'".

After applying the patches and rebuilding with OpenJDK 8, gradle can
then build itself with openjdk 9. I have also rebuild groovy, gant,
spock (FTBFS due to source/target 1.5), and dom4j (FTBFS due to
failing tests) which all previously failed.

Hopefully this should unblock #875336.

Please note that the debdiff includes the fix for #893487 for convenience.

thanks

On Fri, 25 Aug 2017 17:01:23 +0100 Chris West
 wrote:
> Source: gradle
> Version: 3.2.1-1
> Severity: normal
> User: debian-j...@lists.debian.org
> Usertags: default-java9
>
> Gradle doesn't officially support running under Java 9 until 4.1, which
> was released a fortnight ago.
>
> The version in Debian seems to actually be much better at surviving real
> builds than other random versions of Gradle I have lying around, but it
> would still be nice totally eliminate this as a java-9 blocker.
>
> Cheers,
> Chris.
>
>
>
diff -Nru gradle-3.4.1/debian/changelog gradle-3.4.1/debian/changelog
--- gradle-3.4.1/debian/changelog	2017-11-29 16:09:02.0 +0100
+++ gradle-3.4.1/debian/changelog	2018-03-19 12:19:49.0 +0100
@@ -1,3 +1,15 @@
+gradle (3.4.1-3) UNRELEASED; urgency=medium
+
+  * d/p/cast-estimated-runtime-to-long.patch: fix FTBFS due to missing cast.
+(Closes: #893487)
+  * d/p/support-running-gradle-on-jdk-10-500485df3a18.patch,
+d/p/add-test-case-for-10-internal_c1fe5e40a76b.patch,
+d/p/support-zulu9-version-number_d9c35cf9d74c.patch: prevent failures when
+building projects with openjdk 9.
+
+
+ -- Tiago Stürmer Daitx   Mon, 19 Mar 2018 11:19:49 +
+
 gradle (3.4.1-2) experimental; urgency=medium
 
   * Team upload.
diff -Nru gradle-3.4.1/debian/patches/add-test-case-for-10-internal_c1fe5e40a76b.patch gradle-3.4.1/debian/patches/add-test-case-for-10-internal_c1fe5e40a76b.patch
--- gradle-3.4.1/debian/patches/add-test-case-for-10-internal_c1fe5e40a76b.patch	1970-01-01 01:00:00.0 +0100
+++ gradle-3.4.1/debian/patches/add-test-case-for-10-internal_c1fe5e40a76b.patch	2018-03-19 12:19:49.0 +0100
@@ -0,0 +1,21 @@
+From c1fe5e40a76b79a98e8916c2ce3b4e1e6ed3f343 Mon Sep 17 00:00:00 2001
+From: Cedric Champeau 
+Date: Thu, 13 Jul 2017 16:16:46 +0200
+Subject: [PATCH] Add test case for `10-internal`
+
+---
+ .../base-services/src/test/groovy/org/gradle/api/JavaVersionSpec.groovy  | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/subprojects/base-services/src/test/groovy/org/gradle/api/JavaVersionSpec.groovy b/subprojects/base-services/src/test/groovy/org/gradle/api/JavaVersionSpec.groovy
+index 75459ed3f06..fbb243ba992 100644
+--- a/subprojects/base-services/src/test/groovy/org/gradle/api/JavaVersionSpec.groovy
 b/subprojects/base-services/src/test/groovy/org/gradle/api/JavaVersionSpec.groovy
+@@ -65,6 +65,7 @@ public class JavaVersionSpec extends Specification {
+ JavaVersion.toVersion("9-ea") == JavaVersion.VERSION_1_9
+ 
+ JavaVersion.toVersion("10-ea") == JavaVersion.VERSION_1_10
++JavaVersion.toVersion("10-internal") == JavaVersion.VERSION_1_10
+ }
+ 
+ def convertClassVersionToJavaVersion() {
diff -Nru gradle-3.4.1/debian/patches/cast-estimated-runtime-to-long.patch gradle-3.4.1/debian/patches/cast-estimated-runtime-to-long.patch
--- gradle-3.4.1/debian/patches/cast-estimated-runtime-to-long.patch	1970-01-01 01:00:00.0 +0100
+++ gradle-3.4.1/debian/patches/cast-estimated-runtime-to-long.patch	2018-03-19 12:15:47.0 +0100
@@ -0,0 +1,22 @@
+Description: gradle 3.4.1 FTBFS with a missing cast to long
+ estimatedRuntime must be cast to long otherwise gradle 3.4.1 FTBFS with
+ buildSrc/src/main/groovy/org/gradle/testing/DistributedPerformanceTest.groovy:
+ 134: [Static type checking] - Cannot assign value of type java.math.BigDecimal
+ to variable of type long.
+Author: Tiago Stürmer Daitx 
+Bug-Debian: https://bugs.debian.org/893487
+Forwarded: no
+Last-Update: 2018-03-19
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/buildSrc/src/main/groovy/org/gradle/testing/DistributedPerformanceTest.groovy
 b/buildSrc/src/main/groovy/org/gradle/testing/DistributedPerformanceTest.groovy
+@@ -131,7 +131,7 @@ class DistributedPerformanceTest extends
+ def scenarios = scenarioList.readLines()
+ .collect { line ->
+ def parts = Splitter.on(';').split(line).toList()
+-new Scenario(id : parts[0], estimatedRuntime: new BigDecimal(parts[1]), templates: parts.subList(2, parts.size()))
++new Scenario(id : parts[0], estimatedRuntime: new BigDecimal(parts[1]) as long, templates: parts.subList(2, parts.size()))
+ }
+ .sort{ 

Bug#887785: javacc-maven-plugin and build-rdeps FTBFS with jtb 1.4.12-1

[Tiago Daitx]

This is caused by a groupId change in 1.4.12-1 where it was changed
from "edu.ucla.cs.compilers" [1] to "edu.purdue.cs" [2].

Please see bug #891893 [3] for more information.

Regards,
Tiago

[1] 
https://anonscm.debian.org/cgit/collab-maint/jtb.git/tree/debian/pom.xml?id=cffddde94d57ef60f7415f8c8d400a75ba4c0f30
[2] 
https://anonscm.debian.org/cgit/collab-maint/jtb.git/tree/pom.xml?id=19bafc71af2bdb92a0abe47b01a0aa8504945cab
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891893

Bug#831081:

[Tiago Daitx]

GCC 6 abs to std::abs fix accepted and committed upstream:
https://github.com/timschmidt/repsnapper/commit/93dde1ef83c0c1c555f3f1ca8ff477d14d29a1e9

Original pull request: https://github.com/timschmidt/repsnapper/pull/119

Attached patch and a debdiff, the debdiff includes a workaround for
bug #810907 (avoids yet another FTBFS on powerpc/ppc64el).

-- 
Tiago Stürmer Daitx
Software Engineer
tiago.da...@canonical.com

PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com)
Fingerprint = 45D0 FE5A 8109 1E91 866E  8CA4 1931 8D5E F5B2 13BE


repsnapper_2.4a0-1_repsnapper_2.4a0-1ubuntu1.debdiff
Description: Binary data
Description: resnapper FTBFS due to mismathing headers in linux-libc-dev
 The headers in linux-libc-dev are different in powerpc/ppc64el compared
 to other archs, they seems to be missing include clauses to the 
 header under the asm-generic/ directory.
 This patch works around that by explicitly including both headers under
 asm-generic.
 Note that the include of arm/termbits.h had to be removed because it
 causes yet another conflict, this time due to the redefinition of types
 termios and ktermios, which also only affects powepc/ppc64el.
 
Author: Tiago Stürmer Daitx 
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810907
Bug-Ubuntu: https://bugs.launchpad.net/debian/+source/repsnapper/+bug/1619100
Forwarded: https://bugs.launchpad.net/bugs/1619446
Last-Update: 2016-09-01
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- a/src/printer/custom_baud.cpp
+++ b/src/printer/custom_baud.cpp
@@ -6,7 +6,8 @@
 #include 
 #include 
 #include 
-#include 
+#include 
+#include 
 #endif
 
 bool set_custom_baudrate( int device_fd, int baudrate ) {

Bug#810907: repsnapper: FTBFS on ppc64el: termios problems

[Tiago Daitx]

On Sun, 14 Feb 2016 18:39:49 +0100 Andreas Beckmann  wrote:
> Followup-For: Bug #810907
> Control: found -1 2.4a0-1
> Control: severity -1 serious
> Control: tag -1 patch
>
> the same issue happens on powerpc
>
> https://buildd.debian.org/status/fetch.php?pkg=repsnapper=powerpc=2.4a0-1=1455299926
> https://buildd.debian.org/status/fetch.php?pkg=repsnapper=ppc64el=2.4a0-1=1455299989
>

I have modified the original patch with a workaround that works for
all archs in Ubuntu [1].

Additionally, the attached debdiff also includes a fix for FTBFS that
happens when building with gcc 6 [2].

There is an open bug report against linux on Ubuntu due to the
mismatching headers between powerpc/ppc64el and the other archs, which
is the actual reason for this particular FTBFS.

Ubuntu bugs:
[1] https://bugs.launchpad.net/debian/+source/repsnapper/+bug/1619100
[2] https://bugs.launchpad.net/ubuntu/+source/repsnapper/+bug/1619289
[3] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1619446

thanks


repsnapper_2.4a0-1_repsnapper_2.4a0-1ubuntu1.debdiff
Description: Binary data
Description: resnapper FTBFS due to mismathing headers in linux-libc-dev
 The headers in linux-libc-dev are different in powerpc/ppc64el compared
 to other archs, they seems to be missing include clauses to the 
 header under the asm-generic/ directory.
 This patch works around that by explicitly including both headers under
 asm-generic.
 Note that the include of arm/termbits.h had to be removed because it
 causes yet another conflict, this time due to the redefinition of types
 termios and ktermios, which also only affects powepc/ppc64el.
 
Author: Tiago Stürmer Daitx 
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810907
Bug-Ubuntu: https://bugs.launchpad.net/debian/+source/repsnapper/+bug/1619100
Forwarded: not-needed
Last-Update: 2016-09-01
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- a/src/printer/custom_baud.cpp
+++ b/src/printer/custom_baud.cpp
@@ -6,7 +6,8 @@
 #include 
 #include 
 #include 
-#include 
+#include 
+#include 
 #endif
 
 bool set_custom_baudrate( int device_fd, int baudrate ) {

Bug#793137: Also affects openscad - #797816

[Tiago Daitx]

The same issue has been reported in openscad for armhf. See
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797816

-- 
Tiago Stürmer Daitx
Software Engineer
tiago.da...@canonical.com