libnfnetlink and libmnl

libnfnetlink and libmnl

[Adolf Belka]

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

Hi All,

We have both libnfnetlink and libmnl in IPFire. I have just done an update of libmnl.
There is an update of libnfnetlink but it also says that libnfnetlink is still deprecated and should preferably be replaced by libmnl

I have run ./make.sh find-dependencies on both libmnl.so.0.2.0 and libnfnetlink.so.0.2.0 and neither came up with anything. Doing a grep on the git repository for mnl or nfnetlink also didn't indicate anything using these.
How are they being used and what needs to be done to change the usage of libnfnetlink to libmnl?

Regards,
Adolf

Re: libnfnetlink and libmnl

[Michael Tremer]

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

Hello Adolf,

> On 6 Apr 2022, at 14:18, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
> 
> Hi All,
> 
> We have both libnfnetlink and libmnl in IPFire. I have just done an update of libmnl.
> There is an update of libnfnetlink but it also says that libnfnetlink is still deprecated and should preferably be replaced by libmnl

Oh this is very interesting.

It looks like libmnl was introduced for conntrack-tools in this commit:

commit a10733a5d8580b6ab8cff46235daab6547723781
Author: Arne Fitzenreiter <Arne_F(a)ipfire.org>
Date:   Thu Jan 3 14:27:11 2013 +0100

    conntrack-tools: add conntrack and needed deps.

You can try to comment out libnfnetlink and libmnl and run a clean build and see if it goes through. If so, then we can safely drop them.

> I have run ./make.sh find-dependencies on both libmnl.so.0.2.0 and libnfnetlink.so.0.2.0 and neither came up with anything. Doing a grep on the git repository for mnl or nfnetlink also didn't indicate anything using these.
> How are they being used and what needs to be done to change the usage of libnfnetlink to libmnl?

See above.

I believe there are a couple of other candidates for this which we should have a look at. There is libdnet that I noticed a little while ago, but I am sure there will be plenty more when looking through the package list:

libaio
libart
libnet
libnl (and if something depends on it, can it not use libnl-3?)
libpri (if I remember correctly this was a dependency of asterisk)
libsolv can absolutely go for the moment, we don’t need it
netpbm?
pigz (we don’t use it anywhere since we are compressing images with XZ b302b9a695e391477eab0cb2343f3ba1b1ba1989)
sdparm

If you have the time, maybe you can have a look at what is used somewhere and what can be dropped?

This won’t shrink the distribution by a massive amount, but why should we carry around dead code?

Best,
-Michael

> Regards,
> Adolf

Re: libnfnetlink and libmnl

[Tom Rymes]

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



> On Apr 6, 2022, at 10:42 AM, Michael Tremer <michael.tremer(a)ipfire.org> wrote:
> 
> Hello Adolf,

[snip]

> libpri (if I remember correctly this was a dependency of asterisk)

[snip]

libpri should be a dependency of dahdi, which is a dependency of asterisk.

Tom

Re: libnfnetlink and libmnl

[Michael Tremer]

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

Thanks for chiming in. That is what I thought and we don’t have asterisk any more. So it can very likely go, too.

> On 6 Apr 2022, at 16:20, Tom Rymes <tom(a)rymes.net> wrote:
> 
> 
> 
>> On Apr 6, 2022, at 10:42 AM, Michael Tremer <michael.tremer(a)ipfire.org> wrote:
>> 
>> Hello Adolf,
> 
> [snip]
> 
>> libpri (if I remember correctly this was a dependency of asterisk)
> 
> [snip]
> 
> libpri should be a dependency of dahdi, which is a dependency of asterisk.
> 
> Tom

Re: libnfnetlink and libmnl

[Adolf Belka]

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

Hi Michael,

