Re: FreeBSD_HEAD_amd64_gcc - Build #1144 - Failure

[Baptiste Daroussin]

On Mon, Apr 04, 2016 at 08:38:03PM +0800, Li-Wen Hsu wrote:
> On Mon, Apr 04, 2016 at 14:32:35 +0200, Baptiste Daroussin wrote:
> > On Mon, Apr 04, 2016 at 08:25:39PM +0800, Li-Wen Hsu wrote:
> > > On Mon, Apr 04, 2016 at 12:53:16 +0200, Baptiste Daroussin wrote:
> > > > On Mon, Apr 04, 2016 at 06:39:00PM +0800, Li-Wen Hsu wrote:
> > > > > On Mon, Apr 04, 2016 at 00:50:14 +0200, Baptiste Daroussin wrote:
> > > > > > On Mon, Apr 04, 2016 at 04:41:47AM +0800, Li-Wen Hsu wrote:
> > > > > > > I've checked this a little more, I found the return code of
> > > > > > > "installing a installed package" has been changed.
> > > > > > > 
> > > > > > > For pkg 1.6.4_1, it returns 0, but 1.7.1 returns 70, thus jenkins
> > > > > > > consider the build script execution failure.
> > > > > > > 
> > > > > > > 
> > > > > > It shoudl not return 70 if it returns 70 then there is a bug I can 
> > > > > > fix, I need
> > > > > > to know more about what is failing to be able to fix
> > > > > 
> > > > > What else information do you need?  My experiment is as following:
> > > > > 
> > > > > On a machine uses quarterly branch, where pkg is 1.6.4_1, install a
> > > > > installed package.  I choose rsync here, then echo $?, it returns 0.
> > > > > 
> > > > > And I switch to latest branch, also use `pkg install -y rsync`, but 
> > > > > this
> > > > > time $? is 70.
> > > > > 
> > > > > Jenkins "Execute shell" build step checks return value of each command
> > > > > in the shell script, if it is non-zero, it aborts the build and
> > > > > considers if failure.
> > > > 
> > > > Return 70 means an error occured. if I look at the log I can see that
> > > > powerpc64-gcc is not installed for sure, hence the error 70
> > > > 
> > > > What is strange it that no "error message is shown"
> > > 
> > > Very strange, no further error message is shown, even -d provided.
> > > 
> > > root@jenkins10a:~ # pkg -d install -y devel/amd64-xtoolchain-gcc
> > > DBG(1)[44393]> pkg initialized
> > > Updating FreeBSD repository catalogue...
> > > DBG(1)[44393]> PkgRepo: verifying update for FreeBSD
> > > DBG(1)[44393]> Pkgrepo, begin update of '/var/db/pkg/repo-FreeBSD.sqlite'
> > > DBG(1)[44393]> Fetch: fetching from: 
> > > http://pkgmir.pkg.freebsd.org/FreeBSD:10:amd64/latest/meta.txz with opts 
> > > "i"
> > > DBG(1)[44393]> Fetch: fetching from: 
> > > http://pkgmir.pkg.freebsd.org/FreeBSD:10:amd64/latest/packagesite.txz 
> > > with opts "i"
> > > FreeBSD repository is up-to-date.
> > > All repositories are up-to-date.
> > > DBG(1)[44393]> want to get an advisory lock on a database
> > > DBG(1)[44393]> release an advisory lock on a database
> > > root@jenkins10a:~ # echo $?
> > > 70
> > > 
> > > Is there anything I can help on debugging this?
> > > 
> > pkg info amd64-xtoolchain-gcc please
> 
> root@jenkins10a:~ # pkg -d info amd64-xtoolchain-gcc
> DBG(1)[44644]> pkg initialized
> amd64-xtoolchain-gcc-0.1
> Name   : amd64-xtoolchain-gcc
> Version: 0.1
> Installed on   : Tue Mar  3 07:32:25 2015 UTC
> Origin : devel/amd64-xtoolchain-gcc
> Architecture   : freebsd:10:x86:64
> Prefix : /usr/local
> Categories : devel
> Licenses   :
> Maintainer : b...@freebsd.org
> WWW: UNKNOWN
> Comment: Pre seeded toolchain to cross build FreeBSD base
> Annotations:
> repo_type  : binary
> repository : FreeBSD
> Flat size  : 225B
> Description:
> Pre seeded cross toolchain definition to cross build FreeBSD base
> 

