Re: Packaging on GitHub ?

[olivier sallou]

Le 27 mai 2012 03:12, "Jon Bernard"  a écrit :
>
> * Charles Plessy  wrote:
> > Hello everybody,
> >
> > for one of the packages maintained by the pkg-eucalyptus team
(euca2ools), the
> > upstream source moved to GitHub, and we would like to try to maintain
the
> > Debian package there as well.
> >
> > I see that there is already a Debian account on GitHub
> > (https://github.com/debian), currently empty.  Does it belong to a
Developer ?
> > Would it be availble to maintain the euca2ools package in ?
> >
> > I never tried GitHub before.  I know it is not Free.  The point
maintaining a
> > Debian package on GitHub would be to easily make pull requests to
Upstream.  Is
> > it something that would be doable from external repositories, for
instance
> > making a pull request to GitHub from Alioth ?  (I mean, the Pull Request
> > function of GitHub, not sending an email Upstream saying in plain
English that
> > they can pull from Alioth).
>
> I believe a Github pull-request must reference a commit within Github
itself.
> You could still file an issue linking to an external repository, but I
suspect
> they're encouraging you to use Github for packaging so they can leverage
all of
> the utilities that Github provides. You could always use Alioth as the
primary
> repository and keep an updated mirror on Github just for this sort of
thing.
>
Github tools work with local repo only. Keeping an updated mirror is not a
good method for me, it is a painful task and you are never sure of the
status

By the way, you can t use Debian repo to put several repo. a github repo
refers to a single git repo.

For info, there is a very nice github like free tool named gitlab , but it
I a software, not a service.
Olivier
> --
> Jon
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
listmas...@lists.debian.org
> Archive: http://lists.debian.org/20120527011140.GB32538@quintessa
>
 Le 27 mai 2012 03:12, "Jon Bernard"  a écrit :

Re: MIA check: Patrick Winnertz

[Bart Martens]

On Sun, May 27, 2012 at 02:25:20AM +0100, Miah Gregory wrote:
> Hi folks,
> 
> Has anyone seen/heard from Patrick recently? He has a number of packages
> which are somewhat out of date (lmms specifically interests me), which
> would be good to get sorted prior to the freeze.

Here's an upload on 16 November 2011:
http://packages.qa.debian.org/l/lustre/news/2016T130707Z.html

Regards,

Bart Martens


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120527044513.gb10...@master.debian.org

Re: Packaging on GitHub ?

[Yaroslav Halchenko]

On Sat, 26 May 2012, Jon Bernard wrote:
> > I see that there is already a Debian account on GitHub
> > (https://github.com/debian), currently empty.  Does it belong to a 
> > Developer ?
> > Would it be availble to maintain the euca2ools package in ? 

if there is no reply here it might be worth contacting github support
trying to figure it out or to reclaim it.  Usually they are quite open
and supportive (although I never had to deal with reclaiming)

> the utilities that Github provides. You could always use Alioth as the primary
> repository and keep an updated mirror on Github just for this sort of thing.

yeap -- FWIW I have been using such setup for many projects.  With a
help of few git aliases pushing to multiple repositories becomes very
easy to keep them in sync.

little hint -- for your clone on github in Admin page you can change the
default branch to point to 'debian' or whatever it would be if not
master where packaging would reside.

-- 
Yaroslav O. Halchenko
Postdoctoral Fellow,   Department of Psychological and Brain Sciences
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120527030634.gd11...@onerussian.com

Re: Moving /tmp to tmpfs makes it useless

[Joey Hess]

Adam Borowski wrote:
> I think that box had jfs, but other filesystems are no different: for
> example, ext* will fsync() during a rename() call behind your back even if
> you don't request it, forcing every file to hit the disk platters even
> though they'll immediately get changed again.  For files outside /tmp/ that
> makes sense: the system has to guarantee you won't lose data during a crash.
> But why should I care about not losing temp files?

In practice, it's rare for anything that uses libc's interfaces to /tmp
(or TMPDIR directly) to rename files in /tmp. Files in /tmp are opened,
unlinked, written, read, and closed. Renaming files in /tmp is thus not
likely to be a major source of system load. My charge of premature
optimisation stands.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Moving /tmp to tmpfs is fine

[Serge]

2012/5/25 Iustin Pop wrote:

> And no, "I really can't think of any popular application" is not a valid
> discussion point.

But there're already popular applications and usecases that break because
of that. It can render the system unstable because of heavy swap usage.
So there must be some strong point to still use it despite those problems.
There must be some very popular application, that do not break because
of that feature and even becomes better.

Otherwise, if this feature causes problems to some applications and no
benefits to others, what's the point in using it?

> This is plain wrong. NO benefits for tmpfs? "just works somehow"?

Ok, I must be missing some obvious benefit. Please, help me and name it.
But real one not theoretical. Some real (and popular, since we're talking
about defaults) application that becomes faster (or better in any other
way) because of /tmp being on tmpfs. All the tests showed tmpfs being no
better than ext3 so far.

> you only look at _your_ use case and dismiss all others, or that you
> don't understand the different behaviours of fsync() (with enough memory,
> that is) on tmpfs, HDDs and SSDs.

I don't dismiss them. But we talk about *defaults*. And I don't know
any real applications, heavily fsync()ing files in /tmp, that people are
expected to use by default. Can you name some?

> iustin, happily using /tmp on tmpfs since many, many years ago

Heh... A lot of people use it. I guess most of them have seen "/tmp", then
they were seing "tmpfs", and decided that "tmpfs is the fs for /tmp", it
seemed natural to them. They never really thought, whether it's good or
bad idea, or that there may be some better ideas. It was just natural to
use it.

And when I say, "hey, that's a bad idea", I hurt them (I'm sorry for that).
They start arguing that "it's not that bad as you say, look, not everything
is broken, many programs still work". They can't say why it's better than
using disk because they never though about that. It was just "natural"...

That's just my guess, of course.

-- 
  Serge


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caoveneom+nfemjxs61xqekbbt0ui5_epw0yl9t930ratvhe...@mail.gmail.com

Re: Moving /tmp to tmpfs makes it useless

[Serge]

2012/5/27 Adam Borowski wrote:

> I think that box had jfs, but other filesystems are no different: for
> example, ext* will fsync() during a rename() call behind your back even
> if you don't request it, forcing every file to hit the disk

This is easy to check:
  $ cd /path/to/tmpfs
  $ touch 1
  $ time for i in `seq 1`; do mv $i $((i+1)); done
  real0m9.760s
  user0m2.727s
  sys 0m6.773s
  $ cd /path/to/ext3
  $ touch 1
  $ time for i in `seq 1`; do mv $i $((i+1)); done
  real0m9.624s
  user0m2.679s
  sys 0m6.877s
I don't see major difference. Both tests gave 9.5-9.8s range between runs.
Maybe your filesystem is to blame?

> So don't tell me real filesystems are "almost as good" as tmpfs

Tests tell you that. :)

Actually real filesystem is not just "as good", it's better, because it
does not eat memory and slow down other running programs when
writing to disk.

-- 
  Serge


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caovenermwbuku08ahyo8f5-ejahzjct6_gy+snyjdqkq7w-...@mail.gmail.com

Re: Packages still in experimental but removed in unstable

[Stefan Lippers-Hollmann]

Hi

On Sunday 27 May 2012, Luca Falavigna wrote:
> Hi,
> 
> I generated a list of source packages which have been removed from
> unstable, but are still kept into experimental for some reason. I
> excluded those which seem maintained, and generated a dd-list of the
> remaining ones. I will file removal bugs for them within the end of
> June if nobody claims they should be kept around.
[…]
> Simon Richter 
>misdn-kernel

This package is obsolete, mISDN has been merged into the mainline 
kernel in 2.6.27 (and it's close to imposssible that this ancient 
version still compiles against a kernel from squeeze or wheezy).

>misdn-user
[…]

To work with the final in-kernel mISDN subsystem, an update to 
mISDNuser >= 2.x would be required[1], as the userspace API of the 
mISDN kernel subsystem has changed to a socket based one before it 
could get merged mainline. While it might make sense to update/ 
overhaul this package for unstable, the current version in experimental
definately can't work with anything newer than lenny.

Disclaimer: I can't speak for the maintainer and haven't actually 
tested mISDN in a long time.

Regards
Stefan Lippers-Hollmann

[1] http://www.misdn.org/index.php/MISDN_Release_Notes


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201205270419.02267.s@gmx.de

MIA check: Patrick Winnertz

[Miah Gregory]

Hi folks,

Has anyone seen/heard from Patrick recently? He has a number of packages
which are somewhat out of date (lmms specifically interests me), which
would be good to get sorted prior to the freeze.

-- 
Regards,

Miah




-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1338081920.5565.7.ca...@thinkpad3.darksilence.net

Re: Packaging on GitHub ?

[Jon Bernard]

* Charles Plessy  wrote:
> Hello everybody,
> 
> for one of the packages maintained by the pkg-eucalyptus team (euca2ools), the
> upstream source moved to GitHub, and we would like to try to maintain the
> Debian package there as well.
> 
> I see that there is already a Debian account on GitHub
> (https://github.com/debian), currently empty.  Does it belong to a Developer ?
> Would it be availble to maintain the euca2ools package in ? 
> 
> I never tried GitHub before.  I know it is not Free.  The point maintaining a
> Debian package on GitHub would be to easily make pull requests to Upstream.  
> Is
> it something that would be doable from external repositories, for instance
> making a pull request to GitHub from Alioth ?  (I mean, the Pull Request
> function of GitHub, not sending an email Upstream saying in plain English that
> they can pull from Alioth).

I believe a Github pull-request must reference a commit within Github itself.
You could still file an issue linking to an external repository, but I suspect
they're encouraging you to use Github for packaging so they can leverage all of
the utilities that Github provides. You could always use Alioth as the primary
repository and keep an updated mirror on Github just for this sort of thing.

-- 
Jon


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120527011140.GB32538@quintessa

Packaging on GitHub ?

[Charles Plessy]

Hello everybody,

for one of the packages maintained by the pkg-eucalyptus team (euca2ools), the
upstream source moved to GitHub, and we would like to try to maintain the
Debian package there as well.

I see that there is already a Debian account on GitHub
(https://github.com/debian), currently empty.  Does it belong to a Developer ?
Would it be availble to maintain the euca2ools package in ? 

I never tried GitHub before.  I know it is not Free.  The point maintaining a
Debian package on GitHub would be to easily make pull requests to Upstream.  Is
it something that would be doable from external repositories, for instance
making a pull request to GitHub from Alioth ?  (I mean, the Pull Request
function of GitHub, not sending an email Upstream saying in plain English that
they can pull from Alioth).

Have a nice Sunday,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120527004639.ga9...@falafel.plessy.net

Bug#674724: ITP: tunesviewer -- program to access iTunesU media and podcasts

[Rogério Brito]

Package: wnpp
Severity: wishlist
Owner: "Rogério Brito" 

* Package name: tunesviewer
  Version : 1.4.99.0
  Upstream Author : Luke Bryan ,
Rogério Theodoro de Brito 
* URL : https://sf.net/projects/tunesviewer
* License : GPL-2+
  Programming Lang: Python, JavaScript
  Description : program to access iTunesU media and podcasts

TunesViewer is a small, easy-to-use program to access iTunesU media and
podcasts from Linux.  TunesViewer lets you:
.
 * Search, browse, and download videos, audio lectures, and ebooks.
 * Go directly from the "loading iTunes-U..." page to viewing podcast with
   TunesViewer.
 * Reveal the standard RSS-podcast-feed of an iTunes podcast, for use in
   podcast software.
 * Log in to download students-and-staff-only media.

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://rb.doesntexist.org/blog : Projects : https://github.com/rbrito/
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120527003459.ga15...@ime.usp.br

Re: Debian documentation permalinks

[Jonathan Callen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 05/26/2012 03:09 PM, Philip Ashmore wrote:
> I'm happy and sad with this. Happy that Wikipedia provides
> permalink support. Sad that it didn't document it in its article
> about permalinks.
> 
> Is there documentation on this feature somewhere?
> 

Generally, a Wikipedia article on a particular feature of web sites
tries to avoid referencing Wikipedia itself as an example.
Wikipedia's documentation on MediaWiki permalinks is linked at the
very top of that article ("For permalinks in Wikipedia, see [Help:Page
history#Linking to a specific version of a page][1]") however, and
there is a "Permanent Link" link in the toolbox in the far left column
of every page, although you need to expand the toolbox to see it.
There are some caveats regarding the implementation of permalinks, so
you may wish to read [1] first.

[1]
http://en.wikipedia.org/wiki/Help:Page_history#Linking_to_a_specific_version_of_a_page
- -- 
Jonathan Callen
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCgAGBQJPwXOoAAoJELHSF2kinlg4kpYP/0Ohq0yy4Y20TRlBYNU9Hnbq
rOTm1wvfXGf3mdHbtkdQeyWoBL+35WM/0pMc6dcn2RsgTy11iELwmDk7XKp5KC69
45Gq6SnU17N3x5M889BxMOuOkknBs3Ir5/94iYi2PR1fvM75aHHNyT26EtJ6PBmt
6TuSSBmnwqeoiIdvcrGX3ao0VIIpAN7dEnzgwDbX4agdCIFBeog/XZDb82dUMK1c
plHSSdhJ9tm80YJU0TPjI/lc0/M1egTPjSEN0IGfAGXFY+99fzq0u6WinkjLXeQS
J0njHqQaGidAGZ3rM3M/ekpmDUOffd0i8H2EVEGqDza0t7SXrrRIXWR0VN1A9jWf
Hp5OhtujOckSIkwup5IZfqhiIp1qdFSqWeY9gm3X6DTaxDQHo+cYYDhYzSngdqbI
LzyrTMXbbAgMeizT0zt+oMTgime8SsKrUxx0deiqc58I6rUAiYfxX3pAJ37REpf1
U9rbE80RtlOSVCLRhOwql8iiFEqp9dKakg1FZFVV5HPVEkPbVOln3zdeuIcgOMyZ
/OVt7vpnzdUsuRtz9cvO4jY70LuIHPrtsJTGu8nvRgraDR6787XvkstFa+Cp4pcG
vGA2T/2S3r3V4qzSEL954n8NDFuXl85+TLn4PKkO5Sfil7cD9cJFbjx+74hHuO61
Oar1yWgh5ElbeNU7Ietl
=TuIT
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fc173b1.8070...@gmail.com

Re: Moving /tmp to tmpfs makes it useless

[Adam Borowski]

On Sat, May 26, 2012 at 04:27:01PM -0400, Joey Hess wrote:
> Josselin Mouette wrote:
> > Oh stop, there is a difference: in a tmpfs the system doesn’t need to
> > commit the data on disk, and therefore can write it to disk whenever it
> > likes, especially when the disk is not too used. There is no need to
> > keep a journal nor to access the disk several times to update metadata.
> > Only unused data is written to disk. Which means a *huge* performance
> > improvement. Do the measurements yourself, it works with basically
> > anything that makes heavy use of /tmp.
> 
> I'm looking foward to a report from systems instrumented to track all
> accesses to /tmp, that analizes the frequency of accesses and gives
> numbers about just how huge this performance improvement is.
> 
> Until we have such a report, why are we engaging in premature optimisation?

Recently, I had a pile of over a hundred snapshots of a project in tarballs
and zips, all with random extra junk, never having the same capitalization
of file names, etc.  I wanted to put all non-junk data into git.  Cue ad-hoc
scripts to unzip, fix newlines, check encoding and convert to UTF-8 if
needed, etc, etc.  Lots of churn but at any given time the working set was a
small fraction of memory.

Every iteration took 60ish seconds of I/O -- damn frustrating when
interspersed with manual work.  I then tried it on /tmp/, and suddenly
everything went down to well below a second.

So don't tell me real filesystems are "almost as good" as tmpfs when memory
is not tight so there's no need for writeouts.  And on modern systems,
memory is hardly ever tight.

I think that box had jfs, but other filesystems are no different: for
example, ext* will fsync() during a rename() call behind your back even if
you don't request it, forcing every file to hit the disk platters even
though they'll immediately get changed again.  For files outside /tmp/ that
makes sense: the system has to guarantee you won't lose data during a crash.
But why should I care about not losing temp files?


-- 
I was born an ugly, dumb and work-loving child, then an evil midwife
replaced me in the crib.


signature.asc
Description: Digital signature

Re: /tmp on multi-FS set-ups, or: block users from using /tmp?

[Adam Borowski]

On Sat, May 26, 2012 at 08:23:31PM +, brian m. carlson wrote:
> I work for a company that develops software for shared-hosting
> providers.  I can guarantee you that multi-user is far from a corner
> case.  We employ 135 people and are growing, as is the shared-hosting
> market.
> 
> For my personal purposes, tmpfs on /tmp is fine.  For shared-hosting
> purposes, tmpfs on /tmp is a DoS waiting to happen.  Many web hosting
> companies overprovision their servers (the business is cutthroat) and
> memory is very tight.

Ie, you need swap anyway.

tmpfs for /tmp/ is good no matter if you have enough memory (there won't be
any I/O at all), or if memory is tight (it removes the need for journaling
and barriers).

Real problems in this thread are default settings for allotted space,
complaints about tight memory are red herring.


-- 
“This is gonna be as easy as cheating on an ethics exam!”
-Cerise Brightmoon


signature.asc
Description: Digital signature

Re: /tmp on multi-FS set-ups, or: block users from using /tmp?

[Salvo Tomaselli]

> Again, I thought that:
> There is a single base directory relative to which user-specific
> non-essential (cached) data should be written. This directory is defined
> by the environment variable $XDG_CACHE_HOME.
> 
> There is a single base directory relative to which user-specific runtime
> files and other file objects should be placed. This directory is defined
> by the environment variable $XDG_RUNTIME_DIR.
> 
> 
> (http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html)
> 
> I think these two definitions cover what most "users" (i.e. *human*
> users) would use /tmp for.

$ echo $XDG_CACHE_DIR |wc
  1   0   1

Yes they do cover many uses but several programs need to be fixed, and to 
include code to empty the directory afterwards.

If you don't plan to fix them all, and until those directories are actually 
used, you don't have a good point.
Besides office systems usually have a NFS /home and a local /tmp which means 
that writing cache on the home is bad. But that's quite a specific situation 
and we shouldn't bother too much for it.


Bye
-- 
Salvo Tomaselli


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201205270055.44745.tipos...@tiscali.it

Re: Moving /tmp to tmpfs makes it useless

[Ben Hutchings]

On Sat, 2012-05-26 at 16:29 -0400, Joey Hess wrote:
> Ted Ts'o wrote:
> > The main advantage of tmpfs is that it gets wiped on reboot, and so it
> > prevents people and applications from thinking that they can keep
> > stuff in /tmp forever.  It's also faster because a file system has to
> > do extra work to make sure the files are preserved after a reboot.
> 
> This is no new advantage; Debian has deleted the contents of /tmp
> on boot by default for as long as I can remember.

A normal filesystem implementation will try to preserve files in a way
that they survive a reboot, ignorant of the fact that they're destined
to be removed.  It have in the past been annoyed to have to wait for
/tmp to be fsck'd just before it's wiped clean.

Ben.

-- 
Ben Hutchings
You can't have everything.  Where would you put it?


signature.asc
Description: This is a digitally signed message part

Re: Moving /tmp to tmpfs makes it useless

[Carlos Alberto Lopez Perez]

On 25/05/12 12:14, Henrique de Moraes Holschuh wrote:
> 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.
> 
This is a corner case.

Defaults should be sane for most of the cases, and not for corner cases.
Also defaults should prioritize stability (and non-breakage) over
performance.

With "tmpfs on /tmp" you are breaking many applications that assume that
they have enough space to write on /tmp like the flash player ( see
Debian bug #666096 ) or cdrecord software ( see #665634 ).

>> the point. Maybe we should add a /small-files-on-tmpfs (choose
>> a better name, of course...) folder so that apps know what to do,
>> that'd be a lot more graceful than just switching to whole /tmp
>> to tmpfs without any app knowing about it.
> 
> Nice idea, but it would be worthless.
> 
> In fact it is the other way.  We have /var/tmp for the large file since
> about forever, and important platforms that have /tmp in memory since the
> early 2000's (Solaris)
> 

They did it, because their native file system (UFS) was very slow.
Even linux ext2 was faster than Solaris tmpfs!! [1]

> And that STILL wasn't enough for people to not screw it up and dump large
> files in /tmp.
> 

The FHS [2] does not define *nothing* about the size of /tmp or
/var/tmp. It *only* says that programs using files under /tmp must not
assume that this files are preserved between invocations of the program


So please, *stop* saying that /tmp should be only for small files
because this is simply *not* *true*. It is *not* defined on any standard
that files on /tmp should be small. Period.


Regards!


[1]
http://marc.info/?l=linux-kernel&m=90222140834090&w=2
http://marc.info/?t=9022392841
[2]
http://www.pathname.com/fhs/pub/fhs-2.3.html#TMPTEMPORARYFILES
-- 
~~~
Carlos Alberto Lopez Perez   http://neutrino.es
Igalia - Free Software Engineeringhttp://www.igalia.com
~~~



signature.asc
Description: OpenPGP digital signature

Re: Moving /tmp to tmpfs makes it useless

[Joey Hess]

Roger Leigh wrote:
> I did want to have this for wheezy (#633299).  But I lacked the time
> and familiarity with the d-i code, and the d-i developers also have
> higher priorities.

Personally, this d-i developer has as one priority that the system d-i
installs be broadly useful. d-i has at times needed to frob files in
/etc to achieve this goal, and I have not ruled out the possibility that
it might need to do so again...

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Moving /tmp to tmpfs makes it useless

[Russ Allbery]

Joey Hess  writes:
> Henrique de Moraes Holschuh wrote:

>> In fact it is the other way.  We have /var/tmp for the large file since
>> about forever, and important platforms that have /tmp in memory since
>> the early 2000's (Solaris)

>> And that STILL wasn't enough for people to not screw it up and dump
>> large files in /tmp.

> No, that is not the difference between /var/tmp and /tmp. Users of /tmp
> are not "screwing up", they are storing files that are intended only to
> persist while the computer is up, to the correct place.

> If programs that write large files to /tmp are changed to usr /var/tmp,
> then over time a system will accumulate orphaned large tmp files in
> /var/tmp. Nothing will come along and clean them up.

I started as one of the people in the "Solaris has been doing this for
years, what's the problem?" camp, but I find the argument presented by
Joey and others to be persuasive.  If there are a wide variety of programs
that expect to be able to write files of arbitrary size to /tmp (and I
think it's fairly clear from the bug reports that there are, including
video streaming, sort, temporary unpacks of archives by file managers, and
even Debian's own tools like debdelta), tmpfs is (in most installations)
going to be much smaller than the typical available space on a physical
disk.

The root problem here is that we have multiple parameters that we want to
set on temporary storage:

1. Space for dumping arbitrary files without assuming anything about the
   structure of the user's home directory.

2. Fast space for small temporary files that will be removed when the
   system is rebooted.

3. Space for large temporary files that will be removed when the system is
   rebooted.

Both /tmp and /var/tmp satisfy 1, but /var/tmp does not satisfy either 2
or 3.  Previously, /tmp satisfied 3 but not 2.  Now that it's switched to
tmpfs, it satisfies 2 but not 3.

In an ideal world, in which we could throw out all of UNIX history and
make up our own rules, 1 (alone) would be /var/tmp, 2 would be some new
path (/run/tmp or something), and 3 would be /tmp.  But we don't live in
the world where it's likely we can convince everything to move to some new
/run/tmp location or the like.

Given that, we're not going to be able to satisfy 2 and 3 at the same
time.  The advantage of 2 over 3 is speed while the advantage of 3 over 2
is functionality, and as a general rule of thumb functionality should be
preferred over speed.  The argument before was basically that the
functionality improvement of 3 was a corner case, but I'm not sure from
this thread that we can support that conclusion.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ehq67kel@windlord.stanford.edu

Re: Moving /tmp to tmpfs makes it useless

[Joey Hess]

Ted Ts'o wrote:
> The main advantage of tmpfs is that it gets wiped on reboot, and so it
> prevents people and applications from thinking that they can keep
> stuff in /tmp forever.  It's also faster because a file system has to
> do extra work to make sure the files are preserved after a reboot.

This is no new advantage; Debian has deleted the contents of /tmp
on boot by default for as long as I can remember.

-- 
see shy jo, astouded at the amount of misinformation in this thread


signature.asc
Description: Digital signature

Re: Moving /tmp to tmpfs makes it useless

[Joey Hess]

Josselin Mouette wrote:
> Oh stop, there is a difference: in a tmpfs the system doesn’t need to
> commit the data on disk, and therefore can write it to disk whenever it
> likes, especially when the disk is not too used. There is no need to
> keep a journal nor to access the disk several times to update metadata.
> Only unused data is written to disk. Which means a *huge* performance
> improvement. Do the measurements yourself, it works with basically
> anything that makes heavy use of /tmp.

I'm looking foward to a report from systems instrumented to track all
accesses to /tmp, that analizes the frequency of accesses and gives
numbers about just how huge this performance improvement is.

Until we have such a report, why are we engaging in premature optimisation?

-- 
see shy jo


signature.asc
Description: Digital signature

Re: /tmp on multi-FS set-ups, or: block users from using /tmp?

[brian m. carlson]

On Sat, May 26, 2012 at 02:32:15PM -0400, Ted Ts'o wrote:
> These days I'd argue that multi-user is such a corner case that it's
> not worth optimizing for it as far as defaults are concerned.  If
> you're trying to run a secure multi-user system, you need to be an
> expert system administrator, keep up with all security patches, and
> even then, good luck to you.  (The reality is that these days, no
> matter what OS you're talking about, shell == root.  And that's
> probably even true on the most unusably locked down SELinux system.)

I work for a company that develops software for shared-hosting
providers.  I can guarantee you that multi-user is far from a corner
case.  We employ 135 people and are growing, as is the shared-hosting
market.

For my personal purposes, tmpfs on /tmp is fine.  For shared-hosting
purposes, tmpfs on /tmp is a DoS waiting to happen.  Many web hosting
companies overprovision their servers (the business is cutthroat) and
memory is very tight.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Moving /tmp to tmpfs makes it useless

[Joey Hess]

Henrique de Moraes Holschuh wrote:
> In fact it is the other way.  We have /var/tmp for the large file since
> about forever, and important platforms that have /tmp in memory since the
> early 2000's (Solaris)
> 
> And that STILL wasn't enough for people to not screw it up and dump large
> files in /tmp.

No, that is not the difference between /var/tmp and /tmp. Users of /tmp
are not "screwing up", they are storing files that are intended only
to persist while the computer is up, to the correct place.

If programs that write large files to /tmp are changed to usr /var/tmp,
then over time a system will accumulate orphaned large tmp files in
/var/tmp. Nothing will come along and clean them up.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Moving /tmp to tmpfs makes it useful

[Joey Hess]

Ted Ts'o wrote:
> If you're worried about installations which don't have much memory
> (i.e., the 512mb netbook), then swap is absolutely mandatory, I would
> think!

Not really. I have no legitimate programs that use more than 50% of my 1 gb. 
I have an SSD. So why enable swap? If chromium goes crazy, the OOM killer
does what I want it to do.

> And if you consider how much memory most desktop/laptops have, and how
> often people **really** are downloading multi-gigabyte files to /tmp
> (note that browsers tend to default downloads to ~/Downloads), I
> really think the people who are agitating against tmpfs are really
> making a much more theoretical argument than one that seems likely to
> be hit by an unsophisticated user --- and a sophistcated user can
> easily decide whether to use /tmp on disk or not.

I read the debian-user list and have forwarded a half-dozen cases of
users experiencing problems with tmpfs /tmp to the BTS.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: /tmp on multi-FS set-ups, or: block users from using /tmp?

[Serge]

2012/5/26 Andrei POPESCU wrote:

> Maybe trying to kill two birds with one stone, but what if the display
> managers would set TMPDIR to ~/tmp/ (or ~/.cache/tmp or whatever)?

What's the point of dropping /tmp and then reinventing it in another
place on disk? Everyone could just continue using /tmp on disk then...

If the point is to have /home and /tmp on the same partiton then:
# install  -d  -m  1777  -o  root  -g  root  /home/tmp
# mount  --bind  /tmp  /home/tmp
[edit /etc/fstab to have the mount permanent]
That gives /tmp on a /home partition without memory/swap headache.
As a bonus it will clean on boot automatically.

-- 
  Serge


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caoveneqonrqvrzcwwrnojaefhvx2ah+_ythxj46x0wagyas...@mail.gmail.com

Re: Moving /tmp to tmpfs is fine

[Salvo Tomaselli]

> Or, it should get clever and not unpack everything. There are plenty of
> software that are able to read into archives without extracting from
> them. 
You can't do it for a .tar.gz or a .tar.bz and they are the most common kind 
of archive.

-- 
Salvo Tomaselli


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201205262113.26922.tipos...@tiscali.it

Re: Debian documentation permalinks

[Philip Ashmore]

On 05/26/2012 06:53 AM, Jonathan Callen wrote:
> On 05/25/2012 10:03 PM, Philip Ashmore wrote:
>> 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".
>
> And here's the permalink to the above article, as it was when the
> preceding post was made:
> http://en.wikipedia.org/w/index.php?title=Permalink&oldid=483438630
> Or, if you prefer links that don't indicate where they're really going:
> http://en.wikipedia.org/w/index.php?oldid=483438630

I'm happy and sad with this.
Happy that Wikipedia provides permalink support.
Sad that it didn't document it in its article about permalinks.

Is there documentation on this feature somewhere?

Permalinks, along with the fact that MediaWiki is free GPLv2, makes a
compelling argument for moving Debian documentation to MediaWiki.

Regards,
Philip Ashmore


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fc12a6c.1010...@philipashmore.com

Re: Moving /tmp to tmpfs makes it useful

[Mike Hommey]

On Sat, May 26, 2012 at 08:20:46PM +0200, Carlos Alberto Lopez Perez wrote:
> On 26/05/12 19:43, Russ Allbery wrote:
> > Carlos Alberto Lopez Perez  writes:
> >> On 26/05/12 19:13, Russ Allbery wrote:
> > 
> >>> I find some of the assertions in this thread confusing.  I've been
> >>> using tmpfs /tmp on my laptop for quite some time and have watched
> >>> hour-long movies via the Adobe Flash player and have never noticed any
> >>> unexpected consumption of space in /tmp.
> > 
> >>> Are you sure that video streaming via Adobe's Flash player works the
> >>> way that you seem to think it works?
> > 
> >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666096
> > 
> > That bug contains little actual information, not even what software was
> > being used.
> > 
> 
> Ok... so you want a prove?
> 
> * Open with iceweasel http://vimeo.com/13726978
> * Ensure that is playing with flashplayer (right click on the movie
> should show the typical dialog that includes "about flashplayer"
> * Now launch:
>   watch df -h /tmp/
> * And see how the space used grows.
> 
> *Important*: use "df -h /tmp" NOT "du -hs /tmp", since the flash player
> deletes the file entry from /tmp as soon as it gets the inode allocated.
> I believe this a measure to "prevent" piracy (people ripping the video
> from /tmp)

I hope it isn't, because it's poor "security". It's easy to read the
file from /proc/$pid/fd/$num

Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120526185519.ga28...@glandium.org

Re: Moving /tmp to tmpfs is fine

[Mike Hommey]

On Sat, May 26, 2012 at 06:59:35PM +0100, Wookey wrote:
> I hesitate to prolong this thread further, but I do have a couple of
> data points. (and couldn't let Neil's nonsense go).
> 
> +++ Neil Williams [2012-05-25 16:15 +0100]:
> > > So instead of fixing the defaults you suggest everybody to drop the
> > > programs they use (mc, firefox, mysql)? ;)
> > 
> > On machines which don't have the resources for those programs, yes.
> > There are alternatives out there - change to a less hungry program or
> > expand the hardware.
> 
> The idea that there are machines without the resources for mc is
> silly. It's a very low-resource console-based program.
> 
> But there is this issue of the way its vfs does temporay unpacking in
> /tmp. That makes sense in the 'this is temporary, it should go away on
> reboot' sense, but some big files will use up a lot of ram when /tmp
> is tmpfs. 
> 
> I don't know what the right thing to do about this is, but the 'set
> TMPDIR' sugestion is useless IMHO. When I start mc I have no idea what
> things will be unpacked under the VFS over the next days/weeks. I
> don't want _everything_ to go in /var/tmp and not get cleaned up
> automatically (is there cron job that does this for old files?)
> 
> Perhaps mc should get clever and change TMPDIR itself on the fly for
> large files, but I don't know how practical that is. 

Or, it should get clever and not unpack everything. There are plenty of
software that are able to read into archives without extracting from
them. There are even fuse filesystems to do that if it doesn't want to
do it itself. Using a temporary directory, be it on disk or in RAM, is
*always* going to be a limitation. As a matter of fact, i remember some
virtualization solution (vserver or lxc, i think) that gave me a 16MB /tmp
by default. It doesn't matter if it's on disk or in RAM at this point.
If mc is going to try to unpack a kernel archive in there, it's going to
blatantly fail. Yet, there's no excuse for it to not do better.

Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120526185205.ga24...@glandium.org

Re: /tmp on multi-FS set-ups, or: block users from using /tmp?

[Jean-Christophe Dubacq]

On 26/05/2012 20:32, Ted Ts'o wrote:
> On Sat, May 26, 2012 at 09:29:30PM +0700, Ivan Shmakov wrote:
>>  … But that makes me recall a solution to both the /tmp and quota
>>  issues I've seen somewhere: use ~/tmp/ instead of /tmp.  This
>>  way, user's temporary files will be subject to exactly the same
>>  limits as all the other his or her files.
>>
>>  (Still, we may need to identify the software that ignores TMPDIR
>>  and tries to write to /tmp unconditionally.)
>>
>>  > (Snark aside, does tmpfs support quotas yet/will it ever?)
> 
> These days I'd argue that multi-user is such a corner case that it's
> not worth optimizing for it as far as defaults are concerned.  If
> you're trying to run a secure multi-user system, you need to be an
> expert system administrator, keep up with all security patches, and
> even then, good luck to you.  (The reality is that these days, no
> matter what OS you're talking about, shell == root.  And that's
> probably even true on the most unusably locked down SELinux system.)
> 
> What I'd do in that situation is to use per-user /tmp directories,
> where each user would get its own mount namespace, and so each user
> would have its own /tmp --- either a bind-mounted $(HOME)/tmp to /tmp
> if you want to enforce quotas that way, or a separate tmpfs for each
> user --- and then you can specify the size of the per-user tmpfs
> mounted on each user's version of /tmp.
> 
> Cheers,

Again, I thought that:
There is a single base directory relative to which user-specific
non-essential (cached) data should be written. This directory is defined
by the environment variable $XDG_CACHE_HOME.

There is a single base directory relative to which user-specific runtime
files and other file objects should be placed. This directory is defined
by the environment variable $XDG_RUNTIME_DIR.


(http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html)

I think these two definitions cover what most "users" (i.e. *human*
users) would use /tmp for.

-- 
Jean-Christophe Dubacq


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fc12517.3060...@free.fr

Re: Moving /tmp to tmpfs makes it useful

[François Bottin]

On 05/26/2012 07:08 PM, Thomas Goirand wrote:

On 05/26/2012 11:14 PM, François Bottin wrote:

On 05/26/2012 04:47 PM, Thomas Goirand wrote:

Try playing a 2h video with flash, and see that 60 MB isn't enough...


If Adobe Flash is broken, then fix it!



I will let you ask the sources from Adobe, create an
alternative *that works*. I will also let you fix all
the other apps that we mentioned that have the same
kind of issues. But *IN THE MEAN WHILE*, until you are
done with this huge and important work, let's not
change the default to tmpfs.


My point is that I can't stand that the major point to not use tmpfs is 
caused by a closed source software. If you think it is faulty, then do 
not use it!
By the way, I can't reproduce your problem. That's probably due to the 
fact that there is no non-free software on my machines...



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fc1226a.5090...@free.fr

Re: Moving /tmp to tmpfs makes it useful

[Russ Allbery]

Carlos Alberto Lopez Perez  writes:
> On 26/05/12 19:43, Russ Allbery wrote:
>> Carlos Alberto Lopez Perez  writes:

>>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666096

>> That bug contains little actual information, not even what software was
>> being used.

> Ok... so you want a prove?

I want the bug report to actually be useful, yes.  :)  It's always good to
have a reproducible test case.

> * Open with iceweasel http://vimeo.com/13726978
> * Ensure that is playing with flashplayer (right click on the movie
> should show the typical dialog that includes "about flashplayer"
> * Now launch:
>   watch df -h /tmp/
> * And see how the space used grows.

> *Important*: use "df -h /tmp" NOT "du -hs /tmp", since the flash player
> deletes the file entry from /tmp as soon as it gets the inode allocated.
> I believe this a measure to "prevent" piracy (people ripping the video
> from /tmp)

> See:

> ls -l /proc/$(ps aux|grep libf[l]ashplayer.so|awk '{print $2}')/fd

> And see how there is an entry pointing to /tmp/FlashXX that appears
> as deleted but you can still access it. Just open /proc/pid/fd/number
> with vlc for example

Thank you!  Those instructions are very good.  I'm copying them to the bug
report so that the bug report contains clear information.

When I did this (on a laptop with 2GB of memory and 2.5GB of swap and a
405MB tmpfs /tmp), the movie exhausted all space in /tmp.  It then kept
playing without any trouble, and the system never started swapping or had
any other performance issues.  However, /tmp was completely full, and
creating any other files in /tmp resulted in errors (which I know can
cause all sorts of problems for other programs that assume they can always
create small files in /tmp).

I didn't continue to play the movie through to the end, so I don't know if
the movie playback would encounter problems at the point at which the
buffered movie exhausted /tmp or if the Flash player would have coped by
windowing the streaming.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87bolaaj12@windlord.stanford.edu

Re: /tmp on multi-FS set-ups, or: block users from using /tmp?

[Ted Ts'o]

On Sat, May 26, 2012 at 09:29:30PM +0700, Ivan Shmakov wrote:
>   … But that makes me recall a solution to both the /tmp and quota
>   issues I've seen somewhere: use ~/tmp/ instead of /tmp.  This
>   way, user's temporary files will be subject to exactly the same
>   limits as all the other his or her files.
> 
>   (Still, we may need to identify the software that ignores TMPDIR
>   and tries to write to /tmp unconditionally.)
> 
>  > (Snark aside, does tmpfs support quotas yet/will it ever?)

These days I'd argue that multi-user is such a corner case that it's
not worth optimizing for it as far as defaults are concerned.  If
you're trying to run a secure multi-user system, you need to be an
expert system administrator, keep up with all security patches, and
even then, good luck to you.  (The reality is that these days, no
matter what OS you're talking about, shell == root.  And that's
probably even true on the most unusably locked down SELinux system.)

What I'd do in that situation is to use per-user /tmp directories,
where each user would get its own mount namespace, and so each user
would have its own /tmp --- either a bind-mounted $(HOME)/tmp to /tmp
if you want to enforce quotas that way, or a separate tmpfs for each
user --- and then you can specify the size of the per-user tmpfs
mounted on each user's version of /tmp.

Cheers,

- Ted


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120526183215.ga11...@thunk.org

Re: /tmp on multi-FS set-ups, or: block users from using /tmp?

[Andrei POPESCU]

On Sb, 26 mai 12, 21:29:30, Ivan Shmakov wrote:
> 
>   … But that makes me recall a solution to both the /tmp and quota
>   issues I've seen somewhere: use ~/tmp/ instead of /tmp.  This
>   way, user's temporary files will be subject to exactly the same
>   limits as all the other his or her files.
> 
>   (Still, we may need to identify the software that ignores TMPDIR
>   and tries to write to /tmp unconditionally.)

Maybe trying to kill two birds with one stone, but what if the display 
managers would set TMPDIR to ~/tmp/ (or ~/.cache/tmp or whatever)?

Kind regards,
Andrei
-- 
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic


signature.asc
Description: Digital signature

Re: Moving /tmp to tmpfs makes it useful

[Carlos Alberto Lopez Perez]

On 26/05/12 19:43, Russ Allbery wrote:
> Carlos Alberto Lopez Perez  writes:
>> On 26/05/12 19:13, Russ Allbery wrote:
> 
>>> I find some of the assertions in this thread confusing.  I've been
>>> using tmpfs /tmp on my laptop for quite some time and have watched
>>> hour-long movies via the Adobe Flash player and have never noticed any
>>> unexpected consumption of space in /tmp.
> 
>>> Are you sure that video streaming via Adobe's Flash player works the
>>> way that you seem to think it works?
> 
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666096
> 
> That bug contains little actual information, not even what software was
> being used.
> 

Ok... so you want a prove?

* Open with iceweasel http://vimeo.com/13726978
* Ensure that is playing with flashplayer (right click on the movie
should show the typical dialog that includes "about flashplayer"
* Now launch:
  watch df -h /tmp/
* And see how the space used grows.

*Important*: use "df -h /tmp" NOT "du -hs /tmp", since the flash player
deletes the file entry from /tmp as soon as it gets the inode allocated.
I believe this a measure to "prevent" piracy (people ripping the video
from /tmp)

See:

ls -l /proc/$(ps aux|grep libf[l]ashplayer.so|awk '{print $2}')/fd

And see how there is an entry pointing to /tmp/FlashXX that appears
as deleted but you can still access it. Just open /proc/pid/fd/number
with vlc for example


Regards!


-- 
~~~
Carlos Alberto Lopez Perez   http://neutrino.es
Igalia - Free Software Engineeringhttp://www.igalia.com
~~~



signature.asc
Description: OpenPGP digital signature

Bug#674684: ITP: qpdfview -- tabbed PDF viewer

[Benjamin Eltzner]

Package: wnpp
Severity: wishlist
Owner: Benjamin Eltzner 


* Package name: qpdfview
  Version : 0.2.2
  Upstream Author : Adam Reichold 
* URL : https://launchpad.net/qpdfview
* License : GPL-3
  Programming Lang: C++
  Description : tabbed PDF viewer



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120526181423.6699.12562.reportbug@Geilomat

Bug#674680: ITP: gcin-table-dayi3 -- Dayi 3 table for gcin input method

[魏銘廷]

Package: wnpp
Severity: wishlist
Owner: "Yao Wei (魏銘廷)" 

* Package name: gcin-table-dayi3
* URL : http://hyperrate.com/dir.php?eid=67
* License : Proprietary (Not modifiable)
  Description : Dayi 3-key table for gcin input method

This is one of the Chinese input method table called Dayi.

This table is shipped with gcin source code but is dfsg-sanitized when
packaging gcin, and I am packaging this to fulfill the missing piece.

It is considered non-free because the license does not allow users to
modify the relations. But changes on the presentation of the relations
is permitted.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120526175303.9976.96206.reportbug@homura

Re: Moving /tmp to tmpfs is fine

[Wookey]

I hesitate to prolong this thread further, but I do have a couple of
data points. (and couldn't let Neil's nonsense go).

+++ Neil Williams [2012-05-25 16:15 +0100]:
> > So instead of fixing the defaults you suggest everybody to drop the
> > programs they use (mc, firefox, mysql)? ;)
> 
> On machines which don't have the resources for those programs, yes.
> There are alternatives out there - change to a less hungry program or
> expand the hardware.

The idea that there are machines without the resources for mc is
silly. It's a very low-resource console-based program.

But there is this issue of the way its vfs does temporay unpacking in
/tmp. That makes sense in the 'this is temporary, it should go away on
reboot' sense, but some big files will use up a lot of ram when /tmp
is tmpfs. 

I don't know what the right thing to do about this is, but the 'set
TMPDIR' sugestion is useless IMHO. When I start mc I have no idea what
things will be unpacked under the VFS over the next days/weeks. I
don't want _everything_ to go in /var/tmp and not get cleaned up
automatically (is there cron job that does this for old files?)

Perhaps mc should get clever and change TMPDIR itself on the fly for
large files, but I don't know how practical that is. 

I only have 2G in this machine and astonishing slowdown due to
thrashing is quite common after a few days work (generally firefoxes
fault). I do begrudge /tmp (and thus tmpfs) having more than a few MB
of ram.


hmm. I just checked some stats: 
after looking inside a 45MB .deb files in mc:
tmpfs382M  212K  382M   1% /tmp

so it's not unpacking it there any more even though
MC_TMPDIR=/tmp/mc-wookey perhaps this issue is fixed at least for this
app? 

here's a case where a lot of space gets used in there: open a .ppt
(powerpoint) file in libreoffice. The conversion involves writing a
file in /tmp/ for every page/image. To open an image-heavy
256Mb .ppt I have lying about here, generates 382MB of files in /tmp.

I tried to do this live when someone was having trouble with a
presentation - it took over 20mins to open this file due to thrashing
and I was unable to save the presenation from being something of a
disaster. /tmp being a tmpfs presumably contributed to that failure
(It just opened fine in about 2mins on the same machine with less
memory pressure). And of course I didn't set 'TMPDIR' beforehand a)
because all I did was double-click on the file in the filer, which ran
libreoffice impress and b) because I had no idea that it would general
hundreds of megs of files in /tmp. (I found out afterwards).

So I'm with serge that this can be a real-world problem. I'm
not claiming that the only solution is a real-disk /tmp, because I
agree with those who do see advantages in /tmp as tmpfs so long as
/tmp stays fairly small. 

> No problem with tmpfs being in RAM, it's all about being rational in
> the selection of packages.

'firefox' is a perfectly rational choice of package on this laptop of
2G ram. mc is a rational choice on any machine.

You can't solve the issue of 'unpacking huge tarballs/debs/whatevers'
in /tmp' by telling people to use different packages. Something else
is needed. It is possible that that something else already exists, but
I must admit to now being a little confused about what actually
happens as this thread contains conflicting info.


Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120526175935.ge11...@stoneboat.aleph1.co.uk

Re: Moving /tmp to tmpfs makes it useful

[Russ Allbery]

Carlos Alberto Lopez Perez  writes:
> On 26/05/12 19:13, Russ Allbery wrote:

>> I find some of the assertions in this thread confusing.  I've been
>> using tmpfs /tmp on my laptop for quite some time and have watched
>> hour-long movies via the Adobe Flash player and have never noticed any
>> unexpected consumption of space in /tmp.

>> Are you sure that video streaming via Adobe's Flash player works the
>> way that you seem to think it works?

> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666096

That bug contains little actual information, not even what software was
being used.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87txz2alef@windlord.stanford.edu

Re: Moving /tmp to tmpfs makes it useful

[Carlos Alberto Lopez Perez]

On 26/05/12 19:13, Russ Allbery wrote:
> Thomas Goirand  writes:
> 
>> I will let you ask the sources from Adobe, create an alternative *that
>> works*. I will also let you fix all the other apps that we mentioned
>> that have the same kind of issues. But *IN THE MEAN WHILE*, until you
>> are done with this huge and important work, let's not change the default
>> to tmpfs.
> 
> I find some of the assertions in this thread confusing.  I've been using
> tmpfs /tmp on my laptop for quite some time and have watched hour-long
> movies via the Adobe Flash player and have never noticed any unexpected
> consumption of space in /tmp.
> 
> Are you sure that video streaming via Adobe's Flash player works the way
> that you seem to think it works?
> 

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666096

-- 
~~~
Carlos Alberto Lopez Perez   http://neutrino.es
Igalia - Free Software Engineeringhttp://www.igalia.com
~~~



signature.asc
Description: OpenPGP digital signature

Re: Moving /tmp to tmpfs makes it useful

[Russ Allbery]

Thomas Goirand  writes:

> I will let you ask the sources from Adobe, create an alternative *that
> works*. I will also let you fix all the other apps that we mentioned
> that have the same kind of issues. But *IN THE MEAN WHILE*, until you
> are done with this huge and important work, let's not change the default
> to tmpfs.

I find some of the assertions in this thread confusing.  I've been using
tmpfs /tmp on my laptop for quite some time and have watched hour-long
movies via the Adobe Flash player and have never noticed any unexpected
consumption of space in /tmp.

Are you sure that video streaming via Adobe's Flash player works the way
that you seem to think it works?

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/878vgec1bv@windlord.stanford.edu

Re: Moving /tmp to tmpfs makes it useful

[Thomas Goirand]

On 05/26/2012 11:14 PM, François Bottin wrote:
> On 05/26/2012 04:47 PM, Thomas Goirand wrote:
>> Try playing a 2h video with flash, and see that 60 MB isn't enough...
>
> If Adobe Flash is broken, then fix it!
>
>
I will let you ask the sources from Adobe, create an
alternative *that works*. I will also let you fix all
the other apps that we mentioned that have the same
kind of issues. But *IN THE MEAN WHILE*, until you are
done with this huge and important work, let's not
change the default to tmpfs.

Cheers,

Thomas


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fc10e23.7050...@debian.org

Re: Moving /tmp to tmpfs makes it useless

[Carlos Alberto Lopez Perez]

On 25/05/12 12:20, Henrique de Moraes Holschuh wrote:
> 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.
> 
> What IO scheduler are you using?  It must not be CFQ.  CFQ will happly
> screw it up and stall both readers and writers when the number of dirty
> pages gets too large (which will happen if you write a gigabyte file to
> disk).
> 
> Either that, or you're cheating and your backend devices are simply "fast
> enough" that it doesn't matter (fast RAID or fast SSD).
> 
> The real question is: what does it better under CFQ+IO contention?
> Several threads doing filesystem IO, or the swapper?  Hint: it is not an
> easy question to answer because it depends on the load, type of load,
> and backend device.
> 

I think that any user that has been using Linux for a while knows how
ugly the things become when the systems starts swapping.

When the system is swapping, the whole system will become so
unresponsive while the swapping process is taking place that even your
mouse pointer will stop moving.

And this is *very* *very* annoying.

This is so annoying, that I even had configured my laptop with a very
low amount of swap, since I rather prefer the oom-killer to kill the
application that is filling the ram than rather suffer this annoying
situation.

So please, don't argue about theoretical things about virtual memory or
IO schedulers. If you are a desktop Linux user, you should know how ugly
the things get when the system is swapping.

I don't know the ultimate reason behind this ugly behaviour of Linux
when the swapping process is happening, but I know this is real and it
happens because I have experimented this situation myself more than a
couple of times.

Regards!

-- 
~~~
Carlos Alberto Lopez Perez   http://neutrino.es
Igalia - Free Software Engineeringhttp://www.igalia.com
~~~



signature.asc
Description: OpenPGP digital signature

default settings should be sane

[Carlos Alberto Lopez Perez]

I think that we should keep in mind that this is not about whether tmpfs
for /tmp is good or bad, or it gives a 3-second performance gain when
unpacking a tarball on /tmp, but about the sane default setting.


default settings are meant to be *sane* settings that prioritize
stability over performance and ensure the system works on most of the
cases, this are meant just for users that don't know anything (or care)
about this settings.


If you *know* what tmpfs is, and you think this can be good for your
system: *just* *turn* *it* *on*!!, nothing prevents you from doing it.

We are *not* talking about removing the "tmpfs for /tmp" feature from Debian

But we are talking about whether is a *sane* thing to have this setting
enabled by *default*.


Just think about an user that just has a laptop with 3GB of ram and a
300GB HDD (this is probably one of the most common user-cases nowadays)

This user knows nothing about tmpfs or partitions, or even knows how to
use a shell. Its just a normal desktop user.

He decides to give a try to Debian. He just downloads the Debian ISO
image, burns it on a DVD and installs Debian on his laptop (just
pressing next,next and next).


What happens if tmpfs on /tmp is the default?
 * The user will end with a /tmp of 615M.
 * One day the user try to copy a DVD and he is unable to do it #665634
 * One day the user try to stream a movie from youtube or vimeo and he
is unable to do it #666096
 * The user gives up with Debian and decides to go back to Windows.

What happens if tmpfs on /tmp is *not* the default?
 * The user is happy with Debian because he can get things done and
tells its friend about Debian.



Regards!

-- 
~~~
Carlos Alberto Lopez Perez   http://neutrino.es
Igalia - Free Software Engineeringhttp://www.igalia.com
~~~



signature.asc
Description: OpenPGP digital signature

Re: Moving /tmp to tmpfs makes it useful

[François Bottin]

On 05/26/2012 04:47 PM, Thomas Goirand wrote:

Try playing a 2h video with flash, and see that 60 MB isn't enough...


If Adobe Flash is broken, then fix it!


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fc0f35a.5090...@free.fr

Re: Moving /tmp to tmpfs makes it useful

[Thomas Goirand]

On 05/26/2012 01:33 PM, Clint Byrum wrote:
> On laptops and other power sensitive devices, this is pretty critical.
>
> Hypothetical: I have 2GB of RAM, and I want to watch a 50MB video file
> on a connection that will take, say, 10 minutes to cache the whole thing
> (and its a 10 minute video).
>
> With a regular filesystem hosting /tmp, Every 30 seconds I will wake up
> the hard disk, and write data to it. I doubt most spinning disks will
> go to sleep in < 30 seconds, so this is more than 10 minutes solid of
> hard disk spinning.
>
> With tmpfs, there is no memory pressure, so my disk never even spins up
> to write anything to it. If I do run into memory pressure, yes, I need
> to use swap at that point. But at that point I've got a lot more than
> just the disk draining power.
>   

Now, another hypothetical. Same machine but with 1 GB of RAM (please,
don't tell me that's unusual...), a 600 MB video file, with a video that
is 2
hours long. You have Firefox started (to watch the video), and many
pluggins and many tabs open, and it's taking 600 MB of RAM (that's
nothing really unusual, unfortunately). After a while, your HDD starts
spinning like hell, because it's swapping...

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fc0ee82.6030...@debian.org

Re: Moving /tmp to tmpfs makes it useful

[Andrey Rahmatullin]

On Sat, May 26, 2012 at 10:47:37PM +0800, Thomas Goirand 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?
> >> 
> > I'm saying that 60M is a substantial amount which still may be not called
> > "large".
> >   
> Try playing a 2h video with flash, and see that 60 MB isn't enough...
Enough for what? 60 Mb is used space, not total space. And how is that
relevant to my question anyway?

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: Moving /tmp to tmpfs makes it useful

[Thomas Goirand]

On 05/26/2012 04:40 PM, Andrey Rahmatullin wrote:
> On Sat, May 26, 2012 at 03:24:02AM +0800, Thomas Goirand 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?
>> 
> I'm saying that 60M is a substantial amount which still may be not called
> "large".
>   
Try playing a 2h video with flash, and see that 60 MB isn't enough...

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fc0ed09.3080...@debian.org

Bug#674662: general: While closing the Run Command application in kde desktop, its shadow remains after its closed.

[Shankar Menon]

Package: general
Severity: minor

Dear Maintainer,
*** Please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these lines ***



-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-2-686-pae (SMP w/4 CPU cores)
Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120526142741.3645.54362.reportbug@shankarmenon

/tmp on multi-FS set-ups, or: block users from using /tmp?

[Ivan Shmakov]

> Weldon Goree  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) and then
 >> cause a lot of breakage.

 >> However, if I put /tmp in a separate (on-disk) file system, I have
 >> to decide how much disk space to I want to permanently allocate for
 >> temporary data, in addition to the disk space permanently allocated
 >> for swapping.

[…]

Somehow, I feel that some of the participants of this discussion
are missing this very point: having /tmp on disk /doesn't/ mean
that /all/ the free disk space will be available for it at any
given time.

In particular, as Ext2+ filesystems can only be expanded, and
not reduced (without unmounting), I've got the habit of having
most of the disk space unallocated, and only expanding the
filesystems as they grow full.  (Unless, of course, considerable
amounts of cruft could be identified and removed at that time.)

 > If only ext*fs supported quotas...

… But that makes me recall a solution to both the /tmp and quota
issues I've seen somewhere: use ~/tmp/ instead of /tmp.  This
way, user's temporary files will be subject to exactly the same
limits as all the other his or her files.

(Still, we may need to identify the software that ignores TMPDIR
and tries to write to /tmp unconditionally.)

 > (Snark aside, does tmpfs support quotas yet/will it ever?)

-- 
FSF associate member #7257


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/86r4u7koc5.fsf...@gray.siamics.net

Re: Moving /tmp to tmpfs makes it useful

[Serge]

2012/5/26 Clint Byrum:

> On laptops and other power sensitive devices, this is pretty critical.

> Hypothetical: I have 2GB of RAM, and I want to watch a 50MB video file
> on a connection that will take, say, 10 minutes to cache the whole thing
> (and its a 10 minute video).

> With a regular filesystem hosting /tmp, Every 30 seconds I will wake up
> the hard disk, and write data to it.

There's a much better solution to that: /proc/sys/vm/laptop_mode and
laptop-mode-tools. If you `echo 1 > /proc/sys/vm/laptop_mode` disk
will spin up only when reading. laptop-mode-tools usually also increase
dirty_*_centisecs allowing to not write cache for minutes. So you get
all the benefits of tmpfs without its problems, like heavy swapping or
size limited by memory. :)

> I doubt most spinning disks will go to sleep in < 30 seconds

Mine spins down in 5 seconds.

-- 
  Serge


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAOVenEpJzU+kqpKy5-g7XNA8RH99jOn7aarw43Gfnf-rMO=v...@mail.gmail.com

Re: Moving /tmp to tmpfs makes it useless

[Weldon Goree]

On Fri, 25 May 2012 15:12:03 -0400
Nikolaus Rath  wrote:

> Weldon Goree  writes:
> > If only ext*fs supported quotas...
> 
> Aren't quotas only for non-root and per file system? I think we're
> already safe from non-root filling up / because of the reserved 5%.

Yes, but I was thinking of a multi-user install (that being, after all, what I 
administer for a living). I like the ability to keep ~fred and ~joe from 
locking each other out of /tmp (yes, there are ways to do that with tmpfs, but 
I have to think about them, unlike quotaing a "normal" filesystem). Then again, 
with virtualization the days of multiple-interactive-user installations may be 
coming to an end. 

Cheers,
Weldon


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120526082230.f450dc45.wel...@b.rontosaur.us

Re: Moving /tmp to tmpfs makes it useful

[Weldon Goree]

On Fri, 25 May 2012 21:56:55 -0400
Ted Ts'o  wrote:

> 
> The major difference is that tmpfs pages only get written out to swap
> when the system is under memory pressure.  In contrast, pages which
> are backed by a filesystem will start being written to disk after 30
> seconds _or_ if the system is under memory pressure.
> 

I still think the major difference is that page cache -> ext2 can be quota'd 
while tmpfs -> swap cannot (AFAIK; has that changed in the past couple of 
years?). This may be good or bad depending on your use case.

> 
> And if you consider how much memory most desktop/laptops have, and how
> often people **really** are downloading multi-gigabyte files to /tmp
> (note that browsers tend to default downloads to ~/Downloads)

Browsers write files to ~/Downloads (or ~/Desktop) *when the user selects "Save 
As"*. On Iceweasel and Chrome at least, if you click a link to a content-type 
the browser cannot natively display, it downloads it to /tmp while it's waiting 
for you to tell it what to do with it. These files can be arbitrarily large.

Weldon


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120526073853.d0868690.wel...@b.rontosaur.us

Re: Packages still in experimental but removed in unstable

[Julien Cristau]

On Sat, May 26, 2012 at 12:09:53 +0200, Luca Falavigna wrote:

> Debian X Strike Force 
>xserver-xorg-video-v4l
> 
This should be kept around, and a newer version uploaded to unstable.

Cheers,
Julien


signature.asc
Description: Digital signature

Packages still in experimental but removed in unstable

[Luca Falavigna]

Hi,

I generated a list of source packages which have been removed from
unstable, but are still kept into experimental for some reason. I
excluded those which seem maintained, and generated a dd-list of the
remaining ones. I will file removal bugs for them within the end of
June if nobody claims they should be kept around.


Albin Tonnerre 
   python-ecore (U)
   python-evas (U)

Charles Fry 
   libjgrapht-java (U)

Cyril Brulebois 
   xserver-xorg-video-v4l (U)

David Nusinow 
   xserver-xorg-video-v4l (U)

Debian freesmartphone.org Team 
   zhone

Debian Java Maintainers 
   libjgrapht-java

Debian Pkg-e Team 
   python-ecore
   python-evas

Debian X Strike Force 
   xserver-xorg-video-v4l

Guido Günther 
   iceowl

Jakub Wilk 
   re2 (U)

Jan Lübbe 
   python-ecore (U)
   python-evas (U)

Joachim Breitner 
   zhone (U)

Luca Capello 
   zhone (U)

Marc Haber 
   rageircd

Michael Koch 
   libjgrapht-java (U)

Nikita V. Youshchenko 
   zhone (U)

Simon Richter 
   misdn-kernel
   misdn-user

Stefano Rivera 
   re2

Steffen Moeller 
   libjgrapht-java (U)

Thierry Randrianiriana 
   qpopper

Timo Jyrinki 
   zhone (U)



Cheers,
Luca


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CADk7b0PW3cmRQPA5kX6K-7P6wBYoSycJ-gCbm6D+y4bir=y...@mail.gmail.com

Re: Moving /tmp to tmpfs makes it useful

[Andrey Rahmatullin]

On Sat, May 26, 2012 at 03:24:02AM +0800, Thomas Goirand 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?
I'm saying that 60M is a substantial amount which still may be not called
"large".

-- 
WBR, wRAR


signature.asc
Description: Digital signature