On 06/04/2022 16:42, Michael Tremer wrote:
> Hello Adolf,
> 
>> On 6 Apr 2022, at 14:18, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>
>> Hi All,
>>
>> We have both libnfnetlink and libmnl in IPFire. I have just done an update of libmnl.
>> There is an update of libnfnetlink but it also says that libnfnetlink is still deprecated and should preferably be replaced by libmnl
> 
> Oh this is very interesting.
> 
> It looks like libmnl was introduced for conntrack-tools in this commit:
> 
> commit a10733a5d8580b6ab8cff46235daab6547723781
> Author: Arne Fitzenreiter <Arne_F(a)ipfire.org>
> Date:   Thu Jan 3 14:27:11 2013 +0100
> 
>      conntrack-tools: add conntrack and needed deps.
> 
> You can try to comment out libnfnetlink and libmnl and run a clean build and see if it goes through. If so, then we can safely drop them.
> 
>> I have run ./make.sh find-dependencies on both libmnl.so.0.2.0 and libnfnetlink.so.0.2.0 and neither came up with anything. Doing a grep on the git repository for mnl or nfnetlink also didn't indicate anything using these.
>> How are they being used and what needs to be done to change the usage of libnfnetlink to libmnl?
> 
> See above.
> 
> I believe there are a couple of other candidates for this which we should have a look at. There is libdnet that I noticed a little while ago, but I am sure there will be plenty more when looking through the package list:
> 
> libaio
> libart
> libnet
> libnl (and if something depends on it, can it not use libnl-3?)
> libpri (if I remember correctly this was a dependency of asterisk)
> libsolv can absolutely go for the moment, we don’t need it
> netpbm?
> pigz (we don’t use it anywhere since we are compressing images with XZ b302b9a695e391477eab0cb2343f3ba1b1ba1989)
> sdparm
> 
> If you have the time, maybe you can have a look at what is used somewhere and what can be dropped?
I will give that a go and use your inputs as starting points.

Regards,
Adolf
> 
> This won’t shrink the distribution by a massive amount, but why should we carry around dead code?
> 
> Best,
> -Michael
> 
>> Regards,
>> Adolf
> 

Re: libnfnetlink and libmnl

[Adolf Belka]

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

Hi Michael,

On 06/04/2022 17:38, Adolf Belka wrote:
> Hi Michael,
>
> On 06/04/2022 16:42, Michael Tremer wrote:
>> Hello Adolf,
>>
>>> On 6 Apr 2022, at 14:18, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>>
>>> Hi All,
>>>
>>> We have both libnfnetlink and libmnl in IPFire. I have just done an update of libmnl.
>>> There is an update of libnfnetlink but it also says that libnfnetlink is still deprecated and should preferably be replaced by libmnl
>>
>> Oh this is very interesting.
>>
>> It looks like libmnl was introduced for conntrack-tools in this commit:
>>
>> commit a10733a5d8580b6ab8cff46235daab6547723781
>> Author: Arne Fitzenreiter <Arne_F(a)ipfire.org>
>> Date:   Thu Jan 3 14:27:11 2013 +0100
>>
>>      conntrack-tools: add conntrack and needed deps.
>>
>> You can try to comment out libnfnetlink and libmnl and run a clean build and see if it goes through. If so, then we can safely drop them.
>>
It didn't go clean. It looks like libnetfilter_queue requires both libmnl and libnfnetlink for compiling/building different parts of libnetfilter_queue. I don't know if it is required for running but it wouldn't surprise me so both these will have to stay.

It's interesting that the group that says libmnl should be used in preference to libnfnetlink then go and require both to still be used for one of their programs.


I will continue looking through other files that you highlighted.


Regards,

Adolf.

>>> I have run ./make.sh find-dependencies on both libmnl.so.0.2.0 and libnfnetlink.so.0.2.0 and neither came up with anything. Doing a grep on the git repository for mnl or nfnetlink also didn't indicate anything using these.
>>> How are they being used and what needs to be done to change the usage of libnfnetlink to libmnl?
>>
>> See above.
>>
>> I believe there are a couple of other candidates for this which we should have a look at. There is libdnet that I noticed a little while ago, but I am sure there will be plenty more when looking through the package list:
>>
>> libaio
>> libart
>> libnet
>> libnl (and if something depends on it, can it not use libnl-3?)
>> libpri (if I remember correctly this was a dependency of asterisk)
>> libsolv can absolutely go for the moment, we don’t need it
>> netpbm?
>> pigz (we don’t use it anywhere since we are compressing images with XZ b302b9a695e391477eab0cb2343f3ba1b1ba1989)
>> sdparm
>>
>> If you have the time, maybe you can have a look at what is used somewhere and what can be dropped?
> I will give that a go and use your inputs as starting points.
>
> Regards,
> Adolf
>>
>> This won’t shrink the distribution by a massive amount, but why should we carry around dead code?
>>
>> Best,
>> -Michael
>>
>>> Regards,
>>> Adolf
>>

Re: libnfnetlink and libmnl

[Michael Tremer]

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

Hello,

> On 6 Apr 2022, at 17:52, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
> 
> Hi Michael,
> 
> On 06/04/2022 17:38, Adolf Belka wrote:
>> Hi Michael,
>> 
>> On 06/04/2022 16:42, Michael Tremer wrote:
>>> Hello Adolf,
>>> 
>>>> On 6 Apr 2022, at 14:18, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>>> 
>>>> Hi All,
>>>> 
>>>> We have both libnfnetlink and libmnl in IPFire. I have just done an update of libmnl.
>>>> There is an update of libnfnetlink but it also says that libnfnetlink is still deprecated and should preferably be replaced by libmnl
>>> 
>>> Oh this is very interesting.
>>> 
>>> It looks like libmnl was introduced for conntrack-tools in this commit:
>>> 
>>> commit a10733a5d8580b6ab8cff46235daab6547723781
>>> Author: Arne Fitzenreiter <Arne_F(a)ipfire.org>
>>> Date:  Thu Jan 3 14:27:11 2013 +0100
>>> 
>>> conntrack-tools: add conntrack and needed deps.
>>> 
>>> You can try to comment out libnfnetlink and libmnl and run a clean build and see if it goes through. If so, then we can safely drop them.
>>> 
> It didn't go clean. It looks like libnetfilter_queue requires both libmnl and libnfnetlink for compiling/building different parts of libnetfilter_queue. I don't know if it is required for running but it wouldn't surprise me so both these will have to stay.
> 
> It's interesting that the group that says libmnl should be used in preference to libnfnetlink then go and require both to still be used for one of their programs.

Well, we all have good intentions to keep our software clean, but very often there is some legacy bit that everyone relies on and simply never gets cleaned up.

> I will continue looking through other files that you highlighted.

Thank you.

> 
> 
> Regards,
> 
> Adolf.
> 
>>>> I have run ./make.sh find-dependencies on both libmnl.so.0.2.0 and libnfnetlink.so.0.2.0 and neither came up with anything. Doing a grep on the git repository for mnl or nfnetlink also didn't indicate anything using these.
>>>> How are they being used and what needs to be done to change the usage of libnfnetlink to libmnl?
>>> 
>>> See above.
>>> 
>>> I believe there are a couple of other candidates for this which we should have a look at. There is libdnet that I noticed a little while ago, but I am sure there will be plenty more when looking through the package list:
>>> 
>>> libaio
>>> libart
>>> libnet
>>> libnl (and if something depends on it, can it not use libnl-3?)
>>> libpri (if I remember correctly this was a dependency of asterisk)
>>> libsolv can absolutely go for the moment, we don’t need it
>>> netpbm?
>>> pigz (we don’t use it anywhere since we are compressing images with XZ b302b9a695e391477eab0cb2343f3ba1b1ba1989)
>>> sdparm
>>> 
>>> If you have the time, maybe you can have a look at what is used somewhere and what can be dropped?
>> I will give that a go and use your inputs as starting points.
>> 
>> Regards,
>> Adolf
>>> 
>>> This won’t shrink the distribution by a massive amount, but why should we carry around dead code?
>>> 
>>> Best,
>>> -Michael
>>> 
>>>> Regards,
>>>> Adolf

Re: libnfnetlink and libmnl

[Adolf Belka]

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

Hi Michael & *,

Building without

libart
libdnet
libpri
libsolv
pigz
sdparm

went without any problems. I have submitted a patch set removing them from IPFire.

libnet needs to stay as arping requires it.

libaio is needed by lvm2. However when I looked at lvm2 in IPFire it is not actually used by IPFire at all. The commands are all available but there are no mapped volume groups , logical groups etc.
Is lvm2 provided so that people can use logical volumes on additional hard disks that might be mounted on IPFire. Presumably if people have already created lvm structures on other disk drives on the IPFire hardware then we need to stay with lvm2 being present otherwise its removal would stop people being able to access that additional hard disk(s).
If that is the case then libaio will also need to stay.

Regards,
Adolf.

