[oi-dev] HEADS-UP: OpenIndiana pkg update to Python 3.9 needs illumos environment changes

[Richard Lowe]

Due to the update to pkg to use Python 3.9 in OpenIndiana, your illumos
builds _must_ produce a libbe-39 package.
This means your build must be set up such that PYTHON3_VERSION or
PYTHON3b_VERSION are 3.9:

export PYTHON3b_VERSION=3.9
export PYTHON3b_SUFFIX=
export PYTHON3b_PKGVERS=-39

A future change to illumos will make this the default PYTHON3_VERSION.

-- Rich
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Removal of python 3.5 from OI

[Richard Lowe]

Note that I'm not done migrating pkg yet, there are several more steps to
doing it cleanly.

-- Rich

On Sun, May 8, 2022, 14:49 Gary Mills  wrote:

> I've attached a file of affected directories to this message.  It's a
> list of directories with a Makefile that contain "runtime/python-35".
> Note that it's not a list of packages.  All that it implies is that
> the directory contains at least one package that requires python 3.5 .
>
> Some Makefiles iterate over python versions to create "-35" packages,
> along with other packages.  In that case, it's usually only necessary
> to obsolete the "-35" package and to remove all references to python
> 3.5 .  Other Makefiles specify only a single python version.  If that
> is so, the software can usually be upgraded to python 3.7 or 3.9 .
>
> The trick is to obsolete packages in such a way as to avoid affecting
> users.  Packages using python 3.5 that are not required by other
> packages can be obsoleted at any time.  In the case of python 3.5
> scripts, the easiest thing is to upgrade first, to a newer python
> version, and work down the dependency tree from there.
>
> Note that there has been no official announcement of the removal of
> python 3.5 from OI yet.  However, python 2.7 has already mostly been
> eliminated from OI.
>
>
> --
> -Gary Mills--refurb--Winnipeg, Manitoba,
> Canada-
> ___
> 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] The end of python-27

[Richard Lowe]

IPS (used to?) depend on this, and has lingering references to xml2po too.

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] libxml2 mapfile and symbol removal

[Richard Lowe]

If they were public they really should stick around. I have no idea how
best you could do that though.  Did the soname change so both versions
could be shipped?

-- Rich

On Sat, Nov 13, 2021, 22:25 Tim Mooney via oi-dev 
wrote:

>
> All-
>
> I'm investigating how difficult it might be to update libxml2 and libxslt
> to current latest versions.
>
> Unfortunately, libxml2 removed a bunch of formerly public symbols at
> version 2.9.10:
>
> # emptyExp; removed in 2.9.10
> # forbiddenExp; removed in 2.9.10
> # xmlExpCtxtNbCons; removed in 2.9.10
> # xmlExpCtxtNbNodes; removed in 2.9.10
> # xmlExpDump; removed in 2.9.10
> # xmlExpExpDerive; removed in 2.9.10
> # xmlExpFreeCtxt; removed in 2.9.10
> # xmlExpFree; removed in 2.9.10
> # xmlExpGetLanguage; removed in 2.9.10
> # xmlExpGetStart; removed in 2.9.10
> # xmlExpIsNillable; removed in 2.9.10
> # xmlExpMaxToken; removed in 2.9.10
> # xmlExpNewAtom; removed in 2.9.10
> # xmlExpNewCtxt; removed in 2.9.10
> # xmlExpNewOr; removed in 2.9.10
> # xmlExpNewRange; removed in 2.9.10
> # xmlExpNewSeq; removed in 2.9.10
> # xmlExpParse; removed in 2.9.10
> # xmlExpRef; removed in 2.9.10
> # xmlExpStringDerive; removed in 2.9.10
> # xmlExpSubsume; removed in 2.9.10
>
> At a minimum, that likely means that nearly everything that depends
> upon libxml2 will need a rebuild.
>
> My question is about what should be done to the mapfile we use with
> libxml2.  Most of these symbols are marked "global" at
>
> SYMBOL_VERSION SUNW_1.6 {
>
> Do I just comment them out of that block, or is there some other better
> way to handle these now-removed symbols?
>
> Tim
> --
> Tim Mooney tim.moo...@ndsu.edu
> Enterprise Computing & Infrastructure /
> Division of Information Technology/701-231-1076 (Voice)
> North Dakota State University, Fargo, ND 58105-5164
>
> ___
> 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] mapfile and RESERVE_SEGMENT or CAPABILITY

[Richard Lowe]

Ok yeah.  What seems to be happening is that we don't let you put a
mapping over the va hole (which I guess Oracle is smart about), and
obviously also don't let you put a mapping past userlimit.
So you'd need one segment that covers up as far as the va hole (which
is fine), and another bit that covers up from the end of the hole
until userlimit (which you can't do).  I'd guess Oracle did things
more thoroughly properly in their mapfile v2 changes.

Moving userlimit seems fine to me, I hope illumos does it (especially
if y'all already have).  We already (used to) set the limit that way
when running under xen.

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] mapfile and RESERVE_SEGMENT or CAPABILITY

[Richard Lowe]

the memsz there is waayyy too big.

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] mapfile and RESERVE_SEGMENT or CAPABILITY

[Richard Lowe]

It's been so long I honestly don't remember right now, but it or V look
right (ignoring the documentation, for now).  You should be able to check
it was created using elfdump -p

-- Rich

On Mon, Aug 9, 2021, 01:34 Carsten Grzemba via oi-dev <
oi-dev@openindiana.org> wrote:

>
>
> Am 08.08.21 23:46 schrieb *Richard Lowe * :
>
> We haven't added RESERVE_SEGMENT yet, though it would be fairly easy to do
> I think.
> You can do the same thing in the v1 syntax though, using the ?E flag to
> say it's empty.
>
> --
>
> I try to translate the mapfile version 2 to version 1
> version 2;
>
> RESERVE_SEGMENT spidermonkey_reserve {
> VADDR = 0x8000;
> SIZE = 0x7fff;
>  };
>
> Is the following correct in version = 1?
>
> spidermonkey_reserve = LOAD A0x8000 L0x7fff ?E;
>
> The documentation mentions virtual_address (V) is not usabel for userland
> bins but alligment (A) seems to have an other meaning here.
> I am wrong?
> --
> Carsten
> ___
> 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] mapfile and RESERVE_SEGMENT or CAPABILITY

[Richard Lowe]

We haven't added RESERVE_SEGMENT yet, though it would be fairly easy to do
I think.
You can do the same thing in the v1 syntax though, using the ?E flag to say
it's empty.
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] What is the equivalent of COMPONENT_REVISION for pkg5?

[Richard Lowe]

The versions get set by the pkg5 build process, you shouldn't need to
do anything.  If you need to do it for your own testing, it's the
PKGVERS variable in src/pkg/Makefile

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Download error for dlc.openindiana.org

[Richard Lowe]

Something seems wrong with the DLC host.  And, more annoying for you,
the upstream seems to have deleted or moved that source so the build
was falling back to DLC.

A workaround would be to find an alternate source for the
cracklib-2.9.6 tarball.

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI Hipster 2019.04

[Richard Lowe]

I think that's me not-remembering whether doing that with entire would
do the right thing, did you try specifying @latest for all the
incorporations in the original error?

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI Hipster 2019.04

[Richard Lowe]

> Dependency analysis is unable to determine the cause.
> Try specifying expected versions to obtain more detailed error messages.
>

Do what it says there,

Specify the verisons of those 'latest incorporations', and probably
also entire, including the versions.

You may be able to just do 'pkg install -nv entire@latest' but I can
never remember whether only specifying 'entire' does the right thing.

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Am I stuck?

[Richard Lowe]

Reason:  No version for 'require' dependency on system/mta can be found

Seems a leaf failure, does one really not exist?

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] [developer] [Samba] gencache.tdb: device busy

[Richard Lowe]

You could check whether the mutex already looks initialized to us using a
debugger or logging statements added to the code.

If that's the case, we can think again about relaxing the check I added in
9959.



On Sun, Apr 21, 2019, 08:20 Rouven WEILER  wrote:

> Any chance to get to know what happens?
>
> Am 21.04.2019 um 14:12 schrieb Richard Lowe :
>
> It's possible there's a bug.  It's also possible you're getting really
> unlucky and the uninitialized mutex looks valid because the magic is valid.
>
> On Sun, Apr 21, 2019, 06:10 Rouven WEILER  wrote:
>
>> Dear all,
>>
>> trying to make samba work and getting rid of my error message
>>
>> [2019/04/01 09:51:41.112485,  0] 
>> ../../lib/tdb_wrap/tdb_wrap.c:64(tdb_wrap_log)
>>  tdb(/var/samba/lock/gencache.tdb): tdb_open_ex: tdb_mutex_init failed for 
>> /var/samba/lock/gencache.tdb: Device busy
>>
>>
>> I followed the info of Youzhong. It definitely works. So thankx.
>> BUT: The OS (OpenIndiana; state of April,19th) is patched against the
>> illumos issue 9959
>>
>> So there might be some mechanism (maybe MUTEX_MAGIC) that avoids the
>> initialization of the mutex before init.
>> I am really not deep in all that pthread stuff…
>>
>> Is there the possiblity that there is a bug in the code base of issue
>> 9959?
>>
>>
>> Best regards
>>
>> Rouven
>>
>>
>> Am 18.04.2019 um 19:20 schrieb Robert Mustacchi :
>>
>> On 4/18/19 10:12 , Youzhong Yang wrote:
>>
>> Little bit confused. The page  https://www.openindiana.org/download/
>> shows
>> latest ISO is dated 2018.10, but 9959 fix was submitted on 11/26/2018, I
>> guess Hipster doesn't have it.
>>
>>
>> The ISO is just the install image. Generally, after using that to
>> bootstrap, then folks will update to latest bits via IPS. As a result,
>> the ISO isn't updated (and generally doesn't have to be) quite as often.
>>
>> Robert
>>
>> On Thu, Apr 18, 2019 at 12:38 PM Rouven WEILER 
>> wrote:
>>
>> On my system the issue is solved and the sources are patched accordingly.
>> Thus, the issue seems to be somewhere else.
>>
>> Am 18.04.2019 um 18:27 schrieb Rouven WEILER :
>>
>> concerning openindiana I am using the most recent one. I right now asked
>> if the issue is solved in the latest version.
>>
>> another interesting thing is that older samba versions do not throw EBUSY,
>> although on the same underlying system.
>>
>>
>>
>> Am 18.04.2019 um 18:07 schrieb Youzhong Yang :
>>
>> That is interesting. I am curious about how pthread_mutexattr_init ends up
>> returning EBUSY. What verison of Openindiana are you running? is there a
>> link pointing to the fix that it has for 9959?
>>
>> On Thu, Apr 18, 2019 at 11:53 AM Rouven WEILER 
>> wrote:
>>
>> I understand and see that it works, but as written below
>> pthread_mutexattr_init throws EBUSY, not pthread_mutex_init.
>>
>> Also Openindiana seems to include the patch for issue 9959 mentioned. I
>> will clarify that to make sure.
>>
>> I just want to make sure that the patch you suggest aims for the issue
>> and is not a workaround.
>>
>>
>> Am 18.04.2019 um 16:09 schrieb Youzhong Yang :
>>
>> I reproduced the issue on a smartos version which does not have the fix
>> for  https://www.illumos.org/issues/9959.
>>
>> The pthread_mutex_init() at line 590 returns EBUSY:
>> ret = pthread_mutex_init(chain, );
>>
>>
>> https://git.samba.org/?p=samba.git;a=blob;f=lib/tdb/common/mutex.c;h=8a122d5d6a2ec321bce25cf06062acc808f1e126;hb=HEAD#l590
>>
>>
>> Then I applied the following patch to lib/tdb/common/mutex.c:
>>
>> # git grep -B 1 -n pthread_mutex_init lib/tdb/common/mutex.c
>> lib/tdb/common/mutex.c-590- bzero(chain,
>> sizeof(pthread_mutex_t));
>> lib/tdb/common/mutex.c:591: ret = pthread_mutex_init(chain,
>> );
>> --
>> lib/tdb/common/mutex.c-599- bzero(>allrecord_mutex,
>> sizeof(pthread_mutex_t));
>> lib/tdb/common/mutex.c:600: ret =
>> pthread_mutex_init(>allrecord_mutex, );
>> --
>> lib/tdb/common/mutex.c-693- bzero(, sizeof(pthread_mutex_t));
>> lib/tdb/common/mutex.c:694: ret = pthread_mutex_init(, );
>> --
>> lib/tdb/common/mutex.c-891- bzero(ptr, sizeof(pthread_mutex_t));
>> lib/tdb/common/mutex.c:892: ret = pthread_mutex_init(ptr, );
>>
>> It works like a charm. Fair enough?
>>
>> So again I recommend either of the f

Re: [oi-dev] [developer] [Samba] gencache.tdb: device busy

[Richard Lowe]

It's possible there's a bug.  It's also possible you're getting really
unlucky and the uninitialized mutex looks valid because the magic is valid.

On Sun, Apr 21, 2019, 06:10 Rouven WEILER  wrote:

> Dear all,
>
> trying to make samba work and getting rid of my error message
>
> [2019/04/01 09:51:41.112485,  0] 
> ../../lib/tdb_wrap/tdb_wrap.c:64(tdb_wrap_log)
>  tdb(/var/samba/lock/gencache.tdb): tdb_open_ex: tdb_mutex_init failed for 
> /var/samba/lock/gencache.tdb: Device busy
>
>
> I followed the info of Youzhong. It definitely works. So thankx.
> BUT: The OS (OpenIndiana; state of April,19th) is patched against the
> illumos issue 9959
>
> So there might be some mechanism (maybe MUTEX_MAGIC) that avoids the
> initialization of the mutex before init.
> I am really not deep in all that pthread stuff…
>
> Is there the possiblity that there is a bug in the code base of issue 9959?
>
>
> Best regards
>
> Rouven
>
>
> Am 18.04.2019 um 19:20 schrieb Robert Mustacchi :
>
> On 4/18/19 10:12 , Youzhong Yang wrote:
>
> Little bit confused. The page  https://www.openindiana.org/download/ shows
> latest ISO is dated 2018.10, but 9959 fix was submitted on 11/26/2018, I
> guess Hipster doesn't have it.
>
>
> The ISO is just the install image. Generally, after using that to
> bootstrap, then folks will update to latest bits via IPS. As a result,
> the ISO isn't updated (and generally doesn't have to be) quite as often.
>
> Robert
>
> On Thu, Apr 18, 2019 at 12:38 PM Rouven WEILER 
> wrote:
>
> On my system the issue is solved and the sources are patched accordingly.
> Thus, the issue seems to be somewhere else.
>
> Am 18.04.2019 um 18:27 schrieb Rouven WEILER :
>
> concerning openindiana I am using the most recent one. I right now asked
> if the issue is solved in the latest version.
>
> another interesting thing is that older samba versions do not throw EBUSY,
> although on the same underlying system.
>
>
>
> Am 18.04.2019 um 18:07 schrieb Youzhong Yang :
>
> That is interesting. I am curious about how pthread_mutexattr_init ends up
> returning EBUSY. What verison of Openindiana are you running? is there a
> link pointing to the fix that it has for 9959?
>
> On Thu, Apr 18, 2019 at 11:53 AM Rouven WEILER 
> wrote:
>
> I understand and see that it works, but as written below
> pthread_mutexattr_init throws EBUSY, not pthread_mutex_init.
>
> Also Openindiana seems to include the patch for issue 9959 mentioned. I
> will clarify that to make sure.
>
> I just want to make sure that the patch you suggest aims for the issue
> and is not a workaround.
>
>
> Am 18.04.2019 um 16:09 schrieb Youzhong Yang :
>
> I reproduced the issue on a smartos version which does not have the fix
> for  https://www.illumos.org/issues/9959.
>
> The pthread_mutex_init() at line 590 returns EBUSY:
> ret = pthread_mutex_init(chain, );
>
>
> https://git.samba.org/?p=samba.git;a=blob;f=lib/tdb/common/mutex.c;h=8a122d5d6a2ec321bce25cf06062acc808f1e126;hb=HEAD#l590
>
>
> Then I applied the following patch to lib/tdb/common/mutex.c:
>
> # git grep -B 1 -n pthread_mutex_init lib/tdb/common/mutex.c
> lib/tdb/common/mutex.c-590- bzero(chain,
> sizeof(pthread_mutex_t));
> lib/tdb/common/mutex.c:591: ret = pthread_mutex_init(chain,
> );
> --
> lib/tdb/common/mutex.c-599- bzero(>allrecord_mutex,
> sizeof(pthread_mutex_t));
> lib/tdb/common/mutex.c:600: ret =
> pthread_mutex_init(>allrecord_mutex, );
> --
> lib/tdb/common/mutex.c-693- bzero(, sizeof(pthread_mutex_t));
> lib/tdb/common/mutex.c:694: ret = pthread_mutex_init(, );
> --
> lib/tdb/common/mutex.c-891- bzero(ptr, sizeof(pthread_mutex_t));
> lib/tdb/common/mutex.c:892: ret = pthread_mutex_init(ptr, );
>
> It works like a charm. Fair enough?
>
> So again I recommend either of the following two:
> - apply 9959 fix to your OS image, or use a newer version which has 9959
> fix
> - bzero pthread_mutex_t struct before calling pthread_mutex_init().
>
> In my environment I applied bzero patch to all pthread_mutex_init() calls
> in the entire samba code base, you know, who knows what is going to happen.
>
>
>
> On Thu, Apr 18, 2019 at 4:29 AM Rouven WEILER 
> wrote:
>
> That sounds reasonable!
> Could you help me to dtrace that in a feasible way? Up to now I am not
> used to dtrace. Except knowing what is and that its powerful.
>
> Am 18.04.2019 um 09:29 schrieb Jason King :
>
> It appears that the robust mutexes are mmapped from the .tdb file.
> EBUSY means that the mutex has already been intialized.  It also appears
> that if the TDB_CLEAR_IF_FIRST flag is _not_ set when opening the tdb, it
> will try to initialize the mutexes.  I’m wondering if the tdb file gets
> created, the memory image of the initialized mutexes is getting saved, then
> when it’s opened again, if that flag is not set, it tries to re-initialize
> the mutexes and fails (because they are already constructed) legitimately
> returning EBUSY.  If the samba code is in fact trying to 

Re: [oi-dev] Build of gcc-7.3.0 stops with linker errors

[Richard Lowe]

On Sat, May 26, 2018 at 12:26 PM Gary Mills  wrote:

> On Sat, May 26, 2018 at 03:32:55PM +0300, Igor Kozhukhov wrote:
> >
> > we have tried to do some research for GNU AS replacement with
> > illumos build on SPARC - but GNU binutils (GAS) should be updated a
> little.
> > i have filed som bugs and they was resolved, but not at all.
>
> Are you saying that gas for SPARC is not a general-purpose assembler,
> that it's only designed to handle the output from the compiler?
>

That's not the case.

