jquery_1.7.2+debian-2_i386.changes uploaded successfully to localhost
along with the files:
jquery_1.7.2+debian-2.dsc
jquery_1.7.2+debian-2.debian.tar.gz
libjs-jquery_1.7.2+debian-2_all.deb
Greetings,
Your Debian queue daemon (running on host franck.debian.org)
Accepted:
jquery_1.7.2+debian-2.debian.tar.gz
to main/j/jquery/jquery_1.7.2+debian-2.debian.tar.gz
jquery_1.7.2+debian-2.dsc
to main/j/jquery/jquery_1.7.2+debian-2.dsc
libjs-jquery_1.7.2+debian-2_all.deb
to main/j/jquery/libjs-jquery_1.7.2+debian-2_all.deb
Changes:
jquery
Hi Andres,
On 12-06-14 at 10:37am, Andres Rodriguez wrote:
So, in order [for Ubuntu] to not differ with Debian, we were wondering
a few things:
1. Would it make sense to include versions in the installation paths?
(i.e. /usr/share/javascript/yui/2.8.2/*.js ,
Your message dated Thu, 14 Jun 2012 16:02:30 +
with message-id e1sfcvc-00010k...@franck.debian.org
and subject line Bug#676838: fixed in jquery 1.7.2+debian-2
has caused the Debian Bug report #676838,
regarding libjs-jquery package should be marked Multi-Arch: foreign
to be marked as done.
On 12-06-14 at 05:40pm, Pau Garcia i Quiles wrote:
We should just treat JavaScript libraries exactly the same way we
treat C/C++ libraries, with soversions and all. That makes multiple
runtime versions co-installable and co-dependable, which would solve
the problem.
How to resolve the
HI All,
Thanks for the comments and suggestions.
How to resolve the SO-name for JavaScript?
By full path. I. e. instead of:
/usr/share/javascript/jquery/jquery.js
let's have:
/usr/share/javascript/jquery/1.7.2/jquery.js
I agree with this as is the same as I was thinking.
Then the
On Thu, Jun 14, 2012 at 6:55 PM, Andres Rodriguez andres...@ubuntu.com wrote:
How to resolve the SO-name for JavaScript?
By full path. I. e. instead of:
/usr/share/javascript/jquery/jquery.js
let's have:
/usr/share/javascript/jquery/1.7.2/jquery.js
I agree with this as is the same as
It would be more like jquery-1.7.2 ships libjs-jquery56, i. e. there
is no relation at all between the soname version and the library
version. If jQuery 1.7.3, 1.7.4, 1.8, etc remain API- and behavior-
compatible with 1.7.2, then jquery-1.7.3, jquery-1.7.4, etc would
still provide
Processing commands for cont...@bugs.debian.org:
#libv8 (3.10.8.16-1) UNRELEASED; urgency=low
#
# * debian/rules:
#+ extract the soname version from upstream version.
#+ enable mipsel architecture.
#+ force mips3 (Loongson) support.
#+ set test timeout to 400 seconds for
On 08/06/2012 12:33, Jonas Smedegaard wrote:
On 12-06-08 at 11:52am, Jérémy Lal wrote:
Hi,
it's now clearer [1] to me how upstream v8 release their library :
1 - They start a new branch, say 3.10
2 - the first minor versions can break API (3.10.2, 3.10.4, 3.10.6)
3 - at some point they only
Hi,
Thanks for committing the kFreeBSD patches.
I hope this isn't too late, but I just tested building 3.10.8.16-1 from
git on kfreebsd-i386, and it failed due to a -Wunused-but-set-variable
that I didn't notice before in some FreeBSD-specific code.
Attached is another patch to fix this and
tags 670836 = patch
thanks
On 15/06/12 01:41, Steven Chamberlain wrote:
[...] failed due to a -Wunused-but-set-variable
that I didn't notice before in some FreeBSD-specific code.
Ah, now I see why; that compiler option just got re-enabled.
I notice that a fix for this was added to
12 matches
Mail list logo
