[dev] [PATCH] [slock] Use MODE and GROUP in install
---
Makefile | 4 ++--
config.mk | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Makefile b/Makefile
index 2bea555..d53171c 100644
--- a/Makefile
+++ b/Makefile
@@ -40,8 +40,8 @@ install: all
@echo installing executable file to ${DESTDIR}${PREFIX}/bin
@mkdir -p ${DESTDIR}${PREFIX}/bin
@cp -f slock ${DESTDIR}${PREFIX}/bin
- @chmod 755 ${DESTDIR}${PREFIX}/bin/slock
- @chmod u+s ${DESTDIR}${PREFIX}/bin/slock
+ @chgrp ${GROUP} ${DESTDIR}${PREFIX}/bin/slock
+ @chmod ${MODE} ${DESTDIR}${PREFIX}/bin/slock
uninstall:
@echo removing executable file from ${DESTDIR}${PREFIX}/bin
diff --git a/config.mk b/config.mk
index 8cc3f68..aee4b79 100644
--- a/config.mk
+++ b/config.mk
@@ -26,5 +26,5 @@ CC = cc
# Install mode. On BSD systems MODE=2755 and GROUP=auth
# On others MODE=4755 and GROUP=root
-#MODE=2755
-#GROUP=auth
+MODE=4755
+GROUP=root
--
1.8.5.2 (Apple Git-48)
[dev] Re: [PATCH] [slock] Use MODE and GROUP in install
Bump. The unpatched code doesn't work properly on BSD for reasons not
obvious to the person compiling it.
On Mon, Apr 28, 2014 at 10:46 AM, Steve Dee wrote:
>
> ---
> Makefile | 4 ++--
> config.mk | 4 ++--
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 2bea555..d53171c 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -40,8 +40,8 @@ install: all
> @echo installing executable file to ${DESTDIR}${PREFIX}/bin
> @mkdir -p ${DESTDIR}${PREFIX}/bin
> @cp -f slock ${DESTDIR}${PREFIX}/bin
> - @chmod 755 ${DESTDIR}${PREFIX}/bin/slock
> - @chmod u+s ${DESTDIR}${PREFIX}/bin/slock
> + @chgrp ${GROUP} ${DESTDIR}${PREFIX}/bin/slock
> + @chmod ${MODE} ${DESTDIR}${PREFIX}/bin/slock
>
> uninstall:
> @echo removing executable file from ${DESTDIR}${PREFIX}/bin
> diff --git a/config.mk b/config.mk
> index 8cc3f68..aee4b79 100644
> --- a/config.mk
> +++ b/config.mk
> @@ -26,5 +26,5 @@ CC = cc
>
> # Install mode. On BSD systems MODE=2755 and GROUP=auth
> # On others MODE=4755 and GROUP=root
> -#MODE=2755
> -#GROUP=auth
> +MODE=4755
> +GROUP=root
> --
> 1.8.5.2 (Apple Git-48)
>
Re: [dev] network protocol packing
See also: https://kentonv.github.io/capnproto/
Re: [dev] network protocol packing
On Tue, Jul 1, 2014 at 8:01 AM, Markus Teich wrote: > Rob wrote: >> You've got alignment issues here - msg will be aligned to support any >> type (as malloc's interface specifies) so msg+1 will most likely be on >> an odd address, one byte off a highly aligned address. This means if >> your struct contains anything other than chars, you'll have UB. This is >> fine on x86, which allows unaligned access with a performance penalty >> but on something like an ARM machine you'll have issues. > > Heyho, > > so if every field in the message is a multiple of 4 bytes long, this should > fix > the problem? In this case I would just make op an uint32_t and htonl it before > sending, ntohl after receiving. It may be worth taking a look at capnproto as I mentioned above if you haven't yet. It's taken a very similar approach to the problem, and come up with a rather low-suck solution. Messages are all aligned to 64-bit words and sent that way over the wire, with an optional lightweight packing format to reduce message sizes. There are C bindings in a mostly-working state. You don't need to touch C++ except to compile their protocol format, which you shouldn't have to do most of the time. The only thing from your strawman that capnproto doesn't do directly in a similarly simple manner is message signing, and it's not hard to imagine adding it. That said, I think your strawman is great, and I'm not trying to shoot it down -- just pointing in the direction of similar work that might be inspiring or might save you some effort. > > --Markus >
[dev] [sbase] [patch] Get it building on OpenBSD
OpenBSD doesn't have utmpx.h or clearenv. Also, the dependency "$(BIN): util.a" seems to shadow the implicit build rule in BSD make, resulting in nothing past util.a getting built. The patch includes a rather stupid workaround for this. (Less stupid solutions welcome --- it'd be simple to specify with a ".for", but then it'd be BSD-make--specific, and I don't feel like figuring out cross-platform makefiles.) sbase-openbsd.diff Description: Binary data
Re: [dev] [sbase] [patch] Get it building on OpenBSD
On Fri, Jul 12, 2013 at 5:36 PM, Galos, David wrote: >> OpenBSD doesn't have utmpx.h or clearenv. > Does it also not have "getutent"? It doesn't, as far as I can tell. That implementation comes from OpenBSD's who.
Re: [dev] [sbase] [patch] Get it building on OpenBSD
On Thu, Jul 18, 2013 at 11:31 AM, Galos, David wrote: >> It doesn't, as far as I can tell. That implementation comes from OpenBSD's >> who. > Is the utmp file guaranteed to be machine endian? OpenBSD assumes it is. And on Linux, man 5 utmp claims: "The file format is machine-dependent, so it is recommended that it be processed only on the machine architecture where it was created." > This patch seems to imply > that. > >> *environ = NULL; > The linux manpage suggests 'environ = NULL'. Is BSD different in that regard? Either will work as long as it's done consistently everywhere. NULLing the first entry seems slightly better (in case anyone has their own pointer, or doesn't check for NULL), but I've added a guard against an already-NULL environ. (This version also uses a slightly less harmful Makefile hack.) > > I would like to see sbase compile on OpenBSD, so hopefully we can find > solutions that works everywhere. > sbase-openbsd-2.diff Description: Binary data
Re: [dev] [sbase] [patch] Add df(1)
BSD-compatible, opinionated df attached. Always prints 512-blocks. Guesses high on used counts. Untested in Linux because time. The -std=c99 patch is to suppress warnings about using the %llu format specifier. It's kept separate in case C99 is undesirable, though. On Mon, Jul 22, 2013 at 9:55 AM, sin wrote: > On Mon, Jul 22, 2013 at 03:26:09PM +0300, sin wrote: >> Hi all, >> >> This is an initial bare bones df(1) implementation. >> I'm looking for some feedback, I have not put too much thought >> into the code yet (too busy atm). >> >> No manpage yet. > > I should also mention, that this naturally breaks on *BSD. > If we do care about that, we should think of a proper way to > handle this. > > Thanks, > sin > sbase-bsd-df.patch Description: Binary data sbase-stdc99.patch Description: Binary data
[dev] [surf] [patch] More consistent keybindings
C-[hjkl] are in-page scrolling. C-i and C-o are back/forth page navigation, just like in Vim. This frees up C-u for view source, just like in Chrome. This patch messes with surfers' muscle memory, but I think the consistency with the rest of the world is nice enough to at least be worth an email. Do with it what you will. Cheers, Steven surf-vimkeys.patch Description: Binary data
[dev] Re: [surf] [patch] More consistent keybindings
Accompanying manual patch. On Mon, Jul 22, 2013 at 11:33 AM, Steve Dee wrote: > C-[hjkl] are in-page scrolling. C-i and C-o are back/forth page > navigation, just like in Vim. This frees up C-u for view source, just > like in Chrome. This patch messes with surfers' muscle memory, but I > think the consistency with the rest of the world is nice enough to at > least be worth an email. Do with it what you will. > > Cheers, > Steven surf-1-vimkeys.patch Description: Binary data
Re: [dev] [sbase] [patch v3] Add df(1)
Nice. BSD doesn't have mntent or /proc, but does have getmntinfo. I think we can create a common interface that requires a minimal amount of conditional compilation (though obviously no conditional compilation is better than any conditional compilation), but I don't have time to do this for the next few days. On Tue, Jul 23, 2013 at 8:13 AM, sin wrote: > Clean up the code a bit. Behave like -a by default.
Re: [dev] [sbase] [patch v3] Add df(1)
On Tue, Jul 23, 2013 at 10:29 AM, sin wrote: > On Tue, Jul 23, 2013 at 10:18:01AM -0400, Steve Dee wrote: >> I don't have time to do this for the next few days. Actually, I had a bit of time before running off into the woods. Here's something that compiles on both OpenBSD and Linux. The conditional directives are intentionally overspecific -- ideally we'll remove them, but maybe this'll help in coming up with a good solution. > > Yeah I chose to do df(1) exactly because it will be incompatible > with BSD. I want to find a sensible solution so we can have it > working on BSD as well. This raises a good point. There's a larger question around how cross-platform we want to be. I'm too new here to have much to say on it, besides that I love the code I've seen in both BSD and the various suckless projects. sbase-df-cond-cc.patch Description: Binary data
[dev] [surf] [PATCH] Clean up SSL validation
soup_message_get_flags returns a bunch of flags besides SOUP_MESSAGE_CERTIFICATE_TRUSTED, so the XOR check was incorrect. While I was tracking this bug, I switched from libsoup's deprecated [0] ssl-ca-file to its non-deprecated tls-database property. I don't know if I did that properly, having never touched glib nor being able to find whether g_object_set transfers pointers. So here's two patches, one almost certainly good and somewhat important, and the other of unknown validity and unimportant. [0] https://developer.gnome.org/libsoup/stable/SoupSession.html#SoupSession--ssl-ca-file 0001-Properly-verify-ssl-connections.patch Description: Binary data 0002-Use-tls-database-instead-of-ssl-ca-file.patch Description: Binary data
