Re: [Nix-dev] pthread
Vladimír Čunát vcu...@gmail.com writes: On 01/31/2014 02:38 PM, Marco Maggesi wrote: Which derivation contains pthread? Is it in gcc? libpthread is part of glibc (and is pthread.h) You don't need to add anything. I think just specifying -pthread or -lpthread when linking does the thing. Yes, but the app probably already does that. The error might be completely unrelated to pthread itself, might be just the first test where it tries to run a compiler and something goes awry. Petr -- id' Ash = Ash; id' Dust = Dust; id' _ = undefined ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Maintainership
Thomas Bereknyei tombe...@gmail.com writes: That almost sounds like an unstable channel. Unstable and unmaintained are two very different things. Rather than removing unmaintained packages, can we make them available as a separate, opt-in channel? I'd say that is an option, but if the unmaintained pile contains important software and basically everybody needs to enable it, we are not much better off -- we'll still get a lot of breakage every time we update the system and even up-to-date systems will likely sport many vulnerabilities. Not everyone is happy to rely on security by obscurity of NixOS, and if it becomes more widespread it could become an easy attack target. I imagine that non-NixOS installations of nixpkgs have a different set of trade-offs though. -- id' Ash = Ash; id' Dust = Dust; id' _ = undefined ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Maintainership
Jan Malakhovski o...@oxij.org writes: * First, this remove unmaintained policy discourages adding new packages to the public nixpkgs by users that are unable to maintain stuff. In the example above, I would better store the package in my own branch than risk it being unexpectedly removed. This would probably imply duplication of work in case somebody else will want to have it at some later point. I wouldn't search all the nixpkgs' forks for a possibility that somebody already has an expression for this package. It is a trade-off. Broken packages can be more overhead than duplication of work. If you make a package that works for you, push it to nixpkgs and abandon it, the next person will find it broken for his purpose, fix it and in the process break it for you. You will both spend time debugging the package. If one of the two users was a maintainer, the other could come to him and they can figure out something that works for both. If there is no maintainer and you update once in a while, you can end up ping-ponging fixes and counterfixes. I would rather drop this remove unmaintained altogether, at least for current requirements for being a maintainer (especially about the timely fashion). Marking unmaintained (or even better: unmaintained and potentially exploitable (which I would define as: it's a daemon or some other package uses it)) packages broken and notifying contributors about this fact looks okay. Even things that are marked as broken involve cognitive overhead when working on nixpkgs. They clutter up the source, often use outdated idioms, they hold up or complicate changes in support code. It's like a closet, it's hard to get at the things you actually use when it's full of junk. As for exploitable, that's an extremely conservative approach you suggest. I'm wondering if a remote code execution vulnerability in your browser or e-mail client is of no concern to you. :-) Or a PDF reader? Flash plugin? There have been countless security breaches due to bugs in non-daemon, leaf packages. Petr -- id' Ash = Ash; id' Dust = Dust; id' _ = undefined ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Maintainership
Michael Raskin 7c6f4...@mail.ru writes: Somehow, whenever updates of packages I care about were broken, it was a simple mistake that was easy to fix separately… I think this scenario is overly pessimistic. Well, depends on your point of view. If you only care about a few packages for your personal use, it's one thing, when you deploy an installation with twenty users it's entirely different. You run into the need to fix packages that you don't personally use or aren't very familiar with, and even if you figure out a fix, it is unlikely to be entirely correct. Being able to consult someone who understands both nix(os) *and* the package in question in a timely fashion would make fixing such problems much easier, and even somewhat less likely to be required. In general, one can expect that the amount of time maintainers spend on their packages will not change too much whatever policy change you propose. There are some packages that I want to have installed but don't care about versions, so the question is not whether I will maintain them well but whether I will keep them in configurations/ or nixpkgs/. Well, I expect that if the tools make it easy to see whom to contact about a particular package, maintainers will see more engagement from their users. That alone can work to make them more active, and can give them valuable feedback/new knowledge about how the package is/can be used. It also makes it less likely they break use-cases in the future if they are familiar with them. Of course, having nix-env or somesuch list maintainers, and making it possible to file issues with individual packages (as opposed to just making a generic issue in github) would help with those things as well. Petr -- id' Ash = Ash; id' Dust = Dust; id' _ = undefined ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Maintainership
Hi, I agree with basically everything said, and I think breaking packages with no maintainers (after the next stable branch-off, 14.0x?) would be really good to make it obvious what is broken and is a candidate for removal. It would also give people a chance to adopt a package they use before it is removed. Shea Levy s...@shealevy.com writes: * If a change elsewhere breaks a maintained package in a non-obvious way, the maintainers should make a reasonable effort to fix the breakage in a timely fashion I'd say that maintainers of things (packages) with reverse dependencies should also try to help out their dependees when they do bumps likely to break downstream packages. At least by scheduling such bumps at times when they are going to be available for consulting, if nothing else. Petr -- id' Ash = Ash; id' Dust = Dust; id' _ = undefined ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Improving the Developer Experience in the Nix Community
Hi folks, Shea Levy s...@shealevy.com writes: That's why I opened this thread, because we have people with different values but no one is really coming out and saying this is what I want, this is why what's here now is bad. I am more or less a bystander and not really active, but this caught my attention (and the thread above). Above all, the main reason I am not active is that it seems that submitting patches is a hit-or-miss affair. They tend to get blackholed about as often as not. So I don't submit any: I just locally fork any package that I need to change, and in addition I keep a number of extra packages that way; basically, I maintain a private overlay in /etc/nixos. Now if there was a simple and documented way to submit patches (*especially* new packages) that would actually work, it would probably make my life easier, even as a bystander, by reducing the size of the overlay significantly. Btw., I am planning a not entirely small deployment of NixOS later this week, so I would really like to hear something positive about sustainability. (Well, there's still time to call it off and stick to Debian, although I do like NixOS more on general principles.) Yours, Petr -- id' Ash = Ash; id' Dust = Dust; id' _ = undefined ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] development/libraries too large
Hi, Yury G. Kudryashov urkud.ur...@gmail.com writes: Probably we should drop the tree structure (reduce the number of categories?) and replace it by search tags + tools to query these tags. I tend to agree, and I think it would be prudent to at least have a look at debtags. Lot of effort went into this one, and although it's not optimal, it's probably going to be pretty hard to come up with something better. Not everything directly applies to NixOS, but it shouldn't be a far cry either. (What I primarily mean is the list of facets and tags, and probably the package - tag data which I imagine could be semi-automatically transferred.) Petr -- id' Ash = Ash; id' Dust = Dust; id' _ = undefined ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] wicd managing wireless network
Hi,
rocon...@theorem.ca writes:
Why isn't wpa_supplicant.conf managed by NixOS?
Because it contains passwords.
Ah, I see.
For the record, I keep a /etc/nixos/wpa-supplicant.nix which I require
from configuration.nix and that says environment.etc = [ {
source = pkgs.writeText wpa_supplicant.conf ''
...
'';
target = wpa_supplicant.conf;
} ];
(plus the requisite boilerplate, stolen from hardware-configuration.nix)
The advantage is that I don't need to think about wpa_supplicant.conf
when cloning my configuration, which I tend to do between two
laptops. (I keep /etc/nixos in version control, so I can push and pull
changes around conveniently...)
Yours,
Petr
--
id' Ash = Ash; id' Dust = Dust; id' _ = undefined
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] [PATCH] Add a package with DICT-formatted wiktionary.
Hi,
the attached patch builds a dictd-compatible package that contains a
local copy of the (English) wiktionary data, built from the official
wikimedia dumps (http://dumps.wikimedia.org).
Petr
Index: pkgs/servers/dict/wiktionary2dict.py
===
--- pkgs/servers/dict/wiktionary2dict.py (revision 0)
+++ pkgs/servers/dict/wiktionary2dict.py (working copy)
@@ -0,0 +1,778 @@
+# Adapted to produce DICT-compatible files by Petr Rockai in 2012
+# Based on code from wiktiondict by Greg Hewgill
+import re
+import sys
+import codecs
+import os
+import textwrap
+import time
+import xml.sax
+
+class Text:
+def __init__(self, s):
+self.s = s
+def process(self):
+return s
+
+class TemplateCall:
+def __init__(self):
+pass
+def process(self):
+pass
+
+class Template:
+def __init__(self):
+self.parts = []
+def append(self, part):
+self.parts.append(part)
+def process(self):
+return ''.join(x.process() for x in self.parts)
+
+class Whitespace:
+def __init__(self, s):
+self.s = s
+
+class OpenDouble: pass
+class OpenTriple: pass
+class CloseDouble: pass
+class CloseTriple: pass
+
+class Equals:
+def __str__(self):
+return =
+
+class Delimiter:
+def __init__(self, c):
+self.c = c
+def __str__(self):
+return self.c
+
+def Tokenise(s):
+s = unicode(s)
+stack = []
+last = 0
+i = 0
+while i len(s):
+if s[i] == '{' and i+1 len(s) and s[i+1] == '{':
+if i last:
+yield s[last:i]
+if i+2 len(s) and s[i+2] == '{':
+yield OpenTriple()
+stack.append(3)
+i += 3
+else:
+yield OpenDouble()
+stack.append(2)
+i += 2
+last = i
+elif s[i] == '}' and i+1 len(s) and s[i+1] == '}':
+if i last:
+yield s[last:i]
+if len(stack) == 0:
+yield }}
+i += 2
+elif stack[-1] == 2:
+yield CloseDouble()
+i += 2
+stack.pop()
+elif i+2 len(s) and s[i+2] == '}':
+yield CloseTriple()
+i += 3
+stack.pop()
+else:
+raise SyntaxError()
+last = i
+elif s[i] == ':' or s[i] == '|':
+if i last:
+yield s[last:i]
+yield Delimiter(s[i])
+i += 1
+last = i
+elif s[i] == '=':
+if i last:
+yield s[last:i]
+yield Equals()
+i += 1
+last = i
+#elif s[i] == ' ' or s[i] == '\t' or s[i] == '\n':
+#if i last:
+#yield s[last:i]
+#last = i
+#m = re.match(r\s+, s[i:])
+#assert m
+#yield Whitespace(m.group(0))
+#i += len(m.group(0))
+#last = i
+else:
+i += 1
+if i last:
+yield s[last:i]
+
+def processSub(templates, tokens, args):
+t = tokens.next()
+if not isinstance(t, unicode):
+raise SyntaxError
+name = t
+t = tokens.next()
+default = None
+if isinstance(t, Delimiter) and t.c == '|':
+default =
+while True:
+t = tokens.next()
+if isinstance(t, unicode):
+default += t
+elif isinstance(t, OpenDouble):
+default += processTemplateCall(templates, tokens, args)
+elif isinstance(t, OpenTriple):
+default += processSub(templates, tokens, args)
+elif isinstance(t, CloseTriple):
+break
+else:
+print Unexpected:, t
+raise SyntaxError()
+if name in args:
+return args[name]
+if default is not None:
+return default
+if name == lang:
+return en
+return {{{%s}}} % name
+
+def processTemplateCall(templates, tokens, args):
+template = tokens.next().strip().lower()
+args = {}
+a = 1
+t = tokens.next()
+while True:
+if isinstance(t, Delimiter):
+name = unicode(a)
+arg =
+while True:
+t = tokens.next()
+if isinstance(t, unicode):
+arg += t
+elif isinstance(t, OpenDouble):
+arg += processTemplateCall(templates, tokens, args)
+elif isinstance(t, OpenTriple):
+arg += processSub(templates, tokens, args)
+elif isinstance(t, Delimiter) and t.c != '|':
+arg += str(t)
+else:
+break
+if isinstance(t, Equals):
+name = arg.strip()
+arg =
+while True
[Nix-dev] [PATCH] Add a package with dictd-compatible copy of wordnet.
Hi,
the attached patch makes it possible to install wordnet data as a dictd
dictionary.
Petr
Index: pkgs/applications/misc/wordnet/dictd.nix
===
--- pkgs/applications/misc/wordnet/dictd.nix (revision 0)
+++ pkgs/applications/misc/wordnet/dictd.nix (working copy)
@@ -0,0 +1,37 @@
+{stdenv, fetchsvn, python, wordnet}:
+
+stdenv.mkDerivation rec {
+ version = 542;
+ name = dict-db-wordnet-${version};
+ src = fetchsvn {
+url = http://svn.memespace.net/svn/hobby/trivialities/wordnet_tools;;
+sha256 = 32477cf239540d8910e2745a16ce0fbd0bc47368b04415ae0b255af12c83a5f2;
+ };
+
+ buildInputs = [python wordnet];
+
+ installPhase = ''
+ensureDir $out/share/dictd/
+srcdir=`pwd`
+cd $out/share/dictd
+for i in ${wordnet}/dict/data.*; do
+ DATA=$DATA `echo $i | sed -e s,data,index,` $i;
+done
+python $srcdir/wordnet_structures.py $DATA
+echo en_US.UTF-8 locale
+ '';
+
+ meta = {
+description = dictd-compatible version of WordNet;
+
+longDescription =
+ '' WordNet® is a large lexical database of English. This package makes
+ the wordnet data available to dictd and by extension for lookup with
+ the dict command. '';
+
+homepage = http://wordnet.princeton.edu/;
+
+maintainers = [ stdenv.lib.maintainers.mornfall ];
+platforms = stdenv.lib.platforms.gnu; # arbitrary choice
+ };
+}
--
id' Ash = Ash; id' Dust = Dust; id' _ = undefined
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] [PATCH] Update dictd to current upstream (1.12.0).
Hi,
the attached patch updates the DICT.org software, with some resistance,
to the current upstream releases. The current nixpkgs version of dictfmt
tends to SEGV on big complicated dictionaries.
Petr
Index: pkgs/servers/dict/libmaa.nix
===
--- pkgs/servers/dict/libmaa.nix (revision 0)
+++ pkgs/servers/dict/libmaa.nix (working copy)
@@ -0,0 +1,16 @@
+{ stdenv, fetchurl, libtool }:
+
+stdenv.mkDerivation rec {
+ name = libmaa-1.3.1;
+
+ src = fetchurl {
+url = mirror://sourceforge/dict/${name}.tar.gz;
+sha256 = 0xzhypadhh2nc266gilmddd47vibnvyb4s86znwsi89y6dvi0h2k;
+ };
+
+ buildInputs = [ libtool ];
+
+ meta = {
+description = libmaa from dict.org;
+ };
+}
Index: pkgs/servers/dict/default.nix
===
--- pkgs/servers/dict/default.nix (revision 31261)
+++ pkgs/servers/dict/default.nix (working copy)
@@ -1,16 +1,20 @@
-{ stdenv, fetchurl, which, bison, flex }:
+{ stdenv, fetchurl, which, bison, flex, makeWrapper, libmaa, zlib, libtool }:
-stdenv.mkDerivation {
- name = dictd-1.9.15;
+stdenv.mkDerivation rec {
+ name = dictd-1.12.0;
src = fetchurl {
-url = mirror://sourceforge/dict/dictd-1.9.15.tar.gz;
-sha256 = 0p41yf72l0igmshz6vxy3hm51z25600vrnb9j2jpgws4c03fqnac;
+url = mirror://sourceforge/dict/${name}.tar.gz;
+sha256 = 18m4yhz5mdbpyjvl5cb6iz270zsdlzz8dshp6v7qiq26kk927i2y;
};
- buildInputs = [ flex bison which ];
+ buildInputs = [ flex bison which makeWrapper libmaa zlib libtool ];
+ patches = [ ./buildfixes.diff ];
- configureFlags = --datadir=/var/run/current-system/share/dictd;
+ configureFlags = --datadir=/var/run/current-system/share/dictd --with-system-utf8;
+ postInstall = ''
+wrapProgram $out/bin/dict --add-flags -c --add-flags /etc/dict.conf
+ '';
meta = {
description = Dict protocol server and client;
Index: pkgs/servers/dict/buildfixes.diff
===
--- pkgs/servers/dict/buildfixes.diff (revision 0)
+++ pkgs/servers/dict/buildfixes.diff (working copy)
@@ -0,0 +1,146 @@
+diff -ru dictd-1.12.0/dictfmt.c dictd-1.12.0.my/dictfmt.c
+--- dictd-1.12.0/dictfmt.c 2011-01-08 16:43:30.0 +0100
dictd-1.12.0.my/dictfmt.c 2012-01-03 22:13:55.0 +0100
+@@ -123,7 +123,7 @@
+ return -1;
+
+ default:
+- width = wcwidth__ (wchar);
++ width = wcwidth (wchar);
+ if (-1 == width)
+ width = 1; /* we also count non-printable characters */
+
+diff -ru dictd-1.12.0/Makefile.in dictd-1.12.0.my/Makefile.in
+--- dictd-1.12.0/Makefile.in 2011-01-09 20:34:55.0 +0100
dictd-1.12.0.my/Makefile.in 2012-01-03 22:12:41.0 +0100
+@@ -72,7 +72,7 @@
+ LIBMAA= @LIBMAA@
+ LIBS= @LIBS@ ${LIBMAA}
+ LDFLAGS=@LDFLAGS@
+-LIBOBJS=@LIBOBJS@
++LIBOBJS=$(subst .o,.lo,@LIBOBJS@)
+ EXES= dict dictd dictzip dictfmt
+
+ all: $(EXES) $(LIBRARIES)
+@@ -103,60 +103,60 @@
+ endif
+
+ ifdef USE_PLUGIN
+-SRCHOBJS= index.o data.o str.o plugin.o #dictdplugin.o
++SRCHOBJS= index.lo data.lo str.lo plugin.lo #dictdplugin.o
+ else
+-SRCHOBJS= index.o data.o str.o #dictdplugin.o
++SRCHOBJS= index.lo data.lo str.lo #dictdplugin.o
+ endif
+
+-NETOBJS=daemon.o strategy.o net.o servscan.o servparse.o md5.o
+-CLIOBJS=net.o clientscan.o clientparse.o md5.o
++NETOBJS=daemon.lo strategy.lo net.lo servscan.lo servparse.lo md5.lo
++CLIOBJS=net.lo clientscan.lo clientparse.lo md5.lo
+
+ TMPS= servscan.c servparse.c servparse.h \
+ clientscan.c clientparse.c clientparse.h
+
+ @SET_MAKE@
+
+-%.o: %.c
++%.lo: %.c
+ $(LIBTOOL) --tag=CC --mode=compile $(CC) -c $(CFLAGS) $ -o $@
+-%.o: %.cpp
++%.lo: %.cpp
+ $(LIBTOOL) --tag=CXX --mode=compile $(CXX) -c $(CFLAGS) $ -o $@
+
+-%: %.o
++%: %.lo
+ $(LIBTOOL) --tag=CC --mode=link $(CC) -o $@ -static \
+ $^ $(OBJS) $(LDFLAGS) -lz ${LIBS}
+
+ include $(srcdir)/deps
+
+-dictd.o : servparse.h
++dictd.lo : servparse.h
+
+ $(PLUGINS) dictdplugin_popen.la dictdplugin_exit.la : $(LIBOBJS)
+ # libdictdplugin.a
+
+-lib%.a : %.o
++lib%.a : .libs/%.o
+ $(AR) rc $@ $^
+
+-%.la : %.o $(LIBOBJS)
++%.la : %.lo $(LIBOBJS)
+ $(LIBTOOL) --tag=CC --mode=link $(CC) -o $@ -module \
+ $(^:.o=.lo) \
+ -rpath ${PLUGIN_DIR} \
+ $(LDFLAGS) ${LIBS}
+
+-dictdplugin_man.la : data.o str.o heap.o dictdplugin_man.o \
+- plugins_common.o $(LIBOBJS)
++dictdplugin_man.la : data.lo str.lo heap.lo dictdplugin_man.lo \
++ plugins_common.lo $(LIBOBJS)
+ $(LIBTOOL) --tag=CC --mode=link $(CC) -o $@ -module \
+ $(^:.o=.lo) \
+ -rpath ${PLUGIN_DIR} \
+ $(LDFLAGS) ${LIBS}
+
+-dictdplugin_judy.la : data.o str.o heap.o dictdplugin_judy.o \
+- plugins_common.o $(LIBOBJS)
++dictdplugin_judy.la : data.lo str.lo heap.lo dictdplugin_judy.lo \
++
Re: [Nix-dev] [PATCH] Weaken an overzealous sanity check on udev rules...
Shea Levy s...@shealevy.com writes: Hi Petr, On 12/4/11 8:52 PM, Petr Rockai wrote: Hi, the below patch is needed to build a configuration that includes recent SANE (scanner drivers) udev rules which mention RUN+=/path/to/script in a comment (which breaks the check). Yours, Petr Can you give an example udev rule that is currently rejected but shouldn't be? # bla bla RUN+=/path/to/script bla bla (I.e., the file is rejected based on a comment, not an actual rule.) Petr -- id' Ash = Ash; id' Dust = Dust; id' _ = undefined ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
