Re: Debian XDG basedir compliance

2013-10-11 Thread Paul Wise 
On Sat, Oct 12, 2013 at 8:26 AM, Charles Plessy wrote:

> I think that this would be more suitable for the Upstream Guide
> (https://wiki.debian.org/UpstreamGuide).  The Debian Policy focuses on how to
> integrate works in Debian, so if being XDG-compliant or not does not make a
> difference, then I think that there is no need to mention this standard.

Good point. I've added a section on user home directories to the UG,
pointing out the XDG spec and the libraries that support it.

https://wiki.debian.org/UpstreamGuide#User_home_directories

I also put a paragraph about the HOME environment variable and falling
back to getpwuid.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: Debian XDG basedir compliance

2013-10-11 Thread Russ Allbery 
debian-de...@liska.ath.cx (Olе Streicher) writes:
> Lars Wirzenius  writes:

>> Having Debian versions of the programs differ in this from everyone
>> else would create a lot of confusion, and needlessly cause everyone
>> more support burden than is needed.

> Isn't that the same case with the FHS?

To add on to what Lars said, users still often use the same home directory
on multiple systems (via NFS, AFS, etc.) and expect, when running the same
application on different systems, for programs to find their configuration
files in the same places.  The FHS doesn't pose the same issue, since
those directories are generally (albeit not always) local to each system.

> I don't mean it as a strong requirement (yet); but couldn't this be
> included in the policy as recommendation and/or goal?

I don't think it's appropriate for Policy because it isn't something that
Debian can do at the packaging level.  It would, however, be appropriate
for the guide for what upstreams should do to help their software work
well on Debian.  I think that's maintained on the wiki, although I forget
where.

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


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

Re: automake transition breakages

2013-10-11 Thread Russ Allbery 
Ian Jackson  writes:
> Russ Allbery writes ("Re: automake transition breakages"):

>> Well, the simple answer is that we avoid having to maintain local
>> patches against the upstream source to remove -Werror, since generally
>> it's not something over which we have a choice without patching the
>> upstream source.  It's usually expressed in configure.ac.

> I don't think this is a sufficiently good reason to take the portability
> hit.

> Think, for example, about downstreams (including users) who may want to
> forward-port a package to a different Debian release and thus a
> different automake version.

> For such a central tool as automake, we should tolerate lots of version
> skew slop.

I have not had any problems in practice with my software with -Werror with
Automake, and therefore intend to keep using it with all of the software
for which I'm both upstream and Debian maintainer.  (And hence would
oppose Lintian tests, etc.)

If folks are having trouble here with software for which they're not
upstream, I can see the benefit in removing it, but my expectation is that
upstreams who care enough to use -Werror are (like me) probably also going
to care enough to quickly fix problems that result in Automake warnings.

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


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

Re: Debian XDG basedir compliance

2013-10-11 Thread Charles Plessy 
Le Fri, Oct 11, 2013 at 09:04:57PM +0200, Olе Streicher a écrit :
> 
> I don't mean it as a strong requirement (yet); but couldn't this be
> included in the policy as recommendation and/or goal?

Hi Olе,

I think that this would be more suitable for the Upstream Guide
(https://wiki.debian.org/UpstreamGuide).  The Debian Policy focuses on how to
integrate works in Debian, so if being XDG-compliant or not does not make a
difference, then I think that there is no need to mention this standard.

By the way, there are roughly 200 issues open on the debian-policy package, so
everybody's help to pick one and resolve it is more than welcome !

Have a nice week-end,

-- 
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/20131012002605.ga5...@falafel.plessy.net

Re: pidof changing from sysvinit-devel to procps

2013-10-11 Thread Craig Small 
On Sun, Aug 11, 2013 at 11:28:47AM +1000, Craig Small wrote:
> On Fri, Aug 09, 2013 at 01:39:20PM +0200, Ben Hutchings wrote:
> > I also wonder whether it would not be more sensible to split procps into
> > essential and non-essential binary packages.  Aside from pidof, I bet
> > there are lots of scripts using pkill, pgrep, /bin/kill and ps without
> > the necessary dependency now.  (I saw one using ps just the other day:
> > #719126.)
> I happen to think this is probably the best way.  There are lots of things
> using pidof and ps in scripts, usually init scripts. (As an aside, this is
> probably wrong; there is a lsb function for this sort of thing; also 
> kill `pidof blah` is not nice either). It would come down to what
> is left over and is it worth putting it into another package.
We're getting close to releasing procps upstream which will have the
pidof in it. So its also getting time to work out what to do.

I think I will need to split procps into two binary packages. The first
will have pidof and possibly some other binaries such as ps and would
need to be promoted to Essential

The key thing between the two binary packages is to not pull in
libncurses5w which isn't used by any Essential package currently.
However libprocps would need to be installed as its a dependency
on almost all the binaries.

my first cut of it would be:
procps-base: pidof, ps, sysctl, pgrep, pkill
procps: pwdx, vmstat, tload, free, pmap, skill, slabtop, top, uptime,
watch, w, snice

procps-base is Essential and depends on libc6, libncurses, libprocps, 
libtinfo5, lsb-base, initscripts
It will also Replaces and Breaks sysvinit-utils (<< some version number)
as that is where pidof comes from.

procps is not Essential and depends on libncurses5w as well as the above
set.

 - Craig
-- 
Craig Small VK2XLZ   http://enc.com.au/  csmall at : enc.com.au
Debian GNU/Linux http://www.debian.org/  csmall at : debian.org
GPG fingerprint: 5D2F B320 B825 D939 04D2  0519 3938 F96B DF50 FEA5


-- 
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/20131011230133.ga17...@enc.com.au

Re: Insufficient RAM on build-machines (was Bug#726009: yade: FTBFS on i386 (and others))

2013-10-11 Thread Steve Langasek 
On Fri, Oct 11, 2013 at 09:55:34PM +0100, Dmitrijs Ledkovs wrote:
> I'm not sure, but launchpad is running 64-bit machines even when
> compiling for the i386 architecture, and then launchpad supports PAE
> only and thus can get >4GB of address space.

A 32-bit process can still only address 32-bits of memory.  PAE only lets
you extend past 4GB across *multiple* processes; the 4GB limit still applies
to any one 32-bit process.

> I think debian buildds are also all 64-bit apart from one (or
> something like that) thus it shouldn't be a problem there.
> 
> Last time I spoke with Colin about yade FTBFS due to memory
> exhaustion, the recommendation he gave was to reduce translation units
> and thus to reduce the compiler memory usage. GCC memory usage can go
> very large and has regressed since 3.3 when templates are used
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12850
> It has been done before for some other packages, but i haven't yet had
> time to look more into yade. I think that's the best way to go for
> yade, to address it in the source-code / restructure it to use less
> memory at compile time.

Yes, even if we can pinpoint a specific recent change in the compiler that
caused increased memory usage, the most reliable fix for the problem is
going to be to just refactor this code.  If your compiler is taking anywhere
near 3GB of memory to build a single object file, that's not a good thing
anyway.

-- 
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: Insufficient RAM on build-machines (was Bug#726009: yade: FTBFS on i386 (and others))

2013-10-11 Thread Dmitrijs Ledkovs 
On 11 October 2013 22:34, Ben Hutchings  wrote:
> On Fri, Oct 11, 2013 at 09:55:34PM +0100, Dmitrijs Ledkovs wrote:
> [...]
>> I'm not sure, but launchpad is running 64-bit machines even when
>> compiling for the i386 architecture, and then launchpad supports PAE
>> only and thus can get >4GB of address space.
> [...]
>
> Which bit of 'Physical Address Extension' do you not understand?
>

ignore me, friday evening. the parts where virtual address space is
limitted to 4gb per process none the less.

Regards,

Dmitrijs.


-- 
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/canbhlujadw1epezxg0f8oheb8ly_vy496l4ncwffgg-tmz+...@mail.gmail.com

Re: automake transition breakages

2013-10-11 Thread Cyril Brulebois 
Cyril Brulebois  (2013-09-30):
> That's nice for well maintained packages. Not so nice when packages
> start FTBFSing in the middle of a transition because of an automake
> update, and maintainers are otherwise busy or MIA.

FWIW it took me less than 10 days after I wrote this to actually hit
this very issue, when trying to submit a patch against src:check, so
that src:netcfg could have a chance to build, so that I could upload
src:debian-installer.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Insufficient RAM on build-machines (was Bug#726009: yade: FTBFS on i386 (and others))

2013-10-11 Thread Ben Hutchings 
On Fri, Oct 11, 2013 at 09:55:34PM +0100, Dmitrijs Ledkovs wrote:
[...]
> I'm not sure, but launchpad is running 64-bit machines even when
> compiling for the i386 architecture, and then launchpad supports PAE
> only and thus can get >4GB of address space.
[...]

Which bit of 'Physical Address Extension' do you not understand?

Ben.

-- 
Ben Hutchings
No political challenge can be met by shopping. - George Monbiot


-- 
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/20131011213415.gd4...@decadent.org.uk

Re: Insufficient RAM on build-machines (was Bug#726009: yade: FTBFS on i386 (and others))

2013-10-11 Thread Dmitrijs Ledkovs 
On 11 October 2013 20:32, Steve Langasek  wrote:
> severity 726009 serious
> thanks
>
> This remains a serious bug.  Your package, which previously built on
> multiple architectures, is now failing to build due to memory exhaustion.
> While in some circumstances it is permissible to remove the old binaries and
> drop support for an architecture, this remains a serious bug until this has
> been done.  (And anyway, your package won't reach testing in the current
> state, so is de facto unreleasable.)
>
> On Fri, Oct 11, 2013 at 09:00:36PM +0200, Anton Gladky wrote:
>> severity 726009 wishlist
>> retitle 726009 Yade requires too much RAM for building
>> thanks
>
>> thanks for bug-report. The problem is, that all build-failures are due
>> to insufficient RAM on build-machines [1]. I do not really know how to
>> "fix" that except of backlisting of some machines, as was suggested by
>> Julien [2]. The same package builds fine on Launchpad's PPA. It seems,
>> the package builds only on machines, where >4Gb RAM is available.
>
> This diagnosis is incorrect.  The error you are hitting here is not that you
> are exhausting the available memory on the machine, it's that you're
> exhausting the *address space* on the machine.  Adding more memory to the
> buildd would have zero effect, because you're on a 32-bit system which has a
> limit of 4GB of address space anyway.  (In practice, I believe this is 3GB
> for userspace and 1GB for kernel on i386.)
>
> The buildd almost certainly has swap already, giving it total available
> memory in excess of 4GB, but that doesn't help if you have a single process
> - in this case g++ - that needs more than 3GB all to itself.
>
> If this same package version built on Launchpad but is failing to build in
> Debian unstable, then you should look at differences in toolchain versions
> between the two.  It's possible that Ubuntu has a compiler fix that isn't
> yet available in unstable; it's equally possible that the successful builds
> in Launchpad were done with an earlier toolchain, and that there's a more
> recent regression in g++ memory usage.  Either way, it's not the buildd's
> fault.

I'm not sure, but launchpad is running 64-bit machines even when
compiling for the i386 architecture, and then launchpad supports PAE
only and thus can get >4GB of address space.
I think debian buildds are also all 64-bit apart from one (or
something like that) thus it shouldn't be a problem there.

Last time I spoke with Colin about yade FTBFS due to memory
exhaustion, the recommendation he gave was to reduce translation units
and thus to reduce the compiler memory usage. GCC memory usage can go
very large and has regressed since 3.3 when templates are used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12850
It has been done before for some other packages, but i haven't yet had
time to look more into yade. I think that's the best way to go for
yade, to address it in the source-code / restructure it to use less
memory at compile time.

Regards,

Dmitrijs.


-- 
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/CANBHLUj6+mjT2itJTdaMZtHFSuJdCVHHGC8Lpgp_5nFkicHK=q...@mail.gmail.com

Re: Insufficient RAM on build-machines (was Bug#726009: yade: FTBFS on i386 (and others))

2013-10-11 Thread Kurt Roeckx 
On Fri, Oct 11, 2013 at 12:32:27PM -0700, Steve Langasek wrote:
> severity 726009 serious
> thanks
> 
> This remains a serious bug.  Your package, which previously built on
> multiple architectures, is now failing to build due to memory exhaustion. 
> While in some circumstances it is permissible to remove the old binaries and
> drop support for an architecture, this remains a serious bug until this has
> been done.  (And anyway, your package won't reach testing in the current
> state, so is de facto unreleasable.)
> 
> On Fri, Oct 11, 2013 at 09:00:36PM +0200, Anton Gladky wrote:
> > severity 726009 wishlist
> > retitle 726009 Yade requires too much RAM for building
> > thanks
> 
> > thanks for bug-report. The problem is, that all build-failures are due
> > to insufficient RAM on build-machines [1]. I do not really know how to
> > "fix" that except of backlisting of some machines, as was suggested by
> > Julien [2]. The same package builds fine on Launchpad's PPA. It seems,
> > the package builds only on machines, where >4Gb RAM is available.
> 
> This diagnosis is incorrect.  The error you are hitting here is not that you
> are exhausting the available memory on the machine, it's that you're
> exhausting the *address space* on the machine.  Adding more memory to the
> buildd would have zero effect, because you're on a 32-bit system which has a
> limit of 4GB of address space anyway.  (In practice, I believe this is 3GB
> for userspace and 1GB for kernel on i386.)

I've explained this same thing to people before.  All i386 buildds
are now actually running on an amd64 hosts with an amd64 kernel.
All of them have more than 4 GB available except from brahms which
only as 2 GB + 512 MB of swap.

The buildds it failed on (babin, biber) each have 8 GB of RAM
available.

With an amd64 kernel, i386 userspace can actually use 4 GB, which
is more than it can on a real i386 host.

If you fix it on the other buildds and it still fails on brahms I
can either ask DSA to give more RAM to it or I can exclude the
package there.


Kurt


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

Re: Debian XDG basedir compliance

2013-10-11 Thread Lars Wirzenius 
On Fri, Oct 11, 2013 at 09:04:57PM +0200, Olе Streicher wrote:
> Lars Wirzenius  writes:
> > Having Debian versions of the programs differ in this from everyone
> > else would create a lot of confusion, and needlessly cause everyone
> > more support burden than is needed.
> 
> Isn't that the same case with the FHS?

FHS compliance is required for Debian to be able to integrate upstream
projects into a working operating system at all. XDG is mainly about
making user's home directories cleaner: a worthy goal, and one I agree
with, but not necessary for Debian to do.

FHS also built on long-standing Unix tradition, and most programs
already support it, either out of the box or by suitable configuration
at build time. XDG is gaining traction only slowly, and mainly in
software written using GUI toolkits.

> To bring an example here from my ongoing packaging projects: IRAF [1]
> uses /iraf/ as the root path for its directory structure as standard,
> and they are probably not going to change this. So, with Debian
> deviating from everyone else here would probably also create a lot of
> confusion; however I will ofcourse obey the policy here.

There are exceptions to upstream being FHS compliant. They're fairly
rare.

> > Please do contribute to any upstream projects that interest you to add
> > support for XDG, but don't try to make it mandatory in Debian.
> 
> I don't mean it as a strong requirement (yet); but couldn't this be
> included in the policy as recommendation and/or goal?

I would object to that. It is not Debian's job to make these changes,
or to make sure software we package follows the XDG: it doesn't
provide great benefit, but does (at this point in time) require too
much effort.

I'm all for the XDG directory specification. I'm all for helping
upstreams support it. I do not want Debian package maintainers to
spend time doing it as part of their Debian duties. We have much
more important problems to solve.

-- 
http://www.cafepress.com/trunktees -- geeky funny T-shirts
http://gtdfh.branchable.com/ -- GTD for hackers


-- 
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/20131011200314.GV17839@holywood

Re: Insufficient RAM on build-machines (was Bug#726009: yade: FTBFS on i386 (and others))

2013-10-11 Thread Steve Langasek 
severity 726009 serious
thanks

This remains a serious bug.  Your package, which previously built on
multiple architectures, is now failing to build due to memory exhaustion. 
While in some circumstances it is permissible to remove the old binaries and
drop support for an architecture, this remains a serious bug until this has
been done.  (And anyway, your package won't reach testing in the current
state, so is de facto unreleasable.)

On Fri, Oct 11, 2013 at 09:00:36PM +0200, Anton Gladky wrote:
> severity 726009 wishlist
> retitle 726009 Yade requires too much RAM for building
> thanks

> thanks for bug-report. The problem is, that all build-failures are due
> to insufficient RAM on build-machines [1]. I do not really know how to
> "fix" that except of backlisting of some machines, as was suggested by
> Julien [2]. The same package builds fine on Launchpad's PPA. It seems,
> the package builds only on machines, where >4Gb RAM is available.

This diagnosis is incorrect.  The error you are hitting here is not that you
are exhausting the available memory on the machine, it's that you're
exhausting the *address space* on the machine.  Adding more memory to the
buildd would have zero effect, because you're on a 32-bit system which has a
limit of 4GB of address space anyway.  (In practice, I believe this is 3GB
for userspace and 1GB for kernel on i386.)

The buildd almost certainly has swap already, giving it total available
memory in excess of 4GB, but that doesn't help if you have a single process
- in this case g++ - that needs more than 3GB all to itself.

If this same package version built on Launchpad but is failing to build in
Debian unstable, then you should look at differences in toolchain versions
between the two.  It's possible that Ubuntu has a compiler fix that isn't
yet available in unstable; it's equally possible that the successful builds
in Launchpad were done with an earlier toolchain, and that there's a more
recent regression in g++ memory usage.  Either way, it's not the buildd's
fault.

-- 
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: Debian XDG basedir compliance

2013-10-11 Thread Olе Streicher 
Lars Wirzenius  writes:
> Having Debian versions of the programs differ in this from everyone
> else would create a lot of confusion, and needlessly cause everyone
> more support burden than is needed.

Isn't that the same case with the FHS?

To bring an example here from my ongoing packaging projects: IRAF [1]
uses /iraf/ as the root path for its directory structure as standard,
and they are probably not going to change this. So, with Debian
deviating from everyone else here would probably also create a lot of
confusion; however I will ofcourse obey the policy here.

Also, the XDG is made to *unify* the structure, not just between
programs, but also between (Desktop Linux/Unix) platforms.

> Please do contribute to any upstream projects that interest you to add
> support for XDG, but don't try to make it mandatory in Debian.

I don't mean it as a strong requirement (yet); but couldn't this be
included in the policy as recommendation and/or goal?

Best regards

Ole

[1] http://bugs.debian.org/690531


-- 
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/87hacn633a@news.ole.ath.cx

Insufficient RAM on build-machines (was Bug#726009: yade: FTBFS on i386 (and others))

2013-10-11 Thread Anton Gladky 
severity 726009 wishlist
retitle 726009 Yade requires too much RAM for building
thanks

Hello,

thanks for bug-report. The problem is, that all build-failures are due
to insufficient RAM on build-machines [1]. I do not really know how to
"fix" that except of backlisting of some machines, as was suggested by
Julien [2]. The same package builds fine on Launchpad's PPA. It seems,
the package builds only on machines, where >4Gb RAM is available.

Thus I am reducing the bug's severity and CC-ing -devel with the hope to
get dome more ideas how to fix the problem.

I am also one of upstream-authors of this software and during last
several years we did not add to the code something, what can
sufficiently increase RAM-consumption.

[1] https://buildd.debian.org/status/package.php?p=yade
[2] https://lists.debian.org/debian-science/2013/10/msg7.html

Thanks,

Anton



On 10/11/2013 09:12 AM, Ralf Treinen wrote:
> Source: yade
> Version: 1.00.0-2
> Severity: serious
> User: trei...@debian.org
> Usertags: edos-outdated
> 
> Hello,
> 
> yade 1.00.0-2 FTBFS on the i396 autobuilder with message:
> 
> /usr/bin/c++   -Dyade_EXPORTS -g -O2 -fstack-protector 
> --param=ssp-buffer-size=4 -Wformat -Werror=format-security 
> -D_FORTIFY_SOURCE=2  -DYADE_PTR_CAST=static_pointer_cast 
> -DYADE_CAST=static_cast -fPIC -DYADE_VTK -DYADE_OPENMP -fopenmp -DYADE_GTS  
> -DQGLVIEWER_FOUND -DYADE_OPENGL -frounding-math -DYADE_CGAL -DFLOW_ENGINE 
> -frounding-math -DLINSOLV -DFLOW_ENGINE -DYADE_GL2PS -O3 -DNDEBUG -fPIC 
> -I/usr/lib/pymodules/python2.7/numpy/core/include -I/usr/include/eigen3 
> -I/usr/include/vtk-5.8 -I/usr/include/glib-2.0 
> -I/usr/lib/i386-linux-gnu/glib-2.0/include -I/usr/include/qt4/QtDesigner 
> -I/usr/include/qt4/QtDeclarative -I/usr/include/qt4/QtScriptTools 
> -I/usr/include/qt4/QtDBus -I/usr/include/qt4/QtXml -I/usr/include/qt4/QtSql 
> -I/usr/include/qt4/QtOpenGL -I/usr/include/qt4/QtNetwork 
> -I/usr/include/qt4/QtXmlPatterns -I/usr/include/qt4/QtHelp 
> -I/usr/include/qt4/QtUiTools -I/usr/include/qt4/QtTest 
> -I/usr/include/qt4/QtScript -I/usr/include/qt4/QtSvg 
> -I/usr/include/qt4/Qt3Support -I/usr/include/q
t4/QtGui -I/usr/include/qt4/QtCore -I/usr/share/qt4/mkspecs/default 
-I/usr/include/qt4 -I/usr/include/suitesparse -I/usr/include/python2.7 
-I/usr/include/i386-linux-gnu/python2.7 
-I/«PKGBUILDDIR»/extra/floating_point_utilities_v3 
-I/«PKGBUILDDIR»/debian/build-o 
CMakeFiles/yade.dir/pkg/dem/DomainLimiter.cpp.o -c 
/«PKGBUILDDIR»/pkg/dem/DomainLimiter.cpp
> virtual memory exhausted: Cannot allocate memory
> make[3]: *** [CMakeFiles/yade.dir/pkg/dem/DomainLimiter.cpp.o] Error 1
> make[3]: Leaving directory `/«PKGBUILDDIR»/debian/build'
> make[2]: *** [CMakeFiles/yade.dir/all] Error 2
> make[2]: Leaving directory `/«PKGBUILDDIR»/debian/build'
> make[1]: *** [all] Error 2
> make[1]: Leaving directory `/«PKGBUILDDIR»/debian/build'
> dh_auto_build: make -j1 returned exit code 2
> make: *** [build-arch] Error 2
> dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2
> 
> See
> 
> https://buildd.debian.org/status/fetch.php?pkg=yade&arch=i386&ver=1.00.0-2&stamp=1380696072
> 
> There are also build failures on other architectures.
> 
> -Ralf.
> 




signature.asc
Description: OpenPGP digital signature

Re: Debian XDG basedir compliance

2013-10-11 Thread Wookey 
+++ Lars Wirzenius [2013-10-11 18:48 +0100]:
> On Fri, Oct 11, 2013 at 07:17:32PM +0200, Olе Streicher wrote:
> > What are the status, the pros and cons here? Is there an attempt to get
> > the XDG somehow into the Debian policy?
> 
> There is no active Debian effort to make all our packages to conform
> to the XDG directory spec. It is my understanding that the consensus
> within Debian is that it is beyond our scope, and is something that's
> best done by our upstream projects directly. That way, the results
> would be shared by all users of the programs, instead of just the
> Debian users of those programs. Having Debian versions of the programs
> differ in this from everyone else would create a lot of confusion, and
> needlessly cause everyone more support burden than is needed.

I made upstream support XDG when I packaged something recently. He was
a bit grumpy because it made linux different from other OSes (it was a
java GUI app), but it seemed to me that this was the right thing to do.
(The default was to store data in CWD so you ended up with a lot of
dirs called 'data' on your disk, instead of one called '.terraintool'
in $XDGHOME)

This was done upstream, not just for Debian, so conforms with what
you've said above, although I wasn't aware of any particular consensus.

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.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/20131011180533.gr32...@stoneboat.aleph1.co.uk

Re: Debian XDG basedir compliance

2013-10-11 Thread Lars Wirzenius 
On Fri, Oct 11, 2013 at 07:17:32PM +0200, Olе Streicher wrote:
> What are the status, the pros and cons here? Is there an attempt to get
> the XDG somehow into the Debian policy?

There is no active Debian effort to make all our packages to conform
to the XDG directory spec. It is my understanding that the consensus
within Debian is that it is beyond our scope, and is something that's
best done by our upstream projects directly. That way, the results
would be shared by all users of the programs, instead of just the
Debian users of those programs. Having Debian versions of the programs
differ in this from everyone else would create a lot of confusion, and
needlessly cause everyone more support burden than is needed.

Please do contribute to any upstream projects that interest you to add
support for XDG, but don't try to make it mandatory in Debian.

-- 
http://www.cafepress.com/trunktees -- geeky funny T-shirts
http://gtdfh.branchable.com/ -- GTD for hackers


-- 
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/20131011174801.gu5...@mavolio.codethink.co.uk

Debian XDG basedir compliance

2013-10-11 Thread Olе Streicher 
Hi,

for one of my packages (astropy), I am currently in discussion with
upstream on whether the XDG rules shoule be applied [1]. I am arguing
there that for a new software, it would be better to follow this
standard.

The XDG basedir specification [2] basically defines where user specific
configuration files, data, and cache files should be placed.

However, I found that a lot of software on Debian seems to be not XDG
compliant yet, and I am wondering if there is any attempt to change
this. XDG compliant seem to be mostly GUI oriented programs (like LO,
VLC or the desktop environments), while classic command line programs
(with the shells on first place) seem to ignore the standard.

What are the status, the pros and cons here? Is there an attempt to get
the XDG somehow into the Debian policy?

Best regards

Ole

[1] https://groups.google.com/d/msg/astropy-dev/YiTZl43CAg8/AwSZSONpQdcJ
[2] http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html


-- 
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/87pprb682b@news.ole.ath.cx

Re: automake transition breakages

2013-10-11 Thread Ian Jackson 
Russ Allbery writes ("Re: automake transition breakages"):
> Cyril Brulebois  writes:
> > Meaning one needs to get a fix once; a random NMUer might need to chase
> > upstream patches (never a pleasure when fixing unrelated issues). Given
> > what you wrote, I'm not sure what it buys us to keep -Werror in
> > distribution packages, except for the possibly ticking time bomb.
> 
> Well, the simple answer is that we avoid having to maintain local patches
> against the upstream source to remove -Werror, since generally it's not
> something over which we have a choice without patching the upstream
> source.  It's usually expressed in configure.ac.

I don't think this is a sufficiently good reason to take the
portability hit.

Think, for example, about downstreams (including users) who may want
to forward-port a package to a different Debian release and thus a
different automake version.

For such a central tool as automake, we should tolerate lots of
version skew slop.

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

Bug#726042: ITP: libconvert-ascii85-perl -- Encoding and decoding of ascii85/base85 strings

2013-10-11 Thread Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 
Package: wnpp
Owner: Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 (CPAN/PAUSE) 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org

* Package name: libconvert-ascii85-perl
  Version : 0.01
  Upstream Author : Lukas Mai 
* URL : https://metacpan.org/release/Convert-Ascii85
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Encoding and decoding of ascii85/base85 strings

Convert::Ascii85 implements the Ascii85 (also known as Base85)
algorithm for encoding binary data as text. This is done by
interpreting each group of four bytes as a 32-bit integer, which is
then converted to a five-digit base-85 representation using the digits
from ASCII 33 (!) to 117 (u).

This is similar to MIME::Base64 but more space efficient: The overhead
is only 1/4 of the original data (as opposed to 1/3 for Base64).

This description was automagically extracted from the module by
dh-make-perl.




signature.asc
Description: PGP signature

Bug#726026: ITP: libtypes-path-tiny-perl -- Path::Tiny types and coercions for Moose and Moo

2013-10-11 Thread Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 
Package: wnpp
Owner: Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 (CPAN/PAUSE) 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org

* Package name: libtypes-path-tiny-perl
  Version : 0.005
  Upstream Author : David Golden 
* URL : https://metacpan.org/release/Types-Path-Tiny
* License : Apache-2.0
  Programming Lang: Perl
  Description : Path::Tiny types and coercions for Moose and Moo

Types::Path::Tiny provides Path::Tiny types for Moose, Moo, etc.

It handles two important types of coercion:

 • coercing objects with overloaded stringification
 • coercing to absolute paths

It also can check to ensure that files or directories exist.




signature.asc
Description: PGP signature

Bug#726025: ITP: tigris -- Stream-based JSON string escaping for Clojure

2013-10-11 Thread Wolodja Wentland 
Package: wnpp
Severity: wishlist
Owner: Wolodja Wentland 

* Package name: tigris
  Version : 0.1.1
  Upstream Author : Matthew Lee Hinman 
* URL : https://github.com/dakrone/tigris
* License : EPL-1.0
  Programming Lang: Clojure, Java
  Description : Stream-based JSON string escaping for Clojure

Tigris is a Clojure library providing a stream for escaping JSON strings as
 they are being read from a different stream. This stream-to-stream string
 encoding allows for easy integration of JSON escaping into your data
 processing pipeline.


-- 
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/20131011102613.15814.2216.reportbug@asasello.local