<srhb>
I do hope we get a proper deprecation in (especially for 18.09) but since it's not done yet, I thing reverting is sane.
lassulus has quit [Quit: WeeChat 2.0]
lassulus has joined #nixos-dev
phreedom has quit [Remote host closed the connection]
phreedom has joined #nixos-dev
<andi->
srhb: :+1: it is probably better to do that then to wait for a "better" version at some point in the future. At least on master it is blocking a channel that might be used by people already and 18.09 should be testable while we stabilize it..
orivej has quit [Ping timeout: 252 seconds]
<andi->
The only nit-pick I do have is that we could probably keep the documentation changes (since they drop the notice of the old attributes) and if we release 18.09 like this people will have "correct" documentation.
<srhb>
andi-: Happy to remove those.
<srhb>
andi-: Done
<andi->
srhb: thanks :) Let see what other people think about it.. I am always for a working channel.
<thoughtpolice>
samueldr: I was unfortunately sick during the beginning of the month meaning I missed the merge deadline to master. But as Bas noted, it might have to go through staging, too. :(
<samueldr>
I was subscribed to the thread and making sure to follow all that
<thoughtpolice>
If it can't make it (or you and vcunat disagree) I understand. I'd still like to land it in master this week though
<samueldr>
also taking the pulse of the other nixpkgs maintainers
<thoughtpolice>
And I owe Bas a drink, sometime.
<thoughtpolice>
samueldr: Thanks for keeping track! If you think it's still possible to hit for 18.09, that'd be grand, and Bas and I can surely handle it.
<thoughtpolice>
(I get the impression they're already using this at LumiGuide, perhaps)
<thoughtpolice>
However, that all assumes a staging merge will go through to release-18.09, I guess, before the finale...
<samueldr>
I kinda feel bad special-casing this as I previously dismissed another module update for 18.09 :/
<samueldr>
(for backport post-feature-freeze)
<samueldr>
though, I know how much work, and how it's been slated for 18.09 inclusion originally
<thoughtpolice>
Mmmm, I understand. Truthfully I should have got it done much earlier, though, time is just so slim these days.
<samueldr>
that, I do understand :)
<thoughtpolice>
It's a pretty big change. I was wondering if merging it would maybe catch people by surprise. But honestly I imagine most people wouldn't even have tested this until they switched to release-18.09 anyway. (Plus it aims to be backwards compat, but there's always a chance for bugs)
<samueldr>
my biggest issue is how users using the beta 18.09 would have stateVersion 18.09 possibly mean something new... which probably isn't an issue as long as it's beta
<thoughtpolice>
IMO, I agree on that. We're waiting (at $WORK) until after the branch to migrate anywhere (we recently just went through a long migration from 17.09 to 18.03)
<thoughtpolice>
In theory I could also maintain a branch with this work (or both Bas and I could) for anyone who wants to stick on 18.09 but that is a bit of dedication...
<samueldr>
though, I'm about 90% sure the thing I said about stateVersion for 18.09 is a non-issue... it's still a huge change, don't know if anyone else here has opinions or facts
<thoughtpolice>
I think anyone using PostgreSQL would be happy about it so, maybe ask someone not using it :P
<thoughtpolice>
However, niksnut may have an opinion, since it will impact Hydra (at least in theory), which is pretty important!
<thoughtpolice>
On a side note, part of the thing that took me so long is that, like -- this branch already worked for me and I've been running it for months. So in a real sense, _my_ problems were solved, at least, hence me putting bandwidth on other topics. I'll have to take a lesson from that one.
<thoughtpolice>
In any case -- I can get things ready for a merge to staging pretty soon, at least.
<thoughtpolice>
Bas already has a version cherry-picked onto 18.09, so if an OK is given (no pressure ofc) then we have something to work with immediately to get the ball rolling, luckily.
<timokau[m]>
Does anybody know if nix works on cygwin?
<thoughtpolice>
I think Cygwin, in theory, should be able to build Nix and whatnot fine. It's "just" a C++ app. Nixpkgs is a totally different story, though there's some code scattered in there still. Support for Cygwin has sort of been on/off over the years, IIRC, so -- "it works, if it works"?
<timokau[m]>
Alright, thanks :) I'm asking because of a semi-serious discussion to replace sage's build system with nix, which would require Cygwin support.
<thoughtpolice>
Yeah, that's going to be a tough sell, unless you can dedicate (and show continued) serious maintenance power. In some limited cases like pure C++, you can probably do something like use Clang to cross-compile an MSVC/MinGW binary, using Linux/macOS based Nix, but that's also a bit of work and pretty limited in scope.
<thoughtpolice>
Personally I've said before that, I wish Nixpkgs didn't support anything other than Linux, because it's a large maintenance burden, for what's a small portion of the userbase. But in retrospect it would have been better for cases like this, too, because it would have required different platforms to carefully devise their own package sets, and that would have been healthier, long term.
<thoughtpolice>
After all, one of the main advantages of Nix is that things that work always keep working. So it seems odd that Nixpkgs has support these little "one off" platforms like Cygwin that small users care about, and stuff that constantly falls into states of disarray, when really you only need Nix, and a package set, and it will *keep working*.
<timokau[m]>
Well they currently use their own make-based packaging system, so its hard to be worse than that.
<thoughtpolice>
If there was a Nixpkgs-cygwin repository for example, presumably it would still work, more or less, even today, if you could just get Nix working. Even if nobody touched it for a long time. Instead you have to untangle/fork/mess with Nixpkgs itself, which has a huge surface area (and is in part complicated due to Linux being such a large user)
<timokau[m]>
I'm not sure what you mean by your other point
<timokau[m]>
Ah, but then everything would be horribly outdated.
<timokau[m]>
I think up-to-date with chance of breakage is better than outdated. Users can still use an old version of nixpkgs. I don't see any harm in supporting other platforms as long as it doesn't hinder me on NixOS. Specifically on platforms without their own package manager like MacOS it seems to be useful.
<thoughtpolice>
It probably wouldn't be as large either, so working it into your needs may not require such massive changes. But it's not unprecedented; Pacman for example is used for Arch Linux, and Windows MSYS2, but have completely different package sets. This is, IMO, the right way to go. The package manager can work in a lot of places. But the package set often needs to be carefully maintained and tuned for a platform.
matthewbauer has quit [Ping timeout: 264 seconds]
<copumpkin>
I'm biased but am glad we support darwin
<copumpkin>
and it's one of the main reasons I and many others I know use it even on linux
<copumpkin>
being able to get the same packages on the two platforms is huge :)
<copumpkin>
but yes, continued maintenance is key and is hard
<copumpkin>
fwiw, I don't think the darwin stuff has hindered linux folks, much, because they're always breaking our stuff :P
<copumpkin>
if we imposed some sort of "thou shalt test on darwin" rule, I could see that argument more
<thoughtpolice>
Sure, but I can do that on msys2 and arch linux as well. But the maintainers don't step on each others toes, and personally I think that's a big win. I'm often terrified of breaking macOS related packages, but OTOH it often takes disproportionate amounts of time to sort it out.
<thoughtpolice>
And even beyond macOS, there are Linux-related discussions too, like the ongoing Musl stuff... Two is fine, but once you get to 4 or 5 configurations, some things really do explode in complexity pretty hard. Maybe I'm just bitter from hitting those cases :P
<thoughtpolice>
That said it's not like I can take away macOS support! So there's no cause for alarm. But I do wonder how much sharing hurts vs not-sharing, especially when the sample size grows beyond, like, 2 major systems.
<copumpkin>
sharing has been a huge benefit to us, fwiw
<copumpkin>
probably not the other direction
<copumpkin>
no way the darwin subcommunity has the resources to package all this stuff ourselves
<timokau[m]>
I also think the work of a few bug fixes is way less than the work of completely duplicating the package set
<copumpkin>
so we do our best to be as compatible as possible and gain improvements as the linux folks put them out
<timokau[m]>
As long as there is somebody maintaining it, I don't mind
<thoughtpolice>
Yeah, and part of that is that also the core development group is still basically tiny. So sharing helps a bit more. If you crank up the number of developers and supported packages, I wonder what it'd look like... The Linux side is only "bigger" but not much bigger than "tiny".
<timokau[m]>
What would be nice sometimes would be somebody to ping when ofBorg reports darwin failures, since its currently hard to decide what to do with those
<thoughtpolice>
All that said, a lot of people seem to be motivated to do this stuff by making Nix "the one true Package Manager Everywhere", so people want Windows, and all this other stuff -- and frankly those just aren't my goals, but I admit it's admirable, so who am I to complain *that* much.
<thoughtpolice>
(And I will also absolutely admit Nix is the probably the best design you can choose, if you wanted to achieve something like that.)
<samueldr>
one of the biggest failing for darwin (for my part) is how it's almost impossible to dig into it without apple-branded hardware :(
<samueldr>
so you can't "just check"
<copumpkin>
that's something I'd love to fix, fwiw
<samueldr>
while windows (for cygwin) still isn't "just there", it's closer by being easier to virtualize :/
<copumpkin>
we have a couple of options there but both require people to put in work :)
<copumpkin>
which is the real limiting factor
<timokau[m]>
Yeah maybe we should have a sort of "darwin-maintainer" team that we could ping when necessary.
<copumpkin>
we do have that
<copumpkin>
I think literally called that actually
<timokau[m]>
At least there is a "darwin problem" label, although I don't know if anybody does triage on that.
<samueldr>
it would be interesting to see how much fixes for a BSD would also fix darwin issues, thus if it's a good goal for darwin to also try and get a BSD around
<copumpkin>
samueldr: largely not at all
<samueldr>
depends on the kind of error though AFAICT
<copumpkin>
for Nix's purposes, darwin isn't BSD
<copumpkin>
it's GNU
<samueldr>
yeah, that I gather
<timokau[m]>
Huh, thats nice to know. Is it appropriate to ping that team on minor issues like "ofBorg check for darwin fails on this issue, what should i do?"?
<samueldr>
that's why I said "interesting to see"
<copumpkin>
what I mean is that the kernel isn't a BSD kernel (mach/xnu) and the only thing that makes macOS a BSD is its userland, which we've largely completely dumped to improve compatibility with linux for the sake of nix builds
<copumpkin>
so we use gnu coreutils, findutils, etc.
<copumpkin>
same as the linux stdenv
<copumpkin>
you could call Nix-on-Darwin GNU-for-macOS
<copumpkin>
timokau[m]: sure
<clever>
something neat about the darwin kernel, is that it supports 2 sets of syscalls
<samueldr>
part of the issues may be related to linuxisms and not lack-of-darwinism?
<clever>
BSD and mach-o syscalls i believe
<clever>
one is positive ints, the other is negative
<copumpkin>
clever: really? never noticed that
<copumpkin>
you're not supposed to make syscalls yourself
<copumpkin>
they have a big doc saying "don't do it"
<copumpkin>
:P
<timokau[m]>
> lack-of-darwinism
<{^_^}>
undefined variable 'lack-of-darwinism' at (string):193:1
<clever>
copumpkin: they are probably trying to hide their shame :P
<timokau[m]>
Maybe we should just execute people that break tests?
<copumpkin>
samueldr: yes, most of them. Someone will depend on libcap on linux and that makes no sense on darwin
<copumpkin>
clever: hehe, they just don't want to commit to a syscall ABI
<copumpkin>
very deliberately
<clever>
copumpkin: also, didnt nix discover a flaw because it was directly calling a syscall to kill all processes in a uid?
<copumpkin>
Go ignores that and gets bitten by it every so often
<samueldr>
copumpkin: in that case, would any non-linux that's more readily available help?
<copumpkin>
clever: sort of
<clever>
copumpkin: and there was a lack of restrictions in the kernel, which allowed nix to kill everything
<copumpkin>
it was a race in the kernel actually
<clever>
ah
<copumpkin>
but yeah, we were doing something undocumented
<clever>
and semi-related, M$ changes syscall numbers within patches to the OS, so you cant reliably call them directly
<clever>
and at one time, M$ was doing buffer size checks, in userland
<clever>
so using the raw syscall allowed you to buffer-overflow the kernel
<copumpkin>
samueldr: not really, I don't think. Most userland tooling is GNU but there are still a few macOS-specific libraries and such, and a lot of configure scripts will do darwin-specific things if they see it in your uname
<copumpkin>
nice
<copumpkin>
xnu at least doesn't do that
<copumpkin>
it's still fairly nicely separated with basically no logic in userland
<copumpkin>
other than shuffling arguments into the right place for the ABI-du-jour
<samueldr>
doesn't that contradict this? [15:35:42] <copumpkin> samueldr: yes, most of them. Someone will depend on libcap on linux and that makes no sense on darwin
<copumpkin>
oh sorry
<copumpkin>
yes, for issues like that definitely
<thoughtpolice>
clever: To be fair, Linux has perf_events which is like, a landmine of bad shit still, probably.
<samueldr>
yeah, I do see the whole "we use our own userland so it won't help there"
<clever>
thoughtpolice: and debian considers the entire user-namespace framework to be a landmine, so they flagged it as needing root
<samueldr>
I'm thinking about guarding against introducing linuxisms and testing them without darwin
<copumpkin>
oh yes, I'd love that :)
<copumpkin>
a lot of them just fail evaluation
<thoughtpolice>
Oh yeah, lotta people do that. Arch and CentOS/RHEL at least, as well.
<copumpkin>
so that doesn't even require a working builder
<clever>
thoughtpolice: but thats more a case of just choosing to disable rather then audit
<copumpkin>
lots of assert system == "x86_64-linux"; and such
<samueldr>
what about aarch64? ;)
<copumpkin>
that's where ofborg becomes super handy
<copumpkin>
testing eval on different platforms, even without building
<LnL>
timokau[m]: I look at the labels regularly and yes feel free to ping @NixOS/darwin-maintainers, that's kind of what it's there for :)
<thoughtpolice>
Eh, system == "x86_64-linux" can mean at least 2 things, though, IMO. Some things are only 64-bit. Occasionally I mark them that way precisely because I can't get/guarantee a working macOS package, even if I speculate it will work.
<copumpkin>
just use meta.platforms then
<copumpkin>
asserts just break our stuff
<thoughtpolice>
Oh, I missed the 'assert'
<thoughtpolice>
Nevermind, then
<copumpkin>
:)
<LnL>
yeah don't use asserts for platform stuff (in almost all cases)
<copumpkin>
but yes, meta.platforms is great
<copumpkin>
lets us easily see what we might want to improve support for
<copumpkin>
and see what's expected to work where
<thoughtpolice>
Side note, but I also really wish that you could give specific reasons for why a platform doesn't work.
<samueldr>
just musing, I know it's not really plausible here, platforms could need a trinary state; where you have [WORKS, UNKNOWN, NOPE], where unknown is the default, and a system could enable unknown to verify things work, then mark on a certain platform as WORKS or NOPE
<thoughtpolice>
Like, outside of a comment.
<clever>
thoughtpolice: i recently helped somebody in #nixos that wanted a "linux only" thing on darwin, turns out it was just missing libiconv in buildInputs
<thoughtpolice>
It would be nice to just say "Really complex, will require new derivation" or "Probably easy, no macOS hardware available to the current maintainer" or "Upstream only supports 64-bit Linux"
<clever>
thoughtpolice: on linux, its provided by glibc, but on darwin, its a seperate package
<thoughtpolice>
clever: yeah, exactly
<samueldr>
or even "can't know if darwin works ¯\_(ツ)_/¯
<clever>
there is also the binary based stuff
matthewbauer has joined #nixos-dev
<clever>
ive had to repeadedly explain to one user, that you cant patch the ELF files to make them work on darwin
<thoughtpolice>
samueldr: Yeah, something like every platform triple having a tri-state sounds about right.
<thoughtpolice>
Err, well, we don't really have triples in meta.platforms. I'm thinking of autoconf :)
<samueldr>
that way you can mark as "verified for linux-x86_64", without actively neabling linux-aarch64, neither disabling it :/
<clever>
samueldr: ofborg helps here, just enable what makes sense, and wait for ofborg to complain
<samueldr>
yeah, helps, but still can't verify the thing *works*
<samueldr>
building != working
<clever>
add a working check phase
<thoughtpolice>
It doesn't help when you're *reading* it, though. ofborg is not telepathic, as far as I know.
<LnL>
samueldr: I kind of use platforms vs broken for that
<copumpkin>
we have the tests stuff now
<copumpkin>
better than checkphase supposedly, but I haven't done much with them
<copumpkin>
but I do like the three-state platforms idea
<copumpkin>
could branch on whether platforms is a list or an attrset
<LnL>
platforms are a list of attrs already
<thoughtpolice>
Like, I probably read expressions 800x more often than I look at ofborg results. So it can tell me if I need to change `meta.platforms = [ "x86_64-linux" "x86_64-darwin" ];` to remove the darwin clause (because it doesn't work), when I file the PR. But I don't know at all when I'm reading it sometime down the road why that might be the case.
matthewbauer has quit [Ping timeout: 240 seconds]
<thoughtpolice>
Complicated by the fact you often will have to follow the log/blame to get the PR or commit, since people can (and do) move/rename stuff around, breaking basic file tracking.
<copumpkin>
yeah, that's why I like the idea of multiple states
<copumpkin>
"this is known not to work, and why" vs. "never thought to try"
<simpson>
Also, more direct feedback for packages with `doCheck = false;`
<LnL>
thoughtpolice: git is smart enough to follow diffs
matthewbauer has joined #nixos-dev
<copumpkin>
if people are nice and write good commit messages :)
<copumpkin>
most of the time it's "somepackage: 1.5 -> 1.7"
<thoughtpolice>
If you use --follow or whatever, right? Which wasn't always the default (I don't even know if it is). But really, even having to do 'git log' to reverse engineer that information is already the problem, IMO, when it's very easy to just read it.
<thoughtpolice>
Even if they do write a good commit message!
<LnL>
check out git log -L
<thoughtpolice>
Which is always welcome, of course.
<timokau[m]>
I feel like we should document more stuff in comments anyways, that is the #1 thing I mention in reviews
<timokau[m]>
Often times there is a detailed analysis in the PR text but only a one-line change in the code without any comment explaining the reasons
<timokau[m]>
(#2 is probably upstreaming stuff, which we should do more of too)
<manveru>
i think it'd be nice if stuff marked as broken was built once in a while to see if it's not broken anymore :)