date:20110413

On Wed, 13 Apr 2011 09:05:23 +0300, Andrew O. Shadoura bugzi...@tut.by 
wrote:
 Hello,
 
 I'd like to hear opinions on hwclock.sh operation.
 
 Few thoughts of my own:
 
 i) It's still quite common that battery in the RTC becomes flat.
 In this case, hwclock.sh silently sets system clock to 1970 (or
 whatever else nonsense), efficiently turning file access and modify
 times into a mess, and also causing at least two fscks of the root fs.
 It'd be good if `hwclock.sh stop` stored the current system time in a
 file, and on boot, if the current time (as per RTC) is earlier,
 set the system clock to $storedtime + small-enough-constant, so at
 least the time runs forward. I've implemented this on my local machine
 (I had problems with my RTC for a while) and it worked. And yet more:
 NTP isn't always available, especially whe you're mobile.
 
 ii) Possibly, `hwclock.sh stop` should be run more frequently than just
 once on shutdown, because it sometimes happens that the system doesn't
 shut down correctly. If that happens after some time correction (like
 DST), system time can go wrong, and ntp might not perform the automatic
 correction. Possibly, hwclock saving can be done, for example, once a
 day per anacron, or... any more ideas?

One possibility here would be to look for files that are being routinely
touched anyway (i.e. /var/log/syslog) and taking the most recent of
those as the time to start with.  We could also look at atimes (although
people often mount things we might want to look out for with noatime).

Of course, there are problems with this -- /var is probably not mounted
when hwclock.sh is run and the local admin might have decided to send all
logging via the net, so no files are being touched.

Also we're currently trying to ensure that it's possible to run with a
read-only / (the last of which is likely to cause problems for anything
that needs to touch a file that's available early enough for this to
work).  This is never going to work on systems that are read-only except
for the ramdisks they mount.

I suppose we could make the script look for evidence that something
funny is going on (i.e. if RTC is set to a date before the release date
of the util-linux package, we then hunt for more likely indicators)

We could also re-run hwclock.sh (or a new script) later in the boot if
it was found that the date was bogus in the first place -- we could then
look at the dates on log files, etc.  (with all the same caveats)

 iii) Also, it would be good to hear opinions about negative
 consequences of saving the system time to the RTC on frequent basis.

If you do the simple-minded thing of assuming that the file with the
date in it is correct, then I see a danger that the clock could somehow
get set momentarily into the far future, and then saved, and that every
reboot would then confusingly jump back into the future because that
date still exists in the saved-date file -- hence, I think that it would
be fair enough to have an initial check to see if the system date is
before the date that the util-linux package was built, say, and only
enable this extra code if we're sure that there's a problem -- it cannot
then make things much worse even if it is based on some pretty fragile
assumptions about where we might find a better guess for the date.

Cheers, Phil.

