Re: Debian Games Team

[Andreas Tille]

On Fri, 13 Jan 2006, Miriam Ruiz wrote:


We've been recently talking about creating a group to maintain games in Debian
in a collaborative way.


Are you aware of the Debian-Junior project.  While quite inactive in the last
time a certain effort was done in classifying games by building some interesting
meta packages.  You might also consider to join the Custom Debian Distribution
effort which might help to make your target better visible for the users.

Kind regards

  Andreas.

--
http://fam-tille.de


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

Re: Trivial bug on apt-file (Was : Re: Development standards for unstable)

[Anthony Towns]

On Fri, Jan 13, 2006 at 02:34:32PM +0900, Charles Plessy wrote:
> On Fri, Jan 13, 2006 at 04:47:33AM +1000, Anthony Towns wrote :
> > On Thu, Jan 12, 2006 at 06:48:38PM +0100, Luk Claes wrote:
> > > > But if you read this bug (#307833), you'd see that the maintainer 
> > > > doesn't
> > > > consider it a bug, and has documented why in the README file.
> > > It is a bug as the package is not usable without curl or wget installed.
> > > Though, I give him a chance to respond to my intention to NMU...
> > An NMU is not the place to "fix" things that the maintainer has
> > specifically said aren't bugs.
> Dear Anthony,
> As stated by the Debian Policy Manual :

I'm not disputing whether it's a bug or not, the maintainer is. If
you are *helping* the maintainer, then fine: do an NMU. 

But if you're specifically trying to do something against their wishes,
do *not*, under any circumstances, NMU. Find a compromise the
maintainer thinks is acceptable, or as a last resort talk to the tech
ctte instead.

To be clear: it's the maintainer that gets to judge whether what you're
doing is helpful or not, not you.

> As complaining to the tech-ctte should not be done becaues I did not
> even try to contact the maintainer directly, I will either:
> - Forget about it, or
> - File a wishlist bug against packages.debian.org, or whatever
>   appropriate, to suggest to stop suggesting the use of a broken
>   package, or at least to mention the bug.

Huh? What's wrong with "- Contact the maintainer" ?

> Sébastien, please fix your bug! Can you imagine Debian if all the
> packages, like yours, would need a manual inspection of the error
> messages to figure out on what it really depends ???

In my experience you almost always get a better response from people if
you assume they've got a good reason for doing what they have been doing,
rather than just trying to add extra punctuation to your sentences.

Admittedly, punctuation is pretty cool...

Cheers,
aj



signature.asc
Description: Digital signature

Re: Need for launchpad

[Steve Langasek]

On Thu, Jan 12, 2006 at 07:36:06AM +, Martin Meredith wrote:
> But, also - and I've had this experience myself - there are some DD's who
> just plain and simple dont want the stuff from ubuntu. I've had a couple
> of times where I've had an issue with a package - and realised it was a
> problem in debian and upstream too. Usually - I've contacted both upstream
> and the DD via Email about this - and have had various responses - for
> example, for one package - I sent about 7 emails over the space of a
> month, emailed upstream, tried to contact the DD on IRC - many a thing -
> but well - no response - and I've tried a couple of times with different
> issues to contact that developer regarding those issues - but have never
> had any awknowledgement, reply etc etc.

Out of curiosity, when emailing these DDs, do you send mail through the BTS?
It's not unknown for developers to filter bts mail differently from mail
sent to their maintainer addresses; and as missing (or over-committed)
maintainers are a constant issue in an org as large as Debian, making sure
information reaches the BTS makes it possible for a future maintainer to
pick up the pieces more readily.

> To me though - and i will stress this highly - I don't think that it's a
> fact that ubuntu isnt contributing to debian - because it is. But I
> believe that some people (maybe a lot of people) for whatever issue aren't
> willing to work either way - as Ubuntu can't do all the work - and nor can
> debian - but - when one side isnt willing to work (I'm not on about
> projects as a whole - I'm on about individual people/maintainers) then it
> spoils the whole thing.

FWIW, here's what I see in practice.  We have Ubuntu saying that they give
back to Debian; and then we have a fairly large divergence between what
Debian has in unstable and what's going into the next Ubuntu release, with
IME very little patch submission to the Debian BTS, plus particular
individuals who are working diligently to make sure their own Ubuntu changes
get integrated effectively into Debian.  I haven't seen anything systematic
that supports the "giving back to Debian" assertion, and I think a lot of
this has to do with Ubuntu's development structures ensuring that re-merging
with Debian is an afterthought, *not* the primary development modality
encouraged by the leadership.

Now, it may be that this is an unrealistic pipe dream on my part that's
incompatible with Ubuntu's goals/release schedule, but it seems to me that
everyone involved would get more mileage out of the "giving-back" process if
there were more emphasis on trying to get changes made in sid *before*
changing things in universe, wherever possible.  I realize there are some
practical issues on the Debian side that would need to be addressed to make
this a reality, and I know there are plenty of cases when Ubuntu won't be
able to wait for Debian before making particular changes, but I think it
would greatly mitigate the concerns over divergence if people viewed
universe as less of a sandbox for innovation than they seem to today.

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


signature.asc
Description: Digital signature

Re: Canonical's business model

[Kevin Mark]

On Thu, Jan 12, 2006 at 09:03:24PM -0200, Gustavo Noronha Silva wrote:
> Having said that, I'd also like to have non-ubuntu-specific patches be
> fed to our BTS; that would really make me feel there's a strong policy
> of giving back. While my relationship with people at ubuntu working on
> gksu is quite good, I still have to look for patches manually sometimes,
> like David Nusinow mentioned, and I have found patches that improved
> debian's gksu this way at least twice. It would have been much better to
> have them filed to the BTS.
> 
> See ya, 
Hi Gustavo,
would it be good for ubuntu to have a user-defined tag, like the BTS
has, for 'ubuntu-specific' or conversly 'non-ubuntu-specific'?
cheers,
Kev
-- 
counter.li.org #238656 -- goto counter.li.org and be counted!
  `$' $' 
   $  $  _
 ,d$$$g$  ,d$$$b. $,d$$$b`$' g$b $,d$$b
,$P'  `$ ,$P' `Y$ $$'  `$ $  "'   `$ $$' `$
$$ $ $$g$ $ $ $ ,$P""  $ $$
`$g. ,$$ `$$._ _. $ _,g$P $ `$b. ,$$ $$
 `Y$$P'$. `YP $$$P"' ,$. `Y$$P'$ $.  ,$.


signature.asc
Description: Digital signature

Re: Development standards for unstable

[Frank Küster]

Jeroen van Wolffelaar <[EMAIL PROTECTED]> wrote:

> That said, I do believe that if a package is unpopular enough that
> nobody picks up maintaining it, even while it's orphaned, what the
> prospects of the package are, and how much use it has to prolong its
> life extraordinary. If you're sufficiently committed to a certain
> package, you can just as well adopt it after all.

Hm, well, no.  I do particularly care for one orphaned package,
lmodern.  But since it currently doesn't have any (real) RC bugs, I have
more important things to do than adopt it on behalf of the
debian-tetex-maint list (or talking Norbert Preining into creating it
from his texlive sources).  If any work is really badly needed, someone
of us will for sure step in;  but that doesn't mean that we're happy to
have the additional burden.  I'd rather have it marked as orphaned, so
that a new maintainer "candidate" can clearly see that it needs care,
than formally adopt it while we can in fact only care for RC bugs[1].


Therefore I don't think that merely being orphaned is a good criterion
for removal; especially not until we make sure that all unmaintained or
badly maintained packages are in fact orphaned.

Regards, Frank


[1] and the important one, which might turn out to be RC
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: Debian Games Team

[Miriam Ruiz]

 --- Eddy Petriºor <[EMAIL PROTECTED]> escribió:

> Can ome packaging can be done for non-free games? (I am thinking about
> a wrapper over the pristine installers/data/ to make the games
> installable through apt-get).

To be honest, I'm not particulary interested in non-free software at all,
including games, but I have nothing against it if we decide as a group to do
so. In my oppinion there's so much work to do about free games that I don't
think it's a good idea giving away our time to non-free projects. Of course,
there's the usual balance to consider between freeness and users-friendliness,
but, as it has happened to other kinds of programs in more critical areas, I
think it might better to concentrate in improving free games than in packaging
non-free stuff, and in the long term it might give better results.

Greetings,
Miry






__ 
LLama Gratis a cualquier PC del Mundo. 
Llamadas a fijos y móviles desde 1 céntimo por minuto. 
http://es.voice.yahoo.com


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

Re: Bug#347849: ITP: easychem -- Draw high-quality molecules and chemical 2D formulas

[Frank Küster]

Chris Peterman <[EMAIL PROTECTED]> wrote:

> Package: wnpp
> Severity: wishlist
>
> * Package name: easychem
>   Version : 0.6 
>   Upstream Author : Francois-Xavier Coudert <[EMAIL PROTECTED]>
> * URL or Web page : http://easychem.sourceforge.net
> * License : GPL
>   Description : Draw high-quality molecules and chemical 2D formulas

You should think of a decent long description; the "Why using EasyChem"
on the website seems to be a good start.  And indicates that the package
seems to be misnomed using the adjective "Easy", maybe "PowerChem" would
be better...

,
| The only tool able to draw press-quality molecules was... xfig, [...]
| To solve this problem [...], I decided to develop my own software:
| EasyChem.
| 
| The problem I see in all existing programs is: they intend to be easy
| to use at first try, kind of a quick-and-dirty approach. EasyChem
| would be a bit difficult to learn, but when you master it, you can be
| very fast, and with a huge precision.
`

Regards, Frank

-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: initramfs-tools backport?

[Joerg Platte]

Am Donnerstag, 12. Januar 2006 23:31 schrieb Norbert Tretkowski:

> It was just uploaded.

Great! Thanks!

regards,
Jörg

-- 
Dipl.-Ing. Jörg Platte
Institut für Roboterforschung - Abteilung Informationstechnik
Universitaet Dortmund | phone:  +49 231-755-6165
Otto-Hahn-Str. 4 (P1-01-116)  | mobile: +49 178-2978865
44221 Dortmund, Germany   | fax:+49 231-755-3251


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

Re: Development standards for unstable

[Thomas Viehmann]

Frank Küster wrote:
> Hm, well, no.  I do particularly care for one orphaned package,
> lmodern.  But since it currently doesn't have any (real) RC bugs, I have
> more important things to do than adopt it on behalf of the
> debian-tetex-maint list (or talking Norbert Preining into creating it
> from his texlive sources).  If any work is really badly needed, someone
> of us will for sure step in;  but that doesn't mean that we're happy to
> have the additional burden.  I'd rather have it marked as orphaned, so
> that a new maintainer "candidate" can clearly see that it needs care,
> than formally adopt it while we can in fact only care for RC bugs[1].

Well, maybe the actual situation would be better reflected if one of the
interested parties adopted the package and retitled the O bug to RFA?

> Therefore I don't think that merely being orphaned is a good criterion
> for removal; especially not until we make sure that all unmaintained or
> badly maintained packages are in fact orphaned.

Can you elaborate on this? I'm not sure how the existence of more
packages that should be orphaned invalidates dealing with those that
presently are.
There's 169 orphaned packages today, why not do something about them?

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


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

Re: Debian Games Team

[Ben Finney]

On 13-Jan-2006, Miriam Ruiz wrote:
>  --- Eddy Petriºor <[EMAIL PROTECTED]> escribió:
> > Can ome packaging can be done for non-free games?
> 
> To be honest, I'm not particulary interested in non-free software at
> all, including games, but I have nothing against it if we decide as
> a group to do so. In my oppinion there's so much work to do about
> free games that I don't think it's a good idea giving away our time
> to non-free projects.

Seconded. This Debian user would be much better pleased by Debian's
efforts going to improving the packaging and coordination of free
software games.

-- 
 \"I took it easy today. I just pretty much layed around in my |
  `\  underwear all day. ... Got kicked out of quite a few places, |
_o__)   though."  -- Bug-Eyed Earl, _Red Meat_ |
Ben Finney <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Re: Development standards for unstable

[Frank Küster]

Thomas Viehmann <[EMAIL PROTECTED]> wrote:

> Well, maybe the actual situation would be better reflected if one of the
> interested parties adopted the package and retitled the O bug to RFA?

Sounds right...

>> Therefore I don't think that merely being orphaned is a good criterion
>> for removal; especially not until we make sure that all unmaintained or
>> badly maintained packages are in fact orphaned.
>
> Can you elaborate on this? I'm not sure how the existence of more
> packages that should be orphaned invalidates dealing with those that
> presently are.
> There's 169 orphaned packages today, why not do something about them?

What I meant is that we would start removing moderately buggy, well
usable packages (just because they are orphaned), but keep badly buggy,
unmaintained packages with lots of annoying bugs - just because nobody
has orphaned them, or because the maintainer only shows up to tell
people to keep their fingers off the package.

When browsing the BTS for a particular question, I frequently run into
packages where I think "this looks like unmaintained".  But often I
don't have time to check whether this is really true.  I assume others
experience the same, and therefore you can't expect every problematic
package to be discussed with care and actually orphaned if found
unmaintained. 

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Bug#347880: ITP: r-cran-eco -- GNU R routines for Bayesian ecological inference

[Chris Lawrence]

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

* Package name: r-cran-eco
  Version : 2.2-1
  Upstream Author : Kosuke Imai and Ying Lu
* URL : http://imai.princeton.edu/research/eco.html
* License : GPL
  Description : GNU R routines for Bayesian ecological inference

 This is a set of routines for GNU R that implement Imai and Lu's
 parametric and nonparametric Bayesian ecological inference algorithms
 using Markov chain Monte Carlo estimation.  Ecological inference is a
 statistical technique designed to recover individual-level information
 from aggregate-level data.
 .
 The suggested r-cran-mcmcpack package includes other EI estimators that
 may be useful alternatives to those included in this package.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15-rc5
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)


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

Re: Debian Games Team

[Martin Meredith]

Ben Finney wrote:
> On 13-Jan-2006, Miriam Ruiz wrote:
> 
>> --- Eddy Petriºor <[EMAIL PROTECTED]> escribió:
>>
>>>Can ome packaging can be done for non-free games?
>>
>>To be honest, I'm not particulary interested in non-free software at
>>all, including games, but I have nothing against it if we decide as
>>a group to do so. In my oppinion there's so much work to do about
>>free games that I don't think it's a good idea giving away our time
>>to non-free projects.
> 
> 
> Seconded. This Debian user would be much better pleased by Debian's
> efforts going to improving the packaging and coordination of free
> software games.
> 
Thirded :D lol - I'd love to participate in this - but more on the side of
"game utilities" like aabrowse :D


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

Re: Getting rid of circular dependencies, stage 3

[Josselin Mouette]

Le jeudi 12 janvier 2006 à 21:12 +0400, Stepan Golosunov a écrit :
> > Looking at them, I fail to see why debconf-i18n has to depend on
> > debconf.
> 
> Because /usr/share/doc/debconf-i18n is a symlink?

Then this is something that can easily be fixed. Not as easily as with
the classical foo -> foo-data dependency, as debconf-english has the
same symlink, but it's possible to keep these directories in the
package. Gaining a few kilobytes on the hard disk to have the changelog
in another package, at the cost of a circular dependency, is too
expensive IMHO.

Regards,
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
   `-  Debian GNU/Linux -- The power of freedom

Re: Need for launchpad

[Thomas Hood]

Steve Langasek wrote:
> FWIW, here's what I see in practice.  We have Ubuntu saying that they
> give back to Debian; and then we have a fairly large divergence
> between what Debian has in unstable and what's going into the next
> Ubuntu release, with IME very little patch submission to the Debian
> BTS, plus particular individuals who are working diligently to make
> sure their own Ubuntu changes get integrated effectively into Debian.


I don't think that patches-submitted-to-the-BTS is a good way to
measure how much Ubuntu is contributing to Debian.  Ubuntu's patches
are readily available:

http://people.ubuntulinux.org/~scott/patches/

If they were submitted to the BTS then that would just create more work
for the Debian maintainer as well as for the Ubuntu maintainer, since
the former would have to tag the report and ensure it gets closed on
the next upload, etc.  Yes, it might be more helpful than the current
breakdown of patches into "changelog" and "packaging" components if
there was a further breakdown into parts suitable for Debian and parts
not suitable for Debian.  However, to perform this breakdown would be
for Ubuntu developers to make judgments about what is suitable for
Debian, and I am sure that such judgments would provoke negative
reactions from Debian developers.

So I think that it is up to Debian maintainers to review the Ubuntu
patches from time to time and to backport what appears to be suitable
for Debian.

I agree that it would be nice if Ubuntu developers tried to get their
changes into sid.  It is certainly not their responsibility to do so,
but in my experience Ubuntu developers have been very cooperative when
they have been approached.  So I don't see a big problem.
-- 
Thomas Hood


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

Re: Debian Games Team

[Eddy Petrişor]

On 1/13/06, Ben Finney <[EMAIL PROTECTED]> wrote:
> > > Can ome packaging can be done for non-free games?
> Seconded. This Debian user would be much better pleased by Debian's
> efforts going to improving the packaging and coordination of free
> software games.

I agree that free software is the priority, but I don't feel that
packaging efforts would be wasted. In any case some experience is
gathered and supporting games like Unreal Tournament, NWN, is not that
hard as they release more rarely than free ones, imho.

PS: I would love to have more free games like quake, but let's face
it, games still are majorly non-free land (I felt this the most when I
changed primary arch to ppc).

--
Regards,
EddyP
=
"Imagination is more important than knowledge" A.Einstein

Bug#347895: ITP: cnet -- A X11 TclTK based network simulator program

[Jesús Espino]

Package: wnpp
Severity: wishlist
Owner: "Jesús Espino" <[EMAIL PROTECTED]>


* Package name: cnet
  Version : 2.0.9
  Upstream Author : Chris McDonald <[EMAIL PROTECTED]> 
* URL : http://www.csse.uwa.edu.au/cnet/
* License : GPL
  Description : A X11 TclTK based network simulator program

 Cnet allows you to simulate data link layer network protocols, by
 programming it in C language. Also, you specify the topology of
 the simulated network.
 .
 Cnet compiles your source and dinamically links it, and the
 simulation begins. It is a graphical program, so you can view
 your simulated packets travelling on your virtual network.

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

Re: Trivial bug on apt-file (Was : Re: Development standards for unstable)

[Henrique de Moraes Holschuh]

On Fri, 13 Jan 2006, Charles Plessy wrote:
> dependancy on curl. However, declaring proper dependancies for the
> package is a "should", not a "must", so if a debian developper is free
> to creating uninstallable packages if he fancies this.

Disclaimer: I am not talking about apt-file.


I sure hope no DDs have such sloppy standards for their work that they would
upload such crap to unstable knowlingly.  Note that transitory dependency
problems are not what we are talking about.


If you are going to violate a _should_ forever, you better be able to
provide a full, acceptable technical explanation for your reasons.  And for
the sake of team work, that also means tagging a bug about the issue as
wontfix, and adding the explanation to the bug logs.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: Dissection of an Ubuntu PR message

[Gustavo Franco]

On 1/13/06, Andrew Suffield <[EMAIL PROTECTED]> wrote:
> On Thu, Jan 12, 2006 at 06:08:52PM -0200, Gustavo Franco wrote:
> > We can't decide how they need to "give us something MORE back" and
> > it's their problem?
>
> Whoever said they need to do that? They just need to stop bragging
> about shit they don't do. There's at least two ways to accomplish this.
>
> If they fail to contribute in a meaningful way, it just means more
> work for them (in trying to maintain a diverging fork). Hence, that's
> their problem. It's not really a problem for us.
>

We can't say that Canonical/Ubuntu isn't contributing back. They're,
as pointed out by some of us. e.g.: David said that Daniel helped him,
but if he did that in his workhours it's under Canonical bless.

It seems that the main problem is how they're handling the list of
patches. If they want to spread the word that they're contributing, it
seems that many of us want to be informed about the patches as we
inform upstreams and not as it's today.

I can't affirm if they're saying more than they're doing, but we are
for sure. I was the only trying to prepare a list of things that we
can ask them to change, and mdz (Ubuntu/Debian) tried to collect
feedback too. We want cooperation, it seems that they want too but
Debian by nature is a complicated project and Ubuntu will never
satisfy all our needs, even for just handling and reporting back some
patches.

With that in mind, it would be good to hear about some internal
discussion in Ubuntu camp too, maybe in the next online meeting or in
London. It will proof that they want to be something different than a
simple fork, as described by mako[0].

[0] = http://mako.cc/writing/to_fork_or_not_to_fork.html  (long)

--
Gustavo Franco

Re: Preparing the m68k port for the future.

[Wouter Verhelst]

Hi,

On Fri, Jan 13, 2006 at 01:21:18PM +1000, Anthony Towns wrote:
> On Thu, Jan 12, 2006 at 07:17:48PM +0100, Wouter Verhelst wrote:
> > Yes, 'm68k' and 'future' in one sentence. Amazing, isn't it? Surely we
> > must be joking?
> 
> Hey, I haven't seen any activity wrt m68k archive (re)qualificiation.

You haven't been looking good enough, then.

> Given m68k's dropped back below the 95% cutoff (and has spent about
> 1/3rd of the last 90 days beneath it) and has a number of red squares
> still on the release arch qualification page it seems certain at this
> point that you won't get a "release arch" exception any time soon.

That's being worked on.

The backlog started because there were not enough build daemons to keep
up with the extra work introduced by the move to GCC4. This has been
remedied in the mean time, and we're back to 0 needs-build on a regular
basis. Also, the extra CPU power that this new port will bring us is
most certainly going to improve our position in that area.

The fact that we're not completely caught up yet has everything to with
a number of toolchain issues that need work. I'm trying to tackle them
one at a time; currently I'm working on #340563 (which was cloned into
#345574 for g++-4.0), and on which I intend to look a bit further
sometime during next week or so. It doesn't help that I'm not all that
familiar with the innards of the gcc and binutils code yet, but then I
expect that by doing more work on such bugs and by doing work on the
coldfire-support will help me to improve in that area.

Your concern is grounded, though, and I'm not entirely confident at this
point that we'll be able to make it, either--help in this area is most
certainly appreciated.

> > Anyway. To cope with the above issues, the m68k port's developers have
> > been looking for alternatives for quite a while now. It has been
> > suggested that we start employing distcc or similar things so that we
> > would be able to use cross-compilers on much faster hardware, but for
> > various reasons this is not practical. 
> 
> BTW, it's not very encouraging when you say "Yes, we'll definitely try
> this and see how it works!" then, six months later, fail to have ever
> bothered, and can only handwave it away as being "impractical".

No, I did try it. I did, however, neglect to bring out the results in
the open. Mea culpa. Here goes:

When I first tried to create this setup, about a month after DebConf5
(and about around the time when I announced this), it turned out that it
was plain impossible to build a cross-compiler with the GCC4 code; not
with toolchain-source (because that had not been updated yet to GCC4, so
would be useless for this purpose) but also not with the upstream source
and the scripts from kegel.com: Some internals of the GCC4 code expected
that the compiler and the binutils would be called 'm68k-linux-foo',
whereas other bits expected 'm68k-linux-gnu-foo'. Obviously this could
be fixed by someone familiar with the gcc/binutils build system, but
that's besides the point; the point is that rolling our own, very
special, setup might introduce extra weaknesses (I had warned in
Helsinki about the possibility that a cross-compiler might not produce
the very exact same object code that a native build would, but had not
considered the possibility that there might be bugs in the build system
which would only occur when trying to build cross-compilers). This would
complicate such a setup further.

Additionally, Ingo told me when the mail about that meeting had come out
that he'd already tried such a setup in the past (I didn't know that
when we were in Helsinki, but it was before that), and that his setup,
IIRC, was in fact slower than a native build because of the overhead of
the network call to start the compiler--At least that's how I recall his
explanation. I don't remember the details; if you have any questions,
please ask him.

