Hi,
Am Mittwoch, den 06.02.2013, 16:31 -0800 schrieb Russ Allbery:
> Normal
> versioning problems that we just take for granted in C, such as allowing
> the coexistence of two versions of the same library with different ABIs on
> the system at the same time without doing the equivalent of static
>
On Thu, Feb 07, 2013 at 10:28:28AM +1100, Russell Coker wrote:
> Such capabilities allow the process to bind to all low ports, which usually
> isn't what you desire. If you want to permit a daemon to bind to exactly one
> reserved port and no others then it seems that the options are systemd (if
* Hilko Bengen:
> I drew a different conclusion from Ian's messages the thread you
> mentioned (see the quotes below). Apparently, one *can* build shared
> libraries using gccgo, but they are not currently usable using dlopen().
> My impression was that this means that regular use of shared librar
On 07/02/13 09:39, Philipp Kern wrote:
>> If you want to permit a daemon to bind to exactly one reserved
>> port and no others then it seems that the options are systemd (if
>> the daemon supports socket based activation) and SE Linux.
>
> (x)inetd, no?
For completeness: the systemd socket-activa
* Thomas Goirand:
> Which would be the wrong way of doing things / wrong reason
> for using root as running user, since you can set the
> CAP_NET_BIND_SERVICE capability... (man capabilities ...)
This allows to bind to all lower ports, which in some cases is
equivalent to root privileges. A more
On Thursday 07 February 2013 10.39.59 Philipp Kern wrote:
> On Thu, Feb 07, 2013 at 10:28:28AM +1100, Russell Coker wrote:
> > Such capabilities allow the process to bind to all low ports, which
> > usually isn't what you desire. If you want to permit a daemon to bind
> > to exactly one reserved p
On Thu, 7 Feb 2013, Salvo Tomaselli wrote:
Yes but the xinetd process keeps the socket open, then on new connection forks
and gives the service the fd of the new connection, retaining the fd for the
listener part.
Which means that on every connection it has to fork (and that's extremely
slow).
On Wed, Feb 06, 2013 at 04:31:55PM -0800, Russ Allbery wrote:
> I keep being tempted to go off on a rant about how we have all of these
> modern, sophisticated, much more expressive programming languages, and yet
> still none of them handle ABI versioning as well as C does. Normal
> versioning pro
On Thu, Feb 07, 2013 at 08:54:32AM +0800, Paul Wise wrote:
> Why did Debian have to invent /usr/share/pyshared and symlink farms in
> /usr/lib/pythonX.Y instead of upstream having something like that in
> the default install and search paths?
This is all resolved now in python3. There is no more
Package: wnpp
Severity: wishlist
Owner: rm
* Package name: qtweetlib
Version : 1.0.0
Upstream Author : Jonas Erlandsson
* URL : https://github.com/minimoog/QTweetLib.git
* License : LGPL
Programming Lang: C++, QT
Description: qtweetlib
- Supports only XAu
Package: wnpp
Severity: wishlist
Owner: rm
* Package name: libjreen
Version : 1.1.1
Upstream Author : Jonas Erlandsson
* URL : http://qutim.org/jreen/
* License : GPL2
Programming Lang: C++/QT
Description : A powerful Jabber/XMPP library implemented in
* Steve Langasek:
> Actually, if you look closely, you'll find that the traditional Java
> .jar linking resolver precisely mirrors the behavior of the C linker
> on Solaris from the same era (allows you to link dynamically, but
> requires top-level objects to be linked at build time with all the
>
The Built-Using field required[1] by recent policy results in some
problems for maintainers:
1. It needs to indicate the exact version of the source package used in
the build. So this has to be kept up-to-date, or dynamically
generated. Updating it manually is busywork and won't reflect
v
I notice some upstreams hack NDEBUG into their Makefile, while others
leave it at the discretion of the user
Is there any distribution policy for this? Should I be adding something
into debian/rules to set -DNDEBUG when I prepare a package for release?
--
To UNSUBSCRIBE, email to debian-deve
Package: wnpp
Severity: wishlist
Owner: Maximiliano Curia
* Package name: bbswitch-dkms
Version : 0.5-1
Upstream Author : Peter Lekensteyn
* URL : https://github.com/Bumblebee-Project/bbswitch
* License : GPL
Programming Lang: C
Description : Kernel mo
Russ Allbery writes:
> I keep being tempted to go off on a rant about how we have all of
> these modern, sophisticated, much more expressive programming
> languages, and yet still none of them handle ABI versioning as well as
> C does. Normal versioning problems that we just take for granted in C
On Thu 07 Feb 2013 14:02:53 rm escribió:
> Package: wnpp
> Severity: wishlist
> Owner: rm
>
> * Package name: libjreen
> Version : 1.1.1
> Upstream Author : Jonas Erlandsson
> * URL : http://qutim.org/jreen/
> * License : GPL2
> Programming Lang: C++/QT
>
Joey Hess writes:
> We can take advantage of the architecture specification in Build-Depends
> being fairly wide-open. So this should not break existing parsers:
>
> Build-Depends: foo [any built-using], bar [i386 amd64 built-using]
[...]
>
> Alternatively, a package named built-using could be upl
Le Thu, Feb 07, 2013 at 03:09:07PM -0400, Joey Hess a écrit :
> The Built-Using field required[1] by recent policy results in some
> problems for maintainers:
> [1] Or at least encouraged, depending on how policy and the intent of
> policy is interpreted.
Hi Joey,
in section 5.3, that lists
On Thu, 7 Feb 2013 20:16:18 +
Matthew Woodcraft wrote:
> I don't think it's as clear-cut as that.
>
> Debian handles multiple versions of C libraries at _runtime_ well, but I
> think its support for C libraries still leaves a good deal to be
> desired: it doesn't let you install multiple ver
On Thu, 2013-02-07 at 15:09 -0400, Joey Hess wrote:
> The Built-Using field required[1] by recent policy results in some
> problems for maintainers:
>
> 1. It needs to indicate the exact version of the source package used in
>the build. So this has to be kept up-to-date, or dynamically
>ge
Package: wnpp
Severity: wishlist
Owner: Nick Black
* Package name: growlight -- Disk manipulation and system preparation
tool
Version : 1.0.4.5
Upstream Author : Nick Black
* URL : http://nick-black.com/dankwiki/index.php/Growlight
* License : GPL
Programmin
Neil Williams writes:
> Matthew Woodcraft wrote:
>> I don't think it's as clear-cut as that.
>> Debian handles multiple versions of C libraries at _runtime_ well, but
>> I think its support for C libraries still leaves a good deal to be
>> desired: it doesn't let you install multiple versions o
The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.
Total number of orphaned packages: 526 (new: 3)
Total number of packages offered up for adoption: 142 (new: 1)
Total number of packages request
Ben Hutchings wrote:
> Or 'source', short for 'the build-dependency's source code should be
> treated as part of my source code'. This is already reserved as a
> special architecture name for use in changes file.
Hmm, if it's reserved, what use it is reserved for? Wouldn't want to
step on toes. I
On Thu, 2013-02-07 at 20:51 -0400, Joey Hess wrote:
> Ben Hutchings wrote:
> > Or 'source', short for 'the build-dependency's source code should be
> > treated as part of my source code'. This is already reserved as a
> > special architecture name for use in changes file.
>
> Hmm, if it's reserve
On 07/02/2013 09:16, Steve Langasek wrote:
>
>> > Debian's Python build helper tools are still breeding like rabbits,
>> > there is a new one in experimental. I guess because the current ones
>> > dh_python2/dh_python3 don't handle packages that contain only code
>> > that runs on both python2 and
Chow Loong Jin writes:
> Well, relative to other languages, I think Python's had the most changes
> with regards to build helper tools -- there was dh_pycentral, and
> dh_pysupport in the past which did more or less the same thing in
> different ways, and now we have dh_python2, and dh_python3. I
On Fri, Feb 08, 2013 at 10:00:47AM +0800, Chow Loong Jin wrote:
> On 07/02/2013 09:16, Steve Langasek wrote:
> >> > Debian's Python build helper tools are still breeding like rabbits,
> >> > there is a new one in experimental. I guess because the current ones
> >> > dh_python2/dh_python3 don't han
On 08/02/2013 10:07, Steve Langasek wrote:
> On Fri, Feb 08, 2013 at 10:00:47AM +0800, Chow Loong Jin wrote:
> [...]
>> Well, relative to other languages, I think Python's had the most changes
>> with regards to build helper tools -- there was dh_pycentral, and
>> dh_pysupport in the past which did
Ben Hutchings wrote:
> What I mean is that a changes file for a sourceful upload has
> 'source' (and maybe some real architecture names) in the Architecture
> field. Therefore 'source' cannot be assigned as the name of a real
> architecture.
Ah, sure.
However, "source" in Build-Depends could be
On Thu, 07 Feb 2013, Joey Hess wrote:
> Ben Hutchings wrote:
> > What I mean is that a changes file for a sourceful upload has
> > 'source' (and maybe some real architecture names) in the Architecture
> > field. Therefore 'source' cannot be assigned as the name of a real
> > architecture.
>
> Ah,
32 matches
Mail list logo
