Re: [Pkg-javascript-devel] Javascript policy and npm2deb

2017-10-11 Thread Ximin Luo 
Please CC me on all replies, I don't receive mail from this mailing list due to 
too much node-related traffic that I don't want to see.

> In a recent bug report, I came across this disparity,
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877213#36
> 
> npm2deb creates source packages with node- prefix. I think the policy
> should be updated to reflect this.

As I mentioned on that bug report, not all javascript is node or npm. It would 
be totally inappropriate to rename jquery or mathjax as node-jquery or 
node-mathjax.

My d3-format source package provides both node-d3-format and libjs-d3-format, 
which is a standalone javascript library that doesn't need node at all. The 
build does not need NPM, and it needs nodejs only to run uglifyjs. Calling a 
package node-XXX just because a build tool uses /usr/bin/nodejs is ridiculous, 
we might as well rename all/most packages to cc-XXX or gcc-XXX.

More generally we should be liberating as many Debian javascript packages as 
possible from the shackles of the neoliberal "free-market" npm "ecosystem".

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

-- 
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#877213: node-d3-color: B-D npm not available in testing

2017-10-11 Thread Ximin Luo 
Pirate Praveen:
> On Tue, 10 Oct 2017 15:23:00 +0000 Ximin Luo <infini...@debian.org> wrote:
>> I was following https://wiki.debian.org/Javascript/Policy
> 
> The top of the page says "This document is still work in progress.'
> 
> Anyway, I have started a thread in pkg-javascript-devel list [1], lets
> continue this discussion there.
> 
> [1]
> http://lists.alioth.debian.org/pipermail/pkg-javascript-devel/2017-October/021645.html
> 

I'm not subscribed because I don't want node spam polluting my inbox. Please CC 
me on the thread.

I personally would be in favour of splitting off node-related things into a 
separate team away from pkg-javascript.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

-- 
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#877213: node-d3-color: B-D npm not available in testing

2017-10-10 Thread Ximin Luo 
Pirate Praveen:
> On ചൊവ്വ 10 ഒക്ടോബര്‍ 2017 06:08 വൈകു, Ximin Luo wrote:
>> I will also file a RM request later to remove node-d3-format, since it 
>> shouldn't have been accepted into Debian in the first place. Please do your 
>> research properly next time before filing ITPs.
> This happened because npm2deb search expects source package name to be
> node-d3-format. It'd be good to follow the same standard for naming
> packages to avoid issues like this. Or you could have added an exception
> to https://wiki.debian.org/Javascript/Nodejs/Database instead.
> 
> https://wiki.debian.org/Javascript/Nodejs/Tasks/gitlab showed d3-format
> as unpackaged.
>> Feel free to contact me separately about upgrading d3-format to 1.2.0.
> Please update.
> 

I was following https://wiki.debian.org/Javascript/Policy

1. given a foo library, binary package must be called libjs-foo and the source 
package name should be called foo.js; 
[..]
5. should generate a node-foo binary package if the script is usable also for 
Nodejs 

Not everything javascript is tied to npm or nodejs.

If you develop your own tools you should be aware of what else exists in the 
world. A quick "apt-cache search" or web search on packages.debian.org would be 
sufficient.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

-- 
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#864983: highlight.js: New upstream version available in experimental, upload to unstable

2017-07-12 Thread Ximin Luo 
Ximin Luo:
> Source: highlight.js
> Version: 8.2+ds-5
> Severity: normal
> 
> Dear Maintainer,
> 
> I've uploaded a new version of highlight.js to Debian experimental. Now that
> the freeze is over, I'd like to upload it to unstable soon. The next version 
> of
> rust will need this version (>= 9) for its documentation, and I'd like to
> upload that to unstable soon as well.
> 
> I've CCd the maintainers of the packages that depend on this library to ensure
> that their packages still work against version 9. To these people: please
> install the highlight.js packages from Debian experimental and verify that 
> they
> don't break your packages.
> 
> Here are the changes from 8:
> 
> https://github.com/isagalaev/highlight.js/blob/master/CHANGES.md#version-9110
> 
> In particular, in Version 9.0.0:
> 
> "This change is backwards incompatible for those who uses highlight.js with a
> custom stylesheet. The new style guide explains how to write styles in this 
> new
> world."
> 
> If I hear no response within TWO WEEKS (July 2) I will go ahead and upload 9
> to unstable. If people mention that are issues before then, I'll be happy to
> delay this upload. I hope that's reasonable.
> 
> [..]

Hey all, another reminder about this. I'll upload it next week if I don't hear 
anything.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

-- 
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#864983: highlight.js: New upstream version available in experimental, upload to unstable

2017-06-18 Thread Ximin Luo 
Source: highlight.js
Version: 8.2+ds-5
Severity: normal

Dear Maintainer,

I've uploaded a new version of highlight.js to Debian experimental. Now that
the freeze is over, I'd like to upload it to unstable soon. The next version of
rust will need this version (>= 9) for its documentation, and I'd like to
upload that to unstable soon as well.

I've CCd the maintainers of the packages that depend on this library to ensure
that their packages still work against version 9. To these people: please
install the highlight.js packages from Debian experimental and verify that they
don't break your packages.

Here are the changes from 8:

https://github.com/isagalaev/highlight.js/blob/master/CHANGES.md#version-9110

In particular, in Version 9.0.0:

"This change is backwards incompatible for those who uses highlight.js with a
custom stylesheet. The new style guide explains how to write styles in this new
world."

If I hear no response within TWO WEEKS (July 2) I will go ahead and upload 9
to unstable. If people mention that are issues before then, I'll be happy to
delay this upload. I hope that's reasonable.

