On Fri, Jan 14, 2005 at 12:59:24PM +0100, Santiago Vila wrote: > On Thu, 13 Jan 2005, Steve Langasek wrote: > > On Thu, Jan 13, 2005 at 09:15:22PM +0100, Santiago Vila wrote: > > > Despite being ACCEPTed, this package failed the database sanity checks > > > at the time of install. This should only happen rarely and in > > > corner-cases (a binary upload of a package which has since been > > > melanie'd for example), so no code to do the necessary unaccept > > > actions has been written. These actions (e.g. bug reopening, > > > announcement rescinding, etc.) will have to be done by hand. Also, > > > the files have been left in the accepted directory; please deal with > > > them as well. > > > I receive a message like this every day now, and I'm still waiting for > > > somebody to tell me how do I "deal with them". > > The files in question are not in NEW; I'm pretty sure this corresponds to > > the UNACCEPTED state, which means the packages were accepted by katie and > > then something broke afterwards. > Yes, I know, but it's a very similar case: once the files disappear > from the queue, you don't seem to have control over them anymore. > I wonder why this message ask me to deal with them if I can't. In the ftp upload queue, you have access to delete files, but not to read them; this is necessary for crypto-in-main purposes (and is generally a good idea if you don't want your ftp site used as a warez exchange :P). Once the package is moved out of the ftp queue, if it needs to go through NEW processing, you can neither read the files nor access them to delete them. When the package is processed from NEW and moves to the accepted queue, you can read the files (http://incoming.debian.org) but you can't edit them. This is not without reason -- letting developers delete files after they've been accepted into this stage of processing would make an unholy mess of the archive database. If something breaks after the package is accepted and it then has to be kicked into an "unaccepted" state, the package has already touched the database, so fixing it up requires someone with administrative access to the archive. > > Please check with the ftpmasters on how to fix this. > I contacted them the very first day this happened. No reply so far. > That's why I asked here. If you or anybody else knows how to "deal > with them", I would be very interested to know. For the above reasons, "dealing with them" remains "bug ftp-master". -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature