maintainership of pv, status of kcoyner
http://packages.qa.debian.org/p/pv.html i love this tool. there's a bunch new releases sitting upstream that I'd be happy to package in debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745820 anyone heard of Kevin (in cc)? he seems to be MIA right now... i contacted the MIA team before, we'll see what happens there. i'd be happy to start maintaining pv if the MIA team decides to orphan the package. i'd probably throw this at collab-maint and everyone is welcome to join in, but it's such a small tool i don't see a team around it really. :) note that there are other packages to look at if kevin is indeed missing: http://qa.debian.org/developer.php?login=kcoy...@debian.org .. but must are fairly up to date right now. cheers, a. PS: Kevin, if you're reading this, I hope you are well and that I'm not stepping on any toes. :) -- Le Québec ne rêve plus de devenir une société modèle: voilà son problème d'environnement. - Pierre Dansereau (1911 - 2011) pgpS47lk95mxs.pgp Description: PGP signature
Bug#684440: ITP: horst -- small, lightweight IEEE802.11 wireless LAN analyzer with a text interface
Package: wnpp
Severity: wishlist
Owner: "Antoine Beaupré"
* Package name: horst
Version : 3.0
Upstream Author : Bruno Randolf
* URL : http://br1.einfach.org/tech/horst/
* License : GPL-2
Programming Lang: C
Description : small, lightweight IEEE802.11 wireless LAN analyzer with a
text interface
horst is a small, lightweight IEEE802.11 wireless LAN analyzer with a
text interface. Its basic function is similar to tcpdump, Wireshark
or Kismet, but it's much smaller and shows different, aggregated
information which is not easily available from other tools. It is
mainly targeted at debugging wireless LANs with a focus on ad-hoc
(IBSS) mode in larger mesh networks. It can be useful to get a quick
overview of what's going on on all wireless LAN channels and to
identify problems.
.
* Shows signal/noise values per station
* Calculates channel utilization ("usage") by adding up the amount
of time the packets actually occupy the medium
* "Spectrum Analyzer" shows signal levels and usage per channel
Graphical packet history, with signal/noise, packet type and physical
rate
* Shows all stations per ESSID and the live TSF per node as it is
counting
* Detects IBSS "splits" (same ESSID but different BSSID \u2013 this
is a common driver problem)
* Statistics of packets/bytes per physical rate and per packet type
* Has some support for mesh protocols (OLSR and batman)
* Can filter specific packet types source addresses or BSSIDs
* Client/server support for monitoring on remote nodes
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20120810024551.29365.45117.report...@marcos.anarcat.ath.cx
Bug#684549: ITP: pepper -- source code statistics reporting tool
Package: wnpp Severity: wishlist Owner: "Antoine Beaupré" * Package name: pepper Version : 0.3.2 Upstream Author : Jonas Gehring * URL : http://scm-pepper.sourceforge.net * License : GPL-3 Programming Lang: C++, Lua Description : source code statistics reporting tool pepper is a flexible command-line tool for retrieving statistics and generating reports from source code repositories. It ships with several graphical and textual reports, and is easily extendable using the Lua scripting language. pepper includes support for multiple version control systems, including Git and Subversion. Using native language bindings, multi-threading and a local revision cache, it provides fast access to repository data. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120811023829.14695.27931.report...@marcos.anarcat.ath.cx
status of eligibility of dug lists on lists.debian.org
Hi, We are in the process of kickstarting a Debian User Group (DUG), also known as a Local Group on the Debian wiki[1], in Montreal. We wish to unite the Debian Members that are in the city, but also interest the numerous free software enthusiasts in the Debian project. However, after digging through numerous documentation pages[2], it is now unclear to me that there is a concensus over the user of lists.debian.org for such local groups, even though the wiki page says otherwise. For example, the dug-muc (munich) request has been rejected[3] and the dug-nyc request seems to be on hold, mentionning that the proper place is on teams.debian.net[4]. There also seems to be a disagreement about how big a group should be to "desserve" a mailing list[3]. I think this is doing a disservice to our users. I can't imagine a user being able to go through all this trouble to setup tools for a local group. Even as a Debian Developer, I find the situation daunting, and I am not too eager to file a bug report only to be flamed for reporting issues[5]. So I request opinion from my fellow developers - what should a local group do to have discussions about their group? Should Debian infrastructure be available for this? If so, which? I see the following options: [ ] A: Do nothing, let them figure it out [ ] B: Host lists on lists.debian.org [ ] C: Host lists on teams.debian.org [ ] D: Host lists on alioth So far it seems that teams are setting up their own listservs in random places, but that seems to be like a patchwork solution: my opinion is that we should instead help our users with the resources at our dispoal. Thank you for your time and understanding, A. Notes: [1] http://wiki.debian.org/LocalGroups [2] http://www.debian.org/MailingLists and http://www.debian.org/MailingLists/HOWTO_start_list.en.html [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=687558 - although it seems the original requestor closed the bug himself... [4] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=454642 - also note that the above NYC request describes problems with archives and mail delivery on teams.debian.net [5] I find http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=687558#20 to be out of order and unnecessary. -- N'aimer qu'un seul est barbarie, car c'est au détriment de tous les autres. Fût-ce l'amour de Dieu. - Nietzsche, "Par delà le bien et le mal" pgpV3fL2FcOcO.pgp Description: PGP signature
Bug#719882: ITP: prosody-modules -- extension modules for Prosody
Package: wnpp Severity: wishlist Owner: "Antoine Beaupré" * Package name: prosody-modules Version : ? Upstream Author : Various (https://code.google.com/p/prosody-modules/people/list) * URL : https://code.google.com/p/prosody-modules/ * License : MIT/X Programming Lang: Lua Description : extension modules for Prosody Community repository for non-core, unofficial and/or experimental plugins for Prosody. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130816125902.14629.25189.report...@marcos.orangeseeds.org
Bug#644519: ITP: drush-make -- drupal source code deployment tool
Package: wnpp Severity: wishlist Owner: "Antoine Beaupré" * Package name: drush-make Version : 2.3 Upstream Author : Dmitri Gaskin * URL : https://drupal.org/project/drush_make * License : GPL2+ Programming Lang: PHP Description : drupal source code deployment tool Drush make is an extension to drush that can create a ready-to-use drupal site, pulling sources from various locations. It does this by parsing a flat text file (similar to a drupal .info file) and downloading the sources it describes. In practical terms, this means that it is possible to distribute a complicated Drupal distribution as a single text file. Among drush make's capabilities are: * Downloading Drupal core, as well as contrib modules from drupal.org. * Checking code out from CVS, SVN, git, and bzr repositories. * Getting plain .tar.gz and .zip files (particularly useful for libraries that can not be distributed directly with drupal core or modules). * Fetching and applying patches. * Fetching modules, themes, and installation profiles, but also external libraries. * Drush make does not turn modules on automatically: it only assembles Drupal directories -- it does not touch any database. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111006142955.1332.13607.report...@marcos.anarcat.ath.cx
Bug#645220: ITP: kedpm -- KED Password Manager
Package: wnpp Severity: wishlist Owner: "Antoine Beaupré" * Package name: kedpm Version : 0.5.0 Upstream Author : Andrey Lebedev * URL : https://redmine.koumbit.net/projects/kedpm * License : GPL-2+ Programming Lang: Python Description : KED Password Manager Ked Password Manager helps to manage large amounts of passwords and related information, and simplifies the tasks of searching and entering password data. . It is Figaro Password Manager compatible and can act as a near-complete replacement. . Ked Password Manager has a command line and gtk2 based user interfaces. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111013163906.24219.50288.report...@marcos.anarcat.ath.cx
Bug#645222: ITP: qwebirc -- fast and easy to use Web-based IRC client
Package: wnpp Severity: wishlist Owner: "Antoine Beaupré" * Package name: qwebirc Version : ?? Upstream Author : Chris Porter and the qwebirc project * URL : http://qwebirc.org/ * License : GPL-2, MIT, BSD, Public domain Programming Lang: Python, Java Description : fast and easy to use Web-based IRC client QwebIRC is the web client for the venerable and popular Quakenet IRC network. It features support for multiple channels and query windows, SSL support, asynchronous DNS and much more. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111013164448.26176.30750.report...@marcos.anarcat.ath.cx
Bug#645333: ITP: qthid-fcd-controller -- simple controller for the Funcube Dongle SDR
Package: wnpp Severity: wishlist Owner: "Antoine Beaupré" * Package name: qthid-fcd-controller Version : 3.1 Upstream Author : Alexandru Csete, OZ9AEC * URL : http://www.oz9aec.net/index.php/funcube-dongle/qthid-fcd-controller * License : GPL3 Programming Lang: C++ Description : simple controller for the Funcube Dongle SDR This is a simple cross platform controller application for the Funcube Dongle software defined radio (SDR) receiver. It provides full support for the Funcube Dongle API:: * Change frequency and apply frequency correction. * Change RF gains and filters. * Change IF gains and filters. * LNA enhancement, bias current, etc. * I/Q correction. * Auto-repeat tuning buttons (click and hold button to scan). * Variable frequency step. * Upgrade and verify the firmware. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111014150302.21343.34741.report...@marcos.anarcat.ath.cx
Bug#645521: ITP: owx -- utility to program Wouxun dual-band handheld radios
Package: wnpp Severity: wishlist Owner: "Antoine Beaupré" * Package name: owx Version : 20111015 Upstream Author : SP5GOF (Adam Wysocki) g...@chmurka.net * URL : http://owx.chmurka.net * License : dual: Apache 2.0, beerware Programming Lang: C++ Description : utility to program Wouxun dual-band handheld radios Open Wouxun (OWX) is a portable, open-source, command-line utility designed to program Wouxun dual-banders under any modern UNIX operating system. It supports KG-UV2D, KG-UVD1P and possibly other radios that identify as KG669V (such as Navcomm TK-890, Midland TK-790, Albrecht DB-270, Dynascan DB-48 and other brands). Utility has five functions. They are used to: - check radio connection - download binary data from radio - upload binary data to radio - export human-readable spreadsheet from binary data file - import edited spreadsheet into existing binary data file Binary data contains everything that can be changed in the radio - all settings, channels, current modes of operation etc. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111016155536.18761.21550.report...@marcos.anarcat.ath.cx
Bug#646607: ITP: atheme-services -- modular IRC services daemon
Package: wnpp Severity: wishlist Owner: "Antoine Beaupré" * Package name: atheme-services Version : 6.0.0 Upstream Author : William Pitcock and others * URL : http://www.atheme.net/ * License : GPL Programming Lang: C Description : modular IRC services daemon Atheme-services is a portable, secure set of open source, modular IRC services, designed to run on many IRC server implementations. Unlike alternative packages, atheme-services' core is minimalistic, providing only core functionality. atheme-services is a complete services set, excluding features designed for oper abuse. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111025162018.2549.33387.report...@marcos.anarcat.ath.cx
Bug#646776: ITP: kiwiirc -- Web based IRC client
Package: wnpp Severity: wishlist Owner: "Antoine Beaupré" * Package name: kiwiirc Version : 0~20111004 Upstream Author : Darren * URL : https://github.com/prawnsalad/KiwiIRC * License : AGPL Programming Lang: Javascript Description : Web based IRC client Kiwiirc is a web-based IRC client written in Node JS. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111027025703.26339.70540.report...@marcos.anarcat.ath.cx
Bug#649455: ITP: semanticscuttle -- Self-hosted and web-based social bookmark manager
Package: wnpp Severity: wishlist Owner: "Antoine Beaupré" * Package name: semanticscuttle Version : 0.98.3 Upstream Author : Christian Weiske , Benjamin Huynh-Kim-Bang , Eric Dane * URL : http://semanticscuttle.sourceforge.net/ * License : GPL Programming Lang: PHP Description : Self-hosted and web-based social bookmark manager SemanticScuttle is a social bookmarking tool experimenting with new features like structured tags and collaborative descriptions of tags. Originally a fork of Scuttle, it has overtaken its ancestor in stability, features and usability. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2021011829.2403.36792.report...@marcos.anarcat.ath.cx
Bug#652819: ITP: lico-update -- Machine update script for The New Linux Counter Project
Package: wnpp Severity: wishlist Owner: "Antoine Beaupré" * Package name: lico-update Version : 0.3.17 Upstream Author : Alexander Mieland (Leader and Manager of The New Linux Counter Project) * URL : https://linuxcounter.net/ * License : GPL-2 Programming Lang: sh Description : Machine update script for The New Linux Counter Project This is the official machine-update script for LiCo - The New Linux Counter Project. This is used to create a new machine or to update an existent machine in your LiCo account. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111220170129.25173.11536.report...@marcos.anarcat.ath.cx
Bug#707178: ITP: breakin -- stress-test and hardware diagnostics tool
Package: wnpp Severity: wishlist Owner: "Antoine Beaupré" * Package name: breakin Version : 3.20 Upstream Author : Jason D. Clinton , Kyle Sheumaker * URL : http://www.advancedclustering.com/software/breakin.html * License : GPL2 Programming Lang: C Description : stress-test and hardware diagnostics tool Breakin is Advanced Clustering's stress-test and hardware diagnostics tool. Advanced Clustering engineers developed breakin because no other available product — commercial or open source — could pinpoint hardware issues and component failures as well as they wanted. = Packaging notes = The software is split into two main parts: the "breakin" software, which is a fairly self-contained C program with affiliated scripts which runs on boot up, and the "bootimage" distribution, which is a custom Linux distribution that is built from the ground up. I believe that the "breakin" part should be made into a Debian package, and the "bootimage" part should be discarded or made into a "debirf" extension. The dependencies of breakin are unclear, but the bootimage build scripts build the following parts: anarcat@desktop006:bootimage$ ls srcctrl/ actdmidropbearhtoplvm2 parted syslinux wget afio e2fsprogs initfs mcelogpciutils tcpdump arecacli edac-utils ipmitoolmdadm rsync terminfo bonnie++ ethtool kernel mdinfoscreen udev breakin hddtemp links mstflint smartmontools udpcast busybox hpl lm-sensors numactl stream util-linux A lot of those are available in Debian already, except: actdmi arecacli breakin hpl initfs kernel mdinfo stream terminfo Specific assessment should be done on those dependencies. I am interested in packaging the "breakin" part, but my time is limited and would appreciate any help. I can sponsor a package too, and will try to inform upstream of our efforts. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130507225521.14563.888.report...@marcos.orangeseeds.org
Bug#737585: O: semanticscuttle -- Self-hosted and web-based social bookmark manager
Package: wnpp Severity: normal I intend to orphan the semanticscuttle package. The package description is: SemanticScuttle is a social bookmarking tool experimenting with new features like structured tags and collaborative descriptions of tags. Originally a fork of Scuttle, it has overtaken its ancestor in stability, features and usability. . * LDAP/Active Directory authentication * RSS feed support: global feed, user feeds, per-tag feeds, private feeds * Public and private bookmarks * Delicious and Browser bookmark import * Theming support * Firefox plugin I am not really using the Debian package for deployment anymore, and can therefore not really fix the release-critical bugs which affect the installs (#659390). I will probably switch to Zotero to manage my bookmarks anyways (#709925). If anyone wants to take over the package, I can provide some overview of the package, but, quite frankly, it's been so long since I touched it that I barely remember anything at all. ;) I'll try to update to the latest upstream at least. Sorry for the inconvenience. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140204023157.26565.62837.report...@marcos.anarc.at
Bug#771403: ITP: willie -- simple, lightweight, open source, easy-to-use IRC utility bot
Package: wnpp Severity: wishlist Owner: "Antoine Beaupré" * Package name: willie Version : 4.5.1 Upstream Author : Michael Yanovich, Edward Powell, Elad Alfassa... * URL : https://github.com/embolalia/willie * License : EFLv2 Programming Lang: Python Description : simple, lightweight, open source, easy-to-use IRC utility bot Upstream description: Willie is a simple, lightweight, open source, easy-to-use IRC utility bot, written in Python. It's designed to be easy to use, easy to run, and easy to make new features for. Willie comes with a ton of ready-made features for you to use. It can leave notes for people, give you reminders, check RSS feeds, and much more. Willie also comes with a fully-documented and easy-to-use API, so you can write your own features. There's also an easy tutorial you can follow along with, to help you learn. Developing for Willie is a great way to familiarize yourself with Python. It's easy to start, but there's no limit to the cool things you can do with it. I find the software interesting because it is a modern, elegantly designed yet minimal Python-based IRC bot. It compares favorably to the already packaged supybot: https://github.com/embolalia/willie/wiki/Comparison-to-other-bots I would be happy to have co-maintainers and I am unlikely to work on this in the very short term, but I will probably get around to work on this for $WORK eventually anyways, so this is an ITP. Note that Willie is a derivative of Phenny, which itself is a derivative of Jenni (or something like that). There are some optional Python dependencies for this bot, some of which are not packaged in Debian: https://github.com/embolalia/willie/wiki/System-Requirements Specifically, I couldn't find the praw package. But that's not a blocker since it's optional and only used for reddit. Otherwise the package seems pretty straightforward Python packaging with a daemon, which also has a systemd service file and an easy auto-configuration tool. The package would probably need to just create a user to sandbox the bot and tell the admin to run the config wizard and we'd be done with this package. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141129082632.25235.90987.report...@marcos.anarc.at
Re: Confusing our users - who is supporting LTS?
On 2018-10-26 10:26:09, Thadeu Lima de Souza Cascardo wrote: > On Wed, Oct 24, 2018 at 09:30:46AM +0800, Paul Wise wrote: >> On Wed, Oct 24, 2018 at 4:15 AM Sean Whitton wrote: >> > >> > On Tue 23 Oct 2018 at 05:06PM +0200, Markus Koschany wrote: >> > > >> > > In short: Make it very clear if you want to provide long-term support >> > > for your project. Talk to the LTS team in case you need help. Nobody is >> > > forced to do anything. >> > >> > This is a good idea, but ISTM the assumption should be that the >> > subproject does not participate unless it explicitly says that it does. >> >> This thread started because users have the opposite assumption. So I >> think it would be better to be explicit about support teams and >> timelines. >> >> -- >> bye, >> pabs >> >> https://wiki.debian.org/PaulWise >> > > I am guessing one of the other (incorrect) assumption users might make > is that the "LTS version" is preferred over other versions. That's how > LTS works for Linux and Ubuntu, for example. So, a user would rather > install Ubuntu 18.04 that is supported for 5 years than Ubuntu 18.10, > that is supported for 9 months. The same happens with Linux 4.14 versus > Linux 4.18. I agree that is a concern... > I am not sure it's clear to users that all Debian stable versions would > have Long Term Support, because the releases are not *labeled* as LTS. I > know the wiki says: > > "Debian Long Term Support (LTS) is a project to extend the lifetime of > *all* Debian stable releases to (at least) 5 years." (emphasis mine) > > But I believe the table right below that would still confuse some users > that would understand that Jessie is supported by LTS, while Stretch is > not, even though there is a schedule column there. ... but, well, that is pretty clear isn't it? "All" releases are supported, and "stretch" is explicitely mentioned in the table. I think we've done our part. > Using the LTS term in a slightly different way than the "industry > standard" now means we need to spend a little more effort on users > education. I'm not sure we're using it that differently. But it's true normal stable releases don't immediately get marked as LTS. There are good reasons for that, and those would be very hard to work around. To get more explicit, we can answer your questions one by one: > Should we: > > 1) Start calling the stable releases as LTS releases? No. That would be very confusing, as the stable releases are (to simplify greatly) under the responsability of the security team (ST) and the stable release managers (SRM), not the LTS team. > 2) Say "supported by Security team" versus "supported by Freexian", > instead of just saying "supported by LTS"? Hm... I'm not sure what that refers to or what you're proposing, but LTS releases are *not* supported by the security team, but by the LTS team. > 3) Stop using LTS as a "label" for oldstable releases? I am not sure how that would help anything. :) I do like, however, the idea brought by Jeremy Stanley in a reply to your email of using the "Extended Maintenance" label instead of "Long Term Support" because the latter is usually attached to a *current* release, while the former is seen as an *extension*. But renaming the project seems like a huge undertaking and I'm not sure it would really resolve this conendrum. > 4) Just advise users all the time that they should prefer the latest > stable release, as that is going to have the "latest term support"? Right. So maybe that's a piece that's been missing in our communications, and that could be the reason why people still think they should install jessie cloud images. ;) So maybe we could make some proeminent statement on the LTS and LTS/Using pages in the wiki? > 5) Is that not true anymore with Extended LTS and CIP? Sorry, what is not true? #4? If so, I think people should *still* install the latest supported Debian release (stable or stretch right now) and not LTS or ELTS, when deploying new systems. I think the idea here is that we think Debian rocks. It's solid, stable, and we love it. But we want to support it for even longer than what our volunteer team can deal with right now, so we're hiring a bunch of dedicated fanatics who can figure out how to fit a square peg in a round hole for you. But please don't make us any more square pegs and install Debian normally. Don't break Debian! :) https://wiki.debian.org/DontBreakDebian Thanks! A. -- Work expands so as to fill the time available for its completion. - Parkinson's law
Re: Confusing our users - who is supporting LTS?
On 2018-10-26 13:02:57, Thadeu Lima de Souza Cascardo wrote: >> > 5) Is that not true anymore with Extended LTS and CIP? >> >> Sorry, what is not true? #4? If so, I think people should *still* >> install the latest supported Debian release (stable or stretch right >> now) and not LTS or ELTS, when deploying new systems. > > Yeah, not true that Stretch would have a latest term support compared to > any earlier release. So, if one needs something that lasts 12 years, > should one be picking up Stretch, Jessie or Wheezy? "12 years" ... it depends when you start counting. Do you count from the release date of the software? Or "now"? Because if you want 12 years support, jessie, even less so wheezy is not going to help you. >From that perspective, you might stand a better chance of installing *unstable* or *buster* right now if you want the longer support schedule from *right now* because then you'll get the buster release cycle (three years, starting from late 2019 if not 2020), then LTS (two years) and maybe even an extra ELTS (a year or more) slapped on top, which will bring you somewhere somewhere close to 2027. That's 9 years from now, a far cry from your 12 years objective, but it's pretty much the best shot we have. 12-year support cycle is the crazy stuff they do at Solaris, or at least did. Since Oracle bought it, they bumped that up to *twenty* years: https://en.wikipedia.org/wiki/Solaris_(operating_system)#Version_history We're still far away from that goal. And keep in mind the Solaris that is supported there is a very limited operating system when compared with the scope of packages supported in Debian... A. -- La seule excuse de Dieu, c'est qu'il n'existe pas. - Stendhal
Re: Bug#909550: possible conflict over the /usr/bin/ia namespace
On 2018-12-15 09:41:50, Chris Lamb wrote: > [Adding ftpmas...@debian.org to CC] > > Hi Antoine et al., > >> So anyways - irl will upload a new package now, presumably -2 or more, >> so i think << 0.242+git20151019-2~ is fine. > > I just went to process this package in NEW but this new upload does > not appear to have happened yet. Is that correct? You mean the NEW upload or the duckduckgo one? >From what I can tell, both were: https://tracker.debian.org/news/989684/accepted-python-duckduckgo2-0242git20151019-2-source-amd64-into-unstable/ https://ftp-master.debian.org/new/python-internetarchive_1.8.1-1.html Did I miss something? Thanks for looking into this! A. -- Gods don't like people not doing much work. People who aren't busy all the time might start to think. - Terry Pratchett, Small Gods
Re: Bug#909550: possible conflict over the /usr/bin/ia namespace
On 2018-12-15 22:25:58, Chris Lamb wrote: > Antoine Beaupré wrote: > >> >From what I can tell, both were: >> >> https://tracker.debian.org/news/989684/accepted-python-duckduckgo2-0242git20151019-2-source-amd64-into-unstable/ > > Neat, thanks. I've just processed python-internetarchive 1.8.1-1 in > NEW. Thanks!! -- Un éducateur dans l'âme ne prend rien au sérieux que par rapport à ses disciples -- soi-même non excepté. - Nietzsche, "Par delà le bien et le mal"
Bug#919936: ITP: golang-github-apparentlymart-go-openvpn-mgmt -- [WIP] Go client library for OpenVPN's management protocol
Package: wnpp Severity: wishlist Owner: Antoine Beaupré * Package name: golang-github-apparentlymart-go-openvpn-mgmt Version : 0.0~git20161009.9a305ae-1 Upstream Author : Martin Atkins * URL : https://github.com/apparentlymart/go-openvpn-mgmt * License : MIT Programming Lang: Go Description : Go client library for OpenVPN's management protocol Go package that implements a client for the OpenVPN management interface. This can be used to monitor and control an OpenVPN process running with its management port enabled. . Currently only a subset of the protocol is supported, primarily focused on monitoring status changes and cleanly shutting down or restarting connections. This is a dependency for the package riseupvpn which is also being package. signature.asc Description: PGP signature
Bug#919938: ITP: golang-github-getlantern-context --
Package: wnpp Severity: wishlist Owner: Antoine Beaupré * Package name: golang-github-getlantern-context Version : 0.0~git20190109.c447772-1 Upstream Author : Lantern * URL : https://github.com/getlantern/context * License : Apache-2.0 Programming Lang: Go Description : goroutine-based context state Provides goroutine-based context state inspired by https://github.com/tylerb/gls and https://github.com/jtolds/gls. It uses the same basic hack as tylerb's library, but adds a stack abstraction that allows nested contexts similar to jtolds' library, but using Enter() and Exit() instead of callback functions. -- This is a dependency of riseup-vpn, #919937. signature.asc Description: PGP signature
Bug#919941: ITP: golang-github-getlantern-golog -- Really basic (dumb really) logging mostly for flashlight
Package: wnpp Severity: wishlist Owner: Antoine Beaupré * Package name: golang-github-getlantern-golog Version : 0.0~git20170508.cca714f-1 Upstream Author : Lantern * URL : https://github.com/getlantern/golog * License : Apache-2.0 Programming Lang: Go Description : Really basic (dumb really) logging mostly for flashlight Provides logging used in many getlantern components. -- This is a dependency of the riseup VPN, see #919937. signature.asc Description: PGP signature
Bug#919944: ITP: golang-github-getlantern-context --
Package: wnpp Severity: wishlist Owner: Antoine Beaupré * Package name: golang-github-getlantern-errors Version : N/A Upstream Author : Lantern * URL : https://github.com/getlantern/errors * License : ? Programming Lang: Go Description : Structured errors for Go Dependency for riseup-vpn, #919937. License unclear, asked for clarification in: https://github.com/getlantern/errors/issues/4 signature.asc Description: PGP signature
Bug#919945: ITP: golang-github-getlantern-hex --
Package: wnpp Severity: wishlist Owner: Antoine Beaupré * Package name: golang-github-getlantern-hex Version : N/A Upstream Author : Lantern * URL : https://github.com/getlantern/hex * License : "BSD-style" Programming Lang: Go Description : Configurable hex encoding Dependency for riseup-vpn, #919937. The license isn't quite clear, clarification requested at: https://github.com/getlantern/hex/issues/1 signature.asc Description: PGP signature
Bug#919946: ITP: golang-github-getlantern-hidden
Package: wnpp Severity: wishlist Owner: Antoine Beaupré * Package name: golang-github-getlantern-hidden Version : N/A Upstream Author : Lantern * URL : https://github.com/getlantern/hidden * License : ? Programming Lang: Go Description : Hide text in text Dependency of riseup-vpn: #919937 Copyright unclear, asked for clarification: https://github.com/getlantern/hidden/issues/1 signature.asc Description: PGP signature
Bug#919948: ITP: golang-github-jmshal-go-locale
Package: wnpp Severity: wishlist Owner: Antoine Beaupré * Package name: golang-github-jmshal-go-locale Version : N/A Upstream Author : ? * URL : https://github.com/jmshal/go-locale * License : ? Programming Lang: Go Description : User locale detection for Go Dependency of riseup-vpn, #919937 Unclear license: https://github.com/jmshal/go-locale/issues/3 signature.asc Description: PGP signature
Bug#919947: ITP: golang-github-getlantern-ops
Package: wnpp Severity: wishlist Owner: Antoine Beaupré * Package name: golang-github-getlantern-ops Version : N/A Upstream Author : Lantern * URL : https://github.com/getlantern/ops * License : ? Programming Lang: Go Description : Track success or failure of operations in code Dependency of riseup-vpn, #919937 Unclear license, https://github.com/getlantern/ops/issues/2 signature.asc Description: PGP signature
Bug#920387: ITP: golang-github-proglottis-gpgme -- Go wrapper for the GPGME library
Package: wnpp Severity: wishlist Owner: Antoine Beaupré * Package name: golang-github-proglottis-gpgme Version : 0.0~git20181127.3b0be09-1 Upstream Author : James Fargher * URL : https://github.com/proglottis/gpgme * License : BSD-3-clause Programming Lang: Go Description : Go wrapper for the GPGME library GPGME (golang) Go wrapper for the GPGME library. . This library is intended for use with desktop applications. If you are looking to add OpenPGP support to a server application I suggest you first look at golang.org/x/crypto/openpgp (https://godoc.org/golang.org/x/crypto/openpgp). Installationgo get -u github.com/proglottis/gpgme Documentation• godoc (https://godoc.org/github.com/proglottis/gpgme) Dependency for #920385. signature.asc Description: PGP signature
Bug#920388: ITP: golang-github-keltia-archive -- Small Go library for handling archives of various types.
Package: wnpp Severity: wishlist Owner: Antoine Beaupré * Package name: golang-github-keltia-archive Version : 0.3.3-1 Upstream Author : Ollivier Robert * URL : https://github.com/keltia/archive * License : BSD-3-clause Programming Lang: Go Description : Small Go library for handling archives of various types. -- Dependency for #920385. signature.asc Description: PGP signature
Bug#920389: ITP: golang-github-intel-tfortools -- template scripting support to go programs
Package: wnpp
Severity: wishlist
Owner: Antoine Beaupré
* Package name: golang-github-intel-tfortools
Version : 0.2.0+git20180102.ec3334c-1
Upstream Author : Intel Corporation
* URL : https://github.com/intel/tfortools
* License : Apache-2.0
Programming Lang: Go
Description : template scripting support to go programs
Package tfortools provides a set of functions that are designed to make
it easier for developers to add template based scripting to their command
line tools.
.
Command line tools written in Go often allow users to specify a template
script to tailor the output of the tool to their specific needs. This can
be useful both when visually inspecting the data and also when invoking
command line tools in scripts. The best example of this is go list which
allows users to pass a template script to extract interesting information
about Go packages. For example,
.
.
go list -f '{{range .Imports}}{{println .}}{{end}}'
.
.
prints all the imports of the current package.
.
The aim of this package is to make it easier for developers to add
template scripting support to their tools and easier for users of
these tools to extract the information they need. It does this by
augmenting the templating language provided by the standard library
package text/template in two ways: • It auto generates descriptions of
the data structures passed as input to a template script for use in help
messages. This ensures that help usage information is always up to date
with the source code.• It provides a suite of convenience functions to
make it easy for script writers to extract the data they need. There are
functions for sorting, selecting rows and columns and generating nicely
formatted tables. For example, if a program passed a slice of structs
containing stock data to a template script, we could use the following
script to extract the names of the 3 stocks with the highest trade volume.
.
.
{{table (cols (head (sort . "Volume" "dsc") 3) "Name" "Volume")}}
.
.
The output might look something like this:
.
.
Name Volume Happy Enterprises 6395624278 Big Company
750 Medium Company300122
.
.
The functions head, sort, tables and col are provided by this package.
--
Dependency for #920385.
signature.asc
Description: PGP signature
Bug#920390: ITP: golang-github-ivpusic-grpool -- Lightweight Goroutine pool
Package: wnpp Severity: wishlist Owner: Antoine Beaupré * Package name: golang-github-ivpusic-grpool Version : 0.0~git20170804.28957a2-1 Upstream Author : Ivan Pusic * URL : https://github.com/ivpusic/grpool * License : MIT Programming Lang: Go Description : Lightweight Goroutine pool Clients can submit jobs. Dispatcher takes job, and sends it to first available worker. When worker is done with processing job, will be returned back to worker pool. . Number of workers and Job queue size is configurable. Dependency for #920385. signature.asc Description: PGP signature
Bug#921276: ITP: gotop -- A terminal based graphical activity monitor inspired by gtop and vtop
Package: wnpp Severity: wishlist Owner: Antoine Beaupré * Package name: gotop Version : 2.0.0-1 Upstream Author : Caleb Bassi * URL : https://github.com/cjbassi/gotop * License : AGPL-3.0 Programming Lang: Go Description : A terminal based graphical activity monitor inspired by gtop and vtop This is another terminal based graphical activity monitor, inspired by gtop and vtop, this time written in Golang. It shows CPU/Disk/Memory/Network usage and process lists in a user-friendly interface, with historical graphs. -- This is a really neat little package, I am not aware of something that would show memory usage over time in a terminal graph like this currently in Debian. Correct my if I'm wrong. dh-make-golang has this estimate: $ dh-make-golang estimate github.com/cjbassi/gotop 2019/02/03 15:55:45 Bringing github.com/cjbassi/gotop to Debian requires packaging the following Go packages: github.com/cjbassi/gotop github.com/docopt/docopt.go github.com/gizak/termui github.com/cjbassi/drawille-go github.com/distatus/battery github.com/ProtonMail/go-appdir So it will require a few deps to be bundled, but those look useful in themselves as well. Will package this as part of the golang team, as usual. signature.asc Description: PGP signature
Bug#921285: ITP: golang-github-cjbassi-drawille-go -- Pixel graphics in terminal with unicode braille characters (golang)
Package: wnpp Severity: wishlist Owner: Antoine Beaupré * Package name: golang-github-cjbassi-drawille-go Version : 0.0~git20190126.27dc511-1 Upstream Author : Caleb Bassi * URL : https://github.com/cjbassi/drawille-go * License : MIT/Expat? Programming Lang: Go Description : Pixel graphics in terminal with unicode braille characters (golang) A drawille implementation in Go with a more permissive license. -- Dependency for gotop (#921276) Asked for tagged releases in https://github.com/cjbassi/drawille-go/issues/1 signature.asc Description: PGP signature
Bug#921286: ITP: termui -- Golang terminal dashboard
Package: wnpp Severity: wishlist Owner: Antoine Beaupré * Package name: termui Version : 2.3.0-1 Upstream Author : Zack Guo * URL : https://github.com/gizak/termui * License : MIT/Expat? Programming Lang: Go Description : Golang terminal dashboard termui is a cross-platform and fully-customizable terminal dashboard and widget library built on top of termbox-go. It is inspired by blessed-contrib and tui-rs and written purely in Go. Features * Built in widget implementations for common use cases * Utilities to create custom widgets * A grid layout for relative widget positioning * Mouse support * Event handling for keyboard, mouse and resizing events * Colors and styling -- Dependency for gotop. signature.asc Description: PGP signature
Bug#921288: ITP: golang-github-protonmail-go-appdir -- Minimalistic Go package to get application directories such as config and cache
Package: wnpp Severity: wishlist Owner: Antoine Beaupré * Package name: golang-github-protonmail-go-appdir Version : 0.0~git20190108.8d7e66f-1 Upstream Author : * URL : https://github.com/ProtonMail/go-appdir * License : MIT/Expat? Programming Lang: Go Description : Minimalistic Go package to get application directories such as config and cache Minimalistic Go package to get application directories such as config and cache. gotop dependency. asked for releases in https://github.com/ProtonMail/go-appdir/issues/3 signature.asc Description: PGP signature
Bug#921287: ITP: battery -- cross-platform, normalized battery information library
Package: wnpp Severity: wishlist Owner: Antoine Beaupré * Package name: battery Version : 0.0~git20170521.916919e-1 Upstream Author : * URL : https://github.com/distatus/battery * License : Expat? Programming Lang: Go Description : cross-platform, normalized battery information library Gives access to a system independent, typed battery state, capacity, charge and voltage values recalculated as necessary to be returned in mW, mWh or V units. -- gotop dependency. asked for releases in https://github.com/distatus/battery/issues/9 signature.asc Description: PGP signature
Bug#922628: ITP: dt -- DNS tool - display information about your domain
Package: wnpp Severity: wishlist Owner: Antoine Beaupré * Package name: dt Version : 0.0.9 Upstream Author : Wim * URL : https://github.com/42wim/dt * License : Apache-2.0 Programming Lang: Go Description : DNS tool - display information about your domain dt a DNS tool that displays information about your domain. . Features • common records scanning (use -scan) • validate DNSSEC chain (use -debug to see more info) • change query speed for scanning (default 10 queries per second) * diagnostic of your domain (similar to intodns.com, dnsspy.io) This is a great tool. I worked on packaging a similar tool (dnsdiag, #824670) for Debian, but it stopped where dt begun: https://github.com/farrokhi/dnsdiag/issues/16 So I would love to see this in Debian. As usual, I would co-maintain this in the golang team. signature.asc Description: PGP signature
Bug#922629: ITP: golang-github-ammario-ipisp -- Golang IP to ISP library utilizing team cymru's IP to ASN service
Package: wnpp Severity: wishlist Owner: Antoine Beaupré * Package name: golang-github-ammario-ipisp Version : 0.0~git20181009.77157c3-1 Upstream Author : Ammar Bandukwala * URL : https://github.com/ammario/ipisp * License : Expat/MIT? Programming Lang: Go Description : Golang IP to ISP library utilizing team cymru's IP to ASN service IPISP IPISP provides a Go client for Team Cymru's (http://www.team-cymru.org/IP-ASN-mapping.html) ASN resolution service. . Features - Programmatically resolve IP addresses or ASNs to network information. - Allows bulk conversion. - DNS and Netcat/Whois client. - Thread-safe. -- ipisp is a dependency of the dt (#922628). It has no official releases: https://github.com/ammario/ipisp/issues/16 ... and dt itself uses its own for of ipisp, which should be fixed: https://github.com/42wim/ipisp signature.asc Description: PGP signature
Bug#922631: ITP: golang-github-briandowns-spinner -- Go (golang) package for providing a terminal spinner/progress indicator with options.
Package: wnpp Severity: wishlist Owner: Antoine Beaupré * Package name: golang-github-briandowns-spinner Version : 1.4 Upstream Author : Brian Downs * URL : https://github.com/briandowns/spinner * License : Apache-2.0 Programming Lang: Go Description : terminal spinner/progress indicator with options spinner is a simple package to add a spinner / progress indicator to any terminal application. Examples can be found below as well as full examples in the examples directory. -- This is a dependency for dt (#922628). Unfortunately, there are already *two* existing spinner packages in golang: https://tracker.debian.org/pkg/golang-github-tj-go-spin https://tracker.debian.org/pkg/golang-github-odeke-em-cli-spinner Brian Downs' implementation is much more featureful, however, so I think it might be reasonable to add it to Debian even though it duplicates the above packages. (I *would* question, however, the reasoning behind having the above *two* packages because *those* are almost identical in functionality...) signature.asc Description: PGP signature
Re: Bug#922628: ITP: dt -- DNS tool - display information about your domain
[re-adding debian-devel to avoid further duplicates...] On 2019-02-19 03:11:47, Ben Hutchings wrote: > This command name is very short, and in fact we already have a dt > command (in the ditrack package). I suggest you try to convince > upstream to pick a unique command name. ... so for the third time today: now, I know about ditrack, thanks! :) There were options proposed in the bug, I'm hesitating between asking upstream to change its name (generally not well received) or renaming ditrack, which has a low popcon and no upstream release in a decade. A. -- We must learn to live together as brothers or perish together as fools. - Martin Luther King, Jr.
Bug#1034360: ITP: supersonic -- A lightweight cross-platform desktop client for Subsonic music servers
Package: wnpp Severity: wishlist Owner: Antoine Beaupré * Package name: supersonic Version : 0.1.0~beta-1 Upstream Author : Drew Weymouth * URL : https://github.com/dweymouth/supersonic * License : GPL-3.0 Programming Lang: Go Description : A lightweight cross-platform desktop client for Subsonic music servers A lightweight cross-platform desktop client for Subsonic music servers (Navidrome, Gonic, Airsonic, etc). Features * Fast, lightweight, native UI * High-quality gapless audio playback powered by MPV, with optional audio exclusive mode * ReplayGain support (depends on files being tagged on server) * Infinite scrolling * Scrobble plays to server, with configurable criteria * Browse by albums, artists, genres, playlists * Album and playlist views with tracklist and cover image * Artist view with biography, image, similar artists, and discography * Create, play, and update playlists * Configure visible tracklist columns * Set/unset favorite and browse by favorite albums, artists, and songs * View and edit play queue (add and remove tracks; reorder support coming soon) * Shuffle and repeat playback modes (partial; shuffle album, playlist, artist radio, random songs) We already have a Subsonic client in Debian (sublime-music, Python), packaged by my friend pollo. But in my experience, sublime is really slow and clunky, so much that it barely works at all. In comparison, Supersonic is, well, supersonic! I've tested the git build and it just works flawlessly, really impressive stuff. There's a handful of limitations though: * Set filters in albums browsing view (planned) * Browse by folders (planned) * Multi-server support (planned) * Download songs, albums or playlists (planned) * Cast to uPnP/DLNA devices (likely planned) * Built-in multi-band equalizer (eventully planned) * Offline mode (eventually planned) * Lyrics support (eventually planned) * iOS/Android support (maybe eventually planned) The "download" part is probably the most important part for me, but for now I can actually live without it... Dependency-wise, however, it's another story altogether. Supersonic is built with a GUI framework called Fyne which is, as far as I know, not at all packaged in Debian and *that* is quite a chunk of stuff to package: https://github.com/fyne-io/fyne/blob/master/go.mod I count 20+ deps there that need to at least be checked to see if they're in Debian. Faithful to itself, dh-make-golang crashes on estimate, so it's unclear to me how easy packaging that would be. Other than Fyne, it looks like the following packages are also missing: * github.com/20after4/configdir * github.com/dweymouth/go-mpv * github.com/dweymouth/go-subsonic The latter two being libraries made by the same author, presumably specifically for Supersonic, but that could possibly be used by other packages of course... The first one is kind of odd. There's another configdir package in Debian (https://github.com/shibukawa/configdir) and it *looks* kind of similar if you squinte a little, but their git history doesn't seem related as far as GitHub is concerned. 20after4/configdir is also a fork of kirsle/configdir, also unrelated. It looks like two similar implementations (complete with the same filename) but with completely different *actual* implementation. Epic. Anyway, not even close to being packaged, but I thought I'd throw this one out there.
Bug#1064925: ITP: fail2ban-prometheus-exporter - collect and export Prometheus metrics on Fail2Ban
Package: wnpp
Severity: wishlist
Owner: Antoine Beaupré
Reasoning: I need this! :) I could have written a mtail parser instead, but
/fail2ban.actions\s+\[\d+\]:\s+\w+\s+\[(?P)\] (?PBan|Unban)\s+/ {
fail2ban_action_count[$jail][$action]++
/fail2ban.filter\s+\[\d+\]:\s+\w+\s+\[(?P)\] (?PFound)\s+/ {
fail2ban_filter_count[$jail][$action]++
* Package name: fail2ban-prometheus-exporter
Version : 0.10.1-1
Upstream Author : hectorjsmith
* URL : https://gitlab.com/hectorjsmith/fail2ban-prometheus-exporter
* License : MIT
Programming Lang: Go
Description : collect and export Prometheus metrics on fail2ban
This Prometheus exporter provides Prometheus (or OpenMetrics) metrics
for the fail2ban package. It tracks the number of IPs currently
blocked, matched, how long they are tracked, and keeps track of
errors.
It parses data from the fail2ban socket and can export metrics over a
normal HTTP service or the text file collector.
halfway through doing that, I wondered "surely someone must have fixed that
already", and lo and behold.
A mtail equivalent might be:
# fail2ban log parser
#
# log lines:
#
# 2024-02-17 15:30:53,167 fail2ban.filter [578]: INFO
[fraud-donation-spam] Found 185.92.25.49 - 2024-02-17 15:30:52
# 2024-02-17 15:30:53,542 fail2ban.actions[578]: NOTICE
[fraud-donation-spam] Ban 185.92.25.49
# 2024-02-24 15:30:45,200 fail2ban.actions[578]: NOTICE
[fraud-donation-spam] Unban 91.230.225.115
counter fail2ban_action_count by jail, action
}
}
but is not quite as accurate, because it tracks bans/unbans
independently, and doesn't reflect the actual state of the system
properly.
Autocrypt: addr=anar...@debian.org; prefer-encrypt=nopreference;
keydata=xjMEZHZPzhYJKwYBBAHaRw8BAQdAWdVzOFRW6FYVpeVaDo3sC4aJ2kUW4ukdEZ36UJLAHd7NJUFudG9pbmUgQmVhdXByw6kgPGFuYXJjYXRAZGViaWFuLm9yZz7ClgQTFggAPhYhBLu2zUyY104TWKdSpgIpOm+k5TRzBQJkdmCVAhsDBQkB4TOABQsJCAcDBRUKCQgLBRYCAwEAAh4BAheAAAoJEAIpOm+k5TRz+w8BANbRA+AMH0LN7trugVhaWe4wDpg94UVJloHPL+adJMK/AQCh39hyQXk3ivS2cK7xKZUgK0dBsbtJ2I2XBXvL9dS3Cc44BGR2UM4SCisGAQQBl1UBBQEBB0CYZha2IMY54WFXMG4S9/Smef54Pgon99LJ/hJ885p0ZAMBCAfCdwQYFggAIBYhBLu2zUyY104TWKdSpgIpOm+k5TRzBQJkdlDOAhsMAAoJEAIpOm+k5TRzBg0A+IbcsZhLx6FRIqBJCdfYMo7qovEo+vX0HZsUPRlq4HkBAIctCzmH3WyfOD/aUTeOF3tY+tIGUxxjQLGsNQZeGrQI
Date: Tue, 27 Feb 2024 14:34:11 -0500
Message-ID: <87msrl3dn0@angela.anarc.at>
Bug#1066893: RFP: vale -- :pencil: A markup-aware linter for prose built with speed and extensibility in mind.
Package: wnpp Severity: wishlist Owner: Antoine Beaupré * Package name: vale Version : 3.0.0-1 Upstream Author : errata.ai * URL : https://github.com/errata-ai/vale * License : Expat Programming Lang: Go Description : A markup-aware linter for prose built with speed and extensibility in mind. Vale is a command-line tool that brings code-like linting to prose. It's fast, cross-platform (Windows, macOS, and Linux), and highly customizable. Key Features Support for markup: Vale has a rich understanding of many markup formats, allowing it to avoid syntax-related false positives and intelligently exclude code snippets from prose-related rules. A highly customizable extension system: Vale is capable of enforcing your style—be it a standard editorial style guide or a custom in-house set of rules (such as those created by GitLab, Homebrew, Linode, CockroachDB, and Spotify). Easy-to-install, stand-alone binaries: Unlike other tools, Vale doesn't require you to install and configure a particular programming language and its related tooling (such as Python/pip or Node.js/npm). There are a handful of spell-checkers and linters for prose in Debian, but vale is a little different. It's not *only* a spellchecker and does *other* things like checking for styles or allow for extensibility. Similar software include diction(1) and markdownlint, where diction is *really* old (e.g. doesn't know about markdown) and mdl is not very customizable (e.g. it's hard, in my experience to add words to a dictionary). So I'm considering vale instead. -- We must learn to live together as brothers or perish together as fools. - Martin Luther King, Jr.
Re: Bug#1001903: ITP: loki-database -- Like Prometheus, but for logs.
On 2021-12-19 07:30:57, Paul Wise wrote:
> On Sat, 2021-12-18 at 12:20 -0500, Sean Anderson wrote:
>
>> The upstream package name conflicts with the existing package loki
>> ("MCMC linkage analysis on general pedigrees"). However, that package is
>> "dead upstream" (according to debian/watch), so perhaps this package can
>> get the name eventually. Name suggestions are appreciated.
>
> Since Loki is a relatively generic name used for many different things,
> personally I think no one package should use the unqualified name. For
> example the Loki C++ library distinguishes itself as loki-lib. The name
> loki-database seems a good choice for the software you are packaging.
>
> https://en.wikipedia.org/wiki/Loki_(disambiguation)
> https://en.wikipedia.org/wiki/Loki_(C++)
>
>> Grafana itself live in another source package and will be a separate effort.
>
> Since Grafana was in Debian before and was removed due to being
> orphaned, outdated and RC-buggy, please note the extra steps required
> when reintroducing packages; base your new package on the latest
> version of the old package (such as from the old now archived VCS),
> unarchive/reopen and triage bugs closed by the removal and reopen and
> triage security issues closed by the removal.
>
> https://tracker.debian.org/pkg/grafana
> https://tracker.debian.org/news/994097/removed-260dfsg-3-from-unstable/
> https://bugs.debian.org/909592
> https://alioth-archive.debian.org/git/collab-maint/grafana.git.tar.xz
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=both;src=grafana
> https://www.debian.org/doc/manuals/developers-reference/pkgs.html#reintroducing-pkgs
I should point out that there's already a separate RFP for repackaging
Grafana in Debian, as #923872. It's a challenge to package, to say the
least, but I think it's such a useful package that it should be properly
packaged.
Hopefully, however, it should not *block* loki's packaging. We should be
able to install loki from Debian packages without requiring us to also
package Grafana: the web UI could be run from Docker or upstream
packages or whatever...
And hopefully loki may be easier to package than Grafana (which doesn't
say much), but looking at the dependency list makes me run screaming in
horror:
https://github.com/grafana/loki/blob/main/go.mod
200+ deps, a dozen "replace" (which, in golang world, means "a fork of
an upstream library we vendor in here", basically).
>From that perspective, it's actually worse than Grafana, which has less
dependencies, believe it or not. But Grafana is also a webapp which is
where it really hurt us, because there you also need to package 300+
nodejs dependencies (!). At least loki spares us that horror.
Thanks for working on that difficult package, and let us know of your
progress!
a.
--
Qui vit sans folie n'est pas si sage qu'il croit.
- François de La Rochefoucauld
Re: Bug#1001903: ITP: loki-database -- Like Prometheus, but for logs.
On 2022-03-31 10:06:40, Antoine Beaupré wrote: [...] > From that perspective, it's actually worse than Grafana, which has less > dependencies, believe it or not. But Grafana is also a webapp which is > where it really hurt us, because there you also need to package 300+ > nodejs dependencies (!). At least loki spares us that horror. For what it's worth, I looked at those deps and it seems we're missing about 28 immediate dependencies (which themselves might have their own missing deps). I tried to run `dh-make-golang estimate` but it fails to do a report, which is not reassuring. It also seems like there is a handful of kubernetes stuff in there which could also be a problem considering the approach *that* package has taken regarding packaging (which is to vendor all that shit in, so we can't reuse their work). It could be possible to strip some of that code out though, maybe we don't need a loki kubernetes operator in Debian for example. But I haven't actually checked why that code is there at all, nor how easy such a change would be. Anyways, here's the dump: $ dh-make-golang make github.com/grafana/loki [...] 2022/03/31 10:14:45 Build-Dependency "sigs.k8s.io/controller-runtime" is not yet available in Debian, or has not yet been converted to use XS-Go-Import-Path in debian/control 2022/03/31 10:14:45 Build-Dependency "k8s.io/apimachinery" is not yet available in Debian, or has not yet been converted to use XS-Go-Import-Path in debian/control 2022/03/31 10:14:45 Build-Dependency "github.com/thanos-io/thanos" is not yet available in Debian, or has not yet been converted to use XS-Go-Import-Path in debian/control 2022/03/31 10:14:45 Build-Dependency "github.com/aws/aws-lambda-go" is not yet available in Debian, or has not yet been converted to use XS-Go-Import-Path in debian/control 2022/03/31 10:14:45 Build-Dependency "github.com/grafana/dskit" is not yet available in Debian, or has not yet been converted to use XS-Go-Import-Path in debian/control 2022/03/31 10:14:45 Build-Dependency "github.com/cristalhq/hedgedhttp" is not yet available in Debian, or has not yet been converted to use XS-Go-Import-Path in debian/control 2022/03/31 10:14:45 Build-Dependency "github.com/cloudflare/cloudflare-go" is not yet available in Debian, or has not yet been converted to use XS-Go-Import-Path in debian/control 2022/03/31 10:14:45 Build-Dependency "github.com/fluent/fluent-bit-go" is not yet available in Debian, or has not yet been converted to use XS-Go-Import-Path in debian/control 2022/03/31 10:14:45 Build-Dependency "gopkg.in/Graylog2/go-gelf.v2" is not yet available in Debian, or has not yet been converted to use XS-Go-Import-Path in debian/control 2022/03/31 10:14:45 Build-Dependency "inet.af/netaddr" is not yet available in Debian, or has not yet been converted to use XS-Go-Import-Path in debian/control 2022/03/31 10:14:45 Build-Dependency "github.com/weaveworks/common" is not yet available in Debian, or has not yet been converted to use XS-Go-Import-Path in debian/control 2022/03/31 10:14:45 Build-Dependency "github.com/uber/jaeger-client-go" is not yet available in Debian, or has not yet been converted to use XS-Go-Import-Path in debian/control 2022/03/31 10:14:45 Build-Dependency "github.com/sony/gobreaker" is not yet available in Debian, or has not yet been converted to use XS-Go-Import-Path in debian/control 2022/03/31 10:14:45 Build-Dependency "github.com/drone/envsubst" is not yet available in Debian, or has not yet been converted to use XS-Go-Import-Path in debian/control 2022/03/31 10:14:45 Build-Dependency "github.com/joncrlsn/dque" is not yet available in Debian, or has not yet been converted to use XS-Go-Import-Path in debian/control 2022/03/31 10:14:45 Build-Dependency "github.com/docker/go-plugins-helpers" is not yet available in Debian, or has not yet been converted to use XS-Go-Import-Path in debian/control 2022/03/31 10:14:45 Build-Dependency "k8s.io/client-go" is not yet available in Debian, or has not yet been converted to use XS-Go-Import-Path in debian/control 2022/03/31 10:14:45 Build-Dependency "github.com/ViaQ/logerr" is not yet available in Debian, or has not yet been converted to use XS-Go-Import-Path in debian/control 2022/03/31 10:14:45 Build-Dependency "github.com/c2h5oh/datasize" is not yet available in Debian, or has not yet been converted to use XS-Go-Import-Path in debian/control 2022/03/31 10:14:45 Build-Dependency "gopkg.in/fsnotify.v1" is not yet available in Debian, or has not yet been converted to use XS-Go-Import-Path in debian/control 2022/03/31 10:14:45 Build-Dependency "k8s.io/api" is not yet available in Debian, or has not yet been converted to use XS-Go-Import-Path in deb
Re: Bug#1001903: ITP: loki-database -- Like Prometheus, but for logs.
On 2022-03-31 18:55:44, Sean Anderson wrote: > Hi Antoine, > > On 3/31/22 10:19 AM, Antoine Beaupré wrote: >> On 2022-03-31 10:06:40, Antoine Beaupré wrote: [...] > I've packaged around 20 dependencies so far. Impressive! Good job! > I have yet to submit them (primarily because I find doing this sort of > work sucks the energy out of me). I did not quite realize what I was > getting myself into :) That must be indeed *so* hard! I think it's worth at least pushing what you have to salsa, so that someone else can carry the torch from where you stopped, if you get tired of this. Who knows, another golang packager might also need the same dep and help you! > My TODO list follows. Packages with a # are done, those with a ! > have an error, and I forget what - means. Really nice, a few comments inline... > loki > #github.com/Workiva/go-datastructures > #github.com/joncrlsn/dque > #github.com/c2h5oh/datasize > #github.com/shurcooL/vfsgen > github.com/prometheus/prometheus surely that is packaged somehow. we have the `prometheus` binary package already in Debian, maybe that could be reused? > github.com/cortexproject/cortex oh wow, they link against cortex! that's massive right there... > #github.com/uber/jaeger-client-go i think i commented out the code linking to this in some other golang package, and i can't remember which one it is right now. That is probably as unhelpful as it sounds. :p > dskit > ^go.etcd.io/etcd wtf, they link to etcd too.. wth is this thing. that is certainly used by k8s. > migrate > modernc.org/sqlite that one is massive. i started using it for wallabako (#893648) and it brought in a ridiculous number of deps. but it's faster and more portable than the other sqlite lib I was using before, so that would be really nice to have in Debian. ... if a little bonkers (that thing basically transpiles sqlite from C to golang). > -gopkg.in/natefinch/lumberjack.v2 that's another one I used in wallabako, probably worth packaging in debian in general, just because a bunch of golang packages are likely to use it as well. > I can make an effort to submit the ones I have packaged, but I haven't > worked on this for a bit (as other projects took priority) That's absolutely fine, I think, and it would be really awesome if you could push what you have somewhere already, so that if someone wants to resume the work on loki, they can start from there. And, alternatively, that work would be useful for other packaging efforts, I am sure. Thank you so much! a.
Re: Bug#1001903: ITP: loki-database -- Like Prometheus, but for logs.
On 2022-03-31 20:54:32, Sean Anderson wrote: > On 3/31/22 8:36 PM, Antoine Beaupré wrote: [...] > Basically I looked at this and thought "OK that's 20 or so first order deps, > I can do this" and then I discovered that several of these had 20 first-order > deps of their own. Typical dependency hell. I'm so sorry for your loss of innocence. :p >>> I can make an effort to submit the ones I have packaged, but I haven't >>> worked on this for a bit (as other projects took priority) >> >> That's absolutely fine, I think, and it would be really awesome if you >> could push what you have somewhere already, so that if someone wants to >> resume the work on loki, they can start from there. >> >> And, alternatively, that work would be useful for other packaging >> efforts, I am sure. >> >> Thank you so much! > > Well, as a first step, I requested access to the golang package group, but > it looks like it was never approved. My username is butterball_geometry. I just approved you. -- Work expands so as to fill the time available for its completion. - Parkinson's law
Re: Bug#1001903: ITP: loki-database -- Like Prometheus, but for logs.
On 2022-03-31 21:15:21, Sean Anderson wrote: > OK, I uploaded a package to > https://salsa.debian.org/go-team/packages/golang-github-c2h5oh-datasize/ > > Can you have a quick look at it? I used dh-make-golang, but if there's > anything I need to tweak I'd like to know before I start uploading. This looks good to me. Did you ask upstream for tags? Sometimes it actually works! :) > And should I send ITPs for everything, or is it OK to leave the closes > as TODO in the changelog? Typically I like to fire ITPs for everything, because the roundtrip with NEW can be slow at times. It might also give a heads up for the FTP team of the relationships between the packages, which might not be obvious from the names. -- Drowning people Sometimes die Fighting their rescuers. - Octavia Butler
Re: Bug#1001903: ITP: loki-database -- Like Prometheus, but for logs.
On 2022-03-31 21:28:05, Sean Anderson wrote: > On 3/31/22 9:21 PM, Antoine Beaupré wrote: >> On 2022-03-31 21:15:21, Sean Anderson wrote: >>> OK, I uploaded a package to >>> https://salsa.debian.org/go-team/packages/golang-github-c2h5oh-datasize/ >>> >>> Can you have a quick look at it? I used dh-make-golang, but if there's >>> anything I need to tweak I'd like to know before I start uploading. >> >> This looks good to me. Did you ask upstream for tags? Sometimes it >> actually works! :) > > I did not. I'm going to start by focusing on uploading my past work. no problem. >>> And should I send ITPs for everything, or is it OK to leave the closes >>> as TODO in the changelog? >> >> Typically I like to fire ITPs for everything, because the roundtrip with >> NEW can be slow at times. It might also give a heads up for the FTP team >> of the relationships between the packages, which might not be obvious >> from the names. > > Sending these out might be the slowest part of all this >.> How so? Do you have to copy-paste those in an MTA? :) I found that setting up a local MTA helps tremendously in dealing with those kind of problems, as you can just pipe things around easily... > And what's the proper way to update an existing package? Should I create a PR? > Or should I just push directly? (what's the review process like) Since this is a 25+ year old project, there's probably a dozen ways to do this. The canonical way is to open a bug report with a patch in the BTS (bugtracker we're talking through here). If that doesn't get a response, in theory, you're allowed to do an NMU. If that doesn't work, you're allowed, again in theory, to salvage the package. And then there's salsa where you can send merge requests. But sometimes those get ignored by graybeards like me who forget it exists or forget to setup notifications, so the BTS is always a safer bet. All those acronyms are expanded somewhere in this article I just wrote about salvaging packages, by pure coincidence (i swear): https://anarc.at/blog/2022-03-31-first-package-salvaged/ Let me know if you have any further question -- La nature n'a créé ni maîtres ni esclaves Je ne veux ni donner ni recevoir de lois. - Denis Diderot
Re: Bug#1005858: gh,gitsome: File conflict, both ship /usr/bin/gh
On 2022-02-27 10:09:32, Paul Wise wrote: > Control: forwarded -1 https://github.com/donnemartin/gitsome/issues/177 > > On Sat, 26 Feb 2022 23:43:14 +0800 SZ Lin (林上智) wrote: > >> The "gitsome" has used "gh" since 2017, and thus would you mind renaming >> the "gh" in your package to avoid the conflict issue? > > Since gh is the official GitHub client, probably it should retain "gh" > and gitsome should move to "git some" or similar, as I have suggested > in the above upstream issue. The only commentor there agreed with me. And I agree with you. The gitsome package already installs two binaries: one is called "gh" and the other is called "gitsome". It seems to me it could simply drop the "gh" alias and none would be the worse. SZ, in your February 26 message[1], you explicitly asked the gh package maintainers to rename their package, which was refused. It seems the concensus that has developped in the following thread is that it is instead your package, gitsome, that should have its binary renamed. Pabs suggested `gitsome` could also be renamed to `git-some` which would make it visible as a `git some` subcommand, from what I understand. It seems like the `gh` alias is kind of an alias unrelated with the main functionality of the package. SZ, do you agree with removing the `gh` binary from the `gitsome` binary package? I'd be happy to send a NMU to do this if you agree, which would unblock `gh` from migrating into testing. Otherwise, how can we reach consensus on this? The policy says that if we can't reach consensus, *both* packages need to be renamed, and that seems like a situation where we would all lose. I'll also point out that the upstream issue hasn't seen any activity since pabs commented on it in February, so it doesn't seem like we can count on upstream to fix this for us. The issue has been open for 2 years now. Thank you for your time! [1]: https://lists.debian.org/msgid-search/CAFk6z8Mw0kFHehm_a7=0bmdt6mzff03sewx+y93xy42bkq7...@mail.gmail.com -- Tu connaîtras la vérité de ton chemin à ce qui te rend heureux. - Aristote
Re: Bug#1005858: gh,gitsome: File conflict, both ship /usr/bin/gh
On 2022-05-24 21:52:55, SZ Lin (林上智) wrote: > Hi, > > Antoine Beaupré 於 2022年5月19日 週四 下午10:11寫道： >> [...] >> SZ, do you agree with removing the `gh` binary from the `gitsome` binary >> package? I'd be happy to send a NMU to do this if you agree, which would >> unblock `gh` from migrating into testing. > > Yes, please go ahead :-) Great, that's really good to hear. I'm going to make a NMU and MR this very morning to solve this. Thanks for doing the right thing! -- Premature optimization is the root of all evil - Donald Knuth
Re: Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio
On Sat, 10 Sep 2022 12:17:23 +, Holger Levsen wrote: > On Fri, Sep 09, 2022 at 09:38:39PM +0200, Michael Biebl wrote: > > Should we repeat this mistake? Or put this differently: is there a pressing > > need/compelling reason to switch to pipewire in bookworm? > > I.e. what I miss from the proposal are the benefits of pipewire over > > pulseaudio. > > Can you elaborate why you'd want to make the switch in bookworm? > > yes, I'm missing answers to these questions too. The most pressing reason to ship pipewire in bookworm is to have support for scrensharing in Wayland, from what I understand. I am not very familiar with that part, so I'll stop there, but that seems pretty huge already. For me, the killer feature is that pipewire adds jack-like capabilities to pulseaudio. This is really amazing: i've been able to use this to help people debug their audio setups in videoconferencing by piping their outputs into Ardour (or it could actually be any recorder!) and do accoustic analysis there. That would have been *much* harder to do: possible, but hard. I also have the feeling that pipewire has already gone beyond what pulseaudio is capable of in terms of Bluetooth support, but I might be mistaken on that. > > Personally, I'd rather see pipewire mature a little bit more before we make > > the switch. > > same here. I think the timing is ripe. Ubuntu and Fedora switched already, so we won't be the first guinea pigs. And if we *don't* switch now, it's going to take *years* to shake off those bugs. And you *know* that people (like me) are going to try pipewire again when bookworm comes out and then complain it "doesn't work in Debian", and they will (rightly so, IMHO) blame Debian for not making it work properly. > > This puts less pressure on you, as maintainer, and pipewire as upstream > > project. > > yes. Well I guess I'd defer to the maintainer and upstream on that, but I will point out that Pipewire maintainers *have* been careful about not introducing pipewire as a default in *bullseye* in the past. If they feel confident in doing so now, I would definitely trust their judgement. As for upstream, this is their response to this FAQ: https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ#is-pipewire-ready-yet Excerpt: | Is PipeWire Ready Yet? | | It is pretty much ready for most users. It has been used since Fedora | 27 (November 2017) for Wayland screen sharing and has been the default | audio server since Fedora 34 (April 2021). | | The API/ABI has been declared stable since version 0.3. | | The protocol can support older 0.2 version clients transparently. This | means that flatpaks with older PipeWire libraries can connect to a | newer daemon. I mean yeah, it's 0.3, but they have a stable API and they say it's "pretty much ready for most users". I wouldn't even put Pulseaudio in this category, because *many* users can't use it for their main task (e.g. all pro audio users will need jack or pipewire instead). So, you know, I think it might just be ready! :) My personal, completely anecdotal experience with this is that I had some issues running it in *bullseye*. I filed a bug report about ardour interoperability (#994208) and that is probably already fixed. I just need to test this in bookworm, which is why I'm interested in this discussion in the first place. Also note that enabling pipewire was kind of clunky in bullseye. I don't know if that improved since then, but that makes it so most users won't actually try it until it's made default. So there's an argument to be made here that we should switch the default, even if temporarily -- say in unstable for a while -- just to get our unstable users to try it out more, so we can get a feedback loop going there. The freeze is coming, we should do this now, and not in a year. a. a. -- Premature optimization is the root of all evil - Donald Knuth
Re: Bug#1032137: ITP: python-hardware -- hardware detection and classification utilities
On 2023-02-28 15:18:33, Thomas Goirand wrote: > * Package name: python-hardware > Description : hardware detection and classification utilities > > Detect hardware features of a Linux systems: > * RAID > * hard drives > * IPMI > * network cards > * DMI infos > * memory settings > * processor features > . > Filter hardware according to hardware profiles. Oh, this is interesting! There's very little documentation on the upstream site, what do you plan on using this for? It looks like a library I could very well use to rewrite stressant into something more sane... It seems it even has benchmarks... Thanks for any clarification! -- We all pay for life with death, so everything in between should be free. - Bill Hicks signature.asc Description: PGP signature
Re: Best practices for Debian developers who are also upstreams?
On 2020-02-08 22:07:48, Otto Kekäläinen wrote: > Hello! > > I've ended up in being both the maintainer in Debian and an upstream > developer for a couple of packages and I have been fantasizing about > how to optimize my workflow so that I primarily fix all bugs and do QA > directly on the upstream development version (=upstream git master) > and then have only a very small overhead work then importing and > uploading new upstream releases in Debian. > > Is somebody else already doing something similar like this? > Any tips, blogs, examples on the topic? I maintain a few packages in Debian for which I am also the (mostly solo) upstream: * feed2exec * gameclock * monkeysign * undertime Those packages are all *native* packages, in that they *don't* have a -N suffix in the version number. This is generally frowned upon, but in my situation, it's been helpful because I don't need to worry about "upstream" vs "debian": everything is "in Debian". This implies that I have only one debian/ directory: the upstream. When I need to make a release, I push it to unstable. If I need to make a hotfix release for security or stable, I make a branch. I use semantic versionning and basically maintain a "major" version per Debian release (as necessary, which is "rarely"). > I find it annoying to carry Debian patches for bugs that could be > fixed globally at upstream, and it is also annoying when something > Debian QA catches is broken at upstream and I find it out only at the > time I am preparing an upload to Debian. I do both at once, all the time, as part of CI and the release process. I do the Debian checklist before I even push tags upstream, but sometimes things come up in Debian after I pushed the tag. Then I just make another patch release, no big deal. > My goals would be: > - have debian/ in upstream repository, and a CI that does the bulk of > Debian QA on every upstream commit and immediately gives feedback to > upstream devs that "break" something from Debian QA point of view The tricky part here is generating a new version without mangling debian/changelog all the time. I haven't found a great story for that that works with git, but maybe you can generate syntetic commits to fake a new Debian package version in CI. > - have the delta of Debian debian/ an upstream debian/ as small as > possible For me, there's no diff. It's the same branch, same code. I do, however, generate debian/changelog only on release so I don't have to repeat myself between commit logs (in git) and release notes (in debian/changelog). > - fix all bugs detected in Debian directly at upstream when possible Not sure what that means, but when I fix a bug in Debian, it's fixed in "upstream" first, ie. I push it to git, and I tag it as "pending" in the BTS to make it clear it will be fixed in the next upload. > - when not possible, fix them "locally" first in Debian and eventually > have it upstreamed I never have to do that. To fix it "first in Debian", I just make a new upstream release. If it's on a previous "branch" (e.g. stable), I make a release on that branch. For example right now undertime is 1.7.0 in buster and 1.8.0 in bullseye/sid. Next RC bugfix release is 1.8.1 in sid and 1.7.1 in buster, and I would have a 1.7.x branch to follow buster (which I haven't needed yet). > - have it easy to compare Debian and upstream debian/ contents Trivial. It's my different maintenance branches. > - bonus: import upstream releases as git operations without having to > export and import tar.gz packages I export tarballs only as part of the release process and otherwise don't bother with those artefacts at all. > I have in rdiff-backup pretty much this setup already in place but I > have some challenges on how to handle the debian/changelog file and a > couple of other details. I would be very keen to learn from others > before inventing too much of new. The changelog is the hard part. I update it only on release which simplifies things tremendously, but will make CI harder, as I mentioned before. Also, this is not for everyone: it makes it hard for Debian folks to send updates to the git repository (because it might not be on debian.org infra) and inversely it makes it hard for "upstream" to make a release if they're not Debian developers. Fortunately, I am both and those are mostly solo projects so that hasn't been an issue so far. When it will be, the package will just go non-native and follow more usual development practices. This happened to etckeeper when joeyh left us, for example. I hope that helps! A. -- Si les triangles avaient un Dieu, ils lui donneraient trois côtés. - Montesquieu, Lettres persanes
Re: Best practices for Debian developers who are also upstreams?
On 2020-02-18 23:14:14, Simon McVittie wrote: > On Tue, 18 Feb 2020 at 15:47:17 -0500, Antoine Beaupré wrote: >> The tricky part here is generating a new version without mangling >> debian/changelog all the time. I haven't found a great story for that >> that works with git, but maybe you can generate syntetic commits to fake >> a new Debian package version in CI. > > I think the way to do this is to have an uncommitted change to d/changelog > when you do your build, and choose your CI version numbers carefully so > that they interleave correctly with "real" version numbers. > https://gitlab.collabora.com/smcv/deb-build-snapshot/ (currently on my > employer's infrastructure, but I'll probably move it to Salsa at some > point) is designed for this workflow. My trouble with doing that by hand is when I change the git-repo, git-buildpackage and friends complain about uncommitted changes.. :) I'm sure there are simple ways around that, but that was the blocker I remembered back then. > The version-number-generating part, deb-git-version-gen, implements the > careful choice of version numbers and has been split out into a separate > script which I might propose for inclusion in devscripts at some point - > it should be feasible to run as a git-buildpackage hook or similar, > and can either run dch itself, or output a simple version number or a > blob of JSON describing the package's versioning (the latter includes > some suggested arguments for dch). That would be really nice. >> Also, this is not for everyone: it makes it hard for Debian folks to >> send updates to the git repository (because it might not be on >> debian.org infra) > > This seems particularly weird for native packages, which are supposedly > "written specifically to be a Debian package" (Policy §5.6.12). I have always found the wording and context around native packages to be really weird. Aren't all Debian *packages* written specifically to be debian packages? :) (I know the actual wording is "a piece of software was written specifically to be a Debian package"... So yes, I'm being facetious here.) I think that restriction should be lifted, personnally. Using native packages has made my job as an upstream and a Debian developer much easier even if the tools weren't specifically written for inclusion in Debian. There are many cases of such packages that don't respect policy and I wonder if policy should adapt rather than changing that practice. I also find it quite ironic to think about this provision in the context where a lot of software specifically written for Debian is actually *not* packaged in Debian itself. Instead it's being deployed through other means on Debian.org infrastructure. So the prime use case of native packages is not being really used in the first place. ;) [...] >> and inversely it makes it hard for "upstream" to make >> a release if they're not Debian developers. > > This was a practical problem when Joey Hess left Debian: ikiwiki was a > native package, with no release procedure other than uploading it to > Debian, and I became a single point of failure for security releases > because I was suddenly the only person with both ikiwiki commit access > and Debian upload rights. > > (I later disentangled it so that upstream releases are just git tags > pointing to a native package, and the Debian packaging is non-native.) I have not found the switch between native and non-native to be that problematic, personnally. It's something that needs to happen on upstream or debian team changes, but it can be done reasonably easily. Or at least it's easy enough that it's not a disincentive to use native packages when you can. A. -- All governments are run by liars and nothing they say should be believed. - I. F. Stone
Bug#833897: ITP: abduco -- Terminal session management in a clean and simple way
Package: wnpp Severity: wishlist Owner: "Antoine Beaupré" * Package name: abduco Version : 0.6 Upstream Author : Marc Andre Tanner * URL : http://www.brain-dump.org/projects/abduco/ * License : ISC Programming Lang: C Description : Terminal session management in a clean and simple way abduco provides session management i.e. it allows programs to be run independently from their controlling terminal. That is programs can be detached - run in the background - and then later reattached. Together with dvtm it provides a simpler and cleaner alternative to tmux or screen. . abduco is in many ways very similar to dtach but is a completely independent implementation which is actively maintained, contains no legacy code, provides a few additional features, has a cleaner, more robust implementation and is distributed under the ISC license. Abduco was removed from Debian in may because it was out of date. This is an attempt at updating the package to a more recent versions that is hopefully more stable. I intend to replace my screen setup with dvtm + abduco shortly. In cc, the previous maintainer and his sponsor (hi francois! :)
Bug#842974: ITP: slop -- queries for a selection from the user and prints the region to stdout.
Package: wnpp Severity: wishlist Owner: "Antoine Beaupré" * Package name: slop Version : 4.3.21 Upstream Author : Dalton Nell * URL : https://github.com/naelstrof/slop * License : GPL-3 Programming Lang: C++ Description : queries for a selection from the user and prints the region to stdout. slop (Select Operation) is an application that queries for a selection from the user and prints the region to stdout. It grabs the mouse and turns it into a crosshair, lets the user click and drag to make a selection (or click on a window) while drawing a pretty box around it, then finally prints the selection's dimensions to stdout. Features: * Hovering over a window will cause a selection rectangle to appear over it. * Clicking on a window makes slop return the dimensions of the window. * Clicking and dragging causes a selection rectangle to appear, renders pretty well (compared to scrot). And will return the dimensions of that rectangle in absolute screen coords. * On startup it turns your cursor into a crosshair, then adjusts the cursor into angles as you drag the selection rectangle. * Supports simple arguments: * Change selection rectangle border size. * Select X display. * Set padding size, even negative padding sizes! * Set click tolerance for if you have a shaky mouse. * Set the color of the selection rectangles to match your theme! (Even supports transparency!) * Remove window decorations from selections. * Supports OpenGL hardware acceleration. * Supports textured themes. * Supports programmable shaders. * Supports a magnifying glass.
Bug#842975: ITP: xininfo -- Small helper program for monitor layouts
Package: wnpp Severity: wishlist Owner: "Antoine Beaupré" * Package name: xininfo Version : 0.14.11 Upstream Author : Dave Davenport * URL : https://github.com/DaveDavenport/xininfo * License : MIT Programming Lang: C Description : Small helper program for monitor layouts xininfo is an X11 utility to query the current layout and size of each configured monitor. It is designed to be used by scripts. I am packaging this as a dependency for teiler.
Bug#842977: ITP: teiler -- Little script for screenshots and screencasts utilizing rofi, maim, ffmpeg
Package: wnpp Severity: wishlist Owner: "Antoine Beaupré" * Package name: teiler Version : 3.0 Upstream Author : Rasmus Steinke * URL : https://carnager.github.io/teiler/ * License : GPL-3 Programming Lang: Bash Description : Little script for screenshots and screencasts utilizing rofi, maim, ffmpeg teiler uses or rofi to draw a menu which lets you choose between screenshots or screencasts. Features: * screenshots fullscreen/monitor/area * delay of screenshots * screencasts of monitor/area * upload screenshots/screencasts - teiler can also upload your files via scp, imgur or filebin, ix (for pastes) and amazon s3. * History of Images and Videos with support for + Viewing + Editing + Uploading * Commandline interface for direct access to all features. Useful for hotkeys
improved alioth-salsa test script (calls for testing/improvements)s
So some of us have been working on streamlining the migration between Alioth and GitLab, because clikety things are annoying. At first, Christopher Berg wrote this script to trigger the GitLab API: http://www.df7cb.de/blog/2017/Salsa_batch_import.html Good start, but it triggered a bug in the GitLab API that happens on large groups, which means it's slow. Then Raphael Hertzog made a script to disable repos on Alioth. I "improved" it a bit by expanding and reusing the description file, having worked on my own hand-made equivalent, for some repos I migrated. That lived for a while in ~rhertzog but now lives in ~anarcat/bin/disable-repository. And then I got tired of doing things by hand or waiting for Berg's script, so I merge both scripts in a hacky Python script. It's a little more polished, but maybe not as well tested. I migrated half a dozen of my repos, and shaken out most bugs (I think!), but I would love to get more testing. The script now lives in ~anarcat/bin/migrate-repo. Documentation for all that stuff is in the Debian wiki: https://wiki.debian.org/Salsa/AliothMigration#Import_git_repository The source code is in my home repo for now, but maybe it should live in the salsa/ group (which I'm not a member of) or debian/ group (which I am). Considering people can fork and send merge requests, I don't think it matters much for now. https://salsa.debian.org/anarcat/alioth-migration The README there has more details & limitations as well. So hack and migrate away! From what I understand, the migration is going quite well, and a large number of repos have already moved. Hopefully, this will make it easier. Feedback, bug reports, pull requests all welcome of course. A. -- Pour marcher au pas d'une musique militaire, il n'y a pas besoin de cerveau, une moelle épinière suffit. - Albert Einstein
Re: [Alioth-staff-replacement] improved alioth-salsa test script (calls for testing/improvements)s
On 2018-05-02 19:45:17, Holger Levsen wrote: > On Wed, May 02, 2018 at 07:02:29PM +0200, Paolo Greppi wrote: >> Hi Holger, try this: >> /alioth-migration/migrate-repo -v -d /git/collab-maint/anarchism.git >> /debian/anarchism > > holger@moszumanska:~$ ls /alioth-migration/migrate-repo > ls: cannot access /alioth-migration/migrate-repo: No such file or > directory try removing the first slash there :) >> It seems the script "works better" if the path to the original repo on >> alioth is the shortest possible > > this cannot^wmust not be true. it might be. the script works by making some educated guesses that are easily broken. a. -- The individual has always had to struggle to keep from being overwhelmed by the tribe. If you try it, you will be lonely often, and sometimes frightened. But no price is too high to pay for the privilege of owning yourself.- Friedrich Nietzsche
possible conflict over the /usr/bin/ia namespace
Hi, TL;DR: new package from archive.org conflicts with existing `ia` binary from python-duckduckgo2. Policy §10.1 consensus sought. I'm in the process of packaging the Internet Archive (archive.org) Python commandline client and that installs a client that is conveniently called "ia" in /usr/bin. It's a simple wrapper around a more elaborate Python library, but it allows a fairly complete set of operations of the archive like searching, downloading, uploading and deleting data. Unfortunately, apt-file (is there a better way?) tells me that python-duckduckgo2 already claimed that command namespace, along with the ddg command, naturally. I tried to figure out what the other package does: there's no documentation in the Debian package, and neither command supports has inline help or manpages. From what I can tell, the `ddg` command output structured data from a DDG (DuckDuckGo.com) search and `ia` command does a "feel lucky" type of request to output only one answer. This seems to be somewhat related "Instant Answers" API (hence the `ia` acronym) as defined here: https://duckduckgo.com/api So the situation falls directly under section 10.1 of the Policy: https://www.debian.org/doc/debian-policy/ch-files.html#s-binaries > Two different packages must not install programs with different > functionality but with the same filenames. The solution proposed by the policy is to rename one or both of the packages, after a discussion here: > [...] try to find a consensus about which program will have to be > renamed. If a consensus cannot be reached, both programs must be > renamed. Obviously, DDG has the upper hand right now: it's already passed new and is in the archive. My "internetarchive" package is only at the ITP stage (in CC) but it's fairly complete and would be ready for upload. Right now it Conflicts with the DDG package, but that's not the best solution - I would need to rename the commandline binary to respect policy, if I understand it correctly. But before doing that, I want to give the Internet Archive a chance. As an argument for the archive, I would say its acronym is more commonly known and used than DDG's, which I found out for the first time here and never heard about before. Wikipedia agrees; in this disambiguiation page, DDG is not listed at the time of writing, while the Archive is: https://en.wikipedia.org/wiki/IA The "snap" package `ia` also points to the archive's software: https://snapcraft.io/ia Same for FreeBSD and, as far as I can tell, Arch Linux. I would therefore propose for the python-duckduckgo2 ia binary to be renamed to ddg-ia, as its "ia" use is only secondary in the package's purpose. The alternative course of action would be to rename the ia binary in the internetarchive package to "internetarchive" but that's rather long and unusual: all upstream documentation refers to the `ia` binary and this could confuse our users needlessly, especially since other platforms also use the `ia` acronym to refer to the archive as well. The source of the package is available here: https://salsa.debian.org/python-team/modules/python-internetarchive Progress in the packaging can be followed in the CC'd bug report. With good faith and spirit, sorry for the long email and thanks for any feedback! A, PS: there is, incidentally, also the question of how to name this (source and binary!) package: python3-internetarchive, internetarchive and ia would all be interesting names for various reasons. I would prefer the latter, but it would obviously require the DDG side to rename first to make any sense. The Debian Python policy on this is, as far as I know, rather undecided right now, especially for packages like internetarchive that mix libraries and commandline tools. -- I'm no longer accepting the things I cannot change. I'm changing the things I cannot accept. - Angela Davis
Re: possible conflict over the /usr/bin/ia namespace
On 2018-09-25 10:45:07, Iain Learmonth wrote: > Hi, > > On 25/09/18 05:35, Antoine Beaupré wrote: >> I tried to figure out what the other package does: > > It uses the DuckDuckGo instant answers API to give an instant answer on > the command line as a more human friendly version of the ddg command > which is machine-readable but contains more information. > > popcon reports 7 old and 0 recent. > > The ia script was added in a patch and never actually present upstream: > > https://sources.debian.org/src/python-duckduckgo2/0.242+git20151019-1/debian/patches/0001-add-ia-script.patch/ > > I was using this as part of an IRC bot but I now just call Python directly. > > The easiest solution here is probably that I drop that script. It was > never accepted upstream anyway, nor have there been any updates upstream > since 2015. Great! I would be happy to help with that if you need any assistance. In the meantime, should I just upload IA to NEW? :) A. -- To punish me for my contempt for authority, fate made me an authority myself. - Albert Einstein
Re: possible conflict over the /usr/bin/ia namespace
On 2018-09-25 13:43:42, Ian Jackson wrote:
> Antoine Beaupré writes ("Re: possible conflict over the /usr/bin/ia
> namespace"):
>> Great! I would be happy to help with that if you need any assistance.
>> In the meantime, should I just upload IA to NEW? :)
>
> You need to coordinate the transition for the /usr/bin/ia filename. I
> think that means your new internet-archive package should probably
> Conflict: python-duckduckgo2 (<< version-without-ia~)
>
> That can probably be uploaded before the new python-duckduckgo2 but
> the relevant version number should be agreed.
Makes sense. How about:
Conflicts: python-duckduckgo2 (<= 0.242+git20151019-1)
This way we assume any newer upload of the package will remove ia?
I'd be happy to do that upload, actually. I see the git repo used to be
on Alioth:
https://alioth-archive.debian.org/git/collab-maint/python-duckduckgo2.git.tar.xz
... but it hasn't been migrated to Salsa. Would you be okay to move this
in the Python module's team umbrella (as opposed to simply collab-maint)?
> And if you do upload internet-archive before python-duckduckgo2 is
> changed there there should probably be a bug against
> python-duckduckgo2.
Sure, I'll file that anyways now.
> I guess that bug doesn't need to be rc ?
Yeah, that's not RC material, as long as the bug is not forgotten in the
next upload of course. :)
A.
--
Instead of worrying about what somebody else is going to do, which is
not under your control, the important thing is, what are you going to
decide about what is under your control?
- Richard Stallman
Re: possible conflict over the /usr/bin/ia namespace
On 2018-09-25 14:22:44, Ian Jackson wrote:
> Antoine Beaupré writes ("Re: possible conflict over the /usr/bin/ia
> namespace"):
>> Makes sense. How about:
>>
>> Conflicts: python-duckduckgo2 (<= 0.242+git20151019-1)
>>
>> This way we assume any newer upload of the package will remove ia?
>
> That's not a good choice because it excludes (local) backports,
> security updates, etc., which tend to add +something to versions.
> If you can't get a better idea I would suggest
> << 0.242+git20151019-1.1~
> which is all versions until the next draft(~)-of-an-nmu (.1).
But wouldn't <= 0.242+git20151019-1~ be as effective? Why does it need
to be <
Re: possible conflict over the /usr/bin/ia namespace
On 2018-09-25 14:25:25, Ian Jackson wrote:
> Iain Learmonth writes ("Re: possible conflict over the /usr/bin/ia
> namespace"):
>> On 25/09/18 14:16, Antoine Beaupré wrote:
>> > ... but it hasn't been migrated to Salsa. Would you be okay to move this
>> > in the Python module's team umbrella (as opposed to simply collab-maint)?
>>
>> The whole salsa thing is not something that I've been able to keep up
>> with. I have git repos locally and I've been moving things to salsa as
>> and when I do updates. You probably shouldn't trust what is on salsa
>> anyway unless we all start using signed commits and tags. The archive is
>> the only true record of packages.
I agree with that, for the record. Like any upload I sponsor or work on,
I review the diff before signing anyways, regardless of the source.
> For packages maintained by very small (or unitary) teams with limited
> collaboration, ad-hoc sharing via personal git repos works OK. And of
> course you can share your git branch more formally with everyone,
> in step with the archive, and with reasonable security, by using `dgit
> push'.
I really should give dgit a try again, but I guess it's a great use case
for people allergic to salsa (pun intended) and that just need a git
repo, right? :)
>> I once looked at doing team maintenance on these packages but there was
>> enough extra policy regarding that team management that I did not have
>> the time to look at it. If you would like to adopt the package and move
>> it into the team then that's fine with me. I am also on the list of "low
>> nmu" maintainers. I am not interested in maintaining the package within
>> the team myself though.
>From what I understand, the Python folks are easy: it's just a way to
get the package some visibility and help, and the overhead is
minimal. You don't have to join the team to upload.
But "collab-maint" (also known as "debian" now on Salsa) also works
fine. I don't need a new package to maintain so I'd be happy to let you
proceed with the future of this one. :)
>> Ok, I will close that in approx 15 minutes. (:
Awesome! I'll proceed with the upload of "internetarchive" (binary and
source, after consulting with #debian-python people) shortly as well.
A.
--
Toute mère doit être mère par choix.
Tout enfant doit être un enfant désiré.
- Henry Morgentaler
Re: possible conflict over the /usr/bin/ia namespace
On 2018-09-25 14:33:44, Ian Jackson wrote:
> Antoine Beaupré writes ("Re: possible conflict over the /usr/bin/ia
> namespace"):
>> On 2018-09-25 14:22:44, Ian Jackson wrote:
>> > If you can't get a better idea I would suggest
>> > << 0.242+git20151019-1.1~
>> > which is all versions until the next draft(~)-of-an-nmu (.1).
>>
>> But wouldn't <= 0.242+git20151019-1~ be as effective? Why does it need
>> to be <
> 0.242+git20151019-1 is not <= 0.242+git20151019-1~ so that is
> definitely wrong. Maybe you meant <= 0.242+git20151019-1.1~ ?
> But if I were preparing an NMU I would be intending to use
> 0.242+git20151019-1.1 as the nmu version; and my draft packages would
> be called precisely 0.242+git20151019-1.1~ and don't want to be
> conflicted against. Hence 0.242+git20151019-1.1~
>
> This seems like arcane lore really. Surely this stuff ought to be
> documented somewhere ?
It's super weird corner cases - those are hard to document... I looked
into those places in the policy, for example, and couldn't quite figure
it out:
https://www.debian.org/doc/debian-policy/ch-relationships.html#conflicting-binary-packages-conflicts
https://www.debian.org/doc/debian-policy/ch-relationships.html#syntax-of-relationship-fields
The former does not mention any way to specify the actual version; it
probably should. The latter mentions the comparison operators but it
doesn't go into details into how to use them.
The developer's reference also does not seem to have anything about this
that I could find quickly.
So anyways - irl will upload a new package now, presumably -2 or more,
so i think << 0.242+git20151019-2~ is fine.
A.
--
One of the things the Web teaches us is that everything is connected
(hyperlinks) and we all should work together (standards). Too often
school teaches us that everything is separate (many different
'subjects') and that we should all work alone. - Aaron Swartz
Re: Limiting the power of packages
On 2018-10-04 08:38:09, Paul Wise wrote: > On Thu, Oct 4, 2018 at 1:19 AM Lars Wirzenius wrote: > >> The problem: when a .deb package is installed, upgraded, or removed, >> the maintainer scripts are run as root and can thus do anything. > > anarcat wrote this related wiki page that covers this general topic: > > https://wiki.debian.org/UntrustedDebs > > The maintainer scripts are just the first problem that comes up when > installing untrusted packages. > > There are myriad ways a package could install files that allow it to > get root. setuid binaries, cron jobs, systemd units, apt keyring > information, sudoers files and so on. The amount of stuff that can > lead to root completely depends on the packages one already has > installed. Then there are myriad other things that don't allow root > that untrusted applications should not get hold of (like your private > diary, some keys or passwords etc). Yet I still think we should start fixing those problems. Yes, there are a billion things that could go wrong in the current approach, but if we had *some* safety net, controlled in the sources.list file, we could at least restrict what third-party packages would do. For example, there's no reason why a package like Chromium should be able to run stuff as root. The vast majority of third-party repositories out there mostly ship this one binary that does not require special privileges other than installing stuff in /usr, without suid or any special permissions. > To fully solve the problem you need a whitelist based approach that > ends up something completely different like Flatpak. > > It might become possible to convert .debs to Flatpak using something > like the ArchLinux approach for this and a future version of > mmdebstrap that might allow installing sub-essential. > > https://wiki.archlinux.org/index.php/Flatpak#Creating_apps_with_pacman Yes well, we *could* consider rewriting Debian to be based on appimage/flatpak/snappy, but that would be a rather controversial change. I think there are smaller, incremental steps we can take before that to improve the situation without rewriting the whole world. The wiki page I wrote was a short inventory of some of that stuff. There are somewhat low-hanging fruits in there like declarative maintainer scripts. I would also like to see end-to-end trust verification (like we see on Android) for .debs, although I'm not exactly sure how that could work in practice. At least shipping the signatures to allow some manual verification would be an easy first step. == The devil, of course, is in the details, and someone needs to sit down and make sense of all that stuff. It *is* true that the flatpak model does try to address a lot of those issues and we might want to consider that more closely. Beyond this issue, what I'm mostly concerned about these days is isolation between different apps. Our only solution on the desktop right now is Qubes and it seems rather overengineered for my needs. Compared with the security models of iOS or Android, we still have quite a lot of work to do to make sure (say) my IRC client cannot steal my bank credentials or (the horror!) vice-versa. ;) A. -- Man is, at one and the same time, a solitary being and a social being, - Albert Einstein
Re: Bug#910253: ITP: nmtree -- Validates modes, ownership, and contents of directory tree against specification
On 2018-10-03 21:03:22, John Goerzen wrote: > Package: wnpp > Severity: wishlist > Owner: John Goerzen > > * Package name: mtree-netbsd > Version : 20180822 > Upstream Author : Joerg Sonnenberger and NetBSD > contributors > * URL : > http://cdn.netbsd.org/pub/pkgsrc/current/pkgsrc/pkgtools/mtree/README.html > * License : BSD > Programming Lang: C > Description : Validates modes, ownership, and contents of directory > tree against specification > > The mtree utility compares a file hierarchy against a specification, > creates a specification for a file hierarchy, or modifies a specification. > This specification can be controlled by the user, but typically includes > file/directory/symlink names, ownership information, permission bits, and > so forth. It may optionally also include various hashes, such as SHA-256 > or MD5. > . > This mtree utility can understand its own files, as well as those generated > by the FreeBSD mtree (in Debian as fmtree in freebsd-buildutils and > freebsd-glue) and bsdtar/libarchive. Why do we need NetBSD's mtree when we have freebsd's already? I don't mind much the duplication: I'm genuinely curious. :) (I have also wondered for a long time why we don't have simply a `mtree` package in Debian - it's a very useful tool to have!) a. -- During times of universal deceit, telling the truth becomes a revolutionary act. - Georges Orwell
Re: Confusing our users - who is supporting LTS?
Hi Steve! On 2018-10-23 04:26:18, Steve McIntyre wrote: > So I'm worried that those of us who have *not* volunteered to support > LTS are being pressured into spending our time on it anyway. What can > we do to fix that? How/where do we clarify for our users (and > developers!) what LTS means, and what expectations are fair? TL;DR: Why not just delegate image management to the LTS team once oldstable because LTS just like we do with security? Zobel also provided a good template for the images life cycle which could clarify this on debian-cloud@, which I fully support. I acknowledge this is, indeed, a problem Debian volunteers have sometimes mentioned. It's a broader issue than just the cloud team of course, but if I may, I would like to try and fix that specific issue in itself. I know there's the larger debate of separation of duty and infrastructure, paid-vs-unpaid work and other questions, but I do not think it's productive to fix that particular issue by addressing the larger ones up front, as they seem intractable unless we address specific cases. In this case, it seems to me we have a flawed assumption in the way we handle Debian LTS: we assume people will not actually install it and instead just upgrade machines installed when LTS was "stable". It's a fair assumption in the case of workstations and long-lived, "pet" servers. I know I wouldn't install a new bare-metal server with an unsupported release: I would install stretch, if not buster, not jessie. But in the cloud infrastructure, things are slightly different. The base image isn't as important as the application and/or data that runs on top. In the cloud, we install new "machines" all the time, sometimes as part of CI/CD processes and those machines are not "pets", they are "cattle" and recycled constantly. In that sense, switching the base OS is, paradoxically, a big deal so it actually makes sense to install an older release for newer machines. This is why Travis CI still supports Ubuntu LTS Precise (12.04) and Trusty (14.04), the former which isn't supported by Canonical, and it's missing *two* more recent LTS releases, Xenial (16.04) and Bionic (18.04). So while we haven't taken up the work of managing the debian-installer parts of Debian LTS (because there was no need or demand for it), it seems to me like a fair request that the Debian LTS team should manage the Debian Cloud images once the official support window closes. Just like the security team delegates oldstable to LTS, the cloud team could hand off unsupported images to the LTS team. In a way, just like APT and the normal archive, "cloud images" are just another way to "upgrade" an existing Debian install. It seems like a nice, symmetrical approach to solve the problem: just punt this over to the LTS team. We have some capacity and knowledge. I know I would be happy to work on those images. That's for the expectations part of the question. As for how to clarify this to our users, Martin Zobel-Helas made a good proposal for a workflow of how and when the team updates the images and when they become unsupported. The /etc/motd in the images could mention this, for example and the last build could add a warning pointing to it. If we agree to delegate to the LTS team, the document should also mention that transition. Sorry for the long email, I hope it's useful! a. -- We have to talk about liberating minds as well as liberating society. - Angela Davis
maim maintainer (Patrick O'Doherty) whereabouts?
Hi! (In CC, the sponsor of the first maim upload.) I'm looking for the maintainer of the maim package, Patrick O'Doherty. I have done two NMUs on the package in the last month or so, and I haven't had a reply from him to any of my emails. I suspect we may have a miscommunication problem. The problem right now is that maim and slop are maintainer by the same upstream, and he has this nasty tendency of breaking ABI at every other release of slop, which breaks maim completely. To fix this, I'd be interested in either delegating the slop maintainership, co-maintaining both packages, or adopting maim. I'll otherwise continue to upload NMUs to fix those problems as they come, but I must say it's a rather inconvenient delay to deal with (and Patrick is not in the LowNMU list). Thanks for any advice! A. -- The greatest tragedy in mankind's entire history may be the hijacking of morality by religion. - Arthur C. Clarke
Re: Bug#881378: ITP: benchmark -- Microbenchmark support library
On 2017-11-10 23:18:26, Anton Gladky wrote: > Package: wnpp > Severity: wishlist > Owner: Anton Gladky > > * Package name: benchmark > Version : 1.3.0 > * URL : https://github.com/google/benchmark > * License : Apache-2.0 > Programming Lang: C++ > Description : Microbenchmark support library > > Library to support the benchmarking of functions, similar to unit-tests. > https://github.com/google/benchmark/blob/master/README.md > > The package will be maintained under the roof of Debian Science Team. Isn't this a rather... generic package name? :) May i suggest packaging this as "libbench" or something to that effect at least? A. -- If quantum mechanics hasn't profoundly shocked you, you haven't understood it yet. - Niels Bohr
Re: Debian Project Leader Elections 2016: last call for votes
> - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- > 739cd7a3-8473-486c-8cbe-f54835b4b3b6 > [1 ] Choice 1: Mehdi Dogguy > [2 ] Choice 2: None Of The Above > - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- -- Il est sage de nous réconcilier avec notre adolescence ; haїr, mépriser, nier ou simplement oublier l’adolescent que nous fûmes est en soi une attitude adolescente. - Daniel Pennac, Comme un roman
Bug#824712: RFH: smokeping
Package: wnpp Severity: normal I need help maintaining the smokeping package. I do not really use it anymore and i'd be happy to help people to sponsor it. There's a bunch of obscure bugs all over the place, and while I think the package mostly works, it's just a wild guess since well, I'm not using it right now.
Re: proposal: Hybrid network stack for Trixie
It seems to me this proposal is just a *tad* too ambitious. I haven't followed the entirety of all threads about this topic (has anyone?) but it seems to me we're proposing to do two major changes at once: 1. replace ifupdown with systemd-networkd 2. unify configuration of networkd and NetworkManager with netplan *Either* of those seems somewhat controversial to me, and after reading a few messages in this thread, seems that neither has reached consensus. For example, in my personal opinion, even if netplan could work with an ifupdown backend (and it can't!) I wouldn't support #2 here. I don't see why I would need a unified configuration layer between ifupdown (or systemd-networkd) and NM, it basically never has been a use case for me. I either configure servers (in which case i use ifupdown or networkd) or desktops (in which case I use NM). And then, of course, there's the "systemd question". I've been slowly converting my personal servers over to systemd-networkd, because I've been having similar issues than DSA with IPv6 contention issues. It generally works! And, yeah, it's a couple of config files to manage, but it's nothing that puppet (or ansible) can't easily handle, so that's not a problem for me at all. Yet, that change is a big deal in Debian. ifupdown is one of those Debian-specific things that has been around since basically forever. It's in numerous guides and manuals, so lots of documentation would need to be updated to reflect such a huge change. And that's not counting all the people who have expressed here and elsewhere that they just don't *want* to change away from ifupdown. I happen to think it's the right way to go, personally, but I think the way to do this would be to first add support for systemd-networkd in d-i and cloud images, rather than netplan, because that would be far less controversial. It would still allow people who want to to stick to ifupdown, for example, it would "just" change defaults. Either way, coming from the bits from the DPL here, I was hoping to see a unified proposal that would try to approach consensus, but I don't feel this is it. netplan is yet another controversial idea, and I don't think it's consensual. I would focus on trying to reach consensus to replace ifupdown with networkd in d-i/images first, in any case. If we *must* use netplan to do this, as an implementation, then okay, so be it. But just deciding this is a huge step, and we should focus on that, if that's the direction we want to go. Just a thought. -- Computer science is no more about computers than astronomy is about telescopes - E. Dijkstra signature.asc Description: PGP signature
Re: Bug#1107670: ITP: condense-json -- Python function for condensing JSON using replacement strings
On 2025-06-12 10:50:38, Guillem Jover wrote: > Hi! > > On Wed, 2025-06-11 at 13:43:51 -0400, Antoine Beaupre wrote: >> Package: wnpp >> Severity: wishlist >> Owner: Antoine Beaupre >> X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org > >> * Package name: condense-json >> Version : 0.1.3 >> Upstream Contact: Simon Willison >> * URL : https://github.com/simonw/condense-json >> * License : Apache >> Programming Lang: Python >> Description : Python function for condensing JSON using replacement >> strings >> >> The `condense_json` function searches a JSON-like object for strings >> that contain specified replacement substrings. It replaces these >> substrings with a compact representation, making the JSON more >> concise. >> . >> This is mostly used as a dependency for the llm package. > > Please namespace the source package with python-, so that we do not > take the global namespace for language specific packages. Okay! This has already been uploaded to NEW, but I guess I can just upload a new version to replace it? The binary package already has the python-* prefix, FWIW, so I figured it was okay for the source package to be like this... a. -- The odds are greatly against you being immensely smarter than everyone else in the field. If your analysis says your terminal velocity is twice the speed of light, you may have invented warp drive, but the chances are a lot better that you've screwed up. - Akin's Laws of Spacecraft Design