Though, for what it's worth, using the assembler through the compiler
front-end would simplify things a lot (though you'd have to rename any
files that needed the preprocessor .S rather than .s).

-- Rich
-- 

-- Rich
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Build of gcc-7.3.0 stops with linker errors

[Richard Lowe]

They're not different enough to be more than theoretically mechanical
changes, but are (just) different enough you may not be able to _actually_
do it all mechanically.

Assembler being much more rigid, you'll have an easier time comparing the
outputs to make sure you're doing the same things -- and of course, you
having a SPARC to test really helps.

-- Rich
-- 

-- Rich
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Build of gcc-7.3.0 stops with linker errors

[Richard Lowe]

I would not be surprised, if enabling crt*S is still an illumos patch, if
that patch was not somehow wrong.  I don't have a SPARC to actually check
it.

On Sat, May 19, 2018 at 6:22 PM Aurélien Larcher 
wrote:

> On Sun, May 20, 2018 at 12:19 AM, Gary Mills 
> wrote:
>
>> On Sat, May 19, 2018 at 10:47:05PM +0200, Aurélien Larcher wrote:
>> >
>> >Are you sure there is no crtbeginS.o at all in the directory?
>>
>> Quite sure:
>>
>> $ find build -name 'crt*.o' -ls
>> 227005892 -rw-r--r--   1 millsstaff1416 May 19 10:40
>> build/sparcv7/gcc/sparcv9/crt1.o
>> 227005874 -rw-r--r--   1 millsstaff3232 May 19 10:40
>> build/sparcv7/gcc/sparcv9/crtbegin.o
>> 227005882 -rw-r--r--   1 millsstaff 952 May 19 10:40
>> build/sparcv7/gcc/sparcv9/crtend.o
>> 227005915 -rw-r--r--   1 millsstaff3928 May 19 10:40
>> build/sparcv7/gcc/sparcv9/crtfastmath.o
>> 227005845 -rw-r--r--   1 millsstaff3928 May 19 10:40
>> build/sparcv7/sparc-sun-solaris2.11/sparcv9/libgcc/crtfastmath.o
>> 227005782 -rw-r--r--   1 millsstaff 952 May 19 10:40
>> build/sparcv7/sparc-sun-solaris2.11/sparcv9/libgcc/crtend.o
>> 227005764 -rw-r--r--   1 millsstaff3232 May 19 10:40
>> build/sparcv7/sparc-sun-solaris2.11/sparcv9/libgcc/crtbegin.o
>> 227005802 -rw-r--r--   1 millsstaff1416 May 19 10:40
>> build/sparcv7/sparc-sun-solaris2.11/sparcv9/libgcc/crt1.o
>>
>> >Should they not be created already from stage-1?
>>
>> That's what I expected.
>>
>> >You should be able to set the ld path to them using boot-ldflags.
>>
>> They don't exist anywhere on the system.
>>
>> >Also I do not remember if multilib is considered as a native build.
>> If
>> >not, you may need to --enable-bootstrap explicitly.
>>
>> Okay, thanks.
>>
>
> Sorry, my memory is a bit shaky on these topics... :S
>
>
>>
>> --
>> -Gary Mills--refurb--Winnipeg, Manitoba,
>> Canada-
>>
>> ___
>> oi-dev mailing list
>> oi-dev@openindiana.org
>> https://openindiana.org/mailman/listinfo/oi-dev
>>
>
> --
> ---
> Praise the Caffeine embeddings
> ___
> oi-dev mailing list
> oi-dev@openindiana.org
> https://openindiana.org/mailman/listinfo/oi-dev

-- 

-- Rich
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] dmake packaging changes

[Richard Lowe]

I'd expect few people to have developer/.../xcu4 installed.  Is that not
the case?
The solution there is the same as with the regular .../make, split the
package (so people can still have the xpg sccs, and have the xpg make in a
separate package which you can obsolete when I integrate.

I really do hate the mess Sun made of packaging some of this stuff :(

On Mon, Jun 29, 2015 at 5:34 PM Alexander Pyhalov a...@rsu.ru wrote:

 Richard Lowe писал 29.06.2015 18:51:
  Hi,
 
  When I integrate dmake into illumos, this is going to cause packaging
  problems
  for anyone who uses IPS and also inherited package names from Sun.
  That's
  you
  guys (and anyone downstream of you, presumably).
 
  The problem is that the package pkg:/developer/build/make, which I am
  delivering, also includes SCCS and as(1), for historical reasons.
 
  You're going to need to split those off into separate packages, I'd
  suggest:
 
pkg:/developer/versioning/sccs
  and
pkg:/developer/as
(or maybe 'assembler' or 'sun-as' or something)

 Hi.
 We are ready. We deliver  developer/versioning/sccs and developer/as.
 Also note that old developer/xopen/xcu4  package has conflicts with new
 make as it delivers usr/xpg4/bin/make.
 We deliver new developer/xopen/xcu4 which depends on sccs and make, but
 this means that latest xcu4 package has conflicts with current make (via
 sccs).
 So if you have developer/xopen/xcu4 installed, you'll have to freeze it
 before pkg update . This is a temporary situation, until new dmake is
 delivered.
 This means we are interested in fast dmake integration.


 ---
 System Administrator of Southern Federal University Computer Center





___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] LD relocation error and GCC visibility

[Richard Lowe]

A _really_ simple test case would be appreciated, I'm not exactly sure
what you'd need to do to create one, though.

___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] [developer] recent nightly changes and other consolidation

