Re: [Pkg-javascript-devel] Node.js and it's future in debian

2012-05-05 Thread Philip Hands 
On Fri, 4 May 2012 19:00:10 +0200, Pau Garcia i Quiles  
wrote:
...
> Agreed. That's why my proposal was that *all* of those (Debian,
> Fedora, Suse, MacPorts and brew) did the rename, not just us (Debian).
> It's certainly not nice to push upstream to do something they don't
> want to do, but when upstream is not doing their due diligence...

As a lapsed HAM who's not transmitted anything for about 20 years, and
someone vaguely aware of node.js, I feel relatively unbiased about this.

How about doing the following:

  node package replaced by a node-legacy package that contains no more
  than a README and a symlink node --> ax25-node, and depends on
  ax25-node

  ax25-node package, which contains what node does now, with the binary
  renamed

  nodejs package replaced by a node.js-legacy (or a better name if there
  is one) package that contains no more than a README and a symlink node
  --> node.js (or whatever), and depends on node.js

  node.js package that is the nodejs package with a renamed binary.

and make node-legacy and  node.js-legacy conflict.

The problems with this would seem to be the potential pain of renaming
packages, and the fact that using conflicts like that is a policy
violation -- could we perhaps make an exception for a case like this on
the basis that the package descriptions could spell out why the
conflict is there.

The result would be that either camp can install the -legacy package and
carry on unaffected, and anyone that needs both simply avoids the
-legacy packages, and fixes any hard-coded paths on their system, which
they'll know to do because they'll be a (probably more cluefull than
average) combined HAM and Node.js user who's been pointed at the READMEs
by the conflict and the package descriptions.

The -legacy naming will apply a gentle pressure to just use the real
packages, which will leave the door open to upstreams to see the light
and change their default name, but not so much pressure that they'll get
upset about it.

The READMEs of all the packages could refer to why this was done, and
how to get what you want depending one which of the various permutations
of behaviours you want.

So this would need package replacement, which is a pain, and an
exception for a policy violation -- is that enough to kill the idea?

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


pgp6pmjLaSL3o.pgp
Description: PGP signature

Re: How often is any package tested for FTBS on main arch ?

2012-05-05 Thread Dominique Dumont 
Le Friday 4 May 2012 11:09:52, Neil Williams a écrit :
> Dominique Dumont  wrote:
> > We, sdl maintainers, made a recent change in our package by removing
> > unnecessary build depends on -dev packages [1].
> 
> ... at which point you should have looked at the list of reverse
> dependencies and done some tests yourselves before uploading ...
> 
> i.e. not rebuild all 400 necessarily but to identify those which of
> those 400 do not already build-depend on the packages you removed and at
> least let the maintainers of the packages know that your change may
> reveal an RC bug in their packages.

Sorry, no. SDL team was recenty reconstructed from scratch [1] and we have 
only 2 active people. I don't count myself as active in sdl team as I mostly 
do package reviews and upload. We just don't have the time to perform what you 
suggest just to compensate for easy-to-fix packaging mistakes.

> > Unfortunately, some package did rely on this "extra" dependencies and
> > went ftbs [2].
> 
> ... which could, arguably, be jointly your fault as this could have
> been handled cleanly if done so in advance.

Not my fault, nor current team's fault: this mistake was done years ago. We 
are still cleaning up what we found.

> Yes, the maintainer of the
> other packages made a mistake by relying on indirect dependencies (it's
> usually best to build-depend on everything you check for in your
> configure stage) but that bug was revealed by your change, so it would
> have been helpful to raise this as a problem in advance.

Agreed. I admit I did not foresee the potential problem.

> How about doing the real work instead and identifying which packages
> might be affected, alerting those maintainers and starting a few
> rebuild tests of this shortened list? Then you've got some real data
> to make the decision about what to do.

Actually, the whole point of my mail was to gather real data from work already 
done. Thanks to Lucas, we know about failing packages. Too bad we don't know 
about succeeding packages.


All the best

[1] http://ddumont.wordpress.com/2011/11/19/sdl-team-revival/

Dominique


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

Re: Bug#671302: Circular Build Dependencies (was Bug#671302: libav: circular dependency between libav and opencv)

2012-05-05 Thread Simon McVittie 
On 04/05/12 21:45, Andres Mejia wrote:
> On May 4, 2012 4:43 PM, "Fabian Greffrath"  > wrote:
>>
>> > libav -> x264 -> libav
>>
>> AFAICT the x264 frontend uses libav whereas libav uses the libx264 shared
>> library. So theortically (!) this issue could be solved by two separate
>> source packages for the x264 frontend and the library.

This would also be pretty straightforward via the DebianBootstrap
proposal from the wiki: the stage-1 build of x264 would only compile the
library, and omit the front-end.

I believe the current state-of-the-art for bootstrapping new
architectures, or getting a particularly "slow" architecture caught up,
is essentially to do the equivalent of that proposal, but by hand
(dpkg-buildpackage -d, and maybe temporary source changes that are never
uploaded).

dbus and dbus-glib also have cyclic build-dependencies: you can break
the cycle by ignoring the dbus-glib dependency (which means most of the
dbus regression tests aren't compiled), then building dbus-glib, then
rebuilding dbus against it. In the absence of a finalized version of the
bootstrap proposal, this is documented in comments in debian/control.

> This doesn't resolve the issue with opencv though.

What's the cycle here? Can it also be broken by temporarily taking out
similar optional functionality - tests or front-ends or something?

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/4fa4f75f.6060...@debian.org

Re: How often is any package tested for FTBS on main arch ?

2012-05-05 Thread Neil Williams 
On Sat, 5 May 2012 11:34:45 +0200
Dominique Dumont  wrote:

> > i.e. not rebuild all 400 necessarily but to identify those which of
> > those 400 do not already build-depend on the packages you removed and at
> > least let the maintainers of the packages know that your change may
> > reveal an RC bug in their packages.
> 
> Sorry, no. SDL team was recenty reconstructed from scratch [1] and we have 
> only 2 active people. I don't count myself as active in sdl team as I mostly 
> do package reviews and upload. We just don't have the time to perform what 
> you 
> suggest just to compensate for easy-to-fix packaging mistakes.

It really isn't that much work to scan through apt-cache rdepends and
then check that against Sources.gz to get a list of collated
Build-Depends.

If the new team don't have time to write and run a short script then
maybe the package would have been better off without the upload.
Maintenance is not about being an automaton with a GPG key and a
package review should include the implications of the changes on
other packages which use the package being reviewed. 

> > > Unfortunately, some package did rely on this "extra" dependencies and
> > > went ftbs [2].
> > 
> > ... which could, arguably, be jointly your fault as this could have
> > been handled cleanly if done so in advance.
> 
> Not my fault, nor current team's fault: this mistake was done years ago. We 
> are still cleaning up what we found.

The original mistake, yes, but then the package didn't FTBFS. Those
failures arise from the change you made. Albeit for sensible reasons but
not *compulsory* reasons - there is no requirement to drop unnecessary
build-dependencies, the requirement is not be lacking build
dependencies. IMHO it's perfectly acceptable to have redundant
build-dependencies *where removing them would cause breakage elsewhere*
as this gives an opportunity to get those issues fixed smoothly.

What has been achieved by removing those build-dependencies? Your
package is a bit cleaner and Debian is a bit more broken. Gee, thanks.
Less work for you, more work for the rest of us and without even a
heads-up or thought of the consequences. Sounds like you're taking more
than just Lucas for granted.

I don't seek to diminish the problems in the other packages - as Russ
points out, those packages are already ignoring Policy - but solving
those Policy issues without generating RC bugs en masse would have been
so much better.

In effect, the package upload has induced a mass bug filing without any
checks or attempts at detection let alone prevention, in the expectation
that someone else will not only pick up the pieces but identify where
things have been broken by *your* change.

To not even bother checking what might break until *AFTER* the upload
is beyond careless, it is presumptive. Maintainers of libraries have
responsibilities to the maintainers of packages which are reverse
dependencies - those include handling things like SONAME changes API
breakage cleanly and alerting them to upcoming changes with sufficient
time that packages can be adapted without breakage. If time is allowed
and nothing happens, so be it, but to upload and then confess to the
breakage only after packages have failed to build is poor.

> Actually, the whole point of my mail was to gather real data from work 
> already 
> done. Thanks to Lucas, we know about failing packages. Too bad we don't know 
> about succeeding packages.

That would have been fine but the upload had been made without this
check being done. This could have been so much better if the discussion
had preceded the upload.

-- 


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



pgpiHh1jYOfAa.pgp
Description: PGP signature

Re: switching from exim to postfix

2012-05-05 Thread George Danchev 
On Monday 30 April 2012 12:58:18 Carsten Hey wrote:

Hi,

> The rest of this mail is likely not interesting for most of you since it
> only tries to answer the natural follow up question "Why does it need
> a cronjob then?" and explains why I don't think anymore that a switch to
> incron should be considered.
> 
> 
> Two reasons for running dma -q via cronjob in my own words but stolen
> from README.Debian are:
>  * If the queue is not empty after reboot, dma -q needs to be run at
>least once to start delivering these mails.  A @reboot cronjob or an
>init script would also to this job.

This still holds.

>  * Delivery processes might die for various reasons, but the mails still
>need to be delivered in a timely manner.

Then 'dma -q' will exit with non-zero status, and could be retried 
chronologically (every 5 min.) until it succeeds.

> If dma would be the default MTA, then it should IMHO be as reliable as
> possible and even try to prevent user errors.  If a user would
> unintentionally enables deferred mode (which is useful if you are behind
> a dial-up line) but would not set up dma -q to run periodically, then
> the mails would not be delivered without such a default cronjob.
> A comment that reminds users to adapt the cronjob if needed should be
> added to the config file.  If dma -q is run every 5 minutes be default
> anyway, the option -bq does not make that much sense anymore; this can
> possibly be solved by implementing different ways of processing queued
> mails.  All in all, enabling the cronjob by default, as it is already
> done in Debian, seems to be sane.
> 
> > I think that was Carsten's point about switching to incron, which
> > would then do the right thing for new outgoing mail.
> 
> This is a reasonable and logical assumption, but it is wrong ;)
> 
> Actually the reason to mention incron was that I thought that running
> dma -q if triggered by inotify could be a bit cheaper than running it
> every five minutes.  For a default MTA, the amount of systems that run
> it could make considering even minimal differences in efficiency
> worthwhile.
> 
> The idea was to use incron to restart failed delivery processes, if this
> would be possible at all depends on details of dma and incron/inotify
> I'm not aware off.  An additional reason to the explanation above not to
> use incron is that in rare cases dma might fail for example with ENOMEM
> whilst reading its configuration file before it is able to open any file
> in the spool dir, which would render running it by incron to be not 100%
> bullet proof anyway.

