Re: Building multiple kernels with "make release"
It is on my list of things to look into next week.
Glen
Sent from my phone.
Please excuse my brevity and/or typos.
> On Aug 20, 2021, at 4:10 PM, Alan Somers wrote:
>
>
>> On Thu, Jul 29, 2021 at 12:43 PM Emmanuel Vadot
>> wrote:
>> On Thu, 29 Jul 2021 00:13:54 +
>> Glen Barber wrote:
>>
>> > On Wed, Jul 28, 2021 at 06:00:28PM -0600, Alan Somers wrote:
>> > > On Wed, Jul 28, 2021 at 5:52 PM Miroslav Lachman <000.f...@quip.cz>
>> > > wrote:
>> > >
>> > > > On 28/07/2021 20:46, Juraj Lutter wrote:
>> > > > >
>> > > > >
>> > > > >> On 28 Jul 2021, at 20:37, Glen Barber wrote:
>> > > > >>
>> > > > >> On Wed, Jul 28, 2021 at 12:05:25PM -0600, Alan Somers wrote:
>> > > > >>> On Wed, Jul 28, 2021 at 11:57 AM Glen Barber
>> > > > >>> wrote:
>> > > > Just on a hunch, could you try with adding
>> > > > INSTALLKERNEL="${KERNEL}"
>> > > > to
>> > > > your release.conf?
>> > > >
>> > > > I now seem to recall some weirdness with this, but the exact
>> > > > details
>> > > > elude me at the moment.
>> > > >
>> > > > >>>
>> > > > >>> Setting INSTALLKERNEL="GENERIC-NODEBUG" during "make
>> > > > >>> installkernel"
>> > > > >>> overrides whatever KERNCONF was set to. But it still only
>> > > > >>> installs one
>> > > > >>> kernel. Trying to set that variable to a list doesn't work.
>> > > > >>
>> > > > >> Ok. Give me a day or so to try to figure out what is (or isn't)
>> > > > >> happening here. I do not recall any recent-ish changes that would
>> > > > >> have
>> > > > >> caused this, and I am 95% certain it has worked in the past.
>> > > > >
>> > > > > According to Makefile.inc1:
>> > > > >
>> > > > > make installkernel KERNCONF=?KERN1 KERN2?
>> > > > >
>> > > > > should install KERN1 and KERN2. Similar goes for buildkernel.
>> > > > >
>> > > > > Or is there something I am missing?
>> > > >
>> > > > Does 'make installkernel KERNCONF=?KERN1 KERN2?' really install both
>> > > > kernels? Under which names?
>> > > > I have 3 kernels defined in KERNCONF in /etc/make.conf for years. 3
>> > > > kernels are built by "make buildkernel" but only one installed by "make
>> > > > installkernel".
>> > > >
>> > > > To install other kernels I use:
>> > > >
>> > > > make installkernel KERNCONF=KERN2 KODIR=/boot/kernel.KERN2
>> > > >
>> > > > make installkernel KERNCONF=KERN3 KODIR=/boot/kernel.KERN3
>> > > >
>> > >
>> > > Miroslav is right. Despite the comment that Juraj found, "make
>> > > installkernel" only installs the first kernel listed in KERNCONF.
>> >
>> > Good find. I honestly thought this worked as expected versus as
>> > written. In fact, I *thought* secondary, tertiary, etc. kernels were
>> > installed as /boot/kernel.KERN2, /boot/kernel.KERN3 (using the example
>> > above).
>>
>> You need to set NO_INSTALLEXTRAKERNELS=no for that to happens (yes the
>> variable name and double no sucks if anyone have a patch for that that
>> would be awesome).
>>
>> > Although, I may be misremembering, and 'kernel.KERN2.txz' may be created
>> > instead, although not installed/extracted. Though, we are going back at
>> > least seven years, and I do not even remember what I had eaten for
>> > dinner last night, so there's that...
>> >
>> > Glen
>> >
>>
>>
>> --
>> Emmanuel Vadot
>
> NO_INSTALLEXTRAKERNELS=no works for "make installkernel". However, it still
> doesn't work with release.sh. It seems there is work left to do.
> -Alan
Re: Building multiple kernels with "make release"
On Thu, Jul 29, 2021 at 12:43 PM Emmanuel Vadot
wrote:
> On Thu, 29 Jul 2021 00:13:54 +
> Glen Barber wrote:
>
> > On Wed, Jul 28, 2021 at 06:00:28PM -0600, Alan Somers wrote:
> > > On Wed, Jul 28, 2021 at 5:52 PM Miroslav Lachman <000.f...@quip.cz>
> wrote:
> > >
> > > > On 28/07/2021 20:46, Juraj Lutter wrote:
> > > > >
> > > > >
> > > > >> On 28 Jul 2021, at 20:37, Glen Barber wrote:
> > > > >>
> > > > >> On Wed, Jul 28, 2021 at 12:05:25PM -0600, Alan Somers wrote:
> > > > >>> On Wed, Jul 28, 2021 at 11:57 AM Glen Barber
> wrote:
> > > > Just on a hunch, could you try with adding
> INSTALLKERNEL="${KERNEL}"
> > > > to
> > > > your release.conf?
> > > >
> > > > I now seem to recall some weirdness with this, but the exact
> details
> > > > elude me at the moment.
> > > >
> > > > >>>
> > > > >>> Setting INSTALLKERNEL="GENERIC-NODEBUG" during "make
> installkernel"
> > > > >>> overrides whatever KERNCONF was set to. But it still only
> installs one
> > > > >>> kernel. Trying to set that variable to a list doesn't work.
> > > > >>
> > > > >> Ok. Give me a day or so to try to figure out what is (or isn't)
> > > > >> happening here. I do not recall any recent-ish changes that
> would have
> > > > >> caused this, and I am 95% certain it has worked in the past.
> > > > >
> > > > > According to Makefile.inc1:
> > > > >
> > > > > make installkernel KERNCONF=?KERN1 KERN2?
> > > > >
> > > > > should install KERN1 and KERN2. Similar goes for buildkernel.
> > > > >
> > > > > Or is there something I am missing?
> > > >
> > > > Does 'make installkernel KERNCONF=?KERN1 KERN2?' really install both
> > > > kernels? Under which names?
> > > > I have 3 kernels defined in KERNCONF in /etc/make.conf for years. 3
> > > > kernels are built by "make buildkernel" but only one installed by
> "make
> > > > installkernel".
> > > >
> > > > To install other kernels I use:
> > > >
> > > > make installkernel KERNCONF=KERN2 KODIR=/boot/kernel.KERN2
> > > >
> > > > make installkernel KERNCONF=KERN3 KODIR=/boot/kernel.KERN3
> > > >
> > >
> > > Miroslav is right. Despite the comment that Juraj found, "make
> > > installkernel" only installs the first kernel listed in KERNCONF.
> >
> > Good find. I honestly thought this worked as expected versus as
> > written. In fact, I *thought* secondary, tertiary, etc. kernels were
> > installed as /boot/kernel.KERN2, /boot/kernel.KERN3 (using the example
> > above).
>
> You need to set NO_INSTALLEXTRAKERNELS=no for that to happens (yes the
> variable name and double no sucks if anyone have a patch for that that
> would be awesome).
>
> > Although, I may be misremembering, and 'kernel.KERN2.txz' may be created
> > instead, although not installed/extracted. Though, we are going back at
> > least seven years, and I do not even remember what I had eaten for
> > dinner last night, so there's that...
> >
> > Glen
> >
>
>
> --
> Emmanuel Vadot
>
NO_INSTALLEXTRAKERNELS=no works for "make installkernel". However, it
still doesn't work with release.sh. It seems there is work left to do.
-Alan
Re: Building multiple kernels with "make release"
On Thu, 29 Jul 2021 00:13:54 +
Glen Barber wrote:
> On Wed, Jul 28, 2021 at 06:00:28PM -0600, Alan Somers wrote:
> > On Wed, Jul 28, 2021 at 5:52 PM Miroslav Lachman <000.f...@quip.cz> wrote:
> >
> > > On 28/07/2021 20:46, Juraj Lutter wrote:
> > > >
> > > >
> > > >> On 28 Jul 2021, at 20:37, Glen Barber wrote:
> > > >>
> > > >> On Wed, Jul 28, 2021 at 12:05:25PM -0600, Alan Somers wrote:
> > > >>> On Wed, Jul 28, 2021 at 11:57 AM Glen Barber wrote:
> > > Just on a hunch, could you try with adding INSTALLKERNEL="${KERNEL}"
> > > to
> > > your release.conf?
> > >
> > > I now seem to recall some weirdness with this, but the exact details
> > > elude me at the moment.
> > >
> > > >>>
> > > >>> Setting INSTALLKERNEL="GENERIC-NODEBUG" during "make installkernel"
> > > >>> overrides whatever KERNCONF was set to. But it still only installs
> > > >>> one
> > > >>> kernel. Trying to set that variable to a list doesn't work.
> > > >>
> > > >> Ok. Give me a day or so to try to figure out what is (or isn't)
> > > >> happening here. I do not recall any recent-ish changes that would have
> > > >> caused this, and I am 95% certain it has worked in the past.
> > > >
> > > > According to Makefile.inc1:
> > > >
> > > > make installkernel KERNCONF=?KERN1 KERN2?
> > > >
> > > > should install KERN1 and KERN2. Similar goes for buildkernel.
> > > >
> > > > Or is there something I am missing?
> > >
> > > Does 'make installkernel KERNCONF=?KERN1 KERN2?' really install both
> > > kernels? Under which names?
> > > I have 3 kernels defined in KERNCONF in /etc/make.conf for years. 3
> > > kernels are built by "make buildkernel" but only one installed by "make
> > > installkernel".
> > >
> > > To install other kernels I use:
> > >
> > > make installkernel KERNCONF=KERN2 KODIR=/boot/kernel.KERN2
> > >
> > > make installkernel KERNCONF=KERN3 KODIR=/boot/kernel.KERN3
> > >
> >
> > Miroslav is right. Despite the comment that Juraj found, "make
> > installkernel" only installs the first kernel listed in KERNCONF.
>
> Good find. I honestly thought this worked as expected versus as
> written. In fact, I *thought* secondary, tertiary, etc. kernels were
> installed as /boot/kernel.KERN2, /boot/kernel.KERN3 (using the example
> above).
You need to set NO_INSTALLEXTRAKERNELS=no for that to happens (yes the
variable name and double no sucks if anyone have a patch for that that
would be awesome).
> Although, I may be misremembering, and 'kernel.KERN2.txz' may be created
> instead, although not installed/extracted. Though, we are going back at
> least seven years, and I do not even remember what I had eaten for
> dinner last night, so there's that...
>
> Glen
>
--
Emmanuel Vadot
Re: Building multiple kernels with "make release"
On 2021-07-28 10:11, Alan Somers wrote: Is it possible to build multiple different kernels and include them all in a release image? release.conf says so. But from experiment, what I see is that: * release.sh does pass both kernels in the KERNCONF variable to "make buildkernel" * "make buildkernel" dutifully builds both * BUT, "make installkernel" only installs the first kernel and ignores the rest * Only the first kernel ends up in the final image * It's not really clear where an alternate kernel should go, anyway. FWIW For me, the way I've always accomplished this was via the DESTDIR keyword for kernels. Probably not the most elegant, or maybe even the "correct" way. But It's something figured out a good while ago and since it worked. I continue to use it. Maybe it'll work for you. HTH --Chris Probably someplace like /boot/kernel.debug , but release.conf doesn't provide a way to specify that. So is the "multiple kernels in release.conf" feature unfinished? If so, does anybody have a good idea about the best way to finish it? https://github.com/freebsd/freebsd-src/blob/7045b1603bdf054145dd958a4acc17b410fb62a0/release/release.conf.sample#L32 -Alan 0xBDE49540.asc Description: application/pgp-keys
Re: Building multiple kernels with "make release"
On Wed, Jul 28, 2021 at 06:00:28PM -0600, Alan Somers wrote:
> On Wed, Jul 28, 2021 at 5:52 PM Miroslav Lachman <000.f...@quip.cz> wrote:
>
> > On 28/07/2021 20:46, Juraj Lutter wrote:
> > >
> > >
> > >> On 28 Jul 2021, at 20:37, Glen Barber wrote:
> > >>
> > >> On Wed, Jul 28, 2021 at 12:05:25PM -0600, Alan Somers wrote:
> > >>> On Wed, Jul 28, 2021 at 11:57 AM Glen Barber wrote:
> > Just on a hunch, could you try with adding INSTALLKERNEL="${KERNEL}"
> > to
> > your release.conf?
> >
> > I now seem to recall some weirdness with this, but the exact details
> > elude me at the moment.
> >
> > >>>
> > >>> Setting INSTALLKERNEL="GENERIC-NODEBUG" during "make installkernel"
> > >>> overrides whatever KERNCONF was set to. But it still only installs one
> > >>> kernel. Trying to set that variable to a list doesn't work.
> > >>
> > >> Ok. Give me a day or so to try to figure out what is (or isn't)
> > >> happening here. I do not recall any recent-ish changes that would have
> > >> caused this, and I am 95% certain it has worked in the past.
> > >
> > > According to Makefile.inc1:
> > >
> > > make installkernel KERNCONF=“KERN1 KERN2”
> > >
> > > should install KERN1 and KERN2. Similar goes for buildkernel.
> > >
> > > Or is there something I am missing?
> >
> > Does 'make installkernel KERNCONF=“KERN1 KERN2”' really install both
> > kernels? Under which names?
> > I have 3 kernels defined in KERNCONF in /etc/make.conf for years. 3
> > kernels are built by "make buildkernel" but only one installed by "make
> > installkernel".
> >
> > To install other kernels I use:
> >
> > make installkernel KERNCONF=KERN2 KODIR=/boot/kernel.KERN2
> >
> > make installkernel KERNCONF=KERN3 KODIR=/boot/kernel.KERN3
> >
>
> Miroslav is right. Despite the comment that Juraj found, "make
> installkernel" only installs the first kernel listed in KERNCONF.
Good find. I honestly thought this worked as expected versus as
written. In fact, I *thought* secondary, tertiary, etc. kernels were
installed as /boot/kernel.KERN2, /boot/kernel.KERN3 (using the example
above).
Although, I may be misremembering, and 'kernel.KERN2.txz' may be created
instead, although not installed/extracted. Though, we are going back at
least seven years, and I do not even remember what I had eaten for
dinner last night, so there's that...
Glen
signature.asc
Description: PGP signature
Re: Building multiple kernels with "make release"
On Wed, Jul 28, 2021 at 5:52 PM Miroslav Lachman <000.f...@quip.cz> wrote:
> On 28/07/2021 20:46, Juraj Lutter wrote:
> >
> >
> >> On 28 Jul 2021, at 20:37, Glen Barber wrote:
> >>
> >> On Wed, Jul 28, 2021 at 12:05:25PM -0600, Alan Somers wrote:
> >>> On Wed, Jul 28, 2021 at 11:57 AM Glen Barber wrote:
> Just on a hunch, could you try with adding INSTALLKERNEL="${KERNEL}"
> to
> your release.conf?
>
> I now seem to recall some weirdness with this, but the exact details
> elude me at the moment.
>
> >>>
> >>> Setting INSTALLKERNEL="GENERIC-NODEBUG" during "make installkernel"
> >>> overrides whatever KERNCONF was set to. But it still only installs one
> >>> kernel. Trying to set that variable to a list doesn't work.
> >>
> >> Ok. Give me a day or so to try to figure out what is (or isn't)
> >> happening here. I do not recall any recent-ish changes that would have
> >> caused this, and I am 95% certain it has worked in the past.
> >
> > According to Makefile.inc1:
> >
> > make installkernel KERNCONF=“KERN1 KERN2”
> >
> > should install KERN1 and KERN2. Similar goes for buildkernel.
> >
> > Or is there something I am missing?
>
> Does 'make installkernel KERNCONF=“KERN1 KERN2”' really install both
> kernels? Under which names?
> I have 3 kernels defined in KERNCONF in /etc/make.conf for years. 3
> kernels are built by "make buildkernel" but only one installed by "make
> installkernel".
>
> To install other kernels I use:
>
> make installkernel KERNCONF=KERN2 KODIR=/boot/kernel.KERN2
>
> make installkernel KERNCONF=KERN3 KODIR=/boot/kernel.KERN3
>
> Miroslav Lachman
>
Miroslav is right. Despite the comment that Juraj found, "make
installkernel" only installs the first kernel listed in KERNCONF.
-Alan
Re: Building multiple kernels with "make release"
On 28/07/2021 20:46, Juraj Lutter wrote:
On 28 Jul 2021, at 20:37, Glen Barber wrote:
On Wed, Jul 28, 2021 at 12:05:25PM -0600, Alan Somers wrote:
On Wed, Jul 28, 2021 at 11:57 AM Glen Barber wrote:
Just on a hunch, could you try with adding INSTALLKERNEL="${KERNEL}" to
your release.conf?
I now seem to recall some weirdness with this, but the exact details
elude me at the moment.
Setting INSTALLKERNEL="GENERIC-NODEBUG" during "make installkernel"
overrides whatever KERNCONF was set to. But it still only installs one
kernel. Trying to set that variable to a list doesn't work.
Ok. Give me a day or so to try to figure out what is (or isn't)
happening here. I do not recall any recent-ish changes that would have
caused this, and I am 95% certain it has worked in the past.
According to Makefile.inc1:
make installkernel KERNCONF=“KERN1 KERN2”
should install KERN1 and KERN2. Similar goes for buildkernel.
Or is there something I am missing?
Does 'make installkernel KERNCONF=“KERN1 KERN2”' really install both
kernels? Under which names?
I have 3 kernels defined in KERNCONF in /etc/make.conf for years. 3
kernels are built by "make buildkernel" but only one installed by "make
installkernel".
To install other kernels I use:
make installkernel KERNCONF=KERN2 KODIR=/boot/kernel.KERN2
make installkernel KERNCONF=KERN3 KODIR=/boot/kernel.KERN3
Miroslav Lachman
Re: Building multiple kernels with "make release"
On Wed, Jul 28, 2021 at 08:46:19PM +0200, Juraj Lutter wrote:
>
>
> > On 28 Jul 2021, at 20:37, Glen Barber wrote:
> >
> > On Wed, Jul 28, 2021 at 12:05:25PM -0600, Alan Somers wrote:
> >> On Wed, Jul 28, 2021 at 11:57 AM Glen Barber wrote:
> >>> Just on a hunch, could you try with adding INSTALLKERNEL="${KERNEL}" to
> >>> your release.conf?
> >>>
> >>> I now seem to recall some weirdness with this, but the exact details
> >>> elude me at the moment.
> >>>
> >>
> >> Setting INSTALLKERNEL="GENERIC-NODEBUG" during "make installkernel"
> >> overrides whatever KERNCONF was set to. But it still only installs one
> >> kernel. Trying to set that variable to a list doesn't work.
> >
> > Ok. Give me a day or so to try to figure out what is (or isn't)
> > happening here. I do not recall any recent-ish changes that would have
> > caused this, and I am 95% certain it has worked in the past.
>
> According to Makefile.inc1:
>
> make installkernel KERNCONF=“KERN1 KERN2”
>
> should install KERN1 and KERN2. Similar goes for buildkernel.
>
> Or is there something I am missing?
>
Nope, I think you found what is missing. I'll test changes to
release.sh tomorrow after tonight's snapshot builds are done.
Thank you for the hint.
Glen
signature.asc
Description: PGP signature
Re: Building multiple kernels with "make release"
> On 28 Jul 2021, at 20:37, Glen Barber wrote:
>
> On Wed, Jul 28, 2021 at 12:05:25PM -0600, Alan Somers wrote:
>> On Wed, Jul 28, 2021 at 11:57 AM Glen Barber wrote:
>>> Just on a hunch, could you try with adding INSTALLKERNEL="${KERNEL}" to
>>> your release.conf?
>>>
>>> I now seem to recall some weirdness with this, but the exact details
>>> elude me at the moment.
>>>
>>
>> Setting INSTALLKERNEL="GENERIC-NODEBUG" during "make installkernel"
>> overrides whatever KERNCONF was set to. But it still only installs one
>> kernel. Trying to set that variable to a list doesn't work.
>
> Ok. Give me a day or so to try to figure out what is (or isn't)
> happening here. I do not recall any recent-ish changes that would have
> caused this, and I am 95% certain it has worked in the past.
According to Makefile.inc1:
make installkernel KERNCONF=“KERN1 KERN2”
should install KERN1 and KERN2. Similar goes for buildkernel.
Or is there something I am missing?
—
Juraj Lutter
o...@freebsd.org
signature.asc
Description: Message signed with OpenPGP
Re: Building multiple kernels with "make release"
On Wed, Jul 28, 2021 at 12:05:25PM -0600, Alan Somers wrote:
> On Wed, Jul 28, 2021 at 11:57 AM Glen Barber wrote:
> > Just on a hunch, could you try with adding INSTALLKERNEL="${KERNEL}" to
> > your release.conf?
> >
> > I now seem to recall some weirdness with this, but the exact details
> > elude me at the moment.
> >
>
> Setting INSTALLKERNEL="GENERIC-NODEBUG" during "make installkernel"
> overrides whatever KERNCONF was set to. But it still only installs one
> kernel. Trying to set that variable to a list doesn't work.
Ok. Give me a day or so to try to figure out what is (or isn't)
happening here. I do not recall any recent-ish changes that would have
caused this, and I am 95% certain it has worked in the past.
Glen
signature.asc
Description: PGP signature
Re: Building multiple kernels with "make release"
On Wed, Jul 28, 2021 at 11:57 AM Glen Barber wrote:
> On Wed, Jul 28, 2021 at 05:32:03PM +, Glen Barber wrote:
> > On Wed, Jul 28, 2021 at 11:30:44AM -0600, Alan Somers wrote:
> > > On Wed, Jul 28, 2021 at 11:28 AM Glen Barber wrote:
> > >
> > > > On Wed, Jul 28, 2021 at 05:26:50PM +, Glen Barber wrote:
> > > > > On Wed, Jul 28, 2021 at 11:11:48AM -0600, Alan Somers wrote:
> > > > > > Is it possible to build multiple different kernels and include
> them
> > > > all in
> > > > > > a release image? release.conf says so. But from experiment,
> what I
> > > > see is
> > > > > > that:
> > > > > >
> > > > > > * release.sh does pass both kernels in the KERNCONF variable to
> "make
> > > > > > buildkernel"
> > > > > > * "make buildkernel" dutifully builds both
> > > > > > * BUT, "make installkernel" only installs the first kernel and
> ignores
> > > > the
> > > > > > rest
> > > > > > * Only the first kernel ends up in the final image
> > > > > > * It's not really clear where an alternate kernel should go,
> anyway.
> > > > > > Probably someplace like /boot/kernel.debug , but release.conf
> doesn't
> > > > > > provide a way to specify that.
> > > > > >
> > > > > > So is the "multiple kernels in release.conf" feature
> unfinished? If
> > > > so,
> > > > > > does anybody have a good idea about the best way to finish it?
> > > > > >
> > > > > >
> > > >
> https://github.com/freebsd/freebsd-src/blob/7045b1603bdf054145dd958a4acc17b410fb62a0/release/release.conf.sample#L32
> > > > > >
> > > > >
> > > > > Last I was aware, based on a patch sent to me privately, I
> believe, it
> > > > > should work.
> > > > >
> > > > > Let me take a look.
> > > > >
> > > >
> > > > Oh, wait. Are you using 'make release' or release/release.sh?
> > > >
> > >
> > > I'm using release.sh. I thought that was just a wrapper for "make
> > > release".
> >
> > It is, I just want to make sure I'm looking in the right place(s).
> >
>
> Just on a hunch, could you try with adding INSTALLKERNEL="${KERNEL}" to
> your release.conf?
>
> I now seem to recall some weirdness with this, but the exact details
> elude me at the moment.
>
> Glen
>
Setting INSTALLKERNEL="GENERIC-NODEBUG" during "make installkernel"
overrides whatever KERNCONF was set to. But it still only installs one
kernel. Trying to set that variable to a list doesn't work.
-Alan
Re: Building multiple kernels with "make release"
On Wed, Jul 28, 2021 at 05:32:03PM +, Glen Barber wrote:
> On Wed, Jul 28, 2021 at 11:30:44AM -0600, Alan Somers wrote:
> > On Wed, Jul 28, 2021 at 11:28 AM Glen Barber wrote:
> >
> > > On Wed, Jul 28, 2021 at 05:26:50PM +, Glen Barber wrote:
> > > > On Wed, Jul 28, 2021 at 11:11:48AM -0600, Alan Somers wrote:
> > > > > Is it possible to build multiple different kernels and include them
> > > all in
> > > > > a release image? release.conf says so. But from experiment, what I
> > > see is
> > > > > that:
> > > > >
> > > > > * release.sh does pass both kernels in the KERNCONF variable to "make
> > > > > buildkernel"
> > > > > * "make buildkernel" dutifully builds both
> > > > > * BUT, "make installkernel" only installs the first kernel and ignores
> > > the
> > > > > rest
> > > > > * Only the first kernel ends up in the final image
> > > > > * It's not really clear where an alternate kernel should go, anyway.
> > > > > Probably someplace like /boot/kernel.debug , but release.conf doesn't
> > > > > provide a way to specify that.
> > > > >
> > > > > So is the "multiple kernels in release.conf" feature unfinished? If
> > > so,
> > > > > does anybody have a good idea about the best way to finish it?
> > > > >
> > > > >
> > > https://github.com/freebsd/freebsd-src/blob/7045b1603bdf054145dd958a4acc17b410fb62a0/release/release.conf.sample#L32
> > > > >
> > > >
> > > > Last I was aware, based on a patch sent to me privately, I believe, it
> > > > should work.
> > > >
> > > > Let me take a look.
> > > >
> > >
> > > Oh, wait. Are you using 'make release' or release/release.sh?
> > >
> >
> > I'm using release.sh. I thought that was just a wrapper for "make
> > release".
>
> It is, I just want to make sure I'm looking in the right place(s).
>
Just on a hunch, could you try with adding INSTALLKERNEL="${KERNEL}" to
your release.conf?
I now seem to recall some weirdness with this, but the exact details
elude me at the moment.
Glen
signature.asc
Description: PGP signature
Re: Building multiple kernels with "make release"
On Wed, Jul 28, 2021 at 11:30:44AM -0600, Alan Somers wrote: > On Wed, Jul 28, 2021 at 11:28 AM Glen Barber wrote: > > > On Wed, Jul 28, 2021 at 05:26:50PM +, Glen Barber wrote: > > > On Wed, Jul 28, 2021 at 11:11:48AM -0600, Alan Somers wrote: > > > > Is it possible to build multiple different kernels and include them > > all in > > > > a release image? release.conf says so. But from experiment, what I > > see is > > > > that: > > > > > > > > * release.sh does pass both kernels in the KERNCONF variable to "make > > > > buildkernel" > > > > * "make buildkernel" dutifully builds both > > > > * BUT, "make installkernel" only installs the first kernel and ignores > > the > > > > rest > > > > * Only the first kernel ends up in the final image > > > > * It's not really clear where an alternate kernel should go, anyway. > > > > Probably someplace like /boot/kernel.debug , but release.conf doesn't > > > > provide a way to specify that. > > > > > > > > So is the "multiple kernels in release.conf" feature unfinished? If > > so, > > > > does anybody have a good idea about the best way to finish it? > > > > > > > > > > https://github.com/freebsd/freebsd-src/blob/7045b1603bdf054145dd958a4acc17b410fb62a0/release/release.conf.sample#L32 > > > > > > > > > > Last I was aware, based on a patch sent to me privately, I believe, it > > > should work. > > > > > > Let me take a look. > > > > > > > Oh, wait. Are you using 'make release' or release/release.sh? > > > > I'm using release.sh. I thought that was just a wrapper for "make > release". It is, I just want to make sure I'm looking in the right place(s). Glen signature.asc Description: PGP signature
Re: Building multiple kernels with "make release"
On Wed, Jul 28, 2021 at 11:28 AM Glen Barber wrote: > On Wed, Jul 28, 2021 at 05:26:50PM +, Glen Barber wrote: > > On Wed, Jul 28, 2021 at 11:11:48AM -0600, Alan Somers wrote: > > > Is it possible to build multiple different kernels and include them > all in > > > a release image? release.conf says so. But from experiment, what I > see is > > > that: > > > > > > * release.sh does pass both kernels in the KERNCONF variable to "make > > > buildkernel" > > > * "make buildkernel" dutifully builds both > > > * BUT, "make installkernel" only installs the first kernel and ignores > the > > > rest > > > * Only the first kernel ends up in the final image > > > * It's not really clear where an alternate kernel should go, anyway. > > > Probably someplace like /boot/kernel.debug , but release.conf doesn't > > > provide a way to specify that. > > > > > > So is the "multiple kernels in release.conf" feature unfinished? If > so, > > > does anybody have a good idea about the best way to finish it? > > > > > > > https://github.com/freebsd/freebsd-src/blob/7045b1603bdf054145dd958a4acc17b410fb62a0/release/release.conf.sample#L32 > > > > > > > Last I was aware, based on a patch sent to me privately, I believe, it > > should work. > > > > Let me take a look. > > > > Oh, wait. Are you using 'make release' or release/release.sh? > > Glen > I'm using release.sh. I thought that was just a wrapper for "make release".
Re: Building multiple kernels with "make release"
On Wed, Jul 28, 2021 at 05:26:50PM +, Glen Barber wrote: > On Wed, Jul 28, 2021 at 11:11:48AM -0600, Alan Somers wrote: > > Is it possible to build multiple different kernels and include them all in > > a release image? release.conf says so. But from experiment, what I see is > > that: > > > > * release.sh does pass both kernels in the KERNCONF variable to "make > > buildkernel" > > * "make buildkernel" dutifully builds both > > * BUT, "make installkernel" only installs the first kernel and ignores the > > rest > > * Only the first kernel ends up in the final image > > * It's not really clear where an alternate kernel should go, anyway. > > Probably someplace like /boot/kernel.debug , but release.conf doesn't > > provide a way to specify that. > > > > So is the "multiple kernels in release.conf" feature unfinished? If so, > > does anybody have a good idea about the best way to finish it? > > > > https://github.com/freebsd/freebsd-src/blob/7045b1603bdf054145dd958a4acc17b410fb62a0/release/release.conf.sample#L32 > > > > Last I was aware, based on a patch sent to me privately, I believe, it > should work. > > Let me take a look. > Oh, wait. Are you using 'make release' or release/release.sh? Glen signature.asc Description: PGP signature
Re: Building multiple kernels with "make release"
On Wed, Jul 28, 2021 at 11:11:48AM -0600, Alan Somers wrote: > Is it possible to build multiple different kernels and include them all in > a release image? release.conf says so. But from experiment, what I see is > that: > > * release.sh does pass both kernels in the KERNCONF variable to "make > buildkernel" > * "make buildkernel" dutifully builds both > * BUT, "make installkernel" only installs the first kernel and ignores the > rest > * Only the first kernel ends up in the final image > * It's not really clear where an alternate kernel should go, anyway. > Probably someplace like /boot/kernel.debug , but release.conf doesn't > provide a way to specify that. > > So is the "multiple kernels in release.conf" feature unfinished? If so, > does anybody have a good idea about the best way to finish it? > > https://github.com/freebsd/freebsd-src/blob/7045b1603bdf054145dd958a4acc17b410fb62a0/release/release.conf.sample#L32 > Last I was aware, based on a patch sent to me privately, I believe, it should work. Let me take a look. Glen signature.asc Description: PGP signature
Building multiple kernels with "make release"
Is it possible to build multiple different kernels and include them all in a release image? release.conf says so. But from experiment, what I see is that: * release.sh does pass both kernels in the KERNCONF variable to "make buildkernel" * "make buildkernel" dutifully builds both * BUT, "make installkernel" only installs the first kernel and ignores the rest * Only the first kernel ends up in the final image * It's not really clear where an alternate kernel should go, anyway. Probably someplace like /boot/kernel.debug , but release.conf doesn't provide a way to specify that. So is the "multiple kernels in release.conf" feature unfinished? If so, does anybody have a good idea about the best way to finish it? https://github.com/freebsd/freebsd-src/blob/7045b1603bdf054145dd958a4acc17b410fb62a0/release/release.conf.sample#L32 -Alan
make release broken?
Any ideas what broke this?
--
>>> Kernel build for GENERIC completed on Tue Feb 9 20:48:05 UTC 2021
--
>>> Kernel(s) GENERIC built in 465 seconds, ncpu: 8, make -j8
--
make -C /usr/src/release obj
make -C /usr/src/release ftp cdrom dvdrom memstick.img mini-memstick.img
`ftp' is up to date.
sh /usr/src/release/i386/mkisoimages.sh -b 14_0_CURRENT_i386_CD
disc1.iso disc1
makefs: cd9660_add_boot_disk: lstat("disc1/boot/cdboot"): No such file
or directory
*** Error code 1
Stop.
make[1]: stopped in /usr/src/release
*** Error code 1
imb
___
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: trying to make release with git-derived 14-current
On 30/01/2021 17:23, tech-lists wrote: Hi, I'm trying to make release with -current on a rpi4b/8GB. Basically, I have a working rpi4B/8GB with a no-debug kernel running -current. However, release(7) says a lot about svn and nothing about git. What's the method with git? thanks, Correct me please, if I'm wrong, from <https://cgit.freebsd.org/src/commit/release/release.sh?id=041b28524a3c69ff6e893067df156c3faabcac9a> I assume that there's still work in progress. ___ 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"
trying to make release with git-derived 14-current
Hi, I'm trying to make release with -current on a rpi4b/8GB. Basically, I have a working rpi4B/8GB with a no-debug kernel running -current. However, release(7) says a lot about svn and nothing about git. What's the method with git? thanks, -- J. signature.asc Description: PGP signature
make release with i386 target now fails
I'm sure I did this yesterday without a failure; any hints as to what broke/how to fix it? imb ===> tests/sys/cddl/zfs/tests/threadsappend (all) ===> tests/sys/cddl/zfs/tests/truncate (all) ===> usr.sbin/amd/libamu (all) ===> usr.sbin/audit (all) ===> tests/sys/cddl/zfs/tests/txg_integrity (all) ===> tests/sys/cddl/zfs/tests/userquota (all) --- xdr_func_%undef.c --- *** [xdr_func_%undef.c] Error code 1 make[5]: *** xdr_func_%undef.c removed make[5]: stopped in /usr/local/release-builds/i386/usr/src/usr.sbin/amd/libamu .ERROR_TARGET='xdr_func_%undef.c' .ERROR_META_FILE='/usr/local/release-builds/i386/tmp/obj/usr/local/release-builds/i386/usr/src/amd64.amd64/usr.sbin/amd/libamu/xdr_func_%undef.c.meta' .MAKE.LEVEL='5' MAKEFILE='' .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes' _ERROR_CMD='unifdef -x1 -DHAVE_XDR_ATTRSTAT -DHAVE_XDR_CREATEARGS -DHAVE_XDR_DIRLIST -DHAVE_XDR_DIROPARGS -DHAVE_XDR_DIROPOKRES -DHAVE_XDR_DIROPRES -DHAVE_XDR_DIRPATH -DHAVE_XDR_ENTRY -DHAVE_XDR_EXPORTNODE -DHAVE_XDR_EXPORTS -DHAVE_XDR_FATTR -DHAVE_XDR_FHANDLE -DHAVE_XDR_FHSTATUS -DHAVE_XDR_FILENAME -DHAVE_XDR_FTYPE -DHAVE_XDR_GROUPNODE -DHAVE_XDR_GROUPS -DHAVE_XDR_LINKARGS -DHAVE_XDR_MOUNTBODY -DHAVE_XDR_MOUNTLIST -DHAVE_XDR_NAME -DHAVE_XDR_NFS_FH -DHAVE_XDR_NFSCOOKIE -DHAVE_XDR_NFSPATH -DHAVE_XDR_NFSSTAT -DHAVE_XDR_NFSTIME -DHAVE_XDR_POINTER -DHAVE_XDR_READARGS -DHAVE_XDR_READDIRARGS -DHAVE_XDR_READDIRRES -DHAVE_XDR_READLINKRES -DHAVE_XDR_READOKRES -DHAVE_XDR_READRES -DHAVE_XDR_RENAMEARGS -DHAVE_XDR_SATTR -DHAVE_XDR_SATTRARGS -DHAVE_XDR_STATFSOKRES -DHAVE_XDR_STATFSRES -DHAVE_XDR_SYMLINKARGS -DHAVE_XDR_WRITEARGS -DHAVE_XDR_U_INT64_T -o xdr_func_%undef.c /usr/local/release-builds/i386/usr/src/contrib/amd/libamu/xdr_func.c;' ___ 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: make release: how utilise filemon?
On 5/10/17 1:12 AM, O. Hartmann wrote: > hello, > > building a release of most recent 12-CURRENT seems to be at some point very > annoying. When building the main host's system out of /usr/src > using /etc/src-env.conf set with WITH_META_MODE=yes, build time decreases > significantly. Now I perform some tasks building release. The source tree is > 11-STABLE. > > In release.conf, I tried setting > > ## Set to use world- and kernel-specific make(1) flags. > WORLD_FLAGS="-DNO_CLEAN -j $(sysctl -n hw.ncpu)" > KERNEL_FLAGS="-DNO_CLEAN -j $(( $(( $(sysctl -n hw.ncpu) + 1 )) / 2 ))" > > without any noticable effect - make release always build release fully, no > matter wether there has been new sources checked out or not. It takes a lot of > time compiling llvm/clang. Using 11-stable on a NanoBSD installation, > -DNO_CLEAN seems to take effect on the very same source revision, while it > doesn't on "make release". The target (obj-directory) is always properly set, > the same and not deleted by a run of "make release", so I'm quite sure this > portion of the setting is correct. > > release(7) does have some tags setting src.conf, but I miss src-env.conf > settings as this can be customised in the "ordinary" /usr/src world. > > What am I doing or thinking wrong in this matter? > > Kind regards, > > Oliver > ___ META_MODE is only allowed in a whitelist of targets (see META_TGT_WHITELIST in Makefile). I wanted to avoid META MODE ever being enabled for an 'install' target or utility target like 'check-old' or 'delete-old', etc. META MODE has the potential to skip doing things that are actually needed, like copying a file to /. So I decided to whitelist to known-safe targets. The 'make release' target, and all of release/, is something I've never ran and am not very familiar with, so I didn't list it. Thus WITH_META_MODE=yes and 'make release' has no effect, it will build without META MODE. In summary, support needs to be added for release/ in safe and useful ways. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
make release: how utilise filemon?
hello, building a release of most recent 12-CURRENT seems to be at some point very annoying. When building the main host's system out of /usr/src using /etc/src-env.conf set with WITH_META_MODE=yes, build time decreases significantly. Now I perform some tasks building release. The source tree is 11-STABLE. In release.conf, I tried setting ## Set to use world- and kernel-specific make(1) flags. WORLD_FLAGS="-DNO_CLEAN -j $(sysctl -n hw.ncpu)" KERNEL_FLAGS="-DNO_CLEAN -j $(( $(( $(sysctl -n hw.ncpu) + 1 )) / 2 ))" without any noticable effect - make release always build release fully, no matter wether there has been new sources checked out or not. It takes a lot of time compiling llvm/clang. Using 11-stable on a NanoBSD installation, -DNO_CLEAN seems to take effect on the very same source revision, while it doesn't on "make release". The target (obj-directory) is always properly set, the same and not deleted by a run of "make release", so I'm quite sure this portion of the setting is correct. release(7) does have some tags setting src.conf, but I miss src-env.conf settings as this can be customised in the "ordinary" /usr/src world. What am I doing or thinking wrong in this matter? Kind regards, Oliver ___ 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"
make release vs jenkins
We use jenkins to build, test and release 11.0-CURRENT using jenkin's uid:gid. Everything works well up to "install -o root -g wheel" in "make release". Anyone know what the use case is for requiring release to be built as root? Roger ___ 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: make release fails...
On Fri, Sep 13, 2013 at 11:21:43AM +0900, Lundberg, Johannes wrote: Trying to create a custom install image which has been successful before but suddenly fails during make release/memstick. Procedure 1) cd /usr/src 2) make buildworld 3) make buildkernel 4) cd release 5) make release and I get the error ... gencat be_BY.UTF-8.cat /usr/src/lib/libc/nls/be_BY.UTF-8.msg make[8]: exec(gencat) failed (no such file or directory) This is not enough context. Also, what is output of 'sysctl -n kern.osreldate' on the build host, and which branch and revision are you trying to build? Glen pgpWdgLPdVDMT.pgp Description: PGP signature
make release fails...
Hi Trying to create a custom install image which has been successful before but suddenly fails during make release/memstick. Procedure 1) cd /usr/src 2) make buildworld 3) make buildkernel 4) cd release 5) make release and I get the error ... gencat be_BY.UTF-8.cat /usr/src/lib/libc/nls/be_BY.UTF-8.msg make[8]: exec(gencat) failed (no such file or directory) -- Johannes Lundberg Project leader and lead developer of Mirama OS (previously Viking OS) BRILLIANTSERVICE CO., LTD. My blog http://brilliantobjc.blogspot.com Mirama homepage http://www.brilliantservice.co.jp/viking/ bloghttp://hmdviking.blogspot.jp Company homepage http://www.brilliantservice.co.jp ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: make release fails...
# sysctl -n kern.osreldate 145 The system is 10.0. I used it before to build custom distribution. What I've done since last time is basically removing /usr/src and grabbing a new one from head. -- Johannes Lundberg Project leader and lead developer of Mirama OS (previously Viking OS) BRILLIANTSERVICE CO., LTD. My blog http://brilliantobjc.blogspot.com Mirama homepage http://www.brilliantservice.co.jp/viking/ bloghttp://hmdviking.blogspot.jp Company homepage http://www.brilliantservice.co.jp On Fri, Sep 13, 2013 at 11:27 AM, Glen Barber g...@freebsd.org wrote: On Fri, Sep 13, 2013 at 11:21:43AM +0900, Lundberg, Johannes wrote: Trying to create a custom install image which has been successful before but suddenly fails during make release/memstick. Procedure 1) cd /usr/src 2) make buildworld 3) make buildkernel 4) cd release 5) make release and I get the error ... gencat be_BY.UTF-8.cat /usr/src/lib/libc/nls/be_BY.UTF-8.msg make[8]: exec(gencat) failed (no such file or directory) This is not enough context. Also, what is output of 'sysctl -n kern.osreldate' on the build host, and which branch and revision are you trying to build? Glen ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: make release fails...
On Fri, Sep 13, 2013 at 11:30:44AM +0900, Lundberg, Johannes wrote: # sysctl -n kern.osreldate 145 The system is 10.0. I used it before to build custom distribution. What I've done since last time is basically removing /usr/src and grabbing a new one from head. Recent changes in head/ (unfortunately) require the build system revision to be at least 155 or greater, due to some backward compatibility issues introduced recently. If you upgrade the build environment and retry the build, you should be fine. (And yes, I am serious, as I've just spent several hours on exactly these types of issues...) Glen pgpMRrq2veMKk.pgp Description: PGP signature
Re: make release fails...
Is this perhaps related to the 20130905 post in UPDATING, regarding the Capsicum framework? -- Johannes Lundberg Project leader and lead developer of Mirama OS (previously Viking OS) BRILLIANTSERVICE CO., LTD. My blog http://brilliantobjc.blogspot.com Mirama homepage http://www.brilliantservice.co.jp/viking/ bloghttp://hmdviking.blogspot.jp Company homepage http://www.brilliantservice.co.jp On Fri, Sep 13, 2013 at 11:37 AM, Lundberg, Johannes johan...@brilliantservice.co.jp wrote: Oh.. Thanks a lot! But please tell me, how can I upgrade the build environment? Do I have to rebuild world and kernel on the host system? -- Johannes Lundberg Project leader and lead developer of Mirama OS (previously Viking OS) BRILLIANTSERVICE CO., LTD. My blog http://brilliantobjc.blogspot.com Mirama homepage http://www.brilliantservice.co.jp/viking/ bloghttp://hmdviking.blogspot.jp Company homepage http://www.brilliantservice.co.jp On Fri, Sep 13, 2013 at 11:35 AM, Glen Barber g...@freebsd.org wrote: On Fri, Sep 13, 2013 at 11:30:44AM +0900, Lundberg, Johannes wrote: # sysctl -n kern.osreldate 145 The system is 10.0. I used it before to build custom distribution. What I've done since last time is basically removing /usr/src and grabbing a new one from head. Recent changes in head/ (unfortunately) require the build system revision to be at least 155 or greater, due to some backward compatibility issues introduced recently. If you upgrade the build environment and retry the build, you should be fine. (And yes, I am serious, as I've just spent several hours on exactly these types of issues...) Glen ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: make release fails...
Oh.. Thanks a lot! But please tell me, how can I upgrade the build environment? Do I have to rebuild world and kernel on the host system? -- Johannes Lundberg Project leader and lead developer of Mirama OS (previously Viking OS) BRILLIANTSERVICE CO., LTD. My blog http://brilliantobjc.blogspot.com Mirama homepage http://www.brilliantservice.co.jp/viking/ bloghttp://hmdviking.blogspot.jp Company homepage http://www.brilliantservice.co.jp On Fri, Sep 13, 2013 at 11:35 AM, Glen Barber g...@freebsd.org wrote: On Fri, Sep 13, 2013 at 11:30:44AM +0900, Lundberg, Johannes wrote: # sysctl -n kern.osreldate 145 The system is 10.0. I used it before to build custom distribution. What I've done since last time is basically removing /usr/src and grabbing a new one from head. Recent changes in head/ (unfortunately) require the build system revision to be at least 155 or greater, due to some backward compatibility issues introduced recently. If you upgrade the build environment and retry the build, you should be fine. (And yes, I am serious, as I've just spent several hours on exactly these types of issues...) Glen ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: make release fails...
Yes, the buildworld/buildkernel. Glen On Fri, Sep 13, 2013 at 11:37:38AM +0900, Lundberg, Johannes wrote: Oh.. Thanks a lot! But please tell me, how can I upgrade the build environment? Do I have to rebuild world and kernel on the host system? -- Johannes Lundberg Project leader and lead developer of Mirama OS (previously Viking OS) BRILLIANTSERVICE CO., LTD. My blog http://brilliantobjc.blogspot.com Mirama homepage http://www.brilliantservice.co.jp/viking/ bloghttp://hmdviking.blogspot.jp Company homepage http://www.brilliantservice.co.jp On Fri, Sep 13, 2013 at 11:35 AM, Glen Barber g...@freebsd.org wrote: On Fri, Sep 13, 2013 at 11:30:44AM +0900, Lundberg, Johannes wrote: # sysctl -n kern.osreldate 145 The system is 10.0. I used it before to build custom distribution. What I've done since last time is basically removing /usr/src and grabbing a new one from head. Recent changes in head/ (unfortunately) require the build system revision to be at least 155 or greater, due to some backward compatibility issues introduced recently. If you upgrade the build environment and retry the build, you should be fine. (And yes, I am serious, as I've just spent several hours on exactly these types of issues...) Glen pgpivCirxcKq9.pgp Description: PGP signature
Re: make release fails...
In part, yes. Glen On Fri, Sep 13, 2013 at 11:41:54AM +0900, Lundberg, Johannes wrote: Is this perhaps related to the 20130905 post in UPDATING, regarding the Capsicum framework? -- Johannes Lundberg Project leader and lead developer of Mirama OS (previously Viking OS) BRILLIANTSERVICE CO., LTD. My blog http://brilliantobjc.blogspot.com Mirama homepage http://www.brilliantservice.co.jp/viking/ bloghttp://hmdviking.blogspot.jp Company homepage http://www.brilliantservice.co.jp On Fri, Sep 13, 2013 at 11:37 AM, Lundberg, Johannes johan...@brilliantservice.co.jp wrote: Oh.. Thanks a lot! But please tell me, how can I upgrade the build environment? Do I have to rebuild world and kernel on the host system? -- Johannes Lundberg Project leader and lead developer of Mirama OS (previously Viking OS) BRILLIANTSERVICE CO., LTD. My blog http://brilliantobjc.blogspot.com Mirama homepage http://www.brilliantservice.co.jp/viking/ bloghttp://hmdviking.blogspot.jp Company homepage http://www.brilliantservice.co.jp On Fri, Sep 13, 2013 at 11:35 AM, Glen Barber g...@freebsd.org wrote: On Fri, Sep 13, 2013 at 11:30:44AM +0900, Lundberg, Johannes wrote: # sysctl -n kern.osreldate 145 The system is 10.0. I used it before to build custom distribution. What I've done since last time is basically removing /usr/src and grabbing a new one from head. Recent changes in head/ (unfortunately) require the build system revision to be at least 155 or greater, due to some backward compatibility issues introduced recently. If you upgrade the build environment and retry the build, you should be fine. (And yes, I am serious, as I've just spent several hours on exactly these types of issues...) Glen pgppIC6i58N_J.pgp Description: PGP signature
Re: make release recursion
Alexander Pyhalov a...@rsu.ru wrote: Hello. On 07/28/2012 00:09, Glen Barber wrote: Hello, On Fri, Jul 27, 2012 at 09:35:13AM +0400, Alexander Pyhalov wrote: Hello. I've tried to do make cdrom on recent 10-current (svn revision 238763) and got after day of work: [...] Could you please retry the cdrom build with NOSRC=yes set? I've tried make NOSRC=yes cdrom and the command completed in about an hour without recursion. -- Best regards, Alexander Pyhalov, system administrator of Computer Center of Southern Federal University Thank you for reporting back on this. I believe I know where the recursion is happening, and will look into it further for a fix. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: make release recursion
Hi, On Fri, Jul 27, 2012 at 09:35:13AM +0400, Alexander Pyhalov wrote: Hello. I've tried to do make cdrom on recent 10-current (svn revision 238763) and got after day of work: [...] It seems, it continued to add files to some archive recursively... Is it a bug or maybe I just can't cook it properly? just to note: I just ran into the same thing with 9-STABLE - Oliver -- | Oliver Brandmueller http://sysadm.in/ o...@sysadm.in | |Ich bin das Internet. Sowahr ich Gott helfe. | ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: make release recursion
On Fri, Jul 27, 2012 at 7:26 AM, Oliver Brandmueller o...@e-gitt.net wrote: Hi, On Fri, Jul 27, 2012 at 09:35:13AM +0400, Alexander Pyhalov wrote: Hello. I've tried to do make cdrom on recent 10-current (svn revision 238763) and got after day of work: [...] It seems, it continued to add files to some archive recursively... Is it a bug or maybe I just can't cook it properly? just to note: I just ran into the same thing with 9-STABLE This is a known change after 9.0-RELEASE, but out of curiosity, how are you invoking make? I know how things in general need to be fixed but I need to figure out which variable you're passing in incorrectly. Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: make release recursion
On Fri, Jul 27, 2012 at 8:37 AM, Garrett Cooper yaneg...@gmail.com wrote: On Fri, Jul 27, 2012 at 7:26 AM, Oliver Brandmueller o...@e-gitt.net wrote: Hi, On Fri, Jul 27, 2012 at 09:35:13AM +0400, Alexander Pyhalov wrote: Hello. I've tried to do make cdrom on recent 10-current (svn revision 238763) and got after day of work: [...] It seems, it continued to add files to some archive recursively... Is it a bug or maybe I just can't cook it properly? just to note: I just ran into the same thing with 9-STABLE This is a known change after 9.0-RELEASE, but out of curiosity, how are you invoking make? I know how things in general need to be fixed but I need to figure out which variable you're passing in incorrectly. Another good reference to note: http://lists.freebsd.org/pipermail/freebsd-current/2011-June/025326.html . You're not the first people to stumble on this, so I'm filing a PR to help fix it. Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: make release recursion
Hello, On Fri, Jul 27, 2012 at 09:35:13AM +0400, Alexander Pyhalov wrote: Hello. I've tried to do make cdrom on recent 10-current (svn revision 238763) and got after day of work: [...] Could you please retry the cdrom build with NOSRC=yes set? If this does not succeed, could you please provide specific details on how your build environment is set up? While I do recall encountering this in 9-STABLE prior to 9.0-RELEASE, I do not see this happen on 10-CURRENT r237614, and my buildworld/buildkernel on an up-to-date checkout of head is still in progress. Regards, Glen ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
make release recursion
Hello. I've tried to do make cdrom on recent 10-current (svn revision 238763) and got after day of work: a usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/base/usr/lib/pam_echo.so a usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/base/usr/lib/libwind_p.a a usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/base/usr/lib/librpcsec_gss.so.1 a usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/base/usr/lib/libzfs_p.a ... Here I hitted ^C and received: *** src.txz removed It seems, it continued to add files to some archive recursively... Is it a bug or maybe I just can't cook it properly? -- Best regards, Alexander Pyhalov, system administrator of Computer Center of Southern Federal University ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
CURRENT as of 5/8/2012 make release
Ive noticed trying a make release on CURRENT that it appears to be looping deeper and deeper, does this appear normal to anyone else??? a usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/sys/dev/malo/if_malohal.h a usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/sys/dev/malo/if_malo.h a usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/sys/dev/twa/tw_osl_freebsd.c a usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/sys/dev/twa/tw_cl_misc.c a usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/sys/dev/twa/tw_osl_externs.h a usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/sys/dev/twa/tw_cl_io.c ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: make release: doesn't work for me, getting
Attempting to run: make release resulted in 'looping' until a kernel compile directory sys/amd64/compile/* was removed. Maybe I missed something in the docs. -kim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: make release: doesn't work for me, getting
On Fri, Jun 24, 2011 at 8:47 AM, Kim Culhan w8hd...@gmail.com wrote: Attempting to run: make release resulted in 'looping' until a kernel compile directory sys/amd64/compile/* was removed. Maybe I missed something in the docs. -kim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org http://lists.freebsd.org/pipermail/freebsd-current/2011-June/025326.html ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
make release: doesn't work for me, getting recursive looping
Try to build a cdrom from most recent CURRENT/amd64 sources. Issuing the follwing command fails the build process looping recursively and indefinitely within the source folder /usr/src/release: make release cdrom CHROOTDIR=/unused/release/9.0/ SVNROOT/usr/src BUILDNAME=9.0-CURRENT RELEASETAG=RELENG_9 NOPORTS=YES NODOC=YES The chrooted folder is empty and as the doc says, it should be the location where the release should be build. Since I do not use CVS anymore, but SVN, I use SVNROOT instead of CVSROOT to point to the location of the sources. What's wrong in the picture? Am I misunderstanding something or is the build proxess broken? Thanks. Oliver ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: make release: doesn't work for me, getting recursive looping
On 06/18/11 05:15, Hartmann, O. wrote: Try to build a cdrom from most recent CURRENT/amd64 sources. Issuing the follwing command fails the build process looping recursively and indefinitely within the source folder /usr/src/release: make release cdrom CHROOTDIR=/unused/release/9.0/ SVNROOT/usr/src BUILDNAME=9.0-CURRENT RELEASETAG=RELENG_9 NOPORTS=YES NODOC=YES The chrooted folder is empty and as the doc says, it should be the location where the release should be build. Since I do not use CVS anymore, but SVN, I use SVNROOT instead of CVSROOT to point to the location of the sources. This is not how release building works anymore. See release(7). If you want to do something analagous to the old-style make release, with SVN checkouts and a chroot, which you seem to wan to do, you need to use generate-release.sh. You can also use make release to build a system out of the current source directory by simply doing make release NOPORTS=yes NODOC=yes. The reason it is hanging is that one of the sub-targets invoked by make cdrom requires that make obj be run first. make release protects against this, but manually invoking sub-targets does not. -Nathan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: make release: doesn't work for me, getting recursive looping
On 06/18/11 17:35, Nathan Whitehorn wrote: On 06/18/11 05:15, Hartmann, O. wrote: Try to build a cdrom from most recent CURRENT/amd64 sources. Issuing the follwing command fails the build process looping recursively and indefinitely within the source folder /usr/src/release: make release cdrom CHROOTDIR=/unused/release/9.0/ SVNROOT/usr/src BUILDNAME=9.0-CURRENT RELEASETAG=RELENG_9 NOPORTS=YES NODOC=YES The chrooted folder is empty and as the doc says, it should be the location where the release should be build. Since I do not use CVS anymore, but SVN, I use SVNROOT instead of CVSROOT to point to the location of the sources. This is not how release building works anymore. See release(7). If you want to do something analagous to the old-style make release, with SVN checkouts and a chroot, which you seem to wan to do, you need to use generate-release.sh. You can also use make release to build a system out of the current source directory by simply doing make release NOPORTS=yes NODOC=yes. The reason it is hanging is that one of the sub-targets invoked by make cdrom requires that make obj be run first. make release protects against this, but manually invoking sub-targets does not. -Nathan Thanks a lot. I'm new to this and I remember the old style, but the new one seems to be more sophisticated and 'clean'. Oliver ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
make release
I am trying to make a release with the following arguments: make release CHROOTDIR=/usr/home/current BUILDNAME=9-CURRENT EXTSRCDIR=/usr/src NOPORTS=YES MAKE_ISOS=YES however /usr/home/current is being ignored completely and everything ends up in /usr/obj/usr/src. Am I doing something wrong ? Thanks -- George Kontostanos aisecure.net http://www.aisecure.net ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: make release
On 12/04/2011, at 17:02, George Kontostanos wrote: I am trying to make a release with the following arguments: make release CHROOTDIR=/usr/home/current BUILDNAME=9-CURRENT EXTSRCDIR=/usr/src NOPORTS=YES MAKE_ISOS=YES however /usr/home/current is being ignored completely and everything ends up in /usr/obj/usr/src. Am I doing something wrong ? I found this too, I think it's the new way. (I think the makefile still mentions CHROOTDIR though.. not sure if it does anything with it or not though) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: make release
On 04/12/11 10:02, George Kontostanos wrote: I am trying to make a release with the following arguments: make release CHROOTDIR=/usr/home/current BUILDNAME=9-CURRENT EXTSRCDIR=/usr/src NOPORTS=YES MAKE_ISOS=YES however /usr/home/current is being ignored completely and everything ends up in /usr/obj/usr/src. Am I doing something wrong ? Following switching the default installer away from sysinstall, make release works differently now (see release(7), which has been updated to reflect the new release-building process). The closest analog to the command above (though you may want to do something different) is: cd /usr/src/release ./generate-release.sh head /usr/home/current -Nathan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: make release
Sorry I didn't read the man pages lately!
releaseMeta-target to build all release media and distributions
applicable to this platform. All output goes to
${.OBJDIR}, which will likely be either src/release or
the
equivalent path in /usr/obj.
The following sequence of commands can be used to build a ``-CURRENT
snapshot'' in a clean environment, including ports and documentation:
cd /usr/src
make buildworld
cd release
export CVSUP_HOST=cvsupN.freebsd.org
sh generate-release.sh head /local3/release
On Tue, Apr 12, 2011 at 6:14 PM, Nathan Whitehorn nwhiteh...@freebsd.orgwrote:
On 04/12/11 10:02, George Kontostanos wrote:
I am trying to make a release with the following arguments:
make release CHROOTDIR=/usr/home/current BUILDNAME=9-CURRENT
EXTSRCDIR=/usr/src NOPORTS=YES MAKE_ISOS=YES
however /usr/home/current is being ignored completely and everything ends
up
in /usr/obj/usr/src. Am I doing something wrong ?
Following switching the default installer away from sysinstall, make
release works differently now (see release(7), which has been updated to
reflect the new release-building process). The closest analog to the command
above (though you may want to do something different) is:
cd /usr/src/release
./generate-release.sh head /usr/home/current
-Nathan
--
George Kontostanos
aisecure.net http://www.aisecure.net
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: make release problems (amd64)
On 26/03/2011, at 18:42, O. Hartmann wrote: Yes, I tried and I ran into the same problems. But I didn't run into problems lately, the problem resists for me now for approx. three weeks or so and I reported this in questions@ once. Try 'make obj' before 'make release' - that fixed it for me. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: make release problems (amd64)
On 26.03.2011 05:32, Daniel O'Connor wrote:
Has anyone done one recently?
I note there aren't any snapshots for this month, so perhaps I'm not alone.
I tried this :-
RELNAME=9.0
BUILDNAME=${RELNAME}-GENESIS
make release CHROOTDIR=/tmp/${RELNAME}-release BUILDNAME=$BUILDNAME
HTTP_PROXY=http://proxy:3128 FTP_PROXY=http://proxy:3128 EXTSRCDIR=/usr/src
EXTPORTSDIR=/usr/ports EXTDOCDIR=/usr/doc NOPORTS=YES MAKE_ISOS=YES
However it appears to have started recursively taring up /usr/src/release/dist
:-/
[snip]
a ./boot/kernel/linker.hints
mv /usr/src/release/dist/kernel.txz /usr/src/release
mkdir -p /usr/src/release/dist/usr
ln -fs /usr/src/release/.. /usr/src/release/dist/usr/src
cd /usr/src/release/dist tar cLvJf /usr/src/release/src.txz --exclude .svn
--exclude CVS usr/
src
a usr/src
a usr/src/usr.bin
a usr/src/release
...
a
usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/lib32.txz
a
usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/kernel.txz
then I killed it.
I'm not sure why it's putting stuff in /usr/src/release rather than
/tmp/9.0-GENESIS or /usr/obj somewhere..
--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
The nice thing about standards is that there
are so many of them to choose from.
-- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
Hello.
Yes, I tried and I ran into the same problems. But I didn't run into
problems lately, the problem resists for me now for approx. three weeks
or so and I reported this in questions@ once.
Oliver
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: make release problems (amd64)
On 03/26/11 03:44, Daniel O'Connor wrote: On 26/03/2011, at 18:42, O. Hartmann wrote: Yes, I tried and I ran into the same problems. But I didn't run into problems lately, the problem resists for me now for approx. three weeks or so and I reported this in questions@ once. Try 'make obj' before 'make release' - that fixed it for me. Thanks for reporting this! I just modified src/release/Makefile so that 'make release' causes the obj target to be run first, so this shouldn't happen anymore. -Nathan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
make release problems (amd64)
Has anyone done one recently?
I note there aren't any snapshots for this month, so perhaps I'm not alone.
I tried this :-
RELNAME=9.0
BUILDNAME=${RELNAME}-GENESIS
make release CHROOTDIR=/tmp/${RELNAME}-release BUILDNAME=$BUILDNAME
HTTP_PROXY=http://proxy:3128 FTP_PROXY=http://proxy:3128 EXTSRCDIR=/usr/src
EXTPORTSDIR=/usr/ports EXTDOCDIR=/usr/doc NOPORTS=YES MAKE_ISOS=YES
However it appears to have started recursively taring up /usr/src/release/dist
:-/
[snip]
a ./boot/kernel/linker.hints
mv /usr/src/release/dist/kernel.txz /usr/src/release
mkdir -p /usr/src/release/dist/usr
ln -fs /usr/src/release/.. /usr/src/release/dist/usr/src
cd /usr/src/release/dist tar cLvJf /usr/src/release/src.txz --exclude .svn
--exclude CVS usr/
src
a usr/src
a usr/src/usr.bin
a usr/src/release
...
a
usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/lib32.txz
a
usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/kernel.txz
then I killed it.
I'm not sure why it's putting stuff in /usr/src/release rather than
/tmp/9.0-GENESIS or /usr/obj somewhere..
--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
The nice thing about standards is that there
are so many of them to choose from.
-- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: make release problems (amd64)
On 26/03/2011, at 15:02, Daniel O'Connor wrote: usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/dist/usr/src/release/kernel.txz then I killed it. I'm not sure why it's putting stuff in /usr/src/release rather than /tmp/9.0-GENESIS or /usr/obj somewhere.. I did a bit more looking around and found that I needed a 'make obj' first, all good now :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ports/150265: [patch] print/ghostscript8 disable bogus port conflicts in make release
On Sun, Sep 5, 2010 at 10:15, v...@freebsd.org wrote: Rob, IMO the question is not if the problem _can_ be solved in the base build system. I doubt you'll find many src committers willing to break other peoples machines by using DISABLE_CONFLICTS as a general problem solver. It may well work for your machine and you're free to do that. The maintainer of ghostscript8 may check the issue but is free to close the PR as WONTFIX (I suspect that will most likely happen). Instead of filing a PR for such problems, a discussion on our fine mailing lists might be good. Thanks! [adding a mailing list per your suggestion] I think you are misunderstanding the issue here. This is not a ghostscript issue and the maintainer of ghostscript isn't the right person to look at it. The same issue can appear with other ports used by make release, such as perl. In fact, there isn't any way for this to be solved in the ports tree short of removing the CONFLICTS handling (which is not what I am suggesting). What happens is the release building process uses certain ports to generate the HTML documentation (release notes, etc.) on the CDs. To insure a clean build environment, these ports are built and installed in a chroot away from the main system. However, prior to entering the chroot, the distfiles for these ports are fetched and checksummed with make checksum-recursive. This process occurs outside the chroot, so the ports system looks for conflicts with what is installed in /usr/local, assuming that these distfiles are for ports to be installed in /usr/local. This assumption is flawed, since they will not be installed there and thus will not conflict. My patch runs the make checksum-recursive target with -DDISABLE_CONFLICTS to avoid these false positives. This will not break other people's machines as you state because the absolute worst case scenario with my patch is having a couple duplicate distfiles (such as perl5.10 and perl5.12). Nothing is built or installed with the DISABLE_CONFLICTS flag. What I'm asking you to do is revert the description, category, and assignment of the PR so that someone who is familiar with the release building process will see it. -- Rob Farmer ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: make release broken
On 5/22/2010 8:25 PM, Rob Farmer wrote: make release is still broken on amd64 as of svn 208373 (2010-05-21 04:52:49 -0500) That patch seems unrelated? What needs done is /src/release/$ARCH/boot_crunch.conf files need the relevant libraries added to the libs section. I haven't tested it, but I think adding -llzma there will fix the problems. That works for me, except that I had to add -lcrypto too? I don't know if that's a good idea. Index: release/amd64/boot_crunch.conf === --- release/amd64/boot_crunch.conf (revision 208373) +++ release/amd64/boot_crunch.conf (working copy) @@ -41,4 +41,4 @@ libs -ll -ledit -lutil -lmd -lcrypt -lftpio -lz -lnetgraph libs -ldialog -lncurses -ldisk -lcam -lsbuf -lufs -ldevinfo -libs -lbsdxml -larchive -lbz2 -lusb -ljail +libs -lbsdxml -larchive -lbz2 -lusb -ljail -llzma -lcrypto ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: make release broken
On Sun, May 23, 2010 at 11:02 PM, James R. Van Artsdalen james-freebsd-curr...@jrv.org wrote: On 5/22/2010 8:25 PM, Rob Farmer wrote: make release is still broken on amd64 as of svn 208373 (2010-05-21 04:52:49 -0500) That patch seems unrelated? What needs done is /src/release/$ARCH/boot_crunch.conf files need the relevant libraries added to the libs section. I haven't tested it, but I think adding -llzma there will fix the problems. That works for me, except that I had to add -lcrypto too? I don't know if that's a good idea. Yeah, I found that out too when I tested it. I've submitted a PR with patches for all the archs: http://www.freebsd.org/cgi/query-pr.cgi?pr=misc/146904 -- Rob Farmer Index: release/amd64/boot_crunch.conf === --- release/amd64/boot_crunch.conf (revision 208373) +++ release/amd64/boot_crunch.conf (working copy) @@ -41,4 +41,4 @@ libs -ll -ledit -lutil -lmd -lcrypt -lftpio -lz -lnetgraph libs -ldialog -lncurses -ldisk -lcam -lsbuf -lufs -ldevinfo -libs -lbsdxml -larchive -lbz2 -lusb -ljail +libs -lbsdxml -larchive -lbz2 -lusb -ljail -llzma -lcrypto ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: make release broken
On 5/18/2010 2:34 AM, jhell wrote: On Mon, May 17, 2010 at 10:35 PM, Rob Farmer rfar...@predatorlabs.net wrote: make release is broken on current. Seems to be related to the lzma import. This is on i386: cc -static -o boot_crunch boot_crunch.o hostname.lo pwd.lo rm.lo sh.lo test.lo camcontrol.lo dhclient.lo fsck_ffs.lo ifconfig.lo mount_nfs.lo newfs.lo route.lo rtsol.lo tunefs.lo cpio.lo find.lo minigzip.lo sed.lo arp.lo ppp.lo sysinstall.lo usbconfig.lo -ll -ledit -lutil -lmd -lcrypt -lftpio -lz -lnetgraph -ldialog -lncurses -ldisk -lcam -lsbuf -lufs -ldevinfo -lbsdxml -larchive -lbz2 -lusb -ljail /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_compression_xz.o)(.text+0x1e6): In function `archive_compressor_xz_init': : undefined reference to `lzma_lzma_preset' ... This URL looks to be the problem you are seeing above. http://docs.freebsd.org/cgi/getmsg.cgi?fetch=20426+0+current/freebsd-current make release is still broken on amd64 as of svn 208373 (2010-05-21 04:52:49 -0500) That patch seems unrelated? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: make release broken
On Sat, May 22, 2010 at 8:09 AM, James R. Van Artsdalen james-freebsd-curr...@jrv.org wrote: On 5/18/2010 2:34 AM, jhell wrote: On Mon, May 17, 2010 at 10:35 PM, Rob Farmer rfar...@predatorlabs.net wrote: make release is broken on current. Seems to be related to the lzma import. This is on i386: cc -static -o boot_crunch boot_crunch.o hostname.lo pwd.lo rm.lo sh.lo test.lo camcontrol.lo dhclient.lo fsck_ffs.lo ifconfig.lo mount_nfs.lo newfs.lo route.lo rtsol.lo tunefs.lo cpio.lo find.lo minigzip.lo sed.lo arp.lo ppp.lo sysinstall.lo usbconfig.lo -ll -ledit -lutil -lmd -lcrypt -lftpio -lz -lnetgraph -ldialog -lncurses -ldisk -lcam -lsbuf -lufs -ldevinfo -lbsdxml -larchive -lbz2 -lusb -ljail /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_compression_xz.o)(.text+0x1e6): In function `archive_compressor_xz_init': : undefined reference to `lzma_lzma_preset' ... This URL looks to be the problem you are seeing above. http://docs.freebsd.org/cgi/getmsg.cgi?fetch=20426+0+current/freebsd-current make release is still broken on amd64 as of svn 208373 (2010-05-21 04:52:49 -0500) That patch seems unrelated? That patch is unrelated - it is for building current on RELENG_7 or something like that. What needs done is /src/release/$ARCH/boot_crunch.conf files need the relevant libraries added to the libs section. I haven't tested it, but I think adding -llzma there will fix the problems. -- Rob Farmer ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: make release broken
On 5/18/2010 1:39 AM, Garrett Cooper wrote: On Mon, May 17, 2010 at 10:35 PM, Rob Farmer rfar...@predatorlabs.net wrote: Hi, make release is broken on current. Seems to be related to the lzma import. This is on i386: cc -static -o boot_crunch boot_crunch.o hostname.lo pwd.lo rm.lo sh.lo test.lo camcontrol.lo dhclient.lo fsck_ffs.lo ifconfig.lo mount_nfs.lo newfs.lo route.lo rtsol.lo tunefs.lo cpio.lo find.lo minigzip.lo sed.lo arp.lo ppp.lo sysinstall.lo usbconfig.lo -ll -ledit -lutil -lmd -lcrypt -lftpio -lz -lnetgraph -ldialog -lncurses -ldisk -lcam -lsbuf -lufs -ldevinfo -lbsdxml -larchive -lbz2 -lusb -ljail /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_compression_xz.o)(.text+0x1e6): In function `archive_compressor_xz_init': : undefined reference to `lzma_lzma_preset' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_compression_xz.o)(.text+0x263): In function `archive_compressor_xz_init': : undefined reference to `lzma_alone_encoder' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_compression_xz.o)(.text+0x2c9): In function `archive_compressor_xz_init': : undefined reference to `lzma_stream_encoder' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_compression_xz.o)(.text+0x3ba): In function `drive_compressor': : undefined reference to `lzma_code' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_compression_xz.o)(.text+0x418): In function `drive_compressor': : undefined reference to `lzma_memusage' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_compression_xz.o)(.text+0x640): In function `archive_compressor_xz_finish': : undefined reference to `lzma_end' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x9e8): In function `archive_write_mtree_finish_entry': : undefined reference to `SHA1_Final' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0xa2e): In function `archive_write_mtree_finish_entry': : undefined reference to `RIPEMD160_Final' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0xa78): In function `archive_write_mtree_finish_entry': : undefined reference to `MD5_Final' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0xe43): In function `archive_write_mtree_data': : undefined reference to `SHA1_Update' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0xe63): In function `archive_write_mtree_data': : undefined reference to `MD5_Update' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0xe8b): In function `archive_write_mtree_data': : undefined reference to `RIPEMD160_Update' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x1297): In function `archive_write_mtree_header': : undefined reference to `SHA1_Init' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x12c7): In function `archive_write_mtree_header': : undefined reference to `RIPEMD160_Init' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x12f4): In function `archive_write_mtree_header': : undefined reference to `MD5_Init' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_read_support_compression_xz.o)(.text+0x152): In function `xz_lzma_bidder_init': : undefined reference to `lzma_alone_decoder' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_read_support_compression_xz.o)(.text+0x18c): In function `xz_lzma_bidder_init': : undefined reference to `lzma_stream_decoder' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_read_support_compression_xz.o)(.text+0x2b1): In function `xz_filter_close': : undefined reference to `lzma_end' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_read_support_compression_xz.o)(.text+0x567): In function `xz_filter_read': : undefined reference to `lzma_code' *** Error code 1 Stop in /usr/obj/usr/src/release/boot_crunch. *** Error code 1 Stop in /usr/src/release. + umount /dev *** Error code 1 Stop in /usr/src/release. libopenssl and libmd bits are missing too. Thanks, -Garrett This URL looks to be the problem you are seeing above. http://docs.freebsd.org/cgi/getmsg.cgi?fetch=20426+0+current/freebsd-current -- jhell ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: make release broken
Rob Farmer wrote: Hi, make release is broken on current. Seems to be related to the lzma import. This is on i386: .. : undefined reference to `lzma_end' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_read_support_compression_xz.o)(.text+0x567): In function `xz_filter_read': : undefined reference to `lzma_code' *** Error code 1 Stop in /usr/obj/usr/src/release/boot_crunch. *** Error code 1 I saw the same on my amd64 8.0-RELEASE, inside a chroot, building another 8.0-RELEASE. The end of my log below (all I kept, sorry, I'll give it another run now, at the time I assumed it was something wrong in my box). ext+0x392): In function `drive_compressor': : undefined reference to `lzma_code' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_compression_xz.o)(.text+0x3eb): In function `drive_compressor': : undefined reference to `lzma_memusage' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_compression_xz.o)(.text+0x5cf): In function `archive_compressor_xz_finish': : undefined reference to `lzma_end' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x96a): In function `archive_write_mtree_finish_entry': : undefined reference to `RIPEMD160_Final' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x9b0): In function `archive_write_mtree_finish_entry': : undefined reference to `SHA1_Final' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x9eb): In function `archive_write_mtree_finish_entry': : undefined reference to `MD5_Final' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0xd36): In function `archive_write_mtree_data': : undefined reference to `SHA1_Update' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0xd50): In function `archive_write_mtree_data': : undefined reference to `MD5_Update' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0xd70): In function `archive_write_mtree_data': : undefined reference to `RIPEMD160_Update' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x1204): In function `archive_write_mtree_header': : undefined reference to `SHA1_Init' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x1238): In function `archive_write_mtree_header': : undefined reference to `RIPEMD160_Init' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x1268): In function `archive_write_mtree_header': : undefined reference to `MD5_Init' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_read_support_compression_xz.o)(.text+0x178): In function `xz_lzma_bidder_init': : undefined reference to `lzma_alone_decoder' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_read_support_compression_xz.o)(.text+0x1a5): In function `xz_lzma_bidder_init': : undefined reference to `lzma_stream_decoder' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_read_support_compression_xz.o)(.text+0x2a9): In function `xz_filter_close': : undefined reference to `lzma_end' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_read_support_compression_xz.o)(.text+0x560): In function `xz_filter_read': : undefined reference to `lzma_code' *** Error code 1 Stop in /usr/obj/usr/src/release/boot_crunch. *** Error code 1 Stop in /usr/src/release. + umount /dev *** Error code 1 Cheers, Julian -- Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text, Not HTML quoted-printable Base64 http://www.asciiribbon.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
make release broken
Hi, make release is broken on current. Seems to be related to the lzma import. This is on i386: cc -static -o boot_crunch boot_crunch.o hostname.lo pwd.lo rm.lo sh.lo test.lo camcontrol.lo dhclient.lo fsck_ffs.lo ifconfig.lo mount_nfs.lo newfs.lo route.lo rtsol.lo tunefs.lo cpio.lo find.lo minigzip.lo sed.lo arp.lo ppp.lo sysinstall.lo usbconfig.lo -ll -ledit -lutil -lmd -lcrypt -lftpio -lz -lnetgraph -ldialog -lncurses -ldisk -lcam -lsbuf -lufs -ldevinfo -lbsdxml -larchive -lbz2 -lusb -ljail /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_compression_xz.o)(.text+0x1e6): In function `archive_compressor_xz_init': : undefined reference to `lzma_lzma_preset' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_compression_xz.o)(.text+0x263): In function `archive_compressor_xz_init': : undefined reference to `lzma_alone_encoder' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_compression_xz.o)(.text+0x2c9): In function `archive_compressor_xz_init': : undefined reference to `lzma_stream_encoder' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_compression_xz.o)(.text+0x3ba): In function `drive_compressor': : undefined reference to `lzma_code' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_compression_xz.o)(.text+0x418): In function `drive_compressor': : undefined reference to `lzma_memusage' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_compression_xz.o)(.text+0x640): In function `archive_compressor_xz_finish': : undefined reference to `lzma_end' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x9e8): In function `archive_write_mtree_finish_entry': : undefined reference to `SHA1_Final' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0xa2e): In function `archive_write_mtree_finish_entry': : undefined reference to `RIPEMD160_Final' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0xa78): In function `archive_write_mtree_finish_entry': : undefined reference to `MD5_Final' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0xe43): In function `archive_write_mtree_data': : undefined reference to `SHA1_Update' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0xe63): In function `archive_write_mtree_data': : undefined reference to `MD5_Update' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0xe8b): In function `archive_write_mtree_data': : undefined reference to `RIPEMD160_Update' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x1297): In function `archive_write_mtree_header': : undefined reference to `SHA1_Init' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x12c7): In function `archive_write_mtree_header': : undefined reference to `RIPEMD160_Init' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x12f4): In function `archive_write_mtree_header': : undefined reference to `MD5_Init' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_read_support_compression_xz.o)(.text+0x152): In function `xz_lzma_bidder_init': : undefined reference to `lzma_alone_decoder' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_read_support_compression_xz.o)(.text+0x18c): In function `xz_lzma_bidder_init': : undefined reference to `lzma_stream_decoder' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_read_support_compression_xz.o)(.text+0x2b1): In function `xz_filter_close': : undefined reference to `lzma_end' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_read_support_compression_xz.o)(.text+0x567): In function `xz_filter_read': : undefined reference to `lzma_code' *** Error code 1 Stop in /usr/obj/usr/src/release/boot_crunch. *** Error code 1 Stop in /usr/src/release. + umount /dev *** Error code 1 Stop in /usr/src/release. -- Rob Farmer ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: make release broken
On Mon, May 17, 2010 at 10:35 PM, Rob Farmer rfar...@predatorlabs.net wrote: Hi, make release is broken on current. Seems to be related to the lzma import. This is on i386: cc -static -o boot_crunch boot_crunch.o hostname.lo pwd.lo rm.lo sh.lo test.lo camcontrol.lo dhclient.lo fsck_ffs.lo ifconfig.lo mount_nfs.lo newfs.lo route.lo rtsol.lo tunefs.lo cpio.lo find.lo minigzip.lo sed.lo arp.lo ppp.lo sysinstall.lo usbconfig.lo -ll -ledit -lutil -lmd -lcrypt -lftpio -lz -lnetgraph -ldialog -lncurses -ldisk -lcam -lsbuf -lufs -ldevinfo -lbsdxml -larchive -lbz2 -lusb -ljail /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_compression_xz.o)(.text+0x1e6): In function `archive_compressor_xz_init': : undefined reference to `lzma_lzma_preset' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_compression_xz.o)(.text+0x263): In function `archive_compressor_xz_init': : undefined reference to `lzma_alone_encoder' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_compression_xz.o)(.text+0x2c9): In function `archive_compressor_xz_init': : undefined reference to `lzma_stream_encoder' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_compression_xz.o)(.text+0x3ba): In function `drive_compressor': : undefined reference to `lzma_code' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_compression_xz.o)(.text+0x418): In function `drive_compressor': : undefined reference to `lzma_memusage' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_compression_xz.o)(.text+0x640): In function `archive_compressor_xz_finish': : undefined reference to `lzma_end' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x9e8): In function `archive_write_mtree_finish_entry': : undefined reference to `SHA1_Final' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0xa2e): In function `archive_write_mtree_finish_entry': : undefined reference to `RIPEMD160_Final' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0xa78): In function `archive_write_mtree_finish_entry': : undefined reference to `MD5_Final' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0xe43): In function `archive_write_mtree_data': : undefined reference to `SHA1_Update' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0xe63): In function `archive_write_mtree_data': : undefined reference to `MD5_Update' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0xe8b): In function `archive_write_mtree_data': : undefined reference to `RIPEMD160_Update' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x1297): In function `archive_write_mtree_header': : undefined reference to `SHA1_Init' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x12c7): In function `archive_write_mtree_header': : undefined reference to `RIPEMD160_Init' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x12f4): In function `archive_write_mtree_header': : undefined reference to `MD5_Init' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_read_support_compression_xz.o)(.text+0x152): In function `xz_lzma_bidder_init': : undefined reference to `lzma_alone_decoder' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_read_support_compression_xz.o)(.text+0x18c): In function `xz_lzma_bidder_init': : undefined reference to `lzma_stream_decoder' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_read_support_compression_xz.o)(.text+0x2b1): In function `xz_filter_close': : undefined reference to `lzma_end' /usr/obj/usr/src/tmp/usr/lib/libarchive.a(archive_read_support_compression_xz.o)(.text+0x567): In function `xz_filter_read': : undefined reference to `lzma_code' *** Error code 1 Stop in /usr/obj/usr/src/release/boot_crunch. *** Error code 1 Stop in /usr/src/release. + umount /dev *** Error code 1 Stop in /usr/src/release. libopenssl and libmd bits are missing too. Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: make release...
thanks alot for your reply... but, after patched my FreeBSD with your patch, i still get errors root pwd /home/fajri/data/usr/src/release root patch genesis-patch-ae root make release CHROOTDIR=/home/fajri/data/root BUILDNAME=FAJRI CVSROOT=/home/fajri/data/usr RELEASETAG=RELENG_4_8_RELEASE cd /home/fajri/data/root/usr rm -rf src cvs -R -d /home/fajri/data/usr co -P -r RELENG_4_8_RELEASE src cvs [checkout aborted]: no such tag RELENG_4_8_RELEASE *** Error code 1 Stop in /home/fajri/data/usr/src/release. root make release CHROOTDIR=/home/fajri/data/root BUILDNAME=FAJRI CVSROOT=/home/fajri/data/usr RELEASETAG=RELENG_4_8 cd /home/fajri/data/root/usr rm -rf src cvs -R -d /home/fajri/data/usr co -P -r RELENG_4_8 src cvs [checkout aborted]: no such tag RELENG_4_8 *** Error code 1 Stop in /home/fajri/data/usr/src/release. ..::f::.. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make release...
On Wednesday 22 October 2003 22:15, Anthony Fajri wrote: thanks alot for your reply... but, after patched my FreeBSD with your patch, i still get errors Err the patch isn't designed to fix your problem, it is just written by me to make things a bit easier. I suggest re-reading my email. root pwd /home/fajri/data/usr/src/release root patch genesis-patch-ae root make release CHROOTDIR=/home/fajri/data/root BUILDNAME=FAJRI CVSROOT=/home/fajri/data/usr RELEASETAG=RELENG_4_8_RELEASE cd /home/fajri/data/root/usr rm -rf src cvs -R -d /home/fajri/data/usr co -P -r RELENG_4_8_RELEASE src cvs [checkout aborted]: no such tag RELENG_4_8_RELEASE *** Error code 1 Stop in /home/fajri/data/usr/src/release. root make release CHROOTDIR=/home/fajri/data/root BUILDNAME=FAJRI CVSROOT=/home/fajri/data/usr RELEASETAG=RELENG_4_8 cd /home/fajri/data/root/usr rm -rf src cvs -R -d /home/fajri/data/usr co -P -r RELENG_4_8 src cvs [checkout aborted]: no such tag RELENG_4_8 *** Error code 1 Stop in /home/fajri/data/usr/src/release. ..::f::.. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
make release...
fajri more stable-supfile|grep release *default release=cvs tag=RELENG_4 == # make release CHROOTDIR=/home/fajri/data/root BUILDNAME=FAJRI CVSROOT=/home/fajri/data/usr RELEASETAG=RELENG_4 if [ -f /etc/resolv.conf ]; then cp -p /etc/resolv.conf /home/fajri/data/root/etc; fi cd /home/fajri/data/root/usr rm -rf src cvs -R -d /home/fajri/data/usr co -P -r RELENG_4 src cvs [checkout aborted]: no such tag RELENG_4 *** Error code 1 Stop in /home/fajri/data/usr/src/release. === FreeBSD xxx.xxx.xxx 4.8-STABLE FreeBSD 4.8-STABLE #0: Sat Oct 11 09:05:56 GMT 2003 [EMAIL PROTECTED]:/usr/src/sys/compile/xxx i386 # make release CHROOTDIR=/home/fajri/data/root BUILDNAME=FAJRI \ CVSROOT=/home/fajri/data/usr RELEASETAG=RELENG_4_8 \ BUILDNAME=RELENG_4_8_STABLE_FAJRI cd /home/fajri/data/root/usr rm -rf src cvs -R -d /home/fajri/data/usr co -P -r RELENG_4_8 src cvs [checkout aborted]: no such tag RELENG_4_8 *** Error code 1 === # make release CHROOTDIR=/home/fajri/data/root BUILDNAME=FAJRI \ CVSROOT=/home/fajri/data/usr cd /home/fajri/data/root/usr rm -rf ports cvs -R -d /home/fajri/data/usr co -P ports cvs checkout: cannot find module `ports' - ignored *** Error code 1 Stop in /home/fajri/data/usr/src/release. # make release CHROOTDIR=/home/fajri/data/root BUILDNAME=FAJRI CVSROOT=/home/fajri/data/usr RELEASETAG=RELENG_4_8_RELEASE cd /home/fajri/data/root/usr rm -rf src cvs -R -d /home/fajri/data/usr co -P -r RELENG_4_8_RELEASE src cvs [checkout aborted]: no such tag RELENG_4_8_RELEASE *** Error code 1 ..::f::.. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make release...
On Tuesday 21 October 2003 16:31, Anthony Fajri wrote:
fajri more stable-supfile|grep release
*default release=cvs tag=RELENG_4
You aren't syncing the repo with cvsup so the check out in make release
doesn't work.
Either apply the patch I attached and add CPNOTCVS= to your make release
options, or check out the repository.
PS the lack of commentry in your email isn't very polite IMO.
--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
The nice thing about standards is that there
are so many of them to choose from.
-- Andrew Tanenbaum
GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5
Index: release/Makefile
===
RCS file: /usr/local/ncvs/src/release/Makefile,v
retrieving revision 1.536.2.110
diff -u -r1.536.2.110 Makefile
--- release/Makefile 10 May 2003 23:01:29 - 1.536.2.110
+++ release/Makefile 9 Oct 2003 04:49:50 -
@@ -281,6 +281,10 @@
if [ -f /etc/resolv.conf ]; then \
cp -p /etc/resolv.conf ${CHROOTDIR}/etc; \
fi
+.if defined(CPNOTCVS)
+ cd ${CHROOTDIR}/usr rm -rf src \
+ mkdir src cp -pRP ${CVSROOT}/src/* src/
+.else
.if !defined(RELEASETAG)
cd ${CHROOTDIR}/usr rm -rf src \
cvs -R -d ${CVSROOT} co ${CVSCMDARGS} -P ${RELEASESRCMODULE}
@@ -288,6 +292,8 @@
cd ${CHROOTDIR}/usr rm -rf src \
cvs -R -d ${CVSROOT} co ${CVSCMDARGS} -P -r ${RELEASETAG} ${RELEASESRCMODULE}
.endif
+.endif
+.endif
.if defined(LOCAL_PATCHES) exists(${LOCAL_PATCHES})
cd ${CHROOTDIR}/usr/src patch ${PATCH_FLAGS} ${LOCAL_PATCHES}
.endif
@@ -295,11 +301,16 @@
cd ${CHROOTDIR} env CHROOTDIR=${CHROOTDIR} BUILDNAME=${BUILDNAME} RELEASETAG=${RELEASETAG} ${LOCAL_SCRIPT}
.endif
.if !defined(NOPORTS)
+.if defined(CPNOTCVS)
+ cd ${CHROOTDIR}/usr rm -rf ports \
+ mkdir ports cp -pRP ${CVSROOT}/ports/* ports/
+.else
.if defined(PORTSRELEASETAG)
cd ${CHROOTDIR}/usr rm -rf ports cvs -R -d ${CVSROOT} co ${CVSCMDARGS} -P -r ${PORTSRELEASETAG} ${RELEASEPORTSMODULE}
.else
cd ${CHROOTDIR}/usr rm -rf ports cvs -R -d ${CVSROOT} co ${CVSCMDARGS} -P ${RELEASEPORTSMODULE}
.endif
+.endif
.elif defined(DOMINIMALDOCPORTS) ${DOMINIMALDOCPORTS} == YES
.if defined(PORTSRELEASETAG)
cd ${CHROOTDIR}/usr rm -rf ports cvs -R -d ${CVSROOT} co ${CVSCMDARGS} -P -r ${PORTSRELEASETAG} ${MINIMALDOCPORTS}
@@ -308,11 +319,15 @@
.endif
.endif
.if !defined(NODOC)
+.if defined(CPNOTCVS)
+ cd ${CHROOTDIR}/usr rm -rf doc mkdir doc cp -pRP ${CVSROOT}/doc/* doc/
+.else
.if defined(DOCRELEASETAG)
cd ${CHROOTDIR}/usr rm -rf doc cvs -R -d ${CVSROOT} co ${CVSCMDARGS} -P -r ${DOCRELEASETAG} ${RELEASEDOCMODULE}
.else
cd ${CHROOTDIR}/usr rm -rf doc cvs -R -d ${CVSROOT} co ${CVSCMDARGS} -P ${RELEASEDOCMODULE}
.endif
+.endif
if [ -d ${RELEASEDISTFILES}/ ]; then \
cp -rp ${RELEASEDISTFILES} ${CHROOTDIR}/usr/ports/distfiles; \
else \
@@ -327,7 +342,6 @@
done
.endif
.endif
-.endif
.if make(rerelease)
.if !defined(RELEASENOUPDATE)
.if !defined(RELEASETAG)
@@ -344,7 +358,12 @@
done
.endif
.if !defined(NODOC)
+.if defined(CPNOTCVS)
+ cd ${CHROOTDIR}/usr rm -rf src \
+ mkdir doc cp -pRP ${CVSROOT}/doc/* doc/
+.else
cd ${CHROOTDIR}/usr/doc cvs -R -q update ${CVSCMDARGS} -P -d
+.endif
.endif
.endif
.endif
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make release...
On Tue, Oct 21, 2003 at 04:51:22PM +0930, Daniel O'Connor wrote: [...] Either apply the patch I attached and add CPNOTCVS= to your make release options, or check out the repository. In HEAD, a similar functionality is already provided through the use of the EXTSRCDIR variable. JFYI. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
Re: make release...
On Tue, Oct 21, 2003 at 04:51:22PM +0930, Daniel O'Connor wrote: [...] Either apply the patch I attached and add CPNOTCVS= to your make release options, or check out the repository. In HEAD, a similar functionality is already provided through the use of the EXTSRCDIR variable. JFYI. Ahh interesting.. My patch overrides all of the checkouts (src, port doc) though. --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
make release and md(4) problem
Hi, when doing my first make release I noticed it stopped somewhere and hung :( 74830 p2 D+ 0:01.12 cpio -dump /mnt The host is i386 and TARGET ist sparc64 just to confuse. The base system runs a HEAD world/kernel from mid july. The above cpio must be from src/release/sparc64/mkisoimages.sh unlucky me tried to see what's going on and did a ls /u3/mnt which also hung. more unlucky me also typed in sync in another screen. kill -9 on the processes did not help. After another sync I am no longer able to remotely do anything with the machine apart from successfully pinging it. Somewhere in between I tried to ktrace the processes but didn't get any output. This is what strace said: abcde# strace -p 74883 # ls getdirentries(3, ^C unfinished ... abcde# strace -p 74830 # cpio write(4, ., 512^C unfinished ... abcde# strace -p 74920 # sync sync(0^C unfinished ... I found an older PR http://www.freebsd.org/cgi/query-pr.cgi?pr=47538 that might be related. How are snapshots and release builds done by others ? Or are things already fixed and I should update base system to latest head (thinking about atang) ? and btw: are /dev/mdXc supposed to be existent as given in the release Makefiles/scripts ? Thanks for any comments. -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT 56 69 73 69 74 http://www.zabbadoz.net/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Bug in make release regarding install.cfg
Folks, I've noted that the following inconsistency exists in make release. If there is a install.cfg file in /usr/src/release when executing make release (the file which if exists is placed into the root of mfs and customises behaviour of sysinstall), /usr/src/release/install.cfg takes precedence over the same file in CVS from which release is being built and is placed onto the floppy instead of file with the same name in CVS. Appatently this breaks clean room principle of make release and needs to be fixed. Regards, Maxim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
fbsd 4.8 make release question ?
How can the values for BIGBOOT image can be changed so if there is source patch for the system like ssp make release won;t fail when buidling release.9 stage ? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: fbsd 4.8 make release question ?
On 14-Aug-2003 NIkolay Kalev wrote: How can the values for BIGBOOT image can be changed so if there is source patch for the system like ssp make release won;t fail when buidling release.9 stage ? Use a local patch via LOCAL_PATCHES. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
-current 'make release' status?
Hi,
I'm currently down to this patch to allow a make release to complete
for -current:
===
RCS file: /home/ncvs/src/release/Makefile,v
retrieving revision 1.801
diff -u -r1.801 Makefile
--- Makefile26 Jul 2003 06:47:40 - 1.801
+++ Makefile29 Jul 2003 05:09:31 -
@@ -1053,7 +1053,7 @@
cd ${.CURDIR}/..; \
KERNEL_KO=BOOTMFS KODIR= \
${CROSSMAKE} ${KERNEL_FLAGS} -DNO_MODULES -DNO_KERNELCLEAN \
- KERNCONF=BOOTMFS COPTFLAGS=-Os -pipe -DNO_CPU_COPTFLAGS \
+ KERNCONF=BOOTMFS COPTFLAGS=-Os -pipe -w -DNO_CPU_COPTFLAGS \
buildkernel reinstallkernel \
DESTDIR=${RD}/kernels
[ -r ${.CURDIR}/../sys/${TARGET}/conf/BOOTMFS.hints ] \
without it, the following causes BOOTMFS to abort:
cc -c -Os -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith
-Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/usr/src/sys
-I/usr/src/sys/dev -I/usr/src
/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/dev/ath
-I/usr/src/sys/contrib/dev/a
th/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000
-mno-align-long-strings -mpreferred-st
ack-boundary=2 -ffreestanding -Werror /usr/src/sys/cam/cam_periph.c
In file included from /usr/src/sys/cam/cam_periph.c:41:
/usr/src/sys/sys/buf.h: In function `BUF_LOCK':
/usr/src/sys/sys/buf.h:289: warning: dereferencing type-punned pointer will break
strict-aliasing rules
/usr/src/sys/sys/buf.h:289: warning: dereferencing type-punned pointer will break
strict-aliasing rules
/usr/src/sys/sys/buf.h: In function `BUF_TIMELOCK':
/usr/src/sys/sys/buf.h:310: warning: dereferencing type-punned pointer will break
strict-aliasing rules
/usr/src/sys/sys/buf.h:310: warning: dereferencing type-punned pointer will break
strict-aliasing rules
/usr/src/sys/sys/buf.h: In function `BUF_UNLOCK':
/usr/src/sys/sys/buf.h:325: warning: dereferencing type-punned pointer will break
strict-aliasing rules
/usr/src/sys/sys/buf.h:325: warning: dereferencing type-punned pointer will break
strict-aliasing rules
/usr/src/sys/sys/buf.h: In function `BUF_KERNPROC':
/usr/src/sys/sys/buf.h:350: warning: dereferencing type-punned pointer will break
strict-aliasing rules
/usr/src/sys/sys/buf.h:350: warning: dereferencing type-punned pointer will break
strict-aliasing rules
/usr/src/sys/sys/buf.h:352: warning: dereferencing type-punned pointer will break
strict-aliasing rules
/usr/src/sys/sys/buf.h:352: warning: dereferencing type-punned pointer will break
strict-aliasing rules
/usr/src/sys/cam/cam_periph.c: In function `cam_periph_mapmem':
/usr/src/sys/cam/cam_periph.c:624: warning: dereferencing type-punned pointer will
break strict-aliasing rules
.
.
.
Thoughts? Plans?
It's also worth noting that the BOOTMFS kernel build is inconsistant. The
initial build via 'make release' fails with no patch. After the failure,
a followup:
chroot $RDIR /bin/sh
/mk doMFSKERN
works correctly. The 'make release' environment is setup differently
from that of /mk. Depending on what folks think, maybe some form of:
make mk TARGET=doMFSKERN
would be appropriate to guarentee consistancy. Just a thought.
-John
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: -current 'make release' status?
On Tue, Jul 29, 2003 at 06:30:54AM -0400, John wrote:
Hi,
I'm currently down to this patch to allow a make release to complete
for -current:
[...]
Try setting the KERNEL_FLAGS=-DNO_WERROR instead.
without it, the following causes BOOTMFS to abort:
cc -c -Os -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith
-Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I.
-I/usr/src/sys -I/usr/src/sys/dev -I/usr/src
/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter
-I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/a
th/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000
-mno-align-long-strings -mpreferred-st
ack-boundary=2 -ffreestanding -Werror /usr/src/sys/cam/cam_periph.c
In file included from /usr/src/sys/cam/cam_periph.c:41:
/usr/src/sys/sys/buf.h: In function `BUF_LOCK':
/usr/src/sys/sys/buf.h:289: warning: dereferencing type-punned pointer will break
strict-aliasing rules
/usr/src/sys/sys/buf.h:289: warning: dereferencing type-punned pointer will break
strict-aliasing rules
/usr/src/sys/sys/buf.h: In function `BUF_TIMELOCK':
/usr/src/sys/sys/buf.h:310: warning: dereferencing type-punned pointer will break
strict-aliasing rules
/usr/src/sys/sys/buf.h:310: warning: dereferencing type-punned pointer will break
strict-aliasing rules
/usr/src/sys/sys/buf.h: In function `BUF_UNLOCK':
/usr/src/sys/sys/buf.h:325: warning: dereferencing type-punned pointer will break
strict-aliasing rules
/usr/src/sys/sys/buf.h:325: warning: dereferencing type-punned pointer will break
strict-aliasing rules
/usr/src/sys/sys/buf.h: In function `BUF_KERNPROC':
/usr/src/sys/sys/buf.h:350: warning: dereferencing type-punned pointer will break
strict-aliasing rules
/usr/src/sys/sys/buf.h:350: warning: dereferencing type-punned pointer will break
strict-aliasing rules
/usr/src/sys/sys/buf.h:352: warning: dereferencing type-punned pointer will break
strict-aliasing rules
/usr/src/sys/sys/buf.h:352: warning: dereferencing type-punned pointer will break
strict-aliasing rules
/usr/src/sys/cam/cam_periph.c: In function `cam_periph_mapmem':
/usr/src/sys/cam/cam_periph.c:624: warning: dereferencing type-punned pointer will
break strict-aliasing rules
.
.
.
Thoughts? Plans?
It's also worth noting that the BOOTMFS kernel build is inconsistant. The
initial build via 'make release' fails with no patch. After the failure,
a followup:
chroot $RDIR /bin/sh
/mk doMFSKERN
works correctly. The 'make release' environment is setup differently
from that of /mk. Depending on what folks think, maybe some form of:
make mk TARGET=doMFSKERN
would be appropriate to guarentee consistancy. Just a thought.
If this is the case, then it's a bug and should be fixed. I am
looking to see now if I can reproduce the problem, but a wild
guess is that: release/Makefile calls chroot(8) a bit differently,
with a clean environment, like this:
env -i /usr/sbin/chroot ${CHROOTDIR} /mk
Could it be that you have something in your environment similar
to NO_WERROR?
Cheers,
--
Ruslan Ermilov Sysadmin and DBA,
[EMAIL PROTECTED] Sunbay Software Ltd,
[EMAIL PROTECTED] FreeBSD committer
pgp0.pgp
Description: PGP signature
Re: -current 'make release' status? [SOLVED]
On Tue, Jul 29, 2003 at 09:41:54AM -0400, John De Boskey wrote: - Ruslan Ermilov's Original Message - No, I have nothing in my environment that should affect the build, no /etc/make.conf in the chroot area.. But then again: running make rerelease is effectively just calls the command above. I'm currently in the middle of the make release and will see if this is reproduceable. # chroot /vol/vol0/work/5-current-chrootdir /bin/sh # env A few things not needed that are inherited from my normal account, but nothing that should have a negative affect. Do you still get the error if you try make rerelease? Do you still get the error if you try chroot ... /mk? Do you still get the error if you try env -i chroot ... /mk? I'll see what I can find.. John, I see the same breakage as you do. But in all three cases above, I see the same breakage (as expected). Even if I'm running chroot /data/ru/R then ./mk doMFSKERN, I still get it: : In file included from /usr/src/sys/cam/cam_periph.c:41: : /usr/src/sys/sys/buf.h: In function `BUF_LOCK': : /usr/src/sys/sys/buf.h:289: warning: dereferencing type-punned pointer will break strict-aliasing rules : ... : *** Error code 1 : : Stop in /usr/obj/usr/src/sys/BOOTMFS. Forget what I've said about NO_WERROR, it (unfortunately) only applies to the userland. Still, running make rerelease KERNEL_FLAGS=WERROR= gets the release done. I wondered why I get it, and similarly my nigthly buildkernel completed without errors. This turned out to be due to the -O vs. -Os differences. For example, compiling vfs_subr.o from the GENERIC kernel results in these same warnings when compiled with COPTFLAGS=-Os -pipe. Peter, should we switch -Werror back off in kern.pre.mk? Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
Re: -current 'make release' status? [SOLVED]
On Tue, 29 Jul 2003, Ruslan Ermilov wrote: ... Forget what I've said about NO_WERROR, it (unfortunately) only applies to the userland. Still, running make rerelease KERNEL_FLAGS=WERROR= gets the release done. I wondered why I get it, and similarly my nigthly buildkernel completed without errors. This turned out to be due to the -O vs. -Os differences. For example, compiling vfs_subr.o from the GENERIC kernel results in these same warnings when compiled with COPTFLAGS=-Os -pipe. Peter, should we switch -Werror back off in kern.pre.mk? Use -fno-strict-aliasing if you use -Os. Otherwise, -Os is stricter than -O. On second thoughts, -Os implies -f-strict-aliasing because -Os may need strict aliasing for the same reasons as -O2. We've seen -O2 in combination with broken aliasing in libm cause fatal errors. Better find part of -O2 that needs strict aliasing and turn it off too. Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: -current 'make release' status? [SOLVED]
On Wed, Jul 30, 2003 at 06:14:17AM +1000, Bruce Evans wrote: On Tue, 29 Jul 2003, Ruslan Ermilov wrote: ... Forget what I've said about NO_WERROR, it (unfortunately) only applies to the userland. Still, running make rerelease KERNEL_FLAGS=WERROR= gets the release done. I wondered why I get it, and similarly my nigthly buildkernel completed without errors. This turned out to be due to the -O vs. -Os differences. For example, compiling vfs_subr.o from the GENERIC kernel results in these same warnings when compiled with COPTFLAGS=-Os -pipe. Peter, should we switch -Werror back off in kern.pre.mk? Use -fno-strict-aliasing if you use -Os. Otherwise, -Os is stricter than -O. On second thoughts, -Os implies -f-strict-aliasing because -Os may need strict aliasing for the same reasons as -O2. We've seen -O2 in combination with broken aliasing in libm cause fatal errors. Better find part of -O2 that needs strict aliasing and turn it off too. Hm, I always thought that -O2 and -Os are just useful aliases that in effect only turn a few dozens of -f optimization flags, and that switching some of them off later is allowed. I.e., -Os -fno-strict-aliasing should work. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
Re: -current 'make release' status? [SOLVED]
In the last episode (Jul 29), Ruslan Ermilov said: Hm, I always thought that -O2 and -Os are just useful aliases that in effect only turn a few dozens of -f optimization flags, and that switching some of them off later is allowed. I.e., -Os -fno-strict-aliasing should work. That does work, but there are still things you can't turn off with -f. They're half-aliases. toplev.c::parse_options_and_default_flags does set -f flags based on the optimization level, but there is still a whole lot of gcc code that directly tests the value of optimize and optimize_size. -- Dan Nelson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: -current 'make release' status? [SOLVED]
On Tue, 29 Jul 2003, Ruslan Ermilov wrote: On Wed, Jul 30, 2003 at 06:14:17AM +1000, Bruce Evans wrote: On Tue, 29 Jul 2003, Ruslan Ermilov wrote: ... Forget what I've said about NO_WERROR, it (unfortunately) only applies to the userland. Still, running make rerelease KERNEL_FLAGS=WERROR= gets the release done. I wondered why I get it, and similarly my nigthly buildkernel completed without errors. This turned out to be due to the -O vs. -Os differences. For example, compiling vfs_subr.o from the GENERIC kernel results in these same warnings when compiled with COPTFLAGS=-Os -pipe. Peter, should we switch -Werror back off in kern.pre.mk? Use -fno-strict-aliasing if you use -Os. Otherwise, -Os is stricter ^^ This was too complete :-). I meant -Wno-strict-aliasing when I wrote it (since I misread the info about -Os). than -O. On second thoughts, -Os implies -f-strict-aliasing because -Os may need strict aliasing for the same reasons as -O2. We've seen -O2 in combination with broken aliasing in libm cause fatal errors. Better find part of -O2 that needs strict aliasing and turn it off too. Hm, I always thought that -O2 and -Os are just useful aliases that in effect only turn a few dozens of -f optimization flags, and that switching some of them off later is allowed. I.e., -Os -fno-strict-aliasing should work. Yes, this seems to be the only option that needs warnings about strict aliasing. Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make release broken [FIX]
On Tue, Jul 22, 2003 at 02:26:34PM -0400, John Baldwin wrote: On 22-Jul-2003 Ruslan Ermilov wrote: Hi! As many of you probably know, recent telnet commit broke snapshot building. Since I needed a working make release to go on with my task on floppy-less make release (for AMD64, etc.), I had to just fix it. Attached is the patch. It also fixes another issue with this telnet commit: it ensures that crypto telnet[d] do not end up in the base distribution. Why not simply enable 'NO_FLOPPIES' on the arch's that don't want floppies? For one, its broken -- NO_FLOPPIES doesn't build the bootmfs floppy but still does the driver floppy. At least for Alpha this was true during 5.1 RC time. -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make release broken [FIX]
On Fri, Jul 25, 2003 at 01:59:40PM -0700, David O'Brien wrote: On Tue, Jul 22, 2003 at 02:26:34PM -0400, John Baldwin wrote: On 22-Jul-2003 Ruslan Ermilov wrote: Hi! As many of you probably know, recent telnet commit broke snapshot building. Since I needed a working make release to go on with my task on floppy-less make release (for AMD64, etc.), I had to just fix it. Attached is the patch. It also fixes another issue with this telnet commit: it ensures that crypto telnet[d] do not end up in the base distribution. Why not simply enable 'NO_FLOPPIES' on the arch's that don't want floppies? For one, its broken -- NO_FLOPPIES doesn't build the bootmfs floppy but still does the driver floppy. At least for Alpha this was true during 5.1 RC time. Please look at the latest release/Makefile, then follow up in this thread. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
Re: make release broken [FIX]
On Tue, Jul 22, 2003 at 03:07:01PM -0400, John Baldwin wrote:
Are you eliminating the mfsroot?
Yes.
Ugh.
How does sysinstall work with this change? You do realize that we
mount the MFS as /, then mount the disk under /mnt, chroot to /mnt,
then mount the CD in /dist in the chroot and install from there?
Are you going to mount the CD as root or something? It is probably
a lot simpler to simply let sysinstall always execute in a MFS root.
John, Warner,
At this stage it's obvious to me that we'd better with always
building mfsroot stuff, even for platforms that do not provide
floppy installation (AMD64). As such, the following commit
would be in order, but as it falls under the obrien vs ru
category, I hereby ask (again) your permission to commit it:
%%%
Index: Makefile
===
RCS file: /home/ncvs/src/release/Makefile,v
retrieving revision 1.790
diff -u -r1.790 Makefile
--- Makefile23 Jul 2003 06:00:56 - 1.790
+++ Makefile23 Jul 2003 06:02:11 -
@@ -985,14 +985,8 @@
md5 * CHECKSUM.MD5) \
)
-.if target(release.9.${TARGET_ARCH})
-RELEASE9=release.9.${TARGET_ARCH}
-.else
-RELEASE9=release.9
-.endif
-
doRELEASE: release.1 release.2 release.3 ${DOCREL} release.4 release.5 \
- release.6 release.7 release.8 ${RELEASE9} ${FIXIT_TARGET}
+ release.6 release.7 release.8 release.9 ${FIXIT_TARGET}
@cd ${.CURDIR} ${MAKE} ${EXTRAS}
@echo Release done
%%%
The release.9 target is responsible for creating mfsroot, amongst
other tasks.
Cheers,
--
Ruslan Ermilov Sysadmin and DBA,
[EMAIL PROTECTED] Sunbay Software Ltd,
[EMAIL PROTECTED] FreeBSD committer
pgp0.pgp
Description: PGP signature
Re: make release broken [FIX]
On Tue, Jul 22, 2003 at 07:42:33PM +0300, Ruslan Ermilov wrote:
Hi!
As many of you probably know, recent telnet commit broke snapshot
building. Since I needed a working make release to go on with
my task on floppy-less make release (for AMD64, etc.), I had to
just fix it. Attached is the patch. It also fixes another issue
with this telnet commit: it ensures that crypto telnet[d] do not
end up in the base distribution.
Missed in the patch: set DISTRIBUTION=crypto in lib/libtelnet/Makefile,
so that we still have crypto/usr/include/arpa/telnet.h.
%%%
Index: Makefile
===
RCS file: /home/ncvs/src/lib/libtelnet/Makefile,v
retrieving revision 1.16
diff -u -r1.16 Makefile
--- Makefile20 Jul 2003 23:29:46 - 1.16
+++ Makefile23 Jul 2003 06:37:09 -
@@ -13,10 +13,11 @@
WARNS?=2
-.if !defined(NOCRYPT) !defined(NO_OPENSSL)
+.if exists(${.CURDIR}/../../crypto) !defined(NOCRYPT) !defined(NO_OPENSSL)
+DISTRIBUTION= crypto
SRCS+= encrypt.c auth.c enc_des.c sra.c pk.c
CFLAGS+= -DENCRYPTION -DAUTHENTICATION -DSRA
-.if !defined(NO_KERBEROS)
+.if exists(${.CURDIR}/../../kerberos5) !defined(NO_KERBEROS)
SRCS+= kerberos5.c
CFLAGS+= -DKRB5 -I${KRB5DIR}/lib/krb5 -I${KRB5OBJDIR} -I${ASN1OBJDIR}
CFLAGS+= -DFORWARD -Dnet_write=telnet_net_write
%%%
Cheers,
--
Ruslan Ermilov Sysadmin and DBA,
[EMAIL PROTECTED] Sunbay Software Ltd,
[EMAIL PROTECTED] FreeBSD committer
pgp0.pgp
Description: PGP signature
Re: make release broken [FIX]
Hi
Please do not commit this.
M
Ruslan Ermilov writes:
--A9z/3b/E4MkkD+7G
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Jul 22, 2003 at 07:42:33PM +0300, Ruslan Ermilov wrote:
Hi!
=20
As many of you probably know, recent telnet commit broke snapshot
building. Since I needed a working make release to go on with
my task on floppy-less make release (for AMD64, etc.), I had to
just fix it. Attached is the patch. It also fixes another issue
with this telnet commit: it ensures that crypto telnet[d] do not
end up in the base distribution.
=20
Missed in the patch: set DISTRIBUTION=3Dcrypto in lib/libtelnet/Makefile,
so that we still have crypto/usr/include/arpa/telnet.h.
%%%
Index: Makefile
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /home/ncvs/src/lib/libtelnet/Makefile,v
retrieving revision 1.16
diff -u -r1.16 Makefile
--- Makefile 20 Jul 2003 23:29:46 - 1.16
+++ Makefile 23 Jul 2003 06:37:09 -
@@ -13,10 +13,11 @@
=20
WARNS?=3D2
=20
-.if !defined(NOCRYPT) !defined(NO_OPENSSL)
+.if exists(${.CURDIR}/../../crypto) !defined(NOCRYPT) !defined(NO_OP=
ENSSL)
+DISTRIBUTION=3D crypto
SRCS+=3D encrypt.c auth.c enc_des.c sra.c pk.c
CFLAGS+=3D -DENCRYPTION -DAUTHENTICATION -DSRA
-.if !defined(NO_KERBEROS)
+.if exists(${.CURDIR}/../../kerberos5) !defined(NO_KERBEROS)
SRCS+=3D kerberos5.c
CFLAGS+=3D -DKRB5 -I${KRB5DIR}/lib/krb5 -I${KRB5OBJDIR} -I${ASN1OBJDIR}
CFLAGS+=3D -DFORWARD -Dnet_write=3Dtelnet_net_write
%%%
Cheers,
--=20
Ruslan ErmilovSysadmin and DBA,
[EMAIL PROTECTED] Sunbay Software Ltd,
[EMAIL PROTECTED] FreeBSD committer
--A9z/3b/E4MkkD+7G
Content-Type: application/pgp-signature
Content-Disposition: inline
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (FreeBSD)
iD8DBQE/Hi8lUkv4P6juNwoRArAKAJ0QpXpQ9YPuG5gXUo/5p+uia83CiACfTkYW
Myhb+SttdXFnNahueIHJ7Us=
=LyZK
-END PGP SIGNATURE-
--A9z/3b/E4MkkD+7G--
--
Mark Murray
iumop ap!sdn w,I idlaH
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make release broken [FIX]
On Wed, Jul 23, 2003 at 11:33:50AM +0100, Mark Murray wrote: Hi Please do not commit this. Please stop repeating this endlessly. This patch is only for those who need a working make release urgently, like me. You made it clear that you're working on a better fix. -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
make release broken [FIX]
Hi!
As many of you probably know, recent telnet commit broke snapshot
building. Since I needed a working make release to go on with
my task on floppy-less make release (for AMD64, etc.), I had to
just fix it. Attached is the patch. It also fixes another issue
with this telnet commit: it ensures that crypto telnet[d] do not
end up in the base distribution.
Cheers,
--
Ruslan Ermilov Sysadmin and DBA,
[EMAIL PROTECTED] Sunbay Software Ltd,
[EMAIL PROTECTED] FreeBSD committer
Index: release/Makefile
===
RCS file: /home/ncvs/src/release/Makefile,v
retrieving revision 1.787
diff -u -r1.787 Makefile
--- release/Makefile4 Jul 2003 14:39:17 - 1.787
+++ release/Makefile21 Jul 2003 20:14:33 -
@@ -236,7 +236,8 @@
.if !defined(FIXCRYPTO)
FIXCRYPTO!=cd ${.CURDIR}/../kerberos5; ${MAKE} -V KPROGS
FIXCRYPTO+=bin/ed usr.sbin/ppp usr.sbin/pppd usr.sbin/tcpdump/tcpdump \
- lib/libfetch usr.bin/fetch
+ lib/libfetch usr.bin/fetch \
+ lib/libtelnet libexec/telnetd usr.bin/telnet
.if !defined(NO_SENDMAIL)
FIXCRYPTO+=usr.sbin/sendmail
.endif
Index: lib/libtelnet/Makefile
===
RCS file: /home/ncvs/src/lib/libtelnet/Makefile,v
retrieving revision 1.16
diff -u -r1.16 Makefile
--- lib/libtelnet/Makefile 20 Jul 2003 23:29:46 - 1.16
+++ lib/libtelnet/Makefile 21 Jul 2003 19:58:26 -
@@ -13,10 +13,10 @@
WARNS?=2
-.if !defined(NOCRYPT) !defined(NO_OPENSSL)
+.if exists(${.CURDIR}/../../crypto) !defined(NOCRYPT) !defined(NO_OPENSSL)
SRCS+= encrypt.c auth.c enc_des.c sra.c pk.c
CFLAGS+= -DENCRYPTION -DAUTHENTICATION -DSRA
-.if !defined(NO_KERBEROS)
+.if exists(${.CURDIR}/../../kerberos5) !defined(NO_KERBEROS)
SRCS+= kerberos5.c
CFLAGS+= -DKRB5 -I${KRB5DIR}/lib/krb5 -I${KRB5OBJDIR} -I${ASN1OBJDIR}
CFLAGS+= -DFORWARD -Dnet_write=telnet_net_write
Index: libexec/telnetd/Makefile
===
RCS file: /home/ncvs/src/libexec/telnetd/Makefile,v
retrieving revision 1.21
diff -u -r1.21 Makefile
--- libexec/telnetd/Makefile20 Jul 2003 23:29:46 - 1.21
+++ libexec/telnetd/Makefile21 Jul 2003 20:19:17 -
@@ -28,12 +28,13 @@
DPADD= ${LIBUTIL} ${LIBTERMCAP} ${LIBTELNET}
LDADD= -lutil -ltermcap ${LIBTELNET}
-.if !defined(NOCRYPT) !defined(NO_OPENSSL)
+.if exists(${.CURDIR}/../../crypto) !defined(NOCRYPT) !defined(NO_OPENSSL)
+DISTRIBUTION= crypto
SRCS+= authenc.c
CFLAGS+= -DAUTHENTICATION -DENCRYPTION
DPADD+=${LIBMP} ${LIBCRYPTO} ${LIBCRYPT} ${LIBPAM}
LDADD+=-lmp -lcrypto -lcrypt ${MINUSLPAM}
-.if !defined(NO_KERBEROS)
+.if exists(${.CURDIR}/../../kerberos5) !defined(NO_KERBEROS)
CFLAGS+= -DKRB5 -DFORWARD -Dnet_write=telnet_net_write
DPADD+=${LIBKRB5} ${LIBASN1} ${LIBROKEN} ${LIBCOM_ERR}
LDADD+=-lkrb5 -lasn1 -lroken -lcom_err
Index: usr.bin/telnet/Makefile
===
RCS file: /home/ncvs/src/usr.bin/telnet/Makefile,v
retrieving revision 1.23
diff -u -r1.23 Makefile
--- usr.bin/telnet/Makefile 20 Jul 2003 23:29:46 - 1.23
+++ usr.bin/telnet/Makefile 22 Jul 2003 11:41:02 -
@@ -20,25 +20,26 @@
DPADD= ${LIBTERMCAP} ${LIBTELNET}
LDADD= -ltermcap ${LIBTELNET}
-.if !defined(RELEASE_CRUNCH)
-CFLAGS+= -DINET6 -DIPSEC
-DPADD+=${LIBIPSEC}
-LDADD+=-lipsec
-.else
+.if defined(RELEASE_CRUNCH)
.PATH: ${TELNETDIR}/libtelnet
SRCS+= genget.c getent.c misc.c
CFLAGS+= -DHAS_CGETENT
-.endif
+.else
+CFLAGS+= -DINET6 -DIPSEC
+DPADD+=${LIBIPSEC}
+LDADD+=-lipsec
-.if !defined(NOCRYPT) !defined(NO_OPENSSL)
+.if exists(${.CURDIR}/../../crypto) !defined(NOCRYPT) !defined(NO_OPENSSL)
+DISTRIBUTION= crypto
SRCS+= authenc.c
CFLAGS+= -DENCRYPTION -DAUTHENTICATION -DIPSEC
DPADD+=${LIBMP} ${LIBCRYPTO} ${LIBCRYPT} ${LIBIPSEC} ${LIBPAM}
LDADD+=-lmp -lcrypto -lcrypt -lipsec ${MINUSLPAM}
-.if !defined(NO_KERBEROS)
+.if exists(${.CURDIR}/../../kerberos5) !defined(NO_KERBEROS)
CFLAGS+= -DKRB5 -DFORWARD -Dnet_write=telnet_net_write
DPADD+=${LIBKRB5} ${LIBASN1} ${LIBCOM_ERR} ${LIBROKEN}
LDADD+=-lkrb5 -lasn1 -lcom_err -lroken
+.endif
.endif
.endif
pgp0.pgp
Description: PGP signature
Re: make release broken [FIX]
This is on my TODO.
Do not commit this - I have a much cleaner fix.
M
Ruslan Ermilov writes:
--v9Ux+11Zm5mwPlX6
Content-Type: multipart/mixed; boundary=a8Wt8u1KmwUX3Y2C
Content-Disposition: inline
--a8Wt8u1KmwUX3Y2C
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Hi!
As many of you probably know, recent telnet commit broke snapshot
building. Since I needed a working make release to go on with
my task on floppy-less make release (for AMD64, etc.), I had to
just fix it. Attached is the patch. It also fixes another issue
with this telnet commit: it ensures that crypto telnet[d] do not
end up in the base distribution.
Cheers,
--=20
Ruslan ErmilovSysadmin and DBA,
[EMAIL PROTECTED] Sunbay Software Ltd,
[EMAIL PROTECTED] FreeBSD committer
--a8Wt8u1KmwUX3Y2C
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=p
Content-Transfer-Encoding: quoted-printable
Index: release/Makefile
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /home/ncvs/src/release/Makefile,v
retrieving revision 1.787
diff -u -r1.787 Makefile
--- release/Makefile 4 Jul 2003 14:39:17 - 1.787
+++ release/Makefile 21 Jul 2003 20:14:33 -
@@ -236,7 +236,8 @@
.if !defined(FIXCRYPTO)
FIXCRYPTO!=3Dcd ${.CURDIR}/../kerberos5; ${MAKE} -V KPROGS
FIXCRYPTO+=3Dbin/ed usr.sbin/ppp usr.sbin/pppd usr.sbin/tcpdump/tcpd
ump \
- lib/libfetch usr.bin/fetch
+ lib/libfetch usr.bin/fetch \
+ lib/libtelnet libexec/telnetd usr.bin/telnet
.if !defined(NO_SENDMAIL)
FIXCRYPTO+=3Dusr.sbin/sendmail
.endif
Index: lib/libtelnet/Makefile
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /home/ncvs/src/lib/libtelnet/Makefile,v
retrieving revision 1.16
diff -u -r1.16 Makefile
--- lib/libtelnet/Makefile20 Jul 2003 23:29:46 - 1.16
+++ lib/libtelnet/Makefile21 Jul 2003 19:58:26 -
@@ -13,10 +13,10 @@
=20
WARNS?=3D2
=20
-.if !defined(NOCRYPT) !defined(NO_OPENSSL)
+.if exists(${.CURDIR}/../../crypto) !defined(NOCRYPT) !defined(NO_OP=
ENSSL)
SRCS+=3D encrypt.c auth.c enc_des.c sra.c pk.c
CFLAGS+=3D -DENCRYPTION -DAUTHENTICATION -DSRA
-.if !defined(NO_KERBEROS)
+.if exists(${.CURDIR}/../../kerberos5) !defined(NO_KERBEROS)
SRCS+=3D kerberos5.c
CFLAGS+=3D -DKRB5 -I${KRB5DIR}/lib/krb5 -I${KRB5OBJDIR} -I${ASN1OBJDIR}
CFLAGS+=3D -DFORWARD -Dnet_write=3Dtelnet_net_write
Index: libexec/telnetd/Makefile
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /home/ncvs/src/libexec/telnetd/Makefile,v
retrieving revision 1.21
diff -u -r1.21 Makefile
--- libexec/telnetd/Makefile 20 Jul 2003 23:29:46 - 1.21
+++ libexec/telnetd/Makefile 21 Jul 2003 20:19:17 -
@@ -28,12 +28,13 @@
DPADD=3D ${LIBUTIL} ${LIBTERMCAP} ${LIBTELNET}
LDADD=3D -lutil -ltermcap ${LIBTELNET}
=20
-.if !defined(NOCRYPT) !defined(NO_OPENSSL)
+.if exists(${.CURDIR}/../../crypto) !defined(NOCRYPT) !defined(NO_OP=
ENSSL)
+DISTRIBUTION=3D crypto
SRCS+=3D authenc.c
CFLAGS+=3D -DAUTHENTICATION -DENCRYPTION
DPADD+=3D${LIBMP} ${LIBCRYPTO} ${LIBCRYPT} ${LIBPAM}
LDADD+=3D-lmp -lcrypto -lcrypt ${MINUSLPAM}
-.if !defined(NO_KERBEROS)
+.if exists(${.CURDIR}/../../kerberos5) !defined(NO_KERBEROS)
CFLAGS+=3D -DKRB5 -DFORWARD -Dnet_write=3Dtelnet_net_write
DPADD+=3D${LIBKRB5} ${LIBASN1} ${LIBROKEN} ${LIBCOM_ERR}
LDADD+=3D-lkrb5 -lasn1 -lroken -lcom_err
Index: usr.bin/telnet/Makefile
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /home/ncvs/src/usr.bin/telnet/Makefile,v
retrieving revision 1.23
diff -u -r1.23 Makefile
--- usr.bin/telnet/Makefile 20 Jul 2003 23:29:46 - 1.23
+++ usr.bin/telnet/Makefile 22 Jul 2003 11:41:02 -
@@ -20,25 +20,26 @@
DPADD=3D ${LIBTERMCAP} ${LIBTELNET}
LDADD=3D -ltermcap ${LIBTELNET}
=20
-.if !defined(RELEASE_CRUNCH)
-CFLAGS+=3D -DINET6 -DIPSEC
-DPADD+=3D${LIBIPSEC}
-LDADD+=3D-lipsec
-.else
+.if defined(RELEASE_CRUNCH)
.PATH: ${TELNETDIR}/libtelnet
SRCS
RE: make release broken [FIX]
On 22-Jul-2003 Ruslan Ermilov wrote: Hi! As many of you probably know, recent telnet commit broke snapshot building. Since I needed a working make release to go on with my task on floppy-less make release (for AMD64, etc.), I had to just fix it. Attached is the patch. It also fixes another issue with this telnet commit: it ensures that crypto telnet[d] do not end up in the base distribution. Why not simply enable 'NO_FLOPPIES' on the arch's that don't want floppies? -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make release broken [FIX]
On Tue, Jul 22, 2003 at 02:26:34PM -0400, John Baldwin wrote: On 22-Jul-2003 Ruslan Ermilov wrote: Hi! As many of you probably know, recent telnet commit broke snapshot building. Since I needed a working make release to go on with my task on floppy-less make release (for AMD64, etc.), I had to just fix it. Attached is the patch. It also fixes another issue with this telnet commit: it ensures that crypto telnet[d] do not end up in the base distribution. Why not simply enable 'NO_FLOPPIES' on the arch's that don't want floppies? Because NO_FLOPPIES doesn't mean like it sounds; it means do not create floppy _images_, and we want to skip much more than that. I have a preliminary patch that is currently under the make release test. Let me know (or anyone else) if you want to review it or the final version before I commit it. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
Re: make release broken [FIX]
On 22-Jul-2003 Ruslan Ermilov wrote: On Tue, Jul 22, 2003 at 02:26:34PM -0400, John Baldwin wrote: On 22-Jul-2003 Ruslan Ermilov wrote: Hi! As many of you probably know, recent telnet commit broke snapshot building. Since I needed a working make release to go on with my task on floppy-less make release (for AMD64, etc.), I had to just fix it. Attached is the patch. It also fixes another issue with this telnet commit: it ensures that crypto telnet[d] do not end up in the base distribution. Why not simply enable 'NO_FLOPPIES' on the arch's that don't want floppies? Because NO_FLOPPIES doesn't mean like it sounds; it means do not create floppy _images_, and we want to skip much more than that. I have a preliminary patch that is currently under the make release test. Let me know (or anyone else) if you want to review it or the final version before I commit it. Are you eliminating the mfsroot? All the bootable CD's use that right now, so what more are you doing than eliminating the floppy images? -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make release broken [FIX]
On Tue, Jul 22, 2003 at 02:45:52PM -0400, John Baldwin wrote:
On 22-Jul-2003 Ruslan Ermilov wrote:
On Tue, Jul 22, 2003 at 02:26:34PM -0400, John Baldwin wrote:
On 22-Jul-2003 Ruslan Ermilov wrote:
Hi!
As many of you probably know, recent telnet commit broke snapshot
building. Since I needed a working make release to go on with
my task on floppy-less make release (for AMD64, etc.), I had to
just fix it. Attached is the patch. It also fixes another issue
with this telnet commit: it ensures that crypto telnet[d] do not
end up in the base distribution.
Why not simply enable 'NO_FLOPPIES' on the arch's that don't want
floppies?
Because NO_FLOPPIES doesn't mean like it sounds; it means do not
create floppy _images_, and we want to skip much more than that.
I have a preliminary patch that is currently under the make
release test. Let me know (or anyone else) if you want to review
it or the final version before I commit it.
Are you eliminating the mfsroot?
Yes.
All the bootable CD's use
that right now, so what more are you doing than eliminating
the floppy images?
Part of the patch for the iso.1 target has this (cut-n-pasted):
@@ -885,10 +873,7 @@
.if ${TARGET} != pc98
@echo Setting up /boot
@rm -f ${CD_DISC2}/boot/loader.conf
- @cp ${RD}/mfsroot/mfsroot.gz ${CD_DISC2}/boot/mfsroot.gz
- @echo 'mfsroot_load=YES' ${CD_DISC2}/boot/loader.conf
- @echo 'mfsroot_type=mfs_root' ${CD_DISC2}/boot/loader.conf
- @echo 'mfsroot_name=/boot/mfsroot' ${CD_DISC2}/boot/loader.conf
+ @echo 'init_path=/usr/sbin/sysinstall' ${CD_DISC2}/boot/loader.conf
@cp -Rp ${CD_DISC2}/boot ${CD_DISC1}
.endif
.if !defined(NOPORTS)
Cheers,
--
Ruslan Ermilov Sysadmin and DBA,
[EMAIL PROTECTED] Sunbay Software Ltd,
[EMAIL PROTECTED] FreeBSD committer
pgp0.pgp
Description: PGP signature
Re: make release broken [FIX]
On 22-Jul-2003 Ruslan Ermilov wrote:
On Tue, Jul 22, 2003 at 02:45:52PM -0400, John Baldwin wrote:
On 22-Jul-2003 Ruslan Ermilov wrote:
On Tue, Jul 22, 2003 at 02:26:34PM -0400, John Baldwin wrote:
On 22-Jul-2003 Ruslan Ermilov wrote:
Hi!
As many of you probably know, recent telnet commit broke snapshot
building. Since I needed a working make release to go on with
my task on floppy-less make release (for AMD64, etc.), I had to
just fix it. Attached is the patch. It also fixes another issue
with this telnet commit: it ensures that crypto telnet[d] do not
end up in the base distribution.
Why not simply enable 'NO_FLOPPIES' on the arch's that don't want
floppies?
Because NO_FLOPPIES doesn't mean like it sounds; it means do not
create floppy _images_, and we want to skip much more than that.
I have a preliminary patch that is currently under the make
release test. Let me know (or anyone else) if you want to review
it or the final version before I commit it.
Are you eliminating the mfsroot?
Yes.
Ugh.
All the bootable CD's use
that right now, so what more are you doing than eliminating
the floppy images?
Part of the patch for the iso.1 target has this (cut-n-pasted):
@@ -885,10 +873,7 @@
.if ${TARGET} != pc98
@echo Setting up /boot
@rm -f ${CD_DISC2}/boot/loader.conf
- @cp ${RD}/mfsroot/mfsroot.gz ${CD_DISC2}/boot/mfsroot.gz
- @echo 'mfsroot_load=YES' ${CD_DISC2}/boot/loader.conf
- @echo 'mfsroot_type=mfs_root' ${CD_DISC2}/boot/loader.conf
- @echo 'mfsroot_name=/boot/mfsroot' ${CD_DISC2}/boot/loader.conf
+ @echo 'init_path=/usr/sbin/sysinstall' ${CD_DISC2}/boot/loader.conf
@cp -Rp ${CD_DISC2}/boot ${CD_DISC1}
.endif
.if !defined(NOPORTS)
How does sysinstall work with this change? You do realize that we
mount the MFS as /, then mount the disk under /mnt, chroot to /mnt,
then mount the CD in /dist in the chroot and install from there?
Are you going to mount the CD as root or something? It is probably
a lot simpler to simply let sysinstall always execute in a MFS root.
If you really want to rewrite the installation environment, then you
might want to talk that over on a mailing list first to get some input.
It's not a trivial task.
--
John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve! - http://www.FreeBSD.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make release broken [FIX]
On Tue, Jul 22, 2003 at 03:07:01PM -0400, John Baldwin wrote: Why not simply enable 'NO_FLOPPIES' on the arch's that don't want floppies? Are you eliminating the mfsroot? Yes. Ugh. Yes, after looking into this a bit deeper, I must agree that preserving the mfsroot is much simpler. And I will probably do just that. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
Re: make release of CURRENT on 4.7 broken again ?
On Sun, Jul 20, 2003 at 02:44:23PM +0300, Ruslan Ermilov wrote:
A few days ago I've noticed such messages in CURRENT buildlog (on 4.7
box, building without -jsomething) :
cc -Os -pipe -c chown_stub.c
ld -dc -r -o chown.lo chown_stub.o /usr/obj//usr/src/usr.sbin/chown/chown.o
crunchide -k _crunched_chown_stub chown.lo
echo int _crunched_chroot_stub(int argc, char **argv, char **envp){return
main(argc,argv,envp);} chroot_stub.c
cc -Os -pipe -c chroot_stub.c
ld -dc -r -o chroot.lo chroot_stub.o /usr/obj//usr/src/usr.sbin/chroot/chroot.o
crunchide -k _crunched_chroot_stub chroot.lo
cc -static -o fixit_crunch fixit_crunch.o cat.lo chmod.lo cp.lo dd.lo df.lo
echo.lo expr.lo kill.lo ln.lo ls.lo mkdir.lo mv.lo rm.lo rmdir.lo sleep.lo sync.lo
bsdlabel.lo clri.lo dmesg.lo fdisk.lo mknod.lo mount.lo mount_cd9660.lo
mount_msdosfs.lo reboot.lo restore.lo swapon.lo umount.lo ftp.lo telnet.lo vi.lo
chown.lo chroot.lo -ledit -lgeom -lkvm -lm -lncurses
-lutil
*** Error code 1
Stop in /usr/obj/usr/src/release/fixit_crunch.
*** Error code 1
I have committed a fix for this to src/bin/ed/ a few minutes ago.
Hmm. But I got the same error during last release building (this night).
Cheers,
--
Ruslan ErmilovSysadmin and DBA,
[EMAIL PROTECTED] Sunbay Software Ltd,
[EMAIL PROTECTED] FreeBSD committer
--
Andrey Elperin
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make release of CURRENT on 4.7 broken again ?
On Mon, Jul 21, 2003 at 02:13:45PM +0300, Andrey Elperin wrote:
On Sun, Jul 20, 2003 at 02:44:23PM +0300, Ruslan Ermilov wrote:
A few days ago I've noticed such messages in CURRENT buildlog (on 4.7
box, building without -jsomething) :
cc -Os -pipe -c chown_stub.c
ld -dc -r -o chown.lo chown_stub.o /usr/obj//usr/src/usr.sbin/chown/chown.o
crunchide -k _crunched_chown_stub chown.lo
echo int _crunched_chroot_stub(int argc, char **argv, char **envp){return
main(argc,argv,envp);} chroot_stub.c
cc -Os -pipe -c chroot_stub.c
ld -dc -r -o chroot.lo chroot_stub.o /usr/obj//usr/src/usr.sbin/chroot/chroot.o
crunchide -k _crunched_chroot_stub chroot.lo
cc -static -o fixit_crunch fixit_crunch.o cat.lo chmod.lo cp.lo dd.lo df.lo
echo.lo expr.lo kill.lo ln.lo ls.lo mkdir.lo mv.lo rm.lo rmdir.lo sleep.lo
sync.lo bsdlabel.lo clri.lo dmesg.lo fdisk.lo mknod.lo mount.lo mount_cd9660.lo
mount_msdosfs.lo reboot.lo restore.lo swapon.lo umount.lo ftp.lo telnet.lo vi.lo
chown.lo chroot.lo -ledit -lgeom -lkvm -lm -lncurses
-lutil
*** Error code 1
Stop in /usr/obj/usr/src/release/fixit_crunch.
*** Error code 1
I have committed a fix for this to src/bin/ed/ a few minutes ago.
Hmm. But I got the same error during last release building (this night).
The make -j buildworld is currently broken by the recent changes
to kerberos5/, and the issue is being worked out. The breakage is
mostly visible in the 4.x doing the build of 5.x case, because
the latter has /usr/include/roken.h and hides the building bug.
At the moment, I'm retesting the snapshot build of 5.x on my 4.x
SMP box without -j. I will follow up with what I get.
Cheers,
--
Ruslan Ermilov Sysadmin and DBA,
[EMAIL PROTECTED] Sunbay Software Ltd,
[EMAIL PROTECTED] FreeBSD committer
pgp0.pgp
Description: PGP signature
Re: make release of CURRENT on 4.7 broken again ?
On Mon, Jul 21, 2003 at 06:08:43PM +0300, Ruslan Ermilov wrote:
On Mon, Jul 21, 2003 at 02:13:45PM +0300, Andrey Elperin wrote:
On Sun, Jul 20, 2003 at 02:44:23PM +0300, Ruslan Ermilov wrote:
A few days ago I've noticed such messages in CURRENT buildlog (on 4.7
box, building without -jsomething) :
cc -Os -pipe -c chown_stub.c
ld -dc -r -o chown.lo chown_stub.o /usr/obj//usr/src/usr.sbin/chown/chown.o
crunchide -k _crunched_chown_stub chown.lo
echo int _crunched_chroot_stub(int argc, char **argv, char **envp){return
main(argc,argv,envp);} chroot_stub.c
cc -Os -pipe -c chroot_stub.c
ld -dc -r -o chroot.lo chroot_stub.o /usr/obj//usr/src/usr.sbin/chroot/chroot.o
crunchide -k _crunched_chroot_stub chroot.lo
cc -static -o fixit_crunch fixit_crunch.o cat.lo chmod.lo cp.lo dd.lo df.lo
echo.lo expr.lo kill.lo ln.lo ls.lo mkdir.lo mv.lo rm.lo rmdir.lo sleep.lo
sync.lo bsdlabel.lo clri.lo dmesg.lo fdisk.lo mknod.lo mount.lo
mount_cd9660.lo mount_msdosfs.lo reboot.lo restore.lo swapon.lo umount.lo
ftp.lo telnet.lo vi.lo chown.lo chroot.lo -ledit -lgeom -lkvm -lm -lncurses
-lutil
*** Error code 1
Stop in /usr/obj/usr/src/release/fixit_crunch.
*** Error code 1
I have committed a fix for this to src/bin/ed/ a few minutes ago.
Hmm. But I got the same error during last release building (this night).
The make -j buildworld is currently broken by the recent changes
to kerberos5/, and the issue is being worked out. The breakage is
mostly visible in the 4.x doing the build of 5.x case, because
the latter has /usr/include/roken.h and hides the building bug.
At the moment, I'm retesting the snapshot build of 5.x on my 4.x
SMP box without -j. I will follow up with what I get.
Yes, I can see the breakage:
: crunchide -k _crunched_vi_stub vi.lo
: echo int _crunched_chown_stub(int argc, char **argv, char **envp){return main(a
: rgc,argv,envp);} chown_stub.c
: cc -Os -pipe -c chown_stub.c
: ld -dc -r -o chown.lo chown_stub.o /usr/obj//usr/src/usr.sbin/chown/chown.o
: crunchide -k _crunched_chown_stub chown.lo
: echo int _crunched_chroot_stub(int argc, char **argv, char **envp){return main(
: argc,argv,envp);} chroot_stub.c
: cc -Os -pipe -c chroot_stub.c
: ld -dc -r -o chroot.lo chroot_stub.o /usr/obj//usr/src/usr.sbin/chroot/chroot.o
: crunchide -k _crunched_chroot_stub chroot.lo
: cc -static -o fixit_crunch fixit_crunch.o cat.lo chmod.lo cp.lo dd.lo df.lo echo
: .lo expr.lo kill.lo ln.lo ls.lo mkdir.lo mv.lo rm.lo rmdir.lo sleep.lo sync.lo b
: sdlabel.lo clri.lo dmesg.lo fdisk.lo mknod.lo mount.lo mount_cd9660.lo mount_msd
: osfs.lo reboot.lo restore.lo swapon.lo umount.lo ftp.lo telnet.lo vi.lo chown.lo
: chroot.lo -ledit -lgeom -lkvm -lm -lncurses -lutil
: telnet.lo: In function `display':
: telnet.lo(.text+0x122e): undefined reference to `EncryptStatus'
: telnet.lo: In function `status':
: telnet.lo(.text+0x1e85): undefined reference to `encrypt_display'
: ...
:
: telnet.lo(.data+0xaa0): undefined reference to `EncryptStatus'
: *** Error code 1
:
: Stop in /usr/obj/usr/src/release/fixit_crunch.
: *** Error code 1
:
: Stop in /usr/src/release.
I believe Mark has committed a fix for this today (commit log
is attached).
Cheers,
--
Ruslan Ermilov Sysadmin and DBA,
[EMAIL PROTECTED] Sunbay Software Ltd,
[EMAIL PROTECTED] FreeBSD committer
---BeginMessage---
markm 2003/07/20 16:29:46 PDT
FreeBSD src repository
Modified files:
lib/libtelnetMakefile
libexec/telnetd Makefile
usr.bin/telnet Makefile
Log:
Test correct macro for without crypto option(s).
Revision ChangesPath
1.16 +1 -1 src/lib/libtelnet/Makefile
1.21 +1 -1 src/libexec/telnetd/Makefile
1.23 +1 -1 src/usr.bin/telnet/Makefile
---End Message---
pgp0.pgp
Description: PGP signature
i386 'make release' broken
Just got the following from a 'make release BUILDNAME=5.1-CURRENT CHROOTDIR=/usr/release CVSROOT=/usr/ncvs NOPORTS= NODOC= . My world was up to date to within a day. The full log is at http://people.freebsd.org/~scottl/current-release-i386.log.gz. Note that while this is an SMP machine, -j was not used. Also, this problem did not stop the previous 'buildworld' from completing. I haven't tried to build a release in a few weeks, so I can't quickly say when the breakage started. cc -O -pipe -mcpu=pentiumpro-Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wbad-function-cast -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /usr/src/bin/ed/re.c /usr/src/bin/ed/re.c: In function `get_compiled_pattern': /usr/src/bin/ed/re.c:44: warning: declaration of `exp' shadows a global declaration built-in:0: warning: shadowed declaration is here *** Error code 1 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: i386 'make release' broken
On Sun, Jul 20, 2003 at 02:18:42AM -0600, Scott Long wrote: Just got the following from a 'make release BUILDNAME=5.1-CURRENT CHROOTDIR=/usr/release CVSROOT=/usr/ncvs NOPORTS= NODOC= . My world was up to date to within a day. The full log is at http://people.freebsd.org/~scottl/current-release-i386.log.gz. Note that while this is an SMP machine, -j was not used. Also, this problem did not stop the previous 'buildworld' from completing. I haven't tried to build a release in a few weeks, so I can't quickly say when the breakage started. cc -O -pipe -mcpu=pentiumpro-Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wbad-function-cast -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /usr/src/bin/ed/re.c /usr/src/bin/ed/re.c: In function `get_compiled_pattern': /usr/src/bin/ed/re.c:44: warning: declaration of `exp' shadows a global declaration built-in:0: warning: shadowed declaration is here *** Error code 1 Marius Strobl has submitted a fix for this (privately to me and Alexander) a week ago. I have just committed it. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
make release of CURRENT on 4.7 broken again ?
Hi,
A few days ago I've noticed such messages in CURRENT buildlog (on 4.7
box, building without -jsomething) :
cc -Os -pipe -c chown_stub.c
ld -dc -r -o chown.lo chown_stub.o /usr/obj//usr/src/usr.sbin/chown/chown.o
crunchide -k _crunched_chown_stub chown.lo
echo int _crunched_chroot_stub(int argc, char **argv, char **envp){return
main(argc,argv,envp);} chroot_stub.c
cc -Os -pipe -c chroot_stub.c
ld -dc -r -o chroot.lo chroot_stub.o /usr/obj//usr/src/usr.sbin/chroot/chroot.o
crunchide -k _crunched_chroot_stub chroot.lo
cc -static -o fixit_crunch fixit_crunch.o cat.lo chmod.lo cp.lo dd.lo df.lo echo.lo
expr.lo kill.lo ln.lo ls.lo mkdir.lo mv.lo rm.lo rmdir.lo sleep.lo sync.lo bsdlabel.lo
clri.lo dmesg.lo fdisk.lo mknod.lo mount.lo mount_cd9660.lo mount_msdosfs.lo reboot.lo
restore.lo swapon.lo umount.lo ftp.lo telnet.lo vi.lo chown.lo chroot.lo -ledit -lgeom
-lkvm -lm -lncurses
-lutil
*** Error code 1
Stop in /usr/obj/usr/src/release/fixit_crunch.
*** Error code 1
Stop in /usr/src/release.
*** Error code 1
Stop in /usr/src/release.
Did anyone who build CURRENT on 4.x notice the same ? Last release of CURRENT
on my box was successfully builded on July, 16 (with CVSCMDARGS=2003-07-16 00:00).
Thanks in advance.
--
Andrey Elperin
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make release of CURRENT on 4.7 broken again ?
On Sun, Jul 20, 2003 at 02:04:28PM +0300, Andrey Elperin wrote:
Hi,
A few days ago I've noticed such messages in CURRENT buildlog (on 4.7
box, building without -jsomething) :
cc -Os -pipe -c chown_stub.c
ld -dc -r -o chown.lo chown_stub.o /usr/obj//usr/src/usr.sbin/chown/chown.o
crunchide -k _crunched_chown_stub chown.lo
echo int _crunched_chroot_stub(int argc, char **argv, char **envp){return
main(argc,argv,envp);} chroot_stub.c
cc -Os -pipe -c chroot_stub.c
ld -dc -r -o chroot.lo chroot_stub.o /usr/obj//usr/src/usr.sbin/chroot/chroot.o
crunchide -k _crunched_chroot_stub chroot.lo
cc -static -o fixit_crunch fixit_crunch.o cat.lo chmod.lo cp.lo dd.lo df.lo echo.lo
expr.lo kill.lo ln.lo ls.lo mkdir.lo mv.lo rm.lo rmdir.lo sleep.lo sync.lo
bsdlabel.lo clri.lo dmesg.lo fdisk.lo mknod.lo mount.lo mount_cd9660.lo
mount_msdosfs.lo reboot.lo restore.lo swapon.lo umount.lo ftp.lo telnet.lo vi.lo
chown.lo chroot.lo -ledit -lgeom -lkvm -lm -lncurses
-lutil
*** Error code 1
Stop in /usr/obj/usr/src/release/fixit_crunch.
*** Error code 1
I have committed a fix for this to src/bin/ed/ a few minutes ago.
Cheers,
--
Ruslan Ermilov Sysadmin and DBA,
[EMAIL PROTECTED] Sunbay Software Ltd,
[EMAIL PROTECTED] FreeBSD committer
pgp0.pgp
Description: PGP signature
