Your in-home source of health information

[Mabel]

Achieving a strong erection in 15 minutes is easy as 1-2-3!
http://rjb.7ms0tqp0mz7fbqp.visional72d3.com



The only atheism is the denial of truth. 
There is never enough time, unless you're serving it.
Reality is a crutch for people who can't cope with drugs.  




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

Re: Problems with: Bug#295706: "Preferences" is empty

[Tollef Fog Heen]

* Michelle Konzack 

| The BUG, described by me, occures if you upgrade from WOODY to SARGE.

Could you please stop yelling at our releases?

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  


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

Re: Libraries with ABI changes

[Tollef Fog Heen]

* Hamish Moffatt 

| An advantage of keeping the old library in oldlibs for a while is that
| local admins may have their own binaries compiled against these
| libraries. Rapid replacements of libraries break local binaries.

Not as long as you bump the package name.  There's nothing pulling the
old library package off an admin's system so unless the admin removes
it himself the local binaries should work fine.

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  


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

Bug#311321: RFP: redet -- regular expression development and execution tool

[Bartosz Fenski aka fEnIo]

Package: wnpp
Severity: wishlist
Owner: Bartosz Fenski aka fEnIo <[EMAIL PROTECTED]>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: redet
  Version : 6.5
  Upstream Author : William J. Poser <[EMAIL PROTECTED]>
* URL : http://www.cis.upenn.edu/~wjposer/redet.html
* License : GPL
  Description : regular expression development and execution tool

Redet allows the user to construct regular expressions and test them
against input data by executing any of a variety of search programs,
editors, and programming languages that make use of regular expressions.
When a suitable regular expression has been constructed it may be saved to
a file. redet stands for Regular Expression Development and Execution Tool.
For each program, a palette showing the available regular expression syntax
is provided. Selections from the palette may be copied to the regular
expression window with a mouse click. Users may add their own definitions
to the palette via their initialization file. Redet also keeps a list of
the regular expressions executed, from which entries may be copied back
into the regular expression under construction. The history list is saved
to a file and restored on startup, so it persists across sessions. So long
as the underlying program supports Unicode, redet allows UTF-8 Unicode in
both test data and regular expressions.

Comparision with other similar tools:

 * Redet supports many programs. Most other regexp tools are aimed at
   a single language or style of regular expression.
 * Redet determines the properties of the programs that actually execute
   the regular expressions empirically. This guarantees that the version of
   the program you are using will actually behave as described. It also makes
   it likely that if new features are added to a program's regular expression
   repertoire, they will be detected and shown on the palette without any
   modification to the program.
 * Redet is explicitly designed for use in a variety of languages and
   writing systems. It provides the ability to change locale without exiting
   and reports whether Unicode support is available for each combination of
   program and locale. It provides special support for Unicode, such as lists
   of Unicode ranges and character properties. Redet itself is fully
   internationalized. By adding a suitable translation catalogue, buttons,
   labels, and messages may all be provided in any language.
 * Most regular expression tools are useful for constructing and
   understanding regular expressions but are not designed for use as search
   environments. Redet provides a number of facilities that make it a good
   search environment, including a relatively large, re-sizable text window,
   the ability to enter both regular expressions and data in various ways and
   to save them to files, editable, persistent history, and journalling.
 * Redet handles both matching and substitution. Most programs deal only
   with matching.
 * Redet allows the user to define named character classes and to
   intersect them.


- -- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.4.27-2-686
Locale: LANG=pl_PL, LC_CTYPE=pl_PL (charmap=ISO-8859-2)

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCnBLshQui3hP+/EARAnkUAKDNprseGrGeNATPicQxvNNnG3sGewCfUdQM
ZJlUrRXg/M72XnsBhtKuGNU=
=+8ki
-END PGP SIGNATURE-


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

Re: Problems with: Bug#295706: "Preferences" is empty

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> So Upgraders must move the old mozilla config manualy out of the way.
> Can this BUG solved ?

This happens very often. I think it is a Mozilla Bug to require too much
manuel intervention on upgrade. It is not related to releases (however more
likely between releases). I think we had something about this in the last
release notes and can put the same text in the upcoming.

If thats your only upgrade problem, we are really very very good:)

Bernd


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

Re: Dear Adrian Bunk, Please hold off a week or two

[Adrian Bunk]

On Mon, May 30, 2005 at 03:45:07PM -0400, Joey Hess wrote:
> Adrian Bunk wrote:
> > Or do you _really_ want to release sarge with many dozens of already 
> > known and fixed bugs?
> 
> I'd worry about it more if we hadn't suffered from the same or similar
> problems with ever previous Debian release, TBPH. Even back when we froze
> unstable, this just pushed certian bugfixes out of the archive entirely.
>...

How can this happen whenyou freeze unstable?

> see shy jo

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: Dear Adrian Bunk, Please hold off a week or two

[Adrian Bunk]

On Tue, May 31, 2005 at 04:07:11PM +1200, Nigel Jones wrote:

> I noticed that Adrian moved a bug report for a kernel in sid (2.6.10
> IIRC) to the 2.6.8 kernel so it appeared as a Sarge RC Bug?  I didn't
> see anything that showed that it was a 2.6.8 problem, maybe it is, but
> it looked like second guessing to me...

The important part of the bug log is the following by one of the Debian 
kernel maintainers:
  well reiserfs doesn't work well with preempt,
  could you please try the 2.6.11 kernel-iamge.
  there preempt is disabled afair.

PREEMPT is enabled in both the 2.6.8 and the 2.6.10 kernel images but no 
longer in the 2.6.11 kernel images.

It might look like second guessing, but if ReiserFS has problems with 
PREEMPT in 2.6.10, the probability that this is also present in 2.6.8 is 
quite high.

> How is this helping Sarge?  If it turns out that it does affect part
> of Sarge then isn't there a means provided to upload the new .deb
> files after release?

The main question is not when and how to fix such an issue.

The problem is that the release team's scripts to measure their RC bugs 
metric can't handle pseudo-packages correctly.

Steve has already acknowledged this limitation (and AFAIK it has yet 
to be fixed).

Therefore my reassigning was required to get this bug on the radar of 
the release team.

> Bug in question is #303200, also it seems it was downgraded to a
> non-RC bug, so now doesn't that mean that it is now filed in wrong
> places?
>...

The most important thing seems to be the added "moreinfo" tag.

The maintainer know better about such issues than I do.

I do not claim to have been able to reproduce this problem, all I claim 
is that if it's a problem (IOW: not a local hardware problem of the 
submitter) it's most likely also present in kernel 2.6.8.

And my reassigning was requred to get it on the radar of the release 
team.

> N Jones

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: Example where testing-security was used?

[Adrian Bunk]

On Mon, May 30, 2005 at 10:56:16PM +0200, Marc 'HE' Brockschmidt wrote:
> Hamish Moffatt <[EMAIL PROTECTED]> writes:
> > On Mon, May 30, 2005 at 11:48:54AM +0100, Mark Brown wrote:
> >> On Mon, May 30, 2005 at 12:34:21PM +0200, Adrian Bunk wrote:
> >>> But setting up autobuilders doesn't require a new infrastructure
> >>> (and shouldn't require more than half a year).
> >>> Wasn't the infrastructure a prerequisite for woody and is working?
> >> It turned out that the central part of the existing infrastructure
> >> didn't scale up well enough to cope with the new architectures in sarge.
> > There are no new architectures in sarge.
> 
> That's right, but the buildd network has to work for both oldstable and
> stable. potato + woody didn't need as many buildds as woody + sarge
> will need.

17 -> 22 architectures is an increase, but doesn't look like a very 
serious one.

> Marc

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: Dear Adrian Bunk, Please hold off a week or two

[Santiago Vila]

On Tue, 31 May 2005, Adrian Bunk wrote:

> On Mon, May 30, 2005 at 03:45:07PM -0400, Joey Hess wrote:
> > Adrian Bunk wrote:
> > > Or do you _really_ want to release sarge with many dozens of already 
> > > known and fixed bugs?
> > 
> > I'd worry about it more if we hadn't suffered from the same or similar
> > problems with ever previous Debian release, TBPH. Even back when we froze
> > unstable, this just pushed certian bugfixes out of the archive entirely.
> >...
> 
> How can this happen whenyou freeze unstable?

I guess you will not understand at each other if you use the term
"freezing unstable" with two different meanings. I see that the term
may have at least two meanings:

* "frozen" is created initially as a copy of unstable. After this,
frozen and unstable evolve separately, unless you upload some package
for "frozen unstable", as we did in the old days. I bet Adrian would
not call this a proper freeze of unstable, as it would be the "frozen"
distribution who would be really frozen, not unstable.

* "unstable" is actually frozen, which means uploads for unstable
are either discouraged, they remain in the limbo, or they are automatically
put in some other distribution above unstable, like new-unstable, until
testing or unstable becomes the new stable.


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

Bug#311332: ITP: gofax -- Fax solution based on hylafax and LDAP

[scheiter]

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


* Package name: gofax
  Version : 1.4 
  Upstream Author : Lars Scheiter <[EMAIL PROTECTED]>
* URL : http://oss.gonicus.de/project/?group_id=2 
* License : GPL
  Description : Fax solution based on hylafax and LDAP

GOfax is an extendable fax solution based on hylafax. It
provides pluggable facilities to store user account data,
preferred in LDAP directories.

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.4.30
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)


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

Bug#311333: ITP: gopdc -- Helper Scripts to build up an Samba DC

[scheiter]

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


* Package name: gopdc
  Version : 1.0.0
  Upstream Author : Lars Scheiter <[EMAIL PROTECTED]>
* URL : http://oss.gonicus.de/project/?group_id=8 
* License : GPL
  Description : Helper Scripts to build up an Samba DC

GOpdc Scripts may be used to build up an Samba DC, which will
help you to build up a fully integrated Domain Controller.
In combination with GOsa and Samba these scripts make a nearly NT4 style
complete Domain Controller posssible. GOpdc is in most cases similar
to the smbldap-tools but written in PHP for the ease of use.
Configuration is managed via an xml file.

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.4.30
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)


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

Re: Dear Adrian Bunk, Please hold off a week or two

[Thijs Kinkhorst]

On Tue, May 31, 2005 03:43, Miles Bader wrote:
> Bernd Eckenfels <[EMAIL PROTECTED]> writes:
>> Actually I am glad somebody is working public visible on the release
>> issues and would not critisize him for that.
>
> Pointing out a problem is nice, but doing so in an obnoxious manner
> hurts.

I would like to add: pointing out a problem is easy, providing good
solutions is a lot harder. Continuously pointing out problems ("the metric
is wrong", "testing is bad") is destructive critisism, while what we
really need is constructive thinking about the issues for etch, after the
release. In the vast majority of his mails I see mr Bunk only hammering on
perceived problems. Very tiring.


Thijs


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

Re: Release update: minor delay; no non-RC fixes; upgrade reports

[Steve Langasek]

On Mon, May 30, 2005 at 12:59:26PM +0200, Adrian Bunk wrote:
> Since it seems noone of the release team bothered to pay this part of 
> the price for the testing release process, I'm sometimes using one or 
> two spare hours to go a bit through update_excuses and report half a 
> dozen of such issues.

> Steve saw this, and before the latest release update he sent (which was 
> the one before yours), he asked me in a private mail about a prediction 
> how many such RC bugs I'd expect in sarge for inclusion in his release 
> update.

> It seems my prediction about the number of such issues didn't match his 
> wishes regarding the state of sarge, and he did therefore neither answer 
> my email nor mention this in the release update nor does it seem he 
> assigned a member of the release team to do this work properly.

On the contrary, I found your answer reasonably satisfactory, and as a
result had postponed replying to you in favor of dealing with more directly
pressing release issues.

You indicated that as of two weeks ago, you'd been through the "middle
seventh" of update_excuses checking for unidentified RC bugs, and that most
of the packages below this range were not in testing and therefore wouldn't
hold many hidden RC bugs; and I've been tracking the status of RC bugs
closed since the freeze began, which accounts for many (though not all) of
the more recent uploads.

So it is probably true that sarge will release with some RC bugs that could
have easily been fixed had we known about them, but I don't think this
number will be so great that we want to redirect resources or delay the
release in order to try to catch them.  I don't think it's realistic to
charge the release team with identifying all RC bugs in the distribution,
only to take care that we don't release with them once they are so
identified.

> [1] And no, version tracking in the BTS wouldn't prevent this problem.
> In my experience, there are so many of these issues reported with
> a wrong version or manually closed or even without any bug report in 
> the BTS that claiming version tracking might eliminate this problem 
> sounds like a bad joke.

 The problems you describe are not ones that would go away with the
removal of testing; if maintainers are not engaged in the process of
ensuring their packages are free of RC bugs for release, and do not take
care that RC bugs are a) documented in the BTS, b) filed at the correct
severity, and c) fixed in the version of the package that's releasing (in
case something goes wrong with a and b), we are going to miss RC bugs that
could have been caught.  This is a social problem, not a technical one, and
I don't think there are any viable technical solutions.

For my part, I have explicitly *not* given a free pass to packages with RC
bugs that were filed a long time ago but only recently raised to their
proper severity.  It's great if bug submitters know what severity a bug
should be filed at, but it's the *responsibility* of the maintainer to
adjust the severity if it's wrong -- even if that means raising the
severity, something none of us want to do.  Even more, it's the maintainer's
responsibility to *deal with* such bugs at the proper severity even if they
were filed wrong.  It simply can't be the responsibility of any central
group to babysit the severities of bugs filed: that's not scalable in the
least.

So yes, sarge will ship with bugs that should have been considered RC.  But
this is inevitable in any case because of the many RC bugs that are never
*identified* by our testing, so there's no reason for the release team to
treat these bugs as blocking issues if no one cares enough to make sure
they're brought to our attention.  This doesn't mean that your work to
identify overlooked RC bugs is any less valuable, Adrian, or that I'm any
less grateful to you for it (in spite of the visceral irritation sometimes
at seeing the bug count moving in the wrong direction ;).  It just means
having a pragmatic, big-picture view of what it means to release, and
whether the improvement to sarge is worth it to our users every time we
delay another week to fix a handful of bugs.  After all, let's not forget
that sarge is already quite good, and nothing to be ashamed of!

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: Example where testing-security was used?

[Steve Langasek]

On Tue, May 31, 2005 at 11:25:39AM +0200, Adrian Bunk wrote:
> On Mon, May 30, 2005 at 10:56:16PM +0200, Marc 'HE' Brockschmidt wrote:
> > Hamish Moffatt <[EMAIL PROTECTED]> writes:
> > > On Mon, May 30, 2005 at 11:48:54AM +0100, Mark Brown wrote:
> > >> On Mon, May 30, 2005 at 12:34:21PM +0200, Adrian Bunk wrote:
> > >>> But setting up autobuilders doesn't require a new infrastructure
> > >>> (and shouldn't require more than half a year).
> > >>> Wasn't the infrastructure a prerequisite for woody and is working?
> > >> It turned out that the central part of the existing infrastructure
> > >> didn't scale up well enough to cope with the new architectures in sarge.
> > > There are no new architectures in sarge.

> > That's right, but the buildd network has to work for both oldstable and
> > stable. potato + woody didn't need as many buildds as woody + sarge
> > will need.

> 17 -> 22 architectures is an increase, but doesn't look like a very 
> serious one.

There were never security autobuilders for potato; and security and
proposed-updates are separate queues.  So in terms of centralized load on
the wanna-build server, this is a jump from 22 (11 stable-security + 11
proposed-updates) to 33 (11 oldstable-security + 11 stable-security + 11
proposed-updates; AFAIK there is no oldstable-proposed-updates).

If testing-security is brought on-line again for etch within the year
following sarge's release (as I certainly hope it will), the peak number of
wanna-build *databases* being served by ftp-master.d.o (saying nothing of
the number of actual buildd connections) would be 66 (oldstable-security +
stable-security + proposed-updates + testing-proposed-updates +
testing-security + unstable, x 11 archs -- not counting prospective archs).
The greatest number newraff has ever really been asked to handle at any one
time up to this point has been 55 (the number we have currently), which was
only done *after* newraff's scalability problems were addressed; prior to
that, AFAIK there were only ever as many as 44 databases actively used (p-u
+ s-s + t-p-u + u, from the release of woody w/ security autobuilder support
up until this spring).

So at 44 the server was already at its limit, the release required a 25%
increase in the number of databases (and roughly the same increase in the
number of connections), and etch would have brought us up to 50% over that
limit.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: Example where testing-security was used?

[Adrian Bunk]

On Tue, May 31, 2005 at 04:56:52AM -0700, Steve Langasek wrote:
> On Tue, May 31, 2005 at 11:25:39AM +0200, Adrian Bunk wrote:
> > On Mon, May 30, 2005 at 10:56:16PM +0200, Marc 'HE' Brockschmidt wrote:
> > > Hamish Moffatt <[EMAIL PROTECTED]> writes:
> > > > On Mon, May 30, 2005 at 11:48:54AM +0100, Mark Brown wrote:
> > > >> On Mon, May 30, 2005 at 12:34:21PM +0200, Adrian Bunk wrote:
> > > >>> But setting up autobuilders doesn't require a new infrastructure
> > > >>> (and shouldn't require more than half a year).
> > > >>> Wasn't the infrastructure a prerequisite for woody and is working?
> > > >> It turned out that the central part of the existing infrastructure
> > > >> didn't scale up well enough to cope with the new architectures in 
> > > >> sarge.
> > > > There are no new architectures in sarge.
> 
> > > That's right, but the buildd network has to work for both oldstable and
> > > stable. potato + woody didn't need as many buildds as woody + sarge
> > > will need.
> 
> > 17 -> 22 architectures is an increase, but doesn't look like a very 
> > serious one.
> 
> There were never security autobuilders for potato; and security and
> proposed-updates are separate queues.  So in terms of centralized load on
> the wanna-build server, this is a jump from 22 (11 stable-security + 11
> proposed-updates) to 33 (11 oldstable-security + 11 stable-security + 11
> proposed-updates; AFAIK there is no oldstable-proposed-updates).
> 
> If testing-security is brought on-line again for etch within the year
> following sarge's release (as I certainly hope it will), the peak number of
> wanna-build *databases* being served by ftp-master.d.o (saying nothing of
> the number of actual buildd connections) would be 66 (oldstable-security +
> stable-security + proposed-updates + testing-proposed-updates +
> testing-security + unstable, x 11 archs -- not counting prospective archs).
>...
> So at 44 the server was already at its limit, the release required a 25%
> increase in the number of databases (and roughly the same increase in the
> number of connections), and etch would have brought us up to 50% over that
> limit.

I'm glad to hear that you do no longer plan to drop architectures from 
etch.  :-)

> Steve Langasek

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: New Nokia device is Debian-based?

[Bastian Blank]

On Fri, May 27, 2005 at 11:23:14AM +0400, Nikita V. Youshchenko wrote:
> The open source software component of the Nokia 770 can be downloaded from
> Maemo.org as a complete filesystem, or managed as a collection of Debian
> source and binary packages.

Yep, and many of the packages match the Debian versions an half year
ago.

Bastian

-- 
You're too beautiful to ignore.  Too much woman.
-- Kirk to Yeoman Rand, "The Enemy Within", stardate unknown


signature.asc
Description: Digital signature

Re: Example where testing-security was used?

[Steve Langasek]

On Tue, May 31, 2005 at 02:01:48PM +0200, Adrian Bunk wrote:
> On Tue, May 31, 2005 at 04:56:52AM -0700, Steve Langasek wrote:
> > On Tue, May 31, 2005 at 11:25:39AM +0200, Adrian Bunk wrote:
> > > On Mon, May 30, 2005 at 10:56:16PM +0200, Marc 'HE' Brockschmidt wrote:
> > > > Hamish Moffatt <[EMAIL PROTECTED]> writes:
> > > > > On Mon, May 30, 2005 at 11:48:54AM +0100, Mark Brown wrote:
> > > > >> On Mon, May 30, 2005 at 12:34:21PM +0200, Adrian Bunk wrote:
> > > > >>> But setting up autobuilders doesn't require a new infrastructure
> > > > >>> (and shouldn't require more than half a year).
> > > > >>> Wasn't the infrastructure a prerequisite for woody and is working?
> > > > >> It turned out that the central part of the existing infrastructure
> > > > >> didn't scale up well enough to cope with the new architectures in 
> > > > >> sarge.
> > > > > There are no new architectures in sarge.

> > > > That's right, but the buildd network has to work for both oldstable and
> > > > stable. potato + woody didn't need as many buildds as woody + sarge
> > > > will need.

> > > 17 -> 22 architectures is an increase, but doesn't look like a very 
> > > serious one.

> > There were never security autobuilders for potato; and security and
> > proposed-updates are separate queues.  So in terms of centralized load on
> > the wanna-build server, this is a jump from 22 (11 stable-security + 11
> > proposed-updates) to 33 (11 oldstable-security + 11 stable-security + 11
> > proposed-updates; AFAIK there is no oldstable-proposed-updates).

> > If testing-security is brought on-line again for etch within the year
> > following sarge's release (as I certainly hope it will), the peak number of
> > wanna-build *databases* being served by ftp-master.d.o (saying nothing of
> > the number of actual buildd connections) would be 66 (oldstable-security +
> > stable-security + proposed-updates + testing-proposed-updates +
> > testing-security + unstable, x 11 archs -- not counting prospective archs).
> >...
> > So at 44 the server was already at its limit, the release required a 25%
> > increase in the number of databases (and roughly the same increase in the
> > number of connections), and etch would have brought us up to 50% over that
> > limit.

> I'm glad to hear that you do no longer plan to drop architectures from 
> etch.  :-)

I no longer have any illusions that we'll be able to persuade the project
that this is in Debian's best interest, or that we'll find an alternate
solution that's acceptable to the porters of the architectures in question.

In any case, given the number of prospective ports waiting in the wings, 11
is probably a roughly correct estimate even if we *do* drop some
architectures.  (And since non-release ports are likely to stay in unstable,
and adding a release port adds three w-b databases where dropping one only
removes two w-b databases, it takes 1 1/2 dropped archs to balance one added
arch...)

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: Example where testing-security was used?

[Pierre Habouzit]

> In any case, given the number of prospective ports waiting in the
> wings, 11 is probably a roughly correct estimate even if we *do* drop
> some architectures.  (And since non-release ports are likely to stay
> in unstable, and adding a release port adds three w-b databases where
> dropping one only removes two w-b databases, it takes 1 1/2 dropped
> archs to balance one added arch...)

in all those debates about the lack of buildds, sth seems odd to me. 
I've always thought that moore's law was quite accurate... and my 
understanding (I may be wrong, it's only how I understand the whole 
thing) is that debian growth is quite linear, compared to the cpu 
speed, disk size, BW ... growth, the time passing, we should have less 
and less limitations.

I'm aware that more's law is not appliable on some archs (like arm I 
believe) but the question is, well, who uses openoffice.org or kde on 
an arm (only to cite those) ?

In fact, the point is, I don't understand how hardware limitations are 
really possible. I understand fully that many ports needs *a lot* of 
work for porters/security teams (it's a pity human brains does not 
follow moore's law) ... but I find hard to believe that hardware is the 
reason why we cannot manage many arches.

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpdaVPkl87ui.pgp
Description: PGP signature

Bug#311348: ITP: ptunnel -- Send TCP traffic over ICMP

[Romain Beauxis]

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


* Package name: ptunnel
  Version : 0.61
  Upstream Author : Daniel Stoedle <[EMAIL PROTECTED]>
* URL : http://www.cs.uit.no/~daniels/PingTunnel/
* License : BSD like
  Description : Send TCP traffic over ICMP

Ptunnel is an application that allows you to reliably tunnel TCP
connections to a remote host using ICMP echo request and reply packets,
commonly known as ping requests and replies. 


-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.11.8-romidaboss
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: Example where testing-security was used?

[Steve Langasek]

On Tue, May 31, 2005 at 03:08:09PM +0200, Pierre Habouzit wrote:
> > In any case, given the number of prospective ports waiting in the
> > wings, 11 is probably a roughly correct estimate even if we *do* drop
> > some architectures.  (And since non-release ports are likely to stay
> > in unstable, and adding a release port adds three w-b databases where
> > dropping one only removes two w-b databases, it takes 1 1/2 dropped
> > archs to balance one added arch...)

> in all those debates about the lack of buildds, sth seems odd to me. 
> I've always thought that moore's law was quite accurate... and my 
> understanding (I may be wrong, it's only how I understand the whole 
> thing) is that debian growth is quite linear, compared to the cpu 
> speed, disk size, BW ... growth, the time passing, we should have less 
> and less limitations.

Moore's Law governs the rate at which the speed of hardware (at a given
price-point) doubles.  It says nothing about the speed at which current
software will *run* on current machines; and it certainly has nothing to say
about the speed at which such software will run on machines that are no
longer on the Moore's Law curve due to a lack of new hardware being
designed/manufactured for that architecture.

IOW, it doesn't (directly) give meaningful predictions about the rate at
which a given piece of hardware becomes obsolete.

It also has no capacity to predict an organization's *ability* to replace
hardware.

> I'm aware that more's law is not appliable on some archs (like arm I 
> believe) but the question is, well, who uses openoffice.org or kde on 
> an arm (only to cite those) ?

This mitigates the linear growth of the archive itself (assuming we did
subset the archive for slower archs), but it doesn't mitigate the growth of
software complexity that causes subsequent revisions of the same software to
run slower on the same hardware over time -- which, if it's true of nothing
else, is at least true of compilers.

> In fact, the point is, I don't understand how hardware limitations are 
> really possible. I understand fully that many ports needs *a lot* of 
> work for porters/security teams (it's a pity human brains does not 
> follow moore's law) ... but I find hard to believe that hardware is the 
> reason why we cannot manage many arches.

I don't remember anyone ever saying this was a hardware problem.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: Example where testing-security was used?

[Romain Francoise]

Steve Langasek <[EMAIL PROTECTED]> writes:

> In any case, given the number of prospective ports waiting in the
> wings, 11 is probably a roughly correct estimate even if we *do* drop
> some architectures.

Speaking of prospective ports, what would be the feasibility of keeping
testing frozen after sarge releases, do whatever toolchain updates are
needed to support amd64 via t-p-u, and release etch as a "sarge+amd64"
release in, say, 3 months?

The rationale is that amd64 would be immediately useful whereas other
architectures like s390x or whatever other port we plan to support can
probably wait the 2+ years before the next release...

(I don't know if it's possible to add an architecture without having all
binaries go through unstable first so the idea is probably doomed, but
it certainly appeals.)

-- 
  ,''`.
 : :' :Romain Francoise <[EMAIL PROTECTED]>
 `. `' http://people.debian.org/~rfrancoise/
   `-


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

Re: Example where testing-security was used?

[Pierre Habouzit]

> IOW, it doesn't (directly) give meaningful predictions about the rate
> at which a given piece of hardware becomes obsolete.
>
> It also has no capacity to predict an organization's *ability* to
> replace hardware.

ok, true

> > I'm aware that more's law is not appliable on some archs (like arm
> > I believe) but the question is, well, who uses openoffice.org or
> > kde on an arm (only to cite those) ?
>
> This mitigates the linear growth of the archive itself (assuming we
> did subset the archive for slower archs), but it doesn't mitigate the
> growth of software complexity that causes subsequent revisions of the
> same software to run slower on the same hardware over time -- which,
> if it's true of nothing else, is at least true of compilers.

hmmm, if you don't give such monsters like openoffice or any big c++ 
application to build on slow/rare arches, I guess that will ease the 
autobuilders a lot too, not only the archive.

maybe the solution is to write a [EMAIL PROTECTED] (like [EMAIL PROTECTED] or 
[EMAIL PROTECTED] does) in order to ease the autobuilders :D (kidding of 
course)

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpQCOiqDjrqK.pgp
Description: PGP signature

Re: Dear Adrian Bunk, Please hold off a week or two

[Steve Langasek]

On Tue, May 31, 2005 at 11:22:20AM +0200, Adrian Bunk wrote:
> > I noticed that Adrian moved a bug report for a kernel in sid (2.6.10
> > IIRC) to the 2.6.8 kernel so it appeared as a Sarge RC Bug?  I didn't
> > see anything that showed that it was a 2.6.8 problem, maybe it is, but
> > it looked like second guessing to me...

> The important part of the bug log is the following by one of the Debian 
> kernel maintainers:
>   well reiserfs doesn't work well with preempt,
>   could you please try the 2.6.11 kernel-iamge.
>   there preempt is disabled afair.

> PREEMPT is enabled in both the 2.6.8 and the 2.6.10 kernel images but no 
> longer in the 2.6.11 kernel images.

> It might look like second guessing, but if ReiserFS has problems with 
> PREEMPT in 2.6.10, the probability that this is also present in 2.6.8 is 
> quite high.

> > How is this helping Sarge?  If it turns out that it does affect part
> > of Sarge then isn't there a means provided to upload the new .deb
> > files after release?

> The main question is not when and how to fix such an issue.

> The problem is that the release team's scripts to measure their RC bugs 
> metric can't handle pseudo-packages correctly.

> Steve has already acknowledged this limitation (and AFAIK it has yet 
> to be fixed).

> Therefore my reassigning was required to get this bug on the radar of 
> the release team.

Actually, I've started using

 lynx -width=160 -dump http://bugs.debian.org/release-critical/other/all.html \
 | grep -v '\[[EUS]*X*\]\|I\]\|\[TX\]' | grep -B3 '\[\]'

as a means of tracking the status of sarge-affecting RC bugs according to
bugs.debian.org.

The diff between this and bts.turmzimmer.net includes two bugs against
packages that are only in non-US; two bugs against installation-reports
which most likely need to be downgraded; one upgrade-reports bug which is
probably unreproducible; one bug on 'kernel' that is probably sarge-ignore
but I haven't looked at it in any detail yet; one unreproducible bug against
"general" which is probably a fixed bug in an old package; and one RC bug
against ftp.debian.org asking for d-i udeb packages to be synced for the
release (95% resolved as far as the release is concerned, current overall
status seen at ).

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Keysigning without physically meeting ... thoughts?

[Wesley J. Landaker]

Hi folks,

I wrote this up to someone. I thought I'd share it, and get your thoughts.
(e.g. anybody see any weaknesses in #1-#3 that *aren't* present in the 
typical meet, check ID, get GPG fingerprint, assuming #4 is always used 
afterwards?)

On Tuesday 31 May 2005 08:44, Wesley J. Landaker wrote:
> For instance, I don't know if this is officially acceptable or not, but I
> would probably be willing to sign someone's key even if I hadn't met them
> in person, if I got in the mail:
>
>   1) A picture of them holding a recent newspaper with their GPG
> fingerprint and signature written on it. (This would relate the person's
> face & signature with their GPG key, and verify that it's recent).
>  
>   2) A copy of an acceptable (probably government-issued, non-expired)
> picture ID. (This would relate the person's face with their "government"
> identity).
>
>   3) A signed, dated, and notarized statement saying something to the
> effect of "My name is __, my active e-mail that I control is
> [EMAIL PROTECTED], and the GPG fingerprint of my active key that I
> control and is not compromised is __. Attached to
> this statement is a picture of me with a newspaper dated ___ with the
> same GPG fingerprint, and a copy of my ___ photo ID, which I have
> shown to the undersigned notary. Signed __, notarized by
> ___." (Relates the date (which should be reasonably close to the
> time when the picture in #1 was taken--a few weeks at the most), their
> name, e-mail, and GPG fingerprint together by the statement, and the
> picture from #1, and with their "government" identity, as that is checked
> by the notary).
>
>   4) I'd sign the key, and send the updated key to the e-mail address
> given, signed by the GPG key with the fingerprint given. (Relates the
> e-mail address with the GPG key, as if they can't get the e-mail or
> decrypt the e-mail to get the signature, it effectively hasn't really
> been signed).

-- 
Wesley J. Landaker <[EMAIL PROTECTED]>
OpenPGP FP: 4135 2A3B 4726 ACC5 9094  0097 F0A9 8A4C 4CD6 E3D2


pgpTmKyVwiLKk.pgp
Description: PGP signature

Bug#311371: ITP: elektra -- A framework to store configuration atoms hierarchically

[Simon Law]

Package: wnpp
Version: N/A; reported 2005-05-31
Severity: wishlist

* Package name: elektra
  Version : 0.5
  Upstream Author : Avi Alkalay <[EMAIL PROTECTED]>
* URL : http://elektra.sourceforge.net/
* License : BSD
  Description : A framework to store configuration atoms hierarchically

Elektra provides a universal and secure framework to store configuration
parameters in a hierarchical key-value pair mechanism, instead of each
program using its own text configuration files. This allows any program
to read and save its configuration with a consistent API, and allows
them to be aware of other applications' configurations, permitting easy
application integration. While architecturally similar to other OS
registries, Elektra does not have most of the problems found in those
implementations.

-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux alps 2.4.18-1-686 #1 Wed Apr 14 18:20:10 UTC 2004 i686
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8


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

Bug#311373: ITP: wifi-radar -- GUI utility for managing WiFi profiles

[Stephen Birch]

Package: wnpp
Severity: wishlist
Owner: Stephen Birch <[EMAIL PROTECTED]>

* Package name: wifi-radar
  Version : 1.9.3
  Upstream Author : [EMAIL PROTECTED]
* URL : http://www.bitbuilder.com/wifi_radar/
* License : GPL
  Description : GUI utility for managing WiFi profiles

WiFi Radar is a Python/PyGTK2 utility for managing WiFi profiles.  It
enables you to scan for available networks and create profiles for
your preferred networks. At boot time, running WiFi Radar will
automatically scan for an available preferred network and connect to
it. You can drag and drop your preferred networks to arrange the
profile priority.

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: All
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)


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

Is Ubuntu a debian derivative or is it a fork?

[Stephen Birch]

Forgive me if this has already been discussed ... if so could someone
give me a pointer to the thread.

I find myself fairly confused about Ubuntu packages.  I had thought
that Ubuntu is a Debian derivative.  Therefore I expected new
packages to be first placed in Debian and then flow to Ubuntu.

However, I recently found this page:

https://www.ubuntulinux.org/wiki/MOTUNewPackages

The project seems to have established a mechanism for putting new
packeges directly into Ubuntu.  Are new Ubuntu packages also put in
Debian by the Ubuntu team members?

The Ubuntu literature indicates that Ubuntu is a derivative of debian
but it looks more like a fork to me.

Also, when Ubuntu makes improvements to packages how do those
improvements flow back to Debian?

Steve



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

Re: Is Ubuntu a debian derivative or is it a fork?

[Tollef Fog Heen]

* Stephen Birch 

| The project seems to have established a mechanism for putting new
| packeges directly into Ubuntu.  Are new Ubuntu packages also put in
| Debian by the Ubuntu team members?

Yes.

| The Ubuntu literature indicates that Ubuntu is a derivative of debian
| but it looks more like a fork to me.

It's a spoon.

| Also, when Ubuntu makes improvements to packages how do those
| improvements flow back to Debian?

Patches to bugs, debian maintainers picking up the patches from the
patch repository, inter-team communication.  It depends.

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  


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

subscribe

[Enrique Ocaña González]

-- 
Enrique Ocaña González
Ingeniero en Informática 
mailto:[EMAIL PROTECTED]
Igalia S.L. http://www.igalia.com


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

Re: Example where testing-security was used?

[Adam Heath]

On Tue, 31 May 2005, Steve Langasek wrote:

> Moore's Law governs the rate at which the speed of hardware (at a given
> price-point) doubles.  It says nothing about the speed at which current
> software will *run* on current machines; and it certainly has nothing to say
> about the speed at which such software will run on machines that are no
> longer on the Moore's Law curve due to a lack of new hardware being
> designed/manufactured for that architecture.

Actually, doesn't Moore's Law mean the average for all new silicon?  So, some
cutting-edge new hardware may evolve faster than the average.


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

Re: Is Ubuntu a debian derivative or is it a fork?

[Stephen Birch]

Tollef Fog Heen([EMAIL PROTECTED])@2005-05-31 18:06:
> * Stephen Birch 
> 
> | The project seems to have established a mechanism for putting new
> | packeges directly into Ubuntu.  Are new Ubuntu packages also put in
> | Debian by the Ubuntu team members?
> 
> Yes.

Let me give you an example.  I filed an ITP this morning on a
promising package called wifi-radar.

After writing the ITP I discovered someone has already built a deb for
Ubuntu and placed it on the Ubuntu wiki.  But they did not file an
ITP.

Normal debian etiquette identifies the maintainer of a new package as
the first person to file an ITP.  So how is this coordinated with
Ubuntu?

Unless I missed the ITP and filed a double by mistake we appear to
have two independent wifi-radar maintainers now. The Ubuntu one and
the debian one. In this instance there isnt an issue, I just want to
see the software packaged and I'll happily yeald to the other
maintainer if he/she wants.  But I can see the possibility of a
conflict in future when this happens with other packages.

> | The Ubuntu literature indicates that Ubuntu is a derivative of debian
> | but it looks more like a fork to me.
> 
> It's a spoon.

And a very good looking spoon indeed.  I like Ubuntu and am switching
my customer base over to it from Debian.

But I sure want to see good coordination between Ubuntu and Debian.

> 
> | Also, when Ubuntu makes improvements to packages how do those
> | improvements flow back to Debian?
> 
> Patches to bugs, debian maintainers picking up the patches from the
> patch repository, inter-team communication.  It depends.

Still looks more like a fork than a derivative . or a spoon :-)

Steve


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

proficiency-level tag for debian packages

[Mark Edgington]

Pardon me if this has already been discussed, but I wonder if there 
should be a tag in debian packages indicating the a minimum proficiency 
level that a user should have in order for a package to be useful to the 
user.


For example, a package like OpenOffice or Firefox are end-user 
applications which most users (even those completely unfamiliar with 
linux) would have a good chance at understanding and being able to use. 
 On the other hand, a package like nmap might not be something my 
Grandma would be wanting to use every day, and thus it might be better 
to have a higher proficiency-level rating for such a package.


The motivation for such a thing is that it would make it possible for 
package-management tools to operate in an "easy" mode which would only 
display (or display in a separate category) packages which have a 
proficiency-rating < x.  This would be very handy in that it would 
permit using Debian and an apt frontend like synaptic to make it easy 
for more-or-less "computer-illiterate" people to install new packages 
which match their skill-level, without having to wade through hundreds 
of libraries and technical tools which they would never use.


Perhaps there's a better way to accomplish this, but the ability to 
limit the display of packages in this manner is something that it seems 
would be beneficial to have.


-Mark


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

Re: proficiency-level tag for debian packages

[Cesar Martinez Izquierdo]

El Martes 31 Mayo 2005 19:41, Mark Edgington escribió:
> Pardon me if this has already been discussed, but I wonder if there
> should be a tag in debian packages indicating the a minimum proficiency
> level that a user should have in order for a package to be useful to the
> user.
>
> For example, a package like OpenOffice or Firefox are end-user
> applications which most users (even those completely unfamiliar with
> linux) would have a good chance at understanding and being able to use.
>   On the other hand, a package like nmap might not be something my
> Grandma would be wanting to use every day, and thus it might be better
> to have a higher proficiency-level rating for such a package.
>
> The motivation for such a thing is that it would make it possible for
> package-management tools to operate in an "easy" mode which would only
> display (or display in a separate category) packages which have a
> proficiency-rating < x.  This would be very handy in that it would
> permit using Debian and an apt frontend like synaptic to make it easy
> for more-or-less "computer-illiterate" people to install new packages
> which match their skill-level, without having to wade th
> rough hundreds 
> of libraries and technical tools which they would never use.
>
> Perhaps there's a better way to accomplish this, but the ability to
> limit the display of packages in this manner is something that it seems
> would be beneficial to have.
>
> -Mark

I find it a quite interesting idea. If it was implemented, there should be an 
scale, so that maintainers have some reference in order to tag their 
packages.

Something similar to:
Firefox, OpenOffice, koffice, gxine - 100
Thunderbird, Kmail, Evolution - 95
Dia, Inkscape, Gimp,  - 90
konsole, gnome-terminal - 50
Libraries - 0

Of course, such scale should be further discussed and studied than my 
fast-done one...

  Cesar

Re: proficiency-level tag for debian packages

[Will Newton]

On Tuesday 31 May 2005 19:06, Cesar Martinez Izquierdo wrote:
> El Martes 31 Mayo 2005 19:41, Mark Edgington escribió:
> > Pardon me if this has already been discussed, but I wonder if there
> > should be a tag in debian packages indicating the a minimum proficiency
> > level that a user should have in order for a package to be useful to the
> > user.
> >
> > For example, a package like OpenOffice or Firefox are end-user
> > applications which most users (even those completely unfamiliar with
> > linux) would have a good chance at understanding and being able to use.
> >   On the other hand, a package like nmap might not be something my
> > Grandma would be wanting to use every day, and thus it might be better
> > to have a higher proficiency-level rating for such a package.
> >
> > The motivation for such a thing is that it would make it possible for
> > package-management tools to operate in an "easy" mode which would only
> > display (or display in a separate category) packages which have a
> > proficiency-rating < x.  This would be very handy in that it would
> > permit using Debian and an apt frontend like synaptic to make it easy
> > for more-or-less "computer-illiterate" people to install new packages
> > which match their skill-level, without having to wade th
> > rough hundreds
> > of libraries and technical tools which they would never use.
> >
> > Perhaps there's a better way to accomplish this, but the ability to
> > limit the display of packages in this manner is something that it seems
> > would be beneficial to have.
> >
> > -Mark
>
> I find it a quite interesting idea. If it was implemented, there should be
> an scale, so that maintainers have some reference in order to tag their
> packages.

This would be rather arbitrary and probably be liable to cause disagreements. 
I think you could get much the same affect with some well chosen tags and 
debtags. e.g. you could filter on:

command line only tools
enterprise tools (e.g. groupware, RDBMS)
scientific tools (e.g. octave, R)
sysadmin tools (e.g. mrtg)

Alternatively create a custom distro based on Debian with only the required 
packages installed by default.

Hungary (Pecs and Budapest), meeting and key signing

[Fabio Tranchitella]

Hello,
  I will be in Hungary from Saturday 4 to Sunday 12 June, mainly in
Pecs except one day in Budapest, but I don't know yet which day will 
be. If someone is there and has some spare time, let me know. :)

Thanks,

-- 
Fabio Tranchitella <[EMAIL PROTECTED]>.''`.
Proud Debian GNU/Linux developer, admin and user.: :'  :
 `. `'`
   http://people.debian.org/~kobold/   `-
_
1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564


signature.asc
Description: Digital signature

New Penis Enlargement Patches!

[Teresa]

Penis enhancement system that works for countless men worldwide.
http://www.jnaz.net/ss/





Good taste is always an asset.   
I'm tough, ambitious and I know exactly what I want.   
Do not envy a sinner; you don't know what disaster awaits him. 
Military intelligence is a contradiction in terms.  
Health is not valued till sickness comes.  




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

Re: Is Ubuntu a debian derivative or is it a fork?

[Adrian von Bidder]

On Tuesday 31 May 2005 19.17, Stephen Birch wrote:
>
> Still looks more like a fork than a derivative . or a spoon :-)

I have problems with your terminology - what do you mean by 'fork', and what 
do you mean by 'derivative'?

To my understanding, Ubuntu is certainly a derivative of Debian (since it 
derives most of its packaging from Debian), and it's a fork (since Debian 
is not dead, and both projects are maintained.)  Passing of code between 
branches of a fork is something that can happen - for example, the gcc/egcs 
fork was originally announce that way: both branches would take code from 
the other side.)

cheers
-- vbi

-- 
 madduck: Umm, if you wanna hack at kernel-package in non-standard
ways, you need to be one with the source
 make is not one with its own Makefiles.
--  #debian-devel, Fri, 04 Mar 2005 17:50 +0100


pgpHd9i0WCRAw.pgp
Description: PGP signature

Re: Is Ubuntu a debian derivative or is it a fork?

[John Goerzen]

On Tue, May 31, 2005 at 10:17:38AM -0700, Stephen Birch wrote:
> And a very good looking spoon indeed.  I like Ubuntu and am switching
> my customer base over to it from Debian.

I may do that too, but its architecture support is abysmal compared to
Debian, so I have no choice in the matter at this point (and lack the
time to port ubuntu to all my archs).

Which is too bad; it shouldn't be too hard to have ubuntu support every
arch that debian does.

-- John


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

Re: Is Ubuntu a debian derivative or is it a fork?

[Clint Adams]

> I may do that too, but its architecture support is abysmal compared to
> Debian, so I have no choice in the matter at this point (and lack the
> time to port ubuntu to all my archs).

Perhaps the SCC plan will help make that choice easier for you.


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

Re: Wifi-radar

[Ante Karamatić]

On Tue, 2005-05-31 at 11:11 -0700, Stephen Birch wrote:

> I would be very happy to handle the debian side for this package if
> that works for you.

If I understand you well, you would like to repackage it for Sid? Or
just upload it in it?

-- 
Ante Karamatic|--|ivoks(@)grad.hr|--|PGP: D3BDA225
http://master.grad.hr/~ivoks/|--|ICQ: 64631782
May, 15.  we're fixing the universe, it's not an easy duty!


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

Re: Is Ubuntu a debian derivative or is it a fork?

[Ante Karamatić]

First of all, hi to all developers!

I packaged that wifi-radar for Ubuntu. It was my first package and I
didn't fill ITP, untill it was reviewed by others. I'm sorry for not
filling ITP. I didn't know I have to. I'm new in creating packages and
don't know all the rules.

So, could someone point me to some HOWTO or documentation regarind the
ITP and debian etiquette?

Speaking of package. It has few changes regarding upstream (man page,
autodetection of wifi interface, menu entry and uses gksudo instead of
sudo).

-- 
Ante Karamatic|--|ivoks(@)grad.hr|--|PGP: D3BDA225
http://master.grad.hr/~ivoks/|--|ICQ: 64631782
May, 15.  we're fixing the universe, it's not an easy duty!


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

Re: proficiency-level tag for debian packages

[Wouter Verhelst]

On Tue, May 31, 2005 at 07:09:38PM +0100, Will Newton wrote:
> On Tuesday 31 May 2005 19:06, Cesar Martinez Izquierdo wrote:
> > I find it a quite interesting idea. If it was implemented, there should be
> > an scale, so that maintainers have some reference in order to tag their
> > packages.
> 
> This would be rather arbitrary and probably be liable to cause disagreements. 

Not much more so than with the priorities for the alternatives system.

I find this quite an interesting idea, really.

> I think you could get much the same affect with some well chosen tags and 
> debtags. e.g. you could filter on:
> 
> command line only tools
> enterprise tools (e.g. groupware, RDBMS)
> scientific tools (e.g. octave, R)
> sysadmin tools (e.g. mrtg)

That could work too; however, in that case the "proviciency level" of
your filter would need to be pretty expert-ish, I'm afraid. Which would
defeat the purpose, kinda.

-- 
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond


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

Re: Is Ubuntu a debian derivative or is it a fork?

[Miros/law Baran]

31.05.2005 pisze Stephen Birch ([EMAIL PROTECTED]):

> Still looks more like a fork than a derivative . or a spoon :-)

``The question is: who cares?''. Or, better: does it really matter,
what name will be used? Are you perchance a free software taxonomist?

Jubal

-- 
[ Miros/law L Baran, baran-at-knm-org-pl, neg IQ, cert AI ] [ 0101010 is ]
[ BOF2510053411, makabra.knm.org.pl/~baran/, alchemy pany ] [ The Answer ] 

   Cauliflower is nothing but Cabbage with a College Education.
   -- Mark Twain


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

Re: proficiency-level tag for debian packages

[Will Newton]

On Tuesday 31 May 2005 19:55, Wouter Verhelst wrote:
> > This would be rather arbitrary and probably be liable to cause
> > disagreements.
>
> Not much more so than with the priorities for the alternatives system.
>
> I find this quite an interesting idea, really.

Alternatives are down a fairly narrow axis - is text editor X more appropriate 
to install by default than editor Y which can be argued quite sensibly along 
the lines of popularity or ease of use for the novice.

Is KMail easier to use than the Gimp? Does that question even make sense to 
ask?

> > command line only tools
> > enterprise tools (e.g. groupware, RDBMS)
> > scientific tools (e.g. octave, R)
> > sysadmin tools (e.g. mrtg)
>
> That could work too; however, in that case the "proviciency level" of
> your filter would need to be pretty expert-ish, I'm afraid. Which would
> defeat the purpose, kinda.

I'm not sure I understand your meaning, could you expand on that a little?

I was suggesting that an install that is tagged "novice" or similar would not 
by default show packages with those tags in listings and searches, installing 
them only as dependencies. The only user intervention required would be to 
enable some kind of "expert mode" to get at the hidden packages.


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

Linux / Debian / Ubuntu

[Andrew M.A. Cater]

Listening to BBC world service right now - good mentions of Linux, Open
Source, Hacker Ethic - and specifically Ubuntu (mentioned as derived
from Debian Linux). Go Digital - on air and on line

Also mentioning "open source ethic" as a possible way of developing
e.g. drugs and other collaborative developments and that Linux
enthusiasts came along to advise/share experience.

GO DEBIAN :)

Andy


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

Re: proficiency-level tag for debian packages

[Rich Walker]

Will Newton <[EMAIL PROTECTED]> writes:

> This would be rather arbitrary and probably be liable to cause disagreements. 
> I think you could get much the same affect with some well chosen tags and 
> debtags. e.g. you could filter on:
>
> command line only tools
> enterprise tools (e.g. groupware, RDBMS)
> scientific tools (e.g. octave, R)
> sysadmin tools (e.g. mrtg)

Even within these categories there is some need for finer grain.

For example, groupware clients are mostly "easy, end-user, corporate"
groupware servers are mostly "impossible, sysadmin, corporate, server"

But debtags should cope with this?

I can see an installer screen like the old tasksel menu, where I can say
to someone over the phone:

"Yes, now the installer should have brought up a long list of words with
tick-boxes by them. Select easy, desktop, internet, end-user, corporate
and OurLocalPackages. Now click [Install All Relevant]"

cheers, Rich.


-- 
rich walker |  Shadow Robot Company | [EMAIL PROTECTED]
technical director 251 Liverpool Road   |
need a Hand?   London  N1 1LX   | +UK 20 7700 2487
www.shadow.org.uk/products/newhand.shtml


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

Debian Packaging Question

[Michael S. Peek]

Hello all,

I hope I have the right list.  If not, just kindly point me in the right
direction.

I am attempting to develop my own .deb packages that customize a debian
installation for our network.  Some of my packages attempt to divert files out
of the way in preinst before unpacking my custom files in their place.  A good
example is autofs.  My autofs configuration package will attempt to divert
/etc/auto.master in preinst, and unpack my own /etc/auto.master in it's place.

But, when I try to have the autofs packages and my autofs configuration
package installed at the same time, I get some errors back from my preinst
script:

| Unpacking autofs (from .../autofs_4.1.3+4.1.4beta2-10_i386.deb) ...
| Selecting previously deselected package libhesiod0.
| Unpacking libhesiod0 (from .../libhesiod0_3.0.2-15.1_i386.deb) ...
| Selecting previously deselected package autofs-hesiod.
| Unpacking autofs-hesiod (from .../autofs-hesiod_4.1.3+4.1.4beta2-10_i386.deb
| ) ...
| Selecting previously deselected package tiem.autofs-config.
| Unpacking tiem.autofs-config (from .../tiem.autofs-config_1.0_all.deb) ...
| tiem.autofs-config::preinst::install (new version)
| *** WARNING: Cannot divert file:
| File: /etc/auto.master
| File does not exist
| *** WARNING: Cannot divert file:
| File: /etc/auto.media
| File does not exist
| dpkg: error processing /var/cache/apt/archives/tiem.autofs-config_1.0_all.de
| b (--unpack):
| trying to overwrite `/etc/auto.master', which is also in package autofs
| tiem.autofs-config::postrm::abort-install (new version)

The error messages are from my preinst script, which checks for the existence
of the files-to-be-diverted before attempting to divert them.

I thought I had this licked, because I made my autofs configuration package
(tiem.autofs-config) Pre-Depend on autofs and autofs-hesiod.  I thought that
doing so would force dpkg to configure autofs and autofs-hesiod *BEFORE*
installing my tiem.autofs-config.

What *should* I be doing instead?

Thanks for your help,

Michael Peek


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

Re: Is Ubuntu a debian derivative or is it a fork?

[Matt Zimmerman]

On Tue, May 31, 2005 at 01:34:51PM -0500, John Goerzen wrote:

> I may do that too, but its architecture support is abysmal compared to
> Debian, so I have no choice in the matter at this point (and lack the time
> to port ubuntu to all my archs).

Ubuntu currently has first-class ports for i386, amd64 and powerpc, and
second-class ports for ia64 and sparc.  Whether that qualifies as abysmal,
of course, depends on the needs of the individual or organization involved.

> Which is too bad; it shouldn't be too hard to have ubuntu support every
> arch that debian does.

Given that Ubuntu is based on Debian, there isn't much porting work to be
done at all for architectures that Debian already supports.  However, any
new port needs a custodian (or better, a team of them) to take
responsibility for it.  Given that, it is not a problem to get the relevant
infrastructure in place for building and distributing packages.

-- 
 - mdz


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

Re: Is Ubuntu a debian derivative or is it a fork?

[Matt Zimmerman]

On Tue, May 31, 2005 at 10:17:38AM -0700, Stephen Birch wrote:

> Normal debian etiquette identifies the maintainer of a new package as
> the first person to file an ITP.  So how is this coordinated with
> Ubuntu?

In some cases, Ubuntu maintainers are not also Debian maintainers, and as
such would require sponsorship in order to upload their packages to Debian.
Ubuntu, on the other hand, imports all new source packages from Debian, so
there's no problem in that direction.

At first glance, it would seem sensible for Ubuntu maintainers to file ITPs
in order to avoid duplication of effort.  However, it's not clear to me how
they should proceed once they have packaged the software and uploaded it to
Ubuntu.  Ideally, they would be connected with a sponsor to upload the
package to Debian, but this can't be a requirement

> Unless I missed the ITP and filed a double by mistake we appear to have
> two independent wifi-radar maintainers now. The Ubuntu one and the debian
> one.

I don't see a wifi-radar package in Ubuntu, so unless I've missed something,
yours is the most authoritative package.

> But I sure want to see good coordination between Ubuntu and Debian.

As do we, of course.

> > Patches to bugs, debian maintainers picking up the patches from the
> > patch repository, inter-team communication.  It depends.
> 
> Still looks more like a fork than a derivative . or a spoon :-)

I don't know what basis you're using for this terminology, but "fork" in the
context of open source projects tends to have a negative connotation of
non-cooperation, which is certainly not the intent in the case of Ubuntu.

The -mm branch of Linux could technically be called a "fork", but given that
it serves a purpose complementary to that of Linus' tree, and provides a
source of patches to be merged into mainline, it would be misleading to
refer to it as such.

-- 
 - mdz


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

Re: proficiency-level tag for debian packages

[Will Newton]

On Tuesday 31 May 2005 20:07, Rich Walker wrote:

> Even within these categories there is some need for finer grain.
>
> For example, groupware clients are mostly "easy, end-user, corporate"
> groupware servers are mostly "impossible, sysadmin, corporate, server"

If you are installing a groupware server you probably want to do more research 
than that. Groupware clients like evolution and kmail I would guess would 
come under the end-user classification.

> But debtags should cope with this?

Debtags would cope with the scheme I proposed above, which I would not suggest 
would be 100% ideal, but is probably an 80/20 solution.


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

Re: Dear Adrian Bunk, Please hold off a week or two

[Andrew Suffield]

On Tue, May 31, 2005 at 11:36:06AM +0200, Thijs Kinkhorst wrote:
> On Tue, May 31, 2005 03:43, Miles Bader wrote:
> > Bernd Eckenfels <[EMAIL PROTECTED]> writes:
> >> Actually I am glad somebody is working public visible on the release
> >> issues and would not critisize him for that.
> >
> > Pointing out a problem is nice, but doing so in an obnoxious manner
> > hurts.
> 
> I would like to add: pointing out a problem is easy, providing good
> solutions is a lot harder. Continuously pointing out problems ("the metric
> is wrong", "testing is bad") is destructive critisism,

There's nothing wrong with destructive criticism. The correct solution
to an activity which is actually bad *is* to destroy it. Some
activities don't need replacing with a more productive one, they just
need eliminating.

Being obnoxious is unproductive, but that's not the annoying thing
here either.

The thing about Bunk which is annoying is the way he is continually
searching for reasons to destroy testing by proving it bad, and
continually *failing*. Not many people would mind if he was actually
right. It's being wrong every time, on a weekly basis (because he has
an axe to grind but no actual point) which annoys people.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


signature.asc
Description: Digital signature

Re: Example where testing-security was used?

[Andrew Suffield]

On Tue, May 31, 2005 at 11:46:29AM -0500, Adam Heath wrote:
> On Tue, 31 May 2005, Steve Langasek wrote:
> 
> > Moore's Law governs the rate at which the speed of hardware (at a given
> > price-point) doubles.  It says nothing about the speed at which current
> > software will *run* on current machines; and it certainly has nothing to say
> > about the speed at which such software will run on machines that are no
> > longer on the Moore's Law curve due to a lack of new hardware being
> > designed/manufactured for that architecture.
> 
> Actually, doesn't Moore's Law mean the average for all new silicon?  So, some
> cutting-edge new hardware may evolve faster than the average.

No, it's just the rate of growth of one given *line* of chips. The
'fastest chip available' has never really followed it, too many
external factors. Although it may do now that x86-64 is going
mainstream; the principal reason it's never worked historically is
because the 'fastest' machines have been obscure stuff that gets
fucked for business reasons.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


signature.asc
Description: Digital signature

Re: Example where testing-security was used?

[Andrew Suffield]

On Tue, May 31, 2005 at 03:08:09PM +0200, Pierre Habouzit wrote:
> 
> > In any case, given the number of prospective ports waiting in the
> > wings, 11 is probably a roughly correct estimate even if we *do* drop
> > some architectures.  (And since non-release ports are likely to stay
> > in unstable, and adding a release port adds three w-b databases where
> > dropping one only removes two w-b databases, it takes 1 1/2 dropped
> > archs to balance one added arch...)
> 
> in all those debates about the lack of buildds, sth seems odd to me. 
> I've always thought that moore's law was quite accurate... and my 
> understanding (I may be wrong, it's only how I understand the whole 
> thing) is that debian growth is quite linear, compared to the cpu 
> speed, disk size, BW ... growth, the time passing, we should have less 
> and less limitations.

Moore's law is cpu speed. The effective speed of software roughly
halves every 18 months (java, python, XML, SOAP, etc). In other words,
the rate of hardware performance increase is almost entirely cancelled
out by the rate of growth of software inefficiency; demands expand to
fill available resources. We scrape together some new features, but
aside from specialist/scientific stuff, the actual *functional* speed
of computers does not increase much at all. If you sit down at a gnome
desktop on a modern box, it's not actually all that different in
performance or general behaviour to what'd you got on Acorn RiscOS or
OS/2 ten years ago. Openoffice Write takes about as long to load from
hard drive as Impression Style took to load from a floppy - and it
doesn't do a hell of a lot more that you're actually going to use.

This probably says something significant.

[Note that trying *modern* software on an old box, and observing how
much slower it is, just underlines my point. The comparison here is to
the software you would have run on it when the box was new].

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


signature.asc
Description: Digital signature

Re: Debian Packaging Question

[David Moreno Garza]

On Tue, 2005-05-31 at 14:51 -0400, Michael S. Peek wrote:
> What *should* I be doing instead?

You should forward it to -mentors mailing list.

--
David Moreno Garza <[EMAIL PROTECTED]> | http://www.damog.net/
 Windows isn't a virus, viruses do something. 
 GPG: C671257D - 6EF6 C284 C95D 78F6 0B78 FFD3 981C 5FD7 C671 257D


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

Re: Keysigning without physically meeting ... thoughts?

[Andrew Suffield]

On Tue, May 31, 2005 at 09:03:12AM -0600, Wesley J. Landaker wrote:
> I wrote this up to someone. I thought I'd share it, and get your thoughts.
> (e.g. anybody see any weaknesses in #1-#3 that *aren't* present in the 
> typical meet, check ID, get GPG fingerprint, assuming #4 is always used 
> afterwards?)

Falsifying a government-issued ID is a criminal offence, regardless of
how often it happens (using it to buy alcohol is not important; they
simply raise the minimum age to compensate, so there's no need to
enforce it there). Falsifying a random photograph is not illegal at
all, and there is no reason why somebody wouldn't do it. Nothing here
has verified their identity with any strength to speak of. A person
who wants to generate an identity can do so with minimal effort and no
repercussions - so why wouldn't they?

> On Tuesday 31 May 2005 08:44, Wesley J. Landaker wrote:
> > For instance, I don't know if this is officially acceptable or not, but I
> > would probably be willing to sign someone's key even if I hadn't met them
> > in person, if I got in the mail:
> >
> >   1) A picture of them holding a recent newspaper with their GPG
> > fingerprint and signature written on it. (This would relate the person's
> > face & signature with their GPG key, and verify that it's recent).
> >  
> >   2) A copy of an acceptable (probably government-issued, non-expired)
> > picture ID. (This would relate the person's face with their "government"
> > identity).
> >
> >   3) A signed, dated, and notarized statement saying something to the
> > effect of "My name is __, my active e-mail that I control is
> > [EMAIL PROTECTED], and the GPG fingerprint of my active key that I
> > control and is not compromised is __. Attached to
> > this statement is a picture of me with a newspaper dated ___ with the
> > same GPG fingerprint, and a copy of my ___ photo ID, which I have
> > shown to the undersigned notary. Signed __, notarized by
> > ___." (Relates the date (which should be reasonably close to the
> > time when the picture in #1 was taken--a few weeks at the most), their
> > name, e-mail, and GPG fingerprint together by the statement, and the
> > picture from #1, and with their "government" identity, as that is checked
> > by the notary).
> >
> >   4) I'd sign the key, and send the updated key to the e-mail address
> > given, signed by the GPG key with the fingerprint given. (Relates the
> > e-mail address with the GPG key, as if they can't get the e-mail or
> > decrypt the e-mail to get the signature, it effectively hasn't really
> > been signed).

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


signature.asc
Description: Digital signature

Re: Is Ubuntu a debian derivative or is it a fork?

[Tollef Fog Heen]

* Stephen Birch 

| Tollef Fog Heen([EMAIL PROTECTED])@2005-05-31 18:06:
| > * Stephen Birch 
| > 
| > | The project seems to have established a mechanism for putting new
| > | packeges directly into Ubuntu.  Are new Ubuntu packages also put in
| > | Debian by the Ubuntu team members?
| > 
| > Yes.

Sorry, I originally misread your question.  They aren't necessarily
put in Debian, but they may be.  It depends on whether the person
uploading to Ubuntu is also a DD or has a Debian sponsor.

| Let me give you an example.  I filed an ITP this morning on a
| promising package called wifi-radar.
| 
| After writing the ITP I discovered someone has already built a deb for
| Ubuntu and placed it on the Ubuntu wiki.  But they did not file an
| ITP.
| 
| Normal debian etiquette identifies the maintainer of a new package as
| the first person to file an ITP.  So how is this coordinated with
| Ubuntu?

It's not coordinated per se, but this isn't a problem either.  If the
version in Ubuntu is modified from the version in Debian, they won't
be synced automatically.  If you want to work with the maintainer in
Ubuntu -- that's great and the result will hopefully be even better.

| Unless I missed the ITP and filed a double by mistake we appear to
| have two independent wifi-radar maintainers now. The Ubuntu one and
| the debian one. In this instance there isnt an issue, I just want to
| see the software packaged and I'll happily yeald to the other
| maintainer if he/she wants.  But I can see the possibility of a
| conflict in future when this happens with other packages.

If the person maintaining the Ubuntu version wants to make some
changes and those aren't accepted by Debian, it's just a forked
package with no harm done (except for any wasted effort).

| > | Also, when Ubuntu makes improvements to packages how do those
| > | improvements flow back to Debian?
| > 
| > Patches to bugs, debian maintainers picking up the patches from the
| > patch repository, inter-team communication.  It depends.
| 
| Still looks more like a fork than a derivative . or a spoon :-)

It's both and not.  I think of a fork as «we want to do this
differently and we're not going to “waste” effort getting stuff merged
again».  Ubuntu isn't that; Ubuntu is trying to get the changes back
into Debian so they don't have to maintain their own versions forever.

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  

Re: Is Ubuntu a debian derivative or is it a fork?

[Andrew Suffield]

On Tue, May 31, 2005 at 08:56:15AM -0700, Stephen Birch wrote:
> Forgive me if this has already been discussed ... if so could someone
> give me a pointer to the thread.

All the time. Just look for anything about ubuntu on -devel or
-project.

> I find myself fairly confused about Ubuntu packages.  I had thought
> that Ubuntu is a Debian derivative.  Therefore I expected new
> packages to be first placed in Debian and then flow to Ubuntu.
> 
> However, I recently found this page:
> 
> https://www.ubuntulinux.org/wiki/MOTUNewPackages
> 
> The project seems to have established a mechanism for putting new
> packeges directly into Ubuntu.  Are new Ubuntu packages also put in
> Debian by the Ubuntu team members?
> 
> The Ubuntu literature indicates that Ubuntu is a derivative of debian
> but it looks more like a fork to me.

It's a fork.

> Also, when Ubuntu makes improvements to packages how do those
> improvements flow back to Debian?

They generally don't. Ubuntu considers it more effective to spend
their time on PR to make people think they are giving stuff back, than
to actually do it; it generates more 'goodwill', since most people
won't bother to check. This thread will probably become a good
example, most of the others did.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


signature.asc
Description: Digital signature

Re: Example where testing-security was used?

[Rich Walker]

Andrew Suffield <[EMAIL PROTECTED]> writes:
>
> Moore's law is cpu speed. 

*TRANSISTORS* on a single die




cheers, Rich.


-- 
rich walker |  Shadow Robot Company | [EMAIL PROTECTED]
technical director 251 Liverpool Road   |
need a Hand?   London  N1 1LX   | +UK 20 7700 2487
www.shadow.org.uk/products/newhand.shtml


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

Re: Is Ubuntu a debian derivative or is it a fork?

[Stephen Birch]

John Goerzen([EMAIL PROTECTED])@2005-05-31 13:34:
> I may do that too, but its architecture support is abysmal compared to
> Debian, so I have no choice in the matter at this point (and lack the
> time to port ubuntu to all my archs).

That is unfortunate for you.  I am lucky (or unlucky perhaps) in that
all of my customers' machines are x86 based.  May be a sub-optimal
platform but it does make sys admin easier.

Steve


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

Re: proficiency-level tag for debian packages

[Rich Walker]

Will Newton <[EMAIL PROTECTED]> writes:

> On Tuesday 31 May 2005 20:07, Rich Walker wrote:
>
>> Even within these categories there is some need for finer grain.
>>
>> For example, groupware clients are mostly "easy, end-user, corporate"
>> groupware servers are mostly "impossible, sysadmin, corporate, server"
>
> If you are installing a groupware server you probably want to do more 
> research 
> than that. 

Hence the "impossible" tag. Having attempted to install a bunch of
groupware servers on a machine, I'd agree with you that More Research Is
Needed - but having a tag that tells you "you only want to do this if
you are a wizard" will at least ensure others don't try without fair
warning :->

> Groupware clients like evolution and kmail I would guess would 
> come under the end-user classification.

Yes, I just like the idea of being able to filter on multiple keys
simultaneously. easy + ( end-user | corporate ) you would expect to
install, say, the Mozilla packages, some kind of LDAP support,
DHCP-clients, and so on.

>
>> But debtags should cope with this?
>
> Debtags would cope with the scheme I proposed above, which I would not 
> suggest 
> would be 100% ideal, but is probably an 80/20 solution.

Better than 0!

cheers, Rich.


-- 
rich walker |  Shadow Robot Company | [EMAIL PROTECTED]
technical director 251 Liverpool Road   |
need a Hand?   London  N1 1LX   | +UK 20 7700 2487
www.shadow.org.uk/products/newhand.shtml


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

Re: Linux / Debian / Ubuntu

[Darren Salt]

I demand that Andrew M.A. Cater may or may not have written...

> Listening to BBC world service right now - good mentions of Linux, Open
> Source, Hacker Ethic - and specifically Ubuntu (mentioned as derived from
> Debian Linux). Go Digital - on air and on line

> Also mentioning "open source ethic" as a possible way of developing e.g.
> drugs and other collaborative developments and that Linux enthusiasts came
> along to advise/share experience.

> GO DEBIAN :)

For those who've missed the first three broadcasts today, there's one more at
01:05 GMT; also see http://news.bbc.co.uk/2/hi/technology/1478157.stm>.

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

Many receive advice, few profit by it.


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

Re: Is Ubuntu a debian derivative or is it a fork?

[Stephen Birch]

Miros/law Baran([EMAIL PROTECTED])@2005-05-31 21:02:
> ``The question is: who cares?''. Or, better: does it really matter,
> what name will be used?

Its not the name that would bother me, it is the result.  As Matt
Zimmerman pointed out elsewhere in this thread a "fork" is quite
negative and has the potential to badly damage both projects.

The Unix world was badly hurt by deliberate code forking during the
80s.  Those of us who lived through it are scared of a repeat.

It does look as if Ubuntu has none of the characteristics of a code
fork that can create such damage.

> Are you perchance a free software taxonomist?

No .. not at all.

Steve


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

Re: Example where testing-security was used?

[Andrew Suffield]

On Tue, May 31, 2005 at 09:30:40PM +0100, Rich Walker wrote:
> Andrew Suffield <[EMAIL PROTECTED]> writes:
> >
> > Moore's law is cpu speed. 
> 
> *TRANSISTORS* on a single die
> 
> 

Bah, yeah, but it's more or less the same thing for a given line of
chips, even when it's not a linear relationship.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


signature.asc
Description: Digital signature

Re: Is Ubuntu a debian derivative or is it a fork?

[Stephen Birch]

Tollef Fog Heen([EMAIL PROTECTED])@2005-05-31 22:21:

> ... 
> It's both and not.  I think of a fork as ??we want to do this
> differently and we're not going to ???waste??? effort getting stuff merged
> again??.  Ubuntu isn't that; Ubuntu is trying to get the changes back
> into Debian so they don't have to maintain their own versions forever.

Ah ..  that is what I wanted to read.

That makes sense. Cool.

Steve


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

Re: Is Ubuntu a debian derivative or is it a fork?

[Michael K. Edwards]

On 5/31/05, Andrew Suffield <[EMAIL PROTECTED]> wrote:
> > Also, when Ubuntu makes improvements to packages how do those
> > improvements flow back to Debian?
> 
> They generally don't. Ubuntu considers it more effective to spend
> their time on PR to make people think they are giving stuff back, than
> to actually do it; it generates more 'goodwill', since most people
> won't bother to check. This thread will probably become a good
> example, most of the others did.

If you've been around d-d awhile, you know not to take Andrew's
randomly directed flame cannon very seriously.

I have no relationship to Debian and Ubuntu other than satisfied
industrial-scale user (and kibitzer), but I think it's inane to kvetch
about Ubuntu's pattern of "giving stuff back" over the last year. 
Software process is hard work, especially when you add an extra layer
of judgment calls between upstream and release engineering.

What is the point of, say, harassing the glibc maintainer to take a
patch against the version in sid, when he's planning on jumping to
2.3.4 as soon as sarge releases?  If you want evidence on which to
judge the sincerity of Ubuntu's "giving back", watch what happens
post-sarge.  I'm optimistic, largely because the Ubuntu folks seem to
have thick enough skins to shrug off attitudes like Andrew's.

Cheers,
- Michael

Re: Is Ubuntu a debian derivative or is it a fork?

[Stephen Birch]

Hi Ante, welcome to the debian project!

Ante Karamati?([EMAIL PROTECTED])@2005-05-31 20:09:
> First of all, hi to all developers!
> 
> I packaged that wifi-radar for Ubuntu. It was my first package and I
> didn't fill ITP, untill it was reviewed by others. I'm sorry for not
> filling ITP. I didn't know I have to. I'm new in creating packages and
> don't know all the rules.

No problem at all, I am the guy that filed the ITP (Intent To Package)
before I knew of your work.  Lets chat off the list about how you want
to proceed. I'll do the best I can to help.

I only started this thread because it seems there is the possibility of
problems later on with other packages with packages being created by
two people, one on Ubuntu and one on Debian. Duplicated effort.
 
> So, could someone point me to some HOWTO or documentation regarind the
> ITP and debian etiquette?

Debian is quite well documented in most areas, but there is a ton to
read.  Here is a good place to start

http://www.debian.org/devel/join/
 
> Speaking of package. It has few changes regarding upstream (man
> page,

Genereally it is a good idea to contact the upstream developer.  Most
are delighted to hear that somebody is planning to do the packaging
work on their behalf.  Most times they will accept patches and try to
incorporate your improvements into the package.  That is excellent because
you don't have too keep patching with each new release from upstream.

> autodetection of wifi interface, menu entry and uses gksudo instead of
> sudo).

Why did you not use sudo?

Steve


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

Re: Debian Packaging Question

[Tollef Fog Heen]

* "Michael S. Peek" 

| I am attempting to develop my own .deb packages that customize a debian
| installation for our network.  Some of my packages attempt to divert files out
| of the way in preinst before unpacking my custom files in their place.  A good
| example is autofs.  My autofs configuration package will attempt to divert
| /etc/auto.master in preinst, and unpack my own /etc/auto.master in it's place.

Be aware of the fact that diverting conffiles doesn't work.

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  


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

Re: Is Ubuntu a debian derivative or is it a fork?

[Ante Karamatić]

On Tue, 2005-05-31 at 11:54 -0700, Matt Zimmerman wrote:

> I don't see a wifi-radar package in Ubuntu, so unless I've missed something,
> yours is the most authoritative package.

wifi-radar will get in Ubuntu. But, I can stop this process and open a
discussion about it. If I'm not mistaken, Stephen agreed over private
corespondance that I'll do maintaining in Ubuntu, and he'll upload
package to Debian. This would be perfect example of vice versa
contribution. But, as I said, I'm willing to stop importing wifi-radar
into Ubuntu, untill we get agreement about this kind of situations.

-- 
Ante Karamatic|--|ivoks(@)grad.hr|--|PGP: D3BDA225
http://master.grad.hr/~ivoks/|--|ICQ: 64631782
May, 15.  we're fixing the universe, it's not an easy duty!


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

Re: Is Ubuntu a debian derivative or is it a fork?

[Ante Karamatić]

On Tue, 2005-05-31 at 14:08 -0700, Stephen Birch wrote:

> Debian is quite well documented in most areas, but there is a ton to
> read.  Here is a good place to start
> 
> http://www.debian.org/devel/join/

Thanks.

> Genereally it is a good idea to contact the upstream developer.  Most
> are delighted to hear that somebody is planning to do the packaging
> work on their behalf.  Most times they will accept patches and try to
> incorporate your improvements into the package.  That is excellent because
> you don't have too keep patching with each new release from upstream.

I contacted upstream week or two ago, notifying him about debianized
wifi-radar. He said he would put package on website, but that didn't
happend.

> Why did you not use sudo?

I find wifi-radar.sh useless script. It's used only to start wifi-radar
as root. Instead of runing that script, I created .desktop entry that
will exec 'gksudo wifi-radar'. gksudo is much nicer than runing shell
script. But, you can allways open terminal, and run sudo wifi-radar.
It's same thing.

-- 
Ante Karamatic|--|ivoks(@)grad.hr|--|PGP: D3BDA225
http://master.grad.hr/~ivoks/|--|ICQ: 64631782
May, 15.  we're fixing the universe, it's not an easy duty!


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

Re: Is Ubuntu a debian derivative or is it a fork?

[Matt Zimmerman]

On Tue, May 31, 2005 at 11:14:53PM +0200, Ante Karamatić wrote:

> On Tue, 2005-05-31 at 11:54 -0700, Matt Zimmerman wrote:
> 
> > I don't see a wifi-radar package in Ubuntu, so unless I've missed something,
> > yours is the most authoritative package.
> 
> wifi-radar will get in Ubuntu. But, I can stop this process and open a
> discussion about it. If I'm not mistaken, Stephen agreed over private
> corespondance that I'll do maintaining in Ubuntu, and he'll upload
> package to Debian. This would be perfect example of vice versa
> contribution. But, as I said, I'm willing to stop importing wifi-radar
> into Ubuntu, untill we get agreement about this kind of situations.

If you've come to an agreement with Stephen, then please carry on with it
according to your agreement, regardless of any discussions about how to
handle this situation in the future.

Thanks,

-- 
 - mdz


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

Re: Is Ubuntu a debian derivative or is it a fork?

[John Hasler]

Steve writes:
> The Unix world was badly hurt by deliberate code forking during the 80s.
> Those of us who lived through it are scared of a repeat.

I don't believe that a Free Software fork can cause such damage.  The Unix
wars of the eighties depended on closed-source licensing.  They also
resulted from deliberate policies of attempting to lock-in customers with
"differentiation".
-- 
John Hasler


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

Re: Release update: minor delay; no non-RC fixes; upgrade reports

[Adrian Bunk]

On Tue, May 31, 2005 at 04:29:31AM -0700, Steve Langasek wrote:
> On Mon, May 30, 2005 at 12:59:26PM +0200, Adrian Bunk wrote:
> > Since it seems noone of the release team bothered to pay this part of 
> > the price for the testing release process, I'm sometimes using one or 
> > two spare hours to go a bit through update_excuses and report half a 
> > dozen of such issues.
> 
> > Steve saw this, and before the latest release update he sent (which was 
> > the one before yours), he asked me in a private mail about a prediction 
> > how many such RC bugs I'd expect in sarge for inclusion in his release 
> > update.
> 
> > It seems my prediction about the number of such issues didn't match his 
> > wishes regarding the state of sarge, and he did therefore neither answer 
> > my email nor mention this in the release update nor does it seem he 
> > assigned a member of the release team to do this work properly.
> 
> On the contrary, I found your answer reasonably satisfactory, and as a
> result had postponed replying to you in favor of dealing with more directly
> pressing release issues.
> 
> You indicated that as of two weeks ago, you'd been through the "middle
> seventh" of update_excuses checking for unidentified RC bugs, and that most
> of the packages below this range were not in testing and therefore wouldn't
> hold many hidden RC bugs; and I've been tracking the status of RC bugs
> closed since the freeze began, which accounts for many (though not all) of
> the more recent uploads.

What's the current number of RC bugs you've tracked this way?
Am I right to assume that you count them when looking whether you reach 
your 15 RC bugs in your metric you want to achieve today?

> So it is probably true that sarge will release with some RC bugs that could
> have easily been fixed had we known about them, but I don't think this
> number will be so great that we want to redirect resources or delay the
> release in order to try to catch them.  I don't think it's realistic to
> charge the release team with identifying all RC bugs in the distribution,
> only to take care that we don't release with them once they are so
> identified.


Not "all RC bugs" (there are most likely many not yet reported RC bugs 
in sarge).
It's "all RC bugs that are both known and already fixed in unstable".


It might sound old-fashioned, but Debian used to be famous for it's 
stability.

I remember times when there where two weeks test cycles where the whole 
thing was frozen with zero changes for at about a week, and if any 
serious problems were found they were fixed and then there was the next 
test cycle.

Why is there now always such a hurry to get everything out within a 
week?

Why are there always extremely aggressive timelines (with at least three 
publically announced release dates for sarge already passed) instead of 
making everything more relaxed for being able to improve sarge without 
being in a big hurry?


> > [1] And no, version tracking in the BTS wouldn't prevent this problem.
> > In my experience, there are so many of these issues reported with
> > a wrong version or manually closed or even without any bug report in 
> > the BTS that claiming version tracking might eliminate this problem 
> > sounds like a bad joke.
> 
>  The problems you describe are not ones that would go away with the
> removal of testing; if maintainers are not engaged in the process of
> ensuring their packages are free of RC bugs for release, and do not take
> care that RC bugs are a) documented in the BTS, b) filed at the correct
> severity, and c) fixed in the version of the package that's releasing (in
> case something goes wrong with a and b), we are going to miss RC bugs that
> could have been caught.  This is a social problem, not a technical one, and
> I don't think there are any viable technical solutions.

Relying on version tracking will add one more point where this existing 
social problem might have negative impacts on the quality of your 
releases.

> For my part, I have explicitly *not* given a free pass to packages with RC
> bugs that were filed a long time ago but only recently raised to their
> proper severity.  It's great if bug submitters know what severity a bug
> should be filed at, but it's the *responsibility* of the maintainer to
> adjust the severity if it's wrong -- even if that means raising the
> severity, something none of us want to do.  Even more, it's the maintainer's
> responsibility to *deal with* such bugs at the proper severity even if they
> were filed wrong.  It simply can't be the responsibility of any central
> group to babysit the severities of bugs filed: that's not scalable in the
> least.
> 
> So yes, sarge will ship with bugs that should have been considered RC.  But
> this is inevitable in any case because of the many RC bugs that are never
> *identified* by our testing, so there's no reason for the release team to
> treat these bugs as blocking issues if no one cares enough to m

Re: Example where testing-security was used?

[Andreas Barth]

* Marc 'HE' Brockschmidt ([EMAIL PROTECTED]) [050531 08:58]:
> Hamish Moffatt <[EMAIL PROTECTED]> writes:
> > On Mon, May 30, 2005 at 11:48:54AM +0100, Mark Brown wrote:
> >> On Mon, May 30, 2005 at 12:34:21PM +0200, Adrian Bunk wrote:
> >>> But setting up autobuilders doesn't require a new infrastructure
> >>> (and shouldn't require more than half a year).
> >>> Wasn't the infrastructure a prerequisite for woody and is working?
> >> It turned out that the central part of the existing infrastructure
> >> didn't scale up well enough to cope with the new architectures in sarge.
> > There are no new architectures in sarge.

> That's right, but the buildd network has to work for both oldstable and
> stable. potato + woody didn't need as many buildds as woody + sarge
> will need.

Especially as potato didn't had security buildds. :)


Cheers,
Andi


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

Bug#311413: ITP: nunit -- Automated testing framework for .NET

[Jelmer Vernooij]

Package: wnpp
Severity: wishlist
Owner: Jelmer Vernooij <[EMAIL PROTECTED]>

* Package name: nunit
  Version : 2.2.0
  Upstream Author : Charlie Poole <[EMAIL PROTECTED]>
* URL : http://www.nunit.org/
* License : zlib/png license
  Description : Automated testing framework for .NET

NUnit is a unit testing framework for all .NET languages. It serves the
same purpose as JUnit does in the Java world. It supports test
categories, testing for exceptions and writing test results in plain
text or XML.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.8.1
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)


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

Bug#311420: ITP: cl-aspectl -- provides aspect orientation for the Common Lisp Object System

[Rene van Bevern]

Package: wnpp
Severity: wishlist
Owner: Rene van Bevern <[EMAIL PROTECTED]>

* Package name: cl-aspectl
  Version : 0.6.4
  Upstream Author : Pascal Constanza <[EMAIL PROTECTED]>
* URL : http://common-lisp.net/project/aspectl/
* License : Creative Commons 2.0
  Description : provides aspect orientation for the Common Lisp Object 
System

AspectL provides support for aspect oriented programming to Common Lisp.
Features include:
 * Generic Pointcuts: Join points and aspect weavers
 * Mixins: Incrementally modify class definitions
 * Rebinding places instead of assigning them
 * Special generic functions: methods that are executable in the current
  dynamic scope only
.
Homepage: http://common-lisp.net/project/aspectl/


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

Murphy's Law.

[Hillary]

Confusion not only reigns, it pours. Safe Sex
It is a good thing for an uneducated man to read books of quotations.  Shake a 
leg

Chip on his Shoulder http://www.tamountophtime.com/ Shake a leg
Vampire Jaywalk
Van Gogh's ear for music Why is the third hand on the watch called the second 
hand?







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

Bug#311421: ITP: haploview -- [Biology] visualisation of SNP data with linkage disequilibrium

[Steffen Moeller]

Package: wnpp
Severity: wishlist
Owner: Steffen Moeller <[EMAIL PROTECTED]>


* Package name: haploview
  Version : 3.2
  Upstream Author : Jeffrey Barrett, Julian Maller in Mark Daly's lab <[EMAIL 
PROTECTED]>
* URL : http://www.broad.mit.edu/mpg/haploview/index.php
* License : Comes with its own DFSG-compliant license
  Description : [Biology] visualisation of SNP data with linkage 
disequilibrium

 Haploview is designed to simplify and expedite the process of haplotype
 analysis by providing a common interface to several tasks relating
 to such analyses. Haploview currently allows users to examine block
 structures, generate haplotypes in these blocks, run association
 tests,
 and save the data in a number of formats. All functionalities are
 highly customizable.

 The problem with haploview is its use of Java2 features that are not
 yet implemented by free tools. Anybody willing to help out sponsoring
 please contact me. The package is on
 http://bioinformatics.pzr.uni-rostock.de/~moeller/debian/haploview

 Many thanks and regards

 Steffen


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

Re: Is Ubuntu a debian derivative or is it a fork?

[mag]

2005-05-31, k keltezéssel 16.24-kor John Hasler ezt írta:
> Steve writes:
> > The Unix world was badly hurt by deliberate code forking during the 80s.
> > Those of us who lived through it are scared of a repeat.
> 
> I don't believe that a Free Software fork can cause such damage. 

Forks in OSS do have drawbacks, this is why they are generally frowned
upon. Of course there are cases when advantages greater than drawbacks,
esp. when the latter are minimized, e.g. by submitting back patches.
Taxonomists may argue that such forks has to be called spoons;)
Other taxonomist may also argue that Debian is an infrastructural
distribution, which is well suited to be the base of such "spoons".

Re: Dear Adrian Bunk, Please hold off a week or two

[Russ Allbery]

Santiago Vila <[EMAIL PROTECTED]> writes:

> * "unstable" is actually frozen, which means uploads for unstable are
> either discouraged, they remain in the limbo, or they are automatically
> put in some other distribution above unstable, like new-unstable, until
> testing or unstable becomes the new stable.

At which point there are *still* fixed bugs that don't make it into the
release.  They're fixed upstream, fixed in experimental, fixed in private
working repositories that don't get uploaded due to the freeze, etc.
There are also the bugs that people just don't notice.

As near as I can tell (and I've had a package affected by this), the
release team is doing a great job making sure that fixes that they know
about propagate into sarge.  There will be fixes they don't know about.
There will be RC bugs found after the release.  Debian is just far, far
too large to be able to release a bug-free distribution.  This isn't a
serious problem; this is just life.  If they're RC and actually
significant (some of the missing dependencies are RC but not really that
important for normal use scenarios), hopefully they can be fixed through
proposed-updates.

Let's not spend a bunch of time fretting about the last 1%.  Doing
something reasonable and then going with it will produce results that will
be quite acceptable in practice.

-- 
Russ Allbery ([EMAIL PROTECTED]) 


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

Re: Is Ubuntu a debian derivative or is it a fork?

[John Goerzen]

On Wed, Jun 01, 2005 at 04:49:20AM +0200, mag wrote:
> 2005-05-31, k keltezéssel 16.24-kor John Hasler ezt írta:
> Forks in OSS do have drawbacks, this is why they are generally frowned
> upon. Of course there are cases when advantages greater than drawbacks,
> esp. when the latter are minimized, e.g. by submitting back patches.
> Taxonomists may argue that such forks has to be called spoons;)
> Other taxonomist may also argue that Debian is an infrastructural
> distribution, which is well suited to be the base of such "spoons".

Perhaps, but there are some issues with that.

In the ubuntu case in particular, I wish that they would be more
proactive in sending their patches to the Debian maintainers.  Asking
us Debian folk to go to an obscure site somewhere, wade through
listings of thousands of diffs, and find changes is difficult.  For
example, Python 2.4 is in sid, and I don't mind making my packages use
it now.  I'd appreciate any and all diffs from ubuntu folks.

Sometimes they are changing things for some unique "ubuntu way".  I'd
like to ask them: why must the Ubuntu way be different from Debian?
Is there a better way we could minimize patches and perhaps do
something like provide differing defaults?

I've also been on the other side of the coin, and something that makes
it difficult for the derivers is lack of communication from some
quarters of Debian.  I certainly recall frustration about inactive
maintainers, and we must remember that there are maintainers in Debian
that can't even be bothered to apply good patches when they see them.

Finally, I would like to see many more developers putting their
packages a distributed version control system like Arch or, better
yet, Darcs.  It makes it a lot easier for others to collaborate with
you.  For an example of what I'm talking about, see
http://darcs.complete.org.  Most of the directories there are Debian
packages, and most of my Debian packages are in darcs.

darcs-buildpackage and tla-buildpackage are your friends :-)

-- John

Re: Is Ubuntu a debian derivative or is it a fork?

[John Hasler]

Steve writes:
 The Unix world was badly hurt by deliberate code forking during the 80s.
> Those of us who lived through it are scared of a repeat.

I wrote:
> I don't believe that a Free Software fork can cause such damage. 

mag writes:
> Forks in OSS do have drawbacks, this is why they are generally frowned
> upon.

I agree that they may have drawbacks, but I don't believe that they can
cause the sort of damage that the Unix wars caused.
-- 
John Hasler 
[EMAIL PROTECTED]
Elmwood, WI USA


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

Re: Keysigning without physically meeting ... thoughts?

[Wesley J. Landaker]

On Tuesday 31 May 2005 14:11, Andrew Suffield wrote:
> On Tue, May 31, 2005 at 09:03:12AM -0600, Wesley J. Landaker wrote:
> > I wrote this up to someone. I thought I'd share it, and get your
> > thoughts. (e.g. anybody see any weaknesses in #1-#3 that *aren't*
> > present in the typical meet, check ID, get GPG fingerprint, assuming #4
> > is always used afterwards?)
>
> Falsifying a government-issued ID is a criminal offence, regardless of
> how often it happens (using it to buy alcohol is not important; they
> simply raise the minimum age to compensate, so there's no need to
> enforce it there). Falsifying a random photograph is not illegal at
> all, and there is no reason why somebody wouldn't do it. Nothing here
> has verified their identity with any strength to speak of. A person
> who wants to generate an identity can do so with minimal effort and no
> repercussions - so why wouldn't they?

Right, but they have to get it notarized (or forge a notary's seal, which is 
a criminal offense, at least in the US) which requires government ID 
(again, at least in the US). 

Regardless, how is this different from meeting someone in person? They can 
just show me their fake ID--I won't know it's fake. (And, as you said, 
forged ID happens a lot and is easily available. =)

-- 
Wesley J. Landaker <[EMAIL PROTECTED]>
OpenPGP FP: 4135 2A3B 4726 ACC5 9094  0097 F0A9 8A4C 4CD6 E3D2


pgpwZ651ztwc2.pgp
Description: PGP signature

Re: Keysigning without physically meeting ... thoughts?

[Jacob S]

On Tue, 31 May 2005 14:13:54 -0600
"Wesley J. Landaker" <[EMAIL PROTECTED]> wrote:

> On Tuesday 31 May 2005 14:11, Andrew Suffield wrote:
> > On Tue, May 31, 2005 at 09:03:12AM -0600, Wesley J. Landaker wrote:
> > > I wrote this up to someone. I thought I'd share it, and get your
> > > thoughts. (e.g. anybody see any weaknesses in #1-#3 that *aren't*
> > > present in the typical meet, check ID, get GPG fingerprint,
> > > assuming #4 is always used afterwards?)
> >
> > Falsifying a government-issued ID is a criminal offence, regardless
> > of how often it happens (using it to buy alcohol is not important;
> > they simply raise the minimum age to compensate, so there's no need
> > to enforce it there). Falsifying a random photograph is not illegal
> > at all, and there is no reason why somebody wouldn't do it. Nothing
> > here has verified their identity with any strength to speak of. A
> > person who wants to generate an identity can do so with minimal
> > effort and no repercussions - so why wouldn't they?
> 
> Right, but they have to get it notarized (or forge a notary's seal,
> which is  a criminal offense, at least in the US) which requires
> government ID  (again, at least in the US). 
> 
> Regardless, how is this different from meeting someone in person? They
> can  just show me their fake ID--I won't know it's fake. (And, as you
> said,  forged ID happens a lot and is easily available. =)

So why bother with steps 1 & 2 when 3 is the only one that carries any
weight? Maybe there is a good reason that I do not know of, but I can
not think of any. I am genuinely curious, though.

Just my $0.02.

Jacob


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

Re: Is Ubuntu a debian derivative or is it a fork?

[John Goerzen]

On Tue, May 31, 2005 at 08:21:01PM -0500, John Hasler wrote:
> mag writes:
> > Forks in OSS do have drawbacks, this is why they are generally frowned
> > upon.
> 
> I agree that they may have drawbacks, but I don't believe that they can
> cause the sort of damage that the Unix wars caused.

Not only that, but we're developing some quite sophisticated tools to
manage them.  Darcs is my favorite example of this, with its "every
checkout is a fork, and every push is a merge" way of operation.
Quite powerful and elegant, IMHO.

I no longer subscribe to the "forking is inherently bad" idea.

Cooperative forking can, and often has, been a Good Thing.  Example:
baz, which is more or less a fork of tla.  In some ways, it serves as
an "unstable" tla, where new ideas get tested.

-- John


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

Re: Keysigning without physically meeting ... thoughts?

[Wesley J. Landaker]

On Tuesday 31 May 2005 20:48, Jacob S wrote:
> > Regardless, how is this different from meeting someone in person? They
> > can  just show me their fake ID--I won't know it's fake. (And, as you
> > said,  forged ID happens a lot and is easily available. =)
>
> So why bother with steps 1 & 2 when 3 is the only one that carries any
> weight? Maybe there is a good reason that I do not know of, but I can
> not think of any. I am genuinely curious, though.

The general idea was to be purposefully overkill--that if they were going to 
forge something, they'd have to forge a whole lot of it. 

Partly, this was in response to the (perceived(?)) guideline that you 
shouldn't ever sign someone's public key unless you've met them in 
person--I was trying to narrow down all of the links that were important 
(seeing the person's face, seeing their ID, seeing that the two match, 
knowing that it was actually the person I saw who has control of the key 
and that same person has control of their e-mail address, etc).

Barring something I just totally missed, I believe what I wrote up is at 
least as good at determining that a person is who they say they are as 
meeting in person and checking ID's. Obviously there are always the issue 
of forgeries, but I don't think this method is any *worse* in the respect. 
But I thought I'd give anyone interested a chance to bang at the idea, 
because I'm curious if someone else knows something I don't. =)

-- 
Wesley J. Landaker <[EMAIL PROTECTED]>
OpenPGP FP: 4135 2A3B 4726 ACC5 9094  0097 F0A9 8A4C 4CD6 E3D2


pgpCORrW0LTyO.pgp
Description: PGP signature

Re: More about GFDL

[Nathanael Nerode]

Cesar Martinez Izquierdo wrote:
> El Viernes 22 Abril 2005 14:37, Maciej Dems escribió:
>> 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?
Yes, until the GFDL is revised, mainly due to the so-called "anti-DRM
clause".

First of all, to avoid Invariant-Section-like problems, the document also
must include no cover texts.  Acknowledgements and Dedications appear to
suffer similar problems (though it's unclear).  (One of the things which
makes these worse than similar requirements in other licenses is that these
apparently must be included *in* rather than *alongside* the document, and
presumably in the table of contents as well.  The title preservation
requirements are also troublesome.)

But without all of these?  Still not free.  The "anti-DRM clause", as
written, makes the GFDL documentation non-free.  (We believe that this is a
mistake and hope that it will be fixed in the next version.)

In addition, the "transparent and opaque forms" section is of uncertain
freeness, and we haven't got a clarification.  It's unclear, but the
license may also prohibit pseudonymous authorship, which would be non-free,
and we haven't got a clarification.

-- 
This space intentionally left blank.

Re: Is Ubuntu a debian derivative or is it a fork?

[mag]

2005-05-31, k keltezéssel 21.00-kor John Goerzen ezt írta:
> > Other taxonomist may also argue that Debian is an infrastructural
> > distribution, which is well suited to be the base of such "spoons".
> 
> Perhaps, but there are some issues with that.
> 
> In the ubuntu case in particular, I wish that they would be more
> proactive in sending their patches to the Debian maintainers. 

> Sometimes they are changing things for some unique "ubuntu way". 

Okay, these were the problems.

And here is a good part of the solution:

> Finally, I would like to see many more developers putting their
> packages a distributed version control system like Arch or, better
> yet, Darcs.  


If everyone in the food chain, at least down from the debian maintainer,
would use that, it would greatly simplify problems with patch
management. Just I highly doubt it is doable.

It could also help to apply upper stream patches for spoons while
sticking to their spoonerisms ;), and even not giving them back in
patches again and again.

I guess that we, as Debian developers have no ground to criticise
downstream for doing things in their own way, provided they don't keep
pushing things deemed unacceptable.

It is another thing that I also used to be nervous to an other Debian
spoon;) when my friends ask for help, and I face its own little ugly
ways like completely changed init, or postinst scripts made completely
unintelligible...

Re: Is Ubuntu a debian derivative or is it a fork?

[Matt Zimmerman]

On Tue, May 31, 2005 at 09:00:33PM -0500, John Goerzen wrote:

> In the ubuntu case in particular, I wish that they would be more
> proactive in sending their patches to the Debian maintainers.  Asking
> us Debian folk to go to an obscure site somewhere, wade through
> listings of thousands of diffs, and find changes is difficult.  For
> example, Python 2.4 is in sid, and I don't mind making my packages use
> it now.  I'd appreciate any and all diffs from ubuntu folks.

I don't want to repeat the discussion about pushing patches; there's a
perfectly reasonable one already in the list archives.  There are good
reasons why we do this the way that we do.

FWIW, the diffs you would get from Ubuntu would build for Python 2.4 _as the
default version_, which isn't what you want.

After Sarge, releases, it should be pretty straightforward for someone to
set up a script to mass-mail Debian maintainers copies of the Python
transition patches from Ubuntu (or all of the patches, if that's really what
they believe that Debian maintainers want).

> Sometimes they are changing things for some unique "ubuntu way".  I'd
> like to ask them: why must the Ubuntu way be different from Debian?
> Is there a better way we could minimize patches and perhaps do
> something like provide differing defaults?

You might as well ask the same question of any Debian derivative.  The
reason that derivatives exist is because people want different things.
In the case of Ubuntu, we outline on our website what we do differently.

It is of course in our best interest to keep the delta manageable, and we
try to do that.

> I've also been on the other side of the coin, and something that makes it
> difficult for the derivers is lack of communication from some quarters of
> Debian.  I certainly recall frustration about inactive maintainers, and we
> must remember that there are maintainers in Debian that can't even be
> bothered to apply good patches when they see them.

Indeed, for all of the gripes about submitting patches, a disappointingly
small fraction of the patches that Ubuntu proactively submits are actually
uploaded to Debian by the maintainer.

> Finally, I would like to see many more developers putting their
> packages a distributed version control system like Arch or, better
> yet, Darcs.  It makes it a lot easier for others to collaborate with
> you.  For an example of what I'm talking about, see
> http://darcs.complete.org.  Most of the directories there are Debian
> packages, and most of my Debian packages are in darcs.

In the not-so-distant future, a huge proportion of Ubuntu development will
take place in Arch branches, with the intent of promoting more efficient
collaboration both within Ubuntu and with Debian.

-- 
 - mdz


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

Re: Is Ubuntu a debian derivative or is it a fork?

[Stephen Birch]

Michael K. Edwards([EMAIL PROTECTED])@2005-05-31 13:56:
> What is the point of, say, harassing the glibc maintainer to take a
> patch against the version in sid, when he's planning on jumping to
> 2.3.4 as soon as sarge releases?  If you want evidence on which to
> judge the sincerity of Ubuntu's "giving back", watch what happens
> post-sarge.  I'm optimistic, largely because the Ubuntu folks seem to

Okay - you have my attention.  If you are right etch will be as
beautiful as Hoary within a few weeks of the sarge release.

Oh my gosh, I hope and pray you are right.

We are all watching ...

Steve




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

Re: Linux / Debian / Ubuntu

[Stephen Birch]

Darren Salt([EMAIL PROTECTED])@2005-05-31 21:49:
> For those who've missed the first three broadcasts today, there's one more at
> 01:05 GMT; also see http://news.bbc.co.uk/2/hi/technology/1478157.stm>.

Why on earth does the BBC force its listeners to all hit its servers
at the same time.  Doesn't make sense at all, why not ogg the program
up and put it on its servers so the audience can listen when they
want.

Okay, so I know the answer.  The BBC is still coming to grips with the
idea that "boradcasting" is dead.  The tech generation wants to time
and space shift programming to a convenient time/location.

Steve


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

Re: Is Ubuntu a debian derivative or is it a fork?

[John Goerzen]

On Tue, May 31, 2005 at 07:47:19PM -0700, Matt Zimmerman wrote:
> On Tue, May 31, 2005 at 09:00:33PM -0500, John Goerzen wrote:
> 
> > example, Python 2.4 is in sid, and I don't mind making my packages use
> > it now.  I'd appreciate any and all diffs from ubuntu folks.
> 
> I don't want to repeat the discussion about pushing patches; there's a
> perfectly reasonable one already in the list archives.  There are good
> reasons why we do this the way that we do.

A discussion, yes... perfectly reasonable, not so much :-(

Anyway, it was not my intention to beat that particular dead horse.

Want to do us Debian folks a big favor for little work?  Provide a
view of your patches sorted by maintainer, then by source package.

> After Sarge, releases, it should be pretty straightforward for someone to
> set up a script to mass-mail Debian maintainers copies of the Python
> transition patches from Ubuntu (or all of the patches, if that's really what
> they believe that Debian maintainers want).

I'd prefer wishlist bugs tagged patch when there is a patch relevant
for Debian, personally.

> You might as well ask the same question of any Debian derivative.  The
> reason that derivatives exist is because people want different things.
> In the case of Ubuntu, we outline on our website what we do differently.

I'm aware of that.  There are cases, though, where people tend to
create a difference when it's not necessary.  A common place is
graphics on the default desktop.  I don't know if Ubuntu changes
those, but I know some derivatives do, and thus have to fork some
packages.  I figure it would be easier to use /etc/alternatives to
manage those defaults, but that's just me.

> It is of course in our best interest to keep the delta manageable, and we
> try to do that.

Yes, of course.

> Indeed, for all of the gripes about submitting patches, a disappointingly
> small fraction of the patches that Ubuntu proactively submits are actually
> uploaded to Debian by the maintainer.

Out of curiousity, do you have a rough estimate of the percentage that
actually make it into Debian?  Or the percentage that are held back
with no good reason?

> In the not-so-distant future, a huge proportion of Ubuntu development will
> take place in Arch branches, with the intent of promoting more efficient
> collaboration both within Ubuntu and with Debian.

Very nice.

Looks like someone needs to write the Arch backend for darcs :-)

BTW, the baz folks could get some very neat ideas from darcs.  The
"offline mode comes free" way of working is very nice, and the
branching being easier than Arch is nice, too.

-- John


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

Re: Keysigning without physically meeting ... thoughts?

[Marc Haber]

On Tue, 31 May 2005 14:13:54 -0600, "Wesley J. Landaker"
<[EMAIL PROTECTED]> wrote:
>Right, but they have to get it notarized (or forge a notary's seal, which is 
>a criminal offense, at least in the US) which requires government ID 
>(again, at least in the US). 

The entire procedure is quite US centric. I don't understand why you
US guys are so fond of your notaries. Over here, it's a three digit
bill for the notary to open the office door and to offer you a chair,
so there might be cultures where one thinks twice or even three times
before having something notarized.

Additionally, the web of trust is the web of trust because it is
entirely self-contained, without putting any trust on government and
state official. Your suggestion violates this principle by moving the
verification state to the notary.

Even if the notary were sufficiently advanced to offer PGP key signing
with her official key this were not good enough for Debian, since the
Debian web of trust explicitly relies on being self-contained. You'd
need to have a DD notary, which at this point makes the signature
valid because of the DD property, and being notary becomes irrelevant.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: Is Ubuntu a debian derivative or is it a fork?

[Michael K. Edwards]

On 5/31/05, Stephen Birch <[EMAIL PROTECTED]> wrote:
> Okay - you have my attention.  If you are right etch will be as
> beautiful as Hoary within a few weeks of the sarge release.

I think it's been so long since Debian started having pre-sarge
freeze-spasms that we've all forgotten what it's like when the
floodgates open post-release.  (I, for one, wasn't around for the last
one, but I've done a certain amount of reading.)  "A few weeks" is
probably on the optimistic side.  I don't know if Ubuntu has Breezy is
in any kind of usable state yet, and I don't think they let in
anything like the backlog of updates that is awaiting etch.

Once sarge does release, the Ubuntu folks are going to be right there
in the trenches with everyone else dealing with GCC 4.0, the death of
devfs, and the demands for a graphical installer.  If anything they'll
be pulling Debian forward with Linux 2.6.11.bignum, just as they are
with Python 2.4 and some of the remaining java-in-main issues.  It is
not in their interest to let their fork (or spoon or other implement
of destruction) go off into the rough.

> Oh my gosh, I hope and pray you are right.
> 
> We are all watching ...

I'm not quite sure this is sarcasm, although I have my suspicions. 
But I happened to be watching on #ubuntu-devel as the last few hoary
RCs got knocked off.  These guys (and gals) are pros, and they're
excited about what they're doing, and they aren't any less committed
to Debian than they were before no-name-yet.  They're used to dealing
patiently with bull-headed upstreams when wearing their DD hats, so
they can probably take Debian-Ubuntu frictions in stride.

Some things about the relationship are going to be hard, though.  I
was very distressed to find that a last-minute ABI change in sarge's
glibc will cause any package built on sarge that gets a versioned
glibc dependency to be uninstallable on hoary.  I really had hoped to
run the same mysql-server packages on both, and I'm not quite sure
what I'm going to do for a distro-neutral C++ build environment.  :-(

Cheers,
- Michael

Re: Is Ubuntu a debian derivative or is it a fork?

[Andreas Tille]

On Tue, 31 May 2005, John Goerzen wrote:


I've also been on the other side of the coin, and something that makes
it difficult for the derivers is lack of communication from some
quarters of Debian.  I certainly recall frustration about inactive
maintainers, and we must remember that there are maintainers in Debian
that can't even be bothered to apply good patches when they see them.

If there are inactive maintainers in Debian why not starting group
maintainance?  The Ubuntu maintainer might be listed in the Uploaders
field and find a sponsor to upload the package (in the best case the
other maintainer).  THis is called group maintainance and IMHO the
biggest problem in Debian is that outsiders often assume they just
have to wait until something in Debian is done.  If they are active
persons they do something outside others just whine about Debian. But
the best solution would be how to learn how to do things *inside*
Debian instead of forking / spooning / deriving / whatevering.

Kind regards

 Andreas.

--
http://fam-tille.de


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

Re: Is Ubuntu a debian derivative or is it a fork?

[Andreas Tille]

On Wed, 1 Jun 2005, John Goerzen wrote:


On Tue, May 31, 2005 at 07:47:19PM -0700, Matt Zimmerman wrote:

After Sarge, releases, it should be pretty straightforward for someone to
set up a script to mass-mail Debian maintainers copies of the Python
transition patches from Ubuntu (or all of the patches, if that's really what
they believe that Debian maintainers want).

I'd prefer wishlist bugs tagged patch when there is a patch relevant
for Debian, personally.

The idea of filing wishlist bug reports against something a user wanted
to have changed is so straightforeward that I never expected that experienced
Debian users (= I expect DDs to be experienced users) would come up with the
idea of mass-mailing patches.

IMHO somebody who derives from Debian is just a special type of a Debian
user (he just uses the code basis) and for user wishes we have implemented
the wishlist tag in the BTS.  If this has drawbacks for certain purposes please
explain - at best file a bug report against BTS preferably with a patch.


I'm aware of that.  There are cases, though, where people tend to
create a difference when it's not necessary.  A common place is
graphics on the default desktop.  I don't know if Ubuntu changes
those, but I know some derivatives do, and thus have to fork some
packages.  I figure it would be easier to use /etc/alternatives to
manage those defaults, but that's just me.

... and me as well.

Kind regards

 Andreas.

--
http://fam-tille.de


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

Re: Is Ubuntu a debian derivative or is it a fork?

[Andreas Tille]

On Tue, 31 May 2005, Ante [iso-8859-2] Karamati? wrote:


I contacted upstream week or two ago, notifying him about debianized
wifi-radar. He said he would put package on website, but that didn't
happend.

There were several discusions about the sense that upstream maintains
a downloadable copy of the Debian package or provides the debian/
directory in the upstream archive.  The result was that this is a
bad idea because it requires more work for upstream to keep on watching
the Debian development and the maintainer to push his development
to upstream.  Just mentioning that there is a Debian package and putting
a link on the upstream web site is fine.  Everything else just
produces more work and confusion if there are different package versions
around.

Kind regards

Andreas.

--
http://fam-tille.de


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

Re: Is Ubuntu a debian derivative or is it a fork?

[Matt Zimmerman]

On Wed, Jun 01, 2005 at 12:06:39AM -0500, John Goerzen wrote:

> On Tue, May 31, 2005 at 07:47:19PM -0700, Matt Zimmerman wrote:
> > After Sarge, releases, it should be pretty straightforward for someone to
> > set up a script to mass-mail Debian maintainers copies of the Python
> > transition patches from Ubuntu (or all of the patches, if that's really what
> > they believe that Debian maintainers want).
> 
> I'd prefer wishlist bugs tagged patch when there is a patch relevant
> for Debian, personally.

That would be only slightly more work for someone to automate.  I see no
need to argue about whether Ubuntu should push; the patches are all there in
an easily accessible tree, and it would be trivial to pull the patches and
push them someplace else if that's desirable.

> > You might as well ask the same question of any Debian derivative.  The
> > reason that derivatives exist is because people want different things.
> > In the case of Ubuntu, we outline on our website what we do differently.
> 
> I'm aware of that.  There are cases, though, where people tend to create a
> difference when it's not necessary.  A common place is graphics on the
> default desktop.  I don't know if Ubuntu changes those, but I know some
> derivatives do, and thus have to fork some packages.  I figure it would be
> easier to use /etc/alternatives to manage those defaults, but that's just
> me.

We're going to do the work to make this kind of branding easy in Ubuntu.  If
the appropriate Debian maintainers will merge some of those patches, so much
the better.

> Out of curiousity, do you have a rough estimate of the percentage that
> actually make it into Debian?  Or the percentage that are held back
> with no good reason?

I don't have any hard statistics, but here are some random examples of
patches whose development was sponsored by Canonical, were tested and proven
in Ubuntu, were proactively submitted to Debian by an Ubuntu developer, and
remain in debbugs months later without comment from the maintainer:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=298060
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=298064

Several similar patches were submitted after a comprehensive review of
daemon privileges in Ubuntu, and at last count, only one of them had made it
into Debian proper.

I'm not trying to make anyone look bad, least of all Debian developers who
are spending their leisure time on package maintenance.  It's just fact that
it sometimes takes an indefinite period of time to get changes into Debian,
even if every effort is made to simplify the process for the maintainer.

> BTW, the baz folks could get some very neat ideas from darcs.  The
> "offline mode comes free" way of working is very nice, and the
> branching being easier than Arch is nice, too.

The next generation of Bazaar aims to incorporate the best bits of other
revision control systems, including darcs:

http://www.bazaar-ng.org/

If you care to discuss particular ideas, I suggest mailing either the
bazaar-ng mailing list, or Martin Pool.

-- 
 - mdz


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

10 minutes before sex, lasts for 24-36 hours

[Stella]

We have been rated as #1 One-Stop-Shop Internet pharmacy.
http://qqfynv.1ymcn21cgbj9521.clerklessjm.com



Never let your persistence and passion turn into stubbornness and ignorance.  
How wonderful opera would be if there were no singers.   
Someone's boring me. I think it's me.  




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

Re: Example where testing-security was used?

[Steve Langasek]

On Tue, May 31, 2005 at 03:49:09PM +0200, Romain Francoise wrote:
> Steve Langasek <[EMAIL PROTECTED]> writes:

> > In any case, given the number of prospective ports waiting in the
> > wings, 11 is probably a roughly correct estimate even if we *do* drop
> > some architectures.

> Speaking of prospective ports, what would be the feasibility of keeping
> testing frozen after sarge releases, do whatever toolchain updates are
> needed to support amd64 via t-p-u, and release etch as a "sarge+amd64"
> release in, say, 3 months?

uh, probably roughly 0 I imagine, since such a project would be contending
for archive space with the amd64 port for etch...

But ultimately a question for the SRM and the ftpmasters anyway, I think.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature