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 files are
On Fri, May 25, 2012 at 06:08:34AM +0300, Serge wrote:
It dosn't always work in practice. Among the problems I faced myself...
I wasn't able to watch a web presentation (from something like
vimeo/youtube), because there was not enough free space in /tmp for flash
player to download and show
On Fri, May 25, 2012 at 12:41:44PM +0600, Andrey Rahmatullin wrote:
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
Le vendredi 25 mai 2012 à 02:22 +0300, Serge a écrit :
I've read across different debates about whether using tmpfs is good or bad
but I could not find the most important reason, so here it is...
Reason
==
What's a temporary file? Really, why would applications temporarily store
its
Le 25/05/2012 05:03, Russell Coker a écrit :
On Fri, 25 May 2012, Serge sergem...@gmail.com wrote:
Q: /tmp on tmpfs increases apps performance.
A: What apps? Real apps don't write files during performance-critical
operations. Even if they do, they write large files. And large files are
On Fri, May 25, 2012 at 08:22:20AM +0100, Jon Dowland 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.
On Fri, 25 May 2012 02:22:24 +0300
Serge sergem...@gmail.com 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.
Most
On Fri, May 25, 2012 at 09:46:37AM +0200, Vincent Danjean wrote:
If some kind of sync is required by the application, I think this is
because the application want to ensure the data are really written to
the disk so that their state remains coherent even in case of crash.
If the application
On 05/25/2012 03:22 PM, Jon Dowland wrote:
How much RAM do you have / how big is your /tmp(fs)? The fact this caused
you trouble suggests to me that they must be very small.
What if we're installing Debian on a very small system, and that
we need operations with big files in /tmp?
How much
We all know how bad can Linux behave in some conditions involving heavy
swap usage.
Apparently not everybody has experienced that, and this would explain why they
are so happy about the idea of paging out a couple of Gigabytes.
--
Salvo Tomaselli
--
To UNSUBSCRIBE, email to
This is complete bullshit. If you know nothing about how virtual memory
works, please refrain from making a fool of yourself.
:-(
Files which are written on a regular filesystem stay on memory. This is
called the buffer cache. Whenever they are not used and/or the system
needs to reclaim
It's beginning to sound like your particular machines need either more
RAM or to use a different temporary location which is on a permanent
location. Just add some rules to clean it all up at reboot.
Perhaps there are a couple of thousand users with the same use case, I don't
know if it is the
On Vi, 25 mai 12, 17:08:42, Thomas Goirand wrote:
On 05/25/2012 03:22 PM, Jon Dowland wrote:
How much RAM do you have / how big is your /tmp(fs)? The fact this caused
you trouble suggests to me that they must be very small.
What if we're installing Debian on a very small system, and
Hi all,
like many, I also felt like I had something to say in that thread. But as
discussed in the “making debian-devel useful” thread(s), I will wait a bit to
see if others will not say it better before me.
Most importantly, it has been proposed many times that pepole limit themselves
to
On 25/05/12 11:08, Thomas Goirand wrote:
On 05/25/2012 03:22 PM, Jon Dowland wrote:
How much RAM do you have / how big is your /tmp(fs)? The fact this
caused you trouble suggests to me that they must be very small.
What if we're installing Debian on a very small system, and that we
need
Le vendredi 25 mai 2012 à 11:11 +0200, Salvo Tomaselli a écrit :
You seem to forget that memory is not an unlimited resource, the system might
need it for other things, and in that case a large tmpfs causes severe
slowdown (and even complete freeze).
Then increase your swap size.
When you
Le vendredi 25 mai 2012 à 11:04 +0200, Salvo Tomaselli a écrit :
Apparently not everybody has experienced that, and this would explain why
they
are so happy about the idea of paging out a couple of Gigabytes.
Because paging out a couple Gigabytes is veery different from
writing a couple
Because paging out a couple Gigabytes is veery different from
writing a couple Gigabytes to disk, of course.
Yes because writing that on disk will only block the thread performing the
write, not every thread that tries to allocate memory.
--
Salvo Tomaselli
--
To UNSUBSCRIBE, email to
Am 2012-05-25 11:19, schrieb Salvo Tomaselli:
It's beginning to sound like your particular machines need either
more
RAM or to use a different temporary location which is on a permanent
location. Just add some rules to clean it all up at reboot.
Perhaps there are a couple of thousand users with
In data Friday 25 May 2012 11:39:07, Josselin Mouette ha scritto:
Le vendredi 25 mai 2012 à 11:11 +0200, Salvo Tomaselli a écrit :
You seem to forget that memory is not an unlimited resource, the system
might need it for other things, and in that case a large tmpfs causes
severe slowdown
On Fri, 25 May 2012, Thomas Goirand wrote:
for small files, and in that case, it's faster. In reality, it's
not that much faster, thanks to Linux caching of the filesystem,
Under heavy filesystem IO load, yes it is. By several orders of magnitude.
the point. Maybe we should add a
On Friday 25 May 2012 09:46:37 Vincent Danjean wrote:
If some kind of sync is required by the application, I think this is
because the application want to ensure the data are really written to
the disk so that their state remains coherent even in case of crash.
If the application is ok to
On Fri, 25 May 2012, Jon Dowland wrote:
On Fri, May 25, 2012 at 09:46:37AM +0200, Vincent Danjean wrote:
If some kind of sync is required by the application, I think this is
because the application want to ensure the data are really written to
the disk so that their state remains coherent
Doing that on inferior hardware is just plain stupid. If you have
plenty of
disk space, just unpack the tar archive.
Double-click on a .tar causes it to be unpacked in /tmp/something.
I suppose a lot of not so skilled users do that instead of tar -xf
And those with lots of RAM but not so
On Fri, 25 May 2012, Salvo Tomaselli wrote:
Because paging out a couple Gigabytes is veery different from
writing a couple Gigabytes to disk, of course.
Yes because writing that on disk will only block the thread performing the
write, not every thread that tries to allocate memory.
On Fri, 25 May 2012, Salvo Tomaselli wrote:
nevertheless. And somehow the OOM killer was not even triggered, i kept
ending
up with a system where i had a working shell but could not run certain
commands (such as kill), but i could see the output of free for example.
Switch to the deadline
On 25/05/2012 18:20, Salvo Tomaselli wrote:
Double-click on a .tar causes it to be unpacked in /tmp/something.
I suppose a lot of not so skilled users do that instead of tar -xf
That doesn't seem to happen with file-roller. Perhaps you need to file a bug
with your graphical archiver program.
Henrique de Moraes Holschuh dixit:
On Fri, 25 May 2012, Thomas Goirand wrote:
for small files, and in that case, it's faster. In reality, it's
not that much faster, thanks to Linux caching of the filesystem,
Under heavy filesystem IO load, yes it is. By several orders of magnitude.
Not just
On Fri, May 25, 2012 at 1:32 AM, Brian May
br...@microcomaustralia.com.au wrote:
On 23 May 2012 23:31, Bastien ROUCARIES roucaries.bast...@gmail.com wrote:
9. git checkout -b debian-patches/6.7.7.0-1
10. git checkout -b debian/6.7.7.0-1 # create new debian branch
Just curious here, why do
On Fri, May 25, 2012 at 02:22:24AM +0300, Serge wrote:
I've read across different debates about whether using tmpfs is good or bad
but I could not find the most important reason, so here it is...
I haven't got anything particularly new to add to the discussion here.
But I would like to refer
Jon Dowland dixit:
On Fri, May 25, 2012 at 09:46:37AM +0200, Vincent Danjean wrote:
If some kind of sync is required by the application, I think this is
because the application want to ensure the data are really written to
the disk so that their state remains coherent even in case of crash.
Chow Loong Jin dixit:
On 25/05/2012 18:20, Salvo Tomaselli wrote:
Double-click on a .tar causes it to be unpacked in /tmp/something.
I suppose a lot of not so skilled users do that instead of tar -xf
That doesn't seem to happen with file-roller. Perhaps you need to file a bug
Hm. mc does put
2012/5/25 Neil Williams wrote:
You cannot expect to mix those two worlds and for things to just
work.
Easy. Let's leave /tmp on a real disk and both world will just work.
If program A is too resource-hungry, find (or write) program B.
Or fix the program A, right? And here we go... By
2012/5/25 Henrique de Moraes Holschuh wrote:
Switch to the deadline IO scheduler
[...] and make proper use of cgroups.
[...] And disable memory overcommit
Ehm, so you assume that heavy swapping is not a bad thing, and instead of
fixing a single default option you suggest every debian user to
Hi there,
this Bugreport (see below) seems to break the bts [1]
just for the record.
kind regards,
Michael
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674515
Beginn der weitergeleiteten Nachricht:
Datum: Fri, 25 May 2012
2012/5/25 Thorsten Glaser wrote:
It’s faster because the files don’t even get written to disc if
they’re kept for, say, five minutes, and aren’t just short-lived.
Theoretically, yes. But I'm not asking to forbid everybody to use
tmpfs. We're talking about defaults and about the most used test
On Fri, May 25, 2012 at 11:11:06AM +0200, Salvo Tomaselli wrote:
Files which are written on a regular filesystem stay on memory. This is
called the buffer cache. Whenever they are not used and/or the system
needs to reclaim memory, they are trashed.
Files which are written on a tmpfs stay
Hi,
On 2012-05-25 13:40, Michael Stummvoll wrote:
Hi there,
this Bugreport (see below) seems to break the bts [1]
just for the record.
ow...@bugs.debian.org is the place to report this.
Thanks,
--
Jonathan Wiltshire j...@debian.org
Debian Developer
On Fri, May 25, 2012 at 03:50:31PM +0300, Serge wrote:
/tmp on tmpfs won't help in that case. You do not reduce number of disk
writes, you just move them to other directories. As you suggested, all
the programs will still use files i.e. in /var/tmp. Or they'll write to
swap if tmpfs is large
ow...@bugs.debian.org is the place to report this.
Thanks,
I just send the mail there, thanks for that info.
Kind regards,
Michael
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
Josselin Mouette wrote:
Files which are written on a regular filesystem stay on memory. This is
called the buffer cache. Whenever they are not used and/or the system
needs to reclaim memory, they are trashed.
Files which are written on a tmpfs stay on memory. Whenever they are not
used and/or
Le vendredi 25 mai 2012 à 16:01 +0300, Uoti Urpala a écrit :
There is one significant difference though. When you read data back to
memory from swap, the kernel does not remember that it already exists on
disk; when the data is evicted from memory again, it is unnecessarily
rewritten to disk
On 25/05/12 13:50, Serge wrote:
Again, I'm not asking to drop this feature. I'm asking to have it disabled
*by default* but supported by debian installer, so really smart people,
that know what may be broken by it, but really need it, could enable it.
+1
On 25/05/12 13:52, Ted Ts'o wrote:
2012/5/25 Andrey Rahmatullin wrote:
Why do you assume tmpfs contents is always written to the swap?
Most programs, using /tmp for temporary files, may write *large* files
there. So most programs fill tmpfs with large files. So tmpfs grows and
swaps out (probably swapping out other applications
On Fri, May 25, 2012 at 05:08:37PM +0300, Serge wrote:
Why do you assume tmpfs contents is always written to the swap?
Most programs, using /tmp for temporary files, may write *large* files
there. So most programs fill tmpfs with large files. So tmpfs grows and
swaps out (probably swapping
On Fri, May 25, 2012 at 11:44:15AM +, Thorsten Glaser wrote:
No. An application might not know it’s writing to tmpfs (for
example, if it wasn’t even written for an operating system
with tmpfs in the first place). And it might want to use sync
writes. The user of such application might want
On Fri, May 25, 2012 at 05:08:42PM +0800, Thomas Goirand wrote:
On 05/25/2012 03:22 PM, Jon Dowland wrote:
How much RAM do you have / how big is your /tmp(fs)? The fact this caused
you trouble suggests to me that they must be very small.
What if we're installing Debian on a very small
]] Josselin Mouette
Le vendredi 25 mai 2012 à 11:11 +0200, Salvo Tomaselli a écrit:
You seem to forget that memory is not an unlimited resource, the
system might need it for other things, and in that case a large
tmpfs causes severe slowdown (and even complete freeze).
Then increase
Serge sergem...@gmail.com writes:
Suggestion
==
Do not mount /tmp as tmpfs by default. Instead...
Debian already allows custom partitioning during the system install. For
example it's possible to mount /tmp on a separate partition. The suggestion
is to extend partitioner with a new
On Fri, 25 May 2012 15:25:58 +0300
Serge sergem...@gmail.com wrote:
2012/5/25 Neil Williams wrote:
You cannot expect to mix those two worlds and for things to just
work.
Easy. Let's leave /tmp on a real disk and both world will just work.
Do you not use swap?
If program A is too
Switch to the deadline IO scheduler
[...] and make proper use of cgroups.
[...] And disable memory overcommit
[Serge]
instead of fixing a single default option you suggest every debian
user to tweak and/or rebuild the kernel? Are you serious? ;)
What?!? and/or rebuild the kernel is
2012/5/25 Jon Dowland wrote:
I wasn't able to watch a web presentation (from something like
vimeo/youtube), because there was not enough free space in /tmp for
flash player to download and show it.
I thought those were streaming video sites?
You mean, those sites don't store temporary
Serge dixit:
cases. Can you name some popular real-world program that write
only small files and become noticeably faster when /tmp is on tmpfs?
Most shell scripts using (here documents). mc, out of all things,
as long as the temporary files (e.g. of a tarball) fit inside it.
And countless
2012/5/25 Nikolaus Rath wrote:
You still haven't said what the new default should be.
The suggestion was to just leave it as it was configured in partitioner.
If it was configured as a part of root fs leave it as it is. If it's on
a separate partition leave it there. Just no automatic tmpfs.
2012/5/25 Neil Williams wrote:
Do you not use swap?
I use it for suspend-to-disk.
Yes you lose functionality but functionality takes up resources, so
something has to give.
Which functionality will I lose by placing /tmp on the real disk?
The vast majority of systems have large amounts of
On Fri, 2012-05-25 at 10:02 -0400, Nikolaus Rath wrote:
I think having / and /tmp share the same file system is a bad idea,
because then writing lots of stuff to /tmp would potentially fill up the
root file system (that typically also includes /var) and then cause a
lot of breakage.
If only
Serge sergem...@gmail.com writes:
2012/5/25 Nikolaus Rath wrote:
You still haven't said what the new default should be.
The suggestion was to just leave it as it was configured in partitioner.
If it was configured as a part of root fs leave it as it is. If it's on
a separate partition leave
So what? If you write to a normal file system, it goes into the page
cache, which is pretty much the same as writing into tmpfs.
tmpfs will make it stay forever in the RAM, caches are flushed to disk and
their space can be used for new things.
- Ted
--
Salvo
On 05/25/2012 10:20 PM, Andrey Rahmatullin wrote:
/tmp 8,0G 60M 8,0G1% /tmp
Does this count as large files?
As a lot of small-only files?
Exactly how is this a practical explanation and example? :/
Are you saying that in *your case* /tmp is almost unused?
On 05/26/2012 12:21 AM, Thorsten Glaser wrote:
What you want is
to optimise for a corner case.
Ah... So Mysql, flash videos, mc, image editors,
cd burners, and all the (very common) examples
he gave are just corner cases in your book?
We must have very different readings...
Thomas
--
To
Salvo Tomaselli dixit:
tmpfs will make it stay forever in the RAM, caches are flushed to disk and
their space can be used for new things.
For sane values of “forever”, usually a second of so.
As long as there’s a way to change it¹, please don’t optimise
for the uncommon behaviour.
① tmpfs can
On 05/25/2012 05:33 PM, Mehdi Dogguy wrote:
What if we're installing Debian on a very small system, and that we
need operations with big files in /tmp?
Increase your swap?
So, in this case, we will have the following scenario:
- An app writes in /tmp
- There's not enough space, so the
Le 25/05/2012 04:00, Steve Langasek a écrit :
On Fri, May 25, 2012 at 03:57:28AM +0300, Serge wrote:
Every file that exists in /tmp on the system from which I'm writing this
exists there not because the application is saving memory but because the
application needs to share that file with
In data Friday 25 May 2012 21:23:28, Thorsten Glaser ha scritto:
Salvo Tomaselli dixit:
tmpfs will make it stay forever in the RAM, caches are flushed to disk and
their space can be used for new things.
For sane values of “forever”, usually a second of so.
I've things in my /tmp that were
Weldon Goree wel...@b.rontosaur.us writes:
On Fri, 2012-05-25 at 10:02 -0400, Nikolaus Rath wrote:
I think having / and /tmp share the same file system is a bad idea,
because then writing lots of stuff to /tmp would potentially fill up the
root file system (that typically also includes /var)
Nikolaus Rath nikol...@rath.org wrote:
I think having / and /tmp share the same file system is a bad idea,
because then writing lots of stuff to /tmp would potentially fill up
the
root file system (that typically also includes /var) and then cause a
lot of breakage.
no, by default ext3/4
On Fri, May 25, 2012 at 08:14:10PM +0300, Serge wrote:
2012/5/25 Neil Williams wrote:
Different hardware - different software selection.
I don't understand your point. I could understand it if we were choosing
among benefits that most users get from /tmp being on disk and /tmp being
on
Serge sergem...@gmail.com writes:
Every tool either supports setting TMPDIR=/var/tmp before running
it or is buggy. Go fix these instead
Do I understand you right? You suggest every tool that need large
tmp files to use /var/tmp instead?
That's not a new suggestion, it's been standard
Le Fri, May 25, 2012 at 12:44:03PM +0100, Roger Leigh a écrit :
I haven't got anything particularly new to add to the discussion here.
But I would like to refer you to the previous discussion on the
topic. I am well aware that the default does not satisfy all use
cases, but that's simply
2012/5/25 Thorsten Glaser wrote:
Ok, we have guesses, let's do some TESTS...
Can you name some popular real-world program that write
only small files and become noticeably faster when /tmp is on tmpfs?
Most shell scripts using (here documents). mc, out of all things,
as long as the
Serge sergem...@gmail.com writes:
I'm asking for *popular* apps, that create files in /tmp, *never put
large files* there, and become *noticeably* faster with /tmp on tmpfs?
Is that even the issue, for the most part? My impression is that
using tmpfs is just logistically simpler and safer --
On Fri, May 25, 2012 at 02:49:14PM +0100, Will Daniels wrote:
On 25/05/12 13:52, Ted Ts'o wrote:
So what? If you write to a normal file system, it goes into the page
cache, which is pretty much the same as writing into tmpfs. In both
cases if you have swap configured, the data will get
Thomas Goirand z...@debian.org writes:
On 05/25/2012 05:33 PM, Mehdi Dogguy wrote:
What if we're installing Debian on a very small system, and that we
need operations with big files in /tmp?
Increase your swap?
So, in this case, we will have the following scenario:
- An app writes in
Hi there.
First, here's what I'm talking about -
http://en.wikipedia.org/wiki/Permalink
Unfortunately Wikipedia doesn't offer permalinks itself, so hopefully
the above
link won't rot.
This was initially in reference to the recent spat of comments/opinions to
Re: Moving /tmp to tmpfs makes it
2012/5/25 Nikolaus Rath wrote:
I don't think /tmp as part of the rootfs is a good idea for the reasons
outlined in the rest of my mail.
Forgot to answer that part. Sorry.
I think having / and /tmp share the same file system is a bad idea,
because then writing lots of stuff to /tmp would
Hi there.
I recently had cause to search for an environment variable to see if it
was being set.
As a result I noticed that the environment has become a bit of a dumping
ground for
installed programs where configuration files would have been a cleaner
option.
Looking for an override in the
On Sat, May 26, 2012 at 03:50:02AM +0100, Philip Ashmore wrote:
[...]
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!
That's 225517 bytes that needs to be copied
On 26/05/12 03:50, Philip Ashmore wrote:
That's 225517 bytes that needs to be copied every time a script runs.
Yeah that should read every time a script or program runs.
Philip
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
On 26/05/12 03:59, Philip Ashmore wrote:
On 26/05/12 03:50, Philip Ashmore wrote:
That's 225517 bytes that needs to be copied every time a script runs.
Yeah that should read every time a script or program runs.
Philip
Sorry Ben, our emails collided.
According to man sh (which links to
Philip Ashmore cont...@philipashmore.com writes:
According to man sh (which links to the dash man page)
set [{ -options | +options | -- }] arg ...
The set command performs three different functions.
With no arguments, it lists the values of all shell variables.
On 26/05/12 04:14, Russ Allbery wrote:
I'm curious why even your set of shell variables is so large, though. My
environment is only 1699 bytes on a system I logged onto via ssh, and
1998
on my desktop (running Xfce). One of the biggest chunks of that is
LS_COLORS.
Here's where I wish I
Hi,
On Fri, May 25, 2012 at 08:14:28PM -0700, Russ Allbery wrote:
Philip Ashmore cont...@philipashmore.com writes:
I'm curious why even your set of shell variables is so large, though. My
environment is only 1699 bytes on a system I logged onto via ssh, and 1998
on my desktop (running Xfce).
Philip Ashmore cont...@philipashmore.com writes:
Here's where I wish I was a shell script guru:
for var in `cat set.txt`; do
{ if in env discard }
done
{ sort offenders by decending size }
Here's a summary of the ones that caught my eye. Sorry if I missed
anyone out!
Oh.
On 26/05/12 04:34, Russ Allbery wrote:
Philip Ashmore cont...@philipashmore.com writes:
Here's where I wish I was a shell script guru:
for var in `cat set.txt`; do
{ if in env discard }
done
{ sort offenders by decending size }
Here's a summary of the ones that caught my
2012/5/26 Miles Bader wrote:
I'm asking for *popular* apps, that create files in /tmp, *never put
large files* there, and become *noticeably* faster with /tmp on tmpfs?
Is that even the issue, for the most part? My impression is that
using tmpfs is just logistically simpler and safer -- it
Excerpts from Ted Ts'o's message of 2012-05-25 18:56:55 -0700:
On Fri, May 25, 2012 at 02:49:14PM +0100, Will Daniels wrote:
On 25/05/12 13:52, Ted Ts'o wrote:
So what? If you write to a normal file system, it goes into the page
cache, which is pretty much the same as writing into tmpfs.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Thu, 24 May 2012 10:52:22 +0200
Source: foomatic-db
Binary: foomatic-db foomatic-db-compressed-ppds openprinting-ppds
openprinting-ppds-extra
Architecture: source all
Version: 20120523-1
Distribution: unstable
Urgency: low
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Wed, 23 May 2012 17:59:07 +0200
Source: foo2zjs
Binary: printer-driver-foo2zjs foo2zjs
Architecture: source amd64 all
Version: 20120510dfsg0-1
Distribution: unstable
Urgency: low
Maintainer: Debian Printing Team
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Thu, 24 May 2012 14:13:43 +0200
Source: pyside
Binary: python-pyside python3-pyside libpyside1.1 libpyside-py3-1.1
libpyside-dev python-pyside.qtcore python3-pyside.qtcore
python-pyside.qtdeclarative python3-pyside.qtdeclarative
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Fri, 25 May 2012 08:22:27 +0200
Source: live-build
Binary: live-build live-build-cgi live-build-cron
Architecture: source all
Version: 3.0~a48-1
Distribution: unstable
Urgency: low
Maintainer: Debian Live Project
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Format: 1.8
Date: Fri, 25 May 2012 06:45:11 +
Source: php-config
Binary: php-config
Architecture: source all
Version: 1.10.12-3
Distribution: unstable
Urgency: low
Maintainer: PKG-PHP PEAR team pkg-php-p...@lists.alioth.debian.org
Changed-By:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Fri, 25 May 2012 00:44:09 +0200
Source: wine
Binary: wine wine-bin libwine-dbg libwine-dev libwine libwine-alsa libwine-bin
libwine-capi libwine-cms libwine-esd libwine-gl libwine-gphoto2 libwine-jack
libwine-ldap libwine-nas
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Format: 1.8
Date: Fri, 25 May 2012 11:13:30 +0400
Source: libdr-tarantool-perl
Binary: libdr-tarantool-perl
Architecture: source amd64
Version: 0.08-1
Distribution: unstable
Urgency: low
Maintainer: Dmitry E. Oboukhov un...@debian.org
Changed-By:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Format: 1.8
Date: Fri, 25 May 2012 11:20:52 +0400
Source: libdr-tarantool-perl
Binary: libdr-tarantool-perl
Architecture: source amd64
Version: 0.08-2
Distribution: unstable
Urgency: low
Maintainer: Dmitry E. Oboukhov un...@debian.org
Changed-By:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Fri, 25 May 2012 09:37:40 +0200
Source: haskell-transformers
Binary: libghc-transformers-dev libghc-transformers-prof libghc-transformers-doc
Architecture: source all amd64
Version: 0.3.0.0-1
Distribution: unstable
Urgency: low
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Fri, 25 May 2012 09:36:21 +0200
Source: haskell-xhtml
Binary: libghc-xhtml-dev libghc-xhtml-prof libghc-xhtml-doc
Architecture: source all amd64
Version: 3000.2.1-1
Distribution: unstable
Urgency: low
Maintainer: Debian Haskell Group
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Thu, 24 May 2012 13:08:11 +0200
Source: qpid-cpp
Binary: qpidd qpid-client libqmf1 libqmf-dev libqmf2-1 libqmf2-dev
libqmfconsole2 libqmfconsole2-dev libqpidmessaging2 libqpidmessaging2-dev
libsslcommon2 libsslcommon2-dev
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Wed, 23 May 2012 12:28:33 +0200
Source: dkopp
Binary: dkopp
Architecture: source amd64
Version: 6.2-1
Distribution: unstable
Urgency: low
Maintainer: Leo Iannacone l...@ubuntu.com
Changed-By: Leo Iannacone l...@ubuntu.com
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Fri, 25 May 2012 09:41:45 +0200
Source: haskell-mtl
Binary: libghc-mtl-dev libghc-mtl-prof libghc-mtl-doc
Architecture: source all amd64
Version: 2.1.1-1
Distribution: unstable
Urgency: low
Maintainer: Debian Haskell Group
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Fri, 25 May 2012 09:40:59 +0200
Source: haskell-platform
Binary: haskell-platform haskell-platform-prof haskell-platform-doc
Architecture: source all
Version: 2012.2.0.0~rc2
Distribution: unstable
Urgency: low
Maintainer: Debian
1 - 100 of 198 matches
Mail list logo
