Re: Starting services automatically after install
On 03/06/2012 11:23, Aaron Toponce wrote: > On Sat, Jun 02, 2012 at 10:43:00PM +0200, Tollef Fog Heen wrote: >> Are you seriously suggesting that DHCP and SSH servers should not listen >> on external interfaces by default? The use case for SSH or DHCPd on >> localhost only is pretty small. > > I would much rather have DHCP listening on localhost, than competing with > an already existing DHCP server on the LAN. > Is there even a point in having DHCP listening on localhost? -- Kind regards, Loong Jin signature.asc Description: OpenPGP digital signature
Re: Starting services automatically after install
* Aaron Toponce [120602 16:26]: > However, I am calling into question the validity of starting a service by > default post-install. I think it introduces security concerns, possible > headaces on the local LAN, and just unnessary work for the administrator. > Other than "if you don't want a service, don't install the package" > agrument, I don't understand why services _should_ be started by default > post-install. Try to see it from the other side: I don't understand why you would a like a service not started by default. The daemon is there to be run, so running it is the most sensible approach in almost all cases[1]. If a service comes with a default config that can be a real security concern, then that alone needs fixing. As administrator I also prefer that I just have to copy a config and install the package. Anything not run by default (or at last by default once its configuration is complete) means I have to tweak another config file, which is uncessary annoying work. Bernhard R. Link [1] Exceptions being specific things like unconfigured dhcp servers, but I never met one that would run by default as it first needs a subnet configured. But if I place a dhcpd.conf at the right location it starts as it should... -- 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/20120603062134.ga2...@client.brlink.eu
Re: Starting services automatically after install
On Sat, Jun 02, 2012 at 10:43:00PM +0200, Tollef Fog Heen wrote: > Are you seriously suggesting that DHCP and SSH servers should not listen > on external interfaces by default? The use case for SSH or DHCPd on > localhost only is pretty small. I would much rather have DHCP listening on localhost, than competing with an already existing DHCP server on the LAN. -- . o . o . o . . o o . . . o . . . o . o o o . o . o o . . o o o o . o . . o o o o . o o o -- 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/20120603032337.gi12...@kratos.cocyt.us
Bug#675736: ITP: libmodule-install-authorrequires-perl -- declare author-only dependencies
Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard
* Package name: libmodule-install-authorrequires-perl
Version : 0.02
Upstream Author : Florian Ragwitz
* URL : http://search.cpan.org/dist/Module-Install-AuthorRequires/
* License : Artistic or GPL-1+
Programming Lang: Perl
Description : declare author-only dependencies
Modules often have optional requirements, for example dependencies that
are useful for (optional) tests, but not required for the module to
work properly.
.
Usually you want all developers of a project to have these optional
modules installed. However, simply telling everyone or printing
diagnostic messages if optional dependencies are missing often isn't
enough to make sure all authors have all optional modules installed.
.
Module::Install already has a way of detecting an author environment,
so an easy way to achieve the above would be something like:
.
if ($Module::Install::AUTHOR) {
requires 'Some::Module';
requires 'Another::Module' => '0.42';
}
.
Unfortunately, that'll also make the optional dependencies show up in
the distributions "META.yml" file, which is obviously wrong, as they
aren't actually hard requirements.
.
Working that around requires a considerable amount of non-trivial
Makefile.PL hackery, or simply using Module::Install::AuthorRequires's
"author_requires" command.
--
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/20120603013712.3358.30930.report...@auryn.jones.dk
Bug#675733: ITP: libmodule-package-perl -- postmodern Perl module packaging
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard * Package name: libmodule-package-perl Version : 0.30 Upstream Author : Ingy döt Net * URL : http://search.cpan.org/dist/Module-Package/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : postmodern Perl module packaging Module::Package is a drop-in replacement for Module::Install. It does everything Module::Install does, but just a bit better. . Actually this module is simply a wrapper around Module::Install. It attempts to drastically reduce what goes in a Makefile.PL, while at the same time, fixing many of the problems that people have had with Module::Install (and other module frameworks) over the years. -- 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/20120603011026.32338.36480.report...@auryn.jones.dk
Results for Diversity statement
Greetings,
This message is an automated, unofficial publication of vote results.
Official results shall follow, sent in by the vote taker, namely
Debian Project Secretary
This email is just a convenience for the impatient.
I remain, gentle folks,
Your humble servant,
Devotee (on behalf of Debian Project Secretary)
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Starting results calculation at Sun Jun 3 00:00:06 2012
Option 1 "Ratify diversity statement"
Option 2 "Further Discussion"
In the following table, tally[row x][col y] represents the votes that
option x received over option y.
Option
1 2
=== ===
Option 1 251
Option 2 19
Looking at row 2, column 1, Further Discussion
received 19 votes over Ratify diversity statement
Looking at row 1, column 2, Ratify diversity statement
received 251 votes over Further Discussion.
Option 1 Reached quorum: 251 > 46.2574318353278
Option 1 passes Majority. 13.211 (251/19) >= 1
Option 1 defeats Option 2 by ( 251 - 19) = 232 votes.
The Schwartz Set contains:
Option 1 "Ratify diversity statement"
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
The winners are:
Option 1 "Ratify diversity statement"
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
--
The voters have spoken, the bastards... --unknown
DEbian VOTe EnginE
digraph Results {
ranksep=0.25;
"Ratify diversity statement\n13.21" [ style="filled" , color="powderblue",
shape=egg, fontcolor="NavyBlue", fontname="Helvetica", fontsize=10 ];
"Ratify diversity statement\n13.21" -> "Further Discussion" [ label="232" ];
"Further Discussion" [ style="filled" , shape=diamond, fontcolor="Red",
fontname="Helvetica", fontsize=10 ];
}
pgpWP3EM1tjc3.pgp
Description: PGP signature
Re: Idea: mount /tmp to tmpfs depending on free space and RAM
On June 2, 2012 03:48:03 AM Serge wrote: > 2012/6/2 Bruce Sass wrote: > >> Maintainer will probably write a better code. > > > > Much better... if TMPTIME != 0 it will be necessary to mount the FS based > > /tmp, clean it, create a tmpfs, move anything left in /tmp to the tmpfs, > > then mount --bind the tmpfs on /tmp. > > Oh... I was not thinking about TMPTIME. Does it mean that there's no way > we can mount /tmp to tmpfs because it breaks TMPTIME? no... TMPTIME is currently meaningless (or effectively == 0) when /tmp is a tmpfs, that is simply an expected consequence of keeping /tmp in RAM. It could become meaningful if tmpfs on /tmp's contents were written to disk at shutdown then reloaded at boot when TMPTIME's value is !=0. What it does mean is that automatically changing a system over to /tmp on tmpfs was a bad idea both philosophically and because it could cause data lose; and that there should be a check of TMPTIME's value and the contents of /tmp before any automated mechanism changes to a tmpfs based /tmp, to mitigate the possibility of data loss. - Bruce -- 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/201206021602.24750.bms...@shaw.ca
Re: Starting services automatically after install
]] Aaron Toponce > Enabling services on external interfaces by default is indeed a bug, IMO, > especially things like SSH, DHCP, SMTP or Bind (which has a long history of > security problems). Are you seriously suggesting that DHCP and SSH servers should not listen on external interfaces by default? The use case for SSH or DHCPd on localhost only is pretty small. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87vcj9momj@xoog.err.no
Re: Moving /tmp to tmpfs makes it useless
Hi Now lets do a benchmark on a busy system (during a kernel compile) and some memory pressure, due to building on tmpfs. While this is not directly representative for /tmp/ usage patterns, it does show what happens if /tmp/ gets full and fights against normal RAM uses. Tested on a current unstable system under KDE 4.7.4, debuild invoked under 'konsole'. For each test the system was freshly rebooted and is mostly idle. As an indicator for system responsiveness the only application running besides konsole && debuild is kaffeine, displaying a 720*576 DVB-T/ MPEG2 stream. *system specifications* - Intel Core2 Quad Q9550, 2.8 GHz - 8 GB RAM - ATI RV630 [Radeon HD 2600 Series] using xserver-xorg-radeon and its firmware - Seagate ST31000340AS HDD, 1 TB, 7200 rpm - io scheduler cfq registered (default) - kernel 3.4.1-rc1 required space for building linux-2.6 3.2.19-1 on amd64 using debuild on an unclean host, involving a lengthy lintian run (no devscripts.conf customisation), ~19 GB *ext4* single GPT partition spanning the whole disk, freshly formatted with ext4 (all defaults, empty). /dev/sdc1 /mnt ext4 rw,relatime,data=ordered 0 0 [during the build, towards the end (docbook generation)] $ free -m total used free sharedbuffers cached Mem: 7991 7830160 0 57 6435 -/+ buffers/cache: 1338 6652 Swap:0 0 0 $ time debuild -j8 […] real142m17.038s user249m31.896s sys 33m25.303s The system remains responsive during the whole build time, video display remains fluent. *tmpfs* single GPT partition spanning the whole disk, freshly mkswap'ed benchmark /mnt tmpfs rw,nosuid,nodev,relatime,size=838860800k 0 0 [during the build, towards the end (docbook generation)] $ free -m total used free sharedbuffers cached Mem: 7991 7486504 0 2 6527 -/+ buffers/cache:956 7034 Swap: 953868 7142 946726 [immediately after the build] $ free -m total used free sharedbuffers cached Mem: 7991 7250740 0 87 6302 -/+ buffers/cache:861 7129 Swap: 953868 11846 942021 $ time debuild -j8 […] real163m15.803s user253m6.583s sys 35m38.599s Once the system gets under memory pressure (more than ~7-9 GB space needed on tmpfs), system responsiveness is gone. Video playback becomes a strobe light slide show, mouse and cli are choppy, moving windows is basically impossible - not enough to get tempted to hit hard-reset, but interactive system use is no longer useful. Of course this is not a representative benchmark, unless swap is many times larger than system RAM, but it shows what happens when tmpfs gets full (which is not an unlikely situation, as demonstrated in this thread) and enforces swapping. Keep in mind that the OOM killer cannot evict tmpfs, but only page it out. However comparable situations might easily arise on systems up to 1 GB RAM and twice its RAM size as swap, these systems have basically no RAM to spare for tmpfs. While I'm not arguing for or against the RAMTMP defaults, given that I tend deviate from normal procedures[1] here, I don't think systems with less than 2 GB system RAM can spare any of their RAM for /tmp/[2]. Even on systems with more RAM, it might be pretty hard to reserve enough space on a tmpfs backed /tmp/ to meet the expectations of contemporary applications, without compromising on system memory. Regards Stefan Lippers-Hollmann [1] by bind mounting /var/tmp/ on /tmp/, either backed by a separate /var/ partition or a dedicated /var/tmp/ partition on servers [2] using KDE4 or GNOME3, anything below 1 GB RAM severely limits "multi-tasking"; running browser, office suite, PDF viewer, file manager at email client at once basically requires ~1.5 GB RAM at least. -- 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/201206022038.39233.s@gmx.de
Re: amd64 as default architecture
On 2012-06-01 11:54 +0200, Goswin von Brederlow wrote: > Guillem Jover writes: > >> On Sun, 2012-05-20 at 14:03:35 +0200, David Kalnischkies wrote: >>> On Sun, May 20, 2012 at 1:10 PM, Sven Joachim wrote: >>> > On 2012-05-20 11:27 +0200, Goswin von Brederlow wrote: >>> > > Slightly OT but I wanted to mention it for its similarity: >>> > > >>> > > One thing that should be tested and then documented prominently as yay >>> > > or nay in the wheezy upgrade notes is wether one can cross-grade from >>> > > i386 to amd64 using multiarch. Wether one can install apt/dpkg:amd64 and >>> > > then migrate to a 64bit userspace. >>> > >>> > Won't work in wheezy, apt does not support crossgradesน. > > Why? What breaks? You give the answer yourself: > Testing (see below) shows that there is one big issue, namely that > crossgrading wants to remove the package before installing the new > one. This means you have to crossgrade at least the essential packages without apt's help. While this should not pose insurmountable difficulties, it is probably not something to be recommended to the average user. > Interestingly enough apt has no problem with removing an essential > package from a foreign architecture. In this case though it breaks > because the diversion handling in bash/dash is broken for crossgrades: > > Removing dash ... > Removing 'diversion of /bin/sh to /bin/sh.distrib by dash' > dpkg-divert: error: rename involves overwriting `/bin/sh' with > different file `/bin/sh.distrib', not allowed > dpkg: error processing dash (--remove): > subprocess installed pre-removal script returned error exit status 2 This may be a bug in dash. Few people remove essential packages, so removing dash has probably not been tested so well. > Overall the one MAJOR showstopped seems to be that apt/dpkg can't > crossgrade a package without removing it. Only apt cannot do that, dpkg has no problem with it. But if you use dpkg alone you may be left with lots of unfulfilled dependencies after the crossgrade, see #20471¹. Cheers, Sven ¹ http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=20471 -- 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/87fwadin1e@turtle.gmx.de
Re: Idea: mount /tmp to tmpfs depending on free space and RAM
On Sat, Jun 02, 2012 at 02:56:03PM +0200, Philipp Kern wrote: If you assume an unexpected reboot, then all that data will be lost, Well, I can count my unexpected reboots in the last years with one hand, so this is not a problem. And as already mentioned, you can configure with TMPTIME in /etc/default/rcS, which files in /tmp will be deleted. you to redownload these images. Couldn't /var/tmp serve this purpose better, if it's not exactly ephemeral data? (Like a temporary ISO created from on-disk content.) Since I’m not interested in filling my /var partition with tmp files (and so getting problems with databases or logs), /var/tmp is always a link to /tmp. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Bug#675695: ITP: abtransfers -- simple online banking application for online money transfers
Package: wnpp Severity: wishlist Owner: Micha Lenk Hi, just for the records, I am currently working on packaging abTransfers from Patrick Wacker. * Package name: abtransfers Version : 0.0.3.0 Upstream Author : Patrick Wacker * URL : http://schmufu.dyndns.org/dokuwiki/ab_transfer:start * License : GPL Programming Lang: C++ Description : simple online banking application for online money transfers AB-Transfers is an application for online money transfers of any kind. In contrast to KMyMoney or Gnucash it is not intended to be used as a complete accounting application but is intended to be used as a companion to them to perform money transfers that they don't support. If it seems to fit it will serve as a replacement for the package qbankmanager that I am maintaining too, but which is abandoned upstream. Regards, Micha -- 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/20120602180554.6234.36272.report...@ian.lenk.info
Re: pbuilder + ccache suddenly fails
On Sat, Jun 02, 2012 at 12:08:24PM -0500, Steve M. Robbins wrote: > How do I disable ccache inside pbuilder? OK, I figured this out. The workaround is detailed in #675691. Cheers, -Steve signature.asc Description: Digital signature
Re: pbuilder + ccache suddenly fails
Am 02.06.2012 19:08, schrieb Steve M. Robbins: > This hit me again. Is no-one else experiencing this? I had this problem too. I found a bugreport about this somewhere in BTS (cant remember the number). There was the suggestion to set BUILDUSERID as env var in the shell to your userid. This worked for me. The man page of ccache says that setting CCACHE_DISABLE=1 will disable ccache. -- MfG, Christian Welzel GPG-Key: pub 4096R/5117E119 2011-09-19 Fingerprint: 3688 337C 0D3E 3725 94EC E401 8D52 CDE9 5117 E119 -- 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/jqdjnt$9d6$1...@dough.gmane.org
Re: pbuilder + ccache suddenly fails
On Sun, May 06, 2012 at 05:33:10PM -0400, Andres Mejia wrote: > On Sun, May 6, 2012 at 2:40 PM, Steve M. Robbins wrote: > > On Sun, May 06, 2012 at 01:21:57PM -0400, Andres Mejia wrote: > >> On Sat, May 5, 2012 at 9:57 PM, Steve M. Robbins wrote: > >> > I've routinely used pbuilder to build packages for years. > >> > Yesterday, I have started to see the following failure: > >> > > >> > ccache: FATAL: Failed to create /var/cache/pbuilder/ccache/0/f: > >> > Permission denied This hit me again. Is no-one else experiencing this? > Part of the reason to use pbuilder or sbuild is to build packages in a > clean chroot. Providing ccache support in this way isn't clean and > apparently it's prone to problems such as the bug you pointed out. See > also [1]. > > If you're going to upload to the archive, simply disable ccache. As I explained: I have neither enabled nor disabled ccache within pbuilder, nor have I changed my pbuilder practices. This had never happened to me prior to a month ago. Has something changed in pbuilder or ccache in the last few months to account for this? How do I disable ccache inside pbuilder? Thanks, -Steve > > 1. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=430765#35 > > -- > ~ Andres > signature.asc Description: Digital signature
Re: Starting services automatically after install
On 2012-06-02 08:25:40 -0600 (-0600), Aaron Toponce wrote:
[...]
> I don't understand why services _should_ be started by default
> post-install.
[...]
There are many desktop-oriented home networking applications (file
and printer sharing, media distribution, et cetera) which really do
need to be started upon installation. The average desktop user is
going to expect them to "just work" when installed, and probably
doesn't even grok the concept of a socket listener much less
understand why it would need to be "started" before it works.
On a server with a competent system administrator, there's someone
who understands that a service needs to be configured and started.
On the other hand, that same administrator can protect their systems
from compromise through an automatically-started-but-mostly-secure
default configured network service (local packet filters, selinux
policies, network firewall devices, out-of-band/offline
upgrades...).
It may not be a popular opinion, but I'm personally quite a fan of
the maintainers who compromise by providing a package with the
daemon and then one or more separate packages with init system
bindings/scripts. That way you can install *just* the software,
configure it, then install a second package which causes it to run
by default. And if someone wants it to run automatically, they can
just install the init binding package which depends on the
corresponding daemon package. Seems elegant to me, admittedly at the
expense of increasing the size of the package database with teensy
init-oriented packages (but really, are the majority of Debian's
packages network daemons anyway?).
--
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fu...@yuggoth.org); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); IRC(fu...@irc.yuggoth.org#ccl); }
--
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/20120602170032.gf1...@yuggoth.org
Bug#675626: ITP: lutok -- Lightweight C++ API library for Lua
Package: wnpp Severity: wishlist Owner: Julio Merino * Package name: lutok Version : 0.2 Upstream Author : Julio Merino * URL : http://code.google.com/p/lutok/ * License : BSD Programming Lang: C++ Description : Lightweight C++ API library for Lua Lutok provides thin C++ wrappers around the Lua C API to ease the interaction between C++ and Lua. These wrappers make intensive use of RAII to prevent resource leakage, expose C++-friendly data types, report errors by means of exceptions and ensure that the Lua stack is always left untouched in the face of errors. The library also provides a small subset of miscellaneous utility functions built on top of the wrappers. Lutok focuses on providing a clean and safe C++ interface; the drawback is that it is not suitable for performance-critical environments. In order to implement error-safe C++ wrappers on top of a Lua C binary library, Lutok adds several layers or abstraction and error checking that go against the original spirit of the Lua C API and thus degrade performance. -- 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/20120602153507.18550.72331.report...@debian.julipedia.org
Re: Starting services automatically after install
On Sat, Jun 02, 2012 at 04:02:57PM +0300, Serge wrote: > I'm not experienced in this topic much yet, that's why I'm writing not in > list, but directly. Feel free to reply into list, if you wish. I would prefer to keep it on the list for a public archive, and to benefit the greater admin population. > I understand both approaches, so here's the question/suggestion. > > If both approaches are valid and there're people who likes each of them, > then, maybe, we can suit them all. > > Is it possible to configure dpkg (or something else) so that it would not > start services? I.e. is there some simple option, like: > echo START_ON_INSTALL=no >> /etc/dpkg/dpkg.cfg > so that one could configure which approach he likes? This, or a global /etc/default/services (or similar file) for all services. However, I am calling into question the validity of starting a service by default post-install. I think it introduces security concerns, possible headaces on the local LAN, and just unnessary work for the administrator. Other than "if you don't want a service, don't install the package" agrument, I don't understand why services _should_ be started by default post-install. -- . o . o . o . . o o . . . o . . . o . o o o . o . o o . . o o o o . o . . o o o o . o o o -- 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/20120602142539.gh12...@kratos.cocyt.us
Re: Starting services automatically after install
On Fri, Jun 01, 2012 at 08:23:20PM +0200, Jonas Smedegaard wrote: > Debian goal is - as you probably know already - for packages to work out > of the box. For daemons this means they are started by default. > > If a package (service or not) is insecure by default, it is a bug! > Severity of such bugs vary - e.g. some may consider it insecure for a > web server to publicly display a static page saying "It works!" while > most probably won't. > > You can override the default of daemons using policy.d. > > What I do for chroots - which you can adapt to your own personal needs, > is to install the package policyrcd-script-zg2 and add the attached > config file as /usr/local/sbin/policy-rc.d . (Snipped code) This is quite a bit of work from the administrator's point of view. And, as much as we would not like to admit it, no software is "secure by default". Security isn't a binary function. I wouldn't mind so bad if the services listened to localhost by default, and not on external interfaces. This would allow me to make configuration changes, and continue to reload the service, testing locally, until I'm satisfied it can be for the general public, or whomever my customers are. Enabling services on external interfaces by default is indeed a bug, IMO, especially things like SSH, DHCP, SMTP or Bind (which has a long history of security problems). -- . o . o . o . . o o . . . o . . . o . o o o . o . o o . . o o o o . o . . o o o o . o o o -- 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/20120602142101.gg12...@kratos.cocyt.us
Re: Starting services automatically after install
On Fri, Jun 01, 2012 at 07:49:03PM +0100, Philip Hands wrote: > The reason that RedHat don't start things is that their default approach > has been to install a whole load of stuff that you might possibly want, > and allow you to enable it when you are inspired to give some new > service a try. > > The Debian approach has always been to not install anything that you > don't intend to use. It is also to ensure that if you do choose to > install something, it should be doing something useful by the end of the > install (if possible, security considerations allowing). I don't understand what you are saying. When I install a RHEL system from scratch, as with the Debian Installer, it's trivial to install just a base system, then install the software you need after that. In this case, I will do a "yum install httpd", and it will install Apache and its dependencies. In a similar fashion, doing an "aptitude install apache2" will also install Apache and its dependencies. Both systems will be in a similar state with installed software, except RHEL will wait for me to configure the package first, before starting, while Debian is shiiping the "It Works!" page to anyone who queries the server. > That is also why Debian and RedHat diverge when it comes to prompting > the user for configuration questions -- RedHat just want the software to > install, whereas Debian wants it to be useful, so may need to ask > questions. I also don't understand what you are saying here. Red Hat installs the software and makes it possible for me to start providing value to my "customers", as does Debian. What do you mean that Red Hat does not want useful services, and Debian does. > It also leads to the fact that you can do major release upgrades of > Debian, whereas that's not really supported in RedHat, as chances are > your configuration is going to get trashed to some extent, and they > don't have the chance to ask you what you want to do about it. No. In both cases, doing a major release, whether Debian stable -> Debian stable, or RHEL 5 -> RHEL 6, there is going to be breakage. This should always be heavily tested before such a massive migration. This is why there is such things as "development" and "QA" evironments. You always test major software upgrades before doing them. Regardless of operating system. Heh. > If you don't like the assumptions, you are much better off switching to > a distribution that you prefer, rather than trying to persuade the > overwhelming majority of the people that like the current assumptions, > and use Debian because of those assumptions, that they should change > their minds because they are supposedly wrong for liking it that way. Wrong answer. Rather than telling people to go elsewhere, because you don't understand their point of view, the constructive approach would be a discussion about adding a /etc/default/services config file, with "START=on" or "START=off", or something similar. Debian provides a great deal of value to me and many others. Just because it might have one point that I don't agree with, does mean I should ignore all the other points that I do agree with, and use a different operating system. I'm curious how this solves any problems at all. -- . o . o . o . . o o . . . o . . . o . o o o . o . o o . . o o o o . o . . o o o o . o o o signature.asc Description: Digital signature
Re: Bug#675577: libgmp-dev: arch-dependent files in "Multi-Arch: same" package
On Sat, Jun 02, 2012 at 10:54:13AM +0200, Jakub Wilk wrote: > Package: libgmp-dev > Version: 2:5.0.5+dfsg-2 > User: multiarch-de...@lists.alioth.debian.org > Usertags: multiarch > > libgmp-dev is marked as "Multi-Arch: same", but the following files > are architecture-dependent: > > /usr/include/gmp-arm.h > /usr/include/gmp-i386.h > /usr/include/gmp-mips.h > /usr/include/gmp-x86_64.h True, but only one such file exists in each arch's build. I was told this is acceptable as long as any file name that is shared among architectures has the same contents [1] (which is the case). Who is right? [1] http://lists.alioth.debian.org/pipermail/debian-science-maintainers/2012-May/013450.html Thanks, -Steve signature.asc Description: Digital signature
Re: Idea: mount /tmp to tmpfs depending on free space and RAM
2012/6/2 Toni Mueller wrote: >> Well, nobody named the benefits yet. Just the problems. There were a > > Well, I named one on 28th of May. Did you read it? Sorry, I was trying to send not so many messages then, and I had not answered yours. I guess you talk about these: > Eg. web application's session data very frequently goes there, and/or > the sysadmin wants it to go onto a tmpfs. 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're different admins, however... >> Q: gcc writes small files in /tmp >> A: usually it does not, especially when used with -pipe option > > Changing all (generated?) Makefiles floating around out there, and > getting the changes committed upstream to actually benefit from that is > easier than using a tmpfs, of course. No need to. You only need to add -pipe to your *FLAGS. You don't build software with default autotools flags (-g -O2) anyway, I guess. -- 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/CAOVenEpgq4vfwODL=fa+krvdeshavo4fcuzwspnyn4-myhf...@mail.gmail.com
Upgrade path for packages that dropped ia32-libs for wheezy
Hello, I have a non-free package that is distributable but comes precompiled for i386. Squeeze (and previous) released an amd64 package that depended on ia32-libs. For wheezy we've been able to use multiarched libraries to drop the dependency. Is there a mechanism that will make the upgrade to wheezy work for the package? Right now dpkg uninstalls the package (because it sees the data package, which is "all" but can't find the corresponding binary package in amd64), users are confused, find a bug report on the BTS or the changelog on a debian site telling them to enable i386 in dpkg, then they install the :i386 package and it works. This may just be a non-free issue people have to deal with, I just wanted to see if there was a better way or plan in place to handle this. Regards, Scott -- 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/CANg8-dDH-SiOP=fbfbld74ewujvfd7svki9txsp3cxx0exu...@mail.gmail.com
Re: Idea: mount /tmp to tmpfs depending on free space and RAM
On Fri, Jun 01, 2012 at 07:21:40PM +0200, Stephan Seitz wrote: > /tmp is for temporary files, so I expect my /tmp to hold all these > files, in my case DVD ISO images (downloaded or localy generated) > that I will burn and then delete. So my /tmp is at least 20GB. > BluRay users may need more. If you assume an unexpected reboot, then all that data will be lost, forcing you to redownload these images. Couldn't /var/tmp serve this purpose better, if it's not exactly ephemeral data? (Like a temporary ISO created from on-disk content.) Kind regards Philipp Kern -- 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/20120602125603.ga11...@spike.0x539.de
Re: Moving /tmp to tmpfs makes it useless
> that problem applies to disks as well, and especially to small / > partitions, if you don't have /tmp somewhere else. But by default the installer doesn't create a small / partition, it uses all the available space. So by default just by clicking next->next, there are no such problems. Users who don't like defaults can change them but they are supposed to know, or at least have a clue of what they are doing. So you are taking into consideration an odd and uncommon situation. If the user just happens to have a 1Gb drive then... well... i guess you can't expect the swap partition to be 10Gb right? -- 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/201206021453.02506.tipos...@tiscali.it
Re: Moving /tmp to tmpfs makes it useless
* Toni Mueller [2012-06-02 13:46:19 +0200] wrote: > My suggested fix for this problem is to install a ~/tmp upon account > creation, and set the TEMP environment variable in, say, > /etc/environments. That *should* fix up all cases except for rogue > applications that don't honour $TEMP. We can then proceed to fix these > over time, while not demanding too many changes to the general setup. As a simple Debian user my suggestion is to not "fix" non-problems. /tmp on a regular disk is not a problem. It works. It has been working nicely many years. It's the best default. -- 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/87y5o5zz5p@mithlond.arda
Re: Starting services automatically after install
On 12-06-02 at 12:52pm, Tollef Fog Heen wrote: > ]] Jonas Smedegaard > > > > A problem with using policy-rc.d is you don't know whether a > > > service is being started because it's the initial install or if > > > it's because of an upgrade. I'll sometimes not want the service > > > to start on initial installation (because chef is just about to > > > plop its configuration into place), but if it's an upgrade, then > > > please just restart the service. > > > > You could setup your local policy to check if the service exist in > > e.g. /etc/local-ok-services/ and then when you've customized or > > security-checked or whatever each service you do a > > > >touch /etc/local-ok-services/$service > > > > Or did I misunderstand? > > You could do something like this, and it would handle most cases, but > not all corner cases. However, it's a workaround for information that > the system already has. The postinst already know whether it's an > initial installation or not, invoke-rc.d and policy-rc.d should just > be told so it can make a better decision. > > (An obvious problem with having a whitelist is then what happens when > you purge a package? It won't magically be removed from the whitelist > and so you end up in an unwanted situation.) > > > (We haven't spoken much in person, but I regard you as pretty clever > > so am surprised that you describe this as a problem and I feel it so > > simple to solve...) > > The 90% solution is easy, I don't think the 100% solution is that > easy. I haven't investigated it deeply though. Makes sense. Thanks - my confidence in you is now restored :-D - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On 06/01/2012 08:45 PM, Steve Langasek wrote:
> On Thu, May 31, 2012 at 08:20:40AM +0200, Raphael Hertzog wrote:
>> On Wed, 30 May 2012, Steve Langasek wrote:
>>> There is no excuse for hijacking a package, ever.
>
>>> If the maintainer is MIA, use the MIA process to get the package orphaned.
>
>> This goes too far IMO. One of the reasons why the MIA process has been
>> setup is because many DD fear forcibly taking over or forcibly orphaning
>> a package. So instead of relying on random DD to do it, we put up some
>> best practice procedure and a team to handle this.
>
>> But this process is not set in stone, and if a DD believes that the best
>> course of action is to orphan/take over a package, he should certainly be
>> free to do it all by him/herself.
>
>> Informing the MIA team for tracking purpose is still a good idea, though.
>
> So I should probably clarify, because I misspoke in my previous message. By
> "MIA process" I was not merely referring to the process used to determine
> that a Debian developer is MIA and should have their account expired; I was
> also referring to the longstanding process of discussing package orphaning
> on the QA mailing list, and having the QA team make a determination that a
> package is de facto maintainerless and should be orphaned.
That is exactly what the MIA team does (or should do but sometimes just doesn't
find the time to do so). There is no formal QA team.
> The important thing here is still that the decisions are made by consensus
> within the QA *team*, not as a decision by a single developer who decides to
> take over the package. This is an important check on developers deciding in
> the moment that their particular pet issue should trump our conventions.
Everybody is part of the QA team, there are only some people with write access
to the repositories, that is the only difference. As I mentioned before (see my
other mails in this thread) such discussions happened for years on debian-devel
(or on debian-qa, but that does not make a difference), and not somewhere in a
QA "team".
> So no, I stand by my statement that an individual DD should not take it upon
> themselves to decide that a package should be orphaned. This sort of thing
> needs to be a community decision.
What do you think why the original submitter wrote to debian-devel?
> On Thu, May 31, 2012 at 01:08:11PM +0100, Ian Jackson wrote:
>> Steve Langasek writes ("Re: Orphaning php-codesniffer, then take it over by
>> the PHP PEAR team"):
>>> A hijack is, by definition, a declaration by the hijacker that they believe
>>> they are not answerable to the project's processes for how package
>>> maintenance is decided. It is antisocial vigilanteism and it is not
>>> acceptable.
>
>> Our processes for how package maintenance is decided are utterly
>> dysfunctional.
>
>> If the TC had _ever_ voted to remove a maintainer who wanted to keep
>> hold of a package, it might be at least reasonably possible to argue
>> that the TC was the right forum for these disputes.
>
>>> As a sitting member of the Technical Committee, I encourage anyone who sees
>>> a package being hijacked to immediately bring it to the attention of the TC.
>>> I will without hesitation vote to have the hijacker barred from being made
>>> the maintainer of the package.
>
>> Instead of this kind of aggressive approach to those who are IMO quite
>> reasonably working around our dysfunctional formal processes, how
>> about working towards fixing those dysfunctional processes ?
>
>> I await with interest your suggestions for revising the way the TC
>> deals with problematic maintainers. I have been arguing for years
>> that we need a much more robust approach.
>
> Right, so the constitution says that it's the TC that decides whenever
> there's a question of maintainer.
>
> But in practice, when one of the would-be maintainers is not doing the work
> and not responding to email, I don't think there should be any need for the
> formal process of a TC vote. I think it's more than sufficient to get a
> consensus on the mailing list that the maintainer isn't coming back, *after*
> making an appropriate effort to contact the maintainer and waiting a
> suitable amount of time for a response. And indeed, this is the convention
> that's been in place for approximately the past decade on the debian-qa
> list.
Why on debian-qa? It is a long tradition to post such requests to debian-devel,
and most people read this list. I can't see a reason why it should be posted to
-qa, especially not as there is no special QA team.
> The key points of this process are:
>
> - It's not a decision by an individual that the package can be orphaned
>(and silence does not imply consent).
> - An effort is made to actively contact the maintainer on the subject of
>orphaning, rather than assuming the maintainer's non-interest based on
>the state of bugs.
> - The maintainer is given a suitable amount of time to respond. A week is
Re: Idea: mount /tmp to tmpfs depending on free space and RAM
On Fri, Jun 01, 2012 at 07:00:52PM +0300, Serge wrote: > Well, nobody named the benefits yet. Just the problems. There were a Well, I named one on 28th of May. Did you read it? Kind regards, --Toni++ -- 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/20120602115220.gc20...@spruce.wiehl.oeko.net
Re: Moving /tmp to tmpfs makes it useless
Hi Thomas, On Sat, Jun 02, 2012 at 07:33:26PM +0800, Thomas Goirand wrote: > > All the complaints about /tmp as tmpfs come down to one simple issue: > > The size of the tmpfs isn't chosen well. It would be more constructive > > to find a better heuristic for the size there. > > No. The complain is that it will never be big enough for some cases. If > you tell me that it should be twice as big as now, then I'll tell you: > what if we have to handle files twice as big as what you thought to > begin with? that problem applies to disks as well, and especially to small / partitions, if you don't have /tmp somewhere else. If we are talking by making /tmp its own file system, that's ok, but if we are talking about manually relocating it to (say) /var/tmp, then we've made exactly as much progress as we would have made by making it tmpfs by default: We then require the user to manually intervene and change the default. > don't force it to all users as a default which might break and that some > users wont understand. This is just too risky to have some users saying > "linux is crap, libreoffice can't open big PPT files, it gets horribly > slow, then crashes the whole system so much that I have to reboot". > Probably that's wrong, but it's still going to be the comments of our > users. You certainly can't cover all edge cases, and especially "non-technical users" have just too many ways to break any system, as well as usually being too rash to investigate. My suggested fix for this problem is to install a ~/tmp upon account creation, and set the TEMP environment variable in, say, /etc/environments. That *should* fix up all cases except for rogue applications that don't honour $TEMP. We can then proceed to fix these over time, while not demanding too many changes to the general setup. And fwiw, the user's home is supposed to be big enough for all such cases where the user is "non-technical", but still his own systems administrator - the case you are highlighting. Kind regards, --Toni++ -- 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/20120602114619.gb20...@spruce.wiehl.oeko.net
Re: Maintainer responsible for or only doing maintenance?
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 $package | grep Maintainer in the stable distribution, I can see who was the last person who was declared as the maintainer of a package before Stable was released. This gives very few hints on who is the *actual* maintainer of a package. Somebody without much experience might rapidly get fooled and write to the wrong email address. I'm not sure what's the solution. Maybe having "apt-cache show" to replace the Maintainer field by a link to packages.debian.org or something like that... 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/4fc9fcfb.2080...@debian.org
Re: Moving /tmp to tmpfs makes it useless
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 tmpfs is too small, either it eats all your RAM. None are good options, unless you have a ridiculous huge amount of RAM available. And that's why we shouldn't have it *by default* (that's the only thing we are discussing here, not the fact that tmpfs is good or not, please don't "hijack" the debate). > All the complaints about /tmp as tmpfs come down to one simple issue: > The size of the tmpfs isn't chosen well. It would be more constructive > to find a better heuristic for the size there. No. The complain is that it will never be big enough for some cases. If you tell me that it should be twice as big as now, then I'll tell you: what if we have to handle files twice as big as what you thought to begin with? If you tell me 4 times, I'll tell you about files 4 times bigger as well, and so on... So it all goes down to a simple fact: in nearly all cases, we have a lot more HDD space than we have RAM, which is why /tmp needs to be using the HDD. There's never a case where tmpfs /tmp will be big enough to handle all situations, while using HDD has a lot more chance to be able to cope with it. Anyway, if you're an expect, no problem, choose tmpfs if you want. But don't force it to all users as a default which might break and that some users wont understand. This is just too risky to have some users saying "linux is crap, libreoffice can't open big PPT files, it gets horribly slow, then crashes the whole system so much that I have to reboot". Probably that's wrong, but it's still going to be the comments of our users. Will you be watching debian-users@l.d.o and our forum, and explain each of them? Will you take the time to explain this to my wife and my mom (good luck...)? 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/4fc9fa06.7080...@debian.org
Re: Starting services automatically after install
Hi Phil, On Fri, Jun 01, 2012 at 07:49:03PM +0100, Philip Hands wrote: > The Debian approach has always been to not install anything that you > don't intend to use. I have brought up this topic in the past, too. Summary: I often do want the Debian-packaged software on my systems, but use it entirely differently from what the package maintainer had in mind when he created the package. Eg. restring services to certain IPs, configure ACLs, change locations, running not under init but runit instead, whatever. > It is also to ensure that if you do choose to > install something, it should be doing something useful by the end of the > install (if possible, security considerations allowing). I can actually do that. Please note that this problem only ever affects services, and the person who is going to run a service will have to do one additional action if the service is not being started right away (start it if he is satisfied with the default configuration), whereas everyone with different requirements, and it's very easy to run into such a situation, will have to scramble to avoid doing that. Makes unattended operations more difficult, imho. > the user for configuration questions -- RedHat just want the software to > install, whereas Debian wants it to be useful, so may need to ask > questions. The package maintainer can do only so much to make a package "useful right away", and certainly not cover many interesting cases from the real world, due to lack of time, or also imagination, or expertise. > Both approaches are valid, and are mostly a matter of taste. If you > are using a distribution that uses one assumption, it's not useful to > start introducing packages that work on the opposite assumption. I was never under the assumption that it was Debian's policy that made the system this way, but only the superiour packaging system that enables this kind of configuration to be done at package-install-time. And what if you had set the debconf value for the user interface to "noninteractive"? Start the service, anyway? It's just safer to not start the service immediately after installation. Eg. when I recently installed some nova* packages on one system, they destroyed that system because of missing/wrong configuration and the unability to cope with the situation they found, but nevertheless cheerfully started immediately, anyway, with no way for me to anticipate and/or prevent that situation... major bummer (I'm just recovering from it)! > If you don't like the assumptions, you are much better off switching to > a distribution that you prefer, rather than trying to persuade the > overwhelming majority of the people that like the current assumptions, > and use Debian because of those assumptions, that they should change > their minds because they are supposedly wrong for liking it that way. These are *quite* strong words, imho. Whoever wasn't aware of these assumtions, or doesn't have a dedicated opinion, would probably object to being pocketed like this. I also think that there are more, other reasons for choosing Debian, not only this habit. Kind regards, --Toni++ -- 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/20120602111809.ga20...@spruce.wiehl.oeko.net
Re: Idea: mount /tmp to tmpfs depending on free space and RAM
On Sat, Jun 02, 2012 at 12:48:03PM +0300, Serge wrote: Oh... I was not thinking about TMPTIME. Does it mean that there's no way we can mount /tmp to tmpfs because it breaks TMPTIME? Well, I think, as long as this setting exist, no. With „-1” you can even disable tmp cleaning. So if the admin wishes to change the setting to keep files in /tmp even after reboot, you can’t use tmpfs, even if you don’t have enough space left. You can only print a warning message but not ignore the local configuration. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: Maintainer responsible for or only doing maintenance?
On 12-06-02 at 04:59pm, Paul Wise wrote: > On Sat, Jun 2, 2012 at 1:33 AM, Jonas Smedegaard wrote: > > > Today I find the Maintainer field a joke. > > Both the Maintainer and Uploaders fields are less than useful for a > number of reasons: > > 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. > > They are not sufficient to represent reality. While we have some > definition in, there are many different styles of maintainership and > different levels of commitment. > > I would like to see Debian get rid of the Maintainer and Uploaders > fields and instead implement something like DEP-2 where we have a list > of people, what they are willing to work on and the things they are > willing to do. [snip] > In this way we will get a much more realistic picture of the > commitment of the Debian community to the software that we are > shipping. Registering this level of detail might not be something > individuals are willing to do though. So because the classic fields are insufficient, you want to drop them. Even if you already ahead notice that replacement is probably too complex for simple uses. I have not followed DEP-2, so unaware if I am totally off here, but seems more sensible to me to keep classic hints as defaults. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Re: Starting services automatically after install
]] Jonas Smedegaard > > A problem with using policy-rc.d is you don't know whether a service > > is being started because it's the initial install or if it's because > > of an upgrade. I'll sometimes not want the service to start on > > initial installation (because chef is just about to plop its > > configuration into place), but if it's an upgrade, then please just > > restart the service. > > You could setup your local policy to check if the service exist in e.g. > /etc/local-ok-services/ and then when you've customized or > security-checked or whatever each service you do a > >touch /etc/local-ok-services/$service > > Or did I misunderstand? You could do something like this, and it would handle most cases, but not all corner cases. However, it's a workaround for information that the system already has. The postinst already know whether it's an initial installation or not, invoke-rc.d and policy-rc.d should just be told so it can make a better decision. (An obvious problem with having a whitelist is then what happens when you purge a package? It won't magically be removed from the whitelist and so you end up in an unwanted situation.) > (We haven't spoken much in person, but I regard you as pretty clever so > am surprised that you describe this as a problem and I feel it so simple > to solve...) The 90% solution is easy, I don't think the 100% solution is that easy. I haven't investigated it deeply though. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87zk8mm1ec@xoog.err.no
Bug#675583: ITP: torrentflux-b4rt -- web-based bittorrent client manager, built on top of torrentflux
Package: wnpp Severity: wishlist Owner: Panayiotis Karabassis * Package name: torrentflux-b4rt Version : 1.0-beta2 Upstream Author : Multiple * URL : http://tf-b4rt.berlios.de/ * License : GPL2 Programming Lang: PHP, Perl Description : web-based bittorrent client manager, built on top of torrentflux -- 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/20120602100505.9599.1744.reportbug@smyrna
Re: Moving /tmp to tmpfs makes it useless
2012/6/2 Carlos Alberto Lopez Perez wrote: > IMHO The logical way of behaving in such situation is to slow-down the > IO bandwidth of the processes that are filling the cache, by sending to > sleep any process that requests more IO while the cache is full instead > of trying to free RAM by swapping out things from the RAM to the swap. > Do you know any way to avoid (or mitigate) this? Perhaps some sysctl > variable? It's already there and it works that way by default: /proc/sys/vm/dirty_* files and vm.dirty_* sysctls. I have the ratio set to 10%, which means, that process will start writing to disk if it filled 10% of memory (note: not FULL cache, just 10% of memory is enough to "slow-down" the process). Of course anybody who don't like these defaults can change them in /etc/sysctl.conf See also: http://www.kernel.org/doc/Documentation/sysctl/vm.txt -- Linux kernel is usually smart enough, 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/CAOVenEpp9XjC7dw8-kTMZwWnMOSAqbkfp6CV9JTz++XO=3t...@mail.gmail.com
Re: Idea: mount /tmp to tmpfs depending on free space and RAM
2012/6/2 Bruce Sass wrote: >> Maintainer will probably write a better code. > Much better... if TMPTIME != 0 it will be necessary to mount the FS based > /tmp, clean it, create a tmpfs, move anything left in /tmp to the tmpfs, > then mount --bind the tmpfs on /tmp. Oh... I was not thinking about TMPTIME. Does it mean that there's no way we can mount /tmp to tmpfs because it breaks TMPTIME? -- 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/CAOVenEqm2ZMcX6yM9njDGeX9xji_=syt7p4t1c2_qezwhbd...@mail.gmail.com
Re: Moving /tmp to tmpfs makes it useless
2012/6/2 Roger Leigh wrote: > These tests were all performed on current unstable using a core2 quad > core system with ext4 and swap on LVM on a 1 TiB MD RAID1 PV, and > Btrfs internally using RAID1 over 2 1TiB partitions. Well, not fair for btrfs, but anyway, finally, some tests! Thank you for doing them. > 1) Checkout of several tags in a git repository > 2) Building a package (sysvinit) These are strange tests. We're not just talking about tmpfs, but about /tmp on tmpfs. Are people expected to use git in /tmp? Or building packages inside /tmp by default? I mean, it may be a good hack for you to mount tmpfs to /mnt/tmpfs and use it for your personal scripts, but why do you use _/tmp_ for that? > 3) Unpacking of a large zip file > 4) Unpacking of large uncompressed tarfile How large were these "large" files?: > unpack 1.2 GiB of data. Hm, it means, that there must be _at_least_ 2GB of RAM and 4GB of swap just for this test to work. Are you sure it's a good *default*? ;) > Without the overhead of uncompression, making it largely CPU bound, > tmpfs is the fastest by far. Hah! And this makes your test the artificial corner case. I mean, default users are not really expected to unpack zip and uncompressed tars to /tmp? (i.e. mc won't unpack them) And personally I haven't ever seen 1+GB zip archives (where did you got it from, just curious, or have you created it just for the test?). > So if you're doing a lot of I/O, tmpfs is unquestionably faster. You're right. But who does a lot of I/O in _/tmp_? Your tests show that if you wrote some scripts doing a lot of I/O it may be nice to make them working on a large tmpfs mounted to i.e. /mnt/tmpfs, but they don't explain why _/tmp_ must be mounted on tmpfs. -- 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/CAOVenEqNCAL8ihiL0Vi9ryW6o3OS3eM=no0QEt+0OxR=1e1...@mail.gmail.com
Re: Maintainer responsible for or only doing maintenance?
On Sat, Jun 2, 2012 at 1:33 AM, Jonas Smedegaard wrote: > Today I find the Maintainer field a joke. Both the Maintainer and Uploaders fields are less than useful for a number of reasons: 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. They are not sufficient to represent reality. While we have some definition in, there are many different styles of maintainership and different levels of commitment. I would like to see Debian get rid of the Maintainer and Uploaders fields and instead implement something like DEP-2 where we have a list of people, what they are willing to work on and the things they are willing to do. For example, as a Debian member with upload privelidges who is part of the games team I could specify that I am willing to fix RC bugs in all packages with Section: games, sponsor updates for packages in Section: games, sponsor new uploads when the meet QA criteria X, am upstream for chromium-bsu and am willing to deal with bugs filed against iotop. People in the security team might say they are willing to fix bugs tagged security on any package in the archive, except for web browser foo. In this way we will get a much more realistic picture of the commitment of the Debian community to the software that we are shipping. Registering this level of detail might not be something individuals are willing to do though. -- bye, pabs http://wiki.debian.org/PaulWise -- 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/CAKTje6HHnndBAULd-zuUk-C=q=shvvtf_2ergej1yffikxz...@mail.gmail.com
Re: why hijacking is bad (and salvaging is good) Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On Saturday 02 June 2012 05:36:04 Thomas Goirand wrote: > 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). No one is perfect, but in this paticular case, I think your good will, patience, complete lack of hostality and desire to communicate the whole issue, has become a victim of what I'd more or less qualify as an unlawful or inappropriate interference. So, thank you for your commitment, and for being that patient and endurant! > I swear its never intended ! :) OMG, I hope we don't need any oath-taking ceremonies any time we try to improve something within Debian. -- pub 4096R/0E4BD0AB -- 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/201206021046.50162.danc...@spnet.net
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On 12-05-31 at 11:05am, Jonas Smedegaard wrote: > Thanks to Daniel Kahn Gilmore for lending me the bike! Gillmor. Sorry! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