Actually, I still think that your idea of utilizing incron to trigger mail 
queue flushing actions (inotify event-based), makes sense. We just need to 
complete the chronological part (for the failed attempts) of the whole task.

While it is true that incron will not restart a failed dma run (AFAICT looking 
at its current code; the failure will only be registered in the syslog and not 
re-tried), it is also true that this task could be offloaded to a wrapper which 
is to be started by incron when a file creation event happens for the mail 
spool directory. The fact is that 'dma -q' will only exit with zero status if 
it successfully and fully has flushed the mail queue. Having this in mind, I 
think that some idempotent wrapper script around dma -q, which is to be 
started by incron, should take a decent care of the whole job of flushing new 
and failed mail found in spool.

It is of course not at the stage of 'verified design' and probably racy.

#!/bin/sh

SELF=`basename ${0}`
DELAY=300
RUNNING=1

is_running() {
# check for any dma instances
pidof dma >/dev/null
case $? in
0)
echo -n "dma is already running..."
RUNNING=1
return
;;
esac

# check for any instances of $SELF, excluding ourselves
pidof -o %PPID -x ${SELF} >/dev/null
case $? in
0)
echo -n "$SELF is already running..."
RUNNING=1
return
;;
esac
RUNNING=0
}

while true; do
echo -n "Attempting to flush..."
is_running
if test $RUNNING = 1; then
echo "Retrying in $DELAY seconds."
sleep $DELAY
continue
fi
/usr/sbin/dma -D -q 2>/dev/null
if test $? = 0; then
echo "ok."
break;
fi
echo "FAIL. Retrying in $DELAY seconds."
sleep $DELAY
done


-- 
pub 4096R/0E4BD0AB 


-- 
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/201205051529.44816.danc...@spnet.net

Bug#671615: ITP: libgeo-point-perl -- module to simplify handling geographic points

2012-05-05 Thread Jonas Smedegaard 
Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

* Package name: libgeo-point-perl
  Version : 0.93
  Upstream Author : Mark Overmeer 
* URL : http://search.cpan.org/dist/Geo-point/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : module to simplify handling geographic points

 One location on the globe, in any coordinate system. Geo::Point tries
 to hide the maths and the coordinate system in which the point is
 represented.
 .
 One of the most confusing things when handling geometrical data, is
 that sometimes latlong, sometimes xy are used: horizontal and vertical
 organization reversed. This package tries to hide this from your
 program by providing abstract accessors latlong(), longlat(), xy(), and
 yx().
 .
 This package provides the following modules:
  * Geo::Line - a sequence of connected points
  * Geo::Point - a point on the globe
  * Geo::Proj - simplified wrapper for Geo::Proj4
  * Geo::Shape - base class for 2-dimensional points on the earth
surface
  * Geo::Space - A collection of various items
  * Geo::Surface - A surface description



-- 
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/20120505120057.11295.64386.report...@auryn.jones.dk

Bug#671627: RFH: spice - Simple Protocol for Independent Computing Environment

2012-05-05 Thread Liang Guo 
Package: wnpp
Severity: normal
X-Debbugs-CC: debian-devel@lists.debian.org

Hi, 

I'm looking for co-maintainers of package spice. Current spice
embeds celt051, an obsolete version of celt, so we intend to 
remove celt051 support in spice, but I don't have enought time,
sufficient knowledge and necessary equipments to complete this
job, if someone interesting on this package, please let me know. 
For the history of celt problem, please reference to [1].

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=603699

If someone interesting in this package, other private discussion
on this topic can be forwarded. 

Thanks and Regards,
--
Liang Guo
http://bluestone.cublog.cn


signature.asc
Description: Digital signature

Bug#671634: ITP: python-roman -- Python module for generating/analyzing Roman numerals

2012-05-05 Thread Jakub Wilk 

Package: wnpp
Severity: wishlist
Owner: Jakub Wilk 

* Package name: python-roman
  Version : 1.4
  Upstream Author : Mark Pilgrim
* URL : http://pypi.python.org/pypi/roman/
* License : Python 2.1.1 license
  Programming Lang: Python
  Description : Python module for generating/analyzing Roman numerals

This module converts from and to Roman numerals. It can convert numbers 
from 1 to 4999 and understands the common shortcuts (IX == 9), but not 
illegal ones (MIM == 1999).


(This used to be built form the python-docutils package, but now is 
going to be packaged separately.)


--
Jakub Wilk



--
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/20120505142153.ga3...@jwilk.net

Bug#671650: ITP: libfile-spec-native-perl -- module for using native OS implementation of File::Spec from a subclass

2012-05-05 Thread gregor herrmann 
Package: wnpp
Owner: gregor herrmann 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org

* Package name: libfile-spec-native-perl
  Version : 1.003
  Upstream Author : Randy Stauner 
* URL : http://search.cpan.org/dist/File-Spec-Native/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : module for using native OS implementation of File::Spec 
from a subclass

File::Spec::Native is a stupid hack to make the default File::Spec behavior
available from a subclass. This can be useful when using another module that
expects a subclass of File::Spec but you want to use the current, native OS
format (automatically detected by File::Spec).

For example: Path::Class/as_foreign (as of version 0.24) allows you to
translate a Path::Class object from one OS format to another. However, there
is no way to specify that you want to translate the path into the current,
native OS format without guessing at what that format is (which may include
peeking into @File::Spec::ISA).

This module @ISA File::Spec.



-- 
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/20120505160522.ga30...@jadzia.comodo.priv.at

Bug#671654: ITP: libdist-metadata-perl -- module for getting information about a perl module distribution

2012-05-05 Thread gregor herrmann 
Package: wnpp
Owner: gregor herrmann 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org

* Package name: libdist-metadata-perl
  Version : 0.922
  Upstream Author : Randy Stauner 
* URL : http://search.cpan.org/dist/Dist-Metadata/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : module for getting information about a perl module 
distribution

Dist::Metadata provides an easy interface for getting various metadata about
a Perl module distribution.

This is mostly a wrapper around CPAN::Meta providing an easy interface to
find and load the meta file from a tar.gz file. A dist can also be
represented by a directory or merely a structure of data.

If the dist does not contain a meta file the module will attempt to determine
some of that data from the dist.



-- 
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/20120505161508.ga8...@jadzia.comodo.priv.at

Bug#671656: ITP: libmodule-cpanfile-perl -- format for describing CPAN dependencies of Perl applications

2012-05-05 Thread gregor herrmann 
Package: wnpp
Owner: gregor herrmann 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org

* Package name: libmodule-cpanfile-perl
  Version : 0.9007
  Upstream Author : Tatsuhiko Miyagawa
* URL : http://search.cpan.org/dist/Module-CPANfile/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : format for describing CPAN dependencies of Perl applications

`cpanfile` describes CPAN dependencies required to execute associated Perl
code.

Place the `cpanfile` in the root of the directory containing the associated
code. For instance, in a Catalyst application, place the `cpanfile` in the
same directory as `myapp.conf`.

Tools supporting `cpanfile` format (e.g. cpanm and carton) will automatically
detect the file and install dependencies for the code to run.



-- 
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/20120505163108.ga...@jadzia.comodo.priv.at

Processed: Re: Bug#671503: general: APT repository format is not documented

2012-05-05 Thread Debian Bug Tracking System 
Processing commands for cont...@bugs.debian.org:

> reassign 671503 debian-policy
Bug #671503 [general] general: APT repository format is not documented
Bug reassigned from package 'general' to 'debian-policy'.
Ignoring request to alter found versions of bug #671503 to the same values 
previously set
Ignoring request to alter fixed versions of bug #671503 to the same values 
previously set
> thanks
Stopping processing here.

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

Re: Bug#671503: general: APT repository format is not documented

2012-05-05 Thread Joerg Jaspert 
On 12836 March 1977, David Kalnischkies wrote:

> I would personal tend toward ftp-master to be the authority with reference
> implementation being dak, but they have no public mailinglist and dak isn't
> used by all derivatives…

debian-dak@lists.d.o

On 12836 March 1977, Russ Allbery wrote:

> I would be happy to maintain this as a sub-Policy as part of the
> debian-policy package and (subject to my always insufficient time
> available) be happy to handle the mechanics of formatting and wordsmithing
> updates, but don't personally have time to write the original text or to
> investigate and document changes.

> A prerequisite for this working properly would be for ftp-master to feel
> like they could send updates to somewhere and have them be absorbed and
> handled by someone.  I don't think it's going to be viable to add having
> to write the documentation as yet another ftp-master task, nor do I think
> it would be viable to expect someone outside the group making changes to
> reverse-engineer and guess at the changes.  It would need to be a
> cooperation between notification of changes from the folks working on them
> and someone doing the wordsmithing and turning that into a document.

We could deal with that, yes.

-- 
bye, Joerg
1. 0  2. 1  3. 2  4. 3  5. 4  6. 5  7. 6  8. 7
|-) What sort of FTP proxy firewall do you have?
   -- libnet-perl 1.16-1


--
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/8762cabfsk@gkar.ganneff.de

pbuilder + ccache suddenly fails

2012-05-05 Thread Steve M. Robbins 
I've routinely used pbuilder to build packages for years.
Yesterday, I have started to see the following failure:

ccache: FATAL: Failed to create /var/cache/pbuilder/ccache/0/f: Permission 
denied

Any idea what's going on?  Google found only one other mention of this
[1].

Thanks,
-Steve


[1] http://lists.debian.org/debian-mentors/2012/02/msg00490.html

signature.asc
Description: Digital signature

Re: Bug#671503: general: APT repository format is not documented

2012-05-05 Thread Paul Wise 
On Sat, May 5, 2012 at 5:13 AM, Russ Allbery wrote:

> I think debian-policy is the right repository for this.  I think it would
> make the most sense to maintain this via a looser update method than the
> normal Policy process and to instead just apply any update that ftp-master
> says is in place, since the decision-making is already handled through
> ftp-master and other discussions and there's not much to be gained by an
> additional decision process.

As someone who has been working on validating the apt repository
metadata from our derivatives, I would greatly appreciate it if
debian-policy documented that metadata, especially the Release files.

-- 
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/caktje6f7nzndsjrwuoq2qwo2rcxtn60hkqlg_fuz2_unha3...@mail.gmail.com