Re: Improper NMU (Re: NMU for libquota-perl)

[Elie Rosenblum]

On Mon, Sep 02, 2002 at 02:25:30AM +0100, Colin Watson wrote:
> On Sun, Sep 01, 2002 at 09:19:17PM -0400, Elie Rosenblum wrote:
> > On Mon, Sep 02, 2002 at 02:16:11AM +0100, Colin Watson wrote:
> > > Technically it wasn't. The upload is still in the DELAYED queue, which
> > > is really just a convenient automated way of saying "I'll NMU this
> > > package in  days if I don't hear anything", with the added bonus of
> > > allowing the maintainer to poke at it and see exactly what would go in
> > > in the absence of a maintainer upload. I usually explain this when using
> > > the delayed queue.
> > 
> > I assume you also submit a bug.
> 
> Quite.

Would you agree that performing an NMU without a BTS entry is wrong?

> > Do you generally do this without leaving a bug for a few days first?
> 
> In the case of the perl transition I've been given to understand by the
> actions of other developers that the -devel-announce post on 31st July
> was enough. Otherwise no.

I see.

Well, I disagree with this (as do I believe some others), but only
in that no NMU should be done until the bug has existed for a few
days (if nothing else, this addresses the distinct possibility of
NMUs actually breaking stuff, which has already been brought up in
this thread). I'm probably not going to convince you of this, any
more than you will convince me that I'm wrong here. I have not,
however, been hit with this general case...I've been hit with an
irresponsible maintainer performing an NMU without submitting a
bug at all, even if it was 5 minutes before he uploaded. This is
just plain wrong, and something that can cause us really serious
problems if people start to imagine that it's acceptable - 
especially since we have little control over which keys can
successfully upload any given package.

-- 
Elie Rosenblum That is not dead which can eternal lie,
http://www.cosanostra.net   And with strange aeons even death may die.
Admin / Mercenary / System Programmer - _The Necronomicon_

Packages affected by removal of free mp3 players

[Joe Drew]

If the worst does happen, and we need to remove all mp3 players from
Debian, many packages will be affected. Most of these are because of
their dependency on libsmpeg, which is the SDL MPEG audio and video
decoder. Others depend on other MP3-playing libraries, such as libmad,
mpeglib (which is named oddly), etc. (Please let me know if I've
forgotten some.) A few packages depend on mpg321 as well - mostly
front-ends.

Some notable packages affected are pygame (affects pyddr, for those
unfortunate few who cannot attend the 12-step meetings), alsaplayer,
GAnSO, ogle, and many others.

One of the main culprits is libsdl-mixer1.2, I think: this causes many
(most?) SDL games, including frozen-bubble, to be affected by the
removal of libsmpeg0. I don't know if libsdl-mixer can be compiled
without smpeg support, though, or what this would mean for users of
libsdl-mixer1.2. In the very worst case, we may be able to get a new
upstream version of libsdl-mixer released which supports only Vorbis.

For those which depend on pure mp3 playing libraries such as libmad, we
may be SOL - especially in the case of programs which require the
ability to decode MPEG 1 layer 3, like ogle. Suggestions are welcome.

Attached are the lists of reverse dependencies for the packages I could
think of.

-- 
Joe Drew <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

"This particular group of cats is mostly self-herding." -- Bdale Garbee
alsaplayer
alsaplayer-alsa
alsaplayer-common
alsaplayer-esd
alsaplayer-gtk
alsaplayer-jack
alsaplayer-nas
alsaplayer-oss
alsaplayer-text
audacity
avifile-mad-plugin
dvb-zapping
gqmpeg
gstreamer-mad
gstreamer-plugins
irmp3
kreatecd
libmad0
libmad0-dev
madplay
mp3burn
mpg123-el
mpg321
mq3
mserv
nautilus1.1-suggested
ogle
ogle-gui
ogle-mmx
playmp3list
simplecdrx
vlc-mad
artsbuilder
brahms
kdemultimedia-dev
libarts-mpeglib
mpeglib
noatun
noatun-plugins
rosegarden4
black-box
bugsquish
bumprace
castle-combat
chromium
circuslinux
crimson
criticalmass
csmash
csmash-demosong
defendguin
enigma
frozen-bubble
ganso
gemdropx
gl-117
gltron
gnome-office
heroes-common
heroes-ggi
heroes-sdl
icebreaker
jumpnbump
jumpnbump-levels
junior-arcade
junior-art
junior-games-gl
junior-puzzle
junior-typing
ksmp3play
lbreakout2
lgeneral
libopenal0
libopenal-dev
libsdl-mixer1.2
libsdl-mixer1.2-dev
libsdl-ocaml
libsdl-ocaml-dev
libsdl-perl
libsdl-ruby
libsmpeg0
libsmpeg-dev
ltris
madbomber
mangoquest
mirrormagic
moon-lander
penguin-command
prboom
pygame
pysol-sound-server
python2.1-pygame
python2.2-pygame
python-pygame
rockdodger
rocks-n-diamonds
smpeg-gtv
smpeg-plaympeg
smpeg-xmms
solarwolf
toppler
tuxpaint
tuxracer
tuxtype
vectoroids
vegastrike

Re: The harden-*flaws packages.

[Daniel Martin]

Martin Schulze <[EMAIL PROTECTED]> writes:

> Please see the thread summarized in 
> :
> 
> Policy for Woody Point-Releases. [4]Several [5]developers [6]would
> [7]like to add new packages and updates to their packages to the
> recently released stable distribution of Debian. Adding new packages
> and random updates to the stable distribution, however, would nullify
> the entire idea of having a stable release, Joey [8]explained. Hence,
> the same policy as before will be used for point-releases of woody.

Yes, but how does this apply to a package that does nothing but
conflict with existing packages?  (As is the case with most of the
harden-* packages)

Agreed, _random_ updates would be a bad thing.  However, what the
maintainer is proposing here is updates that are driven by DSAs.
Although I find it a slight stretch, one could easily argue that the
updates to the harden-*flaws packages are security updates.

These updates share another feature with security updates.  Imagine
the package netostrich, which helps you bury your head in the sand
remotely.  Now, suppose the upstream authors discover a flaw in the
2.0 series of netostrich prior to version 2.33 which allows random
network users to bury other people's heads in the sand.  Sarge soon
contains 2.34 with the security fix, yet woody contains 2.29.1 with a
backported fix.  Then there would similarly need to be two
harden-remoteflaws; one for woody, which conflicts with netostrich
prior to 2.29.1, and one for sarge, which conflicts with netostrich
prior to 2.34.  The harden-*flaws update has to be backported along
with the backported fix to netostrich.

Now, if we want the harden-remoteflaws package to be at all useful, it
needs to be updated along with DSAs...

Hrm.  The more I think about this the more I wonder if maybe the
harden-*flaws packages make much sense in stable at all.  If someone
is apt-get'ing from security.debian.org, they're already replacing
vulnerable versions with fixed ones.  If someone is updating from a
point release CD, the same thing applies.  The only case where I can
see it making sense is with someone following testing with most of
their packages on hold (they really want a stable system, and only
upgrade a package when they need to).  Am I missing a scenario?

Re: Improper NMU (Re: NMU for libquota-perl)

[Colin Watson]

On Sun, Sep 01, 2002 at 09:19:17PM -0400, Elie Rosenblum wrote:
> On Mon, Sep 02, 2002 at 02:16:11AM +0100, Colin Watson wrote:
> > Technically it wasn't. The upload is still in the DELAYED queue, which
> > is really just a convenient automated way of saying "I'll NMU this
> > package in  days if I don't hear anything", with the added bonus of
> > allowing the maintainer to poke at it and see exactly what would go in
> > in the absence of a maintainer upload. I usually explain this when using
> > the delayed queue.
> 
> I assume you also submit a bug.

Quite.

> Do you generally do this without leaving a bug for a few days first?

In the case of the perl transition I've been given to understand by the
actions of other developers that the -devel-announce post on 31st July
was enough. Otherwise no.

-- 
Colin Watson  [EMAIL PROTECTED]

Re: Improper NMU (Re: NMU for libquota-perl)

[Elie Rosenblum]

On Mon, Sep 02, 2002 at 02:16:11AM +0100, Colin Watson wrote:
> On Sun, Sep 01, 2002 at 09:06:20PM -0400, Elie Rosenblum wrote:
> > The NMU was made before I was in any way contacted.
> 
> Technically it wasn't. The upload is still in the DELAYED queue, which
> is really just a convenient automated way of saying "I'll NMU this
> package in  days if I don't hear anything", with the added bonus of
> allowing the maintainer to poke at it and see exactly what would go in
> in the absence of a maintainer upload. I usually explain this when using
> the delayed queue.

I assume you also submit a bug.

Do you generally do this without leaving a bug for a few days first?

-- 
Elie Rosenblum That is not dead which can eternal lie,
http://www.cosanostra.net   And with strange aeons even death may die.
Admin / Mercenary / System Programmer - _The Necronomicon_

Re: Improper NMU (Re: NMU for libquota-perl)

[Colin Watson]

On Sun, Sep 01, 2002 at 09:06:20PM -0400, Elie Rosenblum wrote:
> The NMU was made before I was in any way contacted.

Technically it wasn't. The upload is still in the DELAYED queue, which
is really just a convenient automated way of saying "I'll NMU this
package in  days if I don't hear anything", with the added bonus of
allowing the maintainer to poke at it and see exactly what would go in
in the absence of a maintainer upload. I usually explain this when using
the delayed queue.

-- 
Colin Watson  [EMAIL PROTECTED]

Re: Improper NMU (Re: NMU for libquota-perl)

[Elie Rosenblum]

On Mon, Sep 02, 2002 at 01:28:42AM +0100, Colin Watson wrote:
> Yeah. I did several perl 5.8 NMUs this weekend (all to the delayed
> queue), but all of them are filed in the BTS. I don't think aj intended
> that routine procedure to be changed.
> 
> > I'm concerned that a single person has the power to dictate such dramatic
> > changes in our procedures.
> 
> There was quite a bit of discussion about it, mostly centred around the
> fact that there are a quite unreasonable number of bugs mired with
> inactive maintainers. The DELAYED queue is a fantastic tool to encourage
> people to fix bugs while still giving maintainers warning of the
> proposed changes well before they're actually made.

In this case, no bug was ever submitted. I am also not an inactive
maintainer; I deal with bugs in my packages in an expedient manner,
when they are submitted properly.

The NMU was made before I was in any way contacted.

Had bugs been submitted, I would not have even uploaded the package
that ended up being NMU'd; there's a new version of the library out
as of a couple of weeks ago, and I would have knocked out both at
the same time (as I am doing shortly, after this apt-get finishes).

There are a number of maintainers who seem to have agreed that the
way this NMU was done is incorrect.

I don't think anyone is arguing that the fix isn't needed; I don't,
however, appreciate being treated like an MIA maintainer and having
my responsibilities coopted. There is no urgency that requires an
NMU if it's not important enough to file a bug.

-- 
Elie Rosenblum That is not dead which can eternal lie,
http://www.cosanostra.net   And with strange aeons even death may die.
Admin / Mercenary / System Programmer - _The Necronomicon_

unsubscribe

[rweir]

unsubscribe

Pending removal of konverse/kdestudio

[Ben Burton]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Hi all.  At some near point in the future I'm going to ask for the removal of 
konverse and kdestudio from sid/sarge.

Konverse doesn't work so well and by all appearances seems dead upstream.  
Upstream assures us they're in the middle of a complete rewrite but this has 
been the case for some time now and it's not clear how long it will take.  
Once this rewrite appears I'm perfectly happy to have it back, but until then 
it seems better IMHO to remove it completely.

KDEStudio on the other hand *is* dead upstream; upstream has a notice to this 
effect on their website.  I plan to keep it around as long as KDE2 is in sid, 
but once sid moves to KDE3 I'm again going to request its removal rather than 
do the port.

So if anyone wants to rescue these packages from their imminent fate, please 
mail me; otherwise I'll keep maintaining them until the KDE3 transition and 
then file bugs on ftp.d.o for their removal.

Ben.

- -- 

Ben Burton
[EMAIL PROTECTED]  |  [EMAIL PROTECTED]
http://baasil.humbug.org.au/bab/
Public Key: finger [EMAIL PROTECTED]

If this is the way Queen Victoria treats her prisoners, she doesn't
deserve to have any. (Complaining at having to wait in the rain for
transport to take him to prison)
- Oscar Wilde

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

iD8DBQE9crCyMQNuxza4YcERAigyAJ4lFPkwTL3vHYnFlCVgWcLelC+pIQCfRDN0
o6/aPNZOICQ2zkmpVwgyAbo=
=deL7
-END PGP SIGNATURE-

Re: Improper NMU (Re: NMU for libquota-perl)

[Colin Watson]

On Sun, Sep 01, 2002 at 07:13:33PM -0500, John Goerzen wrote:
> On Sun, Sep 01, 2002 at 07:35:25PM -0400, Joey Hess wrote:
> > Standard procedure for NMU's was considerably relaxed (or rather,
> > clarified) this winter by the release manager. The developers reference
> > is just that: a reference of typical best practice. Sometimes it's
> > expedient to not follow its every letter, and that's ok.
> 
> I think that doing things for "expediency" can come back to haunt us.  If
> NMUs are not properly logged in the BTS, maintainers can miss them and end
> up uploading newer versions later that lack the NMU code.

Yeah. I did several perl 5.8 NMUs this weekend (all to the delayed
queue), but all of them are filed in the BTS. I don't think aj intended
that routine procedure to be changed.

> I'm concerned that a single person has the power to dictate such dramatic
> changes in our procedures.

There was quite a bit of discussion about it, mostly centred around the
fact that there are a quite unreasonable number of bugs mired with
inactive maintainers. The DELAYED queue is a fantastic tool to encourage
people to fix bugs while still giving maintainers warning of the
proposed changes well before they're actually made.

-- 
Colin Watson  [EMAIL PROTECTED]

Re: Improper NMU (Re: NMU for libquota-perl)

[John Goerzen]

On Sun, Sep 01, 2002 at 07:35:25PM -0400, Joey Hess wrote:

> Standard procedure for NMU's was considerably relaxed (or rather,
> clarified) this winter by the release manager. The developers reference
> is just that: a reference of typical best practice. Sometimes it's
> expedient to not follow its every letter, and that's ok.

I think that doing things for "expediency" can come back to haunt us.  If
NMUs are not properly logged in the BTS, maintainers can miss them and end
up uploading newer versions later that lack the NMU code.  Furthermore, I
have seen plenty of cases where NMUs break the package more than they fix
it.  There is reason for the procedures we have.

I'm concerned that a single person has the power to dictate such dramatic
changes in our procedures.  Why is the NMU procedure not codified in Debian
Policy?  There, at least, we have a better mechanism of updating it.

In any case, the reference does little good if it does not reflect the
current state of things.  

-- John

Fwd: Love it when a good plan works out!

[Sean 'Shaleh' Perry]

Great warm and fuzzy mail with an interesting P.S.

--  Forwarded Message  --

Subject: Love it when a good plan works out!
Date: Sun, 1 Sep 2002 16:03:14 -0700
From: Johnny Quazar <[EMAIL PROTECTED]>
To: debian-user@lists.debian.org

Just completed my first crack at the new Woody 3.0r0 release, and
wanted to write and kudos to the team!

Wow, smooth as silk, the >only< glitch I experienced was an
overloaded security.debian.org server -- and you guys even
anticipated that event! I used retry a couple times and blamo --
pain-free Linux install!

I've got a few of these under my belt and have never seen it go
smoother -- GOOD JOB PEOPLE! Huge Warm Fuzzies!!

Thanks again,

Rob Leachman
[EMAIL PROTECTED]


PS: Well I wanted to write one of those really rare messages but
cannot click send without finding something to suggest... nowhere in
the (i386) install manual does it clearly state:

1. Download compact-rescue and compact-root
2. Make floppies
3. Boot the rescue disk
4. Do the most obvious thing
5. Bask in the glow

I had to "go for it" with less certainty than would have been
provided with at least step 1 explicitly stated (under the
"installing over network" section?). Shrug, whatever.

Substitute this suggestion with "how the heck did I get nethack, in a
minimal install" if the above doesn't seem important, ha ha.


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

---

Bug#159232: ITP: bluez-pan -- BlueZ Bluetooth PAN utilities

[Edd Dumbill]

Package: wnpp
Severity: wishlist

* Package name: bluez-pan
  Version : 1.0
  Upstream Author : Johannes Loebbert <[EMAIL PROTECTED]>
* URL : http://bluez.sf.net/
* License : GPL
  Description : BlueZ Bluetooth PAN utilities

Daemon and tool for controlling Bluetooth PAN connections using the
BlueZ Linux Bluetooth stack.  PAN enabless Bluetooth devices to
function as Linux network devices.

Re: Improper NMU (Re: NMU for libquota-perl)

[Joey Hess]

John Goerzen wrote:
> > Why are you upset about it? Was the quality of the NMU bad? One of the
> > main points of a BSP is afaik that you can make NMUs to delayed
> > _without_ previous notice to the maintainer.
> 
> I see no reason that a BSP should be a "sanctioned but undocumented
> exception to procedure".  Why not follow standard procedures?

Standard procedure for NMU's was considerably relaxed (or rather,
clarified) this winter by the release manager. The developers reference
is just that: a reference of typical best practice. Sometimes it's
expedient to not follow its every letter, and that's ok.

-- 
see shy jo


pgpvqGeIZQciC.pgp
Description: PGP signature

Re: Improper NMU (Re: NMU for libquota-perl)

[Elie Rosenblum]

On Sun, Sep 01, 2002 at 10:42:44PM +0100, Colin Watson wrote:
> On Sun, Sep 01, 2002 at 05:26:28PM -0400, [EMAIL PROTECTED] wrote:
> > If a bug even existed for this already, it would certainly not be
> > release critical.
> 
> Sure it would. libquota-perl is currently uninstallable.

Mmm. Yes, I see this, now that I'm updating my build machine so I
can rebuild all my perl packages.

Well, in any case, the rest of my argument stands without this.

-- 
Elie Rosenblum That is not dead which can eternal lie,
http://www.cosanostra.net   And with strange aeons even death may die.
Admin / Mercenary / System Programmer - _The Necronomicon_

Re: Non-Intel package uploads by maintainer

[Goswin Brederlow]

John Goerzen <[EMAIL PROTECTED]> writes:

> On Sun, Sep 01, 2002 at 09:51:32PM +0200, Goswin Brederlow wrote:
> 
> > Imagine for eample the case where the sources are missing files, as
> > happens too often. Then the binary is in violation of the GPL.
> > 
> > Not good. So why not let the autobuilder do their job for all archs.
> 
> Because then there's no opportunity to test what was built prior to
> uploading it to the archive.  If you do a standard upload, you'll at least
> have the opportunity to test the actual .debs produced on one architecture.
> 
> -- John

You should do that anyway. Testing and uploading should be seperate
steps.

MfG
Goswin

PS: you should also test the result of the autobuilder.

Re: More manpower to our core teams

[Josip Rodin]

On Sun, Sep 01, 2002 at 11:45:56PM +0200, Martin Schulze wrote:
> > > System Administration:Ryan Murray <[EMAIL PROTECTED]>
> > >   Philip Hands <[EMAIL PROTECTED]>
> > 
> > Er, Phil has been one of the four admins almost everywhere, before Ryan
> > joined. Arguably he isn't involved as much, but still...
> 
> He was added lately, before that he was only admin of open, irrc.

I'm sure I saw Phil do admin stuff on machines before Ryan. There was always
the problem of him not being in the sudoers file on new machines, but that
would always get fixed.

> > Anyway, I don't see the point of posting their email addresses.
> 
> They're more or less public anyway, so that don't hurt.

I for one wouldn't have liked if someone sent my @d.o address to -d-a,
because I don't use it for that stuff in order to have less spam on it.
IWJ seems to do the same for his @d.o address, and I believe several others.

-- 
 2. That which causes joy or happiness.

Re: More manpower to our core teams

[Martin Schulze]

Josip Rodin wrote:
> On Sat, Aug 31, 2002 at 01:44:18PM +0200, Torsten Landschoff wrote:
> > So here is the list of the new nominations:
> > 
> > FTP Archive Maintenance:Ryan Murray <[EMAIL PROTECTED]>
> 
> You forgot Randall Donald there.

That's my fault, since he's too invisible for me to recognize him.

> > System Administration:  Ryan Murray <[EMAIL PROTECTED]>
> > Philip Hands <[EMAIL PROTECTED]>
> 
> Er, Phil has been one of the four admins almost everywhere, before Ryan
> joined. Arguably he isn't involved as much, but still...

He was added lately, before that he was only admin of open, irrc.

Btw. there's also Mako Hill, the delegate for handling hardware donations.

> Anyway, I don't see the point of posting their email addresses.

They're more or less public anyway, so that don't hurt.

Regards,

Joey

-- 
Linux - the choice of a GNU generation.

Please always Cc to me when replying to me on the lists.

Re: Improper NMU (Re: NMU for libquota-perl)

[Colin Watson]

On Sun, Sep 01, 2002 at 05:26:28PM -0400, [EMAIL PROTECTED] wrote:
> If a bug even existed for this already, it would certainly not be
> release critical.

Sure it would. libquota-perl is currently uninstallable.

-- 
Colin Watson  [EMAIL PROTECTED]

Re: Improper NMU (Re: NMU for libquota-perl)

[fnord]

On Sun, Sep 01, 2002 at 10:53:47PM +0200, Bas Zoetekouw wrote:
> Hi John!
> 
> You wrote:
> 
> > > So please ... don't complain about NMUers when they are only trying ot
> > > help you !
> > 
> > There's a difference between NMUs done right and NMUs done wrong.  The
> > latter may not be a help at all, whatever the intent may be.
> 
> So far, I've heard no objections to the _content_ of the NMU, only to
> the procedure.

The procedure is all that there _is_ to this NMU. I am assuming you did
nothing other than compile against the new perl.

Don't mess with other maintainers packages if you're not willing to do
it the right way.

I reiterate my request that you delete your NMU from the incoming queue
if you have not done so already. If nothing else, I have seen no
evidence that you have regression tested this code at all under the new
version of perl.

Do not NMU packages without following the established guidelines. The
world will _not_ end if you follow the damn guidelines - and they are
there for a reason.

Your BS about "it's the intent of a bug squashing party to _decrease_
the number of RC bugs" is completely irrelevent. There was no open bug
on this, so you're not decreasing bugs. This is a case where you should
be opening a bug. There is nothing _wrong_ with opening bugs - why do
you think we _have_ a BTS? If a bug even existed for this already, it
would certainly not be release critical.

-- 
Elie Rosenblum That is not dead which can eternal lie,
http://www.cosanostra.net   And with strange aeons even death may die.
Admin / Mercenary / System Programmer - _The Necronomicon_


pgpZBkJcrAH0C.pgp
Description: PGP signature

Re: The harden-*flaws packages.

[Martin Schulze]

Please see the thread summarized in 
:

Policy for Woody Point-Releases. [4]Several [5]developers [6]would
[7]like to add new packages and updates to their packages to the
recently released stable distribution of Debian. Adding new packages
and random updates to the stable distribution, however, would nullify
the entire idea of having a stable release, Joey [8]explained. Hence,
the same policy as before will be used for point-releases of woody.

 4. http://lists.debian.org/debian-devel-0207/msg01411.html
 5. http://lists.debian.org/debian-devel-0207/msg01416.html
 6. http://lists.debian.org/debian-devel-0207/msg01614.html
 7. http://lists.debian.org/debian-devel-0207/msg01483.html
 8. http://lists.debian.org/debian-devel-0207/msg01641.html

Regards,

Joey

-- 
Linux - the choice of a GNU generation.

Re: Improper NMU (Re: NMU for libquota-perl)

[Bas Zoetekouw]

Hi John!

You wrote:

> > So please ... don't complain about NMUers when they are only trying ot
> > help you !
> 
> There's a difference between NMUs done right and NMUs done wrong.  The
> latter may not be a help at all, whatever the intent may be.

So far, I've heard no objections to the _content_ of the NMU, only to
the procedure.

-- 
Kind regards,
+---+
| Bas Zoetekouw  | Si l'on sait exactement ce   |
|| que l'on va faire, a quoi|
| [EMAIL PROTECTED] | bon le faire?|
| [EMAIL PROTECTED] |   Pablo Picasso  |
+---+ 

Re: Improper NMU (Re: NMU for libquota-perl)

[John Goerzen]

On Sun, Sep 01, 2002 at 07:24:46PM +0200, Andreas Metzler wrote:

> You did get some mail notice (including the changelog of the NMU)
> before the package was/is going to be installed, didn't you?

Our reference states that this should occur via the BTS.  There is good
reason for that -- in particular, it allows the maintainer to track the
progress of their packages in a single location.  It also allows OTHER
developers to figure out what the status it.

http://www.debian.org/doc/developers-reference/ch-pkgs.en.html#s-nmu

> Why are you upset about it? Was the quality of the NMU bad? One of the
> main points of a BSP is afaik that you can make NMUs to delayed
> _without_ previous notice to the maintainer.

I see no reason that a BSP should be a "sanctioned but undocumented
exception to procedure".  Why not follow standard procedures?

Re: Improper NMU (Re: NMU for libquota-perl)

[John Goerzen]

On Sun, Sep 01, 2002 at 07:14:37PM +0200, Raphael Hertzog wrote:

> Policy doesn't rule the NMUs. There's no rule for NMUs, just
> guidelines ... and the guideline during a BSP are "NMU without prior
> notification but upload to DELAYED in order to leave some time to the
> maintainer if he's not happy with the NMU".

http://www.debian.org/doc/developers-reference/ch-pkgs.en.html#s-nmu

There's no indication that there are special rules for the BSP. 
Furthermore, I find it silly that our standard procedures should be ignored
for the BSP.  If our standard procedures are inadequate, let's fix them, not
use some undocumented hard-to-track exception for the BSP.

> So please ... don't complain about NMUers when they are only trying ot
> help you !

There's a difference between NMUs done right and NMUs done wrong.  The
latter may not be a help at all, whatever the intent may be.

Re: Non-Intel package uploads by maintainer

[John Goerzen]

On Sun, Sep 01, 2002 at 09:51:32PM +0200, Goswin Brederlow wrote:

> Imagine for eample the case where the sources are missing files, as
> happens too often. Then the binary is in violation of the GPL.
> 
> Not good. So why not let the autobuilder do their job for all archs.

Because then there's no opportunity to test what was built prior to
uploading it to the archive.  If you do a standard upload, you'll at least
have the opportunity to test the actual .debs produced on one architecture.

-- John

Re: Non-Intel package uploads by maintainer

[Josip Rodin]

On Sun, Sep 01, 2002 at 09:51:32PM +0200, Goswin Brederlow wrote:
> > > > > The autobuilder will check the build-process of your package. It will
> > > > > build in a clean chroot with proper build-depends. With proper
> > > > > versions of all tools.
> > > > > 
> > > > > If you upload binaries you get the usual bugs of missing
> > > > > build-depends, wrong versions of tools or libraries and so on. Just
> > > > > because you had them installed.
> > > > 
> > > > In his case, most of these will be noticed by the remaining nine 
> > > > buildds,
> > > > anyway. 
> > > 
> > > But the uploaded binaries will still be in the archive with broken
> > > sources.
> > 
> > Er, so? He'll still get RC bugs filed, and will have to upload another
> > revision, which would be fixed.
> 
> Imagine for eample the case where the sources are missing files, as
> happens too often. Then the binary is in violation of the GPL.
> 
> Not good. So why not let the autobuilder do their job for all archs.

Fifteen minutes after the upload, the first buildds will get to it, and
hours later, the first buildd maintainers will get to it, and the violation
could be fixed shortly after.

Encourage source-only uploads has a worse downside, because not having at
least one binary uploaded takes away the slim hope we now have, that the
maintainer has actually tested the binary and saw that it works.

Accidental temporary license violation, or an accidental temporary major
breakage for users -- I'd choose the former.

-- 
 2. That which causes joy or happiness.

Re: Non-Intel package uploads by maintainer

[Goswin Brederlow]

Josip Rodin <[EMAIL PROTECTED]> writes:

> On Sun, Sep 01, 2002 at 06:44:24AM +0200, Goswin Brederlow wrote:
> > > > Don't upload binaries at all.
> > > > 
> > > > The autobuilder will check the build-process of your package. It will
> > > > build in a clean chroot with proper build-depends. With proper
> > > > versions of all tools.
> > > > 
> > > > If you upload binaries you get the usual bugs of missing
> > > > build-depends, wrong versions of tools or libraries and so on. Just
> > > > because you had them installed.
> > > 
> > > In his case, most of these will be noticed by the remaining nine buildds,
> > > anyway. 
> > 
> > But the uploaded binaries will still be in the archive with broken
> > sources.
> 
> Er, so? He'll still get RC bugs filed, and will have to upload another
> revision, which would be fixed.

Imagine for eample the case where the sources are missing files, as
happens too often. Then the binary is in violation of the GPL.

Not good. So why not let the autobuilder do their job for all archs.

MfG
Goswin

Bug#159037: general: Time Problem

[Matt Filizzi]

On Sun, Sep 01, 2002 at 06:47:06AM +0200, Goswin Brederlow wrote:
> "Matt Filizzi" <[EMAIL PROTECTED]> writes:
> 
> > Package: general
> > Version: N/A; reported 2002-08-31
> > Severity: normal
> > Tags: sid
> > 
> > I don't know what is causing this problem but all I know is that I have
> > narrowed it down to being caused either by a package or by the install
> > system.  I installed from the woody install disks then upgraded to sid.
> > What happenes is that the time jumps ahead then back, eg (this is output
> > from "while true; do date;done"
> > 
> > Sat Aug 31 19:07:26 EDT 2002
> > Sat Aug 31 19:07:26 EDT 2002
> > Sat Aug 31 19:07:26 EDT 2002
> > Sat Aug 31 19:07:26 EDT 2002
> > Sat Aug 31 20:19:01 EDT 2002
> > Sat Aug 31 20:19:01 EDT 2002
> > Sat Aug 31 20:19:01 EDT 2002
> > Sat Aug 31 19:07:27 EDT 2002
> > Sat Aug 31 19:07:27 EDT 2002
> > 
> > The only thing I did differently then previous installs was I told the
> > installer that it could set the bios go UTC.  The only time it is really
> > noticable is when in X, the screensaver kicks in when it jumps.
> 
> ntpdate, ntp, chrony,  installed?
> 
> Maybe two of them, one with summer time, one without in its config?
> 

ntpdate and ntp are installed, however they were installed in an attempt 
to solve this problem (with no luck).

-- 
Matt (Fizz) Filizzi All that is required for
http://beyond.hjsoft.comEvil to triumph is that
[EMAIL PROTECTED]  good people do nothing.
  - Edmund Burke


pgpW48IbnUIc7.pgp
Description: PGP signature

Re: Improper NMU (Re: NMU for libquota-perl)

[Colin Watson]

On Sun, Sep 01, 2002 at 12:42:20PM -0400, Elie Rosenblum wrote:
> I also don't see a bug submitted with this. If you're submitting
> NMU's, you sure as hell better be submitting bugs with patches (or
> the fact that no patch is required other than rebuilding with an
> updated system).
> 
> Please delete your uploads. You are violating policy.
> 
> For debian-devel: The NMU here was made to rebuild for perl 5.8;
> no other changes would have been necessary.
> 
> What is the concensus on this? I'm not talking out of my ass here,
> am I?

The perl 5.8 transition was announced several weeks ago (to
-devel-announce, which everybody reads, right?), and there was an
opportunity to upload packages to a staging area so that the transition
in unstable would be less painful. The uploads that have been made this
weekend are for those packages that didn't take advantage of the several
weeks' notice that were given.

If you don't want the NMU, *please* make a maintainer upload. That's the
point of the delayed queue.

-- 
Colin Watson  [EMAIL PROTECTED]

Re: Improper NMU (Re: NMU for libquota-perl)

[Andreas Metzler]

Elie Rosenblum <[EMAIL PROTECTED]> wrote:
> On Sun, Sep 01, 2002 at 06:37:52PM +0200, Bas Zoetekouw wrote:
[Trivial NMU which was needed for perl-5.8 transition was made on BSP
to delayed queue without beforehand notice to the maintainer]
> Please delete your uploads. You are violating policy.

Hello,
Could you please show me the respective line in policy?

You did get some mail notice (including the changelog of the NMU)
before the package was/is going to be installed, didn't you?

> For debian-devel: The NMU here was made to rebuild for perl 5.8;
> no other changes would have been necessary.
[...]

Why are you upset about it? Was the quality of the NMU bad? One of the
main points of a BSP is afaik that you can make NMUs to delayed
_without_ previous notice to the maintainer.
 cu andreas (no debian developer)
-- 
Unofficial _Debian-packages_ of latest _tin_
http://www.logic.univie.ac.at/~ametzler/debian/tin-snapshot/

Re: Improper NMU (Re: NMU for libquota-perl)

[Raphael Hertzog]

Le Sun, Sep 01, 2002 at 12:42:20PM -0400, Elie Rosenblum écrivait:
> I also don't see a bug submitted with this. If you're submitting
> NMU's, you sure as hell better be submitting bugs with patches (or
> the fact that no patch is required other than rebuilding with an
> updated system).

The NMUer has to send the patch of the NMU to the maintainer, either
through the BTS or directly, yes.

> Please delete your uploads. You are violating policy.

Policy doesn't rule the NMUs. There's no rule for NMUs, just
guidelines ... and the guideline during a BSP are "NMU without prior
notification but upload to DELAYED in order to leave some time to the
maintainer if he's not happy with the NMU".

> For debian-devel: The NMU here was made to rebuild for perl 5.8;
> no other changes would have been necessary.

You should stop complaining about the NMU, the perl 5.8 upgrade has
been announced twice on debian-deval-announce.

If you were a good maintainer, you would already have uploaded a fixed
package compiled against perl 5.8 and you wouldn't have had a single
problem.

So please ... don't complain about NMUers when they are only trying ot
help you !

Cheers,
-- 
Raphaël Hertzog -+- http://www.ouaza.com
Formation Linux et logiciel libre : http://www.logidee.com

Re: Improper NMU (Re: NMU for libquota-perl)

[David B Harris]

On Sun, 1 Sep 2002 12:42:20 -0400
Elie Rosenblum <[EMAIL PROTECTED]> wrote:
> I also don't see a bug submitted with this. If you're submitting
> NMU's, you sure as hell better be submitting bugs with patches (or
> the fact that no patch is required other than rebuilding with an
> updated system).
> 
> Please delete your uploads. You are violating policy.
> 
> For debian-devel: The NMU here was made to rebuild for perl 5.8;
> no other changes would have been necessary.
> 
> What is the concensus on this? I'm not talking out of my ass here,
> am I?

Typically, when somebody rebuilds on of my packages for a library change
and then NMUs it, I say "thank you". :)


pgpom9cIl2Wft.pgp
Description: PGP signature

Improper NMU (Re: NMU for libquota-perl)

[Elie Rosenblum]

On Sun, Sep 01, 2002 at 06:37:52PM +0200, Bas Zoetekouw wrote:
> Hi Elie!
> 
> You wrote:
> 
> > Why did you NMU this instead of submitting a bug?
> > This is inappropriate.
> 
> Well, it's the intent of a bug squashing party to _decrease_ the number
> of RC bugs, not to increase it. Also, we're trying to get the perl
> transition done this weekend. 
> Of course, I could've mailed you beforehand, but the fix is trivial, so
> I didn't really see the need for that.
> 
> > I maintain several perl libraries, and it would be easier if I just did
> > them all at once.
> 
> Which you can still do. I uploaded to DELAYED, so sooner uploads will
> be prefered by the installer.

I also don't see a bug submitted with this. If you're submitting
NMU's, you sure as hell better be submitting bugs with patches (or
the fact that no patch is required other than rebuilding with an
updated system).

Please delete your uploads. You are violating policy.

For debian-devel: The NMU here was made to rebuild for perl 5.8;
no other changes would have been necessary.

What is the concensus on this? I'm not talking out of my ass here,
am I?

-- 
Elie Rosenblum That is not dead which can eternal lie,
http://www.cosanostra.net   And with strange aeons even death may die.
Admin / Mercenary / System Programmer - _The Necronomicon_

FYI: SDL_ttf for adoption

[Jérôme Marant]

Hi,

  SDL_ttf's current maintainer is no longer interested in it and
  doesn't mind giving it away.
  In addition, version 2 has been released for some time now.

  Cheers, 

-- 
Jérôme Marant

http://marant.org

Re: Terraform up for adoption

[Tomas Guemes]

Hi Mike,

On 01 Sep 2002 11:47:04 -0400
Mike Furr <[EMAIL PROTECTED]> wrote:

> On Sun, 2002-09-01 at 09:49, Tomas Guemes wrote:
> > if no ones has any complain, i will close the bug and try to package
> > 
> > the new upstream version as soon as posible.
> Don't close the bug.  Retitle to an ITA and then close it when you
> upload your new package.

Ok, thanks for the advice 

I will wait until tonite to retitle the bug to an ITA, maybe somebody
has another suggestion :)

greetings

Tomas
> 
> 
> -m
> 



pgp2guZ2bhu9Z.pgp
Description: PGP signature

Re: Terraform up for adoption

[Mike Furr]

On Sun, 2002-09-01 at 09:49, Tomas Guemes wrote:
> if no ones has any complain, i will close the bug and try to package 
> the new upstream version as soon as posible.
Don't close the bug.  Retitle to an ITA and then close it when you
upload your new package.


-m


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

Bug#159037: general: Time Problem

[Matt Filizzi]

On Sat, Aug 31, 2002 at 11:07:54PM -0700, Daniel Schepler wrote:
> "Matt Filizzi" <[EMAIL PROTECTED]> writes:
> 
> > Package: general
> > Version: N/A; reported 2002-08-31
> > Severity: normal
> > Tags: sid
> > 
> > I don't know what is causing this problem but all I know is that I have
> > narrowed it down to being caused either by a package or by the install
> > system.  I installed from the woody install disks then upgraded to sid.
> > What happenes is that the time jumps ahead then back, eg (this is output
> > from "while true; do date;done"
> > 
> > Sat Aug 31 19:07:26 EDT 2002
> > Sat Aug 31 19:07:26 EDT 2002
> > Sat Aug 31 19:07:26 EDT 2002
> > Sat Aug 31 19:07:26 EDT 2002
> > Sat Aug 31 20:19:01 EDT 2002
> > Sat Aug 31 20:19:01 EDT 2002
> > Sat Aug 31 20:19:01 EDT 2002
> > Sat Aug 31 19:07:27 EDT 2002
> > Sat Aug 31 19:07:27 EDT 2002
> > 
> > The only thing I did differently then previous installs was I told the
> > installer that it could set the bios go UTC.  The only time it is really
> > noticable is when in X, the screensaver kicks in when it jumps.
> 
> I can confirm that this bug happens on my system as well, even as far
> as the time jump being approximately 71 minutes.  I had ntpd
> installed.  I've recently tried disabling ntpd, but since it happens
> very sporadically for me, I can't tell yet whether disabling that
> works -- it sometimes takes on the order of several weeks of uptime
> before it happens.
> 
> My bios clock is also set to UTC.  I didn't even think of that as a
> possible cause before, but I don't see how this could be the cause
> since, as far as I know, the bios clock is only read or set at boot
> time or shutdown.

As far as I know, this bug is not caused by NTP, because I installed ntp 
in hopes it would solve the problem.  I've slowly been stoping running 
processes to try to narrow down the cause as well (even processes that 
seemingly have nothing to do with time) with no luck.

-- 
Matt (Fizz) Filizzi All that is required for
http://beyond.hjsoft.comEvil to triumph is that
[EMAIL PROTECTED]  good people do nothing.
  - Edmund Burke

Re: Terraform up for adoption

[Tomas Guemes]

Hi,

On Sun, 1 Sep 2002 23:04:08 +1000
Ben Burton <[EMAIL PROTECTED]> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> 
> So I have less and less to do with GNOME anything and I suspect the
> terraform package would really be better off with someone else. 
> Anyone wants to adopt it, be my guest.  There's a new upstream
> version, and hopefully the povray patches can be removed since povray
> 3.1 has finally been uploaded.
> 
> If anyone does adopt it please drop me an email to let me know.  The
> wnpp bug is #156372.

I will like to adopt it, i'm still in the process of being a dd.

if no ones has any complain, i will close the bug and try to package 
the new upstream version as soon as posible.

greetings

Tomas



pgplNpWdgQKRo.pgp
Description: PGP signature

Terraform up for adoption

[Ben Burton]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


So I have less and less to do with GNOME anything and I suspect the terraform 
package would really be better off with someone else.  Anyone wants to adopt 
it, be my guest.  There's a new upstream version, and hopefully the povray 
patches can be removed since povray 3.1 has finally been uploaded.

If anyone does adopt it please drop me an email to let me know.  The wnpp bug 
is #156372.

The package description is:
 Allows you to create a fractal terrain (also called a height field)
 and transform it using a number of algorithms. It is meant to be a tool for
 those who want to generate digital terrain models for use in raytracing or
 other simulations.

- -- 

Ben Burton
[EMAIL PROTECTED]  |  [EMAIL PROTECTED]
http://baasil.humbug.org.au/bab/
Public Key: finger [EMAIL PROTECTED]

If Michelangelo had been straight, the Sistine Chapel would have been
wallpapered.
- Robin Tyler, Washington, 9 Jan 1988

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

iD8DBQE9chBLMQNuxza4YcERAhT/AJ9LUaBePjYJIU3FXChAMuw9+5mPiwCfSgYP
SmJhE4d2k0R2vYabXGEVA3o=
=R03r
-END PGP SIGNATURE-

$BL$>5Bz9-9p"(AGE($J=P2q$$(B

[LOVE GET!]

<$BAw?.LOVE GET!
$B"(Aw?.$r4uK>$7$J$$J}$O([EMAIL PROTECTED](B
$BJV?.$*4j$$CW$7$^$9(B
$BO"[EMAIL PROTECTED](B
(B06-6736-9153
(B
$B;E;vBgJQ!)(B
$B$?$^$K$O!"=P2q$C$F$k!)(B
$B%5%i%j!<[EMAIL PROTECTED]"%/%;%9!*(B
(B
(Bhttp://z852564.hoops.ne.jp/i/
(B
(B[EMAIL PROTECTED](B
(B[EMAIL PROTECTED]"B(MxMQ2DG=!*(B
$B=i2s(B30P$B%W%l%<%s%HCf!*!*(B

Bug#159037: general: Time Problem

[Bart Schuller]

On Sat, Aug 31, 2002 at 07:14:43PM -0400, Matt Filizzi wrote:
> I don't know what is causing this problem but all I know is that I have
> narrowed it down to being caused either by a package or by the install
> system.  I installed from the woody install disks then upgraded to sid.
> What happenes is that the time jumps ahead then back, eg (this is output
> from "while true; do date;done"

I've had the same thing happen and in my case it's caused by the VIA
chipset on my motherboard. Some kernels will print "probable hardware
bug: clock timer configuration lost - probably a VIA686a." which you can
check for in the dmesg output.

I notice that kernel 2.4.19 doesn't print this anymore and also doesn't
exhibit the problem, so I'm happy using that.

-- 
Bart.

Re: woody CD not bootable with adaptec + scsi-cdrom

[Richard Atterer]

On Sun, Sep 01, 2002 at 06:51:16AM +0200, Goswin Brederlow wrote:
> I the discovered that the woody CD (linuxtag prerelease) doesn't
> boot. I heard of similar for the real woody release CDs on irc.
> 
> Can anyone boot the CDs, which one of the set and what hardware? 
> Same if you can't boot.
> 
> Also whats different between potato and woody? potato has this
> multiboot thing and woody not anymore, right? What was wrong with
> it? Seems to be more compatible the old way.

Before the woody release, it became clear that many people needed
different kernels for their hardware: Quite a few need bf24 for their
new hardware (e.g. USB keyboard), others need vanilla for their
ancient hardware. See  for
info on the different flavours.

At the same time, it was considered important to allow installation
using just the first CD, so somebody came up with the multiboot idea.

Experiments then showed that multiboot didn't work on some machines -
*however*, this can be said of all methods which allow you to choose
between several images at boot time.

So the final solution was to use multiboot only on the first CD, the
other CDs use the same method as potato. The few machines on which it
fails are either old or have a SCSI CD-ROM, booting from one of the
later CDs should work for them. AFAIK if the woody release multiboot
CD fails, it even prints a message which tells you to do that.

Cheers,

  Richard

-- 
  __   _
  |_) /|  Richard Atterer |  CS student at the Technische  |  GnuPG key:
  | \/¯|  http://atterer.net  |  Universität München, Germany  |  0x888354F7
  ¯ '` ¯

Re: Non-Intel package uploads by maintainer

[Josip Rodin]

On Sun, Sep 01, 2002 at 06:44:24AM +0200, Goswin Brederlow wrote:
> > > Don't upload binaries at all.
> > > 
> > > The autobuilder will check the build-process of your package. It will
> > > build in a clean chroot with proper build-depends. With proper
> > > versions of all tools.
> > > 
> > > If you upload binaries you get the usual bugs of missing
> > > build-depends, wrong versions of tools or libraries and so on. Just
> > > because you had them installed.
> > 
> > In his case, most of these will be noticed by the remaining nine buildds,
> > anyway. 
> 
> But the uploaded binaries will still be in the archive with broken
> sources.

Er, so? He'll still get RC bugs filed, and will have to upload another
revision, which would be fixed.

-- 
 2. That which causes joy or happiness.

Re: woody CD not bootable with adaptec + scsi-cdrom

[Andreas Metzler]

Disclaimer: Because I do not work on the debian-cd, bf or installer
and do not follow the mailing lists regularily, I do not know much
about this issue and there are probably lots of errors in this mail.

Goswin Brederlow <[EMAIL PROTECTED]> wrote:
> I just crasht my system working on libsafe and hat to boot from CD.

> I the discovered that the woody CD (linuxtag prerelease) doesn't
> boot. I heard of similar for the real woody release CDs on irc.

> Can anyone boot the CDs, which one of the set and what hardware?
> Same if you can't boot.

Hello,
Lots of people can, the official CD-image _were_ tested. - I think the
linuxtag prerelease CD is similar to the official CD1.

I can boot from CD1, on a PentiumMMX-class machine (SiS 5591/5), an
iirc 1 year old Athlon 800 (VIA 133) and a 2 month old Duron1200
(VIA 266A).

> Also whats different between potato and woody?

potato used floppy-emulation, woody _CD1_ uses isolinux(??).

> potato has this multiboot thing and woody not anymore, right? What
> was wrong with it?  Seems to be more compatible the old way.

It is not, search the Debian-CD mailing-list.

IIRC: Basically Microsoft switched the CD-boot method they used for
their OS CDs, the BIOS manufacturers followed suit and dropped support
for or did not fix bugs in the old method and added support for the
"new" method. For maximum compatibility with old computers you need
floppy-emulation, for new computers you need the new method. BTW
RedHat et al. don't use floppy-emulation, too.

If your computer cannot boot woody CD1 try CD2-CD7 - they use
floppy-emulation and should work on old computers.
   cu andreas
-- 
Hey, da ist ein Ballonautomat auf der Toilette!
Unofficial _Debian-packages_ of latest _tin_
http://www.logic.univie.ac.at/~ametzler/debian/tin-snapshot/

Re: [Mark.Martinec@ijs.si: Re: perl 5.8 breaks amavis]

[Graeme Mathieson]

On Thu, Aug 29, 2002 at 10:28:43AM +0100, Colin Watson wrote:
> On Thu, Aug 29, 2002 at 10:34:04AM +0200, Marcelo E. Magallon wrote:
r > >> Brian May <[EMAIL PROTECTED]> writes:
> >  > I don't have an unstable system handy...
> >  > 
> >  > So can anybody tell if if perl 5.8 has Unix::Syslog?
> >  > 
> >  > Do I need to add an extra depends or something to amavis?

Yup.  That's why I built the package in the first place (I'd been
intending to do Amavis too).

> Is Graeme Mathieson around? (He's a sponsored maintainer, so there's no
> "last seen" information in the database.) He has two other packages
> which also need rebuilt for perl 5.8. If need be I can supply either
> sponsorship or NMUs.

I'm around, just not paying enough attention. :-)  I'm on holiday just
now somewhere in the vicinity of London, but I'll be back by Tuesday.
I'll rebuild stuff and upload it then.  I think with Unix::Syslog in
particular, there's a new version just been released.
-- 
[EMAIL PROTECTED]  http://www.wossname.org.uk/~mathie/

Bug#159072: ITP: standalone-zodb -- an object database for Python

[Moshe Zadka]

Package: wnpp
Version: N/A; reported 2002-09-01
Severity: wishlist

* Package name: standalone-zodb
  Version : 1.0
  Upstream Author : Zope Corporation
* URL : http://www.some.org/
* License : ZPL v2.0
  Description : an object database for Python

ZODB is the object database at the base of the Zope framework.
Standalone ZODB is a release which allows one to use ZODB without
the Zope baggage.

Packages available at http://moshez.org/debian/


-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux green 2.4.19-gentoo-r7 #1 Wed Jun 26 00:58:30 IDT 2002 i686
Locale: LANG=C, LC_CTYPE=C

Re: Non-Intel package uploads by maintainer

[Joerg Jaspert]

Goswin Brederlow <[EMAIL PROTECTED]> writes:

>> > The autobuilder will check the build-process of your package.
>> YOU should do that.
> To err is human.

Yes. But that does not transform to "Dont do it, i could make an error."

>> There are enough ways to test your Build-Depends.
>> And if you have an up2date chroot the versions of the Depends should be
>> alright.
> How many maintainer realy bother?

Everyone who knows what he does?

> And then there are still mistakes.

To err is human. But if you dont try it -> go away. It is your job to
get the package in the best state, not the job of buildds to fail on
a package just because the Maintainer is to lazy to check build-depends
himself.


-- 
begin  OjE-ist-scheisse.txt
bye, Joerg Encrypted Mail preferred!
Registered Linux User #97793 @ http://counter.li.org
end

pgp4YIXfl1JAx.pgp
Description: PGP signature

Bug#159037: general: Time Problem

[Philip Charles]

On 31 Aug 2002, Daniel Schepler wrote:

> "Matt Filizzi" <[EMAIL PROTECTED]> writes:
>
> > Package: general
> > Version: N/A; reported 2002-08-31
> > Severity: normal
> > Tags: sid
> >
> > I don't know what is causing this problem but all I know is that I have
> > narrowed it down to being caused either by a package or by the install
> > system.  I installed from the woody install disks then upgraded to sid.
> > What happenes is that the time jumps ahead then back, eg (this is output
> > from "while true; do date;done"
> >
> > Sat Aug 31 19:07:26 EDT 2002
> > Sat Aug 31 19:07:26 EDT 2002
> > Sat Aug 31 19:07:26 EDT 2002
> > Sat Aug 31 19:07:26 EDT 2002
> > Sat Aug 31 20:19:01 EDT 2002
> > Sat Aug 31 20:19:01 EDT 2002
> > Sat Aug 31 20:19:01 EDT 2002
> > Sat Aug 31 19:07:27 EDT 2002
> > Sat Aug 31 19:07:27 EDT 2002
> >
> > The only thing I did differently then previous installs was I told the
> > installer that it could set the bios go UTC.  The only time it is really
> > noticable is when in X, the screensaver kicks in when it jumps.
>
> I can confirm that this bug happens on my system as well, even as far
> as the time jump being approximately 71 minutes.  I had ntpd
> installed.  I've recently tried disabling ntpd, but since it happens
> very sporadically for me, I can't tell yet whether disabling that
> works -- it sometimes takes on the order of several weeks of uptime
> before it happens.
>
> My bios clock is also set to UTC.  I didn't even think of that as a
> possible cause before, but I don't see how this could be the cause
> since, as far as I know, the bios clock is only read or set at boot
> time or shutdown.

I don't know if this is related, but some of us in New Zealand noticed the
system clock getting very slow.  After some investigation we narrowed it
down to a bug in the 2.4 kernel.  The slowdown happened in my case when
CDs were being burnt so it seems to be related to some real-time critical
operations.  I just remembered to run "hwclock -s" as I have burnt some
CDs earlier today, the hardware clock keeps good time.

Phil.

--
  Philip Charles; 39a Paterson Street, Abbotsford, Dunedin, New Zealand
   +64 3 488 2818Fax +64 3 488 2875Mobile 025 267 9420
 [EMAIL PROTECTED] - preferred.  [EMAIL PROTECTED]
 I sell GNU/Linux & GNU/Hurd CDs.   See http://www.copyleft.co.nz

Bug#159037: general: Time Problem

[Daniel Schepler]

"Matt Filizzi" <[EMAIL PROTECTED]> writes:

> Package: general
> Version: N/A; reported 2002-08-31
> Severity: normal
> Tags: sid
> 
> I don't know what is causing this problem but all I know is that I have
> narrowed it down to being caused either by a package or by the install
> system.  I installed from the woody install disks then upgraded to sid.
> What happenes is that the time jumps ahead then back, eg (this is output
> from "while true; do date;done"
> 
> Sat Aug 31 19:07:26 EDT 2002
> Sat Aug 31 19:07:26 EDT 2002
> Sat Aug 31 19:07:26 EDT 2002
> Sat Aug 31 19:07:26 EDT 2002
> Sat Aug 31 20:19:01 EDT 2002
> Sat Aug 31 20:19:01 EDT 2002
> Sat Aug 31 20:19:01 EDT 2002
> Sat Aug 31 19:07:27 EDT 2002
> Sat Aug 31 19:07:27 EDT 2002
> 
> The only thing I did differently then previous installs was I told the
> installer that it could set the bios go UTC.  The only time it is really
> noticable is when in X, the screensaver kicks in when it jumps.

I can confirm that this bug happens on my system as well, even as far
as the time jump being approximately 71 minutes.  I had ntpd
installed.  I've recently tried disabling ntpd, but since it happens
very sporadically for me, I can't tell yet whether disabling that
works -- it sometimes takes on the order of several weeks of uptime
before it happens.

My bios clock is also set to UTC.  I didn't even think of that as a
possible cause before, but I don't see how this could be the cause
since, as far as I know, the bios clock is only read or set at boot
time or shutdown.
-- 
Daniel Schepler  "Please don't disillusion me.  I
[EMAIL PROTECTED]haven't had breakfast yet."
 -- Orson Scott Card

Re: Bug#159037: general: Time Problem

[Daniel Schepler]

(Already sent to the bug report address -- I accidentally Cc'ed to
[EMAIL PROTECTED] the first time.)

"Matt Filizzi" <[EMAIL PROTECTED]> writes:

> Package: general
> Version: N/A; reported 2002-08-31
> Severity: normal
> Tags: sid
> 
> I don't know what is causing this problem but all I know is that I have
> narrowed it down to being caused either by a package or by the install
> system.  I installed from the woody install disks then upgraded to sid.
> What happenes is that the time jumps ahead then back, eg (this is output
> from "while true; do date;done"
> 
> Sat Aug 31 19:07:26 EDT 2002
> Sat Aug 31 19:07:26 EDT 2002
> Sat Aug 31 19:07:26 EDT 2002
> Sat Aug 31 19:07:26 EDT 2002
> Sat Aug 31 20:19:01 EDT 2002
> Sat Aug 31 20:19:01 EDT 2002
> Sat Aug 31 20:19:01 EDT 2002
> Sat Aug 31 19:07:27 EDT 2002
> Sat Aug 31 19:07:27 EDT 2002
> 
> The only thing I did differently then previous installs was I told the
> installer that it could set the bios go UTC.  The only time it is really
> noticable is when in X, the screensaver kicks in when it jumps.

I can confirm that this bug happens on my system as well, even as far
as the time jump being approximately 71.5 minutes.  I had ntpd
installed.  I've recently tried disabling ntpd, but since it happens
very sporadically for me, I can't tell yet whether disabling that
works -- it sometimes takes on the order of a couple weeks of uptime
before it happens.

My bios clock is also set to UTC.  I didn't even think of that as a
possible cause before, but I don't see how this could be the cause
since, as far as I know, the bios clock is only read or set at boot
time or shutdown.
-- 
Daniel Schepler  "Please don't disillusion me.  I
[EMAIL PROTECTED]haven't had breakfast yet."
 -- Orson Scott Card