Processed: Re: Bug#643712: general: GNOME or GTK tabs are very slow

[Debian Bug Tracking System]

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

> reassign 643712 gnome
Bug #643712 [general] general: GNOME or GTK tabs are very slow
Bug reassigned from package 'general' to 'gnome'.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
643712: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=643712
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.13172794163428.transcr...@bugs.debian.org

Bug#643736: ITP: ocaml-zarith -- arithmetic and logical operations over arbitrary-precision integers

[Mehdi Dogguy]

Package: wnpp
Severity: wishlist
Owner: Mehdi Dogguy 

* Package name: ocaml-zarith
  Version : 1.0
  Upstream Author : Xavier Leroy and Antoine Mine
* Url : https://forge.ocamlcore.org/projects/zarith/
* License : LGPL 2 with special linking exception
  Programming Lang: OCaml, C, ASM
  Description : arithmetic and logical operations over arbitrary-precision 
integers

The Zarith library implements arithmetic and logical operations over
arbitrary-precision integers. It uses GMP to efficiently implement
arithmetic over big integers. Small integers are represented as Caml
unboxed integers, for speed and space economy.



-- 
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/20110929052550.31728.72253.report...@potassium.pps.jussieu.fr

Bug#643722: ITP: guacamole -- Guacamole Clientless Remote Desktop

[Michael Jumper]

Package: wnpp
Severity: wishlist
Owner: Michael Jumper 

* Package name: guacamole
  Version : 0.4.0
  Upstream Author : Michael Jumper 
* URL : http://guacamole.sourceforge.net/
* License : AGPL-3
  Programming Lang: Java
  Description : HTML5 web appi to access remote desktop 
  
Guacamole is an HTML5 web application that provides access to your
desktop using remote desktop protocols. A centralized server acts as a tunnel
and proxy, allowing access to multiple desktops through a web browser; no
plugins needed. The client requires nothing more than a web browser supporting
HTML5 and AJAX. 

Guacamole would require additional source packages for different
components.



-- 
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/20110929001159.3964.76776.report...@novo.onerussian.com

Re: Bits from dpkg developers - dpkg 1.16.1

[Charles Plessy]

Le Tue, Sep 27, 2011 at 06:01:54PM -0700, Kees Cook a écrit :
> On Fri, Sep 23, 2011 at 08:17:54AM +0200, Raphael Hertzog wrote:
> >   Two hardening features are not enabled by default: PIE and bindnow.
> >   If your package supports PIE, you might want to consider enabling it.
> >   If the binaries are long running processes like daemons, and as such
> >   the startup performance penalty of “bindnow” is acceptable, it might
> >   be a good idea to enable it too but only if relro is in effect,
> >   although another option might be to just define LD_BIND_NOW=1 on the
> >   daemon's environment (for example in the init.d script), in which case
> >   the sysadmin can always disable it, something that's not possible with
> >   the build option.
> 
> Just to be explicit, PIE tends to have small (<1%) performance hits on
> register-starved architectures (i386) in most cases, for for certain work
> loads (e.g. python) the hit is large (~15%). On architectures with plenty
> of registers (amd64) there's virtually no measurable performance hit that
> I've seen.

By the way – and please pardon me if it is a too naive question – does this
recommendation of building packages with PIE when possible make obsolete the
recommendation of Policy's §10.2 to not build static libraries with -fPIC ?

  http://www.debian.org/doc/debian-policy/ch-files.html#s-libraries

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/20110928214129.ge9...@merveille.plessy.net

Re: Bits from dpkg developers - dpkg 1.16.1

[Mike Hommey]

On Wed, Sep 28, 2011 at 10:52:15PM +0300, Riku Voipio wrote:
> On Tue, Sep 27, 2011 at 06:01:54PM -0700, Kees Cook wrote:
> > Just to be explicit, PIE tends to have small (<1%) performance hits on
> > register-starved architectures (i386) in most cases, for for certain work
> > loads (e.g. python) the hit is large (~15%). On architectures with plenty
> > of registers (amd64) there's virtually no measurable performance hit that
> > I've seen.
>  
> > If your package handles 3rd party data of any kind (renders, network
> > daemons, file parsers, etc), I strongly recommend enabling PIE.
> 
> However, on 32bit architectures address space randomizing (which is why
> people try sell PIE as a security feature) does not add much security.
> 
>   http://benpfaff.org/papers/asrandom.pdf

Also note that as long as you can read memory in the process and have
access to /proc/self/auxv, you can find the base address of all
libraries.

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/20110928213806.ga30...@glandium.org

Bug#643712: general: GNOME or GTK tabs are very slow

[David Rogers]

Package: general
Severity: important

Dear Maintainer,

For the last two days any GNOME or GTK program that I run that has tabs (e.g.
gedit, nautilus, Iceweasel etc) have become very slow to open new tabs, switch
between tabs or close tabs. Nautilus and Iceweasel work with no slow down at
all as long as I don't open more than one tab (as both won't show the tab bar
if there is only one tab) but gedit is always slow as the tab bar is always
shown.

I tested if this was isolated to GTK or GNOME by using a qt program I have
installed with video4fuze which has no slow down when switching tabs (I can't
open or close them in that program).

I'm not sure what package upgrade caused this. I'm running Debian Wheezy amd64.



-- System Information:
Debian Release: wheezy/sid
  APT prefers testing-proposed-updates
  APT policy: (500, 'testing-proposed-updates'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.0.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.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/20110928212854.3586.25762.reportbug@alice

Re: Bits from dpkg developers - dpkg 1.16.1

[Riku Voipio]

On Tue, Sep 27, 2011 at 06:01:54PM -0700, Kees Cook wrote:
> Just to be explicit, PIE tends to have small (<1%) performance hits on
> register-starved architectures (i386) in most cases, for for certain work
> loads (e.g. python) the hit is large (~15%). On architectures with plenty
> of registers (amd64) there's virtually no measurable performance hit that
> I've seen.
 
> If your package handles 3rd party data of any kind (renders, network
> daemons, file parsers, etc), I strongly recommend enabling PIE.

However, on 32bit architectures address space randomizing (which is why
people try sell PIE as a security feature) does not add much security.

  http://benpfaff.org/papers/asrandom.pdf

Riku


-- 
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/20110928195215.ga24...@afflict.kos.to

Re: BTW question: how expensive is archive/unarchive

[Colin Watson]

On Wed, Sep 28, 2011 at 10:00:11AM -0700, Don Armstrong wrote:
> On Wed, 28 Sep 2011, Theodore Ts'o wrote:
> > How expensive is this?  Is archive/unarchive just a flag to prevent
> > spam from getting entered into the bug report, or something more?
> 
> It's mainly just a link/unlink with some indexing afterwards, so it's
> reasonably cheap. Go ahead and run it.

And as for the reason for archiving, yes, it's principally to prevent
spam, with a side order of keeping default package report views down to
a reasonable size.  (One might disagree on the relative priorities of
these, of course ...)

-- 
Colin Watson   [cjwat...@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/20110928171158.ga10...@riva.dynamic.greenend.org.uk

Re: BTW question: how expensive is archive/unarchive

[Don Armstrong]

On Wed, 28 Sep 2011, Theodore Ts'o wrote:
> There are a bunch of bug reports where a bug was fixed in the stable
> branch, and for whatever reason it wasn't obvious to BTS that the
> bug was fixed in the development branch as well, so it shows a
> picture like this:
> 
> http://bugs.debian.org/cgi-bin/version.cgi?info=1;absolute=0;fixed=e2fsprogs%2F1.41.12-3;collapse=1;found=e2fsprogs%2F1.41.11-1;package=e2fsprogs
> 
> Since it was marked "done", the bug report has been marked archived, so
> I can't just send a command:
> 
> fixed 588726 e2fsprogs/1.42~WIP-2011-07-02-01
> 
> I'd instead have to do this:
> 
> unarchive 588726
> fixed 588726 e2fsprogs/1.42~WIP-2011-07-02-01
> archive 588726
> 
> How expensive is this?  Is archive/unarchive just a flag to prevent
> spam from getting entered into the bug report, or something more?

It's mainly just a link/unlink with some indexing afterwards, so it's
reasonably cheap. Go ahead and run it.
 
> Also, I found the following in the HowToUseBTS archive:
> 
>"Because bug reports can get archived after 28 days if they fulfil
>some criteria: usually bugs have to get fixed both in unstable and in
>testing to get archived."
> 
> So it's a bit annoying that I need to go in and manually mark all of
> these bugs as fixed in a historical release --- but given that BTS
> thinks that both unstable and testing still have these bugs marked
> as unfixed, why were they archived in the first place?

If on June 6th, the bug was fixed in unstable and testing, then it
would have been archived, even if the bug later became unfixed in
unstable. Bugs like this should probably automatically become
unarchived, but I haven't sat down and wrote the code to do that.


Don Armstrong

-- 
Of course, there are cases where only a rare individual will have the
vision to perceive a system which governs many people's lives; a
system which had never before even been recognized as a system; then
such people often devote their lives to convincing other people that
the system really is there and that it aught to be exited from. 
 -- Douglas R. Hofstadter _Gödel Escher Bach. Eternal Golden Braid_

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
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/20110928170011.gz16...@rzlab.ucr.edu

BTW question: how expensive is archive/unarchive

[Theodore Ts'o]

Hi there,

There are a bunch of bug reports where a bug was fixed in the stable
branch, and for whatever reason it wasn't obvious to BTS that the bug
was fixed in the development branch as well, so it shows a picture like
this:

http://bugs.debian.org/cgi-bin/version.cgi?info=1;absolute=0;fixed=e2fsprogs%2F1.41.12-3;collapse=1;found=e2fsprogs%2F1.41.11-1;package=e2fsprogs

Since it was marked "done", the bug report has been marked archived, so
I can't just send a command:

fixed 588726 e2fsprogs/1.42~WIP-2011-07-02-01

I'd instead have to do this:

unarchive 588726
fixed 588726 e2fsprogs/1.42~WIP-2011-07-02-01
archive 588726

How expensive is this?  Is archive/unarchive just a flag to prevent
spam from getting entered into the bug report, or something more?

Also, I found the following in the HowToUseBTS archive:

   "Because bug reports can get archived after 28 days if they fulfil
   some criteria: usually bugs have to get fixed both in unstable and in
   testing to get archived."

So it's a bit annoying that I need to go in and manually mark all of
these bugs as fixed in a historical release --- but given that BTS
thinks that both unstable and testing still have these bugs marked as
unfixed, why were they archived in the first place?

   - Ted


-- 
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/e1r8x7b-0005hi...@tytso-glaptop.cam.corp.google.com

Re: Mobile UXes - From the DebConf11 BoF to the stars

[Didier Raboud]

Le vendredi, 9 septembre 2011 09.21:20, Luca Capello a écrit :
> On Thu, 08 Sep 2011 10:36:17 +0200, Didier Raboud wrote:
> > The main reference to build up this list has been
> > http://wiki.debian.org/Smartphone, which is still a good reference! Now
> > to the list.
> 
> What about [1]?  There is no reference in your email.
> 
> [1] 

Thanks for that. Unfortunately, nobody mentionned it during the BoF, so it 
just got under the radar.

> Please note that I am not volunteering for anything, given that I have
> completely lost any faith about having a real free smartphone

Too bad. :-/

-- 
OdyX


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

lists.debian.org: Please create debian-mob...@lists.debian.org (was: Re: Mobile UXes - From the DebConf11 BoF to the stars)

[Didier Raboud]

Package: lists.debian.org
Severity: normal

Le jeudi, 8 septembre 2011 16.32:45, Stefano Zacchiroli a écrit :
> I applaud this "merge" effort. Kudos!
> 
> On Thu, Sep 08, 2011 at 10:36:17AM +0200, Didier Raboud wrote:
> > c) Create a new Alioth project, 'mobile-ux', with associated
> > mailing-lists and a wiki page.
> 
> Given you are going to provide a central discussion forum for Debian
> "mobile" stuff, you might want to be a bit more bold and request the
> "debian-mobile@lists.d.o" mailing list. That might provide some more
> visibility to this laudable initiative.

Agreed.

So here is the formal request for a debian-mob...@lists.debian.org :

Name: debian-mob...@lists.debian.org

Rationale: Packaging efforts around mobile user interfaces are currently
 scattered around in many different alioth projects, mailing lists, etc.
 See http://lists.debian.org/debian-devel/2011/09/msg00126.html for a more
 complete rationale.

Short description: Mobile interfaces in Debian

Long description: Discussions around packaging suitable mobile interfaces to 
 Debian. Mobile systems have a user-interface different than the traditional
 'keyboard-mouse' pair, can be battery-powered, have a generally small form
 factor and/or only allow few elements on a given screen.

Category: Developers

Subscription Policy: open

Post Policy: open

Web Archive: yes


Thanks for considering, cheers,

-- 
OdyX


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

Re: Bug#643669: ITP: pp-popularity-contest -- PredictProtein popularity contest

[Simon McVittie]

On Wed, 28 Sep 2011 at 16:38:11 +0200, Laszlo Kajan wrote:
> Without the funding received based on the usage statistics you contribute by
> installing this package none of the packages on Debian could have been made
> available to you at no cost.

I'm pretty sure that's not true. None of the PredictProtein packages, maybe...

Would data from the normal popularity-contest package be enough for your
usage statistics?

S


-- 
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/20110928150152.gc17...@reptile.pseudorandom.co.uk

Re: Eliminating bash scripts?

[Simon McVittie]

On Wed, 28 Sep 2011 at 13:01:45 +0200, Thomas Hood wrote:
> * The package then has fewer dependencies
> * ... and can then be installed on a system without bash.

This doesn't help Debian directly, but it may help upstreams to be portable
to operating systems with a reason to use a non-bash shell - embedded systems
with Busybox, BSDs with ideological objections to the GPL, proprietary Unixes
with a grudgingly-POSIX-compliant proprietary shell.

> * If sed has to be used, that OK, its regexps are better than
> bash's extended globs.

If you can use ${x%%y}, ${x#y} etc. to achieve the same effect (you often can),
you get the best of both worlds. I believe they're specified by POSIX;
certainly, current dash supports them, and they're in the SUS.

Otherwise, it's a trade-off. Basic use of sed + sh should work on most
Busybox-based embedded systems and on any POSIX-compliant Unix, whereas
bash is a non-standard addition - but on the other hand, bash extended
globs save a fork().

> Should we be aiming to eliminate all bash scripts from Debian?

IMO: if there are bash scripts that can be converted into POSIX sh scripts
easily, why not? but if it would make the script significantly less
maintainable, your time is usually more valuable than your CPU's.

S


-- 
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/20110928145940.gb17...@reptile.pseudorandom.co.uk

Bug#643669: ITP: pp-popularity-contest -- PredictProtein popularity contest

[Laszlo Kajan]

Package: wnpp
Severity: wishlist
Owner: Laszlo Kajan 


* Package name: pp-popularity-contest
  Version : 1.0.3
  Upstream Author : Laszlo Kajan 
* URL : http://www.rostlab.org/
* License : GPL
  Programming Lang: C++
  Description : PredictProtein popularity contest

The pp-popularity-contest package sets up a cron job
that periodically submits the developers anonymous statistics on the usage of 
Rost Lab prediction methods installed on this system.
.
This information helps to make decisions like which packages
should receive high priority when fixing bugs or receive funding for further
development and support.
This information is also very important when the Rost Lab applies for funding.
.
Without the funding received based on the usage statistics you contribute by
installing this package none of the packages on Debian could have been made
available to you at no cost.
.
Please install this package when it is recommended.



-- 
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/20110928143811.2433.28670.reportbug@n0d.rostclust

Re: Eliminating bash scripts?

[Ian Jackson]

Thomas Hood writes ("Eliminating bash scripts?"):
> Recently I noticed some bug reports asking that scripts be
> rewritten to run on (POSIX) sh.  These weren't the familiar
> (and completely justified) complaints about bashisms in scripts
> shebanged #!/bin/sh. These were requests to rewrite #!/bin/bash
> scripts as #!/bin/sh scripts.  Why do this?  The following reasons
> were advanced.
>   [stuff]
...
> I wonder what Debian folk think about these claims.

I think it depends on the script.  There are also some very good
reasons to use bash rather than dash.  bash has some important
features which are either very hard to emulate in dash, or where the
alternatives are often annoyingly clumsy:
  * Array variables
  * set -o pipefail / ${PIPESTATUS[*]}
  * shopt -s nullglob / failglob
  * glob substitutions ${//} etc.
  * bunches of other niche stuff which is very useful if you
 happen to want it (eg, RANDOM, disown)

If some part of your program uses these features extensively, it can
be quite a bit of work to change it.  I would need a compelling reason
to do so.

One also needs to think about the environment the script might run
in.  I think, for example, that it's perfectly reasonable to expect
bash to be installed when doing package builds, so I have no
hesitation in using bashisms freely in build and packaging scripts.

Also for desktop systems running gnome, kde, web browsers, etc., the
additional cost of bash is negligible.  So packages aimed at those
environments can also sensibly use bash.

On the other hand, there is a lot of potential benefit to getting rid
of the dependency on bash for essential packages - even if we can't
get bash out of essential in Debian proper, derivatives might do so.

> * The package then has fewer dependencies
> * ... and can then be installed on a system without bash.
> * When /bin/sh is dash, the script will run faster
> * ... and will run on a shell which is smaller and thus less buggy

These are probably true (although dash used to be quite buggy, it's
much less so now).

> * ... and more secure
> * ... and, after all, standard, whereas bash is not,
> * ... and consequently better understood by programmers,
> * ... and portable, whereas bash is not.

These reasons are at best doubtful.

> * Indeed, dash is the future whereas bash is history.
> * If sed has to be used, that OK, its regexps are better than
>   bash's extended globs.

And these are by and large false.

> Should we be aiming to eliminate all bash scripts from Debian?

No.  But it might be worthwhile seeing if we can get rid of it from
essential, for example.

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/20099.7661.214781.947...@chiark.greenend.org.uk

Re: Eliminating bash scripts?

[Neil Williams]

On Wed, 28 Sep 2011 13:01:45 +0200
Thomas Hood  wrote:

> * The package then has fewer dependencies
> * ... and can then be installed on a system without bash.

Unless the package is doing a lot of clever stuff in shell (at which
point it is possibly worth asking if the package should use a faster
interpreted language like perl - which will be installed even if bash
is not - or converted to a compiled tool), the reasons to
keep #!/bin/bash are likely to be inertia.

> * When /bin/sh is dash, the script will run faster
> * ... and will run on a shell which is smaller and thus less buggy

Not necessarily true.

> * ... and more secure

Not necessarily true.

> * Indeed, dash is the future whereas bash is history.

Opinion.

> Should we be aiming to eliminate all bash scripts from Debian?

I see no good reasons.
 
> Are there real-world Debian systems that are "minimal" enough
> to have trouble running bash, but not so minimal that busybox
> has to be used?

Such systems would probably involve some form of embedded usage and
most people investigating such things could be expected to at least ask
on the debian-embedded lists or #emdebian on IRC. I don't miss many
queries on either of those and I cannot remember a single instance of
anyone wanting to remove bash but keep dash.

If bash is a problem then perl is a bigger problem and dash is not the
solution. The solution is busybox which means removing coreutils and a
whole world of fettling. i.e. Emdebian Crush.

> One thing I would like to point out immediately is that a bash
> script will not necessarily run faster if it has to be rewritten
> to run on sh.  This is especially true if ${//}s are replaced by
> pipes to sed.

All the more reason to make the rewrite in a different language. If the
tool isn't likely to be needed on minimal systems where the only
available shell is busybox, then a rewrite in perl, python or something
else would seem appropriate. If it could be used with busybox, the only
really sane option is to compile it.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpgFR6vPqRkY.pgp
Description: PGP signature

Eliminating bash scripts?

[Thomas Hood]

Recently I noticed some bug reports asking that scripts be
rewritten to run on (POSIX) sh.  These weren't the familiar
(and completely justified) complaints about bashisms in scripts
shebanged #!/bin/sh. These were requests to rewrite #!/bin/bash
scripts as #!/bin/sh scripts.  Why do this?  The following reasons
were advanced.

* The package then has fewer dependencies
* ... and can then be installed on a system without bash.
* When /bin/sh is dash, the script will run faster
* ... and will run on a shell which is smaller and thus less buggy
* ... and more secure
* ... and, after all, standard, whereas bash is not,
* ... and consequently better understood by programmers,
* ... and portable, whereas bash is not.
* Indeed, dash is the future whereas bash is history.
* If sed has to be used, that OK, its regexps are better than
bash's extended globs.

I wonder what Debian folk think about these claims.

Should we be aiming to eliminate all bash scripts from Debian?

Are there real-world Debian systems that are "minimal" enough
to have trouble running bash, but not so minimal that busybox
has to be used?

One thing I would like to point out immediately is that a bash
script will not necessarily run faster if it has to be rewritten
to run on sh.  This is especially true if ${//}s are replaced by
pipes to sed.
-- 
Thomas Hood

Re: Bits from dpkg developers - dpkg 1.16.1

[Bernhard R. Link]

* Ian Jackson  [110927 20:21]:
> Bernhard R. Link writes ("Re: Bits from dpkg developers - dpkg 1.16.1"):
> > CFLAGS and LDFLAGS (and CPPFLAGS and so on) are in my opionion normal
> > things to be in a users environment, so a package's rules file should
> > in my eyes not depend on them not being set or having any values sensible.
>
> This tells us more about the reliability of your opinion than it does
> about build systems.

Thanks in advance for keeping personal attacks out of the discussion
in the future.

> In general, upstream build systems cannot be
> relied on do to anything sane or predictable if they are run with
> these variables in the environment.

While some upstream build systems have problems with those flags,
most broken ones simply ignore them (unlike setting them as
make variables on the command line, where much more break).

automake/autoconf usually do a very good job on respecting those
variables and if some project fails to handle those properly, they
usually do so in not respecting a setting in the environment at
configure time (by overwriting it) or by adding stuff to it at
configure time so that running make with different flags given
as arguments misses those arguments (which is well for additional
warning flags and stuff like that but not for things like including
private headers), but both of those cases also cause no problem.

If mostly dealing with auto* projects, having some
CPPFLAGS=-I~/stuff/include and LDFLAGS=-L~/stuff/lib
together with some LD_LIBRARY_PATH is an very easy way to
develop as user without root priviledges (just needing
--prefix=~/stuff then for all configure runs).

Bernhard R. Link


-- 
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/20110928085838.ga30...@server.brlink.eu

Bug#643630: ITP: librg-utils-perl -- parsers and format conversion utilities used by (e.g.) profphd

[Laszlo Kajan]

Package: wnpp
Severity: wishlist
Owner: Laszlo Kajan 


* Package name: librg-utils-perl
  Version : 1.0.41
  Upstream Author : Burkhard Rost 
* URL : http://www.rostlab.org/
* License : GPL
  Programming Lang: Perl
  Description : parsers and format conversion utilities used by (e.g.) 
profphd

This package contains tools like:

* blast2saf.pl, blastpgp_to_saf.pl, conv_hssp2saf.pl, copf.pl, hssp_filter.pl,
safFilterRed.pl

and modules like:

* RG:Utils::Conv_hssp2saf RG:Utils::Copf RG:Utils::Hssp_filter



-- 
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/20110928084729.27937.48522.reportbug@n0d.rostclust