Hi Yaroslav,
Thanks very much for mentoring us on the Debian package. We greatly
appreciate this. Here are two finer points: If Kapil already discussed
them with you, then you can ignore this.
1)
> > > ignorant questions: would it work on other architectures? shouldn't
> > > generated file also cover /usr/lib32 library paths on 64bit systems?
> > DMTCP will work only on i386 and amd64 architectures. I am sorry, but
> > I don't understand which files should I put under /usr/lib32?
We have an option: ./configure --enable-m32
which builds a 32-bit library on a 64-bit Linux. This is used for
checkpointing and restarting 32-bit apps in 64-bit Linux. This feature
is seldom used, and so it is not necessary to support this in the Debian
package. Should we simply avoid that issue, or should we be including
32-bit libraries in /usr/lib32?
2)
A small number of source files are modified from glibc source files.
You can find them by doing:
grep -r 'This file is part of the GNU C Library' ./
Both DMTCP and GLIBC use the LGPL license. Do we appropriately acknowledge
any of our source code that is derived from glibc?
Thanks,
- Gene
On Tue, Jan 25, 2011 at 10:18:58PM -0500, Yaroslav Halchenko wrote:
> On Tue, 25 Jan 2011, Kapil Arya wrote:
> > > * debian/control:
> > > - Standards-Version: 3.8.3
> > > make sure it is compatible with current one (3.9.1) and adjust control
> > > file accordingly
> > Done. However, I haven't setup the quilt so lintian is complaining.
>
> there is not much to "setup":
>
> mkdir debian/patches
> touch debian/patches/series # not even necessary per se
> svn commit debian/patches/series
>
> ;-) you might never use it, unless at some point you decide to carry some
> fixes
> without rolling out a new "upstream" release
>
> > > - there are arch dependent patches: mtcp.t.patch-* covering only two
> > > architectures.
> > > ignorant questions: would it work on other architectures? shouldn't
> > > generated file also cover /usr/lib32 library paths on 64bit systems?
> > DMTCP will work only on i386 and amd64 architectures. I am sorry, but
> > I don't understand which files should I put under /usr/lib32?
>
> what I meant is:
> $> grep SEARCH ./mtcp/mtcp.t.patch-x86_64
> SEARCH_DIR("/usr/x86_64-linux-gnu/lib64"); SEARCH_DIR("/usr/local/lib64");
> SEARCH_DIR("/lib64"); SEARCH_DIR("/usr/lib64");
> SEARCH_DIR("/usr/x86_64-linux-gnu/lib"); SEARCH_DIR("/usr/local/lib");
> SEARCH_DIR("/lib"); SEARCH_DIR("/usr/lib");
>
> and on 64bit systems we have a set of 32bit libraries under /usr/lib32; so
> what
> would happen if I try to checkpoint a 32-bit application using any of those
> running within x86_64 build of dmtcp? (sorry -- not in the shape to try atm)
> so
> my blunt question was -- either SEARCH_DIR should have been expanded to
> include
> /usr/lib32 as well.
>
> > Thanks for pointing this out. There is no need of
> > libdmtcpawareSOVERSION and you are right that we should create
>
> do you mean that you will not provide public dynamic library? then
> manpage should be adjusted I guess ;-)
>
> > libdmtcpaware-dev binary package (containing .a and .h). However, I
> > need to lookup how to create two binary packages.
>
> just add a -dev package description to debian/control ;-) and install
> those 2 files correspondingly under debian/libdmtcpaware-dev directory instead
> of debian/dmtcp
>
> > BTW, this time I have used svn-buildpackage since dmtcp uses
> > subversion (hosted on sourceforge) and seemed easier that way to make
> > the changes in upstream as well.
> good ;-)
>
> > Do you want me to upload the updated
> > package or wait until I finish the libdmtcpaware-dev package as well.
>
> ideally I would prefer to receive a url to the signed .dsc file (e.g.
> from mentors), which is checked to build fine in a clean environment
> (pbuilder,
> cowbuilder, etc) and which is "lintian free"
>
> Additional questions:
>
> * your key EF26082C ... ? I failed to fetch it from public servers:
>
> $> gpg --recv-key 0xEF26082C
> gpg: requesting key EF26082C from hkp server pgp.mit.edu
> gpgkeys: key EF26082C not found on keyserver
> gpg: no valid OpenPGP data found.
> gpg: Total number processed: 0
>
> * QUICK-START seems to be a good resource, why not
>
> echo QUICK-START >> debian/docs
>
> ?
>
> * add those other borrowed GNU files/snippets to debian/copyright
>
> $> git grep -l 'Copyright.*Free Software Foundation' | grep -v COPYING
> dmtcp/src/glibcsystem.cpp
> mtcp/NOTES-x86_64/syscall.S
> mtcp/NOTES-x86_64/sysdep-x86_64.h
> mtcp/NOTES-x86_64/sysdep.S
> mtcp/NOTES-x86_64/tls-i386.h
> mtcp/NOTES-x86_64/tls-x86_64.h
> mtcp/mtcp_sigaction_i386.ic
> mtcp/mtcp_sigaction_x86_64.ic
> mtcp/sysdep-x86_64.h
>
> actually mtcp/sysdep-* ;-)
>
> * ideally, since you do have tests battery -- it could/should have been
> run during package build time... could be an item for future TODO ;-)
>
> * since this version is first one to come to Debian, please adjust
> description and remove "Starting with release 1.2.0,...".
>
> BTW -- since 1.2.0 has been released a while... and current svn has already
> changes outside of debian/ directory, will be there 1.2.1 release so that
> Debian package's version (1.2.1-1) would make clear sense... otherwise it
> should be mentioned that this version is 1.2.0+svn857 or something like that
> to
> do not confuse users
>
>
> uff... ;-) hope it is of use
>
> Cheers,
> --
> =------------------------------------------------------------------=
> Keep in touch www.onerussian.com
> Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
