Re: Explicitely Cc bug reporters

[Stefano Zacchiroli]

On Thu, Sep 10, 2009 at 01:47:22PM -0700, Don Armstrong wrote:
> 1: Not to mention the multiple messages erroneously describing my
> position on the matter without allowing time for a response, or
> bothering to read the logs of the relevant bugs.

While I hope I'm not in that author set :-), let me take the chance to
thank you for the often thankless work on debbugs. I'm sure all of us
are very grateful of what you do and have always welcomed the frequent
improvements you, together with the other debbugs contributors,
frequently deliver.

Still, I often fall in the trap of believing that most geeks has strong
opinion and I confess that, mainly due to "folklore" I guess, I
effectively thought your judgement was against Cc-ing (or equivalent) by
default. One of the post of yours in this thread [1] was terribly clear
and enlightening in that respect, and dissipated my wrong assumptions.

Many thanks and keep up the good work.
Cheers.

[1] http://lists.debian.org/debian-devel/2009/09/msg00458.html

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: Explicitely Cc bug reporters

[Paul Wise]

On Thu, Sep 10, 2009 at 9:45 PM, Samuel Thibault  wrote:

> I'd like to remind maintainers that in order to reach bug reporters to
> ask for tests etc. you _need_ to explicitely Cc the bug reporter, else
> he won't receive the mail and of course not do the tests etc.  It's now
> quite a few times that I have received a "you didn't answer" mail...

