Re: [oi-dev] Intel grafix do not work with new drm module
Am 14.06.24 14:08 schrieb Stephan Althaus :
>
> On 6/14/24 13:41, Carsten Grzemba via oi-dev wrote:
> > After updating to the latest drm and libdrm my Xorg uses only the vesa
> > driver in the relolution 1024x768. The older installation uses the
> > resolution 1366x768 and dtrace shows that i915 module is used.
> > The dtrace script for check with the new drm:
> >
> > dtrace -n 'fbt:i915::entry {@num[probefunc] = count();} fbt:drm::entry
> > {@num[probefunc] = count();}'
> > drm_sun_ioctl 25259
> > idr_find 25259
> > idr_find_used_id 25259
> > idr_compare 50518
> >
> > If I dtrace the new drm and i915 I see no calls in the i915 module,
> > instead mostly only drm_sun_ioctl:
> >
> > fbt:drm:drm_sun_ioctl:entry
> > {
> > self->rvalp = (int*) arg4;
> > printf("cmd=%x mode=%x", arg1, arg2);
> > }
> > fbt:drm:drm_sun_ioctl:return
> > {
> > printf("ret=%x rval=%x", arg1, *self->rvalp);
> > }
> >
> >
> > 2 48751 drm_sun_ioctl:entry cmd=5605 mode=fe000f919490
> > 2 48752 drm_sun_ioctl:return ret=0 rval=a9
> >
> > Xorg is working there only with the vesa driver in the 1024x768
> > resolution. Try to force resolution with xorg.config.file do not work.
> >
> > Any hints what is going wrong here?
> > --
> > Carsten Grzemba
> >
> >
> > ___
> > oi-dev mailing list
> > oi-dev@openindiana.org
> > https://openindiana.org/mailman/listinfo/oi-dev
>
> Hello!
>
> Maybe i am asking too high-level, but does the module i915 get loaded?
>
> i would then re-check /etc/driver-aliases fpr your pci vendor:device id
> found with prtconf -v ...
>
> ?
>
> Regards,
>
> Stephan
>
Sure, dtrace don't complains about to trace i915 probes.
--
Carsten
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] Intel grafix do not work with new drm module
After updating to the latest drm and libdrm my Xorg uses only the vesa driver
in the relolution 1024x768. The older installation uses the resolution 1366x768
and dtrace shows that i915 module is used.
The dtrace script for check with the new drm:
dtrace -n 'fbt:i915::entry {@num[probefunc] = count();} fbt:drm::entry
{@num[probefunc] = count();}'
drm_sun_ioctl 25259
idr_find 25259
idr_find_used_id 25259
idr_compare 50518
If I dtrace the new drm and i915 I see no calls in the i915 module, instead
mostly only drm_sun_ioctl:
fbt:drm:drm_sun_ioctl:entry
{
self->rvalp = (int*) arg4;
printf("cmd=%x mode=%x", arg1, arg2);
}
fbt:drm:drm_sun_ioctl:return
{
printf("ret=%x rval=%x", arg1, *self->rvalp);
}
2 48751 drm_sun_ioctl:entry cmd=5605 mode=fe000f919490
2 48752 drm_sun_ioctl:return ret=0 rval=a9
Xorg is working there only with the vesa driver in the 1024x768 resolution. Try
to force resolution with xorg.config.file do not work.
Any hints what is going wrong here?
--
Carsten Grzemba
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Xorg intel driver not working any more with update drm
Am 23.05.24 16:05 schrieb "Carsten Grzemba" : > > > I updated my laptop on May 22. With this BE, Xorg fails back to VESA and uses > there an ugly resolution 1024x768. > > The BE from May 08 is working fine with Xorg intel driver. > > In this time the DRM packages was updated. Has anyone an idea what happens > here. Someone seen similar problems? How can I get back Xorg working with the > right resolution? > > > Regards > -- > Carsten > no suggestion at all? I froze the drm and libdrm package on the old BE and updated again, now the Xorg Intel driver works as before. The drm or libdrm package version 0.5.11-2024.0.0.85 are broken? -- Carsten ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] Xorg intel driver not working any more with update drm
I updated my laptop on May 22. With this BE, Xorg fails back to VESA and uses there an ugly resolution 1024x768. The BE from May 08 is working fine with Xorg intel driver. In this time the DRM packages was updated. Has anyone an idea what happens here. Someone seen similar problems? How can I get back Xorg working with the right resolution? Regards -- Carsten ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] QT link error on build Virtaulbox 7
Am 21.05.24 14:31 schrieb Stephan Althaus :
>
>
>
>
>
>
>
>
> On 5/21/24 14:06, Carsten Grzemba via oi-dev wrote:
>
>
> >
> > I try to update VirtualBox 7.
> >
> > It works so far beside a small link issue of UICommon.so
> >
> >
> >
> >
> > VirtualBoxVM: supR3HardenedMainGetTrustedMain:
> > dlopen("/opt/VirtualBox/amd64/VirtualBoxVM.so",) failed: ld.so.1:
> > VirtualBoxVM: fatal: relocation error: file
> > /opt/VirtualBox/amd64/UICommon.so: symbol _ZN8QPrinterC1ENS_11PrinterModeE:
> > referenced symbol not found
> >
> >
> >
> > This problem disappears if UICommon.so is linked with
> > libQt5PrintSupport.so.
> >
> >
> >
> > But I have now the problem how to fix the kbuild environment in such way
> > that UICommon.so is linked with this QT lib.
> > It seems that kbuild determines the dependencies by it self or in a magic
> > kind.
> >
> >
> >
> >
> > Has anyone some experieance here?
> >
> >
> >
> >
> > Thanks!
> >
> > - -
> > Carsten
> >
> > ___ oi-dev mailing list
> > oi-dev@openindiana.orghttps://openindiana.org/mailman/listinfo/oi-dev
> >
>
> Hi!
>
> VB 6 was linked with QT 5, with many occurrences of QT5 in the Makefile ?
>
> Did you make a change to QT6 ?
>
>
> Regards,
>
> Stephan
>
>
>
No, because Linux is using still QT5 I decide to use QT5 also.
Carsten
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] QT link error on build Virtaulbox 7
I try to update VirtualBox 7.
It works so far beside a small link issue of UICommon.so
VirtualBoxVM: supR3HardenedMainGetTrustedMain:
dlopen("/opt/VirtualBox/amd64/VirtualBoxVM.so",) failed: ld.so.1: VirtualBoxVM:
fatal: relocation error: file /opt/VirtualBox/amd64/UICommon.so: symbol
_ZN8QPrinterC1ENS_11PrinterModeE: referenced symbol not found
This problem disappears if UICommon.so is linked with libQt5PrintSupport.so.
But I have now the problem how to fix the kbuild environment in such way that
UICommon.so is linked with this QT lib.
It seems that kbuild determines the dependencies by it self or in a magic kind.
Has anyone some experieance here?
Thanks!
- -
Carsten
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi buildsystem different patches for 32-bit or 64-bit
Am 01.02.24 20:02 schrieb "Carsten Grzemba" : > > > > Am 01.02.24 15:20 schrieb Gordon Ross : > > > > You could always make your patches so that the resulting code has #ifdef > > _LP64 > > or whatever to make the code do what you want both 32-bit and 64-bit. > > > > On Thu, Feb 1, 2024 at 7:36 AM Carsten Grzemba via oi-dev > > wrote: > > > > > > Am 01.02.24 12:46 schrieb Carsten Grzemba via oi-dev > > > : > > > > > > Do we have the possibility to use different patches for 32-bit builds > > > than in 64-bit? > > > > > > For Pulseaudio I like to build in 32-bit only the pulse client (lib's)? > > > > > > I withdraw my question. Patches is used on source tree and this tree is > > > the same for build 64-bit or 32-bit. So this would not work in general. > > > > > > My intention is to patch only the build system that only the libraries needed > by client applications are build. The idea is to get less trouble with > compiling code in 32-bit. In general we want ship less 32-bit binaries. > With build system I mean the build of the component, not the OI build system. In the case of Pulseaudio it is the meson - ninja build. I know that OpenCSW has the option to build libraries only of a component. Something like that... ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi buildsystem different patches for 32-bit or 64-bit
Am 01.02.24 12:46 schrieb Carsten Grzemba via oi-dev : > > > Do we have the possibility to use different patches for 32-bit builds than in > 64-bit? > > For Pulseaudio I like to build in 32-bit only the pulse client (lib's)? > I withdraw my question. Patches is used on source tree and this tree is the same for build 64-bit or 32-bit. So this would not work in general. Carsten ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] oi buildsystem different patches for 32-bit or 64-bit
Do we have the possibility to use different patches for 32-bit builds than in 64-bit? For Pulseaudio I like to build in 32-bit only the pulse client (lib's)? -- Carsten ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] package mtx
I want to provide an updated build recipe of the tool mtx, where ever the former package was come from. I am wondering if the current FMRI media/mtx is a name which we should kept. Or is system/storage/mtx a better choice? Or keep it simple and leave everything as it is. -- Carsten ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] LD_EXEC_OPTION and ASLR_MODE
I do some attempts to update package Erlang. The OI-userland build recipe contains ASLR_MODE = $(ASLR_DISABLE) ASLR_MODE has the value '-z aslr=disable'. this setting lands in LD_EXEC_OPTION and the linked binary should have set in the dynamic section DT_SUNW_ASLR (that the name mentioned in SECURITY-FLAGS(7)) But this is not the case. elfdump -d beam.jit shows no such variable. Adding LDFLAG=-Wl,-z,aslr=disable for linking beam.jit, I get in the setting the dynamic section SUNW_ASLR 0 For me it looks like the setting in LD_EXEC_OPTION is ignored from the ld. Do this works like intended? -- Carsten ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Virtualbox crash
Am 15.09.2023 08:58 schrieb Stephan Althaus :Hello Carsten! I have seen your new PR to VirtualBox. I don't understand why it is a good idea to compile packges with GCC-12 instead of GCC-10. Shoudn't we stay with GCC-10 not to break further more things with an additional ABI incompatibility in the line GCC-7 - GCC-10 - GCC-12 ? What will be the next standard-compiler (after GCCC-10) for illumos/OI, GCC-12 or GCC-13 ? Would you be so kind and explain it in short, or maybe present a link for further reading? Thanks! Stephan ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev Vbox builds with gcc10 or gcc11 always crash in c++ excepion handling. Only gcc7 or gcc12 builds survived.That's the reason. ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Virtualbox crash
Am 28.08.23 13:27 schrieb "Carsten Grzemba" :
>
>
>
> Am 28.08.23 12:38 schrieb Toomas Soome :
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > >
> > > On 28. Aug 2023, at 13:32, Carsten Grzemba via oi-dev
> > > wrote:
> > >
> > >
> > >
> > > >
> > > >
> > > >
> > > >
> > > > >
> > > > > #11 0x007b1eb5 in Medium::i_queryInfo
> > > > > (this=this@entry=0xe004c0, fSetImageId=fSetImageId@entry=false,
> > > > > fSetParentId=fSetParentId@entry=false, autoCaller=...)
> > > > > at
> > > > > /code/github/oi-userland/components/sysutils/virtualbox/build/amd64/src/VBox/Main/src-server/MediumImpl.cpp:7176
> > > > > #12 0x007b2dc5 in Medium::refreshState (this=0xe004c0,
> > > > > autoCaller=..., aState=0xe0b1a0)
> > > > > at
> > > > > /code/github/oi-userland/components/sysutils/virtualbox/build/amd64/src/VBox/Main/src-server/MediumImpl.cpp:2180
> > > > > #13 0x009acf71 in MediumWrap::RefreshState (this=0xe004c0,
> > > > > aState=0xe0b1a0)
> > > > > at
> > > > > /code/github/oi-userland/components/sysutils/virtualbox/build/amd64/out/solaris.amd64/debug/obj/VBoxAPIWrap/MediumWrap.cpp:1344
> > > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
> >
> >
> > Those are bits you want to look into, as you get throw from:
> >
> >
> > Medium::i_queryInfo+0x2ae()
> >
> >
> >
> >
> > rgds,
> >
> > toomas
> >
> >
> >
> >
> try
> {
> /* skip accessibility checks for host drives */
> if (m->hostDrive)
> {
> success = true;
> --->> throw S_OK;
> }
>
>
> ...8<..
>
>
> }
> catch (HRESULT aRC)
> {
> rc = aRC;
> }
>
>
> Which is a very impressive application of C++-Exception ...
>
>
>
>
> --
> Carsten
>
A little bit confusing, the working binary compiled with gcc7:
$ gdb /opt/VirtualBox/amd64/VBoxSVC
GNU gdb (GDB) 13.2
...
(gdb) b Medium::i_queryInfo
warning: could not convert 'Medium::i_queryInfo' from the host encoding
(ISO-8859-1) to UTF-32.
This normally should not happen, please file a bug report.
Breakpoint 1 at 0x75f0c0: file
/code/github/oi-userland/components/sysutils/virtualbox/build/amd64/src/VBox/Main/src-server/MediumImpl.cpp,
line 7054.
and the not working compiled with gcc10
$ gdb /opt/VirtualBox/amd64/VBoxSVC
GNU gdb (GDB) 13.2
...
(gdb) b Medium::i_queryInfo
warning: could not convert 'Medium::i_queryInfo' from the host encoding
(ISO-8859-1) to UTF-32.
This normally should not happen, please file a bug report.
Breakpoint 1 at 0x7bb2a0: file
/code/github/oi-userland/components/sysutils/virtualbox/build/amd64/include/VBox/com/AutoLock.h,
line 266.
the symbol Medium::i_queryInfo is mapped different.
--
Carsten
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Virtualbox crash
Am 28.08.23 12:38 schrieb Toomas Soome :
>
>
>
>
>
>
>
>
>
>
> >
> > On 28. Aug 2023, at 13:32, Carsten Grzemba via oi-dev
> > wrote:
> >
> >
> >
> > >
> > >
> > >
> > >
> > > >
> > > > #11 0x007b1eb5 in Medium::i_queryInfo
> > > > (this=this@entry=0xe004c0, fSetImageId=fSetImageId@entry=false,
> > > > fSetParentId=fSetParentId@entry=false, autoCaller=...)
> > > > at
> > > > /code/github/oi-userland/components/sysutils/virtualbox/build/amd64/src/VBox/Main/src-server/MediumImpl.cpp:7176
> > > > #12 0x007b2dc5 in Medium::refreshState (this=0xe004c0,
> > > > autoCaller=..., aState=0xe0b1a0)
> > > > at
> > > > /code/github/oi-userland/components/sysutils/virtualbox/build/amd64/src/VBox/Main/src-server/MediumImpl.cpp:2180
> > > > #13 0x009acf71 in MediumWrap::RefreshState (this=0xe004c0,
> > > > aState=0xe0b1a0)
> > > > at
> > > > /code/github/oi-userland/components/sysutils/virtualbox/build/amd64/out/solaris.amd64/debug/obj/VBoxAPIWrap/MediumWrap.cpp:1344
> > > >
> > >
> > >
> > >
> > >
> >
> >
>
>
>
>
> Those are bits you want to look into, as you get throw from:
>
>
> Medium::i_queryInfo+0x2ae()
>
>
>
>
> rgds,
>
> toomas
>
>
>
>
try
{
/* skip accessibility checks for host drives */
if (m->hostDrive)
{
success = true;
--->> throw S_OK;
}
...8<..
}
catch (HRESULT aRC)
{
rc = aRC;
}
Which is a very impressive application of C++-Exception ...
--
Carsten
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Virtualbox crash
Am 28.08.23 12:22 schrieb Stephan Althaus : > > > > > > > > > On 8/28/23 11:30, Carsten Grzemba via oi-dev wrote: > > > > > > Currently the G++10 compiled Virtualbox crashs in exception handling. The > > stack looks similar to the problem with libexiv2 in > > https://www.illumos.org/issues/13824 > > > > but it seems the correct libs are loaded in the correct sequence. > > > > > > > > > > (gdb) bt > > #0 0x7fffaf4091ca in _lwp_kill () from /lib/64/libc.so.1 > > #1 0x7fffaf3ffa9a in thr_kill () from /lib/64/libc.so.1 > > #2 0x7fffaf39b762 in raise () from /lib/64/libc.so.1 > > #3 0x7fffaf374fa8 in abort () from /lib/64/libc.so.1 > > #4 0x7fffa67fa42d in ?? () from /usr/gcc/10/lib/amd64/libstdc++.so.6 > > #5 0x7fffa67f7249 in ?? () from /usr/gcc/10/lib/amd64/libstdc++.so.6 > > #6 0x7fffa67f6099 in ?? () from /usr/gcc/10/lib/amd64/libstdc++.so.6 > > #7 0x7fffa67f6a8c in __gxx_personality_v0 () from > > /usr/gcc/10/lib/amd64/libstdc++.so.6 > > #8 0x7fffa8235716 in _Unwind_RaiseException_Phase2 > > (exc=exc@entry=0xe5c410, context=context@entry=0x7fffadfce5a0, > > frames_p=frames_p@entry=0x7fffadfce690) > > at > > /jenkins/jobs/oi-userland/workspace/components/developer/gcc-10/gcc-releases-gcc-10.5.0/libgcc/unwind.inc:64 > > #9 0x7fffa8235dc1 in _Unwind_RaiseException (exc=0xe5c410) > > at > > /jenkins/jobs/oi-userland/workspace/components/developer/gcc-10/gcc-releases-gcc-10.5.0/libgcc/unwind.inc:136 > > #10 0x7fffa67f7570 in __cxa_throw () from > > /usr/gcc/10/lib/amd64/libstdc++.so.6 > > #11 0x007b1eb5 in Medium::i_queryInfo (this=this@entry=0xe004c0, > > fSetImageId=fSetImageId@entry=false, > > fSetParentId=fSetParentId@entry=false, autoCaller=...) > > at > > /code/github/oi-userland/components/sysutils/virtualbox/build/amd64/src/VBox/Main/src-server/MediumImpl.cpp:7176 > > #12 0x007b2dc5 in Medium::refreshState (this=0xe004c0, > > autoCaller=..., aState=0xe0b1a0) > > at > > /code/github/oi-userland/components/sysutils/virtualbox/build/amd64/src/VBox/Main/src-server/MediumImpl.cpp:2180 > > #13 0x009acf71 in MediumWrap::RefreshState (this=0xe004c0, > > aState=0xe0b1a0) > > at > > /code/github/oi-userland/components/sysutils/virtualbox/build/amd64/out/solaris.amd64/debug/obj/VBoxAPIWrap/MediumWrap.cpp:1344 > > #14 0x7fff8d47a040 in XPTC_InvokeByIndex (that=0xe00530, > > methodIndex=41, paramCount=1, params=0xe0b1a0) > > at > > /code/github/oi-userland/components/sysutils/virtualbox/build/amd64/src/libs/xpcom18a4/xpcom/reflect/xptcall/src/md/unix/xptcinvoke_x86_64_linux.cpp:221 > > #15 0x7fff8f7b53f9 in ipcDConnectService::OnInvoke (this=0xcf6c40, > > peer=2, invoke=0xe0b170, opLen=18) > > at > > /code/github/oi-userland/components/sysutils/virtualbox/build/amd64/src/libs/xpcom18a4/ipc/ipcd/extensions/dconnect/src/ipcDConnectService.cpp:4076 > > #16 0x7fff8f7b3f5d in ipcDConnectService::OnIncomingRequest > > (this=0xcf6c40, peer=2, op=0xe0b170, opLen=18) > > at > > /code/github/oi-userland/components/sysutils/virtualbox/build/amd64/src/libs/xpcom18a4/ipc/ipcd/extensions/dconnect/src/ipcDConnectService.cpp:3706 > > #17 0x7fff8f7b1afb in DConnectWorker::Run (this=0xe0b650) > > at > > /code/github/oi-userland/components/sysutils/virtualbox/build/amd64/src/libs/xpcom18a4/ipc/ipcd/extensions/dconnect/src/ipcDConnectService.cpp:2979 > > #18 0x7fff8d4637bc in nsThread::Main (arg=0xd9a100) > > at > > /code/github/oi-userland/components/sysutils/virtualbox/build/amd64/src/libs/xpcom18a4/xpcom/threads/nsThread.cpp:118 > > #19 0x7fff8d4afdc1 in _pt_root (arg=0xe97870) > > at > > /code/github/oi-userland/components/sysutils/virtualbox/build/amd64/src/libs/xpcom18a4/nsprpub/pr/src/pthreads/ptthread.c:224 > > #20 0x7fff8d4aff0a in _pt_iprt_root (Thread=0xe2cbb0, pvUser=0xe97870) > > at > > /code/github/oi-userland/components/sysutils/virtualbox/build/amd64/src/libs/xpcom18a4/nsprpub/pr/src/pthreads/ptthread.c:272 > > #21 0x7fff8d7d6563 in rtThreadMain (pThread=pThread@entry=0xe2cbb0, > > NativeThread=NativeThread@entry=11, > > pszThreadName=pszThreadName@entry=0xe2d488 "nspr-3") > > at > > /code/github/oi-userland/components/sysutils/virtualbox/build/amd64/src/VBox/Runtime/common/misc/thread.cpp:727 > > #22 0x7fff8d8de1d3 in rtThreadNativeMain (pvArgs=0xe2cbb0) > > at > > /code/github/oi-userland/components/sysutils/virtualbox/build/amd64/src/VB
[oi-dev] Virtualbox crash
Currently the G++10 compiled Virtualbox crashs in exception handling. The stack looks similar to the problem with libexiv2 in https://www.illumos.org/issues/13824 but it seems the correct libs are loaded in the correct sequence. (gdb) bt #0 0x7fffaf4091ca in _lwp_kill () from /lib/64/libc.so.1 #1 0x7fffaf3ffa9a in thr_kill () from /lib/64/libc.so.1 #2 0x7fffaf39b762 in raise () from /lib/64/libc.so.1 #3 0x7fffaf374fa8 in abort () from /lib/64/libc.so.1 #4 0x7fffa67fa42d in ?? () from /usr/gcc/10/lib/amd64/libstdc++.so.6 #5 0x7fffa67f7249 in ?? () from /usr/gcc/10/lib/amd64/libstdc++.so.6 #6 0x7fffa67f6099 in ?? () from /usr/gcc/10/lib/amd64/libstdc++.so.6 #7 0x7fffa67f6a8c in __gxx_personality_v0 () from /usr/gcc/10/lib/amd64/libstdc++.so.6 #8 0x7fffa8235716 in _Unwind_RaiseException_Phase2 (exc=exc@entry=0xe5c410, context=context@entry=0x7fffadfce5a0, frames_p=frames_p@entry=0x7fffadfce690) at /jenkins/jobs/oi-userland/workspace/components/developer/gcc-10/gcc-releases-gcc-10.5.0/libgcc/unwind.inc:64 #9 0x7fffa8235dc1 in _Unwind_RaiseException (exc=0xe5c410) at /jenkins/jobs/oi-userland/workspace/components/developer/gcc-10/gcc-releases-gcc-10.5.0/libgcc/unwind.inc:136 #10 0x7fffa67f7570 in __cxa_throw () from /usr/gcc/10/lib/amd64/libstdc++.so.6 #11 0x007b1eb5 in Medium::i_queryInfo (this=this@entry=0xe004c0, fSetImageId=fSetImageId@entry=false, fSetParentId=fSetParentId@entry=false, autoCaller=...) at /code/github/oi-userland/components/sysutils/virtualbox/build/amd64/src/VBox/Main/src-server/MediumImpl.cpp:7176 #12 0x007b2dc5 in Medium::refreshState (this=0xe004c0, autoCaller=..., aState=0xe0b1a0) at /code/github/oi-userland/components/sysutils/virtualbox/build/amd64/src/VBox/Main/src-server/MediumImpl.cpp:2180 #13 0x009acf71 in MediumWrap::RefreshState (this=0xe004c0, aState=0xe0b1a0) at /code/github/oi-userland/components/sysutils/virtualbox/build/amd64/out/solaris.amd64/debug/obj/VBoxAPIWrap/MediumWrap.cpp:1344 #14 0x7fff8d47a040 in XPTC_InvokeByIndex (that=0xe00530, methodIndex=41, paramCount=1, params=0xe0b1a0) at /code/github/oi-userland/components/sysutils/virtualbox/build/amd64/src/libs/xpcom18a4/xpcom/reflect/xptcall/src/md/unix/xptcinvoke_x86_64_linux.cpp:221 #15 0x7fff8f7b53f9 in ipcDConnectService::OnInvoke (this=0xcf6c40, peer=2, invoke=0xe0b170, opLen=18) at /code/github/oi-userland/components/sysutils/virtualbox/build/amd64/src/libs/xpcom18a4/ipc/ipcd/extensions/dconnect/src/ipcDConnectService.cpp:4076 #16 0x7fff8f7b3f5d in ipcDConnectService::OnIncomingRequest (this=0xcf6c40, peer=2, op=0xe0b170, opLen=18) at /code/github/oi-userland/components/sysutils/virtualbox/build/amd64/src/libs/xpcom18a4/ipc/ipcd/extensions/dconnect/src/ipcDConnectService.cpp:3706 #17 0x7fff8f7b1afb in DConnectWorker::Run (this=0xe0b650) at /code/github/oi-userland/components/sysutils/virtualbox/build/amd64/src/libs/xpcom18a4/ipc/ipcd/extensions/dconnect/src/ipcDConnectService.cpp:2979 #18 0x7fff8d4637bc in nsThread::Main (arg=0xd9a100) at /code/github/oi-userland/components/sysutils/virtualbox/build/amd64/src/libs/xpcom18a4/xpcom/threads/nsThread.cpp:118 #19 0x7fff8d4afdc1 in _pt_root (arg=0xe97870) at /code/github/oi-userland/components/sysutils/virtualbox/build/amd64/src/libs/xpcom18a4/nsprpub/pr/src/pthreads/ptthread.c:224 #20 0x7fff8d4aff0a in _pt_iprt_root (Thread=0xe2cbb0, pvUser=0xe97870) at /code/github/oi-userland/components/sysutils/virtualbox/build/amd64/src/libs/xpcom18a4/nsprpub/pr/src/pthreads/ptthread.c:272 #21 0x7fff8d7d6563 in rtThreadMain (pThread=pThread@entry=0xe2cbb0, NativeThread=NativeThread@entry=11, pszThreadName=pszThreadName@entry=0xe2d488 "nspr-3") at /code/github/oi-userland/components/sysutils/virtualbox/build/amd64/src/VBox/Runtime/common/misc/thread.cpp:727 #22 0x7fff8d8de1d3 in rtThreadNativeMain (pvArgs=0xe2cbb0) at /code/github/oi-userland/components/sysutils/virtualbox/build/amd64/src/VBox/Runtime/r3/posix/thread-posix.cpp:386 #23 0x7fffaf401de7 in _thrp_setup () from /lib/64/libc.so.1 #24 0x7fffaf402130 in ?? () from /lib/64/libc.so.1 or the mdb view: > $C 7fffae33c0e0 libc.so.1`_lwp_kill+0xa() 7fffae33c110 libc.so.1`raise+0x22(6) 7fffae33c160 libc.so.1`abort+0x58() 7fffae33c1a0 libstdc++.so.6.0.28`__gnu_cxx::__verbose_terminate_handler+0x65() 7fffae33c1c0 libstdc++.so.6.0.28`__cxxabiv1::__terminate+9() 7fffae33c1e0 0x7fffa67f6099() 7fffae33c2d0 libstdc++.so.6.0.28`__gxx_personality_v0+0x2bc() 7fffae33c4a0 libgcc_s.so.1`_Unwind_RaiseException_Phase2+0xa6() 7fffae33c850 libgcc_s.so.1`_Unwind_RaiseException+0x331() 7fffae33c880 libstdc++.so.6.0.28`__cxa_throw+0x40() 7fffae33ca70 Medium::i_queryInfo+0x2ae() 7fffae33cab0 Medium::refreshState+0xa5() 7fffae33cb00 MediumWrap::RefreshState+0x121() 7fffae33cbd0 VBoxXPCOM.so`XPTC_InvokeByIndex+0x1c7() 7fffae33cdd0
Re: [oi-dev] Gimp and G++10 issue
Am 20.01.23 23:39 schrieb Bob Friesenhahn : > > On Fri, 20 Jan 2023, Carsten Grzemba via oi-dev wrote: > > > >If libc.so.1 the only involved C code shared object, would that mean that > >libc has to build with gcc10 and option -fexceptions? > > That would depend on who is calling who. Normally the C/C++ run-time arranges > to call a main() routine which is not part of libc. If a shared library is > involved then shared library initializer functions may be called and I am not > sure what code is responsible for that. If the C++ code has static objects > then the C++ run-time needs to assure that those are constructed before > main() is called. > in this case GCC/G++ 10 runtime x7fffade26a30 0x7fffadfa0234 Yes /usr/lib/64/libexiv2.so.27 0x7fffad9038b0 0x7fffada061fa Yes /usr/gcc/10/lib/amd64/libstdc++.so.6 0x7fffaf3a6820 0x7fffaf3d2f42 Yes (*) /lib/64/libm.so.2 Yes (*) /lib/64/librt.so.1 0x7fffaf4381f0 0x7fffaf4491bc Yes /usr/gcc/10/lib/amd64/libgcc_s.so.1 0x7fffaf0d96e0 0x7fffaf188440 Yes (*) /lib/64/libc.so.1 0x7fffad565c60 0x7fffad598bae Yes (*) /lib/amd64/ld.so.1 (*): Shared library is missing debugging information. > > > > Regardless, GraphicsMagick has a test in its C++ component (Magick++) because > this failure to catch exceptions used to be a common problem. > > Bob > -- > Bob Friesenhahn > bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ > GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ > Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt > > ___ > oi-dev mailing list > oi-dev@openindiana.org > https://openindiana.org/mailman/listinfo/oi-dev > -- Carsten Grzemba Tel.: +49 3677 64740 Mobil: +49 171 9749479 Email: carsten.grze...@contac-dt.de contac Datentechnik GmbH ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Gimp and G++10 issue
Am 20.01.23 19:37 schrieb Bob Friesenhahn : > > On Fri, 20 Jan 2023, Carsten Grzemba via oi-dev wrote: > > > >and compile the test source with g++ 7 it works: > >./jens > >Caught error No namespace info available for XMP prefix `gnome' > >http://www.gnome.org/xmp/ > > > > > >and if I compile the test source with g++ 10 it crashes: > > > >./jens > >terminate called after throwing an instance of 'Exiv2::BasicError' > >what(): No namespace info available for XMP prefix `gnome' > >Abort (core dumped) > > > > > >Anyone how have an idea what the problem here? > > A problem like this seems most likely to be a mixup of C++ run-time libraries. > > If any C code is involved in the exception path, then GCC needs to have > exceptions enabled while compiling the C code (-fexceptions), except that it > may be that GCC for some systems has this option enabled by default. > > Bob > If libc.so.1 the only involved C code shared object, would that mean that libc has to build with gcc10 and option -fexceptions? -- Carsten ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Gimp and G++10 issue
Am 20.01.23 19:37 schrieb Bob Friesenhahn : > > On Fri, 20 Jan 2023, Carsten Grzemba via oi-dev wrote: > > > >and compile the test source with g++ 7 it works: > >./jens > >Caught error No namespace info available for XMP prefix `gnome' > >http://www.gnome.org/xmp/ > > > > > >and if I compile the test source with g++ 10 it crashes: > > > >./jens > >terminate called after throwing an instance of 'Exiv2::BasicError' > >what(): No namespace info available for XMP prefix `gnome' > >Abort (core dumped) > > > > > >Anyone how have an idea what the problem here? > > A problem like this seems most likely to be a mixup of C++ run-time libraries. > > If any C code is involved in the exception path, then GCC needs to have > exceptions enabled while compiling the C code (-fexceptions), except that it > may be that GCC for some systems has this option enabled by default. > > Bob > In the simple example jens.cpp is on top of libexiv2.so only C++ source and here only involved: libexiv2.so.27 => /usr/lib/64/libexiv2.so.27 libstdc++.so.6 => /usr/gcc/10/lib/amd64/libstdc++.so.6 libm.so.2 => /lib/64/libm.so.2 librt.so.1 => /lib/64/librt.so.1 libgcc_s.so.1 => /usr/gcc/10/lib/amd64/libgcc_s.so.1 libc.so.1 => /lib/64/libc.so.1 libnsl.so.1 => /lib/64/libnsl.so.1 libsocket.so.1 => /lib/64/libsocket.so.1 libexpat.so.1 => /usr/lib/64/libexpat.so.1 libz.so.1 => /usr/lib/64/libz.so.1 libmp.so.2 => /lib/64/libmp.so.2 libmd.so.1 => /lib/64/libmd.so.1 and in the stack trace then only C lib I seen was libc.so.1 therefore the option -fexception would not work in this case. -- Carsten ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] DKIM violationRe: Gimp and G++10 issue
Am 20.01.23 13:30 schrieb Klaus Ziegler :
>
>
>
>
>
>
>
>
>
>
> On 1/20/23 13:27, Carsten Grzemba via oi-dev wrote:
>
>
> >
> > The current Gimp can't load image files format which support EXIF data.
> >
> >
> >
> >
> > eg the file-jpeg or file-png command crashs on current Gimp if it attempts
> > to open a image file.
> >
> >
> >
> >
> > The crashing function is Exiv2::XmpProperties::nsInfoUnsafe
> >
> >
> >
> >
> > There is an old closed BUG
> >
> >
> > ttps://github.com/Exiv2/exiv2/pull/959
> >
> >
> >
> >
> > The bug is related the Error class in throwing an exception.
> >
> >
> > The simple test source shows our problem:
> >
> >
> >
> >
> >
> > // file: jens.cpp
> > // https://github.com/Exiv2/exiv2/issues/644#issuecomment-452472029 /*
> > Linux:
> > $ c++ -std=c++98 jens.cpp -I/usr/local/include -L/usr/local/lib -lexiv2 -o
> > jens
> > $ ./jens
> > Caught error No namespace info available for XMP prefix `gnome'
> > http://www.gnome.org/xmp/
> > $
> > */ #include
> > #include int main(int argc, char *argv[])
> > { try { Exiv2::XmpProperties::ns("gnome"); } catch (Exiv2::Error &error) {
> > std::cerr << "Caught error " << error.what() << "\n";
> > Exiv2::XmpProperties::registerNs("http://www.gnome.org/xmp";(http://www.gnome.org/xmp
> > ), "gnome"); } std::cout << Exiv2::XmpProperties::ns("gnome") << std::endl;
> > }
> >
> >
> > If I test with exiv2
> >
> >
> >
> >
> > pkg://openindiana.org/image/library/exiv2@0.27.5-2020.0.1.0:20211030T093809Z
> >
> >
> >
> >
> > and compile the test source with g++ 7 it works:
> >
> > ./jens
> > Caught error No namespace info available for XMP prefix `gnome'
> > http://www.gnome.org/xmp/
> >
> >
> >
> > and if I compile the test source with g++ 10 it crashes:
> >
> >
> >
> >
> > ./jens
> > terminate called after throwing an instance of 'Exiv2::BasicError'
> > what(): No namespace info available for XMP prefix `gnome'
> > Abort (core dumped)
> >
> >
> >
> >
> >
> > Anyone how have an idea what the problem here?
> >
> >
> >
> >
> > --
> >
> > Carsten
> >
> >
> >
> >
> >
> > ___
> > oi-dev mailing list
> > oi-dev@openindiana.org
> > https://openindiana.org/mailman/listinfo/oi-dev
> >
> Hi Carsten,
> try setting CFLAGS including -fcommon
> Rgds
> Klaus
>
>
>
Hi Klaus,
no difference
$ /usr/gcc/10/bin/g++ -fcommon -g -o jens -l exiv2 jens.cpp
grzemba@oi-sr ~/Tests $ ./jens
terminate called after throwing an instance of 'Exiv2::BasicError'
what(): No namespace info available for XMP prefix `gnome'
Abort (core dumped)
For completeness the stack
$ mdb ./jens core
Loading modules: [ libc.so.1 ld.so.1 ]
> $G
C++ symbol demangling enabled
> ::stack
libc.so.1`_lwp_kill+0xa()
libc.so.1`raise+0x1e(6)
libc.so.1`abort+0x58()
libstdc++.so.6.0.28`__gnu_cxx::__verbose_terminate_handler+0x65()
libstdc++.so.6.0.28`__cxxabiv1::__terminate+9()
0x7fffad7071d1()
0x7fffaec8155c()
libexiv2.so.0.27.5`Exiv2::XmpProperties::nsInfoUnsafe+0x15a()
libexiv2.so.0.27.5`Exiv2::XmpProperties::ns+0xf8()
main+0xbf()
_start_crt+0x87()
_start+0x18()
Carsten
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] hald glib https://www.illumos.org/issues/14226
I added some findings to the issue related hald and newer glib versions. hald do not not work with newer glib versions than 2.63.4. because there is a change in g_io_channel_read_line which handles the output of the function differently if the string contains null character. The change seems reasonable for me. (https://gitlab.gnome.org/GNOME/glib/-/issues/2002) But remains the question what special line/string receives g_io_channel_read_line for hald here and how should this handled in hald. Or should a better string send by DBUS (or whoever). -- Carsten ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] DKIM violationRe: problems publishing rust
Am 20.06.22 22:07 schrieb Gary Mills : > > On Mon, Jun 20, 2022 at 09:21:58PM +0200, Andreas Wacknitz wrote: > > We already had another guy trying to build a newer rust failing with the > > same problem. > > He found out that this is a known problem and there should already be a > > fix (as far as I understood) but it hadn't been integrated in the release. > > It looks like the situation didn't change in the last weeks. > > Who is the other guy? That makes three of us. > > I had the same problem. The solution is to copy the files in the > Makefile, instead of using symlinks or hard links: > > # Workaround the symlink name length 100 problem, but hope it is not > neccessary > # but also with patch src_tools_rust-installer_src_generator.rs.patch > COMPONENT_PRE_CONFIGURE_ACTION = $(CP) -r $(SOURCE_DIR)/* $(@D)/ > My experience was, if I remember correctly, it is sufficent to use hard links so you do not waste a lot of disk spaceand time for copying . or that I used a Python script: https://github.com/cgrzemba/oi-userland/blob/rust-144/components/developer/rust/files/sym2hard.py -- Carsten ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] oibuild server: someone working on this:maintenance Jun_06 svc:/application/pkg/server:PR-8313
Hi, there are a lot of pkg.depotd processes running on oibuild and a lot of SMF' pkg/server in maintenance state. log reports: pkg.depotd: The path '/ws/jenkins/workspace/Organisation_oi-userland_PR-8303/i386/repo' does not contain a valid package repository. -- Carsten ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] runpath check in OI pkglint userland check
the main idea of pkglint userland runpath check is to prevent shipping bins in package whith runpaths like /export/home/user/myprivate/builddir/lib wrong architecture like 32bit path for 64bit bin or standard paths which knows the ldd already. Our pkglint userland checker complains about runpaths which are correct. So we should update this tool. e.g. ERROR userland.action001.3 bad RUNPATH, 'opt/SUNWsamfs/bin/archive' includes '/opt/SUNWsamfs/lib' ERROR userland.action001.3 bad RUNPATH, 'opt/SUNWsamfs/bin/notify' includes '/opt/SUNWsamfs/lib' ERROR userland.action001.3 bad RUNPATH, 'opt/SUNWsamfs/bin/request' includes '/opt/SUNWsamfs/lib' these false positives we can get rid off by the version used by solaris-userland. https://github.com/OpenIndiana/oi-userland/pull/7710 But look deeper there is some more work to do. This version will not accept runpaths like /usr/gcc/.. and /usr/mariadb/..., which are correct. We can allow this paths per default. The most complete solution would be to allow this paths, if there resolved dependencies for the related bins Any thoughts? -- Carsten ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Optimize level O2 for libz
Am 14.10.21 20:01 schrieb "s...@pandora.be" : > > > If there are tests for libz and if the tests do not fail, the O2 setting > could be removed. > > Ideally there exist tests that show why the O2 setting was/is being used. > > In the case of Smalltalk Squeak I currently have a note in my Makefile > > # override gcc_OPT (defaults to -O3) for the moment > # squeak compiles with -O2 or -O3 but > # KernelTests-Chronology with version 4.16.7 or 4.19.* > # gcc -O : 438 pass tests > # gcc -O2 : 20 failures 1 errors #testAsDelay error > # the system compiled with -O3 / -O2 is usable but has Chronology failures > gcc_OPT= -O > > > What exactly is the "maintainer meeting" ? > A jitsi session every first wednesday of month. If you like Till can invite you. > > > > Regards, > David Stes > > - Op 12 okt 2021 om 15:34 schreef oi-dev oi-dev@openindiana.org: > > > We discussed in the last maintainer meeting about the history of the O2 > > setting > > for build libz in OI. In the component build recipe is a note about problems > > with firefox if libz optimized in a higher level. > > I build libz without this restriction an tested with firefox 91.2.0esr. > > There I > > could not see any problems, so I suggest to remove the O2 setting for libz. > > -- > > Carsten > > > > ___ > > oi-dev mailing list > > oi-dev@openindiana.org > > https://openindiana.org/mailman/listinfo/oi-dev > -- Carsten Grzemba Tel.: +49 3677 64740 Mobil: +49 171 9749479 Email: carsten.grze...@contac-dt.de contac Datentechnik GmbH ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] Optimize level O2 for libz
We discussed in the last maintainer meeting about the history of the O2 setting for build libz in OI. In the component build recipe is a note about problems with firefox if libz optimized in a higher level. I build libz without this restriction an tested with firefox 91.2.0esr. There I could not see any problems, so I suggest to remove the O2 setting for libz. -- Carsten ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Status of OpenIndiana Wiki (Atlassian Confluence)
Am 11.09.21 19:39 schrieb Till Wegmueller : > > Hi James > > It's not Offline just because the Vulnerability. It crashes on an ongoing > basis. I know Wacki has been starting it whenever somebody asked. But not > recently. > > Ist there a good way to get a HTML export of the WIKI for migration purposes? > If so we could make one and then just dump that to a Webserver and continue > to migrate to docs. > wiki.opencsw.org is a old Confluence Wiki? Xwiki can import Conflunce but I think this is also not an solution. We have an new site on docs.openindiana.org with simple markdown on git. > > > > -Till > > On 11.09.21 14:08, James Madgwick wrote: > >Hi, > > > >I notice the old Wiki (https://wiki.openindiana.org) is giving "503 > >Service Unavailable". Recently a major vulnerability in old versions of > >Confluence, including the version used on the Wiki, has been in the > >news. I'm wondering if this is why the Wiki is down? > > > >In any case, I had been making a list of the pages in the Wiki and what > >content needed to be migrated. The eventual goal being to decommission > >the Wiki once everything useful had been migrated. The majority of the > >Wiki's content was already migrated to the Docs website in the last few > >years. > > > >If the Wiki has been forced offline, it would probably be easiest to > >restore it only briefly to perform a full HTML export and use that in > >the interim. Patching the Confluence vulnerability probably wouldn't be > >worth it. > > > > > >James > > > >Vulnerability details: > >https://us-cert.cisa.gov/ncas/current-activity/2021/09/03/atlassian-releases-security-updates-confluence-server-and-data > >https://confluence.atlassian.com/doc/confluence-security-advisory-2021-08-25-1077906215.html > >https://www.zdnet.com/article/us-cybercom-says-mass-exploitation-of-atlassian-confluence-vulnerability-ongoing-and-expected-to-accelerate/ > > > >___ > >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 > ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] update of Rust to 1.51 or higher: there are activity for uodate Clang 12?
I try to build Firefox 91esr. This requires Rustc 1.51 My first attempt to use rustup ends up in rsutc 1.54 compiler crash: https://github.com/rust-lang/rust/issues/88181 The second attempt is to update our Rust package. The build failed with missing a libLVM-12... So my guess is, I need a newer clang&LLVM package. Is there some activity for update Clang? The PR 6756 was deleted recently. -- Carsten ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] mapfile and RESERVE_SEGMENT or CAPABILITY
Am 09.08.21 23:03 schrieb 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
> 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;
> >
> >
>
>
Linked with this mapfile I get with elfdump -p xpcshell:
Program Header[0]:
p_vaddr: 0x400040 p_flags: [ PF_X PF_R ]
p_paddr: 0 p_type: [ PT_PHDR ]
p_filesz: 0x1c0 p_memsz: 0x1c0
p_offset: 0x40 p_align: 0
Program Header[1]:
p_vaddr: 0x400200 p_flags: [ PF_R ]
p_paddr: 0 p_type: [ PT_INTERP ]
p_filesz: 0x17 p_memsz: 0x17
p_offset: 0x200 p_align: 0
Program Header[2]:
p_vaddr: 0x40 p_flags: [ PF_X PF_R ]
p_paddr: 0 p_type: [ PT_LOAD ]
p_filesz: 0x3f811 p_memsz: 0x3f811
p_offset: 0 p_align: 0x1
Program Header[3]:
p_vaddr: 0x44f820 p_flags: [ PF_W PF_R ]
p_paddr: 0 p_type: [ PT_LOAD ]
p_filesz: 0x8a8 p_memsz: 0xdf8
p_offset: 0x3f820 p_align: 0x1
Program Header[4]:
p_vaddr: 0x8000 p_flags: 0
p_paddr: 0 p_type: [ PT_LOAD ]
p_filesz: 0 p_memsz: 0x7fff
p_offset: 0 p_align: 0x10
Program Header[5]:
p_vaddr: 0x44fb10 p_flags: [ PF_W PF_R ]
p_paddr: 0 p_type: [ PT_DYNAMIC ]
p_filesz: 0x470 p_memsz: 0
p_offset: 0x3fb10 p_align: 0
Program Header[6]:
p_vaddr: 0x4500c8 p_flags: [ PF_W PF_R ]
p_paddr: 0 p_type: [ PT_TLS ]
p_filesz: 0 p_memsz: 0x8
p_offset: 0x400c8 p_align: 0x8
Program Header[7]:
p_vaddr: 0x400218 p_flags: [ PF_R ]
p_paddr: 0 p_type: [ PT_SUNW_UNWIND ]
p_filesz: 0xe4c p_memsz: 0xe4c
p_offset: 0x218 p_align: 0x8
If I try to run:
$ LD_LIBRARY_PATH=. ./xpcshell
Killed
or
$ LD_LIBRARY_PATH=. ldd ./xpcshell
ldd: ./xpcshell: execution failed due to signal 9
So I guess to use LOAD for this is no good idea because OS thinks this space is
really to reserve instead of not to use?
--
Carsten
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] mapfile and RESERVE_SEGMENT or CAPABILITY
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
Re: [oi-dev] mapfile and RESERVE_SEGMENT or CAPABILITY
Am 08.08.21 11:27 schrieb "s...@pandora.be" : > > > Back in March 2021 there was an interesting post by Alan Coopersmith about > the address space layout diagrams for the AMD64 ABI. > > This was related in March to firefox, spidermonkey and so-called tagged > pointers. > > He described various strategies, some were adding a ld link editor mapfile > using either RESERVE_SEGMENT or CAPABILITY. > > However I fear that the OpenIndiana ld has no support for RESERVE_SEGMENT. > > I have ran into a new issue in the very latest versions of OpenSmalltalk > cog-spur where apparently new code in OpenSmalltalk expects the Linux address > space layout - not the OpenIndiana layout. > > The issue is that new code when ran under a debugger seems to set > > endOfJITZone = 0x80ffbcecf000 > > instead of > > endOfJITZone = 0x7fffbe40 > > as on Linux. The OpenIndiana layout seems to use the full 64bit pointer range > while Linux does not seem to do that but unfortunately it appears that > OpenSmalltalk now expects the Linux layout. A few weeks ago that was not the > case so I already raised the issue with the OpenSmalltalk developers. > > I am trying now to use a ld -M mapfile on OI as workaround. > > There are some examples in : > > /usr/lib/ld > > and > > /usr/lib/ld/amd64 > > These examples are : map.default, map.below4G and map.above4G > > Has anyone - perhaps for spidermonkey ? - created a mapfile for simulating > the Linux address space layout ? > > Something like: /usr/lib/ld/amd64/map.linux ? > > Thanks > David Stes > > ___ > oi-dev mailing list > oi-dev@openindiana.org > https://openindiana.org/mailman/listinfo/oi-dev > OI mapfile do not support such setting, so I guess the /etc/system setting: set _userlimit=0x7fffc000 is the only option for you. -- Carsten ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] atge driver issue
Am 01.07.21 21:57 schrieb Gary Mills :
>
> On Thu, Jul 01, 2021 at 06:27:55PM +0200, Carsten Grzemba via oi-dev wrote:
> >
> > I use the atge driver on my laptop with AR8151V2 chip. There I have the
> > problem if the cable disconnects 10 sec later I get a L1C error and as
> > a result it seems that the upper layer assumes that the link is up with
> > 10MB half duplex.
> [...]
> > But it seems there is very less similarity of the illumos driver with
> > the BSD or Linux driver.
> >
> > So I am wondering which source was the blue print for the Illumos atge
> > driver?
>
> I started with the Freebsd alc driver, and wound up with a new version
> of the illumos atge driver. This was in 2010. Much has changed since
> then. At the time, I tested the AR8132 on my ASUS laptop. Masayuki
> Murayama tested the AR8131 on his laptop. This was my first driver.
> I had a great deal of help from other people. There was one report in
> 2012 of a driver failure with AR8151 v2.0 hardware.
>
>
> --
> -Gary Mills- -refurb- -Winnipeg, Manitoba, Canada-
>
It seems the fix is simple:
--- a/usr/src/uts/common/io/atge/atge_main.c
+++ b/usr/src/uts/common/io/atge/atge_main.c
@@ -256,7 +256,7 @@ static mii_ops_t atge_l1c_mii_ops = {
atge_l1c_mii_read,
atge_l1c_mii_write,
atge_mii_notify,
- NULL
+ atge_l1c_mii_reset
};
the function atge_l1c_mii_reset exist already but is not registered in the
mii_ops table.
With this the "atge0: L1C chip detected a fatal error, interrupt status: 2200"
did not occur again on cable disconnect.
The interface is working if the cable is connected again.
--
Carsten
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] atge driver issue
Hi, some time ago I described my problem here https://illumos.topicbox.com/groups/developer/T634206bd4ad02a71-M13c079595752100c6a52d7a9 already. I use the atge driver on my laptop with AR8151V2 chip. There I have the problem if the cable disconnects 10 sec later I get a L1C error and as a result it seems that the upper layer assumes that the link is up with 10MB half duplex. If I use the dtrace debug output of the atge driver I see after this error no further output, so I guess the driver is gone to nirvana. My explanation of this behaviour is that atge_device_stop did not stop all ISR activity. So I like to check how is the alc driver in BSD or the alx dirver in Linux working. But it seems there is very less similarity of the illumos driver with the BSD or Linux driver. So I am wondering which source was the blue print for the Illumos atge driver? Perhaps can Gary give me a hint? Many thanks -- Carsten ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] Location of Python modules in speech-dispatcher
Hi, I want to update speech-dispatcher. The problem of firefox with a library from this package is now more common. The package contains some Python bindings which will installed in site-packages directory on default. For relocate these in path vendor-packages was set: CONFIGURE_ENV+= am_cv_python_pyexecdir=$(PYTHON_VENDOR_PACKAGES) CONFIGURE_ENV+= am_cv_python_pythondir=$(PYTHON_VENDOR_PACKAGES) but it seems not working on current version. Do we have a "common solution" for this problem? -- Carsten ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] connot install libp11 and openssl togther
Am 17.05.21 14:16 schrieb Carsten Grzemba via oi-dev : > > > I attempt to update my OI where I use openconnect, but the process stuck > there : > > pkg install: The following packages deliver conflicting action types to > lib/openssl/engines: > > dir: > > pkg://openindiana.org/library/security/libp11@0.4.11,5.11-2020.0.1.0:20201231T145229Z > link: > > pkg://openindiana.org/library/security/openssl@1.0.2.21,5.11-2020.0.1.4:20210220T075124Z > > These packages cannot be installed together. Any non-conflicting subset > of the above packages can be installed. > > The following packages deliver conflicting action types to > lib/openssl/default: > > dir: > > pkg://openindiana.org/library/security/libp11@0.4.11,5.11-2020.0.1.0:20201231T145229Z > link: > > pkg://openindiana.org/library/security/openssl@1.0.2.21,5.11-2020.0.1.4:20210220T075124Z > > These packages cannot be installed together. Any non-conflicting subset > of the above packages can be installed. > > > > normal install of libp11 do not deliver anything in lib/openssl/default and > lib/openssl/engines > The reason of this error is not clear for me because the manifest contains no > dir entry at all, only links of engines which not containted in openssl (any > more). > -- > Carsten > > Could it be, that the problem is?: libp11 ships path=lib/openssl/default/engines/pkcs11.so but lib/openssl/default is now a link to ../../../usr/openssl/1.0/lib ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] connot install libp11 and openssl togther
I attempt to update my OI where I use openconnect, but the process stuck there : pkg install: The following packages deliver conflicting action types to lib/openssl/engines: dir: pkg://openindiana.org/library/security/libp11@0.4.11,5.11-2020.0.1.0:20201231T145229Z link: pkg://openindiana.org/library/security/openssl@1.0.2.21,5.11-2020.0.1.4:20210220T075124Z These packages cannot be installed together. Any non-conflicting subset of the above packages can be installed. The following packages deliver conflicting action types to lib/openssl/default: dir: pkg://openindiana.org/library/security/libp11@0.4.11,5.11-2020.0.1.0:20201231T145229Z link: pkg://openindiana.org/library/security/openssl@1.0.2.21,5.11-2020.0.1.4:20210220T075124Z These packages cannot be installed together. Any non-conflicting subset of the above packages can be installed. normal install of libp11 do not deliver anything in lib/openssl/default and lib/openssl/engines The reason of this error is not clear for me because the manifest contains no dir entry at all, only links of engines which not containted in openssl (any more). -- Carsten ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] Rust packaing for OI and cc-rs PR#585
Hi Joshua, With Rust on OI I run also in the trouble described in https://github.com/alexcrichton/cc-rs/pull/585 running: "ar" "s" "/home/grzemba/Tests/Rust/file_list/target/debug/build/ring-f4ce5e05b289a62a/out/libring-core.a" cargo:warning=ar: one of [drqtpmx] must be specified exit code: 1 running : $ AR=/usr/bin/gar cargo build has helped. Can you give me a hint, where can I apply this patch on Rust packaging for OI? -- Carsten Grzemba ___ 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
Re: [oi-dev] [developer] Re: Virtual address space and Firefox
Am 13.03.21 19:09 schrieb Alan Coopersmith :
>
> On 3/12/21 11:58 PM, Carsten Grzemba via oi-dev wrote:
> >It seems that this are raised by MOZ_ASSERTION because the JS-engine
> >(spidermonkey) expects that addresses for JS Values are not in the upper
> >memory area:
> >
> >ptr must be a valid user-mode pointer, with the top 16 bits clear
>
> Yes - spidermonkey expects to be able to store its own data in the top bits of
> the pointer, which has known issues on Solarish kernels:
> https://bugzilla.mozilla.org/show_bug.cgi?id=577056
>
> You can read more about what spidermonkey is doing at:
> https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/Internals#javascript_values
> https://doar-e.github.io/blog/2018/11/19/introduction-to-spidermonkey-exploitation/#jsvalues-and-jsobjects
>
> >In solaris-userland Oracle has placed a patch but only for Sparc:
> >sparc-47bit-VA-space.patch
> >This use a mapfile with
> >RESERVE_SEGMENT spidermonkey_reserve {
> > VADDR = 0x8000;
> > SIZE = 0x7fff;
> >};
> >Illumos ld don't know the option RESERVE_SEGMENT, but it is for Sparc how I
> >already stated.
>
> This is the second version of the mapfile we've used - the first was:
> CAPABILITY {
> SF += ADDR32;
> };
> but that limits a 64-bit program to a 32-bit address space, and Firefox really
> needs more than 4gb of address space these days, so we had to find a better
> solution.
>
> Fortunately, we already had added RESERVE_SEGMENT to the mapfile syntax and
> ELF program headers to block out a part of the address space, and ensure that
> the system wouldn't map anything in that range, even if ASLR happened to
> randomly pick an address there, so we used that instead:
> https://blogs.oracle.com/solaris/virtual-address-reservation-in-solaris-113-v2
> https://docs.oracle.com/cd/E37838_01/html/E36783/gjpky.html#OSLLGgjpte
>
> >Do IllumOS use the whole 64bit address space and not only the expected
> >47bit? Or I am completly wrong here in the maze of physical and virtual
> >address spaces?
>
> The address model is different than Linux - it's effectively just 47 bits, but
> they're in different subsets of the 64-bit address space than Linux uses.
>
> To quote from one of the engineers who worked on this:
> "On x86-64 they rely on the fact that Mac OS X, Windows and Linux all put the
> userspace/kernelspace boundary at the VA hole. In Solaris, instead, we still
> dynamically restrict it to some arbitrary (depending on amount of memory and
> other factors) boundary line above the VA hole."
> Another engineer just pointed to:
> https://en.wikipedia.org/wiki/X86-64#Virtual_address_space_details
>
> This led to a workaround of putting this line in /etc/system:
> set _userlimit=0x7fffc000
> until the RESERVE_SEGMENT change was available.
>
> But then we also changed the x86 kernel in Solaris 11.4 to make that the
> default
> userlimit on x86 systems, making us match the other OS'es and no longer need
> to
> do anything special to deal with this on x86 systems, only SPARC.
>
> You can see this change in the address space layout diagrams for the AMD64 ABI
> between the 11.3 & 11.4 docs:
> https://docs.oracle.com/cd/E53394_01/html/E61689/fcowb.html#SSFDGfcpaf
> https://docs.oracle.com/cd/E37838_01/html/E66175/fcowb.html#SSFDGfcpaf
>
> -alan-
>
> --
> illumos: illumos-developer
> Permalink:
> https://illumos.topicbox.com/groups/developer/T85d63ca2deb8458a-M1425e543d5d14e98cf2884e7
> Delivery options: https://illumos.topicbox.com/groups/developer/subscription
>
I can confirm that
set _userlimit=0x7fffc000
works here, but is there an impact for the system or other applications with
this system setting?
--
Carsten
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] Virtual address space and Firefox
On building FF for OI I run in core dumps.
It seems that this are raised by MOZ_ASSERTION because the JS-engine
(spidermonkey) expects that addresses for JS Values are not in the upper memory
area:
ptr must be a valid user-mode pointer, with the top 16 bits clear
The ptr is for example 0xfbffef120fb0
so the address is too high in this case. pmap shows the related range as mmap
allocated area (anonymous)
Related the assertions there was a change in FF68.2
In solaris-userland Oracle has placed a patch but only for Sparc:
sparc-47bit-VA-space.patch
This use a mapfile with
RESERVE_SEGMENT spidermonkey_reserve {
VADDR = 0x8000;
SIZE = 0x7fff;
};
Illumos ld don't know the option RESERVE_SEGMENT, but it is for Sparc how I
already stated.
Do IllumOS use the whole 64bit address space and not only the expected 47bit?
Or I am completly wrong here in the maze of physical and virtual address spaces?
--
Carsten
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Firefox build - Link problems
Am 09.03.21 09:38 schrieb "Joshua M. Clulow" : > > On Tue, 9 Mar 2021 at 00:35, Carsten Grzemba via oi-dev > wrote: > > I attempt to build newer Firefox for OI, but my results alwas run in core > > dumps early on start or later on exit. One of them is demonstrated here. > > Our current userland toolchain use gcc7, but with gcc7 I get an strange > > memory allocation error of g++, so I switched to gcc10. Here cores 'js' in > > libicu. libicu is build with gcc7: > > > > here is shown libstdc++ of gcc7 and gcc10 is loaded: > > $ pldd core > > core 'core' of 2496: ./js > > /lib/amd64/libpthread.so.1 > > /lib/amd64/libsocket.so.1 > > /usr/lib/amd64/libffi.so.6.0.4 > > /usr/lib/amd64/libicui18n.so.66.1 > > /usr/lib/amd64/libicuuc.so.66.1 > > /usr/lib/amd64/libicudata.so.66.1 > > /usr/lib/mps/amd64/libplds4.so > > /usr/lib/mps/amd64/libplc4.so > > /usr/lib/mps/amd64/libnspr4.so > > /lib/amd64/libdl.so.1 > > /lib/amd64/librt.so.1 > > /usr/lib/amd64/libz.so.1.2.11 > > /lib/amd64/libm.so.2 > > /lib/amd64/libnsl.so.1 > > /usr/gcc/10/lib/amd64/libstdc++.so.6.0.28 > > /usr/gcc/10/lib/amd64/libgcc_s.so.1 > > /lib/amd64/libc.so.1 > > /usr/gcc/7/lib/amd64/libstdc++.so.6.0.24 > > /usr/gcc/7/lib/amd64/libgcc_s.so.1 > > > > if I modify the rpath to load the gcc7 libs: > > $ elfedit -e 'dyn:value -s RPATH > > "$ORIGIN:/usr/lib/mps/amd64:/usr/gcc/7/lib/amd64"' js > > the 'js' binary runs without core and an 'pldd' shows the libs of gcc7 only > > are loaded. > > What was the RPATH/RUNPATH value before you modified it? > [20] RPATH 0x19c635 /usr/gcc/10/lib/amd64:$ORIGIN I had to add the /usr/lib/mps/amd64 path anyway > > > > It might help to use "ldd -v" on the actual binary (rather than the > core) to see more details about why the runtime link editor decided to > load each copy of libstdc++... > because I have js modified already, here of xpcshell, the unmodified rpath [27] RUNPATH 0x6327 /usr/gcc/10/lib/amd64:$ORIGIN [28] RPATH 0x6327 /usr/gcc/10/lib/amd64:$ORIGIN $ ldd -v xpcshell ..8<.. find object=libstdc++.so.6; required by xpcshell libstdc++.so.6 => /usr/gcc/10/lib/amd64/libstdc++.so.6 find version=libstdc++.so.6 libstdc++.so.6 (GLIBCXX_3.4.21) => /usr/gcc/10/lib/amd64/libstdc++.so.6 libstdc++.so.6 (CXXABI_1.3) => /usr/gcc/10/lib/amd64/libstdc++.so.6 ..8<.. find object=libstdc++.so.6; required by /ws/grzemba/oi-userland/components/web/firefox/build/amd64/dist/bin/libxul.so find version=libstdc++.so.6 libstdc++.so.6 (GLIBCXX_3.4.26) => /usr/gcc/10/lib/amd64/libstdc++.so.6 libstdc++.so.6 (CXXABI_1.3.5) => /usr/gcc/10/lib/amd64/libstdc++.so.6 ..8<.. find object=libstdc++.so.6; required by /usr/lib/64/libicui18n.so.66 libstdc++.so.6 => /usr/gcc/7/lib/amd64/libstdc++.so.6 find version=libstdc++.so.6 libstdc++.so.6 (GLIBCXX_3.4) => /usr/gcc/7/lib/amd64/libstdc++.so.6 libstdc++.so.6 (CXXABI_1.3.9) => /usr/gcc/7/lib/amd64/libstdc++.so.6 ..8<.. find object=libstdc++.so.6; required by /usr/lib/64/libicuuc.so.66 find version=libstdc++.so.6 libstdc++.so.6 (GLIBCXX_3.4.11) => /usr/gcc/7/lib/amd64/libstdc++.so.6 libstdc++.so.6 (CXXABI_1.3.9) => /usr/gcc/7/lib/amd64/libstdc++.so.6 ..8<.. It seems so far correct but it do not works so. $ pstack core | c++filt core 'core' of 6259: ./xpcshell - thread# 1 / lwp# 1 - () fbffedab1408 icu_66::umtx_initImplPreInit(icu_66::UInitOnce&) () + 78 fbffedab195c u_init_66 () + 4c fbffe5f7a27c JS::detail::InitWithFailureDiagnostic(bool) () + 116 fbffe31d5578 NS_InitXPCOM () + 6c1 fbffe385cf79 XRE_XPCShellMain(int, char**, char**, XREShellData const*) () + 14dc fbffe5db9de8 mozilla::BootstrapImpl::XRE_XPCShellMain(int, char**, char**, XREShellData const*) () + 14 00411f08 main () + 76 00411dd7 _start_crt () + 87 00411d38 _start () + 18 > > > > -- > Joshua M. Clulow > http://blog.sysmgr.org > -- Carsten ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] Firefox build - Link problems
I attempt to build newer Firefox for OI, but my results alwas run in core dumps early on start or later on exit. One of them is demonstrated here. Our current userland toolchain use gcc7, but with gcc7 I get an strange memory allocation error of g++, so I switched to gcc10. Here cores 'js' in libicu. libicu is build with gcc7: $ pstack core | c++filt core 'core' of 2450: ./js () fbffee2b1408 icu_66::umtx_initImplPreInit(icu_66::UInitOnce&) () + 78 fbffee2b195c u_init_66 () + 4c 008f2ac2 JS::detail::InitWithFailureDiagnostic(bool) () + 116 00763f8c main () + b7 00746a37 _start_crt () + 87 00746998 _start () + 18 here is shown libstdc++ of gcc7 and gcc10 is loaded: $ pldd core core 'core' of 2496: ./js /lib/amd64/libpthread.so.1 /lib/amd64/libsocket.so.1 /usr/lib/amd64/libffi.so.6.0.4 /usr/lib/amd64/libicui18n.so.66.1 /usr/lib/amd64/libicuuc.so.66.1 /usr/lib/amd64/libicudata.so.66.1 /usr/lib/mps/amd64/libplds4.so /usr/lib/mps/amd64/libplc4.so /usr/lib/mps/amd64/libnspr4.so /lib/amd64/libdl.so.1 /lib/amd64/librt.so.1 /usr/lib/amd64/libz.so.1.2.11 /lib/amd64/libm.so.2 /lib/amd64/libnsl.so.1 /usr/gcc/10/lib/amd64/libstdc++.so.6.0.28 /usr/gcc/10/lib/amd64/libgcc_s.so.1 /lib/amd64/libc.so.1 /usr/gcc/7/lib/amd64/libstdc++.so.6.0.24 /usr/gcc/7/lib/amd64/libgcc_s.so.1 if I modify the rpath to load the gcc7 libs: $ elfedit -e 'dyn:value -s RPATH "$ORIGIN:/usr/lib/mps/amd64:/usr/gcc/7/lib/amd64"' js the 'js' binary runs without core and an 'pldd' shows the libs of gcc7 only are loaded. $ pldd 2500 2500: ./js /lib/amd64/libpthread.so.1 /lib/amd64/libsocket.so.1 /usr/lib/amd64/libffi.so.6.0.4 /usr/lib/amd64/libicui18n.so.66.1 /usr/lib/amd64/libicuuc.so.66.1 /usr/lib/amd64/libicudata.so.66.1 /usr/lib/mps/amd64/libplds4.so /usr/lib/mps/amd64/libplc4.so /usr/lib/mps/amd64/libnspr4.so /lib/amd64/libdl.so.1 /lib/amd64/librt.so.1 /usr/lib/amd64/libz.so.1.2.11 /lib/amd64/libm.so.2 /lib/amd64/libnsl.so.1 /usr/gcc/7/lib/amd64/libstdc++.so.6.0.24 /usr/gcc/7/lib/amd64/libgcc_s.so.1 /lib/amd64/libc.so.1 But I thought nowadays the lib knows how to link the correct library, but here seems that libicu do not. -- Carsten ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] firefox linking problem for debug
Am 12.02.21 14:29 schrieb Carsten Grzemba via oi-dev : > > Because my FF builds alwas core on startup, I try to build objects with debug > information. But the linking of libxul.so fails with: > > Text relocation remains against symbol .. > > The releated option -shared and -fPIC are in place. There are a hint to use > option -mimpure-text. I will it try but what does it mean? > There are any other hints? It is a little bit anoying, because the linking > takes nearly 3hours on my build VM. > > /usr/gcc/9/bin/g++ -std=gnu++17 -fstack-protector-strong -Wall -Wempty-body > -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith -Wsign-compare > -Wtype-limits -Wunreachable-code -Wwrite-strings -Wno-invalid-offsetof > -Wduplicated-cond -Wimplicit-fallthrough -Wunused-function -Wunused-variable > -Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations > -Wno-error=array-bounds -Wno-error=coverage-mismatch > -Wno-error=free-nonheap-object -Wno-multistatement-macros > -Wno-error=class-memaccess -Wno-error=deprecated-copy -Wformat > -Wformat-overflow=2 -fno-sized-deallocation -fno-aligned-new -O0 -fPIC -m64 > -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -Wno-invalid-offsetof -fpermissive > -fno-exceptions -fno-strict-aliasing -DSOLARIS -fno-rtti -ffunction-sections > -fdata-sections -fno-exceptions -fno-math-errno -pthread -pipe -g > -fno-omit-frame-pointer -funwind-tables -fPIC -shared -Wl,-h,libxul.so -o > libxul.so > @/code/github/openindiana/oi-userland/components/web/firefox-78esr/build/amd64/toolkit/library/build/libxul_so.list > -lpthread -m64 -Wl,-z,text -fstack-protector-strong > -L/code/github/openindiana/oi-userland/components/web/firefox-78esr/build/amd64/dist/bin > '-Wl,-R,$ORIGIN' ../../../js/src/build/libjs_static.a > /code/github/openindiana/oi-userland/components/web/firefox-78esr/build/amd64/x86_64-sun-solaris/debug/libgkrust.a > ../../../config/external/lgpllibs/liblgpllibs.so > ../../../config/external/sqlite/libmozsqlite3.so > ../../../widget/gtk/mozgtk/stub/libmozgtk_stub.so -lsocket -licui18n -licuuc > -licudata -lpthread -lffi -L/usr/lib/mps/amd64 -lplds4 -lplc4 -lnspr4 -ldl > -lposix4 -R/usr/lib/mps/amd64 -lz -lm -lnsl -lsocket -lnss3 -lsmime3 -lssl3 > -lnssutil3 -lfreetype -lfontconfig -lXrender -levent-2.0 -lpixman-1 > -ldbus-glib-1 -ldbus-1 -lgobject-2.0 -lglib-2.0 -lpangocairo-1.0 -lpango-1.0 > -lharfbuzz -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 > -lX11-xcb -lxcb-shm -lxcb -lX11 -lXext -lpangoft2-1.0 -lXt -lgthread-2.0 > ld: warning: symbol '_cairo_pattern_black' has differing sizes: > (file ../../../gfx/cairo/cairo/src/Unified_c_gfx_cairo_cairo_src2.o > value=0x98; file /usr/lib/amd64/libcairo.so value=0xa0); > ../../../gfx/cairo/cairo/src/Unified_c_gfx_cairo_cairo_src2.o definition > taken > ld: warning: symbol '_cairo_pattern_clear' has differing sizes: > (file ../../../gfx/cairo/cairo/src/Unified_c_gfx_cairo_cairo_src2.o > value=0x98; file /usr/lib/amd64/libcairo.so value=0xa0); > ../../../gfx/cairo/cairo/src/Unified_c_gfx_cairo_cairo_src2.o definition > taken > ld: warning: symbol '_cairo_user_font_face_backend' has differing sizes: > (file ../../../gfx/cairo/cairo/src/Unified_c_gfx_cairo_cairo_src3.o > value=0x38; file /usr/lib/amd64/libcairo.so value=0x28); > ../../../gfx/cairo/cairo/src/Unified_c_gfx_cairo_cairo_src3.o definition > taken > ld: warning: symbol '_cairo_pattern_white' has differing sizes: > (file ../../../gfx/cairo/cairo/src/Unified_c_gfx_cairo_cairo_src2.o > value=0x98; file /usr/lib/amd64/libcairo.so value=0xa0); > ../../../gfx/cairo/cairo/src/Unified_c_gfx_cairo_cairo_src2.o definition > taken > ld: warning: symbol '_cairo_image_surface_backend' has differing sizes: > (file ../../../gfx/cairo/cairo/src/Unified_c_gfx_cairo_cairo_src1.o > value=0x110; file /usr/lib/amd64/libcairo.so value=0xd8); > ../../../gfx/cairo/cairo/src/Unified_c_gfx_cairo_cairo_src1.o definition > taken > ld: warning: symbol '_cairo_font_face_nil' has differing sizes: > (file ../../../gfx/cairo/cairo/src/Unified_c_gfx_cairo_cairo_src1.o > value=0x38; file /usr/lib/amd64/libcairo.so value=0x30); > ../../../gfx/cairo/cairo/src/Unified_c_gfx_cairo_cairo_src1.o definition > taken > ld: warning: symbol '_cairo_ft_font_face_backend' has differing sizes: > (file ../../../gfx/cairo/cairo/src/cairo-ft-font.o value=0x38; file > /usr/lib/amd64/libcairo.so value=0x28); > ../../../gfx/cairo/cairo/src/cairo-ft-font.o definition taken > Text relocation remains referenced > against symbol offset in file > mozilla::ThreadSafeAutoRefCnt::ThreadSafeAutoRefCnt() 0x36 > ../../../security/certverifier/Unified_cp
[oi-dev] firefox linking problem for debug
Because my FF builds alwas core on startup, I try to build objects with debug information. But the linking of libxul.so fails with: Text relocation remains against symbol .. The releated option -shared and -fPIC are in place. There are a hint to use option -mimpure-text. I will it try but what does it mean? There are any other hints? It is a little bit anoying, because the linking takes nearly 3hours on my build VM. /usr/gcc/9/bin/g++ -std=gnu++17 -fstack-protector-strong -Wall -Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wwrite-strings -Wno-invalid-offsetof -Wduplicated-cond -Wimplicit-fallthrough -Wunused-function -Wunused-variable -Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations -Wno-error=array-bounds -Wno-error=coverage-mismatch -Wno-error=free-nonheap-object -Wno-multistatement-macros -Wno-error=class-memaccess -Wno-error=deprecated-copy -Wformat -Wformat-overflow=2 -fno-sized-deallocation -fno-aligned-new -O0 -fPIC -m64 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -Wno-invalid-offsetof -fpermissive -fno-exceptions -fno-strict-aliasing -DSOLARIS -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno -pthread -pipe -g -fno-omit-frame-pointer -funwind-tables -fPIC -shared -Wl,-h,libxul.so -o libxul.so @/code/github/openindiana/oi-userland/components/web/firefox-78esr/build/amd64/toolkit/library/build/libxul_so.list -lpthread -m64 -Wl,-z,text -fstack-protector-strong -L/code/github/openindiana/oi-userland/components/web/firefox-78esr/build/amd64/dist/bin '-Wl,-R,$ORIGIN' ../../../js/src/build/libjs_static.a /code/github/openindiana/oi-userland/components/web/firefox-78esr/build/amd64/x86_64-sun-solaris/debug/libgkrust.a ../../../config/external/lgpllibs/liblgpllibs.so ../../../config/external/sqlite/libmozsqlite3.so ../../../widget/gtk/mozgtk/stub/libmozgtk_stub.so -lsocket -licui18n -licuuc -licudata -lpthread -lffi -L/usr/lib/mps/amd64 -lplds4 -lplc4 -lnspr4 -ldl -lposix4 -R/usr/lib/mps/amd64 -lz -lm -lnsl -lsocket -lnss3 -lsmime3 -lssl3 -lnssutil3 -lfreetype -lfontconfig -lXrender -levent-2.0 -lpixman-1 -ldbus-glib-1 -ldbus-1 -lgobject-2.0 -lglib-2.0 -lpangocairo-1.0 -lpango-1.0 -lharfbuzz -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lX11-xcb -lxcb-shm -lxcb -lX11 -lXext -lpangoft2-1.0 -lXt -lgthread-2.0 ld: warning: symbol '_cairo_pattern_black' has differing sizes: (file ../../../gfx/cairo/cairo/src/Unified_c_gfx_cairo_cairo_src2.o value=0x98; file /usr/lib/amd64/libcairo.so value=0xa0); ../../../gfx/cairo/cairo/src/Unified_c_gfx_cairo_cairo_src2.o definition taken ld: warning: symbol '_cairo_pattern_clear' has differing sizes: (file ../../../gfx/cairo/cairo/src/Unified_c_gfx_cairo_cairo_src2.o value=0x98; file /usr/lib/amd64/libcairo.so value=0xa0); ../../../gfx/cairo/cairo/src/Unified_c_gfx_cairo_cairo_src2.o definition taken ld: warning: symbol '_cairo_user_font_face_backend' has differing sizes: (file ../../../gfx/cairo/cairo/src/Unified_c_gfx_cairo_cairo_src3.o value=0x38; file /usr/lib/amd64/libcairo.so value=0x28); ../../../gfx/cairo/cairo/src/Unified_c_gfx_cairo_cairo_src3.o definition taken ld: warning: symbol '_cairo_pattern_white' has differing sizes: (file ../../../gfx/cairo/cairo/src/Unified_c_gfx_cairo_cairo_src2.o value=0x98; file /usr/lib/amd64/libcairo.so value=0xa0); ../../../gfx/cairo/cairo/src/Unified_c_gfx_cairo_cairo_src2.o definition taken ld: warning: symbol '_cairo_image_surface_backend' has differing sizes: (file ../../../gfx/cairo/cairo/src/Unified_c_gfx_cairo_cairo_src1.o value=0x110; file /usr/lib/amd64/libcairo.so value=0xd8); ../../../gfx/cairo/cairo/src/Unified_c_gfx_cairo_cairo_src1.o definition taken ld: warning: symbol '_cairo_font_face_nil' has differing sizes: (file ../../../gfx/cairo/cairo/src/Unified_c_gfx_cairo_cairo_src1.o value=0x38; file /usr/lib/amd64/libcairo.so value=0x30); ../../../gfx/cairo/cairo/src/Unified_c_gfx_cairo_cairo_src1.o definition taken ld: warning: symbol '_cairo_ft_font_face_backend' has differing sizes: (file ../../../gfx/cairo/cairo/src/cairo-ft-font.o value=0x38; file /usr/lib/amd64/libcairo.so value=0x28); ../../../gfx/cairo/cairo/src/cairo-ft-font.o definition taken Text relocation remains referenced against symbol offset in file mozilla::ThreadSafeAutoRefCnt::ThreadSafeAutoRefCnt() 0x36 ../../../security/certverifier/Unified_cpp_certverifier0.o mozilla::ThreadSafeAutoRefCnt::ThreadSafeAutoRefCnt() 0x25 ../../../security/apps/Unified_cpp_security_apps0.o ..8<.. cut, 2500 such lines follow ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] some notes related package firefox
as we discussed on wednesday, here some notes for getting a current FF version
on OI
first we need here also:
- mozilla-nss@3.57
because NSS libs has no versioning in libname, only in elf data, update should
not have side effects for the Illumos ldapclient. At least my oi ldapclient is
still working ;)
- libicu@68.2
this means also that a respin of loffice, qt4, qt5, keepassx etc packages has
to be done, it is a similar problem like whith update openssl
- rusts version > 1.41.1
this seems to be solvable with less effort
- the small sqlite lib fix, reported on bugs-openindiana
I used gcc for build, not clang.
A debug build produces a 3GB libxul.so where the build toolchain has to pickup
the 64bit readelf! 32bit readelf presents errors like:
readelf: Error: Unable to seek to 0xd2aedb60 for section headers
readelf: Error: Unable to read in 3513427240 bytes of symbols
readelf: Error: Unable to determine the number of symbols to load
readelf: Error: Unable to determine the length of the dynamic string table
The Solaris 11.4 ld knows nowadays some extra options like:
-z gnu-version-script=file
process GNU version script mapfile
-z gnu-version-script-compat
enable GNU --version-script compatibility option
which illumos don't have, and produce linker errors
unfortunatly the FF 68esr or 78esr builds which I get core in JS stuff imediate
after startup. It looks like a related problem reported in mozilla-bug 577056
and
https://bugzilla.mozilla.org/show_bug.cgi?id=1540672
which we had already a fix. But the code is reworked and seems now not working
anymore on Illumos.
solaris-userland uses here a patch but this is addressed to SPARC.
For setting here the 47bit address range is a linker map with RESERVE_SEGMENT
used, which the Illumos ld also not knows:
# Mozilla JavaScript expects that no address above 47bits address range
# will get ever used. Solaris SPARC is not limiting address space.
# Therefore we need to enforce it artificially.
$mapfile_version 2
RESERVE_SEGMENT spidermonkey_reserve {
VADDR = 0x8000;
SIZE = 0x7fff;
};
Carsten
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] Rust packaging error on oi-userland
I get a strange error message on rustc install target:
running:
"/code/github/openindiana/oi-userland/components/developer/rust/build/amd64/build/x86_64-sun-solaris/stage0-tools-bin/fabricate"
"generate" "--product-name=Rust" "--rel-manifest-dir=rustlib"
"--success-message=Awesome-Source." "--image-dir"
"/code/github/openindiana/oi-userland/components/developer/rust/build/amd64/build/tmp/dist/rust-src-1.44.1-image"
"--work-dir"
"/code/github/openindiana/oi-userland/components/developer/rust/build/amd64/build/tmp/dist"
"--output-dir"
"/code/github/openindiana/oi-userland/components/developer/rust/build/amd64/build/dist"
"--package-name=rust-src-1.44.1" "--component-name=rust-src"
"--legacy-manifest-dirs=rustlib,cargo"
Error: Custom { kind: Other, error: "provided value is too long when setting
link name for " }
0: failure::backtrace::internal::InternalBacktrace::new
1: failure::backtrace::Backtrace::new
2: installer::tarballer::append_path
3: rayon_core::thread_pool::ThreadPool::install::{{closure}}
4: as rayon_core::job::Job>::execute
5: rayon_core::registry::WorkerThread::wait_until_cold
6: rayon_core::registry::ThreadBuilder::run
7: std::sys_common::backtrace::__rust_begin_short_backtrace
8: core::ops::function::FnOnce::call_once{{vtable.shim}}
9: std::sys::unix::thread::Thread::new::thread_start
10:
11:
failed to tar file
'/code/github/openindiana/oi-userland/components/developer/rust/build/amd64/build/tmp/dist/rust-src-1.44.1/rust-src/lib/rustlib/src/rust/src/stdarch/LICENSE-APACHE'
failed to generate installer
the related link:
'/code/github/openindiana/oi-userland/components/developer/rust/build/amd64/build/tmp/dist/rust-src-1.44.1/rust-src/lib/rustlib/src/rust/src/stdarch/LICENSE-APACHE'
has target
ls -l
'/code/github/openindiana/oi-userland/components/developer/rust/build/amd64/build/tmp/dist/rust-src-1.44.1/rust-src/lib/rustlib/src/rust/src/stdarch/LICENSE-APACHE'
lrwxrwxrwx 1 builder staff 106 Feb 2 08:20
/code/github/openindiana/oi-userland/components/developer/rust/build/amd64/build/tmp/dist/rust-src-1.44.1/rust-src/lib/rustlib/src/rust/src/stdarch/LICENSE-APACHE
->
/code/github/openindiana/oi-userland/components/developer/rust/rustc-1.44.1-src/src/stdarch/LICENSE-APACHE
ls -lL
'/code/github/openindiana/oi-userland/components/developer/rust/build/amd64/build/tmp/dist/rust-src-1.44.1/rust-src/lib/rustlib/src/rust/src/stdarch/LICENSE-APACHE'
-rw-r--r-- 1 builder staff 10847 Jun 17 2020
/code/github/openindiana/oi-userland/components/developer/rust/build/amd64/build/tmp/dist/rust-src-1.44.1/rust-src/lib/rustlib/src/rust/src/stdarch/LICENSE-APACHE
I know that replace the symlink whith copy helps, but why should the symlink
not working? 107 chars for a target name too long?...
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Tasks to focus on
Am 22.01.21 17:40 schrieb Gary Mills : > > On Thu, Jan 07, 2021 at 10:39:12PM +0100, Aurélien Larcher wrote: > > Back in March I was working on: > > - building oi-userland with GCC-10 (everything was built except ~10 > > packages). > > - providing Python 3.8 and 3.9. > > - migrating pkg5 to Python 3.7. > > - updating Boost. > > - updating Clang. > > - updating Rust. > For Rust I did some effort for package Firefox. Version 1.41.1 builds except rustdoc do not link because missing lib-search-path for libLLVM-9.so. > > > > - updating libdrm to 2.4.100. > > - bringing automated rebuild of oi-userland packages and dependencies > > in order. > > However priorities should be set as I cannot dedicate too much time... > > - What do you think should be prioritized? > > - Is anybody interested in picking up one of the tasks? I can assist > > and provide some guidance. > > Is your list still the same, or have some tasks been completed? > > I'd like to take on something, but those tasks are mostly outside of > my area of expertise. On the other hand, I know how to build OI > packages and how to create PRs. What do you suggest. > > I know C and perl, but not Python. My background is Solaris, mostly > command-line, not GUI. I'm slow but steady. > > > -- > -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] Tasks to focus on
Am 23.01.21 07:47 schrieb "s...@pandora.be" : > > > - Op 22 jan 2021 om 17:39 schreef gary mills gary_mi...@fastmail.fm: > > > > I'd like to take on something, but those tasks are mostly outside of > > my area of expertise. On the other hand, I know how to build OI > > packages and how to create PRs. What do you suggest. > > It could be nice to have packages for TeX Live (texlive) or MikTeX > http://tug.org/ see e.g. http://tug.org/texlive/ or https://miktex.org/ > > Maybe I'm missing something ... but I don't see any TeX and/or tex font > packages, > unless they exist in some "extra" repository. > > Another package that would be nice to have on OI : fontforge.org. > > ___ > oi-dev mailing list > oi-dev@openindiana.org > https://openindiana.org/mailman/listinfo/oi-dev > I use here the openCSW package, a little bit matured bu it works ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] NodeJS update
Am 31.12.20 18:35 schrieb Andreas Wacknitz : > > > > > > > > > Am 31.12.20 um 17:09 schrieb Carsten Grzemba via oi-dev: > > > > any plans for update NodeJS? Firefox 78esr requires version 10.21 or > > newer. > > -- > > Carsten > > > > > > > > ___ oi-dev mailing list > > oi-dev@openindiana.orghttps://openindiana.org/mailman/listinfo/oi-dev > > > > ╰─➤ pkg list -a|grep nodejs > runtime/nodejs (openindiana.org) 0.12.18-2020.0.1.3 --r > runtime/nodejs-10 (openindiana.org) 10.23.0-2020.0.1.0 --- > runtime/nodejs-12 (openindiana.org) 12.20.0-2020.0.1.0 --- > runtime/nodejs-14 (openindiana.org) 14.15.3-2020.0.1.0 i-- > runtime/nodejs-6 (openindiana.org) 6.17.1-2020.0.1.1 --r > runtime/nodejs-7 (openindiana.org) 7.10.1-2018.0.0.2 --o > runtime/nodejs-8 (openindiana.org) 8.17.0-2020.0.1.1 --r > > What are you missing? We provide nodejs-10.23.0, 12.20.0 and 14.15.3. All of > them the latest supported versions. > > > perfectly, it's all what I need. > > > > > > 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
[oi-dev] NodeJS update
any plans for update NodeJS? Firefox 78esr requires version 10.21 or newer. -- Carsten ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] I'm taking a break
Thaks for your valuable hints, hope to hear you again, so it's only a break ... Am 08.09.20 19:36 schrieb Andreas Wacknitz : > > Am 08.09.20 um 17:36 schrieb Alexander Pyhalov via oi-dev: > >Hi, guys. > > > >I wasn't sure if this should be a public message, but when I understood that > >CC list reached > 5 persons, decided to send it here. > > > >Briefly, I'm taking a break. > >This doesn't mean that I'll not be able to answer your questions or that I > >will not commit anything to OI repos - I don't know. But for now I'm > >changing my job and likely will relocate to Moscow in near future. Given > >that's new position is a new area for me, I'll just have no time for such > >time-consuming hobby as OI. > > > >I'm still excited about OI and illumos. It was a wonderful experience, but > >for now our ways parted. > >Good luck. You can always reach me via my gmail account. > > > >Best regards, > >Alexander Pyhalov, > >(still) system administrator of Southern Federal University IT department > > > >___ > >oi-dev mailing list > >oi-dev@openindiana.org > >https://openindiana.org/mailman/listinfo/oi-dev > Hi Alexander, > > sad to hear that, but understandable. Good luck for the next time, > especially for your new job. > > Who is left with access to the build system? I "only" have commit rights > but nothing else... > > Regards, > Andreas > > ___ > oi-dev mailing list > oi-dev@openindiana.org > https://openindiana.org/mailman/listinfo/oi-dev > -- Carsten ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] loader problems on upgrade
Am 29.05.20 17:38 schrieb Toomas Soome : > > > > > On 29. May 2020, at 16:09, Carsten Grzemba via oi-dev > > wrote: > > > > I upgraded my system on Supermicro X10SLM from quite older OI (2017) to > > current and faces some problems here. > > Got a system panic on first boot an then on loader > > - loader shows a lot of old BE's which not exist anymore for a long time in > > the rpool > > Loader does get the BE list from rpool/boot/menu.lst file, you can remove the > file and when you use beadm, it will re-populate it. > > > > - if I walk through the BE list I can't select a BE in the subsequent > > choices, it selects from the first choice, forunatly select with 'beadm' on > > loader CLI works! > > hitting ghost entries? > no, one of the existing BE entry. > > > > > - most most annoying thing: can't see the serial console anymore if the > > system boots, on the old version it worked with ttyb > > set console=ttyb > boot -k > I add /boot/conf.d/console file also with content: console=ttyb > > > > rgds, > toomas > -- Carsten Grzemba ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] loader problems on upgrade
R Am 29.05.20 15:10 schrieb Carsten Grzemba via oi-dev : > > > I upgraded my system on Supermicro X10SLM from quite older OI (2017) to > current and faces some problems here. > Got a system panic on first boot an then on loader > - loader shows a lot of old BE's which not exist anymore for a long time in > the rpool > > - if I walk through the BE list I can't select a BE in the subsequent > choices, it selects from the first choice, forunatly select with 'beadm' on > loader CLI works! > - most most annoying thing: can't see the serial console anymore if the > system boots, on the old version it worked with ttyb > > How can I get back my console for troubleshoot the OS booting problems? > -- > Carsten Grzemba > > > ___ > oi-dev mailing list > oi-dev@openindiana.org > https://openindiana.org/mailman/listinfo/oi-dev > > related to the old BE's this are the existings: # beadm list BE Active Mountpoint Space Policy Created hipster-2017.16945 N / 2,50G static 2018-01-19 09:31 hipster-2017.16945-backup-15 - - 320K static 2020-05-29 10:45 hipster-2017.16945-backup-16 - - 36,6M static 2020-05-29 10:52 hipster-19793 R - 131G static 2020-05-29 11:07 This are what loader shows: # bootadm list-menu the location for the active menu is: /rpool/boot/menu.lst INDEX NAME DEVICE TYPE DEFAULT 0 oi-151a9-pre-srss-install rpool/ROOT/oi-151a9-pre-srss-install bootfs - 1 oi-151a9-pre-samfs rpool/ROOT/oi-151a9-pre-samfs bootfs - 2 oi-151a9-pre-usbdrived rpool/ROOT/oi-151a9-pre-usbdrived bootfs - 3 oi-151a9-backup-1 rpool/ROOT/oi-151a9-backup-1 bootfs - 4 Openindiana-HipUpdate-S3 rpool/ROOT/Openindiana-HipUpdate-S3 bootfs - 5 Openindiana-HipUpdate-S3-backup-1 rpool/ROOT/Openindiana-HipUpdate-S3-backup-1 bootfs - 6 Openindiana-HipUpdate-S3-backup-2 rpool/ROOT/Openindiana-HipUpdate-S3-backup-2 bootfs - 7 Openindiana-HipUpdate-S3-backup-3 rpool/ROOT/Openindiana-HipUpdate-S3-backup-3 bootfs - 8 Openindiana-HipUpdate-S2-backup-1 rpool/ROOT/Openindiana-HipUpdate-S2-backup-1 bootfs - 9 hipster-2017.16945 rpool/ROOT/hipster-2017.16945 bootfs - 10 hipster-2017.16945-backup-15 rpool/ROOT/hipster-2017.16945-backup-15 bootfs - 11 hipster-2017.16945-backup-16 rpool/ROOT/hipster-2017.16945-backup-16 bootfs - 12 hipster-19793 rpool/ROOT/hipster-19793 bootfs * -- Carsten Grzemba ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] loader problems on upgrade
I upgraded my system on Supermicro X10SLM from quite older OI (2017) to current and faces some problems here. Got a system panic on first boot an then on loader - loader shows a lot of old BE's which not exist anymore for a long time in the rpool - if I walk through the BE list I can't select a BE in the subsequent choices, it selects from the first choice, forunatly select with 'beadm' on loader CLI works! - most most annoying thing: can't see the serial console anymore if the system boots, on the old version it worked with ttyb How can I get back my console for troubleshoot the OS booting problems? -- Carsten Grzemba ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] pkglint fails during publish
Am 08.05.20 04:06 schrieb Gary Mills : > > When I'm attempting a publish, I get this error: > > /usr/bin/pkglint \ > -f > /dpool/export/home/mills/Downloads/code/oi-userland-jan/tools/pkglintrc > > /dpool/export/home/mills/Downloads/code/oi-userland/components/x11/xorg-server-1.20.8/build/manifest-i386-trusted-xorg.depend.res > ... > > /dpool/export/home/mills/Downloads/code/oi-userland/components/x11/xorg-server-1.20.8/build/manifest-i386-xdmx.depend.res > > Lint engine setup... > pkglint: Error parsing config value for pkglint.ext.content: No module named > 'pkglint' > Error: Error parsing config value for pkglint.ext.content: No module named > 'pkglint' > gmake: *** > [/dpool/export/home/mills/Downloads/code/oi-userland-jan/make-rules/ips.mk:463: > > /dpool/export/home/mills/Downloads/code/oi-userland/components/x11/xorg-server-1.20.8/build/.linted-i386] > Error 2 > > I'm building part of a source clone from January 2019, but the BE is > from March 2020. I'm assuming the error is a result of the change > from python2.7 to python3.5 that happened during that interval. The > file /usr/bin/pkglint is a python3.5 script. The statement: > > pkglint.ext.content = pkglint.userland > > occurs in the tools/pkglintrc file. This seems to be the source > of the error. > > Am I missing a package, or has something else gone wrong? > So check, that userland-tools start pkglint with Python3 > > > > > -- > -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] oi-docs builds
Am 03.04.20 13:48 schrieb Alexander Pyhalov via oi-dev : > > Hi. > It seems there was some issue with Travis CI oi-docs build, at least last PRs > were not checked. > I've reconfigured Travis CI integration, results can be found at > https://travis-ci.com/github/OpenIndiana > > It fails with the same error like 2 month ago, where the problem seems to be link_validator.py with non working links: The job exceeded the maximum time limit for jobs, and has been terminated. ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Would OI be interested in Pale Moon?
On 11.12.19 10:32, Till Wegmüller wrote: > > I concur. Some politeness goes a long way. This problem with the license > requirements however stems from firefox originally. Only that in > firefox'es case they fought with the debian community and lost. It seems > like the Palemoon community needs to have the same experience. Sadly > > Anyhow. Thanks for the work on Palemoon and bringing it to the point of > being distributed as binary. If you would like to contribute more to > OpenIndiana and learn how the oi-userland build system works have a look > at the developers corner in the docs [0] > > Manifest files (p5m) are usually genered with the make target > "sample-manifest" and then have some small changes added on top. If any > special cases are required we point them out during Merging of the Pull > Request. > > We would greatly welcome if you worked on more packages. > > Greetings > Till > > > [0] http://docs.openindiana.org/dev/userland/ > > On 11.12.19 09:40, Alexander Pyhalov via oi-dev wrote: > > Hi. > > I was a bit of uncomfortable to point to this issue, but as others already > > mention this, let this be settled. We will not distribute Pale Moon via OI > > infrastructure. If someone has free cycles, I'd advice him to look at FF > > component, which needs some love. > > > > Best regards, > > Alexander Pyhalov, > > system administrator of Southern Federal University IT department > > > > > > От: Adam Števko > > Отправлено: 11 декабря 2019 г. 11:36 > > Кому: OpenIndiana Developer mailing list > > Тема: Re: [oi-dev] Would OI be interested in Pale Moon? > > > > Thanks Michal for pointing that out. I wasn’t aware of that. Additional > > reason to avoid it then :) > > > >> On 11 Dec 2019, at 09:22, Michal Nowak via oi-dev > >> wrote: > >> > >> On 12/11/19 07:38 AM, Jeremy Andrews wrote: > >>> I ported UXP to illumos and Solaris recently, and I got them to take the > >>> code upstream. I'm pretty anxious about the process now honestly, and > >>> really want everything to work out. There are a few things I'm worried > >>> about, though. > >>> 1. I'm not very familiar with how packages are actually packaged for OI, > >>> and the p5m file for Firefox in particular is... so complicated that > >>> I've been holding off creating a Pale Moon system package for OI until > >>> now, when they're pushing me to try. I was hoping that the subject > >>> wouldn't come up and they'd just want to distribute a binary .tar.xz > >>> file like they do for other operating systems (that kind of package is > >>> very easy to create with a single command). I'm so mixed up because the > >>> .p5m file for Firefox 52 looks so different from the one for Firefox 60, > >>> and includes all these header files, is for 32-bit, etc. And I'm trying > >>> to figure out which differences are due to a change in package design, > >>> and which are due to actual differences in Firefox. > >>> 2. Pale Moon has some unusual requirements. For one thing, it can't use > >>> the system NSS because Mozilla has changed the API somewhat since they > >>> forked. In general, they're leery of using system libraries over the > >>> ones in their own tree because sometimes those libraries have to be > >>> modified in specific ways for the browser. On top of that, they seem to > >>> have a problem with distributing the langpacks with the browser. They > >>> have a site where you can download a langpack of your choice, but you > >>> can't ship it with the browser for some reason. > >>> I'm kind of afraid now that I've done all this for nothing. I'm worried > >>> that their packaging requirements and our packaging requirements may not > >>> line up, and I'll wind up only being able to distribute a tarball on my > >>> own web space that no one will ever download. It's a very good browser, > >>> and the people behind it are actually decent people, but... I'm > >>> overwhelmed with the sense that I've gotten in over my head. > >> > >> Given the hostility Pale Moon developers showed towards a license > >> non-complying OpenBSD port at > >> https://github.com/jasperla/openbsd-wip/issues/86, I'd rather avoid this > >> community at all. > >> > >> The other reason is maintenance cost on the OpenIndiana project. We > >> already have Firefox and due to it's complexity it gives us hard time to > >> keep-up even with ESR releases (currently we are stuck at version 60, 68 > >> is the latest one; the story for the 52->60 transition was the same). Same > >> with Thunderbird. I am afraid Pale Moon would be another chapter of the > >> very same story. > >> > >> Michal > >> > >> ___ > >> 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] Openindiana on Laptop: touchpad not working
On 03.06.19 16:44, "Carsten Grzemba" wrote: > > > > On 23.05.19 08:34, Carsten Grzemba via oi-dev > wrote: > > > > I compared the Xorg log: > > > > in the working log the mouse driver is loaded on PS/s mouse on /dev/mouse: > > > > [ 38.008] (II) LoadModule: "mouse" > > [ 38.008] (II) Loading /usr/lib/xorg/modules/input/amd64/mouse_drv.so > > [ 38.012] (II) Module mouse: vendor="X.Org Foundation" > > [ 38.012] compiled for 1.19.5, module version = 1.9.2 > > [ 38.012] Module class: X.Org XInput Driver > > [ 38.012] ABI class: X.Org XInput driver, version 24.1 > > [ 38.012] (II) Using input driver 'mouse' for 'PS/2 Port for PS/2-style > > Mice' > > [ 38.012] (**) PS/2 Port for PS/2-style Mice: always reports core events > > [ 38.012] (**) Option "Device" "/dev/mouse" > > [ 38.012] (II) PS/2 Port for PS/2-style Mice: Setting Device option to > > "/dev/mouse" > > [ 38.014] (==) PS/2 Port for PS/2-style Mice: Protocol: "VUID" > > [ 38.014] (**) PS/2 Port for PS/2-style Mice: always reports core events > > [ 38.014] (**) Option "Device" "/dev/mouse" > > [ 38.014] (==) PS/2 Port for PS/2-style Mice: Emulate3Buttons, > > Emulate3Timeout: 50 > > [ 38.014] (**) PS/2 Port for PS/2-style Mice: ZAxisMapping: buttons 4 and 5 > > [ 38.014] (**) PS/2 Port for PS/2-style Mice: Buttons: 9 > > [ 38.014] (**) Option "config_info" > > "hal:/org/freedesktop/Hal/devices/pci_0_0/isa_1f/i8042_1_60/mouse_1_0_logicaldev_input" > > [ 38.014] (II) XINPUT: Adding extended input device "PS/2 Port for > > PS/2-style Mice" (type: MOUSE, id 6) > > [ 38.014] (**) PS/2 Port for PS/2-style Mice: (accel) keeping acceleration > > scheme 1 > > [ 38.014] (**) PS/2 Port for PS/2-style Mice: (accel) acceleration profile 0 > > [ 38.015] (**) PS/2 Port for PS/2-style Mice: (accel) acceleration factor: > > 2.000 > > [ 38.015] (**) PS/2 Port for PS/2-style Mice: (accel) acceleration > > threshold: 4 > > > > and the not working on the generic USB device /dev/usb/hid1: > > > > [ 523.036] (II) Loading /usr/lib/xorg/modules/input/amd64/mouse_drv.so > > [ 523.036] (II) Module mouse: vendor="X.Org Foundation" > > [ 523.036] compiled for 1.19.5, module version = 1.9.2 > > [ 523.036] Module class: X.Org XInput Driver > > [ 523.037] ABI class: X.Org XInput driver, version 24.1 > > [ 523.037] (II) Using input driver 'mouse' for 'mouse' > > [ 523.037] (**) mouse: always reports core events > > [ 523.037] (**) Option "Protocol" "VUID" > > [ 523.037] (**) Option "Device" "/dev/usb/hid1" > > [ 523.037] (**) Option "StreamsModule" "usbms" > > [ 523.039] (**) mouse: Protocol: "VUID" > > [ 523.039] (**) mouse: always reports core events > > [ 523.039] (==) mouse: Emulate3Buttons, Emulate3Timeout: 50 > > [ 523.039] (**) mouse: ZAxisMapping: buttons 4 and 5 > > [ 523.039] (**) mouse: Buttons: 9 > > [ 523.039] (**) Option "config_info" > > "hal:/org/freedesktop/Hal/devices/pci_0_0/pci1025_1019_14/device_4/mouse_1_if1_4_logicaldev_input" > > [ 523.039] (II) XINPUT: Adding extended input device "mouse" (type: MOUSE, > > id 6) > > [ 523.039] (**) mouse: (accel) keeping acceleration scheme 1 > > [ 523.039] (**) mouse: (accel) acceleration profile 0 > > [ 523.039] (**) mouse: (accel) acceleration factor: 2.000 > > [ 523.039] (**) mouse: (accel) acceleration threshold: 4 > > [ 523.045] (II) config/hal: Adding input device hotkey > > > > > > in both cases is the the touchpad avail and a extern USB mouse connected. > > the /dev/mouse dev link is in both BE targeted to > > /devices/pseudo/cons@0:mouse > > > > > Still no luck with the latest hipster on my laptop: > > scanpci: > pci bus 0x cardnum 0x00 function 0x00: vendor 0x8086 device 0x1604 > Intel Corporation Broadwell-U Host Bridge -OPI > > pci bus 0x cardnum 0x02 function 0x00: vendor 0x8086 device 0x1616 > Intel Corporation HD Graphics 5500 > > pci bus 0x cardnum 0x03 function 0x00: vendor 0x8086 device 0x160c > Intel Corporation Broadwell-U Audio Controller > > pci bus 0x cardnum 0x14 function 0x00: vendor 0x8086 device 0x9cb1 > Intel Corporation Wildcat Point-LP USB xHCI Controller > > pci bus 0x cardnum 0x16 function 0x00: vendor 0x8086 device 0x9cba > Intel Corporation Wildcat Point-LP MEI Controller #1 > > pci bus
Re: [oi-dev] Openindiana on Laptop: touchpad not working
On 23.05.19 08:34, Carsten Grzemba via oi-dev wrote: > > I compared the Xorg log: > > in the working log the mouse driver is loaded on PS/s mouse on /dev/mouse: > > [ 38.008] (II) LoadModule: "mouse" > [ 38.008] (II) Loading /usr/lib/xorg/modules/input/amd64/mouse_drv.so > [ 38.012] (II) Module mouse: vendor="X.Org Foundation" > [ 38.012] compiled for 1.19.5, module version = 1.9.2 > [ 38.012] Module class: X.Org XInput Driver > [ 38.012] ABI class: X.Org XInput driver, version 24.1 > [ 38.012] (II) Using input driver 'mouse' for 'PS/2 Port for PS/2-style Mice' > [ 38.012] (**) PS/2 Port for PS/2-style Mice: always reports core events > [ 38.012] (**) Option "Device" "/dev/mouse" > [ 38.012] (II) PS/2 Port for PS/2-style Mice: Setting Device option to > "/dev/mouse" > [ 38.014] (==) PS/2 Port for PS/2-style Mice: Protocol: "VUID" > [ 38.014] (**) PS/2 Port for PS/2-style Mice: always reports core events > [ 38.014] (**) Option "Device" "/dev/mouse" > [ 38.014] (==) PS/2 Port for PS/2-style Mice: Emulate3Buttons, > Emulate3Timeout: 50 > [ 38.014] (**) PS/2 Port for PS/2-style Mice: ZAxisMapping: buttons 4 and 5 > [ 38.014] (**) PS/2 Port for PS/2-style Mice: Buttons: 9 > [ 38.014] (**) Option "config_info" > "hal:/org/freedesktop/Hal/devices/pci_0_0/isa_1f/i8042_1_60/mouse_1_0_logicaldev_input" > [ 38.014] (II) XINPUT: Adding extended input device "PS/2 Port for PS/2-style > Mice" (type: MOUSE, id 6) > [ 38.014] (**) PS/2 Port for PS/2-style Mice: (accel) keeping acceleration > scheme 1 > [ 38.014] (**) PS/2 Port for PS/2-style Mice: (accel) acceleration profile 0 > [ 38.015] (**) PS/2 Port for PS/2-style Mice: (accel) acceleration factor: > 2.000 > [ 38.015] (**) PS/2 Port for PS/2-style Mice: (accel) acceleration threshold: > 4 > > and the not working on the generic USB device /dev/usb/hid1: > > [ 523.036] (II) Loading /usr/lib/xorg/modules/input/amd64/mouse_drv.so > [ 523.036] (II) Module mouse: vendor="X.Org Foundation" > [ 523.036] compiled for 1.19.5, module version = 1.9.2 > [ 523.036] Module class: X.Org XInput Driver > [ 523.037] ABI class: X.Org XInput driver, version 24.1 > [ 523.037] (II) Using input driver 'mouse' for 'mouse' > [ 523.037] (**) mouse: always reports core events > [ 523.037] (**) Option "Protocol" "VUID" > [ 523.037] (**) Option "Device" "/dev/usb/hid1" > [ 523.037] (**) Option "StreamsModule" "usbms" > [ 523.039] (**) mouse: Protocol: "VUID" > [ 523.039] (**) mouse: always reports core events > [ 523.039] (==) mouse: Emulate3Buttons, Emulate3Timeout: 50 > [ 523.039] (**) mouse: ZAxisMapping: buttons 4 and 5 > [ 523.039] (**) mouse: Buttons: 9 > [ 523.039] (**) Option "config_info" > "hal:/org/freedesktop/Hal/devices/pci_0_0/pci1025_1019_14/device_4/mouse_1_if1_4_logicaldev_input" > [ 523.039] (II) XINPUT: Adding extended input device "mouse" (type: MOUSE, id > 6) > [ 523.039] (**) mouse: (accel) keeping acceleration scheme 1 > [ 523.039] (**) mouse: (accel) acceleration profile 0 > [ 523.039] (**) mouse: (accel) acceleration factor: 2.000 > [ 523.039] (**) mouse: (accel) acceleration threshold: 4 > [ 523.045] (II) config/hal: Adding input device hotkey > > > in both cases is the the touchpad avail and a extern USB mouse connected. the > /dev/mouse dev link is in both BE targeted to /devices/pseudo/cons@0:mouse > > Still no luck with the latest hipster on my laptop: scanpci: pci bus 0x cardnum 0x00 function 0x00: vendor 0x8086 device 0x1604 Intel Corporation Broadwell-U Host Bridge -OPI pci bus 0x cardnum 0x02 function 0x00: vendor 0x8086 device 0x1616 Intel Corporation HD Graphics 5500 pci bus 0x cardnum 0x03 function 0x00: vendor 0x8086 device 0x160c Intel Corporation Broadwell-U Audio Controller pci bus 0x cardnum 0x14 function 0x00: vendor 0x8086 device 0x9cb1 Intel Corporation Wildcat Point-LP USB xHCI Controller pci bus 0x cardnum 0x16 function 0x00: vendor 0x8086 device 0x9cba Intel Corporation Wildcat Point-LP MEI Controller #1 pci bus 0x cardnum 0x1b function 0x00: vendor 0x8086 device 0x9ca0 Intel Corporation Wildcat Point-LP High Definition Audio Controller pci bus 0x cardnum 0x1c function 0x00: vendor 0x8086 device 0x9c90 Intel Corporation Wildcat Point-LP PCI Express Root Port #1 pci bus 0x cardnum 0x1c function 0x02: vendor 0x8086 device 0x9c94 Intel Corporation Wildcat Point-LP PCI Express Root Port #3 pci bus 0x0002 cardnum 0x00 function 0x00: vendor 0x10ec device 0x8168 Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gig
Re: [oi-dev] Openindiana on Laptop: touchpad not working
I compared the Xorg log: in the working log the mouse driver is loaded on PS/s mouse on /dev/mouse: [ 38.008] (II) LoadModule: "mouse" [ 38.008] (II) Loading /usr/lib/xorg/modules/input/amd64/mouse_drv.so [ 38.012] (II) Module mouse: vendor="X.Org Foundation" [ 38.012] compiled for 1.19.5, module version = 1.9.2 [ 38.012] Module class: X.Org XInput Driver [ 38.012] ABI class: X.Org XInput driver, version 24.1 [ 38.012] (II) Using input driver 'mouse' for 'PS/2 Port for PS/2-style Mice' [ 38.012] (**) PS/2 Port for PS/2-style Mice: always reports core events [ 38.012] (**) Option "Device" "/dev/mouse" [ 38.012] (II) PS/2 Port for PS/2-style Mice: Setting Device option to "/dev/mouse" [ 38.014] (==) PS/2 Port for PS/2-style Mice: Protocol: "VUID" [ 38.014] (**) PS/2 Port for PS/2-style Mice: always reports core events [ 38.014] (**) Option "Device" "/dev/mouse" [ 38.014] (==) PS/2 Port for PS/2-style Mice: Emulate3Buttons, Emulate3Timeout: 50 [ 38.014] (**) PS/2 Port for PS/2-style Mice: ZAxisMapping: buttons 4 and 5 [ 38.014] (**) PS/2 Port for PS/2-style Mice: Buttons: 9 [ 38.014] (**) Option "config_info" "hal:/org/freedesktop/Hal/devices/pci_0_0/isa_1f/i8042_1_60/mouse_1_0_logicaldev_input" [ 38.014] (II) XINPUT: Adding extended input device "PS/2 Port for PS/2-style Mice" (type: MOUSE, id 6) [ 38.014] (**) PS/2 Port for PS/2-style Mice: (accel) keeping acceleration scheme 1 [ 38.014] (**) PS/2 Port for PS/2-style Mice: (accel) acceleration profile 0 [ 38.015] (**) PS/2 Port for PS/2-style Mice: (accel) acceleration factor: 2.000 [ 38.015] (**) PS/2 Port for PS/2-style Mice: (accel) acceleration threshold: 4 and the not working on the generic USB device /dev/usb/hid1: [ 523.036] (II) Loading /usr/lib/xorg/modules/input/amd64/mouse_drv.so [ 523.036] (II) Module mouse: vendor="X.Org Foundation" [ 523.036] compiled for 1.19.5, module version = 1.9.2 [ 523.036] Module class: X.Org XInput Driver [ 523.037] ABI class: X.Org XInput driver, version 24.1 [ 523.037] (II) Using input driver 'mouse' for 'mouse' [ 523.037] (**) mouse: always reports core events [ 523.037] (**) Option "Protocol" "VUID" [ 523.037] (**) Option "Device" "/dev/usb/hid1" [ 523.037] (**) Option "StreamsModule" "usbms" [ 523.039] (**) mouse: Protocol: "VUID" [ 523.039] (**) mouse: always reports core events [ 523.039] (==) mouse: Emulate3Buttons, Emulate3Timeout: 50 [ 523.039] (**) mouse: ZAxisMapping: buttons 4 and 5 [ 523.039] (**) mouse: Buttons: 9 [ 523.039] (**) Option "config_info" "hal:/org/freedesktop/Hal/devices/pci_0_0/pci1025_1019_14/device_4/mouse_1_if1_4_logicaldev_input" [ 523.039] (II) XINPUT: Adding extended input device "mouse" (type: MOUSE, id 6) [ 523.039] (**) mouse: (accel) keeping acceleration scheme 1 [ 523.039] (**) mouse: (accel) acceleration profile 0 [ 523.039] (**) mouse: (accel) acceleration factor: 2.000 [ 523.039] (**) mouse: (accel) acceleration threshold: 4 [ 523.045] (II) config/hal: Adding input device hotkey in both cases is the the touchpad avail and a extern USB mouse connected. the /dev/mouse dev link is in both BE targeted to /devices/pseudo/cons@0:mouse On 21.05.19 17:11, Bob Friesenhahn wrote: > > On Tue, 21 May 2019, Carsten Grzemba via oi-dev wrote: > > >With newer releases I have the problem, that touchpad is not working anymore. > > You forgot to provide any useful information, such as what hardware you are > using. > > Bob > -- > Bob Friesenhahn > bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ > GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ > Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt > -- Carsten Grzemba Tel.: +49 3677 64740 Mobil: +49 171 9749479 Email: carsten.grze...@contac-dt.de contac Datentechnik GmbH ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Openindiana on Laptop: touchpad not working
On 21.05.19 17:11, Bob Friesenhahn wrote: > > On Tue, 21 May 2019, Carsten Grzemba via oi-dev wrote: > > >With newer releases I have the problem, that touchpad is not working anymore. > > You forgot to provide any useful information, such as what hardware you are > using. > Acer Travelmate P257 > > > > Bob > -- > Bob Friesenhahn > bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ > GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ > Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt > -- Carsten Grzemba Tel.: +49 3677 64740 Mobil: +49 171 9749479 Email: carsten.grze...@contac-dt.de contac Datentechnik GmbH ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] Openindiana on Laptop: touchpad not working
With newer releases I have the problem, that touchpad is not working anymore. When I test further, I have found that the Fn-keys for speakers and display brightness also not working. This has worked in the past, but not on my update from January. How can I bring back the touchpad on working? And perhaps also the Fn-keys for speaker an display. The touchpad problem prevents me from updating. TIA -- Carsten ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
