Re: can't upload to mentors
Hi, >to be honest, i don't have a good reason besides testing the resulting deb and >that is >my existing workflow I usually do two dpkg-buildpackage, one for my system, and the source one for ftpmasters the second one is usually really fast, because it just requires a source pack, no real building. (probably you should try to upload something like hedgewars, with a +200MB binary, to understand why you will like to avoid it :p) >on top of a debian source tree and it always works, so why change? because source only uploads are niceTM :) [1] >i'm not sure i follow you here, but here goes my reasoning anyway > >ftp-master will request a binary upload, so why don't do the same for mentors >since is >the very thing you're going to be doing later down the road. only for new or bin-new queue, lots of stuff on mentors is a subsequent update with no new binaries >i'd love if ftp-master accepted source only or even better >discard the uploaded binaries, but is not the way it is today sadly true >i'm very tempted to do uploads to debian using !amd64 binaries to be sure that >the binary used by (most of the) users hasn't been build by me but a buildd! true, I sometimes upload for i386 for this reason :) [1] https://wiki.debian.org/SourceOnlyUpload
Bug#845472: RFS: openbox/3.6.1-4 [RC]
On 2016-11-23 20:50, Gianfranco Costamagna wrote: control: owner -1 ! control: tags -1 moreinfo * Update manpage. (Closes: #800669) + cp doc/openbox.1.in openbox.1 I don't get this: how do you plan to update stuff like @configdir@/openbox/autostart.sh and similar? I don't get it, even if I didn't try to build and run it G. It was merged as pull on github. I fix it by install from debian/openbox.manpages.
Bug#844599: marked as done (RFS: confget/2.0.0-2 -- updated packaging)
Your message dated Thu, 24 Nov 2016 10:07:31 + (UTC) with message-id <221972147.1764331.1479982051...@mail.yahoo.com> and subject line Re: Bug#844599: RFS: confget/2.0.0-2 -- updated packaging has caused the Debian Bug report #844599, regarding RFS: confget/2.0.0-2 -- updated packaging to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 844599: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844599 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for a new Debian upload of my package "confget" to refresh some aspects of the Debian packaging. * Package name: confget Version : 2.0.0-2 Upstream Author : Peter Pentchev * URL : https://devel.ringlet.net/textproc/confget/ * License : BSD-2-clause Section : text It builds a single binary package that has been tested with sbuild and Lintian: confget- read variables from INI-style configuration files To access further information about this package, please visit the following URL: https://mentors.debian.net/package/confget Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/c/confget/confget_2.0.0-2.dsc ...or obtain it from my Git repository: debcheckout confget cd confget git describe # should output mentors/2.0.0-2 git tag -v mentors/2.0.0-2 pristine-tar checkout ../confget_2.0.0.orig.tar.bz2 More information about confget can be obtained from its homepage at https://devel.ringlet.net/textproc/confget/ Changes since the last upload: confget (2.0.0-2) unstable; urgency=medium * Depend on debhelper 10 now that it is in unstable, testing, and jessie-backports. Drop the Lintian override about the version. * Switch to the HTTPS scheme for various Debian and upstream URLs. * Use the v4 substitution variables in the watch file. -- Peter Pentchev Thu, 17 Nov 2016 13:53:02 +0200 Thanks in advance! G'luck, Peter -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) signature.asc Description: PGP signature --- End Message --- --- Begin Message --- Hi, >I am looking for a sponsor for a new Debian upload of my package >"confget" to refresh some aspects of the Debian packaging. I also granted you dm for it :) G.--- End Message ---
Bug#844599: RFS: confget/2.0.0-2 -- updated packaging
On Thu, Nov 24, 2016 at 10:07:31AM +, Gianfranco Costamagna wrote: > Hi, > > >I am looking for a sponsor for a new Debian upload of my package > > >"confget" to refresh some aspects of the Debian packaging. > > > I also granted you dm for it :) Thanks! :) G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@freebsd.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#844608: [Pkg-protobuf-devel] Looking for sponsor for protobuf NMU
Hi, On Tue, 2016-11-22 at 08:44 +, Gianfranco Costamagna wrote: > > and sponsored in deferred/5. Where can I find the deferred package? I found nothing at https://ftp-master.debian.org/deferred/ I'd like to confirm the package you sponsored shipped the correct patch, since the original one is somewhat buggy. The correct patch contains changelog like so: +protobuf (3.0.0-7.1) unstable; urgency=medium + + * Non-maintainer upload. + * Build python3-protobuf, thanks to Thomas Viehmann. (Closes: #836821) + * Add the missing B-D "libgtest-dev". (Closes: #836826) + * Add "python3-six" to B-D, which is required by python3 test. P.S. python module "six" is required according to setup.py, I found that debomatic-amd64 tried to download and install the "six" package with pip at the python3 test stage, which should never happen according to policy (no download during build). Hence the addition of python3-six.
Bug#844608: [Pkg-protobuf-devel] Looking for sponsor for protobuf NMU
Hi, >Where can I find the deferred package? I found nothing at >https://ftp-master.debian.org/deferred/ you can't. Nobody can, just ftpmasters. (and I did even upload to a queue that is not visible there) >I'd like to confirm the package you sponsored shipped >the correct patch, since the original one is somewhat buggy. I removed it.>P.S. python module "six" is required according to setup.py, I found that >debomatic-amd64 tried to download and install the "six" package with pip >at the python3 test stage, which should never happen according to policy >(no download during build). Hence the addition of python3-six. I don't think it was a bad upload, because I used DoM to build and test it. In any case, post a patch to the bug report, and I'll review/reupload. G.
Bug#844608: [Pkg-protobuf-devel] Looking for sponsor for protobuf NMU
On Thu, 2016-11-24 at 14:37 +, Gianfranco Costamagna wrote: > > I don't think it was a bad upload, because I used DoM to build and > test it. Thank you for confirmation. I checked the package at DoM and it is correct. So let's wait for maintainers' comments.
Re: can't upload to mentors
On 2016-11-24 11:21+0800, gustavo panizzo (gfa) wrote: > can i ask you why are you doing source-only uploads? > > i did a lot of binary+source uploads in the last days without an issue (after > removing > .buildinfo from .changes) Sure! - First I was told to remove the .buildinfo from the binary .changes and sign it again, which did not work. - Then I was told to do a source only upload, which did not work either. - Then I was told to go to #debian-mentors to find what was going on, which did work: there appeared to be a (still present and not identified) bug in debexpo. signature.asc Description: PGP signature
Re: can't upload to mentors
On Thu, Nov 24, 2016 at 05:23:25PM +0100, Félix Sipma wrote: > On 2016-11-24 11:21+0800, gustavo panizzo (gfa) wrote: > > can i ask you why are you doing source-only uploads? > > > > i did a lot of binary+source uploads in the last days without an issue > > (after removing > > .buildinfo from .changes) > > Sure! > > - First I was told to remove the .buildinfo from the binary .changes and sign > it again, which did not work. i did this 3 or 4 times last week - delete all resulting files from previous builds but the orig.tar.gz, the result directory should only have the orig.tar.gz file before you start to build - sbuid/pbuilder/gbp to create a binary+source package - edit the .changes file to remove the .builinfo line - sign the .changes, debsign mypackage_1.8beta5+ds1-2_amd64.changes - upload to mentors, dput mentors mypackage_1.8beta5+ds1-2_amd64.changes if you want to upload again you have to wait until the crojob delete the files before upload connect to ftp://mentors.debian.net and check your files are not there - wait until the other cronjob accepts the package and sends you an email letting you know it worked :) - profit! :) i *think* you signed the .changes, edited and signed again. if you follow above's steps and keeps failing (remember to wait for the cronjobs...) paste the output of every command here and i'll help you. but it shouldn't, as i said i did it like 3 times last week > - Then I was told to do a source only upload, which did not work either. > - Then I was told to go to #debian-mentors to find what was going on, which > did > work: there appeared to be a (still present and not identified) bug in > debexpo. yeah, debexpo doesn't like .buildinfo files (maybe other bugs i'm not aware) good luck! -- 1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333 keybase: https://keybase.io/gfa
Bug#845311: Bug#843775: jessie-pu: package mdadm/3.3.2-5+deb8u2
Control: tags 843775 + pending On Tue, 2016-11-22 at 12:43 +0100, Cyril Brulebois wrote: > (dropping debian-boot@, adding 845311@) > > Hi Jens, > > Jens Sauer (2016-11-22): > > Thank you for reviewing this package. It was my first time doing this, > > I hope everything is alright. > > It looks to me everything was right on the first attempt. :) > > > I opened a RFS to find a sponsor for the upload: > > https://bugs.debian.org/845311 > > According to my inbox it's possible to perform source-only uploads for > jessie-proposed-updates (at least it worked for src:debian-installer), > so I've just sponsored your package this way. Please close the RFS if it > gets queued as expected; otherwise I'll re-sponsor the package with a > binary build included. Flagged for acceptance into p-u. Regards, Adam
Bug#845574: RFS: asl/0.1.7-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "asl" * Package name: asl Version : 0.1.7-1 Upstream Author : Avtech Scientific * URL : http://asl.org.il * License : AGPL-3 Section : science It builds those binary packages: asl-doc- documentation for ASL asl-tools - command-line tools for ASL libasl-dev - development files for ASL libasl0- multiphysics simulation software To access further information about this package, please visit the following URL: https://mentors.debian.net/package/asl Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/a/asl/asl_0.1.7-1.dsc Successful build on debomatic: http://debomatic-amd64.debian.net/distribution#unstable/asl/0.1.7-1/buildlog Changes since the last upload: * Update patch queue. - Drop Explicitly-define-namespace-of-ifstream-and-ofstream.patch, applied upstream. - Drop Replace-includes-math.h-cmath.patch, applied upstream. - Refresh Use-system-MathJax.patch. - New patch Fix-spelling-errors-reported-by-Lintian.patch. * Update list of build dependencies. * Upgrade packaging to debhelper 10. * Replace occurrences of .md files with .org. * Drop build of unused examples and tests. * Use DEB_HOST_MULTIARCH for multiarch path injection. * Keep the doxygen generated instance of jQuery. * Update the description of all binary packages. * Provide utilities in new asl-tools package. * Rename libasl-doc package to asl-doc. Regards, Ghislain Vaillant
Bug#844608: [Pkg-protobuf-devel] Bug#844608: Looking for sponsor for protobuf NMU
Hi,
On Thu, Nov 24, 2016 at 4:01 PM, lumin wrote:
> On Thu, 2016-11-24 at 14:37 +, Gianfranco Costamagna wrote:
>> I don't think it was a bad upload, because I used DoM to build and
>> test it.
>
> Thank you for confirmation. I checked the package at DoM and
> it is correct. So let's wait for maintainers' comments.
Your changes seem to be correct. I plan to upload the attached diff
in some hours if you don't mind.
Thanks for your contribution,
Laszlo/GCS
diff -Nru protobuf-3.0.0/debian/changelog protobuf-3.0.0/debian/changelog
--- protobuf-3.0.0/debian/changelog 2016-09-02 06:57:13.0 +
+++ protobuf-3.0.0/debian/changelog 2016-11-24 17:33:28.0 +
@@ -1,3 +1,15 @@
+protobuf (3.0.0-8) unstable; urgency=medium
+
+ [ Zhou Mo ]
+ * Build python3-protobuf, thanks to Thomas Viehmann (closes: #836821).
+ * Add the missing B-D "libgtest-dev" (closes: #836826).
+ * Add "python3-six" to B-D, which is required by python3 test.
+
+ [ Bart Martens ]
+ * Generalize watch file.
+
+ -- Laszlo Boszormenyi (GCS) Thu, 24 Nov 2016 17:33:28 +
+
protobuf (3.0.0-7) unstable; urgency=medium
* Team upload.
diff -Nru protobuf-3.0.0/debian/control protobuf-3.0.0/debian/control
--- protobuf-3.0.0/debian/control 2016-08-25 22:28:51.0 +
+++ protobuf-3.0.0/debian/control 2016-11-24 17:33:28.0 +
@@ -16,12 +16,17 @@
, g++ (>= 4:4.7)
, zlib1g-dev
, google-mock
+ , libgtest-dev
# Python
, dh-python
, python-all (>= 2.7)
, libpython-all-dev (>= 2.7)
+ , python3-all (>= 3.3)
+ , libpython3-all-dev (>= 3.3)
, python-setuptools
+ , python3-setuptools
, python-google-apputils
+ , python3-six
# Manpage generator
, xmlto
# Tests
@@ -180,6 +185,27 @@
need the protoc tool (in the protobuf-compiler package) to compile your
definition to Python classes, and then the modules in this package will allow
you to use those classes in your programs.
+
+Package: python3-protobuf
+Architecture: any
+Section: python
+Depends: ${shlibs:Depends}, ${python3:Depends}, ${misc:Depends}
+Description: Python 3 bindings for protocol buffers
+ Protocol buffers are a flexible, efficient, automated mechanism for
+ serializing structured data - similar to XML, but smaller, faster, and
+ simpler. You define how you want your data to be structured once, then you can
+ use special generated source code to easily write and read your structured
+ data to and from a variety of data streams and using a variety of languages.
+ You can even update your data structure without breaking deployed programs
+ that are compiled against the "old" format.
+ .
+ Google uses Protocol Buffers for almost all of its internal RPC protocols and
+ file formats.
+ .
+ This package contains the Python 3 bindings for the protocol buffers. You will
+ need the protoc tool (in the protobuf-compiler package) to compile your
+ definition to Python classes, and then the modules in this package will allow
+ you to use those classes in your programs.
Package: libprotobuf-java
Architecture: all
diff -Nru protobuf-3.0.0/debian/copyright protobuf-3.0.0/debian/copyright
--- protobuf-3.0.0/debian/copyright 2016-08-22 05:30:23.0 +
+++ protobuf-3.0.0/debian/copyright 2016-11-24 17:33:28.0 +
@@ -51,6 +51,7 @@
Copyright:
2009 Dirk Eddelbuettel
2016 Dmitry Smirnov
+2016 Laszlo Boszormenyi (GCS)
2009 Julien Cristau
2013-2014 Robert Edmonds
2008,2009,2010 Iustin Pop
diff -Nru protobuf-3.0.0/debian/python-protobuf3.README.Debian protobuf-3.0.0/debian/python-protobuf3.README.Debian
--- protobuf-3.0.0/debian/python-protobuf3.README.Debian 1970-01-01 00:00:00.0 +
+++ protobuf-3.0.0/debian/python-protobuf3.README.Debian 2016-11-24 17:33:28.0 +
@@ -0,0 +1,11 @@
+C++ backend
+===
+
+As of protobuf 2.6.0, a new C++ backend for the Python protobuf bindings is
+available, which is faster than the default pure Python implementation. It can
+be activated by setting the following environment variables:
+
+PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION=cpp
+PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION_VERSION=2
+
+ -- Robert Edmonds Thu, 28 Aug 2014 21:10:30 -0700
diff -Nru protobuf-3.0.0/debian/rules protobuf-3.0.0/debian/rules
--- protobuf-3.0.0/debian/rules 2016-08-25 00:28:25.0 +
+++ protobuf-3.0.0/debian/rules 2016-11-24 17:33:28.0 +
@@ -1,7 +1,8 @@
#!/usr/bin/make -f
+# -*- makefile -*-
%:
- dh $@ --with autoreconf,python2 --parallel
+ dh $@ --with autoreconf,python2,python3 --parallel
override_dh_auto_build-arch:
## Chicken<->Egg problem: protobuf requires self-generated .pb.go files to
@@ -14,8 +15,10 @@
# Generate the manpage.
xmlto man debian/protoc.xml
- # Python build.
+ # Python and Python3 build.
+ cp -rv python python3
cd python && python setup.py build --cpp_implementation
+ cd python3 && python3 setup.py build --cpp_implementation
override_dh_auto_build-indep:
dh_auto_build
Bug#832941: RFS: 4pane (debian: to exclusive)
Dear David, Here's another review, based on your 4pane-debian-dir repo. Must-fixes -- 1. At least one of the files added by AddExtraM4Files.patch isn't accounted for in d/copyright. 2. Vcs-* still point to the upstream code, not your 4pane-debian-dir repo. 3. d/copyright says that only you hold copyright on MyGenericDirCtrl.cpp and sdk/fswatcher/*, but the file headers have several other people's names. They should all be in d/copyright. 4. Your own copyright is not all 2016. Some files are 2014, and About.htm says 2007--2016. 5. Alberto Griggio and Otto Wyss also hold copyright on MyTreeCtrl.* 6. config.guess, config.sub, configure, configure.in, Makefile.in and install-sh are not accounted for in d/copyright. 7. Some bitmaps aren't accounted for in d/copyright. For example, I'm guessing you didn't produce bitmaps/libreoffice.png yourself (unless you did?). 8. Further, could you confirm that, for the files in bitmaps/ and the images in doc/ whose preferred format for modification is not .png, the .xpm/.svg/whatever source is available? I see some .xpm/.svg files but not for every file. If the preferred format for modification for those other files is editing the .png then it's fine. 9. Lots of files in .build/ are not accounted for in d/copyright. 10. .build/DONT_README (heh) explains that the Bakefile tool is required to regenerate the build system. I.e. the preferred format for modification of the buildsystem is not by editing Makefile.in, but by changing some other files and running Bakefile (is Makefile.in the only file that Bakefile outputs?). As before, this is a violation of DFSG. I think you need to package Bakefile for Debian, unless you can think of a way around this. 11. You need to run dch -r to refresh the changelog timestamp so it is after the various changes you've made recently. Command I used to find the copyright issues: `licensecheck --copyright -r .` Suggestions --- 1. You might raise the debhelper compat to 10, the latest version. That means you can drop '--parallel --with autoreconf' which are automatic at compat 10. 2. At the top of d/rules you define various EXTRA_ env vars. Could you explain further why you can't do this "the standard way"? Would it be possible to make it work by patching the upstream Makefile? Generally speaking, it's better to have a short d/rules and move logic into the upstream Makefile (otherwise someone trying to understand it has to flip back and forth between two files). 3. In a previous e-mail I explained why I think it would be clearer to call the wxWindows license "GPL-2+ or wxWindows-3.1+". So far as I can tell you never responded to that -- please consider the points I made. Unless I'm missing something, it would make d/copyright clearer. 4. You should probably s/4pane/4Pane/ in 4pane.doc-base. 5. Rather than installing 4Pane.desktop twice, you could do something like this: override_dh_install: dh_install ( cd debian/4pane/usr/share && mv 4Pane/rc/4Pane.desktop applications ) On Sun, Nov 20, 2016 at 06:31:33PM +, David Hart wrote: > Dear Sean, > > >1. Why do you have a folder full of patches, when you are the upstream > >author of 4Pane? Have they been applied upstream, but there hasn't been > >a release of 4Pane recently? > > Yes. They are implementing your previous suggestions. There hasn't been a > recent 4Pane release and, unless needed for debian packaging reasons, there > won't be one soon. A new release is not needed. Thanks for the explanation. > >2. I see that w.r.t. 4pane/4Pane, you're using 4Pane wherever Debian > >policy permits you too. Good idea. The only thing I'm not sure about > >is the symlink from /usr/share/doc/4Pane to /usr/share/doc/4pane/html. > >It could be misleading, since Debian users expect /usr/share/doc/foo to > >give them a folder containing a changelog, a Debian changelog etc. Why > >not link to /usr/share/doc/4pane? > > IIUC the current situation is correct: the debian changelog etc files are in > /usr/share/doc/4pane/ as expected, while the symlink from /usr/share/doc/4Pane > to html/ allows the program to find its F1 help files (which can be accessed > outside the program using a doc-base reader). > > If this is wrong please tell me. 6. It's definitely not wrong, but it might not be optimal. What I'm imagining is the following situation: Debian users expect to find certain files (changelogs, copyright files) in /usr/share/doc/foo. Since 4Pane is known as '4Pane', a user might reasonably look in /usr/share/doc/4Pane. But then they wouldn't be able to find the standard files. For this reason, I think /usr/share/doc/4Pane should be a link to /usr/share/doc/4pane and 4Pane can be patched to find its help files there. -- Sean Whitton signature.asc Description: PGP signature
Bug#844184: RFS: muse-el/3.20+dfsg-1 [ITA]
Hi Sean, Thank you very much for all your help and for this review! Would you please pull my working copy from here: git+ssh://git.debian.org/git/pkg-emacsen/pkg/muse-el.git here: https://anonscm.debian.org/git/pkg-emacsen/pkg/muse-el.git or consult this: https://anonscm.debian.org/cgit/pkg-emacsen/pkg/muse-el.git/ to see how I've implemented the changes you've advised. Further questions follow inline. On Sun, Nov 13, 2016 at 03:38:01PM -0700, Sean Whitton wrote: > In the future, when submitting a new bug, please use X-Debbugs-CC: rather > than CC: so that the bug gets assigned a number before reaching my > inbox. Would you please share how to get X-Debbugs-CC: to show up in mutt's edit_headers? It seems to be ignored unless it is set using this: my_hdr X-Debbugs-CC: bogus_value > I've split my review into two sections: things that I would consider > must-fixes before an upload to Debian, and suggested improvements. The > latter aren't strictly necessary, but they would help demonstrate to a > potential sponsor that you are committed to maintaining this package in > Debian. > > Must-fixes > == > > 1. Your changelog could do with some work. > > - you should close the ITA bug Close the ITA bug in the changelog? Do I need to send a control email to the ITA bug (something like "also affects")? I anticipate a "closes bugs improperly" lintian error. > - "Update format." -- from what to what? I'm not sure what format the old copyright was. Where "Format:" is usually found it said this: This package was debianized by Trent Buck on Thu, 23 Jun 2005 13:12:12 +1000. Updated to this: Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ > 3. README.Debian should have a single timestamp. Remove the previous > maintainer's timestamp, add subheadings for the parts added by each of > you, and put your timestamp at the bottom. I'm not adding any new information so much as updating the paths to reflect the new install locations. Please let me know if this is a more clear to do it this way than my original "Whenever path X is mentioned, it actually refers to path Y". The upside is the paths can now be copied and pasted, useful full-text search, usefully grepped etc, but I'm not sure if I've sufficiently attributed the original author. > 5. There are a lot of Lintian warnings. Please make the package > Lintian-clean. I'm having trouble with "W: elpa-muse: syntax-error-in-debian-news-file line 68 "found eof where expected first heading", and have tried synchronising my date stamp with the one in changelog, removing '*'s and '-'s, and several white-space experiments...to no avail. > > Do my patches look ok? > > 8. They need patch headers, preferably conforming to DEP-3, explaining > what each of them is for. Try to include a Forwarded: header, in > particular. I've added headers, and I've added you to the "Reviewed-by: " one. Why do I need the "Forwarded: " header when my patch is already checked into git.debian.org? > > Should elpafied packages continue to be arch-independent? > > Yup. When debugging some of my failed experimental modifications I noticed that this is a binary package. Is arch-independent interpreted source + docs still a binary package? As far as I can tell, the QuickStart.pdf is the only binary. > Suggestions > === > Complete. Please let me know if I've correctly addressed all ellipted items. Cheers, Nicholas signature.asc Description: Digital signature
Bug#844608: [Pkg-protobuf-devel] Bug#844608: Looking for sponsor for protobuf NMU
On Thu, 2016-11-24 at 20:39 +0100, László Böszörményi (GCS) wrote: > > Your changes seem to be correct. I plan to upload the attached diff > in some hours if you don't mind. I see it in the NEW queue, thank you!
Bug#844184: RFS: muse-el/3.20+dfsg-1 [ITA]
On Thu, Nov 24, 2016 at 07:25:29PM -0500, Nicholas D Steeves wrote: > > 5. There are a lot of Lintian warnings. Please make the package > > Lintian-clean. > > I'm having trouble with "W: elpa-muse: syntax-error-in-debian-news-file > line 68 "found eof where expected first heading", and have tried > synchronising my date stamp with the one in changelog, removing '*'s and > '-'s, and several white-space experiments...to no avail. Fixed. I did it by: 1. Discovering dch --news 2. Removing my additions 3. Dch --news 4. Oops, it picks UNRELEASED 5. Change changelog entry to UNRELEASED 6. Paste my additions back into NEWS 7. Dch -r --news 8. git commit 9. Build. And then, for some reason, it worked... I fail to understand why, and it seems like voodoo hand waving. The only thing I can think of is that there is a hidden rule that the date stamps on changelog and NEWS cannot be the same, and that NEWS must be older than changelog. Additionally, I wonder if there is an invisible mtime to claimed datestamp comparison. Whatever the case, it looks like I'll be using dch --news in the future. :-) Cheers, Nicholas signature.asc Description: Digital signature
Bug#844184: marked as done (RFS: muse-el/3.20+dfsg-1 [ITA])
Your message dated Fri, 25 Nov 2016 04:29:54 + with message-id and subject line closing RFS: muse-el/3.20+dfsg-1 [ITA] has caused the Debian Bug report #844184, regarding RFS: muse-el/3.20+dfsg-1 [ITA] to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 844184: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844184 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: normal Dear mentors, I am looking for review and a sponsor for my package "src:muse-el". I've CC'd Sean Whitton who is willing to help me with elpa, LISP, and any emacs-on-Debian integration issues. Here are a few things I'm wondering about: Are the generated packages in the correct sections for an elpafied package? Is removing hrefs to favicon.ico (Bug: #775885) sufficient? Distributing a favicon.ico seems unnecessary and honestly, I'm against it. In Canada, because the author retains all distribution rights in the absence of a license or declared copyright, even something as trivial as a favicon.ico can be unredistributable. I couldn't find the license on Michael Olson's website , so I decided it was best not to copy it. Do my patches look ok? Should elpafied packages continue to be arch-independent? Is debian/changelog too verbose and could it be condensed? Package name: muse-el Version : 3.20+dfsg-1 Section : editors It builds those binary packages: elpa-muse - Author and publish projects using Wiki-like markup muse-el- transitional dummy package for elpa-muse. To access further information about this package, please visit the following URL: https://mentors.debian.net/package/muse-el Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/m/muse-el/muse-el_3.20+dfsg-1.dsc More information about hello can be obtained from https://www.example.com. Changes since the last upload: muse-el (3.20+dfsg-1) unstable; urgency=medium * New Maintainer. * debian/control: - Bump required debhelper to >=9. - Update emacs dependency. - Add emacs-goodies-el dependency, which provides htmlize.el. * Switch to debcompat 9; Switch to 3.0 (quilt) non-native packaging. * Add patch to fix privacy breaches; removes hrefs. (Closes: #775885) * Elpafy! (depends on dh-elpa). * Add patch to disable non-DFSG compliant texi stuff. * Install docs and examples the new dh_way. * debian/rules: - add override to build examples and autoloads. - add override to install upstream changelog series. * debian/copyright: - Fix misattributed source (found by comparing timestamps in comments between gna.org tarballs and git sources). - Update format. - Add debian/* section. * Include images used by the QuickStart.muse example. (Closes: #720121) * Add patch to use Debian's "see" command instead of "open". Thank you Kevin Ryde, I didn't know about the existence of "see" before reading this bug report. (Closes: #720126) * Patch README to explain how installed files relate to src:muse-el. -- Nicholas D Steeves Tue, 18 Oct 2016 20:58:45 -0400 Regards, Nicholas D Steeves --- End Message --- --- Begin Message --- Package muse-el has been removed from mentors.--- End Message ---
