<clever>
lucus16: that would be why its not auto spawning! but why...
<clever>
lucus16: what is inside /etc/pulse/client.conf ?
<clever>
lucus16: then it must be an issue with the auto-starting...
<clever>
lucus16: does audio work now?
<clever>
lucus16: dont bother rebooting
<clever>
lucus16: try just running pulseaudio in a shell
<clever>
?
<clever>
lucus16: try kill
<clever>
mojjo: it also overwrites any other value, rather then merging
<clever>
mojjo: and foo overwrites foo, so you lost your foo.a, causing confusion!
<clever>
> :p { foo.a = 1; } // { foo.b = 2; }
<clever>
> { foo.a = 1; } // { foo.b = 2; }
<clever>
mojjo: // will just merge sets, so
<clever>
lucus16: if you close every application related to pulseaudio, can you stop the daemon?
<clever>
lucus16: then the parent is already gone, and pid1 adopted the orphan
<clever>
lucus16: to start with, does `ps -eH x` show which process is the parrent of pulseaudio?
<clever>
mojjo: also, using // on nxios config will cause more problems, your better off putting my.nix into the imports list, it will merge things a lot better
<clever>
mojjo: you need to get writeTextFile from somewhere else, (import <nixpkgs> {}).writeTextFile
<clever>
mojjo: it does work, but nixos must know the content of your nixos config, to know what the value of pkgs is
<clever>
lucus16: try killing the rogue daemon, while pavucontrol is open
<clever>
lucus16: run pavucontrol, what does it show?
<clever>
lucus16: are there audio applications running outside of the X11 session?
<clever>
lucus16: is hardware.pulseaudio.enable = true; set?
<clever>
lucus16: if any client program tries to use pulse, but cant find an existing server, it will spawn its own server on the spot
<clever>
then you can call those, to make a new crystal, the same way its already doing to make a dozen versions of itself
<clever>
i would modify the default.nix to just expose generic and genericBinary directly
<clever>
and when you change crystal, the old buildCrystalPackage remains, and refers to the old crystal
<clever>
so, crystal has a buildCrystalPackage, that references the original crystal
<clever>
and yeah, then i have profiles, for certain tasks, some shared, some i just want an easy off switch
<clever>
machine1.nix is per-device, and each has its own entry-point
<clever>
blaggacao: so i dont need to make a host symlink, the imports entry handles that
<clever>
blaggacao: and then i do imports = [ ./machine1.nix ];
<clever>
blaggacao: personally, i keep configuration.nix rather bare, only the stuff related to the hardware (like fs uuid's, and bootloader cfg)
<clever>
blaggacao: there is a hello world example in the comments, which will print "hello world!" out the serial port, without any closed-source firmware (other then the boot rom)
<clever>
ilya-fedin: you could try running strip on the binary, in a postBuild hook
<clever>
blaggacao: ive not looked into the wayland stuff, so i dont know that
<clever>
blaggacao: but vc4 is a dual-core cpu, that is heavily specialized into vector operations
<clever>
blaggacao: basically, v3d is just a 3d rendering core, its highly specialized at turning textures and vertexes into 3d renderings
<clever>
blaggacao: vc4 is a whole new beast, that ive only just recently started to play with
<clever>
blaggacao: it was mostly just a matter of setting a config.txt flag to disable start.elf from touching v3d, and then writing linux drivers to poke the right registers
<clever>
blaggacao: i was once writing v3d drivers for the rpi, they ran entirely from the arm side of things
<clever>
ilya-fedin: somewhere inside the binary of that file, is a path to the library, youll want to run strings on the binary to get the full path, crystal (the compiler) may need to be modified to be split output, so the libs are in their own output
<clever>
that then loads kernel.img, and turns the ARM core(s) on
<clever>
that then enables the dram, and loads start.elf (another VC4 binary)
<clever>
that loads bootcode.bin into the L2 cache (128kb of sram)
<clever>
when you first power on, the pi, it begins running the boot rom on the VC4 cpu
<clever>
nope
<clever>
VC4 is more if you want to replace the gpu firmware entire with opensource
<clever>
wayland could be done entirely on the arm side, using the dispmanx api
<clever>
models*
<clever>
VC4 is the GPU side for all modems
<clever>
the rules say you cant share the boot rom, but nothing stops you from reading it, so you could always dump your own boot rom, and dis-assemble it
<clever>
blaggacao: i also have a PR open to add the entire VC4 toolchain (the gpu side of things) to nixpkgs, which can disassembly the gpu firmware
<clever>
blaggacao: partially, your only getting a trace of what filenames it tries to read
<clever>
[root@router:/tftproot]# ls -ltrh 9080d9b6/root.squashfs -L
<clever>
-r--r--r-- 4 root root 41M Jan 1 1970 9080d9b6/root.squashfs
<clever>
so you can abuse the tftp boot, as a way to see what the bootrom is thinking, and find hidden features
<clever>
and some of those files also work on the sd card, and arent documented
<clever>
that reveals, what files its searching for
<clever>
another neat thing, is that if the rpi boot rom tries to netboot, it will query the tftp server for all the files
<clever>
or, the nix expresion in the profile, could generate a directory for every mac in the setup, and manage them all as one unit
<clever>
so i could just make a 2nd profile, and point other macs to that other profile
<clever>
and i have symlinks for some macs, pointing to the rpi3-netboot profile
<clever>
blaggacao: the boot rom in the rpi, will search for a directory named after its mac addr
<clever>
its mostly a security thing, if you turn it on after the card fell out, it will netboot, and you may not trust the local network
<clever>
blaggacao: and once enabled, it cant be disabled, but it will still support booting from sdcard
<clever>
blaggacao: with the rpi3, you need an entry in config.txt on the sdcard, to enable network boot
<clever>
so you can now update the boot code, without having to keep an SD card around
<clever>
the rpi4 also added an SPI flash chip, to solve that problem for good
<clever>
blaggacao: with some models of rpi, the boot rom cant fully network boot on its own, but if you make an SD card with ONLY bootcode.bin and nothing else, that can patch the boot rom bugs, and the card never accepts any writes
<clever>
and i do have it booting on rpi's, but currently without X11
<clever>
LnL: i havent noticed that actually working, and the problem is more that its trying to use an interpreter, when there was already a working #!
<clever>
eyJhb: probably
<clever>
KarelWDingeldey[: there is a month of overlap when a new release comes out, then the old release stops getting updates
<clever>
eyJhb: b: patch ycm to obey the #!
<clever>
eyJhb: a: tell ycmd to explicitly use python3 (but its still ignoring the #!)
<clever>
eyJhb: its probably designed for lesser OS's that dont use #!'s as heavily
<clever>
eyJhb: and its ignoring the fact that ycmd already had a #! that did the right thing
<clever>
eyJhb: the problem is that the vim script, is looking in places like /usr/bin to find a python binary, to run ycmd
<clever>
eyJhb: its already using python3
<clever>
eyJhb: nix-build '<nixpkgs>' -A python3 -o ~/python3-root, for ex
<clever>
eyJhb: youll need to build a python3 then, put its link somewhere predictable, and put its path into the vimrc
<clever>
eyJhb: and all of that is pointless, because ycmd already had a #!/nix/store/foo/bin/python on it
<clever>
eyJhb: the problem, is that the ycm stuff in vim, tries to run `python /path/to/ycmd`, but looks up the python path in a number of places
<clever>
eyJhb: you need to add this to the vimrc
<clever>
48 let g:ycm_server_python_interpreter='${pkgs.python3.interpreter}'
<clever>
eyJhb: one sec
<clever>
davidak: what exactly is it fetching from the internet? could you fake it with an nginx server and /etc/hosts?
<clever>
davidak: the internet is disabled during all testing
<clever>
mananamenos: run `id`
<clever>
davidak: not sure why its so slow then, but usually better to do the test in the derivation, without qemu
<clever>
davidak: does /dev/kvm exist on your machine?
<clever>
so chromium itself isnt a module, but it relies on a module to start
<clever>
i think the only reason things like chromium are in a nixos test, is because it needs X11 to test
<clever>
davidak: for cli apps, its usually simpler to just put it into the derivation, as a checkPhase