RFS: ldtp
Dear mentors,
I am looking for a sponsor for the new version 0.9.2-3
of my package ldtp.
It builds these binary packages:
ldtp - GNU/Linux Desktop Testing Project (GNU/LDTP)
GNU/LDTP is aimed at producing high quality test automation framework and
cutting-edge tools that can be used to test GNU/Linux Desktop and improve it.
It uses the Accessibility libraries to poke through the application's user
interface. The framework has tools to generate AppMap by reading through the
user interface components of an application. The framework also has tools to
record test-cases based on user-selection on the application.
.
GNU/LDTP core framework uses AppMap and the recorded test-cases to test an
application and gives the status of each test-case as output.
python-ldtp - Python bindings for GNU/Linux Desktop Testing Project
This package provides Python bindings for LDTP.
The package appears to be lintian clean.
The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/l/ldtp
- Source repository: deb-src http://mentors.debian.net/debian unstable
main contrib non-free
- dget http://mentors.debian.net/debian/pool/main/l/ldtp/ldtp_0.9.2-3.dsc
I would be glad if someone uploaded this package for me.
--
Cheers,
Kartik Mistry | 0xD1028C8D | IRC: kart_
Blogs: {ftbfs,kartikm}.wordpress.com
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: ldtp-doc
Dear mentors,
I am looking for a sponsor for the new version 0.8-2 of my package ldtp-doc.
It builds these binary packages:
ldtp-doc - Documentation for LDTP packages
Description: Documentation for LDTP packages
Linux Desktop Testing Project (LDTP) is aimed at producing high quality test
automation framework and cutting-edge tools that can be used to test Linux
Desktop and improve it. It uses the Accessibility libraries to poke through the
application's user interface. The framework also has tools to record test-cases
based on user-selection on the application.
.
This package contains documentation for LDTP packages.
The package appears to be lintian clean.
The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/l/ldtp-doc
- Source repository: deb-src http://mentors.debian.net/debian unstable
main contrib non-free
- dget http://mentors.debian.net/debian/pool/main/l/ldtp-doc/ldtp-doc_0.8-2.dsc
I would be glad if someone uploaded this package for me.
--
Cheers,
Kartik Mistry | 0xD1028C8D | IRC: kart_
Blogs: {ftbfs,kartikm}.wordpress.com
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: failmalloc
On Thu, 14 Feb 2008 14:49:25 + Jon Dowland [EMAIL PROTECTED] wrote: the unpacked source is back to pristine upstream after the make clean target, which is particularly nice if you have your tree in a VCS and don't want to keep filtering the sub/guess changes out of commits. That is, if you branch, make a change, do a build, see it worked, do a clean, then want to commit your change, you don't have config/sub diffs in your commit (or have to fix them by hand for each feature add). Also, if state 0 - build - state 1 - clean - state 2 and state 0 != 2, there's the potential for not the same two builds in a row, which afaik is a QA goal for lenny. Umm, we should commit changes in debian/ directory only, not upstream source, so you can ignore this problem. And dpkg-source ignores diffs in config.* at build. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ITR: xf86-input-tslib (updated package)
On Fri, 2008-02-15 at 17:53 +, Neil Williams wrote: On Sat, 2008-02-16 at 01:27 +0800, Wen-Yen Chuang wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear mentors, I am looking for a sponsor for the new version 0.0.4-4 of my package xf86-input-tslib. Always check that your package can be installed and upgraded: dpkg: regarding .../xserver-xorg-input-tslib_0.0.4-4_amd64.deb containing xserver-xorg-input-tslib: xserver-xorg-input-tslib conflicts with xf86-input-tslib xf86-input-tslib (version 0.0.4-3) is installed. dpkg: error processing ../xserver-xorg-input-tslib_0.0.4-4_amd64.deb (--install): conflicting packages - not installing xserver-xorg-input-tslib Errors were encountered while processing: ../xserver-xorg-input-tslib_0.0.4-4_amd64.deb The problem is a missing 'Replaces: xf86-input-tslib in debian/control. With that fixed, you would get: dpkg: considering removing xf86-input-tslib in favour of xserver-xorg-input-tslib ... dpkg: yes, will remove xf86-input-tslib in favour of xserver-xorg-input-tslib. (Reading database ... 195058 files and directories currently installed.) Unpacking xserver-xorg-input-tslib (from .../xserver-xorg-input-tslib_0.0.4-4_amd64.deb) ... Setting up xserver-xorg-input-tslib (0.0.4-4) ... If you can fix this in 0.0.4-5, I'm happy to upload. -- 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: removal of unneeded packages installed by pbuilder
On Sat, 2008-02-16 at 11:44 +0900, Paul Wise wrote: On Feb 16, 2008 11:13 AM, Kamaraju S Kusumanchi [EMAIL PROTECTED] wrote: Is there any equivalent to 'apt-get autoclean' to remove unnecessary packages installed by pbuilder? I looked in http://www.netfort.gr.jp/~dancer/software/pbuilder-doc/pbuilder-doc.html but could not find anything. You can make any changes you want to pbuilder's chroot using one of these: pbuilder --login --save-after-login No. As far as the apt cache is concerned, using 'apt-get autoclean' here does not remove the files from the *external* aptcache, only from within the chroot and is therefore pointless because precisely the same files are then copied back into the chroot when you next extract it. i.e. pbuilder (and probably cowbuilder) has a one-way copy operation built into the aptcache handler. New files downloaded in the chroot are added, existing or missing files are ignored. In essence, --save-after-login has no effect on the aptcache, only on the rest of the chroot because the aptcache isn't actually ever saved into the base tgz, it is copied in afresh each time. Try it - you'll see exactly the same files persist. (empdebuild from emdebian-tools uses pbuilder code extensively and in extending pbuilder to work with a cross building toolchain, I've learnt a bit about pbuilder internals.) pbuilder does support a clean mode but this removes all files from the aptcache, not just the unwanted ones. The current solution is to run --clean once in a while and face the hassle of having to download a lot of files that have just been deleted during the next run of pdebuild etc. If I can work out a suitable solution for empdebuild in emdebian-tools, I'll see if pbuilder can support 'autoclean' using the same patch. The idea would be to delete files in the external cache if they no longer exist inside the cache in the chroot. I suspect pbuilder has a good reason for not doing it this way so this isn't an easy fix. The main problem is breaking support for people who have pbuilder tarballs for sid, lenny and etch (or Ubuntu equivalents). Creating individual aptcaches for each is not a viable alternative. It's probably just as easy to run a cron job to remove the pbuilder aptcache once a month or so. -- 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: removal of unneeded packages installed by pbuilder
Hello,
One way to use pbuilder and avoid using aptcache is to use a
local mirroring tool as the MIRRORSITE. I use approx but YMMV.
Another way to avoid the massive file copying is to use a
BINDMOUNTS and set APTCACHE to . The tricky part is that
pbuilder's BINDMOUNTS allows you to specify the source of
the bind but not the target. So one way around this would be
to use BINDMOUNTS as /var/cache/pbuilder/${DISTRIBUTION}/aptcache.
Then you configure apt in the chroot to use this directory
as its cache directory. I had this setup until I hit upon the first
option.
Regards,
Kapil.
--
signature.asc
Description: Digital signature
Re: removal of unneeded packages installed by pbuilder
Hello, On Sun, 17 Feb 2008, Kapil Hari Paranjape wrote: Then you configure apt in the chroot to use this directory as its cache directory. I had this setup until I hit upon the first option. I forgot to say that you can use the APTCONFDIR option to give a specialised configuration for APT inside the CHROOT. Regards, Kapil. -- signature.asc Description: Digital signature
RFS: docbook-xsl (1.73.2.dfsg.1-3)
Hi, Because my usual sponsor is still busy, I would like to request a one-time sponsorship for my docbook-xsl package. The version 1.73.2.dfsg.1-3 closes: http://bugs.debian.org/445901 http://bugs.debian.org/447958 http://bugs.debian.org/449582 http://bugs.debian.org/464708 http://bugs.debian.org/465820 and is lintian clean. Get the source via dget from http://debian.wgdd.de/debian/incoming/packages/debian-xml-sgml/docbook-xsl_1.73.2.dfsg.1-3.dsc For questions, just ask. CCing the Debian XML/SGML groups list and debian-sgml. PS: It would be nice if this person could also sponsor the xmlto and docbook2x updates. See http://lists.debian.org/debian-mentors/2008/02/msg00329.html Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Writing get-orig-source targets to conform with policy
Hello, I have two questions. First question is; Is it at all possible to write a get-orig-source target that calls an external script to handle generating the orig tarball? The problem I'm facing is when the get-orig-source target is written like: get-orig-source: debian/external-script It works fine under the package's top directory, but fails under any other directory, for instance, /tmp. I've looked over the GNU make documentation hoping to find a special parameter for finding the name of the make script ran, just how a shell script has $0, but I've been unable to find one. Second question is regarding a get-orig-source target I have for the package mediatomb. It goes like: # Common variables used to ease maintenance of the get-orig-source target. MEDIATOMB_TARBALL = mediatomb-0.10.0.tar.gz MEDIATOMB_VERSION = 0.10.0 CORRECT_CHECKSUM = 2436c73de4ac5f3ba1575f7ee93a0430 # Haven't found a way to use this without running it twice COMPUTED_CHECKSUM = $(shell md5sum $(MEDIATOMB_TARBALL) | cut -d ' ' -f 1) get-orig-source: [ -e $(MEDIATOMB_TARBALL) ] || \ wget http://downloads.sourceforge.net/mediatomb/$(MEDIATOMB_TARBALL) ifeq ($(CORRECT_CHECKSUM),$(COMPUTED_CHECKSUM)) @echo Generating orig tarball tar -xzf $(MEDIATOMB_TARBALL) # Removing some problematic files from upstream rm mediatomb-$(MEDIATOMB_VERSION)/tombupnp/upnp/src/inc/upnp_md5.h rm mediatomb-$(MEDIATOMB_VERSION)/tombupnp/upnp/src/uuid/upnp_md5.c # tar -czf mediatomb_$(MEDIATOMB_VERSION).dfsg1.orig.tar.gz \ mediatomb-$(MEDIATOMB_VERSION) rm -rf mediatomb-$(MEDIATOMB_VERSION) rm $(MEDIATOMB_TARBALL) @echo done. else @echo Checksum mismatch. Correct checksum is $(CORRECT_CHECKSUM). @echo Computed checksum was $(COMPUTED_CHECKSUM). exit 1 endif The problem here is that the get-orig-source target has to be run twice before the checksum passes (unless you happen to have the file in the current directory already). Is there any way around this? The second problem is why I more interested in finding a way to handle external scripts that conforms to Debian Policy where it explains, This target may be invoked in any directory. -- Regards, Andres -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ITR: xf86-input-tslib (updated package)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Neil Williams wrote: The problem is a missing 'Replaces: xf86-input-tslib in debian/control. If you can fix this in 0.0.4-5, I'm happy to upload. Done. :-) The package can be found on mentors.debian.net: - - dget http://mentors.debian.net/debian/pool/main/x/xf86-input-tslib/xf86-input-tslib_0.0.4-5.dsc - -- Wen-Yen Chuang (caleb) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHt7jydEpXpumNYVkRAlaKAJ9KrwS9NgL1cvzT30iecWxjdt8lLQCdHm4G 1qBJVkAA3LS28zROvz4pGeo= =dV0t -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: removal of unneeded packages installed by pbuilder
Paul Wise wrote: On Feb 16, 2008 11:13 AM, Kamaraju S Kusumanchi [EMAIL PROTECTED] wrote: Is there any equivalent to 'apt-get autoclean' to remove unnecessary packages installed by pbuilder? I looked in http://www.netfort.gr.jp/~dancer/software/pbuilder-doc/pbuilder-doc.html but could not find anything. You can make any changes you want to pbuilder's chroot using one of these: pbuilder --login --save-after-login cowbuilder --login --save-after-login Thanks for all the replies. The chroot login is a cool thing to do. I did not know about it before. I finally used the --autocleanaptcache option of pbuilder and it worked. I did not notice this option before posting the question here. thanks raju -- Kamaraju S Kusumanchi http://www.people.cornell.edu/pages/kk288/ http://malayamaarutham.blogspot.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Writing get-orig-source targets to conform with policy
Hello, On Sat, 16 Feb 2008, Andres Mejia wrote: Second question is regarding a get-orig-source target I have for the package mediatomb. It goes like: # Common variables used to ease maintenance of the get-orig-source target. MEDIATOMB_TARBALL = mediatomb-0.10.0.tar.gz MEDIATOMB_VERSION = 0.10.0 CORRECT_CHECKSUM = 2436c73de4ac5f3ba1575f7ee93a0430 Why have you hardcoded the version number and checksum for the tarball? The way I understand it, the get-orig-source target is used to get newer upstream sources. Policy 4.9 says: `get-orig-source' (optional) This target fetches the most recent version of the original ^^^ source package from a canonical archive site (via FTP or WWW, for example), does any necessary rearrangement to turn it into the original source tar file format described below, and leaves it in the current directory. So your script is mainly a tool to provide an automated way for someone to get a newer version of upstream source re-packaged exactly the way you have done with the current version. If you want to document how/why you re-packaged the source for Debian, this should be in README.Debian-source. This target may be invoked in any directory, and should take care to clean up any temporary files it may have left. I think this means that you should probably run the download in a temporary directory using mktemp and then create/move the output to the directory just above the current directory. I hope this clarifies most of your questions. Regards, Kapil. -- signature.asc Description: Digital signature
Re: Writing get-orig-source targets to conform with policy
On Sunday 17 February 2008 12:52:30 am Kapil Hari Paranjape wrote: Hello, On Sat, 16 Feb 2008, Andres Mejia wrote: Second question is regarding a get-orig-source target I have for the package mediatomb. It goes like: # Common variables used to ease maintenance of the get-orig-source target. MEDIATOMB_TARBALL = mediatomb-0.10.0.tar.gz MEDIATOMB_VERSION = 0.10.0 CORRECT_CHECKSUM = 2436c73de4ac5f3ba1575f7ee93a0430 Why have you hardcoded the version number and checksum for the tarball? For ensuring the exact tarball that was used to generate the orig tarball is used. The way I understand it, the get-orig-source target is used to get newer upstream sources. Policy 4.9 says: `get-orig-source' (optional) This target fetches the most recent version of the original ^^^ source package from a canonical archive site (via FTP or WWW, for example), does any necessary rearrangement to turn it into the original source tar file format described below, and leaves it in the current directory. So your script is mainly a tool to provide an automated way for someone to get a newer version of upstream source re-packaged exactly the way you have done with the current version. Well, to me, the purpose of the get-orig-source target was to allow anyone to generate the orig tarball of the current version that is/will be uploaded to the archive. If this is what policy states, I suppose I'll just not use the target. Also, I don't want to automate packaging a new tarball too much as there are things that could change. If you want to document how/why you re-packaged the source for Debian, this should be in README.Debian-source. This target may be invoked in any directory, and should take care to clean up any temporary files it may have left. I think this means that you should probably run the download in a temporary directory using mktemp and then create/move the output to the directory just above the current directory. To me, it means running the target from any directory ($HOME, /tmp, etc.). I hope this clarifies most of your questions. Regards, Kapil. -- -- Regards, Andres -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Writing get-orig-source targets to conform with policy
On Sat, Feb 16, 2008 at 11:10:01PM -0500, Andres Mejia wrote:
Second question is regarding a get-orig-source target I have for the package
mediatomb. It goes like:
# Haven't found a way to use this without running it twice
COMPUTED_CHECKSUM = $(shell md5sum $(MEDIATOMB_TARBALL) | cut -d ' ' -f 1)
get-orig-source:
ifeq ($(CORRECT_CHECKSUM),$(COMPUTED_CHECKSUM))
The problem here is that the get-orig-source target has to be run
twice before the checksum passes (unless you happen to have the file
in the current directory already). Is there any way around this?
The reason is that $(shell ...) is evaluated by make before wget creates
the file (I think it happens at the beginning of the rule). Instead I
think you should either use a shell test:
[ $md50 = $md51 ] || { echo $0: error: ... 2; exit 1; }
Or use a 2nd rule which creates the upstream file (using wget), and then
get-orig-source depends on that rule and does md5sum; tar xzf;
manipulate; tar czf.
Justin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
