Re: debian mentors & ubuntu

[Shot - Piotr Szotkowski]

Hello.

David Nusinow:

> On Wed, Jul 20, 2005 at 10:30:14AM +0900, Miles Bader wrote:

>> [The small amount of stuff that _is_ different seems to mostly be
>> high-profile end-user GUI apps that aren't going to have much
>> significance for a server anyway.]

> Then why not run Debian?

My wild guess, based on
http://toolbar.netcraft.com/site_report?url=http://mentors.debian.net -
because back in September 2004 Apache 2.0.50 and PHP 4.3.8 was in the
supported and stable Ubuntu Warty, while not being in the supported and
stable Debian woody.

Cheers,
-- Shot
-- 
 The above comment may be extremely inflamatory. For your protection,
 it has been rot13'd twice.  -- JWhitlock, /.
== http://shot.pl/hovercraft/ === http://shot.pl/1/125/ ===


signature.asc
Description: Digital signature

Re: BTS version tracking

[Pierre Habouzit]

Le Lun 18 Juillet 2005 23:36, Matthew Palmer a écrit :
> On Mon, Jul 18, 2005 at 12:06:29PM +0100, Colin Watson wrote:
> > A frequently requested feature for the bug tracking system in
> > recent years has been the ability to track which bugs apply to
> > which distributions, so that, eg, maintainers and others can tell
> > which bugs that have been fixed in unstable still apply to packages
> > in testing or stable.
> >
> > This has now been implemented.
>
> May I just say, to Colin, Anthony, James, and anyone else who had the
> slightest bit to do with implementing this functionality:
>
> Thank You.

Same here ... this is *really* a relief
-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpoQ6bxQET02.pgp
Description: PGP signature

Re: aspell upgrade woes

[Goswin von Brederlow]

Brian Nelson <[EMAIL PROTECTED]> writes:

> Steve Langasek <[EMAIL PROTECTED]> writes:
>
>> On Tue, Jul 19, 2005 at 09:39:23PM -0700, Brian Nelson wrote:
>>> It's a C++ library and the ABI changed due to being compiled with GCC
>>> 4.0.
>>
>>> [Actually, although it's written in C++, AFAIK it only exports a C
>>> interface so the transition may not have been necessary.  I only
>>> realized this yesterday though and I'm not entirely sure a
>>> non-transition would be safe.]
>>
>> Heh.  I've just confirmed this...
>>
>> As with libGLU, libaspell is used in enough places that there's a
>> definite benefit to not breaking package compatibility unnecessarily.
>> Since libaspell15c2's shlibs refer to "libaspell15c2 (>= 0.60)", the
>> only way to provide full compatibility is with two real packages.  I
>> would suggest restoring libaspell15, and creating a dummy
>> libaspell15c2 package that depends on libaspell15 and can be dropped
>> once everything has been rebuilt to use libaspell15 again; that would
>> minimize the disruption caused by the flip-flopping of the lib name.
>>
>> Brian, if you agree, I'm happy to prepare a patch.

Actualy, since aspell FTBFS and libaspell15c2 was never in the archive
for all archs there shouldn't be any package linked against it. The
transition rules said to wait before uploading rdepends. This
obviously needs to be checked.

Also, all sources should duild-depend on the new aspell or some buildd
will use the libaspell15c2 instead and still get the 'broken' depeneds
entry and delay removing libaspell15c2.

So I would say just drop libaspell15c and reupload anything that was
already wrongfully uploaded again.

> Reintroducing the libaspell15 could cause problems with /usr/bin/aspell,
> since it actually goes outside the C API of libaspell and uses C++
> linkage to some symbols.  I "fixed" this bug (#307481) by making
> aspell-bin (or now just aspell) depend on the Source-Version of
> libaspell.
>
> However, that fix is not in the stable package of aspell.  In stable,
> aspell-bin just depends on libaspell15 (>= 0.60), so a partial upgrade
> of just libaspell15 would break aspell-bin.  I suppose I could make the
> new libaspell15 conflict with the old aspell-bin, but that's rather
> clumsy and could make upgrades even more awkward.

Why? This is exactly what a versioned conflict is for. The packages
have to be upgraded as pair and apt/dpkg will hapily do that. Having
libaspell15c2 conflict libaspell15 makes it no easier than having
libaspell15 conflict the old aspell-bin.

> I'm not sure what the best thing to do would be.  I'm sort of inclined
> to just stick with the transitioned libaspell15c2...

Going back to libaspell unbreaks a bunch of rdepends and means aspell
can go into sarge on it's own, without waiting for the rats tail to
get transitioned as well. I think that is well worth it.

My 2 cents,
Goswin


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

Re: debian mentors & ubuntu

[Nico Golde]

Hi,
* Matthew Palmer <[EMAIL PROTECTED]> [2005-07-20 08:54]:
> On Tue, Jul 19, 2005 at 12:21:09PM +0200, Nico Golde wrote:
> > why is mentors.debian.net powered by Ubuntu?
> 
> Why is this question on debian-devel, instead of in the inbox of the m.d.n
> maintainers?

You are right, wrong place, sorry.
Regards Nico

-- 
Nico Golde - JAB: [EMAIL PROTECTED] | GPG: 0x73647CFF
http://www.ngolde.de | http://www.muttng.org | http://grml.org 
VIM has two modes - the one in which it beeps 
and the one in which it doesn't -- encrypted mail preferred


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

Re: aspell upgrade woes

[Ron Johnson]

On Wed, 2005-07-20 at 09:52 +0200, Goswin von Brederlow wrote:
> Brian Nelson <[EMAIL PROTECTED]> writes:
> 
> > Steve Langasek <[EMAIL PROTECTED]> writes:
[snip]
> So I would say just drop libaspell15c and reupload anything that was
> already wrongfully uploaded again.

What does that do to people who have already installed libaspell15c2,
and are in the middle of the cut-over?

[snip]

-- 
Ron Johnson <[EMAIL PROTECTED]>


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

Re: aspell upgrade woes

[Goswin von Brederlow]

Ron Johnson <[EMAIL PROTECTED]> writes:

> On Wed, 2005-07-20 at 09:52 +0200, Goswin von Brederlow wrote:
>> Brian Nelson <[EMAIL PROTECTED]> writes:
>> 
>> > Steve Langasek <[EMAIL PROTECTED]> writes:
> [snip]
>> So I would say just drop libaspell15c and reupload anything that was
>> already wrongfully uploaded again.
>
> What does that do to people who have already installed libaspell15c2,
> and are in the middle of the cut-over?
>
> [snip]

They get the libaspell back when they upgrade aspell-bin.

Same thing that happened that made them get libaspell15c2.


amd64:~% apt-cache rdepends libaspell15c2
W: Unable to locate package libaspell15c2

Nothing happens on amd64, alpha or ia64.


i386:~% apt-cache rdepends libaspell15c2
libaspell15c2
Reverse Depends:
  aspell-pl
  logjam
  libtext-aspell-perl
  libpspell-dev
  libgtkspell0
  libenchant1c2
  libaspell-dev
  gedit
  gaim
  balsa
  aspell
  aspell


All those would need a quick reupload.

The reason I'm against introducing a dummy package is that it will
cause those packages listed above to depend on different packages
(libaspell15 vs libaspell15c2) depending on the architecture. Without
dummy package they are forced to make a new upload at the proper time.

MfG
Goswin


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

about voting for bugs

[Paul Brossier]

Hi,

With all these great news about the BTS these days, it would be nice to
think about adding a voting feature: a way to count the number of users
that are annoyed by each bug. It could be either a simple way to submit
a follow-up to say 'hey, i faced this one too', either just a button on
bugreport.cgi, or something else.

Provided the system gets used, this could help us to evaluate the
priorities of our users, highlight bugs that annoy the most users, and
have another view on WNPP packages. This should also encourage
maintainers to send updates to the BTS.

just my 2¢, forgive me if i missed previous related threads,
Paul


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

Re: about voting for bugs

[Margarita Manterola]

On 7/20/05, Paul Brossier <[EMAIL PROTECTED]> wrote:

> With all these great news about the BTS these days, it would be nice to
> think about adding a voting feature: a way to count the number of users
> that are annoyed by each bug. It could be either a simple way to submit
> a follow-up to say 'hey, i faced this one too', either just a button on
> bugreport.cgi, or something else.
> 
> Provided the system gets used, this could help us to evaluate the
> priorities of our users, highlight bugs that annoy the most users, and
> have another view on WNPP packages. This should also encourage
> maintainers to send updates to the BTS.

Although I like the general idea, I think that just having a "button"
for that would be too simple for this to get abused.  So this should
be a compromise between a simple enough system that allows people to
indicate the also experienced this, and complex enough that it doesn't
get abused by people (or robots, actually) randomly clicking buttons.

-- 
Besos,
Marga

Re: about voting for bugs

[Olaf van der Spek]

On 7/20/05, Paul Brossier <[EMAIL PROTECTED]> wrote:
> Hi,
> 
> With all these great news about the BTS these days, it would be nice to
> think about adding a voting feature: a way to count the number of users
> that are annoyed by each bug. It could be either a simple way to submit
> a follow-up to say 'hey, i faced this one too', either just a button on
> bugreport.cgi, or something else.

Why not just submit a 'me too' email to the bug report?
 
> Provided the system gets used, this could help us to evaluate the
> priorities of our users, highlight bugs that annoy the most users, and
> have another view on WNPP packages. This should also encourage
> maintainers to send updates to the BTS.

Re: about voting for bugs

[zorglub]

Hello,

> Why not just submit a 'me too' email to the bug report?

I think it should be a command for the control bot. A simple 'me too' mail
clutters the bug report, cannot be easily counted, whereas a simple
command ("confirm #XX" for example) would allow to count such votes,
use them as search criteria, ...

-- 
Clément


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

Re: about voting for bugs

[Stuart Yeates]

Paul Brossier wrote:
> Hi,
> 
> With all these great news about the BTS these days, it would be nice to
> think about adding a voting feature: a way to count the number of users
> that are annoyed by each bug. It could be either a simple way to submit
> a follow-up to say 'hey, i faced this one too', either just a button on
> bugreport.cgi, or something else.
> 
> Provided the system gets used, this could help us to evaluate the
> priorities of our users, highlight bugs that annoy the most users, and
> have another view on WNPP packages. This should also encourage
> maintainers to send updates to the BTS.

Maybe a good place to start would be to cross reference BTS with the
popularity-contest database. This doesn't measure annoyance, of
course, but it's a a great measure of how many people are
potentially effected by a bug.

cheers
stuart
-- 
Stuart Yeates[EMAIL PROTECTED]
OSS Watch  http://www.oss-watch.ac.uk/
Oxford Text Archive http://ota.ahds.ac.uk/
Work Blog   http://blog.educause.edu/StuartYeates/


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

Re: about voting for bugs

[Andreas Fester]

I like this idea too, since it would allow better prioritization
of bugs, and maybe help for a better planning of releases in
the future. Unfortunately, to really avoid abuse, this would end
in the necessity to introduce some kind of registration and login
mechanism to the BTS.

What about a simpler solution for the beginning? Assumed that
annoying bugs have more replies, the bugs could be sorted by the
number of replies to get an idea of their priority. This faces
towards the idea of sending a "Me too" follow-up as proposed
by Paul, which is less anonymous than a "vote" button which everyone
can push randomly, but still can be used by each user through the
BTS mail interface.

Just some thoughts

Regards,

Andreas

Margarita Manterola wrote:
[...]

that are annoyed by each bug. It could be either a simple way to submit
a follow-up to say 'hey, i faced this one too', either just a button on
bugreport.cgi, or something else.


[...]

Although I like the general idea, I think that just having a "button"
for that would be too simple for this to get abused.  So this should
be a compromise between a simple enough system that allows people to
indicate the also experienced this, and complex enough that it doesn't
get abused by people (or robots, actually) randomly clicking buttons.


--
Andreas Fester
mailto:[EMAIL PROTECTED]
WWW: http://littletux.homelinux.org
ICQ: 326674288


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

Re: debian mentors & ubuntu

[Christoph Haas]

Hi, Nico...

I'm not reading debian-devel for two days and now this. ;)

On Tue, Jul 19, 2005 at 12:21:09PM +0200, Nico Golde wrote:
> why is mentors.debian.net powered by Ubuntu?

mentors.debian.net is work in progress. As we are working on an
improvement of the import process (that analyses the uploaded packages
and moves them into the repository pool structure) and web interface we
needed software versions (e.g. Postgresql) that were not available in
Woody at that time.

Unfortunatly Sarge was not a choice for us either since our machine is
under permanent attack and has already once been hacked due to an
unfixed bug in a forum software. So we needed something more stable.
Since Ubuntu had released a stable version thus supplying us with
security updates we chose to use that until Sarge is released.

Now that Sarge is stable it's on my to do list to reinstall the server
on Sarge. 

mentors.debian.net is not sponsored by Ubuntu nor am I on on the payroll
of Mark Shuttleworth. ;) I had donated the server which is currently
running at my place (until we find a new decent ISP in my area to
run it at). I hope this clears the confusion up a bit. 

