<worldofpeace>
Jan Tojnar: So I've been thinking about how I could wrap switchboard and wingpanel better without hardcode patches or a messy wrapper. I was thinking that maybe wrapGAppsHook could write the arguments it was going to give to makeWrapper in a json format in nix-support. Then in the wrapper for switchboard I could load this somehow and collect all the arguments it was going to give to makeWrapper for each indicator. So
<worldofpeace>
basically it takes those json files as inputs and converts it to bash somehow and produces one proper wrapper.
orivej has joined #nixos-dev
<samueldr>
are pkgsCross'd clang-based stdenv supposed to work?
<samueldr>
went back to the first channel bump introducing pkgsCross, and basically the same error as on current unstable
<samueldr>
hmm, adding a hack to make compiler-rt pass (dummy file in $out), the compiler is for the native platform
<clever>
adisbladis: i think 1733a6f94156b849a8b8b567607cd693615ff6b1 broke the build of qt59.qtbase, i can look into it more in about 8-ish hours if you havent by then
<das_j>
andi-: I though this was generally the case for src = [any derivation]
<andi->
no, `src = fetchFromGitHub` qualifies for that as well. `fetchFromGitHub` is a fixed output derivation.
<andi->
,ifd das_j
<{^_^}>
das_j: import-from-derivation (IFD) is when you evaluate nix from a derivation result, for example `import (pkgs.writeText "n" "1 + 1")` will evaluate to 2. This is sometimes problematic because it requires evaluating some, building some, and then evaluating the build result. It has been described as "such a nice footgun."
<das_j>
thanks!
<das_j>
hmm, but doesn't evaluating brotli also evaluate the src?
<andi->
das_j: the actual result of `gitsrc` doesn't change the build script nix is going to run. The build might fail but nix doesn't eval any nix code from `gitsrc`.
<das_j>
but src is an input for the derivation, so the hash of it should matter. it's not a fixed output derivation because it's a runCommand
<Taneb>
Fun fact: Hydra will insert each mandatory system feature of a machine into its list of supported features twice
<andi->
das_j: all our packages are (mostly) not fixed output derivations but they depend on inputs that are fixed output derivations. IFD is not really about where the sources come from but where the nix expressions come from. e.g. what nix code is being executed and usually also requires an `import` statement to be present. In your example there is no input that might change over time. If you would
<andi->
use `import` on some downloaded files then those could be using e.g. `builtins.currentTime` and that could change the execution in the future.
<andi->
as far as I can see that is used by `nixos/tests/os-prober.nix` but that isn't run on hydra as far as I can tell... Mine tried to execut it even tho I didn't lift the restric eval thing..
<das_j>
ah I saw that somewhere in the kernel build as well
<gchristensen>
zimbatm and I had specced out a project called "death to noPos" for a clientonce but they didn't bite :(
<domenkozar[m]>
who would do the work?
<gchristensen>
he and I was going to
<zimbatm>
it's weird to see my nick and "C++ hero" in the same sentence
<domenkozar[m]>
I'm willing to organize crowdfunding
<domenkozar[m]>
if you share the spec :)
<gchristensen>
not sure howmuch of a spec we wrote :x
drakonis_ has joined #nixos-dev
psyanticy has joined #nixos-dev
drakonis has quit [Ping timeout: 276 seconds]
<LnL>
has anybody here ever tried to build clang from git before?
<clever>
adisbladis: youll need to fix plex-media-player to not use 5.9 then
<jtojnar>
worldofpeace yeah, that would work (it is similar to propagatedUserEnvPkgs, but with more limited scope), though I would still consider patches less messy
__monty__ has joined #nixos-dev
<clever>
adisbladis: i'll see what happens if i bump the qt in plex...
<worldofpeace>
Jan Tojnar: Wishing there was function in glib that allows you to add to the directories schemas sources are loaded (in main()) . then instead of wrapping it could be a substitution on the source code for every directory in GSETTINGS_SCHEMAS_PATH.
<gchristensen>
no, this happens with scripted networking too
<arianvp>
no it happens on both
<arianvp>
or at least, i dont know if it happens on networkd :P
<arianvp>
it happens on scripted for sure
<gchristensen>
ehhhh
<arianvp>
gchristensen: bingo
<gchristensen>
so if the problem is actually the MAC address, I can set networking.interfaces.bond0.macAddress = "..."
<arianvp>
that sounds like it is the culprit?
<gchristensen>
let's give it a go ....
<arianvp>
what was the old behaviour for bonds?
<gchristensen>
no idea
<gchristensen>
seems like maybe systemd/udev just didn't meddle so much with bonds
<andi->
That is why I initially stated the fallback thing on packets side. That would mean after ~30min they "learn" new macs for the bond interfaces.
<gchristensen>
andi-: aaaaah
* gchristensen
kicks over the server for a reprovision test
<gchristensen>
these poor SSDS.
<andi->
Can we reproduce this on e.g. Ubuntu with networkd? if that is the case I believe they should check their configuration or document the expectations.
<gchristensen>
(a) does ubuntu use such a recent version of systemd? (b) Packet hasn't been able to reproduce it on anything they install out of the box
<arianvp>
ubuntu is on 237
<arianvp>
(18.04 that is)
<arianvp>
and 19.04 is on 240
<gchristensen>
heh
<arianvp>
Do they have coreos images??
<gchristensen>
they do, but coreos might use dhcp and not properly bond
<andi->
fedora has a 244-rc1 package...
<arianvp>
ahh they're on 241 haha
<arianvp>
i still dont understand what the macAddress has to do with setting up the bond
<gchristensen>
these nics have two interfaces, with macs 00:11:22:33:44:55 and 00:11:22:33:44:56. usually bonding them makes them both 00:11:22:33:44:55
<andi->
the systemd change now derives that 3rd mac address from the name that you give the interface if I got it right.
<arianvp>
correct. addr = hash(name)
<gchristensen>
that is a nightmare
<gchristensen>
since everybody and their mother uses "bond0"
<arianvp>
why would that be a problem though? (I know not much about bonding)
<arianvp>
oh jeesh
<gchristensen>
the switch is expecting certain MACs
<arianvp>
yes that is gonna be horrible
<arianvp>
lmao
<andi->
I am not sure it is that easy...
* andi-
starts reading source
<gchristensen>
I believe you, andi-
<arianvp>
hash(iface1|iface2|name) makes more sense to me
<arianvp>
brb getting some dinner
<gchristensen>
well maybe not because you very likely will end up adding more interfaces
<gchristensen>
andi-: I'm booting in to the install environment now fwiw
<arianvp>
hash(iface1..n|name) then :P
<gchristensen>
yeah but you wouldn't want your MAC changing when you add new backup interfaces
<arianvp>
so you think the problem is that multiple devices on the network have that MAC address and that's why it's not connecting?
<gchristensen>
no, I think it is probably that the switch is expecting the MAC the hardware is assigned
<andi->
information from /proc/net/bonding/* might be good to have.
<gchristensen>
andi-: want to hop on a session? :) :) :)
<andi->
gchristensen: sure
psyanticy has quit [Quit: Connection closed for inactivity]
<andi->
it is using the /etc/machine-id as "random" source
<srhb>
gchristensen: sup? The scripted Mac shenanigans?
<samueldr>
MAC as in networking
<srhb>
I can help tomorrow but the short story is that 19.09 scripted networking has an issue where it misbehaves with bonded networking. I think I submitted an issue.
<srhb>
We didn't find the root cause.
<srhb>
But basically don't expect it to work with static DHCP leases.
<srhb>
If you want it to work *now* the easiest way is to use networkd and set the mac explicitly.
<srhb>
I didn't get it to work with scripted networking.
<srhb>
(set it to that of the first interface in the bond, that is.)
<srhb>
Back to the concert. o/
<gchristensen>
andi-: "test2 is having connectivity issues"
<gchristensen>
networking.interfaces.bond0.macAddress works :o
<elvishjerricco>
Trying out a dead simple (kinda silly) way to use systemd for the initrd. Just having `default.target` basically launch our usual stage-1-init.sh as a systemd unit that calls `systemctl switch-root` instead of `switch_root`.
<elvishjerricco>
But for some reason `copy_bin_and_libs` isn't working for the `systemd` binary
<adisbladis>
Does gchristensen have a cat :O
<gchristensen>
I am just super miffed by this systemd change
<elvishjerricco>
`libcap.so.2 => not found`, even that's certainly in the `extra-utils` dir.
<arianvp>
gchristensen: I can understand
<arianvp>
but does it even make sense that systemd sets a new mac address for the bond? Or is that actually bad design
<arianvp>
e.g. does it not break bonding by default for networkd too?
<gchristensen>
well
<arianvp>
or does that depend on your switch
<gchristensen>
that depends on your switch configuration
<gchristensen>
in this case, Packet is probably requiring certain MACs from the NIC for customer isolation
<gchristensen>
as part of customer isolation*
<gchristensen>
it is sorta weird that they're doing this since Linux has been (since basically forever) setting the mac of the bond to the lower mac of the bond
<gchristensen>
but I don't want to be a grumpy systemd person :P
<arianvp>
it's at least worth opening an issue for
<arianvp>
people are gonna run into this a lot once redhat and ubuntu move to 242 :P
<srhb>
Lower? First, right?
<gchristensen>
first I guess, yeah
<gchristensen>
arianvp: definitely a good idea
<srhb>
What we saw was some kind of ex nihilo macs.
<srhb>
Which breaks errything. :p
<gchristensen>
yuuup
<gchristensen>
we're getting mac 06:eb:e5:f0:53:2d, when it should be 50:6b:4b:44:00:ea
<srhb>
Yeah. Tons of fun. :p
<srhb>
Did you find any docs that say it's intentional?
<Ox4A6F>
Nice work.
<gchristensen>
I think it is this commit but only because it is the only commit that turned up with "bond0" and "MACPolicy"
<srhb>
Ah... Like, that's a good idea. But not well advertised.
<gchristensen>
is it, though :)
<srhb>
Well advertised?
<gchristensen>
a good idea
<gchristensen>
it doesn't seem like it is a good idea to do this for bonds. for virtual networks, it seems like a brilliant idea
<andi->
I still think it kind of makes sense for hardware based bonds as well as you might remove an interface and use it otherwise at any given point in time. Having the bond then keep the mac address of that interface sounds like a bug to me.
drakonis has quit [Ping timeout: 252 seconds]
<gchristensen>
srhb: I owe you so many thank-yous over the digging you did
<gchristensen>
and same to you, andi-, and arianvp
<gchristensen>
(and thanks to mmlb who told me secrets)
<srhb>
Not at all! Glad you're not exploding (anymore) :D
<mmlb>
np, seems like I owe some peeps some beers on behalf of packet
<arianvp>
beers are always welcome
<mmlb>
yeah lets keep gchristensen in one piece
<arianvp>
Also write this one down in a jira ticket somewhere for when 242 drops on your other distros :P
<arianvp>
you'll thank me later
<arianvp>
(Add a note: When you read this, buy arian a bier)
<gchristensen>
I literally _just_ PM'd the person who would do that
<andi->
so, nixcon2020 beer sponsored by packet? ;)
<gchristensen>
+1
* mmlb
fires off email, Subject: nixcon2020
<andi->
mmlb: we can get that sponsorhip secured right away ;)
<mmlb>
I thought we did a bit this year?
<andi->
I think that never got anywhere.. We bounced a few mails back and forth
<andi->
(no worries tho)
<Profpatsch>
packet doesn’t even know how much CPU we can use!
<Profpatsch>
packet doesn’t even know how much beer we can drink!