profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/Profpatsch/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Profpatsch Possehl Analytics Augsburg, Paris http://profpatsch.de he/him, they/them

dhall-lang/dhall-haskell 747

Maintainable configuration files

nix-community/lorri 132

Your project’s nix-env [maintainer=@Profpatsch]

justinwoo/purescript-milkis 45

A Purescript library for working with fetch for HTTP requests

Profpatsch/blog 21

My blog (shake static builder & content)

justinwoo/easy-dhall-nix 19

Derivations for easily downloading Dhall binaries and putting them to use.

cko/nixcon2017 6

Source of the NixCon 2017 website

nixcon/2015.nixcon.org 1

NixCon 2015 conference website

Profpatsch/beekeeper 1

Configuration management for beehive.

atixlabs/cardano-sl 0

Icarus, a reference implementation for a lightweight wallet developed by the IOHK Engineering Team.

Profpatsch/aarch64-build-box 0

Config for the Community aarch64 NixOS box [maintainer=@grahamc]

issue commenthaskell/cabal

Migrate from the .cabal format to a widely supported format

Thank you @TikhonJelvis for the demonstrations, this mirrors exactly the experiences I had with writing json-schema and editor completion for simple cases.

I can confirm that taplo works pretty well, I use it at work in combination with vscode. So using TOML instead of YAML is certainly possible with not too much overhead. Plus, improving taplo will improve the whole TOML ecosystem, not just cabal.

Profpatsch

comment created time in 2 days

issue commenthaskell/cabal

Migrate from the .cabal format to a widely supported format

By json schema, do you mean in-editor completion and documentation on hover when editing the configuration?

Both. vscode gives you both when you have a schema, out of the box.

Profpatsch

comment created time in 2 days

pull request commentNixOS/rfcs

[RFC 0099] Change default shell from bash to oil

* make it opt-in for people who want to use it. (keep stdenv compatible to both oil and bash, then let people pick an interpreter in their derivation). If it ends up not being popular then reverting won't be a problem. If it ends up being popular then we can put more efforts into it.

Why would people care? People want their programs to run, they don’t care which shell is used to run make/make install.

I’m sorry, but all this sounds like a maintenance nightmare to me.

happysalada

comment created time in 2 days

push eventNixOS/nixpkgs

sternenseemann

commit sha 1d67a676d4150227a057100c710984dd44470f40

inspircd: 3.10.0 -> 3.11.0 https://docs.inspircd.org/3/change-log/#inspircd-3110

view details

push time in 3 days

PR merged NixOS/nixpkgs

Reviewers
inspircd: 3.10.0 -> 3.11.0 10.rebuild-linux: 1-10 10.rebuild-darwin: 1-10 11.by: package-maintainer

https://docs.inspircd.org/3/change-log/#inspircd-3110

<!-- To help with the large amounts of pull requests, we would appreciate your reviews of other pull requests, especially simple package updates. Just leave a comment describing what you have tested in the relevant package/service. Reviewing helps to reduce the average time-to-merge for everyone. Thanks a lot if you do! List of open PRs: https://github.com/NixOS/nixpkgs/pulls Reviewing guidelines: https://nixos.org/manual/nixpkgs/unstable/#chap-reviewing-contributions -->

Motivation for this change
Things done

<!-- Please check what applies. Note that these are not hard requirements but merely serve as information for reviewers. -->

  • Built on platform(s)
    • [x] x86_64-linux
    • [ ] aarch64-linux
    • [ ] x86_64-darwin
    • [ ] aarch64-darwin
  • [ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
  • [x] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • [ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
  • [ ] Tested execution of all binary files (usually in ./result/bin/)
  • 21.11 Release Notes (or backporting 21.05 Release notes)
    • [ ] (Package updates) Added a release notes entry if the change is major or breaking
    • [ ] (Module updates) Added a release notes entry if the change is significant
    • [ ] (Module addition) Added a release notes entry if adding a new NixOS module
  • [x] Fits CONTRIBUTING.md.
+2 -2

2 comments

1 changed file

sternenseemann

pr closed time in 3 days

pull request commentNixOS/nixpkgs

inspircd: 3.10.0 -> 3.11.0

noice

sternenseemann

comment created time in 3 days

pull request commentNixOS/rfcs

[RFC 0099] Change default shell from bash to oil

I'm also nominating myself.

@edolstra are you interested in this (or something similar) happening?

happysalada

comment created time in 3 days

pull request commentNixOS/rfcs

[RFC 0100] Sign commits

One is that the expectation is that this would be the standard way of verifying trust.

I think the first step here is to define this sentence.

I don’t know what is meant by:

  • the standard way
  • verifying trust
  • trust
L-as

comment created time in 3 days

issue commentnix-community/lorri

Failed to enable unit: Unit file lorri.service does not exist.

Hi @maxdevjs, could you please run the following commands:

$ lorri info
<please paste output here>

$ uname -a
<please paste output here>
maxdevjs

comment created time in 3 days

pull request commentNixOS/rfcs

[RFC 0100] Sign commits

Thanks for explaining! iirc I’ve also seen cases where an RFC was closed because there were no shepherds that wanted to adopt it.

In this case my main problem is that it’s a policy discussion, so I’d want to see someone with the social credit in nixpkgs to push it through, should the shepherds agree it’s a good idea to implement in nixpkgs.

The RFC is not about that directly anymore. It's about adding mechanisms that allow you to do that, for any repository, not just Nixpkgs. Even if this isn't used in Nixpkgs, it would be useful for a lot of people, including me.

But then, wouldn’t an independent implementation be a better fit? Why does it have to go through the nixpkgs RFC process if it’s not about a nixpkgs implementation?

For example, the POP-RFC was opened a while ago, and recently the theory behind it has gotten a paper that was accepted to a conference, which gives me more assurance that it’s a worthwhile goal to pursue (https://github.com/NixOS/rfcs/pull/91/commits/dab823950244e5ded6da712aaa7b5c4f80549fd1) even though I was skeptical at first.

L-as

comment created time in 3 days

pull request commentNixOS/rfcs

[RFC 0098] Community Team

In all these years I have been very happy with how things worked: discussion has been most stricly technical; I have seen some disagreement regarding, again, technical decisions, but this never ever resulted in heated discussion, let alone insults or worse; I have never felt out-of-place, harrassed or anything of the like.

I’m pretty sure “it has never happened to me, so it does not happen to other people” is a common fallacy regarding moderation discussions.

IreneKnapp

comment created time in 3 days

pull request commentNixOS/rfcs

[RFC 0100] Sign commits

For example, at the time of writing my comment in https://github.com/NixOS/rfcs/pull/100#issuecomment-898952043 got 7 thumbs up, which I’d interpret as a pretty broad disagreement with the idea behind signing commits (as described in the RFC).

L-as

comment created time in 3 days

pull request commentNixOS/rfcs

[RFC 0100] Sign commits

I’m unsure of how RFCs are intended to be closed if enough people think they are not a good idea.

If there’s 3 shepherds, does that mean there is a general consensus that this RFC should be generally accepted? Even if the shepherds figure out how they’d want to do it, it’s still a policy decision in the end.

L-as

comment created time in 3 days

pull request commentNixOS/nixpkgs

lib: fix ini generators

thanks!

zimbatm

comment created time in 3 days

pull request commentnix-community/lorri

feature: add a command to remove gc roots for old or removed projects

Before looking at this PR, here’s an unprimed design mockup of what I’d expect the gc root cleaning CLI to look like:

# lorri notes

## GC

> lorri gc info

Shows info about projects (shell files) that exist and have been evaluated.

Shows info about which projects don’t have a corresponding directory (or just can’t be reached anymore)

`--json` prints a json representation that can be parsed in scripts.
It contains

- The shell file path
- Whether the shell file is still accessible (i.e. the project got deleted or moved)
- The last derivation generated for the project (?)
- The gc root for the store path
- The timestamp of when the project was evaluated (or built?) last.

> lorri gc rm --shell-file path/to/shell.nix --shell-file … 

Removes any gc roots to the shell file, so that the next nix garbage collect removes the project store paths.

Removes the project from lorri’s database.

Afterwards runs `nix-store --delete` on all drvs and store paths that we know about (how to determine? Do we have references to the store paths? Or do we need an extra `nix-store --query` to find the paths?

Since there is no way to figure out if a drv has some IfD-paths it instantiates (is there?), we should print a message to run `nix-store --gc` to remove all artifacts, also the ones from previous runs.

> lorri gc rm --all

Removes all gc roots that were created by lorri.

Convenience for parsing `gc info --json` and constructing a long `gc rm` command line with all files.

> lorri gc rm --older-than=\<days\>

Removes all gc roots that haven’t been updated `<days>` ago.

Convenience for parsing this information from the `gc info --json` output and creating a `gc rm` command line with all files.
symphorien

comment created time in 4 days

pull request commentNixOS/rfcs

[RFC 0083] Common interface package sets

Having a published paper at the Scheme conf really piked my interest in this, I’ll try to read the paper when I find the time.

Nixos does have a quite big sunk cost on its current module system, but e.g. https://github.com/tweag/nickel/ might be a good candidate for applying this research! cc @yannham

FRidh

comment created time in 6 days

PR merged nix-community/lorri

fix(daemon): fix fd leak when writing yields BrokenPipe

we would be waiting on read on an empty pipe for ever.

the leak is hit by running lorri internal stream-events --kind snapshot in a loop

  • [x] Amended the changelog in release.nix (see release.nix for instructions)
+8 -1

1 comment

2 changed files

symphorien

pr closed time in 9 days

push eventnix-community/lorri

Symphorien Gibol

commit sha 780c9a9825969f1bd068690717341ba1d5a9538f

fix(daemon): fix fd leak when writing yields BrokenPipe we would be waiting on read on an empty pipe for ever.

view details

push time in 9 days

pull request commentnix-community/lorri

fix(daemon): fix fd leak when writing yields BrokenPipe

Nice find!

symphorien

comment created time in 9 days

startedmuesli/gitty

started time in 13 days

startednumtide/treefmt

started time in 16 days

pull request commentProfpatsch/yarn2nix

Fix binary name for scoped packages

Released as 0.9.0.

jvasseur

comment created time in 23 days

release Profpatsch/yarn2nix

0.9.0

released time in 23 days

created tagProfpatsch/yarn2nix

tag0.9.0

Build and deploy node packages with nix from yarn.lock files.

created time in 23 days

push eventProfpatsch/yarn2nix

Profpatsch

commit sha 45dd37ed7b82785b31a729d2eff30cd993670d75

chore(CHANGELOG) yarn2nix 0.9.0

view details

push time in 23 days

push eventProfpatsch/yarn2nix

Profpatsch

commit sha d42656e8d3855d4d15b68cfd626e6f6bb9475c64

chore(*): Add default .hlint.yaml and fix warnings

view details

push time in 23 days

push eventProfpatsch/yarn2nix

Profpatsch

commit sha 2e0ef5bab3e7d0e334908a6ad097562badc56c56

chore(*): Replace maybe/fromMaybe with case matches Just for clarity.

view details

Profpatsch

commit sha ec8b17921dbd105fcd360dbfbf2e315a6e9138e7

chore(OptimizedNixOutput): fix warning

view details

push time in 24 days

pull request commentProfpatsch/yarn2nix

Fix binary name for scoped packages

Thanks, LGTM.

jvasseur

comment created time in 24 days

push eventProfpatsch/yarn2nix

Jérôme Vasseur

commit sha 01cb29ee3d3018ee6c40f6c111080fba81a64a70

Fix bin name for scoped packages

view details

push time in 24 days

PR merged Profpatsch/yarn2nix

Reviewers
Fix binary name for scoped packages

Fix short form of bin field ("bin": "./path/to/bin") for scoped package where the binary name should be the package name without scope instead of the full name.

For example for @babel/parser it should generate a .bin/parser link instead of a .bin/@babel/parser link.

It probably makes https://github.com/Profpatsch/yarn2nix/pull/45 unnecessary.

(this is my first time writing Haskell so I might have made some newbie mistakes)

+24 -10

2 comments

3 changed files

jvasseur

pr closed time in 24 days