you want
to delete these antediluvian scripts that are still in your box? yes/no
with yes as default).
Thoughts? Am I doing too many assumptions here, and thinking
too much that everyone is facing the same situation I did?
Thomas Goirand (zigo)
--
To UNSUBSCRIBE, email to debi
On 04/11/2012 06:12 AM, Chris Knadle wrote:
> - if the init script left behind was part of a Debian package, deleting the
> init script means removing part of the configuration from the Debian pacakge,
> yet not purging the package it belongs to. This feels like something that
> would volate D
On 04/15/2012 08:25 AM, Arno Töll wrote:
> Thus, to summarize once again: I'd like to change the default directory
> served by web servers from /var/www to /var/www/html along with
> remaining web servers in Debian.
>
> Comments?
>
I support this.
Thomas
--
To UNSUBSCRIBE, email to debian-dev
On 04/15/2012 06:29 PM, Olaf van der Spek wrote:
> On Sun, Apr 15, 2012 at 2:25 AM, Arno Töll wrote:
>
>> Thus, to summarize once again: I'd like to change the default directory
>> served by web servers from /var/www to /var/www/html along with
>> remaining web servers in Debian.
>>
>> Comments
On 04/15/2012 07:21 PM, Olaf van der Spek wrote:
> That's what you get with silly partitioning. :p
I'm not sure if this is supposed to be a joke, but if it is, it's not
really funny (because it's been re-occurring so many times).
Each time there's a change proposed that will affect people with a
On 04/04/2012 05:35 PM, Didier 'OdyX' Raboud wrote:
> Hi -devel (and -lsb),
>
> I have recently uploaded lsb-base 4.1+Debian0+fancy0 to experimental. As
> this version introduces a small change that has a big visual impact on
> the Debian boot, I would like to get some feedback on it before
> uploa
On 04/17/2012 04:38 AM, Stefan Fritsch wrote:
> The new document root is supposed to be the default vhosts document
> root (there is no need to distinguish between default vhost and no
> vhost). Other vhosts can be put in other sub directories in /var/www/,
> like /var/www/www.example.com or /va
On 04/18/2012 08:27 AM, Steve McIntyre wrote:
> If a maintainer isn't (capable of) doing the necessary work on a
> package themselves, then after a while the best thing they can do is
> admit that and cede control to others. It's not an easy thing to admit
> "failure" like this, but it's better to
elp you to help (and maybe, other
DDs will join). So if you don't have much experience about bug
squashing, but want to help, you are warmly welcome as well.
See you soon, hacking at the Shanghai BSP,
Thomas Goirand (zigo)
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.o
On 04/20/2012 08:26 AM, w...@debian.org wrote:
>stellarium (#668916), orphaned 4 days ago
> Description: real-time photo-realistic sky generator
> Installations reported by Popcon: 2713
>
I just would like to highlight that Stellarium is great, and
that it'd be great if someone to
Package: wnpp
Severity: wishlist
Owner: Thomas Goirand
* Package name: pear-symfony-project-channel
Version : 1.0-1
Upstream Author : Thomas Goirand
* URL : http://pear.symfony-project.com/
* License : BSD
Programming Lang: XML
Description : PEAR
由于中国政府规定 4/28 星期六为上班日，
而4/30星期一为弹性休假日，因此我们决定将活动更改为 4/29-30。
这次活动在 peopoe spuared 的场地举办，是一个很舒适的地点。关于 people
squared 的更多资讯请至以下网站了解：http://www.people-squared.com/
感谢所有 people squared 成员的帮忙以及立即答应提供活动场地的Bob Zheng。
上海 Linux 用户组同时也是本次活动的协办单位。他们也帮忙在邮件列表上
公告本次活动消息。
因为上海的 Debian 贡献者不多，本次抓虫大会也欢迎新手参加。我(Thomas
On 04/26/2012 12:19 AM, Holger Levsen wrote:
> Hi,
>
> as a very first step I suggest to get OpenRC packaged for Debian. Until then,
> your suggestion is a bit like suggesting to use the hurd as the default
> kernel
> ;-)
>
>
> cheers,
> Holger
>
>
>
Patric is in Shanghai, like me, I ca
On 04/26/2012 08:42 PM, Roger Leigh wrote:
> If anyone fancies
> doing the packaging, I'll be happy to join in. I'll probably be able
> to provide a better overview once I know a bit more.
>
>
> Regards,
> Roger
>
As I wrote already, Patrick lives in Shanghai just like me. What happened
is tha
On 04/27/2012 10:02 AM, Russell Coker wrote:
> Every version of Debian is released with some bugs, it's the way that
> software
> development goes. If the worst bug was that plugging a USB stick at the
> wrong
> time could disrupt the boot then I think that most people would consider it
> as
Package: wnpp
Severity: wishlist
Owner: Thomas Goirand
* Package name: php-mdb2
Version : 2.5.0b3
Upstream Author : Lukas Smith
* URL : http://pear.php.net/package/MDB2
* License : BSD
Programming Lang: PHP
Description : a merge of the PEAR DB and
Package: wnpp
Severity: wishlist
Owner: Thomas Goirand
* Package name: php-mdb2-schema
Version : 0.8.5
Upstream Author : Lukas Smith
* URL : http://pear.php.net/package/MDB2_Schema
* License : BSD
Programming Lang: PHP
Description : enables users to
Package: wnpp
Severity: wishlist
Owner: Thomas Goirand
* Package name: php-xml-dtd
Version : 0.5.2
Upstream Author : Tomas V.V.Cox , Igor Feghali
* URL : http://pear.php.net/package/XML_DTD
* License : BSD
Programming Lang: PHP
Description : parsing
On 04/27/2012 06:52 PM, Philipp Kern wrote:
> On Fri, Apr 27, 2012 at 04:44:24PM +0800, Thomas Goirand wrote:
>> * Package name: php-mdb2
>> Version : 2.5.0b3
>
> php-mdb2 is already in Debian.
I know.
>> This is a request from people packaging "own
On 04/28/2012 08:29 AM, Vincent Bernat wrote:
> We are in 2012 and if a non-essential daemon blocks the boot (no working
> network), we have no way to get a getty to be run.
>
I agree with the rest of your post, but here, you are are
picturing a very badly written init script that doesn't have
a
On 04/30/2012 05:33 PM, Jon Dowland wrote:
> Oh joy-of-joys, a context free drive-by-CC to -devel, and a bug which
> indicates
> an NMU without warning, DELAYED queue use or nmudiff, for a package to which
> the maintainer is actively discussing the bug (not MIA), for a maintainer who
> is just be
On 04/30/2012 05:25 AM, Marco d'Itri wrote:
> This has been happening more and more after SuSE has become irrelevant.
>
What (or what time) are you talking about?
Has SuSE ever been relevant? :)
Thomas
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsub
On 04/30/2012 04:56 AM, Fernando Lemos wrote:
> I agree that OpenRC would be an improvement over the status
> quo, but migrating *away* from OpenRC later on would be a major pain
> as we would have to support both LSB/sysvinit scripts and OpenRC
> service descriptions for the foreseeable future.
>
On 05/02/2012 06:00 AM, Russ Allbery wrote:
> and the binary isn't invoked directly by
> users
If the binary isn't invoked directly by the users,
why do we have a problem? Why can't a patch be
introduced so that the binary doesn't live in a
user accessible path (eg: not in /usr/bin)?
Thomas
--
On 05/08/2012 12:53 AM, Gergely Nagy wrote:
> FWIW, Debian provides a couple of init systems already, and has been for
> as long as I can remember. You certainly have the option to choose.
>
Sure, we have the init replacement packages, but nobody
supports them, so you can install upstart or syst
On 05/08/2012 02:35 AM, Gergely Nagy wrote:
> Thomas Goirand writes:
>
>
>> On 05/08/2012 12:53 AM, Gergely Nagy wrote:
>>
>>> FWIW, Debian provides a couple of init systems already, and has been for
>>> as long as I can remember.
On 05/08/2012 02:40 AM, Arto Jantunen wrote:
> Sadly the point you are trying to make is painfully obvious
Well, it is now obvious to me that my previous post has been
taken as aggressive, which was really not intended. I really
was asking for more of Gergely's view.
Thomas
--
To UNSUBSCRIBE, e
On 05/03/2012 07:23 PM, Stefano Zacchiroli wrote:
> I agree that's a problem too and I share your feeling that it has been
> particularly bad in recent discussions like the init system ones.
To keep on the topic of the init systems, we had Patrick Lauer,
a Gentoo developer who I believe knows quite
On 05/10/2012 12:14 AM, Uoti Urpala wrote:
> Not having the files in /etc by default does have technical advantages.
> It's easier to see what is local non-default configuration. Original
> default file is always available in a known location (and very easy to
> revert to, temporarily for testing o
On 05/10/2012 04:52 AM, Steve McIntyre wrote:
> No, really - please *do* do this. The fact that a lot of the software
> coming out of RedHat development seems to be designed solely for their
> use, including working around the missing/broken features of RPM, is
> seriously annoying. Configuration b
On 05/10/2012 07:01 AM, Fernando Lemos wrote:
> I've seen people mention that the way udev and systemd do config files
> is really motivated by limitations in RH's packaging tools. Maybe
> that's the case, maybe not.
It's *not*! It's a difference in *policy*. :)
RH's policy is that you should neve
On 05/10/2012 07:13 AM, Uoti Urpala wrote:
> I have given technical reasons to prefer etc-overrides-lib semantics.
> You failed to address any of the reasons I or others have given. Instead
> you started by bashing Red Hat, and then gave as your only reason to
> prefer traditional conffile semantic
On 05/11/2012 12:53 AM, Uoti Urpala wrote:
> The reason why most old applications do not follow that approach (at
> least not yet) is pretty obvious: their authors never considered it.
> etc-overrides-lib semantics have only become a seriously considered
> alternative fairly recently.
>
No.
The
On 05/11/2012 04:04 AM, David Weinehall wrote:
> On Fri, May 11, 2012 at 02:44:45AM +0800, Thomas Goirand wrote:
>
>> On 05/10/2012 04:52 AM, Steve McIntyre wrote:
>>
>>> No, really - please *do* do this. The fact that a lot of the software
>>> coming o
On 05/11/2012 04:21 AM, Uoti Urpala wrote:
> Advantages I mentioned earlier would still be there:
> It's easier to see what is local non-default configuration. Original
> default file is always available in a known location (and very easy to
> revert to, temporarily for testing or permanently).
As
On 05/11/2012 04:52 PM, Gergely Nagy wrote:
> Neither the FHS, nor the policy says anything about etc-overrides-lib as
> far as I can see. Neither pro or con. Do feel free to point me to the
> relevant section, would I be mistaken.
>
Section 10.7.2 of dpm:
"Any configuration files created or u
On 05/11/2012 05:25 PM, Gergely Nagy wrote:
> And in etc-overrides-lib, config files still remain in /etc.
No.
--
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/4facf398
On 05/11/2012 06:39 PM, Gergely Nagy wrote:
>In other words, it does *exactly* the same thing systemd is
>criticised for.
>
Which doesn't mean that it's a good practice.
Thomas
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble
On 05/11/2012 06:39 PM, Gergely Nagy wrote:
> Long story short, I still don't see what the fuss is about.
>
The fuss is about we're being told that there will be silent
overwriting of configuration files without being prompted about
changes, which potentially, will make it horrible to manage
upg
On 05/11/2012 08:30 PM, Marco d'Itri wrote:
> On May 11, Thomas Goirand wrote:
>
>
>>> Long story short, I still don't see what the fuss is about.
>>>
>> The fuss is about we're being told that there will be silent
>> overwriti
On 05/11/2012 08:33 PM, Michael Biebl wrote:
> Am 11.05.2012 14:30, schrieb Marco d'Itri:
>
>> The problem with etc-overrides-lib is that a file must be copied in
>> full from /lib to /etc to be modified, and then future changes to the
>> same file in /lib will be ignored (so maybe the package
On 05/11/2012 08:28 PM, David Weinehall wrote:
> Talking about yourself in pluralis majestatis now?
> Yes, I get it that you are. Or are you somehow assuming that you can
> speak for all of Debian? I guess you're aware of the fact that I'm a DD
> too?
>
By reading other replies, I thought ther
On 05/11/2012 07:04 PM, Gergely Nagy wrote:
> Steve McIntyre writes:
>
>
>> Jean-Christophe Dubacq wrote:
>>
>>> If dpkg kept a copy of the original configuration file (to be retrieved
>>> at all times), it would be easier to spot local changes.
>>> I use etckeeper to do that, but it's a b
On 05/11/2012 11:08 PM, Marvin Renich wrote:
> For clarity, the etc-overrides-non-etc model that I am talking about is
> where the file in /etc can override individual values, not where the
> file in /etc must replace the entirety of the non-etc configuration.
>
This case is much much more accep
On 05/12/2012 12:22 AM, Jean-Christophe Dubacq wrote:
> I find your attitude assumes users always have the knowledge and the
> time to investigate everything. This is not the reality.
>
> Sincerly,
>
Not at all. Anyone without the knowledge will not be able to
restore anything anyway.
Anyone wi
On 05/12/2012 01:34 AM, Jean-Christophe Dubacq wrote:
> I think it would be really great to have some program being able to
> output all manual differences to all /etc files really useful for
> maintenance. I used to do that, but some rapidly evolving configuration
> files make it quickly unmaintai
On 05/12/2012 03:19 AM, Gergely Nagy wrote:
> The solution, however, is very simple: wrap dpkg calls, and have a list
> of files to watch for. Whenever a package touches a file that's on the
> list, fire a trigger, that can run a hook. Said hook can be something
> provided by etckeeper or similar,
On 05/12/2012 03:19 AM, Gergely Nagy wrote:
> It's perfectly able to notice changes
> in /lib/systemd too, or pretty much anywhere else.
>
I thought these were only default which we shouldn't
have to care about?!? :)
Thomas
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
wi
On 05/12/2012 03:29 AM, Gergely Nagy wrote:
> It's not etc-overrides-lib that is the problem. It's defaults changing
> without notice that is.
Then, let me ask this:
Do you expect that systemd's default in /lib will change often?
By the way, I finally found the time to try systemd, and I was
shoc
On 05/11/2012 05:07 PM, Gergely Nagy wrote:
> I'll turn this around: how do you handle cases where the defaults of
> packages like apt, exim or syslogd change? Where the defaults are
> embedded in the executable.
>
The thing is, if you put the default in a file, it's because you
expect these to
On 05/12/2012 10:02 PM, Nikolaus Rath wrote:
> The advantage of having the defaults in a file is that it makes it much
> easier to inspect them. A .h file would typically not be installed, so
> it wouldn't be readily available. In addition to that, it is much less
> expressive. The nice thing about
On 05/13/2012 08:12 PM, Toni Mueller wrote:
> Hi,
>
> On Sun, May 13, 2012 at 11:26:26AM +0100, Ben Hutchings wrote:
>
>> The value is the same as for most packages: it's easy to install and
>> easy to upgrade (I assume; I don't use Wordpress). Yes, the expected
>>
> if someone in Debian w
On 05/13/2012 05:32 PM, Russell Coker wrote:
> There are lots of people who choose Wordpress because it seems to provide a
> lot of features that other systems don't provide, which includes a
> significant
> set of free themes and plugins which are available from Wordpress.org (not in
> Debian)
On 05/03/2012 07:23 AM, Henrique de Moraes Holschuh wrote:
> Well, FWIW postfix allows you to override all MTA notifications, not just
> bounce messages, but the full set. We do that at work.
>
Interesting. Can you post an example here?
Thomas
--
To UNSUBSCRIBE, email to debian-devel-requ..
On 05/16/2012 08:45 PM, Jon Dowland wrote:
> Of course, many of these could be separate source/binary packages in their own
> right[1], as they have value outside of wordpress, and be
> Build-Depends/Depends
> of wordpress. In fact a few already are: jquery (already packaged); swfupload
> (not yet
On 05/20/2012 10:16 AM, Ben Hutchings wrote:
> Does anyone see a problem with the above, in particular points 1 and 2?
>
I agree with all you said (you know better than I), but what
I would really love to see would be the installer warning
people when they try to install the i386 version on a 64
On 05/20/2012 01:29 AM, Christoph Anton Mitterer wrote:
> Hi...
>
>
> On Sat, 2012-05-19 at 15:10 +0200, Alain SAURAT wrote:
>
>> This package is only avaible for squeeze and sid, is it normal ?
>>
> In addition to what Cyril already mentioned, see also
> http://bugs.debian.org/cgi-bin/bugr
On 05/25/2012 11:08 AM, Serge 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. Also mc was not able to open archives
>
On the server side, you can add that MySQL
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 muc
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
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
--
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 th
On 05/26/2012 09:20 AM, Nikolaus Rath wrote:
> I believe tmpfs memory is swapped out preferentially, so your scenario
> doesn't have to play out like that. However, paging being a complex
> process, it's not impossible either.
I haven't read the actual kernel code, just making assumption
from what
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-
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).
>
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
a
On 05/27/2012 02:55 AM, Mike Hommey wrote:
> I hope it isn't, because it's poor "security". It's easy to read the
> file from /proc/$pid/fd/$num
>
> Mike
>
If you were to trust Adobe in terms of security, then you'd be the first
person I know to do so.
Jokes set apart, I believe that they just
On 05/27/2012 02:35 AM, François Bottin wrote:
> 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
On 05/27/2012 04:32 AM, Russ Allbery wrote:
> 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 t
On 05/27/2012 04:32 AM, Russ Allbery wrote:
> 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
On 05/27/2012 08:09 PM, Henrique de Moraes Holschuh wrote:
> But my point was that people will not switch to writing small temporary
> files somewhere else, because they have not switched to writing files to
> $TMPDIR even after 10 years.
>
Please define who are the people you are talking about.
On 05/25/2012 05:41 PM, Josselin Mouette wrote:
> 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 pagin
On 05/25/2012 03:29 PM, Josselin Mouette wrote:
> Which means a *huge* performance
> improvement. Do the measurements yourself, it works with basically
> anything that makes heavy use of /tmp.
>
I have yet to know what application you are talking about.
Who's doing heavy use of /tmp exactly?
Th
On 05/27/2012 01:59 AM, Wookey wrote:
> 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 file
On 05/27/2012 02:52 AM, Mike Hommey wrote:
> 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 dire
On 05/25/2012 07:44 PM, Roger Leigh wrote:
> However, the majority of
> software which finds the tmpfs too small has unreasonable expectations
> of what can be expected to be available (by default).
>
We welcome you to rewrite / patch these software then!
Good luck, the list is huge, and growing
On 05/26/2012 03:12 AM, Nikolaus Rath wrote:
> 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%.
>
> Best,
>
>-Nikolaus
>
That's a bit off-topic but...
XFS has project quota, which are directory based. I'd
On 05/27/2012 09:38 PM, Russell Coker wrote:
> Sure it's easy for me to fix that when upgrading and when compared to all the
> other things I have to do on an upgrade it's not much of a big deal.
It's *not* easy, this involve init.d script foo ATM. See #674517.
Thomas
--
To UNSUBSCRIBE, email
On 05/27/2012 11:25 PM, Ben Hutchings wrote:
> As will /tmp on a small root partition.
> As will a small dedicated /tmp partition.
>
Why taking just bad configurations as counter arguments?
Do you know it is as well possible to have enough space
in your /tmp? :)
Cheers,
Thomas
--
To UNSUBSC
On 05/27/2012 02:42 PM, olivier sallou wrote:
> Keeping an updated mirror is not a good method for me, it is a painful
> task and you are never sure of the status
Isn't it possible to keep this repo up-to-date using
some of the git hooks? Like, when you push to your
repo on Alioth, it would aut
On 05/28/2012 02:08 AM, Salvo Tomaselli wrote:
> man 3 mktemp
>
I was talking about /bin/mktemp.
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/4fc28113.20
On 05/28/2012 05:32 AM, Roger Leigh wrote:
> On Sun, May 27, 2012 at 10:46:27PM +0800, Thomas Goirand wrote:
>> On 05/25/2012 07:44 PM, Roger Leigh wrote:
>>> However, the majority of
>>> software which finds the tmpfs too small has unreasonable expectations
>&g
On 05/28/2012 04:46 AM, Serge wrote:
> The truth is that tmpfs IS FASTER in some cases. The problem is that
> *nobody* can notice that on *real* applications.
Serge, I'm on your side of the discussion, but the above is simply
not truth. And by the way, that's not the issue. The issue is potential
b
On 05/28/2012 04:47 PM, Bernhard R. Link wrote:
> I personally think having tmpdir on /tmp might be a good default for
> new systems. If systems get changed to that from something else on
> upgrade without asking, I consider that quite an ugly bug.
>
And you're not the only one. It seems that at
On 05/29/2012 03:13 AM, Petter Reinholdtsen wrote:
> Perhaps it should be
> extended to allow the directory to be below ~/ instead of below
> /tmp/. :)
>
I don't think so. As other pointed out, your /home could be
remote (over NFS?), and then slow, while /tmp is normally
on your local machine, s
ure, we'll do that.
If anyone doesn't agree, please raise your concern *now* (including you,
Jack).
Cheers,
Thomas Goirand (zigo)
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.
On 05/30/2012 10:07 AM, Serge wrote:
> 2012/5/28 Thomas Goirand wrote:
>
>
>>> The truth is that tmpfs IS FASTER in some cases. The problem is that
>>> *nobody* can notice that on *real* applications.
>>>
>> Serge, I'm on your side of the d
in
> 2011). By the way, perhaps you can keep his sponosor (rmgolbeck) in the loop,
> maybe he knows other ways to contact the maintainer ?
>
rmgolbeck is Cc: to this mail.
Cheers,
Thomas Goirand (zigo)
--
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/4fc59455.9060...@goirand.fr
On 05/30/2012 05:11 PM, Jonas Smedegaard wrote:
> *nothing* qualifies for a hijacking.
>
> With hijacking I mean disrespectful takeover.
>
> Either respect maintainership by only NMUing, or respectfully resolve
> with the Debian community that the current maintainer is unfit for the
> task.
Ok,
On 05/31/2012 09:03 AM, Steve Langasek wrote:
> If you're unhappy that the package has been unmaintained for a long time and
> that the MIA process takes time to result in an orphaning... suck it up. If
> it was actually a problem, someone would have noticed it earlier and done
> something about i
On 05/31/2012 04:36 PM, Jonas Smedegaard wrote:
> Hijacking, in my vocabulary, is when a non-maintainer takes matters in
> his/her/their own hands and takes over maintainership without the
> consent of the former maintainer and outside formal Debian procedures.
>
Nobody did that, or had the in
On 05/31/2012 08:43 PM, Jonas Smedegaard wrote:
> I have no intention of spreading or amplifying wrong information.
>
> Do I understand it correctly that your intention in your original
> post was to have the package orphaned and then have a team take over
> maintainance?
>
I was also pointin
On 05/31/2012 10:52 PM, Mehdi Dogguy wrote:
> Please note that "badly maintained" is something quite different from
> "not maintained". AFAICS, the package we are talking about is not
> affected by severe or critical bugs.
That's a mater of views. #470294 should be made RC IMO.
Or is writing to /
On 06/01/2012 05:19 PM, Russ Allbery wrote:
> I don't know if this is all explicitly written down anywhere, but it's
> certainly my feel of the general consensus and social expectations of the
> people who discuss this sort of thing on debian-mentors.
>
I don't know if what you pretend is writt
On 06/02/2012 04:43 AM, Holger Levsen wrote:
> now that I notice the subject change I also notice the original subject...
>
> hi Thomas 8-)
>
LOL !
I'm amazed that it's seems I'm capable of creating huge uncontrollable
threads out of nowhere (eg: this isn't the first time).
I swear its never i
On 06/01/2012 06:50 PM, Goswin von Brederlow wrote:
> There is also no problem with having large files in tmpfs. Only
> requirement is that you make tmpfs large enough and add enough ram
> and/or swap to cope with it.
Well, there's the problem that it will take some memory at least. So
either your
On 06/02/2012 04:59 PM, Paul Wise wrote:
> They are tied to the source package, this is bad because people's
> commitment to and responsiblity for packages changes over time
> independent of source package uploads.
>
There's another thing that bothers me currently. If I do:
apt-cache show $pack
On 06/02/2012 10:11 PM, Serge wrote:
> First, there can be rather large session directory, you probably don't
> want ~365595 files to be always eating your RAM. Second, session data
> MUST NOT be lost on reboot by default. So even without /tmp, sysadmin
> should not put session data on tmpfs. There
On 06/06/2012 01:41 AM, Michael Gilbert wrote:
> And even then, I plan
> to defer the matter to the tech committee
Please do this *now*. We've already discussed about Wine in this
list few months ago, and the situation is still the same. At some
point, we need to get things moving...
Thomas
--
On 06/06/2012 04:23 AM, Stefano Zacchiroli wrote:
> Please don't spread incorrect information. The situation is by far not
> the same (as in: it's *much* better now), and that is also thanks to the
> discussion back then. -devel FTW, ... sometimes :-)
>
> Cheers.
>
I can see it, and I'm very h
301 - 400 of 1953 matches
Mail list logo
