* Ben Hutchings [120527 17:25]:
> Creating arbitrarily large temporary files outside the user's home
> directory is generally going to be unreliable.
The only thing more unreliable than that is creating arbitrary large
file in user's home directory. If it is not supposed to be persistent
data tha
Your message dated Mon, 28 May 2012 11:04:38 +0200
with message-id <201205281104.39421.hol...@layer-acht.org>
and subject line this ain't a general problem
has caused the Debian Bug report #666541,
regarding [Wish] package OpenSearch descriptions for reuse by all browsers
to be marked as done.
Thi
Your message dated Mon, 28 May 2012 11:10:45 +0200
with message-id <201205281110.46218.hol...@layer-acht.org>
and subject line Re: Bug#626424: Please implement a method to save and restore
netfilter rules at boot
has caused the Debian Bug report #626424,
regarding Please implement a method to save
Your message dated Mon, 28 May 2012 11:11:39 +0200
with message-id <20120528.40391.hol...@layer-acht.org>
and subject line hardware issue, thus closing
has caused the Debian Bug report #662932,
regarding general: USB devices, mass storage, and printer cause system fail,
and report a lot of log
Processing commands for cont...@bugs.debian.org:
> reassign 635756 hal
Bug #635756 [general] unknown: Improved useability for ExpressCard to
CompactFlash adaptors
Bug reassigned from package 'general' to 'hal'.
Ignoring request to alter found versions of bug #635756 to the same values
previously
Hi,
On Fri, May 25, 2012 at 02:22:24AM +0300, Serge wrote:
> What's a temporary file? Really, why would applications temporarily store
> its data in a file? They do that to *free some memory*. Placing those files
> back to memory renders the whole process of writing the file useless.
> If the fil
On Sun, May 27, 2012 at 05:58:55PM +, Thorsten Glaser wrote:
> Charles Plessy dixit:
> >upstream source moved to GitHub, and we would like to try to maintain the
> >Debian package there as well.
>
> This is not a good idea: http://mako.cc/writing/hill-free_tools.html
MUCH seconded. Thanks for
On Mon, 28 May 2012 13:03:47 +0200
Toni Mueller wrote:
> It's not, see below. Also, most of the time, /tmp goes into / (on
> smaller systems), and is thus typically *very* much limited in space.
If the theory is to design for the "trained chicken" install (and it still is,
right?), then / gets t
On Mon, May 28, 2012 at 01:21:43PM +0800, Thomas Goirand wrote:
As you wrote, nothing is infinite. I don't think that /tmp is worse than
/home like other said. Your /home could become full as well.
Your /home could be a network share like NFS and /tmp a local partition,
so you don’t want to us
On Mon, May 28, 2012 at 01:59:24AM +0100, Ben Hutchings wrote:
I don't recall that being common practice on any multi-user Unix-like
system I've used. (It's also not something a Windows user would expect,
Well, it was back in my university days, and it still is where I work.
Maybe „multi-use
Package: wnpp
Severity: wishlist
Owner: Luk Claes
* Package name: libsiw
Version : 0.9?
Upstream Author : Bernard Metzler
* URL : https://gitorious.org/softiwarp/userlib
* License : GPL-2 or BSD
Programming Lang: C
Description : user space library for
On 28/05/12 08:15, Miles Bader wrote:
> Salvo Tomaselli writes:
>>> This is indeed a valid point. But that’s no regression; /tmp has
>>> always been for small short-lived files, and /var/tmp for those
>>> that are not one of them or not both.
>>
>> You just made up this difference.
>
> No he didn
Package: wnpp
Severity: wishlist
Owner: Luk Claes
* Package name: softiwarp-kernel
Version : ??
Upstream Author : Bernard Metzler
* URL : https://gitorious.org/softiwarp/kernel
* License : GPL-2 or BSD
Programming Lang: C
Description : Soft-iWARP kerne
Hi Debian,
Are you still interested in learning more about green funds?
Kind regards,
Louise Smith
Investment Consultant
Offshore Consulting Group
Email: l...@ocgbiz.com
www.ocgbiz.com
Tel: (0034)695 487 889
This e-mail and all information contained in it is confidential and
may be
On 05/28/2012 04:46 AM, Serge wrote:
> The truth is that tmpfs IS FASTER in some cases. The problem is that
> *nobody* can notice that on *real* applications.
Serge, I'm on your side of the discussion, but the above is simply
not truth. And by the way, that's not the issue. The issue is potential
b
On 28/05/12 17:48, Thomas Goirand wrote:
> On 05/28/2012 04:46 AM, Serge wrote:
>> The truth is that tmpfs IS FASTER in some cases. The problem is that
>> *nobody* can notice that on *real* applications.
> Serge, I'm on your side of the discussion, but the above is simply
> not truth. And by the wa
On Tue, May 22, 2012 at 05:06:25PM -0700, Steve Langasek wrote:
> Of course, all of these packages appear to be specific to amd64, so I don't
> know why Mark would be adding new biarch packages for s390. You should
> probably ask him.
Ask the s390x folks, they asked for them. Though what on ear
On Tue, May 22, 2012 at 12:14:49PM +, Thorsten Glaser wrote:
> Seeing the trouble broonie has with zlib, why are those
> packages still built anyway? Can???t they please go away?
The biarch packages really aren't any bother, the issue with s390x has
been having to jump through hoops due to th
Mark Brown (28/05/2012):
> Ask the s390x folks, they asked for them. Though what on earth inspired
> them to name the new architecture such that the old architecture name is
> a substring of the new name is beyond me... As far as I can tell nobody
> is really using the biarch packages on most ar
[Philip Ashmore]
> On my machine running "set > set.txt && ls -lsa set.txt" reveals that my
> environment contains 225517 of "stuff" - some of it is even being
> taken up by
> exported function definitions!
As mentioned earlier, 'set' is not reporting much more than the
environment exported to ex
On 28/05/12 19:17, Peter Samuelson wrote:
[Philip Ashmore]
On my machine running "set> set.txt&& ls -lsa set.txt" reveals that my
environment contains 225517 of "stuff" - some of it is even being
taken up by
exported function definitions!
As mentioned earlier, 'set' is not reporting much mo
[Ben Hutchings]
> We should be thinking about implementing per-user temporary directories
> and making sure that programs respect $TMPDIR.
Yes, per-user temp directories is a good idea. Installing the
libpam-tmpdir package enable this by default, and beside some problems
with the root user (bad T
On 05/28/2012 04:47 PM, Bernhard R. Link wrote:
> I personally think having tmpdir on /tmp might be a good default for
> new systems. If systems get changed to that from something else on
> upgrade without asking, I consider that quite an ugly bug.
>
And you're not the only one. It seems that at
[Philip Ashmore]
> I guess I'm confused as to why bash completion needs these.
Easy enough to read /etc/bash_completion and /etc/bash_completion.d/*
and see for yourself why it needs these.
bash-completion is full of special cases to "do the right thing" in
hundreds or thousands of different cir
Peter Samuelson writes:
> If you can think of a way to implement this same stuff (and remember,
> bash-completion supports a _lot_ more complex cases than 'kill')
> without adding 200 kB of shell functions to bash's runtime, by all
> means, do it and see how it works out.
What would seem interest
On Tue, May 29, 2012 at 9:18 AM, Miles Baderwrote:
> What would seem interesting would be a way to autoload bash completion
> support for each command ... as it would seem not uncommon to have shell
> sessions where the user never tries to use completion for 99% of the
> commands handled.
>
> [or
On 05/29/2012 03:13 AM, Petter Reinholdtsen wrote:
> Perhaps it should be
> extended to allow the directory to be below ~/ instead of below
> /tmp/. :)
>
I don't think so. As other pointed out, your /home could be
remote (over NFS?), and then slow, while /tmp is normally
on your local machine, s
Package: libpam-tmpdir
Severity: wishlist
]] Petter Reinholdtsen
> [Ben Hutchings]
> > We should be thinking about implementing per-user temporary directories
> > and making sure that programs respect $TMPDIR.
>
> Yes, per-user temp directories is a good idea. Installing the
> libpam-tmpdir p
]] Thomas Goirand
> What's the folder structure in /tmp then? /tmp//$USER?
/tmp/user/$UID is the default. It can be overridden, but not in a
manner that's compatible with Petter's suggestion.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
--
To UNSUBSCR
On Tue, 2012-05-29 at 12:15 +0800, Thomas Goirand wrote:
> What's the folder structure in /tmp then? /tmp//$USER?
It's the Wild West over there. You'll often see something
like /tmp/$procname/$pid/blah or /tmp/$procname/$user/blah, or
just /tmp/$some_hash_of_who_knows_what/blah.
FHS is uncharact
Brian May writes:
>>> This is not a good idea: http://mako.cc/writing/hill-free_tools.html
>>
>> MUCH seconded. Thanks for sharing the link!
>
> I don't see the problem, github is just a hosting provider. Unlike,
> say Bitkeeper, you are free to make git clones anywhere, entirely with
> open sourc
Thomas Goirand writes:
>> Perhaps it should be
>> extended to allow the directory to be below ~/ instead of below
>> /tmp/. :)
>>
> I don't think so. As other pointed out, your /home could be
> remote (over NFS?), and then slow, while /tmp is normally
> on your local machine, so moving the temp
Miles Bader writes:
> bazillion packages in debian that blithely cache vast quantities of
> (often very uninteresting) data in random subdirs of $HOME... and then
Fortunately there is some movement towards the use of XDG_CACHE_DIR
(defaults to ~/.cache).
--
To UNSUBSCRIBE, email to debian-deve
I am thinking about a more general topic like:
Managing packaging on VCS services other than Alioth
I think it is not good to focus on a specific service or tool.
Just 2 cents.
--
Yao Wei
P.S. AFAIK pkg-ime is currently syncing pkg-ime packaging with GitHub
for backup, for checking out them at
On 28 May 2012 21:16, Toni Mueller wrote:
>> This is not a good idea: http://mako.cc/writing/hill-free_tools.html
>
> MUCH seconded. Thanks for sharing the link!
I don't see the problem, github is just a hosting provider. Unlike,
say Bitkeeper, you are free to make git clones anywhere, entirely w
Package: wnpp
Severity: wishlist
Owner: "Yao Wei (魏銘廷)"
* Package name: hime-table-dayi3
* URL : http://hime.luna.com.tw/
* License : Proprietary (Not modifiable)
Description : Dayi 3-key table for hime input method
This is one of the Chinese input method table call
36 matches
Mail list logo
