On Sun, Jun 5, 2016 at 11:48 AM, Jack Howarth <howarth.at.f...@gmail.com>
wrote:
>
>
> On Sun, Jun 5, 2016 at 11:28 AM, TheSin <the...@southofheaven.org> wrote:
>
>> I haven’t tried yet so I’m not seeing it yet. But I did have lots of
>> problems with gnu vs bad tar when I started updating dpkg years ago, so I
>> know I made lots of changes to the calls. I don’t think it’s used the same
>> way at all anymore, it’s been a bit so I’ll have not go over the patch
>> again but search for tar params in the patch not execlp. In newer dpkg
>> they have their own exec functions now.
>>
>> I’ll install tar 1.28 and test it with my version to see if it happens,
>> I’ll also check in current debian see if it’s happening there and what they
>> are doing about it. I’ll try and make time to check and test it out
>> tonight.
>>
>
> I assume that you are against the newer test dpkg right? On the current
> older dpkg, the issue is easily reproduced with the test tar-1.29-1
> packaging by simply trying to rebuild it a second time after the first
> build/install of the new tar.
> Jack
> ps I wouldn't waste time with tar 1.28 as it obviously doesn't exhibit the
> regression. The priority should be to puzzle out the exact invocation of
> tar within older dpkg which is misbehaving under the new tar 1.29 release
> so we can report back upstream on that permutation.
>
One issue that really puzzles me is this. Against tar-1.29-1, the /DEBIAN
directory seems to be created during either...
Unpacking fink-buildlock-tar-1.29-1 (from
.../fink-buildlock-tar-1.29-1_2016.06.05-12.25.59_darwin-x86_64.deb) ...
or
Setting up fink-buildlock-tar-1.29-1 (2016.06.05-12.25.59) ...
however, under the tar-1.26-4 release, I don't see a DEBIAN subdirectory
being created anywhere on the volume in those steps (at least that isn't
immediately removed so that a search with 'find / . -name DEBIAN' doesn't
report its location,
>
>> ---
>> TS
>> http://www.southofheaven.org/
>> Life begins and ends with chaos, live between the chaos!
>>
>> > On Jun 5, 2016, at 9:00 AM, Jack Howarth <howarth.at.f...@gmail.com>
>> wrote:
>> >
>> >
>> >
>> > On Sun, Jun 5, 2016 at 10:47 AM, TheSin <the...@southofheaven.org>
>> wrote:
>> > our version of dpkg is FAR too old to report upstream, not to mention
>> I’m sure it is fixed upstream by now. Check the patch in my PR see if it’s
>> still needed. I haven’t had a chance but i’m gonna try it. I’m pretty
>> sure I have a test case already in dpkg 1.15.x for gnu vs bad tar at the
>> very least.
>> >
>> > Are you saying that you have already found a similar failure in dpkg
>> when using it against the tar 1.27 or 1.28 releases? Also in
>> http://fink.cvs.sourceforge.net/viewvc/fink/experimental/thesin/finkinfo/new/
>> I don't see any evidence of the execlp part of dpkg.patch since the changes
>> are all based on the newer dpkg. Since this really might represent a
>> previously unknown regression in the newer tar, we really ought to try to
>> puzzle out a reproducer to submit back upstream (assuming that this is just
>> an invocation of tar with options that no longer behaves as expected).
>> > Jack
>> >
>> > ---
>> > TS
>> > http://www.southofheaven.org/
>> > Life begins and ends with chaos, live between the chaos!
>> >
>> > > On Jun 5, 2016, at 8:35 AM, Jack Howarth <howarth.at.f...@gmail.com>
>> wrote:
>> > >
>> > > The new tar 1.29 release (which is available on fink tracker at
>> https://sourceforge.net/p/fink/package-submissions/4664/) passes its
>> test suite cleanly on x86_64-apple-darwin15 but causes fink to exhibit
>> broken behavior when installed. The problem is that, when a package is
>> built under the new tar 1.29 release, the creation of the build-lock
>> misplaces the DEBIAN control directory at the root level. This creates debs
>> that incorrectly have the DEBIAN control directory placed at root as well
>> and thus all conflict with each other.
>> > > We should try to puzzle out if the tar hacks used in dpkg.patch
>> really valid and, if so, try to create a stand-alone test case to report
>> back upstream to the bug-tar mailing list (as this glitch isn't being
>> captured by their current test suite).
>> > > Jack
>> > > ps The main changes I see here are...
>> > >
>> > > - execlp(TAR,"tar","-cf", "-", "-T", "-", "--null",
>> "--no-recursion", (char*)0);
>> > > + execlp(TAR,"tar","-cf", "-", "--null", "-T", "-",
>> "--no-recursion", (char*)0);
>> > >
>> > >
>> > > for dpkg-1.10.21/dpkg-deb/build.c.
>> > >
>> > >
>> > >
>> ------------------------------------------------------------------------------
>> > > What NetFlow Analyzer can do for you? Monitors network bandwidth and
>> traffic
>> > > patterns at an interface-level. Reveals which users, apps, and
>> protocols are
>> > > consuming the most bandwidth. Provides multi-vendor support for
>> NetFlow,
>> > > J-Flow, sFlow and other flows. Make informed decisions using capacity
>> > > planning reports.
>> https://ad.doubleclick.net/ddm/clk/305295220;132659582;e_______________________________________________
>> > > Fink-devel mailing list
>> > > Fink-devel@lists.sourceforge.net
>> > > List archive:
>> > > http://news.gmane.org/gmane.os.apple.fink.devel
>> > > Subscription management:
>> > > https://lists.sourceforge.net/lists/listinfo/fink-devel
>> >
>> >
>>
>>
>
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
_______________________________________________
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel
