globin has quit [Remote host closed the connection]
globin has joined #nixos-dev
<andi->
Is hydra having difficulties with channel bumps (again)? NixOS 18.09 is ~7d old now, there was a successful `tested` job execution about 9h ago.
orivej has joined #nixos-dev
<srhb>
andi-: Most of them are held up by incomplete evaluations. aarch64 has been the slowest lately in most cases.
<srhb>
andi-: But yeah, it looks like there are several candidates that are complete and should have bumped the channels, so it does seem likely that the channel bump script is shot.
<samueldr>
though, with only about a day and a half going, removing the epyc machine seems to help? how long should we keep this up to try and better feel if it helped or not?
<samueldr>
aszlig: whenever convenient for you, you may want to follow up whether or not your mail got to the recipient, and the list, as it doesn't show up on the web interfaces still
arianvp has quit [Quit: WeeChat 2.2]
arianvp has joined #nixos-dev
<gchristensen>
maybe that one binned it too
Synthetica has joined #nixos-dev
<gchristensen>
tragically, renaming the labels to drop comments, ie: 1,000 renamed to 1000
<infinisil>
Would require a mass refactor of nixpkgs, but I'm thinking about starting with this
<gchristensen>
that would be a massive project
<gchristensen>
would require a lot of strategy, I think, around how to introduce and release it
<infinisil>
Well the general idea is probably gonna be: add an option to enable secure settings by default (for systemd services), convert all services over over time by setting this option to true. Prepare for switching the default to true by informing users via a deprecation warning. Switch the default to true
<gchristensen>
you're 50% to an RFC :)
<infinisil>
Yeah
<infinisil>
I've been thinking about looking for a job when I'm done with this semesters exams, but now I'm thinking it might be a good idea to do lots of work on nixpkgs with stuff like that and opening a patreon/<other donation site> for that
symphorien has quit [Quit: WeeChat 2.3]
<gchristensen>
there might be grants available to improve the nixpkgs / nixos ecosystem, depending on what you want to work on
<infinisil>
How does that work?
<gchristensen>
also, you're probably not going to make enough off patreon / whatever to make it work. I don't know of any/many project(s) which manage to do that. BUT this sort of stuff is super relevant to the interests of, say, mayflower, tweag, flyingcircus
<gchristensen>
(full time, anyway)
<gchristensen>
there are some grant programs through the EU
<lassulus>
We have a lot of users > 65536, it works fine, there are problems above MAX_INT though
* gchristensen
has an idea
<lassulus>
But DynamicUsers is the way to go
<gchristensen>
I could rewrite all my users to be >65536 and see how it goes. none of my services' user data retains anyway
<infinisil>
gchristensen: I see, well I wouldn't really care how much I'll make (I don't really need money right now). I'm mainly looking to have some motivation to work on this (other than "I want to improve nixpkgs"), because it sure does take a lot of time
<gchristensen>
mind if we take this to a PM?
<infinisil>
And to actually make things people want, to have some pressure too
<infinisil>
gchristensen: No problem
andi- has quit [Ping timeout: 250 seconds]
andi- has joined #nixos-dev
__Sander__ has quit [Quit: Konversation terminated!]
<edef>
I'm not really sure what to do about that? It's very clearly working on NixOS, so either the macOS builder is uniquely broken or GitHub is serving inconsistent tarballs to it, by my best guesses.
<samueldr>
fetchFromGitHub should be hashing the contents
<gchristensen>
sometimes this problem is from filenames
<edef>
Hm. I'm not sure what to do about that.
<edef>
I guess I could switch things to the official source tarballs, which seems like a better move than fetchFromGitHub anyway.
<infinisil>
worldofpeace: I think it should be fine to not run the tests. Assuming they have tested the package a bit, the chance of the tests failing is pretty much nil (minus network related failures)
apaul1729 has quit [Remote host closed the connection]
ivan has quit [Quit: lp0 on fire]
harrow has quit [Ping timeout: 245 seconds]
harrow has joined #nixos-dev
ivan has joined #nixos-dev
q6AA4FD has quit [Read error: Connection reset by peer]
<worldofpeace>
edef: I think the macos filesystem does some weird unicode normalization to certain files. Though I really don't think we need to use fetchzip for github anymore.
<samueldr>
all github archives are not guaranteed to be stable, so it still is an issue
<samueldr>
(and while I say github, any fetchArchiveThatIsBuiltOnTheFly is going to have the same issue)
<samueldr>
unless server-side they use one of the reproducible tar tools
<worldofpeace>
Idk I don't think it's been a problem that github has had for a while now. Might need some research
<samueldr>
I recently had an issue with it, on a personal thing
orivej has quit [Ping timeout: 240 seconds]
orivej_ has joined #nixos-dev
<samueldr>
it's not frequent when it happens
<worldofpeace>
Ah now I remember, infrequent but still producable
<samueldr>
which is a reason to prefer a source release from the upstream projects if they do them, evne if fetchFromGitHub works the same way
<worldofpeace>
+1 on that, I do that in practice
<ekleog>
samueldr: personal opinion: I much prefer fetchFromGitHub
<ekleog>
because it makes it easier to patch projects, as one doesn't have to figure out the steps upstream uses to go from the GitHub to the tarball
<ekleog>
(well… as it's done in nixpkgs, not by the end-overrider)
<ekleog>
also, because there's quite a bit more accountability in the GitHub than in the source tarball, because a source tarball can include some auto-generated stuff no-one wants to review and that could be backdoored
<ekleog>
and finally, because it's in the policy of “only use source distribution”, which is defined by the GPL as the preferred way of working with the source, which is in the GitHub and not in the release tarball
<samueldr>
not sure how to reply, since I see and understand entirely the point, but I'm not sure it's "right" to go and use whatever source instead of the released sources... but I guess only in a handful of cases there would be real differences, so there's no real worry
<ekleog>
yeah, same here, anyway everyone will use what they'd rather and that'll be fine this way, we need more package updates/additions than we need bikeshed about which one is best :)
<samueldr>
though I agree, I also disagree on one point: there's only status quo, no documentation, so bikeshed will happen on that front at some point, and for contributors the same could apply, they wouldn't know which to prefer :/ something in the contributor guide like "Prefer using ... as the source, since .... Except if ..." could help streamline those, but then bikeshedding *that* will be a pain possibly
<samueldr>
(so status quo might still be the better alternative for now)
q6AA4FD has joined #nixos-dev
<ekleog>
maybe someone will find the motivation to write up a RFC
<andi->
srhb, samueldr: #53935 might be an issue but I think we are also seeing another issue with the channel bumps. https://hydra.nixos.org/jobset/nixos/release-18.09/latest-eval points to the right eval but hydra doesn't pick it up for nixos.org/channels/. I guess only niksnut can have a look onto the actual machine to figure out what happens?