Re: Packaging repository using both upstream-as-git and tarballs / branch name conflicts
On Sat, Jul 13, 2019 at 02:41:18PM +0100, Rebecca N. Palmer wrote: > (b) How do I deal with branch/tag name conflicts between upstream and > packaging? They shouldn't happen. > There are at least two ways conflicts can happen by accident: > > (i) gbp defaults to naming the packaging branch 'master', which is also > plain git's default name for the first branch of a new repository. If a remote has a branch this doesn't mean your repo has the same branch. > (ii) gbp's upstream-branch/-tag settings are used both for reading (build) > and writing (import-orig). Hence, if a contributor using upstream-as-git > commits a debian/gbp.conf with these set to the upstream branch name and tag > format, then another contributor imports an upstream tarball with gbp > import-orig, the tarball-import commit ends up on what was the > upstream-as-git branch with an upstream-format tag name [3]. Then don't do that. A repo either uses upstream tags directly or uses upstream/* tags that cannot clash with the upstream ones. > Is there a standard way to tell gbp "this is an upstream-as-git-only > repository, don't import tarballs" to prevent (ii) in future? debian/README.source. -- WBR, wRAR signature.asc Description: PGP signature
Bug#932004: RFS: uriparser/0.9.3-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "uriparser" Package name: uriparser Version : 0.9.3-1 Upstream Author : Sebastian Pipping URL : https://github.com/uriparser/uriparser License : BSD-3-clause, LGPL-2.1+ Section : libs It builds those binary packages: liburiparser-dev - development files for uriparser liburiparser-doc - documentation files for uriparser liburiparser1- URI parsing library compliant with RFC 3986 To access further information about this package, please visit the following URL: https://mentors.debian.net/package/uriparser Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/u/uriparser/uriparser_0.9.3-1.dsc or from git: https://jff.email/cgit/uriparser.git/?h=release%2Fdebian%2F0.9.3-1 Changes since the last upload: * New upstream release. - Refresh symbols file. - Rewrite build process. * Migrate to debhelper 12: - Change debian/compat to 12. - Bump minimum debhelper version in debian/control to >= 12. * Declare compliance with Debian Policy 4.4.0 (No changes needed). The build with sbuild and pdebuild and the tests with Lintain and Piuparts are ok: +--+ | Summary | +--+ Build Architecture: amd64 Build Type: full Build-Space: 48596 Build-Time: 31 Distribution: sid Host Architecture: amd64 Install-Time: 193 Job: /data/entwicklung/linux/debian/uriparser/uriparser_0.9.3-1.dsc Lintian: info Machine Architecture: amd64 Package: uriparser Package-Time: 243 Piuparts: pass Source-Version: 0.9.3-1 Space: 48596 Status: successful Version: 0.9.3-1 Finished at 2019-07-13T17:01:30Z Build needed 00:04:03, 48596k disk space Regards, Jörg Frings-Fürst -- New: GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB 30EE 09F8 9F3C 8CA1 D25D GPG key (long) : 09F89F3C8CA1D25D GPG Key: 8CA1D25D CAcert Key S/N : 0E:D4:56 Old pgp Key: BE581B6E (revoked since 2014-12-31). Jörg Frings-Fürst D-54470 Lieser git: https://jff.email/cgit/ Threema: SYR8SJXB Wire: @joergfringsfuerst Skype:joergpenguin Ring: jff Telegram: @joergfringsfuerst My wish list: - Please send me a picture from the nature at your home.
Packaging repository using both upstream-as-git and tarballs / branch name conflicts
(a) The git-buildpackage manual [0] mentions, and [1] further discusses, a workflow that imports *both* upstream's git and upstream's tarball of the same release: upstream-vcsuUuuUu \ \ upstream-for-gbp --i--i--- \ \ debian -iP--ppPippP-- u, U = upstream commit, release p, P = packaging commit, release i = tarball+git import (gbp import-orig --upstream-vcs-tag) gbp --upstream-branch points to upstream-for-gbp upstream-vcs's remote points to upstream's repo This also allows git-only and tarball-only imports to coexist with the above and each other: upstream-vcsuUuuuUuuUu \ \ upstream-for-gbp --m---\--o--- \ \ \ debian -mP--mppP---oppP-- m = git only import (git merge or gbp import-ref) o = tarball only import (gbp import-orig) (Building the second form of git-only requires temporarily pointing --upstream-branch to upstream-for-gbp, so I suggest preferring the first one for the occasional unreleased-so-no-tarball snapshot in a normally tarball-using repository.) This option seems to be missing from the wiki page [2]: it only has git-only, tarball-only, and "salsa git from upstream git only, archive .orig from tarball" (noting the "they might not match" problem with the last). Is this omission a recommendation against it, or should it be added? --- (b) How do I deal with branch/tag name conflicts between upstream and packaging? There are at least two ways conflicts can happen by accident: (i) gbp defaults to naming the packaging branch 'master', which is also plain git's default name for the first branch of a new repository. (ii) gbp's upstream-branch/-tag settings are used both for reading (build) and writing (import-orig). Hence, if a contributor using upstream-as-git commits a debian/gbp.conf with these set to the upstream branch name and tag format, then another contributor imports an upstream tarball with gbp import-orig, the tarball-import commit ends up on what was the upstream-as-git branch with an upstream-format tag name [3]. Given that Git considers the same final contents via a different history to be a different commit number, I suspect (but haven't tried) that this makes that branch no longer usable for 'git pull' from upstream. [4] suggests that the command to pull a branch with a different name is git branch -u upstream/master upstream-vcs Is this correct, and will it sanely handle tag conflicts (e.g. by skipping the conflicting tags)? Is there a convention for what name to give this branch? Is there a standard way to tell gbp "this is an upstream-as-git-only repository, don't import tarballs" to prevent (ii) in future? (Avoiding (i) for new repositories is DEP-14 / #829444.) [0] https://sources.debian.org/src/git-buildpackage/0.9.14/docs/chapters/import.xml/#L233, or if you have it installed, file:///usr/share/doc/git-buildpackage/manual-html/gbp.import.html#GBP.IMPORT.UPSTREAM-GIT [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=664771 [2] https://wiki.debian.org/GitPackagingSurvey [3] I have seen what appears to be a real example of this on Salsa. [4] https://github.com/Debian/pkg-go-tools/blob/master/cmd/pgt-remote-add-upstream/upstream.go
Bug#931989: RFS: desktopfolder/1.1.0-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "desktopfolder" * Package name: desktopfolder Version : 1.1.0-1 Upstream Author : José Amuedo Salmerón joseamu...@gmail.com * URL : https://github.com/spheras/desktopfolder * License : GPL-3+ Section : x11 It builds those binary packages: desktopfolder - Organize your desktop with panels, notes and photos To access further information about this package, please visit the following URL: https://mentors.debian.net/package/desktopfolder Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/d/desktopfolder/desktopfolder_1.1.0-1.dsc Notes: I have run check-all-the-things and helped resolve source matters in consultation with the maintainer. I have built via sbuild on the current unstable repo. sbuild is configured to run lintian -i -I --pedantic on the built source. One Information lintian remains - missing autopkgtest. I dont consider it necessary for such a test to be defined. I have rechecked the copyright file - no changes required. If appropriate I would like to continue maintainership of this package (assuming that it is acceptable to Debian) in a similar manner as my current maintainership packages (dak fossfree...@ubuntu.com) Changes since the last upload: * New upstream release - See ChangeLog * Packaging Changes - Control: Bump StandardsVersion: no changes required - Control: Bump debhelper/compat to 12 - Control: Add intltool to build-depends - Drop existing patch since this area has been superseded in this release Regards, David Mohammed
Bug#931942: marked as done (RFS: libonig/6.9.2-1)
Your message dated Sat, 13 Jul 2019 12:19:46 +0200 with message-id <20190713101946.ga20...@angband.pl> and subject line Re: Bug#931942: RFS: libonig/6.9.2-1 has caused the Debian Bug report #931942, regarding RFS: libonig/6.9.2-1 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 931942: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931942 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "libonig" Package name: libonig Version : 6.9.2-1 Upstream Author : K.Kosako URL : https://github.com/kkos/oniguruma License : BSD-2-clause Section : libs It builds those binary packages: libonig-dev - regular expressions library — development files libonig5- regular expressions library To access further information about this package, please visit the following URL: https://mentors.debian.net/package/libonig Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/libo/libonig/libonig_6.9.2-1.dsc or https://jff.email/cgit/libonig.git/?h=release%2Fdebian%2F6.9.2-1 Changes since the last upload: * New upstream release: - Refresh symbols file. - Refresh debian/patches/0100-source_typos.patch. * Rewrite debain/watch. * New debian/patches/0105-CVE-2019-13224.patch and debian/patches/0110-CVE-2019-13225.patch (Closes: #931878): - Fixes CVE-2019-13224 A use-after-free in onig_new_deluxe() in regext.c. - Fixes CVE-2019-13225 A NULL Pointer Dereference in match_at() in regexec.c. * Declare compliance with Debian Policy 4.4.0 (No changes needed). * Migrate to debhelper 12: - Change debian/compat to 12. - Bump minimum debhelper version in debian/control to >= 12. - debian/rules: Remove obsolete dh_install --fail-missing. The build with sbuild and pdebuild and the tests with Lintain and Piuparts are ok: +--+ | Summary | +--+ Build Architecture: amd64 Build Type: full Build-Space: 29572 Build-Time: 28 Distribution: sid Host Architecture: amd64 Install-Time: 35 Job: /data/entwicklung/linux/debian/libonig/libonig_6.9.2-1.dsc Lintian: info Machine Architecture: amd64 Package: libonig Package-Time: 80 Piuparts: pass Source-Version: 6.9.2-1 Space: 29572 Status: successful Version: 6.9.2-1 Finished at 2019-07-12T17:20:07Z Build needed 00:01:20, 29572k disk space Regards, Jörg Frings-Fürst -- New: GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB 30EE 09F8 9F3C 8CA1 D25D GPG key (long) : 09F89F3C8CA1D25D GPG Key: 8CA1D25D CAcert Key S/N : 0E:D4:56 Old pgp Key: BE581B6E (revoked since 2014-12-31). Jörg Frings-Fürst D-54470 Lieser git: https://jff.email/cgit/ Threema: SYR8SJXB Wire: @joergfringsfuerst Skype:joergpenguin Ring: jff Telegram: @joergfringsfuerst My wish list: - Please send me a picture from the nature at your home. --- End Message --- --- Begin Message --- On Fri, Jul 12, 2019 at 07:25:56PM +0200, Jörg Frings-Fürst wrote: >Package name: libonig >Version : 6.9.2-1 > * New upstream release: > - Refresh symbols file. > - Refresh debian/patches/0100-source_typos.patch. > * Rewrite debain/watch. > * New debian/patches/0105-CVE-2019-13224.patch and > debian/patches/0110-CVE-2019-13225.patch (Closes: #931878): > - Fixes CVE-2019-13224 A use-after-free in onig_new_deluxe() in regext.c. > - Fixes CVE-2019-13225 A NULL Pointer Dereference in match_at() >in regexec.c. > * Declare compliance with Debian Policy 4.4.0 (No changes needed). > * Migrate to debhelper 12: > - Change debian/compat to 12. > - Bump minimum debhelper version in debian/control to >= 12. > - debian/rules: Remove obsolete dh_install --fail-missing. LGTM -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ According to recent spams, "all my email accounts are owned ⢿⡄⠘⠷⠚⠋ by a hacker". So what's the problem? ⠈⠳⣄--- End Message ---
Bug#931960: RFS: jool/4.0.2-1 [ITP] -- IP/ICMP Translators
❦ 12 juillet 2019 18:48 -05, Alberto Leiva Popper : > I am looking for a sponsor for my package "jool" I have posted a review in #883393 (before seeing this RFS). -- Debian package sponsoring guidelines: https://vincent.bernat.ch/en/debian-package-sponsoring signature.asc Description: PGP signature
Bug#931814: RFS: daggy/1.1.2-1 [ITP]
Differences from multiplexers: 1. Daggy can run commands on localhost without ssh 2. Daggy can run different sets of commands on different sets servers (taktuk, for example, can run only one command on set of servers) 3. Daggy has human readable config. For example - https://github.com/synacker/daggy/blob/master/docs/.gitbook/assets/simple_multiple_servers.yaml 4. Daggy streams command outputs to your local folder at runtime by default - separate file for each command. 5. Daggy is crossplatform. It means, that one data sources config can be run from multiple types of hosts (Windows, MacOS, Linux). Thank you for attention! сб, 13 июл. 2019 г. в 11:28, Dmitry Bogatov : > [2019-07-10 22:17] Михаил Миловидов > > > > part 2 text/plain1010 > > Package: sponsorship-requests > > Severity: wishlist > > > > Dear mentors, > > > > I am looking for a sponsor for my package "daggy": > > > > * Package name : daggy > > Version : 1.1.2-1 > > Upstream Author : Mikhail Milovidov milovidovmikh...@gmail.com > > * URL : https://daggy.dev > > * License : Expat > > Section : net > > > > It builds those binary packages: > > > > daggy - run multiple commands on remote servers and save output locally > > How does it compare with heap of ssh multiplexers already in Archive? > For example, > > $ apt-cache search ssh multiplex > [... filtered a bit ...] > sslh - Applicative protocol multiplexer > taktuk - efficient, large scale, parallel remote execution of > commands > > -- > Note, that I send and fetch email in batch, once in a few days. > Please, mention in body of your reply when you add or remove recepients. >
Bug#931814: RFS: daggy/1.1.2-1 [ITP]
[2019-07-10 22:17] Михаил Миловидов > > part 2 text/plain1010 > Package: sponsorship-requests > Severity: wishlist > > Dear mentors, > > I am looking for a sponsor for my package "daggy": > > * Package name : daggy > Version : 1.1.2-1 > Upstream Author : Mikhail Milovidov milovidovmikh...@gmail.com > * URL : https://daggy.dev > * License : Expat > Section : net > > It builds those binary packages: > > daggy - run multiple commands on remote servers and save output locally How does it compare with heap of ssh multiplexers already in Archive? For example, $ apt-cache search ssh multiplex [... filtered a bit ...] sslh - Applicative protocol multiplexer taktuk - efficient, large scale, parallel remote execution of commands -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#931972: Bug#930637: unblock: monit/1:5.25.2-3+deb10u1
On 7/13/19 8:25 AM, Sergey B Kirpichev wrote: > On Sun, 7 Jul 2019 08:29:08 +0200 Sebastiaan Couwenberg > wrote: >> Please upload a new revision to unstable with source-only changes... > > Backport for Buster: > https://mentors.debian.net/package/monit > Please sponsor this package. I will sponsor the upload as soon a buster-backports accepts packages. All the backports I uploaded today were rejected because source is not accepted yet. > Sponsorship request: > https://bugs.debian.org/931972 CC'ed. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#931972: RFS: monit/1:5.26.0-1~bpo9+1 -- backport for buster
Package: sponsorship-requests Severity: normal I am looking for a sponsor for my backport package "monit": To access further information about this package, please visit the following URL: https://mentors.debian.net/package/monit