P.S. something like this may be helpful somewhere in your scripting:

  stat --printf='%x\n%y\n%z\n' /var/l??/* /boot/* /etc/* | sort | tail -1
-- 
|)|  Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/
|-|  HANDS.COM Ltd.http://www.uk.debian.org/
|(|  10 Onslow Gardens, South Woodford, London  E18 1NE  ENGLAND


pgpU1tUHFnRbb.pgp
Description: PGP signature

Bug#615153: exec: 58: /usr: Permission denied

2011-04-13 Thread Jonathan Nieder

# Probably not an X bug, but one has to start somewhere.
# Please cc me on replies.
reassign 615153 xserver-xorg
quit

Hi again,

Debian_bug_report wrote[1]:

 Sorry for the delay,

Now it's my turn to apologize.  Our analysts have been very carefully
looking over the information you sent and --- hey, who am I kidding.
In the original report, you wrote:

 So, when I restart my machine
 and try to start my X with the command startx, the system returns the error:
 xinit: connection to X server lost and after said Wait for X server to shut
 down and stayed with prompt flashing again.

but the strace you sent does not show that message[2].  Instead it shows

  X: user not authorized to run the X server, aborting

due to

  open(/etc/X11/Xwrapper.config, O_RDONLY) = -1 EACCES (Permission denied)

What does ls -l /usr/bin/X /etc/X11/Xwrapper.config tell?  For reference,
on my system, it gives

 -rw--- 1 root root  601 Jan 31 08:31 /etc/X11/Xwrapper.config
 -rwsr-sr-x 1 root root 9024 Apr  2 10:23 /usr/bin/X

Notice in particular the setuid (s) bits on X.  Is it the same on yours?
Do you use any unusual filesystem or kernel feature (selinux,
apparmor, etc) that might cause that not to work?

Also for reference I would be interested in the output from
dpkg-query -W xserver-xorg x11-common.

That's all for now.  Hope that helps.

Regards,
Jonathan

[1] http://bugs.debian.org/615153
[2]
 So, I tried invoke X with root and
 I had sucess! When I went to the .xsession-errors I saw this error:

 Xsession: X session started for invisiblemanguard at Ter Fev 22 16:36:02 BRT 
 2011
 exec: 58: /usr: Permission denied

I admit I was more interested in what produces the latter message (so,
sudo strace -f startx) but let's look at your stracelog for the
former.  First, a quick cast of characters:

 $ egrep '^[0-9]*  (clone|exec|wait|... clone)' stracelog | think
 2300 startx
 - 2301 hostname
 - 2302 (startx)
   - 2303 hostname
   - 2304 grep
 - 2305 hostname
 - 2306 mcookie
 - 2307 mktemp
 - 2308 xauth
 - 2309 (startx)
   - 2310 xauth
   - 2311 sed
 - 2312 xauth
 - 2313 (startx)
   - 2314 xauth
   - 2315 sed
 - 2316 xauth
 - 2317 xinit
   - 2318 xserverrc - X
 - 2319 rm

The expected symptom is xinit: connection to X server lost, but
instead we get (from xinit):

  connect(3, {sa_family=AF_INET6, sin6_port=htons(6000), inet_pton(AF_INET6, 
::1, sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 ECONNREFUSED 
(Connection refused)
  [...]
  connect(3, {sa_family=AF_INET, sin_port=htons(6000), 
sin_addr=inet_addr(127.0.0.1)}, 16) = -1 ECONNREFUSED (Connection refused)
  close(3)  = 0
  wait4(2318, [{WIFEXITED(s)  WEXITSTATUS(s) == 1}], WNOHANG, NULL) = 2318
  write(2, xinit: , 7)= 7
  write(2, giving up, 9)  = 9
  write(2, \n, 1) = 1
  write(2, xinit: , 7)= 7
  write(2, unable to connect to X server, 29) = 29
  write(2, : Connection refused\n, 21) = 21

What happened to the server?

  open(/etc/X11/Xwrapper.config, O_RDONLY) = -1 EACCES (Permission denied)
  lstat(/etc/X11/X, {st_mode=S_IFLNK|0777, st_size=13, ...}) = 0
  readlink(/etc/X11/X, /usr/bin/Xorg, 1024) = 13
  access(/etc/X11/X, X_OK)= 0
  getuid()  = 1000
  write(2, X: user not authorized to run th..., 54) = 54
  exit_group(1) = ?

Ah.



-- 
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/20110413075533.GA12757@elie

Processed: Re: exec: 58: /usr: Permission denied

2011-04-13 Thread Debian Bug Tracking System

Processing commands for cont...@bugs.debian.org:

 # Probably not an X bug, but one has to start somewhere.
 # Please cc me on replies.
 reassign 615153 xserver-xorg
Bug #615153 [general] exec: 58: /usr: Permission denied
Bug reassigned from package 'general' to 'xserver-xorg'.
 quit
Stopping processing here.

Please contact me if you need assistance.
-- 
615153: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=615153
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


-- 
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/handler.s.c.130268134915001.transcr...@bugs.debian.org

Re: Bits from the Release Team - Kicking off Wheezy

2011-04-13 Thread sean finney

Hi Raphaël,

On Wed, Apr 13, 2011 at 08:50:04AM +0200, Raphael Hertzog wrote:
 On Sun, 10 Apr 2011, sean finney wrote:
  My suggestion/feedback would be that we find a way where releases aren't
  managed so linearly, and can be be handled in a more parallel manner
  without such disruptive stoppage in unstable.
 
 +1 I also mentionned this in my feedback mail (although much more
 quickly/shortly).
 
  I've been mulling this idea over quite a bit, but with all the CUT
  discussions I've been hesitant to bring it up because it's sort of
  taking things in a different direction.
 
 Why are you thinking this? On the contrary, this is something that was
 suggested to implement the rolling distribution. I would very much like
 to form a group of developers ready to put some work towards this goal.
 And I would be glad if you could be part of it.

I was only 50% at the last DebConf and missed the CUT BoF, but thought
reading blogposts etc afterwards that people weren't as focused on the
branch out stable approach that I'm talking about, and rather were 
more interested in stuff like snapshot testing, alternative testing
from unstable, etc).  But I could be mistaken.

   * create new release
   * instead of freeze, branch testing to new release
   * testing is now release+1 and continues to be fed by unstable[1]
   * use release-proposed-updates for uploader-targeted changes earlier than
 usual.
   * -release team can use $tool[2] to merge/cherry-pick collecitons
 of source packages (rebuild+version bump) and/or binary packages
 (no change).

 While I think this is the long-term goal, it might be more sensible
 to start with rolling and testing in parallel. And I also think it
 requires us to become involved in release matters and to develop
 new tools to streamline the process.

In the way I had thought of things, rolling == testing.  That's to
say that nextstable branches off the main line of development, gets it's
own staging area for updates, and the testing/unstable duo function just as
they did before.  So from what I see we would need the nextstable-testing
area, plugged into the autobuild system, and an independant instance of
the release infrastructure as a starting point.

But either way, i agree tools and processes would need to be hammered
out well in advance, to show that the idea works in practice as well
as principle.  But one of the benefits I see for how I'm proposing
things is that since it doesn't involve any fundamental changes in how
the rest of the project works[1].  It would be very easy to do several
dry run/mock releases where we improve tools/processes and explore
the problem further.


  I guess the real concern here is whether there's enough person-power to 
  handle
  the extra work/overhead.
 
 And also whether release-proposed-updates is workable earlier in the cycle
 as the release manager like to pick updates from unstable because it gives
 some good prior-testing that release-proposed-updates might not provide.

They shouldd still be able to pull from testing/unstable as well, until
it gets to the point that their own freeze criteria prevents them from
migrating in packages.  So that's the same as before.  But being parallel
and all, the delta (and thus likelihood of such conflicts) will by design
grow faster and earlier than it currently does.  Thus the exceptional
case of needing -p-u becomes less exceptional.  So any potential solution
would need to address making that easier to manage as well as ensuring
that there's sufficient people using the p-u/nextstable-testing area.


I don't think I've heard anything back from anyone who's actually on
the release team regarding this, but if they were at least non-comittedly
open to the idea, I'd be willing to throw my hat into the ring to help
put something together.


sean

[1] maybe modulo solving the problem of getting better test coverage on
the nextstable-testing area, if we can't find a good solution for
that, which I'd hope we could.


-- 
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/20110413080643.ga18...@cobija.connexer.com

Bug#622593: ITP: libeval-closure-perl -- Perl module to safely and cleanly create closures via string eval

2011-04-13 Thread Alessandro Ghedini

Package: wnpp
Severity: wishlist
Owner: Alessandro Ghedini al3x...@gmail.com

* Package name: libeval-closure-perl
  Version : 0.03
  Upstream Author : Jesse Luehrs d...@tozt.net
* URL : http://search.cpan.org/dist/Eval-Closure/
* License : GPL-1+ or Artistic
  Programming Lang: Perl
  Description : Perl module to safely and cleanly create closures via 
string eval

 String eval is often used for dynamic code generation. For instance, Moose
 uses it heavily, to generate inlined versions of accessors and constructors,
 which speeds code up at runtime by a significant amount. String eval is not
 without its issues however - it's difficult to control the scope it's used in
 (which determines which variables are in scope inside the eval), and it can
 be quite slow, especially if doing a large number of evals.
 .
 Eval::Closure attempts to solve both of those problems. It provides an
 eval_closure function, which evals a string in a clean environment, other
 than a fixed list of specified variables. It also caches the result of the
 eval, so that doing repeated evals of the same source, even with a different
 environment, will be much faster (but note that the description is part of
 the string to be evaled, so it must also be the same (or non-existent) if
 caching is to work properly).



-- 
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/20110413084514.2658.80077.reportbug@PC-Ale.WAG300N

Re: network-manager as default? No!

2011-04-13 Thread Bernd Zeimetz

On 04/04/2011 12:56 PM, Jon Dowland wrote:
 On Sun, Apr 03, 2011 at 07:22:47PM +0300, Faidon Liambotis wrote:
 It also can't do VLANs (.1q), bridges, bonds and all possible  
 permutations of the above. I'd speculate that it also wouldn't be able  
 to do things like 1k (or more) interfaces. It also doesn't support hooks  
 to be able to do more advanced setups, such as multihoming, policy  
 routing, QoS, etc.
 
 Is it necessary for the distribution's *default* network-management solution 
 to
 handle all of these? 

Yes. For a distribution which is targeted to support servers properly, yes,
definitely. For everything else there is Ubuntu.


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprints: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F


-- 
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/4da56479.60...@bzed.de

only servers pfff (Was: Re: network-manager as default? No!)

2011-04-13 Thread Martin Bagge / brother

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2011-04-13 10:53, Bernd Zeimetz wrote:
 Yes. For a distribution which is targeted to support servers properly, yes,
 definitely. For everything else there is Ubuntu.

The universal OS is only running on servers. Check.

- -- 
brother
http://sis.bthstudent.se
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBCAAGBQJNpWUuAAoJEJbdSEaj0jV7Fc4H/i0dTHQTnQH93lFMbrw1Tzi2
RKAwVHoh04tmzb0+td/TVNHOe/D9AG7KYcOPHC1Wn9oUewSI2/jF9CtTV8axPi1N
6r1k1C951rGMUF1AVG9MWkiGs9pqEgqZ124hv1XnlXXetg5hLw3vqGsE7pA3DPsk
wGcJDjx0HNyN8hW4pJ+aDojNxy75eDtahX3bzi/dBPe6cCqi92diRtjWrEvy0kON
sBflPRmz6drCLFAXqHaw8uX7QqH+31g/EIMRVUMgMS7N9K24qy3bTIEDBZtiCwxg
yMwYTZauvq9Q462rfk770/6k0wuFwX9SiQvFl1CkO593j3WJLJ3zvy4Ycv1yZoY=
=qPaT
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4da5652e.90...@bsnet.se

Re: [Pkg-samba-maint] Default size limits for /run (/var/run) and /run/lock (/var/lock)

2011-04-13 Thread Stig Sandbeck Mathisen

Roger Leigh rle...@codelibre.net writes:

 One reason for doing this is to have a single writable mount on the
 system, which might be useful for tiny systems with minimal resources,
 where root is r/o. On such a system, it might be useful to pool the
 limited writable space (which might not be a tmpfs).

Could this case be handled better by the fsprotect package?

-- 
Stig Sandbeck Mathisen s...@debian.org


pgpZY6Bxgti27.pgp
Description: PGP signature

Re: [Pkg-samba-maint] Default size limits for /run (/var/run) and /run/lock (/var/lock)

On Wed, Apr 13, 2011 at 10:29:16AM +0200, Stig Sandbeck Mathisen wrote:
 Roger Leigh rle...@codelibre.net writes:
 
  One reason for doing this is to have a single writable mount on the
  system, which might be useful for tiny systems with minimal resources,
  where root is r/o. On such a system, it might be useful to pool the
  limited writable space (which might not be a tmpfs).
 
 Could this case be handled better by the fsprotect package?

It's a nice idea, but for a somewhat different purpose.  This is
overlaying the read-only root with a writable overlay.  Where I'd
like to get to is a purely read-only setup where nothing is writing
to e.g. /etc.  fsprotect could be considered to be working around
deficiencies with our current situation, where I would like to
fix the underlying problems making an aufs overlay necessary in the
first place.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


signature.asc
Description: Digital signature

Re: network-manager as default? No!

2011-04-13 Thread sean finney

On Mon, Apr 04, 2011 at 11:56:23AM +0100, Jon Dowland wrote:
 On Sun, Apr 03, 2011 at 07:22:47PM +0300, Faidon Liambotis wrote:
  It also can't do VLANs (.1q), bridges, bonds and all possible  
  permutations of the above. I'd speculate that it also wouldn't be able  
  to do things like 1k (or more) interfaces. It also doesn't support hooks  
  to be able to do more advanced setups, such as multihoming, policy  
  routing, QoS, etc.
 
 Is it necessary for the distribution's *default* network-management solution 
 to
 handle all of these?  If it could be easily substituted for another solution
 that was better suited to tasks which a majority of users will not use, then
 surely that is fine.
 
 (although I'd like to get NM and bridging working more nicely personally, I
  consider this more of a feature bug than an RC one)

Except that it'd also be a regression from what's possible on current
default server installs, since it already works.  And any regression should
be countered by strong motivation for why it's important to throw the baby
out with the bathwater, and hopefully some plans for going and finding the
baby later on.

Did i miss the part where somebody explained what the user benefit of having
network-manager on a server was? (apart from then it's the same as your
desktop[1], anyway).


sean

[1] although it isn't, unless you're installing gnome on your server, but then
you're installing a desktop not a server, and you'd get it by default
anyway, and then what's the point?


-- 
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/20110413091127.ga19...@cobija.connexer.com

Re: Default size limits for /run (/var/run) and /run/lock (/var/lock)

On Tue, Apr 12, 2011 at 12:38:03PM +0100, Roger Leigh wrote:
 On Mon, Apr 11, 2011 at 08:01:42PM +0100, Roger Leigh wrote:
  With the transition to /run and /run/lock as tmpfs filesystems, it
  would be desirable to provide sensible default size limits.  Currently,
  we default to the tmpfs default of ½ RAM.  But with several tmpfs
  filesystems, this does have the potential for the system to be OOMed
  by a user filling up more than one of the filesystems.  A sensible
  default size limit would be useful here, for at least some of the
  filesystems.
  
  We currently allow specification of size limits for:
  /run (RUN_SIZE)
  /run/lock (LOCK_SIZE, optional)
  /dev/shm (SHM_SIZE)
  /tmp (TMP_SIZE, optional)
  
  [from temporary git repo at 
  http://git.debian.org/?p=collab-maint/sysvinit;a=summary]
  
  In order to default to a sensible size, I would appreciate it if I
  could have some figures for the useage of these filesystems: e.g.
  
  % sudo du -sk /var/run /var/lock /dev/shm
 
 OK, some results:
 
 /var/run  /var/lock  /dev/shm
 Min9 0 0
 5% percentile 60 0 0
 Mean 886 9   599
 Median   120 8 0
 95% percentile   61217   310
 Max4769652 80744

Following the discussion yesterday, I'd like to propose doing
something like the example below.  It's possible to size a tmpfs
as a percentage of core memory, the default being -o size=50%.
Rather than setting an absolute value, we can size e.g. /run
as a percentage of total memory, which should scale with /run
usage better than a fixed value.

Proposal:
Switch the default for all tmpfs mounts from 50% to 20%; it's
still very large, but you have to mount many more to be able to
break your system.
/run: Use 10% core.  This gives 102MiB on 1GiB system; the largest
observed user used 50MiB.  Even a system with 512MiB would not have
hit the observed maximum, and that was a very large system with
presumably more memory than this.
/run/lock and /lib/init/rw: 5MiB each.  More than plenty, but far
less than current usage.
/run/shm: No default (use general tmpfs default of 20%)
/tmp: No default (use general tmpfs default of 20%)


Regards,
Roger


---
[/etc/default/tmpfs]

# Defaults for tmpfs filesystems mounted in early boot, before
# filesystems from /etc/fstab are mounted.
#
# _SIZE variables are the maximum size (in bytes) that tmpfs
# filesystems can use.  The size will be rounded down to a multiple of
# the page size, 4096 bytes.  If no size is set, TMPFS_SIZE will be
# used as the default.  _MODE variables are the initial access
# permissions for the root of the tmpfs mount.  If no mode is set,
# TMPFS_MODE will be used as the default.

# TMPFS_SIZE: maximum size for all tmpfs filesystems if no specific
# size is provided.  If no value is provided here, the kernel default
# will be used.
TMPFS_SIZE=20%
TMPFS_MODE=755

# RUN_SIZE: maximum size of /run (/var/run)
#
# Defaults to 10% core memory; the size required varies widely
# depending upon the demands of the software being run; this heuristic
# scales /run usage on system size.  Samba in particular has been seen
# to use at least 50MiB in a large heavily used server.  Typical usage
# is hundreds of KiB, maximum is tens of MiB.
RUN_SIZE=10%
RUN_MODE=755

# LOCK_SIZE: maximum size of /run/lock (/var/lock)
#
# Typical usage: tens of KiB; maximum hundreds of KiB.  Default of
# 5MiB should ensure the limit is never reached.
LOCK_SIZE=5242880 # 5MiB
LOCK_MODE=1777

# SHM_SIZE: maximum size of /run/shm (/dev/shm)
#
# No default size; the size required varies widely depending upon the
# demands of the software being run.
SHM_SIZE=
SHM_MODE=1777

# TMP_SIZE: maximum size of /tmp
#
# No default size.
TMP_SIZE=
TMP_MODE=1777

# RW_SIZE: maximum size of /lib/init/rw
#
# Note /lib/init/rw is deprecated and programs using is are migrating
# to use /run.  It will be removed once all users have migrated to
# /run.
# Typical usage: tens of KiB.  Default of 5MiB should ensure the limit
# is never reached.
RW_SIZE=5242880 # 5 MiB
RW_MODE=755


-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


signature.asc
Description: Digital signature

Re: network-manager as default? No!

2011-04-13 Thread Stephan Seitz


On Wed, Apr 13, 2011 at 11:11:27AM +0200, sean finney wrote:
Did i miss the part where somebody explained what the user benefit of 
having network-manager on a server was? (apart from then it's the same 
as your desktop[1], anyway).


I don’t even know why NM should be on a normal desktop.
My first (and last) contact with NM was not a good one. I was doing 
a remote upgrade of a desktop and suddenly the system was unreachable.  
After a reboot it worked, but shortly the system was unreachable again.  
Then I noticed that the default gateway was missing. The desktop didn’t 
have a configured eth0, but two configured vlan interfaces. NM thought, 
hey let’s configure eth0, and tried to configure eth0 via DHCP and 
deleted the default gateway. Since then, the first thing I do is to 
disable this crap. Besides I don’t have any desktop with WLAN interface.  
So ifupdown is more than enough to configure the network.


Some people say that NM is good with WLAN. Maybe. Since I don’t touch NM 
again, I always used ifupdown and wpasupplicant with success. But 
I rarely use WLAN. If NM is really good with WLAN it should only be part 
of the laptop task and never touch cable networks.


The only thing that I miss from ifupdown (and I configured bonds, bridges 
and vlans) is a good IPv6 support. I can’t separately activate or 
deactivate IPv4 or IPv6 parts of an interface.


Shade and sweet water!

Stephan

--
| Stephan Seitz E-Mail: s...@fsing.rootsland.net |
| PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html |


signature.asc
Description: Digital signature

Re: rock around hwclock.sh

2011-04-13 Thread Adrian von Bidder

On Wednesday 13 April 2011 08.05:23 Andrew O. Shadoura wrote:
 ii) Possibly, `hwclock.sh stop` should be run more frequently than just
 once on shutdown, because it sometimes happens that the system doesn't
 shut down correctly. If that happens after some time correction (like
 DST), system time can go wrong, and ntp might not perform the automatic
 correction. Possibly, hwclock saving can be done, for example, once a
 day per anacron, or... any more ideas?

run hwclock stop only at shutdown, but set system clock to latest(rtc, 
hwclock stored time + delta, /var/log/syslog + delta) at boot?

I am aware that not everybody has /var/log/syslog in heavily customized 
installs, but if it's there, it's usually occasionally written to. And using 
that is certainly faster than find most recently modified file on all 
filesystems :-)

-- vbi

-- 
featured product: ClamAV Antivirus - http://www.clamav.net/


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

Re: only servers pfff (Was: Re: network-manager as default? No!)

2011-04-13 Thread Bernd Zeimetz

On 04/13/2011 10:56 AM, Martin Bagge / brother wrote:
 On 2011-04-13 10:53, Bernd Zeimetz wrote:
 Yes. For a distribution which is targeted to support servers properly, yes,
 definitely. For everything else there is Ubuntu.
 
 The universal OS is only running on servers. Check.

Get your facts straight. Targeted to support servers properly does not
mean only on servers.

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprints: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F


-- 
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/4da5739c.2020...@bzed.de

Re: Default size limits for /run (/var/run) and /run/lock (/var/lock)

2011-04-13 Thread Thomas Hood

First of all, thanks to Roger Leigh for leading this effort.

Roger Leigh wrote:
 Proposal:
 Switch the default for all tmpfs mounts from 50% to 20%; it's
 still very large, but you have to mount many more to be able to
 break your system.


He should have said ... but you have to mount *and fill* many more
to be able to break your system.

The current tmpfs size of 50% suffices to protect the system should
any *one* tmpfs be completely filled by a wayward process.  Is that
not good enough?  I.e., do we really need to worry about the case
where multiple tmpfses get filled simultaneously?

Does it matter whether the system fails due to filesystem full or
due to OOM?  Broken is broken.

If we do need to worry about that case then the real solution is
not arbitrarily to increase the number-of-tmpfses-to-fill-up-in-
order-to-break-the-system from 2 to 5.  One real solution is to
limit the total amount of memory that all tmpfses can take up to
some value less than 100%.  Another is to look more closely at which
tmpfses could reasonably be attacked and limit the sum of *their*
sizes to something less than 100%.
-- 
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/4da576b3.7010...@gmail.com

Re: Default size limits for /run (/var/run) and /run/lock (/var/lock)

On Tue, 12 Apr 2011 13:51:09 +0200, Michael Biebl bi...@debian.org wrote:
 Am 12.04.2011 13:38, schrieb Roger Leigh:
 
  this for /var/lock (/run/lock), which can be mounted as a separate
  tmpfs on /run/lock if RAMLOCK is set in /etc/defaults/rcS.  We could
  also do the same for /dev/shm (/run/shm) and /tmp (/run/tmp) as well.
  In the case of /tmp this would not be the default except when root is
  read-only.
 
 I don't think symlinking /tmp to /run would be a good idea, as one could fill 
 up
 /tmp (accidentaly)  pretty quick.
 If we want to make / ro, then a separate tmpfs for /tmp looks like a better 
 idea
 to me.

While were about this, for installs where the users select multiple
partitions we currently create a separate /tmp partition.

This strikes me as suboptimal, since one could use the disk space
allocated to /tmp as extra swap and then allocate a tmpfs of that size
to be mounted on /tmp with no effect other than allowing the system to
have access to more swap than it would have otherwise had (of course,
that's probably more than it needs, so instead you could just save some
disk space that would otherwise be left generally unused by overloading
the swap usage with /tmp usage.

Therefore, in the multi-partition setup, I think we should also default
to having /tmp on tmpfs.

Cheers, Phil.
-- 
|)|  Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/
|-|  HANDS.COM Ltd.http://www.uk.debian.org/
|(|  10 Onslow Gardens, South Woodford, London  E18 1NE  ENGLAND


pgpsRy7739Pbe.pgp
Description: PGP signature

Re: Default size limits for /run (/var/run) and /run/lock (/var/lock)

2011-04-13 Thread Bastian Blank

On Tue, Apr 12, 2011 at 09:30:53PM +0200, Jan Hauke Rahm wrote:
 On Tue, Apr 12, 2011 at 08:21:25PM +0100, Roger Leigh wrote:
  I know little about vservers.  How do they currently deal with
  /dev/shm and /lib/init/rw?
 Interesting question. Actually, in my setup, I don't see /dev/shm at
 all and /lib/init/rw is a regular directory.

They don't. / is writable.

Bastian

-- 
Insufficient facts always invite danger.
-- Spock, Space Seed, stardate 3141.9


-- 
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/20110413111310.ga29...@wavehammer.waldi.eu.org

Re: Default size limits for /run (/var/run) and /run/lock (/var/lock)

On Wed, Apr 13, 2011 at 10:51:50AM +0100, Philip Hands wrote:
 On Tue, 12 Apr 2011 13:51:09 +0200, Michael Biebl bi...@debian.org wrote:
  I don't think symlinking /tmp to /run would be a good idea, as one could 
  fill up
  /tmp (accidentaly)  pretty quick.
  If we want to make / ro, then a separate tmpfs for /tmp looks like a better 
  idea
  to me.
 
 While were about this, for installs where the users select multiple
 partitions we currently create a separate /tmp partition.
 
 This strikes me as suboptimal, since one could use the disk space
 allocated to /tmp as extra swap and then allocate a tmpfs of that size
 to be mounted on /tmp with no effect other than allowing the system to
 have access to more swap than it would have otherwise had (of course,
 that's probably more than it needs, so instead you could just save some
 disk space that would otherwise be left generally unused by overloading
 the swap usage with /tmp usage.
 
 Therefore, in the multi-partition setup, I think we should also default
 to having /tmp on tmpfs.

Sounds like a great idea.  I'd extend it to any setups with a swap.

Tmpfs is a lot faster than regular filesystems: it doesn't have to care
about preserving the data's integrity after a crash and thus has no
barriers, journaling, fsync().  When there's plenty of unused memory, the
data will not ever touch the disk, too -- gracefully getting written out
when there is a better use for memory it takes.  Since most files in /tmp/
are very short lived, it's a good optimization.

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


signature.asc
Description: Digital signature

Re: network-manager as default? No!

2011-04-13 Thread Felipe Sateler

On Wed, 13 Apr 2011 10:53:13 +0200, Bernd Zeimetz wrote:

 On 04/04/2011 12:56 PM, Jon Dowland wrote:
 On Sun, Apr 03, 2011 at 07:22:47PM +0300, Faidon Liambotis wrote:
 It also can't do VLANs (.1q), bridges, bonds and all possible
 permutations of the above. I'd speculate that it also wouldn't be able
 to do things like 1k (or more) interfaces. It also doesn't support
 hooks to be able to do more advanced setups, such as multihoming,
 policy routing, QoS, etc.
 
 Is it necessary for the distribution's *default* network-management
 solution to handle all of these?
 
 Yes. For a distribution which is targeted to support servers properly,
 yes, definitely. For everything else there is Ubuntu.

Surely a person managing a server can do aptitude install ifupdown 
network-manager-?



-- 
Saludos,
Felipe Sateler


-- 
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/io418e$1pq$1...@dough.gmane.org

Re: network-manager as default? No!

On Wed, Apr 13, 2011 at 11:26:06AM +, Felipe Sateler wrote:
 On Wed, 13 Apr 2011 10:53:13 +0200, Bernd Zeimetz wrote:
  Yes. For a distribution which is targeted to support servers properly,
  yes, definitely. For everything else there is Ubuntu.
 
 Surely a person managing a server can do aptitude install ifupdown 
 network-manager-?

No, unless you are physically at the keyboard at the time.

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


signature.asc
Description: Digital signature

Re: Default size limits for /run (/var/run) and /run/lock (/var/lock)

2011-04-13 Thread Bernhard R. Link

* Philip Hands p...@hands.com [110413 12:54]:
 This strikes me as suboptimal, since one could use the disk space
 allocated to /tmp as extra swap and then allocate a tmpfs of that size
 to be mounted on /tmp with no effect other than allowing the system to
 have access to more swap than it would have otherwise had (of course,
 that's probably more than it needs, so instead you could just save some
 disk space that would otherwise be left generally unused by overloading
 the swap usage with /tmp usage.

 Therefore, in the multi-partition setup, I think we should also default
 to having /tmp on tmpfs.

This has both the disadvantage of a system then having swap (given the
big memory sizes one currently has and the big difference between RAM
and disk access times, having swap is often quite a disadvantage) and
of mixing several different things (/tmp is usually something simply
filling over time, so without low enough limits one risks that something
important is sometime not working because of missing RAM).

Bernhard R. Link


-- 
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/20110413113412.ga3...@pcpool00.mathematik.uni-freiburg.de

Re: network-manager as default? No!

2011-04-13 Thread Mehdi Dogguy


On 13/04/2011 10:53, Bernd Zeimetz wrote:

On 04/04/2011 12:56 PM, Jon Dowland wrote:

On Sun, Apr 03, 2011 at 07:22:47PM +0300, Faidon Liambotis wrote:

It also can't do VLANs (.1q), bridges, bonds and all possible
permutations of the above. I'd speculate that it also wouldn't be
able to do things like 1k (or more) interfaces. It also doesn't
support hooks to be able to do more advanced setups, such as
multihoming, policy routing, QoS, etc.


Is it necessary for the distribution's *default* network-management
solution to handle all of these?


Yes. For a distribution which is targeted to support servers properly,
 yes, definitely. For everything else there is Ubuntu.



I sincerely hope that you're joking… At least, the rest of the project
doesn't share this view. It's like saying that Desktop users are second
class citizens, which is plain wrong!

Regards,

--
Mehdi Dogguy مهدي الدڤي
http://dogguy.org/


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

Re: Question about the version of debian

On Wed, 2011-04-13 at 13:44 +0800, Asias He wrote:
 On Wed, Apr 13, 2011 at 12:32 PM, YANG,Chao yor...@ust.hk wrote:
  Dear Sir,
Recently, I downloaded a 32bit version of Debian from the following
  website:
 
  http://cdimage.debian.org/debian-cd/6.0.1a/i386/iso-dvd/
 
However, after finishing installation, I found that the 32bit OS
  turned out to be amd-64bit:
uname -a
Linux my-computer 2.6.32-5-amd64 #1 SMP Tue Mar 8 22:49:26 UTC 2011
  x86_64 GNU/Linux
 
 Can you post:
 
 $ dpkg -l|grep linux-image
 
 in your system.
 
 Did you have a 64-bit kernel installed on a 32-bit host.

'dpkg-architecture -qDEB_HOST_ARCH' will show which architecture the
rest of the system uses.

A 64-bit kernel is not supposed to be automatically selected, but it
could be if the system has 4 GB RAM and the '686-bigmem' flavour is not
available for some reason.

Please use 'reportbug installation-report' to provide more information.
The debian-devel list is not the place to send bug reports.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


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

Re: Bits from the Release Team - Kicking off Wheezy

2011-04-13 Thread Raphael Hertzog

On Wed, 13 Apr 2011, sean finney wrote:
I was only 50% at the last DebConf and missed the CUT BoF, but thought

I missed the BoF too (I was not at DebConf).

reading blogposts etc afterwards that people weren't as focused on the
branch out stable approach that I'm talking about, and rather were
more interested in stuff like snapshot testing, alternative testing
from unstable, etc). But I could be mistaken.

There's clearly 2 sides to CUT:
- provide regular snapshots with a working installer
- rolling, aka make testing suitable for end-users and something that
never freezes

The summary article I wrote some time ago presents both aspects:
http://raphaelhertzog.com/2010/10/04/can-debian-offer-a-constantly-usable-testing-distribution/

While I think this is the long-term goal, it might be more sensible
to start with rolling and testing in parallel. And I also think it
requires us to become involved in release matters and to develop
new tools to streamline the process.

In the way I had thought of things, rolling == testing. That's to
say that nextstable branches off the main line of development, gets it's
own staging area for updates, and the testing/unstable duo function just as
they did before. So from what I see we would need the nextstable-testing
area, plugged into the autobuild system, and an independant instance of
the release infrastructure as a starting point.

Is the nexstable staging area the same as release-proposed-updates
in your view ?

Or would there be a britney moving stuff from your staging area to
nextstable ?

I don't think I've heard anything back from anyone who's actually on
the release team regarding this, but if they were at least non-comittedly
open to the idea, I'd be willing to throw my hat into the ring to help
put something together.

Yeah, it would be great to have some feedback from RT team members. I
tried to get some indirectly when I interviewed Meddi Dogguy and Adam D.
Barratt:
http://raphaelhertzog.com/2011/04/07/people-behind-debian-adam-d-barratt-release-manager/
http://raphaelhertzog.com/2010/12/23/people-behind-debian-mehdi-dogguy-release-assistant/

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)

--
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/20110413122138.gd3...@rivendell.home.ouaza.com

Re: network-manager as default? No!

2011-04-13 Thread Jan Hauke Rahm

On Wed, Apr 13, 2011 at 01:42:43PM +0200, Mehdi Dogguy wrote:
 On 13/04/2011 10:53, Bernd Zeimetz wrote:
 On 04/04/2011 12:56 PM, Jon Dowland wrote:
 On Sun, Apr 03, 2011 at 07:22:47PM +0300, Faidon Liambotis wrote:
 It also can't do VLANs (.1q), bridges, bonds and all possible
 permutations of the above. I'd speculate that it also wouldn't be
 able to do things like 1k (or more) interfaces. It also doesn't
 support hooks to be able to do more advanced setups, such as
 multihoming, policy routing, QoS, etc.
 
 Is it necessary for the distribution's *default* network-management
 solution to handle all of these?
 
 Yes. For a distribution which is targeted to support servers properly,
  yes, definitely. For everything else there is Ubuntu.
 
 
 I sincerely hope that you're joking… At least, the rest of the project
 doesn't share this view. It's like saying that Desktop users are second
 class citizens, which is plain wrong!

He didn't say anything you're implying. Some misunderstanding, I guess.
Debian, as a universal OS, needs to support Servers and Desktops and ...
properly. Any solution thus needs to handle all those cases properly.

Then add the usual Ubuntu bashing: for all who don't need that kind of
universality, there's Ubuntu (which, btw, also delivers server
solutions).

No-one is second class. Or, if I understand bzed right, Ubuntu is. :)

Hauke

-- 
 .''`.   Jan Hauke Rahm j...@debian.org   www.jhr-online.de
: :'  :  Debian Developer www.debian.org
`. `'`   Member of the Linux Foundationwww.linux.com
  `- Fellow of the Free Software Foundation Europe  www.fsfe.org


signature.asc
Description: Digital signature

Re: Default size limits for /run (/var/run) and /run/lock (/var/lock)

On Wed, 2011-04-13 at 13:34 +0200, Bernhard R. Link wrote:
 * Philip Hands p...@hands.com [110413 12:54]:
  This strikes me as suboptimal, since one could use the disk space
  allocated to /tmp as extra swap and then allocate a tmpfs of that size
  to be mounted on /tmp with no effect other than allowing the system to
  have access to more swap than it would have otherwise had (of course,
  that's probably more than it needs, so instead you could just save some
  disk space that would otherwise be left generally unused by overloading
  the swap usage with /tmp usage.
 
  Therefore, in the multi-partition setup, I think we should also default
  to having /tmp on tmpfs.
 
 This has both the disadvantage of a system then having swap (given the
 big memory sizes one currently has and the big difference between RAM
 and disk access times, having swap is often quite a disadvantage)
[...]

Under Linux, swap space is a requirement to defragment RAM.  (This may
change in the future.)  Without swap space, the kernel eventually
becomes unable to make large physically-contiguous allocations.  Don't
turn it off.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


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

Re: Question about the version of debian

2011-04-13 Thread Raphael Hertzog

On Wed, 13 Apr 2011, Ben Hutchings wrote:
 'dpkg-architecture -qDEB_HOST_ARCH' will show which architecture the
 rest of the system uses.

dpkg --print-architecture is better suited (dpkg-architecture is a
dpkg-dev script).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
  ▶ http://RaphaelHertzog.fr (Français)


-- 
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/20110413122736.ge3...@rivendell.home.ouaza.com

Bug#622619: ITP: libjsyntaxpane-java -- Java EditorPane with support for Syntax Highlighting

2011-04-13 Thread Martin Quinson

Package: wnpp
Severity: wishlist
Owner: Martin Quinson mquin...@debian.org

* Package name: libjsyntaxpane-java
  Version : 0.9.5~svn148
  Upstream Author : Ayman Al-Sairafi (ayman.alsair...@gmail.com)
* URL : http://code.google.com/p/jsyntaxpane/
* License : Apache-2.0
  Programming Lang: Java
  Description : Java EditorPane with support for Syntax Highlighting

JSyntaxPane provides you with a very simple to use, and now with
simple method to configure, way to handle simple Syntax Highlighting
and editing of various languages within your Java Swing application.

Currently supported out of the box are Java, JavaScript, Properties,
Groovy, C, C++, XML, SQL, Ruby and Python. 


**
Upstream does not distribute any source package, so I had to get it
from the svn directly. The prefered version is 0.9.5, but it is not
released yet, with some beta versions distributed (in binary version)
since one year and half. There is no tag in this branch pointing to
where the binary version were taken. This explain the strange version
number I've picked. I hope it's ok.

I'm packaging it as a dependency to JLM (see #622324).

The current version of the package is at
git://git.debian.org/pkg-java/libjsyntaxpane-java.git
(empty right now, soon populated)



-- 
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/20110413124554.20231.73409.report...@arthur.loria.fr

Bug#622620: O: argyll -- Color Management System, calibrator and profiler

2011-04-13 Thread Roland Mas

Package: wnpp
Severity: normal

I think it's time for me to stop pretending I have enough
time/energy/interest to properly maintain Argyll.  I'm therefore
regretfully orphaning the package.

  Prospective adopters: most of the difficulty I've had in maintaining
this package comes from my switch of build system from Jam to
Autoconf/Automake/Libtool.  If you can live with Jam, then you'll
probably have an easier job.

  I'm quite prepared to offer sponsorship and/or guidance to anyone
willing to adopt the package and needing one or the other.

Roland.
-- 
Roland Mas

La menace de la baffe pèse plus lourd que la baffe elle-même.
  -- in Sri Raoul le petit yogi (Gaudelette)



--
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/87oc4ae2uj@mirexpress.internal.placard.fr.eu.org

Request for testing: /run and initscripts

On Wed, Apr 13, 2011 at 01:23:04PM +0200, Adam Borowski wrote:
 On Wed, Apr 13, 2011 at 10:51:50AM +0100, Philip Hands wrote:
  On Tue, 12 Apr 2011 13:51:09 +0200, Michael Biebl bi...@debian.org wrote:
   I don't think symlinking /tmp to /run would be a good idea, as one could 
   fill up
   /tmp (accidentaly)  pretty quick.
   If we want to make / ro, then a separate tmpfs for /tmp looks like a 
   better idea
   to me.
  
  While were about this, for installs where the users select multiple
  partitions we currently create a separate /tmp partition.
  
  This strikes me as suboptimal, since one could use the disk space
  allocated to /tmp as extra swap and then allocate a tmpfs of that size
  to be mounted on /tmp with no effect other than allowing the system to
  have access to more swap than it would have otherwise had (of course,
  that's probably more than it needs, so instead you could just save some
  disk space that would otherwise be left generally unused by overloading
  the swap usage with /tmp usage.
  
  Therefore, in the multi-partition setup, I think we should also default
  to having /tmp on tmpfs.
 
 Sounds like a great idea.  I'd extend it to any setups with a swap.
 
 Tmpfs is a lot faster than regular filesystems: it doesn't have to care
 about preserving the data's integrity after a crash and thus has no
 barriers, journaling, fsync().  When there's plenty of unused memory, the
 data will not ever touch the disk, too -- gracefully getting written out
 when there is a better use for memory it takes.  Since most files in /tmp/
 are very short lived, it's a good optimization.

I have now implemented this (though it's not the default).

I would very much appreciate it if anyone could take the time to
install the new initscripts and test it out.

http://people.debian.org/~rleigh/run/sysvinit_2.88dsf-13.3.dsc
http://people.debian.org/~rleigh/run/initscripts_2.88dsf-13.3_amd64.deb

Note that it is safe to test these out on live systems; I've
installed it on my amd64 and powerpc machines, and not had any
issues.  I did notice an unclean umount of /var in one case,
but I think this was due to messing around with mount --move
which messes up /etc/mtab when moving recursively (/run/lock
probably didn't get unmounted).  I've not seen that on any other
systems.


So, by default, you get (separate tmpfs mounts):
/run
/run/shm
/lib/init/rw

(RAMLOCK=no, RAMSHM=yes, RAMTMP=no)

For additional safety and security, it's possible to mount everything
as separate tmpfs filesystems:

/run
/run/shm
/run/lock
/lib/init/rw
/tmp

(RAMLOCK=yes, RAMSHM=yes, RAMTMP=yes).  This lets one have separate
size limits and mount modes for each mount.

Alternatively, it's possible to have everything on a single /run
tmpfs, including /tmp (excluding /lib/init/rw, which will be
removed soon):

/run
/lib/init/rw
/tmp → /run/tmp

(RAMLOCK=no, RAMSHM=no, RAMTMP=no).  Note that /tmp was symlinked
to /run/tmp prior to restarting, and /run/tmp was created by the
init scripts (mountkernfs).  The symlink needs creating by hand
should you wish to do this.  Having /tmp as a symlink can be used
whatever the setting of RAMTMP, so you could have a tmpfs mounted
on /run/tmp if you chose.

In all these cases, these links were automatically created:
/dev/shm → /run/shm
/var/run → /run
/var/lock → /run/lock

The default size and permissions were set as proposed earlier in this
thread; there's still time to adjust or remove those depending upon
what the general consensus is.  We could also make not mounting
/run/shm the default, so that it's shared with /run by default; users
who need a dedicated large /run/shm could then enable this at their
discretion using RAMSHM and SHM_SIZE.


I would be very grateful to anyone who can take the time to install
the new initscripts and try it out.  It should set up bind mounts
of /var/run, /var/lock and /dev/shm to their locations in /run on
installation, and then set up the tmpfs filesystems properly and
do the conversion to symlinks on reboot.

Note that I did discuss doing this migration all in postinst using
mount --move with mbiebl, but it's unfortuntately linux-specific
and has some race conditions between moving and setting up the
symlinks (which may or may not be acceptable).  This patch errs on the
side of caution and ensures that the directories being moved are
available at all times, and that the code works on all architectures.

Also note that the move of /dev/shm to /run/shm might require the
selinux stuff tweaking.  This might require a change in one of the
selinux packages.  But I know little about selinux.

One oddity I noticed was that /etc/default/rcS is not a conffile,
making it difficult to add new options on upgrade since it's only
copied once on initial install.  Does anyone know why this is the
case, and would it be a problem if I made it into a conffile in
order to add the new RAMSHM and RAMTMP options (and remove RAMRUN)?
I've worked around this by setting defaults if unset in

Re: network-manager as default? No!

On Wed, 13 Apr 2011 11:26:06 + (UTC), Felipe Sateler fsate...@debian.org 
wrote:
 On Wed, 13 Apr 2011 10:53:13 +0200, Bernd Zeimetz wrote:
 
  On 04/04/2011 12:56 PM, Jon Dowland wrote:
  On Sun, Apr 03, 2011 at 07:22:47PM +0300, Faidon Liambotis wrote:
  It also can't do VLANs (.1q), bridges, bonds and all possible
  permutations of the above. I'd speculate that it also wouldn't be able
  to do things like 1k (or more) interfaces. It also doesn't support
  hooks to be able to do more advanced setups, such as multihoming,
  policy routing, QoS, etc.
  
  Is it necessary for the distribution's *default* network-management
  solution to handle all of these?
  
  Yes. For a distribution which is targeted to support servers properly,
  yes, definitely. For everything else there is Ubuntu.
 
 Surely a person managing a server can do aptitude install ifupdown 
 network-manager-?

You appear to want to inflict extra work on large swathes of our
users.  If that is the case, I'd like to see some sort of justification
for that.

What is it that installing N-M on servers will gain us or our users?

I don't perceive the advantage. Many other people in this thread don't
seem to perceive it.  I don't believe that anyone's even hinted at the
advantage, but perhaps I missed it.

In the absence of such justification, I don't see what's wrong with the
status quo (i.e. N-M on Gnome desktops by default, ifupdown elsewhere by
default, with both choices entirely overridable by the user)

Cheers, Phil.
-- 
|)|  Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/
|-|  HANDS.COM Ltd.http://www.uk.debian.org/
|(|  10 Onslow Gardens, South Woodford, London  E18 1NE  ENGLAND


pgpNE97l5E8wG.pgp
Description: PGP signature

Re: Question about the version of debian

On Wed, 2011-04-13 at 20:47 +0800, YANG,Chao wrote:
 dpkg --print-architecture shows
 i386.
 
 However, uname -a shows
 x86-64
 
 what does this mean?

It means Asias He was right.  And this is a perfectly valid
configuration (though it confuses some third-party installers).

But I think this is a bug in the configuration of the CD/DVD creation:
the amd64 flavour is on DVD 1 but the 686-bigmem flavour is on DVD 2.
The latter definitely should be on DVD 1 (and CD 1 or 2, rather than CD
10!).

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


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

Re: Question about the version of debian

2011-04-13 Thread YANG,Chao

dpkg --print-architecture shows
i386.

However, uname -a shows
x86-64

what does this mean?

Best,


On 2011-04-13 14:27 +0200，Raphael Hertzog wrote：
 On Wed, 13 Apr 2011, Ben Hutchings wrote:
  'dpkg-architecture -qDEB_HOST_ARCH' will show which architecture the
  rest of the system uses.
 
 dpkg --print-architecture is better suited (dpkg-architecture is a
 dpkg-dev script).
 
 Cheers,

-- 
Yang Chao
RM B007D, University Apartment Tower B
The Hong Kong University of Science and Technology Clear Water Bay,
Kowloon 
Hong Kong
Email: yor...@ust.hk


-- 
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/1302698854.3700.2.ca...@yorkey-pc.resnet.ust.hk

Re: Request for testing: /run and initscripts

On Wed, Apr 13, 2011 at 01:49:15PM +0100, Roger Leigh wrote:
 I have now implemented this (though it's not the default).
 
 I would very much appreciate it if anyone could take the time to
 install the new initscripts and test it out.
 
 http://people.debian.org/~rleigh/run/sysvinit_2.88dsf-13.3.dsc
 http://people.debian.org/~rleigh/run/initscripts_2.88dsf-13.3_amd64.deb

It breaks down at least on vservers (which can't do mount() calls):

find: `var/run': No such file or directory
fakerunlevel: open(/var/run/utmp): No such file or directory

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


signature.asc
Description: Digital signature

Re: Python2.6 as default

2011-04-13 Thread Barry Warsaw

On Apr 11, 2011, at 07:22 PM, Scott Kitterman wrote:

Hopefully it will gain additional sanity before approval (the authors did
improve it based on comments I sent them it could still be better). The
notion that /usr/bin/python pointing to any python3 version in the near term
is anything other than crazy talk is, well, crazy.

I agree we're[*] not there yet.  But I do think we're at a tipping point.
At Pycon 2011, where in previous years the responses were largely we have no
plans to port to Python 3, it's now quite common to hear we have an
experimental branch to support it or people are working on it.  So I do
think it's worth Debian thinking about, planning for, and possibly helping
with a transition to Python 3.

Python 2 won't go away any time soon.  If I had to guess, I'd say we're
probably 18-24 months away from actually being *able* to make python3 the
default, which I think is pretty well aligned with Guido's 5-year plan.

Cheers,
-Barry

[*] and by we I mean the larger Python community, not just Debian.


signature.asc
Description: PGP signature

Re: Request for testing: /run and initscripts

On Wed, Apr 13, 2011 at 03:20:38PM +0200, Adam Borowski wrote:
 On Wed, Apr 13, 2011 at 01:49:15PM +0100, Roger Leigh wrote:
  I have now implemented this (though it's not the default).
  
  I would very much appreciate it if anyone could take the time to
  install the new initscripts and test it out.
  
  http://people.debian.org/~rleigh/run/sysvinit_2.88dsf-13.3.dsc
  http://people.debian.org/~rleigh/run/initscripts_2.88dsf-13.3_amd64.deb
 
 It breaks down at least on vservers (which can't do mount() calls):
 
 find: `var/run': No such file or directory
 fakerunlevel: open(/var/run/utmp): No such file or directory

When is this, in postinst or init scripts?  We have logic
in postinst to detect chroot environments and not do any
mounting; could we add a similar check for vservers?


Thanks,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


signature.asc
Description: Digital signature

Re: Request for testing: /run and initscripts

On Wed, Apr 13, 2011 at 02:24:30PM +0100, Roger Leigh wrote:
 On Wed, Apr 13, 2011 at 03:20:38PM +0200, Adam Borowski wrote:
  On Wed, Apr 13, 2011 at 01:49:15PM +0100, Roger Leigh wrote:
   I have now implemented this (though it's not the default).
   
   I would very much appreciate it if anyone could take the time to
   install the new initscripts and test it out.
   
   http://people.debian.org/~rleigh/run/sysvinit_2.88dsf-13.3.dsc
   http://people.debian.org/~rleigh/run/initscripts_2.88dsf-13.3_amd64.deb
  
  It breaks down at least on vservers (which can't do mount() calls):
  
  find: `var/run': No such file or directory
  fakerunlevel: open(/var/run/utmp): No such file or directory
 
 When is this, in postinst or init scripts?  We have logic
 in postinst to detect chroot environments and not do any
 mounting; could we add a similar check for vservers?

postinst reported success.

This error was upon trying to [re]start the vserver afterwards, not sure
where exactly it comes from.


You might want to ask someone who deals with LXC to test it as well, as
it has a different approach to mounting filesystems inside the guest.

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


signature.asc
Description: Digital signature

Re: Python2.6 as default

2011-04-13 Thread Scott Kitterman

On Wednesday, April 13, 2011 09:22:44 AM Barry Warsaw wrote:
 On Apr 11, 2011, at 07:22 PM, Scott Kitterman wrote:
 Hopefully it will gain additional sanity before approval (the authors did
 improve it based on comments I sent them it could still be better). The
 notion that /usr/bin/python pointing to any python3 version in the near
 term is anything other than crazy talk is, well, crazy.
 
 I agree we're[*] not there yet.  But I do think we're at a tipping point.
 At Pycon 2011, where in previous years the responses were largely we have
 no plans to port to Python 3, it's now quite common to hear we have an
 experimental branch to support it or people are working on it.  So I do
 think it's worth Debian thinking about, planning for, and possibly helping
 with a transition to Python 3.
 
 Python 2 won't go away any time soon.  If I had to guess, I'd say we're
 probably 18-24 months away from actually being *able* to make python3 the
 default, which I think is pretty well aligned with Guido's 5-year plan.
 
 Cheers,
 -Barry
 
 [*] and by we I mean the larger Python community, not just Debian.

If by default you mean something like the version we normally use, then I 
agree.  If you mean pointing /usr/bin/python at a python3 version, I don't.  
Taking that step is not just about what's in the archive, it's about the 
stacks and stacks of small python scripts that are used everywhere, but never 
published.  Changing /usr/bin/python to be python3 is something I think 
happens about one release before we remove python2 entirely.  I don't think 
that's where we'll be in two years.

Scott K


-- 
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/201104130937.35999.deb...@kitterman.com

Re: Request for testing: /run and initscripts

2011-04-13 Thread Bastian Blank

On Wed, Apr 13, 2011 at 02:24:30PM +0100, Roger Leigh wrote:
 On Wed, Apr 13, 2011 at 03:20:38PM +0200, Adam Borowski wrote:
  find: `var/run': No such file or directory
  fakerunlevel: open(/var/run/utmp): No such file or directory
 When is this, in postinst or init scripts?  We have logic
 in postinst to detect chroot environments and not do any
 mounting; could we add a similar check for vservers?

No. You have to handle errors in mouting in all cases. Even the init
script may fail there.

Bastian

-- 
Fascinating is a word I use for the unexpected.
-- Spock, The Squire of Gothos, stardate 2124.5


-- 
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/20110413133936.ga31...@wavehammer.waldi.eu.org

Re: Python2.6 as default

2011-04-13 Thread Michael Gilbert

Scott Kitterman wrote:

 On Wednesday, April 13, 2011 09:22:44 AM Barry Warsaw wrote:
  On Apr 11, 2011, at 07:22 PM, Scott Kitterman wrote:
  Hopefully it will gain additional sanity before approval (the authors did
  improve it based on comments I sent them it could still be better). The
  notion that /usr/bin/python pointing to any python3 version in the near
  term is anything other than crazy talk is, well, crazy.
  
  I agree we're[*] not there yet.  But I do think we're at a tipping point.
  At Pycon 2011, where in previous years the responses were largely we have
  no plans to port to Python 3, it's now quite common to hear we have an
  experimental branch to support it or people are working on it.  So I do
  think it's worth Debian thinking about, planning for, and possibly helping
  with a transition to Python 3.
  
  Python 2 won't go away any time soon.  If I had to guess, I'd say we're
  probably 18-24 months away from actually being *able* to make python3 the
  default, which I think is pretty well aligned with Guido's 5-year plan.
  
  Cheers,
  -Barry
  
  [*] and by we I mean the larger Python community, not just Debian.
 
 If by default you mean something like the version we normally use, then I 
 agree.  If you mean pointing /usr/bin/python at a python3 version, I don't.  
 Taking that step is not just about what's in the archive, it's about the 
 stacks and stacks of small python scripts that are used everywhere, but never 
 published.  Changing /usr/bin/python to be python3 is something I think 
 happens about one release before we remove python2 entirely.  I don't think 
 that's where we'll be in two years.

Can't that be solved in the release notes when that happens?  Something
like:

python3 is now the default /usr/bin/python, so if you have existing
python2 scripts you will need to make sure to use /usr/bin/python2
instead (or convert them to python3).

Best wishes,
Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110413094233.f87b2d8c.michael.s.gilb...@gmail.com

Bug#622625: ITP: haskell-blaze-builder -- an abstraction of buffered output of byte streams

2011-04-13 Thread Marco Túlio Gontijo e Silva

Package: wnpp
Severity: wishlist
Owner: Marco Túlio Gontijo e Silva mar...@debian.org

* Package name: haskell-blaze-builder
  Version : 0.2.1.4
  Upstream Author : Simon Meier iridc...@gmail.com
* URL : http://hackage.haskell.org/package/blaze-builder
* License : BSD3
  Programming Lang: Haskell
  Description : an abstraction of buffered output of byte streams

 This package provides a library for the Haskell programming language.
 See http://www.haskell.org/ for more information on Haskell.
 .
 This library provides an abstraction of buffered output of byte streams and
 several convenience functions to exploit it. For example, it allows to
 efficiently serialize Haskell values to lazy bytestrings with a large average
 chunk size. The large average chunk size allows to make good use of cache
 prefetching in later processing steps (e.g. compression) and reduces the sytem
 call overhead when writing the resulting lazy bytestring to a file or sending
 it over the network.



-- 
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/20110413133503.18148.74452.reportbug@zezinho

Re: Default size limits for /run (/var/run) and /run/lock (/var/lock)

On Wed, 13 Apr 2011 13:34:13 +0200, Bernhard R. Link brl...@debian.org 
wrote:
 * Philip Hands p...@hands.com [110413 12:54]:
  This strikes me as suboptimal, since one could use the disk space
  allocated to /tmp as extra swap and then allocate a tmpfs of that size
  to be mounted on /tmp with no effect other than allowing the system to
  have access to more swap than it would have otherwise had (of course,
  that's probably more than it needs, so instead you could just save some
  disk space that would otherwise be left generally unused by overloading
  the swap usage with /tmp usage.
 
  Therefore, in the multi-partition setup, I think we should also default
  to having /tmp on tmpfs.
 
 This has both the disadvantage of a system then having swap (given the
 big memory sizes one currently has and the big difference between RAM
 and disk access times, having swap is often quite a disadvantage) and

Are you suggesting that a system that has enough RAM to not need swap
will become slower if you enable swap but don't use it?

If not, then either the files in /tmp will sit in RAM and therefore be a
lot faster, or if they need to go to disk, will have been staged via
swap, which may well allow a lot of small writes to small files to be
coalesced into larger swap writes, although I'm not familiar enough with
that to compare the amount of disk activity provoked by writing a lot of
small files onto an ext3 file system vs. taking the most elderly data
From a tmpfs and deciding to swap it out.

I can imagine that, for instance, removing a large file from /tmp when
on a file system might well require several writes, whereas it seems
possible that doing the same for a swapped out tmpfs might be a case of
simply recording that the blocks are ready for reuse.  On the other
hand, it may be that one needs to read in each and every block in order
to mark it ad being deleted, but I would hope that's not the way it works.

 of mixing several different things (/tmp is usually something simply
 filling over time,

Really?  Checking a couple of servers at random, one that's been running
for about 8 months but is fairly tightly locked down, has 8Kb used, and
another that's got rather more random stuff running on it, it has 17Mb
in /tmp, and that turns out to be debris laying around after a process
that does OCR on postfix files while scanning for SPAM -- so that's
actually a bug by the looks of it.

Even on servers where it is the case that /tmp grows over time, it
strikes me that tmpfs gives the system a much better chance to make
sensible decisions about when to write data out to disk.

On a mounted file system the system will attempt to ensure that the data
gets out to disk in a reasonably timely manner, since it's trying to
ensure that it's not lost in the event of a crash -- in that case of
/tmp, any effort to keep the normal file-system promise of post-crash
integrity is wasted effort, since we're going to throw the data away
anyway.

With tmpfs on the other hand, the data will never hit the disk if there
is enough RAM, and if there is a need to write it out, it'll generally
write the oldest data out first, so the portions of the tmpfs that are
being used for short-lived files will generally not be written before
those files are deleted again, so that they never need to be written at
all.

 so without low enough limits one risks that something
 important is sometime not working because of missing RAM).

If you'd read what I wrote, I suggested that a reasonable start would be
to allocate the /tmp filesystem space as swap, and then limit /tmp to
that size -- even if you then fill /tmp it cannot exceed the extra size
that you allocated to swap by giving it the disk that you'd otherwise be
using for /tmp as a file system.

Admittedly, I think that using the amount the we currently allocate to
/tmp for swap would be a waste, but it's a reasonable starting point.

In fact, it wouldn't surprise me if the act of mounting an additional
filesystem consumes more memory than a tmpfs with 8kb of files on it, so
for the first server mentioned above I may well be consuming less RAM
than I would be mounting an empty /tmp from the disk.

Cheers, Phil.
-- 
|)|  Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/
|-|  HANDS.COM Ltd.http://www.uk.debian.org/
|(|  10 Onslow Gardens, South Woodford, London  E18 1NE  ENGLAND


pgpiEojmazFuq.pgp
Description: PGP signature

Re: Python2.6 as default

2011-04-13 Thread Piotr Ożarowski

[Michael Gilbert, 2011-04-13]
 Can't that be solved in the release notes when that happens?  Something
 like:
 
 python3 is now the default /usr/bin/python, so if you have existing
 python2 scripts you will need to make sure to use /usr/bin/python2
 instead (or convert them to python3).

IMO we can change /usr/bin/python to point to python3 once Python 2.X
will no longer be supported by Debian, not sooner (as local scripts with
#!/usr/bin/python shebang would stop working anyway)
-- 
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl  www.griffith.cc   www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645


-- 
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/20110413135136.gi19...@piotro.eu

Re: Python2.6 as default

2011-04-13 Thread Michael Gilbert

Piotr Ożarowski wrote:

 [Michael Gilbert, 2011-04-13]
  Can't that be solved in the release notes when that happens?  Something
  like:
  
  python3 is now the default /usr/bin/python, so if you have existing
  python2 scripts you will need to make sure to use /usr/bin/python2
  instead (or convert them to python3).
 
 IMO we can change /usr/bin/python to point to python3 once Python 2.X
 will no longer be supported by Debian, not sooner (as local scripts with
 #!/usr/bin/python shebang would stop working anyway)

I think it makes more sense to have a release or two where users can
fall back on python2.  Well there needs to be at least one
where /usr/bin/python becomes python3 alerting users to the change and
giving them the python2 fallback, just so they have time to be prepared
for the permanent change.

Best wishes,
Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110413100036.f1a7a623.michael.s.gilb...@gmail.com

Re: Default size limits for /run (/var/run) and /run/lock (/var/lock)

2011-04-13 Thread David Goodenough

On Wednesday 13 April 2011, Ben Hutchings wrote:
 On Wed, 2011-04-13 at 13:34 +0200, Bernhard R. Link wrote:
  * Philip Hands p...@hands.com [110413 12:54]:
   This strikes me as suboptimal, since one could use the disk space
   allocated to /tmp as extra swap and then allocate a tmpfs of that size
   to be mounted on /tmp with no effect other than allowing the system to
   have access to more swap than it would have otherwise had (of course,
   that's probably more than it needs, so instead you could just save some
   disk space that would otherwise be left generally unused by overloading
   the swap usage with /tmp usage.
   
   Therefore, in the multi-partition setup, I think we should also default
   to having /tmp on tmpfs.
  
  This has both the disadvantage of a system then having swap (given the
  big memory sizes one currently has and the big difference between RAM
  and disk access times, having swap is often quite a disadvantage)
 
 [...]
 
 Under Linux, swap space is a requirement to defragment RAM.  (This may
 change in the future.)  Without swap space, the kernel eventually
 becomes unable to make large physically-contiguous allocations.  Don't
 turn it off.
 
 Ben.
I am surprised at this.  I have several boxes which are small single board
computers with solid state disks (MIDE or CF), so as I did not need swap 
space (the running set is fixed and the memory requirement was within
the total available memory, I did not define any swap space.  A few days
ago I needed to move one of the boxes I noted its uptime at 594 days just
before I switched it off.  I grant you that it has 256MB of memory, and 
120MB is currently free, but I have not noticed any problems growing over
the time it was up.  Maybe it just did not need to make any large physically
contiguous allocations.

BTW, /var/run is currently occupying a grand total of 27KB if that is relevant
to the subject of this thread.

David


-- 
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/201104131544.37402.david.goodeno...@btconnect.com

Re: Default size limits for /run (/var/run) and /run/lock (/var/lock)

2011-04-13 Thread Philipp Kern

On 2011-04-13, David Goodenough david.goodeno...@btconnect.com wrote:
 I am surprised at this.  I have several boxes which are small single board
 computers with solid state disks (MIDE or CF), so as I did not need swap 
 space (the running set is fixed and the memory requirement was within
 the total available memory, I did not define any swap space.  A few days
 ago I needed to move one of the boxes I noted its uptime at 594 days just
 before I switched it off.  I grant you that it has 256MB of memory, and 
 120MB is currently free, but I have not noticed any problems growing over
 the time it was up.  Maybe it just did not need to make any large physically
 contiguous allocations.

Given that Linux does paging, you normally don't need large physically
contiguous allocations.  I think the exceptions are mainly I/O regions for
DMA.  And you're probably not using that heavily on such a machine.

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/slrniqbfk4.rnn.tr...@kelgar.0x539.de

Re: Default size limits for /run (/var/run) and /run/lock (/var/lock)

2011-04-13 Thread Bernhard R. Link

* Philip Hands p...@hands.com [110413 15:51]:
 Are you suggesting that a system that has enough RAM to not need swap
 will become slower if you enable swap but don't use it?

If you don't use it it will hopefully make not much big difference.
The difference is if it gets used. If some program goes harvoc and
allocates to much stuff without swap it will most of the time simply
get killed. With swap it will first make the computer unuseably slow
for some time before it finally gets killed.

  of mixing several different things (/tmp is usually something simply
  filling over time,

 Really?  Checking a couple of servers at random, one that's been running
 for about 8 months but is fairly tightly locked down, has 8Kb used,

Servers of course usually have not that much (unless they are
terminal/login servers). The big /tmp stuff are usually user programs and
lab computers and other machines with many different users loging in are usually
multi-partition.

Some lab computers:
/dev/sda7 6,5G  164M  6,0G   3% /tmp
/dev/sda7 6,5G  157M  6,0G   3% /tmp
/dev/sda7 6,5G  148M  6,0G   3% /tmp
/dev/sda7 6,5G  145M  6,0G   3% /tmp
/dev/sda7 6,5G  205M  5,9G   4% /tmp
/dev/sda7 6,5G  321M  5,8G   6% /tmp
/dev/sda7 6,5G  148M  6,0G   3% /tmp
/dev/sda7 6,5G  225M  5,9G   4% /tmp
/dev/sda7 6,5G  2,8G  3,4G  46% /tmp
/dev/sda7 6,5G  152M  6,0G   3% /tmp
/dev/sda7 6,5G  152M  6,0G   3% /tmp
/dev/sda7 6,5G  150M  6,0G   3% /tmp
/dev/sda7 6.5G  162M  6.0G   3% /tmp

A login server:
/dev/vda4  21G  173M   18G   1% /tmp

A login server from another institute:
/dev/hda5 9,9G  1,2G  8,2G  13% /tmp

 If you'd read what I wrote, I suggested that a reasonable start would be
 to allocate the /tmp filesystem space as swap, and then limit /tmp to
 that size -- even if you then fill /tmp it cannot exceed the extra size
 that you allocated to swap by giving it the disk that you'd otherwise be
 using for /tmp as a file system.

And how do you make sure those metrics are correct if that is enabled
as default in the installer?

 In fact, it wouldn't surprise me if the act of mounting an additional
 filesystem consumes more memory than a tmpfs with 8kb of files on it, so
 for the first server mentioned above I may well be consuming less RAM
 than I would be mounting an empty /tmp from the disk.

RAM is nowadays for most uses usually there in abundancy. It's not that
it is scarce. The problems are faulty programs trying to get as much as
they can. If things grow unlimited there will always hit the limit.
And having different limits usually makes things more easy to control.

Bernhard R. Link


-- 
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/20110413152716.ga5...@pcpool00.mathematik.uni-freiburg.de

Re: Request for testing: /run and initscripts

On Wed, Apr 13, 2011 at 03:35:24PM +0200, Adam Borowski wrote:
 On Wed, Apr 13, 2011 at 02:24:30PM +0100, Roger Leigh wrote:
  On Wed, Apr 13, 2011 at 03:20:38PM +0200, Adam Borowski wrote:
   On Wed, Apr 13, 2011 at 01:49:15PM +0100, Roger Leigh wrote:
I have now implemented this (though it's not the default).

I would very much appreciate it if anyone could take the time to
install the new initscripts and test it out.

http://people.debian.org/~rleigh/run/sysvinit_2.88dsf-13.3.dsc
http://people.debian.org/~rleigh/run/initscripts_2.88dsf-13.3_amd64.deb
   
   It breaks down at least on vservers (which can't do mount() calls):
   
   find: `var/run': No such file or directory
   fakerunlevel: open(/var/run/utmp): No such file or directory
  
  When is this, in postinst or init scripts?  We have logic
  in postinst to detect chroot environments and not do any
  mounting; could we add a similar check for vservers?
 
 postinst reported success.
 
 This error was upon trying to [re]start the vserver afterwards, not sure
 where exactly it comes from.

Not knowing anything about vservers, do they normally run
the standard rcS init scripts?  While this patch does change
some mounts to new locations, it's pretty much doing the same
thing as before.  If /dev/shm and /lib/init/rw aren't mounted,
it looks like they are not run.

After this failure, does /var/run exist?  Is it a directory or
symlink?  What's mounted there or what does it point to?  Is
that location also valid?

When the postinst ran, did it set up bind mounts, or did it
run the chroot setup only?  If vservers never run the rcS scripts,
we need to ensure that the package runs the same postinst codepaths
as for chroots.  Is it possible to determine if we are running in
a vserver enviroment in the postinst?

 You might want to ask someone who deals with LXC to test it as well, as
 it has a different approach to mounting filesystems inside the guest.

Looks a bit more comprehensive, and you have the choice of
running the native init.  We would need to know if rcS will be
run or not when running the postinst.  Comments from anyone using
lxc with Debian would be most helpful.


Regards,
Roger
-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


signature.asc
Description: Digital signature

Re: Python2.6 as default

2011-04-13 Thread Barry Warsaw

On Apr 13, 2011, at 10:00 AM, Michael Gilbert wrote:

I think it makes more sense to have a release or two where users can
fall back on python2.  Well there needs to be at least one
where /usr/bin/python becomes python3 alerting users to the change and
giving them the python2 fallback, just so they have time to be prepared
for the permanent change.

I do agree that we could add the python2 symlink now so that folks who want to
prepare can start changing their #! lines to use /usr/bin/python2.

Cheers,
-Barry


signature.asc
Description: PGP signature

Re: Default size limits for /run (/var/run) and /run/lock (/var/lock)

2011-04-13 Thread Thomas Hood

I just realized that I misunderstood Roger Leigh's posting and so
my previous message was mostly superfluous.  My apologies.

1. His statement but you have to mount many more to be able to
break your system was correct (and can be made more explicit by
adding ... by filling them all).

2. His proposal *was* to reduce the size of all tmpfses (together)
to 50%, as follows:

/run 10%
/run/shm 20%
/tmp 20%
/run/lock, /lib/init/rw  very small

What remains of my previous message are my two questions:

1. Is OOM importantly worse than a full system tmpfs?  I think so
too, but

2. Even if so, do we have to worry about OOM happening because
*multiple* tmpfses got filled?  We are already safe from OOM if
one tmpfs (whose size is 50% of memory) gets filled.
-- 
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/4da5bf6e.9090...@gmail.com

Re: Default size limits for /run (/var/run) and /run/lock (/var/lock)

On Wed, Apr 13, 2011 at 03:17:24PM +, Philipp Kern wrote:
 On 2011-04-13, David Goodenough david.goodeno...@btconnect.com wrote:
  I am surprised at this.  I have several boxes which are small single board
  computers with solid state disks (MIDE or CF), so as I did not need swap 
  space (the running set is fixed and the memory requirement was within
  the total available memory, I did not define any swap space.  A few days
  ago I needed to move one of the boxes I noted its uptime at 594 days just
  before I switched it off.  I grant you that it has 256MB of memory, and 
  120MB is currently free, but I have not noticed any problems growing over
  the time it was up.  Maybe it just did not need to make any large physically
  contiguous allocations.
 
 Given that Linux does paging, you normally don't need large physically
 contiguous allocations.  I think the exceptions are mainly I/O regions for
 DMA.

Heap allocations also have to be contiguous.  And every thread needs a
kernel stack which is at least 2 contiguous pages on most architectures.

 And you're probably not using that heavily on such a machine.
 
Evidently.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus


-- 
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/20110413160825.gi2...@decadent.org.uk

Re: Default size limits for /run (/var/run) and /run/lock (/var/lock)

2011-04-13 Thread David Goodenough

On Wednesday 13 April 2011, Ben Hutchings wrote:
 On Wed, Apr 13, 2011 at 03:17:24PM +, Philipp Kern wrote:
  On 2011-04-13, David Goodenough david.goodeno...@btconnect.com wrote:
   I am surprised at this.  I have several boxes which are small single
   board computers with solid state disks (MIDE or CF), so as I did not
   need swap space (the running set is fixed and the memory requirement
   was within the total available memory, I did not define any swap
   space.  A few days ago I needed to move one of the boxes I noted its
   uptime at 594 days just before I switched it off.  I grant you that it
   has 256MB of memory, and 120MB is currently free, but I have not
   noticed any problems growing over the time it was up.  Maybe it just
   did not need to make any large physically contiguous allocations.
  
  Given that Linux does paging, you normally don't need large physically
  contiguous allocations.  I think the exceptions are mainly I/O regions
  for DMA.
 
 Heap allocations also have to be contiguous.  And every thread needs a
 kernel stack which is at least 2 contiguous pages on most architectures.
 
  And you're probably not using that heavily on such a machine.
Its acting as a network router.  So presumably once everything is 
allocated, it keeps reusing them.

David
 
 Evidently.
 
 Ben.


-- 
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/201104131720.18057.david.goodeno...@btconnect.com

Re: Default size limits for /run (/var/run) and /run/lock (/var/lock)

On Wed, Apr 13, 2011 at 05:21:18PM +0200, Thomas Hood wrote:
 I just realized that I misunderstood Roger Leigh's posting and so
 my previous message was mostly superfluous.  My apologies.
 
 1. His statement but you have to mount many more to be able to
 break your system was correct (and can be made more explicit by
 adding ... by filling them all).

Yes, I did word it poorly, I'm afraid.

 2. His proposal *was* to reduce the size of all tmpfses (together)
 to 50%, as follows:
 
 /run 10%
 /run/shm 20%
 /tmp 20%
 /run/lock, /lib/init/rw  very small

I should admit that the 50% here is more by coincidence than intent,
but the general idea is that it's restricted overall to a sensible
amount.  Given that tmpfs on /tmp is optional and disabled by default,
it would be 30% + 10MiB for the last two.

What I should have stated more clearly in my earlier messages about
the limits is that we now have the flexibility to choose exactly
how to manage the space.  We can have a single large tmpfs (less
flexible and can be filled up by users, but there's much less
chance of a single part running out of space cf multiple mounts)
or we can have a collection of separate tmpfs mounts with different
size limits (less chance of a user filling a system-only part, but
an increased possibility of a single mount filling up).  Or we can
choose something in between those two extremes.  For the defaults,
I'd like something which will work in all cases, and which can be
easily tweaked for special/non-standard uses.

If we have a single shared tmpfs, 50% core is eminently sensible,
providing you have some swap to back it.  If we have multiple
tmpfs mounts, we do want to consider restricting it further.

The 10% and 20% figures are fairly arbitrary (the 10% comes from the
max. samba usage seen with a big margin added to it; it's still
three orders of magnitude bigger than the average usage of /run).
The 20% is a bit more fuzzy; it's smaller than the 50% default, but
still large enough that the chance of using it all is extremely
remote.  I'm quite happy to adjust these values if needed.

 What remains of my previous message are my two questions:
 
 1. Is OOM importantly worse than a full system tmpfs?  I think so
 too, but

They are both undesirable.  OOM is worse because it's potentially
unrecoverable (the OOM killer can't kill a process to reclaim
space on tmpfs [with the exception of POSIX SHM, but I don't think
the kernel knows about that--it's purely a userspace implementation],
so you can lock up the whole machine).  But equally we don't want to
allow users to interfere with system processes by denying them the
resources they need (e.g. not being able to create a lockfile/pidfile);
but in this situation, it is rather easier to recover since we can
just delete the offending files to free up some space.

[It would be nice if tmpfs offered a superuser-only allocation of
e.g. 5% like ext does, which would go a long way to mitigate
user DoS.]

 2. Even if so, do we have to worry about OOM happening because
 *multiple* tmpfses got filled?  We are already safe from OOM if
 one tmpfs (whose size is 50% of memory) gets filled.

This is really down to the limits we have set on them.  If we have
sensible limits, even far too large for what we expect to be
typical usage, we're safe from OOM.  With no limit (or more accurately
the default kernel limit), as used at present, adding multiple tmpfs
mounts does make this more likely.  The proposed default values are
intended to satisfy these requirements, but they may well not be
optimal, and I'll be happy to adjust them as needed.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


signature.asc
Description: Digital signature

/usr/bin/python2 again

2011-04-13 Thread Piotr Ożarowski

[Barry Warsaw, 2011-04-13]
 On Apr 13, 2011, at 10:00 AM, Michael Gilbert wrote:
 
 I think it makes more sense to have a release or two where users can
 fall back on python2.  Well there needs to be at least one
 where /usr/bin/python becomes python3 alerting users to the change and
 giving them the python2 fallback, just so they have time to be prepared
 for the permanent change.
 
 I do agree that we could add the python2 symlink now so that folks who want to
 prepare can start changing their #! lines to use /usr/bin/python2.

what's the point? /usr/bin/python2 will not work either when we'll drop
support for Python 2.X. How about providing python3-foo packages as
soon as possible (to make it easier to migrate) instead of wasting time
on /usr/bin/python2 mess?
-- 
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl  www.griffith.cc   www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645


-- 
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/20110413171959.gj19...@piotro.eu

i386 ISO also installing kernel for AMD64 (Squeeze)

2011-04-13 Thread André Barone Rodrigues

Dear sirs,
I think there's something not entirelly clear to me and perhaps to some
other people, because I couldn't find any solution to my problem.

I have downloaded an i386 ISO for Squeeze (6.0.1a) and used the same media
to perform installation on 2 different machines.
 On the first one I got a perfect i686  and on the other an  AMD64  kernel.
presumibly, my media is not mult-arch.

One problem I have felt so far is about Virtualbox OSE, which brings a
kernel problem while installing from Debian Packages.

Best Regards,
André.

Re: /usr/bin/python2 again

2011-04-13 Thread Jon Dowland

On Wed, Apr 13, 2011 at 07:19:59PM +0200, Piotr Ożarowski wrote:
 what's the point? /usr/bin/python2 will not work either when we'll drop
 support for Python 2.X.

Do you think we'll ever drop supported for 2.X?  It seems quite likely to me
that it will live on for a long, long time.


-- 
Jon Dowland


-- 
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/20110413184003.ga4...@deckard.alcopop.org

Re: network-manager as default? No!

2011-04-13 Thread Jon Dowland

On Wed, Apr 13, 2011 at 01:39:38PM +0100, Philip Hands wrote:
  Surely a person managing a server can do aptitude install ifupdown 
  network-manager-?
 
 You appear to want to inflict extra work on large swathes of our
 users.  If that is the case, I'd like to see some sort of justification
 for that.

Does the following assumption hold?

Desktop users favour fewer prompts at install time and more sane default
choices.  Server users want fine control over the nuances of installation,
but harness additional technologies/options to help with installations
(starting with expert mode and continuing with netboots and preseeding,
other technologies like FAI, etc.; followed by a configuration management
solution to finish implementing local policies).

Therefore, slanting d-i towards fewer questions in normal priorities and
more desktop-oriented smart defaults does not disadvantage server users,
because they toggle the relevant switches to have greater control anyway.

Or in other words, if a server user does an attended install via d-i, doesn't
trigger expert mode and accepts the defaults for most questions,  is it wrong
if they end up with NetworkManager?  Surely there are a lot of other
customisatons they will need to perform to get going, in a similar category
of risk (to remote operation) as changing the network plumbing (installing
SSH? reconfiguring PAM? etc.)

And finally, the vast majority of servers I have adminned have had very simple
networking requirements, very similar to a desktop user: one network interface
with a link, IP via DHCP (at least initially, later tweaked to be static).  Of
the hundreds of machines I've looked after, past and present, very, VERY few
have had the need for the more interesting stuff: bridging for VM hosts,
bonding, tunnelling and a few other bits and pieces for HA front-ends, that's
about it.  Where it has been necessary to reconfigure by hand, the burden of
swapping some packages around would pale in comparison to writing the
interfaces file.

 In the absence of such justification, I don't see what's wrong with the
 status quo (i.e. N-M on Gnome desktops by default, ifupdown elsewhere by
 default, with both choices entirely overridable by the user)

Having said all of the above, and the thread being where it is now, I have to
admit I can't remember what the value proposition was in the first place. Time
to re-read...


-- 
Jon Dowland


-- 
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/20110413185302.gb4...@deckard.alcopop.org

Re: /usr/bin/python2 again

2011-04-13 Thread Philipp Kern

On 2011-04-13, Piotr Ożarowski pi...@debian.org wrote:
 [Barry Warsaw, 2011-04-13]
 On Apr 13, 2011, at 10:00 AM, Michael Gilbert wrote:
 I think it makes more sense to have a release or two where users can
 fall back on python2.  Well there needs to be at least one
 where /usr/bin/python becomes python3 alerting users to the change and
 giving them the python2 fallback, just so they have time to be prepared
 for the permanent change.
 I do agree that we could add the python2 symlink now so that folks who want 
 to
 prepare can start changing their #! lines to use /usr/bin/python2.
 what's the point? /usr/bin/python2 will not work either when we'll drop
 support for Python 2.X. How about providing python3-foo packages as
 soon as possible (to make it easier to migrate) instead of wasting time
 on /usr/bin/python2 mess?

Given that other distributions will also pick up python2 due to PEP-0394 it
doesn't feel like wasted time if we want to foster cross-distro compatibility.

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/slrniqbt19.s35.tr...@kelgar.0x539.de

Re: /usr/bin/python2 again

2011-04-13 Thread Scott Kitterman

On Wednesday, April 13, 2011 03:06:17 PM Philipp Kern wrote:
 On 2011-04-13, Piotr Ożarowski pi...@debian.org wrote:
  [Barry Warsaw, 2011-04-13]
  
  On Apr 13, 2011, at 10:00 AM, Michael Gilbert wrote:
  I think it makes more sense to have a release or two where users can
  fall back on python2.  Well there needs to be at least one
  where /usr/bin/python becomes python3 alerting users to the change and
  giving them the python2 fallback, just so they have time to be prepared
  for the permanent change.
  
  I do agree that we could add the python2 symlink now so that folks who
  want to prepare can start changing their #! lines to use
  /usr/bin/python2.
  
  what's the point? /usr/bin/python2 will not work either when we'll drop
  support for Python 2.X. How about providing python3-foo packages as
  soon as possible (to make it easier to migrate) instead of wasting time
  on /usr/bin/python2 mess?
 
 Given that other distributions will also pick up python2 due to PEP-0394 it
 doesn't feel like wasted time if we want to foster cross-distro
 compatibility.

So far the PEP is just a draft.  I suspect something like this will eventually 
get approved.  When that happens (and upstream figures out how they will ship 
/usr/bin/python2 within python2.7) then I think that's a good point.  For now, 
I think it's premature.

Scott K


--
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/201104131528.05052.deb...@kitterman.com

Re: Bug#621833: System users: removing them

2011-04-13 Thread Lars Wirzenius

On ti, 2011-04-12 at 21:31 +0200, sean finney wrote:
 Hi Lars,
 
 On Tue, Apr 12, 2011 at 06:41:10PM +0100, Lars Wirzenius wrote:
   But shouldn't we say they _must_ lock package-specific system users
   and groups when the package is removed ?
  
  I think that's a good idea. Steve Langasek in the bug (#621833) and
  others agree, so I think there's a strong consensus on that.
 
 I don't think I'd agree there, at least without also addressing:
 
  * It also needs to limit the scope to locally defined users (i.e. not
fail when it is unable to lock an NIS/LDAP/etc account).
  * There needs to be a way to explicitly do that with adduser or a similar
tool[1][2][3][4].

Yes, and these were already suggested in the bug log, if I've undertood
everyone correctly (not all those mails were on -devel, though).

 Also, we haven't discussed what should be done in the case of a user
 account possibly shared between different packages, where any one of
 them may create it and 1..N of them might be installed.

In my opinion, those packages should arrange for things to work right
amongst themselves. The typical case would be to have a -common package,
which creates and locks down the user, and everything else depends on
it. But other options are also possible; I guess anything that achieves
the same effect should be OK by the policy manual.

-- 
Blog/wiki/website hosting with ikiwiki (free for free software):
http://www.branchable.com/


-- 
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/1302723569.2921.12.ca...@havelock.liw.fi

Re: network-manager as default? No!

2011-04-13 Thread Bjørn Mork

Stephan Seitz stse+deb...@fsing.rootsland.net writes:

 The only thing that I miss from ifupdown (and I configured bonds,
 bridges and vlans) is a good IPv6 support. I can’t separately activate
 or deactivate IPv4 or IPv6 parts of an interface.

I have seen several requests for this feature, but I really don't
understand why you'd want that.  If an interface is configured as a dual
stack interface, then I expect both stacks to be brought up and down
(near) simultaneously.  In fact, the one thing I dislike about ifupdown
is the illusion that there can be both an iface eth0 inet and an
iface eth0 inet6.  There can't.  It's the same interface running two
protocols.  I would have preferred something like some routers do:

  iface eth0
   address ..
   ipv6address ..


Juniper router do of course do this even better, splitting the IPv4 and
IPv6 configuration in separate family blocks, but still grouping all
the protocol families under the same unit (representing a VLAN,
physical port, or some other layer 2 interface). But that is a bit too
late to implement in ifupdown.

If you really want to handle the protocols individually, then don't
configure a dual stack interface in the first place.  Use separate vlans
or ports.




Bjørn






-- 
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/87y63ex79x@nemi.mork.no

Re: i386 ISO also installing kernel for AMD64 (Squeeze)

On Wed, Apr 13, 2011 at 02:38:03PM -0300, André Barone Rodrigues wrote:
 Dear sirs,
 I think there's something not entirelly clear to me and perhaps to some
 other people, because I couldn't find any solution to my problem.
 
 I have downloaded an i386 ISO for Squeeze (6.0.1a) and used the same media
 to perform installation on 2 different machines.
  On the first one I got a perfect i686  and on the other an  AMD64  kernel.
 presumibly, my media is not mult-arch.

The second machine presumably has 4 GB or more memory, so the '686'
kernel is not suitable.  There should be a '686-bigmem' kernel on the
first DVD, but there isn't.  This is bug #622622
http://bugs.debian.org/622622.

You can install 'linux-image-2.6-686-bigmem' using the network and
then remove the 'linux-image-2.6-amd64' and 'linux-image-2.6.32-5-amd64'
packages.

 One problem I have felt so far is about Virtualbox OSE, which brings a
 kernel problem while installing from Debian Packages.

Use the 'reportbug' command to report a bug on whichever package seems
to be at fault.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus


-- 
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/20110413200348.gk2...@decadent.org.uk

Re: Request for testing: /run and initscripts