Re: [oi-dev] Distribution build system requirements?
I won't get to it until summer as at the moment outdoor work here is tolerable, but I plan to go over the entire issue of disk labeling and partitioning. There are a huge number of what are retrospectively poor decisions and ancient cruft that needs to be addressed in format(1m). On consideration, I think gparted should go away and the functionality moved to format(1m). Of course, that presumes that the OI/Illumos community are still comfortable with command line tools and do not require a GUI. I just bought an HP Z840 and will be spending the next month or so configuring it to build Illumos and OI in preparation for doing a modest amount of serious work on things that annoy me. I'm not so old as to have dealt with SMD drives, but I had lots of experience with the disk geometry and remember format(1m) responding to a 5400 rpm speed with a "preposterous" error message. I need to do a *lot* of reading about how modern drives behave with respect to alignment. At present it appears to me that we have lie stacked upon lie stacked upon lie. It's time for a bit of truth. Have Fun! Reg On Wednesday, April 14, 2021, 06:36:20 PM CDT, Gordon Ross wrote: If anyone gets around to working on gparted (or an alternative) please consider making it use "megabyte aligned partitions" and ignore so-called "geometry" (like partition editors do on pretty much every other OS does now). On Tue, Apr 13, 2021 at 9:02 AM Reginald Beardsley via oi-dev wrote: > > On Tuesday, April 13, 2021, 05:19:05 AM CDT, Aurélien Larcher > wrote: > > [snip] > > I know gparted is not great... I attempted to port our patchset to newer > versions a long time ago but it was too much work... > > > > The issue is gparted dumps core on the 2020.10 Live Image. It works on the > 2017.10 Live Image and the 2020.10 installed system. I'm going to look very > closely at format as I think it might serve for EFI/GPT labels more sensibly. > I can see no reason for having 128 partitions. And I did manage to get a > traditional Sun partition table with 9 slots and an EFI label on a 5 TB disk. > IIRC I had to format it in Win 7 and then relabel it with format(1m). > > I just bought an HP Z840 with 1x 14 core E5-2690 V4 on ebay. I need to add 64 > GB of DRAM which may be a bit of a hassle because of the global chip > shortage. I'm planning on 4x 4 TB disks in RAIDZ2 configuration. A single > slice if booting a RAIDZ2 pool with a disk missing is reliable. > > Have Fun! > Reg > ___ > oi-dev mailing list > oi-dev@openindiana.org > https://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Distribution build system requirements?
If anyone gets around to working on gparted (or an alternative) please consider making it use "megabyte aligned partitions" and ignore so-called "geometry" (like partition editors do on pretty much every other OS does now). On Tue, Apr 13, 2021 at 9:02 AM Reginald Beardsley via oi-dev wrote: > > On Tuesday, April 13, 2021, 05:19:05 AM CDT, Aurélien Larcher > wrote: > > [snip] > > I know gparted is not great... I attempted to port our patchset to newer > versions a long time ago but it was too much work... > > > > The issue is gparted dumps core on the 2020.10 Live Image. It works on the > 2017.10 Live Image and the 2020.10 installed system. I'm going to look very > closely at format as I think it might serve for EFI/GPT labels more sensibly. > I can see no reason for having 128 partitions. And I did manage to get a > traditional Sun partition table with 9 slots and an EFI label on a 5 TB disk. > IIRC I had to format it in Win 7 and then relabel it with format(1m). > > I just bought an HP Z840 with 1x 14 core E5-2690 V4 on ebay. I need to add 64 > GB of DRAM which may be a bit of a hassle because of the global chip > shortage. I'm planning on 4x 4 TB disks in RAIDZ2 configuration. A single > slice if booting a RAIDZ2 pool with a disk missing is reliable. > > Have Fun! > Reg > ___ > oi-dev mailing list > oi-dev@openindiana.org > https://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Variable PATH in Makefile (tornado)
On Wed, Apr 14, 2021 at 12:40:17PM +0200, Nona Hansel wrote: > >I'm having some problems updating tornado. Currently, the PATH variable >in Makefile is defined in the older mode like this: > >PATH=/usr/bin:/usr/gnu/bin:/usr/sbin > >Like this, tornado builds, installs and publishes fine. > >When I change it to the newer mode: > >PATH=$(PATH.gnu) >It builds fine, but fails during gmake install with this message: The order of directories in the search path only matters if the commands have the same name, because the first one is found. `sed' does exist in both /usr/bin and /usr/gnu/bin, for example. `gsed', however, only exists in /usr/bin . Of course, a missing directory in the path will matter, because the command will not be found. Some Makefiles use `env -i', which deletes all environment variables, including useful ones like PATH . In that case, you need to reinstate PATH . -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Variable PATH in Makefile (tornado)
Thank you, PATH=$(PATH.illumos) worked! -- Původní e-mail -- Od: Andreas Wacknitz Komu: oi-dev@openindiana.org Datum: 14. 4. 2021 13:19:36 Předmět: Re: [oi-dev] Variable PATH in Makefile (tornado) "Am 14.04.21 um 12:40 schrieb Nona Hansel: > Hello, > > I'm having some problems updating tornado. Currently, the PATH > variable in Makefile is defined in the older mode like this: > PATH=/usr/bin:/usr/gnu/bin:/usr/sbin > Like this, tornado builds, installs and publishes fine. > The old settings prefer / priorize our own tools over the GNU ones because /usr/bin comes before /usr/gnu/bin. When you look in make-rules for the definitions of PATH.gnu and PATH.illumos then you will see that PATH.illumos does something similar. It priorizes our tools over the GNU tools, but nevertheless it also includes the GNU binaries path. So I would expect that the right thing to do would be to use PATH=$(PATH.illumos) here. Andreas ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev "___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Variable PATH in Makefile (tornado)
Am 14.04.21 um 12:40 schrieb Nona Hansel: Hello, I'm having some problems updating tornado. Currently, the PATH variable in Makefile is defined in the older mode like this: PATH=/usr/bin:/usr/gnu/bin:/usr/sbin Like this, tornado builds, installs and publishes fine. The old settings prefer / priorize our own tools over the GNU ones because /usr/bin comes before /usr/gnu/bin. When you look in make-rules for the definitions of PATH.gnu and PATH.illumos then you will see that PATH.illumos does something similar. It priorizes our tools over the GNU tools, but nevertheless it also includes the GNU binaries path. So I would expect that the right thing to do would be to use PATH=$(PATH.illumos) here. Andreas ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Variable PATH in Makefile (tornado)
Am 14.04.21 12:40 schrieb Nona Hansel :
>
>
>
>
>
>
> Hello,
>
> I'm having some problems updating tornado. Currently, the PATH variable in
> Makefile is defined in the older mode like this:
> PATH=/usr/bin:/usr/gnu/bin:/usr/sbin
> Like this, tornado builds, installs and publishes fine.
>
>
> When I change it to the newer mode:
> PATH=$(PATH.gnu)
> It builds fine, but fails during gmake install with this message:
>
> Copying tornado.egg-info to
> /export/home/nona/oi-userland/components/python/tornado/build/prototype/i386/usr/lib/python2.7/vendor-packages/tornado-5.1.1-py2.7.egg-info
>
> running install_scripts
> gfind
> /export/home/nona/oi-userland/components/python/tornado/build/prototype/i386/usr/lib/python2.7/vendor-packages
> -type f -exec gawk '/^#!.*python/{print FILENAME}{nextfile}' {} + | xargs
> gsed -i -e '1 s;^.*$;#!/usr/bin/python2.7;'
> gsed: no input files
> gmake: *** [/export/home/nona/oi-userland/make-rules/setup.py.mk:113:
> /export/home/nona/oi-userland/components/python/tornado/build/i86-2.7/.installed]
> Error 123
>
>
> Do you have any idea why it doesn't work? How can I fix it?
> Thank you!
> Best regards,
> Nona
>
>
>
>
> ___
> oi-dev mailing list
> oi-dev@openindiana.org
> https://openindiana.org/mailman/listinfo/oi-dev
>
>
This is the contents of PATH.gnu:
PATH.gnu =
$(PATH.prepend):$(GNUBIN):$(USRBINDIR$(BITS)):$(USRBINDIR):$(USRSBINDIR$(BITS)):$(USRSBINDIR):$(PERL5BINDIR)
I think the sequence is important or the problem.
--
Carsten
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] Variable PATH in Makefile (tornado)
Hello,
I'm having some problems updating tornado. Currently, the PATH variable in
Makefile is defined in the older mode like this:
PATH=/usr/bin:/usr/gnu/bin:/usr/sbin
Like this, tornado builds, installs and publishes fine.
When I change it to the newer mode:
PATH=$(PATH.gnu)
It builds fine, but fails during gmake install with this message:
Copying tornado.egg-info to /export/home/nona/oi-userland/components/python/
tornado/build/prototype/i386/usr/lib/python2.7/vendor-packages/tornado-5.1.1
-py2.7.egg-info
running install_scripts
gfind /export/home/nona/oi-userland/components/python/tornado/build/
prototype/i386/usr/lib/python2.7/vendor-packages -type f -exec gawk '/^#!.*
python/{print FILENAME}{nextfile}' {} + | xargs gsed -i -e '1 s;^.*$;#!/usr/
bin/python2.7;'
gsed: no input files
gmake: *** [/export/home/nona/oi-userland/make-rules/setup.py.mk:113: /
export/home/nona/oi-userland/components/python/tornado/build/i86-2.7/.
installed] Error 123
Do you have any idea why it doesn't work? How can I fix it?
Thank you!
Best regards,
Nona
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev
