<samueldr>
the PR being accepted pushed me into taking another look into the framework and all (also, at the time I implemented the PR I was "deep" into learning and getting tired)
<samueldr>
seems convoluted, also considering it's the whole repo for the patches; I've seen generally a fetcher function which takes { patchName, sha256 } and that fetchpatches the patches
<samueldr>
through a proper url for the service
<worldofpeace>
Most things I do are covoluted, though I did this because I'm not familiar with launchpad's urls
<samueldr>
looks like they're cgit
<worldofpeace>
And I hate updating hashes for the patches, and I don't want an ad-hoc script
<samueldr>
hm, I thought there was a fetchCgit that could be used to compose more specific fetchers
<samueldr>
did I dream that?
<worldofpeace>
Dreams are real, though this one isn't yet :)
<samueldr>
though yeah, I see how an ad-hoc script and maintaining the hashes could be annoying; I also do not like the ad-hoc solutions
<samueldr>
there may be enough reuse to warrant *something* to handle those kind of repos, debian and ubuntu copies of the upstream source, with a `debian/patches/*.patch` list of patches to pick from
<worldofpeace>
I was thinking the same thing, almost wish they kept the patches in a separate branch
<samueldr>
and the series file (needed to know the order)
<worldofpeace>
and possibly specifing which patches you'd like ommitted, removing them from it
<samueldr>
anyone knows reasons to avoid subshells?
<samueldr>
e.g. here you could use a subshell to set exglob to any value you like without caring to set it back to what it was
<worldofpeace>
I thought of that as well. I think it would be preferred
<ekleog>
ivan: it's the kind of things that could live into NUR
<samueldr>
worldofpeace: though same caveat as fetchFromGitHub, it'd need to hash the contents
<worldofpeace>
samueldr: thanks, fetchgit isn't preferred after all
<samueldr>
dunno
<samueldr>
just continuing the train of thought from earlier
<samueldr>
fetchgit might be fine
<samueldr>
so it would need to use fetchzip to hash properly
<worldofpeace>
samueldr: oh you meant getting a fetchCgit
<gchristensen>
i sort of prefer the hash-per-patch style, since it minimizes reasons to change the hash... but it isn't a big deal I guess
<samueldr>
yeah, there are pros and cons to both; a list of patch + hash is unwieldy and annoying to generate
<samueldr>
while a "debianSeries" thing could hide a bunch of complexity, maybe too much
<gchristensen>
yeah
<gchristensen>
in the case of sources, including patches, the hash is the ID of the source -- which is what makes me value it a lot
<samueldr>
though I feel having a unified interface to debian series would be good since I can see a bunch of differing implementations, and probably some that I don't see
<worldofpeace>
err seeing plasma in nixpkgs using `lib.readPathsFromFile` :)
<gchristensen>
hrm?
<samueldr>
(not working on that btw, just thinking about it at a high level since I'm not 100% sold)
<samueldr>
I feel both solutions have the same "weight" in pros and cons, so status quo it might be
<worldofpeace>
maintain the status quo, or the altrusitic solution is always the question
<samueldr>
because yeah, sha256 of one patch means that patch hasn't changed
<worldofpeace>
Though I agree that the hash is the proper id of the source
<samueldr>
while hashing the picked series could easily allow introducing nastyness
<samueldr>
maybe what's needed is an interface to that, but still keeping the name/hash pairs
<worldofpeace>
That strikes a nice balance, I wouldn't mind updating all these hashes if I didn't have to write yet another silly script
<samueldr>
hashes shouldn't change unless they change the patches, so it's good
<worldofpeace>
True, though certain projects go through lots of rotation
Lingjian has joined #nixos-dev
eadwu has quit [Ping timeout: 250 seconds]
eadwu has joined #nixos-dev
Lingjian has quit [Ping timeout: 252 seconds]
drakonis_ has joined #nixos-dev
teto has joined #nixos-dev
lopsided98 has quit [Quit: Disconnected]
bgamari has joined #nixos-dev
lopsided98 has joined #nixos-dev
MP2E has quit [Remote host closed the connection]
lopsided98 has quit [Quit: Disconnected]
lopsided98 has joined #nixos-dev
worldofpeace_ has joined #nixos-dev
worldofpeace_ has quit [Read error: Connection reset by peer]
worldofpeace__ has quit [Remote host closed the connection]
orivej has joined #nixos-dev
MichaelRaskin has quit [Quit: MichaelRaskin]
__Sander__ has joined #nixos-dev
Phillemann has joined #nixos-dev
orivej has quit [Ping timeout: 272 seconds]
<Profpatsch>
gchristensen: haha, I’ve been needing something like this. Awesome.
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-dev
eadwu has joined #nixos-dev
phreedom has quit [Remote host closed the connection]
phreedom has joined #nixos-dev
<ivan>
I want the hardened kernel to run 32-bit binaries because that's the only hardening that breaks 3 of my use cases but https://github.com/NixOS/nixpkgs/pull/53511 is going the other way
<{^_^}>
#53511 (by joachifm, 2 weeks ago, open): linux: flag to indicate 32bit emulation support
phreedom has quit [Remote host closed the connection]
phreedom has joined #nixos-dev
eadwu has quit [Ping timeout: 264 seconds]
<ivan>
{32-bit stdenv for building things, steam, wine}
eadwu has joined #nixos-dev
srk has quit [Ping timeout: 244 seconds]
srk has joined #nixos-dev
<sphalerite>
ivan: I'd suggest not using the hardened kernel :p
<ivan>
sphalerite: it seems fine to me otherwise
orivej has quit [Ping timeout: 246 seconds]
<ivan>
I just removed that one config option
__Sander__ has quit [Quit: Konversation terminated!]
cransom_ is now known as cransom
orivej has joined #nixos-dev
ixxie has joined #nixos-dev
aszlig has quit [Quit: Kerneling down for reboot NOW.]
<worldofpeace>
I'd also want to see a contributors handbook :)
<infinisil>
worldofpeace: The nixpkgs manual has a bit on that, not a lot thoughg
<ixxie>
worldofpeace: there is the wiki, you can easily add sections to that
<worldofpeace>
infinisil: I'm actually pretty interested in writing one, as I've done a lot of observation, I also feel like handbook is a softer word to use
<worldofpeace>
ixxie: Was just thinking that :)
<worldofpeace>
However I'd like things to be formalized
<samueldr>
at 22:xx UTC a build was marked finished at 23:xx UTC
<samueldr>
oops
<samueldr>
at 22:xx UTC a build was marked finished at 23:xx
<LnL>
I just assumed it was, time and dates is hard enough without timezones
<samueldr>
sure, and it is close enough to UTC not to ask too many questions :(
<samueldr>
except I was cross-referrencing failures with grafana... one hour off
<LnL>
yeah exactly
<samueldr>
sadly, nothing exciting in the graphs at those moments
<LnL>
guess what happened to the reasonable worker task timeouts of an hour
<LnL>
if it was looking at a database model without timezone information
<samueldr>
0 minutes or 120 minutes
<LnL>
:D
<LnL>
it was zero in this case and not reproducible because everybody's machine was using the local timezone instead
eadwu has quit [Ping timeout: 250 seconds]
<ekleog>
niksnut: would it be possible to open the issues on NixOS/rfcs? I'm seeing issues tagged [RFC] on nixpkgs, that I'd like to close and point to from an issue on NixOS/rfcs. These would be used just like for rust-lang/rust: as a way of keeping track of things that would deserve an RFC should one gather enough motivation to write one, a sort of “pre-RFC” stage
<samueldr>
(joking) write an RFC for that
<ekleog>
it's like the third time I'm suggesting this, each time pinging someone else, up to now everyone I've tried pinging didn't have the rights on the rfcs repo, so… it may be a last-resort option :p