On 06/04/2022 19:02, Michael Tremer wrote:
> Hello,
> 
>> On 6 Apr 2022, at 17:52, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>
>> Hi Michael,
>>
>> On 06/04/2022 17:38, Adolf Belka wrote:
>>> Hi Michael,
>>>
>>> On 06/04/2022 16:42, Michael Tremer wrote:
>>>> Hello Adolf,
>>>>
>>>>> On 6 Apr 2022, at 14:18, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>>>>
>>>>> Hi All,
>>>>>
>>>>> We have both libnfnetlink and libmnl in IPFire. I have just done an update of libmnl.
>>>>> There is an update of libnfnetlink but it also says that libnfnetlink is still deprecated and should preferably be replaced by libmnl
>>>>
>>>> Oh this is very interesting.
>>>>
>>>> It looks like libmnl was introduced for conntrack-tools in this commit:
>>>>
>>>> commit a10733a5d8580b6ab8cff46235daab6547723781
>>>> Author: Arne Fitzenreiter <Arne_F(a)ipfire.org>
>>>> Date:  Thu Jan 3 14:27:11 2013 +0100
>>>>
>>>> conntrack-tools: add conntrack and needed deps.
>>>>
>>>> You can try to comment out libnfnetlink and libmnl and run a clean build and see if it goes through. If so, then we can safely drop them.
>>>>
>> It didn't go clean. It looks like libnetfilter_queue requires both libmnl and libnfnetlink for compiling/building different parts of libnetfilter_queue. I don't know if it is required for running but it wouldn't surprise me so both these will have to stay.
>>
>> It's interesting that the group that says libmnl should be used in preference to libnfnetlink then go and require both to still be used for one of their programs.
> 
> Well, we all have good intentions to keep our software clean, but very often there is some legacy bit that everyone relies on and simply never gets cleaned up.
> 
>> I will continue looking through other files that you highlighted.
> 
> Thank you.
> 
>>
>>
>> Regards,
>>
>> Adolf.
>>
>>>>> I have run ./make.sh find-dependencies on both libmnl.so.0.2.0 and libnfnetlink.so.0.2.0 and neither came up with anything. Doing a grep on the git repository for mnl or nfnetlink also didn't indicate anything using these.
>>>>> How are they being used and what needs to be done to change the usage of libnfnetlink to libmnl?
>>>>
>>>> See above.
>>>>
>>>> I believe there are a couple of other candidates for this which we should have a look at. There is libdnet that I noticed a little while ago, but I am sure there will be plenty more when looking through the package list:
>>>>
>>>> libaio
>>>> libart
>>>> libnet
>>>> libnl (and if something depends on it, can it not use libnl-3?)
>>>> libpri (if I remember correctly this was a dependency of asterisk)
>>>> libsolv can absolutely go for the moment, we don’t need it
>>>> netpbm?
>>>> pigz (we don’t use it anywhere since we are compressing images with XZ b302b9a695e391477eab0cb2343f3ba1b1ba1989)
>>>> sdparm
>>>>
>>>> If you have the time, maybe you can have a look at what is used somewhere and what can be dropped?
>>> I will give that a go and use your inputs as starting points.
>>>
>>> Regards,
>>> Adolf
>>>>
>>>> This won’t shrink the distribution by a massive amount, but why should we carry around dead code?
>>>>
>>>> Best,
>>>> -Michael
>>>>
>>>>> Regards,
>>>>> Adolf
> 

Re: libnfnetlink and libmnl

[Tom Rymes]

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

Adolf,

Is sdparm and/or lvm2 used by the “extra HD” addon?

Tom

> On Apr 7, 2022, at 7:19 AM, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
> 
> Hi Michael & *,
> 
> Building without
> 
> libart
> libdnet
> libpri
> libsolv
> pigz
> sdparm
> 
> went without any problems. I have submitted a patch set removing them from IPFire.
> 
> libnet needs to stay as arping requires it.
> 
> libaio is needed by lvm2. However when I looked at lvm2 in IPFire it is not actually used by IPFire at all. The commands are all available but there are no mapped volume groups , logical groups etc.
> Is lvm2 provided so that people can use logical volumes on additional hard disks that might be mounted on IPFire. Presumably if people have already created lvm structures on other disk drives on the IPFire hardware then we need to stay with lvm2 being present otherwise its removal would stop people being able to access that additional hard disk(s).
> If that is the case then libaio will also need to stay.
> 
> Regards,
> Adolf.
> 
>> On 06/04/2022 19:02, Michael Tremer wrote:
>> Hello,
>>>> On 6 Apr 2022, at 17:52, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>> 
>>> Hi Michael,
>>> 
>>> On 06/04/2022 17:38, Adolf Belka wrote:
>>>> Hi Michael,
>>>> 
>>>> On 06/04/2022 16:42, Michael Tremer wrote:
>>>>> Hello Adolf,
>>>>> 
>>>>>> On 6 Apr 2022, at 14:18, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>>>>> 
>>>>>> Hi All,
>>>>>> 
>>>>>> We have both libnfnetlink and libmnl in IPFire. I have just done an update of libmnl.
>>>>>> There is an update of libnfnetlink but it also says that libnfnetlink is still deprecated and should preferably be replaced by libmnl
>>>>> 
>>>>> Oh this is very interesting.
>>>>> 
>>>>> It looks like libmnl was introduced for conntrack-tools in this commit:
>>>>> 
>>>>> commit a10733a5d8580b6ab8cff46235daab6547723781
>>>>> Author: Arne Fitzenreiter <Arne_F(a)ipfire.org>
>>>>> Date:  Thu Jan 3 14:27:11 2013 +0100
>>>>> 
>>>>> conntrack-tools: add conntrack and needed deps.
>>>>> 
>>>>> You can try to comment out libnfnetlink and libmnl and run a clean build and see if it goes through. If so, then we can safely drop them.
>>>>> 
>>> It didn't go clean. It looks like libnetfilter_queue requires both libmnl and libnfnetlink for compiling/building different parts of libnetfilter_queue. I don't know if it is required for running but it wouldn't surprise me so both these will have to stay.
>>> 
>>> It's interesting that the group that says libmnl should be used in preference to libnfnetlink then go and require both to still be used for one of their programs.
>> Well, we all have good intentions to keep our software clean, but very often there is some legacy bit that everyone relies on and simply never gets cleaned up.
>>> I will continue looking through other files that you highlighted.
>> Thank you.
>>> 
>>> 
>>> Regards,
>>> 
>>> Adolf.
>>> 
>>>>>> I have run ./make.sh find-dependencies on both libmnl.so.0.2.0 and libnfnetlink.so.0.2.0 and neither came up with anything. Doing a grep on the git repository for mnl or nfnetlink also didn't indicate anything using these.
>>>>>> How are they being used and what needs to be done to change the usage of libnfnetlink to libmnl?
>>>>> 
>>>>> See above.
>>>>> 
>>>>> I believe there are a couple of other candidates for this which we should have a look at. There is libdnet that I noticed a little while ago, but I am sure there will be plenty more when looking through the package list:
>>>>> 
>>>>> libaio
>>>>> libart
>>>>> libnet
>>>>> libnl (and if something depends on it, can it not use libnl-3?)
>>>>> libpri (if I remember correctly this was a dependency of asterisk)
>>>>> libsolv can absolutely go for the moment, we don’t need it
>>>>> netpbm?
>>>>> pigz (we don’t use it anywhere since we are compressing images with XZ b302b9a695e391477eab0cb2343f3ba1b1ba1989)
>>>>> sdparm
>>>>> 
>>>>> If you have the time, maybe you can have a look at what is used somewhere and what can be dropped?
>>>> I will give that a go and use your inputs as starting points.
>>>> 
>>>> Regards,
>>>> Adolf
>>>>> 
>>>>> This won’t shrink the distribution by a massive amount, but why should we carry around dead code?
>>>>> 
>>>>> Best,
>>>>> -Michael
>>>>> 
>>>>>> Regards,
>>>>>> Adolf

Re: libnfnetlink and libmnl

[Adolf Belka]

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

Hi Tom,


On 07/04/2022 17:37, Tom Rymes wrote:
> Adolf,
> 
> Is sdparm and/or lvm2 used by the “extra HD” addon?

It didn't show up with a grep of the IPFire git repository. I will have a further look into it to see if they are needed to run it.

Regards,
Adolf.
> 
> Tom
> 
>> On Apr 7, 2022, at 7:19 AM, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>
>> Hi Michael & *,
>>
>> Building without
>>
>> libart
>> libdnet
>> libpri
>> libsolv
>> pigz
>> sdparm
>>
>> went without any problems. I have submitted a patch set removing them from IPFire.
>>
>> libnet needs to stay as arping requires it.
>>
>> libaio is needed by lvm2. However when I looked at lvm2 in IPFire it is not actually used by IPFire at all. The commands are all available but there are no mapped volume groups , logical groups etc.
>> Is lvm2 provided so that people can use logical volumes on additional hard disks that might be mounted on IPFire. Presumably if people have already created lvm structures on other disk drives on the IPFire hardware then we need to stay with lvm2 being present otherwise its removal would stop people being able to access that additional hard disk(s).
>> If that is the case then libaio will also need to stay.
>>
>> Regards,
>> Adolf.
>>
>>> On 06/04/2022 19:02, Michael Tremer wrote:
>>> Hello,
>>>>> On 6 Apr 2022, at 17:52, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>>>
>>>> Hi Michael,
>>>>
>>>> On 06/04/2022 17:38, Adolf Belka wrote:
>>>>> Hi Michael,
>>>>>
>>>>> On 06/04/2022 16:42, Michael Tremer wrote:
>>>>>> Hello Adolf,
>>>>>>
>>>>>>> On 6 Apr 2022, at 14:18, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>>>>>>
>>>>>>> Hi All,
>>>>>>>
>>>>>>> We have both libnfnetlink and libmnl in IPFire. I have just done an update of libmnl.
>>>>>>> There is an update of libnfnetlink but it also says that libnfnetlink is still deprecated and should preferably be replaced by libmnl
>>>>>>
>>>>>> Oh this is very interesting.
>>>>>>
>>>>>> It looks like libmnl was introduced for conntrack-tools in this commit:
>>>>>>
>>>>>> commit a10733a5d8580b6ab8cff46235daab6547723781
>>>>>> Author: Arne Fitzenreiter <Arne_F(a)ipfire.org>
>>>>>> Date:  Thu Jan 3 14:27:11 2013 +0100
>>>>>>
>>>>>> conntrack-tools: add conntrack and needed deps.
>>>>>>
>>>>>> You can try to comment out libnfnetlink and libmnl and run a clean build and see if it goes through. If so, then we can safely drop them.
>>>>>>
>>>> It didn't go clean. It looks like libnetfilter_queue requires both libmnl and libnfnetlink for compiling/building different parts of libnetfilter_queue. I don't know if it is required for running but it wouldn't surprise me so both these will have to stay.
>>>>
>>>> It's interesting that the group that says libmnl should be used in preference to libnfnetlink then go and require both to still be used for one of their programs.
>>> Well, we all have good intentions to keep our software clean, but very often there is some legacy bit that everyone relies on and simply never gets cleaned up.
>>>> I will continue looking through other files that you highlighted.
>>> Thank you.
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Adolf.
>>>>
>>>>>>> I have run ./make.sh find-dependencies on both libmnl.so.0.2.0 and libnfnetlink.so.0.2.0 and neither came up with anything. Doing a grep on the git repository for mnl or nfnetlink also didn't indicate anything using these.
>>>>>>> How are they being used and what needs to be done to change the usage of libnfnetlink to libmnl?
>>>>>>
>>>>>> See above.
>>>>>>
>>>>>> I believe there are a couple of other candidates for this which we should have a look at. There is libdnet that I noticed a little while ago, but I am sure there will be plenty more when looking through the package list:
>>>>>>
>>>>>> libaio
>>>>>> libart
>>>>>> libnet
>>>>>> libnl (and if something depends on it, can it not use libnl-3?)
>>>>>> libpri (if I remember correctly this was a dependency of asterisk)
>>>>>> libsolv can absolutely go for the moment, we don’t need it
>>>>>> netpbm?
>>>>>> pigz (we don’t use it anywhere since we are compressing images with XZ b302b9a695e391477eab0cb2343f3ba1b1ba1989)
>>>>>> sdparm
>>>>>>
>>>>>> If you have the time, maybe you can have a look at what is used somewhere and what can be dropped?
>>>>> I will give that a go and use your inputs as starting points.
>>>>>
>>>>> Regards,
>>>>> Adolf
>>>>>>
>>>>>> This won’t shrink the distribution by a massive amount, but why should we carry around dead code?
>>>>>>
>>>>>> Best,
>>>>>> -Michael
>>>>>>
>>>>>>> Regards,
>>>>>>> Adolf

