gptfdisk: add follow-up patch to fix with current popt

sgdisk still segfaults for some tasks (e.g 'sgdisk -v', 'sgdisk -V')

Add a follow-up patch that fixes the issue. It was taken from Archlinux

Signed-off-by: Markus Volk <f_l_k@t-online.de>
---
 .../fdisk/gptfdisk/popt-1.19-follow-up.patch  | 42 +++++++++++++++++++
 meta/recipes-devtools/fdisk/gptfdisk_1.0.9.bb |  1 +
 2 files changed, 43 insertions(+)
 create mode 100644 meta/recipes-devtools/fdisk/gptfdisk/popt-1.19-follow-up.patch

It’s not a backport as source comes from source forge. Please check other
patches to see the upstream situation and correct the status.

Alex

On Thu 19. Jan 2023 at 14.20, Markus Volk <f_l_k@t-online.de> wrote:

> sgdisk still segfaults for some tasks (e.g 'sgdisk -v', 'sgdisk -V')
>
> Add a follow-up patch that fixes the issue. It was taken from Archlinux
>
> Signed-off-by: Markus Volk <f_l_k@t-online.de>
> ---
>  .../fdisk/gptfdisk/popt-1.19-follow-up.patch  | 42 +++++++++++++++++++
>  meta/recipes-devtools/fdisk/gptfdisk_1.0.9.bb |  1 +
>  2 files changed, 43 insertions(+)
>  create mode 100644
> meta/recipes-devtools/fdisk/gptfdisk/popt-1.19-follow-up.patch
>
> diff --git
> a/meta/recipes-devtools/fdisk/gptfdisk/popt-1.19-follow-up.patch
> b/meta/recipes-devtools/fdisk/gptfdisk/popt-1.19-follow-up.patch
> new file mode 100644
> index 0000000000..a5ccd2385a
> --- /dev/null
> +++ b/meta/recipes-devtools/fdisk/gptfdisk/popt-1.19-follow-up.patch
> @@ -0,0 +1,42 @@
> +From f5de3401b974ce103ffd93af8f9d43505a04aaf9 Mon Sep 17 00:00:00 2001
> +From: Damian Kurek <starfire24680@gmail.com>
> +Date: Thu, 7 Jul 2022 03:39:16 +0000
> +Subject: [PATCH] Fix NULL dereference when duplicating string argument
> +
> +poptGetArg can return NULL if there are no additional arguments, which
> +makes strdup dereference NULL on strlen
> +
> +Upstream-Status: Backport [
> https://github.com/archlinux/svntogit-packages/tree/packages/gptfdisk/trunk
> ]
> +
> +Unsure if this patch is really a backport yet. It was taken from Archlinux
> +---
> + gptcl.cc | 6 ++++--
> + 1 file changed, 4 insertions(+), 2 deletions(-)
> +
> +diff --git a/gptcl.cc b/gptcl.cc
> +index 0d578eb..ab95239 100644
> +--- a/gptcl.cc
> ++++ b/gptcl.cc
> +@@ -155,10 +155,11 @@ int GPTDataCL::DoOptions(int argc, char* argv[]) {
> +    } // while
> +
> +    // Assume first non-option argument is the device filename....
> +-   device = strdup((char*) poptGetArg(poptCon));
> +-   poptResetContext(poptCon);
> ++   device = (char*) poptGetArg(poptCon);
> +
> +    if (device != NULL) {
> ++      device = strdup(device);
> ++      poptResetContext(poptCon);
> +       JustLooking(); // reset as necessary
> +       BeQuiet(); // Tell called functions to be less verbose &
> interactive
> +       if (LoadPartitions((string) device)) {
> +@@ -498,6 +499,7 @@ int GPTDataCL::DoOptions(int argc, char* argv[]) {
> +          cerr << "Error encountered; not saving changes.\n";
> +          retval = 4;
> +       } // if
> ++      free(device);
> +    } // if (device != NULL)
> +    poptFreeContext(poptCon);
> +    return retval;
> +
> diff --git a/meta/recipes-devtools/fdisk/gptfdisk_1.0.9.bb
> b/meta/recipes-devtools/fdisk/gptfdisk_1.0.9.bb
> index 66935b7fbb..cf0a60a1a9 100644
> --- a/meta/recipes-devtools/fdisk/gptfdisk_1.0.9.bb
> +++ b/meta/recipes-devtools/fdisk/gptfdisk_1.0.9.bb
> @@ -12,6 +12,7 @@ SRC_URI =
> "${SOURCEFORGE_MIRROR}/${BPN}/${PV}/${BP}.tar.gz \
>
> file://0001-Updated-guid.cc-to-deal-with-minor-change-in-libuuid.patch \
>
> file://0001-Fix-failure-crash-of-sgdisk-when-compiled-with-lates.patch \
>             file://0001-Use-64bit-time_t-on-linux-as-well.patch \
> +           file://popt-1.19-follow-up.patch \
>             "
>  SRC_URI[sha256sum] =
> "dafead2693faeb8e8b97832b23407f6ed5b3219bc1784f482dd855774e2d50c2"
>
> --
> 2.34.1
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#176138):
> https://lists.openembedded.org/g/openembedded-core/message/176138
> Mute This Topic: https://lists.openembedded.org/mt/96376633/1686489
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [
> alex.kanavin@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>

Am Do, 19. Jan 2023 um 16:14:58 +0100 schrieb Alexander Kanavin 
<alex.kanavin@gmail.com>:
> ck other patches to see the upstream situation and correct the status.

Then i guess the correct status would be pending ?

No. If it can be submitted upstream, then you should do so.

Alex

On Thu 19. Jan 2023 at 16.16, Markus Volk <f_l_k@t-online.de> wrote:

> Am Do, 19. Jan 2023 um 16:14:58 +0100 schrieb Alexander Kanavin <
> alex.kanavin@gmail.com>:
>
> ck other patches to see the upstream situation and correct the status.
>
>
> Then i guess the correct status would be pending ?
>

Am Do, 19. Jan 2023 um 16:14:58 +0100 schrieb Alexander Kanavin 
<alex.kanavin@gmail.com>:
> ck other patches to see the upstream situation and correct the status.

But its neither my patch nor am I familiar with sourceforge or the 
actual issue with popt ... and I'm not keen on changing that. I think 
if the gptfdisk maintainer wants to release a new version, he will be 
able to find the patch on the net like I was.

And if he wants to get more help from the community it would be a good 
idea to have a git repo available somewhere. Or am I missing something 
and just wasn't able to find it?

On Thu, 19 Jan 2023 at 16:27, Markus Volk <f_l_k@t-online.de> wrote:
> But its neither my patch nor am I familiar with sourceforge or the actual issue with popt ... and I'm not keen on changing that. I think if the gptfdisk maintainer wants to release a new version, he will be able to find the patch on the net like I was.
>
> And if he wants to get more help from the community it would be a good idea to have a git repo available somewhere. Or am I missing something and just wasn't able to find it?

The git repo is in fact on sourceforge:
https://sourceforge.net/p/gptfdisk/code/ci/master/tree/
and you can open a merge request there. There's one from Khem for example.

Please do not come up with reasons to push this work (submitting
patches upstream) on me; I do not appreciate that.

Alex

I don't want to push this work to you. Just wanted to give a reason, 
why I'd rather dont like to do myself, at least for the next days. Have 
still plenty of work lying here and in fact I do this only for fun and 
thats what it still needs to be to give me reason. I'm not related to 
technical things for a living. It's just, that I had an issue with 
gnome-disks and as a side effect I realized that sgdisk has an issue as 
well and found a fix for it.
But if thats not appropriate like this, just drop that commit for now. 
Will send a v2 when I've been digging into it enough, to have the 
feeling that I am halfway knowing what I talk about, if sending a merge 
request for a patch I didn't create.


Am Do, 19. Jan 2023 um 18:10:05 +0100 schrieb Alexander Kanavin 
<alex.kanavin@gmail.com>:
> On Thu, 19 Jan 2023 at 16:27, Markus Volk <f_l_k@t-online.de 
> <mailto:f_l_k@t-online.de>> wrote:
>>  But its neither my patch nor am I familiar with sourceforge or the 
>> actual issue with popt ... and I'm not keen on changing that. I 
>> think if the gptfdisk maintainer wants to release a new version, he 
>> will be able to find the patch on the net like I was.
>> 
>>  And if he wants to get more help from the community it would be a 
>> good idea to have a git repo available somewhere. Or am I missing 
>> something and just wasn't able to find it?
> 
> The git repo is in fact on sourceforge:
> <https://sourceforge.net/p/gptfdisk/code/ci/master/tree/>
> and you can open a merge request there. There's one from Khem for 
> example.
> 
> Please do not come up with reasons to push this work (submitting
> patches upstream) on me; I do not appreciate that.
> 
> Alex

I sent oe-core patches upstream that aren't mine all the time.
Sometimes I as well don't even understand them fully, and then I have
upstream explain to me what's wrong with it or why is it not
appropriate or poorly written. Or they rework it themselves. The
primary goal is to engage the upstream and make them aware, and no one
expects you to produce a perfect patch and complete understanding of
the issue in your head up-front.

My request is simply to go through the not-too-hard technicality of
sending the patch via opening a merge request, so that there is an
link for it that can be followed up later by you, or by someone else.
Later can be measured in weeks or months, and often is.

Alex

On Thu, 19 Jan 2023 at 18:22, Markus Volk <f_l_k@t-online.de> wrote:
>
> I don't want to push this work to you. Just wanted to give a reason, why I'd rather dont like to do myself, at least for the next days. Have still plenty of work lying here and in fact I do this only for fun and thats what it still needs to be to give me reason. I'm not related to technical things for a living. It's just, that I had an issue with gnome-disks and as a side effect I realized that sgdisk has an issue as well and found a fix for it.
> But if thats not appropriate like this, just drop that commit for now. Will send a v2 when I've been digging into it enough, to have the feeling that I am halfway knowing what I talk about, if sending a merge request for a patch I didn't create.
>
>
> Am Do, 19. Jan 2023 um 18:10:05 +0100 schrieb Alexander Kanavin <alex.kanavin@gmail.com>:
>
> On Thu, 19 Jan 2023 at 16:27, Markus Volk <f_l_k@t-online.de> wrote:
>
> But its neither my patch nor am I familiar with sourceforge or the actual issue with popt ... and I'm not keen on changing that. I think if the gptfdisk maintainer wants to release a new version, he will be able to find the patch on the net like I was. And if he wants to get more help from the community it would be a good idea to have a git repo available somewhere. Or am I missing something and just wasn't able to find it?
>
> The git repo is in fact on sourceforge: https://sourceforge.net/p/gptfdisk/code/ci/master/tree/ and you can open a merge request there. There's one from Khem for example. Please do not come up with reasons to push this work (submitting patches upstream) on me; I do not appreciate that. Alex

Am Do, 19. Jan 2023 um 18:33:35 +0100 schrieb Alexander Kanavin 
<alex.kanavin@gmail.com>:
> no one
> expects you to produce a perfect patch and complete understanding of
> the issue in your head up-front.

I really didn't find the git repository and thought they were still 
using subversion. But I have to admit that I didn't search thoroughly. 
When I see code still hosted on Sourceforge, I'm automatically a bit 
skeptical.  It's not hard to do merge requests, but I really prefer to 
know something before I do it. And it's of course also a bit of a 
hassle.
The only thing I know for now is that it fixes a segfault, thats what I 
at least have tested. So it looks like an improvement.

But now that I have a git repo, I guess I lack the excuse ;)

Am Do, 19. Jan 2023 um 16:14:58 +0100 schrieb Alexander Kanavin 
<alex.kanavin@gmail.com>:
> It’s not a backport as source comes from source forge.

After registering on sourceforge, I found out that the original author 
had submitted this patch about half a year ago without receiving any 
comment so far. This reinforces my prejudice against code that is still 
hosted there.

<https://sourceforge.net/p/gptfdisk/code/merge-requests/28/>