Ok I see the issue, I will fix it thanks.

Bapt


signature.asc
Description: PGP signature

Re: FreeBSD_HEAD_amd64_gcc - Build #1144 - Failure

[Li-Wen Hsu]

On Mon, Apr 04, 2016 at 14:32:35 +0200, Baptiste Daroussin wrote:
> On Mon, Apr 04, 2016 at 08:25:39PM +0800, Li-Wen Hsu wrote:
> > On Mon, Apr 04, 2016 at 12:53:16 +0200, Baptiste Daroussin wrote:
> > > On Mon, Apr 04, 2016 at 06:39:00PM +0800, Li-Wen Hsu wrote:
> > > > On Mon, Apr 04, 2016 at 00:50:14 +0200, Baptiste Daroussin wrote:
> > > > > On Mon, Apr 04, 2016 at 04:41:47AM +0800, Li-Wen Hsu wrote:
> > > > > > I've checked this a little more, I found the return code of
> > > > > > "installing a installed package" has been changed.
> > > > > > 
> > > > > > For pkg 1.6.4_1, it returns 0, but 1.7.1 returns 70, thus jenkins
> > > > > > consider the build script execution failure.
> > > > > > 
> > > > > > 
> > > > > It shoudl not return 70 if it returns 70 then there is a bug I can 
> > > > > fix, I need
> > > > > to know more about what is failing to be able to fix
> > > > 
> > > > What else information do you need?  My experiment is as following:
> > > > 
> > > > On a machine uses quarterly branch, where pkg is 1.6.4_1, install a
> > > > installed package.  I choose rsync here, then echo $?, it returns 0.
> > > > 
> > > > And I switch to latest branch, also use `pkg install -y rsync`, but this
> > > > time $? is 70.
> > > > 
> > > > Jenkins "Execute shell" build step checks return value of each command
> > > > in the shell script, if it is non-zero, it aborts the build and
> > > > considers if failure.
> > > 
> > > Return 70 means an error occured. if I look at the log I can see that
> > > powerpc64-gcc is not installed for sure, hence the error 70
> > > 
> > > What is strange it that no "error message is shown"
> > 
> > Very strange, no further error message is shown, even -d provided.
> > 
> > root@jenkins10a:~ # pkg -d install -y devel/amd64-xtoolchain-gcc
> > DBG(1)[44393]> pkg initialized
> > Updating FreeBSD repository catalogue...
> > DBG(1)[44393]> PkgRepo: verifying update for FreeBSD
> > DBG(1)[44393]> Pkgrepo, begin update of '/var/db/pkg/repo-FreeBSD.sqlite'
> > DBG(1)[44393]> Fetch: fetching from: 
> > http://pkgmir.pkg.freebsd.org/FreeBSD:10:amd64/latest/meta.txz with opts "i"
> > DBG(1)[44393]> Fetch: fetching from: 
> > http://pkgmir.pkg.freebsd.org/FreeBSD:10:amd64/latest/packagesite.txz with 
> > opts "i"
> > FreeBSD repository is up-to-date.
> > All repositories are up-to-date.
> > DBG(1)[44393]> want to get an advisory lock on a database
> > DBG(1)[44393]> release an advisory lock on a database
> > root@jenkins10a:~ # echo $?
> > 70
> > 
> > Is there anything I can help on debugging this?
> > 
> pkg info amd64-xtoolchain-gcc please

root@jenkins10a:~ # pkg -d info amd64-xtoolchain-gcc
DBG(1)[44644]> pkg initialized
amd64-xtoolchain-gcc-0.1
Name   : amd64-xtoolchain-gcc
Version: 0.1
Installed on   : Tue Mar  3 07:32:25 2015 UTC
Origin : devel/amd64-xtoolchain-gcc
Architecture   : freebsd:10:x86:64
Prefix : /usr/local
Categories : devel
Licenses   :
Maintainer : b...@freebsd.org
WWW: UNKNOWN
Comment: Pre seeded toolchain to cross build FreeBSD base
Annotations:
repo_type  : binary
repository : FreeBSD
Flat size  : 225B
Description:
Pre seeded cross toolchain definition to cross build FreeBSD base



-- 
Li-Wen Hsu 
https://lwhsu.org


pgpdHfuwNBFfu.pgp
Description: PGP signature

Re: FreeBSD_HEAD_amd64_gcc - Build #1144 - Failure

[Baptiste Daroussin]

On Mon, Apr 04, 2016 at 08:25:39PM +0800, Li-Wen Hsu wrote:
> On Mon, Apr 04, 2016 at 12:53:16 +0200, Baptiste Daroussin wrote:
> > On Mon, Apr 04, 2016 at 06:39:00PM +0800, Li-Wen Hsu wrote:
> > > On Mon, Apr 04, 2016 at 00:50:14 +0200, Baptiste Daroussin wrote:
> > > > On Mon, Apr 04, 2016 at 04:41:47AM +0800, Li-Wen Hsu wrote:
> > > > > I've checked this a little more, I found the return code of
> > > > > "installing a installed package" has been changed.
> > > > > 
> > > > > For pkg 1.6.4_1, it returns 0, but 1.7.1 returns 70, thus jenkins
> > > > > consider the build script execution failure.
> > > > > 
> > > > > 
> > > > It shoudl not return 70 if it returns 70 then there is a bug I can fix, 
> > > > I need
> > > > to know more about what is failing to be able to fix
> > > 
> > > What else information do you need?  My experiment is as following:
> > > 
> > > On a machine uses quarterly branch, where pkg is 1.6.4_1, install a
> > > installed package.  I choose rsync here, then echo $?, it returns 0.
> > > 
> > > And I switch to latest branch, also use `pkg install -y rsync`, but this
> > > time $? is 70.
> > > 
> > > Jenkins "Execute shell" build step checks return value of each command
> > > in the shell script, if it is non-zero, it aborts the build and
> > > considers if failure.
> > 
> > Return 70 means an error occured. if I look at the log I can see that
> > powerpc64-gcc is not installed for sure, hence the error 70
> > 
> > What is strange it that no "error message is shown"
> 
> Very strange, no further error message is shown, even -d provided.
> 
> root@jenkins10a:~ # pkg -d install -y devel/amd64-xtoolchain-gcc
> DBG(1)[44393]> pkg initialized
> Updating FreeBSD repository catalogue...
> DBG(1)[44393]> PkgRepo: verifying update for FreeBSD
> DBG(1)[44393]> Pkgrepo, begin update of '/var/db/pkg/repo-FreeBSD.sqlite'
> DBG(1)[44393]> Fetch: fetching from: 
> http://pkgmir.pkg.freebsd.org/FreeBSD:10:amd64/latest/meta.txz with opts "i"
> DBG(1)[44393]> Fetch: fetching from: 
> http://pkgmir.pkg.freebsd.org/FreeBSD:10:amd64/latest/packagesite.txz with 
> opts "i"
> FreeBSD repository is up-to-date.
> All repositories are up-to-date.
> DBG(1)[44393]> want to get an advisory lock on a database
> DBG(1)[44393]> release an advisory lock on a database
> root@jenkins10a:~ # echo $?
> 70
> 
> Is there anything I can help on debugging this?
> 
pkg info amd64-xtoolchain-gcc please

Bapt


signature.asc
Description: PGP signature

Re: FreeBSD_HEAD_amd64_gcc - Build #1144 - Failure

[Li-Wen Hsu]

On Mon, Apr 04, 2016 at 12:53:16 +0200, Baptiste Daroussin wrote:
> On Mon, Apr 04, 2016 at 06:39:00PM +0800, Li-Wen Hsu wrote:
> > On Mon, Apr 04, 2016 at 00:50:14 +0200, Baptiste Daroussin wrote:
> > > On Mon, Apr 04, 2016 at 04:41:47AM +0800, Li-Wen Hsu wrote:
> > > > I've checked this a little more, I found the return code of
> > > > "installing a installed package" has been changed.
> > > > 
> > > > For pkg 1.6.4_1, it returns 0, but 1.7.1 returns 70, thus jenkins
> > > > consider the build script execution failure.
> > > > 
> > > > 
> > > It shoudl not return 70 if it returns 70 then there is a bug I can fix, I 
> > > need
> > > to know more about what is failing to be able to fix
> > 
> > What else information do you need?  My experiment is as following:
> > 
> > On a machine uses quarterly branch, where pkg is 1.6.4_1, install a
> > installed package.  I choose rsync here, then echo $?, it returns 0.
> > 
> > And I switch to latest branch, also use `pkg install -y rsync`, but this
> > time $? is 70.
> > 
> > Jenkins "Execute shell" build step checks return value of each command
> > in the shell script, if it is non-zero, it aborts the build and
> > considers if failure.
> 
> Return 70 means an error occured. if I look at the log I can see that
> powerpc64-gcc is not installed for sure, hence the error 70
> 
> What is strange it that no "error message is shown"

