Re: Static libraries in development packages

[Steve M. Robbins]

> As I've come to understanding, nowadays many libraries doesn't allow
> trivial static linkage,

I don't follow; it's generally as simple as using -static on
the link line.  Pretty trivial.


> and that it's generally not recommended to
> link statically in packages.

That is completely separate from the question of whether Debian should
provide static libraries for users to link with.  I don't see that it
should have any bearing.


> Thus I think we should consider updating the policy to either
> specify that a development package should provide a static library
> if possible,

I agree with this sentiment.


-Steve


signature.asc
Description: Digital signature

Re: Default size limits for /run (/var/run) and /run/lock (/var/lock)

[Josselin Mouette]

Le mercredi 13 avril 2011 à 10:51 +0100, Philip Hands a écrit : 
> Therefore, in the multi-partition setup, I think we should also default
> to having /tmp on tmpfs.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=245465

-- 
 .''`.  Josselin Mouette
: :' :
`. `'  “If you behave this way because you are blackmailed by someone,
  `-[…] I will see what I can do for you.”  -- Jörg Schilling



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

Re: Question about the version of debian

[Josselin Mouette]

Le mercredi 13 avril 2011 à 14:02 +0100, Ben Hutchings a écrit : 
> On Wed, 2011-04-13 at 20:47 +0800, YANG,Chao wrote:
> > dpkg --print-architecture shows
> > i386.
> > 
> > However, uname -a shows
> > x86-64
> > 
> > what does this mean?
> 
> It means Asias He was right.  And this is a perfectly valid
> configuration (though it confuses some third-party installers).
> 
> But I think this is a bug in the configuration of the CD/DVD creation:
> the amd64 flavour is on DVD 1 but the 686-bigmem flavour is on DVD 2.
> The latter definitely should be on DVD 1 (and CD 1 or 2, rather than CD
> 10!).

How is that a problem? An overwhelming majority of CPUs today are amd64,
and even if you choose to install a i386 userland (there are various
good reasons for that), you still want an amd64 kernel to benefit of all
your CPU can offer.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'  “If you behave this way because you are blackmailed by someone,
  `-[…] I will see what I can do for you.”  -- Jörg Schilling



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

Re: Default size limits for /run (/var/run) and /run/lock (/var/lock)

[Goswin von Brederlow]

Roger Leigh  writes:

> On Fri, Apr 15, 2011 at 04:41:56PM +0200, Goswin von Brederlow wrote:
>> Roger Leigh  writes:
>> 
>> > If it wasn't already clear, having /tmp as a tmpfs is a
>> > /configurable option/, and it is /not/ the default (except when
>> > root is read-only (ro) in fstab).
>> 
>> I hope you check the fstab first. If there is a entry for a non tmpfs
>> /tmp filesystem then that should be used. I'm assuming you do but just
>> to be sure...
>
> No, we don't check.  It's up to the admin to configure their
> system properly.  If there is an entry in in fstab, it'll be
> mounted on top of the tmpfs, so the system will be configured
> the way they asked, but there will be a hidden tmpfs mount.
> But they would have explicitly needed to set RAMTMP=yes to get
> into this situation.
>
> For new installs, where the default /etc/default/rcS files does
> set RAMTMP=yes by default, the fstab file will not yet contain
> any user-specific mounts.  If they do want to manuall mount
> something on /tmp, then they simply set RAMTMP=no.
>
> Note this behaviour is exactly the same as existing practice for
> /dev/shm, /var/run and /var/lock.

Then I don't get your 'is /not/ the default (except when root is
read-only (ro) in fstab)'.

To me that reads like you will mount a tmpfs on /tmp if root is
read-only even if RAMTMP is not set. Which is wrong if the system has a
/tmp filesystem in /etc/fstab.

I already have a tmpfs for /tmp in my /etc/fstab and my root is
read-only. Does that then mean I do get 2 tmpfs mounted for /tmp, one
over the other?

Also mount -a (in mountall.sh) fails, and therefore the whole boot, if a
mountpoint already has something else mounted. If you unconditionally
mount a tmpfs on /tmp if root is read-only then you just made systems
unbootable that have /tmp in fstab. You do not get the behaviour you
describe above.

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/87oc464pie.fsf@frosties.localnet

Re: Static libraries in development packages

[Andreas Metzler]

Steve M. Robbins  wrote:
>> As I've come to understanding, nowadays many libraries doesn't allow
>> trivial static linkage,

> I don't follow; it's generally as simple as using -static on
> the link line.  Pretty trivial.
[...]

Unless your are trying to link against a library that uses other
libraries ...

cu andreas


-- 
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/s4un78-r4s@argenau.downhill.at.eu.org

Re: Static libraries in development packages

[Goswin von Brederlow]

"Steve M. Robbins"  writes:

>> As I've come to understanding, nowadays many libraries doesn't allow
>> trivial static linkage,
>
> I don't follow; it's generally as simple as using -static on
> the link line.  Pretty trivial.

Which a) might not be simple to get the build system to do and b) is far
from enough to build a static library.

The problem here is having all the library packages ship the libfoo.a
files in their libfoo-dev packages. Not compiling a static binary once
you have those.

>> and that it's generally not recommended to
>> link statically in packages.
>
> That is completely separate from the question of whether Debian should
> provide static libraries for users to link with.  I don't see that it
> should have any bearing.

I think the better question is wether static linking even works at
all?

There are many libraries that use plugins, most importantly libc6. The
probability that you invoke one of the plugin functions in libc6 in any
non trivial programm is high and then the static binary crashes and
burns if the dynamic libc6 on the system is incompatible.  And if the
dynamic libc6 on the system is compatible then why would you ever want
to link it static?

Static linking of libc6 basically never makes sense. The same can be
said for many other libs.


On the other hand, even assuming the build system supports a static lib,
building a static lib means building the library twice. That complicates
the rules file and packaging. It also increases package size.

>> Thus I think we should consider updating the policy to either
>> specify that a development package should provide a static library
>> if possible,
>
> I agree with this sentiment.
>
>
> -Steve

Given the cost that involves and that nobody has screamed about it in
the last 10 years I would opt for rephrasing it to "as needed". The
would reflect the current practice best.

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/87k4eu4oll.fsf@frosties.localnet

Re: /run support for wheezy: final (I hope) call for testing

[Lars Wirzenius]

On pe, 2011-04-15 at 21:58 -0300, Henrique de Moraes Holschuh wrote:
> Symlinks in system path components REALLY are best avoided.

Out of curiosity: why?

-- 
Blog/wiki/website hosting with ikiwiki (free for free software):
http://www.branchable.com/


-- 
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/1302941257.2921.74.ca...@havelock.liw.fi

Bug#622968: ITP: libcitygml -- a small and easy to use C++ library for parsing CityGML files

[YunQiang Su]

Package: wnpp
Severity: wishlist
Owner: YunQiang Su 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


* Package name: libcitygml
  Version : 0.1.4
  Upstream Author : jpouder...@gmail.com
* URL : http://code.google.com/p/libcitygml/
* License : LGPL
  Programming Lang: C++
  Description : a small and easy to use C++ library for parsing CityGML 
files

CityGML (City Geography Markup Language) is an XML-based schema for the 
modelling and exchange of georeferenced 3D city and landscape models that is 
quickly being adopted on an international level.

libcitygml is a small and easy to use open source C++ library for parsing 
CityGML files in such a way that data can be easily exploited by 3D rendering 
applications (geometry data are tesselated and optimized for rendering during 
parsing). For instance, it can be used to develop readers of CityGML files in 
many 3D based applications (OpenGL, OpenSceneGraph, ...) Most metadata are not 
lost, they are available through a per-node hashmap.

libcitygml is developed by the 3D team of BRGM (the French leading public 
institution involved in the Earth Science field for the sustainable management 
of natural resources and surface and subsurface risks) for the research project 
DeepCity3D.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBCAAGBQJNqV/OAAoJEGqO9vovZQkSBXcIALP7SMW2+EbaulqkYe2FYzdS
GsMRBaGInxw+DBkcCfArNdBj9W1NR06DXjaMquS6Hm+BSVt9x7StS8Lzq2cRLIZG
GEDMVzuolde6TRWCNmrNQcHiHFa6VrQnBoLAGHDKLZh/0GqHf0gzPWHDunFyED4o
my+0LQO9Uo7AswoVe1rFZ5/TB+6vs7mQo72wrs0t/oUMSCs6j0z8sQxTXj2YQr7r
SrDTprkTsCxuMg1K5GdpC1l3kF4EanVCN7X0efIGtmwHcjWvJBlJhjOwTV0mbYwg
MF5oHZg4hnT+rzOE6gutBhdI6onczFiTMI/uW3p0xc5uGzF9G/LhlZcJ9ahGAL8=
=Nu6x
-END PGP SIGNATURE-



-- 
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/2011041609.15501.93095.reportbug@localhost6

Re: Default size limits for /run (/var/run) and /run/lock (/var/lock)

[Roger Leigh]

On Sat, Apr 16, 2011 at 09:35:53AM +0200, Goswin von Brederlow wrote:
> Roger Leigh  writes:
> 
> > On Fri, Apr 15, 2011 at 04:41:56PM +0200, Goswin von Brederlow wrote:
> >> Roger Leigh  writes:
> >> 
> >> > If it wasn't already clear, having /tmp as a tmpfs is a
> >> > /configurable option/, and it is /not/ the default (except when
> >> > root is read-only (ro) in fstab).
> >> 
> >> I hope you check the fstab first. If there is a entry for a non tmpfs
> >> /tmp filesystem then that should be used. I'm assuming you do but just
> >> to be sure...
> >
> > No, we don't check.  It's up to the admin to configure their
> > system properly.  If there is an entry in in fstab, it'll be
> > mounted on top of the tmpfs, so the system will be configured
> > the way they asked, but there will be a hidden tmpfs mount.
> > But they would have explicitly needed to set RAMTMP=yes to get
> > into this situation.
> >
> > For new installs, where the default /etc/default/rcS files does
> > set RAMTMP=yes by default, the fstab file will not yet contain
> > any user-specific mounts.  If they do want to manuall mount
> > something on /tmp, then they simply set RAMTMP=no.
> >
> > Note this behaviour is exactly the same as existing practice for
> > /dev/shm, /var/run and /var/lock.
> 
> Then I don't get your 'is /not/ the default (except when root is
> read-only (ro) in fstab)'.
> 
> To me that reads like you will mount a tmpfs on /tmp if root is
> read-only even if RAMTMP is not set. Which is wrong if the system has a
> /tmp filesystem in /etc/fstab.

This is a good point.  I've added the ability to detect if a
filesystem will be mounted, and skip the tmpfs mount on /tmp if
an entry for /tmp exists in fstab (will_mount in
/lib/init/mount-functions.sh)

> Also mount -a (in mountall.sh) fails, and therefore the whole boot, if a
> mountpoint already has something else mounted. If you unconditionally
> mount a tmpfs on /tmp if root is read-only then you just made systems
> unbootable that have /tmp in fstab.

This is not correct.  Have you actually tried it?  I have, and other
than the cosmetic issue of having a real filesystem mounted over the
top of the tmpfs, the system is entirely functional, and boots error
free.  And with the above change, even this cosmetic issue is gone.


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.


signature.asc
Description: Digital signature

Re: /run support for wheezy: final (I hope) call for testing

[Roger Leigh]

On Fri, Apr 15, 2011 at 09:58:58PM -0300, Henrique de Moraes Holschuh wrote:
> On Sat, 16 Apr 2011, Roger Leigh wrote:
> > On Fri, Apr 15, 2011 at 08:59:01PM -0300, Henrique de Moraes Holschuh wrote:
> > > On Fri, 15 Apr 2011, Roger Leigh wrote:
> > > > { find var/run/  ! -type d -print0; \
> > > >   find var/lock/ ! -type d -print0; } | xargs -0r $_CHROOT_SH rm
> > > > 
> > > > I'm afraid this will need fixing in util-vserver(?) though.  We can't
> > > > work around this in initscripts postinst, I'm afraid, since it worked
> > > > correctly, and this happened after the migration.
> > > 
> > > The proper fix would be to use bind mounts, or always use multiple tmpfs
> > > (which is safer, anyway).
> > 
> > We have now fixed this issue by never moving /var/run or /var/lock
> > in postinst.  In the case of a chroot/vserver, we simply create a
> > symlink from the new location (/run) to the old (/var/run) so that
> > both paths are functional.  In consequence, /var/run and /var/lock
> > will remain directories in a vserver environment.
> 
> Now, scripts that work outside of vservers and want /run might croak when
> run inside a vserver.

Why would they?  In both situations, /run, /run/lock and /run/shm
are all valid paths, be they real directories or symlinks.  In the
postinst and init scripts, we've taken care to ensure that the old
and new paths are valid (and the same) in all circumstances.

> We CAN afford four tmpfs in the first place, */run and */lock can be very
> strictly limited (e.g. 10MB-100MB), so even in a bug/local attack scenario,
> they are not a large problem.  And that's only needed if bind mounts are
> really such an horrible alternative in the first place (are they?).

On a host system, we can bind mount /run on /var/run and /run/lock
on /var/lock easily enough.  We already do this if we can't create a
symlink.  But a symlink works just as well, and is less likely to
result in inconsistency if the original directory is replaced with
another mount, unmounted, or otherwise changed (mount options).
Since it's just a pointer, it doesn't itself hold separate state,
which a bind mount does (given that they are independent vfsmounts).

On a guest system, we can never use bind mounts: rcS is either not
run, might run, or is replaced by other scripts, so we have to set
up the symlinks in postinst.  If we used bind mounts in postinst
they would be lost and never recreated on system restart.  Symlinks
are the only reliable choice here.


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.


signature.asc
Description: Digital signature

Bug#622972: ITP: qonjugator -- Qonjugator conjugates verbs in different languages

[Filippo Rusconi]

Package: wnpp
Severity: wishlist
Owner: Filippo Rusconi 


* Package name: qonjugator
  Version : 0.17
  Upstream Author : Glad Deschrijver 
* URL : 
http://qt-apps.org/content/show.php/Qonjugator?content=112575
* License : GPL
  Programming Lang: C++
  Description : Qonjugator conjugates verbs in different languages
 The program allows one to conjugate verbs in a number of
 languages. The architecture of the software is plugin-based so that
 conjugation rules for new languages can be added with new plugins.
 .
 The software is made of the following components:
 - a library which loads the conjugation plugins for the different
   languages and which does the actual conjugation;
 - a GUI in which the user can conjugate verbs, the GUI uses the library;
 - a command-line interface;
 - modules for French, Spanish and Italian;
 - a plasmoid that can be used in KDE 4.x or later;
 - a QML application.



-- 
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/20110416095526.4762.22359.report...@licorne.clio.u-psud.fr

Re: Static libraries in development packages

[Russell Coker]

On Sat, 16 Apr 2011, Goswin von Brederlow  wrote:
> Static linking of libc6 basically never makes sense. The same can be
> said for many other libs.

Yes, static linking of libc6 is a corner case that makes entirely statically 
linked programs a bad idea.  However mostly statically linked programs make a 
lot of sense in some situations.

After Lenny was released I developed fixes for a number of serious library 
bugs that caused an important application written for one of my clients to 
crash.  As some of the deployment platforms couldn't be guaranteed to have the 
patched versions of the libraries without extreme effort (due to customers 
having some interesting procedures for determining which updates were applied) 
the easiest solution was to statically link every library that needed a patch.

I could have done that static linking without help from the DD in question 
(making my own static libraries under /usr/local isn't THAT hard).  But the 
result is better if you can modify build-depends and just use static libraries 
that come as part of the package.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/


-- 
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/201104162025.52648.russ...@coker.com.au

Re: Default size limits for /run (/var/run) and /run/lock (/var/lock)

[Philip Hands]

On Sat, 16 Apr 2011 09:17:04 +0200, Josselin Mouette  wrote:
> Le mercredi 13 avril 2011 à 10:51 +0100, Philip Hands a écrit : 
> > Therefore, in the multi-partition setup, I think we should also default
> > to having /tmp on tmpfs.
> 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=245465

Ah, good point -- so rather than just chatting about this I should
probably get off my arse and start making some sort of contribution to
d-i.

I'll test your patch.

Cheers, Phil.
-- 
|)|  Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/
|-|  HANDS.COM Ltd.http://www.uk.debian.org/
|(|  10 Onslow Gardens, South Woodford, London  E18 1NE  ENGLAND


pgp3SdiDFr41A.pgp
Description: PGP signature

Only forbid use of old alternatives to /run in wheezy+1?

[Thomas Hood]

While I applaud the introduction of /run, I have some concerns about
how quickly users of alternatives to /run could be required to switch
to the new location.

Consider the following scenario.

Package P is using /lib/init/rw.  At some point the new version of
initscripts is installed.  The latter's postinst makes /run available,
initially as a bind mount of /var/run, post-reboot as a separate tmpfs.
OK.  But P has not been updated yet; it is still using /lib/init/rw.  So
initscripts's postinst certainly can't remove /lib/init/rw immediately.
What if the latter merely arranges for the removal of /lib/init/rw
after the next reboot?  Then if the admin reboots, P is broken after
the reboot until it gets upgraded.  But if P is some kind of infrastructure
package then its breakage could cause the administrator anguish.
Note that P's maintainer can't do anything about this problem because
it is the squeeze version of P that gets broken.  The squeeze version
of P simply didn't expect that /lib/init/rw would suddenly disappear.

I suppose the new initscripts could Conflict with P in order to force
upgrade of P at the same time as initscripts; but this makes the
upgrade process more rigid and fragile.  If the upgrade fails for one
reason or another after initscripts has been installed then, again, P
is broken after reboot until it gets upgraded.  But does the system
still have access to the network?

I think that P should be allowed to continue using /lib/init/rw at
least until the wheezy version of its postinst runs.

But this occurs after initscripts's postinst runs.  And that is the last
chance initscripts has to eliminate /lib/init/rw in wheezy.  So I
conclude that initscripts should only eliminate /lib/init/rw in
wheezy+1.
-- 
Thomas Hood


-- 
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/banlktikb9w+-mirnnceykt1z2wk01tm...@mail.gmail.com

Re: Bug#622922: ITP: apparmor -- AppArmor Mandatory Access Control system userspace tools

[Philipp Kern]

On 2011-04-15, Kees Cook  wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Kees Cook 
>
> * Package name: apparmor
>   Version : 2.6.1
>   Upstream Author : AppArmor project members
> * URL : http://apparmor.net/
> * License : GPL-2, LGPL-2
>   Programming Lang: C, C++, Perl, Python
>   Description : AppArmor Mandatory Access Control system userspace tools
>
> This provides the AppArmor userspace tools, including initialization scripts,
> needed to use the AppArmor Mandatory Access Control system. Additionally 
> includes
> documentation and SWIG bindings for the AppArmor libraries.

Will we get it turned on in the stock kernel?  Last time I looked that was
refused because it eats RAM to have it available but not turned on.

Kind regards
Philipp Kern


-- 
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/slrniqiulq.36f.tr...@kelgar.0x539.de

Bug#622982: ITP: naev-data -- 2D space trading combat game

[Vincent Cheng]

Package: wnpp
Severity: wishlist
Owner: Vincent Cheng 


* Package name: naev-data
  Version : 0.4.2
  Upstream Author : Edgar Simo "bobbens" 
 Nikola Whallon <6.satur...@gmail.com>
 Josiah Schwartfeger
Deiz
Bas Fournier "BTAxis" 
* URL : http://code.google.com/p/naev/
* License : code - GPL-3 ; data - public domain,
  GPLv2, GPLv3, CC-By (and -SA) 3.0
  Programming Lang: C, Lua
  Description : 2D space trading combat game

 NAEV is a 2D space trading and combat game, in a similar
 vein to Escape Velocity.

 NAEV is played from a top-down perspective, featuring fast-paced combat,
 many ships and outfits, and a large galaxy to explore. The game is highly
 open-ended, letting players proceed at their own paces.

 This package contains the data files for Naev.

(For reference, #609295 is my ITP for Naev itself.)



-- 
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/20110416111615.724.34673.reportbug@vincent-laptop

Re: Default size limits for /run (/var/run) and /run/lock (/var/lock)

[rleigh]

On Sat, Apr 16, 2011 at 11:31:08AM +0100, Philip Hands wrote:
> On Sat, 16 Apr 2011 09:17:04 +0200, Josselin Mouette  wrote:
> > Le mercredi 13 avril 2011 à 10:51 +0100, Philip Hands a écrit : 
> > > Therefore, in the multi-partition setup, I think we should also default
> > > to having /tmp on tmpfs.
> > 
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=245465
> 
> Ah, good point -- so rather than just chatting about this I should
> probably get off my arse and start making some sort of contribution to
> d-i.

By the way, now that initscripts has support for mounting tmpfs
on /tmp, all d-i needs to do is to set RUNTMP=yes when creating
/etc/default/rcS (it already needs to do this for UTC).  It
might also want to allow adjustment of the size set in
/etc/default/tmpfs and ensure there's sufficient swap space
configured, but it shouldn't actually require any fstab changes.
(Though the mount logic should let it pick up the mount options
from /etc/fstab, if present.)


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/20110416110822.gb13...@codelibre.net

Re: Only forbid use of old alternatives to /run in wheezy+1?

[rleigh]

On Sat, Apr 16, 2011 at 12:39:03PM +0200, Thomas Hood wrote:
> While I applaud the introduction of /run, I have some concerns about
> how quickly users of alternatives to /run could be required to switch
> to the new location.
> 
> Consider the following scenario.
> 
> Package P is using /lib/init/rw.  At some point the new version of
> initscripts is installed.  The latter's postinst makes /run available,
> initially as a bind mount of /var/run, post-reboot as a separate tmpfs.
> OK.  But P has not been updated yet; it is still using /lib/init/rw.  So
> initscripts's postinst certainly can't remove /lib/init/rw immediately.
> What if the latter merely arranges for the removal of /lib/init/rw
> after the next reboot?  Then if the admin reboots, P is broken after
> the reboot until it gets upgraded.  But if P is some kind of infrastructure
> package then its breakage could cause the administrator anguish.
> Note that P's maintainer can't do anything about this problem because
> it is the squeeze version of P that gets broken.  The squeeze version
> of P simply didn't expect that /lib/init/rw would suddenly disappear.

/lib/init/rw isn't going to just disappear without coping with this
scenario.  Given the low number of users of /lib/init/rw, it's quite
possible that we can just add a list of Breaks: P (<< fixed-version)
for each of the packages concerned (where fixed-version is the
version which switches to /run).  This will ensure they are all using
/run before we remove /lib/init/rw.

We haven't made any plans to remove it yet.  We'll look more closely
at the best way to do that once all the users are moved over.  Given
the small number, it's quite likely this won't take very long.  If
it turns out that there are other users of /lib/init/rw, it's not a
problem keeping it around for wheezy.  But if there aren't, there's
no need to retain it.

If there is a cleaner method than using versioned Breaks, I'm sure we
can look at that instead--nothing concrete is planned yet for the
removal, so all suggestions are welcome.


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/20110416112132.gc13...@codelibre.net

Re: Static libraries in development packages

[Steve M. Robbins]

On Sat, Apr 16, 2011 at 09:55:34AM +0200, Goswin von Brederlow wrote:
> "Steve M. Robbins"  writes:
> 
> >> As I've come to understanding, nowadays many libraries doesn't allow
> >> trivial static linkage,
> >
> > I don't follow; it's generally as simple as using -static on
> > the link line.  Pretty trivial.
> 
> Which a) might not be simple to get the build system to do and b) is far
> from enough to build a static library.

I see that we read the original comment differently.  I was reacting
to the claim "libraries can't be LINKED TO statically".  You read it
as "libraries can't be BUILT statically".

With your reading, I agree that it's not *always* possible.  At the 
end of my remarks, I agreed with the statement

A development package should provide a static library 
*if possible*.


> >> and that it's generally not recommended to
> >> link statically in packages.
> >
> > That is completely separate from the question of whether Debian should
> > provide static libraries for users to link with.  I don't see that it
> > should have any bearing.
> 
> I think the better question is wether static linking even works at
> all?
> 
> There are many libraries that use plugins, most importantly libc6. The
> probability that you invoke one of the plugin functions in libc6 in any
> non trivial programm is high and then the static binary crashes and
> burns if the dynamic libc6 on the system is incompatible.  And if the
> dynamic libc6 on the system is compatible then why would you ever want
> to link it static?
> 
> Static linking of libc6 basically never makes sense. The same can be
> said for many other libs.

Possibly that's true for many libraries, but surely not all of them.


> On the other hand, even assuming the build system supports a static lib,
> building a static lib means building the library twice. That complicates
> the rules file and packaging. It also increases package size.

Our priorities are our users.  

There are many things that complicate life for a packager, but are
important to do because they benefit our users.


> >> Thus I think we should consider updating the policy to either
> >> specify that a development package should provide a static library
> >> if possible,
> >
> > I agree with this sentiment.
> >
> >
> > -Steve
> 
> Given the cost that involves and that nobody has screamed about it in
> the last 10 years I would opt for rephrasing it to "as needed". The
> would reflect the current practice best.

I don't accept either of your premises.  

For my part, I haven't surveyed our users to understand how important
static linking is.  However, I do know of communities that routinely
build static binaries in order to guarantee reproducibility of data
analysis results over time -- part of the so-called Reducible Research
movement [1].

Secondly, in my packaging of libraries -- including the monstrous
Boost -- I supply static libs whereever possible, not "as needed".
This is how I've always read the current policy and I believe that
phrase best reflects current practice.

Regards,
-Steve

[1] http://www.rrplanet.com/reproducible-research-librum/


signature.asc
Description: Digital signature

Re: Static libraries in development packages

[Tollef Fog Heen]

]] Russell Coker 

Hi,

| After Lenny was released I developed fixes for a number of serious library 
| bugs that caused an important application written for one of my clients to 
| crash.  As some of the deployment platforms couldn't be guaranteed to have 
the 
| patched versions of the libraries without extreme effort (due to customers 
| having some interesting procedures for determining which updates were 
applied) 
| the easiest solution was to statically link every library that needed a patch.

Wouldn't just shipping known-good dynamic libs and linking with rpath
and $ORIGIN be much simpler?  As a bonus, it makes it a) possible to
update the libraries if the admin wants to and b) it makes it clear what
libraries your binary depends on, without having to pull apart the
binary and guess.

Cheers,
-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
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/87tydy44k4@qurzaw.varnish-software.com

Re: Question about the version of debian

[Ben Hutchings]

On Sat, 2011-04-16 at 09:19 +0200, Josselin Mouette wrote:
> Le mercredi 13 avril 2011 à 14:02 +0100, Ben Hutchings a écrit : 
> > On Wed, 2011-04-13 at 20:47 +0800, YANG,Chao wrote:
> > > dpkg --print-architecture shows
> > > i386.
> > > 
> > > However, uname -a shows
> > > x86-64
> > > 
> > > what does this mean?
> > 
> > It means Asias He was right.  And this is a perfectly valid
> > configuration (though it confuses some third-party installers).
> > 
> > But I think this is a bug in the configuration of the CD/DVD creation:
> > the amd64 flavour is on DVD 1 but the 686-bigmem flavour is on DVD 2.
> > The latter definitely should be on DVD 1 (and CD 1 or 2, rather than CD
> > 10!).
> 
> How is that a problem? An overwhelming majority of CPUs today are amd64,
> and even if you choose to install a i386 userland (there are various
> good reasons for that), you still want an amd64 kernel to benefit of all
> your CPU can offer.

There are compatibility issues with third-party scripts that rely on
'uname -m' to select which architecture to use in userland.  And there
are still a few places where 32-bit compatibility wrappers are missing
in the kernel.  Personally, I do use this combination, but I'm not ready
to recommend it in general.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


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

Re: Bug#622922: ITP: apparmor -- AppArmor Mandatory Access Control system userspace tools

[Ben Hutchings]

On Sat, 2011-04-16 at 11:17 +, Philipp Kern wrote:
> On 2011-04-15, Kees Cook  wrote:
> > Package: wnpp
> > Severity: wishlist
> > Owner: Kees Cook 
> >
> > * Package name: apparmor
> >   Version : 2.6.1
> >   Upstream Author : AppArmor project members
> > * URL : http://apparmor.net/
> > * License : GPL-2, LGPL-2
> >   Programming Lang: C, C++, Perl, Python
> >   Description : AppArmor Mandatory Access Control system userspace tools
> >
> > This provides the AppArmor userspace tools, including initialization 
> > scripts,
> > needed to use the AppArmor Mandatory Access Control system. Additionally 
> > includes
> > documentation and SWIG bindings for the AppArmor libraries.
> 
> Will we get it turned on in the stock kernel?  Last time I looked that was
> refused because it eats RAM to have it available but not turned on.

I'm (slowly) working on a way to build in all LSMs and then free memory
for those that aren't used.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


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

Re: Question about the version of debian

[Mike Hommey]

On Sat, Apr 16, 2011 at 04:09:45PM +0100, Ben Hutchings wrote:
> On Sat, 2011-04-16 at 09:19 +0200, Josselin Mouette wrote:
> > Le mercredi 13 avril 2011 à 14:02 +0100, Ben Hutchings a écrit : 
> > > On Wed, 2011-04-13 at 20:47 +0800, YANG,Chao wrote:
> > > > dpkg --print-architecture shows
> > > > i386.
> > > > 
> > > > However, uname -a shows
> > > > x86-64
> > > > 
> > > > what does this mean?
> > > 
> > > It means Asias He was right.  And this is a perfectly valid
> > > configuration (though it confuses some third-party installers).
> > > 
> > > But I think this is a bug in the configuration of the CD/DVD creation:
> > > the amd64 flavour is on DVD 1 but the 686-bigmem flavour is on DVD 2.
> > > The latter definitely should be on DVD 1 (and CD 1 or 2, rather than CD
> > > 10!).
> > 
> > How is that a problem? An overwhelming majority of CPUs today are amd64,
> > and even if you choose to install a i386 userland (there are various
> > good reasons for that), you still want an amd64 kernel to benefit of all
> > your CPU can offer.
> 
> There are compatibility issues with third-party scripts that rely on
> 'uname -m' to select which architecture to use in userland.

Is there a compelling reason for init not to set the right personality?

Mike


-- 
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/20110416152113.ga13...@glandium.org

Bug#623016: ITP: python-tidylib -- Python wrapper for HTML Tidy (tidylib)

[Janos Guljas]

Package: wnpp
Severity: wishlist
Owner: Janos Guljas 

* Package name: python-tidylib
  Version : 0.2.1
  Upstream Author : Jason Stitt 
* URL : http://countergram.com/open-source/pytidylib/
* License : MIT/X11 (BSD like)
  Programming Lang: Python
  Description : Python wrapper for HTML Tidy (tidylib)

 PyTidyLib is a Python package that wraps the HTML Tidy library. This
 allows you, from Python code, to “fix” invalid (X)HTML markup. Some
 of the library’s  many capabilities include:

  * Clean up unclosed tags and unescaped characters such as ampersands
  * Output HTML 4 or XHTML, strict or transitional, and add missing
doctypes
  * Convert named entities to numeric entities, which can then be used
in XML documents without an HTML doctype.
  * Clean up HTML from programs such as Word (to an extent)
  * Indent the output, including proper (i.e. no) indenting for pre
elements, which some (X)HTML indenting code overlooks.



-- 
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/20110416162959.5327.4681.report...@mac.resenje.org

Re: Only forbid use of old alternatives to /run in wheezy+1?

[Edward Allcutt]

On Sat, 16 Apr 2011, rleigh wrote:

We haven't made any plans to remove it yet.  We'll look more closely
at the best way to do that once all the users are moved over.  Given
the small number, it's quite likely this won't take very long.  If
it turns out that there are other users of /lib/init/rw, it's not a
problem keeping it around for wheezy.  But if there aren't, there's
no need to retain it.

If there is a cleaner method than using versioned Breaks, I'm sure we
can look at that instead--nothing concrete is planned yet for the
removal, so all suggestions are welcome.


I suggest:
 - on upgrade, bind mount or symlink /run/init -> /lib/init/rw
 - on boot, after mounting /run, mkdir /run/init; ln -s /run/init /lib/init/rw

Or in other words - exactly like we're handling /var/lock and /dev/shm except
without a possible separate tmpfs.

This keeps /lib/init/rw available at all times and doesn't require any
particular upgrade order. The link could be dropped in wheezy+1 but there's no
urgency to do so.

I was under the impression that this was already part of the plan, did
/run/init get dropped for some reason?

--
Edward Allcutt


--
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/alpine.deb.2.00.1104161750130.30...@pandora.retrosnub.co.uk

Re: Only forbid use of old alternatives to /run in wheezy+1?

[Roger Leigh]

On Sat, Apr 16, 2011 at 05:58:19PM +0100, Edward Allcutt wrote:
> On Sat, 16 Apr 2011, rleigh wrote:
> >We haven't made any plans to remove it yet.  We'll look more closely
> >at the best way to do that once all the users are moved over.  Given
> >the small number, it's quite likely this won't take very long.  If
> >it turns out that there are other users of /lib/init/rw, it's not a
> >problem keeping it around for wheezy.  But if there aren't, there's
> >no need to retain it.
> >
> >If there is a cleaner method than using versioned Breaks, I'm sure we
> >can look at that instead--nothing concrete is planned yet for the
> >removal, so all suggestions are welcome.
> 
> I suggest:
>  - on upgrade, bind mount or symlink /run/init -> /lib/init/rw
>  - on boot, after mounting /run, mkdir /run/init; ln -s /run/init /lib/init/rw
> 
> Or in other words - exactly like we're handling /var/lock and /dev/shm except
> without a possible separate tmpfs.
> 
> This keeps /lib/init/rw available at all times and doesn't require any
> particular upgrade order. The link could be dropped in wheezy+1 but there's no
> urgency to do so.
> 
> I was under the impression that this was already part of the plan, did
> /run/init get dropped for some reason?

It did.  The general consensus was that if we did bind mount /run/init
to /lib/init/rw on boot (and vice versa on initial install, as for the
othe locations), we would still need to transition from /run/init to
/run anyway, so we might as well transition directly from /lib/init/rw
to /run in a single shot.  This is unlike the other directories, where
the files are linked directly to their final destinations.

The number of packages making use of /lib/init/rw is tiny (33), so it
was thought that it could be removed fairly speedily as soon as the
transition can begin.  Of those, 16 use the sendsigs.d interface
(trivial mv in postinst), 3 are just documentation/examples.  The others
can also be done fairly simply, while I haven't looked at all of them,
most can simply just mv any files in their postinst (with a versioned
dependency on initscripts).


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.


signature.asc
Description: Digital signature

GRUPO CBES ENFERMAGEM DO TRABALHO (TURMA CONFIRMADAS)

[GRUPO CBES]

enfermagem









Caso não consiga visualizar a imagem CLIQUE AQUI.

Re: network-manager as default? No!

[Stephan Seitz]

On Fri, Apr 15, 2011 at 03:32:18PM +0200, Josselin Mouette wrote:
This was stated in the original proposal: ifupdown is not event-based 
and does not integrate correctly with modern boot systems.


So what? ifupdown is working on most setups without problems with VLANs 
bonds, or bridges out of the box without unnecessary dependencies and 
daemons.
Beside I am not interested in having my network reconfigured by a stupid 
daemon finding some „events”. I don’t even use event base boot systems 
(still using file-rc), because I don’t like the idea.


Sticking to this unmaintained piece of software with a design for 
systems from the 80s only leads to an increasing amount of complexity to 


This design has not changed much. Even today most systems still have the 
same configuration as they had for the last ten years. One IP address, 
one gateway and some DNS servers.


The configuration for ifupdown has become easier in the last years as 
well. In the beginning you had to script your VLAN or bond magic 
yourself, now there already exists hooks.


I certainly don’t mind having N-M in the archives. If someone wish to 
install it, he should be able to.
But I don’t want N-M as part of the base installation and handling my 
network without me choosing to do so.


Shade and sweet water!

Stephan

--
| Stephan Seitz E-Mail: s...@fsing.rootsland.net |
| PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html |


signature.asc
Description: Digital signature

Bug#623022: ITP: expeyes -- hardware & software framework for developing science experiments

[Georges Khaznadar]

Package: wnpp
Severity: wishlist
Owner: Georges Khaznadar 


* Package name: expeyes
  Version : 1.0.0
  Upstream Author : Ajith Kumar B.P 
* URL : http://expeyes.in/
* License : GPL-3
  Programming Lang: Python
  Description : hardware & software framework for developing science 
experiments

 This package provides high level interfaces for making science experiments
 with an ExpEYES box.
 .
 ExpEYES is from the PHOENIX project of Inter-University Accelerator
 Centre, New Delhi. It is a hardware & software framework for
 developing science experiments, demonstrations and projects and learn
 science and engineering by exploration. Capable of doing real time
 measurements and analysing the data in different ways. Analog
 voltages are measured with 0.025% resolution and time intervals with
 one microsecond. This project is based on Free and Open Source
 software, mostly written in Python programming language. The hardware
 design is also open.



-- 
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/20110416172759.10777.35270.report...@photos.khaznadar.fr

Re: Static libraries in development packages

[Steve Langasek]

On Sat, Apr 16, 2011 at 09:47:08AM +0200, Andreas Metzler wrote:
> Steve M. Robbins  wrote:
> >> As I've come to understanding, nowadays many libraries doesn't allow
> >> trivial static linkage,

> > I don't follow; it's generally as simple as using -static on
> > the link line.  Pretty trivial.
> [...]

> Unless your are trying to link against a library that uses other
> libraries ...

In which case, since you're using pkg-config already, all you have to do is
pass --static to pkg-config --libs too.

Still pretty trivial.  Remember that in the whole wide world of Unix
linkers, glibc is an *anomaly* in being able to recursively resolve ELF
dependencies; on most other systems, users have to construct the same sort
of commandline for *dynamic* linking as we do for static linking.  So
there's been quite a lot of effort put into making it easy to construct
these commandlines automatically (pkg-config and libtool).  libtool's method
of course has nasty side-effects for our common case that have led us to
prefer stripping out the dependency information, but pkg-config still makes
this pretty easy.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: network-manager as default? No!

[Stephan Seitz]

On Fri, Apr 15, 2011 at 03:23:32PM +0200, Josselin Mouette wrote:

NM may be good for laptops, so put it in the laptop task and leave the
rest alone in the default installation.

And keep the installer unable to do things as widespread as WPA?
And keep it unable to generate a proper configuration for laptops?


How many systems are needing WLAN for installation?
Servers don’t have WLAN, I never have seen a Desktop with WLAN (neither 
in companies nor private PCs). I only have WLAN in laptops. And since 
I only have Intel WiFi, d-i never was able to use it because I need 
non-free firmware (no fault of d-i, mind you, non-free is non-free, which 
is a part why I don’t like WLAN).


But if you think that is so important, put N-M in d-i and activate it if 
the user wants to use WLAN for installation. But don’t install it if the 
user doesn’t explicitly ask for it.


Shade and sweet water!

Stephan

--
| Stephan Seitz E-Mail: s...@fsing.rootsland.net |
| PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html |


signature.asc
Description: Digital signature

Re: Only forbid use of old alternatives to /run in wheezy+1?

[Edward Allcutt]

On Sat, 16 Apr 2011, Roger Leigh wrote:

On Sat, Apr 16, 2011 at 05:58:19PM +0100, Edward Allcutt wrote:

I suggest:
 - on upgrade, bind mount or symlink /run/init -> /lib/init/rw
 - on boot, after mounting /run, mkdir /run/init; ln -s /run/init /lib/init/rw

Or in other words - exactly like we're handling /var/lock and /dev/shm except
without a possible separate tmpfs.

This keeps /lib/init/rw available at all times and doesn't require any
particular upgrade order. The link could be dropped in wheezy+1 but there's no
urgency to do so.

I was under the impression that this was already part of the plan, did
/run/init get dropped for some reason?


It did.  The general consensus was that if we did bind mount /run/init
to /lib/init/rw on boot (and vice versa on initial install, as for the
othe locations), we would still need to transition from /run/init to
/run anyway, so we might as well transition directly from /lib/init/rw
to /run in a single shot.  This is unlike the other directories, where
the files are linked directly to their final destinations.

I see. I don't see how this can be done in a single shot though.

Let's take the example of package P which currently keeps state in
/lib/init/rw/P. It has version P1 in squeeze. For version P2 in wheezy
it aims to move that state to /run/P.

The plan is for packages that will use /run in wheezy to predepend on
initscripts (>= X).

To achieve this, P (version P2) has to Pre-Depend: initscripts (>= X).
Because initscripts intends to forcibly move /lib/init/rw/* to /run/*
you're proposing that initscripts will Breaks: P (<< P2).

I'm hoping I've misunderstood somewhere because that sure looks like
an unbreakable cycle to me...

If /run/init has been inextricably vetoed then the safe option looks
like leaving /lib/init/rw alone in wheezy and letting all relevant
packages handle their own transition to /run. If we want to try hard
to remove /lib/init/rw in wheezy+1 then we need RC bugs against
packages using it which don't safely transition away for wheezy.

--
Edward Allcutt


--
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/alpine.deb.2.00.1104161837100.30...@pandora.retrosnub.co.uk

Re: network-manager as default? No!

[Stephan Seitz]

On Wed, Apr 13, 2011 at 09:47:54PM +0200, Bjørn Mork wrote:

protocols.  I would have preferred something like some routers do:

 iface eth0
  address ..
  ipv6address ..


I think this is a very good idea, because you don’t have to duplicate 
bridge configurations. If the configuration looked like this I could live 
with the fact not being able to (de)activate one part of a dual stack 
interface.


Shade and sweet water!

Stephan

--
| Stephan Seitz E-Mail: s...@fsing.rootsland.net |
| PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html |


signature.asc
Description: Digital signature

Re: Default size limits for /run (/var/run) and /run/lock (/var/lock)

[Goswin von Brederlow]

Roger Leigh  writes:

> On Sat, Apr 16, 2011 at 09:35:53AM +0200, Goswin von Brederlow wrote:
>> To me that reads like you will mount a tmpfs on /tmp if root is
>> read-only even if RAMTMP is not set. Which is wrong if the system has a
>> /tmp filesystem in /etc/fstab.
>
> This is a good point.  I've added the ability to detect if a
> filesystem will be mounted, and skip the tmpfs mount on /tmp if
> an entry for /tmp exists in fstab (will_mount in
> /lib/init/mount-functions.sh)

Thanks.

>> Also mount -a (in mountall.sh) fails, and therefore the whole boot, if a
>> mountpoint already has something else mounted. If you unconditionally
>> mount a tmpfs on /tmp if root is read-only then you just made systems
>> unbootable that have /tmp in fstab.
>
> This is not correct.  Have you actually tried it?  I have, and other
> than the cosmetic issue of having a real filesystem mounted over the
> top of the tmpfs, the system is entirely functional, and boots error
> free.  And with the above change, even this cosmetic issue is gone.

Hmm. This is strange. I extrapolated from my experience with proc
(#603858):

/proc/mounts: (proc mounted by initramfs-tools in the ramdisk)
none on /proc type proc (rw,relatime)

fstab:
proc/proc   procdefaults0   0

# mount -v -a -t nonfs,nfs4,smbfs,cifs,ncp,ncpfs,coda,ocfs2,gfs,gfs2 -O 
no_netdev
mount: proc already mounted or /proc busy
mount: according to mtab, none is already mounted on /proc
# echo $?
32


BUT:

/proc/mounts:
none on /tmp2 type tmpfs (rw,relatime)

fstab:
tmpfs   /tmp2   tmpfs   defaults0   0

# mount -v -a -t nonfs,nfs4,smbfs,cifs,ncp,ncpfs,coda,ocfs2,gfs,gfs2 -O 
no_netdev
tmpfs on /tmp2 type tmpfs (rw)
# echo $?
0


It seems like proc is a special case that doesn't allow mounting
something over it. With tmpfs it just mounts over the old entry. Sorry
for raising the alarm.

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/87oc46dqy2.fsf@frosties.localnet

Re: Bug#622922: ITP: apparmor -- AppArmor Mandatory Access Control system userspace tools

[Joachim Wiedorn]

Ben Hutchings  wrote on 2011-04-16 16:11:

> I'm (slowly) working on a way to build in all LSMs and then free memory
> for those that aren't used.

That is a good news because I am on the way to package smack tools for
Debian.

---
Have a nice day.

Joachim (Germany)


-- 
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/20110416195823.09d9b...@jupiter.home

/run or not /run?

[Hans-J. Ullrich]

Dear maintainers, 

I am a little bit confused of the trouble with the last udev-package.

What is now debian-standard? Must I create a directory /run and make it root-
writable? Or is /run still not standard? Questions, questions, questions.

At the moment, there is no /run on my system, as it is set up many years ago 
(and of course regularly updated). I am using debian/testing (=wheezy)

Best regards

Hans



-- 
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/201104162001.06076.hans.ullr...@loop.de

Re: /run support for wheezy: final (I hope) call for testing

[Adam Borowski]

On Fri, Apr 15, 2011 at 09:58:58PM -0300, Henrique de Moraes Holschuh wrote:
> On Sat, 16 Apr 2011, Roger Leigh wrote:
> > On Fri, Apr 15, 2011 at 08:59:01PM -0300, Henrique de Moraes Holschuh wrote:
> > > On Fri, 15 Apr 2011, Roger Leigh wrote:
> > > > { find var/run/  ! -type d -print0; \
> > > >   find var/lock/ ! -type d -print0; } | xargs -0r $_CHROOT_SH rm
> > > > 
> > > > I'm afraid this will need fixing in util-vserver(?) though.  We can't
> > > > work around this in initscripts postinst, I'm afraid, since it worked
> > > > correctly, and this happened after the migration.
> > > 
> > > The proper fix would be to use bind mounts, or always use multiple tmpfs
> > > (which is safer, anyway).
> > 
> > We have now fixed this issue by never moving /var/run or /var/lock
> > in postinst.  In the case of a chroot/vserver, we simply create a
> > symlink from the new location (/run) to the old (/var/run) so that
> > both paths are functional.  In consequence, /var/run and /var/lock
> > will remain directories in a vserver environment.
> 
> Now, scripts that work outside of vservers and want /run might croak when
> run inside a vserver.

Only if the symlink says "/run".  If it leads to "../run", an outside script
will still work.

The last version I tested produced absolute ones, it might be better to make
them relative.

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


signature.asc
Description: Digital signature

Re: Static libraries in development packages

[Goswin von Brederlow]

"Steve M. Robbins"  writes:

> On Sat, Apr 16, 2011 at 09:55:34AM +0200, Goswin von Brederlow wrote:
>> Given the cost that involves and that nobody has screamed about it in
>> the last 10 years I would opt for rephrasing it to "as needed". The
>> would reflect the current practice best.
>
> I don't accept either of your premises.  
>
> For my part, I haven't surveyed our users to understand how important
> static linking is.  However, I do know of communities that routinely
> build static binaries in order to guarantee reproducibility of data
> analysis results over time -- part of the so-called Reducible Research
> movement [1].
>
> Secondly, in my packaging of libraries -- including the monstrous
> Boost -- I supply static libs whereever possible, not "as needed".
> This is how I've always read the current policy and I believe that
> phrase best reflects current practice.
>
> Regards,
> -Steve
>
> [1] http://www.rrplanet.com/reproducible-research-librum/

I'm not saying you should stop doing so. Nor am I saying that for
example glib should start shipping static libs. I'm saying the current
status should be maintained as it seems to work. The users aren't
screaming.

And that status is more one of "if you feel like it" than one of "do it
unless you see a reason not to". Imho a SHOULD in policy would be too
strong for current practice.

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/87hb9ydplf.fsf@frosties.localnet

Re: /run or not /run?

[Adam Borowski]

On Sat, Apr 16, 2011 at 08:01:05PM +0200, Hans-J. Ullrich wrote:
> Dear maintainers, 
> 
> I am a little bit confused of the trouble with the last udev-package.
> 
> What is now debian-standard? Must I create a directory /run and make it root-
> writable? Or is /run still not standard? Questions, questions, questions.

You need to Pre-Depend on initscripts >= 2.88dsf-13.3, which hasn't been
uploaded yet.

Ie, just wait, and use the old directories if you want to upload your
package now.

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


signature.asc
Description: Digital signature

Bug#623030: ITP: libjaba-client-java -- minimal client for the JABAWS server

[Vincent Fourmond]

Package: wnpp
Severity: wishlist
Owner: Vincent Fourmond 

* Package name: libjaba-client-java
  Version : 0 (versioning yet unclear)
  Upstream Author : Peter V. Troshin, James B. Procter and Geoffrey J. Barton 
* URL : http://www.compbio.dundee.ac.uk/jabaws/
* License : Apache 2.0
  Programming Lang: Java
  Description : minimal client for the JABAWS server

This package contains a library for building a client for the JABAWS
sequence alignment server. This is used by jalview.
 




-- 
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/20110416184250.22487.9466.report...@tanyaivinco.homelinux.org

Tool to sort package list in dependency order

[Rob Browning]

Do we have a tool that will sort a list of packages in dependency order?
I ask because if we have one, I'd like to use it to replace the tsort
mess in emacsen-common.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4


-- 
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/87ipuevtmk@raven.defaultvalue.org

Bug#623037: general: Usb flash drive crashes Debian

[Atanas Atanassov]

Package: general
Severity: normal

Every time when I plug a usb drive Debian crashes. The system mount the drive
successfully and crashes when I am trying to browse the folder



-- System Information:
Debian Release: 6.0.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



-- 
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/20110416205001.2884.8334.reportbug@debian.MSHOME

Re: Static libraries in development packages

[Philip Ashmore]

Hi there.

Nobody thought to mention that static linking can dramatically increase 
performance,
or to put it the other way around, dynamic linking can incur serious 
runtime penalties.


I don't want to encourage everyone to start static linking everywhere 
just to get a
few percentage points in efficiency, obviously your mileage may vary, 
but basically
my treedb project got 100 times faster and meta-treedb got at least 20 
times faster,

through static linking on x86_64.

You can get these from SourceForge.

These do little more than function calls and memory access through 
memory maps,

so maybe they're unusual in this respect.

I've yet to upload the versions (including v3c) that build static 
libraries and the

static tests, but I thought it was worth mentioning.

Philip


--
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/4daa0912.6070...@philipashmore.com

Re: Static libraries in development packages

[Philipp Kern]

On 2011-04-16, Philip Ashmore  wrote:
> Nobody thought to mention that static linking can dramatically
> increase performance, or to put it the other way around, dynamic
> linking can incur serious runtime penalties.

At the expence of more RAM in use if multiple instances of the problem
are running because the library pages can't be shared anymore.

But of course linking might make smarter decisions.

Kind regards
Philipp Kern


-- 
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/slrniqk3hp.447.tr...@kelgar.0x539.de

Re: Tool to sort package list in dependency order

[Obey Arthur Liu]

Not really what you asked but there is a GSoC project this year about
apt/dpkg ordering optimization.

Arthur
On Apr 16, 2011 4:27 PM, "Rob Browning"  wrote:
>
> Do we have a tool that will sort a list of packages in dependency order?
> I ask because if we have one, I'd like to use it to replace the tsort
> mess in emacsen-common.
>
> Thanks
> --
> Rob Browning
> rlb @defaultvalue.org and @debian.org
> GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
>
>
> --
> 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/87ipuevtmk@raven.defaultvalue.org
>

Processed (with 1 errors): Re: Bug#623037: general: Usb flash drive crashes Debian

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 623037 moreinfo
Bug #623037 [general] general: Usb flash drive crashes Debian
Added tag(s) moreinfo.
> severity wishlist
Unknown command or malformed arguments to command.

> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
623037: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=623037
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


-- 
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/handler.s.c.130299920027049.transcr...@bugs.debian.org

Bug#623037: general: Usb flash drive crashes Debian

[Osamu Aoki]

tags 623037 moreinfo
severity wishlist
thanks

Hi,

On Sat, Apr 16, 2011 at 01:50:01PM -0700, Atanas Atanassov wrote:
> Package: general
> Severity: normal
> 
> Every time when I plug a usb drive Debian crashes. The system mount the drive
> successfully and crashes when I am trying to browse the folder

It could be broken harddware (It is typical for flash drive.)
It could be user configuration issue.

This report is useless as presented, unless you provide us with explicit
information such as: 
 * under what live Linux CD you can use your usb drive.
 * under some older Debian you can use your usb drive.
 * what partition table and size is this
 * some kernel log found in crashed system.
 * did you upgraded system or installed it as fresh?
 * what desktop environment is used
 * non-GUI mount (after disablng desktop) result
 

Unless submitter can produce more useful ino, we should close this as
done. BTS is not support help line 

Regards,

Osamu



-- 
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/20110417001237.ga3...@debian.org

Bug#623037: general: Usb flash drive crashes Debian

[Ben Hutchings]

On Sun, 2011-04-17 at 09:12 +0900, Osamu Aoki wrote:
> tags 623037 moreinfo
> severity wishlist
> thanks
> 
> Hi,
> 
> On Sat, Apr 16, 2011 at 01:50:01PM -0700, Atanas Atanassov wrote:
> > Package: general
> > Severity: normal
> > 
> > Every time when I plug a usb drive Debian crashes. The system mount the 
> > drive
> > successfully and crashes when I am trying to browse the folder
> 
> It could be broken harddware (It is typical for flash drive.)
[...]

The kernel is supposed to be robust against faulty USB devices.  They
should not be able to cause a crash, unless the device or port has an
electrical fault (e.g. short circuit).

Given that Atanas says says the drive could be mounted, I think this is
a kernel bug.  See the section 'required information' at
.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


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

Processed: reassign 623037 to linux-2.6, severity of 623037 is important

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign 623037 linux-2.6
Bug #623037 [general] general: Usb flash drive crashes Debian
Bug reassigned from package 'general' to 'linux-2.6'.
> severity 623037 important
Bug #623037 [linux-2.6] general: Usb flash drive crashes Debian
Severity set to 'important' from 'normal'

> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
623037: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=623037
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


-- 
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/handler.s.c.130300095531153.transcr...@bugs.debian.org

Re: /run support for wheezy: final (I hope) call for testing

[Henrique de Moraes Holschuh]

On Sat, 16 Apr 2011, Lars Wirzenius wrote:
> On pe, 2011-04-15 at 21:58 -0300, Henrique de Moraes Holschuh wrote:
> > Symlinks in system path components REALLY are best avoided.
> 
> Out of curiosity: why?

Because not everything is blind to what it is transversing to get to the
inode a path refers to, and a lot more are not blind at the type of the last
component in a path.  Missing the last / is a lot common, it will refer to
the symlink itself, and at that point, stuff can notice the difference and
behave differently.

You don't break an unknown amount of stuff outside of your control when you
have another choice, unless that choice is much worse.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
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/20110417014414.ga15...@khazad-dum.debian.net

Re: Openstack Compute nova, Cactus release, Squeeze built available in our private repo

[Charles Plessy]

Le Sat, Apr 16, 2011 at 10:43:43AM +0800, Thomas Goirand a écrit :
> 
> Again, if other DDs want to participate to this packaging effort, you'd
> be welcome. Especially, it seems that the current version of euca tools
> are broken (uec-publish-tarball got me stuck on my work for a week), and
> would need debugging.

Hi Thomas,

Debian's euca2ools package is definitely outdated.  Is the problem with
uec-publish-tarball fixed in upstream's version 1.3.1 ?

I will be mostly unavailable for the next three weeks, with two business trips
followed by vacations.  So if you or anybody else would like to go ahead and
update the package, you are most welcome !  I can add you to the pkg-eucalyptus
group any time.

Cheers,

-- 
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/20110417050544.gf30...@merveille.plessy.net

Re: Only forbid use of old alternatives to /run in wheezy+1?

[Goswin von Brederlow]

Edward Allcutt  writes:

> On Sat, 16 Apr 2011, Roger Leigh wrote:
>> On Sat, Apr 16, 2011 at 05:58:19PM +0100, Edward Allcutt wrote:
>>> I suggest:
>>>  - on upgrade, bind mount or symlink /run/init -> /lib/init/rw
>>>  - on boot, after mounting /run, mkdir /run/init; ln -s /run/init 
>>> /lib/init/rw
>>>
>>> Or in other words - exactly like we're handling /var/lock and /dev/shm 
>>> except
>>> without a possible separate tmpfs.
>>>
>>> This keeps /lib/init/rw available at all times and doesn't require any
>>> particular upgrade order. The link could be dropped in wheezy+1 but there's 
>>> no
>>> urgency to do so.
>>>
>>> I was under the impression that this was already part of the plan, did
>>> /run/init get dropped for some reason?
>>
>> It did.  The general consensus was that if we did bind mount /run/init
>> to /lib/init/rw on boot (and vice versa on initial install, as for the
>> othe locations), we would still need to transition from /run/init to
>> /run anyway, so we might as well transition directly from /lib/init/rw
>> to /run in a single shot.  This is unlike the other directories, where
>> the files are linked directly to their final destinations.
> I see. I don't see how this can be done in a single shot though.
>
> Let's take the example of package P which currently keeps state in
> /lib/init/rw/P. It has version P1 in squeeze. For version P2 in wheezy
> it aims to move that state to /run/P.
>
> The plan is for packages that will use /run in wheezy to predepend on
> initscripts (>= X).
>
> To achieve this, P (version P2) has to Pre-Depend: initscripts (>= X).
> Because initscripts intends to forcibly move /lib/init/rw/* to /run/*
> you're proposing that initscripts will Breaks: P (<< P2).
>
> I'm hoping I've misunderstood somewhere because that sure looks like
> an unbreakable cycle to me...
>
> If /run/init has been inextricably vetoed then the safe option looks
> like leaving /lib/init/rw alone in wheezy and letting all relevant
> packages handle their own transition to /run. If we want to try hard
> to remove /lib/init/rw in wheezy+1 then we need RC bugs against
> packages using it which don't safely transition away for wheezy.

Breaks isn't Conflicts. The update happens in the following order:

deconfigure P
unpack initscripts
configure initscripts
unpack P
configure P

Breaks only forces package managers to update the broken packages. It
doesn't cause unbreakable cycles.

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/87vcydzb1k.fsf@frosties.localnet