From: [email protected]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Just to note that there is progress on fixing this RC bug.

I've implemented a strip wrapper that autodetects correct strip binary
for given args; it basically works.
It needs some more testing and fixes (i.e. proper ar archives handling),
and proper integration into dpkg-cross.
I hope to have this finished today or tomorrow.

The fix is ready.
Unfortunatly can't commit now, due to some problem at alioth.debian.org: ssh_exchange_identification: Connection closed by remote host
cvs [add aborted]: end of file from server (consult above messages if any)
Will commit later.

Nikita
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBJZZOsTbPknTfAB4RAo7KAJ9ewbkcDbpM0fCdHzf0I6ZVe56YywCgi2Ef 19Vfu8VBOZLeGlHtHpbSuys=
=jLa3
-----END PGP SIGNATURE-----


--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]

--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)

From: [email protected]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Just to note that there is progress on fixing this RC bug.

I've implemented a strip wrapper that autodetects correct strip binary
for given args; it basically works.
It needs some more testing and fixes (i.e. proper ar archives
handling), and proper integration into dpkg-cross.
I hope to have this finished today or tomorrow.

The fix is ready.
Unfortunatly can't commit now, due to some problem at alioth.debian.org: ssh_exchange_identification: Connection closed by remote host
cvs [add aborted]: end of file from server (consult above messages if
any) Will commit later.

Still can't commit :(
For now, I've uploaded dpkg-cross 1.17.2 to my repository at http://zigzag.lvk.cs.msu.su/~nikita/debian

Please review.
David, if/when you will upload to debian, please check how I handle old diversion removing in postinst. I couldn't think of anything better :(.

dpkg-cross (1.17.2) unstable; urgency=low

* Added strip wrapper that tries to detect architectures of given
binaries and call appropriate strip programs.
Modified dpkg-buildpackage wrapper to add strip wrapper to PATH.
Removed dh_strip wrapper and diversion of dh_strip (Closes: #265620).
* Stop adding /usr/local/bin to path - user who needs it probably
already has it.
* Removed ancient dpkg-cross-convert - it is already 5 years old,
and is probably not compatable with current dpkg-cross.
* Note at the top of README.Debian that information there is outdated.
* Fix a typo in dpkg-cross script that caused '-aarm' not work.
* Depend on 'binutils' and on 'file' because scripts use programs
provided
by those packages.

-- Nikita V. Youshchenko <[email protected]> Fri, 20 Aug 2004 10:00:06
+0400

dpkg-cross (1.17.1) unstable; urgency=low

Changes by Raphael Bossek <[email protected]>

* Added gccross as wrapper for cross-compilers.
* Fixed proceeding of /usr/(src|lib) directories with dpkg-cross.

-- Nikita V. Youshchenko <[email protected]> Thu, 22 Jul 2004 23:38:12
+0400

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBJlgbsTbPknTfAB4RAscuAKC1CS8OTIw44N3mnHaqn/Hxi3zcawCgtHpJ 1fkn2cPf1aqvRfd3WvhG9X8=
=O9mN
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)

From: [email protected]

Package: dpkg-cross
Version: 1.17
Severity: serious

dpkg-cross is in violation of my copyright. It also causes some packages
to fail to build from source. And this was all done in a way that is a
serious violation of Debian's best practices.


1. dpkg-cross is in violation of my copyright. You include in this
package a /usr/bin/dh_strip (diverting the one in debhelper). This
program is a lightly modified version of dh_strip from debhelper. Your modifications included claiming copyright over the program, removing my authorship statements, and not including a notice of my copyright
anywhere in your package. This is a violation of my rights under
copyright law, and a violation of the GPL. The modified dh_strip claims:

# dh_strip - Modified verion of dh_strip for dpkg-cross
# Copyright (C) 2004 Raphael Bossek <[email protected]>

This is incorrect, the correct copyright notice is:

Debhelper is written by and copyright 1997-2004 Joey Hess <[email protected]>.

I insist that you honor my copyright, leave my name on the program, and
don't try to claim something that is not substantially your work as your
own.


2. dpkg-cross causes some packages to fail to build from source. Since dpkg-cross diverts /usr/bin/dh_strip with a program of its own, incompatabilities between that program and the standard dh_strip found
in debhelper will cause packages that build-depend on an appropriate
version of debhelper to get a dh_strip that behaves differently than
they expect. This can cause failure to build from source.

The immediate problem is that since you copied dh_strip and modified it,
I have fixed bug #246366. Therefore, if dpkg-cross is installed and
someone attempts to build libc on the hurd, it will fail as described in
that bug.

The long range problem is that you have no mechanism to keep this script
in sync with the one in the latest version of debhelper, let alone
with whatever version of debhelper is actually installed on a machine
along with dpkg-cross to satisfy some package's build dependencies. This
is a long string of accidents waiting to happen, I have to wonder WTF
you were thinking..

Until this bug is addressed somehow, debhelper will simply conflict with dpkg-cross to work around it. Of course this makes dpkg-cross somewhat useless..


3. And this was all done in a way that is a serious violation of
Debian's best practices. It is established practice in Debian to
communicate with a package's maintainer before diverting a file from
that package. After all, the maintainr deserves to know about it, they
need to know to redirect bugs to the diverting package, and they may
even have a better idea that doesn't call for a diversion. I can find no
record in my mail archive for this year of you trying to contact me
about diverting dh_strip before you made this change.

If you had contacted me, I would have objected to your diversion on the
grounds of 2. above. I would have referred you to previous discussion
about making dh_strip use a different strip program (hint: it's trivial;
it runs whatever is first in PATH). I would have pointed out that binutils-multiarch contains a multiple architecture strip which works
with dh_strip.

--
see shy jo

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFBHWVSd8HHehbQuO8RAp3IAKDgcCBCp9fYiob1R4I3YGZUD5FxiQCdHqqR fH/jM6fgw3J3HM4B7kDLrxE=
=4Cpb
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)

From: [email protected]

On Fri, Aug 13, 2004 at 10:05:22PM -0300, Joey Hess wrote:

1. dpkg-cross is in violation of my copyright. You include in this
package a /usr/bin/dh_strip (diverting the one in debhelper). This
program is a lightly modified version of dh_strip from debhelper. Your modifications included claiming copyright over the program, removing my authorship statements, and not including a notice of my copyright
anywhere in your package. This is a violation of my rights under
copyright law, and a violation of the GPL. The modified dh_strip claims:

# dh_strip - Modified verion of dh_strip for dpkg-cross
# Copyright (C) 2004 Raphael Bossek <[email protected]>

There's no copyright statement on the original. However, there is
no excuse for not adding at least _something_ about where it was
derived from. Please feel free to flame him. (And tell him to fix
the file in CVS.)

If you had contacted me, I would have objected to your diversion on the grounds of 2. above. I would have referred you to previous discussion
about making dh_strip use a different strip program (hint: it's trivial;
it runs whatever is first in PATH). I would have pointed out that binutils-multiarch contains a multiple architecture strip which works
with dh_strip.

Perhaps you forgot that you were contacted in bug #252931? These
people have work to get done, and you brushed off the patches that
got that work done. And now you complain that they did it
incorrectly.

Excuse me as I call the poison control center about the irony
overdose.



dave...



--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]

--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)

From: [email protected]

David Schleef wrote:

# dh_strip - Modified verion of dh_strip for dpkg-cross
# Copyright (C) 2004 Raphael Bossek <[email protected]>

There's no copyright statement on the original.

debhelper contains a package-wide copyright statement.

If that's not good enough for you, anyone on debian-legal will tell you
that in the absense of a formal statement of copyright, the author of a
work retains copyright, and that it is then licensed under a very strict default license.

If you feel that the way I have arranged debhelper's copyright statement
means that dh_strip is not covered by
/usr/share/doc/debhelper/copyright, then I look forward to the RC bug
against debhelper for containing non-DFSG free software.

Perhaps you forgot that you were contacted in bug #252931? These
people have work to get done, and you brushed off the patches that
got that work done. And now you complain that they did it
incorrectly.

Unlike some maintainers, I don't take patches when they complicate a
program to no good end.

Bug #252931 is some of the previous discussion I was referring to. So
are bugs #221700, #229190, #66564, #154214, and #217222. #154214 even
mentions how dpkg-cross's dpkg-buildpackage gets PATH wrong. But nothing
in bug #252931 says anything about diverting dh_strip.

Excuse me as I call the poison control center about the irony
overdose.

How would you feel if someone theoretically involved in the same project
as yourself violated your copyright and introduced bugs and design
flaws while doing so? Think about it.

--
see shy jo

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFBHYKed8HHehbQuO8RAsfWAJ0ZHlf0nhnUl2PCt+0ZIz0sQiK9ZQCgzOux ZNpHXuAvBXF/vugHCfPe/Y8=
=VtXj
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)

From: [email protected]

Joey Hess wrote:

But nothing in bug #252931 says anything about diverting dh_strip.

Finally on the fourth reading I noticed Raphael Bossek's concluding
sentence, "It's so simple make dh_strip gantler and prevent and
diversion by dpkg-cross." Which I suppose is what you're referring to.

I see that Nikita V. Youshchenko started a thread on -devel about this;
I was on vacation at the time and missed it as it was not CCed to me,
and did not mention debhelper in the subject.

I'd think that someone would have thought to CC one of the 20+ messages
on debian-embedded about this to the maintainer of the package in
question, but if you want to go off and do your own thing not part of
the Debian project, that's your business.

--
see shy jo

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFBHYb6d8HHehbQuO8RAlnHAKDJysgCyKZEqjGji+yPLiEkHZZR9gCeMtAf TIR59K5347/LTTxx5YOJpxY=
=46hu
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)

From: [email protected]

On Sat, Aug 14, 2004 at 12:28:58AM -0300, Joey Hess wrote:

Finally on the fourth reading I noticed Raphael Bossek's concluding
sentence, "It's so simple make dh_strip gantler and prevent and
diversion by dpkg-cross." Which I suppose is what you're referring to.

(Actually, no, I missed that too. I was taking issue with the idea
that you've never been exposed to this issue.)

I see that Nikita V. Youshchenko started a thread on -devel about this;
I was on vacation at the time and missed it as it was not CCed to me,
and did not mention debhelper in the subject.

(Er, I missed that too.)

I'd think that someone would have thought to CC one of the 20+ messages
on debian-embedded about this to the maintainer of the package in
question, but if you want to go off and do your own thing not part of
the Debian project, that's your business.

By the way, I'm not really involved with the recent development
in dpkg-cross, I just upload the packages. I'm really happy people
are taking initiative and working on dpkg-cross, since it shows off
some of the wonderful advantages that Debian offers, particularily
the consistency of packaging.

Please forgive the removed accreditation from dh_strip -- I assume
it was not intentional, and I would hope that you assume that another
Debian developer would not have done it intentionally. Some people
(including myself) add their own copyright statement _every time_
they significantly edit a file, and they don't spend a great deal
of time figuring out why it doesn't already have a copyright block.
This is a pretty typical practice, and obviously does not imply any
malice.

As for not not CC'ing you about the entire mess, I'd like to point
out that they wrote a patch to debhelper and filed a whishlist bug,
and _you blew them off_. Given the typical response of DD's being
"Fuck off, I already said no",[1] I'm not surprised that they went off
and did the next best thing. (This doesn't reflect my own personal
experience with you, but then, they're not me. I'm just trying to
keep otherwise sane people from being pissed at each other.) I
certainly don't blame you for blowing up about it, since I'm guessing
that you spent way too much time tracking a bug caused by this. But
going off on people who are clearly trying to make Debian better, and
may not have known _how_ to do it in a better way, is not productive.
Feel free to vent to me, I have a thick skin.

(I would like to comment that the reason dpkg-cross exists at all
is because, at some point in time, the dpkg maintainer told Roman
Hodek to "fuck off" and that cross-compilation wasn't important to
Debian. Sad, since minor changes in dpkg would make cross-compilation
of Debian packages much easier.)



dave...


[1] At least, this is a feeling that I observe in new developers.



--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]

