Re: NEW handling: About rejects, and kernels

[Marco d'Itri]

On Apr 03, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote:

> A free kernel can't support that hardware.  It's a shame, but it's
This is a lie. Devices which need a firmware upload are supported by
totally free drivers.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: NEW handling: About rejects, and kernels

[Wouter Verhelst]

On Sat, Apr 02, 2005 at 04:52:58PM +0100, Henning Makholm wrote:
> Scripsit [EMAIL PROTECTED] (Marco d'Itri)
> > On Apr 02, Henning Makholm <[EMAIL PROTECTED]> wrote:
> >> So what?
> 
> > So it is a problem, because currently it would not be allowed.
> 
> Where does it say that such images are not allowed?

Our social contract, §1: "We will never make the system depend on an
item of non-free software".

Putting items from the non-free archive in the installer images does
just that. It is debatable whether the intention is the same, but by our
rulebook, this is not allowed.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


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

Re: NEW handling: About rejects, and kernels

[Wouter Verhelst]

On Sat, Apr 02, 2005 at 04:51:18PM +0100, Henning Makholm wrote:
> | Installer images x, y, and z belong to the 'main' distribution of
> | Debian, and therefore do support various recent makes of hardware
> | (link to list) that require non-free firmware that cannot go into
> | 'main'.  If you need to have one these devices work before you can
> | access the network, you will want to use one of the installer images
> | u, v, and w, from the 'non-free' section.

Ah, that is what you mean. I thought you were advocating to put the
non-free firmware blobs in the installer images in main.

That voids my argument, then.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


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

Re: NEW handling: About rejects, and kernels

[Mark Brown]

On Sun, Apr 03, 2005 at 01:19:32AM +0100, Henning Makholm wrote:
> Scripsit Mark Brown <[EMAIL PROTECTED]>

> > One example: with our current package management tools once you've got
> > an apt source in your configuration the packages it provides will start
> > to show up in things like searches.

> It is possible to edit sources.list *after* having defined the
> packages one needs.

That's not a static choice, though.

> Also, there is no need to have the entire non-free
> archive in one's sources.list at any time at all if one uses an
> installer image that contains the necessary drivers itself.

Given that one of the reasons hardware vendors use downloads is to make
it easier for them to provide bug fixes it would be desirable to have
the ability to track new firmware packages.

> I *am*, however, opposed to including non-free firmware in main
> because somebody feels that the non-free archive is not split
> sufficiently finegrained yet.

There's slightly more to it than splitting out the firmware section from
non-free - things like how to handle it in the installer, for example.
We used to ask if people wanted non-free during installation but don't
do that any more.  Some similar things may be desirable should a
firmware section be created.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."


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

Re: NEW handling: About rejects, and kernels

[Marco d'Itri]

On Apr 03, Wouter Verhelst <[EMAIL PROTECTED]> wrote:

> On Sat, Apr 02, 2005 at 04:51:18PM +0100, Henning Makholm wrote:
> > | Installer images x, y, and z belong to the 'main' distribution of
> > | Debian, and therefore do support various recent makes of hardware
> > | (link to list) that require non-free firmware that cannot go into
> > | 'main'.  If you need to have one these devices work before you can
> > | access the network, you will want to use one of the installer images
> > | u, v, and w, from the 'non-free' section.
> Ah, that is what you mean. I thought you were advocating to put the
> non-free firmware blobs in the installer images in main.
Indeed, this would mean that Debian would not support these devices, so
I'm opposed to this "solution".

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: NEW handling: About rejects, and kernels

[Mark Brown]

On Sat, Apr 02, 2005 at 06:15:04PM -0800, Thomas Bushnell BSG wrote:
> Matthew Garrett <[EMAIL PROTECTED]> writes:

> > This does present certain logistical problems for producing installers.

> A free kernel can't support that hardware.  It's a shame, but it's
> true.

Do you mean to say a free installer rather than a free kernel here?

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."


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

Building issues on sparc

[Søren Boll Overgaard]

Hi,

I am attempting to build packages on my spanking new Debian system running on
sparc. Unfortunately, I have run into the following problem, when executing
dpkg-buildpackage:

[EMAIL PROTECTED]:~/sandbox/xpad/xpad-2.6$ dpkg-buildpackage -rfakeroot -uc -us
dpkg-buildpackage: source package is xpad
dpkg-buildpackage: source version is 2.6-1
dpkg-buildpackage: source maintainer is Soeren Boll Overgaard <[EMAIL 
PROTECTED]>
dpkg-buildpackage: host architecture is sparc
 fakeroot debian/rules clean
/usr/bin/fakeroot: debian/rules: /usr/bin/make: bad interpreter: Permission
denied
[EMAIL PROTECTED]:~/sandbox/xpad/xpad-2.6$ 

Googling only suggested that permissions for debian/rules was wrong. That
doesn't seem to be the case however:

[EMAIL PROTECTED]:~/sandbox/xpad/xpad-2.6$ ls -la debian/rules /usr/bin/make
/usr/bin/fakeroot
-rwxr-xr-x  1 boll boll   2381 2005-03-14 10:23 debian/rules
lrwxrwxrwx  1 root root 26 2005-03-19 09:19 /usr/bin/fakeroot ->
/etc/alternatives/fakeroot
-rwxr-xr-x  1 root root 135592 2004-07-22 22:13 /usr/bin/make
[EMAIL PROTECTED]:~/sandbox/xpad/xpad-2.6$

Additonal info that might be useful:

[EMAIL PROTECTED]:~/sandbox/xpad/xpad-2.6$ head -1 debian/rules 
#!/usr/bin/make -f
[EMAIL PROTECTED]:~/sandbox/xpad/xpad-2.6$

[EMAIL PROTECTED]:~/sandbox/xpad/xpad-2.6$ file /usr/bin/make
/usr/bin/make: ELF 32-bit MSB executable, SPARC, version 1 (SYSV), for
GNU/Linux 2.2.0, dynamically linked (uses shared libs), stripped
[EMAIL PROTECTED]:~/sandbox/xpad/xpad-2.6$ 

Any suggestions on how to fix this would be greatly appreciated.

Thanks.


-- 
Søren O.   ,''`.
  : :' :
GPG key id: 0x1EB2DE66`. `'
GPG signed mail preferred.  `-


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

Re: Building issues on sparc

[Andreas Metzler]

Søren Boll Overgaard <[EMAIL PROTECTED]> wrote:
[...]
> [EMAIL PROTECTED]:~/sandbox/xpad/xpad-2.6$ dpkg-buildpackage -rfakeroot -uc 
> -us
> dpkg-buildpackage: source package is xpad
> dpkg-buildpackage: source version is 2.6-1
> dpkg-buildpackage: source maintainer is Soeren Boll Overgaard <[EMAIL 
> PROTECTED]>
> dpkg-buildpackage: host architecture is sparc
> fakeroot debian/rules clean
> /usr/bin/fakeroot: debian/rules: /usr/bin/make: bad interpreter: Permission
> denied
> [EMAIL PROTECTED]:~/sandbox/xpad/xpad-2.6$ 

> Googling only suggested that permissions for debian/rules was wrong. That
> doesn't seem to be the case however:
[...]

Is the filesystem that ~/sandbox lives perhaps mounted noexec?
   cu andreas
-- 
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"
   http://downhill.aus.cc/


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

Re: why allow broken packages to get all the way to mirrors?

[Thijs Kinkhorst]

On Sun, April 3, 2005 05:39, John Hasler said:
>> For instance, let's say we are a food company. Why not check to see if
>> the food is rotten before it gets to the consumer?
>
> That's what Unstable is for.

Why, if tests can be automated, do we have a need to go through the
process of spreading a package to mirrors, have people install it and file
bug reports by hand? (Often these reports are a day later already
out-of-date because it was just a matter of time.) Isn't one of our
strenghts that we can automate what we can so we can use our time for all
those tasks that are left?

Regards,

Thijs Kinkhorst


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

Re: why allow broken packages to get all the way to mirrors?

[Petri Latvala]

On Sun, Apr 03, 2005 at 02:26:34PM +0200, Thijs Kinkhorst wrote:
> On Sun, April 3, 2005 05:39, John Hasler said:
> >> For instance, let's say we are a food company. Why not check to see if
> >> the food is rotten before it gets to the consumer?
> >
> > That's what Unstable is for.
> 
> Why, if tests can be automated, do we have a need to go through the
> process of spreading a package to mirrors, have people install it and file
> bug reports by hand? (Often these reports are a day later already
> out-of-date because it was just a matter of time.) Isn't one of our
> strenghts that we can automate what we can so we can use our time for all
> those tasks that are left?


Good idea! Let's make a new repository of packages that only
receives new packages that have their dependencies fulfilled.

We need a good name for such a repository. How about "testing"?


-- 
Petri Latvala
The house of sarcasm


signature.asc
Description: Digital signature

Re: why allow broken packages to get all the way to mirrors?

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> It seems there are only minimal checks, so developers can unwittingly
> upload broken packages.

Any numbers where you can proof your claim? Developers are required to test
the packages before upload, and I havent noticed any uninstallable package
in years.

> Even if the package is only "broken until tomorrow, whereupon the
> upload will be complete", that too should not be allowed to propagate
> to the mirrors until ready.

This cannot happen, what do you mean? Uploads are integrity checked.
Besides, thats what unstable is for, a package does not propagate to testing
or stable it has bugs.

Gruss
Bernd


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

Re: Vancouver meeting - clarifications

[Andrew Pollock]

On Sun, Mar 27, 2005 at 05:03:50PM +0200, Peter 'p2' De Schrijver wrote:
> 
> You don't need to install anyone else's operating system. You can easily
> do : 
> 
> Boot target using NFS root

Ah but how do you create an NFS root for one architecture on another? This
is one of the limitations of FAI. One cannot create the NFS root for say
Sparc on i386.

regards

Andrew


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

Re: why allow broken packages to get all the way to mirrors?

[Mike Hommey]

On Sun, Apr 03, 2005 at 02:28:36PM +0200, Bernd Eckenfels <[EMAIL PROTECTED]> 
wrote:
> In article <[EMAIL PROTECTED]> you wrote:
> > It seems there are only minimal checks, so developers can unwittingly
> > upload broken packages.
> 
> Any numbers where you can proof your claim? Developers are required to test
> the packages before upload, and I havent noticed any uninstallable package
> in years.
> 
> > Even if the package is only "broken until tomorrow, whereupon the
> > upload will be complete", that too should not be allowed to propagate
> > to the mirrors until ready.
> 
> This cannot happen, what do you mean? Uploads are integrity checked.
> Besides, thats what unstable is for, a package does not propagate to testing
> or stable it has bugs.

I think he's talking about mirrored Packages files being updated before
all the packages get mirrored and/or arch all packages reaching the
archive before arch specific builds (except the maintainer's arch),
because of buildd queue.

Mike


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

Re: why allow broken packages to get all the way to mirrors?

[Adrian Bunk]

On Sun, Apr 03, 2005 at 02:26:34PM +0200, Thijs Kinkhorst wrote:
> On Sun, April 3, 2005 05:39, John Hasler said:
> >> For instance, let's say we are a food company. Why not check to see if
> >> the food is rotten before it gets to the consumer?
> >
> > That's what Unstable is for.
> 
> Why, if tests can be automated, do we have a need to go through the
> process of spreading a package to mirrors, have people install it and file
> bug reports by hand? (Often these reports are a day later already
> out-of-date because it was just a matter of time.) Isn't one of our
> strenghts that we can automate what we can so we can use our time for all
> those tasks that are left?

Where do fully automated bug preventing techniques really work in 
Debian?

All places I know either require a serious amount of work to keep it
running or require people regularily checking the reports (which is 
often not done).

And note that "not installable packages" are only a small and not the 
worst class of bugs - and they are usually reported pretty fast.

"unstable" is unstable and every user of unstable is expected to know 
what to do when the installation of a package fails.

E.g. DSA-177-1 describes a _real_ problem - and this wouldn't have been 
caught.

> Regards,
> 
> Thijs Kinkhorst

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed


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

Re: The 98% and N<=2 criteria (was: Vancouver meeting - clarifications)

[Andrew Pollock]

On Mon, Mar 21, 2005 at 03:04:08PM +0100, Wouter Verhelst wrote:
> On Sat, Mar 19, 2005 at 09:52:18AM -0600, Gunnar Wolf wrote:
> > As you say, _most_ of the issues are triggered by one of those three
> > chips, not all. And, by not making a hard requirement to compile the
> > packages which will not be used, you are not holding the project back
> > waiting for m68k's KDE. Probably m68k will _never_ compile KDE, as I
> > doubt their buildds are ever idle
> 
> kiivi.cyber.ee, the unstable m68k buildd that I maintain, is usually
> idle for about 30% of the time. /Of course/ we build KDE, there's no
> point in not doing that.
> 

Why, does it get used on this architecture?

(Serious question, I have no idea).

regards

Andrew


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

Re: NEW handling: About rejects, and kernels

[Hamish Moffatt]

On Sun, Apr 03, 2005 at 11:51:15AM +0200, Wouter Verhelst wrote:
> On Sat, Apr 02, 2005 at 04:52:58PM +0100, Henning Makholm wrote:
> > Scripsit [EMAIL PROTECTED] (Marco d'Itri)
> > > On Apr 02, Henning Makholm <[EMAIL PROTECTED]> wrote:
> > >> So what?
> > 
> > > So it is a problem, because currently it would not be allowed.
> > 
> > Where does it say that such images are not allowed?
> 
> Our social contract, §1: "We will never make the system depend on an
> item of non-free software".

Given some options:

1. Don't distribute the firmware blob at all;
2. Provide a way to download the blob during install (while admitting
   this won't work if the blob is the code for your ADSL modem);
3. Provide the blob on disk in the regular install media (ie in main);
4. Provide the blob on disk in a special tained installer
   (ie in non-free or a special firmware section).

Which do you think makes the system *depend* less or more on non-free
software? (Depend is the key word.)


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


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

Re: why allow broken packages to get all the way to mirrors?

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> Why, if tests can be automated

which tests?

Gruss
Bernd


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

Re: NEW handling: About rejects, and kernels

[Henning Makholm]

Scripsit Mark Brown <[EMAIL PROTECTED]>
> On Sun, Apr 03, 2005 at 01:19:32AM +0100, Henning Makholm wrote:
>> Scripsit Mark Brown <[EMAIL PROTECTED]>

>> > One example: with our current package management tools once you've got
>> > an apt source in your configuration the packages it provides will start
>> > to show up in things like searches.

>> It is possible to edit sources.list *after* having defined the
>> packages one needs.

> That's not a static choice, though.

My point is that the choice is not static.

>> Also, there is no need to have the entire non-free
>> archive in one's sources.list at any time at all if one uses an
>> installer image that contains the necessary drivers itself.

> Given that one of the reasons hardware vendors use downloads is to make
> it easier for them to provide bug fixes it would be desirable to have
> the ability to track new firmware packages.

Then add an appropriate repository to your sources.list. It's your
choice. You just cannot have your cake and eat it.

>> I *am*, however, opposed to including non-free firmware in main
>> because somebody feels that the non-free archive is not split
>> sufficiently finegrained yet.

> There's slightly more to it than splitting out the firmware section from
> non-free - things like how to handle it in the installer, for example.

Which does not change my point.

-- 
Henning Makholm   "We will discuss your youth another time."


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

Re: How to find out why a package was removed from testing?

[Anthony Towns]

Frank Küster wrote:
Well, the point is that I thought about doing an NMU.  However, I don't
feel like digging into the problem if the package was removed for an
unrelated reason which I cannot change (like dead upstream, better
replacement available).
Err, those are reasons to remove the package from /unstable/, not from 
testing. Packages get removed from testing when they have RC bugs, and 
that's pretty much it. I don't believe any package has ever been removed 
from testing because there's a "better replacement" or "dead upstream" 
without it either also having some RC bugs, or having already been 
removed from unstable...

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

Re: Vancouver meeting - clarifications

[Peter 'p2' De Schrijver]

On Sun, Apr 03, 2005 at 10:30:03PM +1000, Andrew Pollock wrote:
> On Sun, Mar 27, 2005 at 05:03:50PM +0200, Peter 'p2' De Schrijver wrote:
> > 
> > You don't need to install anyone else's operating system. You can easily
> > do : 
> > 
> > Boot target using NFS root
> 
> Ah but how do you create an NFS root for one architecture on another? This
> is one of the limitations of FAI. One cannot create the NFS root for say
> Sparc on i386.

That's a generic debian problem. The hurd people have built something
which solves this issue more or less. Presumably this can be extended to
other archs/OSes as well. I haven't looked into it though.

Cheers,

Peter (p2).


signature.asc
Description: Digital signature

Re: The 98% and N<=2 criteria (was: Vancouver meeting - clarifications)

[Wouter Verhelst]

On Sun, Apr 03, 2005 at 10:37:25PM +1000, Andrew Pollock wrote:
> On Mon, Mar 21, 2005 at 03:04:08PM +0100, Wouter Verhelst wrote:
> > On Sat, Mar 19, 2005 at 09:52:18AM -0600, Gunnar Wolf wrote:
> > > As you say, _most_ of the issues are triggered by one of those three
> > > chips, not all. And, by not making a hard requirement to compile the
> > > packages which will not be used, you are not holding the project back
> > > waiting for m68k's KDE. Probably m68k will _never_ compile KDE, as I
> > > doubt their buildds are ever idle
> > 
> > kiivi.cyber.ee, the unstable m68k buildd that I maintain, is usually
> > idle for about 30% of the time. /Of course/ we build KDE, there's no
> > point in not doing that.
> > 
> 
> Why, does it get used on this architecture?



-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


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

Re: How to find out why a package was removed from testing?

[Darren Salt]

I demand that Martin Michlmayr may or may not have written...

> * Frank Küster <[EMAIL PROTECTED]> [2005-04-01 19:28]:
>> - its open bugs (one RC, but worked on)

> http://ftp-master.debian.org/testing/hints/vorlon contains

> # bug #295060
> remove wwwoffle/2.8e-1

> So, yes, because of an RC bug.

gxine's RC bug (289412/295344) was fixed in 0.4.2; the current release is
0.4.3, which I released a week ago. The bug is marked "fixed-upstream".

I'm currently awaiting a response from the package maintainer wrt getting it
back into sarge (I hear via xine-devel that he's busy). I'll prepare an NMU
if somebody will sponsor it, preferably uploading it to some suitable DELAYED
queue.

-- 
| Darren Salt   | nr. Ashington, | linux (or ds) at
| woody, sarge, | Northumberland | youmustbejoking
| RISC OS   | Toon Army  | demon co uk
|   We've got Shearer, you haven't

A man who turns green has eschewed protein.


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

Re: How to find out why a package was removed from testing?

[Darren Salt]

I demand that Andreas Barth may or may not have written...

[snip]
> perhaps replacing maintainers with bugs is a good idea).

I'm not so sure. What do the bugs know about package maintenance? ;-)

-- 
| Darren Salt   | linux (or ds) at | nr. Ashington,
| sarge,| youmustbejoking  | Northumberland
| RISC OS   | demon co uk  | Toon Army
|   http://www.youmustbejoking.demon.co.uk/> (PGP 2.6, GPG keys)

Ernest BORGnine... you be the judge...


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

Re: NEW handling: About rejects, and kernels

[Daniel Burrows]

On Sunday 03 April 2005 05:51 am, Wouter Verhelst wrote:
> Putting items from the non-free archive in the installer images does
> just that. It is debatable whether the intention is the same, but by our
> rulebook, this is not allowed.

  Wait...so you're saying it's OK to put non-free stuff in the installer image 
if we close our eyes and put our fingers in our ears and pretend that it's 
free and put it in "main" -- but if we call it "non-free", then it's 
forbidden?

  In that case, I think I'll go adjust the odometer in my car so I get better 
gas milage...

  Daniel

-- 
/--- Daniel Burrows <[EMAIL PROTECTED]> --\
|   Exhilaration is that feeling you get just   |
|   after a great idea hits you, and just before|
|   you realize what is wrong with it.  |
\ Got APT? -- Debian GNU/Linux http://www.debian.org ---/


pgpWuMOtZii8b.pgp
Description: PGP signature

bug #255367: Lake of PPTP in Debian first CD

[Lior Kaplan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

I'd like to raise a discussion about PPTP (package name is pptp-linux).
The package is used to connect to the internet, mostly with DSL connections.

According to popcon.debian.org is at #3218 with 323 installations.
Although that number isn't very high, many people in many places (e.g.
Austria, Italy, Israel) depend on this package for internet
connectivity. Without internet connection many people tend to abend
debian during the installation phase.

The package isn't large (91 KB) according to
http://packages.debian.org/unstable/net/pptp-linux.

I'd like to hear what people have to say for/against this bug report.

- --

Thanks,

Lior Kaplan
[EMAIL PROTECTED]
http://www.Guides.co.il

Debian GNU/Linux unstable (SID)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD4DBQFCUDnIFViURZnoHaARAnTHAJ9aVtV0lom1bZd7U1WOR95PsmF0bACY1hmw
VvLFq62+T8+Kky9WYMeYNQ==
=j+xH
-END PGP SIGNATURE-


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

Re: bug #255367: Lake of PPTP in Debian first CD

[Marco d'Itri]

On Apr 03, Lior Kaplan <[EMAIL PROTECTED]> wrote:

> I'd like to hear what people have to say for/against this bug report.
I believe this is a reasonable request.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: bug #255367: Lake of PPTP in Debian first CD

[Henrique de Moraes Holschuh]

On Sun, 03 Apr 2005, Lior Kaplan wrote:
> I'd like to raise a discussion about PPTP (package name is pptp-linux).
> The package is used to connect to the internet, mostly with DSL connections.

I thought that was pppoe?  Isn't pptp some half-assed encripted VPN protocol
from MS ?

-- 
  "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: bug #255367: Lake of PPTP in Debian first CD

[Marco d'Itri]

On Apr 03, Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote:

> I thought that was pppoe?  Isn't pptp some half-assed encripted VPN protocol
> from MS ?
No, but it's related.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: bug #255367: Lake of PPTP in Debian first CD

[Lior Kaplan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I rather use PPPoE, but that's not always an option due to ISPs' choice
(of hardware or software).

Quoting http://www.poptop.org :
"What is PPTP?
PPTP stands for Point to Point Tunneling Protocol. It was developed by a
consortium including Microsoft and is used for establishing VPN (Virtual
Private Network) tunnels across the Internet. This allows remote users
to securely and inexpensively access their corporate network from
anywhere on the Internet.

PPTP uses a client-server model for establishing VPN connections. Most
Microsoft operating systems ship with a PPTP client, so there is no need
to purchase third-party client software. PPTP has the additional
advantage over other VPN technologies of being easy to setup."

Henrique de Moraes Holschuh wrote:
> On Sun, 03 Apr 2005, Lior Kaplan wrote:
> 
>>I'd like to raise a discussion about PPTP (package name is pptp-linux).
>>The package is used to connect to the internet, mostly with DSL connections.
> 
> 
> I thought that was pppoe?  Isn't pptp some half-assed encripted VPN protocol
> from MS ?
> 

- --

Regards,

Lior Kaplan
[EMAIL PROTECTED]
http://www.Guides.co.il

Debian GNU/Linux unstable (SID)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCUEuMFViURZnoHaARAj/RAJ0YXeF/lsvJ/AbpNLCsYWmT6x57+gCeMfBl
JURzgmTdmJ+xNAt9LKumR0M=
=EMB2
-END PGP SIGNATURE-


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

unsubscribe

[David R]

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

Re: Bug#250202: Standardizing make target for 'patch' and 'upstream-source'

[David Schmitt]

On Friday 01 April 2005 02:12, Scott James Remnant wrote:
> I was initially thinking along these lines myself
> , however I'm now starting to lean
> towards not allowing arbitrary shell to just open up a source package;
> it doesn't "feel" safe enough.
>
> I also don't want to break "cd source-version" as the definitive way to
> get to the source afterwards, and am not currently sure how to do that
> with packages containing multiple tarballs.
>
> There's also the issue of how do you clean or put a source package back
> together, when it's got the patches all applied -- how do you know which
> patch any modifications should go into?

Adam Heath claims to have a dbs-ng prototype which does "the right thing".

See http://lists.debian.org/debian-devel/2005/04/msg00062.html


Regards, David
-- 
- hallo... wie gehts heute?
- *hust* gut *rotz* *keuch*
- gott sei dank kommunizieren wir Ãber ein septisches medium ;)
 -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15

Bug#302993: ITP: cduce -- Programming language adapted to the manipulation of XML data

[Thomas Petazzoni]

Package: wnpp
Severity: wishlist
Owner: Thomas Petazzoni <[EMAIL PROTECTED]>


* Package name: cduce
  Version : 0.3.1
  Upstream Author : Alain Frisch <[EMAIL PROTECTED]>
* URL : http://www.cduce.org
* License : MIT-like license
  Description : Programming language adapted to the manipulation of XML data

 CDuce is a modern programming language adapted to the manipulation of
 XML documents.
 .
 Some of CDuce peculiar features:
  - XML objects can be manipulated as first-class citizen values:
elements, sequences, tags, characters and strings, attribute sets;
sequences of XML elements can be specified by regular expressions,
which also apply to characters strings;
  - functions themselves are first-class values, they can be
manipulated, stored in data structure, returned by a function,...;
  - a powerful pattern matching operation can perform complex
extractions from sequences of XML elements;
  - a rich type algebra, with recursive types and arbitrary boolean
combinations (union, intersection, complement) allows precise
definitions of data structures and XML types; general purpose
types and types constructors are taken seriously (products,
extensible records, arbitrary precision integers with interval
constraints, Unicode characters);
  - polymorphism through a natural notion of subtyping, and overloaded
functions with dynamic dispatch; - an highly-effective type-driven
compilation schema
 .
 CDuce is fast, functional, type-safe, and conforms to basic
 standards: Unicode, XML, DTD, Namespaces are fully supported, partial
 support of XML Schema validation is in alpha testing (and
 undocumented) while queries are being implemented.


-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.10
Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1)


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

Re: intend-to-implement: script to obtain Debian Source

[Junichi Uekawa]

Hi,

> The new toolset(tentatively called dbs-ng while I'm developing it) supports
> what I call pre-patched source.

Was this a April-fools joke, or do you have some code that we can look at?

However, the concept looks possible to implement, and 
will fix most of the problems we have with handling Debian 
source packages; I'm not sure if it helps the maintainer side or not,
since I have not looked into the usability aspect yet.

regards,
junichi


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

Re: intend-to-implement: script to obtain Debian Source

[Junichi Uekawa]

Hi,

> | I second suggestion given at #250202 and like to see "unpacked" and
> | "patched" targets to hit Policy 4.8.
> 
> If so, it should be «unpack» and «patch» to match the build and
> install targets.

Note that there are existing packages that use 'unpack' and 'patch'
targets for other meanings.


unpack: some packages unpack the upstream tarball, some do patching
patch: some patch the source tree, some generate patch out of it.


regards,
junichi

Re: bug #255367: Lake of PPTP in Debian first CD

[Henrique de Moraes Holschuh]

On Sun, 03 Apr 2005, Lior Kaplan wrote:
> I rather use PPPoE, but that's not always an option due to ISPs' choice
> (of hardware or software).

I see.  Well, since it IS being used to setup access, then I can't see how
we could object to moving the required packages to support pptp to the first
CD.

So, I vote for including it on the first CD as well.

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