Bug#970744: ben: please provide machine-parseable version of transition status
clone 970744 -1 retitle 970744 ben traker: please support multiple outputs retitle -1 ben: please provide richer JSON output tags -1 + moreinfo thanks Le 26/09/2020 à 10:37, Stéphane Glondu a écrit : > Yes. There are two tasks here, which I think are independent: > > 1. extend `ben tracker` with --outputs a,b,... for all supported (or a >selected subset of) outputs of `ben monitor` I've eventually implemented a new parameter in the global configuration file, "output-formats", a list of wanted formats, among "html", "txt", "json" and "levels" for the moment. > 2. enrich JSON output with "the other fields" I've cloned this bug to handle this. Cheers, -- Stéphane
Bug#970744: ben: please provide machine-parseable version of transition status
Le 25/09/2020 à 22:55, Sebastian Ramacher a écrit : >> I just realized there is already a JSON output, made by Mehdi in 2015... >> maybe it could suit your needs? > > If I'm not missing a switch somewhere, the JSON output can only be used > with `ben monitor`, right? Indeed, HTML output seems hard-coded in `ben tracker`. > Could that somehow be integrated into `ben > tracker` and extended with the other fields? Yes. There are two tasks here, which I think are independent: 1. extend `ben tracker` with --outputs a,b,... for all supported (or a selected subset of) outputs of `ben monitor` 2. enrich JSON output with "the other fields" I can do both. It will take more time than I expected, though. Cheers, -- Stéphane
Bug#970744: ben: please provide machine-parseable version of transition status
On 2020-09-24 15:39:30 +0200, Stéphane Glondu wrote: > Le 23/09/2020 à 20:52, Sebastian Ramacher a écrit : > >>> thanks for maintaining ben. In additiona to the HTML output, it would be > >>> great to have the same information as machine-parseable file. With such > >>> a file one could feed other tools to further process the info produced > >>> by ben, e.g., to produce a list of binNMUs. > >> > >> Did you know that there were a text output? Probably not what you mean > >> by "machine-parseable", but maybe easier to parse than the HTML output. > > > > No, I didn't. I work with the HTML output on release.debian.org most of > > the time. > > I just realized there is already a JSON output, made by Mehdi in 2015... > maybe it could suit your needs? If I'm not missing a switch somewhere, the JSON output can only be used with `ben monitor`, right? Could that somehow be integrated into `ben tracker` and extended with the other fields? Cheers -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#970744: ben: please provide machine-parseable version of transition status
Le 23/09/2020 à 20:52, Sebastian Ramacher a écrit : >>> thanks for maintaining ben. In additiona to the HTML output, it would be >>> great to have the same information as machine-parseable file. With such >>> a file one could feed other tools to further process the info produced >>> by ben, e.g., to produce a list of binNMUs. >> >> Did you know that there were a text output? Probably not what you mean >> by "machine-parseable", but maybe easier to parse than the HTML output. > > No, I didn't. I work with the HTML output on release.debian.org most of > the time. I just realized there is already a JSON output, made by Mehdi in 2015... maybe it could suit your needs? Cheers, -- Stéphane
Bug#970744: ben: please provide machine-parseable version of transition status
On 2020-09-23 20:52:03 +0200, Sebastian Ramacher wrote: > Hi Stéphane > > On 2020-09-23 09:42:27 +0200, Stéphane Glondu wrote: > > Le 22/09/2020 à 22:12, Sebastian Ramacher a écrit : > > > thanks for maintaining ben. In additiona to the HTML output, it would be > > > great to have the same information as machine-parseable file. With such > > > a file one could feed other tools to further process the info produced > > > by ben, e.g., to produce a list of binNMUs. > > > > Did you know that there were a text output? Probably not what you mean > > by "machine-parseable", but maybe easier to parse than the HTML output. > > No, I didn't. I work with the HTML output on release.debian.org most of > the time. > > > I'm willing to implement another output format. What would you like? > > Could you provide an example? > > A YAML file with a list of the packages including versions, their > dependency lievel, and the state on the architectures would suffice. > Additionally, info on whether they are only in sid and if they produce > MA: same binaries would be helpful. > > It could look like the following: > > packages: > - dependency_level: 3 > ma_same: true > package: vlc > sid_only: false > state: > amd64: good > arm64: partial > i386: bad > version: 3.0.11.1-2 > - dependency_level: 2 > ma_same: false > package: ffmpeg > sid_only: true > state: > amd64: good > arm64: good > armel: good > armhf: good > i386: good > mips64el: bad > mipsel: partial > ppc64el: good > s390x: good > version: 7:4.3.1-3 > transition: auto-test Oh, and also a flag for Architecture: all packages (e.g., arch_all: true or false). Cheers > > Architectures were the sate is unknown could be skipped. Thanks for > considering. > > Cheers > -- > Sebastian Ramacher -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#970744: ben: please provide machine-parseable version of transition status
Hi Stéphane On 2020-09-23 09:42:27 +0200, Stéphane Glondu wrote: > Le 22/09/2020 à 22:12, Sebastian Ramacher a écrit : > > thanks for maintaining ben. In additiona to the HTML output, it would be > > great to have the same information as machine-parseable file. With such > > a file one could feed other tools to further process the info produced > > by ben, e.g., to produce a list of binNMUs. > > Did you know that there were a text output? Probably not what you mean > by "machine-parseable", but maybe easier to parse than the HTML output. No, I didn't. I work with the HTML output on release.debian.org most of the time. > I'm willing to implement another output format. What would you like? > Could you provide an example? A YAML file with a list of the packages including versions, their dependency lievel, and the state on the architectures would suffice. Additionally, info on whether they are only in sid and if they produce MA: same binaries would be helpful. It could look like the following: packages: - dependency_level: 3 ma_same: true package: vlc sid_only: false state: amd64: good arm64: partial i386: bad version: 3.0.11.1-2 - dependency_level: 2 ma_same: false package: ffmpeg sid_only: true state: amd64: good arm64: good armel: good armhf: good i386: good mips64el: bad mipsel: partial ppc64el: good s390x: good version: 7:4.3.1-3 transition: auto-test Architectures were the sate is unknown could be skipped. Thanks for considering. Cheers -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#970744: ben: please provide machine-parseable version of transition status
Le 22/09/2020 à 22:12, Sebastian Ramacher a écrit : > thanks for maintaining ben. In additiona to the HTML output, it would be > great to have the same information as machine-parseable file. With such > a file one could feed other tools to further process the info produced > by ben, e.g., to produce a list of binNMUs. Did you know that there were a text output? Probably not what you mean by "machine-parseable", but maybe easier to parse than the HTML output. I'm willing to implement another output format. What would you like? Could you provide an example? Cheers, -- Stéphane
Bug#970744: ben: please provide machine-parseable version of transition status
Package: ben Version: 0.9.0 Severity: wishlist Hi, thanks for maintaining ben. In additiona to the HTML output, it would be great to have the same information as machine-parseable file. With such a file one could feed other tools to further process the info produced by ben, e.g., to produce a list of binNMUs. Cheers -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (650, 'unstable-debug'), (650, 'unstable'), (601, 'testing'), (600, 'experimental-debug'), (600, 'buildd-unstable'), (600, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.8.0-1-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages ben depends on: ii bzip2 1.0.8-4 ii curl7.72.0-1 ii libben-ocaml [libben-ocaml-dvwl1] 0.9.0+b8 ii libc6 2.31-3 ii libjs-jquery3.5.1+dfsg-4 ii libpcre32:8.39-13 ii libpq5 12.4-1 ii libtyxml-ocaml [libtyxml-ocaml-vbzd5] 4.4.0-1 ii ocaml-base-nox [ocaml-base-nox-4.08.1] 4.08.1-10 Versions of packages ben recommends: ii dose-distcheck 5.0.1-15+b1 Versions of packages ben suggests: ii python3-yaml 5.3.1-2 -- no debconf information -- Sebastian Ramacher signature.asc Description: PGP signature