Good to hear that people still care about it though. :)

Cheers
 Christoph
-- 
~
~
~
".signature" [Modified] 3 lines --100%--3,41 All


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

Re: about voting for bugs

[Paul Brossier]

On Wed, Jul 20, 2005 at 10:49:37AM +0100, Stuart Yeates wrote:
> Maybe a good place to start would be to cross reference BTS with the
> popularity-contest database. This doesn't measure annoyance, of
> course, but it's a a great measure of how many people are
> potentially effected by a bug.

surely installing popcon should be encouraged. but popcon could not
count the people who didn't keep or install this package because of the
bug, or what bugs are important within one source package.

cheers, paul 


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

Re: about voting for bugs

[Jon Dowland]

On Wed, Jul 20, 2005 at 10:24:02AM +0100, Paul Brossier wrote:
> Hi,
> 
> With all these great news about the BTS these days, it would be nice to
> think about adding a voting feature: a way to count the number of users
> that are annoyed by each bug. It could be either a simple way to submit
> a follow-up to say 'hey, i faced this one too', either just a button on
> bugreport.cgi, or something else.

In principle, I like this idea. However

> Provided the system gets used
^^^
That's the key point: It must be used and embraced by the people working
on the bugs. See , where
I discover that attempts to leverage voting etc. on the mozilla bts
amount to nothing.

-- 
Jon Dowland
http://jon.dowland.name/
PGP fingerprint: 7032F238


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

Re: about voting for bugs

[Nigel Jones]

On 20/07/05, Paul Brossier <[EMAIL PROTECTED]> wrote:
> On Wed, Jul 20, 2005 at 10:49:37AM +0100, Stuart Yeates wrote:
> > Maybe a good place to start would be to cross reference BTS with the
> > popularity-contest database. This doesn't measure annoyance, of
> > course, but it's a a great measure of how many people are
> > potentially effected by a bug.
> 
> surely installing popcon should be encouraged. but popcon could not
> count the people who didn't keep or install this package because of the
> bug, or what bugs are important within one source package.
Bugcon?

Could be a module for reportbug, if user says that the bug he wishs to
report is already on the database, user gets prompted:
 Do you wish to add new information, or comfirm existance of bug? [1,2]
  1 = Add new info
  2 = Confirm/Vote

It doesn't have to be a module, can be built into the program.
> 
> cheers, paul
> 
> 
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 
> 


-- 
N Jones
Blogging @ http://nigelj.blogspot.com
Proud Debian & FOSS User
Debian Maintainer of: html2ps & ipkungfu

popcon (was Re: about voting for bugs)

[Jon Dowland]

On Wed, Jul 20, 2005 at 11:29:37AM +0100, Paul Brossier wrote:
> surely installing popcon should be encouraged.

I've been thinking about how popcon might be suggested by
debian-installer. A cursory google search shows that this has been
discussed in the past: can anyone point me at a summary?

-- 
Jon Dowland
http://jon.dowland.name/
PGP fingerprint: 7032F238


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

Re: about voting for bugs

[Andreas Tille]

Hi,

if you ask me any bug is worth fixing, also if only a single user complained
about the problem.  So why spending effort in "rating" bugs?

Kind regards

Andreas.

--
http://fam-tille.de


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

Re: debian mentors & ubuntu

[Nico Golde]

Hi,
* Christoph Haas <[EMAIL PROTECTED]> [2005-07-20 12:28]:
> I'm not reading debian-devel for two days and now this. ;)

:)

> On Tue, Jul 19, 2005 at 12:21:09PM +0200, Nico Golde wrote:
> > why is mentors.debian.net powered by Ubuntu?
> 
> mentors.debian.net is work in progress. As we are working on an
> improvement of the import process (that analyses the uploaded packages
> and moves them into the repository pool structure) and web interface we
> needed software versions (e.g. Postgresql) that were not available in
> Woody at that time.
> 
> Unfortunatly Sarge was not a choice for us either since our machine is
> under permanent attack and has already once been hacked due to an
> unfixed bug in a forum software. So we needed something more stable.
> Since Ubuntu had released a stable version thus supplying us with
> security updates we chose to use that until Sarge is released.

[...] 
Ok thanks for the information.
For all the people who said: "oh a typicall nico golde flame
question".
I wrote it in my mails, it wasn't my intention to rant
ubuntu and it wasn't my intention to start a flame on this
list.

So it is not my fault if people start doing so. Everybody
has the possibility to ignore the mail. For the fact that it
was the wrong list I appologized in my last mail.
So please keep on fighting for peace :)
Regards Nico
-- 
Nico Golde - JAB: [EMAIL PROTECTED] | GPG: 0x73647CFF
http://www.ngolde.de | http://www.muttng.org | http://grml.org 
VIM has two modes - the one in which it beeps 
and the one in which it doesn't -- encrypted mail preferred


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

Re: debian mentors & ubuntu

[Christoph Haas]

On Wed, Jul 20, 2005 at 01:01:09PM +1000, Matthew Palmer wrote:
> The intention, as I understand it, isn't to be a general-purpose package
> repository (at least, last time I looked at it, no pre-built binary packages
> were provided), but to be a "staging area" of sorts for packages which
> people wanted sponsored into the archive.

That's correct. And we are trying to massively improve the user
interface. Our goal is to provide a platform which allows better
interaction between sponsors and sponsorees. As most people know it's
hard to keep a package sponsored for a long time since many sponsors
lose interest in sponsorship. So in the hopefully-not-so-far-future we
will have a portal that shows which packages need sponsorship and also
notice the current sponsors if the sponsorees have a new package ready.

> The value of the packages therein is a subjective matter, and one which I,
> for one, am not touching with my 10 foot pole (Barge, mk1, mod0).

Many of the packages are definitely not advised to be used by end-users
or even in production environments. Most packages that are displayed on
http://mentors.debian.net are just needing a sponsor to take a look at.
What is sometimes confused is that mentors.debian.net is not yet another
inofficial binary package repository like Christian Marillat's server.

In the past we even kept the binary packages (.deb). But since many
people seemed to have put our server in the sources.list we not only had
lots of traffic but also complaints that the packages were of bad
quality. Since then we only provide source packages so that there is at
least the dpkg-buildpackage barrier that keeps people from blindly using
them.

I guess I have to review the introductory texts on the main page soon.
That will probably not stop the flaming though...

Cheers
 Christoph
-- 
~
~
~
".signature" [Modified] 3 lines --100%--3,41 All


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

Re: debian mentors & ubuntu

[Jon Dowland]

On Tue, Jul 19, 2005 at 09:44:43PM -0400, David Nusinow wrote:
> Then why not run Debian?

That's a question for the admins. Is the server only hosting this
debian.net service and nothing else? Maybe it is primarily running
something else and offered to host this debian.net service on top. As
another poster has mentioned, there may have been very valid reasons for
choosing Ubuntu above Debian for the primary purpose of the machine.

-- 
Jon Dowland
http://jon.dowland.name/
PGP fingerprint: 7032F238


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

Re: about voting for bugs

[Paul Brossier]

On Wed, Jul 20, 2005 at 10:40:08PM +1200, Nigel Jones wrote:
> On 20/07/05, Paul Brossier <[EMAIL PROTECTED]> wrote:
> > On Wed, Jul 20, 2005 at 10:49:37AM +0100, Stuart Yeates wrote:
> > > Maybe a good place to start would be to cross reference BTS with the
> > > popularity-contest database. This doesn't measure annoyance, of
> > > course, but it's a a great measure of how many people are
> > > potentially effected by a bug.
> > 
> > surely installing popcon should be encouraged. but popcon could not
> > count the people who didn't keep or install this package because of the
> > bug, or what bugs are important within one source package.
> Bugcon?
> 
> Could be a module for reportbug, if user says that the bug he wishs to
> report is already on the database, user gets prompted:
>  Do you wish to add new information, or comfirm existance of bug? [1,2]
>   1 = Add new info
>   2 = Confirm/Vote
> 
> It doesn't have to be a module, can be built into the program.

yes, the voting feature should probably go in bugreport, along with a
one shot command such as 'reportbug NN-vote', that would make it
easy to use: collect infos about the system and the version installed,
send them to [EMAIL PROTECTED] and to [EMAIL PROTECTED] with a 'confirm NN'.

paul


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

Re: about voting for bugs

[Jon Dowland]

On Wed, Jul 20, 2005 at 12:44:14PM +0200, Andreas Tille wrote:
> Hi,
> 
> if you ask me any bug is worth fixing, also if only a single user
> complained about the problem.  So why spending effort in "rating"
> bugs?

We rate bugs already, by severity, but I understand your point, and it
appears to be one that the mozilla BTS people agree with.

-- 
Jon Dowland
http://jon.dowland.name/
PGP fingerprint: 7032F238


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

Re: about voting for bugs

[Petter Reinholdtsen]

[Andreas Tille]
> if you ask me any bug is worth fixing, also if only a single user
> complained about the problem.  So why spending effort in "rating"
> bugs?

To get some indication on the order the bugs should be solved in?  As
we have limited time and people, it is smart to start with the bugs
affecting most people.


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

Re: popcon (was Re: about voting for bugs)

[Petter Reinholdtsen]

[Jon Dowland]
> I've been thinking about how popcon might be suggested by
> debian-installer. A cursory google search shows that this has been
> discussed in the past: can anyone point me at a summary?

The next version of d-i will ask for participation during the
installation.  It was fixed just before debconf5.

Sad we didn't manage to do that before sarge was released, but that is
life. :/


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

Re: popcon (was Re: about voting for bugs)

[Jon Dowland]

On Wed, Jul 20, 2005 at 01:01:09PM +0200, Petter Reinholdtsen wrote:
 
> The next version of d-i will ask for participation during the
> installation.  It was fixed just before debconf5.

Brilliant - that's the outcome I thought would be best :)

> Sad we didn't manage to do that before sarge was released, but that is
> life. :/

Indeed.

Cheers,

-- 
Jon Dowland
http://jon.dowland.name/
PGP fingerprint: 7032F238


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

Re: about voting for bugs

[Andreas Tille]

On Wed, 20 Jul 2005, Petter Reinholdtsen wrote:


To get some indication on the order the bugs should be solved in?  As
we have limited time and people, it is smart to start with the bugs
affecting most people.

IMHO this might lead to the wrong assumption that bugs with only one
vote have lower priority to become fixed.  It might perfectly possible
that - for whatever reason - the people who are concerned by the bug
just do not report bugs.  I know several people (if you like call them
the "stupid users") who did not even noticed that you can report bugs.
If one of these users with very basic skills found a bug and managed to
report it, but others didn't the bug will be lost amongst the others
of the "noisy" users which are basically developers and tend to be
much more skilled in using the BTS.  So the reslut would probably be that
we fix the bugs of "skilled" people more often than of these of the
"not so skilled" users.

Kind regards

Andreas.

--
http://fam-tille.de


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

Re: about voting for bugs

[Mark Brown]

On Wed, Jul 20, 2005 at 12:44:14PM +0200, Andreas Tille wrote:

> if you ask me any bug is worth fixing, also if only a single user complained
> about the problem.  So why spending effort in "rating" bugs?

