Bug#904066: ITP: python-openidc-client -- A Python OpenID Connect client with token caching and management
Package: wnpp Severity: wishlist Owner: Sergio Durigan Junior * Package name: python-openidc-client Version : 0.6.0 Upstream Author : Patrick Uiterwijk * URL : https://github.com/puiterwijk/python-openidc-client * License : Expat Programming Lang: Python Description : A Python OpenID Connect client with token caching and management This package is a simple Python OpenID Connect client library with token caching and management. I will maintain this package with the DPMT. -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/ signature.asc Description: PGP signature
Re: Bug#903438: RFA: asciinema -- Record and share your terminal sessions, the right way
Fwiw asciinema is quite handy! We use it for our demos (generate them automatically from our *cast scripts, along with possible narrated videos, actual scripts, or just interactive demonstrations where people get blown away at "my" typing speed/stability), see eg those asciinemas at http://datalad.org/for/reproducible-science So I would appreciate if someone takes care about this valuable package... if there would be nobody, please buzz me, I will keep it afloat Cheers On July 18, 2018 7:48:56 PM EDT, gustavo panizzo wrote: >Hi >On Thu, Jul 19, 2018 at 12:06:58AM +0200, Hilmar Preuße wrote: >>Am 18.07.2018 um 21:55 teilte gustavo panizzo mit: >> >>Hi Gustavo, >> >>>Forget screen recording apps and blurry video. Enjoy a lightweight, >>>purely text based approach to terminal recording. >>>This package provides a command line recorder for asciinema.org >>>service or other instance of asciinema server. >>> >>At first the dumb question: what main features does this application >>have, I can't find in script [1]? Well, except the upload feature. > >the playback always works, this was my motivation to use (and package) >asciinema, since it does not depend on what console do you use to play >it back it always works (and people with windows can play the >recordings) >when i started with it, we used asciinema and an internal server to >record trainings and play them back to students > > >but i changed jobs and stop using it some time ago, that's why RFA >> >>Thanks! >> >>H. >> >>[1] http://man.openbsd.org/script.1 >>-- >>#206401 http://counter.li.org -- Sent from a phone which beats iPhone.
Re: Bug#903438: RFA: asciinema -- Record and share your terminal sessions, the right way
Am 18.07.2018 um 21:55 teilte gustavo panizzo mit: Hi Gustavo, Forget screen recording apps and blurry video. Enjoy a lightweight, purely text based approach to terminal recording. This package provides a command line recorder for asciinema.org service or other instance of asciinema server. At first the dumb question: what main features does this application have, I can't find in script [1]? Well, except the upload feature. Thanks! H. [1] http://man.openbsd.org/script.1 -- #206401 http://counter.li.org
Bug#904054: ITP: cccolutils -- Python Kerberos Credential Cache Collection Utilities
Package: wnpp Severity: wishlist Owner: Sergio Durigan Junior * Package name: cccolutils Version : 1.4 Upstream Author : https://pagure.io/cccolutils * URL : Patrick Uiterwijk * License : GPL-2+ Programming Lang: Python Description : Python Kerberos Credential Cache Collection Utilities This module provides Kerberos 5 credential cache collection utilities for Python 2.6+ and 3. . When a user authenticates to a Kerberos realm (eg. with kinit), the user has a short-lived credential in a cache (view it with klist). . You can use this cccolutils module to easily determine if the user has any valid Kerberos credentials, or what the username is for a particular Kerberos realm. I will maintain this package with the DPMT. -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/ signature.asc Description: PGP signature
Re: Bug#903438: RFA: asciinema -- Record and share your terminal sessions, the right way
Hello Python Applications Packaging team! I've submitted an RFA for the asciinema package, which is a pure python application, maybe someone from the PAP team wants to carry over. I'll be around to answer questions. Package has no open bugs, latest upstream release has been packaged and uploaded. Packaging is maintained in salsa.debian.org Upstream is helpful, I'd recommend to subscribe to https://github.com/asciinema/asciinema/issues/116 if you plan to maintain the package I no longer use the package, that's why i'm RFAing it Package description: Forget screen recording apps and blurry video. Enjoy a lightweight, purely text based approach to terminal recording. This package provides a command line recorder for asciinema.org service or other instance of asciinema server. thanks! PS: i'm not subscribed to this list, please CC me in answers -- IRC: gfa GPG: 0X44BB1BA79F6C6333
Re: pyacoustid: upstream update and various packaging improvements
Hi Lars
On 2018-07-16 01:25:37, Lars Kruse wrote:
> Hello,
>
> I am a member of the DPMT, but no DD or DM.
> This is supposed to be my first package upload within the DPMT, thus please be
> patient, in case I misunderstand the procedure.
>
> My proposed changes of the package include the following:
> * migrate from git-dpm to gbp
> * update upstream (closing all open bugs)
> * add initial autopkgtests
> * updates of policy version and compat level
>
> I prepared a merge request with my changes:
> https://salsa.debian.org/python-team/modules/pyacoustid/merge_requests/1
>
> The git-dpm migration requires a branch renaming ("master" ->
> "debian/master").
> The upstream update requires an update of the upstream branch.
> Thus the merge request is not fully self-contained. See my forked repository
> for
> the complete updated environment:
> https://salsa.debian.org/sumpfralle-guest/pyacoustid/
>
> I am not sure, how to proceed now, but I could imagine the following steps:
> 1) someone takes the time to review my changes (maybe followed by fixes from
> me)
> 2) I push my changes (including a debian/??? version tag) to the
>packaging repository within DPMT (and delete my forked repository)
> 3) the reviewer sponsors the upload of the package
>
> I am looking forward to your comments or reviews.
Thanks for taking care of pyacoustid. I'm no longer active in the Python teams,
but as long as you follow their best practices, it should be easy enough to find
a sponsor on the Python mailing list (or via sponsorhip-requests).
Cheers
--
Sebastian Ramacher
signature.asc
Description: PGP signature
Re: kivy package in trouble?
On July 18, 2018 1:00:15 PM UTC, Dean Serenevy wrote: > >Hello, I am a user of the python3-kivy package and just noticed that >kivy is no longer listed in buster [1]. > >Is help needed? (I am not a DD, but I am willing to test and submit >packaging patches if it would help.) > > >[1] https://packages.debian.org/search?keywords=python3-kivy This is the bug that needs fixing to get it back in: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=873501 If you can submit a solution, that would help. Scott K
Re: kivy package in trouble?
[Dean Serenevy, 2018-07-18] > Hello, I am a user of the python3-kivy package and just noticed that > kivy is no longer listed in buster [1]. > > Is help needed? (I am not a DD, but I am willing to test and submit > packaging patches if it would help.) tracker¹ points to bug #873501² (FTBFS with cython 0.26) [¹] https://tracker.debian.org/pkg/kivy [²] https://bugs.debian.org/873501 -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: kivy package in trouble?
On Wed, Jul 18, 2018 at 09:00:15AM -0400, Dean Serenevy wrote: > Hello, I am a user of the python3-kivy package and just noticed that kivy is > no longer listed in buster [1]. > > Is help needed? (I am not a DD, but I am willing to test and submit packaging > patches if it would help.) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=873501 -- WBR, wRAR signature.asc Description: PGP signature
kivy package in trouble?
Hello, I am a user of the python3-kivy package and just noticed that kivy is no longer listed in buster [1]. Is help needed? (I am not a DD, but I am willing to test and submit packaging patches if it would help.) [1] https://packages.debian.org/search?keywords=python3-kivy signature.asc Description: OpenPGP digital signature
python3-pyvcf: python-module-in-wrong-location usr/lib/python3.7/dist-packages/vcf/ usr/lib/python3/dist-packages/vcf/
Hi, I intend to update python-pyvcf and have prepared this on Salsa[1]. The package builds but I get: python3-pyvcf: python-module-in-wrong-location usr/lib/python3.7/dist-packages/vcf/ usr/lib/python3/dist-packages/vcf/ ... dh_python3 can be used to fix this for Python 3 modules. I can confirm from the log that dh_python3 is run. I never experienced this kind of misplaced files. Thus before I do some manual copying I'd like to ask here what I might possibly do wrong. Kind regards Andreas. [1] https://salsa.debian.org/med-team/python-pyvcf -- http://fam-tille.de
Re: Safest way to set python3 as default for `python`
Ben Finney wrote: > To have a command with custom behaviour, the recommendation is the > general one: put an executable file at ‘/usr/local/bin/python’ with > whatever behaviour you want. eeek, please don't! If a user created an incompatible /usr/local/bin/rm (didn't delete files, didn't exit 0), that would break a lot of tools and we'd tell the user not to do that. Fortunately, users don't tend to. /usr/local/bin/python is no different but for some reason users feel they can meddle with it. Do not put locally versions of system tools like 'python' in root's PATH (or indeed in any user's PATH if the user expects to be able to run packaged tools). Doing so ends up potentially breaking packaged modules (they can find the wrong versions of dependencies in /usr/local since that is also in sys.path), and packaged applications (broken modules plus perhaps now running with the wrong version of the interpreter which is either incompatible or doesn't have the necessary modules installed). There's a reasonable number of things in /usr/bin with "#!/usr/bin/env python" that would be unhappy with this configuration. We have lots of experience of this sort of breakage in #debian, where we see the this breaking maintainer scripts or packaged tools. As soon as we see a python backtrace with /usr/local in it, we know that is going to be the problem and expunging the local python installation from /usr/local is what is needed. Putting python in other places such as /opt or ~/.local would be fine; even better still is to use one of the many virtualenv approaches so you're not even leaking that incompatible interpreter into a user's default environment. (see also: please don't run pip as root) cheers Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
