Bug#858531: RFS: delight/1.5-1 ITP
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "delight" * Package name : delight Version : 1.5-1 Upstream Author : Phil Sainty * Url : https://savannah.nongnu.org/projects/delight * Licenses : GPL-3+ Programming Lang : Emacs Lisp Section : lisp Emacs add-on 'delight' provides functionality to customise the mode names displayed in the mode line. . For major modes, the buffer-local `mode-name' variable is modified. For minor modes, the associated value in `minor-mode-alist' is set. It builds those binary packages: * elpa-delight To access further information about this package, visit the following URL: https://mentors.debian.net/package/delight Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/d/delight/delight_1.5-1.dsc Alternatively, you can access package debian/ directory via git from URL: https://anonscm.debian.org/git/pkg-emacsen/pkg/delight.git More information about delight can be obtained from https://savannah.nongnu.org/projects/delight Regards, Dmitry Bogatov
Re: arpwatch & systemd
Hello, >since I'm using arpwatch and it has been orphaned for a while now, I am >thinking about adopting this package. I've started picking a few >easy enough bugs in the BTS and fixed them. Before I'm ready to >officially declare my intent I wanted some advice in particular on >supplying systemd unit files for this package (other feedback is >welcome as well of course). > >The current LSB init script checks /etc/arpwatch.conf for lines >matching '^[a-z]'. > >* If there are any, it uses a multi instance mode using information > from this configuration file to add additional parameters (in > addition to what is read from /etc/default/arpwatch) as command > arguments (which may be different for the interfaces) >* If there are no such lines, it will just use the parameters > from /etc/default/arpwatch to start one instance of arpwatch. > >Note that /etc/arpwatch.conf is not a "usual" configuration file in that >it is never read by arpwatch but only by the init system to construct >the arguments to be passed to arpwatch when executing. > >Thoughts on about how to provide a systemd unit file (inspired a lot by >how openvpn handles multiple instances): >* I want the processes for different interfaces supervised individually > by systemd; the only way how to do this I know about is to supply > a template unit file (arpwatch@.service) which can be > instanciated with an instance name (which will in my case be an > interface name). > >* I want to keep supporting different parameters for the different > instances; the easiest way to support this seems to be using the > EnvironmentFile directive, with allows to use the contents of the > variables when invoking arpwatch; however, this means I need a > separate configuration file for each interface. >* I do not consider starting arpwatch without the `-i` parameter to > specify an interface useful (it uses pcap_lookupdev in that case, > which allows you to find "the default" device on which to capture, > for whatever that means). I think that people running arpwatch > should have an opinion on which network interface arpwatch should run > on. >So what I have done is: >* I've dropped the "one instance" mode as I always want to have the > interface(s) specified, even if it's only one. >* I've converted /etc/arpwatch.conf to individual configuration files > in /etc/arpwatch/IFNAME.iface which have a shell source-able syntax > (I've adjusted the LSB init script accordingly) and can be used with > systemd's EnvironmentFile= directive. >* Consequently there is no /etc/arpwatch.conf any more, I removed it. >* As I don't know which interface the admin is going to use, I cannot > provide a "default" configuration file with helpful comments. As a > current workaround I have created an /etc/arpwatch/README file which > briefly explains the interface configuration. >* I've added an INTERFACES= variable to /etc/default/arpwatch: > - This allows specifying which interfaces to run on, but is only used >by the LSB init script and ignored by systemd. > - For systemd I expect the administrators to explicitly enable and >start the instantiated unit files using systemctl; alternatively >we could write a generator for systemd, similar to what openvpn >does, to activate all the instances specified in INTERFACES. > >I would like advice on the concept itself: Is it ok or should a take a >different approach? Can someone point me to a package that handles a >similar service startup situation differently (better)? > O>her than that I'm quite concerned about the upgrade path: >* I do remove /etc/arpwatch.conf from the package (but this will of > course stay in the filesystem); converting this into individual files > in /etc/arpwatch/IFNAME.iface in a maintainer script would be > possible… >* I have a README file in /etc/arpwatch/ which is not a configuration > file. Is there a better solution and, if not, would this be > acceptable? >* After the upgrade, the service has to be explicitly activated for the > interfaces it should be started on, even if the service was > previously running (again, could be handled in a maintainer script > at least for some cases, but is not easy to do considering how the > different init systems need a different form of activation) >* In any case I do not think that we can offer a seamless upgrade path > for all cases. > >Sorry for the wall of text. You can find the current status in the >following git repository in the *staged-changes* branch (this is >work-in-progress and will see force commits): >https://git.somlen.de/arpwatch.git before having a deep look (and I won't until you request an RFS sponsorship, I have a question: did you consider to merge the work from Fedora? they already have a systemd service, and IIRC the project seems somewhat dead upstream, so merging their work and sending them patches might be beneficial for both distros. Please try to have a similar working tool, rather than diverging t
Bug#858476: RFS: wolfssl/3.10.2+dfsg-1 [RC] -- wolfSSL encryption library
Well, the security issue is probably worth fixing, but it may not make sense to ship the library in stretch. No other official packages depend on it. On Wed, Mar 22, 2017 at 12:28 PM, Andrey Rahmatullin wrote: > On Wed, Mar 22, 2017 at 12:15:49PM -0700, Felix Lechner wrote: > > Changes since the last upload: > > > > * New upstream release. > > * New major version is 10 > > * New maintainer email address > > * Fixes a low level vulnerability for buffer overflow when loading a > > malformed temporary DH file > > * Fixes a medium level vulnerability for processing of OCSP response > > * Fixes CVE-2017-6076, a low level vulnerability for a potential cache > attack > > on RSA operations (Closes: #856114) > According to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=856114#20 > this is not intended to be fixed in testing, is that correct? > > -- > WBR, wRAR >
Re: arpwatch & systemd
❦ 22 mars 2017 20:08 +0100, Lukas Schwaighofer : > I would like advice on the concept itself: Is it ok or should a take a > different approach? Can someone point me to a package that handles a > similar service startup situation differently (better)? It seems a good plan. > Other than that I'm quite concerned about the upgrade path: > * I do remove /etc/arpwatch.conf from the package (but this will of > course stay in the filesystem); converting this into individual files > in /etc/arpwatch/IFNAME.iface in a maintainer script would be > possible… You can use dpkg-maintscript-helper rm_conffile which does the right thing when removing a file. I wouldn't bother converting the current configuration. Explain the situation in NEWS.Debian. > * I have a README file in /etc/arpwatch/ which is not a configuration > file. Is there a better solution and, if not, would this be > acceptable? This is acceptable. Lots of packages do that. > * After the upgrade, the service has to be explicitly activated for the > interfaces it should be started on, even if the service was > previously running (again, could be handled in a maintainer script > at least for some cases, but is not easy to do considering how the > different init systems need a different form of activation) Same, let the user handles that. -- He that breaks a thing to find out what it is has left the path of wisdom. -- J.R.R. Tolkien signature.asc Description: PGP signature
Bug#858476: RFS: wolfssl/3.10.2+dfsg-1 [RC] -- wolfSSL encryption library
On Wed, Mar 22, 2017 at 12:15:49PM -0700, Felix Lechner wrote: > Changes since the last upload: > > * New upstream release. > * New major version is 10 > * New maintainer email address > * Fixes a low level vulnerability for buffer overflow when loading a > malformed temporary DH file > * Fixes a medium level vulnerability for processing of OCSP response > * Fixes CVE-2017-6076, a low level vulnerability for a potential cache > attack > on RSA operations (Closes: #856114) According to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=856114#20 this is not intended to be fixed in testing, is that correct? -- WBR, wRAR signature.asc Description: PGP signature
arpwatch & systemd
Hi mentors, [I'm on list] since I'm using arpwatch and it has been orphaned for a while now, I am thinking about adopting this package. I've started picking a few easy enough bugs in the BTS and fixed them. Before I'm ready to officially declare my intent I wanted some advice in particular on supplying systemd unit files for this package (other feedback is welcome as well of course). The current LSB init script checks /etc/arpwatch.conf for lines matching '^[a-z]'. * If there are any, it uses a multi instance mode using information from this configuration file to add additional parameters (in addition to what is read from /etc/default/arpwatch) as command arguments (which may be different for the interfaces) * If there are no such lines, it will just use the parameters from /etc/default/arpwatch to start one instance of arpwatch. Note that /etc/arpwatch.conf is not a "usual" configuration file in that it is never read by arpwatch but only by the init system to construct the arguments to be passed to arpwatch when executing. Thoughts on about how to provide a systemd unit file (inspired a lot by how openvpn handles multiple instances): * I want the processes for different interfaces supervised individually by systemd; the only way how to do this I know about is to supply a template unit file (arpwatch@.service) which can be instanciated with an instance name (which will in my case be an interface name). * I want to keep supporting different parameters for the different instances; the easiest way to support this seems to be using the EnvironmentFile directive, with allows to use the contents of the variables when invoking arpwatch; however, this means I need a separate configuration file for each interface. * I do not consider starting arpwatch without the `-i` parameter to specify an interface useful (it uses pcap_lookupdev in that case, which allows you to find "the default" device on which to capture, for whatever that means). I think that people running arpwatch should have an opinion on which network interface arpwatch should run on. So what I have done is: * I've dropped the "one instance" mode as I always want to have the interface(s) specified, even if it's only one. * I've converted /etc/arpwatch.conf to individual configuration files in /etc/arpwatch/IFNAME.iface which have a shell source-able syntax (I've adjusted the LSB init script accordingly) and can be used with systemd's EnvironmentFile= directive. * Consequently there is no /etc/arpwatch.conf any more, I removed it. * As I don't know which interface the admin is going to use, I cannot provide a "default" configuration file with helpful comments. As a current workaround I have created an /etc/arpwatch/README file which briefly explains the interface configuration. * I've added an INTERFACES= variable to /etc/default/arpwatch: - This allows specifying which interfaces to run on, but is only used by the LSB init script and ignored by systemd. - For systemd I expect the administrators to explicitly enable and start the instantiated unit files using systemctl; alternatively we could write a generator for systemd, similar to what openvpn does, to activate all the instances specified in INTERFACES. I would like advice on the concept itself: Is it ok or should a take a different approach? Can someone point me to a package that handles a similar service startup situation differently (better)? Other than that I'm quite concerned about the upgrade path: * I do remove /etc/arpwatch.conf from the package (but this will of course stay in the filesystem); converting this into individual files in /etc/arpwatch/IFNAME.iface in a maintainer script would be possible… * I have a README file in /etc/arpwatch/ which is not a configuration file. Is there a better solution and, if not, would this be acceptable? * After the upgrade, the service has to be explicitly activated for the interfaces it should be started on, even if the service was previously running (again, could be handled in a maintainer script at least for some cases, but is not easy to do considering how the different init systems need a different form of activation) * In any case I do not think that we can offer a seamless upgrade path for all cases. Sorry for the wall of text. You can find the current status in the following git repository in the *staged-changes* branch (this is work-in-progress and will see force commits): https://git.somlen.de/arpwatch.git Thank you Lukas Schwaighofer pgpnkBKMlxwpQ.pgp Description: OpenPGP digital signature
Bug#858476: RFS: wolfssl/3.10.2+dfsg-1 [RC] -- wolfSSL encryption library
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "wolfssl": * Package name: wolfssl Version : 3.10.2+dfsg-1 Upstream Author : wolfSSL Inc. * URL : www.wolfssl.com * License : various Section : libs It builds those binary packages: libwolfssl10 - wolfSSL encryption library libwolfssl-dev - Development files for the wolfSSL encryption library To access further information about this package, please visit the following URL: https://mentors.debian.net/package/wolfssl Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/w/wolfssl/wolfssl_3.10.2+dfsg-1.dsc More information about wolfSSL can be obtained from https://www.wolfssl.com. Changes since the last upload: * New upstream release. * New major version is 10 * New maintainer email address * Fixes a low level vulnerability for buffer overflow when loading a malformed temporary DH file * Fixes a medium level vulnerability for processing of OCSP response * Fixes CVE-2017-6076, a low level vulnerability for a potential cache attack on RSA operations (Closes: #856114) Best regards, Felix Lechner -- System Information: Debian Release: 9.0 APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system)
Bug#858454: RFS: simple-obfs/0.0.3-1~exp1 [ITP] -- simple obfusacting plugin for shadowsocks server
Package: sponsorship-requests Severity: wishlist X-Debbugs-Cc: max.c...@gmail.com, rogershim...@gmail.com Dear mentors, I am looking for a sponsor for my package "simple-obfs", which is a new dependency of shadowsocks-libev since v3.0.3 * Package name: simple-obfs Version : 0.0.3-1~exp1 Upstream Author : Max Lv * URL : https://github.com/shadowsocks/simple-obfs * License : GPL-3+ Section : net It builds those binary packages: simple-obfs - simple obfusacting plugin for shadowsocks server To access further information about this package, please visit the following URL: https://mentors.debian.net/package/simple-obfs Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/s/simple-obfs/simple-obfs_0.0.3-1~exp1.dsc or you can use git-buildpackage to build: gbp clone --pristine-tar https://github.com/rogers0/simple-obfs.git cd simple-obfs git checkout mentors mk-build-deps --root-cmd sudo --install --tool "apt-get -o Debug::pkgProblemResolver=yes --no-install-recommends" gbp buildpackage -uc -us --git-ignore-branch --git-pristine-tar I also built this package on debomatic (amd64): http://debomatic-amd64.debian.net/distribution#experimental/simple-obfs/0.0.3-1~exp1/buildlog [changelog] simple-obfs (0.0.3-1~exp1) experimental; urgency=low * Initial release. (Closes: #858370) Thanks advance for your review and upload! Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1 pgpiEAXknd3MC.pgp Description: PGP signature
