NinjaTrappeur has quit [Ping timeout: 264 seconds]
cole-h_ has quit [Ping timeout: 265 seconds]
NinjaTrappeur has joined #nixos-dev
supersandro2000 has quit [Disconnected by services]
supersandro2000 has joined #nixos-dev
rajivr has joined #nixos-dev
NinjaTrappeur has quit [Ping timeout: 244 seconds]
NinjaTrappeur has joined #nixos-dev
ris has quit [Ping timeout: 256 seconds]
evils has quit [Ping timeout: 246 seconds]
evils has joined #nixos-dev
teto has quit [Ping timeout: 272 seconds]
s1341_ has quit [Quit: Connection closed for inactivity]
<siraben>
tazjin: that's crazy, imagine the amount of conflicts and constant rebases
<siraben>
or do rebases not scale when you have dozens of people working on the same branch
orivej has joined #nixos-dev
cole-h_ has joined #nixos-dev
cole-h_ is now known as cole-h
srk has quit [Remote host closed the connection]
srk has joined #nixos-dev
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-dev
jonringer has quit [Ping timeout: 264 seconds]
orivej has quit [Ping timeout: 276 seconds]
orivej has joined #nixos-dev
pmy has quit [Quit: WeeChat 3.1]
pmy has joined #nixos-dev
pmy has quit [Client Quit]
pmy has joined #nixos-dev
cole-h has quit [Ping timeout: 264 seconds]
orivej has quit [Ping timeout: 264 seconds]
evanjs has quit [Read error: Connection reset by peer]
evanjs has joined #nixos-dev
teto has joined #nixos-dev
<tazjin>
siraben: everything is (conceptually) rebase only at Google, and your unit of work is always one commit equivalent - I'd suspect Uber is the same. This means the problem doesn't come up for the most part
pmy_ has joined #nixos-dev
evils_ has joined #nixos-dev
pmy has quit [*.net *.split]
evils has quit [*.net *.split]
devhell has joined #nixos-dev
__monty__ has joined #nixos-dev
Raito_Bezarius has quit [Ping timeout: 264 seconds]
evils_ has quit [Ping timeout: 264 seconds]
mkaito has joined #nixos-dev
Raito_Bezarius has joined #nixos-dev
mkaito has quit [Quit: WeeChat 3.1]
mkaito has joined #nixos-dev
mkaito has joined #nixos-dev
Synthetica has joined #nixos-dev
orivej has joined #nixos-dev
AlwaysLivid has joined #nixos-dev
pmy_ has quit [Quit: WeeChat 3.1]
orivej has quit [Ping timeout: 264 seconds]
pmy has joined #nixos-dev
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 265 seconds]
orivej has joined #nixos-dev
mkaito has quit [Read error: Connection reset by peer]
orivej has quit [Ping timeout: 246 seconds]
pmy has quit [Quit: WeeChat 3.1]
pmy has joined #nixos-dev
pmy has quit [Client Quit]
orivej has joined #nixos-dev
mkaito has joined #nixos-dev
mkaito has joined #nixos-dev
mkaito has quit [Changing host]
orivej has quit [Ping timeout: 256 seconds]
tv has quit [Ping timeout: 245 seconds]
tv has joined #nixos-dev
orivej has joined #nixos-dev
adisbladi is now known as adisbladis
<gchristensen>
so Nix technically allows for packages to have `.`s in attribute names
<gchristensen>
should Nixpkgs?
orivej has quit [Ping timeout: 256 seconds]
<siraben>
would be confusing
<siraben>
what does `foo.bar.baz` mean?
<gchristensen>
that has a clear meaning(ish), foo."bar.baz" would be how to do it
<siraben>
ah
<adisbladis>
I think the answer is nuanced
<adisbladis>
Which packages are you thinking of where this would be relevant?
<Synthetica>
Doesn't sound like something we want to do on first glance, what's your intended usecase? Version numbers?
<adisbladis>
I tend to think that we should follow upstream names ~110% of the time
<sterni>
gchristensen: it would be a pain to specify nix-build -A \"foo\" on the command line
<niksnut>
gchristensen: no, and also it shouldn't have package names starting with digits
<gchristensen>
usecase? none. I'm looking at some deep dark Hydra code :)
<niksnut>
nix-env filters them out
<gchristensen>
hmm yeah
<jtojnar>
kill nix-env then
<niksnut>
IIRC hydra also filters out bad attribute names
<sterni>
adisbladis: we probably should make an effort to get closer to that but not sure if dots contained is the place to start :p
<niksnut>
because dots definitely break the project.jobset.job notation
<gchristensen>
for sure, right
<sterni>
niksnut: attribute names starting with a number are a parse error though, right?
<siraben>
Ah, but no way to workaround the nul byte
<siraben>
heh
<siraben>
wanted to do lib.ord 0
<siraben>
I mean lib.chr 0
<sterni>
nul byte is strictly off limits
<siraben>
aw shucks
rj_ has joined #nixos-dev
orivej has joined #nixos-dev
s1341_ has joined #nixos-dev
rng4 has joined #nixos-dev
teto has joined #nixos-dev
b42 has quit [Ping timeout: 264 seconds]
b42 has joined #nixos-dev
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-dev
cole-h has joined #nixos-dev
devhell has quit [Quit: leaving]
teto has quit [Ping timeout: 256 seconds]
<rmcgibbo[m]>
Does anyone understand why hydra would show "This job is not a member of the latest evaluation of its jobset. This means it was removed or had an evaluation error." for a package on aarch64-linux (but not x86_64-linux)? But (a) I don't actually see an evaluation error in the tab that shows all of the evaluation errors, and (b) ofborg didn't throw an evaluation error either, and showed it as a changed attr.