severity 699206 serious
thanks
Hi Dominik,
first of all, please stop including all the email and bottom-posting,
this is a pain and against usual netiquette.
Then ...
On Mo, 30 Sep 2013, Dominik George wrote:
> If you accuse everyone else in the community
[...]
I did not accuse anyone, I ask
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Norbert Preining schrieb:
>Hi Dominik,
>
>> Simply put: Because you made no effort to fix it :).
>
>Thanks for the very useful comment.
>
>Yes, I care for RC bugs in my own packages ... and that are quite
>a lot. So no time to fix RC bugs of other
Hi Dominik,
> Simply put: Because you made no effort to fix it :).
Thanks for the very useful comment.
Yes, I care for RC bugs in my own packages ... and that are quite
a lot. So no time to fix RC bugs of other maintainers.
Norbert
--
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Norbert Preining schrieb:
>On So, 29 Sep 2013, Stephen Kitt wrote:
>> > Uninstall the libc6-amd64:i386 package.
>> > See http://lists.debian.org/debian-mentors/2013/03/msg00139.html.
>>
>> But watch out for http://bugs.debian.org/699206 - make sur
On So, 29 Sep 2013, Stephen Kitt wrote:
> > Uninstall the libc6-amd64:i386 package.
> > See http://lists.debian.org/debian-mentors/2013/03/msg00139.html.
>
> But watch out for http://bugs.debian.org/699206 - make sure you have a root
> sash running somewhere so you can relink /lib64/ld-linux-x86-6
On Sun, 29 Sep 2013 08:58:36 +0200, Sven Joachim wrote:
> On 2013-09-28 22:18 +0200, Norbert Preining wrote:
> > since a short time when I build a binary package on my running system,
> > I cannot install the created .deb anymore because it depends on
> > libc-amd64 (>= some.version) which somehow
On 29-09-13 08:40, Norbert Preining wrote:
> What is going wrong here?
For whatever reason, the amd64 build is picking up i386 paths. I don't
know how that happens, except that I expect it is some multi-arch
twitch. I recommend you build your packages in a chroot to avoid this
(an other) issues. I
On 2013-09-28 22:18 +0200, Norbert Preining wrote:
> since a short time when I build a binary package on my running system,
> I cannot install the created .deb anymore because it depends on
> libc-amd64 (>= some.version) which somehow is not what I have although
> I am running amd64 sid.
Uninstal
Hi everyone,
second try, with more data ..
default package texinfo, I am importing a new upstream into my git,
no changes to debian/rules or debian/control, rebuild.
>From the debian/control:
..
Package: info
...
Architecture: any
Multi-Arch: foreign
...
After building the package looks like:
i
On Sun, Sep 29, 2013 at 12:18:03AM +0400, Norbert Preining wrote:
> since a short time when I build a binary package on my running system, I
> cannot install the created .deb anymore because it depends on
>libc-amd64 (>= some.version)
> which somehow is not what I have although I am running am
On Fri, Mar 30, 2012 at 14:08:33 +0100, Roger Leigh wrote:
> Would there not be some advantage to making dpkg-buildpackge the
> interface for building? (Not dropping the debian/rules interface,
> of course.) This would permit the automatic setting of all the
> host- and build-related variables w
+++ peter green [2012-03-29 20:06 +0100]:
> >Now, you can build packages without using dpkg-buildpackage by calling
> >rules directly, and in that case the rules file would need to call
> >dpkg-architecture, but someone would have to convince me that that was
> >an interface worth supporting for no
On Fri, 30 Mar 2012, Neil Williams wrote:
> > Honestly I have never seen anyone doing cross-builds and calling
> > debian/rules manually.
>
> ... only because it *always* fails
>
> I have longed for such support myself at times. It is incredibly
> frustrating to see a cross-build fail 90% of
On Mar 30, 2012 8:40 AM, "Goswin von Brederlow" wrote:
>
> Hopefully dpkg-buildpackage will stop setting those varibales at some
> point so sources that wrongfully depend on the variables being set
> actualy break.
Already happened in version 1.16.1 (#560070).
On Thu, Mar 29, 2012 at 09:58:41PM +0200, Julien Cristau wrote:
> On Thu, Mar 29, 2012 at 19:10:05 +0100, Wookey wrote:
>
> > Should a package depending on this behaviour build-dep on a particular
> > dpkg version? As it already works in build-essential in stable do the
> > same rules apply as ess
Wookey writes:
> +++ Raphael Hertzog [2012-03-29 21:06 +0200]:
>> Hi,
>>
>> On Thu, 29 Mar 2012, Wookey wrote:
>> > Anyone know when this happened and what if any, the limitations are?
>> > It's certainly true in wheezy, squeeze, precise and oineiric.
>>
>> This has always been the case ever s
On Fri, 30 Mar 2012 08:06:56 +0200
Raphael Hertzog wrote:
> On Thu, 29 Mar 2012, Wookey wrote:
> > Well, perhaps I shouldn't (and indeed I'd like us to get to a point
> > where we don't), but currently, in practice, non-native builds need
> > other things setting in the environment anyway so even
On Thu, 29 Mar 2012, Wookey wrote:
> > But you should not rely on this because calling debian/rules directly
> > must be supported.
>
> Hmm, but if a package cannot use the variables set by
> dpkg-buildpackage and must set them itself, what is the point of
> dpkg-buildpackage setting them? To save
+++ Raphael Hertzog [2012-03-29 21:06 +0200]:
> Hi,
>
> On Thu, 29 Mar 2012, Wookey wrote:
> > Anyone know when this happened and what if any, the limitations are?
> > It's certainly true in wheezy, squeeze, precise and oineiric.
>
> This has always been the case ever since dpkg-architecture has
On Thu, Mar 29, 2012 at 19:10:05 +0100, Wookey wrote:
> Should a package depending on this behaviour build-dep on a particular
> dpkg version? As it already works in build-essential in stable do the
> same rules apply as essential packages in stable (i.e no explicit
> dependency required)? That wo
Now, you can build packages without using dpkg-buildpackage by calling
rules directly, and in that case the rules file would need to call
dpkg-architecture, but someone would have to convince me that that was
an interface worth supporting for non-native builds
The big reason it's worth supporting
Hi,
On Thu, 29 Mar 2012, Wookey wrote:
> Anyone know when this happened and what if any, the limitations are?
> It's certainly true in wheezy, squeeze, precise and oineiric.
This has always been the case ever since dpkg-architecture has been
introduced.
But you should not rely on this because c
Hi Wookey,
Wookey wrote:
> I recently noticed that when building with dpkg-buildpackage there is
> no need for the
>
> DEB_BUILD_GNU_TYPE := $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
> DEB_HOST_GNU_TYPE := $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
Don't you mean "?="?
[...]
Ok, thank you for clarifying.
I have subscribed myself to the bug 629385
Anton
On Wed, Dec 7, 2011 at 5:34 PM, Roger Leigh wrote:
> On Wed, Dec 07, 2011 at 05:17:47PM +0100, Anton Gladky wrote:
>> Thank you, Roger, for your extended response.
>>
>> > What is preventing you from building the d
On Wed, Dec 07, 2011 at 05:17:47PM +0100, Anton Gladky wrote:
> Thank you, Roger, for your extended response.
>
> > What is preventing you from building the docs in build-indep?
> I am trying it to do it now, using new -indep and -arch options.
>
> > Are you using the latest debhelper?
> Yes, 8.
Thank you, Roger, for your extended response.
> What is preventing you from building the docs in build-indep?
I am trying it to do it now, using new -indep and -arch options.
> Are you using the latest debhelper?
Yes, 8.9.11
I have simplified debian/rules:
On Tue, Dec 06, 2011 at 05:53:55PM +0100, Anton Gladky wrote:
> Hi all,
>
> I have an eigen3 package, which uses --before option to escape
> DOC-building on all platforms.
> debian/rules is looking so now:
>
>
> binary-indep:
> dh $@ --buildsystem=cmake
On Wed, Apr 22, 2009 at 10:32:27AM +0200, Raffaele Morelli wrote:
> Just did it on another machine with libgdal1-1.5, but I need this support
> for libgdal1-1.4* on another one.
> Does gdal-ecw plugin works for previous gdal releases?
>
No, you need to change a bit patches for that,
and anyway if
2009/4/22 Francesco P. Lovergine
> On Tue, Apr 21, 2009 at 10:18:59AM +0200, cassiel wrote:
> > Hi you all,
> >
> > don't know if this could be regarded as off topic, however it involves
> > debian package building system.
> >
> > I am trying to build gdal libraries with ECW support (
> > http://
On Tue, Apr 21, 2009 at 10:18:59AM +0200, cassiel wrote:
> Hi you all,
>
> don't know if this could be regarded as off topic, however it involves
> debian package building system.
>
> I am trying to build gdal libraries with ECW support (
> http://trac.osgeo.org/gdal/wiki/ECW) because this compre
Raphael Hertzog <[EMAIL PROTECTED]> writes:
> 2/ Otavio was sort of acknowledging it as a good thing but a good thing
> that should be delayed for an unknown amount of time waiting for a fix on
> apt's side while the lack of fix didn't seem to create important problems
>
> Under those conditions,
Hi,
On Sun, 24 Feb 2008, Ian Jackson wrote:
> Raphael Hertzog writes ("Re: dpkg-buildpackage now reorganizing
> debian/control Dependsfield??"):
> > I won't revert anything unless you come up with some proof that this
> > causes severe issues that will
"David Paleino" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
Il giorno Fri, 22 Feb 2008 10:04:52 -0300
Otavio Salvador <[EMAIL PROTECTED]> ha scritto:
As I said, for APT, the order has meaning _always_.
apt-get install foo bar
Is completely different of
apt-get install bar f
Raphael Hertzog writes ("Re: dpkg-buildpackage now reorganizing debian/control
Depends field??"):
> I can certainly change dpkg-shlibdeps to define ${shlibs:Depends} that way.
> For other variables, it's more difficult (substition variables do not
> always conta
Raphael Hertzog writes ("Re: dpkg-buildpackage now reorganizing debian/control
Depends field??"):
> I won't revert anything unless you come up with some proof that this
> causes severe issues that will disturb the lenny release process.
I think this is the wrong approac
On Fri, Feb 22, 2008 at 06:23:28PM -0800, Daniel Burrows wrote:
> Would it be possible to only re-order elements that were introduced by
> a variable substitution? That would make the list deterministic without
> changing what the maintainer wrote.
At best you could:
(a) sort substvar
On Fri, Feb 22, 2008, Raphael Hertzog wrote:
> 2/ debdiff uses wdiff to show changes on field values and wdiff gives
> spurious differences if the sole difference between both values is
> a different order. Thus debdiff output is more useful with ordered Depends
> fields.
(Probably stating the ob
On 23/02/2008, Matthew Johnson wrote:
> On Sat Feb 23 12:02, Kumar Appaiah wrote:
> > So, I want to build against the reference lapack and blas, and then,
> > if the user chooses, then I want the alternatives system to enable the
> > use of atlas. Now, the new dpkg-source reordering installs atl
On Fri, 22 Feb 2008, Daniel Burrows wrote:
> On Fri, Feb 22, 2008 at 08:50:37PM +0100, Raphael Hertzog <[EMAIL PROTECTED]>
> was heard to say:
> > No, Sergei is right. The order of packages within ${shlibs:Depends} is not
> > defined, you're not completely avoiding the problem by reverting the
> >
On ven, 2008-02-22 at 21:55 +0100, Raphael Hertzog wrote:
> On Fri, 22 Feb 2008, Mike Bird wrote:
> > What please is the benefit of unnecessarily reordering dependencies
> > and leaving everyone on tenterhooks as to whether it will change
> > installation outcomes? (If this has already been explai
On Sat Feb 23 12:02, Kumar Appaiah wrote:
> So, I want to build against the reference lapack and blas, and then,
> if the user chooses, then I want the alternatives system to enable the
> use of atlas. Now, the new dpkg-source reordering installs atlas as
> well during build, which causes the "smar
On 23/02/2008, Colin Tuckley wrote:
> In the gFortran transition we have come across some cases where this
> happens, depending on the order specified for depends you either get a
> specialist (requested) package, or if you don't care which maths lib for
> example is used by the package then yo
On Fri, Feb 22, 2008 at 08:50:37PM +0100, Raphael Hertzog <[EMAIL PROTECTED]>
was heard to say:
> On Fri, 22 Feb 2008, Otavio Salvador wrote:
> > "Sergei Golovan" <[EMAIL PROTECTED]> writes:
> > > Then having a unique, well-defined order of packages in Depends is a
> > > good idea. If packages are
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Raphael Hertzog wrote:
> On Thu, 21 Feb 2008, Kevin B. McCarty wrote:
>> In some cases, particularly when the Depends can be satisfied by
>> different sets of alternatives, this change could have the effect of
>> changing the packages actually pulled
Raphael Hertzog wrote:
> On Fri, 22 Feb 2008, Mike Bird wrote:
>> Raphael,
>>
>> What please is the benefit of unnecessarily reordering dependencies
>> and leaving everyone on tenterhooks as to whether it will change
>> installation outcomes? (If this has already been explained I apologize
>> f
On Fri February 22 2008 12:55:31 Raphael Hertzog wrote:
> > What please is the benefit of unnecessarily reordering dependencies
> > and leaving everyone on tenterhooks as to whether it will change
> > installation outcomes? (If this has already been explained I apologize
> > for overlooking it.)
>
Raphael Hertzog writes ("Re: dpkg-buildpackage now reorganizing debian/control
Depends field??"):
> You're speaking of something that you have not understood. The order
> of packages listed in an OR has not changed... I am (of course) aware
> that the order has a meaning
On Fri, Feb 22, 2008 at 09:55:31PM +0100, Raphael Hertzog wrote:
> On Fri, 22 Feb 2008, Mike Bird wrote:
> > > I won't revert anything unless you come up with some proof that this
> > > causes severe issues that will disturb the lenny release process.
> > Raphael,
> > What please is the benefit
Hi,
On Fri, 22 Feb 2008, Mike Bird wrote:
> > I won't revert anything unless you come up with some proof that this
> > causes severe issues that will disturb the lenny release process.
>
> Raphael,
>
> What please is the benefit of unnecessarily reordering dependencies
> and leaving everyone on
On Fri, Feb 22, 2008 at 05:49:32PM +0100, David Paleino wrote:
> Il giorno Fri, 22 Feb 2008 15:30:48 +0100
> Michael Koch <[EMAIL PROTECTED]> ha scritto:
>
> > On Fri, Feb 22, 2008 at 02:54:20PM +0100, David Paleino wrote:
> > > Il giorno Fri, 22 Feb 2008 10:04:52 -0300
> > > Otavio Salvador <[EMA
On Fri February 22 2008 11:50:37 Raphael Hertzog wrote:
> On Fri, 22 Feb 2008, Otavio Salvador wrote:
> > As I said, it's a know issue and we need to fix it however it would be
> > nice to not get the problem worse changing the package dependencies
> > ordering at build time, at least for now.
>
>
On Fri, 22 Feb 2008, Otavio Salvador wrote:
> "Sergei Golovan" <[EMAIL PROTECTED]> writes:
> > Then having a unique, well-defined order of packages in Depends is a
> > good idea. If packages aren't sorted their order is undefined (not all
> > of the dependencies are added by hands, many of them com
Minor correction for my example 2:
Kevin B. McCarty wrote:
> Note that liblapack.so.3 (both
> versions) requires libblas.so.3; but liblapack.so.3 from lapack3 can use
> either version of libblas, while liblapack.so.3 from atlas3-base needs
> the libblas.so.3 from atlas3-base-dev.
Hi,
first let me apologize to Norbert that my original email was unclear: it
is indeed true, as Raphael notes, that dpkg-deb (or whatever) is NOT
changing the order of individual packages within an OR'ed set, only of
the packages (or OR'ed sets of packages) separated by commas.
Raphael Hertzog wr
Il giorno Fri, 22 Feb 2008 15:30:48 +0100
Michael Koch <[EMAIL PROTECTED]> ha scritto:
> On Fri, Feb 22, 2008 at 02:54:20PM +0100, David Paleino wrote:
> > Il giorno Fri, 22 Feb 2008 10:04:52 -0300
> > Otavio Salvador <[EMAIL PROTECTED]> ha scritto:
> >
> > > As I said, for APT, the order has mea
On Fri, Feb 22, 2008 at 02:54:20PM +0100, David Paleino <[EMAIL PROTECTED]> was
heard to say:
> Il giorno Fri, 22 Feb 2008 10:04:52 -0300
> Otavio Salvador <[EMAIL PROTECTED]> ha scritto:
>
> > As I said, for APT, the order has meaning _always_.
> >
> > apt-get install foo bar
> >
> > Is compl
"Sergei Golovan" <[EMAIL PROTECTED]> writes:
> On 2/22/08, Otavio Salvador <[EMAIL PROTECTED]> wrote:
>>
>> As I said, for APT, the order has meaning _always_.
>>
>> apt-get install foo bar
>>
>> Is completely different of
>>
>> apt-get install bar foo
>
> Then having a unique, well-defined ord
On Fri, Feb 22, 2008 at 02:54:20PM +0100, David Paleino wrote:
> Il giorno Fri, 22 Feb 2008 10:04:52 -0300
> Otavio Salvador <[EMAIL PROTECTED]> ha scritto:
>
> > As I said, for APT, the order has meaning _always_.
> >
> > apt-get install foo bar
> >
> > Is completely different of
> >
> > apt-
Il giorno Fri, 22 Feb 2008 10:04:52 -0300
Otavio Salvador <[EMAIL PROTECTED]> ha scritto:
> As I said, for APT, the order has meaning _always_.
>
> apt-get install foo bar
>
> Is completely different of
>
> apt-get install bar foo
Could you please elaborate on this? I know for sure that Pre-D
On 2/22/08, Otavio Salvador <[EMAIL PROTECTED]> wrote:
>
> As I said, for APT, the order has meaning _always_.
>
> apt-get install foo bar
>
> Is completely different of
>
> apt-get install bar foo
Then having a unique, well-defined order of packages in Depends is a
good idea. If packages aren'
Raphael Hertzog <[EMAIL PROTECTED]> writes:
> On Fri, 22 Feb 2008, Otavio Salvador wrote:
>> Please, revert this change.
>
> No. I don't see any good reason for that:
>
> 1/ I have yet to see a major breakage due to that, the worst has
> been changed dependencies on a built package due to choices
Raphael Hertzog <[EMAIL PROTECTED]> writes:
> On Fri, 22 Feb 2008, Norbert Preining wrote:
>> On Fr, 22 Feb 2008, Raphael Hertzog wrote:
>> > I can understand it might change the list of packages pulled, but both set
>> > are supposed to work since that what dependencies are expressing. If you
>>
Hi Raphael,
On Fr, 22 Feb 2008, Raphael Hertzog wrote:
> You're speaking of something that you have not understood. The order
> of packages listed in an OR has not changed... I am (of course) aware
> that the order has a meaning in that case.
That is what could be easily understood of the previou
On Fri, 22 Feb 2008, Norbert Preining wrote:
> On Fr, 22 Feb 2008, Raphael Hertzog wrote:
> > I can understand it might change the list of packages pulled, but both set
> > are supposed to work since that what dependencies are expressing. If you
>
> I disagree. Sometimes alternatives are something
On Fr, 22 Feb 2008, Raphael Hertzog wrote:
> I can understand it might change the list of packages pulled, but both set
> are supposed to work since that what dependencies are expressing. If you
I disagree. Sometimes alternatives are something we put in to help
transition. We have
... texl
Hi,
On Thu, 21 Feb 2008, Kevin B. McCarty wrote:
> I've just noticed that packages I've built recently have had the list of
> Depends reorganized into ASCIIbetical order in the generated binary
> .debs. I guess this was the next logical step after having dpkg-dev
> re-order Build-Depends internal
"Kevin B. McCarty" <[EMAIL PROTECTED]> writes:
> In some cases, particularly when the Depends can be satisfied by
> different sets of alternatives, this change could have the effect of
> changing the packages actually pulled in by apt-get or aptitude. I will
> be happy to post a couple such examp
On Sun, Aug 11, 2002 at 07:52:04PM +0200, Daniel Kobras wrote:
> On Sun, Aug 11, 2002 at 01:29:19PM -0400, Matt Zimmerman wrote:
> > On Sun, Aug 11, 2002 at 02:12:25PM +0200, Daniel Kobras wrote:
> > > Rather 'chmod +x /usr/bin/make' according to the error message. Weird.
> >
> > It is a confusi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sunday 11 August 2002 20:03, Paul Cupis wrote:
> On Sunday 11 August 2002 18:52, Daniel Kobras wrote:
> > % chmod a-x debian/rules
>
> *Ahem*
>
> chmod a+x debian/rules
Never mind.
/me smacks himself
Paul Cupis
- --
[EMAIL PROTECTED]
-BEGIN
On 11/08/2002 Daniel Kobras wrote:
> % chmod a+x debian/rules
> % sudo chmod a-x /usr/bin/make
First line right, second is moronic. /usr/bin/make is a binary, it must
be executable.
bye
mejo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sunday 11 August 2002 18:52, Daniel Kobras wrote:
> % chmod a-x debian/rules
*Ahem*
chmod a+x debian/rules
Paul Cupis
- --
[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE9VrUQIzuKV+SHX/kRAuugAJ9rpyEw
On Sun, Aug 11, 2002 at 01:29:19PM -0400, Matt Zimmerman wrote:
> On Sun, Aug 11, 2002 at 02:12:25PM +0200, Daniel Kobras wrote:
> > Rather 'chmod +x /usr/bin/make' according to the error message. Weird.
>
> It is a confusing (confused) error message. The permission problem is with
> the script,
On Sun, Aug 11, 2002 at 02:12:25PM +0200, Daniel Kobras wrote:
> On Sun, Aug 11, 2002 at 02:05:23PM +0200, Bart Schuller wrote:
> >
> > chmod +x debian/rules
>
> Rather 'chmod +x /usr/bin/make' according to the error message. Weird.
It is a confusing (confused) error message. The permission p
On Sun, Aug 11, 2002 at 11:54:34PM +1200, Adam Warner wrote:
> Could someone please help me interpret this clisp 2.28 build error:
>
> $dpkg-buildpackage -rfakeroot
> dpkg-buildpackage: source package is clisp
> dpkg-buildpackage: source version is 1:2.28-1
> dpkg-buildpackage: source maintainer
Hi Bart Schuller,
>> sh: debian/rules: /usr/bin/make: bad interpreter: Permission denied
>
> chmod +x debian/rules
Of course! Thanks Bart and Daniel.
The resulting diff of debian/rules to compile in POSIX regular expression
support for CLISP is below.
28a29
> --with-module=rege
Michael Meskes wrote:
:
: Heiko Schlittermann writes:
: > Perhaps someone should release dpkg_1.4.1 ... If there are no
: > voluntaries, I'd do it.
:
: But please name it 1.4.0.1 (as Ian proposed). :-)
yea, it was a typo -- I meant 1.4.0.1 :-)
: Anyway, there's another nasty problem with dpkg-
On Thu, 19 Sep 1996, Dale Scheetz wrote:
> On Thu, 19 Sep 1996, Heiko Schlittermann wrote:
>
> > @@ -710,6 +710,7 @@
> > "listed by tar as \`$_'");
> > $fn= $filesinarchive[$efix++]; $mode= $1;
> > if ($mode =~ m/^l/) { $_ =~ s/ -\> .*//; }
> > +if (/
Heiko Schlittermann wrote:
> Yes, dpkg-source bails out if tar reports hardlinks:
And if tar converts non ascii-characters in file names to octal representation.
This happens with the kbd package which has a file with a Unicode-encoded
name for demonstration purposes.
I have already reported this
Heiko Schlittermann writes:
> Perhaps someone should release dpkg_1.4.1 ... If there are no
> voluntaries, I'd do it.
But please name it 1.4.0.1 (as Ian proposed). :-)
Anyway, there's another nasty problem with dpkg-buildpackage, namely that is
doesn't quote the commands executed via $rootcomman
Michael Meskes wrote:
:
: > dpkg-source -b joe-2.8
: > dpkg-source: building joe using existing joe_2.8.orig.tar.gz
: > dpkg-source: building joe using existing joe_2.8.orig.tar.gz
: > dpkg-source: error: tarfile `joe_2.8.orig.tar.gz' contains unexpected
: > object listed by tar as `-rw-r--r-- roo
On Thu, 19 Sep 1996, Heiko Schlittermann wrote:
> @@ -710,6 +710,7 @@
> "listed by tar as \`$_'");
> $fn= $filesinarchive[$efix++]; $mode= $1;
> if ($mode =~ m/^l/) { $_ =~ s/ -\> .*//; }
> +if (/ link to /) { $_ =~ s/ link to .*//; }
> substr
On Thu, 19 Sep 1996, Heiko Schlittermann wrote:
> : If you figure out what's going on here can you let me know? I've run
> : into the same problem while rebuilding for m68kers and was unable to
> : determine the cause.
>
> Until Ian is back, you'll might use my diff as appended
> Heiko
Coo
llucius wrote:
:
: On Wed, 18 Sep 1996, Dale Scheetz wrote:
: > dpkg-source: building joe using existing joe_2.8.orig.tar.gz
: > dpkg-source: building joe using existing joe_2.8.orig.tar.gz
: > dpkg-source: error: tarfile `joe_2.8.orig.tar.gz' contains unexpected
: > object listed by tar as `-rw-r
On Thu, 19 Sep 1996, Michael Meskes wrote:
> > dpkg-source: error: tarfile `joe_2.8.orig.tar.gz' contains unexpected
> > object listed by tar as `-rw-r--r-- root/users0 Jan 22 22:45 1995
> > joe-2.8.orig/jmacsrc link to joe-2.8.orig/.jmacsrc', expected
> > `joe-2.8.orig/jmacsrc'
> > dpkg-
Dale Scheetz writes:
>
> I am converting the joe package to the new source format and have run into
> a strange problem. The first time I run dpkg-buildpackage the .orig tree
> is tarred up ok. The second time I run it, it tries to use the tar.gz file
> created in the previous run but fails, givin
On Wed, 18 Sep 1996, Guy Maor wrote:
> On Wed, 18 Sep 1996, Dale Scheetz wrote:
>
> > I am converting the joe package to the new source format and have run into
> > a strange problem.
>
> What version of tar are you using? tar 1.11.11 is a beta that changes
> tar's behavior in all sorts of terr
On Wed, 18 Sep 1996, Dale Scheetz wrote:
> I am converting the joe package to the new source format and have run into
> a strange problem.
What version of tar are you using? tar 1.11.11 is a beta that changes
tar's behavior in all sorts of terrible ways. GNU accidentally
released it and then wi
On Wed, 18 Sep 1996, Dale Scheetz wrote:
> dpkg-source -b joe-2.8
> dpkg-source: building joe using existing joe_2.8.orig.tar.gz
> dpkg-source: building joe using existing joe_2.8.orig.tar.gz
> dpkg-source: error: tarfile `joe_2.8.orig.tar.gz' contains unexpected
> object listed by tar as `-rw-r-
Dale Scheetz writes ("Re: dpkg-buildpackage and -source questions"):
> On Fri, 30 Aug 1996, Ian Jackson wrote:
> > If you get this message [deleted]
> > you should upgrade your cpio. [...]
>
> This resolved the problem for me. At least at this point I can unpack
&g
On Fri, 30 Aug 1996, Ian Jackson wrote:
> If you get this message:
>
> dpkg-source: error: tarfile `./exmh_1.6.9.orig.tar.gz' contains object with
> newline in its name
> (exmh-1.6.9.orig/?exmh-1.6.9.orig/exmh.README?exmh-1.6.9.orig/COPYRIGHT?exmh-1.6.9.orig/e...(rest
> of output deleted)
>
>
If you get this message:
dpkg-source: error: tarfile `./exmh_1.6.9.orig.tar.gz' contains object with
newline in its name
(exmh-1.6.9.orig/?exmh-1.6.9.orig/exmh.README?exmh-1.6.9.orig/COPYRIGHT?exmh-1.6.9.orig/e...(rest
of output deleted)
You should upgrade your cpio. Unfortunately the (Debian
Karl Sackett writes ("dpkg-buildpackage and -source questions"):
> Regarding the -r option for dpkg-buildpackage, are there any
> examples of what's called for here? Is the gain-root-command
> something each developer provides for himself, or is there a command
> or shell somewhere that performs t
92 matches
Mail list logo
