bhipple has quit [Remote host closed the connection]
matthewbauer has joined #nixos-dev
cole-h has quit [Quit: Goodbye]
drakonis has quit [Ping timeout: 246 seconds]
octe has quit [Ping timeout: 240 seconds]
<MichaelRaskin>
I wonder why all these special measures to forbid push to origin. Is it just me who assigns origin to my fork and upstream to the mainline? (I still sometimes push small tested fixes to master, but it has to be not just git push but a more explicit command)
<MichaelRaskin>
domenkozar[m]: re: false positives in banning — after remembering the bans applied in Nix*, I have a pretty strong suspicion that some of the (perfectly justified) bans you have applied at GH required understanding the conversations to decide, and I would be surprised if these did not take the most effort anyway…
FRidh has joined #nixos-dev
<domenkozar[m]>
so far I banned two people which due to style we suspect it was the same asshole that was insulting everyone around :)
FRidh has quit [Quit: Konversation terminated!]
<MichaelRaskin>
I am not sure there is a chance to calibrate Discord people to make sure they pick up just on insults.
<MichaelRaskin>
For us it is obvious that he was basically saying «your preferences are wrong» in half of the messages, which … does not have a chance to be constructive
<domenkozar[m]>
yeah it's tricky I agree with you
<domenkozar[m]>
I wouldn't say that discord solve this particular problem as a selling point, but rather ease of use
<MichaelRaskin>
I fully expect their false positive rate to be strictly higher than true positive (unless both are zero), so nobody who has time to actually understand the conversation having an option to override unconditionally is a drawback
<MichaelRaskin>
Discord is pretty high on my list of annoying UIs
<MichaelRaskin>
(but using reCaptcha is enough to get there)
<domenkozar[m]>
oh why do you find it annoying UI?
<MichaelRaskin>
Well, it starts by using reCaptcha which already primes me to dislike it (it continues to extort a phone number an hour later just to make sure)
<domenkozar[m]>
even if you register?
<MichaelRaskin>
Yes, specifically if I register
<domenkozar[m]>
interesting, I never got asked for a phone number
FRidh has joined #nixos-dev
<MichaelRaskin>
Maybe you were logged in with a Google account and reCaptcha reported this
<Profpatsch>
MichaelRaskin: Oh, Github has some data consistency issues all right. e.g. we had jwiegley merge our PRs for quite some time, even though he never touched our project. It’s just Github shuffling things up.
<MichaelRaskin>
«pushed 0 commits»
<Profpatsch>
As long as the source of data is the git repo *looks at issue and PR tabs* oh, crap
<MichaelRaskin>
And I remember that time where comments showed up and did not show up at random, and however many times people reposted the comment after it not showing up, all of these arrived an hour later
<Profpatsch>
That’s a normal occurence when they have a problem, their internal queues get blocked and are released when webhooks are back up.
<MichaelRaskin>
Well, git is kind of bad at data consistency in some cases… oh wait, GH uses their own implementation, we know nothing
<Profpatsch>
I haven’t seen any comments lost so far though
<MichaelRaskin>
Profpatsch: it was not a blocked queue, it was a DB split-brain quite clearly
<MichaelRaskin>
With reloads being served from different sides of a split
<Profpatsch>
or that. It’s a hard problem when you serve all of OSS at the same time.
<Profpatsch>
But you can do lots of data mining.
<MichaelRaskin>
Well, one entity serving all of the OSS _is_ the problem
* Profpatsch
used irony. It’s very effective!
<MichaelRaskin>
But really, by-project sharding with rare rebalancing is kind of well-known, so serving more projects should not be a consistency problem
<MichaelRaskin>
Serving even one large project might be, sure
<srk>
more reasons to consider alternatives before it's too late
<MichaelRaskin>
Arguably, setting up scraping the discussions is the main thing that needs to be done before it's too late
<MichaelRaskin>
NisOS has homepage on the own domain, so proving continuity during a migration would be feasible
__monty__ has joined #nixos-dev
Mic92 has quit [Quit: WeeChat 2.7]
Mic92 has joined #nixos-dev
orivej has joined #nixos-dev
octe has joined #nixos-dev
ciil has joined #nixos-dev
ciil has quit [Client Quit]
ciil has joined #nixos-dev
ciil has quit [Client Quit]
<Profpatsch>
nixpkgs would never have reached this level of success and community-based effort if it weren’t for Github. Bless.
ciil has joined #nixos-dev
<MichaelRaskin>
I think this should be qualified with «in a world where GH has achieved network-effect domination»
Jackneill has joined #nixos-dev
harrow has quit [Ping timeout: 250 seconds]
FRidh2 has joined #nixos-dev
phreedom has quit [Ping timeout: 240 seconds]
FRidh has quit [Read error: Connection reset by peer]
phreedom has joined #nixos-dev
harrow has joined #nixos-dev
orivej has quit [Ping timeout: 256 seconds]
avn has joined #nixos-dev
orivej has joined #nixos-dev
leonardp has joined #nixos-dev
MoreTea has quit [Quit: WeeChat 1.9]
<yorick>
pie_[bnc]: please rebase the PR, some of the changes did make it in
<yorick>
pie_[bnc]: we worked around this by not evaluating on the target hosts ever
phreedom has quit [Remote host closed the connection]
phreedom has joined #nixos-dev
Cale has quit [Ping timeout: 260 seconds]
phreedom has quit [Remote host closed the connection]
phreedom has joined #nixos-dev
phreedom_ has joined #nixos-dev
phreedom has quit [Remote host closed the connection]
orivej has quit [Ping timeout: 250 seconds]
leonardp has quit [Remote host closed the connection]
ryantm has quit [Ping timeout: 256 seconds]
ryantm has joined #nixos-dev
phreedom_ has quit [Remote host closed the connection]
phreedom has joined #nixos-dev
Cale has joined #nixos-dev
<timokau[m]>
Does anyone know what's going on with the linux.x86_64-linux test job?
<Ericson2314>
cole-h: I should just submit to your fork of Nix first :D
<cole-h>
LOL
<cole-h>
Feel free :P
<drakonis>
RIIR
<cole-h>
Slowly but surely
<cole-h>
>:)
<drakonis>
when's rewrite in racket :V
<cole-h>
Ericson2314: Don't forget the `ideomatic` in your commit message ;^)
lopsided98 has quit [Quit: Disconnected]
lopsided98 has joined #nixos-dev
<drakonis>
oh a quick reminder that the submission period for the google season of docs is taking place
<drakonis>
soon taking place, rather.
<Ericson2314>
cole-h: it is one commit so I might just squash merge to do that :D
<cole-h>
As long as you don't forget ;^)
Cale has quit [Ping timeout: 260 seconds]
Cale has joined #nixos-dev
CRTified has quit [Ping timeout: 240 seconds]
lovesegfault has joined #nixos-dev
<ma27[m]>
are there any objections against merging https://github.com/NixOS/nixpkgs/pull/40082 (mongodb updates) and backporting it to 20.03? As it builds and works fine (including the aarch64 stuff now), I'd merge tomorrow. If we don't do this, mongodb will be unusable by default in 20.03 as it currently depends on openssl 1.0.1 which is marked as vulnerable in our package set.
<Ericson2314>
niksnut: I've now opened up a big ol' bunch of Nix PRs; I'd be happy to help you make sense of them all in real time at some convenient European hour if you like :)
<worldofpeace>
ma27: I'm guessing there isn't a more minor change that could be made so it builds without unsecure openssl?
garbas has quit [Ping timeout: 250 seconds]
<worldofpeace>
we marked the old version of openssl as a freeze exception, not sure how we didn't catch this one earlier
<colemickens>
How are qt5 updates usually handled? Is there someone working on 5.14? (I didn't see any open issues/prs)
<worldofpeace>
* marked the old version of openssl as insecure in a freeze exception
<worldofpeace>
Cole Mickens: It's a very difficult upgrade
<{^_^}>
#74355 (by jpathy, 17 weeks ago, open): Qt needs update to 5.14 and more maintainers
<colemickens>
Well, I guess it's probably not trying to pretend to be semver, probably a bad assumption on my part.
<colemickens>
-_- maybe I searched "qt5 5.12" instead of "qt". anyway, I'll read up. thanks.
<worldofpeace>
Cole Mickens: "need to be significantly overhauled" and expecting completely rewritten patches
<colemickens>
the url looks ominous anyway
<ma27[m]>
worldofpeace: you're right, it would be sufficient to backport the mongodb 3.4 update (3.4.10 -> 3.4.24). (as the changeset is quite big I would've openend a backport-PR anyway :))
<worldofpeace>
Woah, that PR has been open since 2018
<drakonis>
well now
<ma27[m]>
worldofpeace: btw sorry to bother you with that one as well, but would you mind taking a brief look at https://github.com/NixOS/nixpkgs/pull/82353 ? (creates a safe upgrade path for nextcloud between 19.09 and 20.03, so this is something that should land in the release IMHO)
<{^_^}>
#82353 (by Ma27, 1 week ago, open): nixos/nextcloud: fix upgrade path from 19.09 to 20.03
<worldofpeace>
ma27: Oh no, it isn't a bother. This is what I should do as an RM 😁 That PR was on my radar, it just looked pretty big.
<worldofpeace>
ma27: I can look now.
<ma27[m]>
awesome, thanks! :)
ixxie has joined #nixos-dev
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-dev
<lovesegfault>
When was staging merged last?
<lovesegfault>
it feels like it's been a long time
<lovesegfault>
It was 20 days ago, by bhipple and merged by FRidh
<lovesegfault>
Almost a month :(
<worldofpeace>
lovesegfault: we just got gnome 3.36, so expect it fairly soon
<lovesegfault>
worldofpeace: oh, nice
<worldofpeace>
* gnome 3.36 in staging
<lovesegfault>
I was about to make the PR to merge staging to staging-next
<lovesegfault>
FWIW: The current SPOF and lack of clarity around staging is a bit of a bummer
* lovesegfault
does not understand how it works. staging -> staging-next -> ??? -> profit
<worldofpeace>
lovesegfault: I frequently forget the merge strategy, but I believe the flow is staging -> staging-next -> master
<worldofpeace>
lovesegfault: yeah, currently only two people basically handle those iterations IIRC
<lovesegfault>
worldofpeace: two? I thought it was only FRidh?
<worldofpeace>
lovesegfault: also vcunat, who does a lot of things to keep stuff flowing
<worldofpeace>
lovesegfault: yeah, maybe we should productively complain 🤣
<lovesegfault>
worldofpeace: is that RFC accepted?
<lovesegfault>
(26, that is)
<worldofpeace>
lovesegfault: all accepted rfcs are in that directory, so yes.
<lovesegfault>
worldofpeace: it's kind of nuts to have an accepted RFC that puts docs as future work :(
<worldofpeace>
lovesegfault: I agree, but also, think about it. Would you commit to writing docbook?
<gchristensen>
hah
<lovesegfault>
lol
<worldofpeace>
hehe, I'm a bit shady today.
<domenkozar[m]>
worldofpeace++
<{^_^}>
worldofpeace's karma got increased to 79
<worldofpeace>
It would have been easier to have drafted the docs in the RFC
<domenkozar[m]>
wow that's a nice karma scoring
<domenkozar[m]>
should've started counting when I was release manager :P
<lovesegfault>
FWIW: the real issue with docs is that Nix doesn't support inline docs like Rust
<worldofpeace>
domenkozar++
<{^_^}>
domenkozar's karma got increased to 26
<worldofpeace>
domenkozar: I'm coming for those stickers/thingy that gchristensen promised high karma havers
lovesegfault has quit [Quit: WeeChat 2.7.1]
<domenkozar[m]>
seems like you'll need two
lovesegfault has joined #nixos-dev
<tilpner>
,loot worldofpeace
<{^_^}>
worldofpeace: [2018-05-26 20:24:58] <gchristensen> 25 points gets you a sticker, 100 points gets you a t-shirt, 1000 verified points gets you a free trip to nixcon *restrictions apply, must be verifiable points, given by grateful people, in channels I'm in
<gchristensen>
oh no
<domenkozar[m]>
well I was wrong, 3 stickers
<domenkozar[m]>
so does a 1000 give you 40 stickers and 10 t-shirts?
<worldofpeace>
gchristensen: I believe clever is just exempt from the loot rule?
ixxie has quit [Ping timeout: 240 seconds]
<gchristensen>
worldofpeace: more that I'm derelict in my promise
<lovesegfault>
thx worldofpeace++
<{^_^}>
worldofpeace's karma got increased to 80
<infinisil>
I want a builtin like `builtins.attrsFromFunction f` where f is a function that takes an attribute name and returns either {} if it doesn't exist, or { value = <value>; } if it does exist
__monty__ has quit [Quit: leaving]
<infinisil>
And that builtin would then return a "pseudo attribute set", which behaves like an attribute set (except that you can't builtins.attrNames on it)
<gchristensen>
why?
<infinisil>
This allows working around the problem of attribute sets being strict in keys
bachp has joined #nixos-dev
<infinisil>
Maybe types.lazyAttrsOf wouldn't be necessary if this existed
* gchristensen
is still not what the problem is :x hehe
<puck>
infinisil: hrmm, so basically a function that generates an attrset on-the-fly
<infinisil>
Although, on the other hand, if you don't know what names an attribute set has, I'm not sure how useful it would still be
<infinisil>
puck: Yea
<infinisil>
This means you could do `attrset ? key` and `attrset.key` without evaluating all other keys
<puck>
mm
<gchristensen>
I'm not sure if you're trying to answer my question or something else :P
<puck>
i thought of this before and was actually considering implementing something similar, but that's mostly because i have tooling that allows you to return different values from the same lambda call
<infinisil>
I hope you're not using that in actual code!
<puck>
sadly no :p
<puck>
if only it worked on remote stores
<infinisil>
puck: Check what I wrote in #nix-lang though, just found another case of something like this :)
<ashkitten>
are there instructions for packaging dkms modules?
<ashkitten>
or other out of tree modules
<clever>
ashkitten: you need to do something like `boot.kernelPackages = pkgs.linuxPackages_hardened.extend (self: super: {` and then mirror what nixpkgs does for every other out of tree module
<clever>
ashkitten: and use self.callPackage within that block, to pass it a kernel
<ashkitten>
clever: can't i use boot.extraModulePackages?
<ashkitten>
also i'm looking to get this into nixpkgs, at some point, so that it's available to others
<clever>
ashkitten: that is how you take something from boot.kernelPackages and make it actually usable
<clever>
ashkitten: you would do `boot.extraModulePackages = [ boot.kernelPackages.thing ];`
<clever>
and the extend bit, adds thing to it
<clever>
you could maybe also use `boot.extraModulePackages = [ (boot.kernelPackages.callPackage ./thing.nix {}) ];`