--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)

From: [email protected]

* Joey Hess <[email protected]> [2004-08-13 22:05]:

even have a better idea that doesn't call for a diversion. I can
find no record in my mail archive for this year of you trying to
contact me about diverting dh_strip before you made this change.

It was raised on debian-devel, and I objected (but maybe not clearly
enough).

Subject: request for diversion + please help to determine default targets
Date: Wed, 16 Jun 2004 01:44:21 +0400

--
Martin Michlmayr
[email protected]


--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]

--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)

From: [email protected]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello.

I'm the person who committed the diversion to dpkg-cros CVS, and I'm really sorry of what has happened.

The problem was:
- - many packages use 'dh_strip', that is hardcoded to call 'strip';
- - on many systems, 'strip' binary that is in path by default used to
corrupt non-native binaries (AFAIK this is fixed in recent binutils, but
still strip program can't strip binaries for architectures it doesn't recognize);
- - situation that is (was?) there for ages is that toolchain/debhelper maintainers ask embedded developers to use binutils-multiarch, and
embedded developers don't like this idea for different reasons.

So my idea was to implement some wrapper that will force dh_strip to use correct strip binary, and to divert dh_strip with this wrapper. At that
time, I wrote a posting to -devel asking about diversion, as policy says.
I have not found in policy any instructions about CCing to anybody;
probably I could guess I should, but I didn't. A good lesson for me ...

Anyway, there was not much interest in my posting on -devel, so I thought people don't care. And it looked naturally - after all, dpkg-cross is a
tool for embedded developers; most people don't need it. So I decided that it's ok to divert.

However, I have not implemented the wrapper fast enough (we all work on
Debian when we have time to, don't we?), and Raphael came with his
solution. I didn't like it (mostly because copying a script from other
package sooner or later causes 'out-of-sync' problems), but I thought it's better that nothing, so I committed it.


Anyway, the current solution is far from being perfect from technical point
of view. For example, dh_strip is not the only way package build scripts
use to call strip (strip may be called manually, or via 'install -s', or
in some other way). So we should ensure that 'strip' in path will always handle the binaries it is called for. I propose solution (in the situation that many people don't like binutils-multiarch) to write a script that
will detect correct strip program to run and then run it (probably using different strip programs for different args), call this script 'strip' and ensure that it is in PATH before /usr/bin. I'm going to implement this as
soon as I have time to, and remove the diversion in question. To avoid
other diversions, I'll put the script somewhere
under /usr/share/dpkg-cross/, and make dpkg-buildpackage wrapper to add
the script location to the beginning of PATH.

I hope this solution will satisfy everybody envolved.

Nikita
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBIQTQsTbPknTfAB4RArvcAKCIeUouRNTtA192VUs88NHtr8ofrQCfdl+/ 3EVWh9Z4LI7HqHDVqUzUOko=
=cWP8
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)

From: [email protected]

On Monday 16 August 2004 22:02, Nikita V. Youshchenko wrote:

- - situation that is (was?) there for ages is that toolchain/debhelper maintainers ask embedded developers to use binutils-multiarch, and
embedded developers don't like this idea for different reasons.

Can you explain what are these different reasons? Disk space is a lousy
excuse with current hard drive pricing, and since the whole point of
dpkg-cross is to avoid compiling in the target, target resources shouldn't be
a problem either.

If binutils-multiarch is missing some needed arch, It would seem more usefull to everyone add the support to -multiarch rather that to everyone to have to compile their own binutils..


