[new] sysutils/es-srme - resize softraid crypto volumes
I wrote this small, ~8K utility to resize softraid crypto volumes back in March, after a thread on misc that highlighted that there was not already code to do this: https://marc.info/?l=openbsd-misc=164812563223554=2 The source has been downloaded a number of times from our website: https://www.exoticsilicon.com/research/resizing_softraid_volumes ... and there have been no complaints so far. Since people are either using it, or at least interested in it, I've created a port, (attached). Incidentally, in the process of writing es-srme, I discovered a kernel bug, which I posted about on tech, but which has not yet been fixed in CVS: https://marc.info/?l=openbsd-tech=164834052628572=2 sysutils.es-srme.tar.gz Description: application/tar-gz
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On Fri, Jan 21, 2022 at 01:12:05PM -0600, joshua stein wrote: > On Fri, 21 Jan 2022 at 16:06:00 -0300, Crystal Kolipe wrote: > > On Fri, Jan 21, 2022 at 11:42:35AM -0700, Aaron Bieber wrote: > > > Here is my experience: http://www.oxide.org/cvs/abieber.html > > > > Wow, that server is slow. And doesn't even support https. > > So you want to enforce your "standard", I.E. https, on everybody? > > If we're going to have a "standard", why not make it the lowest > common denominator, so that people who are comfortable with browsing > with their own tools can easily handle it the way they want to? > Which is, basically, the whole unix philosophy anyway. Thankyou! I totally agree! And the lowest common denominator would be to post the content to the list, (or preferably to me personally and to stop spamming the list with off-topic drivel). That way I wouldn't have to fetch an external resource, be it over http or https or gopher, or whatever. Which was, ironically, one of my original rants about the proposed use of GitHub. Nevertheless, if you ARE going to post an external link, at least give people the OPTION of pulling it over https.
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On Fri, Jan 21, 2022 at 11:42:35AM -0700, Aaron Bieber wrote: > Here is my experience: http://www.oxide.org/cvs/abieber.html Wow, that server is slow. And doesn't even support https.
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On Fri, Jan 21, 2022 at 11:24:34AM -0700, Aaron Bieber wrote: > > Crystal Kolipe writes: > > > On Fri, Jan 21, 2022 at 11:05:12AM -0700, Aaron Bieber wrote: > >> "Knowing" the tools isn't the problem. jcs@ knows how to use tar. I know > >> how to use tar. The problem is that people send things totally > >> differently and there is no agreed upon "standard". GH would remedy this > >> because everything would become a diff - plain text! > > > > So you want to enforce your "standard", I.E. GitHub, on everybody? > > > > If we're going to have a "standard", why not make it the lowest common > > denominator, so that people who are comfortable with creating their own > > tools can easily handle it the way they want to? Which is, basically, > > the whole unix philosophy anyway. > > > >> Also if people don't want to use the GH approach - they don't have to! > > > > But the use of GitHub would become like a virus, in that it also affects > > people who don't want to use it. > > > >> at no point did jcs suggest that we make everyone get a GH account and > >> switch to using it exclusively. > > > > Go and read the Linux kernel archives from 20 years ago, and the flamewars > > over the use of BitKeeper to manage the kernel source. > > I don't even know how to respond to this. You are saying that GH usage > will infect people and then they will be forced to use it? Not really, no. I'm saying that once some people start using GitHub to automatically generate diffs and send them to this mailing list, then the next step will likely be that development starts moving off of the mailing list altogether, and only accessible via a tedious pointy-clicky webbrowser interface, rather than as free-format conversation on a mailing list, which has worked fine ever since the OpenBSD project first began. > That seems a bit far fetched to me. But maybe that's the mindvirus at > work! > > No idea what linux kernel archievs from 20 years ago have to do with any > of this. Well, you've really answered your own question there. Do you even know why git was created? What came before it?
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On Fri, Jan 21, 2022 at 11:05:12AM -0700, Aaron Bieber wrote: > "Knowing" the tools isn't the problem. jcs@ knows how to use tar. I know > how to use tar. The problem is that people send things totally > differently and there is no agreed upon "standard". GH would remedy this > because everything would become a diff - plain text! So you want to enforce your "standard", I.E. GitHub, on everybody? If we're going to have a "standard", why not make it the lowest common denominator, so that people who are comfortable with creating their own tools can easily handle it the way they want to? Which is, basically, the whole unix philosophy anyway. > Also if people don't want to use the GH approach - they don't have to! But the use of GitHub would become like a virus, in that it also affects people who don't want to use it. > at no point did jcs suggest that we make everyone get a GH account and > switch to using it exclusively. Go and read the Linux kernel archives from 20 years ago, and the flamewars over the use of BitKeeper to manage the kernel source.
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On Fri, Jan 21, 2022 at 11:42:08AM -0600, joshua stein wrote: > Maybe we can do something radical like enable GitHub pull requests > to let people submit changes against the ports repo on GitHub Cringe. I sincerely hope that this doesn't happen. Just look at the typical quality of the projects hosted on GitHub, and you'll see how relying on a set of third-party managed tools to do your work instead of taking the time to learn the basic tools, (tar, diff, an email program, etc), yourself can lead to laziness and poor quality. If people can't be bothered to do things themselves or make their own tools to automate a process, how dedicated are they likely to be? > I believe that the GitHub repo can be configured to also email > ports@openbsd.org on any submissions/comments there, so the mailing > list would still be in the loop on everything for anyone that > doesn't want to use GitHub. So the mailing list is going to be flooded with automated mails from GitHub, that become tedious, leading people to just skim over them or OK them without really reviewing the content. Honestly, I think we all want to keep the quality of the ports tree as high as possible, and if learing to use tar and diff as a barrier to entry for some people is doing that, I suggest we continue as we are.
Re: [UPDATE] print/ghostscript/gnu 9.55.0
On Fri, Jan 14, 2022 at 08:26:28PM +, Stuart Henderson wrote: > On 2022/01/14 17:05, Crystal Kolipe wrote: > > As this new version is no longer 'gnu ghostscript', shouldn't the path > > change > > to just print/ghostscript? > > No because there is another subdirectory under print/ghostscript What, the fonts? By the way, you do know that the homepage link in the makefile has been broken for ages: http://www.cs.wisc.edu/~ghost/doc/cvs/Fonts.htm :)
Re: [UPDATE] print/ghostscript/gnu 9.55.0
On Fri, Jan 14, 2022 at 08:16:14PM +0100, Volker Schlecht wrote: > ok, so here's my first attempt. I did manage to use system and ports > libraries, except for jbig2dec. Here the version in ports is too old. > > I bumped the shared object version from 15.0 to 16.0 - not sure if that's > advisable and/or necessary, but I think for a first shot it's pretty good ;) > > Looking forward to everyone's feedback. There seem to be a bunch of really > nasty and exploitable bugs in ghostscript versions < 9.55 so I hope we can > somehow get a more recent version into ports. As this new version is no longer 'gnu ghostscript', shouldn't the path change to just print/ghostscript?
Re: MPV, graphics driver, or AUDIO driver??
On Sun, Jan 09, 2022 at 10:49:55AM -0500, fo...@dnmx.org wrote: > So, because of that I went from TTY5 (home/xendom or at least > CTRL+ALT+Function5) to TTY1 to log-in and see if that changed anything I think this is a known bug that was introduced between 6.9-release and 7.0-release. Can you reproduce it on the same hardware with 6.9-release?
Re: [Fwd: Re: MPV, graphics driver, or AUDIO driver??]
On Sun, Jan 09, 2022 at 11:01:26AM +0100, Stefan Hagen wrote: > Theo de Raadt wrote: > > Stefan Hagen wrote: > > > > > Crystal Kolipe wrote: > > > > On Sat, Jan 08, 2022 at 08:15:43PM +0100, Stefan Hagen wrote: > > > > > Start X via xenodm and not via startx. Then it runs through > > > > > /etc/X11/xenodm/GiveConsole, which contains: > > > > > > > > > > if [ -c /dev/dri/card0 ]; then > > > > > chown $USER /dev/dri/card0 > > > > > fi > > > > > > > > > > Alternatively add the chown command above to your .xinitrc > > > > > > > > WHAT!? > > > > > > > > /dev/dri/card0 will be automatically chown'ed to the user logged in on > > > > ttyC0 unless you've changed /etc/fbtab from the default. > > > > > > > > Additionally, /etc/X11/xinit is run as the calling user, not as root. > > > > So how on earth would the chown command succeed, called from xinit? > > > > > > doas(1) helps. But the whole suggestion was a bandaid. I should not have > > > given it. > > > > What unbelievable terrible advice, to encourage people to make their > > accounts root-equivelant. > > > > Just wow. > > My morning brain agrees that doas and chown should not be mentioned in > one sentence. But there's no paddling back from this on a mailing list... > > So: DON'T DO THAT! As theo said, then every file could be chowned to > your user and altered and chowned back. It's basically root for > everything. Except the files that the knowledgeable sysadmin has flagged with schg. Those should be immune. Well, unless a malicious user uses the exploit you would have introduced to actually get real root access, then they can potentially remove the schg flag by directly accesing the raw disk device. Which in turn could be avoided by running in securelevel 2. > We should really hunt down why the device owner is not set properly with > the mechanism in place. Exactly. This is generally a very good idea. The mechanisms in place have hopefully been well thought out, and tested, and shouldn't allow unexpected or unintended behaviour.
Re: [Fwd: Re: MPV, graphics driver, or AUDIO driver??]
On Sat, Jan 08, 2022 at 08:15:43PM +0100, Stefan Hagen wrote: > Start X via xenodm and not via startx. Then it runs through > /etc/X11/xenodm/GiveConsole, which contains: > > if [ -c /dev/dri/card0 ]; then > chown $USER /dev/dri/card0 > fi > > Alternatively add the chown command above to your .xinitrc WHAT!? /dev/dri/card0 will be automatically chown'ed to the user logged in on ttyC0 unless you've changed /etc/fbtab from the default. Additionally, /etc/X11/xinit is run as the calling user, not as root. So how on earth would the chown command succeed, called from xinit?
Re: Update www/surf to 2.1
On Wed, Dec 22, 2021 at 11:33:21PM +0100, Joerg Jung wrote: > On Wed, Dec 22, 2021 at 04:33:11PM +0100, Joerg Jung wrote: > > > Am 20.12.2021 um 20:02 schrieb Crystal Kolipe > > > : > > > > > > ???Surf 2.1 was released seven months ago, but we still have 2.0 in ports. > > > > Thanks, I???ll take care soon. > > > > > Patch attached. > > > > > Your diff had multiple issues, i.e. not needed REVISION, missing PLIST > update etc. and it did not compile (for me) at all. My bad, I was working on several versions and testing patches from their CVS at the same time. > Please find below a better one for testing, which seems to work fine. Thanks, your version compiles and runs fine here. Do you think it would be worth including this post 2.1 fix from CVS: http://git.suckless.org/surf/commit/761ea9e4c6c4d8aba4a4d39da9c9b4db8ac471b1.html
Re: a bearable browser
On Tue, Dec 21, 2021 at 08:54:05PM +0100, Jan Stary wrote: > On Dec 20 09:44:38, mlar...@nested.page wrote: > > On Mon, Dec 20, 2021 at 11:55:38AM +0100, Jan Stary wrote: > > > Dear all, > > > > > > I know the question keeps repeating here, > > > but is there a web browser that is at least usable? > > > > > > I switched from Firefox to Chrome about a year ago, > > > but it has become unbearably slow and hungry. > > > > > > On a machine with Intel(R) Core(TM)2 Duo CPU P8400 @ 2.26GHz, > > > and 8GB of ram, about ten tabs make it ridiculously unresponsive. > > > > > > > That's a CPU released in 2008. Thirteen years ago. While I agree that > > browsers > > have become more bloated, I think the "ridiculously unreponsive" claim here > > is probably due to something else in this case. > > Is that considered slow by now? I honestly don't know. > Beside chrome, everything runs smooth as an oiled cucumber; > kernel recompiles in a few minutes, no problem except the browser. > (Truth be told, I also happen to like these older Thinkpads.) I regularly use surf, a webkit-based browser, on a Thinkpad X201 without much difficulty: Intel(R) Core(TM) i5 CPU M 540 @ 2.53GHz, 2793.49 MHz, 06-25-02 Performance is slightly slower but still usable on a RockPI-4b: cpu0 at mainbus0 mpidr 0: ARM Cortex-A53 r0p4 cpu0: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache cpu0: 512KB 64b/line 16-way L2 cache cpu1 at mainbus0 mpidr 1: ARM Cortex-A53 r0p4 cpu1: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache cpu1: 512KB 64b/line 16-way L2 cache cpu2 at mainbus0 mpidr 2: ARM Cortex-A53 r0p4 cpu2: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache cpu2: 512KB 64b/line 16-way L2 cache cpu3 at mainbus0 mpidr 3: ARM Cortex-A53 r0p4 cpu3: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache cpu3: 512KB 64b/line 16-way L2 cache cpu4 at mainbus0 mpidr 100: ARM Cortex-A72 r0p2 cpu4: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache cpu4: 1024KB 64b/line 16-way L2 cache cpu5 at mainbus0 mpidr 101: ARM Cortex-A72 r0p2 cpu5: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache cpu5: 1024KB 64b/line 16-way L2 cache
Update www/surf to 2.1
Surf 2.1 was released seven months ago, but we still have 2.0 in ports.
Patch attached.
diff -ur surf.dist/Makefile surf/Makefile
--- surf.dist/Makefile Fri Jul 12 17:51:06 2019
+++ surf/Makefile Mon Dec 20 15:19:39 2021
@@ -2,10 +2,10 @@
COMMENT = simple webbrowser based on webkit/gtk+
-DISTNAME = surf-2.0
+DISTNAME = surf-2.1
CATEGORIES = www
HOMEPAGE = http://surf.suckless.org/
-REVISION = 1
+REVISION = 0
MAINTAINER=Joerg Jung
diff -ur surf.dist/distinfo surf/distinfo
--- surf.dist/distinfo Fri May 26 17:37:56 2017
+++ surf/distinfo Mon Dec 20 13:59:06 2021
@@ -1,2 +1,2 @@
-SHA256 (surf-2.0.tar.gz) = +u5MemLDj8l5Hv8a0GeHw8myt58ziAaCf1FSp7xUlR0=
-SIZE (surf-2.0.tar.gz) = 19056
+SHA256 (surf-2.1.tar.gz) = cuWCkguiWmRiA+k8LSMx2H8DA3ooiU1sfpmvAO4EMlc=
+SIZE (surf-2.1.tar.gz) = 22555
diff -ur surf.dist/patches/patch-Makefile surf/patches/patch-Makefile
--- surf.dist/patches/patch-MakefileWed Dec 23 17:40:03 2015
+++ surf/patches/patch-Makefile Mon Dec 20 14:26:38 2021
@@ -1,38 +1,20 @@
-$OpenBSD: patch-Makefile,v 1.1 2015/12/23 20:40:03 jung Exp $
Makefile.orig Sat Dec 19 20:52:53 2015
-+++ Makefile Sat Dec 19 20:55:19 2015
-@@ -15,8 +15,7 @@ options:
- @echo "CC = ${CC}"
+--- Makefile.dist Sun May 9 19:34:33 2021
Makefile Mon Dec 20 14:26:26 2021
+@@ -53,17 +53,12 @@
+ rm -rf surf-$(VERSION)
- .c.o:
-- @echo CC $<
-- @${CC} -c ${CFLAGS} $<
-+ ${CC} -c ${CFLAGS} $<
-
- ${OBJ}: config.h config.mk
-
-@@ -25,8 +24,7 @@ config.h:
- @cp config.def.h $@
-
- surf: ${OBJ}
-- @echo CC -o $@
-- @${CC} -o $@ surf.o ${LDFLAGS}
-+ ${CC} -o $@ surf.o ${LDFLAGS}
-
- clean:
- @echo cleaning
-@@ -43,14 +41,12 @@ dist: clean
- @rm -rf surf-${VERSION}
-
install: all
-- @echo installing executable file to ${DESTDIR}${PREFIX}/bin
-- @mkdir -p ${DESTDIR}${PREFIX}/bin
-- @cp -f surf ${DESTDIR}${PREFIX}/bin
-- @chmod 755 ${DESTDIR}${PREFIX}/bin/surf
-- @echo installing manual page to ${DESTDIR}${MANPREFIX}/man1
-- @mkdir -p ${DESTDIR}${MANPREFIX}/man1
-- @sed "s/VERSION/${VERSION}/g" < surf.1 >
${DESTDIR}${MANPREFIX}/man1/surf.1
-- @chmod 644 ${DESTDIR}${MANPREFIX}/man1/surf.1
+- mkdir -p $(DESTDIR)$(PREFIX)/bin
+- cp -f surf $(DESTDIR)$(PREFIX)/bin
+- chmod 755 $(DESTDIR)$(PREFIX)/bin/surf
+- mkdir -p $(DESTDIR)$(LIBDIR)
+- cp -f $(WLIB) $(DESTDIR)$(LIBDIR)
+- for wlib in $(WLIB); do \
+- chmod 644 $(DESTDIR)$(LIBDIR)/$$wlib; \
+- done
+- mkdir -p $(DESTDIR)$(MANPREFIX)/man1
+- sed "s/VERSION/$(VERSION)/g" < surf.1 >
$(DESTDIR)$(MANPREFIX)/man1/surf.1
+- chmod 644 $(DESTDIR)$(MANPREFIX)/man1/surf.1
+ ${BSD_INSTALL_PROGRAM_DIR} ${DESTDIR}${PREFIX}/bin
+ ${BSD_INSTALL_PROGRAM} surf ${DESTDIR}${PREFIX}/bin
+ ${BSD_INSTALL_MAN_DIR} ${DESTDIR}${MANPREFIX}/man1
@@ -41,4 +23,4 @@
+ ${BSD_INSTALL_MAN} surf.1 ${DESTDIR}${MANPREFIX}/man1
uninstall:
- @echo removing executable file from ${DESTDIR}${PREFIX}/bin
+ rm -f $(DESTDIR)$(PREFIX)/bin/surf
diff -ur surf.dist/patches/patch-config_def_h surf/patches/patch-config_def_h
--- surf.dist/patches/patch-config_def_hFri May 26 17:37:56 2017
+++ surf/patches/patch-config_def_h Mon Dec 20 14:30:20 2021
@@ -1,22 +1,11 @@
-$OpenBSD: patch-config_def_h,v 1.5 2017/05/26 20:37:56 jung Exp $
-Index: config.def.h
config.def.h.orig
-+++ config.def.h
-@@ -30,7 +30,7 @@ static Parameter defconfig[ParameterLast] = {
- SETB(SiteQuirks, 1),
- SETB(SpellChecking, 0),
- SETV(SpellLanguages, ((char *[]){ "en_US", NULL })),
-- SETB(StrictSSL, 0),
-+ SETB(StrictSSL, 1),
- SETB(Style, 1),
- SETF(ZoomLevel, 1.0),
- };
-@@ -58,7 +58,7 @@ static WebKitFindOptions findopts = WEBKIT_FIND_OPTION
+--- config.def.h.dist Sun May 9 19:34:33 2021
config.def.h Mon Dec 20 14:30:08 2021
+@@ -76,7 +76,7 @@
+
/* DOWNLOAD(URI, referer) */
- #define DOWNLOAD(d, r) { \
- .v = (const char *[]){ "/bin/sh", "-c", \
-- "st -e /bin/sh -c \"curl -g -L -J -O --user-agent '$1'" \
-+ "xterm -e /bin/sh -c \"curl -g -L -J -O --user-agent '$1'" \
- " --referer '$2' -b $3 -c $3 '$0';" \
- " sleep 5;\"", \
- d, useragent, r, cookiefile, NULL \
+ #define DOWNLOAD(u, r) { \
+-.v = (const char *[]){ "st", "-e", "/bin/sh", "-c",\
++.v = (const char *[]){ "xterm", "-e", "/bin/sh", "-c",\
+ "curl -g -L -J -O -A \"$1\" -b \"$2\" -c \"$2\"" \
+ " -e \"$3\" \"$4\"; read", \
+ "surf-download", useragent, cookiefile, r, u, NULL \
diff -ur surf.dist/patches/patch-config_mk surf/patches/patch-config_mk
--- surf.dist/patches/patch-config_mk Fri May 26 17:37:56 2017
+++ surf/patches/patch-config_mkMon
