[dev] dmenu tip build error
Hi, it seems that the commit 484:0b6490d9a62b remove _POSIX_C_SOURCE cflag broke the build on at least Fedora 16. The following patch fixes it on Fedora 16. I haven't tested it on anything else. diff -r 1659395e4de0 stest.c --- a/stest.c Thu Jan 19 22:52:17 2012 + +++ b/stest.c Wed Jan 25 10:39:21 2012 +0100 @@ -6,6 +6,7 @@ #include string.h #include unistd.h #include sys/stat.h +#include getopt.h #define FLAG(x) (flag[(x)-'a'])
Re: [dev] dmenu tip build error
Hey, On 25 January 2012 09:40, Carsten Mattner carstenmatt...@googlemail.com wrote: it seems that the commit 484:0b6490d9a62b remove _POSIX_C_SOURCE cflag broke the build on at least Fedora 16. The following patch fixes it on Fedora 16. I haven't tested it on anything else. I think that patch is GNU-specific. The problem is that using -D_POSIX_C_SOURCE=2 was breaking builds on FreeBSD, and apparently not having it at all breaks builds on Fedora. So we need to find out which _POSIX_C_SOURCE value works on both BSD and GNU. Ugh. Thanks, cls
Re: [dev] dmenu tip build error
On 01/25/12 12:26, Connor Lane Smith wrote: I think that patch is GNU-specific. The problem is that using -D_POSIX_C_SOURCE=2 was breaking builds on FreeBSD FWIW, my update to FreeBSD's dmenu port patches those bits, so it's probably OK if you don't worry too much about it for FreeBSD. :)
Re: [dev] dmenu tip build error
On Wed, Jan 25, 2012 at 11:52 AM, Aragon Gouveia ara...@phat.za.net wrote: On 01/25/12 12:26, Connor Lane Smith wrote: I think that patch is GNU-specific. The problem is that using -D_POSIX_C_SOURCE=2 was breaking builds on FreeBSD FWIW, my update to FreeBSD's dmenu port patches those bits, so it's probably OK if you don't worry too much about it for FreeBSD. :) It's preferable to have it build out of the box. Should be easy to find a fix without relying on autoconf to check the function, shouldn't it?
[dev] Confusion about ii's handling of JOIN messages
ii performs some strange processing around JOIN messages, which means
that they are not handled correctly (they are put in the server buffer
with 'null' channel name). The following patch fixes that, but I can't
believe the code was in there for no reason, as it seems rather
deliberate. Could someone shed some light on this?
diff -r d163c8917af7 ii.c
--- a/ii.c Mon Oct 31 21:35:12 2011 +0100
+++ b/ii.c Wed Jan 25 13:56:03 2012 +0100
@@ -347,13 +347,7 @@
} else if(!strncmp(ERROR, argv[TOK_CMD], 6))
snprintf(message, PIPE_BUF, -!- error %s, argv[TOK_TEXT] ? argv[TOK_TEXT] : unknown);
else if(!strncmp(JOIN, argv[TOK_CMD], 5)) {
- if(argv[TOK_TEXT] != NULL){
- p = strchr(argv[TOK_TEXT], ' ');
- if(p)
-*p = 0;
- }
- argv[TOK_CHAN] = argv[TOK_TEXT];
- snprintf(message, PIPE_BUF, -!- %s(%s) has joined %s, argv[TOK_NICKSRV], argv[TOK_USER], argv[TOK_TEXT]);
+ snprintf(message, PIPE_BUF, -!- %s(%s) has joined %s, argv[TOK_NICKSRV], argv[TOK_USER], argv[TOK_CHAN]);
} else if(!strncmp(PART, argv[TOK_CMD], 5)) {
snprintf(message, PIPE_BUF, -!- %s(%s) has left %s, argv[TOK_NICKSRV], argv[TOK_USER], argv[TOK_CHAN]);
} else if(!strncmp(MODE, argv[TOK_CMD], 5))
--
\ Troels
/\ Henriksen
Re: [dev] suckless vs. security? - Was: [slock] kill slock with Ctrl+Alt+Multiply
On Mon 23 Jan 2012 07:10:57 PM PST, Bjartur Thorlacius wrote: On Mon, 23 Jan 2012 11:04:55 -, Nick wrote: On Mon, Jan 23, 2012 at 11:57:42AM +0100, hiro wrote: Security is not a feature. I thought you were restricting yourself to Sundays. Yes, on Sundays ;) Ah, such comedians! I love reading this mailing list. :) -- Some of my readers ask me what a Serial Port is. The answer is: I don't know. Is it some kind of wine you have with breakfast?
Re: [dev] install dwm
On Tue, 24 Jan 2012, Michael Stummvoll wrote: On 24.01.2012 10:08, Anthony Campbell wrote: I use Debian Sid, which is similar though not identical to Ubuntu. I haven't tried to make a .deb file, which seems like an unnecessary complication. - apt-get build-dep dwm - apt-get source dwm and then, in the dwm-directory: - edit the source like you want - dpkg-buildpackage - dpkg -i ../dwm*.deb between editing the source and building the package you may want run something like 'dch local changes' to prevent your dwm gets overriden by apt with the same version in repository. This may seem blatantly obvious and unspoken -- however: it is OK to install dwm to /usr/local or $HOME on the mentioned distros. It is a lot of work to roll packages per-setup and per-user. It also seems logical to put personal binaries in a personal directory. It seems the real question here is How do I use Debian's package management facilities to install XYZ?. Suckless frowns upon this kind of question. Please see to using Debian docs next time! -- Winston Weinert
Re: [dev] Confusion about ii's handling of JOIN messages
Troels Henriksen at...@sigkill.dk wrote:
ii performs some strange processing around JOIN messages, which means
that they are not handled correctly (they are put in the server buffer
with 'null' channel name). The following patch fixes that, but I can't
believe the code was in there for no reason, as it seems rather
deliberate. Could someone shed some light on this?
Just talked to you on #suckless, but for the reast of the ML, here's the
patch that nion gave me. Not sure why it hasn't been pushed.
-emg
diff -r ff0f9af69619 -r fa797b7349f7 ii.c
--- a/ii.c Tue Nov 01 15:44:18 2011 -0700
+++ b/ii.c Mon Nov 28 01:34:26 2011 -0800
@@ -368,6 +368,9 @@
if((p = strchr(cmd, ':'))) {
*p = 0;
argv[TOK_TEXT] = ++p;
+ } else if((p = strchr(cmd, ' '))) {
+ *p = 0;
+ argv[TOK_TEXT] = ++p;
}
tokenize(argv[TOK_CMD], TOK_LAST - TOK_CMD, cmd, ' ');
Re: [dev] interested in issue tracker dev
On Fri, Jan 13, 2012 at 03:27:26PM +0100, Paul Onyschuk wrote: On Thu, 12 Jan 2012 19:34:09 +0200 aecepoglu@ wrote: I might be interested in trying to help write one such suckless issue tracker as requested on the webpage. I just want to ask; What set of features are a must for you? After reading some discussion I have some ideas. For small projects keeping TODO file in repository can work quite well. What about extending this idea? Use one of the mbox mail formats to store data: - mbox file per issue - treat first message in mbox as meta: modify and store common informations (priority, short description, category of issue and so on) there Ick. - store everything under version control system: closed/resolved issues can be moved to different branch (smaller checkout) Interesting. This way data can be accessed very easily, some usage ideas: - searching for existing issues simple as checking out repository and greping files Yay. - nice time-line provided by version control system (history of commits): when issue was updated, closed, new response was send Double yay. - advanced usage e.g. search for issues with specific priority, cat them into one file and open with your email client Excellent. I think that would make some people happy. Sounds like some good ideas to me. Use mailing list as main interface, web interface could just send messages to list. Every message would be automatically prefixed with issue ID, ID would be also used as name for mbox file. Version control system would provide some security against corruption (just rollback to previous working checkout). I'm not crazy about shoehorning issue tracking into e-mail like this, it's more complicated than it needs to be. Concentrate on simple, basic storage and functions and let someone else who cares about a web interface write one. Anyway those are just random ideas, not sure if that is the way to go. That's good for starters. Here's a simple issue tracker repository using directories, key-value text files, and symlinks: /path/to/repo/ ticket/ abc123/ +owner/ yolanda - ../../../user/yolanda properties [status, description, whatever] history [log of activity, append-only] mail/ [maildir, mh mailbox, whatever] +attachments/ hjk987 - ../../../attachment/hjk987 user/ yolanda/ +tickets/ abc123 - ../../../ticket/abc123 properties [name, e-mail address, etc.] attachment/ hjk987/ properties contents.foo [the file itself] Simple, extensible (group/*, project/*, ticket/*/+watchers, ticket/*/+parent, whatever), and if for some reason you don't want symlinks you can manage the relationships between things some other way (hard links, plain text files, whatever). Call it nfuit (non-fucked up issue tracker) and write some shell functions for convenience: nfuit_create_repository nfuit_create_repository /path/to/another/repo nfuit_create nfuit_create user/bob -name Bob -email b...@example.net nfuit_setnfuit_set user/$u -name $name -email $addr nfuit_properties nfuit_properties user/bob | while read key val; do ...; done nfuit_lognfuit_log $(nfuit_now) ticket/123 created -by bob -status open nfuit_exists if !nfuit_exists ticket/999; then ...; fi nfuit_link nfuit_link user/bob +tickets ticket/666 nfuit_unlink # obvious nfuit_links for t in $(nfuit_links user/yolanda +tickets); do ...; done nfuit_is_linked if nfuit_is_linked user/$u +tickets ticket/123; then ...; fi nfuit_lock nfuit_lock user/bob/properties nfuit_unlock nfuit_unlock user/bob/properties I've done most of this (in zsh). Then build the rest on top of this and utils like grep, find, munpack, etc. Paul. -- Paul Hoffman nkui...@nkuitse.com
Re: [dev] install dwm
On 26 January 2012 04:28, Winston Weinert winst...@lavabit.com wrote: This may seem blatantly obvious and unspoken -- however: it is OK to install dwm to /usr/local or $HOME on the mentioned distros. It is a lot of work to roll packages per-setup and per-user. It also seems logical to put personal binaries in a personal directory. Nowadays with inexpensive VPS and what not, your server is probably not a multi-user system. So there is little point in bending over backwards installing binaries in $HOME in my opinion. It seems the real question here is How do I use Debian's package management facilities to install XYZ?. Suckless frowns upon this kind of question. Please see to using Debian docs next time! You'll learn like I have, that Debian packages aren't all that. /usr/local/bin is fine and manageable. Especially since the binaries can have config.h tweaks. ls -1 /usr/local/bin/ ansi2html dmenu dmenu_run dwm markdown st stest sxiv xosview
Re: [dev] install dwm
Bending over backward: cd ~/.bin/builds/dwm make cp dwm ~/.bin; echo export PATH=$PATH:~/.bin/ ~/.bashrc
Re: [dev] install dwm
On Wed, Jan 25, 2012 at 10:31:41PM -0500, Bryan Bennett wrote: Bending over backward: cd ~/.bin/builds/dwm make cp dwm ~/.bin; echo export PATH=$PATH:~/.bin/ ~/.bashrc excuse me, I think you missed some steps. I can't find the 'cd' or 'make' or 'echo' buttons in unity.
