<electronic_eel>
is there some policy about tool requirements for Glasgow patches?
<electronic_eel>
I was showing my Glasgow to a friend this afternoon. Installation went smooth and all, just the -abc9 option for yosys didn't work
<electronic_eel>
he used Fedora which has yosys 0.9 packaged. But -abc9 seems to be just in git, not in the 0.9 release
<electronic_eel>
It took me a few minutes to realize what the problem was and revert the patch. But maybe someone new might have a problem with something like that
<emily>
oh yeah
<emily>
it should gate that on yosys version
<emily>
whitequark:
<emily>
0.9 shipped without abc9 :(
<emily>
electronic_eel: fwiw, having 0.9 packaged is pretty lucky, it only came out recently
<emily>
so for many distros there is no packaged yosys that works with nmigen/glasgow
<electronic_eel>
seems like there are active openfpga devs using fedora, it was packaged a few days after release. nextpnr is also packaged. very convenient
<emily>
that is nice, don't you need rawhide for that though?
<emily>
since stable releases only filter down every 6 months?
<electronic_eel>
no, regular released f30
<emily>
lucky timing I guess
<electronic_eel>
it depends a bit on the application: some apps that are deemed important infrastructure and that have major updates only get them in a new fedora release
<emily>
I see, so Fedora is semi-rolling-release for some packages, that's nice
<electronic_eel>
smaller programs and smaller updates are also done on the current release
<emily>
Debian refuses to do it for anything it doesn't has to (browsers, basically), I think
<electronic_eel>
hmm, but debian releases are like every two or three years. No updates whatsoever in between, all bugfixes and security patches backported?
<electronic_eel>
for a workstation that seems a bit unpractical for me
<electronic_eel>
for a server this is necessary. I use centos on the servers, that has even longer support
<emily>
it works a bit badly, yes
<emily>
I don't think it's necessary or even necessarily desirable for servers either, personally
<emily>
OpenSUSE and NixOS have rolling releases that are gated on test/QA suites passing; in combination with reproducible builds and referenceable repository snapshots this gives you rolling releases with a stability competing with that of traditional slow-cycle distros
<emily>
especially in a world where so many servers are just running other versions of another distro in Docker containers because they need some newer dependency anyway :/
<electronic_eel>
it depends on how many different servers / services you have running. Even a smaller company has hundreds of services running today. If you constantly have issues with stuff breaking because of rolling releases this is not acceptable
<electronic_eel>
often stuff breaks in subtle manner and it takes a lot of time to figure it out and nail it to some rolling update
<emily>
that's where the comprehensive test suites come in
<emily>
especially as scale goes larger you have to start operating in this way, because manually fighting and tracking down each individual fire isn't possible
<electronic_eel>
even if you develop this level of testing for the stuff you wrote yourself, most other software you get doesn't have it
<electronic_eel>
in the open source projects I use, there often is some kind of test suite, but sometimes it is difficult to set up so it is only feasible for the developers themselves
<electronic_eel>
so for the mission critical stuff I have good test suites, but not for the dozens of other programs and services that run
<electronic_eel>
but even the not so important stuff can suck away a lot of time
<electronic_eel>
so I prefer the very long support time for centos and happliy invest a few minutes to package up newer stuff if I need it
<_whitenotifier>
[Glasgow] electroniceel opened pull request #158: cli: make output legible on black-on-white terminals too - https://git.io/JesRa
electronic_eel_ has joined #glasgow
electronic_eel has quit [Ping timeout: 268 seconds]