Hello,
On Fri, Dec 02, 2005 at 01:22:55AM -0600, Ming Hua wrote:
> One package I maintain (libscim8 from scim) is going through the c2->c2a
> C++ ABI transition. I have two questions about the dependency handling
> in such a transition:
> 1. Raised by my sponsor - Should I add g++ (>= 4.0.2-4)
* Henrique de Moraes Holschuh <[EMAIL PROTECTED]> [020423 12:17]:
> On Tue, 23 Apr 2002, Yves Arrouye wrote:
> > Package has a Depends on icu which cannot be satisfied on hurd-i386.
> > Package has a Depends on icu which cannot be satisfied on sh.
> >
> > Do I need to care about these? There is no
* Henrique de Moraes Holschuh <[EMAIL PROTECTED]> [020423 12:17]:
> On Tue, 23 Apr 2002, Yves Arrouye wrote:
> > Package has a Depends on icu which cannot be satisfied on hurd-i386.
> > Package has a Depends on icu which cannot be satisfied on sh.
> >
> > Do I need to care about these? There is n
On Tue, 23 Apr 2002, Yves Arrouye wrote:
> Package has a Depends on icu which cannot be satisfied on hurd-i386.
> Package has a Depends on icu which cannot be satisfied on sh.
>
> Do I need to care about these? There is no problem listed in
No. Just ignore sh and hurd for now...
--
"One disk
On Tue, 23 Apr 2002, Yves Arrouye wrote:
> Package has a Depends on icu which cannot be satisfied on hurd-i386.
> Package has a Depends on icu which cannot be satisfied on sh.
>
> Do I need to care about these? There is no problem listed in
No. Just ignore sh and hurd for now...
--
"One disk
On Fri, Aug 03, 2001 at 08:31:19PM +0430, Pratik Sinha wrote:
> First Question
>
> Which one should be preferred???- dh_make or deb-make
i think dh_make (dh stands for debhelper) is to be prefered, maybe even
deb-make is obsolet, but am not sure.
anyway, use dh_make and debhelper.
> Second Que
On Fri, Jul 06, 2001 at 06:44:03PM -0700, David R. Van Sandt wrote:
> Thanks. In my digging today I found the archtable - and it
> is indeed compiled in. I think the version I have doesn't
> have the right/full archtable in it.
>
> Here's another quetion. The system I'm compiling on is
> missing.
On Fri, Jul 06, 2001 at 06:44:03PM -0700, David R. Van Sandt wrote:
> Thanks. In my digging today I found the archtable - and it
> is indeed compiled in. I think the version I have doesn't
> have the right/full archtable in it.
>
> Here's another quetion. The system I'm compiling on is
> missing.
.h
/usr/include/sys/ieeefp.h
Where can I get these? OS vendor package or GNU package?
thanks!
> -Original Message-
> From: Shaul Karl [mailto:[EMAIL PROTECTED]
> Sent: Friday, July 06, 2001 6:36 PM
> To: David R. Van Sandt
> Cc: debian-mentors@lists.debian.or
> We are using dpkg on Solaris to manage packages. I am having a
> couple of difficulties.
>
> 1. I've built a package, but when I install it I get this error.
>
> dpkg: warning, architecture `sun4u-sunos-5.8' not in remapping table
> dpkg: error processing reng.cgiemail-1.6-v-1.deb (--install):
.h
/usr/include/sys/ieeefp.h
Where can I get these? OS vendor package or GNU package?
thanks!
> -Original Message-
> From: Shaul Karl [mailto:[EMAIL PROTECTED]]
> Sent: Friday, July 06, 2001 6:36 PM
> To: David R. Van Sandt
> Cc: [EMAIL PROTECTED]
> Subject: Re
> We are using dpkg on Solaris to manage packages. I am having a
> couple of difficulties.
>
> 1. I've built a package, but when I install it I get this error.
>
> dpkg: warning, architecture `sun4u-sunos-5.8' not in remapping table
> dpkg: error processing reng.cgiemail-1.6-v-1.deb (--install):
On Fri, 6 Oct 2000 [EMAIL PROTECTED] wrote:
> If you want to use rpath then you might want to check it with
> somebody with experience in security (Debian security team?),
rpath has some advantages in this case over hardwiring the paths into the
executable (for example, you can add paths at runti
On Fri, 6 Oct 2000 [EMAIL PROTECTED] wrote:
> If you want to use rpath then you might want to check it with
> somebody with experience in security (Debian security team?),
rpath has some advantages in this case over hardwiring the paths into the
executable (for example, you can add paths at runt
If you want to use rpath then you might want to check it with
somebody with experience in security (Debian security team?),
I think one of the arguments was about security. I may be
totally off here, but IIRC rpath also checks an environment
variable and this is considered very insecure.
HTH
t.aa
If you want to use rpath then you might want to check it with
somebody with experience in security (Debian security team?),
I think one of the arguments was about security. I may be
totally off here, but IIRC rpath also checks an environment
variable and this is considered very insecure.
HTH
t.a
On Thu, 5 Oct 2000, Rick Younie wrote:
> Yeah, I talked to the Regina maintainer about this. He's happier
> leaving the libs in /usr/lib rather than using rpath so I guess
> he'd feel the same about modifying ld.so.conf.
Another option for loadable modules would be to dlopen() them with the
full
On Thu, 5 Oct 2000, Rick Younie wrote:
> Yeah, I talked to the Regina maintainer about this. He's happier
> leaving the libs in /usr/lib rather than using rpath so I guess
> he'd feel the same about modifying ld.so.conf.
Another option for loadable modules would be to dlopen() them with the
ful
> > Another thing you could do is to stuck the libs in a
> subdirectory and have
> > your postinst and postrm edit /etc/ld.so.conf. That sounds like the
> > traditional way to me, but then that was before rpath...
>
> It's a little trickier than the way xaw3d handled it though. A
> half-dozen pa
> > Another thing you could do is to stuck the libs in a
> subdirectory and have
> > your postinst and postrm edit /etc/ld.so.conf. That sounds like the
> > traditional way to me, but then that was before rpath...
>
> It's a little trickier than the way xaw3d handled it though. A
> half-dozen p
> > > 1. I see no mention on rpath in the policy manual (grepping through
all the
> > > .html files) yet lintian issues a warning about it. I'm asking because
I'm
> > > packaging something that uses rpath heavily.
>
> > rpath hardcodes an item's location. If this item later moves,
everything using
> > > 1. I see no mention on rpath in the policy manual (grepping through
all the
> > > .html files) yet lintian issues a warning about it. I'm asking because
I'm
> > > packaging something that uses rpath heavily.
>
> > rpath hardcodes an item's location. If this item later moves,
everything usin
> I was wondering about rpath as well. I maintain a couple
> packages that drop 5 function libs for regina-rexx in /usr/lib.
> There are probably another 6-8 that someone might package.
> /usr/lib could soon be as bad as /var/lib/dpkg/info. You can
> pretty much go for coffee on your first 'dpkg
Simon Richter wrote:
> On Tue, 3 Oct 2000, Sean 'Shaleh' Perry wrote:
>
>> rpath hardcodes an item's location. If this item later moves,
>> everything using it gets confused. rpath is generally frowned
>> upon.
>
> rpath adds additional path elements to the search list. Libraries are
> still fou
> I was wondering about rpath as well. I maintain a couple
> packages that drop 5 function libs for regina-rexx in /usr/lib.
> There are probably another 6-8 that someone might package.
> /usr/lib could soon be as bad as /var/lib/dpkg/info. You can
> pretty much go for coffee on your first 'dpkg
Simon Richter wrote:
> On Tue, 3 Oct 2000, Sean 'Shaleh' Perry wrote:
>
>> rpath hardcodes an item's location. If this item later moves,
>> everything using it gets confused. rpath is generally frowned
>> upon.
>
> rpath adds additional path elements to the search list. Libraries are
> still fo
>
> I could be wrong, but it seems to me like you might not want to define
> REENTRANT if your library isn't. There are many many libraries that are
> not, one way or another.
>
Policy states a lib in Debian should be compiled with REENTRANT. So if this
fails, he can file a bug.
On Tue, 3 Oct 2000, Sean 'Shaleh' Perry wrote:
> > So, let's say the package is build with --disable-threads. I should still
> > use -D_REENTRANT for the libraries since even though they don't use threads
> > themselves they may be used by applications that do use threads. And then I
> > should n
On Tue, 3 Oct 2000, Sean 'Shaleh' Perry wrote:
> > 1. I see no mention on rpath in the policy manual (grepping through all the
> > .html files) yet lintian issues a warning about it. I'm asking because I'm
> > packaging something that uses rpath heavily.
> rpath hardcodes an item's location. If
>
> So, let's say the package is build with --disable-threads. I should still
> use -D_REENTRANT for the libraries since even though they don't use threads
> themselves they may be used by applications that do use threads. And then I
> should not use -D_REENTRANT for the applications themselves si
> > 1. I see no mention on rpath in the policy manual (grepping
> through all the
> > .html files) yet lintian issues a warning about it. I'm
> asking because I'm
> > packaging something that uses rpath heavily.
> >
> rpath hardcodes an item's location. If this item later
> moves, everything u
On 03-Oct-2000 Yves Arrouye wrote:
> Hi,
>
> I was browsing policy to familiarize myself with it again, and I have two
> questions:
>
> 1. I see no mention on rpath in the policy manual (grepping through all the
> .html files) yet lintian issues a warning about it. I'm asking because I'm
> packa
>
> I could be wrong, but it seems to me like you might not want to define
> REENTRANT if your library isn't. There are many many libraries that are
> not, one way or another.
>
Policy states a lib in Debian should be compiled with REENTRANT. So if this
fails, he can file a bug.
--
To UNS
On Tue, 3 Oct 2000, Sean 'Shaleh' Perry wrote:
> > So, let's say the package is build with --disable-threads. I should still
> > use -D_REENTRANT for the libraries since even though they don't use threads
> > themselves they may be used by applications that do use threads. And then I
> > should
On Tue, 3 Oct 2000, Sean 'Shaleh' Perry wrote:
> > 1. I see no mention on rpath in the policy manual (grepping through all the
> > .html files) yet lintian issues a warning about it. I'm asking because I'm
> > packaging something that uses rpath heavily.
> rpath hardcodes an item's location. If
>
> So, let's say the package is build with --disable-threads. I should still
> use -D_REENTRANT for the libraries since even though they don't use threads
> themselves they may be used by applications that do use threads. And then I
> should not use -D_REENTRANT for the applications themselves s
> > 1. I see no mention on rpath in the policy manual (grepping
> through all the
> > .html files) yet lintian issues a warning about it. I'm
> asking because I'm
> > packaging something that uses rpath heavily.
> >
> rpath hardcodes an item's location. If this item later
> moves, everything
On 03-Oct-2000 Yves Arrouye wrote:
> Hi,
>
> I was browsing policy to familiarize myself with it again, and I have two
> questions:
>
> 1. I see no mention on rpath in the policy manual (grepping through all the
> .html files) yet lintian issues a warning about it. I'm asking because I'm
> pack
38 matches
Mail list logo
