Package: wnpp
Severity: wishlist
Owner: Charles Plessy
Package name: permute
Version : 0.6-3
Upstream Author : Gavin L. Simpson
URL : http://cran.r-project.org/web/packages/permute/
License : GPL-2
Programming Lang: R
Description : R functions fo
Package: wnpp
Severity: wishlist
Owner: Michael Hanke
* Package name: neo
Version : 0.2
Upstream Author : Samuel Garcia, Pierre Yger, Luc Estabanez, Andrew Davison,
Yury V. Zaytsev
* URL : http://neuralensemble.org/trac/neo
* License : BSD
Programming Lang:
Package: wnpp
Severity: wishlist
Owner: Timo Aaltonen
* Package name: 389-admin-console
Version : 1.1.8
Upstream Author : Red Hat, Inc.
* URL : http://directory.fedoraproject.org/
* License : GPL-2
Programming Lang: Java
Description : 389 admin server m
On 11/02/12 15:54, Neil Williams wrote:
debian-u...@lists.debian.org would probably have been better, or
searching on packages.debian.org and contacting the relevant
maintainers.
Discussion of virtual-package-names-list.txt is certainly on-topic for
-devel and really not a user-level question
Package: wnpp
Severity: wishlist
Owner: Timo Aaltonen
* Package name: libwacom
Version : 0.3
Upstream Author : Bastien Nocera
* URL : http://sourceforge.net/projects/linuxwacom/
* License : MIT
Programming Lang: C
Description : Wacom model feature query
On Sun, Feb 12, 2012 at 08:00, Carsten Hey wrote:
> * Aron Xu [2012-02-09 01:22 +0800]:
>> Some packages come with data files that endianness matters, and many
>> of them are large enough to split into a separate arch:all package if
>> endianness were not something to care about. ...
>
> Debian Po
Steve Langasek writes ("Re: Please test gzip -9n - related to dpkg with
multiarch support"):
> And what about adding 700 packages vs. adding no packages at all, in the
> case of systems which aren't going to have multiarch enabled?
One thing that seems to have been overlooked in this discussion o
I wrote:
> Or to put it another way: if currently
> libfoo1 (1.1) contains and needs /usr/share/libfoo1/foo-data-1.1
> libfoo1 (1.2) contains and needs /usr/share/libfoo2/foo-data-1.2
> then splitting the foo-data out into
> libfoo1-data (1.1) <-depends- libfoo1 (1.1)
> libfoo1-data (1.2) <
Goswin von Brederlow writes ("Re: Please test gzip -9n - related to dpkg with
multiarch support"):
> Steve Langasek writes:
> > the [pam] module packages should be installed
> > for all archs, not just a subset[1].
>
> Ok, that is acceptable. We just lack any technical means to ensure this
> so
Serafeim Zanikolas writes ("[DEP9] call for testing of reconf-inetd
(update-inetd replacement)"):
> To test it, in a nutshell:
>
> - make your package install xinetd.conf(5) fragment files in
> /usr/share/reconf-inetd/, one file per service that needs an entry in
> inetd.conf
>
>
Russ Allbery writes ("Re: severity for bugs in ignoring TMP/TMPDIR?"):
> You could probably use strace to find problems by looking for an
> open(O_CREAT) of a file in /tmp that doesn't look like it's
> mkstemp-created (ending in six random characters) and doesn't use O_EXCL.
> You'll get some false
On Feb 13, Ian Jackson wrote:
> The rule would be that if:
> * A file is being opened in a sticky directory
> * The file is going to be created by this operation
> * O_EXCL was not specified
> then the syscall fails with EPERM.
This should be easy to implement as a LSM.
--
ciao,
Marco
s
On Mon, Feb 13, 2012 at 8:57 PM, Marco d'Itri wrote:
> On Feb 13, Ian Jackson wrote:
>
>> The rule would be that if:
>> * A file is being opened in a sticky directory
>> * The file is going to be created by this operation
>> * O_EXCL was not specified
>> then the syscall fails with EPERM.
>
On Mon, 2012-02-13 at 12:40 +, Ian Jackson wrote:
> Russ Allbery writes ("Re: severity for bugs in ignoring TMP/TMPDIR?"):
> > You could probably use strace to find problems by looking for an
> > open(O_CREAT) of a file in /tmp that doesn't look like it's
> > mkstemp-created (ending in six rand
On Mon, 2012-02-13 at 22:07 +0800, Paul Wise wrote:
> On Mon, Feb 13, 2012 at 8:57 PM, Marco d'Itri wrote:
> > On Feb 13, Ian Jackson wrote:
> >
> >> The rule would be that if:
> >> * A file is being opened in a sticky directory
> >> * The file is going to be created by this operation
> >> *
On Sat, Feb 11, 2012 at 10:44:38AM +0800, Paul Wise wrote:
> Based on a quick grep of /usr/bin/* I expect you are correct.
If $TMPDIR is not set, /tmp is a reasonable default, so I'd expect a *lot*
of matches for '/tmp' in programs with correct behaviour.
--
To UNSUBSCRIBE, email to debian-deve
Ben Hutchings writes:
> On Sat, 2012-02-11 at 17:33 +0100, Goswin von Brederlow wrote:
>> Bastian Blank writes:
>>
>> > On Fri, Feb 10, 2012 at 01:00:50PM +0100, Bernhard R. Link wrote:
>> >> just
>> >> to have a suiteable kern
Package: wnpp
Severity: wishlist
Owner: Carlos Vicente
* Package name: libnet-irr-perl
Version : 0.08
Upstream Author : Todd Caine
* URL : http://search.cpan.org/dist/Net-IRR
* License : Artistic or GPL-1+
Programming Lang: Perl
Description : Net::IRR
Ian Jackson writes:
> Goswin von Brederlow writes ("Re: Please test gzip -9n - related to dpkg with
> multiarch support"):
>> Steve Langasek writes:
>> > the [pam] module packages should be installed
>> > for all archs, not just a subset[1].
>>
>> Ok, that is acceptable. We just lack any tech
Ian Jackson writes:
> I wrote:
>> Or to put it another way: if currently
>> libfoo1 (1.1) contains and needs /usr/share/libfoo1/foo-data-1.1
>> libfoo1 (1.2) contains and needs /usr/share/libfoo2/foo-data-1.2
>> then splitting the foo-data out into
>> libfoo1-data (1.1) <-depends- libfoo1 (
Adam Borowski writes:
> On Sat, Feb 11, 2012 at 05:33:45PM +0100, Goswin von Brederlow wrote:
>> If there is no 64bit kernel in i386 then you can not safely enable
>> multiarch to install amd64 packages (in general, kernel my just
>> work). It is kind of a prerequisite.
>
> qemu-user?
>
> Of cour
Goswin von Brederlow writes ("Re: Multi-arch all-architecture plugins"):
> As you said these are usualy plugins that nothing depends on. So this
> wouldn't help much. Also if there is a dependency than the rules for
> m-a:same should be sufficient. If the package is something to depend on
> then pa
Hi Ian,
First of all, thanks for the feedback.
On Mon, Feb 13, 2012 at 12:36:40PM +, Ian Jackson wrote:
> Serafeim Zanikolas writes ("[DEP9] call for testing of reconf-inetd
> (update-inetd replacement)"):
> > To test it, in a nutshell:
> >
> > - make your package install xinetd.conf(5)
Package: wnpp
Severity: wishlist
Owner: Alessio Treglia
* Package name: xvidenc
Version : 8.4.3
Upstream Author : Grozdan Nikolov
* URL : http://xvidenc.sf.net/
* License : GPL
Programming Lang: Bash
Description : shell script to encode DVDs to Xvid
Package: wnpp
Severity: wishlist
Owner: Carlos Vicente
* Package name: liblog-dispatch-config-perl
Version : 1.04
Upstream Author : Tatsuhiko Miyagawa
* URL : http://search.cpan.org/dist/Log-Dispatch-Config/
* License : Artistic or GPL-1+
Programming Lang:
Package: wnpp
Severity: wishlist
Owner: Carlos Vicente
* Package name: liblog-dispatch-configurator-any-perl
Version : 1.110690
Upstream Author : Oliver Gorwits
* URL : http://search.cpan.org/dist/Log-Dispatch-Configurator-Any
* License : Artistic or GPL-1+
On 2/13/12 12:53 PM, Faidon Liambotis wrote:
> Carlos,
>
> On 02/13/12 17:29, Carlos Vicente wrote:
>> Hopefully this module will stimulate development of new Route
>> Registry tools written in Perl. An example of Route Registry tools
>> can be found by googling for RAToolset which is now known as
Carlos,
On 02/13/12 17:29, Carlos Vicente wrote:
> Hopefully this module will stimulate development of new Route
> Registry tools written in Perl. An example of Route Registry tools
> can be found by googling for RAToolset which is now known as the
> IRRToolset. The RAToolset was originally develo
Package: wnpp
Severity: wishlist
Owner: Carlos Vicente
* Package name: Net::CLI::Interact
Version : 1.120042
Upstream Author : Oliver Gorwits
* URL : http://search.cpan.org/dist/Net-CLI-Interact/
* License : Artistic or GPL-1+
Programming Lang: Perl
Descri
On Mon, Feb 13, 2012 at 04:30:47PM +0100, Goswin von Brederlow wrote:
> Ben Hutchings writes:
>
> > On Sat, 2012-02-11 at 17:33 +0100, Goswin von Brederlow wrote:
> >> Bastian Blank writes:
> >>
> >> > On Fri, Feb 10, 2012 at 01:00:50PM +0100, Bernhard R. Link wrote:
> >> >>
Package: wnpp
Severity: wishlist
Owner: Carlos Vicente
* Package name: libnet-appliance-session-perl
Version : 3.113610
Upstream Author : Oliver Gorwits
* URL : http://search.cpan.org/dist/Net-Appliance-Session/
* License : Artistic or GPL-1+
Programming La
On Sun, Jan 29, 2012 at 11:06:27PM +, Sune Vuorela wrote:
> Hi
>
> One of my upstreams of a collection of shared libraries is about to make
> a change that is going to require all executables built against these
> shared libraries to be built with -fPIE (and libraries with -fPIC).
>
> Is ther
Kurt Roeckx writes:
> On Sun, Jan 29, 2012 at 11:06:27PM +, Sune Vuorela wrote:
>> One of my upstreams of a collection of shared libraries is about to
>> make a change that is going to require all executables built against
>> these shared libraries to be built with -fPIE (and libraries with
>
On 2012-02-13, Russ Allbery wrote:
> No, I think only executables would be built PIE. Libraries would continue
> to be built PIC
Correct.
/Sune
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Arch
Package: wnpp
Severity: wishlist
Owner: Neil Williams
* Package name: ladder
Version : 0.0.1
Upstream Author : Neil Williams
* License : GPL3+
Programming Lang: Perl
Description : Stepwise repository upgrade tool
Creates a local repository of packages required to
Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org
--- Please fill out the fields below. ---
Package name: jenkins-subversion-plugin
Version: 1.37
Upstream Author: Kohsuke Kawaguchi and others
License: MIT
Description: Jenkins Subversion Plugin (J
Kurt Roeckx roeckx.be> writes:
> So my understanding is that you want to build libraries with -fPIE
> instead of -fPIC, and that that creates a different ABI?
What affects the ABI is compiling the library in a way that does not support
copy relocations. This can be done with visibility attributes
On Tue, Jan 31, 2012 at 10:07:22PM +, Roger Leigh wrote:
> On Tue, Jan 31, 2012 at 11:52:42AM -0800, Steve Langasek wrote:
> > On Tue, Jan 31, 2012 at 08:10:11PM +0100, Luk Claes wrote:
> > > > Interesting timing. initscripts started depending on ucf just a few
> > > > days ago, which makes ucf
Package: wnpp
Severity: wishlist
Owner: Ximin Luo
* Package name: mozilla-gnome-keyring
Version : 0.6.1
Upstream Author : Ximin Luo
* URL : https://github.com/infinity0/mozilla-gnome-keyring
* License : MPL-1.1 or GPL-2+ or LGPL-2.1+
Programming Lang: C++
On Mon, Feb 13, 2012 at 11:29 PM, Jon Dowland wrote:
> If $TMPDIR is not set, /tmp is a reasonable default, so I'd expect a *lot*
> of matches for '/tmp' in programs with correct behaviour.
I get the impression that directly hardcoding /tmp/ usually indicates
that safe temporary file/dir function
Paul Wise writes:
> On Mon, Feb 13, 2012 at 11:29 PM, Jon Dowland wrote:
>> If $TMPDIR is not set, /tmp is a reasonable default, so I'd expect a
>> *lot* of matches for '/tmp' in programs with correct behaviour.
> I get the impression that directly hardcoding /tmp/ usually indicates
> that safe
On Tue, Feb 14, 2012 at 00:09, Ian Jackson
wrote:
> Goswin von Brederlow writes ("Re: Multi-arch all-architecture plugins"):
>> As you said these are usualy plugins that nothing depends on. So this
>> wouldn't help much. Also if there is a dependency than the rules for
>> m-a:same should be suffic
Package: wnpp
Severity: wishlist
Owner: Carlos Vicente
* Package name: libnet-dns-zonefile-fast-perl
Version : 1.16
Upstream Author : Wes Hardaker
* URL : http://search.cpan.org/dist/Net-DNS-ZoneFile-Fast/
* License : THE BEER-WARE LICENSE
Programming Lang:
[Ian Jackson]
> Where should this fact be declared ? Is it a property of a package
> that it makes sense to install it only on all configured architectures
> or none ? Or is it a property of the dependency from the depending
> package ?
Neither. If I've configured i386 on an amd64 system just
There's been a lot of discussion of this, but it seems to have been fairly
inconclusive. We need to decide what we're doing, if anything, for wheezy
fairly soon, so I think we need to try to drive this discussion to some
concrete conclusions.
First, Steve's point here is very good:
Steve Langase
On Mon, 13 Feb 2012, Russ Allbery wrote:
> There's been a lot of discussion of this, but it seems to have been fairly
> inconclusive. We need to decide what we're doing, if anything, for wheezy
> fairly soon, so I think we need to try to drive this discussion to some
> concrete conclusions.
Thank
46 matches
Mail list logo
