Bug#819452: [pkg-go] Bug#819452: golang-fsnotify: FTBFS, not working at all in ppc64el

2016-08-21 Thread Santiago Vila 
On Sun, Aug 21, 2016 at 11:27:14PM +0300, Adrian Bunk wrote:
> On Sun, Aug 21, 2016 at 09:55:26PM +0200, Santiago Vila wrote:
> > On Sun, Aug 21, 2016 at 10:49:22PM +0300, Adrian Bunk wrote:
> > > On Sun, Aug 21, 2016 at 09:05:19PM +0200, Santiago Vila wrote:
> > > > When a package fails to build from source, there are no runtime
> > > > problems at all, because the binary package does not even exist.
> > > 
> > > That is only true when the build always fails (see my next email).
> > 
> > Indeed. When I wrote that I was still confused about why "FTBFS"
> > was in the subject of this report.
> > 
> > Maybe he meant that the package made others packages to FTBFS (?).
> > I don't know.
> 
> golang-fsnotify builds only binary-all packages.
> 
> golang-fsnotify contains testcases.
> 
> This is not a normal FTBFS that you would see on the autobuilders
> (no autobuilder ever tried to build golang-fsnotify),
> but if you would try to build golang-fsnotify on ppc64el I assume
> the build would fail due to failing testcases.

Aha, so the subject could have been like this:

(FTBFS and not working at all) in ppc64el

and this is what I understood:

FTBFS and (not working at all in ppc64el)

Thanks for the claritication.

Bug#819452: [pkg-go] Bug#819452: golang-fsnotify: FTBFS, not working at all in ppc64el

2016-08-21 Thread Santiago Vila 
On Sun, Aug 21, 2016 at 11:06:02PM +0300, Adrian Bunk wrote:

> What misled me was that the first build was successful and only the 
> second build failed.
> 
> The failure in the second build is:
> === RUN   TestInotifyStress
> --- FAIL: TestInotifyStress (5.00s)
>   inotify_test.go:236: Creates and removes should not be off by more than 
> one: 1502 creates, 1509 removes
> 
> Is the second build constantly failing due to some difference in the 
> build environments (e.g. TestInotifyStress dislikes French), or is
> this a testcase that sometimes fails randomly?

I think it is more likely to be a testcase that sometimes fails
randomly, because I always have the same environment (provided by sbuild)
and it does also fail randomly for me.

> This seems clearly different from both #819452 and your
> "dpkg-buildpackage -A" issue.

Ok, as I think there are still some misunderstandings, here goes the
long explanation:

There was really no "dpkg-buildpackage -A" issue here.

I'm just checking that "dpkg-buildpackage -A" works.

When the package is "Arch: all" (like this one) and "dpkg-buildpackage -A"
fails, I use the build log as an evidence that the package FTBFS in the
usual sense, because in such case "dpkg-buildpackage -A" and
"dpkg-buildpackage" are just equivalent.

The only exception is when there is an absolutely trivial bug in
debian/rules, like binary-arch and binary-indep being swapped, but all
those bugs are already reported.

Is this usual FTBFS what I intended to report here, not any bug
of "dpkg-buildpackage -A" type.

> I agree with you that this is RC no matter whether it depends on the 
> environment or happens randomly.

Great. The random failure is reported here:

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

Thanks.

Bug#819452: [pkg-go] Bug#819452: golang-fsnotify: FTBFS, not working at all in ppc64el

2016-08-21 Thread Adrian Bunk 
On Sun, Aug 21, 2016 at 09:55:26PM +0200, Santiago Vila wrote:
> On Sun, Aug 21, 2016 at 10:49:22PM +0300, Adrian Bunk wrote:
> > On Sun, Aug 21, 2016 at 09:05:19PM +0200, Santiago Vila wrote:
> > > When a package fails to build from source, there are no runtime
> > > problems at all, because the binary package does not even exist.
> > 
> > That is only true when the build always fails (see my next email).
> 
> Indeed. When I wrote that I was still confused about why "FTBFS"
> was in the subject of this report.
> 
> Maybe he meant that the package made others packages to FTBFS (?).
> I don't know.

golang-fsnotify builds only binary-all packages.

golang-fsnotify contains testcases.

This is not a normal FTBFS that you would see on the autobuilders
(no autobuilder ever tried to build golang-fsnotify), but if you
would try to build golang-fsnotify on ppc64el I assume the build
would fail due to failing testcases.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#819452: [pkg-go] Bug#819452: golang-fsnotify: FTBFS, not working at all in ppc64el