I personally prefer not to be CCed on bug reports. I don't want to
recieve any mail about a bug unless it is asking me to supply more
information or if the bug is being closed due to a fix or because the
software was removed from Debian. I sometimes get people CCing me even
when there is no need to (#545785 most recently).

Given the massive thread this post generated, with a variety of
opinions, I would propose:

A subscribe pseudo-header for submit@ mails that has values 'yes' and 'no'.

A way for people to set the default value of the subscribe
pseudo-header for new bugs.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Explicitely Cc bug reporters

[Bernhard R. Link]

* Don Armstrong  [090910 22:47]:
> On Thu, 10 Sep 2009, Sandro Tosi wrote:
> > Given the high rate of people (at least in those that replied here)
> > in favor of adding submitter in the loop of n...@b.d.o, I think your
> > plan is very good:
> >
> > - include the submitter in n...@b.d.o by default now;
>
> Considering the fact that this thread has only been here for a few
> hours,[1] I'm going to hold off at least for a few days to entertain
> objections. But hearing none, I'll implement this when I get a chance.

If you change that, please add a new -followup@ with the old
behaviour. And I think it would be wisest to change the mail the user
gets to no longer point to -followup@ instead of @ [1].

As the supplier of additional information has usually no idea whether the
original bug submitter wants to be informed about some hints about some
secondary effects/influences, it would still be very nice to have an
possibility to subscribe to a bug to get the -followup mails.

Hochachtungsvoll,
Bernhard R. Link

[1] I think that is the biggest argument against this change: The
current behaviour is user centered and the new one will be
developer-centered, so most likely be confusing to the user.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Explicitely Cc bug reporters

[Frans Pop]

Paul Wise wrote:
> I personally prefer not to be CCed on bug reports. I don't want to
> recieve any mail about a bug unless it is asking me to supply more
> information.

So you *do* want to be CCed if the maintainer needs more information.

Then there's one thing I don't get.
- if we change the default to "always CC", nobody is going to explicitly
  CC submitters anymore; that's only logical, correct?
- you choose not to subscribe
- ergo, you will never see any requests for additional information

How would you solve that problem within your proposal?


As I've mentioned before, IMO there is only one valid reason to 
unsubscribe from BRs after we change the default, and that is if you 
*already* receive follow-ups because
- the package has Maintainer set to a mailing list and you are subscribed
  to that list
- you are subscribed to bug mails for the package through the PTS

I'm sorry that you consider receiving follow-ups an inconvenience, but IMO 
the benefit of in general being sure submitters will get follow-ups 
outweighs that.

It will also solve the problem that I've seen numerous times that CCs from 
me directly get rejected by submitters through overly aggressive spam 
filtering. (And yes, I do send out mails through my ISP.)

Cheers,
FJP


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: #545996: please inform submitters they need to subs cribe

[Michael Banck]

On Thu, Sep 10, 2009 at 08:13:12PM +0200, Holger Levsen wrote:
> package: bugs.debian.org
> severity: wishlist
> x-debbugs-cc: debian-devel@lists.debian.org
> 
> Hi,
> 
> On Donnerstag, 10. September 2009, Bernhard R. Link wrote:
> > But reporters are sacrifing some of their time to help us make our
> > distribution better. Do you really think we should scare them away
> > by rewarding bug reports by pulling the reporters in lengthy
> > discussions how the bug is best fixed?
> 
> I think I agree with this rhetorical question.

I don't - if we think the mail coorespondance of a bug report is not
something a user would like to receive, we're doing it wrong.

Either are the mails too technically and complicated. That is a fair
point, but I do not think it scares users away - if at all, it assures
them that their bug is in good hands (but if they want, unsubsribing
from it [except for the "bug closed" mail] should be easy, like
mentioned in the mail footer)

Or we think our own blame-assignments and bickering and argueing will
scare users away.  That is maybe the real reason we do not want to have
users be subscribed?  In that case, I think we should rather address
this point on our side and make our bug reports mail exchanges better to
read for everybody.


Michael


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Explicitely Cc bug reporters

[Christoph Egger]

Frans Pop schrieb:
> Paul Wise wrote:
>> I personally prefer not to be CCed on bug reports. I don't want to
>> recieve any mail about a bug unless it is asking me to supply more
>> information.
> 
> So you *do* want to be CCed if the maintainer needs more information.
> 
> Then there's one thing I don't get.
> - if we change the default to "always CC", nobody is going to explicitly
>   CC submitters anymore; that's only logical, correct?
> - you choose not to subscribe
> - ergo, you will never see any requests for additional information
> 
> How would you solve that problem within your proposal?

I'm seeing exactly this problem with the proposal. IMHO we really need
a way to definitely get the submitter and we need to use that whenever
we need a answer. subscribing the submitter to ???...@bugs.d.o by
default and giving the option to unsubscribe will just increase the
number of Maintainers not thinking of CC the submitter.

I don't care if we have -submitter to reach the submitter or
-nosubmitter or whatever to keep him of the loop but a way to maybe
reach the submitter and depending on that is really worse than what we
have now.

Regards

Christoph

-- 
/"\  ASCII Ribbon : GPG-Key ID: 0x0372275D
\ /Campaign   : GPG 4096R : 0xD49AE731
 X   against HTML : Debian NM
/ \   in eMails   : http://www.debian.org/

http://www.christoph-egger.org/



signature.asc
Description: OpenPGP digital signature

Bug#546166: ITP: rabbit -- presentation tool using RD, a simple text format

[Youhei SASAKI]

Package: wnpp
Owner: Youhei SASAKI 
Severity: wishlist

* Package name: rabbit
  Version : 0.6.1
  Upstream Author : Kouhei Sutou 
* URL or Web page : http://www.cozmixng.org/~rwiki/?cmd=view;name=Rabbit
* License : GPL
  Description : presentation tool using RD, a simple text format




-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Explicitely Cc bug reporters

[Jon Dowland]

On Thu, Sep 10, 2009 at 09:35:02PM +0200, Frans Pop wrote:
> I don't think it should be too easy to opt-out. We should
> not get in a situation where we no longer CC a submitter
> because we assume he/she is subscribed, while the
> submitter will never get the mails because he did not
> realize that would be the consequence of opting out when
> he submitted the bug.

The wording needs to be clear, then, but opting out should
always be easy, or we will increase user frustration and
risk the BTS being considered unsound in mail reputation
services.


-- 
Jon Dowland


signature.asc
Description: Digital signature

Re: Explicitely Cc bug reporters

[Jon Dowland]

On Fri, Sep 11, 2009 at 09:40:21AM +0200, Bernhard R. Link wrote:
> [1] I think that is the biggest argument against this change: The
> current behaviour is user centered and the new one will be
> developer-centered, so most likely be confusing to the user.

I don't agree with the positioning here. As a *user*, the
current behaviour is less than optimal to me, and I welcome
a change to the default.


-- 
Jon Dowland


signature.asc
Description: Digital signature

Re: Explicitely Cc bug reporters

[Jon Dowland]

On Fri, Sep 11, 2009 at 10:21:07AM +0200, Frans Pop wrote:
> As I've mentioned before, IMO there is only one valid
> reason to unsubscribe from BRs after we change the
> default, and that is if you *already* receive follow-ups
> because
snip

There's also the case where you submitted a bug in a package
or with hardware that you no longer use or have access to,
so can no longer test fixes. Perhaps others have "me too"'d
the bug, so it shouldn't just be closed (although I'd argue
that submitter dropping off a bug is not reason alone to
close it)

-- 
Jon Dowland


signature.asc
Description: Digital signature

Bug#546183: ITP: libsx -- Simple X library

[Alastair McKinstry]

