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

[Thibaut Paumard]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

Le 05/05/12 09:29, Philip Hands a écrit :
> 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.

I'm just an unbiased reader of Debian devel, I don't care for either
package (but I care for Debian). Your proposal seems very sane to me.

> 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

In addition, node-legacy could Provide node, so that it is installed
on system upgrade for systems where it was there before, with an
explanation that this package is for transition purpose and the
implications of removing it.
[...]
> So this would need package replacement, which is a pain, and an 
> exception for a policy violation -- is that enough to kill the
> idea?

As I understand it, Policy is broken here: if the two binaries where
installed in /usr/bin, it would be fine (Policy-wise) to Conflict.  We
have here a rare (hopefully) instance where the conflicting command
name are not file conflicts, which just happens to be badly handled by
policy.

Regards, Thibaut.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+mRFUACgkQ+37NkUuUiPGwcgCeNr1mPo3+dIlx3SE02jY7bNXj
6/oAn12ubOx94mneghPABCuQeKisi3L3
=SNV0
-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/4fa64455.7020...@users.sourceforge.net

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

[Dominique Dumont]

Le Saturday 5 May 2012 12:29:03, Neil Williams a écrit :
> 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.

ok. there's a misunderstanding. I do not want to justify the upload that was 
done without prior communication: This was a mistake. Mistakes happens. If a 
similar situation occurs, proper communication will be done before upload.


All the best

Dominique


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

Bug#671744: ITP: rutorrent -- a web front-end for the rtorrent client

[Andriy Senkovych]

Package: wnpp
Severity: wishlist
Owner: Andriy Senkovych 

* Package name: rutorrent
  Version : 3.4
  Upstream Author : Alexander Moskalets 
* URL : http://code.google.com/p/rutorrent/
* License : GPLv3
  Programming Lang: PHP
  Description : a web front-end for the rtorrent client

 rutorrent is a web frontend for rtorrent designed to emulate the look and feel
 of µTorrent WebUI. The name "RuTorrent" is the combination of µTorrent and
 rTorrent.
..
 The original version of ruTorrent was based on an older version of µTorrent
 WebUI but has been completely rewritten as of 3.0. 
..
 Features:
..
  * lightweight server side, so it can be installed on old and low-end servers
 and even on some SOHO routers;
  * customizable - a bunch of plugins available including geoip, RSS feeds
support, cpu and disk monitoring, schedulers and others
  * nice look


P.S. This project is starred by 530 people on google code (there are 32 '+1's
as well). I'm using this software myself and find it quite useful.



-- 
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/20120506150109.5485.76366.reportbug@gamma.trdata.local

Re: Fwd: Re: Bug#614907: nodejs/node command conflict: why can't we have both?

[Bernd Zeimetz]

On 05/04/2012 12:38 AM, Carsten Hey wrote:
> Should not at least @debian.org addresses by default be whitelisted on
> the tech-ctte list?

I don't think so - the BTS is usefull to ensure that all discussion to a bug is
collected at one place and not spread between the bug and the mailinglist.

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F


-- 
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/4fa6a7de.5090...@bzed.de

Re: Circular Build Dependencies

[Andres Mejia]

On Fri, May 4, 2012 at 4:21 AM, Goswin von Brederlow  wrote:
> Andres Mejia  writes:
>
>> On May 3, 2012 10:20 AM, "Andres Mejia"  wrote:
>>>
>>> On May 3, 2012 9:30 AM, "Pino Toscano"  wrote:
>>> >
>>> > Alle giovedì 3 maggio 2012, Andres Mejia ha scritto:
>>> > > On Thu, May 3, 2012 at 3:44 AM, Pino Toscano  wrote:
>>> > > > Package: libav
>>> > > > Version: 6:0.8.1-7
>>> > > > Severity: important
>>> > > >
>>> > > > Hi,
>>> > > >
>>> > > > libav 6:0.8.1-7 reenables the use of opencv... which itself uses
>>> > > > libav libraries. This currently makes libav unbuildable on mipsel
>>> > > > and hurd-i386, and generically makes libav no more bootstrap'able
>>> > > > without having itself compiled already.
>>> > > > Could you please drop the opencv usage again, please?
>>> > > >
>>> > > What could be done instead is a binary only upload with opencv
>>> > > support disabled (i.e. use dpkg-buildpackage -B). Doing it on our
>>> > > end will not require changing the version. Once this package is
>>> > > uploaded, the release team can then be asked to do a binNMU for
>>> > > these archs, which will bring back opencv support since the archive
>>> > > will contain the regular *.debian.tar.gz changes that included
>>> > > opencv.
>>> > >
>>> > > I believe this is better than doing a full build on all archs without
>>> > > opencv, then doing another build with opencv.
>>> >
>>> > This mess (which is only a mess, not a clean solution) does not solve at
>>> > all the fact that you cannot do a clean build of libav without having
>>> > libav compiled already (for opencv).
>>> > I don't see this as a viable solution, especially if in the future the
>>> > epoch is raised bringing again conflicts between the old libav libraries
>>> > and the new one.
>>> >
>>> > --
>>> > Pino Toscano
>>>
>>> I'm not entirely certain how build circular dependency issues like this are
>> resolved. Perhaps we should ask for help from the toolchain package 
>> maintainers
>> or debian-devel.
>>>
>>> ~ Andres
>>
>> Hello all,
>> I would like to know if there is a good (perhaps best) approach in resolving
>> issues with packages with circular build dependencies.
>>
>> Libav has various circular build dependencies including.
>>
>> libav -> opencv -> libav
>> libav -> x264 -> libav
>> libav -> x264 -> gpac -> libav
>>
>> I found some mention of this issue at [1]. This however doesn't offer any 
>> clear
>> solution.
>>
>> 1. http://wiki.debian.org/DebianBootstrap
>>
>> ~ Andres
>
> gcc depends on gcc. *gasp*
>
> I think at some point you simply have to live with such circular
> Build-Depends. [1] offers a solution, or the begining of one, using
> stages (see Mechanism). What is unclear about the idea?

I had meant there is no clear solution that can be used now.

> MfG
>        Goswin


-- 
~ Andres


--
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/capm41nnf4w10vy1g+e0ux_-ijcuj0ednzpsommvqt12h1dx...@mail.gmail.com

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

[Andres Mejia]

On Sat, May 5, 2012 at 5:48 AM, Simon McVittie  wrote:
> 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?

It was libav -> opencv -> libav. It can be broken by temporarily
taking out opencv support.

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

I suppose the proposal offers a good solution to break these circular
build dependencies. I imagine the buildd network can treat these
staged build depends as regular build depends (i.e. have states like
"Stage N BD-Uninstallable"). It can iterate through the stages
starting from the final stage until the first stage, checking which
stage it can build. Then from there, it can iterate back up the
stages, building each stage until it builds the final stage packages.

So something like this.

STAGE_BUILDS
stage = n
for i from n to 1
stage = i
if build depends for stage i satisfiable then
break
for i from stage to n
build stage i

-- 
~ Andres


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

Re: pbuilder + ccache suddenly fails

[Andres Mejia]

On Sat, May 5, 2012 at 9:57 PM, Steve M. Robbins  wrote:
> 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

You should instead not enable ccache inside builds using pbuilder or
sbuild since the directories where these builds occur end up being
deleted, thus deleting the output generated from ccache.

-- 
~ Andres


--
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/CAPM41nN=-qkuzedg+p9uvitg0f2zsxjtsaitxc5nfa1nk5h...@mail.gmail.com

Re: pbuilder + ccache suddenly fails

[Steve M. Robbins]

On Sun, May 06, 2012 at 01:21:57PM -0400, Andres Mejia wrote:
> On Sat, May 5, 2012 at 9:57 PM, Steve M. Robbins  wrote:
> > 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


> You should instead not enable ccache inside builds using pbuilder or
> sbuild since the directories where these builds occur end up being
> deleted, thus deleting the output generated from ccache.

I haven't been explicitly using ccache inside pbuilder.  In fact, I
just put a build-conflict against ccache to avoid using it (#671173).
Two years ago, pbuilder itself added support for ccache:

pbuilder (0.197) unstable; urgency=low

   * Add builtin support for using ccache in pbuilder and enable it by default.
 Ship a new /var/cache/pbuilder/ccache dir and bind-mount and chown it to
 BUILDUSERID at build time.  Install/remove ccache automatically on
 create/update if CCACHEDIR is set/unset.  Update docs and remove old
 ccache config example.  Add a NEWS entry featuring the change.  Stop
 intalling ccache sample config

 -- Junichi Uekawa   Wed, 23 Jun 2010 07:21:11 +0900 


I haven't done anything different recently so I'm quite mystified by
my recent trouble.  To work around this, I simply gave the world write
permissions on /var/cache/pbuilder/ccache.

Thanks,
-Steve


signature.asc
Description: Digital signature

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

[Russ Allbery]

Thibaut Paumard  writes:

> As I understand it, Policy is broken here: if the two binaries where
> installed in /usr/bin, it would be fine (Policy-wise) to Conflict.

Our current Policy specifically prohibits that.  See Policy 10.1:

Two different packages must not install programs with different
functionality but with the same filenames. (The case of two programs
having the same functionality but different implementations is handled
via "alternatives" or the "Conflicts" mechanism. See Maintainer
Scripts, Section 3.9 and Conflicting binary packages - Conflicts,
Section 7.4 respectively.) If this case happens, one of the programs
must be renamed. The maintainers should report this to the
debian-devel mailing list and try to find a consensus about which
program will have to be renamed. If a consensus cannot be reached,
both programs must be renamed.

If there's a gap in Policy, it's actually around the current situation
where the two binaries don't have the same paths, since it's not clear
what Policy means by "filename".  But it's pretty obvious that the intent
of Policy is also to prohibit binaries with different functionality in
sbin and bin, given how unstable of a situation that creates with varying
PATH.

Now, that certainly doesn't rule out the sorts of solutions we're talking
about.  As I mentioned elsewhere, the point of Policy is to make the
system usable, not to have packages follow Policy just for their own sake.
If we come up with a better way of solving this situation that requires an
exception to Policy for transitional or compatibility packages, I think
that's fine.

-- 
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/87vck9cfb6@windlord.stanford.edu

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

[Steve Langasek]

On Sat, May 05, 2012 at 08:29:40AM +0100, Philip Hands wrote:
> 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

As mentioned by Carsten Hey on debian-ctte, we should certainly keep the
same binary package name ('node') to ensure smooth upgrades for users that
already have it installed.

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

Because Node.js is a scripting interpreter, I believe there's no point in
trying to declare the package on the nodejs side 'legacy' unless there's a
committment from upstream to deprecate the /usr/bin/node name.

So from my perspective, the packages would be:

  Package: node
  Depends: ax25-node
  Conflicts: nodejs
-- /usr/sbin/node -> /usr/sbin/ax25-node

  Package: ax25-node
-- /usr/sbin/ax25-node
  
  Package: nodejs
  Conflicts: node
-- /usr/bin/nodejs
-- /usr/bin/node -> /usr/bin/nodejs

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

I think it's an acceptable compromise under the circumstances.

-- 
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: [Pkg-javascript-devel] Node.js and it's future in debian

[Steve Langasek]

On Sat, May 05, 2012 at 03:07:27AM +0200, Jonas Smedegaard wrote:
> We have until now maintained Nodejs only in unstable because requests to 
> rename axnode was met with either silence or refusal with the reasoning 
> that axnode was more widely used in Debian than Nodejs.

> Obviously Nodejs is not widely used in Debian when initially packaged.  
> So I've simply waited until it was really sensible to make such 
> comparison of popularity among the users of Debian.  Which seems to be 
> the case now - even if still impaired by Nodejs only offered to our 
> users of unstable and experimental Debian.

I find this response from you *very* disappointing.  It implies that you
knew that you had a responsibility to rename the Nodejs binary according to
Policy, but that rather than acting in a timely manner to persuade upstream
of the importance of renaming, you decided to wait until momentum was on
your side so that you could have an outcome in your favor.

My understanding is that Node.js is a three-year-old project, and that the
namespace issue was first raised upstream at least a year and a half ago.
We would have been in a much better position to resolve this in a manner
that does right by our existing ham community if you had lived up to your
moral obligations as a Debian developer *then* instead of letting the issue
fester.

'node' is a stupid name for a program, and this should have been impressed
upon Node.js upstream early and often.  We would have been in a position,
together with other distributions, to force a sensible upstream name.  I
believe we no longer are in a position to do so, and even if we did, the
transition now would be many times more disruptive for users than if this
had been dealt with in 2010.

> If Debian is frozen tomorrow, then Nodejs will not be part of it, for 
> the very reason that I *did* respect Policy.

It may not be part of the release, but it will still be a mess for everyone
involved.

-- 
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: [Pkg-javascript-devel] Node.js and it's future in debian

[Jonas Smedegaard]

Greetings, dear Debian developer,

[replying via bugreport as I am not subscribed to tech-ctte@d.o]

On 12-05-06 at 10:22am, Steve Langasek wrote:
> On Sat, May 05, 2012 at 03:07:27AM +0200, Jonas Smedegaard wrote:
> > We have until now maintained Nodejs only in unstable because 
> > requests to rename axnode was met with either silence or refusal 
> > with the reasoning that axnode was more widely used in Debian than 
> > Nodejs.
> 
> > Obviously Nodejs is not widely used in Debian when initially 
> > packaged.  So I've simply waited until it was really sensible to 
> > make such comparison of popularity among the users of Debian.  Which 
> > seems to be the case now - even if still impaired by Nodejs only 
> > offered to our users of unstable and experimental Debian.
> 
> I find this response from you *very* disappointing.  It implies that 
> you knew that you had a responsibility to rename the Nodejs binary 
> according to Policy, but that rather than acting in a timely manner to 
> persuade upstream of the importance of renaming, you decided to wait 
> until momentum was on your side so that you could have an outcome in 
> your favor.

No, that is not what it means.  You are reading timings into it that I 
did not write there, and you are reading those timings wrong!


> My understanding is that Node.js is a three-year-old project, and that 
> the namespace issue was first raised upstream at least a year and a 
> half ago. We would have been in a much better position to resolve this 
> in a manner that does right by our existing ham community if you had 
> lived up to your moral obligations as a Debian developer *then* 
> instead of letting the issue fester.

Your moral obligation, before throwing accusations like that, is to at 
least investigate the issue, and ideally first asking nicely.

You can read from nodejs packaging changelog and git commits when I got 
involved in the maintainance, and you can read from bugreports and 
mailinglists how my fellow maintainer, Jérémy Lal, conducted those moral 
obligations which you claim that I should've done before I even knew 
what "node" meant.


> 'node' is a stupid name for a program, and this should have been 
> impressed upon Node.js upstream early and often.  We would have been 
> in a position, together with other distributions, to force a sensible 
> upstream name.  I believe we no longer are in a position to do so, and 
> even if we did, the transition now would be many times more disruptive 
> for users than if this had been dealt with in 2010.
> 
> > If Debian is frozen tomorrow, then Nodejs will not be part of it, 
> > for the very reason that I *did* respect Policy.
> 
> It may not be part of the release, but it will still be a mess for 
> everyone involved.

Thanks to stpid actions by people not doing their homework, yes.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature

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

[Thomas Preud'homme]

Le dimanche 6 mai 2012 21:49:11, Jonas Smedegaard a écrit :
> Greetings, dear Debian developer,
> 
> [replying via bugreport as I am not subscribed to tech-ctte@d.o]
> 
> On 12-05-06 at 10:22am, Steve Langasek wrote:
> > On Sat, May 05, 2012 at 03:07:27AM +0200, Jonas Smedegaard wrote:
> > > We have until now maintained Nodejs only in unstable because
> > > requests to rename axnode was met with either silence or refusal
> > > with the reasoning that axnode was more widely used in Debian than
> > > Nodejs.
> > > 
> > > Obviously Nodejs is not widely used in Debian when initially
> > > packaged.  So I've simply waited until it was really sensible to
> > > make such comparison of popularity among the users of Debian.  Which
> > > seems to be the case now - even if still impaired by Nodejs only
> > > offered to our users of unstable and experimental Debian.
> > 
> > I find this response from you *very* disappointing.  It implies that
> > you knew that you had a responsibility to rename the Nodejs binary
> > according to Policy, but that rather than acting in a timely manner to
> > persuade upstream of the importance of renaming, you decided to wait
> > until momentum was on your side so that you could have an outcome in
> > your favor.
> 
> No, that is not what it means.  You are reading timings into it that I
> did not write there, and you are reading those timings wrong!

I believe the writing was just misleading and Steve just misunderstood it. I 
understood the same myself and I don't think I have any a priori on this since 
I am not at all involved. I believe this feeling come from the sentence "I've 
simply waiting until it was really sensible to make such a comparison of 
popularity".

So let's just assume it was a misunderstanding and go back to technical 
argument in order to avoid this discussion to become too heated.

> 
> > My understanding is that Node.js is a three-year-old project, and that
> > the namespace issue was first raised upstream at least a year and a
> > half ago. We would have been in a much better position to resolve this
> > in a manner that does right by our existing ham community if you had
> > lived up to your moral obligations as a Debian developer *then*
> > instead of letting the issue fester.
> 
> Your moral obligation, before throwing accusations like that, is to at
> least investigate the issue, and ideally first asking nicely.
> 
> You can read from nodejs packaging changelog and git commits when I got
> involved in the maintainance, and you can read from bugreports and
> mailinglists how my fellow maintainer, Jérémy Lal, conducted those moral
> obligations which you claim that I should've done before I even knew
> what "node" meant.
> 
> > 'node' is a stupid name for a program, and this should have been
> > impressed upon Node.js upstream early and often.  We would have been
> > in a position, together with other distributions, to force a sensible
> > upstream name.  I believe we no longer are in a position to do so, and
> > even if we did, the transition now would be many times more disruptive
> > for users than if this had been dealt with in 2010.
> > 
> > > If Debian is frozen tomorrow, then Nodejs will not be part of it,
> > > for the very reason that I *did* respect Policy.
> > 
> > It may not be part of the release, but it will still be a mess for
> > everyone involved.
> 
> Thanks to stpid actions by people not doing their homework, yes.
> 
> 
>  - Jonas

Best regards,

Thomas Preud'homme


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

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

[Jonas Smedegaard]

On 12-05-06 at 11:00pm, Thomas Preud'homme wrote:
> Le dimanche 6 mai 2012 21:49:11, Jonas Smedegaard a écrit :
> > Greetings, dear Debian developer,
> > 
> > [replying via bugreport as I am not subscribed to tech-ctte@d.o]
> > 
> > On 12-05-06 at 10:22am, Steve Langasek wrote:
> > > On Sat, May 05, 2012 at 03:07:27AM +0200, Jonas Smedegaard wrote:
> > > > We have until now maintained Nodejs only in unstable because 
> > > > requests to rename axnode was met with either silence or refusal 
> > > > with the reasoning that axnode was more widely used in Debian 
> > > > than Nodejs.
> > > > 
> > > > Obviously Nodejs is not widely used in Debian when initially 
> > > > packaged.  So I've simply waited until it was really sensible to 
> > > > make such comparison of popularity among the users of Debian.  
> > > > Which seems to be the case now - even if still impaired by 
> > > > Nodejs only offered to our users of unstable and experimental 
> > > > Debian.
> > > 
> > > I find this response from you *very* disappointing.  It implies 
> > > that you knew that you had a responsibility to rename the Nodejs 
> > > binary according to Policy, but that rather than acting in a 
> > > timely manner to persuade upstream of the importance of renaming, 
> > > you decided to wait until momentum was on your side so that you 
> > > could have an outcome in your favor.
> > 
> > No, that is not what it means.  You are reading timings into it that 
> > I did not write there, and you are reading those timings wrong!
> 
> I believe the writing was just misleading and Steve just misunderstood 
> it. I understood the same myself and I don't think I have any a priori 
> on this since I am not at all involved. I believe this feeling come 
> from the sentence "I've simply waiting until it was really sensible to 
> make such a comparison of popularity".
> 
> So let's just assume it was a misunderstanding and go back to 
> technical argument in order to avoid this discussion to become too 
> heated.

I am perfectly calm :-)


> > > My understanding is that Node.js is a three-year-old project, and 
> > > that the namespace issue was first raised upstream at least a year 
> > > and a half ago. We would have been in a much better position to 
> > > resolve this in a manner that does right by our existing ham 
> > > community if you had lived up to your moral obligations as a 
> > > Debian developer *then* instead of letting the issue fester.
> > 
> > Your moral obligation, before throwing accusations like that, is to 
> > at least investigate the issue, and ideally first asking nicely.

...but even when calm, I do not approve of a fellow developer 
patronizing me like that.

If _that_ can be the last word on this little sidestep, I am fine that 
we all move on with the technical discussion.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature

Bug#671779: ITP: qdjango -- Cross-platform C++ web development framework

[Jeremy Laine]

Package: wnpp
Severity: wishlist
Owner: Jeremy Lainé 

* Package name: qdjango
  Version : 0.2.0
  Upstream Author : Jeremy Lainé 
* URL : http://code.google.com/p/qdjango/
* License : LGPL
  Programming Lang: C++
  Description : Cross-platform C++ web development framework

QDjango is a web framework written in C++ and built on top of the Qt library.
Where possible it tries to follow django's API, hence its name.



--
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/20120506211236.8014.45961.reportbug@sharky

Re: pbuilder + ccache suddenly fails

[Andres Mejia]

On Sun, May 6, 2012 at 2:40 PM, Steve M. Robbins  wrote:
> On Sun, May 06, 2012 at 01:21:57PM -0400, Andres Mejia wrote:
>> On Sat, May 5, 2012 at 9:57 PM, Steve M. Robbins  wrote:
>> > 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
>
>
>> You should instead not enable ccache inside builds using pbuilder or
>> sbuild since the directories where these builds occur end up being
>> deleted, thus deleting the output generated from ccache.
>
> I haven't been explicitly using ccache inside pbuilder.  In fact, I
> just put a build-conflict against ccache to avoid using it (#671173).
> Two years ago, pbuilder itself added support for ccache:
>
> pbuilder (0.197) unstable; urgency=low
>
>   * Add builtin support for using ccache in pbuilder and enable it by default.
>     Ship a new /var/cache/pbuilder/ccache dir and bind-mount and chown it to
>     BUILDUSERID at build time.  Install/remove ccache automatically on
>     create/update if CCACHEDIR is set/unset.  Update docs and remove old
>     ccache config example.  Add a NEWS entry featuring the change.  Stop
>     intalling ccache sample config
>
>  -- Junichi Uekawa   Wed, 23 Jun 2010 07:21:11 +0900
>
>
> I haven't done anything different recently so I'm quite mystified by
> my recent trouble.  To work around this, I simply gave the world write
> permissions on /var/cache/pbuilder/ccache.
>
> Thanks,
> -Steve

Part of the reason to use pbuilder or sbuild is to build packages in a
clean chroot. Providing ccache support in this way isn't clean and
apparently it's prone to problems such as the bug you pointed out. See
also [1].

If you're going to upload to the archive, simply disable ccache.

1. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=430765#35

-- 
~ Andres


--
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/capm41nnsl4uptz+wgoq0ly32wzy4esqdqri0fepjavrrh8x...@mail.gmail.com

RFP: openjump -- OpenJUMP is an open source Geographic Information System (GIS) written in Java

[Touko Korpela]

This is bug #671787

- Forwarded message from Touko Korpela  -

Date: Mon, 07 May 2012 01:01:38 +0300
From: Touko Korpela 
To: Debian Bug Tracking System 
Subject: RFP: openjump -- OpenJUMP is an open source Geographic Information
System
(GIS) written in Java
X-Mailer: reportbug 6.3.1

Package: wnpp
Severity: wishlist

* Package name: openjump
  Version : 1.5.1
  Upstream Author : OpenJUMP contributors
* URL : http://www.openjump.org/
* License : GPL v2
  Programming Lang: Java
  Description : OpenJUMP is an open source Geographic Information System 
(GIS) written in Java

I would like to have OpenJUMP GIS packaged for Debian (and included in
Wheezy, if possible). OpenJUMP 1.0 was included in Lenny, but it was removed
from archive in last May (reason: Obsolete and newer versions have problems
with license. Also currently FTBS.) Is there still license trouble?

- End forwarded message -


-- 
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/20120506223639.GA9212@tiikeri.vuoristo.local

RFP bugs and debian-devel list

[Touko Korpela]

Aren't RFP bugs automatically forwarded to debian-devel, like ITP bugs?


-- 
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/20120506231408.GA10470@tiikeri.vuoristo.local

Bug#671797: ITP: libdancer-logger-psgi-perl -- PSGI Log handler for Dancer

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

* Package name: libdancer-logger-psgi-perl
  Version : 0.04
  Upstream Author : franck cuny 
* URL : http://search.cpan.org/dist/Dancer-Logger-PSGI/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : PSGI Log handler for Dancer

 Dancer is a Perl web application framework.
 .
 Dancer::Logger:PSGI is an interface between your Dancer application and
 psgix.logger. Message will be logged in whatever logger you decided to
 use in your Plack handler. If no logger is defined, nothing will be
 logged.



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

Bug#662932:

[Marcel Toma]

I use windows and any time I put a pendrive in a usb drive that is or is
not directly connected to the motherboard, I get a error and windows give
me the blue screen.

I tested in mint and it gaves me this error, I believe now, this is a
problem with my hardware

May  7 00:41:36 mint kernel: [  880.944017] usb 1-1: reset high speed USB
device number 7 using ehci_hcd
May  7 00:42:07 mint kernel: [  911.952016] usb 1-1: reset high speed USB
device number 7 using ehci_hcd
May  7 00:43:39 mint kernel: [ 1003.984020] usb 1-1: reset high speed USB
device number 7 using ehci_hcd
May  7 00:44:11 mint kernel: [ 1035.984018] usb 1-1: reset high speed USB
device number 7 using ehci_hcd
May  7 00:44:43 mint kernel: [ 1067.984024] usb 1-1: reset high speed USB
device number 7 using ehci_hcd
May  7 00:44:55 mint kernel: [ 1080.428045] INFO: task flush-8:96:4828
blocked for more than 120 seconds.
May  7 00:44:55 mint kernel: [ 1080.428049] "echo 0 >
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
May  7 00:44:55 mint kernel: [ 1080.428052] flush-8:96  D
81605120 0  4828  2 0x
May  7 00:44:55 mint kernel: [ 1080.428056]  8800c0d718e0
0046 8800c0d718d0 8105726e
May  7 00:44:55 mint kernel: [ 1080.428061]  8800c0d71fd8
8800c0d71fd8 8800c0d71fd8 00012a40
May  7 00:44:55 mint kernel: [ 1080.428065]  880118f18000
8800aad08000 88011ffef028 88011fc932c0
May  7 00:44:55 mint kernel: [ 1080.428069] Call Trace:
May  7 00:44:55 mint kernel: [ 1080.428077]  [] ?
try_to_wake_up+0x18e/0x200
May  7 00:44:55 mint kernel: [ 1080.428086]  [] ?
__lock_page+0x70/0x70
May  7 00:44:55 mint kernel: [ 1080.428090]  []
io_schedule+0x8f/0xd0
May  7 00:44:55 mint kernel: [ 1080.428094]  []
sleep_on_page+0xe/0x20
May  7 00:44:55 mint kernel: [ 1080.428097]  []
__wait_on_bit_lock+0x5a/0xc0
May  7 00:44:55 mint kernel: [ 1080.428100]  []
__lock_page+0x67/0x70
May  7 00:44:55 mint kernel: [ 1080.428104]  [] ?
autoremove_wake_function+0x40/0x40
May  7 00:44:55 mint kernel: [ 1080.428108]  []
write_cache_pages+0x3e0/0x470
May  7 00:44:55 mint kernel: [ 1080.428112]  [] ?
mpage_readpages+0x140/0x140
May  7 00:44:55 mint kernel: [ 1080.428119]  [] ?
fat_calc_dir_size+0x90/0x90 [fat]
May  7 00:44:55 mint kernel: [ 1080.428122]  []
mpage_writepages+0x61/0xb0
May  7 00:44:55 mint kernel: [ 1080.428127]  [] ?
fat_calc_dir_size+0x90/0x90 [fat]
May  7 00:44:55 mint kernel: [ 1080.428131]  []
fat_writepages+0x15/0x20 [fat]
May  7 00:44:55 mint kernel: [ 1080.428134]  []
do_writepages+0x21/0x40
May  7 00:44:55 mint kernel: [ 1080.428138]  []
writeback_single_inode+0x103/0x270
May  7 00:44:55 mint kernel: [ 1080.428142]  []
writeback_sb_inodes+0xe1/0x1b0
May  7 00:44:55 mint kernel: [ 1080.428145]  []
writeback_inodes_wb+0xa6/0xf0
May  7 00:44:55 mint kernel: [ 1080.428148]  []
wb_writeback+0x32f/0x430
May  7 00:44:55 mint kernel: [ 1080.428151]  []
wb_check_old_data_flush+0x98/0xa0
May  7 00:44:55 mint kernel: [ 1080.428154]  []
wb_do_writeback+0x151/0x1f0
May  7 00:44:55 mint kernel: [ 1080.428159]  [] ?
usleep_range+0x50/0x50
May  7 00:44:55 mint kernel: [ 1080.428162]  []
bdi_writeback_thread+0x83/0x2a0
May  7 00:44:55 mint kernel: [ 1080.428165]  [] ?
wb_do_writeback+0x1f0/0x1f0
May  7 00:44:55 mint kernel: [ 1080.428168]  []
kthread+0x8c/0xa0
May  7 00:44:55 mint kernel: [ 1080.428171]  []
kernel_thread_helper+0x4/0x10
May  7 00:44:55 mint kernel: [ 1080.428175]  [] ?
flush_kthread_worker+0xa0/0xa0
May  7 00:44:55 mint kernel: [ 1080.428183]  [] ?
gs_change+0x13/0x13
May  7 00:44:55 mint kernel: [ 1080.428189] INFO: task cp:4886 blocked for
more than 120 seconds.
May  7 00:44:55 mint kernel: [ 1080.428190] "echo 0 >
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
May  7 00:44:55 mint kernel: [ 1080.428192] cp  D
81605120 0  4886   4721 0x
May  7 00:44:55 mint kernel: [ 1080.428195]  88008d08d858
0086 88008d08d858 0246
May  7 00:44:55 mint kernel: [ 1080.428198]  88008d08dfd8
88008d08dfd8 88008d08dfd8 00012a40
May  7 00:44:55 mint kernel: [ 1080.428201]  880118f54560
8801147a9720 8800c0e43600 88011fd932c0
May  7 00:44:55 mint kernel: [ 1080.428203] Call Trace:
May  7 00:44:55 mint kernel: [ 1080.428206]  []
io_schedule+0x8f/0xd0
May  7 00:44:55 mint kernel: [ 1080.428209]  []
get_request_wait+0xcd/0x1b0
May  7 00:44:55 mint kernel: [ 1080.428211]  [] ?
add_wait_queue+0x60/0x60
May  7 00:44:55 mint kernel: [ 1080.428213]  []
__make_request+0x159/0x350
May  7 00:44:55 mint kernel: [ 1080.428216]  []
generic_make_request.part.51+0x24f/0x510
May  7 00:44:55 mint kernel: [ 1080.428218]  []
generic_make_request+0x45/0x60
May  7 00:44:55 mint kernel: [ 1080.428220]  []
submit_bio+0x87/0x110
May  7 00:44:55 mint kernel: [ 1080.428222]  [] ?
test_set_page_writeback+0xed/0x1a0
May  7 00:44:55 mint kernel: [ 1080.428225]  []
__mpage_writepage+0x485/0x

Re: RFP bugs and debian-devel list

[Paul Wise]

On Mon, May 7, 2012 at 7:14 AM, Touko Korpela wrote:

> Aren't RFP bugs automatically forwarded to debian-devel, like ITP bugs?

No wnpp bugs (inc ITP) are automatically forwarded to debian-devel, to
do that the submitter has to include the X-Debbugs-CC header or
pseudo-header in their email.

-- 
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/caktje6f_nmw9jm9f83wv+rkmknlo-ej2nxdiavaazhij9qq...@mail.gmail.com

Re: Making -devel discussions more viable

[Chris Knadle]

On Thursday, May 03, 2012 10:49:22, Gergely Nagy wrote:
> Stefano Zacchiroli  writes:
> > 2) "don't feed the troll" + report abuses to listmasters and act
> > 
> >accordingly
> 
> Of the three, this is the least disruptive, in my opinion. Of course,
> all the problems you mention (social awkwardity, effort from the
> community and extra burden on listmasters) apply, BUT!
> 
> Perhaps a compromise could be to close threads forcibly, and temporarily
> ban everyone from posting to the list, if they attempt to post to a
> closed thread after its closing has been announced (a little window
> of error should be given, of course, half an hour tops, or thereabouts).

I've been helping moderate a LUG mailing list for a couple of years that uses 
this strategy, and I think it works.  The message of "this thread is closed, 
anyone posting will be temporarily banned from posting if they reply" comes as 
a relief when the thread has gone on long enough to have touched on seemingly 
all the possibilities for solving an issue, but feels slightly heavy-handed 
and "muzzle-ing" if done too quickly.  Feedback on the list typically helps 
the list moderators attain a reasonable equilibrium for the cuttoff point.

There are a couple of downsides to this strategy:

  - one or more moderators need to be monitoring posts, and thus it's work.
The volume that this particular mailing list gets I think it's not a
one person task.  [Come to think of it, how many DDs are currently
allowed to officially moderate the list?]

  - There's a tendency to forget that the 'mod bit' is set for the user
that's been temporarily banned from posting

> This reduces the social awkwardness, as we'd be reporting bad threads
> instead of bad people, and threads don't mind. It would reduce the load
> on listmasters, as threads are fewer than people, and there's less
> emotion involved, and justification is easier.
> 
> And if so need be, the temporary bans can gradually increase in length
> if one keeps on posting to closed threads.

Yes, this works.  Thankfully it very rarely ever comes to this, but I've seen 
a couple of instances where this became necessary.

> I've seen things like this work reasonably well on web-based forums, and
> while it is considerably harder to implement it on a mailing list (and
> probably impossible to make it entirely correct at that), something
> reasonably similar that works in most cases shouldn't be terribly hard
> to implement. People abusing the shortcomings of the solution can still
> be banned on a case-by-case basis.

It's always a judgement call.  Not all judgements are going to be correct.

  -- Chris

--
Chris Knadle
chris.kna...@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74


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

Re: Making -devel discussions more viable

[Chris Knadle]

On Thursday, May 03, 2012 02:50:41, Raphael Hertzog wrote:
...
> When I see that the bad patterns tend to continue, I mail the listmasters
> and ask them to send a warning to to the person. If enough persons
> complain, they might even put a filter if that person doesn't stop.
> 
> But it's difficult to do it on a regular basis because:
> - if I'm alone doing it, it won't have much impact
> - given I have no way to know that others are doing the same, I tend to
>   assume that it doesn't help much, and thus loses some of the motivation
>   to draft gentle replies pointing out the problematic behaviour
> 
> Maybe we need a private DD-only list where people interested in
> improving our lists can CC their private complaints. listmasters
> could follow the list and take action when they notice that
> the same person got multiple complaints.

FWIW there's a [debian-private] mailing list:
   debian-private: Private discussions among developers 

and this list is not archived.

  -- Chris

--
Chris Knadle
chris.kna...@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74


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

free assimilation (git-svn migration) service offer

[Thomas Koch]

Hi,

I've now converted a few SVN repos to Git for other Debian people. Since this 
is a one time task, it does not make much sense that everybody needs to learn 
how to do it.

Therefor if anybody would like to have his old, inferior SVN repo assimilated 
and to join the collective, please open a bug on your package and assign it to 
me or just answer me.

Make sure to sign the mail/bug so that I don't act without the consent of the 
maintainer.

Even PHP switched to Git by now... :-)

Regards,

Thomas Koch, http://www.koch.ro


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

Re: Making -devel discussions more viable

[Raphael Hertzog]

On Sun, 06 May 2012, Chris Knadle wrote:
> On Thursday, May 03, 2012 02:50:41, Raphael Hertzog wrote:
> > Maybe we need a private DD-only list where people interested in
> > improving our lists can CC their private complaints. listmasters
> > could follow the list and take action when they notice that
> > the same person got multiple complaints.
> 
> FWIW there's a [debian-private] mailing list:
>debian-private: Private discussions among developers 
> 
> and this list is not archived.

Heh, thank you for the notice. But I knew about this list (and any DD knows
about it since most of us are subscribed and it's one of the first things
that you do when you get the DD status) and it's really not its purpose.

I believe that such mails should not be imposed to debian-private readers
but only to people who specifically opted to help "moderate" our mailing
lists through "social influence".

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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


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