<jtojnar>
I would like to strip wrapGAppsHook of dependencies
<jtojnar>
the few are usually already listed in the individual packages’ dependencies
<jtojnar>
and it would allow us to use the hook for for example CLI apps
ris has quit [(Ping timeout: 240 seconds)]
<gchristensen>
that seems fine
Sonarpulse has quit [(Ping timeout: 248 seconds)]
<gchristensen>
lol ... hydra requires no auth at all to trigger evals.
orivej_ has joined joined #nixos-dev
propumpkin has joined joined #nixos-dev
zraexy1 has joined joined #nixos-dev
mbrgm has quit [(Ping timeout: 240 seconds)]
mbrgm has joined joined #nixos-dev
orivej_ has quit [(Ping timeout: 264 seconds)]
orivej has joined joined #nixos-dev
wapl has quit [(Ping timeout: 248 seconds)]
wapl has joined joined #nixos-dev
<orivej>
Could someone bump https://hydra.nixos.org/eval/1414999 to the front of the queue? There are just 297 darwin packages left, but most of them have been queued for two days.
ma27 has joined joined #nixos-dev
ma27 has quit [(Ping timeout: 240 seconds)]
phreedom has quit [(Remote host closed the connection)]
vcunat has joined joined #nixos-dev
FRidh has joined joined #nixos-dev
goibhniu has joined joined #nixos-dev
__Sander__ has joined joined #nixos-dev
orivej has quit [(Ping timeout: 260 seconds)]
<LnL>
oh! nix-build --store ssh-ng://foo is a thing
<__Sander__>
he also wrote an interesting issue for node2nix
<gchristensen>
oh?
ma27 has joined joined #nixos-dev
<octe>
trap you?
<__Sander__>
asking me whether it was something professional or just a hobby
<phreedom>
gchristensen: yeah nixpkgs is a trap. you are hooked for life
<vcunat>
:-D
<gchristensen>
lol
<vcunat>
Those comments don't seem too bad to me.
<__Sander__>
well this is not too bad yet
<phreedom>
vcunat: have you ever seen trap clearly marked as such? :)
<__Sander__>
but
<gchristensen>
they're not, but he seems to have a way of starting somewhere and drawing you in to something
<gchristensen>
__Sander__: unfortunately for you, I have an easier way out. I just closed his issue and archived the repo :P
<__Sander__>
hehe
<__Sander__>
well he did not do anything too offensive yet
<gchristensen>
not yet
<MichaelRaskin>
Yeah, unlike NixOS Nixpkgs is catastrophically sticky.
<__Sander__>
sounds a bit like 0xABAB
<__Sander__>
I still remember some of his comments :D
<__Sander__>
asking the author whether he was "qualified enough to do such a project"
<gchristensen>
yeah
<gchristensen>
I'm half-tempted to label issues from people we think are 0xabab as such
<gchristensen>
but that is probably not a good idea
<MichaelRaskin>
Yeah, you shouldn't assume there is only one troll in the entire world.
<MichaelRaskin>
Delusions are bad.
<vcunat>
GitHub doesn't allow us to label users...
<gchristensen>
not only one troll, but pretty sure this is the same one
<gchristensen>
unless we happen to be on a string of brand new not-connected users who happen to register on github right around the time the last one was banned
<vcunat>
It might be a not-too-rare combination of personality traits, from what I know.
<gchristensen>
and exclusively to open issues in nixpkgs and repos by people involved with nixpkgs :P
<MichaelRaskin>
Well, if we ever base actual decisions on the likelyhood of this-being-0xABAB, they will start masking a bit better and try to troll us into confusing someone else for the next clone…
* gchristensen
hides
<vcunat>
I think nixpkgs has been relatively lucky, seeing very few people whose contributions might be considered of negative value.
<gchristensen>
I agree
<gchristensen>
iirc, before 0xabab the ban list was 1 person for years
<MichaelRaskin>
I think we still have relatively high technical knowledge threshold for even understanding why looking at Nix is a good idea.
<gchristensen>
ohh trolls as a measure of a symptom of an adoption problem!
<MichaelRaskin>
I am not sure having too low adoption is The Problem now, to be honest…
<vcunat>
:-) the fraction of "new" users does seem relatively high, in the last few years.
<vcunat>
(new contributors actually; I suspect we don't ever hear about most of users)
<MichaelRaskin>
Also I think we have quite a thin line between what is expected to earn a ban relatively quickly (personal attacks and vague criticism that everything is done wrong — this is declared low-quality trolling everywhere, even between high-quality trolls) and what is accepted without really noticing it (you are doing this specific thing wrong — well, we will get around to it, some day…)
<MichaelRaskin>
As for adoption — I think debottlenecking decisions (or making the bottlenecked areas super clear) and getting a consistent flow from regular contributors to reviewers are both more interesting questions than raw numbers.
orivej has joined joined #nixos-dev
<gchristensen>
MichaelRaskin: I'm not sure I understand your comment about the thin line
<MichaelRaskin>
Well, we don't even attract people without technical skills; and then Nix community is not one that is easy to troll acidentally.
<vcunat>
hmm, shall we make a label for stuck (major) decisions?
<gchristensen>
ahh I see now, thank you for clarifying :)
<vcunat>
... or do open RFCs serve for the definitive list?
<MichaelRaskin>
Accepted RFCs show the rare major decisions that are not stuck. Major decisions are stuck by default.
<vcunat>
Well, yes.
<vcunat>
I agree with that default.
<vcunat>
but I suppose there are too few people motivated by unstucking them.
<vcunat>
(besides each single proponent)
<MichaelRaskin>
gchristensen: maybe this lack of gray area is a positive side-effect of most RFCs being stuck. We came to expect that every two users have a question where they consider each other's opinion weird and wrong. When such is the norm, it is hard to get a flamewar to spill.
<MichaelRaskin>
vcunat: I meant that any major issue gets stuck, whatever you do, unless you get really lucky.
<vcunat>
yes, probably
<vcunat>
it may happen that noone notices or cares enough
<MichaelRaskin>
vcunat: the expectation of what constitutes consensus are currently higher than the actual average level of _any_ participation (either supportive or critical).
<vcunat>
:-)
<vcunat>
perhaps accumulating more experienced nixers will help that
<MichaelRaskin>
Nope.
<MichaelRaskin>
It will actually hurt.
<gchristensen>
there has been a bit of simmering discussion about joining the software freedom conservancy or something like it. one of their questions is how do decisions get made and how are disagreements handled. this was the hardest part, and something we need to solve
<MichaelRaskin>
If you have 50% chance of getting any opinion from each person, and need 80% participation, the fewer people there are, the higher chance of a fluke high participation there is.
<vcunat>
hmm, right, major decisions will almost certainly get tougher with larger community (on average)
<MichaelRaskin>
decisions? get made? This is not about Nixpkgs.
* gchristensen
is confused
<gchristensen>
or is that a joke that no decisions get made about nixpkgs
<vcunat>
Well, e.g. I resigned on support for older kernels in unstable/master (and thus support for nixpkgs on RHEL/CentOS 6).
<vcunat>
Noone really opposed it, so it just went through.
<vcunat>
(AFAIK)
<gchristensen>
it is a shame you didn't come to nixcon MichaelRaskin, it'd've been fun to meet you
<vcunat>
ever been to NixCon-like event?
<MichaelRaskin>
gchristensen: well, this is an overpessimistic interpretation of the long history of Nix.
<gchristensen>
vcunat: I'd have requested we support RHEL6 a bit longer if I knew it was going to happen :P
<vcunat>
:-D
<vcunat>
I'm considering to propose that we maintain 17.09 for longer than half a year.
<MichaelRaskin>
I have never been to any Nix-topical event. I go to European Lisp Symposium and to some theoretical conferences.
<gchristensen>
next mini-NixCon should be at the European Lisp Symposium
<phreedom>
I still don't get why people go to conferences instead of writing blog posts :)
<vcunat>
I wonder, maybe co-locating it with some big loosely related event might be advantageous.
<vcunat>
Some smaller/focused conferences do that.
<phreedom>
also the eu, where all this happens is a pita to travel to
<gchristensen>
phreedom: where are you based?
<vcunat>
ATM :-)
<phreedom>
I do my best to stay mobile, but I'm writing this from kiev, ukraine :)
<gchristensen>
cool :)
<phreedom>
I wish it was cool :)
<MichaelRaskin>
phreedom: hasn't 90-days-tourist-visits agreement come into effect yet
<MichaelRaskin>
??
<gchristensen>
I found it incredibly motivating to meet all these people in real life, which I can't get fromblog posts
<phreedom>
MichaelRaskin: well, now you need a passport with fingerprints. I can't say this is such an improvement
<phreedom>
MichaelRaskin: and soon everyone will also need an eletronic travel authorisation. basically a mini-visa
<phreedom>
gchristensen: hanging around with cool people is something I'd like, but I think conferences actually impede this, as long of time is wasted on activities easily replaced by blogs
<gchristensen>
haha cool ;0
<vcunat>
For NixCon, the presentations are nice, but for those alone it wouldn't be worth for me to come.
<gchristensen>
:)
<gchristensen>
the presentations are what convinced my company to pay some of it
<vcunat>
:-) this depends on organizers - I think it was relatively different two years ago
<vcunat>
(and before in Llubljana it was just a week-long hackathlon, kind of)
FRidh has quit [(Quit: Konversation terminated!)]
ma27 has quit [(Ping timeout: 250 seconds)]
ma27 has joined joined #nixos-dev
vcunat has quit [(Quit: Leaving.)]
<orivej>
MichaelRaskin: What major decisions are you interested in? (I have missed the part of the conversation before 12:31 UTC.)
<gchristensen>
it is funny, I know and have experienced the difficulty of decision making in the Nix ecosystem but don't have good examples
<orivej>
I am not aware of any outstanding issues...
<gchristensen>
you may just not be around long enough to have butted against them yet
<gchristensen>
which is good!
<orivej>
true. but from what I've read above, it seemed MichaelRaskin had something bothering him today
<gchristensen>
no, nothing specific today
<MichaelRaskin>
I would like to have saner settings for parallel builds…
<gchristensen>
the current major decision making flow is: 1. someone suggests a thing, 2. they ping people in the issue tracker until pretty much eelco says it is okay
<MichaelRaskin>
This is an _old_ fiasco.
<MichaelRaskin>
I stopped caring since then…
<orivej>
wrt parallel building, enabling it by default for all projects will require some constant diligence to Hydra for a while, and may not bring measurable benefits. However, enabling it for *cmake*-based projects is almost safe, affects a lot of projects, and should not be strongly opposed.
LnL has quit [(Quit: exit 1)]
<gchristensen>
you're still working within the confines of the system that already exists for enabling parallel builds, and MichaelRaskin doesn't want to
ma27 has quit [(Quit: WeeChat 1.9.1)]
LnL has joined joined #nixos-dev
ma27 has joined joined #nixos-dev
<orivej>
I don't understand the confines. `nativeBuildInputs = [ cmake ]` could simply activate parallel builds unless `enableParallelBuilding = false`. The way buildGoPackage does.
<MichaelRaskin>
orivej: Hydra severly limits the parallelism on the global level, and this is a correct thing to do.
<MichaelRaskin>
But the expressions currently can only have known-good state; a better case would be to have known-good and known-bad states, with the default being configurable by the build machine's administrator.
<orivej>
MichaelRaskin: If I understand you correctly, expressions can and do designate known-bad state with `enableParallelBuilding = false`. (It is distinct from `enableParallelBuilding` being absert: the former sets the environment variable to an empty string and the latter leaves it unset.) AFAIK hydra does not impose additional constraints on the parallel building (except that it may globally limit parallel fetching of the sources).
<MichaelRaskin>
orivej: this difference is not handled by the stdenv, though.
<MichaelRaskin>
(parallel building is a permitted impurity)
<orivej>
It does not make much sense to me to let some builders treat absent enableParallelBuilding as true when Hydra treats it as false: parallel builds should be a common effort and a common benefit, since you can not discover and debug its issues as efficiently as Hydra and the community, or when there are no issues (presumably with cmake), there is no reason not to enable it for everyone.
<gchristensen>
I think it is important to support different use cases and requirements
<MichaelRaskin>
Hydra is not supposed to be used to discover if packages can be safely built in parallel.
<MichaelRaskin>
It is quite conservative, actually, because it fills the binary cache and should choose safety.
<orivej>
IHMO its role in filling binary caches is as important as its role in ensuring the quality of Nixpkgs: I really do not want the users of Nixpkgs (with sandboxing) to encounter build failers without having a chance to notice these build failures on Hydra before them.
<MichaelRaskin>
Well, I think parallelism is off by default.
<__Sander__>
I finally managed to deploy one of our non-trivial projects with NPM 5.x/Node.js 8 + node2nix
<phreedom>
and node is what makes it non-trivial? :)
<__Sander__>
hehe
<__Sander__>
well actually the project has 24K+ dependencies
<__Sander__>
that's what I meant
<__Sander__>
I also have a couple of test cases with only 10 dependencies or so :p
<phreedom>
that's epic
<phreedom>
and I doubt it works
<phreedom>
:D
<phreedom>
seriously, the JS code quality tends to be pretty bad. 24k packages sounds like an endless source of bugs and quirks
<__Sander__>
yes actually
<__Sander__>
I'm totally unhappy with the quality of the project
<__Sander__>
so co-worker thought it would be a good idea to take somebody else's project template with a gazillion grunt plugins
<__Sander__>
and he told me: "but hey, it implements the best practices of this company"
<phreedom>
gulp is a similar mess, if it makes you feel any better :)
<__Sander__>
nope
<MichaelRaskin>
orivej: well, I would consider sometimes trying to force-enable parallel builds of most packages, but there is no option to do this.
<__Sander__>
also the deployment/update times of this project are quite long
<__Sander__>
and we only use 10% of the grunt plugins
<__Sander__>
but "due to other priorities and time pressure" we're not going to change it anytime soon :p
<gchristensen>
wowww __Sander__
<__Sander__>
anyway
<__Sander__>
node2nix can handle it
<__Sander__>
despite the fact that the project is junk :D
<phreedom>
and now imagine doing the same on the frontend, where you don't even get bug reports. you simply notice different and suspicious traffic patterns :)
<__Sander__>
indeed
<orivej>
MichaelRaskin: put `: ${enableParallelBuilding=1}` at the beginning of `pkgs/stdenv/generic/setup.sh`
<MichaelRaskin>
orivej: which makes such an experiment incompatible with using anything fomr binary cache.
<MichaelRaskin>
Like GCC.
taktoa has quit [(Remote host closed the connection)]
<orivej>
If you don't have a hydra cluster, you may ask for a personal jobset on Hydra, it will populate the binary cache.
<orivej>
Moreover, you made me considere doing a PR with `: ${enableParallelBuilding=1}` in `pkgs/development/tools/build-managers/cmake/setup-hook.sh` (after testing on my hydra).
<MichaelRaskin>
Hm, that sounds nice, thanks.
phreedom has quit [(Ping timeout: 252 seconds)]
phreedom has joined joined #nixos-dev
__Sander__ has quit [(Quit: Konversation terminated!)]
goibhniu has quit [(Ping timeout: 248 seconds)]
Sonarpulse has joined joined #nixos-dev
ma27 has quit [(Ping timeout: 258 seconds)]
<Sonarpulse>
bgamari: I think I found it!
<Sonarpulse>
CFLAGS_FOR_BUILD = EXTRA_FLAGS in builder.sh
<Sonarpulse>
that is no good!
<bgamari>
yay!
<Sonarpulse>
trying now
propumpkin is now known as contrapumpkin
peti has quit [(Quit: WeeChat 1.8)]
orivej has quit [(Ping timeout: 248 seconds)]
peti has joined joined #nixos-dev
ris has joined joined #nixos-dev
pbogdan has quit [(Quit: ZNC 1.6.5 - http://znc.in)]