Re: Getting rid of circular dependencies, stage 3

[Tollef Fog Heen]

* "Joe Smith" 

| "Joey Hess" <[EMAIL PROTECTED]> wrote in message
| news:[EMAIL PROTECTED]
|
| >> Joey Hess <[EMAIL PROTECTED]>
| >>  debconf
| >>  debconf-english
| >>  debconf-i18n
| >
| >These are all necessary, and debconf is an essential package which is
| >not subject to the circular dependency postinst ordering problems afaik.
|
| Well, I'm not sure if that is an excuse for violating policy.

Essential: yes packages must work while unconfigured, so they won't be
bitten by the bug in question here.

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


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

Re: Dissection of an Ubuntu PR message

[Tollef Fog Heen]

* Christian Perrier 

| No chance that people from Canonical show up over there? I can even
| host (Perrier's bed and breakfast, including cheese)...:)

I doubt it; There's a Ubuntu distro sprint in London that week so
we'll all be very, very busy with discussions and bug fixing on our
own.

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


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

Re: Canonical's business model

[Marc Haber]

On Wed, 11 Jan 2006 16:48:21 +0100, martin f krafft
<[EMAIL PROTECTED]> wrote:
>IMHO, the border between contributing and employing people who also
>work on Debian is not entirely clear.
>
>How do you think Canonical could *better* work with Debian, ignoring
>whether they meet up to their promises at the moment or not.
>
>What would you like to see?

I would like to see Canonical employees who are not doing their jobs
in Debian to step down from the Debian job. Just as I would like to
see that for any Debian delegate or volunteer who does not have the
time to do the job.

Greetings
Marc

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

Re: Getting rid of circular dependencies, stage 3

[Josselin Mouette]

Le jeudi 12 janvier 2006 à 01:49 +0100, Jeroen van Wolffelaar a écrit :
> > At the very least, I think they should be treated like pre-depends, with
> > a request on this list being mandatory before adding a circular
> > dependency. Until now, all circular dependencies cases I have met were
> > fixable. At first, some of them looked necessary and they required quite
> > some work, but they were fixable.
> 
> You know when you're adding a pre-depends. You're typing the word
> "Pre-Depends" in a debian/control file.
> 
> You don't know when you're introducing a circular depends that easily,
> and it could be either of the packages in the circle that shouldn't have
> such a depends, not necessarily the last one that closed the circle
> should change.

Sure, and I agree Bill's checks should go on. However, looking at the
list, a vast majority of circular dependencies come from the same source
package. This could be checked e.g. by lintian.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
   `-  Debian GNU/Linux -- The power of freedom

Re: Getting rid of circular dependencies, stage 3

[Josselin Mouette]

Le lundi 09 janvier 2006 à 22:15 -0500, Joey Hess a écrit :
> Bill Allombert wrote:
> > Here the lists of packages involved in circular dependencies listed by
> > maintainers.
> 
> > Joey Hess <[EMAIL PROTECTED]>
> > debconf
> > debconf-english
> > debconf-i18n
> 
> These are all necessary, and debconf is an essential package which is
> not subject to the circular dependency postinst ordering problems afaik.

Looking at them, I fail to see why debconf-i18n has to depend on
debconf. Wouldn't it possible to just remove this dependency?

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

Sabbatical

[Scott James Remnant]

Hi guys,

For various personal reasons you've probably not seen me around much in
the last few months; and unfortunately, for the same reasons I've
decided to take a Sabbatical from working on Debian.

I've already arranged maintainership of both of my packages:

  Matthias Klose will take over build-essential, as he's one of the few
  people who get a "yes" answer to bugs on that anyway.

  Dpkg will return to a team maintainership, and I've asked a few people
  to be on the initial team:
Frank Lichtenheld, as he's been supplying a lot of dpkg-dev patches.
Brendan O'Dea who supplied the "Wig and Pen" code
Guillem Jover who's also supplied patches and nagged a bit ;)
Christian Perrier who'll hopefully continue his translation efforts.


I may see some of you at conferences, if I'm there on behalf of Ubuntu;
but I don't have any plans to attend any myself this year.

Scott
-- 
Have you ever, ever felt like this?
Had strange things happen?  Are you going round the twist?


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

Re: Canonical's business model

[jeremiah foster]

Can't Canonical devote resources to better Ubuntu's contribution to debian? This seems like a reasonable request since Canonical crows about how they are the number one linux distro and they have excellent support, but surely the reliability of their product rests upon the reliability of debian. 

Can Canonical allocate paid positions for debian developers to integrate Ubuntu patches back into debian? These would be debian developers tasked with developing fixes for debian from Ubuntu not beholden to any business model or corporate creed.

The allocation of resources might assuage some of the smoldering resentment harbored by DDs towards Canonical.

Jeremiah

libecw

[Jorge Garcia]

Hello!
Dou you know when will be available libecw in Debian repository?
Thanks!
Jorge.


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

RE: libecw

[Miriam Ruiz]

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:

Use of the ECW SDK with Unlimited Decompressing and Unlimited Compression for
applications licensed under a GNU General Public style license ("GPL") is
governed by the "ECW SDK PUBLIC USE LICENSE AGREEMENT".


* About modifications:

b)  You may make modifications to the Software and distribute your
modifications, in a form that is separate from the Software, such as 
patches. The following restrictions apply to modifications: 
i)  Modifications must not alter or remove any copyright notices in the
Software. 
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. 
iii)You are not permitted to change the ECW file format.
iv) You are not permitted to use Software Product for development or
distribution of "Server Software" that provides services or 
functionality on a computer acting as a server.


* About restriction of use (I just don't know DFARS 252.227-7013 so I have no
idea what's said in here)

3)  U.S. GOVERNMENT RESTRICTED RIGHTS. 
The SOFTWARE PRODUCT and documentation are provided with RESTRICTED RIGHTS.
Use, duplication, or disclosure by the US Government is subject 
to restrictions as set forth in subparagraph (c)(1)(ii) of The Rights in
Technical Data and Computer Software clause at DFARS 252.227-7013 
or subparagraphs (c)(1) and (2) of the Commercial Computer Software -
Restricted Rights at 48 CFR 52.227-19, as applicable. Manufacturer is 
Earth Resource Mapping Limited.

4)  DESCRIPTION OF OTHER RIGHTS AND LIMITATIONS. 
a)  Rental. You may not rent, lease or lend the SOFTWARE PRODUCT. 


I find it to be quite an obscure license, does anyone know for sure?

Greetings,
Miry


 --- Jorge Garcia <[EMAIL PROTECTED]> escribió:

> Hello!
> Dou you know when will be available libecw in Debian repository?
> Thanks!
> Jorge.




__ 
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: libecw

[Jorge Garcia]

El Jueves 12 Enero 2006 10:58, Miriam Ruiz escribió:
> 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:
And in non-free ?
>
> Use of the ECW SDK with Unlimited Decompressing and Unlimited Compression
> for applications licensed under a GNU General Public style license ("GPL")
> is governed by the "ECW SDK PUBLIC USE LICENSE AGREEMENT".
>
>
> * About modifications:
>
> b)You may make modifications to the Software and distribute your
> modifications, in a form that is separate from the Software, such as
> patches. The following restrictions apply to modifications:
> i)Modifications must not alter or remove any copyright notices in the
> Software.
> 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.
> iii)  You are not permitted to change the ECW file format.
> iv)   You are not permitted to use Software Product for development or
> distribution of "Server Software" that provides services or
> functionality on a computer acting as a server.
>
>
> * About restriction of use (I just don't know DFARS 252.227-7013 so I have
> no idea what's said in here)
>
> 3)U.S. GOVERNMENT RESTRICTED RIGHTS.
> The SOFTWARE PRODUCT and documentation are provided with RESTRICTED RIGHTS.
> Use, duplication, or disclosure by the US Government is subject
> to restrictions as set forth in subparagraph (c)(1)(ii) of The Rights in
> Technical Data and Computer Software clause at DFARS 252.227-7013
> or subparagraphs (c)(1) and (2) of the Commercial Computer Software -
> Restricted Rights at 48 CFR 52.227-19, as applicable. Manufacturer is
> Earth Resource Mapping Limited.
>
> 4)DESCRIPTION OF OTHER RIGHTS AND LIMITATIONS.
> a)Rental. You may not rent, lease or lend the SOFTWARE PRODUCT.
>
>
> I find it to be quite an obscure license, does anyone know for sure?
>
> Greetings,
> Miry
>
>  --- Jorge Garcia <[EMAIL PROTECTED]> escribió:
> > Hello!
> > Dou you know when will be available libecw in Debian repository?
> > Thanks!
> > Jorge.
>
> __
> LLama Gratis a cualquier PC del Mundo.
> Llamadas a fijos y móviles desde 1 céntimo por minuto.
> http://es.voice.yahoo.com

Re: Need for launchpad

[Martin Meredith]

It has come to my attention that this last email could have been construed as a 
personal attack
against a certain ubuntu developer. It is not meant that way.

What I don't seem to have put across properly are the following points.

1) the blog post mentioned that made me irate was because of the way It was 
worded andhow i read it
at the time. I didnt read this properly the first time round - and the opinion 
is expressed about
what I thought the person was trying to put across. After re-reading the 
article - I changed my mind
(but would still have been irate if the post had been what I first thought it 
was)

2) I am not lumping all Ubuntu Devs into one boat - nor all Debian Devs - I'm 
jsut saying that I
think it's the few people out of the large who arent willing to cooperate for 
whatever reason that
are causing this tension.

Martin Meredith wrote:
> Ok - I'm going to reply to the first post i found on this whole - thing, so 
> apologies if it shows up
> in some weird place in threaded view.
> 
> Basically the way I see it isnt the fact that ubuntu isn't giving back to 
> debian - or debian isn't
> willing to have the stuff from ubuntu. The way i see it is that there are a 
> few people - who - for
> some reason or another - just don't do the right thing.
> 
> I can definately understand some DD's views here - they seem to get nothing 
> from ubuntu - have to
> wade through patches or whatever to try and find the useful stuff - have to 
> do all this work to get
> all the stuff from ubuntu, because whatever ubuntu dev is doing things isn't 
> contributing back to
> debian. This definately happens. There's no doubt about it.
> 
> 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.
> 
> I eventually gave up trying contacting that maintainer - and just carried on 
> with the work in ubuntu
> - and worked with upstream. It's people like that that are spoiling it, as 
> I've had experiences with
> other DD's who've been very helpful indeed.
> 
> Recently, a certain member of the MOTU team in ubuntu posted a blog post 
> basically saying (from the
> way it came across to me) that contributing back up to debian was a waste of 
> our meagre resources. I
> can't express how ... and this is a very mild way of me putting it (Code of 
> Conduct and all - darn
> it!)... annoyed that made me - I was infuriated, espescially seeing as I'd 
> been one of those people
> who'd raised the issue of contributing back to debian.
> 
> I, personally - see contributing to debian as a vital part of the ubuntu 
> development process - after
> all - debian is our upstream - and I'm sure none of the DD's would think that 
> contributing to
> upstream for the packages they maintain is a waste of the time that they 
> could be putting back into
> debian.
> 
> 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.
> 
> Basically - I dont think the brand should be put on ubuntu as a whole - feel 
> free to target those
> people specifically you see not contributing - but remember - it's a two way 
> thing - and there are
> people not willing to cooperate on both sides.
> 
> *dons asbestos underwear and waits for replies*
> 
> 
> 
> 
> Manoj Srivastava wrote:
> 
>>On Fri, 06 Jan 2006 15:19:42 -0500, Frans Jessop
>><[EMAIL PROTECTED]> said:  
>>
>>
>>
>>>Ubuntu's launchpad is amazing.  Do you think it would be helpful if
>>>all DD's worked through it on their projects?
>>
>>
>>Sure, as long as they change lauchpad to meet my workflow
>> requirements. This would mean letting me have a local repo, signed
>> remote repos, arch, email only interfaces, and not getting into my
>> way.  If they make changes to meet these requirements, I'll have
>> absolutely no problem throwing away tools I have worked on honing for
>> a decade or so and switching to launchpad. Oh, and release launchpad
>> under a free license, of course, so I don't make Debian development
>>

Re: Getting rid of circular dependencies, stage 3

[Henning Glawe]

On Thu, Jan 12, 2006 at 09:01:58AM +0100, Tollef Fog Heen wrote:
> | >These are all necessary, and debconf is an essential package which is
> | >not subject to the circular dependency postinst ordering problems afaik.
> |
> | Well, I'm not sure if that is an excuse for violating policy.
> 
> Essential: yes packages must work while unconfigured, so they won't be
> bitten by the bug in question here.

They could be bitten by this bug. Or speaking more accurately: they can make 
apt be bitten by this bug. The problem is not that they are not working; the
problem is that apt breaks lists of to-be-configured packages at arbitrary
points, which depend only on the list length; while dpkg can only handle
circular dependencies if all elements of the circular dependency are passed
to it at the same time.

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: 
a) dpkg --configure -a
b) goto 0

-- 
c u
henning


signature.asc
Description: Digital signature

Re: Development standards for unstable

[Florian Weimer]

* Anthony Towns:

> If you'd like to make suggestions about ideas that would be useful,

What about: stop threatening your fellow developers?


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

Re: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=265920

[Frank Küster]

Luke Kenneth Casson Leighton <[EMAIL PROTECTED]> wrote:

>> > It's the job of either the bug submitter or (more
>> > usually) the Debian maintainer to contact upstream to make sure that
>> > they're aware of the bug. It is *not* the upstream maintainer's job to
>> > examine Debian's bug database.
>
>  that distinction isn't made clear: it's only if people think about it
>  that they will realise that they are supposed to report debian-specific
>  packaging bugs to the debian bugs database and package-specific bugs
>  to whatever upstream thingy they can find.  _if_ they can find it.

That (what you, Luke wrote) is not correct.  It's perfect if you report
upstream bugs to the Debian Bugtracking System.  In many cases it might
even speed fixing up, because the Debian maintainers are used to
communicate with non-experts to figure out the details, and also used to
checking whether it still occurs in a possible newer, yet unpackaged
upstream version, or in upstream CVS - while some upstream developer
lists, where upstream bugreports get to, are rather technical.  And
sometimes bugs that look like upstream's have been introduced by the
Debian packaging.

So, again, it's fine to report any bug to the Debian bugtracking
system.  IMO it's the responsibility of the Debian maintainer to make
sure that if it's an upstream bug, upstream developers are indeed
notified, or alternatively to ask the user who reported the bug to
contact upstream.

Both approaches - contacting upstream themselves, and asking the
submitter to do that - are valid approaches, and it depends on the
nature of the bug, on the relations of the Debian maintainer to
upstream, and of course on the workload of the Debian maintainer which
is best in a particular case.

In your case the maintainer thought it would be better if you contacted
upstream, and he asked you to do so.

>  for the _really_ popular packages, this becomes a serious problem:
>  the percentage of people reporting bugs into what effectively becomes
>  a black hole starts to get quite serious.

But that's not a problem of where bug reports go to, but how many people
work on a package.  By the way, IMO handling bugs of a package they use,
figuring out the details with submitters, and contacting upstream (or
other Debian packages' maintainers) is a good place to start Debian work
for a newcomer.

>> > Which is, uh, pretty much what Dirk said. Luke, what the christ are you
>> > upset about? 
>
>  
>  
>> Nobody's said "Don't report this bug to us",

That's right, because nobody wanted to express such a thing.

>> > they've said
>> > "If you report a bug to Debian and nobody forwards it, we know nothing
>> > about it".

That came later. Adeodato wrote in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=265920;msg=25:

,
|   ok, that's very valid reasoning. we'll keep the bug report open and
|   set it to a wishlist severity.
| 
|   you or some other SE/Linux user may consider reporting the problem to
|   upstream KDE, with a good reasoning too.
`

This is we are talking about:  You or some other person interested in
SE/Linux should have contacted the KDE people.

>>   All correct. Thanks, Matthew. I'll just note that the Debian KDE
>>   packages receive an incredible amount of bug reports, and that we're
>>   understaffed to forward all of them to KDE upstream. 
>
>  that's why one of my recommendations was to consider putting, into
>  certain key very popular packages, a means to either transfer the bug
>  to upstream (via some mad notional XMLeey are pee cee-ey common API)

Go ahead and code it...

>  or
>  to simply put into reportbug a list of packages for which reporting
>  should be given special messages:
>
>  if reporting on package "kde, libkonq  long list " then
>  report "if this is a bug in KDE itself, please DO NOT report the
>  bug here, go to http://bugs.kde.org whatever.  if you have a
>  debian-specific packaging issue (installation problem, missing
>  files, conflict etc.), please continue".

I don't think that this is a good solution.  Many users are not able to
distinguish between upstream bugs, packaging bugs (and pebcak, anyway).
The ones who can often already decide on their own to report the bug
upstream, and either not report it to Debian at all, or only for
reference, giving upstream's bug ID.

>  1) add into the dpkg thingy an upstream URL where bugs can be reported:
>
> UpstreamBugs: http://bugs.kde.org/enter_bug.cgi (whatever)
>  if you encounter a bug in kde.
>  please report it here because otherwise nobody.
>  will fix it, thank you.
> .