Re: libnfnetlink and libmnl

[Michael Tremer]

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

I couldn’t find anything using this either. Happy to be corrected if I am wrong :)

> On 7 Apr 2022, at 16:43, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
> 
> Hi Tom,
> 
> 
> On 07/04/2022 17:37, Tom Rymes wrote:
>> Adolf,
>> Is sdparm and/or lvm2 used by the “extra HD” addon?
> 
> It didn't show up with a grep of the IPFire git repository. I will have a further look into it to see if they are needed to run it.
> 
> Regards,
> Adolf.
>> Tom
>>> On Apr 7, 2022, at 7:19 AM, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>> 
>>> Hi Michael & *,
>>> 
>>> Building without
>>> 
>>> libart
>>> libdnet
>>> libpri
>>> libsolv
>>> pigz
>>> sdparm
>>> 
>>> went without any problems. I have submitted a patch set removing them from IPFire.
>>> 
>>> libnet needs to stay as arping requires it.
>>> 
>>> libaio is needed by lvm2. However when I looked at lvm2 in IPFire it is not actually used by IPFire at all. The commands are all available but there are no mapped volume groups , logical groups etc.
>>> Is lvm2 provided so that people can use logical volumes on additional hard disks that might be mounted on IPFire. Presumably if people have already created lvm structures on other disk drives on the IPFire hardware then we need to stay with lvm2 being present otherwise its removal would stop people being able to access that additional hard disk(s).
>>> If that is the case then libaio will also need to stay.
>>> 
>>> Regards,
>>> Adolf.
>>> 
>>>> On 06/04/2022 19:02, Michael Tremer wrote:
>>>> Hello,
>>>>>> On 6 Apr 2022, at 17:52, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>>>> 
>>>>> Hi Michael,
>>>>> 
>>>>> On 06/04/2022 17:38, Adolf Belka wrote:
>>>>>> Hi Michael,
>>>>>> 
>>>>>> On 06/04/2022 16:42, Michael Tremer wrote:
>>>>>>> Hello Adolf,
>>>>>>> 
>>>>>>>> On 6 Apr 2022, at 14:18, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>>>>>>> 
>>>>>>>> Hi All,
>>>>>>>> 
>>>>>>>> We have both libnfnetlink and libmnl in IPFire. I have just done an update of libmnl.
>>>>>>>> There is an update of libnfnetlink but it also says that libnfnetlink is still deprecated and should preferably be replaced by libmnl
>>>>>>> 
>>>>>>> Oh this is very interesting.
>>>>>>> 
>>>>>>> It looks like libmnl was introduced for conntrack-tools in this commit:
>>>>>>> 
>>>>>>> commit a10733a5d8580b6ab8cff46235daab6547723781
>>>>>>> Author: Arne Fitzenreiter <Arne_F(a)ipfire.org>
>>>>>>> Date:  Thu Jan 3 14:27:11 2013 +0100
>>>>>>> 
>>>>>>> conntrack-tools: add conntrack and needed deps.
>>>>>>> 
>>>>>>> You can try to comment out libnfnetlink and libmnl and run a clean build and see if it goes through. If so, then we can safely drop them.
>>>>>>> 
>>>>> It didn't go clean. It looks like libnetfilter_queue requires both libmnl and libnfnetlink for compiling/building different parts of libnetfilter_queue. I don't know if it is required for running but it wouldn't surprise me so both these will have to stay.
>>>>> 
>>>>> It's interesting that the group that says libmnl should be used in preference to libnfnetlink then go and require both to still be used for one of their programs.
>>>> Well, we all have good intentions to keep our software clean, but very often there is some legacy bit that everyone relies on and simply never gets cleaned up.
>>>>> I will continue looking through other files that you highlighted.
>>>> Thank you.
>>>>> 
>>>>> 
>>>>> Regards,
>>>>> 
>>>>> Adolf.
>>>>> 
>>>>>>>> I have run ./make.sh find-dependencies on both libmnl.so.0.2.0 and libnfnetlink.so.0.2.0 and neither came up with anything. Doing a grep on the git repository for mnl or nfnetlink also didn't indicate anything using these.
>>>>>>>> How are they being used and what needs to be done to change the usage of libnfnetlink to libmnl?
>>>>>>> 
>>>>>>> See above.
>>>>>>> 
>>>>>>> I believe there are a couple of other candidates for this which we should have a look at. There is libdnet that I noticed a little while ago, but I am sure there will be plenty more when looking through the package list:
>>>>>>> 
>>>>>>> libaio
>>>>>>> libart
>>>>>>> libnet
>>>>>>> libnl (and if something depends on it, can it not use libnl-3?)
>>>>>>> libpri (if I remember correctly this was a dependency of asterisk)
>>>>>>> libsolv can absolutely go for the moment, we don’t need it
>>>>>>> netpbm?
>>>>>>> pigz (we don’t use it anywhere since we are compressing images with XZ b302b9a695e391477eab0cb2343f3ba1b1ba1989)
>>>>>>> sdparm
>>>>>>> 
>>>>>>> If you have the time, maybe you can have a look at what is used somewhere and what can be dropped?
>>>>>> I will give that a go and use your inputs as starting points.
>>>>>> 
>>>>>> Regards,
>>>>>> Adolf
>>>>>>> 
>>>>>>> This won’t shrink the distribution by a massive amount, but why should we carry around dead code?
>>>>>>> 
>>>>>>> Best,
>>>>>>> -Michael
>>>>>>> 
>>>>>>>> Regards,
>>>>>>>> Adolf

Re: libnfnetlink and libmnl

[Adolf Belka]

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

I just had a detailed look through extrahd.cgi and extrahd.pl and scanhd and neither lvm nor sdparm are used.

Basically the ExtraHD entry uses data from fstab and searching in /sys/block/... to find info about disks and partitions.

Regards,

Adolf.

On 07/04/2022 17:53, Michael Tremer wrote:
> I couldn’t find anything using this either. Happy to be corrected if I am wrong :)
> 
>> On 7 Apr 2022, at 16:43, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>
>> Hi Tom,
>>
>>
>> On 07/04/2022 17:37, Tom Rymes wrote:
>>> Adolf,
>>> Is sdparm and/or lvm2 used by the “extra HD” addon?
>>
>> It didn't show up with a grep of the IPFire git repository. I will have a further look into it to see if they are needed to run it.
>>
>> Regards,
>> Adolf.
>>> Tom
>>>> On Apr 7, 2022, at 7:19 AM, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>>>
>>>> Hi Michael & *,
>>>>
>>>> Building without
>>>>
>>>> libart
>>>> libdnet
>>>> libpri
>>>> libsolv
>>>> pigz
>>>> sdparm
>>>>
>>>> went without any problems. I have submitted a patch set removing them from IPFire.
>>>>
>>>> libnet needs to stay as arping requires it.
>>>>
>>>> libaio is needed by lvm2. However when I looked at lvm2 in IPFire it is not actually used by IPFire at all. The commands are all available but there are no mapped volume groups , logical groups etc.
>>>> Is lvm2 provided so that people can use logical volumes on additional hard disks that might be mounted on IPFire. Presumably if people have already created lvm structures on other disk drives on the IPFire hardware then we need to stay with lvm2 being present otherwise its removal would stop people being able to access that additional hard disk(s).
>>>> If that is the case then libaio will also need to stay.
>>>>
>>>> Regards,
>>>> Adolf.
>>>>
>>>>> On 06/04/2022 19:02, Michael Tremer wrote:
>>>>> Hello,
>>>>>>> On 6 Apr 2022, at 17:52, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>>>>>
>>>>>> Hi Michael,
>>>>>>
>>>>>> On 06/04/2022 17:38, Adolf Belka wrote:
>>>>>>> Hi Michael,
>>>>>>>
>>>>>>> On 06/04/2022 16:42, Michael Tremer wrote:
>>>>>>>> Hello Adolf,
>>>>>>>>
>>>>>>>>> On 6 Apr 2022, at 14:18, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>>>>>>>>
>>>>>>>>> Hi All,
>>>>>>>>>
>>>>>>>>> We have both libnfnetlink and libmnl in IPFire. I have just done an update of libmnl.
>>>>>>>>> There is an update of libnfnetlink but it also says that libnfnetlink is still deprecated and should preferably be replaced by libmnl
>>>>>>>>
>>>>>>>> Oh this is very interesting.
>>>>>>>>
>>>>>>>> It looks like libmnl was introduced for conntrack-tools in this commit:
>>>>>>>>
>>>>>>>> commit a10733a5d8580b6ab8cff46235daab6547723781
>>>>>>>> Author: Arne Fitzenreiter <Arne_F(a)ipfire.org>
>>>>>>>> Date:  Thu Jan 3 14:27:11 2013 +0100
>>>>>>>>
>>>>>>>> conntrack-tools: add conntrack and needed deps.
>>>>>>>>
>>>>>>>> You can try to comment out libnfnetlink and libmnl and run a clean build and see if it goes through. If so, then we can safely drop them.
>>>>>>>>
>>>>>> It didn't go clean. It looks like libnetfilter_queue requires both libmnl and libnfnetlink for compiling/building different parts of libnetfilter_queue. I don't know if it is required for running but it wouldn't surprise me so both these will have to stay.
>>>>>>
>>>>>> It's interesting that the group that says libmnl should be used in preference to libnfnetlink then go and require both to still be used for one of their programs.
>>>>> Well, we all have good intentions to keep our software clean, but very often there is some legacy bit that everyone relies on and simply never gets cleaned up.
>>>>>> I will continue looking through other files that you highlighted.
>>>>> Thank you.
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Adolf.
>>>>>>
>>>>>>>>> I have run ./make.sh find-dependencies on both libmnl.so.0.2.0 and libnfnetlink.so.0.2.0 and neither came up with anything. Doing a grep on the git repository for mnl or nfnetlink also didn't indicate anything using these.
>>>>>>>>> How are they being used and what needs to be done to change the usage of libnfnetlink to libmnl?
>>>>>>>>
>>>>>>>> See above.
>>>>>>>>
>>>>>>>> I believe there are a couple of other candidates for this which we should have a look at. There is libdnet that I noticed a little while ago, but I am sure there will be plenty more when looking through the package list:
>>>>>>>>
>>>>>>>> libaio
>>>>>>>> libart
>>>>>>>> libnet
>>>>>>>> libnl (and if something depends on it, can it not use libnl-3?)
>>>>>>>> libpri (if I remember correctly this was a dependency of asterisk)
>>>>>>>> libsolv can absolutely go for the moment, we don’t need it
>>>>>>>> netpbm?
>>>>>>>> pigz (we don’t use it anywhere since we are compressing images with XZ b302b9a695e391477eab0cb2343f3ba1b1ba1989)
>>>>>>>> sdparm
>>>>>>>>
>>>>>>>> If you have the time, maybe you can have a look at what is used somewhere and what can be dropped?
>>>>>>> I will give that a go and use your inputs as starting points.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Adolf
>>>>>>>>
>>>>>>>> This won’t shrink the distribution by a massive amount, but why should we carry around dead code?
>>>>>>>>
>>>>>>>> Best,
>>>>>>>> -Michael
>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Adolf
>