Re: 6.5 PowerPC Packages
The best may be to see ppc@ mailing list over last year. Certainly there is some interest, but well judge yourself. Karel On 5/9/19 4:45 PM, Andrew Luke Nesbit wrote: On 09/05/2019 14:56, Allan Streib wrote: Unless https://www.openbsd.org/plat.html is out of date, it doesn't look like OpenBSD is currently supporting POWER8 or POWER9 plaftorms. I wonder what is the best way to determine interest in getting OpenBSD to work on POWER8/9? My first thought is to ask around in the OpenBSD and OpenPOWER communities. Then to see if there is any natural rapport between them. Andrew
Re: 6.5 PowerPC Packages
On 5/9/19 5:00 PM, Janne Johansson wrote: Den tors 9 maj 2019 kl 16:49 skrev Andrew Luke Nesbit < em...@andrewnesbit.org>: Unless https://www.openbsd.org/plat.html is out of date, it doesn't look like OpenBSD is currently supporting POWER8 or POWER9 plaftorms. I wonder what is the best way to determine interest in getting OpenBSD to work on POWER8/9? Look for amount of diffs published in the direction of getting it to work. If that is zero or very close to zero, then interest is probably at the same level. It's not that simple. From application developer even with decades of experience you do not convert into kernel developer over night. Neither you will be able to read all the required docs and specs and make a brain map from them over night. It takes time. Also with all this under your belt, still the port itself will take another time. So I would be less sharp with 0 patches == 0 interest judgement.
Re: single user question
Misc User writes: > It is theoretically possible to do that, but you'd have to do -a lot- > of work to get it to do so. It'd be much easier finding a proper > way to accomplish what you want without running single-user. I wouldn't recommend using single user mode to do anything other than repair but it's not true to say that doing so is a lot of work. /etc/rc is only ~600 lines and a lot of that is unnecessary if the server is going to run a single thing. In many cases you can probably get away with just mount/fsck/pfctl/netstart. There is actually no such thing as "single user mode". All there is is a kernel which hasn't done anything yet, and everything OpenBSD's does as it "enters multi-user mode" is described clearly and comprehensively in /etc/rc. Duplicating what little of it you want is, literally, as simple as copy-paste. Matthew
Re: Danish FreeBSD Developer hates jews collectively
Dear Poul-Henning! I do get your point. I do not think you are an antesimite. I would think the opposite: most antisemites hide behind their israel-friendliness. I appreciate your involvement on what is happenning in the near east. From the end of WWI the situation of the palestinians got only worse and worser, and with the last developements, faster. You got it, it was not a skilled use of twitter, but unfortunately not only that: you made some errors. It is perhaps not your guilt, because these errors are promoted by the israeli propaganda. From the very beginning there was jewish oposition to the zionist enterprise, due to different reasons, from so called secular jews and from religious ones. Many as radical as the most radical palestinian. In the internet era this should be clear to you: I suppose you are new in the thema. This is why one cannot use the word "jews" to name a party in the conflict, unless in a very restricted context. The AIPAC is not a jewish political lobbying organization, but a zionist one, a israeli one. The zionist propaganda always told that all jews are behind israel, that they represent all jews, it equates zionist with jewish, and opposition to zionism with antisemitism. It seems you fell in their trap. The other error is perhaps to consider jews as a religious group, that they freely chose to be that: it is irrelevant in the context of the conflict. Arabs see them as a religious group, but zionists, antisemites and perhaps most europeans see them as a people. But even among them there are discussions about it (Shlomo Sand). I once met a very anti-israel jew that very proudly considered her ethnicity as "ashkenazy". How they define their collective identity is mainly their issue. As said, I appreciate your involvement, but I think you were also not prudent. While these guys kill without scrupples in the near east, hidden behind heavy weapons, elsewhere their favourite weapon even against the most weak opposition is diffamation. Best regards Rodrigo On Thu, 9 May 2019, Poul-Henning Kamp wrote: You forgot to include this link: http://phk.freebsd.dk/sagas/israel/
Re: Upgrade procedure encrypted filesystem (6.4 -> 6.5)
>> Remove everything that is to do with KDE and go and quietly contemplate >> the life choices which led to you having it installed in the first place. > Hi chohag > it was a leftover when i first installed my laptop > used it for about a week then switch to I3 and never looked back. > will pkg_delete kde4 remove it all ? No. The kde4 "meta-package" is just a set of dependencies to get the other parts installed easily. Uninstalling a package doesn't automatically remove depended-on packages. You can uninstall *all* packages that were pulled in automatically via a dependency that are no longer needed by another package with "pkg_delete -a". But this might remove more than you want; maybe a package was only installed as a dependency but now you do actually want to use it; in that case the simplest option is to review the output from pkg_delete -a and re-install manually as needed.
Re: 6.5 PowerPC Packages
On 2019-05-09, Matthew Graybosch wrote: > On Thu, May 9, 2019, at 9:28 AM, Henry Bonath wrote: >> I'm not sure how many folks out there are PowerPC users, but I was >> just curious if anyone had an idea on if or when we might see those >> out in the mirrors. > > I've got a 2003 lamp-style iMac that runs the macppc port of OpenBSD > -CURRENT. It runs fine but could use a RAM upgrade and a new SSD. > Pre-built package support for macppc isn't as extensive as on amd64; > NetSurf is the best graphical web browser I've found in macppc > packages, and I haven't dared try compiling from ports using only > 256MB of RAM and the original 60GB HDD -- but at least I've got Emacs. If something isn't present in pre-built packages (excluding ports with license restrictions), it will be because the build failed - building from ports won't help unless you are making changes to fix it.
Re: 6.5 PowerPC Packages
On 2019-05-10, Karel Gardas wrote: > > > On 5/9/19 5:00 PM, Janne Johansson wrote: >> Den tors 9 maj 2019 kl 16:49 skrev Andrew Luke Nesbit < >> em...@andrewnesbit.org>: >> Unless https://www.openbsd.org/plat.html is out of date, it doesn't look like OpenBSD is currently supporting POWER8 or POWER9 plaftorms. >>> >>> I wonder what is the best way to determine interest in getting OpenBSD >>> to work on POWER8/9? >>> >> >> Look for amount of diffs published in the direction of getting it to work. >> If that is zero or very close to zero, then interest is probably at the >> same level. > > It's not that simple. From application developer even with decades of > experience you do not convert into kernel developer over night. Neither > you will be able to read all the required docs and specs and make a > brain map from them over night. It takes time. Also with all this under > your belt, still the port itself will take another time. So I would be > less sharp with 0 patches == 0 interest judgement. There are two different things. "interest in getting it to work" can be estimated by, as jj says, diffs, and also by seeing questions come up indicating that someone is looking in that direction. "interest in somebody else getting it to work" is different and pretty much irrelevant to whether it happens. >From what I've seen on mailing lists and other places, there's been at most a handful of the latter, and afaik 0 of the former.
Re: When will be created a great desktop experience for OpenBSD?
On 2019-05-08, Consus wrote: > On 02:01 Tue 07 May, Clark Block wrote: >> When will be created a great desktop experience for OpenBSD? > > After binary package updates will be out-of-box, without using > third-party M:Tier. Oh, but they already are. Install snapshots instead of release.
Criteria for errata
Hey misc@, I'm running 6.5 stable on a thinkpad x1 carbon 6th gen. Everything works beautifully, *except* I'm plagued by this issue: http://openbsd-archive.7691.n7.nabble.com/Xorg-crash-every-few-days-td357384.html which is fixed by this revision: http://cvsweb.openbsd.org/cgi-bin/cvsweb/xenocara/xserver/hw/xfree86/common/xf86VGAarbiterPriv.h.diff?r1=1.8&r2=1.9 I've snagged the 6.5 xenocara.tar.gz, patched it with just that above fix, and installed it on my system which has made X rock-stable for me. This is totally fine for me personally, but I was curious if other people have run into this issue on their 6.5 installs, and if so, is this something worth pushing a reliability errata out for? I'm unfamiliar with how the process traditionally works so please excuse me if the question is outlandish. Thanks, Jeremy
Re: ulpt vs kernel relinking
On Thu, May 09, 2019 at 11:41:17PM -0600, Theo de Raadt wrote: > config -e is incompatible with the KARL relinking sequence. > > For now, we consider KARL more valuable than config -e usage > patterns. > > We've thought about this but for now we don't have a clever > solution to solve this. Usual disclaimer, you're on your own etc... You can probably do something like this in /etc/rc.shutdown: printf 'disable ulpt\nq\n' | config -ef /bsd sha256 /bsd >/var/db/kernel.SHA256 > Thuban wrote: > > > Hi, > > I have a printer that require ulpt to be disabled > > as mentionned in /usr/local/share/doc/pkg-readmes/cups. And it works. > > > > # config -fe /bsd > > disable ulpt > > quit > > > > After a reboot, I can notice : > > > > reorder_kernel: kernel relinking failed; see > > /usr/share/relink/kernel/GENERIC.MP/relink.log > > > > Ok, so I run, as mentioned in the above file : > > > > sha256 -h /var/db/kernel.SHA256 /bsd > > > > However, at next reboot, ulpt is reenabled. > > > > How can I still have KARL and use my printer ? > > > > > > -- > > thuban > > > -- Antoine
Re: Criteria for errata
Jeremy O'Brien wrote: > I've snagged the 6.5 xenocara.tar.gz, patched it with just that above fix, > and installed it on my system which has made X rock-stable for me. This is > totally fine for me personally, but I was curious if other people have run > into this issue on their 6.5 installs, and if so, is this something worth > pushing a reliability errata out for? I'm unfamiliar with how the process > traditionally works so please excuse me if the question is outlandish. security issues and major reliability issues. but we try not to spend all our time making errata. that fix may be a contender. depends on how widely reported it is.
Re: Criteria for errata
On Fri, May 10, 2019 at 09:14:00AM -0400, Ted Unangst wrote: > Jeremy O'Brien wrote: > > I've snagged the 6.5 xenocara.tar.gz, patched it with just that above fix, > > and installed it on my system which has made X rock-stable for me. This is > > totally fine for me personally, but I was curious if other people have run > > into this issue on their 6.5 installs, and if so, is this something worth > > pushing a reliability errata out for? I'm unfamiliar with how the process > > traditionally works so please excuse me if the question is outlandish. > > security issues and major reliability issues. but we try not to spend all our > time making errata. that fix may be a contender. depends on how widely > reported it is. > vga arbiter is only used with multiple cards which isn't the common case
Blind OpenBSD users
Hi misc@! I am looking to understand / enhance the OpenBSD experience for blind users. Do we have any blind users reading misc that can offer any insight into their usecases / pain points / work flows / wants? I am sure OpenBSD is lacking on this front, so use cases in *nix would also be helpful. Cheers, Aaron -- PGP: 0x1F81112D62A9ADCE / 3586 3350 BFEA C101 DB1A 4AF0 1F81 112D 62A9 ADCE
Re: Criteria for errata
On Fri, May 10, 2019, at 09:58, Jonathan Gray wrote: > On Fri, May 10, 2019 at 09:14:00AM -0400, Ted Unangst wrote: > > Jeremy O'Brien wrote: > > > I've snagged the 6.5 xenocara.tar.gz, patched it with just that above > > > fix, and installed it on my system which has made X rock-stable for me. > > > This is totally fine for me personally, but I was curious if other people > > > have run into this issue on their 6.5 installs, and if so, is this > > > something worth pushing a reliability errata out for? I'm unfamiliar with > > > how the process traditionally works so please excuse me if the question > > > is outlandish. > > > > security issues and major reliability issues. but we try not to spend all > > our > > time making errata. that fix may be a contender. depends on how widely > > reported it is. > > > > vga arbiter is only used with multiple cards which isn't the common case > That's how I understood the bug too, but when I enabled a debug build of xenocara and examined the core dump after a crash, I had the same "VGAarbiterSpriteMoveCursor" recursive-stack backtrace as in that bug report.
Re: Thinkpad A285 mouse issues
Actually both things fix the issue. Seems to be better just changing the timecounter, rather than running on just one core. I noticed by the way that when I run sysupgrade, or upgrade as before the SP kernel is the one installed. And I have to change manually and reboot. Also I noticed that when I run dmesg both kernels output data. Can't recall if this was the usual behavior. So, are there any advise against running with acpihpet0 timecounter instead of tsc? I'm attaching my dmesg. timecounters: sysctl kern.timecounter kern.timecounter.tick=1 kern.timecounter.timestepwarnings=0 kern.timecounter.hardware=acpihpet0 kern.timecounter.choice=i8254(0) tsc(2000) acpihpet0(1000) acpitimer0(1000) dummy(-100) Regards, --- Oriol Demaria 2FFED630C16E4FF8 On 10/05/2019 01:15, Jonathan Gray wrote: On Thu, May 09, 2019 at 04:17:40PM +0100, Oriol Demaria wrote: I have this laptop and I'm having issues with this laptop. Wireless has to be replaced and basically have to wait till the graphics card is properly supported, right now is running X with the UEFI framebuffer. So this issues are expected. But I'm having a very annoying bug on X. The mouse stops working, specially Firefox seems to be a problem, but other apps too (perhaps I notice more here as others I mainly use the keyboard). When I run xprop to try to figure out something I get the error "Can't grab the mouse" and won't run. Seems that some event holds the mouse, and prevents you from "clicking". Changed the touchpad to synaptics to see if it makes difference, seems to improve a bit, but still the problem comes back. The other mouse devices are using ws driver. Has someone got a workaround for this? Similar experience? Try a non-mp kernel or sysctl kern.timecounter.hardware=acpihpet0 Thanks in advance. Relevant part of the xorg log file: [ 18193.428] (II) XINPUT: Adding extended input device "/dev/wskbd" (type: KEYBOARD, id 6) [ 18193.925] (II) config/wscons: checking input device /dev/wsmouse0 [ 18193.925] (**) /dev/wsmouse0: Applying InputClass "wsmouse touchpad" [ 18193.925] (II) LoadModule: "synaptics" [ 18193.927] (II) Loading /usr/X11R6/lib/modules/input/synaptics_drv.so [ 18193.929] (II) Module synaptics: vendor="X.Org Foundation" [ 18193.929]compiled for 1.19.7, module version = 1.9.1 [ 18193.929]Module class: X.Org XInput Driver [ 18193.929]ABI class: X.Org XInput driver, version 24.1 [ 18193.929] (II) Using input driver 'synaptics' for '/dev/wsmouse0' [ 18193.929] (**) /dev/wsmouse0: always reports core events [ 18193.929] (**) Option "Device" "/dev/wsmouse0" [ 18194.831] (--) synaptics: /dev/wsmouse0: x-axis range 1266 - 5676 resolution 45 [ 18194.831] (--) synaptics: /dev/wsmouse0: y-axis range 1094 - 4760 resolution 69 [ 18194.832] (**) /dev/wsmouse0: always reports core events [ 18194.835] (II) XINPUT: Adding extended input device "/dev/wsmouse0" (type: TOUCHPAD, id 7) [ 18194.835] (**) synaptics: /dev/wsmouse0: (accel) MinSpeed is now constant deceleration 2.5 [ 18194.835] (**) synaptics: /dev/wsmouse0: (accel) MaxSpeed is now 1.75 [ 18194.835] (**) synaptics: /dev/wsmouse0: (accel) AccelFactor is now 0.035 [ 18194.836] (**) /dev/wsmouse0: (accel) keeping acceleration scheme 1 [ 18194.836] (**) /dev/wsmouse0: (accel) acceleration profile 1 [ 18194.836] (**) /dev/wsmouse0: (accel) acceleration factor: 2.000 [ 18194.836] (**) /dev/wsmouse0: (accel) acceleration threshold: 4 [ 18195.340] (II) config/wscons: checking input device /dev/wsmouse [ 18195.340] (II) LoadModule: "ws" [ 18195.341] (II) Loading /usr/X11R6/lib/modules/input/ws_drv.so [ 18195.342] (II) Module ws: vendor="X.Org Foundation" [ 18195.342]compiled for 1.19.7, module version = 1.3.0 [ 18195.342]Module class: X.Org XInput Driver [ 18195.342]ABI class: X.Org XInput driver, version 24.1 [ 18195.343] (II) Using input driver 'ws' for '/dev/wsmouse' [ 18195.343] (**) /dev/wsmouse: always reports core events [ 18195.343] (II) ws: /dev/wsmouse: debuglevel 0 [ 18195.343] (**) Option "Device" "/dev/wsmouse" [ 18195.343] (**) ws: /dev/wsmouse: ZAxisMapping: buttons 4 and 5 [ 18195.343] (**) ws: /dev/wsmouse: WAxisMapping: buttons 6 and 7 [ 18195.343] (**) ws: /dev/wsmouse: associated screen: 0 [ 18195.372] (II) ws: /dev/wsmouse: minimum x position: 0 [ 18195.372] (II) ws: /dev/wsmouse: maximum x position: 1919 [ 18195.372] (II) ws: /dev/wsmouse: minimum y position: 0 [ 18195.372] (II) ws: /dev/wsmouse: maximum y position: 1079 [ 18195.372] (==) ws: /dev/wsmouse: Buttons: 7 [ 18195.404] (**) ws: /dev/wsmouse: YAxisMapping: buttons 4 and 5 [ 18195.404] (II) XINPUT: Adding extended input device "/dev/wsmouse" (type: MOUSE, id 8) [ 18195.436] (**) /dev/wsmouse: (accel) keeping acceleration scheme 1 [ 18195.436] (**) /dev/wsmouse: (accel) acceleration profile 0 [ 18195.436] (**) /dev/wsmouse: (accel) acceleration factor: 2.000 [ 18195.436] (**) /dev/wsmouse: (accel) acceleration threshold: 4 wsconsctl | grep mouse mouse.t
Re: Thinkpad A285 mouse issues
On systems with tsc desychronised between cores acpihpet is preferable. There is no code to detect this and automatically select acpihpet or try to sychronise tsc between cores currently. This often comes up on AMD based systems but not Intel ones. On Fri, May 10, 2019 at 03:30:41PM +0100, Oriol Demaria wrote: > Actually both things fix the issue. Seems to be better just changing the > timecounter, rather than running on just one core. I noticed by the way that > when I run sysupgrade, or upgrade as before the SP kernel is the one > installed. And I have to change manually and reboot. Also I noticed that > when I run dmesg both kernels output data. Can't recall if this was the > usual behavior. > > So, are there any advise against running with acpihpet0 timecounter instead > of tsc? I'm attaching my dmesg. > > timecounters: > > sysctl kern.timecounter > kern.timecounter.tick=1 > kern.timecounter.timestepwarnings=0 > kern.timecounter.hardware=acpihpet0 > kern.timecounter.choice=i8254(0) tsc(2000) acpihpet0(1000) acpitimer0(1000) > dummy(-100) > > Regards, > > --- > Oriol Demaria > 2FFED630C16E4FF8 > > On 10/05/2019 01:15, Jonathan Gray wrote: > > On Thu, May 09, 2019 at 04:17:40PM +0100, Oriol Demaria wrote: > > > I have this laptop and I'm having issues with this laptop. Wireless > > > has to > > > be replaced and basically have to wait till the graphics card is > > > properly > > > supported, right now is running X with the UEFI framebuffer. So this > > > issues > > > are expected. > > > > > > But I'm having a very annoying bug on X. The mouse stops working, > > > specially > > > Firefox seems to be a problem, but other apps too (perhaps I notice > > > more > > > here as others I mainly use the keyboard). When I run xprop to try > > > to figure > > > out something I get the error "Can't grab the mouse" and won't run. > > > Seems > > > that some event holds the mouse, and prevents you from "clicking". > > > > > > Changed the touchpad to synaptics to see if it makes difference, > > > seems to > > > improve a bit, but still the problem comes back. The other mouse > > > devices are > > > using ws driver. Has someone got a workaround for this? Similar > > > experience? > > > > Try a non-mp kernel or sysctl kern.timecounter.hardware=acpihpet0 > > > > > > > > Thanks in advance. > > > > > > Relevant part of the xorg log file: > > > > > > [ 18193.428] (II) XINPUT: Adding extended input device "/dev/wskbd" > > > (type: > > > KEYBOARD, id 6) > > > [ 18193.925] (II) config/wscons: checking input device /dev/wsmouse0 > > > [ 18193.925] (**) /dev/wsmouse0: Applying InputClass "wsmouse > > > touchpad" > > > [ 18193.925] (II) LoadModule: "synaptics" > > > [ 18193.927] (II) Loading > > > /usr/X11R6/lib/modules/input/synaptics_drv.so > > > [ 18193.929] (II) Module synaptics: vendor="X.Org Foundation" > > > [ 18193.929]compiled for 1.19.7, module version = 1.9.1 > > > [ 18193.929]Module class: X.Org XInput Driver > > > [ 18193.929]ABI class: X.Org XInput driver, version 24.1 > > > [ 18193.929] (II) Using input driver 'synaptics' for '/dev/wsmouse0' > > > [ 18193.929] (**) /dev/wsmouse0: always reports core events > > > [ 18193.929] (**) Option "Device" "/dev/wsmouse0" > > > [ 18194.831] (--) synaptics: /dev/wsmouse0: x-axis range 1266 - 5676 > > > resolution 45 > > > [ 18194.831] (--) synaptics: /dev/wsmouse0: y-axis range 1094 - 4760 > > > resolution 69 > > > [ 18194.832] (**) /dev/wsmouse0: always reports core events > > > [ 18194.835] (II) XINPUT: Adding extended input device "/dev/wsmouse0" > > > (type: TOUCHPAD, id 7) > > > [ 18194.835] (**) synaptics: /dev/wsmouse0: (accel) MinSpeed is now > > > constant > > > deceleration 2.5 > > > [ 18194.835] (**) synaptics: /dev/wsmouse0: (accel) MaxSpeed is now > > > 1.75 > > > [ 18194.835] (**) synaptics: /dev/wsmouse0: (accel) AccelFactor is > > > now 0.035 > > > [ 18194.836] (**) /dev/wsmouse0: (accel) keeping acceleration scheme 1 > > > [ 18194.836] (**) /dev/wsmouse0: (accel) acceleration profile 1 > > > [ 18194.836] (**) /dev/wsmouse0: (accel) acceleration factor: 2.000 > > > [ 18194.836] (**) /dev/wsmouse0: (accel) acceleration threshold: 4 > > > [ 18195.340] (II) config/wscons: checking input device /dev/wsmouse > > > [ 18195.340] (II) LoadModule: "ws" > > > [ 18195.341] (II) Loading /usr/X11R6/lib/modules/input/ws_drv.so > > > [ 18195.342] (II) Module ws: vendor="X.Org Foundation" > > > [ 18195.342]compiled for 1.19.7, module version = 1.3.0 > > > [ 18195.342]Module class: X.Org XInput Driver > > > [ 18195.342]ABI class: X.Org XInput driver, version 24.1 > > > [ 18195.343] (II) Using input driver 'ws' for '/dev/wsmouse' > > > [ 18195.343] (**) /dev/wsmouse: always reports core events > > > [ 18195.343] (II) ws: /dev/wsmouse: debuglevel 0 > > > [ 18195.343] (**) Option "Device" "/dev/wsmouse" > > > [ 18195.343] (**) ws: /dev/wsmouse: ZAxisMapping: buttons 4 and 5 > > > [ 18195.343] (**) ws: /dev/wsmouse: WAxisMapping: buttons 6 a
Haskell compilation issues
Hello, I'm trying to start a little haskell project for the first time in a few months. This is the first time I'm trying to run ghc on OpenBSD I'm not sure what ghc's problem is, I've pasted the error message below along with the version of ld and dmesg I'm pretty sure that this is an openbsd problem. The only "fix" I was able to find was this: https://gitlab.haskell.org/ghc/ghc/issues/8825 However, setting the locale had no effect. I have also copied the version of ghc and the output of locale below. I appreciate any kind of help. --- ghc output --- [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... : error: Warning: Couldn't figure out linker information! Make sure you're using GNU ld, GNU gold or the built in OS X linker, etc. --- ghc -v output --- Glasgow Haskell Compiler, Version 8.2.2, stage 2 booted by GHC version 8.2.2.20180330 Using binary package database: /usr/local/lib/ghc/package.conf.d/package.cache package flags [] loading package database /usr/local/lib/ghc/package.conf.d wired-in package ghc-prim mapped to ghc-prim-0.5.1.1 wired-in package integer-gmp mapped to integer-gmp-1.0.1.0 wired-in package base mapped to base-4.10.1.0 wired-in package rts mapped to rts wired-in package template-haskell mapped to template-haskell-2.12.0.0 wired-in package ghc mapped to ghc-8.2.2 wired-in package dph-seq not found. wired-in package dph-par not found. *** Deleting temp files: Deleting: *** Deleting temp dirs: Deleting: ghc: no input files Usage: For basic information, try the `--help' option. --- ld -v output --- LLD 7.0.1 (compatible with GNU linkers) --- locale output --- LANG= LC_COLLATE="C" LC_CTYPE=en_US.UTF-8 LC_MONETARY="C" LC_NUMERIC="C" LC_TIME="C" LC_MESSAGES="C" LC_ALL= --- dmesg --- OpenBSD 6.5 (GENERIC.MP) #3: Sat Apr 13 14:48:43 MDT 2019 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4156157952 (3963MB) avail mem = 4020568064 (3834MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xdae9c000 (65 entries) bios0: vendor LENOVO version "8DET55WW (1.25 )" date 11/01/2011 bios0: LENOVO 42912XG acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC SSDT SSDT SSDT HPET APIC MCFG ECDT ASF! TCPA SSDT SSDT UEFI UEFI UEFI acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP4(S4) EXP7(S4) EHC1(S3) EHC2(S3) HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5-2540M CPU @ 2.60GHz, 2591.95 MHz, 06-2a-07 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i5-2540M CPU @ 2.60GHz, 2591.59 MHz, 06-2a-07 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Core(TM) i5-2540M CPU @ 2.60GHz, 2591.58 MHz, 06-2a-07 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 1, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i5-2540M CPU @ 2.60GHz, 2591.59 MHz, 06-2a-07 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xf800, bus 0-63 acpiec0 at acpi0 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG_)
Re: Thinkpad A285 mouse issues
On Fri, May 10, 2019 at 03:30:41PM +0100, Oriol Demaria wrote: > Actually both things fix the issue. Seems to be better just changing the > timecounter, rather than running on just one core. I noticed by the way that > when I run sysupgrade, or upgrade as before the SP kernel is the one > installed. And I have to change manually and reboot. Also I noticed that > when I run dmesg both kernels output data. Can't recall if this was the > usual behavior. > > So, are there any advise against running with acpihpet0 timecounter instead > of tsc? I'm attaching my dmesg. On AMD hardware, it's best to use acpihpet0 as your timecounter. +--+ Carlos > > timecounters: > > sysctl kern.timecounter > kern.timecounter.tick=1 > kern.timecounter.timestepwarnings=0 > kern.timecounter.hardware=acpihpet0 > kern.timecounter.choice=i8254(0) tsc(2000) acpihpet0(1000) acpitimer0(1000) > dummy(-100) > > Regards, > > --- > Oriol Demaria > 2FFED630C16E4FF8 > > On 10/05/2019 01:15, Jonathan Gray wrote: > > On Thu, May 09, 2019 at 04:17:40PM +0100, Oriol Demaria wrote: > > > I have this laptop and I'm having issues with this laptop. Wireless > > > has to > > > be replaced and basically have to wait till the graphics card is > > > properly > > > supported, right now is running X with the UEFI framebuffer. So this > > > issues > > > are expected. > > > > > > But I'm having a very annoying bug on X. The mouse stops working, > > > specially > > > Firefox seems to be a problem, but other apps too (perhaps I notice > > > more > > > here as others I mainly use the keyboard). When I run xprop to try > > > to figure > > > out something I get the error "Can't grab the mouse" and won't run. > > > Seems > > > that some event holds the mouse, and prevents you from "clicking". > > > > > > Changed the touchpad to synaptics to see if it makes difference, > > > seems to > > > improve a bit, but still the problem comes back. The other mouse > > > devices are > > > using ws driver. Has someone got a workaround for this? Similar > > > experience? > > > > Try a non-mp kernel or sysctl kern.timecounter.hardware=acpihpet0
Re: single user question
On 5/10/2019 1:28 AM, cho...@jtan.com wrote: Misc User writes: It is theoretically possible to do that, but you'd have to do -a lot- of work to get it to do so. It'd be much easier finding a proper way to accomplish what you want without running single-user. I wouldn't recommend using single user mode to do anything other than repair but it's not true to say that doing so is a lot of work. /etc/rc is only ~600 lines and a lot of that is unnecessary if the server is going to run a single thing. In many cases you can probably get away with just mount/fsck/pfctl/netstart. There is actually no such thing as "single user mode". All there is is a kernel which hasn't done anything yet, and everything OpenBSD's does as it "enters multi-user mode" is described clearly and comprehensively in /etc/rc. Duplicating what little of it you want is, literally, as simple as copy-paste. Matthew What I'm saying is that it would take far more work to get something like httpd to run at that stage than it would take to make the changes to a fully booted, and supportable, system. Making changes to rc is going to force the system's operator to make adjustments at every system upgrade. Besides, it is possible to build a very light-weight system to run a single thing while still be secure and supportable. I have a VM template (Wel, a sitexx.tgz file) that just contains an rc.conf.local, a new crontab, a syslogd.conf, and a few trivial scripts. The system weighs in at 8 MB of used RAM in normal operation and a load average of zero. It is also trivial to upgrade, has all its protections, and I can remotely monitor it. Took me two hours to build it, most of that spent modifying copies of daily/weekly/monthly to output via syslog instead of mail. What I"m saying is that it takes less work overall to subtract from a system in a supportable way than it is to try and handcraft an unsupportable system.
Re: ulpt vs kernel relinking
* Antoine Jacoutot le [10-05-2019 14:41:08 +0200]: > On Thu, May 09, 2019 at 11:41:17PM -0600, Theo de Raadt wrote: > > config -e is incompatible with the KARL relinking sequence. > > > > For now, we consider KARL more valuable than config -e usage > > patterns. > > > > We've thought about this but for now we don't have a clever > > solution to solve this. > Thanks for enlightenment. > Usual disclaimer, you're on your own etc... > You can probably do something like this in /etc/rc.shutdown: > > printf 'disable ulpt\nq\n' | config -ef /bsd > sha256 /bsd >/var/db/kernel.SHA256 Indeed, this removes wanings. Thank you.
Re: Criteria for errata
Jeremy O'Brien(neut...@fastmail.com) on 2019.05.10 10:30:42 -0400: > On Fri, May 10, 2019, at 09:58, Jonathan Gray wrote: > > On Fri, May 10, 2019 at 09:14:00AM -0400, Ted Unangst wrote: > > > Jeremy O'Brien wrote: > > > > I've snagged the 6.5 xenocara.tar.gz, patched it with just that above > > > > fix, and installed it on my system which has made X rock-stable for me. > > > > This is totally fine for me personally, but I was curious if other > > > > people have run into this issue on their 6.5 installs, and if so, is > > > > this something worth pushing a reliability errata out for? I'm > > > > unfamiliar with how the process traditionally works so please excuse me > > > > if the question is outlandish. > > > > > > security issues and major reliability issues. but we try not to spend all > > > our > > > time making errata. that fix may be a contender. depends on how widely > > > reported it is. > > > > > > > vga arbiter is only used with multiple cards which isn't the common case > > > > That's how I understood the bug too, but when I enabled a debug build of > xenocara and examined the core dump after a crash, I had the same > "VGAarbiterSpriteMoveCursor" recursive-stack backtrace as in that bug report. I dont know much about xenocara, but i think that including dmesg and maybe /var/log/Xorg.0.log output in your mail can't hurt.
Re: ulpt vs kernel relinking
I cooked up a diff like this once, but I dont really use it any more.
diff --git a/libexec/reorder_kernel/reorder_kernel.sh
b/libexec/reorder_kernel/reorder_kernel.sh
index d8b8a2d24a..b59faca992 100644
--- a/libexec/reorder_kernel/reorder_kernel.sh
+++ b/libexec/reorder_kernel/reorder_kernel.sh
@@ -26,6 +26,7 @@ df -t nfs /usr/share >/dev/null 2>&1 && exit 1
KERNEL=$(sysctl -n kern.osversion)
KERNEL=${KERNEL%#*}
KERNEL_DIR=/usr/share/relink/kernel
+KERNEL_CONF=/etc/kernel.conf
LOGFILE=$KERNEL_DIR/$KERNEL/relink.log
PROGNAME=${0##*/}
SHA256=/var/db/kernel.SHA256
@@ -63,6 +64,14 @@ fi
cd $KERNEL_DIR/$KERNEL
make newbsd
+
+# Configure custom kernel options
+if [[ -f $KERNEL_CONF ]]; then
+ while read _option; do
+ printf "%s\nquit" "$_option" | config -fe bsd
+ done < $KERNEL_CONF
+fi
+
make newinstall
echo "\nKernel has been relinked and is active on next reboot.\n"
On Thu, 09 May 2019 23:41:17 -0600
"Theo de Raadt" wrote:
> config -e is incompatible with the KARL relinking sequence.
>
> For now, we consider KARL more valuable than config -e usage
> patterns.
>
> We've thought about this but for now we don't have a clever
> solution to solve this.
>
> Thuban wrote:
>
> > Hi,
> > I have a printer that require ulpt to be disabled
> > as mentionned in /usr/local/share/doc/pkg-readmes/cups. And it works.
> >
> > # config -fe /bsd
> > disable ulpt
> > quit
> >
> > After a reboot, I can notice :
> >
> > reorder_kernel: kernel relinking failed; see
> > /usr/share/relink/kernel/GENERIC.MP/relink.log
> >
> > Ok, so I run, as mentioned in the above file :
> >
> > sha256 -h /var/db/kernel.SHA256 /bsd
> >
> > However, at next reboot, ulpt is reenabled.
> >
> > How can I still have KARL and use my printer ?
> >
> >
> > --
> > thuban
> >
>
bgpd : route in FIB, not in kernel route table
Hi,
I had a weird problem today that I can't explain when I tried to add a peer
(185.22.129.11) to bgpd.
The prefix was accepted, shows up in RIB as valid, installed in FIB according to
bgpctl but kernel could not find a route. Group "liopen" provides a fullview.
OpenBSD-current from May 8th.
I had to restart bgpd for the route to show up.
Any idea what happened ?
rt-grav-02# bgpctl sh fib 193.169.46.0/23
flags: * = valid, B = BGP, C = Connected, S = Static, D = Dynamic
N = BGP Nexthop reachable via this route
r = reject route, b = blackhole route
flags prio destination gateway
*B 48 193.169.46.0/23 185.22.129.11
rt-grav-02# route get 193.169.46.0/23
get net 193.169.46.0/23: not in table
My config file :
AS 60983
router-id 185.22.128.253
neighbor 185.22.129.11 {
remote-as 49623
multihop 5
enforce neighbor-as yes
enforce local-as yes
announce IPv4 unicast
}
group "liopen" {
neighbor 2a00:6060::1 {
descr "rt-grav-01 v6"
remote-as 60983
enforce neighbor-as no
enforce local-as yes
announce IPv6 unicast
}
neighbor 185.22.129.254 {
descr "rt-grav-01 v4"
remote-as 60983
enforce neighbor-as no
enforce local-as yes
announce IPv4 unicast
}
}
match to 185.22.129.254 set { nexthop self }
allow from 185.22.129.11
allow to 185.22.129.11
allow from ibgp
allow to ibgp
allow from any prefix 0.0.0.0/0 prefixlen 8 - 24
allow from any prefix ::/0 prefixlen 16 - 48
match from any community 65535:0 set { localpref 0 }
deny quick from any AS 23456
deny quick from any AS 64496 - 131071
deny quick from any AS 42 - 4294967295
deny from any max-as-len 100
Re: GIVE UP: Re: SOLVED: Re: No more KDE's dolphin after upgrade to 6.5
On Tuesday, April 30, 2019 3:54:38 AM -04 you wrote: > Anyway, I finally had to give up! > > Even if I was then able to run both konsole and dolphin, they were > unusable. Eventually, I have done a complete FRESH NEW Install (no > Upgrade) to 6.5 (amd64), but all problems remained: a lot of kactivities > crashes, dolphin usually starts only once and then usually freezes, > okular randomly freezes too, etc, etc... > > I repeat: all this happened with a NEW Installation, even with a FRESH > home directory. > > So, I had to do a NEW Installation of 6.4 and now everything work perfectly. > > Now the question is: is there something bad in my PC (or in the > installation I have done) or I'm not the only one experiencing this and > there are some problems with the switch to the KDE KF5 apps? Federico, I recently installed OpenBSD 6.5 on my Lenovo ThinkPad X1 Carbon (4th gen), and I'm having similar issues. For example, the following command crashes the "konsole" terminal: echo hello world | vim - I see messages like the following in dmesg: trap [vim]43153/491863 type 6: sp 1e2cec6619b8 not inside 1e2cec65c000-1e2cec662000 That command works just fine in urxvt, qterminal, xterm, and st. Other programs were crashing also until I changed my user's class to staff and increased the staff resource limits. Now `htop` crashes only periodically, but I'm able to make konsole crash each and every time with the command above. So, I don't think it's just your machine. I'm happy to hear it's not my hardware either and that someone else is having the same problem. David
Re: Haskell compilation issues
Hi, > Hello, > I'm trying to start a little haskell project for the first time in a few > months. > This is the first time I'm trying to run ghc on OpenBSD > I'm not sure what ghc's problem is, I've pasted the error message below > along with the version of ld and dmesg > > I'm pretty sure that this is an openbsd problem. It's more a problem of ghc (8.2) trying to make guesses about the installed toolchain in a way that doesn't work correctly on OpenBSD. > The only "fix" I was able > to find was this: https://gitlab.haskell.org/ghc/ghc/issues/8825 > However, setting the locale had no effect. > I have also copied the version of ghc and the output of locale below. > > I appreciate any kind of help. > > --- ghc output --- > [1 of 1] Compiling Main ( Main.hs, Main.o ) > Linking Main ... > > : error: > Warning: Couldn't figure out linker information! > Make sure you're using GNU ld, GNU gold or the built in OS X > linker, etc. That error isn't an error but just a warning which gets misinterpreted by (probably) the ghc driver. If you check the exit code of ghc, you'll notice that it's 0. And if you ls -l, you'll see a perfect 'Main' executable. I think this should be fixed in ghc-8.6, but I can't check it now, because I managed to brick my build machine. I hope to fix it next monday and continue to work on a update of our ghc port. Ciao, Kili ps: please note that I'm not subscribed to misc@ with my 'real' mail account, only with a crappy gmail account I'm only reading on my tablet (from which I forwarded your mail to my real address). So better cc' me if you've any other questions ;-)
Re: Criteria for errata
On Fri, May 10, 2019, at 13:29, Sebastian Benoit wrote: > Jeremy O'Brien(neut...@fastmail.com) on 2019.05.10 10:30:42 -0400: > > On Fri, May 10, 2019, at 09:58, Jonathan Gray wrote: > > > On Fri, May 10, 2019 at 09:14:00AM -0400, Ted Unangst wrote: > > > > Jeremy O'Brien wrote: > > > > > I've snagged the 6.5 xenocara.tar.gz, patched it with just that above > > > > > fix, and installed it on my system which has made X rock-stable for > > > > > me. This is totally fine for me personally, but I was curious if > > > > > other people have run into this issue on their 6.5 installs, and if > > > > > so, is this something worth pushing a reliability errata out for? I'm > > > > > unfamiliar with how the process traditionally works so please excuse > > > > > me if the question is outlandish. > > > > > > > > security issues and major reliability issues. but we try not to spend > > > > all our > > > > time making errata. that fix may be a contender. depends on how widely > > > > reported it is. > > > > > > > > > > vga arbiter is only used with multiple cards which isn't the common case > > > > > > > That's how I understood the bug too, but when I enabled a debug build of > > xenocara and examined the core dump after a crash, I had the same > > "VGAarbiterSpriteMoveCursor" recursive-stack backtrace as in that bug > > report. > > I dont know much about xenocara, but i think that including dmesg and > maybe /var/log/Xorg.0.log output in your mail can't hurt. > I already have a bug report sent to bugs@ https://marc.info/?l=openbsd-bugs&m=155716824903439&w=2
Re: When will be created a great desktop experience for OpenBSD?
On 08/05/2019, Steve Litt wrote: > ...you'd better crank way up on its fonts. Fvwm fonts > are so small that if you have bad vision, you can't read the screen > well enough to increase the font size. > > It's easy for a well-sighted person to reduce fonts, but for the poorly > sighted person who can't read the screen in the first place, it's a > long, difficult process. Have you or has anyone ever set up Compiz zoom (Enhanced Zoom Desktop in ccsm) on an OpenBSD box? I don't even know what Desktop Environments and Window Managers would be compatible with it, and this isn't something I have tried, but it may be worth investigating in your situation. Hmm... https://www.google.com/search?q=site:ports.su+compiz Also, if you'd still be happy to give me a clue on the below, I'd still be grateful after all: > > I know a much better way, but it involves installing a lightweight > > $this_other_launcher with almost zero dependencies, so I won't talk > > about it. > > > > SteveT > > Okay, so now I *AM* curious and *would* be thankful if you could elaborate. > You win. Sorry for being such an overly restrictive ass earlier.
Re: Criteria for errata
> > > That's how I understood the bug too, but when I enabled a debug build of > > > xenocara and examined the core dump after a crash, I had the same > > > "VGAarbiterSpriteMoveCursor" recursive-stack backtrace as in that bug > > > report. > > > > I dont know much about xenocara, but i think that including dmesg and > > maybe /var/log/Xorg.0.log output in your mail can't hurt. > > > > I already have a bug report sent to bugs@ > > https://marc.info/?l=openbsd-bugs&m=155716824903439&w=2 > A few weeks ago, I was told that this fix was added to -current. I cannot find the email now though.
Re: Danish FreeBSD Developer hates jews collectively
On Fri, 10 May 2019 08:56:48 -0800 Robert Wing wrote: > At the cost of sending more spam to the FreeBSD-Current mailing > list... > > I'm posting the following excerpt taken from the FreeBSD website as a > reminder to those subscribed to this list and who continue to spam it: > > "This is the mailing list for users of freebsd-current. It includes > warnings about new features coming out in -current that will affect > the users, and instructions on steps that must be taken to remain > -current. Anyone running "current" must subscribe to this list." Im not sure that freebsd.org is tech resource after it apply CoC.
Re: Criteria for errata
On Fri, May 10, 2019, at 17:33, Joe M wrote: > > > > That's how I understood the bug too, but when I enabled a debug build > > > > of xenocara and examined the core dump after a crash, I had the same > > > > "VGAarbiterSpriteMoveCursor" recursive-stack backtrace as in that bug > > > > report. > > > > > > I dont know much about xenocara, but i think that including dmesg and > > > maybe /var/log/Xorg.0.log output in your mail can't hurt. > > > > > > > I already have a bug report sent to bugs@ > > > > https://marc.info/?l=openbsd-bugs&m=155716824903439&w=2 > > > > A few weeks ago, I was told that this fix was added to -current. I > cannot find the email now though. > Yeah it is. I've had hard lockups on -current which is keeping me on stable for now.
Re: Criteria for errata
On Fri, May 10, 2019, at 16:40, Jeremy O'Brien wrote: > On Fri, May 10, 2019, at 13:29, Sebastian Benoit wrote: > > Jeremy O'Brien(neut...@fastmail.com) on 2019.05.10 10:30:42 -0400: > > > On Fri, May 10, 2019, at 09:58, Jonathan Gray wrote: > > > > On Fri, May 10, 2019 at 09:14:00AM -0400, Ted Unangst wrote: > > > > > Jeremy O'Brien wrote: > > > > > > I've snagged the 6.5 xenocara.tar.gz, patched it with just that > > > > > > above fix, and installed it on my system which has made X > > > > > > rock-stable for me. This is totally fine for me personally, but I > > > > > > was curious if other people have run into this issue on their 6.5 > > > > > > installs, and if so, is this something worth pushing a reliability > > > > > > errata out for? I'm unfamiliar with how the process traditionally > > > > > > works so please excuse me if the question is outlandish. > > > > > > > > > > security issues and major reliability issues. but we try not to spend > > > > > all our > > > > > time making errata. that fix may be a contender. depends on how widely > > > > > reported it is. > > > > > > > > > > > > > vga arbiter is only used with multiple cards which isn't the common case > > > > > > > > > > That's how I understood the bug too, but when I enabled a debug build of > > > xenocara and examined the core dump after a crash, I had the same > > > "VGAarbiterSpriteMoveCursor" recursive-stack backtrace as in that bug > > > report. > > > > I dont know much about xenocara, but i think that including dmesg and > > maybe /var/log/Xorg.0.log output in your mail can't hurt. > > > > I already have a bug report sent to bugs@ > > https://marc.info/?l=openbsd-bugs&m=155716824903439&w=2 > > Gah sorry. I confused myself. The report I linked has nothing to do with the (already fixed in -current) VGAarbiterSpriteMoveCursor issue.
Re: Haskell compilation issues
On Fri, May 10, 2019 at 02:50:49PM +, Kaleta wrote: > Hello, > I'm trying to start a little haskell project for the first time in a few > months. > This is the first time I'm trying to run ghc on OpenBSD > I'm not sure what ghc's problem is, I've pasted the error message below along > with the version of ld and dmesg > > I'm pretty sure that this is an openbsd problem. The only "fix" I was able to > find was this: https://gitlab.haskell.org/ghc/ghc/issues/8825 > However, setting the locale had no effect. > I have also copied the version of ghc and the output of locale below. > > I appreciate any kind of help. > > --- ghc output --- > [1 of 1] Compiling Main ( Main.hs, Main.o ) > Linking Main ... It's been a while since I've worked in haskell on OpenBSD but, for what I recall, this > : error: > Warning: Couldn't figure out linker information! > Make sure you're using GNU ld, GNU gold or the built in OS X > linker, etc. should not matter (don't know if it's relevant on 6.5 though.) What I think it's required to compile and run haskell program is to wxallow the partition. If you're using the standard layout the /tmp and /home should be wxallowed. Hope it helps! PS: I read somewhere a guy that did some fancy things in order to not wxallow /home, something like linking directory from /usr/local to the user home, but I don't recall now, nor I remember if it was actually "safe". > --- ghc -v output --- > Glasgow Haskell Compiler, Version 8.2.2, stage 2 booted by GHC version > 8.2.2.20180330 > Using binary package database: /usr/local/lib/ghc/package.conf.d/package.cache > package flags [] > loading package database /usr/local/lib/ghc/package.conf.d > wired-in package ghc-prim mapped to ghc-prim-0.5.1.1 > wired-in package integer-gmp mapped to integer-gmp-1.0.1.0 > wired-in package base mapped to base-4.10.1.0 > wired-in package rts mapped to rts > wired-in package template-haskell mapped to template-haskell-2.12.0.0 > wired-in package ghc mapped to ghc-8.2.2 > wired-in package dph-seq not found. > wired-in package dph-par not found. > *** Deleting temp files: > Deleting: > *** Deleting temp dirs: > Deleting: > ghc: no input files > Usage: For basic information, try the `--help' option. > > --- ld -v output --- > LLD 7.0.1 (compatible with GNU linkers) > > --- locale output --- > LANG= > LC_COLLATE="C" > LC_CTYPE=en_US.UTF-8 > LC_MONETARY="C" > LC_NUMERIC="C" > LC_TIME="C" > LC_MESSAGES="C" > LC_ALL= > > --- dmesg --- > OpenBSD 6.5 (GENERIC.MP) #3: Sat Apr 13 14:48:43 MDT 2019 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 4156157952 (3963MB) > avail mem = 4020568064 (3834MB) > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xdae9c000 (65 entries) > bios0: vendor LENOVO version "8DET55WW (1.25 )" date 11/01/2011 > bios0: LENOVO 42912XG > acpi0 at bios0: rev 2 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP SLIC SSDT SSDT SSDT HPET APIC MCFG ECDT ASF! TCPA > SSDT SSDT UEFI UEFI UEFI > acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP4(S4) EXP7(S4) EHC1(S3) > EHC2(S3) HDEF(S4) > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpihpet0 at acpi0: 14318179 Hz > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Core(TM) i5-2540M CPU @ 2.60GHz, 2591.95 MHz, 06-2a-07 > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu0: 256KB 64b/line 8-way L2 cache > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges > cpu0: apic clock running at 99MHz > cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE > cpu1 at mainbus0: apid 1 (application processor) > cpu1: Intel(R) Core(TM) i5-2540M CPU @ 2.60GHz, 2591.59 MHz, 06-2a-07 > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu1: 256KB 64b/line 8-way L2 cache > cpu1: smt 1, core 0, package 0 > cpu2 at mainbus0: apid 2 (application processor) > cpu2: Intel(R) Core(TM) i5-2540M CPU @ 2.60GHz, 2591.58 MHz, 06-2a-07 > cpu2: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,M
Re: Error Upgrading 6.4 to 6.5 mount failure
Antonino Sidoti wrote: [1. image/png; Screen Shot 2019-05-11 at 8.43.13 am.png]... Antonino, If you can't file a proper bug report as described in many places -- such as the FAQ -- that is just lazy and inconsiderate. You are pushing others to go out of their way for some random person who elects to steal their time. Grow up. Be a responsibile adult. Do it right, or go run something else, or even consider buying a product.