Most of the time it's quite easy to find this out by looking at
/usr/share/doc/ - either there's a bugreporting link on the
package homepage, or you simply contact the upstream developers by email.

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

Re: Canonical's business model

[Marco d'Itri]

On Jan 12, Matt Zimmerman <[EMAIL PROTECTED]> wrote:

> The relevant context is generally available in the changelog (which is in
At least for my packages, this is often false.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Development standards for unstable

[Petter Reinholdtsen]

[Florian Weimer]
> What about: stop threatening your fellow developers?

Why is specifying the consequences of doing a bad job with maintaining
ones debian packages threatening?

Personally I believe it is time we made clear and written down
explanations on what will happen to badly maintained packages, and
then implement it, to make sure the quality of the packages still in
Debian when this policy is implement is higher than the current level.


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

Re: Development standards for unstable

[martin f krafft]

also sprach Florian Weimer <[EMAIL PROTECTED]> [2006.01.12.1209 +0100]:
> > If you'd like to make suggestions about ideas that would be useful,
> 
> What about: stop threatening your fellow developers?

Thanks, Anthony, for the heads-up.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver!
 
echo '[dO%O+38%O+PO/d0<0]Fi22os0CC4BA64E418CE7l0xAP' | dc


signature.asc
Description: Digital signature (GPG/PGP)

Re: Development standards for unstable

[Andreas Tille]

On Thu, 12 Jan 2006, Petter Reinholdtsen wrote:


[Florian Weimer]

What about: stop threatening your fellow developers?


Why is specifying the consequences of doing a bad job with maintaining
ones debian packages threatening?


IMHO it isn't at all.


Personally I believe it is time we made clear and written down
explanations on what will happen to badly maintained packages, and
then implement it, to make sure the quality of the packages still in
Debian when this policy is implement is higher than the current level.


In addition to the list of Anthony I might add:
Require kind of a monthly status report of the maintainer.  There must be a
reason if an RC bug is open longer than a month.  The maintainer should
give reasons like "Need help", "Discussing with upstream", ...
If the RC bug is two month old: "Sorry, got no help", "Upstream is ignorant",
...
If a maintainer would not manage to respond to an RC bug for three months
the package is obviousely not maintained and should be taken over by
somebody else, IMHO.

Kind regards

   Andreas.

--
http://fam-tille.de


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

Re: Development standards for unstable

[Anthony Towns]

On Thu, Jan 12, 2006 at 12:09:04PM +0100, Florian Weimer wrote:
> * Anthony Towns:
> > If you'd like to make suggestions about ideas that would be useful,
> What about: stop threatening your fellow developers?

For instance, bug #303131 has been open since April last year, and
has had no further recorded action since being tagged serious in May
last year.  Sure, it's only half a meg (though 1600 such packages would
be a gigabyte, even if they were all as small as xml2rfc), and sure it's
only had a couple of uploads since then, but it also clutters all our QA
and tracking tools.  Fundamentally, if a package isn't worth the effort
of maintaining to Debian's standards, it shouldn't _be_ in Debian.

And how about not interpreting it as a threat everytime someone indicates
that things might not go 100% how you might wish? Geez.

Cheers,
aj



signature.asc
Description: Digital signature

Re: Canonical's business model

[Frank Küster]

Matt Zimmerman <[EMAIL PROTECTED]> wrote:

> I know that sometimes users do the wrong thing in spite of this, and that's
> unfortunate.  However, given that I've never received an inappropriate
> message from an Ubuntu user about one of my packages in Debian at my
> Maintainer: email address, it seems to me that the volume is probably low
> enough to be no more than an occasional nuisance.

Yes, and one should also take into account the fact that some users
regard a responsive Debian maintainer, or maintainer's mailinglist, as a
general support line for every question remotely related to the
package.  It's no more than an occasional nuisance, either, probably
comparable. 

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

Re: Bug#347617: ITP: itrans -- Converts romanised Indic text to LaTeX, HTML & Postscript

[Frank Küster]

Baishampayan Ghose <[EMAIL PROTECTED]> wrote:

> Package: wnpp
> Severity: wishlist
> Owner: Baishampayan Ghose <[EMAIL PROTECTED]>
>
>
> * Package name: itrans
>   Version : 5.3
>   Upstream Author : Avinash Chopde <[EMAIL PROTECTED]>
> * URL : http://www.aczoom.com/itrans/

How did you manage to download the sources from there?  I get:

$ ftp ftp.aczoom.com
Connected to ftp.aczoom.com.
220-- Welcome to Pure-FTPd [TLS] --
220-You are user number 2 of 250 allowed.
220-Local time is now 07:28. Server port: 21.
220 You will be disconnected after 4 minutes of inactivity.
421 Unable to set up secure anonymous FTP
Login failed.

Regards, Frank

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

Re: Bug#347617: ITP: itrans -- Converts romanised Indic text to LaTeX, HTML & Postscript

[Yves-Alexis Perez]

Frank Küster wrote:
> Baishampayan Ghose <[EMAIL PROTECTED]> wrote:

> How did you manage to download the sources from there?  I get:

ftp://ftp%40aczoom%2Ecom:[EMAIL PROTECTED]/itrans/53/itrans53.zip

Link is on http://www.aczoom.com/itrans/#download

Regards,
-- 
Yves-Alexis Perez



signature.asc
Description: OpenPGP digital signature

Re: Development standards for unstable

[Steve Langasek]

On Thu, Jan 12, 2006 at 01:00:50PM +0100, Andreas Tille wrote:
> On Thu, 12 Jan 2006, Petter Reinholdtsen wrote:

> >[Florian Weimer]
> >>What about: stop threatening your fellow developers?

> >Why is specifying the consequences of doing a bad job with maintaining
> >ones debian packages threatening?

> IMHO it isn't at all.

> >Personally I believe it is time we made clear and written down
> >explanations on what will happen to badly maintained packages, and
> >then implement it, to make sure the quality of the packages still in
> >Debian when this policy is implement is higher than the current level.

> In addition to the list of Anthony I might add:
> Require kind of a monthly status report of the maintainer.  There must be a
> reason if an RC bug is open longer than a month.  The maintainer should
> give reasons like "Need help", "Discussing with upstream", ...
> If the RC bug is two month old: "Sorry, got no help", "Upstream is 
> ignorant",
> ...
> If a maintainer would not manage to respond to an RC bug for three months
> the package is obviousely not maintained and should be taken over by
> somebody else, IMHO.

I think the problem with saying "it should be taken over by somebody else",
is this:



35 open RC bugs on orphaned packages at severity: serious or higher, some of
them months or even years old.  14 of them are on packages with versions in
testing (these would be the ones with the newer RC bugs), the rest are on
packages that are not candidates for release in etch.

If RC bugs go unanswered for 3 months, I agree that something should be
done; I just don't think that saying someone else should take it over is
necessarily enough.  I believe we need clearer methods for handling packages
in the case that *no one* is handling them, nor will do so.

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

[Roger Leigh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Martin Meredith <[EMAIL PROTECTED]> writes:

> I can definately understand some DD's views here - they seem to get
> nothing from ubuntu - have to wade through patches or whatever to try
> and find the useful stuff - have to do all this work to get all the
> stuff from ubuntu, because whatever ubuntu dev is doing things isn't
> contributing back to debian. This definately happens. There's no doubt
> about it.
>
> 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.
>
> I eventually gave up trying contacting that maintainer - and just
> carried on with the work in ubuntu - and worked with upstream. It's
> people like that that are spoiling it, as I've had experiences with
> other DD's who've been very helpful indeed.

This is definitely a problem, and it's not limited to Ubuntu
maintainers being ignored.  Some Debian developers are completely
non-responsive to everybody, including users and fellow developers.
Being a volunteer project, a delay is understandable, but a month is
not.  When a maintainer is unresponsive/uncooperative, they are
falling short of their duties as a package maintainer, and I think
that we do need a better mechanism for dealing with it, not least a
way to notify the project about it in the first instance.

We do have the Technical Committee, but this is mainly focussed upon
technical issues, and it's not widely known outside Debian.  Perhaps
its role could be widened, or an alternative committee created to deal
with it.

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

Agreed.  I think Debian has gone past the size where non-responsive
maintainers can be coped with.  They cause huge delays in big
transitions, because they hold up all dependent packages while others
do their work for them, and unmaintained and buggy packages lower the
quality of the distribution.

I don't know if you read my other mail, but I do find it hard to
cooperate with Ubuntu for my own package, because each time it has
been uploaded to Ubuntu it was done my a different person, so I don't
know who I should be cooperating /with/.  For large and important
packages, this isn't a problem, but for others it's difficult.


Regards,
Roger

- -- 
Roger Leigh
Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
Debian GNU/Linuxhttp://www.debian.org/
GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ 

iD8DBQFDxlNGVcFcaSW/uEgRAsA6AJ9xh6FeipzRZBhymxNXQZyXzHmr/wCg4BgQ
ruJGjBikSN1Z1ABaMvoaT7o=
=6kXc
-END PGP SIGNATURE-


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

Re: Canonical's business model

[Gustavo Franco]

On 1/11/06, Daniel Ruoso <[EMAIL PROTECTED]> wrote:
> Em Qua, 2006-01-11 às 14:36 -0800, Thomas Bushnell BSG escreveu:
> > Gustavo Franco <[EMAIL PROTECTED]> writes:
> > > It was already discussed[0], and there's no consensus on this idea of
> > > "every Ubuntu changeset, a patch in Debian BTS" between DDs.
> > Right.  I want Ubuntu to exercise judgment, and not just give a big
> > pile of patches, some of which are Debian-relevant and some of which
> > are not.  Think, for example, of the normal way a Debian developer
> > should interact with upstream.
>
> This is exactly the point, what can I do with a patch if I don't know
> why it's there? Which problem is it trying to address (I know, I can
> read the patch and guess, but WTF), and why such solution was adopted...
> Everytime I submit a patch, I also submit this reasoning...

I disagree with a pile of patches and as i said it would be better a
revision control system and good log (and debian/changelog) entries.
We can use PTS (and we're doing already in a way) to be warned about
new patches. I don't think Canonical will put money on judging by DDs,
in the end it's up to us include or not the change.

If they want to promote that they give us something back their
reponsability is keep things more organized (for DDs and NMs) and
publish somewhere what exactly they're giving back (for the
community), IMHO. Does it mean that they're not contributing? No,
they're believe in me. We just need to do our homework, and inform
them that we can do the things in a better way.

--
Gustavo Franco

Re: Canonical's business model

[Gustavo Franco]

On 1/11/06, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote:
> Gustavo Franco <[EMAIL PROTECTED]> writes:
>
> (...)
>
> > I don't
> > remember Linspire, Progeny, ... employees doing the same thing so it
> > makes no sense rant against Canonical only.
>
> On the other hand, Linspire and Progeny do not pretend to be
> cooperating with Debian.

Yes, they do. Progeny[0] even has a Ubuntu' similar page[1]. Linspire
doesn't do much noise about that but, sponsor events. I'm not saying
that both companies don't give something back to Debian, but we never
discussed if it was being done in the right way. If we started with
Canonical great, but we need to consider others too, IMHO.

[0] = http://www.progeny.com/partners/debian.htm
[1] = http://www.ubuntu.com/ubuntu/relationship

--
Gustavo Franco

Re: Development standards for unstable

[Olaf van der Spek]

On 1/12/06, Andreas Tille <[EMAIL PROTECTED]> wrote:
> On Thu, 12 Jan 2006, Petter Reinholdtsen wrote:
>
> > [Florian Weimer]
> >> What about: stop threatening your fellow developers?
> >
> > Why is specifying the consequences of doing a bad job with maintaining
> > ones debian packages threatening?
>
> IMHO it isn't at all.
>
> > Personally I believe it is time we made clear and written down
> > explanations on what will happen to badly maintained packages, and
> > then implement it, to make sure the quality of the packages still in
> > Debian when this policy is implement is higher than the current level.
>
> In addition to the list of Anthony I might add:
> Require kind of a monthly status report of the maintainer.  There must be a
> reason if an RC bug is open longer than a month.  The maintainer should
> give reasons like "Need help", "Discussing with upstream", ...
> If the RC bug is two month old: "Sorry, got no help", "Upstream is ignorant",
> ...
> If a maintainer would not manage to respond to an RC bug for three months
> the package is obviousely not maintained and should be taken over by
> somebody else, IMHO.

I wish something like that applied to all bugs.
There are packages that have seen little updates for months/years with
lots of wishlist bugs.

Re: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=265920

[Anthony DeRobertis]

Felipe Sateler wrote:

> This seems like a nice idea. File a whishlist bug against reportbug ;)
> 

