Re: latex-cjk upload to unstable ...
Aloha! Greetings from a tropical Belgium!
> > 1.
> > Sorry for keeping you waiting, but I got quite some problems with
> > dpatch. The main problem is now that because of the GPL headers
> > added upstream, the .w (and therefore also the .c) files are changed:
> > the line numbers are now augmented with 17. However, dpatch deapply
> > will fail, because upstream these line numbers haven't changed.
> > So a second "debuild" or dpatch deapply-all won't be successful.
> > You'll have to remove the directory and use dpkg-source -x again.
>
> Hm, I don't understand - can't you recreate the patches? I don't know
> whether dpatch provides any functionality for this, but at least
> manually it shouldn't be hard, only tedious.
Well, I'll change the line numbers in the .w files, and make a new
patch from it. I hope dpatch deapply will work then. If I get around
this, I'll then make another dpatch from it (I know that Debian likes
clean and pristine source tarballs ;).
> > 2.
> >> Which calls for a function:
> >> [...]
> >
> > Thanks for the function. This runs fine in a shell script, but fails
> > in the Makefile from latex-cjk-japanese-wadalb. I have tried putting
> > it on top of the Makefile, in a target, with or without tab, changing
> > $ to $$ or \$, but to no avail. So now all the commands' output is
> > redirected to a file called "log" ( >> log 2>&1; ). I think this is
> > simpler. And the log is kept intact; it won't be removed or
> > overwritten, but everything will be appended to it ( >> ).
>
> This here works in a Makefile:
>
> directory=$$HOME/src/Packages
>
>
> all:
> if ls $(directory) > log 2>&1; then \
> # if ls $(directory) > log 2>&1; false; then \
> echo done; \
> rm log; \
> else \
> echo failed; cat log; \
> fi
> echo ready
Thanks! But I don't like removing the log files, even if the
compilation successful, because there are a number of warnings that I
like to keep for everyone to see. E.g. some characters aren't
included in the 55th page of the Big5 fonts (bkai and bsmi), and a
warning is outputted.
However, such an error trapping makes it swankier and more useful
should something go wrong. So I'll definitely include it.
> > Also, latex-cjk-chinese-arphic depends on the fonts
> > ttf-arphic-{bkai00mp,bsmi00lp,gkai00mp,gbsn00lp}. But there are also
> > two new fonts by Arne Götje, ukai and uming, using Unicode and merging
> > resp. bkai+gkai and bsmi+gbsn. Both ukai and uming Debian packages
> > provide the older ttf-arphic-* package names, so debuild doesn't
> > recognize that only ukai and uming are installed, and not the original
> > (older) packages.
>
> Does that mean that the new packages claim to provide the old fonts, but
> actually don't do this? Or are they just in a different format?
Arne Götje's ttf-arphic-ukai and ttf-arphic-uming packages provide
each one TTF, ukai.ttf and uming.ttf resp. So they can coexist with
the original ttf-arphic-* files.
In my case, I recently did a clean reinstall of Linux and only
installed the ukai and uming packages. I had hoped debuild would
notice this, and give me a warning, but alas it didn't.
> > How can I force a Build-Depends on the original TTF packages instead
> > of the newer Unicode packages?
>
> It might be possible with versioned Build-Depends or alternatively with
> Build-Conflicts. However, it seems to me there's an underlying problem
> that I don't understand yet. Do the source packages for the "old" fonts
> still exist?
I have tried a versioned Build-Depends, but that doesn't work.
The source packages of the "old" fonts still exist, and are in no way
deprecated. You can download them under the names
ttf-arphic-bkai00mp, ttf-arphic-bsmi00lp, ttf-arphic-gbsn00lp and
ttf-arphic-gkai00mp; they provide resp. the TTF bkai00mp.ttf,
bsmi00lp.ttf, gbsn00lp.ttf and gkai00mp.ttf.
> > pbuilder isn't affected, but I suppose
> > other users who wish to build this package themselves will have
> > problems.
>
> Why does this not happen on pbuilder? Only because the old binary
> packages are still available?
Indeed. And there's no need (yet) to make them deprecated, because
the newer fonts are still being worked on, while the older and
original Arphic fonts are pretty much mature. Götje's team's aim is
to create unified CJK fonts which can be used in Japanese and
simplified and traditional Chinese.
Because the original Arphic font packages are still available,
pbuilder will correctly choose them instead of Götje's packages.
> > I don't want to add a Conflict line, because it isn't really
> > conflicting. It's just that it's misleading debuild.
>
> Maybe it's a bug in the new font packages to declare the provides?
Hmmm, dunno. Doesn't seem like it.
ttf-arphic-ukai for example just provides the names
ttf-arphic-bkai00mp and ttf-arphic-gkai00mp. I don't think it's
u{kai,ming}'s fault, I think it's a missing feature in dpkg.
What I could do, is to add a line in debian/rules and check whether
the original font files are installed. If not, the user will get a
message explaining the situation briefly.
> > 5.
> > Currently, latex-cjk-chinese-arphic is being pbuild'ed, and everything
> > seems okay. I have added all the necessary dependencies (e.g.
> > perl-base for latex-cjk-chinese-arphic).
>
> This is doubly strange. First of all, perl-base is in Section: base and
> has priority: required, so it should always be installed. Second, AFAIK
> perl-base is only a minimal stripped-down Perl for use in maintainer
> scripts of packages in base, and should usually not be used as a
> (build-)dependency. Anyway, in my pbuilder chroot:
>
> # dpkg -l perl perl-base
> Desired=Unknown/Install/Remove/Purge/Hold
> | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
> |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
> ||/ Name Version Description
> +++-========================-========================-================================================================
> ii perl 5.8.8-6 Larry Wall's Practical Extraction and Report Language
> ii perl-base 5.8.8-6 The Pathologically Eclectic Rubbish Lister
Well, I didn't put the perl-base dependency at first, but pbuilder
failed after an hour when it had to run "perl clonevf.pl [...]".
Then I set "perl-base (>=5.8.0)" in the Build-Dependss line and it
worked. o.O?
Next time I do a pbuild, I'll remove perl-base again and see what
happens then. Perhaps an updated pbuilder will do wonders.
> > OK, I added
> > #include <stdlib.h>
> > #include <string.h>
> > to wftodm.c (as suggested by Fredrik Roubert) and the warnings have
> > gone. But it still segfaults. :/
> >
> > Or do I have to try an ia32 chroot like in
> > http://alioth.debian.org/docman/view.php/30192/21/debian-amd64-howto.html#id271960
> > and do a debuild there? What about pbuilder then, do I also have to
> > do it within that chroot?
>
> No, I don't think that you need a different-architecture chroot. You
> want to build native amd64 binaries and run them on amd64, don't you?
> AFAIK, these chroots are only for software that cannot be fixed to
> compile on amd64, or not even rebuilt at all (non-free plugins, Opera,
> etc.).
I certainly want 64-bittiness. It's so much faster than my old
compy.
> Here on i386 it doesn't segfault. Maybe you should ask on the amd64
> list?
I'll do that.
> > If successful on ia32 and ready to be uploaded, how will the Debian
> > machines know that for AMD64 it has to be built inside such a chroot?
> > Or is that the responsibility of the end user to build this package in
> > his/her own chroot?
>
> No, the package must be built on the Debian buildds.
So there's no way I could force Debian's AMD64 machine to build in an
ia32 chroot.
Hmmm, I get the feeling that this package will be very polished when
it's released. I like building cathedrals. ;D
Best regards
Danai SAE-HAN
韓達耐
--
题目:《画眉鸟》
作者:欧阳修（１００７－１０７２）
百啭千声随意移，山花红紫树高低。
始知锁向金笼听，不及林间自在啼。
Reply to: