suckless-tools: FTBFS on hurd-i386
Source: suckless-tools Version: 38 Severity: important Tags: patch User: debian-hurd@lists.debian.org Usertags: hurd Hi, This patch solves the build problems for GNU/Hurd due to PATH_MAX issues. The solution is to make dynamic string allocations instead of using fixed length buffers. The patch involves one file, and is trivial. TODO: Should the "whole package" be tested with valgrind on GNU/Linux?! If yes, is there a standard procedure to do it?! Thanks! (Not submitted yet, comments are welcome.) fix_FTBFS4Hurd.patch Description: Binary data
Re: suckless-tools-38 hurd patch (PATH_MAX)
Hi 2012/1/31 Jérémie Koenig : > The patch looks good, you should submit it. Thanks, I'll do that! question: first I submit it to this list as "draft" and then what? For instance, the memstat patch I sent few days ago hasn't been commented for days... what is the next step? Cheers, Tanguy -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cajbrmlbuajxhr6odt4rm-vcf4c-t0o36vz+7yndyz7z2cec...@mail.gmail.com
Re: suckless-tools-38 hurd patch (PATH_MAX)
Hi Tanguy, On Tue, Jan 31, 2012 at 2:13 PM, Tanguy LE CARROUR wrote: > Another (small) one if some of you guys have time to review some code. The patch looks good, you should submit it. -- Jérémie Koenig http://jk.fr.eu.org/ -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CA+kCSAbgn3e8G_VuqW70WbUbuCjs0a4ZqM0k=+rstsw8xkj...@mail.gmail.com
Re: Thoughts on MAXPATHLEN
On Tue, Jan 31, 2012 at 12:57 PM, Justus Winter wrote: > Well, fixing fixed-sized buffer issues is a good exercise to improve > ones c skills, but I do not see how it helps anyone to get a foot into > the Hurd project if he fixed a bug in e.g. nautilus or tar. A social foot maybe, but otherwise I agree. > Fixing real problems related to Hurd, gnumach, mig, the documentation > and Debian or Arch integration and packaging is much more helpful for > both Hurd users and the project itself. Right. For what it's worth, I'm personnaly agnostic with regards to defining PATH_MAX on Hurd. -- Jérémie Koenig http://jk.fr.eu.org/ -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ca+kcsaa6g4svzjvftgg7sgpsxgc+k4rqiak3moxjajljx1f...@mail.gmail.com
suckless-tools-38 hurd patch (PATH_MAX)
Hi!
Another (small) one if some of you guys have time to review some code.
Cheers,
Tanguy
--- old/suckless-tools-38/dmenu/dmenu_path.c2012-01-31 13:02:23.226833682
+0100
+++ suckless-tools-38/dmenu/dmenu_path.c2012-01-31 14:01:10.282784329
+0100
@@ -46,7 +46,9 @@
void
scan(void) {
- char buf[PATH_MAX];
+ char *buf = NULL;
+ char *new_buf = NULL;
+ size_t buf_size = 0;
char *dir, *p;
size_t i, count;
struct dirent *ent;
@@ -60,6 +62,13 @@
if(!(dp = opendir(dir)))
continue;
while((ent = readdir(dp))) {
+ buf_size = strlen(dir)+strlen(ent->d_name)+2;
+ if(!buf || strlen(buf) < buf_size) {
+ new_buf = realloc(buf, buf_size);
+ if(!new_buf)
+ die("realloc failed");
+ buf = new_buf;
+ }
snprintf(buf, sizeof buf, "%s/%s", dir, ent->d_name);
if(ent->d_name[0] == '.' || access(buf, X_OK) < 0)
continue;
@@ -68,6 +77,7 @@
if(!(items[count-1] = strdup(ent->d_name)))
die("strdup failed");
}
+ free(buf);
closedir(dp);
}
qsort(items, count, sizeof *items, qstrcmp);
suckless-tools.hurd.patch
Description: Binary data
Re: BIG FAT WARNING (sysvinit)
Hi, (a proper subject would have helped a bit more...) Alle martedì 31 gennaio 2012, Svante Signell ha scritto: > Be careful not to upgrade to initscripts 2.88dsf-21 or 2.88dsf-22 > is you want to play safe. In particular, any version of sysvinit >= 2.88dsf-19 during the migration from /dev/initctl to /run/initclt causes a SIGUSR1 to be sent to the process with PID 1, which for us is /hurd/init. (This uncover an old gotha with kill(), which allows base system processes to be killed.) The affected packages are all the ones of the sysvinit source, i.e.: sysvinit sysvinit-utils sysv-rc initscripts bootlogd A solution for this is already being investigated with Roger Leigh. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Re: BIG FAT WARNING
On Tue, 2012-01-31 at 13:29 +0100, Richard Braun wrote: > On Tue, Jan 31, 2012 at 01:06:02PM +0100, Svante Signell wrote: > > Be careful not to upgrade to initscripts 2.88dsf-21 or 2.88dsf-22 is > > you want to play safe. They can cause your filesystem to be heavily > > trashed, at least it did for me (on two kvm instances, twice on one of > > them!): > > What's your system setup (RAM & swap size mostly) ? > > I didn't have any issue with my VMs (2 GiB RAM, 1 or 2 of swap). 1GiB RAM, 1 GiB swap. I'm suspecting it can be some hardware error on the host, like RAM! -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1328013704.3525.346.ca...@hp.my.own.domain
Re: BIG FAT WARNING
On Tue, Jan 31, 2012 at 01:06:02PM +0100, Svante Signell wrote: > Be careful not to upgrade to initscripts 2.88dsf-21 or 2.88dsf-22 is > you want to play safe. They can cause your filesystem to be heavily > trashed, at least it did for me (on two kvm instances, twice on one of > them!): What's your system setup (RAM & swap size mostly) ? I didn't have any issue with my VMs (2 GiB RAM, 1 or 2 of swap). -- Richard Braun -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120131122945.ga15...@mail.sceen.net
Re: Thoughts on MAXPATHLEN
Quoting Richard Braun (2012-01-31 09:59:58) >On Sun, Jan 29, 2012 at 11:31:58AM -, Justus Winter wrote: >> 1. File bugs for software that uses MAXPATHLEN and co, do so politely >>and explain the issues. Talk directly to upstream and *do not* >>mention the Hurd. > >Without mentioning there is at least a system out there on which the >issue is present, upstream will probably just ignore the request. My point was that there is a system that has those issues, and that system is Linux (and Hurd, and probably all of the BSDs too). >> 2. Define MAXPATHLEN and work on more important issues. > >Why not do both ? Fixing those issues is a good way to get a first foot >in the project. Well, fixing fixed-sized buffer issues is a good exercise to improve ones c skills, but I do not see how it helps anyone to get a foot into the Hurd project if he fixed a bug in e.g. nautilus or tar. Fixing real problems related to Hurd, gnumach, mig, the documentation and Debian or Arch integration and packaging is much more helpful for both Hurd users and the project itself. Justus -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120131115702.23430.64...@thinkbox.jade-hamburg.de
BIG FAT WARNING
Be careful not to upgrade to initscripts 2.88dsf-21 or 2.88dsf-22 is you want to play safe. They can cause your filesystem to be heavily trashed, at least it did for me (on two kvm instances, twice on one of them!): In an ssh window: (second time, first with -21!) Preparing to replace sysvinit 2.88dsf-21 (using .../sysvinit_2.88dsf-22_hurd-i386.deb) ... Unpacking replacement sysvinit ... Processing triggers for man-db ... Setting up sysvinit (2.88dsf-22) ... sysvinit: creating /run/initctl sysvinit: restarting...init: timeout opening/writing control channel /run/initctl .init: timeout opening/writing control channel /run/initctl .init: timeout opening/writing control channel /run/initctl .init: timeout opening/writing control channel /run/initctl .init: timeout opening/writing control channel /run/initctl .init: timeout opening/writing control channel /run/initctl . init: timeout opening/writing control channel /run/initctl .init: timeout opening/writing control channel /run/initctl failed. (Reading database ... 5% ... On the console: (repeating forever until the kvm process is killed) /etc/hurd/runsystem.gnu: line 162: 24115 Killed $(SHELL) -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1328011562.3525.344.ca...@hp.my.own.domain
Re: Thoughts on MAXPATHLEN
On Sun, Jan 29, 2012 at 11:31:58AM -, Justus Winter wrote: > 1. File bugs for software that uses MAXPATHLEN and co, do so politely >and explain the issues. Talk directly to upstream and *do not* >mention the Hurd. Without mentioning there is at least a system out there on which the issue is present, upstream will probably just ignore the request. > 2. Define MAXPATHLEN and work on more important issues. Why not do both ? Fixing those issues is a good way to get a first foot in the project. -- Richard Braun -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120131085958.ga9...@mail.sceen.net
Re: Bug#652575: rsyslog: /etc/init.d/rsyslog modifications for GNU/Hurd
Michael Biebl, le Tue 31 Jan 2012 07:54:24 +0100, a écrit : > I'd like to get rid of arch specific code in the init script and instead > move the pipe to /run/xconsole and create a symlink in /dev for > backwards compat with existing tools. > > Would this work on hurd? It should work. > (the alternative is to drop xconsole support completely. The value of > that is questionable anyway) I'm using it everyday on my desktop. Samuel -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120131084100.gv13...@type.famille.thibault.fr