X

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'buildd-unstable'), (300, 'unstable'), (100, 
'experimental'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- 
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] [Debian-science-sagemath] Sage 7.6

2017-04-05 Thread Ximin Luo 
+pkg-javascript-devel

Gordon Ball:
> [..]
> 
> My notes on what is needed to upgrade ipywidgets/jupyter-notebook and
> general jupyter stuff:
> 
> No new dependencies, probably uncomplicated:
> 
>  * ipykernel 4.5.2 -> 4.6.0
>  * ipython 5.1.0 -> 5.3.0
>  * ipython-genutils 0.1.0 -> 0.2.0
>  * jupyter-client 4.4.0 -> 5.0.1
>  * jupyter-core 4.2.1 -> 4.3.0
>  * jupyter-console 5.0.0 -> 5.1.0 (already in dpmt git)
>  * nbformat 4.2.0 -> 4.3.0
>  * nbconvert 4.2.0 -> 5.1.1 (already in dpmt git)
>  * traitlets 4.3.1 -> 4.3.2
>  * qtconsole 4.2.1 -> 4.3.0
>  * prompt-toolkit 1.0.9 -> 1.0.14
> 
> Complicated
> 
>  * jupyter-notebook 4.2.3 -> 5.0.0
>  + upgrade codemirror -> 5.22.2
>  + upgrade underscore -> 1.8.3 (already in debian)
>  + drop term.js
>  + add xterm.js 2.3.2
>  + add preact 7.2.0
>  + add preact-compat 0.14.4
>  + add proptypes 0.14.4
>  * ipywidgets 5.2.2 -> 6.0.0
>  + add phosphor 0.7.0
>  + new internal JS package jupyter-widgets-schema
>  + new internal JS package jupyterlab-widgets
>  + upgrade jquery -> 3.1.1 (already in debian)
>  + upgrade jquery-ui -> 1.12.1 (already in debian)
>  + add font-awesome 4.5.0 (already in debian)
>  + drop bootstrap
>  + add ajv 4.9.0
>  + add jupyterlab-services
>  + add @types-backbone 1.3.33
>  + add @types-semver 5.3.30
> 
> Further dependencies:
> 
>  * xterm.js -> @types/node, typescript 2.2.0, browserify
>  * preact -> babel, webpack, rollup, typescript 2.2.2
>  * preact-compat -> babel, webpack, rollup, typescript, preact
>  * proptypes -> babel
>  * phosphor ->
>  * ajv -> co, json-stable-stringify, browserify
>  * co -> browserify
>  * json-stable-stringify -> jsonify (in debian)
> 
> Notebook buildsystem remains the same.
> 
> The ipywidgets buildsystem is still webpack based, but has gained a
> bunch of typescript dependencies as well, which will probably make
> emulating it even more complicated. The repo has moved to
> github.com/jupyter-widgets/ipywidgets - I suspect the JS and python
> stuff will get separated into different repositories at some point which
> should make it easier to package than the current monolith. Ipywidgets
> now also generates jupyterlab widgets and depends on jupyterlab
> javascript, but this is hopefully optional until jupyterlab is packaged.
> 

Thanks, this information will be very useful. I took a very quick look a few 
days ago and also agree that jupyterlab widgets can probably be skipped for 
sage.

> Jupyter is generally moving towards typescript rather than javascript,
> which is probably in general a good thing but means that where it still
> depends on javascript libraries, we need along side them type annotation
> packages (node packages: `@types/JSLIB`, I don't think any are yet in
> debian).
> 

npm is the main pain point here rather than javascript itself. Do these 
typescript packages still use npm (or a derivative), or a less stupid package 
manager?

Moving to typescript won't solve any of this stuff, unless they also move to a 
better buildsystem - which would automatically fix these development practises 
that make it difficult to package, at very little cost to the ipywidgets 
developers.

X

rant for pkg-js-devel's benefit, skip if you already agree that npm is shit:

The whole concept around declaring strict-version-constraints is what causes 
the whole mess, as well as the fact that they don't have a well-defined concept 
of what a "source package" is, and mislead their users into thinking that 
pre-built javascript is "source code".

Together these factors encourage library writers to not pay attention to API 
compatibility, which raises the cost of producing a working "build product" 
(and therefore its perceived value), which encourages people to check their 
binary-blob build products into version control (as well as binary blobs of 
their dependencies) and at the same time discourages them from testing their 
programs across many different environments.

Advertising that they are the world's "biggest repository of open source 
software" is a fucking insult to the concept of open source, when 90% of it is 
pre-built binary blobs!

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

-- 
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#850719: rollup: please consider mention why package is in contrib

2017-03-11 Thread Ximin Luo 
Source: node-rollup
Followup-For: Bug #850719

Possibly it needs undeclared extra dependencies not in Debian, see 857496 for
a description for the symptom.

