from:"Amul Shah"

Re: Novice needs help submitting a bug report

2023-04-05 Thread Amul Shah

Many thanks Mathieu!

On Tue, Apr 4, 2023, at 3:57 AM, Mathieu Malaterre wrote:
> On Tue, Apr 4, 2023 at 8:37 AM Mathieu Malaterre  wrote:
>>
>> 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?
>
> OK, nevermind. I did read the complete exchange on bugzilla, and created:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033931
>
> Just FYI you can report a bug from almost anywhere, simply follow the
> example from:
>
> * https://www.debian.org/Bugs/Reporting
>
>> > 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: Please update fis-gtm package

2018-12-01 Thread Amul Shah

On Oct 28, 2018, at 7:09 AM, Andreas Tille  wrote:
> 
> Hi Amul,
> 
> when updating all Vcs fields of Debian Med packages to salsa I update
> fis-gtm.  I noticed that you had injected a changelog entry for V6.3-004
> but now V6.3-005 is up to date.  You did not yet answered my question
> about the continuous name change of the binary package (or I forgot your
> answer ;-) ).  Please review and update the packaging and tell me once
> you are finished to let me upload the package.

Hi Andreas,
It’s been a busy few months and I keep telling myself that I’ll do the fis-gtm 
package next week. We released V6.3-006 at the end of last month, but the 
corporate security goon squad decided to block SourceForge.net and we’re still 
awaiting for permission to access it from corporate resources.

I tried searching (both in my email and via a mailing list search) for the 
package name discussion, but couldn’t find it. Could you resend it or remind me 
what the question is?

thanks,
Amul

Re: [fis-gtm] "action needed" items

2016-04-01 Thread Amul Shah




On 03/31/16 16:32, Andreas Tille wrote:

Hi Amul,

On Thu, Mar 31, 2016 at 10:59:59AM -0400, Amul Shah wrote:

Hi Andreas,

On 03/31/16 06:05, Andreas Tille wrote:

On Wed, Mar 30, 2016 at 05:17:52PM -0400, Amul Shah wrote:

FIS released GT.M V6.3-000 yesterday and I am in the process of updating the
Debian package. Since I have the spare cycles, I want to address a few of
the "action needed" items listed on 
https://urldefense.proofpoint.com/v2/url?u=https-3A__tracker.debian.org_pkg_fis-2Dgtm=BQIBAg=3BfiSO86x5iKjpl2b39jud9R1NrKYqPq2js90dwBswk=9ssj4QMqXvXerR0OPzrgsqFDldUsqMEK5X4uhRXsy2Q=YORLm8M3Qw3iJc6i6s29cfgJTMmSJHlp8J14aQxl7kU=ZMLBgoGBKH0F_wZpBO6OnULXzoS2kBC0WK_m95wC6zM=

Thanks for keeping the packages up to date.

[amul:2] After the last round of updates, we instituted a few changes
internally to ensure that we can ship the Debian package ASAP. Can you look
over my recent commit and make any necessary changes? Also, when do can we
push the new version into unstable?

Just uploaded.  Will be in unstable after the next mirror sync.


[amul:3] Thanks!



The only thing I'd recommend to test is the following patch:

$ git diff
diff --git a/debian/rules b/debian/rules
index cef9eff..5415aa0 100755
--- a/debian/rules
+++ b/debian/rules
@@ -15,6 +15,8 @@ BINPKG := $(shell awk '/Package:.*[0-9]/{print $$2;}' 
debian/control)
  GTM_INSTALL_DIR := lib/$(MARCH)/fis-gtm/$(UAPIDIR)
  LOCAL_GTM_INSTALL_DIR := $(CURDIR)/debian/$(BINPKG)/usr/$(GTM_INSTALL_DIR)
  
+export DEB_BUILD_MAINT_OPTIONS = hardening=+all

+
  %:
 dh $@ --parallel
  



This should reduce the number of lintian issues about hardening (when
using lintian with info severity).


[amul:3] I will give that a try.



The above files are FIS GT.M database files generated during the build.
These databases hold the online help for FIS GT.M executables. Database
files won't be the same due to time related information in the block
headers. So I need to exclude these files from being checked.

I wonder whether there would be any sensible chance to determine the
time stamp - may be for instance to the time stamp of the changelog.
Does GT.M provide any such functionality?

[amul:2] I don't know of such a functionality. :(

Could you contact upstream about adding such a feature.  If I would
design such a system I think this is kind of an essential feature for
instance if you want to design a test suite to be able to rely on a
defined state.  BTW, what about creating a test suite that could be run
at build time as well as autopkgtest.


[amul:3] About adding the feature, see below.

[amul:3] FIS has a 15+ year old regression test suite. Migrating parts of it 
into CTest (usable by autopkgtest) is on my todo list.




I do not think that you can exclude any files from beeing checked.  I'd
recommend talking with upstream whether any fixed time setting would be
possible or the reproducible builds team whether they know any way to
create a fake-system-time.

[amul:2] By upstream, do you mean FIS GT.M developers?

Yes, that's the usual Debian slang.


[amul:3] I guess you forgot that I am upstream. :) I should have said that in the last mail. I tried the libfaketime and 
datefudgechange for fun but that didn't change reproducibility. I need to look into the DB block level format to figure out if I 
can work through this.



Best Regards,
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.

Re: [fis-gtm] "action needed" items

2016-03-31 Thread Amul Shah

Hi Andreas,

On 03/31/16 06:05, Andreas Tille wrote:

On Wed, Mar 30, 2016 at 05:17:52PM -0400, Amul Shah wrote:

FIS released GT.M V6.3-000 yesterday and I am in the process of updating the
Debian package. Since I have the spare cycles, I want to address a few of
the "action needed" items listed on https://tracker.debian.org/pkg/fis-gtm

Thanks for keeping the packages up to date.
[amul:2] After the last round of updates, we instituted a few changes internally to ensure that we can ship the Debian package
ASAP. Can you look over my recent commit and make any necessary changes? Also, when do can we push the new version into unstable?

report if they consider it an issue of packaging.

Previously, when I looked at the non-reproducible build warnings, I saw a
warning complaining about the following list of files:
dsehelp.dat
gdehelp.dat
gtmhelp.dat
lkehelp.dat
mupiphelp.dat

The above files are FIS GT.M database files generated during the build.
These databases hold the online help for FIS GT.M executables. Database
files won't be the same due to time related information in the block
headers. So I need to exclude these files from being checked.

I wonder whether there would be any sensible chance to determine the
time stamp - may be for instance to the time stamp of the changelog.
Does GT.M provide any such functionality?

[amul:2] I don't know of such a functionality. :(

I readhttps://wiki.debian.org/ReproducibleBuilds
andhttps://reproducible-builds.org/docs
to learn how to exclude these files
from being checked, but could not find any mechanism. Most of the docs
merely glorified the greatness* reproducible builds. Does
anyone know a way to exclude these files? * I agree with it the
principle, but I have an exception that I cannot work around.

I do not think that you can exclude any files from beeing checked. I'd
recommend talking with upstream whether any fixed time setting would be
possible or the reproducible builds team whether they know any way to
create a fake-system-time.

[amul:2] By upstream, do you mean FIS GT.M developers? There is a library libfaketime (https://github.com/wolfcw/libfaketime)
that might help in this. I'll let you know.

-- build log check warning --

I admit I never cared about this and thus can't comment on this.

[amul:2] Ok, I'll happily ignore this for now. :)

As always, thanks for you 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.

[fis-gtm] "action needed" items

2016-03-30 Thread Amul Shah

Hello,
FIS released GT.M V6.3-000 yesterday and I am in the process of updating the Debian package. Since I have the spare cycles, I
want to address a few of the "action needed" items listed on https://tracker.debian.org/pkg/fis-gtm. I made some changes to
address the uscan error and lintian warnings, but I have some questions about two other items.

-- non-reproducible builds --
The link for this, https://tests.reproducible-builds.org/rb-pkg/testing/amd64/fis-gtm.html, is marked with a FTBFS for the
second build. The problem with the second build seems to be a configuration problem on the build server. Notice the complaints
(below) from PERL about LC_ALL. The recurring setlocale warnings seem to have caused problems for CMake resulting in a build
failure.

I: using fakeroot in build.
I: pbuilder: network access will be disabled during build
I: Current time: Mon May 1 02:34:11 GMT-14 2017
I: pbuilder-time-stamp: 1493555651
I: Building the build Environment
I: extracting base tarball [/var/cache/pbuilder/testing-reproducible-base.tgz]
I: copying local configuration
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = "fr_CH.UTF-8",
LANG = "fr_CH.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").

See
https://tests.reproducible-builds.org/logs/unstable/amd64/fis-gtm_6.2-002A-3.build2.log.gz
for the full build log

Do I need to take any action to address the above?

Previously, when I looked at the non-reproducible build warnings, I saw a
warning complaining about the following list of files:
dsehelp.dat
gdehelp.dat
gtmhelp.dat
lkehelp.dat
mupiphelp.dat

The above files are FIS GT.M database files generated during the build. These databases hold the online help for FIS GT.M
executables. Database files won't be the same due to time related information in the block headers. So I need to exclude these
files from being checked.

I read https://wiki.debian.org/ReproducibleBuilds and https://reproducible-builds.org/docs to learn how to exclude these files
from being checked, but could not find any mechanism. Most of the docs merely glorified the greatness* reproducible builds. Does
anyone know a way to exclude these files? * I agree with it the principle, but I have an exception that I cannot work around.

-- build log check warning --
The fis-gtm build was tagged with "W-compiler-flags-hidden". If I understood
https://wiki.debian.org/Hardening#Notes_for_packages_using_CMake correctly, I should get dpkg-buildflags for free. Am I correct?

The hardening options are in force.
shaha:~/debmed/fis-gtm> hardening-check /usr/lib/x86_64-linux-gnu/fis-gtm/V6.3-000_x86_64/mumps
/usr/lib/x86_64-linux-gnu/fis-gtm/V6.3-000_x86_64/libgtmshr.so

/usr/lib/x86_64-linux-gnu/fis-gtm/V6.3-000_x86_64/mumps:
Position Independent Executable: no, normal executable!
Stack protected: yes
Fortify Source functions: yes
Read-only relocations: yes
Immediate binding: no, not found!
/usr/lib/x86_64-linux-gnu/fis-gtm/V6.3-000_x86_64/libgtmshr.so:
Position Independent Executable: no, regular shared library (ignored)
Stack protected: yes
Fortify Source functions: yes (some protected functions found)
Read-only relocations: yes
Immediate binding: no, not found!

On a second read of
https://qa.debian.org/bls/bytag/W-compiler-flags-hidden.html, I think I
understand the complaint better.

buildd log scanner tag W-compiler-flags-hidden

description

The package contains build commands which hide the real compiler flags (non-verbose builds). This prevents automatic checks
for missing (hardening) flags.

False positives are possible, especially when building in parallel. In this
case this warning can be ignored.

The complaint is that the build flags are not present in the build log file.
Would the fix be to build with VERBOSE=1?

Thanks in advance,
Amul

Re: fis-gtm is Marked for autoremoval on 04 September, Bug #794733

2015-08-21 Thread Amul Shah



 On Aug 21, 2015, at 3:24 AM, Andreas Tille andr...@fam-tille.de wrote:
 
 severity 794733 important
 thanks
 
 As per
 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794733#14
 
 this problem does not affect the libconfig transition.  It also can not
 be reproduced on an unstable system.  So I decrease its severity from
 serious to important.
 
 Kind regards
 
   Andreas.
 
 On Thu, Aug 20, 2015 at 05:36:20PM -0400, Amul Shah wrote:
 Someone logged a FTBFS (failed to build from source) bug against fis-gtm
 (https://tracker.debian.org/pkg/fis-gtm). I have at my disposal Debian 7.8
 and unstable servers. I attempted to reproduce the failure on each without
 success.
 
 How do I respond to such a claim when I cannot reproduce it?
 
 thanks,
 Amul

Thanks Andreas! Does the bug reporter usually respond to confirm that it's no 
longer present?

Amul

fis-gtm is Marked for autoremoval on 04 September, Bug #794733

2015-08-20 Thread Amul Shah

Someone logged a FTBFS (failed to build from source) bug against fis-gtm (https://tracker.debian.org/pkg/fis-gtm). I have at my 
disposal Debian 7.8 and unstable servers. I attempted to reproduce the failure on each without success.


How do I respond to such a claim when I cannot reproduce it?

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.

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

2015-06-09 Thread Amul Shah


Hi Andreas,

On 06/09/15 10:36, Andreas Tille wrote:

Hi Amul,

On Tue, Jun 09, 2015 at 01:19:46PM +, 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

_
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/55772fa1.3030...@fisglobal.com

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

2015-01-23 Thread Amul Shah

On 01/23/15 03:30, Andreas Tille wrote:

Hi Amul,

On Fri, Jan 23, 2015 at 12:34:44AM +, Shah, Amul wrote:

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

OK.

[amul:3] I checked
https://urldefense.proofpoint.com/v2/url?u=https-3A__tracker.debian.org_pkg_fis-2Dgtmd=AAIBAgc=3BfiSO86x5iKjpl2b39jud9R1NrKYqPq2js90dwBswkr=9ssj4QMqXvXerR0OPzrgsqFDldUsqMEK5X4uhRXsy2Qm=193k-07vNc2YIahOZdLPKMv-1MIWcoyauQdbs1XU248s=f8o_NnFxekHRHlZ_A7NTkULyUO93jHeWGheJaaSFjRUe=
for the latest status and saw that the standards version has increased. Should I change it?

Yes. A package targeting at unstable (== not bound to the smallest set
of modifications to reach the frozen Jessie) should comply with the
latest standards version and in close to all cases this is simply done
by bumping the version number. The most easy way to do this is

cme fix dpkg-control

[amul:4] Changes committed, please take a look.

which does this for you besided some checking of your (Build-)Depends.
(See policy manual about what packages to install to enable cme.)

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

Hmmm, no idea about this - if you are concerned about this I'd suggest
to ask on debian-ment...@lists.debian.org.

[amul:4] I'll try that thanks.

Amul

--
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/54c29a7d.3040...@fisglobal.com

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

2015-01-14 Thread Amul Shah


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.



I was unable to reproduce the
bug using the package that I built on my workstation, but I was able
to reproduce it using the package that I downloaded from
https://urldefense.proofpoint.com/v2/url?u=https-3A__packages.debian.org_sid_fis-2Dgtm-2D6.2-2D000d=AAIBAgc=3BfiSO86x5iKjpl2b39jud9R1NrKYqPq2js90dwBswkr=9ssj4QMqXvXerR0OPzrgsqFDldUsqMEK5X4uhRXsy2Qm=TfDgPzIN1Hni668ZWcVy38TkfHzQFZuozR9w69C6blos=IKPE41foFP0W3Cs_636umZdsGu27MoR0FjcLqxAWWO0e=
 .

How did you build the package on your workstation?  If you were using
git-buildpackage in connection with pbuilder (as suggested in Debian Med
policy) it should be basically identically to the downloaded package.  I
guess / hope that the solution for the bug might be hidden behind this
question - otherwise I have no idea what to do.


I checked the build logs available on
https://urldefense.proofpoint.com/v2/url?u=https-3A__tracker.debian.org_pkg_fis-2Dgtmd=AAIBAgc=3BfiSO86x5iKjpl2b39jud9R1NrKYqPq2js90dwBswkr=9ssj4QMqXvXerR0OPzrgsqFDldUsqMEK5X4uhRXsy2Qm=TfDgPzIN1Hni668ZWcVy38TkfHzQFZuozR9w69C6blos=ymoCTnfWgU-dY-r2mkTnVhnYhw0qng6uWb13e2eQS-Me=
 , but didn't see anything
amiss. What is the usual debugging pattern for such an issue?

I personally have not faced such an issue before so I can not come up
with a usual pattern.  It might help to create a minimal chroot
environment and try to rebuild and run there.  As said above please
explain how exactly you created your local package.  Perhaps you can
run ldd against the binaries inside the package to see against what
these are linked?


[amul:2] Uh-oh, I used git-buildpackage. I have a clean non-GT.M development system at home to try the package build. If that 
fails, I will create the minimal chroot like you suggested.


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/54b67c9a.1050...@fisglobal.com

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

2015-01-13 Thread Amul Shah


All,
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.


I just filed a bug, Bug#775302, against the fis-gtm package on behalf of a user on comp.lang.mumps. I was unable to reproduce 
the bug using the package that I built on my workstation, but I was able to reproduce it using the package that I downloaded 
from https://packages.debian.org/sid/fis-gtm-6.2-000.


I checked the build logs available on https://tracker.debian.org/pkg/fis-gtm, but didn't see anything amiss. What is the usual 
debugging pattern for such an issue?


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/54b590cc.6090...@fisglobal.com

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

2014-10-09 Thread Amul Shah


Hi Thorsten and Andreas,

On 10/09/14 07:37, Andreas Tille wrote:

Hi Thorsten,

On Thu, Oct 09, 2014 at 12:26:16PM +0200, Thorsten Alteholz wrote:

Hmm, strictly speaking the bug is in 6.1-000 and won't be fixed by
uploading 6.2-000. I think the bug should not be assigned to package
fis-gtm but rather fis-gtm-6.1-000 (and of course be fixed in
fis-gtm-6.2-000 as well)

Hmmm, the affected fis-gtm-6.1-000 will vanish from Debian mirror, after
fis-gtm-6.2-000 will be accepted.

fis-gtm in version 6.1-000 will vanish after upload of fis-gtm in
version 6.2-000.
But src:fis-gtm currently creates bin:fis-gtm-6.1-000 and will
create bin:fis-gtm-6.2-000 after the upload.

Yes.


Wasn't the reason for
creating the fis-gtm meta package to have different versions in the
archive? Otherwise it wouldn't make sense to have the version within
the package name.

The agreement was that a user could pick some older binary package from
snapshot.debian.org which can be installed in parallel to the versioned
package.  Or the user can install fis-gtm-6.2-000 in addition to an
older version - but the older version vanishes from the archive.  At
least I have understood it this way.  I have no idea whether this makes
really sense - I'm no fis-gtm user.  However, we agreed that for a low
popcon package it is not possible to maintain several versions
officially.

Does this clarify my idea why fixing the licensing issue in
fis-gtm-6.2-000 would be sufficient?


[amul:11] We have two options at this point regarding fis-gtm-6.1-000. Withdraw the version or update it. We - I, Bhaskar and a 
few other GT.M developers - are fine with either. If someone could point me to a doc to show how to fix the prior version, I can 
fix it. My google-fu isn't turning anything up.


[amul:11] I looked through https://www.debian.org/doc/manuals/developers-reference for the steps to withdraw the package 
(https://www.debian.org/doc/manuals/developers-reference/pkgs.html#removing-pkgs) and close the bug 
(https://www.debian.org/doc/manuals/developers-reference/pkgs.html#upload-bugfix). Is that what I should do?


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/54369ea0.7000...@fisglobal.com

[newbie question] Does the fis-gtm package exist as both binary and source packages?

2014-10-08 Thread Amul Shah


Andreas (or anyone else with the answer :),
When we request an upload of the fis-gtm package, does that imply the creation of a source package? If not, what do I need to do 
to ensure that there is a source package?


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/54354ec0.2010...@fisglobal.com

Re: [newbie question] Does the fis-gtm package exist as both binary and source packages?

2014-10-08 Thread Amul Shah

Emilien,
Thanks. I didn't realize the source package is the starting point.

Amul

 On Oct 8, 2014, at 2:05 PM, Emilien Klein emilien+deb...@klein.st wrote:
 
 A classical Debian package is always composed by a source package (the
 combination of the upstream source code and the Debian-specific
 metadata and scripts, i.e. the /debian repository) and a binary
 package (the .deb you would install on your system).
 If a specific upstream source has been uploaded to the repository, and
 changes are made to the Debian-specific bits, the upstream tarball
 would not be changed but a new version of the /debian files will be
 created, along with a new version of the binary package.
 If a new upstream version is released, the new upstream tarball along
 with an updated /debian folder is uploaded, and also the new binary
 package.
 
 Does that answer your question?
   +Emilien
 
 
 
 2014-10-08 16:48 GMT+02:00 Amul Shah amul.s...@fisglobal.com:
 Andreas (or anyone else with the answer :),
 When we request an upload of the fis-gtm package, does that imply the
 creation of a source package? If not, what do I need to do to ensure that
 there is a source package?
 
 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/54354ec0.2010...@fisglobal.com
 
 
 -- 
 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/canqxmqh0-jesxytw5mewlwkz6gckic8pbyxekw0cyugxk-u...@mail.gmail.com
 


--
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/af3ac520-e39d-4fb4-868b-307455c2f...@amulz.com

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

2014-10-08 Thread Amul Shah



On 10/08/14 15:57, Andreas Tille wrote:

On Tue, Oct 07, 2014 at 08:33:53PM -0400, Amul Shah wrote:

Andreas,
Kindly upload fis-gtm... again.

No - the package is not ready yet. :-(

You did not addressed

   https://bugs.debian.org/762457

which is really important to let fis-gtm migrate to testing (=future
stable).  Please fix the copyright and make sure you allways check

   https://bugs.debian.org/src:fis-gtm

when preparing a package.


[amul:9] Thanks for those links. I didn't know there was a bug filed. I'll take 
care of that this evening.

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/5435af30.9000...@fisglobal.com

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

2014-10-08 Thread Amul Shah

Hi Andreas,

On Wed, Oct 8, 2014, at 05:40 PM, Amul Shah wrote:
 
 On 10/08/14 15:57, Andreas Tille wrote:
  On Tue, Oct 07, 2014 at 08:33:53PM -0400, Amul Shah wrote:
  Andreas,
  Kindly upload fis-gtm... again.
  No - the package is not ready yet. :-(
 
  You did not addressed
 
 https://bugs.debian.org/762457
 
  which is really important to let fis-gtm migrate to testing (=future
  stable).  Please fix the copyright and make sure you allways check
 
 https://bugs.debian.org/src:fis-gtm
 
  when preparing a package.
 
 [amul:9] Thanks for those links. I didn't know there was a bug filed. I'll 
 take care of that this evening.
 

[amul:10] I committed and pushed the license update as well as commented on the 
bug. Does it matter that the bug was submitted against 6.1-000 and we are 
working on V6.2-000?

Regards,
Amul


-- 
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/1412827911.3854736.176882169.460b8...@webmail.messagingengine.com

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

2014-10-07 Thread Amul Shah

On Mon, Oct 6, 2014, at 11:12 AM, Bhaskar, K.S wrote:
 
 On 10/06/2014 07:55 AM, Thorsten Alteholz wrote:
  Hi Bhaskar,
 
  On Thu, 2 Oct 2014, Bhaskar, K.S wrote:
  [KSB] Those *openssl* files are versions of the reference
  implementation of
  the plugin compiled with #include, #if, etc. configured to call call
  OpenSSL.  They are not actually linked to OpenSSL or other libraries -
  linking happens dynamically. 
 
 [KSB2] …snip…
 
   *  Include a statement in the README that says something like: As
  dynamic
  linking by the reference implementation of the plugin to software
  such
  as cryptographic libraries that are released under non-copyleft
  licenses
  is not considered to create a derivative work, there is no
  interaction
  between the license used for GT.M and those of cryptographic
  libraries.
   *  Remove any claim of copyright from the reference implementation of
  the
  plugin (i.e., place the reference implementation in the public
  domain).
   *  Remove the precompiled versions of the reference implementation of
  the
  plugin from the distribution and include only the source of the
  plugin
  (as I noted earlier, the GT.M binary distribution includes source
  code
  for the reference implementation of the plugin).  Use the
  post-install
  script to compile the reference implementation of the plugin.
 
  Thorsten, please let me know what you think.
 
  I don't understand why you don't want to go the easy way? As you
  consider to remove the license in 2), why don't you just add the
  exception to your license text? Otherwise the last proposal would be fine.
 
 [KSB2] Adding a license exception to the COPYING file would probably
 require me to go through Legal and that may add delays that increase the
 risk of pushing us past the deadline.  However, the reference
 implementation of the plugin is just a minuscule part of GT.M, and
 removing a claim of copyright specifically to the reference
 implementation of the plugin is something that we can do easily without
 requiring approval.
 
 Would removing the claim of copyright to the reference implementation of
 the plugin solve the issue?  Thanks.
 
 Regards
 -- Bhaskar
 

Bhaskar,
As discussed, the fis-gtm package no longer includes the reference encryption 
plugin libraries. I committed those changes and fis-gtm 6.2-000 is ready for 
upload.

Andreas,
Kindly upload fis-gtm... again.

Andreas/Thorsten,
Earlier today we came up with a non-license changing way for people to use the 
reference encryption plugin libraries. If we built all of the plugins as part 
of the installation fis-gtm or another separate package. Does building at 
install time solve the distribution license conflict?

Note that the way we package GT.M today, the sources for the plugins are 
included. It's up to the end user to decide what to do with them.

thanks,
Amul


--
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/1412728433.2917772.176366109.61c05...@webmail.messagingengine.com

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

2014-10-04 Thread Amul Shah

Hi Andreas,  
  [amul:4] V6.2-000 is ready for upload!
 
 And so I did.  Thanks for your work on this

[amul:7] While we wait for the apparent licensing conflict to resolve (I don't 
understand how dynamically linking a library causes problems, but I'm no lawyer 
;), I went ahead and updated the CMakelists.txt patch to not build the 
encryption plugins that leverage OpenSSL. I also eliminated the final lintian 
warnings. I'll ensure those changes reach upstream.

[amul:7] We are once again ready for upload!

thanks, Amul


-- 
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/1412465050.1657935.175204153.3d2fa...@webmail.messagingengine.com

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

2014-09-29 Thread Amul Shah


Hi Andreas,

On 09/27/14 02:56, Andreas Tille wrote:

On Fri, Sep 26, 2014 at 11:50:28PM -0400, Amul Shah wrote:

[amul:3] These warnings made me chuckle a bit. I didn't realize that we had 
typos in our messaging from C sources. The flagging of M sources below occurred 
because of the technique we adopted to handle the DESTDIR problem.

instance1:~ lintian --display-info fis-gtm-6.2-000_6.2-000-1_amd64.deb
I: fis-gtm-6.2-000: spelling-error-in-binary 
usr/lib/x86_64-linux-gnu/fis-gtm/V6.2-000_x86_64/dse accomodate accommodate
I: fis-gtm-6.2-000: spelling-error-in-binary 
usr/lib/x86_64-linux-gnu/fis-gtm/V6.2-000_x86_64/libgtmutil.so begining 
beginning
I: fis-gtm-6.2-000: spelling-error-in-binary 
usr/lib/x86_64-linux-gnu/fis-gtm/V6.2-000_x86_64/utf8/libgtmutil.so begining 
beginning

I wonder whether you'd call this relevant for an upload or not (for me
it would be not if next upstream version would be fixed.)


[amul:4] I will see to it that this is fixed in the upstream.





I: fis-gtm-6.2-000: unused-override shared-lib-without-dependency-information 
usr/lib/*/fis-gtm/*/utf8/libgtmutil.so
N: 12 tags overridden (12 warnings)

[amul:3] The above warnings require changes to the following lines. I will fix 
these in the upstream.
sr_port/dse_shift.c:131:util_out_print(Error:  block not 
large enough to accomodate shift., TRUE);
sr_port/rsel.mpt:124:e  s strt=$$mask(beg),stop=$$mask(end) i 
$l($p(stop,$)) q:stop']strt  ; if end before begining, done
sr_port/rsel.mpt:128:   f  s r=$$search(pct) q:r]stop!'$l(r)  d save
; do begining
sr_port/xcmd.mpt:17:; Protect %XCMD's error handler by NEWing and SETing 
$ETRAP at the begining of the XECUTEd comma

Good.

There is also a

I: fis-gtm source: quilt-patch-missing-description 
upstream_build_all_encryption_libs

left which would be helpful to be fixed.


[amul:4] This is now fixed. I guess I got carried away with how smoothly this 
went. :)

[amul:4] V6.2-000 is ready for upload!

Regards,
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/542972cf.8000...@fisglobal.com

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

2014-09-26 Thread Amul Shah

Hi Andreas,

On Fri, Sep 26, 2014, at 11:20 PM, Shah, Amul wrote:
 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:3] These warnings made me chuckle a bit. I didn't realize that we had 
typos in our messaging from C sources. The flagging of M sources below occurred 
because of the technique we adopted to handle the DESTDIR problem.

instance1:~ lintian --display-info fis-gtm-6.2-000_6.2-000-1_amd64.deb 
I: fis-gtm-6.2-000: spelling-error-in-binary 
usr/lib/x86_64-linux-gnu/fis-gtm/V6.2-000_x86_64/dse accomodate accommodate
I: fis-gtm-6.2-000: spelling-error-in-binary 
usr/lib/x86_64-linux-gnu/fis-gtm/V6.2-000_x86_64/libgtmutil.so begining 
beginning
I: fis-gtm-6.2-000: spelling-error-in-binary 
usr/lib/x86_64-linux-gnu/fis-gtm/V6.2-000_x86_64/utf8/libgtmutil.so begining 
beginning
I: fis-gtm-6.2-000: unused-override shared-lib-without-dependency-information 
usr/lib/*/fis-gtm/*/utf8/libgtmutil.so
N: 12 tags overridden (12 warnings)

[amul:3] The above warnings require changes to the following lines. I will fix 
these in the upstream.
sr_port/dse_shift.c:131:util_out_print(Error:  block 
not large enough to accomodate shift., TRUE);
sr_port/rsel.mpt:124:e  s strt=$$mask(beg),stop=$$mask(end) i 
$l($p(stop,$)) q:stop']strt  ; if end before begining, done
sr_port/rsel.mpt:128:   f  s r=$$search(pct) q:r]stop!'$l(r)  d save
; do begining
sr_port/xcmd.mpt:17:; Protect %XCMD's error handler by NEWing and SETing 
$ETRAP at the begining of the XECUTEd comma

[amul:3] Note that there is an unused override. I will remove it later. 

 [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. :)

[amul:3] I think we hit a major milestone in the packaging of GT.M. Two 
packages released back to back! With one delayed by a tinsy six months. ;)

Best Regards,
Amul


-- 
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/1411789828.2018718.172305605.393af...@webmail.messagingengine.com

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

2014-09-24 Thread Amul Shah

Hi Andreas,

On 09/24/14 08:43, Andreas Tille wrote:

Hi Amul,

On Wed, Sep 24, 2014 at 12:25:22AM -0400, Amul Shah wrote:

Hi Andreas,
Thanks to your prior instructions and V6.2-000 changes eliminating the patch
series, going through this round was a quite quick.

:-)

I added two lintian warnings overrides. Please let me know if they are correct.

Lintian was able to use the crated overrides - so this is obviously fine.
I just fixed

W: fis-gtm-6.2-000: debian-changelog-line-too-long line 6

(git pull) - please note that the target distribution should be
UNRELEASED until we will release.

[amul:1] Whoops! Thanks for catching that.

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.

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.

[amul:1] The plugin directory as a symlink is only a problem when using an encrypted database with V6.1-000 and UTF-8. Since
we have V6.2-000 almost ready, I don't know if it is worth the time to fix that bug in V6.1-000 package. I'll remove the TODO
from the changelog later this evening.

On a loosely related note, I learned how to avoid signing the packages without my GPG key
(https://urldefense.proofpoint.com/v1/url?u=http://notes.timeghost.net/2009/12/build-a-binary-deb-package-without-signing.htmlk=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0Ar=KgGzFmrpr0CH7A8VRCDGC05IrYOn9XWlNRvgNmiK%2BUg%3D%0Am=suSYh9PBJI4AnykXR8LT0MXOo4laSsqYvvlWactd2zQ%3D%0As=eb46e5a0552dcec80118381e87eda2e691ead9d6001bd2edd592f889d46e1764).
You may recall this was my stumbling block for V6.0-003.
git-buildpackage --git-builder=debuild -i -us -uc

Yup - I should have mentioned this, sorry.

Kind regards and thanks for your work on this

Andreas.

[amul:1] No worries. I learned enough looking for the answers to my problems.

thanks, Amul

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

2014-09-23 Thread Amul Shah

Hi Andreas,
Thanks to your prior instructions and V6.2-000 changes eliminating the patch 
series, going through this round was a quite quick.

I added two lintian warnings overrides. Please let me know if they are correct.

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

On a loosely related note, I learned how to avoid signing the packages without 
my GPG key 
(http://notes.timeghost.net/2009/12/build-a-binary-deb-package-without-signing.html).
 You may recall this was my stumbling block for V6.0-003.
  git-buildpackage --git-builder=debuild -i -us -uc

thanks,
Amul


-- 
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/1411532722.503536.171076653.20fbb...@webmail.messagingengine.com

Re: Updating the fis-gtm package to V6.1-000

2014-09-21 Thread Amul Shah

Hi Andreas,

On Sep 21, 2014, at 5:21 PM, Andreas Tille andr...@an3as.eu wrote:

 Hi Amul,
 
 On Fri, Sep 19, 2014 at 09:25:03AM -0400, Amul Shah wrote:
 I do not see why it should be a goal to avoid postinst/prerm scripts.  I
 personally have not dealt with similar problems but if I would need to I
 would have a look how openjdk, python or gcc are solving this issue.  In
 any case you can always consult debian-ment...@lists.debian.org if you
 might face problems to apply the technique used in these packages for
 fis-gtm.
 [amul:8] Since V6.2-000 was just release, I'm skipping this feature for the 
 V6.1-000 package.
 
 Sounds very reasonable.
 
 Multiarch is the way to go.
 [amul:8] I implemented this option. I was surprised by how little work was 
 actually required.
 
 :-)
 The tools are quite nifty.
 
 [amul:8] Could you look over my work when you have some time.
 Everything works as I think it should, which means the work is only
 as good as I think. ;) I think that we are ready to upload V6.1-000.
 
 I uploaded after fixing some lintian overrides.  Thanks for your work on
 this package.

[amul:9] Thanks for the fixes. I’ll read through to understand what I missed.


 
 [amul:8] I hope to get the V6.2-000 packing done by the end of the
 month. I know this will result in overlapping packages, but I would
 very much like to have the work for V6.1-000 result in a package.
 
 I think it would be great to have V6.2-000 in the next 2-3 

[amul:9] You should see the thread with V6.2-000 in the subject shortly.

thanks,
Amul


--
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/093ce889-bb03-46e8-9b9c-94155b392...@amulz.com

Re: Updating the fis-gtm package to V6.1-000

2014-09-19 Thread Amul Shah

Hi Andreas,

On 09/11/14 16:46, Andreas Tille wrote:

Hi Amul,

On Thu, Sep 11, 2014 at 03:30:18PM -0400, Amul Shah wrote:

[amul:7] To manage the default current link, /opt/fis-gtm/current,
debian/rules includes a override_dh_link target. We would like to
let users install GT.M version 6.0-003 and V6.1-000 concurrently.
Any ideas on achieving a current link without using a
postinst/prerm script?

I do not see why it should be a goal to avoid postinst/prerm scripts. I
personally have not dealt with similar problems but if I would need to I
would have a look how openjdk, python or gcc are solving this issue. In
any case you can always consult debian-ment...@lists.debian.org if you
might face problems to apply the technique used in these packages for
fis-gtm.

[amul:8] Since V6.2-000 was just release, I'm skipping this feature for the
V6.1-000 package.

[amul:7] To install both 32bit and 64it versions of GT.M on the same
machine, we are considering going with two separate packages or
multiarch. What are your thoughts on separate packages vs multiarch?
If I read everything correctly, the ia32-libs model is being
replaced with multiarch.

Multiarch is the way to go.

[amul:8] I implemented this option. I was surprised by how little work was
actually required.

[amul:8] Could you look over my work when you have some time. Everything works as I think it should, which means the work is
only as good as I think. ;) I think that we are ready to upload V6.1-000.

[amul:8] I hope to get the V6.2-000 packing done by the end of the month. I know this will result in overlapping packages, but I
would very much like to have the work for V6.1-000 result in a package.

thanks,
Amul

Re: Updating the fis-gtm package to V6.1-000

2014-09-02 Thread Amul Shah

Hi Andreas,
I'm putting two threads back in one place. Look for [amul:6] below. The mail
ends with the current list of TODOs.

On 09/01/14 04:04, Andreas Tille wrote:

Hi Amul,

On Fri, Aug 29, 2014 at 08:14:03AM -0400, Amul Shah wrote:

[amul:4] You asked in another mail if port 22 is blocked and it is. We have
tools for allowed out-bound SSH connections but they don't work for
git.debian.org. I'm guessing that host is disallowed for port 22 access.

This is what I expected. There are ways to use different ports
(preferably 443) but this is not really a packaging topic. If you can
deal with this somehow we could take this issue as settled - otherwise
we should discuss in a separate thread.

Kind regards

Andreas.

[amul:6] Consider it closed. I'll search for ways around this. Consider this
closed.

On 09/01/14 04:05, Andreas Tille wrote:

Hi Amul,

On Fri, Aug 29, 2014 at 10:15:07AM -0400, Amul Shah wrote:

[amul:5] I've surmounted the above issue. I don't completely follow everything, but I
reverted the commit that merged the upstream (this is branch that existed
only in my local copy as opposed to the branch from Alioth) and then re-ran git
import-orig --pristin-tar. The build is in progress. I expect it to bomb out on the GPG
issue (the keys are not on my corp laptop, most likely never will be).

Well, you could create a fake key if this becomes boring to you.

Thanks for keeping us updated

Andreas.

[amul:6] It works! :-) I returned this morning (Monday was a holiday in the US) to find git-buildpackage asking for the key's
password. Entered it and packages were created!

[amul:6] TODOs:
- CMakeLists.txt for V6.1-000 does not build the encryption libraries. The builds work, but I need to (a) test the result, (b)
create the patch for the debian package, (c) carry the build changes forward to the upstream release and lastly, (d) update the
source README.

- Fix the issue where the /opt/fis-gtm/current link points to the 32bit version
of GT.M for the 64bit install
- Allow i386 and x86_64 packages to coexist. Currently the packages conflict. Also ensure that users can install multiple GT.M
versions.

[amul:6] I'm working on the top bullet right now. I will follow up with
questions - after searching :) - for the last two.

Best Regards,
Amul

Re: Updating the fis-gtm package to V6.1-000

2014-08-29 Thread Amul Shah

Hi Andreas,

On Thu, Aug 28, 2014, at 02:09 AM, Andreas Tille wrote:

[amul:3] The HTML doc link above indicated going to the initial source
import. I tried that (see the bit about COMMIT_ID), but the merge resulted
in numerous conflicts. I fired up gitk and saw prior upstream commits had
already chained off the initial source import until the upstream/6.0-003. I
used the commit ID of the upstream/6.0-003 below.

git clone ssh://git.debian.org/git/debian-med/fis-gtm.git fis-gtm-debmed.git
cd fis-gtm-debmed.git
git branch upstream d883233f4018839ce9f3da6faa57a5de8e2de98f
git-import-orig --pristine-tar ~/Downloads/fis-gtm-V6.1-000.tar.gz -u
6.1-000
commit
dch -v 6.1-000
commit
rm -rf .pc

While `rm -rf .pc` is sensible before commiting you should make sure
that you do not forget `quilt pop -a` before.

[amul:4] I check git status -s before moving forward.

[amul:3] I ended up hitting the same error that stopped me in my tracks
last time. Here's the error. I'll try to correct it tomorrow.

Finished running lintian.
Now signing changes and any dsc files...
signfile fis-gtm_6.1-000.dsc Amul Shah amul.s...@fisglobal.com
gpg: directory `/home/shaha/.gnupg' created
gpg: new configuration file `/home/shaha/.gnupg/gpg.conf' created
gpg: WARNING: options in `/home/shaha/.gnupg/gpg.conf' are not yet active
during this run
gpg: keyring `/home/shaha/.gnupg/secring.gpg' created
gpg: keyring `/home/shaha/.gnupg/pubring.gpg' created
gpg: skipped Amul Shah amul.s...@fisglobal.com: secret key not
available
gpg: /tmp/debsign.BbZPAaF6/fis-gtm_6.1-000.dsc: clearsign failed: secret
key not available
debsign: gpg error occurred! Aborting
debuild: fatal error at line 1271:
running debsign failed

Well, do you have a valid GPG key? If not please create one (I hope
there are pointers in new maintainer guide - if not a web search like
site:debian.org create gpg key
will uncover reasonable docs.

[amul:4] The regular docs were good.

[amul:3] Where I am right now: I committed my changes, but could not test
them. If someone else could give it a try that would be a great help. I
also have a git push error that I don't understand. I try doing some more
searches tomorrow.

To give a short summary:

0. create gpg key
1. gbp-clone ssh://git.debian.org/git/debian-med/fis-gtm.git
2. cd fis-gtm
3. git import-orig --pristine-tar new_upstream_tarball
4. dch -i
5. git commit
6. git-buildpackage
7. git push

[amul:4] This helps, thanks. I hit an error at step 6. I'm going to go search
for answers, but wanted to let you know that I am making progress.

dpkg-source: info: using source format `3.0 (quilt)'
dpkg-source: info: building fis-gtm using existing ./fis-gtm_6.1-000.orig.tar.gz
dpkg-source: error: cannot represent change to
fis-gtm/fis-gtm_6.0-003.orig.tar.gz.delta: binary file contents changed
dpkg-source: error: add fis-gtm_6.0-003.orig.tar.gz.delta in
debian/source/include-binaries if you want to store the modified binary in the
debian tarball
dpkg-source: error: cannot represent change to
fis-gtm/fis-gtm_6.0-001.orig.tar.gz.delta: binary file contents changed
dpkg-source: error: add fis-gtm_6.0-001.orig.tar.gz.delta in
debian/source/include-binaries if you want to store the modified binary in the
debian tarball
dpkg-source: error: unrepresentable changes to source
dpkg-buildpackage: error: dpkg-source -i -I -b fis-gtm gave error exit status 2

Best Regards,
Amul

--
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/1409314443.3808090.158164749.40a4a...@webmail.messagingengine.com

Re: Updating the fis-gtm package to V6.1-000

2014-08-29 Thread Amul Shah

Hi Andreas,

On Fri, Aug 29, 2014, at 08:14 AM, Amul Shah wrote:
 On Thu, Aug 28, 2014, at 02:09 AM, Andreas Tille wrote:
   [amul:3] Where I am right now: I committed my changes, but could not test 
   them. If someone else could give it a try that would be a great help. I 
   also have a git push error that I don't understand. I try doing some more 
   searches tomorrow.
   
  To give a short summary:
  
0. create gpg key
1. gbp-clone ssh://git.debian.org/git/debian-med/fis-gtm.git
2. cd fis-gtm
3. git import-orig --pristine-tar new_upstream_tarball
4. dch -i
5. git commit
6. git-buildpackage
7. git push
 
 [amul:4] This helps, thanks. I hit an error at step 6. I'm going to go search 
 for answers, but wanted to let you know that I am making progress.
 
 dpkg-source: info: using source format `3.0 (quilt)'
 dpkg-source: info: building fis-gtm using existing 
 ./fis-gtm_6.1-000.orig.tar.gz
 dpkg-source: error: cannot represent change to 
 fis-gtm/fis-gtm_6.0-003.orig.tar.gz.delta: binary file contents changed
 dpkg-source: error: add fis-gtm_6.0-003.orig.tar.gz.delta in 
 debian/source/include-binaries if you want to store the modified binary in 
 the debian tarball
 dpkg-source: error: cannot represent change to 
 fis-gtm/fis-gtm_6.0-001.orig.tar.gz.delta: binary file contents changed
 dpkg-source: error: add fis-gtm_6.0-001.orig.tar.gz.delta in 
 debian/source/include-binaries if you want to store the modified binary in 
 the debian tarball
 dpkg-source: error: unrepresentable changes to source
 dpkg-buildpackage: error: dpkg-source -i -I -b fis-gtm gave error exit status 
 2
 

[amul:5] I've surmounted the above issue. I don't completely follow everything, 
but I reverted the commit that merged the upstream (this is branch that 
existed only in my local copy as opposed to the branch from Alioth) and then 
re-ran git import-orig --pristin-tar. The build is in progress. I expect it to 
bomb out on the GPG issue (the keys are not on my corp laptop, most likely 
never will be).

Best Regards,
Amul


-- 
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/1409321707.3840907.158208761.00b0c...@webmail.messagingengine.com

Re: [MoM] Your Git commit (Was: [fis-gtm] branch master updated (3a6c8c0 - c8316bd))

2014-08-28 Thread Amul Shah


Hi Andreas,
I apologize for the mix-up. Is there a way for me to back those changes out of 
the master branch?

I will go through the earlier mail and repeat my changes. It looks like I 
deleted my GPG keys, so I will regenerate them.

Thank you for your patience.

Regards,
Amul

On 08/28/14 02:19, Andreas Tille wrote:

Hi Amul,

as you wrote your latest commits seem to have endet up all in the master
branch which is wrong.  While we now know, that you are able to commit
(which is good) I wonder whether this might become a serious problem for
git-buildpackage in the long run.  Please try to follow the step by step
instructions I have given in my other mail.

Kind regards

  Andreas.

On Thu, Aug 28, 2014 at 04:13:53AM +, Amul Shah wrote:

This is an automated email from the git hooks/post-receive script.

tuskentower-guest pushed a change to branch master
in repository fis-gtm.

   from  3a6c8c0   Updated Standards version to 3.9.5.
new  880ee72   Imported Upstream version 6.1-000
new  e8b7885   Merge tag 'upstream/6.1-000'
new  90715ea   Patch maintenance
new  c8316bd   Update versions and changelog

The 4 revisions listed above as new are entirely new to this
repository and will be described in separate emails.  The revisions
listed as adds were already present in the repository and have only
been added to this reference.


Summary of changes:
  CMakeLists.txt |92 +-
  README |20 +-
  debian/changelog   | 7 +-
  debian/control | 9 +-
  debian/copyright   | 2 +-
  debian/patches/install_help_files.patch|14 -
  debian/patches/series  | 4 +-
  ...estdir_Refactor-object-file-source-name-storage |22 +-
  ...pport-source-to-object-compilation-in-a-DESTDIR | 4 +-
  debian/patches/up_gtm_destdir_substitution |10 +-
  debian/patches/upstream_backport_README_change |24 +
  .../upstream_backport_i586_default_32bit_linux |21 +
  sr_avms/release_name.h | 4 +-
  sr_i386/emit_code.c|   206 +-
  sr_i386/gdeerrors_ctl.c|64 +-
  sr_i386/merrors_ansi.h |35 +-
  sr_i386/merrors_ctl.c  |82 +-
  sr_i386/ttt.c  |   792 +-
  sr_linux/gtm_env_sp.csh| 3 +-
  sr_linux/release_name.h|12 +-
  sr_port/act_in_gvt.c   |37 +-
  sr_port/alias_funcs.c  | 4 +-
  sr_port/anticipatory_freeze.h  |14 +-
  sr_port/buddy_list.h   | 4 +-
  sr_port/cdbg_dump.c|29 +-
  sr_port/cdbg_dump.h| 3 +-
  sr_port/collseq.h  |13 +-
  sr_port/compiler.h |92 +-
  sr_port/compiler_ch.c  | 4 +-
  sr_port/compiler_startup.c |40 +-
  sr_port/cre_jnl_file.c |58 +-
  sr_port/cre_private_code_copy.c| 9 +-
  sr_port/create_dummy_gbldir.c  |85 +-
  sr_port/dbcertify_base_ch.c|76 +-
  sr_port/dbcertify_scan_phase.c |44 +-
  sr_port/deviceparameters.c |32 +-
  sr_port/dfa_calc.c |16 +-
  sr_port/dpgbldir.c |   117 +-
  sr_port/dpgbldir.h |14 +-
  sr_port/dse.h  |11 +-
  sr_port/dse.hlp|44 +-
  sr_port/dse_adrec.c|23 +-
  sr_port/dse_adstar.c   |13 +-
  sr_port/dse_all.c  |51 +-
  sr_port/dse_chng_bhead.c   | 7 +-
  sr_port/dse_chng_rhead.c   |13 +-
  sr_port/dse_dmp.c  | 4 +-
  sr_port/dse_f_blk.c|16 +-
  sr_port/dse_f_key.c|   108 +-
  sr_port/dse_f_reg.c|89 +-
  sr_port/dse_find_gvt.c |71 +
  sr_port/dse_getki.c|66 +-
  sr_port/dse_ksrch.c|16 +-
  sr_port/dse_over.c |16 +-
  sr_port/dse_rest.c |37 +-
  sr_port/dse_rmrec.c| 5

Re: Updating the fis-gtm package to V6.1-000

2014-08-27 Thread Amul Shah

On 08/27/14 16:46, Andreas Tille wrote:

Hi Amul,

On Wed, Aug 27, 2014 at 03:44:44PM -0400, Amul Shah wrote:

Folks,
I'm working towards updating the fis-gtm package. I have several TODOs for this:
- Incorporate the updated sources
- Refresh existing and apply new patches, quilt is just awesome
- Update the virtual package fis-gtm depends to V6.1-000
- Use the ARCH settings
(https://urldefense.proofpoint.com/v1/url?u=https://groups.google.com/d/msg/comp.lang.mumps/mH9mdI8ozQ0/n752Z_8jlJYJk=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0Ar=KgGzFmrpr0CH7A8VRCDGC05IrYOn9XWlNRvgNmiK%2BUg%3D%0Am=Gpqdn7yjtAWoCxI2Z%2FSz4JqQ68DJDvIxSgdNyq3HwK4%3D%0As=87c8999074bc2609dd6690067639fd59a3d105aa594d4222ffb18118a642bf83)
for 64bit (x86_64) and 32bit (i586) builds
- Test - I had problems with this last time and may need help

Sounds like a sensible plan.

The first question I have is what repository should I work from? For now, I
cloned

https://urldefense.proofpoint.com/v1/url?u=https://alioth.debian.org/anonscm/git/debian-med/fis-gtm.gitk=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0Ar=KgGzFmrpr0CH7A8VRCDGC05IrYOn9XWlNRvgNmiK%2BUg%3D%0Am=Gpqdn7yjtAWoCxI2Z%2FSz4JqQ68DJDvIxSgdNyq3HwK4%3D%0As=648d8cfbb56d7fbb08e87c29139afbec8be4c4de76c0f7440d7a9f55d9778557

That's annonymous. You should rather clone (or set remote origin to):

ssh://git.debian.org/git/debian-med/fis-gtm.git

Please use

git import-orig --pristine-tar new_upstream_tarball

(and nothing else) to do your first step (Incorporate the updated
sources). If you then try `git push` you will see whether you have
commit permissions.

I have keys established on alioth which I used to access the SVN repositories.

So you can

ssh git.debian.org ?

[amul:2] Looks like I can't from work. Doing it from home will be easier.

I started reading the Debian New Maintainers' Guide because I can't
remember a single thing about this process other than
git-buildpackage.

You need to tweak the debian/ dir between

git import-orig --pristine-tar

and

git-buildpackage

The bare minimum is to

dch -i

to create a new changelog entry.

Feel free to come up on this list with any question you might have.

Kind regards and thanks for caring for fis-gtm

Andreas.

[amul:2] Thanks for the pointers Andreas. I'm still working with the anon
sources. I'll fix that later tonight.

[amul:2] I read the mail about freeze dates (https://lists.debian.org/debian-devel-announce/2014/07/msg2.html), but didn't
quite understand some terms. What is the drop dead date to get fis-gtm up to date?

Best regards, Amul

Re: Updating the fis-gtm package to V6.1-000

2014-08-27 Thread Amul Shah

Hi Andreas,

On Wed, Aug 27, 2014, at 04:46 PM, Andreas Tille wrote:
 On Wed, Aug 27, 2014 at 03:44:44PM -0400, Amul Shah wrote:
  Folks,
  I'm working towards updating the fis-gtm package. I have several TODOs for 
  this:
  - Incorporate the updated sources
  - Refresh existing and apply new patches, quilt is just awesome
  - Update the virtual package fis-gtm depends to V6.1-000
  - Use the ARCH settings 
  (https://groups.google.com/d/msg/comp.lang.mumps/mH9mdI8ozQ0/n752Z_8jlJYJ)
  for 64bit (x86_64) and 32bit (i586) builds
  - Test - I had problems with this last time and may need help
 
 Sounds like a sensible plan.
  
  The first question I have is what repository should I work from? For now, I 
  cloned
  https://alioth.debian.org/anonscm/git/debian-med/fis-gtm.git
 
 That's annonymous.  You should rather clone (or set remote origin to):
 
ssh://git.debian.org/git/debian-med/fis-gtm.git
 
 Please use
 
git import-orig --pristine-tar new_upstream_tarball

[amul:3] This step took a bit of trial and error until I got it to work. I'm 
going to step through the errors so I have a record of it and if I'm doing 
something incorrectly, it can be corrected. Here's the error that I started out 
with.

instance1:~/fis-gtm-debmed.git git-import-orig --pristine-tar 
~/Downloads/fis-gtm-V6.1-000.tar.gz -u 6.1-000
gbp:error: 
Repository does not have branch 'upstream' for upstream sources. If there is 
none see
file:///usr/share/doc/git-buildpackage/manual-html/gbp.import.html#GBP.IMPORT.CONVERT
on howto create it otherwise use --upstream-branch to specify it.

[amul:3] The HTML doc link above indicated going to the initial source import. 
I tried that (see the bit about COMMIT_ID), but the merge resulted in numerous 
conflicts. I fired up gitk and saw prior upstream commits had already chained 
off the initial source import until the upstream/6.0-003. I used the commit ID 
of the upstream/6.0-003 below.

git clone ssh://git.debian.org/git/debian-med/fis-gtm.git fis-gtm-debmed.git
cd fis-gtm-debmed.git
git branch upstream d883233f4018839ce9f3da6faa57a5de8e2de98f
git-import-orig --pristine-tar ~/Downloads/fis-gtm-V6.1-000.tar.gz -u 6.1-000
  commit
dch -v 6.1-000
  commit
rm -rf .pc
mv ~/Downloads/fis-gtm-V6.1-000.tar.gz ../fis-gtm_6.1.orig.tar.gz
git-buildpackage


[amul:3] I ended up hitting the same error that stopped me in my tracks last 
time. Here's the error. I'll try to correct it tomorrow.

Finished running lintian.
Now signing changes and any dsc files...
 signfile fis-gtm_6.1-000.dsc Amul Shah  amul.s...@fisglobal.com
gpg: directory `/home/shaha/.gnupg' created
gpg: new configuration file `/home/shaha/.gnupg/gpg.conf' created
gpg: WARNING: options in `/home/shaha/.gnupg/gpg.conf' are not yet active 
during this run
gpg: keyring `/home/shaha/.gnupg/secring.gpg' created
gpg: keyring `/home/shaha/.gnupg/pubring.gpg' created
gpg: skipped Amul Shah  amul.s...@fisglobal.com: secret key not available
gpg: /tmp/debsign.BbZPAaF6/fis-gtm_6.1-000.dsc: clearsign failed: secret key 
not available
debsign: gpg error occurred!  Aborting
debuild: fatal error at line 1271:
running debsign failed
gbp:error: debuild -i -I returned 29
gbp:error: Couldn't run 'debuild -i -I'


[amul:3] When I tried to push I hit yet another problem.

instance1:~/fis-gtm-debmed.git git push
Counting objects: 1229, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (652/652), done.
Writing objects: 100% (653/653), 786.83 KiB, done.
Total 653 (delta 577), reused 0 (delta 0)
remote: Sending notification emails to: 
debian-med-com...@lists.alioth.debian.org
To ssh://git.debian.org/git/debian-med/fis-gtm.git
   3a6c8c0..c8316bd  master - master
 ! [rejected]pristine-tar - pristine-tar (non-fast-forward)
 ! [rejected]upstream - upstream (non-fast-forward)
error: failed to push some refs to 
'ssh://git.debian.org/git/debian-med/fis-gtm.git'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes (e.g. 'git pull') before pushing again.  See the
'Note about fast-forwards' section of 'git push --help' for details.
instance1:~/fis-gtm-debmed.git git pull
Already up-to-date.


[amul:3] Searches revealed some quick answers (below), but those didn't resolve 
the reject messages. I cloned into another directory and saw that my changes 
made it to the master branch. What am I doing wrong, and do I need to correct 
this?
  git pull origin upstream
  git pull origin pristine-tar

[amul:3] Where I am right now: I committed my changes, but could not test them. 
If someone else could give it a try that would be a great help. I also have a 
git push error that I don't understand. I try doing some more searches tomorrow.

Thanks for the help,
Amul


-- 
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/1409200219.3344980.157602897.6d68f

Re: Fis-gtm accepted in unstable

2013-12-21 Thread Amul Shah


Brad/Andreas,
I'll make sure this fix is applied to the upcoming release sources.

Brad,
Thanks for the fast action.

thanks,
Amul

On 12/20/13 17:09, Andreas Tille wrote:

Hi Brad,

many thanks for the patch!

On Fri, Dec 20, 2013 at 02:24:12PM -0500, Brad King wrote:

On 12/15/2013 05:38 PM, Bhaskar, K.S wrote:

Yes, thanks to all, and especially Andreas Tille, Amul Shah, Luis Ibañez and 
Brad King.

Thanks to all as well.

I've just tested installation on my Debian x86_64 system and
have discovered that zhelp does not work:

  $ sudo aptitude install fis-gtm-6.0-003
  $ export gtm_dist=/usr/lib/fis-gtm/V6.0-003_x86_64
  $ export gtmroutines=$gtm_dist/libgtmutil.so $gtm_dist
  $ $gtm_dist/mumps -dir

If this is the way you are calling mumps we should rather provide a
wrapper doing this.  WHat do you think?
  

  GTMzhelp

  Error in GT.M  help utility

I just uploaded a package with your patch which shows the help properly.
Note: As a beginner it is definitely *not* intuitively to leave this
help - I neede to interupt by ^C.
  

I downloaded the package source and built with CMake by hand.
The build tree does contain the global directory files and using
zhelp works with gtm_dist pointing at the build tree.  It does
not work after make install with gtm_dist pointing at the install
tree.  The patch below installs the .gld files and makes zhelp work
from the install tree.

Do these files need to be installed from the build tree or should
something else be creating them later?

I think the patch belongs to upstream.  Why not suggesting it to their
bug tracker?
  
Apropos bug tracker:  Next time you could rather use


 reportbug fis-gtm

which would push the problem report exactly to the right place.

Thanks again

Andreas.



_
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/52b5e243.1020...@fisglobal.com

[fis-gtm] user experience (WAS Re: Fis-gtm accepted in unstable)

2013-12-21 Thread Amul Shah

Hi Andreas,
One, sorry for sending the last email as a top post.

On 12/20/13 17:09, Andreas Tille wrote:

$ sudo aptitude install fis-gtm-6.0-003
$ export gtm_dist=/usr/lib/fis-gtm/V6.0-003_x86_64
$ export gtmroutines=$gtm_dist/libgtmutil.so $gtm_dist
$ $gtm_dist/mumps -dir
If this is the way you are calling mumps we should rather provide a
wrapper doing this. WHat do you think?

GTMzhelp

Error in GT.M help utility

I just uploaded a package with your patch which shows the help properly.
Note: As a beginner it is definitely *not* intuitively to leave this
help - I neede to interupt by ^C.

[amul:2] Could explain this a bit more? It may not be obvious but hitting return/enter a few times will exit the user from the
Topic? prompt.

[amul:2] Bhaskar spent a bit of time crafting a script called gtm in the installation directory. Assuming that GT.M is installed
in /opt/fis-gtm/V6.0-003_x8664/, execute /opt/fis-gtm/V6.0-003_x8664/gtm. Here is what I see when I use GT.M as installed from
FIS's GT.M distribution tar ball.

shaha@shaha:~/work/cmakezhelp$ /opt/fis-gtm/V6.0-003_x8664/gtm
%GDE-I-GDUSEDEFS, Using defaults for Global Directory
/home/shaha/.fis-gtm/V6.0-003_x86_64/g/gtm.gld

GDE
%GDE-I-EXECOM, Executing command file /opt/fis-gtm/V6.0-003_x8664/gdedefaults

GDE
%GDE-I-VERIFY, Verification OK

%GDE-I-GDCREATE, Creating Global Directory file
/home/shaha/.fis-gtm/V6.0-003_x86_64/g/gtm.gld
Created file /home/shaha/.fis-gtm/V6.0-003_x86_64/g/gtm.dat
%GTM-I-JNLCREATE, Journal file
/home/shaha/.fis-gtm/V6.0-003_x86_64/g/gtm.mjl created for region DEFAULT with
BEFORE_IMAGES
%GTM-I-JNLSTATE, Journaling state for region DEFAULT is now ON

GTMhalt
shaha@shaha:~/work/cmakezhelp$ /opt/fis-gtm/V6.0-003_x8664/gtm

GTMhalt
shaha@shaha:~/work/cmakezhelp$ /opt/fis-gtm/V6.0-003_x8664/gtm -help
gtm -dir[ect] to enter direct mode (halt returns to shell)
gtm -run entryref to start executing at an entryref
gtm -help / gtm -h / gtm -? to display this text

[amul:2] Should we include a getting started section in the README?

thanks,
Amul

Re: Fis-gtm accepted in unstable

2013-12-15 Thread Amul Shah

Andreas,

 On Dec 15, 2013, at 1:18 PM, Andreas Tille andr...@an3as.eu wrote:
 
 Hi,
 
 finally we have a nice Christmas gift for all people dealing with VistA:
 fis-gtm is now accepted in unstable.  

Excellent news!

Regarding fis-gtm, what work remains for the existing packaging? Off the top my 
head I know that we need man pages.

The next release will have some build changes for which I may need 
help/guidance from the good folks at Kitware. 

Thanks
Amul


--
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/d8d0442a-18e6-4a64-82ab-a7fe5eae5...@amulz.com

Re: [fis-gtm] ready for upload - needs sponsor

2013-11-24 Thread Amul Shah


On Sun, Nov 24, 2013, at 04:35 AM, Andreas Tille wrote:
 Hi Amul,
 
 On Sat, Nov 23, 2013 at 06:25:33PM -0500, Amul Shah wrote:
[snip]

[amul] [rewrote old information for brevity] FIS releases GT.M sources for 
Linux IA32 and x86_64 as one archive. The archive is named fis-gtm-version 
major-version minor-sub minor version.tar.gz and untars into a directory 
with the same name as the archive without the tar.gz.

[snip]

  The binary archives are available from the following links:
  http://sourceforge.net/projects/fis-gtm/files/GT.M-amd64-Linux/V6.0-003/
  http://sourceforge.net/projects/fis-gtm/files/GT.M-x86-Linux/V6.0-003/
  
  The source archive is available from the following link:
  http://sourceforge.net/projects/fis-gtm/files/GT.M-x86-Linux-src/V6.0-003/
  
  The same sources are also available via SourceForge CVS.

[snip]

 May be I was not reading your previous mails studiously enough but
 exactly this was the information I needed and this was totally new to
 me.  I tried to express this in my mail on month ago[1] where I used the
 word urgently in connection to clarification between 'pro' and 'src'
 because we needed to create a working watch file first.  When I
 yesterday tried to fetch the tarball with the watch file which I assumed
 to be valid I endedt up with the binary distribution.  That's why I was
 wondering whether you were assuming that we would package the binaries
 ...

[amul] Understood.

  With respect to not understanding the principles behind packaging, I would 
  say that I don’t know what the principles are. Hence no understanding. For 
  that I apologize.  My knowledge is completely adhoc.
 
 Well, in the case above probably the main principle is beeing more
 verbose in case some open questions are remaining.  In your last mail
 you have precisely answered these.  Thanks for this and sorry if I was a
 bit grumpy yesterday night.

[amul] Grumpy is fine. At least we're on the same page now. :)

  To get this going forward, do I need to push the archive somewhere as part 
  of the GIT repository? Or is it the watch file that needs fixing?
 
 The watch file is just fixed in the packaging git repository now.

[amul] Great.

[snip]

 There is one remaining question:  In the packaging git in
 
   debian/upstream-files/
 
 there are some external README files (GTM_V6.0-001_Release_Notes.html)
 which are included into the packaging as upstream changelog.  BTW,
 missing to specify the proper license for these files was finally the
 reason for the rejection.  From my point of view these files are doing
 more harm than good.  Besides this rejection it always creates manual
 work - for instance I now need to fetch the file for the new version.
 If this changelog is not included in your source tarball it is probably
 not important enough for the user to be shipped inside the binary Debian
 package.  So why not simply providing a link inside README.Debian where
 the user can find the needed information instead of creating manual
 work over and over and blowing up the debian/copyright file with an
 extra copy of GFDL?
 
 In short: Where is the download location of
 
GTM_V6.0-003_Release_Notes.html
 
 and would you agree to just provide a link to this location instead of
 the complete file?

[amul] IIRC, during the hackathon we (as in everyone present) decided to 
include the release notes since there was no change-log file. We can, as you 
suggest, simply provide a link to the release notes. We have two link options 
below.

[amul] All GT.M release notes files from V5.0-000D onward are available from 
the link below. If we place this link in the README, then we won't ever need to 
update the link in the README (yes, I am lazy :).
  http://tinco.pair.com/bhaskar/gtm/doc/articles/index.html

[amul] If the expectation is that we point to the version specific release 
note, then below is the link that we use. Could we programmatically regenerate 
the link per release using the same logic as the watch file?
  http://tinco.pair.com/bhaskar/gtm/doc/articles/GTM_Vmajor version.minor 
version-sub minor version_Release_Notes.html

[amul] With respect to missing the proper license, the web page says the 
following in the Legal section.

  Copyright © 2013 Fidelity Information Services, Inc. All Rights Reserved
  Permission is granted to copy, distribute and/or modify this document under 
the terms of the GNU Free Documentation License, Version 1.3 or any later 
version published by the Free Software Foundation; with no Invariant Sections, 
no Front-Cover Texts and no Back-Cover Texts.
  GT.M™ is a trademark of Fidelity Information Services, Inc. Other trademarks 
are the property of their respective owners.
  This document contains a description of GT.M and the operating instructions 
pertaining to the various functions that comprise the system. This document 
does not contain any commitment of FIS. FIS believes the information in this 
publication is accurate as of its publication date

Re: [fis-gtm] ready for upload - needs sponsor

2013-11-23 Thread Amul Shah

On Nov 23, 2013, at 4:48 PM, Andreas Tille andr...@an3as.eu wrote:

 Hi Amul,
 
 since my first upload was rejected due to some licensing issue of some
 documentation file we have some chance for an update.  However, I think
 you totally missed the point what we need to build the package.  As I
 said from the beginning the difference between the
 gtm_version_linux_i686_pro.tar.gz and
 gtm_version_linux_i686_src.tar.gz are not clear to me.  You claimed
 that V60003 would have been the latext fis-gtm version and I can confirm
 that there is
 
   gtm_V60003_linux_i686_pro.tar.gz
 
 available but this file does not contain the SOURCE.  The latest
 download file which really contains source files is
 
   gtm_V60001_linux_i686_src.tar.gz
 
 Amul, please pretty please, if you do not understand the principles
 behind packaging just tell us so to enable to be more verbose and to
 teach you.  Providing wrong information is not helpful and drains time
 of others.
 
 After having fixed Git now to fit ftpmasters requirements I'm idling
 until I get reliable information about the latest upstream source for
 download.  If I do not see any newer source than 60001 for download
 until Wednesday next week I will reupload this version to not loose more
 time.  As I said we can upload later new versions way more quickly once
 the package might have passed the new queue.
 
 Kind regards
 
  Andreas.

[snip]

Hi Andreas,
Getting rejected has some benefits. :)

To clarify, the GT.M binary archive has never shipped with the sources. 
Previously, we uploaded to SourceForge two archives per platform, one for the 
binaries and one for the sources. FIS releases GT.M as open source on VMS and 
Linux IA32 and x86_64. As part of the after hackathon (many thanks to Luis, 
Brad and Yaroslav for their help then and afterwards) todo items, I merged all 
sources into one unified tar archive containing the sources for Linux (IA32 and 
x86_64) and VMS.

I also renamed the archive to use fis-gtm-version major-version minor-sub 
minor version.tar.gz which unpacked into a directory with the same name as the 
archive without the tar.gz. Previously the archive untarred to the current 
working directory which meant that someone had to create the target directory 
for the sources, change directory into it and untar the archive.

The binary archives are available from the following links:
http://sourceforge.net/projects/fis-gtm/files/GT.M-amd64-Linux/V6.0-003/
http://sourceforge.net/projects/fis-gtm/files/GT.M-x86-Linux/V6.0-003/

The source archive is available from the following link:
http://sourceforge.net/projects/fis-gtm/files/GT.M-x86-Linux-src/V6.0-003/

The same sources are also available via SourceForge CVS.

I have a strong feeling that I’m not saying anything new to you.

With respect to not understanding the principles behind packaging, I would say 
that I don’t know what the principles are. Hence no understanding. For that I 
apologize.  My knowledge is completely adhoc.

To get this going forward, do I need to push the archive somewhere as part of 
the GIT repository? Or is it the watch file that needs fixing?

Is FIS expected to ship binaries and sources in the same archive for Debian 
packaging?

thanks,
Amul




--
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/840eecc8-b7ca-4c88-8290-3a80c3a4b...@amulz.com

Re: [fis-gtm] ready for upload - needs sponsor

2013-10-24 Thread Amul Shah


 
 I'm still working on recollecting where I left off.
 
 Please be as verbose as possible about any problem you might face.  Luis
 mentioned some login problems (which I do not remember).  Just let us
 know any hurdle you need to take.

Hi Andreas,
Well, I have no clue as to where I left off. :( It took me a bit to find my GIT 
debmed workspace.

Apparently I was sitting on a commit for V6.0-002. I merged my changes with 
yours and bumped the version to V6.0-003 in debian/control and 
debian/get-orig-source. Please take a look.

I don't fully grasp how the watch file works, but that URL looks wrong. This is 
the URL that get-orig-source uses:
  
http://sourceforge.net/projects/fis-gtm/files/GT.M-x86-Linux-src/${PKGVERSION}/fis-gtm-${PKGVERSION}.tar.gz

get-orig-source is a script that Luis gave me. The watch file from my branch 
seemed to use that script.

If it helps, the  SourceForge CVS repo is up to date.

I have not tried to do a build yet, because I don't remember how to do it. 
Apparently it's so drop dead easy that I didn't bother to leave myself any 
notes.

thanks,
Amul


--
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/ced87f6a-d39f-47ca-9e70-85a9c89ba...@amulz.com

Re: [fis-gtm] ready for upload - needs sponsor

2013-10-22 Thread Amul Shah

Thanks for picking up my slack Andreas. I am in fact quite swamped with work. 
Did you upload from Git or did you upload from SVN? Did you commit your changes?

While I have new man pages. Any new user to GT.M is always going to have a 
steep learning curve.

Luis, thanks for getting us started with a README. 

If I recall correctly, the last version of GTM in git is V6.0-002. I will 
upgrade to latest version tonight.

Amul


 On Oct 22, 2013, at 5:18 PM, Luis Ibanez luis.iba...@kitware.com wrote:
 
 Hi Andreas,
 
 Many thanks for moving forward with the package,
 and doing the clean up and upload.
 
 I'm sure that Amul remains interested, and he is most likely 
 swamped in day-to-day work.
 
 We are happy at Kitware to help move the package forward.
 
 In particular, I'll be happy to help test the package, especially with
 the classes that I'm teaching at Rensselaer Polytechnic and at 
 SUNY Albany, where we are introducing MUMPS in the curriculum.
 
 
 I can start by writing the:
 
   README.debian
 
 
 This is in fact related to the several M/MUMPS tutorials that we
 have been preparing and delivering at RPI and SUNY in the past
 two years:
 
 http://www.opensourcesoftwarepractice.org/M-Tutorial/
 http://www.opensourcesoftwarepractice.org/OSDB-Tutorial/M/index.html
 
 both of them hosted in Github:
 
 https://github.com/SUNY-Albany-CCI/open-source-databases-tutorial
 https://github.com/SUNY-Albany-CCI/M-Tutorial
 
 --
 
 Looking at:
 http://www.debian.org/doc/manuals/maint-guide/dother.en.html#readme
 It seems like I should add it to the debian directory in the SVN repository.
 
 I'll start doing that right away.
 
 It will essentially contain this environment configuration:
 http://www.opensourcesoftwarepractice.org/OSDB-Tutorial/M/Installation.html#environment
 that a user should do, just after installing the package.
 
 
 It is very exciting to see the package moving forward in the pipeline.
 
 
  Many Thanks
 
 
   Luis
 
 
 
 On Tue, Oct 22, 2013 at 4:28 PM, Andreas Tille andr...@fam-tille.de wrote:
 Hi Luis,
 
 since for me no answer (in this case no answer from Amul) means: Just
 do whatever you want to do I decided to do something and polished the
 package lintian clean and decided to upload.  The package is from my
 point technically at some level that can be thrown at the users for
 testing and considering that ftp new queue currently takes some time we
 might have something to throw at a dedicated user base perhaps in
 November.  This at least fits my planed timing even if I'm not happy
 documentation wise.s
 
 The package is IMHO a horror for the uneducated user (without any first
 entry documentation like a README.Debian and things like this) and there
 is even no command you can start straight from /usr/bin.  This is kind
 of very untypical but proably fis-gtm is an untypical package in itself.
 We *really* need to trust on the thorough checking of the package from
 people from kitware (or other fis-gtm developers) once it arrives in
 unstable just to make sure that it really does what it is expected to
 do.  Currently the upload was the only option I have seen to push things
 reasonably forward.
 
 I hope this is in you interest.
 
 Kind regards
 
Andreas.
 
 
 On Thu, Oct 17, 2013 at 10:53:05AM -0400, Luis Ibanez wrote:
  Hi Amul,
 
 
  Just to second Andreas,
 
 
  Please note that we at Kitware will be happy
  to help move the package forward.
 
  For example, if a Hackathon can help,
  we will be glad to put one together.
 
 
   Best,
 
 
   Luis
 
 --
 http://fam-tille.de

Re: [fis-gtm] ready for upload - needs sponsor

2013-10-22 Thread Amul Shah

Hi Andreas,
I checked my directories and I was using SVN and not GIT.

SourceForge, the upstream repo, is at V6.0-003. debmed's SVN repo is at 
V6.0-001.

I'm still working on recollecting where I left off.

thanks,
Amul


On Oct 22, 2013, at 7:25 PM, Amul Shah a...@amulz.com wrote:

 Thanks for picking up my slack Andreas. I am in fact quite swamped with work. 
 Did you upload from Git or did you upload from SVN? Did you commit your 
 changes?
 
 While I have new man pages. Any new user to GT.M is always going to have a 
 steep learning curve.
 
 Luis, thanks for getting us started with a README. 
 
 If I recall correctly, the last version of GTM in git is V6.0-002. I will 
 upgrade to latest version tonight.
 
 Amul
 
 
 On Oct 22, 2013, at 5:18 PM, Luis Ibanez luis.iba...@kitware.com wrote:
 
 Hi Andreas,
 
 Many thanks for moving forward with the package,
 and doing the clean up and upload.
 
 I'm sure that Amul remains interested, and he is most likely 
 swamped in day-to-day work.
 
 We are happy at Kitware to help move the package forward.
 
 In particular, I'll be happy to help test the package, especially with
 the classes that I'm teaching at Rensselaer Polytechnic and at 
 SUNY Albany, where we are introducing MUMPS in the curriculum.
 
 
 I can start by writing the:
 
   README.debian
 
 
 This is in fact related to the several M/MUMPS tutorials that we
 have been preparing and delivering at RPI and SUNY in the past
 two years:
 
 http://www.opensourcesoftwarepractice.org/M-Tutorial/
 http://www.opensourcesoftwarepractice.org/OSDB-Tutorial/M/index.html
 
 both of them hosted in Github:
 
 https://github.com/SUNY-Albany-CCI/open-source-databases-tutorial
 https://github.com/SUNY-Albany-CCI/M-Tutorial
 
 --
 
 Looking at:
 http://www.debian.org/doc/manuals/maint-guide/dother.en.html#readme
 It seems like I should add it to the debian directory in the SVN repository.
 
 I'll start doing that right away.
 
 It will essentially contain this environment configuration:
 http://www.opensourcesoftwarepractice.org/OSDB-Tutorial/M/Installation.html#environment
 that a user should do, just after installing the package.
 
 
 It is very exciting to see the package moving forward in the pipeline.
 
 
  Many Thanks
 
 
   Luis
 
 
 
 On Tue, Oct 22, 2013 at 4:28 PM, Andreas Tille andr...@fam-tille.de wrote:
 Hi Luis,
 
 since for me no answer (in this case no answer from Amul) means: Just
 do whatever you want to do I decided to do something and polished the
 package lintian clean and decided to upload.  The package is from my
 point technically at some level that can be thrown at the users for
 testing and considering that ftp new queue currently takes some time we
 might have something to throw at a dedicated user base perhaps in
 November.  This at least fits my planed timing even if I'm not happy
 documentation wise.s
 
 The package is IMHO a horror for the uneducated user (without any first
 entry documentation like a README.Debian and things like this) and there
 is even no command you can start straight from /usr/bin.  This is kind
 of very untypical but proably fis-gtm is an untypical package in itself.
 We *really* need to trust on the thorough checking of the package from
 people from kitware (or other fis-gtm developers) once it arrives in
 unstable just to make sure that it really does what it is expected to
 do.  Currently the upload was the only option I have seen to push things
 reasonably forward.
 
 I hope this is in you interest.
 
 Kind regards
 
Andreas.
 
 
 On Thu, Oct 17, 2013 at 10:53:05AM -0400, Luis Ibanez wrote:
  Hi Amul,
 
 
  Just to second Andreas,
 
 
  Please note that we at Kitware will be happy
  to help move the package forward.
 
  For example, if a Hackathon can help,
  we will be glad to put one together.
 
 
   Best,
 
 
   Luis
 
 --
 http://fam-tille.de

Re: [fis-gtm] ready for upload - needs sponsor

2013-04-11 Thread Amul Shah

Hi Yaroslav,
Thanks for checking in. We're in the run up to releasing V6.0-002 so I haven't 
done anything recently. Once the release is out, I have a few todos for final 
packaging.

Amul

On Apr 11, 2013, at 8:52 AM, Yaroslav Halchenko deb...@onerussian.com wrote:

 How is it going?  so close to the finish line -- can't give up! ;)
 
 On Fri, 08 Mar 2013, Karsten Hilbert wrote:
 
 On Fri, Mar 08, 2013 at 10:06:57PM +0100, Andreas Tille wrote:
 
 3. In MUMPS its ZHELP. :) I don't think we can help with MUMPS per
 se, but we will give enough for point 2 above to get someone
 started.
 
 That's fine.  I will not try to be too picky - just to give you some
 feeling what users of Debian packages might expect.
 
 A minimal
 
/usr/share/doc/fis-gtm/README(.Debian)
 
 might contain that and how to run ZHELP...
 
 Karsten
 -- 
 Yaroslav O. Halchenko
 http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org
 Senior Research Associate, Psychological and Brain Sciences Dept.
 Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
 Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
 WWW:   http://www.linkedin.com/in/yarik
 
 
 -- 
 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/20130411125217.gj5...@onerussian.com
 


--
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/b7589406-f55b-4f3e-b868-e8bdbb084...@amulz.com

Re: [fis-gtm] ready for upload - needs sponsor

2013-03-08 Thread Amul Shah


Hi Andreas,

On 03/07/2013 04:33 PM, Andreas Tille wrote:

Hi Amul,

On Thu, Mar 07, 2013 at 02:10:15PM -0500, Amul Shah wrote:

Hi Andreas,
Aside from my debsign issues, the package is ready.

The latest git log is

commit 95792777b89fe78bae3c9a69e001159a86d2318b
Author: Amul Shahamul.s...@fisglobal.com
Date:   Tue Feb 19 11:48:00 2013 -0500

 Remove files per the DebMed package policy


[amul:2] That's what I have locally.


So I assume you did not pushed everything because there are some
remaining lintian issues which at least I would like to be fixed
some of them - specifically the one marked 'E:':

  $ lintian fis-gtm_6.0-001-1_amd64.changes
I: fis-gtm-6.0-001: spelling-error-in-binary 
usr/lib/fis-gtm/V6.0-001_x86_64/dse accomodate accommodate
E: fis-gtm-6.0-001: unstripped-binary-or-object 
usr/lib/fis-gtm/V6.0-001_x86_64/plugin/gtmcrypt/maskpass
W: fis-gtm-6.0-001: non-standard-dir-perm usr/lib/fis-gtm/V6.0-001_x86_64/ 0655 
!= 0755
W: fis-gtm-6.0-001: setuid-binary usr/lib/fis-gtm/V6.0-001_x86_64/gtmsecshr 
4755 root/root
W: fis-gtm-6.0-001: non-standard-dir-perm 
usr/lib/fis-gtm/V6.0-001_x86_64/gtmsecshrdir/ 0500 != 0755
W: fis-gtm-6.0-001: setuid-binary 
usr/lib/fis-gtm/V6.0-001_x86_64/gtmsecshrdir/gtmsecshr 4500 root/root
W: fis-gtm-6.0-001: executable-is-not-world-readable 
usr/lib/fis-gtm/V6.0-001_x86_64/gtmsecshrdir/gtmsecshr 4500
W: fis-gtm-6.0-001: non-standard-dir-perm 
usr/lib/fis-gtm/V6.0-001_x86_64/plugin/gtmcrypt/ 0655 != 0755
W: fis-gtm-6.0-001: non-standard-dir-perm 
usr/lib/fis-gtm/V6.0-001_x86_64/plugin/o/ 0655 != 0755
W: fis-gtm-6.0-001: non-standard-dir-perm 
usr/lib/fis-gtm/V6.0-001_x86_64/plugin/o/utf8/ 0655 != 0755
W: fis-gtm-6.0-001: non-standard-dir-perm 
usr/lib/fis-gtm/V6.0-001_x86_64/plugin/r/ 0655 != 0755
I: fis-gtm-6.0-001: package-contains-empty-directory 
usr/lib/fis-gtm/V6.0-001_x86_64/plugin/o/utf8/
I: fis-gtm-6.0-001: package-contains-empty-directory 
usr/lib/fis-gtm/V6.0-001_x86_64/plugin/r/
W: fis-gtm-6.0-001: script-not-executable usr/lib/fis-gtm/V6.0-001_x86_64/gtm
W: fis-gtm-6.0-001: script-not-executable 
usr/lib/fis-gtm/V6.0-001_x86_64/gtmbase
W: fis-gtm-6.0-001: script-not-executable 
usr/lib/fis-gtm/V6.0-001_x86_64/plugin/gtmcrypt/add_db_key.sh
W: fis-gtm-6.0-001: script-not-executable 
usr/lib/fis-gtm/V6.0-001_x86_64/plugin/gtmcrypt/encrypt_sign_db_key.sh
W: fis-gtm-6.0-001: script-not-executable 
usr/lib/fis-gtm/V6.0-001_x86_64/plugin/gtmcrypt/gen_keypair.sh
W: fis-gtm-6.0-001: script-not-executable 
usr/lib/fis-gtm/V6.0-001_x86_64/plugin/gtmcrypt/gen_sym_hash.sh
W: fis-gtm-6.0-001: script-not-executable 
usr/lib/fis-gtm/V6.0-001_x86_64/plugin/gtmcrypt/gen_sym_key.sh
W: fis-gtm-6.0-001: script-not-executable 
usr/lib/fis-gtm/V6.0-001_x86_64/plugin/gtmcrypt/import_and_sign_key.sh
W: fis-gtm-6.0-001: script-not-executable 
usr/lib/fis-gtm/V6.0-001_x86_64/plugin/gtmcrypt/pinentry-gtm.sh
W: fis-gtm-6.0-001: script-not-executable 
usr/lib/fis-gtm/V6.0-001_x86_64/plugin/gtmcrypt/show_install_config.sh
X: fis-gtm-6.0-001: package-contains-broken-symlink 
usr/lib/fis-gtm/V6.0-001_x86_64/utf8/COPYING ../COPYING
I: fis-gtm-6.0-001: unused-override setuid-binary usr/lib/fis-gtm/*/gtmsecshr
N: 3 tags overridden (3 warnings)


[amul:2] I didn't know that I could do that! Thanks for pointing it out. When I run the same command, I see fewer things. Here's 
my lintian run with verbose specified.


9:53am [shaha@shaha:/home/shaha/debmed/testbuild/fis-gtm] lintian -v 
../fis-gtm_6.0-001-1_amd64.changes
N: Using profile debian/main.
N: Setting up lab in /tmp/temp-lintian-lab-nVooRJLTQ3 ...
N: 
N: Processing changes file fis-gtm (version 6.0-001-1, arch source all amd64) 
...
N: 
N: Processing source package fis-gtm (version 6.0-001-1, arch source) ...
N: 
N: Processing binary package fis-gtm (version 6.0-001-1, arch all) ...
W: fis-gtm: readme-debian-contains-debmake-template
N: 
N: Processing binary package fis-gtm-6.0-001 (version 6.0-001-1, arch amd64) ...
W: fis-gtm-6.0-001: setuid-binary usr/lib/fis-gtm/V6.0-001_x86_64/gtmsecshr 
4755 root/root
W: fis-gtm-6.0-001: non-standard-dir-perm 
usr/lib/fis-gtm/V6.0-001_x86_64/gtmsecshrdir/ 0500 != 0755
W: fis-gtm-6.0-001: setuid-binary 
usr/lib/fis-gtm/V6.0-001_x86_64/gtmsecshrdir/gtmsecshr 4500 root/root
W: fis-gtm-6.0-001: executable-is-not-world-readable 
usr/lib/fis-gtm/V6.0-001_x86_64/gtmsecshrdir/gtmsecshr 4500
N: 3 tags overridden (3 warnings)

[amul:2] I would say I have something that I did not commit, but I do not know 
where to look. My host is Debian 7 (aka wheezy).

[amul:2] Thoughts? Any docs or search terms that point me in the right 
direction are appreciated.

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

[fis-gtm] ready for upload - needs sponsor

2013-03-07 Thread Amul Shah


Hi Andreas,
Aside from my debsign issues, the package is ready.

thanks,
Amul


On 02/21/2013 04:28 PM, Andreas Tille wrote:

Hi Amul,

On Thu, Feb 21, 2013 at 03:49:58PM -0500, Amul Shah wrote:

Assumed you mean with released the upload to the Debian mirror:  You
just need to confirm here (on the list) that you are ready with the
package.  A sponsor (any DD in the team - in this case most probably
but not necessarily me) will check the packaging and upload.

[amul:3] That is what I mean.

OK, so the question is answered.


_
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/5138e617.4070...@fisglobal.com

[fis-gtm] git-buildpackage works until debsign

2013-02-21 Thread Amul Shah


Hi Andreas,

On 02/19/2013 03:32 PM, Andreas Tille wrote:

Assumed you mean with released the upload to the Debian mirror:  You
just need to confirm here (on the list) that you are ready with the
package.  A sponsor (any DD in the team - in this case most probably
but not necessarily me) will check the packaging and upload.


[amul:3] That is what I mean.



I did create a GPG key for myself defined for my personal email
address, not my work email address. How do others handle this? Do
you create two keys? Or do you create just one for your personal
email address?

It makes sense to have one key and attach all your e-mail addresses to
it - except you have some very specific needs. 


[amul:3] I have created a key with two email addresses and put it into my local 
keyring. However the build still fails.


Finished running lintian.
Now signing changes and any dsc files...
 signfile fis-gtm_6.0-001-1.dsc Amul Shah amul.s...@fisglobal.com
gpg: skipped Amul Shah amul.s...@fisglobal.com: secret key not available
gpg: /tmp/debsign.MfDS04bE/fis-gtm_6.0-001-1.dsc: clearsign failed: secret key 
not available
debsign: gpg error occurred!  Aborting
debuild: fatal error at line 1278:
running debsign failed
gbp:error: Couldn't run 'debuild -i -I': debuild -i -I returned 29


[amul:3] Any ideas on what is wrong? I'm using the script recommended in the 
instructions.

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/51268876.5020...@fisglobal.com

[fis-gtm] git-buildpackage is working

2013-02-19 Thread Amul Shah

FYI,
Thanks to questions from Luis and Andreas, I have moved forward. :) My first mistake was not using sudo to start
git-buildpacakge. I dropped cowbuilder and the build works. But, you knew there was one, I cannot complete the build because I
don't have GPG keys!

This is how the build log finishes.
---
Finished running lintian.
Now signing changes and any dsc files...
signfile fis-gtm_6.0-001-1.dsc Amul Shah amul.s...@fisglobal.com
gpg: skipped Amul Shah amul.s...@fisglobal.com: secret key not available
gpg: /tmp/debsign.lPOutHj4/fis-gtm_6.0-001-1.dsc: clearsign failed: secret key
not available
debsign: gpg error occurred! Aborting
---

I did create a GPG key for myself defined for my personal email address, not my work email address. How do others handle this?
Do you create two keys? Or do you create just one for your personal email address?

thanks,
Amul

On 02/18/2013 01:03 PM, Amul Shah wrote:

Hello Yaroslav,
Following the instructions that Andreas pointed to, I created a GIT repo on alioth for fis-gtm. When I try to debcheckout, I
hit an error.

---
12:41pm [shaha@shaha:/home/shaha/debmed/testbuild] debcheckout --git-track='*'
git+ssh://git.debian.org/git/debian-med/fis-gtm.git

declared git repository at git+ssh://git.debian.org/git/debian-med/fis-gtm.git
git clone git+ssh://git.debian.org/git/debian-med/fis-gtm.git fis-gtm ...
Cloning into 'fis-gtm'...
remote: Counting objects: 3115, done.
remote: Compressing objects: 100% (2005/2005), done.
remote: Total 3115 (delta 1103), reused 3111 (delta 1103)
Receiving objects: 100% (3115/3115), 4.74 MiB | 446 KiB/s, done.
Resolving deltas: 100% (1103/1103), done.
Branch pristine-tar set up to track remote branch pristine-tar from origin.
Branch upstream set up to track remote branch upstream from origin.
Use of uninitialized value $srcpkg in substitution (s///) at
/usr/bin/debcheckout line 822.
---

I found a thread with a similar error, http://lists.debian.org/debian-med/2012/10/msg00057.html, but I did push all my changes
up with git push --all --set-upstream. For instance:

---
12:42pm [shaha@shaha:/home/shaha/debmed/fis-gtm-6.0.001] git push --all
--set-upstream
Branch master set up to track remote branch master from origin.
Branch pristine-tar set up to track remote branch pristine-tar from origin.
Branch upstream set up to track remote branch upstream from origin.
Everything up-to-date
---

I can debcheckout from the repo on my machine. But when I try to use git-buildpackage, it complains about cp: cannot stat
`/var/cache/pbuilder/base.cow': No such file or directory. I guess I'm missing some setup. If so, is there a quick start
guide? Otherwise, what doc do I need to read?

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.

Re: [fis-gtm] git repo created

2013-02-19 Thread Amul Shah

Hi Andreas,

On 02/19/2013 04:43 AM, Andreas Tille wrote:

Hi Amul,

On Mon, Feb 18, 2013 at 05:12:35PM -0500, Amul Shah wrote:

Hi Andreas,
Thanks for the help. I checked the logs. The changes look fine. I removed the
*.ex files.

Thanks. If you look at the debian/README* files these also are
templates with no meaning. I guess you did tried dh_make which usually
creates those templates. In general it is a good idea to use dh_make
but I'm for myself (and for the rest of the Debian Med team) created
some more simple template that even implements part of the Debian Med
policy. So you (or anybody else) might like to try

svn://svn.debian.org/svn/debian-med/trunk/package_template

which I just tweak regarding the package name and I'm way more happy
with this than I was with dh_make.

It does help. I removed those files and compared against your template. Things look better. I realized my mistake with
git-buildpackage and sent another mail about where I am with that.

thanks,
Amul

--
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/5123aebb.2000...@fisglobal.com

Re: [fis-gtm] git-buildpackage is working

2013-02-19 Thread Amul Shah


Hi Andreas,

On 02/19/2013 01:06 PM, Andreas Tille wrote:

Hi Amul,

before I answer your question:  The policy on all lists
@lists.debian.org is to not CC the posters (except expressed
explicitly.)  So please just leave out the CCs and use the list-reply
feature of your MUA (which hopefully will have this - it 'L' in mutt)


[amul:2] Thunderbird supports that. I ignore mails not addressed to me. ;)



On Tue, Feb 19, 2013 at 11:40:59AM -0500, Amul Shah wrote:

FYI,
Thanks to questions from Luis and Andreas, I have moved forward. :)
My first mistake was not using sudo to start git-buildpacakge. I
dropped cowbuilder and the build works.

Good.  However, you finally want to use cowbuilder and so it makes sense
to get this working at some point in time.


[amul:2] Will do. After that, what is necessary for this to be released?




I did create a GPG key for myself defined for my personal email
address, not my work email address. How do others handle this? Do
you create two keys? Or do you create just one for your personal
email address?

It makes sense to have one key and attach all your e-mail addresses to
it - except you have some very specific needs.


[amul:2] Will do.

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/5123dacd.1090...@fisglobal.com

[fis-gtm] git repo created

2013-02-18 Thread Amul Shah

Hello Yaroslav,
Following the instructions that Andreas pointed to, I created a GIT repo on alioth for fis-gtm. When I try to debcheckout, I hit
an error.

---
12:41pm [shaha@shaha:/home/shaha/debmed/testbuild] debcheckout --git-track='*'
git+ssh://git.debian.org/git/debian-med/fis-gtm.git
declared git repository at git+ssh://git.debian.org/git/debian-med/fis-gtm.git
git clone git+ssh://git.debian.org/git/debian-med/fis-gtm.git fis-gtm ...
Cloning into 'fis-gtm'...
remote: Counting objects: 3115, done.
remote: Compressing objects: 100% (2005/2005), done.
remote: Total 3115 (delta 1103), reused 3111 (delta 1103)
Receiving objects: 100% (3115/3115), 4.74 MiB | 446 KiB/s, done.
Resolving deltas: 100% (1103/1103), done.
Branch pristine-tar set up to track remote branch pristine-tar from origin.
Branch upstream set up to track remote branch upstream from origin.
Use of uninitialized value $srcpkg in substitution (s///) at
/usr/bin/debcheckout line 822.
---

I found a thread with a similar error, http://lists.debian.org/debian-med/2012/10/msg00057.html, but I did push all my changes
up with git push --all --set-upstream. For instance:

thanks,
Amul

Re: [fis-gtm] git repo created

2013-02-18 Thread Amul Shah


Hi Andreas,
Thanks for the help. I checked the logs. The changes look fine. I removed the 
*.ex files.

Amul

On 02/18/2013 03:45 PM, Andreas Tille wrote:

Hi again,

I have done some slight changes to make sure that all data was taken
over from SVN and removed the SVN directory droping a README.status
file there about the svn to git migration.

Please check the commit logs.

Kind regards

   Andreas.



_
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/5122a753.4060...@fisglobal.com

Re: [fis-gtm] builds with pbuilder

2013-02-12 Thread Amul Shah

Hi Andreas,

On 02/11/2013 04:03 PM, Andreas Tille wrote:

[amul:5] Let's not wait for V6.0-002. I have a strong feeling that
we will need some deployment changes to the package that we won't
find in my simple tests. And by strong feeling, I mean that I've
been burned often enough by small deployment problems

For sure you decide here. Just go on and let us know here if you need
help. As I said before: If it turns out to be a problem I personally
would not consider the full history as a very important thing to keep.

[amul:4] Ok. I think we're ready to ship this package. What do I do now?

[amul:5] How is the following for a DEP3 compliant explanation?

---

Author: Amul Shahamul.s...@fisglobal.com
Description: FIS GT.M uses a setuid binary to facilitate multi-user access to
database shared memory

That's fine and belongs strait at the head of the patch file. (Just
have a look into patch files of other packages to see how it is used.)

FIS GT.M (hereby referred to as just GT.M) processes run with normal
UNIX user and group ids. GT.M has no database daemon that needs to
...

That's way to much for the patch description. About one paragraph is
completely sufficient. Finally it is a developer oriented information -
if more details might be needed there is a plenty of information out
there.

[amul:4] To clarify. I'm not patching the build with the lintian ignores. I'm going to commit those changes. The DEP3 compliant
patch is the commit log correct?

thanks, Amul

Re: [fis-gtm] builds with pbuilder

2013-02-11 Thread Amul Shah

On 02/08/2013 01:41 PM, Yaroslav Halchenko wrote:

On Fri, 08 Feb 2013, Amul Shah wrote:

- The next GT.M release will eliminate the dpkg-shlibdeps warnings (Yaroslav
suggested - -Wl,--as-needed)

well -- you would need to verify that with this your build still
functions properly and has all needed bindings (e.g. if plugin relies on
some library to be loaded by the main process, but main process doesn't
use those symbols -- it would have undesired effects)

if you find that those are needed -- then better to live with the
warnings ;)

[amul:4] I meant to say should eliminate and not will eliminate. :) The plan is to try both your suggestion and do my
homework to learn which binaries require what libraries. I don't like warnings.

While I'm typing up the explanation, can we get the changes tested on a Debian
build server?

pbuilder environment would be your 'Debian build server'. but you might
like to create at least two -- amd64 and i386 (--architecture arg) on
your 64bit box -- to verify build in both 32 and 64 bit mode

[amul:4] pbuilder starter amd64 and i386 builds work on my machine (Debian 6
amd64). I can see day light! :)

thanks, Amul

Re: [fis-gtm] builds with pbuilder

2013-02-11 Thread Amul Shah

Hi Andreas,

On 02/08/2013 02:00 PM, Andreas Tille wrote:

Andreas asked if we should use GIT. Yes please. How do I/we do that?

I remember Charles has given a hint to a script which does the job.
From my *personal* perspective it is fine to forget about the history
and just create a fresh Git repository as described in Debian Med policy
document. I could imagine that V6.0-002 release might be a good starting
point (if it is expected in the not so distant future) because you save
the trouble with the dirty tarball and can straight import from upstream.
But finally it is your choice to do it right now.

[amul:5] For GIT conversion, I found the following links. I'll give them a try
once we're ready to release the V6.0-001 package/
http://wiki.debian.org/Alioth/Git#Convert_a_SVN_Alioth_repository_to_Git
http://lists.debian.org/debian-med/2009/11/msg6.html

[amul:5] Let's not wait for V6.0-002. I have a strong feeling that we will need some deployment changes to the package that we
won't find in my simple tests. And by strong feeling, I mean that I've been burned often enough by small deployment problems

What remains:
- I need a DEP3 compliant explanation of the suppression of the gtmsechr setuid
and permissions.

[amul:5] Where should I put the explanation for the suppression options?

[amul:5] How is the following for a DEP3 compliant explanation?

---

Author: Amul Shah amul.s...@fisglobal.com
Description: FIS GT.M uses a setuid binary to facilitate multi-user access to
database shared memory

[description adapted from the Admin and Operations Guide]

FIS GT.M (hereby referred to as just GT.M) processes run with normal UNIX user and group ids. GT.M has no database daemon that
needs to run with elevated privileges. Process code written in M will be able to read a database file if and only if the process
has read permission for that database file, and to update that database file if and only if the process has read/write
permission for that database file.

Processes with normal user and group ids do not have adequate permissions to effect necessary GT.M interprocess communication
and cleanup after abnormal process termination. A process called gtmsecshr runs as root in order to effect the following
functionality:
- Interprocess communication, including sending SIGALARM and SIGCONT between processes where normal UNIX permissions do not
permit such signals to be sent.
- Cleanup after processes that terminate abnormally, including removing semaphores, shared memory segments, and flushing
database file headers (but not database blocks) from shared memory segments to disk.

Whenever a GT.M process lacks adequate permissions to effect any of the above operations, it automatically invokes gtmsecshr if
it is not already running.

In order to run as root, and to be invoked by a process that has normal user and group ids, the invocation chain for |gtmsecshr|
requires an executable image that is owned by root and which has the |setuid| bit turned on in its file permissions.

There are two images named gtmsecshr, one located in /usr/lib/fis-gtm/version_arch/gtmsecshr and
/usr/lib/fis-gtm/version_arch/gtmsecshrdir/gtmsecshr.

/usr/lib/fis-gtm/version_arch/gtmsecshr exists to sanitize the UNIX environment and to validate that the permissions on
/usr/lib/fis-gtm/version_arch/gtmsecshrdir and /usr/lib/fis-gtm/version_arch/gtmsecshrdir/gtmsecshr match its
expectations. The permissions expectations for each path are listed in octal notation:

4755 /usr/lib/fis-gtm/version_arch/gtmsecshr
0500 /usr/lib/fis-gtm/version_arch/gtmsecshrdir
4500 /usr/lib/fis-gtm/version_arch/gtmsecshrdir/gtmsecshr

---

Thanks, Amul

Re: [fis-gtm] builds with pbuilder

2013-02-07 Thread Amul Shah




On 02/07/2013 12:21 PM, Yaroslav Halchenko wrote:

On Thu, 07 Feb 2013, Amul Shah wrote:


Andreas/Yaroslav,
Thanks to Luis, I setup a pbuilder environment and built GT.M. There
are a few lintian warnings and some package naming oddities that I
am unsure about. How do I grab the build log, aside from using tee?

spoiled me uses git-buildpackage (could be called with --pbuilder
option) and that generates a nice .log  for me


I say package naming oddity, because the generated deb is named
fis-gtm-6.0-001_6.0-001-1_amd64.deb, where I expected to see a deb
named fis-gtm_6.0-001-1_amd64.deb.

per our discussion at kitware some time ago -- we agreed to have
versioned binary package (i.e. version in the name) to signal that per
se you can't just upgrade fis-gtm to a new major.minor version to still
access previous DB -- it needs to be migrated.  And that is why it is
better to be able to co-install 2 (or more) versions at the same
time.  I do not remember though having -001 revision in there, and
would have expected fis-gtm-6.0_6.0-001-1_amd64.deb, but I could be
wrong.


[amul:2] That -001 is the sub minor version. Our next release is going to be V6.0-002. I think we need that in there to allow 
V6.0-001 and V6.0-002 to coexist. Correct? We don't need one of those version numbers, that's for sure. Where are they coming 
from? I know one is in debian/control.




I can't find the lintian warnings in pbuidler's output, but I did see them in 
debuild's output. This is what I see in debuild:
W: fis-gtm source: changelog-should-mention-nmu
W: fis-gtm source: source-nmu-has-incorrect-version-number 6.0-001-1

are you listed in Maintainers/Uploaders as well (with identical name in
the last changelog entry signature)?


[amul:2] I'm listed as an uploader (or at least I think I am). I don't have a GPG key yet (well I did, but I forgot the 
password). My name is in both files, but the email address case is different.

 grep -i fisglobal debian/*
debian/changelog: -- Amul Shah amul.s...@fisglobal.com  Fri, 25 Jan 2013 
23:13:11 -0500
debian/control:   Amul Shah amul.s...@fisglobal.com



W: fis-gtm-6.0-001: setuid-binary usr/lib/fis-gtm/V6.0-001_x86_64/gtmsecshr 
4755 root/root
W: fis-gtm-6.0-001: non-standard-dir-perm 
usr/lib/fis-gtm/V6.0-001_x86_64/gtmsecshrdir/ 0500 != 0755
W: fis-gtm-6.0-001: setuid-binary 
usr/lib/fis-gtm/V6.0-001_x86_64/gtmsecshrdir/gtmsecshr 4500 root/root
W: fis-gtm-6.0-001: executable-is-not-world-readable 
usr/lib/fis-gtm/V6.0-001_x86_64/gtmsecshrdir/gtmsecshr 4500

I think we had discussion on those security measures -- would need to
look in emails to rehears what was our conclusion ;)


[amul:2] Sure. I'll dredge them up.





I'm not sure what nmu is.

http://wiki.debian.org/NonMaintainerUpload


[amul:2] Ah, I guess I'm not an uploader.



The flagged permissions for gtmsecshr are
what we require and check for. Do I need to suppress those warnings?

probably


[amul:2] Ok, I'll take care of them.




These are the warnings that I see in pbuilder's output:
dpkg-shlibdeps: warning: 
debian/fis-gtm-6.0-001/usr/lib/fis-gtm/V6.0-001_x86_64/plugin/libgtmcrypt.so
contains an unresolvable reference to symbol gtm_free: it's probably
a plugin
dpkg-shlibdeps: warning: 6 other similar warnings have been skipped (use -v to 
see them all)
dpkg-shlibdeps: warning: package could avoid a useless dependency if

and it is a plugin, so might rely on the main process to have the
namespace loaded for it.,.. so should be safe to ignore (not sure if
there is a way to suppress)


[amul:2] Ignoring works for me. :)



debian/fis-gtm-6.0-001/usr/lib/fis-gtm/V6.0-001_x86_64/ftok
debian/fis-gtm-6.0-001/usr/lib/fis-gtm/V6.0-001_x86_64/gtcm_server
debian/fis-gtm-6.0-001/usr/lib/fis-gtm/V6.0-001_x86_64/lke
debian/fis-gtm-6.0-001/usr/lib/fis-gtm/V6.0-001_x86_64/mumps
debian/fis-gtm-6.0-001/usr/lib/fis-gtm/V6.0-001_x86_64/mupip 
debian/fis-gtm-6.0-001/usr/lib/fis-gtm/V6.0-001_x86_64/gtcm_gnp_server
debian/fis-gtm-6.0-001/usr/lib/fis-gtm/V6.0-001_x86_64/gtcm_pkdisp
debian/fis-gtm-6.0-001/usr/lib/fis-gtm/V6.0-001_x86_64/dse
debian/fis-gtm-6.0-001/usr/lib/fis-gtm/V6.0-001_x86_64/libgtmshr.so
debian/fis-gtm-6.0-001/usr/lib/fis-gtm/V6.0-001_x86_64/gtcm_shmclean 
debian/fis-gtm-6.0-001/usr/lib/fis-gtm/V6.0-001_x86_64/gtmsecshrdir/gtmsecshr
debian/fis-gtm-6.0-001/usr/lib/fis-gtm/V6.0-001_x86_64/gtcm_play
were not linked against libncurses.so.5 (they use none of the
library's symbols)
dpkg-shlibdeps: warning: package could avoid a useless dependency if 
debian/fis-gtm-6.0-001/usr/lib/fis-gtm/V6.0-001_x86_64/plugin/libgtmcrypt.so
was not linked against libgpg-error.so.0 (it uses none of the
library's symbols)
gtm_free is provided by
debian/fis-gtm-6.0-001/usr/lib/fis-gtm/V6.0-001_x86_64/libgtmshr.so.

if those statements are correct -- you might like to adjust your CMake*
files ... but that is not critical really


[amul:2] That's the plan. I won't change the current release unless it is 
needed.




Do I need

[FIS-GTM] Packing V6.0-001 - Status Update

2013-01-25 Thread Amul Shah


I'm writing this mail so that interested parties know where this work stands.

I had a call today (2013/01/25) with Luis Ibanez and Brad King from Kitware to 
get up to speed on the packaging for GT.M (thanks!).

 * I have an account and uploaded an SSH-key so that I can checkout and commit 
(thanks to Luis)
 * Brad helped me out with a problem applying patches based off the prior GT.M 
release (thanks again)
 * I updated the changelog to reflect the latest GT.M version, V6.0-001.
 * (TODO) I am using the new patch set with the V6.0-001 sources
 * (TODO) I will convert the get-orig-source target to pull the sources from 
SourceForge

I will keep everyone apprised of my progress.

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.

Re: Any progress with FIS GT.M?

2012-07-05 Thread Amul Shah

Luis,
Thanks! Comments below as [amul:1]

On 07/04/12 14:08, Luis Ibanez wrote:
 Amul,

 Thanks for making the changes in the Git repository.

 In order to match that new version:

 1) I modified changlog to pull :  57f2d896697
 2) Removed the insertion of shebang lines from the rules file.
 3) Removed the incorrect setuid attempt from the rules file.
 4) Inserted an override_dh_fixperms in the rules file.

 Then, building with debuild, returns:

 Now running lintian...
 W: fis-gtm-5.5.000: hardening-no-relro usr/lib/fis-gtm/V5.5-000_x86_64/dse
 W: fis-gtm-5.5.000: hardening-no-fortify-functions 
 usr/lib/fis-gtm/V5.5-000_x86_64/dse
 W: fis-gtm-5.5.000: hardening-no-relro usr/lib/fis-gtm/V5.5-000_x86_64/ftok
 W: fis-gtm-5.5.000: hardening-no-fortify-functions 
 usr/lib/fis-gtm/V5.5-000_x86_64/ftok
 W: fis-gtm-5.5.000: hardening-no-relro usr/lib/fis-gtm/V5.5-000_x86_64/geteuid
 W: fis-gtm-5.5.000: hardening-no-relro 
 usr/lib/fis-gtm/V5.5-000_x86_64/gtcm_gnp_server
 W: fis-gtm-5.5.000: hardening-no-fortify-functions 
 usr/lib/fis-gtm/V5.5-000_x86_64/gtcm_gnp_server
 W: fis-gtm-5.5.000: hardening-no-relro 
 usr/lib/fis-gtm/V5.5-000_x86_64/gtcm_pkdisp
 W: fis-gtm-5.5.000: hardening-no-fortify-functions 
 usr/lib/fis-gtm/V5.5-000_x86_64/gtcm_pkdisp
 W: fis-gtm-5.5.000: hardening-no-relro 
 usr/lib/fis-gtm/V5.5-000_x86_64/gtcm_play
 W: fis-gtm-5.5.000: hardening-no-fortify-functions 
 usr/lib/fis-gtm/V5.5-000_x86_64/gtcm_play
 W: fis-gtm-5.5.000: hardening-no-relro 
 usr/lib/fis-gtm/V5.5-000_x86_64/gtcm_server
 W: fis-gtm-5.5.000: hardening-no-fortify-functions 
 usr/lib/fis-gtm/V5.5-000_x86_64/gtcm_server
 W: fis-gtm-5.5.000: hardening-no-relro 
 usr/lib/fis-gtm/V5.5-000_x86_64/gtcm_shmclean
 W: fis-gtm-5.5.000: hardening-no-fortify-functions 
 usr/lib/fis-gtm/V5.5-000_x86_64/gtcm_shmclean
 W: fis-gtm-5.5.000: hardening-no-relro 
 usr/lib/fis-gtm/V5.5-000_x86_64/gtmsecshr
 W: fis-gtm-5.5.000: hardening-no-fortify-functions 
 usr/lib/fis-gtm/V5.5-000_x86_64/gtmsecshr
 W: fis-gtm-5.5.000: hardening-no-relro 
 usr/lib/fis-gtm/V5.5-000_x86_64/gtmsecshrdir/gtmsecshr
 W: fis-gtm-5.5.000: hardening-no-fortify-functions 
 usr/lib/fis-gtm/V5.5-000_x86_64/gtmsecshrdir/gtmsecshr
 W: fis-gtm-5.5.000: hardening-no-relro 
 usr/lib/fis-gtm/V5.5-000_x86_64/libgtmshr.so
 W: fis-gtm-5.5.000: hardening-no-fortify-functions 
 usr/lib/fis-gtm/V5.5-000_x86_64/libgtmshr.so
 W: fis-gtm-5.5.000: shared-lib-without-dependency-information 
 usr/lib/fis-gtm/V5.5-000_x86_64/libgtmutil.so
 W: fis-gtm-5.5.000: hardening-no-relro usr/lib/fis-gtm/V5.5-000_x86_64/lke
 W: fis-gtm-5.5.000: hardening-no-fortify-functions 
 usr/lib/fis-gtm/V5.5-000_x86_64/lke
 W: fis-gtm-5.5.000: hardening-no-relro usr/lib/fis-gtm/V5.5-000_x86_64/mumps
 W: fis-gtm-5.5.000: hardening-no-fortify-functions 
 usr/lib/fis-gtm/V5.5-000_x86_64/mumps
 W: fis-gtm-5.5.000: hardening-no-relro usr/lib/fis-gtm/V5.5-000_x86_64/mupip
 W: fis-gtm-5.5.000: hardening-no-fortify-functions 
 usr/lib/fis-gtm/V5.5-000_x86_64/mupip
 W: fis-gtm-5.5.000: hardening-no-relro 
 usr/lib/fis-gtm/V5.5-000_x86_64/plugin/gtmcrypt/maskpass
 W: fis-gtm-5.5.000: hardening-no-fortify-functions 
 usr/lib/fis-gtm/V5.5-000_x86_64/plugin/gtmcrypt/maskpass
 W: fis-gtm-5.5.000: hardening-no-relro 
 usr/lib/fis-gtm/V5.5-000_x86_64/plugin/libgtmcrypt.so
 W: fis-gtm-5.5.000: hardening-no-fortify-functions 
 usr/lib/fis-gtm/V5.5-000_x86_64/plugin/libgtmcrypt.so
 W: fis-gtm-5.5.000: hardening-no-relro 
 usr/lib/fis-gtm/V5.5-000_x86_64/semstat2
 W: fis-gtm-5.5.000: hardening-no-fortify-functions 
 usr/lib/fis-gtm/V5.5-000_x86_64/semstat2
 W: fis-gtm-5.5.000: shared-lib-without-dependency-information 
 usr/lib/fis-gtm/V5.5-000_x86_64/utf8/libgtmutil.so
 W: fis-gtm-5.5.000: non-standard-executable-perm 
 usr/lib/fis-gtm/V5.5-000_x86_64/gtcm_run 0744 != 0755
 W: fis-gtm-5.5.000: non-standard-executable-perm 
 usr/lib/fis-gtm/V5.5-000_x86_64/gtcm_slist 0744 != 0755
 W: fis-gtm-5.5.000: setuid-binary usr/lib/fis-gtm/V5.5-000_x86_64/gtmsecshr 
 4755 root/root
 W: fis-gtm-5.5.000: non-standard-dir-perm 
 usr/lib/fis-gtm/V5.5-000_x86_64/gtmsecshrdir/ 0700 != 0755
 W: fis-gtm-5.5.000: setuid-binary 
 usr/lib/fis-gtm/V5.5-000_x86_64/gtmsecshrdir/gtmsecshr 4700 root/root
 W: fis-gtm-5.5.000: executable-is-not-world-readable 
 usr/lib/fis-gtm/V5.5-000_x86_64/gtmsecshrdir/gtmsecshr 4700
 W: fis-gtm-5.5.000: non-standard-executable-perm 
 usr/lib/fis-gtm/V5.5-000_x86_64/gtmstart 0744 != 0755
 W: fis-gtm-5.5.000: non-standard-executable-perm 
 usr/lib/fis-gtm/V5.5-000_x86_64/gtmstop 0744 != 0755
 W: fis-gtm-5.5.000: executable-not-elf-or-script 
 usr/lib/fis-gtm/V5.5-000_x86_64/gtcm_slist
 W: fis-gtm-5.5.000: executable-not-elf-or-script 
 usr/lib/fis-gtm/V5.5-000_x86_64/gtmcshrc
 W: fis-gtm-5.5.000: executable-not-elf-or-script 
 usr/lib/fis-gtm/V5.5-000_x86_64/gtmprofile
 W: fis-gtm-5.5.000: executable-not-elf-or-script 
 usr/lib/fis-gtm/V5.5-000_x86_64/gtmprofile_preV54000
 E: fis-gtm-5.5.000: shlib-with-executable-bit

Re: Any progress with FIS GT.M?

2012-07-03 Thread Amul Shah

responses as [amul:2]

On 07/02/12 22:44, Yaroslav Halchenko wrote:
 On Mon, 02 Jul 2012, Luis Ibanez wrote:
  yeap -- all executables scripts must have shebang to guarantee proper
  environment to be chosen.
I'm now inserting the shebang line in the rules file, by calling sed.
It is not pretty, but it does the trick.
 I would strongly recommend just to do these changes in upstream
 repository so they become a part of upcoming fresh orig tarball.  If
 those scripts are POSIX-shell compliant (e.g. with dash which is default
 /bin/sh on Debian systems) -- use #!/bin/sh.  If they require bash --
 #!/bin/bash (which might be a safer choice altogether).

Note that, after the change, one of the scripts get a format warning
from lintian. (must still track that one:  +1 in my TODO list).
 ;-) just change in upstream sources -- any objections Amul?
[amul:2] For the moment we'll change the upstream GIT
repo. We may have to maintain this as a patch until I
learn why the scripts don't have the shebang. I'm
guessing at least one of our supported platforms forced
us to make the files this way.

[amul:2] Going back to the original list, these are shell
env and configuration files:
 W: fis-gtm source: newer-standards-version 3.9.3 (current is 3.9.1)
 W: fis-gtm-5.5.000: executable-not-elf-or-script 
 ./usr/lib/fis-gtm/V5.5-000_x86_64/gtmprofile
 W: fis-gtm-5.5.000: executable-not-elf-or-script 
 ./usr/lib/fis-gtm/V5.5-000_x86_64/gtmprofile_preV54000
 W: fis-gtm-5.5.000: executable-not-elf-or-script 
 ./usr/lib/fis-gtm/V5.5-000_x86_64/gtmcshrc
 W: fis-gtm-5.5.000: executable-not-elf-or-script 
 ./usr/lib/fis-gtm/V5.5-000_x86_64/gtcm_slist

[amul:2] These are actual scripts that need the shebang.

 W: fis-gtm-5.5.000: executable-not-elf-or-script 
 ./usr/lib/fis-gtm/V5.5-000_x86_64/gtmstart
 W: fis-gtm-5.5.000: executable-not-elf-or-script 
 ./usr/lib/fis-gtm/V5.5-000_x86_64/gtcm_run
 W: fis-gtm-5.5.000: executable-not-elf-or-script 
 ./usr/lib/fis-gtm/V5.5-000_x86_64/gtmstop





  if they are to be sourced they should not be executable... we might
  altogether place them under /etc/fis-gtm/5.5.000/ since they sound like
  environment configuration files.  Are they supposed to be sourced by any
  fis-gtm's script? then we might like to symlink them back under
  /usr/lib/fis-gtm/V5.5-000_x86_64/
This is a question for Bhaskar.
The implications escape me...:-)
 there should be none (unless there is some obscure readlink -f logic
 inside ;) ) 

[amul:2] Seems fair enough to me. However, Bhaskar
has more experience with VistA deployments and
may offer a better suggestion when he is back from
vacation.




  most probably.  if no internal scripts/binaries rely on it to be there:
  rm after installation (in debian/rules).  If they are needed -- lintian
  override is needed with a description for that
I used the dictatorial method of deleting the COPYING file
with an entry in the rules file. Another non-pretty solution,
but yet one that does the trick...
 that one is how I would do it -- so must be correct! ;)

   W: fis-gtm-5.5.000: shlib-with-executable-stack
  usr/lib/fis-gtm/V5.5-000_x86_64/libgtmshr.so
   [amul:1] This is expected. Ignore it
  weird -- that should have been ignored since I added creation of an
  override in debian/rules... may be that old lintian did not understand
  the '*' in the file pattern... test with  a fresh one
I'll post the outputs of a fresh build.
 I hope we could avoid that ;) (i.e. it would just work ;) )


This step resets permissions to safe defaults.
In our case, we have to override the default behavior
of this stage, in order to prevent it from changing the
permissions that we have set correctly in the intermediate
installation.
Is that right ?
 sounds correct



_
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/4ff307b3.5020...@fisglobal.com

Re: Any progress with FIS GT.M?

2012-07-03 Thread Amul Shah

On 07/03/12 14:27, Andreas Tille wrote:
 On Tue, Jul 03, 2012 at 10:54:43AM -0400, Amul Shah wrote:
 We may have to maintain this as a patch until I
 learn why the scripts don't have the shebang. I'm
 guessing at least one of our supported platforms forced
 us to make the files this way.
 Just for the sake of interest: Can you please give a list of all
 supported platforms?  As far as I know for Linux it is i386 and amd64
 (in Debian jargon).  What other platforms do you support?

 Kind regards

   Andreas. 
Andreas,
From Wikipedia (http://en.wikipedia.org/wiki/GT.M#Platforms)
 GT.M is fully supported on the following platforms (in alphabetic order):

 AIX on IBM System p
 GNU/Linux on IBM System z, Itanium, x86_64 and IA-32 (x86) architectures
 HP-UX on Itanium
 Solaris on SPARC
 z/OS on IBM System z

 GT.M is also supported on the following platforms. Although bugs are fixed, 
 releases get new functionality only when the code
 changes are portable to the platforms with no extra work:

 HP-UX on HP 9000 (PA-RISC)
 OpenVMS on Alpha/AXP
 Tru64 UNIX on Alpha/AXP

 On the latter set of platforms, and on GNU/Linux on the IA-32 (x86) 
 architecture, GT.M is a 32-bit application; on all others,
 it is a 64-bit application.

 The code base for GT.M on GNU/Linux on IA-32 (x86) includes changes needed to 
 run on Cygwin on Microsoft Windows but this is
 not yet considered a supported platform.

Open source release timeline:
- FIS released the i386 version of GT.M as open source in 2001 with GT.M 
V4.2-002
- FIS released GT.M V5.0-000 for VMS and Tru64 as open source in 2005
- FIS AMD64 was added in 2010 with GT.M V5.4-000A

HTH,
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/4ff33ea1.9080...@fisglobal.com

Re: Any progress with FIS GT.M?

2012-07-03 Thread Amul Shah

Luis,
I fixed the #!/bin/sh in the scripts. I checked our CVS history and email 
archives and found that the scripts are bourne shell
scripts. The gtmstart script had a colon on the first line which giggle 
searches showed as an indicator for the Bourne shell. I
will make sure that the next release has these scripts fixed.

Testing also turned up one more missing item in CMakeLists.txt. The GT.CM 
servers needed to use the gtmexe_symbsols.exports
while linking.

Please integrate at your convenience.

Thanks,
Amul

PS: Happy 4th!

On 07/02/12 10:54, Shah, Amul wrote:
 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.



_
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/4ff36127.4090...@fisglobal.com

Re: Any progress with FIS GT.M?

2012-07-02 Thread Amul Shah

Hi Andreas,
The next official release of FIS GT.M will include the cmake build and related 
changes. However, I do not know the date or
version number of the next official release. If you have any questions about 
the GT.M release cycle, please ask Bhaskar.

There will be no official FIS GT.M V5.5-000A release. This is a source only 
release for the first Debian package of GT.M.

Luis started with the original V5.5-000 release sources. Due to problems with 
the build system, we met with the folks at Kitware
(Luis and Brad) and Yaroslav. The sources were modified to
- Use cmake for building (which added a few new source.in files)
- Add source files generated by GT.M
- Eliminate the deprecated -I- compiler option
- Fix a bug where using memcpy instead of memmove resulted in access violations

FIS, as the upstream maintainer, will ensure that the next release builds with 
cmake.

I hope that answers your question.
thanks,
Amul

On 07/02/12 12:40, Andreas Tille wrote:
 Hi Amul,

 from my perspective it looks like this:

   1. We missed the freeze data for the next Debian stable release
  (which is no big issued, just a fact).
   2. You modified some version (V5.5-000) to use cmake
   3. You are attempting to release some next version (V5.5-000A)

 Question: Will the next release V5.5-000A include the cmake build
 system?

 If the answer is yes then I would be in big favour of targeting at
 this version for the first Debian release.  I do not see any point in
 packaging unreleased version with a set of patches if we could have
 everything for free inside an official release and we are not in a hurry
 (considering 1. above).

 If the answer to the question would be no that would be a bit
 unfortunate and we should think carefully what might be the next step.

 Kind regards

   Andreas.

 On Mon, Jul 02, 2012 at 02:54:58PM +, Shah, Amul wrote:
 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/4ff1e6a8.3030...@fisglobal.com

Re: Any progress with FIS GT.M?

2012-06-29 Thread Amul Shah



On 06/29/12 05:19, Andreas Tille wrote:
 On Thu, Jun 28, 2012 at 11:02:07PM -0400, Luis Ibanez wrote:
 so I could have also a look and then
 possibly workout helper settings files under /etc/fis-gts/, and possibly
 give a final look to code-base, and upload to Debian.
 I think we are ready for this step.
 Sounds good and I would probably consider to do it before tomorrow
 evening.  While I think NEW will not be processed before the freeze we
 could use it as our internal goal.

 So please let me rephrase what needs to be done:

   1. Check out orig source using
make -f debian/rules get-orig-source
   2. Use Build stuff in SVN to build the package

 Is this correct?  If yes I'd be very happy to do this and upload.

 Question: It seems development is strongly focussed on Git.  It might
 sound natural to move the packaging also into Debian Med git.  Do you
 agree and if yes do we want to do this step before we upload or after?
 Also if yes: If you regard the history of packaging as relevant would
 you volunteer to move the packaging in SVN to Git (I'm no Git expert
 I would only follow the instructions to create a new repository)?
  
Andreas,
We chose git because that's what Luis was already using. My opinion, choose the 
repository that makes it easier to manage the
GT.M package.

As far as history goes, we can ignore everything except the changes that we 
made to the GT.M sources. I will take responsibility
of committing the sources to the final repository. Just point me to it and let 
me know what I need to do. NB I am not a Debian
developer.

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/4fedb1bc.3030...@fisglobal.com

Re: Any progress with FIS GT.M?

2012-06-27 Thread Amul Shah

BTW, Who is doing what right now? I'm working on validating the built object 
files.

I will need to run the FIS GT.M Regression Test Suite against the final Debian 
package.

thanks,
Amul

On 06/26/12 10:51, Amul Shah wrote:
 I think the CMake stuff is done. Brad and/or I (probably Brad) fixed the 
 problem described in #3 below.

 We made some fixes while switching to CMake. I'm pushing them into the 
 upstream repo.

 HTH,
 Amul

 On 06/26/12 10:33, Yaroslav Halchenko wrote:
 It was so lonely in this cold deserted thread that I have decided to
 ask:  are we done cmake-ification wise and it is just a matter of
 finishing/polishing packaging? ;-)

 or everyone is on vacation? ;)

 Cheers

 On Wed, 20 Jun 2012, Luis Ibanez wrote:

Status Update:
1) The execution permissions problem has been solved.
 (it was due to a problem with LD_LIBRARY_PATH
 and fakeroot).   Brad fixed it here:

 [1]https://github.com/luisibanez/fis-gtm/commit/8dde79ed64efebc53e4ac2dbd6c4ed0c394e5286
2)  The installed files now do not have any internal references
  to the destdir directory. (which is good news !)
   
3) We are now tracking a problem with GTMHELP.o GTMHLPD.o
The configure script compiles them, but the it deletes them,
and that prevents the help from working.
4) As far as testing goes, after installing the Debian package,
we managed to run:  helloworld.m and fibonacci.m but
have trouble running threee1nf.m.
   
We created the local database using the installed gtm,
but then, when running threeen1f.m, the program starts
and doesn't quit in the usual 30 seconds, but instead
continues running.
We will need help from
Amul and Bhaskar to figure out items (3) and (4)  :-)

_
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/4feb5f18.1000...@fisglobal.com

Re: Any progress with FIS GT.M?

2012-06-26 Thread Amul Shah

I think the CMake stuff is done. Brad and/or I (probably Brad) fixed the 
problem described in #3 below.

We made some fixes while switching to CMake. I'm pushing them into the upstream 
repo.

HTH,
Amul

On 06/26/12 10:33, Yaroslav Halchenko wrote:
 It was so lonely in this cold deserted thread that I have decided to
 ask:  are we done cmake-ification wise and it is just a matter of
 finishing/polishing packaging? ;-)

 or everyone is on vacation? ;)

 Cheers

 On Wed, 20 Jun 2012, Luis Ibanez wrote:

Status Update:
1) The execution permissions problem has been solved.
 (it was due to a problem with LD_LIBRARY_PATH
 and fakeroot).   Brad fixed it here:

 [1]https://github.com/luisibanez/fis-gtm/commit/8dde79ed64efebc53e4ac2dbd6c4ed0c394e5286
2)  The installed files now do not have any internal references
  to the destdir directory. (which is good news !)
   
3) We are now tracking a problem with GTMHELP.o GTMHLPD.o
The configure script compiles them, but the it deletes them,
and that prevents the help from working.
4) As far as testing goes, after installing the Debian package,
we managed to run:  helloworld.m and fibonacci.m but
have trouble running threee1nf.m.
   
We created the local database using the installed gtm,
but then, when running threeen1f.m, the program starts
and doesn't quit in the usual 30 seconds, but instead
continues running.
We will need help from
Amul and Bhaskar to figure out items (3) and (4)  :-)

_
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/4fe9cc81.2050...@fisglobal.com

Re: Any progress with FIS GT.M?

2012-06-20 Thread Amul Shah

Yaroslav,
 [ 92%] Generating utf8/GDE.o
 cd /tmp/buildd/fis-gtm-5.5-000+git92-g81e6aa8/obj-x86_64-linux-gnu/utf8  
 /usr/bin/cmake -D 
 gtm_dist=/tmp/buildd/fis-gtm-5.5-000+git92-g81e6aa8/obj-x86_64-linux-gnu -D 
 gtmroutines=. -D gtm_chset=UTF-8 -D gtm_icu_version=4.8 -D 
 mumps=/tmp/buildd/fis-gtm-5.5-000+git92-g81e6aa8/obj-x86_64-linux-gnu/mumps 
 -D 
 args=/tmp/buildd/fis-gtm-5.5-000+git92-g81e6aa8/obj-x86_64-linux-gnu/utf8/GDE.m
  -P /tmp/buildd/fis-gtm-5.5-000+git92-g81e6aa8/sr_unix/mumps.cmake
 %GTM-E-NONUTF8LOCALE, Locale has character encoding (ANSI_X3.4-1968) which is 
 not compatible with UTF-8 character set
[amul:1] I don't know if saw it, but I asked in a mail to Brad yesterday if 
anyone was having problems with Unicode. I have an
enhancement that hacks locale. Thank you for that blog post - which is blocked 
by the corporate proxy. :( I'll update my work
accordingly.

 I needed to install locales and configure to have en.US-UTF8 -- then it
 succeeded.  So I wonder -- if this requirement to have utf8 locale configured
 at build time could be relaxed?  otherwise I would need to check how to assure
 (if possible currently at all ;) never ran into such situation) presence of a
 utf8 local in a sanitized (! ;-) ) environment.

[amul:1] IIRC, you have to have a valid locale for libicu to do the right 
parsing. I think that our development some of our
machines already have the locale set correctly. Which would explain why neither 
Brad nor I hit NONUTF8LOCALE while doing the
UTF8 directory.

Amul



On 06/20/12 00:30, Yaroslav Halchenko wrote:
 Amul, Bhaskar -- question to you,

 testing installation in a clean chroot (using cowbuilder) it fails
 with

 -- Installing: 
 /tmp/buildd/fis-gtm-5.5-000+git92-g81e6aa8/debian/fis-gtm-5.5.000-stage1/usr/lib/fis-gtm/V5.5-000_x86_64/GDEVERIF.o
 CMake Error at cmake_install.cmake:699 (FILE):
   file INSTALL cannot find
   
 /tmp/buildd/fis-gtm-5.5-000+git92-g81e6aa8/obj-x86_64-linux-gnu/utf8/GDE.o.

 make[2]: *** [install] Error 1
 make[2]: Leaving directory 
 `/tmp/buildd/fis-gtm-5.5-000+git92-g81e6aa8/obj-x86_64-linux-gnu'
 dh_auto_install: make -j1 install 
 DESTDIR=/tmp/buildd/fis-gtm-5.5-000+git92-g81e6aa8/debian/fis-gtm-5.5.000-stage1
  AM_UPDATE_INFO_DIR=no returned exit code 2
 make[1]: *** [override_dh_auto_install] Error 29
 make[1]: Leaving directory `/tmp/buildd/fis-gtm-5.5-000+git92-g81e6aa8'

 due to apparently failed build of everything under utf8/:

 root@head2:~/fis-gtm-5.5-000+git92-g81e6aa8/obj-x86_64-linux-gnu# ls utf8/
 GDE.m GDECHANG.m  GDEEXIT.m  GDEHELP.m  GDELOCKS.m  GDEMAP.mGDEOGET.m 
   GDEPUT.m   GDERENAM.m  GDESETGD.m  GDESPAWN.m  GDEVERIF.m
 GDEADD.m  GDEDELET.m  GDEGET.m   GDEINIT.m  GDELOG.mGDEMSGIN.m  
 GDEPARSE.m  GDEQUIT.m  GDESCAN.m   GDESHOW.m   GDETEMPL.m


 due to:

 [ 92%] Generating utf8/GDE.o
 cd /tmp/buildd/fis-gtm-5.5-000+git92-g81e6aa8/obj-x86_64-linux-gnu/utf8  
 /usr/bin/cmake -D 
 gtm_dist=/tmp/buildd/fis-gtm-5.5-000+git92-g81e6aa8/obj-x86_64-linux-gnu -D 
 gtmroutines=. -D gtm_chset=UTF-8 -D gtm_icu_version=4.8 -D 
 mumps=/tmp/buildd/fis-gtm-5.5-000+git92-g81e6aa8/obj-x86_64-linux-gnu/mumps 
 -D 
 args=/tmp/buildd/fis-gtm-5.5-000+git92-g81e6aa8/obj-x86_64-linux-gnu/utf8/GDE.m
  -P /tmp/buildd/fis-gtm-5.5-000+git92-g81e6aa8/sr_unix/mumps.cmake
 %GTM-E-NONUTF8LOCALE, Locale has character encoding (ANSI_X3.4-1968) which is 
 not compatible with UTF-8 character set

 I needed to install locales and configure to have en.US-UTF8 -- then it
 succeeded.  So I wonder -- if this requirement to have utf8 locale configured
 at build time could be relaxed?  otherwise I would need to check how to assure
 (if possible currently at all ;) never ran into such situation) presence of a
 utf8 local in a sanitized (! ;-) ) environment.

 Cheers,

 On Tue, 19 Jun 2012, Luis Ibanez wrote:

Here is the status of what we have 
done with Brad this afternoon.
1) The package for fis-gtm is now building and installing 
correctly by using the following git HEAD

 [1]https://github.com/luisibanez/fis-gtm/commit/74aa25e0751a28a08202a13f9f13c79e532c29ab
 the Debian-med SVN revision 11396.
 and 
 applying to it the following patch to the git sources:
diff --git a/sr_unix/configure.gtc b/sr_unix/configure.gtc
index 7b3a604..08a83d2 100644
--- a/sr_unix/configure.gtc
+++ b/sr_unix/configure.gtc
@@ -592,7 +592,7 @@ if [ -d $plugin_gtmcrypt ]; then
 
# Install gpgagent.tab
# This is an external call table so the path to the shared library
has to be adjusted
-   echo $gtmdist/plugin/libgtmcrypt.so 
$gtmdist/$plugin/gpgagent.tab
+   echo ${gtmdist#${gtm_destdir:-}}/plugin/libgtmcrypt.so 
$gtmdist/$plugin/gpgagent.tab
cat $plugin/gpgagent.tab | sed 1d  $gtmdist/$plugin/gpgagent.tab
 
This change above probably should be setup as a patch in Debian-med SVN

Re: Any progress with FIS GT.M?

2012-06-20 Thread Amul Shah

Yaroslav,
I assume that you will take care of setting LC_ALL in the debian package build, 
correct?

Luis,
One comment down below.

On 06/20/12 15:34, Bhaskar, K.S wrote:


 On 06/20/2012 03:26 PM, Luis Ibanez wrote:

 Status Update:

 1) The execution permissions problem has been solved.
  (it was due to a problem with LD_LIBRARY_PATH
  and fakeroot).   Brad fixed it here:
 https://github.com/luisibanez/fis-gtm/commit/8dde79ed64efebc53e4ac2dbd6c4ed0c394e5286


 2)  The installed files now do not have any internal references
   to the destdir directory. (which is good news !)


 3) We are now tracking a problem with GTMHELP.o GTMHLPD.o
 The configure script compiles them, but the it deletes them,
 and that prevents the help from working.

 [KSB] On the 64-bit platform, configure should use ld to put them in the 
 shared library $gtm_dist/libgtmutil.so and then
 delete the .o files.  $gtmroutines should end in $gtm_dist/libgtmutil.so to 
 find these files.  On the 32-bit platform, no
 shared library should be built, the .o files should remain in $gtm_dist, and 
 $gtmroutines should end in $gtm_dist.

[amul] I fixed this (thanks for bringing it to our attention) and added to the 
list of fixes we need to make in the upstream.
While testing zhelp, I noticed that the global directory files were missing in 
the install directory. I fixed this.





 4) As far as testing goes, after installing the Debian package,
 we managed to run:  helloworld.m and fibonacci.m but
 have trouble running threee1nf.m.

 We created the local database using the installed gtm,
 but then, when running threeen1f.m, the program starts
 and doesn't quit in the usual 30 seconds, but instead
 continues running.

 [KSB] Did you source the gdedefaults file with GDE when you created the 
 database, or did you just exit from GDE and use its
 default values?  If the latter, the values for database key and record size 
 may not be large enough for threeen1f.  In this
 case, the child processes probably errored out leaving the parent processing 
 waiting for ever (it's a demo/test program, not
 production grade application code).  Check for non-empty *.mjo and *.mje 
 files, which are the stdout/stderr of the child
 processes.

 Regards
 -- Bhaskar



 We will need help from
 Amul and Bhaskar to figure out items (3) and (4)  :-)


Luis


 -- 
 GT.M - Rock solid. Lightning fast. Secure. No compromises.

_
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: Any progress with FIS GT.M?

2012-06-19 Thread Amul Shah



On 06/19/12 12:41, Yaroslav Halchenko wrote:
 On Tue, 19 Jun 2012, Amul Shah wrote:

  chmod: cannot access `gtmcrypt_ref.c': No such file or directory
  chmod: cannot access `gtmcrypt_ref.h': No such file or directory
  chmod: cannot access `gtmcrypt_interface.h': No such file or directory
  chmod: cannot access `gtmxc_types.h': No such file or directory
  chmod: cannot access `maskpass.c': No such file or directory
  chmod: cannot access `gtmcrypt_dbk_ref.c': No such file or directory
  ...
  I guess they shouldn't just be ignored, right?  but those .c's are the
  original sources which aren't installed with the stage1 installation --
  is that just some legacy pieces in configure or am I missing smth?
[amul:1] I asked Brad to tar those C files into source.tar which the
configure script is trying to do. If we revert that bit, the configure
script will work just fine. Or we fix the configure script to not package
the tar ball when it is already present.
 I am sorry but I am a bit lost since I do not see any relevant commits
 in those files:

 $ git lg sr_unix/configure.gtc sr_unix/gtminstall.sh
 * dee7100 - (5.5-000, origin/v55000, gh-yarikoptic/v55000) ENH: Version 
 5.5000 from sourceforge. (3 months ago) [Luis Ibanez]
 * 9299623 - (origin/v54002B, origin/master, origin/HEAD, 
 gh-yarikoptic/v54002B, gh-yarikoptic/master, master) ENH: Initial import from 
 sourceforge. (5 months ago) [Luis Ibanez]

 anyways -- are they needed anyhow for stage2 building/installation to
 obtain the ultimate installation ? ;)
[amul:2] Brad made the changes in CMakeLists.txt. So when you 'make install' 
instead of seeing the C files, you get a tarball
named 'source.tar' in '$gtm_dist/plugin/gtmcrypt/'. I can't find the commit for 
it, but its there. :)

[amul:2] The CMake install directory is almost stage 2. What's missing for a 
complete stage2 are the help database files, all
the object files, and the replacements for GTM_DIST in the shell scripts. In 
order to let configure work as is, we should role
the install directory back to stage1 (my fault for bringing us past stage1).


_
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/4fe0b509.3050...@fisglobal.com

Re: Any progress with FIS GT.M?

2012-06-19 Thread Amul Shah



On 06/19/12 13:34, Brad King wrote:
 On 06/19/2012 01:21 PM, Amul Shah wrote:
 [amul:2] Brad made the changes in CMakeLists.txt. So when you 'make install' 
 instead of seeing the C files, you get a tarball
 named 'source.tar' in '$gtm_dist/plugin/gtmcrypt/'. I can't find the commit 
 for it, but its there. :)
 It was here:

  https://github.com/luisibanez/fis-gtm/commit/68f30307

 though it was based on a commit by you which removed direct
 installation of those files.
[amul:3] Thanks. Yes, you did what I asked. :)

 [amul:2] The CMake install directory is almost stage 2. What's missing for a 
 complete stage2 are the help database files, all
 the object files, and the replacements for GTM_DIST in the shell scripts. In 
 order to let configure work as is, we should role
 the install directory back to stage1 (my fault for bringing us past stage1).
 I pushed out a change to hackathonjune2012-brad that reverts
 this behavior and directly installs the files:

  https://github.com/luisibanez/fis-gtm/commit/3b4bcd7e

 Now the only errors I get from manually running configure are:

  cp: cannot stat `gdehelp.dat': No such file or directory
  chown: cannot access `/home/kingb/GTM/Test2/gdehelp.dat': No such file or 
 directory
  cp: cannot stat `gtmhelp.dat': No such file or directory
  chown: cannot access `/home/kingb/GTM/Test2/gtmhelp.dat': No such file or 
 directory
  ...
  chmod: cannot access `/home/kingb/GTM/Test2/*.dat': No such file or directory

 Should these two files be built and installed by CMake?
[amul:3] Looking at the build scripts, yes. I'm going to create a separate 
cmake file for generating the help Global Directory
and Database file.

[amul:3] Is everyone generating the Unicode GDE files in the install directory? 
My machine is throwing an error, but I thought I
got past this part before without setting LC_CTYPE correctly.
%GTM-E-NONUTF8LOCALE, Locale has character encoding (ANSI_X3.4-1968) which is 
not compatible with UTF-8 character set

thanks,
Amu


_
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/4fe0c1aa.7030...@fisglobal.com

Re: Any progress with FIS GT.M?

2012-06-19 Thread Amul Shah



On 06/19/12 14:02, Brad King wrote:
 On 06/19/2012 01:34 PM, Brad King wrote:
 Now the only errors I get from manually running configure are:

  cp: cannot stat `gdehelp.dat': No such file or directory
  chown: cannot access `/home/kingb/GTM/Test2/gdehelp.dat': No such file or 
 directory
  cp: cannot stat `gtmhelp.dat': No such file or directory
  chown: cannot access `/home/kingb/GTM/Test2/gtmhelp.dat': No such file or 
 directory
  ...
  chmod: cannot access `/home/kingb/GTM/Test2/*.dat': No such file or 
 directory

 Should these two files be built and installed by CMake?
 In case the answer is yes, I pushed out branch

  hackathonjune2012-brad-help-dat

 with commit

  https://github.com/luisibanez/fis-gtm/commit/eb42ac55

 to do it.

 -Brad
[amul:4] thanks. I should have read my inbox before sending my last mail. There 
is one modification, the path given to GDE
should be '$gtm_dist/XYZhlp.dat' . GT.M will resolve the $gtm_dist to the 
correct location.

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.

Re: Any progress with FIS GT.M?

2012-06-19 Thread Amul Shah



On 06/19/12 15:01, Brad King wrote:
 On 06/19/2012 02:41 PM, Brad King wrote:
 On 06/19/2012 02:20 PM, Amul Shah wrote:
 the path given to GDE should be '$gtm_dist/XYZhlp.dat'
 Okay.  I pushed the help generation plus this fix
 Perhaps the change below is needed too for the destdir case,
 and does not hurt in the normal case?

 -Brad

[amul:2] Yes. That is what I meant in my last mail.



 diff --git a/sr_unix/configure.gtc b/sr_unix/configure.gtc
 index 0c5b54e..7b3a604 100644
 --- a/sr_unix/configure.gtc
 +++ b/sr_unix/configure.gtc
 @@ -754,7 +754,7 @@ export gtmgbldir

  cat GDE.in1 | $gtmdist/mumps -direct
  Do ^GDE
 -Change -segment DEFAULT-block=2048 -file=$gtmdist/gtmhelp.dat
 +Change -segment DEFAULT-block=2048 -file=\$gtm_dist/gtmhelp.dat
  Change -region DEFAULT -record=1020-key=255
  Exit
  GDE.in1
 @@ -764,7 +764,7 @@ export gtmgbldir

  cat GDE.in2 | $gtmdist/mumps -direct
  Do ^GDE
 -Change -segment DEFAULT-block=2048 -file=$gtmdist/gdehelp.dat
 +Change -segment DEFAULT-block=2048 -file=\$gtm_dist/gdehelp.dat
  Change -region DEFAULT -record=1020-key=255
  Exit
  GDE.in2

_
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/4fe0ce12.20...@fisglobal.com

66 matches

Mail list logo