Bug#956343: ITP: dateparse -- GoLang Parse many date strings without knowing format in advance
Package: wnpp Severity: wishlist Owner: Alois Micard * Package name: dateparse Version : 0.0~git20200409.d820a61-1 Upstream Author : Aaron Raddon * URL : https://github.com/araddon/dateparse * License : Expat Programming Lang: Go Description : GoLang Parse many date strings without knowing format in advance. This library is needed for advancedlogic/GoOse. Thank in advance -- Aloïs Micard GPG: DA4A A436 9BFA E299 67CD E85B F733 E871 0859 FCD2
Bug#956340: ITP: golang-github-scylladb-termtables -- Fork of github.com/apcera/termtables
Package: wnpp Severity: wishlist Owner: Aloïs Micard * Package name: golang-github-scylladb-termtables Version : 0.0~git20191203.c4c0b6d-1 Upstream Author : ScyllaDB * URL : https://github.com/scylladb/termtables * License : Apache-2.0 Programming Lang: Go Description : Fork of github.com/apcera/termtables This package is needed for araddon/dateparse Thank in advance -- Aloïs Micard GPG: DA4A A436 9BFA E299 67CD E85B F733 E871 0859 FCD2
Bug#956331: ITP: jekyll-theme-minima -- beautiful, minimal theme for jekyll
Package: wnpp Severity: wishlist Owner: Daniel Leidert -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: jekyll-theme-minima Version : 2.5.1 Upstream Author : Parker Moore * URL : https://jekyll.github.io/minima/ * License : MIT Programming Lang: HTML/CSS/SASS/Markdown Description : beautiful, minimal theme for jekyll Minima is a one-size-fits-all Jekyll theme for writers. It's Jekyll's default (and first) theme. It's what you get when you run `jekyll new`. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAl6Pwi4ACgkQS80FZ8KW 0F17ZA//W6V/3CTX2UHN5ZdUKvYBVm+bb0DAhCYyuHvd2mPw/CgcAeOFDLrAum4B dssDoaCGUcj4JJ979EAFvcXa8Bkj2Ys0HulYrXaX/qGHhmOHuVGkyYnv7ZgaqEQr yvM/frMyR/+nv2NXib9D9SeD5aoCbXLd8mrXTC4RNDXyuv1i0OlxbFqbXt5dkkUn uhtEgq8jbjELPrcZAVgknybDxLGqLMqJAFl7al1GQgqnqhh45yOJiFAoOZyQihz5 P6SfrvzdUUKnMmnkch0V9eYGEkkqiLjiVsQM5ICqVWE3YpAesYOeSaH8Ok5bsigG H69wiydqsVNRzqyQYlyXCjQac4KObb/SUSXhi7sz41CG1Ioe7Zt3aoMPSdSAbQ5T x7jXOAltfxCJv5qpdTuboXVRMvq2hjbIh1sBVmHY5HVJsP7LDyIdwjphmLa7sDwl X+NnVc74qqbRj9fKpmcl9+4cQ5p9M1xIr96Tsz8ECPAEcqRBKtjSX6hY8Fj8dea6 +43K1Y46A20T6C+M4EfLSZau0fcFjwHJMJtAolVswq32bh8ULvunUPyxNtCveqCU hO0E/hejJlX3Y+H31AjvtPo8YHPXlLjCKMmHjJY3B2AuhQeajZzelkzmNnoaSJCb YWGyxIGtMFfCjCV/1Nn5QV5uzh5Buy04HGWJ33GU8phMek76fUw= =i1Iq -END PGP SIGNATURE-
Work-needing packages report for Apr 10, 2020
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 1212 (new: 9) Total number of packages offered up for adoption: 223 (new: 0) Total number of packages requested help for: 60 (new: 0) Please refer to https://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: alltray (#955982), orphaned 4 days ago Description: Dock any program into the system tray Installations reported by Popcon: 190 Bug Report URL: https://bugs.debian.org/955982 aqemu (#955988), orphaned 4 days ago Description: Qt5 front-end for QEMU and KVM Installations reported by Popcon: 745 Bug Report URL: https://bugs.debian.org/955988 didiwiki (#955989), orphaned 4 days ago Description: simple wiki implementation with built-in webserver Installations reported by Popcon: 36 Bug Report URL: https://bugs.debian.org/955989 gip (#955987), orphaned 4 days ago Description: IP calculator for GNOME desktop environment Installations reported by Popcon: 233 Bug Report URL: https://bugs.debian.org/955987 iptotal (#955986), orphaned 4 days ago Description: monitor for IP traffic, not requiring SNMP Installations reported by Popcon: 40 Bug Report URL: https://bugs.debian.org/955986 kdocker (#955985), orphaned 4 days ago Description: lets you dock any application into the system tray Installations reported by Popcon: 226 Bug Report URL: https://bugs.debian.org/955985 kiki (#955984), orphaned 4 days ago Description: tool for python regular expression testing Installations reported by Popcon: 170 Bug Report URL: https://bugs.debian.org/955984 python-tablib (#955701), orphaned 6 days ago Description: format agnostic tabular dataset library Installations reported by Popcon: 6 Bug Report URL: https://bugs.debian.org/955701 tenshi (#955983), orphaned 4 days ago Description: https://tracker.debian.org/pkg/tenshi Installations reported by Popcon: 14 Bug Report URL: https://bugs.debian.org/955983 1203 older packages have been omitted from this listing, see https://www.debian.org/devel/wnpp/orphaned for a complete list. No new packages have been given up for adoption, but a total of 223 packages are awaiting adoption. See https://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: apache2 (#910917), requested 544 days ago Description: Apache HTTP Server Reverse Depends: apache2 apache2-ssl-dev apache2-suexec-custom apache2-suexec-pristine backuppc courier-webadmin cvsweb debbugs-web dms-wsgi doc-central (136 more omitted) Installations reported by Popcon: 97027 Bug Report URL: https://bugs.debian.org/910917 autopkgtest (#846328), requested 1226 days ago Description: automatic as-installed testing for Debian packages Reverse Depends: debci-worker Installations reported by Popcon: 1173 Bug Report URL: https://bugs.debian.org/846328 balsa (#642906), requested 3119 days ago Description: An e-mail client for GNOME Installations reported by Popcon: 684 Bug Report URL: https://bugs.debian.org/642906 broadcom-sta (#886599), requested 822 days ago (non-free) Description: Broadcom STA Wireless driver (non-free) Installations reported by Popcon: 1792 Bug Report URL: https://bugs.debian.org/886599 cargo (#860116), requested 1094 days ago Description: Rust package manager Reverse Depends: dh-cargo Installations reported by Popcon: 1651 Bug Report URL: https://bugs.debian.org/860116 cyrus-imapd (#921717), requested 426 days ago Description: Cyrus mail system - IMAP support Reverse Depends: cyrus-admin cyrus-caldav cyrus-clients cyrus-dev cyrus-imapd cyrus-murder cyrus-nntpd cyrus-pop3d cyrus-replication Installations reported by Popcon: 443 Bug Report URL: https://bugs.debian.org/921717 cyrus-sasl2 (#799864), requested 1660 days ago Description: authentication abstraction library Reverse Depends: 389-ds-base adcli autofs-ldap cyrus-caldav cyrus-clients cyrus-common cyrus-dev cyrus-imapd cyrus-imspd cyrus-murder (78 more omitted) Installations reported by Popcon: 202163 Bug Report URL: https://bugs.debian.org/799864 dee (#831388), requested 1364 days ago Description: model to synchronize mutiple instances over DBus Reverse Depends: dee-tools gir1.2-dee-1.0 libdee-dev zeitgeist-core Installations reported by Popcon: 32220 Bug Report URL: https://bugs.d
Re: OpenStack release & Debian [was: What to do when DD considers policy to be optional?]
On 2020-04-09 22:27:31 +0200 (+0200), Thomas Goirand wrote: > On 4/9/20 6:09 PM, Jeremy Stanley wrote: [...] > > for example I anticipate an interest in expiring releases > > prior to the current one a bit faster because it will mean not > > having to continue supporting Python 2.7 within the test > > infrastructure for as long. > > What does it mean for let's say Rocky? (which is fully Python 3 in > Debian already)? [...] Very tough to know at this early stage, but the challenge is that while most of the software was tested to work in Python3-only environments over the past 2+ years, there was still a lot of ancillary testing and automation in the CI for those older branches which needed to be overhauled to remove all lingering traces of Python2 use. It will probably boil down to whether anyone is sufficiently motivated to do the work to backport all of that testing and automation uplift to those earlier branches. -- Jeremy Stanley signature.asc Description: PGP signature
Re: OpenStack release & Debian [was: What to do when DD considers policy to be optional?]
On 4/9/20 6:09 PM, Jeremy Stanley wrote: > Yep, at the moment it's running around the 3-year mark where the > community ceases to be able to maintain extensive integration > testing any longer 3 years is already helping a lot. I clearly remember a few Debian release ago that the OpenStack release being in the frozen next Debian went EOL before the Debian final release! > for example I anticipate an interest in expiring releases > prior to the current one a bit faster because it will mean not > having to continue supporting Python 2.7 within the test > infrastructure for as long. What does it mean for let's say Rocky? (which is fully Python 3 in Debian already)? > Some public > providers are basically deploying from master or at least upgrading > to the released versions by/on release day (I'm a happy customer of > one of them and they even use Debian, though I think they're > deploying from source with Ansible so not using the OpenStack > packages you're maintaining). I know who you're talking about! :) The thing is, I also offer the latest release with packages on the day of the OpenStack release, through backports using the packages available on the debian.net domain or with Sid. Though deploying from master still feels a bit crazy to me! > I get that the software is still changing far faster than is > comfortable for LTS GNU/Linux distribution release cadences, and > more recent improvements like support for "fast-forward" upgrades to > get between noncontiguous major releases are only a half measure. It'd be nice if we had the "fast-forward" thing support for at least 5 releases, so we'd get our ass covered for distros like Debian and Ubuntu. But I understand it's probably too much of a technical debt upstream. Being able to "jump" one version is already very nice for all our users (and as I wrote, the Debian OpenStack still keep preciously all OpenStack releases backports to stable for people to upgrade...). > I still hold out hope that as the software matures (it's only 10 years > old now, which is relatively young compared to other ecosystems its > size), things will continue to stabilize and become more viable in > traditional distro packaging realms. I very much think it's the case that OpenStack has matured. At $work however, we still are bit by corner cases. Like recently: unclean live migration lead packets being routed to the wrong compute node, and iSCSI volumes being exported to the wrong compute as well! Lucky, my colleagues are skilled enough and found the way to fix the db (but not the code ... yet!). > The work you're doing to keep > up with it in Debian is massive, and I can't thank you enough for > that. Please do know that it's greatly appreciated! Thanks! :) I'm looking forward for OpenStack Ussuri to be released. I'm already up-to-date with all the artifacts for it uploaded to Experimental! :) Cheers, Thomas Goirand (zigo)
Re: What to do when DD considers policy to be optional? [kubernetes]
On 2020-04-09 09:42:28 +0200 (+0200), Thomas Goirand wrote: [...] > I agree with all what you wrote above. However, there's still no > LTS release in OpenStack, unfortunately. I can support Debian > stable, though I have (understandably) given up on oldstable, yet > even on Debian LTS. Yep, at the moment it's running around the 3-year mark where the community ceases to be able to maintain extensive integration testing any longer (the Ocata release from early 2017 is at the point where it's falling apart now CI-wise). This fluctuates a bit though, for example I anticipate an interest in expiring releases prior to the current one a bit faster because it will mean not having to continue supporting Python 2.7 within the test infrastructure for as long. > Also, it used not to be the way you described. The OpenStack > community has evolved from operators like Rackspace proudly > advertising they deploy from master, to something more reasonable. > It is currently widely accepted that running older releases of > OpenStack is actually OK, and that upgrades aren't easy. [...] I don't think that goal has gone away entirely. Some public providers are basically deploying from master or at least upgrading to the released versions by/on release day (I'm a happy customer of one of them and they even use Debian, though I think they're deploying from source with Ansible so not using the OpenStack packages you're maintaining). On the other hand, upgrades have become far easier for users/operators than they used to be, with most of the deployment automation projects now performing system-wide upgrade tests on every proposed change, stable branch policies limiting what sorts of configuration transitions are allowable between releases, and so on. I get that the software is still changing far faster than is comfortable for LTS GNU/Linux distribution release cadences, and more recent improvements like support for "fast-forward" upgrades to get between noncontiguous major releases are only a half measure. I still hold out hope that as the software matures (it's only 10 years old now, which is relatively young compared to other ecosystems its size), things will continue to stabilize and become more viable in traditional distro packaging realms. The work you're doing to keep up with it in Debian is massive, and I can't thank you enough for that. Please do know that it's greatly appreciated! The Kubernetes community is roughly 5 years behind OpenStack, so they're just now bumping up against the challenges the OpenStack community ran into circa 2015, and much like many of OpenStack's struggles stem from challenges with Python software management, Kubernetes is running into different problems with their choice of programming language. Python was 15-16 years old when OpenStack started, while Golang was only 5-6 years old when Kubernetes began. In some ways this was a benefit to the Kubernetes community as it allowed their work to help shape the language (not to say that OpenStack hasn't had a significant impact on Python as well), but with that also comes the joys of trying to maintain a very large project in a rapidly-evolving language. -- Jeremy Stanley signature.asc Description: PGP signature
Bug#956303: ITP: apkparser -- APK manifest & resources parsing in Golang.
Package: wnpp
Severity: wishlist
Owner: Hans-Christoph Steiner
* Package name: apkparser
Version : 0.0~git20200402.9fd46d5-1
Upstream Author : Avast
* URL : https://github.com/avast/apkparser
* License : LGPL-3.0
Programming Lang: Go
Description : APK manifest & resources parsing in Golang.
apkparser GoDoc (https://godoc.org/github.com/avast/apkparser) Build
Status (https://travis-ci.org/avast/apkparser)
.
APK AndroidManifest.xml and resources.arsc parsing.
.
Works with Go 1.8 or higher.
.
Documentation on GoDoc (https://godoc.org/github.com/avast/apkparser)
go get github.com/avast/apkparser ZipReader Because Android can handle
even broken ZIP archives, this packages has it's own zip reader, based
on archive/zip. axml2xml A tool to extract AndroidManifest.xml
and verify APK signature is also part of this repo. go get
github.com/avast/apkparser go install github.com/avast/apkparser/axml2xml
./axml2xml -v application.apk Example ```go package main
.
import (
"encoding/xml" "fmt" "github.com/avast/apkparser" "os"
)
.
func main() {
enc := xml.NewEncoder(os.Stdout) enc.Indent("", "\t") zipErr, resErr,
manErr := apkparser.ParseApk(os.Args[1], enc) if zipErr != nil {
fmt.Fprintf(os.Stderr, "Failed to open the APK: %s",
zipErr.Error()) os.Exit(1) return
}
if resErr != nil {
fmt.Fprintf(os.Stderr, "Failed to parse resources: %s",
resErr.Error())
} if manErr != nil {
fmt.Fprintf(os.Stderr, "Failed to parse AndroidManifest.xml: %s",
manErr.Error()) os.Exit(1) return
} fmt.Println()
.
} ```
TODO: perhaps reasoning
Re: What to do when DD considers policy to be optional? [kubernetes]
On 4/8/20 11:25 PM, Jeremy Stanley wrote: > On 2020-04-08 22:36:17 +0200 (+0200), Thomas Goirand wrote: > [...] >> Also, the docker world is not the only one to be this way. It used to be >> like this in OpenStack too. In the OpenStack world, they haven't changed >> the way they release (ie: every 6 months), but the user survey has shown >> that almost every user is lagging 4 or 5 versions behind, because >> upgrading the infrastructure is both difficult and time consuming. Over >> time, they became very helpful for back-porting fixes to EOL versions too. >> >> The main issue is that upstream wants to be able to do fast development, >> and focus on the development rather than on their users. Taking care of >> a long term release is time consuming. Taking care of multiple old >> release is very annoying (backporting fixes may not be always obvious). >> >> So yeah, probably upstream will reply with "Debian is stupid". Let them >> say it if they want to: that doesn't make them right. It only shows they >> are completely ignorant of what their users want, and the need of >> downstream distributions. >> >> The more there's going to be users going at them asking them about a 2 >> year old release, the more they will realize that Debian isn't stupid, >> and that this is the way the final users want to consume their work. So >> it's good for us, and beneficial to the project. It's doing our users a >> favor, and it doesn't hurt us. > [...] > > To be fair, the OpenStack community as a whole never suggested it > was stupid for distros to carry older versions of the software (many > folks there have experience packaging for and in LTS GNU/Linux > distributions too, so understand the pain). What was said is that > it's hard to find enough people with sufficient time to maintain > years-old versions of the software, thus the community looks to the > distributions' package maintainers to help shoulder some of that > burden, coordinate with each other on backporting fixes they need to > the versions they're carrying, and so on. What has typically been > laughed off as impractical is suggestions like not developing as > much software so quickly. > > The OpenStack community also doesn't tell users who have questions > about 2+ year old versions of the software to go away until they > upgrade to the bleeding edge. However, it's only natural that if > users ask questions about old tech, they may find that the number of > folks still around who remember how it worked (beyond what's already > in the older versions of the software's documentation) will be > vanishingly small. Jeremy, I agree with all what you wrote above. However, there's still no LTS release in OpenStack, unfortunately. I can support Debian stable, though I have (understandably) given up on oldstable, yet even on Debian LTS. Also, it used not to be the way you described. The OpenStack community has evolved from operators like Rackspace proudly advertising they deploy from master, to something more reasonable. It is currently widely accepted that running older releases of OpenStack is actually OK, and that upgrades aren't easy. I by the way completely understand that the need for more people maintaining older releases of OpenStack (and the CI that goes with it) has never been fixed, and probably never will, unless a big corp like Red Hat puts serious resources on it, which would be the only serious way to maintain an OpenStack LTS. I don't know the Kubernets community, but probably they are facing the same difficulties (ie: the lack of resources to maintain older versions). Cheers, Thomas Goirand (zigo)
Re: What to do when DD considers policy to be optional? [kubernetes]
On 4/8/20 10:58 PM, Michael Stone wrote: > On Wed, Apr 08, 2020 at 10:36:17PM +0200, Thomas Goirand wrote: >> I don't agree with this *at all*. It is not in the interest of our users >> to be forced to update the software they use for their infrastructure >> every few months. > > Isn't that the user's decision, when they decided to adopt a tool that > requires this deployment model? As a distribution, it's our role to give the choice to use the software, without the painful points of the release management choices from upstream. > Or, if they're not clear about what > adopting this tool means, I agree that isn't in their interest for them > to see that there's a debian package and be fooled into thinking it > doesn't require this deployment model just because there's a zombie > package in debian stable which will be essentially unsupported If the package becomes a "zombie package" as you describe, then you're right. Hopefully, that's not the plan! > Putting it into > debian provides zero benefit, and they could get the same "stability" > guarantee by just keeping a copy of a two year old third party .deb and > never updating it. Though hopefully, the Debian package will be updated and fixed for any bug found in Stable, plus security updates. In the OpenStack world, we still find bugs after a year of using a one year old release in production, which I insist fixing (though dealing with the Stable release updates in Debian isn't easy, for reasons outside of the scope of this thread). I expect the same things in the Kubernets world too (both software stack are comparable in many ways). Cheers, Thomas Goirand (zigo)
Re: What to do when DD considers policy to be optional? [kubernetes]
On 09.04.20 08:47, Thomas Goirand wrote: > As a user, I'd prefer Kubernets to be in Stable if possible. I'd be one > of these users who don't care about the latest shiny feature, and prefer > something stable, supported for YEARS to come, not just 3 months. To give a datapoint: Kubernetes as a Service offerings on the market are often already one, two or three major releases behind. Which IMHO serves as a useful datapoint of the "needs of the users"... Once you have a cluster running, there is very little incentive to take it down (which is the exact contrary of why you'd run a cluster in the first place) and upgrade it... so one can expect Kubernetes **in particular** to remain on the same major version once it's running and in production. Note that Kubernetes had major breakages between major releases (deprecated old APIs were removed), which means that upgrading your cluster has high potential to break your deployment. One more reason to stay put with whatever release you're running on. I'm saying all this not as an opinion for or against anything, but just to present datapoints and arguments. *t
