Bug#850487: RFS: terminaltables/3.1.0-1 [ITP]
I have uploaded a new package to mentors and git which now builds successfully in a sid chroot with sbuild when given colorclass as an --extra-package. I would ideally like this in unstable, but since colorclass is already in NEW targeting experimental, and this package depends on that one, my understanding is that this also needs to go into experimental for now.
Bug#850664: marked as done (RFS: python-pynzb/0.1.0-3)
Your message dated Wed, 11 Jan 2017 21:37:30 -0700 with message-id <20170112043730.tfojaeovamiud...@hephaestus.silentflame.com> and subject line Re: Bug#850664: RFS: python-pynzb/0.1.0-3 has caused the Debian Bug report #850664, regarding RFS: python-pynzb/0.1.0-3 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 850664: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850664 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "python-pynzb" * Package name: python-pynzb Version : 0.1.0-3 * URL : https://github.com/ericflo/pynzb * License : BSD-3-clause Section : python I am interested in this package as a dependency for flexget (ITP: #724718). The package has not received any attention from upstream, but it a very simple set of wrappers for XML parsers to parse a simple XML format: NZB. For this release I switch to building the Python 3 module which required the use of 2to3 in the build step. The Python 2 module can still be built fine, but I removed it since there were no rdeps. It builds these binary packages: python3-pynzb - unified API for parsing NZB files from NNTP (Usenet) servers To access further information about this package, please visit the following URL: https://mentors.debian.net/package/python-pynzb Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/python-pynzb/python-pynzb_0.1.0-3.dsc Changes since the last upload: python-pynzb (0.1.0-3) unstable; urgency=medium * Add myself to uploaders. * Switch to pybuild and dh-python. * Bump d/compat to 10. * Bump standards-version to 3.9.8 (no changes). * d/copyright: add myself and fix license short names - "public domain" -> public-domain - BSD -> BSD-3-clause. * Change Vcs to DPMT git repository and use https. * Change Homepage to GitHub. * Build the Python 3 module and drop the Python 2 module (no rdeps). * Run the test suite with pytest. * Call 2to3 during auto build. * 0001-set-message_id-properly-in-expat-parser.patch: fix an upstream code. Tests pass for Python 2 with only this change. * Move lxml to Suggests since there are fallbacks, but Build-Depend on it to run the tests. * For Python 3, decode strings -> bytes as utf-8 for lxml. * Fix watch file (although the last release was some time ago). -- Carl Suster Mon, 09 Jan 2017 12:17:45 +1100 Cheers, Carl --- End Message --- --- Begin Message --- Hello Carl, Uploaded. Thank you for your attention to detail. A tip: it looks like you ran the `wrap-and-sort` tool. It's useful to put this in the changelog with the parameters you used, e.g. * wrap-and-sort -abst That means that someone else/your later self working on the package can tidy up the control files using the same options (in this case, 'abst'). -- Sean Whitton signature.asc Description: PGP signature --- End Message ---
Bug#842588: marked as done (RFS: photo-booth/1.0.1~rc1-1 [ITP])
Your message dated Thu, 12 Jan 2017 04:29:03 + with message-id and subject line closing RFS: photo-booth/1.0.1~rc1-1 [ITP] has caused the Debian Bug report #842588, regarding RFS: photo-booth/1.0.1~rc1-1 [ITP] 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.) -- 842588: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842588 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "photo-booth" * Package name: photo-booth Version : 1.0.1~rc1-1 Upstream Author : Adam Roses Wight * URL : https://github.com/adamwight/photo-booth * License : GPL-3 Section : graphics It builds these binary packages: photo-booth - Self-serve photo booth software To access further information about this package, please visit the following URL: https://mentors.debian.net/package/photo-booth Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/photo-booth/photo-booth_1.0.1~rc1-1.dsc More information about photo-booth can be obtained from https://github.com/adamwight/photo-booth Changes since the last upload: * Fix most lintian warnings. Thank you, Adam Roses Wight --- End Message --- --- Begin Message --- Package photo-booth has been removed from mentors.--- End Message ---
Bug#835274: marked as done (RFS: bcron/0.10-4 )
Your message dated Thu, 12 Jan 2017 04:29:03 + with message-id and subject line closing RFS: bcron/0.10-4 has caused the Debian Bug report #835274, regarding RFS: bcron/0.10-4 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.) -- 835274: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=835274 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "bcron" * Package name: bcron Version : 0.10-4 Upstream Author : Bruce Guenter * Url : http://untroubled.org/bcron * Licenses: GPL-2+ Section : admin It builds those binary packages: * bcron * bcron-run To access futher information about this package, visit the following URL: http://mentors.debian.net/package/bcron Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/b/bcron/bcron_0.10-4.dsc Alternatively, you can access package debian/ directory via git from URL: https://anonscm.debian.org/cgit/users/kaction-guest/bcron.git More information about bcron can be obtained from http://untroubled.org/bcron Changes since last upload: * Write debian/watch * Change source package format to quilt, remove manual patches application * Convert package to use debhelper * Use `dh-runit' to install runit scripts and generate log scripts (Closes: #832656) * Use `dh-buildinfo' to simplify tracking bugs, related to build-tools * Avoid need of hand-written maintainer scripts by use of `dh-runit' and `dh-sysuser' * Drop diet libc build due issues with errno * Remove no longer needed README files * Move 'debian/crontab' into 'debian/contrib' for more clean package layout * Enable hardening * Fix @dircategory in texinfo manual * Install `doc-base' document * Add Homepage field * Bump standards version to 3.9.8 (no changes needed) * Remove Section field from `bcron-run' field, since it duplicated one defined in first paragraph. * Update Vcs-Git and Vcs-Browser fields * Convert `debian/copyrigh' to dep5 format * Use `dh-text' to avoid duplication in `debian/control' (description slightly modified to avoid issues with quotation symbols) Regards, Dmitry Bogatov --- End Message --- --- Begin Message --- Package bcron has been removed from mentors.--- End Message ---
Bug#850607: Re: Bug#850607: RFS: flask-login/0.4.0-1 [ITA]
On Thu, Jan 12, 2017 at 12:48:18PM +1100, Carl Suster wrote: > Ok I added these headers in git under a new unreleased changelog entry so > they'll be picked up next time there's a release. Great work :) -- Sean Whitton signature.asc Description: PGP signature
Bug#850942: RFS: pydbus/0.6.0-1
control: tags -1 moreinfo Hi Alberto, On 11-01-2017 10:12, Alberto Caso wrote: > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I am looking for a sponsor for my package "pydbus" > I just did a quick review on your package and below are some details that could be adjusted: d/changelog: - Even the transition to testing is 10 days, you can keep urgency=medium, this is the default. - Please specify the files that have changed or removed (eg: debian/copyright). d/control e d/compat: - Please update debhelper to version 10. - Still in d/control you can update in the Vcs-Browser address from "cgit" to "git". d/copyright: - What do you think about aligning the copyright years in the doc/tutorial.rst block? You could add the email Linus in this block too. d/rules: - Remove the first lines of comments, this is not necessary. d/watch: - Please, update to version 4. cheers, Giovani signature.asc Description: OpenPGP digital signature
Bug#850664: RFS: python-pynzb/0.1.0-3
Control: tag -1 -moreinfo Hi Sean, I think you forgot to `git push` :) Oops! Done. Also, it would be good if you could use the Forwarded: header to indicate whether your patches have been sent upstream or not. This is especially useful in team-maintained packages. If you add this now, don't forget `dch -r` and `git push` ;) I added the Forwarded headers to point to pull requests I made upstream. Thanks again, Carl
Bug#850928: marked as done (RFS[ITP]: minetest-mod-3d-armor/0.4.5-1)
Your message dated Thu, 12 Jan 2017 01:16:21 +0100 with message-id <20170112001620.xdqg6bzn4croy...@mapreri.org> and subject line Re: Bug#850928: RFS[ITP]: minetest-mod-3d-armor/0.4.5-1 has caused the Debian Bug report #850928, regarding RFS[ITP]: minetest-mod-3d-armor/0.4.5-1 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 850928: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850928 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "minetest-mod-3d-armor" * Package name: minetest-mod-3d-armor Version : 0.4.5-1 Upstream Author : Stuart Jones * URL : https://github.com/stujones11/minetest-3d_armor * License : LGPL-2.1, CC-BY-SA-3.0 and WTFPL Section : games It builds those binary packages: minetest-mod-player-3d-armor - Modpack to add armor and wielded weapons for Minetest To access further information about this package, please visit the following URL: https://mentors.debian.net/package/minetest-mod-3d-armor Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/m/minetest-mod-3d-armor/minetest-mod-3d-armor_0.4.5-1.dsc It is packaged within the Debian Games Team: Vcs-Git: https://anonscm.debian.org/git/pkg-games/minetest-mod-3d-armor.git Vcs-Browser: https://anonscm.debian.org/git/pkg-games/minetest-mod-3d-armor.git IMPORTANT NOTICE: d/copyright doesn't correspond to what you find in 0.4.5's LICENSE.md and README.md files (notice the plural) : it corresponds to the clarifications I obtained from upstream, which have been committed to their repository but haven't found their way in an official release yet: https://github.com/stujones11/minetest-3d_armor/issues/75 Thanks, Snark on #debian-games --- End Message --- --- Begin Message --- On Wed, Jan 11, 2017 at 11:45:11PM +0100, Julien Puydt wrote: > Upstream was kind enough to release 0.4.7 which has everything settled -- I > updated both the git repository and mentor's. oh, this is the best of all the worlds :D > Back to RFS-ing :-) uplaoded! -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature --- End Message ---
Bug#851097: RFS: par2cmdline/0.6.14-2 -- PAR 2.0 compatible file verification and repair tool
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for "par2cmdline": Package name: par2cmdline Version : 0.6.14-2 Upstream Author : Ike Devolder et al. URL : https://github.com/Parchive/par2cmdline License : GPL-2+ Section : utils It builds a single binary package: par2 - PAR 2.0 compatible file verification and repair tool Mentors URL: https://mentors.debian.net/package/par2cmdline Download: dget -x https://mentors.debian.net/debian/pool/main/p/par2cmdline/par2cmdline_0.6.14-2.dsc Changes since the last upload: * Control: switch git url to https. * Rules: enable all hardening options. * Patches: + add 02: restore the examples section from the previous manpage, written by Andres Salomon. (Closes: #827720) + add 03: avoid unconditional use of PATH_MAX which isn't defined on hurd. Fixes build failure on that platform. * Bump Standards-Version to 3.9.8 (from 3.9.6, no further changes). Thanks. pgp1XA_8ew8ci.pgp Description: OpenPGP digital signature
Re: Debian packaging for packages that provide the same files
On 2017-01-11 14:25 -0800, J.T. Conklin wrote:
> Niels Thykier writes:
> And now that I've refreshed my memory by reading
> (https://www.debian.org/doc/manuals/maint-guide/dother.en.html#install),
> I see that *.install files can specify both the source and destination
> paths. So maybe I can forgo configure/make/install entirely and have
> each debian/.install file copy files directly from the sources.
You can. I've just been doing this for a package which just installs
binary drivers from existing upstream collections of drivers. This is
exactly analagous to your set-up, I think, in that I have a lot of
'hardware/arch/usage/' dirs, and each one is packed up
into a very similar-looking package called
foo-hardware-usage-driver_ver_arch.deb
I have an ugly shell script to generate the control file listing all
the packages and the set of executable *.install files to do the
copying (below).
That's pretty-much what you want, I think. Please don't copy my shell
script, it's currently embarassing and rather too specific and
fragile, but it illustrates that this is actually fairly
straightforward :-)
You should do something rather fancier that actually traversed the
available directories rather than hardcoded it. You could also use
make to ensure that it was actually run to keep things uptodate, etc.
#!/bin/sh
set -e
#set -x
EGLDEPS="libegl1-x11, libgles1, libgles2, libopencl1"
# make install file and control entry for each platform/arch/gpu/display flavour
mkpkg() {
# generate dh_install file
installfile="mali-${1}-${2}-driver.install"
echo "#! /usr/bin/dh-exec" > "${installfile}"
echo "${1}/\${DEB_HOST_ARCH}/${2}/* /usr/lib/\${DEB_HOST_MULTIARCH}/" >>
"${installfile}"
chmod +x ${installfile}
#then add control entry
case "$1" in
4xx)
CODENAME="utgard"
;;
t60x|t62x)
CODENAME="midgard"
;;
t76x)
CODENAME="bifrost"
;;
esac
case "$2" in
fbdev)
TYPE="framebuffer"
DESC="the kernel framebuffer"
;;
x11)
TYPE="x11"
DESC="x11"
;;
wayland)
TYPE="wayland"
DESC="wayland"
;;
fbdev-wayland)
TYPE="wayland(no DRM)"
DESC="wayland without DRM"
;;
wayland-fbdev)
TYPE="wayland"
DESC="wayland"
;;
esac
cat >> control < control
#nasty hack for arch support - fixme!
ARCH1=armhf
ARCH2=arm64
mkpkg t62x fbdev ${ARCH1} ${ARCH2}
#mkpkg t62x wayland ${ARCH1} ${ARCH2}
#mkpkg t62x x11 ${ARCH1} ${ARCH2}
ARCH=arm64
mkpkg t62x wayland-fbdev ${ARCH}
mkpkg t62x fbdev-wayland ${ARCH}
ARCH=armhf
mkpkg t60x fbdev ${ARCH}
mkpkg t60x x11 ${ARCH}
mkpkg t62x wayland ${ARCH}
mkpkg t62x x11 ${ARCH}
mkpkg t76x fbdev ${ARCH}
mkpkg t76x x11 ${ARCH}
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
Bug#850928: RFS[ITP]: minetest-mod-3d-armor/0.4.5-1
Hi, On 11/01/2017 11:41, Mattia Rizzolo wrote: IMPORTANT NOTICE: d/copyright doesn't correspond to what you find in 0.4.5's LICENSE.md and README.md files (notice the plural) : it corresponds to the clarifications I obtained from upstream, which have been committed to their repository but haven't found their way in an official release yet: https://github.com/stujones11/minetest-3d_armor/issues/75 uh. please apply that patch, and add a Comment: field somewhere in d/copyright ; ftpmasters are not going to read this email. Upstream was kind enough to release 0.4.7 which has everything settled -- I updated both the git repository and mentor's. Back to RFS-ing :-) Snark on #debian-games
Re: Debian packaging for packages that provide the same files
Niels Thykier writes:
>> A complication is that each platform config package installs the same
>> set of files, so the normal package build technique of having all files
>> being installed to a common staging directory and each package's files
>> being selected by the debian/.install doesn't work.
>>
>
> Not quite sure I understand exactly what the issue is, so I might miss
> with this.
A quick, cut-down, example:
There are a set of configuration files for each (hardware) platform.
We generate a separate platform specific package for each, but each
package will contain the same files (but different file contents).
For this example, assume that there are only two platforms: "x1000"
and "x2000". Thus we need to create "opx-platform-config-x1000" and
"opx-platform-config-x2000" packages. Each of those packages will
contain the config file /etc/opx/foo.xml.
> Are you aware that debian/.install can be made executable and thus
> arbitrary filter based on any logic you can devise in said file?
Now that you mention it, I do recall reading this before.
And now that I've refreshed my memory by reading
(https://www.debian.org/doc/manuals/maint-guide/dother.en.html#install),
I see that *.install files can specify both the source and destination
paths. So maybe I can forgo configure/make/install entirely and have
each debian/.install file copy files directly from the sources.
> The only two uses in Debian, I know of, rely on the selection being done
> /before/ the build starts. Not quite sure how they well they fit you,
> but they are:
>
> * Generating debian/control from debian/control.in
> * Using Build-Profiles to omit building some packages (using a
>"pkg.${sourcepkg}.${name_of_choice}" profile[1]).
>
> [1] https://wiki.debian.org/BuildProfileSpec
>
> It is primarily targeted as dealing with dependencies bootstrapping
> issues, but it does list an "Extension namespace".
Thanks Niels, I'll follow up on these as well.
--jtc
Re: Patch upload not showing up in deferred queue
Dear Taylor, On Tue, Jan 10, 2017 at 06:51:56PM -0600, Taylor Kline wrote: > Ooh okay. Thank you 😊 > > So how do non-DDs help out with providing patches? My last e-mail was overly curt. Sorry about that. As others have said, you can just submit the patch to the bug. You will generally be credited by the maintainer in the Debian changelog. If you think the maintainer is taking too long to respond to your fix, though, you can prepare an NMU, and then get a sponsor to upload it (though this would be unusual for a bug of 'wishlist' severity). Please read up on our conventions for NMUs in the Debian Developer's Reference. Thank you for your contribution. -- Sean Whitton signature.asc Description: PGP signature
Bug#851068: RFS: mathicgb/1.0~git20170104-1
Package: sponsorship-requests
Severity: normal
Dear mentors,
I am looking for a sponsor for my package "mathicgb":
* Package name: mathicgb
Version : 1.0~git20170104
Upstream Author : Bjarke Hammersholt Roune and Mike Stillman
* URL : https://github.com/Macaulay2/mathicgb
* License : GPL-2+
Section : math/libs
It builds those binary packages:
mathicgb - Compute Groebner bases (command line tool)
libmathicgb-dev - Compute Groebner bases (developer tools)
libmathicgb0 - Compute Groebner bases (runtime library)
To access further information about this package, please visit the
following URL:
https://anonscm.debian.org/git/debian-science/packages/mathicgb.git
Changes since the last upload:
mathicgb (1.0~git20170104-1) unstable; urgency=medium
* New upstream release (git snapshot).
* debian/control
- Bump to Standards-Version 3.9.8.
- Remove libmathicgb-dbg package in favor of new automatically
generated *-dbgsym packages.
* debian/mathicgb.install
- Move installation of manpage to dh_install.
* debian/{mathicgb.manpages,mgb.1}
- Remove files; manpage added upstream.
* debian/rules
- Add --dbgsym-migration option to dh_strip.
* debian/tests/unittest
- Use upstream unit tests for continuous integration.
-- Doug Torrance Wed, 11 Jan 2017 16:46:27 -0500
Regards,
Doug Torrance
Re: Preference for build or debhelper installing systemd unit files?
Niels Thykier writes: >> My question, in the case where the same organization/people are >> responsible for both the software and the debian packaging, is whether >> there is a preference of which method is used. > If you are (working on/with) upstream and doing the packaging, I believe > making the upstream build system install the systemd file correctly is > preferred. The primary motivation being that the service file is then > also installed when: > > * packaging is done for another non-Debian-based distribution >(possibly done by volunteers outside your organization). > > * an end users wants to compile from source (on a non-Debian-based >system). > > (The argument here is not limited to systemd service files as debhelper > have other tools with similar functionality) Thanks Niels. The packages currently do it this way, so it turns out nothing needs to change. --jtc
Re: Restoring old package version
On Wed, Jan 11, 2017 at 05:54:52PM +0100, Adam Borowski wrote: > 2. 0.9.1-really-0.7.0-1 -- fugly but will go away once 0.9 stabilizes. This is ingenious. Thanks for sharing. -- Sean Whitton signature.asc Description: PGP signature
Re: Preference for build or debhelper installing systemd unit files?
J.T. Conklin: > My question, in the case where the same organization/people are > responsible for both the software and the debian packaging, is whether > there is a preference of which method is used. > > --jtc Hi, If you are (working on/with) upstream and doing the packaging, I believe making the upstream build system install the systemd file correctly is preferred. The primary motivation being that the service file is then also installed when: * packaging is done for another non-Debian-based distribution (possibly done by volunteers outside your organization). * an end users wants to compile from source (on a non-Debian-based system). (The argument here is not limited to systemd service files as debhelper have other tools with similar functionality) Thanks, ~Niels
Re: Debian packaging for packages that provide the same files
J.T. Conklin:
> [...]
>
> A complication is that each platform config package installs the same
> set of files, so the normal package build technique of having all files
> being installed to a common staging directory and each package's files
> being selected by the debian/.install doesn't work.
>
Hi,
Not quite sure I understand exactly what the issue is, so I might miss
with this.
Are you aware that debian/.install can be made executable and thus
arbitrary filter based on any logic you can devise in said file?
CAVEATS:
* Requires debhelper using compat 9+ (trivially satisfied in any
supported Debian, but ymmv if you support other targets)
* debhelper is very strict with output of executable config files
(e.g. it does not allow comments, empty lines and does not expand
wildcards).
> I could have the configure script take a platform type parameter, and
> only install the files for that platform, but there doesn't seem to be
> an obvious way to plumb that in to debian/control & debian/rules; in
> particular, I don't think you can conditionalize the output package
> names listed in the control file.
>
The only two uses in Debian, I know of, rely on the selection being done
/before/ the build starts. Not quite sure how they well they fit you,
but they are:
* Generating debian/control from debian/control.in
* Using Build-Profiles to omit building some packages (using a
"pkg.${sourcepkg}.${name_of_choice}" profile[1]).
[1] https://wiki.debian.org/BuildProfileSpec
It is primarily targeted as dealing with dependencies bootstrapping
issues, but it does list an "Extension namespace".
> Before I put this on the back burner, I thought I'd ask whether there
> are any existing packages that face this, or similar, types of issues
> that I could use as a template.
>
> Thanks in advance,
>
> --jtc
>
Hope it was useful.
Thanks,
~Niels
Bug#850821: RFS: inkscape-open-symbols/1.0-1
On 2017-01-11 18:59+0100, Adam Borowski wrote: > On Wed, Jan 11, 2017 at 06:32:59PM +0100, Félix Sipma wrote: >> On 2017-01-11 11:27+0100, Adam Borowski wrote: >>> While from technical point of view it looks good, I'm afraid there's a >>> license problem: you're mixing GPL-2 and GPL-3+. I believe this is not a >>> problem between symbol sets -- there's mere aggregation without derivation >>> or linking, but this can't be said for packaging. >> >> There's a discussion about the licensing there: >> https://github.com/Xaviju/inkscape-open-symbols/issues/61 >> >> I'm not sure about how inkscape-open-symbols could be licensed (for now it's >> GPL-2, so it's problematic, isn't it?)... Sure, it is a collection, but then, >> what would be the difference with the Debian package? > > The Debian packaging consists of nothing but a makefile (debian/rules) and a > few assorted bits of metadata. Hardly copyrightable, but above the commonly > quoted threshold of copyrightability (~10 lines). > > I might be wrong about the ftpmasters' point of view -- might be good to > hear a clarification -- but I for one don't see a difference between > aggregating two unrelated packages with conflicting licenses in one iso > image, vs aggregating two unrelated symbol sets with conflicting licenses in > one package, as long as they're clearly not derived from one another nor > linked/etc. > > So the only issue I see is license compatibility between the packaging > and every of included symbol sets separately. And here, any license > compatible with both GPL-2 and GPL-3+ will do. So, for you, if the inkscape-open-symbols is licensed under MIT (upstream intends to do that), is there a problem or not? signature.asc Description: PGP signature
Preference for build or debhelper installing systemd unit files?
This question is related to components Dell EMC (my current employer)
are contributing to the Linux Foundation's openswitch project.
With debhelper, systemd unit files can be installed by a package's build
(ie. the Makefile installs them in $DESTDIR/lib/systemd/system/...) or
they can be put in the debian/.service and dh_systemd_* will
copy them to the package. In both cases, the dh_systemd_* scripts
ensure that the proper boilerplate to enable/disable the service is
added to the package's {post,pre}{inst,rm} scriptlets.
My question, in the case where the same organization/people are
responsible for both the software and the debian packaging, is whether
there is a preference of which method is used.
--jtc
Debian packaging for packages that provide the same files
This question is related to components Dell EMC (my current employer) are contributing to the Linux Foundation's openswitch project. Dell is contributing platform independent packages that depend on a platform specific package that provides configuration files. For our own internal use, we've been using separate git repositories / packaging for each platform specific config file package. This has worked reasonably well so far, but we're starting to run into scalability issues as each new platform requires a new repository. It's also less convienent when "global" changes that effect all platforms are required. Any scalability concerns will only get worse in the openswitch context, as other vendors add support for their hardware. So I've been asked to look at alternative solutions where source for all platforms are available in a single git repository, and so developers can build a platform-config packages for any or all supported platforms. A complication is that each platform config package installs the same set of files, so the normal package build technique of having all files being installed to a common staging directory and each package's files being selected by the debian/.install doesn't work. I could have the configure script take a platform type parameter, and only install the files for that platform, but there doesn't seem to be an obvious way to plumb that in to debian/control & debian/rules; in particular, I don't think you can conditionalize the output package names listed in the control file. Before I put this on the back burner, I thought I'd ask whether there are any existing packages that face this, or similar, types of issues that I could use as a template. Thanks in advance, --jtc
Re: Restoring old package version
On Wed, Jan 11, 2017 at 05:09:10PM +0100, Mattia Rizzolo wrote: > terminology doesn't seem to be affected by any RC bug. What are you > talking about? Oh you're right, I messed up - I thought 848370 was severity serious, but it's only important. Thanks, Ross signature.asc Description: PGP signature
Bug#850821: RFS: inkscape-open-symbols/1.0-1
On Wed, Jan 11, 2017 at 06:32:59PM +0100, Félix Sipma wrote: > On 2017-01-11 11:27+0100, Adam Borowski wrote: > > While from technical point of view it looks good, I'm afraid there's a > > license problem: you're mixing GPL-2 and GPL-3+. I believe this is not a > > problem between symbol sets -- there's mere aggregation without derivation > > or linking, but this can't be said for packaging. > > There's a discussion about the licensing there: > https://github.com/Xaviju/inkscape-open-symbols/issues/61 > > I'm not sure about how inkscape-open-symbols could be licensed (for now it's > GPL-2, so it's problematic, isn't it?)... Sure, it is a collection, but then, > what would be the difference with the Debian package? The Debian packaging consists of nothing but a makefile (debian/rules) and a few assorted bits of metadata. Hardly copyrightable, but above the commonly quoted threshold of copyrightability (~10 lines). I might be wrong about the ftpmasters' point of view -- might be good to hear a clarification -- but I for one don't see a difference between aggregating two unrelated packages with conflicting licenses in one iso image, vs aggregating two unrelated symbol sets with conflicting licenses in one package, as long as they're clearly not derived from one another nor linked/etc. So the only issue I see is license compatibility between the packaging and every of included symbol sets separately. And here, any license compatible with both GPL-2 and GPL-3+ will do. Meow! -- Autotools hint: to do a zx-spectrum build on a pdp11 host, type: ./configure --host=zx-spectrum --build=pdp11
Bug#850821: RFS: inkscape-open-symbols/1.0-1
On 2017-01-11 11:27+0100, Adam Borowski wrote: > While from technical point of view it looks good, I'm afraid there's a > license problem: you're mixing GPL-2 and GPL-3+. I believe this is not a > problem between symbol sets -- there's mere aggregation without derivation > or linking, but this can't be said for packaging. There's a discussion about the licensing there: https://github.com/Xaviju/inkscape-open-symbols/issues/61 I'm not sure about how inkscape-open-symbols could be licensed (for now it's GPL-2, so it's problematic, isn't it?)... Sure, it is a collection, but then, what would be the difference with the Debian package? signature.asc Description: PGP signature
Bug#850664: RFS: python-pynzb/0.1.0-3
control: tag -1 +moreinfo Hello Carl, I think you forgot to `git push` :) Also, it would be good if you could use the Forwarded: header to indicate whether your patches have been sent upstream or not. This is especially useful in team-maintained packages. If you add this now, don't forget `dch -r` and `git push` ;) -- Sean Whitton signature.asc Description: PGP signature
Bug#850607: marked as done (RFS: flask-login/0.4.0-1 [ITA])
Your message dated Wed, 11 Jan 2017 10:11:08 -0700 with message-id <2017071108.gdn7n5hh5t7ao...@hephaestus.silentflame.com> and subject line Re: Bug#850607: RFS: flask-login/0.4.0-1 [ITA] has caused the Debian Bug report #850607, regarding RFS: flask-login/0.4.0-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.) -- 850607: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850607 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: normal Control: block 836501 by -1 Dear mentors, I am looking for a sponsor for my package "flask-login" * Package name: flask-login Version : 0.4.0-1 * URL : https://github.com/maxcountryman/flask-login * License : Expat Section : python It builds these binary packages: python3-flask-login - user session management for Flask -- Python 3 module python3-flask-login-doc - user session management for Flask -- documentation I am adopting this package in order to build the Python 3 module which is a dependency of flexget (ITP: #724718) and has also been requested by multiple people in #802614. To be clear I am not targeting stretch even if that's somehow possible at this stage. I have dropped the Python 2 module binary package since there were no rdeps and my understanding is that going forward we don't want to keep around unnecessary Python 2 packages. To access further information about this package, please visit the following URL: https://mentors.debian.net/package/flask-login Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/f/flask-login/flask-login_0.4.0-1.dsc Changes since the last upload: flask-login (0.4.0-1) experimental; urgency=medium * New upstream release. * New maintainer (Closes: #836501). * Update d/compat to 10. * Switch to using dh-python. * Relicense debian/* as Expat to match upstream. * Change d/watch to follow GitHub releases. * Change homepage to GitHub. * Build the Python 3 module (Closes: #802614). * Stop building the Python 2 module (no rdepends). * Move Vcs to DPMT git. * Bump standards version to 3.9.8 (no changes). * Build the documentation in a -doc package. * Add 0001-disable-github-fork-ribbon.patch to turn off the GitHub ribbon. * Run the test suite using upstream's makefile. -- Carl Suster Sun, 08 Jan 2017 20:13:27 +1100 Cheers, Carl --- End Message --- --- Begin Message --- Hello Carl, Uploading now. Thank you for your adoption! Tip: you can use the Forwarded: patch header to indicate whether a patch is Debian-specific or has been forwarded upstream. -- Sean Whitton signature.asc Description: PGP signature --- End Message ---
Re: Restoring old package version
On Wed, Jan 11, 2017 at 05:09:10PM +0100, Mattia Rizzolo wrote: > On Wed, Jan 11, 2017 at 10:48:58AM -0500, Ross Vandegrift wrote: > > In [1], it says to upload the > > old version. I'm not clear on what I need to do - should I open > > an RFS with the old version from snapshot.d.o? > > That wouldn't be enough, you can't upload a version lower than what's > already in the target suite. 1. Epoch: 1:0.7.0-2 -- looks better in the short term, but stays forever. 2. 0.9.1-really-0.7.0-1 -- fugly but will go away once 0.9 stabilizes. Meow! -- Autotools hint: to do a zx-spectrum build on a pdp11 host, type: ./configure --host=zx-spectrum --build=pdp11
Re: Bug#850789: Patch upload not showing up in deferred queue
I see, thank you, Gianfranco. So if I'm getting this correctly, only providing the output of nmudiff is enough, without needing to upload anything? On Jan 11, 2017 1:36 AM, "Gianfranco Costamagna" wrote: control: tags -1 patch >It's not useful for me to spare the maintainer(s) the work? 😐 I figured if I could do the footwork and let the maintainer just review and approve the patch, they >would be happy. you already opened a bug, provided a patch and I'm tagging this bug accordingly. The maintainer will probably upload the package with some more changes in some days (uploading a src:python3 package with just a change in watch file is an overkill, people will upgrade their pc with MB of stuff, just because of a "useless to them" packaging change). Moreover the Debian Maintainer is also upstream developer, so he knows when a new version is out :) thanks for the patch, I'm sure it will be eventually added! G.
Re: Bug#850789: Patch upload not showing up in deferred queue
Hi Taylor, >So if I'm getting this correctly, only providing the output of nmudiff is >enough, without needing to upload anything? yep, also finding a sponsor or waiting for a maintainer upload, but in this case the patch is enough I think :) G.
Re: Restoring old package version
On Wed, Jan 11, 2017 at 10:48:58AM -0500, Ross Vandegrift wrote: > terminology was affected by the RC bugs flooding issue mentioned in the > recent email on the Strech freeze status. terminology doesn't seem to be affected by any RC bug. What are you talking about? > In [1], it says to upload the > old version. I'm not clear on what I need to do - should I open > an RFS with the old version from snapshot.d.o? That wouldn't be enough, you can't upload a version lower than what's already in the target suite. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Restoring old package version
terminology was affected by the RC bugs flooding issue mentioned in the recent email on the Strech freeze status. In [1], it says to upload the old version. I'm not clear on what I need to do - should I open an RFS with the old version from snapshot.d.o? Thanks, Ross [1]: https://lists.debian.org/debian-devel-announce/2017/01/msg2.html
Bug#850918: RFS: rear/2.00+dfsg-1 ITP: rear -- Bare metal disaster recovery and system migration framework
Hello Frederic Bonnard, On Wed, Jan 11, 2017 at 09:28:19AM +0100, Frederic Bonnard wrote: > > Package: sponsorship-requests > Severity: normal > > Dear mentors, Gianfranco, > first best wishes to you all for this new year, health, success ; > especially in you Debian area :) . > > I am looking for a sponsor for my package "rear". > This is an upgrade to previous 1.19 and it fixes a FTBFS bug. Extract from > d/changelog : > > rear (2.00+dfsg-1) unstable; urgency=medium > > * New upstream release > * d/control : move asciidoc to Build-Depends (Closes: #849303) > > -- Frédéric Bonnard Tue, 10 Jan 2017 15:12:34 > +0100 [...] Given asciidoc was recently restructured with a new package split and the asciidoc package itself became a meta-package shouldn't you also take this opportunity to switch your build-dep to something else, like possibly asciidoc-base? (Not sure exactly what your needs are and which one of the asciidoc packages is suitable for you. The rear-doc package only seems to contain html files though and the asciidoc-base package description makes me think that's the suitable one.) Regards, Andreas Henriksson
Re: [Debian-med-packaging] Help with watch file for ecopcr needed
On Wed, Jan 11, 2017 at 03:16:38PM +0100, Sascha Steinbiss wrote: > > Any idea how to properly download the upstream source tarball with > > uscan? > > could you please try: > > opts=filenamemangle=s/.*\.tar\.gz\?ref=ecopcr_v?(\d\S+)/ecopcr-$1\.tar\.gz/g > \ > https://git.metabarcoding.org/obitools/ecopcr/tags?sort=updated_desc > .*archive\.tar\.gz\?ref=ecopcr_v?(\d\S+) > > This seems to have worked for me, I get a proper orig tarball. Works - feel free to commit to Git in future cases. :-) Thanks Andreas. -- http://fam-tille.de
Bug#850678: marked as done (RFS: gnome-shell-extension-show-ip/4.0.1-2 [ITP])
Your message dated Wed, 11 Jan 2017 15:21:58 +0100 with message-id <2017042158.ga27...@fatal.se> and subject line Re: RFS: gnome-shell-extension-show-ip/4.0.1-1 [ITP] has caused the Debian Bug report #850678, regarding RFS: gnome-shell-extension-show-ip/4.0.1-2 [ITP] 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.) -- 850678: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850678 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "gnome-shell-extension-show-ip" * Package name: gnome-shell-extension-show-ip Version : 4.0.1-1 Upstream Author : Kyle Robbertze * URL : https://gitlab.com/paddatrapper/show-ip-gnome-extension * License : GPL-3+ Section : gnome It builds these binary packages: gnome-shell-extension-show-ip - Shows the current private or public IP address To access further information about this package, please visit the following URL: https://mentors.debian.net/package/gnome-shell-extension-show-ip Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/g/gnome-shell-extension-show-ip/gnome-shell-extension-show-ip_4.0.1-1.dsc More information about gnome-shell-extension-show-ip can be obtained from https://gitlab.com/paddatrapper/show-ip-gnome-extension Changes since the last upload: gnome-shell-extension-show-ip (4.0.1-1) unstable; urgency=medium * Initial release (Closes: #850672) -- Kyle Robbertze Mon, 09 Jan 2017 09:42:24 +0200 Regards, Kyle Robbertze signature.asc Description: OpenPGP digital signature --- End Message --- --- Begin Message --- Hi Kyle Robbertze, On Tue, Jan 10, 2017 at 09:43:07PM +0200, Kyle Robbertze wrote: > Hi Andreas Henriksson, > > On 10/01/2017 15:36, Andreas Henriksson wrote: > > Hello Kyle Robbertze, > > > > [...] > > In my personal opinion it's your choice to "upgrade" to the later version > > but in my experience the ftp-masters expect you to document the original > > licensing offer made by upstream in debian/copyright. > > (So if you actually intend to upgrade the version of the license > > you likely atleast need to state this explicitly so it's obvious > > when it gets reviewed. I assume it's a simple mistake on your side > > though and you intended to use the same license as upstream.) > I licensed it under the GPLv3+, because, while src/extension.js is ... and src/prefs.js is also GPLv2+ ... > licensed under the GPLv2+, the rest according to the LICENSE file is > under the GPLv3+. Should I rather add the src/extension.js exception? Indeed LICENSE file is GPLv3 which I find peculiar. The extension is basically made up of: src/convenience.js: BSD (3 clause) src/extension.js: GPL (v2 or later) src/prefs.js: GPL (v2 or later) Other files like schemas, json, etc. are likely not copyrightable at all, but what do I know. You might want to ask your upstream to clarify the licensing situation. For now documenting the overall license to be GPLv3+ is probably ok, but I think ftp-masters might say you should still document the src/extension.js and src/prefs.js as GPLv2+ though. Lets upload and see what they say... be prepared for possibly a reject. Apart from that I can't really spot any real issues with your package. One advice though would be to make install.sh reusable via DESTDIR and use it from debian/rules instead of duplicating install.sh in debian/rules. Basically replace DEST=... in install.sh with: if [ -z "$DESTDIR" ]; then DESTDIR=~/.local//$NAME else DESTDIR="$DESTDIR/$NAME" fi You might also want to add -p to your mkdir call. Then call it like this from debian/rules: DESTDIR=debian/tmp/usr/share/./extensions ./install.sh local-install This means you can also drop debian/*install etc. Just a suggestion. Anyway, uploaded. Regards, Andreas Henriksson--- End Message ---
Re: [Debian-med-packaging] Help with watch file for ecopcr needed
Hi Andreas, [...] > Any idea how to properly download the upstream source tarball with > uscan? could you please try: opts=filenamemangle=s/.*\.tar\.gz\?ref=ecopcr_v?(\d\S+)/ecopcr-$1\.tar\.gz/g \ https://git.metabarcoding.org/obitools/ecopcr/tags?sort=updated_desc .*archive\.tar\.gz\?ref=ecopcr_v?(\d\S+) This seems to have worked for me, I get a proper orig tarball. Cheers Sascha signature.asc Description: OpenPGP digital signature
Help with watch file for ecopcr needed
Hi, upstream of ecopcr has added release tags at my request in their local gitlab instance. I think I adapted d/watch[1] accordingly but when doing uscan --verbose --force-download it just says uscan info:=> Package is up to date for from https://git.metabarcoding.org/obitools/ecopcr/repository/archive.tar.gz?ref=ecopcr_v0.5.0 uscan info:=> Forcing download as requested uscan info: Downloading upstream package: /obitools/ecopcr/tags/ecopcr_v0.5.0 uscan info: Requesting URL: https://git.metabarcoding.org/obitools/ecopcr/repository/archive.tar.gz?ref=ecopcr_v0.5.0 uscan info: Successfully downloaded package: /obitools/ecopcr/tags/ecopcr_v0.5.0 ... but there is nothing downloaded actually. I verified that by using wget sith the URL above the proper archive is downloaded. Any idea how to properly download the upstream source tarball with uscan? Kind regards Andreas. [1] https://anonscm.debian.org/cgit/debian-med/ecopcr.git/tree/debian/watch -- http://fam-tille.de
Bug#850942: RFS: pydbus/0.6.0-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "pydbus" * Package name: pydbus Version : 0.6.0-1 Upstream Author : Linus Lewandowski * URL : https://github.com/LEW21/pydbus * License : LGPL-2.1+ Section : python It builds these binary packages: python-pydbus - Pythonic D-Bus library (Python 2) python-pydbus-doc - Pythonic D-Bus library (common documentation) python3-pydbus - Pythonic D-Bus library (Python 3) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/pydbus Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/pydbus/pydbus_0.6.0-1.dsc It is also in Alioth: https://anonscm.debian.org/cgit/python-modules/packages/pydbus.git/ Changes since the last upload: pydbus (0.6.0-1) unstable; urgency=low * New upstream release. * Update copyright info to reflect upstream author's new name and email address. * Remove no longer necessary .pyremove files. * Add autopkgtest tests. * Lower rst2html's report level when generating README.html to avoid warnings on minor typo. * Add Multi-Arch tags. Regards, -- Alberto Caso Servicio de Implantación de Sistemas. Dir. Gral. de Administración Electrónica y Tecnologías de la Información. Consejería de Hacienda y Administración Pública. Junta de Extremadura.
Bug#850664: RFS: python-pynzb/0.1.0-3
Hi Gianfranco,
Thanks for your comments!
what about calling 2to3 in setup.py?
I somehow overlooked that this was possible. That's much more sensible than what
I was doing.
and you can patch the code with a retro-compatible code
if you can't find a way that works with both python2 and 3, there is the
version_info
variable that can help you in understanding what is the current interpreter
Ok, I've added a patch to do it the sys.version_info way since there doesn't
seem to be a more elegant option.
I'm mostly sure upstream would appreciate a porting/retrocompatible patch :)
I hope so!
I've uploaded a new version which removes the d/rules hacks and implements
proper patches (to be forwarded upstream at a later date). New diff from the
same base is below.
Cheers,
Carl
$ git diff 281489c
diff --git a/debian/.git-dpm b/debian/.git-dpm
index b634411..f93cbbb 100644
--- a/debian/.git-dpm
+++ b/debian/.git-dpm
@@ -1,6 +1,6 @@
# see git-dpm(1) from git-dpm package
-0a5a3e9b44be1ec1a150c027a07754a53f039189
-0a5a3e9b44be1ec1a150c027a07754a53f039189
+591e67b26a2d694d5aae2d77985eab4d8daf2d9e
+591e67b26a2d694d5aae2d77985eab4d8daf2d9e
124074ce42e5d83c71e028a8757afb392cc96548
124074ce42e5d83c71e028a8757afb392cc96548
python-pynzb_0.1.0.orig.tar.gz
diff --git a/debian/changelog b/debian/changelog
index c9a8606..2895253 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -2,27 +2,33 @@ python-pynzb (0.1.0-3) unstable; urgency=medium
* Add myself to uploaders.
* Switch to pybuild and dh-python.
- * Bump d/compat to 10.
+ * Bump d/compat to 10 and update version of B-D on debhelper.
* Bump standards-version to 3.9.8 (no changes).
- * d/copyright: add myself and fix license short names
-- "public domain" -> public-domain
+ * d/copyright: add myself and fix license short names:
+- "public domain" -> public-domain,
- BSD -> BSD-3-clause.
* Change Vcs to DPMT git repository and use https.
- * Change Homepage to GitHub.
- * Build the Python 3 module and drop the Python 2 module (no rdeps).
- * Run the test suite with pytest.
- * Call 2to3 during auto build.
- * 0001-set-message_id-properly-in-expat-parser.patch: fix an upstream code.
-This change allows the tests to pass for Python 2.
+ * Change Homepage to Github.
+ * Build the Python 3 module.
+- replace B-D: python{,3}-setuptools and python{,3}-all
+ * Drop the Python 2 module (no rdeps):
+ * Run the test suite with pytest:
+- cleanup the produced .cache/ in d/clean,
+- add B-D on python3-pytest.
+ * 0001-set-message_id-properly-in-expat-parser.patch: fix an upstream code
+typo. This change allows the tests to pass for Python 2.
+ * 0002-enable-use_2to3-in-setup.py.patch: enable 2to3 invocation in setup.py.
* Move lxml to Suggests rather than Depends since there are fallbacks using
standard library XML parsers.
* Build-Depend on lxml in order to run the test for the implementation of the
NZB parser using lxml (LXMLNZBParser).
- * For Python 3, add a command to PYBUILD_AFTTER_BUILD_python3 in d/rules to
-change the code to decode strings -> bytes as utf-8 for lxml's benefit.
- * Fix watch file.
+ * 0003-give-lxml-etree-BytesIO-in-Python-3.patch: make the code Python 3
+compatible by decoding strings -> bytes as UTF-8 and substituting BytesIO
+for StringIO. This only affects the LXMLNZPParser.
+ * Fix watch file and declare version 4 format.
+ * Cleanup .egg-info files in d/clean and d/source/options.
- -- Carl Suster Tue, 10 Jan 2017 15:49:05 +1100
+ -- Carl Suster Wed, 11 Jan 2017 23:24:01 +1100
python-pynzb (0.1.0-2) unstable; urgency=low
diff --git a/debian/patches/0002-enable-use_2to3-in-setup.py.patch
b/debian/patches/0002-enable-use_2to3-in-setup.py.patch
new file mode 100644
index 000..16f2a85
--- /dev/null
+++ b/debian/patches/0002-enable-use_2to3-in-setup.py.patch
@@ -0,0 +1,21 @@
+From 01027917584eafdf4228bf0590123dfd47fe14a8 Mon Sep 17 00:00:00 2001
+From: Carl Suster
+Date: Wed, 11 Jan 2017 22:23:32 +1100
+Subject: enable use_2to3 in setup.py
+
+---
+ setup.py | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/setup.py b/setup.py
+index 0fd9d51..62f1ff3 100644
+--- a/setup.py
b/setup.py
+@@ -168,4 +168,5 @@ setup(
+ include_package_data=True,
+ zip_safe=False,
+ install_requires=['setuptools'],
+-)
+\ No newline at end of file
++use_2to3=True,
++)
diff --git a/debian/patches/0003-give-lxml-etree-BytesIO-in-Python-3.patch
b/debian/patches/0003-give-lxml-etree-BytesIO-in-Python-3.patch
new file mode 100644
index 000..aac136f
--- /dev/null
+++ b/debian/patches/0003-give-lxml-etree-BytesIO-in-Python-3.patch
@@ -0,0 +1,40 @@
+From 591e67b26a2d694d5aae2d77985eab4d8daf2d9e Mon Sep 17 00:00:00 2001
+From: Carl Suster
+Date: Wed, 11 Jan 2017 22:34:34 +1100
+Subject: give lxml etree BytesIO in Python 3
+
+The lxml etree API changed in Python 3 to take BytesIO instead of
+StringIO. This
Bug#850495: marked as done (RFS: safe/0.4-1 [ITP])
Your message dated Wed, 11 Jan 2017 23:22:31 +1100 with message-id and subject line Re: Bug#850088: ITP: safe -- password strength checking library for Python has caused the Debian Bug report #850495, regarding RFS: safe/0.4-1 [ITP] 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.) -- 850495: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850495 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: wishlist Control: block #850088 by -1 Dear mentors, I am looking for a sponsor for my package "safe" * Package name: safe Version : 0.4 Upstream Author : Hsiaoming Yang * URL : https://github.com/lepture/safe * License : BSD Programming Lang: Python Description : password strength checking library for Python I've packaged this because it is a dependency of flexget (ITP: #724718). It builds those binary packages: python3-safe - password strength checking library for Python To access further information about this package, please visit the following URL: https://mentors.debian.net/package/safe Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/s/safe/safe_0.4-1.dsc Cheers, Carl --- End Message --- --- Begin Message --- Control: tag 850088 +wontfix Control: tag 850495 +wontfix I have decided to withdraw this ITP/RFS because I discovered that the python-zxcvbn package already in the Debian archives can fulfil the same function. I convinced upstream flexget to drop the dependency on Safe in favour of zxcvbn: https://github.com/Flexget/Flexget/pull/1620 Note however that the Debian package is following an abandoned fork of zxcvbn with a slightly different API: https://bugs.debian.org/850910 Cheers, Carl--- End Message ---
Bug#850821: RFS: inkscape-open-symbols/1.0-1
On 2017-01-11 11:27+0100, Adam Borowski wrote: > Control: tag -1 +moreinfo > > On Tue, Jan 10, 2017 at 02:38:00PM +0100, Félix Sipma wrote: >> I am looking for a sponsor for my package "inkscape-open-symbols". >> inkscape-open-symbols - Open source SVG symbol sets that can be used as >> Inkscape symbols >> >> Package: inkscape-open-symbols >> Version: 1.0-1 >> Upstream Author: Xaviju >> Homepage: http://github.com/Xaviju/inkscape-open-symbols >> License: GPL-2 >> Section: graphics > >> dget -x >> https://mentors.debian.net/debian/pool/main/i/inkscape-open-symbols/inkscape-open-symbols_1.0-1.dsc > > While from technical point of view it looks good, I'm afraid there's a > license problem: you're mixing GPL-2 and GPL-3+. I believe this is not a > problem between symbol sets -- there's mere aggregation without derivation > or linking, but this can't be said for packaging. > > Meow! I've fixed some of the licenses (which where in fact GPL-2+). I'm trying to see if upstream agrees to relicense inkscape-open-symbols to GPL-2+ and then I'll do another package. Nice catch! signature.asc Description: PGP signature
Bug#850928: RFS[ITP]: minetest-mod-3d-armor/0.4.5-1
Control: owner -1 ! Control: tag -1 moreinfo On Wed, Jan 11, 2017 at 11:34:18AM +0100, Julien Puydt wrote: > I am looking for a sponsor for my package "minetest-mod-3d-armor" o/ > Vcs-Git: > https://anonscm.debian.org/git/pkg-games/minetest-mod-3d-armor.git > IMPORTANT NOTICE: d/copyright doesn't correspond to what you find in > 0.4.5's LICENSE.md and README.md files (notice the plural) : it corresponds > to the clarifications I obtained from upstream, which have been committed to > their repository but haven't found their way in an official release yet: > https://github.com/stujones11/minetest-3d_armor/issues/75 uh. please apply that patch, and add a Comment: field somewhere in d/copyright ; ftpmasters are not going to read this email. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#850928: RFS[ITP]: minetest-mod-3d-armor/0.4.5-1
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "minetest-mod-3d-armor" * Package name: minetest-mod-3d-armor Version : 0.4.5-1 Upstream Author : Stuart Jones * URL : https://github.com/stujones11/minetest-3d_armor * License : LGPL-2.1, CC-BY-SA-3.0 and WTFPL Section : games It builds those binary packages: minetest-mod-player-3d-armor - Modpack to add armor and wielded weapons for Minetest To access further information about this package, please visit the following URL: https://mentors.debian.net/package/minetest-mod-3d-armor Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/m/minetest-mod-3d-armor/minetest-mod-3d-armor_0.4.5-1.dsc It is packaged within the Debian Games Team: Vcs-Git: https://anonscm.debian.org/git/pkg-games/minetest-mod-3d-armor.git Vcs-Browser: https://anonscm.debian.org/git/pkg-games/minetest-mod-3d-armor.git IMPORTANT NOTICE: d/copyright doesn't correspond to what you find in 0.4.5's LICENSE.md and README.md files (notice the plural) : it corresponds to the clarifications I obtained from upstream, which have been committed to their repository but haven't found their way in an official release yet: https://github.com/stujones11/minetest-3d_armor/issues/75 Thanks, Snark on #debian-games
Bug#850821: RFS: inkscape-open-symbols/1.0-1
Control: tag -1 +moreinfo On Tue, Jan 10, 2017 at 02:38:00PM +0100, Félix Sipma wrote: > I am looking for a sponsor for my package "inkscape-open-symbols". > inkscape-open-symbols - Open source SVG symbol sets that can be used as > Inkscape symbols > > Package: inkscape-open-symbols > Version: 1.0-1 > Upstream Author: Xaviju > Homepage: http://github.com/Xaviju/inkscape-open-symbols > License: GPL-2 > Section: graphics > dget -x > https://mentors.debian.net/debian/pool/main/i/inkscape-open-symbols/inkscape-open-symbols_1.0-1.dsc While from technical point of view it looks good, I'm afraid there's a license problem: you're mixing GPL-2 and GPL-3+. I believe this is not a problem between symbol sets -- there's mere aggregation without derivation or linking, but this can't be said for packaging. Meow! -- Autotools hint: to do a zx-spectrum build on a pdp11 host, type: ./configure --host=zx-spectrum --build=pdp11
Re: Patch upload not showing up in deferred queue
On Tue, Jan 10, 2017 at 06:51:56PM -0600, Taylor Kline wrote: > So how do non-DDs help out with providing patches? By attaching patches in the bugs. The ability to actually upload the packages is the whole distinction between DD and external contributors. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#847941: RFS: libvecpf/1.1.0-1 ITP: libvecpf -- Vector Printf Library
Hi Tobias, Gianfranco. Tobias, Thierry agreed and I change the owner, I hope it's better now. Any of you would have time to review the package? I added Gianfranco as is my usual sponsor, but I forgot to Cc him in my initial request. Thanks, F. On Mon, 19 Dec 2016 08:12:06 +0100, Tobias Frost wrote: > Control: tags -1 wontfix > Control: block 806720 by -1 > > Hi Frederick, > > the ITP is owned by Thierry Fauck, did you check with him if it is ok > to take this ITP? (Should be done via the BTS and then the ITP's meta > data should be corrected accordingly. > > Please remove the wontfix when this has been resolved. > > -- > tobi > pgpJRdZtHS2hi.pgp Description: PGP signature
Bug#850918: RFS: rear/2.00+dfsg-1 ITP: rear -- Bare metal disaster recovery and system migration framework
Package: sponsorship-requests Severity: normal Dear mentors, Gianfranco, first best wishes to you all for this new year, health, success ; especially in you Debian area :) . I am looking for a sponsor for my package "rear". This is an upgrade to previous 1.19 and it fixes a FTBFS bug. Extract from d/changelog : rear (2.00+dfsg-1) unstable; urgency=medium * New upstream release * d/control : move asciidoc to Build-Depends (Closes: #849303) -- Frédéric Bonnard Tue, 10 Jan 2017 15:12:34 +0100 --- Package name: rear Version : 2.00+dfsg-1 Upstream Author : Schlomo Schapiro, Gratien D'haese, Stefan Semmelroggen, Peer Heinlein, Dag Wieers, Jeroen Hoekx URL : https://github.com/rear/rear/ License : GPL-3+, LGPL-2.1+, GPL-2+ Section : admin It builds those binary packages: rear - Bare metal disaster recovery and system migration framework rear-doc - Bare metal disaster recovery and system migration framework (documentation) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/rear Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/r/rear/rear_2.00+dfsg-1.dsc More information about rear can be obtained from http://relax-and-recover.org/ Note: There is a load of Info lintians but this is due to the fact that rear embeds skeleton files/dirs that won't be use by the system installing rear, but those files will be used by the rear OS created to be booted later. Regards, Frederic Bonnard pgpcRTal130QX.pgp Description: PGP signature
