Re: buildd and experimental

[Brian M. Carlson]

No need to Cc, I'm subscribed[0].

On Mon, 2006-02-27 at 23:39 -0800, Thomas Bushnell BSG wrote:
> "Brian M. Carlson" <[EMAIL PROTECTED]> writes:
> 
> > On Mon, 2006-02-27 at 22:59 -0800, Thomas Bushnell BSG wrote:
[gnucash not appearing on buildd.d.o; is this normal?]
> > Yes.  You want experimental.ftbfs.de, specifically:
> > .  Right now,
> > it's only showing kfreebsd-i386, but that's probably because
> > experimental packages haven't been built before (and that kfreebsd-i386
> > uses e.f.d for all packages building).
> 
> Very helpful, thanks.
> 
> How do I get the package queued more generally?  Is it automatic?

I'm not sure I understand.  Is your question "how does a package get in
to the build queues for experimental?"  If so, the answer is yes, it is
automatic.  You can see the queues at www.buildd.net.  For some reason,
it appears that "gnucash [is] not registered" at least for sparc[1].
However, that is probably because gnucash has never (at least, not
recently) been built for experimental before, and the non-sid buildds
just haven't realized that it's there yet.  They'll get to it, I'm sure.

[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
that I will ask to be Cc'd if necessary.  Not a complaint, just a note.
[1] And powerpc, but I noted that you actually uploaded the powerpc
binary.  I must remember that you upload powerpc binaries.


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

dspam in experimental. Please, test.

[Jesus Climent]

Hi, you all.

For those of you who enjoy to live in the bleeding edge, have loads of free
time or just feel like helping a bit, there is a dspam package in experimental
waiting for your love.

Please, give it a try and if you find a bug, report it.

Otherwise, should no showstoppers are found by the end of the week, it will be
uploaded to unstable.

The reason is not there yet is that we are treating with people's mail, and
that seems to be a sensitive subject if you suddenly are releaved from reading
flames by your favourite spam eater, when/if it decides to pipe * to /dev/null.

Cheers,
-- 
Jesus Climent  info:www.pumuki.org
Unix SysAdm|Linux User #66350|Debian Developer|2.6.15|Helsinki Finland
GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429  7E18 66FC 1D7F 8694 6D69

Don't "Sir" me young man, you have no idea who you're dealing with.
--Kay (Men in Black)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#122188: SSH rc?.d/S19 instead of S20, will this bug ever get closed? First submission is 5 years ago!

[Petter Reinholdtsen]

[Jeroen Massar]
> Just bump the priority to S19 this will make it start before the
> default value of all other daemons, on a more-or-less standard colo
> box that means waiting for large tools like mailman, mysql, postfix,
> apache2, makedev etc.

Would running the scripts in parallel solve you problem?  This is
possible with the current sysvinit package in etch and sid.  Look for
CONCURRENCY in /etc/init.d/rc to figure out how.

Also, you could make sure the sshd init.d script include correct
dependency information in LSB format,
http://wiki.debian.org/LSBInitScripts>.  Next, you can use
insserv to reorder all the scripts to make sure the scripts are
started in dependency order.  This is a bit higher risk at the moment,
as the runlevels 1 and 6 are not entirely correctly documented yet,
but work fine for the other runlevels.

Friendly,
-- 
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Bastian Blank]

On Tue, Feb 28, 2006 at 09:59:17AM +0100, maximilian attems wrote:
> xen 3.0 is out since the 6th of december!
> so it has seen considerable amount of production use since.
> as the xen userspace is tightly integrated to the xen kernel,
> it makes a lot of sense to release both in the same run.

The current package from pkg-xen is not releasable.

- Overwrites xen binary package without an upgrade procedure.
- Uses xen as source name, which at least the kernel team knows that
  this may easily break if more than one version is needed.
- All core binary packages lacks the version in the name.
- The installed xen image lacks a version in there name and another
  identification, which type it is.
- The hg-to-dist script is crap as hg is not able to show me the
  revision of the working copy, only the revision of the repo. As they
  propose that to build release tars, this will sooner or later break
  there releases.

> waldi is packaging the xen kernel in the linux-2.6 way.
> i'm confident that those packages get further enhanced.

Already mostly done.

Bastian

-- 
Power is danger.
-- The Centurion, "Balance of Terror", stardate 1709.2

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

[maximilian attems]

On Mon, 27 Feb 2006, Guido Trotter wrote:

> 
> Absolutely true! The current xen team is fully agrees on this position!
> 
> Guido

xen 3.0 is out since the 6th of december!
so it has seen considerable amount of production use since.
as the xen userspace is tightly integrated to the xen kernel,
it makes a lot of sense to release both in the same run.

the debian kernel team has always been open to valuable input.
beeing just annoyed and threatening to bypass on weblog doesn't
put your team on a good light.

waldi is packaging the xen kernel in the linux-2.6 way.
i'm confident that those packages get further enhanced.

-- 
maks


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#354654: general: fat32 gets corrupted

[Juan Piñeros]

Hello Cesare,

In machine1 hdparm is not currently installed, but it was 1 year ago when the 
machine1 had woody installed. I suppose hdparm does not change anything to 
the disk itself but only to the ide modules of the kernel?

In machine2, hdparm is installed, but I do not remember to have changed 
anything to the configuration of it (the log file I was maintaining for 
machine2 was lost during the disk crash). Do I have to check something or 
simply uninstall it?

Thanks for your reply,
Juan.

Le Tuesday 28 February 2006 01:56, Cesare Leonardi a écrit :
> Juan Piñeros wrote:
> > I do not find any logical explanation. No strange message in syslog, we
> > used "normal" programs (konqueror, thunderbird, oowriter) when sudenly
> > when try to save a file or read mail, an error appears just saying that
> > the directories did not exist any more.
>
> In the past i had a similar problem: sometimes, with no appearing
> regularity, some files simply got corrupted (filesystem was ext3).
> I simply couldn't understand what could be, since the hard disk seemed
> to be ok.
> Until i have remembered to have played with hdparm and put an optimized
> hdparm command line in a boot script.
> After i commented out that line, i hadn't no more corruption.
>
> I don't know if this can be your case.
> Regards.
>
> Cesare.

Re: Problems found by piuparts

[Thijs Kinkhorst]

On Mon, 2006-02-27 at 19:18 +0100, Thomas Viehmann wrote:
> Note that individual maintainers can already configure dput to stop the
> upload on lintian/linda errors.

Yes, but the point raised was whether it would be better to centralise
that. There are a lot of opportunities to run lintian but appearently a
lot of packages with errors/warnings are being uploaded.

> > Since these tools can already differentiate between errors and warnings,
> > it would make sense to define the subset for rejection as "all errors".
> 
> I'm afraid I have to disagree here. An old FSF address doesn't warrant a
> reject. Neither do false positives in lintian, they do happen (e.g. the
> last C++ transition would have been impeded, in fact l.d.o still shows
> lintian errors for "libfoo0c2a").
> Effectively, this would only foster an increase in questionable
> overrides. Lintian is a useful tool, but it's results need to be subject
> to review before filing bugs or doing rejects.

The original poster talked about a "subset of errors" to reject a
package on. I do think that introducing a third category of lintian
problems (warnings, errors, and now reject-errors) doesn't help, if we
want to go through with this, we need to clearly define what problems
are errors (i.e.: not acceptable in the archive) and reject them instead
of inventing another category.


Thijs


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

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

[Julien Danjou]

On Tue, Feb 28, 2006 at 09:59:17AM +0100, maximilian attems wrote:
> as the xen userspace is tightly integrated to the xen kernel,
> it makes a lot of sense to release both in the same run.

I hear that the kernel team don't want to maintain userspace tools.

> the debian kernel team has always been open to valuable input.

I have no doubt about that.

> beeing just annoyed and threatening to bypass on weblog doesn't
> put your team on a good light.
> 
> waldi is packaging the xen kernel in the linux-2.6 way.
> i'm confident that those packages get further enhanced.

Everybody seems to be agree that Xen should be maintain by a team.
For now, Bastian is *alone* working on his package. I know he told that
he had the kernel team on his side, but it seems that's the kernel team
don't claim to manage the Xen package.

Furthermore, Bastian did not answer to our request to work with us. It
seems that Bastian prefers to scorn us and our work instead of talking
about that.

As I already said, I don't really care about who is maintaining Xen, and
Bastian is welcome to join the Debian Xen team.

-- 
Julien Danjou
.''`.  Debian Developer
: :' : http://julien.danjou.info
`. `'  http://people.debian.org/~acid
  `-   9A0D 5FD9 EB42 22F6 8974  C95C A462 B51E C2FE E5CD


signature.asc
Description: Digital signature

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

[Steve Langasek]

On Tue, Feb 28, 2006 at 09:59:17AM +0100, maximilian attems wrote:
> On Mon, 27 Feb 2006, Guido Trotter wrote:

> > Absolutely true! The current xen team is fully agrees on this position!

> xen 3.0 is out since the 6th of december!
> so it has seen considerable amount of production use since.
> 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, 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?

> the debian kernel team has always been open to valuable input.
> beeing just annoyed and threatening to bypass on weblog doesn't
> put your team on a good light.

Holding all the members of the pkg-xen team responsible for what one of
their fellows has written in his blog would be petty and immature, and would
not exactly be the kind of encouragement one would hope to see from the
kernel team seeking the input of others interested in Xen packaging.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

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

[Guido Trotter]

On Tue, Feb 28, 2006 at 10:15:39AM +0100, Bastian Blank wrote:

Hi,

> The current package from pkg-xen is not releasable.
> 

Then why don't you just join and commit your fixes before anybody tried to
release it?

Guido


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#353277: ndiswrapper in main

[Stephen Gran]

This one time, at band camp, Hamish Moffatt said:
> flashplugin-nonfree itself contains scripts which I presume meet the
> DFSG. Do you think we should put it in main?

I assume this is a troll, and you have not bothered to read any of the
other messages in this tediously long thread.  

> > ndiswrapper is a piece of free software.  It does not need non-free tools
> > to build, and it will execute as a standalone app without any drivers.
> 
> (And do what? Display a usage screen? Anything more?)

This has already been answered.  Please feel free to read the archives.
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: Problems found by piuparts

[Peter Samuelson]

[Thijs Kinkhorst]
> Yes, but the point raised was whether it would be better to
> centralise that. There are a lot of opportunities to run lintian but
> appearently a lot of packages with errors/warnings are being
> uploaded.

Sometimes lintian tests have bugs / limitations - false positives which
*can* be fixed but haven't been.  In those cases, you're not supposed
to add a lintian override - instead, file a bug against lintian, and
live with the warning until the bug is fixed.

If you want to reject uploads which are not lintian-clean, you'll have
to convince the lintian maintainers to stop advocating this policy.


signature.asc
Description: Digital signature

Re: Bug#353277: ndiswrapper in main

[Stephen Gran]

This one time, at band camp, Thomas Bushnell BSG said:
> 
> The reason this interests me is that this seems to be the key
> question; it seems to me that if something is *now* not useful for
> free-software-only systems, it might be better placed in contrib (and
> the installer fixed, and perhaps not placed in contrib until after the
> installer is fixed), and only moved to main if/when there is a reason.

I'm guessing this thread reset means you didn't like the answers you
were getting?

I'm stopping for now, as this is getting tedious.
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Bug#354654: general: fat32 gets corrupted

[Juan Piñeros]

Hello Jacques,

I reply here below:

Le Tuesday 28 February 2006 00:56, jacques Normand a écrit :
> On Mon, Feb 27, 2006 at 11:33:19PM +0100, Juan Piñeros wrote:
> >   1 Raw_Read_Error_Rate 0x000d   100   100   050
> >  Pre-fail  Offline
> > -   51
> > 195 Hardware_ECC_Recovered  0x001a   100   100   000
> >  Old_age   Always
> > -   2
> > 199 UDMA_CRC_Error_Count0x003e   200   200   000
> >  Old_age   Always
> > -   9
>
> This is where your issue seems to live. I have never seen the read
> error and ecc corrected number not matching. It would mean that an error
> occurs but there has been no way to make it right so I would expect the
> read to be garbage... Did you see any corruption in your files? I mean
> data corrupted instead of metadata?

* IN MACHINE1:

In machine1, the files that were recovered after the crash were converted to 8 
characters dos names, but the files I tried to open were ok (I can not open 
all of them since this is 10GB). There were some unrecoverable files 
(following the recover soft said) but I suppose these were previously deleted 
files that were partially overwritten before the crash.

I never saw a file simply corrupted but still existing in machine1: simply 
they were ok, then suddenly a whole directory was lost.

One thing I remember now is that I installed smartools in machine1 two months 
before the crash (the disk was 2 years in use without problems before), but 
this is maybe unrelated with the crash.

* IN MACHINE2:

Here, the most recent files that were lost and after that recovered were 
totally corrupted. However we avoided to write on the disk with linux, and 
the disk recovery function of windows (the "System Volume Information") was 
disabled.

>
> Also, you say that sata does not support smart. That is not true, with
> one of the very recent kernels (2.6.15.4), you can get them. I have not
> much experience with the kernels shipped with debian. I always recompile
> my own. But some problems I had with an nfs server (in an HPC system)
> vanished when I upgraded from 2.6.12 to 2.6.14. There was a bug with the
> futex, and I think that was the source of my problems (race conditions
> are always nasty).

I can try to install a more recent kernel to make smart working, but the disk 
is new, is it useful? I have another question: why did etch installer chose 
the 2.6.12-1-386 kernel? Why not the 686? Maybe installing 686 can help? 
However this problem in machine2 remains classified as a bug and not as a 
problem related to user choices?

>
> As for the udma crc? That usually means that your controller/cable is
> going bad. Each time I have seen that, the whole system crashed
> corrupting files everywhere... That is pretty odd that you see the thig
> on two different system though.

So it seems that I have two different problems in the two machines? It seems 
that machine1's disk is to be replaced?

>
> jacques
>
> PS: With development kernels, always try to use the latest. Especially
> when you see a problem. (And I still consider the 2.6 as being a
> development version)

So if you install a very recent kernel from kernel.org, you have to apply a 
lot of patches before having it working? Is it better that I install a stock 
2.4 debian kernel on machine2? It can be difficult to downgrade from 2.6 to 
2.4 (udev, etc).

Thanks,
Juan.

Re: Bug#353277: ndiswrapper in main

[Hamish Moffatt]

On Tue, Feb 28, 2006 at 10:31:17AM +, Stephen Gran wrote:
> This one time, at band camp, Hamish Moffatt said:
> > flashplugin-nonfree itself contains scripts which I presume meet the
> > DFSG. Do you think we should put it in main?
> 
> I assume this is a troll, and you have not bothered to read any of the
> other messages in this tediously long thread.  

It's not a troll. In the quote that you trimmed, you said that all
dependencies are expressed as Depends: in the control file. I explained
why this is not the case. Please acknowledge that you understand this.

> > > ndiswrapper is a piece of free software.  It does not need non-free tools
> > > to build, and it will execute as a standalone app without any drivers.
> > 
> > (And do what? Display a usage screen? Anything more?)
> 
> This has already been answered.  Please feel free to read the archives.

I have read the whole thread, and it hasn't been answered adequately.

Your argument is simply that an unuseful driver is enough reason to
put ndiswrapper in main. You argue that contrib is not enough because
then it won't be available in the installer. This must mean that it's
needed at install time to use non-free drivers.


Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: buildd and experimental

[Gabor Gombas]

On Tue, Feb 28, 2006 at 08:59:46AM +, 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.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -

Re: Bug#353277: ndiswrapper in main

[Peter Samuelson]

  [Hamish Moffatt]
> > flashplugin-nonfree itself contains scripts which I presume meet
> > the DFSG. Do you think we should put it in main?

[Stephen Gran]
> I assume this is a troll

Your refusal to answer his question is itself an answer.

> > > ndiswrapper is a piece of free software.  It does not need non-free tools
> > > to build, and it will execute as a standalone app without any drivers.
> > 
> > (And do what? Display a usage screen? Anything more?)
> 
> This has already been answered.  Please feel free to read the archives.

Hamish, to save you the trouble of reading the archives, I'll tell you
the answer.  It doesn't display a usage screen.  It "provides an API"
for drivers to use.

Of course, since it's just an API for drivers, it does nothing if you
don't have a driver.  Well, it uses some of your kernel memory, and it
might print a status line to the kernel log.  But "It does nothing" is
obviously not an answer Stephen wanted to give.  Much better to imply
that a more satisfying answer might exist somewhere else in the thread.
(It doesn't.)

You know what would be great, though?  It would be great if some user
who uses ndiswrapper without non-free software, or indeed without any
drivers at all, would speak up.  Then we could stop arguing about
whether he exists.  'Cause, frankly, I don't think he does.


signature.asc
Description: Digital signature

Re: buildd and experimental

[Frank Lichtenheld]

On Mon, Feb 27, 2006 at 11:39:21PM -0800, Thomas Bushnell BSG wrote:
> How do I get the package queued more generally?  Is it automatic?

Yes. But the experimental buildds don't build from incoming, so you
have to wait at least one dinstall run for it to happen. And since you
uploaded gnucash shortly after the last one this is a big delay in your
case..

Gruesse,
-- 
Frank Lichtenheld <[EMAIL PROTECTED]>
www: http://www.djpig.de/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#353277: ndiswrapper in main

[Stephen Gran]

This one time, at band camp, Hamish Moffatt said:
> On Tue, Feb 28, 2006 at 10:31:17AM +, Stephen Gran wrote:
> > This one time, at band camp, Hamish Moffatt said:
> > > flashplugin-nonfree itself contains scripts which I presume meet the
> > > DFSG. Do you think we should put it in main?
> > 
> > I assume this is a troll, and you have not bothered to read any of the
> > other messages in this tediously long thread.  
> 
> It's not a troll. In the quote that you trimmed, you said that all
> dependencies are expressed as Depends: in the control file. I explained
> why this is not the case. Please acknowledge that you understand this.

Of course I understand this.  In another post I explained that examples
of packages that should be in contrib are things like installers for
non-free software.  Since flashplugin-nonfree is exactly one of these, I
have to assume you didn't read the rest of the thread, and were just
trolling.  Sorry if you just missed it under all the noise.

Since ndiswrapper is not an installer for non-free software, I don't
actually see what flashplugin-nonfree hass to do with the discussion.
OK?

> > > > ndiswrapper is a piece of free software.  It does not need non-free 
> > > > tools
> > > > to build, and it will execute as a standalone app without any drivers.
> > > 
> > > (And do what? Display a usage screen? Anything more?)
> > 
> > This has already been answered.  Please feel free to read the archives.
> 
> I have read the whole thread, and it hasn't been answered adequately.
> 
> Your argument is simply that an unuseful driver is enough reason to
> put ndiswrapper in main. You argue that contrib is not enough because
> then it won't be available in the installer. This must mean that it's
> needed at install time to use non-free drivers.

No, this was someone else's argument.  My argument is that ndiswrapper
successfully enables a kernel API to allow drivers that use an NDIS
stack to communicate with the linux network stack.  It does this,
whether or not those drivers are ever used.  Non-free drivers need
ndiswrapper to execute on linux.  ndiswrapper does not need non-free
drivers.  Does that make my position clear enough?
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: dspam in experimental. Please, test.

[Gabor Gombas]

On Tue, Feb 28, 2006 at 10:20:30AM +0100, Jesus Climent wrote:

> For those of you who enjoy to live in the bleeding edge, have loads of free
> time or just feel like helping a bit, there is a dspam package in experimental
> waiting for your love.

Finally :-) Thank you for packaging it!

> Please, give it a try and if you find a bug, report it.

I'm still running my locally built dspam version but I intend to check
out the Debian packages as soon as I'll have some time.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#353277: ndiswrapper in main

[Wouter Verhelst]

On Mon, Feb 27, 2006 at 01:50:16PM -0800, Thomas Bushnell BSG wrote:
> Or, perhaps it's not true that there are no free drivers for it.  The
> claim was also made that there was a single free driver out there for
> use with ndiswrapper, but others claimed that the hardware in question
> is already supported, and better, without the use of that driver.

The crip driver is actually not made for a specific piece of hardware;
it's really an encryption layer.

I fail to see whether if something works "better" is important. Using
OpenOffice.org also works "better" than using Microsoft Office under
wine, yet I have seen _many_ people asking whether it is possible to do
so.

> I don't know whether this is true, but if it is true, I would
> appreciate hearing why that should be treated differently than there
> being no such free driver at all.

I would appreciate hearing why you would think that it should be treated
the same. There is a driver, it is free, it works with ndiswrapper, so
there is a use case. Why should one perception on its usefulness be
relevant?

-- 
Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#353277: ndiswrapper in main

[Wouter Verhelst]

On Mon, Feb 27, 2006 at 03:23:05PM -0800, Thomas Bushnell BSG wrote:
> Adam McKenna <[EMAIL PROTECTED]> writes:
> 
> > On Mon, Feb 27, 2006 at 02:48:51PM -0800, Thomas Bushnell BSG wrote:
> >> The question is not whether there is such a dependency declared; the
> >> question is whether the software is useful without the use of non-free
> >> software.
> >
> > All right, who pushed the 'thread reset' button?
> 
> Unlike some, I do not have a perfect memory.  Moreover, I do not
> appreciate vague "we already discussed this" references.  I've read
> the damn thread; I ask the question because the previous discussion
> did not seem to actually *answer* the question.

It's been answered a zillion times already, you just didn't accept the
answer as valid. That's okay, but re-asking it again and again isn't
going to give you a different answer.

Can you please agree to disagree already?

-- 
Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Please reject to rule on the ndiswrapper question

[Wouter Verhelst]

Hi,

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

-- 
Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4


signature.asc
Description: Digital signature

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

[Bastian Blank]

On Tue, Feb 28, 2006 at 11:25:57AM +0100, Guido Trotter wrote:
> On Tue, Feb 28, 2006 at 10:15:39AM +0100, Bastian Blank wrote:
> > The current package from pkg-xen is not releasable.
> Then why don't you just join and commit your fixes before anybody tried to
> release it?

I can.

Bastian

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


signature.asc
Description: Digital signature

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

[Sven Luther]

On Tue, Feb 28, 2006 at 02:02:34PM +0100, Bastian Blank wrote:
> On Tue, Feb 28, 2006 at 11:25:57AM +0100, Guido Trotter wrote:
> > On Tue, Feb 28, 2006 at 10:15:39AM +0100, Bastian Blank wrote:
> > > The current package from pkg-xen is not releasable.
> > Then why don't you just join and commit your fixes before anybody tried to
> > release it?
> 
> I can.

:)

Guido, be warned that Bastian often communicates with a few monosylabes and
SVN commits :) This doesn't make working with him too problematic usually
though :)

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#353277: ndiswrapper in main

[Wouter Verhelst]

On Mon, Feb 27, 2006 at 04:45:04PM -0800, Thomas Bushnell BSG wrote:
> If there are no uses of it (actual *uses*, where it is *useful*) with
> free programs, then it sure seems like a wrapper for non-free
> programs.

You want a useful use case of the NDIS CIPE driver? Allright, I'll give
you one.

I'm a GNU/Linux consultant. It is my job to help people with installing,
configuring, and generally using GNU/Linux. I prefer to use non-free
software as little as possible, and most of my own systems currently
have no non-free software installed (although not all of them).

On the other hand, I have no say over what a customer would want; and if
my choice is to either help them out with non-free software or loose the
contract, then I will do the former. That still doesn't mean that I'd
like to use non-free software myself, so I'll avoid it if possible.

The CIPE driver doesn't actually need hardware, since it is an
encryption layer. As such, I can use it as a test-case for ndiswrapper,
to find out how the latter works and to actually be able to test whether
I set it up correctly. If a customer should at one point ask me to help
them out with setting up ndiswrapper, I can then first experiment on my
own with the CIPE driver, and then help them out with their non-free
driver.

Want another one? Here goes.

A kernel hacker might be interested in helping out to hack on
ndiswrapper itself, but not be very interested in having their laptop
crash every five minutes by loading experimental versions of the driver.
An obvious solution would be to use a virtualization environment like
qemu, but then you can't use a driver that requires specific hardware.
The fact that CIPE exists, which does not have any hardware
requirements, can allow you to test stuff without having an unstable
computing environment for other things.

Right, so there's two examples. But then again, the above two are all
based on the assumption that it is impossible to test out ndiswrapper
without an NDIS driver -- and that having something in main for testing
purposes only would be something some zealot might not accept (for
clarity, I'm not claiming you are a zealot of any sort). So let's think
of another use case:

I don't know about you, but personally, I had never heard about the CIPE
driver before, while everyone here seems to know ndiswrapper already. It
is conceivable that projects which attract a high level of publicity
(such as ndiswrapper) also attract a lot more developers than projects
which do not (such as CIPE). Indeed, it would seem that there are
currently only a handful of developers working on CIPE.

Now consider that there is a change in some future version of the
kernel, which is security-related, and which breaks the kernel API wrt
network drivers incompatibly. While not incredibly regular, it most
certainly is not unlikely, either. Depending on the complexity of the
change, it might be that it will take a considerate effort to update
drivers to the newer Linux API, which the handful of people working on
the CIPE driver will take ages to do. The ndiswrapper folks, however,
because of their relatively higher number of developers, might get the
job done a lot sooner. People who don't want to be vulnerable (which
might be "all of them", seen as how this is about crypto intended for
use in VPN environments) will want to use the ndiswrapper driver until
the native driver has been updated.

There, that's three. I'm sure you can come up with more use cases
yourself; and I'm sure I can come up with more if you think none of the
above are any convincing. In the mean time, I'll tell you that just
because you can't come up with any reasonable use case of free software
without non-free software, even if the main purpose of that free
software is to use that non-free software, that this doesn't mean there
isn't any such use case.

-- 
Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4


signature.asc
Description: Digital signature

Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)

[Gabor Gombas]

On Mon, Feb 27, 2006 at 10:04:59AM -0800, Adam McKenna wrote:

> Taking it out of main moves us in the wrong direction if our goal is to
> give our users a *usable* operating system, as opposed to some kind of
> 'proof of concept' OS that some people here seem to want to create, but
> that the majority of our users will not want to use.

One point that nobody raised so far: _reliable_ working on ndiswrapper
depends on the 16k-stack patch that is not available in Debian AFAIK.
Without that patch, drivers requiring ndiswrapper (being free or not)
only work by pure chance. So whatever the Depends: line says,
ndiswrapper for any practical purposes depends on software that is not
in main.

So the question is: does a piece of software, that is known not to work
reliably and will never work reliably with the (Linux) kernels shipped
by Debian, have a place in main?

There are efforts from time to time to make the 4K stack the default on
i386 upstream; if/when that happens, ndiswrapper will stop working with
stock Linux kernels. What will be the answer then? Other distributions
like Fedora have already switched to 4K stacks...

Gabor

p.s. I personally still do not care whether ndiswrapper is in main or
in contrib...

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#353277: ndiswrapper in main

[Wouter Verhelst]

On Mon, Feb 27, 2006 at 05:21:56PM -0800, Thomas Bushnell BSG wrote:
> Stephen Gran <[EMAIL PROTECTED]> writes:
> 
> >> In any case, the real point here is the following statement from
> >> 2.2.2, which says that contrib is for "wrapper packages or other sorts
> >> of free accessories for non-free programs."
> >
> > Since ndiswrapper's main purpose is to create a kernel API to allow
> > drivers designed for a different API to communicate with the kernel, I
> > don't think this counts as a wrapper.  ndiswrapper does what it sets out
> > to do, whether or not any software (free or not) uses that API.
> 
> That's curious.  It's described as a wrapper in the package name, the
> Debian package description, and the upstream webpage.
> 
> In both cases, it is specifically documented as being for use with
> non-free software.  It's specifically said that its purpose is to deal
> with the fact that some vendors "refuse to release hardware
> specifications" and that for such hardware, users are stuck with
> non-free NDIS drivers.
> 
> While we are trusting the package maintainer, surely we should trust
> the package maintainer to be correctly documenting the program?  
> 
> However, if the description is incorrect, then perhaps it should be
> changed.  I don't really know, because I'm not an expert on the
> technical question here.

There are a few ways to interpret the word "wrapper". Ndiswrapper could
certainly be seen as a "wrapper" of sorts, but not in the way that
policy means. A "wrapper", as used in policy, is a script or small
executable that will set up the environment (LD_PRELOAD,
LD_LIBRARY_PATH, PATH, ...) and then run the "actual" binary.
/usr/bin/firefox on a Debian system, for example, is a wrapper in the
meaning that policy is talking about.

ndiswrapper is not.

> > No, the question is, is ndiswrapper a functionally complete program?
> 
> Are you saying that ndiswrapper is useful all by itself, without any
> drivers at all?  I have asked this question before, but didn't get an
> answer; I really don't know.  What functions does it provide, in the
> absence of an NDIS driver?

I've given a few answers to that question in another post I just posted;
here, I'd like to add that the function anything provides is irrelevant
if you are discussing its freeness.

If someone gives me a horse, then this is a free horse (as in beer).
Yet, since I don't know how to ride a horse, I'll have to find someone
who will teach me how to do so, which may well cost money. This will
make the adventure be not free (as in beer) to me; but I could of course
also just be someone who enjoys watching horses, without riding them.
Does that make it a non-free horse?

The same reasoning can be applied to ndiswrapper's freeness (as in
speech). Ndiswrapper itself is free, and does not require the use of any
non-free software to be run. Yet, if you have no free drivers to use
ndiswrapper, it could be argued that it is not really useful. But
usefulness is something that Debian considers in deciding whether
something is free or not (why else do you think we compile KDE, GNOME,
mozilla, *and* emacs for m68k?). If it runs, can do something as
designed, then it is ok for it to go into main. Ndiswrapper complies
with those requirements.

[...]

-- 
Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Guido Trotter]

On Tue, Feb 28, 2006 at 02:17:45PM +0100, Sven Luther wrote:

Hi,

> > I can.
> 
> :)
> 
> Guido, be warned that Bastian often communicates with a few monosylabes and
> SVN commits :) This doesn't make working with him too problematic usually
> though :)
> 

We've been a bit more chatty, for now, but I guess we will survive as long as
the commits are agreed by everyone... ;) At this point I propose Jeremy to add
Bastian to the pkg-xen alioth project (he's the only one who can do that, I
think) and we can go ahead! :)

Guido


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: buildd and experimental

[Wouter Verhelst]

On Mon, Feb 27, 2006 at 10:59:01PM -0800, Thomas Bushnell BSG wrote:
> I recently uploaded gnucash 1.9.1 to Debian experimental, but this
> doesn't seem to have affected buildd.debian.org.  Is this normal?

That question has already been adequately answered by other people in
this thread.

However, for clarity, I'll add that the experimental buildd network
behaves slightly different from the unstable buildd network, and this
may require some work from your end:

* First, there is no guarantee that the experimental buildd network will
  build your package. We do a best effort to successfully build as many
  packages as possible, but it is not possible to guarantee that every
  package will be built on all architectures for experimental. This is
  partially because of the other points, but also because some
  architectures simply do not have enough buildd power for experimental;
  m68k, for example, currently builds experimental with only one buildd
  host (quickstep.nixsys.be), a 25Mhz 68040, and cannot keep up (I do
  plan to add jazz.nixsys.be when I have the time; but that's not going
  to happen very soon, I'm afraid). This is not considered to be a
  problem, as experimental is not as important as unstable.
* If you need packages from experimental to build, you must specify your
  build-dependencies on those packages in more detail. For example, if
  there is a foo_0.1_all.deb in unstable, and a foo_0.2_all.deb in
  experimental; a bar_0.1_all.deb in unstable, and a bar_0.2_all.deb in
  experimental; your package requires the use of bar, and you want to
  build against packages in experimental; and bar depends on foo (with
  the bar version in experimental having a versioned depends on the foo
  version in experimental); then you need have a versioned build-depend
  on not only bar, but also foo for the buildd build to succeed. This is
  because apt cannot be set up to take packages from unstable by default
  but to take them from experimental if that is the only way to resolve
  a dependency that occurs in a case of something like "apt-get install
  bar=0.2"
* The above currently isn't even true for many of the architectures; to
  my knowledge, only m68k and one other architecture that I can't
  remember off the top of my head currently behaves like that. Other
  architectures will simply fail to build a package that has versioned
  build-dependencies which can only be resolved with packages from
  experimental.
  This, however, is a bug, and AAUI one that is in the process of being
  resolved.

Note that this is all about the experimental buildd network, i.e., those
machines that actually build packages from experimental. That is not the
same thing as "machines that send their logs to experimental.ftbfs.de",
which includes machines who build for unstable only and (should) behave
like "regular" buildd machines.

-- 
Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4


signature.asc
Description: Digital signature

Re: buildd and experimental

[Wouter Verhelst]

On Tue, Feb 28, 2006 at 03:13:34PM +0100, Wouter Verhelst wrote:
>   This, however, is a bug, and AAUI one that is in the process of being
>   resolved.
[mumble, mumble]

No, not Apple Attachment Unit Interface, "AIUI": As I Understand It.

-- 
Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4


signature.asc
Description: Digital signature

Re: Bug#353277: ndiswrapper in main

[Gabor Gombas]

On Tue, Feb 28, 2006 at 02:36:52PM +0100, Wouter Verhelst wrote:

> The CIPE driver doesn't actually need hardware, since it is an
> encryption layer. As such, I can use it as a test-case for ndiswrapper,
> to find out how the latter works and to actually be able to test whether
> I set it up correctly. If a customer should at one point ask me to help
> them out with setting up ndiswrapper, I can then first experiment on my
> own with the CIPE driver, and then help them out with their non-free
> driver.

In this case I do not want to hire you as a consultant ever, thank you
very much. You should know that Windows gives ~16k stack to network
drivers, while current Linux+ndiswrapper only gives ~6k if you are
lucky, and ~4k if/when the "4K stacks" option becomes the default. So
even if your test case works it _does not_ give any indication that any
other non-free driver will also work. A non-free driver that happens to
use 10k stack will work perfectly on Windows but will not work on the
kernels shipped by Debian at all.

> A kernel hacker might be interested in helping out to hack on
> ndiswrapper itself, but not be very interested in having their laptop
> crash every five minutes by loading experimental versions of the driver.
> An obvious solution would be to use a virtualization environment like
> qemu, but then you can't use a driver that requires specific hardware.
> The fact that CIPE exists, which does not have any hardware
> requirements, can allow you to test stuff without having an unstable
> computing environment for other things.

You are not serious that such a developer would be incapable to locate
the ndiswrapper source if it was in contrib instead of main, are you?
Also, such a developer would be a fool to use the Debian-packaged
version of ndiswrapper instead of the latest upstream snapshot, given
the long time between stable Debian releases.

> Now consider that there is a change in some future version of the
> kernel, which is security-related, and which breaks the kernel API wrt
> network drivers incompatibly.

Unlikely, whoever breaks in-kernel API is responsible for fixing all
in-kernel drivers as well. And IMHO there are more Linux network driver
maintainers than ndiswrapper maintainers, and they are quite capable of
morphing a huge number of drivers at once.

On the other hand, the kernel has already broken compatibility with
ndiswrapper (16k stacks were never part of the official kernel) and
there is effor to break it even more (if you want to look at it from
this angle). Just look up the "4k stack" flamewars in LKML archives.

Fedora already ships it's kernels with 4k stacks.

Please stop these excuses. "ndiswrapper will remain in main because the
sky is blue" is a lot more acceptable reasoning than anything that
popped up in this thread so far. If you _really_ want to help
ndiswrapper, then work on solving the 4k-stack issue; that would help a
_lot_ more than this silly thread.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -

Re: Please reject to rule on the ndiswrapper question

[Bas Zoetekouw]

Hi Wouter!

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

Wouldn't the ftp-masters be the right authority for this issue?  It is
them who decide if the package can go into main or not.

-- 
Kind regards,
++
| Bas Zoetekouw  | GPG key: 0644fab7 |
|| Fingerprint: c1f5 f24c d514 3fec 8bf6 |
| [EMAIL PROTECTED], [EMAIL PROTECTED] |  a2b1 2bae e41f 0644 fab7 |
++ 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#353277: ndiswrapper in main

[Wouter Verhelst]

On Tue, Feb 28, 2006 at 03:25:37PM +0100, Gabor Gombas wrote:
> On Tue, Feb 28, 2006 at 02:36:52PM +0100, Wouter Verhelst wrote:
> 
> > The CIPE driver doesn't actually need hardware, since it is an
> > encryption layer. As such, I can use it as a test-case for ndiswrapper,
> > to find out how the latter works and to actually be able to test whether
> > I set it up correctly. If a customer should at one point ask me to help
> > them out with setting up ndiswrapper, I can then first experiment on my
> > own with the CIPE driver, and then help them out with their non-free
> > driver.
> 
> In this case I do not want to hire you as a consultant ever, thank you
> very much. You should know that Windows gives ~16k stack to network
> drivers, while current Linux+ndiswrapper only gives ~6k if you are
> lucky, and ~4k if/when the "4K stacks" option becomes the default. So
> even if your test case works it _does not_ give any indication that any
> other non-free driver will also work.

No, but it will allow me to find out how the bloody thing is _supposed_
to work, even without having direct access to the customer's hardware.

There is nothing to prevent me from experimenting a bit more at the
customer's site; but at least this can give me a headstart.

[...]
> > A kernel hacker might be interested in helping out to hack on
> > ndiswrapper itself, but not be very interested in having their laptop
> > crash every five minutes by loading experimental versions of the driver.
> > An obvious solution would be to use a virtualization environment like
> > qemu, but then you can't use a driver that requires specific hardware.
> > The fact that CIPE exists, which does not have any hardware
> > requirements, can allow you to test stuff without having an unstable
> > computing environment for other things.
> 
> You are not serious that such a developer would be incapable to locate
> the ndiswrapper source if it was in contrib instead of main, are you?

The question was not whether I developer would be able to locate the
source if it were in contrib; the question was whether there is a real
use case of the NDIS version of the CIPE driver. I gave you one. Well,
three actually.

[...]
> > Now consider that there is a change in some future version of the
> > kernel, which is security-related, and which breaks the kernel API wrt
> > network drivers incompatibly.
> 
> Unlikely, whoever breaks in-kernel API is responsible for fixing all
> in-kernel drivers as well.

CIPE is currently not an in-kernel driver.

-- 
Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Please reject to rule on the ndiswrapper question

[Michael Poole]

Bas Zoetekouw writes:

> Hi Wouter!
> 
> You 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.
> 
> Wouldn't the ftp-masters be the right authority for this issue?  It is
> them who decide if the package can go into main or not.

The package is already in main.  The person who filed this bug thinks
the maintainer and ftp-master decisions were wrong and should be
changed or overruled.

Michael Poole


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Please reject to rule on the ndiswrapper question

[Wouter Verhelst]

On Tue, Feb 28, 2006 at 09:45:00AM -0500, Michael Poole wrote:
> Bas Zoetekouw writes:
> 
> > Hi Wouter!
> > 
> > You 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.
> > 
> > Wouldn't the ftp-masters be the right authority for this issue?  It is
> > them who decide if the package can go into main or not.
> 
> The package is already in main.  The person who filed this bug thinks
> the maintainer and ftp-master decisions were wrong and should be
> changed or overruled.

Right. My take, however, is that they are not technical issues and are
therefore not suited for the technical committee; since the body with
authority over this interpretation already made a decision, the only way
to overrule would seem to be a GR.

No, I'm not willing to propose such a GR, because I do not think that
overruling this decision is required.

-- 
Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dspam in experimental. Please, test.

[Florent Bayle]

Le Mardi 28 Février 2006 10:20, Jesus Climent a écrit :
> Hi, you all.
>
> For those of you who enjoy to live in the bleeding edge, have loads of free
> time or just feel like helping a bit, there is a dspam package in
> experimental waiting for your love.
>
> Please, give it a try and if you find a bug, report it.

I'm using dspam packages since 3.6.2-3, and I've no problems with them.

>
> Otherwise, should no showstoppers are found by the end of the week, it will
> be uploaded to unstable.

Thanks for your work. I think that dspam is a very great project, and seeing 
it in Debian is very nice. 

>
> The reason is not there yet is that we are treating with people's mail, and
> that seems to be a sensitive subject if you suddenly are releaved from
> reading flames by your favourite spam eater, when/if it decides to pipe *
> to /dev/null.

Of course.

Some statistics since I use dspam :

Overall accuracy 98.456%
(SPAM messages caught + Good messages delivered) / Total number of 
messages
Spam identification 90.087%
(Spam catch rate only)
Spam ratio 15.416%
Total SPAM messages (both caught & missed) / Total number of messages

SPAM messages
194 missed1763 caught
Good messages
2 missed10736 delivered

Only 2 false positives at the begining, very impressive IMHO.

-- 
Florent


pgphgp9uhPA09.pgp
Description: PGP signature

Re: Please reject to rule on the ndiswrapper question

[Bas Zoetekouw]

Hi Michael!

[Cc'ed Manoj, as he's the authority on the constitution...]

You wrote:

> > Wouldn't the ftp-masters be the right authority for this issue?  It is
> > them who decide if the package can go into main or not.
> 
> The package is already in main.  The person who filed this bug thinks
> the maintainer and ftp-master decisions were wrong and should be
> changed or overruled.

Well, I guess that on non-technical issues, the ftp-masters can indeed
only be overruled by a GR.  I agree with Wouter that the Technical
Committee has no authority here.

-- 
Kind regards,
++
| Bas Zoetekouw  | GPG key: 0644fab7 |
|| Fingerprint: c1f5 f24c d514 3fec 8bf6 |
| [EMAIL PROTECTED], [EMAIL PROTECTED] |  a2b1 2bae e41f 0644 fab7 |
++ 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

4GB address space

[Mad Props]

Hi,

i'm interested in whether it is possible to modify the Linux kernel so that
user applications can use the whole 4GB of virtual address space while the
kernel runs it's own AS.

If yes, how complicated would that be ??

Thanks,

Thomas

 


-- 
DSL-Aktion wegen großer Nachfrage bis 28.2.2006 verlängert:
GMX DSL-Flatrate 1 Jahr kostenlos* http://www.gmx.net/de/go/dsl


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: AT&T Korn Shell

[Josh Hurst]

On 2/20/06, Andrew Porter <[EMAIL PROTECTED]> wrote:
>  On Sat, 2006-02-18 at 14:19 +0100, Josh Hurst wrote:
>
>
>  Does the Debian ksh93 package include libast and libshell?
>
>
>  No -
>
>  dpkg -L ksh
>  /.
>  /bin
>  /bin/ksh93
>  /usr
>  /usr/bin
>  /usr/bin/shcomp
>  /usr/share
>  /usr/share/man
>  /usr/share/man/man1
>  /usr/share/man/man1/ksh93.1.gz
>  /usr/share/man/man1/shcomp.1.gz
>  /usr/share/man/fr
>  /usr/share/man/fr/man1
>  /usr/share/man/fr/man1/shcomp.1.gz
>  /usr/share/ksh
>  /usr/share/ksh/functions
>  /usr/share/ksh/functions/dirs
>  /usr/share/ksh/functions/popd
>  /usr/share/ksh/functions/pushd
>  /usr/share/doc
>  /usr/share/doc/ksh
>  /usr/share/doc/ksh/OBSOLETE
>  /usr/share/doc/ksh/example.kshrc
>  /usr/share/doc/ksh/copyright
>  /usr/share/doc/ksh/COMPATIBILITY.gz
>  /usr/share/doc/ksh/RELEASE.gz
>  /usr/share/doc/ksh/RELEASE88.gz
>  /usr/share/doc/ksh/RELEASE93.gz
>  /usr/share/doc/ksh/PROMO.mm.gz
>  /usr/share/doc/ksh/changelog.Debian.gz
>  /usr/share/menu
>  /usr/share/menu/ksh
Seems these libraries are statically linked. It may be worth to think
about providing shared library versions since there are many
applications which can use libshell and libast. For example AT&T
claims a 30%+ performance improvement for perl applications if sfio
(provided by libast) is used instead of stdio.
--
Josh

Re: 4GB address space

[Wouter Verhelst]

On Tue, Feb 28, 2006 at 04:19:45PM +0100, Mad Props wrote:
> Hi,
> 
> i'm interested in whether it is possible to modify the Linux kernel so that
> user applications can use the whole 4GB of virtual address space while the
> kernel runs it's own AS.
> 
> If yes, how complicated would that be ??

Run "make menuconfig"; then, select "Processor type and features", and
"High Memory Support". Done.

-- 
Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Guido Trotter]

