why thread is not usable in perl5 of OpenBSD6.4?
I have to use thread on the perl5 of OpenBSD 6.4. However, it was disabled on the distribution. I tried to make the thread active to recompile the perl5 with -Dusethreads, which led me to many test fails. Why the thread function was disabled in this release? Is it security reason? Kenji
Common Lisp and OpenBSD
There don't seem to be any Common Lisp libraries available as packages. I'd be interested in packaging the most common and mature Common Lisp libraries, but I'm not certain who I'd discuss this with. I'd appreciate any help with getting started contributing to OpenBSD.
Re: Common Lisp and OpenBSD
On Sun, 2018-11-25 at 05:17 -0500, Programmer wrote: > There don't seem to be any Common Lisp libraries available as > packages. I'd be interested in packaging the most common and mature > Common Lisp libraries, but I'm not certain who I'd discuss this with. > > I'd appreciate any help with getting started contributing to OpenBSD. > I found a guide at https://www.openbsd.org/faq/ports/. There is also a ports mailing list. -- Kristjan Komloši -- Dobite me lahko preko/you can contact me through: Mail (šola/school): kristjan.koml...@sg.sckr.si Mail (privat/private): kristjan.koml...@gmail.com Tel: +386 31 679 339 (po 14. uri / after 14:00)
Re: Common Lisp and OpenBSD
Programmer wrote: > There don't seem to be any Common Lisp libraries available as > packages. I'd be interested in packaging the most common and mature > Common Lisp libraries, but I'm not certain who I'd discuss this with. > > I'd appreciate any help with getting started contributing to OpenBSD. hello What software requires porting common lisp libraries? There is no point in doing ports for CL libraries if it's not used by a port. We already have a few CL software in ports, and none requires ported libs: - net/clic uses no lib - sysutils/cl-launch uses no lib - sysutils/reed-alert uses no lib - x11/spectrwm uses no lib - x11/stumpwm uses 2 libs which are downloaded before compiling the port and then, stumpwm is compiled as a binary, including the libs I already been thinking about packaging some libs but I found no software to port to use them. If a software would requires too much libs, it may be easier (as we do for go packages) to use quicklisp to create a folder embedding the libraries, and use that tarball for compiling it. I also had patches for lang/sbcl and lang/ecl to add a system wide folder into the asdf loading path in case we wanted to port libs see https://marc.info/?l=openbsd-ports&m=147983440719241&w=2
Re: X won't start with latest snapshot as user (Solution provided)
On 0926, Edgar Pettijohn III wrote: > > On 11/11/18 12:59 AM, Marc Espie wrote: > > On Sat, Nov 10, 2018 at 10:42:57PM -0600, Andrew wrote: > > > Personally I use spectrwm, so I can't speak for other the wm's. In my > > > case, all I had to do was: > > > > > > $> cp .xinitrc .xsession > > > $> chmod +x .xsession > > > > > > ... and it "just worked" as expected :-) > > You were lucky to not have something interesting in your .profile > > That one got me. > > > you weren't alone. took me a while to figure out why stuff didn't work how > it did before. :) > +1 . ~/.profile helped me in ~/.xsession.
Re: smtpd.conf and junk
On Wed, Nov 21, 2018 at 09:21:46PM +0100, Thuban wrote: > * Gilles Chehade le [21-11-2018 21:06:39 +0100]: > > On Wed, Nov 21, 2018 at 06:38:43PM +0100, Thuban wrote: > > > * Edgar Pettijohn le [21-11-2018 11:32:43 > > > -0600]: > > > > > > > > On Nov 21, 2018 8:22 AM, Thuban wrote: > > > > > > > > > > Hi, > > > > > I can't figure how to make this "junk" argument to work as > > > > > mentioned in The smtpd.conf manpages : > > > > > > > > > > If the junk argument is provided, the message will be > > > > > moved to the Junk folder if it contains a positive X-Spam > > > > > header. > > > > > > > > > > > > > > > spams detected by spamassassin have multiple X-Spam-* headers, but > > > > > aren't placed > > > > > into Junk folder. > > > > > > > > > > Any advice ? > > > > > > > > > > > > > > > > > > > > -- > > > > > ?? thuban > > > > > > > > > It looks for a header matching: > > > > > > > > X-Spam: Yes > > > > > > > > You may need to configure spamassassin to write it that way. I believe > > > > that the default is different, but I can't check right now. > > > > > > > > > > I tried to add this in spamassassin.conf [0] : > > > > > > add_header spam X-Spam > > > > > > But if you read the link [0] closely, it can't work because spamassassin > > > add > > > headers "X-Spam-someting", never "X-Spam" : > > > > > > All headers begin with X-Spam- (so a header_name Foo will generate a > > > header called X-Spam-Foo) > > > > > > I guess the "junk" keyword in smtpd.conf was written to be handy, so I > > > miss > > > something. Where ? > > > > > > > You didn't miss anything, the maildir agent only supports X-Spam headers > > as of today so this will need a diff to support SpamAssassin if it can't > > generate a X-Spam header. > > > > Okay, thanks, I doubt since english is not my main language. > > > SpamAssassin wasn't a target when I wrote that feature but it's just one > > diff away ;-) > > > > Just need to check "X-Spam-Flag: YES" or "X-Spam-Status: Yes,.*" then. > > Just curious, what was the target of that 'junk' feature ? rspamd ? Another ? > > Regards. > in -current, maildir junk now recognizes X-Spam-Flag: YES cheers, -- Gilles Chehade @poolpOrg https://www.poolp.org tip me: https://paypal.me/poolpOrg
Help with LibreSSL manpages
Hello, I've recently been getting into (re)writing my manpages using mdoc(7), and came across Ingo's talk about mandoc/LibreSSL [1]. In it he mentioned that there are still some functions to document and many pages need a couple of goes over (specifically openssl(1)). Now I've never developed for Open/LibreSSL, and have an OK knowledge of C, but I do have a bit of free time over Christmas and would be happy to help out in any way. Would I need to fully grok the code before I could write the docs? [1] https://www.openbsd.org/papers/eurobsdcon2018-mandoc.pdf -- Stephen Gregoratto
Re: Help with LibreSSL manpages
Hi Stephen, Stephen Gregoratto wrote on Mon, Nov 26, 2018 at 12:26:21AM +1100: > I've recently been getting into (re)writing my manpages using mdoc(7), > and came across Ingo's talk about mandoc/LibreSSL [1]. In it he > mentioned that there are still some functions to document and many > pages need a couple of goes over (specifically openssl(1)). > > Now I've never developed for Open/LibreSSL, That will make the learning curve significantly steeper, but it should still be possibly to help. You should expect to spend considerable amounts of time learning how the features you are trying to document work, though, in addition to the time needed to work on the text itself. > and have an OK knowledge of C, That is good. > but I do have a bit of free time over Christmas If you never plan to come back to the project in 2019 or later, i have some doubts as to how much you can get done. If one or two weeks is all the time you have to spend, most of that will be used up learning about LibreSSL, mdoc, and about how OpenBSD development works in general. If you have some time now and are not yet sure whether you might be interested to work again on it in the future but consider that possible, just try. > and would be happy to help out in any way. That's quite welcome. > Would I need to fully grok the code before I could write the docs? Absolutely not. You could spend an infinite amount of time to understand the code if you tried to understand everything. Of course, there is nothing wrong with studying whatever interests you. But if your main goal is to improve the docs, you only need to look at the code when it is unclear what a given feature does or how it must be used, and you only need to understand enough of the code such that you can can answer these two questions. Judging from how you describe your knowledge and experience, i (wildly) *guess* that the main challenges might be: * Figuring out what are gaps in the documentation and what is intentionally undocumented (as i explained in the talk, that's a serious problem for anyone, even for me, heck, even for jsing@). * Getting used to the style of OpenBSD documentation (assuming i understand correctly that you never provided significant contributions to OpenBSD docs before). You can't learn that style from LibreSSL docs because they are written in a different style, in OpenSSL style. The only way to learn that style is trial and error, discussing your patches with OpenBSD developers, and occasionally looking at OpenBSD libc section 2 and section 3 manual pages. * Getting used to the way OpenBSD development works. You learn that by sending patches and listening to the feedback. * Getting used to the mdoc(7) languange. You learn that by reading mdoc(7), sending patches, and listening to the feedback. It's likely the least of the challenges. Now, where should you start, both in the sense of choosing a subject area and in the sense of choosing a working style? Regarding the subject area / sub-library: if there is an area you are personally interested in, start with that. Otherwise, consider starting with something that is important (BN_*, EVP_*, RSA_*) or modern (EC*, TLS 1.3). If you ever enter into a coversation with jsing@ over one of your patches, ask him what is most urgent. Possible working styles depend on what you are best at. * Copy editing: read existing manuals, improve the style, make it more concise, more precise, clearer, close gaps. Also fix the order of information. Needed almost everywhere. Works best with a strong understanding of OpenBSD manual style. * New pages: take an important or modern sub-library, look at the public headers and identify undocumented functions. Check with LibreSSL developers which ones should be documented. Write new manuals. Needed almost everywhere. Requires moderate experience writing function manuals from scratch. * Hunting for bugs: compare docs and code and identify contradictions between both: mismatches between argument types in the *.h, *.c, and *.3 files, mismatches of return types, wrong .In lines, typos in function names or other parts of prototypes, statements about behaviour or usage that contradict the code. Can be tedious and take quite some time with little visible results, but requires less experience and has the side-effect of building familiarity with the code and docs. Note that the page openssl(1) is a special case. It already had basic copy editing by jmc@ regarding style and language, but it could use more checking and improving of the content. Since it is merely a testing tool, it is not the most important part; the reason for mentioning it in the talk was that it is a part that so far had less review than other parts, no matter the importance. If you still don't have a clear preference how to start, one useful approach that i'd recommend is to go through recent LibreSSL com
Re: smtpd.conf and junk
* Gilles Chehade le [25-11-2018 15:30:20 +0100]: > On Wed, Nov 21, 2018 at 09:21:46PM +0100, Thuban wrote: > > * Gilles Chehade le [21-11-2018 21:06:39 +0100]: > > > On Wed, Nov 21, 2018 at 06:38:43PM +0100, Thuban wrote: > > > > * Edgar Pettijohn le [21-11-2018 11:32:43 > > > > -0600]: > > > > > > > > > > On Nov 21, 2018 8:22 AM, Thuban wrote: > > > > > > > > > > > > Hi, > > > > > > I can't figure how to make this "junk" argument to work as > > > > > > mentioned in The smtpd.conf manpages : > > > > > > > > > > > > If the junk argument is provided, the message will be > > > > > > moved to the Junk folder if it contains a positive X-Spam > > > > > > header. > > > > > > > > > > > > > > > > > > spams detected by spamassassin have multiple X-Spam-* headers, but > > > > > > aren't placed > > > > > > into Junk folder. > > > > > > > > > > > > Any advice ? > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > ?? thuban > > > > > > > > > > > It looks for a header matching: > > > > > > > > > > X-Spam: Yes > > > > > > > > > > You may need to configure spamassassin to write it that way. I > > > > > believe that the default is different, but I can't check right now. > > > > > > > > > > > > > I tried to add this in spamassassin.conf [0] : > > > > > > > > add_header spam X-Spam > > > > > > > > But if you read the link [0] closely, it can't work because > > > > spamassassin add > > > > headers "X-Spam-someting", never "X-Spam" : > > > > > > > > All headers begin with X-Spam- (so a header_name Foo will > > > > generate a header called X-Spam-Foo) > > > > > > > > I guess the "junk" keyword in smtpd.conf was written to be handy, so I > > > > miss > > > > something. Where ? > > > > > > > > > > You didn't miss anything, the maildir agent only supports X-Spam headers > > > as of today so this will need a diff to support SpamAssassin if it can't > > > generate a X-Spam header. > > > > > > > Okay, thanks, I doubt since english is not my main language. > > > > > SpamAssassin wasn't a target when I wrote that feature but it's just one > > > diff away ;-) > > > > > > > Just need to check "X-Spam-Flag: YES" or "X-Spam-Status: Yes,.*" then. > > > > Just curious, what was the target of that 'junk' feature ? rspamd ? Another > > ? > > > > Regards. > > > > in -current, maildir junk now recognizes X-Spam-Flag: YES Thank you, I'll give it a try. For now, I use dovecot + lmtp and sieve for this (a bit too much...)
Re: Common Lisp and OpenBSD
On Sun, Nov 25, 2018 at 05:17:20AM -0500, Programmer wrote: > There don't seem to be any Common Lisp libraries available as > packages. I'd be interested in packaging the most common and mature > Common Lisp libraries, but I'm not certain who I'd discuss this with. > > I'd appreciate any help with getting started contributing to OpenBSD. Dear Programmer, I am not going to tell you what to do, but if I had enough free time to consider such projects, I would go and ask if Quicklisp project needs some help from me (in case you do not know, it is a package installer for Common Lisp). https://www.quicklisp.org/beta/ http://blog.quicklisp.org/2018/10/october-2018-quicklisp-dist-update-now.html Zach Beane is the author (it seems) and is doing enormous job. It looks like in best case you would be replicating his work, which, with all due respect to OpenBSD, might get ignored if you cannot keep up with updating ports at his speed. I, for one example, would rather stick with quicklisp, because it is going to work everywhere when CL is installed (well, mostly). While I have never done it, I guess making one system wide quicklisp install is easy to do, probably just add user and have his quicklisp files word- or group readable. And have users read this guy's setup.lisp from quicklisp install. And quicklisp allows me to keep using old versions of installed libs, which ports cannot give me, AFAICT. This one feature is worth going QL way. At least to me. HTH -- Regards, Tomasz Rola -- ** A C programmer asked whether computer had Buddha's nature. ** ** As the answer, master did "rm -rif" on the programmer's home** ** directory. And then the C programmer became enlightened... ** ** ** ** Tomasz Rola mailto:tomasz_r...@bigfoot.com **
Re: Common Lisp and OpenBSD
I appreciate all the help. I'll continue this discussion in the ports mailing list so I don't clutter misc.
Re: Common Lisp and OpenBSD
On Sun, Nov 25, 2018 at 04:54:24PM +0100, Tomasz Rola wrote: > On Sun, Nov 25, 2018 at 05:17:20AM -0500, Programmer wrote: > > There don't seem to be any Common Lisp libraries available as > > packages. I'd be interested in packaging the most common and mature > > Common Lisp libraries, but I'm not certain who I'd discuss this with. > > > > I'd appreciate any help with getting started contributing to OpenBSD. > > Dear Programmer, > > I am not going to tell you what to do, but if I had enough free time > to consider such projects, I would go and ask if Quicklisp project > needs some help from me (in case you do not know, it is a package > installer for Common Lisp). > > https://www.quicklisp.org/beta/ > > http://blog.quicklisp.org/2018/10/october-2018-quicklisp-dist-update-now.html > > Zach Beane is the author (it seems) and is doing enormous job. It > looks like in best case you would be replicating his work, which, with > all due respect to OpenBSD, might get ignored if you cannot keep up > with updating ports at his speed. I, for one example, would rather > stick with quicklisp, because it is going to work everywhere when CL > is installed (well, mostly). > > While I have never done it, I guess making one system wide quicklisp > install is easy to do, probably just add user and have his quicklisp > files word- or group readable. And have users read this guy's > setup.lisp from quicklisp install. System wide installations of third party package managers are usually a bad idea. It could give you problems in the future with the OpenBSD packages. Use always a local installation in your home or project directory. > > And quicklisp allows me to keep using old versions of installed libs, > which ports cannot give me, AFAICT. This one feature is worth going QL > way. At least to me. > > HTH > > -- > Regards, > Tomasz Rola > > -- > ** A C programmer asked whether computer had Buddha's nature. ** > ** As the answer, master did "rm -rif" on the programmer's home** > ** directory. And then the C programmer became enlightened... ** > ** ** > ** Tomasz Rola mailto:tomasz_r...@bigfoot.com ** > -- Juan Francisco Cantero Hurtado http://juanfra.info
apmd: howto resume with screen locked
Hi everyone i have in my /etc/rc.conf.local apmd "-A -Z8 -t120" my laptop doesn't hibernate when the power falls below 8% is there more that i need to configure ? shadrock
apmd: howto resume with screen locked
also how do i resume from hibernate or suspend with the screen locked i use i3 and lock the screen with xautolock and i3lock in .i3/config i put i3lock in /etc/apm/resume when i resume from ZZZ no lock screen appears, i am brought straight to my desktop shadrock
Re: apmd: howto resume with screen locked
On 11/25/18 7:16 PM, shadrock uhuru wrote: Hi everyone i have in my /etc/rc.conf.local apmd "-A -Z8 -t120" my laptop doesn't hibernate when the power falls below 8% is there more that i need to configure ? shadrock try: rcctl set apmd status on rcctl set apmd flags -A -Z 8 -t 120 rcctl start apmd
FVWM basic config file
Hello Misc, I have read some post about getting along with the default WM, i mean complaining about configuring it, saying that the man page its dificult and stuff, and then saddly going to another WM. I my OpenBSD era (from 60 to date) i was using cwm but wondering why they say that Theo uses fvwm, so i wondered that maybe it is worth it to try. So i attach my .fvwmrc and i hope that will help someone to start tweaking it and get along with it and be happy with it. I think that the config file is basic enough to start (for me it helped to migrate from cwm) and has a good bindings that one might find useful as: - Control + arrow navigation between pages - Control + Meta + number to move window to page (i couldnt make it dinamically so it could work if its more than 9 pages, sorry about that) - Shift + Left/right to circulate focus between open windows (Like alt tab) - Control + Meta + arrows to snap window to left, right, maximize and iconify (that is my favorite) - Meta + d dmenu (pkg_add dmenu) - Meta + i screenshot ( pkg_add ImageMagick) - Meta + x close window - Control + Meta + p power off - Meta + t make it transparent (pkg_add transset-df) - Meta + m move window - It uses feh to set the wallpaper - It uses conky for basic info - It uses dmenu to fast start applications. I am eager to share it here since it works for the fvwm in base 64, i noticed that there are plenty config files online but they are meant for a newer fvwm that is not in OpenBSD and i couldnt make it work, even i was tempted to post a mail asking for Theo´s config file but i had the impression that the answer would be as fun and educational as always. Again, i hope that it helps. Manuel Solis # This is a customized file based on the bare bones sample .fvwm2rc/system.fvwm2rc # file for fvwm-2. It is the combination of hints for the other .fvwm2rc files # samples, as well as pointers from the various links on the official fvwm web # page (see the FAQ). For questions ask man page. Key Bindings # some simple default mouse bindings: # for the root window: Mouse1RANop Mouse 3R A Menu RootMenu Nop # for the title bar buttons: Mouse 01A Menu Window-Ops2 Close Mouse 02A Maximize-Func Mouse 04A Iconify # for other parts of the window/borders/icons: Mouse 1FAResize-or-Raise Mouse 1TSAMove-or-Raise Mouse 1IAMove-or-Iconify Mouse 2IAIconify Mouse 2FSTAMenu Window-Ops2 Nop Mouse 3TSIFARaiseLower # some simple default key bindings: # Arrow Keys # press arrow + control anywhere, and scroll by 1 page Key LeftACScroll -100 0 Key RightACScroll +100 +0 Key UpACScroll +0 -100 Key DownACScroll +0 +100 # press arrow + Meta anywhere, and Snap Right/Left, Maximize or iconify Key LeftACMLeftSnap Key RightACMRightSnap KeyUpACMMaximize 100 97 KeyDownACMIconify # Shift + arrow to circulate focos between programs # Similar to Alt + Tab Key Left ASPrev [*] FocusAndWarp Key RightASNext [*] FocusAndWarp KeySuper_RAAWindowList # Alt - Tab function to circulate focus between programs #Key Tab A M Next [*] FocusAndWarp # Key bindings # Press Meta + Keys bindings Key Return AMExec /usr/X11R6/bin/xterm Key dAMExec /usr/local/bin/dmenu_run Key iAMExec /usr/local/bin/import -window root $HOME/screenshot.jpg KeykAMExec setxkbmap -layout us KeylAMExec setxkbmap -layout es KeymAMMove #Exec /usr/X11R6/bin/xterm -e man fvwm Key tAMExec /usr/local/bin/transset-df -p -t 0.6 #transparent window KeyxWMDelete KeyxIMDestroy KeyrACMRestart /usr/X11R6/bin/fvwm # Press Meta + Ctrl + Keys bindings KeypACMExec /usr/bin/doas halt -p # Keyboard accelerators Key F1AMMenu RootMenu Key F2AMMenu Window-Ops Key F3AMWindowList FvwmWinList Key F4AMIconify Key F5AMMove Key F6AMResize #Key F7AMCirculateUp #Key F8AMCirculateDown Key1WCMMuevePagina 0 0 Key2WCMMuevePagina 1 0 Key3WCMMuevePagina 2 0 Key4WCMMuevePagina 0 1 Key5WCMMuevePagina 1 1 Key6WCMMuevePagina 2 1 Key7WCMMuevePagina 0 2 Key8WCMMuevePagina 1 2 Key9WCMMuevePagina 2 2 Global Settings # be sure to customize these paths for your installation: ModulePath /
Re: FVWM basic config file
Hi Manuel, Manuel Solis wrote on Sun, Nov 25, 2018 at 08:50:23PM -0600: > I have read some post about getting along with the default WM, i mean > complaining about configuring it, saying that the man page its dificult > and stuff, and then saddly going to another WM. > > I my OpenBSD era (from 60 to date) i was using cwm but wondering why they > say that Theo uses fvwm, so i wondered that maybe it is worth it to try. The default fvwm(1) is certainly not the best part of OpenBSD - the code is old and crappy. I can't speak for Theo, but the reason i'm using it is nothing more and nothing less than that i don't want to bother configuring a window manager. If i have one complaint about the base fvwm(1) - apart from the crappy code - it is that it is way too bloated and has way too many features. For that reason, even though i'm rarely using .dot-files for any programs (except git, mutt, and ssh, which don't work at all without a config file), this is one of the few programs where i do have my own config file. The point is to get rid of all the horrible bloat in the default .fvwrc: $ grep -cv -e '^$' -e '^#' /usr/X11R6/lib/X11/fvwm/.fvwmrc 378 $ grep -cv -e '^$' -e '^#' /home/schwarze/.fvwmrc 81 Yours, Ingo $ ls ~/.profile ~/.*shrc* ~/.ex* ~/.vi* ls: /home/schwarze/.*shrc*: No such file or directory ls: /home/schwarze/.ex*: No such file or directory ls: /home/schwarze/.profile: No such file or directory ls: /home/schwarze/.vi*: No such file or directory $ cat /home/schwarze/.fvwmrc # .fvwmrc - fv window manager configuration script # Ingo Schwarze, 10.6.2001 # Version: Ingo Schwarze, 22.11.2010 # standard settings # paths ModulePath /usr/X11R6/lib/X11/fvwm PixmapPath /usr/X11R6/include/X11/pixmaps IconPath /usr/X11R6/include/X11/bitmaps # screens DeskTopSize 1x1 EdgeResistance 1 1 EdgeScroll 0 0 # windows WindowFont -adobe-times-bold-r-*-*-14-*-*-*-*-*-*-* IconFont -adobe-helvetica-bold-r-*-*-10-*-*-*-*-*-*-* AddToDecor Default HilightColor DarkRed Wheat Style "*" UseDecor Default, Color Black/LightSteelBlue Style "*" BorderWidth 7, HandleWidth 7 Style "*" Icon unknown1.xpm, IconBox 0 -10 -280 -1 Style "*" MWMFunctions, MWMDecor, HintOverride Style "*" DecorateTransient, NoPPosition Style "*" SmartPlacement, StubbornPlacement, SloppyFocus # menus MenuStyle Black LightGrey DarkGrey + -adobe-times-bold-r-*-*-12-*-*-*-*-*-*-* fvwm AddToMenu terminal + "xterm" Exec xterm -ls -geometry 80x80 + "usta" Exec xterm -T usta.de -geometry 80x80 -e /usr/bin/ssh usta AddToMenu window "window" Title + "move%jmove.xpm%" Move + "resize%jresize.xpm%" Resize + "maximize%mini.maximize-horiz.xpm%" Maximize + "raise%jraise.xpm%" Raise + "lower%jlower.xpm%" Lower + "iconify%mini.iconify.xpm%" Iconify + "stick%mini.stick.xpm%" Stick + "" Nop + "list%jwindow.xpm%" WindowList + "" Nop + "refresh%mini.refresh.xpm%" RefreshWindow + "close%mini.winXX-close.xpm%" Close + "delete%mini.cut.xpm%" Delete + "destroy%mini.destroy.xpm%" Destroy AddToMenu system "system" Title + "xlock%mini.xlock.xpm%" Exec exec xlock -mode blank + "recapture%mini.refresh.xpm%" Recapture + "xrdb -load%jx.xpm%" Exec xrdb -load $HOME/.Xdefaults + "restart%mini.excl.xpm" Restart fvwm + "scrotwm" Restart scrotwm + "quit%mini.exit.xpm%" Quit # mouse ClickTime 750 # on the wallpaper Mouse 1 R A Menu terminal Nop Mouse 2 R A Menu window Nop Mouse 3 R A Menu system Nop # in the title bar of a window Mouse 0 1 A Menu window Close Mouse 1 T A Raise Mouse 2 T A Move Mouse 3 T A Lower Mouse 0 2 A Maximize-Func Mouse 0 4 A Iconify # at the edge of a window Mouse 0 SF A Resize # in an icon Mouse 1 I A Iconify Mouse 2 I A Move Mouse 3 I A Iconify # pager AddToFunc InitFunction"I" Module FvwmPager 0 9 AddToFunc RestartFunction "I" Module FvwmPager 0 9 Style "FvwmPager" StaysOnTop, Color DimGrey/LightGrey *FvwmPagerGeometry 60x560+0+0 *FvwmPagerRows 10 *FvwmPagerColumns 1 *FvwmPagerFont -adobe-helvetica-bold-r-*-*-10-*-*-*-*-*-*-* *FvwmPagerSmallFont 5x9 *FvwmPagerFore Black *FvwmPagerBack LightGrey *FvwmPagerHilight Wheat *FvwmPagerLabel 0 "orga" *FvwmPagerLabel 1 "usta" *FvwmPagerLabel 2 "src" *FvwmPagerLabel 3 "regress" *FvwmPagerLabel 4 "man" *FvwmPagerLabel 5 "bsd.lv" *FvwmPagerLabel 6 "ports" *FvwmPagerLabel 7 "misc1" *FvwmPagerLabel 8 "misc2" *FvwmPagerLabel 9 "web" ###
Re: non-interactive sh and SIGTERM
On Fri, Nov 23, 2018 at 1:51 PM Olivier Taïbi wrote: > Sorry about the wrong report, I just tested again and I can see the same > behaviour with OpenBSD 6.4: sending SIGTERM to the sh process after > launching sh -c 'sleep 1000' does not result in sh sending a SIGTERM to > the sleep process. > Hmm, why should it? If you wanted to kill whatever processes where started from that invocation, shouldn't you send SIGTERM to the process group? > Philip, what was your test? > : morgaine; sh -c 'while :; do :; done' & [3] 16632 : morgaine; kill 16632 [3] - Terminated sh -c "while :; do :; done" : morgaine; : morgaine; sh -c 'while :; do sleep 1; done' & [3] 59539 : morgaine; kill 59539 : morgaine; [3] - Terminated sh -c "while :; do sleep 1; done" : morgaine; sh itself doesn't ignore SIGTERM, but rather exits after receiving it. Philip Guenther
Re: why thread is not usable in perl5 of OpenBSD6.4?
On Sun, Nov 25, 2018 at 1:57 AM 岡本健二 wrote: > I have to use thread on the perl5 of OpenBSD 6.4. > However, it was disabled on the distribution. > Hmm, is this something that worked in previous releases, or is something that you've only tried in OpenBSD 6.4? Off-hand, it's still disabled by default in the Configure script that perl people ship, and I don't see anything in the OpenBSD bits to override their choice. > I tried to make the thread active to recompile the perl5 with -Dusethreads, > which led me to many test fails. > Were there tests that failed with -Dusethreads that passed when that wasn't used? If so, which, and what was their output? To put it another way: if you're suggesting that we build the base perl with -Dusethreads, what are the consequences of that? Test failures? Bigger binary? pkg_add is slower? Why the thread function was disabled in this release? > Is it security reason? > Upstream has it off by default, nothing so far has needed it, and it makes things slower (or at least that's why upstream says). Why would we enable it? Philip Guenther
Re: radeondrm failure on amd64 but not on i386?
Same issue, also on a Dell machine with ATI Radeon HD 2400 XT. Allan OpenBSD 6.4 (GENERIC.MP) #0: Sat Nov 17 22:15:46 CET 2018 r...@syspatch-64-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4141871104 (3949MB) avail mem = 4007075840 (3821MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xf0450 (82 entries) bios0: vendor Dell Inc. version "A11" date 01/21/2011 bios0: Dell Inc. OptiPlex 960 acpi0 at bios0: rev 2 acpi0: TCPA checksum error acpi0: sleep states S0 S1 S3 S4 S5 acpi0: tables DSDT FACP SSDT APIC BOOT ASF! MCFG HPET TCPA DMAR SLIC SSDT SSDT SSDT acpi0: wakeup devices VBTN(S4) PCI0(S5) PCI4(S5) PCI2(S5) PCI3(S5) PCI1(S5) PCI5(S5) PCI6(S5) USB0(S3) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5(S3) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz, 2992.96 MHz, 06-17-0a 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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN cpu0: 6MB 64b/line 16-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 7 var ranges, 88 fixed ranges cpu0: apic clock running at 332MHz cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz, 2992.51 MHz, 06-17-0a 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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN cpu1: 6MB 64b/line 16-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins, remapped acpimcfg0 at acpi0 acpimcfg0: addr 0xf800, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 4 (PCI4) acpiprt1 at acpi0: bus 2 (PCI2) acpiprt2 at acpi0: bus 3 (PCI3) acpiprt3 at acpi0: bus 1 (PCI1) acpiprt4 at acpi0: bus -1 (PCI5) acpiprt5 at acpi0: bus -1 (PCI6) acpiprt6 at acpi0: bus 0 (PCI0) acpicpu0 at acpi0: C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: C1(1000@1 mwait.1), PSS acpibtn0 at acpi0: VBTN acpicmos0 at acpi0 "*pnp0c14" at acpi0 not configured cpu0: Enhanced SpeedStep 2992 MHz: speeds: 3000, 2667, 2333, 2000 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel Q45 Host" rev 0x03 ppb0 at pci0 dev 1 function 0 "Intel Q45 PCIE" rev 0x03: msi pci1 at ppb0 bus 1 radeondrm0 at pci1 dev 0 function 0 "ATI Radeon HD 2400 XT" rev 0x00 drm0 at radeondrm0 radeondrm0: msi "Intel Q45 HECI" rev 0x03 at pci0 dev 3 function 0 not configured pciide0 at pci0 dev 3 function 2 "Intel Q45 PT IDER" rev 0x03: DMA (unsupported), channel 0 wired to native-PCI, channel 1 wired to native-PCI pciide0: using apic 8 int 18 for native-PCI interrupt pciide0: channel 0 ignored (not responding; disabled or no drives?) pciide0: channel 1 ignored (not responding; disabled or no drives?) puc0 at pci0 dev 3 function 3 "Intel Q45 KT" rev 0x03: ports: 16 com com4 at puc0 port 0 apic 8 int 17: ns16550a, 16 byte fifo com4: probed fifo depth: 0 bytes em0 at pci0 dev 25 function 0 "Intel ICH10 D BM LM" rev 0x02: msi, address 00:22:19:31:bf:96 uhci0 at pci0 dev 26 function 0 "Intel 82801JD USB" rev 0x02: apic 8 int 16 uhci1 at pci0 dev 26 function 1 "Intel 82801JD USB" rev 0x02: apic 8 int 17 uhci2 at pci0 dev 26 function 2 "Intel 82801JD USB" rev 0x02: apic 8 int 22 ehci0 at pci0 dev 26 function 7 "Intel 82801JD USB" rev 0x02: apic 8 int 22 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 azalia0 at pci0 dev 27 function 0 "Intel 82801JD HD Audio" rev 0x02: msi azalia0: codecs: Analog Devices AD1984A audio0 at azalia0 ppb1 at pci0 dev 28 function 0 "Intel 82801JD PCIE" rev 0x02: msi pci2 at ppb1 bus 2 ppb2 at pci0 dev 28 function 1 "Intel 82801JD PCIE" rev 0x02: msi pci3 at ppb2 bus 3 uhci3 at pci0 dev 29 function 0 "Intel 82801JD USB" rev 0x02: apic 8 int 23 uhci4 at pci0 dev 29 function 1 "Intel 82801JD USB" rev 0x02: apic 8 int 17 uhci5 at pci0 dev 29 function 2 "Intel 82801JD USB" rev 0x02: apic 8 int 18 ehci1 at pci0 dev 29 function 7 "Intel 82801JD USB" rev 0x02: apic 8 int 23 usb1 at ehci1: USB revision 2.0 uhub1 at usb1 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 ppb3 at pci0 dev 30 function 0 "Intel 82801BA Hub-to-PCI" rev 0xa2 pci4 at ppb3 bus 4 pcib0 at pci0 dev 31 function 0 "Intel 82801JDO LPC" rev 0x02 ahci0 at pci0 dev 31 function 2 "Intel 82801JD AHCI" rev 0x02: msi, AHCI 1.2 ahci0: port 0: 3.0Gb/s ahci0: port 1: 1.5Gb/s ahci0: PHY offline on port 2 scsibus1 at ahci0: 32 targets sd0 at scsibus1 targ 0 lun 0: SCSI3 0/direct fixed naa.500a0751094531c8 sd0: 915715MB, 512 bytes/sector
Re: radeondrm failure on amd64 but not on i386?
Thus said Allan Streib on Sun, 25 Nov 2018 21:54:45 -0500: > Same issue, also on a Dell machine with ATI Radeon HD 2400 XT. After Jonathan suggested adding some printf debug statements, I continued to do so and was able to see that the rdev->bios variable that is being inspected at lines 834--840 in radeon_bios.c has neither ATOM nor MOTA in the string at that address for amd64, but has ATOM for i386: tmp = rdev->bios_header_start + 4; if (!memcmp(rdev->bios + tmp, "ATOM", 4) || !memcmp(rdev->bios + tmp, "MOTA", 4)) { rdev->is_atom_bios = true; } else { rdev->is_atom_bios = false; } I suppose additional debug might involve writing the entire contents of rdev->bios to a file and then hexdump it? Andy -- TAI64 timestamp: 40005bfb8e86
Re: radeondrm failure on amd64 but not on i386?
On Mon, Nov 19, 2018 at 08:37:01AM -0700, Andy Bradford wrote: > Thus said Jonathan Gray on Mon, 19 Nov 2018 20:42:46 +1100: > > > > Thanks for the suggestion. Here's the additional output provided by your > > > patch: > > > > > > radeon_atrm_get_bios false > > > radeon_acpi_vfct_bios false > > > igp_read_bios_from_vram false > > > radeon_read_bios false > > > radeon_read_disabled_bios true > > > drm:pid0:r600_init *ERROR* Expecting atombios for R600 GPU > > > drm:pid0:radeondrm_attachhook *ERROR* Fatal error during GPU init > > > [TTM] Memory type 2 has not been initialized > > > drm0 detached > > > radeondrm0 detached > > > > Thanks, could you also show the i386 output with the patch? > > The output on i386 looks pretty much the same except for the failure: > > initializing kernel modesetting (RV610 0x1002:0x94C1 0x1028:0x0D02). > radeon_atrm_get_bios false > radeon_acpi_vfct_bios false > igp_read_bios_from_vram false > radeon_read_bios false > radeon_read_disabled_bios true > radeondrm0: 1680x1050, 32bpp > wsdisplay0 at radeondrm0 mux 1: console (std, vt100 emulation), using wskbd0 r600_read_disabled_bios is just doing register reads/writes it isn't clear to me why that would be different between amd64 and i386.