I’m building Arch Linux nightlies every 2-3 days. These are somewhat more optimized than normal builds. LTO & Clear Linux CXXFLAGS and you’ll have to have an Intel Core iX-6XXX (Haswell) or newer. If that fits your bill I can see if I can host the repo somewhere. Try this recent build if you like:
http://rbts.co/download/kicad-git-6.0.0~r18332.06bf7943b7-1-x86_64.pkg.tar.zst
http://rbts.co/download/kicad-git-6.0.0~r18332.06bf7943b7-1-x86_64.pkg.tar.zst.sig
You can use makepkg to build the latest nighty from aur:
https://aur.archlinux.org/packages/kicad-git/
I can send you this version, build on my machine:
kicad-git-r18309.6cbe2131a-1-x86_64.pkg.tar (160MB)
Cedric, can you post a build online? I’d love to check why my packages are 25MB on average vs 160MB for yours
I recommend agaisnt calling it 6.0.0. We call it 5.99 for a reason to avoid any and all conflicts once we do actually release 6.0, nor to have users call it 6.0 falsely in bug reports and posting. It’s not 6.0 until the first release candidate is announced 
It’s auto-generated:
pkgver() {
cd "${srcdir}/${pkgname}"
if [ -n ${_pkgver} ]; then
echo $(git tag | egrep -o '^[0-9]\.[0-9]\.[0-9]' | sort -V | tail -n 1)~$(printf "r%s.%s" "$(git rev-list HEAD --count --first-parent)" "$(git rev-parse --short HEAD)")
else
printf "${_pkgver}~%s" "$(git rev-list HEAD --count --first-parent)"
fi
}
Edit: As in someone already tagged a 6.0.0 version. Maybe that tag shouldn’t be there?
Hmmm, that may be from the original plan to call it 6.0 before we settled on 5.99. Unfortunately tags do not sync automatically in git between local repos and somebody may have force pushed all tags <.<
Can the tag be removed? It’s undermining the whole reason for version tags imho. My PKGBUILD uses the newer GitLab repository.
Ah, right, I forgot. I disabled compressing the package, so I don’t have to wait for my machine to first compress the package, and then decompress it again then I install it. I routinely delete my build directories afterwards anyway, so the bigger file size if no problem for me. Until now that is, when I offer to transfer the file to somebody else.
In my /etc/makepkg.conf I’ve enabled this line:
PKGEXT=’.pkg.tar’
Thanks @StefanHamminga and @cedric – Stefan’s build works fine here. Building the AUR version just for fun. I was confused initially looking at the AUR package seeing the last update was quite some time ago, but released it builds the latest kicad git version, so it is just the build that has not been updated in awhile.
With AUR packages, is there any way to have both the released and AUR version installed?
I pulled up the design – looks like a 4-layer design. I’d guess quite a bit work went into this design.
There appears to be some length matching and diff pair routing. Are there new features in the nightly build that would help with this?
The new design rules system would help with this, but the Pi folks didn’t use it for this design
I’ve asked the same question on the RPi forum but none of the designers had replied. Since 5.1 branch, heck even v4 is perfectly capable to design differential pairs, I still don’t get why they had used nightly builds for this task.
Working today on the CM4IO board and still yet to see a reason.
Any ideas?
I will need to update my project to use CM4 instead of CM3+. I have installed both 5.1.8 and 5.99 KiCads, however the project is in V5 and I would like to keep it that way… Is there any possibility how to get the CM4 footprint and symbol to V5?
@Kedarius Stay with 5.1.8 and draw what you need manually. Use nightlies to inspect CM4IO.
I’ve been down the 5.99 path just for the same reason. KiCad got a new tester but I’m really slowed down. Although I’m happy to help somehow. Always wanted to contribute to the code side but couldn’t find enough time to solve the code base. For now, settled with testing 
I plan to stay with 5.1.8 unless something really important emerges - I would need to convince my very conservative colleague to use 5.99 So I plan to to use nightlies to inspect the CM4IO and use it as reference, exactly like you said.
However I am kinda sad that there is an already done footprint and symbol for the CM4 and that I would need to recreate it in v5. I do not need to convert anything other but especially the footprint would be great…
Edit: As I posted this post I realized that I should be able to convert the file by hand and it seems to have worked for the footprint (I just needed to tweak the file a little). Now I will try to work on schematic symbol…
Believe me, 5.99 is not ready for prime time. You can see it from the bug tracker. But it is getting there. The developers are really working hard to stabilize it.
Draw the footprint manually. It would be much faster and you’d be much happier
I’m sure this was a decision of an action loving engineer from Raspberry Pi Foundation. They just used what we had with 5.1 already.
I do believe you, I want to use stable 5.1.8. I just do not want to redo 200 pads footprint… Especially as the one in V5.99 project is done by the vendor of said product
Very easy. Use “Create array” feature… Will be very fast.
One more question. How should I solve the issue, that the footprint for CM4 are de facto two 100pin connectors?
As far I did not find any good solution. Either I will use two symbols, two footprints (I could probably use the Hirose connector footprint) but I will need to maintain their relative position. Or I will use one symbol (possibly with two or more units) and one footprint. The second way will keep the relative position of the connectors but I will have only one item in BOM and pick and place file…
The way I think that I would approach this would be to have one footprint and a multi-unit symbol. Maybe several multi-unit symbols for me to choose depending on how I want to split up the pins. First approximation would be for two symbols units, each representing the two different connectors. But as I lay out the schematic I may end up splitting the symbol into function-based units. This would work, but to order the right parts you would need to have a single internal inventory number/identifier to tell you to order two Hirose connectors and the compute module.
If you are concerned about getting all the bits onto a single schematic driven BOM, I would end up with two footprints (one used twice) and an additional symbol (to the multi-unit one, above) used twice. I’ve done this with socketed ICs before and gotten a good BOM with just a small amount more effort than the above process. Like above, the multi-unit CM symbol would link to the footprint that has all the pins layed out with the correct spacing to each other as well as an overall outline on silkscreen and/or fab layer. I wouldn’t put a courtyard on this footprint to allow putting low profile discretes (like bypass caps and/or biasing resistors) under the module without DRC yelling at you. The additional symbol wouldn’t have any pins and is for getting the Hirose board-mount connector into the BOM, and you would need to place this symbol twice. Give them manual Ref’Ds that logically links the connectors (being used like an IC socket) to the compute modules Ref’D to make it easy to pick out when looking at your BOM in spreadsheet form. The footprint for this would have the outline on silkscreen and/or fab and courtyard for a single Hirose connector. There should also be some feature in the connector footprint that PCBNew can snap to for placement to the CM’s footprint to make sure alignment is by object snap instead of eye-ball and/or manual math.
That’s my $0.02, please take it for what it’s worth. ($0.02USD) 
To be quite honest I am not so concerned about BOM, more about pick and place position file… I expect the final PCB be assembled by a board house (probably by PCBWAY) and the worst thing is that the PCB arrives and I would not be able to plug the CM into the connectors because they are misalligned by a half a millimeter
One more option I am considering is to make some sort of automatic BOM/PnP modifying script. I am using a automated “build” process for creating all my fabrication outputs from Git so I should be able to replace on footprint with two. The downside is that I would need to compute the correct positions of the connectors but once the script would be done it would be perfect every time…
