The future of partclone and therefore FOG as it is
-
Would be great if we could come to a satisfactory answer on this matter. Unfortunately I reached the limit on what I can test on my end (all good), but obviously we want to be sure it works at least as well as the older version for everyone.
-
@Quazz Sorry for staying away from this so far. Guess there is not much I can add as I can only test on VirtualBox. I’ll still do that later on an get back to you. Is it still the download links you posted 20 days ago?
-
@Sebastian-Roth Those should still work yes. Also created a PR on github, so through that way people could check it out too I suppose.
We only really have consumer grade hardware here, rarely anything special, so I know it will work in most scenarios, just need to know if it also works in those other scenarios!
-
@george1421 @Junkhacker We had to sort through a couple of things in the pull request and I was just able to merge it all in. It’s build and everyone can test the binaries build from current master here: https://dev.fogproject.org/blue/organizations/jenkins/fos/detail/master/95/artifacts
I will try to do my testing on the weekend. Would be great if you find the time to do tests on your systems in the next days as well.
-
@Sebastian-Roth FYI zstd 1.4.3 is out. it’s a just a bug-fix upgrade, and a bug that’s probably not relevant to our use case, but we should probably upgrade anyway.
-
@Junkhacker Sebastian and I discussed ZSTD a bit and the coin kind of fell on the “let’s keep ZSTD at this version until Buildroot catches up” to keep things a bit simpler and requiring less maintenance from the dev team.
There are other tools in the toolchain that could theoretically also be upgraded, but at the point you’re putting so much maintenance on the board for any future release that you have to question why you’re using a bundled package like Buildroot anymore.
-
@Quazz said in The future of partclone and therefore FOG as it is:
“let’s keep ZSTD at this version until Buildroot catches up
I also agree with this quote. The only exception would be if a certain package had a documented error that would be fixed by an update or The FOG Project needed a feature in a package that is not available in the current buildroot release.
The developers have enough on their plates keeping the project moving forward to have to think about every package and if we are running the latest version of each package. Its roughly equivalent to deciding which OS to install, bleeding edge fedora or a bit older (mature) but more stable OS like CentOS.
-
@george1421 i only brought it up because we’re updating ztsd for this build anyway, so i figured “why not have the latest one?”
-
Ok, I finally got to test the new inits as well and I think we are good to go with this. Though I have only done basic testing. We’ll see what we run into when other users start using it.
I only brought it up because we’re updating ztsd for this build anyway, so i figured “why not have the latest one?”
You are right on the one hand side! This is all kind of work in progress and why not just use the most recent version while we are at it. But on the other hand if we use 1.4.3 now we should all test again and 1.4.4 might be just waiting around the corner. For those reasons I tend to not go for 1.4.3 now but keep 1.4.2 and keep my fingers crossed that buildroot is catching up quickly.
Thank you very much to all of you @Junkhacker @Quazz @george1421 who helped a lot in pushing this forward!!!
-
@Sebastian-Roth i understand the reasoning for not updating it. i’m hoping to have a chance to help with testing by the end of the week.