https://tracker.debian.org/pkg/dballe
Hello, some time ago I uploaded a new version of dballe, which went through NEW because of a change in binary package names (SONAME bump, IIRC). It took two weeks to go through NEW and I turned my energy towards other things since then. Now I see that things got stuck for the transition to testing, and I'm asking for help figuring out what to do. I have this: > This package is part of the ongoing testing transition known as > python3.8. Please avoid uploads unrelated to this transition, they > would likely delay it and require supplementary work from the release > managers. On the other hand, if your package has problems preventing > it to migrate to testing, please fix them as soon as possible. You can > probably find supplementary information in the debian-release archives > or in the corresponding release.debian.org bug. And I have this: > Not built on buildd: arch all binaries uploaded by enrico, a new > source-only upload is needed to allow migration I was asked to do a binary upload to go through NEW, and now I'm asked to do a source only upload to go to testing. There are surely good reasons for that, and I wish there weren't. I don't really have a new version to upload, but I suppose I need to at least bump the debian version with no other changes in the package for it to be accepted. Then, if I did that, would I be helping the python3.8 transition by enabling a migration to testing, or getting in the way by delaying the transition and requiring supplementary work from the release managers? I feel a bit caught in a bureaucratic corner. Please help me with some directions to get out of that. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: https://tracker.debian.org/pkg/dballe
Hi Enrico, On 29-12-2019 09:52, Enrico Zini wrote: > some time ago I uploaded a new version of dballe, which went through NEW > because of a change in binary package names (SONAME bump, IIRC). It took > two weeks to go through NEW and I turned my energy towards other things > since then. > > Now I see that things got stuck for the transition to testing, and I'm > asking for help figuring out what to do. I'm happy to help. > I have this: > >> This package is part of the ongoing testing transition known as >> python3.8. Please avoid uploads unrelated to this transition, they >> would likely delay it and require supplementary work from the release >> managers. On the other hand, if your package has problems preventing >> it to migrate to testing, please fix them as soon as possible. You can >> probably find supplementary information in the debian-release archives >> or in the corresponding release.debian.org bug. The python3.8 transition is not a classical transition, so this normally helpful comment from tracker.d.o doesn't really apply. Please ignore it. If you would follow the link to the transition page, you would find a link to a transition bug (#942106) and it will explain (already in the title) that it is different from most transitions. (While writing this response I realize it may be possible for me to "hide" this info on the tracker, but I haven't done that before). > And I have this: > >> Not built on buildd: arch all binaries uploaded by enrico, a new >> source-only upload is needed to allow migration > > I was asked to do a binary upload to go through NEW, and now I'm asked > to do a source only upload to go to testing. There are surely good > reasons for that, and I wish there weren't. I agree with this. And from your phrasing your not really interested in the explanation, so find that at the bottom [1]. > I don't really have a new version to upload, but I suppose I need to at > least bump the debian version with no other changes in the package for > it to be accepted. Unfortunately, indeed. > Then, if I did that, would I be helping the python3.8 transition by > enabling a migration to testing, or getting in the way by delaying the > transition and requiring supplementary work from the release managers? As explained above, you'll not be interfering, so go ahead. > I feel a bit caught in a bureaucratic corner. Please help me with some > directions to get out of that. Hope this helps. Paul [1] Source packages that build binaries unknown to the archive currently need these binaries to be uploaded by the maintainers for reviewing by ftp-master in NEW. IIRC there have been multiple proposals to avoid these binaries from either being needed or being uploaded to the Debian archive, but so far the current tooling requires this. On the other hand, the release team has decided that we want all binaries in our releases to be build on buildd. For that we have enhanced our migration software to check for non-buildd uploads and add a block for them. Unfortunately, once uploaded we can't fix the situation for arch:all packages as binNMU'ing arch:all is currently broken. There is slow progress to improve that situation, see e.g. bug #916601. signature.asc Description: OpenPGP digital signature
Bug#947716: RFH: terminator -- multiple GNOME terminals in one window
Package: wnpp Severity: normal I request assistance with maintaining the terminator package. [1] The upstream seems pretty much dead, though I'd like the keep the package available. Popcon [2] is not too bad, and I think usage on Ubuntu is also pretty stable (I know a lot of people). The package doesn't have a lot todo, though we should look into some issues and I'd prefer not to work on it alone. Please contact me if you are interested, first step should be to have a look at the packaging, bugs and the patches I've revised for Python 3. Regards Markus The package description is: Terminator is a little project to produce an efficient way of filling a large area of screen space with terminals. . The user can have multiple terminals in one window and use key bindings to switch between them. See the manpage for details. [1] https://tracker.debian.org/pkg/terminator [2] https://qa.debian.org/popcon.php?package=terminator
Re: https://tracker.debian.org/pkg/dballe
On Sun, Dec 29, 2019 at 12:32:24PM +0100, Paul Gevers wrote: > > [1] Source packages that build binaries unknown to the archive currently > need these binaries to be uploaded by the maintainers for reviewing by > ftp-master in NEW. IIRC there have been multiple proposals to avoid > these binaries from either being needed or being uploaded to the Debian > archive, but so far the current tooling requires this. On the other > hand, the release team has decided that we want all binaries in our > releases to be build on buildd. For that we have enhanced our migration > software to check for non-buildd uploads and add a block for them. > Unfortunately, once uploaded we can't fix the situation for arch:all > packages as binNMU'ing arch:all is currently broken. There is slow > progress to improve that situation, see e.g. bug #916601. > I've encountered this issue myself in the past with a SONAME bump in a library package. It was rather surprising. Would it not be possible to eliminate the need for the second unnecessary upload by requiring two signed .changes files to go into NEW? A signed binary changes which would form the basis of the FTP master review and a signed source changes to enter the archive if the package is approved? When I build packages I always end up with both changes files, so requiring both for NEW processing would be a triviality (for me, at least) and eliminate this peculiarity as well. Regards, -Roberto -- Roberto C. Sánchez
Re: https://tracker.debian.org/pkg/dballe
On Sun, Dec 29, 2019 at 09:52:44AM +0100, Enrico Zini wrote: > Hello, > > some time ago I uploaded a new version of dballe, which went through NEW > because of a change in binary package names (SONAME bump, IIRC). It took > two weeks to go through NEW and I turned my energy towards other things > since then. Wow, two weeks? I uploaded a new version of f2fs-tools back in July, with the same issue (SONAME bump), and it's still not gotten through NEW. I had assumed everyone was waiting 5-6+ months to get through NEW - Ted
Re: https://tracker.debian.org/pkg/dballe
On Sun, Dec 29, 2019 at 12:32:24PM +0100, Paul Gevers wrote: > > Now I see that things got stuck for the transition to testing, and I'm > > asking for help figuring out what to do. > > I'm happy to help. Thanks! <3 > The python3.8 transition is not a classical transition, so this normally > helpful comment from tracker.d.o doesn't really apply. Please ignore it. Ack, wonderful. > As explained above, you'll not be interfering, so go ahead. Perfect, I have gone ahead with a new source-only upload. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Bug#947736: ITP: topline -- per-core/NUMA CPU and disk utilization plain-text grapher
Package: wnpp Severity: wishlist Owner: Adam Borowski * Package name: topline Version : 0.1 Upstream Author : yours truly * URL : https://github.com/kilobyte/topline * License : GPL-2+noA Programming Lang: C Description : per-core/NUMA CPU and disk utilization plain-text grapher This is a top-of-the-line logger of CPU usage patterns, designed for machines with ca. 50-300 total hardware threads (fewer results in a narrow graph, more requires a very wide terminal). Every per-tick sample is shown abusing Unicode characters to fit within a single line. . Disk usage is also shown in a similarly terse per-device way, as % utilization for reads and writes. Other similar tools: * htop: full-screen interactive * dstat: can't do more than a few CPUs * VTUNE: can't be used in CI/etc, proprietary, non-portable This is a simple tool, with nowhere as many features as the above, but it has its niche.
NEW processing time (Was: https://tracker.debian.org/pkg/dballe)
On 12/29/19 3:53 PM, Theodore Y. Ts'o wrote: > On Sun, Dec 29, 2019 at 09:52:44AM +0100, Enrico Zini wrote: >> some time ago I uploaded a new version of dballe, which went through NEW >> because of a change in binary package names (SONAME bump, IIRC). It took >> two weeks to go through NEW and I turned my energy towards other things >> since then. > > Wow, two weeks? I uploaded a new version of f2fs-tools back in July, > with the same issue (SONAME bump), and it's still not gotten through > NEW. > > I had assumed everyone was waiting 5-6+ months to get through NEW It seems to differ depending on the package. Every month the qgis package has to go through NEW due to SONAME bumps as well, and this is usually processed within a week or two. Possibly because the changes since the last time it was in NEW is limited. In March netcdf will be in NEW for a year, a number of subsequent upstream releases have accumulated there. I suspect this may be another case where the package got stuck an needs an intervention to get it acceptable again. Asking for explicit review of a package via email or IRC tends to work reasonably well. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: https://tracker.debian.org/pkg/dballe
On Sun, Dec 29, 2019 at 11:32 AM Paul Gevers wrote: > [1] Source packages that build binaries unknown to the archive currently > need these binaries to be uploaded by the maintainers for reviewing by > ftp-master in NEW. IIRC there have been multiple proposals to avoid > these binaries from either being needed or being uploaded to the Debian > archive, but so far the current tooling requires this. There has been some recent work on this part of the problem, I focussed on throwing away binaries for all sourceful uploads and ivodd focussed on doing that for NEW uploads only. Since ivodd's patch is further along than mine, I hope he will extend it to all sourceful uploads. https://lists.debian.org/msgid-search/5ec2e979cd7d7ec9bf386fbf77e3399c7aeeb473.ca...@debian.org https://salsa.debian.org/pabs/dak/commits/discard-binaries https://lists.debian.org/msgid-search/87sgm2lhwc@marvin.43-1.org https://lists.debian.org/msgid-search/de353950121612a86ca706cbdf36153b25b9fa36.ca...@debian.org https://lists.debian.org/msgid-search/27641434-e45a-404f-254f-daea89916...@debian.org https://salsa.debian.org/ivodd/dak/tree/new-throwaway-binary-v10 -- bye, pabs https://wiki.debian.org/PaulWise
Re: https://tracker.debian.org/pkg/dballe
On Sun, Dec 29, 2019 at 1:29 PM Roberto C. Sánchez wrote: > Would it not be possible to eliminate the need for the second > unnecessary upload by requiring two signed .changes files to go into > NEW? A signed binary changes which would form the basis of the FTP > master review and a signed source changes to enter the archive if the > package is approved? Another approach is to simply have dak discard binaries from all sourceful uploads (in dak parlance that means .changes files that have a .dsc) (and save them to an audit directory). The buildds currently only produce non-sourceful uploads so all their binaries get accepted fine. For bootstrap scenarios, maintainers can just do an additional binary-only upload. See the patches myself/ivodd posted recently for a work in progress on this. -- bye, pabs https://wiki.debian.org/PaulWise
Re: NEW processing time (Was: https://tracker.debian.org/pkg/dballe)
On Sun, Dec 29, 2019 at 10:51:36PM +0100, Sebastiaan Couwenberg wrote: > > Wow, two weeks? I uploaded a new version of f2fs-tools back in July, > > with the same issue (SONAME bump), and it's still not gotten through > > NEW. > > > > I had assumed everyone was waiting 5-6+ months to get through NEW > > It seems to differ depending on the package. Every month the qgis > package has to go through NEW due to SONAME bumps as well, and this is > usually processed within a week or two. Possibly because the changes > since the last time it was in NEW is limited. > > In March netcdf will be in NEW for a year, a number of subsequent > upstream releases have accumulated there. I suspect this may be another > case where the package got stuck an needs an intervention to get it > acceptable again. > > Asking for explicit review of a package via email or IRC tends to work > reasonably well. Thanks, I'll try that. I hadn't sent any e-mail pings because I didn't to nag what appeared to be a massively overloaded ftp-master team - Ted