Now it might be that with faster hardware (I don't know the specifics of
Ingo's setup; I seem to recall he mentioned a Pentium III-class system
as the distcc host, but I might be delirious) the distcc stuff will
indeed work better, but if such a setup with a not /that/ old system is
already slower than a native build, then I'm not very hopeful that a
distcc setup is going to get us much benefit, while it _will_ give us a
huge overhead.

-- 
.../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/
../ --/ ./ / .--/ ../ -/ / / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/
-.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ /
../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ / -./ ---/ .-../
---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/


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

Re: Preparing the m68k port for the future.

[Wouter Verhelst]

On Fri, Jan 13, 2006 at 02:09:19PM +0100, Wouter Verhelst wrote:
> Hi,
> 
> On Fri, Jan 13, 2006 at 01:21:18PM +1000, Anthony Towns wrote:
> > On Thu, Jan 12, 2006 at 07:17:48PM +0100, Wouter Verhelst wrote:
> > > Yes, 'm68k' and 'future' in one sentence. Amazing, isn't it? Surely we
> > > must be joking?
> > 
> > Hey, I haven't seen any activity wrt m68k archive (re)qualificiation.
> 
> You haven't been looking good enough, then.
> 
> > Given m68k's dropped back below the 95% cutoff (and has spent about
> > 1/3rd of the last 90 days beneath it) and has a number of red squares
> > still on the release arch qualification page it seems certain at this
> > point that you won't get a "release arch" exception any time soon.
> 
> That's being worked on.
> 
> The backlog started because there were not enough build daemons to keep
> up with the extra work introduced by the move to GCC4. This has been
> remedied in the mean time, and we're back to 0 needs-build on a regular
> basis. Also, the extra CPU power that this new port will bring us is

For clarity: s/this new port/the support for the ColdFire/

[...]

-- 
.../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/
../ --/ ./ / .--/ ../ -/ / / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/
-.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ /
../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ / -./ ---/ .-../
---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/


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

Bug#347907: ITP: libobject-signature-perl -- Signature - Generate cryptographic signatures for objects

[Krzysztof Krzyzaniak (eloy)]

Package: wnpp
Severity: wishlist
Owner: "Krzysztof Krzyzaniak (eloy)" <[EMAIL PROTECTED]>

* Package name: libobject-signature-perl
  Version : 1.03
  Upstream Author : Adam Kennedy <[EMAIL PROTECTED]>
