Bug#457075: salome_5.1.3-7_amd64.changes REJECTED
On Thu, 2010-05-06 at 06:31 +0200, Joerg Jaspert wrote: I'm sorry but I need to temporarily reject your package, as it is by far the largest currently sitting in the NEW queue and ftp-master is currently running low on disc space. I didn't had the time to investigate your package (beside seeing that it is the largest in the NEW queue and rejecting it would reduce the size of NEW by more than a half!). If I make a version without the -doc binary, that takes it from 859 to 235 MiB including .orig.tar.gz. (The -doc binary has a huge amount of very large generated documentation...) Does that reduce it's size enough to consider re-uploading? Yes. Thanks very much, I'll prepare and upload it today. I can appreciate the burden of checking a package of this size. In this case it wasnt about checking it at all. Only about the sheer size and the fact that ftpmaster does have some space issues. I understand, the -doc package has a ridiculous size. We're planning to cut it into separate user and developer documentation, and split it further into core and specialty functionality. That doesn't help the upload size, but will help users to get the help they need without using excessive disk space. A better solution is currently being worked on, but might need some time. Once we have a) a new ftp-master server or b) archieved the etch release, you can reupload your package. Makes sense. But if the above isn't sufficient reduction in the package size, how will we know when this happens? The archive of the etch release will get a message to d-d-a or so. :) Also, we are getting new hardware for ftpmaster, which has much more diskspace too, and which will finally allow us to setup data.debian.org. Your package, at least the -doc part, seems a good target for that. Thanks, we'll look for the announcements on d-d-a and add -doc when appropriate. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#457075: salome_5.1.3-7_amd64.changes REJECTED
On Wed, 2010-05-05 at 18:09 +, Alexander Reichle-Schmehl wrote: Hi Maintainer! I'm sorry but I need to temporarily reject your package, as it is by far the largest currently sitting in the NEW queue and ftp-master is currently running low on disc space. I didn't had the time to investigate your package (beside seeing that it is the largest in the NEW queue and rejecting it would reduce the size of NEW by more than a half!). Oh dear, that's too bad... But yes, it is a gigantic package. If I make a version without the -doc binary, that takes it from 859 to 235 MiB including .orig.tar.gz. (The -doc binary has a huge amount of very large generated documentation...) Does that reduce it's size enough to consider re-uploading? I can appreciate the burden of checking a package of this size. But It's taken a good-sized team a few months of concerted effort to get this far (development actually started about two and a half years ago), and we'd like to be able to use the BTS to track the various issues with the package, among other concerns. [Also, there's a summary of all of the copyright statements in every file of every module in debian/copyright-audit/ to make your life easier.] A better solution is currently being worked on, but might need some time. Once we have a) a new ftp-master server or b) archieved the etch release, you can reupload your package. Makes sense. But if the above isn't sufficient reduction in the package size, how will we know when this happens? Thanks, Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#457075: salome_5.1.3-7_amd64.changes REJECTED
I'm sorry but I need to temporarily reject your package, as it is by far the largest currently sitting in the NEW queue and ftp-master is currently running low on disc space. I didn't had the time to investigate your package (beside seeing that it is the largest in the NEW queue and rejecting it would reduce the size of NEW by more than a half!). If I make a version without the -doc binary, that takes it from 859 to 235 MiB including .orig.tar.gz. (The -doc binary has a huge amount of very large generated documentation...) Does that reduce it's size enough to consider re-uploading? Yes. I can appreciate the burden of checking a package of this size. In this case it wasnt about checking it at all. Only about the sheer size and the fact that ftpmaster does have some space issues. But It's taken a good-sized team a few months of concerted effort to get this far (development actually started about two and a half years ago), and we'd like to be able to use the BTS to track the various issues with the package, among other concerns. Oh sure, of course. A better solution is currently being worked on, but might need some time. Once we have a) a new ftp-master server or b) archieved the etch release, you can reupload your package. Makes sense. But if the above isn't sufficient reduction in the package size, how will we know when this happens? The archive of the etch release will get a message to d-d-a or so. :) Also, we are getting new hardware for ftpmaster, which has much more diskspace too, and which will finally allow us to setup data.debian.org. Your package, at least the -doc part, seems a good target for that. -- bye, Joerg [ New Maintainer Prozess ] panthera ein jahr ist ein bisschen zu optimistisch, _rene_ panthera: kommt auf den NM/AM an. /* _rene_ ist pantheras AM und lässt sich mit pantheras package check schon ein wenig Zeit ;) */ -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87d3x9ps5c@delenn.ganneff.de
