Hello Emmanuel,
On Wed, Jul 10, 2024 at 09:20:45PM -0300, Emmanuel Arias wrote:
> Dear maintainer,
>
> I'm going to upload a NMU to fix this RC bug. I'm going to upload in
> DELAYED/3-days. I attached the patch that I applied.
>
> If you have any objections or would you like to make the changes
On Wed, Nov 02, 2022 at 05:45:26PM -0300, Marcos Talau wrote:
> Control: tags 999145 + patch
> Control: tags 999145 + pending
>
>
> Dear maintainer,
>
> I've prepared an NMU for cappuccino (versioned as 0.5.1-10.1) and
> uploaded it to DELAYED/2. Please feel free to tell me if I
> should delay i
Hi Sergei,
On Wed, May 02, 2018 at 06:25:55PM +, Sergei Golovan wrote:
> Hi Bruno,
>
> If you have access to the ppc64el hardware, could you test the fix (I've
> attached a diff, which is to be applied to the 2.1.0-15 sources)? If it's
> okay, I'll ask the release team about a stable update.
Source: tclreadline
Version: 2.1.0-15
Severity: critical
Tags: patch
Dear maintainer,
I just found that this package is not generating the shared object for
ppc64el platform, as showed below:
dpkg -c tcl-tclreadline_2.1.0-15_ppc64el.deb | grep lib/powerpc64le-linux-gnu
drwxr-xr-x root/root
Hi,
On 02/23/2018 03:52 PM, Aurelien Jarno wrote:
> DSA has installed the latest security kernel (4.9.82-1+deb9u2) on the
> Debian POWER8 machines running ppc64el. While they boot correctly, then
> programs segfault randomly (apt, sbuild, systemd, etc...). Passing
> no_rfi_flush to the command li
Although lack of recent updates, we are still working on this problem.
Barry (on CC) is allocated to work on this issue and should have updates soon.
Some new discover I did today:
1) On function do_random(), the 'values' pointer is being corrupted after the
rand() syscall - In the failure case. If I remove the rand() function, I do
not see corruption.
2) If I get the original 'values' pointer, save it and check it later, it is
corrupted also.
hi Ryan,
On 07/11/2017 02:58 AM, Ryan Tandy wrote:
> Today I built Linux 4.12 from upstream source and the test program still
> crashes. I was looking at your fixes to initialize load_{fp,tm,vec} as well
> as someone else fixing the CONFIG_ALIVEC typo but none of those have helped.
Right, I teste
hi Ryan,
On Sun, Jul 09, 2017 at 08:56:59AM -0700, Ryan Tandy wrote:
> There seems to be a regression on powerpc64 (both endians) that can corrupt
> the vector-scalar registers (VSRs) in a threaded program.
>
> I believe the bad commit is this one:
>
> 4.9.0:
> https://github.com/torvalds/linux
Hey Adrian,
On Thu, Jul 06, 2017 at 10:44:21PM +0200, John Paul Adrian Glaubitz wrote:
> Hi Breno!
>
> On 07/06/2017 09:31 PM, Breno Leitao wrote:
> > I think I found the real case of the problem here. There is an array
> > being allocated, and initialized until 'i&
Ryan,
> Nice. I was able to reproduce it and debug it further. The problem seems
> to be related to a invalid branch/jump, the the next address is not
> memory mapped, thus the segfault. The new address is completely random,
> and definitely is wrong.
I think I found the real case of the problem
Hi Ryan,
On Mon, Jul 03, 2017 at 03:39:35PM -0700, Ryan Tandy wrote:
> Hi debian-powerpc,
>
> Would a ppc64(el) porter be able to help me look at #866122? I have
> requested a porterbox account but it's not gone through yet, and I am unable
> to reproduce the issue at all in a qemu VM.
You can al
Package: jsvc
Version: 1.0.15-7
Severity: serious
Tags: patch
Hello, package jsvc does not work on ppc64el right now.
On ppc64 and ppc64le archs jsvc looks for jvm.cfg and JVM shared objects
in the wrong path. Be it used with IBM Java or OpenJDK (where the
problem was first encountered), there is
Hi Martin,
On Thu, 09 Feb 2017 17:34:33 + Martin Pitt wrote:
> Source: systemd
> Source-Version: 232-16
How will it show up in Stretch?
Are you going to move systemd to 232-16 or backport the patch to stretch 232-15?
Thank you,
Breno
Hi Adrian,
On 01/04/2017 08:50 AM, John Paul Adrian Glaubitz wrote:
> Hi!
>
> The current version 7.4.4-3 of libatomic-ops builds fine on all architectures
> [1].
> Can we close this or am I missing something?
I understand that they are building because the tests are being bypassed as
an workar
We just created a pull request to have this fixed upstream.
https://github.com/pydata/numexpr/pull/235
Should we create a Debian patch also?
On 11/20/2016 07:41 AM, Adrian Bunk wrote:
>
> Lots of failures like:
>
Yes. I just tried it here, and more than 40 tests failed.
It is usually off by 1, and I am wondering if we are being bite by a similar
issue I found on OpenJDK, where there are math inconsistency when using
optimization hig
I just tested haskell-zeromq4-haskell build with a patched GHC and it
worked fine, so, I understand also that the problem is fixed.
I just installed the packages also, and they seem to be working properly:
dpkg -l | grep zeromq
ii libghc-zeromq4-haskell-dev 0.6.5-5
reassign ghc
After some further debug, I found this is, in fact, a ghc bug and it was
fixed in version 8.0.2, as showed in:
https://ghc.haskell.org/trac/ghc/ticket/12621
Source: haskell-zeromq4-haskell
Version: 0.6.5
Severity: serious
Justification: fails to build from source (but built successfully in the past)
The package haskell-zeromq4-haskell is failing to build on ppc64el port
due to the following error:
[1 of 6] Compiling System.ZMQ4.Internal.Base (
d
Thanks Andreas,
I am preparing a new version for cappuccino to solve this issue.
value
+ (double checked that it didn't change when compiling with GCC5 and
+ GCC6 with this fix). (Closes: #811789)
+
+ -- Breno Leitao Sun, 17 Jul 2016 18:02:37 -0400
+
zvbi (0.2.35-10) unstable; urgency=medium
* Migrations:
diff -Nru zvbi-0.2.35/debian/patches/09_FTBFS_gcc6.
ebian/changelog 2012-05-13 10:38:30.0 -0400
+++ critterding-1.0-beta12.1/debian/changelog 2016-07-17 17:11:02.0 -0400
@@ -1,3 +1,10 @@
+critterding (1.0-beta12.1-1.3) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fixing FTBFS on GCC 6. (Closes: 811621)
+
+ -- Breno Leitao
-beta12.1/debian/changelog 2016-07-17 17:11:02.0
-0400
@@ -1,3 +1,10 @@
+critterding (1.0-beta12.1-1.3) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fixing FTBFS on GCC 6. (Closes: 811621)
+
+ -- Breno Leitao Sun, 17 Jul 2016 16:46:12 -0400
+
critterding (1.0-beta12.1-1.2
I am looking at this problem, and I understand that the following patch fixes
this problem:
--- critterding-1.0-beta12.1.orig/src/brainz/brainz.cpp
+++ critterding-1.0-beta12.1/src/brainz/brainz.cpp
@@ -137,7 +137,7 @@ Brainz::Brainz()
// clear Motor Outputs
> Please consider
> applying this patch in Debian as well, and forward upstream as necessary.
Just got the patch accepted by upstream maintainer also.
https://github.com/linux-nvme/nvme-cli/commit/90f00efdd89866b5f4f389c0b0a7ca4305c76303
The other two off-the-tree patches were also accepted no
Hello Steve,
On 07/08/2016 06:49 PM, Steve Langasek wrote:
> I've applied the attached patch in Ubuntu to address this. Please consider
> applying this patch in Debian as well, and forward upstream as necessary.
Thanks for fixing it. I just created a new package version with this fix.
The new p
On Fri, 13 May 2016 10:56:25 +0200 (CEST) Thorsten Glaser
wrote:
> With https://buildd.debian.org/status/package.php?p=luajit
> showing the architectures the stand-alone luajit is not
> available for
In fact we have a ppc64el patch for luajit port, but the upstream
maintainer does not commit or
On 11/26/2015 01:32 PM, James Cowgill wrote:
>> The patch attached solves this problem.
>
> You didn't attach a patch :)
Duh! Yes, my patch was similar to yours.
I just tried to build it on ppc64el and it fails with the same mistake.
The patch attached solves this problem.
Source: linux
Version: 3.16.7-ckt9-3~deb8u1
Severity: critical
Tags: security patch
Justification: breaks the whole system
We should cap 64bit userspace backtraces to PERF_MAX_STACK_DEPTH
(currently 127), otherwise we can be lost in a infinite loop when using a
ppc64el machine. :-(
I am attaching
Package: turnserver
Version: 0.7.3-2
Severity: critical
Tags: patch
At the moment, turnserver doesn't build on ppc64el platform with the following
error:
In file included from tls_peer.c:72:0:
/usr/include/netinet/tcp.h:89:11: error: duplicate member 'th_off'
u_int8_t th_off:4; /* data offset
This error is also blocking ppc64el bootstrap, because it fails to compile as
described above.
The ppc64el build log could be found at:
https://buildd.debian.org/status/fetch.php?pkg=pg-reorg&arch=ppc64el&ver=1.1.9-2&stamp=1410770668
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.deb
Thank you, now ruby-ffi compiled fine on ppc64el as shown in the
following build log:
https://buildd.debian.org/status/fetch.php?pkg=ruby-ffi&arch=ppc64el&ver=1.9.6debian-2&stamp=1413238408
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trou
Package: ruby-ffi
Version: 1.9.6debian-1
Severity: serious
Tags: patch
Justification: fails to build from source
Hi,
The package ruby-ffi package fails to build on ppc64el due to two things:
- A bug that consider ppc64 as powerpc (32 bits)
- The platform was not added into the packages.
So,
I was also able to build it according to the suggested patch. It builds
fine on ppc64el also:
dpkg-deb: building package `guile-1.8' in
`../guile-1.8_1.8.8+1-9_ppc64el.deb'.
dpkg-deb: building package `guile-1.8-doc' in
`../guile-1.8-doc_1.8.8+1-9_all.deb'.
dpkg-deb: buil
On Tue, 7 Oct 2014 20:12:32 +0200 Johan Van de Wauw
wrote:
> I'm aware of the issues.
> I've asked for porter access to see if I can fix these problems.
For what arch? For ppc64el, we have the machine pastel that is available as a
porterbox.
Let me know if you are having access to it.
--
To U
I saw the same problem on ppc64el:
http://ftp.unicamp.br/pub/ppc64el/debian/buildd-upstream/build_logs/logs/seed_3.8.1-1_ppc64el.build
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
This is also affecting ppc64el, as shown:
http://ftp.unicamp.br/pub/ppc64el/debian/buildd-upstream/build_logs/logs/gstreamer0.10_0.10.36-1.2_ppc64el.build
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debia
FWIW, this bug is also found during ppc64el bootstrap.
http://ftp.unicamp.br/pub/ppc64el/debian/buildd-upstream/build_logs/logs/wmcoincoin_2.5.1e-1_ppc64el.build
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@list
hi Reto,
On 07/24/2014 06:20 PM, Reto Buerki wrote:
> On 07/24/2014 10:21 PM, Breno Leitao wrote:
>> This is a bug that is impacting ppc64el bootstrap also.
>>
>> My recomendantion is to keep just a build-depend on gnat, unless you have
>> strict
>> dependency
hi Adrian-Ken,
On 07/24/2014 06:25 PM, Adrian-Ken Rueegsegger wrote:
> On 07/24/2014 10:25 PM, Breno Leitao wrote:
>> this is a bug that is impacting ppc64el bootstrap also.
>
> Thanks for reporting.
>
>> My recomendantion is to keep just a build-depend on gnat, un
this is a bug that is impacting ppc64el bootstrap also.
My recomendantion is to keep just a build-depend on gnat, unless you have strict
dependency of version 4.6, which is not the case in 90% of the packages that
depends on version 4.6
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.d
This is a bug that is impacting ppc64el bootstrap also.
My recomendantion is to keep just a build-depend on gnat, unless you have strict
dependency of version 4.6, which is not the case in 90% of the packages that
depends on version 4.6
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.d
FWIW, we also hit the same problem on ppc64el bootstrapping.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
On 07/22/2014 07:01 PM, gregor herrmann wrote:
> On Tue, 22 Jul 2014 18:14:12 -0300, Breno Leitao wrote:
>
>> I face the same problem during ppc64el bootstrap and gregor's patch solve
>> the problem.
>> Gregor, do you mind making a NMU for it?
>
> Uploaded
Hi,
I face the same problem during ppc64el bootstrap and gregor's patch solve the
problem.
Gregor, do you mind making a NMU for it?
Thanks
Breno
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
package from one architecture
+in a multiarch environemnt. Closes: 706185
+
+ -- Breno Leitao Tue, 22 Jul 2014 14:31:57 +
+
libpam-ldap (184-8.6) unstable; urgency=low
* Non-maintainer upload.
Index: libpam-ldap-184/debian/libpam-ldap.postrm
Hi Helmut,
On 07/18/2014 03:52 PM, Helmut Grohne wrote:
> While your patch moves a lot of files, it does not address the
> underlying problem. The libpam-ldap package still creates the very same
> configuration files using its postinst script and it still removes them
> in postrm.
Right. As I expl
Hi,
I played a little bit with this bug, and I find one possible solution is to have
those common config files in a -common package that becomes arch=all. Thus, they
would not be replaced or removed in the scenario reported by Andreas.
In this case, package src:libpam-ldap would generate two bina
I see the same problem during ppc64el bootstrap. I would appreciate
if the patch gets accepted:
The build log for ppc64el could be found at:
http://ftp.unicamp.br/pub/ppc64el/debian/buildd-upstream/build_logs/logs/hotkeys_0.5.7.4-0.3_ppc64el.build
Thank you,
Breno
--
To UNSUBSCRIBE, email to
I am facing the same problem during ppc64el bootstrap.
The build log could be found at:
http://ftp.unicamp.br/pub/ppc64el/debian/buildd-upstream/build_logs/logs/idzebra_2.0.44-3.1_ppc64el.build
I would really appreciate if this get fixed.
Thank you,
Breno
--
To UNSUBSCRIBE, email to debian-b
I am still facing the same issue on package 2.0.0-5, which is suppose
to contain the fix.
I tested on ppc64el, take a look at the problem, which seems to be the same.
The following tests FAILED:
1 - INTEGRATION_audio (Timeout)
3 - INTEGRATION_cfm_damp
The same bug was hit during the compilation on ppc64el and the
full log could be seen at:
http://ftp.unicamp.br/pub/ppc64el/debian/buildd-upstream/build_logs/logs/setools_3.3.8-3_ppc64el.build
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe".
Found the same problem on ppc64el
http://ftp.unicamp.br/pub/ppc64el/debian/buildd-upstream/build_logs/logs/csh_20110502-2_ppc64el.build
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
I am facing the exact same problem during ppc64el bootstrap, as shown:
Makefile:9: config.mk: No such file or directory
Makefile:10: /subdir.mk: No such file or directory
make[1]: Entering directory `/«PKGBUILDDIR»'
make[1]: *** No rule to make target `/subdir.mk'.
We are finding the same problem during ppc64el bootstrap.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Hi,
We are facing the same problem reported by this bug on ppc64el bootstrap.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Hi,
This bugs is avoiding xca to be compiled in ppc64el platform. If you could
accept
the attached patch,the ppc64el team would appreciate.
Thank you,
Breno
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.d
I also found the same problem during ppc64el bootstrap and hideki's patch fix
the
problem.
Please, consider applying it to the libwfut source.
Thank you
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debia
I see the same problem when bootstrap ppc64el.
http://ftp.unicamp.br/pub/ppc64el/debian/buildd-upstream/build_logs/logs/libnfo_1.0.1-1_ppc64el-20140502-0056.build
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lis
Package: liboping
Version: 1.6.2
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Dear Maintainer,
With the recent change on liboping, it is not able to be build anymore. I
tested the build on the ppc64el and amd64 architectures, and both show the
I just reproduced this bug on the ppc64el buildd. This is exact some error:
/usr/bin/ld: cannot find -lz
http://deb1.ltc.br.ibm.com/wanna-buildd-upstream/logs/pynac_0.2.6-1_ppc64el-20140510-0908.build
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubs
63 matches
Mail list logo