On Mon, Feb 27, 2006 at 02:29:51PM +0100, Sven Luther wrote:

Hi,

> I guess that if people are able to find a kernel source tree outside of
> debian, they are perfectly capable of downloading and applying a patch too.
> 
> Just include an URL to wherever such a patch is in the README.Debian of the
> packages, should be enough.
> 

Yes, this is the current plan! Thanks for your suggestions! :)

Guido


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#354732: ITP: omgifol -- python library for manipulating doom-style WAD files

[Jon Dowland]

Package: wnpp
Severity: wishlist
Owner: Jon Dowland <[EMAIL PROTECTED]>

* Package name: omgifol
  Version : 0.2
  Upstream Author : Fredrik Johansson
* URL : http://www.dd.chalmers.se/~frejohl/doom.html
* License : MIT-style
  Description : python library for manipulating doom-style WAD files

omgifol (Oh My God, It's Full of Lumps) is a python library for
manipulating doom-style WAD files. It includes general purpose
lump-manipulation routines as well as more specific map and texture
editing facilities.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.11-jmtd
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 4GB address space

[Steinar H. Gunderson]

On Tue, Feb 28, 2006 at 04:19:45PM +0100, Mad Props wrote:
> i'm interested in whether it is possible to modify the Linux kernel so that
> user applications can use the whole 4GB of virtual address space while the
> kernel runs it's own AS.

Why would you want to do such a thing? If you really need that much address
space, getting an amd64 machine is cheap these days.

/* Steinar */
-- 
Homepage: http://www.sesse.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Cord Beermann]

Hallo! Du (Amaya) hast geschrieben:
>Cord Beermann wrote:
>> Also we (the listmasters) don't train the bayes-filter, 
>
>May I ask why?

You may. ;-)

I looked into this and found that we automagically train the bayes
with the spam we get, but we don't train in the ham. 

Another thing for the everlasting todo-list.

Cord
-- 
http://lists.debian.org


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

USB-to-UART converter

[kos]

Hi,

I am trying to use a USB-to-UART (8 port) converter. I expected it to
get recognized and create device names like /dev/ttyUSB0, /dev/ttyUSB1
./dev/ttyUSB7. However, this did not happen.

[Surprisingly, the single USB-to-UART (1 port) converter works fine and
/dev/ttyUSB0 is available for my use]

I did

# dmesg | tail

and found the following output...

--
hub.c: USB hub found
hub.c: 4 ports detected
hub.c: new USB device 00:1d.1-1.1, assigned address 3
usb.c: USB device 3 (vend/prod 0x403/0x6010) is not claimed by any
active driver.
hub.c: new USB device 00:1d.1-1.2, assigned address 4
usb.c: USB device 4 (vend/prod 0x403/0x6010) is not claimed by any
active driver.
hub.c: new USB device 00:1d.1-1.3, assigned address 5
usb.c: USB device 5 (vend/prod 0x403/0x6010) is not claimed by any
active driver.
hub.c: new USB device 00:1d.1-1.4, assigned address 6
usb.c: USB device 6 (vend/prod 0x403/0x6010) is not claimed by any
active driver.
---

Does anyone know what this means? Can anybody help me with getting my
USB-to-UART working?

The converter that I am using is from "vscom". I downloaded some driver
from their website for linux. But, these drivers does not build.

Has anyone faced similar problem?

with regards,
- KOS


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Re: /lib/modules//volatile on tmpfs

[Sergio Callegari]

As far as I know, it should exist in Debian too.
For instance, if you look at http://www.phor.net/phpsysinfo-dev/, you'll 
find an updated log of the system information of an host with 
Debian/testing. And it has this dir.

Same if you look at http://s1cness.is-a-geek.com/phpsysinfo/

It is mentioned even in Debian mailing lists: 
http://lists.debian.org/debian-user/2006/01/msg00088.html

yet no one on the Ubuntu forum nor anywhere seems to have a clue about it...

Sergio


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)

[Adam McKenna]

On Tue, Feb 28, 2006 at 02:38:53PM +0100, Gabor Gombas wrote:
> One point that nobody raised so far: _reliable_ working on ndiswrapper
> depends on the 16k-stack patch that is not available in Debian AFAIK.
> Without that patch, drivers requiring ndiswrapper (being free or not)
> only work by pure chance. So whatever the Depends: line says,
> ndiswrapper for any practical purposes depends on software that is not
> in main.

I've been using ndiswrapper with stock kernels since 0.2 or 0.3, and I have
never heard of the '16k-stack patch'.

--Adam


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 4GB address space

[Jim Crilly]

On 02/28/06 04:19:45PM +0100, Mad Props wrote:
> Hi,
> 
> i'm interested in whether it is possible to modify the Linux kernel so that
> user applications can use the whole 4GB of virtual address space while the
> kernel runs it's own AS.
> 
> If yes, how complicated would that be ??
> 
> Thanks,
> 
> Thomas

Yes it's possible and there have been patches posted on lkml that do that,
but it incurrs a performance hit and it's usually easier just to get a
64-bit machine these days.

Jim.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Re: /lib/modules//volatile on tmpfs

[Matt Zimmerman]

On Tue, Feb 28, 2006 at 06:20:47PM +0100, Sergio Callegari wrote:
> As far as I know, it should exist in Debian too.

No, it doesn't.

-- 
 - mdz


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Is there some guideline saying that native packages should be avoided?

[Panu Kalliokoski]

Hello, I'm a long-time debian user that aspires to be a DD someday.  I
recently posted many RFS's on debian-mentors, some of which were
software that I'm both the upstream author and packager of.  These
packages are native Debian packages, i.e. their source distribution is
only one .tar.gz.  It was pointed to me that packages should be
preferably non-native, even if no source release without the debian/
subdir has ever existed.

I would like to ask whether there really is such a guideline, and if so,
which are the technical / political reasons that lead to it.  I have
been informed about one technical detail, which is that when you only
make changes to packaging, you only need to change the .diff.gz.
However, I don't understand the benefit of this, and I've been
maintaining my software as debian-native projects for many years,
without any observable problems.

Panu Kalliokoski

ps. please cc me, because I'm not subscribing to -devel.

-- 
personal contact:   [EMAIL PROTECTED], +35841 5323835
technical contact:  [EMAIL PROTECTED], http://www.iki.fi/atehwa/
PGP fingerprint:0EA5 9D33 6590 FFD4 921C  5A5F BE85 08F1 3169 70EC


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Is there some guideline saying that native packages should be avoided?

[Lars Wirzenius]

ti, 2006-02-28 kello 19:39 +0200, Panu Kalliokoski kirjoitti:
> I would like to ask whether there really is such a guideline, and if so,
> which are the technical / political reasons that lead to it.

There is a somewhat common feeling among Debian developers that Debian
packaging should be separate from upstream sources, for various reasons.

a) If there is a bug in the packaging, it can be fixed without uploading
a new upstream source tarball. Assuming upstream version is 1.2, the
first Debian version would be 1.2-1, and the fixed one would be 1.2-2.
The .orig.tar.gz file would be the same for 1.2-1 and 1.2-2.

b) Keeping upstream and packaging separate makes things easier when they
no longer are maintained by the same person. Upstream doesn't have to
maintain debian/* anymore, and the Debian package maintainer doesn't
need to feed his changes to upstream and wait for them to be
incorporated in a new release.

c) Often, though obviously not always, the upstream developer isn't
following Debian packaging policies and practicies to the extent a
dedicated Debian developer would. Thus, if the package gets uploaded to
Debian, its Debian packaging will differ from upstreams, leading to
confusing and .diff.gz files that are hard to read, since they don't
contain all the Debian packaging.

d) It doesn't really make it harder to keep packaging files separate. It
may require a step or two extra to the script that builds a release, but
it should be easy enough to do that.

-- 
Our technology is sadly insufficiently advanced.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)

[David Weinehall]

On Tue, Feb 28, 2006 at 09:36:46AM -0800, Adam McKenna wrote:
> On Tue, Feb 28, 2006 at 02:38:53PM +0100, Gabor Gombas wrote:
> > One point that nobody raised so far: _reliable_ working on ndiswrapper
> > depends on the 16k-stack patch that is not available in Debian AFAIK.
> > Without that patch, drivers requiring ndiswrapper (being free or not)
> > only work by pure chance. So whatever the Depends: line says,
> > ndiswrapper for any practical purposes depends on software that is not
> > in main.
> 
> I've been using ndiswrapper with stock kernels since 0.2 or 0.3, and I have
> never heard of the '16k-stack patch'.

The thing is: Windows has a 16k stack for drivers.  The Linux kernel
has either a 4k + 4k stack or an 8k stack, depending on what version of
the kernel you use.  Most drivers don't need >8k stack (some might
even work with 4k too), but some do, thus you need to patch the kernel
to provide 16k stacks (this is really bad for other reasons).


Regards: David Weinehall
-- 
 /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window   (\
//  ~   //  Diamond-white roses of fire //
\)  http://www.acc.umu.se/~tao/(/   Beautiful hoar-frost   (/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#353277: ndiswrapper in main

[Thomas Bushnell BSG]

Stephen Gran <[EMAIL PROTECTED]> writes:

> This one time, at band camp, Thomas Bushnell BSG said:
>> 
>> The reason this interests me is that this seems to be the key
>> question; it seems to me that if something is *now* not useful for
>> free-software-only systems, it might be better placed in contrib (and
>> the installer fixed, and perhaps not placed in contrib until after the
>> installer is fixed), and only moved to main if/when there is a reason.
>
> I'm guessing this thread reset means you didn't like the answers you
> were getting?

No, it's that people kept on refusing to answer simple questions, and
after a bit of that, they said they had already answered them (when
they in fact had not), and now they complain that it's a "thread
reset" to continue to ask the questions.

Look, if the position is that ndiswrapper is, at present, only useful
with non-free software, but it should, even so, be in Debian main, I'm
prepared to entertain that possibility.  But I can't even figure out
what you *are* saying, because everytime I ask, people start getting
cagey.

Thomas
 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#353277: ndiswrapper in main

[Thomas Bushnell BSG]

Wouter Verhelst <[EMAIL PROTECTED]> writes:

> On Mon, Feb 27, 2006 at 01:50:16PM -0800, Thomas Bushnell BSG wrote:
>> Or, perhaps it's not true that there are no free drivers for it.  The
>> claim was also made that there was a single free driver out there for
>> use with ndiswrapper, but others claimed that the hardware in question
>> is already supported, and better, without the use of that driver.
>
> The crip driver is actually not made for a specific piece of hardware;
> it's really an encryption layer.
>
> I fail to see whether if something works "better" is important. Using
> OpenOffice.org also works "better" than using Microsoft Office under
> wine, yet I have seen _many_ people asking whether it is possible to do
> so.

Actually, I addressed exactly this already.  If there is some remote
difference to crip-with-ndiswrapper rather than
crip-directly-in-linux which makes anyone's life better, than I'm
happy to say that ndiswrapper is clearly useful for a piece of free
software.

But when I ask this question: exactly what are the advantages here to
running crip with ndiswrapper instead of directly? nobody will answer
me.

>> I don't know whether this is true, but if it is true, I would
>> appreciate hearing why that should be treated differently than there
>> being no such free driver at all.
>
> I would appreciate hearing why you would think that it should be treated
> the same. There is a driver, it is free, it works with ndiswrapper, so
> there is a use case. Why should one perception on its usefulness be
> relevant?

Please, can we answer the question?  If it's not useful then say,
"Yes, it's not useful, but that's not relevant."  If it's useful say,
"It's useful, which should settle the case."

Instead, I hear, "Nyaa nyaa nyaa, I'm not goiny to say whether it's
useful."

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#353277: ndiswrapper in main

[Thomas Bushnell BSG]

Wouter Verhelst <[EMAIL PROTECTED]> writes:

> It's been answered a zillion times already, you just didn't accept the
> answer as valid. That's okay, but re-asking it again and again isn't
> going to give you a different answer.

My question was not answered.  Is ndiswrapper useful on a
free-software-only system?  That's my question.

You insisted that this question is irrelevant, but that's not the same
thing as answering it.  It simply has not been answered as far as I
can tell.  I have been told that it's a "thread reset" to ask it, I
have been told that it's irrelevant what the answer is, and so forth.

It's frustrating, because I feel as if the answer is right there, on
the tip of people's tongues, and they are refusing to just say "here
is the case where ndiswrapper enables something that would not
otherwise be possible" or "there are no such cases now that I can
think of."

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#353277: ndiswrapper in main

[Thomas Bushnell BSG]

Wouter Verhelst <[EMAIL PROTECTED]> writes:

> There are a few ways to interpret the word "wrapper". Ndiswrapper could
> certainly be seen as a "wrapper" of sorts, but not in the way that
> policy means. A "wrapper", as used in policy, is a script or small
> executable that will set up the environment (LD_PRELOAD,
> LD_LIBRARY_PATH, PATH, ...) and then run the "actual" binary.
> /usr/bin/firefox on a Debian system, for example, is a wrapper in the
> meaning that policy is talking about.

Wow, all that from one sentence.  I don't see policy saying anything
of the kind.  I can see that this is one interpretation of it, but I
can't see any reason to think this is the preferred one.

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: AT&T Korn Shell

[Kevin B. McCarty]

Josh Hurst wrote:

> On 2/20/06, Andrew Porter <[EMAIL PROTECTED]> wrote:
>>  On Sat, 2006-02-18 at 14:19 +0100, Josh Hurst wrote:
>>>  Does the Debian ksh93 package include libast and libshell?
>>
>>  No -
[snip]

> Seems these libraries are statically linked. It may be worth to think
> about providing shared library versions since there are many
> applications which can use libshell and libast. For example AT&T
> claims a 30%+ performance improvement for perl applications if sfio
> (provided by libast) is used instead of stdio.

There is already a libast in Debian:

benjo (sid)[4]:~% apt-file search libast.so
libast2: usr/lib/libast.so.2
libast2: usr/lib/libast.so.2.0.0
libast2-dev: usr/lib/libast.so

benjo (sid)[8]:~% apt-cache show libast2
[snip]
Description: the Library of Assorted Spiffy Things
 LibAST is the Library of Assorted Spiffy Things.  It contains many
 spiffy things, and it is a library.  Thus, the ever-so-creative name.
 LibAST has been previously known as libmej, the Eterm helper library
 which nobody really understood and certainly never used. ...

Is this the same libast that you mean?  If not, then providing the ksh
libast in Debian would require one of the two libraries to change its
name (Policy, Section 10.1 - ugh, this will create a mess when applied
to libraries).  This may be why the ksh maintainer(s) decided to link it
statically, avoiding the problem.

-- 
Kevin B. McCarty <[EMAIL PROTECTED]>   Physics Department
WWW: http://www.princeton.edu/~kmccarty/Princeton University
GPG: public key ID 4F83C751 Princeton, NJ 08544


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#353277: ndiswrapper in main

[Michael Poole]

Thomas Bushnell BSG writes:

> Look, if the position is that ndiswrapper is, at present, only useful
> with non-free software, but it should, even so, be in Debian main, I'm
> prepared to entertain that possibility.  But I can't even figure out
> what you *are* saying, because everytime I ask, people start getting
> cagey.

Looking at the first packages alphabetically in (main/)admin, one
could ask the same question of a great many packages.  The aboot*
packages assume you have DEC/HP's SRM firmware on your machine.
acorn-fdisk assumes that you have the Acorn RISC OS.  acpid assumes
you have an ACPI-compatible BIOS.  adtool is for a piece of software
written by Microsoft, identified by a trademark registered to
Microsoft.  What is the difference between ndiswrapper and these tools
that assume or require you have non-free software in your system, and
are written to let Debian interoperate with that non-free software?

Michael Poole


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#353277: ndiswrapper in main

[Thomas Bushnell BSG]

Michael Poole <[EMAIL PROTECTED]> writes:

> Looking at the first packages alphabetically in (main/)admin, one
> could ask the same question of a great many packages.  The aboot*
> packages assume you have DEC/HP's SRM firmware on your machine.
> acorn-fdisk assumes that you have the Acorn RISC OS.  acpid assumes
> you have an ACPI-compatible BIOS.  adtool is for a piece of software
> written by Microsoft, identified by a trademark registered to
> Microsoft.  What is the difference between ndiswrapper and these tools
> that assume or require you have non-free software in your system, and
> are written to let Debian interoperate with that non-free software?

I'm not sure there is a difference, but I'm not going to accept as a
premise that there are no categorization mistakes, especially when I'm
trying to figure out whether there has been one in this case or not.

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Problem regarding modules.dep

[Hendrik Sattler]

Am Dienstag, 28. Februar 2006 14:34 schrieb conn itnel:
>   I am a student and according to my academic project requirement.. I need
> to cross compile the kernel on P4 (PC HOST) for i386 (TARGET).  Now the  PC
> Host and  Target contains the same  debian  3.1r1  sarge. I successfully
> crosscompile kernel 2.6.8 on PC Host for Target using i386 toolchain. For
> that i have done the following changes in the Makefile ::

This is not the right list for such questions.
However: you don't need to cross-compile at all (after all, it is the same 
architecture), just select the right processor in the kernel configuration 
and that's it.
Reading the gcc documentation will give you more insight that you don't need 
any cross-compiler, the standard gcc binary will do for you.

HS

-- 
Mein GPG-Key ist auf meiner Homepage verfügbar: http://www.hendrik-sattler.de
oder über pgp.net

PingoS - Linux-User helfen Schulen: http://www.pingos.org


pgpmF3PEKzJPE.pgp
Description: PGP signature

Re: AT&T Korn Shell

[Aaron M. Ucko]

"Josh Hurst" <[EMAIL PROTECTED]> writes:

> Seems these libraries are statically linked. It may be worth to think
> about providing shared library versions since there are many
> applications which can use libshell and libast. For example AT&T
> claims a 30%+ performance improvement for perl applications if sfio
> (provided by libast) is used instead of stdio.

There are sfio-dev and sfio2000 packages, though nothing in the
archive appears to be built against them at present.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: gnucash 1.9.1

[David Goodenough]

On Monday 27 February 2006 23:51, Thomas Bushnell BSG wrote:
> I have uploaded gnucash 1.9.1 to the experimental archive today.  This
> is the long-awaited GNOME-2 version of gnucash.
>
> Users of gnucash who are willing to use this experimental software are
> desired.  It is not a good idea for every casual user to use it (or I
> would have put it in unstable), but testing will help the process
> along.
>
> It should be noted that there is no good documentation for it yet
> (anyone interested in that is eagerly asked to help out), and there
> are features and parts of the software which are infrequently used and
> may be quite buggy.  Indeed, if they stay uncertain, they will
> probably be dropped from the 2.0 release when it happens.  That means
> that if you like those features (such things as quicken imports, for
> example), you are especially wanted as a tester, given the warning
> that they are extremely fragile.
>
> I do not intend to upload the 1.9 series to unstable ever; I will
> upload 2.0 to unstable once it appears.  At that point, I will not be
> supported the old gnome-1 version of gnucash any longer, and I will
> orphan the gnome-1 libraries that I have been maintaining.
>
> Thomas
Did you include the SQL bits of gnucach?

David


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#353277: ndiswrapper in main

[Henning Makholm]

Scripsit Tom Rauchenwald <[EMAIL PROTECTED]>

> I am not a DD, so maybe my opinion is idiotic. But: the thing is free,
> it allows people to use non-free drivers, but it is entirerly up to the
> user to use those drivers. I don't know, but for me this discussion is
> pointless. Does ndiswrapper require non-free packages? no.

Well, that's the point of contention. I think it is not meaningful to
speak about whether the software, viewed as a bag of bits that live in
a vacuum, "requires" this or that other software. The question only
makes sense when we put it in a context and ask: Does ndiswrapper
require a non-free software *to do its thing*?

Unfortunately the answer depends on what one takes "ndiswrapper's
thing" to be. I think the schism in the current thread is based mostly
on differing intitial assumptions about how one views the purpose of
ndiswrapper.

Case 1: Ndiswrapper is for users who have hardware XYZ; it promises to
make this hardware useful with Linux. It cannot keep this promise
without also having a driver, and the only existing driver for XYZ is
non-free. From this viewpoint it is clear that ndiswrapper should be
in contrib.

Case 2: Ndiswrapper is for users who already have some driver software
written to the NDIS specification, never mind where they got it, and
want to run this driver. From this point of view, ndiswrapper is akin
to a programming language implementation, or a shared library - it can
be in main independently of the freedom of any programs that use it.
Thus from this perspective it is clear that ndiswrapper should be in
main.

The tragedy is that both viewpoints - "I want to use this hardware"
and "I want to run this driver" - are possible and legitimate and the
package descriptions does not clearly invalidate one of them, yet they
lead to incompatible conclusions about where the package should be
filed.

> if the user decides to use non-free drivers, then it's his choice,
> not debian's, so what.

The point of the distinction between main and contrib is to support
the user in his choice. We want that if a user finds package that
promises some functionality in 'main', then he can ideed get that
functionality without resorting to software outside main.  That is why
the differing views of what functionality ndiswrapper promises is
important.


Personally I favor using a test somebody invented an earlier time we
discussed a similar problem: To determine whether A "requires" B for
the purpose of the social contract, assume hypothetically that B was
free and packaged, and then ask whether ordinary packaging practice
would lead to A a declaring a "Depends:" relationship on B in that
situation. This test would allow us to move the question into the
technical realm.

I think that according to this test, we would conclude that
ndiswrapper does not "require" the driver it wraps. If we had a
handful of prackages that provided free NDIS drivers, the driver
packages would depend on ndiswrapper, not the other way around. We
don't let libfoo depend on , or let ruby
depend on , even though we
_could_ do this with virtual packages if we thought it would be
useful.

This is just parallel to the fact that we can have a library in main
without having any clients for the library in main. An example is
libc5 - it exists in sarge *only* to support old applications,
presumably non-free and certainly not in main themselves. Yet I have
not heard anybody suggest that it ought to have been in contrib for
that reason.

-- 
Henning Makholm   "... a specialist in the breakaway
   oxidation phenomena of certain nuclear reactors."


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Is there some guideline saying that native packages should be avoided?

[Henning Makholm]

Scripsit Panu Kalliokoski <[EMAIL PROTECTED]>

> It was pointed to me that packages should be preferably non-native,
> even if no source release without the debian/ subdir has ever
> existed.
> I would like to ask whether there really is such a guideline, and if so,
> which are the technical / political reasons that lead to it.

In addition do the answers Lars gave, I think there is a major
consideration to make for people who do _not_ use Debian but are
still interested in your software. Because of the sheer size of
Debian, it is not uncommon to use our source archive as a generic
place to find free software sources - sort of a meta-CxAN.

For this kind of users, a non-native package is a clear signal that
the software is supposed to be generally useful on Linux and probably
also other unices. Conversely, a Debian-native package may make people
assume that you don't care a bit whether it compiles or runs on other
OSes, and that you would be reluctant to accept patches for
portability beyond Debian, or patches for easier installation in $HOME
for users who are not root on their system, and so on.

Further, providing an .orig.tar.gz without the debian/ directory helps
prevent confusion for users on non-Debian systems.

And if you do provide such a debian/-less tarball for nondebian
users then of course you SHOULD use that as pristine source in the
Debian package too.


And last: if someday _you_ decide that you like, say, Ubuntu better
than Debian and start releasing your master distribution there instead
of here, confusion will result if the Ubuntu packaging in debian/
cannot be easily separated from the upstream source that a new Debian
maintainer might want to package.

It is easier to just do it right from the beginning.

-- 
Henning Makholm   "Jeg mener, at der eksisterer et hemmeligt
 selskab med forgreninger i hele verden, som
 arbejder i det skjulte for at udsprede det rygte at
  der eksisterer en verdensomspændende sammensværgelse."


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Please reject to rule on the ndiswrapper question

[Jeroen van Wolffelaar]

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

--Jeroen
Another FTP-Team member, who doesn't yet have an opinion on this matter,
but hasn't been asked for one either

-- 
Jeroen van Wolffelaar
[EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Is there some guideline saying that native packages should be avoided?

[Hendrik Sattler]

Am Dienstag, 28. Februar 2006 21:26 schrieb Henning Makholm:
> Further, providing an .orig.tar.gz without the debian/ directory helps
> prevent confusion for users on non-Debian systems.

So the same reason for not including a .spec file (for creating RPM packages).
On the other side, some user may find it very useful.
Same goes for users of Debian stable that like to use a newer version without 
doing the backporting.

I think the main reason for not inluding the debian subdir in upstream sources 
it that it may result in naming problem (see the cupsys packages: the deb 
provided by upstream was a single package named "cups").
And the patch is easier to read if the subdir is only added ;)

HS

-- 
Mein GPG-Key ist auf meiner Homepage verfügbar: http://www.hendrik-sattler.de
oder über pgp.net

PingoS - Linux-User helfen Schulen: http://www.pingos.org


pgpg3Nxg55gw6.pgp
Description: PGP signature

Re: gnucash 1.9.1

[Roland Mas]

Thomas Bushnell BSG, 2006-02-28 01:00:08 +0100 :

> Users of gnucash who are willing to use this experimental software
> are desired.  It is not a good idea for every casual user to use it
> (or I would have put it in unstable), but testing will help the
> process along.

Okay.  Built it in a pbuilder chroot (it does take quite some time
:-), then installed it into same chroot, and started using it in a VNC
after copying my roland.xac into the chroot.

  First impressions (posted here as much to give potential new users a
warning of what doesn't exactly work yet as in an attempt to prove
that there *can* be some on-topic content on this list despite current
rumours): 

- Data seems to have been correctly imported (phew).

- Accounts names seem to have been mangled a bit, especially for
non-ASCII characters.  They were stored as é for an "é" in
1.8, which now appears as the oh-so-familiar é.  I run under an
fr_FR.UTF-8 locale in both cases.

- Still locale-related: no, the monetary unit in use in fr_FR.UTF-8
shouldn't be USD :-)

- And again: I haven't seen anything displayed in French, which makes
me wonder if maybe the locale setting isn't taken into account (haha)
at all.

- I haven't managed to expand the graphs horizontally as much as I'd
have liked, apparently I can't have a report wider than it is high.
Since the captions are apparently proportional in size to the report
itself, the actual graphics are very tightly compressed to the left of
the report.

- In the Help menu, only the Tips of the Day and the About entries
have any effect.  The other two seem inoperant (which is a pity, I'd
have loved to learn about this new "books" thing).

- I tried closing my books, and apparently one transaction wasn't
categorised into a book, so it appears all by itself above the
book-closing transaction.

- After closing the books, I couldn't find a way to access the
transactions of the previous years in their account tabs (even
read-only), only through a hack (search for transactions by date).
Are they really hidden, or was I bitten by the "no help" problem?

- I love the new hierarchical display in the quote editor -- the
previous everything-in-the-same-list was getting tedious after
hundreds of quotes.

  Otherwise, it seems to work, but I'm not exactly a heavy user.

  Question though: will the SQL support be enabled at some point?  I
think that would open up a lot of possibilities (gateways with other
apps, for instance).

  Thanks, visible evolution coming from Gnucash is a relief, I was
starting to wonder whether I'd have to switch to something else... :-)

Roland.
-- 
Roland Mas

You can tune a filesystem, but you can't tuna fish.
  -- in the tunefs(8) manual page.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: gnucash 1.9.1

[Thomas Bushnell BSG]

David Goodenough <[EMAIL PROTECTED]> writes:

> Did you include the SQL bits of gnucach?

The package I have uploaded does not support SQL.  My intention is to
turn that on (I am uncertain yet whether it is worth making it a
separate package as it used to be) once 1.9.x has had a time to
settle.

I am unlikely to turn SQL on for 1.8.  Certainly the current 1.8 has
to hit testing before I would even consider it, and it's currently
hung up due to a guile bug.

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#354654: general: fat32 gets corrupted

[Cesare Leonardi]

Juan Piñeros wrote:
In machine1 hdparm is not currently installed, but it was 1 year ago when the 
machine1 had woody installed. I suppose hdparm does not change anything to 
the disk itself but only to the ide modules of the kernel?


Hdparm is a powerful tool that can activate/deactivate some feature/mode 
of your ATA hard disk. It can tweak various disk parameter using the ATA 
driver of the kernel. But, as the manual reports, various feature are 
dangerous and if not used correctly can cause data corruption. As 
happened to me...   ;-)


But since one of your machine haven't got hdparm installed, it doesn't 
seem to be the cause.


In machine2, hdparm is installed, but I do not remember to have changed 
anything to the configuration of it (the log file I was maintaining for 
machine2 was lost during the disk crash). Do I have to check something or 
simply uninstall it?


In my system there is the boot script "/etc/init.d/hdparm" that read the 
configuration file "/etc/hdparm.conf". The last file is a list of 
feature that you can use: on my system i have never touched it and it is 
still in the maintainder default status, that is pratically all 
commented out.


Your problem is a tipical one that can make you crazy.
I think you have to check all the things that your machine has in 
common, expecially on the software side. It doesn't seems to be an 
hardware problem, since the two machine has so different components...
The machine2, in particular, is a common hardware platform with a 
popular chipset...


If i were you, i'll start to try this things:
- search on the internet if there are known problem regarding kernel 2.6 
and FAT partition, in particular if created by WinXP;

- boot with a 2.4 kernel and check if the problem persists;
- if possible, try with a USB key or, better, a USB external drive, 
formatted FAT by WinXP and see if there are corruptions on that drive; i 
suggest to use a partition as similar as possible to the ones you have 
on your notebook: same dimension and same type (FAT32);
- if possible, try to reformat one of the partition with a win98 format 
or with mkfs.vfat and see it the problem persists.


Since you have told that on one machine there where Woody installed, i 
suppose that the problem didn't existed at that time, is it true?


Good luck.

Cesare.

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

[Javier Fernández-Sanguino Peña]

On Fri, Feb 24, 2006 at 07:03:31AM -0600, Cord Beermann wrote:
> 
> If you get spam via our lists, BOUNCE[1] it to
> [EMAIL PROTECTED] 

The advantage of posting it here is that it can be used as a measure of how
much spam does posting to a debian mailing attracts, spammers will probably
send some mails directly to that address, thus enhacing the filters :-)

> 
> * Incomplete mails[2] will be discarded,
> * mis-use (report of non-spam, mass-reporting of one spam, automatic
>forwarding based on some automatism (scores of Anti-Spamtools or
>something)) will be blacklisted.

I've just bounced all the spam from Debian mailing lists that got through my
(local and ISP's) filters and I had stored in a separate folder to that
address. They are 33, hopefully it will not get me blacklisted.

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

---
# Debian spam reporting configuration
alias debian-spam-rep [EMAIL PROTECTED]
#set mime_forward=yes
send-hook  [EMAIL PROTECTED]  set signature=""
send-hook  [EMAIL PROTECTED]  set autoedit=no
send-hook  [EMAIL PROTECTED]  set fast_reply=yes
send-hook  [EMAIL PROTECTED]  set mime_forward=yes
send-hook  [EMAIL PROTECTED]  set editor=\"/bin/true\"
macro index \cf 
"debian-spam-rep\n\n\n" "Forward 
mail to Debian spam reporter"
macro pager \cf 
"debian-spam-rep\n\n\n" "Forward 
mail to Debian spam report"
---

Regards

Javier


signature.asc
Description: Digital signature

Re: Bug#353277: ndiswrapper in main

[Eduard Bloch]

#include 
* Thomas Bushnell BSG [Mon, Feb 27 2006, 12:53:12PM]:

> I certainly do not think that the installer should be limited to
> software in main (and perhaps not even software in main+contrib,
> provided it still works correctly without non-free things around).
> 
> Is that the root issue?  Are there people who insist that the
> installer should be limited to things in main?

I think this is the worst problem. Contrib never has been a section with
strong separation, it is just subjective line that has been drawn
between main and contrib. Therefore this whole thread is almost
pointless.

However, some people like to define "Debian" just as "main" and use the
main section as the single acceptable set of free software. Which
is, of course, wrong, because requirements for contrib are defined by
DFSG, exactly as for main.

And I have never understood why the apt-setup questions for contrib and
non-free have been put into the same dialog. The only possible reason is
that the users that have deliberately decided to not use non-free
software (because of "political" reasons) should never come in touch
with it and therefore all possible ways that may lead to the "dark side"
should be hidden. OTOH the last action is already a kind of limiting the
freedom of choice. And if not (eg. is explained as something else,
political correctness or whatever) then it still means making life or
users harder and is a violation of DSFG. Pushing users for ideological
reasons sucks.

Eduard.

-- 
 ich bin ja auch ein sehr ueberzeugter windoze nutzer
 ja windoze ist toll!
 samba ist scheisse
 ich versteh nicht warum ihr das nicht begreift...


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#353277: ndiswrapper in main

[Adam McKenna]

On Wed, Mar 01, 2006 at 12:06:51AM +0100, Eduard Bloch wrote:
> However, some people like to define "Debian" just as "main" and use the
> main section as the single acceptable set of free software. Which
> is, of course, wrong, because requirements for contrib are defined by
> DFSG, exactly as for main.

According to the SC, contrib is not part of Debian.

--Adam


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 4GB address space

[Gabor Gombas]

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
 -


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[maximilian attems]

On Tue, 28 Feb 2006, Steve Langasek wrote:

> On Tue, Feb 28, 2006 at 09:59:17AM +0100, maximilian attems wrote:

> 
> > 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.
 
> Holding all the members of the pkg-xen team responsible for what one of
> their fellows has written in his blog would be petty and immature, and would
> not exactly be the kind of encouragement one would hope to see from the
> kernel team seeking the input of others interested in Xen packaging.

i'm relying on xen at my work place. i'm very interested in xen packaging.
as it allows me to easily test initramfs-tools on various setups.
firing up roots on lvm2, md0 or whatever..
looking forward to switch from handbuild rsynced chroots to fine debs ;)

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.

-- 
maks


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: buildd and experimental

[Brian M. Carlson]

[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 +, 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.


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

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

[Adeodato Simó]

* 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 '[EMAIL PROTECTED]'? ('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 [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: /lib/modules//volatile on tmpfs

[Joe Smith]

"Sergio Callegari" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

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. 




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Please reject to rule on the ndiswrapper question

[Steve Langasek]

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
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: buildd and experimental

[Gabor Gombas]

On Wed, Mar 01, 2006 at 01:04:17AM +, 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.

The problem is, every project has different requirements for its mailing
lists. Right now I'm subscibed to about 20 lists only, but I'm sure
as hell can not remember the policy for each of them. So if you'd like
people to follow a specific policy, then tell that to their MUA by
setting Reply-To:. After all, we have computers to do some work instead
of us, not the other way around...

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -

Re: Please reject to rule on the ndiswrapper question

[Steve Langasek]

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

You and I both know that the ftp team is not going to unilaterally move a
package from main to contrib; the package would need to be reuploaded, by
the maintainer or in NMU, and pass through the NEW queue.  If an upload had
been made to move ndiswrapper to contrib and the ftp team had rejected this
upload, that would definitely be an ftp team decision to be discussed
between the ftp team and the uploader, with an appeal to the tech ctte if an
agreement cannot be reached.  But the only decision the ctte has been asked
to overturn here has been the decision of the package maintainer to have the
package in main, and the maintainer has explicitly said he will not move the
package without a ruling from the tech ctte.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: Mirror split, amd64 update

[Henrique de Moraes Holschuh]

On Mon, 27 Feb 2006, Julien BLACHE wrote:
> "Joe Smith" <[EMAIL PROTECTED]> 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


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Jeremy T. Bouse]

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


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Please reject to rule on the ndiswrapper question

[Henrique de Moraes Holschuh]

On Tue, 28 Feb 2006, Steve Langasek wrote:
> 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.

(OBdisclaimer: I could care less wether ndiswrapper is in main, contrib, or
/dev/null)

Steve, it is rare that I disagree with you, but frankly, that makes no sense
at all.  Either that, or I misunderstood what you meant.

You have here a political/social fact "A" which causes a technical
device/method/procedure "B" to exist/happen.

The ctte can override how B is done, but only insofar as to implement *the
same* "A".

Otherwise, the ctte could overrule just about everything in Debian.  Were
they not bound by the SC themselves, they could overrule even the SC itself
by determining that the files that determine in which suite a package go
should make all packages in the non-free suite go into the main suite.

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

They can consider it, obviously.  They cannot overrule ftp-masters on this
matter, however.  OTOH, ftp-masters may decide to listen to whatever the
ctte recommends, but they don't *have* to.

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

Agreed.

But ndiswrappers being in main or contrib is a sad reason for a GR.

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

The answer to that question is: the one policy determines it to.  The ctte
can not say much more than that, packages are not placed into a *suite*
(main or contrib) because of any sort of technical concern.

Placement inside the suit (whether in main/foo or main/bar) might be
different, as it is a best-fit question decided only on technical grounds,
but that's outside the scope of this thread.

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


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Please reject to rule on the ndiswrapper question

[Adam McKenna]

On Wed, Mar 01, 2006 at 01:03:56AM -0300, Henrique de Moraes Holschuh wrote:
> They can consider it, obviously.  They cannot overrule ftp-masters on this
> matter, however.  OTOH, ftp-masters may decide to listen to whatever the
> ctte recommends, but they don't *have* to.

They can consider it individually, or even jointly, and make individual 
recommendations to ftpmaster like any other developers.  It would be 
inappropriate for them to make an official statement about it.

I tried, poorly, to make this point in the other thread.  Thanks for
elucidating.

--Adam

-- 
Adam McKenna  <[EMAIL PROTECTED]>  <[EMAIL PROTECTED]>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: buildd and experimental

[Matthew Palmer]

On Wed, Mar 01, 2006 at 02:46:02AM +0100, Gabor Gombas wrote:
> On Wed, Mar 01, 2006 at 01:04:17AM +, Brian M. Carlson wrote:
> > 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.

How?  I can't use the same header for two purposes; if I want to specify
that private replies should go to one address, but I want list replies to go
to the list (and only the list), how do I go about that using only Reply-To?

- Matt


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Is there some guideline saying that native packages should be avoided?

[Christian Perrier]

> I would like to ask whether there really is such a guideline, and if so,
> which are the technical / political reasons that lead to it.  I have


Wearing my i18n hat, I can add one reason, certainly not THE reason
but yet another argument to avoid native packages except for
Debian-specific stuff (apt, dpkg and the like...).

When packages are internationalized, we (Debian i18n team) recommend
translators to first focus on them if there is translation work to do.

The rationale for this is that translations for Debian-specific stuff
is better coming "from the Debian world" while other packages are
likely to be translated by some other way.

So, making a package Debian native gives it some priority for being
translated first.

There are already a few i18n'ed packages in the archive that are
native packages and are actually NOT Debian-sepcific (xmorph, lpe,
pdbv, rpncalc, wxwidgets2.6)I'd really like not seeing more..:)

I think I have reported a bug against all of them and, IIRC, the
maintainer's arguments have not been very convincing..:). moreover,
several of these are currently obviously not maintained. Some have
pending French translations since more than 1 year.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Is there some guideline saying that native packages should be avoided?

[Henning Makholm]

Scripsit Hendrik Sattler <[EMAIL PROTECTED]>
> Am Dienstag, 28. Februar 2006 21:26 schrieb Henning Makholm:

>> Further, providing an .orig.tar.gz without the debian/ directory helps
>> prevent confusion for users on non-Debian systems.

> On the other side, some user may find it very useful.

Then the user can easily download the .diff.gz too.

-- 
Henning Makholm  "Punctuation, is? fun!"


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]