<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?
<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>
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>
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>
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]
<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>
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>
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 :)
<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 :)
<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]