Re: testing OpenSSL 1.1.0 on jessie
On 18/11/16 21:09, Kurt Roeckx wrote: > On Fri, Nov 18, 2016 at 02:22:23PM -0500, Zack Weinberg wrote: >> Daniel Pocock wrote: >>> I wanted to try compiling some upstream projects against OpenSSL 1.1.0 >>> on jessie, without installing the package though. I tried the following: >>> >>> dget -x >>> http://http.debian.net/debian/pool/main/o/openssl/openssl_1.1.0c-1.dsc >>> >>> cd openssl-1.1.0c/ >>> dpkg-buildpackage -rfakeroot -j13 >>> >>> and it builds but only 4 of the headers appear to install: >> >> Start over from scratch with -j1. Seriously. I haven't tested 1.1.0, >> but the last time I built OpenSSL its makefiles were >> _catastrophically_ broken with any amount of parallelism. You >> probably didn't even get a complete build, and the source code may >> have been damaged. > > The Makefiles were completly changed in 1.1.0 and it should > support parallel building now. > > You might want to try -J13 instead of -j13. I've never tried the > -j option. Maybe something is broken in the rules files. > > I unpacked the source package again, dropped the -j and built it like this: $ dpkg-buildpackage -rfakeroot -us -uc Now it appears all the headers are installed under debian/ and I can (try to) build stuff against it as described in my original email $ find debian/ -name '*.h' debian/libssl-dev/usr/include/openssl/aes.h debian/libssl-dev/usr/include/openssl/asn1.h debian/libssl-dev/usr/include/openssl/asn1_mac.h debian/libssl-dev/usr/include/openssl/asn1t.h debian/libssl-dev/usr/include/openssl/async.h debian/libssl-dev/usr/include/openssl/bio.h debian/libssl-dev/usr/include/openssl/blowfish.h debian/libssl-dev/usr/include/openssl/bn.h debian/libssl-dev/usr/include/openssl/buffer.h debian/libssl-dev/usr/include/openssl/camellia.h debian/libssl-dev/usr/include/openssl/cast.h debian/libssl-dev/usr/include/openssl/cmac.h debian/libssl-dev/usr/include/openssl/cms.h debian/libssl-dev/usr/include/openssl/comp.h debian/libssl-dev/usr/include/openssl/conf.h debian/libssl-dev/usr/include/openssl/conf_api.h debian/libssl-dev/usr/include/openssl/crypto.h debian/libssl-dev/usr/include/openssl/ct.h debian/libssl-dev/usr/include/openssl/des.h debian/libssl-dev/usr/include/openssl/dh.h debian/libssl-dev/usr/include/openssl/dsa.h debian/libssl-dev/usr/include/openssl/dtls1.h debian/libssl-dev/usr/include/openssl/e_os2.h debian/libssl-dev/usr/include/openssl/ebcdic.h debian/libssl-dev/usr/include/openssl/ec.h debian/libssl-dev/usr/include/openssl/ecdh.h debian/libssl-dev/usr/include/openssl/ecdsa.h debian/libssl-dev/usr/include/openssl/engine.h debian/libssl-dev/usr/include/openssl/err.h debian/libssl-dev/usr/include/openssl/evp.h debian/libssl-dev/usr/include/openssl/hmac.h debian/libssl-dev/usr/include/openssl/idea.h debian/libssl-dev/usr/include/openssl/kdf.h debian/libssl-dev/usr/include/openssl/lhash.h debian/libssl-dev/usr/include/openssl/md2.h debian/libssl-dev/usr/include/openssl/md4.h debian/libssl-dev/usr/include/openssl/md5.h debian/libssl-dev/usr/include/openssl/mdc2.h debian/libssl-dev/usr/include/openssl/modes.h debian/libssl-dev/usr/include/openssl/obj_mac.h debian/libssl-dev/usr/include/openssl/objects.h debian/libssl-dev/usr/include/openssl/ocsp.h debian/libssl-dev/usr/include/openssl/opensslv.h debian/libssl-dev/usr/include/openssl/ossl_typ.h debian/libssl-dev/usr/include/openssl/pem.h debian/libssl-dev/usr/include/openssl/pem2.h debian/libssl-dev/usr/include/openssl/pkcs12.h debian/libssl-dev/usr/include/openssl/pkcs7.h debian/libssl-dev/usr/include/openssl/rand.h debian/libssl-dev/usr/include/openssl/rc2.h debian/libssl-dev/usr/include/openssl/rc4.h debian/libssl-dev/usr/include/openssl/rc5.h debian/libssl-dev/usr/include/openssl/ripemd.h debian/libssl-dev/usr/include/openssl/rsa.h debian/libssl-dev/usr/include/openssl/safestack.h debian/libssl-dev/usr/include/openssl/seed.h debian/libssl-dev/usr/include/openssl/sha.h debian/libssl-dev/usr/include/openssl/srp.h debian/libssl-dev/usr/include/openssl/srtp.h debian/libssl-dev/usr/include/openssl/ssl.h debian/libssl-dev/usr/include/openssl/ssl2.h debian/libssl-dev/usr/include/openssl/ssl3.h debian/libssl-dev/usr/include/openssl/stack.h debian/libssl-dev/usr/include/openssl/symhacks.h debian/libssl-dev/usr/include/openssl/tls1.h debian/libssl-dev/usr/include/openssl/ts.h debian/libssl-dev/usr/include/openssl/txt_db.h debian/libssl-dev/usr/include/openssl/ui.h debian/libssl-dev/usr/include/openssl/whrlpool.h debian/libssl-dev/usr/include/openssl/x509.h debian/libssl-dev/usr/include/openssl/x509_vfy.h debian/libssl-dev/usr/include/openssl/x509v3.h debian/libssl-dev/usr/include/x86_64-linux-gnu/openssl/opensslconf.h
Bug#844986: ITP: python-jsonref -- JSON Reference implementation for Python
Package: wnpp Severity: wishlist Owner: Paolo Greppi X-Debbugs-Cc: paolo.gre...@libpf.com, debian-devel@lists.debian.org * Package name: python-jsonref Version : 0.1 Upstream Author : Chase Sterling * URL : https://github.com/gazpachoking/jsonref * License : MIT Programming Lang: Python Description : JSON Reference implementation for Python Python library for automatic dereferencing of JSON Reference object. It lets you use a data structure with JSON reference objects, as if the references had been replaced with the referent data. References are evaluated lazily. Nothing is dereferenced until it is used. Recursive references are supported, and create recursive python data structures. the interest in this is that it is required by python-ramlfications (see ITP https://bugs.debian.org/843882) which in turn is a build-dependency for buildbox 0.9.1 Ciao, Paolo signature.asc Description: OpenPGP digital signature
Bug#844985: ITP: fonts-churchslavonic -- This package provides OpenType and TrueType fonts for Church Slavonic (cu)
Package: wnpp Severity: wishlist Owner: Aleksandr Andreev * Package name: fonts-churchslavonic Version : 1.0.0 Upstream Author : Aleksandr Andreev * URL : http://sci.ponomar.net/ * License : SIL Open Font License 1.1 Programming Lang: N/A Description : Fonts for Church Slavonic language This package provides OpenType and TrueType fonts for the Church Slavonic (cu) language. Fonts use OpenType and SIL Graphite features and Unicode encoding. A sponsor is needed.
Bug#844786: ITP: snap -- The open telemetry framework
Package: wnpp Severity: wishlist Owner: matt jones * Package name: snap Version : 1.0.0 Upstream Author : Intel * URL : http://snap-telemetry.io/ * License : Apache License Version 2.0 Programming Lang: Go Description : The open telemetry framework Snap is an open telemetry framework designed to simplify the collection, processing and publishing of system data through a single API. The goals of this project are to: - Empower systems to expose a consistent set of telemetry data - Simplify telemetry ingestion across ubiquitous storage systems - Allow flexible processing of telemetry data on agent (e.g. filtering and decoration) - Provide powerful clustered control of telemetry workflows across small or large clusters I would like to bring this in Debian proper as I work full-time with various telemetry projects and would like better support for telemetry and monitoring based off of it within Debain rather than relying on external sources or builds. At some point if my time allows I would like to create a new team around monitoring telemetry to maintain this package and others that could be associated with or provide additional functionality/capability. For now I will be the maintainer of it.
Re: Bug#805116: ITP: wifi-switcher
On Sat, Nov 19, 2016 at 10:18 AM, Oleg SHALAEV wrote: > but I can not do it because I am not a Debian Developer. > Is it possible to submit the program to a Debian Developer, > or I have to register as a a Debian Developer myself? Please read this page: https://mentors.debian.net/intro-maintainers -- bye, pabs https://wiki.debian.org/PaulWise
Bug#844784: ITP: d3-format -- Formatting numbers for human consumption
Package: wnpp Severity: wishlist Owner: Ximin Luo * Package name: d3-format Version : 1.0.2 Upstream Author : 2010-2015 Mike Bostock * URL : https://github.com/d3/d3-format * License : BSD Programming Lang: JS Description : Formatting numbers for human consumption Sometimes JavaScript doesn’t display numbers the way you expect. For example, printing tenths with a naive simple loop might give you 0, 0.1, 0.2, 0.30004, 0.4, 0.5, 0.6001, 0.7001, 0.8, 0.9 - welcome to binary floating point! Yet rounding error is not the only reason to customize number formatting. A table of numbers should be formatted consistently for comparison; above, 0.0 would be better than 0. Large numbers should have grouped digits (e.g., 42,000) or be in scientific or metric notation (4.2e+4, 42k). Currencies should have fixed precision ($3.50). Reported numerical results should be rounded to significant digits (4021 becomes 4000). Number formats should appropriate to the reader’s locale (42.000,00 or 42,000.00). The list goes on. Formatting numbers for human consumption is the purpose of d3-format, which is modeled after Python 3’s format specification mini-language (PEP 3101).
Re: What to do when a maintainer is blocking maintenance for stretch?
Hello, On Fri, Nov 18, 2016 at 03:12:06PM -0500, Barry Warsaw wrote: > And please strongly consider team maintenance where available. I second the advice to strongly consider it, but it should probably be noted somewhere in this thread that team maintenance is not a panacea. While it might make it easier to get a last-minute fix uploaded, the fact that no-one feels personally responsible for a package can mean that other kinds of improvement don't get made. -- Sean Whitton signature.asc Description: PGP signature
Re: Bug#805116: ITP: wifi-switcher
In my opinion the program is ready for uploading under the GPL2, see http://chalaev.com/wifi-switcher https://github.com/chalaev/wifi-switcher https://github.com/chalaev/wifi-switcher/tree/master/current_release but I can not do it because I am not a Debian Developer. Is it possible to submit the program to a Debian Developer, or I have to register as a a Debian Developer myself? On 2015-11-16 10:06, Andrei POPESCU wrote: Control: reassign -1 wnpp Control: retitle -1 ITP: wifi-switcher -- script to automatically switch between networks ... signature.asc Description: PGP signature
Re: OpenSSL 1.1.0
On Fri, Nov 18, 2016 at 10:22:59PM +0100, Moritz Mühlenhoff wrote: > Adrian Bunk schrieb: > > And/or get sponsorship from companies for supporting ChaCha20-patched > > 1.0.2 > > It's not a matter of whipping up some patch; anything less than an > official backport of chacha20 into a 1.0.2x release is not going > to be supportable. Supporting 1.1.0 in addition to 1.0.2, including 2 years of supporting 1.1.0 after upstream support for it ended - it is confirmed that Debian is able and willing to support that. Supporting 1.0.2 only [1] plus chacha20 patched into that - it is not obvious to me why this would be that much worse in comparison that it would not be an option under any circumstances. Whether it is the best available option is a separate question. My current preference would be stretch 1.0.2-only[2], and an early buster a year later[3] if Fedora manages to make a release with 1.1 in June. With dual 1.0.2/1.1 not working in the current release schedule, what is your preferred solution? > Cheers, > Moritz cu Adrian [1] which should see a lot less code changes now that upstream is focussing on 1.1 and later [2] with or without ChaCha20 patched [3] my preference, whether the release team would agree I do not know -- "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
Re: testing OpenSSL 1.1.0 on jessie
On Fri, Nov 18, 2016 at 10:18:32PM +0100, Daniel Pocock wrote: > > > On 18/11/16 22:12, Kurt Roeckx wrote: > > On Fri, Nov 18, 2016 at 09:15:53PM +0100, Daniel Pocock wrote: > >> > >> > >> On 18/11/16 21:10, Kurt Roeckx wrote: > >>> On Fri, Nov 18, 2016 at 03:53:20PM +0100, Daniel Pocock wrote: > > > I wanted to try compiling some upstream projects against OpenSSL 1.1.0 > on jessie, without installing the package though. > > I tried the following: > > dget -x > http://http.debian.net/debian/pool/main/o/openssl/openssl_1.1.0c-1.dsc > > cd openssl-1.1.0c/ > dpkg-buildpackage -rfakeroot -j13 > > > and it builds but only 4 of the headers appear to install: > > ls debian/libssl-dev/usr/include/openssl/ > aes.h asn1.h asn1_mac.h asn1t.h > > Is this correct? > >>> > >>> No it's not. > >>> > >> > >> Could you suggest how I can get a build of OpenSSL 1.1 like this? > > > > I can't actually reproduce your poblem, it just works for me (with > > -j4, only have 4 cores.) > > > >> I don't need to build .deb files, I just need it to be within the > >> debian/ tree for me to refer to from other build trees. > > > > You could also just point to openssl-1.1.0c/include/openssl/, > > > > Please note that there is also: > > debian/libssl-dev/usr/include/x86_64-linux-gnu/openssl/opensslconf.h > > > > > > In my tree, that isn't there, this is all that I see: > > $ find debian/ -name '*.h' > debian/libssl-dev/usr/include/openssl/aes.h > debian/libssl-dev/usr/include/openssl/asn1.h > debian/libssl-dev/usr/include/openssl/asn1_mac.h > debian/libssl-dev/usr/include/openssl/asn1t.h > > > If it is working for you on jessie, maybe there is something different > in my jessie system. I have some packages from backports, could any of > those impact this build? It shouldn't. Kurt
Re: OpenSSL 1.1.0
Adrian Bunk schrieb: > And/or get sponsorship from companies for supporting ChaCha20-patched > 1.0.2 It's not a matter of whipping up some patch; anything less than an official backport of chacha20 into a 1.0.2x release is not going to be supportable. Cheers, Moritz
Re: testing OpenSSL 1.1.0 on jessie
On 18/11/16 22:12, Kurt Roeckx wrote: > On Fri, Nov 18, 2016 at 09:15:53PM +0100, Daniel Pocock wrote: >> >> >> On 18/11/16 21:10, Kurt Roeckx wrote: >>> On Fri, Nov 18, 2016 at 03:53:20PM +0100, Daniel Pocock wrote: I wanted to try compiling some upstream projects against OpenSSL 1.1.0 on jessie, without installing the package though. I tried the following: dget -x http://http.debian.net/debian/pool/main/o/openssl/openssl_1.1.0c-1.dsc cd openssl-1.1.0c/ dpkg-buildpackage -rfakeroot -j13 and it builds but only 4 of the headers appear to install: ls debian/libssl-dev/usr/include/openssl/ aes.h asn1.h asn1_mac.h asn1t.h Is this correct? >>> >>> No it's not. >>> >> >> Could you suggest how I can get a build of OpenSSL 1.1 like this? > > I can't actually reproduce your poblem, it just works for me (with > -j4, only have 4 cores.) > >> I don't need to build .deb files, I just need it to be within the >> debian/ tree for me to refer to from other build trees. > > You could also just point to openssl-1.1.0c/include/openssl/, > > Please note that there is also: > debian/libssl-dev/usr/include/x86_64-linux-gnu/openssl/opensslconf.h > > In my tree, that isn't there, this is all that I see: $ find debian/ -name '*.h' debian/libssl-dev/usr/include/openssl/aes.h debian/libssl-dev/usr/include/openssl/asn1.h debian/libssl-dev/usr/include/openssl/asn1_mac.h debian/libssl-dev/usr/include/openssl/asn1t.h If it is working for you on jessie, maybe there is something different in my jessie system. I have some packages from backports, could any of those impact this build? Regards, Daniel
Re: testing OpenSSL 1.1.0 on jessie
On Fri, Nov 18, 2016 at 09:15:53PM +0100, Daniel Pocock wrote: > > > On 18/11/16 21:10, Kurt Roeckx wrote: > > On Fri, Nov 18, 2016 at 03:53:20PM +0100, Daniel Pocock wrote: > >> > >> > >> I wanted to try compiling some upstream projects against OpenSSL 1.1.0 > >> on jessie, without installing the package though. > >> > >> I tried the following: > >> > >> dget -x > >> http://http.debian.net/debian/pool/main/o/openssl/openssl_1.1.0c-1.dsc > >> > >> cd openssl-1.1.0c/ > >> dpkg-buildpackage -rfakeroot -j13 > >> > >> > >> and it builds but only 4 of the headers appear to install: > >> > >> ls debian/libssl-dev/usr/include/openssl/ > >> aes.h asn1.h asn1_mac.h asn1t.h > >> > >> Is this correct? > > > > No it's not. > > > > Could you suggest how I can get a build of OpenSSL 1.1 like this? I can't actually reproduce your poblem, it just works for me (with -j4, only have 4 cores.) > I don't need to build .deb files, I just need it to be within the > debian/ tree for me to refer to from other build trees. You could also just point to openssl-1.1.0c/include/openssl/, Please note that there is also: debian/libssl-dev/usr/include/x86_64-linux-gnu/openssl/opensslconf.h Kurt
Re: testing OpenSSL 1.1.0 on jessie
On 18/11/16 21:10, Kurt Roeckx wrote: > On Fri, Nov 18, 2016 at 03:53:20PM +0100, Daniel Pocock wrote: >> >> >> I wanted to try compiling some upstream projects against OpenSSL 1.1.0 >> on jessie, without installing the package though. >> >> I tried the following: >> >> dget -x >> http://http.debian.net/debian/pool/main/o/openssl/openssl_1.1.0c-1.dsc >> >> cd openssl-1.1.0c/ >> dpkg-buildpackage -rfakeroot -j13 >> >> >> and it builds but only 4 of the headers appear to install: >> >> ls debian/libssl-dev/usr/include/openssl/ >> aes.h asn1.h asn1_mac.h asn1t.h >> >> Is this correct? > > No it's not. > Could you suggest how I can get a build of OpenSSL 1.1 like this? I don't need to build .deb files, I just need it to be within the debian/ tree for me to refer to from other build trees. Regards, Daniel
Re: What to do when a maintainer is blocking maintenance for stretch?
On Nov 09, 2016, at 06:45 PM, Mattia Rizzolo wrote: >Also, a personal pledge to everybody who's reading this: please don't attach >yourself to your packages like mussels on a rock. If you realize (or >somebody else is making you realize) that you're doing a bad job on a package >*and* there is a willing adopter, just give it up; or talk to the prospective >adopter about some kind of collaboration, or something on that line. And please strongly consider team maintenance where available. Cheers, -Barry pgp0Ll3xLPIZw.pgp Description: OpenPGP digital signature
Re: testing OpenSSL 1.1.0 on jessie
On Fri, Nov 18, 2016 at 03:53:20PM +0100, Daniel Pocock wrote: > > > I wanted to try compiling some upstream projects against OpenSSL 1.1.0 > on jessie, without installing the package though. > > I tried the following: > > dget -x > http://http.debian.net/debian/pool/main/o/openssl/openssl_1.1.0c-1.dsc > > cd openssl-1.1.0c/ > dpkg-buildpackage -rfakeroot -j13 > > > and it builds but only 4 of the headers appear to install: > > ls debian/libssl-dev/usr/include/openssl/ > aes.h asn1.h asn1_mac.h asn1t.h > > Is this correct? No it's not. Kurt
Re: testing OpenSSL 1.1.0 on jessie
On Fri, Nov 18, 2016 at 02:22:23PM -0500, Zack Weinberg wrote: > Daniel Pocock wrote: > > I wanted to try compiling some upstream projects against OpenSSL 1.1.0 > > on jessie, without installing the package though. I tried the following: > > > > dget -x > > http://http.debian.net/debian/pool/main/o/openssl/openssl_1.1.0c-1.dsc > > > > cd openssl-1.1.0c/ > > dpkg-buildpackage -rfakeroot -j13 > > > > and it builds but only 4 of the headers appear to install: > > Start over from scratch with -j1. Seriously. I haven't tested 1.1.0, > but the last time I built OpenSSL its makefiles were > _catastrophically_ broken with any amount of parallelism. You > probably didn't even get a complete build, and the source code may > have been damaged. The Makefiles were completly changed in 1.1.0 and it should support parallel building now. You might want to try -J13 instead of -j13. I've never tried the -j option. Maybe something is broken in the rules files. Kurt
Re: testing OpenSSL 1.1.0 on jessie
Daniel Pocock wrote: > I wanted to try compiling some upstream projects against OpenSSL 1.1.0 > on jessie, without installing the package though. I tried the following: > > dget -x http://http.debian.net/debian/pool/main/o/openssl/openssl_1.1.0c-1.dsc > > cd openssl-1.1.0c/ > dpkg-buildpackage -rfakeroot -j13 > > and it builds but only 4 of the headers appear to install: Start over from scratch with -j1. Seriously. I haven't tested 1.1.0, but the last time I built OpenSSL its makefiles were _catastrophically_ broken with any amount of parallelism. You probably didn't even get a complete build, and the source code may have been damaged. zw
Bug#844744: ITP: javacc4 -- Java Parser Generator
Package: wnpp Severity: wishlist Owner: Emmanuel Bourg * Package name: javacc4 Version : 4.0 Upstream Author : Sun Microsystems, Inc * URL : http://javacc.org * License : BSE-3-Clause Programming Lang: Java Description : Java Parser Generator Java Compiler Compiler™ (JavaCC™) is a popular parser generator for use with Java applications. A parser generator is a tool that reads a grammar specification and converts it to a Java program that can recognize matches to the grammar. In addition to the parser generator itself, JavaCC provides other standard capabilities related to parser generation such as tree building (via a tool called JJTree included with JavaCC), actions, debugging, etc. This package was forked from the javacc package. It is required for building derby which is incompatible with the more recent versions. This package will be maintained by the Java Team.
Bug#844743: ITP: python-django-allauth -- Django app that allows both local and social authentication
Package: wnpp Severity: wishlist Owner: Jan Luca Naumann * Package name: python-django-allauth Version : 0.28.0 Upstream Author : Raymond Penners and contributors * URL : http://www.intenct.nl/projects/django-allauth/ * License : MIT Programming Lang: Python Description : Django app that allows both local and social authentication Integrated set of Django applications addressing authentication, registration, account management as well as 3rd party (social) account authentication.
Bug#844738: ITP: node-fuzzaldrin-plus -- Fuzzy filtering and string scoring - compatible with fuzzaldrin
Package: wnpp Severity: wishlist Owner: Pirate Praveen X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-fuzzaldrin-plus Version : 0.3.1 Upstream Author : Jean Christophe Roy * URL : https://github.com/jeancroy/fuzzaldrin-plus * License : Expat Programming Lang: JavaScript Description : Fuzzy filtering and string scoring - compatible with fuzzaldrin signature.asc Description: OpenPGP digital signature
Bug#844737: ITP: node-grunt-contrib-coffee -- Compile CoffeeScript files to JavaScript
Package: wnpp Severity: wishlist Owner: Pirate Praveen X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-grunt-contrib-coffee Version : 1.0.0 Upstream Author : Grunt Team (http://gruntjs.com/) * URL : https://github.com/gruntjs/grunt-contrib-coffee * License : Expat Programming Lang: JavaScript Description : Compile CoffeeScript files to JavaScript signature.asc Description: OpenPGP digital signature
testing OpenSSL 1.1.0 on jessie
I wanted to try compiling some upstream projects against OpenSSL 1.1.0
on jessie, without installing the package though.
I tried the following:
dget -x
http://http.debian.net/debian/pool/main/o/openssl/openssl_1.1.0c-1.dsc
cd openssl-1.1.0c/
dpkg-buildpackage -rfakeroot -j13
and it builds but only 4 of the headers appear to install:
ls debian/libssl-dev/usr/include/openssl/
aes.h asn1.h asn1_mac.h asn1t.h
Is this correct?
I tried building another project against it by adding these to the other
project's configure:
MY_OPENSSL=${HOME}/debian/openssl-1.1.0c
CPPFLAGS="-I${MY_OPENSSL}/debian/libssl-dev/usr/include ..."
LDFLAGS="-L${MY_OPENSSL}/debian/libssl1.1/usr/lib/x86_64-linux-gnu ..."
but it failed quite badly, probably because of missing headers under
${MY_OPENSSL}/debian/libssl-dev/usr/include
Re: DEP 8: Gathering Django usage analytics
On Fri, Nov 18, 2016 at 02:00:11PM +0200, Lars Wirzenius wrote: > It's a benign acronym collision: both Debian and Django define DEP: > ours is Debian enhancement proposal, their is Django enhancement > proposal. See https://github.com/django/deps for more info. ah! thanks. -- cheers, Holger signature.asc Description: Digital signature
Re: DEP 8: Gathering Django usage analytics
On Fri, Nov 18, 2016 at 11:55:48AM +, Holger Levsen wrote: > I fail to see the relation to http://dep.debian.net/deps/dep8/ - can you > explain? It's a benign acronym collision: both Debian and Django define DEP: ours is Debian enhancement proposal, their is Django enhancement proposal. See https://github.com/django/deps for more info. -- I want to build worthwhile things that might last. --joeyh signature.asc Description: PGP signature
Re: DEP 8: Gathering Django usage analytics
On Mon, Nov 07, 2016 at 06:05:18PM +1100, Brian May wrote: > Hello, > > I raised this issue on the debian-python mailing list, however it probably > deserves wider attention. > > https://lists.debian.org/debian-python/2016/11/msg00025.html > > Regards > > Original Message > > I think upstream Django have requested our feedback on this pull request: > > https://github.com/django/deps/pull/31 > > Should I ask on debian-devel? I fail to see the relation to http://dep.debian.net/deps/dep8/ - can you explain? -- cheers, Holger signature.asc Description: Digital signature
Bug#844713: ITP: partman-swapfile -- add support for creating swapfiles
Package: wnpp Owner: Dimitri John Ledkov Severity: wishlist * Package name: partman-swapfile Version : 1 Upstream Author : d-i team * URL or Web page : d-i * License : GPL Description : add support for creating swapfiles I am working on minimising number of partitions used in the default instalations in Ubuntu. One of the things I have done already in Ubuntu is to tweak and not use dedicated /boot partition for non-encrypted LVM based installations. Simply by tweaking the partman-auto recipes, on architectures/bootloaders that support booting off LVM. Another thing I am investigating is moving away from swap partitions to swap files, on non-lvm installations. This will involve tweaking the default partman-auto recipes & the no-swap warning. However, to provide swapfiles out of the box I wrote this partman-swapfile module which hooks into /lib/partman/finish.d to create /target/swapfile with an appropriate stanza in /target/etc/fstab. Care is taken not to create swapfiles uncessory, reuse existing one, or do nothing if a swap partition is already present, or swapfiles not supported on a given filesystem (e.g. btrfs). There are two control options to configure the size of the swapfile. Absolute size, and percentage of free space on the rootfs. The defaults are 2GB and 5%, meaning the swapfile will be 2GB in size or 5% of the free space on rootfs, whichever is lower. Setting the size or percentage to zero will skip creating the swapfile. This is a strategy to make sure there is some swap available, without wasting too much of disk space on high-memory-to-disk ratio systems (e.g. 1TB of RAM with a 200GB hard drive). I am not at all sure if this functionality is at all welcomed, needed, or will generate any interest. I do not know if it's wanted to be available by default in Debian's d-i. At the moment I created a git repository in the d-i team, and plan to upload this to experimental for people to try this out. On the implementation side, swapfile is allocated using fallocate (if avaialble and target filesystem creates files without holes using fallocate) otherwise "slow" dd is used. This makes swapfile creation really quick on ext4 rootfs. All the glory details are here: https://anonscm.debian.org/cgit/d-i/partman-swapfile.git/tree/finish.d Regards, Dimitri.
Re: DEP 8: Gathering Django usage analytics
On Fri, Nov 18, 2016 at 08:54:08AM +1100, Brian May wrote: > Lars Wirzenius writes: > > > If I understand this correctly, Django wants to gather usage > > statistics from installed Django instances, in a way that they say > > respects user privacy (though I failed to understand how, given a > > quick read). They claim this information gathering is necessary for > > them to sustainably get funding for Django development. > > ... there was a response to this email here: > https://github.com/django/deps/pull/31#issuecomment-261181821 > > Probably better to followup on this pull request as opposed to here, > where upstream will read it. > -- > Brian May > I've answered to the thread with my views, copy here for convenience: Hi aaugustin, The first response (https://lists.debian.org/debian-devel/2016/11/msg00253.html) misunderstands the proposal widely (or trolls naively, but I'll assume good faith). SInce I'm not subscribed to the mailing-lists I'll reply here instead. Even if I subscribe now I won't get earlier mail so I won't be able to answer in the thread. You can still answer to the thread. Just add the Message-Id as In-Reply-To Header to your mail. (http://webapps.stackexchange.com/questions/23197/reply-to-mailman-archived-message) You'll get probably a better discussion if you do.. The scheme proposed here specifically excludes "installed Django instances". It only targets development setups. This might be a misconception by Lars*, but actually the fact if it is prodution or development does not make a difference. Also devs have a right for privacy. Metrics don't carry any information about which site is being developed. It can't reveal the "a site uses any particular software". There are privacy considerations -- especially around IP addresses, which might reveal which organization the metrics emanate from -- but they're discussed above and the response doesn't build upon that discussion. IPs can be used to track back to people / organizations. That is not so hard. Also the other data, like OS version, django version, python version is sensible information as it reveals that some user has some software with a specific version installed. Let me sidestep here a bit about the Debian Free Software Guidelines [dsfg]. Those guildines must be kept by any software inlcuded to Debian (main). They come along to the defintion of open source but it is considered also important by the project that e.g also privacy is respected. To aid people assessing if a software is complying with the guidelines, a few tests have been developed [dfsg-faq, §9]. While mostly hypothetical, they come to the core and show certain deficits in e.g licenses. It is considered that only licenses passing this tests are (DFSG) free. The test which applies here is the "Dissident Test", let me briefly quote here: _The Dissident test. Consider a dissident in a totalitarian state who wishes to share a modified bit of software with fellow dissidents, but does not wish to reveal the identity of the modifier, or directly reveal the modifications themselves, or even possession of the program, to the government. Any requirement for sending source modifications to anyone other than the recipient of the modified binary---in fact any forced distribution at all, beyond giving source to those who receive a copy of the binary---would put the dissident in danger. For Debian to consider software free it must not require any such "excess" distribution._ Of course, we're not talking about a licensing issue here, but the DFSG presents quite well the spirit of the project and so can be transfered to the topic at hand: It will not be acceptable for Debian to have a by-default-on phone-home functionality. Another data point here are the different lintian errors connected to privacy-breach: lintian-tags, search for "privacy-". Errors are the most severy category emitted by the lintian tool. The author goes on to say the proposal would be acceptable if: "it's opt-in by sysadmins installing Django": I proposed to make it opt-in by requiring explicit confirmation (which may or may not be reflected in the DEP); since sysadmins typically don't run startproject, startapp or runserver, that situation seems highly theoretical anyway "also each user using a site built on top of Django whose use is going to be reported": apparently the author didn't read why we aren't planning to do things like version checks from the admin (or they're just attempting to set an impossibly high bar to kill the proposal, in which case, they picked the wrong bar) I'm pretty sure that you have honest intention and it is only for the best of Django, but for Debian's spirit is not an important detail who runs the commands or what are the reasons are behind. The fact of phoning home is and (when done without explicit consent from the user) deemed inacceptable. To sum up, it appears that @jacobian correctly anticipated the criticism that metrics may draw
Re: DEP 8: Gathering Django usage analytics
Hi, On Fri, 18 Nov 2016, Lars Wirzenius wrote: > I'd rather not debate this on github. It's a proprietary system, and > effectively a web forum I'd need to keep polling to see if there's You get mail notifications on GitHub too. > responses. Further, that response paints me either as someone who's > misunderstood what they want to do, or a troll. If that's how I'm > going to be painted for disagreeing with them, then I don't want to > talk to them. It's probably true that I have misunderstood the details > of their proposals (I did find them written in a way that's confusing > to me), but the details probably don't matter much: if you software I don't agree, details do matter. And if you effectively want to contribute to the discussion, then you should take the time to understand what's proposed and figure out with them what's acceptable and what's not. The discussion has been rather long already, so yes it takes time. I'm not asking you to do that, I already did it as package co-maintainer. But don't be surprised if you're classified as someone not constructive if you only assert high-level principles without discussing the details. > reports on your users (and that includes developers), and the users do > no opt in to that, you're violating people'e privacy and you shouldn't > do that. If it's software packaged for Debian, the Debian package > maintainer should patch it out. I clearly expressed this to upstream already. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Re: DEP 8: Gathering Django usage analytics
On Fri, Nov 18, 2016 at 08:54:08AM +1100, Brian May wrote: > Lars Wirzenius writes: > > > If I understand this correctly, Django wants to gather usage > > statistics from installed Django instances, in a way that they say > > respects user privacy (though I failed to understand how, given a > > quick read). They claim this information gathering is necessary for > > them to sustainably get funding for Django development. > > ... there was a response to this email here: > https://github.com/django/deps/pull/31#issuecomment-261181821 > > Probably better to followup on this pull request as opposed to here, > where upstream will read it. I'd rather not debate this on github. It's a proprietary system, and effectively a web forum I'd need to keep polling to see if there's responses. Further, that response paints me either as someone who's misunderstood what they want to do, or a troll. If that's how I'm going to be painted for disagreeing with them, then I don't want to talk to them. It's probably true that I have misunderstood the details of their proposals (I did find them written in a way that's confusing to me), but the details probably don't matter much: if you software reports on your users (and that includes developers), and the users do no opt in to that, you're violating people'e privacy and you shouldn't do that. If it's software packaged for Debian, the Debian package maintainer should patch it out. -- I want to build worthwhile things that might last. --joeyh signature.asc Description: PGP signature
