<gchristensen>
I swear I wrote a tool to help me fix these
<gchristensen>
I would like to put a $100 bounty on "nixops, but for nix-darwin"
<shlevy>
gchristensen: Just support the musl work and we can just cross-compile for darwin :P
<gchristensen>
it isn't the compiling, its the activation and service management
<gchristensen>
which makes the macs really annoying to admin
<shlevy>
gchristensen: Right, but if you cross-compile to macs you never have to *run* them
<gchristensen>
haha
<gchristensen>
you wish
<shlevy>
OK, strange... I wonder if the long-running build is plugging up the queue somehow? Or if staging shares have some kind of starvation? nixpkgs:trunk has completely built but other stuff's been hanging around unbuilt for up to a week...
<shlevy>
niksnut: How hard would it be to make a "really super seriously abort build" button that would kill the remote connection? :P
<gchristensen>
it'd be pretty annoying I think
<shlevy>
What's our backwards compat policy for nixpkgs by the way? e.g. am I allowed to have stdenv depending on structuredAttrs by 18.07?
<gchristensen>
the mac builds should be fixed now
<shlevy>
Thanks!
<shlevy>
Very odd to me that only one build is running right now
<shlevy>
Only 24k backlog...
<gchristensen>
hmm
<gchristensen>
erm, the strangest thing to me is that it is building on hydra itself
<gchristensen>
maybe a network problem caused hydra to give up on all the remotes for a while
<shlevy>
It seems suspiciously timed relative to the job you killed
<shlevy>
I mean, the job was hanging on networking
<gchristensen>
yep
<shlevy>
But it shouldn't have hogged the whole pipe :o
<gchristensen>
nopew
<gchristensen>
well maybe
<gchristensen>
but AWS did have (they claim minor, so probably the entire DC fell off the net) network issues today according to their dashboard,
<shlevy>
Outage wouldn't have affected routes to e.g. Wendy, right?
<gchristensen>
I don't know :/
pie__ has joined #nixos-dev
pie___ has quit [Ping timeout: 260 seconds]
<samueldr>
let's say I wanted to help triage (mainly older) issues for nixos-homepage, would replying with a comment explaining why it can be closed correct?
yorick has quit [Ping timeout: 256 seconds]
<shlevy>
Think I have a solution for ssh-ng as a build-remote... But it's not pretty :(
<gchristensen>
samueldr: can't hurt :)
jtojnar has quit [Quit: jtojnar]
jtojnar has joined #nixos-dev
jtojnar has quit [Remote host closed the connection]
<fpletz>
so my suggestion would be some time this week probably… vcunat? :)
<fpletz>
ekleog: I was hoping for more reviews on that PR
<vcunat>
I was thinking we might branch now, and cherry-pick smaller regressions later
<vcunat>
(like the upgrade-path problem)
<vcunat>
fpletz: do we know any other "18.03 blocker" that's missing from master?
<fpletz>
vcunat: is the remainig problem only iso generation? with you part-revert at least regular nixos system should be fine, right?
<fpletz>
vcunat: I was going through the PRs on the weekend and didn't find anything else that might delay the branchoff at least :)
<vcunat>
fpletz: well, I know little around that issue, unfortunately.
<vcunat>
I still want to look into a libGL mass-rename before branch-point https://github.com/NixOS/nixpkgs/pull/34461 as it seems best to do it close before branching to minimize conflicts during the whole release cycle.
<vcunat>
:-D taking holidays to do what most would call work.
<__Sander__>
hehe :D
<vcunat>
Wait, I thought NixOS is important for your work. (Contrary to mine.)
<vcunat>
That's even stranger.
<__Sander__>
well, we do use Nix-related solutions
<__Sander__>
but
<__Sander__>
I can only focus myself on the specific areas that my employer considers to be important for them
<vcunat>
Right, I understand the focus. I meant Frank this time, as I thought the company runs some production stuff on NixOS releases, but maybe I was mistaken.
<vcunat>
But even there, they would surely use only a tiny subset of packages, so it actually makes the same sense.
goibhniu1 is now known as goibhniu
<niksnut>
the closure size of my system has increased by over a gigabyte going from 17.09 to 18.03 :-|
<vcunat>
Hehe, should we add closure-size decreases for ZHF?
<niksnut>
maybe we should make the NixOS tests require that there are no -dev paths in the VM closures
<vcunat>
I'd rather hardcode some closure-size limits into them.
<vcunat>
Perhaps as a separate set of closure-size tests.
<vcunat>
Or both approaches. -dev will get reasonably recognized only by pattern matching on the name, right?
<vcunat>
Setting the size values might be even more fragile, but I think it's bearable for _this_ kind of tests to be hacky.
* vcunat
is trying to get a nixos-unstable bump today to avoid the nix-2.0 upgrade problems.
<niksnut>
vcunat: yeah, a closure size limit would also be nice, but more fragile
<pierron>
niksnut: callPackage is lightly better as you can lookup the environment in which these names are solved from.
<niksnut>
I'm not really seeing the difference
<shlevy>
I kind of worry that "include" without extensible attrsets will be strictly worse than the status quo... and with it it can be implemented in library code
<niksnut>
here you can also lookup the environment (namely, it's "pkgs" in this case)
<vcunat>
well, over the long term, I would like to get rid of most significant code in all-packages.nix
<vcunat>
and e.g. do the callPackage stuff inside the per-package expressions
<copumpkin>
is that include like an importScoped?
<copumpkin>
erm, scopedImport :)
<niksnut>
I would argue that any use of library code indicates a failure/insufficiency of Nix as a DSL
<copumpkin>
eh, I much prefer a fairly minimal set of building blocks that allow us to compose them nicely
<copumpkin>
than a DSL that predicts every possible use case and include a special construct for it
<copumpkin>
(it's about smoothness of experience when you do something the DSL author didn't predict)
<vcunat>
yes, I agree we don't need everything inside the language proper
<copumpkin>
so in that sense, I think you did a pretty good job with Nix the DSL so far :P
<niksnut>
then you should use a general-purpose language (e.g. scheme ;-)
<copumpkin>
eh, I don't want that much power :)
<copumpkin>
the lack of arbitrary effects is a big draw for me to Nix
<vcunat>
:-D
<copumpkin>
Haskell would sort of fit my needs, but I still don't know how to type nixpkgs properly, so Nix is perfect
<niksnut>
or dhall
<vcunat>
It seems common that a standard library is "part of language" but written in the language and almost-normally imported.
<vcunat>
(e.g Haskell's prelude)
<copumpkin>
but it's sort of the framework vs. library distinction
<copumpkin>
frameworks seem to (in common parlance) be precomposed lumps of "we make one use case extremely easy, but woe be anyone who attempts to deviate from the endorsed path"
pie__ has quit [Ping timeout: 265 seconds]
<copumpkin>
and I generally don't like that approach, because I generally try to do weird things
<shlevy>
I think using library code in core places is fine. If it's littered throughout normal code then it's maybe a smell your L isn't DS enough, but I think it's case-by-case.
<shlevy>
Putting it another way: A "language" is made up of both core language features and standard library idioms. If you can push things into a library instead of core features without sacrificing expressiveness or ease of use in the common case, great!
<shlevy>
memcpy is a fundamental operation in the domain of "mucking about directly with heap memory", but doesn't need to be provided as a C builtin.
ocharles has quit [Ping timeout: 276 seconds]
globin_ has quit [Ping timeout: 276 seconds]
pbogdan has quit [Ping timeout: 276 seconds]
globin_ has joined #nixos-dev
ocharles has joined #nixos-dev
pbogdan has joined #nixos-dev
ma27 has joined #nixos-dev
<niksnut>
actually sacrificing expressiveness might be a good thing
<niksnut>
the problem with expressiveness (i.e. functions) is that everybody invents their own abstractions
<niksnut>
so potentially every Nix expression looks different
<niksnut>
and is therefore harder to understand for someone unfamiliar with some particular abstraction
<niksnut>
whereas, say, every RPM spec file has the same structure
<gchristensen>
RPM specs have their own invented abstractions based on m4 where if you're unfamiliar with the territory you're hopelessly lost
<gchristensen>
and having to deal with m4 :P
<sorear>
rpm does not use m4
<gchristensen>
hmm you sure? I could have sworn I was dealing with m4.
<vcunat>
I don't find RPM specs readable, for more complicated packages.
<contrapumpkin>
sorear: whoa, are you the mystical old haskeller sorear?
<vcunat>
Those I've seen were way too long, lots of lines in a single file.
<sorear>
rpm has a baroque macro language of its own, I have no idea if it's m4-derived (although it's visually closer to cpp) but it doesn't use m4 today
<niksnut>
I thought it only has variables
<sorear>
contrapumpkin: I was a #haskell person ca 2007, do I have a reputation
<contrapumpkin>
yes :)
<niksnut>
but in any case m4 is a great example of the danger of adding programmability :-)
<contrapumpkin>
JSON for all!
<gchristensen>
the challenge is perhaps not strictly how to limit expressiveness, but how to guide the various pieces of nixpkgs in to developing a common method of getting the job done
<shlevy>
niksnut: I mean sacrificing expressiveness relative to an in-language version of the feature
<vcunat>
Macro languages :-(
<Dezgeg>
how about GNU make?
<Dezgeg>
as a dangerous example :)
<vcunat>
Rings a bell - my work project has everything in gnu-makefiles + pkg-config (instead of autotools or such), and it's a nice mess.
<contrapumpkin>
I like to run M4 over CPP over C++ for maximum fun
<shlevy>
Anyway, as far as I can tell we haven't had a fundamental change in the mkDerivation/callPackage paradigm in a *very* long time. At least as long as I've been around I think. Before implementing new language features I think we can and should try out the new interfaces in the existing language so we can make sure it actually gives us what we want
<gchristensen>
let's all just go back to a time when computers were programmed via needle and wire. no package management problems then.
<shlevy>
(yes, even if the new interface requires hacks like mkIf for the time being)
<Profpatsch>
Or wait, let’s back up the database firs.
<gchristensen>
good luck
vcunat has joined #nixos-dev
mbrgm has joined #nixos-dev
__Sander__ has quit [Quit: Konversation terminated!]
pie__ has joined #nixos-dev
pxc has joined #nixos-dev
<dtz>
anyone observing Nix 2.0 being more or less incapable of functioning within a docker container? Trying with lnl7/nix or nixos/nix as the base, grabbing nixUnstable from nixos-unstable, but then many builds just.... hang? :(
<dtz>
no worries if not, still some env problems to sort out but thought I'd ask since it's strange
<LnL>
I'm using a horrible fork of that container with nixUnstable at work
<dtz>
maybe docker is being silly, for example :).
<dtz>
okay, good to know ty sir
jtojnar has quit [Quit: jtojnar]
<LnL>
release-18.03 \o/
<LnL>
it 2.0 in nixpkgs-unstable yet?
<fpletz>
LnL: yeah!
<fpletz>
oh, nixpkgs… not sure, but probably
<fpletz>
it is in nixos-unstable :)
<LnL>
let me check again if I can create a new image
<Profpatsch>
I’m on 2.0!
<Profpatsch>
*party*
<Profpatsch>
> man nix
<Profpatsch>
No manual entry for nix
<sonarpulse>
Profpatsch: I was thinking the same
<Profpatsch>
man nix build links to the nix-build manpage.
<Profpatsch>
Sonarpulse: But what should be in the manpage?
<Profpatsch>
just typing nix returns an alphabetically sorted list of all commends.
<Profpatsch>
*ands
<Profpatsch>
So maybe the manpage can group them a bit more?
<Profpatsch>
For full documentation, run 'man nix' or 'man nix-<COMMAND>'.
<Profpatsch>
hehe
<sonarpulse>
Profpatsch: oh I didn't know it worked with spaces
<sonarpulse>
c.f. git manpages
<sonarpulse>
also c.f. `man git`
<Profpatsch>
Sonarpulse: That seems to be a man feature.
<Profpatsch>
With docker it works as well, but only one level deep.
<Profpatsch>
man docker container works, but man docker container inspect fails
<sonarpulse>
lol
<sonarpulse>
lazy docker
<samueldr>
isn't that like `man 5 something`?
<Profpatsch>
IP works for
<Profpatsch>
ip a, ip ad, ip addr, ip address …
<Profpatsch>
Interesting.
<Profpatsch>
So it must be program-directed
<samueldr>
hmmm, for `ip addr` I see "No manual entry for addr"
<samueldr>
though, it loads the manpage for `ip`
<Profpatsch>
Ah, I didn’t look close enough.
<Profpatsch>
So it seems to be a man feature after all.
<samueldr>
though, it seems to work with git and docker
* samueldr
is interested
<samueldr>
I've been working off and on (mostly off) on a manpage thing for nix
<samueldr>
By default, man will try to interpret pairs of manual page names given on the command line as equivalent to a single manual page name containing a hyphen or an underscore. This supports the common pattern of programs that implement a number of subcommands, allowing them to provide manual pages for each that can be accessed using similar syntax as would be used to invoke the subcommands themselves. For example:
<Profpatsch>
samueldr: ^
<dtz>
LnL: if you do revisit that docker container, consider installing things like 'gzip' and such so it can unpack channels and such :)
<LnL>
euh, nix-channel works doesn't it?
<fpletz>
vcunat: regarding backporting stuff to the release-18.03 branch: globin and me maintained a release-review branch where we pushed the state of master we reviewed and backported if needed
<fpletz>
do you want to do the same to share the workload or go through all the commits? :)
<vcunat>
Share it :-)
<vcunat>
Probably the same workflow, if it seemed good to you.
<vcunat>
At least from the start, and we'll see.
<fpletz>
worked well for me, open for suggestions though… the branch is basically a marker
<Profpatsch>
We really need a linter that does stuff like test the rewrite to https and propose that.
<Profpatsch>
nix build --lint hello
<Profpatsch>
> you are missing a license
<gchristensen>
like nixpkgs-lint
<Profpatsch>
> The homepage can also be reached by https
<Profpatsch>
> it looks like you produce docs. please add a "man" output and a "doc" output
<Profpatsch>
> Your "doc" output references "out" in this file:
<Profpatsch>
That’s only from the top of my head. :)
<Profpatsch>
nixpkgs-lint is very arcane. It uses the package name for example, and tries to work on all of nixpkgs by default.
<gchristensen>
`like `
<Profpatsch>
Which probably was a good idea when nixpkgs still had a few hundred derivations. :)
<symphorien>
This could go into nox-review
<Profpatsch>
symphorien: Hm, I’d suggest a separate tool that can be integrated into nox.
<Profpatsch>
But yeah, something like that.
<Profpatsch>
So much to do, so little time.
<vcunat>
yeah :-)
MichaelRaskin has joined #nixos-dev
<sonarpulse>
shlevy: said this in nixos-aarch64 but you are not there
<sonarpulse>
I started looking at https://github.com/NixOS/nixpkgs/pull/34444, and tl;dr there is misc rebuilds that I think are best fixed by starting to do the lib.optionalDep thing
<sonarpulse>
shlevy: also pkgs/development/interpreters/guile/1.8.nix is unchanged?
<sonarpulse>
it is the last selfNativeBuildInput
<shlevy>
Sonarpulse: Should I join that channel?
<shlevy>
I don't have any aarch64 :D
<sonarpulse>
shlevy: well, I separately wonder if we are leaning towards too many channels
<shlevy>
:D
<sonarpulse>
when cross-cutting stuff like that comes up a lot
<shlevy>
Yeah. I think #nixos-dev is fine
<sonarpulse>
(I was responding in there, would definitely start the discussion here)
<shlevy>
Anyway, I want to write up my ideas for the interface of the new clean cross-compilation interface, which includes the optionalDep thing
<shlevy>
But it's kind of orthogonal to what we do on the existing infra,if you want to get something in soon
<shlevy>
(AFK for a bit, will see when I get back)
MichaelRaskin has quit [Ping timeout: 248 seconds]
<sonarpulse>
shlevy: also, sorry, but I'd like to get rid of stdenv.isCross for now
<sonarpulse>
I think it too vague
<sonarpulse>
I noticed in guile you use it for native guile
<sonarpulse>
but if native guile is depsBuildBuild, would we not also need it when build == host != target?
vcunat has quit [Quit: Leaving.]
pxc has quit [Ping timeout: 268 seconds]
Guest77574 has joined #nixos-dev
Guest77574 has quit [Quit: Yaaic - Yet another Android IRC client - http://www.yaaic.org]
symphorien has left #nixos-dev ["WeeChat 1.9.1"]
<sonarpulse>
shlevy: why is libtool a buildInput for guile?
<sonarpulse>
oh nevermind the dynamic linking library
pxc has joined #nixos-dev
lopsided98 has quit [Remote host closed the connection]
pxc has quit [Ping timeout: 248 seconds]
lopsided98 has joined #nixos-dev
lopsided98 has quit [Remote host closed the connection]
lopsided98 has joined #nixos-dev
pxc has joined #nixos-dev
sonarpulse has quit [Ping timeout: 260 seconds]
<shlevy>
Mic92: Do you know if the systemd fix will make it into 18.03?