* URL : 
http://mirrors.kernel.org/cpan/modules/by-module/Object/Object-Signature-1.03.tar.gz
* License : Perl: Artistic/GPL
  Description : Signature - Generate cryptographic signatures for objects

 Object::Signature is an abstract base class that you can inherit from in
 order to allow your objects to generate unique cryptographic signatures.
 .
 The method used to generate the signature is based on Storable and
 Digest::MD5. The object is fed to "Storable::nfreeze" to get a string,
 which is then passed to Digest::MD5::md5_hex to get a unique 32
 character hexidecimal signature.


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


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

Re: Need for launchpad

[John Hasler]

Thomas Hood writes:
> If they were submitted to the BTS then that would just create more work
> for the Debian maintainer as well as for the Ubuntu maintainer, since the
> former would have to tag the report and ensure it gets closed on the next
> upload, etc.

That's exactly how I want to handle my packages.  If I ever get around to
looking at the Ubuntu stuff and find anything relevant (I don't know if
they use any of my packages) I'll just put them in the BTS myself anyway.

> However, to perform this breakdown would be for Ubuntu developers to make
> judgments about what is suitable for Debian, and I am sure that such
> judgments would provoke negative reactions from Debian developers.

Why?  Don't we expect users to decide which of their local changes are
suitable for Debian?  I sometimes make local changes to Debian packages.
Sometimes I send patches to the BTS and sometimes I decide that the change
is only relevant to my local situation.  Should I instead put them all up
on a Web site and expect the maintainers to sort through them?

I think of Ubuntu as just another (large) user.  If they don't feel like
filing bugs that's fine: it costs me nothing for them to use my work (if
they indeed do).  However, I can't see how putting up patches on a Web site
is better than (or even as good as) filing bug reports.

> So I think that it is up to Debian maintainers to review the Ubuntu
> patches from time to time and to backport what appears to be suitable for
> Debian.

Again, why should Ubuntu's patches be handled any differently than those of
other users?

> I agree that it would be nice if Ubuntu developers tried to get their
> changes into sid.  It is certainly not their responsibility to do so, but
> in my experience Ubuntu developers have been very cooperative when they
> have been approached.  So I don't see a big problem.

I don't either.  After all, most users don't file bug reports, and Ubuntu
is (in my view), a user.  It would be nice to have their feedback since it
is likely to be useful and of high quality, but we can live without it.
-- 
John Hasler


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

Re: Preparing the m68k port for the future.

[Ingo Juergensmann]

On Fri, Jan 13, 2006 at 02:09:19PM +0100, Wouter Verhelst wrote:

> Additionally, Ingo told me when the mail about that meeting had come out
> that he'd already tried such a setup in the past (I didn't know that
> when we were in Helsinki, but it was before that), and that his setup,
> IIRC, was in fact slower than a native build because of the overhead of
> the network call to start the compiler--At least that's how I recall his
> explanation. I don't remember the details; if you have any questions,
> please ask him.

Uhm, well, yes, I tried a distcc setup on m68k. Actually it's the opposite: 
Of course there's a overhead via network (I was using two m68ks with 450 km
and 2 DSL dialups inbetween), but the test (kernel compile) showed approx. a
total of 40-50% gain in build time. M68ks (well, Amigas at least) only have
10 Mbps NICs, so you won't have much faster transfers than 300-500 kB/s
between hosts anyway. 
The m68k distcc worked quite well, but when I tried to setup a cross-distcc
it failed on the crosscc side. Somehow the generation of the need cross
files failed. Can't remember the specifics anymore. 
 
> Now it might be that with faster hardware (I don't know the specifics of
> Ingo's setup; I seem to recall he mentioned a Pentium III-class system

It was a PowerPC G4 1 GHz. ;)

> as the distcc host, but I might be delirious) the distcc stuff will
> indeed work better, but if such a setup with a not /that/ old system is
> already slower than a native build, then I'm not very hopeful that a
> distcc setup is going to get us much benefit, while it _will_ give us a
> huge overhead.

I think, distcc will be nice for such things like qt-x11 and other long
building stuff. For packages with shorter build times (<1 hour or so) I
don't see much gain, because the installation and removal of build-deps will
take the most time and distcc certainly can't help there. ;)
The benefit of distcc would be, that we can add flawlessly more CPU power
whenever needed, but don't need to when there's no backlog, so we can build
natively. 

The main showblocker with that is that package building doesn't support "make
-jX" yet. I think other archs with SMP support might benefit as well when
there would be a way to support this feature... 

-- 
Ciao...//Fon: 0381-2744150 
  Ingo   \X/ SIP: [EMAIL PROTECTED]

gpg pubkey: http://www.juergensmann.de/ij/public_key.asc


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

Re: Preparing the m68k port for the future.

[Wouter Verhelst]

On Fri, Jan 13, 2006 at 02:38:02PM +0100, Ingo Juergensmann wrote:
> On Fri, Jan 13, 2006 at 02:09:19PM +0100, Wouter Verhelst wrote:
> > Additionally, Ingo told me when the mail about that meeting had come out
> > that he'd already tried such a setup in the past (I didn't know that
> > when we were in Helsinki, but it was before that), and that his setup,
> > IIRC, was in fact slower than a native build because of the overhead of
> > the network call to start the compiler--At least that's how I recall his
> > explanation. I don't remember the details; if you have any questions,
> > please ask him.
> 
> Uhm, well, yes, I tried a distcc setup on m68k. Actually it's the opposite: 
> Of course there's a overhead via network (I was using two m68ks with 450 km
> and 2 DSL dialups inbetween), but the test (kernel compile) showed approx. a
> total of 40-50% gain in build time.
[...]

Ah. Hmm. Well, then I must have misremembered somehow. Sorry about that.

That would indeed change a few things, of course. But, still, I do think
that the ability to start using hardware that is 4-8 times the speed of
what we currently have is a better way to improve the average speed of
our build daemons than to start using complex setups such as distcc. If
that turns out to not be enough, we can still try distcc then.

-- 
.../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/
../ --/ ./ / .--/ ../ -/ / / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/
-.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ /
../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ / -./ ---/ .-../
---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/


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

Re: Need for launchpad

[cobaco (aka Bart Cornelis)]

On Friday 13 January 2006 12:04, Thomas Hood wrote:
> I agree that it would be nice if Ubuntu developers tried to get their
> changes into sid.  It is certainly not their responsibility to do so,

It isn't? Presumably they're that ones that want to remain close to Debian 
(as any divergence means more work for them?)? So how is it the Debian 
maintainers responsibility to go hunting for usefull patches? 

Debian maintainers for the most part would love to not have to duplicate 
work already done by Ubuntu. But at the moment I've seen lots of comments 
by maintainers saying that in most cases it's currently more work to find 
out if there's any usefull bits in the diffs between debian-ubuntu 
packages, then to do the work themselves (for various reasons, which have 
been mentioned before)

> but in my experience Ubuntu developers have been very cooperative when
> they have been approached.  So I don't see a big problem.

Ah, here we come to the heart of the problem: "when they have been 
approached", this clearly points to the fact that the initiative for 
synchronization between ubuntu and debian lies with Debian not Ubuntu (by 
and large, some exceptions have been mentioned).

In the mean while Ubuntu proudly calls "ubuntu gives things back", whereas 
in reality we mostly have a situation of "ubuntu will help debian 
maintainers that want to take things back"

-> It's this misrepresentation of where (most of) the initiative lies which
   pisses people off.
-- 
Cheers, cobaco (aka Bart Cornelis)
  
1. Encrypted mail preferred (GPG KeyID: 0x86624ABB)
2. Plain-text mail recommended since I move html and double
format mails to a low priority folder (they're mainly spam)


pgp0THzWMuhMm.pgp
Description: PGP signature

Re: Preparing the m68k port for the future.

[Geert Uytterhoeven]

On Fri, 13 Jan 2006, Ingo Juergensmann wrote:
> On Fri, Jan 13, 2006 at 02:09:19PM +0100, Wouter Verhelst wrote:
> The main showblocker with that is that package building doesn't support "make
> -jX" yet. I think other archs with SMP support might benefit as well when
> there would be a way to support this feature... 

Enabling `-j' will probably expose concurrency problems in the build system for
lots of packages.

What about building different packages in parallel instead?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


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

Re: Debian Games Team

[Brian Powell]

I also would be interested in getting involved in this project. I
believe there is much room to grow in the area of gaming, and since I
am an avid gamer myself using both "Free" and "Non-Free" games on my
Debian systems I would love to help out where I can.

Regards,
Brian PowellOn 1/13/06, Miriam Ruiz <[EMAIL PROTECTED]> wrote:
Hi,We've been recently talking about creating a group to maintain games in Debianin a collaborative way. As a starting point, I've created a mailing list inalioth for coordination, and also for create discussion threads about the main
problems related to game development and games packages in Debian. You canjoin that list at:http://lists.alioth.debian.org/mailman/listinfo/pkg-games-devel
Here are some points that might be addressed by this group if there isinterested in it:- Maintaining games collaboratively, as they tend to share many points incommon.- "Scale economy" benefits: maintaining more packages, quicker an with less
effort.- Open a way towards a larger involvement in Debian project to peoplemaintaining just one or few games.- Quick-fixing of security issues common to games.- Discussion of problems and facts relative to game packaging.
- Discussion of how to DFGS might be interpreted regarding multimedia contentsand artwork in games.- Identify important games that are not packaged yet and package them.- Identify games that we were only maintainig out of inertia, and consider
dropping them- Make it easier for users to know the games available in Debian, maybe withsome game selector interface, a web page, screenshots or whatever.You're welcome to join the group, or say whatever you think about this
project.Greetings,Miry__LLama Gratis a cualquier PC del Mundo.Llamadas a fijos y móviles desde 1 céntimo por minuto.
http://es.voice.yahoo.com--To UNSUBSCRIBE, email to [EMAIL PROTECTED]with a subject of "unsubscribe". Trouble? Contact 
[EMAIL PROTECTED]-- Regards,Brian Powell-= Debian GNU/Linux =-  http://debian.org

Re: Anthony Towns: What I did today

[Martin Zobel-Helas]

Hi AJ,

On Friday, 13 Jan 2006, you wrote:
> Things I did today:
> 
> 2. Removed the empty SuperH architecture from the archive (binary-sh).
> 
> Coincidence? You decide.
> 
> URL: http://azure.humbug.org.au/~aj/blog/2006/01/13#2006-01-13-sh-irts

Nice you have done this, but Planet is definitely not the correct place
to document changes like this. I would find it more appropriate to
inform fellow DDs either via debian-devel@ or [EMAIL PROTECTED] Not all
developers read planet.debian.org.

To get that clear, i don't want to criticize you removed unneeded SuperH
architecture from the archive, but where you document changes like this.

Greetings
Martin

PS: CC'ed -devel to get fellow developers informed about your changes.


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

Re: libecw

[Henning Makholm]

Scripsit Miriam Ruiz <[EMAIL PROTECTED]>

> I'm not sure if it's license (
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=293346 ) can be considered
> free enough to be in main:

[...]

> ii)   When modifications to the Software are released under this license, a
> non-exclusive royalty-free right is granted to the initial 
> developer of the Software to distribute your modification in future versions
> of the Software provided such versions remain available under 
> these terms in addition to any other license(s) of the initial developer. 

This is controversial at best.

> iii)  You are not permitted to change the ECW file format.

This, however, directly kills DFSG-freedom as well as GPL compatibility.

If the library is actually linked with GPL code, as the authors seem
to expect, the entire think becomes legally undistributable even in
non-free.

-- 
Henning Makholm   "Hi! I'm an Ellen Jamesian. Do
you know what an Ellen Jamesian is?"


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

Re: Need for launchpad

[Thomas Hood]

John Hasler wrote:
> I can't see how putting up patches on a Web site is better than
> (or even as good as) filing bug reports.


The web site requires less labor to maintain than hundreds of bug reports.


> Again, why should Ubuntu's patches be handled any differently than
> those of other users?


In short: because Ubuntu isn't just another user, but a whole distribution.


cobaco wrote:
> So how is it the Debian maintainers responsibility to go hunting for
> usefull patches? 


I did not say that it is a DD's responsibility to go hunting for patches.
As is well known, Debian developers don't have responsibilities
(Constitution article 2.1).  However, if a particular Debian Developer
feels motivated to improve his package then he'd be well advised to
examine what Ubuntu has done to it.

Transfer of information requires two parties: a provider and a recipient.
Ubuntu, the provider, has published its changes.  The transfer can only
be completed when the receiver is ready to receive, but this is not
always the condition of Debian maintainers.  So it is efficient if the
transfer take place on the initiative of the latter.  Once he or she is
ready, he or she doesn't have to "hunt", because the patches are all at
a known location.

http://people.ubuntulinux.org/~scott/patches/


> Ah, here we come to the heart of the problem: "when they have been 
> approached", this clearly points to the fact that the initiative
> for synchronization between ubuntu and debian lies with Debian not
> Ubuntu (by and large, some exceptions have been mentioned).


Right.


> In the mean while Ubuntu proudly calls "ubuntu gives things back",
> whereas in reality we mostly have a situation of "ubuntu will help
> debian maintainers that want to take things back"


I don't see a profound difference between "helping to take" and "giving".
Perhaps what you want is "giving on a silver platter"?


> -> It's this misrepresentation of where (most of) the initiative lies
> which pisses people off.


I think that people are pissed off for other reasons.  (But I admit
that I can only speculate.  I can't read people's hearts and minds.)

Suppose Ubuntu were to cease claiming[0] that it gives back to Debian.
Would everyone be happy then?  I doubt it.

[0] Here: http://ubuntu.com/ubuntu/relationship?highlight=%28debian%29
there's a claim that "they send their bugfixes to the Debian developers
responsible for that package in debian and record the patch URL in the
debian bug system."
-- 
Thomas Hood


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

Re: Getting rid of circular dependencies, stage 3

[Dominique Dumont]

Adrian von Bidder <[EMAIL PROTECTED]> writes:

> From a graph algorithm point of view, if I'm not very mistaken,
> dependencies being guaranteed to be a directed graph instead of a
> generic graph should allow some simplifications/efficiency
> improvements in apt and other tools, too.

For the record, dependencies are a directed graph by nature. 

Preventing circular dependencies will get you a directed acyclic graph
(DAG) which is, IMHO, easier to handle.

HTH
-- 
Dominique Dumont 
"Delivering successful solutions requires giving people what they
need, not what they want." Kurt Bittner


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

Re: Dissection of an Ubuntu PR message

[David Nusinow]

On Fri, Jan 13, 2006 at 10:45:48AM -0200, Gustavo Franco wrote:
> We can't say that Canonical/Ubuntu isn't contributing back. They're,
> as pointed out by some of us. e.g.: David said that Daniel helped him,
> but if he did that in his workhours it's under Canonical bless.

Please stop trying to twist my words around. Canonical didn't contribute
back. An individual who happened to work for Canonical did. If someone
employed by the US government contributes to Debian of his own volition do
we say that the US government gives back to Debian? Do we say that your
employer gives back to Debian?

 - David Nusinow


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

Re: Need for launchpad

[cobaco (aka Bart Cornelis)]

On Friday 13 January 2006 16:27, Thomas Hood wrote:
> John Hasler wrote:
> > I can't see how putting up patches on a Web site is better than
> > (or even as good as) filing bug reports.
>
> The web site requires less labor to maintain than hundreds of bug
> reports.

for Ubuntu that's true, for the Debian maintainer it's not

> However, if a particular Debian Developer 
> feels motivated to improve his package then he'd be well advised to
> examine what Ubuntu has done to it.

I've seen comments from maintainers that tried this and stopped doing so 
because it turned out to be more work then (re)doing things themself. 

The number of such comments I've come acrosss would lead me to believe that 
at the very least the ubuntu patch publishing needs (significant) work to 
be usefull in the majority of cases. So at the moment I'd say the above 
statement is false.

> Transfer of information requires two parties: a provider and a recipient.
> Ubuntu, the provider, has published its changes.  The transfer can only
> be completed when the receiver is ready to receive, but this is not
> always the condition of Debian maintainers.  

> So it is efficient if the transfer take place on the initiative of the
> latter.  Once he or she is ready, he or she doesn't have to "hunt", 
because the patches are all at a known location.

as documented experience by maintainers who've tried that shows, this is 
inefficient enough that reimplementing is mostly faster (and definately 
more attractive, as it involves less drudgework)

-> ubuntu needs to improve efficiency _for_debian_maintainers_ if it wants
   them to use their patches (if it doesn't that's fine, though not ideal,
   from a Debian perspective)

> > Ah, here we come to the heart of the problem: "when they have been
> > approached", this clearly points to the fact that the initiative
> > for synchronization between ubuntu and debian lies with Debian not
> > Ubuntu (by and large, some exceptions have been mentioned).
>
> Right.
>
> > In the mean while Ubuntu proudly calls "ubuntu gives things back",
> > whereas in reality we mostly have a situation of "ubuntu will help
> > debian maintainers that want to take things back"
>
> I don't see a profound difference between "helping to take" and "giving".
> Perhaps what you want is "giving on a silver platter"?

the difference is the one between push and pull, i.e. were the initiative 
lies. And Ubuntu is claiming it's pushing things where it's not. 

-> Ubuntu not pushing things is just ducky in itself. 
-> Ubuntu doing so while sayingthey are is _not_ okay (and that's the
   impression a lot DD's seem to have right now)

> > -> It's this misrepresentation of where (most of) the initiative lies
> > which pisses people off.
>
> I think that people are pissed off for other reasons.  (But I admit
> that I can only speculate.  I can't read people's hearts and minds.)
>
> Suppose Ubuntu were to cease claiming[0] that it gives back to Debian.
> Would everyone be happy then?  

I'm pretty sure people would be happier with one of the following:
- Ubuntu actually doing what it's claiming (i.e. pushing changes to debian)
- Ubuntu stop the claiming

take your pick.

-- 
Cheers, cobaco (aka Bart Cornelis)
  
1. Encrypted mail preferred (GPG KeyID: 0x86624ABB)
2. Plain-text mail recommended since I move html and double
format mails to a low priority folder (they're mainly spam)



pgpevJbtDV4zh.pgp
Description: PGP signature

Re: Debian Games Team

[Ben Armstrong]

On Fri, 2006-01-13 at 09:15 +0100, Andreas Tille wrote:
> On Fri, 13 Jan 2006, Miriam Ruiz wrote:
> 
> > We've been recently talking about creating a group to maintain games in 
> > Debian
> > in a collaborative way.
> 
> Are you aware of the Debian-Junior project.

Thanks for bringing this thread to my attention, Andreas, or I would
have missed it.

Miriam, I'm interested in your project and am joining the list to
contribute ideas relating to Debian Jr.

Ben


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

Re: Trivial bug on apt-file (Was : Re: Development standards for unstable)

[Anthony Towns]

On Fri, Jan 13, 2006 at 10:39:01AM -0200, Henrique de Moraes Holschuh wrote:
> On Fri, 13 Jan 2006, Charles Plessy wrote:
> > dependancy on curl. However, declaring proper dependancies for the
> > package is a "should", not a "must", so if a debian developper is free
> > to creating uninstallable packages if he fancies this.

Err, what? The RC issues for etch thing lists:

Packages must include a "Depends:" line listing any other
packages they require for operation, unless those packages are
marked "Essential: yes". Packages must include a "Pre-Depends:"
line listing any packages required by their preinst.

so violating that is definitely RC. 3.5 of policy uses "must", not should.
In apt-file's case, the maintainer is claiming the current dependencies
are correct, aiui.

> If you are going to violate a _should_ forever, you better be able to
> provide a full, acceptable technical explanation for your reasons.  And for
> the sake of team work, that also means tagging a bug about the issue as
> wontfix, and adding the explanation to the bug logs.

Yes, this RC bug fetish is absurd; we should be spending our time on these
"shoulds", because the "musts" are already fixed... :-/

Cheers,
aj




signature.asc
Description: Digital signature

Re: Preparing the m68k port for the future.

[Anthony Towns]

On Fri, Jan 13, 2006 at 02:09:19PM +0100, Wouter Verhelst wrote:
> On Fri, Jan 13, 2006 at 01:21:18PM +1000, Anthony Towns wrote:
> > On Thu, Jan 12, 2006 at 07:17:48PM +0100, Wouter Verhelst wrote:
> > > Yes, 'm68k' and 'future' in one sentence. Amazing, isn't it? Surely we
> > > must be joking?
> > Hey, I haven't seen any activity wrt m68k archive (re)qualificiation.
> You haven't been looking good enough, then.

Put it in the wiki along with everyone else where it's obvious.

> > Given m68k's dropped back below the 95% cutoff (and has spent about
> > 1/3rd of the last 90 days beneath it) and has a number of red squares
> > still on the release arch qualification page it seems certain at this
> > point that you won't get a "release arch" exception any time soon.
> That's being worked on.

That's fine, but it's irrelevant -- you need to be able to demonstrate
you can keep up consistently for at least a three month period; at the
moment you seem to be at least four months away from that, given how long
it seems to take m68k to catch back up. That's fine, and there's no reason
why m68k can't demonstrate that Debian can effectively maintain a "toy"
or "embedded" or whathaveyou port that's *not* intended to release.
But it does mean you've got no chance of a release requalification
anytime soon, which means you need to be proactive about getting an
archive qualification done.

Cheers,
aj



signature.asc
Description: Digital signature

Re: Anthony Towns: What I did today

[Anthony Towns]

On Fri, Jan 13, 2006 at 04:22:50PM +0100, Martin Zobel-Helas wrote:
> On Friday, 13 Jan 2006, you wrote:
> > Things I did today:
> > 2. Removed the empty SuperH architecture from the archive (binary-sh).
> > Coincidence? You decide.
> > URL: http://azure.humbug.org.au/~aj/blog/2006/01/13#2006-01-13-sh-irts
> Nice you have done this, but Planet is definitely not the correct place
> to document changes like this. I would find it more appropriate to
> inform fellow DDs either via debian-devel@ or [EMAIL PROTECTED] Not all
> developers read planet.debian.org.

I think you'll find the correct place is the -sh list, which was notified:

http://lists.debian.org/debian-superh/2002/04/msg00010.html

The "sh" arch in unstable has consisted of "Architecture: all" packages only
since then.

HTH, HAND.

Cheers,
aj


signature.asc
Description: Digital signature

Re: Dissection of an Ubuntu PR message

[Matthew Garrett]

David Nusinow <[EMAIL PROTECTED]> wrote:

> Please stop trying to twist my words around. Canonical didn't contribute
> back. An individual who happened to work for Canonical did. If someone
> employed by the US government contributes to Debian of his own volition do
> we say that the US government gives back to Debian? Do we say that your
> employer gives back to Debian?

If it's an authorised use of company time, sure. Whether or not it is in
this case, I don't know.

-- 
Matthew Garrett | [EMAIL PROTECTED]


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

Re: Need for launchpad

[Tony Godshall]

...

> Suppose Ubuntu were to cease claiming[0] that it gives back to Debian.
> Would everyone be happy then?  I doubt it.

Is your goal to make everybody happy or be truthful?


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

Re: Dissection of an Ubuntu PR message

[Gustavo Franco]

On 1/13/06, Matthew Garrett <[EMAIL PROTECTED]> wrote:
> David Nusinow <[EMAIL PROTECTED]> wrote:
>
> > Please stop trying to twist my words around. Canonical didn't contribute
> > back. An individual who happened to work for Canonical did. If someone
> > employed by the US government contributes to Debian of his own volition do
> > we say that the US government gives back to Debian? Do we say that your
> > employer gives back to Debian?
>
> If it's an authorised use of company time, sure. Whether or not it is in
> this case, I don't know.
>

Exactly my point Matthew, and calm down David, i wrote: "e.g.: David
said that Daniel helped him, but if he did that in his workhours it's
under Canonical bless.". Do you see ? I just pointed out that there's
a possibility that he was helping you in his workhours, but i won't
cite you as a reference anymore.

--
Gustavo Franco

Re: packages.debian.org service stop ?

[Adam D. Barratt]

On Thursday, January 12, 2006 11:59 PM, Junichi Uekawa
<[EMAIL PROTECTED]> wrote:

> Hi,
>
> I've dug out some information from IRC logs:
>
> saens was overloaded around 5 Jan 2006, with load average of 140 or
> something, and eventually apache stopped.  Since saens is one of
> ftp.debian.org, it had a large impact, and packages.debian.org is
> disabled temporarily as a workaround.

FWIW, the same information is detailed in
http://lists.debian.org/debian-project/2006/01/msg00035.html.

Cheers,

Adam


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

Re: Preparing the m68k port for the future.

[Wouter Verhelst]

On Sat, Jan 14, 2006 at 01:42:32AM +1000, Anthony Towns wrote:
> On Fri, Jan 13, 2006 at 02:09:19PM +0100, Wouter Verhelst wrote:
> > On Fri, Jan 13, 2006 at 01:21:18PM +1000, Anthony Towns wrote:
> > > On Thu, Jan 12, 2006 at 07:17:48PM +0100, Wouter Verhelst wrote:
> > > > Yes, 'm68k' and 'future' in one sentence. Amazing, isn't it? Surely we
> > > > must be joking?
> > > Hey, I haven't seen any activity wrt m68k archive (re)qualificiation.
> > You haven't been looking good enough, then.
> 
> Put it in the wiki along with everyone else where it's obvious.
> 
> > > Given m68k's dropped back below the 95% cutoff (and has spent about
> > > 1/3rd of the last 90 days beneath it) and has a number of red squares
> > > still on the release arch qualification page it seems certain at this
> > > point that you won't get a "release arch" exception any time soon.
> > That's being worked on.
> 
> That's fine, but it's irrelevant 

I beg to differ.

> -- you need to be able to demonstrate you can keep up consistently for
> at least a three month period; at the moment you seem to be at least
> four months away from that, given how long it seems to take m68k to
> catch back up.

I can't make time go faster. All I can do is make sure the problems do
not come back, which I am trying to do as far as is possible.

> That's fine, and there's no reason why m68k can't demonstrate that
> Debian can effectively maintain a "toy" or "embedded" or whathaveyou
> port that's *not* intended to release.

I'm not sure I correctly parse that sentence.

> But it does mean you've got no chance of a release requalification
> anytime soon, which means you need to be proactive about getting an
> archive qualification done.

The point of my previous mail was to demonstrate that I am, in fact,
trying to be proactive about getting the qualification done.

Of course, we all have real life that does get in the way from time to
time. Don't you?

-- 
.../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/
../ --/ ./ / .--/ ../ -/ / / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/
-.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ /
../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ / -./ ---/ .-../
---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/


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

Re: Mirror split stuff

[Ivo Encarnacao]

On 1/13/06, Anthony Towns  wrote:
> Hey all,
>
> First, the executive summary for mirror operators reading this: we'll be
> switching the primary mirror stuff for Debian to be for a small number
> of architectures rather than all of them; initially this will just be
> i386, but will probably expand to include amd64. Single architecture
> mirrors appear to need about 60GB of disk space, dual architecture
> mirrors will need about 80GB of disk space. A full mirror at the moment
> requires slightly over 170GB. We'll be trying to get in touch with you
> all further over the next week or two to make sure the changes go as
> smoothly as possible.
>
> Second, there's a call for help down below. Particularly for people with
> some web programming skillz.
>
> Okay, so!
>
> You've probably heard about this mirror split thing, also known as "scc",
> "second class citizens", and "the evil plot by the cabal to make poor
> blighted amd64 developers and users suffer unduly".
>
> At present, most mirrors mirror all the archive, and at present almost all
> Debian users that use those mirrors use i386 [0]. But with the archive
> growing almost daily (recently breaking the 170GB mark, up from 130GB
> in July iirc), and mirrors often finding it hard to keep up, that's a
> bad tradeoff. That tradeoff becomes even worse when we're unwilling to
> add interesting new architectures because of the immediate increase in
> archive size they cause, in addition to the ongoing accretion.
>
> So obviously that tradeoff's changing in favour of partial mirrors,
> particularly by architecture.
>
> People have been able to do partial mirrors for a while now, and the
> anonftpsync [1] tool we offer includes explicit support for that. In
> further support of partial mirrors, we'll be doing these things:
>
> (a) allowing and in some cases encouraging official mirrors to
> mirror a limited number of archictures
>
> (b) limiting ftp.debian.org to i386 only (probably to also
> include amd64, depending on how popular that architecture
> actually is)
>
> (c) providing simple recommendations on running arch-specific
> mirrors
>
> (d) providing ..mirror.debian.org aliases to make it
> easy for users to find a local mirror that supports their
> preferred architecture
>
> As well as allowing additional architectures, these changes should
> make it plausible to think about a few other things, notably including
> additional suites in the archive (such as "volatile" or "backports"),
> and having the archive pulse occur more frequently than daily.
>
> But one of the things all this stuff requires is some good communication
> with our mirrors. That can use some work at the moment, and one thing
> that would be particularly helpful is some better tracking of who's
> mirroring what. At present we have the "Mirrors masterlist" [2], the
> mirrors pseudopackage on the BTS [3] (and its corresponding mailing list,
> which has public archives on master [4]) and the Debian mirror checker
> [5].
>
> What would be helpful would to improve our tracking stuff so that:
>
> (a) the mirror checker can provide more detailed information on
> mirror stability such as that offered by the apache tracker [6]
>
> (b) the mirror checker script can verify which architectures a
> mirror actually carries
>
> (c) there's some easy way for mirror admins to add, remove and
> update their details in the masterlist, rather than waiting
> for a developer to review the changes (with additions
> confirmed automatically by the checker, ideally)
>
> (d) there are status fields to indicate whether the mirror supports
> pushing downstream mirrors by ssh trigger, in the same manner as
> the top level Debian mirrors
>
> (e) what mirror each mirror mirrors from (ideally checked
> automatically by looking in project/trace; and ideally with
> a pretty graph generated from the data, highlighting mirrors
> that are out of date)
>
> (f) whether the mirror is able to accept *.mirror.debian.org
> requests, so that if, eg, "at.alpha.mirror.debian.org"
> goes down, it can automatically be pointed at another site
> in Austria, or if none are available, another nearby alpha
> mirror.
>
> But that's not really something I'm good at, and the existing folks working
> on organising the mirrors haven't had time to magic it up either, so if other
> folks would like to try their hand at whipping something up that can be
> made official that'd be great.
>
> Having it be something that can be run with minimal priveleges, not
> require PHP or a large framework, something that supports the existing
> Mirrors masterlist format for input and output, and be something that
> is written to run efficiently would 

Re: Preparing the m68k port for the future.

[Graham Wilson]

On Fri, Jan 13, 2006 at 03:05:10PM +0100, Geert Uytterhoeven wrote:
> Enabling `-j' will probably expose concurrency problems in the build
> system for lots of packages.
> 
> What about building different packages in parallel instead?

Isn't that what is done currently?

-- 
gram


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

Re: Getting rid of circular dependencies, stage 3

[Adrian von Bidder]

On Friday 13 January 2006 16:53, you wrote:
> Adrian von Bidder <[EMAIL PROTECTED]> writes:
> > From a graph algorithm point of view, if I'm not very mistaken,
> > dependencies being guaranteed to be a directed graph instead of a
> > generic graph should allow some simplifications/efficiency
> > improvements in apt and other tools, too.
>
> For the record, dependencies are a directed graph by nature.
>
> Preventing circular dependencies will get you a directed acyclic graph
> (DAG) which is, IMHO, easier to handle.

Arrgh.  Of course, just a confusion of terms.

cheers
-- vbi

-- 
F: Was ist ein Pensch?
A: Das mittlere Stück von einem Lam-pensch-irm


pgp7OK8BFipey.pgp
Description: PGP signature

Re: Preparing the m68k port for the future.

[Anthony Towns]

On Fri, Jan 13, 2006 at 06:04:00PM +0100, Wouter Verhelst wrote:
> > > > Given m68k's dropped back below the 95% cutoff (and has spent about
> > > > 1/3rd of the last 90 days beneath it) and has a number of red squares
> > > > still on the release arch qualification page it seems certain at this
> > > > point that you won't get a "release arch" exception any time soon.
> > > That's being worked on.
> > That's fine, but it's irrelevant 
> I beg to differ.

Huh? You can differ all you like, but that doesn't make it any more
relevant.

> > -- you need to be able to demonstrate you can keep up consistently for
> > at least a three month period; at the moment you seem to be at least
> > four months away from that, given how long it seems to take m68k to
> > catch back up.
> I can't make time go faster. 

No, you can't. But in the meantime you need to demonstrate that m68k is
actually worth keeping in the archive, otherwise it'll be replaced by
amd64 which has qualified as a release candidate, and kfreebsd-i386 and
any other architectures which are able to demonstrate their usefulness.

I mean, come on, surely you can demonstrate you're more useful than
Hurd and GNU/kfreebsd. Hurd hasn't even been able to compile vim for a
year! These aren't exactly high bars...

> > But it does mean you've got no chance of a release requalification
> > anytime soon, which means you need to be proactive about getting an
> > archive qualification done.
> The point of my previous mail was to demonstrate that I am, in fact,
> trying to be proactive about getting the qualification done.

The way you demonstrate a commitment to getting archive qualification done
is filling out a page on the wiki like:

http://wiki.debian.org/ArchiveQualification/hurd-i386
http://wiki.debian.org/ArchiveQualification/kfreebsd-i386

> Of course, we all have real life that does get in the way from time to
> time. Don't you?

According to the release qualification page for m68k there are four
other m68k port maintainers who could also be doing this.

The fact you don't have anyone able to make a working cross-compiler
speaks somewhat poorly of the support available for the m68k toolchain,
too.

Cheers,
aj



signature.asc
Description: Digital signature

Re: Trivial bug on apt-file (Was : Re: Development standards for unstable)

[Luk Claes]

Anthony Towns wrote:
> On Thu, Jan 12, 2006 at 06:48:38PM +0100, Luk Claes wrote:
> 
>>>But if you read this bug (#307833), you'd see that the maintainer doesn't
>>>consider it a bug, and has documented why in the README file.
>>
>>It is a bug as the package is not usable without curl or wget installed.
>>Though, I give him a chance to respond to my intention to NMU...
> 
> 
> An NMU is not the place to "fix" things that the maintainer has
> specifically said aren't bugs.

Well the maintainer doesn't tag the bugs wontfix nor closes them all, so
he probably thinks it *are* bugs that don't need immediate attention?

>>>You could of course disagree about whether it's a bug or not, but in that
>>>case, you would want to appeal to the tech-ctte, not debian-devel.
>>
>>...before going to the Technical Committee.
> 
> 
> I'm sure Florian'll be giving you a serve for being so threatening any
> moment now...

Sorry, I don't meant to threaten anyone, I was just saying that I first
want to try all other means before I would consider going to the
Technical Committee.

Cheers

Luk

-- 
Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D
Fingerprint:   D5AF 25FB 316B 53BB 08E7   F999 E544 DE07 9B7C 328D


signature.asc
Description: OpenPGP digital signature

Re: French cheese

[Christian Perrier]

Quoting Matt Zimmerman ([EMAIL PROTECTED]):

> Unfortunately, this conflicts with a development sprint we're having in
> London, so that won't be possible at that time.
> 
> My heart breaks at the prospect of a missed opportunity to gorge myself on
> cheese...


Well, it's just a matter of jumping in the first Eurostar in the
morning, be at Gare du Nord around 8 or 9, go to Solutions Linux,
drink, talk and eat cheese all day long with fellow Debian and Ubuntu
people, then jump in another Eurostar back to London (with some cheese
in your luggage) and be back for hacking with your fellow Ubuntu
people late in the night.

And, for next year, just plan your development sprint in Paris..:-)
(I'm half-serious and even really serious here)





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

Re: Debian Games Team

[Luk Claes]

Miriam Ruiz wrote:
> Hi,

Hi Miriam

> We've been recently talking about creating a group to maintain games in Debian
> in a collaborative way. As a starting point, I've created a mailing list in
> alioth for coordination, and also for create discussion threads about the main
> problems related to game development and games packages in Debian. You can
> join that list at:
[...]
> You're welcome to join the group, or say whatever you think about this
> project.

I think it's a marvellous idea as gaming is one of the aspects that is
IMHO still underrepresented in Debian :-)

Cheers

Luk

-- 
Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D
Fingerprint:   D5AF 25FB 316B 53BB 08E7   F999 E544 DE07 9B7C 328D


signature.asc
Description: OpenPGP digital signature

Re: Development standards for unstable

[Raphael Hertzog]

On Thu, 12 Jan 2006, Andreas Barth wrote:
> One can try to come up with some metric, yes.
> 
> However, on the other hand feel free to create a "common maintained
> packages team" that adopts such packages :)

This may happen sooner that one may think.

The project "collab-maint" on alioth is actually empty but it will be used
for that purpose ... possibly starting with packages created by Ubuntu's
MOTU which are of generic interest for Debian too.

http://wiki.debian.org/CollaborativeMaintenance

This proposal has recently been discussed in the last Ubuntu MOTU meeting
and hopefully something will come out of it.

A+
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


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

Re: Preparing the m68k port for the future.

[Wouter Verhelst]

On Sat, Jan 14, 2006 at 03:24:42AM +1000, Anthony Towns wrote:
> On Fri, Jan 13, 2006 at 06:04:00PM +0100, Wouter Verhelst wrote:
> > The point of my previous mail was to demonstrate that I am, in fact,
> > trying to be proactive about getting the qualification done.
> 
> The way you demonstrate a commitment to getting archive qualification done
> is filling out a page on the wiki like:
> 
> http://wiki.debian.org/ArchiveQualification/hurd-i386
> http://wiki.debian.org/ArchiveQualification/kfreebsd-i386

Oh, hm. Must've missed that. And the stuff I wrote before was because I
misparsed your mail into thinking you were talking about stuff like
m68kEtchReleaseRecertification, which is something totally different.
Sorry 'bout that; working on it now.

[...]
> The fact you don't have anyone able to make a working cross-compiler
> speaks somewhat poorly of the support available for the m68k toolchain,
> too.

The issues with producing a working cross-compiler that I hit against
were not m68k-specific. Also, they may or may not have been fixed in the
mean time; I know for a fact that there is no updated toolchain-source
package available, but there've been a few upstream updates in the mean
time, and I didn't go out and check them anymore (since my previous
attempts failed)

-- 
.../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/
../ --/ ./ / .--/ ../ -/ / / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/
-.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ /
../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ / -./ ---/ .-../
---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/


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

Re: Trivial bug on apt-file (Was : Re: Development standards for unstable)

[Jesus Climent]

On Thu, Jan 12, 2006 at 12:07:02PM -0600, Bill Allombert wrote:
> 
> There are technical ways to solve the problem (e.g. to depend on 
> wget|curl and to detect which one is available at start up). 
> 
> If the mainatiner is willing to give more input than 'it is not a bug'
> on what behaviour he would accept, we can probably come up with a patch.

That would be an ideal solution, which was already proposed in 

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=307833;msg=75

And was responded on a mail (dunno remember if to the bug, to d-d or on IRC)
that the user can utilize several other download managers, but that defeats
the whole purpose of having it done automatically. Besides, if that is the
case, the maintainer can find the most common downloaders and put them as |
dependencies, and receive patches to add config snipets for the most common
case.

Depending on some basic utilities (wget is installed by default on a debian
system) and not providing a simple check for finding the one which is already
installed and use it, instead of giving an error that does not explain the
nature of the problem (heh, 
[ -x $(which curl) ] || { echo "install curl or modify /pathtoconf" ; exit 1;}
would do it) is nonsensical.

The current intent to NMU is not solving the problem, since depending in
wget|curl and having to modify the config file leads to the same problem if
the config points to curl and the user has wget.

