On Thu, Jul 05, 2012 at 06:25:10PM -0400, Luis Ibanez wrote:
An Update on this front:
Overriding dh_fixperms is working great
for the local build with debuild.
The remaining lintian message here are:
...
Sounds good.
We are now tracking the problem with cowbuilder
and the chroot
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)
On Wed, Jul 4, 2012 at 2:08 PM, Luis Ibanez luis.iba...@kitware.com wrote:
Great news is that Yaroslav's finding of dh_fixperms
seems to be the solution to the struggle we were
having with the setuid !:-)
An Update on this front:
Overriding dh_fixperms is working great
for the
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
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
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
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
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
On Sun, Jul 01, 2012 at 05:41:38PM -0400, Luis Ibanez wrote:
Yeap, the chmod u+s is not helping here.
Quick question:
What section in the rules files corresponds to postinst ?
No section of debian/rules. You need an extra file
debian/postinst
and you probably should read the
oy
indeed, bring it postinst into the game is actually what I was trying to
avoid altogether ok -- in such cases it is best to consult ...
another package ;) I see that I have /usr/bin/slock installed with suid
so getting sources
$ dpkg -S /usr/bin/slock
suckless-tools:
Luis, I have inlined my answers ... I do not have a working checkout
of fis-gtm since there was some restructuring you guys were talking
about -- please commit them.
On Mon, 02 Jul 2012, Shah, Amul wrote:
I did not see this email in the debian-med mailing list archive, so I'm
re-sending.
my
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
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
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
Hi Yaroslav,
On Mon, Jul 2, 2012 at 11:00 AM, Yaroslav Halchenko
deb...@onerussian.comwrote:
Luis, I have inlined my answers ... I do not have a working checkout
of fis-gtm since there was some restructuring you guys were talking
about -- please commit them.
mm, It should be building with
On Sat, Jun 30, 2012 at 06:59:03PM -0400, Luis Ibanez wrote:
Here are some interesting observations.
a) When building with debuild instead of cowbuilder,
the resulting package:
fis-gtm-5.5.000_5.5-000+git104-g4077ab8-1_amd64.deb
doesn't report that many warning.
On Sun, Jul 1, 2012 at 2:35 AM, Andreas Tille andr...@an3as.eu wrote:
W: fis-gtm source: newer-standards-version 3.9.3 (current is 3.9.1)
That's because of your squeeze VM. You should probably install lintian
from unstable using
apt-get -t unstable install lintian
(after having
Just for the record,
A) linitian exceptions were added in the file:
debian/source/lintian-overrides
with content:
#
# Overriding warning for the COPYING file.
# We are aware that there is another license file.
# This will be addressed upstream at some point.
#
fis-gtm-5.5.000
On Sun, Jul 01, 2012 at 11:34:10AM -0400, Luis Ibanez wrote:
So, I modified the file:
preferences.d/01-linitan.pref
to contain:
Package: lintian
Pin: release a=unstable
Pin-Priority: 605
Package: hardening-includes
Pin: release a=unstable
Pin-Priority: 605
-
I
It turned out to be easier to remove the COPYING file
as a final step in the installation:
override_dh_auto_install:
dh_auto_install --destdir=debian/$(BINPKG)-stage1 $@
cd debian/$(BINPKG)-stage1/usr/$(GTM_INSTALL_DIR) \
gtm_destdir=$(CURDIR)/debian/$(BINPKG) \
./gtminstall --utf8 default
On Sun, Jul 1, 2012 at 2:40 PM, Andreas Tille andr...@an3as.eu wrote:
--installdir $(CURDIR)/debian/$(BINPKG)/usr/$(GTM_INSTALL_DIR)
@echo I: Fixing up permissions for removed write rights -- we aren't
done yet!
chmod +w -R $(CURDIR)/debian/$(BINPKG)/usr/$(GTM_INSTALL_DIR)
+ chmod
On Sun, 1 Jul 2012, Luis Ibanez wrote:
It turned out to be easier to remove the COPYING file
as a final step in the installation:
override_dh_auto_install:
@echo I: Fixing up permissions for setuid rights -- we aren't done yet!
chmod u+s
On Sun, Jul 1, 2012 at 3:48 PM, Thorsten Alteholz debian-...@alteholz.dewrote:
On Sun, 1 Jul 2012, Luis Ibanez wrote:
It turned out to be easier to remove the COPYING file
as a final step in the installation:
override_dh_auto_install:
@echo I: Fixing up permissions for setuid rights --
Thanks Luis,
On Sat, 30 Jun 2012, Luis Ibanez wrote:
In summary: I think I have now replicated Andreas observation,
and I'm starting to track the source of the problem.
what about my observations? ;) Let's see...
-r-Sr--r-- 1 root root 9888 Jun 30 17:39 gtmsecshr
dr
Hi Yaroslav,
Here are some interesting observations.
a) When building with debuild instead of cowbuilder,
the resulting package:
fis-gtm-5.5.000_5.5-000+git104-g4077ab8-1_amd64.deb
doesn't report that many warning.
More specifically, running lintian in the .desc file
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
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
Hi Luis,
Great to hear that we are almost there. Next step actually would be to
make sure it builds correct binary packages in a clean
environment (e.g. using pbuilder or cowbuilder). Last time I have tried
(22nd of June), and that was the same 5.5-000+git104-g4077ab8 the
resultant .deb's were
Hi,
please note that I reorganised SVN a bit to get rid of previous
packaging attempts which are now obsolete since we are profiting from
new build system.
On Fri, Jun 29, 2012 at 10:07:19AM -0400, Yaroslav Halchenko wrote:
Hi Luis,
Great to hear that we are almost there. Next step actually
Hi Luis,
On Fri, Jun 29, 2012 at 06:17:55PM -0400, Luis Ibanez wrote:
I just double checked in my recent build, and yes, we still
need to address the (a) gtmsecshr and (b) gtmsecshrdir suid:-/
I guess that's connected to the lintian runtime errors, right?
I need to track on whether
Hi Andreas,
On Fri, Jun 29, 2012 at 11:20 AM, Andreas Tille andr...@an3as.eu wrote:
Hi,
please note that I reorganised SVN a bit to get rid of previous
packaging attempts which are now obsolete since we are profiting from
new build system.
Noted !
Thanks for reorganizing the files.
Hi Luis,
On Fri, Jun 29, 2012 at 06:27:46PM -0400, Luis Ibanez wrote:
1. There is nothing in /usr/bin - so I have no idea what to call and
there is also no explanation in README.Debian which might help the
user
From the GTM point of view, this was to be expected.
I think
Good news.
I just run the build from scratch using the Git version that
is set in the debian/rules, and the process went smoothly.
The project is build from source, the .deb files are generated
and after installing the package I was able to run (manually)
the three tests that we have, including
I am trying to keep my head in a sane state while mentoring ~10 projects
to release before debian freeze point...
otherwise -- I am waiting from you to say it seems that everything is
cool with cmakification, and produced/installed binaries work as
destined, and may be Luis's I have built package
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
Got it,
I'll run a review of the state tomorrow (Thursday)
and report back, following the items in your check
list below.
Thanks
Luis
On Wed, Jun 27, 2012 at 3:42 PM, Yaroslav Halchenko
deb...@onerussian.comwrote:
I
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
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
Hi,
On Wed, Jun 20, 2012 at 09:31:42PM -0400, Yaroslav Halchenko wrote:
On Wed, 20 Jun 2012, Amul Shah wrote:
Yaroslav,
I assume that you will take care of setting LC_ALL in the debian package
build, correct?
yeah -- I will... but today I might just collapse and tomorrow evening I
Hi Andreas,
Thanks for jumping in.
On Thu, Jun 21, 2012 at 2:37 AM, Andreas Tille andr...@an3as.eu wrote:
The fis-gtm package is actually really important and I would be happy to
jump in but I somehow lost track in all these discussions. Could somebody
please confirm that a simple
ok -- I have just git svn dcommitted few relevant changes:
* 804f96c - (HEAD, git-svn, master) Progress to use most recent
origin/hackathonjune2012-brad (43 seconds ago) [yoh]
* 1cc6a96 - debian/watch - parse upstream's single number version (e.g. 55000
- 5.5-000) (45 seconds ago) [yoh]
*
On Thu, 21 Jun 2012, Yaroslav Halchenko wrote:
ok -- I have just git svn dcommitted few relevant changes:
* 804f96c - (HEAD, git-svn, master) Progress to use most recent
origin/hackathonjune2012-brad (43 seconds ago) [yoh]
* 1cc6a96 - debian/watch - parse upstream's single number version
On Wed, Jun 20, 2012 at 9:31 PM, Yaroslav Halchenko
deb...@onerussian.comwrote:
On Wed, 20 Jun 2012, Amul Shah wrote:
Yaroslav,
I assume that you will take care of setting LC_ALL in the debian package
build, correct?
yeah -- I will... but today I might just collapse and tomorrow evening
On Thu, 21 Jun 2012, Luis Ibanez wrote:
Here is what Brad found as suggested patch for taking care of the LC_ALL,
but... we don't have an environment setup for testing these changes:
Maybe Andreas or Yaroslav could give it a shot at these changes...?
we can't -- those are the
On 06/21/2012 10:55 AM, Yaroslav Halchenko wrote:
I guess smth is needed in addition to
commit 33f1fdacf98c92e01bb5fb116521a234010cc3fa
Author: Brad King brad.k...@kitware.com
Date: Thu Jun 21 09:33:15 2012 -0400
Generate xfer_desc.i with CMake code
I added a missing dependency
so I committed and testing now
wow -- we even crossed with commits progressing the revision... I took
yours since you committed first, although it is a bit 'incorrect':
-fis-gtm (5.5-000+git100-g949806c-1) UNRELEASED; urgency=low
+fis-gtm (5.5-000+git102-g949806c-1) UNRELEASED; urgency=low
that
unfortunately it didn't help
still got
%GTM-E-NONUTF8LOCALE, Locale has character encoding (ANSI_X3.4-1968) which is
not compatible with UTF-8 character set
may be we need some other than LC_ALL? e.g. LC_CTYPE set?
$ git grep '\WLC_'
sr_unix/buildaux.csh: setenv LC_CTYPE C
nope -- setting LC_CTYPE also didn't help :-/
what else should it be? ;)
P.S. btw feel free to revert/adjust any of my changes if you feel that
there is a better solution!
On Thu, 21 Jun 2012, Yaroslav Halchenko wrote:
unfortunately it didn't help
still got
%GTM-E-NONUTF8LOCALE,
uff -- sorry for the noise -- just disregard my last emails about
locales -- apparently it just wasn't generated at all ;)
On Thu, 21 Jun 2012, Yaroslav Halchenko wrote:
nope -- setting LC_CTYPE also didn't help :-/
what else should it be? ;)
P.S. btw feel free to revert/adjust any of my
ok -- it was silly omission (forgotten build-depends on locales).
committed now -- seems to build in clean chroot now... but seems to
loose
lrwxrwxrwx root/root /usr/lib/fis-gtm/V5.5-000_x86_64/utf8/COPYING -
../COPYING
lrwxrwxrwx root/root /usr/lib/fis-gtm/V5.5-000_x86_64/utf8/GETPASS.m -
On Thu, Jun 21, 2012 at 11:35 AM, Yaroslav Halchenko
deb...@onerussian.comwrote:
so I committed and testing now
wow -- we even crossed with commits progressing the revision... I took
yours since you committed first, although it is a bit 'incorrect':
-fis-gtm (5.5-000+git100-g949806c-1)
On Thu, 21 Jun 2012, Luis Ibanez wrote:
You can easily obtain it if you
do what I did (I can't push to your repo):
If you give me your github username,
I'll add you to the collaborators list for the project.
My apologies, I should have done this earlier.
no problem
so
Hi,
On Wed, Jun 20, 2012 at 09:45:25AM -0400, Bhaskar, K.S wrote:
should we work toward creating/reserving a dedicated group for
fis-gtm? I thought that for now we would just have everything
root.root... but due to the root-suid may be a dedicated group might be
a reasonable thing
[KSB5]
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
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
On Tue, Jun 19, 2012 at 11:57 PM, Yaroslav Halchenko
deb...@onerussian.comwrote:
+ ah right -- test/fix packaging on 32bit system ;)
FWIW,
We are mostly working on 32bits in a Debian VM.
Most of our reports are from what we are doing in 32bits.
Luis
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.
On Wed, 20 Jun 2012, Amul Shah wrote:
Yaroslav,
I assume that you will take care of setting LC_ALL in the debian package
build, correct?
yeah -- I will... but today I might just collapse and tomorrow evening I
have some festivities scheduled, so can't promise much activity. So if
anyone
On 06/19/2012 12:03 AM, Yaroslav Halchenko wrote:
On 06/18/2012 02:42 PM, Brad King wrote:
Here is a patch series that solves this problem. I've only done
some lightweight/manual testing with this. The first patch
refactors both i386 and x86_64 code paths that emit the path to
On 06/19/2012 12:03 AM, Yaroslav Halchenko wrote:
it seems that mumps doesn't even try to load libgtmutil.so
[snip]
$ echo $gtm_dist
/usr/lib/fis-gtm/V5.5-000+git80-g211bd16_x86_64
$ strace -fF -o /tmp/123strace2.log $gtm_dist/mumps -direct
It works for me if I add
$ strace -fF -o /tmp/123strace2.log $gtm_dist/mumps -direct
It works for me if I add
gtmroutines=$gtm_dist/libgtmutil.so
to the environment.
rright -- forgot about this one ;-) so many hidden precious env
variables without any punishing me-forgetful error messages ;)
also we need to
Bhaskar,
tiny questions:
- are there any internal checks/reliance on installed files being
read-only? what is the goal anyway behind making them read-only if
owned by root who is the one with ability to revert that anyways?
- shouldn't gtminstall have 'set -e' (or explicit || exit 1) so
in
Yaroslav,
Thanks for configuring the Debian files to take
advantage of Brad's recent modifications.
I'm trying to replicate the process and run in the following message:
...
I: Fixing up permissions for removed write rights -- we aren't done yet!
chmod +w -R
On 06/19/2012 10:59 AM, Yaroslav Halchenko wrote:
$ strace -fF -o /tmp/123strace2.log $gtm_dist/mumps -direct
It works for me if I add
gtmroutines=$gtm_dist/libgtmutil.so
to the environment.
rright -- forgot about this one ;-) so many hidden precious env
variables without any punishing
On Tue, 19 Jun 2012, Bhaskar, K.S wrote:
On 06/19/2012 10:59 AM, Yaroslav Halchenko wrote:
$ strace -fF -o /tmp/123strace2.log $gtm_dist/mumps -direct
It works for me if I add
gtmroutines=$gtm_dist/libgtmutil.so
to the environment.
rright -- forgot about this one ;-) so many hidden
On Tue, 19 Jun 2012, Luis Ibanez wrote:
tar: ./usr/lib/fis-gtm/V5.5-000+git80-g211bd16_i486/utf8/_utf2hex.m: file
changed as we read it
dpkg-deb: subprocess tar -cf returned error exit status 1
dh_builddeb: dpkg-deb --build debian/fis-gtm-5.5.000 .. returned exit code
2
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
On Tue, 19 Jun 2012, Yaroslav Halchenko wrote:
tar: ./usr/lib/fis-gtm/V5.5-000+git80-g211bd16_i486/utf8/_utf2hex.m: file
changed as we read it
dpkg-deb: subprocess tar -cf returned error exit status 1
dh_builddeb: dpkg-deb --build debian/fis-gtm-5.5.000 .. returned exit
On Tue, 19 Jun 2012, Yaroslav Halchenko wrote:
tar: ./usr/lib/fis-gtm/V5.5-000+git80-g211bd16_i486/utf8/_utf2hex.m:
file
changed as we read it
dpkg-deb: subprocess tar -cf returned error exit status 1
dh_builddeb: dpkg-deb --build debian/fis-gtm-5.5.000 .. returned exit
On Tue, 19 Jun 2012, Yaroslav Halchenko wrote:
make: *** [binary] Error 9
dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit
status 2
debuild: fatal error at line 1325:
dpkg-buildpackage -rfakeroot -d -us -uc failed
I'm doing this by running:
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
On 06/19/2012 11:36 AM, Yaroslav Halchenko wrote:
Bhaskar,
tiny questions:
- are there any internal checks/reliance on installed files being
read-only? what is the goal anyway behind making them read-only if
owned by root who is the one with ability to revert that anyways?
[KSB4] Having
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:
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
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,
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:
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
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
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
https://github.com/luisibanez/fis-gtm/commit/74aa25e0751a28a08202a13f9f13c79e532c29ab
the Debian-med SVN revision
my replies are interleaved with quotes of your email
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
yeay!
On Tue, 19 Jun 2012, Bhaskar, K.S wrote:
owned by root who is the one with ability to revert that anyways?
[KSB4] Having installed files be read-only is good hygiene.
I have heard that excessive sanitation leads to weaker immune system and
allergies ;) but in general in Debian we just
+ I still think I have forgotten smth... we should have kept a TODO ;)
+ ah right -- test/fix packaging on 32bit system ;)
RRIGHT -- now I remembered:
+ following Bhaskar's recommendation -- for prerm script to verify
that there is no running instances
--
Yaroslav O. Halchenko
Postdoctoral
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
actually I think I found a way how it should be done if a utf8 locale is
required
http://www.mattfischer.com/blog/?p=105
;-) just to make sure -- utf8 local influences only utf8/* builds and has no
(negative) impact otherwise, right? ;)
On Wed, 20 Jun 2012, Yaroslav Halchenko wrote:
Amul,
On 06/16/2012 11:03 PM, Yaroslav Halchenko wrote:
Thank you Bhaskar for the testing details! The will definetely be
useful to provide at least a minimal test of having things
built/installed correctly. My family keeps me heavily occupied
this weekend so I will have a chance to look at it
On Mon, 18 Jun 2012, Bhaskar, K.S wrote:
If I understand correctly, you want to make these changes to avoid a
postinstall script in the package. I have to ask whether this amounts to
spending ten dollars to save one dollar.
It might indeed look like that, and if someone jumps in and
On 06/18/2012 12:00 PM, Bhaskar, K.S wrote:
[KSB] I'll see about getting you that information - it is possible
that none of the developers knows that answer right off the top of
his head and some research will be needed. But be aware that you
cannot simply patch it to look for the original .m
On 06/18/2012 02:42 PM, Brad King wrote:
On 06/18/2012 12:00 PM, Bhaskar, K.S wrote:
[KSB] I'll see about getting you that information - it is possible
that none of the developers knows that answer right off the top of
his head and some research will be needed. But be aware that you
cannot
On 06/18/2012 04:29 PM, Bhaskar, K.S wrote:
[KSB2] Thank you very much, Brad.
We would like to ask if you would be willing to solve the issue with one of
two slightly different approaches from what you have implemented.
I just provided the patches as a quick way to solve the immediate
On 06/18/2012 04:48 PM, Brad King wrote:
On 06/18/2012 04:29 PM, Bhaskar, K.S wrote:
[KSB2] Thank you very much, Brad.
We would like to ask if you would be willing to solve the issue with one of two
slightly different approaches from what you have implemented.
I just provided the patches
On 06/18/2012 02:42 PM, Brad King wrote:
Here is a patch series that solves this problem. I've only done
some lightweight/manual testing with this. The first patch
refactors both i386 and x86_64 code paths that emit the path to
the source file into the object file to send source file
On Sat, Jun 16, 2012 at 5:56 AM, Andreas Tille andr...@an3as.eu wrote:
B) Testing, testing, testing: we need to do a lot
of testing on the resulting build, to make
sure that we got things right.
Do you feel the time is ripe for an upload to experimental (and could
On Sat, Jun 16, 2012 at 10:19:48AM -0400, Luis Ibanez wrote:
In that way, we can take care of fixing any issues in parallel. As
different
people work in different parts. Brad and Amul have the build process under
control. So, I probably will be more useful on moving the packaging process
On Fri, Jun 15, 2012 at 6:23 PM, Yaroslav Halchenko
deb...@onerussian.comwrote:
On Fri, 15 Jun 2012, Luis Ibanez wrote:
A) We need to address a Post-Installation step
where some .m files are compiled in their
final destination. We are brainstorming on
this with
On 06/16/2012 11:43 AM, Luis Ibanez wrote:
On Fri, Jun 15, 2012 at 6:23 PM, Yaroslav Halchenko
deb...@onerussian.com mailto:deb...@onerussian.com wrote:
On Fri, 15 Jun 2012, Luis Ibanez wrote:
A) We need to address a Post-Installation step
where some .m files are
On Sat, Jun 16, 2012 at 10:19:48AM -0400, Luis Ibanez wrote:
I would think that it is worth to keep moving through the Debian workflow.
In that way, we can take care of fixing any issues in parallel. As
different
people work in different parts. Brad and Amul have the build process under
On Sat, Jun 16, 2012 at 11:43:55AM -0400, Luis Ibanez wrote:
I just put some initial ones here:
http://public.kitware.com/pub/itk/OSEHRA/testing_sources/
In order from simple to complex they are:
-
- helloworld.m
- fibonacci.m
- threeen1f.m
As we move forward we
Thank you Bhaskar for the testing details! The will definetely be
useful to provide at least a minimal test of having things
built/installed correctly. My family keeps me heavily occupied
this weekend so I will have a chance to look at it with a clear head
only early next week. But regarding:
Andreas,
A quick update on the status of the fis-gtm package.
After the hackathon on Wednesday, there has been
further activity and things are coming along nicely.
The most recent version of the fis-gtm source tree along with
the corresponding CMakeLists.txt file is here (in a branch):
On Fri, 15 Jun 2012, Luis Ibanez wrote:
A) We need to address a Post-Installation step
where some .m files are compiled in their
final destination. We are brainstorming on
this with Yaroslav, Bhaskar, Amul and Brad...
now that it is buildable/usable it is time to
1 - 100 of 124 matches
Mail list logo
