[Pkg-javascript-devel] Bug#853036: marked as done (node-liftoff: Non-determistically FTBFS due to unreliable timing in tests)

[Debian Bug Tracking System]

Your message dated Sun, 29 Jan 2017 07:04:56 +
with message-id 
<1485673496.438276.863023496.78483...@webmail.messagingengine.com>
and subject line (Closing duplicate)
has caused the Debian Bug report #853036,
regarding node-liftoff: Non-determistically FTBFS due to unreliable timing in 
tests
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
853036: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=853036
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: node-liftoff
Version: 2.3.0-2
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Dear Maintainer,

node-liftoff's testsuite appears to use method timing/benchmarking
in such a way that it will non-deterministically FTBFS:

  […]

  
    1) Liftoff launch should skip respawning if process.argv has no values 
from v8flags in it:
   Error: timeout of 5000ms exceeded
at null. (/usr/lib/nodejs/mocha/lib/runnable.js:139:19)
at Timer.listOnTimeout (timers.js:92:15)
  
  
  
  debian/rules:13: recipe for target 'override_dh_auto_test' failed
  make[1]: *** [override_dh_auto_test] Error 1
  make[1]: Leaving directory '«BUILDDIR»'
  debian/rules:8: recipe for target 'build' failed
  make: *** [build] Error 2
  dpkg-buildpackage: error: debian/rules build gave error exit status 2

  […]

