Re: dh: default cmake options overridden
Ubuntu has some of its security flags enabled by default in the compiler itself, so explicit hardening CFLAGS are unnecessary (but harmless): https://wiki.ubuntu.com/Security/Features To check that this has worked, you can use https://wiki.debian.org/Hardening#Validation However, that's the case in both 12.04 and 14.04, and dpkg-buildflags still includes them: trusty$ dpkg-buildflags CFLAGS=-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security CPPFLAGS=-D_FORTIFY_SOURCE=2 CXXFLAGS=-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security FFLAGS=-g -O2 -fstack-protector --param=ssp-buffer-size=4 GCJFLAGS=-g -O2 -fstack-protector --param=ssp-buffer-size=4 LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53995be7.3000...@bham.ac.uk
Re: Python 3 only package
On Jun 11, 2014, at 10:03 PM, Ross Gammon wrote:
A supplementary question - do I need to name the package python3-foo
if a python 2 version is not being provided any more? Or will python-foo
do? Previous versions were just foo and being dealt with by
Conflicts/Replaces.
This could be your problem. Indeed, you currently need to name your binary
package python3-foo in order for pybuild do DTRT with Python 3-only packages.
You'll often see this with Python 3-only applications, as opposed to
libraries, which should always be named python-foo (Python 2) or python3-foo
(Python 3). I recently saw this with the latest python-virtualenv package.
I know that Piotr (pybuild's author) was talking about also respecting
${python3:Depends} as a signal to kick in Python 3 build, but I don't think
that's landed yet.
So, if your package is a Python library, call it python3-foo for now. If it's
an application and you don't want to use the `python3-` prefix, it's still a
good idea to set the build system to pybuild, but you'll need to do more of
the work manually, at least until the above change lands.
debian-python@ and #debian-python might be better places to get more focused
help. If you have a vcs branch, please post it and we might be able to help.
Cheers,
-Barry
signature.asc
Description: PGP signature
Re: Python 3 only package
On 06/12/2014 03:44 PM, Barry Warsaw wrote:
On Jun 11, 2014, at 10:03 PM, Ross Gammon wrote:
A supplementary question - do I need to name the package
python3-foo if a python 2 version is not being provided any
more? Or will python-foo do? Previous versions were just foo
and being dealt with by Conflicts/Replaces.
This could be your problem. Indeed, you currently need to name
your binary package python3-foo in order for pybuild do DTRT with
Python 3-only packages. You'll often see this with Python 3-only
applications, as opposed to libraries, which should always be named
python-foo (Python 2) or python3-foo (Python 3). I recently saw
this with the latest python-virtualenv package.
Thanks Barry - that answers the question about naming the package and
why I need to call them python3-*.
Unfortunately, I have used python3-* names so it still doesn't explain
why the build fails.
I know that Piotr (pybuild's author) was talking about also
respecting ${python3:Depends} as a signal to kick in Python 3
build, but I don't think that's landed yet.
So, if your package is a Python library, call it python3-foo for
now. If it's an application and you don't want to use the
`python3-` prefix, it's still a good idea to set the build system
to pybuild, but you'll need to do more of the work manually, at
least until the above change lands.
It is an application, but I am splitting it up into a gui app and a
webapp (django based) that depend on a core library. It sounds like
python3-* and pybuild are the right options - I try and avoid manual
work when I can :-)
debian-python@ and #debian-python might be better places to get
more focused help. If you have a vcs branch, please post it and we
might be able to help.
It is in a local git branch, so I will do a few more experiments, tidy
up, push it and take it to the python list. After I get the python 3
bit working, I still anticipate a couple of bumps along the way to a
working django app anyway!
Cheers, -Barry
Thanks again,
Ross
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/539a00f8.2030...@the-gammons.net
Bug#751438: RFS: pantomime/1.2.2~r289+dfsg-1 [RC]
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package pantomime. It builds these binary packages: libpantomime1.2 - GNUstep framework for mail handling (runtime library) libpantomime1.2-dev - GNUstep framework for mail handling (development files) To access further information about this package, please visit the following URL: http://mentors.debian.net/package/pantomime Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/p/pantomime/pantomime_1.2.2~r289+dfsg-1.dsc Changes since the last upload: * New upstream release: - Fixes a crash in CWService when self gets deallocated while reading/writing data (Closes: #750217). * debian/watch: Replace stub with a working one. * debian/repack: New script to repack the upstream tarball. * debian/source/format: Switch to 3.0 (quilt). * debian/README.source: Delete. * debian/control: Rename the package back to `pantomime'. (Build-Depends): Remove quilt. (Homepage): Remove, new upstream maintainer but no homepage yet. (Vcs-Git, Vcs-Browser): Use canonical URIs. (Standards-Version): Bump to 3.9.5; no changes needed. * debian/rules: Don't include patchsys-quilt.mk. (LDFLAGS): Define with `+=' to get the value from dpkg-buildflags. (DEB_MAKE_INVOKE): Add OBJCFLAGS. * debian/patches/compilation-errors.patch: Remove; fixed upstream. * debian/patches/compilation-warnings.patch: Remove hunks applied upstream, fix more issues (Closes: #749762). * debian/patches/check-return-result.patch: New; check the return result of some functions and provide better logging (Closes: #461453). * debian/patches/series: Update. * debian/copyright: Switch to format 1.0, update copyright years/holders. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87r42tkg4r@yavor.doganov.org
Re: Python 3 only package
On 06/11/2014 10:03 PM, Ross Gammon wrote: Hi, I am getting a build failure when trying to build a Python 3 only package following the guidance in the Python Library Style Guide: https://wiki.debian.org/Python/LibraryStyleGuide This is the error message: E: pybuild pybuild:256: build: plugin distutils failed with: exit code=1: /usr/bin/python3 setup.py build The plugin distutils failed bit in the error message rings an alarm when I read the following in the style guide: Note: If you are building a Python 3-only package (i.e. there's no Python 2 support) then it is highly recommended you explicitly set the dh build system to pybuild. By default, if there is a setup.py, dh will set the build system to python_distutils which only supports Python 2 and you'll get errors during package build as it tries to invoke some nonexistent Python 2 tools. Okay - this was nothing to do with python. A previous merge error had given me a corrupt file. Copying some lines from above the build error into my first email might have given you a chance to spot my error! Sorry about the noise. Ross -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/539a2446.80...@the-gammons.net
Bug#748870: marked as done (RFS: libr3/1.3.1-1 [ITP] -- high-performance URL router library)
Your message dated Fri, 13 Jun 2014 04:23:37 + with message-id e1wvj1d-0004yh...@quantz.debian.org and subject line closing RFS: libr3/1.3.1-1 [ITP] -- high-performance URL router library has caused the Debian Bug report #748870, regarding RFS: libr3/1.3.1-1 [ITP] -- high-performance URL router library 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.) -- 748870: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748870 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package libr3: * Package name: libr3 Version : 1.0.0 Upstream Author : Yo-An Lin yoanli...@gmail.com * URL : https://github.com/c9s/r3 * License : MIT Section : libs It builds those binary packages: libr3-0: High-performance URL router library libr3-dbg: High-performance URL router library (debug symbols) libr3-dev: High-performance URL router library (development files) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/libr3 Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/libr/libr3/libr3_1.0.0-1.dsc -- ChangZhuo Chen (陳昌倬) czc...@gmail.com http://czchen.info/ Key fingerprint = EC9F 905D 866D BE46 A896 C827 BE0C 9242 03F4 552D signature.asc Description: Digital signature ---End Message--- ---BeginMessage--- Package libr3 version 1.3.1-1 is in NEW now, and the package at mentors is not newer (2014-06-12) than the package in NEW (2014-06-12), so there is currently no package to sponsor. http://ftp-master.debian.org/new/libr3_1.3.1-1.html http://mentors.debian.net/package/libr3 Please remove the package from mentors or mark it needs sponsor = no. If for some reason you need to replace the package in NEW, then you can upload an updated package to mentors and feel free to reopen this RFS 748870 or open a new RFS.---End Message---
