On 1/28/21 8:36 PM, Paul Gevers wrote:
> Hi Matthias,
> 
> On 27-01-2021 22:42, Matthias Klose wrote:
>> I have been following the way the linux source package was uploaded.  
>> Apparently
>> the package entered unstable with just an announcement like this.  And more 
>> than
>> one time.
> 
> For linux there was alignment, but see below.
> 
>>> So, can you please clarify why you think these changes are needed? What
>>> are the risks of including or not including these changes? How are the
>>> risks mitigated?
>>
>> staging in experimental is not possible, unless you remove 2.36, or override 
>> it
>> bumping the epoch.
> 
> (or a +really version number).
> 
>>  - PR27218 is an obvious bug fix, avoiding a segfault.
>>  - DWARF5 is not enabled by default, the DWARF5 fixes are
>>    required for GCC 11 defaulting to use DWARF5. And no,
>>    I'm not planning to upload gcc-11 to unstable.
>>
>> I'm very unhappy about the private decision making for some uploads, while
>> showing a pedantic attitude towards others.
> 
> I must confess that indeed the alignment with the Release Team on linux
> uploads happened in private. It shouldn't have, or at least the outcome
> should have been public.
> 
>>  - PR27218 is an obvious bug fix, avoiding a segfault.
> 
> Sound OK to have.
> 
>>  - DWARF5 is not enabled by default, the DWARF5 fixes are
>>    required for GCC 11 defaulting to use DWARF5.
> 
> https://release.debian.org/britney/pseudo-excuses-experimental.html#binutils
> (for 2.36-1) shows a regression for glibc. Hence we're not totally
> confident. If it's not the default, why do we want this feature now?

the log ends with:

----------------8<----------------8<----------------8<-----------------

WARNING: log file truncated at 20 MB (before compression)

----------------8<----------------8<----------------8<-----------------
autopkgtest [01:21:39]: @@@@@@@@@@@@@@@@@@@@ summary
rebuild              FAIL non-zero exit status 2

> We would be happy with either of the following:
> 1) upload to unstable with PR27218 only
> 2) upload to experimental first (with a 2.36+really2.35.2 version) to
> check all is fine.

so I don't see what an upload for 2) would provide you with more information.

Reply via email to