Besides, the maintainer gave some answers that i consider not technically
adecuate, and some might even say are arrogant:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=307833;msg=34

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

Sick as a dog. Gonna vomit.
--Dr. Evil (Austin Powers: The Spy Who Shagged Me)


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

Re: Trivial bug on apt-file (Was : Re: Development standards for unstable)

[Luk Claes]

Jesus Climent wrote:
> On Thu, Jan 12, 2006 at 12:07:02PM -0600, Bill Allombert wrote:
> 
>>There are technical ways to solve the problem (e.g. to depend on 
>>wget|curl and to detect which one is available at start up). 
>>
>>If the mainatiner is willing to give more input than 'it is not a bug'
>>on what behaviour he would accept, we can probably come up with a patch.
> 
> 
> That would be an ideal solution, which was already proposed in 
> 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=307833;msg=75

Indeed, though I think it's rather another wishlist bug...

> And was responded on a mail (dunno remember if to the bug, to d-d or on IRC)
> that the user can utilize several other download managers, but that defeats
> the whole purpose of having it done automatically. Besides, if that is the
> case, the maintainer can find the most common downloaders and put them as |
> dependencies, and receive patches to add config snipets for the most common
> case.

and this answers IMHO what the maintainer wants a patch for: a system
that would work with all download managers.

> Depending on some basic utilities (wget is installed by default on a debian
> system) and not providing a simple check for finding the one which is already
> installed and use it, instead of giving an error that does not explain the
> nature of the problem (heh, 
> [ -x $(which curl) ] || { echo "install curl or modify /pathtoconf" ; exit 1;}
> would do it) is nonsensical.
> 
> The current intent to NMU is not solving the problem, since depending in
> wget|curl and having to modify the config file leads to the same problem if
> the config points to curl and the user has wget.

The current intent to NMU is proposing curl | wget which doesn't need
any modification to the config file if curl is installed. Though you're
right that you still need to change the config file when curl is not
installed. This is IMHO however not a *severe* bug as some packages need
configuration if you don't choose to use the default.

Cheers

Luk

-- 
Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D
Fingerprint:   D5AF 25FB 316B 53BB 08E7   F999 E544 DE07 9B7C 328D


signature.asc
Description: OpenPGP digital signature

Re: Dissection of an Ubuntu PR message

[Matthew Palmer]

On Fri, Jan 13, 2006 at 03:03:14PM -0200, Gustavo Franco wrote:
> On 1/13/06, Matthew Garrett <[EMAIL PROTECTED]> wrote:
> > David Nusinow <[EMAIL PROTECTED]> wrote:
> >
> > > Please stop trying to twist my words around. Canonical didn't contribute
> > > back. An individual who happened to work for Canonical did. If someone
> > > employed by the US government contributes to Debian of his own volition do
> > > we say that the US government gives back to Debian? Do we say that your
> > > employer gives back to Debian?
> >
> > If it's an authorised use of company time, sure. Whether or not it is in
> > this case, I don't know.
> >
> 
> Exactly my point Matthew, and calm down David, i wrote: "e.g.: David
> said that Daniel helped him, but if he did that in his workhours it's
> under Canonical bless.". Do you see ? I just pointed out that there's
> a possibility that he was helping you in his workhours,

You've never done anything at work that wasn't officially sanctioned by your
boss?

- Matt


signature.asc
Description: Digital signature

Re: Dissection of an Ubuntu PR message

[Gustavo Franco]

On 1/13/06, Matthew Palmer <[EMAIL PROTECTED]> wrote:
> On Fri, Jan 13, 2006 at 03:03:14PM -0200, Gustavo Franco wrote:
> > On 1/13/06, Matthew Garrett <[EMAIL PROTECTED]> wrote:
> > > David Nusinow <[EMAIL PROTECTED]> wrote:
> > >
> > > > Please stop trying to twist my words around. Canonical didn't contribute
> > > > back. An individual who happened to work for Canonical did. If someone
> > > > employed by the US government contributes to Debian of his own volition 
> > > > do
> > > > we say that the US government gives back to Debian? Do we say that your
> > > > employer gives back to Debian?
> > >
> > > If it's an authorised use of company time, sure. Whether or not it is in
> > > this case, I don't know.
> > >
> >
> > Exactly my point Matthew, and calm down David, i wrote: "e.g.: David
> > said that Daniel helped him, but if he did that in his workhours it's
> > under Canonical bless.". Do you see ? I just pointed out that there's
> > a possibility that he was helping you in his workhours,
>
> You've never done anything at work that wasn't officially sanctioned by your
> boss?

No, because i'm the technology coordinator in a NGO and i'm free to
contribute to the Debian project during my workhours since we develop
a CDD for telecentres.

I see your point, but you're mixing different stuff. AFAIK the
'contribute back to Debian' is endorsed by Canonical, so it's
officially sanctioned there using your own words.

--
Gustavo Franco

Re: Anthony Towns: What I did today

[Martin Zobel-Helas]

Hi Anthony,

On Saturday, 14 Jan 2006, you wrote:
> On Fri, Jan 13, 2006 at 04:22:50PM +0100, Martin Zobel-Helas wrote:
> > On Friday, 13 Jan 2006, you wrote:
> > > Things I did today:
> > > 2. Removed the empty SuperH architecture from the archive (binary-sh).
> > > Coincidence? You decide.
> > > URL: http://azure.humbug.org.au/~aj/blog/2006/01/13#2006-01-13-sh-irts
> > Nice you have done this, but Planet is definitely not the correct place
> > to document changes like this. I would find it more appropriate to
> > inform fellow DDs either via debian-devel@ or [EMAIL PROTECTED] Not all
> > developers read planet.debian.org.
> 
> I think you'll find the correct place is the -sh list, which was notified:
> 
> http://lists.debian.org/debian-superh/2002/04/msg00010.html
> 
> The "sh" arch in unstable has consisted of "Architecture: all" packages only
> since then.

Even so you informed the porters it would have been nice to just drop a
mail on -devel? Where is the problem in writing a mail to -devel? Going
this way everybody would be informed and noone can complain afterwards.

Greetings
Martin


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

Requesting pistachio removal in a week

[Guillem Jover]

Hi,

Initially I packaged pistachio because it was supposed to be the next
microkernel to be used by the Hurd. That's questionable now. Also the
package suffers some problems that I don't want to spend time fixing,
like it not building on all supposedly supported arches, upstream not
being much active externally, although they develop on internal repos
which cannot be pushed outside due to research and paper publications
or master thesis.

I'll be requesting its removal in one week, if someone wants to adopt
it please notify me and upload directly.

The package description is:

 L4Ka::Pistachio is built from ground up incorporating the research
 results of the last seven years of microkernel and multi-server
 research. The code is written in C++ with a strong focus on performance
 and portability.

regards,
guillem


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

Re: Development standards for unstable

[Russ Allbery]

Thomas Viehmann <[EMAIL PROTECTED]> writes:

> Can you elaborate on this? I'm not sure how the existence of more
> packages that should be orphaned invalidates dealing with those that
> presently are.

> There's 169 orphaned packages today, why not do something about them?

The thing is... most of the orphaned packages are in fairly good shape.
Most of the orphaned packages are orphaned because they're obscure and the
person who cared about the package has left the project or run out of
time.  However, they are probably still working fine for people with those
obscure needs, and as such there isn't an obvious significant gain for
Debian by getting rid of them.

The packages in the worst trouble in Debian are not the orphaned ones.  By
pretty much every available QA measure we have (RC bugs, open bugs, bugs
without a response, lintian errors, time since last upload, etc.), almost
of the packages in the worst shape have a regular maintainer.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Need for launchpad

[Matt Zimmerman]

On Fri, Jan 13, 2006 at 12:41:29AM -0800, Steve Langasek wrote:
> Now, it may be that this is an unrealistic pipe dream on my part that's
> incompatible with Ubuntu's goals/release schedule, but it seems to me that
> everyone involved would get more mileage out of the "giving-back" process if
> there were more emphasis on trying to get changes made in sid *before*
> changing things in universe, wherever possible.  I realize there are some
> practical issues on the Debian side that would need to be addressed to make
> this a reality, and I know there are plenty of cases when Ubuntu won't be
> able to wait for Debian before making particular changes, but I think it
> would greatly mitigate the concerns over divergence if people viewed
> universe as less of a sandbox for innovation than they seem to today.

I wouldn't say that it's quite a pipe dream, but I think it's an
oversimplification.  I'm puzzled that you seem to admit that this approach
isn't really practical today, for reasons beyond the control of Ubuntu
developers, and yet are still disappointed that it isn't happening that way.

It may be that the issues are more obvious to me, given that I have
substantial first-hand experience with both Debian and Ubuntu development.
I realize that to many Debian developers, Ubuntu is a black box, because
while our development process is just as open as Debian's, they simply have
no interest in it, and I think this leads to many of the misunderstandings
which surface in threads like this one.

By way of illustration, consider this (intentionally) oversimplified view
from the reverse perspective:

  If you want Ubuntu changes to propagate into Debian more quickly, the
  mechanics are very straightforward.  Queue all Ubuntu source uploads,
  build, sign and upload to Debian incoming.  Ubuntu uploads of packages
  inherited from Debian are versioned in an NMU-ish way where a following
  maintainer upload to Debian would override it.  If you're concerned about
  branding changes (which, by the way, are few and far between on an ongoing
  basis), you could apply the same heuristic used in the Ubuntu patch
  archive to flag uploads which look like branding changes, and eyeball the
  changelog before letting them through.  Each time one of these uploads is
  made, generate a debdiff relative to the existing source package in sid,
  and email a debdiff to the BTS with the patch tag.  Ubuntu changes are now
  promptly made available in sid, and all of the patches are filed in the
  BTS.  Done and done.

It sounds awfully efficient compared to managing hundreds of patch queues by
hand between individual developers, but anyone who has spent time in Debian
can easily spot the holes in it.  Likewise, a proposal that Ubuntu
developers should put their changes into Debian instead sounds simple, but
to an Ubuntu developer is obviously impractical.

-- 
 - mdz


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

Re: Getting rid of circular dependencies, stage 3

[Joey Hess]

Bill Allombert wrote:
> > Although sarge's aptitude did..
> 
> I don't know, there were no ways to upgrade to sarge's aptitude.

The bug log contains a log of astronut doing the upgrade with sarge's
aptitude..

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Getting rid of circular dependencies, stage 3

[Joey Hess]

Henning Glawe wrote:
> To illustrate the scenario:
> - Package A depends on package B, which in turn depends on A
>   0) User calls 'apt-get install  A B
>  ':
>   1) apt splits the whole list into smaller parts after sorting by dependency
>  where, in case this bug occurs:
>=" A"
>="B "
>   2) apt calls 'dpkg --unpack' for each element of  and 
>  == so far no problem ==
>   3) apt calls 'dpkg --configure ' and 'dpkg --configure '
>  where the first step already fails, because B is not in
>  , but A depends on B
>  == complete failure, user has to recover manually: 

debconf will not break in this situation

(BTW, it's not formally essential, but it needs to have the same
qualities as essential packages, and does.)

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Anthony Towns: What I did today

[Andreas Schuldei]

* Martin Zobel-Helas <[EMAIL PROTECTED]> [2006-01-13 20:34:20]:
> ...and no one can complain afterwards.

you underestimate your fellow nagg^Wdevelopers.


signature.asc
Description: Digital signature

Re: Need for launchpad

[Matt Zimmerman]

On Fri, Jan 13, 2006 at 07:48:56AM -0600, John Hasler wrote:
> Why?  Don't we expect users to decide which of their local changes are
> suitable for Debian?  I sometimes make local changes to Debian packages.
> Sometimes I send patches to the BTS and sometimes I decide that the change
> is only relevant to my local situation.  Should I instead put them all up
> on a Web site and expect the maintainers to sort through them?

This is a very interesting analogy.  Over the years, I have worked at many
sites which carried local changes to upstream software, changes which were
never seen outside of the company.  Usually this isn't because they don't
care, but because no one got around to it, or because they didn't know how.
As a Debian developer, you are comfortable with the process and motivated to
follow it, while most end users are neither.

You may expect users to do this, but in my experience, they most often
don't.  You simply don't hear about it.

> Again, why should Ubuntu's patches be handled any differently than those of
> other users?

I would say that Ubuntu's patches are handled better than those of Debian
end users in general and better than those of other Debian derivatives.
Ironically, the fact that the patches are so visible has resulted in a
recurring controversy over how they should be handled, while patches which
rot unknown do not reflect on their creators at all.

> I don't either.  After all, most users don't file bug reports, and Ubuntu
> is (in my view), a user.

I disagree with this analogy; Ubuntu is a collaborative project with a
sizeable number of developers, and it doesn't behave like a user to any
meaningful degree.

-- 
 - mdz


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

Re: Need for launchpad

[Matt Zimmerman]

On Fri, Jan 13, 2006 at 05:08:33PM +0100, cobaco (aka Bart Cornelis) wrote:
> as documented experience by maintainers who've tried that shows, this is 
> inefficient enough that reimplementing is mostly faster (and definately 
> more attractive, as it involves less drudgework)

This is at best an exaggeration, and clearly and demonstrably *not* the
rule.



-- 
 - mdz


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

Re: Need for launchpad

[Matt Zimmerman]

On Fri, Jan 13, 2006 at 03:19:09PM +0100, cobaco (aka Bart Cornelis) wrote:
> But at the moment I've seen lots of comments by maintainers saying that in
> most cases it's currently more work to find out if there's any usefull
> bits in the diffs between debian-ubuntu packages, then to do the work
> themselves (for various reasons, which have been mentioned before)

One generally only hears about the problems in these situations.  Someone
who quietly pulls a patch from Ubuntu and goes on with their life doesn't
complain loudly in threads like these, but I see it all the time on
debian-devel-changes.  There are rather few cases where the diffs are truly
hairy, as I've pointed out in previous threads with examples.

> In the mean while Ubuntu proudly calls "ubuntu gives things back", whereas 
> in reality we mostly have a situation of "ubuntu will help debian 
> maintainers that want to take things back"
> 
> -> It's this misrepresentation of where (most of) the initiative lies which
>pisses people off.

This is only the latest expression of the same general discontent which has
been rehashed again and again on this list.  A year ago it was "Ubuntu
aren't contributing", then "Ubuntu aren't contributing in the right way",
and now "Ubuntu aren't contributing in the way that they say that they are".
Ubuntu hasn't significantly changed its practices; it is only the
accusation which has changed over time.

The trouble is that those expressing this opinion seem to have
misunderstandings about what has actually been said.  They talk about what
is said "proudly", that Ubuntu is "crowing" or "bragging" about "giving
back", that it conceals its Debian roots, etc.  If you read what is written
on the Ubuntu website about the relationship between Ubuntu and Debian, it
doesn't have this kind of tone at all, and certainly doesn't use the kind of
language that many have attributed to Ubuntu in this thread.

Some things that it does say:

- Ubuntu is based on Debian, and what this means in terms of the movement of
  packages

- Ubuntu differs from Debian in its philosophy, and how

- The Ubuntu development methodology is different from Debian's, and how

- Ubuntu classifies packages from Debian into different categories, how, and
  why

- Ubuntu's release cycle differs from Debian's, and how

- Ubuntu, unlike many other Debian derivatives, publishes all of its patches
  for Debian's benefit, and on a continuous basis, not only when a release
  is made

- Ubuntu submits fixes for Debian bugs to the Debian BTS including a patch
  URL

The information on the page is accurate (or was at the time of its writing;
there seem to be some outdated bits) and much of it has been validated as
such by virtue of being argued about on this very mailing list.

It does not discuss the direct collaboration which takes place between
certain Ubuntu developers and Debian developers who communicate regularly,
though this practice is not uncommon either.

-- 
 - mdz


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

Re: Anthony Towns: What I did today

[Andreas Tille]

On Fri, 13 Jan 2006, Andreas Schuldei wrote:


* Martin Zobel-Helas <[EMAIL PROTECTED]> [2006-01-13 20:34:20]:

...and no one can complain afterwards.


you underestimate your fellow nagg^Wdevelopers.


Well, there are always people who complain.  But posting development
related mails to debian-devel is the intended purpose of this list
and there is less reason to complain then it is if people do not at
least mark their postings [OT] when they are chatting about other
distributions on debian-devel.

So, if you ask me it would be better if messages like the one Anthony
blogged would be here in the first place and the blog would say: "I
just posted this or that to debian-devel ..." :)

Kind regards

   Andreas.
--
http://fam-tille.de


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

Re: For those who care about their packages in Ubuntu

[Joerg Jaspert]

On 10533 March 1977, Raphael Hertzog wrote:

> Hello fellow Debian developers,
> let me explain shortly why I'll speak of Ubuntu on a Debian announce

[lalala]

Whatever one may think about Ubuntu, d-d-a is the wrong list for an
announcement about Ubuntu plans.

"Announcements of development issues like policy changes, important
release issues &c."

-- 
bye Joerg
>D. You've just heard about this great program and would like to package
>it, what are your next steps?
I would start off by sighing deeply and wishing I were already a DD. :-)
[...]
If I were already a DD, I would perform most of these same steps.  I
would omit the deep sigh and replace it with a gasp of excitement,[...]


pgp7l5IXDwkuX.pgp
Description: PGP signature

Bug#347993: ITP: optipng -- advanced PNG optimizer

[Nelson A. de Oliveira]

Package: wnpp
Severity: wishlist
Owner: "Nelson A. de Oliveira" <[EMAIL PROTECTED]>


* Package name: optipng
  Version : 0.4.8
  Upstream Author : Cosmin Truta <[EMAIL PROTECTED]>
* URL : http://www.cs.toronto.edu/~cosmin/pngtech/optipng/
* License : zlib/libpng
  Description : advanced PNG optimizer

OptiPNG is a PNG optimizer that recompresses the image files to a
smaller size, without losing any information. The idea has been inspired
from pngcrush (http://pmt.sourceforge.net/pngcrush), and is explained in
detail in the PNG-Tech article "A guide to PNG optimization"
(http://www.cs.toronto.edu/~cosmin/pngtech/optipng.html). The
implementation is carried forward in OptiPNG, which offers a faster
execution per trial, and a wider search space.

Nelson

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.13-rc5-mm1
Locale: LANG=pt_BR, LC_CTYPE=pt_BR (charmap=ISO-8859-1) (ignored: LC_ALL set to 
pt_BR)


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

Re: Need for launchpad

[David Nusinow]

On Fri, Jan 13, 2006 at 01:14:18PM -0800, Matt Zimmerman wrote:
> The trouble is that those expressing this opinion seem to have
> misunderstandings about what has actually been said.  They talk about what
> is said "proudly", that Ubuntu is "crowing" or "bragging" about "giving
> back", that it conceals its Debian roots, etc.  If you read what is written
> on the Ubuntu website about the relationship between Ubuntu and Debian, it
> doesn't have this kind of tone at all, and certainly doesn't use the kind of
> language that many have attributed to Ubuntu in this thread.

I don't buy this. The impression that just about everyone has of this
didn't come from nowhere.

http://www.ubuntulinux.org/ubuntu/relationship

  "Sponsored by Canonical, the Ubuntu project attempts to work with
  Debian to address the issues that keep many users from using Debian."
  ...
  "When Ubuntu developers fix bugs that are also present in debian packages
  -- and since the projects are linked, this happens often -- they send
  their bugfixes to the Debian developers responsible for that package in
  debian and record the patch URL in the debian bug system."
  ...
  "First, Ubuntu contributes patches directly to Debian"

I think that's what serves to create a pretty strong impression that Ubuntu
is actually working very closely with Debian to do things like "address the
issues that keep many users from using Debian." From the sound of this
thread everyone would welcome what's on that page with open arms.

 - David Nusinow


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

Re: Getting rid of circular dependencies, stage 3

[Bill Allombert]

On Fri, Jan 13, 2006 at 03:57:57PM -0500, Joey Hess wrote:
> Bill Allombert wrote:
> > > Although sarge's aptitude did..
> > 
> > I don't know, there were no ways to upgrade to sarge's aptitude.
> 
> The bug log contains a log of astronut doing the upgrade with sarge's
> aptitude..

Yes, but only after having run 'aptitude install aptitude perl'
with woody aptitude which did:
56 packages upgraded, 64 newly installed, 5 to remove and 547 not upgraded.
which was a non trivial upgrade.

So sarge aptitude was actually running on a smaller set of packages
where the perl modules cicular-dep was no more present.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here.


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

Re: Need for launchpad

[Matt Zimmerman]

On Mon, Jan 09, 2006 at 03:41:08PM -0800, Russ Allbery wrote:
> I'm not at all surprised that Ubuntu is drifting into closed-source
> software, as this is a standard development path for a company based
> around free software.  I'm not upset.  I'm simply not interested, and
> consider that path to be entirely predictable.

Ubuntu, while its license policy is somewhat less strict than the DFSG, is
not drifting into closed-source software.  It's virtually unchanged since
the project's inception.

http://www.ubuntu.com/ubuntu/licensing

> And certainly, I would oppose blessing any closed-source toolset as part
> of Debian's infrastructure, regardless of its origins.

So would I.  I mean this in the same sense that I assume that you do,
meaning the sort of software which we see and work with directly.

-- 
 - mdz


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

Re: Need for launchpad

[Matthew Palmer]

On Fri, Jan 13, 2006 at 01:14:18PM -0800, Matt Zimmerman wrote:
> Some things that it does say:

[...]

> - Ubuntu submits fixes for Debian bugs to the Debian BTS including a patch
>   URL

If that said "sometimes" or "some people within Ubuntu", it would be
correct.  Not every relevant patch ends up in the BTS.

I'd also echo David Nusinow's comments that the wording of some of the
statements implies a far closer cooperation than is apparent from watching
what actually happens.

- Matt


signature.asc
Description: Digital signature

Re: Need for launchpad

[Matt Zimmerman]

On Sat, Jan 14, 2006 at 10:19:50AM +1100, Matthew Palmer wrote:
> On Fri, Jan 13, 2006 at 01:14:18PM -0800, Matt Zimmerman wrote:
> > Some things that it does say:
> 
> [...]
> 
> > - Ubuntu submits fixes for Debian bugs to the Debian BTS including a patch
> >   URL
> 
> If that said "sometimes" or "some people within Ubuntu", it would be
> correct.  Not every relevant patch ends up in the BTS.

I was afraid that this would start this kind of trivial semantic discussion.

It doesn't say that Ubuntu fixes ALL Debian bugs, or any other absolute.  It
does say that Ubuntu submits bug fixes to Debian through the BTS, and there
are in fact hundreds of such fixes in debbugs today.

-- 
 - mdz


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

Re: Need for launchpad

[Matt Zimmerman]

On Fri, Jan 13, 2006 at 05:49:40PM -0500, David Nusinow wrote:
> I don't buy this. The impression that just about everyone has of this
> didn't come from nowhere.

Not from nowhere, no.  The statements that Ubuntu "steals users from
Debian", "wants to kill Debian", etc. came from somewhere, too, but that
somewhere wasn't Ubuntu.

> http://www.ubuntulinux.org/ubuntu/relationship
> 
>   "Sponsored by Canonical, the Ubuntu project attempts to work with
>   Debian to address the issues that keep many users from using Debian."

Ubuntu does attempt to work with Debian.

>   "When Ubuntu developers fix bugs that are also present in debian packages
>   -- and since the projects are linked, this happens often -- they send
>   their bugfixes to the Debian developers responsible for that package in
>   debian and record the patch URL in the debian bug system."

Ubuntu does submit such patches, though "bugs which were reported to Debian
and consequently fixed by Ubuntu developers" would be more accurate.  I'll
suggest that change.

>   "First, Ubuntu contributes patches directly to Debian"

The word "directly" is somewhat misleading here; in general, Ubuntu
developers are not allowed (by Debian) to make any change "directly" to
Debian.  I will suggest that it be removed.

> I think that's what serves to create a pretty strong impression that Ubuntu
> is actually working very closely with Debian to do things like "address the
> issues that keep many users from using Debian." From the sound of this
> thread everyone would welcome what's on that page with open arms.

I can't agree.  From the sound of this and other threads, there are a number
of folks who are unlikely to be satisfied with any behavior on the part of
the Ubuntu project or its members.  Fortunately, there are others who are
actively cooperating to the mutual benefit of the two projects.

-- 
 - mdz


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

Re: For those who care about their packages in Ubuntu

[Bill Allombert]

On Fri, Jan 13, 2006 at 11:35:24PM +0100, Raphael Hertzog wrote:
> I believe Ubuntu fills an important gap in the Debian world and as such

Ubuntu is not part of the Debian world, because it does not share the
values that found Debian. The Ubuntu people are certainly free to use our
softwares, that is even the whole point of the exercise, but ourself 
should not direct our users (and developers) to distributions with lower
standards by pretending they are 'part of the Debian world' because this
amounts to self-destruction. 

If such gap exist, we should not abdicate our responsability to fill
it to others that do not adhere to our principles.

Cheers,
Bill.


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

Re: Need for launchpad

[Russ Allbery]

Matt Zimmerman <[EMAIL PROTECTED]> writes:

> Ubuntu, while its license policy is somewhat less strict than the DFSG,
> is not drifting into closed-source software.  It's virtually unchanged
> since the project's inception.

The policy and development may be virtually unchanged since the project's
inception since I have no idea how many other closed-source components
such as Launchpad you've been working on from the beginning, but at least
the public face is drifting as those projects are deployed and become part
of the day-to-day work on Ubuntu.

And hey, as I said, if that's what you want to do, more power to you.  I'm
well aware that many in the free software community are quite happy to use
closed-source and/or commercial infrastructure toolsets and services.  The
advertising deluge that drowns me every time I try to look at Sourceforge
is a good reminder of that.  :)  However, the more that you deploy and
depend on closed-source tools, the less interesting Ubuntu is to me
personally.  (It's quite likely that you don't care, and that's fine.  I
don't really expect you to.)

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: French cheese

[Matt Zimmerman]

On Fri, Jan 13, 2006 at 06:15:16PM +0100, Christian Perrier wrote:
> Quoting Matt Zimmerman ([EMAIL PROTECTED]):
> 
> > Unfortunately, this conflicts with a development sprint we're having in
> > London, so that won't be possible at that time.
> > 
> > My heart breaks at the prospect of a missed opportunity to gorge myself on
> > cheese...
> 
> 
> Well, it's just a matter of jumping in the first Eurostar in the
> morning, be at Gare du Nord around 8 or 9, go to Solutions Linux,
> drink, talk and eat cheese all day long with fellow Debian and Ubuntu
> people, then jump in another Eurostar back to London (with some cheese
> in your luggage) and be back for hacking with your fellow Ubuntu
> people late in the night.

I'm afraid I really can't leave in the middle of things, though I'll be in a
convenient time zone and available by voice or IRC much of the time.  I will
simply have to be content with imported cheese until DebConf.

> And, for next year, just plan your development sprint in Paris..:-)
> (I'm half-serious and even really serious here)

Could happen...

-- 
 - mdz


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

Re: Need for launchpad

[Manoj Srivastava]

On Fri, 13 Jan 2006 15:53:51 -0800, Matt Zimmerman <[EMAIL PROTECTED]> said: 

> I can't agree.  From the sound of this and other threads, there are
> a number of folks who are unlikely to be satisfied with any behavior
> on the part of the Ubuntu project or its members.  Fortunately,
> there are others who are actively cooperating to the mutual benefit
> of the two projects.

Whooo. This sounds like a bit of a smear -- either people are
 unsatisfiable cads who demand overmuch, or they are perfectly happily
 contributing back and forth. Nothing in between these extremes?

Which group, pray, do you categorize me into?

manoj
-- 
It is undignified for a woman to play servant to a man who is not
hers. Spock, "Amok Time", stardate 3372.7
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: For those who care about their packages in Ubuntu

[Florian Weimer]

* Raphael Hertzog:

> I believe Ubuntu fills an important gap in the Debian world and as such
> I'm not satisfied when Ubuntu is diverging too much from Debian, and the
> only way to avoid divergence is to merge back what's useful and to provide
> better solution for derivatives when there's a need for a divergence.

How can I request removal of a package which has been added to Ubuntu
("universe", whatever that is), despite not being useful on Ubuntu?


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

Re: Need for launchpad

[Matt Zimmerman]

On Fri, Jan 13, 2006 at 07:19:53PM -0600, Manoj Srivastava wrote:
> Which group, pray, do you categorize me into?

You, Manoj, are in a category all your own.

-- 
 - mdz


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

Re: For those who care about their packages in Ubuntu

[Matt Zimmerman]

On Sat, Jan 14, 2006 at 02:54:30AM +0100, Florian Weimer wrote:
> * Raphael Hertzog:
> 
> > I believe Ubuntu fills an important gap in the Debian world and as such
> > I'm not satisfied when Ubuntu is diverging too much from Debian, and the
> > only way to avoid divergence is to merge back what's useful and to provide
> > better solution for derivatives when there's a need for a divergence.
> 
> How can I request removal of a package which has been added to Ubuntu
> ("universe", whatever that is), despite not being useful on Ubuntu?

The maintainers for the Ubuntu "universe" component can be reached at
[EMAIL PROTECTED]

-- 
 - mdz


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

Re: Dissection of an Ubuntu PR message

[Kevin Mark]

On Fri, Jan 13, 2006 at 03:03:14PM -0200, Gustavo Franco wrote:
> On 1/13/06, Matthew Garrett <[EMAIL PROTECTED]> wrote:
> > David Nusinow <[EMAIL PROTECTED]> wrote:
> >
> > > Please stop trying to twist my words around. Canonical didn't contribute
> > > back. An individual who happened to work for Canonical did. If someone
> > > employed by the US government contributes to Debian of his own volition do
> > > we say that the US government gives back to Debian? Do we say that your
> > > employer gives back to Debian?
> >
> > If it's an authorised use of company time, sure. Whether or not it is in
> > this case, I don't know.
> >
> 
> Exactly my point Matthew, and calm down David, i wrote: "e.g.: David
> said that Daniel helped him, but if he did that in his workhours it's
> under Canonical bless.". Do you see ? I just pointed out that there's
> a possibility that he was helping you in his workhours, but i won't
> cite you as a reference anymore.
> 
> --
> Gustavo Franco
Hi Gustavo,
Is it within the scope of Canonical employees to contribute code to
Debian that is under the his copyright and not Canonical's? And
especially since it is in the exact same area that he was employed by
Canonical to do?  Would this apply to Progeny and Debian, Progeny and
Canonical, Linspire and ...
Cheers,
Kev
-- 
counter.li.org #238656 -- goto counter.li.org and be counted!
  `$' $' 
   $  $  _
 ,d$$$g$  ,d$$$b. $,d$$$b`$' g$b $,d$$b
,$P'  `$ ,$P' `Y$ $$'  `$ $  "'   `$ $$' `$
$$ $ $$g$ $ $ $ ,$P""  $ $$
`$g. ,$$ `$$._ _. $ _,g$P $ `$b. ,$$ $$
 `Y$$P'$. `YP $$$P"' ,$. `Y$$P'$ $.  ,$.


signature.asc
Description: Digital signature

Re: Need for launchpad

[Thomas Bushnell BSG]

David Nusinow <[EMAIL PROTECTED]> writes:

> http://www.ubuntulinux.org/ubuntu/relationship
>
>   "Sponsored by Canonical, the Ubuntu project attempts to work with
>   Debian to address the issues that keep many users from using Debian."
>   ...
>   "When Ubuntu developers fix bugs that are also present in debian packages
>   -- and since the projects are linked, this happens often -- they send
>   their bugfixes to the Debian developers responsible for that package in
>   debian and record the patch URL in the debian bug system."
>   ...
>   "First, Ubuntu contributes patches directly to Debian"
>
> I think that's what serves to create a pretty strong impression that Ubuntu
> is actually working very closely with Debian to do things like "address the
> issues that keep many users from using Debian." From the sound of this
> thread everyone would welcome what's on that page with open arms.

But it doesn't describe Ubuntu's past behavior.  Has there been an
official change, or what?


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

Re: Need for launchpad

[Thomas Bushnell BSG]

Matt Zimmerman <[EMAIL PROTECTED]> writes:

> I can't agree.  From the sound of this and other threads, there are a number
> of folks who are unlikely to be satisfied with any behavior on the part of
> the Ubuntu project or its members.  Fortunately, there are others who are
> actively cooperating to the mutual benefit of the two projects.

Really, it's very easy.  I would be satisfied if both of the following
were done:

Every time you find a bug in an Ubuntu package, make some effort to
determine if it is Ubuntu-specific or might rather affect all Debian
users.  If it is not Ubuntu-specific, then file a bug report, and
optionally, a patch, in the Debian BTS.

Every Ubuntu package should have a different Maintainer unless the
Debian maintainer has agreed to be the Maintainer of the Ubuntu
package as well.  The Ubuntu package should, of course, continue to
give credit to the upstream Debian maintainer, but not by designating
that individual as the Maintainer in the Ubuntu package.

Thomas



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

Re: Need for launchpad

[Thomas Bushnell BSG]

Matt Zimmerman <[EMAIL PROTECTED]> writes:

> It doesn't say that Ubuntu fixes ALL Debian bugs, or any other absolute.  It
> does say that Ubuntu submits bug fixes to Debian through the BTS, and there
> are in fact hundreds of such fixes in debbugs today.

Does Ubuntu do so for every bug it fixes, or only some?


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

Re: Need for launchpad

[Steve Langasek]

On Fri, Jan 13, 2006 at 08:34:33PM -0800, Thomas Bushnell BSG wrote:
> Matt Zimmerman <[EMAIL PROTECTED]> writes:

> > I can't agree.  From the sound of this and other threads, there are a number
> > of folks who are unlikely to be satisfied with any behavior on the part of
> > the Ubuntu project or its members.  Fortunately, there are others who are
> > actively cooperating to the mutual benefit of the two projects.

> Really, it's very easy.  I would be satisfied if both of the following
> were done:

> Every time you find a bug in an Ubuntu package, make some effort to
> determine if it is Ubuntu-specific or might rather affect all Debian
> users.  If it is not Ubuntu-specific, then file a bug report, and
> optionally, a patch, in the Debian BTS.

Which might be ideal, but I don't think it's realistic to ask that they do
this for *every* bug they find.

> Every Ubuntu package should have a different Maintainer unless the
> Debian maintainer has agreed to be the Maintainer of the Ubuntu
> package as well.  The Ubuntu package should, of course, continue to
> give credit to the upstream Debian maintainer, but not by designating
> that individual as the Maintainer in the Ubuntu package.

Which is not something that most Debian developers seem to be hung up on;
and some maintainers seem to prefer to be credited in the packages.

So if this is what it takes to satisfy you, I suspect you're going to have
to live with your dissatisfaction.

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


signature.asc
Description: Digital signature

Re: Need for launchpad

[Thomas Bushnell BSG]

Steve Langasek <[EMAIL PROTECTED]> writes:

>> Every time you find a bug in an Ubuntu package, make some effort to
>> determine if it is Ubuntu-specific or might rather affect all Debian
>> users.  If it is not Ubuntu-specific, then file a bug report, and
>> optionally, a patch, in the Debian BTS.
>
> Which might be ideal, but I don't think it's realistic to ask that they do
> this for *every* bug they find.

Why?  Every time I find a bug in a package I maintain, which is a bug
in the upstream version too, I report it.  Isn't that normal?

This is, in fact, just what is expected.  It's what "cooperation"
means to me.

>> Every Ubuntu package should have a different Maintainer unless the
>> Debian maintainer has agreed to be the Maintainer of the Ubuntu
>> package as well.  The Ubuntu package should, of course, continue to
>> give credit to the upstream Debian maintainer, but not by designating
>> that individual as the Maintainer in the Ubuntu package.
>
> Which is not something that most Debian developers seem to be hung up on;
> and some maintainers seem to prefer to be credited in the packages.

Um, I have said nothing against crediting maintainers in the
packages.  I have only said that I would like Ubuntu to clearly label
which is the Debian maintainer and which is the Ubuntu maintainer.

Thomas


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

Re: libecw

[Paul Wise]

Miriam Ruiz wrote:

> > I'm not sure if it's license (
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=293346 ) can be considered
> > free enough to be in main:

Some feedback from upstream is in this thread:

http://lists.alioth.debian.org/pipermail/pkg-grass-general/2005-August/thread.html#1082
http://lists.alioth.debian.org/pipermail/pkg-grass-general/2005-August/001082.html
http://lists.alioth.debian.org/pipermail/pkg-grass-general/2005-August/001083.html
http://lists.alioth.debian.org/pipermail/pkg-grass-general/2005-August/001085.html
http://lists.alioth.debian.org/pipermail/pkg-grass-general/2005-August/001086.html

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: For those who care about their packages in Ubuntu

[Steve Langasek]

On Sat, Jan 14, 2006 at 01:26:25AM +0100, Bill Allombert wrote:
> On Fri, Jan 13, 2006 at 11:35:24PM +0100, Raphael Hertzog wrote:
> > I believe Ubuntu fills an important gap in the Debian world and as such

> Ubuntu is not part of the Debian world, because it does not share the
> values that found Debian.

That's kind of a strange position to take, isn't it?  Does this mean that
the many users who use Debian directly sheerly on technical excellence
alone, without sharing Debian's "founding values", are not part of the
"Debian world"?  For that matter, I don't know of any derivative Debian
distributions that require their developers to agree to the social contract;
so by that standard, are *any* of them part of the "Debian world"?

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


signature.asc
Description: Digital signature

Re: Packet radio and foul language

[Chris Bannister]

On Wed, Jan 11, 2006 at 03:41:09PM +, Andrew Suffield wrote:
> On Tue, Jan 10, 2006 at 12:43:16PM -0600, Ron Johnson wrote:
> > Manners/politeness is social lubricant.  It makes society run 
> > smoother and less violently.
> 
> I'm pretty sure that people who always take the path of least
> resistance are *precisely* how the world got so fucked up in the first
> place.

Sacrificing "long term gains" for "short term pleasures", perhaps, rather
than "*always* taking the path of least resistance."



-- 
Chris.
==
Reproduction if desired may be handled locally. -- rfc3


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

Re: Need for launchpad

[Anthony Towns]

On Fri, Jan 13, 2006 at 03:53:51PM -0800, Matt Zimmerman wrote:
> >   "First, Ubuntu contributes patches directly to Debian"
> The word "directly" is somewhat misleading here; in general, Ubuntu
> developers are not allowed (by Debian) to make any change "directly" to
> Debian.  I will suggest that it be removed.

Heh. Ubuntu is certainly allowed to "contribute patches" directly to
Debian -- anyone can mail patches to the BTS, including Ubuntu.

> I can't agree.  From the sound of this and other threads, there are a number
> of folks who are unlikely to be satisfied with any behavior on the part of
> the Ubuntu project or its members.  Fortunately, there are others who are
> actively cooperating to the mutual benefit of the two projects.

While I'm sure there'll be some people who'll complain no matter what,
I don't see what the problem with mailing patches directly to the BTS
is. As far as tracking is concerned, making use of "[EMAIL PROTECTED]"
usertags or similar would seem sensible.

Cheers,
aj



signature.asc
Description: Digital signature

Re: Need for launchpad

[Christian Perrier]

> While I'm sure there'll be some people who'll complain no matter what,
> I don't see what the problem with mailing patches directly to the BTS
> is. As far as tracking is concerned, making use of "[EMAIL PROTECTED]"
> usertags or similar would seem sensible.


Silly question, probably, but wouldn't this flood the BTS?

If not, this sounds like an interesting suggestion and the shadow
package maintenance team is opened to serve as a test case for
this



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