Very strange, no further error message is shown, even -d provided.

root@jenkins10a:~ # pkg -d install -y devel/amd64-xtoolchain-gcc
DBG(1)[44393]> pkg initialized
Updating FreeBSD repository catalogue...
DBG(1)[44393]> PkgRepo: verifying update for FreeBSD
DBG(1)[44393]> Pkgrepo, begin update of '/var/db/pkg/repo-FreeBSD.sqlite'
DBG(1)[44393]> Fetch: fetching from: 
http://pkgmir.pkg.freebsd.org/FreeBSD:10:amd64/latest/meta.txz with opts "i"
DBG(1)[44393]> Fetch: fetching from: 
http://pkgmir.pkg.freebsd.org/FreeBSD:10:amd64/latest/packagesite.txz with opts 
"i"
FreeBSD repository is up-to-date.
All repositories are up-to-date.
DBG(1)[44393]> want to get an advisory lock on a database
DBG(1)[44393]> release an advisory lock on a database
root@jenkins10a:~ # echo $?
70

Is there anything I can help on debugging this?

Li-Wen


-- 
Li-Wen Hsu 
https://lwhsu.org


pgpeYe5_Z1goK.pgp
Description: PGP signature

Re: FreeBSD_HEAD_amd64_gcc - Build #1144 - Failure

[Baptiste Daroussin]

On Mon, Apr 04, 2016 at 06:39:00PM +0800, Li-Wen Hsu wrote:
> On Mon, Apr 04, 2016 at 00:50:14 +0200, Baptiste Daroussin wrote:
> > On Mon, Apr 04, 2016 at 04:41:47AM +0800, Li-Wen Hsu wrote:
> > > I've checked this a little more, I found the return code of
> > > "installing a installed package" has been changed.
> > > 
> > > For pkg 1.6.4_1, it returns 0, but 1.7.1 returns 70, thus jenkins
> > > consider the build script execution failure.
> > > 
> > > 
> > It shoudl not return 70 if it returns 70 then there is a bug I can fix, I 
> > need
> > to know more about what is failing to be able to fix
> 
> What else information do you need?  My experiment is as following:
> 
> On a machine uses quarterly branch, where pkg is 1.6.4_1, install a
> installed package.  I choose rsync here, then echo $?, it returns 0.
> 
> And I switch to latest branch, also use `pkg install -y rsync`, but this
> time $? is 70.
> 
> Jenkins "Execute shell" build step checks return value of each command
> in the shell script, if it is non-zero, it aborts the build and
> considers if failure.

Return 70 means an error occured. if I look at the log I can see that
powerpc64-gcc is not installed for sure, hence the error 70

What is strange it that no "error message is shown"

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: FreeBSD_HEAD_amd64_gcc - Build #1144 - Failure

[Li-Wen Hsu]

On Mon, Apr 04, 2016 at 00:50:14 +0200, Baptiste Daroussin wrote:
> On Mon, Apr 04, 2016 at 04:41:47AM +0800, Li-Wen Hsu wrote:
> > I've checked this a little more, I found the return code of
> > "installing a installed package" has been changed.
> > 
> > For pkg 1.6.4_1, it returns 0, but 1.7.1 returns 70, thus jenkins
> > consider the build script execution failure.
> > 
> > 
> It shoudl not return 70 if it returns 70 then there is a bug I can fix, I need
> to know more about what is failing to be able to fix

What else information do you need?  My experiment is as following:

On a machine uses quarterly branch, where pkg is 1.6.4_1, install a
installed package.  I choose rsync here, then echo $?, it returns 0.

And I switch to latest branch, also use `pkg install -y rsync`, but this
time $? is 70.

Jenkins "Execute shell" build step checks return value of each command
in the shell script, if it is non-zero, it aborts the build and
considers if failure.


Regards,
Li-Wen

-- 
Li-Wen Hsu 
https://lwhsu.org


pgp4Q687kR8Pv.pgp
Description: PGP signature

Re: FreeBSD_HEAD_amd64_gcc - Build #1144 - Failure

[Baptiste Daroussin]

On Mon, Apr 04, 2016 at 04:41:47AM +0800, Li-Wen Hsu wrote:
> On Mon, Apr 4, 2016 at 1:59 AM, Dimitry Andric <d...@freebsd.org> wrote:
> > On 03 Apr 2016, at 19:19, Andriy Gapon <a...@freebsd.org> wrote:
> >> On 03/04/2016 12:39, jenkins-ad...@freebsd.org wrote:
> >>> FreeBSD_HEAD_amd64_gcc - Build #1144 - Failure:
> >>>
> >>> Build information: 
> >>> https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1144/
> >>> Full change log: 
> >>> https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1144/changes
> >>> Full build log: 
> >>> https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1144/console
> >>>
> >>
> >> I wasn't able to understand what was the failure here...
> >
> > The step to install the amd64-xtoolchain-gcc package failed, apparently 
> > because it decided to auto-upgrade pkg first, without actually installing 
> > the package that was asked for:
> >
> > + sudo pkg install -y devel/amd64-xtoolchain-gcc
> > Updating FreeBSD repository catalogue...
> > Fetching meta.txz: . done
> > Fetching packagesite.txz: .. done
> > Processing entries: .. done
> > FreeBSD repository update completed. 25093 packages processed.
> > New version of pkg detected; it needs to be installed first.
> > The following 1 package(s) will be affected (of 0 checked):
> >
> > Installed packages to be UPGRADED:
> > pkg: 1.6.4_1 -> 1.7.1
> >
> > The process will require 84 KiB more space.
> > 2 MiB to be downloaded.
> > Fetching pkg-1.7.1.txz: .. done
> > Checking integrity... done (0 conflicting)
> > [1/1] Upgrading pkg from 1.6.4_1 to 1.7.1...
> > [1/1] Extracting pkg-1.7.1: .. done
> > Updating FreeBSD repository catalogue...
> > Repo "FreeBSD" upgrade schema 2012 to 2013: Add vital field
> > FreeBSD repository is up-to-date.
> > All repositories are up-to-date.
> > Build step 'Execute shell' marked build as failure
> >
> > I'd consider this a bug in pkg?  Is it suppose to return a failure code in 
> > this case?
> 
> I've checked this a little more, I found the return code of
> "installing a installed package" has been changed.
> 
> For pkg 1.6.4_1, it returns 0, but 1.7.1 returns 70, thus jenkins
> consider the build script execution failure.
> 
> 
It shoudl not return 70 if it returns 70 then there is a bug I can fix, I need
to know more about what is failing to be able to fix

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: FreeBSD_HEAD_amd64_gcc - Build #1144 - Failure

[Li-Wen Hsu]

On Mon, Apr 4, 2016 at 1:59 AM, Dimitry Andric <d...@freebsd.org> wrote:
> On 03 Apr 2016, at 19:19, Andriy Gapon <a...@freebsd.org> wrote:
>> On 03/04/2016 12:39, jenkins-ad...@freebsd.org wrote:
>>> FreeBSD_HEAD_amd64_gcc - Build #1144 - Failure:
>>>
>>> Build information: 
>>> https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1144/
>>> Full change log: 
>>> https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1144/changes
>>> Full build log: 
>>> https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1144/console
>>>
>>
>> I wasn't able to understand what was the failure here...
>
> The step to install the amd64-xtoolchain-gcc package failed, apparently 
> because it decided to auto-upgrade pkg first, without actually installing the 
> package that was asked for:
>
> + sudo pkg install -y devel/amd64-xtoolchain-gcc
> Updating FreeBSD repository catalogue...
> Fetching meta.txz: . done
> Fetching packagesite.txz: .. done
> Processing entries: .. done
> FreeBSD repository update completed. 25093 packages processed.
> New version of pkg detected; it needs to be installed first.
> The following 1 package(s) will be affected (of 0 checked):
>
> Installed packages to be UPGRADED:
> pkg: 1.6.4_1 -> 1.7.1
>
> The process will require 84 KiB more space.
> 2 MiB to be downloaded.
> Fetching pkg-1.7.1.txz: .. done
> Checking integrity... done (0 conflicting)
> [1/1] Upgrading pkg from 1.6.4_1 to 1.7.1...
> [1/1] Extracting pkg-1.7.1: .. done
> Updating FreeBSD repository catalogue...
> Repo "FreeBSD" upgrade schema 2012 to 2013: Add vital field
> FreeBSD repository is up-to-date.
> All repositories are up-to-date.
> Build step 'Execute shell' marked build as failure
>
> I'd consider this a bug in pkg?  Is it suppose to return a failure code in 
> this case?

I've checked this a little more, I found the return code of
"installing a installed package" has been changed.

For pkg 1.6.4_1, it returns 0, but 1.7.1 returns 70, thus jenkins
consider the build script execution failure.


Li-Wen

-- 
Li-Wen Hsu <lw...@freebsd.org>
https://lwhsu.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD_HEAD_amd64_gcc - Build #1144 - Failure

[Dimitry Andric]

On 03 Apr 2016, at 19:19, Andriy Gapon <a...@freebsd.org> wrote:
> On 03/04/2016 12:39, jenkins-ad...@freebsd.org wrote:
>> FreeBSD_HEAD_amd64_gcc - Build #1144 - Failure:
>> 
>> Build information: 
>> https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1144/
>> Full change log: 
>> https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1144/changes
>> Full build log: 
>> https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1144/console
>> 
> 
> I wasn't able to understand what was the failure here...

The step to install the amd64-xtoolchain-gcc package failed, apparently because 
it decided to auto-upgrade pkg first, without actually installing the package 
that was asked for:

+ sudo pkg install -y devel/amd64-xtoolchain-gcc
Updating FreeBSD repository catalogue...
Fetching meta.txz: . done
Fetching packagesite.txz: .. done
Processing entries: .. done
FreeBSD repository update completed. 25093 packages processed.
New version of pkg detected; it needs to be installed first.
The following 1 package(s) will be affected (of 0 checked):

Installed packages to be UPGRADED:
pkg: 1.6.4_1 -> 1.7.1

The process will require 84 KiB more space.
2 MiB to be downloaded.
Fetching pkg-1.7.1.txz: .. done
Checking integrity... done (0 conflicting)
[1/1] Upgrading pkg from 1.6.4_1 to 1.7.1...
[1/1] Extracting pkg-1.7.1: .. done
Updating FreeBSD repository catalogue...
Repo "FreeBSD" upgrade schema 2012 to 2013: Add vital field
FreeBSD repository is up-to-date.
All repositories are up-to-date.
Build step 'Execute shell' marked build as failure

I'd consider this a bug in pkg?  Is it suppose to return a failure code in this 
case?

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: FreeBSD_HEAD_amd64_gcc - Build #1144 - Failure

[Andriy Gapon]

I wasn't able to understand what was the failure here...

On 03/04/2016 12:39, jenkins-ad...@freebsd.org wrote:
> FreeBSD_HEAD_amd64_gcc - Build #1144 - Failure:
> 
> Build information: 
> https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1144/
> Full change log: 
> https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1144/changes
> Full build log: 
> https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1144/console
> 
> Change summaries:
> 
> 297521 by avg:
> fix zfs set canmount=off on an unmounted filesystem
> 
> Previously this operation tried to unmount and remount children.
> Also see https://www.illumos.org/issues/6428.
> 
> MFC after:2 weeks
> X-Needs-Upstreaming:  illumos
> 
> 297520 by avg:
> zfs receive: -u can be ignored sometimes
> 
> When force-receiving a filesystem that was already mounted the re-created
> filesystem is mounted despite -u flag.
> 
> Also see https://www.illumos.org/issues/6412.
> 
> PR:   204705
> Tested by:Vladimir Krstulja <vlad-f...@acheronmedia.com>
> MFC after:2 weeks
> X-Needs-Upstreaming:  illumos
> 
> 297519 by dchagin:
> Move Linux specific times tests up to guarantee the values are defined.
> 
> CID:  1305178
> Submitted by: pfg@
> MFC after:1 week
> 
> 297514 by jmcneill:
> Improve HDMI display detection by searching the CEA-861 extension block for
> an HDMI vendor-specific data block (VSDB) containing the HDMI 24-bit IEEE
> registration ID (0x000C03).
> 
> Approved by:  gonzo (mentor)
> 
> 297513 by avg:
> remove emulation of VFS_HOLD and VFS_RELE from opensolaris compat
> 
> On FreeBSD VFS_HOLD/VN_RELE were mapped to MNT_REF/MNT_REL that
> manipulate mnt_ref.  But the job of properly maintaining the reference
> count is already automatically performed by insmntque(9) and
> delmntque(9).  So, in effect all ZFS vnodes referenced the corresponding
> mountpoint twice.
> 
> That was completely harmless, but we want to be very explicit about what
> FreeBSD VFS APIs are used, because illumos VFS_HOLD and FreeBSD MNT_REF
> provide quite different guarantees with respect to the held vfs_t /
> mountpoint.  On illumos VFS_HOLD is sufficient to guarantee that
> vfs_t.vfs_data stays valid.  On the other hand, on FreeBSD MNT_REF does
> *not* provide the same guarantee about mnt_data.  We have to use
> vfs_busy() to get that guarantee.
> 
> Thus, the calls to VFS_HOLD/VFS_RELE on vnode init and fini are removed.
> VFS_HOLD calls are replaced with vfs_busy in the ioctl handlers.
> 
> And because vfs_busy has a richer interface that can not be dumbed down
> in all cases it's better to explicitly use it rather than trying to mask
> it behind VFS_HOLD.
> 
> This change fixes a panic that could result from a race between
> zfs_umount() and zfs_ioc_rollback().  We observed a case where
> zfsvfs_free() tried to destroy data that zfsvfs_teardown() was still
> using.  That happened because there was nothing to prevent unmounting of
> a ZFS filesystem that was in between zfs_suspend_fs() and
> zfs_resume_fs().
> 
> Reviewed by:  kib, smh
> MFC after:3 weeks
> Sponsored by: ClusterHQ
> Differential Revision: https://reviews.freebsd.org/D2794
> 
> 
> 
> The end of the build log:
> 
> Started by an SCM change
> Building remotely on jenkins10a.freebsd.org (FreeBSD-10) in workspace 
> /builds/FreeBSD_HEAD_amd64_gcc
> Updating svn://svn.freebsd.org/base/head at revision '2016-04-03T09:38:08.949 
> +'
> U cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c
> U cddl/contrib/opensolaris/lib/libzfs/common/libzfs_sendrecv.c
> U sys/compat/linux/linux_misc.c
> U sys/arm/allwinner/a10_hdmi.c
> U sys/cddl/compat/opensolaris/sys/vfs.h
> U sys/cddl/contrib/opensolaris/uts/common/fs/gfs.c
> U sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c
> U sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c
> At revision 297521
> 
> No emails were triggered.
> [FreeBSD_HEAD_amd64_gcc] $ /bin/sh -xe /tmp/hudson8754098237068074298.sh
> + cat
> + svn revert Makefile.inc1
> + svn revert sys/boot/i386/Makefile
> Reverted 'sys/boot/i386/Makefile'
> + patch -f
> Hmm...  Looks like a unified diff to me...
> The text leading up to this was:
> --
> |Index: sys/boot/i386/Makefile
> |===
> |--- sys/boot/i386/Makefile   (revision 280912)
> |+++ sys/boot/i386/Makefile   (working copy)
> --
> Patching file sys/boot/i386/Makefile using Plan A...
> Hunk #1 succeeded at 16 

FreeBSD_HEAD_amd64_gcc - Build #1144 - Failure

[jenkins-admin]

FreeBSD_HEAD_amd64_gcc - Build #1144 - Failure:

Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1144/
Full change log: 
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1144/changes
Full build log: 
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1144/console

Change summaries:

297521 by avg:
fix zfs set canmount=off on an unmounted filesystem

Previously this operation tried to unmount and remount children.
Also see https://www.illumos.org/issues/6428.

MFC after:  2 weeks
X-Needs-Upstreaming:illumos

297520 by avg:
zfs receive: -u can be ignored sometimes

When force-receiving a filesystem that was already mounted the re-created
filesystem is mounted despite -u flag.

Also see https://www.illumos.org/issues/6412.

PR: 204705
Tested by:  Vladimir Krstulja <vlad-f...@acheronmedia.com>
MFC after:  2 weeks
X-Needs-Upstreaming:illumos

297519 by dchagin:
Move Linux specific times tests up to guarantee the values are defined.

CID:1305178
Submitted by:   pfg@
MFC after:  1 week

