Re: List of packages which should probably be Architecture: all

[Javier Fernández-Sanguino Peña]

On Wed, Jan 02, 2008 at 01:58:24PM -0600, Raphael Geissert wrote:
>clips-common

Fixed now, I'm going to upload a new version (6.24-2) making it arch: all

Javier


signature.asc
Description: Digital signature

wxWidgets2.4

[Thomas Viehmann]

Roberto C. Sanchez wrote:
> * Package name: libalien-wxwidgets-perl
But please don't add packages for WxWindows2.4 reverse dependencies[1].

While I can see why the release team is reluctant to add getting rid of
wxwindows2.4 as a release goal in terms of rendering existing packages RC buggy
just because of that, I am surprised to see that increasing the number of
reverse dependencies (jugglemaster was introduced as a new package in late
November 2007) after half at least half a year of off and on efforts to
eliminate dependencies.

Unless we want to support wxWindows2.4 for lenny (which I don't think anyone is
actually proposing) we should get serious about descreasing the number of
reverse dependencies.

Kind regards

T.

1. http://wiki.debian.org/GetRidOfWxWindows2.4
-- 
Thomas Viehmann, http://thomas.viehmann.net/


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

djbdns, daemontools, ucspi-tcp, qmail

[Jan Mojzis]

Hello,
there are djbdns-installer, daemontools-installer, ucspi-tcp-src, qmail-src 
package,
but for now is not necesary to have this "-installer" packages.
Licence for this software changed "http://cr.yp.to/distributors.html";
Packages are in public domain, including distributing modified versions.

What about remove djbdns-installer, daemontools-installer, ucspi-tcp-src, 
qmail-src and make 
binary packages  djbdns, daemontools, ucspi-tcp, qmail ?

Jan Mojzis



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

Re: -Wl,--as-needed considered possibly harmful

[Neil Williams]

On Fri, 2008-01-04 at 17:52 -0800, Steve Langasek wrote:
> On Wed, Jan 02, 2008 at 11:53:16AM +, Neil Williams wrote:
> > That's upstream covered, it appears I also need debian/libqof1.symbols
> > from http://qa.debian.org/cgi-bin/mole/seedsymbols ? If I had done
> > symbol versioning correctly upstream, shouldn't dpkg-shlibdeps be able
> > to create the necessary data itself? I don't provide a .shlib file of
> > my own at this stage.
> 
> The symbols files are orthogonal to symbol versioning.  Symbols files are
> basically "per-function shlibs", which are applicable even to libs that
> don't use symbol versioning; their main benefit is for libraries which make
> backwards-compatible ABI changes.

In which case I should have been supporting symbols files since v0.6.0
because that is exactly what I've been doing in this package for the
last two years or more - adding new functions, deprecating the old ones,
collecting all the changes into one transition to the next SONAME. Not
sure why the sample symbols file showed the same version for all
functions - quite a lot were simply not present in 0.6.0. Ne'er mind.

It's a bit late now (I'm preparing for a SONAME bump where all those
backwards-compatible layers are removed) but I'll implement it in the
new version to allow tracking of future backwards-compatible ABI
changes.

Thanks.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/




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

Re: pkg-$GROUP on Alioth: please whitelist messages from BTS (was Re: Bug#459247: grub-pc: please don't play with /boot/grub/menu.lst)

[Stephen Gran]

This one time, at band camp, Joerg Jaspert said:
> On 11255 March 1977, Don Armstrong wrote:
> 
> > It should be mandatory at least for it to accept messages from the
> > BTS,[1] and be moderated otherwise.
> 
> > I e-mailed both Robert and Otavio from [EMAIL PROTECTED] to this effect on
> > the first, but haven't heard back from them. Hopefully they will
> > resolve that soon.
> 
> BTS *AND* the archive! I regularly get to hate more developer when
> getting crap back from mailing lists thanks to NEW packages...

I've just told mailman on alioth to look at the envelope sender for
figuring out who mail is coming from.  This means that most lists can
just add debbugs@ and dak@ to the allowed email list and it will pretty
much do the right thing.  This will break things if the normal
subscribers send with random envelopes, but that's probably a bug in
their mail environments.
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: djbdns, daemontools, ucspi-tcp, qmail

[Andreas Metzler]

Jan Mojzis <[EMAIL PROTECTED]> wrote:
> there are djbdns-installer, daemontools-installer, ucspi-tcp-src,
> qmail-src package, but for now is not necesary to have this
> "-installer" packages.  Licence for this software changed
> "http://cr.yp.to/distributors.html"; Packages are in public domain,
> including distributing modified versions.

> What about remove djbdns-installer, daemontools-installer,
> ucspi-tcp-src, qmail-src and make binary packages  djbdns,
> daemontools, ucspi-tcp, qmail ?

Already being worked on. http://bugs.debian.org/wnpp


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

Re: Faster shutdown and the ubuntu "multiuser" update-rc.d extention

[Riku Voipio]

On Fri, Jan 04, 2008 at 11:26:21PM +0100, Josselin Mouette wrote:
> I do hope there are better examples than a confidential application and
> a useless daemon that has been deprecated for years, to justify messing
> with dh_installinit and update-rc.d as you are proposing.

You don't need to *hope*. You could just review your own /etc/init.d
directory for scripts that do nothing nothing but
"start-stop-daemon --stop" or something equal.

looking at mine:

anacron, atd, atftpd, dirmngr, hal, ...


-- 
"rm -rf" only sounds scary if you don't have backups


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

Re: pkg-$GROUP on Alioth: please whitelist messages from BTS (was Re: Bug#459247: grub-pc: please don't play with /boot/grub/menu.lst)

[Joerg Jaspert]

On 11255 March 1977, Stephen Gran wrote:

>> > It should be mandatory at least for it to accept messages from the
>> > BTS,[1] and be moderated otherwise.
>> > I e-mailed both Robert and Otavio from [EMAIL PROTECTED] to this effect on
>> > the first, but haven't heard back from them. Hopefully they will
>> > resolve that soon.
>> BTS *AND* the archive! I regularly get to hate more developer when
>> getting crap back from mailing lists thanks to NEW packages...

> I've just told mailman on alioth to look at the envelope sender for
> figuring out who mail is coming from.  This means that most lists can
> just add debbugs@ and dak@ to the allowed email list and it will pretty
> much do the right thing.  This will break things if the normal
> subscribers send with random envelopes, but that's probably a bug in
> their mail environments.

I think for mails from the NEW queue (reject, prod, accept), from
removals CCed to packages its the address of the one doing it, ie in my
case [EMAIL PROTECTED]

-- 
bye Joerg
 sind jabber und icq 2 unterschiedliche netzwerke ?


pgpFmCFRoVxRj.pgp
Description: PGP signature

Re: Opinions needed: reporting lintian overrides

[Steve McIntyre]

Russ wrote:
>
>* Show the N: line with a count of overrides per package by default and
>  provide an option to suppress this output if someone wants.
>
>* Don't show the N: line by default and provide an option to turn it on.
>
>Which should we do?

As you might expect (as I was the requester for this feature) I'd
*really* prefer the former option. My initial reasoning for it is that
I want to make it immediately visible to sponsors if a package has
suppressed lintian warnings. If it's not the default behaviour to list
them, then I'd be worried that some people just won't notice.

-- 
Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED]
Welcome my son, welcome to the machine.


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

Re: Faster shutdown and the ubuntu "multiuser" update-rc.d extention

[Jörg Sommer]

Hallo Petter,

Petter Reinholdtsen <[EMAIL PROTECTED]> wrote:
> [Kurt Roeckx]
>> Why is it using -18?   Please change that to SIGCONT, it depends on the
>> arch what the value should be.  See signal(7), which even mentions that
>> that is different for ppc/i386.
>
> Historical reasons and because that is what killall5 support, as I
> noticed you discovered shortly after you sent this email. :)

What about kill -l?

% kill -l SIGCONT
18

>> I think it would be nice that in case it needs to send KILL
>> for debug purpuses it could:
>> - output which processes are still running
>
> Would need a change in the interface and behaviour of killall5, or
> perhaps it is enough to do 'ps -ef' or similar?  Not sure if it is
> useful in non-debugging sessions, though.

IMO, yes. Printing the process names should not clutter the screen and
might provide informations to detect problems. It's better to have more
informations than less.

Bye, Jörg.
-- 
Dadurch, dass man einen anderen ins Irrenhaus sperrt,
beweist man noch nicht seinen eigenen Verstand.


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

Bug#459320: ITP: buildutils -- Distutils extensions for developing Python libraries and applications

[Piotr Ożarowski]

Package: wnpp
Severity: wishlist
Owner: "Piotr Ożarowski" <[EMAIL PROTECTED]>

* Package name: buildutils
  Version : 0.3
  Upstream Author : Ian Bicking, Ryan Tomayko <[EMAIL PROTECTED]>
* URL : http://buildutils.lesscode.org/
* License : MIT
  Programming Lang: Python
  Description : Distutils extensions for developing Python libraries and 
applications.

Python Build Utilities (buildutils) is a set of extension commands to Python's
standard distutils that are often useful during development and deployment of
python projects. buildutils was created with the desire of removing make and
other external build tools from the python development process.
.
Because buildutils is integrated with distutils, information about a project
can be obtained from the project's setup.py and setup.cfg files. This allows
commands to provide smart defaults when invoking external tools and utilities.



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

