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: failed i386 build of fis-gtm 7.0-004-1

[Shah, Amul]

Hi Andreas,
Thanks for updating to the latest GT.M version! GT.M V7 dropped support for x86 
due to the transition to 64bit block IDs.

If I could get through the corporate firewall, I would drop i386 from the 
“Architecture” sections in debian/control. Sorry, about that.

Thanks,
Amul

From: Debian buildds 
Date: Wednesday, 10 12, 2022 at 03:30 PM
To: dispa...@tracker.debian.org 
Subject: failed i386 build of fis-gtm 7.0-004-1
* Source package: fis-gtm
 * Version: 7.0-004-1
 * Architecture: i386
 * State: failed
 * Suite: sid
 * Builder: x86-ubc-02.debian.org
 * Build log: 
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbuildd.debian.org%2Fstatus%2Ffetch.php%3Fpkg%3Dfis-gtm%26arch%3Di386%26ver%3D7.0-004-1%26stamp%3D1665602422%26file%3Dlog&data=05%7C01%7Camul.shah%40fisglobal.com%7C44d72b557aa04992d66d08daac883119%7Ce3ff91d834c84b15a0b418910a6ac575%7C0%7C0%7C638011998340273689%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=JimjUwIKxf3s9I2voCudAa1PGdFqL9it2iKvi6kjdZs%3D&reserved=0

Please note that these notifications do not necessarily mean bug reports
in your package but could also be caused by other packages, temporary
uninstallabilities and arch-specific breakages.  A look at the build log
despite this disclaimer would be appreciated however.
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: Naming scheme of fis-gtm binary packages (Was: Bug#1009900: fis-gtm: Multiple CVEs in fis-gtm)

[Shah, Amul]

Hi Andreas,
We discussed this in the group and a number of people were not comfortable with 
removing the current versioning scheme. Let me revise my explanation of our 
versioning:

GT.M’s versioning follows this scheme:
  DBVersion.Major-Minor[Patch]
- DBVersion corresponds to the database block version
- Major corresponds to a major feature change in the product
- Minor represents a minor/incremental feature change in the product
- Patch is an alphabet denoting an emergency single change release

What do other DB projects do in this case? Could we make the DB version a 
textual string and ignore it with respect to the version number?

Currently V6.3-014 has a FTBFS #1011722 logged against it. It would be good to 
get V7.0-003 in the testing stream to close the bug.

Thanks,
Amul

From: Shah, Amul 
Date: Friday, 06 17, 2022 at 04:04 PM
To: Andreas Tille , Debian Med Project List 

Subject: Re: Naming scheme of fis-gtm binary packages (Was: Bug#1009900: 
fis-gtm: Multiple CVEs in fis-gtm)
Hi Andreas,
Thanks for changing the subject and dropping the bug tracker. I realized
my faux pas after the bug tracker replied to my email.

> > Could you remind me about what we are doing to cause this problem? Is it 
> > the installation path?
> > Or did you mean the below situation where there are two possible GT.M 
> > versions?
> > > aptitude search fis-gtm
> > p   fis-gtm 
> >   - metapackage for the latest version 
> > of FIS-GT.M database
> > i   fis-gtm-6.3-002 
> >   - package for FIS-GT.M database
> > p   fis-gtm-6.3-014 
> >   - package for FIS-GT.M database
>
> We (rather you, Bashkar and Luis Ibanez) decided to create a new binary
> package name for any mikro fis-gtm release to enable co-installation of
> all those packages.  I'm personally not convinced, that any single minor
> version bump needs to be installed on a typical Debian installation.
> This I would rather go with binary package names like fis-gtm-6.3  or
> fis-gtm-7.0 no matter whether what mikro version "-002" currently - may
> be "-003" next etc. the package is featuring.

[amul] I think we’re on the same page, to use MAJOR.MINOR in the package name.
Neither Bhaskar nor Luis Ibanez are working on fis-gtm. Let me discuss this 
here at
FIS. I don’t see any reason why we cannot adopt the naming scheme that you
propose, fis-gtm-Major.Minor, which also matches what other projects use.

> However, I do not know anything about fis-gtm and its compatibility between
> micro versions - so may be I'm just on the wrong track while looking from
> a Debian packaging perspective.  My perspective is that I'm just scared
> by uploading to the new queue for every single micro version bump which
> always is causing unpredictable delays until the package gets accepted in

[amul] GT.M’s versioning follows this scheme:
Major.Minor-Increment[Patch]
- Major corresponds to the database block version
- Minor corresponds to a major feature change in the product
- Increment (micro) represents a minor feature change in the product
- Patch is an alphabet denoting an emergency single change release

[amul] GT.M database formats (major version) change infrequently. Inside a
database version, GT.M is tested in various upgrade<->downgrade scenarios.
Meaning that there should be no reason to not upgrade.

Thanks,
Amul


From: Andreas Tille 
Date: Friday, 06 17, 2022 at 04:44 AM
To: Shah, Amul , Debian Med Project List 

Subject: Naming scheme of fis-gtm binary packages (Was: Bug#1009900: fis-gtm: 
Multiple CVEs in fis-gtm)
Hi Amul,

Am Thu, Jun 16, 2022 at 05:58:54PM + schrieb Shah, Amul:
> > Please reconsider the "add any minor version bump leads to a new binary
> > file name" strategy.  This means that fis-gtm always needs to pass the
> > Debian new queue which always means that there is a hardly predictable
> > delay when the package will reach the distribution.
>
> Could you remind me about what we are doing to cause this problem? Is it the 
> installation path?
>
> Or did you mean the below situation where there are two possible GT.M 
> versions?
> > aptitude search fis-gtm
> p   fis-gtm   
> - metapackage for the latest version of 
> FIS-GT.M database
> i   fis-gtm-6.3-002   
> - package for FIS-GT.M database
> p   fis-gtm-6.3-014   

Re: Naming scheme of fis-gtm binary packages (Was: Bug#1009900: fis-gtm: Multiple CVEs in fis-gtm)

[Shah, Amul]

Hi Andreas,
Thanks for changing the subject and dropping the bug tracker. I realized
my faux pas after the bug tracker replied to my email.

> > Could you remind me about what we are doing to cause this problem? Is it 
> > the installation path?
> > Or did you mean the below situation where there are two possible GT.M 
> > versions?
> > > aptitude search fis-gtm
> > p   fis-gtm 
> >   - metapackage for the latest version 
> > of FIS-GT.M database
> > i   fis-gtm-6.3-002 
> >   - package for FIS-GT.M database
> > p   fis-gtm-6.3-014 
> >   - package for FIS-GT.M database
>
> We (rather you, Bashkar and Luis Ibanez) decided to create a new binary
> package name for any mikro fis-gtm release to enable co-installation of
> all those packages.  I'm personally not convinced, that any single minor
> version bump needs to be installed on a typical Debian installation.
> This I would rather go with binary package names like fis-gtm-6.3  or
> fis-gtm-7.0 no matter whether what mikro version "-002" currently - may
> be "-003" next etc. the package is featuring.

[amul] I think we’re on the same page, to use MAJOR.MINOR in the package name.
Neither Bhaskar nor Luis Ibanez are working on fis-gtm. Let me discuss this 
here at
FIS. I don’t see any reason why we cannot adopt the naming scheme that you
propose, fis-gtm-Major.Minor, which also matches what other projects use.

> However, I do not know anything about fis-gtm and its compatibility between
> micro versions - so may be I'm just on the wrong track while looking from
> a Debian packaging perspective.  My perspective is that I'm just scared
> by uploading to the new queue for every single micro version bump which
> always is causing unpredictable delays until the package gets accepted in

[amul] GT.M’s versioning follows this scheme:
Major.Minor-Increment[Patch]
- Major corresponds to the database block version
- Minor corresponds to a major feature change in the product
- Increment (micro) represents a minor feature change in the product
- Patch is an alphabet denoting an emergency single change release

[amul] GT.M database formats (major version) change infrequently. Inside a
database version, GT.M is tested in various upgrade<->downgrade scenarios.
Meaning that there should be no reason to not upgrade.

Thanks,
Amul


From: Andreas Tille 
Date: Friday, 06 17, 2022 at 04:44 AM
To: Shah, Amul , Debian Med Project List 

Subject: Naming scheme of fis-gtm binary packages (Was: Bug#1009900: fis-gtm: 
Multiple CVEs in fis-gtm)
Hi Amul,

Am Thu, Jun 16, 2022 at 05:58:54PM + schrieb Shah, Amul:
> > Please reconsider the "add any minor version bump leads to a new binary
> > file name" strategy.  This means that fis-gtm always needs to pass the
> > Debian new queue which always means that there is a hardly predictable
> > delay when the package will reach the distribution.
>
> Could you remind me about what we are doing to cause this problem? Is it the 
> installation path?
>
> Or did you mean the below situation where there are two possible GT.M 
> versions?
> > aptitude search fis-gtm
> p   fis-gtm   
> - metapackage for the latest version of 
> FIS-GT.M database
> i   fis-gtm-6.3-002   
> - package for FIS-GT.M database
> p   fis-gtm-6.3-014   
> - package for FIS-GT.M database

We (rather you, Bashkar and Luis Ibanez) decided to create a new binary
package name for any mikro fis-gtm release to enable co-installation of
all those packages.  I'm personally not convinced, that any single minor
version bump needs to be installed on a typical Debian installation.
This I would rather go with binary package names like fis-gtm-6.3  or
fis-gtm-7.0 no matter whether what mikro version "-002" currently - may
be "-003" next etc. the package is featuring.

However, I do not know anything about fis-gtm and its compatibility between
micro versions - so may be I'm just on the wrong track while looking from
a Debian packaging perspective.  My perspective is that I'm just scared
by uploading to the new queue for every single micro version bump which
always is causing unpredictable delays until the package gets accepted in
u

RE: [fis-gtm] FW: GT.M V6.2-002A available

[Shah, Amul]

Hi Andreas,


From: Amul Shah [amul.s...@fisglobal.com]
Sent: Tuesday, June 09, 2015 2:25 PM
To: debian-med@lists.debian.org
Subject: Re: [fis-gtm] FW: GT.M V6.2-002 available

Hi Andreas,

On 06/09/15 10:36, Andreas Tille wrote:
> Hi Amul,
>
> On Tue, Jun 09, 2015 at 01:19:46PM +0000, Shah, Amul wrote:
>> I uploaded the latest version of GT.M that we released yesterday.
> Thanks for your work on this.
>
>> I tagged the version as unstable. Let me know if that was the correct thing 
>> to do.
> Perfect.  Unfortunately I'm on vacation behind a quite slow connection
> and thus can not upload any larger package.  If somebody else might take
> this one it would be nice - otherwise please wait until end of June.
>
> Thanks for your work on this
[amul:2] Thank you for responding while on vacation! I'm fine with waiting if 
no one can do the upload.

[amul:3] We had to patch GT.M V6.2-002 due to a customer reported issue. The 
new release is V6.2-002A. I uploaded the sources last week. Please take a look 
and let me know if I handled the GT.M "letter" release correctly.

thanks, Amul

_
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.


--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/fc737af506db9b40b931fcdfbdfaf2f654f7f...@ltcfiswmsgmb17.fnfis.com

[fis-gtm] FW: GT.M V6.2-002 available

[Shah, Amul]

[sorry for the top post, Outlook doesn't do proper quoting]
Hi Andreas,
I uploaded the latest version of GT.M that we released yesterday. I tagged the 
version as unstable. Let me know if that was the correct thing to do.

As always, thanks for help.

Amul


From: Bhaskar, KS
Sent: Monday, June 08, 2015 1:48 PM
To: Omar Shboul; Khamis Siksek; Ahmad Sharaf; Mohammed Sharaf; Murat Khemesh; 
Wasim Naffar
Cc: FIS MLN GG GT.M Support
Subject: GT.M V6.2-002 available


V6.2-002 brings a number of modest enhancements to GT.M.

Improving performance:

  *   By reducing the number of dirty global buffers to be flushed in 
anticipation of an impending epoch, epoch tapers aim to ameliorate spikes in 
response time that can occur at epochs.

  *   $ORDER(gvn,-1) - "reverse dollar order" - of global variables is faster.

  *   Under conditions of high contention, processes holding locks exit faster, 
processes acquire database critical sections more efficiently when the mutex 
queue slots are all used, and lock acquisition is more efficient with 
substantially reduced impact on database throughput.

  *   Code size reduction that also improves performance.

Enhancements include:

  *   Intrinsic special variables: $ZUT provides a universal (across systems 
and across time zones) time stamp, and $ZHOROLOG extends $HOROLOG with 
additional pieces that provide microsecond resolution and time zone information.

  *   TLS for SOCKET devices benefits from enhancements to WRITE /TLS and 
$ZSOCKET().

  *   The environment variable gtm_autorelink_ctlmax provides a control to set 
the number of unique routine names in relink conrol files.

VIEW "POOLLIMIT" functionality introduced as field test grade functionality in 
the production release V6.2-001 is considered production grade functionality in 
V6.2-002.

As always, the release bring numerous smaller enhancements, including to the 
$ZQGBLMOD() function, better handling of split $PRINCIPAL, more helpful 
TPRESTART messages, and more. Robustness is improved, especially in the 
triggers, and security has been tightened by dropping support for dubious edge 
cases . These changes are described in the Release Notes 
(http://tinco.pair.com/bhaskar/gtm/doc/articles/GTM_V6.2-002_Release_Notes.html).

Please do upgrade to V6.2-002, and tell us how it works for you.  Thank you for 
using GT.M.

Regards
-- Bhaskar

--
GT.M - Rock solid. Lightning fast. Secure. Pick any three.

_
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: [fis-gtm] Updating fis-gtm to V6.2-001

[Shah, Amul]

Sent via OWA2010


From: Andreas Tille [andr...@an3as.eu]
Sent: Sunday, January 25, 2015 2:47 PM
To: debian-med@lists.debian.org
Subject: Re: [fis-gtm] Updating fis-gtm to V6.2-001

Hi Amul,

On Fri, Jan 23, 2015 at 02:01:17PM -0500, Amul Shah wrote:
> >
> > cme fix dpkg-control
>
> [amul:4] Changes committed, please take a look.

Looks ready for upload to me.  Should I upload (if yes I would change
the target distribution from precise to unstable).

[amul:5] Ack! That's what I get for working on an Ubuntu machine. I changed the 
release to unstable. Please upload.

As always, thank you for your help!
Amul

_
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.


--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/fc737af506db9b40b931fcdfbdfaf2f6543a9...@ltcfiswmsgmb26.fnfis.com

RE: [fis-gtm] Updating fis-gtm to V6.2-001

[Shah, Amul]

Hi Andreas,
I apologize in advance for the horrid formatting that Outlook does to mails.

From: Amul Shah [amul.s...@fisglobal.com]
Sent: Wednesday, January 14, 2015 9:26 AM
To: debian-med@lists.debian.org
Subject: Re: [fis-gtm] Updating fis-gtm to V6.2-001

Hi Andreas,

On 01/14/15 02:12, Andreas Tille wrote:
> Hi Amul,
>
> On Tue, Jan 13, 2015 at 04:40:28PM -0500, Amul Shah wrote:
>> Last month FIS released GT.M V6.2-001. I have staged the changes for
>> upload. I will upload once I fix one minor issue with the gtmprofile
>> environment script.
> Fine.  Just tell me once you consider it ready for sponsering.

[amul:2] Will do thanks.

[amul:3] While I diagnose the issue with #775302, I thought it prudent to not 
hold V6.2-001. Please consider this version ready for sponsoring.

[amul:3] I checked https://tracker.debian.org/pkg/fis-gtm for the latest status 
and saw that the standards version has increased. Should I change it? I think 
fis-gtm is already compliant with the standards change. There is also a lintian 
error (see below) for the 32bit version which doesn't seem right since we 
always build with -fPIC. I'll see what happens on a 32bit machine and correct 
it.
* shlib-with-non-pic-code
usr/lib/i386-linux-gnu/fis-gtm/V6.2-000_i586/libgtmshr.so

thanks,
Amul

_
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.


--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/fc737af506db9b40b931fcdfbdfaf2f6543a7...@ltcfiswmsgmb26.fnfis.com

RE: Updating the fis-gtm package to V6.2-000

[Shah, Amul]

Hi Andreas,
Excuse the formatting, I'm using the corporate OWA server which mangles mail 
like outlook. Look for [amul:2] below.

On Wed, Sep 24, 2014 at 09:41:34AM -0400, Amul Shah wrote:
> >I also wonder whether you could forward the "spelling-error-in-binary"
> >type lintian infos to upstream.
>
> [amul:1] I didn't see this lintian message. That said, cleaning
> things up in the upstream is preferable. The fewer exceptions the
> better.

You need to call

   lintian -I

to get these.


[amul:2] I have not done this yet.


> >>While looking at the installed directory, I noticed two inconsistencies 
> >>marked as (todo) in the changelog. Both entries are related to the 
> >>encryption plugins. We build only one plugin (using libgcrypt and 
> >>AES256CFB) and the "plugin" directory is a symlink in the utf8 directory 
> >>(which IIRC does not match what our install script produces).
> >So do you plan to fix this before I'll upload?  Please tell me once you
> >are happy with the package since I personally know to less about fis-gtm
> >to know whether these todos are blocking issues or not.
>
> [amul:1] I would like to fix the build to generate all of the
> encryption plugins, but I don't think that should hold up the
> release of the V6.2-000.

OK, just tell me once you consider this done.

[amul:2] I have the patch to build all three encryption plugins and the default 
symlink. I will push this set of changes soon. Please take a look. If you are 
fine with the changes, V6.2-000 is ready for upload. :)

Many thanks for your help,
Amul

_
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.


--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/fc737af506db9b40b931fcdfbdfaf2f65431d...@ltcfiswmsgmb26.fnfis.com

RE: Any progress with FIS GT.M?

[Shah, Amul]

Luis,
GT.M Regression Test Suite results are nearly complete. With the exception of a 
few configuration related issues and tests that need to be fixed, everything is 
in good shape.

The first round of testing hit a latent GT.M bug that is fixed in the upcoming 
release. I back ported the change which switches memcpy to memmove in several 
modules. Because the sources have diverged a from the original V5.5-000 I 
modified sr_linux/release_name.h to change the reported version to V5.5-000A. I 
have pushed these changes to git hub. Please integrate at your convenience.

thanks,
Amul

_
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.


--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/FC737AF506DB9B40B931FCDFBDFAF2F6B7EF97@ltcfiswmsgmb26