<pie_>
can we add a flag to build-vm to just start the VM when it's done
prusnak_ has joined #nixos-dev
prusnak has quit [Ping timeout: 240 seconds]
prusnak_ is now known as prusnak
FRidh has joined #nixos-dev
<siraben>
When's ZHF starting?
orivej has joined #nixos-dev
jonringer has quit [Ping timeout: 240 seconds]
AlwaysLivid has joined #nixos-dev
STERNI is now known as sterni
kini has quit [Remote host closed the connection]
kini has joined #nixos-dev
FLOKLI is now known as flokli
orivej has quit [Ping timeout: 264 seconds]
orivej has joined #nixos-dev
<sterni>
> builtins.deepSeq libglvnd {}
<{^_^}>
anonymous function at /var/lib/nixbot/nixpkgs/master/repo/pkgs/build-support/fetchurl/boot.nix:5:1 called with unexpected argument 'hash', at /var/lib/nixbot/nixpkgs/master/repo/pkgs/development/inter...
<sterni>
libglvnd for some reason has a meson with fetchPypi using fetchurlBoot?
ris has joined #nixos-dev
teto has joined #nixos-dev
<yorick>
srk: may?
<yorick>
siraben:^*
<sterni>
nvm what I said earlier
<sterni>
the ofborg check deepSeq meta.licenses probably and I had a derivation in there accidentally :p
<siraben>
yorick: oh i thought it would be earlier pre-release.
<yorick>
siraben: maybe april at best
<siraben>
I'm going to do another programmatic Nixpkgs query for packages with low dep count but don't have macOS added
<siraben>
probably would be able to get another 100 packages enabled
<yorick>
siraben: toposort, enable macos, try to build, cull dependents of failures
<siraben>
yorick: yeah but how to toposort all of nixpkgs
<yorick>
siraben: instantiate, run drvs though nix-store -q --json
<yorick>
hm, maybe show-derivation instead
<yorick>
oh, it's called nix path-info
<siraben>
instantiate nixpkgs?
<yorick>
of course, this shows you the deps on your current system
<siraben>
not for a specific package but for everything
<siraben>
I might try that approach in the future yeah, would be more precise
<yorick>
siraben: yeah, something like what hydra does
<yorick>
you may need to download more ram
<siraben>
currently lots of blunt tools and CLI grepping heh
<siraben>
`nix-env -f . -qaP --json --out-path` works
mkaito has joined #nixos-dev
mkaito has joined #nixos-dev
<sterni>
siraben: nope, doesn't include outpaths
<sterni>
siraben: without --json it does
<sterni>
gchristensen: can I bother you for your thoughts on a somewhat hydra-related (as in getting hydra to do what we want) nixpkgs PR?
<gchristensen>
worth a shot :)
<sterni>
gchristensen: in #115246 we want to get ofborg && hydra to evaluate all ocamlPackages sets mainly, but also building all of them isn't really worth it
<gchristensen>
ah, we can't really evaluate and not build
<sterni>
gchristensen: I've pushed a hack setting hydraPlatforms = [] for everything but recursing into attrs, but I'm not sure if that is a good idea
<gchristensen>
oh hrm I guess that is an option
<sterni>
gchristensen: because hydra probably never builds a derivaton if hydraPlatforms = [];?
<gchristensen>
why don't you want hydra to build them?
<sterni>
gchristensen: the problem is we would reexpose some of those packages in all-packages and have some packages from all-packages depend on them and then those should be built
<sterni>
well I wouldn't be opposed to that, but some people in the thread seem to be of the opinion we don't have the capacity or it's not worth it
<sterni>
vbgl makes a valid point however, the older ocamlPackages sets see a lot of broken builds we don't really can or want to fix
<sterni>
which would generate unnecessary hydra noise I guess
<gchristensen>
ah
<sterni>
otoh this could get us the feedback to mark them as broken properly
<gchristensen>
that never happesn :P
<sterni>
which could potentially save users time if there are any
<gchristensen>
are ocaml packages typically fast to build individually?
<symphorien[m]>
Yes
<sterni>
yeah it's not too bad, really good in comparison to haskellPackages
<sterni>
*but* we don't have the compilers built
<sterni>
which is a real issue
<sterni>
when you want to build an older ocamlpackage for many of the sets you need to wait around for the compiler
<sterni>
that could be fixed by exposing them on the top-level
<gchristensen>
right, probably should at least build the compilers
<sterni>
but it would be cleaner if we could keep them in their sets
<sterni>
indeed
<sterni>
but that doesn't seem to be possible
<gchristensen>
if we only build the packge set on the latest compiler, how many isthat?
<siraben>
sterni: ok I did it without json and not sure what to make of it
<sterni>
nix-env -qaP -f . -A ocamlPackages | wc -l
<sterni>
616
<sterni>
gchristensen: ^
<gchristensen>
how many older compilers do we have, and do we really need them?
<sterni>
gchristensen: 13 unfortunately
<sterni>
gchristensen: we definitely wouldn't need all sets
<gchristensen>
we can't possibly* need all those (* probably)
<sterni>
all compilers also very unlikely
<gchristensen>
we should probably drop as many as are no longer maintained upstream
<gchristensen>
erm, any that aren't maintained upstream*
<sterni>
there are some pretty old sets still referenced from all-packages.nix
<sterni>
maybe I should make an effort first to try to update these packages so they don't depend on the older compilers
<sterni>
the problem is that legacy versions of ocaml still seem to be used
<sterni>
as the updates do change the language etc etc
<gchristensen>
right
<gchristensen>
importantly, though, nixpkgs shouldn't carry around old software without a highly compelling reason. users of old compilers can get old copies of nixpkgs, or re-package the expression themselves
<gchristensen>
anyway, I think this is the answer: build all of the packages and all of the compilers, but stop carrying around so many compilers
<sterni>
I'll talk to vbgl
<sterni>
I'm interested to hear what they think, it's always a bit of guessing because they are not active on irc so I only interact via github
<sterni>
but they care more about maintenance of some “legacy” stuff than I do for example
<gchristensen>
I could comment ^ if you'd like me to
<sterni>
but the OCaml community is more fragmented than others I feel like and not everyone jumps on the new stuff straight away maybe?
<sterni>
gchristensen: sure why not
<sterni>
gchristensen: btw do you know the answer to my earlier question? what happens if hydra is building a package and then finds a dependency of that package with hydraPlatforms = [];?
<gchristensen>
hydra itself doesn't know about hydraplatforms, so I imagine this is just a filter for top levelattributes and not any sort of thing preventing the derivation from being realized
<gchristensen>
so, should be fine
mkaito has quit [Quit: WeeChat 3.1]
<sterni>
okay well then the hack shouldn't be *that* bad actually
<gchristensen>
sterni: maybe the hack would be fine, but I'm fairly sure it isn't the solution here
AlwaysLivid has quit [Ping timeout: 268 seconds]
<sterni>
yeah I also don't like it for the reasons lied out in the comments below
<sterni>
the big problem is that the OCaml releases are often backwards incompatible in a significant way and not all maintainers release stuff which works with the new compilers right away
<gchristensen>
yeah
<gchristensen>
understood
<gchristensen>
also, 4+years of "not right away" it may be time to consider it abandonware
<sterni>
well there is stuff with releases from last year which doesn't really work with recent compilers I am finding out :|
<gchristensen>
might be time to remove those too :)
<symphorien[m]>
I use ocaml 4.07 at work and it's not abandonware :(
<supersandro2000>
> I use X at work
<{^_^}>
undefined variable 'I' at (string):492:1
<supersandro2000>
well, I know projects that use python 3.4 which is abondand
<supersandro2000>
at work
<symphorien[m]>
sure, it's a token of interest, not of intrinsic worth to keep
<supersandro2000>
well at least ocaml 4.07 is only 3 years old
<symphorien[m]>
oh I would have thought it was older :° it definitely feels old when coding :þ
<ekleog>
What about python2? (a)
<gchristensen>
yeah, it should absolutely be removed
<gchristensen>
which is afaik in progress
<ekleog>
Sorry, let me reword as in: the projects had like 10 years to switch to python3 and up until very recently some major non-abandonware ones hadn't yet
<gchristensen>
sure
<gchristensen>
I stand by this: 13:48 <gchristensen> importantly, though, nixpkgs shouldn't carry around old software without a highly compelling reason.
<ekleog>
oh yes totally, I had stopped going up the backlog at the hydra discussion, sorry for having missed it :)
<supersandro2000>
when we get nixops 2.0 in we can start to throw out more python 2 :P
jonringer has joined #nixos-dev
teto has quit [Ping timeout: 240 seconds]
cole-h has joined #nixos-dev
AlwaysLivid has joined #nixos-dev
__monty__ has joined #nixos-dev
<siraben>
gchristensen: what about old software written in C, say. Purge them too?
<siraben>
Or just in languages that no longer are updated?
<gchristensen>
ocaml has new releases, and we don't package very old compilers for C either
<gchristensen>
(or maybe we do have old compilers, but probably not many old versions of the same compiler)
<gchristensen>
I feel your question is trying to be a bit of a gotcha question and I don't think it makes sense
AlwaysLivid has quit [Ping timeout: 268 seconds]
<ajs124>
while I'm all for deleting old software, we do actually have what I would say are "very old C compilers"
<ajs124>
as in, nixpkgs has gcc 4.8, which was initially released in 2013 and 4.8.5 is from 2015
<ajs124>
we also have gcc 4.9, 6, 7, 8, 9 and 10
<ajs124>
(where 10 is the current version)
<gchristensen>
sounds ripe for pruning :)
<__monty__>
I do hope there's a distinction between stable and just old.
<gchristensen>
"supported"
rajivr has quit [Quit: Connection closed for inactivity]
<ajs124>
sadly, I think it's not that easy in the case of gcc. Although we can obviously never be sure if we don't try.
<ajs124>
I seem to remember samueldr saying that gcc 4.x is still needed for mobile nixos, e.g.
<samueldr>
removing older compilers will be harmful to external users of NixOS not *only* Mobile NixOS IIRC
<samueldr>
(from the last time it was brought forward)
<samueldr>
though I don't remember what other external Nixpkgs users
supersandro2000 has joined #nixos-dev
<ajs124>
I think we use gcc 9 in bbb4nix, right now, to compile the kurento-media-server, but I also seem to remember that somebody actually fixed that with gcc 10 upstream.
<supersandro2000>
I would just mark them as insecure if they are and if they are for long enough start a removal on notice
<samueldr>
are they insecure?
<gchristensen>
btw I'm not saying we should rush to remove them or clean things up
<gchristensen>
and supersandro2000 it might be good for someone else to take the initiative on this one ;)
<samueldr>
it's, yet again, the old issue of Nixpkgs' public API...
<samueldr>
many individuals who want to (for good reasons even) clean Nixpkgs forget that it's not strictly an insulated for-internal-use-only list of software
<samueldr>
any changes in the API will break things for users *outside* of Nixpkgs
<samueldr>
and what's worse, is that many of these users won't know it is broken until the next stable release
<ajs124>
that's exactly why we have our hydra track unstable and release when building all our systems, so we can at least catch that kind of error early
<supersandro2000>
nixpkgs has no public API
<samueldr>
yes it has
<supersandro2000>
no, it hasn't
<samueldr>
then when is pkgs.*?
<samueldr>
what*
<samueldr>
it's not a *defined* API, but it is the de factor public API
<samueldr>
otherwise we'd better start locking all of this in ways external users can't use all of the things
<samueldr>
because it's setting unrealistic expectations
<supersandro2000>
the beauty is you can use it even if you shouldn't
<samueldr>
...
<supersandro2000>
which also means if you use some not defined "API" it might break at some point
<samueldr>
great advertising!
<samueldr>
we'll put that in the marketing
<supersandro2000>
I am not a marketing person. I tell you the sad truth.
<samueldr>
I really don't get your point
<supersandro2000>
there is no defined API which the project promises to keep compatible.
<supersandro2000>
so there might be breakages and things might not eval
<supersandro2000>
which is always better than when things silently break
<samueldr>
yeah, that's the reality we observe... except there is a de facto API that is used publicly... so breaking it shouldn't be taken lightly
<supersandro2000>
there might be ways to improve this in the future but they would be way beyond my current knowledge to suggest
<supersandro2000>
but it is so very easy to break it in some unforeseen way for someone out there which no one can really estimate when reviewing
<gchristensen>
right, we need to respect the users when changing it. it isn't about perfection, but consideration. we don't want to break the api too much or users will either get stuck on ancient versions or stop using it
<supersandro2000>
yeah, wo don't need to change things just to change things
<samueldr>
until quite recently, Nixpkgs was what I would call at the opposite end of the spectrum to "move fast break things"... but I feel in the recent months *something* happened that made it rush toward that end
<samueldr>
I don't know what changed, if anything... maybe also specificially what I end up using
<supersandro2000>
but sometimes you want to change something to prevent spaghetti and clean things up. This can always break something somewhere and this shouldn't old us up if the benefit is bigger.
<samueldr>
we need to bring in better testing for those "if the benefit is bigger"
<gchristensen>
I generally agree with that supersandro2000, though doing many clean ups in one release can add up to be an extremely significant barrier
<samueldr>
I'm actually concerned about the reception of 21.05 with some segment of users given the issues I had in the past few months
<supersandro2000>
How should I test if someone home-configuration breaks?
<samueldr>
we can't... but I've seen a few changes that outright were not tested or else obvious issues would have been found with cross-compilation
<supersandro2000>
cross is not as good tested and ofborg does not check it.
<samueldr>
or one that changed an eval-time-only API, without deprecation warnings or explanatory errors
<supersandro2000>
The best fix for that we have right now is to add strictDeps when you fixed it once
<samueldr>
sure, except that the change was *explicitly* about cross
<supersandro2000>
its not great but better than nothing IMO
<samueldr>
yet it went in without having tested that it didn't regress basic things
<supersandro2000>
and about 21.05: if someone comes up with an issue and we obviously missed something like an alias or aliases for python in general then we can fix that afterwards
<samueldr>
but yes "there's no testing for it"
<samueldr>
I'm working on testing for cross things so we'll be able to catch more regressions
<supersandro2000>
thats awesome to hear
<supersandro2000>
for aliases ofborg could compare if packages are missing
<supersandro2000>
but for pythonPackages the issue is not new and aliases get maybe introduced before 21.05
<gchristensen>
practically speaking we need to care more than our automatic testing can test, because there is no test for upgrade experience
<samueldr>
but breakage is not always about alias of packages... anyway I don't have a clear idea of what the actual issues there will be at fork time
<samueldr>
but I'm actually concerned... hopefully I'm concerned for nothing
<supersandro2000>
and I personally think that an eval error is not nice and we should avoid it as much as possible but it is nicer than what happened when cryptography required rust
<supersandro2000>
I was also affected and it took me half a workday to fix the python pipelines that broke by that
<samueldr>
supersandro2000: "eval error" does that include throws?
<supersandro2000>
I think so
<samueldr>
because well-written throws are nice imo
<samueldr>
it's a controlled failure
<supersandro2000>
yeah and we need something like that if we can't auto fix it
<samueldr>
it points you (hopefully) to a specific reason why it fails rather than a vague "code broke!"
<supersandro2000>
and tell people what happened and how they can fix it
<supersandro2000>
and if you have a clear idea what an issue can be we need to think about it and see if we can fix it
<supersandro2000>
or we need to write it into the release notes
<supersandro2000>
or maybe even revert the change if it turned out to be not so great idea
<gchristensen>
I don't know more what to say beyond, we need to care for and respect the users, and keep their own expressions at least somewhat in mind when making major changes
<samueldr>
running in a VM, I think, on top of a Linux kernel
<samueldr>
but actual mac hardware
<ris>
for legal reasons?
<samueldr>
¯\_(ツ)_/¯ I don't know :)
<ris>
guess it explains why it's always lagged in power
<ris>
i was giving thought to stopping using the actual mac i have access to for personal PR reviewing because it's a PITA and wondering whether a cloud-bare-metal machine would be less painful - but of course most bare metal machines are either huge (aws) or by-the-month (rather than by the hour as i'd use it)
<supersandro2000>
could someone take a look at https://github.com/NixOS/nixpkgs/pull/114628? It is a rather complex compiler and I am not sure if there are some common mistakes still in it.
<sterni>
anyway I can distinguish libcxxStdenv etc. from other stdenvs?
<symphorien[m]>
> stdenv.cc.cc.lib.pname
<{^_^}>
"gcc"
<symphorien[m]>
> libcxxStdenv.cc.cc.lib.pname
<{^_^}>
"clang"
<sterni>
> llvmPackages.stdenv.cc.cc.lib.pname
<{^_^}>
"clang"
<sterni>
some of the clang stdenvs use libc++ from gcc I think
<sterni>
since there is llvmPackages.stdenv and llvmPackages.libcxxStdenv I'd think at least?
<symphorien[m]>
Hum, unfortunate
<sterni>
haven't tried yet, would have to check maybe they all use it
<sterni>
also the darwin stdenv
<ekleog>
Random long-shot thought while reviewing a sane update: we currently don't have any setup that'd allow us to automatically test this kind of PRs. Do we have a place to which we could ship printers, computers with graphics cards and the like, to make it possible to automatically test this kind of PRs?
<ekleog>
(my bet would be “no and it's ok we have many other things we should automatically test before that”, but OTOH it's also stuff that individual maintainers basically can't test themselves at home, exactly because it requires special hardware)
<samueldr>
hmmm
<samueldr>
virtual scanners for QEMU when?
<ekleog>
I don't think that it'd solve the issue that well, at least unless it actually exercises code paths in the various backend drivers
<ekleog>
though it'd probably already help with testing sane itself, but I'd guess sane itself does have a dummy scanner backend probably?
FRidh has quit [Quit: Konversation terminated!]
<gchristensen>
ekleog: I've got a small setup of computers here that I try boot-installing nixos on, maybe extending it to printers and scanners could b edone :P
<ekleog>
ooh that sounds awesome :D
<gchristensen>
I wanted to automate it with Intel ME but never figured out the magic bits to do so
<ekleog>
for the printing side of things I'm kind of worried because paper & ink mean that there's a recurring maintenance cost, plus it needs a camera to be able to check that it printed correctly, so it could only happen as a manually-handled build box I guess
<gchristensen>
test printing and scanning in the same go? :)
<gchristensen>
printer that outputs directly to as canner
<ekleog>
ooh it could work with feeder scanners I guess
<ekleog>
would probably require some mechanical fiddling with the printer so it falls in the right place of the scanner