Bug#459318: ITP: ucspi-tcp -- tcpclient, tcpserver and other TCP easy-use commandline-tools

[Jan Mojzis]

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


* Package name: ucspi-tcp
  Version : 0.88
  Upstream Author : Daniel J. Bernstein
* URL : http://cr.yp.to/ucspi-tcp.html
* License : public domain
  Programming Lang: C
  Description : tcpclient, tcpserver and other TCP easy-use 
commandline-tools

 Written by Dan J. Bernstein, tcpclient and tcpserver are
 powerful easy-to-use command-line tools for building TCP
 client-server applications. tcpserver provides TCP access control
 features, similar to tcp-wrappers/tcpd's hosts.allow but much
 faster; it can run high-availability services much better than
 inetd.
 .
 Real-time Blocking List support is also included in tcpserver, so
 you can run qmail-smtpd with it and avoid a lot of SPAM.
 .
 tcpclient and tcpserver conform to UCSPI, the UNIX Client-Server
 Program Interface, using the TCP protocol.
 .

 For now is ucspi-tcp released into the public domain including distributing
 modified version.


 (I can help with packaging)
 Jan Mojzis
 [EMAIL PROTECTED]




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

Re: wxWidgets2.4

[Roberto C . Sánchez]

On Sat, Jan 05, 2008 at 10:55:06AM +0100, Thomas Viehmann wrote:
> Roberto C. Sanchez wrote:
> > * Package name: libalien-wxwidgets-perl
> But please don't add packages for WxWindows2.4 reverse dependencies[1].

(unstable)miami:/var/lib/chroot/pbuilder-sid/results# dpkg --info 
libalien-wxwidgets-perl_0.32-1_i386.deb
 new debian package, version 2.0.
 size 18094 bytes: control archive= 873 bytes.
 488 bytes,12 lines  control  
 916 bytes,11 lines  md5sums  
 Package: libalien-wxwidgets-perl
 Version: 0.32-1
 Architecture: i386
 Maintainer: Debian Perl Group <[EMAIL PROTECTED]>
 Installed-Size: 124
 Depends: libwxgtk2.6-dev
 Section: perl
 Priority: optional
 Homepage: http://search.cpan.org/dist/Alien-wxWidgets/
 Description: building, finding and using wxWidgets binaries
  Detects configuration settings of an installed wxWidgets.  Can be used in
  order to help in the process of building modules which require wxWidgets.

> 
> While I can see why the release team is reluctant to add getting rid of
> wxwindows2.4 as a release goal in terms of rendering existing packages RC 
> buggy
> just because of that, I am surprised to see that increasing the number of
> reverse dependencies (jugglemaster was introduced as a new package in late
> November 2007) after half at least half a year of off and on efforts to
> eliminate dependencies.
> 
> Unless we want to support wxWindows2.4 for lenny (which I don't think anyone 
> is
> actually proposing) we should get serious about descreasing the number of
> reverse dependencies.
> 
No wx2.4 dependencies or reverse dependencies here :-)

I am packaging this because it is needed by libwx-perl, which I am also
packaging.  As far as I can tell, both happily work wx2.6.

Regards,

-Roberto

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Re: Faster shutdown and the ubuntu "multiuser" update-rc.d extention

[Petter Reinholdtsen]

[Jörg Sommer]
> Hallo Petter,

Hi.

> What about kill -l?
>
> % kill -l SIGCONT
> 18

Hm, interesting idea.  I guess killall5 $(kill -l SIGCOUNT) would
work.

> IMO, yes. Printing the process names should not clutter the screen
> and might provide informations to detect problems. It's better to
> have more informations than less.

Thanks for the feedback.  But more information is not always better.
It increases the cognitive strain and might even increase confusion.

Happy hacking,
-- 
Petter Reinholdtsen


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

Bug#459325: ITP: clang -- A C language family frontend for LLVM

[Y Giridhar Appaji Nag]

Package: wnpp
Severity: wishlist
Owner: Y Giridhar Appaji Nag <[EMAIL PROTECTED]>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: clang
  Version : 2.2svn
  Upstream Author : Chris Lattner <[EMAIL PROTECTED]>
* URL : http://clang.llvm.org/
* License : University of Illinois/NCSA Open Source License
  Programming Lang: C/C++
  Description : A C language family frontend for LLVM

The Clang project is a new C, C++, Objective C and Objective C++
front-end for the LLVM  compiler.  The end-user features of clang are
fast compiles and low memory use, expressive diagnostics, and GCC
compatibility.  It has a modular library based architecture, supports
diverse clients (refactoring, static analysis, code generation, etc.)
and allows tight integration with IDEs.  Internally, clang has a single
unified parser for C, Objective C, C++, and Objective C++.
.
Clang is still in early development stages and good for source analysis
or source-to-source transformation tools.  It is not yet ready for use
as a drop in C compiler.  It currently has pretty good parsing and
semantic analysis support for C and Objective-C.  C++ support is still
very early.

- -- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (800, 'unstable'), (700, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.22-3-686 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash

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

iD8DBQFHf6CH4eu+pR04mIcRAl2JAJ4zI+aveTbyq3Fo859/qHb4mRqnJgCeLvVh
e366AXUaW0yBhDEH98tu6Uc=
=CUPo
-END PGP SIGNATURE-



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

Re: Faster shutdown and the ubuntu "multiuser" update-rc.d extention

[Felipe Sateler]

Petter Reinholdtsen wrote:

> No-one has suggested as far as I can see to remove all shutdown
> scripts, while all arguments against removing some shutdown scripts
> seem to base their argument on that premise.  To repeat myself another
> time:
> 
> Daemons that need a shutdown script should keep it.  Daemons that do
> not need a shutdown script can drop it, and leave it to sendsigs to
> kill them.
> 

If there are daemons which don't need to save state, or do useful work on
shutdown (and thus don't need an init script)... why bother with TERMing them
instead of directly KILLing them?

-- 

  Felipe Sateler


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

Re: Faster shutdown and the ubuntu "multiuser" update-rc.d extention

[Petter Reinholdtsen]

[Felipe Sateler]
> If there are daemons which don't need to save state, or do useful
> work on shutdown (and thus don't need an init script)... why bother
> with TERMing them instead of directly KILLing them?

Mostly to keep the complexity of sendsigs down.  But I agree with your
logic, that either would work.

Happy hacking,
-- 
Petter Reinholdtsen


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

Re: Future Debian package candidate web pages: present and future

[Sebastian Pipping]

Raphael Geissert wrote:

AFAIR the SOAP interface can provide you with such information (refer to the
wiki page).


I'd rather talk to SQL if possible. It's faster and much easier to me.




popcon data is available at popcon.d.o, importance can be extracted from the
Packages files.


Good idea.




* No combined requested-or-worked-on (== not packaged) view


This isn't very clear for me, why do you want to combine them?


When requesting new packages one currently has two search
both lists, which currently means browsing two pages.
But I found out now this page actually does this combination
already:
http://www.debian.org/devel/wnpp/prospective



Sebastian


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

Re: Future Debian package candidate web pages: present and future

[Lucas Nussbaum]

On 05/01/08 at 19:19 +0100, Sebastian Pipping wrote:
> Raphael Geissert wrote:
>> AFAIR the SOAP interface can provide you with such information (refer to the
>> wiki page).
>
> I'd rather talk to SQL if possible. It's faster and much easier to me.

Another solution is to use the BTS dump available at
http://qa.debian.org/data/bts2ldap/
It's very easy to parse (and import in an SQL DB, if you want)
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


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

SOAP in BTS (was: Future Debian package candidate web pages: present and future)

[Nico Golde]

Hi Raphael,
* Raphael Geissert <[EMAIL PROTECTED]> [2008-01-05 12:05]:
[...] 
> AFAIR the SOAP interface can provide you with such information (refer to the
> wiki page).

Yes it can:
{123456=>#nil} 
{}fixed_versions=["eazel
-engine/0.3-1"] {}mergedwith="" {}found=# 
{}unarchived="" {}blockedby="" {}keywords="" {}msgid="<[EMAIL PROTECTED]>" 
{}id=123456 {}forwarded="" {}severity="wishlist" {}owner="" 
{}log_modified=1012335515 {}location="archive" {}originator="Filip Van 
Raemdonck <[EMAIL PROTECTED]>" {}subject="ITP: eazel-engine -- Crux theme for 
GTK+" {}pending="done" {}tags="" {}fixed_date=[] {}package="wnpp" 
{}found_date=[]>}

The date attribute returned by get_status should do the trick.
Kind regards
Nico

-- 
Nico Golde - http://www.ngolde.de - [EMAIL PROTECTED] - GPG: 0x73647CFF
For security reasons, all text in this mail is double-rot13 encrypted.


pgpos3FYzZJyY.pgp
Description: PGP signature

Re: Future Debian package candidate web pages: present and future

[Sebastian Pipping]

Lucas Nussbaum wrote:

Another solution is to use the BTS dump available at
http://qa.debian.org/data/bts2ldap/
It's very easy to parse (and import in an SQL DB, if you want)


Interesting. Thank you!



Sebastian


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

Bug#459350: ITP: enthought-traits-ui -- User interface related modules for enthought traits

[Varun Hiremath]

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

* Package name: enthought-traits-ui
  Version : 2.0.1b1
  Upstream Author : Enthought, Inc.
* URL or Web page : http://code.enthought.com/traits/
* License : BSD-like
  Description : User interface related modules for enthought traits

 Traits lets programmers create  special Python attributes called
 traits that support the following:
  * Initialization: A trait attribute can have a default value
  * Validation: A trait attribute is manifestly typed.
  * Delegation: The value of a trait attribute can be contained in
another object
  * Notification: Setting the value of a trait attribute can fired
callbacks
  * Visualization: With the TraitsUI package, GUIs can be generated
automatically from traited objects.
 .
 The Traits UI package is a set of GUI (Graphical User Interface)
 tools designed to complement Traits. It is based on the wxPython GUI
 toolkit and implements a Model-View-Controller (MVC) architecture on
 top of traits.

-- 
Varun Hiremath
Undergraduate Student,
Aerospace Engineering Department,
Indian Institute of Technology Madras,
Chennai, India
--
Homepage : http://varun.travisbsd.org



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

Bug#459349: ITP: enthought-traits -- Manifest typing and reactive programming for Python

[Varun Hiremath]

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

* Package name: enthought-traits
  Version : 2.0.1b1
  Upstream Author : Enthought, Inc.
* URL or Web page : http://code.enthought.com/traits/
* License : BSD-like
  Description : Manifest typing and reactive programming for Python

 The traits package provides a metaclass with special attributes that
 are called traits. A trait is a type definition that can be used for
 normal Python object attributes, giving the attributes some
 additional characteristics:
  * Initialization: A trait attribute can have a default value
  * Validation: A trait attribute is manifestly typed.
  * Delegation: The value of a trait attribute can be contained in
another object
  * Notification: Setting the value of a trait attribute can fired
callbacks
  * Visualization: With the TraitsUI package, GUIs can be generated
automatically from traited objects.

-- 
Varun Hiremath
Undergraduate Student,
Aerospace Engineering Department,
Indian Institute of Technology Madras,
Chennai, India
-
Homepage : http://varun.travisbsd.org



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

Re: Opinions needed: reporting lintian overrides

[Lars Wirzenius]

On la, 2008-01-05 at 13:43 +, Steve McIntyre wrote:
> As you might expect (as I was the requester for this feature) I'd
> *really* prefer the former option. My initial reasoning for it is that
> I want to make it immediately visible to sponsors if a package has
> suppressed lintian warnings. If it's not the default behaviour to list
> them, then I'd be worried that some people just won't notice.

This might be too much DWIM, but... supposed lintian would, by default,
report the number of suppressed warnings, but only if the person running
it is not the maintainer? Lintian could use the same logic for
determining the name/address as dch does.

Additionally, there should then be options like
--never-summarize-overrides and --always-summarize-overrides.



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

Proposed consensus: reporting lintian overrides

[Russ Allbery]

Steve McIntyre <[EMAIL PROTECTED]> writes:
> Russ wrote:

>> * Show the N: line with a count of overrides per package by default and
>>   provide an option to suppress this output if someone wants.
>>
>> * Don't show the N: line by default and provide an option to turn it on.
>>
>> Which should we do?

> As you might expect (as I was the requester for this feature) I'd
> *really* prefer the former option. My initial reasoning for it is that I
> want to make it immediately visible to sponsors if a package has
> suppressed lintian warnings. If it's not the default behaviour to list
> them, then I'd be worried that some people just won't notice.

I'm getting ready to upload the new version of lintian, so it's time to
declare what the consensus seems to be so that I can implement it.

Interestingly, no one option emerged strongly.  People seem to be split
almost evenly three ways: want the messages by default, don't want them by
default, or want them but only one line per run.

Accordingly, I'm going to modify lintian to print out only one line per
run showing the totals of the overrides for the entire run, on the grounds
that for more details, well, that's what --show-overrides is for.  I think
this should make both the "want this" and the "want this but it's noisy"
folks happy.

For those who really don't want to see this line at all, I'll add a -q
option to lintian that suppresses this line (and anything else like this
that comes up later, if we have anything).

Does that sound consistent with the sentiments on the thread to everyone?

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Opinions needed: reporting lintian overrides

[Russ Allbery]

Raphael Hertzog <[EMAIL PROTECTED]> writes:
> On Sat, 05 Jan 2008, Lars Wirzenius wrote:

>> This might be too much DWIM, but... supposed lintian would, by default,
>> report the number of suppressed warnings, but only if the person
>> running it is not the maintainer? Lintian could use the same logic for
>> determining the name/address as dch does.

> I like that. :) 
>
> So if DEBEMAIL/EMAIL doesn't match Maintainer/Uploaders then you get to
> see the N: lines.

I'm afraid this would require a significant restructuring of lintian's
code and isn't really viable for the next release.  The part of lintian
that is in a position to warn about overrides doesn't have any idea who
the maintainer is.

It will be easier in the future, so I could revisit this later.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Opinions needed: reporting lintian overrides

[Raphael Hertzog]

On Sat, 05 Jan 2008, Lars Wirzenius wrote:
> On la, 2008-01-05 at 13:43 +, Steve McIntyre wrote:
> > As you might expect (as I was the requester for this feature) I'd
> > *really* prefer the former option. My initial reasoning for it is that
> > I want to make it immediately visible to sponsors if a package has
> > suppressed lintian warnings. If it's not the default behaviour to list
> > them, then I'd be worried that some people just won't notice.
> 
> This might be too much DWIM, but... supposed lintian would, by default,
> report the number of suppressed warnings, but only if the person running
> it is not the maintainer? Lintian could use the same logic for
> determining the name/address as dch does.

I like that. :) 

So if DEBEMAIL/EMAIL doesn't match Maintainer/Uploaders then you get to see the
N: lines.

> Additionally, there should then be options like
> --never-summarize-overrides and --always-summarize-overrides.

Indeed.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


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

Availability of wanna-build sources

[Roger Leigh]

Hi folks,

The wanna-build (sbuild, buildd) sources in use on the Project's
buildd infrastructure is maintained by Ryan Murray and is available
From an SVN repository at

  http://svn.cyberhqz.com/svn/wanna-build

However, the version number (99.99) displayed in current sbuild logs
does not reflect the source in the repository, and no commits have
been made since November 2006.

Does anyone know where the sources for the current version of
wanna-build in use on our buildds may be found?


So that the buildd-tools-devel team who maintain the packaged version
of sbuild (and in the near future also wanna-build and buildd) can
maintain compatibility with the version in use on the buildds, I try
to sync changes in upstream SVN as they are made.  However, this is
not currently possible due to the sources apparently not being
available.

  git://git.debian.org/git/buildd-tools/sbuild.git
  git://git.debian.org/git/buildd-tools/buildd.git


Thanks,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


pgpi5KHDMxRYo.pgp
Description: PGP signature

Re: Proposed consensus: reporting lintian overrides

[Bart Martens]

On Sat, 2008-01-05 at 11:12 -0800, Russ Allbery wrote:
> Interestingly, no one option emerged strongly.  People seem to be split
> almost evenly three ways: want the messages by default, don't want them by
> default, or want them but only one line per run.

True, there is no consensus.

> 
> Accordingly, I'm going to modify lintian to print out only one line per
> run showing the totals of the overrides for the entire run, on the grounds
> that for more details, well, that's what --show-overrides is for.  I think
> this should make both the "want this" and the "want this but it's noisy"
> folks happy.

I vote "go ahead with any choice you find best".

> 
> For those who really don't want to see this line at all, I'll add a -q
> option to lintian that suppresses this line (and anything else like this
> that comes up later, if we have anything).

Great, I'll use that -q option.

> 
> Does that sound consistent with the sentiments on the thread to everyone?

No objection from me.  Thanks for asking debian-devel for opinions.

Regards,

Bart Martens



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

Bug#459361: ITP: bubbletrain -- arcade game, shoot coloured bubbles

[Meike Reichle]

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


* Package name: bubbletrain
  Version : 0.0.20050612-1
  Upstream Author : Adam Child <[EMAIL PROTECTED]>
* URL : http://dwarfcity.co.uk/games/bubbletrain.php
* License : GPL
  Programming Lang: C++
  Description : Arcade game, shoot coloured bubbles

Bubble train is a action puzzle game resembling zuma. Its objective
is to shot coloured bubbles into a moving train of bubbles, building
groups of the same colour. It also includes a level editor.

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.21-2-686 (SMP w/1 CPU core)
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/bash



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

Re: Future Debian package candidate web pages: present and future

[Don Armstrong]

On Sat, 05 Jan 2008, Sebastian Pipping wrote:
> Raphael Geissert wrote:
>> AFAIR the SOAP interface can provide you with such information (refer to 
>> the
>> wiki page).
>
> I'd rather talk to SQL if possible. It's faster and much easier to me.

There's no SQL to talk to. If you want actual accurate data, the SOAP
service is the thing to talk to. [Anything else has various delay
lengths in it before you actually see the data reported.]


Don Armstrong

-- 
An elephant: A mouse built to government specifications.
 -- Robert Heinlein _Time Enough For Love_ p244

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


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

Re: Availability of wanna-build sources

[Luk Claes]

Roger Leigh wrote:
> Hi folks,

Hi Roger

> The wanna-build (sbuild, buildd) sources in use on the Project's
> buildd infrastructure is maintained by Ryan Murray and is available
> From an SVN repository at
> 
>   http://svn.cyberhqz.com/svn/wanna-build
> 
> However, the version number (99.99) displayed in current sbuild logs
> does not reflect the source in the repository, and no commits have
> been made since November 2006.

It's only on some current sbuild logs as that version is experimental.

> Does anyone know where the sources for the current version of
> wanna-build in use on our buildds may be found?

The current version is the one of the repository you mentioned. If you
mean the experimental version, well I suppose that's on one of Ryan's
machines.

Cheers

Luk


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

Re: Future Debian package candidate web pages: present and future

[Nico Golde]

Hi Sebastian,
* Sebastian Pipping <[EMAIL PROTECTED]> [2008-01-06 01:03]:
> Don Armstrong wrote:
> >There's no SQL to talk to. If you want actual accurate data, the SOAP
> >service is the thing to talk to. [Anything else has various delay
> >lengths in it before you actually see the data reported.]
> 
> Where does SOAP get the data from?

http://bugs.debian.org:80/cgi-bin/soap.cgi

Have a look at: http://wiki.debian.org/DebbugsSoapInterface

Kind regards
Nico
-- 
Nico Golde - http://www.ngolde.de - [EMAIL PROTECTED] - GPG: 0x73647CFF
For security reasons, all text in this mail is double-rot13 encrypted.


pgpIlB8UrbG8c.pgp
Description: PGP signature

Re: Future Debian package candidate web pages: present and future

[Sebastian Pipping]

Don Armstrong wrote:

There's no SQL to talk to. If you want actual accurate data, the SOAP
service is the thing to talk to. [Anything else has various delay
lengths in it before you actually see the data reported.]


Where does SOAP get the data from?



Sebastian


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

Re: Future Debian package candidate web pages: present and future

[Sebastian Pipping]

Nico Golde wrote:

http://bugs.debian.org:80/cgi-bin/soap.cgi

Have a look at: http://wiki.debian.org/DebbugsSoapInterface


I guess you misunderstood my question. Again:
Where does SOAP (itself) get the data from?



Sebastian


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

Re: Future Debian package candidate web pages: present and future

[Joerg Jaspert]

On 11256 March 1977, Sebastian Pipping wrote:

>> http://bugs.debian.org:80/cgi-bin/soap.cgi>
>> Have a look at: http://wiki.debian.org/DebbugsSoapInterface
> I guess you misunderstood my question. Again:
> Where does SOAP (itself) get the data from?

Its the BTS itself, so from its data storage. And no, thats not SQL or
something.

-- 
bye Joerg
 HE, we had sex in Debian for many years, yes, before I put a stop
  to it


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

Re: Future Debian package candidate web pages: present and future

[Paul Wise]

On Jan 6, 2008 9:49 AM, Sebastian Pipping <[EMAIL PROTECTED]> wrote:
> Nico Golde wrote:
> > http://bugs.debian.org:80/cgi-bin/soap.cgi
> >
> > Have a look at: http://wiki.debian.org/DebbugsSoapInterface
>
> I guess you misunderstood my question. Again:
> Where does SOAP (itself) get the data from?

The debbugs "database" is a bunch of on-disk files, presumably it gets
the data from there like the rest of debbugs does.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: Proposed consensus: reporting lintian overrides

[Steve McIntyre]

Russ wrote:
>
>Accordingly, I'm going to modify lintian to print out only one line per
>run showing the totals of the overrides for the entire run, on the grounds
>that for more details, well, that's what --show-overrides is for.  I think
>this should make both the "want this" and the "want this but it's noisy"
>folks happy.
>
>For those who really don't want to see this line at all, I'll add a -q
>option to lintian that suppresses this line (and anything else like this
>that comes up later, if we have anything).
>
>Does that sound consistent with the sentiments on the thread to everyone?

That sounds entirely fair, yes. Thanks! :-)

-- 
Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED]
"I've only once written 'SQL is my bitch' in a comment. But that code 
 is in use on a military site..." -- Simon Booth


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

Re: Re: Bug#458819: ITP: nettee -- a network "tee" program

[Joel Franco]

> Out of curiosity, besides being a bit easier to remember/type,
> and not requiring the user to choose a port,
> what benefits over combining normal tee and netcat does it have?
> 
> for example:
> 
> On A:  nettee -in IMAGE -next B -v 31  #full logging
> On B:  nettee -next C >/dev/hda
> On C:  nettee -next D >/dev/hda
> On D:  nettee -next E >/dev/hda
> On E:  nettee -next F >/dev/hda
> On F:  nettee >/dev/hda
> 
> 
> AFAICT, that could be done more or less equivlently as
> On A: nc -q0 B 12345  On B: nc -l 12345 | tee >(nc -q0 C 12345) >/dev/hda
> On C: nc -l 12345 | tee >(nc -q0 D 12345) >/dev/hda
> On D: nc -l 12345 | tee >(nc -q0 E 12345) >/dev/hda
> On E: nc -l 12345 | tee >(nc -q0 F 12345) >/dev/hda
> On F: nc -l 12345 >/dev/hda
> 
> (Some stdout redirections to /dev/null could be added, so stdin on the 
> reciving does not come out as stdout on the sending end.)

Hi Joe,

Good question.

IMHO, i think that the main benefits are:

- simplicity: like you already said, the simple command, without complex
  pipe setups like showed in your example comments. You have to agree
  with me that that netcat + tee pipe commands are not trivial. If I
  had known about that commands, i will not have searched for somenthing
  like nettee in Google.
- multiple target: you can specify multiple targets to send the stream
  and not only one. Use the -next hostlist1(,hostlist2(,hostlist3(...)))
  Ok.. ok.. you can make it with a complex pipe; i just can say that
  i will say again the previous argument.
- error check in the stream data: there is a check for transmission
  errors in the code. This is util when there are failed nodes.
- error handling while data is being transmited: there is a lot of
  options to the chain not die if there is a single node failure. In
  your pipe commands, if one node die, the full chain is lost.

In short, simplicity and error check.

If you liked, can you be my sponsor? :)

-- 
|
| Joel Franco Guzmán  .''`.
|  self-powered by   : :' :
|   Debian Linux `. `' 
|  `- 


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

Re: Future Debian package candidate web pages: present and future

[Don Armstrong]

On Sun, 06 Jan 2008, Sebastian Pipping wrote:
> Don Armstrong wrote:
>> There's no SQL to talk to. If you want actual accurate data, the SOAP
>> service is the thing to talk to. [Anything else has various delay
>> lengths in it before you actually see the data reported.]
>
> Where does SOAP get the data from?

From the exact same place the BTS does; the on-disk files in various
different formats, none of which are SQL databases.

SOAP exposes the actual functions that the BTS itself uses to display
information; if there's something that it doesn't currently do that
you want to, feel free to file wishlist bugs or e-mail me or owner@
(or talk to me on IRC.)


Don Armstrong

-- 
Frankly, if ignoring inane opinions and noisy people and not flaming
them to crisp is bad behaviour, I have not yet achieved a state of
nirvana.
 -- Manoj Srivastava in [EMAIL PROTECTED]

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

Re: Booth at SCALE

[Gareth J. Greenaway]

Any Debian developers who are interested in attending SCALE can use the 
promotional code DBIAN and receive a 50% discount on a full priced ticket.  
Early bird registration ends tonight at midnight, of course the promotional 
code will continue to work.

Thanks.
Gareth

On Sat, 5 Jan 2008 18:56:15 -0800
Blars Blarson <> wrote:

> Debian will have a booth at SCALE (www.socallinuxexpo.org) Feb 8-10.
> As usual, we are orgainizing it on the scd mailing list.
> (domain scd.debian.net)
> 

-- 
Gareth J. Greenaway <[EMAIL PROTECTED]>
Voice - 877-831-2569 x130
Southern California Linux Expo 
http://www.socallinuxexpo.org


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

Bug#459401: ITP: c-repl -- read-eval-print loop for C

[Robert Edmonds]

Package: wnpp
Owner: "Robert S. Edmonds" <[EMAIL PROTECTED]>
Severity: wishlist

* Package name: c-repl
  Version : 0.0.20071223
  Upstream Author : Evan Martin
* URL : http://neugierig.org/software/c-repl/
* License : BSD
  Programming Lang: C, Ruby
  Description : read-eval-print loop for C

 Many programming languages come with a REPL (read-eval-print loop), which
 allows you to type in code line by line and see what it does. This is quite
 useful for prototyping, experimentation, and debugging code.  
 .
 Other programming languages, and especially C, use a "compile-run" model,
 and don't provide a REPL. Let's fix that.
 .
 This approach is actually more of a read-eval loop, as c-repl doesn't know
 anything about the types and parse trees of the code it's running. But
 unlike other approaches to solving the "C interpreter" problem, c-repl
 works directly with unmodified libraries and system headers.  
 .
 This means you can experiment with a new library without writing a test
 program or any bindings. Or just use it as a simple calculator, content in
 knowing it is much faster than your neighbors using irb, like driving a
 Ferarri on city streets.

-- 
Robert Edmonds
[EMAIL PROTECTED]


signature.asc
Description: Digital signature