Re: Request for mentor
No offence taken ;) What I meant is that the mailing list is a great place to start for the beginner. Those who don't know - but want to learn. From my experience - a lot of DDs dont want to mother you through learning how to package. Ok, they'll help, but they dont want to teach from scratch :D I agree - once at a certain stage, a personal mentor is a great idea... though it usually eveolves naturally that you find one :D Regards, Martin Meredith [EMAIL PROTECTED] wrote: Hello Ale. No disrespect to Martin, but a specific Debian mentor would benefit you. Giacomo Catenazzi is my Debian mentor, with contributions from Martin Pitt and Enrico Zini. A list is not a mentor. You need a mentor. The list does not assign mentors. It is up to you to find one. The experience of a volunteer project like Debian is that for DDs to seek random volunteers leads to bad results. The initiative must come from you. There are many hidden opportunities. For example, there is an opportunity right now with my own package Debram for a person with the right interest, attitude, patience and skill to contribute. But you have to search the opportunities out, to show the DD in question over a period of time that it is worth his time to mentor you. This is not because we don't like volunteers---we love volunteers---but because past experience is that something like 95 percent of enthusiastic new volunteers soon flame out and disappear. That is wreckage we can't handle. If you think that you are one of the 5 percent, then be patient, study some package interesting to you where the Maintainer seems to want help, prepare a small patch or two, and gradually see if you cannot work your way into the Project. If you do not know which package to look at first---well, I just suggested one, didn't I? Start there. Debian development is a lot of fun. If you choose to stay the course, we'll be glad to have you aboard. Good luck. Andreas Schuldei's 2005 DPL platform [1] is useful further reading in the matter. signature.asc Description: OpenPGP digital signature
Re: dpatch vs. quilt
Kevin B. McCarty [EMAIL PROTECTED] wrote: Frank Küster wrote: The main advantage of quilt IMHO is that it doesn't duplicate the whole tree when editing and updating the patch, which can be time- and disk-consuming in large projects. Instead it keeps a list of files for the patch one is editing and only keeps copies of these. Out of curiosity, does quilt have a mechanism similar to dpatch that allows you to treat shell scripts as patches? My inability to find such a feature was the main reason I opted for dpatch over quilt in the Cernlib package -- I needed to move a bunch of files around within the source, and doing so with a pure patch system will result in huge and fragile diff files (two copies of each file to be moved, which breaks if upstream changes any of them!). But now it sounds like I'm missing out on some features by not using quilt. I don't think that quilt offers this, at least not in a straightforward way. Why can't you separate the moving around of files from the patching? patch-stamp: quilt push -a debian/movefilearound But looking at its implementation, maybe this could easily be changed, just add an additional check whether the patch has a shebang line at the start, and execute it instead of calling patch. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re-libtooling + automake
Whenever I seem to relibtool a package now I always seem to get problems with the timestamps being wrong, and the package tries to re-run automake. Anyway, as a solution for that - we decided that the command lsdiff --strip 1 debian/patches/10_update_libtool.diff | xargs touch -r configure.in.in would work. However I've just stumbled across a package where this doesnt work. Does anyone know enough about automake (I dont) to stop it trying to run on a package build ? I'm getting errors like WARNING: `automake-1.9' is missing on your system. You should only need it if you modified `Makefile.am', `acinclude.m4' or `configure.in'. You might want to install the `Automake' and `Perl' packages. Grab them from any GNU archive site. and I dont think a touch * in the rules is an elegant way to do it :D signature.asc Description: OpenPGP digital signature
Re: Re-libtooling + automake
Hi Mez! :-)
On 1/30/06, Martin Meredith [EMAIL PROTECTED] wrote:
Does anyone know enough about automake (I dont) to stop it trying to
run on a package build ?
I add AM_MAINTAINER_MODE somewhere at the top of configure.{ac,in} to
enable maintainer mode (which I believe prevents the checking of
timestamps) then rebuild the entire build system, usually by running
`autoreconf' with the appropriate environment variables (ACLOCAL,
AUTOMAKE, AUTOCONF, etc) set, if there's not a `bootstrap'/`autogen.sh'
script in the top_srcdir at hand.
HTH,
Zakame
--
Zak B. Elep || http://zakame.spunge.org
[EMAIL PROTECTED] || [EMAIL PROTECTED]
1486 7957 454D E529 E4F1 F75E 5787 B1FD FA53 851D
Re: Re-libtooling + automake
I do know of this - but looking for a solution for now so I dont have to go
down that road unless absolutely neccesary :d (for example - the lsdiff |
touch -r)
Zak B. Elep wrote:
Hi Mez! :-)
On 1/30/06, Martin Meredith [EMAIL PROTECTED] wrote:
Does anyone know enough about automake (I dont) to stop it trying to
run on a package build ?
I add AM_MAINTAINER_MODE somewhere at the top of configure.{ac,in} to
enable maintainer mode (which I believe prevents the checking of
timestamps) then rebuild the entire build system, usually by running
`autoreconf' with the appropriate environment variables (ACLOCAL,
AUTOMAKE, AUTOCONF, etc) set, if there's not a `bootstrap'/`autogen.sh'
script in the top_srcdir at hand.
HTH,
Zakame
--
Zak B. Elep || http://zakame.spunge.org
[EMAIL PROTECTED] || [EMAIL PROTECTED]
1486 7957 454D E529 E4F1 F75E 5787 B1FD FA53 851D
signature.asc
Description: OpenPGP digital signature
Re: dpatch vs. quilt
Frank Küster wrote: Kevin B. McCarty [EMAIL PROTECTED] wrote: Out of curiosity, does quilt have a mechanism similar to dpatch that allows you to treat shell scripts as patches? My inability to find such a feature was the main reason I opted for dpatch over quilt in the Cernlib package -- I needed to move a bunch of files around within the source, and doing so with a pure patch system will result in huge and fragile diff files (two copies of each file to be moved, which breaks if upstream changes any of them!). But now it sounds like I'm missing out on some features by not using quilt. I don't think that quilt offers this, at least not in a straightforward way. Why can't you separate the moving around of files from the patching? patch-stamp: quilt push -a debian/movefilearound I guess in principle I could, but it's nice to have the step where the file move takes place be right next to the step where I edit the Imakefiles (sadly, Cernlib uses imake) to suit. E.g., this file is a script to move some files around: debian/patches/702-fix-packlib-mathlib-circular-mess.sh.dpatch and this patch fixes the Imakefiles appropriately: debian/patches/702-patch-Imakefiles-for-packlib-mathlib.dpatch But looking at its implementation, maybe this could easily be changed, just add an additional check whether the patch has a shebang line at the start, and execute it instead of calling patch. Hmm, I will look into this when I have time and maybe file a wishlist bug on quilt with a patch. Thanks, -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: pkg-config needs a replacement?
On Monday 30 January 2006 4:20 am, skaller wrote:
* there is no provision for other than the limited set
of resources (--cflags, --libs) that it supports
You can make any variable in the .pc file available - anything you can put
into the .pc using (e.g.) .pc.in can be made available to those processes
that read the .pc file. I use it to locate XML schema and other files.
I use:
[EMAIL PROTECTED]@
[EMAIL PROTECTED]@
[EMAIL PROTECTED]@
Libs: -L${libdir} -lqof ${added_libs}
then people can bring those in using:
QOF_LIB_DIR=`$PKG_CONFIG --silence-errors --variable=libdir qof-1`
QOF_XML_DIR=`$PKG_CONFIG --silence-errors --variable=xmldir qof-1`
http://qof.sourceforge.net/hacking.html#automake
User code often requires other resources such as:
** environment variables
** media files
** working services
** authority
All supported as --variable=.
** I'm sure the list is as long as you like :)
** Remember not all 'code' is written C :))
If you can use sed or equivalent, you can make these available to .pc.
For Debian many libraries live in /usr/lib, but not all:
some installed libraries live in strange places anyhow,
and some libraries -- such as the ones my own tool
generates -- aren't installed, and even if they were they
would not be installed by Debian package manager
-- unless the component was so useful someone decided
to package it. Thus, Debian Standards help (a LOT!!)
but aren't enough (SDL doesn't come with pkg-config
meta data).
That's why I support the --variable syntax. Works fine.
--
Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
pgpGB6tdjFFau.pgp
Description: PGP signature
Re: RFS: proxycheck -- link
отправлено в группы и по почте Christoph Haas wrote: Found it. Checked it. Uploaded it. Thank you. Minor thoughts on the package: - Please don't change past entries in the changelog even though I understand that you wanted to correct the line wrapping. Yes, i understand such the necessity. - Consider using dpatch for changing the upstream sources. You may find it easier to keep or remove patches when the next upstream version is released. Thanks, probably i should realize the dpatch's advantage. Is there any article about it? - I assume you have sent your patches upstream already. I did. -- Regards, Al Nikolov JID [EMAIL PROTECTED]IRC clown UIN 312108671 PGP 4B50 F1E3 080C 21A2 91F4 8BF0 CD60 3B5A 2ECF 984B -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
debug packages?
Hi all, I'm packaging a C++ app that has packages like this: foo - binary using the library libfoo0 - the library itself libfoo0-dev - headers and so on libfoo0-doc - docs for the library I'd like to add a package for debug information, since the app crashes occasionally. Should I add a libfoo0-dbg or foo-dbg package containing debug info for the lib and the app? or should I create separate libfoo0-dbg and foo-dbg packages? I'm inclined to think that creating just libfoo0-dbg with debug info for both the binary and is the right way to go, since there is also a gui in another package, which uses the library, therefore more people will just have the library than normal. Secondly, is dh_strip -k the right way to do this? -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: debug packages?
also sprach Paul Wise [EMAIL PROTECTED] [2006.01.30.1518 +0100]: Secondly, is dh_strip -k the right way to do this? Yes. It mostly automates the process too. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver! http://www.transnationalrepublic.org/ signature.asc Description: Digital signature (GPG/PGP)
Re: Re-libtooling + automake
Hi Martin, Martin Meredith wrote: [on AM_MAINTAINER_MODE] I do know of this - but looking for a solution for now so I dont have to go down that road unless absolutely neccesary :d (for example - the lsdiff | touch -r) Well, probably the best solution is to get upstream to put in the AM_MAINTAINER_MODE... Seriously, AM_MAINTAINER_MODE and touch are the two solutions documented in autotools-dev README.Debian. It's probably best to stick to those (or file a bug with patch to update the README.Debian), if only for the sake of clarity should someone else need to look at / touch your packages.[1] The autotools stuff is subtle enough as it is. Kind regards T. 1. This is similar in spirit to the discussion of patching systems and packaging aids that took place on planet Debian some time ago. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpatch vs. quilt
Adeodato Simó wrote: * Kevin B. McCarty [Sun, 29 Jan 2006 11:39:17 -0500]: Out of curiosity, does quilt have a mechanism similar to dpatch that allows you to treat shell scripts as patches? My inability to find such a feature was the main reason I opted for dpatch over quilt in the Cernlib package -- I needed to move a bunch of files around within the source, and doing so with a pure patch system will result in huge and fragile diff files (two copies of each file to be moved, which breaks if upstream changes any of them!). No, in quilt patches are patches, not scripts. :) Why don't you move files around in debian/rules, anyway? I partly answered this elsewhere in the thread (it's nice to logically keep together the file-moving operation with the patching of the Imakefiles to reflect the different file locations, in two files in debian/patches starting with the same number). The other reason is that I'm trying to keep my (fairly substantial) patches to Cernlib [1] accessible to non-Debian distributions. For instance Patrice Dumas is using my set of patches in creating Cernlib RPMs for Fedora Extras. Moving the files around in debian/rules but patching the Imakefiles in separate patches under debian/patches would make his life a lot harder :-P [1] This includes things like creating shared libraries as well as static ones, removing circular library dependencies, fixing things to work on AMD64, etc Unfortunately upstream is almost dead and I don't think they are likely to accept such changes. best regards, -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Lintian Warnings and Modifying Upstream Source
Am 2006-01-21 13:44:28, schrieb Russ Allbery: The error message isn't about its presence in the source package but rather its presence in the generated binary package. In general, in Debian, you should never install additional copies of the GPL, the LGPL, or other common licenses; instead, just refer the user to the copy that already ships with Debian in /usr/share/common-licenses. If I find Packages which include the Licence, I should file a bugreport against the package? If YES, I will file immediatly arround 30 of them. After looking into /usr/share/doc/$PACKAGE/ I have several times found the GPL in form of READMEE.gz. I have tried this on my own pbuilder, but it is not possibel becasue linda complains about it. It seems, that some Maintainer do not test there Packages. Greetings Michelle Konzack Systemadministrator Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Custom Debian CD.
Hello Derek, You should post this question on debian-cd where are realy competent peoples creating CCD. Greetings Michelle Konzack Systemadministrator Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Lintian Warnings and Modifying Upstream Source
On Thu, Jan 26, 2006 at 07:46:58AM +0100, Michelle Konzack wrote: Am 2006-01-21 13:44:28, schrieb Russ Allbery: The error message isn't about its presence in the source package but rather its presence in the generated binary package. In general, in Debian, you should never install additional copies of the GPL, the LGPL, or other common licenses; instead, just refer the user to the copy that already ships with Debian in /usr/share/common-licenses. If I find Packages which include the Licence, I should file a bugreport against the package? If YES, I will file immediatly arround 30 of them. Thats not the right way of doing it :/ This is mass bug filing and riles people sometimes :) Lintian is the source of being able to find the problems, and lintian is already run automatically; check the p.q.debian.org site and also http://lintian.debian.org/reports/tags.html and, in particular, extra-license-file (163 packages, 308 tags): http://lintian.debian.org/reports/Textra-license-file.html. So it is a waste of time and bugs to file them, since interested maintainers can get this information anyway, even if they don't run lintian themselves. There's a wishlist bug, I believe, about showing the count of lintian [I] and [W] outputs directly on the QA page; oh here it is http://bugs.debian.org/243729. -- Clear skies, Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: timeout function in cryptsetup init script
On 30/01/2006 Jan C. Nordholz wrote: Hi, indeed, it sounds exactly like what i'm searching for. but unfortunately it looks like cryptsetup does not have support for reading the password from stdin or command-line. ah, I see, it is using getpass(3) if no keyfile has been specified. Hmm, after having a glance at the source code, the easiest thing seems to patch the source to accept a new command-line option to specify a different input fd. The rest of the code (lib/setup.c:get_key(), most importantly) should work without a change. maybe then the best would be to add support for a --timeout option, instead of supporting another (insecure) input fd. Shall I try to wrap something up? if you like, that would be great. i've not much experiences with coding c(++). ... jonas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: files for an initscript that is run before mountall.sh
On 29/01/2006 Henrique de Moraes Holschuh wrote:
On Mon, 30 Jan 2006, Jonas Meurer wrote:
now my question is, where should i place the check scripts instead?
is /lib/cryptsetup/{pre,post}check correct?
Yes.
thanks.
...
jonas
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: create docs in binary indep
On Sun, Jan 29, 2006 at 09:12:26PM -0800, Jon Saints wrote: I am new to packaging and just received this feedback on a package I helped to create: I just noticed that gdal packaging needs one more revision because it create a -doc package in the binary-arch section. libgdal-doc is [correctly] and Architecture: all package. There are 2 [related] policy violations, in that the binary-indep target doesn't exist [0], and that the Arch: all package is built in the binary-arch target. [0] http://www.us.debian.org/doc/debian-policy/ch-source.html#s-debianrules By the way, why doese debian/libgdal-doc.files exist? Shouldn't it be cleaned, by the clean target, and never exist in the source package? FYI you will want to look at how other, template debhelper rules files do this, wrt exporting DH_OPTIONS: /usr/share/debhelper/dh_make/debianm/rules Should I simply move dh_installdocs to a new binary-indep section in order to solve the policy violation? Something like that. You want to ensure, of course, that whatever mechanism you use, complies with the documented policy, and also - doesn't include the documentation in the main package (otherwise you should not have a separate -doc package); and - includes the documentation in the -doc package (otherwise it will be empty and useless). You can test what gets built where by calling something like fakeroot ./debian/rules binary-arch And ensuring that only the arch-dep packages are built into ../*.deb, and then fakeroot ./debian/rules binary-indep And ensuring that only the arch-indep packages are built into ../*.deb, And then you can test the contents of the packages with dpkg-deb -c. -- Clear skies, Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debug packages?
* Paul Wise [Mon, 30 Jan 2006 22:18:07 +0800]:
Hi all,
I'm packaging a C++ app that has packages like this:
foo - binary using the library
libfoo0 - the library itself
libfoo0-dev - headers and so on
libfoo0-doc - docs for the library
I'd like to add a package for debug information, since the app crashes
occasionally. Should I add a libfoo0-dbg or foo-dbg package containing
debug info for the lib and the app? or should I create separate
libfoo0-dbg and foo-dbg packages? I'm inclined to think that creating
just libfoo0-dbg with debug info for both the binary and is the right
way to go, since there is also a gui in another package, which uses the
library, therefore more people will just have the library than normal.
As long as it's only one -dbg package, I'd say that both names are ok.
Though now that, thanks to debhelper v5, it's easy to create -dbg
packages with symbols from multiple binary packages, I'd favour
${source}-dbg for those. Remember to make it Prio: extra, Section:
libdevel.
Secondly, is dh_strip -k the right way to do this?
By my reading of the manpage, this will keep debug symbols, and ship
them in the _same_ package. I think what you want is:
% echo 5 debian/compat
% dh_strip --dbg-package=foo-dbg
HTH,
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
I try to keep an open mind, but not so open that my brains fall out.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re-libtooling + automake
* Martin Meredith [Mon, 30 Jan 2006 12:04:45 +]: lsdiff --strip 1 debian/patches/10_update_libtool.diff | xargs touch -r configure.in.in However I've just stumbled across a package where this doesnt work. Then, if you insist on using touch-fu (I myself prefer it), you should investigate what the right order of the arguments to touch is. For this, running `make -d` and seeing why things are getting regenerated helps. Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org If there is a sin against life, it consists perhaps not so much in despairing of life as in hoping for another life and in eluding the implacable grandeur of this life. -- Albert Camus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: ksplash-engine-moodin -- fading splash screen engine for KDE
Le Vendredi 30 Septembre 2005 12:14, Fathi Boudra a écrit : * Package name: ksplash-engine-moodin Version : 0.4.2 Upstream Author : Christian Leh [EMAIL PROTECTED] * URL : http://moodwrod.com/files/ * License : GPL Description : fading splash screen engine for KDE Heavily customizable ksplash engine for various types of themes. This KDE splash screen engine is based upon Linspire's engine by Sean Meiners [EMAIL PROTECTED] At the moment, the source file provided by the upstream contains svn directory. So i've got the source-contains-svn-control-dir .svn warning from lintian. My package can be found on mentors.debian.net. hi all, always looking/waiting for a sponsor :) the package is lintian free now. cheers, Fathi
Re: timeout function in cryptsetup init script
ah, I see, it is using getpass(3) if no keyfile has been specified. Hmm, after having a glance at the source code, the easiest thing seems to patch the source to accept a new command-line option to specify a different input fd. The rest of the code (lib/setup.c:get_key(), most importantly) should work without a change. maybe then the best would be to add support for a --timeout option, instead of supporting another (insecure) input fd. The advantage of the fd patch is that it would be rather minimal - the support in setup.c:get_key() is already there (dealing with an arbitrary fd, and calling getpass() only if isatty() succeeds), I would only add a few lines to the main() method. But I agree with you that cryptsetup should support some sort of timeout mechanism internally. Supporting arbitrary fds for input would just make inclusion of cryptsetup a lot easier, and getpass() isn't any safer than a read() on a given fd. Shall I try to wrap something up? if you like, that would be great. i've not much experiences with coding c(++). No problem. I'll do both (fd / timeout), so you can have a look at them and decide. Btw, have you talked to upstream about this? What is his opinion? Regards, Jan -- Jan C. Nordholz jckn At gmx net signature.asc Description: Digital signature
Re: subscribe
I'm so sorry for that mail :/ I forgot to add -request... -- Jérémie signature.asc Description: OpenPGP digital signature
seeking for sponsorship
Respected sir/madam I sonam chophel from bhutan would like to seek sponsorship for continuing my further studies. My problem is that I am not in a position to furhter continue my studies owing to limited source of income of my father, who happens to be a poor farmer with a big family to suppport. My work in the class has always been good throughout and was declared successful to be promoted. I have done my pre schooling from a high in Bhutan i.e till class 12.Recently i discoverd this opurtuniuity for seeking on the net, therefore through deep research i was able to list your email address. i look forward for your acknowledgemewnt of my request and hope you consider. Thanking you and assuring you of my best
