Re: Novice needs help submitting a bug report

[Mathieu Malaterre]

On Mon, Apr 3, 2023 at 11:41 PM Shah, Amul  wrote:
>
> All,
>
> I need some guidance. The host where we encountered a bug is sitting in a lab 
> environment with no direct Internet access. Below is the output from 
> reportbug with the print-only option.
>
>
>
> I am filing a bug against glibc 2.36 due to a bug in memcmp-sse2.S

Here is what I am reading from the git commit message:

[...]
In the case of INCORRECT usage of `memcmp(a, b, N)` where `a` and `b`
are concurrently modified as `memcmp` runs, there can be a SIGSEGV
in `L(ret_nonzero_vec_end_0)` because the sequential logic
assumes that `(rdx - 32 + rax)` is a positive 32-bit integer.
[...]
https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=b712be52645282c706a5faa038242504feb06db5

I am pretty sure the actual root issue is in fis-gtm instead. Could
you check with them directly?

> that causes fis-gtm to segfault possibly leading to data corruption. There is 
> already a fix in the upstream (see below). I am unsure of how to proceed. I 
> know that I should create the bug report so that the problem gets fixed, 
> either by patching or adoption of the version with the fix. Should I submit 
> the patch myself? Or should I just wait for the adoption of the latest glibc 
> version, 2.37?
>
>
>
> Please let me know if there is anything that I can do to improve the quality 
> of my bug report and if I can/should help myself by providing a patch.
>
>
>
> Thanks!
>
> Amul
>
>
>
> --- content of the reportbug email ---
>
>
>
> Content-Type: text/plain; charset="us-ascii"
>
> MIME-Version: 1.0
>
> Content-Transfer-Encoding: 7bit
>
> From: Amul Shah amul.s...@fisglobal.com
>
> To: Debian Bug Tracking System sub...@bugs.debian.org
>
> Subject: libc-bin: Bug in glibc causes SIGSEGV in fis-gtm; see upstream bug 
> report BZ #29863
>
>
>
> Package: libc-bin
>
> Version: 2.36-8
>
> Severity: grave
>
> Justification: renders package unusable
>
> X-Debbugs-Cc: amul.s...@fisglobal.com
>
>
>
> Dear Maintainer,
>
>
>
> There is a bug in glibc 2.36 that has been fixed in 2.37. The two links below 
> detail the original bug report and the fix.
>
> - Upstream bug report - https://sourceware.org/bugzilla/show_bug.cgi?id=29863
>
> - Upstream commit fixing said bug report – 
> https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=b712be52645282c706a5faa038242504feb06db5
>
>
>
> This bug causes fis-gtm to randomly crash on a SIGSEGV. Depending upon 
> process activity, the crash could result in database damage.
>
>
>
> -- System Information:
>
> Debian Release: bookworm/sid
>
>   APT prefers unstable-debug
>
>   APT policy: (500, 'unstable-debug'), (500, 'unstable')
>
> Architecture: amd64 (x86_64)
>
>
>
> Kernel: Linux 6.1.0-3-amd64 (SMP w/8 CPU threads; PREEMPT)
>
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not 
> set
>
> Shell: /bin/sh linked to /usr/bin/dash
>
> Init: systemd (via /run/systemd/system)
>
> LSM: AppArmor: enabled
>
>
>
> Versions of packages libc-bin depends on:
>
> ii  libc6  2.36-8
>
>
>
> Versions of packages libc-bin recommends:
>
> ii  manpages  6.02-1
>
>
>
> libc-bin suggests no packages.
>
> The information contained in this message is proprietary and/or confidential. 
> If you are not the intended recipient, please: (i) delete the message and all 
> copies; (ii) do not disclose, distribute or use the message in any manner; 
> and (iii) notify the sender immediately. In addition, please be aware that 
> any message addressed to our domain is subject to archiving and review by 
> persons other than the intended recipient. Thank you.

Novice needs help submitting a bug report

[Shah, Amul]

All,
I need some guidance. The host where we encountered a bug is sitting in a lab 
environment with no direct Internet access. Below is the output from reportbug 
with the print-only option.

I am filing a bug against glibc 2.36 due to a bug in memcmp-sse2.S that causes 
fis-gtm to segfault possibly leading to data corruption. There is already a fix 
in the upstream (see below). I am unsure of how to proceed. I know that I 
should create the bug report so that the problem gets fixed, either by patching 
or adoption of the version with the fix. Should I submit the patch myself? Or 
should I just wait for the adoption of the latest glibc version, 2.37?

Please let me know if there is anything that I can do to improve the quality of 
my bug report and if I can/should help myself by providing a patch.

Thanks!
Amul

--- content of the reportbug email ---

Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Amul Shah amul.s...@fisglobal.com
To: Debian Bug Tracking System 
sub...@bugs.debian.org
Subject: libc-bin: Bug in glibc causes SIGSEGV in fis-gtm; see upstream bug 
report BZ #29863

Package: libc-bin
Version: 2.36-8
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: amul.s...@fisglobal.com

Dear Maintainer,

There is a bug in glibc 2.36 that has been fixed in 2.37. The two links below 
detail the original bug report and the fix.
- Upstream bug report - https://sourceware.org/bugzilla/show_bug.cgi?id=29863
- Upstream commit fixing said bug report – 
https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=b712be52645282c706a5faa038242504feb06db5

This bug causes fis-gtm to randomly crash on a SIGSEGV. Depending upon process 
activity, the crash could result in database damage.

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-3-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libc-bin depends on:
ii  libc6  2.36-8

Versions of packages libc-bin recommends:
ii  manpages  6.02-1

libc-bin suggests no packages.
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.

Re: New version bali-phy 4.0-beta2

[Benjamin Redelings]

Hi,

Thanks for the advice!

On 3/29/23 3:04 PM, Andreas Tille wrote:

Hi Benjamin,

Am Tue, Mar 28, 2023 at 07:04:52AM +0200 schrieb Pierre Gruet:

Probably you wouold like to do something as in

https://sources.debian.org/src/gedit-plugins/44.1-2/debian/watch/?hl=2#L2
for the gedit-plugins package? This was found by typing "path:debian/watch
beta" in the search field of sources.debian.org. There are other packages
which you could check there.

ACK.


I tried a few things, but haven't figured this out yet.  I see there is 
versionmangle, dversionmangle, and uversionmangle.  I see that we want 
the debian version to be 4.0~beta2, not 4.0-beta2 (i.e. with a tilde).  
I will try again later.



Secondly, I suppose that any new version would need to go into
experimental, since we are in a hard freeze?  I would like to start
working on packaging for version 4 now, since some things have changed
and I'd like to figure out how to deal with them now.

Yes, uploading to experimental is the right thing to do right now :)

I'm wondering whether any beta versions should go to experimental in
general.  The fact that upstream marks it as beta is usually a sign that
the code is not for end users production systems.  I wrote a couple of
watch files that do not even report any alpha/beta versions as new
version.


I am the upstream :-)  I understand the reasoning though.  I don't think 
you should package all betas, but in this case (i.e. for version 
4.0-beta2), as the upstream I feel like its the right thing to do.


I could relabel this as version 4.0, but I would prefer not to, since 
there are some features that I want to add before I label this as 4.0.


Perhaps this does not matter, since it would be uploaded to experimental 
anyway.


-BenRI




Kind regards
 Andreas.