+
+ * Reorder JSON regexp class to unbreak on Opera 9 (Closes: #647596)
+
+ -- Thorsten Glaser Fri, 04 Nov 2011 12:15:39 +0100
+
prototypejs (1.7.0-2) unstable; urgency=low
* push package to unstable
only in patch2:
unchanged:
--- prototypejs-1.7.0.orig/prototype-1.7.0.js
+++ prototypejs
Source: jquery
Version: 1.7.2-1
Severity: serious
Justification: violates source requirement
Hi,
the jquery distfile (jquery_1.7.2.orig.tar.gz) does not contain
complete source code required for regenerating the dist/jquery.js
file as shipped. Indeed, it only contains a part of the main git
check
Hi,
can *please* be something done about this, so we can ship
a version of mediawiki-extensions that actually matches
the version on mediawiki shipped in wheezy?
What, exactly, needs to be done in/for json-js? Can I help?
I’ve got Super Co^W^WDebian Developer Upload Powers.
AFAICS, uglifyjs shou
On Tue, 10 Jul 2012, Jonas Smedegaard wrote:
> Right now I am waiting for the judgement of the tech-ctte regarding
> nodejs. See bug#614907.
Ah. Luckily, that’s almost resolved.
> I am concerned about switching compressor - see the discussion at
> bug#679665.
I see. (But yui was used before,
On Tue, 10 Jul 2012, Jonas Smedegaard wrote:
> Because it performs worse, which makes it less used in general, which
> makes it less tested, which makes it less trustworthy. I thought that
> was already clarified at bug#679665. Does it make sense now?
Thanks, yes.
> It is helpful that you in
On Tue, 10 Jul 2012, Platonides wrote:
> How does json-js block mediawiki-extensions?
One of the extensions depends on that package.
> a) MediaWiki ships with a copy of jQuery since 1.17
Ah, good to know, we’ll need to remove that.
> b) MediaWiki resourceloader will automatically minify the ja
On Thu, 13 Sep 2012, Flavio Bello Fialho wrote:
> I imagine that mediawiki 1:1.19.1-1 is
> incompatible with libjs-jquery-tablesorter 6-1, although one depends on the
> other. I suggest removing the dependency and using the upstream mediawiki file
> instead of the symlink.
That would violate Poli
On Thu, 13 Sep 2012, Flavio Bello Fialho wrote:
> Based on the file header, it seems mediawiki uses a fork of tablesorter or is
> a modified version of it, specifically for use with mediawiki.
I see. In this case, the Policy part I had in mind does
not apply, and it’s correct to use the version s
Hi,
I’ve got a FusionForge derivate properly packaged as Debian
source package, and would like to keep that. (It’s used inhouse
but publicly available.) Now, we are “restyling” it using the
“Bootstrap” CSS/JS stuff, whose version 3.1 will use the MIT
licence (instead of Apache v2) and thus be lice
On Wed, 20 Nov 2013, Jérémy Lal wrote:
> You can figure out easily what exactly is needed to "compile"
> bootstrap in the devDependencies field of:
> https://github.com/twbs/bootstrap/blob/master/package.json
Hm, okay. I’m not familiar with all those things, which is
why I thought to ask the main
Package: node-abbrev
Version: 1.0.5-1
Severity: important
I was just wondering about the ITPs on d-devel, and whether those
packages should not be called nodejs-* instead of node-*, and was
seeing this package in the list first.
Both its short description and its long description are utterly
ridi
On Fri, 28 Nov 2014, Thomas Goirand wrote:
> It's been a long time I've been thinking about it, and I believe that
> the only way to do this, would be to use triggers. Though I have never
Look at libjs-protoaculous which combines prototype and
scriptaculous into one (possibly minified) js file. I
On Sat, 29 Nov 2014, Thomas Goirand wrote:
> 2/ in debian/openstack-dashboard.postinst, implement something like:
>
> if [ "$1" = "triggered" ] ; then
> /usr/share/openstack-dashboard/manage.py compress --force
> fi
>
> Is it *that* simple?
No, triggers unfortunately are not that simple:
On Fri, 28 Nov 2014, Jonas Smedegaard wrote:
> Just looking at the package name that seems not an ideal aproach: Should
> we then make packages for each combination of libraries to be merged
> together, or am I missing a more clever logic? Or do you perhaps point
No, protoaculous is a special
Package: nodejs
Version: 4.4.3~dfsg-1
Severity: normal
On a mixed-architecture system (such as x32 and i386),
nodejs can be installed from i386 even when the main
architecture is x32. However, due to a missing annotation
as Multi-Arch: foreign, rdeps like node-uglify cannot be
installed.
Please a
Jonas Smedegaard dixit:
>Uhm, wouldn't it make more sense to instead file bugreports against
>stuff like node-iglify, to get _more_ of Debian multiarch'ified?
node-uglify is arch:all, therefore there’s nothing to be done
for this package.
I even edited /var/lib/dpkg/status with sudo, to add the
On Sun, 19 Jun 2016, Jérémy Lal wrote:
> After further reading, i think (but i'm still quite confused about
> multiarch)
(who isn’t…)
> there might be some complication with the fact node c++ addons are
> linked against the binary /usr/bin/nodejs.
>
> (This situation will improve with the abilit
Package: node-uglify
Version: 2.4.15-1
Severity: important
This is in a clean jessie chroot (cowbuilder):
(pbuild17583)root@tglase:/# uglifyjs --version
module.js:340
throw err;
^
Error: Cannot find module '../package.json'
at Function.Module._resolveFilename (module.js:338:15
Debian Bug Tracking System dixit:
>This issue was however already reported as bug#784439.
Ah, indeed. It still affects stable, however.
Given that it looks like a one-line fix it might be considered?
Thanks,
//mirabilos
--
exceptions: a truly awful implementation of quite a nice idea.
just ab
retitle 847643 node-uglify: neither manpage nor --help output useful
# Policy 12.1
severity 847643 serious
found 847643 2.8.29-1
thanks
I think this should be addressed ASAP:
tglase@tglase:~ $ dpkg -l node-uglify
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF
Hi,
> * Restore /usr/bin/node following CTTE #862051
> Let's try to drop /usr/bin/nodejs before buster.
> Replaces and Conflicts nodejs-legacy.
> Closes: #754462.
please do NOT completely replace an ABI between releases.
Leave /usr/bin/nodejs there for at least one more release.
Th
On Tue, 29 Aug 2017, Didier 'OdyX' Raboud wrote:
> I'm quite convinced that large parts of the Node.js ecosystem will cope well
> without any /usr/bin/nodejs available in stretch.
>
> So I'm not convinced it's really worth the trouble to keep it around for
> another stable release; I'd probably
On Thu, 31 Aug 2017, Jérémy Lal wrote:
> How about printing a "nice" warning explaining it would be a good idea to
> move to /usr/bin/node ?
That will break scripts that do:
x=$(nodejs somescript)
Or even ./somescript when that has a #!/usr/bin/env nodejs shebang.
> Then in next next release d
On Thu, 31 Aug 2017, Julien Puydt wrote:
> May I suggest to have /usr/bin/nodejs print a nice deprecation warning
> to use /usr/bin/node, and just *never* remove it?
On Thu, 31 Aug 2017, Didier 'OdyX' Raboud wrote:
> Le jeudi, 31 août 2017, 13.52:00 h CEST Jérémy Lal a écrit :
> > How about pri
Package: node-uglify
Version: 2.8.29-3
Severity: minor
tglase@tglase-nb:~ $ uglifyjs --version
2.8.29
This is after an upgrade. Before, it output:
uglify-js 2.8.29
There was apparently no change to the node-uglify package itself,
only to some *other* nodejs packages.
Ple
25 matches
Mail list logo