2016-08-21 Thread Adrian Bunk 
Disclaimer:
I am not a maintainer of this package.


On Sun, Aug 21, 2016 at 09:21:15PM +0200, Santiago Vila wrote:
> On Sun, Aug 21, 2016 at 09:57:14PM +0300, Adrian Bunk wrote:
> 
> > For the "cannot build twice in a row" issue please file yet another 
> > (non-RC) bug.
> 
> I think you misunderstood my reference to reproducible builds completely.
> 
> When I said "fails on reproducible builds" I did not mean that the two
> builds made by reproducible builds differ, but instead that one of the
> builds failed, i.e. that the package FTBFS, which of course it is RC.
> 
> While we are at it, reproducible builds has nothing to do with
> "building twice in a row".
> 
> Building twice in a row means "dpkg-buildpackage; dpkg-buildpackage" fails,
> normally because of bugs in the clean target, but this is not what
> reproducible builds people do.

What misled me was that the first build was successful and only the 
second build failed.

The failure in the second build is:
=== RUN   TestInotifyStress
--- FAIL: TestInotifyStress (5.00s)
inotify_test.go:236: Creates and removes should not be off by more than 
one: 1502 creates, 1509 removes

Is the second build constantly failing due to some difference in the 
build environments (e.g. TestInotifyStress dislikes French), or is
this a testcase that sometimes fails randomly?

This seems clearly different from both #819452 and your
"dpkg-buildpackage -A" issue.

I agree with you that this is RC no matter whether it depends on the 
environment or happens randomly.

> Thanks.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#819452: [pkg-go] Bug#819452: golang-fsnotify: FTBFS, not working at all in ppc64el

2016-08-21 Thread Santiago Vila 
On Sun, Aug 21, 2016 at 10:49:22PM +0300, Adrian Bunk wrote:
> On Sun, Aug 21, 2016 at 09:05:19PM +0200, Santiago Vila wrote:
> > Ok, sorry, but then please retitle the bug and drop the FTBFS word.
> 
> I am just a random person going through RC bugs, but that sounds like a 
> good idea so I'm doing that now.

Thank you. I was going to do exactly the same but have been faster.

> > When a package fails to build from source, there are no runtime
> > problems at all, because the binary package does not even exist.
> 
> That is only true when the build always fails (see my next email).

Indeed. When I wrote that I was still confused about why "FTBFS"
was in the subject of this report.

Maybe he meant that the package made others packages to FTBFS (?).
I don't know.

Thanks.

Bug#819452: [pkg-go] Bug#819452: golang-fsnotify: FTBFS, not working at all in ppc64el

2016-08-21 Thread Adrian Bunk 
retitle 819452 golang-fsnotify: not working at all in ppc64el, arm64
thanks

On Sun, Aug 21, 2016 at 09:05:19PM +0200, Santiago Vila wrote:
> On Sun, Aug 21, 2016 at 09:57:14PM +0300, Adrian Bunk wrote:
> 
> > Please don't hijack an existing bug for an obviously unrelated issue,
> > or actually for two other issues that are both unrelated to this bug.
> > 
> > #819452 is about runtime problems on 64bit ppc and ARM, build problems 
> > on other architectures do not belong here.
> 
> Ok, sorry, but then please retitle the bug and drop the FTBFS word.

I am just a random person going through RC bugs, but that sounds like a 
good idea so I'm doing that now.

> When a package fails to build from source, there are no runtime
> problems at all, because the binary package does not even exist.

That is only true when the build always fails (see my next email).

> Thanks.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#819452: [pkg-go] Bug#819452: golang-fsnotify: FTBFS, not working at all in ppc64el

2016-08-21 Thread Santiago Vila 
On Sun, Aug 21, 2016 at 09:57:14PM +0300, Adrian Bunk wrote:

> For the "cannot build twice in a row" issue please file yet another 
> (non-RC) bug.

I think you misunderstood my reference to reproducible builds completely.

When I said "fails on reproducible builds" I did not mean that the two
builds made by reproducible builds differ, but instead that one of the
builds failed, i.e. that the package FTBFS, which of course it is RC.

While we are at it, reproducible builds has nothing to do with
"building twice in a row".

Building twice in a row means "dpkg-buildpackage; dpkg-buildpackage" fails,
normally because of bugs in the clean target, but this is not what
reproducible builds people do.

Thanks.

Bug#819452: [pkg-go] Bug#819452: golang-fsnotify: FTBFS, not working at all in ppc64el

2016-08-21 Thread Santiago Vila 
On Sun, Aug 21, 2016 at 09:57:14PM +0300, Adrian Bunk wrote:

> Please don't hijack an existing bug for an obviously unrelated issue,
> or actually for two other issues that are both unrelated to this bug.
> 
> #819452 is about runtime problems on 64bit ppc and ARM, build problems 
> on other architectures do not belong here.

Ok, sorry, but then please retitle the bug and drop the FTBFS word.

When a package fails to build from source, there are no runtime
problems at all, because the binary package does not even exist.

Thanks.

Bug#819452: [pkg-go] Bug#819452: golang-fsnotify: FTBFS, not working at all in ppc64el

2016-08-21 Thread Adrian Bunk 
severity 819452 important
thanks

On Fri, Aug 19, 2016 at 05:06:27PM +0200, Santiago Vila wrote:
> severity 819452 serious
> thanks
> 
> I could not build this package while checking for "dpkg-buildpackage -A",
> and it also fails on reproducible builds:
> 
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/golang-fsnotify.html
> 
> Raising severity accordingly.

Please don't hijack an existing bug for an obviously unrelated issue,
or actually for two other issues that are both unrelated to this bug.

#819452 is about runtime problems on 64bit ppc and ARM, build problems 
on other architectures do not belong here.

Please file a proper bug report for the "dpkg-buildpackage -A" issue, 
including the error message for that one.

For the "cannot build twice in a row" issue please file yet another 
(non-RC) bug.

> Thanks.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#819452: [pkg-go] Bug#819452: golang-fsnotify: FTBFS, not working at all in ppc64el

2016-08-19 Thread Santiago Vila 
severity 819452 serious
thanks

I could not build this package while checking for "dpkg-buildpackage -A",
and it also fails on reproducible builds:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/golang-fsnotify.html

Raising severity accordingly.

Thanks.

Bug#819452: [pkg-go] Bug#819452: golang-fsnotify: FTBFS, not working at all in ppc64el

2016-03-28 Thread Martín Ferrari 
On 29/03/16 00:17, Tianon Gravi wrote:

> Do you think it'd make sense to exclude ppc64el and arm64 from
> "Architectures" on this package until that upstream bug is resolved?

I think that would be a sane approach, it does not seem like there is
any obvious fix to this for now. You should exclude ppc64 too, and
possibly ask ftp-masters to remove these binaries?

> My own expertise in the kernel details of inotify is limited, but I
> don't see anything in the code of that package that ought to make it
> particularly unfriendly to these other architectures, so I'm not sure
> what other options we have. :(

Yeah, same here. I looked at the code, and tried to find any bug reports
wrt inotify and these arches, but could not find anything...

For the time being, I have modified prometheus to not use fsnotify at
all in these three architectures, so it would not be affected if you
remove fsnotify.


-- 
Martín Ferrari (Tincho)

Bug#819452: [pkg-go] Bug#819452: golang-fsnotify: FTBFS, not working at all in ppc64el

2016-03-28 Thread Tianon Gravi 
forwarded 819452 https://github.com/fsnotify/fsnotify/issues/130
thanks

On 28 March 2016 at 10:30, Martín Ferrari  wrote:
> As I reported upstream (https://github.com/fsnotify/fsnotify/issues/130),
> fsnotify does not seem to work at all in ppc64el. I noticed this when trying 
> to
> solve a FTBFS in prometheus, that can be tracked down to this module not
> producing any events in that architecture.

Do you think it'd make sense to exclude ppc64el and arm64 from
"Architectures" on this package until that upstream bug is resolved?

My own expertise in the kernel details of inotify is limited, but I
don't see anything in the code of that package that ought to make it
particularly unfriendly to these other architectures, so I'm not sure
what other options we have. :(

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Bug#819452: golang-fsnotify: FTBFS, not working at all in ppc64el

2016-03-28 Thread Martín Ferrari 
Source: golang-fsnotify
Version: 1.2.9-1
Severity: important
Tags: upstream

As I reported upstream (https://github.com/fsnotify/fsnotify/issues/130),
fsnotify does not seem to work at all in ppc64el. I noticed this when trying to
solve a FTBFS in prometheus, that can be tracked down to this module not
producing any events in that architecture.


-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (100, 'unstable'), (50, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.4.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)