X

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (300, 'unstable'), (100, 'experimental'), (1, 
'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

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

2017-01-06 Thread Ximin Luo 
Jonas Smedegaard:
> Quoting Ximin Luo (2017-01-06 11:54:00)
>> Jonas Smedegaard:
>>>>> [..] I do not see this as sustainable and I will not approve any 
>>>>> more requests in this team. if we, as a team are unable to follow 
>>>>> the processes in line with the debian philosophy and spirit, I will 
>>>>> remove myself as an admin from this team.
>>>>>
>>>>> I will not import any of these repos to alioth. Someone who relish 
>>>>> authority and elitism has to do the extra work.
>>>
>>> I wish you wouldn't give in like that, but understand your reasoning 
>>> (and appreciate that you didn't take even worse action!).
>>>
>>>
>>>> Get your head out of your own ass, and stop acting like you're a 
>>>> victim here.
>>>
>>> Go wash your mouth, and step back from your high horse: You are *not* 
>>> the boss around here (noone is), and you have no right to dictate 
>>> newly invented rules nor point fingers at peer team members choosing 
>>> to disagree with them!
>>>
>>
>> I'm neither on a high-horse nor being "the boss" around here. I'm 
>> simply pointing out the insane level of hypocrisy being directed at 
>> me.
>>
>> When I disagree with something being done that affects the whole team, 
>> I'm "dictating newly-invented rules", but when you and Praveen 
>> disagree with something, it's "being welcoming"? No, this is bullshit, 
>> and I won't apologoise for calling it bullshit nor stop calling it 
>> bullshit. Your actions have an effect on everyone, this is not about 
>> being welcoming; get off *your* high horse.
> 
> Oh, you find your own attitude and language fine, and mine problematic.  
> Thanks for sharing.
> 
> I already¹ described my opinion on how this team should treat newcomers, 
> and I (still) welcome everyone on this list to share your opinion on the 
> matter.
> 
> Based on that input, I will consider if I personally want to continue as 
> member of this team.
> 

*eyeroll* Oh well fine, I might as well jump on the bandwagon. I *also* want to 
consider personally if I want to remain on this team. Can't even have a 
discussion about how we should deal with mass-join events without being accused 
of being a dictator.

+1 to opinions and input from more people.

Finally, let me try to sort out the mess. Firstly, I am sorry that I was too 
heavy in my first post. I did not mean to imply that I think these people 
should *never* join the team, or suggest that I was rigid about the "package a 
second package etc" condition. I tried to explain this later, hopefully I am 
more clear here.

Secondly, there was no need to immediately go create separate repos, Praveen 
your students could have waited a while. However, it should be easy to just 
script the creation of these extra repos via the ./setup-repository script that 
we already have. They will each have to register their SSH keys manually, but 
they had to do that in any case. I don't think there is too much extra work 
adding a second git remote and pushing to it.

Thirdly, you talk about about welcoming new contributors, but there are 
existing people on the team to consider as well. It's always easier to 
accommodate new people one-by-one and get to know them, if they join slowly. If 
lots of people join at once, it's reasonable to ask that they do things 
slightly differently, to give the existing team members some time to adjust. 
Obviously nobody would think of autojoining 1000 people at once, everyone has 
some idea of what is "reasonable"; this is not "dictating" who can or can't 
join. Others have voiced opinions along these lines too already, similar but 
different from the suggestions I made. I welcome people to expand on these in 
more detail, and hopefully it'll come across less forceful than my attempts.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

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

2017-01-06 Thread Ximin Luo 
Jonas Smedegaard:
>>> [..] I do not see this as sustainable and I will not approve any more 
>>> requests in this team. if we, as a team are unable to follow the 
>>> processes in line with the debian philosophy and spirit, I will 
>>> remove myself as an admin from this team.
>>>
>>> I will not import any of these repos to alioth. Someone who relish 
>>> authority and elitism has to do the extra work.
> 
> I wish you wouldn't give in like that, but understand your reasoning 
> (and appreciate that you didn't take even worse action!).
> 
> 
>> Get your head out of your own ass, and stop acting like you're a 
>> victim here.
> 
> Go wash your mouth, and step back from your high horse: You are *not* 
> the boss around here (noone is), and you have no right to dictate newly 
> invented rules nor point fingers at peer team members choosing to 
> disagree with them!
> 

I'm neither on a high-horse nor being "the boss" around here. I'm simply 
pointing out the insane level of hypocrisy being directed at me.

When I disagree with something being done that affects the whole team, I'm 
"dictating newly-invented rules", but when you and Praveen disagree with 
something, it's "being welcoming"? No, this is bullshit, and I won't apologoise 
for calling it bullshit nor stop calling it bullshit. Your actions have an 
effect on everyone, this is not about being welcoming; get off *your* high 
horse.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

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

2017-01-06 Thread Ximin Luo 
Pirate Praveen:
> On വ്യാഴം 05 ജനുവരി 2017 10:20 വൈകു, Ximin Luo wrote:
>> Let's please talk about the specifics of this situation rather than 
>> appealing to vague notions of being welcoming.
> 
> This is completely arbitrary restriction. I was thinking we evaluate
> people based on what they have done, rather than when and where they
> have done it. I don't agree with this notion.
> 
>> It's my experience that events like these do not generally result in 
>> long-term maintainers. Yes, I am indeed treating them as "inactive" before 
>> they have already joined, based on what I have seen of related events. So I 
>> propose some reasonable checks, to ensure that we get people who are 
>> interested. I disagree that this attitude is flawed.
> 
> This is pure prejudice based on your personal experience. We should not
> be basing our standards based on personal prejudice and paint a large
> number of people with same color.
> 
>> I didn't propose a similar check for previous incoming contributors because 
>> they did not have a background context of a mass-join event. So it does not 
>> make sense to compare these two situations.
> 
> Arbitrary and discriminatory.
> 

Being a maintainer is about more than doing one small thing. Considering when 
and where they have done it is completely appropriate, and it is completely 
right and fair of me to take into account my own personal experience and 
background context about these types of events.

Pirate Praveen:
> All debian processes has been about advocacy and decision by people who
> have worked with new people. It was never about people who are unaware
> about the contributions. In this case, being the person who has worked
> close with them, I should have been the right person to decide. But it
> seems people who are totally uninformed wants to decide and just want to
> use their personal prejudice as the single deciding factor. [..]

Yes, I have less information than you do. How about instead of accusing me of 
being "discriminatory" and judging without information, you provide us with 
more information? You haven't mentioned who these people are in any amount of 
detail, all you said is that they are some students attending an event run by 
you - ironically painting a large number of people with the same color, 
yourself! Tell us some stories about who each of these individuals are!

> [..] I do not see
> this as sustainable and I will not approve any more requests in this
> team. if we, as a team are unable to follow the processes in line with
> the debian philosophy and spirit, I will remove myself as an admin from
> this team.
> 
> I will not import any of these repos to alioth. Someone who relish
> authority and elitism has to do the extra work.

Get your head out of your own ass, and stop acting like you're a victim here. 
You keep talking about the Debian "philosophy and spirit"; spamming 10 people 
into a group with requests like "I want to package, give me access" is NOT 
that. This does not help anyone trust anyone. Being cautious about these types 
of actions, is not authority or elitism.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

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

2017-01-05 Thread Ximin Luo 
Jonas Smedegaard:
> [..]
> 
> I (loudly!) oppose treating not-yet-members as inactive: Improving 
> security by minimizing activity is a luxury we cannot afford!
> 
> [..]
> 
> Since when did we validate membership based on how they formulated 
> their requests to join?
> 
> Were you yourself treated with scrutiny when you joined, then I 
> appologize on behalf of the team, and kindly ask you to not repeat that 
> flawed attitude towards newcomers.
> 
> or alternatively - if this team generally appraise such attitude, I will 
> respect that by leaving the team, as I personally appreciate the *lack* 
> of hierarchy in Debian.
> 

Let's please talk about the specifics of this situation rather than appealing 
to vague notions of being welcoming.

It's my experience that events like these do not generally result in long-term 
maintainers. Yes, I am indeed treating them as "inactive" before they have 
already joined, based on what I have seen of related events. So I propose some 
reasonable checks, to ensure that we get people who are interested. I disagree 
that this attitude is flawed.

I didn't propose a similar check for previous incoming contributors because 
they did not have a background context of a mass-join event. So it does not 
make sense to compare these two situations.

We totally do validate membership (everywhere, not just this alioth group) 
based on how people formulate their requests to join. Vague requests are 
generally rejected in most places, and rightly so.

Having minimum standards of quality is not "hierarchy".

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

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

2017-01-05 Thread Ximin Luo 
Jonas Smedegaard:
> Quoting Ximin Luo (2017-01-05 13:51:00)
>>
>> [..]
>>
>> The security aspect is just one factor, not the main factor.
> 
> Ok, you now tell me that security is not the main factor.
> 
> I clearly read your previous email as if security was the main factor 
> for rejecting these requests.  For clarity of discussion I shall 
> *ignore* the security factor.
> 
> 
>> But to give more detail, (a) just because we have "little" security, 
>> doesn't mean we have to make it quantitatively worse, which we will do 
>> if we add anyone that asks - it adds surface area. And (b) the 
>> standards of time and continual maintenance that I described 
>> elsewhere, also indicates that a person is careful about their general 
>> computing practices, which also helps to not-reduce security - 
>> compared to giving access to a random person.
> 
> Do I understand you correctly that in your opinion the main factor is 
> devotion to continued mainentance?
> 

I agree it's the main factor, but for me this is also linked to security. 
Having lots of inactive people with that level of access increases risk with no 
benefit in return. It's better to have fewer active people. (Of course lots of 
active people are even better.)

> If so, then we agree on what is "main factor" - but still we disagree on 
> how to then deal with it:
> 
> It seems Praveen find it reasonable to approve "because they are ready 
> to upload their packages", and it seems you find that exact situation 
> reason for rejecting.  I find it neither reject nor approve reason.
> 
> I welcome into this team any and all persons who feel they are ready to 
> *maintain* official Debian packages.  I find it wrong to impose 
> restrictions on that, but I want to emphasize _maintain_ - this team is 
> *not* the Javascript *contribution* team (there are other methods to 
> contribute to Debian in other ways than continuous mainenance).
> 

This is why I suggested having them apply individually later. They can see if 
they're comfortable with doing this semi-regularly. Everything is more fun at a 
group event but this is not the same as robust long-term maintenance of 
packages.

Another issue that I noticed is some of the requests were very vague. (Other 
requests were suitably specific.) I hope these are fixed the next time around. 
Since most of these javascript packages are very small, it would also be good 
to mention more numbers of packages in these requests.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

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

2017-01-05 Thread Ximin Luo 
Pirate Praveen:
> On വ്യാഴം 05 ജനുവരി 2017 06:44 വൈകു, Ximin Luo wrote:
>> It's normal convention in any organisation or project to temporarily revert 
>> a change that is controversial.
> 
> ok.
> 
>> Adding 10 new people from an event, every time there is an event, is also 
>> not sustainable as a team.
> 
> I have organized many packaging workshops over the years. I don't grant
> access to any one just because they attended an event. I have granted
> them access only because I am convinced they qualify to get this access.
> 
> They learned how to make a package lintian clean, how run a clean build
> using sbuild, make patches using quilt, how to repack. They did all this
> by themselves on 3-4 packages that was already packaged before they
> started with a new package.
> 

OK, thanks for sharing these details, it really helps us to properly discuss 
this situation. In terms of knowledge, it sounds like they are sufficiently 
capable.

I still think it's better to have them make requests in their own time, instead 
of all at once. This gives some time for us to read properly their request, and 
distinguish and remember them as individuals separately from the other people 
that also want to join.

It also gives them some time to practise these things and decide if they really 
want to continue with it in the long run. I agree with Jonas that this team 
(and other alioth teams) should be about maintenance, not just contributions. 
(We can continue on this topic in the other subthread.)

>> Please respond to my points (about responsibility, maintenance and events) 
>> instead of accusing me of "contempt" simply because I disagreed with your 
>> actions.
> 
> We do not have such rules for accepting a first package or granting them
> access to a project. I was only following the convention we have set for
> this team.
> 
>> I also don't see why you are making such a fuss. The conditions I described 
>> (making a request at a later date, individually) are not particularly hard 
>> to achieve, and helps to confirm their true long-term interest in being a 
>> team member, to the rest of us that are unsure about these events.
> 
> I make a fuss because you are acting arbitrarily, making up policies and
> rules on the go.
> 

I understand. I did not mean to arbitrarily impose anything - reverting their 
membership was only meant as a temporary measure whilst the discussion is still 
ongoing.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

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

2017-01-05 Thread Ximin Luo 
Pirate Praveen:
> On വ്യാഴം 05 ജനുവരി 2017 06:21 വൈകു, Ximin Luo wrote:
>> We don't have hard rules, but we all have our ideas about what is right or 
>> wrong. For you, it is a question of "are they aware". For me, I explained it 
>> in my other email, and it roughly overlaps with "are they aware".
> 
> I have accepted their request because I have spent time with them. By
> removing people that I have accepted you showed contempt for my
> judgment. What authority do you have to remove people from the project
> just because they are new?
> 
> Is this how this team want to continue? If I have acted wrongly, then
> please remove my admin access as well. But this kind of action is not
> sustainable as a team.
> 

It's normal convention in any organisation or project to temporarily revert a 
change that is controversial.

Adding 10 new people from an event, every time there is an event, is also not 
sustainable as a team.

Please respond to my points (about responsibility, maintenance and events) 
instead of accusing me of "contempt" simply because I disagreed with your 
actions.

I also don't see why you are making such a fuss. The conditions I described 
(making a request at a later date, individually) are not particularly hard to 
achieve, and helps to confirm their true long-term interest in being a team 
member, to the rest of us that are unsure about these events.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

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

2017-01-05 Thread Ximin Luo 
Pirate Praveen:
> On വ്യാഴം 05 ജനുവരി 2017 06:09 വൈകു, Ximin Luo wrote:
>> This has nothing to do with tools, as Jonas mentioned it is about a 
>> continual time dedication to a FOSS project. Please try to understand this.
> 
> Yes, it has a lot to do with our tools. If we were using a git hosting
> tool like gitlab or pagure, we could have reviewed pull requests before
> we grant access to a new contributor.
> 
> You can't demand such dedication from a new contributor. Did you sign
> such a commitment before you got access to pkg-javascript team and debian?
> 
> What did you mean when you said they can use github.com? Isn't that
> evidence of our lack of tools to bring new people to debian? Why should
> I tell anyone to use a proprietary service to contribute to debian? This
> is something we got to fix.
> 
>> It is easy to find people that will do some work at an event under guidance, 
>> but this is very different from someone finding alioth in their own spare 
>> time and out of their own motivation. So the situation is different from 
>> typical contributors that make these requests.
> 
> We don't ask any new contributor for such commitment and it is not
> acceptable you acting unilaterally and removing people from the group.
> 
>> To be granted access, someone should demonstrate that they will properly 
>> take care of the things they claim responsibility for, not merely doing a 
>> one-time task at a fun event that temporarily is quite enjoyable.
> 
> We don't ask such questions to any new contributors. Is it just because
> there were many? If there were only one or two people, you would not
> have even noticed it. So is bringing more people to debian discouraged?
> 
>> As I said, I will happily agree to accept any of these people if they send 
>> in a request at a later date, indicating that they have one of the latter 
>> qualities, either by packaging a second package or by showing that they have 
>> properly maintained the first package that they have taken on.
> 
> If that is the qualification, then we should make it as a team policy
> and enforce it for everyone.
> 
>> Otherwise, from what you described, it doesn't seem like alioth access is 
>> vital for what these people want to do anyway.
> 
> You clearly accepted my argument that its a tool problem. We don't have
> tools in debian to accept contributions this way.
> 

Please try to understand the difference between 10 people at an event asking 
for access because 1 person instructed them to, vs single people asking for 
access at unrelated periods.

Otherwise, this discussion won't move forward.

There are many ways of contributing to Debian and FOSS, and spamming your way 
into infrastructure isn't one of them.

Some people have said they agree with me in other channels, so I am acting as 
"unilaterally" as you are, by inviting this many people into the group without 
consulting people first.

I don't think we need a formal policy, just rough understanding of the point 
that I am trying to make:

10 people at an event asking for access because 1 person instructed them to, vs 
single people asking for access at unrelated periods. These are very very 
different things. Please try to understand this, rather than nitpicking various 
aspects of the point I am making.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

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

2017-01-05 Thread Ximin Luo 
Jonas Smedegaard:
> Quoting Ximin Luo (2017-01-05 12:53:00)
>> Pirate Praveen:
>>> On വ്യാഴം 05 ജനുവരി 2017 04:22 വൈകു, Jérémy Lal wrote:
>>>> This is great, but is this serious ?
>>>> Anyone knows what's happening ?
> 
>>> I'm taking a packaging workshop at College of Engineering Pune [1].
>>>
>>> This is 4th day of the workshop and many have completed their packages
>>> and are ready for upload.
>>>
>>> https://lists.debian.org/debian-dug-in/2016/12/msg1.html
>>>
>>> Initially some sent requests before I told them to give details about
>>> their package. So please approve if the information is complete.
>>>
>>
>> Hi, please don't add these people.
>>
>> People in the alioth group have read-write access to all pkg-javascript git 
>> repos as well as shell access on that machine.
>>
>> I don't think it's right to give this many people, who show up at an event, 
>> this level of access without any other requirement. It is too dangerous.
>>
>> I have rejected these requests and removed these people until they package a 
>> second package *in their own spare time* outside of an event. In the 
>> meantime, they can push their packages on github, this is adequate for a 
>> sponsored upload to Debian.
> 
> I disagree with that approach, Ximian:
> 
> We do not in this team have any rules for membership that one must first 
> prove her worth by packaging outside of Debian, not that they must use 
> their spare time doing so!
> 
> I am concerned if people requesting to join are fully aware what it is 
> they join, which is why I asked about that.  But I see nothing wrong 
> with approving people we don't know well.
> 
> We must recognize that we have little security fencing the assets of 
> this team, and treat them accordingly (double-check what you pull, sign 
> changes you make, etc.).  Making it harder to join this team does *not* 
> help secure our assets!
> 

We don't have hard rules, but we all have our ideas about what is right or 
wrong. For you, it is a question of "are they aware". For me, I explained it in 
my other email, and it roughly overlaps with "are they aware".

The security aspect is just one factor, not the main factor. But to give more 
detail, (a) just because we have "little" security, doesn't mean we have to 
make it quantitatively worse, which we will do if we add anyone that asks - it 
adds surface area. And (b) the standards of time and continual maintenance that 
I described elsewhere, also indicates that a person is careful about their 
general computing practices, which also helps to not-reduce security - compared 
to giving access to a random person.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

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

2017-01-05 Thread Ximin Luo 
Pirate Praveen:
> On വ്യാഴം 05 ജനുവരി 2017 05:23 വൈകു, Ximin Luo wrote:
>> Hi, please don't add these people.
>>
>> People in the alioth group have read-write access to all pkg-javascript git 
>> repos as well as shell access on that machine.
>>
>> I don't think it's right to give this many people, who show up at an event, 
>> this level of access without any other requirement. It is too dangerous.
> 
> They have been learning packaging and doing hands on work for 4 full
> days (at least 8*4 hours of continuous packaging work). This is how we
> add new people to a project. It is something that has to be fixed in the
> tools.
> 
>> I have rejected these requests and removed these people until they package a 
>> second package *in their own spare time* outside of an event. In the 
>> meantime, they can push their packages on github, this is adequate for a 
>> sponsored upload to Debian.
> 
> I think they qualify the requirements we ask for any new contributor.
> 

This has nothing to do with tools, as Jonas mentioned it is about a continual 
time dedication to a FOSS project. Please try to understand this.

It is easy to find people that will do some work at an event under guidance, 
but this is very different from someone finding alioth in their own spare time 
and out of their own motivation. So the situation is different from typical 
contributors that make these requests.

To be granted access, someone should demonstrate that they will properly take 
care of the things they claim responsibility for, not merely doing a one-time 
task at a fun event that temporarily is quite enjoyable.

As I said, I will happily agree to accept any of these people if they send in a 
request at a later date, indicating that they have one of the latter qualities, 
either by packaging a second package or by showing that they have properly 
maintained the first package that they have taken on.

Otherwise, from what you described, it doesn't seem like alioth access is vital 
for what these people want to do anyway.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

-- 
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#846515: src:jquery-ui-themes: path of css files changed

2016-12-11 Thread Ximin Luo 
Hi Paul,

Sorry for the late reply. I'm not subscribed to pkg-javascript@ so I don't 
notice these things, I only notice via my QA page. (Possibly I should remove 
myself from Uploaders, since I don't intend to maintain this in the future, as 
far as I can avoid doing so.)

On Thu, 01 Dec 2016 21:01:32 +0100 Paul Gevers  wrote:
> Package: src:jquery-ui-themes
> Version: 1.12.1+dfsg-1
> Severity: important
> 
> Hi Ximin,
> 
> The debci test of cacti¹ started failing after the update of
> jquery-ui-themes. This is caused by the change of the css file names in the
> packages. The names used to be
> /javascript/jquery-ui-themes//jquery.ui.all.css and are now
> /javascript/jquery-ui-themes//jquery.ui.css. To avoid all dependent
> packages requiring updating, I suggest to rename back to the old name, unless
> this was really done on purpose. In that case I'd like to hear why.
> 
> Paul
> 
> ¹ https://ci.debian.net/packages/c/cacti/unstable/amd64/
> 

This description is not entirely correct, in fact both versions contain 
jquery-ui.css - note the dash instead of a dot.

The new version [1] does not contain any jquery.ui.* files, that is what the 
upstream distribution zip chose for this version. I didn't do this.

The old version [2] contains both jquery-ui.css as well as jquery.ui.all.css. 
The former seems to be an amalgated single-file version of the theme, the 
latter @imports the separate files when loaded.

It looks like upstream has dropped support for this type of usage in the new 
version, though that was what the old README.Debian recommended.

This is a very unfortunate situation but I don't think it would be appropriate 
for Debian to "put back in" the old feature that upstream dropped.

I hope this kind of crappy situation would be an incentive for everyone to 
avoid using JS in their own projects as far as possible, or at least only use 
the good JS projects and avoid the crappy ones (and learn how to distinguish 
them).

X

[1] https://packages.debian.org/sid/all/libjs-jquery-ui-theme-blitzer/filelist
[2] 
https://packages.debian.org/jessie/all/libjs-jquery-ui-theme-blitzer/filelist

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

-- 
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#847740: jquery: FTBFS: Error: Cannot find module '/usr/lib/nodejs/r.js'

2016-12-11 Thread Ximin Luo 
Hello jquery maintainer,

This was partially my "fault", I asked requirejs to fix bug #845158 and they 
did, but of course other packages in Debian would still be using the old name.

Upstream says require('requirejs')
http://requirejs.org/docs/node.html

Here is the new file list:
https://packages.debian.org/sid/all/node-requirejs/filelist

X

Chris Lamb:
> Source: jquery
> Version: 3.1.1-1
> 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,
> 
> jquery fails to build from source in unstable/amd64:
> 
>   […]
> 
>  dh_auto_configure
>  debian/rules override_dh_auto_build
>   make[1]: Entering directory '«BUILDDIR»'
>   sed -e '/^\/\*\s*eslint-/d; /^\/\/ @CODE/,$ d' src/wrapper.js > start.js || 
> (rm -f start.js; false)
>   sed -e '1,/^\/\/ @CODE/ d; /\/\/ build.js inserts compiled jQuery here/d' 
> src/wrapper.js > end.js || (rm -f end.js; false)
>   cp debian/build.js build.js
>   nodejs /usr/lib/nodejs/r.js -o build.js
>   module.js:327
>   throw err;
>   ^
>   
>   Error: Cannot find module '/usr/lib/nodejs/r.js'
>   at Function.Module._resolveFilename (module.js:325:15)
>   at Function.Module._load (module.js:276:25)
>   at Function.Module.runMain (module.js:441:10)
>   at startup (node.js:139:18)
>   at node.js:974:3
>   debian/rules:14: recipe for target 'dist/jquery.js' failed
>   make[1]: *** [dist/jquery.js] Error 1
>   make[1]: Leaving directory '«BUILDDIR»'
>   debian/rules:40: recipe for target 'binary' failed
>   make: *** [binary] Error 2
>   dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit 
> status 2
> 
>   […]
> 
> The full build log is attached.
> 
> 
> Regards,
> 
> 
> 
> ___
> Reproducible-bugs mailing list
> reproducible-b...@lists.alioth.debian.org
> https://lists.alioth.debian.org/mailman/listinfo/reproducible-bugs
> 


-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

-- 
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] jquery-ui-themes_1.12.1+dfsg-1_source.changes ACCEPTED into unstable

2016-11-29 Thread Ximin Luo 
Paul Gevers:
> Hi Ximin,
> 
> I forgot to say "thank you for your work on jquery-ui-themes" in my
> previous e-mail.
> 
> I agree with you.
> 

You're welcome, and thanks for understanding! And don't worry, it was not 
anything you said or didn't say that set me off, I would have said this sooner 
or later to some audience or other.

Anyway, as someone wise probably said at some point, "the most effective way to 
thoroughly destroy something is to replace it with something better". :) I will 
try to do that for JS and minimise the amount of time I and everyone else has 
to sink into this black hole.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

-- 
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#845748: libjs-bootswatch: please symlink /usr/share/javascript/bootstrap/fonts to /usr/share/javascript/bootswatch/fonts

2016-11-26 Thread Ximin Luo 
Package: libjs-bootswatch
Version: 3.3.5+2+dfsg1-1
Severity: normal
Tags: patch

Dear Maintainer,

grep -Ri "url('../fonts/glyphicons" /usr/share/javascript/bootswatch/ | less

turns up lots of results, however that path does not exist. This causes errors 
in the browser like "GET [$path] net::ERR_FILE_NOT_FOUND"

A simple symlink to the fonts directory of the libjs-bootstrap package would 
solve this problem. Don't forget to add a runtime dependency, also.

Thanks!
X

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable'), (300, 'unstable'), (200, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

libjs-bootswatch depends on no packages.

Versions of packages libjs-bootswatch recommends:
ii  javascript-common  11

libjs-bootswatch suggests no packages.

-- no debconf information

-- 
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#789446: libv8-3.14: FTBFS with glibc-2.21 and gcc-5

2015-08-31 Thread Ximin Luo 
Control: close -1 3.14.5.8-10

On 31/08/15 10:03, Jérémy Lal wrote:
> Hello,
> 
> 2015-08-31 3:54 GMT+02:00 Ximin Luo <infini...@debian.org 
> <mailto:infini...@debian.org>>:
> 
> Package: src:libv8-3.14
> Followup-For: Bug #789446
> Control: reopen -1
> 
> Dear Maintainer,
> 
> I'm not sure the fix, setting that = 0 is the best option.
> 
> nodejs themselves manually patched their bundeled version of v8 
> specifically for this bug, see:
> 
> 
> https://github.com/nodejs/node/commits/v0.10.38-release/deps/v8/include/v8.h
> 
> which points to:
> 
> 
> https://github.com/nodejs/node/commit/881ac26f27f4ac9585d66c8d8a67d5b246a23d1b#diff-42f385dff7890b3c213d9699bcc350cc
> 
> We should probably import this, instead of the current "fix".
> 
> 
> This has no relation with "FTBFS with glibc-2.21 and gcc-5".
> Please close this bug, and open a new one !
> 
> Jérémy.
> 

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git

___
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#797545: libv8-3.14-dev: better fix for REPLACE_INVALID_UTF8

2015-08-31 Thread Ximin Luo 
Package: libv8-3.14-dev
Version: 3.14.5.8-10
Severity: normal

Hi,

It's not so clear that the recent workaround for REPLACE_INVALID_UTF8 is
such a good idea. In general, this sort of thing has the potential to lead
to security problems.

nodejs themselves manually patched their bundeled version of v8 specifically 
for this bug, see:

https://github.com/nodejs/node/commits/v0.10.38-release/deps/v8/include/v8.h

which points to:

https://github.com/nodejs/node/commit/881ac26f27f4ac9585d66c8d8a67d5b246a23d1b#diff-42f385dff7890b3c213d9699bcc350cc

We should probably import this, instead of the current "fix".

X

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.0.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libv8-3.14-dev depends on:
ii  libv8-3.14.5  3.14.5.8-10

libv8-3.14-dev recommends no packages.

libv8-3.14-dev suggests no packages.

-- no debconf information

___
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#789446: libv8-3.14: FTBFS with glibc-2.21 and gcc-5

2015-08-30 Thread Ximin Luo 
Package: src:libv8-3.14
Followup-For: Bug #789446
Control: reopen -1

Dear Maintainer,

I'm not sure the fix, setting that = 0 is the best option.

nodejs themselves manually patched their bundeled version of v8 specifically 
for this bug, see:

https://github.com/nodejs/node/commits/v0.10.38-release/deps/v8/include/v8.h

which points to:

https://github.com/nodejs/node/commit/881ac26f27f4ac9585d66c8d8a67d5b246a23d1b#diff-42f385dff7890b3c213d9699bcc350cc

We should probably import this, instead of the current fix.

X

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.0.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

___
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#740569: node-gyp: make node-gyp compile unconditionally using -fPIC

2014-03-02 Thread Ximin Luo 
Package: node-gyp
Version: 0.10.10-2
Severity: normal

/usr/share/node-gyp/addon.gypi has the following logic:

  [ 'OS==freebsd or OS==openbsd or OS==solaris or (OS==linux and 
target_arch!=ia32)', {
'cflags': [ '-fPIC' ],
  }]

I request that the the 'target_arch!=ia32' be removed so that -fPIC is 
unconditionally used.

Otherwise, lintian complains, when a package is built using node-gyp:

http://lintian.debian.org/maintainer/pkg-javascript-de...@lists.alioth.debian.org.html#node-ws
 


-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.9-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages node-gyp depends on:
ii  gyp   0.1~svn1729-3
ii  node-fstream  0.1.24-1
ii  node-glob 3.2.6-1
ii  node-graceful-fs  2.0.0-2
ii  node-minimatch0.2.12-1
ii  node-mkdirp   0.3.5-1
ii  node-nopt 2.1.2-1
ii  node-npmlog   0.0.4-1
ii  node-osenv0.0.3-1
ii  node-request  2.26.1-1
ii  node-rimraf   2.2.2-2
ii  node-semver   2.1.0-2
ii  node-tar  0.1.18-1
ii  node-which1.0.5-2
ii  nodejs0.10.25~dfsg2-2
ii  nodejs-dev0.10.25~dfsg2-2

Versions of packages node-gyp recommends:
ii  build-essential  11.6

node-gyp suggests no packages.

-- no debconf information

___
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#735617: depends on /usr/bin/node against policy

2014-01-16 Thread Ximin Luo 
Package: node-gyp
Version: 0.10.10-2
Severity: serious

