Re: Bug#617867: ITP: morse-coach -- Koch method Morse code trainer for GTK+ and Pulseaudio

[Kirk Wolff]

karl,

I can see someone has added pulseaudio to the old morse package, however
it is not compatible with the approach I'm taking with this program.  I
have many plans for features, some of which are currently being
implemented.  I'll consider adding some of the command-line
functionality from morse, but trying to turn a cli program into a gui
program is like trying to put a square peg into a round hole.  People
would expect to see their old cli when they install morse.  morse-coach
is a completely different kind of morse code training program.
-- 
Kirk Wolff
Wolff Electronic Design
(651) 224-0412 x200
Fax: (651) 925-0412
k...@wolffelectronicdesign.com


On Thu, 2011-04-14 at 12:22 +0930, Karl Goetz wrote:
> On Fri, 11 Mar 2011 17:44:42 -0600
> Kirk Wolff  wrote:
> 
> > Package: wnpp
> > Severity: wishlist
> > Owner: Kirk Wolff 
> > 
> > 
> > * Package name: morse-coach
> >   Version : 0.0.1
> >   Upstream Author : Kirk Wolff 
> > * URL : http://morse-coach.sf.net/
> > * License : GPLv3
> >   Programming Lang: C
> >   Description : Koch method Morse code trainer for GTK+ and
> > Pulseaudio
> 
> How does this relate to debians existing morse package? 
> http://packages.debian.org/squeeze/morse
> There is an updated package of that waiting on mentors too:
> http://mentors.debian.net/debian/pool/main/m/morse/
> 
> both appear to use pulseaudio, could you port your gtk ui to the
> existing morse?
> kk
> 


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

Re: Bug#617867: ITP: morse-coach -- Koch method Morse code trainer for GTK+ and Pulseaudio

[Karl Goetz]

On Fri, 11 Mar 2011 17:44:42 -0600
Kirk Wolff  wrote:

> Package: wnpp
> Severity: wishlist
> Owner: Kirk Wolff 
> 
> 
> * Package name: morse-coach
>   Version : 0.0.1
>   Upstream Author : Kirk Wolff 
> * URL : http://morse-coach.sf.net/
> * License : GPLv3
>   Programming Lang: C
>   Description : Koch method Morse code trainer for GTK+ and
> Pulseaudio

How does this relate to debians existing morse package? 
http://packages.debian.org/squeeze/morse
There is an updated package of that waiting on mentors too:
http://mentors.debian.net/debian/pool/main/m/morse/

both appear to use pulseaudio, could you port your gtk ui to the
existing morse?
kk

-- 
Karl Goetz, (Kamping_Kaiser / VK5FOSS)
Debian contributor / gNewSense Maintainer
http://www.kgoetz.id.au
No, I won't join your social networking group


signature.asc
Description: PGP signature

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

[Karl Goetz]

On Wed, 13 Apr 2011 10:32:42 +0100
Roger Leigh  wrote:

> On Tue, Apr 12, 2011 at 12:38:03PM +0100, Roger Leigh wrote:

> 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:
[...]
> /run/shm: No default (use general tmpfs default of 20%)
> /tmp: No default (use general tmpfs default of 20%)

20% doesn't seem like a lot for /tmp when people try and compile
something. While its not something most people end up doing, it does
seem odd to make people change their tempfs size before they can start
building packages for debian/themselves.
just a thought,
kk

-- 
Karl Goetz, (Kamping_Kaiser / VK5FOSS)
Debian contributor / gNewSense Maintainer
http://www.kgoetz.id.au
No, I won't join your social networking group


signature.asc
Description: PGP signature

Bug#622700: ITP: fastx-toolkit -- FASTQ/A short nucleotide reads pre-processing tools

[Charles Plessy]

Package: wnpp
Severity: wishlist
Owner: Charles Plessy 

  Package name: fastx-toolkit
  Version : 0.0.13
  Upstream Author : Assaf Gordon 
  URL : http://hannonlab.cshl.edu/fastx_toolkit/
  License : AGPL-3+, MIT
  Programming Lang: C
  Description : FASTQ/A short nucleotide reads pre-processing tools

 The FASTX-Toolkit is a collection of command line tools for preprocessing
 short nucleotide reads in FASTA and FASTQ formats, usually produced by
 Next-Generation sequencing machines. The main processing of such FASTA/FASTQ
 files is mapping (aligning) the sequences to reference genomes or other
 databases using specialized programs like BWA, Bowtie and many many others.
 However, it is sometimes more productive to preprocess the FASTA/FASTQ files
 before mapping the sequences to the genome—manipulating the sequences to
 produce better mapping results. The FASTX-Toolkit tools perform some of these
 preprocessing tasks. 



-- 
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/20110414003331.3299.5874.reportbug@chouca.igloo

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

[Goswin von Brederlow]

André Barone Rodrigues  writes:

> 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é.

The i386 port of Debian has the customary 32bit kernel but it also has
64bit kernels. A 64bit kernel is generally faster (even considering it
has to interface with 32bit userspace) and does not limit your physical
memory to 3.5GiB (64GiB with bigmem). It also allows you to run 64bit
applications and 64bit virtual machines if you so choose. So all around
it is a better choice if you have a 64bit capable cpu.

The problem with Virtualbox OSE is regrettable but that would be a bug
in Virtualbox OSE. It should support 64bit kernels with 32bit userspace.
Please do file a bug with details.

MfG
Goswin


-- 
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/87vcyhkd4k.fsf@frosties.localnet

Re: network-manager as default? No!

[Ben Finney]

Jon Dowland  writes:

> 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).

I think you're conflating the administrator of one server with the
administrator of many servers.

A server administator can often be simply someone administrating *one*
machine, without expert mode or preseeding or any of the rest; simply
setting up a single headless machine in a remote data centre.

So network access, once available to the machine, must remain available
during the installation and/or upgrade process unless explicitly
disabled.

> 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.

So long as the default *is* smart. A default which can in many cases
leave the remote user without access to the machine they're installing
is not smart.

> 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?

I think it is wrong, based on the fact expressed in these threads that
NetworkManager can, by default during upgrade, bring down the network
connection.

> 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.)

Such a server administrator as I've described above has the expectation
that the networking configuration, if it works once on installation,
won't need to be changed nor special packages installed to keep it
working on upgrade.

That is a reasonable expectation, and AIUI argues against NetworkManager
as default.

-- 
 \ “I must say that I find television very educational. The minute |
  `\   somebody turns it on, I go to the library and read a book.” |
_o__)—Groucho Marx |
Ben Finney


-- 
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/87vcyh4xsr@benfinney.id.au

Re: Bug#621833: System users: removing them

[Leo 'costela' Antunes]

On 12/04/11 22:43, Scott Kitterman wrote:
>> Also, we need to provide a way for sysadmin to know they can safely remove
>> a stale
>> system user.
> 
> If we could do that, we could just remove them automatically and not
> bother the sysadmin.

Not necessarily. We can't be sure there aren't any files lying around
(at least not efficiently enough) to cause problems with UID reuse etc,
but we may inform the admin that at least from the packaging point of
view, the user/group isn't needed anymore. He can then decide to take
appropriate action if he feels the house-keeping is necessary.
It could simply be a matter of using the "User Name/Comment" field to
write something like "formerly used by package X; may be removed".
Admittedly not strictly necessary, but nice for those cases where you
check your /etc/passwd a few years later and ask yourself where that
user came from.


Cheers

-- 
Leo "costela" Antunes
[insert a witty retort here]


-- 
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/4da61068.8000...@debian.org

Re: Request for testing: /run and initscripts

[Roger Leigh]

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

I've now added support for vservers to the postinst (we treat
them like chroots, since they appear not to run rcS, which is
probably the root cause of the problems here).  The updated
packages are at the URIs above; could you possibly give it a
try and let me know if it works.

The same applies to lxc; if anyone uses it, I'd appreciate feedback.
I don't have any direct knowledge, so I am reliant upon users for
testing.  The same applies to GNU/Hurd.


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: i386 ISO also installing kernel for AMD64 (Squeeze)

[Ben Hutchings]

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
.

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: network-manager as default? No!

[Bjørn Mork]

Stephan Seitz  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: Bug#621833: System users: removing them

[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: /usr/bin/python2 again

[Scott Kitterman]

On Wednesday, April 13, 2011 03:06:17 PM Philipp Kern wrote:
> On 2011-04-13, Piotr Ożarowski  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: /usr/bin/python2 again

[Philipp Kern]

On 2011-04-13, Piotr Ożarowski  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: network-manager as default? No!

[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

[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

i386 ISO also installing kernel for AMD64 (Squeeze)

[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é.

/usr/bin/python2 again

[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

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

[Roger Leigh]

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

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

[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  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)

[Ben Hutchings]

On Wed, Apr 13, 2011 at 03:17:24PM +, Philipp Kern wrote:
> On 2011-04-13, David Goodenough  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)

[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: "Python2.6 as default"

[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: Request for testing: /run and initscripts

[Roger Leigh]

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: Default size limits for /run (/var/run) and /run/lock (/var/lock)

[Bernhard R. Link]

* Philip Hands  [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: Default size limits for /run (/var/run) and /run/lock (/var/lock)

[Philipp Kern]

On 2011-04-13, David Goodenough  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)

[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  [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: "Python2.6 as default"

[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: "Python2.6 as default"

[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: Default size limits for /run (/var/run) and /run/lock (/var/lock)

[Philip Hands]

On Wed, 13 Apr 2011 13:34:13 +0200, "Bernhard R. Link"  
wrote:
> * Philip Hands  [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

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

[Marco Túlio Gontijo e Silva]

Package: wnpp
Severity: wishlist
Owner: "Marco Túlio Gontijo e Silva" 

* Package name: haskell-blaze-builder
  Version : 0.2.1.4
  Upstream Author : Simon Meier 
* 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: "Python2.6 as default"

[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

Re: Request for testing: /run and initscripts

[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"

[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

[Adam Borowski]

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: Request for testing: /run and initscripts

[Roger Leigh]

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: "Python2.6 as default"

[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

[Adam Borowski]

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: Question about the version of debian

[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: Question about the version of debian

[Ben Hutchings]

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: network-manager as default? No!

[Philip Hands]

On Wed, 13 Apr 2011 11:26:06 + (UTC), Felipe Sateler  
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

Request for testing: /run and initscripts

[Roger Leigh]

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  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 aroun

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

[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

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

[Martin Quinson]

Package: wnpp
Severity: wishlist
Owner: Martin Quinson 

* 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

Re: Question about the version of debian

[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

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

[Ben Hutchings]

On Wed, 2011-04-13 at 13:34 +0200, Bernhard R. Link wrote:
> * Philip Hands  [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: network-manager as default? No!

[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 Rahmwww.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: Bits from the Release Team - Kicking off Wheezy

[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 "-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: Question about the version of debian

[Ben Hutchings]

On Wed, 2011-04-13 at 13:44 +0800, Asias He wrote:
> On Wed, Apr 13, 2011 at 12:32 PM, YANG,Chao  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: network-manager as default? No!

[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: Default size limits for /run (/var/run) and /run/lock (/var/lock)

[Bernhard R. Link]

* Philip Hands  [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!

[Adam Borowski]

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: network-manager as default? No!

[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: Default size limits for /run (/var/run) and /run/lock (/var/lock)

[Adam Borowski]

On Wed, Apr 13, 2011 at 10:51:50AM +0100, Philip Hands wrote:
> On Tue, 12 Apr 2011 13:51:09 +0200, Michael Biebl  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: Default size limits for /run (/var/run) and /run/lock (/var/lock)

[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)

[Philip Hands]

On Tue, 12 Apr 2011 13:51:09 +0200, Michael Biebl  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)

[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: only servers pfff (Was: Re: network-manager as default? No!)

[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: rock around hwclock.sh

[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: network-manager as default? No!

[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: Default size limits for /run (/var/run) and /run/lock (/var/lock)

[Roger Leigh]

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!

[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: [Pkg-samba-maint] Default size limits for /run (/var/run) and /run/lock (/var/lock)

[Roger Leigh]

On Wed, Apr 13, 2011 at 10:29:16AM +0200, Stig Sandbeck Mathisen wrote:
> Roger Leigh  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: [Pkg-samba-maint] Default size limits for /run (/var/run) and /run/lock (/var/lock)

[Stig Sandbeck Mathisen]

Roger Leigh  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 


pgpZY6Bxgti27.pgp
Description: PGP signature

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

[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: network-manager as default? No!

[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

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

[Alessandro Ghedini]

Package: wnpp
Severity: wishlist
Owner: Alessandro Ghedini 

* Package name: libeval-closure-perl
  Version : 0.03
  Upstream Author : Jesse Luehrs 
* 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: Bits from the Release Team - Kicking off Wheezy

[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

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

[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

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

[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

Re: rock around hwclock.sh

[Philip Hands]

On Wed, 13 Apr 2011 09:05:23 +0300, "Andrew O. Shadoura"  
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

Re: Python 3 as default? (Re: "Python2.6 as default")

[Piotr Ożarowski]

[Adrian von Bidder, 2011-04-13]
> Agreed. However, it would be interesting to track which of the bg/major 
> python packages/frameworks are not available on Python3 yet, if only as a 
> reference for the next time somebody proposes to have /usr/bin/python be a 
> Python 3.
> 
> http://wiki.debian.org/Python/Python3Packages

please use http://wiki.python.org/moin/PortingToPy3k/Modules instead
-- 
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/20110413072800.ge19...@piotro.eu

Re: Python 3 as default? (Re: "Python2.6 as default")

[Sandro Tosi]

On Wed, Apr 13, 2011 at 08:46, Adrian von Bidder  wrote:
> Agreed. However, it would be interesting to track which of the bg/major
> python packages/frameworks are not available on Python3 yet, if only as a
> reference for the next time somebody proposes to have /usr/bin/python be a
> Python 3.
>
> http://wiki.debian.org/Python/Python3Packages
>
> It's not complete by far, but I guess the fact that django, a big part of
> zope and pylons are all three not available for Python 3 yet (upstream, not
> only packages) should serve to illustrate the point.

http://py3ksupport.appspot.com/
http://getpython3.net/

-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi


-- 
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/banlktinxv2i1pgcorjci04u6nh_o9q1...@mail.gmail.com