gchristensen changed the topic of #nixos-dev to: NixOS Development (#nixos for questions) | https://hydra.nixos.org/jobset/nixos/trunk-combined https://channels.nix.gsc.io/graph.html | 18.03 release managers: fpletz and vcunat
Lisanna has joined #nixos-dev
<sonarpulse> shlevy: is the guile 2.0 build like *dramatically* slower than the others?
<sonarpulse> should be almost done cross compiling but for that
<shlevy> I think so yeah
<shlevy> It's so bad
<sonarpulse> shlevy: cool
<sonarpulse> then fuck it
<sonarpulse> I think my pr is good enuogh
<sonarpulse> I'll open it
<sonarpulse> good job on upstream re improving 2.3
<cstrahan> Sonarpulse: I pushed up one more commit - it's getting close, I think: https://github.com/NixOS/nixpkgs/pull/28029/commits/806edaa0a20db3358836d55d203500b87dbe8624
<sonarpulse> cstrahan: cool!
<sonarpulse> will take a look
<cstrahan> Sonarpulse: you suggested that we could check the validity of the flags from Nix, but I'm not sure I see how that's going to work with the present interface, with enableHardening and disableHardening taking flags for both the cc-wrapper and ld-wrapper, intermixed -- unless I partition that list into those that apply to cc-wrapper and those that apply to ld-wrapper before setting the respective env var, but I would
<cstrahan> think that'd be expensive. Assuming I stated that clearly enough, what did you have in mind here?
<cstrahan> (If I understood one of your points, you were thinking we could reinstate this error: https://github.com/cstrahan/nixpkgs/commit/97a48835b7d7124b3c218a6be7ca4536ac0360a8#diff-cb2689b0887181f0a167bf96f94ab095L71)
<sonarpulse> cstrahan: yeah if we do two env vars we partition in nix
<sonarpulse> with when then its more fine
<cstrahan> sorry, didn't understand that last line.
<sonarpulse> s/when/one/ haha
<sonarpulse> cstrahan: oh from your comment you are still learning towards two vars?
<sonarpulse> I suppose the partitioning is no more cheaper than the validation
<cstrahan> oh, ha -- yeah, I thought so... but I'm not dead set on it. I suppose it could be handled at a later time, bundled with some other mass-rebuild change, if we deem it worth it. as the PR stands now, does this seem correct for the "one-var approach"? If yes, I'm okay with this as is.
<cstrahan> Sonarpulse: ^
<sonarpulse> cstrahan: almost
<sonarpulse> got some comments
<sonarpulse> little things :)
<cstrahan> cool. thanks again for reviewing :)
<sonarpulse> cstrahan: np!
<cstrahan> BTW, what's this talk about an improved mkDerivation, and shlevy's proprosal? Just curious what you guys are up to :P
<sonarpulse> cstrahan: there's some issues
<sonarpulse> nothing concrete that's super exciting yet
<sonarpulse> look for new issues with topic: cross-compilation or topic: portability
LnL has quit [Ping timeout: 265 seconds]
Synthetica has quit [Quit: Connection closed for inactivity]
<shlevy> cstrahan: The most concrete exciting thing is Eelco's draft
<shlevy> One sec
<shlevy> Which inspired me to actually think about how I'd want to write packages, especially if I could assume new language changes eventually
<shlevy> And since Sonarpulse and I had been talking about finally switching to a fully cross-aware stdenv (https://github.com/NixOS/nixpkgs/issues/36217) I decided I should try to get something together that can be reviewed and validated quickly
<cstrahan> Cool, exciting stuff!
<cstrahan> << It's worth noting that the Nix language is intended as a DSL for package and configuration management, but it has no notions of "packages" or "configurations". >>
<cstrahan> That is rather ironic, now that I think of it :)
<sonarpulse> shlevy: we should cherry-pick our guile changes
<sonarpulse> and my makeStdenvCross removal of selfNativeBuildInput to 18.03
<shlevy> Sonarpulse: Why?
<shlevy> Sonarpulse: Has 18.03 actually been branched yet?
<sonarpulse> yes
<sonarpulse> I can forsee down the road people wanting more cross stuff on 18.03
<sonarpulse> but
<sonarpulse> that could be harder to cherry-pick
<sonarpulse> so yes it is stupid on its own
<sonarpulse> but trying to be proactive
* sonarpulse seems to always have something in flight come release time
<gchristensen> it is also okay to tell those cross people they need to use unstable
<shlevy> fpletz: Can we get a mail about the branch-off?
<shlevy> Sonarpulse: if someone has a real use case, we can cherry-pick later
<shlevy> I'd rather not cherry-pick for the sake of cherry-picking... Certainly we have no realistic stability guarantees around cross yet :|
<sonarpulse> shlevy: true
<shlevy> Sonarpulse: Ultimately if you want to make the case I'd open a PR and see what vcunat says. But I think it will be more compelling with a real setup.
<shlevy> E.g. "cross NixOS kind of works on 18.03" is a cool thing to be able to say, and since it's already on staging I hope it'll get in, but I'm not going to try to cherry-pick back the inevitable fixes
<sonarpulse> shlevy: well i got enough to do that you've convinced me
<shlevy> :)
<gchristensen> 18.03 is already branched fwiw
<shlevy> Yeah, I saw
<gchristensen> ok
<shlevy> But staging hasn't been merged in some time
<shlevy> Well, I suppose 2/22 wasn't that long ago :D Feels like forever
<shlevy> I really don't get what's going on with hydra :( https://hydra.nixos.org/status
<shlevy> 8 builds??
<shlevy> All the rackspace boxes are idle, the x86 packet boxes are idle, the macs are idle...
<gchristensen> when I loaded it, a rax box had a job
<shlevy> niksnut: Can I get access to the cache s3 bucket? I'd really like to make progress on glibc and binutils bumps...
<gchristensen> what would that get you?
<shlevy> gchristensen: I can do builds on my own box and upload them :P
<gchristensen> I don't think you're going to get that access
<shlevy> There's definitely something wrong with scheduling shares... trunk only has 2000 and regularly gets scheduled, glibc-2.27 has 100000 after my various attempts to get things building :D
<shlevy> gchristensen: Can't hurt to try :)
<gchristensen> be wary of asking for too much too often :)
<gchristensen> even at 10,000 you're at <1%
<shlevy> gchristensen: And trunk is much less though
<gchristensen> hmm
<shlevy> Eh. I don't think it's that unreasonable to give trusted community members access to things when the official mechanisms aren't fitting the needs. I also don't think it's that unreasonable to say no, but since right now the alternative is debug and fix hydra or stall I figured I'd try.
<shlevy> (not that I think glibc-2.27 *should* be above trunk, but right now it is and still not getting scheduled)
<gchristensen> when did it get bumped up to 10000?
<shlevy> two or three days ago
<dtz> :( according to clone(2) of 4.15 our usage of clone() should never work :P. But it does! So... :(.
<shlevy> dtz: What specifically?
<dtz> mostly it says various things conflict with CLONE_PARENT
<dtz> .... "Only a privileged process (CAP_SYS_ADMIN) can employ CLONE_NEWPID. This flag can't be specified in conjunction with CLONE_THREAD or CLONE_PARENT. "....
<dtz> also "This flag can't be specified in conjunction with CLONE_THREAD or CLONE_PARENT. For security reasons, CLONE_NEWUSER cannot be specified in conjunction with CLONE_FS."
<shlevy> We have an explicit fallback for that case
<shlevy> Which says "Linux < 2.13" which I kind of doubt is right :D
<dtz> haha or important :P:P
<dtz> I'm cloning kernel git currently lol, to see wtf really happens/is allowed.
<shlevy> 3.13 is what he meant :)
<gchristensen> Hydra has only built a few things on the packet x86 machine
<gchristensen> today
<gchristensen> (UTC)
<dtz> yeah docs seem kinda wrong :D re:CLONE_PARENT (or need version constraints anyway). Like I said, it clearly works... xd
<dtz> ruhroh
<lopsided98> Could someone take a look at https://github.com/NixOS/nixpkgs/pull/35093 if you have time?
<gchristensen> ok shlevy doing some further research, I declare this problem very weird
sonarpulse has quit [Ping timeout: 240 seconds]
<shlevy> :D
<shlevy> Yeah?
<gchristensen> hydra, for whatever reason, can't run those jobs
<gchristensen> stupid question
<gchristensen> is the number 70,356,844 reaching any typical numeric type limits?
LnL has joined #nixos-dev
<gchristensen> shlevy: maybe you can rebase your glibc branch on to another base to force new jobs be created?
<shlevy> 2 ^ 26?
<shlevy> Merged in staging
<shlevy> Cancelled builds...
<shlevy> And queued up an eval
<gchristensen> ah ok
<shlevy> 1 running build :D
<shlevy> :o
<gchristensen> I cancelled all other jobs
<shlevy> queue is 51?
<shlevy> Ah
<gchristensen> it seems strangethere is no evaluator error output
<gchristensen> but maybe that is normal
<shlevy> What would you be expecting?
<gchristensen> there you go
<gchristensen> you're building =)
<shlevy> :D yay
<shlevy> Maybe everything queued before the mac error was broken?
<gchristensen> I'm wondering if the jobs got in a bad state from when postgres went down, maybe 5d ago
<shlevy> Aaah
<gchristensen> ^ wild guess
<shlevy> I'd guess we want to terminate all the jobs in staging-small and ericson2314-cross-trunk
<gchristensen> m'onit
<shlevy> I wonder what happens when one of the jobs queued 5 days ago is scheduled again after it's cancelled
<shlevy> Probably not worth exploring
<shlevy> If this works
<gchristensen> well
<gchristensen> if I had to guess
LnL has quit [Ping timeout: 268 seconds]
<gchristensen> the queue runner is churning over the hundreds to thousands of jobs it can't run
<shlevy> What does that mean by the way?
<gchristensen> and can only keep a handful of jobs going at a time
<shlevy> "can't run"
<shlevy> Does it error out? Or just skip them?
<gchristensen> I don't know, just something I'm observing here via the hydra ui and intuition
<gchristensen> but I'd guess they were in a bad state and would probably error and schedule a retry them
<shlevy> Ah OK I thought you were looking at queue runner logs
<gchristensen> unfortunately not :)
<gchristensen> and even more unfortunately, your jobs are no longer building .....
<shlevy> :o
<gchristensen> it is behaving as if the jobs need features that don't exist in the hosts
<shlevy> I guess we'll need someone to get onto the machine
<dtz> does the job introduce new instances of <nix/fetchurl> ? if so, it'll need a builder of type system "builtin" to be scheduled
<shlevy> dtz: Nothing new I don't think
<shlevy> Unless it snuck in via staging
<dtz> had to add "builtin" to my builders' systems earlier today
<gchristensen> let's find out!
<dtz> nix 2 thing I think.
<dtz> anyway may not be related at all just thought I'd mention :D
<shlevy> Hmm the builds 3-5 here are mighty suspicious in light of that comment https://hydra.nixos.org/build/70725072#tabs-build-deps
<shlevy> Ah never mind those completed
<dtz> haha it was bootstrap jobs for me, FWIW
<dtz> but yeah xD
<shlevy> hmm
<shlevy> so glibc 2.27 depends on bison
<dtz> and bouncing hydra-queue-runner doesn't fix it? :(
<shlevy> Which means new packages in the early early stages of stdenv
<gchristensen> nobody online with access
<dtz> lol that's my step 1 debugging technique for "why isn't hydra doing what I want" lol
<shlevy> Hmm but bison failed
<shlevy> erm, built
<dtz> many times been tempted to make cronjob or w/e systemd equiv is to auto-restart
<dtz> oh
<dtz> o_O
<gchristensen> something is extremely weird
<gchristensen> but I got there by clicking a link for acl
<shlevy> \o/ db corruption
<gchristensen> I think actually yes
<shlevy> Almost certainly
<gchristensen> b/c I found a build that was queued, but its dependency was failed
<gchristensen> restarting the dependency seemed to have let a flood of your builds go
<gchristensen> I think we may have unstuck it
<shlevy> Should I cancel non-current again?
<gchristensen> please don't
<shlevy> Seems like you unstuck an old eval
<shlevy> The current eval is still not building anything
<gchristensen> I wonder if we have backups :')
<shlevy> I'll go through the current eval for things with the same issue
<shlevy> Well, other than posterity I'm not sure much would be lost if we had to start fresh
<gchristensen> years of performance data
<shlevy> Sure, but it's unlikely we'll have to *nuke* the DB
<shlevy> Just start with a new one
<gchristensen> ah
<gchristensen> are you canceling old jobs on me?
<shlevy> It's clearly not so broken that queries can't happen at all
<shlevy> Nope
<gchristensen> hmm
<gchristensen> "Aborted (Hydra failure; see below)"
<shlevy> Which job?
<shlevy> Hm so the build failure there is real
<shlevy> The systemd one
<shlevy> I don't know if avahi is meant to depend on it or not
<gchristensen> I wonder if it would be better to put a hold on the poking and meet up with eelco
<shlevy> Yeah, I don't want to change anything else
<shlevy> Honestly if I could I'd stop all actions that write to teh DB
<shlevy> Is it just Rob and Eelco with the access?
<gchristensen> yeah
<shlevy> OK
<shlevy> I'll draft a mail to the ML
<gchristensen> is it normal that from https://hydra.nixos.org/build/69990145#tabs-summary if I click (propagated from build 69990124) which is about systemd, I get to a job about udev
<shlevy> udev is an alias for systemd
<gchristensen> ah
<gchristensen> I dunno, man
<gchristensen> I think something is busted in nixpkgs maybe
<shlevy> I mean, acl going to mariadb is pretty conclusive
<gchristensen> well
<shlevy> Luckily nothing too important happening around the February/March border in the nix world :)
<gchristensen> maybe it is because acl was built as a result of mariadb being a selected thing to build
<gchristensen> so acl was just built as part of mariadb
<shlevy> Where did you see the acl link?
<shlevy> And glibc 2.27 is now idle :)
<gchristensen> shlevy: can you explicitly make acl part of the jobset?
<shlevy> Sure, will do
<gchristensen> shlevy: you sure it isn't an issue of builtins fetchurl? https://github.com/NixOS/hydra/issues/540#issuecomment-370824316
<gchristensen> pkgs/stdenv/linux/bootstrap-files/x86_64.nix
<gchristensen> 5: bootstrapTools = import <nix/fetchurl.nix> {
<shlevy> But that's not new
<gchristensen> true
<shlevy> And things depending on bootstrap tools build
<gchristensen> right
<gchristensen> ok let me know when you've added acl
<shlevy> Cached from mysql
<shlevy> OK
<gchristensen> mysteries ...
<gchristensen> yeah send that email
<shlevy> Check your inbox :)
* gchristensen is behind
<dtz> depending on uncached bootstrap tools seem to trigger this recently-ish
<dtz> and uncached bootstrap tools aren't very common
<dtz> oh I see re:email
<dtz> :(
<gchristensen> this is fairly obnoxious to diagnose over http :P
<shlevy> :D yeah
<dtz> hahaha yeah
pxc has quit [Ping timeout: 260 seconds]
<gchristensen> shlevy: are there multiple acls possible?
<shlevy> Possibly. Why?
<gchristensen> when I build aspell locally on your branch and run nix-store -qR /nix/store/nvswyaalpdr69zq8w93r71jb37xg8mh1-aspell-0.60.6.1.drv I see /nix/store/7cikfdkmvq9vhamr7bmph1dr7gc9v7n8-acl-2.2.52.drv
<gchristensen> but the passing acl in the build is /nix/store/nd81cd2scplml4myrlyyvr26pawlmalx-acl-2.2.52.drv
<gchristensen> in the jobset*
<shlevy> Check the out paths?
<shlevy> drvs paths are not as reproducible due to fixed output build hanlding
mbrgm has quit [Ping timeout: 240 seconds]
<gchristensen> ah, same
Lisanna has quit [Quit: Lisanna]
mbrgm has joined #nixos-dev
<gchristensen> ok I'm heading out
<gchristensen> good luk :)
pxc has joined #nixos-dev
pxc has quit [Ping timeout: 240 seconds]
Lisanna has joined #nixos-dev
pxc has joined #nixos-dev
pxc has quit [Ping timeout: 260 seconds]
pxc has joined #nixos-dev
pxc has quit [Ping timeout: 264 seconds]
pxc has joined #nixos-dev
pxc has quit [Ping timeout: 268 seconds]
Lisanna has quit [Remote host closed the connection]
disasm has quit [Ping timeout: 240 seconds]
pxc has joined #nixos-dev
pxc has quit [Ping timeout: 264 seconds]
pxc has joined #nixos-dev
pxc has quit [Ping timeout: 264 seconds]
disasm has joined #nixos-dev
pie_ has quit [Ping timeout: 248 seconds]
pxc has joined #nixos-dev
pxc has quit [Ping timeout: 240 seconds]
pxc has joined #nixos-dev
pxc has quit [Ping timeout: 240 seconds]
LnL has joined #nixos-dev
MichaelRaskin has quit [Quit: MichaelRaskin]
pxc has joined #nixos-dev
pxc has quit [Ping timeout: 264 seconds]
pxc has joined #nixos-dev
pxc has quit [Ping timeout: 264 seconds]
pxc has joined #nixos-dev
pxc has quit [Ping timeout: 256 seconds]
__Sander__ has joined #nixos-dev
<aminechikhaoui> might be interesting for nixpkgs statistics
<clever> aminechikhaoui: watching the youtube vid linked within, and i can see how a lot of people have abused github in different ways
<clever> cant see any applying directly to nixpkgs so far
<clever> aminechikhaoui: interesting, every fork of a repo is hosted on the same hardware as the original
<clever> aminechikhaoui: ouch! https://youtu.be/-ZNKR9wFe8o?t=19m36s
<sorear> why can't they publish this as text for people who don't deal well with spoken English
<sorear> the internet was much better before the pivot to video
<aminechikhaoui> clever: oh didn't see the youtube video :)
<clever> aminechikhaoui: lol, github was OOM'ing when you tried to fork intelij
capisce has quit [Read error: No route to host]
capisce has joined #nixos-dev
<aminechikhaoui> hehe
pxc has joined #nixos-dev
pxc has quit [Ping timeout: 256 seconds]
jtojnar_ has joined #nixos-dev
<LnL> huh, one of the largest blobs in nixpkgs is a commit with a diff in the message :D
jtojnar has quit [Ping timeout: 248 seconds]
jtojnar_ has quit [Ping timeout: 264 seconds]
davidlt_ has joined #nixos-dev
<clever> LnL: weird
<LnL> not that weird, it means we don't have random garbage in the repo
davidlt has quit [Ping timeout: 260 seconds]
<clever> LnL: do you happen to know where nix stores the rootdir in local?root=/foo, trying to fix a bug with nix handling it poorly
<LnL> at work we have some repos where people committed a bunch of tarballs and deb files
<LnL> and then they complain it's slow -_-
<clever> lol
<LnL> not sure what you're asking
<clever> when using NIX_REMOTE=local?root=/foo, how can the "/foo" string be accessed within libstore
<LnL> hmm, builtins.storePath?
<LnL> oh no, it's still /nix/store
<LnL> the result is only usable from a chroot like nix run ... that maps the store for you
<clever> LnL: the issue, is with nix-store --verify --check-contents
<clever> so its within libstore itself
<clever> checking contents of '/nix/store/y4p3gg22jjr223r2r681nmfdfvj245lk-xz-5.2.3' and realStoreDir is '/tmp/tmp.qvYHEtxOkJ/nix/store'
ma27 has quit [Quit: WeeChat 2.0]
<clever> LnL: nix doesnt prefix the paths correctly when checking them
<LnL> that's a bug then
<clever> yeah, thats what i'm trying to fix
<LnL> oh!
<LnL> inside nix you can access it with store->realStoreDir
<shlevy> clever: Already fixed on master it looks
<LnL> :D
<clever> i checked out master and its still happenng
<clever> i'll need to adjust it
<LnL> including the daemon?
<LnL> hmm no that doesn't matter in this case
<clever> i'll check again more closely in a min
ma27 has joined #nixos-dev
<shlevy> clever: This commit was just made
<shlevy> Did you check it out after niksnut closed your issue?
<clever> oh
<clever> lol, yeah, i see it now
ma27 has quit [Quit: WeeChat 2.0]
ma27 has joined #nixos-dev
<shlevy> viric: Around?
ma27 has quit [Client Quit]
pxc has joined #nixos-dev
pxc has quit [Ping timeout: 240 seconds]
ma27 has joined #nixos-dev
davidlt_ is now known as davidlt
<viric> shlevy: o/
<viric> shlevy: ah, unfortunate.
<viric> shlevy: I don't depend on it now. Break it at your will.
<viric> (I guess it is a downside of some other benefit :)
<shlevy> Yeah, no idea why it broek but all the way back in December...
<viric> no wonder. fragile thing.
<shlevy> niksnut: grahamc: is https://hydra.nixos.org/build/70356827 actually waiting for the gc lock, or is this another instance of the "stalled on sending inputs" bug?
<shlevy> OK looks like cancelling it actually worked
<shlevy> so probably the former
pxc has joined #nixos-dev
<niksnut> yes there is a GC running
<clever> niksnut: would it ever be possible for make-system-tarball.nix to include the narhashes and the signatures (which 2.0 now saves) into the nix-path-registration file?
orivej has quit [Ping timeout: 256 seconds]
ma27 has quit [Quit: WeeChat 2.0]
orivej has joined #nixos-dev
<niksnut> clever: sure
<clever> i'm currently having to do copy-sigs and verify --check-contents at a later stage, when most of the sigs arent available
pxc has quit [Ping timeout: 276 seconds]
<clever> so i'm just going to have to disable signature checks
<clever> oh, and we have `nix-store --query --hash` but no `nix-store --query --sigs`
<niksnut> oh sorry, I didn't see the signatures
<niksnut> no, it will not be possible to support signatures
<clever> i'm trying to generate a complete store database, that includes the signatures, and can be stored as a tar file
<niksnut> we could mark those paths as ultimately trusted
<niksnut> then at least nix verify wouldn't complain about them
<niksnut> but the ultimately trusted bit is really only intended for locally built paths
<niksnut> the more long term solution would be to rewrite the closure to content-addressed form, so it doesn't need signatures
Synthetica has joined #nixos-dev
<gchristensen> niksnut: is hydra back to normal now?
pxc has joined #nixos-dev
ma27 has joined #nixos-dev
pxc has quit [Ping timeout: 260 seconds]
ma27 has quit [Quit: WeeChat 2.0]
<niksnut> gchristensen: I think so
<gchristensen> ok, cool :) thank you for taking a look. I'm sorry for the false alarm about DB corruption :')
ma27 has joined #nixos-dev
ma27 has quit [Quit: WeeChat 2.0]
ma27 has joined #nixos-dev
ma27 has quit [Client Quit]
vcunat has joined #nixos-dev
ma27 has joined #nixos-dev
ma27 has quit [Quit: WeeChat 2.0]
ma27 has joined #nixos-dev
<samueldr> hi!, I'm wondering if I should bother someone, and who to bother for feedback on PRs for nixos-homepage, I mean, other than niksnut
pxc has joined #nixos-dev
pxc has quit [Ping timeout: 268 seconds]
<vcunat> I don't know who has write access in there.
<gchristensen> I think garbas, domen, rob, and eelco
<vcunat> Probably.
<gchristensen> samueldr: what do you want reviewed? can't hurt to get some eyes on it
<gchristensen> even if we can't merge them :)
<vcunat> I have a similar problem with https://github.com/NixOS/nixos-org-configurations/pull/39
<samueldr> two of thems should be obvious merges, and then one is probably a bit more involved and will/should probably generate discussion https://github.com/NixOS/nixos-homepage/pulls/samueldr
<gchristensen> vcunat: maybe drop 16.09 too
<gchristensen> samueldr: love PRs adding more JS see-no-evil.jpg
<gchristensen> #189 is spicy, look at you -- adding whole visual elements
<samueldr> s/adding/fixing/g :) in that case, it fixes text issues in the descriptions wherein the links are completely gone, sometimes making the text look a bit dumb
<vcunat> I didn't think of that. Dropping 16.09 seems safe now.
<gchristensen> ack
<gchristensen> well IMO it isn't helpful to have a separate channel for aarch64 if you're deploying to a mixed arch environmentwith nixops
<gchristensen> you can't have a safe deployment in that case
<vcunat> (see the links on issues)
jtojnar has joined #nixos-dev
<vcunat> It seems like Graham has a red phone to Eelco.
<gchristensen> I promise I don't :)
* gchristensen hides his bananaphone
<Mic92> gchristensen: looks like we need a nixos-homepage core team too :)
<gchristensen> samueldr: ruby -run -ehttpd . -p8000 and python -m SimpleHTTPServer 8000 both fail for me
<Mic92> in what way?
<gchristensen> I see the request work fine and get served, but I still get the error about failing to fetch options
<samueldr> gchristensen: any specific URL or is to plain options.html without params?
<samueldr> hmmm, both firefox and chrome for me do work with the built files, I'll clone in a fresh location
<gchristensen> I'll try chrome
<Mic92> a bit off-topic, but I found caddy also quite handy for those tasks: https://github.com/Mic92/dotfiles/blob/master/nixos/configuration.nix#L180
<samueldr> could you verify if it works with master?
<gchristensen> nope, fails on chrome for me. I can verify it is also broken on master :P
<samueldr> ah good, then it's *something else* :)
<gchristensen> yeah
<samueldr> what's the browser console like?
<gchristensen> cempty
<samueldr> :/
<Mic92> tcpdump -A -n -i any port 8000
<gchristensen> I mean I see it fetched in the network tab
<gchristensen> it just doesn't like it?
<Mic92> maybe you should both check your generated files.
<Mic92> different nix channel? different nix version?
<samueldr> is it .json.gz or .json? I remember for packages having to ungzip then switch the revision
<samueldr> but I can't remember if it is needed for options
<gchristensen> options is a .gz too, and I've tried ungzipping it and altering the HTML
<gchristensen> hmm maybe I did a dumb thing.
<samueldr> gunzip nixos/options.json.gz, then editing the source was indeed required on a fresh checkout
<gchristensen> I did a dumb thing. I had to gunzip it and alter the HTML to point to the .json file. in my pre-coffee stupor, I just `mv options.json.gz options.json`
<samueldr> what's weird is how I don't have the changes locally and it still works, unless, ah!, the generated files I have locally are pre-reverting my change
* samueldr is thinking about finding a one-liner HTTP server that can serve gzipped content correctly
<gchristensen> caddy maybe
orivej has quit [Ping timeout: 248 seconds]
pxc has joined #nixos-dev
pxc has quit [Ping timeout: 264 seconds]
orivej has joined #nixos-dev
* vcunat wonders what "one-liner" should mean, as _some_ code has to do the work anyway.
<gchristensen> I have a fix for the whole situation anyway
<Dezgeg> that the server needs to be implemented in APL?
<vcunat> :-)
<samueldr> vcunat: one-liner as in "one command line" to run the server, not the implementation :)
<vcunat> hydra-eval-jobs returned signal 9: :-(
<gchristensen> https://github.com/NixOS/nixos-homepage/pull/192 this should fix the local dev issue
orivej has quit [Ping timeout: 240 seconds]
<vcunat> samueldr: aha!
<gchristensen> no server necessary
<samueldr> though, s/\n/ /g may work with some languages :)
<samueldr> (ah, it can't work as \n are not part of what's being substituted!)
<Dezgeg> do most browsers allow XHR requests to file:// urls? (wondering about the 'no server needed' part)
<vcunat> tr -d '\n'
<vcunat> maybe
<samueldr> I think chrome doesn't by default
<samueldr> (see the README)
<samueldr> [...] and start your browser with CORS disabled for local files:
<gchristensen> at it works in firefox but not in chrome
<samueldr> and (I need to verify) but the links may not work if they are using absolute URLs
<gchristensen> ahh I'll update the PR
<samueldr> ah, and using the file:/// will not default to index.html on navigation
<gchristensen> fixed
<gchristensen> anyone want to test my PR :)
<Dezgeg> might want to clarify that's for python2 (the other is python3 -m http.server)
<gchristensen> no need -- it works as directed inside the nix shell
<samueldr> may need to remove the part about starting chrome with CORS disabled, then?
<Dezgeg> ah, true. doesn't hurt to do s/python/python2/ though.
<samueldr> oh, didn'T look carefully enough
<gchristensen> samueldr: I did?
<gchristensen> done, Dezgeg
<samueldr> only looked at the diff github told me to look at and it was for the last commit only
<gchristensen> please do indicate on the PR if you've tested it and it LGTY ;)
<samueldr> done
<shlevy> Ugh. memfd_create manpage suggests it should go into <sys/memfd.h>, but glibc 2.27 put it into <sys/mman.h>, so now a bunch of programs trying to detect if it's defined fail
<gchristensen> and people wonder why we're so susceptible to burn out
<shlevy> :)
<shlevy> It's a pain, but it's honestly so much better than when I started on Linux (15 years ago jesus) or when I started on NixOS.
<shlevy> I think the ecosystem as a whole is maturing
<gchristensen> I hope so, the whole ecosystem powers much of the universe
<shlevy> E.g. so far the three packages I've fixed for this issue were just cherry-picking upstream patches :)
<shlevy> :o bunch of segfaults in rust tests
davidlt has quit [Remote host closed the connection]
davidlt has joined #nixos-dev
pxc has joined #nixos-dev
Lisanna has joined #nixos-dev
pxc has quit [Ping timeout: 260 seconds]
s33se has joined #nixos-dev
s33se has quit [Client Quit]
s33se has joined #nixos-dev
orivej has joined #nixos-dev
<shlevy> gchristensen: Does ofborg set the pending github status?
<gchristensen> it does
<shlevy> Ok
<gchristensen> why do you ask?
<gchristensen> wait, what pending status? ;)
<shlevy> On a commit
<shlevy> I'm wondering if no yellow dot means ofborg hasn't started doing anything yet
<gchristensen> yeah it hasn't started anything yet
<shlevy> gchristensen: By the way grahamcofborg's profile links to ofborg on grahamc :)
<gchristensen> I'll bring up a new evaluator
<shlevy> :o
pxc has joined #nixos-dev
sonarpulse has joined #nixos-dev
__Sander__ has quit [Quit: Konversation terminated!]
<gchristensen> niksnut: thank you for going on a merge spree :)
jtojnar has quit [Quit: jtojnar]
<LnL> vcunat: what's the current status of release-18.03, should we cherry-pick fixes there or is it still synced with master
Lisanna has quit [Remote host closed the connection]
jtojnar has joined #nixos-dev
Lisanna has joined #nixos-dev
<cstrahan> Sonarpulse: Did I miss some new feedback on that PR yesterday? Not sure what's left to do there.
<sonarpulse> cstrahan: let me check
shlevy has quit [Quit: Quit]
shlevy has joined #nixos-dev
Lisanna has quit [Quit: Lisanna]
ma27 has quit [Quit: WeeChat 2.0]
ma27 has joined #nixos-dev
ma27 has quit [Ping timeout: 256 seconds]
vcunat1 has joined #nixos-dev
<sonarpulse> shlevy: what's the deal with nix-serv and nix 2?
<sonarpulse> nixpkgs doesn't support it too well atm
<sonarpulse> is it even needed?
<vcunat1> doesn't remote building use it as transport?
vcunat1 has quit [Quit: Leaving.]
vcunat1 has joined #nixos-dev
<vcunat1> (I'm not sure at all)
davidlt has quit [Ping timeout: 252 seconds]
davidlt has joined #nixos-dev
vcunat1 has quit [Read error: Connection timed out]
vcunat1 has joined #nixos-dev
jtojnar has quit [Ping timeout: 240 seconds]
MichaelRaskin has joined #nixos-dev
pxc has quit [Ping timeout: 240 seconds]
vcunat1 has quit [Quit: Leaving.]
vcunat1 has joined #nixos-dev
vcunat1 has joined #nixos-dev
<MichaelRaskin> vcunat1: maybe add that comment you have made into the manual?
<vcunat1> yes, perhaps
<vcunat1> though I'll focus on branching+ZHF announcements first
<vcunat1> There's just too little time to catch everything I want.
<gchristensen> let us know how we can help
jtojnar has joined #nixos-dev
<vcunat1> You can e.g. formulate that texlive comment to express what that person missed.
<vcunat1> Right now I'm writing an e-mail explaining how all commiters can help.
<gchristensen> ok, great
<vcunat1> (one way how they can, at least)
<LnL> that's great!
<LnL> did you see my question about cherry-picking?
<MichaelRaskin> gchristensen: you are writing it? If not, I guess I could try.
<gchristensen> I'm not, I'm not sure what that part was about. I was saying the email sounds great :)
<vcunat1> LnL: I don't remember.
<vcunat1> But what I meant is to announce that most cherry-picking decisions should be done by those who merge to master/staging.
<vcunat1> (or push)
<LnL> that was basically the question :)
<vcunat1> Hmm, do we have a stable branch policy somewhere written down?
<vcunat1> I would expect it here https://nixos.org/nixpkgs/manual/#idm140737317045888 but I can't see it.
<vcunat1> I shall add it there, but I want to first make sure I haven't missed it elsewhere.
<LnL> oh, thought it was in there somewhere
<vcunat1> Possibly it was just ML announcement or something.
<vcunat1> Ah, so I suppose you created this because we didn't have it in manuals.
<gchristensen> yeah and have managed to go this long without putting it in the manual :(
<vcunat1> gchristensen: you know that we have a nixpkgs-17.09-darwin, right?
<gchristensen> we didn't in january 2017 when I wrotee that :)
<vcunat1> Right.
<LnL> about that gchristensen, any idea why nix-info broke?
<gchristensen> it broke?
<gchristensen> In ./nix-info line 146:
<gchristensen> printf " - %s: \`%s\`\n" "$name" "$value"
<gchristensen> ^-- SC1117: Backslash is literal in "\n". Prefer explicit escaping: "\\n".
<gchristensen> looks like shellcheck updated
<LnL> on 17.09?
<LnL> ah thanks
<gchristensen> thank you :)
<LnL> I think somebody updates a bunch of haskell stuff, cabal2nix is also broken :/
<gchristensen> :/
<vcunat1> peti was it perhaps?
<LnL> yeah, but question is why does it work on master
<sonarpulse> vcunat1: hey nix team person that's here (:)) can we get a 2.0 lable in nix issue tracker?
<vcunat1> Meaning what?
<vcunat1> Issues present in 2.x missing from 1.x?
<sonarpulse> vcunat1: yeah
<sonarpulse> or maybe ones for each version
<sonarpulse> (forget if we have something similar for nixpkgs)
<sonarpulse> maybe just milestones and "2.0-regression"
<vcunat1> yeah, I was exactly thinking that
<sonarpulse> vcunat1: perfect
<vcunat1> actually, there's only one issue with the "regression" label
<vcunat1> Is it worth to have two of them?
<sonarpulse> vcunat1: you mean maybe like a found-in-2 + regression is good?
<vcunat1> What I mean - even if a regression appeared in 1.11.6
<vcunat1> I don't expect we will fix it in 1.11.x
<vcunat1> right?
<vcunat1> Moreover I assume we want to fix any regressions relatively quickly.
<sonarpulse> vcunat1: yeah
<sonarpulse> regression + some means to track when things appear
<sonarpulse> is good
<vcunat1> Well, maybe depending on severity, but I don't see much importance on 1.x vs 2.x regressions.
<sonarpulse> milestone is separate
<sonarpulse> (well just for reproducing)
<sonarpulse> but yeah far less important
<vcunat1> OK, so no changes in labels? :-)
<sonarpulse> oh is there already a regression label?
<vcunat1> yes
<sonarpulse> (like i could see dusting off an old 2.5 someday, and trying to reproduce all the 2.5 bugs)
<vcunat1> :-D
<sonarpulse> ok cool
<sonarpulse> we just need somebody to go tag things
<vcunat1> There's also "newui" label.
<sonarpulse> cool
<vcunat1> Hmm, we might arrange some triage workflow in the nix core team.
<sonarpulse> yeah that would be nice
<vcunat1> Labeling is possible only for those with push access, so...
<sonarpulse> vcunat1: thanks
<vcunat1> :-)
<sonarpulse> vcunat1: last thing, with the nix 2.0 save wrong hash on fixed output stuff
<sonarpulse> the plan is to get rid of fixed output scripts?
<sonarpulse> I want to make a issue on behalf of work that there will still be a good way to get back correct hash/drv programmatically
<sonarpulse> but not even sure if the prefetch deprecate plan is written down anywhere
<vcunat1> :-/ What?
<sonarpulse> vcunat1: I think it said in the release notes that it if a fixed output derivations succeeds except for the wrong hash
<sonarpulse> it will be cached under the right cache
<vcunat1> That can cause some regressions?
<vcunat1> I seem to be missing (part of) your point.
<LnL> the darwin channel should be fixed
<domenkozar> is there 18.03 one?
<LnL> the jobset already exists, but maybe the channel probably not yet
<vcunat1> Jobsets are there. I'm just creating announcements.
<vcunat1> domenkozar: channels not yet
orivej has quit [Ping timeout: 240 seconds]
<vcunat1> but committed in the configs, so I'm not sure what's stuck
pxc has joined #nixos-dev
<shlevy> Sonarpulse: ssh-ng basically replaces it IMO
<shlevy> I mean, ssh:// is still around and uses nix-store --serve
<shlevy> And ssh-ng still has some bugs
<vcunat1> ANN: [Stabilizing 18.03 Impala] https://groups.google.com/forum/#!topic/nix-devel/3KxPNwxDV9E
<viric> vcunat1: thank you!
<vcunat1> :-)
<LnL> how are the release notes looking, did we do a better job then last time? :)
<samueldr> > [cherry-picking] Bugfix-only updates (minor, maintenance) // I want to know what's the policy for this both now and the future. Do I ask for cherry picking bugfix releases for what I maintain? Do I open another PR targeting the branch + cherry-picked (-x) commit?
<vcunat1> samueldr: I hope I've described what to cherry-pick in enough detail in the e-mail.
<shlevy> samueldr: IMO you can open a PR targeting the branch + cherry-picked commit. And if you have merge rights, merge after ofborg succeeds if the initial commit had good reviews and it was a trivial cherry-pick
<samueldr> it's not necessarily with 18.03, I'm just not sure the policy for nixos
<vcunat1> I want to transfer that to nixpkgs manual, as noted earlier today.
<MichaelRaskin> vcunat1: I think this specific question (ask via comment or via PR) is actually out of scope of the email
<vcunat1> The policy won't depend on version.
<samueldr> ah right, so e.g. when $SOFTWARE updates, it's fine I open two PRs?
<vcunat1> You may create a separate PR with cherry-picked commits.
<samueldr> thanks!
<vcunat1> But since you can't merge yourself, the merger can easily pick them directly.
<vcunat1> I actually prefer to pick the merge commit itself, as that notifies the PR.
<MichaelRaskin> That's complicated — impulse-review on GH makes it faster to merge two linked PRs
* samueldr is now confused
<vcunat1> Some people prefer to merge via buttons.
<samueldr> so, asking or opening two PRs?
<vcunat1> Let's say it isn't clear-cut.
<LnL> yeah
<samueldr> though, I guess opening a second PR, with proper mention of the master one, someone with merge rights can do as they want and close the other one if they want
<vcunat1> You certainly won't make a mistake if you open two PRs.
<MichaelRaskin> Ask in the description if a second PR is desired.
<MichaelRaskin> Yeah, two PRs seems safe
<MichaelRaskin> Closing an obvious thing to close is never a problem…
<samueldr> thanks, since I now have a package I maintain that updates with some frequency, I want to at least maintain it right
<vcunat1> Maybe the rule-set will need to go through discussion on a PR.
<vcunat1> (RFC would probably be an overkill.)
<MichaelRaskin> We-eeell
<MichaelRaskin> Establishing a policy for stable could be something to put through an RFC. Just to _have it_ in the RFC directory
<LnL> I personally prefer to just cherry-pick myself, less noise
<samueldr> I, for one, like when there is a clear cut path *described* for that kind of management
<MichaelRaskin> I personally hate git and prefer buttons where I can blame GitHub bugs if something goes surprisingly wrong.
<LnL> :p
<vcunat1> You can't sign merges done by the button.
<LnL> didn't github fix that recently?
<shlevy> Surprised github doesn't tell you to upload your key :P
<vcunat1> Your private key :-D
<vcunat1> Maybe they sign it by some key, but they can't sign it by your key, if that key is to be trusted to be only in your control.
<shlevy> Oh of course
<shlevy> They already have my public key
<vcunat1> (No, JavaScript isn't a good idea.)
<shlevy> I get a nice "Verified" badge on my commits
<MichaelRaskin> I think I can talk this channel into a disagreement what a signed commit actually means…
<vcunat1> Yeah, as there's a hundred people allowed to push to nixpkgs...
<MichaelRaskin> That's not the only question.
<sonarpulse> shlevy: this would be like anyone can ssh ssh-ng?
<shlevy> Sonarpulse: Not sure what you mean by that question
<shlevy> Sonarpulse: But the sshServe nixos module supports ssh-ng now in addition to nix-store --serve
jtojnar_ has joined #nixos-dev
jtojnar has quit [Quit: jtojnar]
davidlt has quit [Remote host closed the connection]
davidlt has joined #nixos-dev
jtojnar has joined #nixos-dev
jtojnar_ has quit [Ping timeout: 268 seconds]
vcunat1 has quit [Read error: Connection reset by peer]
davidlt has quit [Ping timeout: 256 seconds]
davidlt has joined #nixos-dev