Package: wnpp
Severity: wishlist
Owner: Alastair McKinstry 

* Package name: libsx
  Version : 2.05
  Upstream Author : Jean-Pierre Demailly 
* URL : ftp://ftp.ac-grenoble.fr/ge/Xlibraries/
* License :  GPL
  Programming Lang: C
  Description : Simple X library

 Libsx (the Simple X library) is a library of code that sits on top of and
 to the side of the Athena widget set.  Its purpose is to make writing X
 applications *much* easier.

 libsx is a dependency  of grads (ITP  540545) and present in Fedora / Redhat
-- System Information:
Debian Release: 5.0.2
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: powerpc (ppc)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Faster boot by running init.d scripts in parallel

[Wouter Verhelst]

On Thu, Sep 10, 2009 at 01:05:32PM +0200, Petter Reinholdtsen wrote:
> If you want to test this feature in testing or unstable, use this
> command:
> 
>   echo CONCURRENCY=makefile >> /etc/default/rcS
> 
> It will enable makefile style concurrency, and run N scripts in
> parallel during boot, where N is the number of CPUs or cores on the
> machine.

That seems suboptimal.

It occurs to me that initscripts are mostly I/O bound (since they need
to start applications that then go waiting in the background), rather
than CPU bound; as such, the number of initscripts that can be ran in
parallel is more dependent on I/O speed than on CPU speed.

It's probably best to make this N be a configurable variable (possibly
defaulting to something based on something we detect from the system
we're running on) rather than have it be something detected and not
configurable.

If it actually is configurable, but you just didn't tell us so, then
please feel free to disregard this mail ;-)

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html


signature.asc
Description: Digital signature

Re: Explicitely Cc bug reporters

[Wouter Verhelst]

On Thu, Sep 10, 2009 at 02:15:43PM -0500, John Goerzen wrote:
> I don't find the existing behavior confusing, especially since there
> is -submitter@

The problem with the -submitter@ mail alias is that it does not get
changed in the forward, so that when a submitter hits 'reply' in his
MUA, he will get his own response, but the person asking for follow-up
information in the first place doesn't get to see that data.

I understand why header mangling is a bad thing in general, and am not
suggesting that this be implemented; but as bug submitters are generally
people who are less knowledgeable about the BTS than are package
maintainers, it usually is easier to just Cc the submitter on a question
than it is to use -submitter (and deal with misdirected replies
afterward).

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Faster boot by running init.d scripts in parallel

[Olivier Bonvalet]

But combined with "readahead", there is no I/O bound during init.
Most of needed files are preload.

Wouter Verhelst a écrit :

On Thu, Sep 10, 2009 at 01:05:32PM +0200, Petter Reinholdtsen wrote:
  

If you want to test this feature in testing or unstable, use this
command:

  echo CONCURRENCY=makefile >> /etc/default/rcS

It will enable makefile style concurrency, and run N scripts in
parallel during boot, where N is the number of CPUs or cores on the
machine.



That seems suboptimal.

It occurs to me that initscripts are mostly I/O bound (since they need
to start applications that then go waiting in the background), rather
than CPU bound; as such, the number of initscripts that can be ran in
parallel is more dependent on I/O speed than on CPU speed.

It's probably best to make this N be a configurable variable (possibly
defaulting to something based on something we detect from the system
we're running on) rather than have it be something detected and not
configurable.

If it actually is configurable, but you just didn't tell us so, then
please feel free to disregard this mail ;-)

  



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Faster boot by running init.d scripts in parallel

[Petter Reinholdtsen]

[Wouter Verhelst]
> That seems suboptimal.

Could be.  See the startpar program to see how the scripts are run in
parallel.  Note that the boot is mostly CPU bound when readahead is
used, which you should use if you care about boot speed. :)

> If it actually is configurable, but you just didn't tell us so, then
> please feel free to disregard this mail ;-)

The startpar program can take arguments to adjust this, but we do not
provide support for this in sysv-rc.  Not sure if we want to do so or
not.

Happy hacking,
-- 
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Explicitely Cc bug reporters

[Julien Cristau]

On Thu, 2009-09-10 at 18:25 +0200, Bernhard R. Link wrote:
> That is the thread at large. Currently it was about why nnn-quiet is no
> suitable workaround if the followup address for users (nnn@) would suddenly
> also mail users.

Speaking of -quiet, I'd be happy to see that die.  Or at the very least,
-submitter needs to stop setting reply-to to -quiet.

Cheers,
Julien


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Explicitely Cc bug reporters

[Julien Cristau]

On Thu, 2009-09-10 at 17:23 +0200, Stefano Zacchiroli wrote:
> Conceptually, what "we" want is trivial: we want submitter to be
> subscribed (in the sense of "bts subscribe") by default. If they want,
> they are free to opt unsubscribing.

If the submitter can unsubscribe, then we haven't won anything, since
we'll still need to remember to cc them manually to request feedback
(and we won't have any way to know whether n...@b.d.o reaches them...)

Cheers,
Julien


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: #545996: please inform submitters they need to subs cribe

[Johannes Wiedersich]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Frans Pop wrote:
> Holger Levsen wrote:
>> But I also think the acknowledgement mail should contain the information
>> that the submitter is not being subscribed by default and how s/he can
>> subscribe.
> 
> IMHO this is very wrong: the user has already taken the trouble to report 
> the bug. We should not make him/her jump through extra hoops just so he 
> can participate in the resolution of the bug. And he should also not run 
> the risk of missing requests for additional information from the package 
> maintainer if he fails to subscribe.

[...]

> I'm very much in favor of having submitters receive mails by default, at 
> least for follow-ups, but IMO also for status changes.
> 
> Only too often have I missed the fact that a maintainer silently changed 
> the priority of a bug I thought was RC. That should not happen. The 
> submitter should be informed so he can argue against the change if he 
> feels it's wrong.

I fully agree. IMHO, the sane default action on part of the BTS is to
automatically subscribe the the OP of the bug report and to provide a
simple means to unsubscribe. Ie., the acknowledgement mail should
contain the information of how to *un*subscribe from the report.

Speaking just for myself, I have too often not received follow up
questions to a bug report or only found them at a much later time and
'by accident' via the web interface. I don't blame this on the
developers though, because I happen to forget to set the right cc's or
to's of a mail rather to often myself.

I think the BTS should make it as simple as possible to 'do the right
thing', ie. keep the maintainer and the reporter of a bug informed.

Cheers,
Johannes
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkqqXKIACgkQC1NzPRl9qEVH1ACeMxW7OUzPqYBw7YQQKZdoST4Y
/WwAnj6ZA2+iQL/rnaelrHi7DbWofeK4
=lpLO
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Explicitely Cc bug reporters

[Harald Braumann]

On Fri, 11 Sep 2009 10:21:07 +0200
Frans Pop  wrote:

> Paul Wise wrote:
> > I personally prefer not to be CCed on bug reports. I don't want to
> > recieve any mail about a bug unless it is asking me to supply more
> > information.
> 
> So you *do* want to be CCed if the maintainer needs more information.
> 
> Then there's one thing I don't get.
> - if we change the default to "always CC", nobody is going to
> explicitly CC submitters anymore; that's only logical, correct?
> - you choose not to subscribe
> - ergo, you will never see any requests for additional information
> 
> How would you solve that problem within your proposal?

I see auto-subscribe as mainly a convenience for the submitter. It won't
solve the problem you mention. If the maintainer has a question
specifically to the submitter, he will have to cc him. I don't see any
other solution.

> As I've mentioned before, IMO there is only one valid reason to 
> unsubscribe from BRs after we change the default, and that is if you 
> *already* receive follow-ups because
> - the package has Maintainer set to a mailing list and you are
> subscribed to that list
> - you are subscribed to bug mails for the package through the PTS

Well, others might have their own reasons. 

> I'm sorry that you consider receiving follow-ups an inconvenience,
> but IMO the benefit of in general being sure submitters will get
> follow-ups outweighs that.

While I personally like to be kept updated on all bugs I file and would
welcome an auto-subscribe feature, one has to accept the fact that
others might not. I always find it very irritating if The System
forces things on me because it thinks it knows what's best for everyone
and regards me as a half-witted imbecile who is not capable of making
his own decisions or anticipate their consequences.

Therefore there needs to be an opt-out feature. And it should be
clear how to opt out and simple to use. 

> It will also solve the problem that I've seen numerous times that CCs
> from me directly get rejected by submitters through overly aggressive
> spam filtering. (And yes, I do send out mails through my ISP.)

No it won't. If there is no simple way to opt-out, the spam filter is
the only solution to work-around what some might consider an
inconvenience.

Cheers,
harry


signature.asc
Description: PGP signature

Re: Faster boot by running init.d scripts in parallel

[Michael Biebl]

Wouter Verhelst wrote:
> On Thu, Sep 10, 2009 at 01:05:32PM +0200, Petter Reinholdtsen wrote:
>> If you want to test this feature in testing or unstable, use this
>> command:
>>
>>   echo CONCURRENCY=makefile >> /etc/default/rcS
>>
>> It will enable makefile style concurrency, and run N scripts in
>> parallel during boot, where N is the number of CPUs or cores on the
>> machine.
> 
> That seems suboptimal.

I think Petter is not right here.
startpar in makefile mode is run with the -p 4 flag in /etc/init.d/rc.

 eval "$(startpar -p 4 -t 20 -T 3 -M $1 -P $previous -R $runlevel)"

The man page says:

> startpar is used to run multiple run-level scripts in parallel. The degree of
> parallelism on one CPU can be set with the -p option, the default is full
> parallelism. An argument to all of the scripts can be provided with the
> -a option.

If I read the man page correctly, this means we start up to 4 concurrent
(independent) run level scripts per CPU.



Cheers,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Explicitely Cc bug reporters

[Steve Langasek]

On Fri, Sep 11, 2009 at 12:44:56PM +0100, Jon Dowland wrote:
> On Fri, Sep 11, 2009 at 10:21:07AM +0200, Frans Pop wrote:
> > As I've mentioned before, IMO there is only one valid
> > reason to unsubscribe from BRs after we change the
> > default, and that is if you *already* receive follow-ups
> > because
> snip

> There's also the case where you submitted a bug in a package
> or with hardware that you no longer use or have access to,
> so can no longer test fixes. Perhaps others have "me too"'d
> the bug, so it shouldn't just be closed (although I'd argue
> that submitter dropping off a bug is not reason alone to
> close it)

