Re: Bug#993936: klogg: Really fast log explorer based on glogg project
Control: reassign -1 wnpp Control: retitle -1 RFP: klogg -- Really fast log explorer based on glogg project On Mi, 08 sep 21, 12:08:32, Daniele Mte90 Scasciafratte wrote: > Package: klogg > Version: 21.09.0.1162 > Severity: wishlist > X-Debbugs-Cc: mte90...@gmail.com > > Klogg is a multi-platform GUI application that helps browse and search > through long and complex log files. It is designed with programmers and > system administrators in mind and can be seen as a graphical, , interactive > combination of grep, less, and tail. > > URL: https://github.com/variar/klogg > > Release automatically debian packages that works on Debian Sid > > -- System Information: > Debian Release: bookworm/sid > APT prefers unstable > APT policy: (500, 'unstable'), (1, 'experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 5.13.14-1-siduction-amd64 (SMP w/4 CPU threads; PREEMPT) > Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_CPU_OUT_OF_SPEC, > TAINT_OOT_MODULE > Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) (ignored: > LC_ALL set to it_IT.UTF-8), LANGUAGE=it > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages klogg depends on: > ii libqt5concurrent5 5.15.2+dfsg-10 > ii libqt5widgets5 5.15.2+dfsg-10 > ii libqt5xml5 5.15.2+dfsg-10 > > klogg recommends no packages. > > klogg suggests no packages. > > -- no debconf information Reassigning to correct (pseudo-)package. Kind regards, Andrei -- Looking after bugs assigned to unknown or inexistent packages signature.asc Description: PGP signature
Re: Bug#993938: git-delta: A viewer for git and diff output
Control: reassign -1 wnpp Control: retitle -1 RFP: git-delta -- A viewer for git and diff output On Mi, 08 sep 21, 12:16:44, Daniele Mte90 Scasciafratte wrote: > Package: git-delta > Version: 0.8.3 > Severity: wishlist > X-Debbugs-Cc: mte90...@gmail.com > > Code evolves, and we all spend time studying diffs. Delta aims to make this > both efficient and enjoyable: it allows you to make extensive changes to the > layout and styling of diffs, as well as allowing you to stay arbitrarily > close to the default git/diff output. > > Other distributions name it git-delta or rust-git-delta. > > URL: https://github.com/dandavison/delta > > -- System Information: > Debian Release: bookworm/sid > APT prefers unstable > APT policy: (500, 'unstable'), (1, 'experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 5.13.14-1-siduction-amd64 (SMP w/4 CPU threads; PREEMPT) > Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_CPU_OUT_OF_SPEC, > TAINT_OOT_MODULE > Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) (ignored: > LC_ALL set to it_IT.UTF-8), LANGUAGE=it > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages git-delta depends on: > ii libc6 2.32-2 > ii libgcc-s1 11.2.0-4 > ii zlib1g 1:1.2.11.dfsg-2 > > git-delta recommends no packages. > > git-delta suggests no packages. > > -- no debconf information Reassigning to correct (pseudo-)package. Kind regards, Andrei -- Looking after bugs assigned to unknown or inexistent packages signature.asc Description: PGP signature
Re: Bug#993938: git-delta: A viewer for git and diff output
Hi, Le 2021-10-19 11:49, Andrei POPESCU a écrit : > Control: reassign -1 wnpp > Control: retitle -1 RFP: git-delta -- A viewer for git and diff output > > On Mi, 08 sep 21, 12:16:44, Daniele Mte90 Scasciafratte wrote: > > Package: git-delta > > Version: 0.8.3 > > Severity: wishlist > > X-Debbugs-Cc: mte90...@gmail.com > > > > Code evolves, and we all spend time studying diffs. Delta aims to make this > > both efficient and enjoyable: it allows you to make extensive changes to > > the layout and styling of diffs, as well as allowing you to stay > > arbitrarily close to the default git/diff output. > > > > Other distributions name it git-delta or rust-git-delta. > > > > URL: https://github.com/dandavison/delta > > > > -- System Information: > > Debian Release: bookworm/sid > > APT prefers unstable > > APT policy: (500, 'unstable'), (1, 'experimental') > > Architecture: amd64 (x86_64) > > Foreign Architectures: i386 > > > > Kernel: Linux 5.13.14-1-siduction-amd64 (SMP w/4 CPU threads; PREEMPT) > > Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_CPU_OUT_OF_SPEC, > > TAINT_OOT_MODULE > > Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) (ignored: > > LC_ALL set to it_IT.UTF-8), LANGUAGE=it > > Shell: /bin/sh linked to /bin/dash > > Init: systemd (via /run/systemd/system) > > LSM: AppArmor: enabled > > > > Versions of packages git-delta depends on: > > ii libc6 2.32-2 > > ii libgcc-s1 11.2.0-4 > > ii zlib1g 1:1.2.11.dfsg-2 > > > > git-delta recommends no packages. > > > > git-delta suggests no packages. > > > > -- no debconf information > > Reassigning to correct (pseudo-)package. Closing since an ITP¹ already exists for Delta. Cheers, Vincent ¹ https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944028 signature.asc Description: PGP signature
Re: Debian's branches and release model
> > https://wiki.debian.org/ReleaseProposals > Great list, contains a lot of what I have to say. The fact that debian is laser focused on stable, and does not officially encourage using testing as a rolling release (as evidenced from a couple replies to this email chain), yet there are still people doing it, is a testament of how good debian is. Just don't abandon us:) If testing is part of QA, then popularizing it should benefit. Staying closer to upstream releases gets my vote. Quote from the page, "Looks like it's time for action! Somebody (maybe the Debian project leader) should pick up the hot potato and compile a list of the proposals which are going to be adopted. Flame wars ensue. Then Debian emerges renewed, as a phoenix from the ashes." cheers, P
Bug#996850: ITP: rhsrvany -- Windows tools used by virt-v2v
Package: wnpp Severity: wishlist Owner: Ryan Pavlik X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: rhsrvany Version : 0.20210127 Upstream Author : Richard W.M. Jones, Red Hat Inc. * URL : https://github.com/rwmjones/rhsrvany * License : GPL-2+ Programming Lang: C Description : Windows tools used by virt-v2v This package contains open-source replacements for proprietary Windows tools, SrvAny (RHSrvAny) and pnp_wait. They are used by the virt-v2v tool when converting Windows virtual machines. This is required for virt-v2v (see https://bugs.debian.org/962293) which was formerly part of libguestfs in Buster and now the subject of its own RFP bug linked above. The draft of that package is in the libvirt team, and if this package is accepted, I'd anticipate joining that team for team maintenance and sponsorship. The code itself is quite stable, with a limited purpose and having seen little need for changes in the past several years, so I anticipate packaging maintenance load to be low. OpenPGP_signature Description: OpenPGP digital signature
Bug#996865: ITP: jheaps -- Java library with various heap implementations
Package: wnpp Severity: wishlist Owner: Debian-java team X-Debbugs-Cc: debian-devel@lists.debian.org, debian-j...@lists.debian.org * Package name: jheaps Version : 0.14 Upstream Author : Dimitrios Michail * URL : https://github.com/d-michail/jheaps * License : Apache-2.0 Programming Lang: Java Description : Java library with various heap implementations This library contains various heap implementations written in Java. A heap is a priority queue data type which contains elements with keys (duplicate keys are permitted) from a totally-ordered universe. The library is easy to use, its data structures have a well defined interface, it is fast and well documented, and the heaps are written in a similar way as in the JDK. jheaps is needed as a dependency of JGraphT, which will also soon be packaged as a dependency of biojava5-live, needed in Debian-med activities. JGraphtT will also be a nice addition to scientific software in Debian-science. The package will be team-maintained in the Debian-java team.
Re: Debian's branches and release model
Hi Simon, For me, the long freeze are very problematic. They may spawn for 6 months, which is how long it takes for a new OpenStack release to show up, and then I don't know where to upload it... :/ As a result, the Wallaby release of OpenStack (released last spring) never had the time to migrate fully to testing, for example, because I uploaded Xena (released last October). Anyways, here's my reply inline below... On 10/18/21 6:54 PM, Simon McVittie wrote: > It > also aligns the incentives for enough people to make sure that we can > successfully make a release in a finite time - even developers who > don't really care about releases and just want the latest versions > are incentivized to fix enough things to make the next release happen, > so that the freeze will end and they can get back to uploading the > latest versions to unstable. I don't know how you can make sure that using testing-proposed-updates instead of unstable would suddenly demotivate everyone that cares about about next stable. Could you explain? On 10/18/21 6:54 PM, Simon McVittie wrote: > However, the problem with freezing testing but not freezing unstable is > that if you do that, all updates to testing during the freeze (to fix the > release-critical bugs that stop it from already being ready for release) > have to go into testing via testing-proposed-updates, which approximately > nobody uses. We don't use it, because we're told to use unstable... If we were told that it's ok to upload changes to unstable during the freeze, and upload to testing-proposed-updates, we'd do it (and IMO, it'd be a very good move from the release team). > Having code changes for our next stable release be essentially untested > is not great from a QA perspective - if nobody is trying out those new > versions except for their maintainer, then nobody can find and report the > (potentially serious) bugs that only happen in system configurations that > differ from the maintainer's system. That's why the release team strongly > discourages packages going into testing via testing-proposed-updates, and > encourages packages going into testing via unstable. If we were, during the freeze, directed to upload fixes to testing-proposed-updates, then there would be more people adding it to their sources.list during the freeze. Cheers, Thomas Goirand (zigo)
Re: Debian's branches and release model
Hello, Am 20.10.21 um 02:43 schrieb Thomas Goirand: > Hi Simon, > > For me, the long freeze are very problematic. They may spawn for 6 > months, which is how long it takes for a new OpenStack release to show > up, and then I don't know where to upload it... :/ You can upload it to experimental > > As a result, the Wallaby release of OpenStack (released last spring) > never had the time to migrate fully to testing, for example, because I > uploaded Xena (released last October). > > Anyways, here's my reply inline below... > > On 10/18/21 6:54 PM, Simon McVittie wrote: >> It >> also aligns the incentives for enough people to make sure that we can >> successfully make a release in a finite time - even developers who >> don't really care about releases and just want the latest versions >> are incentivized to fix enough things to make the next release happen, >> so that the freeze will end and they can get back to uploading the >> latest versions to unstable. > > I don't know how you can make sure that using testing-proposed-updates > instead of unstable would suddenly demotivate everyone that cares about > about next stable. Could you explain? > > On 10/18/21 6:54 PM, Simon McVittie wrote: >> However, the problem with freezing testing but not freezing unstable is >> that if you do that, all updates to testing during the freeze (to fix the >> release-critical bugs that stop it from already being ready for release) >> have to go into testing via testing-proposed-updates, which approximately >> nobody uses. > > We don't use it, because we're told to use unstable... > > If we were told that it's ok to upload changes to unstable during the > freeze, and upload to testing-proposed-updates, we'd do it (and IMO, > it'd be a very good move from the release team). > >> Having code changes for our next stable release be essentially untested >> is not great from a QA perspective - if nobody is trying out those new >> versions except for their maintainer, then nobody can find and report the >> (potentially serious) bugs that only happen in system configurations that >> differ from the maintainer's system. That's why the release team strongly >> discourages packages going into testing via testing-proposed-updates, and >> encourages packages going into testing via unstable. > > If we were, during the freeze, directed to upload fixes to > testing-proposed-updates, then there would be more people adding it to > their sources.list during the freeze. > > Cheers, > > Thomas Goirand (zigo) > -- Mechtilde Stehmann ## Debian Developer ## PGP encryption welcome ## F0E3 7F3D C87A 4998 2899 39E7 F287 7BBA 141A AD7F
Re: Debian's branches and release model
On Wed, Oct 20, 2021 at 02:43:47AM +0200, Thomas Goirand wrote: > > However, the problem with freezing testing but not freezing unstable is > > that if you do that, all updates to testing during the freeze (to fix the > > release-critical bugs that stop it from already being ready for release) > > have to go into testing via testing-proposed-updates, which approximately > > nobody uses. > > We don't use it, because we're told to use unstable... It's about using on machines, not about uploading. > If we were told that it's ok to upload changes to unstable during the > freeze, and upload to testing-proposed-updates, we'd do it (and IMO, > it'd be a very good move from the release team). The RT position on this was always "nobody uses t-p-u it so please no", as repeated every freeze when someone asks why we don't do this. -- WBR, wRAR signature.asc Description: PGP signature
