Bug#305753: general: 38 packages still use 'Origin: debian'

[Thijs Kinkhorst]

On Thu, April 21, 2005 23:23, Dan Jacobson wrote:
> It feels odd that a handful of packages seem to use a dusty field:
> $ grep ^O /var/lib/dpkg/available|sort|uniq -c
> 3 Origin: Debian
> 35 Origin: debian
> Shall I clone this bug to them to get them to take it away?

Perhaps you can state in your bugreport why it is needed to fix this. What
problems does that field cause?


Thijs



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

Re: spca5xx -- Device driver for USB webcams based on the spca5xx chips

[Agustin Martin]

On Wed, Apr 20, 2005 at 05:57:02PM -0700, Jeff Carr wrote:
> Jurij Smakov wrote:
> 
> >Since it is becoming more and more a kernel topic, you might also want 
> >to move discussion to debian-kernel.
> 
> Could someone give us a simple rundown of how we would submit a patch to 
> the debian kernel sources to add spca5xx support? The spca5xx driver 
> adds support for a large number of USB cameras. Recently Carlos posted 
> something about adding support to debian-devel and Jurij suggested we go 
> here as it is a kernel issue.

Since you contacted the spca5xx developer, and he didn't seem to care about
putting that driver into the main kernel, I do not see the point in trying
to bypass him for that, even for the Debian kernel. 

Also I see that the original ITP is from Stephen Birch, please coordinate
your steps with him. I would also keep [EMAIL PROTECTED] cc'ed for the
records in that wnpp bug entry.

As Jurij sugested I would go first for a spca5xx-modules-source package, so
users can build spca5xx-modules packages for the kernel they want, by means
of make-kpkg or directly. A patch package would require rebuilding the whole
kernel, what is usually not desirable, unless some of the kernel files are
being modified. In most cases a modules package can be built out of the
modules-source package just having the appropriate kernel sources package
installed.

> The module dir is self contained and "smart" in that it uses `uname -r` 
> to determine the kernel headers. So, one can just go into the dir and 
> type make;make install and spca5xx.ko will automatically be loaded the 
> next time the user boots.

And if you want to build the modules for a different kernel?

That said, I have one of these sunplus cameras, I am happy to see that
modules packaged for Debian.

Cheers,

-- 
Agustin


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

Re: Policy for devfs support

[Henrique de Moraes Holschuh]

On Fri, 22 Apr 2005, Russell Coker wrote:
> On Sunday 27 March 2005 00:26, Roger Leigh <[EMAIL PROTECTED]> 
> wrote:
> > Is there a project-wide policy for support for devfs (and devfs-style,
> > e.g. udev devfs.rules) device naming?
> 
> The SE Linux kernel code doesn't and won't support devfs.  Devfs is on the 
> way 
> out and there is no interest in adding any support.
> 
> SE Linux also has a list of device names for initially labelling a file 
> system.  Neither devfs nor devfs device names will work with SE Linux.

That's fine.  But regular packages should not limit themselves like that
IMHO.  That way, they will work under udev and static, with or without
devfs, in either standard or devfs naming modes.  SE Linux has special
needs, and that's quite easy to understand.

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

More about GFDL

[Maciej Dems]

I have a simple question concerning the GFDL discussion.

Does the GFDL documentation which currently does not contain any invariant 
section have to go to non-free as well?

As I understand the problem, such documentation is free and only can loose 
its freeness in the future. But the same can be told about eg. any 
BSD-licensed program.

-- 
M.Sc. Maciej Dems   [EMAIL PROTECTED]
-
C o m p u t e r   P h y s i c s   L a b o r a t o r y
Institute of Physics,Technical University of Lodz
ul. Wolczanska 219, 93-005 Lodz, Poland, +48426313649


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

Re: More about GFDL

[Henrique de Moraes Holschuh]

On Fri, 22 Apr 2005, Maciej Dems wrote:
> I have a simple question concerning the GFDL discussion.

For which the simple answer is:
Read http://people.debian.org/~srivasta/Position_Statement.xhtml

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

Bug#305843: ITP: kshutdown -- An advanced shut down utility for Linux/KDE

[Romain Beauxis]

Package: wnpp
Severity: wishlist
Owner: Romain Beauxis <[EMAIL PROTECTED]>


* Package name: kshutdown
  Version : 0.6.0
  Upstream Author : Konrad Twardowski <[EMAIL PROTECTED]>
* URL : http://kshutdown.sourceforge.net/
* License : GPL
  Description : An advanced shut down utility for Linux/KDE

KShutDown is an advanced shutdown utility for KDE that trigger a clean
KDE shutdown timer and many other cool features.

The package is ready, lintian and linda clean, and compiles with
pbuilder under sarge.

You can find the sources at this place:
deb-src http://www.cti.ecp.fr/~beauxir5/debian/ source/


-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.11.7-igrec
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]

Bug#305847: ITP: libservlet2.4-java -- Servlet 2.4 and JSP 2.0 Java classes and documentation

[Arnaud Vandyck]

Package: wnpp
Severity: wishlist

* Package name: libservlet2.4-java
  Version : 2.4
  Upstream Author : Apache Jakarta Group
* URL or Web page : http://jakarta.apache.org/tomcat/index.html
* License : Apache 2.0
  Description : Servlet 2.4 and JSP 2.0 Java classes and documentation
 For more information about Java servlets please take a look at the Tomcat
 home page at http://jakarta.apache.org/tomcat/index.html.
 .
 The official Servlet 2.4 and JSP 2.0 specifications can be found at
 http://java.sun.com/products/servlet/ and http://java.sun.com/products/jsp/.

This is a split of tomcat5 source package (this one will be package later)

-- 
Arnaud Vandyck
Java Trap: http://www.gnu.org/philosophy/java-trap.html


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

Re: upload problems, public key not found

[Matthew Palmer]

On Fri, Apr 22, 2005 at 09:30:39PM +0200, Juergen Strobel wrote:
> Almost noone uses kernel-patch-cryptoloop, so I let things slide. AFAIK,
> sarge is to use a 2.6.x kernel, so this package is mostly useless.
> However, a few people expressed interest recently, and added to the old
> bug report #255953.
> 
> I tried to upload an up to date version of this package today, but got
> denied again. I can't remember how I got the initial version in.

I sponsored it for you.  You uploaded to my local queue, and I then checked
it over and uploaded it to the archive on your behalf.

- Matt


signature.asc
Description: Digital signature

libaio dupload imminent

[William Lee Irwin III]

Following up to Message-ID: <[EMAIL PROTECTED]>, I've
put together a libaio package at http://holomorphy.com/~wli/libaio/
I figured a year or so was long enough to give people time to complain
about the kernel interface vs. glibc's worker thread -based emulation
library and so on, and thus far I've not gotten many objections.

It was a bit of a struggle for me to put this together, as I'm rather
unused to dealing with userspace, so comments and suggestions on the
packaging are welcome.

Thanks to doogie and jvw who gave me a great deal of help with putting
the package together as I encountered various issues.

Thanks.


-- wli


signature.asc
Description: Digital signature

Re: Temporal Release Strategy

[Adrian Bunk]

On Fri, Apr 22, 2005 at 12:21:49PM -0400, Patrick Ouellette wrote:
> On Wed, Apr 20, 2005 at 04:56:32AM +0200, Adrian Bunk wrote:
> > The rules and goals of testing are clear.
> > 
> > The more interesting points are the problems of testing that several 
> > years of using it have shown.
> > 
> > > If package FOO has a RC bug, then everything that depends on FOO will be
> > > stuck AT WHATEVER POINT IT IS IN THE PROCESS until FOO is fixed.  If
> > > fixing FOO breaks BAR, then they all wait again until BAR is fixed.  Use
> > > of experimental to work through some of these issues would help.
> > > I'm not saying it won't take manual coordination to handle complex
> > > changes to the system.  I'm not saying it will make anyone's life
> > > easier.  What my proposal will do is provide the ability to decide when
> > > package $PACKAGE makes it into stable, we will call that an official
> > > release and give it a number.  Alternatively, you could declare every
> > > $INTERVAL Debian releases.  What is in stable should have been well
> > > tested, and supportable.  Stable no longer is a static concept, but a
> > > slowly evolving thing.  If you cannot wrap your mind around to accepting
> > > a stable that evolves, we could snapshot stable at release data and make
> > > a separate archive (really a Packages.gz and related files as long as
> > > the version of the package in the release exists in the package pool).
> > 
> > You completely miss my point:
> > 
> > There are several transitions every month, and a big transition can 
> > involve several hundred packets.
> > 
> > Your proposal requires, that _every single_ package that is part of a 
> > transition has to be both ready and in testing for over 3 months before 
> > it can enter your proposed "candidate".
> > 
> > If _one_ of the packages that is part of a transition is updated in 
> > testing during this time, the 3 months start again. For bigger 
> > transitions, it's therefore practically impossible that they will be 
> > able to enter your "candidate".
> 
> I don't believe I missed your point, you just don't seem to be able to
> grasp the fact that I intend candidate to change slowly. 
> 
> Yes, I am proposing that every package involved in a transition be of
> adequate quality to be promoted to candidate.  The purpose of the entire
> release system is to ensure the quality of the Debian distribution.
> Debian releases "when it's ready" because Debian demands a certain
> minimum level of quality (currently defined as an arbitrary number of RC
> bugs in packages of variable importance in the distribution as seen by
> the release manager).  I'm proposing a system that allows "when it's
> ready" to be defined and automated.  Our current release system places
> an enormous burden on the release manager.
> 
> > 
> > Please try to understand the limitations of testing before proposing 
> > something even stricter.
> > 
> 
> I understand the limitations of testing.  In fact, I am depending on the
> limitations of the testing rules to ensure that candidate is of adequate
> quality and changes slowly enough to be used on desktop workstations and
> that stable is adequate for servers.


The problem is that for many transitions, "slowly" means "never", since 
the criteria you set are unlikely to be fulfilled for all parts of such 
a transition at any time in the future.

And the more time passes, it becomes more and more complicated since 
additional transitions might be interdependent with a transition making 
the problem even more complicated.


> I am proposing a system that removes some of the arbitrary nature of
> what we call a stable package.  I'm proposing that we define QUALITY
> CONTROL standards that ALL packages adhere to so that when someone says
> they recommend Debian's testing/candidate/stable release, they can point to a
> testing system that allows the person to select which branch they use
> based upon well know published criteria for the stability of that
> particular branch.  The user controls the amount of risk they are
> willing to have in their system.


That's already true today.

People who like the latest software can choose between unstable and 
testing with testing usually having a bit less known bugs.

People who want stability use stable.


> Testing, candidate and stable should change progressively slower.  That
> is the entire point.


As I am trying to explain, the speed of changes to stable will sonn 
become zero.


If you believe your approach would work, please try the following:

Take stable from today, and make this your "candidate".
Take testing from today.

Create a complete list of all packages that have to go from testing into 
your "candidate" _at the same time_ for getting e.g. the tiff transition 
into your "candidate".

If after this you do still believe your approch would work, please send 
the complete list of packages you think would be involved in this one 
transition (to let me check whether you missed some - 

Re: Bug#304266: ITP: sdate -- never ending september date

[Henning Makholm]

Scripsit Russell Coker <[EMAIL PROTECTED]>

> Incidentally I wrote a shared object to support changing the apparent time 
> which was actually useful for such tasks as Y2K testing and running demo 
> software.  Getting it to change the time() library call was easy, changing 
> the time stamp on files that were written was more painful.

Hm, perhaps such a thing could also be useful for testing properties
such as "source packages A and B build bitwise-identical binary
packages on architecture X" which would otherwise be skewed by
timestamps embedded in the files in the binary packages. This might be
useful post-Vancouver for letting lesser architectures sneak #ifdef'ed
corrections into the stable source pool without risking functional
changes on the released architectures.

-- 
Henning Makholm "De spiller på harpe og drikker øl."

Re: Temporal Release Strategy

[Patrick Ouellette]

On Mon, Apr 18, 2005 at 07:37:40PM -0500, Gunnar Wolf wrote:
> Patrick Ouellette dijo [Sat, Apr 16, 2005 at 01:04:59AM -0400]:
> > (...)
> > Another difference is that testing will get new versions of packages and
> > those versions might (but should not) cause breakage.  Testing has had
> > breakage issues in the past.  Ten days is not enough time to catch all
> > the possible interactions (or even the majority of them).  I'm also not
> > naive enough to think that my proposed "candidate" step will never cause
> > breakage.  The purpose of the additional step is to have a place where
> > things change slower than testing to catch more of the obscure bugs that
> > only become apparent with more time.  By requiring there be 0 RC bugs to
> > progress from "testing" to "candidate" and "candidate" to "stable" we
> > cause stable to change when the software really stabalizes, not at an
> > arbitrary time selected by the release team. 
> 
> Umh... And... Well, if a RC bug is found in candidate, will it take (a
> very minimum of) one month for the fix to get there? 

Yes, that is true.  It will take time for the fix to work through the
system, and there is also the possibility of finding additional RC bugs
in the candidate version that further delay the cycle.  That's how the
iterative develop-test-release cycle works.

> 
> Don't you think that, during the release cycle (and specially during
> its first phase after a release) we will always have one RC bug
> keeping a second one from getting fixed?
>

If that is indeed the case, no software would ever be released.

The trick is to make the number of known RC bugs at the time a package
moves from one stage to the next 0.  If a bug truly is release
critical, then that package should not be in the release while it
is known to contain that bug.

Pat

-- 

Patrick Ouellette
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Amateur Radio: KB8PYM 


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

ITP: lynkeos.app -- Tool to process planetary astronomical images for GNUstep

[Gürkan Sengün]

Package: wnpp
Severity: wishlist

* Package name: lynkeos.app
  Version : 1.2
  Upstream Authors: Christophe Jalady <[EMAIL PROTECTED]>,
Jean-Etienne Lamiaud <[EMAIL PROTECTED]>
* URL : http://lynkeos.sourceforge.net/
* License : GNU GPL
  Description : Tool to process planetary astronomical images for GNUstep
 This is an application dedicated to the processing of astronomical
 (mainly planetary) images taken with a webcam through a telescope.
 It was created on Mac OS X.
 .
 Homepage: http://christophe.jalady.free.Fr/lynkeos/


It's actually here already for you to try:
http://gnu.ethz.ch/debian/lynkeos/


-- System Information:
Debian Release: testing/unstable
Architecture: powerpc
Kernel: Linux ibook 2.4.23-ben1 #7 Sat Dec 27 11:20:38 CET 2003 ppc
Locale: LANG=POSIX, LC_CTYPE=POSIX


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

Status of 'sarge' for the amd64 architecture

[Andreas Jochens]

As a preparation for the amd64 porters irc meeting tomorrow, 
I tried to build the complete Debian sarge archive for the 
amd64 architecture from the unpatched Debian sarge sources.

It took about a week to build all 8800+ source packages on a standard
single processor EM64T-P4 box (Every package was built in a newly 
created clean chroot environment. By relaxing this requirement, the 
build time for the archive could probably be reduced to less than 
four days.)

The result was very encouraging. Almost all packages build now on 
amd64 without problems using the pristine Debian sarge sources.

There are very few remaining cases where a patch has been submitted to 
the BTS a long time ago and for some reason that patch has not yet been 
applied. These cases could either be solved by a porting NMU or by 
just dropping that package from the amd64 version of sarge.

For some reason, the amd64 architecture has not been added to the 
official Debian archive. There is a plan to change this when sarge is 
released, but as I understand it, there is no plan to provide 
amd64 binaries for sarge in the official Debian archive.

This means that Debian sarge will be released with source packages
that can be used to build a complete and fully usable Debian sarge 
distribution for the amd64 architecture, but there will be no binaries 
available in the main Debian archive.

This is not necessarily as bad as it may look at a first glance. 

First of all, everybody can build its own Debian amd64 sarge archive 
from the official Debian sarge sources. It will take only a 
few days to build the complete archive on cheap commodity hardware.
This archive build process, including later updates, can easily be 
automated by a small script.

To build packages from sources instead of downloading binary packages
from a Debian archive may be a good idea from a security point 
of view. For critical applications it seems to be problematic to trust
a binary archive which depends on the integrity of the machines of 1000
Debian developers.

But of course, there _is_ a binary Debian amd64 sarge archive.
The debian-pure64 amd64 archive on alioth is maintained by members 
of the amd64 porting team. It tracks the current Debian 
'unstable' and 'testing' distributions.

In the current situation, the amd64 porting team is responsible for 
providing and maintaining the amd64 binary archive and the amd64 
buildd infrastructure, while the sources are taken from the 
normal Debian source archive.

I consider this a good way to split up responsibilities. 
This way of handling things could serve as a good example of
how other ports may be organized after sarge is released.

As a conclusion, I think that it may still be possible to release
the amd64 port with sarge. Nothing in the current setup has to be 
changed for that. It is just a matter of recognizing the current 
state of affairs officially. 

It will only be necessary to describe the current situation 
in the official release documents and include pointers 
to the separate amd64 archive, which will be provided 
by the amd64 porting team anyway.

Regards
Andreas Jochens

P.S.: The above statements represent my personal view only.
Other members of the amd64 porting team may view things differently,
of course.


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

Re: Temporal Release Strategy

[Eduard Bloch]

Moin Patrick!
Patrick Ouellette schrieb am Freitag, den 22. April 2005:

> > And the more time passes, it becomes more and more complicated since 
> > additional transitions might be interdependent with a transition making 
> > the problem even more complicated.
> > 
> 
> You are very good at repeating "this will never work."  You are

Please, do the math (literally, the particular are is stochastics).

> > People who want stability use stable.
> > 
> It is not true today.  What is true is people who are not running
> hardware less than 36 (or so) months old have the option of running



> People are not able to choose by their desired "comfort level" of
> stability.  If anything, my proposal might allow people to choose which
> version they want to run based on their desired level of stability -
> instead of what will run on their hardware.

And I still cannot see the innovation in your idea. It is basically a
second testing with stronger conditions - and the current one has
already failed in respect of the original requirements.

Regards,
Eduard.
-- 
 Overfiend: why dont you flame him? you are good at that.
 I have too much else to do.


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

Re: What do you win by moving things to non-free?

[Steve Greenland]

On 20-Apr-05, 16:48 (CDT), Matthew Garrett <[EMAIL PROTECTED]> wrote: 
> Steve Greenland <[EMAIL PROTECTED]> wrote:
> 
> > And now you say it's *still* going on?
> 
> Yes. For various reasons, I'm more hopeful now than I have been
> previously.

Well, I'll be amazed and delighted when you prove me wrong, but I don't
expect it.

Steve

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


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

Re: Bug#302309: ITP: bcron -- Bruce's cron system

[Steve Greenland]

On 21-Apr-05, 05:12 (CDT), Gerrit Pape <[EMAIL PROTECTED]> wrote: 
> > Why re-write cron when cron only needs a minor change?
> 
> I'm afraid I again can't follow your thinking. 

I'm pretty sure that he was only talking about implementing @reboot in
bcron, rather than requiring a whole new system to implement user jobs
at reboot.

Steve

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


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

Re: Temporal Release Strategy

[Patrick Ouellette]

On Fri, Apr 22, 2005 at 07:16:30PM +0200, Adrian Bunk wrote:
> 
> The problem is that for many transitions, "slowly" means "never", since 
> the criteria you set are unlikely to be fulfilled for all parts of such 
> a transition at any time in the future.
> 
> And the more time passes, it becomes more and more complicated since 
> additional transitions might be interdependent with a transition making 
> the problem even more complicated.
> 

You are very good at repeating "this will never work."  You are
essentially saying it is impossible for a package to have no RC bugs,
and that those bugs are never going to be fixed fast enough to progress
through the quality control system I proposed.  I have a bit more faith
in my fellow Debian Developers than that.

I admit that the candidate phase will change more slowly than testing -
it is supposed to.  The stable (or whatever it is called - maybe
production) section will change even more slowly.  This is by design.
> 
> > I am proposing a system that removes some of the arbitrary nature of
> > what we call a stable package.  I'm proposing that we define QUALITY
> > CONTROL standards that ALL packages adhere to so that when someone says
> > they recommend Debian's testing/candidate/stable release, they can point to 
> > a
> > testing system that allows the person to select which branch they use
> > based upon well know published criteria for the stability of that
> > particular branch.  The user controls the amount of risk they are
> > willing to have in their system.
> 
> 
> That's already true today.
> 
> People who like the latest software can choose between unstable and 
> testing with testing usually having a bit less known bugs.
> 
> People who want stability use stable.
> 
It is not true today.  What is true is people who are not running
hardware less than 36 (or so) months old have the option of running
stable (the kernel shipping and included with stable just does not have
drivers for new hardware).  This has been a perpetual problem.

People who need a stable distribution should not be forced to use
testing or unstable because they have hardware that is only 18 months
old, especially when you consider the pace of change in computer
hardware manufacturing.

The reality today is people who have older hardware can choose to run
Debian stable.  People with newer but by no means cutting edge hardware
do not have the option of installing stable.  They can choose testing or
unstable.

People who want security updates from the Debian security team must run
stable.  If you want security fixes and have newer hardware, you must
run unstable (and hope the maintainer uploads a fixed version quickly)
or patch the testing packages yourself.

People are not able to choose by their desired "comfort level" of
stability.  If anything, my proposal might allow people to choose which
version they want to run based on their desired level of stability -
instead of what will run on their hardware.

> 
> > Testing, candidate and stable should change progressively slower.  That
> > is the entire point.
> 
> 
> As I am trying to explain, the speed of changes to stable will sonn 
> become zero.

The speed of changes to stable is currently zero.  Debian does not have
to do anything to maintain that.  My proposal would at the very least
change that from zero to "glacially slow," with the option to pick a
version that changes "slow", "fast", or "continuously."
> 
> 
> If you believe your approach would work, please try the following:
> 
> Take stable from today, and make this your "candidate".
> Take testing from today.
>

Actually, I am planning on working on that this weekend.  I was not
going to start with the current stable, but with the current testing.  I
will be building a candidate list by using my proposed rules (0 RC bugs,
3 months or more in testing).

I will build a "new stable" from the candidate list with those packages
that have been in testing 6 or more months with 0 RC bugs.

It will be interesting to see how many required, base, standard, and
optional packages meet the standard I propose.

> Create a complete list of all packages that have to go from testing into 
> your "candidate" _at the same time_ for getting e.g. the tiff transition 
> into your "candidate".
> 
> If after this you do still believe your approach would work, please send 
> the complete list of packages you think would be involved in this one 
> transition (to let me check whether you missed some - they are much more 
> than hundred), and explain at which time of the future you expect 
> every single package in the list to fulfill your criteria at the same 
> time.
> 

I will publish the results on my people.Debian.org page at
http://people.debian.org/~pouelle/temporal_release.html

Look for that URL to be updated by 13:00 25-APR-2005 UTC

I will not be able to explain at which time I expect a particular
package to meet the standards since I don't maintain each and every
package in Debian.  Debian

Re: Temporal Release Strategy

[Patrick Ouellette]

On Wed, Apr 20, 2005 at 04:56:32AM +0200, Adrian Bunk wrote:
> The rules and goals of testing are clear.
> 
> The more interesting points are the problems of testing that several 
> years of using it have shown.
> 
> > If package FOO has a RC bug, then everything that depends on FOO will be
> > stuck AT WHATEVER POINT IT IS IN THE PROCESS until FOO is fixed.  If
> > fixing FOO breaks BAR, then they all wait again until BAR is fixed.  Use
> > of experimental to work through some of these issues would help.
> > I'm not saying it won't take manual coordination to handle complex
> > changes to the system.  I'm not saying it will make anyone's life
> > easier.  What my proposal will do is provide the ability to decide when
> > package $PACKAGE makes it into stable, we will call that an official
> > release and give it a number.  Alternatively, you could declare every
> > $INTERVAL Debian releases.  What is in stable should have been well
> > tested, and supportable.  Stable no longer is a static concept, but a
> > slowly evolving thing.  If you cannot wrap your mind around to accepting
> > a stable that evolves, we could snapshot stable at release data and make
> > a separate archive (really a Packages.gz and related files as long as
> > the version of the package in the release exists in the package pool).
> 
> You completely miss my point:
> 
> There are several transitions every month, and a big transition can 
> involve several hundred packets.
> 
> Your proposal requires, that _every single_ package that is part of a 
> transition has to be both ready and in testing for over 3 months before 
> it can enter your proposed "candidate".
> 
> If _one_ of the packages that is part of a transition is updated in 
> testing during this time, the 3 months start again. For bigger 
> transitions, it's therefore practically impossible that they will be 
> able to enter your "candidate".

I don't believe I missed your point, you just don't seem to be able to
grasp the fact that I intend candidate to change slowly. 

Yes, I am proposing that every package involved in a transition be of
adequate quality to be promoted to candidate.  The purpose of the entire
release system is to ensure the quality of the Debian distribution.
Debian releases "when it's ready" because Debian demands a certain
minimum level of quality (currently defined as an arbitrary number of RC
bugs in packages of variable importance in the distribution as seen by
the release manager).  I'm proposing a system that allows "when it's
ready" to be defined and automated.  Our current release system places
an enormous burden on the release manager.

> 
> Please try to understand the limitations of testing before proposing 
> something even stricter.
> 

I understand the limitations of testing.  In fact, I am depending on the
limitations of the testing rules to ensure that candidate is of adequate
quality and changes slowly enough to be used on desktop workstations and
that stable is adequate for servers.

I am proposing a system that removes some of the arbitrary nature of
what we call a stable package.  I'm proposing that we define QUALITY
CONTROL standards that ALL packages adhere to so that when someone says
they recommend Debian's testing/candidate/stable release, they can point to a
testing system that allows the person to select which branch they use
based upon well know published criteria for the stability of that
particular branch.  The user controls the amount of risk they are
willing to have in their system.

Testing, candidate and stable should change progressively slower.  That
is the entire point.

Pat

-- 

Patrick Ouellette
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Amateur Radio: KB8PYM 


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

Re: advice needed on handling network port conflicts

[Steve Greenland]

On 21-Apr-05, 11:07 (CDT), Eric Cooper <[EMAIL PROTECTED]> wrote: 
> But if apt-proxy is still installed and running when apt-proxy starts
> up, it will fail because the port is in use.  Should I make the approx
> package conflict with apt-proxy?  Both packages allow the port to be
> changed to something else, so it's not impossible for them to coexist
> (just difficult in their default configurations).  Any suggestions
> or policy pointers here would be appreciated.

Just default to a different port, and suggest in the README.Debian that
people with existing apt-proxy installations can easily change the port
to match. Anybody whose using these tools can probably figure this out.

Steve

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


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

Re: Temporal Release Strategy

[Patrick Ouellette]

On Thu, Apr 21, 2005 at 01:04:34AM +0200, Adrian Bunk wrote:
> Let my try to explain it:
> 
> 
> The "debian stable == obsolete" is a release management problem of 
> Debian. One release every year and it would be suitable for most 
> purposes.
>

This is the problem.  Debian has NEVER been able to have a release every
year.  Most server administrators I know would prefer a release cycle
longer than 12 months, most desktop users would prefer around 12-24
months.

The issue has always been one of "how many RC bugs are acceptable in the
release" and this has always been at the discretion of the release
manager.

> 
> You say you've deployed Debian sarge and sid in server environments 
> (even sarge, although months old security fixes might be missing???).
> 
> Let me ask some questions:
> - How many thousand people can't continue working if the server isn't
>   available?
For comparative purposes, I have worked as systems/network/admin where
the number has been as small as 50 and as large as 30,000.

> - How many million dollar does the customer lose every day the server is
>   not available?

We measured it in millions of dollars per hour, not day.

> - How many days without this server does it take until the company is
>   bankrupt?

We never got to that point, because it was simply not an option.

> 
> 
> If the mail server of a small company isn't running for a few hours it's 
> not a problem - but there are also other environments.
> 

Since you seem to be trolling, I'll feed the troll:  If that small
company relies on the email server to take orders from  customers, that
few hour outage could translate into a large amount of money.  If that
small company is not financially sound, that few hour outage may be the
cause of that small business failing.  Large organizations are much
better equipped to weather a temporary outage (larger cash reserves,
ability to implement backup  systems, etc).

> 
> Regarding things broken in woody:
> 
> In many environments, the important number is not the total number of 
> bugs but the number of regressions. Doing intensive tests once when you 
> install/upgrade the machine is acceptable, but requiring this every 
> month because it's required for the security updates that bring new 
> upstream releases is not acceptable.
> 

This is the current norm now if you take seriously your system's
stability.  If you really value stability, you will test each and every
application on the system each time a change is made.  You would
be examining each security patch to make sure you understood what was
happening and that it was safe before you installed it.

> 
> > >Look at the third use case I explained above. For these users of Debian, 
> > >long-living releases where the _only_ changes are security fixes are 
> > >_very_ important.
> > 
> > Again, I don't think you ever built a commercial product around Linux 
> > based on your statements here. No offence if you have, maybe it's just 
> > corporate culture differences between the EU and US?
> 
> 
> There are reasons why companies pay several thousand dollars licence 
> fees for every computer they run the enterprise version of some 
> distribution on. E.g. RedHat supports each version of their enterprice 
> edition for seven years. A few thousand dollars are _nothing_ compared 
> to the support costs and man months that have to be put into setting up 
> and testing the system.
> 
So it should be no problem for those companies who choose to run Debian
to forward a small donation to Debian for all the thousands they save.
Or maybe they should allow their staff to spend several hours a week
getting paid to contribute to Debian.

My point is Debian is NOT a corporate product.  If it is found to be
useful by corporations that's great for them.  If the corporations want
to run Debian, there are companies that offer similar support for Debian
that RedHat and Novell offer for their respective distros.

Since Debian is not a corporate product, Debian is free to investigate
and try different strategies without worrying about the monetary impact
of those changes in the same way a corporate distribution has to.  We
can innovate because it makes sense, not because it is good for the
bottom line.

> 
> Debian stable is ancient - but that's something you have to ask the 
> Debian release management about. If the officially announced release 
> date for sarge is now missed by more than one and a half years this is 
> the issue where investigation should take place.
> 

Which is the issue I was attempting to suggest a possible solution to.

> Regarding sarge:
> 
> I do personally know people who had serious mail loss due to #220983. At 
> the time I reported this bug, it was present in sarge. This problem 
> couldn't have happened in a Debian stable (because it would have been 
> discovered before the release would have been declared stable). This 

This is the biggest delusion I have ever heard.  Any piece of software
can have a critical and u

Re: Temporal Release Strategy

[Adrian Bunk]

On Fri, Apr 22, 2005 at 12:02:39PM -0400, Patrick Ouellette wrote:
> On Thu, Apr 21, 2005 at 01:04:34AM +0200, Adrian Bunk wrote:
> > Let my try to explain it:
> > 
> > 
> > The "debian stable == obsolete" is a release management problem of 
> > Debian. One release every year and it would be suitable for most 
> > purposes.
> 
> This is the problem.  Debian has NEVER been able to have a release every
> year.  Most server administrators I know would prefer a release cycle
> longer than 12 months, most desktop users would prefer around 12-24
> months.


But this peoblem is not solved by your proposal (and please read my 
other email why your proposal won't work).

Your release management has announced that the testing release process 
was able to achive this if they drop two thirds of the Debian 
architectures.

I'd say the pre-testing was able to achieve this with a dozen 
architectures.


> The issue has always been one of "how many RC bugs are acceptable in the
> release" and this has always been at the discretion of the release
> manager.


This number has never been highe than zero [1].


> > You say you've deployed Debian sarge and sid in server environments 
> > (even sarge, although months old security fixes might be missing???).
> > 
> > Let me ask some questions:
> > - How many thousand people can't continue working if the server isn't
> >   available?
> For comparative purposes, I have worked as systems/network/admin where
> the number has been as small as 50 and as large as 30,000.
> 
> > - How many million dollar does the customer lose every day the server is
> >   not available?
> 
> We measured it in millions of dollars per hour, not day.
> 
> > - How many days without this server does it take until the company is
> >   bankrupt?
> 
> We never got to that point, because it was simply not an option.


And critical machines for such a company were running a Debian testing 
or unstable???


> > If the mail server of a small company isn't running for a few hours it's 
> > not a problem - but there are also other environments.
> 
> Since you seem to be trolling, I'll feed the troll:  If that small
> company relies on the email server to take orders from  customers, that
> few hour outage could translate into a large amount of money.  If that
> small company is not financially sound, that few hour outage may be the
> cause of that small business failing.  Large organizations are much


I am not trolling.

All I wanted to say is that there are not that much computer-bound small 
companies that can live with some outages.


> better equipped to weather a temporary outage (larger cash reserves,
> ability to implement backup  systems, etc).


An interesting problem about software bugs is, that they affect backup 
systems as well.


>...
> > > >Look at the third use case I explained above. For these users of Debian, 
> > > >long-living releases where the _only_ changes are security fixes are 
> > > >_very_ important.
> > > 
> > > Again, I don't think you ever built a commercial product around Linux 
> > > based on your statements here. No offence if you have, maybe it's just 
> > > corporate culture differences between the EU and US?
> > 
> > 
> > There are reasons why companies pay several thousand dollars licence 
> > fees for every computer they run the enterprise version of some 
> > distribution on. E.g. RedHat supports each version of their enterprice 
> > edition for seven years. A few thousand dollars are _nothing_ compared 
> > to the support costs and man months that have to be put into setting up 
> > and testing the system.
> 
> So it should be no problem for those companies who choose to run Debian
> to forward a small donation to Debian for all the thousands they save.
> Or maybe they should allow their staff to spend several hours a week
> getting paid to contribute to Debian.


AFAIK neither money nor human resources are a problem of Debian.

SPI already has more money than plans how to reasonable spand it, and if 
manpower was a problem in a project with nearly thousand official and 
trusted developers, this would be an organizational problem but not a 
problem you could solve by adding more people to the project - people 
discovered not less than thirty years ago that adding people to a 
project often _increases_ the time until the goal is reached.


> My point is Debian is NOT a corporate product.  If it is found to be
> useful by corporations that's great for them.  If the corporations want
> to run Debian, there are companies that offer similar support for Debian
> that RedHat and Novell offer for their respective distros.
> 
> Since Debian is not a corporate product, Debian is free to investigate
> and try different strategies without worrying about the monetary impact
> of those changes in the same way a corporate distribution has to.  We
> can innovate because it makes sense, not because it is good for the
> bottom line.


Debian plans to drop two thirds of it's architectures from

Re: Temporal Release Strategy

[Patrick Ouellette]

On Mon, Apr 18, 2005 at 04:24:34PM -0500, Adam M wrote:
> A similar thing is already here in http://snapshot.debian.net/

Similar only in that they have daily snapshots.  Vastly dissimilar in
that what is provided is the complete archive, bugs and all.

I'm not saying we call each day a release, but we allow stable to be 
updated from candidate daily and call it a release when a particular
event happens.  That event is to be defined outside the process of 
the archive evolution.

> 
> You cannot do this with the archive. The current archive size is
> already too big for most mirrors to handle.
> 

I don't believe this would add a significant amount of material to the
archive.  If the software in candidate is stable, the only time a
package is different between candidate and testing is during the three
month test period. Archive size needs to be addressed, and will most
likely continue to be a problem for some time to come.   

> > You can still have this environment.  As long as your system looks at
> > the Packages file from the release (and the security updates Packages
> > file).
> 
> see above link :)
> 
> > Testing does not remedy this problem.  If testing was "virtually always
> > production quality" then there would be no need for the release manager
> > to go through an elaborate freeze & bug fix cycle to get things in shape
> > for a release.
> 
> All you are proposing is another testing-like stage. Bugs would
> propagate there regardless. Bugs are part of stable as well.
>

Yes, bugs are part of each and every package.  The trick is in knowing
what bugs are present so you can deal with them.  The longer you test,
the greater the chance that a critical bug which requires an unlikely
sequence of events to trigger will be discovered.

> > > We should not destroy the notion of stable to get up-to-date packages.
> > 
> > I'm not trying to destroy the notion of stable, I have a different
> > definition of stable.  My definition of stable is software that does
> > what it is designed to do without bugs, in the manner in which the
> > designer and programmer intended.  I'm also trying to show that the
> 
> Then your stable never existed. All software has bugs be it Linux or
> Windows based Software of any complexity without any bugs does not
> exist. For example, look at the number of bugs in emacs, yet, I would
> consider the software mature and relatively bug-free.
> 

I would argue that it depends on which particular version of emacs you
are using as to if it should be called mature and relatively bug free.a
If you are pulling the latest CVS snapshot I would not call that mature
or bug free.  If you are using a version that has been released for some
time, then it is possible to consider it mature - the bug free part is
another story.  Mature != bug free.  Stable != bug free.  

Mature can mean "feature rich" or "old" and stable can mean "unchanging"
or "of sufficient quality for the intended purpose."

> > traditional concept of a release in Debian is outdated.  I will even go
> > so far as to say the reason Debian has had exponentially longer release
> > cycles is that the traditional concept of a release is flawed for a
> > project the size and scope of Debian.  We need to adjust our thinking
> > outside the traditional definitions.
> 
> Why? Why is there RHEL 2.0, 3.0.. Why not just RHEL 2005-01-01,
> 2005-01-02, etc..? The releases are there to provide interface
> stability. Everyone does this. What you are proposing is the time
> based snapshots which are already available on
> http://snapshot.debian.net/

I am proposing a progressive update to stable, so we can declare a
collection of packages (with their associated version numbers) a release
by a well defined rule.  Once a release is declared, you have what you
termed "interface stability."  I am only proposing time based snapshots
in that you could, on any given day declare what was in the stable
Packages file to be a release, and it could contain different packages
than the previous release.

> 
> Now, if you want to support snapshot of Debian with 36 month security,
> well, be my guest :) In the last 36-months, there were about 30
> uploads of Apache to unstable. Now, if only 15 such versions
> propagated to stable snapshots, then you find a remote hole, and
> suddenly you have to backport a security fix for 15 versions of
> Apache!

If there were 30 uploads of apache, over 36 months, there would not have
been any updates to the candidate package as none of the updates were
old enough.  This is he point of the 3 month time to discover bugs.

If a security fix is needed, we only are fixing the last few versions
that made it to stable - given your scenario at most two versions.

> 
> Also, try providing an efficient stable security build daemons! The
> chroots would have to be rebuilt for each package.
> 

Again, this need is addressed by the requirement that the package meet
the rules for promotion.  The challenge would be little different t

Re: Re: Packages with unusable documentation

[Dominic Amann]

On Sun, Apr 04, 2004 at 10:35:32AM +0200, Otto Wyss wrote:
To solve my mkinitrd problem I searched for solutions. Each time someone
has run into my problem he was asked if module-init-tools are installed
and each time it was answered yes. Unfortunately also each time no
further action is mentioned.
I looked into module-init-tools to find out what's doing. First I tried
"man module-init-tools" which didn't work. Second I looked into
"/usr/share/doc/module-init-tools" just to discover there is just
useless common facts. Third I started dselect and read the package
description which didn't help further.
How about this simple pipe
 dpkg -L PACKAGE | egrep '^/usr/share/(info|man)/'
as a starting point?
Cheers
. Siggy
 

Tragically, here I am in April 2005 with essentially the same problem, 
and the same shortage of information. I basically lucked into this 
discussion thread via google. I honestly can't see the viability of the 
replies given to Otto Wyss. There _is_ a documentation problem. Packages 
don't have an easy (end user) way to list what is in the package, or a 
standard for useful overview or mechanisms. To shout him down, and then 
to provide (admittedly useful, but certainly not end-user friendly) info 
is counter productive. Sure he came off a little as telling package 
maintainers what to do. Sure, his suggestion (which places him in the 
top 1% of complainers) does not fit in to the carefully considered 
packaging strategy being adhered to by you all.

I have yet to find out, for example which files I need to fiddle with to 
fix my autoloading problem of certain modules. I need a debian specific 
overview of where to put my device specific 'aliases' and 'options', 
especially since some packages I am playing with are not debian 
friendly, or were designed for prior kernels/modutils. I am almost 
certain that this info exists somewhere. It is just not apparent where, 
and google is still a somewhat clumsy tool for this job.

I _do_ appreciate the fine work done by mostly volunteer maintainers. I 
do understand that documentation gets short-shift in favour of 
functionality. However, Linux is (in my opinion) to the point where 
lacking documentation might be hindering adoption /more/ than lacking 
functionality. I therefore humbly suggest that in this case, MS has done 
some things right: by enlisting their ordinary users in usability tests, 
they have seriously re-engineered the way many things worked in windows. 
Now we all know there are still many ways windows falls far short. This 
is an opportunity. Linux enthusiasts /must/ listen to their struggling 
users if they have any desire for the wider adoption of linux.

Remember that the average Linux enthusiast spends only a fraction of 
his/her time installing/configuring a particular device/subsystem. They 
will typically spend many more hours productively using their software, 
and almost no time fixing it because it broke itself or was broken by 
insertion of other software. Therefore, almost no-one will have the 
level of deep familiarity with any particular subsystem that the device 
maintainers have. Even to the point of not knowing what questions to ask 
(thus eliminating even google). I wrestle with this issue regularly, 
especially as the kernel is moving fast, and software is playing 
catch-up, and I consider myself quite knowledgeable.

---
Dominic Amann, Linux Based Solutions Ltd., 
   18 Candlewood Cr, Toronto, ON M3J 1G8
   Tel: (416) 678-2297
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Temporal Release Strategy

[Adrian Bunk]

On Fri, Apr 22, 2005 at 02:54:38PM -0400, Patrick Ouellette wrote:
> On Fri, Apr 22, 2005 at 07:16:30PM +0200, Adrian Bunk wrote:
> > 
> > The problem is that for many transitions, "slowly" means "never", since 
> > the criteria you set are unlikely to be fulfilled for all parts of such 
> > a transition at any time in the future.
> > 
> > And the more time passes, it becomes more and more complicated since 
> > additional transitions might be interdependent with a transition making 
> > the problem even more complicated.
> > 
> 
> You are very good at repeating "this will never work."  You are
> essentially saying it is impossible for a package to have no RC bugs,
> and that those bugs are never going to be fixed fast enough to progress
> through the quality control system I proposed.  I have a bit more faith
> in my fellow Debian Developers than that.
> 
> I admit that the candidate phase will change more slowly than testing -
> it is supposed to.  The stable (or whatever it is called - maybe
> production) section will change even more slowly.  This is by design.


Show me how my tiff transition example will work in your proposal, and 
you can prove me wrong...


>...
> > > Testing, candidate and stable should change progressively slower.  That
> > > is the entire point.
> > 
> > 
> > As I am trying to explain, the speed of changes to stable will sonn 
> > become zero.
> 
> The speed of changes to stable is currently zero.  Debian does not have
> to do anything to maintain that.  My proposal would at the very least
> change that from zero to "glacially slow," with the option to pick a
> version that changes "slow", "fast", or "continuously."
> > 
> > 
> > If you believe your approach would work, please try the following:
> > 
> > Take stable from today, and make this your "candidate".
> > Take testing from today.
> >
> 
> Actually, I am planning on working on that this weekend.  I was not
> going to start with the current stable, but with the current testing.  I
> will be building a candidate list by using my proposed rules (0 RC bugs,
> 3 months or more in testing).
> 
> I will build a "new stable" from the candidate list with those packages
> that have been in testing 6 or more months with 0 RC bugs.


Where do you get the information from how long a package is in testing?
Do you have 6 months of update_output, or is there a source I do not 
know about?


> It will be interesting to see how many required, base, standard, and
> optional packages meet the standard I propose.
>...

Since even glibc in testing will not be in your candidate list, I can 
predict that your result set will be very small since you have to ensure 
that all dependencies and build dependencies are fulfillable...


> Pat

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: Status of 'sarge' for the amd64 architecture

[Steve Langasek]

Hi Andreas,

On Fri, Apr 22, 2005 at 08:05:17PM +0200, Andreas Jochens wrote:

> I consider this a good way to split up responsibilities. 
> This way of handling things could serve as a good example of
> how other ports may be organized after sarge is released.

I certainly agree with that; unfortunately, history seems to suggest that
this method of organization tends to fall away once an architecture is
integrated into the archive. :)

> As a conclusion, I think that it may still be possible to release
> the amd64 port with sarge. Nothing in the current setup has to be 
> changed for that. It is just a matter of recognizing the current 
> state of affairs officially. 

> It will only be necessary to describe the current situation 
> in the official release documents and include pointers 
> to the separate amd64 archive, which will be provided 
> by the amd64 porting team anyway.

Have you discussed this with the security team, and have they agreed to
provide stable security support for amd64 in sync with the other
architectures?  Or have they agreed to coordinate with someone on the amd64
team for security support?  I don't think we can consider it an official
stable port without this key feature.

Cheers,
-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: Policy for devfs support

[Russell Coker]

On Friday 22 April 2005 21:28, Henrique de Moraes Holschuh <[EMAIL PROTECTED]> 
wrote:
> > SE Linux also has a list of device names for initially labelling a file
> > system.  Neither devfs nor devfs device names will work with SE Linux.
>
> That's fine.  But regular packages should not limit themselves like that
> IMHO.  That way, they will work under udev and static, with or without
> devfs, in either standard or devfs naming modes.  SE Linux has special
> needs, and that's quite easy to understand.

Every package has certain expectations about device node names.  Since devfs 
is now considered as a bad idea the naming scheme should be as well.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


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

Re: upload problems, public key not found

[Bartosz Fenski aka fEnIo]

On Fri, Apr 22, 2005 at 09:30:39PM +0200, Juergen Strobel wrote:

[...]

> I tried to upload an up to date version of this package today, but got
> denied again. I can't remember how I got the initial version in.
> 
> Questions:
> 
> 1. Where does Katie look for public keys?

In debian-keyring.

> 2. How can I get my key to such a place (it *is* on most public
> keyservers)?

You must be DD.

> 3. If I cannot get upload permission, does anyone else want to take
> over?

I don't want to take over it. Usually if someone is not a DD he/she has to
find sponsor for upload. That's what probably happened with your first
upload.

regards
fEnIo

-- 
  ,''`.  Bartosz Fenski | mailto:[EMAIL PROTECTED] | pgp:0x13fefc40 | irc:fEnIo
 : :' :   32-050 Skawina - Glowackiego 3/15 - w. malopolskie - Poland
 `. `'   phone:+48602383548 | proud Debian maintainer and user
   `-  http://skawina.eu.org | jid:[EMAIL PROTECTED] | rlu:172001


signature.asc
Description: Digital signature

upload problems, public key not found

[Juergen Strobel]

Hi,

I am the maintainer of kernel-patch-cryptoloop. I am not a DD, so my gpg
key is not on the debian keyring.

Almost noone uses kernel-patch-cryptoloop, so I let things slide. AFAIK,
sarge is to use a 2.6.x kernel, so this package is mostly useless.
However, a few people expressed interest recently, and added to the old
bug report #255953.

I tried to upload an up to date version of this package today, but got
denied again. I can't remember how I got the initial version in.

Questions:

1. Where does Katie look for public keys?
2. How can I get my key to such a place (it *is* on most public
keyservers)?
3. If I cannot get upload permission, does anyone else want to take
over?

Jürgen Strobel


- Forwarded message from Archive Administrator <[EMAIL PROTECTED]> -

To: [EMAIL PROTECTED]
Subject: Processing of kernel-patch-cryptoloop_2.4.22.0-30+1_i386.changes
From: Archive Administrator <[EMAIL PROTECTED]>
X-Spam-Status: No, score=-2.6 required=4.0 tests=BAYES_00 autolearn=ham 
version=3.0.2

PGP/GnuPG signature check failed on 
kernel-patch-cryptoloop_2.4.22.0-30+1_i386.changes
gpg: Signature made Fri Apr 22 09:25:27 2005 EDT using RSA key ID A211F5ED
gpg: Can't check signature: public key not found
(Exit status 2)
kernel-patch-cryptoloop_2.4.22.0-30+1_i386.changes has bad PGP/GnuPG signature!
Removing kernel-patch-cryptoloop_2.4.22.0-30+1_i386.changes, but keeping its 
associated files for now.

Greetings,

Your Debian queue daemon


- End forwarded message -

-- 
 The box said it requires Windows 95 or better so I installed Linux


signature.asc
Description: Digital signature

Re: Status of 'sarge' for the amd64 architecture

[Frederik Schueler]

Hello,

On Fri, Apr 22, 2005 at 08:05:17PM +0200, Andreas Jochens wrote:
> As a preparation for the amd64 porters irc meeting tomorrow, 
> I tried to build the complete Debian sarge archive for the 
> amd64 architecture from the unpatched Debian sarge sources.
> 
> The result was very encouraging. Almost all packages build now on 
> amd64 without problems using the pristine Debian sarge sources.
 
Thats great news, thanks for doing the proof of concept =)

> For some reason, the amd64 architecture has not been added to the 
> official Debian archive. There is a plan to change this when sarge is 
> released, but as I understand it, there is no plan to provide 
> amd64 binaries for sarge in the official Debian archive.

Really a sad thing, considering we already demanded addition to the
archive exactly a year ago in a couple of weeks. 


I look forward discussing the other topics on the meeting tomorrow :)

Kind regards
Frederik Schueler

-- 
ENOSIG


signature.asc
Description: Digital signature

Re: Policy for devfs support

[Henrique de Moraes Holschuh]

On Sat, 23 Apr 2005, Russell Coker wrote:
> On Friday 22 April 2005 21:28, Henrique de Moraes Holschuh <[EMAIL 
> PROTECTED]> 
> wrote:
> > > SE Linux also has a list of device names for initially labelling a file
> > > system.  Neither devfs nor devfs device names will work with SE Linux.
> >
> > That's fine.  But regular packages should not limit themselves like that
> > IMHO.  That way, they will work under udev and static, with or without
> > devfs, in either standard or devfs naming modes.  SE Linux has special
> > needs, and that's quite easy to understand.
> 
> Every package has certain expectations about device node names.  Since devfs 
> is now considered as a bad idea the naming scheme should be as well.

Why?  There is nothing wrong with the devfs naming scheme. Devfs *is* a bad
idea, but the naming scheme has nothing to do with the devfs shortcomings.

I may not like it very much, but quite a few people prefer it.

-- 
  "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: Temporal Release Strategy

[luna]

On Fri, 22 Apr 2005 13:58:31 -0400, Patrick Ouellette wrote:
> On Mon, Apr 18, 2005 at 04:24:34PM -0500, Adam M wrote:
>> In many ways, current testing is your stable. Extending the testing
>> period from testing to your proposed candidate and then stable would
>> do nothing about normal bugs. RC bugs are usually found quite quickly
>> by people using unstable.
> If RC bugs are found so quickly in unstable, why has there been no
> release in the last 3 or so years?  Testing is normally quite usable.
> That is part of the reason I believe this type of approach to releases
> would work.
Perhaps because RC bugs are not the only problem to resolve in order to 
release. Indeed, security build seems to be a biggest problem.

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

Re: Re: Packages with unusable documentation

[Alban Browaeys]

Le Fri, 22 Apr 2005 09:35:03 -0400, Dominic Amann a écrit :

>>
>>
>>On Sun, Apr 04, 2004 at 10:35:32AM +0200, Otto Wyss wrote:
>>> To solve my mkinitrd problem I searched for solutions. Each time someone
>>> has run into my problem he was asked if module-init-tools are installed
>>> and each time it was answered yes. Unfortunately also each time no
>>> further action is mentioned.
>>> 
>>> I looked into module-init-tools to find out what's doing. First I tried
>>> "man module-init-tools" which didn't work. Second I looked into
>>> "/usr/share/doc/module-init-tools" just to discover there is just
>>> useless common facts. Third I started dselect and read the package
>>> description which didn't help further.
>>
>>How about this simple pipe
>>
>>  dpkg -L PACKAGE | egrep '^/usr/share/(info|man)/'
>>
>>as a starting point?
>>
hum this is overkill. Install dwww (need an apache install) that s the
best we have in debian until now.

> Tragically, here I am in April 2005 with essentially the same problem,
> and the same shortage of information. I basically lucked into this
> discussion thread via google. I honestly can't see the viability of the
> replies given to Otto Wyss. There _is_ a documentation problem. Packages
> don't have an easy (end user) way to list what is in the package, or a
> standard for useful overview or mechanisms. To shout him down, and then
> to provide (admittedly useful, but certainly not end-user friendly) info
> is counter productive. Sure he came off a little as telling package
> maintainers what to do. Sure, his suggestion (which places him in the
> top 1% of complainers) does not fit in to the carefully considered
> packaging strategy being adhered to by you all.

the best service to look in packages i packages.debian.org . Or again
dwww.
 
> I have yet to find out, for example which files I need to fiddle with to
> fix my autoloading problem of certain modules. I need a debian specific
> overview of where to put my device specific 'aliases' and 'options',
> especially since some packages I am playing with are not debian
> friendly, or were designed for prior kernels/modutils. I am almost
> certain that this info exists somewhere. It is just not apparent where,
> and google is still a somewhat clumsy tool for this job.

The way to deal with modules configuration in debian is modconf. It is not
perfect but works with all kernels. 


 
> I _do_ appreciate the fine work done by mostly volunteer maintainers. I
> do understand that documentation gets short-shift in favour of
> functionality. However, Linux is (in my opinion) to the point where
> lacking documentation might be hindering adoption /more/ than lacking
> functionality. I therefore humbly suggest that in this case, MS has done
> some things right: by enlisting their ordinary users in usability tests,
> they have seriously re-engineered the way many things worked in windows.
> Now we all know there are still many ways windows falls far short. This
> is an opportunity. Linux enthusiasts /must/ listen to their struggling
> users if they have any desire for the wider adoption of linux.
> 

agree but developpers are not the only one who can write documentation
(and usually not the best at it )
I also ranted about the lack of a documentation team the way we have
translation team (which do wonders).
Documentation is my second concern so i would contribute to it but would
not give it the time to coordinate the work.
Please lead up to the task or look after someone for the job.

Grettings
Alban




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

Re: Status of 'sarge' for the amd64 architecture

[Andreas Jochens]

Hello Steve,

thank you for your reply to my status report.

Steve Langasek wrote:
> Andreas Jochens wrote:
>> It will only be necessary to describe the current situation 
>> in the official release documents and include pointers 
>> to the separate amd64 archive, which will be provided 
>> by the amd64 porting team anyway.
> 
> Have you discussed this with the security team, and have they agreed to
> provide stable security support for amd64 in sync with the other
> architectures?  Or have they agreed to coordinate with someone on the amd64
> team for security support?  I don't think we can consider it an official
> stable port without this key feature.

This is still an open issue, yes.

Security support for amd64 sarge will be one of the main topics for the
amd64 porters irc meeting today. An autobuilder has been prepared
which will build amd64 security updates for sarge as soon as the sources 
become available. However, as far as I know, this has not yet been
officially coordinated with the security team and I do not know the 
position of the security team on this. But I am confident that a
solution can be found for this issue. The amd64 is certainly willing
to do the necessary work.

Besides security support, do you have any other concerns which should 
be addressed to make a sarge release for the amd64 architecture 
possible? 

Regards
Andreas Jochens


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

Is Warren Turkal MIA?

[Michael Banck]

Hi,

did anybody see Warran Turkal (the current maintainer of dbs) lately?
He seems to be MIA WRT his NM-process and packaging work.  I tried to
reach him at <[EMAIL PROTECTED]> for a while now, but to no avail.
Does anybody know of a another/better address?


thanks,

Michael

-- 
Michael Banck
Debian Developer
[EMAIL PROTECTED]
http://www.advogato.org/person/mbanck/diary.html


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