<aaronjanse>
I actually think it could be cool to have semgrep for Nix
<aaronjanse>
Although regex would probably get you 99% of the way there
<siraben>
The hard part would be regenerating the AST to make it as close to the original right?
<siraben>
Yeah that's how we got to where are 😂, standard unix tools are good enough for many things
<siraben>
where we are*
<aaronjanse>
Oh, rnix-parser preserves 100% of source code, so it's very easy to regenerate the exact original AST
<siraben>
Great
<aaronjanse>
Tbh it still might take less time to write a regex replacement, unless someone adds Nix support to semgrep (shouldn't be too bad?)
supersandro2000 has joined #nixos-dev
cole-h has quit [Ping timeout: 240 seconds]
<siraben>
gchristensen: coqPackages isn't cached by Hydra?
jonringer has quit [Ping timeout: 276 seconds]
<sterni>
siraben: they should (have recurseForDerivations
<sterni>
siraben: aaronjanse: you have to be careful not to convert release assets into fetchFromGitHub though, but that should be easy with parsing the url
<siraben>
sterni: I don't seem to be fetching from cache for coqPackages.fourcolor, for instance
<siraben>
And when coqPackages get rebuilt, ofborg doesn't report change
<sterni>
huh
<sterni>
ah
<sterni>
it is wrapped by lib.dontDistribute
<sterni>
I don't see why we should have that especially as it is such a small package set
evanjs has quit [Read error: Connection reset by peer]
evanjs has joined #nixos-dev
<siraben>
sterni: exactly, I think it would be good to have it cached
urkk has joined #nixos-dev
<siraben>
Maybe there's some deeper reason as to why (in case the cache gets poisoned and Falsity creeps into the Coq libraries)?
<siraben>
currently everything in coqPackages essentially have to replay all of the proofs
<sterni>
ime vbgl is a bit conservative with hydra usage, but there has to be another reason why you wouldn't want coq packages built if there are so few
<qyliss>
siraben: isn't there a warning for fetchurl with github now?
<qyliss>
I thought I got one the other day
<siraben>
qyliss: I sure hope newer packages aren't using fetchurl with github
<siraben>
but there's older packages that still do
<siraben>
I haven't grepped to see the extent of the problem
<siraben>
if we could minimize such things before 21.05 that'd be great, IMO
<qyliss>
wait what difference does it make to the release?
<siraben>
Wouldn't it necessarily cause rebuilds?
<qyliss>
not if the hash is the same
<qyliss>
which it should be
<siraben>
but IIRC fetchFromGitHub can give a different hash from fetchurl
<siraben>
or fetchTarball
<sterni>
qyliss: it won't since fetchurl hashes the archive and fetchzip / fetchFromGitHub the extracted dir
<siraben>
so some PRs might have to land in staging
<qyliss>
oh, I think I'm thinking of fetchgit/fetchFromGitHub
<sterni>
I think it isn't a big enough problem to warrant rushing it in
<siraben>
but first we should see which packages are the offenders, I suppose
<sterni>
since we cache the tarballs anyways
<siraben>
ah, right.
<qyliss>
yeah, I don't think it really mattres
<sterni>
so hash inconsistencies won't really matter to us
<siraben>
there's some instances where our cache keeps the tarball longer than upstream heh
<qyliss>
at least enough to change it treewide
<siraben>
so upstream's original URL is gone
__monty__ has joined #nixos-dev
<siraben>
I don't think vgbl's comment makes much sense
<siraben>
coqPackages is really small
<siraben>
and changes infrequently, and rebuilds are quite minimal
<supersandro2000>
unlike ocaml
<siraben>
do we also cache the ocaml package set?
<sterni>
yes
<sterni>
OCaml is also pretty small though
<sterni>
like building it completely takes like 1h on normal computers
orivej has joined #nixos-dev
<urkk>
why does clang build binaries with static libstdc++ by default?
<supersandro2000>
darwin probably uses an older clang because the newer ones require a newer sdk
<__monty__>
I'm not sure that's true. So far the only bit that I may have to update is darwin.xnu. (Which is in apple_source_releases, not technically the SDK though this distinction is muddy at best.)
<__monty__>
How do I get more information on how exactly the output is depending on that libunwind?
<sterni>
I think you can grep right?
<sterni>
__monty__: you write it isn't necessary on linux, which llvm stdenv on linux are you referring to?
<sterni>
the lldClang stdenv for example does depend on the LLVM 11 libunwind
<__monty__>
On linux libcxxabi always depends on libunwind afaict.
<sterni>
yep
<sterni>
oh yeah it should not on darwin
<__monty__>
What I mean is that on linux libcxxabi depending on libunwind doesn't cause a problem while enabling it on darwin now causes this problem. And I enabled the buildInput on darwin because I was getting a build failure about `-lunwind` not being found.
<sterni>
where exactly did that happen?
<sterni>
I don't think libc++abi should use the llvm unwinder on darwin
<jtojnar>
but we still need consensus before we change the rule
<endocrimes>
oh niice :3
<endocrimes>
lol i was backscrolled
<endocrimes>
ignore me xD
<__monty__>
sterni: Added the log for the library not found error to the gist. (😭 Why doesn't nix-store --read-log drop ansi escapes when output is piped?)
<__monty__>
I figured LLVM 11 had simply changed to always depending on LLVM libunwind.
mkaito has quit [Read error: Connection reset by peer]
<__monty__>
I'm not sure how to interpret "ofborg-eval" failing on a PR. The log doesn't make much sense to me.
<lukegb>
do you mean the bug where tabs that dynamically load don't ever load if you follow a link to the specific tab?
mkaito has joined #nixos-dev
<gchristensen>
yeah
<lukegb>
I noticed that with the charts for specific attributes as well
<sterni>
qyliss: __monty__: the eval error has something to do with testOnCross (see the locations in release-lib.nix)
justanotheruser has joined #nixos-dev
abathur has joined #nixos-dev
devhell has quit [Quit: nyaa~]
<__monty__>
sterni: Is it maybe something to prevent "regressions" in what packages are available?
<__monty__>
sterni: Did you take a look at the log I added to the gist?
mkaito has quit [Read error: Connection reset by peer]
<sterni>
__monty__: not yet, sorry, only at the eval error
<sterni>
__monty__: yeah it's really weird since the attribute itself is not really referenced anywhere at least according to a quick grep
<__monty__>
No problem.
cole-h has joined #nixos-dev
<__monty__>
I figure libcxxabi ends up with a reference so clang does and therefore stdenv does. But I don't understand why this wouldn't be alright. (I'm also still confused about the versions of libunwind, one comes with LLVM, Apple has another in apple_source_releases and then there's the non-GNU one.)
<sterni>
I'm pretty sure you should end up with apple's libunwind in this situation
<sterni>
so most likely the stdenv you are using to compile libcxxabi needs to have && find that libunwind already
<samueldr>
gchristensen: I noticed it quickly, we'd have to diff the js for the tab activation we use, and look at how this activates now
<sterni>
at least that would be my theory as to how it has worked in the past
<__monty__>
I've tried adding darwin.libunwind to the buildInputs and I got the library not found error again.
<samueldr>
AFAICT it's a generic issue with activating "lazy" tab content, and not specific to any tab
<samueldr>
not sure it `.tab('show')` would end up calling show.bs.tab
<sterni>
__monty__: if you want to use the llvm libunwind for now you have to add it to allowedRequisites in pkgs/stdenv/darwin/default.nix
<samueldr>
hmm... not even sure those "makeLazyTab" are those we've observed
<sterni>
__monty__: it's kinda intersting though that libcxxabi compiles with *just* llvm libunwind in buildInputs, ime it really didn't like it unless you passed LIBCXXABI_USE_LLVM_UNWINDER (or whatever the flag is called)
<samueldr>
gchristensen: not sure I can look into it today, I need to do other things, but initial observation makes it a flip of a coin, either it's a trivial thing from a forgotten bit in migrating to bootstrap 4, or it's something subtle with the interactions
<__monty__>
-DLIBCXXABI_USE_LLVM_UNWINDER=ON is passed in this case I believe.
orivej has quit [Ping timeout: 260 seconds]
<sterni>
__monty__: nope, stdenv.hostPlatform.useLLVM is not set for darwin (as odd as it sounds)
<sterni>
useLLVM is something which only matters for a cross toolchain being bootstrapped
<__monty__>
It is on my branch. I did so because the "standalone" argument disappeared and the flag that toggled is now behind useLLVM.
<sterni>
ah I see :)
<sterni>
oh wait a minute
<__monty__>
I guess I'll revisit that decision then.
<sterni>
I think you'll need to introduce an equivalent of standalone for llvm 11 then
<sterni>
iirc this is used in darwin stdenv bootstrapping somehow
<sterni>
at least I remember breaking darwin by some change to libc++abi which was related to that
<__monty__>
I figured useLLVM was introduced because there was a broader use for it and I didn't know how to judge which flags sholud be included.
<__monty__>
Thanks for the back and forth.
<sterni>
useLLVM is for bootstrapping a cross toolchain which uses clang instead of gcc
<sterni>
there is some crossover with darwin stdenv bootstrapping because don't have libstdc++ for example
<__monty__>
Would be nice to include "cross" in the name if it's only for cross toolchains.
<sterni>
but it's not the same entirely
orivej has joined #nixos-dev
<__monty__>
Part of it was standalone disappeared in the merge that introduced useLLVM.
<Ericson2314>
__monty__: i did end up landing my after talking to jonringer
<Ericson2314>
yeah the fact that the impure native stuff is scattered throughout the bootstrap chain is confusing
<Ericson2314>
(native parts of compiler-rt, native unwinder, etc.)
<__monty__>
Ericson2314: Will rebasing on staging bring in some fixes then?
<Ericson2314>
__monty__: I don't think so, sadly
<Ericson2314>
my PR was more about tidiness than fixing thtings
<__monty__>
Ok, np. I'll refrain then to avoid compiling LLVM again.
mkaito has joined #nixos-dev
mkaito has joined #nixos-dev
mkaito has quit [Changing host]
<hexa->
whats the recommended way of poking users they need to move from `config` to `settings` in a module?
<qyliss>
mkRenamedOptionModule
<hexa->
thx :)
<sterni>
qyliss: but that only works if the types are the same, no?
<qyliss>
then mkChangedOptionModule
<hexa->
qyliss++ sterni++
<{^_^}>
qyliss's karma got increased to 135
<{^_^}>
sterni's karma got increased to 14
<abathur>
Anyone want some glory? :) I think the merge of my installer PR lights a path to full uninstall/reinstall. I can't pursue it any time soon, but happy to discuss as needed. I wrote a proof-of-concept in Oct. that should be reheatable. Validation is also much easier since domen added installer tests.
<qyliss>
i think you're pretty limited in who actually can merge nix PRs
<qyliss>
oh, never mind lol
<qyliss>
wait no
<qyliss>
ignore me
<abathur>
I was indeed
<abathur>
:}
mkaito has quit [Read error: Connection reset by peer]
<hexa->
sterni, qyliss: if both consumed an attrset is the type relevant?
<samueldr>
a few (many) of our contributors are... what some people like to call "real smart" :)
<ris>
that looks basically like exactly what i was planning.. a harnessing of macOS-Simple-KVM
<ris>
ok so there's a shortcut
<ris>
the other part of the equation is getting nixos working on a cheap bare metal hourly instance, which is why i've been playing with phoenixnap
<jonringer>
I spent like 5 hours one day trying to get my server to use qemu to emulate macos, and just gave up. This was 4 or so months ago.
<domenkozar[m]>
oh that's what I've been wanting to do, but I was hoping someone would do it instead :D
<qyliss>
I'm hoping that when we have working BSD support that'll help with a lot of simple macOS failures
<domenkozar[m]>
(re: fastmac)
<qyliss>
I think it probably will for most non-graphical things
<domenkozar[m]>
so cool!
<domenkozar[m]>
qyliss: how will that help, I'm curious!
<qyliss>
domenkozar[m]: well, most of the core bits of macOS are still basically FreeBSD
<domenkozar[m]>
still the same code after so many years? :O
<ris>
i've generally found macos problems to fall into 3 categories: clang, toolchain/binary format nonsense, err and another one i can't remember
<qyliss>
so if you have some command line program that's trying to use Linux-specific, say, socket stuff, making it work on FreeBSD will probably also make it work on macOS
<qyliss>
or, if it's not including some header or whatever
<domenkozar[m]>
ah ok, given that we have a lot more users, it would be fair to say the other way around then :)
<samueldr>
it probably still has enough intersection that it will act as a good net to filter out a chunk of issues
<domenkozar[m]>
users on macOS*
<qyliss>
well no, because for a great many of our contributors, FreeBSD is much more accessible than macOS
<samueldr>
and is legally available to run
<qyliss>
especially since we should be able to cross-compile to it
* samueldr
doesn't need to type anything, qyliss says it better
<domenkozar[m]>
fair enough :)
<qyliss>
so somebody working on linux could just work on getting pkgsCross.x86_64-freebsd.whatever to build, and then that would probably fix it on macOS
<qyliss>
without any need to find a mac, or do silly VM trickery
<cole-h>
qyliss++
<{^_^}>
qyliss's karma got increased to 136
<jonringer>
eventually, aarch64-darwin will be hard to target. And the M1 seems to be the longterm goal for apple now
<qyliss>
it won't help for anything graphical, but it will help for the common cases of clang issues, different header files, minor libc variations, etc.
<ris>
by that point everyone sensible will have switched to linux
<ris>
...
<jonringer>
that's what I thought about windows 8....
<qyliss>
that stuff is all still basically the same on macOS and FreeBSD
<qyliss>
jonringer: wdym by hard to target?
<ris>
hmm i still have to handle a lot of dylib/otool/install_name_tool nonsense
<domenkozar[m]>
jonringer: I don't think so, aarch64 is winning the server battle too
<ris>
i suspect a h*ckintosh-on-aarch64 will be a harder prospect
<domenkozar[m]>
heh
<qyliss>
ris: VM is probably still easy though
<qyliss>
(i've fixed Darwin builds in the past by manually trying to build the software in a FreeBSD VM, fwiw. It does work!)
<ris>
"oh look our OS uses an uncodumented custom instruction"
<ris>
un doc u men ted
<ris>
undocumented
<qyliss>
oh yeah you're right about that
<qyliss>
emulating that stuff would be tricky
<ris>
though reverse-engineers get better every year
<qyliss>
and probably a lot of RE work will already be done by the people porting Linux to M1
qyliss has quit [Quit: bye]
<samueldr>
though linux people don't need to care for the undocumented "speed-up" instructions
<samueldr>
as long as the standard stuff works
<samueldr>
keyword: need :)
<samueldr>
IIRC marcan42 has made a first pass looking for instructions
qyliss has joined #nixos-dev
<qyliss>
presumably they do if they want Linux to be fast!
Profpatsch has quit [Quit: WeeChat 3.0.1]
<qyliss>
presumably they do if they want Linux to be fast!
<qyliss>
ah, yes :)
Profpatsch has joined #nixos-dev
<samueldr>
probably desire, more than need for that, but yes
orivej has quit [Ping timeout: 240 seconds]
pmy has quit [Ping timeout: 252 seconds]
pmy has joined #nixos-dev
<__monty__>
How hard is the cut-off for the freeze? (Waiting on LLVM builds when trying to hit a deadline is pain.)
<jonringer>
qyliss: I looked into getting some beefy aarch64 hardware, and it's hard to find anything that doesn't fit in a server rack
<samueldr>
(yes, because everything beefy is meant to fit in a server rack... so why would they make it so it doesn't fit? ;))
<jonringer>
IIRC, M1 also has some other proprietry items on their SOC, and may differ from what you get from other vendors. Not to mention that apple isn't the best about making hardware available (right to repair, etc)
<jonringer>
Well, I'm thinking like the threadripper equivalent of ARM, where it's just a beefy desktop
<samueldr>
the honeycomb LX2 *might* be the better not-an-SBC option available on the market
<samueldr>
but it's not "threadripper-class"
<samueldr>
jonringer: I was mostly misinterpreting what you wrote :)
<samueldr>
and yes, there is a distinct lack of "desktop class" aarch64
<jonringer>
Yes, and it makes me sad :(. Essentially you get hobby SBC, or server prebuilds, with not much in between. And if there is an offering, it's usually got a very high novelty price tag
<samueldr>
hopefully whatever is apparently coming in chrome-branded hardware with qualcomm is more towards the higher end of laptop-class hardware than the lower-end
<__monty__>
That's the problem with novelty tax, aka, novel technology tax.
<samueldr>
thing is... ARM is far from being a "novelty"... even though it seems it's being treated as either of [toy, embedded, low power, high class server]
<samueldr>
it's kind of lacking exactly one use case
<samueldr>
"desktop"
<jonringer>
It's like linux right? you find it everywhere, but the desktop :)
justanotheruser has quit [Ping timeout: 260 seconds]
<samueldr>
hopefully those fast android devices with eDP output also end up helping the "desktop" use case along the way
<__monty__>
It's still pretty much missing from the laptop class too imo. Chromebooks are a bit niche and other than those the macbooks are the first decent ARM-based ones afaik.
<jonringer>
Honestly, I think the slow move has been from OEMs not being able to ship anything other than windows. And windows story for arm is almost non-existent
<endocrimes>
A lot of ARM "desktop" boards are apparently fairly buggy too
<endocrimes>
according to the arm team at work anyway last time I asked for reccs
<jonringer>
That's one advantage that Apple has, is vertical integration. It's possible to produce the hardware, firmware, and software necessary to make everything cohesive; and doesn't rely on once of those blocking the others adoption.
<endocrimes>
jonringer: the 3990x is surprisingly "good" value for what it is, if you need it tbh
<endocrimes>
I think my next workstation is probably gonna be threadripper
<endocrimes>
(my current is a 3950x)
<samueldr>
I should have stated it, but when I said "desktop" I meant "operating system with a desktop and windows" more than "machine to put on a desktop"
<jonringer>
Yea, if you can make full use of it, it's amazing. I use it for doing nixpkgs reviews all the time
<endocrimes>
I wish there was a good arm laptop that wasn't apple silicon, I ended up buying an m1 mbp to work from parks (ssh'd into work build clusters or more realistically writing in confluence) because of the battery life
<MichaelRaskin>
samueldr: re: pretty fast Android with external monitor connection — it's annoying how Cosmo has fast charge and video-capable USB-C (with weird compatibility profile) on the same port, and charging through the other port seems to be not enough to have a positive energy balance…
<samueldr>
I hadn't realized planet computer hardware did video out
<jonringer>
I was in the same boat... m1 is really tempting for me as well. But chose to buy a pure AMD one, most because they are more linux friendly, and I'm tired of dealing with linux nvidia drivers.
<samueldr>
anyone wanting ARM on laptop probably wants to wait a few months until more details are known about the newest chrome-branded batch of ARM hardware
<jonringer>
Which normally isn't too bad with nixpkgs: drivers get installed before I boot. But still get some weird behaviors because of nvidia.
<samueldr>
not saying it'll be good. I have no idea... but it's something fresh
<MichaelRaskin>
samueldr: they kind of do, and probably well enough for a 60-minute presentation if better options are not available, but not well enough to say «scratch that I just work on my Cosmo»
<samueldr>
huh, apparently there's been one released in january?? *looks*
* colemickens
bought an awesome looking amd (integrated graphics) laptop from aliexpress and couldn't be more excited after having no laptop for 13 months