Bug#854682: RFS: pytest-xvfb/1.0.0-1 [ITP]
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "pytest-xvfb": * Package name: pytest-xvfb Version : 1.0.0-1 Upstream Author : Florian Bruhin * URL : https://github.com/The-Compiler/pytest-xvfb/ * License : Expat Programming Lang: Python It builds those binary packages: python3-pytest-xvfb - pytest plugin to run Xvfb for tests To access further information about this package, please visit the packaging repository URL: https://anonscm.debian.org/git/python-modules/packages/pytest-xvfb.git This package was successfully built on debomatic: http://debomatic-amd64.debian.net/distribution#unstable/pytest-xvfb/1.0.0-1/ Changes since the last upload: * Initial release. (Closes: #854673) Regards, Ghis -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (900, 'testing'), (300, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)
On Feb 07 2017, Barry Warsaw wrote: > On Feb 07, 2017, at 10:47 AM, Ghislain Vaillant wrote: > >>I know the discussion is leaning towards replacing usage of git-dpm >>with gbp-pq. I have nothing against it but, since we are talking about >>solutions for a git-centric workflow, has anyone considered the dgit- >>maint-merge workflow [1]? > > As I understand it, there are a few design choices that make dgit less > desirable for this team. No. You are confusing dgit with one particular way to use it. You can use dgit with the maint-merge workflow mentioned above, you can use dgit with git-dpm, and you can use dgit with gbp. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.«
Naming convention for -doc package
Just to get the opinion from the team, Now that new packages are targeting the Buster cycle, and that Python 2 packages should no longer be built, how should the corresponding -doc packages be named? For instance, I have a source package (pytest-qt) which builds a Python 3 binary package and its corresponding documentation. Right now, they are respectively named python3-pytest-qt and pytest-qt-doc. Shall we keep the current python- prefix (as per Python the language, not Python 2 the version), use a python3- prefix, or drop the prefix (as I temporarily did)? Thought I'd better ask than be sorry later. Cheers, Ghis
Re: Naming convention for -doc package
On Thu, Feb 9, 2017 at 3:17 PM, Ghislain Vaillant wrote: > Now that new packages are targeting the Buster cycle, and that Python 2 > packages should no longer be built, this is news to me, can you point me to where this was announced? -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi G+: https://plus.google.com/u/0/+SandroTosi
Re: Naming convention for -doc package
On Thu, 2017-02-09 at 16:51 -0500, Sandro Tosi wrote: > On Thu, Feb 9, 2017 at 3:17 PM, Ghislain Vaillant wrote: > > Now that new packages are targeting the Buster cycle, and that Python 2 > > packages should no longer be built, > > this is news to me, can you point me to where this was announced? Announced, I don't know. But: https://lintian.debian.org/tags/new-package-should-not-package-python2-module.html Unless I am missing something?
Re: Naming convention for -doc package
On Thu, Feb 9, 2017 at 5:40 PM, Ghislain Vaillant wrote: > On Thu, 2017-02-09 at 16:51 -0500, Sandro Tosi wrote: >> On Thu, Feb 9, 2017 at 3:17 PM, Ghislain Vaillant wrote: >> > Now that new packages are targeting the Buster cycle, and that Python 2 >> > packages should no longer be built, >> >> this is news to me, can you point me to where this was announced? > > Announced, I don't know. But: > > https://lintian.debian.org/tags/new-package-should-not-package-python2-module.html > > Unless I am missing something? this was triggered by https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829744 -- sigh -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi G+: https://plus.google.com/u/0/+SandroTosi
Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)
On February 9, 2017 10:52:04 AM PST, Nikolaus Rath wrote: >On Feb 07 2017, Barry Warsaw wrote: >> On Feb 07, 2017, at 10:47 AM, Ghislain Vaillant wrote: >> >>>I know the discussion is leaning towards replacing usage of git-dpm >>>with gbp-pq. I have nothing against it but, since we are talking >about >>>solutions for a git-centric workflow, has anyone considered the dgit- >>>maint-merge workflow [1]? >> >> As I understand it, there are a few design choices that make dgit >less >> desirable for this team. > >No. You are confusing dgit with one particular way to use it. You can >use dgit with the maint-merge workflow mentioned above, you can use >dgit >with git-dpm, and you can use dgit with gbp. OK. So then I gather it's effectively a layer on top of 'normal' things like gbp-pq or git-dpm? What added value would it provide? Scott K
Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)
On Feb 10 2017, Scott Kitterman wrote: >>No. You are confusing dgit with one particular way to use it. You can >>use dgit with the maint-merge workflow mentioned above, you can use >>dgit >>with git-dpm, and you can use dgit with gbp. > > OK. So then I gather it's effectively a layer on top of 'normal' > things like gbp-pq or git-dpm? What added value would it provide? Among other things, it enables users to run 'dgit clone', and get an up-to-date, patches-applied copy of the most recent source package. But it seems to me that you are contemplating whether or not the team should be using dgit. This is also not a decision that needs to be made prior to any switch away from dgit-dpm, you can start using dgit at any point. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.«
Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)
On February 9, 2017 8:29:32 PM PST, Nikolaus Rath wrote: >On Feb 10 2017, Scott Kitterman wrote: >>>No. You are confusing dgit with one particular way to use it. You can >>>use dgit with the maint-merge workflow mentioned above, you can use >>>dgit >>>with git-dpm, and you can use dgit with gbp. >> >> OK. So then I gather it's effectively a layer on top of 'normal' >> things like gbp-pq or git-dpm? What added value would it provide? > >Among other things, it enables users to run 'dgit clone', and get an >up-to-date, patches-applied copy of the most recent source package. How is that different/better than debcheckout? >But it seems to me that you are contemplating whether or not the team >should be using dgit. This is also not a decision that needs to be made >prior to any switch away from dgit-dpm, you can start using dgit at any >point. OK. Scott K
