headers
Gabor Gombas | 1 Mar 2006 01:17
Picon

Re: 4GB address space

On Tue, Feb 28, 2006 at 05:46:07PM +0100, Wouter Verhelst wrote:

[...]
> > user applications can use the whole 4GB of virtual address space while the
> > kernel runs it's own AS.
[...]
> 
> Run "make menuconfig"; then, select "Processor type and features", and
> "High Memory Support". Done.

The question was not about HIGHMEM but about Ingo Molnar's "4G/4G
split" patch, which is not part of the base kernel. HIGHMEM does not let
userspace use the whole 4G address space.

Gabor

--

-- 
     ---------------------------------------------------------
     MTA SZTAKI Computer and Automation Research Institute
                Hungarian Academy of Sciences
     ---------------------------------------------------------
Permalink | Reply | 6 comments |
headers
maximilian attems | 1 Mar 2006 01:06
Picon

Re: [Pkg-xen-devel] Re: Packaing Xen 3.0 etc for Debian

On Tue, 28 Feb 2006, Steve Langasek wrote:

> On Tue, Feb 28, 2006 at 09:59:17AM +0100, maximilian attems wrote:
<snipp>
> 
> > as the xen userspace is tightly integrated to the xen kernel,
> > it makes a lot of sense to release both in the same run.
> 
> But it doesn't make sense to release them both as part of the same source
> package,

sure that was never proposed.

> and it doesn't necessarily make sense to keep them in the same svn
> repo.  Can you explain why it's better for the xen userspace/hypervisor
> packages to be kept under the aegis of the kernel team, instead of for
> Bastian (and other interested developers) to join the pkg-xen team?  Is
> there really so much more interest in the xen-tools among the members of the
> kernel team than among the, er, Xen team?

yes we want to release etch with Xen!

not like sarge were uml received not the love it should have received.
the 3.0 hypervisor is communicating through procfs. lkml patches have
shown sysfs patches trying to reimpleiment procfs code and more recently
purer sysfs interfaces.  i expect some more churns in that direction,
so a tight cooperation is needed. 

the separted repo and lists to track are at this stage more a nuisance
than a help.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Brian M. Carlson | 1 Mar 2006 02:04

Re: buildd and experimental

[Please followup to -project; I am subscribed there, too, so you should
*not* Cc me.]

On Tue, 2006-02-28 at 12:13 +0100, Gabor Gombas wrote:
> On Tue, Feb 28, 2006 at 08:59:46AM +0000, Brian M. Carlson wrote:
> 
> > [0] In case you're unsure, you can check the X-Spam-Status header, which
> > will tell you that I am an LDOSUBSCRIBER, in which case you can assume
> 
> Just nitpicking: there is no X-Spam-Status: header in my copy; however,
> there is a X-Qmail-Scanner-MOVED-X-Spam-Status: header instead. And even
> if somebody founds that and somehow guesses that this is the right
> header to look at (I have extra headers added by 3 different spam
> checkers), he/she would probably have still no idea what LDOSUBSCRIBER
> means.

I understand that different mail systems do different things (although I
hope you're not using qmail[0]).  However, the code of conduct seems to
point out that one should not Cc someone unless they specifically ask
for it (a guideline that you neglected to follow, after I pointed this
out to Mr. Bushnell).  But since some new or one-time posters may not
realize this (and want to be Cc'd anyway), this provides a heuristic to
guess if someone is actually subscribed, nothing more.

If you are unsure, you could simply not Cc someone unless they ask.

[0] qmail has a nasty habit of sending backscatter, which, AIUI, cannot
be turned off.
Permalink | Reply | 93 comments |
headers
Adeodato Simó | 1 Mar 2006 02:13
Picon
Gravatar

Re: lists.d.o Spam (was: Marking BTS spam)

* Javier Fernández-Sanguino Peña [Wed, 01 Mar 2006 00:47:41 +0100]:

> Is it OK if we, mutt users, use this?

  Why not 'breport-listspam <at> lists.debian.org<enter>'? ('b' does (B)ounce
  in the default keybindings). THat's what Cord asked for...

-- 
Adeodato Simó                                     dato at net.com.org.es
Debian Developer                                  adeodato at debian.org

                          Listening to: Andrés Calamaro - Estadio azteca

--

-- 
To UNSUBSCRIBE, email to debian-devel-REQUEST <at> lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster <at> lists.debian.org
Permalink | Reply | 1 comment |
headers
Joe Smith | 1 Mar 2006 02:15
Picon
Favicon

Re: /lib/modules/≤kernelversion>/volatile on tmpfs


"Sergio Callegari" <scallegari <at> deis.unibo.it> wrote in message 
news:440331E5.5070703 <at> deis.unibo.it...
>I have this directory on an Ubuntu system and it seems to be present
>on recent Debian systems too...
>It is on tmpfs.
>Can anybody tell me what is its purpose (as many other distros don't
>have it) and when it gets mounted?
>
>Thanks!
>
>Sergio

I'm betting that it is caused by a bug somewhere. Something is presumably 
tring to create
a tmpfs on /etc/svc/volatile, but is accidentally doing it in that directory 
instead.

What is probably happing is a script that thinks it is executing in /etc/svc 
is not, or is having its
cwd changed unexpectedly.
Permalink | Reply | 1 comment |
headers
Steve Langasek | 1 Mar 2006 02:34
Picon
Favicon

Re: Please reject to rule on the ndiswrapper question

On Tue, Feb 28, 2006 at 02:05:16PM +0100, Wouter Verhelst wrote:

> I hereby appeal to the technical committee to reject to rule on this
> request, on the grounds that this is not a technical matter, and
> therefore falls outside the authority of the technical committee.

The Section: field of a Debian package's control file is a technical detail
of the package, as is the location of a package on the Debian mirror.  You
may consider that a particular decision has political motivations, but this
may be true of many technical decisions; the technical outcomes are still
under the purview of the Technical Committee.

Having been asked to override the maintainer's decision to list this package
as belonging to Section: misc instead of Section: contrib/misc, I believe
the committee has a responsibility to consider the issue.

> The question at hand is whether the statement "this package is not
> useful without non-free software, even though it will run without
> non-free software" is relevant wrt the requirement which is in Policy
> that no package in main must require any package outside of main to be
> built or executed. This is not a technical issue; it is simply a matter
> of interpretation of the social contract--which is clearly not a
> technical issue.

The question we have been asked to consider is, "which section should the
ndiswrapper package list in its control file?"  This is a technical
question, political factors notwithstanding.

--

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
(Continue reading)

Permalink | Reply | 0 comments |
headers
Gabor Gombas | 1 Mar 2006 02:46
Picon

Re: buildd and experimental

On Wed, Mar 01, 2006 at 01:04:17AM +0000, Brian M. Carlson wrote:

> I understand that different mail systems do different things (although I
> hope you're not using qmail[0]).

Not on my desktop, but I have no control over the institute's central
services.

> However, the code of conduct seems to
> point out that one should not Cc someone unless they specifically ask
> for it (a guideline that you neglected to follow, after I pointed this
> out to Mr. Bushnell).

Frankly, I never check the recipient list when I press "g" in mutt. I
assume that if you do not want to be CC'ed, then you can set up
Reply-To: to express that.

> But since some new or one-time posters may not
> realize this (and want to be Cc'd anyway), this provides a heuristic to
> guess if someone is actually subscribed, nothing more.

Assuming that a new poster will find and decipher the cryptic contents
of a non-standard e-mail header (that is even likely to be overwritten
if there are several spam filters in the delivery chain) is completely
unrealistic. The only sensible default is to assume that if there is a
specific requirement for the reply, then the Reply-To: header will be
set up accordingly (either automatically, or by the user who has the
requirement).

> If you are unsure, you could simply not Cc someone unless they ask.
(Continue reading)

Permalink | Reply | 91 comments |
headers
Steve Langasek | 1 Mar 2006 03:02
Picon
Favicon

Re: Please reject to rule on the ndiswrapper question

On Tue, Feb 28, 2006 at 10:52:49PM +0100, Jeroen van Wolffelaar wrote:
> On Tue, Feb 28, 2006 at 02:05:16PM +0100, Wouter Verhelst wrote:
> > The correct way to proceed would seem to be a ruling by a body
> > authorized to make authoritative interpretations of the Social Contract,
> > or, failing that (since I believe we have no such body), a General
> > Resolution.

> You (or whoever feels strongly about this) could also provide a
> motivation to ftpmaster <at>  why you believe so, and ask for
> reconsideration. Everybody, even the ftp-master team, can make
> mistakes, or be persuadated to change mind provided with a good
> argumentation. I also note that the only ftp-master team member that
> spoke up in this thread seems to be inclined to prefer contrib over main
> for this package. There was no mail at all to ftpmaster <at>  about this, nor
> a bugreport filed/reassigned to the ftp.debian.org pseudopackage.

> Shouldn't overruling of any sort only happen after talking to the
> involved parties failed to yield a satisfactionary response? C.f.
> Constitution 6.3.6:

> | Technical Committee makes decisions only as last resort.
> | 
> | The Technical Committee does not make a technical decision until efforts
> | to resolve it via consensus have been tried and failed, unless it has
> | been asked to make a decision by the person or body who would normally
> | be responsible for it.

> Of course, this paragraph only applies if one assumes the (initial)
> authority to make the main vs contrib decision is with ftp-master, but I
> believe it is.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Henrique de Moraes Holschuh | 1 Mar 2006 04:28
Picon
Favicon

Re: Mirror split, amd64 update

On Mon, 27 Feb 2006, Julien BLACHE wrote:
> "Joe Smith" <unknown_kev_cat <at> hotmail.com> wrote:
> > Anybody blindly mirroring ALL of ftp.debian.org via http or ftp would
> > end up with
> > two copies of the major architectures.
> >
> > However, doing that is a stupid thing anyway, and Debian has no
> > obligation to protect fools who do that.
> 
> Though you'll agree with me that protecting our mirror sponsors from
> such a waste of resources is a sensible thing to do.

Not to mention protecting ftp.d.o against such a waste of network bandwidth.

--

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
Permalink | Reply | 0 comments |
headers
Jeremy T. Bouse | 1 Mar 2006 04:40
Picon
Favicon

Re: [Pkg-xen-devel] Re: Packaing Xen 3.0 etc for Debian

	I take issue with this because we [the xen team] have never excluded
anyone and have tried to get all those people interested in solid Debian
packages of xen to come forth and help. I spent a good amount of time
before actually forming the Alioth project attempting to get in touch
with people that had already expressed interest. No one that has been
interested in helping has been told they couldn't.

	Regards,
	Jeremy

maximilian attems wrote:
> 
> so the xen team needs either to come with us or allow more of us to join.
> also basing their repo on waldi's work.
>
Permalink | Reply | 1 comment |

Gmane