Skip Menu |
 

This queue is for tickets about the PAR-Repository-Client CPAN distribution.

Report information
The Basics
Id: 30018
Status: resolved
Priority: 0/
Queue: PAR-Repository-Client

People
Owner: Nobody in particular
Requestors: ANDK [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Unimportant
Broken in: (no value)
Fixed in: (no value)



Subject: Cleaning up /tmp directory
MIME-Version: 1.0
X-Mailer: MIME-tools 5.418 (Entity 5.418)
Content-Type: text/plain; charset="utf8"
Content-Disposition: inline
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 294
Download (untitled) / with headers
text/plain 294b
Today I can conclude from the timestamp that running make test on SMUELLER/PAR-Repository-Client-0.16.tar.gz has left over a directory /tmp/par-sand/ containing randomly named subdirectories. Would it be feasible without too much hassle to cleanup /tmp/ directory after being run? Thanks!
MIME-Version: 1.0
X-Mailer: MIME-tools 5.418 (Entity 5.418)
Content-Disposition: inline
Message-Id: <rt-3.6.HEAD-18555-1192521503-917.30018-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf8"
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Original-Encoding: utf-8
Content-Length: 747
Download (untitled) / with headers
text/plain 747b
Hallo Andreas, On Mon Oct 15 17:22:38 2007, ANDK wrote: Show quoted text
> Today I can conclude from the timestamp that running make test on > > SMUELLER/PAR-Repository-Client-0.16.tar.gz > > has left over a directory /tmp/par-sand/ containing randomly named > subdirectories. > > Would it be feasible without too much hassle to cleanup /tmp/ directory > after being run?
This is a general PAR thing. The directories under par-$USER are caches for individual .par's that were loaded. I just checked and realized they were empty after make test anyway. I'll see whether I can remove them without deleting the par-$USER directory which may contain valid application caches. This might take some time, though, so don't hold your breath. Best regards, Steffen
CC: ANDK [...] cpan.org
MIME-Version: 1.0
X-Spam-Status: No, hits=-2.6 required=8.0 tests=BAYES_00
X-Authentication-Warning: k75.linux.bogus: k set sender to andreas.koenig.7os6VVqR [...] franz.ak.mind.de using -f
In-Reply-To: <rt-3.6.HEAD-18555-1192521503-917.30018-6-0 [...] rt.cpan.org> (Steffen Müller via's message of "Tue\, 16 Oct 2007 03\:58\:27 -0400")
References: <RT-Ticket-30018 [...] rt.cpan.org> <rt-3.6.HEAD-18555-1192521503-917.30018-6-0 [...] rt.cpan.org>
Content-Type: text/plain; charset=utf-8
X-RT-Original-Encoding: utf-8
Received: from la.mx.develooper.com (x1.develooper.com [63.251.223.170]) by diesel.bestpractical.com (Postfix) with SMTP id 3F91B4D8044 for <bug-PAR-Repository-Client [...] rt.cpan.org>; Tue, 16 Oct 2007 18:37:52 -0400 (EDT)
Received: (qmail 26634 invoked by alias); 16 Oct 2007 22:37:51 -0000
Received: from franz.ak.mind.de (HELO franz.ak.mind.de) (212.42.235.66) by la.mx.develooper.com (qpsmtpd/0.28) with ESMTP; Tue, 16 Oct 2007 15:37:49 -0700
Received: from k75.linux.bogus (localhost.localdomain [127.0.0.1]) by franz.ak.mind.de (8.13.8/8.14.1/Debian-8) with ESMTP id l9GMbYCT025605; Wed, 17 Oct 2007 00:37:34 +0200
Received: (from k [...] localhost) by k75.linux.bogus (8.13.8/8.13.8/Submit) id l9GMbYg6025601; Wed, 17 Oct 2007 00:37:34 +0200
Delivered-To: cpan-bug+par-repository-client [...] diesel.bestpractical.com
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
Subject: Re: [rt.cpan.org #30018] Cleaning up /tmp directory
Return-Path: <andreas.koenig.7os6VVqR [...] franz.ak.mind.de>
X-Spam-Check-BY: la.mx.develooper.com
X-Original-To: bug-PAR-Repository-Client [...] rt.cpan.org
Date: Wed, 17 Oct 2007 00:37:32 +0200
Message-Id: <87r6jufzyr.fsf [...] k75.linux.bogus>
To: bug-PAR-Repository-Client [...] rt.cpan.org
Content-Transfer-Encoding: quoted-printable
From: andreas.koenig.7os6VVqR [...] franz.ak.mind.de (Andreas J. Koenig)
X-RT-Original-Encoding: utf-8
RT-Message-ID: <rt-3.6.HEAD-18552-1192574281-1340.30018-0-0 [...] rt.cpan.org>
Content-Length: 1035
Show quoted text
>>>>> On Tue, 16 Oct 2007 03:58:27 -0400, "Steffen Müller via RT" <bug-PAR-Repository-Client@rt.cpan.org> said:
Show quoted text
>> Would it be feasible without too much hassle to cleanup /tmp/ directory >> after being run?
Show quoted text
> This is a general PAR thing. The directories under par-$USER are caches > for individual .par's that were loaded. I just checked and realized they > were empty after make test anyway.
This is not my experience. The par-sand directory contained a couple of cache directories and they were not empty. But now that you explained it to me, I understand that they were probably left over from other tests from other packages. Show quoted text
> I'll see whether I can remove them > without deleting the par-$USER directory which may contain valid > application caches. This might take some time, though, so don't hold > your breath.
No problem. I just wanted to raise your awareness that some the /tmp directory need some cleanup after tests. Since I started testing I have a new sensibility for this question ;) -- andreas
MIME-Version: 1.0
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
Charset: utf8
Content-Type: text/plain
Message-ID: <rt-3.6.HEAD-24714-1231868445-1856.30018-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 453
Download (untitled) / with headers
text/plain 453b
Hi Andreas, It's been a while since you filed this ticket. It was only today that an obvious solution occurred to me. Any versions of PAR::Repository::Client *beyond* 0.21_01 will not leave test files around in /tmp. I haven't made a release yet since this is the only change since 0.21_01. Thanks for going through the trouble of regularly filing tickets for all the problems you diagnose. Writing those up is not a small task. Best regards, Steffen


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.