subject:"Re\: \[Wireshark\-dev\] Future of Wireshark's Debian packaging scripts in the main repository"




On 20/12/23 22:35, Roland Knall wrote:



Am 20.12.2023 um 22:43 schrieb João Valverde :




On 20/12/23 21:21, Roland Knall wrote:


Am 20.12.2023 um 22:02 schrieb João Valverde :




On 20/12/23 20:52, Roland Knall wrote:


So people can link to our libraries to write other projets? And expect it to 
work reliably? That is news to me. I have made this question many times over 
the years but I guess I was not worthy of a clear answer until now.


I am not saying they should do it or that I appreciate it happening. All I am 
saying is that it happens and is happening and we did not put a stop to it in 
time. Should they expect it to be reliable? Of course not as I answered also in 
other threads on this matter. But at the same time I see no point in having 
them hit a wall face on, rather work in such cases where we know about it, to 
ensure them moving to a saner approach.

What?! I'm back to confused... So you don't like the situation, you say. Here's 
a thought.. maybe if Debian didn't publish system libraries in our name with 
these stupid symbol lists then people wouldn't get the crazy idea they could 
use these libraries that were published for this exact purpose and build their 
own software on top of it and expect it to work reliable and not break every 
other release, like most other non-Wireshark Debian libraries.

I wonder what could be done about that. I guess Debian would get that clue 
pretty darn quick if we weren't mirroring their broken setup in our repository, 
thereby sanctioning it.

I don't know, call me crazy. Or did I misunderstand again? Sure seems 
complicated to get my head around this for such a simple topic as is software 
release and distribution.

Just a thought, libvirt was not created by debian but RedHat so the state of 
debian packaging has nothing to do with them. Debians package is merely moving 
their approach onto Debian, but the decision to implement libvirts plugin in 
such a way had been done by RedHats folks.


And what such way is that?! I don't even know why libvirt keeps coming 
up in this discussion. They wrote a dissector plugin. That's great. Good 
for them. I don't upstream many of my plugins into Wireshark either. 
This is something so banal that I am honestly confused why libvirt keeps 
coming up as a big boogaloo in this discussion.


I ask again in all sincerity, because I could be misunderstanding, what 
is the difficulty created by the libvirt plugin and what does that have 
to do with Debian packaging?




___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe


___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository



> Am 20.12.2023 um 22:43 schrieb João Valverde :
> 
> 
> 
>> On 20/12/23 21:21, Roland Knall wrote:
>> 
 Am 20.12.2023 um 22:02 schrieb João Valverde :
>>> 
>>> 
>>> 
 On 20/12/23 20:52, Roland Knall wrote:
 
 
 So people can link to our libraries to write other projets? And expect it 
 to work reliably? That is news to me. I have made this question many times 
 over the years but I guess I was not worthy of a clear answer until now.
 
>> I am not saying they should do it or that I appreciate it happening. All I 
>> am saying is that it happens and is happening and we did not put a stop to 
>> it in time. Should they expect it to be reliable? Of course not as I 
>> answered also in other threads on this matter. But at the same time I see no 
>> point in having them hit a wall face on, rather work in such cases where we 
>> know about it, to ensure them moving to a saner approach.
> 
> What?! I'm back to confused... So you don't like the situation, you say. 
> Here's a thought.. maybe if Debian didn't publish system libraries in our 
> name with these stupid symbol lists then people wouldn't get the crazy idea 
> they could use these libraries that were published for this exact purpose and 
> build their own software on top of it and expect it to work reliable and not 
> break every other release, like most other non-Wireshark Debian libraries.
> 
> I wonder what could be done about that. I guess Debian would get that clue 
> pretty darn quick if we weren't mirroring their broken setup in our 
> repository, thereby sanctioning it.
> 
> I don't know, call me crazy. Or did I misunderstand again? Sure seems 
> complicated to get my head around this for such a simple topic as is software 
> release and distribution.

Just a thought, libvirt was not created by debian but RedHat so the state of 
debian packaging has nothing to do with them. Debians package is merely moving 
their approach onto Debian, but the decision to implement libvirts plugin in 
such a way had been done by RedHats folks. And most other packages I know that 
use this approach as well are Windows based. Again nothing to do with Debian. 
So could we separate these issues please? 

> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository




On 20/12/23 21:21, Roland Knall wrote:



Am 20.12.2023 um 22:02 schrieb João Valverde :




On 20/12/23 20:52, Roland Knall wrote:


So people can link to our libraries to write other projets? And expect it to 
work reliably? That is news to me. I have made this question many times over 
the years but I guess I was not worthy of a clear answer until now.


I am not saying they should do it or that I appreciate it happening. All I am 
saying is that it happens and is happening and we did not put a stop to it in 
time. Should they expect it to be reliable? Of course not as I answered also in 
other threads on this matter. But at the same time I see no point in having 
them hit a wall face on, rather work in such cases where we know about it, to 
ensure them moving to a saner approach.


What?! I'm back to confused... So you don't like the situation, you say. 
Here's a thought.. maybe if Debian didn't publish system libraries in 
our name with these stupid symbol lists then people wouldn't get the 
crazy idea they could use these libraries that were published for this 
exact purpose and build their own software on top of it and expect it to 
work reliable and not break every other release, like most other 
non-Wireshark Debian libraries.


I wonder what could be done about that. I guess Debian would get that 
clue pretty darn quick if we weren't mirroring their broken setup in our 
repository, thereby sanctioning it.


I don't know, call me crazy. Or did I misunderstand again? Sure seems 
complicated to get my head around this for such a simple topic as is 
software release and distribution.

___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository



> Am 20.12.2023 um 22:02 schrieb João Valverde :
> 
> 
> 
>> On 20/12/23 20:52, Roland Knall wrote:
>> 
>> 
>> Am Mi., 20. Dez. 2023 um 21:24 Uhr schrieb João Valverde :
>> 
>> 
>> 
>>On 20/12/23 16:06, Roland Knall wrote:
>>> Ok, I am not ignoring those points, as I think those points are
>>valid.
>>> It makes sense, that building debian packages from the repository
>>> should behave in the same way as it does with the overall projects.
>>> Now, one could argue, that having multiple packages could have been
>>> avoided in the beginning or it should be changed, that would be a
>>> valid discussion being had, but I do not think it invalidates those
>>> points and arguments. Yes, debian is different but it is also
>>the base
>>> (through ubuntu) for the majority of linux distributions as
>>> wells Microsofts own variety in wsl2 (at least if you go with the
>>> default one), and therefore it should be considered as such.
>> 
>>I don't know what you are trying to get at. I'm not trying to say
>>what
>>Debian should or shouldn't do.  They are free to decide for
>>themselves.
>>I would never presume to tell them what they should do, although I
>>have
>>strong opinions on that. There are lots of problems with their
>>package
>>but that is something to be discussed in the Debian bug tracker, not
>>here. This project isn't part of Debian. This fact seems to be
>>lost on
>>some people.
>> 
>> 
>> The idea Balint had is, that no matter if you are using the official package 
>> or build it yourself with our repository, you will not be locked out of 
>> updating the package or distribution, and most certainly it will not lead to 
>> any issues with package management. This might be a speciality of Debian, 
>> but I think it is something we can support as it does not really hinder us, 
>> except for the issue with the lib manifest, which now seems to be resolved. 
>> And I do think that supporting this choice by our users is something that is 
>> worth supporting.
>> 
>> 
>>>
>>> The libvirt plugin is a valid example of where we messed up. And
>>with
>>> we I mean the whole project. We provided this path and we kept it
>>> maintained for far too long, but it is here now and a solution
>>needs
>>> to be found. We started on that road with stating that we allow
>>> invalidating the api in major version releases and also minor
>>version
>>> releases to some extend. The argument, that libvirt is still doing
>>> something they should not be doing is valid. But the solution
>>here is
>>> not hindering the compatibility, but getting in touch with them and
>>> figuring out how to do it properly together. We created this
>>path, we
>>> should not destroy it but help others find a safer route. And
>>libvirt
>>> is indeed being used by quite a few people.
>> 
>>I don't understand what any of this means, sorry. I'm not being
>>facetious, could be my own fault. I have written many Wireshark
>>plugins
>>so I know a lot about that topic. What problems are the libvirt
>>people
>>experiencing that I am not? What strange and mystical path is this
>>that
>>we are on? Why did we mess up? Please enlighten me. Really, I
>>would like
>>to know so we can have a fruitful conversation about this because
>>right
>>now I am really confused.
>> 
>> 
>> We made the initial mistake of staying in a patch that allowed for a 
>> situation like this to occur. We made sure that you could link against our 
>> libraries and build your own projects from it. To revert this now, will lead 
>> to issues and pains in various places outside of the project, which might 
>> not seem to be a big thing initially, but it can hurt us in the long run. 
>> Think the whole Gnome 2/3 transition which drove quite a few people made, 
>> although they had a good reason for it.
> 
> So people can link to our libraries to write other projets? And expect it to 
> work reliably? That is news to me. I have made this question many times over 
> the years but I guess I was not worthy of a clear answer until now.
> 

I am not saying they should do it or that I appreciate it happening. All I am 
saying is that it happens and is happening and we did not put a stop to it in 
time. Should they expect it to be reliable? Of course not as I answered also in 
other threads on this matter. But at the same time I see no point in having 
them hit a wall face on, rather work in such cases where we know about it, to 
ensure them moving to a saner approach. 


>> 
>> I agree with you btw on the fact that the way libvirt does this plugin is 
>> not a good one. I think they should stop pretending to be extra smart in 
>> this case and revert to a model, where one plugin version may be compatible 
>> with multiple libvirt versions or vice versa. That would resolve this whole 
>>

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

On 20/12/23 20:52, Roland Knall wrote:

Am Mi., 20. Dez. 2023 um 21:24 Uhr schrieb João Valverde :

On 20/12/23 16:06, Roland Knall wrote:
> Ok, I am not ignoring those points, as I think those points are
valid.
> It makes sense, that building debian packages from the repository
> should behave in the same way as it does with the overall projects.
> Now, one could argue, that having multiple packages could have been
> avoided in the beginning or it should be changed, that would be a
> valid discussion being had, but I do not think it invalidates those
> points and arguments. Yes, debian is different but it is also
the base
> (through ubuntu) for the majority of linux distributions as
> wells Microsofts own variety in wsl2 (at least if you go with the
> default one), and therefore it should be considered as such.

I don't know what you are trying to get at. I'm not trying to say
what
Debian should or shouldn't do.  They are free to decide for
themselves.
I would never presume to tell them what they should do, although I
have
strong opinions on that. There are lots of problems with their
package
but that is something to be discussed in the Debian bug tracker, not
here. This project isn't part of Debian. This fact seems to be
lost on
some people.

The idea Balint had is, that no matter if you are using the official 
package or build it yourself with our repository, you will not be 
locked out of updating the package or distribution, and most certainly 
it will not lead to any issues with package management. This might be 
a speciality of Debian, but I think it is something we can support as 
it does not really hinder us, except for the issue with the lib 
manifest, which now seems to be resolved. And I do think that 
supporting this choice by our users is something that is worth supporting.

>
> The libvirt plugin is a valid example of where we messed up. And
with
> we I mean the whole project. We provided this path and we kept it
> maintained for far too long, but it is here now and a solution
needs
> to be found. We started on that road with stating that we allow
> invalidating the api in major version releases and also minor
version
> releases to some extend. The argument, that libvirt is still doing
> something they should not be doing is valid. But the solution
here is
> not hindering the compatibility, but getting in touch with them and
> figuring out how to do it properly together. We created this
path, we
> should not destroy it but help others find a safer route. And
libvirt
> is indeed being used by quite a few people.

I don't understand what any of this means, sorry. I'm not being
facetious, could be my own fault. I have written many Wireshark
plugins
so I know a lot about that topic. What problems are the libvirt
people
experiencing that I am not? What strange and mystical path is this
that
we are on? Why did we mess up? Please enlighten me. Really, I
would like
to know so we can have a fruitful conversation about this because
right
now I am really confused.

We made the initial mistake of staying in a patch that allowed for a 
situation like this to occur. We made sure that you could link against 
our libraries and build your own projects from it. To revert this now, 
will lead to issues and pains in various places outside of the 
project, which might not seem to be a big thing initially, but it can 
hurt us in the long run. Think the whole Gnome 2/3 transition which 
drove quite a few people made, although they had a good reason for it.

So people can link to our libraries to write other projets? And expect 
it to work reliably? That is news to me. I have made this question many 
times over the years but I guess I was not worthy of a clear answer 
until now.

I agree with you btw on the fact that the way libvirt does this plugin 
is not a good one. I think they should stop pretending to be extra 
smart in this case and revert to a model, where one plugin version may 
be compatible with multiple libvirt versions or vice versa. That would 
resolve this whole issue. But unless we are willing to fight this 
fight (and I for one am not particularly interested in that pandora's 
box) I do not see a reason why we should actively undermine their 
approach, just for the sake of "being right". I agree that it would be 
a better approach, but it would also open up quite a few birthing 
pains and that at least would violate our "no breaking unless major 
version release" policy. Another one of those we never actively 
charted down, but try to uphold.

I don't know what libvirt are doing specifically, a plugin is a plugin, 
something very eerie and mysterious seems to be afoot over there, but I 
will investigate, out of curiosity

Hope this clears up the point I was

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

Am Mi., 20. Dez. 2023 um 21:24 Uhr schrieb João Valverde :

>
>
> On 20/12/23 16:06, Roland Knall wrote:
> > Ok, I am not ignoring those points, as I think those points are valid.
> > It makes sense, that building debian packages from the repository
> > should behave in the same way as it does with the overall projects.
> > Now, one could argue, that having multiple packages could have been
> > avoided in the beginning or it should be changed, that would be a
> > valid discussion being had, but I do not think it invalidates those
> > points and arguments. Yes, debian is different but it is also the base
> > (through ubuntu) for the majority of linux distributions as
> > wells Microsofts own variety in wsl2 (at least if you go with the
> > default one), and therefore it should be considered as such.
>
> I don't know what you are trying to get at. I'm not trying to say what
> Debian should or shouldn't do.  They are free to decide for themselves.
> I would never presume to tell them what they should do, although I have
> strong opinions on that. There are lots of problems with their package
> but that is something to be discussed in the Debian bug tracker, not
> here. This project isn't part of Debian. This fact seems to be lost on
> some people.
>
>
The idea Balint had is, that no matter if you are using the official
package or build it yourself with our repository, you will not be locked
out of updating the package or distribution, and most certainly it will not
lead to any issues with package management. This might be a speciality of
Debian, but I think it is something we can support as it does not really
hinder us, except for the issue with the lib manifest, which now seems to
be resolved. And I do think that supporting this choice by our users is
something that is worth supporting.


>
> >
> > The libvirt plugin is a valid example of where we messed up. And with
> > we I mean the whole project. We provided this path and we kept it
> > maintained for far too long, but it is here now and a solution needs
> > to be found. We started on that road with stating that we allow
> > invalidating the api in major version releases and also minor version
> > releases to some extend. The argument, that libvirt is still doing
> > something they should not be doing is valid. But the solution here is
> > not hindering the compatibility, but getting in touch with them and
> > figuring out how to do it properly together. We created this path, we
> > should not destroy it but help others find a safer route. And libvirt
> > is indeed being used by quite a few people.
>
> I don't understand what any of this means, sorry. I'm not being
> facetious, could be my own fault. I have written many Wireshark plugins
> so I know a lot about that topic. What problems are the libvirt people
> experiencing that I am not? What strange and mystical path is this that
> we are on? Why did we mess up? Please enlighten me. Really, I would like
> to know so we can have a fruitful conversation about this because right
> now I am really confused.
>

We made the initial mistake of staying in a patch that allowed for a
situation like this to occur. We made sure that you could link against our
libraries and build your own projects from it. To revert this now, will
lead to issues and pains in various places outside of the project, which
might not seem to be a big thing initially, but it can hurt us in the long
run. Think the whole Gnome 2/3 transition which drove quite a few people
made, although they had a good reason for it.

I agree with you btw on the fact that the way libvirt does this plugin is
not a good one. I think they should stop pretending to be extra smart in
this case and revert to a model, where one plugin version may be compatible
with multiple libvirt versions or vice versa. That would resolve this whole
issue. But unless we are willing to fight this fight (and I for one am not
particularly interested in that pandora's box) I do not see a reason why we
should actively undermine their approach, just for the sake of "being
right". I agree that it would be a better approach, but it would also open
up quite a few birthing pains and that at least would violate our "no
breaking unless major version release" policy. Another one of those we
never actively charted down, but try to uphold.

Hope this clears up the point I was trying to make

kind regards
Roland



> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
>
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository




On 20/12/23 16:06, Roland Knall wrote:
Ok, I am not ignoring those points, as I think those points are valid. 
It makes sense, that building debian packages from the repository 
should behave in the same way as it does with the overall projects. 
Now, one could argue, that having multiple packages could have been 
avoided in the beginning or it should be changed, that would be a 
valid discussion being had, but I do not think it invalidates those 
points and arguments. Yes, debian is different but it is also the base 
(through ubuntu) for the majority of linux distributions as 
wells Microsofts own variety in wsl2 (at least if you go with the 
default one), and therefore it should be considered as such.


I don't know what you are trying to get at. I'm not trying to say what 
Debian should or shouldn't do.  They are free to decide for themselves. 
I would never presume to tell them what they should do, although I have 
strong opinions on that. There are lots of problems with their package 
but that is something to be discussed in the Debian bug tracker, not 
here. This project isn't part of Debian. This fact seems to be lost on 
some people.





The libvirt plugin is a valid example of where we messed up. And with 
we I mean the whole project. We provided this path and we kept it 
maintained for far too long, but it is here now and a solution needs 
to be found. We started on that road with stating that we allow 
invalidating the api in major version releases and also minor version 
releases to some extend. The argument, that libvirt is still doing 
something they should not be doing is valid. But the solution here is 
not hindering the compatibility, but getting in touch with them and 
figuring out how to do it properly together. We created this path, we 
should not destroy it but help others find a safer route. And libvirt 
is indeed being used by quite a few people.


I don't understand what any of this means, sorry. I'm not being 
facetious, could be my own fault. I have written many Wireshark plugins 
so I know a lot about that topic. What problems are the libvirt people 
experiencing that I am not? What strange and mystical path is this that 
we are on? Why did we mess up? Please enlighten me. Really, I would like 
to know so we can have a fruitful conversation about this because right 
now I am really confused.

___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

We messed up in a sense, that we should have found an argument and final
position on API compatibility. Not that it did not work out well, but it
"happened" instead of being planned

That was, what I meant with "messed up".

I read their argument and I still disagree. It might be the best for their
users, but we also facilitated that approach by our approach to the whole
issue.

Am Mi., 20. Dez. 2023 um 19:57 Uhr schrieb Bálint Réczey <
bal...@balintreczey.hu>:

> Roland Knall  ezt írta (időpont: 2023. dec. 20., Sze,
> 17:06):
> >
> > Ok, I am not ignoring those points, as I think those points are valid.
> It makes sense, that building debian packages from the repository should
> behave in the same way as it does with the overall projects. Now, one could
> argue, that having multiple packages could have been avoided in the
> beginning or it should be changed, that would be a valid discussion being
> had, but I do not think it invalidates those points and arguments. Yes,
> debian is different but it is also the base (through ubuntu) for the
> majority of linux distributions as wells Microsofts own variety in wsl2 (at
> least if you go with the default one), and therefore it should be
> considered as such.
> >
> > The examples listed here are valid, although not very widely distributed
> ones. Just because they are not distributed with a debian distribution is
> not a counterargument to the update argument Balint raised. I am also not
> certain, why arguing against that on the pure merit of not being part of a
> distribution is a technical argument.
> >
> > The libvirt plugin is a valid example of where we messed up. And with we
> I mean the whole project. We provided this path and we kept it maintained
> for far too long, but it is here now and a solution needs to be found. We
> started on that road with stating that we allow invalidating the api in
> major version releases and also minor version releases to some extend. The
> argument, that libvirt is still doing something they should not be doing is
> valid. But the solution here is not hindering the compatibility, but
> getting in touch with them and figuring out how to do it properly together.
> We created this path, we should not destroy it but help others find a safer
> route. And libvirt is indeed being used by quite a few people.
>
> I generally agree with you on the other points, but why do you believe
> we messed up? We allow and help external plugin development and did it
> in a widely followed way of maintaining the shared library ABI and
> headers. I think we did great in that regard and libvirt just
> maintains an external plugin, the way we advertised to be possible. I
> also think that there is no better way, but I'll be ready to be proven
> wrong.
>
> We talked about the libvirt plugin and this is why I believe that the
> status quo is the best for the users:
>
> https://gitlab.com/wireshark/wireshark/-/commit/79da670bd1b4f91eebee5c96b19eaf1f33c94777#note_1660815830
>
> I also reached out to them prior to our conversation and they
> elaborated on their decision to ship the plugin separately and I'm
> convinced that that's the best option of the users:
> https://gitlab.com/libvirt/libvirt/-/issues/106#note_488155469
>
> Cheers,
> Balint
>
> >
> > As for the straw man argument, the Code of Conduct defines how
> collaboration and social interaction should happen. As such, I do not see
> this as a straw man argument but a valid reason, why Balint chose the paths
> he chose in the past and why this package exists as it does now. In a
> technical discussion it is as important to understand why somebody did
> something as it is to listen to each others arguments. And this gives
> reason to why the current situation is what it is, and should be validated
> in choosing a solution for the future.
> >
> > kind regards
> > Roland
> >
> > Am Mi., 20. Dez. 2023 um 16:32 Uhr schrieb João Valverde :
> >>
> >> Keep in mind I am just a user but I'm not one to skip a good technical
> >> discussion.
> >>
> >> I'm ignoring your other points on purpose, there is only so much I can
> >> handle in one sitting.
> >>
> >> On 20/12/23 13:24, Bálint Réczey wrote:
> >> > Having separate packages follows Debian packaging best practices and
> >> > served external projects extending wireshark such as netexpect (
> >> >
> https://tracker.debian.org/news/505793/accepted-netexpect-018-1-source-i386/
> >>
> >> I lookup up what netexpect is. Your link is from 2011. Actual link
> >> (https://tracker.debian.org/pkg/netexpect) says "This package is not
> >> part of any Debian distribution." OK... Starting strong there.
> >>
> >> > ) and the separately maintained libvirt dissector (
> >> > https://packages.debian.org/unstable/libvirt-wireshark ).
> >>
> >> You keep coming back to the libvirt plugin. What do you expect to prove
> >> with this? You really think maintaining separate Debian packages is a
> >> benefit to a Wireshark plugin? I'm sorry, I don't know how to respond to
>

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

2023-12-20 Thread Bálint Réczey

Roland Knall  ezt írta (időpont: 2023. dec. 20., Sze, 17:06):
>
> Ok, I am not ignoring those points, as I think those points are valid. It 
> makes sense, that building debian packages from the repository should behave 
> in the same way as it does with the overall projects. Now, one could argue, 
> that having multiple packages could have been avoided in the beginning or it 
> should be changed, that would be a valid discussion being had, but I do not 
> think it invalidates those points and arguments. Yes, debian is different but 
> it is also the base (through ubuntu) for the majority of linux distributions 
> as wells Microsofts own variety in wsl2 (at least if you go with the default 
> one), and therefore it should be considered as such.
>
> The examples listed here are valid, although not very widely distributed 
> ones. Just because they are not distributed with a debian distribution is not 
> a counterargument to the update argument Balint raised. I am also not 
> certain, why arguing against that on the pure merit of not being part of a 
> distribution is a technical argument.
>
> The libvirt plugin is a valid example of where we messed up. And with we I 
> mean the whole project. We provided this path and we kept it maintained for 
> far too long, but it is here now and a solution needs to be found. We started 
> on that road with stating that we allow invalidating the api in major version 
> releases and also minor version releases to some extend. The argument, that 
> libvirt is still doing something they should not be doing is valid. But the 
> solution here is not hindering the compatibility, but getting in touch with 
> them and figuring out how to do it properly together. We created this path, 
> we should not destroy it but help others find a safer route. And libvirt is 
> indeed being used by quite a few people.

I generally agree with you on the other points, but why do you believe
we messed up? We allow and help external plugin development and did it
in a widely followed way of maintaining the shared library ABI and
headers. I think we did great in that regard and libvirt just
maintains an external plugin, the way we advertised to be possible. I
also think that there is no better way, but I'll be ready to be proven
wrong.

We talked about the libvirt plugin and this is why I believe that the
status quo is the best for the users:
https://gitlab.com/wireshark/wireshark/-/commit/79da670bd1b4f91eebee5c96b19eaf1f33c94777#note_1660815830

I also reached out to them prior to our conversation and they
elaborated on their decision to ship the plugin separately and I'm
convinced that that's the best option of the users:
https://gitlab.com/libvirt/libvirt/-/issues/106#note_488155469

Cheers,
Balint

>
> As for the straw man argument, the Code of Conduct defines how collaboration 
> and social interaction should happen. As such, I do not see this as a straw 
> man argument but a valid reason, why Balint chose the paths he chose in the 
> past and why this package exists as it does now. In a technical discussion it 
> is as important to understand why somebody did something as it is to listen 
> to each others arguments. And this gives reason to why the current situation 
> is what it is, and should be validated in choosing a solution for the future.
>
> kind regards
> Roland
>
> Am Mi., 20. Dez. 2023 um 16:32 Uhr schrieb João Valverde :
>>
>> Keep in mind I am just a user but I'm not one to skip a good technical
>> discussion.
>>
>> I'm ignoring your other points on purpose, there is only so much I can
>> handle in one sitting.
>>
>> On 20/12/23 13:24, Bálint Réczey wrote:
>> > Having separate packages follows Debian packaging best practices and
>> > served external projects extending wireshark such as netexpect (
>> > https://tracker.debian.org/news/505793/accepted-netexpect-018-1-source-i386/
>>
>> I lookup up what netexpect is. Your link is from 2011. Actual link
>> (https://tracker.debian.org/pkg/netexpect) says "This package is not
>> part of any Debian distribution." OK... Starting strong there.
>>
>> > ) and the separately maintained libvirt dissector (
>> > https://packages.debian.org/unstable/libvirt-wireshark ).
>>
>> You keep coming back to the libvirt plugin. What do you expect to prove
>> with this? You really think maintaining separate Debian packages is a
>> benefit to a Wireshark plugin? I'm sorry, I don't know how to respond to
>> non-sensical statements. Do you want me to build the libvirt-wireshark
>> plugin against our RPM package just to put this argument to rest once
>> and for all?
>>
>>
>> > As I interpret our Code of Conduct collaboration with other projects
>> > is highly encouraged no matter if Wireshark builds on them or they
>> > build on Wireshark. I acted according to that in maintaining the
>> > Debian packaging both here and in the official Debian repository.
>> >
>>
>> Straw man argument. No one said collaboration is bad.
>>
>>

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

Ok, I am not ignoring those points, as I think those points are valid. It
makes sense, that building debian packages from the repository should
behave in the same way as it does with the overall projects. Now, one could
argue, that having multiple packages could have been avoided in the
beginning or it should be changed, that would be a valid discussion being
had, but I do not think it invalidates those points and arguments. Yes,
debian is different but it is also the base (through ubuntu) for the
majority of linux distributions as wells Microsofts own variety in wsl2 (at
least if you go with the default one), and therefore it should be
considered as such.

The examples listed here are valid, although not very widely distributed
ones. Just because they are not distributed with a debian distribution is
not a counterargument to the update argument Balint raised. I am also not
certain, why arguing against that on the pure merit of not being part of a
distribution is a technical argument.

The libvirt plugin is a valid example of where we messed up. And with we I
mean the whole project. We provided this path and we kept it maintained for
far too long, but it is here now and a solution needs to be found. We
started on that road with stating that we allow invalidating the api in
major version releases and also minor version releases to some extend. The
argument, that libvirt is still doing something they should not be doing is
valid. But the solution here is not hindering the compatibility, but
getting in touch with them and figuring out how to do it properly together.
We created this path, we should not destroy it but help others find a safer
route. And libvirt is indeed being used by quite a few people.

As for the straw man argument, the Code of Conduct defines how
collaboration and social interaction should happen. As such, I do not see
this as a straw man argument but a valid reason, why Balint chose the paths
he chose in the past and why this package exists as it does now. In a
technical discussion it is as important to understand why somebody did
something as it is to listen to each others arguments. And this gives
reason to why the current situation is what it is, and should be validated
in choosing a solution for the future.

kind regards
Roland

Am Mi., 20. Dez. 2023 um 16:32 Uhr schrieb João Valverde :

> Keep in mind I am just a user but I'm not one to skip a good technical
> discussion.
>
> I'm ignoring your other points on purpose, there is only so much I can
> handle in one sitting.
>
> On 20/12/23 13:24, Bálint Réczey wrote:
> > Having separate packages follows Debian packaging best practices and
> > served external projects extending wireshark such as netexpect (
> >
> https://tracker.debian.org/news/505793/accepted-netexpect-018-1-source-i386/
>
> I lookup up what netexpect is. Your link is from 2011. Actual link
> (https://tracker.debian.org/pkg/netexpect) says "This package is not
> part of any Debian distribution." OK... Starting strong there.
>
> > ) and the separately maintained libvirt dissector (
> > https://packages.debian.org/unstable/libvirt-wireshark ).
>
> You keep coming back to the libvirt plugin. What do you expect to prove
> with this? You really think maintaining separate Debian packages is a
> benefit to a Wireshark plugin? I'm sorry, I don't know how to respond to
> non-sensical statements. Do you want me to build the libvirt-wireshark
> plugin against our RPM package just to put this argument to rest once
> and for all?
>
>
> > As I interpret our Code of Conduct collaboration with other projects
> > is highly encouraged no matter if Wireshark builds on them or they
> > build on Wireshark. I acted according to that in maintaining the
> > Debian packaging both here and in the official Debian repository.
> >
>
> Straw man argument. No one said collaboration is bad.
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
>
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

Keep in mind I am just a user but I'm not one to skip a good technical 
discussion.


I'm ignoring your other points on purpose, there is only so much I can 
handle in one sitting.


On 20/12/23 13:24, Bálint Réczey wrote:

Having separate packages follows Debian packaging best practices and
served external projects extending wireshark such as netexpect (
https://tracker.debian.org/news/505793/accepted-netexpect-018-1-source-i386/


I lookup up what netexpect is. Your link is from 2011. Actual link 
(https://tracker.debian.org/pkg/netexpect) says "This package is not 
part of any Debian distribution." OK... Starting strong there.



) and the separately maintained libvirt dissector (
https://packages.debian.org/unstable/libvirt-wireshark ).


You keep coming back to the libvirt plugin. What do you expect to prove 
with this? You really think maintaining separate Debian packages is a 
benefit to a Wireshark plugin? I'm sorry, I don't know how to respond to 
non-sensical statements. Do you want me to build the libvirt-wireshark 
plugin against our RPM package just to put this argument to rest once 
and for all?




As I interpret our Code of Conduct collaboration with other projects
is highly encouraged no matter if Wireshark builds on them or they
build on Wireshark. I acted according to that in maintaining the
Debian packaging both here and in the official Debian repository.



Straw man argument. No one said collaboration is bad.

___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

Hi Balint

It would be worth amending the Readme with this information, as well as the
packaging section of the wiki, to ensure this information is not getting
lost and future discussions may be avoided by pointing to it.

kind regards
Roland

Am Mi., 20. Dez. 2023 um 14:24 Uhr schrieb Bálint Réczey <
bal...@balintreczey.hu>:

> Hi,
>
> João Valverde  ezt írta (időpont: 2023. nov. 27., H, 21:42):
> >
> >
> >
> > On 27/11/23 16:26, Jeff Morriss wrote:
> > > On Wed, Nov 22, 2023 at 11:54 AM João Valverde  wrote:
> > >
> > >
> > > On 22/11/23 15:37, John Thacker wrote:
> > >> On Wed, Nov 22, 2023 at 9:40 AM João Valverde  wrote:
> > >>
> > >>
> > >> There are a myriad issues I have touched upon. To recap, in
> > >> my opinion, if we want to provide public shared libraries
> > >> (libwireshark, wiretap, wsutil... for what I don't know) we
> > >> should do a better job of that collectively as a project. If
> > >> we don't want to do that we should kill the Debian package
> > >> inanity.
> > >>
> > >> A third alternative is just to keep the status quo and I'll
> > >> try to avoid this subject entirely because of how much it
> > >> bothers me to just ignore all these technical issues.
> > >>
> > >>
> > >> My understanding of the Debian packaging scripts (and similar for
> > >> the RPM package) use case is that people might be running one of
> > >> those distributions and want to upgrade Wireshark on their system
> > >> using their distribution's native package manager by taking
> > >> either a git repository or a tarball and building a package that
> > >> they can upgrade their distribution-provided package to.
> > >>
> > >> That isn't necessarily to add custom dissectors and provide
> > >> public shared libraries, though it could be. Oftentimes it's as
> > >> simple as "my distribution is capable of compiling 3.6.x or
> > >> later, but for stability reasons it's still shipping 2.6.x
> > >> (Debian buster/oldstable, RHEL 8 and clones)," and someone wants
> > >> to update wireshark without any of their own changes, just
> > >> without upgrading their distribution. It's handy to be able to
> > >> accommodate that if possible.
> > >
> > > Thanks for the feedback. Let me try to break down my response to
> that:
> > >
> > > 1. I think spending resources on distro packaging is unwise in
> > > general. "Make install" works fine and there are great maintainers
> > > already doing that work for Linux distributions. RPM is just
> > > low-effort low-intrusion enough that it doesn't bother me to
> > > divert from other tasks to work on it when I have to.
> > >
> > >
> > > I used to maintain a custom Wireshark build.  The packaging stuff was
> > > invaluable for that: it allowed me to compile (and easily package)
> > > once and push the resulting RPMs to hundreds of systems.  "make
> > > install" would not have worked for me as the end (user) systems were
> > > not capable of compiling Wireshark.
> > >
> > > I also, for a while, used our RPM stuff as an upstream example for
> > > Fedora/Red Hat to improve their packaging, including (IIRC) bringing
> > > in all the freedesktop integration stuff.  It was a lot easier to
> > > check that stuff into Wireshark and point them to it than try to do
> > > all the work in their world/repo (which is unfamiliar to me).
> > >
> >
> > I was addressing the user-wants-to-build-locally use case with the "make
> > install" comment.
> >
> > To address your use-case:
> >
> > 1. Someone whose job is to maintain a custom build for a medium/large
> > organization does not depend on us to create a package, although it can
> > help of course. At the end of the day resources are limited and need to
> > be prioritized for a volunteer project. Like I said, RPM doesn't bother
> > me, it rarely gets in my way or demands much of my time.
> >
> > 2. If someone on the Wireshark team wants to assume the package
> > maintainer role that could work if they are responsive and not putting
> > some distribution's priorities above our own.
>
> I tried to assess the amount of work required by the presence of the
> Debian packaging scripts in the repository.
> This is what I found covering roughly one year of development in the
> master branch between branching off the 4.0 and 4.2 releases:
>
> $ git merge-base origin/release-4.2 origin/master | xargs git describe
> v4.1.1rc0-386-geb539196a9
> $ git merge-base origin/release-4.2 origin/release-4.0  | xargs git
> describe
> v3.7.3rc0-146-g7d583e1340
> $ git log --oneline v3.7.3rc0-146-g7d583e1340..v4.1.1rc0-386-geb539196a9 |
> wc -l
> 3925
> $ git log --oneline
> v3.7.3rc0-146-g7d583e1340..v4.1.1rc0-386-geb539196a9 --
> packaging/debian/ | wc -l
> 64
> $ git log --oneline
> v3.7.3rc0-146-g7d583e1340..v4.1.1rc0-386-geb539196a9 --
> packaging/debian/*.symbols | wc -l
> 50
>
> 1.6% of all the commits touched the

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

2023-12-20 Thread Bálint Réczey

Hi,

João Valverde  ezt írta (időpont: 2023. nov. 27., H, 21:42):
>
>
>
> On 27/11/23 16:26, Jeff Morriss wrote:
> > On Wed, Nov 22, 2023 at 11:54 AM João Valverde  wrote:
> >
> >
> > On 22/11/23 15:37, John Thacker wrote:
> >> On Wed, Nov 22, 2023 at 9:40 AM João Valverde  wrote:
> >>
> >>
> >> There are a myriad issues I have touched upon. To recap, in
> >> my opinion, if we want to provide public shared libraries
> >> (libwireshark, wiretap, wsutil... for what I don't know) we
> >> should do a better job of that collectively as a project. If
> >> we don't want to do that we should kill the Debian package
> >> inanity.
> >>
> >> A third alternative is just to keep the status quo and I'll
> >> try to avoid this subject entirely because of how much it
> >> bothers me to just ignore all these technical issues.
> >>
> >>
> >> My understanding of the Debian packaging scripts (and similar for
> >> the RPM package) use case is that people might be running one of
> >> those distributions and want to upgrade Wireshark on their system
> >> using their distribution's native package manager by taking
> >> either a git repository or a tarball and building a package that
> >> they can upgrade their distribution-provided package to.
> >>
> >> That isn't necessarily to add custom dissectors and provide
> >> public shared libraries, though it could be. Oftentimes it's as
> >> simple as "my distribution is capable of compiling 3.6.x or
> >> later, but for stability reasons it's still shipping 2.6.x
> >> (Debian buster/oldstable, RHEL 8 and clones)," and someone wants
> >> to update wireshark without any of their own changes, just
> >> without upgrading their distribution. It's handy to be able to
> >> accommodate that if possible.
> >
> > Thanks for the feedback. Let me try to break down my response to that:
> >
> > 1. I think spending resources on distro packaging is unwise in
> > general. "Make install" works fine and there are great maintainers
> > already doing that work for Linux distributions. RPM is just
> > low-effort low-intrusion enough that it doesn't bother me to
> > divert from other tasks to work on it when I have to.
> >
> >
> > I used to maintain a custom Wireshark build.  The packaging stuff was
> > invaluable for that: it allowed me to compile (and easily package)
> > once and push the resulting RPMs to hundreds of systems.  "make
> > install" would not have worked for me as the end (user) systems were
> > not capable of compiling Wireshark.
> >
> > I also, for a while, used our RPM stuff as an upstream example for
> > Fedora/Red Hat to improve their packaging, including (IIRC) bringing
> > in all the freedesktop integration stuff.  It was a lot easier to
> > check that stuff into Wireshark and point them to it than try to do
> > all the work in their world/repo (which is unfamiliar to me).
> >
>
> I was addressing the user-wants-to-build-locally use case with the "make
> install" comment.
>
> To address your use-case:
>
> 1. Someone whose job is to maintain a custom build for a medium/large
> organization does not depend on us to create a package, although it can
> help of course. At the end of the day resources are limited and need to
> be prioritized for a volunteer project. Like I said, RPM doesn't bother
> me, it rarely gets in my way or demands much of my time.
>
> 2. If someone on the Wireshark team wants to assume the package
> maintainer role that could work if they are responsive and not putting
> some distribution's priorities above our own.

I tried to assess the amount of work required by the presence of the
Debian packaging scripts in the repository.
This is what I found covering roughly one year of development in the
master branch between branching off the 4.0 and 4.2 releases:

$ git merge-base origin/release-4.2 origin/master | xargs git describe
v4.1.1rc0-386-geb539196a9
$ git merge-base origin/release-4.2 origin/release-4.0  | xargs git describe
v3.7.3rc0-146-g7d583e1340
$ git log --oneline v3.7.3rc0-146-g7d583e1340..v4.1.1rc0-386-geb539196a9 | wc -l
3925
$ git log --oneline
v3.7.3rc0-146-g7d583e1340..v4.1.1rc0-386-geb539196a9 --
packaging/debian/ | wc -l
64
$ git log --oneline
v3.7.3rc0-146-g7d583e1340..v4.1.1rc0-386-geb539196a9 --
packaging/debian/*.symbols | wc -l
50

1.6% of all the commits touched the packaging scripts. Most of the
1.6% is updating the symbols files when the shared library ABI changed
and I did not consider that excessive, but seeing the complaints I've
switched the packaging to not require symbols file updates in
https://gitlab.com/wireshark/wireshark/-/merge_requests/13385 .

The remaining Debian packaging script 14 updates accidentally matches
the number of updates to the RPM scripts and makes up 0.3% of all
Wireshark commits in the analyzed history:
$ git log --oneline

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

2023-11-27 Thread João Valverde




On 27/11/23 16:26, Jeff Morriss wrote:

On Wed, Nov 22, 2023 at 11:54 AM João Valverde  wrote:


On 22/11/23 15:37, John Thacker wrote:

On Wed, Nov 22, 2023 at 9:40 AM João Valverde  wrote:


There are a myriad issues I have touched upon. To recap, in
my opinion, if we want to provide public shared libraries
(libwireshark, wiretap, wsutil... for what I don't know) we
should do a better job of that collectively as a project. If
we don't want to do that we should kill the Debian package
inanity.

A third alternative is just to keep the status quo and I'll
try to avoid this subject entirely because of how much it
bothers me to just ignore all these technical issues.


My understanding of the Debian packaging scripts (and similar for
the RPM package) use case is that people might be running one of
those distributions and want to upgrade Wireshark on their system
using their distribution's native package manager by taking
either a git repository or a tarball and building a package that
they can upgrade their distribution-provided package to.

That isn't necessarily to add custom dissectors and provide
public shared libraries, though it could be. Oftentimes it's as
simple as "my distribution is capable of compiling 3.6.x or
later, but for stability reasons it's still shipping 2.6.x
(Debian buster/oldstable, RHEL 8 and clones)," and someone wants
to update wireshark without any of their own changes, just
without upgrading their distribution. It's handy to be able to
accommodate that if possible.


Thanks for the feedback. Let me try to break down my response to that:

1. I think spending resources on distro packaging is unwise in
general. "Make install" works fine and there are great maintainers
already doing that work for Linux distributions. RPM is just
low-effort low-intrusion enough that it doesn't bother me to
divert from other tasks to work on it when I have to.


I used to maintain a custom Wireshark build.  The packaging stuff was 
invaluable for that: it allowed me to compile (and easily package) 
once and push the resulting RPMs to hundreds of systems.  "make 
install" would not have worked for me as the end (user) systems were 
not capable of compiling Wireshark.


I also, for a while, used our RPM stuff as an upstream example for 
Fedora/Red Hat to improve their packaging, including (IIRC) bringing 
in all the freedesktop integration stuff.  It was a lot easier to 
check that stuff into Wireshark and point them to it than try to do 
all the work in their world/repo (which is unfamiliar to me).




I was addressing the user-wants-to-build-locally use case with the "make 
install" comment.


To address your use-case:

1. Someone whose job is to maintain a custom build for a medium/large 
organization does not depend on us to create a package, although it can 
help of course. At the end of the day resources are limited and need to 
be prioritized for a volunteer project. Like I said, RPM doesn't bother 
me, it rarely gets in my way or demands much of my time.


2. If someone on the Wireshark team wants to assume the package 
maintainer role that could work if they are responsive and not putting 
some distribution's priorities above our own.


3. Forcing every Wireshark developer to maintain the Debian package like 
the Debian maintainer thinks it should be maintained is definitely not 
fine in my opinion. Nobody so far has been able to offer any sort of 
technical explanation for packaging Wireshark's libraries separately, 
because there is no such rationale, other than Balint is really into 
that stuff.


___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

2023-11-27 Thread Jeff Morriss

On Wed, Nov 22, 2023 at 11:54 AM João Valverde  wrote:

>
> On 22/11/23 15:37, John Thacker wrote:
>
> On Wed, Nov 22, 2023 at 9:40 AM João Valverde  wrote:
>
>>
>> There are a myriad issues I have touched upon. To recap, in my opinion,
>> if we want to provide public shared libraries (libwireshark, wiretap,
>> wsutil... for what I don't know) we should do a better job of that
>> collectively as a project. If we don't want to do that we should kill the
>> Debian package inanity.
>>
>> A third alternative is just to keep the status quo and I'll try to avoid
>> this subject entirely because of how much it bothers me to just ignore all
>> these technical issues.
>>
>
> My understanding of the Debian packaging scripts (and similar for the RPM
> package) use case is that people might be running one of those
> distributions and want to upgrade Wireshark on their system using their
> distribution's native package manager by taking either a git repository or
> a tarball and building a package that they can upgrade their
> distribution-provided package to.
>
> That isn't necessarily to add custom dissectors and provide public shared
> libraries, though it could be. Oftentimes it's as simple as "my
> distribution is capable of compiling 3.6.x or later, but for stability
> reasons it's still shipping 2.6.x (Debian buster/oldstable, RHEL 8 and
> clones)," and someone wants to update wireshark without any of their own
> changes, just without upgrading their distribution. It's handy to be able
> to accommodate that if possible.
>
>
> Thanks for the feedback. Let me try to break down my response to that:
>
> 1. I think spending resources on distro packaging is unwise in general.
> "Make install" works fine and there are great maintainers already doing
> that work for Linux distributions. RPM is just low-effort low-intrusion
> enough that it doesn't bother me to divert from other tasks to work on it
> when I have to.
>

I used to maintain a custom Wireshark build.  The packaging stuff was
invaluable for that: it allowed me to compile (and easily package) once and
push the resulting RPMs to hundreds of systems.  "make install" would not
have worked for me as the end (user) systems were not capable of compiling
Wireshark.

I also, for a while, used our RPM stuff as an upstream example for
Fedora/Red Hat to improve their packaging, including (IIRC) bringing in all
the freedesktop integration stuff.  It was a lot easier to check that stuff
into Wireshark and point them to it than try to do all the work in their
world/repo (which is unfamiliar to me).
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

2023-11-23 Thread João Valverde

I kindly ask you to decide whether we should keep the Debian package
as-is and explain the use-case for the current state of the Debian
package in Wireshark, because it is not clear to me at all. Honestly,
the situation kind of baffles me since it is not used by the Debian
project and they don't help maintain it. Mistakes happen but it is
necessary to allow debate and course-corrections IMO. I still remember
of painful it was to fix and eventually remove the ABI checker thing
that severely degraded the old autotools build.

I don't think anyone should be upset if things don't go their way, as
long as decisions are based on technical merit and minimally sound
judgement. Anyway it's better to have a resolution for these sort of
disagreements.

On 22/11/23 18:28, Gerald Combs wrote:
I think this falls well within the scope of the steering committee,
and would be a good first exercise.

On 11/22/23 3:45 AM, Roland Knall wrote:

I would recommend that we bring this topic before the technical
steering committee. As of right now, that committee needs to be
formed in January and this topic is exactly why we are going to have
the committee in the first place. The process is in the final steps
and should be finished by the end of the year anyway.

I do not think that further discussing this issue is actually
beneficial for the long term resolution of this situation. Both sides
have valid arguments and good pointers and I would suggest as soon as
the committee has taken up the topic we collectively create a single
mission statement as suggested by Joao above. Until then, personally
I will refrain from discussing this further, as I have said
everything there is to say from my perspective.

Do you agree Gerald?

kind regards
Roland

Am Mi., 22. Nov. 2023 um 12:36 Uhr schrieb João Valverde >:

__
Maybe you´d like to volunteer to maintain the Wireshark Debian
assets? Since you've got the experience and actually use it?

There are loads of lintian warnings waiting to be fixed, or there
were until recently. Maybe you'd like to start there, and be more
active staying on top of the all-important symbol lists. Just a thought.

On 21/11/23 15:00, Anders Broman wrote:

Hi,
I found it useful to be able to do Debian packages easily to
provide internal installation packages and even ppa for Ubuntu.

So I have been using the Debian build system.
Best regards
Anders

Den tis 21 nov. 2023 15:48Roland Knall > skrev:

As mentioned on the ticket - just putting it here as well -
I am against dropping packaging/debian. But I am for having it
underneath packaging, and not in the main directory, which is what
the original change was about. I respect Joao's opinion as well as
yours Balint. In this case here I think, we can provide assistance
for future implementors and as a starting point, by keeping the
directory underneath packaging/debian.

just my thoughts
Roland

Am Di., 21. Nov. 2023 um 15:28 Uhr schrieb Bálint Réczey
mailto:bal...@balintreczey.hu>>:

Hi All,

João shared his opinion about the project's commitment
to maintain the

packaging/debian/ in the project's repository:

https://gitlab.com/wireshark/wireshark/-/commit/79da670bd1b4f91eebee5c96b19eaf1f33c94777#note_1656501952

I believe the current practice is reasonable and
beneficial enough for

many parties to warrant the work, but I could be wrong.

Probably the most important question is if there is
anyone relying on
the packaging scripts there. If you are, please speak up
otherwise the

directory may be dropped.

Comments are welcome.

Cheers,
Balint
___
Sent via: Wireshark-dev mailing list
mailto:wireshark-dev@wireshark.org>>
Archives: https://www.wireshark.org/lists/wireshark-dev

Unsubscribe:
https://www.wireshark.org/mailman/options/wireshark-dev

mailto:wireshark-dev-requ...@wireshark.org
?subject=unsubscribe

___
Sent via: Wireshark-dev mailing list
mailto:wireshark-dev@wireshark.org>>
Archives: https://www.wireshark.org/lists/wireshark-dev

Unsubscribe:
https://www.wireshark.org/mailman/options/wireshark-dev

mailto:wireshark-dev-requ...@wireshark.org

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

2023-11-22 Thread Gerald Combs

I think this falls well within the scope of the steering committee, and would
be a good first exercise.

On 11/22/23 3:45 AM, Roland Knall wrote:

I would recommend that we bring this topic before the technical steering
committee. As of right now, that committee needs to be formed in January and
this topic is exactly why we are going to have the committee in the first
place. The process is in the final steps and should be finished by the end of
the year anyway.

I do not think that further discussing this issue is actually beneficial for
the long term resolution of this situation. Both sides have valid arguments and
good pointers and I would suggest as soon as the committee has taken up the
topic we collectively create a single mission statement as suggested by Joao
above. Until then, personally I will refrain from discussing this further, as I
have said everything there is to say from my perspective.

Do you agree Gerald?

kind regards
Roland

Am Mi., 22. Nov. 2023 um 12:36 Uhr schrieb João Valverde mailto:j...@v6e.pt>>:

__
Maybe you´d like to volunteer to maintain the Wireshark Debian assets?
Since you've got the experience and actually use it?

There are loads of lintian warnings waiting to be fixed, or there were
until recently. Maybe you'd like to start there, and be more active staying on
top of the all-important symbol lists. Just a thought.

On 21/11/23 15:00, Anders Broman wrote:

Hi,
I found it useful to be able to do Debian packages easily to provide
internal installation packages and even ppa for Ubuntu.
So I have been using the Debian build system.
Best regards
Anders

Den tis 21 nov. 2023 15:48Roland Knall mailto:rkn...@gmail.com>> skrev:

As mentioned on the ticket - just putting it here as well - I am
against dropping packaging/debian. But I am for having it underneath packaging,
and not in the main directory, which is what the original change was about. I
respect Joao's opinion as well as yours Balint. In this case here I think, we
can provide assistance for future implementors and as a starting point, by
keeping the directory underneath packaging/debian.

just my thoughts
Roland

Am Di., 21. Nov. 2023 um 15:28 Uhr schrieb Bálint Réczey mailto:bal...@balintreczey.hu>>:

Hi All,

João shared his opinion about the project's commitment to maintain
the
packaging/debian/ in the project's repository:

https://gitlab.com/wireshark/wireshark/-/commit/79da670bd1b4f91eebee5c96b19eaf1f33c94777#note_1656501952

I believe the current practice is reasonable and beneficial enough
for
many parties to warrant the work, but I could be wrong.

Probably the most important question is if there is anyone relying
on
the packaging scripts there. If you are, please speak up otherwise
the
directory may be dropped.

Comments are welcome.

Cheers,
Balint

___
Sent via: Wireshark-dev mailing list mailto:wireshark-dev@wireshark.org>>
Archives: https://www.wireshark.org/lists/wireshark-dev

Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev

mailto:wireshark-dev-requ...@wireshark.org
?subject=unsubscribe

___
Sent via: Wireshark-dev mailing list mailto:wireshark-dev@wireshark.org>>
Archives: https://www.wireshark.org/lists/wireshark-dev

Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev

mailto:wireshark-dev-requ...@wireshark.org
?subject=unsubscribe

___
Sent via:Wireshark-dev mailing list

Archives:https://www.wireshark.org/lists/wireshark-dev

Unsubscribe:https://www.wireshark.org/mailman/options/wireshark-dev

mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

___
Sent via: Wireshark-dev mailing list mailto:wireshark-dev@wireshark.org>>

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository




On 22/11/23 15:37, John Thacker wrote:


On Wed, Nov 22, 2023 at 9:40 AM João Valverde  wrote:


There are a myriad issues I have touched upon. To recap, in my
opinion, if we want to provide public shared libraries
(libwireshark, wiretap, wsutil... for what I don't know) we should
do a better job of that collectively as a project. If we don't
want to do that we should kill the Debian package inanity.

A third alternative is just to keep the status quo and I'll try to
avoid this subject entirely because of how much it bothers me to
just ignore all these technical issues.


My understanding of the Debian packaging scripts (and similar for the 
RPM package) use case is that people might be running one of those 
distributions and want to upgrade Wireshark on their system using 
their distribution's native package manager by taking either a git 
repository or a tarball and building a package that they can upgrade 
their distribution-provided package to.


That isn't necessarily to add custom dissectors and provide public 
shared libraries, though it could be. Oftentimes it's as simple as "my 
distribution is capable of compiling 3.6.x or later, but for stability 
reasons it's still shipping 2.6.x (Debian buster/oldstable, RHEL 8 and 
clones)," and someone wants to update wireshark without any of their 
own changes, just without upgrading their distribution. It's handy to 
be able to accommodate that if possible.


Thanks for the feedback. Let me try to break down my response to that:

1. I think spending resources on distro packaging is unwise in general. 
"Make install" works fine and there are great maintainers already doing 
that work for Linux distributions. RPM is just low-effort low-intrusion 
enough that it doesn't bother me to divert from other tasks to work on 
it when I have to.


2. Debian is especially ill-suited for end-users building locally. The 
recommended way to have a stable system without broken dependencies is 
to create a local APT repository. Anything else is asking for trouble.


3. Our Debian package is particularly unfriendly to the 
user-wants-to-build-locally use-case. I could maybe see providing a 
basic .deb package but why are we syncing changes from downstream with 5 
different binary packages and loads of Debian policy baggage? It's a 
very unique situation and I fail to see any benefit for end-users or 
Wireshark developers. Maybe the reason is that we would like to be the 
best upstream possible for Debian. It's a reason at least.




I think moving the packaging assets to the packaging directory and 
telling people to symbolically link it to build Debian, as we've been 
doing, is a relatively minor imposition for the Debian folks, but my 
understanding is that the package builds will fail if all the Lintian 
stuff isn't done, which creates a burden on us.


On RPM distributions there's an annoyance because Red Hat / Fedora 
decided to change their package names around a bit, so they're no 
longer quite compatible with the old names which we provide (and which 
still work with other RPM-based distros - 
https://gitlab.com/wireshark/wireshark/-/issues/18709 ).


John Thacker

___
Sent via:Wireshark-dev mailing list
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe:https://www.wireshark.org/mailman/options/wireshark-dev
  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

2023-11-22 Thread John Thacker

On Wed, Nov 22, 2023 at 10:37 AM John Thacker  wrote:

>
> I think moving the packaging assets to the packaging directory and telling
> people to symbolically link it to build Debian, as we've been doing, is a
> relatively minor imposition for the Debian folks, but my understanding is
> that the package builds will fail if all the Lintian stuff isn't done,
> which creates a burden on us.
>

And it looks like Balint is trying to present a compromise on the symbols
issue:

https://gitlab.com/wireshark/wireshark/-/merge_requests/13385

John
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

2023-11-22 Thread John Thacker

On Wed, Nov 22, 2023 at 9:40 AM João Valverde  wrote:

>
> There are a myriad issues I have touched upon. To recap, in my opinion, if
> we want to provide public shared libraries (libwireshark, wiretap,
> wsutil... for what I don't know) we should do a better job of that
> collectively as a project. If we don't want to do that we should kill the
> Debian package inanity.
>
> A third alternative is just to keep the status quo and I'll try to avoid
> this subject entirely because of how much it bothers me to just ignore all
> these technical issues.
>

My understanding of the Debian packaging scripts (and similar for the RPM
package) use case is that people might be running one of those
distributions and want to upgrade Wireshark on their system using their
distribution's native package manager by taking either a git repository or
a tarball and building a package that they can upgrade their
distribution-provided package to.

That isn't necessarily to add custom dissectors and provide public shared
libraries, though it could be. Oftentimes it's as simple as "my
distribution is capable of compiling 3.6.x or later, but for stability
reasons it's still shipping 2.6.x (Debian buster/oldstable, RHEL 8 and
clones)," and someone wants to update wireshark without any of their own
changes, just without upgrading their distribution. It's handy to be able
to accommodate that if possible.

I think moving the packaging assets to the packaging directory and telling
people to symbolically link it to build Debian, as we've been doing, is a
relatively minor imposition for the Debian folks, but my understanding is
that the package builds will fail if all the Lintian stuff isn't done,
which creates a burden on us.

On RPM distributions there's an annoyance because Red Hat / Fedora decided
to change their package names around a bit, so they're no longer quite
compatible with the old names which we provide (and which still work with
other RPM-based distros -
https://gitlab.com/wireshark/wireshark/-/issues/18709 ).

John Thacker
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository




On 22/11/23 14:39, João Valverde wrote:



On 22/11/23 13:12, Pascal Quantin wrote:

Hi Joao,

Le mer. 22 nov. 2023 à 14:01, João Valverde  a écrit :

You are free to participate in the discussion or not. But I
really don't care to wait for the new committee that is pretty
much exactly the same as the old committee, as far as I can tell.

Anyway silence is another Wireshark project classic. At least you
tried to bring something to the debate, so thank you for that, at
least.


It seems like the discussion is shifting away from the initial goal. 
I don't think aggression/criticism/sarcasm brings anything to the 
debate, so I would prefer to keep a constructive exchange between 
whoever feels involved in the subject. I personally have never used 
the Debian scripts, but I did not consider updating the symbols list 
as being a really time consuming task (and I did it numerous times in 
the past), so I do not have an opinion on whether the current status 
quo is good or bad.
Balint's initial email was to collect some feedback regarding whether 
the scripts are being used or not. Anders provided the first 
feedback, let's see if others do (with the hope that they are 
monitoring this list...).




There are a myriad issues I have touched upon. To recap, in my 
opinion, if we want to provide public shared libraries (libwireshark, 
wiretap, wsutil... for what I don't know) we should do a better job of 
that collectively as a project. If we don't want to do that we should 
kill the Debian package inanity.


A third alternative is just to keep the status quo and I'll try to 
avoid this subject entirely because of how much it bothers me to just 
ignore all these technical issues.


To bring it back to the original issue, I personally disagree with 
moving the Debian assets into the packaging subdir, although I 
sympathize with the reasons of course, and it doesn't bother me in the 
slightest because I don't use it.


Many if not all Debian tools expect a top dir debian directory. And I 
totally understand Debian not trying to accommodate something that is 
not a relevant use-case for the Debian system (like upstream having 
different ideas of what a filesystem layout should be).


Moving it just makes using the Debian package less practical and useful 
than it already is.





Best regards,
Pascal.


On 22/11/23 11:45, Roland Knall wrote:

Hi

I would recommend that we bring this topic before the technical
steering committee. As of right now, that committee needs to be
formed in January and this topic is exactly why we are going to
have the committee in the first place. The process is in the
final steps and should be finished by the end of the year anyway.

I do not think that further discussing this issue is actually
beneficial for the long term resolution of this situation. Both
sides have valid arguments and good pointers and I would suggest
as soon as the committee has taken up the topic we collectively
create a single mission statement as suggested by Joao above.
Until then, personally I will refrain from discussing this
further, as I have said everything there is to say from
my perspective.

Do you agree Gerald?

kind regards
Roland



Am Mi., 22. Nov. 2023 um 12:36 Uhr schrieb João Valverde :

Maybe you´d like to volunteer to maintain the Wireshark
Debian assets? Since you've got the experience and actually
use it?

There are loads of lintian warnings waiting to be fixed, or
there were until recently. Maybe you'd like to start there,
and be more active staying on top of the all-important
symbol lists. Just a thought.

On 21/11/23 15:00, Anders Broman wrote:

Hi,
I found it useful to be able to do Debian packages easily
to provide internal installation packages and even ppa for
Ubuntu.
So I have been using the Debian build system.
Best regards
Anders

Den tis 21 nov. 2023 15:48Roland Knall 
skrev:

As mentioned on the ticket - just putting it here as
well - I am against dropping packaging/debian. But I am
for having it underneath packaging, and not in the main
directory, which is what the original change was about.
I respect Joao's opinion as well as yours Balint. In
this case here I think, we can provide assistance for
future implementors and as a starting point, by keeping
the directory underneath packaging/debian.

just my thoughts
Roland


Am Di., 21. Nov. 2023 um 15:28 Uhr schrieb Bálint
Réczey :

Hi All,

João shared his opinion about the project's
commitment to maintain the
packaging/debian/ in the project's repository:

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

On 22/11/23 13:12, Pascal Quantin wrote:

Hi Joao,

Le mer. 22 nov. 2023 à 14:01, João Valverde a écrit :

You are free to participate in the discussion or not. But I really
don't care to wait for the new committee that is pretty much
exactly the same as the old committee, as far as I can tell.

Anyway silence is another Wireshark project classic. At least you
tried to bring something to the debate, so thank you for that, at
least.

It seems like the discussion is shifting away from the initial goal. I
don't think aggression/criticism/sarcasm brings anything to the
debate, so I would prefer to keep a constructive exchange between
whoever feels involved in the subject. I personally have never used
the Debian scripts, but I did not consider updating the symbols list
as being a really time consuming task (and I did it numerous times in
the past), so I do not have an opinion on whether the current status
quo is good or bad.
Balint's initial email was to collect some feedback regarding whether
the scripts are being used or not. Anders provided the first feedback,
let's see if others do (with the hope that they are monitoring this
list...).

There are a myriad issues I have touched upon. To recap, in my opinion,
if we want to provide public shared libraries (libwireshark, wiretap,
wsutil... for what I don't know) we should do a better job of that
collectively as a project. If we don't want to do that we should kill
the Debian package inanity.

A third alternative is just to keep the status quo and I'll try to avoid
this subject entirely because of how much it bothers me to just ignore
all these technical issues.

Best regards,
Pascal.

On 22/11/23 11:45, Roland Knall wrote:

I would recommend that we bring this topic before the technical
steering committee. As of right now, that committee needs to be
formed in January and this topic is exactly why we are going to
have the committee in the first place. The process is in the
final steps and should be finished by the end of the year anyway.

I do not think that further discussing this issue is actually
beneficial for the long term resolution of this situation. Both
sides have valid arguments and good pointers and I would suggest
as soon as the committee has taken up the topic we collectively
create a single mission statement as suggested by Joao above.
Until then, personally I will refrain from discussing this
further, as I have said everything there is to say from
my perspective.

Do you agree Gerald?

kind regards
Roland

Am Mi., 22. Nov. 2023 um 12:36 Uhr schrieb João Valverde :

Maybe you´d like to volunteer to maintain the Wireshark
Debian assets? Since you've got the experience and actually
use it?

There are loads of lintian warnings waiting to be fixed, or
there were until recently. Maybe you'd like to start there,
and be more active staying on top of the all-important symbol
lists. Just a thought.

On 21/11/23 15:00, Anders Broman wrote:

Hi,
I found it useful to be able to do Debian packages easily to
provide internal installation packages and even ppa for Ubuntu.
So I have been using the Debian build system.
Best regards
Anders

Den tis 21 nov. 2023 15:48Roland Knall skrev:

As mentioned on the ticket - just putting it here as
well - I am against dropping packaging/debian. But I am
for having it underneath packaging, and not in the main
directory, which is what the original change was about.
I respect Joao's opinion as well as yours Balint. In
this case here I think, we can provide assistance for
future implementors and as a starting point, by keeping
the directory underneath packaging/debian.

just my thoughts
Roland

Am Di., 21. Nov. 2023 um 15:28 Uhr schrieb Bálint Réczey
:

Hi All,

João shared his opinion about the project's
commitment to maintain the
packaging/debian/ in the project's repository:

https://gitlab.com/wireshark/wireshark/-/commit/79da670bd1b4f91eebee5c96b19eaf1f33c94777#note_1656501952

I believe the current practice is reasonable and
beneficial enough for
many parties to warrant the work, but I could be wrong.

Probably the most important question is if there is
anyone relying on
the packaging scripts there. If you are, please
speak up otherwise the
directory may be dropped.

Comments are welcome.

Cheers,
Balint

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

On 22/11/23 13:23, Martin Mathieson via Wireshark-dev wrote:
Pretty sure I'm not adding anything useful here, but I was only
vaguely aware of debian packaging support. If I'm sharing builds with
colleagues, I use Windows packaging, or for Ubuntu we tend to set
CMAKE_INSTALL_PREFIX, build the 'install' target and transfer it as a
tarball.

You can use CPack for that now. Something like "cpack -G TZST
". Works really well in my opinion.

On Wed, Nov 22, 2023 at 1:12 PM Pascal Quantin
wrote:

Hi Joao,

Le mer. 22 nov. 2023 à 14:01, João Valverde a écrit :

You are free to participate in the discussion or not. But I
really don't care to wait for the new committee that is pretty
much exactly the same as the old committee, as far as I can tell.

Anyway silence is another Wireshark project classic. At least
you tried to bring something to the debate, so thank you for
that, at least.

It seems like the discussion is shifting away from the initial
goal. I don't think aggression/criticism/sarcasm brings anything
to the debate, so I would prefer to keep a constructive exchange
between whoever feels involved in the subject. I personally have
never used the Debian scripts, but I did not consider updating the
symbols list as being a really time consuming task (and I did it
numerous times in the past), so I do not have an opinion on
whether the current status quo is good or bad.
Balint's initial email was to collect some feedback regarding
whether the scripts are being used or not. Anders provided the
first feedback, let's see if others do (with the hope that they
are monitoring this list...).

Best regards,
Pascal.

On 22/11/23 11:45, Roland Knall wrote:

I would recommend that we bring this topic before the
technical steering committee. As of right now, that committee
needs to be formed in January and this topic is exactly why
we are going to have the committee in the first place. The
process is in the final steps and should be finished by the
end of the year anyway.

I do not think that further discussing this issue is actually
beneficial for the long term resolution of this situation.
Both sides have valid arguments and good pointers and I would
suggest as soon as the committee has taken up the topic we
collectively create a single mission statement as suggested
by Joao above. Until then, personally I will refrain from
discussing this further, as I have said everything there is
to say from my perspective.

Do you agree Gerald?

kind regards
Roland

Am Mi., 22. Nov. 2023 um 12:36 Uhr schrieb João Valverde
:

Maybe you´d like to volunteer to maintain the Wireshark
Debian assets? Since you've got the experience and
actually use it?

There are loads of lintian warnings waiting to be fixed,
or there were until recently. Maybe you'd like to start
there, and be more active staying on top of the
all-important symbol lists. Just a thought.

On 21/11/23 15:00, Anders Broman wrote:

Hi,
I found it useful to be able to do Debian packages
easily to provide internal installation packages and
even ppa for Ubuntu.
So I have been using the Debian build system.
Best regards
Anders

Den tis 21 nov. 2023 15:48Roland Knall
skrev:

As mentioned on the ticket - just putting it here as
well - I am against dropping packaging/debian. But I
am for having it underneath packaging, and not in
the main directory, which is what the original
change was about. I respect Joao's opinion as well
as yours Balint. In this case here I think, we can
provide assistance for future implementors and as a
starting point, by keeping the directory underneath
packaging/debian.

just my thoughts
Roland

Am Di., 21. Nov. 2023 um 15:28 Uhr schrieb Bálint
Réczey :

Hi All,

João shared his opinion about the project's
commitment to maintain the
packaging/debian/ in the project's repository:

https://gitlab.com/wireshark/wireshark/-/commit/79da670bd1b4f91eebee5c96b19eaf1f33c94777#note_1656501952

I believe the current practice is reasonable and
beneficial enough for
many parties to warrant the work, but I could be
wrong.

Probably the most important question is if

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository



On 22/11/23 13:29, Pascal Quantin wrote:



Le mer. 22 nov. 2023 à 14:25, João Valverde  a écrit :


On 22/11/23 13:12, Pascal Quantin wrote:

Hi Joao,

Le mer. 22 nov. 2023 à 14:01, João Valverde  a écrit :

You are free to participate in the discussion or not. But I
really don't care to wait for the new committee that is
pretty much exactly the same as the old committee, as far as
I can tell.

Anyway silence is another Wireshark project classic. At least
you tried to bring something to the debate, so thank you for
that, at least.


It seems like the discussion is shifting away from the initial
goal. I don't think aggression/criticism/sarcasm brings anything
to the debate, so I would prefer to keep a constructive exchange
between whoever feels involved in the subject. I personally have
never used the Debian scripts, but I did not consider updating
the symbols list as being a really time consuming task (and I did
it numerous times in the past), so I do not have an opinion on
whether the current status quo is good or bad.
Balint's initial email was to collect some feedback regarding
whether the scripts are being used or not. Anders provided the
first feedback, let's see if others do (with the hope that they
are monitoring this list...).


I'm not being aggressive, I'm being candid. And also expressing
some pretty valid (IMO) criticisms.

And let the discussion shift, what about it? I think it's all
relevant to the issue of Debian packaging.


Well that's all about communication. I personally find the emails you 
are sending today as being more and more aggressive. Maybe that's just 
me, or maybe this is the language / cultural differences, but I think 
it was worth notifying you as you might not be aware of how others can 
react to what you are writing.


I apologize if the sarcasm in the committee line caused offense. I 
should have phrased that more gently.




Best regards.

___
Sent via:Wireshark-dev mailing list
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe:https://www.wireshark.org/mailman/options/wireshark-dev
  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

2023-11-22 Thread Pascal Quantin

Le mer. 22 nov. 2023 à 14:25, João Valverde  a écrit :

>
> On 22/11/23 13:12, Pascal Quantin wrote:
>
> Hi Joao,
>
> Le mer. 22 nov. 2023 à 14:01, João Valverde  a écrit :
>
>> You are free to participate in the discussion or not. But I really don't
>> care to wait for the new committee that is pretty much exactly the same as
>> the old committee, as far as I can tell.
>>
>> Anyway silence is another Wireshark project classic. At least you tried
>> to bring something to the debate, so thank you for that, at least.
>>
>
> It seems like the discussion is shifting away from the initial goal. I
> don't think aggression/criticism/sarcasm brings anything to the debate, so
> I would prefer to keep a constructive exchange between whoever feels
> involved in the subject. I personally have never used the Debian scripts,
> but I did not consider updating the symbols list as being a really time
> consuming task (and I did it numerous times in the past), so I do not have
> an opinion on whether the current status quo is good or bad.
> Balint's initial email was to collect some feedback regarding whether the
> scripts are being used or not. Anders provided the first feedback, let's
> see if others do (with the hope that they are monitoring this list...).
>
>
> I'm not being aggressive, I'm being candid. And also expressing some
> pretty valid (IMO) criticisms.
>
And let the discussion shift, what about it? I think it's all relevant to
> the issue of Debian packaging.
>

Well that's all about communication. I personally find the emails you are
sending today as being more and more aggressive. Maybe that's just me, or
maybe this is the language / cultural differences, but I think it was worth
notifying you as you might not be aware of how others can react to what you
are writing.

Best regards.
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

On 22/11/23 13:12, Pascal Quantin wrote:

Hi Joao,

Le mer. 22 nov. 2023 à 14:01, João Valverde a écrit :

You are free to participate in the discussion or not. But I really
don't care to wait for the new committee that is pretty much
exactly the same as the old committee, as far as I can tell.

Anyway silence is another Wireshark project classic. At least you
tried to bring something to the debate, so thank you for that, at
least.

I'm not being aggressive, I'm being candid. And also expressing some
pretty valid (IMO) criticisms.

And let the discussion shift, what about it? I think it's all relevant
to the issue of Debian packaging.

Best regards,
Pascal.

On 22/11/23 11:45, Roland Knall wrote:

I would recommend that we bring this topic before the technical
steering committee. As of right now, that committee needs to be
formed in January and this topic is exactly why we are going to
have the committee in the first place. The process is in the
final steps and should be finished by the end of the year anyway.

I do not think that further discussing this issue is actually
beneficial for the long term resolution of this situation. Both
sides have valid arguments and good pointers and I would suggest
as soon as the committee has taken up the topic we collectively
create a single mission statement as suggested by Joao above.
Until then, personally I will refrain from discussing this
further, as I have said everything there is to say from
my perspective.

Do you agree Gerald?

kind regards
Roland

Am Mi., 22. Nov. 2023 um 12:36 Uhr schrieb João Valverde :

Maybe you´d like to volunteer to maintain the Wireshark
Debian assets? Since you've got the experience and actually
use it?

There are loads of lintian warnings waiting to be fixed, or
there were until recently. Maybe you'd like to start there,
and be more active staying on top of the all-important symbol
lists. Just a thought.

On 21/11/23 15:00, Anders Broman wrote:

Hi,
I found it useful to be able to do Debian packages easily to
provide internal installation packages and even ppa for Ubuntu.
So I have been using the Debian build system.
Best regards
Anders

Den tis 21 nov. 2023 15:48Roland Knall skrev:

As mentioned on the ticket - just putting it here as
well - I am against dropping packaging/debian. But I am
for having it underneath packaging, and not in the main
directory, which is what the original change was about.
I respect Joao's opinion as well as yours Balint. In
this case here I think, we can provide assistance for
future implementors and as a starting point, by keeping
the directory underneath packaging/debian.

just my thoughts
Roland

Am Di., 21. Nov. 2023 um 15:28 Uhr schrieb Bálint Réczey
:

Hi All,

João shared his opinion about the project's
commitment to maintain the
packaging/debian/ in the project's repository:

https://gitlab.com/wireshark/wireshark/-/commit/79da670bd1b4f91eebee5c96b19eaf1f33c94777#note_1656501952

I believe the current practice is reasonable and
beneficial enough for
many parties to warrant the work, but I could be wrong.

Probably the most important question is if there is
anyone relying on
the packaging scripts there. If you are, please
speak up otherwise the
directory may be dropped.

Comments are welcome.

Cheers,
Balint

___
Sent via: Wireshark-dev mailing list

Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe:
https://www.wireshark.org/mailman/options/wireshark-dev

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

2023-11-22 Thread Martin Mathieson via Wireshark-dev

Pretty sure I'm not adding anything useful here, but I was only vaguely
aware of debian packaging support.  If I'm sharing builds with colleagues,
I use Windows packaging, or for Ubuntu we tend to set CMAKE_INSTALL_PREFIX,
build the 'install' target and transfer it as a tarball.

On Wed, Nov 22, 2023 at 1:12 PM Pascal Quantin  wrote:

> Hi Joao,
>
> Le mer. 22 nov. 2023 à 14:01, João Valverde  a écrit :
>
>> You are free to participate in the discussion or not. But I really don't
>> care to wait for the new committee that is pretty much exactly the same as
>> the old committee, as far as I can tell.
>>
>> Anyway silence is another Wireshark project classic. At least you tried
>> to bring something to the debate, so thank you for that, at least.
>>
>
> It seems like the discussion is shifting away from the initial goal. I
> don't think aggression/criticism/sarcasm brings anything to the debate, so
> I would prefer to keep a constructive exchange between whoever feels
> involved in the subject. I personally have never used the Debian scripts,
> but I did not consider updating the symbols list as being a really time
> consuming task (and I did it numerous times in the past), so I do not have
> an opinion on whether the current status quo is good or bad.
> Balint's initial email was to collect some feedback regarding whether the
> scripts are being used or not. Anders provided the first feedback, let's
> see if others do (with the hope that they are monitoring this list...).
>
> Best regards,
> Pascal.
>
>
>> On 22/11/23 11:45, Roland Knall wrote:
>>
>> Hi
>>
>> I would recommend that we bring this topic before the technical steering
>> committee. As of right now, that committee needs to be formed in
>> January and this topic is exactly why we are going to have the committee in
>> the first place. The process is in the final steps and should be finished
>> by the end of the year anyway.
>>
>> I do not think that further discussing this issue is actually beneficial
>> for the long term resolution of this situation. Both sides have valid
>> arguments and good pointers and I would suggest as soon as the committee
>> has taken up the topic we collectively create a single mission statement as
>> suggested by Joao above. Until then, personally I will refrain from
>> discussing this further, as I have said everything there is to say from
>> my perspective.
>>
>> Do you agree Gerald?
>>
>> kind regards
>> Roland
>>
>>
>>
>> Am Mi., 22. Nov. 2023 um 12:36 Uhr schrieb João Valverde :
>>
>>> Maybe you´d like to volunteer to maintain the Wireshark Debian assets?
>>> Since you've got the experience and actually use it?
>>>
>>> There are loads of lintian warnings waiting to be fixed, or there were
>>> until recently. Maybe you'd like to start there, and be more active staying
>>> on top of the all-important symbol lists. Just a thought.
>>>
>>> On 21/11/23 15:00, Anders Broman wrote:
>>>
>>> Hi,
>>> I found it useful to be able to do Debian packages easily to provide
>>> internal installation packages and even ppa for Ubuntu.
>>> So I have been using the Debian build system.
>>> Best regards
>>> Anders
>>>
>>> Den tis 21 nov. 2023 15:48Roland Knall  skrev:
>>>
 As mentioned on the ticket - just putting it here as well - I am
 against dropping packaging/debian. But I am for having it underneath
 packaging, and not in the main directory, which is what the original change
 was about. I respect Joao's opinion as well as yours Balint. In this case
 here I think, we can provide assistance for future implementors and as a
 starting point, by keeping the directory underneath packaging/debian.

 just my thoughts
 Roland


 Am Di., 21. Nov. 2023 um 15:28 Uhr schrieb Bálint Réczey <
 bal...@balintreczey.hu>:

> Hi All,
>
> João shared his opinion about the project's commitment to maintain the
> packaging/debian/ in the project's repository:
>
>
> https://gitlab.com/wireshark/wireshark/-/commit/79da670bd1b4f91eebee5c96b19eaf1f33c94777#note_1656501952
>
> I believe the current practice is reasonable and beneficial enough for
> many parties to warrant the work, but I could be wrong.
>
> Probably the most important question is if there is anyone relying on
> the packaging scripts there. If you are, please speak up otherwise the
> directory may be dropped.
>
> Comments are welcome.
>
> Cheers,
> Balint
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
>

 ___
 Sent via:Wireshark-dev mailing list 
 Archives:

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

So you want to discuss how to make it easier? We can do that. How do you
feel about the CPack Debian Generator?

On 22/11/23 12:38, Anders Broman wrote:

Hi,
I think that if you look at the commit history I have made my fair
share of updating the list in the past.

I was just trying to make the point that some found it useful to be
able to build Deb packages and it might be more fruitful to discuss
how that could be made easier? I think today the script tells you what
symbols are missing perhaps it could just update the list, as an example.

Best regards
Anders

Den ons 22 nov. 2023 12:36João Valverde skrev:

Maybe you´d like to volunteer to maintain the Wireshark Debian
assets? Since you've got the experience and actually use it?

On 21/11/23 15:00, Anders Broman wrote:

Hi,
I found it useful to be able to do Debian packages easily to
provide internal installation packages and even ppa for Ubuntu.
So I have been using the Debian build system.
Best regards
Anders

Den tis 21 nov. 2023 15:48Roland Knall skrev:

As mentioned on the ticket - just putting it here as well - I
am against dropping packaging/debian. But I am for having it
underneath packaging, and not in the main directory, which is
what the original change was about. I respect Joao's opinion
as well as yours Balint. In this case here I think, we can
provide assistance for future implementors and as a starting
point, by keeping the directory underneath packaging/debian.

just my thoughts
Roland

Am Di., 21. Nov. 2023 um 15:28 Uhr schrieb Bálint Réczey
:

Hi All,

João shared his opinion about the project's commitment to
maintain the
packaging/debian/ in the project's repository:

https://gitlab.com/wireshark/wireshark/-/commit/79da670bd1b4f91eebee5c96b19eaf1f33c94777#note_1656501952

I believe the current practice is reasonable and
beneficial enough for
many parties to warrant the work, but I could be wrong.

Probably the most important question is if there is
anyone relying on
the packaging scripts there. If you are, please speak up
otherwise the
directory may be dropped.

Comments are welcome.

Cheers,
Balint

___
Sent via: Wireshark-dev mailing list

Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe:
https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

___
Sent via: Wireshark-dev mailing list

Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe:
https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

___
Sent via:Wireshark-dev mailing list

Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe:https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

___
Sent via:Wireshark-dev mailing list
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe:https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

2023-11-22 Thread Pascal Quantin

Hi Joao,

Le mer. 22 nov. 2023 à 14:01, João Valverde  a écrit :

> You are free to participate in the discussion or not. But I really don't
> care to wait for the new committee that is pretty much exactly the same as
> the old committee, as far as I can tell.
>
> Anyway silence is another Wireshark project classic. At least you tried to
> bring something to the debate, so thank you for that, at least.
>

It seems like the discussion is shifting away from the initial goal. I
don't think aggression/criticism/sarcasm brings anything to the debate, so
I would prefer to keep a constructive exchange between whoever feels
involved in the subject. I personally have never used the Debian scripts,
but I did not consider updating the symbols list as being a really time
consuming task (and I did it numerous times in the past), so I do not have
an opinion on whether the current status quo is good or bad.
Balint's initial email was to collect some feedback regarding whether the
scripts are being used or not. Anders provided the first feedback, let's
see if others do (with the hope that they are monitoring this list...).

Best regards,
Pascal.


> On 22/11/23 11:45, Roland Knall wrote:
>
> Hi
>
> I would recommend that we bring this topic before the technical steering
> committee. As of right now, that committee needs to be formed in
> January and this topic is exactly why we are going to have the committee in
> the first place. The process is in the final steps and should be finished
> by the end of the year anyway.
>
> I do not think that further discussing this issue is actually beneficial
> for the long term resolution of this situation. Both sides have valid
> arguments and good pointers and I would suggest as soon as the committee
> has taken up the topic we collectively create a single mission statement as
> suggested by Joao above. Until then, personally I will refrain from
> discussing this further, as I have said everything there is to say from
> my perspective.
>
> Do you agree Gerald?
>
> kind regards
> Roland
>
>
>
> Am Mi., 22. Nov. 2023 um 12:36 Uhr schrieb João Valverde :
>
>> Maybe you´d like to volunteer to maintain the Wireshark Debian assets?
>> Since you've got the experience and actually use it?
>>
>> There are loads of lintian warnings waiting to be fixed, or there were
>> until recently. Maybe you'd like to start there, and be more active staying
>> on top of the all-important symbol lists. Just a thought.
>>
>> On 21/11/23 15:00, Anders Broman wrote:
>>
>> Hi,
>> I found it useful to be able to do Debian packages easily to provide
>> internal installation packages and even ppa for Ubuntu.
>> So I have been using the Debian build system.
>> Best regards
>> Anders
>>
>> Den tis 21 nov. 2023 15:48Roland Knall  skrev:
>>
>>> As mentioned on the ticket - just putting it here as well - I am against
>>> dropping packaging/debian. But I am for having it underneath packaging, and
>>> not in the main directory, which is what the original change was about. I
>>> respect Joao's opinion as well as yours Balint. In this case here I think,
>>> we can provide assistance for future implementors and as a starting point,
>>> by keeping the directory underneath packaging/debian.
>>>
>>> just my thoughts
>>> Roland
>>>
>>>
>>> Am Di., 21. Nov. 2023 um 15:28 Uhr schrieb Bálint Réczey <
>>> bal...@balintreczey.hu>:
>>>
 Hi All,

 João shared his opinion about the project's commitment to maintain the
 packaging/debian/ in the project's repository:


 https://gitlab.com/wireshark/wireshark/-/commit/79da670bd1b4f91eebee5c96b19eaf1f33c94777#note_1656501952

 I believe the current practice is reasonable and beneficial enough for
 many parties to warrant the work, but I could be wrong.

 Probably the most important question is if there is anyone relying on
 the packaging scripts there. If you are, please speak up otherwise the
 directory may be dropped.

 Comments are welcome.

 Cheers,
 Balint

 ___
 Sent via:Wireshark-dev mailing list 
 Archives:https://www.wireshark.org/lists/wireshark-dev
 Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
  mailto:wireshark-dev-requ...@wireshark.org
 ?subject=unsubscribe

>>>
>>> ___
>>> Sent via:Wireshark-dev mailing list 
>>> Archives:https://www.wireshark.org/lists/wireshark-dev
>>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>>>  mailto:wireshark-dev-requ...@wireshark.org
>>> ?subject=unsubscribe
>>>
>>
>> ___
>> Sent via:Wireshark-dev mailing list  
>> 
>> Archives:https://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe:

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

You are free to participate in the discussion or not. But I really don't
care to wait for the new committee that is pretty much exactly the same
as the old committee, as far as I can tell.

Anyway silence is another Wireshark project classic. At least you tried
to bring something to the debate, so thank you for that, at least.

On 22/11/23 11:45, Roland Knall wrote:

I would recommend that we bring this topic before the technical
steering committee. As of right now, that committee needs to be formed
in January and this topic is exactly why we are going to have the
committee in the first place. The process is in the final steps and
should be finished by the end of the year anyway.

I do not think that further discussing this issue is actually
beneficial for the long term resolution of this situation. Both sides
have valid arguments and good pointers and I would suggest as soon as
the committee has taken up the topic we collectively create a single
mission statement as suggested by Joao above. Until then, personally I
will refrain from discussing this further, as I have said everything
there is to say from my perspective.

Do you agree Gerald?

kind regards
Roland

Am Mi., 22. Nov. 2023 um 12:36 Uhr schrieb João Valverde :

Maybe you´d like to volunteer to maintain the Wireshark Debian
assets? Since you've got the experience and actually use it?

On 21/11/23 15:00, Anders Broman wrote:

Hi,
I found it useful to be able to do Debian packages easily to
provide internal installation packages and even ppa for Ubuntu.
So I have been using the Debian build system.
Best regards
Anders

Den tis 21 nov. 2023 15:48Roland Knall skrev:

As mentioned on the ticket - just putting it here as well - I
am against dropping packaging/debian. But I am for having it
underneath packaging, and not in the main directory, which is
what the original change was about. I respect Joao's opinion
as well as yours Balint. In this case here I think, we can
provide assistance for future implementors and as a starting
point, by keeping the directory underneath packaging/debian.

just my thoughts
Roland

Am Di., 21. Nov. 2023 um 15:28 Uhr schrieb Bálint Réczey
:

Hi All,

João shared his opinion about the project's commitment to
maintain the
packaging/debian/ in the project's repository:

https://gitlab.com/wireshark/wireshark/-/commit/79da670bd1b4f91eebee5c96b19eaf1f33c94777#note_1656501952

I believe the current practice is reasonable and
beneficial enough for
many parties to warrant the work, but I could be wrong.

Probably the most important question is if there is
anyone relying on
the packaging scripts there. If you are, please speak up
otherwise the
directory may be dropped.

Comments are welcome.

Cheers,
Balint

___
Sent via: Wireshark-dev mailing list

Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe:
https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

___
Sent via: Wireshark-dev mailing list

Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe:
https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

___
Sent via:Wireshark-dev mailing list

Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe:https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

___
Sent via:Wireshark-dev

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

2023-11-22 Thread Anders Broman

Hi,
I think that if you look at the commit history I have made my fair share of
updating the list in the past.

I was just trying to make the point that some found it useful to be able to
build Deb packages and it might be more fruitful to discuss how that could
be made easier? I think today the script tells you what symbols are missing
perhaps it could just update the list, as an example.
Best regards
Anders

Den ons 22 nov. 2023 12:36João Valverde  skrev:

> Maybe you´d like to volunteer to maintain the Wireshark Debian assets?
> Since you've got the experience and actually use it?
>
> There are loads of lintian warnings waiting to be fixed, or there were
> until recently. Maybe you'd like to start there, and be more active staying
> on top of the all-important symbol lists. Just a thought.
>
> On 21/11/23 15:00, Anders Broman wrote:
>
> Hi,
> I found it useful to be able to do Debian packages easily to provide
> internal installation packages and even ppa for Ubuntu.
> So I have been using the Debian build system.
> Best regards
> Anders
>
> Den tis 21 nov. 2023 15:48Roland Knall  skrev:
>
>> As mentioned on the ticket - just putting it here as well - I am against
>> dropping packaging/debian. But I am for having it underneath packaging, and
>> not in the main directory, which is what the original change was about. I
>> respect Joao's opinion as well as yours Balint. In this case here I think,
>> we can provide assistance for future implementors and as a starting point,
>> by keeping the directory underneath packaging/debian.
>>
>> just my thoughts
>> Roland
>>
>>
>> Am Di., 21. Nov. 2023 um 15:28 Uhr schrieb Bálint Réczey <
>> bal...@balintreczey.hu>:
>>
>>> Hi All,
>>>
>>> João shared his opinion about the project's commitment to maintain the
>>> packaging/debian/ in the project's repository:
>>>
>>>
>>> https://gitlab.com/wireshark/wireshark/-/commit/79da670bd1b4f91eebee5c96b19eaf1f33c94777#note_1656501952
>>>
>>> I believe the current practice is reasonable and beneficial enough for
>>> many parties to warrant the work, but I could be wrong.
>>>
>>> Probably the most important question is if there is anyone relying on
>>> the packaging scripts there. If you are, please speak up otherwise the
>>> directory may be dropped.
>>>
>>> Comments are welcome.
>>>
>>> Cheers,
>>> Balint
>>>
>>> ___
>>> Sent via:Wireshark-dev mailing list 
>>> Archives:https://www.wireshark.org/lists/wireshark-dev
>>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>>>  mailto:wireshark-dev-requ...@wireshark.org
>>> ?subject=unsubscribe
>>>
>>
>> ___
>> Sent via:Wireshark-dev mailing list 
>> Archives:https://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>>  mailto:wireshark-dev-requ...@wireshark.org
>> ?subject=unsubscribe
>>
>
> ___
> Sent via:Wireshark-dev mailing list  
> 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe 
> 
>
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
>
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

2023-11-22 Thread Roland Knall

Hi

I would recommend that we bring this topic before the technical steering
committee. As of right now, that committee needs to be formed in
January and this topic is exactly why we are going to have the committee in
the first place. The process is in the final steps and should be finished
by the end of the year anyway.

I do not think that further discussing this issue is actually beneficial
for the long term resolution of this situation. Both sides have valid
arguments and good pointers and I would suggest as soon as the committee
has taken up the topic we collectively create a single mission statement as
suggested by Joao above. Until then, personally I will refrain from
discussing this further, as I have said everything there is to say from
my perspective.

Do you agree Gerald?

kind regards
Roland



Am Mi., 22. Nov. 2023 um 12:36 Uhr schrieb João Valverde :

> Maybe you´d like to volunteer to maintain the Wireshark Debian assets?
> Since you've got the experience and actually use it?
>
> There are loads of lintian warnings waiting to be fixed, or there were
> until recently. Maybe you'd like to start there, and be more active staying
> on top of the all-important symbol lists. Just a thought.
>
> On 21/11/23 15:00, Anders Broman wrote:
>
> Hi,
> I found it useful to be able to do Debian packages easily to provide
> internal installation packages and even ppa for Ubuntu.
> So I have been using the Debian build system.
> Best regards
> Anders
>
> Den tis 21 nov. 2023 15:48Roland Knall  skrev:
>
>> As mentioned on the ticket - just putting it here as well - I am against
>> dropping packaging/debian. But I am for having it underneath packaging, and
>> not in the main directory, which is what the original change was about. I
>> respect Joao's opinion as well as yours Balint. In this case here I think,
>> we can provide assistance for future implementors and as a starting point,
>> by keeping the directory underneath packaging/debian.
>>
>> just my thoughts
>> Roland
>>
>>
>> Am Di., 21. Nov. 2023 um 15:28 Uhr schrieb Bálint Réczey <
>> bal...@balintreczey.hu>:
>>
>>> Hi All,
>>>
>>> João shared his opinion about the project's commitment to maintain the
>>> packaging/debian/ in the project's repository:
>>>
>>>
>>> https://gitlab.com/wireshark/wireshark/-/commit/79da670bd1b4f91eebee5c96b19eaf1f33c94777#note_1656501952
>>>
>>> I believe the current practice is reasonable and beneficial enough for
>>> many parties to warrant the work, but I could be wrong.
>>>
>>> Probably the most important question is if there is anyone relying on
>>> the packaging scripts there. If you are, please speak up otherwise the
>>> directory may be dropped.
>>>
>>> Comments are welcome.
>>>
>>> Cheers,
>>> Balint
>>>
>>> ___
>>> Sent via:Wireshark-dev mailing list 
>>> Archives:https://www.wireshark.org/lists/wireshark-dev
>>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>>>  mailto:wireshark-dev-requ...@wireshark.org
>>> ?subject=unsubscribe
>>>
>>
>> ___
>> Sent via:Wireshark-dev mailing list 
>> Archives:https://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>>  mailto:wireshark-dev-requ...@wireshark.org
>> ?subject=unsubscribe
>>
>
> ___
> Sent via:Wireshark-dev mailing list  
> 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe 
> 
>
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
>
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

Maybe you´d like to volunteer to maintain the Wireshark Debian assets?
Since you've got the experience and actually use it?

There are loads of lintian warnings waiting to be fixed, or there were
until recently. Maybe you'd like to start there, and be more active
staying on top of the all-important symbol lists. Just a thought.

On 21/11/23 15:00, Anders Broman wrote:

Hi,
I found it useful to be able to do Debian packages easily to provide
internal installation packages and even ppa for Ubuntu.

So I have been using the Debian build system.
Best regards
Anders

Den tis 21 nov. 2023 15:48Roland Knall skrev:

As mentioned on the ticket - just putting it here as well - I am
against dropping packaging/debian. But I am for having it
underneath packaging, and not in the main directory, which is what
the original change was about. I respect Joao's opinion as well as
yours Balint. In this case here I think, we can provide assistance
for future implementors and as a starting point, by keeping the
directory underneath packaging/debian.

just my thoughts
Roland

Am Di., 21. Nov. 2023 um 15:28 Uhr schrieb Bálint Réczey
:

Hi All,

João shared his opinion about the project's commitment to
maintain the
packaging/debian/ in the project's repository:

https://gitlab.com/wireshark/wireshark/-/commit/79da670bd1b4f91eebee5c96b19eaf1f33c94777#note_1656501952

I believe the current practice is reasonable and beneficial
enough for
many parties to warrant the work, but I could be wrong.

Probably the most important question is if there is anyone
relying on
the packaging scripts there. If you are, please speak up
otherwise the
directory may be dropped.

Comments are welcome.

Cheers,
Balint

___
Sent via: Wireshark-dev mailing list

Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe:
https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository