Hi Holger, 在 2019-11-24日的 12:15 +0100，Holger Wansing写道： > Hi, > > I have upload rights for d-i packages, so sponsoring not needed. > But I need help with such an non-source-only upload, as it seems :-| > > My amd64 binary upload was just rejected, I suspect because it does go > through NEW: > > > ============================================================================ > ===== > Date: Sun, 24 Nov 2019 10:53:57 +0000 > From: Debian FTP Masters <ftpmas...@ftp-master.debian.org> > To: Holger Wansing <hwans...@mailbox.org>, Anton Zinoviev < > zinov...@debian.org> > Subject: tasksel_3.57_amd64.changes REJECTED > > > > > ACL dm: NEW uploads are not allowed > > binary:task-chinese-s is NEW. > binary:task-cyrillic-kde-desktop is NEW. > binary:task-hebrew-desktop is NEW. > binary:task-macedonian is NEW. > binary:task-slovenian-kde-desktop is NEW. > binary:task-chinese-s is NEW. > binary:task-hebrew-desktop is NEW. > binary:task-slovenian-kde-desktop is NEW. > binary:task-cyrillic-kde-desktop is NEW. > binary:task-macedonian is NEW. > > ============================================================================ > ===== > > > > But I cannot find any documentation about how to define, if such upload > should go through NEW (or maybe I have overlooked it?)
I believe it is like this. If: 1. You are making an upload onto Sid that contains binary package foo provided by src:foobar, 2. The binary package foo is neither present in Sid nor in Experimental, ...then this upload must go through NEW, which is the same as our current situation. > In the past, I have only done source-only uploads. I have elected to build tasksel 3.57 from git packaging repo ( https://salsa.debian.org/installer-team/tasksel) and made a non-source-only upload onto DELAYED/2. It should enter the NEW queue 2 days later. Dear FTP Masters: please review and accept this upload after it appears in the NEW queue. As discussed in https://bugs.debian.org/944116 , no new packages were actually introduced and this upload was made to circumvent a bug that potentially lay in DAK; this bug should have been fixed by now. Please let me know if further actions are needed. -- Best, Boyuan Yang
