Rejected Upload
Hello all, I upload a package (rdesktop_1.0.0+19.6.6-1_i386.deb or thereabouts) and it is rejected 48 hours later due to having been built with dpkg-1.9.14. I've upgraded to 1.9.15. I want to rebuild and upload again... but: - do I increment the debian verion to 2? - do I tell dpkg to include the original source again? - is it likely to make woody (or, when should I have new packages uploaded by if I want them to make woody)? as the packages don't exist currently they will need to be manually added. - how long is it likely to take for the first upload to appear in unstable? I remember reading 1 month - is this accurate? - samj -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Rejected Upload
msg.pgp
Re: Autoconfig 2.13 failing to detect tcl/tk
On Sat, Jun 30, 2001 at 09:13:31PM -0700, Brett Cundal wrote:
Hiya,
I'm trying to put together a package that uses tk, but the config script
that comes with the upstream package doesn't detect tcl or tk properly...
The tests are just completely wrong... I guess the Debian packages for
tcl/tk put things in non-standard locations?
Anyhow, I imagine there are lots of packages that rely on tcl/tk in Debian,
so is there a common or correct fix for this?
Some details for those interested:
./configure looks for the files /usr/lib/tclConfig.sh and
/usr/lib/tclConfig.sh, but on Debian they are in
/usr/lib/tclversion/tclConfig.sh and /usr/lib/tkversion/tkConfig.sh.
I got around this problem by specifying --with-tcl=/usr/lib/tcl8.3 and
--with-tk=/usr/lib/tk8.3, so it found the configuration scripts, but it
doesn't do any good because ./configure looks in /usr/include for the tcl.h
and tk.h files rather than /usr/include/tcl8.3 and /usr/include/tk8.3...
There's no handy ./configure option to specify these paths, so I think I'm
left with the option of patching the script to use these paths (which I
don't think is a good solution) or getting a more recent version of the
configure script that handles tcl correctly on Debian...
Any recommendations?
2 suggestions:
1. Usually the configure will allow for --with-tclinclude
--with-tkinclude. Point them at /usr/include/{tcl,tk}8.x and it should
work fine.
2. If the above is not possible almost all configure scripts allow for
--with-extra-includes. Here you could add /usr/include/{tcl,tk}8.x as
well.
You might want to look at your {tcl,tk}Config.sh scripts. They both
should have a {TCL,TK}_SRC_DIR that points to the relevant
/usr/include/tcl8.x/{tcl,tk}-private. This all assumes you have the dev
packages installed.
--
Gordon Sadler
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
emacsen-install called twice
Hi there! In my current packaging project, I have created two packages from the upstream source, one base package and one for contrib. Both come with some emacs lisp files, which I would like to compile into bytecode. As I do not want to create an additional directory below site-lisp, both packages should put their elisp files into one directory. The contrib package just adds one file to the ones already being there. What is the standard policy to handle this? When I do as I thought would be right, when the contrib package is to be configured, emacsen-install is called automatically for the base package again, which recompiles everything. I find this pretty annoying (especially because of the warning messages that I get that the *.el files are newer than the *.elc files). Thanks in advance, Marco -- Marco Kuhlmann [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debconf and daemons
Michael Moerz [EMAIL PROTECTED] wrote: doing a echo key value /etc/myfile is a rather evil approach (for reasons search the mailing list and/or debconf docu) better would be something like: cat /etc/myfile | sed -e 's/key.*/key value/' /etc/myfile2 mv /etc/myfile2 /etc/myfile ( you could do that over /tmp too, to avoid cluttering /etc with files, but I leave that over for your imagination ... ) Be aware that using temporary files in world-writable directories (like /tmp) can be a security hazard on multi-user machines (and in some other situations also). -- Sam Couter | Internet Engineer | http://www.topic.com.au/ [EMAIL PROTECTED]| tSA Consulting | OpenPGP key ID: DE89C75C, available on key servers OpenPGP fingerprint: A46B 9BB5 3148 7BEA 1F05 5BD5 8530 03AE DE89 C75C PGP signature
Autoconfig 2.13 failing to detect tcl/tk
Hiya, I'm trying to put together a package that uses tk, but the config script that comes with the upstream package doesn't detect tcl or tk properly... The tests are just completely wrong... I guess the Debian packages for tcl/tk put things in non-standard locations? Anyhow, I imagine there are lots of packages that rely on tcl/tk in Debian, so is there a common or correct fix for this? Some details for those interested: ./configure looks for the files /usr/lib/tclConfig.sh and /usr/lib/tclConfig.sh, but on Debian they are in /usr/lib/tclversion/tclConfig.sh and /usr/lib/tkversion/tkConfig.sh. I got around this problem by specifying --with-tcl=/usr/lib/tcl8.3 and --with-tk=/usr/lib/tk8.3, so it found the configuration scripts, but it doesn't do any good because ./configure looks in /usr/include for the tcl.h and tk.h files rather than /usr/include/tcl8.3 and /usr/include/tk8.3... There's no handy ./configure option to specify these paths, so I think I'm left with the option of patching the script to use these paths (which I don't think is a good solution) or getting a more recent version of the configure script that handles tcl correctly on Debian... Any recommendations? -- Brett
Host system type detected by autoconf
Hi, How do I get my packages to build for the host type 'i386-pc-linux-gnu' rather than 'i686-pc-linux-gnu' ? Is it possible to do this via some environment variable ? viral -- I'll see you on the Dark Side of the Moon.
Re: Host system type detected by autoconf
On Sun, Jul 01, 2001 at 10:12:34AM +0530, Viral wrote: How do I get my packages to build for the host type 'i386-pc-linux-gnu' rather than 'i686-pc-linux-gnu' ? Use the --host switch to configure. -- - mdz
Re: Host system type detected by autoconf
On Sun, Jul 01, 2001 at 10:12:34AM +0530, Viral wrote: How do I get my packages to build for the host type 'i386-pc-linux-gnu' rather than 'i686-pc-linux-gnu' ? Use the --host switch to configure. Uh, how would you do that? I mean, what would you add to your debian/rules file to specify that if the detected architecture is i686-pc-linux-gnu it should compile for i386-pc-linux-gnu, without screwing up compilation of the same source on sparc/arm/alpha/etc. Eric
Re: Host system type detected by autoconf
On Sun, Jul 01, 2001 at 01:29:09AM -0400, [EMAIL PROTECTED] wrote: On Sun, Jul 01, 2001 at 10:12:34AM +0530, Viral wrote: How do I get my packages to build for the host type 'i386-pc-linux-gnu' rather than 'i686-pc-linux-gnu' ? Use the --host switch to configure. Uh, how would you do that? Uh, configure --host=$(shell dpkg-architecture -qDEB_HOST_GNU_TYPE). I mean, what would you add to your debian/rules file to specify that if the detected architecture is i686-pc-linux-gnu it should compile for i386-pc-linux-gnu, without screwing up compilation of the same source on sparc/arm/alpha/etc. dpkg-architecture will always give the Debian architecture, which is what should be used for building packages. In the case of ia32, that will be i386. -- - mdz
Re: GPG Key Signing
Manoj Srivastava [EMAIL PROTECTED] writes: Are you implying that ensuring the person whose identity you verified actually controls the email address and the secret pass phrase adds no value to the web of trust? Not to me (but obviously to you, so overall the web's value is increased, can't argue with that). I basically trust the person to not lie. An evil person could induce me to: * send her messages that she could not decrypt (she lied to me about owning the key). * send messages to a mail adress that - bounces, - is never read, - belongs to another person, who can't decrypt it. In all these scenarios, the maximum loss for me is the work I put into that mail (although I often keep copies, so it may not be entirely lost), and the gain to the attacker is zero. Robbe [...] I'm not that interested in whether the e-mail is Robbe signed by anybody besides the owner of the key. So a compromiser can just merrily add email addresses that never point to the owner, and the owner shall never know. Re-read what I said: while I don't care about others signing additional ids, I consider ids not signed by the key highly dubious. Your compromiser can't add self-signed ids to a public key unless he holds the corresponding private key. -- Robbe signature.ng Description: PGP signature
Re: Packaging xmlrpc-c
On Sun, Jul 01, 2001 at 01:12:57PM +0200, Robert Bihlmeyer wrote: Eric Kidd [EMAIL PROTECTED] writes: Expat 1.x was never packaged as a shared library by its upstream maintainer. [...] Basically, expat 1.x was designed to be used exactly as I'm using it--as an internal library. Ah, I was ignorant of this. This makes your decision much more understandable to me. Well, I'm not trying to be delibrately preverse just for the *fun* of it. ;-) A future decision to upgrade to expat 2.0 would need to involve a thorough audit of the new code base, since it's maintained by a new author, cvs diff -rjclark-orig should do the trick. Actually, from skimming sourceforge's webcvs, the differences seem pretty small. This is *really* good news, and greatly increases the chances of xmlrpc-c upgrading shortly after a new stable version is released. and used less extensively throughout industry. If Debian packages are any guide, those dependant on libxmltok1 are in the same number as those dependant on libexpat1. Of course this naive check misses those statically linking the older version. This seems to be pretty typical for free software. But if you count all the non-free software out there, it appears that a lot more people have studied expat 1.x. If (A) were at all feasible, I'd prefer it, too. But James Clark never packaged expat 1.x as a shared library, so the downstream inconsistencies in various distros are a bit overwhelming from my perspective. Ok. So (C) it is. xmlrpc-c will keep the internal version of expat 1.x it uses on other distros, at least until 2.x is stable and audited. But for Debian's sake, I'll hide all external symbols from this private version of expat in a future upstream release, so Debian packages will be able to depend on Debian's expat *and* xmlrpc-c. Deal? :-) Thank you very much for help on this issue! Cheers, Eric
Rejected Upload
Hello all, I upload a package (rdesktop_1.0.0+19.6.6-1_i386.deb or thereabouts) and it is rejected 48 hours later due to having been built with dpkg-1.9.14. I've upgraded to 1.9.15. I want to rebuild and upload again... but: - do I increment the debian verion to 2? - do I tell dpkg to include the original source again? - is it likely to make woody (or, when should I have new packages uploaded by if I want them to make woody)? as the packages don't exist currently they will need to be manually added. - how long is it likely to take for the first upload to appear in unstable? I remember reading 1 month - is this accurate? - samj
Re: Rejected Upload
msg.pgp Description: PGP message
Re: GPG Key Signing (Was: Advocate/Sponsor)
On Thu, Jun 28, 2001 at 10:27:54AM -0700, John H. Robinson, IV wrote: On Thu, Jun 28, 2001 at 12:13:37PM -0500, Steve Langasek wrote: we should also require them to demonstrate a clear understanding of PKI as part of the NM process. manoj came up with a pretty good protocol to sign a key. i have it available in HTML at http://people.debian.org/~jaqque/keysign.html it does have some weaknesses, but it is a lot stronger than the ``oh, i've met you, i have checked your ID, and off we go'' comments welcome. Nice to see you called it 'Manoj's Singing-Protocol' ;) -john -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Eric VAN BUGGENHAUT [EMAIL PROTECTED]
Re: Autoconfig 2.13 failing to detect tcl/tk
On Sat, Jun 30, 2001 at 09:13:31PM -0700, Brett Cundal wrote:
Hiya,
I'm trying to put together a package that uses tk, but the config script
that comes with the upstream package doesn't detect tcl or tk properly...
The tests are just completely wrong... I guess the Debian packages for
tcl/tk put things in non-standard locations?
Anyhow, I imagine there are lots of packages that rely on tcl/tk in Debian,
so is there a common or correct fix for this?
Some details for those interested:
./configure looks for the files /usr/lib/tclConfig.sh and
/usr/lib/tclConfig.sh, but on Debian they are in
/usr/lib/tclversion/tclConfig.sh and /usr/lib/tkversion/tkConfig.sh.
I got around this problem by specifying --with-tcl=/usr/lib/tcl8.3 and
--with-tk=/usr/lib/tk8.3, so it found the configuration scripts, but it
doesn't do any good because ./configure looks in /usr/include for the tcl.h
and tk.h files rather than /usr/include/tcl8.3 and /usr/include/tk8.3...
There's no handy ./configure option to specify these paths, so I think I'm
left with the option of patching the script to use these paths (which I
don't think is a good solution) or getting a more recent version of the
configure script that handles tcl correctly on Debian...
Any recommendations?
2 suggestions:
1. Usually the configure will allow for --with-tclinclude
--with-tkinclude. Point them at /usr/include/{tcl,tk}8.x and it should
work fine.
2. If the above is not possible almost all configure scripts allow for
--with-extra-includes. Here you could add /usr/include/{tcl,tk}8.x as
well.
You might want to look at your {tcl,tk}Config.sh scripts. They both
should have a {TCL,TK}_SRC_DIR that points to the relevant
/usr/include/tcl8.x/{tcl,tk}-private. This all assumes you have the dev
packages installed.
--
Gordon Sadler
Need an advocate/sponsor
Hi! I'm searching for a Sponsor/Advocate I have packaged: The Flink mailchecker is a small panelapplet for the GNOME panel. It features support for multiple accounts, so that you will not need to have several applets for checking different accounts, Flink is capable to have (almost) an infinite amount of accounts configured. Flink supports POP3, IMAPv4 and mbox right now. Flink homepage: http://flink.leyman.nu/ My debian packages: deb http://www.mikan.net/~mikan/debian/ ./ deb-src http://www.mikan.net/~mikan/debian/ ./ Flink was mostly a learning project, how to create a package etc. But I will continue to support it and help the upstream to include sasl support in it's IMAP mode. I have begun work on a new version of arla (orphaned by [EMAIL PROTECTED]) but I'm not done yet. I have gotten it to build, but I need to figure out how it should create an source package for building kernel modules. I haven't filled an ITP yet, because I want to get an advocate/sponsor first, so I feel that I'm on the right track. CU Mikael Andersson [EMAIL PROTECTED] PS Sorry for my bad(?) english, it's not my primary language, and it's late in sweden :-) DS
Re: debconf and daemons
Michael Moerz [EMAIL PROTECTED] wrote: doing a echo key value /etc/myfile is a rather evil approach (for reasons search the mailing list and/or debconf docu) better would be something like: cat /etc/myfile | sed -e 's/key.*/key value/' /etc/myfile2 mv /etc/myfile2 /etc/myfile ( you could do that over /tmp too, to avoid cluttering /etc with files, but I leave that over for your imagination ... ) Be aware that using temporary files in world-writable directories (like /tmp) can be a security hazard on multi-user machines (and in some other situations also). -- Sam Couter | Internet Engineer | http://www.topic.com.au/ [EMAIL PROTECTED]| tSA Consulting | OpenPGP key ID: DE89C75C, available on key servers OpenPGP fingerprint: A46B 9BB5 3148 7BEA 1F05 5BD5 8530 03AE DE89 C75C pgpBvhbjn2znX.pgp Description: PGP signature
Re: Host system type detected by autoconf
On Sun, Jul 01, 2001 at 12:54:13AM -0400, Matt Zimmerman wrote: On Sun, Jul 01, 2001 at 10:12:34AM +0530, Viral wrote: How do I get my packages to build for the host type 'i386-pc-linux-gnu' rather than 'i686-pc-linux-gnu' ? Use the --host switch to configure. But wouldn't that break when building on other architectures ? viral -- For long you live and high you fly, but only if you ride the tide, And balanced on the biggest wave, you race towards an early grave. pgpI4VNWHk5aE.pgp Description: PGP signature