--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]

--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)

From: [email protected]

Can you explain what are these different reasons? Disk space is a lousy excuse with current hard drive pricing, and since the whole point of dpkg-cross is to avoid compiling in the target, target resources
shouldn't be a problem either.

I can only speek for myself. I have to deal with proprietary cross-compiler suite (HardHat). As today it should be possible to use dpkg-cross with this tools too. As the gccross wrapper uses the cross-compile configuration the strip wrapper should do the same. Use the configuration file to determine
where the right strip application resists and call it.

--
Raphael Bossek

--
NEU: WLAN-Router f�r 0,- EUR* - auch f�r DSL-Wechsler!
GMX DSL = superg�nstig & kabellos http://www.gmx.net/de/go/dsl



--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]

--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)

From: [email protected]

On Monday 16 August 2004 22:02, Nikita V. Youshchenko wrote:

- - situation that is (was?) there for ages is that
toolchain/debhelper maintainers ask embedded developers to use binutils-multiarch, and embedded developers don't like this idea for different reasons.

Can you explain what are these different reasons? Disk space is a lousy excuse with current hard drive pricing, and since the whole point of dpkg-cross is to avoid compiling in the target, target resources
shouldn't be a problem either.

If binutils-multiarch is missing some needed arch, It would seem more
usefull to everyone add the support to -multiarch rather that to
everyone to have to compile their own binutils..

I think people may answer for themselves.

I may mention following:

- binutils-multiarch don't contain cross-assemblers, so cross-binutils are needed anyway. Cross-binutils provide cross-strip; why not using it?

- although disk space is no longer a problem, internet traffic cost still
is. I don't want to download a huge package and updates that provide no additional functionality for me.


--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]

--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)

From: [email protected]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

It is a nice solution, a bit complicated though. Wouldn't it be better
to use the cross-prefix in your script/diversion. This way you don't
have to look for the correct one. The diversion has to detect if it is cross-building or not and acts accordingly. So if it is not
cross-compiled it just uses strip, if dpkg-cross is used it uses 'cross-prefix'-strip. It is just a simpler idea which might save you a
lot of "correct" strip detection stuff.

strip may be called (at least in theory) both for native and target
binaries. E.g. if someone builds a tool for use in the build process, and links is with 'gcc -s'.

I'm having bad times with autodetection. Looks that without
binutils-multiarch it is even not easy to get enough information about ELF file. Both 'file' and 'readelf' may give some information, but I still
can't find an easy way to restore debian arch binary was compiled for.
It is easy to get CPU arch and endian, but I can't find a way to
distinguish between different OSes (e.g. x86-linux and x86-hurd shared libraries). So a clean procedure that will look at binary and restore appropriate crossprefix can't be implemented :(.

Anyway, I still don't want to give up with autodetection.
As far as I understand, OS doesn't really matter for ELF format, and strip
and objdump that have support for a cpu arch, will work regtardless of OS binary was built for.
So the tool will be chosen using only arch name (x86, mips, mipsel, ...).
For any arch and for each arch tool pathname will be read
from /etc/dpkg/crosstools or ~/.dpkg/crosstools. If no information is
there, I'll have a list of crossprefix'es for each arch to try (and $crossprefix will be used as default selection in this list if it exists there); /usr/bin/strip and /usr/bin/objdump will be used if nothing better
is found.

Suggested crosstools file syntax allows tool selection based on dpkg-cross 'modes', e.g.

# <arch> <tool> <mode> <pathname>
arm strip default /usr/bin/arm-linux-strip
arm objdump default /usr/bin/arm-linux-objdump
arm strip HardHat /usr/loca/hardhat/bin/arm-linux-strip
...

Comments?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBIwDksTbPknTfAB4RAp+bAKC1BnjBTZF1pOUOY07byh8cTIBgTgCeIHhq CqfzA/uHtJd5P6njyGAd+W4=
=P5Wm
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)