Re: Bug#1057050 closed by Debian FTP Masters (reply to Patrick Franz ) (Bug#1057050: fixed in qt6-multimedia 6.6.1-1)
Control: reopen -1 Hi, looks like this didn't work: > https://buildd.debian.org/status/fetch.php?pkg=qt6-multimedia&arch=powerpc&ver=6.4.2-11&stamp=1705003199&raw=0 Reopening the bug therefore. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Bug#1053767: chromium: please to add support for s390x or armel
Hello William! On Tue, 2023-10-10 at 20:34 +0200, William Desportes wrote: > Chromium could be built on Debian s390x or armel, but it would probably > require some upstream work. > > For now when trying to build on my Linux One s390x VM I got this: > > ERROR at //base/allocator/partition_allocator/partition_alloc.gni:25:3: > Assertion failed. >assert(false, "Unknown CPU: $current_cpu") > Unknown CPU: s390x > > Let me know what direction to go if it's worth trying to add support for > s390x or not. > I would definitely like to have armel supported, maybe it's a more > suitable target. (https://wiki.debian.org/RaspberryPi) > > Once both architectures are built DEP-8 tests will be able to use > chromium-driver on them. I'm afraid this is far beyond the possibilities that a Debian maintainer has. Unless Chromium upstream has full support for a given architecture, it's next to impossible to support the browser or its engine on that particular platform. WebKit and KHTML are currently the most portable browsers followed by Firefox while Chromium really only works on the targets that Google supports. And unless you have a dedicated maintainer, it's next to impossible to get Google upstream support a new architecture. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Bug#1038447: librsvg: FTBFS on big-endian architectures: multiple test regressions since September 2022
> On Jun 18, 2023, at 3:53 PM, Simon McVittie wrote: > > On Sun, 18 Jun 2023 at 14:47:00 +0100, Simon McVittie wrote: >> I rebuilt librsvg in bookworm on the s390x porterbox zelenka, and can >> confirm that 2.54.5+dfsg-1 now fails in bookworm too. So something must >> have triggered a regression between September 2022 and now. > > It would be helpful if someone with suitable hardware could put this > through debbisect or similar to find out which build-dependency triggered > this. TIL about debbisect. I can try to bisect this on big-endian PowerPC, I have root on multiple big-endian machines. Adrian
Re: unbreaking LibreOffices tests on at least release architectures
Hello! On Sun, 2023-06-18 at 09:31 +0200, Rene Engelhard wrote: > Also note I am not talking about the debian-ports architectures. Those I > forgot and I have no problems making them stay into "testsuite ran but > results ignored" set. Why did you send this mail exclusively to debian-ports then? > Right now, the only architectures where the test actually work (ignoring > the occassional breakage on arm64 which is fixed upstream since they do > aarch64 flatpak builds) is amd64 and arm64. > (...) > I don't really like sweeping it under the carpet again and would > actually pursue the "getting those architectures removed from unstable" > way pointed out and (implicitely) approved/suggested by the release team... You want Debian to drop support for all architectures except amd64 and arm64 because a single package doesn't pass its testsuite on the other architectures? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: needs suggestion on LuaJit's IBM architecture dilemma
Hi! On 5/12/22 03:29, M. Zhou wrote: > I learned in disappointment after becoming LuaJit uploader that > the LuaJit upstream behaves uncooperatively especially for IBM > architectures [1]. IIUC, the upstream has no intention to care > about IBM architectures (ppc64el, s390x). > > The current ppc64el support on stable is done through cherry-picked > out-of-tree patch. And I learned that the patch is no longer > functional[2] for newer snapshots if we step away from that > ancient 2.1.0~beta3 release. > > However, architectures like amd64 needs relatively newer version[3], > while IBM architecture still has demand luajit[4] (only the > ancient version will possibly work on IBM archs). I saw that Matej Cepl was replying in the thread who is a colleague of mine and who is the maintainer of the luajit package in openSUSE/SLE. Since SUSE has a commercial interest in working POWER/S390 support, he takes care of the package and makes sure it keeps working on these architectures. My suggestion would be to just pick the packages from openSUSE [1] since they are kept up-to-date. Adrian > [1] https://build.opensuse.org/package/show/devel:languages:lua/luajit -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#950974: sqlite3: Regressions on big-endian targets break other packages
Source: sqlite3
Severity: critical
Tags: patch
Justification: breaks unrelated software
User: debian-s390@lists.debian.org
Usertags: s390x
Hi!
Due to a regression in sqlite3, git has been failing to build from source
on multiple big-endian targets, including the release target s390x [1].
openSUSE has recently cherry-picked two upstream commits which address
this issue [2, 3, 4] and I have verified that these patches fix git
in Debian on ppc64 (and I assume s390x and sparc64 as well). Thus, please
include these patches to unbreak git on ppc64, sparc64 and s390x.
Severity set to 'critical' as this bug breaks unrelated software.
Attaching the two patches taken from openSUSE.
Thanks,
Adrian
> [1] https://marc.info/?l=git&m=158120991004802&w=2
> [2]
> https://build.opensuse.org/package/rdiff/server:database/sqlite3?linkrev=base&rev=241
> [3] https://sqlite.org/src/info/04885763c4cd00cb
> [4] https://sqlite.org/src/info/b20503aaf5b6595a
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Index: ext/fts5/test/fts5matchinfo.test
==
--- ext/fts5/test/fts5matchinfo.test
+++ ext/fts5/test/fts5matchinfo.test
@@ -498,23 +498,26 @@
CREATE VIRTUAL TABLE t1 USING fts5(x, y);
INSERT INTO t1 VALUES('a', 'b');
INSERT INTO t1 VALUES('c', 'd');
}
+if {$tcl_platform(byteOrder)=="littleEndian"} {
+ set res {X'0200'}
+} else {
+ set res {X'0002'}
+}
do_execsql_test 15.1 {
SELECT quote(matchinfo(t1, 'n')) FROM t1 LIMIT 1;
-} {X'0200'}
-
+} $res
do_execsql_test 15.2 {
DELETE FROM t1_content WHERE rowid=1;
SELECT quote(matchinfo(t1, 'n')) FROM t1 LIMIT 1;
-} {X'0200'}
+} $res
fts5_aux_test_functions db
do_execsql_test 15.3 {
SELECT fts5_test_all(t1) FROM t1 LIMIT 1;
} {
{columnsize {0 0} columntext {c d} columntotalsize {2 2} poslist {} tokenize
{c d} rowcount 2}
}
finish_test
-
Index: test/fts4aa.test
==
--- test/fts4aa.test
+++ test/fts4aa.test
@@ -227,17 +227,22 @@
} {1 {database disk image is malformed}}
# 2019-11-18 https://bugs.chromium.org/p/chromium/issues/detail?id=1025467
db close
sqlite3 db :memory:
+if {$tcl_platform(byteOrder)=="littleEndian"} {
+ set res
{X'02000E000E000100010001000100'}
+} else {
+ set res
{X'0002000E000E0001000100010001'}
+}
do_execsql_test fts4aa-6.10 {
CREATE VIRTUAL TABLE f USING fts4();
INSERT INTO f_segdir VALUES (77,91,0,0,'255
77',x'000130804d5c4ddd4d4d7b4d4d4d614d8019ff4d0501204d4d2e4d6e4d4d4d4b4d6c4d004d4d4d4d4d4d3d4d5d4d4d645d4d004d4d4d4d4d4d4d4d4d454d6910004d05054d646c4d004d5d4d4d4d4d3d4d4d4d4d4d4d4d4d4d4d4d69624d4d4d04004d4d4d4d4d604d4ce1404d554d45');
INSERT INTO f_segdir VALUES (77,108,0,0,'255
77',x'000131fa64004d4d4d3c5d4d654d4d4d614d8000ff4d0501204d4d2e4d6e4d4d4dff4d4d4d4d4d4d00104d4d4d4d4d4d4d0400311d4d4d4d4d4d4d4d4d4d684d6910004d05054d4d6c4d004d4d4d4d4d4d3d4d4d4d4d644d4d4d4d4d4d69624d4d4d03ed4d4d4d4d4d604d4ce1404d550080');
INSERT INTO f_stat VALUES
(0,x'808080801064004d4d4d3c4d4d654d4d4d614d8000ff4df6ff1a00204d4d2e4d6e4d4d4d104d4d4d4d4d4d00104d4d4d4d4d4d69574d4d4d31044d4d4d3e4d4d4c4d05004d6910');
SELECT quote(matchinfo(f,'pnax')) from f where f match '0 1';
-} {X'02000E000E000100010001000100'}
+} $res
# 2019-11-18 Detect infinite loop in fts3SelectLeaf()
db close
sqlite3 db :memory:
do_catchsql_test fts4aa-7.10 {
Index: src/insert.c
==
--- src/insert.c
+++ src/insert.c
@@ -2168,16 +2168,18 @@
** Hence, make a complete copy of the opcode, rather than using
** a pointer to the opcode. */
x = *sqlite3VdbeGetOp(v, addrConflictCk);
if( x.opcode!=OP_IdxRowid ){
int p2; /* New P2 value for copied conflict check opcode */
+ const char *zP4;
if( sqlite3OpcodeProperty[x.opcode]&OPFLG_JUMP ){
p2 = lblRecheckOk;
}else{
p2 = x.p2;
}
- sqlite3VdbeAddOp4(v, x.opcode, x.p1, p2, x.p3, x.p4.z, x.p4type);
+ zP4 = x.p4type==P4_INT32 ? SQLITE_INT_TO_PTR(x.p4.i) : x.p4.z;
+ sqlite3VdbeAddOp4(v, x.opcode, x.p1, p2, x.p3, zP4, x.p4type);
sqlite3VdbeChangeP5(v, x.p5);
VdbeCoverageIf(v, p2!=x.p2);
}
nConflictCk--;
addrConflictCk++;
Re: Bug#942674: Acknowledgement (git: FTBFS on big-endian targets - testsuite failure)
Control: tags -1 +patch
The attached patch fixes the problem for me. It comes from [1].
Thanks,
Adrian
> [1] https://www.spinics.net/lists/git/msg368292.html
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From: SZEDER =?utf-8?B?R8OhYm9y?=
To: John Paul Adrian Glaubitz ,
Junio C Hamano
Cc: Todd Zullinger , g...@vger.kernel.org
Subject: [PATCH] test-progress: fix test failures on big-endian systems
On Sat, Oct 19, 2019 at 11:38:40PM +0200, John Paul Adrian Glaubitz wrote:
> The testsuite is failing again on s390x and all other big-endian targets in
> Debian. For a full build log on s390x see [1].
Gah, my progress display fixes strike again...
I think the patch below should fix it, but I could only test it on
little-endian systems. Could you please confirm that it indeed works
on big-endian as well?
--- >8 ---
Subject: [PATCH] test-progress: fix test failures on big-endian systems
In 't0500-progress-display.sh' all tests running 'test-tool progress
--total=' fail on big-endian systems, e.g. like this:
+ test-tool progress --total=3 Working hard
[...]
+ test_i18ncmp expect out
--- expect 2019-10-18 23:07:54.765523916 +
+++ out 2019-10-18 23:07:54.773523916 +
@@ -1,4 +1,2 @@
-Working hard: 33% (1/3)
-Working hard: 66% (2/3)
-Working hard: 100% (3/3)
-Working hard: 100% (3/3), done.
+Working hard: 0% (1/12884901888)
+Working hard: 0% (3/12884901888), done.
The reason for that bogus value is that '--total's parameter is parsed
via parse-options's OPT_INTEGER into a uint64_t variable [1], so the
two bits of 3 end up in the "wrong" bytes on big-endian systems
(12884901888 = 0x3).
Change the type of that variable from uint64_t to int, to match what
parse-options expects; in the tests of the progress output we won't
use values that don't fit into an int anyway.
[1] start_progress() expects the total number as an uint64_t, that's
why I chose the same type when declaring the variable holding the
value given on the command line.
Signed-off-by: SZEDER Gábor
---
t/helper/test-progress.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/helper/test-progress.c b/t/helper/test-progress.c
index 4e9f7fafdf..42b96cb103 100644
--- a/t/helper/test-progress.c
+++ b/t/helper/test-progress.c
@@ -29,7 +29,7 @@ void progress_test_force_update(void);
int cmd__progress(int argc, const char **argv)
{
- uint64_t total = 0;
+ int total = 0;
const char *title;
struct strbuf line = STRBUF_INIT;
struct progress *progress;
--
2.24.0.rc0.472.ga6f06c86b4
Bug#942674: git: FTBFS on big-endian targets - testsuite failure
Source: git Version: 1:2.24.0~rc0-1 Severity: serious Tags: ftbfs Justification: fails to build from source User: debian-s390@lists.debian.org Usertags: s390x Hi! git currently fails to build from source on all big-endian targets due to test suite failures. This includes powerpc, ppc64, sparc64 and s390x which is why this bug has severity serious [1]. There have been testsuite failures on big-endian in the past before, see [2]. I will also notify upstream. Thanks, Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=git&arch=s390x&ver=1%3A2.24.0%7Erc0-1&stamp=1571440098&raw=0 > [2] https://www.spinics.net/lists/git/msg363527.html -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#933519: git: FTBFS on big-endian architectures due to testsuite failures
Source: git Version: 1:2.23.0~rc0-1 Severity: serious Tags: patch upstream ftbfs Justification: fails to build from source User: debian-s390@lists.debian.org Usertags: s390x Hello! git currently fails to build from source on big-endian targets due to testsuite failures [1]. The issue is already known upstream [2] and a patch [3] has been proposed which I think should be included in the Debian package. Thanks, Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=git&arch=s390x&ver=1%3A2.23.0%7Erc0-1&stamp=1564449102&raw=0 > [2] > https://public-inbox.org/git/04b301d54715$3b371a90$b1a54fb0$@nexbridge.com/T/ > [3] https://public-inbox.org/git/20190731012336.ga13...@sigill.intra.peff.net/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: ghc: FTBFS on all architectures which use the unregistered compiler
Hi! On 7/25/19 12:39 AM, John Paul Adrian Glaubitz wrote: > GHC currently fails to build from source on all architectures which use > the unregisterised compiler. James Clarke (CC'ed) has suggested to use these defines for bootstrapping 8.6.5: In includes/rts/storage/ClosureTypes.h, it should be sufficient to add: #define MUT_ARR_PTRS_FROZEN0 MUT_ARR_PTRS_FROZEN_DIRTY #define MUT_ARR_PTRS_FROZEN MUT_ARR_PTRS_FROZEN_CLEAN #define SMALL_MUT_ARR_PTRS_FROZEN0 SMALL_MUT_ARR_PTRS_FROZEN_DIRTY #define SMALL_MUT_ARR_PTRS_FROZEN SMALL_MUT_ARR_PTRS_FROZEN_CLEAN and for rts/RtsSymbols.c, we need to do something similar although I'm not sure that #defines would work here. Either way, we need to temporarily get the symbols stg_MUT_ARR_PTRS_FROZEN_info, stg_MUT_ARR_PTRS_FROZEN0_info, stg_SMALL_MUT_ARR_PTRS_FROZEN_info and stg_SMALL_MUT_ARR_PTRS_FROZEN0_info back to bootstrap GHC 8.6.5 for unregisterised. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#932941: ghc: FTBFS on all architectures which use the unregistered compiler
Source: ghc
Version: 8.6.5+dfsg1-1
Severity: serious
Tags: upstream ftbfs
Justification: fails to build from source
User: debian-s390@lists.debian.org
Usertags: s390x
Hi!
GHC currently fails to build from source on all architectures which use
the unregisterised compiler.
It fails with:
/tmp/ghc94391_0/ghc_3.hc:1332:61: error:
error: ‘stg_MUT_ARR_PTRS_FROZEN0_info’ undeclared (first use in this
function); did you mean ‘stg_MUT_ARR_PTRS_FROZEN_DIRTY_info’?
((struct {W_ x;} __attribute__((packed))*) _cavk)->x =
(W_)&stg_MUT_ARR_PTRS_FROZEN0_info;
^
stg_MUT_ARR_PTRS_FROZEN_DIRTY_info
|
1332 | ((struct {W_ x;} __attribute__((packed))*) _cavk)->x =
(W_)&stg_MUT_ARR_PTRS_FROZEN0_info;
| ^
/tmp/ghc94391_0/ghc_3.hc:1332:61: error:
note: each undeclared identifier is reported only once for each function
it appears in
|
1332 | ((struct {W_ x;} __attribute__((packed))*) _cavk)->x =
(W_)&stg_MUT_ARR_PTRS_FROZEN0_info;
| ^
/tmp/ghc94391_0/ghc_3.hc: In function ‘_cayY’:
/tmp/ghc94391_0/ghc_3.hc:2198:61: error:
error: ‘stg_MUT_ARR_PTRS_FROZEN0_info’ undeclared (first use in this
function); did you mean ‘stg_MUT_ARR_PTRS_FROZEN_DIRTY_info’?
((struct {W_ x;} __attribute__((packed))*) _sada)->x =
(W_)&stg_MUT_ARR_PTRS_FROZEN0_info;
^
stg_MUT_ARR_PTRS_FROZEN_DIRTY_info
There is an upstream bug report [1] and a crude workaround that Fedora uses [2].
Thanks,
Adrian
> [1] https://gitlab.haskell.org/ghc/ghc/issues/15913
> [2]
> https://src.fedoraproject.org/rpms/ghc/blob/06d6e9c3cdcf70a4dd3148b3d524c3c4e896aeee/f/ghc.spec#_359
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Hurd-i386 and kfreebsd-{i386,amd64} removal
Could you PLEASE stop posting to debian-ports@? You are sending these mails to
every Debian Ports architecture mailing list.
I already asked for the third time now.
Thank You,
Adrian
> On May 26, 2019, at 5:34 AM, wrote:
>
> Sorry if this is off-topic, but I can't help asking if that "15381 March
> 1977" was on purpose or just from some wonky email client: 15380 days after
> March 1st 1977 happens to be April 10th 2019, so...
>
> --
> Pengcheng Xu
> https://jsteward.moe/
>
>
>> -Original Message-
>> From: Aurelien Jarno
>> Sent: Saturday, May 25, 2019 4:56 PM
>> To: debian-h...@lists.debian.org; debian-...@lists.debian.org; debian-
>> de...@lists.debian.org; debian-po...@lists.debian.org; ftpmaster@ports-
>> master.debian.org
>> Subject: Re: Hurd-i386 and kfreebsd-{i386,amd64} removal
>>
>> Hi,
>>
>>> On 2019-04-24 12:34, Joerg Jaspert wrote:
>>> On 15381 March 1977, Aurelien Jarno wrote:
> ^^^ HERE
>>>
>> It would be nice to have a bit more than 2 weeks to do all of that.
> Ok. How much? Is 6 or 8 weeks better? I don't think, given how
> long this is on the table already, it doesn't make much difference if its
> 2
>> or 8.
> Just something thats clear defined and not some random, non-clear
> "sometime in the future" point.
The hurd-i386 architecture has been moved to to debian-ports yesterday.
I hope it shows the willingness to do that. Please give us at least
4 more weeks to do the remaining kfreebsd-*. That will provide some
margin to account for the non-infinite free time to work on that
(especially in the freeze period) and possibly to get more disk
space for the debian-ports machine.
>>>
>>> Thats ok, end of May is a nice point to take.
>>>
>>> Thanks for the work and the timeframe for the rest!
>>
>> kfreebsd-amd64 and kfreebsd-i386 have now been moved to debian-ports.
>> As
>> hurd-i386 has been moved earlier, it means that all the 3 architectures have
>> now been moved.
>>
>> Aurelien
>>
>> --
>> Aurelien Jarno GPG: 4096R/1DDD8C9B
>> aurel...@aurel32.net http://www.aurel32.net
Re: Bug#906016: transition: gjs built with mozjs60
Hi! On 12/17/18 4:11 PM, Julien Cristau wrote: >> We might have a patch for s390x in openSUSE/SLE, I'll have a look. There >> also might be one in Fedora we could pick for Debian. >> > https://bugzilla.mozilla.org/show_bug.cgi?id=1488552 is what I was > hitting last time around. That got resolved as fixed a few days ago, > although it depends on a refactoring that's not in 60. Still, might be > worth trying to run SpiderMonkey tests on trunk on 64bit BE and see if > and how much better it is now. Interesting, thanks for the link. I would give it a go over the holidays, I have already put it on my TODO list for the holidays. Can we postpone the decision until after the holidays? Then I have enough time for trying to whip up a patch. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Bug#906016: transition: gjs built with mozjs60
On 12/17/18 3:56 PM, Simon McVittie wrote: > gjs recently switched from mozjs52 to mozjs60, and mozjs60 doesn't work > on s390x (#909536; about 80% of its tests fail, which means I have no > confidence that the resulting binaries would be useful or usable if > we ignored the test failures). This sounds suspicious and more like a single bug that breaks mozjs60 on s390x, maybe similar to the issues we have on SPARC due to the tagged pointers conflicting with the extended virtual address on SPARC. We might have a patch for s390x in openSUSE/SLE, I'll have a look. There also might be one in Fedora we could pick for Debian. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#916615: rust-ripgrep: FTBFS on big-endian targets due to testsuite failures
or a flake of cigar ash;
~~
', tests/multiline.rs:108:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose
backtrace.
stack backtrace:
0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
1: std::sys_common::backtrace::print
2: std::panicking::default_hook::{{closure}}
3: std::panicking::default_hook
4: std::panicking::rust_panic_with_hook
5: std::panicking::continue_panic_fmt
6: std::panicking::begin_panic_fmt
7: integration::multiline::context::{{closure}}
at tests/multiline.rs:108
8: integration::multiline::context
at tests/macros.rs:7
9: integration::multiline::context::{{closure}}
at tests/macros.rs:5
10: core::ops::function::FnOnce::call_once
at libcore/ops/function.rs:238
11: >::call_box
12: __rust_maybe_catch_panic
multiline::only_matching stdout
thread 'multiline::only_matching' panicked at '
printed outputs differ!
expected:
~~
1:Watson
1:Sherlock
2:Holmes
3:Sherlock Holmes
5:Watson
~~
got:
~~
1:Watson
1:Sherlock
2:Holmes
2:Sherlock Holmes
3:Watson
~~
', tests/multiline.rs:59:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose
backtrace.
stack backtrace:
0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
1: std::sys_common::backtrace::print
2: std::panicking::default_hook::{{closure}}
3: std::panicking::default_hook
4: std::panicking::rust_panic_with_hook
5: std::panicking::continue_panic_fmt
6: std::panicking::begin_panic_fmt
7: integration::multiline::only_matching::{{closure}}
at tests/multiline.rs:59
8: integration::multiline::only_matching
at tests/macros.rs:7
9: integration::multiline::only_matching::{{closure}}
at tests/macros.rs:5
10: core::ops::function::FnOnce::call_once
at libcore/ops/function.rs:238
11: >::call_box
12: __rust_maybe_catch_panic
multiline::vimgrep stdout
thread 'multiline::vimgrep' panicked at '
printed outputs differ!
expected:
~~
sherlock:1:16:For the Doctor Watsons of this world, as opposed to the Sherlock
sherlock:1:57:For the Doctor Watsons of this world, as opposed to the Sherlock
sherlock:2:57:Holmeses, success in the province of detective work must always
sherlock:3:49:be, to a very large extent, the result of luck. Sherlock Holmes
sherlock:5:12:but Doctor Watson has to have it taken out for him and dusted,
~~
got:
~~
sherlock:1:16:For the Doctor Watsons of this world, as opposed to the Sherlock
sherlock:1:57:For the Doctor Watsons of this world, as opposed to the Sherlock
sherlock:2:57:Holmeses, success in the province of detective work must always
sherlock:2:49:be, to a very large extent, the result of luck. Sherlock Holmes
sherlock:3:12:but Doctor Watson has to have it taken out for him and dusted,
~~
', tests/multiline.rs:77:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose
backtrace.
stack backtrace:
0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
1: std::sys_common::backtrace::print
2: std::panicking::default_hook::{{closure}}
3: std::panicking::default_hook
4: std::panicking::rust_panic_with_hook
5: std::panicking::continue_panic_fmt
6: std::panicking::begin_panic_fmt
7: integration::multiline::vimgrep::{{closure}}
at tests/multiline.rs:77
8: integration::multiline::vimgrep
at tests/macros.rs:7
9: integration::multiline::vimgrep::{{closure}}
at tests/macros.rs:5
10: core::ops::function::FnOnce::call_once
at libcore/ops/function.rs:238
11: >::call_box
12: __rust_maybe_catch_panic
failures:
feature::f34_only_matching_line_column
feature::f917_trim
feature::f917_trim_match
json::basic
misc::after_context_line_numbers
misc::before_context_line_numbers
misc::columns
misc::context_line_numbers
misc::inverted_line_numbers
misc::line_numbers
misc::vimgrep
multiline::context
multiline::only_matching
multiline::vimgrep
test result: FAILED. 173 passed; 14 failed; 0 ignored; 0 measured; 0 filtered
out
Full build log for s390x in [1]. I have reported the issue upstream.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Arch qualification for buster: call for DSA, Security, toolchain concerns
Hello! On 12/9/18 3:18 PM, Matthias Klose wrote: > To me it looks sometimes that Debian is used for testing by upstream, and for > that the mips architectures don't need to be release architectures. A note on this: If you decide to move MIPS to Debian Ports, you will make the port unusable to most users as Debian Ports has a rather rudimentary FTP archive setup which has some annoying side effects. There is no support for a testing release, there is no support for cruft and the FTP maintainers will eventually remove any MIPS-only packages from the Debian archive which don't build on other architectures which usually affects packages like boot loaders meaning that it will no longer be easily possible to build the debian-installer package and consequently build installation images. The 32-bit PowerPC port lost quite a number of users because of this change. Not because the port was not healthy but because people want to be able to install a stable release. Debian unfortunately doesn't have really good support for Tier II architectures, it's either release or something based on unstable that requires extra elbow grease from both users and maintainers. Please also keep in mind that removing MIPS from the list of release architectures would mean one less open platform on which Debian is supported. Neither anything based on ARM, x86 or IBM Z provides a true open platform due to the proprietary nature of these architectures. There are some efforts in this regard on IBM POWER, but the hardware is still rather expensive, unfortunately. I do hope that RISC-V will catch up in the future though. I also think that the broad architecture support is one of the selling points of Debian and if we were to limit Debian's architecture support to just ARM, x86, POWER and IBM Z, I fear that Debian would more and more be turned into a mere development project for Ubuntu and other derivatives rather than being an operating system of its own. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Bug#824449: firefox: FTBFS on sparc64 due to wrong platform definitions
Hi! Both firefox and firefox-esr now build fine on sparc64. There is still one alignment-related crash though [1], but that should be addressed in a separate bug report and patch. I'll try to propose a less intrusive patch upstream. Adrian > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1434726 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
New Debian Ports installation images delayed
Hi! I had promised to build new installation images for Debian Ports last week. This has been delayed because of a regression of debian-installer on powerpc and ppc64 due to a change in the kernel packaging. A fix has now been submitted and the kernel packages will soon be rebuilt on powerpc and ppc64 once the FTP servers are in sync again. Once the kernel packages have been rebuilt, I can try building debian-installer on powerpc and ppc64 again and if that works, I can build new installation images. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: armel/armhf arch qualification for buster: call for DSA, Security, toolchain concernsj
Hi Roger! On 07/23/2018 10:42 AM, Roger Shimizu wrote: > I talked to a few people about keeping armel in buster, during 1st and > 2nd day in debcamp. > Seems the blocker is just the buildd server hardware, and memory size it has. According to my colleague Alex Graf at SUSE, you can definitely build ARMv7 on arm64 using chroots. The only problem with chroots is that "uname -a" shows "armv8" which some userspace applications are stumbling over. openSUSE/SLE builds armv7 packages in OBS/IBS using a fully emulated system using KVM. As for the hardware, you should watch out for hardware with ARM Cortex Cores. Alternatively, X-Gene 1. ThunderX, ThunderX2 and Centriq are definitely not supported. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Debian/MIPSeb: proposal to drop mipseb port?
Hi! You should ask in a more public forum rather than on Debian mailing lists if you want to know about potential users. Adrian > On Jul 7, 2018, at 8:31 AM, YunQiang Su wrote: > > Hi, folks, > due to lack of enough man power and build machines for 3 mips* port at > the same time, I think that now it is time for us to have a talk about > dropping mips32eb support now. > > mips32eb, named mips, in our namespace, is used by few people now, at > least compare with mipsel/mips64el. > > The reason we keep it till now is > 1) some people are still using it. > 2) it is the only port 32bit and EB now. > > In fact I don't know anybody is using Debian's mips32eb port. > If you are using it, please tell us.
Re: Arch qualification for buster: call for DSA, Security, toolchain concernsj
On 06/29/2018 10:41 AM, Luke Kenneth Casson Leighton wrote: > On Fri, Jun 29, 2018 at 8:16 AM, Uwe Kleine-König > wrote: > >>> In short, the hardware (development boards) we're currently using to >>> build armel and armhf packages aren't up to our standards, and we >>> really, really want them to go away when stretch goes EOL (expected in >>> 2020). We urge arm porters to find a way to build armhf packages in >>> VMs or chroots on server-class arm64 hardware. > > from what i gather the rule is that the packages have to be built > native. is that a correct understanding or has the policy changed? Native in the sense that the CPU itself is not emulated which is the case when building arm32 packages on arm64. We're also building i386 packages on amd64 and we used to build powerpc packages on ppc64 (and we will continue to do that once the move of powerpc to ports has been completed). I think that building on arm64 after fixing the bug in question is the way to move forward. I'm surprised the bug itself hasn't been fixed yet, doesn't speak for ARM. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Bug#824449: firefox: FTBFS on sparc64 due to wrong platform definitions
On 05/11/2018 11:20 PM, Mike Hommey wrote: >> The only patches we actually need are the one to fix skia on big-endian >> targets >> (I am currently in the process of upstreaming this one) and one tiny patch >> to fix an alignment issue on sparc64. > > For the record, the latter was explicitly rejected. I know. However, the person who wrote it is a security expert (and a friend of mine) and I trust him when he says the patch does not change any behavior or lower the security. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Bug#824449: firefox: FTBFS on sparc64 due to wrong platform definitions
Hi! With Firefox 60.0 ESR now in experimental, most of the sparc64-related patches are now part of the upstream source. The only patches we actually need are the one to fix skia on big-endian targets (I am currently in the process of upstreaming this one) and one tiny patch to fix an alignment issue on sparc64. Attaching both of them. The skia patch will also fix the build on s390x. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 diff -r ee1d1bf1dc8a gfx/skia/skia/include/core/SkColorPriv.h --- a/gfx/skia/skia/include/core/SkColorPriv.h Thu Apr 12 03:35:11 2018 -0700 +++ b/gfx/skia/skia/include/core/SkColorPriv.h Fri Apr 13 10:04:36 2018 +0300 @@ -55,17 +55,10 @@ * Here we enforce this constraint. */ -#ifdef SK_CPU_BENDIAN -#define SK_RGBA_R32_SHIFT 24 -#define SK_RGBA_G32_SHIFT 16 -#define SK_RGBA_B32_SHIFT 8 -#define SK_RGBA_A32_SHIFT 0 -#else -#define SK_RGBA_R32_SHIFT 0 -#define SK_RGBA_G32_SHIFT 8 -#define SK_RGBA_B32_SHIFT 16 -#define SK_RGBA_A32_SHIFT 24 -#endif +#define SK_RGBA_R32_SHIFT 0 +#define SK_RGBA_G32_SHIFT 8 +#define SK_RGBA_B32_SHIFT 16 +#define SK_RGBA_A32_SHIFT 24 #define SkGetPackedA32(packed) ((uint32_t)((packed) << (24 - SK_A32_SHIFT)) >> 24) #define SkGetPackedR32(packed) ((uint32_t)((packed) << (24 - SK_R32_SHIFT)) >> 24) diff -r ee1d1bf1dc8a gfx/skia/skia/include/core/SkImageInfo.h --- a/gfx/skia/skia/include/core/SkImageInfo.h Thu Apr 12 03:35:11 2018 -0700 +++ b/gfx/skia/skia/include/core/SkImageInfo.h Fri Apr 13 10:04:36 2018 +0300 @@ -84,7 +84,7 @@ #elif SK_PMCOLOR_BYTE_ORDER(R,G,B,A) kN32_SkColorType = kRGBA__SkColorType, #else -#error "SK_*32_SHIFT values must correspond to BGRA or RGBA byte order" +kN32_SkColorType = kBGRA__SkColorType #endif }; diff -r ee1d1bf1dc8a gfx/skia/skia/include/gpu/GrTypes.h --- a/gfx/skia/skia/include/gpu/GrTypes.h Thu Apr 12 03:35:11 2018 -0700 +++ b/gfx/skia/skia/include/gpu/GrTypes.h Fri Apr 13 10:04:36 2018 +0300 @@ -344,15 +344,13 @@ static const int kGrPixelConfigCnt = kLast_GrPixelConfig + 1; // Aliases for pixel configs that match skia's byte order. -#ifndef SK_CPU_LENDIAN -#error "Skia gpu currently assumes little endian" -#endif #if SK_PMCOLOR_BYTE_ORDER(B,G,R,A) static const GrPixelConfig kSkia_GrPixelConfig = kBGRA__GrPixelConfig; #elif SK_PMCOLOR_BYTE_ORDER(R,G,B,A) static const GrPixelConfig kSkia_GrPixelConfig = kRGBA__GrPixelConfig; #else -#error "SK_*32_SHIFT values must correspond to GL_BGRA or GL_RGBA format." +static const GrPixelConfig kSkia_GrPixelConfig = kBGRA__GrPixelConfig; +static const GrPixelConfig kSkiaGamma_GrPixelConfig = kSBGRA__GrPixelConfig; #endif /** diff -r ee1d1bf1dc8a gfx/skia/skia/include/private/GrColor.h --- a/gfx/skia/skia/include/private/GrColor.h Thu Apr 12 03:35:11 2018 -0700 +++ b/gfx/skia/skia/include/private/GrColor.h Fri Apr 13 10:04:36 2018 +0300 @@ -74,7 +74,11 @@ * Since premultiplied means that alpha >= color, we construct a color with * each component==255 and alpha == 0 to be "illegal" */ +#ifdef SK_CPU_BENDIAN +#define GrColor_ILLEGAL 0xFF00 +#else #define GrColor_ILLEGAL (~(0xFF << GrColor_SHIFT_A)) +#endif #define GrColor_WHITE 0x #define GrColor_TRANSPARENT_BLACK 0x0 diff -r ee1d1bf1dc8a gfx/skia/skia/src/core/SkColorData.h --- a/gfx/skia/skia/src/core/SkColorData.h Thu Apr 12 03:35:11 2018 -0700 +++ b/gfx/skia/skia/src/core/SkColorData.h Fri Apr 13 10:04:36 2018 +0300 @@ -32,17 +32,10 @@ * Here we enforce this constraint. */ -#ifdef SK_CPU_BENDIAN -#define SK_BGRA_B32_SHIFT 24 -#define SK_BGRA_G32_SHIFT 16 -#define SK_BGRA_R32_SHIFT 8 -#define SK_BGRA_A32_SHIFT 0 -#else -#define SK_BGRA_B32_SHIFT 0 -#define SK_BGRA_G32_SHIFT 8 -#define SK_BGRA_R32_SHIFT 16 -#define SK_BGRA_A32_SHIFT 24 -#endif +#define SK_BGRA_B32_SHIFT 0 +#define SK_BGRA_G32_SHIFT 8 +#define SK_BGRA_R32_SHIFT 16 +#define SK_BGRA_A32_SHIFT 24 #if defined(SK_PMCOLOR_IS_RGBA) && defined(SK_PMCOLOR_IS_BGRA) #error "can't define PMCOLOR to be RGBA and BGRA" >From 334b650e843cb307397fd627814421873131f0ed Mon Sep 17 00:00:00 2001 From: Michael Karcher Date: Thu, 1 Feb 2018 00:04:36 +0100 Subject: [PATCH] Bug 1434726 - Early startup crash on Linux sparc64 in HashIIDPtrKey --- js/xpconnect/src/XPCMaps.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/js/xpconnect/src/XPCMaps.cpp b/js/xpconnect/src/XPCMaps.cpp index bb99b9f8c034..837d5d78970f 100644 --- a/js/xpconnect/src/XPCMaps.cpp +++ b/js/xpconnect/src/XPCMaps.cpp @@ -23,7 +23
Archiving the attic folders from d-i for ports
(Re-send because I forgot debian-ports-devel@alioth is dead, please reply to debian-boot@) Hi! I was pointed at Steve's mail yesterday mentioning that he moved the non-attic repositories of debian-installer to salsa [1]. Since there are still some repositories that we need for debian-ports in the attic, I was wondering whether we should take care of the attic stuff and move it over to salsa or github. FWIW, we are in the progress of moving the sparc* and ppc* ports which aren't on GRUB yet fully over. In fact, GRUB works fine on all SPARC boxes we have tested so far, so at least silo-installer won't be needed anymore in the future. Still, I think we should archive everything. Adrian > [1] https://lists.debian.org/debian-boot/2018/04/msg00253.html -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [Debian-med-packaging] Bug#876147: Bug#876147: camp frequently FTBFS on 64bit big endian: camptest-qt (Failed)
On 04/16/2018 02:21 PM, Flavien Bridault wrote: Sorry the patch is ofc meant to be applied on the raw upstream, not after debian patches being applied. I was applying it directly into the git repo so that's why I did not have any issue. If you want to keep trying it this way, I attached a rebased version of the patch that should apply well on top of other. Ok, this works: (sid_s390x-dchroot)glaubitz@zelenka:~/camp/camp-0.8.1/obj-s390x-linux-gnu$ make test Running tests... /usr/bin/ctest --force-new-ctest-process Test project /home/glaubitz/camp/camp-0.8.1/obj-s390x-linux-gnu Start 1: camptest 1/2 Test #1: camptest . Passed0.01 sec Start 2: camptest-qt 2/2 Test #2: camptest-qt .. Passed0.00 sec 100% tests passed, 0 tests failed out of 2 Total Test time (real) = 0.02 sec (sid_s390x-dchroot)glaubitz@zelenka:~/camp/camp-0.8.1/obj-s390x-linux-gnu$ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [Debian-med-packaging] Bug#876147: Bug#876147: camp frequently FTBFS on 64bit big endian: camptest-qt (Failed)
On 04/16/2018 11:58 AM, Flavien Bridault wrote: Weird, it applies well for me on the master branch of the debian repository. Try the patch attached to this email or directly this link https://patch-diff.githubusercontent.com/raw/fw4spl-org/camp/pull/2.diff Tried to apply against the current package in Debian unstable: glaubitz@zelenka:~$ md5sum fix-s390.diff 3fae8e5c44e239e74e2ef14a667126b4 fix-s390.diff glaubitz@zelenka:~$ cd camp/ glaubitz@zelenka:~/camp$ dget -u http://deb.debian.org/debian/pool/main/c/camp/camp_0.8.1-2.dsc dget: retrieving http://deb.debian.org/debian/pool/main/c/camp/camp_0.8.1-2.dsc % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 321 100 3210 0 4346 0 --:--:-- --:--:-- --:--:-- 4397 100 2000 100 20000 0 20750 0 --:--:-- --:--:-- --:--:-- 20750 dget: retrieving http://deb.debian.org/debian/pool/main/c/camp/camp_0.8.1.orig.tar.gz % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 327 100 3270 0 4570 0 --:--:-- --:--:-- --:--:-- 4605 100 534k 100 534k0 0 4044k 0 --:--:-- --:--:-- --:--:-- 4044k dget: retrieving http://deb.debian.org/debian/pool/main/c/camp/camp_0.8.1-2.debian.tar.xz % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 331 100 3310 0 4809 0 --:--:-- --:--:-- --:--:-- 4867 100 5272 100 52720 0 63979 0 --:--:-- --:--:-- --:--:-- 63979 dpkg-source: info: extracting camp in camp-0.8.1 dpkg-source: info: unpacking camp_0.8.1.orig.tar.gz dpkg-source: info: unpacking camp_0.8.1-2.debian.tar.xz dpkg-source: info: applying remove_licences_files.patch dpkg-source: info: applying hide_boost_from_qt4moc.patch glaubitz@zelenka:~/camp$ cd camp-0.8.1/ glaubitz@zelenka:~/camp/camp-0.8.1$ patch -p1 < ~/fix-s390x.patch patching file .gitignore patching file include/camp/qt/qtfunction.hpp patching file include/camp/qt/qthelper.hpp patching file include/camp/valuemapper.hpp Hunk #2 FAILED at 40. Hunk #3 succeeded at 96 (offset 2 lines). Hunk #4 succeeded at 126 (offset 2 lines). Hunk #5 succeeded at 139 (offset 2 lines). Hunk #6 succeeded at 156 (offset 2 lines). Hunk #7 succeeded at 183 (offset 2 lines). Hunk #8 succeeded at 205 (offset 2 lines). Hunk #9 succeeded at 234 (offset 2 lines). Hunk #10 succeeded at 250 (offset 2 lines). Hunk #11 succeeded at 279 (offset 2 lines). Hunk #12 succeeded at 326 (offset 2 lines). Hunk #13 succeeded at 345 (offset 2 lines). 1 out of 13 hunks FAILED -- saving rejects to file include/camp/valuemapper.hpp.rej patching file test/arrayproperty.hpp Hunk #2 FAILED at 32. Hunk #3 succeeded at 78 (offset 2 lines). 1 out of 3 hunks FAILED -- saving rejects to file test/arrayproperty.hpp.rej patching file test/qt/propertymapping.cpp Hunk #2 succeeded at 34 with fuzz 2 (offset 2 lines). Hunk #3 succeeded at 47 (offset 2 lines). Hunk #4 succeeded at 95 (offset 2 lines). Hunk #5 succeeded at 106 (offset 2 lines). glaubitz@zelenka:~/camp/camp-0.8.1$ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [Debian-med-packaging] Bug#876147: Bug#876147: camp frequently FTBFS on 64bit big endian: camptest-qt (Failed)
On 04/16/2018 11:16 AM, John Paul Adrian Glaubitz wrote: Meanwhile I commited a fix upstream (https://github.com/fw4spl-org/camp/pull/2) so I would just want to try it before proposing the fix in the package. I'll test that for you on s390x. That patch doesn't apply to the Debian version of camp: glaubitz@zelenka:~/camp/camp-0.8.1$ patch -p1 < ~/fix-s390x.patch patching file .gitignore patching file include/camp/qt/qtfunction.hpp patching file include/camp/qt/qthelper.hpp patching file include/camp/valuemapper.hpp Hunk #2 FAILED at 40. Hunk #3 succeeded at 96 (offset 2 lines). Hunk #4 succeeded at 126 (offset 2 lines). Hunk #5 succeeded at 139 (offset 2 lines). Hunk #6 succeeded at 156 (offset 2 lines). Hunk #7 succeeded at 183 (offset 2 lines). Hunk #8 succeeded at 205 (offset 2 lines). Hunk #9 succeeded at 234 (offset 2 lines). Hunk #10 succeeded at 250 (offset 2 lines). Hunk #11 succeeded at 279 (offset 2 lines). Hunk #12 succeeded at 326 (offset 2 lines). Hunk #13 succeeded at 345 (offset 2 lines). 1 out of 13 hunks FAILED -- saving rejects to file include/camp/valuemapper.hpp.rej patching file test/arrayproperty.hpp Hunk #2 FAILED at 32. Hunk #3 succeeded at 78 (offset 2 lines). 1 out of 3 hunks FAILED -- saving rejects to file test/arrayproperty.hpp.rej patching file test/qt/propertymapping.cpp Hunk #2 succeeded at 34 with fuzz 2 (offset 2 lines). Hunk #3 succeeded at 47 (offset 2 lines). Hunk #4 succeeded at 95 (offset 2 lines). Hunk #5 succeeded at 106 (offset 2 lines). glaubitz@zelenka:~/camp/camp-0.8.1$ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [Debian-med-packaging] Bug#876147: Bug#876147: camp frequently FTBFS on 64bit big endian: camptest-qt (Failed)
Hello! On 04/16/2018 09:15 AM, Flavien Bridault wrote: I sent you a private email twice last week but I did not receive any answer from you so I am afraid they did not reach you. Or maybe you were just away or not available, if that's the case sorry for spaming you... I forgot to follow up on that, sorry. I have been very busy. But from the logs it's also apparent that the package builds fine - including the tests - on sparc64, so I'm not sure the sparc64 porterbox would be of any help. You should preferably get access to an s390x porterbox but I don't have any that I can provide access to. You would have to contact the correct people at Debian for that. See: https://dsa.debian.org/doc/guest-account/ Meanwhile I commited a fix upstream (https://github.com/fw4spl-org/camp/pull/2) so I would just want to try it before proposing the fix in the package. I'll test that for you on s390x. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Bug#895193: transition: openmpi
On 04/11/2018 10:53 AM, Alastair McKinstry wrote: As of 3.0.1, openmpi now works on Big-Endian powerpc (which was to be a problem; it had been dropped upstream because of an unknown bug, now fixed). Oh, really, they fixed that? I already had given up hopes and therefore ignored the thread on github out of frustration. The other non-release archs were failing due to missing dependencies: in particular java support (not used by any package in stable/testing) and pmix (new; not used in testing/stable; pmix enables scaling to ~100,000+ nodes, which is unlikely to be needed). I am working on fixing the remaining OpenJDK issues. I'm an upstream committer in the OpenJDK project, so I can commit all changes myself. So, the expected changes to mpi-defaults will no longer be needed. Yay, thanks so much for this! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [Debian-med-packaging] Bug#876147: Bug#876147: camp frequently FTBFS on 64bit big endian: camptest-qt (Failed)
On 04/06/2018 02:34 PM, Flavien Bridault wrote: Okay thanks a lot for your quick answer ! Maybe I misunderstood the excuses https://qa.debian.org/excuses.php?package=camp, but the build failure on s390x looks very similar at the endianess issue we have on sparc64, so this should also solves that. If not I will contact s390x folks. We can give a try non-theless. Please send me a private email with your desired username. Encrypt the mail using my GPG below (you can find in the Debian GPG keyring). Use your key that was signed by the Debian Developer you mentioned. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [Debian-med-packaging] Bug#876147: camp frequently FTBFS on 64bit big endian: camptest-qt (Failed)
Hi Flavien! On 04/06/2018 02:24 PM, Flavien Bridault wrote: I already posted the information but it seems no one got it. My GPG key has been signed by a Debian Developer, would it be possible to gain access to the sparc64 porterbox now ? Yes, we can create an account for you on the sparc64 porterbox. camp has been removed from testing because of this bug and this prevents fw4spl from being updated, I would like to fix this asap. A package failing to build from source on sparc64 does not have any influence on testing migration. In fact, the package builds fine on sparc64 at the moment so I'm not sure a sparc64 porterbox would help you. We can still give you access to the sparc64 porterbox if the problem is big-endian-specific, but I guess access to an s390x machine would be better. Although for that you would have to contact the s390x folk. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#882563: golang-go: Please build for s390x
Package: golang-go Followup-For: Bug #882563 User: debian-s390@lists.debian.org Usertags: s390x Control: fixed -1 2:1.10~4 Hi! This has been fixed in golang-defaults_2:1.10~4 and golang-go is now the default Go compiler on s390x. This also means that golang-any defaults to golang-go on all release architectures and hence it's now safe to replace golang-go with the golang-any build dependency for all Go packages in Debian. Any package that does not build with gccgo-go will affect Debian Ports architectures only which aren't officially supported anyway and for which the Debian Ports team takes care of. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Rust architecture status
ult, using libc::c_long doesn't work. We have to use "i64" on x32 instead. Necessary work: Fix the crash above. Also, get D43630 (https://reviews.llvm.org/D43630) merged in LLVM upstream. Fix the remaining 64-bit time issues in crates like "filetime" and "time". Cheers, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: camp frequently FTBFS on 64bit big endian: camptest-qt (Failed)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 01/08/2018 06:13 PM, Flavien Bridault wrote: > Ah I see maybe I should email Ben Collins > <mailto:bcoll...@debian.org> as stated here > https://www.debian.org/ports/sparc/porting.en.html ? No, that information is unfortunately outdated. We need to ask the webteam to update the website. Thanks for the heads-up. Do you happen to have a GPG key which has been signed by any Debian Developer or any developer from another large Linux distribution? Adrian - -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEYv+KdYTgKVaVRgAGdCY7N/W1+RMFAlpTp3cACgkQdCY7N/W1 +ROXhg/+K0rcF8XWoDdb+0AF2vYT4VTEOKQdA15aLW4TSQ3XGfwdqXE6maNwAXM7 SuqB4NzJxxTHiTXJ8QXXQ1u29yKdCqb6g/vgEwduoLC3FAfupQ+A11WkMNidrqhu MTME4+rq24yLaNdIiE2fS+C3goTaS7raIgFY68nnL5j2x2Ptjs0BNGnJ2QPEflK9 IDMDNPPG9L2OPwQB52XtyWJODZuFANg6kKRE4OwgPMTL8aYRpQEKnLLQ2pxt4sdb IhWivHhDGBTlkwMWpVuTseyMSEyGLBRZrXaXi5Y/5wirg72N8CzzXU8hiwphf3cm L1dUWx45XuK9ZfmLFJ/yUzg48XPheH4AgnLto0Rvq6mIPoKCmLcrZAMVhxIPWEHw /US9H8nu4iipmJAGaPAcwqfPCYLNhngljlPmVPvHY4pgK3Z9XiGtCvwSg7/bBfTD vs6Ok31/+7UlCWEuXVBhS7HV/+5abpDJeMXBFZ84PgzfxcQwayNvpCdTFgZmell0 /GQ8IMUnDFpANmjZ2qtDlUuchwRdTAIxqIkie6v7JmBk3tp3CQMC0AOU29u3Psrh 8ls+bevKJeOAtaJG2fJxWnVH+h9QbM8ug8lcb3+26U2v5QShK6Nyt2yozSzU6wlc CBMnH+8NXtQ95zU2lCZ8Qm7lgG8prKztdyJKGdx9m26Kt5tbGg4= =1hIL -END PGP SIGNATURE-
Re: camp frequently FTBFS on 64bit big endian: camptest-qt (Failed)
We have a new sparc64 porterbox called sakharov.debian.net. Feel free to test your code there. Adrian > On Dec 8, 2017, at 9:49 AM, Andreas Tille wrote: > > Hi Flavien, > > I have put the porter lists of the affected architectures in CC whether > there is somebody who has a hint for a better solution than removing > these architectures from the supported architectures. This kind of > "random failure"[1] is quite hard to debug for somebody who is not > familiar for the said architectures. > > Kind regards > > Andreas. > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=876147#20 > > -- > http://fam-tille.de
Updated installer images
Hi! I have generated an updated set of debian-installer images for Debian Ports which also now includes alpha [1]. I have fixed the installation issues on hppa and sparc64, in both cases the bootloader installer was missing. ppc64 has still some issues with the partition manager, but I'm working on fixing that. Please test and report back on the individual architecture mailing lists, i.e. please don't post to debian-ports@l.d.o as this reaches the mailing lists of all ports. Adrian [1] https://cdimage.debian.org/cdimage/ports/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
New download location for Debian Ports ISOs
Hi! I am cross-posting this to debian-ports@l.d.o because it affects all Debian Ports architectures. As of today, we will be using Debian's official cdimage mirror to host the installation images for Debian Ports, the images can be found in [1]. I have uploaded images for hppa, m68k, ppc64 and sparc64. I am working on uploading more images. Images for alpha are currently missing due to issues with the Linux kernel packages which fails to build on alpha at the moment. Please test the images as thoroughly as you can and report your results to the appropriate architecture-specific mailing lists. Please do not post to this mailing list, debian-ports@l.d.o, as this will cross-post your mail to ALL Debian Ports architectures mailing lists. A huge thanks to Steve McIntyre and the Debian Sysadmins for providing us access to the official cdimage mirror. Thanks, Adrian > [1] https://cdimage.debian.org/cdimage/ports/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#864974: thunderbird: Missing AtomicOperations for multiple architectures cause FTBFS
Source: icedove
Version: 1:52.2.0-1
Severity: serious
Justification: fails to build from source
Hi!
thunderbird fails to build from source on multiple architectures,
including s390x, because the proper AtomicOperations header
is not included for the affected architectures.
Looking at [1], all architectures that do not have their own
variant of the AtomicOperations header must use the generic
ppc or sparc headers, e.g.
(...)
# elif defined(__alpha__)
# include "jit/none/AtomicOperations-ppc.h"
# elif defined(__hppa__)
# include "jit/none/AtomicOperations-ppc.h"
#elif defined(__m68k__)
# include "jit/none/AtomicOperations-ppc.h"
#elif defined(__s390__)
# include "jit/none/AtomicOperations-ppc.h"
#elif defined(__sh__)
# include "jit/none/AtomicOperations-ppc.h"
(...)
From what I can see, you are currently missing:
alpha: __alpha__
hppa: __hppa__
m68k: __m68k__
powerpc and powerpcspe: __ppc__
s390: __s390__
ppc64 and sparc64 should work as they define "__PPC64__" and
"__sparc__" which is actually covered in the current code. I will
check what's wrong on this architectures later.
See also [2] (note: AtomicOperations-ppc.h and AtomicOperations-sparc.h
are identical and have been renamed to AtomicOperations-feeling-lucky.h
by upstream).
All architectures which are not including jit/none/AtomicOperations-ppc.h
or jit/none/AtomicOperations-sparc.h will include
jit/none/AtomicOperations-none.h
and *will* FTBFS by definition (this is intended behavior in the JavaScript
engine). Please note that __sparc__ is also used for sparc64. So please
do not test for sparc64 with "#if defined(__sparc64__)", testing for
"__sparc__" is fine as it is.
Thus, please add the missing definitions for all architectures where the
build fails with:
Executing /«PKGBUILDDIR»/obj-thunderbird/dist/bin/xpcshell -g
/«PKGBUILDDIR»/obj-thunderbird/dist/bin/ -a
/«PKGBUILDDIR»/obj-thunderbird/dist/bin/ -f
/«PKGBUILDDIR»/mozilla/toolkit/mozapps/installer/precompile_cache.js -e
precompile_startupcache("resource://gre/");
d: file /«PKGBUILDDIR»/mozilla/xpcom/build/XPCOMInit.cpp, line 709
[23935] ###!!! ABORT: u_init() failed: file
/«PKGBUILDDIR»/mozilla/xpcom/build/XPCOMInit.cpp, line 709
Traceback (most recent call last):
File "/«PKGBUILDDIR»/mozilla/toolkit/mozapps/installer/packager.py", line
415, in
main()
File "/«PKGBUILDDIR»/mozilla/toolkit/mozapps/installer/packager.py", line
409, in main
args.source, gre_path, base)
File "/«PKGBUILDDIR»/mozilla/toolkit/mozapps/installer/packager.py", line
166, in precompile_cache
errors.fatal('Error while running startup cache precompilation')
File "/«PKGBUILDDIR»/mozilla/python/mozbuild/mozpack/errors.py", line 103, in
fatal
self._handle(self.FATAL, msg)
File "/«PKGBUILDDIR»/mozilla/python/mozbuild/mozpack/errors.py", line 98, in
_handle
raise ErrorMessage(msg)
mozpack.errors.ErrorMessage: Error: Error while running startup cache
precompilation
/«PKGBUILDDIR»/mozilla/toolkit/mozapps/installer/packager.mk:41: recipe for
target 'stage-package' failed
make[4]: *** [stage-package] Error 1
PS: The build logs for ppc64, sparc64 and x32 are currently missing due to
issues on the
buildds with sending mail. We're working on fixing this.
Cheers,
Adrian
> [1]
> https://anonscm.debian.org/cgit/pkg-mozilla/icedove.git/tree/mozilla/js/src/jit/AtomicOperations.h
> [2]
> https://github.com/glaubitz/gecko-dev/blob/m68k/js/src/jit/AtomicOperations.h#L340
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
debian-installer now available in Ports
Hi! Thanks to the recent efforts within the Debian Ports projects, debian-installer is finally available for the Debian Ports architectures [1]. Previously, the installer images had to be built manually because building on the buildds always required a testing repository to be available for a given architecture. With the latest release of debian-installer, the build falls back to the unstable and unreleased repositories for the required udebs. The generated d-i images for powerpc, kfreebsd-* and hurd-i386 can be found here: > ftp://ftp.debian.org/debian/dists/sid/main/installer-$ARCH For the remaining Ports architectures: > http://ftp.ports.debian.org/debian-ports/pool-$ARCH/main/d/debian-installer/ Now, since the process of building installer images no longer requires manual intervention, the process for building CD images has been simplified as well, still requires some manual work. Thus, I was wondering whether any volunteers would be willing to help building ISO images for the various architectures. A rough guide can be found in [2] from which the the d-i part can be omitted, however, a local mirror available through the filesystem is still necessary (see MIRROR in CONF.sh). So, reprepro needs to be used to set up a local mirror or the remote mirror needs to be mounted with a FUSE module or similar. In order to use the debian-installer images for building CD images, they have to be downloaded and extracted (for the remaining Ports architectures above) and placed into the directory pointed to by DI_DIR in the easy-build.sh script, e.g.: export DI_DIR="/srv/d-i/debian-installer/installer/build/tmp/cdrom/. Would be great if we could get several people work on this and create ISOs for alpha, hppa, powerpc, ppc64 and so on. Please note: It's not necessary to run debian-cd on the same architecture as the target architecture of the ISO images. Hence, using an amd64 host should be fine. Thanks, Adrian > [1] https://buildd.debian.org/status/package.php?p=debian-installer&suite=sid > [2] https://wiki.debian.org/PortsDocs/CreateDebianInstallerImages -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Porter roll call for Debian Stretch
On 09/30/2016 09:04 PM, Niels Thykier wrote: > As for "porter qualification" > = > > We got burned during the Jessie release, where a person answered the > roll call for sparc and we kept sparc as a release architecture for > Jessie. However, we ended up with a completely broken and unbootable > sparc kernel. To be fair, this happened because the upstream kernel development for SPARC came to an almost complete stop. There was basically only David Miller working on the port which turned out not to be enough. This isn't the case for PowerPC32 where upstream development is still very active because it's part of the PowerPC kernel which is maintained by IBM. PowerPC32 is also still quite popular which is why it still sees quite some testing in the wild. There are still new PowerPC32 designs based on embedded CPUs (FreeScale and the like). As for SPARC, Oracle is actually now heavily investing in Linux SPARC support, so even SPARC is getting back into shape which is why I hope we can add sparc64 as an official port soon. > That was an embarrassment to the Debian stability and quality > reputation that I never - ever - want to repeat. Well, mistakes happen and while I think it's good and important to learn from mistakes, we should not dramatize such issues. We have had worse issues like the OpenSSL entropy bug, for example, and we still managed to cope with the fallout in a very professional manner. > (For avoidance of doubt: I want to ensure that release architectures > "just work(tm)" and I have no desire to blame that volunteer). I don't think there is any concern regarding the powerpc port in this regard. wanna-build shows almost 11800 packages that are up-to-date which is a good indicator that the port is in good shape, both regarding the toolchain and various source packages which need architecture-specific adaptations like LibreOffice or JavaScript packages. On the other hand, some packages dropped support for PowerPC32 like Mono but this isn't a concern for most users, I would say. > If I am to support powerpc as a realease architecture for Stretch, I > need to know that there are *active* porters behind it committed to > keeping it in the working. People who would definitely catch such > issues long before the release. People who file bugs / submit patches etc. I agree and I'm actually doing that all the time. I always run unstable on my machines and constantly check wanna-build for build issues and report them upstream whenever they occur. I have helped dozens of such issues on "sh4" and "sparc64", for example. > If you need inspiration: Have a look at the [automatic testing of > ppc64el images]. Or the [arm64 machines on ci.debian.net] with > comparable results to amd64. This is the sort of thing that inspires > confidence in the ports for me and I think we should have vastly more of. I agree that would be nice to have. However, to be fair, we don't have that type of testing for all release architectures and to my current knowledge, automated testing of installation images is not a criteria for an architecture to maintain release status. My main argument for why we should keep the powerpc port is its popularity. If we look at the numbers from popcon [1], powerpc is still the fourth-most-popular port and I think we would disappoint many users if we were to drop the port for Stretch. Note that while ports like "arm64" or "ppc64el" receive lots of support, especially from companies, they still haven't reached the same popularity as the powerpc port for example. Heck, there are even more users for "hppa" and "sparc64" which both are just unofficial ports architectures. Thanks, Adrian > [1] http://popcon.debian.org/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Porter roll call for Debian Stretch
On 09/30/2016 06:08 PM, Niels Thykier wrote: > I strongly /suspect/ that "no porters" for powerpc will imply the > removal of powerpc for Stretch. It may or may not be moved to ports > (assuming someone is willing to support it there). So, I take this as a "no" for the offer from me and Christoph Biedel to take over the powerpc port for Stretch? I have quite some experience with working on ports and unlike what Matthias claimed, I'm not just maintaining a few buildds but also getting architecture-specific bugs fixed and so on. Is there any specific qualification I am missing? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Porter roll call for Debian Stretch
On 09/23/2016 03:54 PM, Matthias Klose wrote: > No, you are not maintaining powerpcspe as a release architecture, and that's > something different than building packages for some of the ports > architectures. > If you can get powerpcspe accepted as a release architecture, then maybe you > gain some credibility to maintain another release architecture ;) So, what are the criteria to be knighted to become a maintainer of powerpc? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Porter roll call for Debian Stretch
On 09/20/2016 11:16 PM, Niels Thykier wrote: >- powerpc: No porter (RM blocker) I'd be happy to pick up powerpc to keep it for Stretch. I'm already maintaining powerpcspe which is very similar to powerpc. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 signature.asc Description: OpenPGP digital signature
Re: The (uncalled for) toolchain maintainers roll call for stretch
On 09/10/2016 12:48 AM, Matthias Klose wrote: > Uncovered by the upstream primary and secondary platforms are the mips* > architectures and powerpc. For the uncovered archs I would expect somehow > more > and pro-active Debian maintenance, however I fail to see this happen. > > - see the history of ftbfs on the buildd page of the gcc-snapshot package > - see the status of the gcc-6 package for the pre-release uploads > - see the number of RC issues for binutils which came up with 2.27, >some still open. > - Toolchain packages are not watched by porters, and I can't track >every regression myself, however this is not done well by porters. > > On the recent Porter's call I didn't see any toolchain support for the powerpc > architecture. I would actually be happy to take over the powerpc port as its official porter. I'm already taking care of powerpcspe, so I think it would be a perfect fit. Let me know what needs to be done to make this happen! I don't want to see powerpc go too soon. Cheers, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#833817: kido: FTBFS on non-x86 architectures due to hard-wired compiler flags
Source: kido Version: 0.1.0+dfsg-1 Severity: important Hello! Your package fails to build from source on all non-x86 architectures because the build system hard-wires the compiler flags to use x86-specific flags like "-msse2": [ 0%] Building CXX object kido/CMakeFiles/kido.dir/common/Console.cpp.o cd /<>/kido-0.1.0+dfsg/build/kido && /usr/bin/c++ -DBOOST_TEST_DYN_LINK -DHAVE_BULLET_COLLISION -Dkido_EXPORTS -I/<>/kido-0.1.0+dfsg -isystem /usr/include/eigen3 -isystem /usr/include/bullet -I/<>/kido-0.1.0+dfsg/build -Wall -msse2 -fPIC -std=c++11 -g -O2 -fdebug-prefix-map=/<>/kido-0.1.0+dfsg=. -fPIE -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -I/usr/include/bullet -o CMakeFiles/kido.dir/common/Console.cpp.o -c /<>/kido-0.1.0+dfsg/kido/common/Console.cpp c++: error: unrecognized command line option '-msse2' kido/CMakeFiles/kido.dir/build.make:65: recipe for target 'kido/CMakeFiles/kido.dir/common/Console.cpp.o' failed make[4]: *** [kido/CMakeFiles/kido.dir/common/Console.cpp.o] Error 1 Please modify the CFLAGS used to make your package build on all architectures! Full build log available in [1]. Thanks! Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=kido&arch=sparc64&ver=0.1.0%2Bdfsg-1&stamp=1470693049 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [Stretch] Status for architecture qualification
On 06/20/2016 04:15 PM, Lennart Sorensen wrote: > On Mon, Jun 20, 2016 at 04:11:32PM +0200, John Paul Adrian Glaubitz wrote: >> Well, we just did a full archive rebuild of "ppc64" to be able to >> support ppc64 on the e5500 cores by disabling AltiVec, didn't we? > > Well it is getting there. The archive rebuild is done and around 11200 packages are up-to-date. It's just the installer that needs work and someone needs to convince the release team that ppc64 is something we want as a release architecture. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [Stretch] Status for architecture qualification
On 06/20/2016 04:05 PM, Lennart Sorensen wrote: > Also I suspect many users of 64 bit capable freescale chips > (e5500 and e6500 cores) are running 32 bit powerpc since they > don't have enough ram to actually really gain anything > from going to 64 bit, and the ppc64 port isn't done yet. Well, we just did a full archive rebuild of "ppc64" to be able to support ppc64 on the e5500 cores by disabling AltiVec, didn't we? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [Stretch] Status for architecture qualification
On 06/18/2016 06:25 PM, William ML Leslie wrote: > In case it isn't clear, the number of users of the architecture is not part > of the qualification, it is the amount of maintenance pressure involved. > Package > maintainers have to put more effort into ensuring builds succeed for release > architectures, which detracts from other work that needs to be done. Not > being a > release architecture is perfectly fine. I maintain multiple architectures in Debian Ports, including m68k, powerpcspe, sh4, sparc64 and x32 and actually, it's not so much of a burden to maintain an architecture in Debian. Most of the packages don't need special attention and if they do, it's usually just poorly written code like people doing weird pointer arithmetics which provoke unaligned access or abuse C/C++ in other ways. If upstream developers in these cases cared more about code quality and adhering to the C/C++ standards, we would hardly ever have issues with any ports. Heck, even on m68k, most packages still build fine and they actually work. As long as an architecture is maintained upstream both in the kernel and the toolchain, there is absolutely no reason to not keep it in Debian unless there is no hardware available that can be used for buildds and porterboxes. Ports like Debian/GNU Hurd or Debian/kFreeBSD are a different story though as they need way more work to be able to make all sorts of packages work there. In the case of PowerPC, both the kernel and the toolchain are very well maintained, many packages like GHC have native support for the architecture and even rather problematic packages like Firefox/Thunderbird are supported. Plus, PowerPC packages can be built on the POWER8 virtual machines that IBM provides for Debian Developers in the cloud for free. We have one such machine set up for ppc64, for example. In any case, if PowerPC should ever be dropped as a release architecture, I will be more than happy to adopt it in Debian Ports. PS: If you see your package failing to build on any of the ports architectures and you want to fix it and need help, just let me know :). Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [Stretch] Status for architecture qualification
On 06/14/2016 09:06 AM, Philipp Kern wrote: > Yeah, but that's unfortunately one of the universal truths of this port. > I mean in theory sometimes they turn up on eBay and people try to make > them work[1]. Hilarious talk, thanks a lot for the link :). > It also seems true for other ports where we commonly relied on sponsors > to hand us replacements. But maybe it's only ppc64el these days, maybe > there are useful builds available for the others (including arm64 and > mips) on the market now. The hardware sponsoring is the main thing that keeps us from making sparc64 an official port, I would say. The state of the port itself is great: We recently even got LibreOffice running on sparc64 (patches not yet merged) and the port is quite popular, according to popcon, sparc64 has already more users than arm64 and some of the mips ports :). If we were to add sparc64 to Debian, we could rebuild the archive within a few weeks. We have one user who has two Sun T2 servers which are new-in-box (NIB), would those be ok to set up as machines for DSA? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [Stretch] Status for architecture qualification
On 06/05/2016 02:00 PM, Holger Levsen wrote: > I'm not sure whether you are talking about source or binary packages but > sid/amd64 has over 24000 source packages and over 5 binary packages, > so I would call the above "on par". Or what am I missing? There are just around 12,000 source packages with arch:amd64 in sid: glaubitz@wuiet:~$ wanna-build -A sparc64 -d unstable --list=installed | wc -l 10828 glaubitz@wuiet:~$ wanna-build -A ppc64 -d unstable --list=installed | wc -l 10990 glaubitz@wuiet:~$ wanna-build -A amd64 -d unstable --list=installed | wc -l 12154 glaubitz@wuiet:~$ The rest is arch:all: glaubitz@wuiet:~$ wanna-build -A all -d unstable --list=installed | wc -l 15672 glaubitz@wuiet:~$ Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 signature.asc Description: OpenPGP digital signature
Re: [Stretch] Status for architecture qualification
ernel was recently turned into maintained state again after two developers involved with the J-Core project picked up the code, the latter issue will be hopefully resolved soon. It's already been put onto their TODO list. gcc upstream for SH is also still active, so both gcc-5 and gcc-6 work fine on sh4. Before I picked up sh4, there were actually many issues in the SH backend in gcc which prevented gcc-4.9/5/6 from being built on this architecture. With lots of patience, debugging, bug reporting and patching, gcc-5/6 are both in a healthy and usable state. Currently available SuperH hardware is rather slow and has usually not more than 512 MiB of RAM, so it wouldn't make sense to set up buildds and porterboxes with what is currently available. However, since the J-Core project is currently working on open source hardware, it might be possible that in the future, faster hardware becomes available at affordable prices. So it makes sense to keep an eye on sh4 and J-Core for future Debian releases. Thanks, Adrian PS: If other Debian people are interested in joining our efforts to work on the sparc64 port or making a Debian port for the J-Core happen, I would be happy to provide access to porterboxes. -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 signature.asc Description: OpenPGP digital signature
New ports signing key for 2016
Hello! I just noticed there is a new signing key for debian-ports, please update your buildds: glaubitz@z6:~/m68k> gpg --fingerprint B4C86482705A2CE1 pub 4096R/705A2CE1 2016-01-24 [expires: 2017-02-01] Key fingerprint = 69DD B056 0EA8 6E87 E835 99B3 B4C8 6482 705A 2CE1 uid Debian Ports Archive Automatic Signing Key (2016) glaubitz@z6:~/m68k> Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#811554: haskell-hslua: Please don't build-depend on libluajit-5.1-dev for unsupported architectures
Source: haskell-hslua Version: 0.4.1-4 Severity: important Hello! Currently, haskell-hslua is BD-Uninstallable for multiple architectures were it would actually build if it wasn't for the build dependency on libluajit-5.1-dev which is only supported on a limited number of architectures. I would therefore suggest to change the build dependency on libluajit-5.1-dev to use a whitelist instead of a blacklist, i.e. change debian/control as below: --- control.old 2016-01-19 20:48:43.0 +0100 +++ control.new 2016-01-19 20:50:18.661062876 +0100 @@ -10,7 +10,7 @@ ghc-prof, pkg-config, liblua5.1-0-dev, - libluajit-5.1-dev [!arm64 !ppc64el !s390x], + libluajit-5.1-dev [amd64 armel armhf i386 mips mipsel powerpc hurd-i386 kfreebsd-i386], libghc-hspec-dev, libghc-hspec-contrib-dev, libghc-hunit-dev, This would fix haskell-hslua being BD-Uninstallable on most ports architectures. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Time to change the debian-ports "list"?
I'm in favor of the old design because I think it's important to havw a list which can be used to make announcements about important issues that all porters should be aware of. It's not really that mails going to debian-ports@ appear that often. PS: Excuse my quoting style, currently on mobile. Adrian > On Jul 22, 2015, at 7:04 PM, Steve McIntyre wrote: > >> On Wed, Jul 22, 2015 at 05:38:17PM +0200, Wouter Verhelst wrote: >>> On Fri, Jul 17, 2015 at 01:40:20PM +0100, Steve McIntyre wrote: On Thu, Sep 11, 2014 at 12:51:29PM +0100, Steve McIntyre wrote: > On Wed, Sep 10, 2014 at 07:01:00PM +, Thorsten Glaser wrote: > Alexander Wirt dixit: > >> Could you please (technically) summarize what needs to be done from >> listmaster side? > > 1. Remove whatever debian-po...@lists.debian.org is right now > > 2. Create a new debian-po...@lists.debian.org mailing list which > works just like the other regular lists > > 3. Announce the new debian-po...@lists.debian.org so that people > can subscribe to it; document that there is no longer > an address to reach *all* ports but that people should > eMail the individual ports’ lists (and cross-post if > needed, but only to the amount needed), and that the > new debian-po...@lists.debian.org instead is a mailing list for > discussion about > a) debian-ports.org infrastructure > b) porting Debian in general > c) questions related to setting up a Debian port, > including wanna-build, buildd, etc. >> >> That seems like a bad idea to me, tbh. There will be people who won't >> notice that the meaning of debian-ports@ has changed, and who will try >> to use it with its old meaning. >> >> If there are problems with the current meaning of debian-ports, can't we >> just retire the old alias and create a list under a different name? > > Is there much point to that? I've not heard anybody at all speak up in > favour of the existing behaviour. If anybody does use try to use it > that way in future, the new list will most likely be the best place > for their mail to go... > > -- > Steve McIntyre, Cambridge, UK.st...@einval.com > "I used to be the first kid on the block wanting a cranial implant, > now I want to be the first with a cranial firewall. " -- Charlie Stross > > > -- > To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: https://lists.debian.org/20150722170456.gc5...@einval.com -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/a3f2133d-cea2-42d5-a4d3-5dacfe6ec...@physik.fu-berlin.de
Re: using build profiles breaks debian-ports
On 07/17/2015 09:31 AM, Thorsten Glaser wrote: > using build profiles breaks debian-ports architectures, all of them: What exactly is a build profile in this context? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55a8bda0.4010...@physik.fu-berlin.de
Re: Bug#399608: fixed in sysvinit 2.88dsf-59.1
Hi there! This upload most likely broke the build queue on several ports architectures because sysvinit-tools depend on a specific version of util-linux which wasn't build on the affected architectures yet [1]. I fixed sh4 and m68k manually, but sparc64 and powerpcspe are still stuck because they can't build the current version of util-linux. The problem is currently overshadowed on sparc64 by other BD-Uninstallable packages but it exists there as well most likely. To fix the issue, I had to build util-linux manually, wanna-build was unable to resolve the dependencies. Maybe the dependency on src:util-linux is incorrect and it should be just util-linux as src:util-linux apparently always depends on the most current version in the main archive instead of just any usable version in the archives? I don't know. In any case, I would love to fix the powerpcspe and sparc64 ports but I haven't got an account on any machine with these architectures yet so I can't help at the moment. I have asked for a sparc64 account but with no positive result so far. Anyway, just wanted to raise some awareness that this change broke the build queue on the ports and it might break again once util-linux is updated in the main archive again. Cheers, Adrian > [1] http://buildd.debian-ports.org/status/package.php?p=util-linux&suite=sid -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55588921.7070...@physik.fu-berlin.de
sh4 missing on packages.debian.org
Hi Aurelien! I just noticed that there seems to be something wrong with packages.debian.org regarding sh4. Many packages are not listed there as available even though they are built and installed. For example, src:glibc, has been fully built on sh4, yet: > https://packages.debian.org/sid/libc6 It's not there. It's also not installable anymore: yamato:~# apt-cache policy libc6 libc6: Installed: 2.19-9 Candidate: 2.19-9 Version table: *** 2.19-9 0 100 /var/lib/dpkg/status yamato:~# yamato:~# cat /etc/apt/sources.list deb http://ftp.debian-ports.org/debian/ unstable main deb http://ftp.debian-ports.org/debian/ unreleased main yamato:~# Do you know what could be wrong? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5409ed32.7080...@physik.fu-berlin.de
Re: Roll call for porters of architectures in sid and testing
Hello! On 09/25/2013 05:09 AM, Nobuhiro Iwamatsu wrote: > I am an active porter for the following architectures and I intend > to continue this for the lifetime of the jessie release: > > For sh4, I > - test packages on this architecture > - triage arch-specific bugs > - fix arch-related bugs > - maintain buildds I have joined Nobuhiro to help supporting the sh4 port. I am currently working on to reactive the build queue again. Needs-Build on sh4 is currently over 4000 and I need to build a couple of essential packages like gcc-4.9, gcc-4.8 and python2.7 manually to be able to resolve the dependency problems. gcc-4.9 has been building since Wednesday but it's looking good. I hope to have the packages uploaded over the weekend. Cheers, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53e618fc.9070...@physik.fu-berlin.de
Re: How to get a new palo source package into unstable?
Hi Helge! On 01/11/2014 10:37 PM, Helge Deller wrote: > Since I'm not a debian-developer, I don't know how to get this package into > debian unstable again. > What is the usual process to get a new/old package back into debian unstable? > Maybe someone of you who has a debian developer rights is willing to upload > the > source package? I'm mostly finished with palo now. I converted the package to the latest debhelper format, reformatted the copyright file to the new 1.0 format (still need to some missing copyright holders and verify the license is correct for all source files). I also added a README.source to explain what happened with palo after version 1.16. The remaining things are cleaning up the changelog, removing other cruft and updating files like README.Debian. Hope to get it finished by the weekend. I will send you the patches, have you ACK them and upload on Saturday or Sunday. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/530f4e65.7080...@physik.fu-berlin.de
Re: How to get a new palo source package into unstable?
Hi Helge! On 01/12/2014 10:36 PM, Helge Deller wrote: >> Indeed. Congratulations on that! I'm glad to see the HPPA port coming >> back to life. I'd love to test it myself, but the only PA-RISC machine >> that I currently know of which is in my vicinity is located inside a >> laboratory at my physics department and it's still running HP-UX. >> Might be that it gets scrapped soon and replaced with something more >> fancy so that I can get hold of it, who knows ;). > > Good thing is, that those machines got pretty cheap now. > A Dualcore-C8000 workstation is available on ebay for < 100 EUR. If just had enough room. There are already too many Amigas taking up my space :). Still, I like to support the port as much as I can. >> I'm a Debian Developer with full upload permissions to the archive and >> would absolutely love to help you get the boot loader (and any other >> possibly necessary packages) back into Debian. > > Thanks! > AFAIK the bootloader is the only package which is parisc specific. Ok, good to know. >> The best is to have the package(s) uploaded to Debian Mentors [1] so I >> can grab them from there and review them, send you suggestions on >> improving them and finally upload them. > > I uploaded it, and CC'ed you on the request. > http://mentors.debian.net/package/palo > The info at top of the website is the latest package with most warnings fixed. > It would be nice if you could help me (off-list) further on that. Will do! I'll answer your separate mail later! >> Plus, it would be nice to have access to a PA-RISC machine myself so I >> can perform a test build and inspect the finished package. Would that >> be possible? > > Sure, I'll send you login details off-list. > If other people here on the list want access, please let me know. Thanks, got them. Will change the password and install my SSH key ASAP. > We had problems with sending mails from the buildds when I started the > buildds mid december. > Currently we have 5 buildds running: > http://unstable.buildd.net/index-hppa.html > Since around 2-3 weeks, all buildds except mx3210 do send build logs. Ah, glad to hear it has been fixed. Then there's nothing I am worrying about. Are you working together with Ingo Juergensmann to update the buildd status information on buildd.net? > I can reschedule a rebuild of radeontop for you, or you can just build it > yourself on the machine for which I send you a login. Just let me know. Don't worry about radeontop. I just picked that package as an example to check whether the build logs are still missing or not. This is one of my own packages and the last upload was just done a few weeks ago, so I thought I might check this one to see whether the problem has already been addressed. But when you say the logs are properly uploaded now, I'm happy. So, please don't reschedule the package, it will updated in the very near future anyway. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52d33683.2020...@physik.fu-berlin.de
Re: How to get a new palo source package into unstable?
Hello Helge!
On Sat, Jan 11, 2014 at 10:37:52PM +0100, Helge Deller wrote:
> as you might have noticed, we did huge progress on the HPPA (PA-RISC) port:
> http://buildd.debian-ports.org/stats/
Indeed. Congratulations on that! I'm glad to see the HPPA port coming
back to life. I'd love to test it myself, but the only PA-RISC machine
that I currently know of which is in my vicinity is located inside a
laboratory at my physics department and it's still running HP-UX.
Might be that it gets scrapped soon and replaced with something more
fancy so that I can get hold of it, who knows ;).
> In order to be able to boot parisc machines, the hppa port needs the "palo"
> debian package.
> "PALO" is the "PA-RISC boot loader" and a boot-loader-image generator,
> similar to
> "lilo" on i386 or "silo" on sparc.
Or "aboot" on the Alpha machines.
> I've continued to maintain and further develop palo.
> The new palo git repository is now at:
> git://git.kernel.org/pub/scm/linux/kernel/git/deller/palo.git
> and the source should compile and run on all plattforms.
> A simple checkout and dpkg-buildpackage should work.
Thank you very much for doing this (and the hard work of bringing the
buildds back to life). Even though I currently don't own a PA-RISC
machine, I'm very glad that someone took care of it, such that owners
of these machines can still use it with a current Debian release.
> Since I'm not a debian-developer, I don't know how to get this package into
> debian unstable again.
> What is the usual process to get a new/old package back into debian unstable?
> Maybe someone of you who has a debian developer rights is willing to upload
> the
> source package?
I'm a Debian Developer with full upload permissions to the archive and
would absolutely love to help you get the boot loader (and any other
possibly necessary packages) back into Debian.
The best is to have the package(s) uploaded to Debian Mentors [1] so I
can grab them from there and review them, send you suggestions on
improving them and finally upload them.
Plus, it would be nice to have access to a PA-RISC machine myself so I
can perform a test build and inspect the finished package. Would that
be possible?
PS: I have noticed that the HPPA builds never include the build log,
for example radeontop [2]. Would it be possible to have these
enabled as well, so we can easily find out what went wrong when a
build failed?
Cheers,
Adrian
> [1] http://mentors.debian.net/
> [2] http://buildd.debian-ports.org/status/package.php?p=radeontop&suite=sid
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
--
To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140112163248.ga10...@physik.fu-berlin.de
Re: Bug#730258: please add arch-specific BTS tags
On 11/24/2013 01:20 AM, Thorsten Glaser wrote: > John Paul Adrian Glaubitz dixit: >> So, the buildds are already up and running? Shouldn't they be showing >> up on buildd.debian-ports.org [1]? > > I think I saw buildd uploads for hppa on incoming.d.o this week. Indeed: > http://incoming.debian-ports.org/buildd/packages/unstable/main/ Very cool! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/529148de.8070...@physik.fu-berlin.de
Re: Bug#730258: please add arch-specific BTS tags
On 11/24/2013 12:47 AM, John David Anglin wrote: > On 23-Nov-13, at 6:35 PM, John Paul Adrian Glaubitz wrote: > >> Crossing my fingers! It's been sad to see the number of up-to-date >> packages in hppa dropping over the time. > > It should be going up now. So, the buildds are already up and running? Shouldn't they be showing up on buildd.debian-ports.org [1]? Adrian > [1] http://buildd.debian-ports.org/status/architecture.php?a=hppa&suite=sid -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52913f09.6080...@physik.fu-berlin.de
Re: Bug#730258: please add arch-specific BTS tags
On 11/24/2013 12:22 AM, Helge Deller wrote: > On 11/24/2013 12:21 AM, John Paul Adrian Glaubitz wrote: >> On 11/23/2013 11:51 PM, Helge Deller wrote: >>> Please add "hppa" >> >> Assuming that you are one of the hppa guys, how is the port doing? Any >> chance that the buildds will be up and running again anytime soon? > > Yes, think so. > I'm working on that just right now... Very cool! Hope you guys will soon be where we already are with the m68k port :). Crossing my fingers! It's been sad to see the number of up-to-date packages in hppa dropping over the time. Keep us updated! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52913bad.9000...@physik.fu-berlin.de
Re: Bug#730258: please add arch-specific BTS tags
On 11/23/2013 11:51 PM, Helge Deller wrote: >> What else am I missing? > > Please add "hppa" Assuming that you are one of the hppa guys, how is the port doing? Any chance that the buildds will be up and running again anytime soon? Cheers, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52913875.3080...@physik.fu-berlin.de
