Bug#825237: RFS: mrpt/1:1.4.0-1 [ITA] [RC]
control: owner -1 ! Dear Jose, On Wed, May 25, 2016 at 12:06:50PM +0200, Jose Luis Blanco wrote: > Thank you very much for the review, indeed any help is appreciated! No problem! > > You should drop the libmrpt-dbg package, since we now have automatic > > *-dbgsym binary package generation. > > Done (upstream). I wasn't aware of this change. > In the past, I provided -dbg packages with a totally different meaning > (very similar to those provided by wxWidgets, if you are familiar with > them): they were another version of all libraries, compiled with -g > and other flags that enabled many extra run-time checks. I dropped > those packages because of the (what I understood) was the preferred > meaning of -dbg packages in Debian. > > Now that those -dbg packages have been renamed to -dbgsym, do you > think it may be a good idea to generate again those debug packages? > I would be really thankful for any advice regarding "good practices" > in this sense... Based on your description, it sounds like the -g packages might be useful for someone. The only question is what you should call the binary package. Are you saying that those packages already exist in Debian for wxWidgets? What is the binary package name in that case? > > Could you explain why you changed the package priority optional->extra? > > I did it back in January and can't find an extended description in the > commit log about *why* I did it, but it was probably because of some > Lintian error/warning regarding this part of the policy (2.5 > Priorities): > > Packages must not depend on packages with lower priority values > (excluding build-time dependencies). In order to ensure this, the > priorities of one or more packages may need to be adjusted. > > I have switched it back to "optional" upstream and will try to > re-regenerate all packages and run Lintian to see if that was the > reason. I think that the QA team's debcheck program checks for that, not Lintian. Due to a lack of clarity about the difference between the extra and optional priorities,[1] and the need to file a bug to actually change it, most of us are ignoring the particular error you have quoted for packages that already exist (though of course you should make sure new packages are fully compliant with the policy). > > Unfortunately, it fails to build on my 32-bit machine; log attached. > > wow, that's really unexpected! It seems there is an error in one CMake module: > > CMake Error at /usr/share/cmake-3.5/Modules/TestBigEndian.cmake:104 > (message): > TEST_BIG_ENDIAN found no result! > > Will investigate if it's a real problem with cmake or with my scripts. I can try the build again when you think you've fixed it; just let me know. [1] a recent thread on debian-devel I can't seem to find right now -- Sean Whitton signature.asc Description: PGP signature
Bug#825302: RFS: usbguard/0.4-2 [ITP]
Control: severity -1 wishlist Control: block 791919 by -1 Control: tags -1 moreinfo Hi, On Wed, 2016-05-25 at 21:10 +0200, Muri Nicanor wrote: > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I am looking for a sponsor for my package "usbguard" This looks like quite an interesting package, so here's a review. You do not own the wnpp bug for this package. You need to retitle the bug from an RFP to ITP and set yourself as the owner. Do this before trying to fix anything else. Since libusbguard.so is in a public libs directory, you must put it in a separate package (probably called libusbguard0). You should then put all the development files in libusbguard-dev. I see you added a lintian override for this, but didn't say why you did it in the comment. Please run wrap-and-sort so wrap the Build-Depends field in the control file. You don't need the -2 changelog entry since your -1 version was never uploaded. You add a group "usbguard" in postinst but didn't remove it in postrm. You should probably do that during the purge step. The other things in postrm seem incorrect. Why do you need to remove the service file manually? "usbguard" must depend on adduser to use addgroup in your postinst. The *.install files should use a wildcard (*) instead of including the multiarch directory manually. At the moment the package will FTBFS everywhere except amd64. In rules, --with-bundled-spdlog=no doesn't seem to work. Enable parallel building (dh --parallel) if it works. You build-depend on dh-autoreconf, but don't actually run it. Use something like "dh --with=autoreconf,systemd". copyright: Upstream code is GPL-2+ (not GPL-2) The license identifier for the Boost License is "BSL-1.0" The license identifier for your "MIT-License" is "Expat" https://spdx.org/licenses/ Authors isn't a valid field name. You can use Comment or Upstream-Contact instead. The default config doesn't allow the root user to use usbguard. This doesn't offer ant additional security, but does add inconvenience. usbguard.service contains: WantedBy=base.target but base.target doesn't exist on my system. The usbguard-rules.conf manpage uses "usbguard-daemon.conf" in the NAME section (and other places) which is obviously a typo. Please submit the patch you added upstream when you get the chance. Finally, although you've fixed all the lintian warnings, please try and fix some of the info tags. I: usbguard source: duplicate-short-description usbguard usbguard-dev I: usbguard source: debian-watch-file-is-missing I: usbguard: hardening-no-pie usr/bin/usbguard I: usbguard: hardening-no-bindnow usr/bin/usbguard I: usbguard: spelling-error-in-binary usr/lib/x86_64-linux-gnu/libusbguard.so.0.0.0 Uknown Unknown I: usbguard: hardening-no-bindnow usr/lib/x86_64-linux-gnu/libusbguard.so.0.0.0 I: usbguard: hardening-no-pie usr/sbin/usbguard-daemon I: usbguard: hardening-no-bindnow usr/sbin/usbguard-daemon I: usbguard: spelling-error-in-manpage usr/share/man/man5/usbguard-rules.conf.5.gz formated formatted I: usbguard: no-symbols-control-file usr/lib/x86_64-linux-gnu/libusbguard.so.0.0.0 I: usbguard: systemd-service-file-missing-documentation-key lib/systemd/system/usbguard.service Hopefully I've covered everything! James signature.asc Description: This is a digitally signed message part
Bug#825302: RFS: usbguard/0.4-2 [ITP]
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "usbguard" * Package name: usbguard Version : 0.4-2 Upstream Author : Daniel Kopeček * URL : https://github.com/dkopecek/usbguard * License : GPL-2 Section : utils It builds those binary packages: usbguard - Framework for implementing USB device authorization policies usbguard-dev - Framework for implementing USB device authorization policies To access further information about this package, please 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.4-2.dsc More information about usbguard can be obtained from https://dkopecek.github.io/usbguard/. Changes since the last upload: * fixing some shortcomings of the package regarding the lintian checks Regards, -- muri signature.asc Description: OpenPGP digital signature
Bug#822856: Another try for dvtm?
> Hi Dmitry, due to the partial orphaning of the package in #824284, > are you interested in this package, and starting to maintain it properly? Last version is on mentors. I think it is okay to upload, the only thing I am not sure is about close-multiple-bug syntax. -- Accept: text/plain, text/x-diff Accept-Language: eo,en,ru X-Keep-In-CC: yes X-Web-Site: sinsekvu.github.io
Re: Bug#825236: RFS: openfst/1.5.3-1 -- weighted finite-state transducers library
On 25/05/2016 13:22, Jakub Wilk wrote: > Control: tags -1 + moreinfo > > * Giulio Paci , 2016-05-24, 23:38: >> https://anonscm.debian.org/git/collab-maint/openfst.git > > The package FTBFS (on i386): > > | Making check in test > | make[3]: Entering directory '/build/openfst-aOvp6g/openfst-1.5.3/src/test' > | /usr/bin/make fst_test weight_test algo_test_log algo_test_tropical > algo_test_minmax algo_test_lexicographic algo_test_power > | make[4]: Entering directory '/build/openfst-aOvp6g/openfst-1.5.3/src/test' > | g++ -DHAVE_CONFIG_H -I./../include -Wdate-time -D_FORTIFY_SOURCE=2 -g > -O0 -fPIE -fstack-protector-strong -Wformat -Werror=format-security > -std=c++11 -c -o fst_test.o > fst_test.cc > | /bin/bash ../../libtool --tag=CXX --mode=link g++ -g -O0 -fPIE > -fstack-protector-strong -Wformat -Werror=format-security -std=c++11 -fPIE > -pie -Wl,-z,relro > -Wl,-z,now -o fst_test fst_test.o ../lib/libfst.la -lm -ldl > | libtool: link: g++ -g -O0 -fPIE -fstack-protector-strong -Wformat > -Werror=format-security -std=c++11 -fPIE -pie -Wl,-z -Wl,relro -Wl,-z -Wl,now > -o .libs/fst_test > fst_test.o ../lib/.libs/libfst.so -lm -ldl > | g++ -DHAVE_CONFIG_H -I./../include -Wdate-time -D_FORTIFY_SOURCE=2 -g > -O0 -fPIE -fstack-protector-strong -Wformat -Werror=format-security > -std=c++11 -c -o > weight_test.o weight_test.cc > | /bin/bash ../../libtool --tag=CXX --mode=link g++ -g -O0 -fPIE > -fstack-protector-strong -Wformat -Werror=format-security -std=c++11 -fPIE > -pie -Wl,-z,relro > -Wl,-z,now -o weight_test weight_test.o ../lib/libfst.la -lm -ldl > | libtool: link: g++ -g -O0 -fPIE -fstack-protector-strong -Wformat > -Werror=format-security -std=c++11 -fPIE -pie -Wl,-z -Wl,relro -Wl,-z -Wl,now > -o .libs/weight_test > weight_test.o ../lib/.libs/libfst.so -lm -ldl > | g++ -DHAVE_CONFIG_H -DTEST_LOG -Wdate-time -D_FORTIFY_SOURCE=2 -g -O0 > -fPIE -fstack-protector-strong -Wformat -Werror=format-security -std=c++11 -c > -o > algo_test_log-algo_test.o `test -f 'algo_test.cc' || echo './'`algo_test.cc > | In file included from algo_test.cc:6:0: > | ./algo_test.h:9:24: fatal error: fst/fstlib.h: No such file or directory > | compilation terminated. I added a patch for this. > (I tested 1.5.3-1, but I don't see anything changed in 1.5.3+r2-1 that would > fix it...) > Please reduce optimization level to -O0 only on architectures where it is > strictly required. Otherwise there's a risk that bugs that only trigger with > optimization enabled > go under our radar even on mainstream archs. I added some code to restrict the build to mips, mipsel and hurd-i386. > I'm fine with uploading openfst to unstable. Fine, I updated changelog accordingly. Do you think phonetisaurus [0] can also be uploaded to unstable? [0] https://anonscm.debian.org/cgit/collab-maint/phonetisaurus.git Bests, Giulio
Bug#822856: Another try for dvtm?
and with #825269 there is also an O: bug :) (thanks Mattia for the ping about it) G. Il Mercoledì 25 Maggio 2016 13:18, Gianfranco Costamagna ha scritto: Hi Dmitry, due to the partial orphaning of the package in #824284, are you interested in this package, and starting to maintain it properly? I think now can can proceed with this RFS :) let me know what is your best plan, thanks Gianfranco
Bug#825236: RFS: openfst/1.5.3-1 -- weighted finite-state transducers library
Control: tags -1 + moreinfo * Giulio Paci , 2016-05-24, 23:38: https://anonscm.debian.org/git/collab-maint/openfst.git The package FTBFS (on i386): | Making check in test | make[3]: Entering directory '/build/openfst-aOvp6g/openfst-1.5.3/src/test' | /usr/bin/make fst_test weight_test algo_test_log algo_test_tropical algo_test_minmax algo_test_lexicographic algo_test_power | make[4]: Entering directory '/build/openfst-aOvp6g/openfst-1.5.3/src/test' | g++ -DHAVE_CONFIG_H -I./../include -Wdate-time -D_FORTIFY_SOURCE=2 -g -O0 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -std=c++11 -c -o fst_test.o fst_test.cc | /bin/bash ../../libtool --tag=CXX --mode=link g++ -g -O0 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -std=c++11 -fPIE -pie -Wl,-z,relro -Wl,-z,now -o fst_test fst_test.o ../lib/libfst.la -lm -ldl | libtool: link: g++ -g -O0 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -std=c++11 -fPIE -pie -Wl,-z -Wl,relro -Wl,-z -Wl,now -o .libs/fst_test fst_test.o ../lib/.libs/libfst.so -lm -ldl | g++ -DHAVE_CONFIG_H -I./../include -Wdate-time -D_FORTIFY_SOURCE=2 -g -O0 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -std=c++11 -c -o weight_test.o weight_test.cc | /bin/bash ../../libtool --tag=CXX --mode=link g++ -g -O0 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -std=c++11 -fPIE -pie -Wl,-z,relro -Wl,-z,now -o weight_test weight_test.o ../lib/libfst.la -lm -ldl | libtool: link: g++ -g -O0 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -std=c++11 -fPIE -pie -Wl,-z -Wl,relro -Wl,-z -Wl,now -o .libs/weight_test weight_test.o ../lib/.libs/libfst.so -lm -ldl | g++ -DHAVE_CONFIG_H -DTEST_LOG -Wdate-time -D_FORTIFY_SOURCE=2 -g -O0 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -std=c++11 -c -o algo_test_log-algo_test.o `test -f 'algo_test.cc' || echo './'`algo_test.cc | In file included from algo_test.cc:6:0: | ./algo_test.h:9:24: fatal error: fst/fstlib.h: No such file or directory | compilation terminated. (I tested 1.5.3-1, but I don't see anything changed in 1.5.3+r2-1 that would fix it...) Please reduce optimization level to -O0 only on architectures where it is strictly required. Otherwise there's a risk that bugs that only trigger with optimization enabled go under our radar even on mainstream archs. I'm fine with uploading openfst to unstable. BTW, while supporting as many architectures as possible is of course a desirable goal, supporting all of them is not strictly necessary. Stretch RC policy[0] says: “Packages must autobuild without failure on all architectures on which they are supported. Packages must be supported on as many architectures as is reasonably possible. Packages are assumed to be supported on all architectures for which they have previously built successfully. Prior builds for unsupported architectures must be removed from the archive (contact -release or ftpmaster if this is the case).” Since openfst would be a new package in unstable, missing mips* builds wouldn't be release-critical or block testing migration. [0] https://release.debian.org/stretch/rc_policy.txt -- Jakub Wilk
Bug#822856: Another try for dvtm?
Hi Dmitry, due to the partial orphaning of the package in #824284, are you interested in this package, and starting to maintain it properly? I think now can can proceed with this RFS :) let me know what is your best plan, thanks Gianfranco
Bug#825237: RFS: mrpt/1:1.4.0-1 [ITA] [RC]
Dear Sean, Thank you very much for the review, indeed any help is appreciated! > You should drop the libmrpt-dbg package, since we now have automatic > *-dbgsym binary package generation. Done (upstream). I wasn't aware of this change. In the past, I provided -dbg packages with a totally different meaning (very similar to those provided by wxWidgets, if you are familiar with them): they were another version of all libraries, compiled with -g and other flags that enabled many extra run-time checks. I dropped those packages because of the (what I understood) was the preferred meaning of -dbg packages in Debian. Now that those -dbg packages have been renamed to -dbgsym, do you think it may be a good idea to generate again those debug packages? I would be really thankful for any advice regarding "good practices" in this sense... > Why have you marked this RFS as "[ITA]"? It means "intent to adopt" but > you're already the maintainer. Right, it was a mistake. > Could you explain why you changed the package priority optional->extra? I did it back in January and can't find an extended description in the commit log about *why* I did it, but it was probably because of some Lintian error/warning regarding this part of the policy (2.5 Priorities): Packages must not depend on packages with lower priority values (excluding build-time dependencies). In order to ensure this, the priorities of one or more packages may need to be adjusted. I have switched it back to "optional" upstream and will try to re-regenerate all packages and run Lintian to see if that was the reason. > Unfortunately, it fails to build on my 32-bit machine; log attached. wow, that's really unexpected! It seems there is an error in one CMake module: CMake Error at /usr/share/cmake-3.5/Modules/TestBigEndian.cmake:104 (message): TEST_BIG_ENDIAN found no result! Will investigate if it's a real problem with cmake or with my scripts. Again, thank you very much for the help. Best, Jose Luis