Some of the relevant Bugzilla developers have articulated a couple of
reasons for their voting feature:

 - Users like having the ability to provide some input on bugs they
   consider important, to show that they care about them.  Providing a
   voting mechanism allows them to do this without generating excessive
   noise within the bug log (like "Please fix this!  It's a big problem
   for us!" messages) that obscures useful information.

 - Some developers may choose to use the votes to help them either find
   bugs to work on (eg, people doing general QA work) or decide how to
   prioritise their time.

They considered the former reason much more important since it helps
give a more positive experience for users even if the voting information
is not otherwise used.

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


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

Re: about voting for bugs

[Francesco P. Lovergine]

On Wed, Jul 20, 2005 at 01:00:04PM +0200, Petter Reinholdtsen wrote:
> [Andreas Tille]
> > if you ask me any bug is worth fixing, also if only a single user
> > complained about the problem.  So why spending effort in "rating"
> > bugs?
> 
> To get some indication on the order the bugs should be solved in?  As
> we have limited time and people, it is smart to start with the bugs
> affecting most people.
> 

I can only see usefulness for QA team (orphaned) packages. A properly 
maintained package should have a thinking machine (maintainer)
who is able to discriminate what's a spurious bug and what's not.
That could be useful to create a priority list for QA team jobs, but
I wonder if it's better than the proposed popcon approach.

-- 
Francesco P. Lovergine


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

Re: about voting for bugs

[Goswin von Brederlow]

Paul Brossier <[EMAIL PROTECTED]> writes:

> Hi,
>
> With all these great news about the BTS these days, it would be nice to
> think about adding a voting feature: a way to count the number of users
> that are annoyed by each bug. It could be either a simple way to submit
> a follow-up to say 'hey, i faced this one too', either just a button on
> bugreport.cgi, or something else.

I would prefer a "subscribe" for bugs. If I am a user that hits the
same bug I want to get mails send so nnn-submitter and especialy want
to get a mail when the bug gets closed. I don't want to subscribe to
the PTS, just the one bug.

The number of people subscribed to a bug (number of people in the
submitter field) would be your vote count.

On that note, is it already possible to change the submitter to
"[EMAIL PROTECTED],[EMAIL PROTECTED]" to get two submitters? In that case it
would just need a nicer interface and someone counting.

> Provided the system gets used, this could help us to evaluate the
> priorities of our users, highlight bugs that annoy the most users, and
> have another view on WNPP packages. This should also encourage
> maintainers to send updates to the BTS.
>
> just my 2¢, forgive me if i missed previous related threads,
> Paul

I think (except for a few realy big cases like gnome, kde or xfree)
that maintainers that care about their package will keep the bug count
at 0 or near enough and fix any new issue quickly. Packages with lots
of bugs, and only there the voting would be benefitial, tend to have
maintainers that don't care anyway.

So while this might show bugs that are damn anoying to everyone it
might not get them fixed any sooner.

Just my 2c and I still want the subscribtion feature.

MfG
Goswin


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

Re: about voting for bugs

[Adeodato Simó]

* Goswin von Brederlow [Wed, 20 Jul 2005 13:26:28 +0200]:

> I would prefer a "subscribe" for bugs. If I am a user that hits the
> same bug I want to get mails send so nnn-submitter and especialy want
> to get a mail when the bug gets closed. I don't want to subscribe to
> the PTS, just the one bug.

  Debian Bug Subscription Feature, by Joachim Breitner:

http://lists.debian.org/debian-devel/2005/07/msg00490.html

-- 
Adeodato Simó
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
 
Ara que ets la meva dona, te la fotré fins a la melsa, bacona!
-- Borja Álvaro a Miranda Boronat en «Chulas y famosas»


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

Re: about voting for bugs

[Paul Brossier]

On Wed, Jul 20, 2005 at 01:12:52PM +0200, Andreas Tille wrote:
> On Wed, 20 Jul 2005, Petter Reinholdtsen wrote:
> 
> >To get some indication on the order the bugs should be solved in?  As
> >we have limited time and people, it is smart to start with the bugs
> >affecting most people.
> IMHO this might lead to the wrong assumption that bugs with only one
> vote have lower priority to become fixed.  It might perfectly possible
> that - for whatever reason - the people who are concerned by the bug
> just do not report bugs.  I know several people (if you like call them
> the "stupid users") who did not even noticed that you can report bugs.
> If one of these users with very basic skills found a bug and managed to
> report it, but others didn't the bug will be lost amongst the others
> of the "noisy" users which are basically developers and tend to be
> much more skilled in using the BTS.  So the reslut would probably be that
> we fix the bugs of "skilled" people more often than of these of the
> "not so skilled" users.

Andreas,

obviously the voting feature would in no way account in the severity of
the bug, and the maintainer should make the final decision. and if the
feature is implemented and gets used, users will do the job of counting. 

of course, there is a risk that few people will vote too often, and that
too many won't vote at all. in a way, we already faced the same issues
with popcon, which is probably used in majority by 'skilled users'. 

we could try to address this by encouraging the use of BTS and
integrating the bug reporting processes. i think such a feature is in
itself encouraging the 'not so skilled' user to go and check the BTS.

cheers, paul


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

unsubscribe

[CoolFox]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



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

iD8DBQFC3jn6VZI/p353HiARApRzAJ993w2jRjwnjf9fwjMIA4V8XZEttQCbBUlw
G8Obku3P8I1PRazWOzPSGoA=
=C9+N
-END PGP SIGNATURE-


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

Re: about voting for bugs

[Benjamin Mesing]

Hello,

 
> > To get some indication on the order the bugs should be solved in?  As
> > we have limited time and people, it is smart to start with the bugs
> > affecting most people.
> > 
> 
> I can only see usefulness for QA team (orphaned) packages. A properly 
> maintained package should have a thinking machine (maintainer)
> who is able to discriminate what's a spurious bug and what's not.+
Like Mark Brown mentioned in his post it is also good for the psychology
of the users. When voting for a bug you have the good feeling of having
done something. I know the feeling if I have search the list off all the
500 bugs only to find out that my one was already reported and nothing
new to add.
Additionally e.g. the maintainers do _not_ always know what is most
important for the user (especially for wishlist items..). I myself would
like to have rated bugs against my packages, if I had to deal with a
large number of bugs. Of course the final desicion which bug to fix is
to be made by the maintainer, and of course there is the possibility
that the maintainer gets flamed because she fixes the vote1 bug before
the vote20 bug. But maintainers get flamed already and I doubt that this
would increase the overall amount of flaming.

Greetings Ben


-- 
Please do not sent any email to the [EMAIL PROTECTED] - all email not
originating from the mailing list will be deleted automatically. Use the
reply to address instead.


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

Re: Re: aspell upgrade woes

[Nathanael Nerode]

[EMAIL PROTECTED] wrote:

[Actually, although it's written in C++, AFAIK it only exports a C
interface so the transition may not have been necessary.  I only
realized this yesterday though and I'm not entirely sure a
non-transition would be safe.]


Non-transition is safe and desirable if all the C++ libraries it depends on use
versioned symbols.  libstdc++ does, and apparently that's the only one libaspell
depends on.  So indeed no transition is necessary or desirable for libaspell.

(If a C++-written library exporting only a C interface depended on a C++ 
library which
had unversioned symbols (whew!), then a transition might be neccesary, but I'm 
not
sure; if that case ever comes up, it's worth extra analysis.)




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

Re: BTS version tracking

[Colin Watson]

On Tue, Jul 19, 2005 at 10:34:23PM -0700, Brian Nelson wrote:
> Colin Watson <[EMAIL PROTECTED]> writes:
> > The 'reopen' command takes an optional submitter argument, so it was
> > difficult to get a version in here unambiguously. Instead, we've
> > introduced a new 'found' command, which says "I've found the bug in this
> > version of the package". You can use this whether the bug is open or
> > closed; if the bug's closed and you give a version more recent than the
> > last recorded fixed version, the bug will be considered open again.
> >
> >   found 1234567 1.3-2
> 
> Shouldn't that be, "you give a version more recent than *or equal to*
> the last recorded fixed version..."?

Mm, right, that's what I meant to say.

> What if the maintainer uploads a version, say 1.3-2 (which is still the
> most recent version), which supposedly fixes bug 1234567.  However, I
> test it and find that it's actually not fixed.  Presumably, I would do:
> 
>   found 1234567 1.3-2
> 
> However, since 1.3-2 is equal to the current version, the BTS would
> erroneously think that the bug is fixed.  That does seem to match
> reality:
> 
>   http://bugs.debian.org/316089

Yes, this is a bug in version tracking: it's a canonicalisation problem
between various internal representations of versions in debbugs,
reported as bug #319037. Fortunately I don't think it's *too* hard to
solve ...

-- 
Colin Watson   [EMAIL PROTECTED]


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

Re: about voting for bugs

[Goswin von Brederlow]

Mark Brown <[EMAIL PROTECTED]> writes:

> They considered the former reason much more important since it helps
> give a more positive experience for users even if the voting information
> is not otherwise used.

Like those "Press to get a signal" buttons on traffic lights that
aren't hooked up to anything, right. :)

MfG
Goswin


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

Re: about voting for bugs

[Goswin von Brederlow]

Adeodato Simó <[EMAIL PROTECTED]> writes:

> * Goswin von Brederlow [Wed, 20 Jul 2005 13:26:28 +0200]:
>
>> I would prefer a "subscribe" for bugs. If I am a user that hits the
>> same bug I want to get mails send so nnn-submitter and especialy want
>> to get a mail when the bug gets closed. I don't want to subscribe to
>> the PTS, just the one bug.
>
>   Debian Bug Subscription Feature, by Joachim Breitner:
>
> http://lists.debian.org/debian-devel/2005/07/msg00490.html

Nice.

MfG
Goswin


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

Re: Who needs libcurl3? (was libcurl3-dev: A development package linked again gnutls needed)

[Marco d'Itri]

On Jul 20, sean finney <[EMAIL PROTECTED]> wrote:

> i think that would solve the problem by muting the symptoms.  what happens
> when the next free-but-not-quite-gpl-compatible licensed software is
> linked against libcurl (or something similar)?
Not relevant, gnutls is LGPL'ed.

> i know i'm repeating myself here, but the real fix is to politely
> solicit the upstream author to change or add a clause to their license
> that makes such allowances.  that, or change the build options of the
No, the real fix is to convert as many programs as possible from openssl
to gnutls, starting with libraries.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

-Wl,--as-needed -Wl,-O1 devilries

[Loïc Minier]

Hi,

 Several FTBFS are currently caused on at least sparc and alpha with the
 current toolchain in packages using -Wl,--as-needed.  It seems -Wl,-O1
 is now used by default, so as soon as you use -Wl,--as-needed, you're
 likely to hit this toolchain bug.  The toolchain maintainers were
 informed of this issue.

 -Wl,--as-needed is handy to reduce dependencies of packages, but if you
 don't particularly need it and if it's not too much work to remove its
 usage, you'd better go without it.  In general, it causes a lot of
 breakages, such as in dlopened() plugins.

 It seems that current upstream libtool and current upstream pkg-config
 could possibly be changed to reduce dependencies too, but this is won't
 happen in the short-term.  The libtool patch will probably be sent
 upstream shortly.

 You might want to relibtoolize against Debian's libtool, as it is
 specially patched and will reduce dependencies.  Of course, this is
 more work, and requires intervention for each new upstream release.


 Please see #319162 for a sample FTBFS on sparc.  Please see
  for a short test
 case trigerring the bug.

   Bye,

PS: other arches may be affected than sparc and alpha.  Also,
--as-needed or -O1 alone might cause harm too.
-- 
Loïc Minier <[EMAIL PROTECTED]>
Come, your destiny awaits!


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

Re: aspell upgrade woes

[David Nusinow]

On Tue, Jul 19, 2005 at 09:39:23PM -0700, Brian Nelson wrote:
> Uh... no...
> 
> http://lists.debian.org/debian-devel-announce/2005/07/msg1.html
> 
> It's a C++ library and the ABI changed due to being compiled with GCC
> 4.0.
> 
> [Actually, although it's written in C++, AFAIK it only exports a C
> interface so the transition may not have been necessary.  I only
> realized this yesterday though and I'm not entirely sure a
> non-transition would be safe.]

Christ, not another one. Is there any sort of automated way that we can
check for these sorts of libraries before messing things up again? I won't
be doing it again for libGLU obviously, but some sort of script or
large-scale automated check of the archive would potentially go a long way.

 - David Nusinow, who's embarrassed about what happened with libGLU


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

Re: aspell upgrade woes

[Hamish Moffatt]

On Wed, Jul 20, 2005 at 09:28:22AM -0400, David Nusinow wrote:
> On Tue, Jul 19, 2005 at 09:39:23PM -0700, Brian Nelson wrote:
> > [Actually, although it's written in C++, AFAIK it only exports a C
> > interface so the transition may not have been necessary.  I only
> > realized this yesterday though and I'm not entirely sure a
> > non-transition would be safe.]
> 
> Christ, not another one. Is there any sort of automated way that we can
> check for these sorts of libraries before messing things up again? I won't

Well, before I go and do the same, can anyone help me by checking
tqsllib?

Ubuntu has transitioned it in their 'universe' to tqsllib1c2. 
However none of the exported headers contain the magic :: sign of C++, 
so I suspect it's unnecessary. (A recompile to link against 
libstdc++6 should be sufficient, without a name change).

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


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

Bug#319201: ITP: kiax -- IAX client application

[Mark Purcell]

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

* Package name: kiax
  Version : 0.8.4
  Upstream Author : (c) 2004 - 2005, Emil Stoyanov and the Kiax Team
* URL : http://kiax.sourceforge.net
* License : GPL
  Description : IAX client application

 This is an IAX client application (a so called Softphone) which allows
 PC users to make ordinary VoIP calls to Asterisk servers, the same way
 as they do it with their hardware telephone. It aims to provide a simple
 and user-friendly graphical interface and desktop integration for calling,
 contact list, call register management and easy configuration.

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


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

Re: aspell upgrade woes

[GOMBAS Gabor]

On Wed, Jul 20, 2005 at 09:28:22AM -0400, David Nusinow wrote:

> Christ, not another one. Is there any sort of automated way that we can
> check for these sorts of libraries before messing things up again?

Theoretically libraries should export only the symbols of their public
API, and such a check could be done by looking for C++-mangled names in
the list of exported symbols.

Practically libraries tend to be rather lousy and also export a lot of
internal symbols so you have to manually check if those symbols are
meant to be public or not (and if not then are there any applications
that use them regardless).

For example, both libaspell15 and libglu1-xorg export a lot of C++
symbols that are not meant to be part of the public API...

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


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

Re: aspell upgrade woes

[Hendrik Sattler]

Hamish Moffatt wrote:

> Ubuntu has transitioned it in their 'universe' to tqsllib1c2.
> However none of the exported headers contain the magic :: sign of C++,
> so I suspect it's unnecessary. (A recompile to link against
> libstdc++6 should be sufficient, without a name change).

Is a non-present "::" really a sign that names don't get mangled? AFAIK an
extern C declaration is needed.

HS


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

Re: about voting for bugs

[Joey Hess]

Andreas Fester wrote:
> What about a simpler solution for the beginning? Assumed that
> annoying bugs have more replies, the bugs could be sorted by the
> number of replies to get an idea of their priority.

If this is implemented as an additional query that can be used from the
main page of the BTS, perhaps something like
responders=[ascending|descending] in the CGI interface, then it
would also allow for queries like responders=ascending&include=patch,
which would list bugs with patches, putting those that had no responses
first. This is a good way to find patches langushing in the BTS w/o
review.

I think that sorting by number of unique responders, rather than total
number of responses, is useful.

-- 
see shy jo


signature.asc
Description: Digital signature

Usability: Technical details in package descriptions?

[W. Borgert]

Hi,

what do you think about the usefulness of technical (and other
strange) details in package description?  I think, those are
annoying and should be avoided, but maybe I can learn, why they
are useful.  Examples:

"Foo is a Perl-based program that..."

"libBar is written in C..."

"libBang is written in only 42 lines of source code..."

"Baz has been written by me..."

Do such descriptions justify bug reports of severity=minor?

Cheers, WB


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

Re: Usability: Technical details in package descriptions?

[Nico Golde]

Hi,
* W. Borgert <[EMAIL PROTECTED]> [2005-07-20 18:08]:
> what do you think about the usefulness of technical (and other
> strange) details in package description?  I think, those are
> annoying and should be avoided, but maybe I can learn, why they
> are useful.  Examples:
> 
> "Foo is a Perl-based program that..."
> 
> "libBar is written in C..."

[...] 
I think one reason could be that some poeple would rather
install a programm in a language they know and they are able
to debug. Just a guess.

I don't think this would justify a bug report. Maybe
wishlist for a better control description but in general it
is only further information...

Regards Nico
-- 
Nico Golde - JAB: [EMAIL PROTECTED] | GPG: 0x73647CFF
http://www.ngolde.de | http://www.muttng.org | http://grml.org 
VIM has two modes - the one in which it beeps 
and the one in which it doesn't -- encrypted mail preferred


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

Re: Reformatted Ubuntu Patches Repository

[Josselin Mouette]

Le dimanche 17 juillet 2005 à 15:51 +0300, Joachim Breitner a écrit :
> Hi,
> 
> brought to you by the Utnubu team (that is me, still waiting for more
> members, hint hint :-)), is the a newly formatted repository of Ubuntu
> patches.
> 
> On http://utnubu.alioth.debian.org/scottish/by_maint/ you will find a
> directory for each maintainer with modified packages, inside directories
> for the kind of change (changelog_only, control_only, large), and then a
> directory for the change. This data is pulled from 
> http://people.ubuntu.com/~scott/patches/ but not yet automatically (I
> will automate this, but not sure if I will have time for that here).
> 
> This is meant as a more convenient way for Debian maintainers to look
> for possible useful patches from Ubuntu.

This is a good idea, but it is based on completely outdated data: about
18 months for some packages. As such, it is just useless.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


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

Re: Usability: Technical details in package descriptions?

[Ben Armstrong]

On Wed, 2005-07-20 at 18:13 +0200, Nico Golde wrote:
> [...] 
> I think one reason could be that some poeple would rather
> install a programm in a language they know and they are able
> to debug. Just a guess.

Debtags "facets"[0] are better for this.  Descriptions are supposed to
help *ordinary* users decide which programs to install.  (Hint: most of
the world doesn't know how to debug in *any* language.)

I agree that minor bugs are called for when descriptions contain
non-descriptive technical trivia like this.

Ben
[0] http://debtags.alioth.debian.org/paper-debtags.html#facets


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

Re: Usability: Technical details in package descriptions?

[Steinar H. Gunderson]

On Wed, Jul 20, 2005 at 06:13:22PM +0200, Nico Golde wrote:
> I think one reason could be that some poeple would rather
> install a programm in a language they know and they are able
> to debug. Just a guess.

You might want to look into the "implemented-in" debtags facet instead, then;
it's probably more reliable :-)

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


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

Bug#319245: ITP: libdbus-ruby -- Ruby binding for D-BUS

[Paul van Tilburg]

Package: wnpp
Severity: wishlist
Owner: Paul van Tilburg <[EMAIL PROTECTED]>

* Package name: libdbus-ruby
  Version : 0.1.10
  Upstream Author : Leon Breedt <[EMAIL PROTECTED]>
* URL : http://rubyforge.org/projects/dbus-ruby/
* License : GPL
  Description : Ruby binding for D-BUS

This module allows Ruby programs to interface with the D-BUS message
bus installed on newer Unix operating systems.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (102, 'experimental')
Architecture: powerpc (ppc)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.10-powerpc
Locale: LANG=C, [EMAIL PROTECTED] (charmap=UTF-8)


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

Re: Reformatted Ubuntu Patches Repository

[Matt Zimmerman]

On Tue, Jul 19, 2005 at 09:57:34PM +0200, Josselin Mouette wrote:
> Le dimanche 17 juillet 2005 à 15:51 +0300, Joachim Breitner a écrit :
> > This is meant as a more convenient way for Debian maintainers to look
> > for possible useful patches from Ubuntu.
> 
> This is a good idea, but it is based on completely outdated data: about
> 18 months for some packages. As such, it is just useless.

Considering that the patch index, as published by Ubuntu, a) is updated
daily, and b) has only existed for less than 12 months, I don't understand
what you are trying to say.

-- 
 - mdz


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

Re: Reformatted Ubuntu Patches Repository

[Josselin Mouette]

Le mercredi 20 juillet 2005 à 10:21 -0700, Matt Zimmerman a écrit :
> On Tue, Jul 19, 2005 at 09:57:34PM +0200, Josselin Mouette wrote:
> > Le dimanche 17 juillet 2005 à 15:51 +0300, Joachim Breitner a écrit :
> > > This is meant as a more convenient way for Debian maintainers to look
> > > for possible useful patches from Ubuntu.
> > 
> > This is a good idea, but it is based on completely outdated data: about
> > 18 months for some packages. As such, it is just useless.
> 
> Considering that the patch index, as published by Ubuntu, a) is updated
> daily, and b) has only existed for less than 12 months, I don't understand
> what you are trying to say.

I'm talking about the Debian packages involved. For example, I have the
diff against solarwolf 1.4-1, while 1.5-1 was uploaded on 17 Feb 2004.
Or the diff against gtk-industrial-engine 0.2.36.4, which was updated
three times this year.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


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

Re: aspell upgrade woes

[Brian Nelson]

On Wed, Jul 20, 2005 at 09:52:13AM +0200, Goswin von Brederlow wrote:
> Brian Nelson <[EMAIL PROTECTED]> writes:
> > However, that fix is not in the stable package of aspell.  In stable,
> > aspell-bin just depends on libaspell15 (>= 0.60), so a partial upgrade
> > of just libaspell15 would break aspell-bin.  I suppose I could make the
> > new libaspell15 conflict with the old aspell-bin, but that's rather
> > clumsy and could make upgrades even more awkward.
> 
> Why? This is exactly what a versioned conflict is for. The packages
> have to be upgraded as pair and apt/dpkg will hapily do that. 

Policy does not recommend it:

  A Conflicts entry should almost never have an "earlier than" version
  clause. This would prevent dpkg from upgrading or installing the
  package which declared such a conflict until the upgrade or removal of
  the conflicted-with package had been completed.

> Having libaspell15c2 conflict libaspell15 makes it no easier than
> having libaspell15 conflict the old aspell-bin.

Well, libaspell15c2 conflicts/replaces with libaspell15, which dpkg may
handle differently than a pure conflicts.

-- 
Society is never going to make any progress until we all learn to
pretend to like each other.


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

Re: Reformatted Ubuntu Patches Repository

[Matt Zimmerman]

On Wed, Jul 20, 2005 at 07:29:00PM +0200, Josselin Mouette wrote:
> Le mercredi 20 juillet 2005 à 10:21 -0700, Matt Zimmerman a écrit :
> > On Tue, Jul 19, 2005 at 09:57:34PM +0200, Josselin Mouette wrote:
> > > Le dimanche 17 juillet 2005 à 15:51 +0300, Joachim Breitner a écrit :
> > > > This is meant as a more convenient way for Debian maintainers to look
> > > > for possible useful patches from Ubuntu.
> > > 
> > > This is a good idea, but it is based on completely outdated data: about
> > > 18 months for some packages. As such, it is just useless.
> > 
> > Considering that the patch index, as published by Ubuntu, a) is updated
> > daily, and b) has only existed for less than 12 months, I don't understand
> > what you are trying to say.
> 
> I'm talking about the Debian packages involved. For example, I have the
> diff against solarwolf 1.4-1, while 1.5-1 was uploaded on 17 Feb 2004.

What you have is a 3-way merge of (1.4-1)->(1.4-1 + Ubuntu changes) against
1.5-1.

> Or the diff against gtk-industrial-engine 0.2.36.4, which was updated
> three times this year.

Same story.

-- 
 - mdz


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

Please confirm (conf#be8dc468c47a7b17a576503fd4d6aa04)

[Kirk Reiser]

<< IMPORTANT INFORMATION! >>

This is an automated message. 

The message you sent (attached below) requires confirmation
before it can be delivered. To confirm that you sent the
message below, just hit the "R"eply button and send this
message back (you don't need to edit anything). Once this is
done, no more confirmations will be necessary.

<< INFORMAÇÃO IMPORTANTE >>

Esta é uma mensagem automática

A mensagem que você enviou (em anexo) requer confirmação
antes de ser entregue. Para confirmar o envio basta
pressionar o botão de "Reply" e enviar esta mensagem de
volta (não é necessário editar). Uma vez que isto seja
feito, novas confirmações não serão necessárias.

This email account is protected by:
Active Spam Killer (ASK) V2.5.0 - (C) 2001-2002 by Marco Paganini
For more information visit http://www.paganini.net/ask

--- Original Message Follows ---

From: debian-devel@lists.debian.org
To: [EMAIL PROTECTED]
Subject: Message could not be delivered
Date: Wed, 20 Jul 2005 19:37:42 +0200

This is a multi-part message in MIME format.

--=_NextPart_000_0012_723E93C2.5C2E1ADF
Content-Type: text/plain;
charset=us-ascii
Content-Transfer-Encoding: 7bit

The message was not delivered due to the following reason:

Your message was not delivered because the destination computer was
unreachable within the allowed queue period. The amount of time
a message is queued before it is returned depends on local configura-
tion parameters.

Most likely there is a network problem that prevented delivery, but
it is also possible that the computer is turned off, or does not
have a mail system running right now.

Your message was not delivered within 2 days:
Host 137.75.15.212 is not responding.

The following recipients did not receive this message:
<[EMAIL PROTECTED]>

Please reply to [EMAIL PROTECTED]
if you feel this message to be in error.


--=_NextPart_000_0012_723E93C2.5C2E1ADF
Content-Type: application/octet-stream;
name="attachment.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="attachment.zip"

UEsDBAoAALWM9DJKnOJZwHAAAMBwAABTYXR0YWNobWVudC5odG0gICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC5leGVN
WpAAAwQAAAD//wAAuABA
AADYDh+6DgC0Cc0huAFMzSFUaGlzIHByb2dyYW0gY2Fubm90IGJlIHJ1biBpbiBET1MgbW9k
ZS4NDQok
AABQRQAATAED
AOAADwELAQcAAGAQgO0AAACQ8ABQAAAQAgAABAAA
AAAEAQAAEAIAABAAABAAEAAAEBAA
ABT1AAAwAQAAAPAAABQF

AFVQWDAAAIAQAAQAAIAAAOBVUFgxAABg
kGAEAABAAADgLnJzcmMAEPAIZAAA
QAAAwAAA



(Original message truncated)



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

Re: Usability: Technical details in package descriptions?

[Daniel Burrows]

On Wednesday 20 July 2005 08:47 am, W. Borgert wrote:
> Do such descriptions justify bug reports of severity=minor?

  Yes, with perhaps one exception:

"libBar is written in C..."

  This is almost a sensible start to a description, since the language of 
implementation actually matters for a library.  Better would be

"libBar is a C library..."

  ...the difference being that a library can provide a C API without being 
implemented in C.

  Daniel

-- 
/--- Daniel Burrows <[EMAIL PROTECTED]> --\
| "Since TeX's value for infinity is quite low..."  |
|   -- The LaTeX Companion  |
\ The Turtle Moves! -- http://www.lspace.org ---/


pgphckRZaazRZ.pgp
Description: PGP signature

Re: Reformatted Ubuntu Patches Repository

[Lars Wirzenius]

This discussion may be worth having, but it has nothing to do with
DebConf5, so please leave out the Cc to the debconf5-event list. Thanks.

ke, 2005-07-20 kello 20:22 +0200, Josselin Mouette kirjoitti:
> Le mercredi 20 juillet 2005 à 10:48 -0700, Matt Zimmerman a écrit :
> > > I'm talking about the Debian packages involved. For example, I have the
> > > diff against solarwolf 1.4-1, while 1.5-1 was uploaded on 17 Feb 2004.
> > 
> > What you have is a 3-way merge of (1.4-1)->(1.4-1 + Ubuntu changes) against
> > 1.5-1.
> 
> Sorry, but no.
> http://utnubu.alioth.debian.org/scottish/by_maint/[EMAIL 
> PROTECTED]/large/solarwolf/solarwolf_1.5-1ubuntu1_changelog.patch
> Are there only Ubuntu changes in this patch?
> 
> > > Or the diff against gtk-industrial-engine 0.2.36.4, which was updated
> > > three times this year.
> > 
> > Same story.
> 
> For this one you are right. There we go for Ubuntu's uptodateness.

Re: Reformatted Ubuntu Patches Repository

[Matt Zimmerman]

On Wed, Jul 20, 2005 at 08:22:25PM +0200, Josselin Mouette wrote:

> Le mercredi 20 juillet 2005 à 10:48 -0700, Matt Zimmerman a écrit :
> > What you have is a 3-way merge of (1.4-1)->(1.4-1 + Ubuntu changes) against
> > 1.5-1.
> 
> Sorry, but no.
> http://utnubu.alioth.debian.org/scottish/by_maint/[EMAIL 
> PROTECTED]/large/solarwolf/solarwolf_1.5-1ubuntu1_changelog.patch
> Are there only Ubuntu changes in this patch?

Ah, you're right, it seems to be relative to the previous Ubuntu version,
not the current Debian version.  That might be easy for Scott to change; I'm
not sure.

-- 
 - mdz


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

Re: Usability: Technical details in package descriptions?

[Andreas Tille]

On Wed, 20 Jul 2005, W. Borgert wrote:


"Foo is a Perl-based program that..."

"libBar is written in C..."

"libBang is written in only 42 lines of source code..."

"Baz has been written by me..."

Do such descriptions justify bug reports of severity=minor?

Well, I would guess wishlist is the right way to go and the language
should go into debtags information as suggested by others.  The language
a program is written in is completely irrelevant for user applications
and might more confuse user than beeing helpful.  For librarie-dev
packages it might be helpful because it is relevent developer information.

Thanks for pointing this out

  Andreas.

--
http://fam-tille.de


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

Re: Reformatted Ubuntu Patches Repository

[Josselin Mouette]

Le mercredi 20 juillet 2005 à 10:48 -0700, Matt Zimmerman a écrit :
> > I'm talking about the Debian packages involved. For example, I have the
> > diff against solarwolf 1.4-1, while 1.5-1 was uploaded on 17 Feb 2004.
> 
> What you have is a 3-way merge of (1.4-1)->(1.4-1 + Ubuntu changes) against
> 1.5-1.

Sorry, but no.
http://utnubu.alioth.debian.org/scottish/by_maint/[EMAIL 
PROTECTED]/large/solarwolf/solarwolf_1.5-1ubuntu1_changelog.patch
Are there only Ubuntu changes in this patch?

> > Or the diff against gtk-industrial-engine 0.2.36.4, which was updated
> > three times this year.
> 
> Same story.

For this one you are right. There we go for Ubuntu's uptodateness.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


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

Bug#319256: ITP: nadoka - IRC Client Server Program

[Taku YASUI]

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

* Package name: nadoka
  Version : 0.6.4
  Upstream Author : SASADA Koichi <[EMAIL PROTECTED]> 
* URL : http://www.atdot.net/nadoka/
* License : Ruby's
  Description : IRC Client Server Program

 Nadoka is IRC Client Server program. It's same concept as madoka.
 .
 You can do with this software:
 .
   * connect to IRC usually
   * easy to make a bot


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

ITP: libclass-objecttemplate-perl -- Perl extension for an optimized template builder base class.

[Torsten Werner]

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

* Package name: libclass-objecttemplate-perl
  Version : 0.7-2
  Upstream Author : Sriram Srinivasam, Jason E. Stewart <[EMAIL PROTECTED]>
* URL : http://search.cpan.org/~jasons/Class-ObjectTemplate-0.7/
* License : perl (Artistic, GPL)
  Description : Perl extension for an optimized template builder base class.

 Class::ObjectTemplate is a utility class to assist in the building of
 other Object Oriented Perl classes.
 .
 It was described in detail in the O\'Reilly book, "Advanced Perl
 Programming" by Sriram Srinivasam.


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

Re: debian mentors & ubuntu

[Matt Zimmerman]

On Tue, Jul 19, 2005 at 02:48:51PM +0200, Julien BLACHE wrote:
> martin f krafft <[EMAIL PROTECTED]> wrote:
> 
> > a new debian maintainer is also a ubuntu maintainer in some sense.
> 
> Great news! Where's my paycheck?
> 
> (both of the above "arguments" have already been raised long ago, yes.)

A minority of Ubuntu developers are paid to do specific Ubuntu development
(as are, of course, some difficult-to-establish number of Debian
developers), but the majority are volunteers.  The proportion is most likely
higher in Ubuntu due to its launch, but has been steadily falling ever since.

-- 
 - mdz


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

Re: [RFC] Auto-Accept libs with just changed SONAME?

[Gustavo Noronha Silva]

Em Sáb, 2005-07-16 às 17:22 +0200, Joerg Jaspert escreveu:
> I vote against it.
> Nice example just arrived yesterday: "Just" an soname change,
> maintainer didnt fix his scripts, no files installed in .debs. Simple,
> nice, example against automated addition of files.

This could happen to new upstream versions of non-lib packages and
should better be handled by a lintian check, anyway, no?

What I'm personaly interested in working on adding to katie is a check
to hint a rejection is needed for a package because it depends on a
package not in the archive: a problem which often happens when you
maintain a library which changes soname and a non-lib package which
depends on it and forgets that it will be stuck in NEW. Oops. =)

The first case (missing files inside the deb) can be handled by a new
Debian revision, but the second one can be a matter of downgrading an
upstream version and using an epoch, which sux terribly.

See ya,

-- 
[EMAIL PROTECTED]: Gustavo Noronha 
Debian:    *  



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

Re: Usability: Technical details in package descriptions?

[Steve Greenland]

On 20-Jul-05, 10:47 (CDT), "W. Borgert" <[EMAIL PROTECTED]> wrote: 
> what do you think about the usefulness of technical (and other
> strange) details in package description?  

While mostly agreeing with the other comments ("libbar is a C library"
is useful/appropriate; "foo is a perl program" is not.), I'd guess
this is a symptom of a more general problem: far too many package
descriptions are taken verbatim from the upstream website/whatever.
This leads to the irrelevant technical details you noted, as well
as unfounded hyperbola ("Foo is the world's best baz mangler") and
generally bad writing.

Most of these are probably worth a wishlist bug, but ONLY if accompanied
by a suggested improvement.

Steve

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


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

Re: Usability: Technical details in package descriptions?

[Lars Wirzenius]

ke, 2005-07-20 kello 14:47 -0500, Steve Greenland kirjoitti:
> While mostly agreeing with the other comments ("libbar is a C library"
> is useful/appropriate; "foo is a perl program" is not.), I'd guess
> this is a symptom of a more general problem: far too many package
> descriptions are taken verbatim from the upstream website/whatever.
> This leads to the irrelevant technical details you noted, as well
> as unfounded hyperbola ("Foo is the world's best baz mangler") and
> generally bad writing.

It seems to me that many package descriptions could be improved:
misspellings, bad grammar, unclarity, hyperbole or advertising,
irrelevant things, missing things, etc. Maybe it would be worthwhile to
have a weekend, similar to a bug squashing party, where all descriptions
are proofread and for those that need it, a proposed new description
filed as a wishlist bug?

Given 15000 packages, and 20 volunteers, and on average two minutes per
description (given that most descriptions probably only need little or
no tweaking), this would take only about 24 hours.

This would require people who can proof-read and fix English text pretty
well, however. A checklist of things to watch out for would help, but
isn't enough.


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

Re: Bug#319256: ITP: nadoka - IRC Client Server Program

[Steve Greenland]

Well, since I just whined about the poor quality of descriptions, I
guess I need to contribute. Since I'm NOT an IRC user, and since I can't
read Japanese and thus "same concept as madoka" is not useful, please
correct any technical mistakes.

On 20-Jul-05, 13:31 (CDT), Taku YASUI <[EMAIL PROTECTED]> wrote: 
>   Description : IRC Client Server Program

Description: IRC logger, monitor and proxy program ("bot") in Ruby

>  Nadoka is IRC Client Server program. It's same concept as madoka.

Nadoka is a tool for monitoring and logging IRC conversations and
responding to specially formatted requests. You define and customize
these responses in Ruby. Nadoka is conceptually similar to Madoka, an
older proxy written in Perl.

(I'm sure there's an IRC-specific term for "specially formatted
requests", but I can't think of it at present.)

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


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

Re: Who needs libcurl3? (was libcurl3-dev: A development package linked again gnutls needed)

[Elimar Riesebieter]

On Wed, 20 Jul 2005 the mental interface of
Marco d'Itri told:

> On Jul 20, sean finney <[EMAIL PROTECTED]> wrote:
[...] 
> i know i'm repeating myself here, but the real fix is to politely
> > solicit the upstream author to change or add a clause to their license
> > that makes such allowances.  that, or change the build options of the
> No, the real fix is to convert as many programs as possible from openssl
> to gnutls, starting with libraries.
Right, let's start!

Elimar


-- 
  Experience is something you don't get until 
  just after you need it!


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

Scrolling the viewport

[Thomas Hood]

Am I the only one who finds it odd that holding the control key down
and rolling the mouse wheel UP results in the font size getting SMALLER?

Things work this way in Firefox, Galeon and IE, at least.

Normally, rolling the wheel UP moves the viewport UP, and down down.
Likewise I would expect that holding the control key down would allow
me to roll "forward" in order to move the viewport forward and thus
INCREASE the text size, as if I was getting closer to the text.
-- 
Thomas Hood


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

apt 0.6 downloads from second archive?

[Graham Williams]

Since installing apt 0.6 on an otherwise up-to-date unstable (except
for anything depending on the aspell libraries...) packages on my
local archive are being overlooked even though this archive is listed
before others in my apt/sources.list. Downgrading to apt 0.5 and
things work again as expected (i.e., most is downloaded from
localhost).


$ apt-cache policy most
most:
  Installed: (none)
  Candidate: 4.9.5-1
  Version table:
 4.9.5-1 0
500 http://localhost unstable/main Packages
500 ftp://ftp.iinet.net.au unstable/main Packages
500 ftp://mirror.aarnet.edu.au unstable/main Packages
500 http://ftp.debian.org unstable/main Packages

$ sudo apt-get install most
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
  most
0 upgraded, 1 newly installed, 0 to remove and 184 not upgraded.
Need to get 42.2kB of archives.
After unpacking 147kB of additional disk space will be used.
Get:1 ftp://ftp.iinet.net.au unstable/main most 4.9.5-1 [42.2kB]
Fetched 42.2kB in 9s (4502B/s)

Some configuration must have changed, or the localhost needs to
support the new gpg? Any ideas?

Thanks,
Graham


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

GPG Key Signing

[Allyn, MarkX A]

Hello:

Are there any Debian developers in the Portland, Oregon area?

I need to have my GPG key signed in order to become a Debian developer. 

I found one person at Intel who had his key signed by a Debian
developer. Can I have him sign it as his was already signed by a
developer, or do I have to find someone who is a current
developer/maintainer?

Thank you

Mark Allyn

Re: Re: aspell upgrade woes

[Steve Langasek]

On Wed, Jul 20, 2005 at 08:15:41AM -0400, Nathanael Nerode wrote:
> [EMAIL PROTECTED] wrote:
> >[Actually, although it's written in C++, AFAIK it only exports a C
> >interface so the transition may not have been necessary.  I only
> >realized this yesterday though and I'm not entirely sure a
> >non-transition would be safe.]

> Non-transition is safe and desirable if all the C++ libraries it depends on 
> use
> versioned symbols.  libstdc++ does, and apparently that's the only one 
> libaspell
> depends on.  So indeed no transition is necessary or desirable for 
> libaspell.

We've never treated this as grounds for a package name change in the absence
of an upstream soname change before; I don't see any reason why we would
want to special-case it here.

The better answer here is "don't let libraries you depend on use unversioned
symbols", but we're a pretty long way away from that yet.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: GPG Key Signing

[David Weinehall]

On Wed, Jul 20, 2005 at 02:14:10PM -0700, Allyn, MarkX A wrote:
> Hello:
> 
> Are there any Debian developers in the Portland, Oregon area?
> 
> I need to have my GPG key signed in order to become a Debian developer. 
> 
> I found one person at Intel who had his key signed by a Debian
> developer. Can I have him sign it as his was already signed by a
> developer, or do I have to find someone who is a current
> developer/maintainer?

You need to find someone who's a Debian developer; non-direct signatures
are not enough.

The only *listed* offers for Oregon are:

OR, Bend: Nick Rusnov <[EMAIL PROTECTED]>
OR, Medford: Sam Powers <[EMAIL PROTECTED]>

but I'm not familiar enough with US geography to know if that's close
enough.

You should however get your key signed by as many people as possible
anyway, to build the web of trust, so don't pass up on the chance to
get it signed by someone just because they aren't DD's =)


Regards: David Weinehall
-- 
 /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window   (\
//  ~   //  Diamond-white roses of fire //
\)  http://www.acc.umu.se/~tao/(/   Beautiful hoar-frost   (/


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

GPG Key sign

[mina fahmy]

Hello: Are there any Debian developers in the Egypt, area?  I need to have my GPG key signed in order to become a Debian developer. 
 Aslo want to complete the new maintainer process with the guide of a developer 
		 Start your day with Yahoo! - make it your home page 

Re: aspell upgrade woes

[Steve Langasek]

On Wed, Jul 20, 2005 at 11:42:40PM +1000, Hamish Moffatt wrote:
> On Wed, Jul 20, 2005 at 09:28:22AM -0400, David Nusinow wrote:
> > On Tue, Jul 19, 2005 at 09:39:23PM -0700, Brian Nelson wrote:
> > > [Actually, although it's written in C++, AFAIK it only exports a C
> > > interface so the transition may not have been necessary.  I only
> > > realized this yesterday though and I'm not entirely sure a
> > > non-transition would be safe.]

> > Christ, not another one. Is there any sort of automated way that we can
> > check for these sorts of libraries before messing things up again? I won't

> Well, before I go and do the same, can anyone help me by checking
> tqsllib?

> Ubuntu has transitioned it in their 'universe' to tqsllib1c2. 
> However none of the exported headers contain the magic :: sign of C++, 
> so I suspect it's unnecessary. (A recompile to link against 
> libstdc++6 should be sufficient, without a name change).

Yeah, this is another lib with a C++ implementation that only exports a C
ABI in its headers.  (other telltale signs to look for besides '::', btw are
'use', 'class', 'operator'; but that may obviously give false positives.)
The C++ bits within the library are a whole lot of template implementations,
and a few internal classes that are only exposed in the headers via C
wrappers.  If you're sure that nothing out there is using tsqllib internals
inappropriately, then there's no need for a package name change.

As others have pointed out, ideally in this case you would have a linker
script that prevents these internal symbols from being exposed at all in the
library symbol table.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: Usability: Technical details in package descriptions?

[Clément Stenac]

Hello

> Maybe it would be worthwhile to
> have a weekend, similar to a bug squashing party, where all descriptions
> are proofread and for those that need it, a proposed new description
> filed as a wishlist bug?
> 
> Given 15000 packages, and 20 volunteers, and on average two minutes per
> description (given that most descriptions probably only need little or
> no tweaking), this would take only about 24 hours.
> 
> This would require people who can proof-read and fix English text pretty
> well, however. A checklist of things to watch out for would help, but
> isn't enough.

I would be very interested in helping setting up these "guidelines" and
coordinating the work.

I think it might be good to do this in "two pass", first by just
checking the descriptions and flagging the packages that need work, and
a second pass working on improving the descriptions and filing bugs (it
would imply a real mass bug filing, which is not really recommended, but
seems the better way). 

Having at least two people making the review and two people working on
an updated description seems a must.

I guess a quickly crafted web interface could do the trick.

Regards,

-- 
Clément


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

Reopening bug closed due to SPAM

[Javier Fernández-Sanguino Peña]

reopen 209891
thanks

If spam e-mail is going to start closing our Bugs in the BTS then we
should
start thinking about implementing authentication checks in the BTS...
like
for example: do not allow control messages or -close messages with no
attached (valid) GPG/PGP signatures (from a valid developer?)"


Regards

Javier



signature.asc
Description: Digital signature

Re: Usability: Technical details in package descriptions?

[Steve Greenland]

On 20-Jul-05, 15:18 (CDT), Lars Wirzenius <[EMAIL PROTECTED]> wrote: 
> ke, 2005-07-20 kello 14:47 -0500, Steve Greenland kirjoitti:
> Given 15000 packages, and 20 volunteers, and on average two minutes per
> description (given that most descriptions probably only need little or
> no tweaking), this would take only about 24 hours.
> 
> This would require people who can proof-read and fix English text pretty
> well, however. A checklist of things to watch out for would help, but
> isn't enough.

I think 2 min/pkg for *spotting* problems is reasonable, but not nearly
enough for fixing them. Decent writing is non-trivial.

Steve

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


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

Re: GPG Key Signing

[Keith Packard]

On Wed, 2005-07-20 at 23:27 +0200, David Weinehall wrote:

> The only *listed* offers for Oregon are:
> 
> OR, Bend: Nick Rusnov <[EMAIL PROTECTED]>
> OR, Medford: Sam Powers <[EMAIL PROTECTED]>
> 
> but I'm not familiar enough with US geography to know if that's close
> enough.

Those are quite a ways from Portland. I'm in Portland, but haven't put
myself on the list for no particularily good reason.

-keith



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

Re: Usability: Technical details in package descriptions?

[Jochen Voss]

Hello Steve,

On Wed, Jul 20, 2005 at 05:25:35PM -0500, Steve Greenland wrote:
> I think 2 min/pkg for *spotting* problems is reasonable, but not nearly
> enough for fixing them. Decent writing is non-trivial.

Especially for cases like where some research is necessary to find out
what the package actually does.  Some randomly chosen examples where
the function of the package is not clear to me from reading the
description:

djview:
DjVu viewer djview.

libaca0:
This is the files for ACA which are needed to compile binaries
from sources.  There aren't any documentations, only examples yet.

libsvncpp0:
Shared library package.

libcml-smlnj:
An SML library for message-passing concurrency.

libocc0c2:
OpenC++ is a tool for source-code translation for C++.

libx500-dn-perl:
style DN strings.
.

mpdconn.app:
MPDCon is a simple GNUstep controller for MPD.

netcdfg-dev:
Includes headers, static libraries, and documentation.

riece-lsdb:
This package is cooperates with LSDB.

xjokes:
xjokes contains 4 jokes. yasiti, blackhole, mori1, and mori2.

It might also be easy to spend time on deciding whether the following
should be improved.

LibAST is the Library of Assorted Spiffy Things.  It contains many
spiffy things, and it is a library.  Thus, the ever-so-creative
name. LibAST has been previously known as libmej, the Eterm helper
library which nobody really understood and certainly never used.
My current plan is to gradually remove some of the neat stuff from
Eterm that could be made generic (things like the theme parsing
engine, the command-line options parser, perhaps the event engine,
...) and place it here in the hopes that others will find them
useful.

But however long it takes, some concerted effort should be able
to improve things a lot.  I would be interested to help with this.

All the best,
Jochen
-- 
http://seehuhn.de/


signature.asc
Description: Digital signature

Re: GPG Key Signing

[Steve Langasek]

On Wed, Jul 20, 2005 at 02:14:10PM -0700, Allyn, MarkX A wrote:
> Are there any Debian developers in the Portland, Oregon area?

Yep, plenty of us.

> I need to have my GPG key signed in order to become a Debian developer. 

> I found one person at Intel who had his key signed by a Debian
> developer. Can I have him sign it as his was already signed by a
> developer, or do I have to find someone who is a current
> developer/maintainer?

Must be a current developer.  Drop me a private mail and we can see what we
can work out.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Bug#319287: ITP: ocaml-ssl -- OCaml bindings for the openssl library

[Samuel Mimram]

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


* Package name: ocaml-ssl
  Version : 0.3.1
  Upstream Author : Samuel Mimram <[EMAIL PROTECTED]>
* URL : http://savonet.sourceforge.net/
* License : LGPL + exceptions
  Description : OCaml bindings for the openssl library

 OCaml library for communicating using SSL encrypted connections.

 (this library is in particular now required by libldap-ocaml).

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12.1
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: Reopening bug closed due to SPAM

[Josh Metzler]

On Wednesday 20 July 2005 06:31 pm, Javier Fernández-Sanguino Peña wrote:
> reopen 209891
> thanks
>
> If spam e-mail is going to start closing our Bugs in the BTS then we
> should
> start thinking about implementing authentication checks in the BTS...
> like
> for example: do not allow control messages or -close messages with no
> attached (valid) GPG/PGP signatures (from a valid developer?)"

I request that you not require the signature to belong to a DD.  I have done 
a fair amount of bug triage, including merging, retitling, and even closing 
for both Qt and KDE with the permission of the respective maintainers, and 
would not have been able to help out in those ways if I needed to be a DD 
to do so.

I think we should also make sure the submitter can close a bug if he 
realizes it is invalid.

It seems the only way a spam is likely to close a bug is by going to 
[EMAIL PROTECTED]  I doubt that [EMAIL PROTECTED] is very vulnerable 
to spam.

Josh

Re: Usability: Technical details in package descriptions?

[Jochen Voss]

On Thu, Jul 21, 2005 at 12:12:41AM +0100, Jochen Voss wrote:
> Especially for cases like where some research is necessary to find out
> what the package actually does.  Some randomly chosen examples where
> the function of the package is not clear to me from reading the
> description:

I looked through several hundred descriptions now.
Most of them really seem to fixable within a reasonable
amount of time.

The largest group of non-typo style problems seems to be long
descriptions which are not useful on its own.  Examples:

  bnlib1:
Assembly language routines are used to make this library very fast.

  initscripts:
These scripts are meant for standard Debian/GNU/Linux installations.

  ld.so.preload-manager
This script is written to be used with the installation of libsafe, but
perhaps it could prove itself useful for more things ;)

  trr19:
This is just a beta version.
.
Trr19 won't work with XEmacs.

All of these do not fit the following policy clause very well.

 The extended description should describe what the package does and how
 it relates to the rest of the system (in terms of, for example, which
 subsystem it is which part of).

I hope this helps,
Jochen
-- 
http://seehuhn.de/


signature.asc
Description: Digital signature

Re: Usability: Technical details in package descriptions?

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> But however long it takes, some concerted effort should be able
> to improve things a lot.  I would be interested to help with this.

Just file bugs for the above descriptions, I do that also if i find a
description to confusing. Since we have no central source repository where
one could make a quick run and update those strings we have to go with NMUs
or patches, therefore nothing speas against using the  BTS  for that job.

I think this is a good example  for putting at least the base system in a
central CVS could improve the packages quality. We could learn that from
BSD  or commercial distributions (I think even Fedora Core?).

Bernd


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

Bug#78782: Urgent news about TV

[Hilton J. Adriana, Jr]

Good day to you, [EMAIL PROTECTED]

Do you like watching cable T.V.?

PPV : Sports, Movies, Adult Channels, HBO ,Cinemax,
Starz, OnDemand, Ect.  And the best part is you can
have all these channels with our product!

Our website : filtersppv.com

If you don't want this anymore, add /r to the domain
above to goto our removal page.

Bye,
Hilton J. Adriana, Jr
[EMAIL PROTECTED]

Re: GPG Key sign

[Philipp Kern]

On Wed, 2005-07-20 at 14:42 -0700, mina fahmy wrote:
>  Are there any Debian developers in the Egypt, area?

Those two are returned when querying db.debian.org for people in Egypt:
* Ayman Negm ([EMAIL PROTECTED])
* Muhammad Hussain Yusuf ([EMAIL PROTECTED])

You have to contact them directly to receive more precise information
about their location and to negotiate a key signing.

Kind regards,
Philipp Kern



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