[Pkg-javascript-devel] Bug#701312: libv8: ftbfs with GCC-4.8
Package: src:libv8 Version: 3.8.9.20-2 Severity: important Tags: sid jessie User: debian-...@lists.debian.org Usertags: ftbfs-gcc-4.8 The package fails to build in a test rebuild on at least amd64 with gcc-4.8/g++-4.8, but succeeds to build with gcc-4.7/g++-4.7. The severity of this report may be raised before the jessie release. ../src/checks.h:259:22: error: typedef '__StaticAssertTypedef__440' locally defined but not used [-Werror=unused-local-typedefs] The full build log can be found at: http://people.debian.org/~doko/logs-20130217/gcc48/libv8_3.8.9.20-2_unstable_gcc48.log The last lines of the build log are at the end of this report. To build with GCC 4.8, either set CC=gcc-4.8 CXX=g++-4.8 explicitly, or install the gcc, g++, gfortran, ... packages from experimental. apt-get -t experimental install g++ g++-4.7 g++-4.8 libc6-dev The test rebuild was done with eglibc-2.17 and GCC-4.8, so some issues might be caused by the updated glibc. [...] ../src/checks.h:291:30: note: in expansion of macro 'STATIC_CHECK' #define STATIC_ASSERT(test) STATIC_CHECK(test) ^ ../src/preparse-data.cc:75:3: note: in expansion of macro 'STATIC_ASSERT' STATIC_ASSERT(PreparseDataConstants::kMessageTextPos == 3); ^ cc1plus: all warnings being treated as errors make[2]: *** [/«PKGBUILDDIR»/out/x64.release/obj.target/preparser_lib/src/preparse-data.o] Error 1 In file included from ../src/preparser-api.cc:36:0: ../src/scanner.h: In member function 'void v8::internal::Scanner::Init()': ../src/checks.h:259:22: error: typedef '__StaticAssertTypedef__440' locally defined but not used [-Werror=unused-local-typedefs] SEMI_STATIC_JOIN(__StaticAssertTypedef__, __LINE__) ^ ../src/checks.h:249:39: note: in definition of macro 'SEMI_STATIC_JOIN_HELPER' #define SEMI_STATIC_JOIN_HELPER(a, b) a##b ^ ../src/checks.h:259:5: note: in expansion of macro 'SEMI_STATIC_JOIN' SEMI_STATIC_JOIN(__StaticAssertTypedef__, __LINE__) ^ ../src/checks.h:291:30: note: in expansion of macro 'STATIC_CHECK' #define STATIC_ASSERT(test) STATIC_CHECK(test) ^ ../src/scanner.h:440:5: note: in expansion of macro 'STATIC_ASSERT' STATIC_ASSERT(kCharacterLookaheadBufferSize == 1); ^ cc1plus: all warnings being treated as errors In file included from ../src/preparser.cc:33:0: ../src/scanner.h: In member function 'void v8::internal::Scanner::Init()': ../src/checks.h:259:22: error: typedef '__StaticAssertTypedef__440' locally defined but not used [-Werror=unused-local-typedefs] SEMI_STATIC_JOIN(__StaticAssertTypedef__, __LINE__) ^ ../src/checks.h:249:39: note: in definition of macro 'SEMI_STATIC_JOIN_HELPER' #define SEMI_STATIC_JOIN_HELPER(a, b) a##b ^ ../src/checks.h:259:5: note: in expansion of macro 'SEMI_STATIC_JOIN' SEMI_STATIC_JOIN(__StaticAssertTypedef__, __LINE__) ^ ../src/checks.h:291:30: note: in expansion of macro 'STATIC_CHECK' #define STATIC_ASSERT(test) STATIC_CHECK(test) ^ ../src/scanner.h:440:5: note: in expansion of macro 'STATIC_ASSERT' STATIC_ASSERT(kCharacterLookaheadBufferSize == 1); ^ make[2]: *** [/«PKGBUILDDIR»/out/x64.release/obj.target/preparser_lib/src/preparser-api.o] Error 1 cc1plus: all warnings being treated as errors make[2]: *** [/«PKGBUILDDIR»/out/x64.release/obj.target/preparser_lib/src/preparser.o] Error 1 make[2]: Leaving directory `/«PKGBUILDDIR»/out' make[1]: *** [x64.release] Error 2 make: *** [debian/stamp-makefile-build] Error 2 dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2 ___ 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] packaging WebRTC, and pkg-javascript git repos
Hi, Thanks for adding me to the group I'm planning to upload packages of the two main WebRTC clients, SIPml5 and JsSIP I haven't done any JavaScript packaging before so any feedback is welcome I'm also working on the server-side infrastructure for WebRTC to come into Debian: http://www.resiprocate.org/WebRTC_and_SIP_Over_WebSockets Also, I notice that git SCM wasn't enabled in alioth, so I enabled it. Now it displays a link to http://alioth.debian.org/scm/browser.php?group_id=100128 and doesn't easily let people browse all the repos Furthermore, when I was added to the group, I notice alioth didn't automatically add me to the UNIX group scm_pkg-javascript - maybe this is because the SCM tool wasn't enabled at the time I was added. Anyhow, I've raised a ticket for the alioth support group to check my permissions. Regards, Daniel ___ 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] sipml5_0.0.20130223.1813-1_amd64.changes is NEW
Your package contains new components which requires manual editing of the override file. It is ok otherwise, so please be patient. New packages are usually added to the override file about once a week. ___ 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] packaging WebRTC, and pkg-javascript git repos
Quoting Daniel Pocock (2013-02-23 22:59:05) Thanks for adding me to the group Welcome to the team, Daniel :-) I'm planning to upload packages of the two main WebRTC clients, SIPml5 and JsSIP I haven't done any JavaScript packaging before so any feedback is welcome I'm also working on the server-side infrastructure for WebRTC to come into Debian: http://www.resiprocate.org/WebRTC_and_SIP_Over_WebSockets Sounds great! Generally I suggest to look at existing packages and follow how they are done. Feel free to ask questions. Also feel free to simply wonder loudly, even if not really questions - our team Policy is still pretty loose, e.g. we have no rules for handling versioning or placement of non-JavaScript files like CSS, and it won't hurt to try raise such discussions... Also, I notice that git SCM wasn't enabled in alioth, so I enabled it. Now it displays a link to http://alioth.debian.org/scm/browser.php?group_id=100128 and doesn't easily let people browse all the repos As I understand it, the Alioth interface is crappy and only provides interface for a single git repository, not a pile of them as we need. If I am right in that, I strongly recommend to *not* enable the VCS in the Alioth interface. Also, I prefer to use collab-maint and only use this team at Alioth for our mailinglist. The reason for that is to make it easiest possible for DDs to contribute (because all DDs are by default member of collab-maint). I find that easing access for DDs outweigh making it easiest possible for non-DDs to contribute (they need to first become member of our team and then ask for additional membership of collab-maint). I have heard rumors that it should be possible to ask the Alioth admins to mark our SCM area as automatically including all DDs just as the collab-maint does, but I have not checked if that is indeed possible. Do anyone in this team object to grant access to all DDs to our SCM? If not, do someone volunteer to figure out if it is possible? Furthermore, when I was added to the group, I notice alioth didn't automatically add me to the UNIX group scm_pkg-javascript - maybe this is because the SCM tool wasn't enabled at the time I was added. Anyhow, I've raised a ticket for the alioth support group to check my permissions. Maybe just a matter of time. Some ACL-related stuff is applied by CRON jobs. - 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
Re: [Pkg-javascript-devel] packaging WebRTC, and pkg-javascript git repos
On 23/02/13 23:32, Jonas Smedegaard wrote: Also, I notice that git SCM wasn't enabled in alioth, so I enabled it. Now it displays a link to http://alioth.debian.org/scm/browser.php?group_id=100128 and doesn't easily let people browse all the repos As I understand it, the Alioth interface is crappy and only provides interface for a single git repository, not a pile of them as we need. If I am right in that, I strongly recommend to *not* enable the VCS in the Alioth interface. Ok, but this could also explain why I had a problem with the UNIX group, we could end up with inconsistencies in our group memberships as new members get added. Maybe we can ask the alioth admins to let us substitute the SCM git page with some link to our directory of packages? Also, I prefer to use collab-maint and only use this team at Alioth for our mailinglist. The reason for that is to make it easiest possible for DDs to contribute (because all DDs are by default member of collab-maint). I find that easing access for DDs outweigh making it easiest possible for non-DDs to contribute (they need to first become member of our team and then ask for additional membership of collab-maint). I have heard rumors that it should be possible to ask the Alioth admins to mark our SCM area as automatically including all DDs just as the collab-maint does, but I have not checked if that is indeed possible. Let's have a look, I have two accounts: my guest account is in collab-maint (like many guest accounts): pocock@vasks:/git/collab-maint$ id dpocock-guest ... 40755(collab-maint) ... and my DD account is not in collab-maint but gains write access indirectly: pocock@vasks:/git/collab-maint$ id It may be that we want pkg-javascript owned by one of the other groups, e.g. scm_Debian I'd actually be in favor of giving much wider access though, if only we could limit certain high-risk activities (like git push --force) to pkg-* admins The more significant motivation for using pkg-javascript/*.git is just the logical organisation of the packages rather than security Do anyone in this team object to grant access to all DDs to our SCM? If not, do someone volunteer to figure out if it is possible? Furthermore, when I was added to the group, I notice alioth didn't automatically add me to the UNIX group scm_pkg-javascript - maybe this is because the SCM tool wasn't enabled at the time I was added. Anyhow, I've raised a ticket for the alioth support group to check my permissions. Maybe just a matter of time. Some ACL-related stuff is applied by CRON jobs. Ok, I'll check again tomorrow The package is uploaded now: http://anonscm.debian.org/gitweb/?p=collab-maint/sipml5.git I've just been making some test calls between wheezy and squeeze (both running Chrome 25) against my patched repro SIP proxy Just install the package and visit http://localhost/sipml5-web-phone ___ 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] packaging JsSIP - npm, grunt, etc
I've had a look at JsSIP:
https://github.com/versatica/JsSIP
In particular, it is built using a tool called grunt, and that requires
nodejs and the npm tool
It also pulls in some other dependencies:
https://github.com/opentelecoms-org/JsSIP/blob/master/package.json#L23
devDependencies: {
grunt: 0.3.17,
pegjs: 0.7.0,
node-minify: ~0.7.2
},
I'm just wondering what is the approach here:
a) should I iteratively create packages for everything in this hierarchy?
b) or do I just package the release artifact distributed from upstream?
http://jssip.net/download/
___
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] packaging JsSIP - npm, grunt, etc
On 24/02/2013 00:19, Daniel Pocock wrote:
I've had a look at JsSIP:
https://github.com/versatica/JsSIP
In particular, it is built using a tool called grunt, and that requires
nodejs and the npm tool
It also pulls in some other dependencies:
https://github.com/opentelecoms-org/JsSIP/blob/master/package.json#L23
devDependencies: {
grunt: 0.3.17,
pegjs: 0.7.0,
node-minify: ~0.7.2
},
I'm just wondering what is the approach here:
a) should I iteratively create packages for everything in this hierarchy?
That's the idea, unless, since you are talking about build-deps,
you can figure a simpler build script that does not use grunt.
Note that node-minify is (a wrapper around) uglifyjs.
You might have to package only pegjs and its dependencies.
If grunt is unavoidable, please contact Marcelo at [0].
Jérémy.
[0]
http://lists.alioth.debian.org/pipermail/pkg-javascript-devel/2013-February/004850.html
___
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
