Re: Team maintained packages and git-dpm (was Re: Team upload for python-jedi)
On January 22, 2017 8:11:26 PM EST, Nikolaus Rath wrote: >On Jan 23 2017, Brian May wrote: >[ Convert from git-dpm to gbp ] >> Or would dgit be a better option? I confuse I don't really understand >> dgit. > >dgit can be used with both git-dpm and gbp. Moving to dgit-only would >mean to use a single-debian-patch. Which would be horrible. single-debian-patch means that to understand the upstream modifications, access to the packaging VCS is required. I think that would be a huge step backwards. Downstream consumers of our packages, like the security team and derivatives, should be able to consume the source package as a complete, non-obfuscated representation of the source. I'm not sure it's even DFSG free since it's not the preferred form of modification for the packaging (we need to ship source for that too). This is not saying we shouldn't change. We probably either need to adopt git-dpm or switch to something else. Let's just make sure it's not something that uses single-debian-patch. Scott K
Re: Team maintained packages and git-dpm (was Re: Team upload for python-jedi)
On Jan 23 2017, Brian May wrote: > I don't particular care what we move to, however it seems to me that we > really should be dropping git-dpm. I think git-dpm works very nice as long as the package doesn't get too complex. I think it would be overreaction to convert all packages, just because git-dpm is unsuitable for some of them. 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: Team maintained packages and git-dpm (was Re: Team upload for python-jedi)
On Jan 23 2017, Brian May wrote: [ Convert from git-dpm to gbp ] > Or would dgit be a better option? I confuse I don't really understand > dgit. dgit can be used with both git-dpm and gbp. Moving to dgit-only would mean to use a single-debian-patch. 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: Team maintained packages and git-dpm (was Re: Team upload for python-jedi)
Barry Warsaw writes: > We've talked about eventually dropping git-dpm and just using gbp (with gbp-pq > for patch management). There are some packages (I won't mention names) that have already started doing this. Would it be worth creating a concrete proposal to phase out usage of git-dpm in favour of gbp-pq? e.g. leave packages as-is, however on next update remove the debian/.git-dpm config file and unapply all patches. This could also wait until after the stretch release, however not sure if that matters. Or would dgit be a better option? I confuse I don't really understand dgit. I don't particular care what we move to, however it seems to me that we really should be dropping git-dpm. -- Brian May
Team maintained packages and git-dpm (was Re: Team upload for python-jedi)
On Jan 22, 2017, at 03:00 PM, Dmitry Shachnev wrote: >On Sat, Jan 21, 2017 at 11:54:13AM +, Ghislain Vaillant wrote: >> "Drop DPMT from Uploaders (due to problems with multiple tarballs in >> git-dpm)" >> >> Then, the package is no longer team-maintained? > >Personally I think we could allow such packages to remain in team, even if >they are not able to use git-dpm. In the past, we've discussed the status of git-dpm and team maintained packages. I believe I'm accurate in saying: * git-dpm is no longer actively maintained * even so, in the majority of cases it Just Works for us The main thing that git-dpm gives us is patch management with usually good enough integration with quilt. FWIW, I use straight-up gbp for most of my actual package building tasks, but I use git-dpm for pulling in a new upstream, managing patches, and tagging. We've talked about eventually dropping git-dpm and just using gbp (with gbp-pq for patch management). I think the fact that git-dpm pretty much works fine in most cases reduces the pressure to drop it. And it is true that we want consistency across the team packages so that we can document how you maintain them in one place (e.g. the wiki[1]), and there's no guesswork when you walk up to a repository and want to contribute. But we do have an "out" for team maintained packages where the standard workflow isn't appropriate. This can include packages for which git-dpm doesn't work, for packages which need a different branch naming scheme, etc. This requires you to document the differences in your debian/README.source file. You should be judicious about deviation from our standard team workflow. Be kind to your fellow maintainers and really try to work within the standard team policies and procedures. But in cases where you must deviate, you can still be part of the team! Please discuss your issues on this mailing list, come to some agreement among the active uploaders, and document your differences in d/README.source. Cheers, -Barry [1] https://wiki.debian.org/Python/GitPackaging pgpIs_UFixE1p.pgp Description: OpenPGP digital signature
RFS: humanfriendly/2.3.2-1
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "humanfriendly" * Package name: humanfriendly Version : 2.3.2-1 Upstream Author : Peter Odding * URL : https://humanfriendly.readthedocs.io * License : Expat Section : python It builds those binary packages: humanfriendly - Helper command for the humanfriendly Python3 library python-humanfriendly - Python library to make user friendly text interfaces python3-humanfriendly - Python3 library to make user friendly text interfaces To access further information about this package, please visit the following URL: https://mentors.debian.net/package/humanfriendly Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/h/humanfriendly/humanfriendly_2.3.2-1.dsc A git source repo is also put up at https://github.com/gauravjuvekar/debian-python-humanfriendly.git This is the initial upload RFS. -- Regards, Gaurav Juvekar signature.asc Description: OpenPGP digital signature
Re: Call for testing: Sphinx 1.5
On Fri, Dec 23, 2016 at 06:04:00PM +0300, Dmitry Shachnev wrote: > With some delay (usual for me), Sphinx 1.5 is now available in experimental. > > [...] > > If everything goes well, I want to have Sphinx 1.5 included in Stretch. After all, it looks like 1.5 will *not* be in Stretch (unless someone really wants it and asks me about it). I was waiting for Sphinx 1.5.2 bug-fix release, which was only released today. This leaves me only 4 days to upload it to sid, which is not enough to do the necessary testing. -- Dmitry Shachnev signature.asc Description: PGP signature
Re: Team upload for python-jedi
Hi Ghislain, On Sat, Jan 21, 2017 at 11:54:13AM +, Ghislain Vaillant wrote: > "Drop DPMT from Uploaders (due to problems with multiple tarballs in > git-dpm)" > > Then, the package is no longer team-maintained? Personally I think we could allow such packages to remain in team, even if they are not able to use git-dpm. But Piotr is an administrator, so his opinion is more important here. On Thu, Jan 19, 2017 at 05:57:17PM +, Ghislain Vaillant wrote: > > For now you can just forget about git-dpm, get the sources manually and > > copy the Debian directory from Git on top of them. > > Just to be sure, do you mean I should leave the repository alone and > merge my work in a fresh import-dsc of the current package? I did not mean it. You could just (I think) remove debian/.git-dpm and work with plain git-buildpackage. -- Dmitry Shachnev signature.asc Description: PGP signature