297514 by jmcneill:
Improve HDMI display detection by searching the CEA-861 extension block for
an HDMI vendor-specific data block (VSDB) containing the HDMI 24-bit IEEE
registration ID (0x000C03).

Approved by:gonzo (mentor)

297513 by avg:
remove emulation of VFS_HOLD and VFS_RELE from opensolaris compat

On FreeBSD VFS_HOLD/VN_RELE were mapped to MNT_REF/MNT_REL that
manipulate mnt_ref.  But the job of properly maintaining the reference
count is already automatically performed by insmntque(9) and
delmntque(9).  So, in effect all ZFS vnodes referenced the corresponding
mountpoint twice.

That was completely harmless, but we want to be very explicit about what
FreeBSD VFS APIs are used, because illumos VFS_HOLD and FreeBSD MNT_REF
provide quite different guarantees with respect to the held vfs_t /
mountpoint.  On illumos VFS_HOLD is sufficient to guarantee that
vfs_t.vfs_data stays valid.  On the other hand, on FreeBSD MNT_REF does
*not* provide the same guarantee about mnt_data.  We have to use
vfs_busy() to get that guarantee.

Thus, the calls to VFS_HOLD/VFS_RELE on vnode init and fini are removed.
VFS_HOLD calls are replaced with vfs_busy in the ioctl handlers.

And because vfs_busy has a richer interface that can not be dumbed down
in all cases it's better to explicitly use it rather than trying to mask
it behind VFS_HOLD.

This change fixes a panic that could result from a race between
zfs_umount() and zfs_ioc_rollback().  We observed a case where
zfsvfs_free() tried to destroy data that zfsvfs_teardown() was still
using.  That happened because there was nothing to prevent unmounting of
a ZFS filesystem that was in between zfs_suspend_fs() and
zfs_resume_fs().

Reviewed by:kib, smh
MFC after:  3 weeks
Sponsored by:   ClusterHQ
Differential Revision: https://reviews.freebsd.org/D2794



The end of the build log:

Started by an SCM change
Building remotely on jenkins10a.freebsd.org (FreeBSD-10) in workspace 
/builds/FreeBSD_HEAD_amd64_gcc
Updating svn://svn.freebsd.org/base/head at revision '2016-04-03T09:38:08.949 
+'
U cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c
U cddl/contrib/opensolaris/lib/libzfs/common/libzfs_sendrecv.c
U sys/compat/linux/linux_misc.c
U sys/arm/allwinner/a10_hdmi.c
U sys/cddl/compat/opensolaris/sys/vfs.h
U sys/cddl/contrib/opensolaris/uts/common/fs/gfs.c
U sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c
U sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c
At revision 297521

No emails were triggered.
[FreeBSD_HEAD_amd64_gcc] $ /bin/sh -xe /tmp/hudson8754098237068074298.sh
+ cat
+ svn revert Makefile.inc1
+ svn revert sys/boot/i386/Makefile
Reverted 'sys/boot/i386/Makefile'
+ patch -f
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--
|Index: sys/boot/i386/Makefile
|===
|--- sys/boot/i386/Makefile (revision 280912)
|+++ sys/boot/i386/Makefile (working copy)
--
Patching file sys/boot/i386/Makefile using Plan A...
Hunk #1 succeeded at 16 (offset 4 lines).
Hmm...  Ignoring the trailing garbage.
done
+ /vm/freebsd-ci/scripts/build/cross-build.sh
+ [ -z /builds/FreeBSD_HEAD_amd64_gcc ]
+ [ -z amd64 ]
+ export MAKEOBJDIRPREFIX=/builds/FreeBSD_HEAD_amd64_gcc/obj
+ mkdir -p /builds/FreeBSD_HEAD_amd64_gcc/obj
+ echo -e 'NO_WERROR=yes
WERROR=
WITH_FAST_DEPEND=yes'
+ cat
+ set +x
--
>>> /builds/FreeBSD_HEAD_amd64_gcc/make.conf contains:
+ cat /builds/FreeBSD_HEAD_amd64_gcc/make.conf
# Put make.conf entries here
NO_WERROR=yes
WERROR=
WITH_FAST_DEPEND=yes
+ set +x
--
+ sudo pkg install -y devel/amd64-xtoolchain-gcc
Updating FreeBSD repos