If you really want to do this, look at
/usr/share/doc/reportbug/README.developers.


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

Re: Development standards for unstable

[Andreas Tille]

On Thu, 12 Jan 2006, Steve Langasek wrote:


If RC bugs go unanswered for 3 months, I agree that something should be
done; I just don't think that saying someone else should take it over is
necessarily enough.  I believe we need clearer methods for handling packages
in the case that *no one* is handling them, nor will do so.


Well "no one" is kind of a meta-"someone else" and is equal to droping
the package.  (I know that this is not always reasonable.)

Kind regards

 Andreas.

--
http://fam-tille.de


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

Re: Development standards for unstable

[Thomas Viehmann]

Hi,

first of all, thanks for taking the initiative I think the matter is too
important to be left alone just for avoiding to step on anyones toes.

Anthony Towns wrote:
> Random ideas for negative consequences might include forced
> orphaning by overriding maintainer fields to debian-qa, removal of
Maybe this should not only be limited to packages with RC bugs... For a
lot of packages with inactive maintainers, it might be best to not
release them in etch.

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: Canonical's business model

[Gustavo Franco]

On 1/11/06, Andrew Suffield <[EMAIL PROTECTED]> wrote:
> On Wed, Jan 11, 2006 at 03:25:01PM -0200, Gustavo Franco wrote:
> (...)
> > Are you saying that they're spending more money with PR than really
> > contributing back ?
>
> I don't know about money, but I'm pretty sure their claims exceed
> their actions. I think that a sufficient response is to point this out
> whenever people start worshipping Canonical in public.

If it's a reality, it's up to us inform them that they're spending
more words than work giving Debian something back. In my view, they're
just organizing and publishing the contributions in a way that aren't
satisfiying the Debian majority.

We are complaining about different aspects and some of them were
already addressed, others aren't. Let me try list some of them:

We don't like:
- Canonical is saying more than doing (is it a consensus?);

- Scott's pile of patches and utnubu by_maint list isn't enough;

What we want:
- DDs wants to know when there's a patch for their packages into
Ubuntu that applies to Debian. PTS already lists them in "Patches"
section but it links to Scott's patches and we don't like them, right?
I think we can ask for a revision control system from them and do some
work on PTS (if possible) to mail us or just list the logs in the
website.

Solved stuff (IMHO):
- If you talk with a Ubuntu developer or contributor probably he won't
ignore you. Many of us tried and some are working together with us on
alioth projects or something else;

- The Ubuntu 'universe' has packages that Debian hasn't. There's a
initiative there to contribute back to Debian;

- We won't accept automatic bug reports with each changeset as a patch
for every changed package in Ubuntu;

I'm sure that you can help me with this list, and i think that we can
keep the discussion around "what we have", "what we need", 'what is
solved", things like that. We need to define it, and not only point
the (past and current) problems.

Closing, i hope to see the same effort spread over others Debian
"related" companies and their business model.

--
Gustavo Franco

Re: Canonical's business model

[Gustavo Franco]

On 1/11/06, Gustavo Noronha Silva <[EMAIL PROTECTED]> wrote:
> Em Qua, 2006-01-11 às 19:54 -0300, Daniel Ruoso escreveu:
> > Em Qua, 2006-01-11 às 14:36 -0800, Thomas Bushnell BSG escreveu:
> > > Gustavo Franco <[EMAIL PROTECTED]> writes:
> > > > It was already discussed[0], and there's no consensus on this idea of
> > > > "every Ubuntu changeset, a patch in Debian BTS" between DDs.
> > > Right.  I want Ubuntu to exercise judgment, and not just give a big
> > > pile of patches, some of which are Debian-relevant and some of which
> > > are not.  Think, for example, of the normal way a Debian developer
> > > should interact with upstream.
> >
> > This is exactly the point, what can I do with a patch if I don't know
> > why it's there? Which problem is it trying to address (I know, I can
> > read the patch and guess, but WTF), and why such solution was adopted...
> > Everytime I submit a patch, I also submit this reasoning...
>
> That's sometimes documented in the changelog. I benefited quite a lot
> from the ubuntu patches for gksu, and I've worked quite nicely with
> seb128 and mvo on issues like this one and update-manager.

I agree, things like that are happenning all the time but many DDs
just don't know and Canonical is failing to inform the community how
and where they're helping. I think they're just saying that they're
helping a lot.

> (...)

--
Gustavo Franco

Re: Canonical's business model

[Gustavo Franco]

On 1/11/06, Steve Langasek <[EMAIL PROTECTED]> wrote:
> On Wed, Jan 11, 2006 at 05:48:22PM -0200, Gustavo Franco wrote:
> > On 1/11/06, Daniel Ruoso <[EMAIL PROTECTED]> wrote:
> > > Em Qua, 2006-01-11 às 16:48 +0100, martin f krafft escreveu:
> > > > What would you like to see?
>
> > > I think submitting bugs and patches to the BTS would already be enough.
>
> > It was already discussed[0], and there's no consensus on this idea of
> > "every Ubuntu changeset, a patch in Debian BTS" between DDs. I don't
> > remember Linspire, Progeny, ... employees doing the same thing so it
> > makes no sense rant against Canonical only. There's scott's patches
> > list[1] that sucks IMHO,  and utnubu one[2]. AFAIK, some PTS work was
> > already done too so we (probably) are listing if there's a ubuntu
> > patch in every Debian package from qa.d.o. After all, do you still
> > want annoying automatic bug reports?
>
> > We've a lot more volunteers than Canonical, if you want to change the
> > scenario (and i'm not writing to Daniel only) you should join
> > utnubu[3] and help,
>
> Of course people can do this, but this is so very much not the point.  The
> point is that publishing source packages on a website that people have to
> poll is not "giving back to Debian", and AFAICT the majority of changes
> Ubuntu makes to packages are only made available to Debian in this format.
> This includes many changes in Ubuntu's universe section[1] which I think it's
> bad strategy to be making externally to Debian in the first place if
> they're serious about limiting divergence from Debian.

I agree with the poll thing, but the 'giving back to Debian' applies
when you think about things like xorg (David even wrote it), gksu
(kov), pkg-ltsp, some other transitions and i'm sure that someone can
came up with a better list than me.

> I've also seen Canonical employees make comments in the past to the effect
> that Debian has an obligation to meet Ubuntu part-way (read: monitor
> Ubuntu's changes) on the question of integrating their changes back into
> sid.  This is either a wholly unrealistic assessment of the scalability
> issues with coordinating between the many CDDs and Debian derivatives in
> existence, or simply hubris regarding Ubuntu's privileged position within
> the Debian cosmos; but in either case, it does not support the thesis that
> Canonical systematically "gives back to Debian" or that they have
> succeeded in structuring Ubuntu's culture in a way that promotes such giving
> back.

They give something back to Debian (see above), the current problems
are around the way they're informing us about their patches not if
they contribute or not. They contribute, the people are just mixing up
the patch handling issue with others contributions.

> All of which is fine, and the right of anyone working off of Debian (hurray
> Free Software!), up until the point where one starts claiming to be giving
> back to Debian when by and large they are not; and I'm afraid this does seem
> to be the case with Ubuntu today.

They're saying that really, but they're not saying that every patch is
classified and informed to us. With that in mind, they're not lying
and contributing something back. If it's enough or not and how it
could be better, i'm trying to discuss.

--
Gustavo Franco

Re: libecw

[Anthony DeRobertis]

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:

FYI, the right place to ask this is [EMAIL PROTECTED]
Moving it over there. Full-quoting because of this.

Summary: I don't believe this is a free software licence, failing at
least DFSG 3, 4, and 9. It may additionaly fail DFSG 6. Due to the
failure of DFSG 9, I doubt this can even go in non-free.


> 
> Use of the ECW SDK with Unlimited Decompressing and Unlimited Compression for
> applications licensed under a GNU General Public style license ("GPL") is
> governed by the "ECW SDK PUBLIC USE LICENSE AGREEMENT".

Not sure what they're thinking, as this definitely isn't GPL-compatible.

> 
> 
> * About modifications:
> 
> b)You may make modifications to the Software and distribute your
> modifications, in a form that is separate from the Software, such as 
> patches. The following restrictions apply to modifications: 

Requiring patches is allowed as an explicit exception given in DFSG.
However, I don't see anything allowing us to distribute binaries built
from patched sources, thus this seems to fail DFSG 4 ("[t]he license
must explicitly permit distribution of software built from modified
source code.")

> i)Modifications must not alter or remove any copyright notices in the
> Software. 

This is acceptable, provided they're actually reasonable copyright notices.

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

I'm uncomfortable with this, but considering the other problems I can
punt on deciding :-D

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

Fails DFSG 3.

> iv)   You are not permitted to use Software Product for development or
> distribution of "Server Software" that provides services or 
> functionality on a computer acting as a server.

Fails DFSG 3 and 9 (restriction in this case is "may not be distributed
alongside server software"); also possibly 6.

> 
> 
> * About restriction of use (I just don't know DFARS 252.227-7013 so I have no
> idea what's said in here)

Neither do I.

> 
> 3)U.S. GOVERNMENT RESTRICTED RIGHTS. 
> The SOFTWARE PRODUCT and documentation are provided with RESTRICTED RIGHTS.
> Use, duplication, or disclosure by the US Government is subject 
> to restrictions as set forth in subparagraph (c)(1)(ii) of The Rights in
> Technical Data and Computer Software clause at DFARS 252.227-7013 
> or subparagraphs (c)(1) and (2) of the Commercial Computer Software -
> Restricted Rights at 48 CFR 52.227-19, as applicable. Manufacturer is 
> Earth Resource Mapping Limited.
> 
> 4)DESCRIPTION OF OTHER RIGHTS AND LIMITATIONS. 
> a)Rental. You may not rent, lease or lend the SOFTWARE PRODUCT. 

Not sure how this affects DFSG freeness. I can't think of a single free
license we've seen on -legal with similar provisions.


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

Re: Canonical's business model

[Gustavo Franco]

On 1/12/06, Joey Hess <[EMAIL PROTECTED]> wrote:
> Gustavo Franco wrote:
> > I agree with "similar things being said" but i'm yet to hear about the
> > lack of collaboration and give Debian something back. For example: I
> > don't remember too much people caring about PGI (Progeny) and after
> > that anaconda "port" to say that they weren't contributing the
> > installer efforts to us, even when d-i was already there.
>
> FWIW, progeny uploaded pgi to Debian (I forget if it ever made it out of
> incoming) and have contributed back other tools like pickaxe too (pity
> we haven't tried to use it and are still stuck with the Evil that is
> debian-cd). I think it was pretty clear by the time their anaonda port
> came around that Debian was not very interested it it except possibly as
> a fallback if d-i failed to materialize.

AFAIK, PGI reached our repositories but my point was that nobody
complained that if they're doing the things in the right way. Were all
the Progeny patches (i'm not talking about new packages) listed,
informed, considered, or even reviewed to Debian ? We're doing
considerations about Canonical way that should be involve at least
Progeny too, since we're listed at partners.

--
Gustavo Franco

Re: Bug#347617: ITP: itrans -- Converts romanised Indic text to LaTeX, HTML & Postscript

[Frank Küster]

Yves-Alexis Perez <[EMAIL PROTECTED]> wrote:

> Frank Küster wrote:
>> Baishampayan Ghose <[EMAIL PROTECTED]> wrote:
>
>> How did you manage to download the sources from there?  I get:
>
> ftp://ftp%40aczoom%2Ecom:[EMAIL PROTECTED]/itrans/53/itrans53.zip

That's exactly what I tried - it doesn't matter which "password" or
username I send.  The error message points to a screwed up setup of the
FTP server, according to Google; but if it works for you it's obviously
more complicated...

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

Re: Development standards for unstable

[Thijs Kinkhorst]

On Thu, January 12, 2006 14:23, Thomas Viehmann wrote:
>> Random ideas for negative consequences might include forced
>> orphaning by overriding maintainer fields to debian-qa, removal of
> Maybe this should not only be limited to packages with RC bugs... For a
> lot of packages with inactive maintainers, it might be best to not
> release them in etch.

While the package might not be of the quality we strive to achieve within
Debian; if a bug is not release critical we consider the bug not to be
serious enough to impact the packages' releaseworthyness. This is by
definition. Even if there are many of those bugs, they appearently do not
prevent the core functionality from working.

I very much agree that we should strive to make packages as good as
possible, but if users depend on a package and there are no real
showstoppers in it, we might do our users a better service with shipping
than with not shipping the package.


Thijs


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

Fwd: Bug#344758: init.d script should create /var/run/dirmngr

[Thomas Hood]

The submitter of #344758 wrote:
> The script should create /var/run/dirmngr to allow users to map their
> /var/run to a temporary filesystem like tmpfs. Thanks.

Peter Eisentraut wrote:
> What do you think about this request?  It seems reasonable, but I think if 
> this should be supported, there ought to be a general policy (formal or 
> informal) on it because I think many other init scripts will suffer from 
> similar problems.


A program that needs to put files into a subdirectory of /var/run/ should
create the required subdirectory itself at run time.  This can be done by
an initscript or by the program itself if it runs as root.  Remember ownership
and permissions.

[ ! -d /var/run/foo ] && mkdir --mode=755 /var/run/foo && chown 
foouser:foogroup /var/run/foo

Do this no sooner than /etc/rcS.d/S47 and no later than when the dir is needed. 
 :)

