[pve-devel] [PATCH frr] frr: fix bit flag collision in patch

[Gabriel Goller]

On 14.03.2025 10:33, Thomas Lamprecht wrote:
>On 13/03/2025 16:49, Gabriel Goller wrote:
>> On 13.03.2025 16:16, Thomas Lamprecht wrote:
>>> w.r.t. versioning I'd have bumped the pve1 part to pve2.
>>
>> So '10.2.1-1+pve2'?
>
>Exactly.
>
>>>> +  * fix fabricd dummy_as_loopback flag collision
>>>
>>> collision with what? these entries should be telling for end users (not devs).
>>
>> True, a simpler "fix fabricd dummy_as_loopback flag" would be enough.
>
>No, my question was with what this collides, your correction does not answer
>that at all and is equally "bad" compared to the original. Maybe something
>along the lines of:
>
>  * fix collision in fabricd for the option values of the recent dummy-as-loopback
>    backport and a internal test mode, where enabling one would always enable the
>    other.
>
>As that tells admins actually what collided and what the basic effect was.

Ah, I thought you meant making it simpler for the admin without going
into details. Will fix this.

>>>> +
>>>> + -- Gabriel Goller <g.goller at proxmox.com>  Thu, 13 Mar 2025 13:33:46 +0100
>
>I overlooked that above should be 'Proxmox Support Team <support at proxmox.com>'
>dch uses the DEBEMAIL environment variable here, so you can add something like
>
>export DEBEMAIL='Proxmox Support Team <support at proxmox.com>'
>
>to your shell's rc file to get that correct, makes most sense if you primarily
>develop on Proxmox projects on that host, e.g. I have a dedicated development VM
>to contain all this stuff, otherwise adding an alias that sets this correctly
>might be also an option.

Oops, yeah my bad.

>> Stefan said the exact same thing :)
>> This is done quite commonly in frr e.g.:
>> https://git.proxmox.com/?p=mirror_frr.git;a=blob;f=bgpd/bgpd.h;h=9cb1d51088cfc456f344b17b8068f84d382e3751;hb=HEAD#l210.
>> But I don't think it's that bad anyway :).
>
>If they use it already, then fine, but lets not introduce this in any of our
>(C) code.

It's also done quite commonly in the linux kernel, but fine, I'll
remember to not user it here :)

Thanks again for looking at this and sorry for the oversights.
Will send a v2 soon.