Bug#1069078: RFS: lua-mode/20210802-4 [RC] [Team] -- Emacs major-mode for editing Lua programs
Hello, On Thu 18 Apr 2024 at 06:24pm -07, Xiyue Deng wrote: > Sean Whitton writes: > >> control: tag -1 + moreinfo >> >> Hello Xiyue, >> >> Please explain the autopkgtest_keep change. Remember that autopkgtests >> are to test the installed package. If you need to keep the .el files, >> it must be for some reason other than because the test suite actually >> just tests those. >> > > I think this is another example of buttercup tests that requires source > .el files to run. I'll probably open a bug on buttercup to see whether > this is required for buttercup. Meanwhile I think it'd probably be > better to just disable autopkgtest as the tests are already run as part > of the build process. I agree. It is important not to use autopkgtest_keep without being sure it's the right answer. >> You've removed the Built-Using with the justification that it's an >> arch:all package, but that doesn't make sense; Built-Using is for >> licensing reasons, and may well be applicable to an arch:all package (I >> think this came up before with one of your uploads?). > > Ah I was following the suggestions of Lintian which said it cannot be > used by arch:all packages which is probably wrong. See #999785. > On the other hand, on a closer look at the policy regarding > Built-Using on section 7.8[1], it has the following passage: > > , > | This field should be used only when there are license or DFSG > | requirements to retain the referenced source packages. It should not be > | added solely as a way to locate packages that need to be rebuilt against > | newer versions of their build dependencies. > ` > > I checked that lua-mode is of GPL-2+[2], and of all its dependencies > lua5.3 is of MIT which is compatible with GPL, and the rest are all GPL > 2+ or 3+, so I don't see a license or DFSG need to add this Built-Using > requirement. The change was introduced in [3] but it was part of the > modernization effort so there is no direct justification of adding the > field. May be I'm missing something here? It sounds like it shouldn't have been introduced. So you can remove it based on your reading of Policy, and briefly note your reasoning in d/changelog. -- Sean Whitton signature.asc Description: PGP signature
Bug#1069078: Acknowledgement (RFS: lua-mode/20210802-4 [RC] [Team] -- Emacs major-mode for editing Lua programs)
control: tag -1 + moreinfo Hello Xiyue, Please explain the autopkgtest_keep change. Remember that autopkgtests are to test the installed package. If you need to keep the .el files, it must be for some reason other than because the test suite actually just tests those. You've removed the Built-Using with the justification that it's an arch:all package, but that doesn't make sense; Built-Using is for licensing reasons, and may well be applicable to an arch:all package (I think this came up before with one of your uploads?). -- Sean Whitton signature.asc Description: PGP signature
Bug#1068564: closing 1068564
close 1068564 thanks -- Sean Whitton
Bug#1068564: RFS: emacs-buttercup/1.35-1 -- behaviour-driven testing for Emacs Lisp packages
Hello, On Fri 12 Apr 2024 at 12:44pm +01, Jeremy Sowden wrote: > On 2024-04-12, at 17:53:15 +0800, Sean Whitton wrote: >> Do you have your 1.34 upload of buttercup in git, please? > > Yup, it's all on Salsa. Er. I got confused, then, didn't I? Should this RFS be closed? -- Sean Whitton signature.asc Description: PGP signature
Bug#1068564: RFS: emacs-buttercup/1.35-1 -- behaviour-driven testing for Emacs Lisp packages
Hello Jeremy, Do you have your 1.34 upload of buttercup in git, please? Xiyue, you need to merge in the 1.34 upload, either something from Jeremy, or we can fall back to merging from dgit/sid. This has happened a few times now -- please check whether you're missing uploads before starting to work on top of the branch on salsa :) -- Sean Whitton signature.asc Description: PGP signature
Bug#1067895: RFS: emacs-format-all-the-code/0.6.0-1 [Team] -- Auto-format C, C++, JS, Python, Ruby and 50 other languages
control: tag -1 + moreinfo Looks like the Source: in d/copyright is bogus? -- Sean Whitton
Bug#1067581: RFS: package-lint-el/0.22-1 [Team] -- package-lint Flymake backend
control: tag -1 + moreinfo Hello, Looks like you didn't push to master :) -- Sean Whitton signature.asc Description: PGP signature
Bug#1067127: closing 1067127
close 1067127 thanks -- Sean Whitton
Bug#1054523: RFS: persp-projectile/1:1.0.0+git20210618.4e374d7-1 [RC] [Team] -- integrate perspective.el with projectile
Hello,
On Sun 10 Dec 2023 at 09:09pm -08, Xiyue Deng wrote:
> So a little further reading from the policy[1] and the lintian bug[2]
> helped me understand the usage of "Built-Using" a bit better: it's used
> to include other source package required for building without having to
> depend on them. So technically it's not mutually exclusive with
> arch:all as stated in the bug. However, in the case of
> persp-perspective, I tried with or without it and it doesn't make any
> difference. What's important is that ${elpa:Depends} correctly added
> elpa-perspective and elpa-projectile to the dependency list of the
> binary package. So I think in the end dropping it should be OK.
>
> Still, it makes sense to clarify the actual reason to drop it, so I've
> updated the changelog entry to reflect this fact[3]. PTAL, TIA!
Well, it's more about ensuring that those source package versions aren't
dropped from the archive by dak, rendering us license-incompliant.
Thanks for looking into it further. I've made a further change to your
changelog message. Please take a look.
I've also noticed that there has been an upload to the archive,
1:0.2.0-4, which is not accounted for in our history. Please merge it
in. 'gbp import-dsc apt:persp-projectile/sid', and then a manual merge,
is probably what you want, because of how the patches are unapplied.
--
Sean Whitton
signature.asc
Description: PGP signature
Bug#1054523: RFS: persp-projectile/1:1.0.0+git20210618.4e374d7-1 [RC] [Team] -- integrate perspective.el with projectile
Hello, On Fri 03 Nov 2023 at 05:01pm -07, Xiyue Deng wrote: > I thought mentioning dropping Built-Using from arch:all package could be > an acceptable reason, which in turn also follows Lintian's suggestion :) > But do let me know if I should further clarify. But why couldn't an arch:all package have Built-Using? Built-Using, per Policy, is for license issues. arch:any vs. arch:all isn't determinative. -- Sean Whitton signature.asc Description: PGP signature
Bug#1055379: RFS: clojure-mode/5.18.0-1 [RC] [Team] -- extra font-locking for clojure-mode
Hello, On Sat 09 Dec 2023 at 04:08pm -08, Xiyue Deng wrote: > Looks like the deleted changes are the patches that dropped the > package.el based installation instructions from README.md and an extra > loading path of Eldev based directory. I don't think they'll matter > much to be honest (especially the latter doesn't cause any issue for the > tests), so please feel free to leave them as is. Cool, thanks for reviewing. -- Sean Whitton signature.asc Description: PGP signature
Bug#1055379: RFS: clojure-mode/5.18.0-1 [RC] [Team] -- extra font-locking for clojure-mode
Hello, On Sat 09 Dec 2023 at 04:23pm GMT, Sean Whitton wrote: > Hello Xiyue, > > I made some commits before uploading. Please review. > > For the dgit-maint-merge(7) workflow, there is no need to manually > refresh patches. dgit will do it for us whenever necessary. See the > automatic commit now on the branch. Hmm. Looks like I might have deleted some changes. Could you take a look? Thank you. -- Sean Whitton signature.asc Description: PGP signature
Bug#1054523: RFS: persp-projectile/1:1.0.0+git20210618.4e374d7-1 [RC] [Team] -- integrate perspective.el with projectile
control: tag -1 + moreinfo control: owner -1 ! Hello Xiyue, Thank you for working on this. A review of 2ea5e050fe78c7a382a613bc60ce5f14da4f130a: I'm wondering why you've updated git watch to check for the git HEAD, since upstream seems to now be tagging releases? The changelog should mention the switch d/compat -> debhelper-compat. The typo fix in d/control should be mentioned in d/changelog. You should say that it's --parallel that you dropped from d/rules. Your justification for dropping the Built-Using should not be that Lintian suggested dropping it. Please determine the real reason :) -- Sean Whitton signature.asc Description: PGP signature
Bug#1053987: RFS: bison-mode/0.3-1 [ITP] -- Emacs major mode for editing lex, yacc, and bison grammars
Hello, On Mon 16 Oct 2023 at 03:51am -07, Xiyue Deng wrote: > Looks like I got confused about what you suggested as there was a "0.3" > tag that was from the upstream repo which I assume "git deborig" can use > so I thought an "upstream" may help more. > > I've now also pushed an "upstream/0.3" tag at the commit that matches > the "0.3" tag, but not sure whether this is what you were referring to. > If this works better I can remove the upstream branch to avoid further > complications. Please advice. Thanks! What I meant was simply pushing the 0.3 tag to salsa. -- Sean Whitton signature.asc Description: PGP signature
Bug#1053987: RFS: bison-mode/0.3-1 [ITP] -- Emacs major mode for editing lex, yacc, and bison grammars
Hello, On Sun 15 Oct 2023 at 10:45pm -07, Xiyue Deng wrote: > Ah I see. So for d/copyright we need to stick to the source > information. Dropped Wilfred from the list of copyright holders for > now. Also opened a PR upstream for tracking[1]. Cool. Just to note, in your commit message you wrote that he's not a copyright holder yet, but we can't assert that -- in fact, he probably is a copyright holder. You could have written that he's not /documented/ as a copyright holder. > As this is the first time I attempt of ITP/RFS, I'd like to go over the > steps for packaging as much as possible if OK. But AIUI this package > will need to go through the NEW queue, so I guess if you sponsor my > upload to mentors.d.n it may require some extra steps, then I'm OK if > what you propose can save some trouble. Okay, go ahead and let me know when you've done 'dch -r'. I will still work out of git, so please don't push a signed tag there. See dgit-sponsorship(7) for more. -- Sean Whitton signature.asc Description: PGP signature
Bug#1053987: RFS: bison-mode/0.3-1 [ITP] -- Emacs major mode for editing lex, yacc, and bison grammars
Hello, On Sun 15 Oct 2023 at 10:46pm -07, Xiyue Deng wrote: > Sean Whitton writes: > >> Hello, >> >> On Sun 15 Oct 2023 at 03:10pm +01, Sean Whitton wrote: >> >>> Hello, >>> >>> On Sun 15 Oct 2023 at 05:14am -07, Xiyue Deng wrote: >>> >>>> Sure! It's at https://salsa.debian.org/manphiz/bison-mode. FYI I have >>>> also filed an RFS bug#1053987. >>> >>> Alright, pushed that to a team repo, let's work from there. >> >> It would be a good idea to push upstream's git tags to the repo, so that >> I can just type 'git deborig'. > > Done. The `upstream' branch should be available now. I did mean the tags -- I myself prefer not to push an upstream branch. The idea is that from our point of view the upstream source is immutable, like tags, and unlike branches. But of course it's fine to have one. -- Sean Whitton signature.asc Description: PGP signature
Bug#1053987: RFS: bison-mode/0.3-1 [ITP] -- Emacs major mode for editing lex, yacc, and bison grammars
Hello, On Sun 15 Oct 2023 at 03:10pm +01, Sean Whitton wrote: > Hello, > > On Sun 15 Oct 2023 at 05:14am -07, Xiyue Deng wrote: > >> Sure! It's at https://salsa.debian.org/manphiz/bison-mode. FYI I have >> also filed an RFS bug#1053987. > > Alright, pushed that to a team repo, let's work from there. It would be a good idea to push upstream's git tags to the repo, so that I can just type 'git deborig'. -- Sean Whitton signature.asc Description: PGP signature
Bug#1053987: RFS: bison-mode/0.3-1 [ITP] -- Emacs major mode for editing lex, yacc, and bison grammars
Hello, On Sun 15 Oct 2023 at 05:14am -07, Xiyue Deng wrote: > Sure! It's at https://salsa.debian.org/manphiz/bison-mode. FYI I have > also filed an RFS bug#1053987. Alright, pushed that to a team repo, let's work from there. Review of 8123e6e09fa1591dc2182682661421d9be80c328: - d/copyright is required to say where upstream sources were obtained -- see Debian Policy - It looks like you made up the copyright statement for Wilfred Hughes, right? While he may indeed hold copyright, what the GPL requires is just that we reproduce the copyright notices we actually find in the source. So it's probably best to drop it for now, and consider offering a pull request upstream. - I'd like to suggest dropping the .gitignore, because it interferes with me uploading using dgit. Can explain more if you want. - description "electric support" is ambiguous. Support for doing what? - in general, do you mind if when I upload I commit the 'dch -r' change for you? I.e. the upload is signed off by me, but there'd be [ Xiyue Deng ] in the changelog. This avoids an e-mail roundtrip. Totally up to you. -- Sean Whitton signature.asc Description: PGP signature
Bug#1053987: RFS: bison-mode/0.3-1 [ITP] -- Emacs major mode for editing lex, yacc, and bison grammars
Hello Xiyue, On Sun 15 Oct 2023 at 04:32am -07, Xiyue Deng wrote: > Package: sponsorship-requests > Severity: wishlist > X-Debbugs-Cc: Xiyue Deng , debian-emac...@lists.debian.org > > Dear mentors, > > I am looking for a sponsor for my package "bison-mode": > > * Package name : bison-mode >Version : 0.3-1 >Upstream contact : [fill in name and email of upstream] > * URL : https://github.com/Wilfred/bison-mode > * License : GPL-2+ > * Vcs : https://salsa.debian.org/emacsen-team/bison-mode Can you give me a git repo to clone, please? I'll create and push it to that team repo, then review and sponsor. -- Sean Whitton signature.asc Description: PGP signature
Bug#901584: DMs' difficulties in uploading packages into Backports (Was: Re: Bug#901584 closed by Adam Borowski )
Hello, On Fri, Jun 15 2018, Boyuan Yang wrote: > 2. and that Debian Maintainer asks another Debian Developer to open an > RT ticket to get the uid into the backports ACL and wait till the > ticket is finished. Note that non-DDs have no access to RT system thus > a sponsorship of RT ticket from other DDs is needed. This is not true. Non-DDs cannot look at tickets in the system, but they can submit them. I was a DM uploading to backports long before becoming a DD and I submitted the request to RT myself. -- Sean Whitton
Bug#895848: RFS: inotify-tools/3.14-5
control: tag -1 +moreinfo control: owner -1 ! On Mon, Apr 16, 2018 at 10:25:01PM +0300, Dmitry Bogatov wrote: > > I am looking for a sponsor for my package "inotify-tools" FTBFS: dpkg-gensymbols: warning: some symbols or patterns disappeared in the symbols file: see diff output below dpkg-gensymbols: warning: debian/libinotifytools0/DEBIAN/symbols doesn't match completely debian/libinotifytools0.symbols --- debian/libinotifytools0.symbols (libinotifytools0_3.14-5_amd64) +++ dpkg-gensymbolsU60ncr 2018-04-17 04:48:11.369699111 + @@ -1,7 +1,7 @@ libinotifytools.so.0 libinotifytools0 #MINVER# - __odr_asan.rb_null@Base 3.14-4~ - __odr_asan.tree_filename@Base 3.14-4~ - __odr_asan.tree_wd@Base 3.14-4~ +#MISSING: 3.14-5# __odr_asan.rb_null@Base 3.14-4~ +#MISSING: 3.14-5# __odr_asan.tree_filename@Base 3.14-4~ +#MISSING: 3.14-5# __odr_asan.tree_wd@Base 3.14-4~ _niceassert@Base 3.11 chrtostr@Base 3.11 cleanup_tree@Base 3.12 dh_makeshlibs: failing due to earlier errors make: *** [debian/rules:9: binary] Error 2 dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned exit status 2 Looks like you need to update your symbols file. Please be sure to `dch -r`. -- Sean Whitton signature.asc Description: PGP signature
Bug#889968: RFS: inotify-tools/3.14-4 -- summary of situation
Hello Dmitry, Gianfranco, I did some research and testing into this bug... On Sat, Apr 14 2018, kact...@gnu.org wrote: > Hello. I am a bit lost about state of this RFS, but it seems I did > stupid thing with format=1.0; complicating sponsoring. > > Let me settle things, provide sane package with format=3.0 (quilt), with > pristine tar. I will ping once I am ready. Sorry for noise. That is not the problem. The orig.tar is already in the archive so no-one should need pristine-tar. I can obtain something that works like this: % git clone salsa.debian.org:iu-guest/inotify-tools % cd inotify-tools % origtargz % sbuild# or similar Gianfranco, please try that :) Now as to the FTBFS I was seeing, I investigated further. dh_auto_configure works fine, but dpkg-buildpackage does not: configure:3383: ./conftest ==28639==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD. configure:3387: $? = 1 I found a bug report[1] which says that this error is bogus when triggered by cowbuilder or fakeroot. dpkg-buildpackage doesn't use fakeroot when it invokes dh_auto_configure, though ... I would suggest just disabling address sanitising for now. My sbuild setup is v. similar to the buildds, so I suspect we are going to see an FTBFS if this is left turned on. [1] https://github.com/google/sanitizers/issues/786 -- Sean Whitton signature.asc Description: PGP signature
Bug#889968: RFS: inotify-tools/3.14-4
Hello, On Sat, Apr 14 2018, kact...@gnu.org wrote: > Hello. I am a bit lost about state of this RFS, but it seems I did > stupid thing with format=1.0; complicating sponsoring. > > Let me settle things, provide sane package with format=3.0 (quilt), > with pristine tar. I will ping once I am ready. Sorry for noise. The source package format is not the issue, afaict. pristine-tar can work with source format 1.0 -- Sean Whitton signature.asc Description: PGP signature
Bug#889968: RFS: inotify-tools/3.14-4
Hello, On Fri, Apr 13 2018, Gianfranco Costamagna wrote: >>Please try typing `origtargz`. > > > it downloads the current one in the archive, without the patches, and > then it fails with: Ah, sorry, I thought it would invoke uscan. The next thing you might try is `git deborig`. But I understand just asking Dmitry! -- Sean Whitton signature.asc Description: PGP signature
Bug#889968: RFS: inotify-tools/3.14-4
Hello, On Thu, Apr 12 2018, Gianfranco Costamagna wrote: > I'm worried about the disappear of "debian-changes" patch, is it > somewhere else? should I get a new orig tarball? I don't want my > upload to make something disappear from the patch queue, due to my > lack of dgit procedures. It's because the patch was merged upstream. > Please tell me the commands to get the source in the right way(TM) and > then I'll look/sponsor if the patch has to disappear for some ways. > other things LGTM, the package builds in my pbuilder, and probably in > ppas too. Please try typing `origtargz`. -- Sean Whitton signature.asc Description: PGP signature
Bug#893919: [Pkg-emacsen-addons] Bug#893919: RFS: yasnippet-snippets/0~git20180307.2b4c4d7e-3 [RC]
Hello, On Fri, Mar 23 2018, Nicholas D Steeves wrote: > Unpacking yasnippet-snippets (0~git20180307.2b4c4d7e-3) over > (0~git20161123-1) ... dpkg: warning: unable to delete old directory > '/usr/share/yasnippet-snippets/tuareg-mode': Directory not empty dpkg: > warning: unable to delete old directory > '/usr/share/yasnippet-snippets/scala-mode': Directory not empty dpkg: > warning: unable to delete old directory > '/usr/share/yasnippet-snippets/ruby-mode': Directory not empty dpkg: > warning: unable to delete old directory > '/usr/share/yasnippet-snippets/js-mode': Directory not empty dpkg: > warning: unable to delete old directory > '/usr/share/yasnippet-snippets/clojure-mode': Directory not empty > dpkg: warning: unable to delete old directory > '/usr/share/yasnippet-snippets': Directory not empty These are standard warnings Debian users are used to seeing, so it seems fine to have them IMO. -- Sean Whitton signature.asc Description: PGP signature
Bug#893919: [Pkg-emacsen-addons] Bug#893919: RFS: yasnippet-snippets/0~git20180307.2b4c4d7e-3 [RC]
Hello, On Fri, Mar 23 2018, Nicholas D Steeves wrote: > After many hours trying to work around bug #893598 while attempting to > transition yasnippet-snippets to a dummy package I have had to > conclude that yasnippet-snippets must remain the package that contains > the snippets until buster+1. Please justify this conclusion. Someone on debian-mentors might see a way out. -- Sean Whitton signature.asc Description: PGP signature
Bug#890878: RFS: company-irony
Hello, On Mon, Feb 26 2018, Alberto Luaces wrote: > I have refreshed those fields. I have not still refreshed the > changelog date in order to wait for more potential changes. Thanks for fixing this. I'm not in a position to properly review this package, unfortunately. Sorry for suggesting in a previous mail that I was planning on doing that. Just wanted to get the Vcs-* fields fixed. -- Sean Whitton signature.asc Description: PGP signature
Bug#890878: RFS: company-irony
Hello, On Wed, Feb 21 2018, Alberto Luaces wrote: > Thanks, Sean. It is now located at > > https://salsa.debian.org/aluaces-guest/company-irony > > I guess someone else has to clone it under the team project folders, > so I created that personal repository first. You should be able to do it yourself... are you saying that you were unable to create a repo under emacsen-team? I just bumped your permission level. I don't want to upload the package with the wrong Vcs-* headers, so let's get this fixed first. -- Sean Whitton signature.asc Description: PGP signature
Bug#890878: RFS: company-irony
Hello, On Tue, Feb 20 2018, Alberto Luaces wrote: > I would need someone to sponsor "company-irony", which is now packaged > and uploaded to Alioth. It should be on salsa. alioth is shutting down in a matter of weeks. If you request access to https://salsa.debian.org/emacsen-team/ I'll grant it. -- Sean Whitton signature.asc Description: PGP signature
Bug#889968: RFS: inotify-tools/3.14-4
Hello, On Wed, Feb 14 2018, Sean Whitton wrote: > If you do this, please upload using `dgit push-source` since Dmitry is > using a dgit-based workflow. > > (you can just run `dgit push-source` and it should do everything for > you) Oh, plus --overwrite since the last upload to unstable was not made with dgit. -- Sean Whitton signature.asc Description: PGP signature
Bug#889968: RFS: inotify-tools/3.14-4
Hello Gianfranco,
On Wed, Feb 14 2018, kact...@gnu.org wrote:
> Hello! Gianfranco, could you please consider building and, probably,
> sponsoring this package? We have issue, that it FTBFS on Sean's setup,
> but builds on mine and on debomatic. As debomatic admin notified,
> debomatic is not out-of-date {updated this sunday}.
>
> https://salsa.debian.org/iu-guest/inotify-tools
If you do this, please upload using `dgit push-source` since Dmitry is
using a dgit-based workflow.
(you can just run `dgit push-source` and it should do everything for
you)
--
Sean Whitton
signature.asc
Description: PGP signature
Bug#889968: RFS: inotify-tools/3.14-4
Hello, On Tue, Feb 13 2018, Luca Falavigna wrote: > 2018-02-13 4:18 GMT+01:00 <kact...@gnu.org>: >>> I suspect that the debomatic sid chroot is out-of-date. > > amd64 chroot was updated on Sunday, February 11, 2018 4:20:10 PM UTC > (1518366010.2514317). Thanks for the feedback! -- Sean Whitton signature.asc Description: PGP signature
Bug#889968: RFS: inotify-tools/3.14-4
Hello Dmitry, On Tue, Feb 13 2018, kact...@gnu.org wrote: > [2018-02-12 13:07] Sean Whitton <spwhit...@spwhitton.name> >> > Last version is at bacef877c2f9293f9e1fd624b32d5306d7bc3c27 Maybe, >> > you could try again? >> >> Still FTBFSs. Log attached. >> >> I suspect that the debomatic sid chroot is out-of-date. > > Stange. Just did 'sbuild-update -udcar', and still fails to reproduce. > I have same version of build-essential, by the way. > > Added debomatic admin into CC, maybe he has any opinion about > situation. If not, I could remove sanitize support, although I am not > so happy with it. Or maybe you could tar.gz your chroot and upload > somewhere? I tried deleting and rebuilding my chroot and disabling ccache and tmpfs, and I tried building on my i386 machine, again after rebuilding, disabling ccache and disabling tmpfs. In all cases the package FTBFS. I attach my i386 log.. I'm not sure how to proceed. I can't upload this if I can't build it, and my configuration seems sufficiently standard that even if you are able to build it, we shouldn't upload. Maybe we should try disabling sanitize support for now. -- Sean Whitton inotify-tools_3.14-4_i386-2018-02-13T19:12:26Z.build Description: Binary data signature.asc Description: PGP signature
Bug#889968: RFS: inotify-tools/3.14-4
control: tag -1 +moreinfo control: owner -1 ! Hello Dmitry, Review of 3c46a878fd294e9af9f8e7c225d16e8aceb960cf: - It looks like you added an entry to the changelog for 3.13-3 that should have been in the changelog for 3.13-4. - I'm not sure that DPKG_EXPORT_BUILDFLAGS = 1 will have any effect unless you export it? Not sure; I have not used this feature. - It FTBFSs for me. Log attached. -- Sean Whitton sbuild (Debian sbuild) 0.73.0 (23 Dec 2016) on iris.silentflame.com +==+ | inotify-tools 3.14-4 (amd64) Sat, 10 Feb 2018 19:10:16 + | +==+ Package: inotify-tools Version: 3.14-4 Source Version: 3.14-4 Distribution: unstable Machine Architecture: amd64 Host Architecture: amd64 Build Architecture: amd64 Build Type: binary I: NOTICE: Log filtering will replace 'var/run/schroot/mount/unstable-amd64-sbuild-ea2ba2cd-ce02-480e-b119-6bc5bbd3eb48' with '<>' +--+ | Update chroot| +--+ Get:1 http://deb.debian.org/debian unstable InRelease [241 kB] Get:2 http://deb.debian.org/debian unstable/contrib Sources.diff/Index [27.8 kB] Get:3 http://deb.debian.org/debian unstable/main Sources.diff/Index [27.9 kB] Get:4 http://deb.debian.org/debian unstable/non-free Sources.diff/Index [27.8 kB] Get:5 http://deb.debian.org/debian unstable/non-free amd64 Packages.diff/Index [27.8 kB] Get:6 http://deb.debian.org/debian unstable/contrib amd64 Packages.diff/Index [27.8 kB] Get:7 http://deb.debian.org/debian unstable/main amd64 Packages.diff/Index [27.9 kB] Get:8 http://deb.debian.org/debian unstable/contrib Sources 2018-02-08-0244.34.pdiff [725 B] Get:9 http://deb.debian.org/debian unstable/contrib Sources 2018-02-08-0919.59.pdiff [450 B] Get:10 http://deb.debian.org/debian unstable/main Sources 2018-02-06-2026.31.pdiff [12.6 kB] Get:11 http://deb.debian.org/debian unstable/main Sources 2018-02-07-0231.38.pdiff [12.0 kB] Get:12 http://deb.debian.org/debian unstable/main Sources 2018-02-07-0824.55.pdiff [2263 B] Get:13 http://deb.debian.org/debian unstable/main Sources 2018-02-07-1427.34.pdiff [9180 B] Get:14 http://deb.debian.org/debian unstable/main Sources 2018-02-07-2028.51.pdiff [13.8 kB] Get:15 http://deb.debian.org/debian unstable/main Sources 2018-02-08-0244.34.pdiff [9073 B] Get:16 http://deb.debian.org/debian unstable/main Sources 2018-02-08-0919.59.pdiff [2808 B] Get:17 http://deb.debian.org/debian unstable/main Sources 2018-02-08-1427.47.pdiff [23.5 kB] Get:18 http://deb.debian.org/debian unstable/main Sources 2018-02-08-2039.02.pdiff [15.9 kB] Get:19 http://deb.debian.org/debian unstable/main Sources 2018-02-09-0244.28.pdiff [9256 B] Get:20 http://deb.debian.org/debian unstable/main Sources 2018-02-09-1007.33.pdiff [7287 B] Get:21 http://deb.debian.org/debian unstable/main Sources 2018-02-09-1423.20.pdiff [28.7 kB] Get:22 http://deb.debian.org/debian unstable/main Sources 2018-02-09-2039.28.pdiff [21.4 kB] Get:23 http://deb.debian.org/debian unstable/main Sources 2018-02-10-0230.03.pdiff [9215 B] Get:24 http://deb.debian.org/debian unstable/main Sources 2018-02-10-0831.26.pdiff [7817 B] Get:25 http://deb.debian.org/debian unstable/main Sources 2018-02-10-1428.30.pdiff [43.7 kB] Get:9 http://deb.debian.org/debian unstable/contrib Sources 2018-02-08-0919.59.pdiff [450 B] Get:26 http://deb.debian.org/debian unstable/non-free Sources 2018-02-08-0244.34.pdiff [678 B] Get:27 http://deb.debian.org/debian unstable/non-free Sources 2018-02-08-1427.47.pdiff [243 B] Get:28 http://deb.debian.org/debian unstable/non-free Sources 2018-02-09-0244.28.pdiff [604 B] Get:29 http://deb.debian.org/debian unstable/non-free Sources 2018-02-10-0230.03.pdiff [634 B] Get:30 http://deb.debian.org/debian unstable/non-free Sources 2018-02-10-0831.26.pdiff [387 B] Get:31 http://deb.debian.org/debian unstable/non-free amd64 Packages 2018-02-08-1427.47.pdiff [227 B] Get:32 http://deb.debian.org/debian unstable/non-free amd64 Packages 2018-02-10-0831.26.pdiff [353 B] Get:33 http://deb.debian.org/debian unstable/contrib amd64 Packages 2018-02-07-1427.34.pdiff [377 B] Get:34 http://deb.debian.org/debian unstable/contrib amd64 Packages 2018-02-08-0244.34.pdiff [423 B] Get:25 http://deb.debian.org/debian unstable/main Sources 2018-02-10-1428.30.pdiff [43.7 kB] Get:35 http://deb.debian.org/debian unstable/contrib amd64 Packages 2018-02-08-0919.59.pdiff [305 B] Get:36 http://deb.debian.org/debian unstable/contrib amd64 Packages 2018-02-09-1423.20.pdiff [31 B] Get:37 http://deb.debian.org/debian unstable/main amd64 Packages 2018-02-06-2026.31.pdiff [22.4 kB] Get:38 http://deb.debian.org/debian unstable/main amd64 Pa
Bug#864622: RFS: rich-minority/1.0.1-1 [ITP]
Dear Nicholas, On Mon, Aug 21 2017, Nicholas D Steeves wrote: > Would you like me to add this to the documentation? Of course I'll > also submit a patch upstream. Would be nice. > Also, please let me know if you're currently too busy to sponsor this > one. I can find an off-team sponsor if necessary. I won't be sponsoring this, I'm afaid. -- Sean Whitton signature.asc Description: PGP signature
Bug#833193: chapel/1.15 [ITP]
control: noowner -1 Dear Ben, On Wed, May 24 2017, Sean Whitton wrote: > I will continue as the reviewer and eventual sponsor of the chapel > source package itself (i.e. this RFS). Unfortunately, I'm going to have to renege on this. I recently got a new job within Debian, and the new semester is starting. I wish you the best of luck and hope that chapel is able to make its way into Debian soon. I hope my comments were helpful to that process. -- Sean Whitton signature.asc Description: PGP signature
Bug#859778: [supp...@mentors.debian.net: xtrs uploaded to mentors.debian.net]
Hello Branden, On Thu, Jun 15, 2017 at 04:35:23PM +0100, Sean Whitton wrote: > Please accept my apologies for letting this RFS sit for so long. Thank > you for all your work. Looking forward to uploading it soon. > > Here's a full review of dc84e1861798b3aba0969e2fe81a2431f2ee17de: Any progress on this? -- Sean Whitton signature.asc Description: PGP signature
Bug#868088: RFS: sysbench/1.0.8+ds-1 -- multi-threaded benchmark tool for database systems
control: owner -1 ! control: tag -1 +moreinfo Hello, On Tue, Jul 11, 2017 at 11:57:53PM +0200, JCF Ploemen wrote: > Changes since last upload: > * New upstream release. > * Patches: remove 02 and 05: merged upstream. > * Bump Standards-Version to 4.0.0 (from 3.9.8; no further changes). > * Control: limit build-depend on libaio-dev to linux-only. Could you explain the need for this change, please? Perhaps directly in the changelog. Also, you need to run `dch -r` -- the changelog timestamp is behind changes you've made. -- Sean Whitton signature.asc Description: PGP signature
Bug#851937: RFS: farbfeld/2.20170109-1 ITP
control: tag -1 +moreinfo On Wed, Jul 12, 2017 at 02:58:48PM +0200, Paride Legovini wrote: > Following up from the brief discussion we had on #debian-devel, here is > a tentative package: > > https://anonscm.debian.org/cgit/users/paride-guest/farbfeld.git/ Thanks again for your help with this RFS. Here is a review of 534d41f: - I think we should list Dmitry in the Uploaders: field, which would indicate that he may upload new versions of the package without it counting as an NMU - your git history does not really give credit to Dmitry for his work. I'd like to suggest starting again, and doing it like this: + clone Dmitry's repo + `git merge 3` to get the new upstream version + revert the convert commit (but see below) + apply your other changes - I also think it would be good to state in debian/changelog that most of the Debianisation is due to Dmitry - your changes to the patch header do not make sense: the '3..' will not yield "the changes made by the Debian maintainer in the first upload of upstream version 3". Please take another look at the template. - I disagree with you about Dmitry's `convert` patch. It just doesn't seem likely to me that there would be difficult merge conflicts with new upstream versions, and it is indeed useful to inform the user that convert is not available. But I will defer to your judgement -- if you're sure about dropping the patch, maybe imagemagick should be moved to a hard dependency? If you're able to address the issues I've raised in this message, please remove the moreinfo tag in this bug, and don't forget to re-run `dch -r` to refresh the changelog timestamp. -- Sean Whitton signature.asc Description: PGP signature
Bug#851937: RFS: farbfeld/2.20170109-1 ITP
Dear Paride, On Tue, Jul 11, 2017 at 12:56:48PM +0200, Paride Legovini wrote: > I'm not sure what's the best practice here, so before doing any further > work I'll wait for your opinion. Somehow this e-mail didn't reach me, so sorry for not replying. On Wed, Jul 12, 2017 at 02:58:48PM +0200, Paride Legovini wrote: > Following up from the brief discussion we had on #debian-devel, here is > a tentative package: > > https://anonscm.debian.org/cgit/users/paride-guest/farbfeld.git/ > > I adopted the dgit-maint-merge(7) workflow as Dmitry done initially. > After cloning the repository the package can be built like this: > > $ cd farbfeld > $ git deborig > $ dgit build -tc Thanks. Will review & hopefully upload soon. -- Sean Whitton signature.asc Description: PGP signature
Bug#864912: RFS: emacs-ivy/0.9.1+dfsg-1 [ITP]
Hello Nicholas, On Mon, Jun 26, 2017 at 07:58:54PM -0400, Nicholas D Steeves wrote: > Would you please upload src:emacs-ivy at commit 9776992 if there are > no further outstanding issues? doc/ivy-ox.el should not be installed, > (see commit 3f130b9). Sorry, I haven't had the opportunity to review it yet. -- Sean Whitton signature.asc Description: PGP signature
Bug#864912: RFS: emacs-ivy/0.9.1+dfsg-1 [ITP]
Hello Nicholas, On Fri, Jun 23, 2017 at 02:35:20PM -0400, Nicholas D Steeves wrote: > I wonder if we should generate printable keyboard shortcut pages in > PDF for all elpa modes that have an extensive set, and install those > to /usr/share/docs? If you can come up with a way to do it for every mode, sure. > Emacs-ivy-doc is also pretty much ready to upload to non-free/docs; I > just need to find out what I should build from the .texi--man page, > and info page? Man page, info page and html doc? Something else? Without looking at the source, Info and HTML sounds sensible. -- Sean Whitton signature.asc Description: PGP signature
Bug#859778: [supp...@mentors.debian.net: xtrs uploaded to mentors.debian.net]
control: tag -1 +moreinfo Dear Branden, Please accept my apologies for letting this RFS sit for so long. Thank you for all your work. Looking forward to uploading it soon. Here's a full review of dc84e1861798b3aba0969e2fe81a2431f2ee17de: Should be fixed === 1. Maybe we should just upload to unstable, DELAYED/7, because the freeze will be over this weekend? Would save another RFS next week. 2. Lintian says W: xtrs source: file-without-copyright-information .gitignore .gitignore is not copyrightable, so there is no bug, but I think it would be best to add a Lintian override. Then the package will be Lintian-clean. 3. The orig.tar doesn't seem to be the same as the one available from upstream: zephyr ~ % shasum tmp/xtrs-4.9d.tar.gz rfs/xtrs_4.9d.orig.tar.gz 72b99ede6e8024b8ade4f8aa22eb073078576e74 tmp/xtrs-4.9d.tar.gz 42b1fc90246901456d29071421e838b545f39f0f rfs/xtrs_4.9d.orig.tar.gz Do you know why? (I'm working from git, but I grabbed the orig.tar from mentors.) 4. A few things not mentioned in the changelog: - new d/clean - new d/watch - deleted d/dirs - debhelper compat bump - rewrite d/rules & switch to use dh sequencer (not the same as compat bump) - add d/xtrs.install - std-ver bump (it would be reassuring to see "no changes required") - new build deps, e.g. bsdmainutils (btw, really nice commenting of the build-deps) - postinst tidied up (changes to maintscripts should always be mentioned in the changelog, since they are such a frequent source of bugs) - various patches in d/patches are not in d/changelog. it might also be a good idea to give the patch name, instead of just the file modified, so someone can track down the change 5. Copyright file issues: - id.po and nl.po seem to have broken template "Copyright (C)" lines. - you need entries in d/copyright for the *.po files. Or you could just add the author's names to the stanza for debian/*. - The FSF hold copyright on some code in *-idiomatize-manpage.patch Suggestions === 1. You could use debhelper compat 10. 2. You could uncomment Vcs-* and fill in the address of your alioth repo. 3. Typo "appply" in xtrs.doc-base.cpmutil. 4. I think that cpmutil.dsk and utility.dsk should go into /usr/share/xtrs not /usr/lib/xtrs, since they are binary but not architecture-dependent 5. emtsafe-flag-on-by-default.patch would benefit from a description explaining why it's a good idea. If you're able to address the issues I've raised in this message, please remove the moreinfo tag in this bug, and don't forget to re-run `dch -r` to refresh the changelog timestamp. -- Sean Whitton signature.asc Description: PGP signature
Bug#864626: RFS: visual-fill-column/1.11-1 [ITP]
Hello Nicholas, On Tue, Jun 13, 2017 at 09:49:33PM -0400, Nicholas D Steeves wrote: > Brilliant, in that case no one would have been bothered by this > redundant RFS! ;-) Would you please grant DM permissions for > visual-fill-column? It would be best to ask the person who uploaded the package. -- Sean Whitton signature.asc Description: PGP signature
Bug#864622: RFS: rich-minority/1.0.1-1 [ITP]
Hello Nicholas, On Tue, Jun 13, 2017 at 09:39:43PM -0400, Nicholas D Steeves wrote: > Phase four: Do you think that it would be useful to have > d/package.convert-to-info, d/package.convert-to-text, etc? This would > allow a plain d/rules. This probably wouldn't work because each conversion will probably need particular options and fixups. I also doubt the debhelper maintainers would want to add those files. > Alternatively, it might be a better use of time to just write a > Makefile to generate the docs for each package, and then submit those > to upstreams. What do you think? > [...] > What do you think? Does this sound like a good proposal? When should > I email pkg-emacsen? After Stretch is released? As a rule of thumb it's better to have things merged upstream. I don't think we need any kind of team policy on this. It's not an Emacs-specific issue. Packagers can handle the documentation as they would for any other package. And for elpa-* packages, it's almost always just a README, which can remain in Org/Markdown/plain text. > Hmm, so the question comes down to how committed and able I am to get > rich-minority (and smart-mode-line for that matter) to work with a > potential default of emacs26 for Buster? Chances are it will Just Work. New releases of Emacs do not break very many things. So I would upload it to unstable once you've run it locally for a week or so. > Most packages have a fairly short "long description" so I've been > operating under the assumption that it is supposed to be less than 25 > lines long, with 24 lines preferred. You wouldn't want it to be pages and pages. But feel free to go over 25 lines. > > diminish.el works like this: > > > > (diminish 'auto-fill-function) > > > > That's it. Clearly simpler. > > Does this hide "Fill" from the modeline? Does a subsequent > > (diminish 'flyspell-mode) > > concatenate Fly|Flyspell to the list of minor modes that will be > hidden? Yes. > For now, do you think I should create a README.Debian with these > examples or wait for upstream to merge them? I don't think you need to do either. Just mention that it's meant to be a more flexible/improved version of diminish.el. -- Sean Whitton signature.asc Description: PGP signature
Bug#864622: RFS: rich-minority/1.0.1-1 [ITP]
Hello Nicholas, On Mon, Jun 12, 2017 at 07:33:12PM -0400, Nicholas D Steeves wrote: > Would it be better to ship README.org and file a bug against the > package myself? Yes. Why not ship README.org in the interim? > I still don't have a plan for Policy 12.4, and am currently wondering > if further conversion of README.html to README using html2txt (if > pandoc cannot do this) would be best, because the expectation is that > the upstream README found in /usr/share/doc is a plain text file. I don't think Policy 12.4 really applies to READMEs. It says "extensive documentation", and a README is not extensive documentation. Policy 12.4 is basically saying "ship HTML instead of PDF". > So this?: > > - Copyright: 2014, 2015 Free Software Foundation, Inc. > -2014-2016 Artur Malabarba <em...@endlessparentheses.com> > > +Copyright: 2014-2016 Free Software Foundation, Inc. > + Yes. > > - your rationale for uploading to experimental applies to > > smart-mode-line, but why not upload rich-minority to unstable? Is > > it similarly untested? Maybe we should just wait a few weeks. > > If you'd prefer I'd be happy to wait a few weeks. In terms of > worst-case scenario planning: If for some reason smart-mode-line > upstream didn't add emacs26 compatibility in time for Buster's freeze, > and I (or someone from pkg-emacsen) didn't have time to add it, then > should rich-minority still be part of Buster? It would depend on whether a user of buster gets emacs25 or emacs26 if they type "apt-get install emacs". > How many lines can I dedicate to this? By my count I need to > summarise the following in five lines, and the most salient additions > are the mention of diminish.el, plus compare/contrast by adding what I > suspect are the two most salient points. > * "/missing/...quick and simple replacement functionality" > * the addition of "It accepts *regexps* instead of [individual > specifications]". Where are you getting this line limit from? > These two points seem contradictory to me. Do you know how > diminish.el is more quick and simple? Also, can I use your answer for > a patch against the upstream description, because I might not be the > only one who's not confused about this. Failing that, I can open an > upstream issue/request for clarified description. diminish.el works like this: (diminish 'auto-fill-function) That's it. Clearly simpler. -- Sean Whitton signature.asc Description: PGP signature
Bug#864626: RFS: visual-fill-column/1.11-1 [ITP]
On Mon, Jun 12, 2017 at 05:35:21PM -0400, Nicholas D Steeves wrote: > I do not yet have DM privileges for this package, but if I had > uploaded the new build (with the same version) using dput, would it > have been rejected? Yes. -- Sean Whitton signature.asc Description: PGP signature
Bug#864622: RFS: rich-minority/1.0.1-1 [ITP]
Hello, On Sun, Jun 11 2017, Nicholas D Steeves wrote: > I am looking for a sponsor for my package "rich-minority" > > Package name : rich-minority Version : 1.0.1-1 Here's a review of bc58ab0a49df6002e4e034cea8c1398fd7407322: - why not just install README.org as it is? - the file is not copyright Artur Malabarba. It looks like he assigned copyright to the FSF - your rationale for uploading to experimental applies to smart-mode-line, but why not upload rich-minority to unstable? Is it similarly untested? Maybe we should just wait a few weeks. - it might be a good idea to mention diminish.el in the description -- Sean Whitton signature.asc Description: PGP signature
Bug#860496: RFS: drgeo/1.1.0-10.3 [NMU, RC]
Dear Patrick, Please accept my apologies for allowing this RFS to fall through the cracks. On Fri, Apr 21, 2017 at 08:30:00AM -0400, Patrick Hetu wrote: > The new version is here: > > https://mentors.debian.net/debian/pool/main/d/drgeo/drgeo_1.1.0-10.3.dsc You've written - All modifications to .scm, .cc and .h files are compatibility fixes for guile-2.x. Except comments in geo/drgeo_figure.cc that are disabling undo/redo mecanisms that are causing a segfault. So the commenting out of the undo/redo mechanism isn't part of making drgeo compatible with guile 2.0? In that case, it should be in a separate quilt patch. Additionally, the new line in d/rules cp -vf /usr/share/gettext/config.rpath . is not documented in the changelog. More generally, per Adam, maybe we should just remove drgeo from Debian. The current version is 16 and we are still on version 1.1 .. would anyone want to install this? -- Sean Whitton signature.asc Description: PGP signature
Bug#833193: chapel/1.15 [ITP]
Hello Ben, On Thu, May 25, 2017 at 08:11:30PM +, Ben Albrecht wrote: > We'll let you know when we have the next version ready. Okay. To do this, you can just remove the 'moreinfo' tag from this RFS bug. > OK, for now we will only pursue a minimal version and leave > packaging the other third-party dependencies as future work. It would be good to document this in debian/README.source inside the package. You could put the table you wrote up in that file. That way, other Debian contributors who are interested in chapel could get involved with getting the dependencies in shape. -- Sean Whitton signature.asc Description: PGP signature
Bug#860206: RFS: sysbench
control: tag -1 +moreinfo Hello, Here is a review of 5a5d084bf540c903d4ea19f9761da2d6b38b3907: - It FTBFS. I've attached a log. - New file d/clean not mentioned in changelog. - Changelog typo "priastine-tar". - Did you run `wrap-and-sort`? It's conventional to say in the changelog that you ran it, giving the options you used, so someone else can run it with the same options if they do an NMU/etc. - I think that the "Manpage" section of the changelog could be clearer. You don't mention the new filename "manpage.txt", and you don't mention that you're now using txt2man (except in the d/control changes). - The patch header of 01_ could be enhanced with an explanation of why the third_party dir is included (I think I can guess, but it would be better explicitly stated) - Have you forwarded 02_ upstream? The DEP-3 patch header format can make this easier to indicate. - If you want to keep the "# you guessed :)" I think it would be best to use DEP-3's Description: field, otherwise it's not obvious why the comment line is there. - Patch 04_ definitely needs an explanation in the patch header as to why it's a good idea to strip it - Are you sure the upstream license is GPL-2, not GPL-2+? - src/xoroshiro128plus.h, m4/lib-ld.m4 missing from d/copyright An optional wishlist item: - crc32tbl.h is a generated file, and ideally it would be regenerated during the package build. If you're able to address the issues I've raised in this message, please remove the moreinfo tag in this bug, and don't forget to re-run `dch -r` to refresh the changelog timestamp. -- Sean Whitton sbuild (Debian sbuild) 0.73.0 (23 Dec 2016) on zephyr.silentflame.com +==+ | sysbench 1.0.6+ds-1 (i386) Fri, 19 May 2017 06:58:44 + | +==+ Package: sysbench Version: 1.0.6+ds-1 Source Version: 1.0.6+ds-1 Distribution: experimental Machine Architecture: i386 Host Architecture: i386 Build Architecture: i386 Build Type: binary I: NOTICE: Log filtering will replace 'var/run/schroot/mount/unstable-i386-sbuild-afa975e8-4d29-4456-8230-88a7e11336b9' with '<>' +--+ | Update chroot| +--+ Get:1 http://cdn-fastly.deb.debian.org/debian unstable InRelease [237 kB] Get:2 http://cdn-fastly.deb.debian.org/debian unstable/main Sources.diff/Index [27.9 kB] Get:3 http://cdn-fastly.deb.debian.org/debian unstable/main i386 Packages.diff/Index [27.9 kB] Get:4 http://cdn-fastly.deb.debian.org/debian unstable/main Sources 2017-05-18-0829.06.pdiff [2941 B] Get:5 http://cdn-fastly.deb.debian.org/debian unstable/main Sources 2017-05-18-1430.00.pdiff [3398 B] Get:6 http://cdn-fastly.deb.debian.org/debian unstable/main Sources 2017-05-18-2029.20.pdiff [3961 B] Get:7 http://cdn-fastly.deb.debian.org/debian unstable/main Sources 2017-05-19-0229.06.pdiff [851 B] Get:7 http://cdn-fastly.deb.debian.org/debian unstable/main Sources 2017-05-19-0229.06.pdiff [851 B] Get:8 http://cdn-fastly.deb.debian.org/debian unstable/main i386 Packages 2017-05-18-0829.06.pdiff [4548 B] Get:9 http://cdn-fastly.deb.debian.org/debian unstable/main i386 Packages 2017-05-18-1430.00.pdiff [1848 B] Get:10 http://cdn-fastly.deb.debian.org/debian unstable/main i386 Packages 2017-05-18-2029.20.pdiff [2917 B] Get:11 http://cdn-fastly.deb.debian.org/debian unstable/main i386 Packages 2017-05-19-0229.06.pdiff [33.9 kB] Get:11 http://cdn-fastly.deb.debian.org/debian unstable/main i386 Packages 2017-05-19-0229.06.pdiff [33.9 kB] Fetched 347 kB in 4s (79.3 kB/s) Reading package lists... Reading package lists... Building dependency tree... Reading state information... Calculating upgrade... The following packages will be upgraded: dpkg dpkg-dev libdpkg-perl 3 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 5009 kB of archives. After this operation, 105 kB of additional disk space will be used. Get:1 http://cdn-fastly.deb.debian.org/debian unstable/main i386 dpkg i386 1.18.24 [2134 kB] Get:2 http://cdn-fastly.deb.debian.org/debian unstable/main i386 dpkg-dev all 1.18.24 [1592 kB] Get:3 http://cdn-fastly.deb.debian.org/debian unstable/main i386 libdpkg-perl all 1.18.24 [1283 kB] debconf: delaying package configuration, since apt-utils is not installed Fetched 5009 kB in 4s (1079 kB/s) (Reading database ... (Reading database ... 5% (Reading database ... 10% (Reading database ... 15% (Reading database ... 20% (Reading database ... 25% (Reading database ... 30% (Reading database ... 35% (Reading database ... 40% (Reading database ... 45% (Reading database ... 50% (Reading database ... 55% (Reading datab
Bug#861699: RFS: writegood-mode/2.0.2-1 [ITP]
control: owner -1 ! control: tag -1 +moreinfo On Tue, May 02, 2017 at 04:58:31PM -0400, Nicholas D Steeves wrote: > I am looking for a sponsor for my package "writegood-mode" a5b0ac4 looks good, except I think you should install the README, which could be quite useful to users. If you're able to address the issues I've raised in this message, please remove the moreinfo tag in this bug, and don't forget to re-run `dch -r` to refresh the changelog timestamp. -- Sean Whitton signature.asc Description: PGP signature
Bug#833193: RFS: chapel/1.15-1 [ITP]
Dear Lumin, On Thu, May 04, 2017 at 02:06:10PM +, Lumin wrote: > I quickly went through the packaging, and had some comments about it: Thank you for your input. I agree with all of it except: > * debian/changelog: > currently Debian is still in the deep freeze stage, I'd recommend > you upload to experimental > first. Besides, experimental is more fault-tolerant. This is not needed for completely NEW packages. We should upload this to unstable. -- Sean Whitton signature.asc Description: PGP signature
Bug#861634: RFS: multimc/0.5.1-1 [ITP] -- A free, open source launcher for Minecraft
control: tag -1 +moreinfo On Mon, May 01, 2017 at 10:40:06PM -0500, Zebulon McCorkle wrote: > Â dget -x > https://mentors.debian.net/debian/pool/main/m/multimc/multimc_0.5.1-1.dsc 404. Since this software requires Minecraft, which is non-free, it will need to go into contrib, not main. -- Sean Whitton signature.asc Description: PGP signature
Bug#861368: RFS: helm/2.5.0-2 [Team Upload]
On Fri, Apr 28, 2017 at 05:47:13AM +, Gianfranco Costamagna wrote: > in deferred/2, so Sean can review changes if needed :) LGTM. Rescheduled to 0-day. Thanks again. -- Sean Whitton signature.asc Description: PGP signature
Bug#833193: RFS: chapel/1.15-1 [ITP]
control: tag -1 -moreinfo control: retitle -1 RFS: chapel/1.15-1 [ITP] Dear Ben, On Fri, Apr 28, 2017 at 08:48:00PM +, Ben Albrecht wrote: > Thanks for your feedback. Below are: > * some responses to your questions > * a description of some major changes recently incorporated in the >package > * some questions about the long-term plans of a fully featured >(non-minimal) Chapel package. Thank you for all this. I'm very busy for the next two to three weeks, so I wanted to let you know it'll be a little while before I get to this -- but I will get to it. -- Sean Whitton signature.asc Description: PGP signature
Bug#861368: RFS: helm/2.5.0-2 [Team Upload]
Hello Gianfranco, On Fri, Apr 28, 2017 at 05:47:13AM +, Gianfranco Costamagna wrote: > in deferred/2, so Sean can review changes if needed :) Thanks for uploading -- could you reschedule an extra 2 or 3 days please? I am currently moving house. -- Sean Whitton signature.asc Description: PGP signature
Bug#859778: RFS: xtrs/4.9d-3
Hello Branden, On Sat, Apr 22, 2017 at 03:41:48PM -0400, G. Branden Robinson wrote: > > 1) How about merging the -1, -2 and -3~~unreleased changelog entries > > into a single entry, since we're doing a single upload? > > Won't that prompt the question of what happened to -1 and -2? > > Or do you mean renumber -3 as -1? And move the git tags? On Sat, Apr 22, 2017 at 04:12:38PM -0400, G. Branden Robinson wrote: > Hmm, did you notice that: > > 1) Almost all the changes to upstream code are in release -3? > and > 2) Almost all the changes to packaging are in releases -1 and -2? > > So, to be clear, you're asking me to coalesce all the changelog entries > since 4.9c together and then split them up in a different way, which > less accurately reflects the actual history of recent development? > > Can you explain your reasoning here? Currently, almost all Debian packagers/maintainers use one changelog entry and version number per upload. So if there are rounds of review in an RFS, new changes are folded into the previous changelog entry. My concern is simply that it could be misleading to break this convention. Someone might think that there were -1, -2 and -3 uploads to the archive. Jumping straight to -3 could also be confusing, so it would probably be best to merge the changes in -3 and -2 into -1. The actual history of development is available from the git history, which I will push to https://browse.dgit.debian.org/ as part of the upload. So we're not throwing away any information. I guess that the older practice of using a new version number for each round of review is due to the difficulties created by exchanging raw source packages. But we are using git. On Sat, Apr 22, 2017 at 03:41:48PM -0400, G. Branden Robinson wrote: > > Also, could you confirm that your changes have been forwarded upstream? > > Yes, I emailed some of them to Tim Mann on 3 April, and the rest on 17 > April. I think there were some cosmetic changes to the man pages after > that. Great. Thanks for confirming. -- Sean Whitton signature.asc Description: PGP signature
Bug#859778: RFS: xtrs/4.9d-3
control: tag -1 +moreinfo Hello Branden, I can't get 79e8ccf40499ace8cf36210a7ad9fb157209bbe4 to build. Log attached. Given this problem I haven't done a full review, but I'd like to make two preliminary suggestions: 1) How about merging the -1, -2 and -3~~unreleased changelog entries into a single entry, since we're doing a single upload? 2) You have made a very large number of changes to the upstream source by means of debian/patches. How about separating the changelog into two sections, something like this: Debian packaging changes: * Migrate to new (to me) quilt-based Debian source format 3.0. + Migrate former contents of debian/patches to debian/patch/*; dropping patches now merged upstream. [...] Debian patches to upstream source: * Makefile: Observe LDFLAGS when building internal "compile_rom" tool. Thanks to Graham Inggs for the discussion! (Closes: #859751) [...] Also, could you confirm that your changes have been forwarded upstream? If you're able to address the issues I've raised in this message, please remove the moreinfo tag in this bug, and don't forget to re-run `dch -r` to refresh the changelog timestamp. -- Sean Whitton sbuild (Debian sbuild) 0.73.0 (23 Dec 2016) on iris.silentflame.com +==+ | xtrs 4.9d-3~~unreleased (amd64) Sat, 22 Apr 2017 14:10:34 + | +==+ Package: xtrs Version: 4.9d-3~~unreleased Source Version: 4.9d-3~~unreleased Distribution: unstable Machine Architecture: amd64 Host Architecture: amd64 Build Architecture: amd64 Build Type: binary I: NOTICE: Log filtering will replace 'var/run/schroot/mount/unstable-amd64-sbuild-1c7e7da3-66f5-484d-b0c9-cc3f8abf0834' with '<>' +--+ | Update chroot| +--+ Get:1 http://cdn-fastly.deb.debian.org/debian unstable InRelease [237 kB] Get:2 http://cdn-fastly.deb.debian.org/debian unstable/main Sources.diff/Index [27.9 kB] Get:3 http://cdn-fastly.deb.debian.org/debian unstable/main amd64 Packages.diff/Index [27.9 kB] Get:4 http://cdn-fastly.deb.debian.org/debian unstable/main Sources 2017-04-22-0825.50.pdiff [751 B] Get:4 http://cdn-fastly.deb.debian.org/debian unstable/main Sources 2017-04-22-0825.50.pdiff [751 B] Get:5 http://cdn-fastly.deb.debian.org/debian unstable/main amd64 Packages 2017-04-22-0825.50.pdiff [401 B] Get:5 http://cdn-fastly.deb.debian.org/debian unstable/main amd64 Packages 2017-04-22-0825.50.pdiff [401 B] Fetched 294 kB in 2s (138 kB/s) Reading package lists... Reading package lists... Building dependency tree... Reading state information... Calculating upgrade... 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. +--+ | Fetch source files | +--+ Local sources - /home/spwhitton/rfs/xtrs_4.9d-3~~unreleased.dsc exists in /home/spwhitton/rfs; copying to chroot I: NOTICE: Log filtering will replace 'build/xtrs-A2adR8/xtrs-4.9d' with '<>' I: NOTICE: Log filtering will replace 'build/xtrs-A2adR8' with '<>' +--+ | Install build-essential | +--+ Setup apt archive - Merged Build-Depends: build-essential, fakeroot Filtered Build-Depends: build-essential, fakeroot dpkg-deb: building package 'sbuild-build-depends-core-dummy' in '/<>/resolver-Zssg9G/apt_archive/sbuild-build-depends-core-dummy.deb'. dpkg-scanpackages: warning: Packages in archive but missing from override file: dpkg-scanpackages: warning: sbuild-build-depends-core-dummy dpkg-scanpackages: info: Wrote 1 entries to output Packages file. Ign:1 copy:/<>/resolver-Zssg9G/apt_archive ./ InRelease Get:2 copy:/<>/resolver-Zssg9G/apt_archive ./ Release [957 B] Ign:3 copy:/<>/resolver-Zssg9G/apt_archive ./ Release.gpg Get:4 copy:/<>/resolver-Zssg9G/apt_archive ./ Sources [349 B] Get:5 copy:/<>/resolver-Zssg9G/apt_archive ./ Packages [432 B] Fetched 1738 B in 0s (0 B/s) Reading package lists... Reading package lists... Install core build dependencies (apt-based resolver) Installing build dependencies Reading package lists... Building dependency tree... Reading state information... The following NEW packages will be installed: sbuild-build-depends-core-dum
Re: I have some questions about alioth repository
On Fri, Apr 21, 2017 at 05:37:19PM +0900, JungHwan Kang wrote: > 4. Some packages don't have repository(No repository found by debcheckout > tool) > > Â Â Â like acpi, alsamixergui, apg, aspell-en, autoconf. > > Â Â Â Are there repositories for source code of those packages ? > % dgit clone acpi -- Sean Whitton signature.asc Description: PGP signature
Bug#859778: RFS: xtrs/4.9d-2
Hello Branden, On Thu, Apr 20, 2017 at 04:58:03PM -0400, G. Branden Robinson wrote: > Sure am. In fact I have xtrs 4.9d-3 pretty much ready to go except for > the official versioning and tagging. I've also been in touch with > upstream; he's been working on an xtrs 5.0 for quite some time. :) > > See attachments. I've also pushed my work to alioth. Please remove the moreinfo tag from the bug when it's ready to be uploaded. -- Sean Whitton signature.asc Description: PGP signature
Bug#859778: RFS: xtrs/4.9d-2
Hello Branden, On Wed, Apr 12, 2017 at 11:09:45PM -0400, G. Branden Robinson wrote: > Yeah, I didn't understand that at the time. Subsequently I changed all > the 4.9d changelog entries to target experimental. > > > Thus, it'd be better to target the new version at experimental instead > > (or refrain from updates for now -- but that goes against "release > > early, release often" and makes debdiffs far harder to read). > > It sounds like I should maybe just forget about -2 and upload -3. I had > one more thing I wanted to do for it but it's a big task, rather > involved, and not required. What is the status of this RFS? Are you still working on the upload to experimental? Thanks! -- Sean Whitton signature.asc Description: PGP signature
Bug#860466: RFS: equivs/2.0.10 [QA] -- Circumvent Debian package dependencies
control: tag -1 +moreinfo Dear Roger, On Wed, Apr 19, 2017 at 09:10:52AM +0900, Roger Shimizu wrote: > And I pushed my fixes to branch qa_upload2. > (I removed the final releasing commit of branch qa_upload, and added update > commit) I'd like to note that I'm planning to upload with dgit, so you shouldn't rebase after the upload. It's okay to rebase before the upload. > Indeed. > The new d/copyright was generated by decopy. > I think it's just have issue to support native package, or 1.0 source format, > when I invoked decopy command. (I changed to 3.0 native afterwards) > > Now I merged two parts. > New entries are catched by decopy, which find it in d/changelog, I think. Good, thanks. > > d/changelog: > > > > - You should include in the changelog that you updated the Maintainer: > > field (not every QA upload does this). It's also good to write > > something like (see #xx) where that's the number of the orphaning > > bug. > > Fixed. The changelog still doesn't say that the Maintainer: field has been updated. If you're able to address the issues I've raised in this message, please remove the moreinfo tag in this bug, and don't forget to re-run `dch -r` to refresh the changelog timestamp. -- Sean Whitton signature.asc Description: PGP signature
Bug#860466: RFS: equivs/2.0.10 [QA] -- Circumvent Debian package dependencies
control: tag -1 +moreinfo On Wed, Apr 19, 2017 at 09:10:52AM +0900, Roger Shimizu wrote: > Thanks for your review! No problem. > I think these are all simple fix that suitable for stretch. > The policy don't require pre-approval to upload to unstable [0]. > > If the unblock is rejected, and someone need to to fix another RC bug for > this package, it's still possible since we have "testing-proposed-updates" > [0]. I think you've misunderstood both the freeze policy, and testing-proposed-updates. Firstly, most/all of your changes fail to satisfy any of the bullet points under "Changes which can be considered" in the freeze policy. So the unblock request will be denied. Secondly, testing-proposed-updates is highly inconvenient for the release team. It requires manual intervention and slows everything down. So we shouldn't upload to unstable unless we *expect* it to be unblocked. -- Sean Whitton signature.asc Description: PGP signature
Bug#860466: RFS: equivs/2.0.10 [QA] -- Circumvent Debian package dependencies
control: tag -1 +moreinfo Dear Roger, On Mon, Apr 17, 2017 at 08:25:16PM +0900, Roger Shimizu wrote: > I am looking for a sponsor for my package "equivs" Thanks for working on all these improvements and fixes. Here is a review of 9818bd99a15efbbbf37eace90480f69e682f2e8f: - Shouldn't this target experimental, not unstable, due to the freeze? - In the old copyright file, there was a single list of copyright holders, but you have generated two lists, for * and for debian/*. How did you determine this? Based on d/changelog? I'm not sure that is sufficiently reliable. To be safe, it might be best to just have a "Files: *" stanza for everything -- I'm not sure. d/changelog: - You should include in the changelog that you updated the Maintainer: field (not every QA upload does this). It's also good to write something like (see #xx) where that's the number of the orphaning bug. - You wrote "fix typos" in README.Debian, but the errors were not typos (typos means "typographical errors"). They were just errors. So I would suggest s/typos/minor errors/ or even s/typos/references/. - I think you should say that no changes were required when bumping the std-ver in the template. - You should say that you are bumping the debhelper compat level, not the "debhelper version" -- Sean Whitton signature.asc Description: PGP signature
Bug#860496: RFS: drgeo/1.1.0-10.3 [NMU, RC]
control: tag -1 +moreinfo On Mon, Apr 17, 2017 at 05:59:11PM -0400, Patrick Hetu wrote: > * Fixed compatibility with Guile 2.0. (Closes: #707903) Thank you for your work to fix this bug. What is the source of the patch you have added? It is not indicated anywhere. Did it come from upstream? Maybe we should just update to a new upstream version? Also, your changelog needs to be much more detailed. You should list each change to the debian/ directory on its own line. For example, the changes to d/rules and d/control. Further, since this is an NMU and now a QA upload, it is inappropriate to bump the standards version. You should limit your changes to those necessary to fix the RC bug. -- Sean Whitton signature.asc Description: PGP signature
Bug#860206: RFS: sysbench/1.0.5-1 [ITA] -- multi-threaded benchmark tool for database systems
Thank you for your work to adopt this package. I'd like to review and hopefully sponsor this upload. I do require that we work out of git, instead of exchanging source packages via mentors.debian.net. I recommend the git workflow described in dgit-maint-merge(7), but any dgit-compatible workflow is fine -- see the other dgit-maint-*(7) manpages, and dgit-sponsorship(7). When you publish a packaging branch for me to review, it should be fast-forwarding, i.e., you should not rewrite history during the review process (or indeed, after). If this is acceptable to you, please set me as the owner of this RFS bug, and let me know where I can find your git branch. Otherwise, you are quite free to wait for a different potential sponsor. One point I noticed from your changelog: when you bump the std-ver, it is conventional to note "no changes required" if you bumped it without changing anything to be compliant with the new version. -- Sean Whitton signature.asc Description: PGP signature
Bug#859606: RFS: gnome-shell-extension-tilix-dropdown/5-1 ITP: 858259 -- launch tilix in quake-mode from gnome-shell
control: tag -1 +moreinfo Hello Jonathan, On Wed, Apr 05, 2017 at 09:37:41AM +0200, Jonathan Carter (highvoltage) wrote: > I am looking for a sponsor for my package > "gnome-shell-extension-tilix-dropdown": Surely this package should depend on tilix? -- Sean Whitton signature.asc Description: PGP signature
Bug#858800: RFS: xtrs/4.9d-1 [ITA]
control: owner -1 ! Hello Branden, On Fri, Mar 31, 2017 at 07:40:51PM -0400, G. Branden Robinson wrote: > I've reuploaded 4.9c-4. I can't find this on mentors... As I said, an e-mailed debdiff would be fine at this point. > Please find attached two files which were not dput, which you may wish > to peruse for QA purposes: Thank you for these! -- Sean Whitton signature.asc Description: PGP signature
Bug#858800: RFS: xtrs/4.9d-1 [ITA]
Hello Branden, On Thu, Mar 30, 2017 at 06:13:35PM -0400, G. Branden Robinson wrote: > Yes, it was. Either the build-dep on groff was always too strong or > groff-base got split out at some point in the past decade (or a little > more). > > Would you like me to rebuild? Will I be able to overwrite -4 will a > fresher upload? Yes, mentors will let you overwrite. Or you could just send me an updated debdiff, since it's tiny, and I can apply it to the current version in the archive. Whichever you prefer. -- Sean Whitton signature.asc Description: PGP signature
Bug#858800: RFS: xtrs/4.9d-1 [ITA]
Dear Branden, On Thu, Mar 30, 2017 at 09:29:25AM -0400, G. Branden Robinson wrote: > It can. I've uploaded xtrs 4.9c-4 with a far leaner set of changes, and > am attaching a diff of the diff to this message. As you can see, it's > far leaner. > > Thoughts? Was the Build-Depends change intentional? It's not in the changelog. -- Sean Whitton signature.asc Description: PGP signature
Bug#858800: RFS: xtrs/4.9d-1 [ITA]
Hello Branden,
On Tue, Mar 28, 2017 at 08:29:38PM -0400, G. Branden Robinson wrote:
> > On Tue, Mar 28, 2017 at 05:28:25PM -0400, G. Branden Robinson wrote:
> > > So my goals were, in this order:
> > > 1) Get the package suitable for unstable (which it wasn't); then
> > > 2) Get the package suitable for testing.
>
> It'll be suitable for testing for Buster, that's for sure. My bad luck
> to return during a release freeze.
Right. But your wording ("then") suggested that (2) could be done
exclusively of (1).
> I'm interested in the least-effort solution (for other people) that
> doesn't involve shipping a badly broken package in Stretch.
Well, letting it drop out of testing is technically the least-effort
solution.
--
Sean Whitton
signature.asc
Description: PGP signature
Bug#858800: RFS: xtrs/4.9d-1 [ITA]
Hello Branden, On Tue, Mar 28, 2017 at 05:28:25PM -0400, G. Branden Robinson wrote: > > You are very unlikely to get release team approval for this upload as it > > stands. Given what you wrote in #511645, is your intention for xtrs to > > drop out of stretch, to be reintroduced in buster? > > I've been making conservative (pessimistic) estimates about how fast I'd > be getting things done since I'm freshly back to the project after a > long absence. There were and are best practices I need(ed) to get > caught up on. I also couldn't be absolutely sure I'd get a sponsor > before the removal-from-testing date (scheduled for 11 April); I don't > know when I'll be able to get my new GPG key into the Debian keyring so > that I can upload under my own power[1], and so forth. Finally, I don't > want to cause the release team any trouble. > > So my goals were, in this order: > 1) Get the package suitable for unstable (which it wasn't); then > 2) Get the package suitable for testing. Generally speaking, something shouldn't go into unstable unless it would also be suitable for testing (once deps and r-deps are also ready to migrate). -- Sean Whitton signature.asc Description: PGP signature
Bug#858538: RFS: fadecut/0.2.0-1
Dear Marco, On Tue, Mar 28, 2017 at 01:51:18PM +0200, Marco Balmer wrote: > Is the package quality from your view ok? Sorry, I haven't reviewed it. -- Sean Whitton signature.asc Description: PGP signature
Bug#832941: RFS: 4pane
Dear David, On Tue, Mar 28, 2017 at 01:36:03PM +0100, David Hart wrote: > Hmm, I can't make it fail here. e.g. Sorry, I assumed that uscan would redownload the .pgp file, but it was using the old one. Apologies for wasting your time with that. While you previously said that everything remaining in .build/ is your own work, the file wxwin.m4 is not yours. So that needs to be added to d/copyright. The patch header for ChangeToAutomakeBuild.patch does not make sense... These two are the only remaining issues in d35ef45. As a suggestion, strictly optional: I also noticed that you often cram several copyright lines into a single line. Please consider using line breaks. E.g. Copyright: 2005-2014, Mike Hommey <gland...@debian.org> 1998-2010, Mozilla Project instead of Copyright: 2005-2014, Mike Hommey <gland...@debian.org> 1998-2010, Mozilla Project Similarly for some Files: fields. If you're able to address the issues I've raised in this message, please remove the moreinfo tag in this bug, and don't forget to re-run `dch -r` to refresh the changelog timestamp. -- Sean Whitton signature.asc Description: PGP signature
Bug#858538: RFS: fadecut/0.2.0-1
control: tag -1 +moreinfo Dear Marco, On Thu, Mar 23, 2017 at 09:47:44AM +0100, Marco Balmer wrote: > Changes since the last upload: > > fadecut (0.2.0-1) unstable; urgency=low > > [...] These changes are not appropriate during the current freeze. If you want to upload this as-is, you will need to target experimental. -- Sean Whitton signature.asc Description: PGP signature
Bug#858800: RFS: xtrs/4.9d-1 [ITA]
control: tag -1 +moreinfo Dear Branden, On Sun, Mar 26, 2017 at 06:45:34PM -0400, Branden Robinson wrote: > Changes since the last upload: > > * Merge new upstream release. > + "Deleted all SIGIO code. The code was a kludge to begin with and it no > longer worked with current X libraries and Linux kernels, causing xtrs > to hang. It was also reported to cause hangs when xtrs was compiled for > Windows using Cygwin. Thanks to Howard Pepper, Dennis Lovelady, Arumin > Nueckel, Christopher Currie, and Joe Peterson for bug reports." > (Closes: #511645) Is it impossible to backport this fix to the version currently in stretch? You are very unlikely to get release team approval for this upload as it stands. Given what you wrote in #511645, is your intention for xtrs to drop out of stretch, to be reintroduced in buster? -- Sean Whitton signature.asc Description: PGP signature
Bug#832941: RFS: 4pane
Dear David, I can't review your latest work because the PGP signature for the tarball fails to verify: iris ~/rfs/4pane % origtargz -u W: Unable to locate package 4pane Trying uscan --download-current-version ... uscan: Newest version of 4pane on remote site is 4.0, specified download version is 4.0 gpgv: Signature made Wed 22 Mar 2017 01:04:44 PM MST gpgv:using RSA key D594F63B22250D6A gpgv: BAD signature from "David Hart <deb...@4pane.co.uk>" uscan warn: OpenPGP signature did not verify. Could not find any location for 4pane_4.0+dfsg.orig.tar.* I guess that you haven't uploaded an updated signature. I tried to verify the change by comparing the tarballs with diffoscope, to work around this, but the paths within the tarball have changed (4pane-4.0/ -> ./4pane-4.0/) so that is not feasible. -- Sean Whitton signature.asc Description: PGP signature
Bug#832941: RFS: 4pane
Dear David, On Wed, Mar 15, 2017 at 11:37:58AM +, David Hart wrote: > >- Various stanzas do not include the copyright years, yet these are > > available in the files. The Copyright: field is meant to contain the > > copyright claim as it was stated by the upstream author.. > > May I ask which tool you used for that? I've found debmake -kk the best I've > tried, but it doesn't check for dates. > > I've gone through by hand and added all that I found. Of course: licensecheck --copyright -r . > >- Files in .build/ remain, and are not given in d/copyright. > > The remaining ones are my own files. Won't they be covered by '*'? Oh, sorry, I assumed you hadn't written 4pane.m4. Not so many people know m4, as I understand it :) > >- Files: bitmaps/iceweasel.png > > Copyright: Uncertain > > > >Files: bitmaps/kedit.xpm > >Copyright: Unknown > > > >Files: bitmaps/kwrite.xpm > >Copyright: Various > > > >The ftp-masters would be very likely to reject these. Since you found > >the source repos, surely you can find a name for the copyright fields? > > I tried hard, but failed to find definite copyright authors for these and > other bitmaps; I therefore added 'Comment:' fields. In detail: I understand, and appreciate that this is quite a frustrating time sink. > [...] > With the possible exception of kedit, all of these icons are or were included > in > other debian packages, so it would be surprising if there is no solution short > of removal. In general, what currently acceptable ways are there to fill the > Copyright field when an author isn't specified for a particular element of a > package? What we are hitting up against here is a limitation of the DEP-5 copyright format, which can make it seem like listing all authors is more important than establishing that the work is under a free license. Having read the results of your research, I suggest the following approach: - insert all the authorship info you've managed to find thus far -- no reason to throw away that effort -- in the Copyright: field, not Comment:. In the situation where you have a list of project authors but it is unlikely that they all worked on the icon file, just list them all, and put "Comment: These are the authors for the upstream project from which this file was obtained." - for the files where it is not clear, write a copyright string based on the project name. E.g. for kedit.xpm, "(C) 1999 kde-artist team" If this doesn't sound sane, it might be best to ask debian-legal. But I think we could go ahead and upload and see what the ftp-masters think of my proposed solution. > Finally, my ITP has timed-out and the package removed from > mentors. Does this now matter? We don't need mentors since I am working out of your git repo. Your ITP does not appear to have timed out. If the RFS gets closed, you can just re-open it. -- Sean Whitton signature.asc Description: PGP signature
Re: What option should I now use to do source only builds
Hello Andreas, On Fri, Mar 17, 2017 at 11:32:25PM +0100, Andreas Tille wrote: > I have understood from NEWS.debian of pbuilder 0.228 that the '-S' > option does not work any more. Unfortunately I did not understood what > I need to do now to do a source only build (nor what the problem of this > simple way was). There is also `dgit -wgf build-source` which means "build a source package exactly matching git HEAD", which is quite reassuring, even if you don't use dgit for the upload. -- Sean Whitton signature.asc Description: PGP signature
Bug#856827: RFS: xfce4-equake-plugin/1.3.8.1-2 [RC]
Dear Jeroen, Please be sure to CC the RFS bug! On Wed, Mar 15, 2017 at 10:49:27PM -0700, Jeroen van Aart wrote: > > I'd like to see some improvements to your changelog before uploading > > this. > > > > - changes to d/copyright not documented > > > > - the last point about avoiding lintian warnings is unnecessarily > > brief. Please expand it. There is a convention for std-ver changes: > > > > * Bump standards version to 3.9.8 (no changes required). > > I made the changes you requested and uploaded it to mentors, I kept the > version the same. You still haven't noted that you updated the copyright years. And you haven't documented updating the Homepage: field. Also, there is a typo "Buil-Depends". > I assume I don't need to create a debdiff for this small change? I suggest that when you remove the moreinfo tag from the unblock bug, you say "some changelog tweaks with no functional change (feedback in RFS)". -- Sean Whitton signature.asc Description: PGP signature
Bug#856827: RFS: xfce4-equake-plugin/1.3.8.1-2 [RC]
Dear Jeroen, On Sun, Mar 12, 2017 at 09:04:07PM -0700, Jeroen van Aart wrote: > I gave it version -2 because I initially had uploaded a -1 version to > mentors. There were some lintian warnings and I fixed those, that's why I > bumped the version to -2. If it is a problem I can change it back again, No, it's fine. It's just a convention that version numbers are incremented for uploads to the archive, not uploads to mentors. Please try to follow it in the future, just to avoid any confusion. > I just double checked, when I get the above two version and create a > debdiff, and then download the debdiff from the unblock request > (https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=857118;filename=debdiff_xfce4-equake_v138-1_v1381-2.diff.gz;msg=5) > and then run a diff between those the files turn out to be exactly the > same. > > Maybe you checked against the xfce4-equake-plugin_1.3.8.1-1.dsc version in > mentors? If so, I apologise for the confusion. That wasn't the problem. I was failing to pass -p1 to interdiff. Thank you for double checking, anyway. I'd like to see some improvements to your changelog before uploading this. - changes to d/copyright not documented - the last point about avoiding lintian warnings is unnecessarily brief. Please expand it. There is a convention for std-ver changes: * Bump standards version to 3.9.8 (no changes required). -- Sean Whitton signature.asc Description: PGP signature
Bug#851937: RFS: farbfeld/2.20170109-1 ITP
control: tag -1 +moreinfo control: owner -1 ! On Fri, Jan 20, 2017 at 08:50:26AM +0300, Dmitry Bogatov wrote: > I am looking for a sponsor for my package "farbfeld" Here's a review. - please update the dgit-maint-merge patch header, as we discussed in another RFS - your watch file is empty. Please fill it in! - 2ff(1) suggests that there should be a dependency on imagemagick, because it falls back to convert(1) If you're able to address the issues I've raised in this message, please remove the moreinfo tag in this bug, and don't forget to re-run `dch -r` to refresh the changelog timestamp. -- Sean Whitton signature.asc Description: PGP signature
Bug#856974: RFS: libserialport/0.1.1-2 [ITA]
control: tag -1 +moreinfo Dear Zoltan, Due to the freeze, this needs to be uploaded to experimental, not unstable. Similarly for your other RFSs. -- Sean Whitton signature.asc Description: PGP signature
Bug#857052: RFS: opencryptoki/3.6.2+dfsg-2 [ITA]
control: tag -1 +moreinfo Dear Paulo, On Tue, Mar 07, 2017 at 11:37:10AM -0300, Paulo Ricardo Paz Vital wrote: > opencryptoki (3.6.2+dfsg-2) unstable; urgency=medium > > [...] > > opencryptoki (3.6.2+dfsg-1) experimental; urgency=medium Due to the freeze, your upload needs to go to experimental, not unstable. -- Sean Whitton signature.asc Description: PGP signature
Bug#856827: RFS: xfce4-equake-plugin/1.3.8.1-2 [RC]
control: tag -1 +moreinfo Dear Jeroen, On Thu, Mar 09, 2017 at 04:50:04PM -0800, Jeroen van Aart wrote: > I opened bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857118 to > request an unblock and that was approved, see copy below. I was requested > to upload the new version, however I am unable to upload it myself. > > Would someone be able to upload it on my behalf? Thank you for working on this RC bug. There are some problems with this upload: - it is conventional to use a version number of -1 (mentors will let you overwrite the old source package), but this is not a big deal (integers are cheap) - the debdiff you submitted to the unblock request is not the same as the debdiff between your proposed upload and the version in sid. Can you explain why? We don't want to upload this to sid unless we are sure it will be unblocked. Thanks. -- Sean Whitton signature.asc Description: PGP signature
Bug#832941: RFS: 4pane
Dear David, Hopefully a final review (of b74e630): - you forgot `dch -r` - your copyright on debian/ is out-of-date -- you need s/2016/2017/ By the way, you can merge the '*' and 'debian/*' stanzas. - Files: bitmaps/iceweasel.png Copyright: Uncertain Files: bitmaps/kedit.xpm Copyright: Unknown Files: bitmaps/kwrite.xpm Copyright: Various The ftp-masters would be very likely to reject these. Since you found the source repos, surely you can find a name for the copyright fields? - The shortname "CC-BY-SA" should probably be suffixed with the license version. - Makefile.in is still in the tarball, but it's not in the preferred format for modification, as we've discussed previously. It has to be removed. - Various stanzas do not include the copyright years, yet these are available in the files. The Copyright: field is meant to contain the copyright claim as it was stated by the upstream author.. - Files in .build/ remain, and are not given in d/copyright. -- Sean Whitton signature.asc Description: PGP signature
Bug#857131: RFS: fgrun/2016.4.0-0.1 [RC, NMU]
control: tag -1 +wontfix Dear Boyuan, On Wed, Mar 08, 2017 at 06:53:47PM +0800, Boyuan Yang wrote: > fgrun (2016.4.0-0.1) unstable; urgency=medium > . >* Non-maintainer upload. >* New upstream release. (Closes: #839357) > - Drop patches applied upstream. > - Refresh patches. >* Switch upstream to SourceForge. > - Update corresponding debian/watch file. (Closes: #851845) >* Bump debhelper compat version to v10. >* Apply "wrap-and-sort -abst". >* Update Homepage information on SourceForge. Most of these changes are not appropriate for an NMU, so I'm marking this RFS as 'wontfix'. Since Markus has got involved in this thread, perhaps you can organise a team upload, and/or add Boyuan to the Uploaders: field. > * This package has a longstanding unfixed RC bug (FTBFS) and fell out of > Stretch release. With absolutely zero reverse dependency and migration > blocking, I believe fgrun should be able to enter unstable even though we are > in freeze now (because it wouldn't affect other packages or Stretch release > at > all). Note that the release team's freeze policy does not allow this. -- Sean Whitton signature.asc Description: PGP signature
Bug#856910: RFS: inotify-tools/3.14-3
Dear Dmitry, On Fri, Mar 10, 2017 at 07:33:29AM +0300, Dmitry Bogatov wrote: > Thank you. It is settled. One more review, please? 32f61b4 is fine, except that f4f7bda introduced a Debian delta of more than 3 lines. I think this was not deliberate :) On my system, dgit adds another commit undoing most of the changes in f4f7bda. Is it possible that you are working with the wrong orig.tar on your system? Or is your Emacs performing changes across the source tree? Make sure you use the orig.tar from the archive. -- Sean Whitton signature.asc Description: PGP signature
Bug#832941: RFS: 4pane
Dear David, Unfortunately, your watch file still isn't working: hephaestus ~/rfs/4pane-debian-dir % uscan --download-current-version uscan warn: In debian/watch no matching hrefs for version 4.0 in watch line http://www.4Pane.co.uk/4pane-(.*)\.tar\.gz Remember that by default, uscan looks for tags matching the URI pattern. I'm not an expert on uscan but I think you should be able to get it to substitute the version and just download that. -- Sean Whitton signature.asc Description: PGP signature
Bug#832941: RFS: 4pane
Dear David, On Wed, Mar 08, 2017 at 09:10:26PM +, David Hart wrote: > I've uploaded a +dfsg tarball to the 4Pane website and altered d/watch to > download it. uscan and lintian seem happy, so hopefully I've done this > correctly. This won't work because your changelog still has 4.0-1 as the version number.. While we're at it, why do you have an additional .1 suffix to the dfsg version number? It's certainly not a deal-breaker, but it's hardcoded into the watch file, which could be annoying in the future. -- Sean Whitton signature.asc Description: PGP signature
Bug#856652: RFS: xpdf/3.0.4.real-4
Dear Svante, On Wed, Mar 08, 2017 at 06:55:18AM +0100, Svante Signell wrote: > I still don't get it. The proposed package _doesn't_ depend on poppler any > more. > If you have problems with previous xpdf+poppler versions up to 3.04-4, remove > these from the archive then! I don't see how we could explain it any differently. We are saying that is _should_ depend on poppler. After the release of stretch, I intend to work on removing xpdf from the archive for the reason that it is unmaintainable, not because it depends on poppler. -- Sean Whitton signature.asc Description: PGP signature
Bug#856910: RFS: inotify-tools/3.14-3
Hello Dmitry,
On Wed, Mar 08, 2017 at 08:46:43AM +0300, Dmitry Bogatov wrote:
> I need help with this. If I write
>
> embedded-javascript-library usr/share/doc/libinotifytools0-dev/jquery.js
>
> into debian/libinotify0-dev.lintian-overrides, it does not match and lintian
> complains about unused override.
You can use wildcards ('*').
--
Sean Whitton
signature.asc
Description: PGP signature
Bug#855439: RFS: cvm/0.97
Dear Dmitry, On Wed, Mar 08, 2017 at 08:46:37AM +0300, Dmitry Bogatov wrote: > > control: tag -1 -moreinfo > > [2017-03-06 20:54] Sean Whitton <spwhit...@spwhitton.name> > > Dear Dmitry, > > > > On Sat, Feb 18, 2017 at 10:23:46AM +0300, Dmitry Bogatov wrote: > > > Note, that this is not full-scale modernization of package. It is just > > > a NMU, required for libbg1 -> libbg2 transition. > > > > Could you explain the background, please? Stretch is frozen. Have the > > release team authorized this transition? > > No. It is upload into experimental > > > It's rarely appropriate for an NMU to update to a new upstream version. > > If you are just performing the transition in experimental, there is no > > justification for it. > > I believe I have justification for this. Previous version (cvm-0.96) is > source-incompatible with (bglibs >= 2.03). There *might* be NMU justification if you were uploading to unstable. There definitely isn't for uploading to experimental. It would need to be a QA upload. > > > Please note, that package is maintained with dgit(1) tool using > > > dgit-maint-merge(7) workflow. In particular, it means that quilt > > > patches are squashed in source package and are not intended for > > > review. For more information about how to sponsor this package, > > > see dgit-sponsorship(7). > > > > This is not appropriate for an NMU. Indeed, I see that you've changed > > the source format to 3.0 (quilt) -- also not appropriate for an NMU. > > Well, I can revert it, but truth is that this package is maintained by > Gerrit Pape, who is not active for some years. I took over some of his > packages, but I am not interested in `cvm'. I just need to transit > bglibs, since latest version of `bcron', in which I am interested, > requires latest bglibs. > > Probably this upload should be QA upload, not NMU for lack of actual > maintainer. It is any way to ask QA team to make this upload on their > behalf? Sure, I can adopt, upload and fill RFA at same time, but it > feels wrong. I am talking to the MIA team. You could e-mail them yourself, too. Please be patient! Since Debian's current focus is releasing stretch, there is no reason to bypass our usual conventions for work that cannot end up in stretch. Thanks again. -- Sean Whitton signature.asc Description: PGP signature
Re: Bug#856652: RFS: xpdf/3.0.4.real-4
Dear Svante, On Tue, Mar 07, 2017 at 03:05:54PM +0100, Svante Signell wrote: > In my opinion, the code bases have diverged too far, yes. The fact that the code bases have diverged too far for the current maintenance practice to continue fails to entail that they have diverged too far that we would not expect most security bugs in one of them to also be present in the other. -- Sean Whitton signature.asc Description: PGP signature
Bug#856652: RFS: xpdf/3.0.4.real-4
Dear Svante, On Tue, Mar 07, 2017 at 08:17:08AM +0100, Svante Signell wrote: > I don't see where your concerns regarding security are, please explain. > Reading > more about the bugs in xpdf, the problems are mainly created by the use of > poppler as a backend, not when using the _real_ upstream sources. I explained this in detail in one of my previous e-mails. -- Sean Whitton signature.asc Description: PGP signature
Bug#856910: RFS: inotify-tools/3.14-3
On Mon, Mar 06, 2017 at 09:05:19AM +0300, Dmitry Bogatov wrote: > I am looking for a sponsor for my package "inotify-tools" - you could install NEWS as the upstream changelog - you could add a doc-base registration This would bring you down to a single lintian tag! -- Sean Whitton signature.asc Description: PGP signature
Bug#855439: RFS: cvm/0.97
control: tag -1 +moreinfo Dear Dmitry, On Sat, Feb 18, 2017 at 10:23:46AM +0300, Dmitry Bogatov wrote: > Note, that this is not full-scale modernization of package. It is just > a NMU, required for libbg1 -> libbg2 transition. Could you explain the background, please? Stretch is frozen. Have the release team authorized this transition? It's rarely appropriate for an NMU to update to a new upstream version. If you are just performing the transition in experimental, there is no justification for it. > Please note, that package is maintained with dgit(1) tool using > dgit-maint-merge(7) workflow. In particular, it means that quilt patches > are squashed in source package and are not intended for review. For more > information about how to sponsor this package, see dgit-sponsorship(7). This is not appropriate for an NMU. Indeed, I see that you've changed the source format to 3.0 (quilt) -- also not appropriate for an NMU. -- Sean Whitton signature.asc Description: PGP signature
Bug#856910: RFS: inotify-tools/3.14-3
control: tag -1 +moreinfo control: owner -1 ! Dear Dmitry, On Mon, Mar 06, 2017 at 09:05:19AM +0300, Dmitry Bogatov wrote: > I am looking for a sponsor for my package "inotify-tools" Thank you for your interest in adopting this package. And great choice for the git workflow ;) A review of dca4111: - Your conversion of d/copyright has lost some information, by merging the stanzas for McGovern and McCutchan. If you use two separate stanzas the conversion would not be lossy. - In your changelog you wrote that you bumped the std-ver. It's conventional to say what version you bumped it to. - The Lintian override could use a wildcard so that it only matches the doxygen file, not any other javascript that might appear in a new upstream release (unlikely though that is) - You've modified debian/*.install but this isn't in the changelog. - The dgit-maint-merge patch header has been updated to a better text. Please consider using it: https://manpages.debian.org/dgit-maint-merge - Changes to d/rules not in changelog. - Just fyi: https://manpages.debian.org/git-deborig Don't forget `dch -r` once you've addressed these. -- Sean Whitton signature.asc Description: PGP signature
