Re: Getting rid of circular dependencies, stage 6

[Petter Reinholdtsen]

[Ian Jackson]
> The only argument I've heard against circular dependencies as a
> general rule is that they can trigger a particularly stupid (and
> probably not very hard to fix) bug in apt,

You seem to have missed the argument that packages with circular
dependencies are impossible to install and configure in the correct
(dependency) order, and thus will end up being installed and
configured in a nondeterministic order instead.  It is documented that
dpkg try its best to find a sensible order for the packages, but it is
bound to fail one way or another if two packages really do need each
other to be configured before they are configured.

I'm not sure if missed this argument, choose to ignore it, or do not
consider it an argument, so I thought it best to repeat it in case you
missed it.

Friendly,
-- 
Petter Reinholdtsen


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

Re: arches and etch

[Reinhard Tartler]

Goswin von Brederlow <[EMAIL PROTECTED]> writes:

> So to see a difference for the smaller archs the upgrade should
> ask. 

The only clean way to do this is IMO a dedicated upgrader tool. This
tool could then have special rules for the following issues:

  * known strange dependency changes like 
- changes in the priority of packages, 
- changed dependencies of Priority required/essential packages,
  * known and often installed 3rd party packages like marillats 
acroread package (remove them if they get in the way 'official'
debian packages)
  * forced downgrade of specific packages, which many users have updated
by well known and broken 3rd party repositories (mesa related packages
from beryl/compiz repositories)
  * obey a special order of package upgrades when dist-upgrading. (think
of the perl-doc related foo while upgrading from woody to sarge)
  * remove or add new system groups (think of the famous plugdev group)
  * ask the user if he want local users added to the new groups

and of course
  * ask the admin if he wants to participate in pocon

This is of course an etch+1 thing, and really specific for a given
release.

You can of course imagine that these ideas don't come out of the
blue. In fact, such a tool is already deployed in ubuntu. I think we
could port it to debian as well, if enough people see a need for it.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4


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

Re: RFP: tinymce -- Web based Javascript HTML WYSIWYG editor

[Alexis Sukrieh]

* Kjetil Kjernsmo ([EMAIL PROTECTED]) :
> * Package name: tinymce
[...]
> The TinyMCE is a collection of JavaScripts that make up a HTML WYSIWYG
> editor that can be attached to any TEXTAREA of a HTML page. It is
> widely used, in fact it is allready in multiple copies in Debian.
[...]
> I would therefore suggest splitting TinyMCE into a package of its
> own. Unfortunately, I'm not a DD myself.

Kjetil Kjernsmo wrote:
> The TinyMCE is a collection of JavaScripts that make up a HTML WYSIWYG
> editor that can be attached to any TEXTAREA of a HTML page. It is
> widely used, in fact it is allready in multiple copies in Debian.
[...]
> I would therefore suggest splitting TinyMCE into a package of its
> own. Unfortunately, I'm not a DD myself.

It sounds interesting IMHO, and I could sponsor you if you want to become
responsible of that package.

I would also suggest to package it with the Webapps Policy DRAFT in mind[1].

Feel free to contact me if you have a package to review or want some help
regarding the packaging.

Cheers,

1: http://people.debian.org/~neilm/webapps-policy

-- 
Alexis Sukrieh <[EMAIL PROTECTED]>
0x1EE5DD34
Debian   http://www.debian.org
Backup Manager   http://www.backup-manager.org


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

Re: RFP: tinymce -- Web based Javascript HTML WYSIWYG editor

[Kjetil Kjernsmo]

On Tuesday 24 October 2006 10:23, Alexis Sukrieh wrote:
> > I would therefore suggest splitting TinyMCE into a package of its
> > own. Unfortunately, I'm not a DD myself.
>
> It sounds interesting IMHO, and I could sponsor you if you want to
> become responsible of that package.

Well, I do more and more package building these days, but I haven't had 
time to read the policy documents yet, and each time I try to set aside 
time, a disk dies or something. So it is on my agenda, but right now, 
it doesn't seem like I'll have the time before etch is due out... So, I 
don't know...

Cheers,

Kjetil


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

Re: Getting rid of circular dependencies, stage 6

[Don Armstrong]

On Tue, 24 Oct 2006, Petter Reinholdtsen wrote:
> [Ian Jackson]
> > The only argument I've heard against circular dependencies as a
> > general rule is that they can trigger a particularly stupid (and
> > probably not very hard to fix) bug in apt,
> 
> You seem to have missed the argument that packages with circular
> dependencies are impossible to install and configure in the correct
> (dependency) order, and thus will end up being installed and
> configured in a nondeterministic order instead. It is documented
> that dpkg try its best to find a sensible order for the packages,
> but it is bound to fail one way or another if two packages really do
> need each other to be configured before they are configured.

Packages which have circular dependencies and depend on the other
package being configured are buggy; at most they can depend on the
other package being unpacked. Since there is no way to specify this
kind of dependency, Depends: is as close as you can get.


Don Armstrong

-- 
It has always been Debian's philosophy in the past to stick to what
makes sense, regardless of what crack the rest of the universe is
smoking.
 -- Andrew Suffield in [EMAIL PROTECTED]

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


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

Re: On including 64-bit libs in 32-bit packages (see #344104)

[Juliusz Chroboczek]

> >> Bear in mind that the 64-bit kernel doesn't offer all the functionality 
> >> that the 32-bit one does. vm86 is the most obvious thing missing.

> In arch/x86_64/ia32/ia32entry.S, both the vm86 calls (vm86 and vm86old) 
> are stubbed to sys32_vm86_warning, which just printks "vm86 mode not 
> supported on 64 bit kernel" and then returns -ENOSYS.

If I'm reading the function int10LinuxLoadSubModule in
os-support/linux/int10/linux.c right, it shouldn't matter.  vm86 will
return ENOSYS, which will cause vm86_tst to fail, which will cause the X
server to use x86emu instead of vm86.

Or am I missing something?

  Juliusz Chroboczek


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

Re: RFP: tinymce -- Web based Javascript HTML WYSIWYG editor

[Alexis Sukrieh]

* Kjetil Kjernsmo ([EMAIL PROTECTED]) :
> Well, I do more and more package building these days, but I haven't had 
> time to read the policy documents yet, and each time I try to set aside 
> time, a disk dies or something. So it is on my agenda, but right now, 
> it doesn't seem like I'll have the time before etch is due out... So, I 
> don't know...

[ webapps team hat ]

Hmm, ok, then consider that the Debian Webapps Team[1] will maintain that
package.

Feel free to join the team if you like to contribute to the packaging in
the future.

Regards,

1: http://alioth.debian.org/projects/webapps-common/

-- 
Alexis Sukrieh <[EMAIL PROTECTED]>
0x1EE5DD34
Debian   http://www.debian.org
Backup Manager   http://www.backup-manager.org


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

Re: Bug#394705: ITP: emma -- extendable MySQL managing assistant

[Piotr Ozarowski]

Since users of package emma will start app. most probably from some kind
of menu (I.e. I'm providing debian menu file in my package) and users of
your package will use shell, I will rename /usr/bin/emma to
/usr/bin/Emma.


pgpr3P3ZXkjJR.pgp
Description: PGP signature

Re: Getting rid of circular dependencies, stage 6

[Frank Küster]

Don Armstrong <[EMAIL PROTECTED]> wrote:

> On Tue, 24 Oct 2006, Petter Reinholdtsen wrote:
>> [Ian Jackson]
>> > The only argument I've heard against circular dependencies as a
>> > general rule is that they can trigger a particularly stupid (and
>> > probably not very hard to fix) bug in apt,
>> 
>> You seem to have missed the argument that packages with circular
>> dependencies are impossible to install and configure in the correct
>> (dependency) order, and thus will end up being installed and
>> configured in a nondeterministic order instead. It is documented
>> that dpkg try its best to find a sensible order for the packages,
>> but it is bound to fail one way or another if two packages really do
>> need each other to be configured before they are configured.
>
> Packages which have circular dependencies and depend on the other
> package being configured are buggy; at most they can depend on the
> other package being unpacked. Since there is no way to specify this
> kind of dependency, Depends: is as close as you can get.

It seems to me that the solution in such situation shouldn't be a
circular dependency with its "nondeterministic" behavior, but instead to
separate one of the packages into two.  For example if package b needs
package a unpacked, but not configured, separate package a in a-data and
a-therest, where a-data provides all that package b needs: Now b can
depend on a-data, and a-therest can depend on b.

Regards, Frank
-- 
Dr. Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: Getting rid of circular dependencies, stage 6

[Don Armstrong]

On Tue, 24 Oct 2006, Frank Küster wrote:
> Don Armstrong <[EMAIL PROTECTED]> wrote: 
> > On Tue, 24 Oct 2006, Petter Reinholdtsen wrote:
> >> [Ian Jackson]
> >> > The only argument I've heard against circular dependencies as a
> >> > general rule is that they can trigger a particularly stupid (and
> >> > probably not very hard to fix) bug in apt,
> >> 
> >> You seem to have missed the argument that packages with circular
> >> dependencies are impossible to install and configure in the correct
> >> (dependency) order, and thus will end up being installed and
> >> configured in a nondeterministic order instead. It is documented
> >> that dpkg try its best to find a sensible order for the packages,
> >> but it is bound to fail one way or another if two packages really do
> >> need each other to be configured before they are configured.
> >
> > Packages which have circular dependencies and depend on the other
> > package being configured are buggy; at most they can depend on the
> > other package being unpacked. Since there is no way to specify this
> > kind of dependency, Depends: is as close as you can get.
> 
> It seems to me that the solution in such situation shouldn't be a
> circular dependency with its "nondeterministic" behavior,

The end behavoir is only nondeterministic if the packages in the set
care what order they are configured in. If they do, that's a bug.

> but instead to separate one of the packages into two. For example if
> package b needs package a unpacked, but not configured, separate
> package a in a-data and a-therest, where a-data provides all that
> package b needs: Now b can depend on a-data, and a-therest can
> depend on b.

This is inherently fragile and requires a and b to be closely
cooperating packages; it also makes it difficult to define an
'a-therest' requires 'a-data' >> someversion dependency. (You'd have
to release a new version of b to do so.)

I'm all for removing unecessary circular dependencies, but hacking
around necessary circular dependencies is ugly. Far better to fix the
tools if they're unable to handle them properly.


Don Armstrong

-- 
Taxes are not levied for the benefit of the taxed.
 -- Robert Heinlein _Time Enough For Love_ p250

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

Re: arches and etch

[Brian Morris]

although i have installed  debian on
5 machines in the last two years and
multiple times for testing on a couple of
them, i don't think i have been counted
on popcon and most likely never will be.

the reasons, multiply:

3 of the five have never gone outside of
local network, and in fact only recently
one has gone that far.

the other two are mobile and complicated
to set up mail so i don't, i use free beer services
like gmail and yahoo and i don't download
like with pop or anything.

note this also really created hassles with
bugreports.

but if popcon would put the reports in
the local admin mail i would forward them
by hand - it doesn't.


probably the only thing i would use an
intel machine for would be as mail server,
IF i had a fixed internet adress but it don't
and have no plans for one (free wireless/mobile
is how i go).

if there is a way to deal with all this i welcome
suggestions, especially if it is amenable to
automation.

but for now i wouldn't trust these numbers worth
a stick. seeing for even one example most ppcs are
macs and most macs are laptop and are the most
numerous unix machines... i would rather trust the mailing
list numbers to estimate percentage shares.


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

Re: openssh packages with updated selinux patch

[Frans Pop]

On Tuesday 24 October 2006 07:19, Manoj Srivastava wrote:
> No, it is not. The configure patch:
>
>  ensures that LIBSELINUX expands to -lselinux only on machines where
>  it is available, not otherwise.
>
> Unless you are saying that the configure.ac patch is broken,
>  in which case please supply a log of the regenerated configure script
>  showing that it fails.

AFAICT the argument is that selinux should not be hard linked at all. 
Having openssh require selinux libs is unwanted overhead for the 
installer.

A solution should be found so that selinux will only be used if it is 
available _at runtime_, as was already done for some other libs that also 
produce udebs.

See for comparison:
http://bugs.debian.org/318115
http://bugs.debian.org/375413

Alternatively the udebs could be compiled separately without selinux 
support.

Cheers,
FJP


pgptRNovt1e3b.pgp
Description: PGP signature

Re: arches and etch

[Petter Reinholdtsen]

[Brian Morris]
> if there is a way to deal with all this i welcome suggestions,
> especially if it is amenable to automation.

The default submission method for popularity-contest is now HTTP.  It
might make it easier for your setup.  Also, it is possible for popcon
submit its report somewhere else (for example local admin as you
suggested), and then let this someone else send the email on.  So your
problems do not seem unsolvable.

There are no indication that the problems you describe skew the
relative architecture much.  The relative distribution have been quite
static as the number of submitters have increased from 4000 to 18000.
I take this as an indication that the amount of people not using
popcon is almost the same across all archs. :)

Friendly,
-- 
Petter Reinholdtsen


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

Re: arches and etch

[Goswin von Brederlow]

Petter Reinholdtsen <[EMAIL PROTECTED]> writes:

> [Brian Morris]
>> if there is a way to deal with all this i welcome suggestions,
>> especially if it is amenable to automation.
>
> The default submission method for popularity-contest is now HTTP.  It
> might make it easier for your setup.  Also, it is possible for popcon
> submit its report somewhere else (for example local admin as you
> suggested), and then let this someone else send the email on.  So your
> problems do not seem unsolvable.

To name names: /etc/popularity-contest.conf mentions
/usr/share/popularity-contest/default.conf for more options and that
has

# Local overrides are in /etc/popularity-contest.conf
MAILTO="[EMAIL PROTECTED]"

So you copy that line to your /etc/popularity-contest.conf and change
it to root and there you go.

MfG
   Goswin


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

Re: openssh packages with updated selinux patch

[Aurelien Jarno]

On Tue, Oct 24, 2006 at 12:19:59AM -0500, Manoj Srivastava wrote:
> On Tue, 24 Oct 2006 06:36:34 +0200, Aurelien Jarno <[EMAIL PROTECTED]> said: 
> 
> > Manoj Srivastava a écrit :
> >> Hi,
> >> 
> >> I have created openssh packages with updated SELinux patches, this
> >> brings us in line with the new SELinux release. The patch is
> >> recorded in Bug#394795.  The packages are available at:
>  
> >> Please test these packages out. I would like to see the SELinux
> >> updates enter Etch, and would be happy to do an NMU, if desired.
> 
> > With your patch, sshd is unconditionally linked with
> > libselinux. This breaks debian-installer on architectures using ssh
> > for the installation, and also non-Linux architectures.
> 
> No, it is not. The configure patch:
> +# Check whether user wants SELinux support
> +SELINUX_MSG="no"
> +LIBSELINUX=""
> +AC_ARG_WITH(selinux,
> +   [  --with-selinux[[=LIBSELINUX-PATH]]   Enable SELinux support],
> +   [ if test "x$withval" != "xno" ; then
> +   if test "x$withval" != "xyes"; then
> +   CPPFLAGS="$CPPFLAGS -I${withval}/include"
> +   if test -n "${need_dash_r}"; then
> +   LDFLAGS="-L${withval}/lib -R${withval}/lib 
> ${LDFLAGS}"
> +   else
> +   LDFLAGS="-L${withval}/lib ${LDFLAGS}"
> +   fi
> +   fi 
> +   AC_DEFINE(WITH_SELINUX,1,[Define if you want SELinux 
> support.])
> +   SELINUX_MSG="yes"
> +   AC_CHECK_HEADERS(selinux.h)
> +   LIBSELINUX="-lselinux"
> +   fi
> +   ])
> +AC_SUBST(LIBSELINUX)
> +
>  ensures that LIBSELINUX expands to -lselinux only on machines where
>  it is available, not otherwise.
> 
> Unless you are saying that the configure.ac patch is broken,
>  in which case please supply a log of the regenerated configure script
>  showing that it fails.
> 

I don't say the configure.ac patch is broken, I say the patch as a whole
is broken. After a few searches it seems the problem is in Makefile.in:

[bode:/tmp/openssh-4.3p2]$ grep LIBSELINUX Makefile.in
LIBSELINUX=-lselinux
$(LD) -o $@ $(SSHDOBJS) $(LDFLAGS) -lssh -lopenbsd-compat $(LIBWRAP) 
$(LIBPAM) $(LIBSELINUX) $(LIBS)
[bode:/tmp/openssh-4.3p2]$

I can confirm that the resulting udeb package is linked with libselinux,
even if selinux support is disabled for the udeb pass:

[anguille:/tmp/openssh]$ wget 
http://people.debian.org/~srivasta/packages/pool/o/openssh/openssh-server-udeb_4.3p2-5.1_i386.udeb
--15:35:39--  
http://people.debian.org/~srivasta/packages/pool/o/openssh/openssh-server-udeb_4.3p2-5.1_i386.udeb
   => `openssh-server-udeb_4.3p2-5.1_i386.udeb'
Résolution de people.debian.org... 192.25.206.10
Connexion vers people.debian.org|192.25.206.10|:80...connecté.
requête HTTP transmise, en attente de la réponse...200 OK
Longueur: 160 022 (156K) [text/plain]

100%[>]
 160 022  183.79K/s

15:35:40 (183.36 KB/s) - « openssh-server-udeb_4.3p2-5.1_i386.udeb » sauvegardé 
[160022/160022]

[anguille:/tmp/openssh]$ dpkg -x openssh-server-udeb_4.3p2-5.1_i386.udeb .
[anguille:/tmp/openssh]$ ldd usr/sbin/sshd
linux-gate.so.1 =>  (0xe000)
libselinux.so.1 => /lib/libselinux.so.1 (0xa7ef)
libresolv.so.2 => /lib/tls/i686/cmov/libresolv.so.2 (0xa7edd000)
libcrypto.so.0.9.8 => /usr/lib/i686/cmov/libcrypto.so.0.9.8 (0xa7da2000)
libutil.so.1 => /lib/tls/i686/cmov/libutil.so.1 (0xa7d9e000)
libz.so.1 => /usr/lib/libz.so.1 (0xa7d8a000)
libcrypt.so.1 => /lib/tls/i686/cmov/libcrypt.so.1 (0xa7d5c000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xa7c2b000)
libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xa7c27000)
libsepol.so.1 => /lib/libsepol.so.1 (0xa7be6000)
/lib/ld-linux.so.2 (0xa7f24000)
[anguille:/tmp/openssh]$

-- 
  .''`.  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]

Re: On including 64-bit libs in 32-bit packages (see #344104)

[Matthew Garrett]

Juliusz Chroboczek <[EMAIL PROTECTED]> wrote:

> If I'm reading the function int10LinuxLoadSubModule in
> os-support/linux/int10/linux.c right, it shouldn't matter.  vm86 will
> return ENOSYS, which will cause vm86_tst to fail, which will cause the X
> server to use x86emu instead of vm86.
> 
> Or am I missing something?

The x86emu code doesn't get built on i386, does it? It doesn't look like 
the INT10_VM86 and INT10_X86EMU conditionals can both be set 
simultaneously.

-- 
Matthew Garrett | [EMAIL PROTECTED]


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

Re: Bug mass filling

[Hubert Chan]

On Mon, 23 Oct 2006 13:46:23 -0500, Manoj Srivastava <[EMAIL PROTECTED]> said:

[...]

>> and for policy:

>> These classifications are roughly equivalent to the bug severities
>> serious (for must or required directive violations), minor, normal or
>> important (for should or recommended directive violations) and
>> wishlist (for optional items). [2] However, this is not a direct
>> mapping, and the release managers determine which violations are
>> considered release-critical.

> where does release criticality jump in here from? Policy has
> no mention of RC in this context, I see no reason to suddenly inject
> one.

Well, I did say that it was a very rough draft. ;)

Second try:
  "... However, this is not a direct mapping, and the release managers
  determine the severity of each violation."

> The problem is there are two mappings, one from policy
> violations over to bug severities, and another from severities to
> RC. The former is , according to policy, pretty static; the latter is,
> by the release team directive, a fluid mapping based on the contents
> of a web page, which is updated by the RM's as needed.

> I don't see any reason to fuzzy up the first mapping; and I
> see the etch-ignore tag as a perfectly legitimate and adequate
> representation of the fluidity of the second mapping.

>From my reading, the language for the first mapping is already a bit
fuzzy, since both places that define the mapping use the word "roughly".
So I think that we should either make it explicitly fuzzy by changing
the wording, or make it explicitly not fuzzy by removing the word
"roughly" (and possibly changing policy to reflect reality).

I also would prefer if the first mapping wasn't fuzzy.  But it sounds to
me like the release team is reading it as being a fuzzy mapping
(AFAICT), in which case I would suggest making it more clear that the
mapping is fuzzy.

-- 
Hubert Chan <[EMAIL PROTECTED]> -- Jabber: [EMAIL PROTECTED]
PGP/GnuPG key: 1024D/124B61FA http://www.uhoreg.ca/
Fingerprint: 96C5 012F 5F74 A5F7 1FF7  5291 AF29 C719 124B 61FA


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

Bug#395064: ITP: python-pygments -- syntax highlighting package written in Python

[Piotr Ozarowski]

Package: wnpp
Severity: wishlist
Owner: Piotr Ozarowski <[EMAIL PROTECTED]>

* Package name: python-pygments
  Version : 0.1~svn2258
  Upstream Author : Georg Brandl <[EMAIL PROTECTED]>
* URL : http://pygments.pocoo.org/
* License : LGPL
  Programming Lang: Python
  Description : syntax highlighting package written in Python

Pygments aims to be a generic syntax highlighter for general use in all kinds
of software such as forum systems, wikis or other applications that need to
prettify source code.
.
Highlights are:
  * a wide range of common languages and markup formats is supported
  * special attention is paid to details, increasing quality by a fair amount
  * support for new languages and formats are added easily
  * a number of output formats, presently HTML, LaTeX and ANSI sequences
  * it is usable as a command-line tool and as a library
  * ... and it highlights even Brainfuck!

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


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

Re: RFP: tinymce -- Web based Javascript HTML WYSIWYG editor

[Moritz Muehlenhoff]

Kjetil Kjernsmo wrote:
> I could imagine this creating an undesired overhead for the Security
> Team in case of a flaw. 
>
> I would therefore suggest splitting TinyMCE into a package of its
> own. Unfortunately, I'm not a DD myself.

That would be much appreciated. The second troublemaker if adodb,
which seems embedded in several webapps as well.

Cheers,
Moritz


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

Re: RFP: tinymce -- Web based Javascript HTML WYSIWYG editor

[sean finney]

On Tue, 2006-10-24 at 22:25 +0200, Moritz Muehlenhoff wrote:
> 
> That would be much appreciated. The second troublemaker if adodb,
> which seems embedded in several webapps as well.

and is also already packaged, for clarity.  however, many packages embed
it *anyway*, and some have locally modified versions, or don't work with
the latest versions...  fun!


sean


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

Re: Bug mass filling

[Ian Jackson]

Manoj Srivastava writes ("Re: Bug mass filling"):
> On Fri, 20 Oct 2006 17:18:41 -0700, Steve Langasek <[EMAIL PROTECTED]> said: 
> > 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?
> 
> Gee. Don't we already have something very like this? 
> 
>  These classifications are roughly equivalent to the bug severities
>  _serious_ (for _must_ or _required_ directive violations), _minor_,
>  _normal_ or _important_ (for _should_ or _recommended_ directive
>  violations) and _wishlist_ (for _optional_ items).  [2]

There are two different and orthogonal properties of a policy
requirement:

  1. Is the requirement applicable in all cases, or are there
 sometimes overriding reasons to it another way, or exceptional
 cases where the requirement ought not to apply ?

  2. Is a violation of the requirement release-critical ?  That is,
 would it be better to remove the package (or to stick with
 the old version of the package) than to live with this bug ?

I'm happy that the policy manual should itself determine the answer to
the first question; and this is the conventional distinction between
`must' vs `should'.

But the second question is much more subtle, and also isn't properly
decided by the process that maintains the policy manual.  It should be
probably be decided by the package maintainer in the first instance;
with the release managers giving both general guidance and specific
advice, and having the final decision.

Ian.


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

Re: Re: Your details

[info]

You are receiving this email because you recently sent a message to Pangolin, 
or because a spammer is using your email address as the "FROM" address when 
sending an email to a discontinued email box at Pangolin. 

If you intended to contact Pangolin, your message unfortunately has not been 
delivered. We have discontinued the use of several older email addresses. 
Please re-send your message using our new CONTACT form which can be found at: 
http://www.pangolin.com/contact/index.php 

NOTE: If you are receiving this message in error, we applogize and we will make 
every effort to stop spammers from abusing our server or your email address in 
this way. To report abuse, you may contact Pangolin directly at: 
http://www.pangolin.com/contact/index.php or by phone at +1-407-299-2088.




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

Re: Bug mass filling

[Manoj Srivastava]

On Tue, 24 Oct 2006 17:18:20 +0100, Ian Jackson <[EMAIL PROTECTED]> said: 

> Manoj Srivastava writes ("Re: Bug mass filling"):
>> On Fri, 20 Oct 2006 17:18:41 -0700, Steve Langasek
>> <[EMAIL PROTECTED]> said:
>> > 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?
>> 
>> Gee. Don't we already have something very like this?
>> 
>> These classifications are roughly equivalent to the bug severities
>> _serious_ (for _must_ or _required_ directive violations), _minor_,
>> _normal_ or _important_ (for _should_ or _recommended_ directive
>> violations) and _wishlist_ (for _optional_ items).  [2]

> There are two different and orthogonal properties of a policy
> requirement:

I posit the second one is not a characteristic of the policy
 requirement; it is a characteristic of the bug.

>   1. Is the requirement applicable in all cases, or are there
>  sometimes overriding reasons to it another way, or exceptional
>  cases where the requirement ought not to apply ?

>   2. Is a violation of the requirement release-critical ?  That is,
>  would it be better to remove the package (or to stick with the
>  old version of the package) than to live with this bug ?

> I'm happy that the policy manual should itself determine the answer
> to the first question; and this is the conventional distinction
> between `must' vs `should'.

> But the second question is much more subtle, and also isn't properly
> decided by the process that maintains the policy manual.  It should
> be probably be decided by the package maintainer in the first
> instance; with the release managers giving both general guidance and
> specific advice, and having the final decision.

Nothing you have said contradicts either what I or aba have
 said; the devil lies in the details you have elided.

My stance is that bug severity tags are tied to policy
 violations, since that can be determined mechanically; violate a must
 directive, bug is serious.  Whether or not all serious bugs are RC is
 anothermatter that the release team determines; hence the *-ignore
 tags.

Andreas is of the opinion we should instead have all serious
 bugs be RC, violations of policy must directives that are not RC
 should be downgraded.

The problem is, since this involves human judgement, one can no
 longer state in policy what category a must violation of policy falls
 into; policy must waffle with well, if you find a policy violation,
 fgiure out what severity the ciolation would be, consult your
 feelings, other peoples feelings, release managers,  and perhaps the
 phase of the moon.

Unlike the decision of whether a seirous bug is RC under my
 proposal, where the word of the RM is law; there is no final
 authority about the severity of a policy violation bug under the
 alternate proposal.  Any maintainer is then free to insist that his
 violation of a bug would not be RC, anyway, and downgrade the bug; it
 would mean that the RM's would have to be brought in every time there
 is a violation of policy.

Since we already feel that our RM's are overworked (hence
 dunc-tank and payment schemes), I strongly suggest we not add to the
 RM's burdens any more than we have to.

manoj
-- 
He gave her a look that you could have poured on a waffle.
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

[Manoj Srivastava]

On Tue, 24 Oct 2006 07:21:35 +0200, Andreas Barth <[EMAIL PROTECTED]> said: 

> * Manoj Srivastava ([EMAIL PROTECTED]) [061023 20:14]:
>> Strawman. No one is proosing that; we already have a mechanism for
>> making serious bugs non-RC (etch-ignore tags).

> Etch-ignore tags are usually used for issues where we expect them to
> be RC after etch releases. If we think an issue won't be RC for
> etch+1 etc, then adjusting the severity is correct.

I would assume violations of policy MUST directives are either
 bugs in policy, which should be fixed, or  an issue in the package
 that needs to be fixed after etch releases.

If you are aware of issues that are violations of muSt
 directives that are never going to be RC, there should be a bug
 opened on policy with severity important for every one of them.

manoj
-- 
Any discovery is more likely to be exploited by the wicked than
applied by the virtuous.  -- Marion J. Levy, Jr.
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

[Manoj Srivastava]

On Tue, 24 Oct 2006 13:49:01 -0400, Hubert Chan <[EMAIL PROTECTED]> said: 

> On Mon, 23 Oct 2006 13:46:23 -0500, Manoj Srivastava
> <[EMAIL PROTECTED]> said: [...]

>>> and for policy:

>>> These classifications are roughly equivalent to the bug severities
>>> serious (for must or required directive violations), minor, normal
>>> or important (for should or recommended directive violations) and
>>> wishlist (for optional items). [2] However, this is not a direct
>>> mapping, and the release managers determine which violations are
>>> considered release-critical.

>> where does release criticality jump in here from? Policy has no
>> mention of RC in this context, I see no reason to suddenly inject
>> one.

> Well, I did say that it was a very rough draft. ;)

> Second try:
>   "... However, this is not a direct mapping, and the release
>   managers determine the severity of each violation."

Direct mapping of *WHAT*? are you falling into the assumption
 that serious == RC? Why?

manoj
-- 
Hard work never killed anybody, but why take a chance? Charlie
McCarthy
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: Getting rid of circular dependencies, stage 6

[Manoj Srivastava]

On Tue, 24 Oct 2006 09:30:33 +0200, Petter Reinholdtsen <[EMAIL PROTECTED]> 
said: 

> [Ian Jackson]
>> The only argument I've heard against circular dependencies as a
>> general rule is that they can trigger a particularly stupid (and
>> probably not very hard to fix) bug in apt,

> You seem to have missed the argument that packages with circular
> dependencies are impossible to install and configure in the correct
> (dependency) order, and thus will end up being installed and
> configured in a nondeterministic order instead.  It is documented
> that dpkg try its best to find a sensible order for the packages,
> but it is bound to fail one way or another if two packages really do
> need each other to be configured before they are configured.

If the packages do not require each other for installation,
 then this is irrelevant. I suspect the vast majority of cases is that
 packages depend on each other at *RUN* time, not install time.

Circular dependencies where the dependencies are needed at
 install time are indeed buggy, but I see no indication that the jihad
 against circular dependencies is making any such distinctions.

manoj
-- 
If you have to hate, hate gently.
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]

Bug#395084: ITP: hinventory-client -- Hinventory-client Script to generate Hardware/Software report file in xml for H-Inventory web application.

[julien . safar]

Package: wnpp
Severity: wishlist
Owner: [EMAIL PROTECTED]


* Package name: hinventory-client
  Version : 1.2.8
  Upstream Author : Julien SAFAR <[EMAIL PROTECTED]>
* URL : http://www.h-inventory.com
* License : (GPL)
  Description : Hinventory-client Script to generate Hardware/Software 
report file in xml for H-Inventory web application.

Script to inventory your workstation and list your hardware, softwares
and then upload it on a web interface.

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.11-xenU
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: Bug mass filling

[Steve Langasek]

On Tue, Oct 24, 2006 at 05:00:45PM -0500, Manoj Srivastava wrote:
> > Well, I did say that it was a very rough draft. ;)

> > Second try:
> >   "... However, this is not a direct mapping, and the release
> >   managers determine the severity of each violation."

> Direct mapping of *WHAT*? are you falling into the assumption
>  that serious == RC? Why?

Because your choice of mapping blurs the distinction between one-time
exceptions for RCness (e.g., due to GRs for DFSG issues), vs. policy
violations that the release team does not believe should be promoted to RC
status at any time in the foreseeable future.  "etch-ignore" is most useful
as a tag if its use is restricted to those bugs whose
*non*-release-criticality is transient in nature -- the alternative is that
the release team is stuck going through the BTS after each release and
re-adding new tags to those bugs about policy violations whose severity does
not justify exclusion from the release.

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

Re: Bug mass filling

[Steve Langasek]

On Tue, Oct 24, 2006 at 04:51:08PM -0500, Manoj Srivastava wrote:
> > * Manoj Srivastava ([EMAIL PROTECTED]) [061023 20:14]:
> >> Strawman. No one is proosing that; we already have a mechanism for
> >> making serious bugs non-RC (etch-ignore tags).

> > Etch-ignore tags are usually used for issues where we expect them to
> > be RC after etch releases. If we think an issue won't be RC for
> > etch+1 etc, then adjusting the severity is correct.

> I would assume violations of policy MUST directives are either
>  bugs in policy, which should be fixed, or  an issue in the package
>  that needs to be fixed after etch releases.

> If you are aware of issues that are violations of muSt
>  directives that are never going to be RC, there should be a bug
>  opened on policy with severity important for every one of them.

Why?  If these issues are downgraded to "should"s in policy, doesn't that
again introduce ambiguity about whether a violation of that particular
"should" is a bug, unnecessarily weakening the overall quality of the
distro?

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

Re: Bug mass filling

[Manoj Srivastava]

On Tue, 24 Oct 2006 16:04:54 -0700, Steve Langasek <[EMAIL PROTECTED]> said: 

> On Tue, Oct 24, 2006 at 05:00:45PM -0500, Manoj Srivastava wrote:
>> > Well, I did say that it was a very rough draft. ;)

>> > Second try:
>> >   "... However, this is not a direct mapping, and the release
>> >   managers determine the severity of each violation."

>> Direct mapping of *WHAT*? are you falling into the assumption that
>> serious == RC? Why?

> Because your choice of mapping blurs the distinction between
> one-time exceptions for RCness (e.g., due to GRs for DFSG issues),
> vs. policy violations that the release team does not believe should
> be promoted to RC status at any time in the foreseeable future.
> "etch-ignore" is most useful as a tag if its use is restricted to
> those bugs whose *non*-release-criticality is transient in nature --
> the alternative is that the release team is stuck going through the
> BTS after each release and re-adding new tags to those bugs about
> policy violations whose severity does not justify exclusion from the
> release.

That does not make sense. After etch is released, etch-ignore
 tags are no-ops -- so there is no need to go back and untag anything.

And if there are anyissues that are policy must directives
 that the release team has take upon itself to say are policy
 directives it is not worth following, then they should file important
 bugs against polocuy to either have the requirements removed, or the
 issue resovled by the tech ctte.

This bit about "Oh, lets just ignore policy, for we know
 better" is absolutely the wrong way to go about this.   Fixing policy
 is the right way.

manoj
-- 
Concept, n.: Any "idea" for which an outside consultant billed you
more than $25,000.
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: openssh packages with updated selinux patch

[Manoj Srivastava]

> On Tue, Oct 24, 2006 at 12:19:59AM -0500, Manoj Srivastava wrote:
>> On Tue, 24 Oct 2006 06:36:34 +0200, Aurelien Jarno
>> <[EMAIL PROTECTED]> said:
>> 
>> > Manoj Srivastava a écrit :
>> >> Hi,
>> >> 
>> >> I have created openssh packages with updated SELinux patches,
>> >> this brings us in line with the new SELinux release. The patch
>> >> is recorded in Bug#394795.  The packages are available at:
>> 
>> >> Please test these packages out. I would like to see the SELinux
>> >> updates enter Etch, and would be happy to do an NMU, if desired.
>> 
>> > With your patch, sshd is unconditionally linked with
>> > libselinux. This breaks debian-installer on architectures using
>> > ssh for the installation, and also non-Linux architectures.
>> 
>> No, it is not. The configure patch:

>> ensures that LIBSELINUX expands to -lselinux only on machines where
>> it is available, not otherwise.
>> 
>> Unless you are saying that the configure.ac patch is broken, in
>> which case please supply a log of the regenerated configure script
>> showing that it fails.
>> 

> I don't say the configure.ac patch is broken, I say the patch as a
> whole is broken.

Then you have not actually applied the patch in the BTS. (If
 you used the .dsc on people.d.o, please refresh, since I hadn't meant
 that .dsc to be public -- it is an older version used for testing). I
 have now replaced it with a real version based on the patch.

> After a few searches it seems the problem is in
> Makefile.in:

And that is proof.

> [bode:/tmp/openssh-4.3p2]$ grep LIBSELINUX Makefile.in
> LIBSELINUX=-lselinux
> $(LD) -o $@ $(SSHDOBJS) $(LDFLAGS) -lssh -lopenbsd-compat
> $(LIBWRAP) $(LIBPAM) $(LIBSELINUX) $(LIBS)
> [bode:/tmp/openssh-4.3p2]$

> I can confirm that the resulting udeb package is linked with
> libselinux, even if selinux support is disabled for the udeb pass:

With that Makefile.in, sure. Here is what is in the patch
 submitted:

==
diff -uBbwr ../debian-current/openssh-4.3p2/Makefile.in 
openssh-4.3p2/Makefile.in
--- ../debian-current/openssh-4.3p2/Makefile.in 2006-10-20 12:53:04.0 
-0500
+++ openssh-4.3p2/Makefile.in   2006-10-20 15:34:48.0 -0500
@@ -43,6 +43,7 @@
 [EMAIL PROTECTED]@
 CPPFLAGS=-I. -I$(srcdir) @CPPFLAGS@ $(PATHS) @DEFS@
 [EMAIL PROTECTED]@
[EMAIL PROTECTED]@
 [EMAIL PROTECTED]@
 [EMAIL PROTECTED]@
 [EMAIL PROTECTED]@
@@ -136,7 +137,7 @@
$(LD) -o $@ $(SSHOBJS) $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS)
 
 sshd$(EXEEXT): libssh.a$(LIBCOMPAT) $(SSHDOBJS)
-   $(LD) -o $@ $(SSHDOBJS) $(LDFLAGS) -lssh -lopenbsd-compat $(LIBWRAP) 
$(LIBPAM) $(LIBS)
+   $(LD) -o $@ $(SSHDOBJS) $(LDFLAGS) -lssh -lopenbsd-compat $(LIBWRAP) 
$(LIBPAM) $(LIBSELINUX) $(LIBS)
 
 scp$(EXEEXT): $(LIBCOMPAT) libssh.a scp.o progressmeter.o
$(LD) -o $@ scp.o progressmeter.o bufaux.o $(LDFLAGS) -lssh 
-lopenbsd-compat $(LIBS)
==

I now have a smaller configure.ac patch, which shows better
 what the improvement in configuration is:
==
diff -uBbwr ../debian-current/openssh-4.3p2/configure.ac 
openssh-4.3p2/configure.ac
--- ../debian-current/openssh-4.3p2/configure.ac2006-10-20 
12:53:04.0 -0500
+++ openssh-4.3p2/configure.ac  2006-10-24 15:25:30.0 -0500
@@ -2986,15 +2986,25 @@
 
 # Check whether user wants SELinux support
 SELINUX_MSG="no"
+LIBSELINUX=""
 AC_ARG_WITH(selinux,
-   [  --with-selinux  Enable SELinux support],
+   [  --with-selinux[[=LIBSELINUX-PATH]]   Enable SELinux support],
[ if test "x$withval" != "xno" ; then
+   if test "x$withval" != "xyes"; then
+   CPPFLAGS="$CPPFLAGS -I${withval}/include"
+   if test -n "${need_dash_r}"; then
+   LDFLAGS="-L${withval}/lib -R${withval}/lib 
${LDFLAGS}"
+   else
+   LDFLAGS="-L${withval}/lib ${LDFLAGS}"
+   fi
+   fi 
AC_DEFINE(WITH_SELINUX, 1, [Define if you want SELinux 
support.])
SELINUX_MSG="yes"
AC_CHECK_HEADERS(selinux/selinux.h)
-   LIBS="$LIBS -lselinux"
+   LIBSELINUX="-lselinux"
fi
])
+AC_SUBST(LIBSELINUX)
 
 # Check whether user wants Kerberos 5 support
 KRB5_MSG="no"

==

manoj
-- 
"I not only use all the brains that I have, but all that I can
borrow." -Woodrow Wilson
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: openssh packages with updated selinux patch

[Manoj Srivastava]

On Tue, 24 Oct 2006 13:42:42 +0200, Frans Pop <[EMAIL PROTECTED]> said: 

> AFAICT the argument is that selinux should not be hard linked at
> all.  Having openssh require selinux libs is unwanted overhead for
> the installer.

Well, since openssh already links with libselinux, my patch is
 not a regression.

> A solution should be found so that selinux will only be used if it
> is available _at runtime_, as was already done for some other libs
> that also produce udebs.

> See for comparison:
> http://bugs.debian.org/318115
> http://bugs.debian.org/375413

> Alternatively the udebs could be compiled separately without selinux
> support.

Either of these would be fine (though looking at the size of
 libselinux1, I wonder if there are any numbers behind  the burden
 theory?), but that would be a more intrusive change for openssh than
 I am willing to make as a non-maintainer at this stage of the game.

At this point, openssh links with libselinux1 where
 available. The code in openssh that exercises this library is out of
 date; I am merely bringing it up to be compatible with the SELinux
 infrastructure we will be shipping in Etch.

I am not _adding_ selinux code to openssh; I am _updating_
 code that already exists.

manoj
-- 
There's a fine line between courage and foolishness.  Too bad it's not
a fence.
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

[Manoj Srivastava]

On Tue, 24 Oct 2006 16:18:11 -0700, Steve Langasek <[EMAIL PROTECTED]> said: 

> On Tue, Oct 24, 2006 at 04:51:08PM -0500, Manoj Srivastava wrote:
>> > * Manoj Srivastava ([EMAIL PROTECTED]) [061023 20:14]:
>> >> Strawman. No one is proosing that; we already have a mechanism
>> >> for making serious bugs non-RC (etch-ignore tags).

>> > Etch-ignore tags are usually used for issues where we expect them
>> > to be RC after etch releases. If we think an issue won't be RC
>> > for etch+1 etc, then adjusting the severity is correct.

>> I would assume violations of policy MUST directives are either bugs
>> in policy, which should be fixed, or an issue in the package that
>> needs to be fixed after etch releases.

>> If you are aware of issues that are violations of muSt directives
>> that are never going to be RC, there should be a bug opened on
>> policy with severity important for every one of them.

> Why?  If these issues are downgraded to "should"s in policy, doesn't
> that again introduce ambiguity about whether a violation of that
> particular "should" is a bug, unnecessarily weakening the overall
> quality of the distro?

Why on earth would there be such an ambiguity? Should
 violations are bugs, or severity normal. 

And why is the distro quality su=ffering? Aren't the RM's of
 the opinion that these requirements are not worth following in the
 first place?

Either the policy dictum has to be followed, and a bug results
 (must - serious; should - normal), or the dictum should be removed
 from policy and moved to, say, dev ref.

manoj

-- 
I can give you my word, but I know what it's worth and you don't. Nero
Wolfe, "Over My Dead Body"
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]

Bug#395122: ITP: libxmlrpc-ocaml-dev -- XML-RPC support library for ocaml

[Pietro Abate]

Package: wnpp
Severity: wishlist
Owner: Pietro Abate <[EMAIL PROTECTED]>

* Package name: libxmlrpc-ocaml-dev
  Version : 0.2.3
  Upstream Author : Shawn Wagner <[EMAIL PROTECTED]>
* URL :  http://raevnos.pennmush.org/code/ocaml-xml-rpc/
* License : GPL
  Programming Lang: Ocaml
  Description : XML-RPC support library for ocaml

 Ocaml XML-RPC is a library for the Objective Caml programming language
 that implements the XML-RPC specification. XML-RPC remote procedure
 calling mechanism that uses HTTP as the transport and XML as the
 encoding.


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17-1-686
Locale: LANG=en_AU, LC_CTYPE=en_AU (charmap=ANSI_X3.4-1968) (ignored: LC_ALL 
set to C)

-- 
++ Blog: http://blog.rsise.anu.edu.au/?q=pietro
++ 
++ "All great truths begin as blasphemies." -George Bernard Shaw
++ Please avoid sending me Word or PowerPoint attachments.
   See http://www.fsf.org/philosophy/no-word-attachments.html


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

Re: Bug mass filling

[Hubert Chan]

On Tue, 24 Oct 2006 17:00:45 -0500, Manoj Srivastava <[EMAIL PROTECTED]> said:

> On Tue, 24 Oct 2006 13:49:01 -0400, Hubert Chan <[EMAIL PROTECTED]>
> said:
>> On Mon, 23 Oct 2006 13:46:23 -0500, Manoj Srivastava
>> <[EMAIL PROTECTED]> said: [...]

 and for policy:

 These classifications are roughly equivalent to the bug severities
 serious (for must or required directive violations), minor, normal
 or important (for should or recommended directive violations) and
 wishlist (for optional items). [2] However, this is not a direct
 mapping, and the release managers determine which violations are
 considered release-critical.

>>> where does release criticality jump in here from? Policy has no
>>> mention of RC in this context, I see no reason to suddenly inject
>>> one.

>> Well, I did say that it was a very rough draft. ;)

>> Second try: "... However, this is not a direct mapping, and the
>> release managers determine the severity of each violation."

> Direct mapping of *WHAT*? are you falling into the assumption
> that serious == RC? Why?

No, the previous sentence (which is what we currently have in policy)
defines a mapping of serious bug <=> "must"/"required" directive
violation, and minor/normal/important bug <=> "should"/"recommended"
directive violation, and wishlist bug <=> "optional".  That's the
mapping that it is referring to.

My understanding is that the release team treats that as an approximate
mapping, and the current wording of policy allows this due to the use of
the word "roughly".

("Mapping" may not be the best word to use in policy.  But like I said,
it's a rough draft.)

-- 
Hubert Chan <[EMAIL PROTECTED]> -- Jabber: [EMAIL PROTECTED]
PGP/GnuPG key: 1024D/124B61FA http://www.uhoreg.ca/
Fingerprint: 96C5 012F 5F74 A5F7 1FF7  5291 AF29 C719 124B 61FA


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

Re: Bug mass filling

[Steve Langasek]

On Tue, Oct 24, 2006 at 06:48:10PM -0500, Manoj Srivastava wrote:
> >> If you are aware of issues that are violations of muSt directives
> >> that are never going to be RC, there should be a bug opened on
> >> policy with severity important for every one of them.

> > Why?  If these issues are downgraded to "should"s in policy, doesn't
> > that again introduce ambiguity about whether a violation of that
> > particular "should" is a bug, unnecessarily weakening the overall
> > quality of the distro?

> Why on earth would there be such an ambiguity? Should
>  violations are bugs, or severity normal. 

  Non-conformance with guidelines denoted by _should_ (or _recommended_)
  will generally be considered a bug, but will not necessarily render a
  package unsuitable for distribution.

Is the word "generally" here an error?  I read this as implying the normal
meaning of "should" -- that not everything which violates a "should" mandate
is a bug.

> And why is the distro quality su=ffering? Aren't the RM's of
>  the opinion that these requirements are not worth following in the
>  first place?

Hell no.  We're of the opinion that these requirements are not grounds for
*excluding a package from release* -- but I certainly don't think that the
release team's stick should be the only reason for maintainers to comply
with the rules set out in policy!  And I don't think maintainers should be
left to believe that violations of certain directives in policy which are
unambiguously the correct thing to do should be treated as non-bugs, which
is what that "generally" implies.

I also don't think that all "should"s that might not be bugs should be
automatically shunted to the devref as you suggest, because that leaves us
with no standardization *process* for policy that we can use to get eyeballs
on possible bugs in new requirements, AFAICS.

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

Re: Bug mass filling

[Steve Langasek]

On Tue, Oct 24, 2006 at 04:36:52PM -0500, Manoj Srivastava wrote:
> Since we already feel that our RM's are overworked (hence
>  dunc-tank and payment schemes), I strongly suggest we not add to the
>  RM's burdens any more than we have to.

This is a laughable suggestion, given that the RMs' time is now being taken
up defending the longstanding handling of BTS severities in this thread,
when that is handling is precisely the one that, IME, minimizes the amount
of work the release team should have to do to manually review bug states.

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

Re: Bug mass filling

[Manoj Srivastava]

On Tue, 24 Oct 2006 18:36:43 -0700, Steve Langasek <[EMAIL PROTECTED]> said: 

> On Tue, Oct 24, 2006 at 04:36:52PM -0500, Manoj Srivastava wrote:
>> Since we already feel that our RM's are overworked (hence dunc-tank
>> and payment schemes), I strongly suggest we not add to the RM's
>> burdens any more than we have to.

> This is a laughable suggestion, given that the RMs' time is now
> being taken up defending the longstanding handling of BTS severities
> in this thread, when that is handling is precisely the one that,
> IME, minimizes the amount of work the release team should have to do
> to manually review bug states.

So, you want to be called in for every policy violation bug to
 weigh in on the severity? Sounds like that would increase the
 load. Just answering this question in the affiirmative would stop
 this thread of discussion dead in its tracks.

manoj
-- 
Honi soit la vache qui rit.
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

[Manoj Srivastava]

On Tue, 24 Oct 2006 17:15:55 -0700, Steve Langasek <[EMAIL PROTECTED]> said: 

> On Tue, Oct 24, 2006 at 06:48:10PM -0500, Manoj Srivastava wrote:
>> >> If you are aware of issues that are violations of muSt
>> >> directives that are never going to be RC, there should be a bug
>> >> opened on policy with severity important for every one of them.

>> > Why?  If these issues are downgraded to "should"s in policy,
>> > doesn't that again introduce ambiguity about whether a violation
>> > of that particular "should" is a bug, unnecessarily weakening the
>> > overall quality of the distro?

>> Why on earth would there be such an ambiguity? Should violations
>> are bugs, or severity normal.

>   Non-conformance with guidelines denoted by _should_ (or
>   _recommended_) will generally be considered a bug, but will not
>   necessarily render a package unsuitable for distribution.

> Is the word "generally" here an error?  I read this as implying the
> normal meaning of "should" -- that not everything which violates a
> "should" mandate is a bug.

I am of the opinion that it is. We can replace non-buggy
 instances of should by 'ought to be', if needed.

>> And why is the distro quality su=ffering? Aren't the RM's of the
>> opinion that these requirements are not worth following in the
>> first place?

> Hell no.  We're of the opinion that these requirements are not
> grounds for *excluding a package from release* -- but I certainly
> don't think that the release team's stick should be the only reason
> for maintainers to comply with the rules set out in policy!  And I

Well, maintainers ought to be following the should rules as
 well, so there is no reason for the directive to be a must if the bug
 is not deemed serious or a reason to keep the package out of the
 release until it is fixed.

> don't think maintainers should be left to believe that violations of
> certain directives in policy which are unambiguously the correct
> thing to do should be treated as non-bugs, which is what that
> "generally" implies.

Well, we seem to be in agreement here.  However, this change
 (removing generally) needs to  be ratified by a few more people
 before I would be comfortable changing it.

> I also don't think that all "should"s that might not be bugs should
> be automatically shunted to the devref as you suggest, because that
> leaves us with no standardization *process* for policy that we can
> use to get eyeballs on possible bugs in new requirements, AFAICS.

If something is not a requirement, that is, not doing it would
 not be considered a bug -- then it does not belong in the normative
 part of policy.  I think policy should be a minimal document, and
 omething which can be unequivocally taken at face value. It is not
 supposed to be waffling about, nor a thick tome of best practices. It
 is "do this, ot get a bug" book.


It should be easy enough to create a new document that is "it
 is kinda nice if you would do this, but, no worries, no bug on your
 package if you don't" and submit it to a similar process.

I just don't think that document should be conflated with our
 Technical policy.

manoj
-- 
Some people manage by the book, even though they don't know who wrote
the book or even what book.
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

[Kevin Mark]

On Tue, Oct 24, 2006 at 04:04:54PM -0700, Steve Langasek wrote:
> On Tue, Oct 24, 2006 at 05:00:45PM -0500, Manoj Srivastava wrote:
> > > Well, I did say that it was a very rough draft. ;)
> 
> > > Second try:
> > >   "... However, this is not a direct mapping, and the release
> > >   managers determine the severity of each violation."
> 
> > Direct mapping of *WHAT*? are you falling into the assumption
> >  that serious == RC? Why?
> 
> Because your choice of mapping blurs the distinction between one-time
> exceptions for RCness (e.g., due to GRs for DFSG issues), vs. policy
> violations that the release team does not believe should be promoted to RC
> status at any time in the foreseeable future.  "etch-ignore" is most useful
> as a tag if its use is restricted to those bugs whose
> *non*-release-criticality is transient in nature -- the alternative is that
> the release team is stuck going through the BTS after each release and
> re-adding new tags to those bugs about policy violations whose severity does
> not justify exclusion from the release.
> 
Hi,
So certain bugs can be marked $STABLE-ignore to allow transient rc
issues to be ignored for a release and will become no-ops after release.
Are you suggesting that each package can have a related list of
non-transient bugs that should be marked (with a new tags called )
ignore-this-policy-violation where this can be attached to any package
related bug for any length of time until the issues is deemed
worthy/necessary to be addressed?

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

[Christian Perrier]

>  install time are indeed buggy, but I see no indication that the jihad
>  against circular dependencies is making any such distinctions.


Is the word "jihad" meant to mean "holy, and aggressive, war to spread
out a religion" here?

I recently had an argument with another maintainer who also used tha
word with that meaning, which it doesn't have in the muslim culture
(I'm personnally a bit sensitive about that, for reasons I would have
much difficulties to explain). I felt it to be pretty offensive to my
muslim friends.

It that's the case, I'm not sure this is the best way to make the
point. I'm actually following this thread and I try to understand
whether the circular dependencies used by console-common (for which I
act as co-maintainer with Alastair McKinstry) are Good or Bad.

I appreciate the work done by Bill on that issue and I currently do
not have the feeling that it is run with the intents you seem to put
in the word "jihad".




signature.asc
Description: Digital signature

First draft of review of policy must usage

[Manoj Srivastava]

Hi,

Here is a first draft of changes to the policy that I think
 are required to bring ot closer in line with extant practice. I
 removed portions from the policy that linked policy violations to bug
 severities, since this has been deemed controversial and a "bug" in
 policy.  Next, I removed the DFSG text and replaced it by a pointer
 to the DFSG document itself, this prevents duplication, and I am not
 sure I would have remembered to edit it here if we ever changed the
 DFSG.

Next, I removed clauses that said that all the requirements of
 policy must be met  for a package to be in main or contrib; we know
 that is not true.

I have replaced some uses of the word must when it was
 intended to be non-normative with alternate and equivalent wording,
 which makes it easier to grep for "must".  This still needs to be
 done for should (which I often replace with 'ought to').

Finally, for your review, are some downgrades from must to
 should, which bring the document close to the release policy (though
 I think the release policy is not exhaustive [one must not ignore
 errors in maintainer scripts, and stop installation if needed,
 according to policy, but that is not an RC bug, various and sundry
 must directives in the package name area, and others], and may in
 itself be buggy).

If you have objections to or comments on any of these changes,
 please quote just the relevant chunk, and explain why you think the
 change is not good. Not that any one can change policy at the moment,
 but who knows,  I may yet in the future be able to change policy
 again.

manoj


--- orig/policy.sgml
+++ mod/policy.sgml
@@ -62,7 +62,7 @@
 	  GNU/Linux distribution. This includes the structure and
 	  contents of the Debian archive and several design issues of the
 	  operating system, as well as technical requirements that
-	  each package must satisfy to be included in the
+	  each package needs to satisfy to be included in the
 	  distribution.
 	
 
@@ -113,36 +113,6 @@
 	  either. Please see  for more information.
 	
 
-	
-	  In the normative part of this manual,
-	  the words must, should and
-	  may, and the adjectives required,
-	  recommended and optional, are used to
-	  distinguish the significance of the various guidelines in
-	  this policy document. Packages that do not conform to the
-	  guidelines denoted by must (or required)
-	  will generally not be considered acceptable for the Debian
-	  distribution. Non-conformance with guidelines denoted by
-	  should (or recommended) will generally be
-	  considered a bug, but will not necessarily render a package
-	  unsuitable for distribution. Guidelines denoted by
-	  may (or optional) are truly optional and
-	  adherence is left to the maintainer's discretion.
-	
-
-	
-	  These classifications are roughly equivalent to the bug
-	  severities serious (for must or
-	  required directive violations), minor,
-	  normal or important
-	  (for should or recommended directive
-	  violations) and wishlist (for optional
-	  items).
-	  
-		Compare RFC 2119.  Note, however, that these words are
-		used in a different way in this document.
-	  
-	
 
 	
 	  Much of the information presented in this manual will be
@@ -327,98 +327,11 @@
 	The Debian Free Software Guidelines
 	
 	  The Debian Free Software Guidelines (DFSG) form our
-	  definition of "free software".  These are:
-	
-	  Free Redistribution
-	  
-	  
-		  The license of a Debian component may not restrict any
-		  party from selling or giving away the software as a
-		  component of an aggregate software distribution
-		  containing programs from several different
-		  sources. The license may not require a royalty or
-		  other fee for such sale.
-	  
-	  Source Code
-	  
-	  
-		  The program must include source code, and must allow
-		  distribution in source code as well as compiled form.
-	  
-	  Derived Works
-	  
-	  
-		  The license must allow modifications and derived
-		  works, and must allow them to be distributed under the
-		  same terms as the license of the original software.
-	  
-	  Integrity of The Author's Source Code
-	  
-	  
-		  The license may restrict source-code from being
-		  distributed in modified form only if the
-		  license allows the distribution of "patch files"
-		  with the source code for the purpose of modifying the
-		  program at build time. The license must explicitly
-		  permit distribution of software built from modified
-		  source code. The license may require derived works to
-		  carry a different name or version number from the
-		  original software.  (This is a compromise. The Debian
-		  Project encourages all authors to not restrict any
-		  files, source or binary, from being modified.)
-	  
-	  No Discrimination Against Persons or Groups
-	  
-	  
-		  The license must not discriminate against any person
-		  or group of persons.
-

Re: First draft of review of policy must usage

[Luk Claes]

Manoj Srivastava wrote:
> Hi,

Hi Manoj

Can everyone please focus on the release and discuss things that don't help to
release on December 4th at all till after that date?

Thank you very much.

Luk

PS: For those people that seem to think they can't help: there is still a long
list of RC bugs, the release notes definitely still need work, translations
can still be improved, installation and upgrade tests are always welcome...

-- 
Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D
Fingerprint:   D5AF 25FB 316B 53BB 08E7   F999 E544 DE07 9B7C 328D



signature.asc
Description: OpenPGP digital signature

Re: First draft of review of policy must usage

[Manoj Srivastava]

Dear Luk,

On Wed, 25 Oct 2006 08:16:59 +0200, Luk Claes <[EMAIL PROTECTED]> said: 

> Manoj Srivastava wrote:
>> Hi,

> Hi Manoj

> Can everyone please focus on the release and discuss things that
> don't help to release on December 4th at all till after that date?

> Thank you very much.

The next time you feel the urge to be patronizing, ponder on
 these:
  a) what gives you the right to pontificate and  tell people what to
 do from your high horse?
  b) Why do you think getting on a soap box is likely to help
 anything, including  a dialogue on this list?
  c) that for some of us doing things right trumps releasing on some
 arbitrary deadline hands down?

Part of doing things right it to lick the technical policy in
  shape; reviewing the must directives for bloat has been long
  overdue. If the policy is so far from reality that release managers
  do not consider violation of must directives as something that would
  compromise the high standards of what Debian considers fit for
  release, then it seems to me we need to fix policy.

Now, if you can stop lecturing and review the changes, and
 provide feedback on whether my judgement for thechanges is on the
 right path, you would be helping. If noit, could you please let the
 rest of us work on getting a better technical policy out? 

thank you,

manoj
-- 
Give him an evasive answer.
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]