Re: Please hint gnome-hearts-0.1.3-2 for migration to testing

[Loïc Minier]

On Wed, Dec 13, 2006, Andreas Barth wrote:
> * Sander Marechal ([EMAIL PROTECTED]) [061213 07:50]:
> > Please hint gnome-hearts-0.1.3-2 for migration to testing. It fixes two
> > crash bugs and simplifies dependencies. Summary of the changes:
> approved.

 You seem to have hinted gnome-hearts 0.1.3-1 which has a RC bug fixed
 in -2; please hint -2.

   Thanks,
-- 
Loïc Minier <[EMAIL PROTECTED]>
 "Forget your stupid theme park! I'm gonna make my own! With hookers!
  And blackjack! In fact, forget the theme park!"  -- Bender


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

Freeze exception request: postgresql-common

[Martin Pitt]

Hi release team,

I recently fixed all remaining bugs in postgresql-common to brush it
up for the etch release and to have it officially bug-free again :)
(apart from one unreproducible report which is probably PEBCAK).

I would like to see this in Etch:

postgresql-common (69) unstable; urgency=medium

  * Urgency medium, only safe fixes and this needs to go into Etch due to
first bug fix.
  * debian/supported_versions: Gracefully fall back on an unknown
distribution, instead of failing package installation completely.
Closes: #400628
  * debian/supported_versions: Some minor factorization.
  * Add Spanish debconf translations, thanks to Javier Fernández-Sanguino
Peña! Closes: #402198
  * pg_createcluster: Add --locale and the various --lc_* options that initdb
supports, and mention in POD that directly setting --encoding is not
recommended. Closes: #395083
  * t/050_encodings.t: Use pg_createcluster's new --locale option in some test
cases.
  * Make testsuite work with just one installed major version (mainly boils
down to disabling upgrade tests).

 -- Martin Pitt <[EMAIL PROTECTED]>  Sat,  9 Dec 2006 14:37:42 +0100

The #400628 is really important for any Debian derivative. #395083 is
the only new feature, and a pretty minor one (just passthrough of
options to initdb, covered by the testsuite). The rest is cosmetics
and test suite fixes.

Thanks for considering,

Martin

-- 
Martin Pitt  http://www.piware.de
Ubuntu Developer   http://www.ubuntulinux.org
Debian Developerhttp://www.debian.org


signature.asc
Description: Digital signature

Freeze exception request: postgresql-{7.4,8.1}

[Martin Pitt]

Hi Release team,

The 5-day testing period of postgresql-7.4 and -8.1 is over, and I
would like to ask you to let it into Sarge. There are only two
cosmetic changes:

postgresql-7.4 (1:7.4.14-2) unstable; urgency=medium

  * Urgency medium, since only trivial bug fixes.
  * Add watch file.
  * debian/control: Fix spelling of 'Tcl'. (See #401191)

 -- Martin Pitt <[EMAIL PROTECTED]>  Fri,  8 Dec 2006 22:36:30 +0100

postgresql-8.1 (8.1.5-2) unstable; urgency=medium

  * Urgency medium because only trivial changes.
  * Add watch file.
  * debian/control: Fix spelling of 'Tcl'. Closes: #401191

 -- Martin Pitt <[EMAIL PROTECTED]>  Fri,  8 Dec 2006 22:33:41 +0100

Thanks for considering,

Martin
-- 
Martin Pitt  http://www.piware.de
Ubuntu Developer   http://www.ubuntulinux.org
Debian Developerhttp://www.debian.org


signature.asc
Description: Digital signature

Re: Missing aranym - problem with powerpc

[Steve Langasek]

Hi Antonin,

On Mon, Dec 11, 2006 at 12:26:27PM +0100, Antonin Kral wrote:
> sorry for disturbing gentlemen, but I have problem with powerpc and
> aranym package. Package cannot be build because obscure problem with
> debheper (it reports, that dh_testdir is missing). I have tried to build
> package by hand on powerpc and everything went fine. I have requested
> Ryan Murray and others to help with this, but they were probably
> overloaded with freez.

> So I really want to have new aranym in the release. Could you help me
> with this? Thanks a lot.

> http://packages.qa.debian.org/a/aranym.html

The problem in question was a buildd bug rather than a problem with
debhelper; in any case aranym has subsequently been given back and
successfully built.  I've gone ahead and unblocked this package into
testing, since the missing build was the only reason aranym missed the
freeze.

Thanks,
-- 
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: Hint for autodir (closes RC) and comments about linux-kernel-headers

[Steve Langasek]

On Mon, Dec 11, 2006 at 12:17:12PM +0100, Francesco P. Lovergine wrote:
> After about 20 days of work with both autodir and autofs4 upstream
> a final fix for autodir is available (closes #399454). 
> Incidentally 0.9.8 is almost the same of 0.9.7 (integrating my previous fix
> for an header file and an initial trial to fix the above bug) at upstream 
> level 
> and we are quite confident it does not impact stability in respect with 
> 0.9.7. 
> Just in case I could provide a 1:0.9.7-1 if required (0.9.7 was the last 
> available 
> version in testing AFAIK).

> About the fix, as communicated in #debian-kernel, just FYI:

>  FYI: #399454 is essentially a bug in the auto_fs4.h header
> file, as resulted by talking with autofs and autodir upstreams (API
> breakage due to a change in a union used both in v4 and
> v5). The issue potentially impact any program built on
> 2.6.17+ and depending on auto_fs4.h.
>  any program which still uses v4 protocol, indeed
>  autofs upstream is fixing on his side for the kernel, but I
> wonder if we need to fix as well etch linux-kernel-headers
>  of course this is not a problem for debian binaries, but i
> think developers would not appreciate a broken header in etch for their
> buildings and the issue is quite obscure

If the union is different between v4 and v5, what would a *fixed* header
look like?  Is this anything other than picking which protocol to be
incompatible with?

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

[Fwd: backupninja_0.9.4-5_i386.changes ACCEPTED]

[Micah Anderson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Please allow this package into etch as it fixes a RC bug, and has no
other changes. Danke.

micah

-  Original Message 
Subject: backupninja_0.9.4-5_i386.changes ACCEPTED
Date: Wed, 13 Dec 2006 06:02:02 +
From: Debian Installer <[EMAIL PROTECTED]>
To: Micah Anderson <[EMAIL PROTECTED]>


Accepted:
backupninja_0.9.4-5.diff.gz
  to pool/main/b/backupninja/backupninja_0.9.4-5.diff.gz
backupninja_0.9.4-5.dsc
  to pool/main/b/backupninja/backupninja_0.9.4-5.dsc
backupninja_0.9.4-5_all.deb
  to pool/main/b/backupninja/backupninja_0.9.4-5_all.deb


Override entries for your package:
backupninja_0.9.4-5.dsc - source admin
backupninja_0.9.4-5_all.deb - optional admin

Announcing to debian-devel-changes@lists.debian.org
Closing bugs: 402679


Thank you for your contribution to Debian.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFgMQh9n4qXRzy1ioRAsOGAKCuCO0avXrrBrq4gmfMEq3st8+CrwCfYe6y
l6CVjrwSsT3/s+z2d7V/7qw=
=xvPk
-END PGP SIGNATURE-


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

Please unblock python-njb

[Jaldhar H. Vyas]

I uploaded python-njb last night with priority: high and a note in the 
changelog that it fixes RC bug #402760.  Please unblock it.


--
Jaldhar H. Vyas <[EMAIL PROTECTED]>
La Salle Debain - http://www.braincells.com/debian/


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

Re: [Pkg-kde-extras] Re: digikam 0.8.2 for etch, the next Debian release!? (due to exiv2 0.12)

[Achim Bohnet]

On Wednesday, 13. December 2006 16:59, Andreas Huggel wrote:
> On Wednesday 13 December 2006 03:35, Achim Bohnet wrote:
> > Hi exiv2 developers,

Hi Andreas,

thx for all the infos comments below.
> >
> > the debian-release managers do not accept a library
> > transition from exiv2 0.10 to 0.12 as etch is already
> > frozen:
> >
> >   
> > http://lists.alioth.debian.org/pipermail/pkg-kde-extras/2006-December
> >/002193.html
> > http://lists.debian.org/debian-devel-announce/2006/12/msg4.html
> >
> > Digikam 0.9.0 rc2 requires exiv2 0.12 for good reasons AFAIU:
> >
> > http://www.digikam.org/?q=node/177
> >
> > With digikam rc1 several people observed crashes with exiv2 0.10 in
> > debian too.
> >
> >
> > So as is, rc2 in debian etch is not possible due to missing exiv2
> > 0.12.  rc1 crashes and has therefore release critical bugs.  So
> > only 'save' option would be to go back to digikam 0.8.2.
> >
> > AFAICS the only way to get 0.9.0 rc2 into debian at this stage:
> >
> >   o why is exiv2 0.10 in etch more risky that an 0.12 upgrade?
> 
> http://www.exiv2.org/changelog.html

Mhmm, this lists a handful of crashes and mentions too small 'buffer'
as fixed between 0.10 and 0.12.

> 0.10 is not an option for digikam 0.9.0 rc2, see below. There is a crash 
> (exiv2 bug #482) reported by ufraw which was fixed in 0.11 and an open 
> Debian bug (#396060) for libexiv2-dev from ufraw. The situation may not 
> be as critical for the other Debian applications which use exiv2, I am 
> not aware of any exiv2 related problems they have.
> 
> >   o how risky is 0.10 -> 0.12 for apps using it
> 
> It involves subtle API changes. Applications need to be tested and need 
> to be checked to determine if they are affected. I suggest to check 
> with the application developers. The only feedback I have is an 
> informal heads-up from the ufraw author 

'Subtle' API changes do not sound good short before release :(
> 
> Udi> I noticed that you bumped Exiv2 version to 0.12
> Udi> and tested it (on linux) with UFRaw, and had no problem.

Good, so ufraw and digikam are happy with libexiv 0.12

> >
> > New features of the library and superior applications using the
> > lib are unfortunately not relevant at this stage of the debian
> > etch release cycle.

So my personal summary is:

o follow the 0.8.2 for etch/testing route :(

o get libexiv2 0.12 and all apps that depend ASAP into
  experimental (I'll try to upload backports of them
  for more testing into my repos)

o libexiv2 fixes between 0.10 and 0.12 need a more careful
  look before etch release

If due to last point a 0.10 -> 0.12 migration seem less risky than
sticking with 0.10, we have at least 'tested' pkgs in experimental.

> >
> > Thx for any input,
> > Achim
> 
> On a personal note: If digikam 0.9.0 rc2 is ready to be included in 
> etch, please do not drop it because of this Debian issue.

FWIW: I use it since 0.9 beta1.  Never regret it.

> Seeing their work in a distribution is vital reward and incentive for 
> developers, recent versions of applications are vital for distros. 
> digikam users and developers have contributed a lot of time and effort 
> to improve exiv2 recently, so that it does what they need. Gilles 
> Caulier, the digikam coordinator, is an active exiv2 developer. 
> Consequently, many of the recent changes and bugfixes are important for 
> digikam, some are critical.

Yeah, the situation is very unsatisfying for me too.  Bad timing :(
libexiv2 0.12 and digikam 0.9 final ready some week earlier or etch
frozen some week later and there would be no problem at all.

> So if digikam 0.9.0 rc2 is ready for etch, there must be a creative way 
> to include exiv2 0.12 too, maybe so that it can be used by digikam 
> only. Eg, what about including it in digikam with static linkage, or a 
> 0.12 package just for digikam in addition to 0.10?

I'll try to work other with the others in experimental on a solution.

> Let me know if I can help, I am really looking forward to etch with the 
> latest digikam.

Me too.
> 
> Thanks for all your great work on Debian!
> 
> Andreas 
> (Debian fan, exiv2 author)

Thx for your create work too.  exiv2 is an important
peace of software for everyone, liking free software
and digital cameras!

Achim
-- 
  To me vi is Zen.  To use vi is to practice zen. Every command is
  a koan. Profound to the user, unintelligible to the uninitiated.
  You discover truth everytime you use it.
  -- [EMAIL PROTECTED]


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

Re: Hinting my packages in :)

[Daniel Baumann]

Luk Claes wrote:
> We do have time to review them, but they are no high priority. They will
> probably be reviewed later...

Just saw that they were unblocked today by you, thanks.

-- 
Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
Email:  [EMAIL PROTECTED]
Internet:   http://people.panthera-systems.net/~daniel-baumann/


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

Re: please also hint nvidia legacy

[Randall Donald]

On Wed, 2006-13-12 at 08:26 +0100, Andreas Barth wrote:
> * Randall Donald ([EMAIL PROTECTED]) [061212 20:36]:
> > Thanks for the hints on nvidia-graphics-drivers and modules.
> > 
> > Now that 2.6.18-3 is in, please may I also have the same hinting for 
> > nvidia-graphics-drivers-legacy
> > nvidia-graphics-legacy-modules-amd64
> > and
> > nvidia-graphics-legacy-modules-i386
> 
> nvidia-graphics-legacy-modules-i386 is already current. I started
> pushing them through, but please consider to convert the
> arch=all-packages to arch=amd64 respective arch=i386.
> 
> 
Now uploaded BTW.


Regards,
randy
-- 

Randall Donald [EMAIL PROTECTED]
http://www.khensu.org[EMAIL PROTECTED]
Programmer/Debian Developer GnuPG: 6C27DEAB



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

linux-wlan-ng in etch

[Enrico Tassi]

I've just uploaded a new version to unstable that restores a missing
file that prevents the correct loading of firmware and reverts a patch
taken from Ubuntu that made firmware loading impossible.

The frozen version 0.2.5-2 is really close to the one in unstable
0.2.6+svn20061108-1 that essentially adds a
small patch to make it more network/interfaces friendly (so that you can
use the gnome-network-*) and compilation fixes for kernel 2.6.19. 
The incoming package is 0.2.6+svn20061108-2.

Version 0.2.5-2 manifests only the first problem (missing file) and
since etch will be 2.6.18 the compilation fixes added in 0.2.6+ will be
useless. Anyway, the better compatibility with the gnome stuff makes me
think that it would be better to let 0.2.6+svn20061108-2 enter etch,
instead of providing a minimal fix against 0.2.5.

Do you agree?

Cheers.
-- 
Enrico Tassi


signature.asc
Description: Digital signature

Please hint cyrus-sasl2/2.1.22.dfsg1-8

[Fabian Fagerholm]

Hello,

Please hint cyrus-sasl2/2.1.22.dfsg1-8 for testing migration.

This version tightens the dependencies of the library and transitions
libsasl2-gssapi-mit (previously provided by Source: cyrus-sasl2-mit) to
libsasl2-modules-gssapi-mit, as discussed in another thread.

Here's the changelog:

cyrus-sasl2 (2.1.22.dfsg1-8) unstable; urgency=high

  [ Fabian Fagerholm ]
  * debian/control, libsasl2-2: update Conflicts on Postfix, need a more
recent version still for everything to work.
  * debian/control: add libsasl2-gssapi-mit transitional package.
  * debian/control, libsasl2-2: add versioned Conflicts: libsasl2-gssapi-mit
and libsasl2-krb4-mit. This means Kerberos 4 is no longer supported.
  * debian/control, libsasl2-modules-gssapi-mit: add versioned Conflicts: and
Replaces: libsasl2-gssapi-mit, remove Provides: libsasl2-gssapi-mit.
  * debian/TODO: remember to remove the transitional packages post-etch.

 -- Fabian Fagerholm <[EMAIL PROTECTED]>  Wed, 13 Dec 2006 23:22:02 +0200

Thanks,
-- 
Fabian Fagerholm <[EMAIL PROTECTED]>


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

Re: Question about removal of cyrus-sasl2-mit

[Fabian Fagerholm]

On Wed, 2006-12-13 at 16:11 +0200, Fabian Fagerholm wrote:
> I'm hoping to hear something from Sam with regard to the Kerberos 4
> package, but I'm going to upload a new version of cyrus-sasl2 with a
> libsasl2-gssapi-mit transition package and the neccessary
> Depends/Conflicts/Replaces dance no later than tomorrow.

I just uploaded cyrus-sasl2 2.1.22.dfsg1-8 with the necessary changes to
transition libsasl2-gssapi-mit to libsasl2-modules-gssapi-mit and drop
the Kerberos 4 packages completely (Conflict with the 2.1.19...
version).

I'll send a separate message to -release asking for hinting, so it
doesn't get lost in this thread.

Roberto: did you file the removal bug already? If not, feel free to do
so now.

Sam (and Russ): If you want us to provide Kerberos 4 support, now is the
time to act. Change --disable-krb4 to --enable-krb4 in cyrus-sasl2's
debian/rules and fix the build breakage that it causes. Personally, I
think it's not worth it, but if you want to do the work, I'll be glad to
include it in the package.

Cheers,
-- 
Fabian Fagerholm <[EMAIL PROTECTED]>


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

Re: Request for an "etch-ignore carte blanche" for alternative texlive dependencies

[Frank Küster]

Norbert Preining <[EMAIL PROTECTED]> wrote:

>> [ the bug reports we submitted so far do not specify exact dependencies
>> to use ]
>> 
>> Indeed, since this requires knowledge about the internals of the package
>> that needs more than a cursory look at the sources.  The splitting of
>
> Well. If the maintainers of the respective packages would provide as
> with a list of necessary items (not only "latex") then we can do this.
> But I will not go through tons of C/perl/python/whatever code to search
> for LaTeX style files or fonts or whatever to find what is necessary.
> Maintainers should know this.

I have started to write a "receipe" for maintainers.  After the next
sync pull (I think a couple of minutes after 21:00 UTC), it should be at
http://pkg-tetex.alioth.debian.org/mapping-texlive.html 

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

Re: Coordinating to let some TeX-related packages in: tex-common

[Frank Küster]

Andreas Barth <[EMAIL PROTECTED]> wrote:

> * Frank Küster ([EMAIL PROTECTED]) [061211 20:34]:
>> [...]
>
> tex-common approved.

Thank you.  You gave positive feedback about letting tetex-base in, but
didn't add a hint yet.  Just forgotten, or are we waiting for something?

Regards, Frank

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

Please hint ngircd 0.10.0-3 into etch

[Mario Iseli]

Dear release team,

my AM (formorer) today uploaded the new version of ngircd for me which
includes just a little fix in the default config file, there was a
"="-character missing and I thought it's impossible to release this ugly
little bug. Yeah, it's almost built on all architectures except sparc
and m68k. Could you please already add the hint for it since there isn't
really a diff to the last version.

Thank you very much, hope this was my last issue before etch...

-- 
  .''`. Mario Iseli <[EMAIL PROTECTED]>
 : :'  :proud user of Debian unstable
 `. `'`
   `-  Debian - when you have better things to do than fixing a system


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

Please hint 1:3.1r2-6 for etch

[Arnaud Fontaine]

Hello,

Could you please unlock squashfs  1:3.1r2-6 for etch? It only contains a
missing  manpage for  a binary  and a  patch which  prints  the progress
during the creation of a squashfs file system.

Regards,
Arnaud Fontaine


pgpIbGw4e7pek.pgp
Description: PGP signature

Please unblock binutils-h8300-hms

[Michael Tautschnig]

Dear Release-Team,

please unblock binutils-h8300-hms (2.16.1-4) as it closes a critical bug
(#402821) by a patch already approved upstream and must replace the version
which is currently in testing.

Thanks in advance,
Michael



pgpqmfi0agoJS.pgp
Description: PGP signature

Re: Security team's opinion

[Moritz Muehlenhoff]

Martin Schulze wrote:
> > > > there are two issues where I would like to ask you to comment on:
> > > > 
> > > > - mantis: We have two requests to allow it in. Is this ok from your
> > > >   side? (No bug id, sorry - in case that not, could you please open an
> > > >   RC bug on mantis?)
> > > 
> > > Why should the Security Team oppose a migration of Mantis?
> > 
> > Because it has a _really_ poor security record (21 distinct vulnerabilities
> > in the last two years!), which were extremely hard to fix, as upstream
> > kept information hidden in inaccessible bugs and were thus unadressed for
> > a long time.
> 
> Is the version of Mantis in stable kicked out during a dist-upgrade?
> If not, users will stay with the old version and will probably be more
> harmed compared to if they would upgrade to the newer version.

While this is true, this argument applies for every piece of software
removed between Sarge and Etch. (and we've removed other security-buggy
packages as well)

Aptitude's "Obsolete software" section is an excellent help to find packages
like these.

Cheers,
Moritz


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

Re: Bug#402829: mantis: not supportable by the security team

[Moritz Muehlenhoff]

Thijs Kinkhorst wrote:
> On Wed, 2006-12-13 at 09:49 +0100, "schönfeld / in-medias-res.com"
> wrote:
> > I quiet understand the etch release policy and I am sure that there are
> > cases where 5a matches the case. But in the case of mantis it does *not*
> > match. Because there is currently *one* open security issue which where
> > just reported and which I'm willing to fix in duration of this day. The
> > package *has* a maintainer and it is not out of date or is *too buggy*.
> 
> I think I can say something about this issue. I've been the one actually
> providing the mantis security updates in the sarge lifetime of the
> package.
> 
> I've observed the following:
> - There were many, many security problems with mantis in the sarge
>   release cyle;
> - Upstream did not provide significant details of vulnerabilities, or
>   patches. Also they did not respond to repeated requests from me for
>   that information.
> 
> > It makes me somehow angry that i invested so much work in bringing
> > mantis back in a good shape, when people can block its release by just
> > saying 'hey it had a bad history'.
> 
> You did not add here that the first result of this work only entered
> Debian a couple of weeks ago. While I do value the fact that you've been
> fixing up the package, the few weeks do not give much time to get a
> reliable indication of whether the package has made a radical change.
> 
> >  Given the information by Moritz that
> > it had 21 vulnerabilities it should be worth to mention that almost 50%
> > of the bugs I've seen affected almost dusty versions of mantis that are
> > *far* away from the current release.
> 
> I'm sorry, but I do not buy this. I've fixed a large number of bugs in
> the sarge version of Mantis. The sarge version is 1.5 years old. That
> can hardly be called "far away" or "dusty", can it?
> 
> This is about the same lifetime as expected for etch, so if mantis gets
> obsolete that fast, we're better off not packaging it.
> 
> > Also most of the bugs has been fixed upstream in a reasonable time
> > and i can *not* confirm that mantis developers do hide details of
> > bug fixes.
> 
> I *can*, having worked on actual sarge security updates.
> 
> > In fact they use their own bug tracker to track fixes for bugs and
> > the most of the security issues are IMO documented and discussed
> > there well enough to backport/implement security fixes into current
> > debian packages.
> 
> They keep bugs closed and requests to open up or to get more
> information, even after an updated version has been released, are met
> with absolute silence.
> 
> Maybe this attitude has changed radically in the past couple of months.
> Do you have concrete evidence that they did in fact change their policy
> of handling security issues? And that the code base structurally
> improved the last 1.5 years?
> 
> Please provide it then. I do not think it's convincing to use arguments
> like "it was just dusty" to support your point. Debian had the most
> recent version of mantis when sarge released. This didn't seem to be
> quite immune from vulnerabilities.
> 
> > Lastly i wanted to note that IMO using statistical numbers that are by
> > *no way* representative isn't really a good base for arguing with a poor
> > user base. And given you do trust that this 40 counted users are a
> > representative number: For this 40 counted users mantis might be *very*
> > important. And it might be even more. There might be hundred that do not
> >  participate in popcon.
> 
> But this goes for any other package aswell - the point is that these
> numbers can be seen in a relative way: there's a lot of packages that
> have way higher numbers. The security team only has a fixed amount of
> time available to support them. If a package has an exceptionally high
> amount of work compared to a relatively low usage number, this can be a
> valid argument.

JFTR, I agree completely with the situation as Thijs has summarised it.

Cheers,
Moritz










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

Re: Repackaging question

[Marcus Better]

Matthias Klose wrote:
> looked at libcommons-logging-java, jaxen, dom4j, which do not use
> maven for the build. so which sources are actually including maven
> jars?

I think we are talking about two different things here. No packages include
maven jars. Some packages use maven upstream, but in all cases we build
them with Ant. The Ant build.xml file was generated upstream by maven. (And
most build files are quite easy to recreate by hand if we were forced to do
it.)

Marcus



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

Re: Question about removal of cyrus-sasl2-mit

[Russ Allbery]

Roberto C Sanchez <[EMAIL PROTECTED]> writes:
> On Wed, Dec 13, 2006 at 01:34:09AM -0800, Steve Langasek wrote:

>> Indeed, so I think re-adding a libsasl2-gssapi-mit binary package to
>> cyrus-sasl2 would be the best option.  Is this in progress?

> There is already a libsasl2-modules-gssapi-mit.  Does the
> libsasl2-gssapi-mit binary package need to just be a dummy package which
> depends upon libsasl2-modules-gssapi-mit?

Correct.  libsasl2-modules-gssapi-mit would then also need the relevant
Replaces and versioned Conflicts.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

permission to upload lilypond 2.10 to unstable

[Thomas Bushnell BSG]

In the interests of our users (TM) I'd like to upload lilypond 2.10 to
unstable.  This is the current stable release of lilypond.

Advantages:
  Depending on how long the release takes, it may be appropriate to
transition this to testing at some point. But this is a quite minor
thing.

  Depending on how long the release takes, users of unstable should not
have to put up with 2.8 when 2.10 works.

Disadvantages:
  It becomes a little more laborious to make any necessary fixes to the
2.8 in testing (they would have to go through testing-proposed-updates).

I believe the advantages outweigh the disadvantages.

"But you could put it in experimental."

Actually, what I intend to do is put 2.11 (upstream's experimental
branch) into experimental.

Thomas



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

Re: Request for an "etch-ignore carte blanche" for alternative texlive dependencies

[Norbert Preining]

Hi all!

My few cents.

On Die, 12 Dez 2006, Frank Küster wrote:
> [rumors that texlive does not provide identical functionality compared
> to teTeX]
> 
> I've never heard someone claim that.  There are some packages missing in
> texlive that were already obsolete when sarge's tetex was released, but
> still included in current tetex, but besides that I don't think there's
> any difference.

Umpf, this rumor is rubbish. As Frank said, there may be some old
packages which have been superseeded by other ones, and which are no
longer supported, but that's all.

> [ the bug reports we submitted so far do not specify exact dependencies
> to use ]
> 
> Indeed, since this requires knowledge about the internals of the package
> that needs more than a cursory look at the sources.  The splitting of

Well. If the maintainers of the respective packages would provide as
with a list of necessary items (not only "latex") then we can do this.
But I will not go through tons of C/perl/python/whatever code to search
for LaTeX style files or fonts or whatever to find what is necessary.
Maintainers should know this.

And note that in all the bugs I have filed I told the maintainers a
suggestion, and also that they can contact me in case they need help.
Some did it, some did not respond at all.

Best wishes

Norbert

---
Dr. Norbert Preining <[EMAIL PROTECTED]>Università di Siena
Debian Developer <[EMAIL PROTECTED]> Debian TeX Group
gpg DSA: 0x09C5B094  fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
---
WEEM (n.)
The tools with which a dentist can inflict the greatest
pain. Formerly, which tool this was dependent upon the imagination and
skill of the individual dentist, though now, with technological
advances, weems can be bought specially.
--- Douglas Adams, The Meaning of Liff


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

tesseract / tesseract-ocr(-data)

[Gürkan Sengün]

hello

it was in testing, can it go into testing again so we can have it
in etch?

yours,
guerkan


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

Re: please also hint nvidia legacy

[Randall Donald]

On Wed, 2006-13-12 at 08:26 +0100, Andreas Barth wrote:
> * Randall Donald ([EMAIL PROTECTED]) [061212 20:36]:
> > Thanks for the hints on nvidia-graphics-drivers and modules.
> > 
> > Now that 2.6.18-3 is in, please may I also have the same hinting for 
> > nvidia-graphics-drivers-legacy
> > nvidia-graphics-legacy-modules-amd64
> > and
> > nvidia-graphics-legacy-modules-i386
> 
> nvidia-graphics-legacy-modules-i386 is already current. I started
> pushing them through, but please consider to convert the
> arch=all-packages to arch=amd64 respective arch=i386.
> 
> 
No Problem. I will as soon as power is restored at home and I can upload
again.


-- 

Randall Donald [EMAIL PROTECTED]
http://www.khensu.org[EMAIL PROTECTED]
Programmer/Debian Developer GnuPG: 6C27DEAB



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

Re: Repackaging question

[Matthias Klose]

Marcus Better writes:
> Matthias Klose wrote:
> > Marcus Better writes:
> >> instance we ship a lot of packages that build with Maven, but since we
> >> don't have Maven in Debian, we use the included, pre-generated, Ant build
> >> file instead. What should we do about those?
> > 
> > if these packages are in main, file a RC report and remove them, at
> > least from testing.
> 
> That's a bit drastic, no? Those packages are no different from packages with
> pre-generated configure scripts and the like, and those are accepted in
> main, IIRC.

you can recreate them using packages in main. you can't do this
with the maven jars.

> > Then package maven and maven2.
> 
> "Good idea, why don't you try it?", to quote someone on -project
> recently. :-)
> 
> Actually I'm planning to have a go at those, but they are rather
> complicated.
> 
> > which packages are these?
> 
> AFAICT, all of Jakarta Commons, dom4j, jaxen, and probably a lot more. Plus

looked at libcommons-logging-java, jaxen, dom4j, which do not use
maven for the build. so which sources are actually including maven
jars?

> upcoming Tomcat 6.

that's easy. package it for non-free or don't package it.


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

Re: digikam 0.8.2 for etch, the next Debian release!? (due to exiv2 0.12)

[Andreas Huggel]

On Wednesday 13 December 2006 03:35, Achim Bohnet wrote:
> Hi exiv2 developers,
>
> the debian-release managers do not accept a library
> transition from exiv2 0.10 to 0.12 as etch is already
> frozen:
>
>   
> http://lists.alioth.debian.org/pipermail/pkg-kde-extras/2006-December
>/002193.html
> http://lists.debian.org/debian-devel-announce/2006/12/msg4.html
>
> Digikam 0.9.0 rc2 requires exiv2 0.12 for good reasons AFAIU:
>
>   http://www.digikam.org/?q=node/177
>
> With digikam rc1 several people observed crashes with exiv2 0.10 in
> debian too.
>
>
> So as is, rc2 in debian etch is not possible due to missing exiv2
> 0.12.  rc1 crashes and has therefore release critical bugs.  So
> only 'save' option would be to go back to digikam 0.8.2.
>
> AFAICS the only way to get 0.9.0 rc2 into debian at this stage:
>
>   o why is exiv2 0.10 in etch more risky that an 0.12 upgrade?

http://www.exiv2.org/changelog.html

0.10 is not an option for digikam 0.9.0 rc2, see below. There is a crash 
(exiv2 bug #482) reported by ufraw which was fixed in 0.11 and an open 
Debian bug (#396060) for libexiv2-dev from ufraw. The situation may not 
be as critical for the other Debian applications which use exiv2, I am 
not aware of any exiv2 related problems they have.

>   o how risky is 0.10 -> 0.12 for apps using it

It involves subtle API changes. Applications need to be tested and need 
to be checked to determine if they are affected. I suggest to check 
with the application developers. The only feedback I have is an 
informal heads-up from the ufraw author 

Udi> I noticed that you bumped Exiv2 version to 0.12
Udi> and tested it (on linux) with UFRaw, and had no problem.

>
> New features of the library and superior applications using the
> lib are unfortunately not relevant at this stage of the debian
> etch release cycle.
>
> Thx for any input,
> Achim

On a personal note: If digikam 0.9.0 rc2 is ready to be included in 
etch, please do not drop it because of this Debian issue.
Seeing their work in a distribution is vital reward and incentive for 
developers, recent versions of applications are vital for distros. 
digikam users and developers have contributed a lot of time and effort 
to improve exiv2 recently, so that it does what they need. Gilles 
Caulier, the digikam coordinator, is an active exiv2 developer. 
Consequently, many of the recent changes and bugfixes are important for 
digikam, some are critical.
So if digikam 0.9.0 rc2 is ready for etch, there must be a creative way 
to include exiv2 0.12 too, maybe so that it can be used by digikam 
only. Eg, what about including it in digikam with static linkage, or a 
0.12 package just for digikam in addition to 0.10?

Let me know if I can help, I am really looking forward to etch with the 
latest digikam.

Thanks for all your great work on Debian!

Andreas 
(Debian fan, exiv2 author)


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

Please include mimedefang_2.57-3 into testing

[Christoph Martin]

Hi Release Team,

please include the recently uploaded mimedefang_2.57-3 into etch. This
version includes an updated debconf translation for japanese only. See
bug #402618)

Thanks

Christoph
-- 

Christoph Martin, Leiter der EDV der Verwaltung, Uni-Mainz, Germany
 Internet-Mail:  [EMAIL PROTECTED]
  Telefon: +49-6131-3926337
  Fax: +49-6131-3922856



signature.asc
Description: OpenPGP digital signature

Re: Repackaging question

[Matthias Klose]

Marcus Better writes:
> Andrew Haley wrote:
> >  > It's a good idea to remove generated javadoc and jar files and classes.
> > 
> > Very much so.  Unless you build from source, you have no way to know
> > that the binaries correspond to that source code.  You can't even
> > guarantee that you're not violating the GPL, which requires you to
> > provide source code on demand.
> 
> That may be a valid argument, but there are more troubling cases. For
> instance we ship a lot of packages that build with Maven, but since we
> don't have Maven in Debian, we use the included, pre-generated, Ant build
> file instead. What should we do about those?

if these packages are in main, file a RC report and remove them, at
least from testing.  I don't care that much about contrib. Such
packages may exist in non-free.

Then package maven and maven2.

which packages are these?

  Matthias


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

Re: Please allow mhc into etch

[Tatsuya Kinoshita]

On December 12, 2006 at 2:05AM +0900,
tats (at debian.org) wrote:

> Please allow mhc_0.25.1+20050120-4 into etch if passed 5 days or so.
> (0 days old now)
>
> This isn't a new upstream version, but the upstream part is changed
> to fix important bugs, as follows:
>
>  - ruby-ext/lib/mhc-gtk.rb.in: Fix segfault of the gemcal command.
>(mentioned in Debian bug#384141, merged from upstream)
>  - emacs/mhc-gnus.el: Fix MIME encoding problem for Gnus.
>(no Debian bug number, merged from upstream)
>
> Other changes are translation/documentation/lintian fixes.

To describe the above bugs and show the diff, I've filed bug
reports to BTS.

  Bug#402915: mhc-utils: gemcal causes segfault when [CLOSE] is pushed
  Bug#402918: mhc: mhc-gnus causes "Invalid data for rfc2047 encoding"

Thanks,
--
Tatsuya Kinoshita


pgp4HTG7B0Zpe.pgp
Description: PGP signature

Please hint resolvconf 1.37 for etch

[Marco Nenciarini]

Please unlock resolvconf 1.37

It only contains one new po (for es), an updated po (for ja) and a
trivial fix to a serious bug (#393323).

The trivial fix is "[ -x /sbin/resolvconf ]|| exit 0" at beginning of
initscript to disable it if package is removed but not purged.

Ciao,
Marco

-- 
-
|Marco Nenciarini| Debian/GNU Linux Developer - Plug Member |
| [EMAIL PROTECTED] | http://www.prato.linux.it/~mnencia   |
-
Key fingerprint = FED9 69C7 9E67 21F5 7D95  5270 6864 730D F095 E5E4



signature.asc
Description: Digital signature

Re: Question about removal of cyrus-sasl2-mit

[Fabian Fagerholm]

On Wed, 2006-12-13 at 01:34 -0800, Steve Langasek wrote:
> Indeed, so I think re-adding a libsasl2-gssapi-mit binary package to
> cyrus-sasl2 would be the best option.  Is this in progress?

Yes.

I'm hoping to hear something from Sam with regard to the Kerberos 4
package, but I'm going to upload a new version of cyrus-sasl2 with a
libsasl2-gssapi-mit transition package and the neccessary
Depends/Conflicts/Replaces dance no later than tomorrow.

(I know that Sam is very busy with work, and so am I, so I'm focusing on
the code more than on email at the moment. Sorry if things appear to
have stalled because of this.)

-- 
Fabian Fagerholm <[EMAIL PROTECTED]>


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

enemies-of-carlotta security problem: please allow fix into etch

[Lars Wirzenius]

I've just uploaded version 1.2.4-1 of enemies-of-carlotta to unstable.
It contains a fix for CVE-2006-5875 (and only that fix), a security
problem involving badly quoted shell arguments. Please allow the new
version to enter etch as soon as possible.

I have attached the debdiff from the previous version (1.2.3-1),
currently in etch.

If there's anything I forgot to do to make this easier, please tell me.

diff -Nru /tmp/m0YNIVzyAI/enemies-of-carlotta-1.2.3/debian/changelog /tmp/WJGmpSGD2g/enemies-of-carlotta-1.2.4/debian/changelog
--- /tmp/m0YNIVzyAI/enemies-of-carlotta-1.2.3/debian/changelog	2006-12-13 15:51:48.0 +0200
+++ /tmp/WJGmpSGD2g/enemies-of-carlotta-1.2.4/debian/changelog	2006-12-13 15:51:48.0 +0200
@@ -1,3 +1,13 @@
+enemies-of-carlotta (1.2.4-1) unstable; urgency=high
+
+  * Security fix for CVE-2006-5875. There is no bug report for this, the
+problem was reported privately to me by Antti-Juhani Kaijanaho.
+  * EoC did not correctly deal with SMTP level e-mail addresses that contain
+shell meta characters. This has been fixed by running /usr/sbin/sendmail
+via fork and exec, instead of os.popen.
+
+ -- Lars Wirzenius <[EMAIL PROTECTED]>  Sun,  9 Dec 2006 15:49:22 +0200
+
 enemies-of-carlotta (1.2.3-1) unstable; urgency=low
 
   * New upstream version:
diff -Nru /tmp/m0YNIVzyAI/enemies-of-carlotta-1.2.3/eoc.py /tmp/WJGmpSGD2g/enemies-of-carlotta-1.2.4/eoc.py
--- /tmp/m0YNIVzyAI/enemies-of-carlotta-1.2.3/eoc.py	2006-11-10 19:34:52.0 +0200
+++ /tmp/WJGmpSGD2g/enemies-of-carlotta-1.2.4/eoc.py	2006-12-13 15:30:02.0 +0200
@@ -4,7 +4,7 @@
 address commands. See manual page for more information.
 """
 
-VERSION = "1.2.3"
+VERSION = "1.2.4"
 PLUGIN_INTERFACE_VERSION = "1"
 
 import getopt
@@ -80,6 +80,34 @@
 def md5sum_as_hex(s):
 return md5.new(s).hexdigest()
 
+
+def forkexec(argv, text):
+"""Run a command (given as argv array) and write text to its stdin"""
+(r, w) = os.pipe()
+pid = os.fork()
+if pid == -1:
+raise Exception("fork failed")
+elif pid == 0:
+os.dup2(r, 0)
+os.close(r)
+os.close(w)
+fd = os.open("/dev/null", os.O_RDWR)
+os.dup2(fd, 1)
+os.dup2(fd, 2)
+os.execvp(argv[0], argv)
+sys.exit(1)
+else:
+os.close(r)
+os.write(w, text)
+os.close(w)
+(pid2, exit) = os.waitpid(pid, 0)
+if pid != pid2:
+raise Exception("os.waitpid for %d returned for %d" % (pid, pid2))
+if exit != 0:
+raise Exception("subprocess failed, exit=0x%x" % exit)
+return exit
+
+
 environ = None
 
 def set_environ(new_environ):
@@ -411,14 +439,8 @@
 error("Error sending QMQP mail, mail probably not sent")
 sys.exit(1)
 else:
-recipients = string.join(recipients, " ")
-f = os.popen("%s -oi -f '%s' %s" % 
- (self.sendmail, 
-  envelope_sender, 
-  recipients),
- "w")
-f.write(text)
-status = f.close()
+status = forkexec([self.sendmail, "-oi", "-f", 
+   envelope_sender] + recipients, text)
 if status:
 error("%s returned %s, mail sending probably failed" %
(self.sendmail, status))
diff -Nru /tmp/m0YNIVzyAI/enemies-of-carlotta-1.2.3/NEWS /tmp/WJGmpSGD2g/enemies-of-carlotta-1.2.4/NEWS
--- /tmp/m0YNIVzyAI/enemies-of-carlotta-1.2.3/NEWS	2006-11-10 19:34:52.0 +0200
+++ /tmp/WJGmpSGD2g/enemies-of-carlotta-1.2.4/NEWS	2006-12-13 15:30:02.0 +0200
@@ -1,5 +1,11 @@
 NEWS file for Enemies of Carlotta, a mailing list manager
 
+Significant user-visible changes from version 1.2.3 to version 1.2.4:
+
+* A fix to CVE-2006-5875, a security problem where EoC did not quote
+  shell command line arguments properly. Thanks to Antti-Juhani
+  Kaijanaho for finding the problem.
+
 Significant user-visible changes from version 1.2.2 to version 1.2.3:
 
 * When there is a problem with MIME header encodings, don't kill EoC,


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

Re: XDG Menu Spec compliance

[Josselin Mouette]

Le mardi 12 décembre 2006 à 17:05 +0100, Marc 'HE' Brockschmidt a
écrit :
> >> I don't understand why only these few packages need to be fixed - what's
> >> up with other packages (such as alacarte, for example)?
> > Alacarte does indeed need to be fixed, as it uses
> > gnome-applications-merged instead of applications-merged. However,
> > fixing alacarte would require API additions to python-xdg, which doesn't
> > look reasonable for etch.
> 
> Will alacarte be useable with the new version of libgnome-menu? I just
> want to know if anything would break in such a step to partial
> standard-compliance.

Alacarte doesn't use libgnome-menu as a backend, but python-xdg. If I
understand correctly the purpose of applications-merged, this means
Alacarte won't be able to obtain the list of menu entries added by
third-party applications using it. Currently this is already the case,
the difference is that now gnome-panel and nautilus will correctly
display them.

In short, I don't think fixing gnome-panel will break alacarte more than
it already is.
-- 
Josselin Mouette/\./\

"Do you have any more insane proposals for me?"

Please allow xmoto 0.2.2-2 in testing

[Samuel Mimram]

Hi,

Could you please allow xmoto 0.2.2-2 in testing? Currently testing has
0.2.2-1 and the only difference between them is a patch that corrects
the url where to download new levels for the game (upstream has moved
his website).

Cheers,

Samuel.


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

Re: Bug#402829: mantis: not supportable by the security team

[Thijs Kinkhorst]

On Wed, 2006-12-13 at 09:49 +0100, "schönfeld / in-medias-res.com"
wrote:
> I quiet understand the etch release policy and I am sure that there are
> cases where 5a matches the case. But in the case of mantis it does *not*
> match. Because there is currently *one* open security issue which where
> just reported and which I'm willing to fix in duration of this day. The
> package *has* a maintainer and it is not out of date or is *too buggy*.

I think I can say something about this issue. I've been the one actually
providing the mantis security updates in the sarge lifetime of the
package.

I've observed the following:
- There were many, many security problems with mantis in the sarge
  release cyle;
- Upstream did not provide significant details of vulnerabilities, or
  patches. Also they did not respond to repeated requests from me for
  that information.

> It makes me somehow angry that i invested so much work in bringing
> mantis back in a good shape, when people can block its release by just
> saying 'hey it had a bad history'.

You did not add here that the first result of this work only entered
Debian a couple of weeks ago. While I do value the fact that you've been
fixing up the package, the few weeks do not give much time to get a
reliable indication of whether the package has made a radical change.

>  Given the information by Moritz that
> it had 21 vulnerabilities it should be worth to mention that almost 50%
> of the bugs I've seen affected almost dusty versions of mantis that are
> *far* away from the current release.

I'm sorry, but I do not buy this. I've fixed a large number of bugs in
the sarge version of Mantis. The sarge version is 1.5 years old. That
can hardly be called "far away" or "dusty", can it?

This is about the same lifetime as expected for etch, so if mantis gets
obsolete that fast, we're better off not packaging it.

> Also most of the bugs has been fixed upstream in a reasonable time
> and i can *not* confirm that mantis developers do hide details of
> bug fixes.

I *can*, having worked on actual sarge security updates.

> In fact they use their own bug tracker to track fixes for bugs and
> the most of the security issues are IMO documented and discussed
> there well enough to backport/implement security fixes into current
> debian packages.

They keep bugs closed and requests to open up or to get more
information, even after an updated version has been released, are met
with absolute silence.

Maybe this attitude has changed radically in the past couple of months.
Do you have concrete evidence that they did in fact change their policy
of handling security issues? And that the code base structurally
improved the last 1.5 years?

Please provide it then. I do not think it's convincing to use arguments
like "it was just dusty" to support your point. Debian had the most
recent version of mantis when sarge released. This didn't seem to be
quite immune from vulnerabilities.

> Lastly i wanted to note that IMO using statistical numbers that are by
> *no way* representative isn't really a good base for arguing with a poor
> user base. And given you do trust that this 40 counted users are a
> representative number: For this 40 counted users mantis might be *very*
> important. And it might be even more. There might be hundred that do not
>  participate in popcon.

But this goes for any other package aswell - the point is that these
numbers can be seen in a relative way: there's a lot of packages that
have way higher numbers. The security team only has a fixed amount of
time available to support them. If a package has an exceptionally high
amount of work compared to a relatively low usage number, this can be a
valid argument.

> I would like to further discuss this topic and hopely we could find a
> con sense.

Sure, I really hope we can get the mantis package in a good shape. I'm
also all for giving a second chance to previously leaky software to
change their habits.

But that *does* require concrete evidence that something has indeed
changed. Especially if you're requesting something like this *very*
shortly before the release, with little time to revert any mistakes.

It's up to you now: show why mantis deserves the second chance, and why
it's essential that it deserves it, at this point, instead of e.g. for
Lenny.

By the way, I cannot stress too much that I really appreciate your work
of getting the sid version in order. I'm just wary to put it in a stable
version just a few weeks after.


Thijs


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

Updating libgksu on testing

[Gustavo Noronha]

Hello,

I would like to request that libgksu 2.0.3-3 be migrated to testing, whenever 
it qualifies. I made this upload to fix a (from a UI point of view) reasonably 
big annoyance related to startup notification; see bug #401268.

The changelog follows:

libgksu  (2.0.3-3) unstable; urgency=medium

   * debian/patches/02_desktop_startup_id_fix.diff:
   - fixes the desktop startup notification variable not being set; sudo
 seems to unset the variable anyway, will talk to sudo's maintainer
 (Closes: #401268)
   * urgency set to medium because this is a problem that is bothering
 quite a bit, it seems, and the fix is reasonable simple

 -- Gustavo Noronha Silva <[EMAIL PROTECTED]>  Thu, 7 Dec 2006 09:33:33 -0200 

Thanks,

--
Gustavo Noronha <[EMAIL PROTECTED]>


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

Please migrate yada 0.52 into etch

[Piotr Roszatycki]

Hi.

The yada 0.51 from etch has some important bug 

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=402767

It makes a problem if the same package provides a shared library and the 
binary which depends on this library.

The yada 0.52 from sid has applied the bugfix only for this issue and it is 
safe for packages built with previous version. It fixes only just a bug.

Please migrate current version from ustable to etch. Thank you.
-- 
Piotr Roszatycki


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

Re: Question about removal of cyrus-sasl2-mit

[Roberto C. Sanchez]

On Wed, Dec 13, 2006 at 01:34:09AM -0800, Steve Langasek wrote:
> 
> Indeed, so I think re-adding a libsasl2-gssapi-mit binary package to
> cyrus-sasl2 would be the best option.  Is this in progress?
> 

There is already a libsasl2-modules-gssapi-mit.  Does the
libsasl2-gssapi-mit binary package need to just be a dummy package which
depends upon libsasl2-modules-gssapi-mit?

Regards,

-Roberto
-- 
Roberto C. Sanchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Trac 0.10.3 final release

[Otavio Salvador]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

We're waiting rc1 release to migrate to testing but upstream release
the final release and I checked the interdiff between both. It's
basically the version change and one file that was removed.
diff -Nur trac-0.10.3~rc1/ChangeLog trac-0.10.3/ChangeLog
--- trac-0.10.3~rc1/ChangeLog	2006-12-07 18:10:35.0 -0200
+++ trac-0.10.3/ChangeLog	2006-12-12 16:44:08.0 -0200
@@ -1,3 +1,16 @@
+Trac 0.10.3 (Dec 12, 2006)
+http://svn.edgewall.org/repos/trac/tags/trac-0.10.3
+
+ Trac 0.10.3 is a bug fix release. The following list contains only a 
+ few highlights:
+
+ * Timeline fail to load with a "NoSuchChangeset" error message (#4132).
+ * Timed out MySQL connections not handled properly (#3645).
+ * Subversion repository resync broken. (#4204).
+
+ The complete list of closed tickets can be found here:
+   http://trac.edgewall.org/query?status=closed&milestone=0.10.2
+
 Trac 0.10.3rc1 (Dec 7, 2006)
 http://svn.edgewall.org/repos/trac/tags/trac-0.10.3rc1
 
Binary files trac-0.10.3~rc1/doc/trac_icon_16x16.png and trac-0.10.3/doc/trac_icon_16x16.png differ
Binary files trac-0.10.3~rc1/doc/trac_icon_32x32.png and trac-0.10.3/doc/trac_icon_32x32.png differ
diff -Nur trac-0.10.3~rc1/PKG-INFO trac-0.10.3/PKG-INFO
--- trac-0.10.3~rc1/PKG-INFO	1969-12-31 21:00:00.0 -0300
+++ trac-0.10.3/PKG-INFO	2006-12-12 16:45:14.0 -0200
@@ -0,0 +1,15 @@
+Metadata-Version: 1.0
+Name: trac
+Version: 0.10.3
+Summary: Integrated scm, wiki, issue tracker and project environment
+Home-page: http://trac.edgewall.org/
+Author: Edgewall Software
+Author-email: [EMAIL PROTECTED]
+License: BSD
+Description: 
+Trac is a minimalistic web-based software project management and bug/issue
+tracking system. It provides an interface to the Subversion revision control
+systems, an integrated wiki, flexible issue tracking and convenient report
+facilities.
+
+Platform: UNKNOWN
diff -Nur trac-0.10.3~rc1/RELEASE trac-0.10.3/RELEASE
--- trac-0.10.3~rc1/RELEASE	2006-12-07 18:10:35.0 -0200
+++ trac-0.10.3/RELEASE	2006-12-12 16:44:08.0 -0200
@@ -1,11 +1,8 @@
-Release Notes for Trac 0.10.3rc1
-
-December 7, 2006
+Release Notes for Trac 0.10.3
+=
+December 12, 2006
 
-NOTE: This is a release candidate, the real 0.10.3 will hopefully be
-  released early next week.
-
-We're happy to announce the Trac 0.10.3-rc1 release, available from:
+We're happy to announce the Trac 0.10.3 release, available from:
 
   http://trac.edgewall.org/wiki/TracDownload
 
@@ -14,7 +11,7 @@
 
   http://trac.edgewall.org/wiki/MailingList
 
-Trac 0.10.3 is a bug fix release and fixes few bugs introduced in the 
+Trac 0.10.3 is a bug fix release and fixes a few bugs introduced in the 
 0.10.1 and 0.10.2 releases. A brief summary of major changes:
 
  * Timeline fail to load with a "NoSuchChangeset" error message (#4132).
Binary files trac-0.10.3~rc1/setup_wininst.bmp and trac-0.10.3/setup_wininst.bmp differ
diff -Nur trac-0.10.3~rc1/trac/__init__.py trac-0.10.3/trac/__init__.py
--- trac-0.10.3~rc1/trac/__init__.py	2006-12-07 18:33:46.0 -0200
+++ trac-0.10.3/trac/__init__.py	2006-12-12 16:44:08.0 -0200
@@ -11,7 +11,7 @@
 """
 __docformat__ = 'epytext en'
 
-__version__ = '0.10.3dev'
+__version__ = '0.10.3'
 __url__ = 'http://trac.edgewall.org/'
 __copyright__ = '(C) 2003-2006 Edgewall Software'
 __license__ = 'BSD'
diff -Nur trac-0.10.3~rc1/trac/scripts/tests/admin-tests.txt trac-0.10.3/trac/scripts/tests/admin-tests.txt
--- trac-0.10.3~rc1/trac/scripts/tests/admin-tests.txt	2006-12-07 18:33:46.0 -0200
+++ trac-0.10.3/trac/scripts/tests/admin-tests.txt	2006-12-12 16:44:07.0 -0200
@@ -1,5 +1,5 @@
 = test_help_ok =
-trac-admin - The Trac Administration Console 0.10.3dev
+trac-admin - The Trac Administration Console 0.10.3
 
 Usage: trac-admin  [command [subcommand] [option ...]]
 
diff -Nur trac-0.10.3~rc1/wiki-default/checkwiki.py trac-0.10.3/wiki-default/checkwiki.py
--- trac-0.10.3~rc1/wiki-default/checkwiki.py	2006-08-28 14:22:51.0 -0300
+++ trac-0.10.3/wiki-default/checkwiki.py	1969-12-31 21:00:00.0 -0300
@@ -1,131 +0,0 @@
-#!/usr/bin/python
-#
-# Check/update default wiki pages from the Trac project website.
-#
-# Note: This is a development tool used in Trac packaging/QA, not something
-#   particularly useful for end-users.
-#
-# Author: Daniel Lundin <[EMAIL PROTECTED]>
-
-import httplib
-import re
-import sys
-import getopt
-
-# Pages to include in distribution
-wiki_pages = [
- "CamelCase",
- "InterMapTxt",
- "InterTrac",
- "InterWiki",
- "RecentChanges",
- "TitleIndex",
- "TracAccessibility",
- "TracAdmin",
- "TracBackup",
- "TracBrowser",
- "TracCgi",
- "TracChangeset",
- "TracEnvironment",
- "TracFastCgi",
- "TracGuide",
- "TracImport",
- "TracIni",
- "TracInstall",
- "TracInterfaceCustomization",
- "TracLinks",
- "TracLoggi

Re: Request for an "etch-ignore carte blanche" for alternative texlive dependencies

[Rene Engelhard]

Am Dienstag, 12. Dezember 2006 21:10 schrieb Frank Küster:
> This would overload the buildd's and their ftp mirrors, because the
> small "texlive" metapackage does not cover the complete teTeX, whereas
> texlive-full pulls in really everything, about 2 Gigabyte of files.  And
> it doesn't make sense to introduce new metapackages that map teTeX's
> buggy splitting scheme on the texlive packages.

Then people have to specifiy the correct build-deps. I don't see a problem 
doing that
at the beginning of the lenny cycle.

Regards,

Rene
-- 
 .''`.  René Engelhard -- Debian GNU/Linux Developer
 : :' : http://www.debian.org | http://people.debian.org/~rene/
 `. `'  [EMAIL PROTECTED] | GnuPG-Key ID: 248AEB73
   `-   Fingerprint: 41FA F208 28D4 7CA5 19BB  7AD9 F859 90B0 248A EB73

Re: please let mplayer into testing

[A Mennucc]

[this was meant for d-release (damn autocompletion)]

Moritz Muehlenhoff ha scritto:
> A Mennucc wrote:
>> Brief summary of bug:  MPlayer contains an embedded copy of FFmpeg
>> (indeed, they are developed by ~the same people); Aur=E9lien G=C9R=D4ME a=
>> nd
>> Moritz Muehlenhoff ask that the mplayer package be dynamically linked to
>>  the libraries in the Debian package ffmpeg; they consider this a RC bug.=
>>
>> Unfortunately, this cannot be currently done (mplayer does not compile
>> with current ffmpeg package;  and we are too late to update ffmpeg into
>> Etch ; more details are in the above bug report).
>>
>> So we agreed to ignore that problem for the sake of the etch release
>
> Where did I agree until now?

sorry,  I got confused in the English, that last "we"
was meant to mean "me and Aurelien" (and not including you)

anyway, shortly after I wrote that email, the situation reverted again
(for worse); so currently there is no agreement between me and Aurelien,
and I put that matter to d-ctte, in bug 402772

>> Please hint MPlayer into Etch.
> 
> I've tried it myself and it is indeed not possible to link against
> libavcodec dynamically currently. Given that mplayer was only accepted
> into the archive 2.5 months after the current ffmpeg snapshot was made
> and that mplayer is an important application I do now think we can
> ignore this RC bug for Etch as a one-time exception. In any case further
> mplayer maintenance needs to be synchronised with Debian's libav[codec|
> format], even if it means to not being able to upload the most recent
> upstream version every week.

happy to know this. May you please forward this statement into bug
402772? (I would really appreciate).

> Also, the static linking against libdv introduced in 1.0~rc1-4 should
> be reverted.

I did not mean to introduce any static linking; I will investigate


a.





signature.asc
Description: OpenPGP digital signature

Please allow openal 1:0.0.8-3 into testing

[Cyril Brulebois]

Hi,

openal 1:0.0.8-3 fixed an RC bug, with a trivial fix: s/PWD/CURDIR/
(#402408: FTBFS on alpha, mips, mipsel: doesn't build with `sudo')
and was uploaded prior to the freeze.

Since the 2-day delay is now over, please consider allowing it into
testing.

Cheers,

-- 
Cyril Brulebois

PS: In case you want the complete changelog, here it is:

openal (1:0.0.8-3) unstable; urgency=high

  * Changed `$(PWD)' to `$(CURDIR)' in debian/rules, which fixes the FTBFS on
buildds using `sudo' and not `fakeroot', since the $(PWD) is changed when
sudo is invoked, due to the user change (Closes: #402408).
  * Urgency set to `high' due to RC-buggyness.
  * Added myself in the Uploaders field.

 -- Cyril Brulebois <[EMAIL PROTECTED]>  Sun, 10 Dec 2006 10:09:35 +


pgphmdBFLfvFV.pgp
Description: PGP signature

Please hint clucene-core 0.9.16a for migration to testing

[Fathi Boudra]

Please hint clucene-core 0.9.16a for migration to testing. This is a minor 
upstream bug fix release, without API changes:
* fixed query parser escaping bug
* fixed Explanation and toString code
* added explicity CJK capabilitiy to StandardTokenizer
* fixed an error in StandardTokenizer with long words
* fixed error in InputStreamBuffer. for some libs malloc(NULL...) causes an 
error
* fixed Statistics.cpp code

Thanks,

Fathi


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

Please allow obexpushd 0.4+svn10-2 to testing

[Eugeniy Meshcheryakov]

Hello,

Important bug #401203 is fixed in this release, no other changes.

 obexpushd (0.4+svn10-2) unstable; urgency=low
 .
   * Apply patch from Hendrik Sattler to fix failure to receive files from
 SE K700i phones (closes: #401203)

Thanks,
Eugeniy Meshcheryakov


signature.asc
Description: Digital signature

Please hint childsplay-plugins-lfc_0.84-2 for etch

[Sergio Talens-Oliag]

While upgrading the childsplay package to the latest upstream vesion I did
some testing on the package and noticed that the childsplay-plugins-lfc
version that is included in etch has a bug that makes the catalan localization
of the plugin useless because it does not use the translated files when the
childsplay-lfc-names-ca is installed.

I've uploaded a new childsplay-plugins-lfc with a trivial patch that fixes the
issue (the patch is as simple as adding the language code to a python list),
I've attached an interdiff of my changes for the RM to review.

Thanks in advance,

  Sergio.

-- 
Sergio Talens-Oliag <[EMAIL PROTECTED]>   
Key fingerprint = 29DF 544F  1BD9 548C  8F15 86EF  6770 052B  B8C1 FA69
diff -u childsplay-plugins-lfc-0.84/debian/changelog 
childsplay-plugins-lfc-0.84/debian/changelog
--- childsplay-plugins-lfc-0.84/debian/changelog
+++ childsplay-plugins-lfc-0.84/debian/changelog
@@ -1,3 +1,9 @@
+childsplay-plugins-lfc (0.84-2) unstable; urgency=high
+
+  * Added catalan support to the plugin, I was sure it worked... :(
+
+ -- Sergio Talens-Oliag <[EMAIL PROTECTED]>  Wed, 13 Dec 2006 01:20:09 +0100
+
 childsplay-plugins-lfc (0.84-1) unstable; urgency=low
 
   * New upstream release.
diff -u childsplay-plugins-lfc-0.84/debian/rules 
childsplay-plugins-lfc-0.84/debian/rules
--- childsplay-plugins-lfc-0.84/debian/rules
+++ childsplay-plugins-lfc-0.84/debian/rules
@@ -3,6 +3,7 @@
 # Copyright © 2006 Sergio Talens-Oliag <[EMAIL PROTECTED]>
 
 include /usr/share/cdbs/1/rules/debhelper.mk
+include /usr/share/cdbs/1/rules/simple-patchsys.mk
 
 # Use debhelper's "dh_python" command; makefile code taken from
 # '/usr/share/cdbs/1/class/python-distutils.mk'
only in patch2:
unchanged:
--- childsplay-plugins-lfc-0.84.orig/debian/patches/01_catalan_support.diff
+++ childsplay-plugins-lfc-0.84/debian/patches/01_catalan_support.diff
@@ -0,0 +1,13 @@
+Index: lib/letterFlashcard.py
+===
+--- lib/letterFlashcard.py (revisión: 977)
 lib/letterFlashcard.py (copia de trabajo)
+@@ -26,7 +26,7 @@
+ # The locales we support, it's needed that we switch to English if we run
+ # in a non supported locale.
+ # Add any new locales to this list.
+-SUPPORTED_LOCALES = ['en','nl','fr']
++SUPPORTED_LOCALES = ['en','nl','fr','ca']
+ 
+ import os,sys,random
+ import pygame


signature.asc
Description: Digital signature

KDE packages

[Ana Guerrero]

Dear stressed people,

Please unblock the following KDE packages:

* kdebase (4:3.5.5a.dfsg.1-3)
It mostly includes changes for allow the Etch artwork provided by desktop-base.
Also, makes kdelibs-dbg depend on kdebase-dbg to get useful backtraces when 
debugging
and a couple of small bugfixes.

* kdepim (4:3.5.5.dfsg.1-3) 
This upload improves the patches applied to fix kpilot RC bug (#394534), 
reenabling some functionalities that were left out in order to get the bug
fixed sooner.

* kdeaccessibility (4:3.5.5-2)
This upload was done to remove the plugin for GStreamer 0.8 of kttsd, 
to help with the removal of GStreamer 0.8:
http://lists.debian.org/debian-devel/2006/12/msg00131.html

It also makes kdeaccessibility-dbg depend on kdelibs-dbg to get useful
backtraces when debugging.

* meta-kde-extras (5:51)
Updates "Recommends" of the metapackage kde-extras adding/renaming/removing 
packages.

* kdetoys (4:3.5.5-2)
Really small changes: a patch to add Lithuania to the country list of kweather 
and make kdetoys-dbg depend on kdelibs-dbg to get useful backtraces.

* libkexif (0.2.5-2)
Yes, this is a new upstream version, but it is a bugfix release, and it is
necessary in order to avoid a lot of problems with digikam 0.8.2 (since
digikam will be back to this version).

* kwlan (already requested by Mark Purcell)
Is it possible to reschedule a alpha buildd for the package kwlan, as it last 
failed due to insufficient build-deps:
http://buildd.debian.org/fetch.cgi?&pkg=kwlan&ver=0.5.7-1&arch=alpha&stamp=1165147522&file=log
This is what is keeping this package out of testing:
http://bjorn.haxx.se/debian/testing.pl?package=kwlan

* ksynaptics (already requested by Mark Purcell and Fathi Boudra)
http://bjorn.haxx.se/debian/testing.pl?package=ksynaptics
This package is not required for build on s390 as documented:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=383698


If you need more information in order to approve some of the unblocks, please
tell me.

Ana


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

Re: Question about removal of cyrus-sasl2-mit

[Steve Langasek]

On Mon, Dec 11, 2006 at 11:37:05PM -0800, Russ Allbery wrote:
> >> My guess is that it would be better for the new package to take care of
> >> it, since otherwise we're carrying around an old source package as well
> >> as a transitional binary package.  That seems unnecessary.

> > The only thing that scares me is the NEW processing for the transitional
> > package, which would be avoided by using the old source package to
> > create the transitional binary package. This is probably an irrational
> > fear. :)

> As I recall (and this surprised me too), if you add a transitional package
> that matches the name of a binary package currently provided by another
> source package, there's no NEW approval required.

Indeed, so I think re-adding a libsasl2-gssapi-mit binary package to
cyrus-sasl2 would be the best option.  Is this in progress?

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: Coordinating to let some TeX-related packages in: texlive-bin

[Norbert Preining]

Hi Andreas!

On Die, 12 Dez 2006, Andreas Barth wrote:
> * Frank Küster ([EMAIL PROTECTED]) [061211 20:06]:
> > [..]
> 
> textlive-bin approved.

Thanks a lot, but it seems that you have set the unblock to the -6
version, which was buggy. Please see my last email about this.
The excuses give me:
Unblock request by aba ignored due to version mismatch: 2005.dfsg.2-6
Could you please change this to -7.

Thanks a lot

Best wishes

Norbert

---
Dr. Norbert Preining <[EMAIL PROTECTED]>Università di Siena
Debian Developer <[EMAIL PROTECTED]> Debian TeX Group
gpg DSA: 0x09C5B094  fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
---
SILESIA (n. medical)
The inability to remember, at the critical moment, which is the better
side of a boat to be seasick off.
--- Douglas Adams, The Meaning of Liff


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

Re: Re: Security team's opinion

[Josselin Mouette]

Martin Schulze wrote:
> If I remember correctly, then
> 
>  a) it's not possible to switch mplayer to using the ffmpeg package unless
> i) the code is changed, and
> ii) the release team would allow the package with changed code to go
> into etch which could not be as well tested as before, and
> 
>  b) there is no stable API of ffmpeg, and maybe

Well, that's half-true. I haven't checked how mplayer looks, but for
gst-ffmpeg the changes are very small, as the really significant thing
that changes from one ffmpeg version to another is the list of codecs
(yes, that says much about the ffmpeg developers).

>  c) there's no shared ffmpeg library (?!?), and

Thanks to Sam Hocevar, we have one in Debian :)

>  d) Moritz already okayed mplayer with its own ffmpeg for etch as
> an exception.

Reading the mplayer bug logs, he agreed to make an exception for
gst-ffmpeg but not for mplayer. Now, if you all agree to make a similar
exception for mplayer, that should be fine with everyone, as you'll be
the ones suffering from the situation (along with the mirror admins).

Cheers,
-- 
Josselin Mouette/\./\

"Do you have any more insane proposals for me?"


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

Re: Dead links on /etc/rc?.d/ after a clean install of 'etch-RC1'

[Steve Langasek]

Hi Teodor,

On Fri, Dec 08, 2006 at 12:20:47PM +0200, Teodor wrote:
> I've just made a new installation of Debian using latest the CD image
> for 'net install' (RC1). The installation was completed successfully.

> This message is here to inform you that there are dead links in the
> run levels 2 and 3 as it can be seen below:

> [EMAIL PROTECTED]:~$ ls -l /etc/rc?.d/*ntp*
> lrwxrwxrwx 1 root root 20 2006-11-29 12:03 /etc/rc2.d/K77ntp-server ->
> ../init.d/ntp-server
> lrwxrwxrwx 1 root root 20 2006-11-29 12:03 /etc/rc3.d/K77ntp-server ->
> ../init.d/ntp-server
> [EMAIL PROTECTED]:~$ cd /etc/rc2.d
> [EMAIL PROTECTED]:/etc/rc2.d$ ls -l ../init.d/ntp-server
> ls: ../init.d/ntp-server: No such file or directory

> There is no 'ntp*' package installed automatically or manually.

> I don't know where else should I report this situation. If this should
> be reported to someone else please forward this message to them.

Forwarded to the debian-boot mailing list.

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#402829: mantis: not supportable by the security team

[schönfeld / in-medias-res.com]

dann frazier wrote:
> Package: mantis
> Severity: serious
>
> As per http://release.debian.org/etch_rc_policy.txt - 5a, I am opening
> this RC bug against mantis to prevent it from releasing until which
> time the security team is convinced that it is a package that can
> be reasonably supported.
>
> See the discussion thread here:
>   http://lists.debian.org/debian-release/2006/12/msg00437.html

I quiet understand the etch release policy and I am sure that there are
cases where 5a matches the case. But in the case of mantis it does *not*
match. Because there is currently *one* open security issue which where
just reported and which I'm willing to fix in duration of this day. The
package *has* a maintainer and it is not out of date or is *too buggy*.

It makes me somehow angry that i invested so much work in bringing
mantis back in a good shape, when people can block its release by just
saying 'hey it had a bad history'. Given the information by Moritz that
it had 21 vulnerabilities it should be worth to mention that almost 50%
of the bugs I've seen affected almost dusty versions of mantis that are
*far* away from the current release. Also most of the bugs has been
fixed upstream in a reasonable time and i can *not* confirm that mantis
developers do hide details of bug fixes. In fact they use their own bug
tracker to track fixes for bugs and the most of the security issues are
IMO documented and discussed there well enough to backport/implement
security fixes into current debian packages.

Lastly i wanted to note that IMO using statistical numbers that are by
*no way* representative isn't really a good base for arguing with a poor
user base. And given you do trust that this 40 counted users are a
representative number: For this 40 counted users mantis might be *very*
important. And it might be even more. There might be hundred that do not
 participate in popcon.

I would like to further discuss this topic and hopely we could find a
con sense.

Best Regards

Patrick




signature.asc
Description: OpenPGP digital signature

Re: Permission for uploading new mpdscribble release

[Steve Langasek]

Hi Michal,

On Fri, Dec 08, 2006 at 09:59:55AM +0100, Michal Čihař wrote:
> there happened new mpdscribble release which only fixes several bugs
> (one of them being reported as important in Debian BTS - #396778). Can
> this new version be uploaded?

Well, yes, though no promises it will make it for etch. :)

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#402009: libcommoncpp2-dev library transition proposal (Fwd: Bug#402009: Multiple API-incompatible changes in Common C++ 1.5.3)

[Steve Langasek]

Hi Mark,

On Sat, Dec 09, 2006 at 10:24:48AM +, Mark Purcell wrote:
> On Saturday 09 December 2006 10:10, Mark Purcell wrote:
> > The alternative, which is better, is just to back out the library
> > transition.

> Or even better-better, just don't do the library transition at all.

> The current state of libcommoncpp2 (1.5.1) and rdepends in etch is stable and 
> supportable. Thus nothing needs to be done, prior to release.

Is it certain that all the packages in testing that depend on
libcommoncpp2-1.5-0 are using the old 1.5.1 ABI?  Apparently 1.5.3-1 didn't
bump shlibs either, because there are no reverse-deps waiting on it for
propogation...  Since this package was only 7 days old at the time of
freeze, odds are good that nothing built against the new ABI made it into
testing, but that's not a guarantee.

> > Upload the previous ABI stable release 1.5.1 with an epoc and await the
> > release of etch..

> I won't upload to unstable with an epoc..  Also please ignore, or rather just 
> leave in NEW, the last upload (1.5.3) which does correctly carry forward the 
> soname change.. But is not necessary for etch.

There's no reason that it needs to stay in NEW that I can see, but we don't
make that decision anyway. :)

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: ruledispatch, turbogears and turbojson removals from testing (was: Re: ruledispatch REMOVED from testing)

[Steve Langasek]

On Thu, Dec 07, 2006 at 10:18:04AM -0200, Gustavo Noronha Silva wrote:

> ruledispatch has been removed from testing and, I believe, because of
> that turbogears and turbojson went out also; I uploaded a fix for the
> bug mentioned here (and at the hints file) on 12/04, and it should be
> fixed right now in unstable.

> Is there any action on my part necessary to get those packages back
> into testing?

Nope, I've unblocked all three packages so they should be allowed back into
testing in a couple of days.

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]