Bug#659689: ITP: permute -- R functions for generating restricted permutations of data

[Charles Plessy]

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 for generating restricted permutations of data

 Implements a set of restricted permutation designs for freely exchangeable,
 line transects (time series), and spatial grid designs plus permutation of
 blocks (groups of samples). 'permute' also allows split-plot designs, in which
 the whole-plots or split-plots or both can be freely-exchangeble or one of the
 restricted designs. The permute package is modelled after the permutation
 schemes of Canoco 3.1 by Cajo ter Braak.

This R library is needed to package the “vegan” R library.

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120213090248.16199.76320.reportbug@localhost.localdomain

Bug#659691: ITP: neo -- IO library for electrophysiological data formats in Python

[Michael Hanke]

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: Python
  Description : IO library for electrophysiological data formats in Python
 NEO stands for Neural Ensemble Objects and is a project to provide common
 class names and concepts for dealing with electro-physiological (in vivo
 and/or simulated) data with the aim of getting OpenElectrophy, NeuroTools,
 G-node and maybe other projects with similar goals more close together.
 .
 In particular Neo provides:
 .
  * a set a classes with precise definitions
  * an IO module that offer a simple API that fit many formats
  * documentation.
  * a set of examples like a format convertor



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120213092356.25026.20287.reportbug@meiner

Bug#659693: ITP: 389-admin-console -- 389 admin server management console

[Timo Aaltonen]

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 management console

A Java based remote management console used for managing 
the 389 admin server.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120213092437.14370.66756.reportbug@eldon.tyrell

Re: Virtual package lua should be provided by lua5.1.

[Jon Dowland]

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 or discussion.



--
Jon Dowland


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f38d88f.4080...@debian.org

Bug#659700: ITP: libwacom -- Wacom model feature query library

[Timo Aaltonen]

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 library

libwacom is a library to identify wacom tablets and their model-specific
features. It provides easy access to information such as "is this a built-in
on-screen tablet", "what is the size of this model", etc.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120213103804.14859.25984.reportbug@eldon.tyrell

Re: Endianness of data files in MultiArch (was: Please test gzip -9n - related to dpkg with multiarch support)

[Aron Xu]

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 Policy, begin of section 5.6.8:
> | Depending on context and the control file used, the Architecture field
> | can include the following sets of values:
> |  * A unique single word identifying a Debian machine architecture as
> |    described in Architecture specification strings, Section 11.1.
> |  * An architecture wildcard identifying a set of Debian machine
> |    architectures, see Architecture wildcards, Section 11.1.1. any
> |    matches all Debian machine architectures and is the most frequently
> |    used.
> |  * all, which indicates an architecture-independent package.
> |  * source, which indicates a source package.
>
> Possible addition to solve your problem:
>   * littleendian[1], which indicates a package that is installable on
>     all little endian architectures.
>   * bigendian[1], which indicates a package that is installable on
>     all big endian architectures.
>

I agree this will help a lot, and the endians may be shortened as "le"
and "be". But there's still file collision if maintainer doesn't
install them in different paths, but that's another story.

debian-policy people, would you like to take this idea? What's the
steps to make this (possibly) happen?


-- 
Regards,
Aron Xu


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAMr=8w6zX=2_u9qgswi-sno+axxskr4fpk4au1n7cbxtkjd...@mail.gmail.com

Re: Please test gzip -9n - related to dpkg with multiarch support

[Ian Jackson]

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 of
splitting is that splitting packages is not a completely neutral
operation, semantically.

The package is the unit of installation and upgrade; dependencies do
not prevent a package from being on the system for a considerable time
with its dependencies violated.

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) <-depends- libfoo1 (1.2)
means that when the libfoo packages are upgraded, there will be a
substantial period when we have /usr/lib/libfoo1.so.1.2 installed and
the symlink libfoo1.so.1 points to it, but
/usr/share/libfoo2/foo-data-1.2 is missing.

If the packages are not split, dpkg will unpack
/usr/share/libfoo2/foo-data-1.2 before overwriting the old
libfoo1.so.1 symlink.  So normally, our current arrangements mean that
shared libraries continue to work throughout an upgrade.  Splitting
shared data out like this may make this no longer true (for some
unknown set of packages).

This issue is very important for essential packages, but in general
it's not a good idea to introduce additional sources of skew.  For an
essential package the problem can be solved with a Pre-Depends but the
result has to look like this:
  libfoo1-data1.1 (1.1) <-depends- libfoo1 (1.1)
  libfoo1-data1.2 (1.2) <-depends- libfoo1 (1.2)

So I think the refcounting in dpkg is the best option for these files.

Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20280.65534.54525.328...@chiark.greenend.org.uk

Re: Please test gzip -9n - related to dpkg with multiarch support

[Ian Jackson]

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) <-depends- libfoo1 (1.2)
> means that when the libfoo packages are upgraded, there will be a
> substantial period when we have /usr/lib/libfoo1.so.1.2 installed and
> the symlink libfoo1.so.1 points to it, but
> /usr/share/libfoo2/foo-data-1.2 is missing.

... or vice versa, of course.  How long this situation persists will
vary.

Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20281.91.957041.390...@chiark.greenend.org.uk

Multi-arch all-architecture plugins

[Ian Jackson]

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 far. Same problem as for input method plugins for example.

So we need a new mechanism for this.

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 ?

I'm inclined to the former view.  After all if you think about
installing some plugin, there may not even /be/ a dependency in
question.  And I'm finding it difficult to imagine a package which has
this all-arches-needed multiarch property for some of its purposes but
not others.

This situation can only arise for a m-a:same package, since only those
are coinstallable.  I would suggest that the right answer is a new
value for the Multi-Arch field, let's call it "all".  It would work
like Multi-Arch: same except that:

 * Dependencies on multiarch:all package are not satisfied unless
   the package is suitably installed and configured on all configured 
   architectures.  Ie with

  Package: plugin
  Multi-Arch: all
  Architecture: i386

  Package: plugin
  Multi-Arch: all
  Architecture: amd64

   this dependency

  Depends: plugin

   is read as

  Depends: plugin:i386, plugin:amd64

 * The higher-level package manager, when it is asked to install a
   multiarch:all package, will install it for all configured
   architectures.

Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20281.609.605532.103...@chiark.greenend.org.uk

Re: [DEP9] call for testing of reconf-inetd (update-inetd replacement)

[Ian Jackson]

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
> 
> - run reconf-inetd as root
> 
> - check whether an entry has been added in /etc/inetd.conf.

Thanks.  update-inetd has needed a revamp for quite a while.  I'll
hopefully have a chance to look at this properly at some point, but in
the meantime:

Are you sure putting the fragments in /usr/share is the best 
approach ?  It seems to me that it might be better to put them in
/etc/, where the sysadmin can edit them if they want to change the
behaviour but still get the benefit of the automatic addition/removal.

Thanks,
Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20281.984.894097.80...@chiark.greenend.org.uk

Re: severity for bugs in ignoring TMP/TMPDIR?

[Ian Jackson]

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 positives from files in safely-created directories.

I once proposed a kernel patch which would detect all of these unsafe
tmpfile problems (except if the attack was actually being carried out)
and turn them into hard failures.

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 didn't meet with general approval but I still think it would be a
good idea, at least to try.  And it might even be less effort than
messing with strace, because strace has some pretty serious signal
handling bugs which mean that programs with complicated process farms
often don't work properly under strace.

Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20281.1211.909188.106...@chiark.greenend.org.uk

Re: severity for bugs in ignoring TMP/TMPDIR?

[Marco d'Itri]

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


signature.asc
Description: Digital signature

Re: severity for bugs in ignoring TMP/TMPDIR?

[Paul Wise]

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.
> This should be easy to implement as a LSM.

Kees Cook implemented protections against symlink attacks in Yama (an LSM):

https://lwn.net/Articles/393012/

Of course LSMs don't yet stack so it cannot be combined with SELinux etc.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAKTje6EpvGTpX2mDV-9O9yvQuYg1asMHN=bz8trwevvnqz-...@mail.gmail.com

Re: severity for bugs in ignoring TMP/TMPDIR?

[Ben Hutchings]

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 random characters) and doesn't use O_EXCL.
> > You'll get some false positives from files in safely-created directories.
> 
> I once proposed a kernel patch which would detect all of these unsafe
> tmpfile problems (except if the attack was actually being carried out)
> and turn them into hard failures.
> 
> 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.
[...]

A similar change has been implemented

 and will probably be included in wheezy.

Ben.

-- 
Ben Hutchings
Beware of programmers who carry screwdrivers. - Leonard Brandwein


signature.asc
Description: This is a digitally signed message part

Re: severity for bugs in ignoring TMP/TMPDIR?

[Ben Hutchings]

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
> >>   * O_EXCL was not specified
> >> then the syscall fails with EPERM.
> > This should be easy to implement as a LSM.
> 
> Kees Cook implemented protections against symlink attacks in Yama (an LSM):
> 
> https://lwn.net/Articles/393012/
> 
> Of course LSMs don't yet stack so it cannot be combined with SELinux etc.

YAMA just does ptrace restriction at the moment.  Symlink restrictions
will be done in the security core.

Ben.

-- 
Ben Hutchings
Beware of programmers who carry screwdrivers. - Leonard Brandwein


signature.asc
Description: This is a digitally signed message part

Re: severity for bugs in ignoring TMP/TMPDIR?

[Jon Dowland]

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-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120213152943.GA4732@debian

Re: How to tell users that ia32-libs will go away

[Goswin von Brederlow]

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 kernel would be quite a burden.
>> >
>> > The -amd64 kernel in i386 arch is some sort of upgrade tool. With
>> > multi-arch it gets easier. Either the machine can run 64bit code, than
>> > it is irrelevant what packages are installed from which arch. Or it
>> > can't, then you don't need the amd64 kernel in the first place.
>> >
>> > Bastian
>> 
>> Actualy that raises an interesting point:
>> 
>> 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.
>
> By the same argument you can't ever enable any foreign architecture.
> This is nonsense.
>
> Ben.

Why? I can install qemu-user-static and my system will be able to
execute e.g. armel code.

On the other hand installing linux-image-3.2.0-1-amd64:amd64 would pull
in for example module-init-tools:amd64, making it impossible to
load/remove modules on the running system or reboot with a 32bit kernel.

MfG
Goswin



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87zkcmsqc8.fsf@frosties.localnet

Bug#659753: ITP: libnet-irr-perl -- Net::IRR - Perl interface to the Internet Route Registry Daemon

[Carlos Vicente]

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 - Perl interface to the Internet Route Registry 
Daemon

This module provides an object oriented perl interface to the Internet Route 
Registry. The interface uses the RIPE/RPSL Tool Query Language as defined in 
Appendix B of the IRRd User Guide. The guide can be found at 
http://www.irrd.net/, however an understanding of the query language is not 
required to use this module.

Net::IRR supports IRRd's multiple-command mode. Multiple-command mode is good 
for intensive queries since only one TCP connection needs to be made for 
multiple queries. The interface also allows for additional queries that aren't 
supported by standard UNIX whois utitilies.

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 developed by ISI, http://www.isi.edu/, and is now maintained by 
RIPE, http://www.ripe.net/.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120213152913.14276.30079.reportbug@ubuntu

Re: Multi-arch all-architecture plugins

[Goswin von Brederlow]

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 technical means to ensure this
>> so far. Same problem as for input method plugins for example.
>
> So we need a new mechanism for this.
>
> 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 ?
>
> I'm inclined to the former view.  After all if you think about
> installing some plugin, there may not even /be/ a dependency in
> question.  And I'm finding it difficult to imagine a package which has
> this all-arches-needed multiarch property for some of its purposes but
> not others.

I agree that it is the former and think it unlikely that there is a
dependency on it unless one all-arches-needed plugin depends on another.

> This situation can only arise for a m-a:same package, since only those
> are coinstallable.  I would suggest that the right answer is a new
> value for the Multi-Arch field, let's call it "all".  It would work
> like Multi-Arch: same except that:
>
>  * Dependencies on multiarch:all package are not satisfied unless
>the package is suitably installed and configured on all configured 
>architectures.  Ie with

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 packages of all architectures should depend on it if they use
it. The plugin might only be used by amd64 packages and none of the i386
would depend on it and then installing only amd64 is perfectly fine.

I would concentrate on the case that nothing depends on it and the
solution while keeping the depending case in the back of my mind.

>   Package: plugin
>   Multi-Arch: all
>   Architecture: i386
>
>   Package: plugin
>   Multi-Arch: all
>   Architecture: amd64
>
>this dependency
>
>   Depends: plugin
>
>is read as
>
>   Depends: plugin:i386, plugin:amd64
>
>  * The higher-level package manager, when it is asked to install a
>multiarch:all package, will install it for all configured
>architectures.
>
> Ian.

Another possible solution was to have a metapackage with wildcard
dependency:

Package: plugin-all
Depends: plugin:*

One thing to keep in mind is that the list of architectures for the
system might change (the admin adds another architecture) making any
such all-archs dependencies suddenly unfullfilled. But that is probably
unavoidable and apt-get -f install would fix it right up.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87vcnaspq6.fsf@frosties.localnet

Re: Please test gzip -9n - related to dpkg with multiarch support

[Goswin von Brederlow]

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 (1.1)
>>   libfoo1-data (1.2) <-depends- libfoo1 (1.2)
>> means that when the libfoo packages are upgraded, there will be a
>> substantial period when we have /usr/lib/libfoo1.so.1.2 installed and
>> the symlink libfoo1.so.1 points to it, but
>> /usr/share/libfoo2/foo-data-1.2 is missing.
>
> ... or vice versa, of course.  How long this situation persists will
> vary.
>
> Ian.

I would say that if it is critical for the lib, esspecially essential
ones, that the data exists then it should be arch qualified and kept in
the library package, even if that means duplicating it in the archive
and the users system.

Don't forget that splitting isn't the only options. We can combine
multiple ways to deal with this. I don't beleave any single way will
work for all packages so lets find a good combination of things so that
everybody is happy.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87r4xyspgm.fsf@frosties.localnet

Re: How to tell users that ia32-libs will go away

[Goswin von Brederlow]

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 course, this particular combination is quite bizarre as no non-embedded
> i386 CPU manufactured today can't execute amd64 code directly (Intel had a
> throwback in early Atoms but even that is gone).  Yet I personally did need
> to run qemu-system-amd64 on i386 on one occasion, many years ago.
>
> So I think there should be a way to mark architectures as one of:
> a) primary (can be ran efficiently)
> b) configured for execution (qemu, unwanted variants)
> c) data/headers only (cross-compilation)
>
> Group b) should be avoided by apt when possible, and it should refuse to
> install any executables from c) unless forced.  Not sure what to check for
> -- having any files in /{usr/,}{s}bin ?
>
> This way people would be safe from accidentally installing binaries that
> don't work or work slowly.

Case C should only allow MA:same packages unless forced.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87mx8mspd7.fsf@frosties.localnet

Re: Multi-arch all-architecture plugins

[Ian Jackson]

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 packages of all architectures should depend on it if they use
> it. The plugin might only be used by amd64 packages and none of the i386
> would depend on it and then installing only amd64 is perfectly fine.

I don't think that's the case.  Consider something like fakeroot.  The
fakeroot binary itself may be any architecture, because its function
is to set up a socket and be a server for children and set an
LD_PRELOAD and so forth.  But the libfakeroot.so must be available for
all configured architectures so that the LD_PRELOAD works no matter
what architecture(s') binaries end up running.

So you would have:

   Package: fakeroot
   Multi-Arch: foreign
   Depends: libfakeroot

   Package: libfakeroot
   Multi-Arch: all

and it would have to mean "install libfakeroot for all configured
architectures".  If libfakeroot were m-a:same then it would mean
"install libfakeroot for the arch whose fakeroot we picked" which is
wrong.

> I would concentrate on the case that nothing depends on it and the
> solution while keeping the depending case in the back of my mind.
...
> Another possible solution was to have a metapackage with wildcard
> dependency:
> 
> Package: plugin-all
> Depends: plugin:*

So plugin would be m-a:allowed ?
  
> One thing to keep in mind is that the list of architectures for the
> system might change (the admin adds another architecture) making any
> such all-archs dependencies suddenly unfullfilled. But that is probably
> unavoidable and apt-get -f install would fix it right up.

Yes.  Something would have to be done then, certainly.

Perhaps the right answer is not to consider configured architectures,
but rather architectures for which any package is installed.

Ie, as follows:

 * Find the set of all architectures "foo" for which any package is
   present on the system

 * Now for each

 Package: plugin
 Architecture: bar
 Multi-Arch: all

   imagine a dependency

 Depends: plugin:foo1, plugin:foo2, ...

Should dpkg do this as well as apt ?

Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20281.13734.668798.615...@chiark.greenend.org.uk

Re: [DEP9] call for testing of reconf-inetd (update-inetd replacement)

[Serafeim Zanikolas]

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) fragment files in
> >   /usr/share/reconf-inetd/, one file per service that needs an entry in
> >   inetd.conf
> > 
> > - run reconf-inetd as root
> > 
> > - check whether an entry has been added in /etc/inetd.conf.
> 
> Thanks.  update-inetd has needed a revamp for quite a while.  I'll
> hopefully have a chance to look at this properly at some point, but in
> the meantime:
> 
> Are you sure putting the fragments in /usr/share is the best 
> approach ?  It seems to me that it might be better to put them in
> /etc/, where the sysadmin can edit them if they want to change the
> behaviour but still get the benefit of the automatic addition/removal.

Any local sysadmin changes must be done in inetd.conf, as always.

The choice of /usr/share/ follows from two of the requirements I have set from
the beginning for DEP9 [0]:

- the standard configuration files of inetd and xinetd must remain the
  authoritative files;
- the solution must not change the way system administrators configure inetd

/usr/share/reconf-inetd fragments are not configuration files; they're just
input to reconf-inetd. You can think of them as the file-based equivalent of
command line arguments to update-inetd

cheers,
sez

[0] an older proposal of mine in -devel was rejected (rightfully so) precisely
for not meeting these requirements


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120213160508.GD26977@mobee

Bug#659774: ITP: xvidenc -- shell script to encode DVDs to Xvid

[Alessio Treglia]

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

 A shell script which makes it easy to encode DVDs, (S)VCDs or video files
 to the Xvid video format using MEncoder from the MPlayer project.
 .
 xvidenc is written in a way to be useful for power users yet it is also
 very user friendly for people who are novices when it comes to video
 encoding. xvidenc operates by asking questions to the user, collecting
 input and passing it over to the encoding software. One of its unique
 features is the ability to use built-in video quality presets. This is
 especially useful to people who are just starting to encode video.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120213172341.21139.14113.reportbug@alessio-laptop

Bug#659780: ITP: liblog-dispatch-config-perl -- Log::Dispatch::Config - Log4j for Perl

[Carlos Vicente]

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: Perl
  Description : Log::Dispatch::Config - Log4j for Perl

Log::Dispatch::Config is a subclass of Log::Dispatch and provides a way to 
configure Log::Dispatch object with configulation file (default, in AppConfig 
format). I mean, this is log4j for Perl, not with all API compatibility though.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120213175726.4363.99394.reportbug@ubuntu

Bug#659789: ITP: liblog-dispatch-configurator-any-perl -- Log::Dispatch::Configurator::Any - Configurator implementation with Config::Any

[Carlos Vicente]

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+
  Programming Lang: Perl
  Description : Log::Dispatch::Configurator::Any - Configurator 
implementation with Config::Any



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120213183318.5652.85847.reportbug@ubuntu

Re: Bug#659753: ITP: libnet-irr-perl -- Net::IRR - Perl interface to the Internet Route Registry Daemon

[Carlos Vicente]

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 the
>> IRRToolset. The RAToolset was originally developed by ISI,
>> http://www.isi.edu/, and is now maintained by RIPE,
>> http://www.ripe.net/.
> 
> This is a really old description. IRRToolset has long moved under ISC's
> umbrella¹ where is dying a slow death… There's even an ITP for it (with
> packages prepared) but I've hesitated to upload since it seems to be
> abandoned upstream.
> 
> Regards,
> Faidon
> 
> ¹: http://www.isc.org/software/irrtoolset
> 

OK, I can remove that part from the package description for Net::IRR if
that helps.

Probably best to notify the upstream author, though.

-- 
cv


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f394fa4.5020...@uoregon.edu

Re: Bug#659753: ITP: libnet-irr-perl -- Net::IRR - Perl interface to the Internet Route Registry Daemon

[Faidon Liambotis]

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 developed by ISI,
> http://www.isi.edu/, and is now maintained by RIPE,
> http://www.ripe.net/.

This is a really old description. IRRToolset has long moved under ISC's
umbrella¹ where is dying a slow death… There's even an ITP for it (with
packages prepared) but I've hesitated to upload since it seems to be
abandoned upstream.

Regards,
Faidon

¹: http://www.isc.org/software/irrtoolset


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f394e2f.1040...@debian.org

Bug#659798: ITP: Net::CLI::Interact -- Toolkit for CLI Automation

[Carlos Vicente]

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
  Description : Toolkit for CLI Automation

This module exists to support developers of applications and libraries which 
must interact with a command line interface.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120213190307.10128.77851.reportbug@ubuntu

Re: How to tell users that ia32-libs will go away

[Ben Hutchings]

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:
> >> >> just
> >> >> to have a suiteable kernel would be quite a burden.
> >> >
> >> > The -amd64 kernel in i386 arch is some sort of upgrade tool. With
> >> > multi-arch it gets easier. Either the machine can run 64bit code, than
> >> > it is irrelevant what packages are installed from which arch. Or it
> >> > can't, then you don't need the amd64 kernel in the first place.
> >> >
> >> > Bastian
> >> 
> >> Actualy that raises an interesting point:
> >> 
> >> 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.
> >
> > By the same argument you can't ever enable any foreign architecture.
> > This is nonsense.
> >
> > Ben.
> 
> Why? I can install qemu-user-static and my system will be able to
> execute e.g. armel code.
> 
> On the other hand installing linux-image-3.2.0-1-amd64:amd64 would pull
> in for example module-init-tools:amd64, making it impossible to
> load/remove modules on the running system or reboot with a 32bit kernel.

Currently linux-image-3.2.0-1-amd64:amd64 is effectively uninstallable
on i386 since various other packages depend on module-init-tools:i386.
However, once #649437 is fixed, module-init-tools:i386 (or rather
kmod:i386) will satisfy the dependency.

Since dpkg will prefer to install packages from the native
architecture, I don't see any problem here.  I suppose I'm biased by
having actually tested this.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120213192253.gl12...@decadent.org.uk

Bug#659800: ITP: libnet-appliance-session-perl -- Run command-line sessions to network appliances

[Carlos Vicente]

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 Lang: Perl
  Description : Run command-line sessions to network appliances

Use this module to establish an interactive command-line session with a network 
appliance. There is special support for moving into "privileged" mode and 
"configure" mode, along with the ability to send commands to the connected 
device and retrieve returned output.

There are other CPAN modules that cover similar ground, but they are less 
robust 
and do not handle native SSH, Telnet and Serial Line connections with a single 
interface on both Unix and Windows platforms.

Built-in commands come from a phrasebook which supports many network device 
vendors (Cisco, HP, etc) or you can install a new phrasebook. Most phases of 
the connection are configurable for different device behaviours.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120213193504.14865.59272.reportbug@ubuntu

Re: -fPIE and stuff

[Kurt Roeckx]

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 there anything I should be aware of?
> 
> A bit of background:
> http://www.macieira.org/blog/2012/01/sorry-state-of-dynamic-libraries-on-linux/
> http://www.macieira.org/blog/2012/01/update-and-benchmark-on-the-dynamic-library-proposals/

So my understanding is that you want to build libraries with -fPIE
instead of -fPIC, and that that creates a different ABI?

I think it's going to be a pain to get everything moved to this
new ABI, and would rather wait for the toolchain to change.


Kurt


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120213201613.ga4...@roeckx.be

Re: -fPIE and stuff

[Russ Allbery]

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
>> -fPIC).

> So my understanding is that you want to build libraries with -fPIE
> instead of -fPIC, and that that creates a different ABI?

No, I think only executables would be built PIE.  Libraries would continue
to be built PIC.  (I don't believe you *can* build shared libraries PIE.)

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87y5s6wk2w@windlord.stanford.edu

Re: -fPIE and stuff

[Sune Vuorela]

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
Archive: http://lists.debian.org/slrnjjitco.p7v.nos...@sshway.ssh.pusling.com

Bug#659807: ITP: ladder -- Stepwise repository upgrade tool

[Neil Williams]

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 upgrade
a chroot to a new milestone or software release.
..
The repository can be signed and includes all specified
target packages and dependencies. The repository can then
be distributed and used to upgrade multiple devices in
sequence without needing network access.

This is a package I needed for work and turns out to be
potentially useful for other production environments,
especially where the base system is fixed between
milestones and custom software is released on top.

The principle will be that a sequence of ladder tarballs
can be kept, one for each milestone, allowing devices to
step up the ladder from one milestone to the next.

Downgrading, as in Debian, is not supported.

I'll be using Emdebian SVN before uploading.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120213204524.27240.64616.reportbug@sylvester.codehelp

Bug#659819: ITP: jenkins-subversion-plugin -- Subversion integration for Jenkins

[Jakub Adam]

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 (Java artifacts)

 This plugin adds the Subversion support (via SVNKit) to Jenkins.
 .
 Once this plugin is installed, you'll see Subversion as one of the options in
 the SCM.



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f398990.60...@ktknet.cz

Re: -fPIE and stuff

[Uoti Urpala]

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 or linker flags
like -Bsymbolic. Then the main program needs to be compiled with -fPIE or it
will see different symbol addresses (for the library the symbol will refer to
the "original" one, for the main program it will refer to a copy at a different
address).

Here's an example of a library that requires -fPIE for the main program:
$$ cat lib.c
#include 

__attribute__((visibility("protected"))) int end_of_list_sentinel;
void f(int **list)
{
for (int i = 0; list[i] != &end_of_list_sentinel; i++)
printf("%d\n", *list[i]);
}
$$ cat main.c
#include 

extern int end_of_list_sentinel;
void f(int **list);

int main(void)
{
f((int *[]){&(int){42}, &end_of_list_sentinel});
return 0;
}
$$ gcc --std=gnu99 -Wall -shared -fPIC -o lib.o lib.c
$$ gcc -Wall -fPIE main.c lib.o
$$ LD_LIBRARY_PATH=. ./a.out
42
$$ gcc -Wall main.c lib.o
$$ LD_LIBRARY_PATH=. ./a.out
42
0
1
Segmentation fault



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/loom.20120213t231116-...@post.gmane.org

Re: mass bug filing of 'ucf: command not found' errors detected by piuparts

[Roger Leigh]

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 quasi-essential.
> > 
> > > Unless you are going to argue to add it to the essential set, I can't
> > > see why that matters. It's still wrong to use non-essential packages
> > > in postrm unconditionally. One could even argue that an essential
> > > package should not use ucf unconditionally and have a sane fall back
> > > when it's not available.
> > 
> > Well, I would argue that packages in the essential set shouldn't be adding
> > new dependencies without some discussion and review on debian-devel first.
> 
> Hopefully we can remove the ucf dependency; please see #648433.
> Currently /etc/default/rcS is intentionally only installed once
> during a fresh install, and never updated afterward.  However,
> this precludes ever updating it.  Ideally we could make it a
> conffile and handle it entirely with dpkg; this would probably
> require splitting out the variables which should never be touched
> into a separate file under /etc/defaults.

Just FYI, please see #659451.  I've split the UTC variable into
/etc/default/hwclock, which means /etc/default/rcS can become a
regular dpkg conffile (in current git only for now).  This needs
support in d-i clock-setup (done) and util-linux (pending) before
upload.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120213234531.ge8...@codelibre.net

Bug#659826: ITP: mozilla-gnome-keyring -- Store mozilla passwords in GNOME Keyring.

[Ximin Luo]

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++
  Description : Store mozilla passwords in GNOME Keyring.

 This extenion integrates gnome-keyring into xulrunner applications as the
 software security device.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120213234545.5347.3093.reportbug@localhost.localdomain

Re: severity for bugs in ignoring TMP/TMPDIR?

[Paul Wise]

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 functions are not being used. Usually
there isn't any point in hardcoding /tmp/ if you are using those
functions, since they respect TMPDIR and fall back on /tmp/ anyway.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAKTje6EuL0ZrSmLJPK7=oj_0zsrnabcjkhcktbyuy8ooz7j...@mail.gmail.com

Re: severity for bugs in ignoring TMP/TMPDIR?

[Russ Allbery]

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 temporary file/dir functions are not being used. Usually there
> isn't any point in hardcoding /tmp/ if you are using those functions,
> since they respect TMPDIR and fall back on /tmp/ anyway.

I think this is incorrectly optimistic about the existence of general and
secure functions for creating temporary files that handle TMPDIR.  In C,
for example, the only portable and secure way to create a temporary file
is mkstemp, which does not handle TMPDIR vs. /tmp for you and requires
that you handle it yourself.

tempnam() handles TMPDIR, but it's very difficult to use properly (which
is why the man page says "never use this function").  tmpfile() is secure,
but is not documented as supporting TMPDIR and creates an unlinked file,
so you can't use it for some things you need to use a temporary filel for.
All the other options are worse.

Your statement is correct about shell, where mktemp does the right thing,
but you'd have to look at each language separately.  Most of the scripting
languages probably have some facility to do the right thing; compiled
languages I suspect are a bit more variable.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ipjap3pk@windlord.stanford.edu

Re: Multi-arch all-architecture plugins

[Aron Xu]

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 sufficient. If the package is something to depend on
>> then packages of all architectures should depend on it if they use
>> it. The plugin might only be used by amd64 packages and none of the i386
>> would depend on it and then installing only amd64 is perfectly fine.
>

This is true for maybe all programs that use alike communication
method between main application and its plugins. I encountered another
example with D-Bus. The host architecture side listens on a D-Bus
session, and "MA: same" plugins installed in other architecture (i386
for me) can communicate with the amd64 one and works perfectly fine.

(My example are fcitx-frontend-* and fcitx-module-dbus in Sid.)

> I don't think that's the case.  Consider something like fakeroot.  The
> fakeroot binary itself may be any architecture, because its function
> is to set up a socket and be a server for children and set an
> LD_PRELOAD and so forth.  But the libfakeroot.so must be available for
> all configured architectures so that the LD_PRELOAD works no matter
> what architecture(s') binaries end up running.
>
> So you would have:
>
>   Package: fakeroot
>   Multi-Arch: foreign
>   Depends: libfakeroot
>
>   Package: libfakeroot
>   Multi-Arch: all
>
> and it would have to mean "install libfakeroot for all configured
> architectures".  If libfakeroot were m-a:same then it would mean
> "install libfakeroot for the arch whose fakeroot we picked" which is
> wrong.
>

I second this proposal, but with the doubt about making it a "Depends"
on other co-installed architectures. It might be rather irrelevant on
fakeroot, such an "important" package. But when a user decide to
install something on his primary architecture, and wanted to keep his
other co-installed minimal to do some other stuff, forcing them
installing a bunch of things isn't kind.

Making it works like "Recommends" can be more friendly. And yes, this
way has its shortcomings, but seems to be saner.

-- 
Regards,
Aron Xu


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAMr=8w662+6o1wx_s-iibkyfezbl3btt7213go7wwwugatd...@mail.gmail.com

Bug#659837: ITP: libnet-dns-zonefile-fast-perl -- parse BIND8/9 zone files

[Carlos Vicente]

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: Perl
  Description : parse BIND8/9 zone files

The Net::DNS::ZoneFile::Fast module provides an ability to parse zone files 
that BIND8 and BIND9 use, fast. Currently it provides a single function, 
parse(), which returns a reference to an array of traditional Net::DNS::RR 
objects, so that no new API has to be learned in order to manipulate zone 
records.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120214024712.26034.11357.reportbug@ubuntu

Re: Multi-arch all-architecture plugins

[Peter Samuelson]

[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 to install 2
binaries and libc6, but on amd64 I've installed, say, a gimp plugin, I
don't want to have to install, on i386, not only this same plugin but
also libgimp and its dependency tree, including the whole Gtk stack.
s
What we really want to express is: {this package}, if installed, should
have the same list of architectures as {that package}.

E.g., pam modules should be installed on the same architectures that
need libpam0g.  Thus, all architectures for which you've installed at
least one daemon that uses pam, will have the same plugins.

The same argument works for many other plugin situations I can think
of; in each case there's a (presumably M-A: same) "base" library
package that you could say, if that package is installed for a given
arch, the associated modules should match.

Package: libpam-fprint
Multi-Arch: same-as libpam0g

Package: gimp-texturize
Multi-Arch: same-as libgimp2.0

Package: libsasl2-modules
Multi-Arch: same-as libsasl2-2

-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120214053211.gc2...@p12n.org

Multiarch file overlap summary and proposal (was: Summary: dpkg shared / reference counted files and version match)

[Russ Allbery]

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 Langasek  writes:

> I guess we're looking at the same data, yet we seem to have reached
> opposite conclusions.

>  - Riku reports that 33 out of 82k files have different compression when
>using current gzip vs. 10-year-old gzip.  I'd be surprised if any of
>those binary packages hadn't been superseded long ago.  It's not a
>guarantee, but I think the risks, and ultimate cost, of relying on gzip
>output to not change often and to just do sourceful rebuilds when it
>isn't are a lot smaller than if we go about manually splitting our
>packages further.

>  - The cases where gzip output has been reported to not be reproducible
>seem to all boil down to a single issue with gzip being passed
>different arguments due to the unreproducible nature of *find*'s
>output.  A patch has been made available already on the bug, and this
>patch seems to address the instances of the problem that we've hit so
>far in the Ubuntu archive.

> Now, it's worth following up with gzip upstream about our concerns, but
> even without that, I just don't see this being problematic.

It isn't the end of the world if we have some conflicts provided that we
can detect them and can do something consistent to fix them.  I'm rather
nervous about relying on reproducibility of gzip because of Joey's
experience with pristine-tar, where he does find a lot of variation in
practice, but it is true that, for the purposes of multiarch, Debian *can*
possibly construct things such that we only need to worry about our own
gzip, which does simplify the situation.

However, as we've subsequently discussed, those are not the only issues
with file overlaps between packages.  So I'm going to try to summarize and
propose some possible solutions for the different issues.  I'm going to
discuss these issues in order from the most consistent with a refcounting
solution to the least consistent.

1. Uncompressed files that we know are absolutely identical between
   different architectures.  These include arch-independent header files
   that are just copied verbatim from the upstream source and data files
   in textual formats or arch-independent binary formats that aren't
   compressed and whose generation doesn't vary.  (Symlinks are a special
   case of this.)  Reference counting works great for these.  These also
   resolve most of the file overlaps between -dev packages, and many of
   the harder cases for interpackage dependencies if we split everything
   out.  I think it makes a lot of sense to use refcounting for these
   files.

2. Files like the above but that are compressed.  This is most common in
   the doc directory for things like README or the upstream changelog.
   Upstream man pages written directly in *roff fall into this category as
   well, for -dev packages.  With Steve's point above about gzip, I think
   we're probably okay using refcounting for this as well.

3. Generated documentation.  Here's where I think refcounting starts
   failing.  Man pages generated from POD may change if the version of
   Perl used to generate them changes, if Pod::Simple or Pod::Man have had
   a new release.  Doxygen-generated HTML documentation is even more
   likely to change.  Many documentation generation systems will include
   timestamps or other information that changes, or (even more likely)
   will have minor changes in their output and formatting even if there is
   nothing as obvious as a version number or timestamp.

   I don't think we can use refcounting for generated documentation
   produced as part of the package build process.  If there is
   Doxygen-generated documentation, generated man pages, or the like, I
   think those have to be split into a separate arch: all package.  Even
   if it's just a couple of man pages.  This is rather annoying, but I
   think trying to use refcounting here is just too fragile.

4. Lintian overrides.  I believe these should be qualified with the
   architecture on any multiarch: same package so that the overrides can
   vary by architecture, since this is a semi-frequent use case for
   Lintian.

5. Data files that vary by architecture.  This includes big-endian
   vs. little-endian issues.  These are simply incompatible with multiarch
   as currently designed, and incompatible with the obvious variations
   that I can think of, and will have to either be moved into
   arch-qualified directories (with corresponding patches to the paths
   from which the libraries load the data) or these packages can't be made
   multiarch.

6. Debian changelogs.  The actual content of these files change with
   binNMUs, so these obviously can't be refcounted at all right now.  We
   have to do 

Re: Multiarch file overlap summary and proposal (was: Summary: dpkg shared / reference counted files and version match)

[Raphael Hertzog]

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.

Thanks for this.

> 2. Files like the above but that are compressed.  This is most common in
>the doc directory for things like README or the upstream changelog.
>Upstream man pages written directly in *roff fall into this category as
>well, for -dev packages.  With Steve's point above about gzip, I think
>we're probably okay using refcounting for this as well.

Yes, but I would still document at the policy level that, when feasible
without downsides, it's best to move compressed files in a shared package.

Also it might be wise to relax the policy rules on compression for
multi-arch: same and to let dh_compress not compress (some) files in such
packages.

> Does this seem comprehensive to everyone?  Am I missing any cases?

It's a good summary, yes.

> If this is comprehensive, then I propose the following path forward, which
> is a mix of the various solutions that have been discussed:

I agree with this plan.

> * The binNMU process is changed to add the binNMU changelog entry to an
>   arch-qualified file (changelog.Debian.arch, probably).  We need to
>   figure out what this means if the package being binNMU'd has a
>   /usr/share/doc/ symlink to another package, though; it's not
>   obvious what to do here.

I wonder what's the proper way to handle this. In theory, it would be nice
to deal with that at the dpkg-dev level but dpkg-dev is not at all
involved in installing the changelog. And I believe that the bin-nmu
process just adds a top-level entry to debian/changelog.

So the code should go to dh_installchangelogs... but it doesn't seem to be
a good idea to put the bin-nmu logic there in particular since we might
extend it (see #440094).

Somehow my suggestion is then to extend dpkg-parsechangelog to provide
the required logic to split the changelog in its bin-nmu part and its
usual content.

dpkg-parsechangelog --split-binnmu  

Then dh_installchangelogs could try to use this (and if it fails, fallback
to the standard changelog installation).

Does that sound sane? If yes, I can have a look at implementing this.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120214073923.ga...@rivendell.home.ouaza.com