tilpner has quit [Remote host closed the connection]
<ma27>
question to the core maintainers: would it make sense to replace "Tested execution of all binary files" with "Tested build output" in the PR template on GitHub? I always check this even if the package I changed has no binary, but I tested e.g. the built library
tilpner has joined #nixos-dev
infinisil has quit [Ping timeout: 252 seconds]
ma27 has quit [Ping timeout: 240 seconds]
acowley has quit [Ping timeout: 255 seconds]
acowley has joined #nixos-dev
Lisanna has quit [Quit: Lisanna]
mbrgm has quit [Ping timeout: 248 seconds]
mbrgm has joined #nixos-dev
pie_ has joined #nixos-dev
thefloweringash has joined #nixos-dev
thefloweringash has quit [Quit: WeeChat 1.9.1]
thefloweringash has joined #nixos-dev
pie_ has quit [Ping timeout: 240 seconds]
davidlt has joined #nixos-dev
davidlt_ has joined #nixos-dev
davidlt has quit [Ping timeout: 256 seconds]
FRidh has joined #nixos-dev
ma27 has joined #nixos-dev
JosW has joined #nixos-dev
davidlt_ is now known as davidlt
xeji has joined #nixos-dev
<sphalerite>
I seem to be getting a bunch of emails about packages I have nothing to do with from Hydra, what's going on?
<sphalerite>
ma27: that doesn't sound like a core team question (core team is for nix, *not* nixpkgs)
<sphalerite>
ma27: I'd just open up a PR changing it and see what people say :)
<ma27>
sphalerite: I said core maintainers and meant the nixpkgs folks, but you're right,it was ambiguous and I was wayy too tired when I wrote this message :-D
<shlevy>
sphalerite: It looks to be hydra's "maybe this commit caused this issue" feature, hitting some big merge
<sphalerite>
:(
<gchristensen>
Dezgeg: probably not the time in #nixos to debates the uselessness of using gpg to verify a key you've never trusted before other than b/c this site says you should
<shlevy>
gchristensen: Why not?
<MichaelRaskin>
Should we encourage a completely cargo-culted security approach, though?
<gchristensen>
the convo turned antagonistic I think
<gchristensen>
and we probably should be signing ISOs
<MichaelRaskin>
Erm. Do you actually disagree with my 1000 hours + 3 months statement?
<gchristensen>
no
<gchristensen>
it wouldn't even take 1,000 hrs, just ryan's script
<shlevy>
IMO it doesn't look antagonistic. It *does* look a little problem-focused instead of solution-focused, though.
<MichaelRaskin>
Not really.
<MichaelRaskin>
ryan's patches are _just_ version bumps, and they get reviewed for that
<MichaelRaskin>
gchristensen: I think timestamping «this claim of hash has been made a week ago» is more useful than signing
<manveru>
i'm just waiting for someone to mention blockchains :D
<sorear>
is binary transparency still a thing
<shlevy>
sorear: You mean transparent binary substitution? Yeah
<MichaelRaskin>
blockchain is just a log of timestamping.
<gchristensen>
everything is more or less useful than other things, but it doesn't eliminate the importance and value of signing ISOs
<MichaelRaskin>
If you do not need convergence, independente transparency logs are actually better than blockchain
<gchristensen>
you're looking for the wrong promise
<MichaelRaskin>
We need independent timestamping — binary transparency — yes.
<shlevy>
MichaelRaskin: I disagree. If we signed and stopped there, yes. But it does say something (modulo web of trust, which operationally is an orthogonal concern): This ISO was actually built form this nixpkgs commit.
<shlevy>
And that *is* valuable information, even if as you say it's hardly proof of a secure system
<MichaelRaskin>
No, it just says «this is built on a machine that was at one point intended to build NixOS ISOs»
<gchristensen>
yep
<gchristensen>
that is valuable
<MichaelRaskin>
Because if I can replace the sha256 on Hydra, I can as well ask it to fetch from githud.com
<shlevy>
Replace the sha256?
<MichaelRaskin>
Well, the discussion started with the question how easy it is to make Hydra show wrong ISO and the corresponding SHA256 instead of the correct one.
<gchristensen>
these are two both important considerations but doeesn't remove the importance of knowing the ISO came from the place it should have
<shlevy>
Anyway, I actually think it would be a good idea to have hydra and its builders running some hardened distro... I don't think trust and security are the place to dogfood
<gchristensen>
X_X
* gchristensen
feels a bit insulted
<MichaelRaskin>
shlevy: I think what you say is impossible in a meaningful way.
<shlevy>
gchristensen: I'm sorry. It's not about the current state of NixOS. I would say debian should use RHEL etc.
<gchristensen>
to say RHEL is hardened :')
<shlevy>
:P You know what I mean
<MichaelRaskin>
Well, it is, nothing works there.
<MichaelRaskin>
I mean, upstream SBCL binaries don't start on RHEL.
<gchristensen>
I know they prefer to run ancient software because of stability and bend over backwards to apply "Security-only" (not a real thing) patches
<MichaelRaskin>
The problem is: if we want best possible purity on Hydra, this will use a lot of kernel features, and every Hardened distro will completely forbid at least one of them
<gchristensen>
anyway, my axe in this horse fight is that ISO signing is valuable and it would be cool if we could do that
<MichaelRaskin>
gchristensen: they are also the only distribution that actually uses SELinux, and that does break every program that administrator hasn't spent special effort on fixing, including most of the attack shellcode
<clever>
technically, nix is already signing it, with the cache.nixos.org key, but you need nix to verify that signature
<gchristensen>
that is true
<MichaelRaskin>
We need third-party timestamping of ISO hashes, without it the signatures are worthless against the top realistic risks, and with that, signatures don't add anything (in our development model).
<MichaelRaskin>
I have talked in person to too many people who called Data Matrix labels (with just IDs) «digital signatures» to approve using signatures — which unfortunately imply a different model to many people
<shlevy>
MichaelRaskin: I don't think it's useless. But even if you are correct, if you're not proposing a concrete implementation it's very hard to take action on that
<MichaelRaskin>
Create a subdomain per ISO, with revision and hash in the name, and get a LE certificate for it.
<clever>
lol
<MichaelRaskin>
I am slightly downgrading their model, but it is actually close enough
<shlevy>
MichaelRaskin: Wouldn't we realistically need to do that for every channel release?
<clever>
all that really does is proove you had control of the nixos.org domain at that time, and knew the hash of the iso
<MichaelRaskin>
clever: _at that time_
<clever>
now your just abusing LE as a timestamping server
<gchristensen>
at any time
<clever>
and the certs expire within 3 months, so you need special tools to extract the ttimestamp
<MichaelRaskin>
gchristensen: CT
<gchristensen>
this seems somewhat contrived
<MichaelRaskin>
Certificate transparency is specifically very much interested in proper timestamping
<gchristensen>
but at what time?
<MichaelRaskin>
Basically, we have continuous builds, so _the only_ thing that can be convincing is that an ISO has been reported for two weeks, and no problems have been reported with it.
<MichaelRaskin>
In _linear_ time in terms of what?
<shlevy>
MichaelRaskin: Source code
<MichaelRaskin>
I think building inside Bochs and producing a full log will qualify
<taktoa>
shlevy: :-)
<MichaelRaskin>
Bit-perfect reproducible builds are even a bit better.
<gchristensen>
hopefully they're 0 bits better
<shlevy>
I really wish we had a good way to direct the efforts of all of the various reproducibility projects to base their work on Nix
<shlevy>
It's such a good fit
<shlevy>
Make their job easier and benefit us hugely for free
<gchristensen>
IIRC you can browse the debian issue tracker for reproducible issues w/ patches
<gchristensen>
s/reproducible/reproducibility/
<MichaelRaskin>
I think Debian people have just enough of isolated builds already, so for plain reproducibility they don't gain much from Nix
<MichaelRaskin>
Their patches to the build processes are universally useful anyway
<sorear>
MichaelRaskin: if I wanted to waste your time I'd tell you to research SNARKs
<MichaelRaskin>
sorear: and I would reply «what did you want to learn about them?»
<shlevy>
I think gettimeofday should require CAP_SYS_ADMIN and processes and threads with non-root UIDs should be deterministically serially interleaved
<MichaelRaskin>
It's all just a question which not-really-random-oracle function is good enough to run the standard commit-then-reveal-random-subset ZKP
<manveru>
can we at least make the minimal iso reproducible?
<MichaelRaskin>
Without a seconf party, as the random oracle replaces it
<MichaelRaskin>
shlevy: do you have any idea how much performance that will kill?
<shlevy>
MichaelRaskin: Yes :D
<shlevy>
Sorry, please don't take me seriously
xeji has quit [Quit: WeeChat 2.0]
<clever>
shlevy: ive been anoyyed at how programs are stat'ing /etc/localtime several times a second
<MichaelRaskin>
shlevy: I was just checking if you want to start a top-it competition of convincing lower bounds
<taktoa>
MichaelRaskin: wrt the stuff in my tweet, the idea I had probably won't be linear, but it will be in practice much faster than rerunning the compiler since AFAIK most of a compile time is spent in some kind of proof search or graph coloring
<taktoa>
it does mean that you, as the verifier of the proof, have to trust the compiler source
<taktoa>
though I guess for trusting trust reasons that's true anyway
<shlevy>
taktoa: Couldn't the proof be expressed in terms of some independent formalization of the relevant operational semantics?
<MichaelRaskin>
Well, the tweet _only_ talked about «honest output of compilation by _this_ compiler»
<taktoa>
I meant that you have to trust that the compiler doesn't go into an infinite loop since you will have to execute parts of the compiler source when verifying
<gchristensen>
wait so rolling back, how does the proof help?
<taktoa>
gchristensen: it means that you can have someone else compile something for you and then verify that the binary they produced is legitimate without rerunning the compiler
<gchristensen>
oh I see, ignore me
<MichaelRaskin>
taktoa: that last part is avoidable — the proof comes with a bound on the needed steps
<taktoa>
yeah good point
<MichaelRaskin>
For various reasons, though, I am not sure this will be as productive as you hope. The colouring is applied to an interval graph anyway, so there is a polynomial algorithm
<taktoa>
well most kinds of optimization are a proof search, so we can at least get that benefit
<MichaelRaskin>
Not all proof searches have a large search/verification gap
<shlevy>
Are there numbers on the relationship of the difference in time between -O0 and -O3 and the length of source code?
<MichaelRaskin>
For C, I would also add tinycc, just to have a baseline…
<taktoa>
MichaelRaskin: true, but in an ideal world we'd be using equality saturation ( http://www.cs.cornell.edu/~ross/publications/eqsat/ ) for optimization and that _does_ have a large search/verification gap AFAICT
<taktoa>
(I'm doing my undergrad senior thesis on eqsat for WebAssembly)
<MichaelRaskin>
In the ideal world we would actually have programs that are optimised for parallel execution with task stealing, but oh well.
<taktoa>
MichaelRaskin: those are not mutually exclusive; equality saturation works by converting the CFG to a referentially transparent / algebraic representation with sharing
<taktoa>
(stateful operations is handled via linear token passing)
<manveru>
it'd be really a good start if building the iso locally actually resulted in the same hash as hydra
<manveru>
even for just the minimal one
<MichaelRaskin>
Yes, _then_ signing by people who did a clean build would be a useful things
<manveru>
right now you have to trust hydra and have no way to verify
<MichaelRaskin>
Yes.
<manveru>
once that's reproducible, we can work on distributed verification of builds with signing and stuff
<gchristensen>
gotta get that reproducible build on
<shlevy>
manveru: Start the project :)
<manveru>
i don't even know where to start :P
<MichaelRaskin>
There is an old reproducible-build PR
<MichaelRaskin>
Triaging the patches there into applied/obsolete/relevant would be really useful
<gchristensen>
manveru: lots of nix-build and diffoscope
pie_ has joined #nixos-dev
<FRidh>
Has anyone checked whether the Nix support in Travis now uses nix 2.0?
<copumpkin>
Argh so much hydra spam what’s going on?
<copumpkin>
My inbox is full of it
pie___ has joined #nixos-dev
<MichaelRaskin>
Time to set up email auto-sorting into folders
<MichaelRaskin>
A large merge hit the Hydra
<MichaelRaskin>
And for all the changed states, it emails by the entire commit log
<copumpkin>
I do but usually am able to read my hydra notifications to see if I broke something
<MichaelRaskin>
Well, not this time…
<copumpkin>
This one is wild and has been spamming me with nonsense all morning :?
<MichaelRaskin>
Maybe if you sort by branch…
<gchristensen>
I think this happens every time we make a new channel
<clever>
copumpkin: why have i not gotten a single email? lol
<gchristensen>
how much stuff do you maintain?
<clever>
oh, they are in my spam box, lol
<clever>
gmail doesnt show spam in your search
<copumpkin>
:)
<MichaelRaskin>
Well, keep them in spam, and gmail will silently discard them without even putting them in spam!
pie__ has quit [Ping timeout: 264 seconds]
<copumpkin>
Part of it is that gmail sees them coming from niksnut’s gmail address but knows deep down that gmail didn’t send them so always warns gmail users about it
<sphalerite>
why does hydra not have its own email address??
<MichaelRaskin>
«Part of it is that gmail»
<MichaelRaskin>
Not sure if the rest adds to explanatory power.
<MichaelRaskin>
sphalerite: you know how it goes, it's probably good if replies go somewhere, let's put an address into From:…
orivej has quit [Ping timeout: 256 seconds]
<gchristensen>
niksnut: we have a spam emergency!
<gchristensen>
its hydra!
<gchristensen>
ikwildrpepper:
<gchristensen>
anybody
<obadz>
gchristensen: what's it doing?
<MichaelRaskin>
domenkozar shlevy: do you have jobset cancellation powers on Hydra? Or at least throttling…
<gchristensen>
apparently random one-off commiters have received dozens of failure emails
<simpson>
Wait, is that not normal? I get lots of emails from Hydra. I figure it's just being friendly.
<MichaelRaskin>
Is it feasible to starve 18.03 of build shares?
<niksnut>
maybe just disable email notification for the jobset?
<MichaelRaskin>
Ah, if you are here then yes
<MichaelRaskin>
I was not sure who had which access.
<gchristensen>
niksnut: it works in arrears? like a job already in processing will notice it changed?
<niksnut>
anyway we should probably just disable email notification globally, but I don't think hydra currently has a config option for that
<niksnut>
gchristensen: it should
<gchristensen>
I disabled mail for nixos:release-18.03
<gchristensen>
niksnut: thank you!
<obadz>
btw anyone knows what's going on with the qt packages that hold back 18.03 ?
pie__ has joined #nixos-dev
<gchristensen>
niksnut: it isn't clear that disabling email fixed it
pie___ has quit [Ping timeout: 265 seconds]
<gchristensen>
niksnut: can you stop postfix or something?
<dtz>
Yeah I just never set up email on my hydra lol, "problem solved". Hopefully doesn't have a backlog / growing outbox message queue somewhere :P
<dtz>
Teehee and agreed re:hydra just being friendly :)
<copumpkin>
niksnut, gchristensen: the rate of hydra spam I’m getting suggests it’s slowly burning through a queue
<copumpkin>
I get an email once a minute or two, pretty consistently, and it’s been happening since earlier this morning
<copumpkin>
Also this isn’t email I configured ok Hydra itself, I think it’s just emailing the commit author email address
<contrapumpkin>
yeah, so I'm guessing it's just the relay chugging through an enormous queue at some fixed rate
<clever>
copumpkin: the weird part, is that the headers in the email claim it was received just a few seconds ago, from the hydra process
<samueldr>
so uh, looks like hydra is basically mailing *everybody* and destroying eelco's mail reputation?
<gchristensen>
I mentioned that to him :?
<samueldr>
(I haven't read the backlog carefully)
<samueldr>
I initially thought it was everyone who opted-in
<clever>
the SFP is a soft-fail, so email he sends directly thru gmail is likely going to be more trusted
<joachifm>
it's a little annoying :)
<clever>
the entire first page of my inbox is hydra now
<clever>
./configure: line 1491: syntax error: you disabled math support for $((arith)) syntax
<clever>
virtualbox configure script uses bash features that are disabled
<joachifm>
is it at all possible to halt the mailing feature for now?
<clever>
wait a sec, that email was about a job that failed 5 days ago
<clever>
its already been fixed
<clever>
Received: from localhost.localdomain (localhost [IPv6:::1]) by hydra.nixos.org (Postfix) with ESMTP id BF7021C134B for <cleverca22@gmail.com>; Sun, 11 Mar 2018 16:40:30 +0100 (CET)
<clever>
so a hydra job that finished on the 6th, only managed to contact the localhost postfix on the 11th
<clever>
niksnut: is there a backlog of hydra-notify's in `ps aux` ?
<dtz>
clever: the arith math stuff should be supported for some time now, make sure you're using latest Nix / nixpkgs ? (within few weeks, don't quite rem when)
<clever>
dtz: that was in a hydra error from 5 days ago, and its already been fixed
<dtz>
oh :D haha okay
<clever>
dtz: the real problem, is that hydra is emailing everybody about errors from 5 days ago, that are often already fixed
<dtz>
one of the builders needed to be updated, not sure if that job was just restarted on chanced onto a different builder or
<dtz>
yeah :/
<MichaelRaskin>
The real problem is, Hydra is emailing everybody about everything
<clever>
i just got an email about a problem from 2 days ago
<clever>
and another, from a 5 day old failure, that was fixed 2 days ago
<clever>
strange, a commit i made from oct 5th is in the diff of an eval from 2 days ago, in the middle of the jobset
<clever>
it shouldnt be having that many commits
<MichaelRaskin>
niksnut: on #nixos people wonder if it is time to use iptables as a stop-gap
<ekleog>
niksnut: otherwise, `postfix -f` should drop the queue, if hydra stopped adding new mail to the list
<clever>
ekleog: the timestamps in the headers imply there is no queue in postfix
<ekleog>
if hydra's on NTP then indeed
<contrapumpkin>
I don't think he sees IRC much on the weekend
<clever>
ekleog: it is reliably within a few seconds of the time it arrives, even though its sending emails from jobs that finished days apart
<contrapumpkin>
(I know he responded earlier but I don't think he checks very often)
<contrapumpkin>
not sure if someone's emailed him about it
<ekleog>
that said, I read someone had disabled mails for the 18.03 jobset?
<gchristensen>
I've mailed him
<contrapumpkin>
cool thanks
<ekleog>
so these mails must come from somewhere
<ekleog>
(and if it's just not working, I'd say systemctl stop postfix would likely be a better stop-gap than iptables, but don't know how gracefully hydra'd handle this)
<clever>
looking closer, a lot of the email is coming from the 2nd eval, when the failed jobs went from 91 to 1109
<clever>
still not clear why the 2nd eval has so many commits
<clever>
the 1st eval, was pointed at the 17.09 commit
<clever>
so the 2nd eval, covers every commit between the 2 stable releases
<ekleog>
but then where do the mail come from? hydra moved past this 2nd eval… unless hydra has its own throttler to avoid overloading postfix, and email was blocked in this queue?
<clever>
ekleog: the emails come from the hydra-notify perl script, and i have seen a backlog of those proceses before
<clever>
simply restarting the hydra-queue-runner service can often be enough to destroy the backlog
<ekleog>
oh thanks :)
jeaye has joined #nixos-dev
earldouglas has joined #nixos-dev
psychon_ has joined #nixos-dev
dylex has joined #nixos-dev
das-g has joined #nixos-dev
<das-g>
Heya
<das-g>
Um ... Some months ago I made some tiny contributions to nixpkgs and today I got like 91 emails from the Hydra build daemon about various failures (and 3 successes, yay).
avn has joined #nixos-dev
<das-g>
(And I'm pretty sure the changes I contributed are unrelated to most of those.)
<ekleog>
indeed, that's a bug that happened during creation of the 18.03 channel, hopefully will end soon
<das-g>
ah, i see
<clever>
dtz: the first eval of 18.03 was pointed to the 17.09 commit, so the difference between the 1st and 2nd eval, is every commit between 17.09 and 18.03
<das-g>
ah, that'd explain the message flood. Thanks for the information!
<jeaye>
Might be worth updating the /topic of #nixos and #nixos-dev until then.
<jeaye>
I imagine a lot of people will be wondering what's going on.
<MichaelRaskin>
Maybe also put it into the hydra issue
<ekleog>
gchristensen: ^ (only irc admin of both rooms or so it seems?)
<gchristensen>
write what it should say and I'll do it
<ekleog>
“Currently sending mail to all committers since 17.09. We're on it! | [old topic]” ?
<jeaye>
Looks good to me.
<ekleog>
(maybe “useless mail” would better make it explicit there is an issue?)
<jeaye>
Was in the middle of typing:
<jeaye>
"| Getting email spam? Hydra bug, sorry! Join #nixos-dev if you have questions."
<ekleog>
yeah, better :) (though I'd rather put it at the beginning than at the end of the topic)
<jeaye>
Yep, good point.
<jeaye>
gchristensen: Sound good?
<gchristensen>
why point them here? :P maybe write a wiki thing about it
<gchristensen>
to link to instead
dylex has left #nixos-dev [#nixos-dev]
<niksnut>
I've disabled postfix
<jeaye>
If there's a Hydra bug for it, we could link there.
<clever>
jeaye: there are 2 issues open on hydra for it
<ekleog>
niksnut: thanks! :) so I guess the changing the topic is no longer relevant :)
<clever>
niksnut: any backlog of hydra-notify processes?
<jeaye>
ekleog: We should still set the topic.
<jeaye>
At least for the next 24 hours, I think. People will be wondering, like roconnor in #nixos, who just joined, what's going on. Even if no more emails are pouring in.
<gchristensen>
thank you niksnut
{^_^} has quit [Remote host closed the connection]
{^_^} has joined #nixos-dev
{^_^} has joined #nixos-dev
<ekleog>
true, but then the topic may be “| Received email spam? Hydra bug, sorry! It should be solved by now” (at the end I guess as it's no longer that important?)
<jeaye>
Sure.
<ekleog>
gchristensen: ^ then if you feel like it's useful :)
psychon_ has quit [Quit: leaving]
<gchristensen>
samueldr wrote a small bot to send github notification, but combine them to be less spammy. we can move them to another channel or collapse them betteror whatever. please send feedback if you don't like it.
das-g has quit [Quit: Ex-Chat]
<MichaelRaskin>
So, a line per commit?
<gchristensen>
less I think
<MichaelRaskin>
It's complicated
<samueldr>
it works on push events
<MichaelRaskin>
Given that three 72-char commit titles fit a single IRC line, maybe they should be combined with a weaker separator than newline?
<samueldr>
it will post at most 3 commits per push events
<samueldr>
(that's how the github bot operated)
<samueldr>
right now, it mirrors mostly what the github bot did, but doesn't join/part
<samueldr>
so it's already a net gain
<clever>
samueldr: that just gave me an idea, send the github bot to #nixos-github, and then just have {^_^} mirror the notices over without the join/part
<gchristensen>
yeah maybe a separate channel is the best thing :/
<gchristensen>
not sure
<samueldr>
clever: if not obvious, because it isn't what I wrote is using gchristensen's infra, which has a webhook from github
<samueldr>
maybe we should hold an informal poll about the github notices, I really liked having them on #nixos, but I do know that it's disruptive when discussion is happening
<samueldr>
though, having them on a separate channel would help
<samueldr>
I seem to remember some people remarking on how cool it is to see the activity live on the channel
jeaye has left #nixos-dev ["WeeChat 1.9.1"]
<MichaelRaskin>
I have ideas, but they are a lot of work.
<samueldr>
oh, seems I have added issues, which wasn't previously reported by the github bot!
<MichaelRaskin>
Like accumulate over 1 minute, and hide details depending on the amount (so that the rate is never crazy)
<samueldr>
what's hard in there, how should it be presented next?
<gchristensen>
samueldr: bug or feature?:)
obadz- has joined #nixos-dev
<samueldr>
gchristensen: both! depending
<samueldr>
it's a bug if it should copy the github bot behaviour
<samueldr>
it's a feature if we make it so!
obadz has quit [Ping timeout: 248 seconds]
obadz- is now known as obadz
<samueldr>
for now, I have commented-out the issues webhook subscription, depending on what's needed, this can be changed
<samueldr>
and added the git.io bindings to shorten the github URLs
FRidh has quit [Quit: Konversation terminated!]
pie__ has quit [Ping timeout: 260 seconds]
JosW has quit [Quit: Konversation terminated!]
infinisil has joined #nixos-dev
<ekleog>
hmm, has 18.03 fork not already happened? https://nixos.org/channels/ doesn't appear to list it yet
<MichaelRaskin>
Fork yes, channel — you were among the people who complained about the channel's side effects
<gchristensen>
it has, but hasn't passed checks yet
<ekleog>
oh, hadn't understood that, thanks :)
<ekleog>
(I'd have thought as it was based on unstable it would automatically have at least the first revision as valid?)
<ekleog>
(or maybe stable has a more stringent test suite than unstable?)
<MichaelRaskin>
I think the jobset was created after some divergence has happenned
<ekleog>
oh ok
<shlevy>
MichaelRaskin: Started ml thread for design goals
<MichaelRaskin>
You think GitHub issue will get a wrong kind of exposure?
<shlevy>
Not threaded
<MichaelRaskin>
Fair enough.
<shlevy>
Grr I hate how google groups mangles my signatures :(
<MichaelRaskin>
Mwahaha
<MichaelRaskin>
Also, Javascript
<MichaelRaskin>
(Also, the viewer is not threaded)
<MichaelRaskin>
Although that last part might be changeable
<shlevy>
Oh, I don't use the web interface :P
<shlevy>
I mean the emails that arrive through it come through with invalid sigs
<MichaelRaskin>
Well, it's the only way to link to the archives, though
<shlevy>
Yeah :(
<ekleog>
shlevy: you may try inline PGP instead of PGP/MIME, that's the usual solution for misbehaving ML daemons
<MichaelRaskin>
Dumping the archive into a gist as the new mails arrive is probably too weird?
<shlevy>
:D
<MichaelRaskin>
That could actually be a better UI than Google Groups because everything is better UI than Google Groups
<ekleog>
MichaelRaskin: iirc some ML daemons add the link to the archives as a separate text/plain attachment, that is then displayed as following the message, thus allowing for PGP-signed relayed mails
<MichaelRaskin>
shlevy: so, the idea is to make multiple replies for unrelated goals?
<shlevy>
Yep
<MichaelRaskin>
Now I need to decide if what I want is a subgoal of what you write or an independent goal
<MichaelRaskin>
Although you seem to err on the side of separation, so I will try to do the same
<MichaelRaskin>
shlevy:
tomberek has joined #nixos-dev
tomberek has left #nixos-dev [#nixos-dev]
<Mic92>
I just tested to build a minimal module list for my server. So far it would half the evaluation time.
<manveru>
damn... yarn2nix based packages really need import-from-derivation :(
<manveru>
is this ever going to be possible on hydra/ofborg?
peti has quit [Ping timeout: 240 seconds]
<gchristensen>
probably not any time soon
<gchristensen>
but I dunno :)
<MichaelRaskin>
IFD on ofBorg would require evaluator to build?
<MichaelRaskin>
I hope someone else will write a design goal writeup for IFD/phases/code-generating-code…
<gchristensen>
surely shlevy will
<shlevy>
Not this phase :)
<shlevy>
But the answer is IFD is the wrong place to do phase separation and we just need monadic derivations ;)
peti has joined #nixos-dev
<MichaelRaskin>
Sent the first three letters to the goal thread…
orivej has joined #nixos-dev
pie__ has joined #nixos-dev
<clever>
manveru: what about just having a tool like cabal2nix that generates nix based on the yarn.lock, and then its pure nix?
<manveru>
well, of course we could use a .nix file, but that'd also need to be in nixpkgs then...
<clever>
yeah, but at least it wont be IFD, so no builds at eval time
<manveru>
hm, i wonder how long that'll be, will check :)
<manveru>
for some reason my downloads with nix2 are super slow...
<manveru>
barely ever goes over 53KB/s
<manveru>
alright, the yarn.nix for patchwork is about 6.5k lines
<manveru>
which is so the yarn.lock is still smaller by about 2k lines
<manveru>
do you guys really want such big nix files in nixpkgs?
<gchristensen>
no :)
<manveru>
well, i'll still update the PR with it :P
<manveru>
since it's impossible to merge with IFD, at least it's possible to merge with that monster
<manveru>
ok, actually that doesn't really fix it, since yarn still wants the yarn.lock...
<manveru>
i mostly did it this way now to get some discussions going... every day there are more js apps coming, and they usually have at least a few hundred dependencies
genesis has quit [Read error: Connection reset by peer]
davidlt has quit [Ping timeout: 260 seconds]
genesis has joined #nixos-dev
<gchristensen>
I've sent more mailing list emails today than I have in a loong time
<gchristensen>
PS please check my email to the ML!
<domenkozar>
could we just shut down email sending?
<domenkozar>
to me it was never useful
<domenkozar>
but maybe it is to someone?
<domenkozar>
> Eelco stopped postfix to prevent further sending.
<domenkozar>
ah :)
<MichaelRaskin>
domenkozar: I think there was a time when the mails were useful. I also thin this time has passed forever.
orivej has quit [Ping timeout: 268 seconds]
<domenkozar>
yes :)
<domenkozar>
I'm glad it was handled
<globin>
manveru: i don't think yarn2nix in its current state is too useful for larger JS apps currently, one would have to hook into yarn between yarn installing and running the post-install scripts to be able to patch dependency code
<manveru>
well, yarn2nix supports that
<manveru>
how else would you make gyp work
<globin>
manveru: I couldnt see a way, how did you manage?