Bug#394315: ITP: io -- A small, prototype-based programming language

[Kurt B. Kaiser]

Package: wnpp
Severity: wishlist
Owner: "Kurt B. Kaiser" <[EMAIL PROTECTED]>

* Package name: io
  Version : 2006-10-15
  Upstream Author : "Steve Dekorte" <[EMAIL PROTECTED]>
* URL : http://www.iolang.com
* License : BSD
  Programming Lang: C
  Description : A small, prototype-based programming language

 The ideas in Io are mostly inspired by Smalltalk (all values are objects),
 Self (prototype-based), NewtonScript (differential inheritance), Act1 (actors
 and futures for concurrency), LISP (code is a runtime inspectable/modifiable
 tree) and Lua (small, embeddable).

 Open source BSD license
 Small VM (~10K C statements, 5K Io specific)
 Reasonably fast (comparable to Python, Perl, Ruby)
 Incremental collector, weak links
 Dynamic typing
 Exceptions
 C99 implementation
 Embeddable
 Multi-state (multiple VMs can run in the same application)
 Actor-based concurrency, coroutines
 64 bit clean


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

Bug#97500: Zachary says Hi

[Abraham, Zachary]

Our educational counselors are recruiting new people for our home degree 
program.
We are running this program as an experiment and we feel you may qualify.  This 
program will earn you a fully qualified degree, with transcripts.  Currently we 
are recruiting people with vast knowledge or experience in the field/trade of 
their choice.

Give our recruiting office a call when you have time.

Thanks

Zachary Abraham
Office Number: 1-773-509-4920


We hope to be talking to you soon.
*We are taking calls at anytime in the day or evening.


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

Re: Bug mass filling

[Kevin Mark]

On Fri, Oct 20, 2006 at 05:18:41PM -0700, Steve Langasek wrote:
> On Fri, Oct 20, 2006 at 05:37:36PM -0500, Manoj Srivastava wrote:
> > > That's not correct. [serious, grave, and critical] are the "release
> > > critical" severities, though some release critical issues won't be
> > > fixed for any given release, due to either being not known about or
> > > understood (ie, not filed at all, or not given the appropriate
> > > severity or attention), or given a specific exemption by the release
> > > team ("etch-ignore").
> 
> > So riddle me this: currently, policy states that violating a
> >  "must" or "required" directive in policy is a serious bug; which
> >  seems to fly in the face of the release process having appropriated
> >  the "serious" severity.
> 
> > Are we removing the policy that violations of policy
> >  requirements are serious bugs?  Is there new guidance on what policy
> >  violation bug severities ought to be?  Are such bugs to be filed
> >  under "normal"? Or "important"?
> 
> > My understanding, which seems to be flawed, was policy
> >  violations were taken seriously (heh),  and policy violation meant to
> >  be ignored for a release were granted special dispensation (remained
> >  serious, but were exempt).
> 
> > If this is not the case, we should change the policy, and drop
> >  any reference to bug severities for packages violating policy.
> >  Personally, think that is not a good idea, since adherence to
> >  technical policy seems to be the underpinning of the high quality of
> >  implementation we always had, but perhaps my mileage has varied.
> 
> When there are issues addressed in policy that are black-and-white where all
> violations of the policy requirement are definitely bugs, but not all such
> violations should be grounds for keeping a package out of a release, how do
> you suggest such rules should be handled in the normative language of
> policy, and how do you suggest that the related bugs be handled in the BTS?
> How should we distinguish this case from rules that are *generally* but not
> always an indication of a bug (policy's description of "should"), and from
> one-time exception grants by the release team (the current use of the
> "-ignore" tag)?
> 
> The current handling sanctioned by the BTS admins seems an appropriate
> middle ground for distinguishing the cases that are most relevant to bug
> handling across releases.
> 
Hi Steve,
One of Debian's principal attributes is openness, as with all FLOSS
projects. With each release, would it useful to have, in addition to the
Release notes, a _document_ like this:

$RELEASE_NAME-ignore list:
===
PACKAGE|BUG NUMBER|BUG DESCIPTION  |REASON FOR IGNORING 
ISSUE[|OPTIONAL_NAME|OPTIONAL_DATE]
foo| 1234 | deletes db on mips | no one uses it on mips   | joe RM  
| 01-01-1969
foo| 1234 | deletes db on mips | happens only on sundays  | jane RM 
| 01-02-1969
===

so that users, sysadmin and such could see what issue may affect them.

Similarly,
this document could _first_ be started as a _wiki page_ which could be
generated from the current BTS info and during the release the RM's
could have a location where they can state their reasons and then the
package maintainer can have a centralized place for this info and an
easy way to see and comment upon it.

Because it seems that release issues between package maintainers and
release managers happens in various place and have conflicting or subtly
different answers depending upon person asked, when asked, etc. So a
solid single point of update would seem to at least address some of this
so that if 2 people or RM's give what seems to be confusing or
contradictory info, it would have a single place to reference, where
this would be easily seen by all involved.
happy cat hurding,
Kev
-- 
|  .''`.  == Debian GNU/Linux == |   my web site:   |
| : :' :  The  Universal | debian.home.pipeline.com |
| `. `'  Operating System| go to counter.li.org and |
|   `-http://www.debian.org/ |be counted! #238656   |
| my keysever: pgp.mit.edu   | my NPO: cfsg.org |


signature.asc
Description: Digital signature

Re: Lots of (easily recognisible) spam sent to the BTS today

[Don Armstrong]

On Fri, 20 Oct 2006, Kevin Mark wrote:
> On Sat, Oct 21, 2006 at 12:05:58AM +0200, Javier Fernández-Sanguino Peña 
> wrote:
> > I'm not sure if anybody else is seeing this but I have seen (just today) 28
> > spam messages sent to the BTS. I've received them because they were all sent
> 
> I've seen BTS spam before and ask the list admins about it.
> 
> > to (at least) the 'www.debian.org' pseudo-package, and I have reported all 
> > of
> > them in the BTS' spam interface [1]
> > 
> > They also seem to share common carachteristics:
> > 
> > a) Subject fits the regexp: ".* note|letter|message\. You .* read\."
> > b) The MTA it claims to be: "X-Mailer: Microsoft Office Outlook, Build 
> > 11.0.*"
> 
> I've seen this X-Mailer Header used with recent spam. Is this a 'real'
> used mailer, if not, it maybe an easy regex to stop this spam.

Yes... this regex has already been added.
 
> > c) The first two lines of the body fit these regexps:
> > 
> > The great .* are .*\.
> > The increase is up to 70%.*
> > 
> > I'm pretty sure this spam has probably found a place in many other BTS
> > entries, I was just wondering if the BTS admins have noticed and placed
> > appropiate measures in place (I'm sure they have, but just in case).
> > #101772, #102186, #101772, #101870, #180196, #180118
> 
> Does BTS mail have identifiable header and/or body characteristics
> to determine what is legitimate? Does all mail to the bts come from:
> debian.org mailers, reportbugs or some identifable sources that
> would make legitimate email identifable?

The messages which do have such identifiable characterestics already
have them in place; messages sent to nnn-done@ and nnn@ have no such
requirements, though.

In general, just clicking on the report spam links are good enough; in
cases like this where large amounts of spam have been crafted which
beat the extant rules, Blars Blarson (and to a lesser degree the other
BTS admins, including myself) generally rapidly notice it and deal
appropriately. [When we haven't, just send a note to [EMAIL PROTECTED] and
someone will deal with it.]


Don Armstrong

-- 
Unix, MS-DOS, and Windows NT (also known as the Good, the Bad, and
the Ugly).
 -- Matt Welsh

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

Re: Bug mass filling

[Steve Langasek]

On Fri, Oct 20, 2006 at 05:37:36PM -0500, Manoj Srivastava wrote:
> > That's not correct. [serious, grave, and critical] are the "release
> > critical" severities, though some release critical issues won't be
> > fixed for any given release, due to either being not known about or
> > understood (ie, not filed at all, or not given the appropriate
> > severity or attention), or given a specific exemption by the release
> > team ("etch-ignore").

> So riddle me this: currently, policy states that violating a
>  "must" or "required" directive in policy is a serious bug; which
>  seems to fly in the face of the release process having appropriated
>  the "serious" severity.

> Are we removing the policy that violations of policy
>  requirements are serious bugs?  Is there new guidance on what policy
>  violation bug severities ought to be?  Are such bugs to be filed
>  under "normal"? Or "important"?

> My understanding, which seems to be flawed, was policy
>  violations were taken seriously (heh),  and policy violation meant to
>  be ignored for a release were granted special dispensation (remained
>  serious, but were exempt).

> If this is not the case, we should change the policy, and drop
>  any reference to bug severities for packages violating policy.
>  Personally, think that is not a good idea, since adherence to
>  technical policy seems to be the underpinning of the high quality of
>  implementation we always had, but perhaps my mileage has varied.

When there are issues addressed in policy that are black-and-white where all
violations of the policy requirement are definitely bugs, but not all such
violations should be grounds for keeping a package out of a release, how do
you suggest such rules should be handled in the normative language of
policy, and how do you suggest that the related bugs be handled in the BTS?
How should we distinguish this case from rules that are *generally* but not
always an indication of a bug (policy's description of "should"), and from
one-time exception grants by the release team (the current use of the
"-ignore" tag)?

The current handling sanctioned by the BTS admins seems an appropriate
middle ground for distinguishing the cases that are most relevant to bug
handling across releases.

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


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

Bug#62878: Tyler says Hi

[Lam, Tyler]

Our educational counselors are recruiting new people for our home degree 
program.
We are running this program as an experiment and we feel you may qualify.  This 
program will earn you a fully qualified degree, with transcripts.  Currently we 
are recruiting people with vast knowledge or experience in the field/trade of 
their choice.

Give our recruiting office a call when you have time.

Thanks

Tyler Lam
Office Number: 1-773-509-4920


We hope to be talking to you soon.
*We are taking calls at anytime in the day or evening.



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

Re: Lots of (easily recognisible) spam sent to the BTS today

[Kevin Mark]

Hi Javier,
On Sat, Oct 21, 2006 at 12:05:58AM +0200, Javier Fernández-Sanguino Peña wrote:
> 
> I'm not sure if anybody else is seeing this but I have seen (just today) 28
> spam messages sent to the BTS. I've received them because they were all sent

I've seen BTS spam before and ask the list admins about it.

> to (at least) the 'www.debian.org' pseudo-package, and I have reported all of
> them in the BTS' spam interface [1]
> 
> They also seem to share common carachteristics:
> 
> a) Subject fits the regexp: ".* note|letter|message\. You .* read\."
> b) The MTA it claims to be: "X-Mailer: Microsoft Office Outlook, Build 11.0.*"

I've seen this X-Mailer Header used with recent spam. Is this a 'real'
used mailer, if not, it maybe an easy regex to stop this spam.

> c) The first two lines of the body fit these regexps:
> 
> The great .* are .*\.
> The increase is up to 70%.*
> 
> I'm pretty sure this spam has probably found a place in many other BTS
> entries, I was just wondering if the BTS admins have noticed and placed
> appropiate measures in place (I'm sure they have, but just in case).
> #101772, #102186, #101772, #101870, #180196, #180118

Does BTS mail have identifiable header and/or body characteristics to
determine what is legitimate? Does all mail to the bts come from: debian.org
mailers, reportbugs or some identifable sources that would make
legitimate email identifable?
cheers,
Kev
-- 
|  .''`.  == Debian GNU/Linux == |   my web site:   |
| : :' :  The  Universal | debian.home.pipeline.com |
| `. `'  Operating System| go to counter.li.org and |
|   `-http://www.debian.org/ |be counted! #238656   |
| my keysever: pgp.mit.edu   | my NPO: cfsg.org |


signature.asc
Description: Digital signature

Re: Bug mass filling

[Manoj Srivastava]

On Sat, 21 Oct 2006 06:27:24 +1000, Anthony Towns  
said: 

> On Fri, Oct 20, 2006 at 04:06:05AM -0500, Manoj Srivastava wrote:
>> > Even then, it's only "serious" if it violates the release policy
>> > [http://release.debian.org/etch_rc_policy.txt]. Hence the reason
>> > that
>> No. A bug may be serious and yet not RC, as I understand it.

> That's not correct. [serious, grave, and critical] are the "release
> critical" severities, though some release critical issues won't be
> fixed for any given release, due to either being not known about or
> understood (ie, not filed at all, or not given the appropriate
> severity or attention), or given a specific exemption by the release
> team ("etch-ignore").

So riddle me this: currently, policy states that violating a
 "must" or "required" directive in policy is a serious bug; which
 seems to fly in the face of the release process having appropriated
 the "serious" severity.

Are we removing the policy that violations of policy
 requirements are serious bugs?  Is there new guidance on what policy
 violation bug severities ought to be?  Are such bugs to be filed
 under "normal"? Or "important"?

My understanding, which seems to be flawed, was policy
 violations were taken seriously (heh),  and policy violation meant to
 be ignored for a release were granted special dispensation (remained
 serious, but were exempt).

If this is not the case, we should change the policy, and drop
 any reference to bug severities for packages violating policy.
 Personally, think that is not a good idea, since adherence to
 technical policy seems to be the underpinning of the high quality of
 implementation we always had, but perhaps my mileage has varied.

manoj
-- 
The happiest time of a person's life is after his first
divorce. J.K. Galbraith
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Bug mass filling

[Andreas Barth]

* Aurelien Jarno ([EMAIL PROTECTED]) [061021 00:37]:
> Anthony Towns a écrit :
> >On Thu, Oct 19, 2006 at 03:06:04PM +0200, Aurelien Jarno wrote:
> >>Maybe some errors (E:) of lintian could be changed to critical (C:) and
> >>uploads containing such critical errors be refused by dak? What do you
> >>think?
> >
> >AFAIK dak doesn't support this? Does "C:" exist?
> 
> No AFAIK dak doesn't support that. It was actually a suggestion, I don't 
> know if it is easy to add. C: also does not exists, but it's really easy 
> to implement in lintian. Anyway which bugs are errors (E:) or critical 
> (C:) has to be decided in accordance with the release team.
> 
> My idea with an automated test at upload is that we can use the time 
> used to find such policy violations to find more complex bugs, and 
> therefore improve the quality of the distribution.

That sounds like a worthwhile idea to me - one of the first things we
should do post-etch probably.


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


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

Re: Bug mass filling

[Aurelien Jarno]

Anthony Towns a écrit :

On Thu, Oct 19, 2006 at 03:06:04PM +0200, Aurelien Jarno wrote:

Maybe some errors (E:) of lintian could be changed to critical (C:) and
uploads containing such critical errors be refused by dak? What do you
think?


AFAIK dak doesn't support this? Does "C:" exist?


No AFAIK dak doesn't support that. It was actually a suggestion, I don't 
know if it is easy to add. C: also does not exists, but it's really easy 
to implement in lintian. Anyway which bugs are errors (E:) or critical 
(C:) has to be decided in accordance with the release team.


My idea with an automated test at upload is that we can use the time 
used to find such policy violations to find more complex bugs, and 
therefore improve the quality of the distribution.



Among all of the bugs reported by lintian, one concerns a lot of
packages, the presence of the clean, binary, binary-arch, binary-indep 
and build targets. This is required by both the section 4.9 of the

policy and the Etch release standards [1]. Here is the list of affected
packages. What to do with them?


Please hold off on filing them for a few days, so I can add
usertag-on-submit support to debbugs, so that it should be possible to
automatically track this stuff, and easily avoid filing duplicate bugs
if they're not fixed the next time bugs get filed.


Ok, please let me know when it's ready.

Bye,
Aurelien

--
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian developer   | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.net


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

Does anybody know where Janez Rabzelj Zappone is?

[Carlos Martín Nieto]

Hi,

 I ask because he took (or was going to anyway) maintainership of the
package blam, but this was about a month ago and no new version has been
uploaded.

 I sent him an e-mail a few days ago but he hasn't replied. There is
already a package ready which fixes at least two of the RC bugs, and
perhaps another or two as a side-effect.

 I'm not looking forward to hijacking a package, but with four RC bugs
and the release of etch closing in, I don't see another way to include
it in etch.

 So, if anybody knows that he is working on it, please speak up,
otherwise I will be requesting a sponsor for an updated blam package.

 TIA,

   cmn
-- 
Carlos Martín Nieto|   http://www.cmartin.tk
Hobbyist programmer|



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

Getting rid of circular dependencies, stage 6

[Bill Allombert]

Hello Debian developers,

Thanks to your collective effort, the number of circular dependencies in
Debian has halved since the begining of the year.

Here the lists of packages involved in circular dependencies listed by
maintainers.

This list is also available at

(update daily, courtesy of Robert Lemmen).

A list of dependencies including dependency graphs is available at


The list of bug I reported so far is there:


- - - - - - - - - - - - - - - - - - -

Adeodato Simó <[EMAIL PROTECTED]>
amarok
amarok-engines
amarok-xine

Alastair McKinstry <[EMAIL PROTECTED]>
console-common

Andrew Mitchell <[EMAIL PROTECTED]>
phpgroupware
phpgroupware-admin
phpgroupware-phpgwapi
phpgroupware-preferences
phpgroupware-setup

Bernd Schumacher <[EMAIL PROTECTED]>
bootcd
bootcd-hppa
bootcd-i386
bootcd-ia64

Brendan O'Dea <[EMAIL PROTECTED]>
perl
perl-modules

Carlo Contavalli <[EMAIL PROTECTED]>
wipl-client-exec
wipl-client-standard
wipl-daemon

Christian T. Steigies <[EMAIL PROTECTED]>
luola
luola-data
luola-levels

Console utilities maintainers <[EMAIL PROTECTED]>
kbd

Daniel Burrows <[EMAIL PROTECTED]>
heroes-common
heroes-ggi
heroes-sdl
lbreakout2
lbreakout2-data

David Coe <[EMAIL PROTECTED]>
iamerican
ispell

David Moreno Garza <[EMAIL PROTECTED]>
gxmms-bmp
gxmms-common
gxmms-xmms
playground
playground-plugin-xmms

Debconf Developers <[EMAIL PROTECTED]>
debconf
debconf-english
debconf-i18n

Debian GCC Maintainers 
g++-3.3
g++-3.4
g++-4.0
g++-4.1
gcj-4.1
libgcj7-dev
libstdc++5-3.3-dev
libstdc++6-4.0-dev
libstdc++6-4.1-dev
libstdc++6-dev

Debian GCC maintainers 
g++-2.95
libstdc++2.10-dev

Debian GGZ Maintainers <[EMAIL PROTECTED]>
ggz-gtk-games
ggz-gtk-games-data
ggz-kde-games
ggz-kde-games-data
ggz-sdl-games
ggz-sdl-games-data

Debian Games Team <[EMAIL PROTECTED]>
abuse
abuse-frabs
abuse-lib

Debian Italian Maintainers Task Force <[EMAIL PROTECTED]>
festlex-ifd
festvox-italp16k
festvox-itapc16k

Debian Java Maintainers 
antlr
eclipse-jdt
eclipse-jdt-common
gjdoc
kaffe
kaffe-jthreads
kaffe-pthreads
libswt3.1-gtk-java
libswt3.1-gtk-jni

Debian Java maintainers 
libgnome-java
libgnome-jni

Debian Mono Group <[EMAIL PROTECTED]>
libmono-security2.0-cil
libmono-system2.0-cil

Debian PHP Maintainers <[EMAIL PROTECTED]>
php5-mysql
php5-mysqli

Debian QA Group <[EMAIL PROTECTED]>
gnome-bin
gnome-libs-data
libgnome32
libgnomesupport0
libgnomeui32
libgnorba27

Debian Qt/KDE Maintainers 
libkcal2b
libkdepim1a
libqt4-gui
libqt4-qt3support

Debian VoIP Team <[EMAIL PROTECTED]>
asterisk
asterisk-bristuff
asterisk-classic

Debian X Strike Force 
libx11-dev
libxext-dev
xserver-xorg
xserver-xorg-core
xserver-xorg-input-all
xserver-xorg-input-evdev
xserver-xorg-input-kbd
xserver-xorg-input-mouse
xserver-xorg-video-all
xserver-xorg-video-apm
xserver-xorg-video-ark
xserver-xorg-video-ati
xserver-xorg-video-chips
xserver-xorg-video-cirrus
xserver-xorg-video-cyrix
xserver-xorg-video-dummy
xserver-xorg-video-fbdev
xserver-xorg-video-glint
xserver-xorg-video-i128
xserver-xorg-video-i740
xserver-xorg-video-i810
xserver-xorg-video-imstt
xserver-xorg-video-mga
xserver-xorg-video-neomagic
xserver-xorg-video-newport
xserver-xorg-video-nsc
xserver-xorg-video-nv
xserver-xorg-video-rendition
xserver-xorg-video-s3
xserver-xorg-video-s3virge
xserver-xorg-video-savage
xserver-xorg-video-siliconmotion
xserver-xorg-video-sis
xserver-xorg-video-sisusb
xserver-xorg-video-tdfx
xserver-xorg-video-tga
xserver-xorg-video-trident
xserver-xorg-video-tseng
xserver-xorg-video-v4l
xserver-xorg-video-vesa
xserver-xorg-video-vga
xserver-xorg-video-via
xserver-xorg-video-vmware
xserver-xorg-video-voodoo

Denis Barbier <[EMAIL PROTECTED]>
belocs-locales-bin
belocs-locales-data

Guenter Geiger (Debian/GNU) <[EMAIL PROTECTED]>

Lots of (easily recognisible) spam sent to the BTS today

[Javier Fernández-Sanguino Peña]

I'm not sure if anybody else is seeing this but I have seen (just today) 28
spam messages sent to the BTS. I've received them because they were all sent
to (at least) the 'www.debian.org' pseudo-package, and I have reported all of
them in the BTS' spam interface [1]

They also seem to share common carachteristics:

a) Subject fits the regexp: ".* note|letter|message\. You .* read\."
b) The MTA it claims to be: "X-Mailer: Microsoft Office Outlook, Build 11.0.*"
c) The first two lines of the body fit these regexps:

The great .* are .*\.
The increase is up to 70%.*

I'm pretty sure this spam has probably found a place in many other BTS
entries, I was just wondering if the BTS admins have noticed and placed
appropiate measures in place (I'm sure they have, but just in case).

Regards

Javier

[1] In Bugs #184006, #183585, #189173, #189157, #188865, #188617, #100363,
#99160, #193540, #193106, #177897, #177523, #258918, #263535, #180196,
#180118, #10520, #103975, #182337, #182700, #151147, #150474, #153701,
#153644, #204105, #203950, #182773, #183585, #177215, #177200, #99156,
#98811, #99438, #99160, #131338, #130325, #168601, #168695, #152955, #152609,
#118834, #118592, #100148, #100148, #197674, #197392, #147575, #147164,
#101772, #102186, #101772, #101870, #180196, #180118


signature.asc
Description: Digital signature

Re: Bug mass filling

[Anthony Towns]

On Thu, Oct 19, 2006 at 03:06:04PM +0200, Aurelien Jarno wrote:
> Maybe some errors (E:) of lintian could be changed to critical (C:) and
> uploads containing such critical errors be refused by dak? What do you
> think?

AFAIK dak doesn't support this? Does "C:" exist?

> Among all of the bugs reported by lintian, one concerns a lot of
> packages, the presence of the clean, binary, binary-arch, binary-indep 
> and build targets. This is required by both the section 4.9 of the
> policy and the Etch release standards [1]. Here is the list of affected
> packages. What to do with them?

Please hold off on filing them for a few days, so I can add
usertag-on-submit support to debbugs, so that it should be possible to
automatically track this stuff, and easily avoid filing duplicate bugs
if they're not fixed the next time bugs get filed.

Cheers,
aj


signature.asc
Description: Digital signature

Re: Bug mass filling

[Anthony Towns]

On Fri, Oct 20, 2006 at 04:06:05AM -0500, Manoj Srivastava wrote:
> > Even then, it's only "serious" if it violates the release policy
> > [http://release.debian.org/etch_rc_policy.txt]. Hence the reason
> > that
> No. A bug may be serious and yet not RC, as I understand it.

That's not correct. [serious, grave, and critical] are the "release
critical" severities, though some release critical issues won't be
fixed for any given release, due to either being not known about or
understood (ie, not filed at all, or not given the appropriate severity
or attention), or given a specific exemption by the release team
("etch-ignore").

Cheers,
aj



signature.asc
Description: Digital signature

Bug#394249: ITP: inotify-tools -- A set of command-line programs providing a simple interface to inotify

[Peter Makholm]

Package: wnpp
Severity: wishlist
Owner: Peter Makholm <[EMAIL PROTECTED]>


* Package name: inotify-tools
  Version : 2.6
  Upstream Author : Rohan McGovern <[EMAIL PROTECTED]>
* URL : http://inotify-tools.sourceforge.net/
* License : GPL
  Programming Lang: C
  Description : A set of command-line programs providing a simple interface 
to inotify

inotify-tools is a set of command-line programs for Linux providing a
simple interface to inotify. These programs can be used to monitor and
act upon filesystem events. inotify-tools consists of two utilities:

- inotifywait simply blocks for inotify events, making it appropriate
  for use in shell scripts.

- inotifywatch collects filesystem usage statistics and outputs counts
  of each inotify event.


-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17-2-xen-amd64
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)


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

Re: gcc-4.2 build-depends?

[Aaron M. Ucko]

[EMAIL PROTECTED] writes:

> here. Also, the same solution should be used (eg. split the
> package).

The gcc-4.x packages are already set up to support building the Java
and Ada compilers (and associated libraries) separately from the rest
of GCC; however, there is no need to do so for 4.2 while it is still
only in experimental.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.


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

Re: Question regarding maintainer email

[Petter Reinholdtsen]

[Rafael Laboissiere]
> Moderating has the great advantage of reducing spam in the list.

Yeah.  And if you get a lot of spam to the list, using the listadmin
script make it a lot easier to process through the moderation
requests.  One of the list I moderate get 200 spam a day, and I would
never have been able to moderate it if it wasn't for the listadmin
package.

Friendly,
-- 
Petter Reinholdtsen


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

Re: Question regarding maintainer email

[Matthias Julius]

Rafael Laboissiere <[EMAIL PROTECTED]> writes:

> As regards bouncing, we recognize that receiving an automated message is not
> the suitable behavior.  On the other hand, not receiving anything and not
> seeing the message in the list archives is even worse.  We decided then to
> suppress bouncing and also to be very reactive as regards the moderation.
> We have two moderators for each list and we try to insure that one of them,
> at least, will always be available for prompt moderation. As a courtesy to
> bug reporters, when we accept messages we systematically add the sender to
> the list of people allowed to post.

Since all bug reports come via bugs.debian.org can't you just let in
all messages that come through b.d.o?

Matthias


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

Bug#394223: ITP: cl-cffi -- The Common Foreign Function Interface for Common Lisp

[Peter Van Eynde]

Package: wnpp
Severity: wishlist
Owner: Peter Van Eynde <[EMAIL PROTECTED]>

* Package name: cl-cffi
  Version : 20061013
  Upstream Author : James Bielman
* URL : http://common-lisp.net/project/cffi/
* License : BSD
  Programming Lang: Common Lisp
  Description : The Common Foreign Function Interface for Common Lisp

 CFFI, the Common Foreign Function Interface, purports to be a portable foreign
 function interface for Common Lisp. The CFFI library is composed of a
 Lisp-implementation-specific backend in the CFFI-SYS package, and a portable
 frontend in the CFFI package.
 .
 The CFFI-SYS backend package defines a low-level interface to the native FFI
 support in the Lisp implementation. It offers operators for allocating and
 dereferencing foreign memory, calling foreign functions, and loading shared
 libraries. The CFFI frontend provides a declarative interface for defining
 foreign functions, structures, typedefs, enumerated types. It is implemented
 in portable ANSI CL making use of the low-level operators exported by
 CFFI-SYS.
 .
 A UFFI compatibility layer is also being developed.
 .
 Homepage: http://common-lisp.net/project/cffi/


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


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

Re: Question regarding maintainer email

[Rafael Laboissiere]

* Ben Finney <[EMAIL PROTECTED]> [2006-10-17 09:33]:

> Bill Allombert <[EMAIL PROTECTED]> writes:
> 
> > Something I have yet to understand is what purposes the bounce [from
> > a moderated list] serve in the first place. Moderating is OK, but
> > bouncing ?
> 
> I read many mailing lists (this one, for example) without being
> subscribed as a member.
> 
> An automated message saying "Your post to the list, unlike many
> others, will be delayed until a human acts" tells me that I shouldn't
> get anxious at the non-appearance of my message on the list. Without
> such a message, many people would believe their message was eaten
> somewhere, and post it again and again.

Moderating has the great advantage of reducing spam in the list.  We have
used this setting for the mailing lists of the Debian Octave Group at
Alioth from the beginning and we are not willing to change it.

As regards bouncing, we recognize that receiving an automated message is not
the suitable behavior.  On the other hand, not receiving anything and not
seeing the message in the list archives is even worse.  We decided then to
suppress bouncing and also to be very reactive as regards the moderation.
We have two moderators for each list and we try to insure that one of them,
at least, will always be available for prompt moderation. As a courtesy to
bug reporters, when we accept messages we systematically add the sender to
the list of people allowed to post.

IMHO, if doing like delineated above, then it is totally acceptable to have
mailing lists as maintainer addresses.

-- 
Rafael


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

Bug#394161: ITP: cl-plus-ssl -- A simple Common Lisp interface to OpenSSL

[Peter Van Eynde]

Package: wnpp
Severity: wishlist
Owner: Peter Van Eynde <[EMAIL PROTECTED]>

* Package name: cl-plus-ssl
  Version : 20060904
  Upstream Author : various
* URL : http://common-lisp.net/project/cl-plus-ssl/
* License : Lisp LGPL
  Programming Lang: Common Lisp
  Description : A simple Common Lisp interface to OpenSSL

 This library is a fork of SSL-CMUCL. The main differences are
 that this library uses protable code based on cffi and gray
 streams. With this it defined a libssl BIO portable lisp
 streams based IO.
 .
 Homepage: http://common-lisp.net/project/cl-plus-ssl/


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


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

Bug#394163: ITP: cl-hunchentoot -- The Common Lisp web server formerly known as TBNL

[Peter Van Eynde]

Package: wnpp
Severity: wishlist
Owner: Peter Van Eynde <[EMAIL PROTECTED]>

* Package name: cl-hunchentoot
  Version : 0.4.4
  Upstream Author : Dr. Edmund Weitz
* URL : http://weitz.de/hunchentoot/
* License : BSD
  Programming Lang: Common Lisp
  Description : The Common Lisp web server formerly known as TBNL

 Hunchentoot is a web server written in Common Lisp and at the same time a
 toolkit for building dynamic websites. As a stand-alone web server, Hunchentoot
 is capable of HTTP/1.1 chunking (both directions), persistent connections
 (keep-alive), and SSL, but it can also sit behind the popular Apache using Marc
 Battyani's mod_lisp.
 .
 Hunchentoot provides facilities like automatic session handling (with and
 without cookies), logging (to Apache's log files or to a file in the file
 system), customizable error handling, and easy access to GET and POST
 parameters sent by the client. It does not include functionality to
 programmatically generate HTML output. For this task you can use any library
 you like, e.g. (shameless self-plug) CL-WHO or HTML-TEMPLATE.
 .
 Homepage: http://weitz.de/hunchentoot/

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


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

Bug#394171: ITP: cl-trivial-https -- a fork of trivial-http with https support

[Peter Van Eynde]

Package: wnpp
Severity: wishlist
Owner: Peter Van Eynde <[EMAIL PROTECTED]>

* Package name: cl-trivial-https
  Version : 20051125
  Upstream Author : Brian Mastenbrook / David Lichteblau
* URL : http://common-lisp.net/project/cl-plus-ssl/
* License : BSD
  Programming Lang: Common Lisp
  Description : a fork of trivial-http with https support

 https support is added using cl-plus-ssl. trivial-http is a trivial networking
 library for doing HTTP POST and GET (web client operations) over
 a socket interface.
 .
 Homepage: http://common-lisp.net/project/cl-plus-ssl/

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


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

Re: Bug mass filling

[Miriam Ruiz]

Why don't we all try to calm down and get less paranoid?

I don't think anyone's trying to piss off anyone, so I think we should all try
to take it less personal. We probably all have different priorities, different
goals and different ideas on how to achieve them, and I don't think anyone's
making proposals, asking questions or giving anwers with the purpose of making
anyone feel bad, that would be too presumptuous to think.

I'm lately seeing too many people getting so upset as to orphan their
packages, leave the project, too many insults everywhere or getting paranoid
about every single suggestion it is made. I think most of that is just caused
by the nerves, and after the release everythink will calm down.

Most of us are nice people with just strong feelings about their ideas, but I
guess it might be nice for all of us to learn how to empathyse and respect
other's ideas, and think for a moment that other people might also good
reasons for them, as not everything is black or white.

Miry




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


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

Bug#394138: ITP: vmware-package -- utility for building Vmware related Debian packages

[Marc Haber]

Package: wnpp
Severity: wishlist
Owner: Marc Haber <[EMAIL PROTECTED]>

* Package name: vmware-package
  Version : 0.0
  Upstream Author : Marc Haber <[EMAIL PROTECTED]>
* URL : none yet
* License : GPL
  Programming Lang: shell
  Description : utility for building Vmware related Debian packages

This package provides the capability to create Debian packages for
various VMware products and related software by obtaining VMware
tarballs and then just running make-vmpkg.

It can currently build Debian packages for the following VMware and
VMware related products:

  * VMware kernel modules for Linux, using the vmware-any-any tarball

It is planned to extend make-vmkg to build Debian packages for the
following VMware products:

  * VMware Player 1.0.2

Please note that you need to download the corresponding tarballs
yourself, and that the resulting .deb files are non-free and
non-distributeable.

The package is meant to aid a local admin to roll out VMware products
to their local systems by means of the packaging system.

Greetings
Marc


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

Re: Bug mass filling

[Manoj Srivastava]

On Thu, 19 Oct 2006 18:49:09 +0100, Adam D Barratt <[EMAIL PROTECTED]> said: 

> On Thu, 2006-10-19 at 10:00 -0700, Kevin B. McCarty wrote:
>> Tshepang Lekhonkhobe wrote:
>> 
>> > Doesn't policy violation warrant Critical severity?
>> 
>> No, it "only" warrants the lowest RC severity, serious [0], unless
>> the bug in addition makes the package or other software (mostly)
>> unusable, causes data loss, or introduces a security hole.

> Even then, it's only "serious" if it violates the release policy
> [http://release.debian.org/etch_rc_policy.txt]. Hence the reason
> that

No. A bug may be serious and yet not RC, as I understand it.

manoj

-- 
A hacker does for love what others would not do for money.
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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