Re: [Nix-dev] network problems after upgrade

https://github.com/NixOS/nixpkgs/issues/12361 ? On 16/02/2016 6:15 PM, Máté Kovács wrote: Hi all, The latest `nixos-rebuild switch --upgrade` broke network connectivity. I don't use any networkmanager app, just /etc/wpa_supplicant.conf. How do I figure out what's going wrong here? Thanks,

[Nix-dev] network problems after upgrade

Hi all, The latest `nixos-rebuild switch --upgrade` broke network connectivity. I don't use any networkmanager app, just /etc/wpa_supplicant.conf. How do I figure out what's going wrong here? Thanks, Mate ___ nix-dev mailing list

[Nix-dev] problem with automounted ntfs partitions

Hi all, The problem I'm trying to solve is that automounted ntfs partitions are read-only. For example, `mount | column -t` lists /dev/sdb1 on /run/media/mate/adata type ntfs

Re: [Nix-dev] Checking rpaths for 32 bit on 64 bit

Thanks both you! I ended up just building an ldd expression but eelco's suggestion is something I did not know about and will try and use in the future if I come across the situation again. Thanks! Eelco Dolstra wrote >Hi, > >On 12/02/16 20:38, Tony wrote: > >> Does anyone know if

[Nix-dev] loading the nix-shell in a jenkins job

Hi, I've been trying to get one of my default.nix development environment build in a Jenkins job. I'm not trying to make a package but create a different artifact that will be consumed in a different way. I have this in my execute build step in a freestyle job: ``` #!/usr/bin/env nix-shell

Re: [Nix-dev] Travis Testing Needs Rethinking

14.02.2016, 21:44, "zimbatm" : > What if master was always the latest successful hydra build ? People could > rebase on top and have cached builds. Nox could also have cached builds. > > Instead of merging a PR we would instruct Hydra to queue the build. If the > build is

Re: [Nix-dev] Wiki is dead

Also we are not alone with the spam :) [22:37] alad: I forgot to ask, how do you guys fight against spam on the wiki ? [22:38] zimbatm: there was a recent spam wave, so we've restricted mediawiki API access, add a more difficult captcha, and enabled some extensions like spamregex On Mon, 15

Re: [Nix-dev] Wiki is dead

Alright, let me know how I can help. Personally I am looking forward to much more scoped discussions like how to improve a specific page. On Mon, 15 Feb 2016 at 22:30 Rok Garbas wrote: > Hi Zimbatm and Peter, > > On Mon, Feb 15, 2016 at 1:41 PM, Peter Simons

Re: [Nix-dev] Wiki is dead

Hi Zimbatm and Peter, On Mon, Feb 15, 2016 at 1:41 PM, Peter Simons wrote: > Hi Zimbatm, > > > Is the consensus really to kill the wiki or is it just because it's > > in a bad state? > > I suppose Rok is our local kill-the-wiki champion who can give you the > authoritative

Re: [Nix-dev] Are nix-shells supposed to nest?

It's surprising indeed. I would expect nix-shell to always prepend dependencies to the PATH ~ $ nix-shell -p haskell.compiler.ghc784 --run 'nix-shell -p haskell.compiler.ghc7103 --run "echo $PATH"'

Re: [Nix-dev] Dynamic substituteInPlace

It's not super clear to me what you are trying to achieve. Maybe you've zoomed into that specific solution but with more context there might be others available. Is the file compiled or is it interpreted ? I understand that you want to provide some information at runtime and resolve the path to

Re: [Nix-dev] Wiki is dead

@Peter: haha, point taken :) So I went on #archlinux and asked a few questions on their wiki (transcript below). It might seem obvious but basically it works because somebody close to the core is owning the wiki. -- [21:29] over at #nixos we are wondering how arch manages to have such an

[Nix-dev] Are nix-shells supposed to nest?

Hi folks, the Github issue #13011 [1] asks an interesting question, namely: can we nest nix-shell environments? A simple experiment suggests it's possible, but the result you get when do you it is quite surprising: $ nix-shell -p haskell.compiler.ghc784 --run 'nix-shell -p

[Nix-dev] Wiki is dead

I often find myself on the Arch wiki and porting the content to apply to my NixOS setup. Perhaps that would be a systematic way to start, consider it a port. Take some of the most commonly used Arch wiki pages and make NixOS versions. It would also establish a structure to the wiki. >But I think

Re: [Nix-dev] Debugging Symbols

On Mon, 2016-02-15 at 17:50 +0100, Eelco Dolstra wrote: > This is already supported. Just add > separateDebugInfo = true; > > to a package to get an output named "debug", with debug symbols in > lib/debug/.build-id. This also enables the -ggdb flag. > > You can then enable GDB to find these

Re: [Nix-dev] Debugging Symbols

On Mon, 2016-02-15 at 17:45 +0100, Eelco Dolstra wrote: > Hi, > > On 15/02/16 15:43, Kevin Cox wrote: > > > The solution is obviously seperate debug files > > > > l> which > > allows the debugging symbols to be kept separate from the binary > > itself. I see > > that there was an earlier

Re: [Nix-dev] Haskell Infrastructure - Nix-Shell with Hoogle from cabal2nix

Hi Andreas, > In order to create a development environment, where I have > `cabal-install` available as well, I can write the following Nix > file: [...]. why don't you just put inherently compiler-agnostic tools like cabal-install, stack, alex, happy, etc. into your user's profile or system

[Nix-dev] Redesign of documentation

Hi Nixers, Since NixCon last year UX and documentation are in the spotlight, and especially since the Wiki has gone to read-only there seems to be even more pressure to come up with a good solution to the documentation challenge. I would like to bring up a discussion on what type of

[Nix-dev] Dynamic substituteInPlace

Hello, I've got an issue I don't fully know how to solve in the simplest way. I have a file which contains something like this: 'text' -> input_port var_name_instance(a_dynamic_component_name) output_port ... etc etc a_dynamic_component_name could be a name of one of my components in a file

Re: [Nix-dev] Wiki is dead

I feel like contributing a few points in a Wiki's defense, given the general negativity towards it, but I am not on a crusade :) In general, Wikipedia/MediaWiki works because it scales massively and provides excellent tools to detect and cope with vandalism. The git workflow should scale very

Re: [Nix-dev] Debugging Symbols

Hi, On 15/02/16 15:50, Luca Bruno wrote: >> I noticed that almost all Nix packages are stripped of debugging symbols and >> was hoping to discuss a possible solution that would both keep the closure >> size minimal and allow post-hoc debugging of crashes. The small closure size >> speaks for

Re: [Nix-dev] Debugging Symbols

Hi, On 15/02/16 15:43, Kevin Cox wrote: > The solution is obviously seperate debug files > which > allows the debugging symbols to be kept separate from the binary itself. I see > that there was an earlier attempt but it

Re: [Nix-dev] Wiki is dead

> Several people have made various initiatives to help improving the wiki, > but curiously enough none of those initiatives actually improved the > *contents*. Nix contributors clearly enjoy making the wiki prettier, > writing fancy CSS configurations, rendering the stuff in sophisticated > web

Re: [Nix-dev] Debugging Symbols

On Feb 15, 2016 10:13 AM, "Adrien Devresse" wrote: > > +1 to this proposal. Thanks > > - It happens often that recompiling with debug flags change the behavior of the progrm itself and make the crash/problem impossible to reproduce with debinfos. > I would like to point out

Re: [Nix-dev] Debugging Symbols

+1 to this proposal. The current solution to recompile with a nix function is far to be a perfect solution: - It happens often that recompiling with debug flags change the behavior of the progrm itself and make the crash/problem impossible to reproduce with debinfos. - It is a pain when a

Re: [Nix-dev] Debugging Symbols

On Mon, 2016-02-15 at 15:50 +0100, Luca Bruno wrote: > >   > +1, with the multi outputs branch [1] it makes a lot of sense to ship > an additional output for debug symbols, instead of rebuilding the > program using Nix functions [2] > > [1] https://github.com/NixOS/nixpkgs/pull/7701 > [2]

Re: [Nix-dev] Debugging Symbols

On 15/02/2016 15:43, Kevin Cox wrote: > Hello all, I'm creating a bit of noise this morning. > > I noticed that almost all Nix packages are stripped of debugging > symbols and was hoping to discuss a possible solution that would both > keep the closure size minimal and allow post-hoc debugging of

[Nix-dev] Debugging Symbols

Hello all, I'm creating a bit of noise this morning. I noticed that almost all Nix packages are stripped of debugging symbols and was hoping to discuss a possible solution that would both keep the closure size minimal and allow post-hoc debugging of crashes. The small closure size speaks for

Re: [Nix-dev] Checking rpaths for 32 bit on 64 bit

Hi, On 12/02/16 20:38, Tony wrote: > Does anyone know if there is something like ldd32 in NixOS I can use to check > 32 > bit dynamic executables on a 64 bit system. "patchelf --print-rpath" and "readelf -d ... | grep RPATH" are both architecture-independent, so they should work on any ELF

Re: [Nix-dev] Wiki is dead

>From a newbie's perspective, I want to say two things: 1. From watching the "kill the wiki" presentation (as well as the later discussions), I believe it was actually meant as a provocative/dramatical (in a good way - as in "thought-provoking"/"wake-up call") way of saying "we ought to improve

Re: [Nix-dev] Wiki is dead

Hi Zimbatm, > Is the consensus really to kill the wiki or is it just because it's > in a bad state? I suppose Rok is our local kill-the-wiki champion who can give you the authoritative answer to this question, but FWIW my impression was that our Wiki is in a rather poor state. Yes, there is

Re: [Nix-dev] [erlang-questions] Erlang Package Manager

On 15 Feb 2016 14:12, "Roger Qiu" wrote: > Having all that in nixpkgs might make it quite bloated. Nix is a lazy language, nixpkgs repo size is a non-issue, save for cloning. /sjm ___ nix-dev mailing list