Re: Bits from the release team: the plans for etch

[Steve Langasek]

[Let's please keep this discussion on debian-devel, as debian-release is not
a discussion list, and not exactly widely followed either]

On Sun, Oct 16, 2005 at 10:28:33AM +0200, Roland Stigge wrote:

> Steve Langasek wrote:
> > NMU policy
> > ~~
> > After lots of experimentation with NMU policies during the sarge release
> > process, it's pretty clear that permissive NMU policies had a HUGE,
> > positive impact on our ability as a project to cope with outstanding
> > release-critical issues.  We don't want that to stop now just because
> > the sarge release is behind us; NMUs don't just speed up the release,
> > they're also great for helping the quality of Debian!  For this reason,
> > we would like to continue the 0-day NMU policy from sarge throughout the
> > etch release cycle.  But first, we'd like to hear from you, the
> > developers, about what *you* thought did and didn't work with NMUs for
> > sarge.

> 0-day NMUs are fine, as long as it is emphasized that it's only
> appropriate if the usual maintainer doesn't work on the issue. I.e. you
> either need to try to contact the developer or only operate on
> reasonably "old" bugs; better both.

It's easy to understand why people are opposed to too-frequent NMUs.  They
don't want to be seen as bad maintainers for having too many NMUs on their
packages; they worry about new bugs being introduced in the process; they
worry about sloppy fixes hiding bugs and preventing proper fixes from taking
place.

But let's look at the specific example that you brought up:

> Otherwise things like

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

> will happen more often, and I expect even more stupid things. As seen in
> this example, we also need to stress that NMUs must be done with special
> care and responsibility. And the NMUer needs to be sufficiently skilled
> to work on packages otherwise unknown to him.

So here's the order of events in 308406:

- an RC bug is filed about a missing package dependency during the sarge
  freeze, leaving fairly little time to fix the package for sarge
- three days later, a developer uploads an NMU which fixes this bug (good),
  but also makes a change unrelated to the RC bug and in the process breaks
  the package's build-dependencies (bad)
- the maintainer notices (good), and does his own upload later that day
  which restores the package's previous subtly-buggy behavior (?)
- the package releases with sarge (good)

So was the NMU a net win or loss for Debian?  Would this answer be different
if the NMU had made it into sarge instead of being superseded by the
maintainer?

In both scenarios, I think the NMU in question is a net win for Debian.  In
this specific case, the NMU may have turned out to be *unnecessary*, but
there's no way to know this beforehand, and it's hard even for anyone other
than the maintainer to know it after the fact either as the NMU may have
prompted the MU.  Anyway, the bug that the NMU fixed was release-critical;
the choices were to NMU the package, or wait around and hope that the
maintainer will fix it before the package is dropped from testing (and, at
that point in time, the release).  So even if perfect hindsight suggests it
would have been more efficient not to bother with the NMU, if the
alternative to NMUing is sitting around worrying about whether the
maintainer will upload, well, that's not a clear win even if the maintainer
does do an upload later.

As for the specific content of this NMU: the NMUer fixed a missing
dependency that would prevent users from being able to install the package.
In the process, a change was made that moved all of the build-depends to
Build-Depends-Indep.  This is incorrect, because policy does not require
B-D-I to be satisfied in the clean target and musixtex-slurps uses debhelper
in the clean target.  However, the impact is negligible because
musixtex-slurps builds a single arch: all package, which means the package
will never be autobuilt in an environment which expects to call the 'clean'
and 'binary-arch' targets without also calling the 'binary' target.  And
since the source package already violates policy by building the arch: all
package in the binary-arch target instead of the binary-indep target, one
more policy infraction doesn't make much difference: IMHO, Debian would have
been better off shipping musixtex-slurps_92a-2.1 than not shipping
musixtex-slurps at all.

Was it wrong to make that change in an NMU?  Sure.  Would it have hurt us if
that change had made it into a stable release?  Not really.  Should we be
worried about NMUs of poor quality hindering development?  IMHO, no -- not
based on this example.

Now, more compelling would be an example of a bad NMU that did make its way
into a stable release, and was *more* broken than the bug it was trying to
fix.  Can anyone offer an example like that?

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, an

Re: Closing bugs as submitter?

[Jan C. Nordholz]

On Mon, Oct 17, 2005 at 03:16:01AM +0200, Henning Makholm wrote:
> If I understand correctly, after version tracking was implemented, the
> fixed-in-experimental tag has been superseded by simply closing the
> bug for the current experimental version (i.e. mailing [EMAIL PROTECTED]
> with a pseudo-header giving the version in question).

Ah, thank you for the pointer - my memories of the changes made to the
BTS[1] were not as vivid as I had hoped them to be.


Regards,

Jan

[1] http://lists.debian.org/debian-devel-announce/2005/07/msg00010.html

-- 
Jan C. Nordholz



signature.asc
Description: Digital signature

Re: Closing bugs as submitter?

[Henning Makholm]

Scripsit "Jan C. Nordholz" <[EMAIL PROTECTED]>

> Now I'd like to save the maintainer some work and tag the bug
> fixed-in-experimental myself (together with a short explanatory
> message to the bug log),

If I understand correctly, after version tracking was implemented, the
fixed-in-experimental tag has been superseded by simply closing the
bug for the current experimental version (i.e. mailing [EMAIL PROTECTED]
with a pseudo-header giving the version in question).

-- 
Henning Makholm  "I tried whacking myself repeatedly
 with the cluebat. Unfortunately, it was
 not as effective as whacking someone else."


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

Re: Closing bugs as submitter?

[Jan C. Nordholz]

On Mon, Oct 17, 2005 at 02:17:01AM +0200, Jeroen van Wolffelaar wrote:
> Yes, you may do so -- if in doubt, simply write an explanatory mail to
> [EMAIL PROTECTED], and let the maintainer deal with it. If you're sure
> that what you're doing is correct, there is in general no reason to not do it.
> In order to prevent problems, I suggest being extra cautious changing the
> state of bugs if you're not completely sure how to undo any potential
> mistake you might make.
> 
> In all cases, writing mail to [EMAIL PROTECTED] is always safe to do, and
> there should always be some maintainer somewhere who will read the message can
> can act on it appropriately.
> 
> Thank you for your contribution (bugreports are also contributions in a way)
> to Debian!
> --Jeroen

Hi Jeroen (and all others),

thanks for your quick reply! I'm pretty sure about the change,
I just wanted to make sure that I'm not considered "hijacking
someone's package".

As for my contribution: I'd be happy to do more, and I'm monitoring
wnpp for packages I feel knowledgeable enough about to offer my
help and/or ask for sponsoring, but the right one just hasn't come
across yet. ;-)


Thanks again,

Jan

-- 
Jan C. Nordholz



signature.asc
Description: Digital signature

Re: Closing bugs as submitter?

[Thomas Bushnell BSG]

"Jan C. Nordholz" <[EMAIL PROTECTED]> writes:

> I'd like to ask you if it is desired (and possible at all)
> that submitters close their own bugs if they have been fixed
> without the package maintainer's noticing. The informational
> pages on b.d.o don't state whether [EMAIL PROTECTED] is obeying
> commands from everyone, and whether or not such behaviour
> (meddling with bugs as non-maintainer) would be deemed
> appropriate.

I think it's desirable, just do it correctly.

> In my special case, the bug I've reported two weeks ago
> has apparently been fixed upstream, and the latest upload
> of the package to experimental has brought the fix into
> the archive. Now I'd like to save the maintainer some work
> and tag the bug fixed-in-experimental myself (together with
> a short explanatory message to the bug log), but am unsure
> whether I'm allowed to.

Sure, go right ahead, just do it rightly.


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

Re: Closing bugs as submitter?

[Stephen Gran]

This one time, at band camp, Jan C. Nordholz said:
> Dear list,
> 
> I'd like to ask you if it is desired (and possible at all)
> that submitters close their own bugs if they have been fixed
> without the package maintainer's noticing. The informational
> pages on b.d.o don't state whether [EMAIL PROTECTED] is obeying
> commands from everyone, and whether or not such behaviour
> (meddling with bugs as non-maintainer) would be deemed
> appropriate.
> 
> In my special case, the bug I've reported two weeks ago
> has apparently been fixed upstream, and the latest upload
> of the package to experimental has brought the fix into
> the archive. Now I'd like to save the maintainer some work
> and tag the bug fixed-in-experimental myself (together with
> a short explanatory message to the bug log), but am unsure
> whether I'm allowed to.

Yes, that would be absolutely fine.  The controlbot is (for both good
and bad) available to all.
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: Closing bugs as submitter?

[Jeroen van Wolffelaar]

On Mon, Oct 17, 2005 at 02:09:06AM +0200, Jan C. Nordholz wrote:
> Dear list,
> 
> I'd like to ask you if it is desired (and possible at all)
> that submitters close their own bugs if they have been fixed
> without the package maintainer's noticing. The informational
> pages on b.d.o don't state whether [EMAIL PROTECTED] is obeying
> commands from everyone, and whether or not such behaviour
> (meddling with bugs as non-maintainer) would be deemed
> appropriate.
> 
> In my special case, the bug I've reported two weeks ago
> has apparently been fixed upstream, and the latest upload
> of the package to experimental has brought the fix into
> the archive. Now I'd like to save the maintainer some work
> and tag the bug fixed-in-experimental myself (together with
> a short explanatory message to the bug log), but am unsure
> whether I'm allowed to.

Yes, you may do so -- if in doubt, simply write an explanatory mail to
[EMAIL PROTECTED], and let the maintainer deal with it. If you're sure
that what you're doing is correct, there is in general no reason to not do it.
In order to prevent problems, I suggest being extra cautious changing the
state of bugs if you're not completely sure how to undo any potential
mistake you might make.

In all cases, writing mail to [EMAIL PROTECTED] is always safe to do, and
there should always be some maintainer somewhere who will read the message can
can act on it appropriately.

Thank you for your contribution (bugreports are also contributions in a way)
to Debian!
--Jeroen

-- 
Jeroen van Wolffelaar
[EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl


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

Closing bugs as submitter?

[Jan C. Nordholz]

Dear list,

I'd like to ask you if it is desired (and possible at all)
that submitters close their own bugs if they have been fixed
without the package maintainer's noticing. The informational
pages on b.d.o don't state whether [EMAIL PROTECTED] is obeying
commands from everyone, and whether or not such behaviour
(meddling with bugs as non-maintainer) would be deemed
appropriate.

In my special case, the bug I've reported two weeks ago
has apparently been fixed upstream, and the latest upload
of the package to experimental has brought the fix into
the archive. Now I'd like to save the maintainer some work
and tag the bug fixed-in-experimental myself (together with
a short explanatory message to the bug log), but am unsure
whether I'm allowed to.


Regards,

Jan

-- 
Jan C. Nordholz



signature.asc
Description: Digital signature

udev and Logitech mouse applet

[Frank Hart]

I use the following udev rule to let the Logitech applet change the dpi 
from 400 to 800:

BUS="usb", SYSFS{idVendor}="046d", SYSFS{idProduct}="c025", 
PROGRAM="/usr/bin/lmctl -8 --sms"

This worked with udev 0.068. After I installed 0.070 I have to do a 
'udevstart' after booting and then the rule is applied. Has this 
something to do with hotplugs removal?

Frank

-- 
Woman on Street:Sir, you are drunk; very, very drunk.
Winston Churchill:  Madame, you are ugly; very, very ugly.
I shall be sober in the morning.


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

Re: time seen at top of /var/log/boot

[Jon Dowland]

On Wed, Sep 28, 2005 at 07:01:52AM +0800, Dan Jacobson wrote:
> No its not my BIOS time. It appears to be a timezone 4 timezones east
> of New Zealand, GMT+16, i.e., out of this world. How about on your
> machine?

I don't have a /var/log/boot, sorry. How do I get one?

-- 
Jon Dowland
http://jon.dowland.name/


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

Re: time seen at top of /var/log/boot

[Dan Jacobson]

I installed two Debian sids on separate machines. They work fine.
My only curiosity is what I see with grep Clock /var/log/boot.

> The final time is correct Taiwan time, but the initial time is an
> unworldly GMT+16.  My BIOS is set with my local Taiwan time.

< As Taiwan is GMT+8, it looks as if the initial time is your
< system time interpreted as GMT and corrected for Taiwan timezone.

Ah. Hmmm I bet Tokyo Debian users have GMT+18 then.

< Do you by any chance have UTC=yes in /etc/default/rcS?

UTC=no

I Wonder what other east of GMT, BIOS set to local time users see with
grep Clock /var/log/boot.


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

Re: what's up with the arm and m68k autobuilders

[Stephen R Marenka]

On Sat, Oct 15, 2005 at 05:35:03PM -0700, Thomas Bushnell BSG wrote:
> 
> The arm and m68k autobuilders are having real trouble keeping up; m68k
> has been well below 90% for weeks, and arm has been plummeting
> recently.
> 
> Whats up?

I think the biggest problem on m68k has been the numerous gcc-4.0 bugs
combined with all the transitions.

I've started a wiki page [0] to try to track our porting issues better.

[0] 

-- 
Stephen R. Marenka If life's not fun, you're not doing it right!
<[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Bug#334279: ITP: cando -- student competency tracker

[Brian Sutherland]

Package: wnpp
Severity: wishlist

* Package name: cando
  Version : 2005.2.2
  Upstream Authors: CanDo Developers <[EMAIL PROTECTED]>
* URL : http://www.schooltool.org/products/cando
* License : BSD
  Description : student competency tracker

CanDo is an SchoolTool product that allows teachers and administrators
to track student acquisition of competencies during a course. Using a
database of competencies which students are expected to acquire,
teachers can use CanDo to track and manage student progress in meeting
their competency goals.

Extra ITP information:
I am packaging this for unstable so that more people can use this,
but do not think it is ready for release until it is more closely
integrated with the SchoolTool packages. A serious bug will be filed to
keep cando out of testing until then.


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

Bug#334269: ITP: python-pullparser -- simple "pull API" for HTML parsing

[Brian Sutherland]

Package: wnpp
Severity: wishlist

* Package name: python-pullparser
  Version : 0.0.6
  Upstream Author : Jhon J. Lee <[EMAIL PROTECTED]>
* URL : http://wwwsearch.sourceforge.net/pullparser/
* License : BSD
  Description : simple "pull API" for HTML parsing

Many simple HTML parsing tasks are simpler this way than with the
HTMLParser module. pullparser.PullParser is a subclass of
HTMLParser.HTMLParser.

After Perl's HTML::TokeParser.

Additonal ITP info:
python-pullparser is an unpackaged dependency required for python-mechanize
(ITP: 334241).


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

subscribe

[Florian Schmidt]

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

Re: Finding out in postinst whether some other package is configured

[Frank Küster]

Josselin Mouette <[EMAIL PROTECTED]> wrote:

> Le vendredi 14 octobre 2005 à 22:23 -0400, Anthony DeRobertis a écrit :
>> Frank Küster wrote:
>> 
>> > In the particular case, the reason is something else: If the recommended
>> > package B (tetex-bin) is there, it makes sense to run one of its
>> > executables (mktexlsr, updmap) to register the files of package A (any TeX
>> > font package).  This is a time-consuming process.  However, if B is
>> > installed but unconfigured, we can save this time because when B is
>> > configured, it will run these executables, anyway, and doing this also
>> > will pick up package A's files.
>
> Isn't it possible to run a consistency check, to know whether it is
> necessary to re-run mktexlsr/updmap before actually running them?

Such a check wouldn't be faster than running the actual script...

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: Bug#334225: ITP: libmodelfile -- library to handle quake .md3 files

[Michael Koch]

On Sun, Oct 16, 2005 at 04:45:22PM +0200, Clément Stenac wrote:
> Hello,
> 
> > Description: library to handle quake .md3 files
> >  Full support for loading all quake .md3 models found in the field, many of
> >  which were not handled by tutorial code, or other loaders. Simple converter
> >  provided for stripping environment texture coords to make vertex data more
> >  compact and easy to use.
> >  .
> >  This package contains te runtime library.
> 
> Please make some complete sentences in the long description

I revised the package a bit:


Source: libmodelfile
Section: libs
Priority: optional
Maintainer: Michael Koch <[EMAIL PROTECTED]>
Build-Depends: cdbs, debhelper (>= 4.1.0)
Standards-Version: 3.6.2

Package: libmd3-1
Architecture: any
Section: libs
Depends: ${shlibs:Depends}
Description: library to handle Quake .md3 files - runtime library
 This library provides full support for loading all Quake .md3 models found
 in the field. Many of these were not handled by tutorial code, or other
 loaders. It contains a simple converter provided for stripping environment
 texture coords to make vertex data more compact and easy to use.
 .
 This package contains the runtime library.

Package: libmd3-dev
Architecture: any
Section: libdevel
Depends: libmd3-1 (= ${Source-Version})
Description: library to handle Quake .md3 files - development files
 This library provides full support for loading all Quake .md3 models found
 in the field. Many of these were not handled by tutorial code, or other
 loaders. It contains a simple converter provided for stripping environment
 texture coords to make vertex data more compact and easy to use.
 .
 This package contains the development files needed to compile and link against
 this library.


> Clément

You shoud CC such mails to the people reporting the ITP as reading
debian-devel is not mandatory.


Cheers,
Michael
-- 
Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html

Join the community at http://planet.classpath.org/


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

Bug#334246: RFA: xpenguins -- little penguins walk on your windows

[Bas Zoetekouw]

Package: wnpp
Severity: normal

I request an adopter for the xpenguins package.

The package description is:
 Ever wanted cute little penguins walking along the tops of your
 windows? Ever wanted to send an army of cute little penguins to invade
 the screen of someone else on your network? Probably not, but why not
 try this program out anyway, it's cool!

The program is kind of cool, so I'll keep it if no one else want to
take it.  Upstream is dormant, but reachable.  The main bug in the
package is that it can't handle desktop-environments very well:  the
penguins destroy icons on the desktop.  This could probably be fixed
by someone who knows about gnome/kde stuff.  Furthermore, there are
some smaller bugs that are easily fixed.

This is a nice package for a prospective maintainer to take.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.13-rc6
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)


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

Bug#334241: ITP: python-mechanize -- stateful programmatic web browsing

[Brian Sutherland]

Package: wnpp
Severity: wishlist

* Package name: python-mechanize
  Version : 0.0.9a
  Upstream Author : Jhon J. Lee <[EMAIL PROTECTED]>
* URL : http://wwwsearch.sourceforge.net/mechanize/
* License : BSD
  Description : stateful programmatic web browsing

A library for browsing the web in python. Mechanize acts like a browser
allowing you to do web scraping, functional testing of web sites and
things no one has thought of yet.

Among other things, mechanize:
* Follows links
* Fills in HTML forms
* Automatically observes robots.txt
* Has a browser history

It was modelled after the Perl module WWW::Mechanize.


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

Re: Managing SSL certificates

[Wouter Verhelst]

On Sun, Oct 16, 2005 at 11:00:53AM -0400, sean finney wrote:
> On Sun, Oct 16, 2005 at 03:59:17PM +0200, Wouter Verhelst wrote:
> > Such a tool would be very nice, and not just because of the cruft they
> > leave behind -- many packages currently support SSL connections; some
> > automatically generate a self-signed certificate upon installation,
> > others leave that to the admin. Some use debconf to ask information for
> > the certificate (or to warn that a certificate has to be generated
> > before SSL will be enabled), some don't.
> > 
> > A unified API to clean up this mess would be very interesting.
> 
> i would suggest that in addition to supplying an api, it would be
> very helpful to provide all the debconf templates and maintainer
> script logic as well.

I see that as part of the API, but you're of course right :-)

-- 
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond


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

Re: Managing SSL certificates

[sean finney]

On Sun, Oct 16, 2005 at 03:59:17PM +0200, Wouter Verhelst wrote:
> Such a tool would be very nice, and not just because of the cruft they
> leave behind -- many packages currently support SSL connections; some
> automatically generate a self-signed certificate upon installation,
> others leave that to the admin. Some use debconf to ask information for
> the certificate (or to warn that a certificate has to be generated
> before SSL will be enabled), some don't.
> 
> A unified API to clean up this mess would be very interesting.

i would suggest that in addition to supplying an api, it would be
very helpful to provide all the debconf templates and maintainer
script logic as well.  i do such an approach in dbconfig-common
and it works quite well, such that the only thing maintainers
of other packages who want to use my features need to do is
add two lines to their maintainer scripts and update their dependencies.
this reduces duplicate code, keeps implementation bugs very well confined,
provides a common feel across different packages.  it also makes
translators' lives a lot easier.

also, i think extreme care should be take wrt these ssl certificates.
i don't think they should be blindly purged at package removal (or
probably even package purge) time, without getting permission from
the local admin.


sean

-- 


signature.asc
Description: Digital signature

Re: Bug#334225: ITP: libmodelfile -- library to handle quake .md3 files

[Clément Stenac]

Hello,

> Description: library to handle quake .md3 files
>  Full support for loading all quake .md3 models found in the field, many of
>  which were not handled by tutorial code, or other loaders. Simple converter
>  provided for stripping environment texture coords to make vertex data more
>  compact and easy to use.
>  .
>  This package contains te runtime library.

Please make some complete sentences in the long description

-- 
Clément


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

Re: Managing SSL certificates

[Wouter Verhelst]

On Sat, Oct 15, 2005 at 03:10:50PM +0300, Lars Wirzenius wrote:
> With my testing of packages in etch with piuparts[1], I occasionally run
> into a problem that occurs in many packages in the same way. One such
> problem is the creation and deletion of SSL certificates for various
> services (imaps, https, etc). At the moment, the packages tend to create
> the certificate automatically on installation, if it isn't there
> already, and not remove it when the package is purged. This leaves cruft
> on the filesystem.
> 
> A couple of problematic scenarios that have been brought up:
> 
> * What if the sysadmin modifies the certificate? For example,
> they might add a signature from a CA, or replace it with a
> completely new one.
> 
> * What if the certificate is shared by several packages?
> 
> There are probably others.
> 
> In my opinion, it would be nice to be clean about these certificates so
> that if I install a package and then purge it, without touching the
> certificate in any way, it is removed with the package. While the amount
> of cruft left behind by these files is pretty small, it's still cruft.
> 
> My suggestion would be to create a tool to manage installation and
> removal of certificates. Something like this:
> 
> update-ssl-certificate --create package servicename
> update-ssl-certificate --remove package servicename

Such a tool would be very nice, and not just because of the cruft they
leave behind -- many packages currently support SSL connections; some
automatically generate a self-signed certificate upon installation,
others leave that to the admin. Some use debconf to ask information for
the certificate (or to warn that a certificate has to be generated
before SSL will be enabled), some don't.

A unified API to clean up this mess would be very interesting.

-- 
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond


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

Bug#334225: ITP: libmodelfile -- library to handle quake .md3 files

[Michael Koch]

Package: wnpp
Severity: wishlist
Owner: Michael Koch <[EMAIL PROTECTED]>


* Package name: libmodelfile
  Version : 0.1.92
  Upstream Author : Al Riddoch <[EMAIL PROTECTED]>
* URL : http://www.worldforge.org/
* License : GPL
  Description : library to handle quake .md3 files


Source: libmodelfile
Section: libs
Priority: optional
Maintainer: Michael Koch <[EMAIL PROTECTED]>
Build-Depends: cdbs, debhelper (>= 4.1.0)
Standards-Version: 3.6.2

Package: libmd3-0.2-1
Architecture: any
Section: libs
Depends: ${shlibs:Depends}
Description: library to handle quake .md3 files
 Full support for loading all quake .md3 models found in the field, many of
 which were not handled by tutorial code, or other loaders. Simple converter
 provided for stripping environment texture coords to make vertex data more
 compact and easy to use.
 .
 This package contains te runtime library.

Package: libmd3-0.2-dev
Architecture: any
Section: libdevel
Depends: libmd3-0.2-1 (= ${Source-Version})
Description: library to handle quake .md3 files - development files
 Full support for loading all quake .md3 models found in the field, many of
 which were not handled by tutorial code, or other loaders. Simple converter
 provided for stripping environment texture coords to make vertex data more
 compact and easy to use.
 .
 This package contains the development files needed to compile and link against
 this library.
-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.4.27-2-k7
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: Effort to change IETF's copying conditions for RFCs

[Florian Weimer]

* Peter Samuelson:

>> * Simon Josefsson:
>> > The Contributor grants third parties the right to
>> >copy and distribute the Contribution, with or without
>> >modification, in any medium, without royalty.  If the
>> >Contribution is modified, any claims of endorsement or
>> >official status by the IETF or ISOC must be removed.
>
> [Florian Weimer]
>> Sure, but this might not be acceptable to ISOC, which might want to
>> see a "Portions Copyright (C) 200x The Internet Society" in derived
>> works.
>
> I don't see a conflict there.  A copyright notice is not a claim of
> endorsement or official status - it's particularly clear that this is
> not the case if only "portions" are copyrighted by some standards body.

I didn't mean that, sorry.

The potential problem I see is that Simon's new permission does not
require attribution at all, not even the plain copyright statement.


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

Re: removal of support for /etc/hotplug/usb/

[Jean-Luc Coulon (f5ibh)]

Le 12.10.2005 21:52:54, Jean-Luc Coulon (f5ibh) a écrit :

Le 12.10.2005 21:30:06, Jean-Luc Coulon (f5ibh) a écrit :

Le 12.10.2005 20:08:44, Marco d'Itri a écrit :

On Oct 12, "Jean-Luc Coulon (f5ibh)" <[EMAIL PROTECTED]>
wrote:

> if [ "$ACTION" = "add" -a "$TYPE" = "usb" ]; then
Remove -a "$TYPE" = "usb", it is wrong and I do not understand how  
it

can work with hotplug or real hotplug events.


The rule was applied (permission changed to root:nut) with the  
previous version.

I've dropped the $TYPE and got the same result: nothing.
I've use the same "run level" (025_libhidups.rules) int  
/etc/udev/rules.d, is it correct?



BTW, I've jsut tried the scanner (Epson 1640) managed by  
libusb/libsane. I've exactly the same problem, the permissions arent  
changed. So it is not useable with a normal user.


At least for sane, it works with 070-5


Jean-Luc


pgpQFHbs6p2wv.pgp
Description: PGP signature