The full build log is attached.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- End Message ---
--- Begin Message ---


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   ` End Message ---
-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

[Pkg-javascript-devel] Bug#853035: node-liftoff: Non-determistically FTBFS due to unreliable timing in tests

[Chris Lamb]

Source: node-liftoff
Version: 2.3.0-2
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Dear Maintainer,

node-liftoff's testsuite appears to use method timing/benchmarking
in such a way that it will non-deterministically FTBFS:

  […]

  
    1) Liftoff launch should skip respawning if process.argv has no values 
from v8flags in it:
   Error: timeout of 5000ms exceeded
at null. (/usr/lib/nodejs/mocha/lib/runnable.js:139:19)
at Timer.listOnTimeout (timers.js:92:15)
  
  
  
  debian/rules:13: recipe for target 'override_dh_auto_test' failed
  make[1]: *** [override_dh_auto_test] Error 1
  make[1]: Leaving directory '«BUILDDIR»'
  debian/rules:8: recipe for target 'build' failed
  make: *** [build] Error 2
  dpkg-buildpackage: error: debian/rules build gave error exit status 2

  […]

The full build log is attached.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-


node-liftoff.2.3.0-2.unstable.amd64.log.txt.gz
Description: Binary data
-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

[Pkg-javascript-devel] Bug#853036: node-liftoff: Non-determistically FTBFS due to unreliable timing in tests

[Chris Lamb]

Source: node-liftoff
Version: 2.3.0-2
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Dear Maintainer,

node-liftoff's testsuite appears to use method timing/benchmarking
in such a way that it will non-deterministically FTBFS:

  […]

  
    1) Liftoff launch should skip respawning if process.argv has no values 
from v8flags in it:
   Error: timeout of 5000ms exceeded
at null. (/usr/lib/nodejs/mocha/lib/runnable.js:139:19)
at Timer.listOnTimeout (timers.js:92:15)
  
  
  
  debian/rules:13: recipe for target 'override_dh_auto_test' failed
  make[1]: *** [override_dh_auto_test] Error 1
  make[1]: Leaving directory '«BUILDDIR»'
  debian/rules:8: recipe for target 'build' failed
  make: *** [build] Error 2
  dpkg-buildpackage: error: debian/rules build gave error exit status 2

  […]

The full build log is attached.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

[Pkg-javascript-devel] ITP: node-hoek -- General purpose node utilities

[Akash Sarda]

https://git.fosscommunity.in/AkashSarda/hoek

I have packaged, ran sbuild, and it is linitan error free.
Please review and upload.

Bug No. 850238.

Yours Sincerely
Akash Sarda

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] lots of requests to join pkg-javascript

[Pirate Praveen]

On ശനി 28 ജനുവരി 2017 10:21 വൈകു, Ross Gammon wrote:
> I was disappointed with this too. I think we should be encouraging
> newcomers to place their packaging in the standard place, so we can help
> them when required. The last thing we want is node-*/js packaging being
> done in a different way, in a different place.
> 
> If I had a list of Alioth logins, I would be happy to help adding them
> to the team. We need more help here!

Tushar Agey (tush-guest) requested membership today, you can start with
him. I'll ask each of them to apply again when they are ready to upload
a second package. For now, someone needs to import all the packages
accepted by ftp masters (filter mail by ACCEPTED) so the duplication can
be avoided until npm2deb is fixed to look in experimental too.




signature.asc
Description: OpenPGP digital signature
-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] pre-spring cleaning, please advise

[Jérémy Lal]

2017-01-28 17:46 GMT+01:00 Ross Gammon :
> On 01/28/2017 10:52 AM, Paolo Greppi wrote:
>> This is a good idea ! There is a lot of cruft, especially packages created 
>> for some obscure reason 2-3 years ago and since then abandoned both by the 
>> maintainer and by upstream, and superseded by the next cool thing in the 
>> nodejs ecosystem.
>>
>> I propose to extract from UDD a list of candidate packages to be removed: 
>> those not fulfilling the criteria proposed by Jérémy, plus some more like:
>>
>> - popcon > 20
>> ..
>>
>> The list would be published for scrutiny here in this mailing list or on the 
>> wiki for say 2 weeks.
>>
>> To address the point raised by Ben (i.e. to make sure we don't remove a 
>> library needed at some point in the future for some other package not yet 
>> uploaded), I would leave it to the owner of the high-level package IPTs: for 
>> each of those there is a Task in the wiki or a non-disclosed WIP list - in 
>> any case the ITP owner knows best and she should manually remove from the 
>> list the packages she thinks she'll need, providing a rationale (i.e. 
>> "needed for yarnpkg").
>>
>> Once the 2 weeks are over we can proceed mass filing those "candidate for 
>> removal" bugreports.
>>
>> Once the additional 2 weeks are over the bugreports can be reassigned to 
>> ftpmaster.
>>
>> Paolo
>>
>> On 28/01/2017 10:17, Jonas Smedegaard wrote:
>>> Quoting Ben Finney (2017-01-28 03:07:01)
 Jérémy Lal  writes:

> - or having a reverse (build-)dependency, or what's the point ?
 I am very much in favour of this: node libraries should be in Debian
 to provide a library that is needed for some actual program of benefit
 to Debian users.
>>> Agreed.
>>>
>>>
 But my eagerness to remove useless packages makes me worry that some
 useful ones could be swept up also.

 One use case I don't see addressed: How will we ensure that a library
 is not needed for some other package not yet uploaded to Debian?
>>> Removal from testing involves filing a bugreport to ftpmaster.  I guess
>>> it makes sense if at all uncertain to first file bugreport against the
>>> package and cc this list - of not-to-high severity - suggesting the
>>> intent (removal from stretch or removal from Debian completely) some
>>> time (2 weeks?) before reasigning to ftpmaster.
>>>
>>> Discussing only here is not adequate: Being part of this team and
>>> subscribing to this mailinglist is voluntary.
>>>
>>>
>>>  - Jonas
>>
>
> I agree. But...
>
> It might be a good idea to keep the alioth repo for a while though.
> Upstreams can sometimes get going again when some need is identified and
> someone willing steps up to maintain it. Then we can at least quickly
> resurrect the package if required.
>
> Can we be a little less aggressive on the timescales? It should be a
> Buster goal. It can take me most of a release cycle to get all the other
> dependencies in shape in order for the final reverse dependency to get
> uploaded (I failed with several things this release cycle). Trying to
> re-remember what package I don't want to get "dropped out" (which could
> be maintained by someone else) and then adjusting bug severities does
> take up valuable time which could be spent getting the other
> dependencies ready.
>
> Also, as we enable more and more autopkgtests & buildtime testsuites,
> packages in bad shape will naturally fall out of testing anyway -
> without us doing any work. Periodically looking at the packages that
> have not been in testing for a long time could be another metric to use.
> I know I have a couple of those that weren't worth working on until a
> series of other dependencies were ready.

My proposal was not to remove the debian package entirely, it was more
about not letting a bunch of under-maintained node packages go to next
stable, so the time-scale would be crucial here.
In a second move, of course some packages need to be entirely removed,
but that's something that can be done much more slowly.

Jérémy


-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] lots of requests to join pkg-javascript

[Ross Gammon]

Hi Pirate,

On 01/27/2017 10:02 AM, Pirate Praveen wrote:
> Thanks to a bug in npm2deb search which does not look in experimental
> and our excellent on boarding practices which prefers keeping new git
> repos out of team repo in alioth, people are duplicating work, packaging
> already packaged node modules (node-timed-out and node-cli-spinners
> already, I expect more duplication). I don't see the same level of
> enthusiasm to import those repos to alioth (I'm not going to do it as I
> strongly disagree with the unilateral decision of rejecting their alioth
> requests based on one person's prejudice, it is also unnecessary extra
> work for the team, those who advocated this setup should be willing to
> take the extra work).
>
>

I was disappointed with this too. I think we should be encouraging
newcomers to place their packaging in the standard place, so we can help
them when required. The last thing we want is node-*/js packaging being
done in a different way, in a different place.

If I had a list of Alioth logins, I would be happy to help adding them
to the team. We need more help here!

Ross
-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] pre-spring cleaning, please advise

[Ross Gammon]

On 01/28/2017 10:52 AM, Paolo Greppi wrote:
> This is a good idea ! There is a lot of cruft, especially packages created 
> for some obscure reason 2-3 years ago and since then abandoned both by the 
> maintainer and by upstream, and superseded by the next cool thing in the 
> nodejs ecosystem.
>
> I propose to extract from UDD a list of candidate packages to be removed: 
> those not fulfilling the criteria proposed by Jérémy, plus some more like:
>
> - popcon > 20
> ..
>
> The list would be published for scrutiny here in this mailing list or on the 
> wiki for say 2 weeks.
>
> To address the point raised by Ben (i.e. to make sure we don't remove a 
> library needed at some point in the future for some other package not yet 
> uploaded), I would leave it to the owner of the high-level package IPTs: for 
> each of those there is a Task in the wiki or a non-disclosed WIP list - in 
> any case the ITP owner knows best and she should manually remove from the 
> list the packages she thinks she'll need, providing a rationale (i.e. "needed 
> for yarnpkg").
>
> Once the 2 weeks are over we can proceed mass filing those "candidate for 
> removal" bugreports.
>
> Once the additional 2 weeks are over the bugreports can be reassigned to 
> ftpmaster.
>
> Paolo
>
> On 28/01/2017 10:17, Jonas Smedegaard wrote:
>> Quoting Ben Finney (2017-01-28 03:07:01)
>>> Jérémy Lal  writes:
>>>
 - or having a reverse (build-)dependency, or what's the point ?
>>> I am very much in favour of this: node libraries should be in Debian 
>>> to provide a library that is needed for some actual program of benefit 
>>> to Debian users.
>> Agreed.
>>
>>
>>> But my eagerness to remove useless packages makes me worry that some 
>>> useful ones could be swept up also.
>>>
>>> One use case I don't see addressed: How will we ensure that a library 
>>> is not needed for some other package not yet uploaded to Debian?
>> Removal from testing involves filing a bugreport to ftpmaster.  I guess 
>> it makes sense if at all uncertain to first file bugreport against the 
>> package and cc this list - of not-to-high severity - suggesting the 
>> intent (removal from stretch or removal from Debian completely) some 
>> time (2 weeks?) before reasigning to ftpmaster.
>>
>> Discussing only here is not adequate: Being part of this team and 
>> subscribing to this mailinglist is voluntary.
>>
>>
>>  - Jonas
>

I agree. But...

It might be a good idea to keep the alioth repo for a while though.
Upstreams can sometimes get going again when some need is identified and
someone willing steps up to maintain it. Then we can at least quickly
resurrect the package if required.

Can we be a little less aggressive on the timescales? It should be a
Buster goal. It can take me most of a release cycle to get all the other
dependencies in shape in order for the final reverse dependency to get
uploaded (I failed with several things this release cycle). Trying to
re-remember what package I don't want to get "dropped out" (which could
be maintained by someone else) and then adjusting bug severities does
take up valuable time which could be spent getting the other
dependencies ready.

Also, as we enable more and more autopkgtests & buildtime testsuites,
packages in bad shape will naturally fall out of testing anyway -
without us doing any work. Periodically looking at the packages that
have not been in testing for a long time could be another metric to use.
I know I have a couple of those that weren't worth working on until a
series of other dependencies were ready.

Cheers,

Ross


-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

[Pkg-javascript-devel] RFS: node-is-plain-obj-1.1.0

[Tushar Agey]

I have packaged "node-is-plain-obj" (dependency of AVA). I have made
it lintian-clean and
have tested it using sbuild.

It is available on the repository:

https://git.fosscommunity.in/tushar/node-is-plain-obj.git

I would like to have it sponsored!
Thank you for your valuable time!

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

[Pkg-javascript-devel] node-duplexer3_0.1.4-1_amd64.changes is NEW

[Debian FTP Masters]

binary:node-duplexer3 is NEW.
binary:node-duplexer3 is NEW.
source:node-duplexer3 is NEW.

Your package has been put into the NEW queue, which requires manual action
from the ftpteam to process. The upload was otherwise valid (it had a good
OpenPGP signature and file hashes are valid), so please be patient.

Packages are routinely processed through to the archive, and do feel
free to browse the NEW queue[1].

If there is an issue with the upload, you will receive an email from a
member of the ftpteam.

If you have any questions, you may reply to this email.

[1]: https://ftp-master.debian.org/new.html
 or https://ftp-master.debian.org/backports-new.html for *-backports

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

[Pkg-javascript-devel] node-cli-spinners is already in Debian

[Adrian Bunk]

node-cli-spinners is already in Debian:
  https://tracker.debian.org/pkg/node-cli-spinners

It is currently only in experimental, please talk to the maintainer
(added in Cc) in case you require the package in unstable.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed


-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

[Pkg-javascript-devel] Processing of node-duplexer3_0.1.4-1_amd64.changes

[Debian FTP Masters]

node-duplexer3_0.1.4-1_amd64.changes uploaded successfully to localhost
along with the files:
  node-duplexer3_0.1.4-1.dsc
  node-duplexer3_0.1.4.orig.tar.gz
  node-duplexer3_0.1.4-1.debian.tar.xz
  node-duplexer3_0.1.4-1_all.deb
  node-duplexer3_0.1.4-1_amd64.buildinfo

Greetings,

Your Debian queue daemon (running on host usper.debian.org)

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] RFS: node-duplexer3-0.1.4

[Pirate Praveen]

On ശനി 28 ജനുവരി 2017 04:28 വൈകു, Tushar Agey wrote:
> tests are enabled in debian/tests/control

Thanks! Uploaded.



signature.asc
Description: OpenPGP digital signature
-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

[Pkg-javascript-devel] node-widest-line_1.0.0-1_amd64.changes is NEW

[Debian FTP Masters]

binary:node-widest-line is NEW.
binary:node-widest-line is NEW.
source:node-widest-line is NEW.

Your package has been put into the NEW queue, which requires manual action
from the ftpteam to process. The upload was otherwise valid (it had a good
OpenPGP signature and file hashes are valid), so please be patient.

Packages are routinely processed through to the archive, and do feel
free to browse the NEW queue[1].

If there is an issue with the upload, you will receive an email from a
member of the ftpteam.

If you have any questions, you may reply to this email.

[1]: https://ftp-master.debian.org/new.html
 or https://ftp-master.debian.org/backports-new.html for *-backports

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

[Pkg-javascript-devel] Processing of node-widest-line_1.0.0-1_amd64.changes

[Debian FTP Masters]

node-widest-line_1.0.0-1_amd64.changes uploaded successfully to localhost
along with the files:
  node-widest-line_1.0.0-1.dsc
  node-widest-line_1.0.0.orig.tar.gz
  node-widest-line_1.0.0-1.debian.tar.xz
  node-widest-line_1.0.0-1_all.deb
  node-widest-line_1.0.0-1_amd64.buildinfo

Greetings,

Your Debian queue daemon (running on host usper.debian.org)

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] RFS: node-duplexer3-0.1.4

[Pirate Praveen]

On വെള്ളി 27 ജനുവരി 2017 08:57 വൈകു, Tushar Agey wrote:
> I have packaged "node-duplexer3". I have made it lintian-clean and
> have tested
> it using sbuild.
> 
> It is available on the repository:
> 
> https://git.fosscommunity.in/tushar/node-duplexer3.git
> 
> I would like to have it sponsored!
> Thank you for your valuable time!
> 

Please add autopkgtests in debian/tests/control. See node-glob-stream as
an example.



signature.asc
Description: OpenPGP digital signature
-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] RFS: node-widest-line-1.0.0

[Pirate Praveen]

On വെള്ളി 27 ജനുവരി 2017 09:02 വൈകു, Tushar Agey wrote:
> I have packaged "node-widest-line". I have made it lintian-clean and
> have tested
> it using sbuild.
> 
> It is available on the repository:
> 
> https://git.fosscommunity.in/tushar/node-widest-line.git
> 
> I would like to have it sponsored!
> Thank you for your valuable time!
> 

Uploaded! Thanks for your contribution. Next time mention what
application this dependency is for as well (for example ava or electron).

Since you have two packages in the archive, I suggest you try your luck
again with getting alioth access. It will help avoid duplication as
npm2deb search will find them in alioth.



signature.asc
Description: OpenPGP digital signature
-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

[Pkg-javascript-devel] Processed: found 699482 in 1.4.2-2

[Debian Bug Tracking System]

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

> # just for the BTS graph
> found 699482 1.4.2-2
Bug #699482 {Done: Paul Gevers } [jquery] CVE-2011-4969: 
jQuery 1.6.2 XSS
There is no source info for the package 'jquery' at version '1.4.2-2' with 
architecture ''
Unable to make a source version for version '1.4.2-2'
Marked as found in versions 1.4.2-2.
> thanks
Stopping processing here.

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

-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] pre-spring cleaning, please advise

[Paolo Greppi]

This is a good idea ! There is a lot of cruft, especially packages created for 
some obscure reason 2-3 years ago and since then abandoned both by the 
maintainer and by upstream, and superseded by the next cool thing in the nodejs 
ecosystem.

I propose to extract from UDD a list of candidate packages to be removed: those 
not fulfilling the criteria proposed by Jérémy, plus some more like:

- popcon > 20
..

The list would be published for scrutiny here in this mailing list or on the 
wiki for say 2 weeks.

To address the point raised by Ben (i.e. to make sure we don't remove a library 
needed at some point in the future for some other package not yet uploaded), I 
would leave it to the owner of the high-level package IPTs: for each of those 
there is a Task in the wiki or a non-disclosed WIP list - in any case the ITP 
owner knows best and she should manually remove from the list the packages she 
thinks she'll need, providing a rationale (i.e. "needed for yarnpkg").

Once the 2 weeks are over we can proceed mass filing those "candidate for 
removal" bugreports.

Once the additional 2 weeks are over the bugreports can be reassigned to 
ftpmaster.

Paolo

On 28/01/2017 10:17, Jonas Smedegaard wrote:
> Quoting Ben Finney (2017-01-28 03:07:01)
>> Jérémy Lal  writes:
>>
>>> - or having a reverse (build-)dependency, or what's the point ?
>>
>> I am very much in favour of this: node libraries should be in Debian 
>> to provide a library that is needed for some actual program of benefit 
>> to Debian users.
> 
> Agreed.
> 
> 
>> But my eagerness to remove useless packages makes me worry that some 
>> useful ones could be swept up also.
>>
>> One use case I don't see addressed: How will we ensure that a library 
>> is not needed for some other package not yet uploaded to Debian?
> 
> Removal from testing involves filing a bugreport to ftpmaster.  I guess 
> it makes sense if at all uncertain to first file bugreport against the 
> package and cc this list - of not-to-high severity - suggesting the 
> intent (removal from stretch or removal from Debian completely) some 
> time (2 weeks?) before reasigning to ftpmaster.
> 
> Discussing only here is not adequate: Being part of this team and 
> subscribing to this mailinglist is voluntary.
> 
> 
>  - Jonas


-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

Re: [Pkg-javascript-devel] pre-spring cleaning, please advise

[Jonas Smedegaard]

Quoting Ben Finney (2017-01-28 03:07:01)
> Jérémy Lal  writes:
> 
> > - or having a reverse (build-)dependency, or what's the point ?
> 
> I am very much in favour of this: node libraries should be in Debian 
> to provide a library that is needed for some actual program of benefit 
> to Debian users.

Agreed.


> But my eagerness to remove useless packages makes me worry that some 
> useful ones could be swept up also.
> 
> One use case I don't see addressed: How will we ensure that a library 
> is not needed for some other package not yet uploaded to Debian?

Removal from testing involves filing a bugreport to ftpmaster.  I guess 
it makes sense if at all uncertain to first file bugreport against the 
package and cc this list - of not-to-high severity - suggesting the 
intent (removal from stretch or removal from Debian completely) some 
time (2 weeks?) before reasigning to ftpmaster.

Discussing only here is not adequate: Being part of this team and 
subscribing to this mailinglist is voluntary.


 - 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: signature
-- 
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

[Pkg-javascript-devel] Bug#852923: dojo: FTBFS: OPTIMIZER FAILED: JavaException: java.lang.RuntimeException: null

[Lucas Nussbaum]

Source: dojo
Version: 1.11.0+dfsg-1
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20170128 qa-ftbfs
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.

Relevant part (hopefully):
> make[1]: Entering directory '/<>/dojo-1.11.0+dfsg'
> ln -s /usr/share/java/js.jar /usr/share/java/shrinksafe.jar util/shrinksafe/
> cd util/buildscripts && ./build.sh profile=standard action=release
> processing profile resource 
> /<>/dojo-1.11.0+dfsg/util/buildscripts/profiles/standard.profile.js
> info(107) Package Version: package: dijit; version: 1.11.0
> processing profile resource 
> /<>/dojo-1.11.0+dfsg/dijit/dijit.profile.js
> info(107) Package Version: package: dojox; version: 1.11.0
> processing profile resource 
> /<>/dojo-1.11.0+dfsg/dojox/dojox.profile.js
> info(107) Package Version: package: dojo; version: 1.11.0
> processing profile resource 
> /<>/dojo-1.11.0+dfsg/dojo/dojo.profile.js
> discovering resources...
> starting reading resources...
> starting processing raw resource content...
> starting tokenizing resource...
> starting processing resource tokens...
> starting parsing resource...
> starting processing resource AST...
> warn(224) A plugin dependency was encountered but there was no build-time 
> plugin resolver. module: dijit/Fieldset; plugin: dojo/query
> warn(224) A plugin dependency was encountered but there was no build-time 
> plugin resolver. module: dijit/RadioMenuItem; plugin: dojo/query
> warn(224) A plugin dependency was encountered but there was no build-time 
> plugin resolver. module: dijit/Tree; plugin: dojo/query
> warn(216) dojo/has plugin resource could not be resolved during build-time. 
> plugin resource id: dojo-bidi?./_BidiMixin; reference module id: 
> dijit/_WidgetBase
> warn(224) A plugin dependency was encountered but there was no build-time 
> plugin resolver. module: dijit/form/_RadioButtonMixin; plugin: dojo/query
> warn(216) dojo/has plugin resource could not be resolved during build-time. 
> plugin resource id: dojo-bidi?./bidi/Chart; reference module id: 
> dojox/charting/Chart
> warn(216) dojo/has plugin resource could not be resolved during build-time. 
> plugin resource id: dojo-bidi?./bidi/Chart3D; reference module id: 
> dojox/charting/Chart3D
> warn(216) dojo/has plugin resource could not be resolved during build-time. 
> plugin resource id: dojo-bidi?../bidi/action2d/ZoomAndPan; reference module 
> id: dojox/charting/action2d/MouseZoomAndPan
> warn(216) dojo/has plugin resource could not be resolved during build-time. 
> plugin resource id: dojo-bidi?../bidi/action2d/Tooltip; reference module id: 
> dojox/charting/action2d/Tooltip
> warn(216) dojo/has plugin resource could not be resolved during build-time. 
> plugin resource id: dojo-bidi?../bidi/action2d/ZoomAndPan; reference module 
> id: dojox/charting/action2d/TouchZoomAndPan
> warn(216) dojo/has plugin resource could not be resolved during build-time. 
> plugin resource id: dojo-bidi?../bidi/axis2d/Default; reference module id: 
> dojox/charting/axis2d/Default
> warn(216) dojo/has plugin resource could not be resolved during build-time. 
> plugin resource id: dojo-bidi?../bidi/widget/Chart; reference module id: 
> dojox/charting/widget/Chart
> warn(216) dojo/has plugin resource could not be resolved during build-time. 
> plugin resource id: dojo-bidi?../bidi/widget/Legend; reference module id: 
> dojox/charting/widget/Legend
> warn(216) dojo/has plugin resource could not be resolved during build-time. 
> plugin resource id: dojo-bidi?./bidi/_BidiMixin; reference module id: 
> dojox/grid/DataGrid
> warn(216) dojo/has plugin resource could not be resolved during build-time. 
> plugin resource id: dojo-bidi?dojox/mobile/bidi/Accordion; reference module 
> id: dojox/mobile/Accordion
> warn(216) dojo/has plugin resource could not be resolved during build-time. 
> plugin resource id: dojo-bidi?dojox/mobile/bidi/Badge; reference module id: 
> dojox/mobile/Badge
> warn(216) dojo/has plugin resource could not be resolved during build-time. 
> plugin resource id: dojo-bidi?dojox/mobile/bidi/Button; reference module id: 
> dojox/mobile/Button
> warn(216) dojo/has plugin resource could not be resolved during build-time. 
> plugin resource id: dojo-bidi?dojox/mobile/bidi/Carousel; reference module 
> id: dojox/mobile/Carousel
> warn(216) dojo/has plugin resource could not be resolved during build-time. 
> plugin resource id: dojo-bidi?dojox/mobile/bidi/CarouselItem; reference 
> module id: dojox/mobile/CarouselItem
> warn(224) A plugin dependency was encountered but there was no build-time 
> plugin resolver. module: dojox/mobile/DatePicker; plug