[Richard Lowe]

I'm going to ask the obvious question first:

  Why not just fix the warnings in slim_source?

That said, it setting build_extras_ok does seem reasonable.

___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] fix-includes for g++

[Richard Lowe]

What's the big deal about fixing illumos?  Please, if at all possible, do
not ship fix-includes.  It would actually be preferable for you to patch
your illumos tree with whatever fix you want than to do that.

-- Rich


2013/6/3 Andrzej Szeszo asze...@gmail.com

 My cheeky plan was to get someone to fix the headers in illumos itself.

 Alternative is to ignore the issue and include the fixed-includes
 contents in the gcc package.

 Alexander, feel free to add fixed-includes to the gcc package. My
 initial gcc package is getting rid of the directory in the Makefile
 altogether.

 We can look at fixing illumos headers at later time.

 Andrzej

 On 3 June 2013 15:56, Alexander Pyhalov a...@rsu.ru wrote:
  On 06/03/2013 17:46, Alexander Pyhalov wrote:
 
  Hello, everyone...
  Maybe I'm wrong, but, for example, OpenCSW gcc 4.8 package contains a
  big set of fixed includes. Why doesn't our g++ 4.7 package include any?
 
 
  Compare, for example,
 
 http://pkg.omniti.com/omnios/release/manifest/0/developer%2Fgcc47%404.7.2%2C5.11-0.151006%3A20130429T221114Z
  and
 
 http://pkg.openindiana.org/hipster/manifest/0/developer%2Fgcc-47%404.7.3%2C5.11-0.151.1.8.1%3A20130518T182047Z
  .
 
 
  --
  Best regards,
  Alexander Pyhalov,
  system administrator of Computer Center of Southern Federal University
 
  ___
  oi-dev mailing list
  oi-dev@openindiana.org
  http://openindiana.org/mailman/listinfo/oi-dev

 ___
 oi-dev mailing list
 oi-dev@openindiana.org
 http://openindiana.org/mailman/listinfo/oi-dev

___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] (Laptop) Keyboard locking up when in kmdb panic handler

[Richard Lowe]

 Sorry for being unclear.  I was not suggesting you switch to a
 USB keyboard.  I was asking if you were using one already.

There are two reasons this tends to happen:

1) You have a USB keyboard, that we can't actually use from kmdb at all
2) You've crashed at a point where the state of the world is such that
we can't use the keyboard _right now_

If it's failing sporadically, I'd be assuming #2 though #1 is far from
impossible even then.

Are you crashing too early to get a crash dump?  It's nearly always
preferable to get a dump (if you can), than to debug the system
in-situ.

-- Rich

___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] adding aok=1 and set zfs_recover=1 to live CD's /etc/system as well?

[Richard Lowe]

Assertions are a necessary aid to debugging, do not disable them in a
default environment, be in the live CD or post-install environment.

-- Rich

___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] [userland] gcc44 in illumos-userland

[Richard Lowe]

My patches include no runpath tweaks if up-to-date.

When I'm actually definitively done with that gcc tree I intend to tag it,
and you guys can use github as the tarball URL, and not have to deal with
wrangling the basic illumos-y patches.

