worldofpeace changed the topic of #nixos-dev to: NixOS Development (#nixos for questions) | NixOS 20.09 Nightingale ✨ | | | 20.09 RMs: worldofpeace, jonringer |
orivej has quit [Ping timeout: 258 seconds]
supersandro2000 has quit [Disconnected by services]
supersandro2000 has joined #nixos-dev
teto has quit [Ping timeout: 244 seconds]
ris has quit [Ping timeout: 246 seconds]
rajivr has joined #nixos-dev
<siraben> Have malicious packages ever been submitted/merged into nixpkgs?
<gchristensen> not that I know of
<siraben> I've noticed that maintainers will often build and run packages in PR, isn't that risky?
<ivan> it would help if we had a tool that would automatically compare the upstream source
<ivan> diffoscope already exists and could be wired up to github
<samueldr> hmm, this is a good reason for what Debian does; have a fork of many of the projects they package... though I think they mostly do it to shove the build instructions in the repo
<samueldr> they keep the commits from upstream as is, even... patches are supplied provided with the build instructions
<siraben> Even with diffing upstream source, what if the source itself is malicious?
<siraben> I suppose the blame can't be placed on nixpkgs then but with upstream
<samueldr> yeah, I would assume the question implied "not from upstream", if upstream ends up with malicious stuff in it, it's kind of out of our hands
<ivan> it is worth worrying about, but security bugs are much more common than vendors shipping malware
<ivan> the user has some responsibility for choosing less-dodgy software as well
<ivan> siraben: is what people tried in the Rust community
<siraben> I see.
<siraben> Jan Tojnar: it seems that many packages can't cross-compile to MMIX because the libc hasn't been fully implemented for it
<siraben> So far I've only gotten GNU Hello to cross-compile and run, but I want to do more testing
supersandro2000 has quit [Ping timeout: 260 seconds]
<siraben> I wish there were a list of "small packages to test cross-compilation", currently I try GNU hello, ed
<samueldr> busybox might be one
<samueldr> (and is also helpful)
<siraben> Ah, right.
<samueldr> not sure if small is the appropriate metric, but things like busybox are packages I'd expect to see more trivially cross-compile
<samueldr> as they're kind of the basic first step many times
<samueldr> since it's maybe a bit small, but definitely not simple :)
<siraben> Yeah not small per se, but light on deps.
<siraben> include/platform.h:164:11: fatal error: byteswap.h: No such file or directory
<siraben> | ^~~~~~~~~~~~
<siraben> 164 | # include <byteswap.h>
<siraben> heh
<Ericson2314> siraben: yes the doubles one and the other one
justanotheruser has quit [Ping timeout: 272 seconds]
<siraben> the one in `parse.nix`?
<Ericson2314> see my other comment that you will need to make mmixware a kernel
<Ericson2314> yeah in parse.nix
<siraben> Yeah I did that locally, still errors.
<Ericson2314> what error?
<Ericson2314> `error: Unknown kernel: mmixware` should be gone once you make it a known kernel
<siraben> Oh I have to touch the `kernels` attrset
<siraben> i haven't done that before
justanotheruser has joined #nixos-dev
supersandro2000 has joined #nixos-dev
<siraben> Ok that forces me to change libc to be newlib
<siraben> Pretty insane that a fictional computer has GCC support, heh
<Ericson2314> indeed!
<Ericson2314> ok libc to newlib sounds good
<siraben> And it was extremely easy to get this to cross-compile
<siraben> OTOH i'm still banging my head on the Z80 and CR16 PRs
<siraben> So newlib is an alternative to glibc but for embedded?
<siraben> One pain point I have with the cross arch is how to adapt non-GCC/clang based compilers
<Ericson2314> siraben: yes newlib is that
<Ericson2314> siraben: let's get this one done then worry about the others :)
<siraben> Indeed!
<siraben> Ok, compiling a cross GCC locally now...
<siraben> I learned to put a bell/audible notification at the end of my command so as to not stare at output for 30 mins, heh
<siraben> Ericson2314: so many packages didn't build with the previous libc, will newlib make this better?
<siraben> As in, is newlib arch-agnostic?
<Ericson2314> haah nice trick, done that too
<Ericson2314> siraben: still very few things will compile
<clever> siraben: nix-build ; tput bel
<Ericson2314> it only has very few system calls
<Ericson2314> the emulator supports
<siraben> on darwin, `nix-build; say "finished cross compile hello for mmix"`, heh
<siraben> I see
LnL has quit [Ping timeout: 240 seconds]
LnL has joined #nixos-dev
LnL has joined #nixos-dev
LnL has quit [Changing host]
<siraben> I notice GCC has PDP-11 target support, ooh
<{^_^}> #65589 (by angerman, 1 year ago, open): Can not add additional cross Systems via overlays
<siraben> ^ I've been able to do that in a fork of someone else's overlays
<siraben> but trying to add another CPU in the overlay as well seems impossible
supersandro2000 has quit [Quit: The Lounge -]
<Ericson2314> yeah it's too hard to be practical for now
supersandro2000 has joined #nixos-dev
<siraben> What's the criteria for cross targets being tested on hydra?
kalbasit has quit [Remote host closed the connection]
<Ericson2314> siraben: unclear what it is
<siraben> Ericson2314: looks like armv7l, darwin and linux x86_linux are tested on hydra
<siraben> x86_64*
<samueldr> are they _tested_ or are they incidentally built?
<samueldr> I know I incidentally build armv7l-linux and aarch64-linux for Mobile NixOS
<samueldr> so you end up with some of it cached, but that particular use doesn't really _test_ it
<siraben> I mean built, yeah.
<samueldr> it all ends up being a property of how Nix works :) a happy little accident [by design]
<samueldr> speaking of: GAH! new cross-compilation regression :(
<siraben> If I wanted to test cross-compilation across thousands of packages, is there a practical way to do it?
<siraben> Or would it have to be a hydra job
<samueldr> I can't say if there is a way the foundation can help you
<samueldr> (as in, I don't know)
<samueldr> though you could, yes, run a hydra instance to run the builds, or use nix-build... though that latter option is not great for tracking what is going on
alp has joined #nixos-dev
<siraben> samueldr: i see. I currently use cachix + GH actions, so being able to add cross overlays are pretty important
<siraben> Hm, even busybox failed to build.
<siraben> Ah, if I do `ag '{ stdenv, fetchurl }:'` in nixpkgs that gives me all the packages that have basically no dependencies
<siraben> beyond stdenv
alp has quit [Ping timeout: 272 seconds]
bgamari_ has quit [Ping timeout: 268 seconds]
cole-h has quit [Ping timeout: 240 seconds]
saschagrunert has joined #nixos-dev
alp has joined #nixos-dev
teto has joined #nixos-dev
__monty__ has joined #nixos-dev
FRidh has joined #nixos-dev
bgamari has joined #nixos-dev
orivej has joined #nixos-dev
alp has quit [Ping timeout: 272 seconds]
alp has joined #nixos-dev
chrisaw has quit [Quit: Connection closed for inactivity]
alp has quit [Ping timeout: 246 seconds]
alp has joined #nixos-dev
FRidh has quit [Ping timeout: 260 seconds]
FRidh has joined #nixos-dev
bgamari_ has joined #nixos-dev
bgamari has quit [Ping timeout: 246 seconds]
orivej has quit [Ping timeout: 260 seconds]
* sphalerite notices conspicuous absence of a nixos rfc steering committee meeting ping from Mic92
<hexa-> very sus
<sphalerite> niksnut: spacekookie: ping though :D
<Mic92> sphalerite: good point
orivej has joined #nixos-dev
<niksnut> sphalerite: +1
<niksnut> sphalerite: Mic92: sorry, am having sound issues
<Mic92> niksnut: different browser maybe?
<niksnut> chromium works even worse
<Mic92> spacekookie: are you coming?
<Mic92> niksnut: android?
<Mic92> That's what I am using.
<niksnut> maybe go on without me
<Mic92> niksnut: we are not enough people
<niksnut> we could try hangouts
__monty__ has quit [Quit: leaving]
<Mic92> To join the meeting on Google Meet, click this link:
<Mic92> Or open Meet and enter this code: hkp-qoxu-vyk
<Mic92> niksnut: ^
orivej has quit [Ping timeout: 264 seconds]
alp has quit [Ping timeout: 264 seconds]
alp has joined #nixos-dev
<sphalerite> infinisil: would you like to arrange a meeting for rfcs#67?
<{^_^}> (by FRidh, 33 weeks ago, open): [RFC 0067] Common override interface derivations
<sphalerite> Profpatsch: jtojnar: are you willing to shepherd rfcs#75?
<{^_^}> (by doronbehar, 11 weeks ago, open): [RFC 0075]: Declarative wrappers
<Ericson2314> niksnut: are you saying you support making the daemon it's own executable? :)
<Ericson2314> I made a rfc because i thought it was controversial
<Mic92> Ericson2314: he said its not controversial
<Ericson2314> Mic92: i thought before that Eelco was against it, and a smattering of people were for it, so i figured the RFC process was a chance to work that.
<Ericson2314> I'd feel most confortable closing the RFC if I didn't think the issue would be caught in limbo
<niksnut> I mean, it's not really different from most feature requests
<niksnut> it can still end up not being implemented for not being worth it, or not having time to implement it, or some other reason
<Ericson2314> well to me an RFC is a chance to decide whether something is a good idea independent of who implements it, so if one person does think it's worth it, even if others think it's fine but not something they'd bother persuing themselves, it can still happen
alp has quit [Ping timeout: 260 seconds]
<Profpatsch> sphalerite: I haven’t shepherded an RFC before, and I’m a bit worried I might not be up to it at the moment :)
<Profpatsch> remind me, do I have to comment on the technical implementation?
<Profpatsch> or just do meta-tasks as a shepherd
<Profpatsch> cause I don’t know if I have the headspace for reviewing this
<ma27[m]> niksnut: re my ssh-ng change: it would be better from your PoV to call the substitution from the nix-daemon or store protocol directly as I commented in right?
jonringer has joined #nixos-dev
orivej has joined #nixos-dev
<eyJhb> Any comments on what to do here?
<{^_^}> #102873 (by samsartor, 8 hours ago, open): evdi: v1.7.0 -> v1.8.0
<jonringer> block until upsteam fixes it
alp has joined #nixos-dev
<roberth> can someone cancel all staging-20.09 on hydra and/or give me cancel privilege, thank you
<roberth> oops sorry for the tone there. I'm a bit frustrated by the tzdata thing
<gchristensen> ask in -infra and I think someone should be okay with that under
<roberth> thanks :)
cole-h has joined #nixos-dev
<eyJhb> jonringer: Perfect, lets hope they fix it at some point
<FRidh> that's a good page gchristensen. I started thinking maybe the rfc on having a repo collecting all these kind of things actually isn't such a bad idea. Its understandable to have it documented on this repo, as hydra is part of the configuration, but from a nixpkgs contributors point of view, its not easy to find. Or maybe we actually need to separate infra from CI process
<gchristensen> thanks, I've been trying to document what I do when I do it
rajivr has quit [Quit: Connection closed for inactivity]
justan0theruser has joined #nixos-dev
justanotheruser has quit [Ping timeout: 244 seconds]
evanjs has quit [Quit: ZNC 1.8.2 -]
evanjs has joined #nixos-dev
alp has quit [Ping timeout: 260 seconds]
alp has joined #nixos-dev
FRidh has quit [Quit: Konversation terminated!]
alp has quit [Ping timeout: 272 seconds]
ris has joined #nixos-dev
alp has joined #nixos-dev
justan0theruser has quit [Ping timeout: 272 seconds]
saschagrunert has quit [Remote host closed the connection]
alp has quit [Ping timeout: 272 seconds]
<infinisil> Proposal: Add a `builtins.args` for getting arguments passed with --arg/--argstr explicitly
orivej has quit [Ping timeout: 240 seconds]
alp has joined #nixos-dev
orivej has joined #nixos-dev
justanotheruser has joined #nixos-dev
<worldofpeace> I thought of doing similar for the release documentation, with just a github wiki, but then I wasn't crazy about github wiki's, so then I decided to do
<endocrimes> I'm sometimes a bit confused by some nix contributions that go straight to master in nix. Seems a bit worrying that stuff like kernel bumps don't go through PRs ~ever
<samueldr> there's sometimes not much value to get from going through PRs for mostly automated updates like those
<samueldr> it's a wide-randing spectrum
<samueldr> ranging*
<samueldr> there was some talk about that in
<{^_^}> rfcs#79 (by dasJ, 2 weeks ago, closed): [RFC 0079] No more direct pushes to master and release branches
<samueldr> and the stats from that RFC body are misleading
<samueldr> with another methodology (which looks at PR commits) around 17% of commits didn't go through PRs
<samueldr> (sorry, was busy doing something else)
<samueldr> so yeah, blocking this entirely is problematic for technical reason in addition to the social ones
<samueldr> it would need more tooling than currently exists
<samueldr> but it _would_ be great if "human-made work" always went through PRs
<samueldr> and then, if there was a more formal way for automatic things like kernel upgrades to go through
<samueldr> there is a lack of transparency about that specific process (kernel upgrades)
<endocrimes> I’m not fundamentally against it, but for core package bumps that don’t build it’s kinda... scary
<endocrimes> It feels like we should invest the time in our contribution process to make it so that that isn’t necessary though
<samueldr> "core package bumps that don’t build" ?
<endocrimes> 5.9.5 kernel only builds on arm
<endocrimes> But got committed to master today
<samueldr> do you have a link to the hydra failure already on hand?
<samueldr> (after all, hydra is part of that problem. master is the "fresh changes in" branch, not one to use daily)
<samueldr> (part of the solution to that problem*)
<samueldr> at least, that's the reasoning I understand
<endocrimes> Not now, shut down my computer already
<samueldr> queued, nothing failed yet
<samueldr> (at least on nixpkgs:trunk)
* colemickens always finds the committing to master weird, but then isn't sure how maintainership is handled in other distros
<samueldr> I think the main issue is: we lack the tooling to completely disallow it
<samueldr> and the social aspect is that people will do it since they can
<samueldr> on master:
<samueldr> 20.03..20.09: 3782 commits on master, (17.59%) 21506 total commits.
<cole-h> Has it been fixed? Because `nix build .#linuxPackages_latest.kernel` is working for me (so far)
<samueldr> that's 3782 commits between 20.03 and 20.09 that couldn't be resolved to PRs
<cole-h> Unless it was an actual build issue and not an eval issue
<samueldr> I would assume build issue
<samueldr> hmm, looking at my numbers, even though the total number of commits increase, the absolute amount of direct-to-master commits decreased
<cole-h> In that case, building now.
<samueldr> "possibly rebased commits" are commits which were found in PRs
<cole-h> Indeed, build problem.