From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: Problem with updating ddrescue addon Date: Tue, 02 Feb 2021 18:55:27 +0000 Message-ID: <9BCA06DD-15B0-436F-AAF6-80753CE7A850@ipfire.org> In-Reply-To: <83faf7d8-be9b-3b65-7199-420ffdd16369@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7217902822092545470==" List-Id: --===============7217902822092545470== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, > On 2 Feb 2021, at 17:57, Adolf Belka wrote: >=20 > Hi Michael, >=20 > On 02/02/2021 15:17, Michael Tremer wrote: >> Hi, >> Sorry for my late reply. > No problems. I know all you guys are busy and will reply when you are able = to. Trying to stay on top of things, but yes, many of things are happening at the= same time. There is nothing bad to remind me if I overlooked an email or if something is= more urgent. >>> On 31 Jan 2021, at 11:41, Adolf Belka wrote: >>>=20 >>> Hallo all, >>>=20 >>>=20 >>> I saw that ddrescue addon was a version from 2010 so I thought it was abo= ut time to be updated. However since 2013 gnu has only been using lzip for th= e tarballs and stopped providing gzip versions. >>>=20 >>> IPFire does not have lzip available at the moment. >>>=20 >>> The options seem to me to be:- >>>=20 >>> - remove ddrescue from the addon list >> This is an option, since it does not seem to be the most popular add-on. O= n the other hand, it does not cause us any trouble, so I would vote for keepi= ng it. >>> - leave ddrescue at the 2010 version - v1.12 >> That would be a bad choice, because we do not want to ship outdated softwa= re. >>> - update ddrescue to the last .gz tarball version in 2012 - v1.16 >> Again, this would be outdated. >>> - build lzip into the IPFire build system and update to latest ddresc= ue version from March 2020 - v1.25 >> I would vote for this. There is seems to be a lot of chaos with the compre= ssion algorithms right now. Gzip is outdated and does not compress very well,= bzip2 is in the same situation. XZ compresses well, but it quite slow. LZMA = was a stepping stone to XZ. > Good. Will work on it. >> Now there is Zstandard, lzip and I have even seen tarballs being compresse= d with lzo. They all seem to be have their individual advantages and disadvan= tages, but ultimately we will have to use what the maintainers of upstream so= ftware chose to go with. Sooner or later we will have more packages using lzi= p. >>> should it go into the toolchain where the other compression p= ackages seem to be (how to do that?) >> Since we do not have anything in the toolchain stage yet that is requiring= it, I would suggest building it as a normal package and do so as early as po= ssible. It should not have any dependencies. > Clear. >>> should it go into the build part of IPFire >> Yes :) > Clear. >>> Looking through the changelog from v1.13 to 1.25 there are a lot of new o= ptions added but also some changes to the code itself that look to be fixing = problems. I can't easily see how important these are. No changes have been ma= rked as critical bug fixes or even marked as a bug fix. >>>=20 >>> My view would be to update to the latest version or remove ddrescue from = the addons, as 11 years old seems a long time in computing terms. >> Ancient :) Do we have more of those? > Yes there are others and as I find them I am looking at updating them. >> Thank you for looking into this. It looks like ddrecuse was a package that= I simply have forgotten about. >>> I am open to taking any guidance on the best approach for this. >> Did I answer your questions? > Absolutely yes. :) Sounds great :) -Michael > Regards, > Adolf. >> Best, >> -Michael >>>=20 >>> Regards, >>>=20 >>> Adolf. --===============7217902822092545470==--