Re: Removing packages perhaps too aggressively?
On Sat, Feb 03, 2018 at 11:07:37PM +0100, Adam Borowski wrote: > On Sat, Feb 03, 2018 at 06:04:42PM +0100, Bernd Zeimetz wrote: > > and/or open an rc bug > > This sounds like an abuse to me. Why would it be? You're always allowed to open a bug with "serious" severity under the "in the opinion of the maintainer, this bug is problematic enough to warrant RC-ness" definition. I've occasionally used that to prevent a package of mine from migrating to testing for a few days, even though there wasn't anything RC-wrong with it as such. "I don't think this package is as useful anymore as it once was, and we should get rid of it" sounds like a perfectly valid use of the "serious" severity to me. -- Could you people please use IRC like normal people?!? -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008 Hacklab
Re: Removing packages perhaps too aggressively?
On Sat, Feb 03, 2018 at 01:25:14AM +0100, Adam Borowski wrote: > On Sat, Feb 03, 2018 at 12:39:57AM +0100, Wouter Verhelst wrote: > > On Fri, Feb 02, 2018 at 12:23:51AM +0100, Adam Borowski wrote: > > > If it's orphaned+RC-buggy but it Works For Me™, it's good to stay, right? > > > > This doesn't compute. > > > > A package can be orphaned and still perfectly functional; a package can > > be orphaned and RC-buggy. A package cannot, however, be RC-buggy and in > > a "still works" state. If it's genuinely RC buggy, then by definition it > > no longer works properly or it's causing problems. > > Copyright problems don't make the package any less useful. That would be the "causing problems" part. Legally we may not be able to redistribute it if there are copyright problems. > > If it's RC buggy because the environment changed and it's now holding > > back a transition or some such, then it's actively causing problems and > > should be fixed or removed. > > > If it's RC buggy because it broke and now crashes on startup, then it, > > well, broke and should be fixed or removed. > > What if it crashes on startup only with systemd? This currently means the > majority of users, but doesn't make the package any less useful for me. That sounds like an "important" bug to me, then. If the bug indeed does not occur with other init systems, that means the package is not totally useless. > > If it's RC buggy because someone had a bad case of "my use case is the > > most important one in the world and this package should be fixed NOW", > > then, well, fix the severity (it can be "important" without being RC > > buggy) and it can remain. > > What if it FTBFSes on s390x? What if it may cause serious data loss on ext2 > with a split /var setup? If the package is not likely to be useful on s390x, then ask for the removal of just the s390x binaries, and downgrade the bug severity. The other example seems somewhat contrived and unlikely; I doubt such things are actually a problem in practice. > > But if a package is RC buggy, then it is *broken*, and should either be > > removed or fixed. You don't need to take over maintenance of a package, > > but if you think it's important enough to be retained in the archive, > > ensuring that it at least doesn't have any RC bugs anymore shouldn't be > > too much to ask. If you can't do that, then it's perfectly normal for it > > to be removed. [limited time] I understand all that, and it does make sense. But Debian as a whole has a limited amount of time for everything, and it makes sense to not get distracted by things that nobody's interested in. If you care about an orphaned package, and there's an RC bug, it doesn't hurt you to say "I want to fix this bug so the package can migrate again, but I don't have the time right now". That should be enough to ensure people don't file removal bugs on it. Finally, a removal isn't a way of saying "this package has no purpose being in Debian". It's just a way of saying "we're sorry we couldn't fix this package, but it seems unlikely". If you care enough, you can always take the last version of the package, fix it, and reupload it. There's no real reason why it wouldn't get through NEW. -- Could you people please use IRC like normal people?!? -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008 Hacklab
Bug#889520: ITP: golang-github-disintegration-imaging -- Simple Go image processing package
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: golang-github-disintegration-imaging Version : 1.3.0-1 Upstream Author : Grigory Dryapak * URL : https://github.com/disintegration/imaging * License : Expat Programming Lang: Go Description : Simple Go image processing package Package imaging provides basic image manipulation functions (resize, rotate, flip, crop, etc.). This package is based on the standard Go image package and works best along with it. . Image manipulation functions provided by the package take any image type that implements image.Image interface as an input, and return a new image of *image.NRGBA type (32bit RGBA colors, not premultiplied by alpha). Reason for packaging: Needed by Hugo >= 0.32 for image processing.
Bug#889516: ITP: el-ixir -- two-player board game with randomness
Package: wnpp Severity: wishlist Owner: Adam Borowski * Package name: el-ixir Version : 3.0 Upstream Author : me * URL : https://github.com/kilobyte/el-ixir * License : GPL2+ Programming Lang: Pascal Description : two-player board game with randomness El-Ixir is a board game that has apparently been invented by Isoft in 1981, released as a booter floppy. This is a quite faithful remake, like the original using text-mode graphics. . Every turn, players are presented with four random squares they can place a block on. The object of the game is to connect as many blocks to the board's corners as you can, possibly “embracing” areas while doing so. Just a thingy I made in 1990. Probably a curses-like same-computer interface won't make it popular today, now that everyone expects to tap a phone even if the opponent sits next to you -- but there are stronger contenders for the title of the crappiest package in the archive. And those of us whose beards are grey enough know how to use a shared tmux for remote play.
Re: ITP: lsmount -- a simple formatter for /proc/mounts
Am 03.02.2018 um 18:03 schrieb Andreas Schwarz: > Package: wnpp > Severity: wishlist > Owner: Andreas Schwarz > > * Package name: lsmount > Version : 0.2.1 > Upstream Author : Andreas Schwarz > * URL : https://www.lsmount.org > * License : ISC > Programming Lang: C > Description : a simple formatter for /proc/mounts > > Since the advent of more and more pseudo-file systems the output of > mount became confusing and the information important for everyday life > was difficult to read out. Are you aware of findmnt? If not, please have a look if you are missing a feature. Adding it there would have the benefit that it is available to everyone (as u-i is Essential) -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Removing packages perhaps too aggressively?
On Sat, Feb 03, 2018 at 06:04:42PM +0100, Bernd Zeimetz wrote:
> We don't need yet another process, if you want to get rid of a package
> you can open an RFA bug or orphan it
Orphaned packages tend to be maintained better than many of those which have
an alleged maintainer. The O status shouldn't be taken as a step towards
removal.
Conversely, an active maintainer may have doubts wrt h{is,er} work is
actually of benefit to anyone.
> and/or open an rc bug
This sounds like an abuse to me.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀ The bill with 3 years prison for mentioning Polish concentration
⣾⠁⢰⠒⠀⣿⡁ camps is back. What about KL Warschau (operating until 1956)?
⢿⡄⠘⠷⠚⠋⠀ Zgoda? Łambinowice? Most ex-German KLs? If those were "soviet
⠈⠳⣄ puppets", Bereza Kartuska? Sikorski's camps in UK (thanks Brits!)?
Re: Removing packages perhaps too aggressively?
On Sat, Feb 03, 2018 at 02:01:38AM -0500, Scott Kitterman wrote: > On Saturday, February 03, 2018 08:20:02 AM Adrian Bunk wrote: > > Making RM requests as visible as orphaned packages > > (e.g. in a weekly debian-devel post) would help here. > > So your in favor of shaming DDs to improve their behavior? I can't speak as to Adrian's intent, but from my perspective it's not about shaming, but about awareness. On more than one occasion, packages that I use have (from my perspective) just disappeared from unstable without warning. After some investigation, I discover that they were removed months ago (with no RFH, RFA, or O bugs filed). Had I been aware of an issue prior to the packages being removed, there's a good chance I would have stepped up and either offered assistance or taken over maintenance (as circumstances dictated). I can't realistically follow every single package I use - the amount of email traffic would be unmanageable. But I read the WNPP email every single week and always consider if there's something I can/should act on. So while adding RMs to WNPP (or something similar) may not be the perfect solution, I think it would go a long way to solving this issue for a lot of people. Just my 2 cents. Bill
Re: Removing packages perhaps too aggressively?
On Fri, Feb 02, 2018 at 06:44:36PM +0200, Adrian Bunk wrote: > On Fri, Feb 02, 2018 at 02:29:49AM +, Colin Watson wrote: > > It'd probably make sense to use > > https://www.debian.org/Bugs/server-control#affects for this. > > How would that help? It would at least make it possible to see the pending action that's relevant to the package in its BTS view, even if you perhaps only see it too late. Better than nothing. Many times I've looked at bugs on a package that I'm trying to fix in passing, and not noticed that it had a removal bug either pending or recently processed. If the BTS doesn't have that metadata, it can't do anything useful with it. I think at the moment the "affects" field in a bug's metadata doesn't cause the maintainer of the affected packages to be copied on mail to the bug, but it could probably reasonably be changed to do so, eliminating the occasional problem where one of a package's maintainers doesn't even realise that the RM bug was filed because they weren't copied on it; again, only if the BTS has that metadata. -- Colin Watson [cjwat...@debian.org]
ITP: lsmount -- a simple formatter for /proc/mounts
Package: wnpp Severity: wishlist Owner: Andreas Schwarz * Package name: lsmount Version : 0.2.1 Upstream Author : Andreas Schwarz * URL : https://www.lsmount.org * License : ISC Programming Lang: C Description : a simple formatter for /proc/mounts Since the advent of more and more pseudo-file systems the output of mount became confusing and the information important for everyday life was difficult to read out. lsmount gives you a much more readable output of /proc/mounts with optional colorizing, alignment and more useful options. I plan to maintain the package myself with the help of a supporter. ISC license text Permission to use, copy, modify, and/or distribute this software for any purpose with or without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies. THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. signature.asc Description: OpenPGP digital signature
Re: Removing packages perhaps too aggressively?
On 02/01/2018 01:53 PM, Ian Jackson wrote:
> Scott Kitterman writes ("Re: Removing packages perhaps too aggressively?"):
>> As the FTP team member that processed that removal, I can tell you I think
>> it's perfectly fine. I don't think the FTP team should be in the business
>> of
>> second guessing maintainers that say their packages should be removed.
>
> I agree with your 2nd point but if we introduce an ITR process, then
> it would make sense for ftp team members to check that the process
> looked like it had been followed.
We don't need yet another process, if you want to get rid of a package
you can open an RFA bug or orphan it and/or open an rc bug, so it won't
be part of the next stable release unless somebody takes care of it.
And then ask for removal.
--
Bernd ZeimetzDebian GNU/Linux Developer
http://bzed.dehttp://www.debian.org
GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#889300: ITP: python-aiomeasures -- collect and send metrics to StatsD for Python
Package: wnpp Severity: wishlist Owner: Ondřej Nový * Package name: python-aiomeasures Version : 0.5.14 Upstream Author : Xavier Barbosa * URL : https://lab.errorist.xyz/abc/aiomeasures/ * License : Expat Programming Lang: Python Description : collect and send metrics to StatsD for Python This library allows you to send metrics to your Datadog or Statsd server. This works on Python >= 3.3 and relies on asyncio. I'm going to maintain it in DPMT.
Bug#889296: ITP: python-molotov -- Spiffy load testing tool in Python
Package: wnpp Severity: wishlist Owner: Ondřej Nový * Package name: python-molotov Version : 1.4 Upstream Author : Tarek Ziade * URL : https://pypi.python.org/pypi/molotov * License : Apache-2 Programming Lang: Python Description : Spiffy load testing tool in Python Simple Python 3.5+ tool to write load tests. Based on asyncio, Built with aiohttp. I'm going to maintain it in DPMT.
