Bug#1033058: Booting mini.iso : kernel hangs on ppc64el

[Frédéric Bonnard]

Thank you so much Cyril!

> That being said, we don't have all modules shipped in the installer, and
> some other module might be available and used in the installed system
> (e.g. dedicated driver as opposed to fbdev during a graphical install on
> amd64), which can explain differences. The bootloader configuration
> might be different too.
> 
> As you suggested, this is a regression via a7f0ec26cd, first shipped in
> v6.1.12, which didn't account for the disappearing of-display device
> node in the framebuffer driver. I've tested a trivial patch (see MR)
> and a netboot mini.iso d-i build (similar to daily builds, against udebs
> from unstable) gives me the installer's interface. Available for 15 days
> at: https://people.debian.org/~kibi/bug-1033058/
> 
> I'll open a bug report upstream and submit my patch there. In mainline
> master, another module (not found in 6.1.y) is affected as well, so I
> have this queued up too (but untested):

Excellent!
I was worried seeing the issue coming in rc1 of Bookworm
but also in latest snapshots of Ubuntu 23.04 ( I also
pointed Canonical to this bug and your proposed fix :
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2015994 ).

F.


signature.asc
Description: PGP signature

Bug#1033058: Booting mini.iso : kernel hangs on ppc64el

[Frédéric Bonnard]

Hi Cyril!

> Could you please guide me into reproducing this issue in QEMU? #987368
> had hints, but at least the openpower.xyz part no longer works (it's no
> longer resolving).

much simpler actually because in the current case, we won't emulate a
full baremetal PowerNV machine.
For example, using this mini.iso from 
http://d-i.debian.org/daily-images/ppc64el/daily/netboot/mini.iso
you can just try those 2 cases  (from an x86 machine or other) :

---
$ qemu-system-ppc64le -nographic -nodefaults -serial mon:stdio -cdrom 
/tmp/mini.iso
---
here we just start a ppc64le vm with no graphic card, and boot the iso.
You should reach the debian installer menu on the serial console in your
terminal (if you want to go further, provide a disk file for example).

But if you try a vm with a graphic card like so :
---
qemu-system-ppc64le  -cdrom /tmp/mini.iso
---

You'll see you won't have the d-i menu displayed on the default
graphical output.
Not sure the pointed patch is at fault, but at least it emphasis some
issue in the installer environment in the context of a framebuffer
display in qemu.
I see the installer media gets build from a kernel-image udeb which I
guess provides a different kernel runtime env from the machine installed
with linux-image on disk (which works).


F.


signature.asc
Description: PGP signature

Bug#1033058: Booting mini.iso : kernel hangs on ppc64el

[Frédéric Bonnard]

Thanks Cyril.
Another important detail ... I only get that behavior in qemu in
graphical mode.
On LPARs there is no issue. I didn't try on baremetal so far.

F.

On Tue, 21 Mar 2023 17:44:49 +0100 Cyril Brulebois  wrote:
> Frédéric Bonnard  (2023-03-17):
> > > It would be helpful to confirm which exact kernel version is getting
> > > used in both cases (last 6.1.0-4 working, and first 6.1.0-5 not
> > > working), then look at the changes between both versions, in src:linux
> > > (and resulting udebs).
> > 
> > From linux changelog (
> > https://tracker.debian.org/media/packages/l/linux/changelog-6.1.15-1 )
> > and http://snapshot.debian.org/package/linux/,
> > I see :
> > 6.1.11-1 -> Bump ABI to 4 
> > http://snapshot.debian.org/archive/debian/20230211T151657Z/
> > 6.1.12-1 -> Bump ABI to 5 
> > http://snapshot.debian.org/archive/debian/20230217T033139Z/
> > 
> > and tested from those (rebuilding the same d-i source with the 2 kernels
> > from snapshot.d.o . 6.1.12-1 clearly doesn't work.
> > I had already have a look at the kernel changelog but missed that one :
> > ---
> > linux (6.1.12-1) unstable; urgency=medium
> > ...
> > - of: Make OF framebuffer device names unique
> > ...
> > ---
> > 
> > I recompiled the kernel deb source without that one (
> > https://github.com/torvalds/linux/commit/241d2fb56a18473af5f2ff0d512992a996eb64dd.patch
> > ) and the mini.iso actually made it to the menu... and given the
> > behaviour, a framebuffer actually makes sense.
> > 
> > Now, that patch does not harm when the kernel is installed on disk.
> > But it does in the installer...
> 
> Adding the kernel team to the loop: d-i regression on ppc64el.
> 
> 
> Cheers,
> -- 
> Cyril Brulebois (k...@debian.org)<https://debamax.com/>
> D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1033058: Booting mini.iso : kernel hangs on ppc64el

[Frédéric Bonnard]

Ok found it...

> (nothing attached)

oops! .. not that much to display though (I also tried to remove the
"quiet" boot option, but it didn't change anything, it does not display
anything before getting in debian's init)

> > same happens with 
> > https://cdimage.debian.org/cdimage/weekly-builds/ppc64el/iso-cd/debian-testing-ppc64el-netinst.iso
> > I tried rebuilding d-i with kernel 6.1.0-4 and it seems to work (6.1.0-6
> > fails too).
> > Now why am I opening this bug against d-i ? If I run the d-i with
> > 6.1.0-4, I complete the installation and then runtime kernel of the
> > machine that gets installed is 6.1.0-6 and when the machine is
> > rebooted, kernel 6.1.0-6 boots fine ...
> > So I'm not sure on which side is the issue :)
> > Any clue what could be happening ?
> 
> It would be helpful to confirm which exact kernel version is getting
> used in both cases (last 6.1.0-4 working, and first 6.1.0-5 not
> working), then look at the changes between both versions, in src:linux
> (and resulting udebs).

From linux changelog (
https://tracker.debian.org/media/packages/l/linux/changelog-6.1.15-1 )
and http://snapshot.debian.org/package/linux/,
I see :
6.1.11-1 -> Bump ABI to 4 
http://snapshot.debian.org/archive/debian/20230211T151657Z/
6.1.12-1 -> Bump ABI to 5 
http://snapshot.debian.org/archive/debian/20230217T033139Z/

and tested from those (rebuilding the same d-i source with the 2 kernels
from snapshot.d.o . 6.1.12-1 clearly doesn't work.
I had already have a look at the kernel changelog but missed that one :
---
linux (6.1.12-1) unstable; urgency=medium
...
- of: Make OF framebuffer device names unique
...
---

I recompiled the kernel deb source without that one (
https://github.com/torvalds/linux/commit/241d2fb56a18473af5f2ff0d512992a996eb64dd.patch
) and the mini.iso actually made it to the menu... and given the
behaviour, a framebuffer actually makes sense.

Now, that patch does not harm when the kernel is installed on disk.
But it does in the installer...

F.


> 
> ISTR trying to boot ppc64el under QEMU requires many manual steps, but
> I'll try and figure that out, once I'm done with other topics.
> 
> 
> Cheers,
> -- 
> Cyril Brulebois (k...@debian.org)
> D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1033058: Booting mini.iso : kernel hangs on ppc64el

[Frédéric Bonnard]

Package: installation-reports

Boot method: CD
Image version: http://d-i.debian.org/daily-images/ppc64el/daily/netboot/mini.iso

Hi!
since debian-installer (20230217) uses kernel 6.1.0-5 in mini.iso, the kernel 
hangs
before I have the installer menu (see attached .png) ; same happens with 
https://cdimage.debian.org/cdimage/weekly-builds/ppc64el/iso-cd/debian-testing-ppc64el-netinst.iso
I tried rebuilding d-i with kernel 6.1.0-4 and it seems to work (6.1.0-6
fails too).
Now why am I opening this bug against d-i ? If I run the d-i with
6.1.0-4, I complete the installation and then runtime kernel of the machine that
gets installed is 6.1.0-6 and when the machine is rebooted, kernel
6.1.0-6 boots fine ...
So I'm not sure on which side is the issue :)
Any clue what could be happening ?
Thanks,

F.


signature.asc
Description: PGP signature

Bug#1022973: FTBFS on ppc64el

[Frédéric Bonnard]

Package: src:deal.ii
Version: 9.4.0-1
Control: tags -1 ftbfs
Control: tags -1 patch

--

Dear maintainer,
deal.ii fails to build atm on ppc64el on unstable. It actually fails at
link time.
Full log is here :
https://buildd.debian.org/status/fetch.php?pkg=deal.ii=ppc64el=9.4.0-1%2Bb1=1666717020=0

Link error :

---
/usr/bin/c++ -fPIC -rdynamic -fuse-ld=gold -Wl,-z,relro -ggdb -shared
-Wl,-soname,libdeal.ii.g.so.9.4.0 -o
../lib/powerpc64le-linux-gnu/libdeal.ii.g.so.9.4.0
CMakeFiles/deal.ii.g.dir/dummy.cc.o 
/usr/bin/ld.gold: stub group size is too large; retrying with 0x150
/usr/bin/ld.gold: error: invalid STB_LOCAL symbol in external symbols
/usr/bin/ld.gold: error: linker defined: multiple definition of
'0004.plt_call._ZN6dealii18deal_II_exceptions9internals20compare_for_equalityImjEEbRKT_RKT0_'
/usr/bin/ld.gold: command line: previous definition here
/usr/bin/ld.gold: error: invalid STB_LOCAL symbol in external symbols
/usr/bin/ld.gold: error: linker defined: multiple definition of
'0004.plt_call._ZN6dealii18StandardExceptions20ExcDimensionMismatchC1ERKmS3_'
/usr/bin/ld.gold: command line: previous definition here
/usr/bin/ld.gold: error: invalid STB_LOCAL symbol in external symbols
/usr/bin/ld.gold: error: linker defined: multiple definition of
'0004.plt_call._ZN6dealii18deal_II_exceptions9internals20issue_error_noreturnINS_18StandardExceptions20ExcDimens
...
---

Current unstable uses gcc-12. Trying in same build environment with
gcc-11, ld.gold does work.
Also, in a Ubuntu build environment it does work because they use
-Bsymbolic-functions by default, which once added in the Debian's build
makes linking succeed.

So for some reason gcc-12 does things differently compared to gcc-11.
I understand using -Bsymbolic-functions is more a workaround as it
has side effects on the PLT , but that can help for now (see attached
patch).

Regards,


F.
--- a/deal.ii-9.4.0/debian/rules2022-07-04 18:45:43.0 +0200
+++ b/deal.ii-9.4.0/debian/rules2022-10-28 12:09:03.891074479 +0200
@@ -3,6 +3,10 @@
 export OMPI_MCA_plm_rsh_agent=/bin/false
 export OMPI_MCA_rmaps_base_oversubscribe=1
 
+ifneq (,$(filter $(DEB_HOST_ARCH),ppc64el))
+CONFIGURE_LINKER_FLAGS=-DDEAL_II_LINKER_FLAGS="-Wl,-Bsymbolic-functions"
+endif
+
 %:
dh $@
 
@@ -14,6 +18,7 @@ export OMPI_MCA_rmaps_base_oversubscribe
 override_dh_auto_configure:
dh_auto_configure -- \
-DDEAL_II_CXX_FLAGS="-Wno-nonnull-compare -Wno-address" \
+   $(CONFIGURE_LINKER_FLAGS) \

-DCMAKE_PREFIX_PATH="/usr/lib/$(DEB_HOST_MULTIARCH)/hdf5/openmpi;/usr/include/hdf5/openmpi"
 \
-DCMAKE_BUILD_TYPE=DebugRelease \
-DDEAL_II_ALLOW_AUTODETECTION=OFF \


signature.asc
Description: PGP signature

Bug#1018039: FTBFS on ppc64el with gcc-12

[Frédéric Bonnard]

Package: src:powerpc-utils
Version: 1.3.9-1
Control: tags -1 ftbfs
Control: forwarded -1 
https://github.com/ibm-power-utilities/powerpc-utils/issues/85

--

Dear maintainer,
powerpc-utils 1.3.9-1 fails to build atm with gcc-12.
I checked latest 1.3.10 and it's roughly the same.
I've opened an issue upstream.

Regards,


F.


signature.asc
Description: PGP signature

Bug#1016647: Upgrade to new upstream release, currently 0.7.5

[Frédéric Bonnard]

Package: src:python-schema
Version: 0.6.7-4

--

Dear maintainer,
upstream python-schema introduced support for 'Literal' which the
package "organize" uses in its latest version and I'd like to update
"organize".
Would mind considering upgrading python-schema ?
Thanks a lot,
Regards,

F.


signature.asc
Description: PGP signature

Bug#1013273: [Pkg-rust-maintainers] Bug#1013273: linking problems on ppc64el

[Frédéric Bonnard]

> FWIW, if you want to test - there is an MR open for updating Debian's 
> rustc to 1.60 ;)

Awesome Fabian, that worked .. at least, on a current unstable schroot,
with squeekboard 1.18.0 (which failed just before in the very same schroot),
but with upgraded rustc .debs 1.60.0+dfsg1-1~exp1 .
Thanks,

F.


signature.asc
Description: PGP signature

Bug#1013273: [Pkg-rust-maintainers] Bug#1013273: linking problems on ppc64el

[Frédéric Bonnard]

Hi Sylvestre,
at first, I thought it may be a squeekboard coding issue too, but the fact that 
the
same code breaks with rustc 1.59 and not 1.58 made me think of a
regression (be it squeekboard 1.17.1 or 1.18.0). Also, only rust
components where changed for this test : exact same gcc etc ..
If rustc changed it's behaviour in between, at least the compiler would
have given an advice or a tip. Anyway this does not occur on other
architectures, so yes, I rather think it may be some thorny ppc64el
regression on rustc side, but that is only an assumption.
I'm no rust expert to maybe try a different layout of the code or maybe
rust link option that could help and workaround that linking issue for
the time being.

F.


signature.asc
Description: PGP signature

Bug#1013273: linking problems on ppc64el

[Frédéric Bonnard]

Package: src:rustc
Version: 1.59.0+dfsg1-1

--

Dear maintainer,
squeekboard 1.18.0-1 package does not build on ppc64el, due to unknown symbols 
at
link time : 
https://buildd.debian.org/status/fetch.php?pkg=squeekboard=ppc64el=1.18.0-1=1654176130=0

---
error: linking with `cc` failed: exit status: 1
  |
  = note: "cc" "-m64" 
"/<>/_build/debug/deps/test_layout-11bb72ffb1bce37c.test_layout.5e362dd1-cgu.0.rcgu.o"
 
"/<>/_build/debug/deps/test_layout-11bb72ffb1bce37c.test_layout.5e362dd1-cgu.1.rcgu.o"
 
"/<>/_build/debug/deps/test_layout-11bb72ffb1bce37c.test_layout.5e362dd1-cgu.10.rcgu.o"
 
"/<>/_build/debug/deps/test_layout-11bb72ffb1bce37c.test_layout.5e362dd1-cgu.11.rcgu.o"
 
"/<>/_build/debug/deps/test_layout-11bb72ffb1bce37c.test_layout.5e362dd1-cgu.12.rcgu.o"
 
"/<>/_build/debug/deps/test_layout-11bb72ffb1bce37c.test_layout.5e362dd1-cgu.13.rcgu.o"
 
"/<>/_build/debug/deps/test_layout-11bb72ffb1bce37c.test_layout.5e362dd1-cgu.14.rcgu.o"
 
"/<>/_build/debug/deps/test_layout-11bb72ffb1bce37c.test_layout.5e362dd1-cgu.15.rcgu.o"
 
"/<>/_build/debug/deps/test_layout-11bb72ffb1bce37c.test_layout.5e362dd1-cgu.2.rcgu.o"
 
"/<>/_build/debug/deps/test_layout-11bb72ffb1bce37c.test_layout.5e362dd1-cgu.3.rcgu.o"
 
"/<>/_build/debug/deps/test_layout-11bb72ffb1bce37c.test_layout.5e362dd1-cgu.4.rcgu.o"
 
"/<>/_build/debug/deps/test_layout-11bb72ffb1bce37c.test_layout.5e362dd1-cgu.5.rcgu.o"
 
"/<>/_build/debug/deps/test_layout-11bb72ffb1bce37c.test_layout.5e362dd1-cgu.6.rcgu.o"
 
"/<>/_build/debug/deps/test_layout-11bb72ffb1bce37c.test_layout.5e362dd1-cgu.7.rcgu.o"
 
"/<>/_build/debug/deps/test_layout-11bb72ffb1bce37c.test_layout.5e362dd1-cgu.8.rcgu.o"
 
"/<>/_build/debug/deps/test_layout-11bb72ffb1bce37c.test_layout.5e362dd1-cgu.9.rcgu.o"
 
"/<>/_build/debug/deps/test_layout-11bb72ffb1bce37c.1za2zgv28ktto65n.rcgu.o"
 "-Wl,--as-needed" "-L" "/<>/_build/debug/deps" "-L" 
"/usr/lib/rustlib/powerpc64le-unknown-linux-gnu/lib" "-Wl,-Bstatic" 
"/<>/_build/debug/deps/librs-5d86b83039a84e4a.rlib" 
"/<>/_build/debug/deps/libserde_yaml-182dcbb15eccd1ba.rlib" 
"/<>/_build/debug/deps/libryu-7d6712dc88b0b711.rlib" 
"/<>/_build/debug/deps/libyaml_rust-e76b2bd4d479ec56.rlib" 
"/<>/_build/debug/deps/liblinked_hash_map-09b08e6076b66a8e.rlib" 
"/<>/_build/debug/deps/libzbus-25a4189db214a4dc.rlib" 
"/<>/_build/debug/deps/libfutures-9ee459e9cf24e2b6.rlib" 
"/<>/_build/debug/deps/libscoped_tls-e59bab24ec7035fb.rlib" 
"/<>/_build/debug/deps/libnix-c5f7f77c0593be65.rlib" 
"/<>/_build/debug/deps/libnb_connect-44b9e0fa6198e155.rlib" 
"/<>/_build/debug/deps/libasync_io-c34c4abd1906ee98.rlib" 
"/<>/_build/debug/deps/libpolling-07e2bc397cc98c19.rlib" 
"/<>/_build/debug/deps/liblog-dbee90f3836af202.rlib" 
"/<>/_build/debug/deps/libcfg_if-9e32ba18a1817034.rlib" 
"/<>/_build/debug/deps/libcfg_if-fb419582bef37c5a.rlib" 
"/<>/_build/debug/deps/libconcurrent_queue-a94174f7ffcf459a.rlib" 
"/<>/_build/debug/deps/libcache_padded-243fa3e784b08dd8.rlib" 
"/<>/_build/debug/deps/libsocket2-a75ba586938f1e15.rlib" 
"/<>/_build/debug/deps/libfutures_lite-7352720b89eeed5a.rlib" 
"/<>/_build/debug/deps/libfastrand-1103597adb74edbb.rlib" 
"/<>/_build/debug/deps/libwaker_fn-d20a06f406fe7651.rlib" 
"/<>/_build/debug/deps/libparking-17a48000badaf41e.rlib" 
"/<>/_build/debug/deps/libzvariant-595d9a83c1def639.rlib" 
"/<>/_build/debug/deps/libenumflags2-844ac59f720af453.rlib" 
"/<>/_build/debug/deps/libbyteorder-ada794db65a1f56d.rlib" 
"/<>/_build/debug/deps/libstatic_assertions-b62bc4678c7c6d94.rlib" 
"/<>/_build/debug/deps/libxkbcommon-36f3ed3ee003730a.rlib" 
"/<>/_build/debug/deps/libmemmap-b3cacf2502f8f9e6.rlib" 
"/<>/_build/debug/deps/libserde-4af0d4f241b26211.rlib" 
"/<>/_build/debug/deps/libmaplit-34c7600902ce6af3.rlib" 
"/<>/_build/debug/deps/libgtk-4b4bef998a2e0f2e.rlib" 
"/<>/_build/debug/deps/libfield_offset-b5def348e0a8b749.rlib" 
"/<>/_build/debug/deps/libmemoffset-adf3169c2519dd70.rlib" 
"/<>/_build/debug/deps/libatk-4941d3edd8b881a8.rlib" 
"/<>/_build/debug/deps/libgtk_sys-57f8a50fb311e6aa.rlib" 
"/<>/_build/debug/deps/libatk_sys-d297c0861969ac24.rlib" 
"/<>/_build/debug/deps/libgdk-681b86830d325991.rlib" 
"/<>/_build/debug/deps/libpango-07397902ad818871.rlib" 
"/<>/_build/debug/deps/libgdk_pixbuf-9ba05374e7cd33f8.rlib" 
"/<>/_build/debug/deps/libgio-93043fdf8b8be867.rlib" 
"/<>/_build/debug/deps/libgdk_sys-57c2263db51d6072.rlib" 
"/<>/_build/debug/deps/libpango_sys-23583ca7ba854bb5.rlib" 
"/<>/_build/debug/deps/libgdk_pixbuf_sys-32f25d7c541922ac.rlib" 
"/<>/_build/debug/deps/libgio_sys-6ec4829a8f848d72.rlib" 
"/<>/_build/debug/deps/libcairo-3a8bb59577195f5d.rlib" 
"/<>/_build/debug/deps/libthiserror-c34d3242a646b5ba.rlib" 
"/<>/_build/debug/deps/libglib-55444f920ea41c83.rlib" 
"/<>/_build/debug/deps/libfutures_executor-5fcf7e1faf48524e.rlib" 
"/<>/_build/debug/deps/libfutures_util-51a97b470bd911a6.rlib" 
"/<>/_build/debug/deps/libfutures_io-c5219290384ca41d.rlib" 
"/<>/_build/debug/deps/libslab-40bf4d357c0f49bd.rlib" 

Bug#1012638: Patch proposal

[Frédéric Bonnard]

Control: reassign -1 src:rocksdb
Control: retitle -1 rocksdb wrongly optimized for P9 causes SIGILL in binaries 
using it

Here is a debdiff introducing a quilt patch and explaining what the
issue is.
I'm not sure if should be forwarded/fixed upstream... it depends what
they want to achieve. It was originally a commit called "Add ppc64le
builds to Travis" : 
https://github.com/facebook/rocksdb/pull/6144/files#diff-1e7de1ae2d059d21e1dd75d5812d5a34b0222cef273b7c3a2af62eb747f9d20a
I guess for Debian/Ubuntu, the default gcc profile (P8 compatible on
Debian/P9 compatible on Ubuntu since 22.04), should be used and CPU
related features not forced.

F.
diff -Nru 
rocksdb-7.2.2/debian/patches/rely-on-default-for-optimization-on-Power.patch 
rocksdb-7.2.2/debian/patches/rely-on-default-for-optimization-on-Power.patch
--- 
rocksdb-7.2.2/debian/patches/rely-on-default-for-optimization-on-Power.patch
1970-01-01 01:00:00.0 +0100
+++ 
rocksdb-7.2.2/debian/patches/rely-on-default-for-optimization-on-Power.patch
2022-06-06 20:22:35.0 +0200
@@ -0,0 +1,46 @@
+Description: Don't optimize without knowing the target system on Power
+ Upstream's CMake configuration assumes having gcc P9 optimizations flags means
+ we are compiling for P9.
+ On ppc64*, gcc can produce binaries optimized for P8, P9 or P10 atm.
+ But on Debian we want to be compatible with all and default to P8.
+ ---
+ $ gcc -Q --help=target|grep -i power
+  -mpower10[disabled]
+  -mpower10-fusion [disabled]
+  -mpower8-fusion  [enabled]
+  -mpower8-fusion-sign [disabled]
+  -mpower8-vector  [enabled]
+  -mpower9-minmax  [disabled]
+  -mpower9-misc[disabled]
+  -mpower9-vector  [disabled]
+  -mpowerpc[ignored]
+  -mpowerpc-gfxopt [enabled]
+  -mpowerpc-gpopt  [enabled]
+  -mpowerpc64  [enabled]
+  ---
+ Altivec is a different story, as it is enabled by default on ppc64el but not
+ on ppc64. So leaving it for now.
+Author: Frédéric Bonnard 
+Forwarded: no
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/CMakeLists.txt
 b/CMakeLists.txt
+@@ -203,17 +203,6 @@
+ 
+ include(CheckCCompilerFlag)
+ if(CMAKE_SYSTEM_PROCESSOR MATCHES "^(powerpc|ppc)64")
+-  CHECK_C_COMPILER_FLAG("-mcpu=power9" HAS_POWER9)
+-  if(HAS_POWER9)
+-set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -mcpu=power9 -mtune=power9")
+-set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -mcpu=power9 -mtune=power9")
+-  else()
+-CHECK_C_COMPILER_FLAG("-mcpu=power8" HAS_POWER8)
+-if(HAS_POWER8)
+-  set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -mcpu=power8 -mtune=power8")
+-  set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -mcpu=power8 -mtune=power8")
+-endif(HAS_POWER8)
+-  endif(HAS_POWER9)
+   CHECK_C_COMPILER_FLAG("-maltivec" HAS_ALTIVEC)
+   if(HAS_ALTIVEC)
+ message(STATUS " HAS_ALTIVEC yes")
diff -Nru rocksdb-7.2.2/debian/patches/series 
rocksdb-7.2.2/debian/patches/series
--- rocksdb-7.2.2/debian/patches/series 2022-05-21 19:47:37.0 +0200
+++ rocksdb-7.2.2/debian/patches/series 2022-06-06 20:22:35.0 +0200
@@ -8,3 +8,4 @@
 arm.patch
 armv7_support.patch
 0001-replace-old-sync-with-new-atomic-builtin-equivalents.patch
+rely-on-default-for-optimization-on-Power.patch


signature.asc
Description: PGP signature

Bug#1012638: issue in rocksdb on ppc64

[Frédéric Bonnard]

Control: reassign -1 rocksdb

Hi,
this is actually an issue in latest rocksdb 7.2.2-3 that got compiled
with -mcpu=power9 -mtune=power9 which is not good in Debian, because
we want to be power8 compatible (Debian's gcc defaults).
(which is not the case in Ubuntu which optimize for Power9 and thus
balboa works fine there).
And we run backend/balboa-rocksdb/build/balboa-rocksdb --help, which fail
with SIGFILL.
I'll send a patch for rocksdb in Debian.
Regards,

F.



signature.asc
Description: PGP signature

Bug#1004511: luajit SEGFAULTS on ppc64el

[Frédéric Bonnard]

Hi Paul,
sorry for the late reply.
As I said on debian-devel, I've not enough expertise nor hope on that
topic.
Switching to lua is the way I went a few times, instead on relying on
luajit.


F.

On Mon, 02 May 2022 07:55:50 +0200 Paul Gevers  wrote:
> Hi,
> 
> On 24-04-2022 12:00, Paul Gevers wrote:
> > On Sat, 29 Jan 2022 19:32:53 +0100 Paul Gevers  wrote:
> >> With a recent upload of luajit the autopkgtest of knot-resolver fails 
> >> in testing when that autopkgtest is run with the binary packages of 
> >> luajit from unstable. It passes when run with only packages from 
> >> testing. In tabular form:
> > 
> > knot-resolver has been removed from testing due to this bug report, but 
> > can't migrate back because a newer version fails to build on ppc64el. 
> > Also other reverse dependencies of luajit show SEGFAULT in their 
> > autopkgtest on ppc64el, so this seems a problem in luajit. Unfortunately 
> > (Release Team member opinion) luajit is a key package so can't be 
> > trivially removed. Can you (maintainer and ppc64el porters) please have 
> > a look?
> 
> If this issue is difficult to fix, how about removing luajit from 
> ppc64el? I noticed that the only reverse (build) dependent key package 
> of luajit (src:efl) already switched to plain lua on ppc64el (probably 
> because of this issue).
> 
> Paul


signature.asc
Description: PGP signature

Bug#1007016: ppc64el follow up

[Frédéric Bonnard]

Hi,
as I said, with gcc-9, mlton-20210117+dfsg-3 builds fine. Underlying
mlton to rebuilt it (Build-Depends-Arch) is mlton-20130715-3 .

Then, what I see, is that with 
mlton-20210117+dfsg-3_built_with_gcc-9+mlton-20130715-3
installed as new Build-Depends-Arch instead of mlton-20130715-3, 
mlton-20210117+dfsg-3
does build with gcc-11.

Then this 
mlton-20210117+dfsg-3_built_with_gcc-11+(mlton-20210117+dfsg-3_built_with_gcc-9+mlton-20130715-3)
also enables to build mlton-20210117+dfsg-3 with gcc-11.

Not sure if I'm clear enough, not sure that's the way to go, but I was
wondering if that bootstrap process could lead to somewhere and it does.
Thanks for reading :)

F.


signature.asc
Description: PGP signature

Bug#1007016: FTBFS on ppc64el

[Frédéric Bonnard]

Package: src:mlton
Version: 20210117+dfsg-3
Control: tags -1 ftbfs

--

Dear maintainer,
mlton fails to build on ppc64el :
https://buildd.debian.org/status/fetch.php?pkg=mlton=ppc64el=20210117%2Bdfsg-3=1642700806=0

I've not been able to dig much into that. What I noticed is that is does
build with ggc-9 but not with gcc-[10,11,12].

Regards,


F.


signature.asc
Description: PGP signature

Bug#1006943: eigen3: freecad FTBFS on ppc64el

[Frédéric Bonnard]

Package: src:eigen3
Version: 3.4.0-2
Control: tags -1 + patch

--

Dear maintainer,
freecad fails to build on ppc64el :
https://buildd.debian.org/status/fetch.php?pkg=freecad=ppc64el=0.19.4%2Bdfsg1-1=1646410969=0

This bug is due to gcc failing in eigen3. Some related links :
https://bugzilla.redhat.com/show_bug.cgi?id=1996330
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102059

Ubuntu used a workaround mentionned in the first link for eigen3 :
https://launchpadlibrarian.net/578678112/eigen3_3.4.0-2ubuntu1_3.4.0-2ubuntu2.diff.gz

I used it and freecad builds fine then.
Could you consider using the patch which seems the easiest workaround
for now ?

Regards,


F.


signature.asc
Description: PGP signature

Bug#997969: Failure with latest upstream

[Frédéric Bonnard]

Control: tags -1 + patch

Upstream 0.9.3 has patches.

F.


signature.asc
Description: PGP signature

Bug#997969: Failure with latest upstream

[Frédéric Bonnard]

Control: forwarded -1 https://github.com/stefanberger/libtpms/issues/298

With 0.10.0~dev1 it doesn't build too.

F.


signature.asc
Description: PGP signature

Bug#1000651: Acknowledgement (vmg: FTBFS on ppc64el)

[Frédéric Bonnard]

Hi,
debian/rules just need to fix the path for fpc unit files :

---
ifeq ($(DEB_HOST_GNU_CPU),powerpc64le)
DEB_HOST_GNU_CPU := powerpc64
endif
---

F.


signature.asc
Description: PGP signature

Bug#1000651: vmg: FTBFS on ppc64el

[Frédéric Bonnard]

Package: src:vmg
Version: 3.7.1-5
Control: tags -1 ftbfs

--

Dear maintainer,
vmg fails to build on ppc64el :
https://buildd.debian.org/status/fetch.php?pkg=vmg=ppc64el=3.7.1-5=1604198887=0


Regards,


F.


signature.asc
Description: PGP signature

Bug#995393: fakeroot: FTBFS on ppc64el

[Frédéric Bonnard]

Package: src:fakeroot
Version: 1.26-1
Control: tags -1 ftbfs

--

Dear maintainer,
fakeroot fails to build on ppc64el since 1.26-1
https://buildd.debian.org/status/fetch.php?pkg=fakeroot=ppc64el=1.26-1=1630982822=0

Backtrace from the core file :
---
Core was generated by `chown -R daemon:sys 2 '.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x05e13c212284 in 001b.plt_call.fdopendir@@GLIBC_2.17 ()
(gdb) bt
#0  0x05e13c212284 in 001b.plt_call.fdopendir@@GLIBC_2.17 ()
#1  0x05e13c220fd4 in opendirat (dir_fd=-100, dir=0x5e13fb347b0 "2", 
extra_flags=32768, pnew_fd=0x7fffc6e5cab0) at lib/opendirat.c:44
#2  0x05e13c21cb74 in fts_build (sp=0x5e13fb33ce0, type=3) at lib/fts.c:1340
#3  0x05e13c21be60 in rpl_fts_read (sp=0x5e13fb33ce0) at lib/fts.c:940
#4  0x05e13c214ca0 in chown_files (files=0x7fffc6e5d210, bit_flags=1040, 
uid=1, gid=3, required_uid=4294967295, required_gid=4294967295, 
chopt=0x7fffc6e5cd00) at src/chown-core.c:531
#5  0x05e13c21349c in main (argc=4, argv=0x7fffc6e5d1f8) at src/chown.c:324
---

Bisecting the code I ended up with this commit : 
https://salsa.debian.org/clint/fakeroot/-/commit/f5e0a89ab6f0024f3d3bec5fd9cf631676b44f6c
from which things start to fail.
Especially the openat() function.
What I noticed also is that lowering optimization to O0 makes the test
work.

Simple way to reproduce is on directories : 
---
mkdir bla
LD_PRELOAD=./obj-sysv/.libs/libfakeroot-0.so /bin/rm -fr bla
---
Each time fdopendir seg fault with the fd coming from openat right
before.

Not sure what optimization breaks, I just tried changing openat() to
modify some aggressive optimization on that function and it helped.

---
--- a/libfakeroot.c
+++ b/libfakeroot.c
@@ -2596,7 +2596,11 @@
 #endif
 
 #ifdef HAVE_OPENAT
+#if defined(__powerpc__) && defined(__powerpc64__) && __BYTE_ORDER__ == 
__ORDER_LITTLE_ENDIAN__
+static int openat(int dir_fd, const char *pathname, int flags, ...)
+#else
 int openat(int dir_fd, const char *pathname, int flags, ...)
+#endif
 {
mode_t mode;
---

Hoping you'll get more ideas on this


Regards,


F.


signature.asc
Description: PGP signature

Bug#987368: Installer fails at first menu "Choose language"

[Frédéric Bonnard]

Hi Steve,

awesome, couldn't wait to test it, so I built udpkg 1.20 from salsa and
integrated in latest debian-installer built to have a mini.iso to play
with.

I tried that iso 5-6 times on each of the 2 physical Power machines on
which I encountered the bug and it worked every single time.

From my perspective, it's a huge improvement for bullseye.

Thanks Steve and everyone!

F.


On Fri, 11 Jun 2021 02:57:21 +0100, Steve McIntyre  wrote:
> On Thu, Jun 10, 2021 at 12:11:05AM +0100, Steve McIntyre wrote:
> >
> >Looking at the history in this bug, things are not working as we hoped
> >when we added the multi-console support. When I initially worked with
> >Wookey on this, we didn't see errors like this at all in
> >testing. That's not to say that there's *not* a problem here, but
> >maybe other changes made since then have caused it to be uncovered.
> >
> >Multi-console support is a significant improvement for a number of
> >non-x86 users. This is particularly the case for those with arm64
> >systems where the firmware might default to the primary console being
> >a serial port but the user doesn't even know that. We wanted to be
> >able to start d-i on all the likely-looking consoles (serial *and* tty
> >*and* graphical), allowing the user to interact with the one they
> >preferred.
> >
> >In our testing, I don't remember ever seeing udpkg invocations racing
> >against each other like this. But in my own testing for d-i Bullseye
> >RC2 in an arm64 VM here I've just seen this exact problem myself so
> >it's clearly a thing!
> >
> >I'm looking at udpkg now to see what I can do there. I'm hoping that
> >it might be a reasonably quick fix use filesytem-based locking around
> >status file updates.
> 
> Having experimented with exactly that, after a little bit of tweaking
> I think I've fixed the bug. Previously I could reproduce this bug
> readily, ~75% of the time on my local arm64 VM. With my new udpkg
> build included, I've just run things through a dozen times in
> succession with no problem encountered. I think that's good enough, so
> I've pushed and uploaded a new udpkg into unstable.
> 
> Please check back in a couple of days with a daily build and validate
> this fixes things for you too.
> 
> -- 
> Steve McIntyre, Cambridge, UK.st...@einval.com
> < Aardvark> I dislike C++ to start with. C++11 just seems to be
> handing rope-creating factories for users to hang multiple
> instances of themselves.
> 


signature.asc
Description: PGP signature

Bug#989641: ITP: simplematch -- Minimal, super readable string pattern matching for Python

[Frédéric Bonnard]

Package: wnpp
Owner: Frédéric Bonnard 
Severity: wishlist

* Package name: simplematch
  Version : 1.3
  Upstream Author : Thomas Feldmann 
* URL : https://github.com/tfeldmann/simplematch
* License : Expat
  Programming Lang: Python
  Description : Minimal, super readable string pattern matching for Python

simplematch aims to fill a gap between parsing with str.split() and
regular expressions. It should be as simple as possible, fast and
stable.
The simplematch syntax is transpiled to regular expressions under the
hood, so matching performance should be just as good.

This small library is a dependency of "organize" tool that I intend to
package as well.

--
F.


signature.asc
Description: PGP signature

Bug#989639: ITP: organize -- File management automation tool

[Frédéric Bonnard]

Package: wnpp
Owner: Frédéric Bonnard 
Severity: wishlist

* Package name: organize
  Version : 1.10.1
  Upstream Author : Thomas Feldmann 
* URL : https://github.com/tfeldmann/organize
* License : Expat
  Programming Lang: Python
  Description : File management automation tool

organize is a command line utility to automate file organization tasks.
A list of folders containing files to organize are provided in a
configuration file.
A list of filters can be applied to those files : filtering can be done by
file extension, last modified date, regular expressions and many more.
And a list of actions will be applied to the filtered files : they can
put them into the trash, move them into another folder and many more.

--
F


signature.asc
Description: PGP signature

Bug#987368: Installer fails at first menu "Choose language"

[Frédéric Bonnard]

Hi Cyril/all,
sorry that the process takes long, but that was the only way to
reproduce that bug (which I think may not be specific to ppc64el)
without having Power hardware (and a LPAR/HMC setup).

> Looking at that log, one sees two PIDs for main-menu (272 and 278),
> which could explain a very nice race condition: udpkg racing, one of
> them making the status file disappear from under the feet of the other
> one?

My feeling is that this is exactly what's happening.
I tried touching the missing file and the installer was happy because
the called process (udpkg from what I remember) does not crash anymore
(one can try udpkg without status file and it will crash).

> See also two /sbin/debian-installer processes getting started beforehand
> (one on /dev/hvc0, one on /dev/tty).

Exactly.

> It looks to me this is a clear problem on the debian-installer side (how
> it deals with multiple consoles, similar to #940028 as you mentioned
> initially), rather than some possible issues with emulation?

To me, it's clearly not a qemu issue, since I have that issue on
physical machines too. I just went the emulation way to enable people
without hardware to reproduce the bug. It's more a race condition of
running two debian-installers (not sure now who is remove the status
file, probably udpkg ?).

The point is that some work has already been done by several people on
those multiple consoles setup according to the git commits , and I guess
they will clearly get a grasp of what's going on.


F.


signature.asc
Description: PGP signature

Bug#987368: Installer fails at first menu "Choose language"

[Frédéric Bonnard]

On Fri, 28 May 2021 14:39:56 +0200, Cyril Brulebois  wrote:
> Hi Frédéric,
> 
> Frédéric Bonnard  (2021-05-25):
> > Get that one too :
> > https://openpower.xyz/job/openpower/job/openpower-op-build/label=slave,target=witherspoon/lastSuccessfulBuild/artifact/images/skiboot.lid
> > 
> > and give it to qemu-system-ppc64 by adding "-bios skiboot.lid" to the qemu
> > line (got the same issue. Last components build may require a newer
> > skiboot.lid than the one coming in qemu package).
> 
> OK, thanks! It went further, but I'm now facing this:
> 
> Exiting petitboot. Type 'exit' to return.
> You may run 'pb-sos' to gather diagnostic data
> No password set, running as root. You may set a password in the System 
> Configuration screen.
> # kexec -l vmlinux -i initrd.gz -e 
> load_kernel: Open of vmlinux failed: No such file or directory
> # kexec -s vmlinux -i initrd.gz -e
> file_load failed: Bad file descriptor
> 
> but those files are in the directory where I started qemu-system-ppc64
> from. Did I miss a step?

Actually you need to "wget" the vmlinux and initrd.gz files inside the
emulated system, in the same place where you'll kexec .
So just re-run your wget commands from the petitboot shell and you
should be good :)

> (Third time's the charm? :))

:D 

> 
> 
> Cheers,
> -- 
> Cyril Brulebois (k...@debian.org)<https://debamax.com/>
> D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#987368: Installer fails at first menu "Choose language"

[Frédéric Bonnard]

Hey Cyril,
thanks for trying!
Get that one too :
https://openpower.xyz/job/openpower/job/openpower-op-build/label=slave,target=witherspoon/lastSuccessfulBuild/artifact/images/skiboot.lid

and give it to qemu-system-ppc64 by adding "-bios skiboot.lid" to the qemu
line (got the same issue. Last components build may require a newer
skiboot.lid than the one coming in qemu package).


F.


On Mon, 24 May 2021 04:48:00 +0200, Cyril Brulebois  wrote:
> Hi Frédéric,
> 
> Frédéric Bonnard  (2021-04-26):
> > Thanks for willing to investigate !
> 
> Thanks for the detailed steps!
> 
> > LPAR setup in PowerVM can not be reproduced to my knowledge with qemu;
> > this a partitioning configuration with PHYP proprietary firmware by
> > IBM.  Using a ppc64el vm, I never had the issue, since I think, hvc0
> > does not exist and thus does not create race condition with tty0. The
> > last possible configuration providing hvc0 is the baremetal mode
> > (PowerNV), installating a physical Power machine with linux on top of
> > it.
> > Hopefully, qemu is able to emulate a baremetal machine (PowerNV) as
> > skiboot firmware is opensource (compared to PHYP).
> > I tried and could reproduce the bug after 3 tries.
> > 
> > For this, on your amd64 machine :
> > - install qemu-system-ppc 5.2 (in my case, using stable, I used 
> > 1:5.2+dfsg-9~bpo10+1 )
> > - get those :
> >   * 
> > https://openpower.xyz/job/openpower/job/openpower-op-build/label=slave,target=witherspoon/lastSuccessfulBuild/artifact/images/rootfs.cpio.xz
> >   * 
> > https://openpower.xyz/job/openpower/job/openpower-op-build/label=slave,target=witherspoon/lastSuccessfulBuild/artifact/images/zImage.epapr
> > - use the following to emulate the P9 PowerNV Witherspoon machine :
> >   qemu-system-ppc64 -m 2G -machine powernv9 -smp 8,cores=8,threads=1 \
> > -accel tcg,thread=single \
> > -device e1000e,netdev=net0,mac=C0:FF:EE:00:00:02,bus=pcie.0,addr=0x0  \
> > -netdev user,id=net0,hostfwd=::20022-:22,hostname=pnv \
> > -kernel ./zImage.epapr  \
> > -initrd ./rootfs.cpio.xz \
> > -nographic
> > - Once you get into the petitboot menu, "Exit to shell"
> 
> Using a rather similar qemu package, but on bullseye (1:5.2+dfsg-10),
> I'm not able to get to the petitboot menu:
> 
> kibi@tokyo:~/downloads$ qemu-system-ppc64 -m 2G -machine powernv9 -smp 
> 8,cores=8,threads=1 \
> -accel tcg,thread=single \
> -device e1000e,netdev=net0,mac=C0:FF:EE:00:00:02,bus=pcie.0,addr=0x0  
> \
> -netdev user,id=net0,hostfwd=::20022-:22,hostname=pnv \
> -kernel ./zImage.epapr  \
> -initrd ./rootfs.cpio.xz \
> -nographic
> [0.015788836,5] OPAL v6.4 starting...
> [0.016283111,7] initial console log level: memory 7, driver 5
> [0.016319531,6] CPU: P9 generation processor (max 4 threads/core)
> [0.016335507,7] CPU: Boot CPU PIR is 0x PVR is 0x004e1200
> [0.016452461,7] OPAL table: 0x30110530 .. 0x30110aa0, branch table: 
> 0x30002000
> [0.016622304,7] Assigning physical memory map table for nimbus
> [0.016979537,7] FDT: Parsing fdt @0x100
> [0.019592646,5] CHIP: Detected Qemu simulator
> [0.019757972,6] CHIP: Initialised chip 0 from xscom@603fc
> [0.020117574,6] P9 DD2.00 detected
> [0.020142490,5] CHIP: Chip ID  type: P9N DD2.00
> [0.020155985,7] XSCOM: Base address: 0x603fc
> [0.020192159,7] XSTOP: ibm,sw-checkstop-fir prop not found
> [0.020301881,6] MFSI 0:0: Initialized
> [0.020313870,6] MFSI 0:2: Initialized
> [0.020323201,6] MFSI 0:1: Initialized
> [0.020848585,6] LPC: LPC[000]: Initialized
> [0.020858725,7] LPC: access via MMIO @0x60300
> [0.020894150,7] LPC: Default bus on chip 0x0
> [0.020998003,7] CPU: New max PIR set to 0x1f
> [0.021512680,7] MEM: parsing reserved memory from 
> reserved-names/-ranges properties
> [0.021609903,7] CPU: decrementer bits 56
> [0.021668231,6] CPU: CPU from DT PIR=0x Server#=0x0 State=3
> [0.021750145,6] CPU:  1 secondary threads
> [0.021766340,6] CPU: CPU from DT PIR=0x0004 Server#=0x4 State=3
> [0.021788849,6] CPU:  1 secondary threads
> [0.021797000,6] CPU: CPU from DT PIR=0x0008 Server#=0x8 State=3
> [0.021807120,6] CPU:  1 secondary threads
> [0.021814202,6] CPU: CPU from DT PIR=0x000c Server#=0xc State=3
> [0.021823785,6] CPU:  1 secondary threads
> [0.021834496,6] CPU: CPU from DT PIR=0x0010 Server#=0x10 State=3
> [0.021846219,6] C

Bug#979609: swt4-gtk segfaults on ppc64el

[Frédéric Bonnard]

Hi there,

I tried to bisect between 4.17.0 and 4.18.0 (4.19.0
didn't work either) and found the first offending commit
64ceb09e3297259b58a78b5d6486b1724070a4c9 that makes tracecompass fail
and playing with -DNO_gtk_1check_1button_1set_1inconsistent makes it
work. Soon after f2006cbb02568177a6bfaf074f4e787b3dafdc75 : same kind of
changes and same kind of trick seemed to help.
All those implying GTK port changes and JNI. Also I saw tons of cc
warnings of implicit casts in os.c which is generated by JNIGenerator ..

All in all, I tried with latest git tree as it has other GTK/JNI
improvements and as of v4944r22, it built cleanly and worked well with
tracecompass, syndie and steganosuite.

Maybe not the best answer, but I think it can help going forward.

F.


On Mon, 22 Feb 2021 11:15:29 +0200, Adrian Bunk  wrote:
> On Tue, Jan 12, 2021 at 07:06:36PM +, Sudip Mukherjee wrote:
> > I had been testing little more and I can see the same problem with
> > other packages (syndie and stegosuite) which are using
> > libswt-cairo-gtk-4-jni.
> > So, all the three packages using libswt-cairo-gtk-4-jni triggers the
> > segfault in ppc64el.
> 
> Adding debian-powerpc so that a porter can check.
> 
> > Regards
> > Sudip
> 
> cu
> Adrian
> 


signature.asc
Description: PGP signature

Bug#987665: unblock: libcxl/1.7-2

[Frédéric Bonnard]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package libcxl

The version in testing has bug #987636 which is a FTBFS because of a regression 
in
make 4.3 .
Upstream libcxl has implemented a workaround which I pulled as well a
cosmetic patch for debian/rules that was pushed previously in the git
tree by another Debian Developer.

The build now works fine :
https://buildd.debian.org/status/package.php?p=libcxl

See attached the debdiff for the changes.

unblock libcxl/1.7-2


Thanks!
Regards

F. 

diff -Nru libcxl-1.7/debian/changelog libcxl-1.7/debian/changelog
--- libcxl-1.7/debian/changelog 2018-05-17 16:31:53.0 +0200
+++ libcxl-1.7/debian/changelog 2021-04-27 13:25:03.0 +0200
@@ -1,3 +1,13 @@
+libcxl (1.7-2) unstable; urgency=medium
+
+  [ Ondřej Nový ]
+  * d/rules: Remove trailing whitespaces
+
+  [ Frédéric Bonnard ]
+  * Import upstream fix for make 4.3 use (Closes: #987636)
+
+ -- Frédéric Bonnard   Tue, 27 Apr 2021 13:25:03 +0200
+
 libcxl (1.7-1) unstable; urgency=medium
 
   * Remove unused d/patches effectively
diff -Nru 
libcxl-1.7/debian/patches/0001-Import-upstream-fix-Closes-987636.patch 
libcxl-1.7/debian/patches/0001-Import-upstream-fix-Closes-987636.patch
--- libcxl-1.7/debian/patches/0001-Import-upstream-fix-Closes-987636.patch  
1970-01-01 01:00:00.0 +0100
+++ libcxl-1.7/debian/patches/0001-Import-upstream-fix-Closes-987636.patch  
2021-04-27 13:25:03.0 +0200
@@ -0,0 +1,36 @@
+From: =?utf-8?b?RnLDqWTDqXJpYyBCb25uYXJk?= 
+Date: Tue, 27 Apr 2021 13:22:44 +0200
+Subject: Import upstream fix (Closes: #987636)
+
+https://github.com/ibm-capi/libcxl/commit/f10f957771a1ea7e6f52a48467bcf7ebf3cb1669
+---
+ Makefile | 13 ++---
+ 1 file changed, 10 insertions(+), 3 deletions(-)
+
+diff --git a/Makefile b/Makefile
+index b0626e8..8a07bac 100644
+--- a/Makefile
 b/Makefile
+@@ -18,12 +18,19 @@ all: check_cxl_header $(LIBSONAME) libcxl.so libcxl.a
+ HAS_WGET = $(shell /bin/which wget > /dev/null 2>&1 && echo y || echo n)
+ HAS_CURL = $(shell /bin/which curl > /dev/null 2>&1 && echo y || echo n)
+ 
+-# Update this to test a single feature from the most recent header we require:
+-CHECK_CXL_HEADER_IS_UP_TO_DATE = $(shell /bin/echo -e \\\#include $(1)\\\nint 
i = CXL_START_WORK_TID\; | \
++
++# Update this to test a single feature from the most recent header we require.
++#
++# Note that a backward-incompatible change in make 4.3 modified the
++# handling \# in a function invocation, so we define the test code in
++# a separate variable to work around it and keep consistent behavior
++# across all versions of make
++TEST_CODE = '\#include \nint i = CXL_START_WORK_TID;'
++CHECK_OCXL_HEADER_IS_UP_TO_DATE = $(shell /bin/echo -e $(TEST_CODE) | \
+  $(CC) $(CFLAGS) -Werror -x c -S -o /dev/null - >/dev/null 
2>&1 && echo y || echo n)
+ 
+ check_cxl_header:
+-ifeq ($(call CHECK_CXL_HEADER_IS_UP_TO_DATE,""),n)
++ifeq (${CHECK_CXL_HEADER_IS_UP_TO_DATE},n)
+   mkdir -p include/misc
+ ifeq (${HAS_WGET},y)
+   $(call Q,WGET include/misc/cxl.h, wget -O include/misc/cxl.h -q 
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/plain/include/uapi/misc/cxl.h)
diff -Nru libcxl-1.7/debian/patches/series libcxl-1.7/debian/patches/series
--- libcxl-1.7/debian/patches/series1970-01-01 01:00:00.0 +0100
+++ libcxl-1.7/debian/patches/series2021-04-27 13:25:03.0 +0200
@@ -0,0 +1 @@
+0001-Import-upstream-fix-Closes-987636.patch
diff -Nru libcxl-1.7/debian/rules libcxl-1.7/debian/rules
--- libcxl-1.7/debian/rules 2018-05-16 18:35:20.0 +0200
+++ libcxl-1.7/debian/rules 2021-04-27 13:25:03.0 +0200
@@ -5,7 +5,7 @@
 DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
 
 %:
-   dh $@ 
+   dh $@
 
 override_dh_makeshlibs:
dh_makeshlibs -- -c4


signature.asc
Description: PGP signature

Bug#987368: Installer fails at first menu "Choose language"

[Frédéric Bonnard]

Hi Cyril,

Thanks for willing to investigate !

LPAR setup in PowerVM can not be reproduced to my knowledge with qemu ; this a
partitioning configuration with PHYP proprietary firmware by IBM.
Using a ppc64el vm, I never had the issue, since I think, hvc0 does not
exist and thus does not create race condition with tty0.
The last possible configuration providing hvc0 is the baremetal mode
(PowerNV), installating a physical Power machine with linux on top of
it.
Hopefully, qemu is able to emulate a baremetal machine (PowerNV) as skiboot
firmware is opensource (compared to PHYP).
I tried and could reproduce the bug after 3 tries.

For this, on your amd64 machine :
- install qemu-system-ppc 5.2 (in my case, using stable, I used 
1:5.2+dfsg-9~bpo10+1 )
- get those :
  * 
https://openpower.xyz/job/openpower/job/openpower-op-build/label=slave,target=witherspoon/lastSuccessfulBuild/artifact/images/rootfs.cpio.xz
  * 
https://openpower.xyz/job/openpower/job/openpower-op-build/label=slave,target=witherspoon/lastSuccessfulBuild/artifact/images/zImage.epapr
- use the following to emulate the P9 PowerNV Witherspoon machine :
  qemu-system-ppc64 -m 2G -machine powernv9 -smp 8,cores=8,threads=1 \
-accel tcg,thread=single \
-device e1000e,netdev=net0,mac=C0:FF:EE:00:00:02,bus=pcie.0,addr=0x0  \
-netdev user,id=net0,hostfwd=::20022-:22,hostname=pnv \
-kernel ./zImage.epapr  \
-initrd ./rootfs.cpio.xz \
-nographic
- Once you get into the petitboot menu, "Exit to shell"
- wget : (I couldn't boot the mini.iso)
  * 
https://d-i.debian.org/daily-images/ppc64el/daily/netboot/debian-installer/ppc64el/vmlinux
  * 
https://d-i.debian.org/daily-images/ppc64el/daily/netboot/debian-installer/ppc64el/initrd.gz
- kexec those :
  1. kexec -l vmlinux -i initrd.gz -e (you'll get an error.. but this
  steps seems necessary)
  2. kexec -s vmlinux -i initrd.gz -e
- cross fingers ; if it doesn't fail, halt and rerun qemu...

I hope you get it as well!

F.

On Fri, 23 Apr 2021 22:48:33 +0200, Cyril Brulebois  wrote:
> Hello Frédéric,
> 
> Frédéric Bonnard  (2021-04-22):
> > Boot method: CD
> > Image version: 
> > http://d-i.debian.org/daily-images/ppc64el/daily/netboot/mini.iso
> > Date: April 21st 2021
> > 
> > Machine: Power10 machine but got it on Power8 as well
> > 
> > This happens randomly when the installer menu starts, I get to the first
> > menu "Choose language", but it is red saying "An installation failed...
> > The failing step is: Choose language".
> > 
> > It seems the missing file /var/lib/dpkg/status is causing this.
> > Instead I have /var/lib/dpkg/status.bak
> 
> I don't know much about ppc (I don't think iBook G4 experience counts
> much at this stage), but I see that qemu-system-ppc exists, and that it
> provides qemu-system-ppc64. Would you have some guide that could help us
> reproduce the issue from say an amd64 host?
> 
> 
> Cheers,
> -- 
> Cyril Brulebois (k...@debian.org)<https://debamax.com/>
> D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#987368: Installer fails at first menu "Choose language"

[Frédéric Bonnard]

Package: installation-reports

Boot method: CD
Image version: http://d-i.debian.org/daily-images/ppc64el/daily/netboot/mini.iso
Date: April 21st 2021

Machine: Power10 machine but got it on Power8 as well

This happens randomly when the installer menu starts, I get to the first
menu "Choose language", but it is red saying "An installation failed...
The failing step is: Choose language".

It seems the missing file /var/lib/dpkg/status is causing this.
Instead I have /var/lib/dpkg/status.bak

Digging a bit I found this bug : 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940028

which seems close to what I have :

---
Apr 22 12:11:57 reopen-console: Looking at console hvc0 from /proc/consoles
Apr 22 12:11:57 reopen-console:Adding hvc0 to possible consoles list
Apr 22 12:11:57 reopen-console:hvc0 is preferred
Apr 22 12:11:57 reopen-console:Adding tty0 to possible consoles list
Apr 22 12:11:57 reopen-console: Adding inittab entry for hvc0
Apr 22 12:11:57 reopen-console: Adding inittab entry for tty0
Apr 22 12:11:57 reopen-console: Restarting init to start d-i on the console(s) 
we found
Apr 22 12:11:57 init: reloading /etc/inittab
Apr 22 12:11:57 init: starting pid 239, tty '/dev/tty4': '/usr/bin/tail -f 
/var/log/syslog'
Apr 22 12:11:57 init: starting pid 240, tty '/dev/hvc0': 
'/sbin/debian-installer'
Apr 22 12:11:57 init: starting pid 241, tty '/dev/tty0': '/sbin/debian-installer
Apr 22 12:11:57 debconf: Setting debconf/language to en
Apr 22 12:11:57 main-menu[272]: INFO: Falling back to the package description 
for brltty-udeb
Apr 22 12:11:57 debconf: Setting debconf/language to en
Apr 22 12:11:57 main-menu[272]: INFO: Menu item 'localechooser' selected
Apr 22 12:11:57 main-menu[278]: INFO: Falling back to the package description 
for brltty-udeb
Apr 22 12:11:57 main-menu[278]: INFO: Menu item 'localechooser' selected
Apr 22 12:11:57 main-menu[278]: /var/lib/dpkg/status: No such file or directory
Apr 22 12:11:57 main-menu[272]: /var/lib/dpkg/status: No such file or directory
Apr 22 12:11:57 main-menu[272]: /var/lib/dpkg/status: No such file or directory
---

Regards,

F.


signature.asc
Description: PGP signature

Bug#986558: unblock: libsass-python/0.20.1-3

[Frédéric Bonnard]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package libsass-python

The version in testing has bug #980628 which is a FTBFS because of unported 
tests.
So let's skip those tests for now :
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980628#19

The builds worked fine :
https://buildd.debian.org/status/package.php?p=libsass-python

See attached the debdiff for the changes.

unblock libsass-python/0.20.1-3


Thanks!
Regards

F. 

diff -Nru libsass-python-0.20.1/debian/changelog 
libsass-python-0.20.1/debian/changelog
--- libsass-python-0.20.1/debian/changelog  2020-11-06 11:23:10.0 
+0100
+++ libsass-python-0.20.1/debian/changelog  2021-04-07 12:28:16.0 
+0200
@@ -1,3 +1,10 @@
+libsass-python (0.20.1-3) unstable; urgency=medium
+
+  * Use pytest instead of unittest to run tests and disable unported
+tests (Closes: #980628)
+
+ -- Frédéric Bonnard   Wed, 07 Apr 2021 12:28:16 +0200
+
 libsass-python (0.20.1-2) unstable; urgency=medium
 
   * Avoid code download during doc build (Closes: #972140)
diff -Nru libsass-python-0.20.1/debian/rules libsass-python-0.20.1/debian/rules
--- libsass-python-0.20.1/debian/rules  2020-09-08 14:40:03.0 +0200
+++ libsass-python-0.20.1/debian/rules  2021-04-07 12:18:13.0 +0200
@@ -25,10 +25,14 @@
 
 override_dh_auto_test:
 ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
+   # Skip DistutilsTestCase.* to not rebuild sass again
+   #
+   # FIXME : skip test_build_one test_stack_trace_formatting : to reenable 
once
+   # libsass gets past 3.6.4 (see #980628 and upstream issue)
pybuild -s custom --test -p "$(shell py3versions -vr)" \
--test-args="cd {build_dir}; \
-   sed -i '/^class DistutilsTestCase.*/i @unittest.skip(\"Do not 
build sass again\")' sasstests.py; \
-   {interpreter} -m unittest sasstests"
+   {interpreter} -m pytest -k 'not DistutilsTestCase \
+   and not test_build_one and not test_stack_trace_formatting' 
sasstests.py"
 endif
 
 override_dh_auto_clean:


signature.asc
Description: PGP signature

Bug#986287: unblock: os-autoinst/4.6.1604525166.912dfbd-0.3

[Frédéric Bonnard]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package os-autoinst

The version in testing has bug #977990 which is a FTBFS on i386 because
of flaky tests.
I initially wanted to be stricter than upstream and run all tests as it
worked on my builders, but I've decided to stick to the tests upstream
feels confident to run.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977990#44

Build now works right away on i386 :
https://buildd.debian.org/status/package.php?p=os-autoinst

See attached the debdiff for the changes I did.

unblock os-autoinst/4.6.1604525166.912dfbd-0.3


Thanks!
Regards

F. 

diff -Nru os-autoinst-4.6.1604525166.912dfbd/debian/changelog 
os-autoinst-4.6.1604525166.912dfbd/debian/changelog
--- os-autoinst-4.6.1604525166.912dfbd/debian/changelog 2020-12-22 
15:00:29.0 +0100
+++ os-autoinst-4.6.1604525166.912dfbd/debian/changelog 2021-04-01 
12:50:51.0 +0200
@@ -1,3 +1,10 @@
+os-autoinst (4.6.1604525166.912dfbd-0.3) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * Stick to tests that upstream runs (Closes: #977990)
+
+ -- Frédéric Bonnard   Thu, 01 Apr 2021 12:50:51 +0200
+
 os-autoinst (4.6.1604525166.912dfbd-0.2) unstable; urgency=medium
 
   * Non-maintainer upload
diff -Nru os-autoinst-4.6.1604525166.912dfbd/debian/rules 
os-autoinst-4.6.1604525166.912dfbd/debian/rules
--- os-autoinst-4.6.1604525166.912dfbd/debian/rules 2020-12-22 
14:55:47.0 +0100
+++ os-autoinst-4.6.1604525166.912dfbd/debian/rules 2021-04-01 
12:48:06.0 +0200
@@ -8,6 +8,8 @@
 override_dh_auto_configure:
cp -a $(CURDIR)/isotovideo $(CURDIR)/isotovideo.orig
sed -i 's/my $$thisversion =.*/my $$thisversion = "$(DEB_VERSION)";/' 
$(CURDIR)/isotovideo
+   # Following opensuse .spec : don't require qemu and exclude known flaky 
tests
+   cd t && rm -f 07-commands.t 13-osutils.t 14-isotovideo.t 
18-qemu-options.t 18-backend-qemu.t 99-full-stack.t
dh_auto_configure -- -DOS_AUTOINST_DOC_DIR=/usr/share/doc/$(DEB_SOURCE) 
\
-DSYSTEMD_SERVICE_DIR=/lib/systemd/system 
-DCMAKE_BUILD_TYPE=RelWithDebInfo
 


signature.asc
Description: PGP signature

Bug#977990: os-autoinst: FTBFS on i386: 3/3 Test #3: test-perl-testsuite ..............***Failed 332.81 sec

[Frédéric Bonnard]

Hi,
sorry for the delay.
Initially I wanted to include all tests in the packaging as they just
didn't fail for me on ppc64el, amd64 and i386.
Having a look at the .spec file upstream, they skip some of the tests,
amongst them, the one we have an issue with.

---
# don't require qemu within OBS
# and exclude known flaky tests in OBS check
# https://progress.opensuse.org/issues/52652
# 07-commands: https://progress.opensuse.org/issues/60755
for i in 07-commands 13-osutils 14-isotovideo 18-qemu-options 18-backend-qemu 
99-full-stack; do
rm t/$i.t
done
---

So I think we can safely skip them, if upstream does.
I'm going to change this.

Fred

On Sat, 27 Mar 2021 17:12:17 +0200, Adrian Bunk  wrote:
> ping
> 
> 
> On Fri, Mar 12, 2021 at 05:33:27PM +0200, Adrian Bunk wrote:
> > On Thu, Feb 25, 2021 at 09:52:08AM +0100, Paul Gevers wrote:
> > > Control: found -1 4.5.1527308405.8b586d5-4.2
> > > 
> > > Hi Frédéric, Hideki,
> > > 
> > > On 17-02-2021 22:01, Paul Gevers wrote:
> > > > If the forth time worked because of sheer luck, then please no, keep the
> > > > bug open until the build is less flaky. We need packages to be build
> > > > without failure [1]. Having to baby-sit flaky is not really an option as
> > > > there are too many packages in the Debian archive.
> > > 
> > > I had a look at the reproducible build project history for os-autoinst
> > > [1] and the package FTBFS very, very often, both in unstable and
> > > testing. I have marked this bug as found, so now this package is able to
> > > migrate, *but* you'll have to fix this bug if you want the package to
> > > ship with bullseye. If you can't fix the tests and still believe that
> > > the package is in a good shape for the bullseye release, I suggest you
> > > disable the tests for now.
> > 
> > Or if the package is not in a good shape on i386,
> > remove it from the architecture list.
> > 
> > os-autoinst is amd64-only in buster.
> > 
> > > Paul
> > >...
> > 
> > cu
> > Adrian
> 


signature.asc
Description: PGP signature

Bug#985946: patch proposal

[Frédéric Bonnard]

Hi Davo,
answering quickly as I see you're active right now.
But I'll come back on Monday on your questions in more details because they
deserve answers, but I don't have much time this weekend, so going straight
to the point for now.

March 27, 2021 7:20 AM, "David Bannon"  wrote:

> OK, you are way ahead of me Frédéric, please disregard my previous response.
>
> Great that your patch works, really cool. And thanks ! However, do you
> mind if I query something ? I don't quite see why you call the -
>
> +if [ "$CPU" = "powerpc64le" ]; then
> + CPU="powerpc64"
> +fi
>
> AFTER the line -
>
> TARGET="$CPU-$OS"
>
> If we set TARGET after the "if" statement. the patch is heaps simpler.
> And I like simple patches ...

Yes, I didn't like it as well, because of the same reason and I was kinda 
reluctant
to send and tried to justify it in the patch :)
The reason I complexified this is that I wanted to keep the local objects
produced into a ppc64el related directory which is what is done generally.
Of course this is in the build directory so more or less temporary.
Still if the patch is meant to go upstream, that could make a little bit more 
sense there.
And, powerpc64-linux and powerpc64el-linux objects are not compatible, so same
path does not make sense to me. If cross compiling or doing some other specific 
builds,
the build directory could end up with .o overwriting each other.
On the other hand, lazarus source package produces ppc64 and ppc64el and store 
.o for
binary packages in the very same paths... and I don't really get why lazarus 
does this.

So, if the patch remains in Debian, I think you can perfectly simplify
it as you explain.
I'd still be interested to understand the root "issue" in lazarus. I saw other
distros have the same paths and from digging in lazarus, I didn't find
in the time I had, a way to change this and to try if things still work :)
That would be a question for upstream.

Anyway, the simple patch works well too, that was what I did initially.
I'll come back later for your other questions!

F.

> Now, I cannot test it here but if you can while you have a terminal to a
> P8 machine, and don't have a reason for the way you have done it, could
> you test please ?
>
> Otherwise, if you think it needs to be as per your patch, I am quite
> happy to apply that.
>
> Do you want me to run up a new release or would you prefer to use the
> patch on a Debian downstream release model ?
>
> Davo
>
> On 27/3/21 3:00 am, Frédéric Bonnard wrote:
>
>> Here is a patch proposal which fixes the build.
>> The patch header details the issue and the possible workaround.
>> Regards,
>>
>> F.



signature.asc
Description: PGP signature

Bug#985946: patch proposal

[Frédéric Bonnard]

Here is a patch proposal which fixes the build.
The patch header details the issue and the possible workaround.
Regards,

F.


--- a/buildit.bash
+++ b/buildit.bash
@@ -156,6 +156,9 @@
 CPU="i386"
 fi
 TARGET="$CPU-$OS"
+if [ "$CPU" = "powerpc64le" ]; then
+CPU="powerpc64"
+fi
 CheckFPC
 CheckLazBuild
 CheckForQt5
@@ -193,12 +196,12 @@
 
 FPCHARD=" -Cg  -k-pie -k-znow "
 FPCKOPT=" -MObjFPC -Scgi -Cg -O1 -g -gl -l -vewnibq -vh- -Fi$K_DIR"
-FPCKUNITS=" -Fu$LAZ_DIR/packager/units/$TARGET 
-Fu$LAZ_DIR/components/lazutils/lib/$TARGET"
-FPCKUNITS="$FPCKUNITS -Fu$LAZ_DIR/components/buildintf/units/$TARGET 
-Fu$LAZ_DIR/components/freetype/lib/$TARGET"
-FPCKUNITS="$FPCKUNITS -Fu$LAZ_DIR/lib/$TARGET -Fu$LAZ_DIR/lcl/units/$TARGET 
-Fu$LAZ_DIR/lcl/units/$TARGET/$WIDGET"
-FPCKUNITS="$FPCKUNITS -Fu$LAZ_DIR/components/cairocanvas/lib/$TARGET/$WIDGET 
-Fu$LAZ_DIR/components/lazcontrols/lib/$TARGET/$WIDGET"
-FPCKUNITS="$FPCKUNITS -Fu$LAZ_DIR/components/ideintf/units/$TARGET/$WIDGET 
-Fu$LAZ_DIR/components/printers/lib/$TARGET/$WIDGET"
-FPCKUNITS="$FPCKUNITS -Fu$LAZ_DIR/components/tdbf/lib/$TARGET/$WIDGET -Fu. 
-FUlib/$TARGET"
+FPCKUNITS=" -Fu$LAZ_DIR/packager/units/$CPU-$OS 
-Fu$LAZ_DIR/components/lazutils/lib/$CPU-$OS"
+FPCKUNITS="$FPCKUNITS -Fu$LAZ_DIR/components/buildintf/units/$CPU-$OS 
-Fu$LAZ_DIR/components/freetype/lib/$CPU-$OS"
+FPCKUNITS="$FPCKUNITS -Fu$LAZ_DIR/lib/$CPU-$OS -Fu$LAZ_DIR/lcl/units/$CPU-$OS 
-Fu$LAZ_DIR/lcl/units/$CPU-$OS/$WIDGET"
+FPCKUNITS="$FPCKUNITS -Fu$LAZ_DIR/components/cairocanvas/lib/$CPU-$OS/$WIDGET 
-Fu$LAZ_DIR/components/lazcontrols/lib/$CPU-$OS/$WIDGET"
+FPCKUNITS="$FPCKUNITS -Fu$LAZ_DIR/components/ideintf/units/$CPU-$OS/$WIDGET 
-Fu$LAZ_DIR/components/printers/lib/$CPU-$OS/$WIDGET"
+FPCKUNITS="$FPCKUNITS -Fu$LAZ_DIR/components/tdbf/lib/$CPU-$OS/$WIDGET -Fu. 
-FUlib/$TARGET"
 
 RUNIT="$COMPILER $EXCLUDEMESSAGE $FPCKOPT  $FPCHARD   $FPCKUNITS kmemo.pas"
 
@@ -210,7 +213,7 @@
 # exit
 
 
-if [ ! -e "$K_DIR/lib/$CPU-$OS/kmemo.o" ]; then
+if [ ! -e "$K_DIR/lib/$TARGET/kmemo.o" ]; then
echo "ERROR failed to build KControls, exiting..."
K_DIR=""
exit 1
@@ -254,15 +257,15 @@
 OPT1="-MObjFPC -Scghi -CX -Cg -O3 -XX -Xs -l -vewnibq $EXCLUDEMESSAGE 
-Fi$SOURCE_DIR/lib/$TARGET"
 
 UNITS="$UNITS -Fu$K_DIR/lib/$TARGET"
-UNITS="$UNITS -Fu$LAZ_DIR/components/tdbf/lib/$TARGET/$WIDGET"
-UNITS="$UNITS -Fu$LAZ_DIR/components/printers/lib/$TARGET/$WIDGET"
-UNITS="$UNITS -Fu$LAZ_DIR/components/cairocanvas/lib/$TARGET/$WIDGET"
-UNITS="$UNITS -Fu$LAZ_DIR/components/lazcontrols/lib/$TARGET/$WIDGET"
-UNITS="$UNITS -Fu$LAZ_DIR/components/lazutils/lib/$TARGET"
-UNITS="$UNITS -Fu$LAZ_DIR/components/ideintf/units/$TARGET/$WIDGET"
-UNITS="$UNITS -Fu$LAZ_DIR/lcl/units/$TARGET/$WIDGET"
-UNITS="$UNITS -Fu$LAZ_DIR/lcl/units/$TARGET"
-UNITS="$UNITS -Fu$LAZ_DIR/packager/units/$TARGET"
+UNITS="$UNITS -Fu$LAZ_DIR/components/tdbf/lib/$CPU-$OS/$WIDGET"
+UNITS="$UNITS -Fu$LAZ_DIR/components/printers/lib/$CPU-$OS/$WIDGET"
+UNITS="$UNITS -Fu$LAZ_DIR/components/cairocanvas/lib/$CPU-$OS/$WIDGET"
+UNITS="$UNITS -Fu$LAZ_DIR/components/lazcontrols/lib/$CPU-$OS/$WIDGET"
+UNITS="$UNITS -Fu$LAZ_DIR/components/lazutils/lib/$CPU-$OS"
+UNITS="$UNITS -Fu$LAZ_DIR/components/ideintf/units/$CPU-$OS/$WIDGET"
+UNITS="$UNITS -Fu$LAZ_DIR/lcl/units/$CPU-$OS/$WIDGET"
+UNITS="$UNITS -Fu$LAZ_DIR/lcl/units/$CPU-$OS"
+UNITS="$UNITS -Fu$LAZ_DIR/packager/units/$CPU-$OS"
 
 UNITS="$UNITS -Fu$SOURCE_DIR/"
 UNITS="$UNITS -FU$SOURCE_DIR/lib/$TARGET/" 


signature.asc
Description: PGP signature

Bug#985946: tomboy-ng: FTBFS on ppc64el

[Frédéric Bonnard]

Package: src:tomboy-ng
Version: 0.32-1
Control: tags -1 ftbfs

--

Dear maintainer,
tomboy fails to build on ppc64el :
https://buildd.debian.org/status/fetch.php?pkg=tomboy-ng=ppc64el=0.32-1=1612358331=0


Regards,


F.


signature.asc
Description: PGP signature

Bug#980628: libsass-python FTBFS: possible issue in libsass_3.6.4+20201122-1

[Frédéric Bonnard]

Control: severity -1 important

--

As explained upstream, the behaviour of the tests changed after
libsass's commit "fix how we count unicode characters" that
libsass_3.6.4+20201122-1 pulled.
But upstream's libsass-python doesn't not support non-release of
libsass and they wouldn't help on our issue till libsass 3.6.5 goes out.
I'd trust the "fix how we count unicode characters" and thus, I guess,
the tests may need to be changed.
For the time being, I'll lower the severity of the bug.


F.


signature.asc
Description: PGP signature

Bug#977990: os-autoinst: FTBFS on i386: 3/3 Test #3: test-perl-testsuite ..............***Failed 332.81 sec

[Frédéric Bonnard]

Hi,
indeed Paul, the test is flaky, probably a timing issue. I had already
changed some related parameter that made the tests pass reliably on
my i386 builder, but saw afterward that it still failed on debian's
builder and couldn't reproduce it :
https://salsa.debian.org/debian/os-autoinst/-/commit/38b2f4aefafbdf7ab59ce223ef208c540409a001
I guess, we could increase CI related timeouts here and there but that's
what I tried to avoid when changing CI variable, and I was happy to see
things work.. but not on all i386 builders :)
May we close that bug for now ?

F.


signature.asc
Description: PGP signature

Bug#980628: libsass-python FTBFS: possible issue in libsass_3.6.4+20201122-1

[Frédéric Bonnard]

Control: forwarded -1 https://github.com/sass/libsass-python/issues/331

--

Hi,
as build log shows, the very same version of libsass-python built
successfully some time ago (using libsass_3.6.4-4) :
https://buildd.debian.org/status/logs.php?pkg=libsass-python=amd64=sid

but with latest build dep libsass_3.6.4+20201122-1 it now fails.
I sent upstream my investigations with the change in libsass leading to
the test failing.


F.


signature.asc
Description: PGP signature

Bug#969014: Bug #969014 does not occur anymore

[Frédéric Bonnard]

At the moment, buildd logs show that everything works fine on firefox
83.0-1 / rustc 1.47.0+dfsg1-1
https://buildd.debian.org/status/logs.php?pkg=firefox=83.0-1
I tried myself and it built fine too with current 1.48.0+dfsg1-1 rustc.
Regards,


F.



signature.asc
Description: PGP signature

Bug#976906: Possible lex issue for ppc64el (Was: Bug#976906: libpll: FTBFS on ppc64el: lex_utree.l:22:10: fatal error: parse_utree.h: No such file or directory)

[Frédéric Bonnard]

Here is a patch based on this :
https://www.gnu.org/software/automake/manual/html_node/Yacc-and-Lex.html

Tested on a power machine (where the build failed) and it seems to work.

F.
Description: Fix parallel build
This happened here : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976906
Solution found here : 
https://www.gnu.org/software/automake/manual/html_node/Yacc-and-Lex.html
Author: Frédéric Bonnard 
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -8,6 +8,8 @@
 AM_YFLAGS = -d -p `${SED} -n 's/.*_\(.*\)/pll_\1_/p' <<<"$*"`
 AM_LFLAGS = -P `${SED} -n 's/.*_\(.*\)/pll_\1_/p' <<<"$*"` -o lex.yy.c
 
+BUILT_SOURCES = parse_rtree.h parse_utree.h
+
 libpll_la_SOURCES=\
 fasta.c \
 gamma.c \


signature.asc
Description: PGP signature

Bug#975972: ITP: libmojolicious-plugin-oauth2-perl -- Auth against OAuth2 APIs

[Frédéric Bonnard]

Package: wnpp
Owner: Frédéric Bonnard 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libmojolicious-plugin-oauth2-perl
  Version : 1.58
  Upstream Author : Jan Henning Thorsen 
* URL : https://metacpan.org/release/Mojolicious-Plugin-OAuth2
* License : Artistic-2.0 or GPL-1+
  Programming Lang: Perl
  Description : Auth against OAuth2 APIs

Mojolicious::Plugin::OAuth2 allows you to easily authenticate against a
OAuth2 provider. It includes configurations for a few popular providers,
but you can add your own easily as well.

Note that OAuth2 requires https, so you need to have the optional
Mojolicious dependency required to support it.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.


signature.asc
Description: PGP signature

Bug#974126: ITP: libnet-dns-native-perl -- non-blocking system DNS resolver

[Frédéric Bonnard]

Package: wnpp
Owner: Frédéric Bonnard 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libnet-dns-native-perl
  Version : 0.22
  Upstream Author : Oleg G 
* URL : https://metacpan.org/release/Net-DNS-Native
* License : Artistic or GPL-1+ and LGPL-2+
  Programming Lang: Perl
  Description : non-blocking system DNS resolver

Net::Dns::Native provides several methods for host name resolution.
It is designed to be used with event loops. All resolving are done by
getaddrinfo(3) implemented in your system library. Since getaddrinfo()
is blocking function and this class doesn't want to block, calls to
this function will be done in separate thread. This class uses system
native threads and not perl threads. So overhead shouldn't be too big.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.


signature.asc
Description: PGP signature

Bug#974121: ITP: libcommonmark-perl -- Interface to the CommonMark C library

[Frédéric Bonnard]

Package: wnpp
Owner: Frédéric Bonnard 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libcommonmark-perl
  Version : 0.29
  Upstream Author : Nick Wellnhofer 
* URL : https://metacpan.org/release/CommonMark
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Interface to the CommonMark C library

libcommonmark-perl module is a wrapper around the official CommonMark C
library libcmark. It closely follows the original API.

The main module provides some entry points to parse documents and
convenience functions for node creation. The bulk of features is
available through CommonMark::Node objects of which the parse tree is
made. CommonMark::Iterator is a useful class to walk through the nodes
in a tree. CommonMark::Parser provides a push parser interface.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.


signature.asc
Description: PGP signature

Bug#970014: [Pkg-pascal-devel] Bug#970014: Workaround proposal

[Frédéric Bonnard]

On Wed, 23 Sep 2020 17:45:45 +0200, Frédéric Bonnard  wrote:
> oh right, I didn't realize not all binary packages are built on "any". 2
> needs to be enabled (lcl-qt5-2.0 and lazarus-ide-qt5-2.0). And I tested
> and they build well on ppc64el.
> I'll also tested on ppc64 and provided pie is disabled too, it works
> too.
> So I'll send another MR for those 2 improvements.

I just see you sent them, thanks!

F.


signature.asc
Description: PGP signature

Bug#970014: [Pkg-pascal-devel] Bug#970014: Workaround proposal

[Frédéric Bonnard]

On Wed, 23 Sep 2020 15:01:55 +0200, Graham Inggs  wrote:
> Hi Frédéric
> 
> On Wed, 23 Sep 2020 at 10:47, Frédéric Bonnard  wrote:
> > Debug info type's recommended setting seems to be dwarf anyway (32/64b).
> > So I've replaced -gs with -gw in components/chmhelp/lhelp/Makefile.fpc.
> > It builds on amd64, i386 and ppc64el at least.
> > I'll send another merge request.
> 
> Works for me!  (on plummer and ubuntu)
> Also ddrescueview now builds on ppc64el as well.  I can't build
> doublecmd yet, because lcl-qt5 wasn't built from src:lazarus on
> ppc64el,  I'm going to see now if I can enable that.

oh right, I didn't realize not all binary packages are built on "any". 2
needs to be enabled (lcl-qt5-2.0 and lazarus-ide-qt5-2.0). And I tested
and they build well on ppc64el.
I'll also tested on ppc64 and provided pie is disabled too, it works
too.
So I'll send another MR for those 2 improvements.

> 
> Regards
> Graham


signature.asc
Description: PGP signature

Bug#970014: [Pkg-pascal-devel] Bug#970014: Workaround proposal

[Frédéric Bonnard]

Hi Graham,
indeed, it fails :)
Not sure if something changed in the build deps or if I just missed one
of the bits I mentioned previously, that was actually needed ; probably
the latter.

Debug info type's recommended setting seems to be dwarf anyway (32/64b).
So I've replaced -gs with -gw in components/chmhelp/lhelp/Makefile.fpc. 
It builds on amd64, i386 and ppc64el at least.
I'll send another merge request.

Thanks for letting me know!

F.

On Mon, 21 Sep 2020 11:10:30 +0200, Graham Inggs  wrote:
> Hi Frédéric
> 
> On Thu, 10 Sep 2020 at 11:27, Frédéric Bonnard  wrote:
> > So I just built without pie nor -gw and -gs removal and everything
> > builds and runs fine.
> > So my workaround is that one :
> > https://salsa.debian.org/pascal-team/lazarus/-/merge_requests/2
> 
> I tried building lazarus with your patch on ppc64el in Ubuntu, but it
> failed with the following:
> 
> Compiling basecontentprovider.pas
> Assembling basecontentprovider
> lib/powerpc64-linux/basecontentprovider.s: Assembler messages:
> lib/powerpc64-linux/basecontentprovider.s:1096: Error: can't resolve
> `.text.n_basecontentprovider_$$_registercontentprovider$ansistring$tbasecontentproviderclass$$boolean'
> {.text.n_basecontentprovider_$$_registercontentprovider$ansistring$tbasecontentproviderclass$$boolean
> section} - 
> `.BASECONTENTPROVIDER_$$_REGISTERCONTENTPROVIDER$ANSISTRING$TBASECONTENTPROVIDERCLASS$$BOOLEAN'
> {*UND* section}
> ...
> many similar errors
> ...
> lib/powerpc64-linux/basecontentprovider.s:2099: Error: can't resolve
> `.text.n_basecontentprovider_$$_finalize$'
> {.text.n_basecontentprovider_$$_finalize$ section} -
> `.BASECONTENTPROVIDER_$$_finalize$' {*UND* section}
> basecontentprovider.pas(153) Error: Error while assembling exitcode 1
> basecontentprovider.pas(153) Fatal: There were 2 errors compiling
> module, stopping
> Fatal: Compilation aborted
> 
> I then tried on plummer.debian.org and got the same result.  Did you
> see anything similar?
> 
> Regards
> Graham


signature.asc
Description: PGP signature

Bug#970014: Workaround proposal

[Frédéric Bonnard]

Control: tags -1 patch

--

I'm no Free Pascal expert but having a look at the build on fedora which
work, I saw that they pass -gw to the build command that fails here in
Debian and that works on Fedora.
Which I tried and make it work :
/usr/bin/ppcppc64 -gs -gl -Sghi -O3 -dlclqt5 -Fu. 
-Fu../../../components/lazutils/lib/powerpc64-linux 
-Fu../../../packager/units/powerpc64-linux 
-Fu../../../lcl/units/powerpc64-linux -Fu../../../lcl/units/powerpc64-linux/qt5 
-Fu../../../components/cairocanvas/lib/powerpc64-linux/qt5 
-Fu../../../components/turbopower_ipro/units/powerpc64-linux/qt5 
-Fu../../../components/printers/lib/powerpc64-linux/qt5 
-Fu../packages/help/lib/powerpc64-linux/qt5 
-Fu/usr/lib/powerpc64le-linux-gnu/fpc/3.2.0/units/powerpc64-linux/rtl -FE. 
-FUlib/powerpc64-linux -Fl/usr/lib/gcc/powerpc64le-linux-gnu/10 -Flinclude 
-Fl/etc/ld.so.conf.d/*.conf @/<>/debian/deb-host-fpc.cfg 
-dpowerpc64 lhelp.lpr

Here -gs is specified :
components/chmhelp/lhelp/Makefile.fpc:options=-gs -gl -Sghi -O3 
-dlcl$(LCL_PLATFORM) $(DBG_OPTIONS)

I understand from here that for 64b -gw should be better
https://wiki.freepascal.org/GDB_Debugger_Tips#Stabs_.28only_GDB.29

So removing -gs in favor of -gw makes it work and everything builds, but when
lazbuild is run for "all" packages, this one crashes with :
'error while loading shared libraries: R_PPC64_ADDR16_HA reloc'

And this one, seems related to pie issues.
So I just built without pie nor -gw and -gs removal and everything
builds and runs fine.
So my workaround is that one :
https://salsa.debian.org/pascal-team/lazarus/-/merge_requests/2

I tried to detailed my tries with gs/gw in case that aspect has some
interest later.

F.


signature.asc
Description: PGP signature

Bug#970014: FTBFS on ppc64el

[Frédéric Bonnard]

Package: src:lazarus
Version: 2.0.10+dfsg-2
Control: tags -1 ftbfs

--

Dear maintainer,
lazarus fails to build on ppc64el :
https://buildd.debian.org/status/fetch.php?pkg=lazarus=ppc64el=2.0.10%2Bdfsg-2=1597568160=0


Regards,


F.


signature.asc
Description: PGP signature

Bug#963116: FTBFS on ppc64el and others

[Frédéric Bonnard]

Package: src:arbtt
Version: 0.10.2-0.1
Control: tags -1 ftbfs

--

Dear maintainer,
arbtt fails to build on ppc64el :
https://buildd.debian.org/status/fetch.php?pkg=arbtt=ppc64el=0.10.2-0.1=1592498657=0

but trying on amd64, it failed the same way, the buildd log on amd64
being much older than the ppc64el one at the moment.
I just picked and verified an upstream patch.
Given the lowNMU level, I'll NMU arbtt with that change only.

Regards,


F.


signature.asc
Description: PGP signature

Bug#962402: haskell-text-icu built

[Frédéric Bonnard]

Hi,
I wanted to check that FTBFS but it actually built, on different setup.
After a give back on ppc64el and s390x, everything went fine. Very few
changes between the failing and succeeding build. Same ghc, kernel.
For the record, linux-libc-dev, libgmpxx4ldbl, libgmp-dev, libkrb5support0,
libk5crypto3, libkrb5-3, libgssapi-krb5-2, libnghttp2-14, hscolour were
not the same.

F.


signature.asc
Description: PGP signature

Bug#962667: Fix FTBFS

[Frédéric Bonnard]

Control: tags -1 patch

--

Dear maintainer,
upstream has a commit for that : which I imported and improved as well.
Here is a merge request for ardour packaging :
https://salsa.debian.org/multimedia-team/ardour/-/merge_requests/2

Regards,


F.


signature.asc
Description: PGP signature

Bug#962667: FTBFS on ppc64el

[Frédéric Bonnard]

Package: src:ardour
Version: 1:6.0.0~ds0-1
Control: tags -1 ftbfs

--

Dear maintainer,
ardour fails to build on ppc64el since 1:6.0.0~ds0-1 as shown here :
https://buildd.debian.org/status/logs.php?pkg=ardour

Regards,


F.


signature.asc
Description: PGP signature

Bug#961599: Issues on depending packages on ppc64el

[Frédéric Bonnard]

Package: src:simde
Version:0.0.0.git.20200522-1

--

Dear maintainer,

since last version of simde, I noticed that bowtie2 fails on
ppc64el while it was not on a very similar version before but using
0.0.0.git.20200424-1 (I confirmed that by trying to rebuild bowtie2
2.4.1-4 which now fails)

https://buildd.debian.org/status/logs.php?pkg=bowtie2
The error reported is :
https://buildd.debian.org/status/fetch.php?pkg=bowtie2=ppc64el=2.4.1-5=1590436839=0
 I also got it with mmseqs2 .

I tried with simde's latest git tree as of 20200526 and it works. I
didn't dig more to identify precisely the problem, but you may know as
you follow simde's development more closely.


Regards,


F.
diff -Nru tnftp-20151004/debian/rules tnftp-20151004/debian/rules
--- tnftp-20151004/debian/rules 2020-05-10 16:01:50.0 +0200
+++ tnftp-20151004/debian/rules 2020-05-10 16:01:50.0 +0200
@@ -17,6 +17,7 @@
 build: build-stamp
 build-stamp:
dh_testdir
+   dh_update_autotools_config
./configure --prefix=/usr --mandir=\$${prefix}/share/man
$(MAKE)
touch build-stamp


signature.asc
Description: PGP signature

Bug#961008: FTBFS on tnftp

[Frédéric Bonnard]

Package: src:tnftp
Version: 20151004-1
Control: tags -1 ftbfs patch

--

Dear maintainer,
tnftp fails to build on ppc64el ( probably the same issue on arm64,
riscv64 ) due to an outdated config.guess.
Here is a minimal patch that does the work.


Regards,


F.
diff -Nru tnftp-20151004/debian/rules tnftp-20151004/debian/rules
--- tnftp-20151004/debian/rules 2020-05-10 16:01:50.0 +0200
+++ tnftp-20151004/debian/rules 2020-05-10 16:01:50.0 +0200
@@ -17,6 +17,7 @@
 build: build-stamp
 build-stamp:
dh_testdir
+   dh_update_autotools_config
./configure --prefix=/usr --mandir=\$${prefix}/share/man
$(MAKE)
touch build-stamp


signature.asc
Description: PGP signature

Bug#960354: ytcc: diff for NMU version 1.8.1-1.1

[Frédéric Bonnard]

Hi Boyuan,
thanks for the NMU, no problem with the delay. There's a new upstream release,
but I won't package it right away. So all good!

F.

May 17, 2020 5:48 PM, "Boyuan Yang"  wrote:

> Control: tags 960354 + patch
> Control: tags 960354 + pending
> 
> Dear maintainer,
> 
> I've prepared an NMU for ytcc (versioned as 1.8.1-1.1) and
> uploaded it to DELAYED/7. Please feel free to tell me if I
> should delay it longer.
> 
> Regards.
> 
> diff -Nru ytcc-1.8.1/debian/changelog ytcc-1.8.1/debian/changelog
> --- ytcc-1.8.1/debian/changelog 2019-05-08 23:00:16.0 +0800
> +++ ytcc-1.8.1/debian/changelog 2020-05-17 23:31:49.0 +0800
> @@ -1,3 +1,10 @@
> +ytcc (1.8.1-1.1) unstable; urgency=medium
> +
> + * Non-maintainer upload.
> + * Source-only upload to allow testing migration. (Closes: #960354)
> +
> + -- Boyuan Yang  Sun, 17 May 2020 23:31:49 +0800
> +
> ytcc (1.8.1-1) unstable; urgency=medium
> 
> * Initial release. (Closes: #928755)

Bug#959943: FTBFS on ppc64el

[Frédéric Bonnard]

Sorry for the wrong link.
Merge request : https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4948


signature.asc
Description: PGP signature

Bug#959943: FTBFS on ppc64el

[Frédéric Bonnard]

Hi Timo,
there's no update upstream on the merge request I did :
https://buildd.debian.org/status/fetch.php?pkg=vim=ppc64el=2%3A8.2.0716-3=1589254422=0

I've changed a bit the patch compared to the one I submitted in Debian, but the 
idea is the same.

F.

On Thu, 7 May 2020 22:41:46 +0200, Frédéric Bonnard  wrote:
> > > Here is a merge request for review :
> > > https://salsa.debian.org/xorg-team/lib/mesa/-/merge_requests/13
> > 
> > this is merged now, and I commented that I hope you could send it upstream..
> 
> Thanks Timo!
> I sent a merge request to mesa a few hours ago. But one of the file I
> patched is actually copied by mesa from another project, so my merge
> request needs to be split :
> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4948
> 
> I'll follow up on that monday and will keep you updated.
> 
> Regards,
> 
> F.


signature.asc
Description: PGP signature

Bug#921527: Fix FTBFS

[Frédéric Bonnard]

Control: tags -1 patch

--

Dear maintainer,
this issue is most probably due to char sign-ness .
The list of architectures needing char to be forced as signed because
by default they are unsigned (
https://wiki.debian.org/ArchitectureSpecificsMemo ) needs to be
extended.
See the attached debdiff. I confirm this works on ppc64el at least.

Regards,


F.
diff -Nru cuneiform-1.1.0+dfsg/debian/rules cuneiform-1.1.0+dfsg/debian/rules
--- cuneiform-1.1.0+dfsg/debian/rules   2018-01-13 20:33:42.0 +0100
+++ cuneiform-1.1.0+dfsg/debian/rules   2018-01-13 21:16:06.0 +0100
@@ -3,7 +3,7 @@
 DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
 DEB_BUILD_ARCH ?= $(shell dpkg-architecture -qDEB_BUILD_ARCH)
 
-ifneq (,$(filter $(DEB_BUILD_ARCH),armhf arm64))
+ifneq (,$(filter $(DEB_BUILD_ARCH),armhf arm64 armel ppc64el s390x))
 SIGNED_CHAR = -fsigned-char
 else
 SIGNED_CHAR =


signature.asc
Description: PGP signature

Bug#959943: FTBFS on ppc64el

[Frédéric Bonnard]

> > Here is a merge request for review :
> > https://salsa.debian.org/xorg-team/lib/mesa/-/merge_requests/13
> 
> this is merged now, and I commented that I hope you could send it upstream..

Thanks Timo!
I sent a merge request to mesa a few hours ago. But one of the file I
patched is actually copied by mesa from another project, so my merge
request needs to be split :
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4948

I'll follow up on that monday and will keep you updated.

Regards,

F.


pgp2xRJWm1gCx.pgp
Description: PGP signature

Bug#959943: FTBFS on ppc64el

[Frédéric Bonnard]

Control: tags -1 patch

--

Here is a merge request for review :
https://salsa.debian.org/xorg-team/lib/mesa/-/merge_requests/13

Regards,


F.


pgphsIBUavl8n.pgp
Description: PGP signature

Bug#959880: FTBFS on ppc64el

[Frédéric Bonnard]

Control: tags -1 patch

--

Here is a merge request for review :
https://salsa.debian.org/med-team/spoa/-/merge_requests/1

Regards,


F.


pgpWvO7pZsIro.pgp
Description: PGP signature

Bug#959943: FTBFS on ppc64el

[Frédéric Bonnard]

Package: src:mesa
Version: 20.0.6-1
Control: tags -1 ftbfs

--

Dear maintainer,
mesa fails to build on ppc64el since 20.0.4-2 as shown here :
https://buildd.debian.org/status/fetch.php?pkg=mesa=ppc64el=20.0.6-1=1588668604=0
I've prepared a patch for review.

Regards,


F.


pgppFuVlSjAk3.pgp
Description: PGP signature

Bug#959880: FTBFS on ppc64el

[Frédéric Bonnard]

Package: src:spoa
Version: 3.0.2-4
Control: tags -1 ftbfs

--

Dear maintainer,
spoa fails to build on ppc64el as shown here :
https://buildd.debian.org/status/fetch.php?pkg=spoa=ppc64el=3.0.2-4=1588509193=0
It looks like the recurrent issue being the collision between altivec
and std c++ types.

Regards,


F.


pgpgKSQciU4DD.pgp
Description: PGP signature

Bug#959866: FTBFS on ppc64el

[Frédéric Bonnard]

Package: src:last-align
Version: 1060-3
Control: tags -1 ftbfs

--

Dear maintainer,
last-align fails to build on ppc64el as shown here :
https://buildd.debian.org/status/fetch.php?pkg=last-align=ppc64el=1060-3=1587335358=0

It looks like the recurrent issue being the collision between altivec
and std c++ types.

Regards,


F.


pgpmdtvLGgOSR.pgp
Description: PGP signature

Bug#956220: FTBFS: FileNotFoundError

[Frédéric Bonnard]

Package: src:q2-cutadapt
Version: 2019.10.0-1
Control: tags -1 ftbfs

--

Dear maintainer,
trying to reproduce the ppc64el specific failure : 
https://buildd.debian.org/status/fetch.php?pkg=q2-cutadapt=ppc64el=2019.10.0-1=1582306016=0

I actually found out that q2-cutadapt fails to build on ppc64el as well
as on amd64 and maybe more currently. Maybe something related with qiime ?

--
q2_cutadapt/tests/test_demux.py FFF..   
  [ 73%]
q2_cutadapt/tests/test_trim.py .
  [100%]

=== FAILURES 

___ 
TestDemuxSingle.test_all_matched 


self = 

def test_all_matched(self):
metadata = CategoricalMetadataColumn(
pd.Series(['', '', ''], name='Barcode',
  index=pd.Index(['sample_a', 'sample_b', 'sample_c'],
 name='id')))

with redirected_stdio(stderr=os.devnull):
obs_demuxed_art, obs_untrimmed_art = \
>   self.demux_single_fn(self.muxed_sequences, metadata)

q2_cutadapt/tests/test_demux.py:82:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
:2: in demux_single
???
/usr/lib/python3/dist-packages/qiime2/sdk/action.py:215: in bound_callable
provenance.add_input(name, artifact)
/usr/lib/python3/dist-packages/qiime2/core/archive/provenance.py:406: in 
add_input
self.inputs[name] = self.add_ancestor(input)
/usr/lib/python3/dist-packages/qiime2/core/archive/provenance.py:157: in 
add_ancestor
shutil.copytree(
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

src = 
'/tmp/qiime2-archive-v4zvnm2n/c361bb75-7dcd-4a97-976e-629b57020e7c/provenance'
dst = 
'/tmp/qiime2-provenance-pnb_bn2t/artifacts/c361bb75-7dcd-4a97-976e-629b57020e7c',
 symlinks = False
ignore = ._ignore_patterns at 
0x7f76a7814310>, copy_function = 
ignore_dangling_symlinks = False, dirs_exist_ok = False

def copytree(src, dst, symlinks=False, ignore=None, copy_function=copy2,
 ignore_dangling_symlinks=False, dirs_exist_ok=False):
"""Recursively copy a directory tree and return the destination 
directory.

dirs_exist_ok dictates whether to raise an exception in case dst or any
missing parent directory already exists.

If exception(s) occur, an Error is raised with a list of reasons.

If the optional symlinks flag is true, symbolic links in the
source tree result in symbolic links in the destination tree; if
it is false, the contents of the files pointed to by symbolic
links are copied. If the file pointed by the symlink doesn't
exist, an exception will be added in the list of errors raised in
an Error exception at the end of the copy process.

You can set the optional ignore_dangling_symlinks flag to true if you
want to silence this exception. Notice that this has no effect on
platforms that don't support os.symlink.

The optional ignore argument is a callable. If given, it
is called with the `src` parameter, which is the directory
being visited by copytree(), and `names` which is the list of
`src` contents, as returned by os.listdir():

callable(src, names) -> ignored_names

Since copytree() is called recursively, the callable will be
called once for each directory that is copied. It returns a
list of names relative to the `src` directory that should
not be copied.

The optional copy_function argument is a callable that will be used
to copy each file. It will be called with the source path and the
destination path as arguments. By default, copy2() is used, but any
function that supports the same signature (like copy()) can be used.

"""
sys.audit("shutil.copytree", src, dst)
>   with os.scandir(src) as itr:
E   FileNotFoundError: [Errno 2] No such file or directory: 
'/tmp/qiime2-archive-v4zvnm2n/c361bb75-7dcd-4a97-976e-629b57020e7c/provenance'

/usr/lib/python3.8/shutil.py:552: FileNotFoundError
--

Regards,


F.


pgps5GuixUCWr.pgp
Description: PGP signature

Bug#952759: libsass-python 0.18.0 FTBFS with libsass 3.6.3, please upgrade to 0.19.4

[Frédéric Bonnard]

Hi Anthony

March 9, 2020 8:30 AM, "Anthony Fok"  wrote:

> Control: severity -1 serious
> Control: tags -1 + ftbfs sid
> Control: found -1 0.18.0-1
> 
> On Fri, 28 Feb 2020 17:38:13 +0100 Michael Fladischer  
> wrote:
> 
>> Source: libsass-python
>> Severity: wishlist
>> 
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA512
>> 
>> Dear Maintainer,
>> 
>> right now there is 0.19.4 available from upstream. Would you consider 
>> uploading
>> an updated package to the archive?
>> 
>> Cheers,
>> Michael
> 
> Dear Frédéric,
> 
> I understand that the reason you uploaded libsass-python 0.18.0-1 in
> January 2020, even though 0.19.4 was already released November 2019,
> was to match the existing libsass 3.5.5-4 in Debian.

true

> That changed about 10 days ago on 2020-02-28 when I uploaded libsass
> 3.6.3-1 to Debian sid, and indeed, libsass-python 0.18.0-1 FTBFS with
> libsass 3.6.3-1 with the following errors:
> 
> FAIL: test_importer_returns_wrong_tuple_size_too_big
> (sasstests.CompileTestCase)
> FAIL: test_importer_returns_wrong_tuple_size_zero (sasstests.CompileTestCase)
> FAIL: test_importers_raises_exception (sasstests.CompileTestCase)
> FAIL: test_error (sasstests.CustomFunctionsTest)
> FAIL: test_raises (sasstests.CustomFunctionsTest)
> FAIL: test_returns_unknown_object (sasstests.CustomFunctionsTest)
> FAIL: test_warning (sasstests.CustomFunctionsTest)
> 
> which all go away with libsass-python 0.19.4.

expected at some point :)
I remember having checked in January the status of libsass which latest
version was still in experimental.

> So, it would be great if you could upload libsass-python 0.19.4-1. :-)
> 
> In case you are busy, since I have been fixing the ruby-sassc and
> node-node-sass packages which also FTBFS due to the libsass 3.6.3
> upgrade, I would be very happy to make an NMU upload of libsass-python
> 0.19.4-0.1, which I have prepared at my fork at
> https://salsa.debian.org/foka/libsass-python, and which I am happy to
> upload any time, with your permission of course.

It would be a shame to lose the work you've done already and that I didn't
do, so feel free to NMU libsass-python.

> Please let me know soon, especially because I would like to solve all
> remaining libsass 3.6.3 upgrade issues, hopefully in time for Ubuntu
> 20.04 LTS release.

No worries, thanks a bunch for all the work and kind mail.

Fred

> Many thanks!
> 
> Yours truly,
> 
> Anthony Fok

Bug#950731: FTBFS on ppc64el :

[Frédéric Bonnard]

On Wed, 05 Feb 2020 14:35:53 -0600, Steve Robbins  wrote:
> Thanks!   Do you know why only ppc64el fails?

Hi Steve,
VSX is a POWER technology and opencv package enables VSX only on ppc64el :
https://sources.debian.org/src/opencv/4.2.0+dfsg-4/debian/rules/#L23
because of :
https://github.com/opencv/opencv/commit/d08074869da1ed7c004f1d5f34ed0c0eb4a8

So digikam because of opencv, gets vector, pixel and bool undefined only on
ppc64el (to not collide with some c++ symbols having the same name). We
can still make use of VSX by using __vector, __pixel, __bool.

F.


pgprY8j2HnVPy.pgp
Description: PGP signature

Bug#950731: FTBFS on ppc64el :

[Frédéric Bonnard]

Package: src:digikam
Version: 4:6.4.0+dfsg-1
Control: tags -1 ftbfs patch

--

Dear maintainer,
latest 4:6.4.0+dfsg-1 fails to build on ppc64el here :
https://buildd.debian.org/status/fetch.php?pkg=digikam=ppc64el=4%3A6.4.0%2Bdfsg-1=1580716901=0

Opencv undefines vector, bool and pixel on purpose (
https://en.wikipedia.org/wiki/AltiVec#Issues )

I wrote a patch to fix this :
https://salsa.debian.org/debian/digikam/merge_requests/1

Regards,


F.


pgpHrKFMW6Q3V.pgp
Description: PGP signature

Bug#950567: FTBFS: expected unqualified-id before string constant

[Frédéric Bonnard]

Package: src:wp2latex
Version: 3.86-1
Control: tags -1 ftbfs patch

--

Dear maintainer,
latest 3.86-1 fails to build on multiple architectures with the
following error :
---
In file included from wp2latex.cc:29:
wp2latex.h:20:25: error: expected unqualified-id before string constant
   20 | #define version "3.86"
  | ^~
---

Actually that "version" keyword collides deep in some arch-specific header : for
example on ppc64el, I get this :
---
# 201 "/usr/include/powerpc64le-linux-gnu/asm/ptrace.h" 3 4
struct ppc_debug_info {

# 202 "/usr/include/powerpc64le-linux-gnu/asm/ptrace.h"
__u32 "3.86"
---

Renaming from "version" to "versionwp2l" in the source, for example, does the 
trick.

Regards,


F.
diff -Nru wp2latex-3.86/debian/patches/fix-version-keyword-FTBFS.patch 
wp2latex-3.86/debian/patches/fix-version-keyword-FTBFS.patch
--- wp2latex-3.86/debian/patches/fix-version-keyword-FTBFS.patch
1970-01-01 01:00:00.0 +0100
+++ wp2latex-3.86/debian/patches/fix-version-keyword-FTBFS.patch
2019-12-20 20:56:49.0 +0100
@@ -0,0 +1,64 @@
+--- a/sources.cc/pass2.cc
 b/sources.cc/pass2.cc
+@@ -292,7 +292,7 @@
+ int i;
+ string TeX_RelativeFigDir;
+ 
+-  fprintf(this->LaTeX,_("%% This file was created by the WP2LaTeX program 
version: %s \n"), version );
++  fprintf(this->LaTeX,_("%% This file was created by the WP2LaTeX program 
version: %s \n"), versionwp2l );
+   if(LaTeX_Version<0x300)
+ {
+ fprintf(this->LaTeX, "\\documentstyle[11pt,");
+--- a/sources.cc/wp2latex.cc
 b/sources.cc/wp2latex.cc
+@@ -319,7 +319,7 @@
+  if(Verbosing < 1) return;
+  printf(_("\n>>>WP2LaTeX<<< Conversion program: From Wordperfect to LaTeX 
Version %s \n"
+ "  (c) Made by J.Fojtik   Date : 1996-2019\n"),
+-  version);
++  versionwp2l);
+ }
+ 
+ 
+@@ -733,7 +733,7 @@
+   else fprintf(logg,_("%% log file for converted file %s, %s ver %d.%d\n"
+ "%% conversion program WP2LaTeX v. %s from %s.\n"),
+  wpd_filename(), chk(FilForD.DocumentType), 
FilForD.DocVersion>>8, FilForD.DocVersion & 0xFF,
+-   version, versiondate);
++   versionwp2l, versiondate);
+   }
+ }
+ 
+--- a/sources.cc/wp2latex.h
 b/sources.cc/wp2latex.h
+@@ -17,7 +17,7 @@
+ 
+ #define LineLength   80   /* Split lines after more than 
LineLength charcters */
+ 
+-#define version "3.86"
++#define versionwp2l "3.86"
+ #define versiondate "21 Dec 2019"  /* day (space) month (space) full year */
+ 
+ #ifndef false
+--- a/sources.cc/wp2l_lib.cc
 b/sources.cc/wp2l_lib.cc
+@@ -1842,7 +1842,7 @@
+   }
+   if(!strcmp(name, "v"))
+   {
+-  fprintf(err,_("wp2latex %s   %s\n  
modules:("),version,versiondate);
++  fprintf(err,_("wp2latex %s   %s\n  
modules:("),versionwp2l,versiondate);
+   FFormatTranslator *Fx;
+   Fx = FFormatTranslator::first();
+   while(Fx!=NULL)
+--- a/sources.cc/images.cc
 b/sources.cc/images.cc
+@@ -222,7 +222,7 @@
+ IncludeFeature: *PageSize Letter\n\
+ EndSetup\n\
+ EndComments\n",
+-Filename,version,versiondate);
++Filename,versionwp2l,versiondate);
+ 
+ fprintf(PostScript,"\
+ /$F2psDict 200 dict def\n\
diff -Nru wp2latex-3.86/debian/patches/series 
wp2latex-3.86/debian/patches/series
--- wp2latex-3.86/debian/patches/series 2019-12-20 20:56:49.0 +0100
+++ wp2latex-3.86/debian/patches/series 2019-12-20 20:56:49.0 +0100
@@ -3,3 +3,4 @@
 sources.cc_pass1_3.cc.patch
 sources.cc_wp2l_lib.cc.patch
 no_copy_binary.patch
+fix-version-keyword-FTBFS.patch


pgpmDY_Zb13l2.pgp
Description: PGP signature

Bug#950347: FTBFS on ppc64* : error: conflicting declaration ‘typedef long long unsigned int __u64’

[Frédéric Bonnard]

Package: src:bpfcc
Version: 0.12.0-1
Control: tags -1 ftbfs patch

--

Dear maintainer,
latest 0.12.0-1 fails to build here :
https://buildd.debian.org/status/fetch.php?pkg=bpfcc=ppc64el=0.12.0-1=1580365148=0

upstream recently fixed the test :
https://github.com/iovisor/bcc/commit/5098c9dd2538d6256a10f1a67a36ebc867549e7f

Merge request importing that patch :
https://salsa.debian.org/debian/bpfcc/merge_requests/1

Regards,


F.


pgpvR1jJ1fRzO.pgp
Description: PGP signature

Bug#943602: os-autoinst : fix merge request

[Frédéric Bonnard]

Dear maintainer,
I submitted a merge request to fix that FTBFS :
https://salsa.debian.org/debian/os-autoinst/merge_requests/1

Can you have a look at it ?
Regards,

F.


pgpmaUxJMrahX.pgp
Description: PGP signature

Bug#835360: Missing arch support in golang-github-remyoudompheng-bigfft

[Frédéric Bonnard]

The issue at the moment is probably in golang-github-remyoudompheng-bigfft :

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948794.

F.


pgpc90UqaZLFQ.pgp
Description: PGP signature

Bug#948794: Refresh sources to support more arches

[Frédéric Bonnard]

Package: src:golang-github-remyoudompheng-bigfft
Version: 0.0~git20170806.52369c6-1

--

Dear maintainer,

rkt is failing to build on arm, mips and ppc64el because
golang-github-remyoudompheng-bigfft has missing support on those
architectures ( https://github.com/remyoudompheng/bigfft/issues/5 )
I see upstream has added support on these arches. Could you refresh the
sources to the new ones ?

Thanks,

F.


pgpTfhtJ_cO8h.pgp
Description: PGP signature

Bug#948583: ITP: comskip -- Commercial detector

[Frédéric Bonnard]

Package: wnpp
Severity: wishlist

Comskip is a commercial detector. It is a console application that reads a
mpeg or h.264 file and analyses the content based on a large amount of
configurable parameters. A gui is also provided.

After analysis it generates a file in various possible formats containing the
location of the commercials inside the video file.

The formats include input files for interactive video editors (VideoRedo,
Cuttermaran,Mpeg2Schnitt...) command line video cutters (mpgtx, cuttermaran,
mencoder) and video players (zoomplayer, mplayer, ...).

Comskip can read MPEG PS, TS, DVR-MS and WTV files up to UHD resolution (max
4000x2400) at various framerates (PAL and NTSC). Comskip can NOT read copy
protected recordings.

License: GPL-2+
Copyright: 2006-2020 Erik Kaashoek
URL: https://github.com/erikkaashoek/Comskip


pgpN2pdi12UHC.pgp
Description: PGP signature

Bug#948482: ppc64el patch improvement

[Frédéric Bonnard]

Package: src:qd
Version: 2.3.22+dfsg.1-3
Control: tags -1 patch ftbfs

--

Hi,

after contacting the ppc64 toolchain team about bug #935289, especially
Pat Haugen, he said :
---
Basically the testcase is sensitive to
precision differences when FMA instructions are used (floating point
multiply-add). The compiler will generate these insns when it sees
expressions of the form (a * b) + c. If you want to continue to compile the
code at -O2 you'll need to specify the compiler option "-ffp-contract=off"
in order to prevent the FMA transformation(s).
this is just something specific to the values being used in the
testcase. The compiler will continue to generate 'fmadd' type instructions
at -O2 unless -ffp-contract=off is specified. My digging into the testcase
showed that different results were produced based on whether a fmadd insn
was generated for a specific expression. If it was not the result was 0, if
it was the result was some very small value. That value is then used
further and differences compounded, as you could guess.
---

so, so we may improve the patch by changing -fno-tree-pre into -ffp-contract=off

Thanks,

F.


pgpKWm33_tlEt.pgp
Description: PGP signature

Bug#946520: FTBFS on ppc64el

[Frédéric Bonnard]

Package: src:openafs
Version: 1.8.5-1

--

Dear maintainer,
thanks for enabling ppc64el. It seems some more changes are needed for
openafs to build properly :
https://buildd.debian.org/status/fetch.php?pkg=openafs=ppc64el=1.8.5-1=1572239330=0

Here is a merge request that does the job here :
https://salsa.debian.org/debian/openafs/merge_requests/2

Regards,


F.


pgpxKchC05Zxd.pgp
Description: PGP signature

Bug#946283: vsearch on ppc64el

[Frédéric Bonnard]

Package: src:vsearch
Version: 2.14.1-1

--

Dear maintainer,

vsearch compiles out of the box on ppc64el. Could it be possible that
you enable this architecture ?
Thanks.

Regards,


F.


pgpnOPWMzne_1.pgp
Description: PGP signature

Bug#946271: uswsusp on ppc64

[Frédéric Bonnard]

Package: src:uswsusp
Version: 1.0+20120915-6.2

--

Dear maintainer,

I see that configure.ac mention ppc64 . Does that make sense on PowerMac
64b? Would it make sense en Power machines ? I'm not sure which
technology it relies on.
At least it compile on ppc64. It even compiled on ppc64el after
modifying configure.ac but I don't know either if it makes sense there.

Regards,


F.


pgpmmZ5YacAla.pgp
Description: PGP signature

Bug#943329: Build e3 on more architectures

[Frédéric Bonnard]

Package: src:e3
Version: 1:2.71-2

--

Dear maintainer,
is there any reason that e3 isn't built on more arches ?
I tried on ppc64el/ppc64 and it built out of the box.
Maybe "any" could be enabled ?

Regards,


F.


pgp56IfNB_Bsn.pgp
Description: PGP signature

Bug#942850: Build diamond-aligner on any

[Frédéric Bonnard]

Package: src:diamond-aligner
Version: 0.9.26+dfsg-1

--

Dear maintainer,
with some basic changes I could enable diamond-aligner to built on ppc64el.
It actually builds on powerpc, ppc64, i386 and I thought we could enable
it to build on "any". What do you think of that ?
Here is a merge request :
https://salsa.debian.org/med-team/diamond-aligner/merge_requests/1
Thanks.

Regards,


F.


pgpWX1x6FQSet.pgp
Description: PGP signature

Bug#942587: Build crystalhd on ppc64el

[Frédéric Bonnard]

Package: src:crystalhd
Version: 1:0.0~git20110715.fdd2f19-13

--

Dear maintainer,
with some basic changes I could enable crystalhd to built on ppc64el.
Here is a merge request :
https://salsa.debian.org/multimedia-team/crystalhd/merge_requests/1
Thanks.

Regards,


F.


pgpdULCxKRJTt.pgp
Description: PGP signature

Bug#942582: Build cnvkit on ppc64el

[Frédéric Bonnard]

Package: src:cnvkit
Version: 0.9.6-1

--

Dear maintainer,
is there any reason that cnvkit isn't built on ppc64el ?
Looks like it builds out of the box.

Regards,


F.


pgpBHz0tfsw_d.pgp
Description: PGP signature

Bug#942580: Build htslib on i386

[Frédéric Bonnard]

Package: src:htslib
Version: 1.9-11

--

Dear maintainer,
is there any reason that htslib isn't built on i386 ?
Out of curiosity, I tried to build it and it actually worked.

Regards,


F.


pgpkZweNiDBMh.pgp
Description: PGP signature

Bug#942517: Build libssw on ppc64el

[Frédéric Bonnard]

Package: src:libssw
Version: 1.1-2

--

Dear maintainer,
with some basic changes I could enable libssw to built on ppc64el.
Here is a merge request :
https://salsa.debian.org/med-team/libssw/merge_requests/1
Thanks.

Regards,


F.


pgpS7yxtcRGz1.pgp
Description: PGP signature

Bug#942447: Build bwa on ppc64el

[Frédéric Bonnard]

Package: src:bwa
Version: 0.7.17-3

--

Dear maintainer,
with some basic changes I could enable bwa to built on ppc64el.
Here is a merge request :
https://salsa.debian.org/med-team/bwa/merge_requests/1
Thanks.

Regards,


F.


pgp6kVRRrhHYM.pgp
Description: PGP signature

Bug#941658: Build openafs on other ppc64el

[Frédéric Bonnard]

Hi,

> I think the only reason is that I forgot to add it to debian/control after
> upstream merged the necessary bits :(

no worries.

> Thanks for the reminder; I should be able to include that in the next
> upload.

Thanks a lot Ben!


pgpviGOHeGh2J.pgp
Description: PGP signature

Bug#942324: Build bolt-lmm on i386, ppc64el

[Frédéric Bonnard]

Package: src:bolt-lmm
Version: 2.3.4+dfsg-1

--

Dear maintainer,
with some basic changes I could enable bolt-lmm to built on i386 and
ppc64el. I ran example 2 and it seemed to do the job.
Here is a merge request :
https://salsa.debian.org/med-team/bolt-lmm/merge_requests/1
Thanks.

Regards,


F.


pgpEPKO3AVeX4.pgp
Description: PGP signature

Bug#813559: Fix proposal

[Frédéric Bonnard]

Control: tags -1 patch

--

Hi,

I submitted a merge request which enables ngs-sdk to build on ppc64* and
possibly others :
https://salsa.debian.org/med-team/ngs-sdk/merge_requests/1

Regards,


F.


pgpRFWhUMZx9T.pgp
Description: PGP signature

Bug#942178: Build bcal on other architectures

[Frédéric Bonnard]

Package: src:bcal
Version: 2.1+git20190806.6c8d325-1

--

Dear maintainer,
is there any reason that bcal is not built on other architectures
(any/linux-any)?
I tested and it built well on ppc64/ppc64el.

Regards,


F.


pgpAEEO_1oMrY.pgp
Description: PGP signature

Bug#942022: works with rustc 1.36

[Frédéric Bonnard]

Hi,
I see 2.44.14 which previously built, does not built in the very same build
environment where 2.44.15 fails.
Looking at the differences and trying downgrading some build deps, I
found that replacing rustc 1.37 with 1.36 makes 2.44.14 and 2.44.15 build
again in that latest schroot.
Any idea about changes brought by 1.37 ? maybe bisecting rustc could help point 
out some commit.


F.


pgpfveYXdEmmx.pgp
Description: PGP signature

Bug#942034: Build libguytools2 on other architectures

[Frédéric Bonnard]

Bug#941734: Build libguytools2 on other architectures

[Frédéric Bonnard]

Package: src:libguytools2
Version: 2.0.5-3

--

Dear maintainer,
is there any reason that libguytools2 is not built on more architectures ?
I tested on ppc64/ppc64el and it built well, so at least those arches
could be added.

Regards,


F.


pgpsMk81_sY_Q.pgp
Description: PGP signature

Bug#941728: Build kgb on other architectures

[Frédéric Bonnard]

Package: src:kgb
Version: 1.0b4+ds-14

--

Dear maintainer,
is there any reason that kgb is not built on more architectures ?
I tested on ppc64/ppc64el and it built well, so at least those arches
could be added.

Regards,


F.


pgplIUiOAIN2T.pgp
Description: PGP signature

Bug#941725: Build ibsim on other architectures

[Frédéric Bonnard]

Package: src:ibsim
Version: 0.7-2

--

Dear maintainer,
is there any reason that ibsim is not built on more architectures ?
I tested on ppc64/ppc64el and it built well, so at least those arches
could be added.

Regards,


F.


pgpCgrtKRZmqQ.pgp
Description: PGP signature

Bug#780302: Any plan to apply provided patch ?

[Frédéric Bonnard]

Dear maintainers,

do you have any plan to take that patch for ppc64el build ?
It would also fix the current FTBFS on ppc64.

Regards,

F.


pgpOJSrud57_3.pgp
Description: PGP signature

Bug#941659: Build purelibc on ppc64el

[Frédéric Bonnard]

Package: src:purelibc
Version: 0.4.1-2

--

Dear maintainer,
is there any reason that purelibc isn't built on ppc64el ?
I tested on ppc64el and it built well.
Regards,


F.


pgpAw_gk4oE26.pgp
Description: PGP signature

Bug#941658: Build openafs on other ppc64el

[Frédéric Bonnard]

Package: src:openafs
Version: 1.8.4~pre1-1

--

Dear maintainer,
is there any reason that openafs isn't built on ppc64el(maybe linux-any) ?
I tested on ppc64el and with minor modifications (arch verifications in
debian/sysname and debian/module/sysname), it built well.

Regards,


F.


pgpayCiJ9otvA.pgp
Description: PGP signature