-- Rich
___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Issues pertaining to gcc (for tomorrow's Developer Meeting)

[Richard Lowe]

 (2) Although illumos-gate can be built with Rich Lowe's gcc, as far as
 I know the decision has not been made to actually use gcc to build it
 for the first stable release of OI.  I would suggest that doing so
 would be a very risky move, because we have so little experience with
 a gcc-built Illumos.  One should be cautious here, and treat a
 gcc-built Illumos as experimental for an extended period of time,
 before actually releasing it to the public.  But if Sun Studio is used
 to build Illumos, what is the advantage of building illumos-userland
 with gcc?  As noted in (1), there is a distinct disadvantage -- that
 it would be harder to keep up with upstream.

illumos-gate builds with gcc3.  You need the changesets I've not yet
integrated for gcc4.

That said, at present the people shipping illumos are building with
either the precisely correct versions of Sun Studio, or building with
gcc4 and shipping something based off of my branch.

It's up to OI whatever they choose to do.


 2. Which versions of gcc should OI/Illumian ship?

 It is a given that illumos-gate must be built with gcc 4.4, because
 porting the patches required to get it to build to later versions of
 gcc is a non-trivial task.

Actually, GCC 3.4 at present, which must be delivered to /usr/sfw as now.

 In case Rich is not able to attend tomorrow's meeting, I'll quote what
 he said on #illumos a few minutes ago: basically, my only view on gcc
 is 'Leave the ones used to build illumos alone, then do whatever you
 want'.

Yes.  As long as you ship 3.4 right now, and are willing to ship a 4.4
(or whatever) when I'm done pushing my branch through, I don't care
about other versions.  Note that failing to ship 3.4 will break the
illumos build on your system, which will annoy a bunch of people
(illumos people).

 3. Which version of gcc should be preferred for building things other
   than illumos-gate?

 Since Rich Lowe's patches are not required to build illumos-gate, if

I'm presuming this is a typo for illumos-userland.  The patched GCC
(either Sun's 3.4, or my 4.4) is utterly necessary for illumos-gate.

 4. Where should the preferred gcc version reside?

 The obvious place is in /usr/bin.  Solaris 11 places symlinks to gcc
 4.5 there.  (OI still places symlinks to gcc 3.4.3 there; it should
 stop doing so as quickly as possible.)

I'd put them all in /usr/gcc/X.Y.Z except for 3.4, which _must_ remain
in /usr/sfw (possibly, it can be symlinked, but I'm not sure).

Symlink the one preferable for end users into /usr.

For automated builds, specify PATH explicitly to pick a constant and
well-known version.


 The gcc build of Illumos is done in such a way that Illumos should not
 be affected by the gcc 4.6 runtime residing in /usr/lib.

We don't use libgcc in most cases, except via libstcd++.  When we do
use libstdc++ we explicitly set the runpath ourselves.  This alone
should be fine, but the GCC runtime's attempts at compatibility should
also make this possible.


 6. C++ library ABI incompatibility issues and how to solve them


This is a boring and unsolvable problem in the general case.



I'm willing to answer questions about illumos-gate/gcc interactions.
I'm not interested in arguing about what distributions do, nor about
the relative merits of various compilers.

-- Rich

___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] gcc44 build failure (linker related)

[Richard Lowe]

You need Rainer's patch to disable the use of CFI.  See my il-4_4_4
branch, or pull it out of svn.

-- Rich

___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] gcc44 build failure (linker related)

[Richard Lowe]

 Thanks, Alexander and Richard. That solved it. Now I'm wondering why the
 patch isn't in oi-build - not needed?

Certainly should be necessary.  If it's not, someone did something
worse (forced gld, or whatever)

-- Rich

___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] gcc44 build failure (linker related)

[Richard Lowe]

On Mon, Nov 28, 2011 at 14:54, Igor Kozhukhov ikozhuk...@gmail.com wrote:
 I have plan - prepare patch from your version go GCC44 and add it to
 illumos-userland.


The whole reason OI haven't done that is that I asked them not to
until I'd got the set of changes settled.

-- Rich

___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] pkg version bump in /dev

[Richard Lowe]

The changes of Yuri's to illumos's pkg build, recently, should make
this no longer harmful to us.  It'd be nice if someone could confirm
that though.

-- Rich

___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] oi-build feature #1252 - GCC 4.6.2

[Richard Lowe]

On Mon, Nov 14, 2011 at 04:43, Igor Kozhukhov ikozhuk...@gmail.com wrote:
 Big problems - they are GCC_LIBS.

 We can't use different GCC version from /usr/gcc/version with GCC_LIBS
 from one place - because we have for example: libgcc_s.so.1 and others
 with the same names for different GCC versions and we have to use
 libgcc_s.so for -lgcc_s flags for linker.

GCC attempt to maintain backward compatibility in their runtime
libraries.  This should not be a problem, and we're in the process of
actually testing whether this _is_ a problem, sort of, via OI-SFE.

-- Rich

___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] oi-build feature #1252 - GCC 4.6.2

[Richard Lowe]

On Sat, Nov 12, 2011 at 12:11, Igor Kozhukhov ikozhuk...@gmail.com wrote:
 I think that link to /usr/bin/gcc - it as mistake, because you will broke
 illumos-gate build.

The illumos build uses /usr/sfw/bin/gcc,  If the build finds or tries
to use /usr/bin/gcc, something is wrong with illumos.

 We have to save illumos-gate build based on current userland.

That's why /usr/sfw/bin/gcc must be left alone /usr/bin/gcc should be
fine.  Of course, it's probably a good idea for someone to test that.

The patched GCC4 is not important until the changes to illumos
integrate.  The intent behind the way we were structuring the GCC
paths going forward was that the need for a special GCC for illumos
does not impact any other use of GCC in the system.  That is,
/usr/gcc/X.Y.Z was to be used by people who _specifically_ required a
version of GCC, such as illumos, whereas /usr/bin/gcc could be a
convenient, user-appropriate, version.

