On Tue, Feb 13, 2001 at 10:21:59AM +0100, peter karlsson wrote:
> Chad C. Walstrom:
>
> > The easiest way is to maintain a vendor branch in a local repository.
>
> I would prefer not to make unnecessary copies...
In that case, try creating a branch in the upstream CVS module, rather than a
sepa
Jürgen A. Erhard wrote:
> There are patches that simply cannot be backported. There are others
> that are hard to backport even for the upstream maintainers who are
> *deep* into the code.
>
> So demanding of a "packager" to "always be able to backport" is too
> strong.
fwiw: granted.
> [I fin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> "Martin" == Martin Schulze <[EMAIL PROTECTED]> writes:
Martin> Christian Hammers wrote:
>> Hi
>>
>> As MySQL has a bad security problem and is accordingly to a @mysql.com
person
>> no longer supported in potato's version my
On Tue, Feb 13, 2001 at 10:21:59AM +0100, peter karlsson wrote:
> Chad C. Walstrom:
>
> > The easiest way is to maintain a vendor branch in a local repository.
>
> I would prefer not to make unnecessary copies...
In that case, try creating a branch in the upstream CVS module, rather than a
sep
Jürgen A. Erhard wrote:
> There are patches that simply cannot be backported. There are others
> that are hard to backport even for the upstream maintainers who are
> *deep* into the code.
>
> So demanding of a "packager" to "always be able to backport" is too
> strong.
fwiw: granted.
> [I fin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> "Martin" == Martin Schulze <[EMAIL PROTECTED]> writes:
Martin> Christian Hammers wrote:
>> Hi
>>
>> As MySQL has a bad security problem and is accordingly to a @mysql.com person
>> no longer supported in potato's version my
On Tue, 13 Feb 2001, Joe Drew wrote:
> > dh_shlibdeps
> > dh_gencontrol
> > dpkg-gencontrol: error: current build architecture alpha does not appear in
> > package's list (i386)
> > dh_gencontrol: command returned error code
> > make: *** [binary-arch] Error 1
> >
> > This probably corresponds to
Joe Drew wrote:
> > dh_gencontrol
>
> lxdoom creates a couple of binary packages, one of which (the svgalib binary)
> is useful only on i386. Therefore, I assigned lxdoom-svga Architecture: i386
> only, assuming dpkg-gencontrol would work properly with this. Apparently
> not. How can I get around
Y el martes 13 de febrero, Adam C Powell IV escribió:
>
> Okay, you need to upgrade your libdb2* to 2.7.7-2.2. If for some reason your
> apt
> front-end isn't doing this automatically (I had the same problem), lynx over
> to your
> favorite mirror, download and dpkg-i.
>
It worked fine. Thank
On Tue, Feb 13, 2001 at 04:46:46PM +0100, Paul Slootman wrote:
> dh_shlibdeps
> dh_gencontrol
> dpkg-gencontrol: error: current build architecture alpha does not appear in
> package's list (i386)
> dh_gencontrol: command returned error code
> make: *** [binary-arch] Error 1
>
> This probably corr
On Tue, 13 Feb 2001, Luis Arocha -data- wrote:
> Hi,
Hi Luis,
> Which are the common steps/time for a package to go from incoming to testing?
there is an explanation in section 5.6.1 of the Developer's Reference. It
takes at least 10/5/2 days (for the urgency low/medium/high).
> TIA
cu,
Adria
Hi,
Which are the common steps/time for a package to go from incoming to testing?
TIA
--
Luis Arocha Hernandez "Data" <[EMAIL PROTECTED]>, Islas Canarias - Spain
_ o__o__ o__ O_ OO
o/,>/ ,>/ ,//,/\ ,/|
_()_\()_
Y el martes 13 de febrero, Adam C Powell IV escribió:
>
> Okay, you need to upgrade your libdb2* to 2.7.7-2.2. If for some reason your
> apt
> front-end isn't doing this automatically (I had the same problem), lynx over
> to your
> favorite mirror, download and dpkg-i.
>
I've seen libdb2* 2.7.
On Tue, 13 Feb 2001, Joe Drew wrote:
> > dh_shlibdeps
> > dh_gencontrol
> > dpkg-gencontrol: error: current build architecture alpha does not appear in
>package's list (i386)
> > dh_gencontrol: command returned error code
> > make: *** [binary-arch] Error 1
> >
> > This probably corresponds to l
Joe Drew wrote:
> > dh_gencontrol
>
> lxdoom creates a couple of binary packages, one of which (the svgalib binary)
> is useful only on i386. Therefore, I assigned lxdoom-svga Architecture: i386
> only, assuming dpkg-gencontrol would work properly with this. Apparently
> not. How can I get around
Y el martes 13 de febrero, Adam C Powell IV escribió:
>
> Okay, you need to upgrade your libdb2* to 2.7.7-2.2. If for some reason your apt
> front-end isn't doing this automatically (I had the same problem), lynx over to your
> favorite mirror, download and dpkg-i.
>
It worked fine. Thank you.
peter karlsson wrote:
> I would prefer not to make unnecessary copies...
I think you're referring to the local repository as being unnecessary,
in which case I'd agree with you. However, if you do use local
repositories and do not have direct upstream CVS access, vendor
branchanes are far too con
Luis Arocha wrote:
> Y el lunes 12 de febrero, Adam C Powell IV escribió:
> >
> > Which release are you using? Which version of libdb2-dev?
> >
> > If woody/sid, you will find /usr/lib/libdb.so in libdb2-dev 2.7.7-2.2. If
> > potato,
> > you will find it in libc6-dev 2.1.3-15.
> >
> Installed p
On Tue, Feb 13, 2001 at 04:46:46PM +0100, Paul Slootman wrote:
> dh_shlibdeps
> dh_gencontrol
> dpkg-gencontrol: error: current build architecture alpha does not appear in
>package's list (i386)
> dh_gencontrol: command returned error code
> make: *** [binary-arch] Error 1
>
> This probably corr
On Tue, 13 Feb 2001, Luis Arocha -data- wrote:
> Hi,
Hi Luis,
> Which are the common steps/time for a package to go from incoming to testing?
there is an explanation in section 5.6.1 of the Developer's Reference. It
takes at least 10/5/2 days (for the urgency low/medium/high).
> TIA
cu,
Adri
Hi,
Which are the common steps/time for a package to go from incoming to testing?
TIA
--
Luis Arocha Hernandez "Data" <[EMAIL PROTECTED]>, Islas Canarias - Spain
_ o__o__ o__ O_ OO
o/,>/ ,>/ ,//,/\ ,/|
_()_\()
Y el martes 13 de febrero, Adam C Powell IV escribió:
>
> Okay, you need to upgrade your libdb2* to 2.7.7-2.2. If for some reason your apt
> front-end isn't doing this automatically (I had the same problem), lynx over to your
> favorite mirror, download and dpkg-i.
>
I've seen libdb2* 2.7.7-2.2
Y el lunes 12 de febrero, Adam C Powell IV escribió:
>
> Which release are you using? Which version of libdb2-dev?
>
> If woody/sid, you will find /usr/lib/libdb.so in libdb2-dev 2.7.7-2.2. If
> potato,
> you will find it in libc6-dev 2.1.3-15.
>
Installed packages:
ii libc6 2.2.1-1
peter karlsson wrote:
> I would prefer not to make unnecessary copies...
I think you're referring to the local repository as being unnecessary,
in which case I'd agree with you. However, if you do use local
repositories and do not have direct upstream CVS access, vendor
branchanes are far too co
On Mon, Feb 12, 2001 at 04:21:00PM -0800, Mike Markley wrote:
> IMO the best name is the one that does the best job of expressing what it's
> called without being so generic as to cause potential name conflict. I'd
> personally go with libmetakit, with -dev, -tcl, -python if you split it up.
> In g
Luis Arocha wrote:
> Y el lunes 12 de febrero, Adam C Powell IV escribió:
> >
> > Which release are you using? Which version of libdb2-dev?
> >
> > If woody/sid, you will find /usr/lib/libdb.so in libdb2-dev 2.7.7-2.2. If potato,
> > you will find it in libc6-dev 2.1.3-15.
> >
> Installed packa
Y el lunes 12 de febrero, Adam C Powell IV escribió:
>
> Which release are you using? Which version of libdb2-dev?
>
> If woody/sid, you will find /usr/lib/libdb.so in libdb2-dev 2.7.7-2.2. If potato,
> you will find it in libc6-dev 2.1.3-15.
>
Installed packages:
ii libc6 2.2.1-1
On Mon, Feb 12, 2001 at 04:21:00PM -0800, Mike Markley wrote:
> IMO the best name is the one that does the best job of expressing what it's
> called without being so generic as to cause potential name conflict. I'd
> personally go with libmetakit, with -dev, -tcl, -python if you split it up.
> In
Everything is clear now.
Thanks a lot for these explanations.
--
Jérôme Marant <[EMAIL PROTECTED]>
---
Debian Activity Page:
http://jerome.marant.free.fr/debian
---
Package: dpkg
Version: 1.8.3.1
Severity: minor
On Tue, Feb 13, 2001 at 09:38:35AM +0100, J?r?me Marant wrote:
> This is an extract from dpkg-statoverride manpage:
>
>`stat overrides' are a way to tell dpkg to use a different
>owner or mode for a file when a package is install
Everything is clear now.
Thanks a lot for these explanations.
--
Jérôme Marant <[EMAIL PROTECTED]>
---
Debian Activity Page:
http://jerome.marant.free.fr/debian
---
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subj
Package: dpkg
Version: 1.8.3.1
Severity: minor
On Tue, Feb 13, 2001 at 09:38:35AM +0100, J?r?me Marant wrote:
> This is an extract from dpkg-statoverride manpage:
>
>`stat overrides' are a way to tell dpkg to use a different
>owner or mode for a file when a package is instal
peter karlsson <[EMAIL PROTECTED]> writes:
> Ah. cvs-buildpackage. Yeah, that one could need some documentation. I tried
> using it once, but gave up. And I do have some CVS knowledge... :-)
I've been using it for years. All I have ever done is cut and paste
from the documentation.
jason
--
``
Chad C. Walstrom:
> The easiest way is to maintain a vendor branch in a local repository.
I would prefer not to make unnecessary copies...
> You can use the cvs-inject script provided by cvs-buildpackage to
> automate much of this. (Do an 'apt-cache show cvs-buildpackage'.)
Ah. cvs-buildpackag
Julian Gilbey <[EMAIL PROTECTED]> writes:
> No, you shouldn't do it like this. You should do:
> dpkg-statoverride --list ..., examine the output to see if a specific
> mode/uid/gid is required, and if not, then just use a chmod. *Don't*
> use dpkg-statoverride --add, for then there will be no w
peter karlsson <[EMAIL PROTECTED]> writes:
> Ah. cvs-buildpackage. Yeah, that one could need some documentation. I tried
> using it once, but gave up. And I do have some CVS knowledge... :-)
I've been using it for years. All I have ever done is cut and paste
from the documentation.
jason
--
`
Chad C. Walstrom:
> The easiest way is to maintain a vendor branch in a local repository.
I would prefer not to make unnecessary copies...
> You can use the cvs-inject script provided by cvs-buildpackage to
> automate much of this. (Do an 'apt-cache show cvs-buildpackage'.)
Ah. cvs-buildpacka
Julian Gilbey <[EMAIL PROTECTED]> writes:
> No, you shouldn't do it like this. You should do:
> dpkg-statoverride --list ..., examine the output to see if a specific
> mode/uid/gid is required, and if not, then just use a chmod. *Don't*
> use dpkg-statoverride --add, for then there will be no
38 matches
Mail list logo
