Re: RFS: pcapy/0.11.3-1 [ITA]
On Saturday, August 11 2018, eamanu wrote:
> Hello Sergio!
>
> Thanks for your comments!
No problem, and sorry for the delay.
> 1) On d/copyright, the license specified for the project is wrong.
>> According to the LICENSE file, the project is released under a slightly
>> modified version of the Apache license. This is something really
>> important to get right, otherwise the ftp-masters will certainly reject
>> the package. You listed the license as being "GPL-2", but the text is
>> clearly not GPL-2.
>>
>> Ohh!!! Sorry I saw the old d/copyright file to do this.
No problem. However, the "License:" still doesn't reflect the license
of the software. According to LICENSE:
We provide this software under a slightly modified version of the
Apache Software License. The only changes to the document were the
replacement of "Apache" with "Pcapy" and "Apache Software Foundation"
with "CORE Security Technologies". Feel free to compare the resulting
document to the official Apache license.
The `Apache Software License' is an Open Source Initiative Approved
License.
Therefore, I think a better value for the field would be:
License: Apache with Pcapy modifications
Also, please remove the "All rights reserved." text here:
Copyright (C) 2003-2011 CORE Security Technologies .
All rights reserved.
Oh, and please fix the years. Nowhere in the code I see "2003-2011".
Doing a basic grep, I see that the year should be 2014.
> 2) Still on d/copyright: as said above, the GPL-2 license is wrong.
>> However, I think it's also important to mention that the license text is
>> formatted in a strange/wrong manner. You have text like this:
>>
>> [...]
>> Redistribution and use in source and binary forms, with or without
>>modification, are permitted provided that the following conditions
>>are met:
>>
>>1. Redistributions of source code must retain the above
>> [...]
>>
>> The correct format for d/copyright is to indent the text using 1 space,
>> and to use . (dot) for blank lines. Like this:
>>
>> [...]
>> Redistribution and use in source and binary forms, with or without
>> modification, are permitted provided that the following conditions
>> are met:
>> .
>> 1. Redistributions of source code must retain the above
>> [...]
>>
>
>
> Ready!
Thanks.
I see that the contributions under the debian/ directory are released
under GPL-3+. That's absolutely fine (I am a GPL advocate as well).
However, I must warn you that the Debian patches will also be released
under this license, which may be problematic if/when you decide to
upstream them. But I understand this is the current situation anyway.
You may want to try to contact Arnaud Fontaine and ask him if he's OK
with changing the license to Apache in the future.
>>
>> 3) The package uses a *really* old version of debhelper (version 5!).
>> We're at version 11 already, so you should update both d/compat and
>> d/control (i.e., depend on debhelp >= 11) to reflect that.
>>
>
> Ready!
Thanks.
>>
>> 4) You haven't addressed my comment about building a Python 3 package.
>> IMO you should really do that; lintian will warn you if you don't.
>>
>
> Yes, I forgot do that! Sorry!
Thanks, but what you did is incomplete. In order to create a new
package, you have to create an entry for it on d/control. What you did
(add ${python3:Depends} to python-pcapy's Depends) is wrong because
you're basically pulling Python 3 dependencies for a Python 2 package.
Please have a look at other packages under them DPMT and check their
d/control; you will find many examples of how to create Python 3
packages.
>>
>> 5) You haven't answered my question about why the package has "Suggests:
>> doc-base". It seems to be a relic from this very old debhelper; I think
>> you can safely remove it.
>>
>
> Yes, I remove it. Since I do not have much knowledge about doc-base and why
> it is there, I left it. But now is removed.
Thanks,
--
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/
signature.asc
Description: PGP signature
Bug#905654: marked as done (RFS: usbguard/0.7.2+ds-2)
Your message dated Sun, 19 Aug 2018 21:29:34 +0300 with message-id <20180819182934.GA25940@localhost> and subject line Re: Bug#905654: RFS: usbguard/0.7.2+ds-2 has caused the Debian Bug report #905654, regarding RFS: usbguard/0.7.2+ds-2 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.) -- 905654: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905654 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 "usbguard" * Package name : usbguard Version : 0.7.2+ds-2 Upstream Author : Daniel Kopeček * Url : https://dkopecek.github.io/usbguard/ * Licenses : public-domain,CC-BY-SA-3.0,GPL-3+,GPL-2+,FSFULLR Programming Lang : C Section : utils The USBGuard software framework helps to protect your computer against rogue USB devices (a.k.a. BadUSB) by implementing basic whitelisting and blacklisting capabilities based on device attributes. It builds those binary packages: * libusbguard0 * usbguard * usbguard-applet-qt To access further information about this package, visit the following URL: https://mentors.debian.net/package/usbguard Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/u/usbguard/usbguard_0.7.2+ds-2.dsc Alternatively, you can access package debian/ directory via git from URL: https://salsa.debian.org/muri-guest/usbguard.git More information about usbguard can be obtained from https://dkopecek.github.io/usbguard/ Changes since last upload: * Add a postrm file to clean up on purge (Closes: #905524) Cheers, muri --- End Message --- --- Begin Message --- On Tue, Aug 07, 2018 at 07:25:04PM +0200, Muri Nicanor wrote: >... > Changes since last upload: > > * Add a postrm file to clean up on purge (Closes: #905524) Thanks, uploaded. > Cheers, > muri cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed--- End Message ---
Re: Bug#886291: Debian package transition: Rename package and reuse old name with new content
On Sat, 18 Aug 2018 at 16:31:37 +0200, Alexis Murzeau wrote: > To fix #886291, we should: > - Rename python3-pycryptodome to python3-pycryptodomex > - Reuse python3-pycryptodome package name to package a non compatible > python3 module. > > The rationale of this rename + reuse is that currently, > python3-pycryptodome contains, in fact, the pycryptodomex module. So > renaming that one + introduce the new package for the pycryptodome module. According to apt-file(1), python3-pycryptodome contains /usr/lib/python3/dist-packages/Cryptodome, which you use via "import Cryptodome". If you're renaming packages anyway, would it be better for the package containing /usr/lib/python3/dist-packages/Cryptodome to be the python3-cryptodome package? (My reasoning is that the name you import is the name of the "ABI", the same way the ABI of, for example, libdbus is represented by its SONAME libdbus-1.so.3, which we translate into libdbus-1-3 as a Debian package name.) > I already though of a solution on 886...@bugs.debian.org use multiple > dependencies with "|" but the package must still be buildable with the > first dependency (sbuild ignore dependencies after "|" for example) It's OK for packages in unstable to be uninstallable or unbuildable for a short time, as long as Depends/Breaks/Conflicts or RC bugs ensure that the brokenness doesn't propagate into testing. For instance, if you are going ahead with your renaming plan, you could give the new packages a versioned Breaks on python3-httpsig (<< H) and python3-pysnmp4 (<< S), where H is the first version of python3-httpsig that has been modified to use/expect the new (py)cryptodome(x) package layout, and S is the corresponding version of python3-pysnmp4. smcv
Bug#884697: logrotate package
Hi Andreas, thank you for taking some time and looking over the package. > I've looked over the 3.14.0-1 package version and generally everything> > looks very good to me. I'm appending my review notes about minor things > below which might be useful for future improvements none the less. Thanks! > Please tell me if you want me to go ahead with further testing and > uploading of the package, or if you already have someone else in mind > for this task. Yes, I'd like to go ahead. > Please also mention if you've contacted and what their response have > been for the people offering mentorship (like in > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887151#17 ). I messaged them (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887151#45) but got unfortunately no response yet. > WATCH OUT / HEADS UP: > - I'm not sure about the current state but this has bitten me in the > past. The debhelper systemd integration in the past had no particular > knowledge about timer units. That resulted in the service unit for the > respective timer unit being both enabled and *started* (or restarted, > depending on if the package is newly installed or upgraded) at package > installation/configure time. You likely do not want to trigger a > logrotate at package installation/upgrade time and delay the entire dpkg > operation until it completes. (I imagine some people might have massive > logs that might take a very long time.) Please verify if current > dh-systemd has improved on this front or if you need to add overrides > for logrotate.service to not be started/enabled. I suspect this might > very well be fixed now to just not start or enable services which don't > have any [Install] section (like logrotate.service, but adding a > build-time check to verify upstream doesn't slip one in there might be a > useful safety for the future?). Thanks for the hint; I checked this and package installation/upgrade does not start the service (only the timer). I am not sure though how to write a build time check. > debian/upstream/metadata: > - Repository url should have '.git' appended instead of last '/', right? > - I think Bug-Database is more revelant for listing issues url instead > of using Contact. https://salsa.debian.org/debian/logrotate/commit/46bc5f248aa7d1af886a7b413902e374486790c9 > debian/control: > - I'm not sure using github project url in Homepage field is > appropriate. It's supposed to be an url relevant for end users AFAIK. > eg. github pages url would be suitable (if available, which it doesn't > seem to be for logrotate). There is unfortunately no homepage as such. > debian/logrotate.preinst: > - how old is this? There are no version checks and I didn't look, but > maybe it can be dropped now? The less manual written maintainerscript > code the better. Seems this was changed in 3.11. so I'd like to keep this for buster. > debian/logrotate.README.Debian: > - this seems pretty outdated info as well considering for buster. Maybe > it should also be dropped? https://salsa.debian.org/debian/logrotate/commit/0dee0d88c85ecfe5e74523f0de89a50379b5e508 > debian/rules: > - neat, but even better would be line-wrapping configure override using > a backslash to put each config option on a separate line for easier > reading. https://salsa.debian.org/debian/logrotate/commit/0b52887e1256f6895a1a227df5b96db5f19315fd > debian/tests: > - given existance of tests reduces unstable->testing migration delay, > this might just be a bit too trivial test to exist alone??? > (while at the same time an existing test might be better than no test > at all) I do not know what the test environment offers, so I only wrote that simple test. In my opinion the build time tests plus the test that logrotate is running (even only printing the version and build information) is sufficient for now. But I welcome any test ideas. > debian/patches/manpage.patch: > - why is this information relevant to put in the manpage? A more general > solution would be to describe that apt-file can be used to search for > which package contains something. Not suitable to document in > specialized manpages like logrotate IMHO. Oh, I see this patch is not > listed in series file so not applied. Well, might be another reason to > drop it. https://salsa.debian.org/debian/logrotate/commit/d3f78773060c4dbc91812e8fcbd24322658e6a52 Best regards, Christian Göttsche
Bug#906646: RFS: double-conversion/3.0.0+git20180802.4e8b3b5-1 [ITA, tensorflow deps]
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "double-conversion" * Package name: double-conversion Version : 3.0.0+git20180802.4e8b3b5-1 Upstream Author : [fill in name and email of upstream] * URL : [fill in URL of upstreams web site] * License : [fill in] Section : libs It builds those binary packages: libdouble-conversion-dev - routines to convert IEEE floats to and from strings (development libdouble-conversion1 - routines to convert IEEE floats to and from strings To access further information about this package, please visit the following URL: https://mentors.debian.net/package/double-conversion Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/d/double-conversion/double-conversion_3.0.0+git20180802.4e8b3b5-1.dsc More information about hello can be obtained from 1. salsa git repo [branch: lumin/3.0.0 instead of master] https://salsa.debian.org/science-team/double-conversion 2. dom-amd64 build for sid/experimental http://debomatic-amd64.debian.net/distribution#unstable/double-conversion/3.0.0-1/buildlog autopkgtest is broken due to some debomatic reason. 3. dom-amd64 build + autopkgtest for ubuntu cosmic http://debomatic-amd64.debian.net/distribution#cosmic/double-conversion/3.0.0+git20180802.4e8b3b5-1u1/buildlog 4. ubuntu PPA cosmic build https://launchpad.net/~lumin0/+archive/ubuntu/ppa/+packages amd64, arm64, armhf, i386, ppc64el, s390x [all OK] double-conversion is a Tensorflow dependency. I'm uploading a snapshot to archive instead of the latest release 3.0.0 because libtensorflow.so FTBFS with the stable release. Note, it appears that this package doesn't need a transition slot since there is no ABI change. (however upstream changed SOVERSION due to nonsence). This package should go into experimental first, and enter unstable only if I have finished the reverse dependency check. Afterall this package has a high popcon. Changes since the last upload: double-conversion (3.0.0+git20180802.4e8b3b5-1) experimental; urgency=medium * [O/ITA] Add myself to Uploaders. (Closes: #815264) * New upstream version snapshot 3.0.0+git20180802.4e8b3b5 + Note, the SOVERSION has been bumped to 3.0.0 in upstream's cmake build. However it was bumped only because they had changed the source directory layout, and ABI has not been changed. Hence, in debian/rules SOVERSION is left unchanged because bumping it doesn't make sense for Debian and would trigger an unnecessary rebuild of the reverse dependency tree. * Update Patches. + Refresh fix_m68k.patch . - Remove fix_riscv64.patch , fixed upstream. * Modify source paths in rules , *.install and debian/*.docs , following upstream's directory layout change. * Append hardening flags to rules. * Upgrade watch file to uscan version 4. * Homepage: Upstream project transferred to google. * Add autopkgtest control file to build and run upstream tests. * Bump Standards-Version to 4.2.0 (no change). * Add -I. to CPPFLAGS in order to avoid build failure in clean chroot.
