Re: [dev] [dwm]: something like the xfce scale all windows feature

[Nick]

Quoth Britton Kerin:
> I've got one of the high-res monitors and everything looks really
> tiny.  I notec xfce4 has this
> "scale everything by 2" feature that addresses this, what's the
> easiest way to get this in dwm?

You can just make the font bigger in dwm's config.h, and the border 
size if you want. That's the extent to which dwm is involved, as 
it's just a window manager.

I'm guessing you want other programs to do scaling - there are 
different environment variables to set for different GUI toolkits, 
this webpage gives a reasonable overview - set these in your 
.xprofile or wherever you see fit: 
https://wiki.archlinux.org/title/HiDPI#GUI_toolkits

Re: [dev] Whether a css selector applies to given html surf code

[Nick]

Quoth Страхиња Радић:
> This is what a web page should be:
> 
> http://motherfuckingwebsite.com/

When I load that in tor browser with js disabled (my default setup 
these days), I get a 20741 byte page with the title "Captcha" and no 
content except an eternally rotating image.

The web is beyond saving.

Re: [dev] Wayland compositors

[Nick]

Quoth Страхиња Радић:
> On 21/09/08 01:36, Nick wrote:
> > The fact that the Jitsi devs closed 
> > the bug as "not much we can do on our side" doesn't mean "wayland 
> > broke it and we can't fix it".
> 
> It's exactly the same thing.

In this instance it isn't, maybe I should have been more verbose.  
The issue was with web browser support for wayland screen sharing 
stuff, so Jitsi couldn't fix it theirselves, but it is now well 
integrated and supported in browsers, and therefore by extension 
Jitsi.

> The issues listed show a pattern and the impact of breaking with a
> long-standing, time-tested tradition just for the sake of doing something 
> "new"
> and "different". "New" doesn't automatically mean "good".

True, this is clearly a case where the majority of X developers 
decided it was worth the pain of starting again with a fresh design.  
There are pros and cons to that. In this case I think it sounds like 
it's worth it, as the end result should be a cleaner system with 
less code and more reliability, and I'm happy to pay the short term 
cost of changing some programs I use and learning how to do things 
differently in some cases. Obviously for some people the costs will 
be different, and the benefits don't seem worth it.

It's frustrating to feel like you have so little agency over the 
direction of such decisions - that's one of the things that attracts 
lots of us to suckless - but to some extent that's inevitable with 
large projects like this. As you say, I have little doubt that X 
will continue to receive some attention and support for a long time 
to come, even if not so much from the current core team.

> You haven't mentioned the other points, just some of the major ones being the
> issue of non-GNOME desktop environments, for example KDE. I'm not using KDE, 
> but
> why just erase it in favor of GNOME monopoly? I'm using no desktop 
> environment,
> I'm using dwm, but many of its key features are not supported by Wayland. 

>From what I could see on that list, the KDE and XFCE issues 
mentioned are all things which are being worked on or have already 
been addressed by those projects. I don't really see how Wayland is 
leading to a GNOME monopoly, there are plenty of other compositors 
out there with more on the way.

I'm going to bow out of this conversation now, lest it become even 
more interminable for everyone else! But thanks for sharing your 
opinions and thoughts about it, it's (almost) always good to be 
challenged, even if it doesn't result in minds being changed :)

Nick

Re: [dev] Wayland compositors

[Nick]

Quoth Страхиња Радић:
> On 21/09/08 12:28, Nick wrote:
> > honest I found the arguments made there to be largely unconvincing, 
> 
> Any argument in particular and why?

A lot of the "Wayland breaks" examples don't seem to be fairly 
reporting on the actual issues. The jitsi screen sharing issue, for 
example, has reports that it works fine for fedora, but it's just 
the case that (at least when the bug was being discussed, over a 
year ago), the integration of xda-desktop-portal into the system of 
some users hadn't happened yet. The fact that the Jitsi devs closed 
the bug as "not much we can do on our side" doesn't mean "wayland 
broke it and we can't fix it". The same is true of at least most of 
the screen recording / sharing stuff - it works differently on 
Wayland (for not-bad reasons), so some software is redundant, and 
others needed to be updated to use new APIs, and unsurprisingly the 
proprietary crap is the last to be updated. But ultimately, the 
important tasks represented (screen sharing & screen recording) do 
work fine under wayland.

The other headings are less important, I'd say, and seem to either 
fall under same answer as above (for which the answer is often just 
to use different tools that are built for wayland), or non-terrible 
side effects things that are intentionally done differently, for 
good reasons (thinking of the "prevents GUI applications from 
running as root" and "breaks windows rasing/activating themselves").

That's my reading of that gist, anyway.

Re: [dev] Wayland compositors

[Nick]

Hi Maarten et al,

Many thanks for your replies, this was very handy to read.  
Interesting to hear that sxmo is moving in the wayland direction, 
too. I haven't managed to get around to actually trying wayland yet, 
as as ever my attention has been pulled in too many different 
directions. But I'll get there.

Thanks to Страхиња Радић, too, for the link to the "wayland is bad" 
github gist. The idea that a github gist is the place for such 
discussion is funny to me, given that github's model and interface 
is hardly suckless, but hey ho, such is modern internet life. To be 
honest I found the arguments made there to be largely unconvincing, 
and while the idea that compositing is not separated from window 
management certainly seems dodgy on first reading, the wayland way 
seems much nicer than X to my eyes. I'm reading the Wayland book at 
the moment <https://wayland-book.com>, so soon my opinion will be 
better informed - don't take my words too seriously on the matter 
for now.

The issue with suckless software depending on sucky libraries 
outside of their direct control is an enduring one* with no easy 
fixes, but it looks to me like the move away from X should go some 
way to (hopefully) more solid foundations to build on in the future.  
I'm an optimist, in this way.

Anyway, thanks again for all your thoughts.

Nick

* I'm thinking in particular of the repeated "emojis broke my st" 
  mails, caused by a bug in Xft that noone upstream seems to care much
  about fixing, and the fact that surf is a really just a nice
  interface atop the hulking edifice of webkit2/gtk+

[dev] Wayland compositors

[Nick]

Hi all,

I'm thinking it would be fun to play around with Wayland, so was 
looking at different compositors (which do window management plus 
other stuff). Has anyone else on the list taken Wayland for a spin 
and had any experience with them?

>From a search around the 3 that look interesting to me, a dwm user 
for many years, are:
- velox - written by Michael Forney, described as "inspired by dwm 
  and xmonad"
- sway - i3 for Wayland, undoubtedly mature, undoubtedly more 
  features than I'd prefer
- dwl - "dwm for Wayland", looks nicely dwm-ish, though no built-in 
  status bar so I guess I'd have to find some external software to 
  provide that.

Any thoughts, experiences, recommendations?

Nick

Re: [dev] [lchat] Error compiling

[Nick]

Hi Shirenn,

Quoth shirenn:
> I didn't found out how to install the utf library (by looking it up, I
> found out it was a librairy for plan9), do you know how I could install
> it ? For your information, I am trying to compile it on a arch based
> distro.

I haven't used lchat, but I'd guess it's the libutf that is embedded 
in sbase; see https://git.suckless.org/sbase

If not, cls' libutf used to be used by some suckless projects, IIRC, 
so that could be worth checking on. https://github.com/cls/libutf

Nick

Re: [dev] [st] When shrinking the width of a st window, overflowing text gets cut out and it is no longer retrievable, not even if the width is reset to the original one

[Nick]

Quoth Lee Phillips:
> > What I did to make it work is to run "./scroll" in an already-existing st
> > window, as you would with GNU screen or tmux.
> 
> This works! Thank you very much.
> 
> I was following the instructions in the man page, which say to do `scroll st`.

Nope, the manpage includes this (and looking at git history, has 
since its inception):

EXAMPLES
 st -e scroll /bin/sh

You must have misread it. Anyway, I'm glad it's working for you.  
This thread encouraged me to try it out too (I've been using dvtm 
for this purpose up 'til now), and it seems to be working just fine.

Nick

Re: [dev] [LibrePlanet]: New Presentation

[Nick]

Quoth Hiltjo Posthuma:
> Hi,
> 
> The link doesn't seem to work for me (HTTP 404).
> 
> What is the topic about specificly?
> 
> Are there slides?

This is some sort of spam; precisely the same message was sent to 
the Replicant list, presumably others too.

Best ignored. Or investigated, if you're so inclined.

Re: [dev] [st] Copy from st and paste to Chrome, cause Chrome crash

[Nick]

Hi Damon,

Quoth Damon: 
> I am using: 
> st 0.8.2 with these patches: font2, scrollback, scrollback-mouse, 
> scrollback-mouse-altscreen. 
> Chrome 80.0 
> bspwm
> 
> If I ctrl+shift+c copy something in ST, I can not paste it in Chrome. The 
> right-click menu doesn't work for the address bar or input field, neither 
> ctrl+v does. 

I'm guessing you're new to Linux. There are several different 
"selections" (clipboards) in X. When you select something with the 
mouse in st, it's automatically put onto the primary selection, 
which you can paste somewhere else with the middle mouse button.  
Right click -> paste, and Ctrl+v, generally work on the "clipboard" 
selection (not primary selection), so they won't work. Some other 
terminal emulators copy to the clipboard selection using 
ctrl+shift+c, but st doesn't.

There are programs that run in the background and can provide a "one 
clipboard" experience like you're probably used to with Windows or 
OSX, I recommend you read this for more details:
https://wiki.archlinux.org/index.php/Clipboard

> When I switch focus from chrome to other windows, the menu popup. After a few 
> right-click, chrome crash
> Chromium has this problem too.

That is unrelated to your copy-paste issue. Sounds like either a 
chrome issue or (more likely) a bspwm issue, either way this is not 
the place to find support for it.

Hope this helps,

Nick

Re: [dev] [surf] Bug: _SURF_URI and _SURF_GO sometimes won't update

[Nick]

Quoth Szpak: 
> It's not very often so I don't worry much about that, but I have a feeling
> that (at least on my machine) it's related to:
> 1. using proxy (privoxy or squid in my case);
> 2. unfinished page loading, which stops at some percent before 100, like 89%
> or even 40%;
> 
> The problem number 2 was already discussed here on suckless list a while ago
> but I cannot find it now. Maybe someone else can confirm that it's related
> or not.

FYI that was my post, thread starts here: 
http://lists.suckless.org/dev/1803/32607.html

I don't know if it's related to the OP's issue or not.

Re: [dev] [Announce] [dwm-6.2] [dmenu-4.9] new release

[Nick]

Quoth inasprecali:
> Thanks for the effort. Actually, I just found out that a "historical" patch 
> exists, which seems
> to include you as a contributor: 
> https://dwm.suckless.org/patches/historical/xft/
> (Admittedly, I didn't know, I started using dwm recently and I didn't bother 
> looking up old
> patches until now).
> It shouldn't be a massive amount of work to port it to 6.2, I think.

6.2 still has Xft support, it's later releases that won't. But yes, 
I'm sure it'll be patchable for those who need it.

Thanks Anselm and Hiltjo and everyone for the software!

[dev] Let's talk about Go, baby

[Nick]

Quoth Hiltjo Posthuma:
> On Fri, Jan 25, 2019 at 02:21:26PM +0000, Nick wrote:
> > That way we can devote the mailing list to more productive pursuits,
> > like arguing for the millionth time that C++ is terrible.
> > 
> 
> Don't keep spamming the mailinglist with the same things then. It is up to the
> community to make the mailinglist interesting. An example could be to post 
> your
> personal projects (that conform to the suckless philosophy ofcourse) or 
> patches
> that make the software world better.
> 
> It is a community group effort to make suckless an interesting and fun place 
> to
> be.

I know, I was just joking, I agree.

On that subject, I've been really enjoying writing Go code, lately.  
It's the first high level language I've properly enjoyed using for 
an extended period of time, and the standard library is great. My 
favourite thing about it is that there aren't really many language 
features, but what is there is very powerful (interfaces ftw!), so 
it's easy to learn, understand, and read.

I'm still learning, so figuring out the best ways to construct and 
organise things is a work in progress (my first proper project had 
many tiny libraries, which is annoying), but I'm getting there. And 
the journey to becoming competent in a different language is 
certainly helping me think through problems in new ways, which is 
always good.

Anybody else enjoying Go? Or hating it? Have I become lazy and 
trendy in my middle age?

Love y'all.

[dev] Building workarounds to libxft bug into dwm, st and dmenu

[Nick]

Quoth Alexander Krotov: 
> It is a known bug in libxft:
> https://gitlab.freedesktop.org/xorg/lib/libxft/issues/6
> 
> You can remove Noto fonts as a workaround.

Is there still resistance amongst maintainers of st, dwm and dmenu 
to work around this in the code? Something like the recent patch 
sent to the hackers list, subject line:
  [hackers] [libsl][PATCH] Workaround Xft BadLength X error
looks perfectly reasonable to me. This has been a crashing problem 
for quite a while now, and it looks like it will be a while longer 
until upstream and the distros most people use fix libxft.

That way we can devote the mailing list to more productive pursuits,
like arguing for the millionth time that C++ is terrible.

Re: [dev] suckless html to markdown (text)

[Nick]

Quoth Alexander Krotov:
> > Ideally, with sed/awk, or better in C.
> 
> "Parsing" HTML with sed is simply wrong.

This is a good point that I should have mentioned. I spent years 
using sed and awk to extract things from HTML, writing crawlers and 
suchlike, for personal projects. It can work, of course, but tends 
to be very obfuscated and fragile. I haven't needed to do any such 
crawling for a while now (and often the data is easier to access as 
json, an unexpected side-effect of the horrors of javascript 
overuse), but if I needed to I'd likely look into using something 
like go's html parsing these days.  I'd rather have something 
slightly slower that's more robust and reusable, really.  awk is a 
good fit for line-based parsing, and sed is good for stream 
transformation, neither work well for parsing machine-generated 
mountains of HTML of the sort that dominates the web today.

Re: [dev] suckless html to markdown (text)

[Nick]

Hi Thuban,

Quoth Thuban: 
> I'm looking for a suckless  html to markdown (or text) tool.
> Ideally, with sed/awk, or better in C. 

pandoc seems to always do a reasonable job - I use it daily for 
this.  It's written in haskell, which may not fit your definition of 
suckless, but it is widely used and seems quite sensible. It can 
also convert to formats like epub, if that's useful for you.

Nick

Re: [dev] [surf] Proxy not respected

[Nick]

Hi Peter,

Quoth Quentin Rameau: 
> So maybe something's wrong with your webkitgtk/libsoup setup.

To add on to what Quentin said, webkitgtk2 hasn't always respected 
the http_proxy variable, so updating it is definitely the likely fix 
here. I used to have the same problem.

That said, as I laid out in a post to this mailing list in March 
"[surf] unreliable loading of multiple requests over tor", the proxy 
support in new webkitgtk2 is still a bit crap, at least for me and 
some other users.

Nick

Re: [dev][surf] SURF_FIND not working after WebKitGtk update

[Nick]

Hi Ian,

Quoth Ian Macdonald: 
> I have just updated webkitgtk from 2.18.3 to 2.20.2 and now the 'search
> page' hot keys ( CTRL-slash and Ctrl-f ) no longer do anything.
> 
> Has anyone else had this problem?

I don't have time to look into it properly, but as a datapoint I'm 
currently using a self-built webkitgtk e27fd1c (which is 2.21.1 ish, 
by the looks of it), and the search in page functionality of surf is 
working fine for me.

Re: [dev] Surf with SOCKS5 proxy

[Nick]

Quoth Piotr:
> Does Surf work woith Socks5 proxy? How to configure it?

If you're using the webkit2 branch, then if the 
webkit/libsoap/whatever is not too old it will respect the 
http_proxy and https_proxy environment variables, so set your socks 
environment variables appropriately (you can search the correct 
variable names; I don't use socks proxies myself).

Re: [dev] [surf] [patch] Optionally handle downloads through webkit.

[Nick]

Quoth v4hn:
> On Thu, Mar 22, 2018 at 08:54:34PM +0000, Nick wrote:
> > I wonder whether it would be best to move to webkit handling
> > downloads itself, like this, albeit with a basic user interface.
> 
> This is not a new thought.
> Five years ago people thought it a bad idea.
> 
> https://lists.suckless.org/dev/1301/14371.html

Yeah, I remember that, vaguely. But times have changed. Like 
Quentin, I have definitely found times that surf downloads have 
failed through curl, while they work in alternative browsers. surf 
will always have more suck than we'd like, because of the 
architecture of the web. May as well at least have it handle as much 
as possible of that web correctly.

Re: [dev] [surf] [patch] Optionally handle downloads through webkit.

[Nick]

Hi Arturo,

Quoth Arturo Espinosa: 
> The problem is that with the way surf currently handles downloads, it
> is not possible to handle Blob URIs, since these are resources that
> are only accessible through the web component's internal state.
> 
> Our current solution is to disable curl spawning within surf's code,
> and let webkit handle the download silently. This is an adequate
> solution for us, and we are sending you a small patch that enables
> this functionality as a command-line option.

I just looked briefly at the patch, my first impression is that it 
looks good (I didn't test it).

I wonder whether it would be best to move to webkit handling 
downloads itself, like this, albeit with a basic user interface.  
Blob URIs, as distasteful as some may find them, are parts of the 
web that surf should handle. I think it probably makes more sense to 
just handle all downloads internally, rather than special-case it 
for blobs, so that any other edge-cases like this are more likely to 
be handled by webkit directly.

If the consensus is against this, then this patch should certainly 
go on the wiki. I don't think it makes sense to mainline it, as 
expecting a user to know whether they will need webkit's internal 
download functionality before launching the browser is silly in 
general.

Nick

Re: [dev] [surf] unreliable loading of multiple requests over tor

[Nick]

Quoth Nick: 
> Quoth Quentin Rameau: 
> > Sadly, the webkit process is managing connexions, surf itself doesn't.
> 
> Yeah, I thought that, it may be tricky to debug. This has persisted 
> across the many versions of webkit2 I've used (compiling from 
> source). I'm pretty sure it also happened with webkit1, but I 
> haven't used that for ages.
>
> [snip]
> I'll have a look in the webkit tracker, and see what I can find...

I found the bug on their tracker, along with an annoying workaround: 
https://bugs.webkit.org/show_bug.cgi?id=183163

Last time I dug around in libsoup/webkitgtk I found it unhelpful to 
my mental health. Do I dare swim through that bog again?

Re: [dev] What would a well-designed voice assistant program look like?

[Nick]

Quoth Laslo Hunhold: 
> You'll not get around having to rely on a pre-trained neuronal network
> unless you manage to formalize speech (partially done) or intelligence
> (currently not done and probably impossible).
> In this regard, personal assistants will by definition be bound to
> centralized services, and if you ever think about solving it in open
> source, it will have to be distributed like Diaspora or something
> comparable. If you design it as a "single instance" from the get-go, it
> will fail in the long run.

Well, training such a neural network would certainly require a lot 
of computer power and resources, but unless I'm mistaken I don't 
think running a query through it should be challenging for a non- 
internet connected computer. I haven't used speech recognition 
neural network stuff before, but I'd be surprised if it needed more 
space and compute power than were available on a smartphone.

I don't really see the point of these assistants, but I certainly 
wouldn't consider one with the current architecture of "send every 
sound to large SF corporations."

Re: [dev] [surf] unreliable loading of multiple requests over tor

[Nick]

Thanks for getting back to me, Quentin.

Quoth Quentin Rameau: 
> Sadly, the webkit process is managing connexions, surf itself doesn't.

Yeah, I thought that, it may be tricky to debug. This has persisted 
across the many versions of webkit2 I've used (compiling from 
source). I'm pretty sure it also happened with webkit1, but I 
haven't used that for ages.

> > This never happens when using Tor Browser, though that uses its own 
> > Tor process.
> 
> AFAIK, Tor Browser is Firefox.

That's correct, so not a particularly useful datapoint.

> > I don't find connection problems using Tor+Privoxy with other tools 
> > like youtube-dl or wget, but then there aren't so many simultaneous 
> > requests.
> 
> Could you try with other webkitgtk-based broswers (like midori,
> epiphany) to see if you get the same issue?

I just tried with uzbl (after working around a page load bug 
https://github.com/uzbl/uzbl/issues/397 - it's not very maintained 
these days, by the looks of it). It has exactly the same issue, 
sadly.

I also had a binary of Google Chrome lying around, which did work 
fine with the proxy. But obviously that isn't going to be using 
regular webkit2.

Just in case, I modified my config.h to turn on everything in 
defconfig, and the issue remained. I'll have a look in the webkit 
tracker, and see what I can find...

Nick

[dev] [surf] unreliable loading of multiple requests over tor

[Nick]

Hi all,

I've had this issue with surf forever, but it is gradually becoming 
more of a problem as the web gets ever further away from HTML pages 
served over HTTP.

When using Tor+Privoxy in standard configuration, and sending surf's 
traffic through that by setting the http_proxy and https_proxy 
environment variables, complex pages generally never fully load.  
Specifically, they will partly load, say to 80%, but remaining 
transfers never complete. When I say "complex pages", I mean pages 
which have serious javascript stuff going on, like Google Maps and 
Google Docs. Sometimes they load fine, but more often they do not.
I put up a screenshot of an example failure with the web inspector 
at: https://njw.name/tmp/surfmaps.png

This never happens when using Tor Browser, though that uses its own 
Tor process.

I don't find connection problems using Tor+Privoxy with other tools 
like youtube-dl or wget, but then there aren't so many simultaneous 
requests.

Possibly related (though I haven't had time to investigate much 
yet), the cloudflare captcha page often fails to load the captcha 
part of the page, with a "400 Bad Request" on the payload URL that 
looks like this https://www.google.com/recaptcha/api2/payload?c=[longstring]

As you can tell, I haven't done a lot of debugging on this as of 
yet, but I thought I'd post here to see if others have experienced 
the same issues, or have any thoughts as to the cause of them.  

Nick

Re: [dev] [PATCH][blind] alloca #include for BSDs

[Nick]

Quoth Anthony J. Bentley:
> Variables set with = can easily be overridden by packagers simply by
> passing them as arguments to make(1).
> 
> That's fine for warnings and optimization flags since changing them
> doesn't hurt anything. If -std=c99 is necessary for the build, it
> shouldn't be in CFLAGS at all for that reason.

I see the logic, however to my knowledge no distributor has ever 
complained about the build process for dwm, which uses the same 
system, and is very widely distributed. So I'd be inclined to keep 
it as is until such a time as someone comes up with a real use-case 
for changing it. 

Re: [dev] [PATCH][blind] alloca #include for BSDs

[Nick]

Quoth Yuri: 
> You should also change your config.mk files to allow external optimization
> and other flags. For example:
> 
> > CFLAGS   = -std=c99 -Wall -pedantic -O2
> 
> should be changed to
> 
> > CFLAGS   ?= -O2
> 
> > CFLAGS   += -std=c99 -Wall -pedantic -O2
> 
> This way you can allow externally supplied optimization flags while still
> being able to add your own flags. Same with CPPFLAGS and LDFLAGS.

I believe the reason suckless projects stick to = rather than += or 
?= is that they aren't POSIX / OSI standard. I don't think there's a 
compelling reason to switch to your syntax, as distribution builders 
or whoever can still easily see what the CFLAGS were and add to them 
if they want or need to.

Nick

Re: [dev] [st] Multiple monitors dpi autoswitch

[Nick]

Quoth Amer: 
> Wish -- [st] automatically adjusts it's font size for the monitor,
> manually evaluating monitor dpi from queried physical geometry,
> assuming that both monitors placed on equal distance and require similar
> physical size of letters on screen.

Sounds good to me. I imagine that would probably stay as a patch, as 
automatic font resizing might not be popular with a lot of people, 
but I'd certainly like it, for when I plug my 96 dpi monitor into my 
221 dpi laptop.

I'm pretty sure noone has written something similar for st before, 
so go, code!

Re: [dev] announcing edit-pipe

[Nick]

Quoth Greg Reagle: 
> > * Quote "$edit" in case the editor has a space in its name.
> 
> I deliberately do not quote $edit so that I can set EDITOR to nano -w. 
> Is that non-standard/wacky?  Is there a convention for whether the the
> value of EDITOR environment variable should be able to have options?

Any system that has an EDITOR which includes spaces isn't worth 
supporting. Doubly so because you have a reasonable use-case that 
makes quoting it the wrong thing to do. Bourne shell scripts will 
always have to make certain trade-offs between portability and 
readability. You could make the script massive and try (and fail) to 
cover every eventuality, and it would get more and more horrible and 
fail in more and more subtle ways. Supporting diverse stupid systems 
is what made the GNU code as crazy as it is (arguably that helped it 
gain dominance back when there were so many different and 
incompatible unix systems, happily that's no longer the case today).

Re: [dev] dl.suckless.org file integrity github project

[Nick]

Quoth Joshua Haase: 
> It's not so many work if git is configured to always sign and/or the
> package build system sign by default.

Configuring git to sign every commit is a pain if you have a 
passphrase on your gpg key, or it's tied to a smartcard; entering 
that every time you commit makes the process a lot more annoying.  
Yes, I'm sure you could configure gpg-agent to some mode to mitigate 
that somewhat, but I don't think it's worth it. Just for each tag 
would be fine.

Re: [dev] dl.suckless.org file integrity github project

[Nick]

Quoth Aaron Toponce:
> On Thu, Aug 24, 2017 at 12:45:15AM +0200, hiro wrote:
> > Any responsible suckless person should not download Aaron's software.
> > I cannot guarantee it's not ransomware!
>
> There is no software on that github repository. It's all raw text.

He's just trolling you, while implying that checksums can be used to 
imply more safety than they provide. Internet, eh?

Re: [dev] dl.suckless.org file integrity github project

[Nick]

FWIW, as someone who mostly just a user of suckless stuff, I like 
OpenPGP signing too. I don't have a strong opinion of git tags vs 
tarballs for signing, either is good. It's nice to have a properly 
secure proof of authenticity that doesn't depend on the link not 
being compromised.

I'm really glad HTTPS is going to be rolled out to suckless.org 
soon, thanks for that!

Personally I've gone off the web of trust model somewhat, it 
somewhat depends on long-lived keys, which given the lack of PFS is 
hard to manage securely. But OpenPGP signatures on software, from 
developers, is great. I plan of just doxing all of the suckless devs 
and knocking on their doors demanding to see their signatures. Much 
better. Or maybe checking them once on a different band to where I 
get the software... All depends on my mood.

Nick


Quoth Markus Teich:
> Hiltjo Posthuma wrote:
> > Checksums are available in each project directory, yesterday I've added
> > SHA256 checksums.
> > 
> > For example:
> > SHA256: http://dl.suckless.org/dwm/sha256sums.txt
> > SHA1:   http://dl.suckless.org/dwm/sha1sums.txt
> > MD5:http://dl.suckless.org/dwm/md5sums.txt
> > 
> > HTTPs will be coming in a few weeks when some things are sorted. Maybe in 
> > the
> > future we can add also add PGP signed releases.
> 
> Heyho,
> 
> I don't see the benefit of checksums without signatures. We already kind of 
> have
> transmission integrity by IP for release downloads or by git. We really need
> https, but PGP is probably controversial enough to be discussed. Maybe we have
> some time for that at the hackathon, but that would exclude people who cannot
> attend.
> 
> Thus, start flaming your highly valued opinions about PGP-signing releases to
> the list nao! ;P
> 
> --Markus
> 

Re: [dev] Surf update

[Nick]

Quoth Quentin Rameau:
> surf will “officially” make the switch from webkit1 to webkit2 soon.
> Current master will be pushed to surf-webkit1, and surf-webkit2 to
> master. The move should be done during the coming weekend or sometime
> next week.

Sounds good, I've been using surf-webkit2 for months now with no 
issues. Thanks for your work on surf.

Re: [dev] [surf] badssl.com

[Nick]

Quoth Quentin Rameau: 
> > It does, but it will still make the connection. I'd rather some 
> > dialog box, so that my session state won't be automatically passed 
> > along to an untrusted server. Not sure the most elegant way to do 
> > this - I suppose one could have a little dmenu prompt asking whether 
> > to continue the connection or cancel it.
> I've implemented something like this in surf-webkit2, but I'm waiting on
> another dmenu commit for it to be fully acceptable before pushing.
>
> ...
> 
> In any cas, thanks for the feedback, I hope I can push those changes in
> the near future.
> The surf organisation is in a modification phase, for the better I hope,
> keep connected for future changes.

That's all great to hear Quentin, thanks for all your work on 
surf-webkit2, which I am happy to use daily (with a lightly patched 
webkit2 so that proxies work correctly).

Re: [dev] [surf] badssl.com

[Nick]

Quoth Alexander Keller:
> > surf is not _silently_ ignoring them. If the validation fails, `sslfailed` 
> > will be true and in the window title you can see a `…:U` for untrusted 
> > instead of `…:T` for trusted.
> 
> You're right. It does provide that feedback. My apologies. :)

It does, but it will still make the connection. I'd rather some 
dialog box, so that my session state won't be automatically passed 
along to an untrusted server. Not sure the most elegant way to do 
this - I suppose one could have a little dmenu prompt asking whether 
to continue the connection or cancel it.

> I've just been doing a bunch of digging in the TLS code under `void
> loadstatuschange`. I was prompted because it listed my own domain as
> untrusted. It turns out, if the website is cached and you visit a page
> at https, the page will be marked untrusted. This is because `msg` will
> have no certificate attached. I don't know if this behaviour is
> intentional. You can test this with:
> https://developer.gnome.org/gio/stable/gio-TLS-Overview.html
> 
> Load the page, then close surf and open the page again. The first time
> you visit it will be trusted, the second it will be untrusted. It will
> load regardless of your `strictssl` setting. If it is untrusted the
> first time, clear your cache in `~/.surf/cache/` then repeat the
> experiment you should see it.

Good find, thanks, I had been wondering why some sites showed 
untrusted seemingly erroneously.

Re: [dev] seif opinions?

[Nick Warne]

On Sun, 25 Sep 2016 09:23:11 -0700
Louis Santillan <lpsan...@gmail.com> wrote:


> infrastructure player (like a bank {PayPal}...

Paypal isn't a bank.

Nick
-- 
"Gosh that takes me back... or is it forward?  That's the trouble with
time travel, you never can tell."
-- Doctor Who "Androids of Tara"

Re: [dev] https for suckless.org?

[Nick Warne]

On Sat, 24 Sep 2016 21:25:32 +0100
Joseph Graham <jos...@xylon.me.uk> wrote:

> On Sat, Sep 24, 2016 at 08:54:39PM +0200, ilf wrote:
> > I wonder why the suckless-websites are only available in HTTP, not
> > in HTTPS. In the age of letsencrypt.org, there aren't a lot of
> > valid excuses against TLS. Am I missing one from a
> > suckless-philosopy? Or has this just never been requested?
> > 
> > I for one would love to see unencrypted communications on the
> > internet die.
> > 
> > Greetings to slcon!
> > 
> > (Pardon if it's been discussed, I did not find it in the archives.)
> > 
> > -- 
> > ilf
> > 
> > Über 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht
> > weg! -- Eine Initiative des Bundesamtes für Tastaturbenutzung  
> 
> HTTPS is unecessary and bloated. It creates loads of latency on
> connection, it stops proxies caching requests between clients. All
> just for some false sense of security.
> 
> -Joseph
> 
> 

Whatever:

https://sslmate.com/

Nick
-- 
"Gosh that takes me back... or is it forward?  That's the trouble with
time travel, you never can tell."
-- Doctor Who "Androids of Tara"

Re: [dev] [st] Scrollback patch crashes X

[Nick Warne]

On Sat, 24 Sep 2016 17:30:41 +0100
Nick Warne <n...@linicks.net> wrote:

> On Sat, 24 Sep 2016 17:11:23 +0100
> Nick Warne <n...@linicks.net> wrote:
> 
> > Hi Jochen,
> > 
> > On Sat, 24 Sep 2016 17:47:04 +0200
> > Jochen Sprickerhof <d...@jochen.sprickerhof.de> wrote:
> >   
> > > Hi Nick,
> > > 
> > > * Nick Warne <n...@linicks.net> [2016-09-24 12:50]:
> > > > To reproduce, use st with just the scrollback patch applied.
> > > > 
> > > > Start dwm, and then use nano to load a large(ish) file (like
> > > > dwm.c), and use the PgDn key to scroll down - after about 10
> > > > seconds, X locks up - keyboard/mouse don't do anything.  
> > > 
> > > I've tested it over here but wasn't able to reproduce it (had to
> > > copy dwm.c a couple of times to get 10sec of scroll down). I used
> > > st f739843 (with scrollback), nano 2.7.0 and xorg 1.18.4 from
> > > Debian unstable. What did you use? Can you send a backtrace?
> > 
> > I didn't mean a 10 second scroll back - I just meant using PgDn a
> > few times then maybe up, then down, after 10 ~ 20 secs X crashes...
> > not the length of scroll.
> > 
> > OK, my X is pretty old (maybe the problem):
> > 
> > X.Org X Server 1.14.3 (Slackware 14.1)
> > 
> > nano is 2.6.3
> > 
> > I will update nano first, I didn't realise there was a new
> > release.  
> 
> First report :D
> 
> OK, this is getting messy.  nano version 2.7.0, but I just found that
> dwm stomps on the nano keyboard sequence Shift+Alt+$ to soft wrap long
> lines - dwm pushes me to TAG 4.
> 
> From nano help (Ctrl g):
> M-$ Soft wrapping of overlong lines enable/disable
> 
> I need to do more reading - or maybe hack nano to use a different key
> sequence.

OK, time for me to SHUT THE FUCK UP.

It was my fault.  All works fine with nano and the patched st with
scrollback.

This morning I re-built dwm with my own terminal pointed too in
config.h, but forgot to restart it - so from the original boot-up I was
running st - then after I installed dwm every new terminal spawn... so
now everything has it's [k]nickers in a twist.

Sorry for the terrible noise.

All works great

Nick
P.S. I _will_ pay attention :)
-- 
"Gosh that takes me back... or is it forward?  That's the trouble with
time travel, you never can tell."
-- Doctor Who "Androids of Tara"

Re: [dev] [ST] scroll patch build failure [Really SOLVED]

[Nick Warne]

On Sat, 24 Sep 2016 17:49:00 +0100
Nick Warne <n...@linicks.net> wrote:

> On Sat, 24 Sep 2016 18:43:18 +0200
> Jochen Sprickerhof <d...@jochen.sprickerhof.de> wrote:
> 
> > * Nick Warne <n...@linicks.net> [2016-09-24 17:39]:  
> > > rm config.h, and it builds fine from scratch.  make clean doesn't
> > > remove config.h (should it?).
> > 
> > No, it should not. config.h is your own configuration and you should
> > know how to update it if config.def.h changes.  

Sorry, I see what you mean.  I will shut-up for a bit.

> Well, yes and no.  The patch applies a new #DEFINE that isn't in the
> original config.mk - so unless you _read_ all the patched config.mk,
> then I fail with existing config.h
> 
> Nick



-- 
"Gosh that takes me back... or is it forward?  That's the trouble with
time travel, you never can tell."
-- Doctor Who "Androids of Tara"

Re: [dev] [ST] scroll patch build failure [Really SOLVED]

[Nick Warne]

On Sat, 24 Sep 2016 18:43:18 +0200
Jochen Sprickerhof <d...@jochen.sprickerhof.de> wrote:

> * Nick Warne <n...@linicks.net> [2016-09-24 17:39]:
> > rm config.h, and it builds fine from scratch.  make clean doesn't
> > remove config.h (should it?).  
> 
> No, it should not. config.h is your own configuration and you should
> know how to update it if config.def.h changes.

Well, yes and no.  The patch applies a new #DEFINE that isn't in the
original config.mk - so unless you _read_ all the patched config.mk,
then I fail with existing config.h

Nick
-- 
"Gosh that takes me back... or is it forward?  That's the trouble with
time travel, you never can tell."
-- Doctor Who "Androids of Tara"

Re: [dev] [ST] scroll patch build failure [Really SOLVED]

[Nick Warne]

On Fri, 23 Sep 2016 17:09:36 +0100
Nick Warne <n...@linicks.net> wrote:

> I am not getting much luck here (do _I_ suck?) :(
> 
> dwm and st work great so far and I am well impressed and happy; but
> any patches I apply either fail:
> 
> http://lists.suckless.org/dev/1609/30448.html
> 
> (I have since tried git versions, and it fails to build - but more
> later, that is on the back-burner for a mo)
> 
> ...or get build errors:
> 
> apply the patch to st for scrollback.  Latest git
> and latest diff. Patches fine.
> 
> > make  
> 
> st.c:337:12: error: ‘histsize’ undeclared here (not in a function)
>   Line hist[histsize]; /* history buffer */
> 
> I have read through the code several times for about an hour, but
> can't work out what is going on?

OK, working on the scrollback X crash problem, I found out what is going
on here for the record.

Get git st, build it, install it.  Now get the scrollback patch, apply,
and build.

Then the build error hapens, as you already have a config.h that is not
updated from config.mk.

rm config.h, and it builds fine from scratch.  make clean doesn't
remove config.h (should it?).

Nick
-- 
"Gosh that takes me back... or is it forward?  That's the trouble with
time travel, you never can tell."
-- Doctor Who "Androids of Tara"

Re: [dev] [st] Scrollback patch crashes X

[Nick Warne]

On Sat, 24 Sep 2016 17:11:23 +0100
Nick Warne <n...@linicks.net> wrote:

> Hi Jochen,
> 
> On Sat, 24 Sep 2016 17:47:04 +0200
> Jochen Sprickerhof <d...@jochen.sprickerhof.de> wrote:
> 
> > Hi Nick,
> > 
> > * Nick Warne <n...@linicks.net> [2016-09-24 12:50]:  
> > > To reproduce, use st with just the scrollback patch applied.
> > > 
> > > Start dwm, and then use nano to load a large(ish) file (like
> > > dwm.c), and use the PgDn key to scroll down - after about 10
> > > seconds, X locks up - keyboard/mouse don't do anything.
> > 
> > I've tested it over here but wasn't able to reproduce it (had to
> > copy dwm.c a couple of times to get 10sec of scroll down). I used st
> > f739843 (with scrollback), nano 2.7.0 and xorg 1.18.4 from Debian
> > unstable. What did you use? Can you send a backtrace?  
> 
> I didn't mean a 10 second scroll back - I just meant using PgDn a few
> times then maybe up, then down, after 10 ~ 20 secs X crashes... not
> the length of scroll.
> 
> OK, my X is pretty old (maybe the problem):
> 
> X.Org X Server 1.14.3 (Slackware 14.1)
> 
> nano is 2.6.3
> 
> I will update nano first, I didn't realise there was a new release.

First report :D

OK, this is getting messy.  nano version 2.7.0, but I just found that
dwm stomps on the nano keyboard sequence Shift+Alt+$ to soft wrap long
lines - dwm pushes me to TAG 4.

From nano help (Ctrl g):
M-$ Soft wrapping of overlong lines enable/disable

I need to do more reading - or maybe hack nano to use a different key
sequence.

Nick
-- 
"Gosh that takes me back... or is it forward?  That's the trouble with
time travel, you never can tell."
-- Doctor Who "Androids of Tara"

Re: [dev] [st] Scrollback patch crashes X

[Nick Warne]

Hi Jochen,

On Sat, 24 Sep 2016 17:47:04 +0200
Jochen Sprickerhof <d...@jochen.sprickerhof.de> wrote:

> Hi Nick,
> 
> * Nick Warne <n...@linicks.net> [2016-09-24 12:50]:
> > To reproduce, use st with just the scrollback patch applied.
> > 
> > Start dwm, and then use nano to load a large(ish) file (like dwm.c),
> > and use the PgDn key to scroll down - after about 10 seconds, X
> > locks up - keyboard/mouse don't do anything.  
> 
> I've tested it over here but wasn't able to reproduce it (had to copy
> dwm.c a couple of times to get 10sec of scroll down). I used st
> f739843 (with scrollback), nano 2.7.0 and xorg 1.18.4 from Debian
> unstable. What did you use? Can you send a backtrace?

I didn't mean a 10 second scroll back - I just meant using PgDn a few
times then maybe up, then down, after 10 ~ 20 secs X crashes... not the
length of scroll.

OK, my X is pretty old (maybe the problem):

X.Org X Server 1.14.3 (Slackware 14.1)

nano is 2.6.3

I will update nano first, I didn't realise there was a new release.

I will then go through the steps again, and try to capture the crash
from Xorg logs.  Maybe it will be tomorrow now ~ too many beers
already ;)

Thanks for the help,

Nick
-- 
"Gosh that takes me back... or is it forward?  That's the trouble with
time travel, you never can tell."
-- Doctor Who "Androids of Tara"

Re: [dev] [st] Scrollback patch crashes X

[Nick Warne]

On Sat, 24 Sep 2016 16:57:02 +0200
Martin Kühne <mysat...@gmail.com> wrote:

> You could just use a symbolic link in your $HOME or something instead
> of rebuilding dwm every time.

I don't. Once built, that's it - and as it happens, my own build of
xfce4-terminal works great.

> Just because this setup tends to make you do it, doesn't mean you have
> to solve every problem you have into it.

I just done this to retrace the steps and test st without the
scrollback patch.  symlinks can lead to unexpected results sometimes.

> cheers!
> mar77i
> 

Nick
-- 
"Gosh that takes me back... or is it forward?  That's the trouble with
time travel, you never can tell."
-- Doctor Who "Androids of Tara"

Re: [dev] [st] Scrollback patch crashes X

[Nick Warne]

On Sat, 24 Sep 2016 09:40:38 -0400
Greg Reagle <greg.rea...@umbc.edu> wrote:

> On Sat, Sep 24, 2016, at 09:33, Nick Warne wrote:
> > rebuilt dwm to use st.  
> 
> What does that mean?
> 

I change config.h to use xfce4-terminal, so changed back to use st:

//static const char *termcmd[]  = { "xfce4-terminal", NULL };
static const char *termcmd[]  = { "st", NULL };

I don't like to use symlinks - you can soon get lost to what is what.

Nick
-- 
"Gosh that takes me back... or is it forward?  That's the trouble with
time travel, you never can tell."
-- Doctor Who "Androids of Tara"

Re: [dev] [st] Scrollback patch crashes X

[Nick Warne]

On Sat, 24 Sep 2016 08:55:53 -0400
Greg Reagle <greg.rea...@umbc.edu> wrote:

> On Sat, Sep 24, 2016, at 07:50, Nick Warne wrote:
> > With latest git st and latest git scrollback patch, I had 3 X
> > crashes  
> 
> Does it happen with the latest unpatched st?
> 

OK, just cleaned out st, a new git clone, rebuilt and installed, and
rebuilt dwm to use st.

After a quick 5 minutes in nano messing about, everything works OK.

This morning with the patched st, nano with PgDn crashed X after 20
seconds or so.

Nick
-- 
"Gosh that takes me back... or is it forward?  That's the trouble with
time travel, you never can tell."
-- Doctor Who "Androids of Tara"

Re: [dev] [dwm] Firefox always opens in TAG 9

[Nick Warne]

On Sat, 24 Sep 2016 14:02:20 +0200
Martin Kühne <mysat...@gmail.com> wrote:

> What does that script look like and what does your config.h look like?
> Sounds like you had firefox set to launch on said tag in the latter.
> 
> cheers!
> mar77i
> 

My script from $HOME:

./progs/firefox/firefox > /dev/null 2>&1 &

...but it is in default config.h:

static const Rule rules[] = {
/* xprop(1):
 *  WM_CLASS(STRING) = instance, class
 *  WM_NAME(STRING) = title
 */
/* class  instancetitle   tags mask
isfloating   monitor */ { "Gimp", NULL,   NULL,
0,1,   -1 }, { "Firefox",  NULL,   NULL,
1 << 8, 0,   -1 },

So I have been playing:

static const Rule rules[] = {
/* xprop(1):
 *  WM_CLASS(STRING) = instance, class
 *  WM_NAME(STRING) = title
 */
/* class  instancetitle   tags mask
isfloating   monitor */ { "Gimp", NULL,   NULL,
0,1,   -1 }, { "Firefox",  NULL,   NULL,
1 << 8,   0,   -1 }, { NULL,  NULL,   "Claws
Mail",   1 << 4,   0,   -1 }, { "Dillo",  NULL,
NULL,   1 << 3,   0,   -1 }, };

Works a bloody treat!

dwm is a great bit of kit - wish I found it ages ago!

Nick
-- 
"Gosh that takes me back... or is it forward?  That's the trouble with
time travel, you never can tell."
-- Doctor Who "Androids of Tara"

Re: [dev] [dwm] Firefox always opens in TAG 9

[Nick Warne]

On Sat, 24 Sep 2016 11:38:24 +0200
Uwe <d...@uleenucks.de> wrote:

> On 24 September 2016 10:05:58 CEST, Nick Warne <n...@linicks.net>
> wrote:
> >
> >I have a small script that lauches firefox thus:
> >  
> >> ./ff  
> >
> >but no matter what TAG I run it from, Firefox always opens in TAG 9.
> >Now, no problem with this, but I am curious why only FF shows this
> >behaviour?
> >
> >Nick  
> 
> 
> Check your config.h and how Firefox is configured there  

Duh, didn't think to look there:

1 << 8 = 256 so bit 0 is TAG 1 ~ bit 8 is TAG 9.

Got it! 

Thanks,

Nick
-- 
"Gosh that takes me back... or is it forward?  That's the trouble with
time travel, you never can tell."
-- Doctor Who "Androids of Tara"

[dev] [dwm] Firefox always opens in TAG 9

[Nick Warne]

I have a small script that lauches firefox thus:

> ./ff

but no matter what TAG I run it from, Firefox always opens in TAG 9.
Now, no problem with this, but I am curious why only FF shows this
behaviour?

Nick
-- 
"Gosh that takes me back... or is it forward?  That's the trouble with
time travel, you never can tell."
-- Doctor Who "Androids of Tara"

Re: [dev] [ST] scroll patch build failure

[Nick Warne]

On Fri, 23 Sep 2016 13:43:22 -0300
Draco Metallium(Rodrigo S. Cañibano) <draco@gmail.com> wrote:

> My bad!

No way!

I just cloned st again, got the patch, applied, all builds now and
works OK.

Thanks,

Works a treat.

Nick

> I should have copy the line from the patch itself and not from my
> config.
> 
> On 23 September 2016 at 13:40, Nick Warne <n...@linicks.net> wrote:
> > On Fri, 23 Sep 2016 17:36:21 +0100
> > Nick Warne <n...@linicks.net> wrote:
> >  
> >> On Fri, 23 Sep 2016 13:32:14 -0300
> >> Draco Metallium(Rodrigo S. Cañibano) <draco@gmail.com> wrote:
> >>  
> >> > > st.c:337:12: error: ‘histsize’ undeclared here (not in a
> >> > > function) Line hist[histsize]; /* history buffer */  
> >> >
> >> > In the scroll patch 'histsize' is added to config.def.h, and
> >> > therefore to config.h. Didn't that patch apply?
> >> >
> >> > Does your config.h have a line with "#define histsize 5000"?
> >> >  
> >>
> >> No, nor does:
> >>
> >> st-scrollback-20160727-308bfbf.diff
> >>
> >> I guess I don't suck ;)  
> >
> > Or maybe I do:
> >
> >  #define histsize 2000
> >
> > Ummm.  Let me start again.
> >
> > Nick
> > --
> > "Gosh that takes me back... or is it forward?  That's the trouble
> > with time travel, you never can tell."
> > -- Doctor Who "Androids of Tara"
> >  
> 



-- 
"Gosh that takes me back... or is it forward?  That's the trouble with
time travel, you never can tell."
-- Doctor Who "Androids of Tara"

Re: [dev] [ST] scroll patch build failure

[Nick Warne]

On Fri, 23 Sep 2016 13:32:14 -0300
Draco Metallium(Rodrigo S. Cañibano) <draco@gmail.com> wrote:

> > st.c:337:12: error: ‘histsize’ undeclared here (not in a function)
> >   Line hist[histsize]; /* history buffer */  
> 
> In the scroll patch 'histsize' is added to config.def.h, and therefore
> to config.h. Didn't that patch apply?
> 
> Does your config.h have a line with "#define histsize 5000"?
> 

No, nor does:

st-scrollback-20160727-308bfbf.diff

I guess I don't suck ;)

Nick
-- 
"Gosh that takes me back... or is it forward?  That's the trouble with
time travel, you never can tell."
-- Doctor Who "Androids of Tara"

Re: [dev] [ST] scroll patch build failure

[Nick Warne]

On Fri, 23 Sep 2016 17:36:21 +0100
Nick Warne <n...@linicks.net> wrote:

> On Fri, 23 Sep 2016 13:32:14 -0300
> Draco Metallium(Rodrigo S. Cañibano) <draco@gmail.com> wrote:
> 
> > > st.c:337:12: error: ‘histsize’ undeclared here (not in a function)
> > >   Line hist[histsize]; /* history buffer */
> > 
> > In the scroll patch 'histsize' is added to config.def.h, and
> > therefore to config.h. Didn't that patch apply?
> > 
> > Does your config.h have a line with "#define histsize 5000"?
> >   
> 
> No, nor does:
> 
> st-scrollback-20160727-308bfbf.diff
> 
> I guess I don't suck ;)

Or maybe I do:

 #define histsize 2000

Ummm.  Let me start again.

Nick
-- 
"Gosh that takes me back... or is it forward?  That's the trouble with
time travel, you never can tell."
-- Doctor Who "Androids of Tara"

Re: [dev] [ST] scroll patch build failure [SOLVED]

[Nick Warne]

On Fri, 23 Sep 2016 17:09:36 +0100
Nick Warne <n...@linicks.net> wrote:

> I am not getting much luck here (do _I_ suck?) :(
> 
> dwm and st work great so far and I am well impressed and happy; but
> any patches I apply either fail:
> 
> http://lists.suckless.org/dev/1609/30448.html
> 
> (I have since tried git versions, and it fails to build - but more
> later, that is on the back-burner for a mo)
> 
> ...or get build errors:
> 
> apply the patch to st for scrollback.  Latest git
> and latest diff. Patches fine.
> 
> > make
> 
> st.c:337:12: error: ‘histsize’ undeclared here (not in a function)
>   Line hist[histsize]; /* history buffer */
> 
> I have read through the code several times for about an hour, but
> can't work out what is going on?
> 
> Ideas?

Talking to myself and going mad, I sorted it.

GCC being pedantic:

#CFLAGS += -g -std=c99 -pedantic -Wall -Wvariadic-macros -Os ${INCS}
${CPPFLAGS} CFLAGS += -g -std=c99 -Wall -Wvariadic-macros -Os ${INCS}
${CPPFLAGS}

All built and works great!

Thanks,

Nick
-- 
"Gosh that takes me back... or is it forward?  That's the trouble with
time travel, you never can tell."
-- Doctor Who "Androids of Tara"

[dev] [ST] scroll patch build failure

[Nick Warne]

I am not getting much luck here (do _I_ suck?) :(

dwm and st work great so far and I am well impressed and happy; but any
patches I apply either fail:

http://lists.suckless.org/dev/1609/30448.html

(I have since tried git versions, and it fails to build - but more
later, that is on the back-burner for a mo)

...or get build errors:

apply the patch to st for scrollback.  Latest git
and latest diff. Patches fine.

> make

st.c:337:12: error: ‘histsize’ undeclared here (not in a function)
  Line hist[histsize]; /* history buffer */

I have read through the code several times for about an hour, but can't
work out what is going on?

Ideas?

Thanks,

Nick
-- 
"Gosh that takes me back... or is it forward?  That's the trouble with
time travel, you never can tell."
-- Doctor Who "Androids of Tara"

Re: [dev] Just discovered dwm

[Nick Warne]

On Thu, 22 Sep 2016 21:31:09 +0200
hiro <23h...@gmail.com> wrote:

> then it's no better than ubuntu. i can deselect stuff there, too.
> 

So you use ubuntu? - deselect systemd?

What I meant was pulseaduio, KDE et al isn't a base requirement - just
if you want it.

Nick
-- 
"Gosh that takes me back... or is it forward?  That's the trouble with
time travel, you never can tell."
-- Doctor Who "Androids of Tara"

Re: [dev] slackware custom build

[Nick Warne]

On Thu, 22 Sep 2016 15:06:07 -0400
stephen Turner <stephen.n.tur...@gmail.com> wrote:

> This is a bit off topic and i wanted to avoid thread jacking another
> conversation.
> 
> I see people here are using slackware, i was considering a script
> package management system that allows for easy modifications for a
> "micro distribution" the idea was to not host any of the actual source
> but do everything through scripts. I see slackware does host the
> source tar balls but they have a script inside that facilitates the
> install?
> 

Try:

https://slackbuilds.org/

I use it a lot.  But I also have a directory called 'progs' in my $HOME
that I install stuff in to keep the system clean ~ obviously you need
to supply path info when using it, but e.g. dwm, st, dillo, claws-mail
all live there.

Nick
-- 
"Gosh that takes me back... or is it forward?  That's the trouble with
time travel, you never can tell."
-- Doctor Who "Androids of Tara"

Re: [dev] Just discovered dwm

[Nick Warne]

On 22 Sep 2016 09:51:00 +0100
Nick Warne <n...@linicks.net> wrote:

> On Sep 22 2016, Cág wrote:
> 
> >hiro wrote:
> >  
> >> networkmanager should be removed first thing on any distribution
> >> slack doesn't sound so great if it includes some crap tbh.  
> >
> >It has PulseAudio in the default installation. And KDE is
> >autoselected in the
> >installer.
> >
> >Cág  
> 
> I have none of that installed - just base Slackware.

Just got in from work and read the 14.2 release - pulseaudio?  Bloody
hell.  I still run 14.1, and that only has alsa and also KDE stuff is
only a singleton option on install - it can be deselected to not install
any of it (which I do).

I would say 14.2 follows the same logic.  You don't have to install KDE
and pulseaduio crap - just deselect them.

Nick
-- 
"Gosh that takes me back... or is it forward?  That's the trouble with
time travel, you never can tell."
-- Doctor Who "Androids of Tara"

Re: [dev] dwm systray diff for 6.1 fails.

[Nick Warne]

On Sep 22 2016, Eric Pruitt wrote:


On Wed, Sep 21, 2016 at 05:48:51PM +0100, Nick Warne wrote:

Was going to use this to monitor battery, but HUNK #10 fails - looking
at the patch and dwm.c, the code is totally different at around line
664:


Are you using the tagged 6.1 release or 6.1/HEAD? My version of the
patch applies cleanly against the current dwm HEAD:
https://github.com/ericpruitt/edge/blob/master/patches/dwm-00-systray.diff


I have stable release:

http://dl.suckless.org/dwm/dwm-6.1.tar.gz

and the diff that fails on HUNK#10 is:

http://dwm.suckless.org/patches/dwm-6.1-systray.diff

Nick
--
"Gosh that takes me back... or is it forward?  That's the trouble with
time travel, you never can tell."
-- Doctor Who "Androids of Tara"

Re: [dev] Just discovered dwm

[Nick Warne]

On Sep 22 2016, Cág wrote:


hiro wrote:


networkmanager should be removed first thing on any distribution
slack doesn't sound so great if it includes some crap tbh.


It has PulseAudio in the default installation. And KDE is autoselected 
in the

installer.

Cág


I have none of that installed - just base Slackware.

Nick
--
"Gosh that takes me back... or is it forward?  That's the trouble with
time travel, you never can tell."
-- Doctor Who "Androids of Tara"

Re: [dev] Just discovered dwm

[Nick Warne]

Hi Cág

On Wed, 21 Sep 2016 21:10:42 +0100
Cág <c...@riseup.net> wrote:


> Nice to see Slackware people here.

We are everywhere ;)  Just Slack never breaks so you don't see us :)
 
> > One little thing I do miss though is scrolling with mouse wheel (or
> > using the pad side edge) to scroll a web page etc.
> > 
> > Is that doable?
> >   
> 
> Try some of these [0]. Of course apply what fits you. There are some 
> example
> files I use now [1], since I use mdev on my Alpine and don't use udev 
> (but that
> should work everywhere).
> 
> Cheers,
> Cág
> 
> [0]: 
> https://wiki.archlinux.org/index.php/Touchpad_Synaptics#Configuration

\o/

I quickly went throguh Xorg stuff earlier after work tonight, but missed
the tree for the woods.

Option "VertEdgeScroll" "on"

Fixed it up - forgot I had to do that many years ago, most DE's now
(like xfce4) do it for you.

Many thanks - I was looking at dwm config.h to try to sort it.

Great stuff, and thanks also to all replied to my query!

BTW, sorted the wireless network too - commandline nm-tool and
nm-connection-editor sorts that with default networkmanger service in
Slack.

Nick
-- 
"Gosh that takes me back... or is it forward?  That's the trouble with
time travel, you never can tell."
-- Doctor Who "Androids of Tara"

Re: [dev] Just discovered dwm

[Nick Warne]

On Wed, 21 Sep 2016 11:27:40 -0400
Greg Reagle <greg.rea...@umbc.edu> wrote:

> Speaking of just discovering dwm, I started using it several months
> ago, and I have found that the systray patch for dwm [1] or the
> stalonetray program [2] are very useful for showing my volume
> control, dropbox status, and network icon.
> 
> [1] http://dwm.suckless.org/patches/systray
> [2] http://stalonetray.sourceforge.net/

Actually, re-replying to this, I use gkrellm as a monitor - that works
in dwm just fine, so I can run in it's own TAG :)

Nick
-- 
"Gosh that takes me back... or is it forward?  That's the trouble with
time travel, you never can tell."
-- Doctor Who "Androids of Tara"

[dev] dwm systray diff for 6.1 fails.

[Nick Warne]

Hi all,

Was going to use this to monitor battery, but HUNK #10 fails - looking
at the patch and dwm.c, the code is totally different at around line
664:

Hunk #7 succeeded at 292.
Hunk #8 succeeded at 516.
Hunk #9 succeeded at 566.
Hunk #10 FAILED at 664.
Hunk #11 succeeded at 744 (offset -5 lines).
Hunk #12 succeeded at 798 (offset -5 lines).

All other HUNKS 1->33 apply nicely.

Nick
-- 
"Gosh that takes me back... or is it forward?  That's the trouble with
time travel, you never can tell."
-- Doctor Who "Androids of Tara"

Re: [dev] Just discovered dwm

[Nick Warne]

Hi Greg,

On Wed, 21 Sep 2016 11:27:40 -0400
Greg Reagle <greg.rea...@umbc.edu> wrote:

> Speaking of just discovering dwm, I started using it several months
> ago, and I have found that the systray patch for dwm [1] or the
> stalonetray program [2] are very useful for showing my volume
> control, dropbox status, and network icon.
> 
> [1] http://dwm.suckless.org/patches/systray
> [2] http://stalonetray.sourceforge.net/
> 

Thanks, may look at those sometime, but at the moment I control all
sound/brightness etc. through my own apci stuff via functions keys.
netwrok doesn't worry me either, Slackware just seems to work.  If I do
need to change wireless, then a quick fire up into xfce4 will sort that
out.

One little thing I do miss though is scrolling with mouse wheel (or
using the pad side edge) to scroll a web page etc.

Is that doable?

Thanks

Nick
-- 
"Gosh that takes me back... or is it forward?  That's the trouble with
time travel, you never can tell."
-- Doctor Who "Androids of Tara"

[dev] Just discovered dwm

[Nick Warne]

Hi all,

I stumbled on dwm over the weekend after reading several threads abount
the systemd crap - what a great bit of kit dwm is. Running Dillo (latest
mercurial version) and claws-mail (latest git version) on Slackware
14.1, my little notebook flies - to boot up (with a BIOS password) and
on the Internet with Dillo in 38 seconds is, as youngsters say today
"wicked!".

Many thanks for something brilliant.

Nick
-- 
"Gosh that takes me back... or is it forward?  That's the trouble with
time travel, you never can tell."
-- Doctor Who "Androids of Tara"

Re: [dev] Shell style guide

[Nick]

Quoth Evan Gates:
> On Thu, Sep 8, 2016 at 5:44 AM, Nick <suckless-...@njw.me.uk> wrote:
> > I think this is something one learns with time. There are several
> > good reasons not to quote substitutions, such as passing multiple
> > arguments to another program (e.g. cmd $@), or a for or case
> > statement. But yes, quoting is essential most of the time.  Shell
> > escaping sucks, though, obviously. Another reason to keep bourne
> > shell very simple.
> 
> No. $@ is another example of something that _must_ be quoted every
> time. When inside quotes the shell expands it correctly to a word for
> each parameter. Without quotes the shell will do extra word splitting
> and globbing. For example, try this:
> 
> nargs() { echo "$#"; }
> set -- foo 'bar baz'
> echo "$#"
> nargs "$@"
> nargs $@

Ah, my bad, I did not know that, thanks. I thought that passing "$@" 
would just pass the contents of $@ as one string. And there I was 
considering myself well-versed on the ways of shell.

> When in a case statement should you not quote? I can't think of any examples.

Me neither. Ignore me :p

> I'm opposed to this. If you want convert, write convert. If you want
> gm convert, write gm convert. If you want to be able to change it
> everywhere in your script at once, put it in a function. Functions
> exist for exactly this reason. (That was strongly worded. If you write
> code that won't break, that's fine, but putting commands in variables
> obfuscates the code.)

How does it obfuscate the code to have "$convert a.png a.tif" versus 
"convert a.png a.tif" (where convert has been (re)defined as a 
function earlier in the script)? The former makes clear that you're 
just using the command in the convert variable, the latter does not.

> > I disagree. GNU ls may be, but it isn't supposed to be that way.
> > Something like `ls -tr | tail -n 1` seems perfectly reasonable to
> > me, for example. Sure you could use find, but for some cases ls is
> > simpler.
> 
> Simpler maybe, but incorrect. Filenames can contain newlines
> (filenames can contain everything but a / and a nul byte).

I am against writing scripts that can deal with filenames with 
newlines. Fuck such filenames. If you have to deal with them, shell 
scripting is a terrible technology to use.

Re: [dev] Shell style guide

[Nick]

Hi Evan, I agree with most of your thoughts, I'll just add my own 
where they differ.

> Shebang: Use #!/bin/sh and only use POSIX shell features. If you need
> bash features use the proper shebang, either #!/path/to/bash or
> #!/usr/bin/env bash

No suckless project should be using bash. If you need the 
complexity, use rc or something else more fit for the job.

> Quoting: Quote all expansions/substitutions. e.g. always use "$foo"
> and never use $foo. There are an extremely small number of acceptable
> reasons to break this rule, e.g. $CFLAGS (note that some parts of the
> grammar do not require quotes for safe expansion such as assignment
> and case $var in, we should discuss what to require in these cases)

I think this is something one learns with time. There are several 
good reasons not to quote substitutions, such as passing multiple 
arguments to another program (e.g. cmd $@), or a for or case 
statement. But yes, quoting is essential most of the time.  Shell 
escaping sucks, though, obviously. Another reason to keep bourne 
shell very simple.

> Storing Commands: Do not store commands in strings. This is what
> functions are for. Storing complex commands in strings and trying 
> to execute or eval them is fragile and needlessly complex.

I actually never use functions in shell scripts; I consider any 
script that needs them too complex to use shell. I wouldn't be 
opposed to storing a command name in a string, though, say to store 
something along the lines of 'convert' vs 'gm convert'.

> Command Substitution: Always use "$()", never use backticks. This
> makes for easier nesting and fewer surprises. Remember these should
> always be quoted.

I prefer backticks, because nesting commands is a terrible idea in 
shell scripts. Keep intermediate output in other variables, if you 
need to. But if I see nested commands in a shell script there's a 
high chance I'll rewrite it, if I'm likely to need to actually use / 
maintain it.

> Checking exit status: Do not run a command and then check against $?.
> This is pointless. Instead check the exit status directly withif
> cmd; then or by using a boolean operator such ascmd && ...

Generally yes, but there can be times when it's clearer to have the 
test in a separate statement, for example if the command is long and 
complex.

> Do not parse ls: ls is a tool to view files in a human readable
> format. Most often when someone tries to use the output of ls they
> really just wanted a glob anyway.

I disagree. GNU ls may be, but it isn't supposed to be that way.  
Something like `ls -tr | tail -n 1` seems perfectly reasonable to 
me, for example. Sure you could use find, but for some cases ls is 
simpler.

> Test: Do not use parens or boolean operators inside test expressions.
> They are deprecated and useless. Instead of [ "$a" = foo -a "$b" = bar
> ] use [ "$a" = foo ] && [ "$b" = bar ]

Yep. I actually prefer just using the test command rather than [ / 
], as I find it clearer, rather than some pseudo-syntactical sugar.  
But definitely eschewing boolean operators from test is sensible.

> Echo and printf: Do not use echo if your input includes a variable or
> backslash. There is no safe way to do so. Use printf and %s instead.

Agreed. I'd furthermore say that the first argument of printf should 
always be single-quoted, to ensure no unexpected substitutions can 
occur.

Nick

Re: [dev] Sane office alternative?

[Nick]

Quoth Kevin Michael Frick: 
> what do you use to communicate with the part of the world (a majority,
> unfortunately) who uses suckish formats such as .doc(x), .od[tspg] or
> whatever?

LibreOffice actually isn't that bad nowadays, for interacting with 
these formats. I use pandoc for reading things which are not too 
insane, but for random "open this shitty thing" LO works fast and 
has good input / output filters to every format you'll encounter. I 
treat it like firefox; a necessary evil that I keep around for when 
I need it, that often surprises me at how well it handles monstrous 
tasks.

Re: [dev] [discussion] Cooperation between terminal and graphical programs

[Nick]

Quoth Jochen Sprickerhof: 
> * Marc Collin  [2016-06-25 10:48]:
> > Is there any way to get this behavior on standard Linux with suckless
> > tools (dwm, st, etc)?
> 
> http://dwm.suckless.org/patches/swallow

Cool, I hadn't seen that, thanks for the link!

This has indeed been discussed on the mailing list before, if you 
really want to trawl the archives to find it (I don't).

Re: [dev] Re: Linux distros that don't suck too too much

[Nick]

Thanks for the replies folks.

I would love to give OpenBSD a try, but the laptop I'm getting is rather
new and fancy, and I suspect not all of it would be supported. Plus it's
a new ecosystem and I don't have the time to learn it all at the moment
(this is my work machine, too). I'll have to learn my way around it in
qemu sometime soon. Same for 9front, now I think of it.

I'm glad to hear Gentoo is more solid these days.

Kamil, your point about security updates is a good one, though at the
moment running Debian stable doesn't feel particularly secure to me
(using surf on the system-supplied webkit, which has many known
vulnerabilities, because I haven't yet had the heart to build it for
myself, and in general running various oldish software from Debian which
almost certainly has known holes that haven't been marked as
security-sensitive and fixed in Debian). But yes, that, plus the desire
to not have to switch distributions because one or two peoples'
priorities have changed, makes me wary of going for a small distro.

Devuan I had not heard of. Sounds nice, and the dyne people seem to be
very good people, but I wonder whether it suffers the problems above of
being scarily small. Maybe not, if they mostly just use Debian's repos,
I don't know. parazyd, any comment on that?

Anyway, thanks for all the thoughts, I'm currently leaning towards
Gentoo or Debian/Devuan (I am secretly conservative and boring at
times), but who knows where I'll end up.

Love to you all.

Nick

[dev] Linux distros that don't suck too too much

[Nick]

Hi folks,

A few nights ago my too-expensive laptop met with too-cheap wine and now
it is a far-too-expensive brick. As it's therefore time for me to
install a new OS on a new laptop, I was wondering what people would
recommend. I've been using Debian Stable for years now, which while it
sucks does work well enough that I don't have to think about it very
much, so I can do more interesting things with my time. But particularly
after reading a few good articles about issues with debian [0] [1] I
find myself wondering if there's a better option out there. A rolling
release distribution would be fine with me, but only if it didn't break
often at all; I enjoyed using Gentoo years ago when I was a student, but
keeping it working took a lot of time that I do not want to dedicate to
keeping a working system these days. I'd like to try something like
morpheus [2], but I suspect that would take quite a lot of time and
energy to get going and maintain.

Any suggestions / thoughts?

Nick

0. https://mjg59.dreamwidth.org/41085.html
1.
https://blogs.gnome.org/mcatanzaro/2016/02/01/on-webkit-security-updates/
2. http://morpheus.2f30.org

Re: [dev] [svmidi][PATCH] Prevent 'stuck' MIDI notes

[Nick]

Quoth Johnny Oskarsson: 
> I hope it is okay to continue sending send patches regarding svmidi to
> the suckless mailing list. If not, I will send future patches directly
> to Henrique.

FWIW I'm enjoying reading the discussion and patches on the list.

Re: [dev] Re: [surf] Switching to webkit2 as default

[Nick]

Quoth Charles Lehner:
> I agree. The discussion of security also got me thinking that surf 
> should probably do something about HTTPS certificate verification.
> 
> From the article:
> 
> > Old versions of Epiphany and Midori load pages even if certificate 
> > verification fails; the verification result is only used to change the 
> > status of a security indicator, basically giving up your session 
> > cookies to attackers.
> 
> I did a quick test visiting some sites with invalid certificates: 
> surf-webkit1 and surf-webkit2 load them without any notice. So I am 
> currently vulnerable to MitM attacks when using surf.

You can set strictssl to TRUE in config.h to fix this behaviour (at 
least with the webkit1 surf; haven't looked at the webkit2 one yet).

Re: [dev] [surf] Switching to webkit2 as default

[Nick]

Quoth FRIGN:
> On Fri, 5 Feb 2016 11:52:54 +0100
> Markus Teich <markus.te...@stusta.mhn.de> wrote:
> > You don't have to build CEF yourself, you can just use the
> > binaries provided by google if you trust them.

That's good to know, thanks, I may play with it. It is important to 
me that I can rebuild everything on my system, but for working on 
development stuff using the google binaries would be useful given 
the tough build requirements, (which I'd have to ship off to some 
server somewhere).

> Given the low-level graphical stuff, we "may" have to look into
> OpenGL.

Which would have the additional advantage of working natively in
wayland, which I know isn't that interesting these days, but still a
nice thing to support.

Nick

[dev] [surf] Switching to webkit2 as default

[Nick]

Greetings fellow travellers.

I try not to keep too abreast of things like GTK and WebKit, for the 
sake of my sanity, but I read this[0] today which was a pretty scary 
read, really.

One thing that is particularly important is that webkitgtk2 is 
receiving security updates, whereas webkitgtk1 is not, and hasn't 
for quite a while. I was not aware of this. Web browsing is a 
dangerous thing, and I didn't realise quite how many known 
vulnerabilities I have been surfing with, and would like to reduce 
that number.

I know there's a webkitgtk2 branch of surf. Is there anything 
missing in it that would prevent it from being the default surf 
branch? I'll gladly help bring things up to scratch if there is work 
to do, as surf is a reasonable interface and I dislike it much less 
than other browsers (except my pandoc / markdown / tkread setup, but 
that's not very general-purpose, only really fit to read longform 
articles).

Love and kisses,

Nick

0.  https://blogs.gnome.org/mcatanzaro/2016/02/01/on-webkit-security-updates/

Re: [dev] [slock] chown to root:root on install?

[Nick]

Hi folks,

Quoth Markus Teich:
> Nick wrote:
> > Ideally slock should always be owned by the root user, so that it can 
> > disable
> > the oom lock. I wonder what the right solution is here, as obviously one 
> > can't
> > chown a file to be owned by root if one isn't root oneself.
> > 
> > One option would be to add a line like this to the install rule of the
> > makefile:
> > 
> > @chown root:root ${DESTDIR}${PREFIX}/bin/slock || echo "Could not chown
> > root:root ${DESTDIR}${PREFIX}/bin/slock; please do this manually"
> > 
> > Or else add a note to the readme that the make install rule should be run as
> > root. I am not in the habit of installing software outside of $HOME, so I
> > don't tend to think about elevating to root to install software, so this
> > initially confused me.
> 
> I think the echo on chown fail is a good solution. If no one has a better 
> idea,
> I'll fix that later today.

I had forgotten about this until today, but the above fix still 
hasn't been applied to the Makefile, and I think it should be.

Nick

[dev]

[Nick Raienko]

unsubscribe

Re: [dev] [sent] 0.1 release

[Nick]

Quoth hiro:
> >> presentations suck.
> >> and this shit here is worse than powerpoint cause i can't display it
> >> on someone else's computer.
> >
> > You can, even on Mac OS X and Windows. Sent should work there as well
> > using XQuartz and other goodies.
> 
> Some people don't like to have shit of dubious quality installed on
> their machines by me. They trust me enough to open a powerpoint, but
> not enough to exercise crazy wizard hacker skills in crazy hacker
> terminal.

Indeed, there are times where you can't connect your own equipment 
to a projector, and it's reasonable for other people to not want you 
to install stuff on their computer (and in the case of MacOSX or 
Windows, installing quite a bit of stuff to get to the point of 
being able to compile and run sent).

I propose some masochist makes a little sent -> html convertor (with 
a light sprinkling of javascript to advance to the next slide with 
one keypress). It wouldn't be hard, but it also wouldn't be very 
satisfying. But it would be useful.

Re: [dev] sent-0.1 or libxft bug

[Nick]

Quoth ret set:
> > At least describe in one sentence what you mean.
> Segmentation fault in in sent-0.1.

Christoph is right, you really should have provided more description 
of what the fault is, how to reproduce it, and what you think was 
causing it.

But regardless, as far as I can see this is fixed in the latest code 
in git, aa713a8a342ec0e6eca173cd4489834f8baa0a86.

Re: [dev] paste@

[Nick]

Quoth FRIGN:
> On Tue, 03 Nov 2015 22:42:16 +0100
> Christoph Lohmann <2...@r-36.net> wrote:
> 
> > the web has grown to be a big pastebin of URIs and short‐living content.
> > One good example for this are paste services which don’t guarantee  any‐
> > thing.  I came to the idea of having a paste mailinglist: All history is
> > stored, nothing will vanish and it’s easy to reference to pastes in his‐
> > tory.
> > 
> > What do you think of that idea?
> 
> This is a very nice idea! I'd implement it and allow later access via
> hashes (like
> paste.suckless.org/e6a92ec2fe5fba022c31c32c97ea455cee4b2736). This
> would make sense, as identical pastes would just be stored in the same
> place (it happens often that people paste the same stuff and it would
> also be a direct way to be able to check if the paste hasn't lost
> integrity along the way).

All sounds like a really nice idea to me.

Nick

Re: [dev] A chance for a suckless web?

[Nick]

Quoth tauto...@gmail.com: 
> I have considered making a reader mode in surf, and having a sort of 
> automatic mode for going into reader mode to make it more of a default.

I did that, but not with an automatic reader mode thing. Haven't 
updated it for a while, but it should still just work most of the 
time.

https://njw.name/simplyread

Instructions for installing in surf are in INSTALL.

I haven't used it personally much lately, as I don't generally have 
javascript enabled. I'd like to set surf to allow script.js even 
when other javascript is disabled, but never got around to doing 
that.

Re: [dev] A chance for a suckless web?

[Nick]

Quoth hiro:
> I approve of Ben's comment. I read a lot of web articles on my
> e-reader these days. This way I waste less time in front of shitty web
> browsers (on immobile supercomputers) and have something consuming to
> do on the go.

I recently got an e-reader and thought I should do something 
similar. I was planning to write a couple of scripts to process 
things - how do you do it? Just pass webpages through pandoc and 
save them into a folder to rsync to the device?

Re: [dev] [slock] Ctrl+Alt+Backspace Xorg Termination works

[Nick]

Quoth Mattias Andrée:
> You could write a wrapper that use setxkbmap
> to remove the terminate-option, and restore
> it when slock exits.

Wouldn't it make sense to add this functionality directly to slock?

Re: [dev] [slock] chown to root:root on install?

[Nick]

Quoth Dimitris Papastamos:
> On Tue, Sep 08, 2015 at 02:30:39PM +0100, Nick wrote:
> > Separately to this, slock seems to exit (without prompt) after about 
> > 0.3s after I run it, unless I move the mouse or hit the keyboard 
> > directly after starting it. Has anyone else seen this? I could look 
> > into it more, but wonder if I am perhaps being stupid?
> 
> Please provide a backtrace.

I looked into it a bit more, and it turns out it is exiting with 
status 1; I double-checked and indeed it is returning from the 
"nothing to protect" condition.

Re: [dev] [slock] chown to root:root on install?

[Nick]

Quoth Dimitris Papastamos:
> On Tue, Sep 08, 2015 at 02:44:26PM +0100, Nick wrote:
> > Quoth Dimitris Papastamos:
> > > On Tue, Sep 08, 2015 at 02:30:39PM +0100, Nick wrote:
> > > > Separately to this, slock seems to exit (without prompt) after about 
> > > > 0.3s after I run it, unless I move the mouse or hit the keyboard 
> > > > directly after starting it. Has anyone else seen this? I could look 
> > > > into it more, but wonder if I am perhaps being stupid?
> > > 
> > > Please provide a backtrace.
> > 
> > I looked into it a bit more, and it turns out it is exiting with 
> > status 1; I double-checked and indeed it is returning from the 
> > "nothing to protect" condition.
> 
> I am not sure why, can you try to increase the timeout in the two
> loops that grab the pointer/keyboard inside lockscreen()?
> 
> I suspect len is 0 and lock is set to NULL.

Indeed, increasing the timeout for the pointer grab to 1 makes 
it work properly for me. Increasing the timeout for the keyboard 
lock however just increased the time before it exited with status 1 
and returned to the terminal.

[dev] [slock] chown to root:root on install?

[Nick]

Hi folks,

I just installed slock, and found that it couldn't disable the 
out-of-memory killer for itself, so wouldn't run (presumably it 
would have failed later through not being able to read the shadow 
file, too). This was because I installed it in a directory in my 
$HOME using "make install" rather than as root with "sudo make 
install", so it was owned by my user.  As such the setuid bit didn't 
mean its privileges were heightened to the root user.

Ideally slock should always be owned by the root user, so that it 
can disable the oom lock. I wonder what the right solution is here, 
as obviously one can't chown a file to be owned by root if one isn't 
root oneself.

One option would be to add a line like this to the install rule of 
the makefile:

@chown root:root ${DESTDIR}${PREFIX}/bin/slock || echo "Could not chown 
root:root ${DESTDIR}${PREFIX}/bin/slock; please do this manually"

Or else add a note to the readme that the make install rule should 
be run as root. I am not in the habit of installing software outside 
of $HOME, so I don't tend to think about elevating to root to 
install software, so this initially confused me.

Separately to this, slock seems to exit (without prompt) after about 
0.3s after I run it, unless I move the mouse or hit the keyboard 
directly after starting it. Has anyone else seen this? I could look 
into it more, but wonder if I am perhaps being stupid?

Nick

Re: [dev] [slock] chown to root:root on install?

[Nick]

Quoth Nick:
> Quoth Dimitris Papastamos:
> > On Tue, Sep 08, 2015 at 02:30:39PM +0100, Nick wrote:
> > > Separately to this, slock seems to exit (without prompt) after about 
> > > 0.3s after I run it, unless I move the mouse or hit the keyboard 
> > > directly after starting it. Has anyone else seen this? I could look 
> > > into it more, but wonder if I am perhaps being stupid?
> > 
> > Please provide a backtrace.
> 
> I looked into it a bit more, and it turns out it is exiting with 
> status 1; I double-checked and indeed it is returning from the 
> "nothing to protect" condition.

But note that the screen does blank for a moment before it exits, so 
it seems that this is incorrect (not to mention the fact that I do, 
in fact, have a screen...)

Re: [dev] MIT/BSD licensed ELF linker?

[Nick]

Quoth Anselm R Garbe:
  The concern I have is not about compiling, but about _statically_
  linking and distributing binaries that contain mixed license .o's.
 
 I checked with the FSF on this topic and they confirmed that it is
 fine to distribute statically linked _binaries_ under the terms of GPL
 in case that the source consists of mixed GPL and GPL-compatible
 licenses[0] (like MIT/X). So, I will just publish such binaries under
 the terms of GPL.

I'm glad that is the case. I have no problems complying with the 
GPL, and I can't imagine many others do either.

 There are cases though, where a GPL-incompatible license like the
 OpenSSL license (also used by libressl) might come into play. In such

Happily the OpenSSL license issue should go away soon, as they're 
working on relicensing to Apache 2.0:  
https://www.openssl.org/blog/blog/2015/08/01/cla/

Nick

Re: [dev] [st] Viewing images in terminal with w3m

[Nick]

Quoth Ivan Tham:
 On Thu, Jun 11, 2015 at 10:00:58PM -0700, Eric Pruitt wrote:
 On Fri, Jun 12, 2015 at 12:52:29PM +0800, Ivan Tham wrote:
 There was a patch in mainline to support viewing images in st, but it
 was removed; refer to c0a56ef4be2a0f84360f41b2d45964e7ef297746 and
 c2026a495097a7e3bcfe4b58e1b9e393433cf150. I can't find the thread in the
 message archives.
 Do you know any reason why it was removed?
 It's mentioned in the second commit message. See also:
 http://lists.suckless.org/dev/1304/15283.html .
 
 Thanks, now I know why it doesn't work. It is the fault of w3m. Thanks.

If it's functionality you would find useful, take it as 
encouragement to learn your way around the w3mimg code to improve it 
and make it able to work well with st.

Re: [dev] new mailinglist [news] and hackers repurpose

[Nick]

 2.)  The  purpose  of  hackers@  has been redefined that new 
 patches for projects have to be sent and discussed there.
 
 These  changes  will  keep  the  development  out of the endless support
 threads on dev@ and development more enjoyable.

Sounds great to me, thanks for this, I've subscribed to hackers@ now.

Hope it helps to keep you sane.

Re: [dev] RSS

[Nick]

Quoth Jochen Sprickerhof: 
 I had the same thoughts last week and implemented my own rss2maildir
 script.
 ...
 I've implemented a prototype in Python (yes, I know) and would happily
 share it, if someone is interested.

Make it so!

[dev] [slock] [PATCH] Option to not show failure color on clear

[Nick Currier]

Hello,

This patch adds the failonclear boolean option so that, when false,
the failure color will not appear until a failed login attempt has
been made.
It also maintains the existing behaviour (failure on clear) by default.

Thanks,
hexid
From b5fa0f2cabf03ae3d09a29b8fb5327109ec2e0e0 Mon Sep 17 00:00:00 2001
From: hexid nick.curr...@gmail.com
Date: Fri, 17 Apr 2015 11:09:02 -0600
Subject: [PATCH] Add config option to only show error color if after a
 failed login attempt

---
 config.def.h |  3 ++-
 slock.c  | 20 +++-
 2 files changed, 17 insertions(+), 6 deletions(-)

diff --git a/config.def.h b/config.def.h
index 4bccb5d..3ae2e6e 100644
--- a/config.def.h
+++ b/config.def.h
@@ -1,5 +1,6 @@
 static const char *colorname[NUMCOLS] = {
 	black, /* after initialization */
 	#005577,   /* during input */
 	#CC,   /* failed/cleared the input */
 };
+static const Bool failonclear = True;
diff --git a/slock.c b/slock.c
index 6502c86..8a12cde 100644
--- a/slock.c
+++ b/slock.c
@@ -26,7 +26,7 @@
 enum {
 	INIT,
 	INPUT,
-	EMPTY,
+	FAILED,
 	NUMCOLS
 };
 
@@ -42,6 +42,7 @@ typedef struct {
 static Lock **locks;
 static int nscreens;
 static Bool running = True;
+static Bool failure = False;
 static Bool rr;
 static int rrevbase;
 static int rrerrbase;
@@ -153,8 +154,10 @@ readpw(Display *dpy, const char *pws)
 #else
 running = !!strcmp(crypt(passwd, pws), pws);
 #endif
-if (running)
+if (running) {
 	XBell(dpy, 100);
+	failure = True;
+}
 len = 0;
 break;
 			case XK_Escape:
@@ -177,9 +180,16 @@ readpw(Display *dpy, const char *pws)
 	XClearWindow(dpy, locks[screen]-win);
 }
 			} else if (llen != 0  len == 0) {
-for (screen = 0; screen  nscreens; screen++) {
-	XSetWindowBackground(dpy, locks[screen]-win, locks[screen]-colors[EMPTY]);
-	XClearWindow(dpy, locks[screen]-win);
+if (failure || failonclear) {
+	for (screen = 0; screen  nscreens; screen++) {
+		XSetWindowBackground(dpy, locks[screen]-win, locks[screen]-colors[FAILED]);
+		XClearWindow(dpy, locks[screen]-win);
+	}
+} else {
+	for (screen = 0; screen  nscreens; screen++) {
+		XSetWindowBackground(dpy, locks[screen]-win, locks[screen]-colors[INIT]);
+		XClearWindow(dpy, locks[screen]-win);
+	}
 }
 			}
 			llen = len;
-- 
2.3.5

Re: [dev] [slock] [PATCH] Option to not show failure color on clear

[Nick Currier]

On Wed, May 6, 2015 at 9:20 AM, Markus Teich markus.te...@stusta.mhn.de wrote:
 I think the new behaviour actually is a more reasonable default.

I had talked to both sin and dsp about this and they thought it best
to keep the existing behaviour.
However, it's easy enough to change if the consensus is to change the default.

 locks[screen]-colors[failure || failonclear ?  FAILED : INIT]

I've made this change and attached the updated patch.

Thanks,
hexid
From e7faddb33b183e966bc2858d146ab9ba78695377 Mon Sep 17 00:00:00 2001
From: hexid nick.curr...@gmail.com
Date: Wed, 6 May 2015 09:34:59 -0600
Subject: [PATCH] Add config option to only show error color after a
 failed login attempt

---
 config.def.h | 1 +
 slock.c  | 9 ++---
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/config.def.h b/config.def.h
index 4bccb5d..fca0ae0 100644
--- a/config.def.h
+++ b/config.def.h
@@ -3,3 +3,4 @@ static const char *colorname[NUMCOLS] = {
 	#005577,   /* during input */
 	#CC,   /* failed/cleared the input */
 };
+static const Bool failonclear = True;
diff --git a/slock.c b/slock.c
index 6502c86..1551a9e 100644
--- a/slock.c
+++ b/slock.c
@@ -26,7 +26,7 @@
 enum {
 	INIT,
 	INPUT,
-	EMPTY,
+	FAILED,
 	NUMCOLS
 };
 
@@ -42,6 +42,7 @@ typedef struct {
 static Lock **locks;
 static int nscreens;
 static Bool running = True;
+static Bool failure = False;
 static Bool rr;
 static int rrevbase;
 static int rrerrbase;
@@ -153,8 +154,10 @@ readpw(Display *dpy, const char *pws)
 #else
 running = !!strcmp(crypt(passwd, pws), pws);
 #endif
-if (running)
+if (running) {
 	XBell(dpy, 100);
+	failure = True;
+}
 len = 0;
 break;
 			case XK_Escape:
@@ -178,7 +181,7 @@ readpw(Display *dpy, const char *pws)
 }
 			} else if (llen != 0  len == 0) {
 for (screen = 0; screen  nscreens; screen++) {
-	XSetWindowBackground(dpy, locks[screen]-win, locks[screen]-colors[EMPTY]);
+	XSetWindowBackground(dpy, locks[screen]-win, locks[screen]-colors[failure || failonclear ? FAILED : INIT]);
 	XClearWindow(dpy, locks[screen]-win);
 }
 			}
-- 
2.3.7

Re: [dev] [vis][RFC][PATCH 1/2] Replace first '/' of substitute command with \0

[Nick]

Quoth Silvan Jegen:
 What I am doing with this tag is expressing my good intentions.

Good intentions are assumed for all the patches here, which is 
reasonable and right. If some lawsuit came about (which it won't) 
the norms of behaviour on the list should trump any git tags.

Re: [dev] [sbase] [PATCH] join manpage: Fix spelling

[Nick]

Quoth Wolfgang Corcoran-Mathe:
 '-eth' might sound good to a native English speaker

It doesn't ;) Good patch.

Re: [dev] aijuboard

[Nick]

Hi aiju,

Quoth Julius Schmidt:
 I am currently collecting funds for a production run of a Zynq based
 board built specifically with Plan 9 in mind. It has a dual-core ARM
 CPU and a Xilinx FPGA. We are running 9front, but labs and 9atom
 would likely work fine too.

That sounds cool. To ask a very naive question, why do you need a 
FPGA to offload the Plan 9 drawing operations? Why couldn't you just 
use a regular GPU? Or are there other plans for the FPGA? If so, 
what sort of thing are you envisioning? Is the CPU the bottleneck 
for lots of things Plan 9 users tend to do (I don't use Plan 9), 
such that it could be relieved by offloading to a FPGA? Also, I 
thought GPUs could be used for more than just graphical stuff 
nowadays, or is that either not general enough or not applicable for 
a little board like yours?

Nick

Re: [dev] Miscellaneous sbase issues

[Nick]

Quoth Dimitris Papastamos: 
 Some things that need to be done for tar:
 
 ...
 - Strip leading / from filenames and dangerous things like ../../ etc.

OK, attached is a patch that does that. I think it covers all the 
bases.
From b5acf1e9254080c2f283c623f59e412cdb29939a Mon Sep 17 00:00:00 2001
From: Nick White g...@njw.name
Date: Mon, 27 Apr 2015 12:25:44 +0100
Subject: [PATCH] Strip dangerous path traversal stuff from paths

Specifically, this removes '../' from anywhere in a path, and any
number of '/' at the start of a path
---
 tar.c |   22 ++
 1 file changed, 22 insertions(+)

diff --git a/tar.c b/tar.c
index b1f3b27..0bd3fcf 100644
--- a/tar.c
+++ b/tar.c
@@ -359,6 +359,27 @@ sanitize(struct header *h)
 }
 
 static void
+sanitizepath(char *p)
+{
+	size_t l;
+	char *s;
+
+	/* Strip leading '/' characters */
+	while(*p == '/') {
+		l = strlen(p);
+		memmove(p, p+1, l - 1);
+		*(p + l - 1) = '\0';
+	}
+
+	/* Strip '../' from anywhere */
+	while((s = strstr(p, ../)) != NULL) {
+		l = strlen(s);
+		memmove(s, s + 3, l - 3);
+		*(s + l - 3) = '\0';
+	}
+}
+
+static void
 chktar(struct header *h)
 {
 	char tmp[8], *err;
@@ -407,6 +428,7 @@ xt(int argc, char *argv[], int (*fn)(char *, ssize_t, char[BLKSIZ]))
 			 (int)sizeof(h-prefix), h-prefix);
 		snprintf(fname + n, sizeof(fname) - n, %.*s,
 		 (int)sizeof(h-name), h-name);
+		sanitizepath(fname);
 
 		if ((size = strtol(h-size, p, 8))  0 || *p != '\0')
 			eprintf(strtol %s: invalid number\n, h-size);
-- 
1.7.10.4

Re: [dev] [surf] Patch to print ssl error reasons to stderr

[Nick]

I had forgotten about this patch, but it is a useful one and I 
reckon it should be applied (or rebuked, if appropriate). It still 
applies fine against the current tip (with fuzz).

Quoth Nick:
 Quoth Markus Teich: 
   I recently wrote a patch that printed useful debug info about SSL 
   failures,
   but it got lost when mailman went down and I haven't re-sent it yet. I'll 
   try
   to remember to send it to the list tonight.
  
  That could be very helpful. I'm looking forward to it.
 
 It's attached. It was against the trunk a week or so ago, but 
 probably still applies ;)
 
 Incidentally, does anyone have any thoughts about the best ways to 
 display this sort of extra status information? stderr is fine in a 
 pinch, but in general I don't run my surf sessions from a terminal 
 so most of the time it'd be non-trivial to fetch the output.
 
 Oh, and note I'm not sure whether it'll print the ssl failure output 
 if you have sslstrict on - I haven't tested but it may well abort 
 the connection before surf gets a hold of it.
 
 Nick

 From cfe99acb2382bf9b141042e406bce654e4b9a8be Mon Sep 17 00:00:00 2001
 From: Nick White g...@njw.me.uk
 Date: Mon, 3 Feb 2014 17:02:43 +
 Subject: [PATCH] Print certificate errors on stderr
 
 ---
  surf.c |   43 +++
  1 file changed, 43 insertions(+)
 
 diff --git a/surf.c b/surf.c
 index e967672..14de226 100644
 --- a/surf.c
 +++ b/surf.c
 @@ -69,6 +69,21 @@ typedef struct {
   SoupCookieJarTextClass parent_class;
  } CookieJarClass;
  
 +typedef struct {
 + int flag;
 + char *errstr;
 +} TlsError;
 +
 +static TlsError tlserrors[] = {
 + { G_TLS_CERTIFICATE_UNKNOWN_CA, The signing certificate authority is 
 not known. },
 + { G_TLS_CERTIFICATE_BAD_IDENTITY, The certificate does not match the 
 expected identity of the site that it was retrieved from. },
 + { G_TLS_CERTIFICATE_NOT_ACTIVATED, The certificate's activation time 
 is still in the future. },
 + { G_TLS_CERTIFICATE_EXPIRED, The certificate has expired. },
 + { G_TLS_CERTIFICATE_REVOKED, The certificate has been revoked. },
 + { G_TLS_CERTIFICATE_INSECURE, The certificate's algorithm is 
 considered insecure. },
 + { G_TLS_CERTIFICATE_GENERIC_ERROR, A general error occurred validating 
 the certificate. },
 +};
 +
  G_DEFINE_TYPE(CookieJar, cookiejar, SOUP_TYPE_COOKIE_JAR_TEXT)
  
  static Display *dpy;
 @@ -630,7 +645,13 @@ loadstatuschange(WebKitWebView *view, GParamSpec *pspec, 
 Client *c) {
   WebKitWebDataSource *src;
   WebKitNetworkRequest *request;
   SoupMessage *msg;
 + SoupSession *session;
 + GTlsCertificate *cert;
 + GTlsCertificateFlags flags;
   char *uri;
 + char *cut_uri;
 + char *s;
 + int i;
  
   switch(webkit_web_view_get_load_status (c-view)) {
   case WEBKIT_LOAD_COMMITTED:
 @@ -642,6 +663,28 @@ loadstatuschange(WebKitWebView *view, GParamSpec *pspec, 
 Client *c) {
   msg = webkit_network_request_get_message(request);
   c-sslfailed = !(soup_message_get_flags(msg)
SOUP_MESSAGE_CERTIFICATE_TRUSTED);
 + if(c-sslfailed) {
 + /* For some reason the https status can't be 
 got from webkit's soup msg,
 +  * so we make a dummy connection to the 
 server's homepage here. */
 + cut_uri = g_strdup(uri);
 + s = cut_uri;
 + for (i = 0; i  3; ++i) {
 + s = strchr((s[1]), '/');
 + }
 + s[1] = '\0';
 + msg = soup_message_new(HEAD, uri);
 + soup_message_set_flags(msg, 
 SOUP_MESSAGE_NO_REDIRECT);
 + session = webkit_get_default_session();
 + soup_session_send_message(session, msg);
 +
 + soup_message_get_https_status(msg, cert, 
 flags);
 +
 + for(i = 0; i  LENGTH(tlserrors); i++) {
 + if(flags  tlserrors[i].flag) {
 + fprintf(stderr, %s - %s\n, 
 uri, tlserrors[i].errstr);
 + }
 + }
 + }
   }
   setatom(c, AtomUri, uri);
   break;
 -- 
 1.7.10.4
 



signature.asc
Description: Digital signature

Re: [dev] surf -- how to manage SSL certificates?

[Nick]

Quoth Jakukyo Friel: 
 Just tried with the latest commit (b4ca032),
 surf does not warn about invalid SSL certs.

It totally does. Visit https://njw.me.uk and see the U in the SSL 
section of the status bar, and compare to the T for 
https://njw.name.

 Change `static char *strictssl` to true and rebuild,
 still no effects.

Also not true; I get a SSL handshake error if strictssl is true.

You just reminded me an old patch I made for surf that gave more 
information on SSL failures was never merged - I'll ping it through 
again shortly.


signature.asc
Description: Digital signature

Re: [dev] Miscellaneous sbase issues

[Nick]

Quoth Nick:
 Quoth Dimitris Papastamos: 
  Some things that need to be done for tar:
  
  ...
  - Strip leading / from filenames and dangerous things like ../../ etc.
 
 OK, attached is a patch that does that. I think it covers all the 
 bases.

One thing the patch doesn't cover is an archive using a symlink to 
somewhere like ../../ and then putting a file in symlink/newfile 
(hence sending it to ../../newfile). I only thought of that when 
reading the bsdtar manpage[0].

I'm not sure what the best behaviour is in that case. Some options:

1) If a symlink creates a path ascending further up the directory 
tree (towards /) than the current directory, replace all symlinks in 
the path with directories and extract there.

2) Remove the symlink and replace it with a real directory before 
extracting the file into it (this is the behaviour of bsdtar with 
the -U option)

3) Refuse to create any file following a symlink (this is the 
default behaviour of bsdtar)

4) Issue a warning if writing a file, but follow the symlink as 
instructed

If you're curious about how bsdtar does it, look at check_symlinks() 
in libarchive/archive_write_disk_posix.c, but note the comment at 
the top of the function - TODO: Make this work.

I have a slight preference for option 1, but it doesn't feel 
particularly clean. Anyone else have better ideas? I know it's 
annoying, but I don't think ignore it is good enough, as it would 
be far too easy to create a tarball that blatted any file the user 
had access to using this method (and using -t to check paths 
wouldn't help, as the ../ is in the symlink target). I'm attaching a 
tarball that demonstrates the problem, in case I haven't explained 
it well enough. If you used $HOME/bin/, and unpacked the tarball in 
$HOME/tmp, it will create a file in $HOME/bin/myscript.

Nick

0. 
https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/bsdtar.1.html


test.tar
Description: Unix tar archive


signature.asc
Description: Digital signature

Re: [dev] making releases

[Nick]

Quoth Dimitris Papastamos:
 Use upstream dmenu, port the patches if they do not already work and
 submit them to the wiki.
 
 Packaging suckless software is useless.

I know several people here (who do more good work than me) think 
that, but I disagree. I like not upgrading my software particularly 
often if it doesn't have any bugs I care about in it, so I find it 
easier to have some releases every so often, when I think oh, I'll 
upgrade that now, and spend a few minutes reading through the git 
log and updating my config.h / st.info.

Arguably that's my problem, rather than something that should be 
fixed by adding the occasional vX.X tag, but still...