Re: arpwatch & systemd
Hi Bastien, On Fri, 24 Mar 2017 10:56:58 + Bastien Roucaries wrote: > Will ne also nice to repack in ordre to remove oui db I'm not sure I understand what you mean… should the ethercodes.dat file be removed / used from a different package? Thanks Lukas pgpQfsxdY1uIw.pgp Description: OpenPGP digital signature
Bug#858795: RFS: python-zxcvbn/4.4.14-1 [ITA]
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "python-zxcvbn": * Package name: python-zxcvbn Version : 4.4.14-1 Upstream Author : Daniel Wolf mailto:danielrwo...@gmail.com>> * URL :https://github.com/dwolfhub/zxcvbn-python * License : MIT Section : python It builds those binary packages: python-zxcvbn - A realistic password strength estimator. To access further information about this package, please visit the following URL: https://mentors.debian.net/package/python-zxcvbn Alternatively, one can download the package with dget using this command: dget -xhttps://mentors.debian.net/debian/pool/main/p/python-zxcvbn/python-zxcvbn_4.4.14-1.dsc Changes since the last upload: I have changed upstream source to the new active fork. Regards, Sabino
Re: arpwatch & systemd
On 03/26/2017 09:19 PM, Lukas Schwaighofer wrote: > Hi Bastien, > > On Fri, 24 Mar 2017 10:56:58 + > Bastien Roucaries wrote: > >> Will ne also nice to repack in ordre to remove oui db > > I'm not sure I understand what you mean… should the ethercodes.dat file > be removed / used from a different package? Yes. See also: https://lintian.debian.org/tags/source-contains-data-from-ieee-data-oui-db.html ieee-data also contains a script that allows the admin to update the listing manually, and other packages can hook into that update process if that's required. Repacking the source seems excessive to me though, since the database is under a DFSG-compatible license (ieee-data is in main), but the binary package should probably just depend on ieee-data. (Or recommend it, if it can live with the file not being available.) Regards, Christian
ethercodes.dat / oui.txt (Was: Re: arpwatch & systemd)
Hi, On Sun, 26 Mar 2017 22:30:39 +0200 Christian Seiler wrote: > On 03/26/2017 09:19 PM, Lukas Schwaighofer wrote: > > I'm not sure I understand what you mean… should the ethercodes.dat > > file be removed / used from a different package? > > Yes. See also: > https://lintian.debian.org/tags/source-contains-data-from-ieee-data-oui-db.html > > ieee-data also contains a script that allows the admin to > update the listing manually, and other packages can hook into > that update process if that's required. thanks for clarifying. I need to convert the oui.txt database to a different format (the script to do that is already available). Two options come to my mind: 1. use the maintainer scripts (postinst?) to generate the initial version of the converted database, add a hook for ieee-data to keep it updated 2. check if the database is up to date when the arpwatch service is started by the init system, update it otherwise Option 1 seems somewhat cleaner, but if I understand the mechanisms correctly, this will only trigger when the admin (or a cron job) calls `update-ieee-data`, and not if the ieee-data package gets updated. Since that would allow the converted database to become outdated, that leaves me with option 2. Is that acceptable or is there a better way to do it? The easiest way for me to check if the converted database is up-to-date is to depend on the existence of /var/lib/ieee-data/.lastupdate . Is that ok? > Repacking the source seems excessive to me though, since the > database is under a DFSG-compatible license (ieee-data is in > main), but the binary package should probably just depend on > ieee-data. (Or recommend it, if it can live with the file not > being available.) Ok, thanks. Regards Lukas pgp7GCBgdj4at.pgp Description: OpenPGP digital signature
Bug#858800: RFS: xtrs/4.9d-1 [ITA]
Package: sponsorship-requests
Severity: normal
Dear mentors,
I seek a sponsor for my package "xtrs".
* Package name: xtrs
Version : 4.9d-1
Upstream Author : Tim Mann
* URL : http://www.tim-mann.org/xtrs.html
* License : 2 different custom permissive licenses[1]
Section : otherosfs
It builds those binary packages:
xtrs - emulator for TRS-80 Model I/III/4/4P computers
To access further information about this package, please visit the
following URL:
https://mentors.debian.net/package/xtrs
Alternatively, one can download the package with dget using this
command:
dget -x
https://mentors.debian.net/debian/pool/contrib/x/xtrs/xtrs_4.9d-1.dsc
Changes since the last upload:
* Merge new upstream release.
+ "Deleted all SIGIO code. The code was a kludge to begin with and it no
longer worked with current X libraries and Linux kernels, causing xtrs
to hang. It was also reported to cause hangs when xtrs was compiled for
Windows using Cygwin. Thanks to Howard Pepper, Dennis Lovelady, Arumin
Nueckel, Christopher Currie, and Joe Peterson for bug reports."
(Closes: #511645)
* Update README.Debian to refresh URLs and reflect developments in the
TRS-80 retrocomputing enthusiast community over the past several years.
* Implement debian/compare-copyright script.
+ Add "check" target to debian/rules to call the script.
+ Add debian/{no-,}copyright-info.expected files.
* Migrate former contents of debian/checklist to debian/README.source.
* Rewrite debian/copyright using machine-readable copyright info.
* Migrate to new (to me) quilt-based Debian source format 3.0.
+ Migrate former contents of debian/patches to debian/patch/*; dropping
patches now merged upstream.
* Migrate former contents of debian/README.contrib-only to Disclaimer field
of debian/copyright, and update discussion.
* Stop shipping Tim Mann's TRS-80 FAQ document. It's great, but strictly
speaking, it doesn't carry a license, I don't want to pester him to put
one on it, and in any event it updates much more frequently than the xtrs
software itself. Finally, I trust people to do web searches, and
archive.org to stick around, more now than I did 19 years ago.
* Write doc-base descriptions for the supplementary documentation in
/usr/share/doc/xtrs.
* Add check-source target to debian/rules to aid copyright meticulousness
checking.
* Add check-binary target to debian/rules to aid regression tesing.
* Thanks to Christian Perrier, Hector Oron, Cyril Brulebois, and
YunQiang Su for taking care of this package during my long absence.
Regards,
Branden
[1] See attachment for gory details. The licenses have been recognized
as DFSG-free for about 19 years.
-- System Information:
Debian Release: 9.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Upstream-Name: xtrs
Source: http://www.tim-mann.org/xtrs.html
Disclaimer: Requires non-DFSG-free ROM images and/or operating systems
to be useful for most purposes.
.
There is a freely-licensed boot ROM for Model 4P emulation provided with xtrs;
however, this boot image can only be used to boot an operating system designed
for the Model 4 (it is not sophisticated enough to load the BASIC interpreter
ROM for Model III compatibility mode, provided on Model 4P TRSDOS disks as a
file called MODELA/III). Since most users will likely be using this emulator
to run proprietary legacy applications for the TRS-80 computers, I do not
regard this exception as sufficient to recategorize xtrs for inclusion in main.
.
It is worth keeping an eye on projects like Contiki and FUZIX; if one of them
becomes useful under xtrs, that would be an argument for moving xtrs to main.
+ http://www.contiki-os.org/
+ https://github.com/EtchedPixels/FUZIX
License: local:Timothy-Mann-xtrs-permissive-non-copyleft
This software may be copied, modified, and used for any purpose without fee,
provided that (1) the above copyright notice is retained, and (2) modified
versions are clearly marked as having been modified, with the modifier's name
and the date included.
Files:
cd.ccc
mount.ccc
pwd.ccc
truedam.ccc
umount.ccc
unix.ccc
xtrs8.lst
xtrs8.z80
xtrshard.lst
xtrshard.z80
xtrsmous.lst
xtrsmous.z80
Copyright: 1998 Timothy Mann
License: local:Timothy-Mann-xtrs-permissive-non-copyleft
Files:
cmd.c
cmd.h
hex2cmd.c
trs_disk.c
trs_disk.h
trs_imp_exp.c
trs_imp_exp.h
trs_interrupt.c
Copyright: 1996 Timothy Mann
License: local:Timothy-Mann-xtrs-permissive-non-copyleft
Files:
cmddump.c
load_cmd.c
load_cmd.h
mkdisk.c
Copyright: 1996-98 Timothy Mann
License: local:Timot
Bug#858795: RFS: python-zxcvbn/4.4.14-1 [ITA]
control: owner -1 ! control: tags -1 moreinfo >I am looking for a sponsor for my package "python-zxcvbn": here we are: +python-zxcvbn (4.4.14-1) unstable; urgency=low + + * New maintainer (Closes: #855638) + ^^ remove this newline + * Fixed change upstream source to the active fork (Closes: #850910) + + -- Sabino Sat, 25 Mar 2017 15:30:28 +0100 + +python-zxcvbn (1.0+git20130503.bc1c2d-2) UNRELEASED; urgency=medium + + * Fixed VCS URL (https) ^^ merge this entry into the latest one + + -- Ondřej Nový Tue, 29 Mar 2016 22:28:30 +0200 and then I start the review (*really* incomplete, there is a lot of missing stuff here) 1) the changelog misses *everything*, nobody should review a package with such an incomplete one. (specially because I can't understand why you did changes) 2) moving away from a team maintained package to a single maintained one? - please no. 3) the syntax of zxcvbn (the instantiation as example), changed a lot in this fork. Did you check reverse dependencies? 4) unstable during freeze is a no-no 5) watch file is full of useless stuff 6) copyright entries should be merged (both * and both debian/*) 7) descrition too long (you shouldn't have more than 80 chars per line 8) compat level is 10 now 9) rules file has a sphinx commented documentation... why? probably a lot of stuff still need changes, but I can address it only if you fix the above. Gianfranco