-- Rich

___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] build perl-512 failed on oi-build

[Richard Lowe]

Does your SPARC actually have the specified locale installed?  If not
we'll fall back on C and it'll appear to work.

-- Rich

___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] sea-config package in 151

[Richard Lowe]

Isn't this one of the SNMP packages which Garrett EOF'd?

-- Rich

___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] review for 1619: Mercurial needs to transition to python2.6

[Richard Lowe]

 To try to put it briefly: if I were really moving forward, I'd that in
 oi-build (where a later version of Mercurial is already in place for
 sustaining). As I'm just doing some minor shifting (sideways instead of
 forward, as it were), it seemed simpler to do this with the existing
 build system, which I'm modestly tweaking for the package.


Yes, it's actually getting the resulting package out into the world
that's a pain.

I think what you did is the right way to do it, I'm just not sure that
it'll result in new packages actually being built and distributed...

-- Rich

___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] 1262 Berkeley-db package

[Richard Lowe]

This is because Berkeley DB used to be famously bad at back/forward
compatible of ABI or API.  (it at least used to be the canonical
example of sucking at it).

It doesn't seem wise to ship just one 'bdb' unless someone can say for
certain that they got better, otherwise it's just asking for trouble
(or at least forced rebuilds of every piece of software linking to
it).

-- Rich

___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] 1459 oi-build meta-packages/history/SUNWfppd has incorrect dependency

[Richard Lowe]

looks good.
-- Rich

___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] 1461 oi-build quilt refuses to publish due to #1310 pkglint as can't resolve targets

[Richard Lowe]

 But yes I don't think we should ship to /dev until the pkg situation is
 fixed.

Would be a good idea.  Shipping pkg_166 to anywhere (/dev or /dev-il)
as it currently is is a very bad idea (since it doesn't have the zone
hooks in place to actually function properly, even then)

 Out of all the software in oi-build, there are only a handful of packages
 that needed to be linted.


If it's a small amount, and you're aware of the bugs you might be
hiding (actually, the bugs you're hiding are mostly from not using a
ref repo at all), I guess I think it's merely silly, rather than a bad
idea.

The problem is that oi-build needs a pkg much newer than _151, but
pkgs sufficiently new don't actually work properly on OI (though they
nearly do).

I guess you're not adding to that problem.

-- Rich

___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] 1410 package zilstat

[Richard Lowe]

There's so many versions of arcstat at this point, is Elling and Mike
Herch's the canonical copy now?
Elling said they were working on getting it integrated, then went silent.

-- Rich

___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Happened to notice...

[Richard Lowe]

This is an illumos bug.  There's a handful of other similar noise.

A diff that corrects it and the other noise is here:
https://github.com/richlowe/illumos-gate/compare/misc/pkglint
If someone wants to take that and run with it, that'd be great.  If not I'll
get back to it eventually.

-- Rich
___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Change Request: Lowering dump and swap defaults AKA My dump is too big!

[Richard Lowe]

On Sun, May 22, 2011 at 18:02, Deano de...@rattie.demon.co.uk wrote:
 First question, why huge space for dump files anyway? How many people use
 that facility?

Anyone who wants any bugs they encounter fixed.

 Second do we really use half memory for swap with large memory configs?


It's a rough guess based on the likely compressability of the crash
dump, and the likely size of the kernel image.

dumpadm(1) has its own logic as to the minimum size of dump device it
will even attempt to configure.  I don't know how or if it and install
agree.  It would perhaps be reasonable to have install configure the
minimum size acceptable to dumpadm.

-- Rich

___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Change Request: Lowering dump and swap defaults AKA My dump is too big!

[Richard Lowe]

On Sun, May 22, 2011 at 18:50, Alasdair Lumsden alasdai...@gmail.com wrote:
 On 22 May 2011, at 23:46, Richard Lowe wrote:

 Anyone who wants any bugs they encounter fixed.

 There is that - if theres disk space available for a dump device, its 
 sensible to configure one.


On UFS root filesystems we used to configure the dump device to be the
swap device, we only switched because ZFS let you sensibly separate
this (this is also why we're able to not run savecore by default.
There's nothing that will overwrite the dump on the actual device).

You should be able to:

1) Configure the system to dump to the swap device, as it used to
2) Configure savecore to run by default again (so that dumps don't get
swapped over).

And save the space of the extra dump device.

Someone should have to investigate whether there are problems with
swapping and dumping to the same zvol, as opposed to physical device.

-- Rich

___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] NMI regression on oi_148

[Richard Lowe]

This might be the hang in multi-threaded dump that both bmc and danmcd
have seen.

Try setting dump_plat_mincpu=0 (with /etc/system, or the like) prior
to causing the NMI.  This is just a guess though.

The dump magic is 0 because the dump header written _after_ the dump
is the one savecore cares about, and in this case you've (probably)
hung before writing it.

-- Rich

___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev