Re: jQuery dependency for Trac 0.11 should be < 1.3
On Sat, Dec 26, 2009 at 6:01 PM, W. Martin Borgert wrote: > >> I don't feel like I >> want to check if they are compatible next time I'd like to use one. >> 15kBytes doesn't worth wasted hours. > > The issue is not 15 kB, but the problems Debian would have if an > error must be fixed in jQuery (e.g. a security problem). Currently, > around 58 packages depend on jQuery. In theory, each of them must > have their own copy. 1. Trac is not a package - it's an application. If there will be a problem in one of the files that shipped with Trac sources - it is a Trac bug. If in case of globally installed packages dependency analysis is a good (must) thing, then for standalone application autopsies contribute nothing to the quality of Debian releases. I would say quite contrary. In Python world there is a very nice thing called Virtualenv that was invented for Python Applications because global packages create stability mess. 2. Thing to consider. When you create Environment and "deploy" it with trac-admin (to generate fastcgi/mod_wsgi scripts) - copies of static resources for web-server, including JavaScript won't be updated when you fix your security package. Right now nobody handles this, but only trac-admin "upgrade" could potentially heal it given it will be able to detect old and new jQuery version in user Environment. > Trac does not even depend on jQuery, but only > recommends it, because Trac itself does not need jQuery. Martin, you are wrong. http://trac.edgewall.org/wiki/TracDev/ApiChanges/0.11#NewDependencies http://trac.edgewall.org/wiki/TracDev/JavaScript#jQuery >> The best solution would be to remove "15_remove_jquery_file.dpatch", > > If it is really important to have jQuery 1.2 around, the best way > would be to ask for a libjs-jquery-1.2 package and let Trac > recommend this package instead of libjs-jquery. Does that mean people won't be able to install Trac 0.12 on Lenny? Consider that when people jump from Trac 0.10 to 0.11 they usually create two instances of Trac before switch and new one usually should be run on the same server. That was true for trac-hacks.org (there virtualenv was used) and that is true with me too, except that I am constrained to use Debian packages and therefore used two Debian servers. Admins would really appreciate an ability to have two Trac major versions on the same server. > Anatoly, please file an ITP or RFP bug against the WNPP[1] > pseudo-package about libjs-jquery-1.2, OK? Set the maintainer of > libjs-jquery in Cc, maybe they will package 1.2 as well. I will > change the dependencies in Trac etc. as soon as the package is in. I fixed it with "aptitude install libjs-jquery=1.2.6" and it works for me. It may be useful for jQuery itself, but for Trac I still do not think it is appropriate to mess with Trac innards if Trac team don't list something as installation prerequisites. In any case the final decision is from maintainers. P.S. There is another reason why I won't fill ITP against libjs-jquery. Sorry for the ignorance, but I still didn't read Debian Bible and ITP, RFP, WNPP and the whole bug-entering process is too way complicated to squeeze into my head at once. It is that it is not as intuitive as web form or something - just have to do some things with Trac and a lot of new stuff to read. Anyways. Thanks for support. -- anatoly t. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: jQuery dependency for Trac 0.11 should be < 1.3
On Sat, Dec 26, 2009 at 2:08 PM, Paul Wise wrote: > >> Upstream Trac is shipped with jQuery it needs while leaving Genshi and >> other libraries as dependencies. Debian specific patch removes jQuery >> from Trac distribution even though it contributes only 2% to package >> size. This dependency injection creates aforementioned problems. > > The dependency exists whether or not trac has "Depends: libjs-jquery". This dependency is hidden, encapsulated inside of Trac application. If you see jquery.js file inside of its source package - why not to leave it alone - where is the Policy that requires to replace it with some external copy? Does Policy take priority over common sense if the change may affect application stability? The maintenance work in this case creates more problems than benefits and may be not as appreciated. Coming back to Earth - what security holes are expected from jQuery? What make people think that Trac developers won't release a new version when such important security problem arise? Basically everything you need is to track that Trac includes some version of jQuery to respond to security issues. Possible response could be in creating a patch to include different jQuery version until upstream does the same, but this should be decided on case-by-case basis. You insist on using Debian Package System to pull parts of application automatically, and that requires manually dissecting application into pieces and analyzing dependencies. That's because there is probably no Security Scanner able to detect affected libraries in shipped applications and create security issues automatically. What's the value of Debian then if it takes security over stability with no option to weigh one over other on a discretion of maintainer of dependent package? > Removing the "Depends: libjs-jquery" sounds like the equivalent of > shipping a copy of GTK+ with gnome-terminal. Or a copy of ncurses with > top. Or a copy of glibc with ls or cp. It may sound like if you forget about size ratios of jQuery/Trac=2% and GTK+/gnome-terminal=757% > None of those things are > nessecary, so why should shipping a copy of jQuery with one of the > packages that use it be any different? It is not necessary to do the extra job of removing jQuery liver from the Trac body at all. The only advantage I see are security patches. Anything else? So far the potential security threat from jQuery shipped inside Trac package doesn't worth the time for implementing measures to maintain external dependencies, potential compatibility issues and restriction for having a 1.3.x jQuery on a system with 0.11 Trac. Seems like I finally made my point clear this time. :P >> There are more than 200 plugins tagged for 0.11 on >> http://trac-hacks.org/ They were developed and debugged with jQuery >> 1.2.x which is not forward compatible with 1.3.x I don't feel like I >> want to check if they are compatible next time I'd like to use one. >> 15kBytes doesn't worth wasted hours. > > It sounds like you're installing the trac plugins manually rather from > Debian packages. I'd suggest manually installing jquery 1.2 for the > manually installed plugins that need it and putting the javascript > file at a different URL to the Debian jQuery 1.3 version. If there are > any trac plugins in Debian sid/squeeze that need jQuery 1.2, I'd > suggest filing RC bugs. The problem that Trac is a web application and during web page rendering plugins load and share all available JS code. When JS behaves wrong - it is also not easy to spot. You don't get coredumps or stacktraces or compilation errors. Your DHTML window may not popup as expected, syntax hints may not be displayed, subscription link won't be inserted where it should or hidden form field won't be updated. In most cases you notice a change unless you're a developer of a plugin and won't catch the error unless your users always browse internet with opened JavaScript console. Google Web Toolkit was invented not as some fancy tool for Java guys who want to switch to ajax - it makes even experienced web front end designers skillful in DHTML/JavaScript learn Java. Things in JavaScript are already fragile enough, let's not make them worse. Bugs from broken JS (and there is a lot of JS in 0.12) will be submitted by users to Trac in 95% of cases - not to Debian. Trac developers will be very happy to track bugs down to a wrong jQuery version that by their assumption should correspond to a Trac release. Well, it may sound a little exaggerated, but writing this is nothing compared to the time it took to fix all problems in my Debian Trac installation over sluggish SSH. There is nothing else to add. -- anatoly t. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Unit tests
On Sat, Dec 26, 2009 at 10:17 PM, Ben Finney wrote: > >> Quoting "anatoly techtonik" : >> > Even if most users don't need them, tests greatly increase the value >> > of bugreports and doesn't bloat python packages too much. >> >> True. What do other people think of the issue? > > I think the judgement of “not bloat the package too much” is to be made > with consideration of those users striving for a small system as their > primary concern, e.g. those trying to install onto embedded systems with > minimal storage. Are there any such people here? Do they prefer different package repository with stripped down binary packages like http://wiki.debian.org/Embedded_Debian ? > Also, the dependencies of a package that includes unit tests are > generally greater; a significant amount of Python package unit test > suites require additional packages, e.g. ‘python-nose’, that are not > dependencies for the normal operation of the package. Need more precise statistics. In my opinion 80% use standard unittest and doctest, especially small packages or modules. If there are dependencies like 'python-nose' - they would be optional anyway. -- anatoly t. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: jQuery dependency for Trac 0.11 should be < 1.3
Quoting "anatoly techtonik" : If you see jquery.js file inside of its source package - why not to leave it alone - where is the Policy that requires to replace it with some external copy? In general, Debian puts a lot of work into finding and removing embedded code copies. Sometimes, this is not possible, e.g. if upstream makes incompatible changes. The maintenance work in this case creates more problems than benefits and may be not as appreciated. It would be helpful, if you could state the exact problems you had because of the newer jQuery. What make people think that Trac developers won't release a new version when such important security problem arise? Currently, 58 packages in Debian depends on jQuery. It makes huge difference, if Debian has to update one package or 58. It is not necessary to do the extra job of removing jQuery liver from the Trac body at all. The only advantage I see are security patches. Anything else? Security is only an example. Any kind of error is relevant. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: jQuery dependency for Trac 0.11 should be < 1.3
Quoting "anatoly techtonik" : 1. Trac is not a package - it's an application. Inside of Debian, applications, libraries, and many other things come as "package" as we call it. In Debian, trac is a package. If there will be a problem in one of the files that shipped with Trac sources - it is a Trac bug. And maybe 58 other Debian packages would be affected in the case of jQuery. If in case of globally installed packages dependency analysis is a good (must) thing, then for standalone application autopsies contribute nothing to the quality of Debian releases. I would say quite contrary. In Python world there is a very nice thing called Virtualenv that was invented for Python Applications because global packages create stability mess. His reminds me of an operating systems, I had to use sometimes, where every application came with their local copy of libraries etc. To me it sounds, like you prefer a manuall Trac installation from source, and Debian does not prevent this. Using the packaged version of Trac is an offer, not more. 2. Thing to consider. When you create Environment and "deploy" it with trac-admin (to generate fastcgi/mod_wsgi scripts) - copies of static resources for web-server, including JavaScript won't be updated when you fix your security package. Right now nobody handles this, but only trac-admin "upgrade" could potentially heal it given it will be able to detect old and new jQuery version in user Environment. Trac works fine without having such copies. I really would not recommend this style of installation. Exactly for the reasons you mentioned. I use symlinks and shared directories. Martin, you are wrong. http://trac.edgewall.org/wiki/TracDev/ApiChanges/0.11#NewDependencies http://trac.edgewall.org/wiki/TracDev/JavaScript#jQuery But trac works perfectly well with any kind of JavaScript. (I have JavaScript disabled for anything, but some sites.) Does that mean people won't be able to install Trac 0.12 on Lenny? No. It would mean that two libjs-jquery packages would exist in parallel, one with the latest 1.2, the other with the latest 1.3 version and that Trac 0.11 could use one, 0.12 the other. Consider that when people jump from Trac 0.10 to 0.11 they usually create two instances of Trac before switch and new one usually should be run on the same server. That was true for trac-hacks.org (there virtualenv was used) and that is true with me too, except that I am constrained to use Debian packages and therefore used two Debian servers. Admins would really appreciate an ability to have two Trac major versions on the same server. Yes. I fear, we don't have the human power to maintain both 0.11 and 0.12 in parallel in Debian. OTOH, it would be cool to have 0.12 in the next Debian release, but of course we can't drop 0.11 at the moment, as too many people use it. I fixed it with "aptitude install libjs-jquery=1.2.6" and it works for me. This works, because you have the old jQuery version in one of your deb repositories. For most users this will not work with the next Debian release. Which plugin(s) exactly did not work with libjs-jquery >= 1.3? Do you have any further information what the problem is/was? Sorry for the ignorance, but I still didn't read Debian Bible and ITP, RFP, WNPP and the whole bug-entering process is too way complicated to squeeze into my head at once. I very well understand this! When/if it becomes clear to me, that a libjs-jquery-1.2 package makes sense, I will file the report. Today we will have 30°C, so I will postpone this a little bit :~) -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: jQuery dependency for Trac 0.11 should be < 1.3
anatoly techtonik wrote: > Upstream Trac is shipped with jQuery it needs while leaving Genshi and > other libraries as dependencies. Debian specific patch removes jQuery > from Trac distribution even though it contributes only 2% to package > size. It's not about package size, it's about security issues and package sanity. > This dependency injection creates aforementioned problems. Fix them, but don't reintroduce the embedded code copy. Cheers, Emilio -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: jQuery dependency for Trac 0.11 should be < 1.3
On Sun, Dec 27, 2009 at 6:24 PM, W. Martin Borgert wrote: > > It would be helpful, if you could state the exact problems you > had because of the newer jQuery. Not 100% sure it was only jQuery (can't test this right now) but, for example, I could not drill down beneath the first level in template debugger of TracDeveloper plugin. >> It is not necessary to do the extra job of removing jQuery liver from >> the Trac body at all. The only advantage I see are security patches. >> Anything else? > > Security is only an example. Any kind of error is relevant. Then why can't you wait until upstream developers, whose product bundles that library, confirm, validate, test and release fix for that error in their source package together with release announcement? Also in the case of Trac/jQuery. -- anatoly t. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: jQuery dependency for Trac 0.11 should be < 1.3
On Sun, Dec 27, 2009 at 6:56 PM, W. Martin Borgert wrote: > >> 2. Thing to consider. When you create Environment and "deploy" it with >> trac-admin (to generate fastcgi/mod_wsgi scripts) - copies of static >> resources for web-server, including JavaScript won't be updated when >> you fix your security package. Right now nobody handles this, but only >> trac-admin "upgrade" could potentially heal it given it will be able >> to detect old and new jQuery version in user Environment. > > Trac works fine without having such copies. I really would > not recommend this style of installation. Exactly for the > reasons you mentioned. I use symlinks and shared directories. Is it possible to create symlink on a symlink? (I am on windows right now - can't test) >> Martin, you are wrong. >> http://trac.edgewall.org/wiki/TracDev/ApiChanges/0.11#NewDependencies >> http://trac.edgewall.org/wiki/TracDev/JavaScript#jQuery > > But trac works perfectly well with any kind of JavaScript. > (I have JavaScript disabled for anything, but some sites.) That's true. Trac was designed to work even without JavaScript, but Trac plugins are written by community and people often assume that jQuery is available. >> Does that mean people won't be able to install Trac 0.12 on Lenny? > > No. It would mean that two libjs-jquery packages would exist in > parallel, one with the latest 1.2, the other with the latest > 1.3 version and that Trac 0.11 could use one, 0.12 the other. That makes sense, but they could not at the moment if I understand correctly? It will require splitting libjs-jquery into libjs-jquery12 and libjs-jquery13 - is that right? > Yes. I fear, we don't have the human power to maintain both > 0.11 and 0.12 in parallel in Debian. OTOH, it would be cool > to have 0.12 in the next Debian release, but of course we > can't drop 0.11 at the moment, as too many people use it. Is that only human power problem? Where the most time will be spent if we play this scenario? > Which plugin(s) exactly did not work with libjs-jquery >= 1.3? > Do you have any further information what the problem is/was? At first it was AccountManager, then I ended up with the necessity of installing TracDeveloper, wasted some time patching Trac code to find the source of the problem. Found that TracDeveloper uses wrong version of jQuery, fixed Apache configuration, restored jQuery, reenabled AccountManager, made modifications to my own plugs. Now I still have AccountManager named "urwid" in Trac Admin panel, but I do not even want to repeat this awful SSH experience. > > Today we will have 30°C, so I will postpone this a little bit :~) > You are lucky. It is a few degrees above the zero, the snow is melting, snowboard is slowly covering with rust, Santa was trapped in mud and stole my sock to change one of his own. Everything is just plain wrong. -- anatoly t. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: jQuery dependency for Trac 0.11 should be < 1.3
On Sun, 2009-27-12 at 22:13 +0200, anatoly techtonik wrote: > Is it possible to create symlink on a symlink? yes > (I am on windows right now - can't test) -- --gh -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: jQuery dependency for Trac 0.11 should be < 1.3
Quoting "anatoly techtonik" : Then why can't you wait until upstream developers, whose product bundles that library, confirm, validate, test and release fix for that error in their source package together with release announcement? Also in the case of Trac/jQuery. Again, many applications have many libraries and tools as embedded code copies. jQuery alone is used by 58 Debian packages. As I'm already repeating myself I'll stop now arguing about the issue. Btw. inside of Debian nor Ubuntu I'm not aware of other opinions in this matter. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: jQuery dependency for Trac 0.11 should be < 1.3
Quoting "anatoly techtonik" : Is it possible to create symlink on a symlink? (I am on windows right now - can't test) Yes. That's true. Trac was designed to work even without JavaScript, but Trac plugins are written by community and people often assume that jQuery is available. That's why the Debian Trac package recommends jQuery. In the default case, it is installed automatically, but you can explicitly say "no", if you want to. That makes sense, but they could not at the moment if I understand correctly? It will require splitting libjs-jquery into libjs-jquery12 and libjs-jquery13 - is that right? Yes, exactly. Now I still have AccountManager named "urwid" in Trac Admin panel, but I do not even want to repeat this awful SSH experience. I have the same problem (wrong Python package names as names of Trac plugins in the admin panel) sometimes, but I don't know what the cause is. Any idea? (But I don't think, it's in any way related to JavaScript nor jQuery...) -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: jQuery dependency for Trac 0.11 should be < 1.3
On Mon, Dec 28, 2009 at 3:29 AM, W. Martin Borgert wrote: > Quoting "anatoly techtonik" : >> >> Then why can't you wait until upstream developers, whose product >> bundles that library, confirm, validate, test and release fix for that >> error in their source package together with release announcement? Also >> in the case of Trac/jQuery. > > Again, many applications have many libraries and tools as embedded > code copies. jQuery alone is used by 58 Debian packages. As I'm > already repeating myself I'll stop now arguing about the issue. > Btw. inside of Debian nor Ubuntu I'm not aware of other opinions > in this matter. But we are not maintaining those 58 packages! When I be designing my own cloud OS I'll make sure to give a special attention to this case. So that when new security fix for enclosed/used library is released, package maintainers receive a warning first. >> Is it possible to create symlink on a symlink? >> (I am on windows right now - can't test) > > Yes. Then we should also patch "trac-admin deploy" command so that it create symlinks to static resources instead of copies to update user environments to latest jQuery automaically. >> That's true. Trac was designed to work even without JavaScript, but >> Trac plugins are written by community and people often assume that >> jQuery is available. > > That's why the Debian Trac package recommends jQuery. In the > default case, it is installed automatically, but you can > explicitly say "no", if you want to. So, if a package is listed in "Recommends:" section it is installed automatically by command line "aptitude install trac"? Didn't know that. -- anatoly t. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Trac wrong plugin names.
On Mon, Dec 28, 2009 at 3:34 AM, W. Martin Borgert wrote: > >> Now I still have >> AccountManager named "urwid" in Trac Admin panel, but I do not even >> want to repeat this awful SSH experience. > > I have the same problem (wrong Python package names as names of > Trac plugins in the admin panel) sometimes, but I don't know what > the cause is. Any idea? (But I don't think, it's in any way > related to JavaScript nor jQuery...) Finally decided to change topic as this time it has nothing to do with jQuery. It's probably a conflict between setuptools and Debian packaging (i.e. setuptools vs python-central), because manually installed plugins from my environment are ok. What about switching to python-support and see if it solves the problem? -- anatoly t. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