In that case, use the 'submitter' BTS command to reparent the bug to someone
relevant.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: Explicitely Cc bug reporters

[Don Armstrong]

On Fri, 11 Sep 2009, Christoph Egger wrote:
> I'm seeing exactly this problem with the proposal. IMHO we really
> need a way to definitely get the submitter and we need to use that
> whenever we need a answer. subscribing the submitter to
> ???...@bugs.d.o by default and giving the option to unsubscribe will
> just increase the number of Maintainers not thinking of CC the
> submitter.

The complete plan involves having nnn-submitter@ changing from being
an alias of the submitter's e-mail address to behaving like nnn@, with
the addition of making sure that the submitter gets a copy. See my
mails on this subject.


Don Armstrong

-- 
Only one creature could have duplicated the expressions on their
faces, and that would be a pigeon who has heard not only that Lord
Nelson has got down off his column but has also been seen buying a
12-bore repeater and a box of cartridges.
 -- Terry Pratchet _Mort_

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#513272: Availability of roundl() on armel?

[Michael Hanke]

Hi,

[ I already posted this to debian-armel already [0], but got no response
  so far -- maybe someone on this list can provide a hint ]


I am trying to fix #513272, a FTBFS on armel. The problem basically
boils down to the following snippet failing to compile on armel (tested
with a Debian lenny on a qemu-emulated armel system):

-
#include 

using namespace std;

int main ()
{
  double val = 3.4;
  int res;
  res = roundl(val);
}
-

yields

-

debian-armel:~# g++ -Wall test.cpp
test.cpp: In function ‘int main()’:
test.cpp:9: error: ‘roundl’ was not declared in this scope

-

On i386 and amd64 this works fine. The solution is probably simple, but
I could not determine it. Suggestions are very much appreciated.


Thanks in advance,

Michael

-- 
GPG key:  1024D/3144BE0F Michael Hanke
http://apsy.gse.uni-magdeburg.de/hanke


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#546217: ITP: gargoyle-free -- interactive fiction player

[Sylvain Beucler]

Package: wnpp
Severity: wishlist
Owner: Sylvain Beucler 


* Package name: gargoyle-free
  Version : 2009-08-25
  Upstream Author : Tor Andersson, Ben Cressey
* URL : http://ccxvii.net/gargoyle/
* License : GPL and compatible
  Programming Lang: C
  Description : interactive fiction player

Gargoyle is an Interactive Fiction (text adventure) player that
supports all the major interactive fiction formats.

Most interactive fiction is distributed as portable game files. These
portable game files come in many formats. In the past, you used to
have to download a separate player (interpreter) for each format of IF
you wanted to play. Gargoyle is based on the standard interpreters for
the formats it supports.

This version of gargoyle does not include the non-free Alan and Hugo
interpreter, and use a different, free monospace font.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

DEP-5: query about possible inheritence of License:

[Jon Dowland]

Sorry to raise the spectre of DEP5 after so many months.
And apologies if this has already been raised elsewhere;
I haven't found it in a skim of the list archives and the
wiki page.

Consider the situation where you have a package licensed
entirely under one license and predominantly authored by
one or more persons, with the odd file here and there
authored by a different conjunction of people. In this
case, would the following

Files: *
Copyright: John Doe 
License: GPL-2+

Files: wibble.c
Copyright: John Doe ,
   Jane Doe 

The intention here is to indicate that the Copyright
differs for wibble.c, but the License from the earlier
wildcard still applies. Is this acceptable, or need I
replicate License: in the second stanza?

Related, I'm assuming that declaring a Copyright: line in
the second stanza overrides the one in the former stanza,
so John Doe needs to be represented twice.

If this seems sensible, I think that the former should be
made more explicit in the document and possibly the latter
made more clear. I am prepared to have a stab at the diff.


-- 
Jon Dowland


signature.asc
Description: Digital signature

Re: Bug#513272: Availability of roundl() on armel?

[Jan C. Nordholz]

Hi Michael,

> I am trying to fix #513272, a FTBFS on armel. The problem basically
> boils down to the following snippet failing to compile on armel (tested
> with a Debian lenny on a qemu-emulated armel system):

see /usr/include/bits/mathdef.h on armel:

] [...]
] #ifndef __NO_LONG_DOUBLE_MATH
] /* Signal that we do not really have a `long double'.  This disables the
]declaration of all the `long double' function variants.  */
] # define __NO_LONG_DOUBLE_MATH  1
] #endif

which has exactly the effect you describe. ;-)


Regards,

Jan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Faster boot by running init.d scripts in parallel

[Manoj Srivastava]

On Fri, Sep 11 2009, Wouter Verhelst wrote:

> On Thu, Sep 10, 2009 at 01:05:32PM +0200, Petter Reinholdtsen wrote:
>> If you want to test this feature in testing or unstable, use this
>> command:
>> 
>>   echo CONCURRENCY=makefile >> /etc/default/rcS
>> 
>> It will enable makefile style concurrency, and run N scripts in
>> parallel during boot, where N is the number of CPUs or cores on the
>> machine.
>
> That seems suboptimal.
>
> It occurs to me that initscripts are mostly I/O bound (since they need
> to start applications that then go waiting in the background), rather
> than CPU bound; as such, the number of initscripts that can be ran in
> parallel is more dependent on I/O speed than on CPU speed.
>
> It's probably best to make this N be a configurable variable (possibly
> defaulting to something based on something we detect from the system
> we're running on) rather than have it be something detected and not
> configurable.
>
> If it actually is configurable, but you just didn't tell us so, then
> please feel free to disregard this mail ;-)

I actually lost 7 seconds, according to bootchard, by setting
 that.

manoj
-- 
Texas law forbids anyone to have a pair of pliers in his possession.
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#546220: ITP: agtl -- tool for paperless geocaching

[hstuebner]

Package: wnpp
Severity: wishlist
Owner: Heiko Stuebner 


* Package name: agtl
  Version : 0.3.0
  Upstream Author : Daniel Fett 
* URL : 
http://wiki.openmoko.org/wiki/Advanced_Geocaching_Tool_for_Linux
* License : GPL3 (or later) and one included file GPL2 (or later)
  Programming Lang: Python
  Description : tool for paperless geocaching

It downloads cache locations in the area visible on the map including their 
description,
hints, difficulty levels and images. Searching for caches in your local db is a 
matter
of seconds. The currently selected cache is shown on the map (and also all the 
others
if you want) and there's a traditional compass-like view that always points at 
the cache.

- finger-friendly input and user interface
- download geocaches for offline use with full text, hints & images on your 
freerunner
- log caches and write notes while out in the field and upload them later.

- writes html page for each downloaded cache
- map view with icons for nearby geocaches (uses openstreetmaps and tangogps 
map directory,
  downloades missing tiles automatically)
- search the internal database for geocaches by name or type
- shows current altitude, distance to target, current bearing, direction to 
target, number
  of satellites and current position
- target selection: selected geocache, one of its waypoints or manual input
[description by the author of the program)

Agtl is primarily targeted at smartphones (i.e. the openmoko freerunner)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#546222: RFP: latex-translator -- modular LaTeX string localization system

[Andrey]

Package: wnpp
Severity: wishlist

* Package name: latex-translator
  Version : 1.00
  Upstream Author : Till Tantau (tan...@users.sourceforge.net)
* URL or Web page : http://sourceforge.net/projects/latex-beamer
* License : LaTeX Project Public License or GPL
  Description : modular LaTeX string localization system

The translator package is intended to provide an open platform for
packages that need to be localized. Unlike the babel package (which
can and typically will be used together with translator), the set of
words that can be translated is not fixed and new words and
translations can be added in a simple manner. New translations can be
added in a decentralized manner. The package is written in completely
LaTeX and it is quite lightweight. It could very easily be ported to
plain-TeX or ConTeXt, provided there is a "public demand" for this. A
typical application of this package is the beamer class, which already
uses it, if it present. Then words like "Theorem" will be translated
to "Satz" if the document language is German, for instance. 



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Explicitely Cc bug reporters

[Frans Pop]

Harald Braumann wrote:
> While I personally like to be kept updated on all bugs I file and would
> welcome an auto-subscribe feature, one has to accept the fact that
> others might not. I always find it very irritating if The System
> forces things on me because it thinks it knows what's best for everyone
> and regards me as a half-witted imbecile who is not capable of making
> his own decisions or anticipate their consequences.

OTOH, the system does have to ensure consistent behavior. Having 
submitters CCed by default and then still needing to CC them to be sure 
they get your questions is not consistent behavior. It's just plain 
silly. Either we change the default, or we don't. If we do, some people 
will just have to accept the change.
 
> Therefore there needs to be an opt-out feature. And it should be
> clear how to opt out and simple to use.

I'm not sure there should be, not for the submitter. And, as Steve 
Langasek rightly mentioned, the submitter _can_ be changed in the Debian 
BTS.
 
>> It will also solve the problem that I've seen numerous times that CCs
>> from me directly get rejected by submitters through overly aggressive
>> spam filtering. (And yes, I do send out mails through my ISP.)
> 
> No it won't. If there is no simple way to opt-out, the spam filter is
> the only solution to work-around what some might consider an
> inconvenience.

You misunderstand. There's a HUGE difference between people *filtering* 
out unwanted mail and *rejecting legitimate mail as spam* just because of 
some persieved incorrectness in the mail headers that the sender has 
absolutely zero influence over because his ISP does not understand the 
extreme correctness requirements some people wish to enforce.

Cheers,
FJP


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

RFC about cosmetic bug whith partial upgrades vs. added symbol versioning

[Mike Hommey]

Hi fellow developers,

I uploaded, yesterday, a new upstream of libxml2 that adds symbol
versioning. There is actually no problem with this, and from my testing,
everything is still working as expected (the most important part being
that symbols have only been versioned, and none was removed).

Anyways, my concern is that as reverse dependencies will get built
against this new libxml2, they are going to need versioned symbols at
dynamic load time.

This appears to not be a problem either, because the dynamic loader
falls back to the unversioned symbols when the versioned symbols don't
exist, but it does emit a warning message about the fact that the
versioned symbols have not been found. It looks like it emits one such
message per symbol not found.

Now, libxml2 is used a lot. A whole lot. My concern is that partial
upgrades can possibly leave people with an old libxml2 and newer
programs (they could even put themselves in this situation by pinning
some packages), in which case these warnings are going to show up.

Do you think it would be better to force all rdeps to depend on the
newer libxml2 by the means of shlibs/symbols file so that we avoid this
possibility, or leaving this known "bug" should be fine?

Cheers,

Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Explicitely Cc bug reporters

[Ben Finney]

Don Armstrong  writes:

> The complete plan involves having nnn-submitter@ changing from being
> an alias of the submitter's e-mail address to behaving like nnn@, with
> the addition of making sure that the submitter gets a copy. See my
> mails on this subject.

Thanks for pointing this out again. This seems like the best approach:

* it allows for the common case expressed by package maintainers in this
  discussion:

  “I want to communicate with the bug submitter and keep a record in the
  bug report, using a single ‘To’ address and not needing to know
  anything about specific options the submitter might have chosen.”

* it allows low-interest bug report traffic to go *only* to the bug
  report (at , just like now). The submitter, like
  anyone else, can opt in or out of this traffic.

* it requires no specific action from the submitter beyond the act of
  submitting a bug report at all.

* it requires that we (package maintainers) get into the habit of using
   for the common case of discussion with
  the submitter, which has been independently suggested by many in this
  discussion as an acceptable compromise that isn't particularly
  onerous.

-- 
 \  “When I was a little kid we had a sand box. It was a quicksand |
  `\   box. I was an only child... eventually.” —Steven Wright |
_o__)  |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Faster boot by running init.d scripts in parallel

[Henrique de Moraes Holschuh]

On Fri, 11 Sep 2009, Olivier Bonvalet wrote:
> But combined with "readahead", there is no I/O bound during init.
> Most of needed files are preload.

Any initscripts that deal with devices will still be I/O bound.  And the
current scheduler doesn't help (see current threads in LKML).  You should
start no less than two processes per CPU, probably more, if you want the
minimum boot time.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFC about cosmetic bug whith partial upgrades vs. added symbol versioning

[Henrique de Moraes Holschuh]

On Fri, 11 Sep 2009, Mike Hommey wrote:
> Now, libxml2 is used a lot. A whole lot. My concern is that partial
> upgrades can possibly leave people with an old libxml2 and newer
> programs (they could even put themselves in this situation by pinning
> some packages), in which case these warnings are going to show up.
> 
> Do you think it would be better to force all rdeps to depend on the
> newer libxml2 by the means of shlibs/symbols file so that we avoid this
> possibility, or leaving this known "bug" should be fine?

The lesser-user-annoyance path is to use shlibs to force any new packages to
have a versioned dep on the libxml2-with-symbol-versions pacakges, yes.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Faster boot by running init.d scripts in parallel

[Michael Biebl]

Manoj Srivastava wrote:

> 
> I actually lost 7 seconds, according to bootchard, by setting
>  that.

Would be interesting to have a before and after bootchart so this regression can
be investigated.

Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#546258: ITP: overload -- Scilab toolbox to overload Scilab's macros

[Sylvestre Ledru]

Package: wnpp
Severity: wishlist
Owner: Sylvestre Ledru 


* Package name: overload
  Version : 1.3.1
  Upstream Author : Calixte Denizet 
* URL : http://scilabtbxset.sourceforge.net/
* License : GPL 3
  Programming Lang: C, C++
  Description : Scilab toolbox to overload Scilab's macros

 Thanks to this toolbox, a user can overload user-defined functions 
 as if they were built-in functions.
 . 
 This provides the capabilites to overload low-level Scilab's internal 
 features.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Explicitely Cc bug reporters

[Steve Langasek]

On Thu, Sep 10, 2009 at 10:40:14PM +0200, Sandro Tosi wrote:
> > I'm fine with it being the default, it just needs to be something that
> > a submitter can choose not to receive.

> > If the consensus is that we should implement Cc:'ing the submitter
> > quickly, and that it's ok to implement the opt-out at some future
> > time, that's trivial for me to do, but I've been loth to change the
> > historical functionality of the BTS like this without clear consensus.

> Given the high rate of people (at least in those that replied here) in
> favor of adding submitter in the loop of n...@b.d.o, I think your plan
> is very good:

> - include the submitter in n...@b.d.o by default now;
> - implement the opt-out somewhere in the future; that could also be
> 'never', if the fall back of the change generates no concerns from
> users.

I agree with those who've said that a given mail address either should, or
should not, forward to the submitter.  I also think it's important to fix
it so n...@bugs.debian.org is an address that *does* cc: the submitter, and
for messages not to the submitter we should use -maintonly or something like
it.

How much support must be shown for such an implementation to see it done?

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Bug#546270: ITP: taggrepper -- search and match tags of media files against regular expressions

[Kumar Appaiah]

Package: wnpp
Severity: wishlist
Owner: Kumar Appaiah 

* Package name: taggrepper
  Version : 0.03
  Upstream Author : Kumar Appaiah (myself)
* URL : http://gitorious.org/taggrepper/pages/Home
* License : BSD
  Programming Lang: C
  Description : search and match tags of media files against regular 
expressions

 taggrepper is a small tool written to "grep" tags of media
 files. Currently, it can be used to match some or any tags of MP3,
 Ogg Vorbis and FLAC files, against specified regular expressions, and
 display the name and designated fields of the matching files. It
 supports recursive directory searches as well.

Notes: I wrote this software rather quickly for my own use, but I have
tested it fairly well, and it should work for most. I have not come
across a software which does exactly this, which is why I believe
Debian could possess this. I have done my best to add a tutorial style
README and a man page for the program.

Please voice your opinions and objections on any of the above.

Thanks.

Kumar
-- 
Kumar Appaiah


signature.asc
Description: Digital signature

Re: Explicitely Cc bug reporters

[Christian Perrier]

Quoting Don Armstrong (d...@debian.org):

> Considering the fact that this thread has only been here for a few
> hours,[1] I'm going to hold off at least for a few days to entertain
> objections. But hearing none, I'll implement this when I get a chance.


Not sure that's really needed as you made your point clear but I
personnally wholeheartedly support any change that would lead to
submitters being CC'ed to n...@bugs.d.o by default, with all extra care
taken to allow them to opt-out. In short, suggestions made by Frans in
this thread fit my opinion.

Anyway, I entirely trust you to implement this The Right Way.

It will then take me ages before I lose my now well established habit
to "Reply to All" when discussing about a bug (habit that made me mail
sub...@bugs.debian.org dozens of times) but I'll cope with that..:)




signature.asc
Description: Digital signature