Re: Bits from the Release Team: ride like the wind, Bullseye!
On Sun, 2019-07-21 at 10:55 -0300, Ivo De Decker wrote: > Hi Ben, > > Sorry for not getting back to you about this earlier. > > On 7/7/19 3:43 PM, Ben Hutchings wrote: > > On Sun, 2019-07-07 at 02:47 +0100, Jonathan Wiltshire wrote: > > [...] > > > No binary maintainer uploads for bullseye > > > = > > > > > > The release of buster also means the bullseye release cycle is about to > > > begin. > > > From now on, we will no longer allow binaries uploaded by maintainers to > > > migrate to testing. This means that you will need to do source-only > > > uploads if > > > you want them to reach bullseye. > > > > I support this move in principle, but: > > > > >Q: I already did a binary upload, do I need to do a new (source-only) > > > upload? > > >A: Yes (preferably with other changes, not just a version bump). > > > > > >Q: I needed to do a binary upload because my upload went to the NEW > > > queue, > > > do I need to do a new (source-only) upload for it to reach bullseye? > > >A: Yes. We also suggest going through NEW in experimental instead of > > > unstable > > > where possible, to avoid disruption in unstable. > > [...] > > > > This is not going to fly for src:linux. We can't stage ABI bumps in > > experimental as we typically have a different upstream versions in > > unstable and experimental. We even need to do ABI bumps in stable from > > time to time. > > We are aware that src:linux is a special case here. I added an exception > for the arch:all binaries from src:linux. When the next ABI bump in > unstable happens, feel free to let me know, so that I can check if it > works as expected. linux version 5.2.17-1 was the first version that included an ABI bump and did not have any regressions that blocked it from testing. It has transitioned to testing including the developer-built arch:all packages, so I believe that this exception works. Thank you! Ben. -- Ben Hutchings Unix is many things to many people, but it's never been everything to anybody. signature.asc Description: This is a digitally signed message part
Re: process-upload issue (was: Re: Bits from the Release Team: ride like the wind, Bullseye!)
On Mon, 2019-08-05 at 19:25 +0100, Adam D. Barratt wrote:
> [CC += ftpmaster]
>
> On Mon, 2019-08-05 at 17:49 +0100, Ben Hutchings wrote:
> > On Sun, 2019-07-21 at 10:55 -0300, Ivo De Decker wrote:
> > [...]
> > > We are aware that src:linux is a special case here. I added an
> > > exception for the arch:all binaries from src:linux. When the next
> > > ABI bump in unstable happens, feel free to let me know, so that I
> > > can check if it works as expected.
> >
> > I uploaded a new version (5.2.6-1) to unstable today (11:35 UTC), and
> > the upload was acknowledged (11:40 UTC) but it hasn't yet showed up
> > in the NEW queue.
>
> That looks like a problem on the archive side. The dak log suggests an
> issue logging an issue with a .changes file:
>
> 20190805181929|process-upload|dak|exception|Traceback (most recent call last):
> 20190805181929|process-upload|dak|exception| File "/usr/local/bin/dak", line
> 228, in main
> 20190805181929|process-upload|dak|exception|module.main()
> 20190805181929|process-upload|dak|exception| File
> "/srv/ftp-master.debian.org/dak/dak/process_upload.py", line 591, in main
> 20190805181929|process-upload|dak|exception|process_changes(changes_files)
> 20190805181929|process-upload|dak|exception| File
> "/srv/ftp-master.debian.org/dak/dak/process_upload.py", line 502, in
> process_changes
> 20190805181929|process-upload|dak|exception|Logger.log([filename, "Error
> while loading changes: {0}".format(e)])
> 20190805181929|process-upload|dak|exception|UnicodeEncodeError: 'ascii' codec
> can't encode character u'\ufffd' in position 223: ordinal not in range(128)
Thanks for that. Both my uploads last week seem to have been processed
successfully, but neither of them built on all release architectures so
we haven't yet been able to see whether the special case works.
Ben.
--
Ben Hutchings
Humour is the best antidote to reality.
signature.asc
Description: This is a digitally signed message part
process-upload issue (was: Re: Bits from the Release Team: ride like the wind, Bullseye!)
[CC += ftpmaster]
On Mon, 2019-08-05 at 17:49 +0100, Ben Hutchings wrote:
> On Sun, 2019-07-21 at 10:55 -0300, Ivo De Decker wrote:
> [...]
> > We are aware that src:linux is a special case here. I added an
> > exception for the arch:all binaries from src:linux. When the next
> > ABI bump in unstable happens, feel free to let me know, so that I
> > can check if it works as expected.
>
> I uploaded a new version (5.2.6-1) to unstable today (11:35 UTC), and
> the upload was acknowledged (11:40 UTC) but it hasn't yet showed up
> in the NEW queue.
That looks like a problem on the archive side. The dak log suggests an
issue logging an issue with a .changes file:
20190805181929|process-upload|dak|exception|Traceback (most recent call last):
20190805181929|process-upload|dak|exception| File "/usr/local/bin/dak", line
228, in main
20190805181929|process-upload|dak|exception|module.main()
20190805181929|process-upload|dak|exception| File
"/srv/ftp-master.debian.org/dak/dak/process_upload.py", line 591, in main
20190805181929|process-upload|dak|exception|process_changes(changes_files)
20190805181929|process-upload|dak|exception| File
"/srv/ftp-master.debian.org/dak/dak/process_upload.py", line 502, in
process_changes
20190805181929|process-upload|dak|exception|Logger.log([filename, "Error
while loading changes: {0}".format(e)])
20190805181929|process-upload|dak|exception|UnicodeEncodeError: 'ascii' codec
can't encode character u'\ufffd' in position 223: ordinal not in range(128)
Regards,
Adam
Re: Bits from the Release Team: ride like the wind, Bullseye!
On Sun, 2019-07-21 at 10:55 -0300, Ivo De Decker wrote: [...] > We are aware that src:linux is a special case here. I added an exception > for the arch:all binaries from src:linux. When the next ABI bump in > unstable happens, feel free to let me know, so that I can check if it > works as expected. I uploaded a new version (5.2.6-1) to unstable today (11:35 UTC), and the upload was acknowledged (11:40 UTC) but it hasn't yet showed up in the NEW queue. Ben. -- Ben Hutchings Beware of programmers who carry screwdrivers. - Leonard Brandwein signature.asc Description: This is a digitally signed message part
Re: Bits from the Release Team: ride like the wind, Bullseye!
Hi Ben, Sorry for not getting back to you about this earlier. On 7/7/19 3:43 PM, Ben Hutchings wrote: On Sun, 2019-07-07 at 02:47 +0100, Jonathan Wiltshire wrote: [...] No binary maintainer uploads for bullseye = The release of buster also means the bullseye release cycle is about to begin. From now on, we will no longer allow binaries uploaded by maintainers to migrate to testing. This means that you will need to do source-only uploads if you want them to reach bullseye. I support this move in principle, but: Q: I already did a binary upload, do I need to do a new (source-only) upload? A: Yes (preferably with other changes, not just a version bump). Q: I needed to do a binary upload because my upload went to the NEW queue, do I need to do a new (source-only) upload for it to reach bullseye? A: Yes. We also suggest going through NEW in experimental instead of unstable where possible, to avoid disruption in unstable. [...] This is not going to fly for src:linux. We can't stage ABI bumps in experimental as we typically have a different upstream versions in unstable and experimental. We even need to do ABI bumps in stable from time to time. We are aware that src:linux is a special case here. I added an exception for the arch:all binaries from src:linux. When the next ABI bump in unstable happens, feel free to let me know, so that I can check if it works as expected. Thanks, Ivo
Re: Bits from the Release Team: ride like the wind, Bullseye!
> "Ben" == Ben Hutchings writes: Ben> On Sun, 2019-07-07 at 02:47 +0100, Jonathan Wiltshire wrote: Ben> [...] >> No binary maintainer uploads for bullseye >> = >> >> The release of buster also means the bullseye release cycle is >> about to begin. From now on, we will no longer allow binaries >> uploaded by maintainers to migrate to testing. This means that >> you will need to do source-only uploads if you want them to reach >> bullseye. Ben> I support this move in principle, but: Ben> This is not going to fly for src:linux. We can't stage ABI Ben> bumps in experimental as we typically have a different upstream Ben> versions in unstable and experimental. We even need to do ABI Ben> bumps in stable from time to time. Ben> I think that the requirement to upload binary packages for Ben> binary-NEW (but not source-NEW) needs to go. I agree with Ben. There are a lot of good reasons to stage (possibly even most) binary new packages through experimental. Ben has talked about cases where experimental can't work. I'd like to talk about cases where it is the wrong answer. However, we've gotten a lot of feedback from our maintainers over the years that anything that adds an extra round trip to their workflow is significantly demotivating. If I need to wait for something to go through new, and then after it goes through new do an extra thing to accomplish my goal, that increases the cost of what I'm doing significantly. If it's a simple soname bump because of a new symbol, that doesn't always require experimental. Thinking back to my own experience with krb5, I have a good handle on when ABI bumps need to go through experimental and when things are going to be fine through unstable. I haven't made a lot of mistakes in that front--uploading things to unstable that ended up being broken enough we wished they had gone through experimental. I know I'm not alone. I think that for this to fly, binaries for binary new need to go. I understand that balancing the trade offs here requires a bit of a mind meld between the ftp team and the release team, and I understand that cross team decision making is more complex here. I'd be happy to facilitate any discussion around the trade offs if that would be useful. --Sam
Re: Bits from the Release Team: ride like the wind, Bullseye!
On Sun, 2019-07-07 at 02:47 +0100, Jonathan Wiltshire wrote: [...] > No binary maintainer uploads for bullseye > = > > The release of buster also means the bullseye release cycle is about to begin. > From now on, we will no longer allow binaries uploaded by maintainers to > migrate to testing. This means that you will need to do source-only uploads if > you want them to reach bullseye. I support this move in principle, but: > Q: I already did a binary upload, do I need to do a new (source-only) > upload? > A: Yes (preferably with other changes, not just a version bump). > > Q: I needed to do a binary upload because my upload went to the NEW queue, > do I need to do a new (source-only) upload for it to reach bullseye? > A: Yes. We also suggest going through NEW in experimental instead of > unstable > where possible, to avoid disruption in unstable. [...] This is not going to fly for src:linux. We can't stage ABI bumps in experimental as we typically have a different upstream versions in unstable and experimental. We even need to do ABI bumps in stable from time to time. I think that the requirement to upload binary packages for binary-NEW (but not source-NEW) needs to go. Ben. -- Ben Hutchings Time is nature's way of making sure that everything doesn't happen at once. signature.asc Description: This is a digitally signed message part
