Re: Problem with updating ddrescue addon

Re: Problem with updating ddrescue addon

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 2695 bytes --]

Hi,

Sorry for my late reply.

> On 31 Jan 2021, at 11:41, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
> 
> Hallo all,
> 
> 
> I saw that ddrescue addon was a version from 2010 so I thought it was about time to be updated. However since 2013 gnu has only been using lzip for the tarballs and stopped providing gzip versions.
> 
> IPFire does not have lzip available at the moment.
> 
> The options seem to me to be:-
> 
>     - remove ddrescue from the addon list

This is an option, since it does not seem to be the most popular add-on. On the other hand, it does not cause us any trouble, so I would vote for keeping it.

>     - leave ddrescue at the 2010 version - v1.12

That would be a bad choice, because we do not want to ship outdated software.

>     - 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 ddrescue version from March 2020 - v1.25

I would vote for this. There is seems to be a lot of chaos with the compression 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.

Now there is Zstandard, lzip and I have even seen tarballs being compressed with lzo. They all seem to be have their individual advantages and disadvantages, but ultimately we will have to use what the maintainers of upstream software chose to go with. Sooner or later we will have more packages using lzip.

>             should it go into the toolchain where the other compression packages 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 possible. It should not have any dependencies.

>             should it go into the build part of IPFire

Yes :)

> Looking through the changelog from v1.13 to 1.25 there are a lot of new options 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 marked as critical bug fixes or even marked as a bug fix.
> 
> 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?

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?

Best,
-Michael

> 
> Regards,
> 
> Adolf.
> 

Re: Problem with updating ddrescue addon

[Adolf Belka]

[-- Attachment #1: Type: text/plain, Size: 3080 bytes --]

Hi Michael,

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.
> 
>> On 31 Jan 2021, at 11:41, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>
>> Hallo all,
>>
>>
>> I saw that ddrescue addon was a version from 2010 so I thought it was about time to be updated. However since 2013 gnu has only been using lzip for the tarballs and stopped providing gzip versions.
>>
>> IPFire does not have lzip available at the moment.
>>
>> The options seem to me to be:-
>>
>>      - remove ddrescue from the addon list
> 
> This is an option, since it does not seem to be the most popular add-on. On the other hand, it does not cause us any trouble, so I would vote for keeping it.
> 
>>      - leave ddrescue at the 2010 version - v1.12
> 
> That would be a bad choice, because we do not want to ship outdated software.
> 
>>      - 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 ddrescue version from March 2020 - v1.25
> 
> I would vote for this. There is seems to be a lot of chaos with the compression 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 compressed with lzo. They all seem to be have their individual advantages and disadvantages, but ultimately we will have to use what the maintainers of upstream software chose to go with. Sooner or later we will have more packages using lzip.
> 
>>              should it go into the toolchain where the other compression packages 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 possible. 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 options 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 marked as critical bug fixes or even marked as a bug fix.
>>
>> 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. :)

Regards,
Adolf.
> 
> Best,
> -Michael
> 
>>
>> Regards,
>>
>> Adolf.
>>
> 

Re: Problem with updating ddrescue addon

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 3358 bytes --]

Hi,

> On 2 Feb 2021, at 17:57, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
> 
> Hi Michael,
> 
> 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 <adolf.belka(a)ipfire.org> wrote:
>>> 
>>> Hallo all,
>>> 
>>> 
>>> I saw that ddrescue addon was a version from 2010 so I thought it was about time to be updated. However since 2013 gnu has only been using lzip for the tarballs and stopped providing gzip versions.
>>> 
>>> IPFire does not have lzip available at the moment.
>>> 
>>> The options seem to me to be:-
>>> 
>>>     - remove ddrescue from the addon list
>> This is an option, since it does not seem to be the most popular add-on. On the other hand, it does not cause us any trouble, so I would vote for keeping it.
>>>     - leave ddrescue at the 2010 version - v1.12
>> That would be a bad choice, because we do not want to ship outdated software.
>>>     - 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 ddrescue version from March 2020 - v1.25
>> I would vote for this. There is seems to be a lot of chaos with the compression 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 compressed with lzo. They all seem to be have their individual advantages and disadvantages, but ultimately we will have to use what the maintainers of upstream software chose to go with. Sooner or later we will have more packages using lzip.
>>>             should it go into the toolchain where the other compression packages 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 possible. 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 options 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 marked as critical bug fixes or even marked as a bug fix.
>>> 
>>> 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
>>> 
>>> Regards,
>>> 
>>> Adolf.