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 ch
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
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
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 li
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 cov
the memsz there is waayyy too big.
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev
>
> 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.
>
> --
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/list
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/li
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-
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/lis
> 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 ins
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
now 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 W
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:
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 an
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 -- an
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
Well, as it stands, I'm waiting on Dan. I think I have all my RTI
materials together and acceptable, etc.
Do you think Meths would be willing to fix the old OI too? I only just
realized I forgot to include him on the email...
On Wed, Jul 1, 2015 at 8:28 AM Alexander Pyhalov wrote:
>
eally do hate the mess Sun made of packaging some of this stuff :(
On Mon, Jun 29, 2015 at 5:34 PM Alexander Pyhalov wrote:
> Richard Lowe писал 29.06.2015 18:51:
> > Hi,
> >
> > When I integrate dmake into illumos, this is going to cause packaging
> > problems
>
-z ignore will also ignore unused dynamic dependencies. This may cause
problems for you, but is unlikely to.
___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev
-z ignore is similar but not the same.
-z discard-unused is a (smart) splitting up of the meanings of -z ignore
into separate options. It'd be worth implementing, but we haven't yet
On Tue, Jun 16, 2015 at 12:06 PM Aurélien Larcher <
aurelien.larc...@gmail.com> wrote:
> Hi,
> I encountered '--g
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
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
Using dmake in distributed mode with ON has, to my knowledge, never
actually worked at all. Even if you do everything Irek recommends,
still don't expect it to succeed without having to put more effort in
(or at all).
___
oi-dev mailing list
oi-dev@open
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
> My cheeky plan was to get someone to "fix" the head
> 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 wor
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
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
___
o
> (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
On Mon, Nov 28, 2011 at 14:54, Igor Kozhukhov 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
_
> 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
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
On Wed, Nov 23, 2011 at 19:18, Josef 'Jeff' Sipek wrote:
> On Wed, Nov 23, 2011 at 06:41:22PM -0500, Richard Lowe wrote:
>> 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
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
The patch is here:
http://hg.openindiana.org/oi-build/raw-file/ca563fe5b714/components/python/python26/patches/Python26-07-dtrace.patch
I don't think it's changed much. I think in the Oracle userland gate
you may find a port to 2.7
http://src.opensolaris.org/source/xref/userland/gate/
It shoul
On Mon, Nov 14, 2011 at 04:43, Igor Kozhukhov wrote:
> Big problems - they are GCC_LIBS.
>
> We can't use different GCC version from /usr/gcc/ 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
On Sat, Nov 12, 2011 at 12:11, Igor Kozhukhov 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 ill
Probably the lint is not being run against a reference repository, so
it doesn't realize that /usr/lib/isaexec exists.
I know aszeszo did some things to attempt to pacify old and broken (as
compared to build 170-ish) versions of pkglint. Perhaps some should
be undone (perhaps some changes need to
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
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
>
> 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
I think that that looks correct.
That said, you're unlikely to find anyone overly thrilled by the idea
of rebuilding (all of) SFW, so you may want to check if folks are
willing to dock a new package and re-import to get the update, or
whether they'd prefer an oi-build based way to do it, or... wel
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 troubl
The menu.lst entry you're booting appears to lack a kernel$ line
entirely. That shouldn't be VMware specific...
-- Rich
___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev
>
> Please note that installed system will be configured to use
> http://pkg.openindiana.org/dev publisher URL which at the moment contains
> b148 packages only. The ISO was built using packages from a repository put
> together by Richard Lowe which is not currently available externally.
> 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
It seems like it would be better to use the right version of pkg (or a
correct installation of the system, so that linked-images are ok),
than to spam pkg.linted attributes.
-- Rich
___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/m
looks good.
-- Rich
___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev
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
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
___
On Sun, May 22, 2011 at 18:50, Alasdair Lumsden 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 roo
On Sun, May 22, 2011 at 18:02, Deano 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 li
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 a
It'd be worthwhile to discover whether this is waste, certainly, but it also
should be noted that the largest memory requirement -- install -- is due to
the miniroot and install machinery and is not representative.
Endeavours of this sort will require investigation, not guess work.
-- Rich
__
I don't see anything wrong with setting SPRO_VROOT to the version of
the compilers you need to use.
I don't know if/why you'd need a separate setting for the 64bit
compilers though.
-- Rich
___
oi-dev mailing list
oi-dev@openindiana.org
http://openindia
56 matches
Mail list logo