node-gyp depends on /usr/bin/node function (i.e. implicitly requiring 
nodejs-legacy installed), against policy:

https://lists.debian.org/debian-devel-announce/2012/07/msg2.html

No package in the archive may depend on .. nodejs-legacy.

node-gyp must be patched to call /usr/bin/nodejs instead.

Attempting to build node-ws[1] without nodejs-legacy installed (you may need to 
checkout an older commit by the time you read this) gives this error:

gyp info spawn python
gyp info spawn args [ '/usr/share/node-gyp/gyp/gyp',
gyp info spawn args   'binding.gyp',
gyp info spawn args   '-f',
gyp info spawn args   'make',
gyp info spawn args   '-I',
gyp info spawn args   '/tmp/buildd/node-ws-0.4.30/build/config.gypi',
gyp info spawn args   '-I',
gyp info spawn args   '/usr/share/node-gyp/addon.gypi',
gyp info spawn args   '-I',
gyp info spawn args   '/usr/include/nodejs/common.gypi',
gyp info spawn args   '-Dlibrary=shared_library',
gyp info spawn args   '-Dvisibility=default',
gyp info spawn args   '-Dnode_root_dir=/usr/include/nodejs',
gyp info spawn args   '-Dmodule_root_dir=/tmp/buildd/node-ws-0.4.30',
gyp info spawn args   '--depth=.',
gyp info spawn args   '--generator-output',
gyp info spawn args   'build',
gyp info spawn args   '-Goutput_dir=.' ]
/bin/sh: 1: node: not found
gyp: Call to 'node -p -e require('path').dirname(require.resolve('nan'))' 
returned exit status 127. while trying to load binding.gyp


-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.9-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages node-gyp depends on:
ii  gyp               0.1~svn1729-3
ii  node-fstream      0.1.24-1
ii  node-glob         3.2.6-1
ii  node-graceful-fs  2.0.0-2
ii  node-minimatch    0.2.12-1
ii  node-mkdirp       0.3.5-1
ii  node-nopt         2.1.2-1
ii  node-npmlog       0.0.4-1
ii  node-osenv        0.0.3-1
ii  node-request      2.26.1-1
ii  node-rimraf       2.2.2-2
ii  node-semver       2.1.0-2
ii  node-tar          0.1.18-1
ii  node-which        1.0.5-2
ii  nodejs            0.10.23~dfsg1-3
ii  nodejs-dev        0.10.23~dfsg1-3

Versions of packages node-gyp recommends:
ii  build-essential  11.6

node-gyp suggests no packages.

-- no debconf information

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