jonringer has quit [Remote host closed the connection]
jonringer has joined #nixos-dev
<__monty__>
s1341_: No let really makes a local scope. Though I wouldn't put it past #nix-lang to find a way to circumvent that.
<sterni>
s1341_: nope, but it is in the set anyways, maybe you could just expose it in all-packages.nix as well?
<s1341_>
sterni: how would i do that...
<s1341_>
?
<sterni>
s1341_: in all-packages.nix there is a inherit (callPackage ../os-specific/linux… {}) linuxHeaders; you could just add makeLinuxHeaders there and PR it if you think that is a good idea
<s1341_>
ok. i will do so.
<s1341_>
thanks.
<s1341_>
sterni: while i have your attention, i'm trying to track down why xorgserver depends on systemd.
<s1341_>
why-depends shows me that Xephyr et al. have systemd in their rpath
<s1341_>
because they link with dbus....
<s1341_>
but I disabled dbus in the xorgserver's derivation.
<s1341_>
but it still pulls in systemd....
<s1341_>
any advice?
<clever>
that reminds me, X appears to be broken on my nas, possible all of nixos-unstable, but i dont see how it got thru testing?
<clever>
Mar 21 15:43:47 nas sddm[2496]: Logind interface found
<sterni>
s1341_: at least that what it seems to me like, you'll have to check I have no clue about xorg compilation in nixpkgs in all honestly
<s1341_>
i removed that when building for android....
<sterni>
*honesty
<s1341_>
sterni: how can I modify the ARCH in that makeLinuxHeaders function?
<andi->
likely udev being a dependency which is just an alias of systemd
<s1341_>
andi! that was it!
<sterni>
s1341_: it statically uses stdenvNoCC, so it's not easily changeable
<sterni>
probably would need some refactoring
<sterni>
making it either overrideable or taking it as an explicit input
<s1341_>
nope andi- that wasnt it...
<s1341_>
andi-, sterni: how can I chase down this dependency??
<sterni>
maybe check nix-store -q --requisites and look for anything suspicious
<sterni>
you can also try playing around with nix-tree
cole-h has joined #nixos-dev
<s1341_>
nix-tree shows a direct dependency on nix-shell.
<s1341_>
s/nix-shell/systemd/
<s1341_>
and the derivation itself really does depend on systemd (if i look at the .drv)
Raito_Bezarius has quit [Ping timeout: 264 seconds]
justan0theruser has joined #nixos-dev
justanotheruser has quit [Ping timeout: 265 seconds]
Baughn has joined #nixos-dev
kcalvinalvin has quit [Quit: ZNC 1.7.4 - https://znc.in]
kcalvinalvin has joined #nixos-dev
ris has joined #nixos-dev
cole-h has quit [Quit: Goodbye]
cole-h has joined #nixos-dev
cole-h has quit [Client Quit]
cole-h has joined #nixos-dev
fhdhhw has joined #nixos-dev
rajivr has quit [Quit: Connection closed for inactivity]
Baughn has quit [Quit: ZNC 1.6.2+deb1 - http://znc.in]
cole-h has quit [Quit: Goodbye]
cole-h has joined #nixos-dev
evils has quit [Ping timeout: 245 seconds]
fhdhhw has quit [Quit: Connection closed]
Baughn has joined #nixos-dev
cole-h has quit [Quit: Goodbye]
cole-h has joined #nixos-dev
cole-h has quit [Client Quit]
cole-h has joined #nixos-dev
cole-h has quit [Client Quit]
cole-h has joined #nixos-dev
Baughn has quit [Quit: ZNC 1.6.2+deb1 - http://znc.in]
cole-h has quit [Quit: Goodbye]
cole-h has joined #nixos-dev
Baughn has joined #nixos-dev
mkaito has quit [Quit: WeeChat 3.1]
<s1341_>
how do you guys work on the cross toolchains and binutils... every change requires rebuilding a ton of packages until you get hello build?
<s1341_>
is there a trick I'm missing?
<infinisil>
s1341_: Are you changing nixpkgs or only the package sources?
<s1341_>
infinisil nixpkgs
<infinisil>
Hm not sure
<s1341_>
:*(
<samueldr>
patience *and* fast machines I guess
<s1341_>
samueldr: well i have a 200 core machine, and i've set it up as a remote builder, but it's not particularly effective... i only get a handful of builds concurrently and i get stuck with a bottleneck every once in a while...
<s1341_>
samueldr: do you have recomendations?
<s1341_>
because my cores are idle and want to be fed!
<samueldr>
sorry, none, I guess you're better equpiped with fast machines than I was
<samueldr>
maybe I had more patience?
<s1341_>
perhaps ;)
tomberek has joined #nixos-dev
<sterni>
which one is the staging jobset on hydra or is there none?
<{^_^}>
#117214 (by siraben, 9 hours ago, open): openjdk/darwin: move version out of name
<sterni>
I'm a bit confused as to why this is happening in unstable-small though maybe there's another issue
<sterni>
since unstable-small doesn't care about darwin?!
<sterni>
ah yeah it does test x86_64-darwin
<sterni>
I'm gonna wait for ofborg and if it's no rebuilds squash and merge
<sterni>
we can change the name attribute some other time I guess, but it triggers > 250 rebuilds due to changed outpaths so might not be the best idea rn
<supersandro2000>
250 rebuilds is nothing
<supersandro2000>
this will be done in no time
<supersandro2000>
it is an eval issue that only occurs when you eval the vscode-extensions.redhat.java
<supersandro2000>
because darwin override jdk to some weird version which is still using name
<supersandro2000>
and rebuild reduction here is just a waste of time.
<supersandro2000>
also because version gets added it still causes a rebuild. reverting that workaround and squash merging that
<sterni>
ok doesn't work without rebuilds
<cole-h>
sterni: just fyi, but your attempt to remove rebuilds won't work because `pname` and `version` are part of the derivation
<supersandro2000>
cole-h: thanks. tried to say that earlier
<sterni>
cole-h: yeah I remembered then :)
<sterni>
cole-h: input hash changes unfortunately
<supersandro2000>
also how should someone know that a channel is blocked if they don't check hydra daily?
<cole-h>
gchristensen: There should be no more channel-blocking issues now. But the failure in https://hydra.nixos.org/build/139585985 should already have been fixed a while ago...
<sterni>
otherwise I can probably just cherry pick it
<sterni>
you can't change the target branch for other ppls prs apparently
<ryantm>
sterni: r-ryantm's PRs are committed against a merge base of staging and master, so you should be able to retarget them by clicking edit at the top of the PR and changing the target branch.
<ryantm>
It doesn't look like you can do that while it is closed though.
<sterni>
ryantm: ohhh
<sterni>
ryantm: thanks that does the trick :)
mkaito has joined #nixos-dev
mkaito has joined #nixos-dev
mkaito has quit [Changing host]
<ryantm>
sterni: woo. If you do that for most people's PRs it will spam the hell out of everyone, but targeting the merge-base fixes that.
<ryantm>
I mean committing on top of the merge base.
<cole-h>
what's the nix option that rebuilds packages a certain number of times to test reprodulity?
<sterni>
ryantm: although I've noticed that it's kind of alright if you change target first and force push afterwards
<cole-h>
--check only does it once
<cole-h>
I thought there was an option that would rebuild N number of times
<ryantm>
--option build-repeat N
<ryantm>
at least that's something in the manual
<cole-h>
ah, --repeat, thanks.
<cole-h>
(build-repeat is a deprecated alias)
<ryantm>
Ah yeah.
<cole-h>
ryantm++
<{^_^}>
ryantm's karma got increased to 36
<ryantm>
sterni: Whenever I change the target of someone's PR, it notifies like 30 people and shows hundreds of commits on the PR. Well, this is based on information from years ago because I would never try it again.
<sterni>
ryantm: wait I got it wrong
<sterni>
ryantm: you need to rebase onto staging first and then change the target branch that way you avoid having the thousands of new master commits in your PR temporarily
<sterni>
but it also has a good chance of pinging a few people by accident I guess
<samueldr>
you can do it locally using `git merge-base` to find the common ancestor, and rebase on that
<samueldr>
then changing the pr target branch will not ping
<ryantm>
Right, that's what r-ryantm does.
<samueldr>
changing the target OR pushing, in either order, has the same probabilities of pinging the whole world
<samueldr>
as long as the merge base is not the same
<ryantm>
So the only hope is to target the merge-base from the start?
<gchristensen>
or force push
<samueldr>
exactly, rebase on merge-base, force push, then you're free to change as you want
<sterni>
you guys sound like professionals
<ryantm>
sterni: Grats on being a comitter now.
<sterni>
ryantm: thx :)
<sterni>
this comes at the perfect time … *checks notes* when I really should start writing that paper
<cole-h>
jk, I can't force-push that PR, they unticked the box :(
<cole-h>
guess I'll open a new PR :)
copumpkin has quit [Remote host closed the connection]