Bug#924411: marked as done (RFS: vitetris/0.58.0-1)
Your message dated Wed, 13 Mar 2019 01:37:51 +0100 with message-id <20190313003751.ga29...@angband.pl> and subject line Re: Bug#924411: RFS: vitetris/0.58.0-1 has caused the Debian Bug report #924411, regarding RFS: vitetris/0.58.0-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.) -- 924411: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924411 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 "vitetris" * Package name: vitetris Version : 0.58.0-1 Upstream Author : Victor Geraldsson * URL : http://www.victornils.net/tetris/ * License : BSD-2-Clause Section : games It builds those binary packages: vitetris - Virtual terminal *tris clone To access further information about this package, please visit the following URL: https://mentors.debian.net/package/vitetris Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/v/vitetris/vitetris_0.58.0-1.dsc More information about vitetris can be obtained from https://salsa.debian.org/lyknode-guest/vitetris. Changes since the last upload: * New upstream version 0.58.0 * Drop patches applied upstream: - 0005-fix-implicit-declaration.patch - 0002-fix-insecure-printf.patch * d/watch: Remove leftover from dh_make template Regards, -- Baptiste BEAUPLAT - lyknode signature.asc Description: OpenPGP digital signature --- End Message --- --- Begin Message --- On Tue, Mar 12, 2019 at 07:02:16PM +0100, Baptiste BEAUPLAT wrote: > * Package name: vitetris > Version : 0.58.0-1 > Changes since the last upload: > >* New upstream version 0.58.0 >* Drop patches applied upstream: > - 0005-fix-implicit-declaration.patch > - 0002-fix-insecure-printf.patch >* d/watch: Remove leftover from dh_make template ✓ -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ Have you accepted Khorne as your lord and saviour? ⠈⠳⣄--- End Message ---
Bug#922938: RFS: python-css-parser/1.0.4-1~bpo9+1
On Tue, Mar 12, 2019 at 05:55:37AM -0400, Chris Lamb wrote: > Nicholas, > > > If you have a minute would you please sponsor this backport > > Please drop the "new-package-should-not-package-python2-module" > override and move the justification to the changelog. > > It should be clear from this tag's description that this is override > is inappropriate and, IIRC, explicitly not requested. > Oops, I missed that :-$ Just to confirm: you'd like me to make this change to the stretch-backport (after which it will no longer be a no-change backport), and also the branch for sid, which would not be uploaded until buster is released? Thanks, Nicholas signature.asc Description: PGP signature
Bug#924411: RFS: vitetris/0.58.0-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "vitetris" * Package name: vitetris Version : 0.58.0-1 Upstream Author : Victor Geraldsson * URL : http://www.victornils.net/tetris/ * License : BSD-2-Clause Section : games It builds those binary packages: vitetris - Virtual terminal *tris clone To access further information about this package, please visit the following URL: https://mentors.debian.net/package/vitetris Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/v/vitetris/vitetris_0.58.0-1.dsc More information about vitetris can be obtained from https://salsa.debian.org/lyknode-guest/vitetris. Changes since the last upload: * New upstream version 0.58.0 * Drop patches applied upstream: - 0005-fix-implicit-declaration.patch - 0002-fix-insecure-printf.patch * d/watch: Remove leftover from dh_make template Regards, -- Baptiste BEAUPLAT - lyknode signature.asc Description: OpenPGP digital signature
Bug#923180: Please sponsor my game bug=923180
Hi, Am 11.03.19 um 21:05 schrieb Pedro Pena: > Hello Markus, > > Very exciting.. > > I applied the patches and made the other changes as well. > However, there are lintian warnings because infinitetux.jar > is now included in the source files. [...] I think I know the reason. You used source format 1.0. Better is to use format 3.0 (quilt). The changelog version should be 1.1-1 because infinitetux is a non-native package meaning we append a Debian revision number to the upstream version. The changelog should also close the ITP bug. I have already updated the package accordingly. I forgot to mention that you can even remove the compat file nowadays if you build-depend on debhelper-compat (= 12) instead of just debhelper. Less is more. :) I also added a watch file. See https://wiki.debian.org/debian/watch for future projects. Thanks for changing infinitetux-data to .infinitetux. Everything else looks good, I've just uploaded the package to NEW and imported it to https://salsa.debian.org/games-team/infinitetux If you want to improve the package or package a new upstream version, you can ask for sponsorship on debian-devel-games directly. You don't have to take the mentors route again. I have granted you access to our Git repository so you can prepare new updates there. Thanks for your contribution! Regards, Markus signature.asc Description: OpenPGP digital signature
Re: Understanding Git workflow around DEP-14
deb...@lewenberg.com writes: > Looking at DEP-14 I might have these Git branches: > > master > debian/master > debian/stretch > upstream/latest > > I understand that the Debian packaging files in debian/ will appear in > the "debian/*" branch, but my general question is: what is the > workflow around all these branches? When and how do files get merged > from one branch to another? See below for my take on the subject. Don't fear all the complication spelled out, I'm trying to explain the big picture in the most complex setting, so things hopefully start to make sense. In practice it's pretty intuitive once you get the guiding principles. > 1. Besides the debian/ directory, what is the difference between the > "debian/master" branch and the "upstream/latest" branch? Nothing, if you use the "3.0 (quilt)" source format, which you should. upstream/latest tracks the contents of the pristine upstream tarballs. If you use pristine-tar, you can reproduce the exact upstream tarballs from upstream/latest and the appropriate binary deltas (usually stored in a disconnected/orphan branch called pristine-tar). > 2. What should the "master" branch be used for? Whatever your upstream uses it for. As a packager, you use it for cherry-picking upstream commits into your quilt patch queue and for creating upstream pull requests by cherry-picking from your patch queue. In other words: for communicating commits with your upstream. The "master" branch is not special in a packaging repository, it's just one of the upstream branches. The default branch of a packaging repository is usually debian/master. (Some use debian/sid; since uploads from here can target experimental as well, I prefer debian/master.) The point of DEP-14 is to work with a clone of the upstream repository, adding extra branches under the debian/ namespace for packaging for various Debian distributions, under the ubuntu/ namespace for Ubuntu distributions and so on, keeping the package vendors separate while storing upstream tarball contents under the shared upstream/ namespace. The pristine-tar branch is basically an unordered container of binary deltas, so it's unique. > 3. When a new upstream tarball is released, where should it be > imported? In "upstream/latest"? In "debian/master"? Both? It's typically imported into upstream/latest, unless you package from several version series concurrently and thus you have for example an upstream/2.x branch as well: then you import 2.x tarballs into the upstream/2.x branch and 3.x tarballs into upstream/latest. You can name these branches however you please, the point is them being under the upstream/ namespace for all package vendors' use. For best effect these import commits should be formal merge commits: their first parent is the previous import commit, and the second parent is the upstream commit from which your upstream author created the release tarball. This is all formal, just a "note of relations" in the git history; the actual content of the commit is that of the imported release tarball, not influenced by either parent in any way. However, these relations are meaningful and git can use them answering queries like git tag --contains 123456 and similar. Returning to concrete branch names: in the simplest case your upstream author tags commits on the master branch and generates tarballs from them; you then import these tarballs into upstream/latest, formally merging in the tags on the master branch. However, your upstream may as well create their release tags on a release branch (say stable2), and then you import those into upstream/latest all the same, or they can do both and then you might package both release streams importing into upstream/2.x and upstream/latest appropriately; DEP-14 is very flexible. Once the import is done, you fuse it with your packaging work by merging it into debian/master (assuming a single release stream again). This is another formal merge: what actually happens is that you replace the upstream part of the current contents of debian/master with the contents of upstream/latest, keeping the debian directory (ever present in debian/master only) unchanged[1]. Then you adjust your packaging files by committing on debian/master; these commits mustn't touch anything outside the debian/ directory. You can make upstream changes via files under debian/patches. Now, how do you do this all? Simple: $ gbp import-orig --upstream-vcs-tag=v2.3 ../project-2.3.tgz Issue the above command on your debian/master branch, where you committed a debian/gbp.conf file with content like this[2]: [DEFAULT] debian-branch = debian/master upstream-branch = upstream/latest pristine-tar = True [import-orig] merge-mode = replace Instead of specifying the upstream tarball, you can even use --uscan most of the time, if you already have a working debian/watch file. Besides all the git magic described above, this command also creates an upstream/2.3 tag for future reference.
Bug#924177: marked as done (RFS: blastem/0.6.3-1 -- Fast and accurate Genesis emulator)
Your message dated Tue, 12 Mar 2019 12:04:09 +0200 with message-id <309764cf-7521-bc1f-1727-5eae7b98b...@debian.org> and subject line Uploaded to debian unstable has caused the Debian Bug report #924177, regarding RFS: blastem/0.6.3-1 -- Fast and accurate Genesis emulator 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.) -- 924177: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924177 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 "blastem" * Package name: blastem Version : 0.6.3-1 Upstream Author : Michael Pavone * URL : https://www.retrodev.com/blastem * License : GPL-3+ Section : games It builds those binary packages: blastem - Fast and accurate Genesis emulator To access further information about this package, please visit the following URL: https://mentors.debian.net/package/blastem Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/b/blastem/blastem_0.6.3-1.dsc More information about BlastEm can be obtained from https://gitlab.com/coringao/blastem. Regards, Carlos Donizete Froes [a.k.a coringao] --- End Message --- --- Begin Message --- --- End Message ---
Bug#922938: RFS: python-css-parser/1.0.4-1~bpo9+1
Nicholas, > If you have a minute would you please sponsor this backport Please drop the "new-package-should-not-package-python2-module" override and move the justification to the changelog. It should be clear from this tag's description that this is override is inappropriate and, IIRC, explicitly not requested. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#923969: marked as done (RFS: vitetris/0.57.2-3)
Your message dated Tue, 12 Mar 2019 11:43:45 +0200 with message-id <20306f22-ecdd-9c16-4477-3115633dd...@debian.org> and subject line Uploaded to debian unstable has caused the Debian Bug report #923969, regarding RFS: vitetris/0.57.2-3 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.) -- 923969: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923969 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 "vitetris" * Package name: vitetris Version : 0.57.2-3 Upstream Author : Victor Geraldsson * URL : http://www.victornils.net/tetris/ * License : BSD-2-Clause Section : games It builds those binary packages: vitetris - Virtual terminal *tris clone To access further information about this package, please visit the following URL: https://mentors.debian.net/package/vitetris Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/v/vitetris/vitetris_0.57.2-3.dsc More information about vitetris can be obtained from https://salsa.debian.org/lyknode-guest/vitetris. Changes since the last upload: * Convert repo to DEP-14 * Move binary stripping from Makefile to debhelper * Bump policy version to 4.3.0 * Bump debian-compat to 12. Remove debian/compat Regards, -- Baptiste BEAUPLAT - lyknode signature.asc Description: OpenPGP digital signature --- End Message --- --- Begin Message --- --- End Message ---
Re: Understanding Git workflow around DEP-14
On Mon, Mar 11, 2019 at 05:08:07PM -0500, Matt Zagrabelny wrote: > On Mon, Mar 11, 2019 at 2:12 PM Geert Stappers wrote: > > On Mon, Mar 11, 2019 at 01:50:49PM -0500, Matt Zagrabelny wrote: > > > > > > > > 2. What should the "master" branch be used for? > > > > Consider the string "master" a label for _your leading branch_ > > > > > > > I don't use the master branch with DEP-14. I believe the DEP is stating > > > that you'd use "master" for native packages - which from the sounds of it, > > > yours is not. Therefore, I'd not use "master". > > > > But you have your own leading branch > > > > When I am packaging someone else's software (upstream/latest) for inclusion > in Debian (debian/master), I don't feel like I have "my own" leading branch. > > What am I missing for using (or not using) a "master" branch? Nothing (and nothing) The git term "clone" is a good term. Cloning is not just copying, is creating a child with the exact DNA of its parent. The new repository get its first branch named 'master'. Is it leading? It could. Git being a distributed VCS makes it confuesing for newcomers. We all start as child. There are parents. It takes a while before we become parents. With `git` it goes much faster. Upon clone there is a master. > > > > 3. When a new upstream tarball is released, where should it be imported? > > > > > > > > > > Assuming you have a remote named "github", I suppose you'd do something > > > like: > > > > > > git pull github upstream/latest > > > > > > I think it should be (be warned _not tested_ ) avoid that your > > current branch gets pollueted. > } git checkout upstream/latest > } git pull github > > > > What makes you believe that the current branch would get polluted? > > I believe a: > > git pull repo refspec > > is equivalent to: > > git checkout refspec > git pull repo > > Am I wrong? Don't know, _not tested_. But yes, It could work. I try (way too much) to be on the safe side. > Thanks for the dialog! YW MP Groeten Geert Stappers -- Leven en laten leven
