Bug#918781: src:gnustep-base: odd FTBFS on powerpc, powerpcspe and ppc64
Mathieu Malaterre wrote: > Builds is ok, on MacMini G4 / 512M OK, thanks very much. Let's hope this was a transient failure.
Bug#918781: src:gnustep-base: odd FTBFS on powerpc, powerpcspe and ppc64
On Wed, Jan 9, 2019 at 1:59 PM Mathieu Malaterre wrote: > > On Wed, Jan 9, 2019 at 1:56 PM Yavor Doganov wrote: > > > > Mathieu Malaterre wrote: > > > On Wed, Jan 9, 2019 at 12:15 PM Yavor Doganov wrote: > > > > Mathieu Malaterre wrote: > > > > > Based on the error on powerpc (2): > > > > > > > > > > description.m:26:3: warning: passing argument 3 of > > > > > 'initWithXMLString:options:error:' from incompatible pointer type > > > > > [-Wincompatible-pointer-types] > > > > >xmlDoc = [[NSXMLDocument alloc] initWithXMLString:xmlDocStr > > > > > options:0 error:error]; > > > > >^~ > > > > > description.m:26:3: note: expected 'struct NSError **' but argument is > > > > > of type 'struct NSError *' > > > > > > > > OK, there's a typo here (should be ). But that's certainly not > > > > the reason for the failure; all NXSMLNode tests pass. > > > > > > > > > I would say something is bogus in the deps (update version number in > > > > > d/control to prevent possible incompatible deps). > > > > > > > > I'm afraid I don't understand. What's wrong with the deps? > > > > > > Reading from the error log, it felt like an API was changed (hence the > > > compilation error). So I suggested updating X.Y in something like > > > Depends: libfoo-dev (>= X.Y) in your d/control. > > > > But this doesn't make sense. That's gnustep-base's own testsuite > > which is self-contained: test programs link with the just built > > library and use uninstalled headers from the src tree for compilation. > > I fail to see what debian/control has to do with it. (And it's a > > warning, not compilation error, due to an innocent typo that's also > > present in the version in unstable.) > > I now realize my mistake. I grepped for "error:"... sorry for the noise. > > I'll give it a try on my powerpc box. Builds is ok, on MacMini G4 / 512M
Bug#918781: src:gnustep-base: odd FTBFS on powerpc, powerpcspe and ppc64
On Wed, Jan 9, 2019 at 1:56 PM Yavor Doganov wrote: > > Mathieu Malaterre wrote: > > On Wed, Jan 9, 2019 at 12:15 PM Yavor Doganov wrote: > > > Mathieu Malaterre wrote: > > > > Based on the error on powerpc (2): > > > > > > > > description.m:26:3: warning: passing argument 3 of > > > > 'initWithXMLString:options:error:' from incompatible pointer type > > > > [-Wincompatible-pointer-types] > > > >xmlDoc = [[NSXMLDocument alloc] initWithXMLString:xmlDocStr > > > > options:0 error:error]; > > > >^~ > > > > description.m:26:3: note: expected 'struct NSError **' but argument is > > > > of type 'struct NSError *' > > > > > > OK, there's a typo here (should be ). But that's certainly not > > > the reason for the failure; all NXSMLNode tests pass. > > > > > > > I would say something is bogus in the deps (update version number in > > > > d/control to prevent possible incompatible deps). > > > > > > I'm afraid I don't understand. What's wrong with the deps? > > > > Reading from the error log, it felt like an API was changed (hence the > > compilation error). So I suggested updating X.Y in something like > > Depends: libfoo-dev (>= X.Y) in your d/control. > > But this doesn't make sense. That's gnustep-base's own testsuite > which is self-contained: test programs link with the just built > library and use uninstalled headers from the src tree for compilation. > I fail to see what debian/control has to do with it. (And it's a > warning, not compilation error, due to an innocent typo that's also > present in the version in unstable.) I now realize my mistake. I grepped for "error:"... sorry for the noise. I'll give it a try on my powerpc box.
Bug#918781: src:gnustep-base: odd FTBFS on powerpc, powerpcspe and ppc64
Mathieu Malaterre wrote: > On Wed, Jan 9, 2019 at 12:15 PM Yavor Doganov wrote: > > Mathieu Malaterre wrote: > > > Based on the error on powerpc (2): > > > > > > description.m:26:3: warning: passing argument 3 of > > > 'initWithXMLString:options:error:' from incompatible pointer type > > > [-Wincompatible-pointer-types] > > >xmlDoc = [[NSXMLDocument alloc] initWithXMLString:xmlDocStr > > > options:0 error:error]; > > >^~ > > > description.m:26:3: note: expected 'struct NSError **' but argument is > > > of type 'struct NSError *' > > > > OK, there's a typo here (should be ). But that's certainly not > > the reason for the failure; all NXSMLNode tests pass. > > > > > I would say something is bogus in the deps (update version number in > > > d/control to prevent possible incompatible deps). > > > > I'm afraid I don't understand. What's wrong with the deps? > > Reading from the error log, it felt like an API was changed (hence the > compilation error). So I suggested updating X.Y in something like > Depends: libfoo-dev (>= X.Y) in your d/control. But this doesn't make sense. That's gnustep-base's own testsuite which is self-contained: test programs link with the just built library and use uninstalled headers from the src tree for compilation. I fail to see what debian/control has to do with it. (And it's a warning, not compilation error, due to an innocent typo that's also present in the version in unstable.)
Bug#918781: src:gnustep-base: odd FTBFS on powerpc, powerpcspe and ppc64
On Wed, Jan 9, 2019 at 12:15 PM Yavor Doganov wrote: > > Mathieu Malaterre wrote: > > Based on the error on powerpc (2): > > > > description.m:26:3: warning: passing argument 3 of > > 'initWithXMLString:options:error:' from incompatible pointer type > > [-Wincompatible-pointer-types] > >xmlDoc = [[NSXMLDocument alloc] initWithXMLString:xmlDocStr > > options:0 error:error]; > >^~ > > description.m:26:3: note: expected 'struct NSError **' but argument is > > of type 'struct NSError *' > > OK, there's a typo here (should be ). But that's certainly not > the reason for the failure; all NXSMLNode tests pass. > > > I would say something is bogus in the deps (update version number in > > d/control to prevent possible incompatible deps). > > I'm afraid I don't understand. What's wrong with the deps? Reading from the error log, it felt like an API was changed (hence the compilation error). So I suggested updating X.Y in something like Depends: libfoo-dev (>= X.Y) in your d/control. 2cts -M
Bug#918781: src:gnustep-base: odd FTBFS on powerpc, powerpcspe and ppc64
Mathieu Malaterre wrote: > Based on the error on powerpc (2): > > description.m:26:3: warning: passing argument 3 of > 'initWithXMLString:options:error:' from incompatible pointer type > [-Wincompatible-pointer-types] >xmlDoc = [[NSXMLDocument alloc] initWithXMLString:xmlDocStr > options:0 error:error]; >^~ > description.m:26:3: note: expected 'struct NSError **' but argument is > of type 'struct NSError *' OK, there's a typo here (should be ). But that's certainly not the reason for the failure; all NXSMLNode tests pass. > I would say something is bogus in the deps (update version number in > d/control to prevent possible incompatible deps). I'm afraid I don't understand. What's wrong with the deps?
Bug#918781: src:gnustep-base: odd FTBFS on powerpc, powerpcspe and ppc64
On Wed, Jan 9, 2019 at 11:21 AM Yavor Doganov wrote: > > Source: gnustep-base > Version: 1.26.0-1 > Severity: important > Tags: sid buster ftbfs > User: debian-powe...@lists.debian.org > Usertags: powerpc powerpcspe ppc64 > > Hi PowerPC folks, > > As the subject says, gnustep-base failed to build in experimental on > these architectures so I'd appreciate some help. > > The powerpcspe failure [1] is extremely awkward; the build appears > successful but the log seems truncated, interrupted during dh_install. > On powerpc [2] and ppc64 [3] there is testsuite failure, but all these > tests pass for me on gcc110 from the GCC Compile Farm. However, > that's different toolchain and it's not even running Debian so any > conclusion is unreliable. I don't have access to the porter machines > to test. > > Could these failures be related to the fact that kapitsa/kapitsa2 have > some network-related issues as uploading build logs appears to be > suspended for a certain (long) period? > > I guess give-backs on these three architectures wouldn't harm? Based on the error on powerpc (2): description.m:26:3: warning: passing argument 3 of 'initWithXMLString:options:error:' from incompatible pointer type [-Wincompatible-pointer-types] xmlDoc = [[NSXMLDocument alloc] initWithXMLString:xmlDocStr options:0 error:error]; ^~ description.m:26:3: note: expected 'struct NSError **' but argument is of type 'struct NSError *' I would say something is bogus in the deps (update version number in d/control to prevent possible incompatible deps). > [1] > https://buildd.debian.org/status/fetch.php?pkg=gnustep-base=powerpcspe=1.26.0-1=1546973971=0 > [2] > https://buildd.debian.org/status/fetch.php?pkg=gnustep-base=powerpc=1.26.0-1=1547024045=0 > [3] > https://buildd.debian.org/status/fetch.php?pkg=gnustep-base=ppc64=1.26.0-1=1547024045=0 >
Bug#918781: src:gnustep-base: odd FTBFS on powerpc, powerpcspe and ppc64
Source: gnustep-base Version: 1.26.0-1 Severity: important Tags: sid buster ftbfs User: debian-powe...@lists.debian.org Usertags: powerpc powerpcspe ppc64 Hi PowerPC folks, As the subject says, gnustep-base failed to build in experimental on these architectures so I'd appreciate some help. The powerpcspe failure [1] is extremely awkward; the build appears successful but the log seems truncated, interrupted during dh_install. On powerpc [2] and ppc64 [3] there is testsuite failure, but all these tests pass for me on gcc110 from the GCC Compile Farm. However, that's different toolchain and it's not even running Debian so any conclusion is unreliable. I don't have access to the porter machines to test. Could these failures be related to the fact that kapitsa/kapitsa2 have some network-related issues as uploading build logs appears to be suspended for a certain (long) period? I guess give-backs on these three architectures wouldn't harm? [1] https://buildd.debian.org/status/fetch.php?pkg=gnustep-base=powerpcspe=1.26.0-1=1546973971=0 [2] https://buildd.debian.org/status/fetch.php?pkg=gnustep-base=powerpc=1.26.0-1=1547024045=0 [3] https://buildd.debian.org/status/fetch.php?pkg=gnustep-base=ppc64=1.26.0-1=1547024045=0
