Re: cttex (updated package)
Hi, Sorry for late response. Pls give me a few days to update myself with CVS and check the latest source status. Vuthichai /Hui :) On Feb 2, 2008 2:26 PM, Paul Wise <[EMAIL PROTECTED]> wrote: > On Feb 2, 2008 3:48 PM, Theppitak Karoonboonyanan <[EMAIL PROTECTED]> > wrote: > > > > In addition, it seems there is a new upstream version, or a fork or > > > something (I don't read Thai): > > > > > > http://vuthi.blogspot.com/2004/07/cttex.html > > > > > > You might want to figure out what the deal is there. > > > > It's the upstream author's blog. It seems he has forgotten > > the CVS version, leaving me think it has been abandoned. > > :-( > > Vuthichai, perhaps you could start using it again? > Or are you using another version control repository? > > -- > bye, > pabs > > http://wiki.debian.org/PaulWise >
Re: RFS: thailatex (updated package)
Oops, forgot to Cc: to list. Sorry. Regards, -- Theppitak Karoonboonyanan http://linux.thai.net/~thep/ -- Forwarded message -- From: Theppitak Karoonboonyanan <[EMAIL PROTECTED]> Date: Feb 4, 2008 10:46 AM Subject: Re: RFS: thailatex (updated package) To: Cyril Brulebois <[EMAIL PROTECTED]> On Feb 4, 2008 10:35 AM, Cyril Brulebois <[EMAIL PROTECTED]> wrote: > On 04/02/2008, Theppitak Karoonboonyanan wrote: > > Yet another small update with unchanged version number: Build-dep on > > dpkg-dev (>= 1.14.13), for proper support of the Vcs-Cvs field. > > I wouldn't care so much. Either you're building for unstable or > experimental, and that's guaranteed already; or you're building a > backport of whatever, for which those fields are AFAICT quite > irrelevant. And dpkg is quite cool, and should only discard > unrecognized fields, and shouldn't fail because of them. dpkg (>= 1.14.13) allows control filed values to begin with colon, which is required for CVSROOT. Probably what we need here is Build-Recommends. :P Regards, -- Theppitak Karoonboonyanan http://linux.thai.net/~thep/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: thailatex (updated package)
On 04/02/2008, Theppitak Karoonboonyanan wrote: > Yet another small update with unchanged version number: Build-dep on > dpkg-dev (>= 1.14.13), for proper support of the Vcs-Cvs field. I wouldn't care so much. Either you're building for unstable or experimental, and that's guaranteed already; or you're building a backport of whatever, for which those fields are AFAICT quite irrelevant. And dpkg is quite cool, and should only discard unrecognized fields, and shouldn't fail because of them. Cheers, -- Cyril Brulebois pgpVAEzHFl3yT.pgp Description: PGP signature
Re: RFS: swath 0.3.2-1 (updated package)
On Feb 3, 2008 10:31 AM, Theppitak Karoonboonyanan <[EMAIL PROTECTED]> wrote: > On Feb 2, 2008 1:13 PM, Theppitak Karoonboonyanan <[EMAIL PROTECTED]> wrote: > > > The package can be found on mentors.debian.net: > > - URL: http://mentors.debian.net/debian/pool/main/s/swath > > - Source repository: deb-src http://mentors.debian.net/debian unstable main > > contrib non-free > > - dget http://mentors.debian.net/debian/pool/main/s/swath/swath_0.3.2-1.dsc > > A small update: I've fixed CVSROOT in Vcs-Cvs field, so it > really works with debcheckout. Yet another small update with version number unchanged: Build-dep on dpkg-dev (>= 1.14.13), for proper support of the Vcs-Cvs field. Thanks, -- Theppitak Karoonboonyanan http://linux.thai.net/~thep/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: thailatex (updated package)
On Feb 3, 2008 10:23 AM, Theppitak Karoonboonyanan <[EMAIL PROTECTED]> wrote: > > On Jan 28, 2008 6:33 PM, Theppitak Karoonboonyanan <[EMAIL PROTECTED]> wrote: > > On Jan 27, 2008 6:18 PM, Theppitak Karoonboonyanan <[EMAIL PROTECTED]> > > wrote: > > > > > > Thanks for the check. 'cttex' has long been unmaintained upstream, > > > and I have no interest to adopt it yet. So, I have removed it from > > > thailatex dependencies for the time being. Please find the update > > > in 0.4.2-2: > > > > > > > > > http://mentors.debian.net/debian/pool/main/t/thailatex/thailatex_0.4.2-2.dsc > > > > > > Update: I just realized that I forgot to update copyright > > info for the added fonts in the new upstream version. > > So, I have fixed that in 0.4.2-3: > > > > > > http://mentors.debian.net/debian/pool/main/t/thailatex/thailatex_0.4.2-3.dsc > > > Another small update: I've fixed CVSROOT in Vcs-Cvs, > so it really works with debcheckout. Yet another small update with unchanged version number: Build-dep on dpkg-dev (>= 1.14.13), for proper support of the Vcs-Cvs field. Thanks, -- Theppitak Karoonboonyanan http://linux.thai.net/~thep/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: xf86-input-tslib (xserver-xorg-input-tslib)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Neil Williams wrote: > You missed the clean target: +clean: xsfclean -clean: Done. I also read the debian/xsfbs/xsfbs.mk. :-) > OK - when you come back, just sort out the licence information for the > files in ./m4/* because those are missing from debian/copyright. Done. > It would be nice to use the alternative format for debian/copyright too: Done. > One thing I would ask - to ease cross building support a little further, > create a > debian/xcontrol file. Done. I have uploaded 0.0.4-3 to mentors.debian.net. The package can be found with dget: http://mentors.debian.net/debian/pool/main/x/xf86-input-tslib/xf86-input-tslib_0.0.4-3.dsc - -- Wen-Yen Chuang (caleb) My GPG key is signed by Debian Developer Masayuki Hatta. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHpniBdEpXpumNYVkRAodiAJ4g7Jc0DDqu9tKdNlCniK55Xmr4QQCdFp2g tOd8b4kQTqjXk4pwPJXhadI= =4I6F -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: xf86-input-tslib (xserver-xorg-input-tslib)
On Mon, 2008-02-04 at 05:22 +0800, Wen-Yen Chuang wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Neil Williams wrote: > > On Fri, 2008-02-01 at 11:19 +0800, Wen-Yen Chuang wrote: > >> But it can not auto-generate "Provides: xserver-xorg-input-2" and > > The clue is this line in debian/rules for the kbd package: > > include debian/xsfbs/xsfbs.mk and the target 'serverabi' > > Done. > I have uploaded 0.0.4-2 to mentors.debian.net. > > The package can be found with dget: > http://mentors.debian.net/debian/pool/main/x/xf86-input-tslib/xf86-input-tslib_0.0.4-2.dsc You missed the clean target: +clean: xsfclean -clean: It's not a problem for this package but it's worth reading debian/xsfbs/xsfbs.mk so that you know what the xsfclean target does for future reference. > It provides inputabiver and serverminver correctly. > Both source and binary are lintian/linda clean. OK - when you come back, just sort out the licence information for the files in ./m4/* because those are missing from debian/copyright. This is only needed because the m4/ files contain explicit copyright notices that differ from the rest of the upstream source. It would be nice to use the alternative format for debian/copyright too: http://wiki.debian.org/Proposals/CopyrightFormat Take a look at the debian/copyright of tslib as an example. You'll be glad to know that it cross-builds OK. One thing I would ask - to ease cross building support a little further, create a debian/xcontrol file. It is a copy of debian/control but with the Build-Depends split as follows: Build-Depends: xserver-xorg-dev (>= 2:1.4), libts-dev (>= 1.0-4) Build-Depends-Tools: debhelper (>= 5), pkg-config This allows cross-building tools to easily identify which dependencies need to be installed as cross packages (i.e. which are used for linkages) and which need to be installed as build packages (i.e. which are simply tools to support the build). (In future, the debian-xcontrol package will provide more extensive support for debian/xcontrol files but emdebian-tools already contains support for the Build-Depends split.) I'm happy to upload once these changes are made. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: This is a digitally signed message part
Re: RFS: avant-window-navigator 0.2.1
Thanks a lot Cyril for this explanation, it makes more sense now :)
Using -Wl,--as-needed, I reduce the depends for 1 binary, but it's seems
not good for one other.
But I'll try to correct configure/Makefile directly, since I begin to
understand this strange thing that is autotools :)
--
Kind regards,
Julien Lavergne
jabber : [EMAIL PROTECTED]
On dim, 2008-02-03 at 20:21 +0100, Cyril Brulebois wrote:
> On 03/02/2008, Julien Lavergne wrote:
> > That's something I wanted to do, but I didn't find a good way to do
> > that. I tried to replace ${shlibs:Depends} with only necessary
> > library, but dpkg-shlibdeps still get the same warnings.
>
> Oh, no, you definitely don't want to touch that!
>
> The idea is to get rid of extra/unneeded “-lfoo -lbar …” in the
> upstream Makefile, so as to link only against the libraries that are
> actually used.
>
> Sometimes, just deleting an -lfoo would do. But more commonly, the
> build system doesn't allow you to use fine-grained library
> dependencies. That's where LDFLAGS=-Wl,--as-needed is your friend,
> since it tells the linker to forget about the unused libraries
> (resulting in less NEEDED entries, and happy dpkg-shlibdeps).
>
> *BUT* that might break the resulting binaries, since (depending on
> various things, like build/link options), you may end up with
> undefined references, which result in runtime crashes.
>
> To avoid that, you probably want to use another LDFLAG(S):
> -Wl,-z,defs, which explicitely forbids such undefined references.
>
> Note that this might still break the build system, but that *is* a
> good thing. Usually, the problem is that the intermediate builds are
> broken, since the resolution of undefined references is (again, in
> some conditions) postponed to the final linking. By using this option,
> you explicitely forbid any single undefined reference (including in
> the intermediate targets), which means that you might sometimes have
> to modify the Makefiles to add some -lfoo or -lbar, or e.g. add
> TARGET_LINK_LIBRARIES() in cmake build systems.
>
> That's a bit of work, but you'll probably end up with less
> dependencies (expressed in less Depends:), which is obviously
> (installed size, testing migration, etc.) a good thing.
>
> Cheers,
>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: avant-window-navigator 0.2.1
On 03/02/2008, Neil Williams wrote:
> Just imagine the chaos in Debian if the pkgconfig data of
> libgtk+2.0-0 was changed now. Each reverse dependency would then
> need upstream changes to add extra libs to the build that were
> previously implied. That would be just as disruptive as a full
> SONAME transition in Gtk+ itself - how long is it now since gtk1
> became gtk2? Adding a new pc file is the only realistic method that
> I can see because it supports all builds, not just Debian and the
> migration can be done incrementally.
Well, that pkgconfig modification is “your” plan, and I understand
(quite) well the implications it has, but I don't really see how it is
relevant to (not) using LDFLAGS.
> These kind of things have implications far beyond the current
> package but this is, IMHO, TheRightWay(tm) to fix things, not using
> -Wl,--as-needed.
That might be a means. But given the hell we already have, dealing
with upstreams only shipping a .la file, or not shipping any
{.la,.pc} at all, it's not the kind of modifications I'd like to
see happening know.
Again, I said LDFLAGS is a means of getting (quite safely) rid of
extra dependencies, and that it is *not* a silver bullet. Or call
“TheRightWay©®™” if you like.
> In the meantime, I think it's worth being cautious about
> recommending trimming of dependencies. Maybe applications can be
> trimmed without too many consequences but I wouldn't advise trimming
> the dependencies of a library (or library pkgconfig file) on mentors
> - which is a problem because it is with libraries where the benefits
> of trimming are most evident.
Note that I share your concerns about modifying .pc files, but also
that I didn't suggest such a change, ever; since indeed, it would
require serious testing (at least rebuilds, layer by layer, of all
r-depending packages; but also checking whether functionalities were
lost, etc.).
Besides that, I still don't get the “why we wouldn't advise…” part. If
that leads to problem(s), then that'll be reported, and fixed. But not
even *trying* to improve things looks very wrong to me. We have tools
to detect extra dependencies. We have means of getting rid of (some
of) them, others to ensure we don't introduce breakages (like
undefined references). Why not using them? Just stating “that might
not be safe” looks like FUD to me.
If you want dangerous things, I have real examples: the new symbols
feature from dpkg, which already broke several (previously working)
packages on various architectures, be it armel, kfreebsd-*, etc.
Symbols are *not* safe to be used yet, and that has been announced
since the very beginning, by porters, and that has proven to be right
since (and there are still breakages reported nowadays).
If you want another one: using --as-needed without -z,defs, for the
reasons I already mentioned. But I'm not advertising that, either.
AFAICT, the above-mentioned LDFLAGS didn't break packages until now,
and are used quite often (I'd bet see the gnome-related packages,
since lool has been advocating these options in the thread on -devel,
although I didn't check), at least on a bunch of package I maintain,
or that I'm preparing.
Not to mention that we are on -mentors, and that packages get
double-checked, by the sponsoree (which is supposed to have checked
the runtime quite seriously), and by a sponsor, who could at least
spot the use of --as-needed without -z,defs.
Really, I don't see why we shouldn't encourage people using those
options.
Cheers,
--
Cyril Brulebois
pgpUtuNNnbi31.pgp
Description: PGP signature
Re: RFS: avant-window-navigator 0.2.1
On Sun, 2008-02-03 at 22:14 +0100, Cyril Brulebois wrote:
> On 03/02/2008, Neil Williams wrote:
> > What I meant was if dependencyA appears in the dpkg-shlibdeps list
> > of "not needed" linkages for 'foo' but foo is nearly always
> > installed alongside bar which uses symbols from dependencyA (i.e.
> > dpkg-shlibdeps doesn't complain about dependencyA in the build of
> > bar), then foo probably doesn't need to be altered. It's no
> > absolutely necessary for foo to Depend on dependencyA but it doesn't
> > hurt in the majority of cases.
>
> I now see your point, but I still disagree. Say foo depends on bar,
> bar depends on baz, and there's an extra link (hence Depends) between
> foo and baz. baz gets a bumped SONAME, bar gets rebuilt (through
> binNMUs). Fine. Err, no. foo has to be rebuilt as well. Too bad.
Ah, OK. I see that. The only time foo bears being rebuilt is if the
change in baz means that the rebuilt foo can drop that Depends (maybe
via an improved pkgconfig file in baz).
> > there are also cases where dpkg-shlibdeps reports an extra linkage
> > where the library concerned is already packaged alongside a library
> > that does need to be linked against the package - libdl is the most
> > common.
>
> I agree that there are some special cases, like libdl, pthreads, and
> so on. But ISTR that whole pages were reported by dpkg-shlibdeps, not
> only a few lines.
Very common with GUI packages. I'd like to be able to trim the
dependencies of libgpewidget at some point but the main problem is not
with libgpewidget itself but with the pkgconfig file it provides. This
adds libgtk+2.0-0 to each dependency of libgpewidget. What I really want
is to be able to use:
Requires: gtk+-2.0-minimal
Libs: -L${libdir} -lgpewidget
instead of:
Requires: gtk+-2.0
Libs: -L${libdir} -lgpewidget
/usr/lib/pkgconfig/gtk+-2.0-minimal.pc would then list:
Requires: gdk-${target}-2.0
instead of:
Requires: gdk-${target}-2.0 atk cairo
and
/usr/lib/pkgconfig/gdk-directfb-2.0.pc
would support a -minimal that dropped the pango listing, etc. and maybe
a few others from the current:
Requires: gdk-pixbuf-2.0 cairo-directfb directfb pango pangocairo
then /usr/lib/pkgconfig/gdk-x11-2.0.pc could trim this list:
Requires: gdk-pixbuf-2.0 pango pangocairo
The problem is that these -minimal (and -extra) listings need to be
maintained within Gtk+, not libgpewidget.
I could just patch the libgpewidget.pc file (adding -lgtk2.0-0 to --libs
and replacing the Requires:) but I need the time to test the entire GPE
package set using that setup *and* cross build the whole set before I
can deploy such a change, it's just too disruptive to start on before
Lenny (what with the Lenny soft freeze being less than a month hence).
Just imagine the chaos in Debian if the pkgconfig data of libgtk+2.0-0
was changed now. Each reverse dependency would then need upstream
changes to add extra libs to the build that were previously implied.
That would be just as disruptive as a full SONAME transition in Gtk+
itself - how long is it now since gtk1 became gtk2? Adding a new pc file
is the only realistic method that I can see because it supports all
builds, not just Debian and the migration can be done incrementally.
These kind of things have implications far beyond the current package
but this is, IMHO, TheRightWay(tm) to fix things, not using
-Wl,--as-needed.
> > Now I'm all in favour of reducing spurious dependencies - as anyone
> > would expect whilst working on making Debian small enough for
> > embedded devices - but not at the cost of making more work for
> > myself when cross building the same package. I just want to be sure
> > the changes actually work before recommending them to others. IMHO,
> > -Wl,--as-needed -Wl,zdefs is not at that stage, yet.
>
> In the thread (on -devel) where the use of those options were
> discussed, I don't remind of people reporting broken packages due to
> that. But if you could find examples of broken packages because of
> that, I'm very interested (in having a look and eventually fixing them
> if I can do that).
I will, thanks.
In the meantime, I think it's worth being cautious about recommending
trimming of dependencies. Maybe applications can be trimmed without too
many consequences but I wouldn't advise trimming the dependencies of a
library (or library pkgconfig file) on mentors - which is a problem
because it is with libraries where the benefits of trimming are most
evident.
--
Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
signature.asc
Description: This is a digitally signed message part
Re: RFS: xf86-input-tslib (xserver-xorg-input-tslib)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Neil Williams wrote: > On Fri, 2008-02-01 at 11:19 +0800, Wen-Yen Chuang wrote: >> But it can not auto-generate "Provides: xserver-xorg-input-2" and > The clue is this line in debian/rules for the kbd package: > include debian/xsfbs/xsfbs.mk and the target 'serverabi' Done. I have uploaded 0.0.4-2 to mentors.debian.net. The package can be found with dget: http://mentors.debian.net/debian/pool/main/x/xf86-input-tslib/xf86-input-tslib_0.0.4-2.dsc It provides inputabiver and serverminver correctly. Both source and binary are lintian/linda clean. Feb 7, 2008 is the Chinese New Year. I may have no internet access during Feb 6 to Feb 11. I will keep checking mailing list on Feb 4 and 5. After that I will come back after Feb 12. Thanks to Paul, Julien, and Neil. Happy Chinese New Year! - -- Wen-Yen Chuang (caleb) My GPG key is signed by Debian Developer Masayuki Hatta. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHpjCCdEpXpumNYVkRAkfBAJ9Y4ObItcRa7R1R7xe9VL/SB4JU8gCeKv/N JfftVb6caZoO+jc4HTGPm3c= =88+t -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: avant-window-navigator 0.2.1
On 03/02/2008, Neil Williams wrote: > What I meant was if dependencyA appears in the dpkg-shlibdeps list > of "not needed" linkages for 'foo' but foo is nearly always > installed alongside bar which uses symbols from dependencyA (i.e. > dpkg-shlibdeps doesn't complain about dependencyA in the build of > bar), then foo probably doesn't need to be altered. It's no > absolutely necessary for foo to Depend on dependencyA but it doesn't > hurt in the majority of cases. I now see your point, but I still disagree. Say foo depends on bar, bar depends on baz, and there's an extra link (hence Depends) between foo and baz. baz gets a bumped SONAME, bar gets rebuilt (through binNMUs). Fine. Err, no. foo has to be rebuilt as well. Too bad. I'm not only speaking about testing migration here. That means extra libraries installed whereas the old version on baz could have gone away in a single round. There's no use having additional unneeded dependencies, even if they appear to be legit. > there are also cases where dpkg-shlibdeps reports an extra linkage > where the library concerned is already packaged alongside a library > that does need to be linked against the package - libdl is the most > common. I agree that there are some special cases, like libdl, pthreads, and so on. But ISTR that whole pages were reported by dpkg-shlibdeps, not only a few lines. > Well, it's not something I am doing for my own packages, yet, so I > don't want to push it onto those maintainers whom I sponsor when I > am not comfortable getting it to work on my own packages. I understand that, of course, but I wouldn't jump to conclusions (I'm not sure we should…) anyway. > I'm experimenting with a few things upstream where the upstream > ./configure asks for the pkg-config data but then either does some > parsing of it or substitutes a (shorter) replacement but pkg-config > exists for a good reason and (IMHO) -Wl,as-needed isn't a complete > solution to the problem (with or without zdefs). I didn't say (or at least not in these words) it was a silver bullet, but rather a workaround in the cases where simple patches against the build systems seem unreasonsable (e.g. qmake?), and as a learning experience. > the complication is that tinkering with pkg-config data like this > can trip up porters and cross builders and as my main workload is > cross building, I'm not about to break my own work. :-) I know what porting means, look in the BTS for kfreebsd-* bugs. > Now I'm all in favour of reducing spurious dependencies - as anyone > would expect whilst working on making Debian small enough for > embedded devices - but not at the cost of making more work for > myself when cross building the same package. I just want to be sure > the changes actually work before recommending them to others. IMHO, > -Wl,--as-needed -Wl,zdefs is not at that stage, yet. In the thread (on -devel) where the use of those options were discussed, I don't remind of people reporting broken packages due to that. But if you could find examples of broken packages because of that, I'm very interested (in having a look and eventually fixing them if I can do that). Cheers, -- Cyril Brulebois pgpUIuPy4cVfN.pgp Description: PGP signature
Re: RFS: avant-window-navigator 0.2.1
On Sun, 2008-02-03 at 21:21 +0100, Cyril Brulebois wrote: > On 03/02/2008, Neil Williams wrote: > > but if that extra dependency is genuinely necessary for some other > > application which would almost inevitably be installed alongside the > > package in question, then no harm is done. > > I don't buy this “genuinely necessary”. What I meant was if dependencyA appears in the dpkg-shlibdeps list of "not needed" linkages for 'foo' but foo is nearly always installed alongside bar which uses symbols from dependencyA (i.e. dpkg-shlibdeps doesn't complain about dependencyA in the build of bar), then foo probably doesn't need to be altered. It's no absolutely necessary for foo to Depend on dependencyA but it doesn't hurt in the majority of cases. There are also cases where dpkg-shlibdeps reports an extra linkage where the library concerned is already packaged alongside a library that does need to be linked against the package - libdl is the most common. Until such time as Debian packages this library outside libc[0-9], then the warning from dpkg-shlibdeps just has to be ignored because no benefit arises from removing -dl. > There are some exceptions, but > dependencies between binaries (as in executables and shared objects, > or -data packages are what I call “genuinely necessary”. I'm not going > to second-guess what is then necessary besides that. dpkg-shlibdeps is providing a more fine grained approach that can detect when a Depends: created using dh_shlibdeps is actually unnecessary. By "genuinely necessary" I was thinking of linkages that do not trigger this warning - i.e. the ones that we need to retain after trimming (whichever method is used for the trimming itself). > Blocking (or being blocked for) testing migration still hurts. Agreed. > > > That's a bit of work, but you'll probably end up with less > > > dependencies (expressed in less Depends:), which is obviously > > > (installed size, testing migration, etc.) a good thing. > > > > Agreed, it is a v.good thing. Not sure it is yet something we should > > be advising on mentors, that's all. It may well be harder than > > expected and the methods are not that user-friendly. > > Why? Maintaining a package is not (just) about making lintian happy > and uploading new versions. Getting rid of extra dependencies is IME a > very good learning experience, and I wish it would be the kind of > questions asked during T&S (at least: I'd have been glad to have to > work on this kind of problem). > > And it's (still IMHO) a very good occasion to learn about linker > flags, and possibly have a deeper view on how autotools, cmake, scons > (erk) deal with that. Well, it's not something I am doing for my own packages, yet, so I don't want to push it onto those maintainers whom I sponsor when I am not comfortable getting it to work on my own packages. I'm experimenting with a few things upstream where the upstream ./configure asks for the pkg-config data but then either does some parsing of it or substitutes a (shorter) replacement but pkg-config exists for a good reason and (IMHO) -Wl,as-needed isn't a complete solution to the problem (with or without zdefs). The complication is that tinkering with pkg-config data like this can trip up porters and cross builders and as my main workload is cross building, I'm not about to break my own work. :-) Now I'm all in favour of reducing spurious dependencies - as anyone would expect whilst working on making Debian small enough for embedded devices - but not at the cost of making more work for myself when cross building the same package. I just want to be sure the changes actually work before recommending them to others. IMHO, -Wl,--as-needed -Wl,zdefs is not at that stage, yet. A better solution, (probably) would be for big library packages to become more modular so that several pkg-config files are provided and applications are free to select libfoo-mini.pc or libfoo-default.pc or libfoo-extra.pc - lengthening the pkgconfig --libs data in each one. (The "missing" libs would migrate into Libs.private:) Getting that to work means creating decent management tools for the pc files for use upstream. Changing things just in Debian is not a long-term solution, IMHO (and will dramatically complicate the lives of those who are migrating Debian to new environments like embedded but also existing ones like Ubuntu et al). -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: This is a digitally signed message part
Re: RFS: avant-window-navigator 0.2.1
On 03/02/2008, Neil Williams wrote:
> > Note that this might still break the build system, but that *is* a
> > good thing.
>
> (Agreed, but is probably easier to fix upstream than in Debian,
> YMMV).
Well, if you're packaging something, basic understanding on what the
code is doing, what submodules exist and so on, is expected. That's
IMHO a very good way to get more and more familiar with upstream's
code. And helping upstream fix this kind of problem is usually very
welcome (beside being part of the maintainer's job — I mean: working
together with upstream).
> but if that extra dependency is genuinely necessary for some other
> application which would almost inevitably be installed alongside the
> package in question, then no harm is done.
I don't buy this “genuinely necessary”. There are some exceptions, but
dependencies between binaries (as in executables and shared objects,
or -data packages are what I call “genuinely necessary”. I'm not going
to second-guess what is then necessary besides that. If there are more
to come, that should be in Depends: anyway (like the -bin of a
library, in addition to ${shlibs:Depends}), or Recommends or whatever.
Blocking (or being blocked for) testing migration still hurts.
> > That's a bit of work, but you'll probably end up with less
> > dependencies (expressed in less Depends:), which is obviously
> > (installed size, testing migration, etc.) a good thing.
>
> Agreed, it is a v.good thing. Not sure it is yet something we should
> be advising on mentors, that's all. It may well be harder than
> expected and the methods are not that user-friendly.
Why? Maintaining a package is not (just) about making lintian happy
and uploading new versions. Getting rid of extra dependencies is IME a
very good learning experience, and I wish it would be the kind of
questions asked during T&S (at least: I'd have been glad to have to
work on this kind of problem).
And it's (still IMHO) a very good occasion to learn about linker
flags, and possibly have a deeper view on how autotools, cmake, scons
(erk) deal with that.
Cheers,
--
Cyril Brulebois, still in NM, FWIW.
pgpgNdwPtc9AF.pgp
Description: PGP signature
Re: RFS: avant-window-navigator 0.2.1
On Sun, 2008-02-03 at 20:21 +0100, Cyril Brulebois wrote: > Sometimes, just deleting an -lfoo would do. But more commonly, the > build system doesn't allow you to use fine-grained library > dependencies. That's where LDFLAGS=-Wl,--as-needed is your friend, > since it tells the linker to forget about the unused libraries > (resulting in less NEEDED entries, and happy dpkg-shlibdeps). > > *BUT* that might break the resulting binaries, since (depending on > various things, like build/link options), you may end up with > undefined references, which result in runtime crashes. I can only stress that the *but* here can be a blocker. Not all packages can get away with: > To avoid that, you probably want to use another LDFLAG(S): > -Wl,-z,defs, which explicitely forbids such undefined references. > Note that this might still break the build system, but that *is* a > good thing. (Agreed, but is probably easier to fix upstream than in Debian, YMMV). The main culprit here is Gtk+ (and probably Qt for similar reasons) and I need to find an overall solution to the problem for Emdebian. The problem is identifying *which* reports from dpkg-shlibdeps actually matter in the grand scheme of things. If a package causes an extra dependency that is a problem, yes, but if that extra dependency is genuinely necessary for some other application which would almost inevitably be installed alongside the package in question, then no harm is done. I'm looking at storing the output of dpkg-shlibdeps in some form of database so that I can cross reference which dependencies might be completely unnecessary for a given selection of packages. It'll take some time and will have to fit in with my other work so if anyone fancies helping out . . . . (It'll probably give me a good reason to investigate mole too.) > That's a bit of work, but you'll probably end up with less > dependencies (expressed in less Depends:), which is obviously > (installed size, testing migration, etc.) a good thing. Agreed, it is a v.good thing. Not sure it is yet something we should be advising on mentors, that's all. It may well be harder than expected and the methods are not that user-friendly. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: This is a digitally signed message part
Re: RFS: avant-window-navigator 0.2.1
On 03/02/2008, Julien Lavergne wrote:
> That's something I wanted to do, but I didn't find a good way to do
> that. I tried to replace ${shlibs:Depends} with only necessary
> library, but dpkg-shlibdeps still get the same warnings.
Oh, no, you definitely don't want to touch that!
The idea is to get rid of extra/unneeded “-lfoo -lbar …” in the
upstream Makefile, so as to link only against the libraries that are
actually used.
Sometimes, just deleting an -lfoo would do. But more commonly, the
build system doesn't allow you to use fine-grained library
dependencies. That's where LDFLAGS=-Wl,--as-needed is your friend,
since it tells the linker to forget about the unused libraries
(resulting in less NEEDED entries, and happy dpkg-shlibdeps).
*BUT* that might break the resulting binaries, since (depending on
various things, like build/link options), you may end up with
undefined references, which result in runtime crashes.
To avoid that, you probably want to use another LDFLAG(S):
-Wl,-z,defs, which explicitely forbids such undefined references.
Note that this might still break the build system, but that *is* a
good thing. Usually, the problem is that the intermediate builds are
broken, since the resolution of undefined references is (again, in
some conditions) postponed to the final linking. By using this option,
you explicitely forbid any single undefined reference (including in
the intermediate targets), which means that you might sometimes have
to modify the Makefiles to add some -lfoo or -lbar, or e.g. add
TARGET_LINK_LIBRARIES() in cmake build systems.
That's a bit of work, but you'll probably end up with less
dependencies (expressed in less Depends:), which is obviously
(installed size, testing migration, etc.) a good thing.
Cheers,
--
Cyril Brulebois
pgptP128LiBWj.pgp
Description: PGP signature
Re: RFS: avant-window-navigator 0.2.1
On sam, 2008-02-02 at 00:10 +0100, Adam Borowski wrote:
> It spews several pages of dpkg-shlibdeps warnings during build -- what
> about
> trimming the libs somehow?
That's something I wanted to do, but I didn't find a good way to do
that.
I tried to replace ${shlibs:Depends} with only necessary library, but
dpkg-shlibdeps still get the same warnings.
I searched for a method with the new symbols system, but I found nothing
about this (like a ${symbols:Depends} things).
Any advice is welcome :)
--
Kind regards,
Julien Lavergne
jabber : [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: xf86-input-tslib (xserver-xorg-input-tslib)
On Fri, 2008-02-01 at 11:19 +0800, Wen-Yen Chuang wrote:
> Julien Cristau wrote:
Julien - do you wish to sponsor this package? I've taken over
maintenance of tslib itself recently and I'm going to be using
tslib-type stuff a lot in Emdebian. I'm happy for you to sponsor
xserver-xorg-input-tslib but if you would prefer that I do it, that's
fine too.
Thing is, I'm not part of the Debian X Strike Force and I don't really
have time to join so this is one area where embedded crosses over into
the work of existing teams. I'm happy either way.
> > * you run configure with both --host and --build unconditionally, see
> > /usr/share/doc/autotools-dev/README.Debian.gz on how to fix this
>
> Done.
>
> > * no need to run dh_makeshlibs, you don't ship a shared lib
>
> Done.
>
> > * in debian/control, please build-dep on a recent (>= 2:1.4-1) version
> > of xserver-xorg-dev, and replace the hardcoded 'Provides' and
> > dependency on xserver-xorg-core with automatically generated values
> > using /usr/share/xserver-xorg/{inputabiver,serverminver}
>
> Done.
> But it can not auto-generate "Provides: xserver-xorg-input-2" and
> "Depends: xserver-xorg-core (>= 2:1.4)".
> I looked at xserver-xorg-input-evdev and xserver-xorg-input-evtouch but
> have no clue about this. :-(
Take a look at how the other X driver packages generate their data.
e.g. xserver-xorg-input-kbd uses a similar Provides: in debian/control
and gets a usable result:
Provides: xserver-xorg-input-2
The clue is this line in debian/rules for the kbd package:
include debian/xsfbs/xsfbs.mk
and the target 'serverabi'
Package: xf86-input-tslib
Version: 0.0.4-1
Architecture: amd64
Maintainer: Wen-Yen Chuang <[EMAIL PROTECTED]>
Installed-Size: 76
Depends: libc6 (>= 2.7-1), libts-0.0-0 (>= 1.0), xserver-xorg-core (>= 2:1.4)
Provides: xserver-xorg-input-2
(there's also a clean target that you need).
--
Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
signature.asc
Description: This is a digitally signed message part
Re: RFS: workbone - QA Upload with RC bugfix
On Sunday 3 February 2008 17:04, Barry deFreese wrote: > I've made a QA upload for workbone that closes the RC bug if someone > could review/upload I would appreciate it. > > http://mentors.debian.net/debian/pool/main/w/workbone/workbone_2.40-8.dsc Thanks - I'm building this now and will upload it if all is well. Thijs pgp9YAxwADuGG.pgp Description: PGP signature
RFS: workbone - QA Upload with RC bugfix
Hi, I've made a QA upload for workbone that closes the RC bug if someone could review/upload I would appreciate it. http://mentors.debian.net/debian/pool/main/w/workbone/workbone_2.40-8.dsc Thank you! Barry deFreese -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: xdigger
Hi, I'm looking for a sponsor for the new version of my package xdigger. The new version includes a desktop file (closes #454316) and no longer includes the high score file, so the scores won't be deleted on upgrades. There are also several more minor changes (refer to GPL-2, change section in debian/menu, ...). All patches to the original source were moved to debian/patches (using quilt). http://mentors.debian.net/debian/pool/main/x/xdigger/xdigger_1.0.10-12.dsc Regards, Ansgar -- pgp: 0xF1F477C02BE4 CE2A E9CB 27D3 29F4 502E 53B1 6D9C F1F4 77C0 signature.asc Description: Digital signature
Re: RFS: lordsawar - 0.0.7 - New upstream release
Barry deFreese wrote: > Hi folks, > > New upstream release of lordsawar. Fixes several bugs if someone has a > time to review/upload. > > Kind of a fun game too if you want to "test" some. ;-) > > http://mentors.debian.net/debian/pool/main/l/lordsawar/lordsawar_0.0.7-1.dsc Good for me. On its way. Vincent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