As pointed out by Peter Samuelson, this dir should be removed by the postrm on
purge.  I would advise not including /var/run/foo in the package since it is
superfluous and its presence could hide a bug in your directory-creation code.
-- 
Thomas Hood


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

Re: Development standards for unstable

[Thomas Viehmann]

Thijs Kinkhorst wrote:
> I very much agree that we should strive to make packages as good as
> possible, but if users depend on a package and there are no real
> showstoppers in it, we might do our users a better service with shipping
> than with not shipping the package.
No. Shipping unsupported packages no developer cares about is a bad idea.
Really, how about just automatically[1] removing orphaned packages
without maintained rdepends from testing?

Kind regards

T.

[1] And yes, I'd maintain a list if it's considered a good idea.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


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

Re: Development standards for unstable

[Andreas Tille]

On Thu, 12 Jan 2006, Thijs Kinkhorst wrote:


While the package might not be of the quality we strive to achieve within
Debian; if a bug is not release critical we consider the bug not to be
serious enough to impact the packages' releaseworthyness. This is by
definition. Even if there are many of those bugs, they appearently do not
prevent the core functionality from working.


Well the definition is given in policy and a policy change (to be discussed)
might change the definition of release critical.  So if we define that 
numbers N_n normal bugs and N_i important bugs and  time spans T_n and

T_i where a bug is completely unattended by the maintainer (e.i. no
comments, no reason why not fixed, etc.) we can define a measure

X = Sum(N_n * T_n) + 2 * Sum(N_i * T_i)

and if this measure excedes a certain limit we define this as RC
critical.  This is kind of formal and I have no idea whether this
is reasonable, but by this measure we (well, I know, somebody != me
would really have to do it) could write some automatic test that could
result in an RC bug filed against the package in question that can be
closed by closing (or commenting / give reasons) a number of the bugs
named above which brings the measure below the threshold we defined.

Just my 2 Euro cents

 Andreas.

--
http://fam-tille.de


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

Re: Development standards for unstable

[Frank Küster]

"Thijs Kinkhorst" <[EMAIL PROTECTED]> wrote:

> On Thu, January 12, 2006 14:23, Thomas Viehmann wrote:
>>> Random ideas for negative consequences might include forced
>>> orphaning by overriding maintainer fields to debian-qa, removal of
>> Maybe this should not only be limited to packages with RC bugs... For a
>> lot of packages with inactive maintainers, it might be best to not
>> release them in etch.
>
> While the package might not be of the quality we strive to achieve within
> Debian; if a bug is not release critical we consider the bug not to be
> serious enough to impact the packages' releaseworthyness. This is by
> definition. Even if there are many of those bugs, they appearently do not
> prevent the core functionality from working.
>
> I very much agree that we should strive to make packages as good as
> possible, but if users depend on a package and there are no real
> showstoppers in it, we might do our users a better service with shipping
> than with not shipping the package.

Well, that depends on which kind of package it is:  If the package is 
mainly a dependency of other packages, or something with a long history
(like texinfo which was unmaintained for months if not years until
Norbert Preining took it last autumn), you are right.  

But if a rather new package in active development has many non-RC bugs,
some of them crippling upstream features, and one of them "New version
N.m.o available" (retitled three times meanwhile), then our users are
probably better served by telling them "We can't provide a properly
integrated package, please install it into /usr/local".

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

Re: Canonical's business model

[Manoj Srivastava]

On Wed, 11 Jan 2006 17:48:22 -0200, Gustavo Franco <[EMAIL PROTECTED]> said: 

> On 1/11/06, Daniel Ruoso <[EMAIL PROTECTED]> wrote:
>> Em Qua, 2006-01-11 às 16:48 +0100, martin f krafft escreveu:
>> > What would you like to see?
>> 
>> I think submitting bugs and patches to the BTS would already be
>> enough.
>> 

> It was already discussed[0], and there's no consensus on this idea
> of "every Ubuntu changeset, a patch in Debian BTS" between DDs.

Of course there is no consensus on that, it's a silly
 proposal. However, "every non-branding feature in ubuntu, a wishlist
 bug and targeted patch in debian" would be close to finding consensus.

manoj
-- 
One small step for man, one giant stumble for mankind.
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: Canonical's business model

[Manoj Srivastava]

On Thu, 12 Jan 2006 11:17:55 -0200, Gustavo Franco
<[EMAIL PROTECTED]> said:  

> I disagree with a pile of patches and as i said it would be better a
> revision control system and good log (and debian/changelog) entries.

How is a revision control system (BTW, all of my packages are
 in a public repo on arch.debian.org) help much in the way of
 providing feedback? The best way to work with upstreams is to provide
 minimal patches that implement a feature, or fix a bug, and
 preferably, each patch addressing one or few related issues.

Calling for revision control systems seems like a red
 herring -- and is impractical, anyway, since getting upstream to all
 use the same version control system is not going to work.

> We can use PTS (and we're doing already in a way) to be warned about
> new patches. I don't think Canonical will put money on judging by
> DDs, in the end it's up to us include or not the change.

Umm, every single patch in a downstream repo, all jumbled up
 with other changes, is not much use. I would never subject my
 upstreams to it -- I submit specific, minimal patches, one feature at
 a time, to upstream, since that makes it more likely to be
 integrated. 

> If they want to promote that they give us something back their
> reponsability is keep things more organized (for DDs and NMs) and
> publish somewhere what exactly they're giving back (for the
> community), IMHO. Does it mean that they're not contributing? No,
> they're believe in me. We just need to do our homework, and inform
> them that we can do the things in a better way.

That is just talk. Actually doing something that establishes
 the feed back channel would be laudable, mere talk isn't worth spit.

manoj
-- 
Now is the time for all good men to come to. Walt Kelly
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: Bug#347617: ITP: itrans -- Converts romanised Indic text to LaTeX, HTML & Postscript

[Yves-Alexis Perez]

Frank Küster wrote:
> Yves-Alexis Perez <[EMAIL PROTECTED]> wrote:
> 
> 
>>Frank Küster wrote:
>>
>>>Baishampayan Ghose <[EMAIL PROTECTED]> wrote:
>>
>>>How did you manage to download the sources from there?  I get:
>>
>>ftp://ftp%40aczoom%2Ecom:[EMAIL PROTECTED]/itrans/53/itrans53.zip
> 
> 
> That's exactly what I tried - it doesn't matter which "password" or
> username I send.  The error message points to a screwed up setup of the
> FTP server, according to Google; but if it works for you it's obviously
> more complicated...

Clicking the link from the download page in firefox shows me the Save As
windows. Using yafc I can download too:

yafc [EMAIL PROTECTED]@ftp.aczoom.com:/itrans/53> ls -l
total 6028634
-rw-r--r--   0 3202932031   33452 Dec  5  2004 itrans-cgi.zip
-rw-r--r--   0 3202932031 1010760 Nov  1  2001 itrans53-i386.tgz
-rw-r--r--   0 3202932031 1132228 Nov  1  2001 itrans53-win32.zip
-rw-r--r--   0 3202932031  103948 Apr 24  2002 itrans53.sit.hqx
-rw-r--r--   0 3202932031  446800 Dec 10  2001 itrans53.zip
-rw-r--r--   0 3202932031  823051 Nov  1  2001 itransfn.zip
-rw-r--r--   0 3202932031 1467360 Nov  1  2001 itransht.zip
-rw-r--r--   0 3202932031 1011035 Nov  1  2001 itransps.zip


Be sure to use:

host: ftp.aczoom.com
login: [EMAIL PROTECTED]
pass: aczoom.com

(not very user-friendly, but still usable)


-- 
Yves-Alexis Perez



signature.asc
Description: OpenPGP digital signature

Re: Development standards for unstable

[Christoph Berg]

Re: Thomas Viehmann in <[EMAIL PROTECTED]>
> Really, how about just automatically[1] removing orphaned packages
> without maintained rdepends from testing?

Seconded.

Christoph
-- 
[EMAIL PROTECTED] | http://www.df7cb.de/


signature.asc
Description: Digital signature

Re: Bug#347617: ITP: itrans -- Converts romanised Indic text to LaTeX, HTML & Postscript

[Andrew Vaughan]

On Fri, 13 Jan 2006 00:58, Frank Küster wrote:
> Yves-Alexis Perez <[EMAIL PROTECTED]> wrote:
> > Frank Küster wrote:
> >> Baishampayan Ghose <[EMAIL PROTECTED]> wrote:
> >>
> >> How did you manage to download the sources from there?  I get:
> >
> > ftp://ftp%40aczoom%2Ecom:[EMAIL PROTECTED]/itrans/53/itrans53
> >.zip
>
> That's exactly what I tried - it doesn't matter which "password" or
> username I send.  The error message points to a screwed up setup of the
> FTP server, according to Google; but if it works for you it's obviously
> more complicated...
>
> Regards, Frank

The ftp: url at http://www.aczoom.com/itrans/#download works just fine in 
Konqueror.  From the console

$ftp ftp.aczoom.com
Name (ftp.aczoom.com:andrew): [EMAIL PROTECTED]
Password:aczoom.com

is also fine.  

Andrew

Re: Need for launchpad

[Manoj Srivastava]

On Thu, 12 Jan 2006 07:36:06 +, Martin Meredith <[EMAIL PROTECTED]> said: 

> Ok - I'm going to reply to the first post i found on this whole -
> thing, so apologies if it shows up in some weird place in threaded
> view.

> Basically - I dont think the brand should be put on ubuntu as a
> whole - feel free to target those people specifically you see not
> contributing - but remember - it's a two way thing - and there are
> people not willing to cooperate on both sides.

> *dons asbestos underwear and waits for replies*

> Manoj Srivastava wrote:
>> On Fri, 06 Jan 2006 15:19:42 -0500, Frans Jessop
>> <[EMAIL PROTECTED]> said:
>> 
>> 
>>> Ubuntu's launchpad is amazing.  Do you think it would be helpful
>>> if all DD's worked through it on their projects?
>> 
>> 
>> Sure, as long as they change lauchpad to meet my workflow
>> requirements. This would mean letting me have a local repo, signed
>> remote repos, arch, email only interfaces, and not getting into my
>> way.  If they make changes to meet these requirements, I'll have
>> absolutely no problem throwing away tools I have worked on honing
>> for a decade or so and switching to launchpad. Oh, and release
>> launchpad under a free license, of course, so I don't make Debian
>> development rely on a non-free toolset, of course.
>> 
>> 
>>> Wouldn't that keep things more organized and efficient?  Or
>>> perhaps Debian could build its own version of launchpad which is
>>> better.  Again, I think it would do a good job keeping everything
>>> organized an efficient.
>> 
>> 
>> Yup. Having all humans speak just a single language (and none of
>> these darned wide charset junk) would be way more efficient too.
>> And just have one model of a car -- I mean, who needs all these
>> different companies, so much inefficiency.
>> 
>> BTW, thanks for the laugh.
>> 

OK. Since you selected my post to reply to -- are you implying
 that choosing not to use a propreitary, non-free, repository system
 for primary debian development, and abandoning my decade old workflow
 processes constitute non-cooperation?

manoj
-- 
You will pay for your sins.  If you have already paid, please
disregard this message.
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: libecw

[Alexander Terekhov]

On 1/12/06, Anthony DeRobertis <[EMAIL PROTECTED]> wrote:
[...]
> > Use of the ECW SDK with Unlimited Decompressing and Unlimited Compression 
> > for
> > applications licensed under a GNU General Public style license ("GPL") is
> > governed by the "ECW SDK PUBLIC USE LICENSE AGREEMENT".
>
> Not sure what they're thinking, as this definitely isn't GPL-compatible.

Which is a felony in the GNU Republic only.

regards,
alexander.

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

[Charles Plessy]

On Thu, Jan 12, 2006 at 02:21:03PM +0100, Olaf van der Spek wrote :
> > ...
> > If a maintainer would not manage to respond to an RC bug for three months
> > the package is obviousely not maintained and should be taken over by
> > somebody else, IMHO.
> 
> I wish something like that applied to all bugs.
> There are packages that have seen little updates for months/years with
> lots of wishlist bugs.

Dear debian developpers,

As suggested on the transient packages.debian.org homepage, I tried to
use apt-file while the site is offline. However, apt-file has a bug in
the definition of its dependancies, which makes it uninstable unless one
manually installs curl before.

Of course, this is trivial, but fixing this bug (251 days old) is
also trivial. Then why complain ? I feel that it gives a bad image of
debian, when it suggests to use a broken tool while another one is being
repaired.

So if you want a basic user to innocently raise the severity of the bug,
so that a developper could NMU a fixed package, just drop me a mail.

Best regards,

-- 
Charles Plessy
Wako, Saitama, Japan


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

Re: Need for launchpad

[Reinhard Tartler]

On 1/12/06, Roger Leigh <[EMAIL PROTECTED]> wrote:

> I don't know if you read my other mail, but I do find it hard to
> cooperate with Ubuntu for my own package, because each time it has
> been uploaded to Ubuntu it was done my a different person, so I don't
> know who I should be cooperating /with/.  For large and important
> packages, this isn't a problem, but for others it's difficult.

If in doubt, you can reach the MOTUs as a whole at
[EMAIL PROTECTED] There (and in our irc channel) you are
most likley to find someone you can help out.

--
regards,
Reinhard

Re: Getting rid of circular dependencies, stage 3

[Bill Allombert]

On Thu, Jan 12, 2006 at 09:26:26AM +0100, Josselin Mouette wrote:
> Le jeudi 12 janvier 2006 ? 01:49 +0100, Jeroen van Wolffelaar a ?crit :
> > > At the very least, I think they should be treated like pre-depends, with
> > > a request on this list being mandatory before adding a circular
> > > dependency. Until now, all circular dependencies cases I have met were
> > > fixable. At first, some of them looked necessary and they required quite
> > > some work, but they were fixable.
> > 
> > You know when you're adding a pre-depends. You're typing the word
> > "Pre-Depends" in a debian/control file.
> > 
> > You don't know when you're introducing a circular depends that easily,
> > and it could be either of the packages in the circle that shouldn't have
> > such a depends, not necessarily the last one that closed the circle
> > should change.
> 
> Sure, and I agree Bill's checks should go on. However, looking at the
> list, a vast majority of circular dependencies come from the same source
> package. This could be checked e.g. by lintian.

This is lintian wishlist item #316283.

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: Canonical's business model

[David Nusinow]

On Thu, Jan 12, 2006 at 11:47:53AM -0200, Gustavo Franco wrote:
> On 1/11/06, Steve Langasek <[EMAIL PROTECTED]> wrote:
> > Of course people can do this, but this is so very much not the point.  The
> > point is that publishing source packages on a website that people have to
> > poll is not "giving back to Debian", and AFAICT the majority of changes
> > Ubuntu makes to packages are only made available to Debian in this format.
> > This includes many changes in Ubuntu's universe section[1] which I think 
> > it's
> > bad strategy to be making externally to Debian in the first place if
> > they're serious about limiting divergence from Debian.
> 
> I agree with the poll thing, but the 'giving back to Debian' applies
> when you think about things like xorg (David even wrote it), gksu
> (kov), pkg-ltsp, some other transitions and i'm sure that someone can
> came up with a better list than me.

Perhaps I was unclear in my previous post. What I said wasn't that
Canonical was going out of their way as a company to give back to Debian.
What I said was that Daniel and I established a personal and working
relationship that allowed us to bring the changes back in to Debian.

Fundamentally, I had to do the exact same thing for xorg as anyone else had
to do for patches to their packages. I downloaded the sources to the
breezy(?) packages, looked through each and every packaging file and
diff'ed it against our xfree86 packages, and applied what I wanted.

What Daniel did was be there for me to ask questions of, compare notes, and
occasionally offer fixes when he had the time. As far as I know this wasn't
any corporate decision by Canonical to give back to Debian, but it was a
personal decision by Daniel to help me (for which I'm immensely grateful).

The greatest strength of having Canonical on our side, from my POV, is that
it's a company full of people like Daniel, who are fundamentally Debian
people, and who are willing to work with you on this kind of personal
level. I don't really buy in to their whole "giving back to Debian" thing
(because they didn't really "give back" xorg, I had to take it after they
made it for themselves) but they do present a great opportunity for us to
establish these kinds of working relationships.

 - David Nusinow


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

Re: Development standards for unstable

[Andreas Barth]

* Christoph Berg ([EMAIL PROTECTED]) [060112 16:28]:
> Re: Thomas Viehmann in <[EMAIL PROTECTED]>
> > Really, how about just automatically[1] removing orphaned packages
> > without maintained rdepends from testing?
> 
> Seconded.

well, just make a list that I can just copy into my hint file.


Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


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

Re: Canonical's business model

[Otavio Salvador]

Joey Hess <[EMAIL PROTECTED]> writes:

> Gustavo Franco wrote:
>> I agree with "similar things being said" but i'm yet to hear about the
>> lack of collaboration and give Debian something back. For example: I
>> don't remember too much people caring about PGI (Progeny) and after
>> that anaconda "port" to say that they weren't contributing the
>> installer efforts to us, even when d-i was already there.
>
> FWIW, progeny uploaded pgi to Debian (I forget if it ever made it out of
> incoming) and have contributed back other tools like pickaxe too (pity
> we haven't tried to use it and are still stuck with the Evil that is
> debian-cd). I think it was pretty clear by the time their anaonda port
> came around that Debian was not very interested it it except possibly as
> a fallback if d-i failed to materialize.

Also discover1 and discover2.

-- 
O T A V I OS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://www.freedom.ind.br/otavio
-
"Microsoft gives you Windows ... Linux gives
 you the whole house."


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

[Steinar H. Gunderson]

On Fri, Jan 13, 2006 at 12:03:28AM +0900, Charles Plessy wrote:
> Of course, this is trivial, but fixing this bug (251 days old) is
> also trivial. Then why complain ? I feel that it gives a bad image of
> debian, when it suggests to use a broken tool while another one is being
> repaired.

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.

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.

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


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

Re: Development standards for unstable

[Martin Michlmayr]

* Christoph Berg <[EMAIL PROTECTED]> [2006-01-12 16:05]:
> Re: Thomas Viehmann in <[EMAIL PROTECTED]>
> > Really, how about just automatically[1] removing orphaned packages
> > without maintained rdepends from testing?
> 
> Seconded.

I don't think it's such a great idea (at least not done by itself).
While the focus on testing is natural since this is what we release,
this proposal has the potential of leaving lots of cruft in unstable
You can remove packages from testing automatically but please *also*
mail debian-qa and propose removing the sources from unstable if this
makes sense.

I've regularly removed orphaned packages from unstable in the past but
I've been a bit busy with other work recently. If you, Thomas or
Christoph (or someone else), could help a hand, it would certainly be
appreciated.
-- 
Martin Michlmayr
http://www.cyrius.com/


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

Re: Development standards for unstable

[Adeodato Simó]

* Christoph Berg [Thu, 12 Jan 2006 16:05:52 +0100]:

> Re: Thomas Viehmann in <[EMAIL PROTECTED]>
> > Really, how about just automatically[1] removing orphaned packages
> > without maintained rdepends from testing?

> Seconded.

  Me too.

  (jftr, http://lists.debian.org/debian-qa/2004/06/msg00176.html)

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
America may be unique in being a country which has leapt from barbarism
to decadence without touching civilization.
-- John O'Hara


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

Re: Development standards for unstable

[Thijs Kinkhorst]

On Thu, January 12, 2006 16:02, Frank Küster wrote:
> But if a rather new package in active development has many non-RC bugs,
> some of them crippling upstream features, and one of them "New version
> N.m.o available" (retitled three times meanwhile), then our users are
> probably better served by telling them "We can't provide a properly
> integrated package, please install it into /usr/local".

There's of course a lot of room for nuance; a "NPOASR" package deserves a
lot less patience than a package already in stable. But in general, if we
shipped something, people are probably using it, and if there's no
pressing reason to remove it (e.g.: it doesn't work), quite some bugs but
none serious, we could be better of just shipping it. In the worst case it
hasn't been improved since the last release, but will at least work just
as well.


Thijs


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

Re: Development standards for unstable

[Andreas Barth]

* Thomas Viehmann ([EMAIL PROTECTED]) [060112 15:56]:
> Thijs Kinkhorst wrote:
> > I very much agree that we should strive to make packages as good as
> > possible, but if users depend on a package and there are no real
> > showstoppers in it, we might do our users a better service with shipping
> > than with not shipping the package.
> No. Shipping unsupported packages no developer cares about is a bad idea.

Well, by definition if a package is too broken to support it, the bug is
RC.


Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


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

Re: Canonical's business model

[Frank Küster]

David Nusinow <[EMAIL PROTECTED]> wrote:

> The greatest strength of having Canonical on our side, from my POV, is that
> it's a company full of people like Daniel, who are fundamentally Debian
> people, and who are willing to work with you on this kind of personal
> level. I don't really buy in to their whole "giving back to Debian" thing
> (because they didn't really "give back" xorg, I had to take it after they
> made it for themselves) but they do present a great opportunity for us to
> establish these kinds of working relationships.

It seems to me that there's one particular point where they actively
give back, and that is: security.  I've seen loads of security patches
created by Martin Pitt, applied to Ubuntu *and* submitted as bugs to our
BTS. 

I can't say that I've already built up a working relationship with
Martin, but I've communicated very well with him.  However, I believe
that the reason might not only be Martin's commitment to "give back" to
Debian, but rather the completely egoistic desire not to be forced to
maintain a bunch of security patches that are not in Debian.

Be the reason whatever it is, I think that we have profited from it, and
personally I thank Martin very much!

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

Re: Canonical's business model

[Raphael Hertzog]

On Wed, 11 Jan 2006, Gustavo Franco wrote:
> I see, i would like to see the utnubu patch list[0] integrated in PTS
> (scott's already is[1]), with that everyone subscribed to the package

The patch list from utnubu is the same than the one from Scott, so there's
no point to add a pointer to the utnubu patch repository. The utnubu
repository adds "diffstat" about the patch and a sort by maintainer.
Since the PTS is package-oriented and not developer-oriented, it doesn't
bring anything interesting.

> could receive a mail after a patch shows up there. I'm sure that
> Rafael or someone else said something about it, but not the entire
> idea. Is it possible, Rafael?

Everything is possible, please start hacking your own script which mails
@packages.qa.debian.org ... we can integrate it in the PTS when
you want after that. :-)

http://wiki.debian.org/qa.debian.org/pts

Cheers,
-- 
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: Development standards for unstable

[Frank Küster]

Andreas Barth <[EMAIL PROTECTED]> wrote:

> * Christoph Berg ([EMAIL PROTECTED]) [060112 16:28]:
>> Re: Thomas Viehmann in <[EMAIL PROTECTED]>
>> > Really, how about just automatically[1] removing orphaned packages
>> > without maintained rdepends from testing?
>> 
>> Seconded.
>
> well, just make a list that I can just copy into my hint file.

Hm, I can't find the context:  Are you talking about all such packages,
or only packages with RC bugs?  

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

Re: Development standards for unstable

[Andreas Barth]

* Frank Küster ([EMAIL PROTECTED]) [060112 18:11]:
> Andreas Barth <[EMAIL PROTECTED]> wrote:
> 
> > * Christoph Berg ([EMAIL PROTECTED]) [060112 16:28]:
> >> Re: Thomas Viehmann in <[EMAIL PROTECTED]>
> >> > Really, how about just automatically[1] removing orphaned packages
> >> > without maintained rdepends from testing?
> >> 
> >> Seconded.
> >
> > well, just make a list that I can just copy into my hint file.
> 
> Hm, I can't find the context:  Are you talking about all such packages,
> or only packages with RC bugs?  

The ones that are orphaned for some time. If we see it doesn't work or
is not worth, we can change that back of course.


Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


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

Re: Getting rid of circular dependencies, stage 3

[Stepan Golosunov]

On Thu, Jan 12, 2006 at 09:30:56AM +0100, Josselin Mouette wrote:
> Le lundi 09 janvier 2006 à 22:15 -0500, Joey Hess a écrit :
> > Bill Allombert wrote:
> > > Here the lists of packages involved in circular dependencies listed by
> > > maintainers.
> > 
> > > Joey Hess <[EMAIL PROTECTED]>
> > >   debconf
> > >   debconf-english
> > >   debconf-i18n
> > 
> > These are all necessary, and debconf is an essential package which is
> > not subject to the circular dependency postinst ordering problems afaik.
> 
> Looking at them, I fail to see why debconf-i18n has to depend on
> debconf.

Because /usr/share/doc/debconf-i18n is a symlink?


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

Re: Getting rid of circular dependencies, stage 3

[Robert Lemmen]

On Thu, Jan 12, 2006 at 09:12:27PM +0400, Stepan Golosunov wrote:
> > Looking at them, I fail to see why debconf-i18n has to depend on
> > debconf.
> 
> Because /usr/share/doc/debconf-i18n is a symlink?

perhaps the link should be the other way round. for example the most
common package split would be something like:
foo --depends--> foo-common
if you want one doc dir for it, then of course the real directory has to
be in foo-common, and the link in foo.

cu  robert

-- 
Robert Lemmen   http://www.semistable.com 


signature.asc
Description: Digital signature

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

[Luk Claes]

Steinar H. Gunderson wrote:
> On Fri, Jan 13, 2006 at 12:03:28AM +0900, Charles Plessy wrote:
> 
>>Of course, this is trivial, but fixing this bug (251 days old) is
>>also trivial. Then why complain ? I feel that it gives a bad image of
>>debian, when it suggests to use a broken tool while another one is being
>>repaired.

I agree and have sent an intention to NMU. Though like Jesus Climent
mentioned in the bug log, it could actually be seen as 2 bugs: a
wishlist bug for trying alternatives and a release critical (at least
IMHO) bug about not depending on packages which are used by the package.

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

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

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: Getting rid of circular dependencies, stage 3

[Bill Allombert]

On Wed, Jan 11, 2006 at 09:34:27PM -0500, Joey Hess wrote:
> > I cannot point you exactly why _this_ circular dependency is going to 
> > be a problem, no.
> > However I can point you to bug #310490 which show a woody system that
> > could not be upgraded to sarge without removing most of KDE.
> 
> I've read that bug before and I appreciate the time you've spent in
> chasing down these upgrade issues but I think you're generalising too
> far from that bug to a conclusion that any given trivial dependency loop
> will cause similar problems.
> 
> > and that apt was not able to deal with that optimally.  In the end we 
> > were not able to fix the problem, because we could not fix woody and
> > sarge apt did not fare better anyway.
> 
> Although sarge's aptitude did..

I don't know, there were no ways to upgrade to sarge's aptitude.

> > The situation is too complex to
> > expect the software to make the optimal solution of what should be
> > removed to allow upgrade.
> 
> I'm not so sure, have you seen the work that's been done recently on
> aptitude's problem resolver?

After sarge released ? no. However the upgrade path of aptitude itself
is problematic. We should probably provide a statically linked 
(at least the C++ libs) to ease upgrade.

In my current sarge to etch upgrade test, I installed the first 1000
packages by alphabetic order (minus conflicts, plus dependencies)
and tried to upgrade. aptitude dist-upgrade give:
The following packages will be REMOVED:
  abiword-doc acl2 acl2-books acl2-emacs acl2-infix akregator-i18n 
  akregator-konq-plugin akregator-kontact-plugin alex alsa-headers amarok 
  amarok-arts amarok-engines amarok-gstreamer amarok-xine aqsis aqsis-libs 
  aqsis-libs-dev ardour-gtk aspell-bin aspell-br aspell-cy aspell-da 
  aspell-de aspell-de-alt aspell-el aspell-en aspell-es aspell-fi aspell-fo 
  aspell-fr aspell-ga aspell-gl-minimos aspell-is aspell-it aspell-lt 
  aspell-nl aspell-no aspell-pl aspell-pt aspell-pt-br aspell-sk aspell-sl 
  aspell-sv aspell-tl aspell-ukr axiom axiom-graphics axiom-hypertex 
  axiom-test basket beecrypt2 beecrypt2-dev bibletime bibletime-i18n 
  bitscope brahms capplets castle-combat-data caudium-pixsl cduce g77-3.3 
  gdk-imlib1-dev ghc5 jackd kdelibs4 lam4 libafterstep0 libaiksaurus-data 
  libaiksaurus0c102 libaiksaurusgtk0c102 libardour0 libarkrpg libarts1 
  libclalsadrv libconfigwin-ocaml-dev libcurl3-dev libenchant1 libfam0c102 
  libfltk1.1c102 libgengameng4 libglibmm-2.4-1 libgmp3 
  libgpattern-ocaml-dev libgtkmm-2.4-1 libgtkmm1.2-0 libgtkmmext0 
  libgtop2-2 libid3-3.8.3 libjack0.80.0-dev libkcal2a libkdenetwork2 
  libkdepim1 liblablgtk-ocaml liblablgtk-ocaml-dev libmagick++6 
  libmlchat-ocaml-dev libmodplug0 libmpich1.0 libmyspell3 
  libocamlcvs-ocaml-dev libokey-ocaml-dev libopenexr2 liboptions-ocaml-dev 
  libopts9 libopts9-dev libosp4 libostyle1 libplot2 libpstoedit0 
  libqt3c102-mt libreport-ocaml-dev libsigc++-2.0-0 libsoundtouch1 libsp1 
  libtag1 libtiffxx0 libwpd-stream8 libwpd8 mlchat ocaml-ioxml ocaml-omom 
  ocaml-zoggy odbcinst1 
After unpacking 150MB will be freed.
This look like a bit much.
(actually aptitude while try to remove 11 packages more than apt-get).
Simply upgrading aptitude cause adduser-ng to be removed.

> > So maybe it is not a bug in the uqm package specifically, but it is still 
> > a problem for Debian in the big picture. 
> 
> Filing scattershot but reports with no useful justifications might
> result in enough people going ahead and making changes to make it seem
> worth your time to do so, on the presumption that one of the changes
> will avoid some real problem, but please realize that you run the risk
> of annoying people when you do it.

For that reason I only reported one single bug by maintainers, unless when
maintainers asked me to do otherwise. My experience is that reporting
bugs always annoy people and that the price to pay to do quality
assurance. 

However, that is a fair remark. I decided to go ahead because circular
deps have others drawback so I am not completly wasting everybody time

Do you have other ideas how we can provide smooth sarge to etch upgrade ?

I am not happy with the woody to sarge upgrade path. I did test months
before the freeze but there was simply too much flux in testing to be
conclusive. When sarge finally freeze, upgrade tests got much smoother
(and reproducible) but there was not enough time to really fix the 
issues.

Now, I am experimenting with new kind of tests but transforming the raw
results to useful advices to improve the upgrade path is not obvious.

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: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=265920

[Darren Salt]

[note: sent to d-d only]

I demand that Luke Kenneth Casson Leighton may or may not have written...

> On Tue, Jan 10, 2006 at 02:04:45PM +0100, Adeodato Sim?? wrote:
>> * Matthew Garrett [Tue, 10 Jan 2006 02:50:56 +]:
[snip]
>>> It's the job of either the bug submitter or (more usually) the Debian
>>> maintainer to contact upstream to make sure that they're aware of the
>>> bug. It is *not* the upstream maintainer's job to examine Debian's bug
>>> database.

> that distinction isn't made clear: it's only if people think about it that
> they will realise that they are supposed to report debian-specific
> packaging bugs to the debian bugs database and package-specific bugs to
> whatever upstream thingy they can find. _if_ they can find it.

Not necessarily. The bug could be due to a Debian-specific change in the
package and, for whatever reason, $USER may be unable to determine this - in
that case, the best place for the bug report is the Debian BTS.

> and even if some people do think, there's lots that won't.

Then there are the people who send bug reports upstream anyway, even for
distribution-specific problems...

[snip]
>>> "If you report a bug to Debian and nobody forwards it, we know nothing
>>> about it".

>> All correct. Thanks, Matthew. I'll just note that the Debian KDE packages
>> receive an incredible amount of bug reports, and that we're understaffed
>> to forward all of them to KDE upstream.

> that's why one of my recommendations was to consider putting, into certain
> key very popular packages, a means to either transfer the bug to upstream
> (via some mad notional XMLeey are pee cee-ey common API) or to simply put
> into reportbug a list of packages for which reporting should be given
> special messages:
[snip]

I can imagine a situation in which, due to a lot of packaging-specific bugs
being sent upstream, upstream starts closing bugs, marking them with
something like "report via your distribution's BTS" ;-\

>  other possibilities:

>  1) add into the dpkg thingy an upstream URL where bugs can be reported:

> UpstreamBugs: http://bugs.kde.org/enter_bug.cgi (whatever)
>  if you encounter a bug in kde.
>  please report it here because otherwise nobody
>  will fix it, thank you.
> .

ITYM "... because otherwise your bug report will be ignored".

[snip]
>this would save maintainers a boat-load of time.

Maybe...

>  2) against the list of "UpstreamBugs", on bugs.debian.org, email
> received automatically notifies the sender of the above info.

That /may/ be useful, but it's also another potential black hole, whether the
messages are sent to a person ("not enough time") or to a list. And, as we
know, lists can easily become SEP generators: just add one 9V battery... :-)

[snip]
-- 
| Darren Salt   | nr. Ashington, | linux (or ds) at
| sarge,| Northumberland | youmustbejoking
| RISC OS   | Toon Army  | demon co uk
|   Kill all extremists!

Live within your income, even if you have to borrow to do so.


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

Re: Development standards for unstable

[Britton Kerin]

On Thu, 12 Jan 2006 14:23:31 +0100, "Thomas Viehmann" <[EMAIL PROTECTED]>
said:
> Hi,
> 
> first of all, thanks for taking the initiative I think the matter is too
> important to be left alone just for avoiding to step on anyones toes.
> 
> Anthony Towns wrote:
> > Random ideas for negative consequences might include forced
> > orphaning by overriding maintainer fields to debian-qa, removal of
> Maybe this should not only be limited to packages with RC bugs... For a
> lot of packages with inactive maintainers, it might be best to not
> release them in etch.

Unlikely in general at least.  A lot of buggy packages work and are
being 
used by people, so dumping them outright is probably not going to work.

What we might try is making the BTS info even more accessible by somehow
integrating it with synaptic or dpkg.  The BTS record is one of the most
important peices of information about a package and isn't available for
browing directly from synaptic.

At some point we're also going to have to face the fact that the current
package-the-world-then-fix-every-rc-bug-in-it approach doesn't scale
arbitrarily.  With the current definition of RC bugs (including security
holes, data loss, and breakage of unrelated packages), we will
eventually
be in a situation where we have packages that we don't have time to fix,
but aren't broken enough that the few users who have been using them for
years will be best served by our dumping the packages.  If we had a way
to flag such packages 'deprecated' or 
'very-buggy-your-on-your-own-if-you-try-this-one' (obviously we'd have
to
think of some better names :) it would prevent new users from being
misled
into trying the package without inconviencing existing users.

Britton




> 
> Kind regards
> 
> T.
> -- 
> Thomas Viehmann, http://thomas.viehmann.net/
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact
> [EMAIL PROTECTED]
> 
-- 
  Britton Kerin
  [EMAIL PROTECTED]


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

Re: Bug#347617: ITP: itrans -- Converts romanised Indic text to LaTeX, HTML & Postscript

[Frank Küster]

Yves-Alexis Perez <[EMAIL PROTECTED]> wrote:

> Frank Küster wrote:
>> Yves-Alexis Perez <[EMAIL PROTECTED]> wrote:
>> 
>> 
>>>Frank Küster wrote:
>>>
Baishampayan Ghose <[EMAIL PROTECTED]> wrote:
>>>
How did you manage to download the sources from there?  I get:
>>>
>>>ftp://ftp%40aczoom%2Ecom:[EMAIL PROTECTED]/itrans/53/itrans53.zip
>> 
>> 
>> That's exactly what I tried - it doesn't matter which "password" or
>> username I send.  The error message points to a screwed up setup of the
>> FTP server, according to Google; but if it works for you it's obviously
>> more complicated...
>
> Clicking the link from the download page in firefox shows me the Save As
> windows. Using yafc I can download too:

Hm, no idea why it didn't work in Firefox, but I now found out which
miss-setting caused it to fail with ftp and yafc.

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

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

[Bill Allombert]

On Thu, Jan 12, 2006 at 04:57:46PM +0100, Steinar H. Gunderson wrote:
> On Fri, Jan 13, 2006 at 12:03:28AM +0900, Charles Plessy wrote:
> > Of course, this is trivial, but fixing this bug (251 days old) is
> > also trivial. Then why complain ? I feel that it gives a bad image of
> > debian, when it suggests to use a broken tool while another one is being
> > repaired.
> 
> 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.
> 
> 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.

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.

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: Development standards for unstable

[Frank Küster]

Andreas Barth <[EMAIL PROTECTED]> wrote:

> * Frank Küster ([EMAIL PROTECTED]) [060112 18:11]:
>> Andreas Barth <[EMAIL PROTECTED]> wrote:
>> 
>> > * Christoph Berg ([EMAIL PROTECTED]) [060112 16:28]:
>> >> Re: Thomas Viehmann in <[EMAIL PROTECTED]>
>> >> > Really, how about just automatically[1] removing orphaned packages
>> >> > without maintained rdepends from testing?
>> >> 
>> >> Seconded.
>> >
>> > well, just make a list that I can just copy into my hint file.
>> 
>> Hm, I can't find the context:  Are you talking about all such packages,
>> or only packages with RC bugs?  
>
> The ones that are orphaned for some time. If we see it doesn't work or
> is not worth, we can change that back of course.

I can't see why removing an orphaned package that has no RC bugs, and
let's say, even no important bugs, and which is stable in the sense that
there's no new upstream version (e.g. an established font), from testing
makes testing's quality better.  What about a hypothetical package that
has no bugs at all, but some users according to popcon?

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

Link partnership request with debian.org

[Szabolcs, Herman]

Dear Mr(s),

I visited your site (debian.org) today, and I really like it. I am very 
interested in exchanging links. I've gone ahead and posted a link to 
your site, on this page:

www.budapestnetapartments.hu/travel-links/europe-finland-helsinki.htm

Your website details:
Url: debian.org
Description: Debian Mailing Lists -- Index

I'd be glad if you linked back to my site. You can find sample linking 
code at:
http://www.budapestnetapartments.hu/link-partnership-apuk.htm

If you would like me to modify any details of your site, or if you have 
any other cross-promotion ideas, please let me know.

Best regards,

Szabolcs, Herman
Travel & Trade Solutions
[EMAIL PROTECTED]


If you prefer I not send you future emails, please reply with the word 
'remove' in the subject line


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

Re: Dissection of an Ubuntu PR message

[Andrew Suffield]

On Wed, Jan 11, 2006 at 03:41:16PM -0800, Matt Zimmerman wrote:
> On Wed, Jan 11, 2006 at 11:09:12PM +, Andrew Suffield wrote:
> > Let's take this one apart and see what it is that pisses people off so
> > much.
> 
> I don't intend to participate in this type of email argument with you; I've
> yet to see it pay off for anyone involved.  However, I will be in London
> later this month and would be willing to use that opportunity to civilly
> discuss your concerns face-to-face.

The intent here being "stop people from scrutinising Ubuntu in public;
get it off the lists so that it's less visible". Not likely.

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


signature.asc
Description: Digital signature

Re: Dissection of an Ubuntu PR message

[Gustavo Franco]

On 1/12/06, Andrew Suffield <[EMAIL PROTECTED]> wrote:
> On Wed, Jan 11, 2006 at 03:41:16PM -0800, Matt Zimmerman wrote:
> > On Wed, Jan 11, 2006 at 11:09:12PM +, Andrew Suffield wrote:
> > > Let's take this one apart and see what it is that pisses people off so
> > > much.
> >
> > I don't intend to participate in this type of email argument with you; I've
> > yet to see it pay off for anyone involved.  However, I will be in London
> > later this month and would be willing to use that opportunity to civilly
> > discuss your concerns face-to-face.
>
> The intent here being "stop people from scrutinising Ubuntu in public;
> get it off the lists so that it's less visible". Not likely.

Do you want visibility or solve current problems ? I'm glad that Matt
is open for suggestions, and even a talk in person with you. You
missed a chance to provide (yet another) sane feedback from Debian
perspective to him, and give us something back.

Thanks,
Gustavo Franco

Re: Development standards for unstable

[Andrew Suffield]

On Thu, Jan 12, 2006 at 03:49:08PM +0100, Andreas Tille wrote:
> On Thu, 12 Jan 2006, Thijs Kinkhorst wrote:
> 
> >While the package might not be of the quality we strive to achieve within
> >Debian; if a bug is not release critical we consider the bug not to be
> >serious enough to impact the packages' releaseworthyness. This is by
> >definition. Even if there are many of those bugs, they appearently do not
> >prevent the core functionality from working.
> 
> Well the definition is given in policy and a policy change (to be discussed)
> might change the definition of release critical.  So if we define that 
> numbers N_n normal bugs and N_i important bugs and  time spans T_n and
> T_i where a bug is completely unattended by the maintainer (e.i. no
> comments, no reason why not fixed, etc.) we can define a measure
> 
> X = Sum(N_n * T_n) + 2 * Sum(N_i * T_i)
> 
> and if this measure excedes a certain limit we define this as RC
> critical.

Well it's nice in theory. The problem is that you have to set the
threshold high enough to exempt glibc and dpkg, and when you do that,
I have not yet found a metric that complains about any other packages
(I've tried two or three times to invent one).

Sure, you could just manually exclude those few big offenders, but if
you're going to do that then what's the point?

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


signature.asc
Description: Digital signature

Re: Dissection of an Ubuntu PR message

[Andrew Suffield]

On Thu, Jan 12, 2006 at 05:31:40PM -0200, Gustavo Franco wrote:
> On 1/12/06, Andrew Suffield <[EMAIL PROTECTED]> wrote:
> > On Wed, Jan 11, 2006 at 03:41:16PM -0800, Matt Zimmerman wrote:
> > > On Wed, Jan 11, 2006 at 11:09:12PM +, Andrew Suffield wrote:
> > > > Let's take this one apart and see what it is that pisses people off so
> > > > much.
> > >
> > > I don't intend to participate in this type of email argument with you; 
> > > I've
> > > yet to see it pay off for anyone involved.  However, I will be in London
> > > later this month and would be willing to use that opportunity to civilly
> > > discuss your concerns face-to-face.
> >
> > The intent here being "stop people from scrutinising Ubuntu in public;
> > get it off the lists so that it's less visible". Not likely.
> 
> Do you want visibility or solve current problems ?

If I were interested in solving Ubuntu's problems then I would be
working on Ubuntu. As people keep pointing out, Ubuntu's failure to
cooperate effectively is *not* our problem - the only 'problem' that
*we* have is that Ubuntu-worshippers keep showing up and
proselytizing. An effective solution to this problem is to raise
awareness to the point where people stop believing and start
thinking. It appears to be working.

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


signature.asc
Description: Digital signature

Re: Getting rid of circular dependencies, stage 3

[Steve Langasek]

On Thu, Jan 12, 2006 at 11:49:14AM -0600, Bill Allombert wrote:
> On Wed, Jan 11, 2006 at 09:34:27PM -0500, Joey Hess wrote:
> > > I cannot point you exactly why _this_ circular dependency is going to 
> > > be a problem, no.
> > > However I can point you to bug #310490 which show a woody system that
> > > could not be upgraded to sarge without removing most of KDE.

> > I've read that bug before and I appreciate the time you've spent in
> > chasing down these upgrade issues but I think you're generalising too
> > far from that bug to a conclusion that any given trivial dependency loop
> > will cause similar problems.

> > > and that apt was not able to deal with that optimally.  In the end we 
> > > were not able to fix the problem, because we could not fix woody and
> > > sarge apt did not fare better anyway.

> > Although sarge's aptitude did..

> I don't know, there were no ways to upgrade to sarge's aptitude.

> > > The situation is too complex to
> > > expect the software to make the optimal solution of what should be
> > > removed to allow upgrade.

> > I'm not so sure, have you seen the work that's been done recently on
> > aptitude's problem resolver?

> After sarge released ? no. However the upgrade path of aptitude itself
> is problematic. We should probably provide a statically linked 
> (at least the C++ libs) to ease upgrade.

> In my current sarge to etch upgrade test, I installed the first 1000
> packages by alphabetic order (minus conflicts, plus dependencies)
> and tried to upgrade. aptitude dist-upgrade give:
> The following packages will be REMOVED:
>   abiword-doc acl2 acl2-books acl2-emacs acl2-infix akregator-i18n 
>   akregator-konq-plugin akregator-kontact-plugin alex alsa-headers amarok 
>   amarok-arts amarok-engines amarok-gstreamer amarok-xine aqsis aqsis-libs 
>   aqsis-libs-dev ardour-gtk aspell-bin aspell-br aspell-cy aspell-da 
>   aspell-de aspell-de-alt aspell-el aspell-en aspell-es aspell-fi aspell-fo 
>   aspell-fr aspell-ga aspell-gl-minimos aspell-is aspell-it aspell-lt 
>   aspell-nl aspell-no aspell-pl aspell-pt aspell-pt-br aspell-sk aspell-sl 
>   aspell-sv aspell-tl aspell-ukr axiom axiom-graphics axiom-hypertex 
>   axiom-test basket beecrypt2 beecrypt2-dev bibletime bibletime-i18n 
>   bitscope brahms capplets castle-combat-data caudium-pixsl cduce g77-3.3 
>   gdk-imlib1-dev ghc5 jackd kdelibs4 lam4 libafterstep0 libaiksaurus-data 
>   libaiksaurus0c102 libaiksaurusgtk0c102 libardour0 libarkrpg libarts1 
>   libclalsadrv libconfigwin-ocaml-dev libcurl3-dev libenchant1 libfam0c102 
>   libfltk1.1c102 libgengameng4 libglibmm-2.4-1 libgmp3 
>   libgpattern-ocaml-dev libgtkmm-2.4-1 libgtkmm1.2-0 libgtkmmext0 
>   libgtop2-2 libid3-3.8.3 libjack0.80.0-dev libkcal2a libkdenetwork2 
>   libkdepim1 liblablgtk-ocaml liblablgtk-ocaml-dev libmagick++6 
>   libmlchat-ocaml-dev libmodplug0 libmpich1.0 libmyspell3 
>   libocamlcvs-ocaml-dev libokey-ocaml-dev libopenexr2 liboptions-ocaml-dev 
>   libopts9 libopts9-dev libosp4 libostyle1 libplot2 libpstoedit0 
>   libqt3c102-mt libreport-ocaml-dev libsigc++-2.0-0 libsoundtouch1 libsp1 
>   libtag1 libtiffxx0 libwpd-stream8 libwpd8 mlchat ocaml-ioxml ocaml-omom 
>   ocaml-zoggy odbcinst1 
> After unpacking 150MB will be freed.
> This look like a bit much.
> (actually aptitude while try to remove 11 packages more than apt-get).
> Simply upgrading aptitude cause adduser-ng to be removed.

What does aptitude give as the breakdown between unused packages being
automatically removed, and packages being removed that you actually
requested installed?

In spite of the large number of packages removed, almost all of these are
packages that are not in etch...  From a-c, only these packages are in your
removal list and also in testing at present:  ardour-gtk aspell-br aspell-cy
aspell-da aspell-de aspell-de-alt aspell-el aspell-en aspell-es aspell-fi
aspell-fr aspell-ga aspell-gl-minimos aspell-is aspell-it aspell-lt
aspell-nl aspell-no aspell-pl aspell-pt aspell-pt-br aspell-sk aspell-sl
aspell-sv aspell-ukr bitscope caudium-pixsl

So, counting the aspell issue as one, that looks like a total of 4 upgrade
problems.  Which is four too many, but not as bad as it looks based on the
output alone. :)

-- 
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: Development standards for unstable

[Joey Hess]

Thijs Kinkhorst wrote:
> While the package might not be of the quality we strive to achieve within
> Debian; if a bug is not release critical we consider the bug not to be
> serious enough to impact the packages' releaseworthyness. This is by
> definition. Even if there are many of those bugs, they appearently do not
> prevent the core functionality from working.

One problem with this definition is that it allows a package's quality
to be nickled and dimed to death by hordes of non-RC but variously
annoying bugs, to the point that every user of the package will
encounter annoying bugs that make the package not worth using,
even if which of the many bugs they happen to encounter varies.

This is truely annoying in the case where there are multiple packages in
Debian to serve a given need, and the user is stuck trying each of them
in turn just to find one that is well enough maintained. The only things
we have to deal with this right now are a) tasks and b) unwritten lore
about which packages to avoid.

I think that the RC bug metric is overated and doesn't consider these
kinds of effects that end up pulling down the overall usability of
Debian.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Dissection of an Ubuntu PR message

[Gustavo Franco]

On 1/12/06, Andrew Suffield <[EMAIL PROTECTED]> wrote:
> On Thu, Jan 12, 2006 at 05:31:40PM -0200, Gustavo Franco wrote:
> > On 1/12/06, Andrew Suffield <[EMAIL PROTECTED]> wrote:
> > > On Wed, Jan 11, 2006 at 03:41:16PM -0800, Matt Zimmerman wrote:
> > > > On Wed, Jan 11, 2006 at 11:09:12PM +, Andrew Suffield wrote:
> > > > > Let's take this one apart and see what it is that pisses people off so
> > > > > much.
> > > >
> > > > I don't intend to participate in this type of email argument with you; 
> > > > I've
> > > > yet to see it pay off for anyone involved.  However, I will be in London
> > > > later this month and would be willing to use that opportunity to civilly
> > > > discuss your concerns face-to-face.
> > >
> > > The intent here being "stop people from scrutinising Ubuntu in public;
> > > get it off the lists so that it's less visible". Not likely.
> >
> > Do you want visibility or solve current problems ?
>
> If I were interested in solving Ubuntu's problems then I would be
> working on Ubuntu. As people keep pointing out, Ubuntu's failure to
> cooperate effectively is *not* our problem - the only 'problem' that
> *we* have is that Ubuntu-worshippers keep showing up and
> proselytizing. An effective solution to this problem is to raise
> awareness to the point where people stop believing and start
> thinking. It appears to be working.
>

We can't decide how they need to "give us something MORE back" and
it's their problem? An effective solution is discuss between us and
keep our needs clear, since there are some Canonical employees that
are DDs too, they're in a position that they can participate in these
discussions (they're doing it right now).

You started (in a way) two threads about it and there's other about
launchpad, in my view we've the following status (with comments
below):

- No, Debian isn't going to embrace launchpad and ask for "rw" status
(Debian is listed there as read-only).[0]

- Yes, Ubuntu is contributing back but some DDs judge that it isn't
Canonical but some Canonical employees that are dedicated to Debian
too, so they help because they want;[1]

- Scott's url with patches isn't part of the "give something back"
approach that we want. We need to be well informed about patches, but
we don't know exactly how;

I removed more non-Canonical related initiatives like Ubuntu MOTUs
page about contributing to Debian.

[0] = I agree, DDs and contributors are free to use any tools they
want, so we're not going to force any DD or contributor go through
launchpad. I think it's consensus and valid for other things, like
alioth and related stuff;

[1] = If they're doing it in their workhours, it isn't only because they want.

--
Gustavo Franco

Re: Development standards for unstable

[Joey Hess]

Andrew Suffield wrote:
> Well it's nice in theory. The problem is that you have to set the
> threshold high enough to exempt glibc and dpkg, and when you do that,
> I have not yet found a metric that complains about any other packages
> (I've tried two or three times to invent one).

I think the problem might be that the formula doesn't take the package's
installed base and/or age into account. The number of bugs in the BTS
tends to increase as both values increase without much connection to
the actual number of bugs in the package that affect many users, since
people eventually hit most of the edge cases, and those sort of bugs are
often the least likely to get fixed.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#347807: ITP: xara -- a vector drawing program

[Joachim Breitner]

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

* Package name: xara
* URL : http://www.xaraxtreme.org/ 
* License : to be released as GPL
  Description : a vector drawing program

The makers of the long-around Windows XaraX vector drawing program are
working on a GPL'ed linux release, and I plan to package that for
debian. I already contacted the upstream authors, and they will happily
assist me.

If someone really wants to work on this two, I'm sure we can arrange
some co-maintainership.

Greetings,
Joachim

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14.otto
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)


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

Re: Development standards for unstable

[Andreas Tille]

On Thu, 12 Jan 2006, Andrew Suffield wrote:


Well it's nice in theory. The problem is that you have to set the
threshold high enough to exempt glibc and dpkg, and when you do that,
I have not yet found a metric that complains about any other packages
(I've tried two or three times to invent one).

Sure, you could just manually exclude those few big offenders, but if
you're going to do that then what's the point?


I tried to mention briefly that this will not work in any case and
you just nitpicked these ones.  On the other hand I can not really
believe that it is impossible to touch glibc and dpkg bugs with some
kind of status ("I'm working on it", "Help would be welcome in this
particular task", ...).

The problem is that every honor (to be a DD) is also commitment
(to care for the things that make you a DD).  If you are not able
to fix things you have the responsibility to tell your users why -
at least this is my point of view in maintainership.

So for simplicity lets test the measure I suggested above for
packages with priority extra, right?

Kind regards

 Andreas.

--
http://fam-tille.de


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

Re: Development standards for unstable

[Andreas Barth]

* Frank Küster ([EMAIL PROTECTED]) [060112 19:36]:
> Andreas Barth <[EMAIL PROTECTED]> wrote:
> > * Frank Küster ([EMAIL PROTECTED]) [060112 18:11]:
> >> Andreas Barth <[EMAIL PROTECTED]> wrote:
> >> > * Christoph Berg ([EMAIL PROTECTED]) [060112 16:28]:
> >> >> Re: Thomas Viehmann in <[EMAIL PROTECTED]>
> >> >> > Really, how about just automatically[1] removing orphaned packages
> >> >> > without maintained rdepends from testing?
> >> >> 
> >> >> Seconded.
> >> >
> >> > well, just make a list that I can just copy into my hint file.
> >> 
> >> Hm, I can't find the context:  Are you talking about all such packages,
> >> or only packages with RC bugs?  
> >
> > The ones that are orphaned for some time. If we see it doesn't work or
> > is not worth, we can change that back of course.
> 
> I can't see why removing an orphaned package that has no RC bugs, and
> let's say, even no important bugs, and which is stable in the sense that
> there's no new upstream version (e.g. an established font), from testing
> makes testing's quality better.  What about a hypothetical package that
> has no bugs at all, but some users according to popcon?

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


Cheers,
Andi


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

OT: quoting (was: Development standards for unstable)

[martin f krafft]

also sprach Andreas Barth <[EMAIL PROTECTED]> [2006.01.12.2135 +0100]:
> * Frank Küster ([EMAIL PROTECTED]) [060112 19:36]:
> > Andreas Barth <[EMAIL PROTECTED]> wrote:
> > > * Frank Küster ([EMAIL PROTECTED]) [060112 18:11]:
> > >> Andreas Barth <[EMAIL PROTECTED]> wrote:
> > >> > * Christoph Berg ([EMAIL PROTECTED]) [060112 16:28]:
> > >> >> Re: Thomas Viehmann in <[EMAIL PROTECTED]>

come on, y'all!

no reply necessary.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver!
 
"for art to exist, for any sort of aesthetic activity or perception to
 exist, a certain physiological precondition is indispensable:
 intoxication."
-- friedrich nietzsche


signature.asc
Description: Digital signature (GPG/PGP)

Re: HPPA, Arm, or M68k with g++ >= 4:4.0.2-2 ?

[Ionut Georgescu]

On Wednesday 14 December 2005 19:25, Adeodato Simó wrote:
> * Jens Peter Secher [Wed, 14 Dec 2005 18:50:26 +0100]:
> > I need to test that a package can be built with g++ >= 4:4.0.2-2 on
> > HPPA, Arm, or M68k.  Is there a DD accessible machine that has a current
> > version of g++ installed?
>
>   paer's sid chroot.
>

I maintain grace, but I am not a DD. Can I still access this machine somehow?
grace fails tu build on m68k (http://bugs.debian.org/338433)

Thank you,
Ionut


pgpt1aXUXdNtY.pgp
Description: PGP signature

Re: Development standards for unstable

[David Nusinow]

On Thu, Jan 12, 2006 at 09:35:18PM +0100, Andreas Barth wrote:
> However, on the other hand feel free to create a "common maintained
> packages team" that adopts such packages :)

Isn't that pretty much what the qa team does?

 - David Nusinow


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

Re: Development standards for unstable

[Andreas Barth]

* David Nusinow ([EMAIL PROTECTED]) [060112 21:47]:
> On Thu, Jan 12, 2006 at 09:35:18PM +0100, Andreas Barth wrote:
> > However, on the other hand feel free to create a "common maintained
> > packages team" that adopts such packages :)

> Isn't that pretty much what the qa team does?

Not really. All qa-maintained packages are up for adoption or removal
and are only maintained at a "if it breaks too bad".


Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


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

Re: Development standards for unstable

[Jeroen van Wolffelaar]

On Thu, Jan 12, 2006 at 09:52:13PM +0100, Andreas Barth wrote:
> * David Nusinow ([EMAIL PROTECTED]) [060112 21:47]:
> > On Thu, Jan 12, 2006 at 09:35:18PM +0100, Andreas Barth wrote:
> > > However, on the other hand feel free to create a "common maintained
> > > packages team" that adopts such packages :)
> 
> > Isn't that pretty much what the qa team does?
> 
> Not really. All qa-maintained packages are up for adoption or removal
> and are only maintained at a "if it breaks too bad".

Well, that's current practice, but nobody is stopping anyone to give a
little bit more care into QA packages...

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.

Also, I am wondering how much success such a 'common maintained packages
team' would have while there is a shortage of people caring for general
QA of orphaned packages or just on the archive at all.

--Jeroen

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


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

Bug#347834: ITP: knmap -- Kde interface to nmap

[Moratti Claudio]

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

* Package name: knmap
  Version : 1.99-1
  Upstream Author : Kevin Gilbert <[EMAIL PROTECTED]>
* URL : http://sourceforge.net/projects/knmap
* License : GPL
  Description : Kde interface to nmap

 Knmap is a KDE-based interface to the 'nmap'
 facility available at http://www.insecure.org/nmap.
 .
 The main Knmap window provides for the entry of nmap
 options and the display of nmap-generated output.
 .
 Homepage: http://sourceforge.net/projects/knmap

   
-- 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.15-maxer
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)


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

Bug#347826: ITP: fullquottel -- Tool for recognizing mails/postings in tofu/top-posting style

[gregor herrmann]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


* Package name: fullquottel
  Version : 0.1.1
  Upstream Author : Toastfreeware ([EMAIL PROTECTED])
* URL : http://www.toastfreeware.priv.at/
* License : GPL
  Description : Tool for recognizing mails/postings in tofu/top-posting 
style

 The program performs several tests to decide whether the mail is a tofu
 mail or not. Each test produces a score. The final sum of the individual
 test scores is compared to a threshold. If it is above it, the mail is
 classified as tofu mail ('Fullquottel' is returned). Further more, the
 score itself is returned as number and as a row where each score point
 produces one *. Each test can be customized via a config file or on the
 command line.
 
- -- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15.200601042007
Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15)

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

iD8DBQFDxsefOzKYnQDzz+QRApTHAJ9KmTckXaMx2npFgSRsaHSX5XcpYwCcDWaP
BrXHoUxQmqnMpSFJpev+Ctg=
=Ncs/
-END PGP SIGNATURE-


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

Bug#347828: ITP: mailtextbody -- Tool to return the body of an email message

[gregor herrmann]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


* Package name: mailtextbody
  Version : 0.1.1
  Upstream Author : Toastfreeware <[EMAIL PROTECTED]>
* URL : http://www.toastfreeware.priv.at/
* License : GPL
  Description : Tool to return the body of an email message

 Mailtextbody reads a complete email message on stdin and returns
 the body (the text/plain part) on standard out.
 Mailtextbody can therefore easily be included in other tools using
 pipes.

- -- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15.200601042007
Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15)

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

iD8DBQFDxsh0OzKYnQDzz+QRAmKDAKCdku0Q+NI9aF6EYKoIw+tAIf+NfACfZw1q
ADshmuFv/YH4sHPIU8wqbfs=
=tvm7
-END PGP SIGNATURE-


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

Bug#347832: ITP: mpc123 -- Command-line Musepack audio player

[Daniele Sempione]

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


* Package name: mpc123
  Version : 0.1.9
  Upstream Author : Fernando Vezzosi <[EMAIL PROTECTED]>
* URL : http://mpc123.sourceforge.net/
* License : GPL
  Description : Command-line Musepack audio player

mpc123 is a command-line player for the Musepack audio compression
format.
.
MPC is a lossy compression format like MP3 or Ogg Vorbis. It is
based on the MPEG-1 Layer-2 / MP2 algorithms, but has vastly
improved.
.
Right now the player isn't able to play remote files.

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


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

Re: Dissection of an Ubuntu PR message

[Daniel Ruoso]

Em Qui, 2006-01-12 às 18:08 -0200, Gustavo Franco escreveu:
> - Scott's url with patches isn't part of the "give something back"
> approach that we want. We need to be well informed about patches, but
> we don't know exactly how;

Don't we?

Debian is Ubuntu's upstream, right?

When you modify something in the upstream code, you normally send it to
upstream, right?

Do you send it as a link to a file with a patch only? Or do you send a
comment explaining the problem, the proposed solution and why that
decision was made?

That's it, just it, nothing more... That's what distinguishes
cooperating from forking...

daniel


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

Re: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=265920

[Russ Allbery]

Luke Kenneth Casson Leighton <[EMAIL PROTECTED]> writes:

>  that distinction isn't made clear: it's only if people think about it
>  that they will realise that they are supposed to report debian-specific
>  packaging bugs to the debian bugs database and package-specific bugs to
>  whatever upstream thingy they can find.  _if_ they can find it.

For my packages, I would like people to report upstream bugs with
reportbug.  I'll forward them upstream if need be.  For most of the
packages that I maintain, I have a very close relationship with upstream
and have a lot of communication channels available to me that the bug
reporter probably wouldn't have.

For example, if someone reports a bug in OpenAFS, I usually talk it over
with the developers on Zephyr before forwarding it to the upstream bug
database.

I think this is a case where very large packages like Firefox or
OpenOffice may have different needs than the majority of packages in
Debian.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Development standards for unstable

[Russ Allbery]

Jeroen van Wolffelaar <[EMAIL PROTECTED]> writes:

> Well, that's current practice, but nobody is stopping anyone to give a
> little bit more care into QA packages...

The hardest problem, speaking as someone who wanted to do that and who
still wants to do that as soon as I can find time, is that many of the
packages that are QA-maintained are very difficult for the average
developer to test.  For various reasons, QA accumulates a lot of packages
with obscure usages or obscure dependencies that are difficult to modify
just because one can't be sure one hasn't broken something.

For example:

dcl: GNU Enterprise - Double Choco Latte
eco5000: Orga Eco 5000 smartcard reader PCSC and CT-API driver
gnusim8085: Graphical Intel 8085 simulator
goldedplus: Offline mail reader for Fidonet and Usenet
gsmartcard: A smart card reading, writing and managing program for Gnome
gtkhx: A GTK+ version of Hx, a UNIX Hotline Client

just to pick a few obvious ones off the first page of the orphaned package
list that I'd have no idea how to test.

> Also, I am wondering how much success such a 'common maintained packages
> team' would have while there is a shortage of people caring for general
> QA of orphaned packages or just on the archive at all.

Yeah.  It's not like there's a shortage of work now.  I have 20 or 25
saved messages of people looking for sponsors, another 20 QA packages with
bugs that I think I can fix, and a bunch of work for the Debian Perl group
that I could do as soon as I find some free time.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: initramfs-tools backport?

[Norbert Tretkowski]

* Joerg Platte wrote:
> Am Montag, 7. November 2005 17:48 schrieb Norbert Tretkowski:
> > I'll add initramfs-tools soon, the reason why there's only yaird
> > is that it's easier to backport than initramfs-tools.
> 
> Great news :-) I'm using initramfs-tools for sid for some time now
> with some enhancements to support an rsync-based update mechanism.
> With a backported version it's possible to port these scripts to our
> sarge based cluster and computer pool. IMHO, initramfs-tools is much
> easier to understand and enhance than the old initrd system. 

It was just uploaded.

Norbert


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

French cheese

[Matt Zimmerman]

On Thu, Jan 12, 2006 at 07:26:50AM +0100, Christian Perrier wrote:
> /me...who expects tons of Ubuntu/Debian discussions at Solutions Linux
> in Paris (Jan 31-Feb 2) with both fellow French developers,
> users...and Ubuntu users as well. No chance that people from Canonical
> show up over there? I can even host (Perrier's bed and breakfast,
> including cheese)...:)

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

-- 
 - mdz


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

pbuilder: cowdancer/cowbuilder status update

[Junichi Uekawa]

Hi,

This is an update on using userland COW method with pbuilder.

cowdancer is a tool that allows you to "cp -al" (hardlink) a tree, and
break the hardlink when a write-open to a file is performed. The
adventurous part of cowdancer COW implementation is that it's trying
to do this from within userland only.

cowbuilder doesn't really exist yet; it's a name for pbuilder ported
to fully use cowdancer. cowdancer is under development, and Debian
package exists in unstable. It seems like it's getting nearly there
with the feature set. With version 0.8, performance is improved
against a large tree (I profiled against building the kernel), and
with version 0.9, I fixed a bug which you could not replace /lib/ld.so
while cowdancer was running.

There are a few known bugs and limitations with cowdancer:

1. dpkg does open(O_RDONLY), fchown()/fchmod(). 

  cowdancer is built on a heuristics where a read-only access to an
  i-node will not modify the i-node. This case is currently not
  handled.

2. cowdancer is user-space application

  because it is a user-space application, it cannot do copy-on-write
  operation atomically. If there was a multi-thread application trying
  to newly open a file for write, there is a race condition for COW.


However, most of the tests indicate that it's working good enough.
tests/log/900_test_pbuilder.sh.log in cowdancer source tree is a log
of a run, and tests/900_test_pbuilder.sh is the script to invoke
pbuilder for testing. There is no pretty frontend to pbuilder-cow yet,
but it seems to be theoretically there.

The guts of cowbuilder from tests/900_test_pbuilder.sh are:

sudo cp -al $ORIG $WORK-1
sudo cp var/log/dpkg.log /tmp/a
sudo pbuilder update --buildplace $WORK-1 --no-targz 
--internal-chrootexec "chroot $WORK-1 cow-shell"
sudo pbuilder build --buildplace $WORK-1 --no-targz 
--internal-chrootexec "chroot $WORK-1 cow-shell" dsh*.dsc


regards, 
junichi
-- 
[EMAIL PROTECTED],netfort.gr.jp}   Debian Project


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

> What does aptitude give as the breakdown between unused packages being
> automatically removed, and packages being removed that you actually
> requested installed?

Well I did not install any packages through aptitude.

The numbers of packages below the lines
The following packages will be automatically REMOVED:
and
The following packages will be REMOVED:
are the same.

> In spite of the large number of packages removed, almost all of these are
> packages that are not in etch...  From a-c, only these packages are in your
> removal list and also in testing at present:  ardour-gtk aspell-br aspell-cy
> aspell-da aspell-de aspell-de-alt aspell-el aspell-en aspell-es aspell-fi
> aspell-fr aspell-ga aspell-gl-minimos aspell-is aspell-it aspell-lt
> aspell-nl aspell-no aspell-pl aspell-pt aspell-pt-br aspell-sk aspell-sl
> aspell-sv aspell-ukr bitscope caudium-pixsl
> 
> So, counting the aspell issue as one, that looks like a total of 4 upgrade
> problems.  Which is four too many, but not as bad as it looks based on the
> output alone. :)

Well, that, and why I still cannot deal with aptitude.
Thanks for you review!

Cheers,
Bill.


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