Re: F20 System Wide Change: Web Assets
On Wed, Aug 21, 2013 at 9:35 AM, Behdad Esfahbod beh...@behdad.org wrote: Where's the code? The github link seems to be broken. Sorry for the delay on that. The code is now here: https://github.com/tchollingsworth/ttname And it's already in Rawhide, F20, and F18-19 updates-testing. See the announcement here for more details: https://lists.fedoraproject.org/pipermail/fonts/2013-August/001621.html -T.C. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F20 System Wide Change: Web Assets
Le Dim 4 août 2013 10:44, Till Maas a écrit : On Tue, Jul 23, 2013 at 07:54:38PM +0200, Nicolas Mailhot wrote: Le Mar 23 juillet 2013 19:26, T.C. Hollingsworth a écrit : AFAICS it shouldn't be too hard to script up something so this would as easy as `fixfontmd --copyright $(head -n3 LICENSE) --licensedesc $(cat LICENSE) --licenseurl http://example.com/LICENSE` for packagers. I'd be happy to add a guideline for this and fix up existing packages if this seems amenable. If you can write a tool that makes it easy to fix opentype licensing fields at build time, I'll be delighted to support any guideline change that mandated its use. However if you go in this direction please check on the fonts and openfontlibrary list knowledgeable people agree there are no wrong side-effect (this will reach debian font packagers at least BTW) The guideline should be to ask upstream to fix the meta data. In case of missing license text (e.g. source code with a GPL header but no copy of the GPL itself), it is also upstream's task to fix it and the packager's to ask for it. And if upstream fixes it, the debian font packagers do not need to replicate Fedora's effort. This is already the guideline, the problem is what do you do when upstream postpones fixing to indefinitely later because licensing stuff is low-prio for them -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F20 System Wide Change: Web Assets
Le Mar 6 août 2013 23:48, T.C. Hollingsworth a écrit : There's already some example instructions on how to use ttname here, which accurately reflects the CLI interface as it is now implemented: https://fedoraproject.org/wiki/User:Patches/ttname also please keep the fonts list in CC when discussing changes to fonts packaging in Fedora Thank's for working on this! -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F20 System Wide Change: Web Assets
On Wed, Aug 21, 2013 at 04:52:53PM +0200, Nicolas Mailhot wrote: Le Dim 4 août 2013 10:44, Till Maas a écrit : The guideline should be to ask upstream to fix the meta data. In case of missing license text (e.g. source code with a GPL header but no copy of the GPL itself), it is also upstream's task to fix it and the packager's to ask for it. And if upstream fixes it, the debian font packagers do not need to replicate Fedora's effort. This is already the guideline, the problem is what do you do when upstream postpones fixing to indefinitely later because licensing stuff is low-prio for them If upstream does not see an urgent problem in it, why should we? We do the same with license copies in packages. Also it would be upstream that might have a problem with the license information, since they provided the fonts like they are and allow distribution, I cannot see a problem. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F20 System Wide Change: Web Assets
On Sat, Aug 10, 2013 at 11:34 PM, Ken Dreyer ktdre...@ktdreyer.com wrote: On Fri, Aug 9, 2013 at 5:23 PM, T.C. Hollingsworth tchollingswo...@gmail.com wrote: Debian already uses /usr/share/javascript for this purpose, and it would be really nice if we both could coordinate on getting some upstream support for this in certain cases. I'm very strongly -1 against pointless Fedoraisms here. Speaking of Fedoraisms, could we please serve Javascripts through /javascripts ? Debian already has a long precedent of doing this. I'm concerned that if Fedora invents _sysassets, we're setting ourselves up to make the upstream advocacy task that you mentioned much harder. I wasn't aware Debian already exported a directory for this. (But /javascripts, really?) It would be nice if they wrote that into their policy. We still need something for CSS frameworks and such, but maybe we could drop the underscore and have: /sysassets/ - for CSS, theming, etc. /javascripts/ - for JS The httpd maintainer would really prefer if we didn't use something that could potentially conflict as easily as /javascripts though. Not sure if Debian does it is a good enough reason to override that... Speaking as a web app package maintainer, I think this policy has great intentions, and I think there's advantages to following Debian's URL precedent. -T.C. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F20 System Wide Change: Web Assets
On Mon, Aug 12, 2013 at 12:53 PM, Robert Marcano rob...@marcanoonline.com wrote: This is a better explanation of why the use /usr/share/javascript: We want to be compatible with others distribution that have the legacy idea that JavaScript is a browser only thing, so in this directory we will only store JavaScript that run on the browser No, we want to be compatible with the real world where that's where 99% of JS is used. This sounds like you think there aren't JavaScript libraries that aren't tied to an specific runtime, there are So, where do I put the code for a reusable, non web based, or runtime dependent JavaScript library? like [1] or [2], these examples doesn't have Node.js, GNOME Shell, nor GNOME JavaScript applications dependencies, pure and simple JavaScript. I don't see it on the JavaScript Packaging Guidelines. If this is a general JavaScript Packaging Guidelines, it should standardize something for them, if it is JavaScript for browser Packaging Guidelines it should be renamed Just because JS is obstensibly browser-specific doesn't mean it's useless to any of the other runtimes either. jQuery gets used a lot in the node universe too. (You get a server-side implementation of the DOM with node's jsdom package which is very useful in certain situations.) That means the set of JavaScript that is only ever useful for sending to browsers is the empty set, so it's completely pointless to partition off a space for only that. If everything else apply to them, I don't see why a Node.js application or a GNOME Shell extension need to pull a package named web-assets, it is a wrong name, plain and simple, and worse If they don't store anything on /usr/share/javascript because they aren't browser code, why pull them? You only need web-assets-filesystem if you need /usr/share/javascript. Clarified in: https://fedoraproject.org/w/index.php?title=User:Patches/PackagingDrafts/JavaScriptdiff=349388oldid=348671 -T.C. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F20 System Wide Change: Web Assets
On Mon, Aug 12, 2013 at 1:05 PM, Robert Marcano
rob...@marcanoonline.com wrote:
On 08/12/2013 03:23 PM, Robert Marcano wrote:
This is a better explanation of why the use /usr/share/javascript: We
want to be compatible with others distribution that have the legacy idea
that JavaScript is a browser only thing, so in this directory we will
only store JavaScript that run on the browser
Sorry, I missed this:
If a JavaScript library can be executed locally or consists purely of
JavaScript code, it must be installed into a subdirectory of %{_jsdir}.
and the Feature says:
Additionally the following symlinks will be provided:
/usr/share/web-assets/javascript points to /usr/share/javascript
So non browser JavaScript code will be shared via HTTP?, all those pages are
out of sync that it is difficult to understand what will go to each place
So one possible option that would address your concerns would be to
require every js-foo package to also provide a webjs-foo subpackage or
so that just contains a symlink in /usr/share/web-assets/js to the
appropriate location in /usr/share/javascript.
That would provide a way for dependent packages to express hey, I
just need you on the server-side and another way to say hey, I need
you served over HTTP.
But then, what do we want to do about fonts? Adding *-webfonts
subpackages to every font package would be a lot of work, and makes
that awesome WordPress usecase I mentioned much, much harder. What
about CSS? Do we really need a css-bootstrap for when someone wants
to create a locally run HTML5 application with something like
node-webkit and another webcss-bootstrap for when they really want it
served over HTTP?
It's really a lot of work optimizing for what is an edge case. I'm
not convinced it's necessary, but I'll mention this to FPC during my
meeting with them on Thursday for their input anyway.
-T.C.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F20 System Wide Change: Web Assets
On 08/14/2013 07:34 AM, T.C. Hollingsworth wrote:
On Mon, Aug 12, 2013 at 1:05 PM, Robert Marcano
rob...@marcanoonline.com wrote:
On 08/12/2013 03:23 PM, Robert Marcano wrote:
This is a better explanation of why the use /usr/share/javascript: We
want to be compatible with others distribution that have the legacy idea
that JavaScript is a browser only thing, so in this directory we will
only store JavaScript that run on the browser
Sorry, I missed this:
If a JavaScript library can be executed locally or consists purely of
JavaScript code, it must be installed into a subdirectory of %{_jsdir}.
and the Feature says:
Additionally the following symlinks will be provided:
/usr/share/web-assets/javascript points to /usr/share/javascript
So non browser JavaScript code will be shared via HTTP?, all those pages are
out of sync that it is difficult to understand what will go to each place
So one possible option that would address your concerns would be to
require every js-foo package to also provide a webjs-foo subpackage or
so that just contains a symlink in /usr/share/web-assets/js to the
appropriate location in /usr/share/javascript.
Or not sharing js, fonts and other assets from a shared directory? I was
checking an application like Roundcube. Patching it requires change a
few files because web apps have no standard way to use those files, It
is easy to find assets files than locating where it is used and test if
you aren't missing something after you patch it. There is need to update
the patches every time a new version make the patch invalid. or check if
a new file is linking to them
What about replace the files on the application directory (/roundcube)
using the webserver related configuration for that like Alias
Alias /roundcube/path_to_jquery/jquery.min.js
/usr/share/javascript/jquery/jquery.min.js
The list of the files should be generated anyways, the Java guidelines
explicitly say that the packager should remove other bundled software
and upload a modified source package (I think this makes easier to say
an application is GPL and not GPL + Apache + BSD... on the spec license
field), probably web application should do the same
We can add rpm macros to generate roundcube-httpd, roundcube-cherokee,
roundcube-nginx, taking the mapping list and generating the equivalent
of the Alias of Apache for those web servers, a lot of the current
packaged applications have a dependency on Apache, and sometimes there
is no need for that
The spec authors have expressed that they have no intentions of
mandating that the packager must use the shared directory, that they can
import the files to the application namespace, so why not make the later
it the standard way?
That would provide a way for dependent packages to express hey, I
just need you on the server-side and another way to say hey, I need
you served over HTTP.
But then, what do we want to do about fonts? Adding *-webfonts
subpackages to every font package would be a lot of work, and makes
that awesome WordPress usecase I mentioned much, much harder. What
about CSS? Do we really need a css-bootstrap for when someone wants
to create a locally run HTML5 application with something like
node-webkit and another webcss-bootstrap for when they really want it
served over HTTP?
It's really a lot of work optimizing for what is an edge case. I'm
not convinced it's necessary, but I'll mention this to FPC during my
meeting with them on Thursday for their input anyway.
-T.C.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F20 System Wide Change: Web Assets
On Wed, Aug 14, 2013 at 5:23 AM, T.C. Hollingsworth tchollingswo...@gmail.com wrote: I wasn't aware Debian already exported a directory for this. (But /javascripts, really?) It would be nice if they wrote that into their policy. I was slightly wrong: it's /javascript (singular). I couldn't find any formal Debian packaging policy for this, but the alias is set here: http://sources.debian.net/src/javascript-common/latest/javascript-common.conf I wasn't aware Debian already exported a directory for this. (But /javascripts, really?) It would be nice if they wrote that into their policy. Agreed! The httpd maintainer would really prefer if we didn't use something that could potentially conflict as easily as /javascripts though. Not sure if Debian does it is a good enough reason to override that... I just read over http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=553173 , which makes me wonder if this URL is indeed going to cause problems or even change altogether. I've emailed the Debian pkg-javascript-devel list for clarification. http://lists.alioth.debian.org/pipermail/pkg-javascript-devel/2013-August/005888.html - Ken -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F20 System Wide Change: Web Assets
On 08/09/2013 06:53 PM, T.C. Hollingsworth wrote: On Thu, Aug 8, 2013 at 12:22 PM, Robert Marcano rob...@marcanoonline.com wrote: The directory is not called /usr/share/web-javascript, it is called /usr/share/javascript, and the packaging guidelines draft explicitly says that the intention is to avoid duplication of libraries, so it is calling to move all JavaScript reusable code/frameworks/libraries to it, not only browser based JavaScript, and I quote: /usr/lib/python2.7 is not called /usr/lib/cpython2.7, because when most people think Python, they think CPython, since that has been the main implementation of Python for 22 years. Similarly, /usr/share/javascript is not called /usr/share/web-javascript, because when most people think JavaScript, they think browser JavaScript, since that has been the main implementation of JavaScript for 18 years. There are cool other implementations of Python that work differently, like PyPy, which uses /usr/lib/pypy. There are cool other implementations of JavaScript, like Node.js, which uses /usr/lib/node_modules. Being pointlessly pedantic in either of these cases would just confuse users for no benefit. Debian already uses /usr/share/javascript for this purpose, and it would be really nice if we both could coordinate on getting some upstream support for this in certain cases. I'm very strongly -1 against pointless Fedoraisms here. This is a better explanation of why the use /usr/share/javascript: We want to be compatible with others distribution that have the legacy idea that JavaScript is a browser only thing, so in this directory we will only store JavaScript that run on the browser There are also some JavaScript libraries which are intended to be used on the local system, not served via a web server to a browser. These libraries clearly have all the standard reasons to avoid duplication. The preamble before this and the Install Location section afterward clearly states that there is JavaScript on the system that doesn't belong it /usr/share/javascript, like GNOME Shell Extensions and Node.js modules, which live in directories of their own, This sounds like you think there aren't JavaScript libraries that aren't tied to an specific runtime, there are So, where do I put the code for a reusable, non web based, or runtime dependent JavaScript library? like [1] or [2], these examples doesn't have Node.js, GNOME Shell, nor GNOME JavaScript applications dependencies, pure and simple JavaScript. I don't see it on the JavaScript Packaging Guidelines. If this is a general JavaScript Packaging Guidelines, it should standardize something for them, if it is JavaScript for browser Packaging Guidelines it should be renamed but the rest of the guidelines still apply to them. If everything else apply to them, I don't see why a Node.js application or a GNOME Shell extension need to pull a package named web-assets, it is a wrong name, plain and simple, and worse If they don't store anything on /usr/share/javascript because they aren't browser code, why pull them? I don't really need to repeat that in every paragraph, do I? and later it contradict what you say, indicating that they must use BuildRequires: web-assets-devel and Requires: web-assets-filesystem So, it means all JavaScript, even the used on the local system must depend of web-assets web-assets-filesystem contains a handful of directories and symlinks. It does not drag in Apache configuration. web-assets-devel defines a few RPM macros. It also does not drag in Apache configuration. web-assets-httpd contains the Apache configuration. js-foo libraries MUST not depend on it, since they could be used with any HTTP daemon. -T.C. [1] http://crypto.stanford.edu/sjcl/ [2] http://code.google.com/p/crypto-js/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F20 System Wide Change: Web Assets
On 08/12/2013 03:23 PM, Robert Marcano wrote:
This is a better explanation of why the use /usr/share/javascript: We
want to be compatible with others distribution that have the legacy idea
that JavaScript is a browser only thing, so in this directory we will
only store JavaScript that run on the browser
Sorry, I missed this:
If a JavaScript library can be executed locally or consists purely of
JavaScript code, it must be installed into a subdirectory of %{_jsdir}.
and the Feature says:
Additionally the following symlinks will be provided:
/usr/share/web-assets/javascript points to /usr/share/javascript
So non browser JavaScript code will be shared via HTTP?, all those pages
are out of sync that it is difficult to understand what will go to each
place
There are also some JavaScript libraries which are intended to be
used on
the local system, not served via a web server to a browser. These
libraries
clearly have all the standard reasons to avoid duplication.
The preamble before this and the Install Location section afterward
clearly states that there is JavaScript on the system that doesn't
belong it /usr/share/javascript, like GNOME Shell Extensions and
Node.js modules, which live in directories of their own,
This sounds like you think there aren't JavaScript libraries that aren't
tied to an specific runtime, there are
So, where do I put the code for a reusable, non web based, or runtime
dependent JavaScript library? like [1] or [2], these examples doesn't
have Node.js, GNOME Shell, nor GNOME JavaScript applications
dependencies, pure and simple JavaScript. I don't see it on the
JavaScript Packaging Guidelines. If this is a general JavaScript
Packaging Guidelines, it should standardize something for them, if it
is JavaScript for browser Packaging Guidelines it should be renamed
but the rest
of the guidelines still apply to them.
If everything else apply to them, I don't see why a Node.js application
or a GNOME Shell extension need to pull a package named web-assets, it
is a wrong name, plain and simple, and worse If they don't store
anything on /usr/share/javascript because they aren't browser code, why
pull them?
I don't really need to repeat that in every paragraph, do I?
and later it contradict what you say, indicating that they must use
BuildRequires: web-assets-devel and
Requires: web-assets-filesystem
So, it means all JavaScript, even the used on the local system must
depend
of web-assets
web-assets-filesystem contains a handful of directories and symlinks.
It does not drag in Apache configuration.
web-assets-devel defines a few RPM macros. It also does not drag in
Apache configuration.
web-assets-httpd contains the Apache configuration. js-foo libraries
MUST not depend on it, since they could be used with any HTTP daemon.
-T.C.
[1] http://crypto.stanford.edu/sjcl/
[2] http://code.google.com/p/crypto-js/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F20 System Wide Change: Web Assets
On Fri, Aug 9, 2013 at 5:23 PM, T.C. Hollingsworth tchollingswo...@gmail.com wrote: Debian already uses /usr/share/javascript for this purpose, and it would be really nice if we both could coordinate on getting some upstream support for this in certain cases. I'm very strongly -1 against pointless Fedoraisms here. Speaking of Fedoraisms, could we please serve Javascripts through /javascripts ? Debian already has a long precedent of doing this. I'm concerned that if Fedora invents _sysassets, we're setting ourselves up to make the upstream advocacy task that you mentioned much harder. Speaking as a web app package maintainer, I think this policy has great intentions, and I think there's advantages to following Debian's URL precedent. - Ken -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F20 System Wide Change: Web Assets
On Thu, Aug 8, 2013 at 11:45 AM, Robert Marcano rob...@marcanoonline.com wrote: And I don't see a problems with those examples, because they share only their contents, by installing them you don't share content from other packages. Lets make an example of the mess this will create if I want to share a web application to the world and user another one on my intranet. I will call those Internet and Intranet application Internet application requires JavaScript library intranet-library, and the same with intranet-library. Both applications are installed, I as a sysadmin don't want to expose intranet used assets to the general public, so I need to make changes on it's respective apache configuration file in order to explicitly block /usr/share/web-assets/javascript/intranet-library. A new update to intranet application adds a new requirement. new-intranet-library. So I as a sysadmin must be checking every package installed in order to see if it is exposing more things to the public. You can have many reasons for not wanting that, license of those files, avoid people linking to them and use your bandwidth. The shared directory thing makes this easier! Instead of having to track down which application aliases which library in which apache config fragment, you just have one directory to check. (Not to mention you'll plainly see in yum's output when this happens, anyway.) You can also whitelist/blacklist/use a different version of individual libraries centrally, even per VirtualHost, instead of tracking down a million aliases. I am not against creating some order and removing the privilege that JavaScript code and assets currently have of being allowed to be bundled on every package. But sharing /usr/share/fonts and /usr/share/javascript by default is bad. I think web applications should link themselves to each asset they need on its directory/namespace. You will probably loose the advantage of having only one URL for the same file if you install multiple web applications, but you gain more control having each application using one directory/namespace and only one SELinux must be taken into consideration too, be it that those directories get finally shared entirely or not. Will be created a new SELinux context for font (already exist), JavasScript code and other files?, in order to allow Apache to read files outside /var/www. With the current way of packaging of bundling everything this wasn't a problem because files were part of the application, not anymore with these proposal SELinux currently doesn't prevent any of the accesses we need. There might be a couple opportunities to actually lock down stuff more thanks to the improvements here, but that's just gravy. -T.C. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F20 System Wide Change: Web Assets
On Thu, Aug 8, 2013 at 12:22 PM, Robert Marcano rob...@marcanoonline.com wrote: The directory is not called /usr/share/web-javascript, it is called /usr/share/javascript, and the packaging guidelines draft explicitly says that the intention is to avoid duplication of libraries, so it is calling to move all JavaScript reusable code/frameworks/libraries to it, not only browser based JavaScript, and I quote: /usr/lib/python2.7 is not called /usr/lib/cpython2.7, because when most people think Python, they think CPython, since that has been the main implementation of Python for 22 years. Similarly, /usr/share/javascript is not called /usr/share/web-javascript, because when most people think JavaScript, they think browser JavaScript, since that has been the main implementation of JavaScript for 18 years. There are cool other implementations of Python that work differently, like PyPy, which uses /usr/lib/pypy. There are cool other implementations of JavaScript, like Node.js, which uses /usr/lib/node_modules. Being pointlessly pedantic in either of these cases would just confuse users for no benefit. Debian already uses /usr/share/javascript for this purpose, and it would be really nice if we both could coordinate on getting some upstream support for this in certain cases. I'm very strongly -1 against pointless Fedoraisms here. There are also some JavaScript libraries which are intended to be used on the local system, not served via a web server to a browser. These libraries clearly have all the standard reasons to avoid duplication. The preamble before this and the Install Location section afterward clearly states that there is JavaScript on the system that doesn't belong it /usr/share/javascript, like GNOME Shell Extensions and Node.js modules, which live in directories of their own, but the rest of the guidelines still apply to them. I don't really need to repeat that in every paragraph, do I? and later it contradict what you say, indicating that they must use BuildRequires: web-assets-devel and Requires: web-assets-filesystem So, it means all JavaScript, even the used on the local system must depend of web-assets web-assets-filesystem contains a handful of directories and symlinks. It does not drag in Apache configuration. web-assets-devel defines a few RPM macros. It also does not drag in Apache configuration. web-assets-httpd contains the Apache configuration. js-foo libraries MUST not depend on it, since they could be used with any HTTP daemon. -T.C. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F20 System Wide Change: Web Assets
On 08/06/2013 10:46 AM, Miloslav Trmač wrote: On Tue, Aug 6, 2013 at 5:27 AM, Robert Marcano rob...@marcanoonline.com wrote: You make the decision by installing a js-foo package, just like you make the decision to provide a web application by installing a package for it. You make a decision by installing a package is a really problematic model, e.g. because packages can be dragged in by dependencies. Do you know there are GNOME JavaScript applications? And that JavaScript is being encouraged as a language for desktop applications? So all those libraries that can be used on desktop and web clients will be shared by default if I install a desktop application that need that library and a web application that never uses that library? This is madness, why not share /usr/bin via NFS too by default There is actually a precedent for that - our default httpd configuration aliases /icons, see e.g. https://fedoraproject.org/icons/apache_pb2.png . OK, these are only public domain; then let's see httpd-manual, which publishes Apache-licensed documentation in /manual. And I don't see a problems with those examples, because they share only their contents, by installing them you don't share content from other packages. Lets make an example of the mess this will create if I want to share a web application to the world and user another one on my intranet. I will call those Internet and Intranet application Internet application requires JavaScript library intranet-library, and the same with intranet-library. Both applications are installed, I as a sysadmin don't want to expose intranet used assets to the general public, so I need to make changes on it's respective apache configuration file in order to explicitly block /usr/share/web-assets/javascript/intranet-library. A new update to intranet application adds a new requirement. new-intranet-library. So I as a sysadmin must be checking every package installed in order to see if it is exposing more things to the public. You can have many reasons for not wanting that, license of those files, avoid people linking to them and use your bandwidth. I am not against creating some order and removing the privilege that JavaScript code and assets currently have of being allowed to be bundled on every package. But sharing /usr/share/fonts and /usr/share/javascript by default is bad. I think web applications should link themselves to each asset they need on its directory/namespace. You will probably loose the advantage of having only one URL for the same file if you install multiple web applications, but you gain more control having each application using one directory/namespace and only one SELinux must be taken into consideration too, be it that those directories get finally shared entirely or not. Will be created a new SELinux context for font (already exist), JavasScript code and other files?, in order to allow Apache to read files outside /var/www. With the current way of packaging of bundling everything this wasn't a problem because files were part of the application, not anymore with these proposal (That's not necessarily a good argument that it's OK to do this way, I just wanted to point out that this is not that new.) Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F20 System Wide Change: Web Assets
On 08/06/2013 02:36 PM, Colin Walters wrote: On Mon, 2013-08-05 at 22:57 -0430, Robert Marcano wrote: Do you know there are GNOME JavaScript applications? And that JavaScript is being encouraged as a language for desktop applications? So all those libraries that can be used on desktop and web clients There's *very* little JavaScript code out there that is not tied to the underlying platform; typically when people say JavaScript they mean code that uses the DOM, XHR, etc. node.js and gjs have independent underlying platforms (custom and gobject-introspection respectively). *very* little code is not an opportunity to say: lets treat all of them equally. Examples: [1] sjcl or [2] crypto-js. They aren't tied to a browser but can be used on it. Or we have /usr/share/web-javascript and /usr/share/non-web-javascript or something like that, or treat them equally and share it all to the web wrongly Java packaging guidelines make no distinction if the Java code is being used on a web applet or not, and it shouldn't. If a package is reusable and is being used on another package a link to it should be used, done. /usr/share/java is not shared by default because there are Java applets on the repository (VNC remote viewer). I know, I know applets are dying but follow my idea [1] http://crypto.stanford.edu/sjcl/ [2] http://code.google.com/p/crypto-js/ It makes no sense to serve gjs or node.js code to the web. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F20 System Wide Change: Web Assets
On 08/06/2013 05:10 PM, T.C. Hollingsworth wrote:
On Mon, Aug 5, 2013 at 8:27 PM, Robert Marcano rob...@marcanoonline.com wrote:
Do you know there are GNOME JavaScript applications? And that JavaScript is
being encouraged as a language for desktop applications? So all those
libraries that can be used on desktop and web clients will be shared by
default if I install a desktop application that need that library and a web
application that never uses that library? This is madness, why not share
/usr/bin via NFS too by default
Yes, and they certainly don't belong in the *Web Assets* directory.
This is about JavaScript for the web, not every place under the sun in
which it is embedded.
The directory is not called /usr/share/web-javascript, it is called
/usr/share/javascript, and the packaging guidelines draft explicitly
says that the intention is to avoid duplication of libraries, so it is
calling to move all JavaScript reusable code/frameworks/libraries to it,
not only browser based JavaScript, and I quote:
There are also some JavaScript libraries which are intended to be used
on the local system, not served via a web server to a browser. These
libraries clearly have all the standard reasons to avoid duplication.
and later it contradict what you say, indicating that they must use
BuildRequires: web-assets-devel and
Requires: web-assets-filesystem
So, it means all JavaScript, even the used on the local system must
depend of web-assets
Software which embeds languages usually use their own directory for
the libraries involved. Blender doesn't drop a bunch of crap in
%{python_sitelib} that is only useful to it, and GNOME won't be
dropping a bunch of stuff in %{_jsdir} that is completely useless on
the web since it involves C bindings.
I might add that the policies being implemented here really don't make
sense for non-web JS anyway. Minification is pointless for GNOME
shell extensions, since the entire point of minification is to reduce
HTTP transfer times. Additionally, we don't want the static inclusion
exception to be permitted for server-side or embedded JS. It's not
the '90s anymore; they should be getting libraries right.
I just made a series of changes to the draft JavaScript guidelines
that enforce what I said above.
This is a licensing problem. I should not need to disable it, because I
think Fedora should not share code/assets only because I installed it, the
we application need to share it if it is really needed. I think I a being
repetitive here NAD nobody understand my point of view :-( probably I
should ask on fedora-legal, I don't like where this is going, making me a
distributor by default of every JavaScript package installed even if no web
application needs them
Who is going to install js-jquery and never want to use it on a web
server? Yeah, these will get dragged in as dependencies, but if a web
application `Requires: js-jquery`, that's it saying it needs it!
Yeah, a couple of these libraries can be used by server-side JS
runtimes. But if you install coffee-script, I as a packager can't
psychically divine whether you intend to compile all your coffee
script to JS prior to serving it or dynamically compile it on the fly,
so it makes sense *by default* to support both use cases. And really,
if you're precompiling I sincerely hope you're not doing it on your
production server, in which case you just won't have coffee-script
installed on your server at all.
I think the defaults here are useful for 99% of people's use cases,
and open up a bunch of new ones.
Wouldn't it be cool if you could change your blog's font by just
installing it and selecting it from a drop-down box in WordPress?
Without having to figure out how to make Apache include it? Oh wait,
most users aren't going to mess around with Apache configs, they're
just going to `cp` it to /var/www/html, and when it gets updated
because a glyph gets rendered wrong the copy on their web server will
be outdated forever. :-(
The days where every web application and framework knows exactly what
libraries it needs are over. How can the rails maintainer know if the
dev wants to use jQuery, or Bootstrap, or Angular? We can either make
it dead simple for them to use system versions of these libraries
(just `yum install bootstrap`, add a link tag to your template, and
BAM! it's there!), or again they'll just keep dropping copies in their
directories like they've been doing forever.
We have a really good set of tools for distributing and keeping stuff
up-to-date, and it would be really, REALLY nice if they could be
applied to stuff exported over web servers too, but nobody's going to
use our work if we make it too damn difficult for them to use. :-(
This is just one piece of the puzzle, but it's an important first step. :-)
-T.C.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F20 System Wide Change: Web Assets
Hello, Many web apps use an optimization technique where they try to minimize the number of httpd request by concatenating minified versions into one file. Example: app uses 20 tiny jQuery plugins. Similar use case is when app is using AMD modules and uses only a subset of modules from a huge lib like Dojo+Dijit+Dojox. Loading whole lib is not an option - too big. One usually creates a custom build. Does the proposal count with these use cases? As I read the packaging guidelines [1], one could use the static inclusion of libraries for it. I don't think it was designed for it, though. Related Q: What will happen when included library gets updated? [1] https://fedoraproject.org/wiki/User:Patches/PackagingDrafts/JavaScript#Static_Inclusion_of_Libraries -- Petr Vobornik -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F20 System Wide Change: Web Assets
On Wed, Aug 7, 2013 at 1:20 AM, Petr Vobornik pvobo...@redhat.com wrote: Hello, Many web apps use an optimization technique where they try to minimize the number of httpd request by concatenating minified versions into one file. Example: app uses 20 tiny jQuery plugins. Similar use case is when app is using AMD modules and uses only a subset of modules from a huge lib like Dojo+Dijit+Dojox. Loading whole lib is not an option - too big. One usually creates a custom build. Does the proposal count with these use cases? As I read the packaging guidelines [1], one could use the static inclusion of libraries for it. I don't think it was designed for it, though. I'm not too thrilled with this, but there are only really two solutions here, and they both suck. If you prebuild it, your package becomes a slave to all its dependencies and will have to be updated when even one little one changes, which sucks. If you build it locally, you need to drag in a bunch of dependencies for that, which also sucks. :-( Given that there's no good answer here, I think we should allow this. I tweaked the language in the static inclusion section so this is explicitly permitted and described in the rationale: https://fedoraproject.org/w/index.php?title=User%3APatches%2FPackagingDrafts%2FJavaScriptdiff=348406oldid=348213 Related Q: What will happen when included library gets updated? The proposal calls for adding versioned virtual provides that track what libraries are included, via a macro that adds the version in the buildroot automatically for you. Thanks to that, we can have a cron job that will bug maintainers to rebuild when one of their statically included dependencies updates. :-) Hopefully with stuff like AMD we can add some RPM magic that adds the virtual Provides automatically, so packagers won't have to track it manually, but compiling during the build process complicates that. If you don't end up installing a package.json or having `require()` calls in the %buildroot there's nothing for an AutoProvReq generator to key off of. :-( Anyway, that's something we'll have to look into in more detail when we get around to packaging that stuff. -T.C. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F20 System Wide Change: Web Assets
On Tue, Aug 6, 2013 at 5:27 AM, Robert Marcano rob...@marcanoonline.com wrote: You make the decision by installing a js-foo package, just like you make the decision to provide a web application by installing a package for it. You make a decision by installing a package is a really problematic model, e.g. because packages can be dragged in by dependencies. Do you know there are GNOME JavaScript applications? And that JavaScript is being encouraged as a language for desktop applications? So all those libraries that can be used on desktop and web clients will be shared by default if I install a desktop application that need that library and a web application that never uses that library? This is madness, why not share /usr/bin via NFS too by default There is actually a precedent for that - our default httpd configuration aliases /icons, see e.g. https://fedoraproject.org/icons/apache_pb2.png . OK, these are only public domain; then let's see httpd-manual, which publishes Apache-licensed documentation in /manual. (That's not necessarily a good argument that it's OK to do this way, I just wanted to point out that this is not that new.) Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F20 System Wide Change: Web Assets
On Sun, Aug 04, 2013 at 03:05:21PM -0700, T.C. Hollingsworth wrote: On Sun, Aug 4, 2013 at 1:44 AM, Till Maas opensou...@till.name wrote: The guideline should be to ask upstream to fix the meta data. In case of missing license text (e.g. source code with a GPL header but no copy of the GPL itself), it is also upstream's task to fix it and the packager's to ask for it. And if upstream fixes it, the debian font packagers do not need to replicate Fedora's effort. We absolutely want this fixed upstream first. I adjusted the draft to reflect this: https://fedoraproject.org/wiki/User:Patches/PackagingDrafts/FontsPolicy Sometime this week I'm going to file bugs against all the affected font packages to give packages an opportunity to work with their upstreams to correct this. Please provide actual recommendations about how to run the ttname command to the guidelines before filing bugs. And get the guideline approved to avoid unnecessary changes. Also this does not seem to be really a MUST guideline as long as it is not a MUST guideline to add the GPL license text to all GPL licensed packages if the license text is not included. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F20 System Wide Change: Web Assets
On Tue, 6 Aug 2013 17:48:23 +0200 Till Maas opensou...@till.name wrote: On Sun, Aug 04, 2013 at 03:05:21PM -0700, T.C. Hollingsworth wrote: On Sun, Aug 4, 2013 at 1:44 AM, Till Maas opensou...@till.name wrote: The guideline should be to ask upstream to fix the meta data. In case of missing license text (e.g. source code with a GPL header but no copy of the GPL itself), it is also upstream's task to fix it and the packager's to ask for it. And if upstream fixes it, the debian font packagers do not need to replicate Fedora's effort. We absolutely want this fixed upstream first. I adjusted the draft to reflect this: https://fedoraproject.org/wiki/User:Patches/PackagingDrafts/FontsPolicy Sometime this week I'm going to file bugs against all the affected font packages to give packages an opportunity to work with their upstreams to correct this. Please provide actual recommendations about how to run the ttname command to the guidelines before filing bugs. And get the guideline approved to avoid unnecessary changes. Also this does not seem to be really a MUST guideline as long as it is not a MUST guideline to add the GPL license text to all GPL licensed packages if the license text is not included. If you are going to file a bunch of bugs, PLEASE see: http://fedoraproject.org/wiki/Mass_bug_filing Thanks, kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F20 System Wide Change: Web Assets
On Mon, 2013-08-05 at 22:57 -0430, Robert Marcano wrote: Do you know there are GNOME JavaScript applications? And that JavaScript is being encouraged as a language for desktop applications? So all those libraries that can be used on desktop and web clients There's *very* little JavaScript code out there that is not tied to the underlying platform; typically when people say JavaScript they mean code that uses the DOM, XHR, etc. node.js and gjs have independent underlying platforms (custom and gobject-introspection respectively). It makes no sense to serve gjs or node.js code to the web. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F20 System Wide Change: Web Assets
On Mon, Aug 5, 2013 at 8:27 PM, Robert Marcano rob...@marcanoonline.com wrote:
Do you know there are GNOME JavaScript applications? And that JavaScript is
being encouraged as a language for desktop applications? So all those
libraries that can be used on desktop and web clients will be shared by
default if I install a desktop application that need that library and a web
application that never uses that library? This is madness, why not share
/usr/bin via NFS too by default
Yes, and they certainly don't belong in the *Web Assets* directory.
This is about JavaScript for the web, not every place under the sun in
which it is embedded.
Software which embeds languages usually use their own directory for
the libraries involved. Blender doesn't drop a bunch of crap in
%{python_sitelib} that is only useful to it, and GNOME won't be
dropping a bunch of stuff in %{_jsdir} that is completely useless on
the web since it involves C bindings.
I might add that the policies being implemented here really don't make
sense for non-web JS anyway. Minification is pointless for GNOME
shell extensions, since the entire point of minification is to reduce
HTTP transfer times. Additionally, we don't want the static inclusion
exception to be permitted for server-side or embedded JS. It's not
the '90s anymore; they should be getting libraries right.
I just made a series of changes to the draft JavaScript guidelines
that enforce what I said above.
This is a licensing problem. I should not need to disable it, because I
think Fedora should not share code/assets only because I installed it, the
we application need to share it if it is really needed. I think I a being
repetitive here NAD nobody understand my point of view :-( probably I
should ask on fedora-legal, I don't like where this is going, making me a
distributor by default of every JavaScript package installed even if no web
application needs them
Who is going to install js-jquery and never want to use it on a web
server? Yeah, these will get dragged in as dependencies, but if a web
application `Requires: js-jquery`, that's it saying it needs it!
Yeah, a couple of these libraries can be used by server-side JS
runtimes. But if you install coffee-script, I as a packager can't
psychically divine whether you intend to compile all your coffee
script to JS prior to serving it or dynamically compile it on the fly,
so it makes sense *by default* to support both use cases. And really,
if you're precompiling I sincerely hope you're not doing it on your
production server, in which case you just won't have coffee-script
installed on your server at all.
I think the defaults here are useful for 99% of people's use cases,
and open up a bunch of new ones.
Wouldn't it be cool if you could change your blog's font by just
installing it and selecting it from a drop-down box in WordPress?
Without having to figure out how to make Apache include it? Oh wait,
most users aren't going to mess around with Apache configs, they're
just going to `cp` it to /var/www/html, and when it gets updated
because a glyph gets rendered wrong the copy on their web server will
be outdated forever. :-(
The days where every web application and framework knows exactly what
libraries it needs are over. How can the rails maintainer know if the
dev wants to use jQuery, or Bootstrap, or Angular? We can either make
it dead simple for them to use system versions of these libraries
(just `yum install bootstrap`, add a link tag to your template, and
BAM! it's there!), or again they'll just keep dropping copies in their
directories like they've been doing forever.
We have a really good set of tools for distributing and keeping stuff
up-to-date, and it would be really, REALLY nice if they could be
applied to stuff exported over web servers too, but nobody's going to
use our work if we make it too damn difficult for them to use. :-(
This is just one piece of the puzzle, but it's an important first step. :-)
-T.C.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F20 System Wide Change: Web Assets
On Tue, Aug 6, 2013 at 8:48 AM, Till Maas opensou...@till.name wrote: Please provide actual recommendations about how to run the ttname command to the guidelines before filing bugs. And get the guideline approved to avoid unnecessary changes. Also this does not seem to be really a MUST guideline as long as it is not a MUST guideline to add the GPL license text to all GPL licensed packages if the license text is not included. Bugs will not be filed until ttname is in the distribution. No sense in asking packagers to do something they can't possibly do yet. ;-) BTW, it's already pretty much done, I'm just working on finishing up the test suite and trying it out with a wide variety of fonts in various scripts so I can be sure we're not going to break anything when we start using it. There's already some example instructions on how to use ttname here, which accurately reflects the CLI interface as it is now implemented: https://fedoraproject.org/wiki/User:Patches/ttname -T.C. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F20 System Wide Change: Web Assets
On Tue, Aug 6, 2013 at 9:46 AM, Kevin Fenzi ke...@scrye.com wrote: If you are going to file a bunch of bugs, PLEASE see: http://fedoraproject.org/wiki/Mass_bug_filing I definitely will follow that, thanks! You might want to shout about that a little more widely, I think every mass bug filing I'm aware of in recent history has skipped portions of that. :-( -T.C. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F20 System Wide Change: Web Assets
On Tue, 6 Aug 2013 14:50:01 -0700 T.C. Hollingsworth tchollingswo...@gmail.com wrote: On Tue, Aug 6, 2013 at 9:46 AM, Kevin Fenzi ke...@scrye.com wrote: If you are going to file a bunch of bugs, PLEASE see: http://fedoraproject.org/wiki/Mass_bug_filing I definitely will follow that, thanks! You might want to shout about that a little more widely, I think every mass bug filing I'm aware of in recent history has skipped portions of that. :-( Yeah, but sadly, many people who want to mass file bugs are gung ho and don't ask before they do so, they just charge ahead. ;( Anyhow, do spread it around. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F20 System Wide Change: Web Assets
On Aug 3, 2013 8:55 PM, T.C. Hollingsworth tchollingswo...@gmail.com wrote: On Tue, Jul 30, 2013 at 5:48 AM, Robert Marcano rob...@marcanoonline.com wrote: On 07/26/2013 12:30 PM, Nicolas Mailhot wrote: Le Lun 22 juillet 2013 21:58, Robert Marcano a écrit : The real problem with publishing things is that if I distribute binaries of many things I must follow the license, some say I need to distribute sources, some say that I need to distribute a copy of the license, etc. Making files downloadable by default adds to the distributor more work (legal) because they must comply with their licenses. So if I put an open service of an Apache licensed web application, I will start distributing fonts with other licenses without ever noticing, for example GPL+3 (nothing against any license, only examples of the things people should care when distributing free/open licensed code/assets) Again, the fonts available in Fedora are carefully vetted and none of them have redistribution restrictions (and even for those with GPLish licenses a large part of the font community considers the font file is the font source, so you can't redistribute one without the other) I understand your point but please take another example. There isn't another example, with the exception of Javascript code that is planned to be made available too. I don't consider that the distribution must make the decision to make me a distributor of assets I am not using on one of the web applications I decided to publish on my webserver, those web applications must make available those assets and only those assets. You make the decision by installing a js-foo package, just like you make the decision to provide a web application by installing a package for it. Do you know there are GNOME JavaScript applications? And that JavaScript is being encouraged as a language for desktop applications? So all those libraries that can be used on desktop and web clients will be shared by default if I install a desktop application that need that library and a web application that never uses that library? This is madness, why not share /usr/bin via NFS too by default This is a licensing problem. I should not need to disable it, because I think Fedora should not share code/assets only because I installed it, the we application need to share it if it is really needed. I think I a being repetitive here NAD nobody understand my point of view :-( probably I should ask on fedora-legal, I don't like where this is going, making me a distributor by default of every JavaScript package installed even if no web application needs them Also, it's just a default. Disabling it will be easy; just truncate the relevant config file: echo /etc/httpd/conf.d/web-assets.conf To force me to blacklist is wrong. Javascript code is worse in this aspect because it can be used as an attack vector, finding vulnerabilities that allow someone to inject Javascript code from the same server There is nothing like CORS protections for script tags. (In fact, they are commonly used to evade them, i.e. JSONP.) If an attacker can force your application to load code from your server they can just as easily pull it from a public CDN or a server under their control. Even disabling all external script loading wouldn't help you, since they could just use eval(). -T.C. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F20 System Wide Change: Web Assets
On Tue, Jul 23, 2013 at 07:54:38PM +0200, Nicolas Mailhot wrote: Le Mar 23 juillet 2013 19:26, T.C. Hollingsworth a écrit : AFAICS it shouldn't be too hard to script up something so this would as easy as `fixfontmd --copyright $(head -n3 LICENSE) --licensedesc $(cat LICENSE) --licenseurl http://example.com/LICENSE` for packagers. I'd be happy to add a guideline for this and fix up existing packages if this seems amenable. If you can write a tool that makes it easy to fix opentype licensing fields at build time, I'll be delighted to support any guideline change that mandated its use. However if you go in this direction please check on the fonts and openfontlibrary list knowledgeable people agree there are no wrong side-effect (this will reach debian font packagers at least BTW) The guideline should be to ask upstream to fix the meta data. In case of missing license text (e.g. source code with a GPL header but no copy of the GPL itself), it is also upstream's task to fix it and the packager's to ask for it. And if upstream fixes it, the debian font packagers do not need to replicate Fedora's effort. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F20 System Wide Change: Web Assets
On Mon, Jul 22, 2013 at 12:22:10PM +0200, Björn Persson wrote: Florian Weimer wrote: On 07/16/2013 12:54 PM, Jaroslav Reznik wrote: = Proposed System Wide Change: Web Assets = https://fedoraproject.org/wiki/Changes/Web_Assets Can we please use a different name, like webdata? The term asset seems to scare some people. At least the directory in /usr/share really should have web or something in the name. Someone who does ls /usr/share and sees assets won't understand that it's web related. In the URL namespace web isn't necessary, because in that context it's implicit. Why web and not www? For variable www data the default path is /var/lib/www, therefore for static content /usr/share/www sounds more appropriate. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F20 System Wide Change: Web Assets
On Sun, Aug 4, 2013 at 1:44 AM, Till Maas opensou...@till.name wrote: The guideline should be to ask upstream to fix the meta data. In case of missing license text (e.g. source code with a GPL header but no copy of the GPL itself), it is also upstream's task to fix it and the packager's to ask for it. And if upstream fixes it, the debian font packagers do not need to replicate Fedora's effort. We absolutely want this fixed upstream first. I adjusted the draft to reflect this: https://fedoraproject.org/wiki/User:Patches/PackagingDrafts/FontsPolicy Sometime this week I'm going to file bugs against all the affected font packages to give packages an opportunity to work with their upstreams to correct this. -T.C. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F20 System Wide Change: Web Assets
On Tue, Jul 30, 2013 at 5:48 AM, Robert Marcano rob...@marcanoonline.com wrote: On 07/26/2013 12:30 PM, Nicolas Mailhot wrote: Le Lun 22 juillet 2013 21:58, Robert Marcano a écrit : The real problem with publishing things is that if I distribute binaries of many things I must follow the license, some say I need to distribute sources, some say that I need to distribute a copy of the license, etc. Making files downloadable by default adds to the distributor more work (legal) because they must comply with their licenses. So if I put an open service of an Apache licensed web application, I will start distributing fonts with other licenses without ever noticing, for example GPL+3 (nothing against any license, only examples of the things people should care when distributing free/open licensed code/assets) Again, the fonts available in Fedora are carefully vetted and none of them have redistribution restrictions (and even for those with GPLish licenses a large part of the font community considers the font file is the font source, so you can't redistribute one without the other) I understand your point but please take another example. There isn't another example, with the exception of Javascript code that is planned to be made available too. I don't consider that the distribution must make the decision to make me a distributor of assets I am not using on one of the web applications I decided to publish on my webserver, those web applications must make available those assets and only those assets. You make the decision by installing a js-foo package, just like you make the decision to provide a web application by installing a package for it. Also, it's just a default. Disabling it will be easy; just truncate the relevant config file: echo /etc/httpd/conf.d/web-assets.conf To force me to blacklist is wrong. Javascript code is worse in this aspect because it can be used as an attack vector, finding vulnerabilities that allow someone to inject Javascript code from the same server There is nothing like CORS protections for script tags. (In fact, they are commonly used to evade them, i.e. JSONP.) If an attacker can force your application to load code from your server they can just as easily pull it from a public CDN or a server under their control. Even disabling all external script loading wouldn't help you, since they could just use eval(). -T.C. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F20 System Wide Change: Web Assets
On 07/26/2013 12:30 PM, Nicolas Mailhot wrote: Le Lun 22 juillet 2013 21:58, Robert Marcano a écrit : The real problem with publishing things is that if I distribute binaries of many things I must follow the license, some say I need to distribute sources, some say that I need to distribute a copy of the license, etc. Making files downloadable by default adds to the distributor more work (legal) because they must comply with their licenses. So if I put an open service of an Apache licensed web application, I will start distributing fonts with other licenses without ever noticing, for example GPL+3 (nothing against any license, only examples of the things people should care when distributing free/open licensed code/assets) Again, the fonts available in Fedora are carefully vetted and none of them have redistribution restrictions (and even for those with GPLish licenses a large part of the font community considers the font file is the font source, so you can't redistribute one without the other) I understand your point but please take another example. There isn't another example, with the exception of Javascript code that is planned to be made available too. I don't consider that the distribution must make the decision to make me a distributor of assets I am not using on one of the web applications I decided to publish on my webserver, those web applications must make available those assets and only those assets. To force me to blacklist is wrong. Javascript code is worse in this aspect because it can be used as an attack vector, finding vulnerabilities that allow someone to inject Javascript code from the same server -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F20 System Wide Change: Web Assets
Le Lun 22 juillet 2013 21:58, Robert Marcano a écrit : The real problem with publishing things is that if I distribute binaries of many things I must follow the license, some say I need to distribute sources, some say that I need to distribute a copy of the license, etc. Making files downloadable by default adds to the distributor more work (legal) because they must comply with their licenses. So if I put an open service of an Apache licensed web application, I will start distributing fonts with other licenses without ever noticing, for example GPL+3 (nothing against any license, only examples of the things people should care when distributing free/open licensed code/assets) Again, the fonts available in Fedora are carefully vetted and none of them have redistribution restrictions (and even for those with GPLish licenses a large part of the font community considers the font file is the font source, so you can't redistribute one without the other) I understand your point but please take another example. -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F20 System Wide Change: Web Assets
On 07/23/2013 12:56 PM, T.C. Hollingsworth wrote: On Mon, Jul 22, 2013 at 8:41 AM, Nicolas Mailhot nicolas.mail...@laposte.net wrote: Le Lun 22 juillet 2013 17:07, Robert Marcano a écrit : Fonts has licenses, some of them require the license to be shown or the copyright displayed, some fonts has the copyright added to their metadata, I don't find for example that gnu-free-serif-fonts says on it's metadata that is GPL+3 with exceptions. On the contrary, /usr/share/fonts/gnu-free/FreeSerif.ttf does contain the usual This is free software, you may distribute it under the GNU GPL... block in the name table. I'd say that when a font requires some communication of licensing downstream, but forgets to put its own license in the font metadata, that's an upstream problem. Upstream can not complain Fedora didn't work hard enough about something it didn't do itself. Honestly, I'd prefer that we fixed this in Fedora. It solves this problem quite nicely, and I don't really think it's that widespread an issue anyway. (I'm going to run a script to check soon; I'm downloading 300MB worth of fonts right now. ;-) Fixing the font metadata is a good thing, but I still don't want a distribution that make a distributor of everything by default. If I install a web application package. I am accepting I will distribute what that applications needs and I will respect their license, not everything that is installed, This apply to the Javascript libraries too. If I install application that needs asset A, but I have installed asset B that is not needed by the applications, that doesn't means I want asset B to be distributed by default, that will means I should start blacklisting (that is wrong) or I need to uninstall the package and I am probably using the package for something local. We now have GNOME applications built using Javascript, so it is not rare we start using libraries that people think are only for the web and they aren't AFAICS it shouldn't be too hard to script up something so this would as easy as `fixfontmd --copyright $(head -n3 LICENSE) --licensedesc $(cat LICENSE) --licenseurl http://example.com/LICENSE` for packagers. I'd be happy to add a guideline for this and fix up existing packages if this seems amenable. -T.C. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: Web Assets
So, this change has FPC guidelines and also some redhat-rpm-macros changes? Do those need to be done before the mass rebuild? kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: Web Assets
On Wed, Jul 24, 2013 at 1:56 PM, Kevin Fenzi ke...@scrye.com wrote: So, this change has FPC guidelines and also some redhat-rpm-macros changes? Yup, we just need to add a macro so it's available during createSRPMfromSCM in Koji. (The conditionalized syntax we'd need otherwise is just awful.) Do those need to be done before the mass rebuild? Nope, they don't affect anything currently packaged. It's only for a bunch of new packages we want to get in. :-) -T.C. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: Web Assets
On Wed, 24 Jul 2013 14:20:39 -0700 T.C. Hollingsworth tchollingswo...@gmail.com wrote: On Wed, Jul 24, 2013 at 1:56 PM, Kevin Fenzi ke...@scrye.com wrote: So, this change has FPC guidelines and also some redhat-rpm-macros changes? Yup, we just need to add a macro so it's available during createSRPMfromSCM in Koji. (The conditionalized syntax we'd need otherwise is just awful.) Do those need to be done before the mass rebuild? Nope, they don't affect anything currently packaged. It's only for a bunch of new packages we want to get in. :-) Great! Just wanted to confirm it wasn't something that needed to land before mass rebuild. Thanks, kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: Web Assets
On Mon, Jul 22, 2013 at 8:41 AM, Nicolas Mailhot nicolas.mail...@laposte.net wrote: Le Lun 22 juillet 2013 17:07, Robert Marcano a écrit : Fonts has licenses, some of them require the license to be shown or the copyright displayed, some fonts has the copyright added to their metadata, I don't find for example that gnu-free-serif-fonts says on it's metadata that is GPL+3 with exceptions. On the contrary, /usr/share/fonts/gnu-free/FreeSerif.ttf does contain the usual This is free software, you may distribute it under the GNU GPL... block in the name table. I'd say that when a font requires some communication of licensing downstream, but forgets to put its own license in the font metadata, that's an upstream problem. Upstream can not complain Fedora didn't work hard enough about something it didn't do itself. Honestly, I'd prefer that we fixed this in Fedora. It solves this problem quite nicely, and I don't really think it's that widespread an issue anyway. (I'm going to run a script to check soon; I'm downloading 300MB worth of fonts right now. ;-) AFAICS it shouldn't be too hard to script up something so this would as easy as `fixfontmd --copyright $(head -n3 LICENSE) --licensedesc $(cat LICENSE) --licenseurl http://example.com/LICENSE` for packagers. I'd be happy to add a guideline for this and fix up existing packages if this seems amenable. -T.C. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: Web Assets
Le Mar 23 juillet 2013 19:26, T.C. Hollingsworth a écrit : Honestly, I'd prefer that we fixed this in Fedora. It solves this problem quite nicely, and I don't really think it's that widespread an issue anyway. Historically it was quite widespread. The only bit of font metadata one could rely on was the font name, and then not always. A font author would widely announce the relicensing of his font and not change the metadata in the font files. Even Google Droid had rotten licensing metadata when it was first released IIRC However there has been quite a lot evangelization about this issue in free/open font circles those past years, so the situation may have improved (I'm going to run a script to check soon; I'm downloading 300MB worth of fonts right now. ;-) AFAICS it shouldn't be too hard to script up something so this would as easy as `fixfontmd --copyright $(head -n3 LICENSE) --licensedesc $(cat LICENSE) --licenseurl http://example.com/LICENSE` for packagers. I'd be happy to add a guideline for this and fix up existing packages if this seems amenable. If you can write a tool that makes it easy to fix opentype licensing fields at build time, I'll be delighted to support any guideline change that mandated its use. However if you go in this direction please check on the fonts and openfontlibrary list knowledgeable people agree there are no wrong side-effect (this will reach debian font packagers at least BTW) Regards, -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: Web Assets
On Tue, Jul 23, 2013 at 10:54 AM, Nicolas Mailhot nicolas.mail...@laposte.net wrote: Historically it was quite widespread. The only bit of font metadata one could rely on was the font name, and then not always. A font author would widely announce the relicensing of his font and not change the metadata in the font files. Even Google Droid had rotten licensing metadata when it was first released IIRC Google still seems to be the worst offender in my search thus far. :-/ However there has been quite a lot evangelization about this issue in free/open font circles those past years, so the situation may have improved (I'm going to run a script to check soon; I'm downloading 300MB worth of fonts right now. ;-) And the results are in... There are 80 fonts in 28 packages that have neither the copyright (name ID#0) nor license description (#13) field populated. [1] There are additionally 252 fonts in 128 packages that don't set the license description field while setting the copyright field. [2] These are probably fine, but we might want to take a look over them anyway. (There are none with a description but no copyright.) Finally, 880 fonts in 402 packages don't set the license URL (#14) field, but this definitely isn't a blocker. [3] AFAICS it shouldn't be too hard to script up something so this would as easy as `fixfontmd --copyright $(head -n3 LICENSE) --licensedesc $(cat LICENSE) --licenseurl http://example.com/LICENSE` for packagers. I'd be happy to add a guideline for this and fix up existing packages if this seems amenable. If you can write a tool that makes it easy to fix opentype licensing fields at build time, I'll be delighted to support any guideline change that mandated its use. However if you go in this direction please check on the fonts and openfontlibrary list knowledgeable people agree there are no wrong side-effect (this will reach debian font packagers at least BTW) Thanks, will do when I have something concrete to show. The fontTools library underlying the ttx tool seems to make this kind of stuff pretty easy. (I used it to perform the query above.) I'm hoping it won't mangle the fonts into oblivion. ;-) -T.C. [1] http://patches.fedorapeople.org/js-repoqueries/fonts-neither [2] http://patches.fedorapeople.org/js-repoqueries/fonts-nodesc [3] http://patches.fedorapeople.org/js-repoqueries/fonts-nourl -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: Web Assets
On Tue, Jul 23, 2013 at 11:45 AM, T.C. Hollingsworth tchollingswo...@gmail.com wrote: There are additionally 252 fonts in 128 packages that don't set the license description field while setting the copyright field. [2] These are probably fine, but we might want to take a look over them anyway. (There are none with a description but no copyright.) Actually we'll probably need to fix quite a few of these. :-( I've dumped the text here so I can go through them later: https://fedoraproject.org/wiki/Web_Assets/Fonts/Missing_Descriptions -T.C. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: Web Assets
Le Mar 23 juillet 2013 21:20, T.C. Hollingsworth a écrit : On Tue, Jul 23, 2013 at 11:45 AM, T.C. Hollingsworth tchollingswo...@gmail.com wrote: There are additionally 252 fonts in 128 packages that don't set the license description field while setting the copyright field. [2] These are probably fine, but we might want to take a look over them anyway. (There are none with a description but no copyright.) Actually we'll probably need to fix quite a few of these. :-( Not surprised:( Needs some hero to clean up the legacy pile (guidelines may ensure new problems are not introduced in future packages) I've dumped the text here so I can go through them later: https://fedoraproject.org/wiki/Web_Assets/Fonts/Missing_Descriptions -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: Web Assets
On 07/16/2013 12:54 PM, Jaroslav Reznik wrote: = Proposed System Wide Change: Web Assets = https://fedoraproject.org/wiki/Changes/Web_Assets Can we please use a different name, like webdata? The term asset seems to scare some people. -- Florian Weimer / Red Hat Product Security Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: Web Assets
Florian Weimer wrote: On 07/16/2013 12:54 PM, Jaroslav Reznik wrote: = Proposed System Wide Change: Web Assets = https://fedoraproject.org/wiki/Changes/Web_Assets Can we please use a different name, like webdata? The term asset seems to scare some people. At least the directory in /usr/share really should have web or something in the name. Someone who does ls /usr/share and sees assets won't understand that it's web related. In the URL namespace web isn't necessary, because in that context it's implicit. Data isn't a good description of Javascript code and stylesheets though, even if it's just data from the HTTP daemon's point of view. How about Web Libraries and /usr/share/weblib? -- Björn Persson Sent from my computer. signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: Web Assets
On Mon, Jul 22, 2013, Florian Weimer fwei...@redhat.com wrote: Can we please use a different name, like webdata? The term asset seems to scare some people. Huh? It's a pretty common industry term for static bits used as dependencies for websites. I've never heard of anyone being scared of it. webdata sounds to me more like something that should be in /var, not where content and code shared by web applications would live. (And a big part of this feature is that we *stop* treating this stuff like data and start treating it like code! ;-) -T.C. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: Web Assets
On Mon, Jul 22, 2013 at 3:22 AM, Björn Persson bj...@xn--rombobjrn-67a.se wrote: Florian Weimer wrote: On 07/16/2013 12:54 PM, Jaroslav Reznik wrote: = Proposed System Wide Change: Web Assets = https://fedoraproject.org/wiki/Changes/Web_Assets Can we please use a different name, like webdata? The term asset seems to scare some people. At least the directory in /usr/share really should have web or something in the name. Someone who does ls /usr/share and sees assets won't understand that it's web related. In the URL namespace web isn't necessary, because in that context it's implicit. Yeah, /usr/share/web-assets or so would be fine by me. Data isn't a good description of Javascript code and stylesheets though, even if it's just data from the HTTP daemon's point of view. How about Web Libraries and /usr/share/weblib? I don't like that either. CSS files aren't really libraries. ;-) -T.C. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: Web Assets
Le Lun 22 juillet 2013 12:31, T.C. Hollingsworth a écrit : On Mon, Jul 22, 2013, Florian Weimer fwei...@redhat.com wrote: Can we please use a different name, like webdata? The term asset seems to scare some people. Huh? It's a pretty common industry term for static bits used as dependencies for websites. I've never heard of anyone being scared of it. resources may be more neutral than assets Regards, -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: Web Assets
On 07/22/2013 12:31 PM, T.C. Hollingsworth wrote: On Mon, Jul 22, 2013, Florian Weimer fwei...@redhat.com wrote: Can we please use a different name, like webdata? The term asset seems to scare some people. Huh? It's a pretty common industry term for static bits used as dependencies for websites. I've never heard of anyone being scared of it. The term has a completely different meaning in the fields of law and accounting. -- Florian Weimer / Red Hat Product Security Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: Web Assets
Le Lun 22 juillet 2013 17:07, Robert Marcano a écrit : Fonts has licenses, some of them require the license to be shown or the copyright displayed, some fonts has the copyright added to their metadata, I don't find for example that gnu-free-serif-fonts says on it's metadata that is GPL+3 with exceptions. I'd say that when a font requires some communication of licensing downstream, but forgets to put its own license in the font metadata, that's an upstream problem. Upstream can not complain Fedora didn't work hard enough about something it didn't do itself. It's another thing when the licensing actually prohibits distribution, but we don't have those in Fedora, and people that deploy such fonts in Fedora can write deny apache rules themselves (though providing a sample of tuch a rule would be good) Regards, -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: Web Assets
On 07/19/2013 01:13 AM, T.C. Hollingsworth wrote: On Thu, Jul 18, 2013 at 1:13 PM, Robert Marcano rob...@marcanoonline.com wrote: Not all fonts installed had the same licensing requirement, people install fonts from other places that are not as careful as Fedora with the licenses. It is problematic if someone install a non free font to be used on their desktop application and automatically the font is shared on the network because he installed a web application on their machine Good point! That's something I hadn't considered. If some web applications needs a font it must create the symlink of that font on that package First of all, regardless of whether or not the shared directory exists web applications are permitted by the draft guidelines to use symlinks or Apache's Alias directive to make web assets available in their namespace. This makes migration a lot easier in many cases. But we don't have to kill of the shared directory just to work around this. We can just whitelist fonts installed from the Fedora package collection and blacklist the rest unless the sysadmin specifically enables them. I am not sure it is good to share by default files that are not needed by other web applications. The definition of the directory is fine for me, but packages must be responsible to say which fonts to share, not by default. Fonts has licenses, some of them require the license to be shown or the copyright displayed, some fonts has the copyright added to their metadata, I don't find for example that gnu-free-serif-fonts says on it's metadata that is GPL+3 with exceptions. If the font is used by an applications as a web asset, It is responsibility of the application to follow the font license (showing the copyright on a page, for example), but free to download files are a problem -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: Web Assets
On 07/22/2013 11:11 AM, Nicolas Mailhot wrote: Le Lun 22 juillet 2013 17:07, Robert Marcano a écrit : Fonts has licenses, some of them require the license to be shown or the copyright displayed, some fonts has the copyright added to their metadata, I don't find for example that gnu-free-serif-fonts says on it's metadata that is GPL+3 with exceptions. I'd say that when a font requires some communication of licensing downstream, but forgets to put its own license in the font metadata, that's an upstream problem. Upstream can not complain Fedora didn't work hard enough about something it didn't do itself. I disagree, they added the license file to the downloaded package. If you extend that way of thinking, then if executables doesn't have license metadata it isn't my problem that I publish them on my web server It's another thing when the licensing actually prohibits distribution, but we don't have those in Fedora, and people that deploy such fonts in Fedora can write deny apache rules themselves (though providing a sample of tuch a rule would be good) The real problem with publishing things is that if I distribute binaries of many things I must follow the license, some say I need to distribute sources, some say that I need to distribute a copy of the license, etc. Making files downloadable by default adds to the distributor more work (legal) because they must comply with their licenses. So if I put an open service of an Apache licensed web application, I will start distributing fonts with other licenses without ever noticing, for example GPL+3 (nothing against any license, only examples of the things people should care when distributing free/open licensed code/assets) Regards, -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: Web Assets
On Mon, 2013-07-22 at 15:23 +0200, Florian Weimer wrote: On 07/22/2013 12:31 PM, T.C. Hollingsworth wrote: On Mon, Jul 22, 2013, Florian Weimer fwei...@redhat.com wrote: Can we please use a different name, like webdata? The term asset seems to scare some people. Huh? It's a pretty common industry term for static bits used as dependencies for websites. I've never heard of anyone being scared of it. The term has a completely different meaning in the fields of law and accounting. Fortunately we're making an operating system, not prosecuting a case or auditing anyone's accounts, so that does not seem to present a problem. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: Web Assets
On 7/22/13, Adam Williamson awill...@redhat.com wrote: On Mon, 2013-07-22 at 15:23 +0200, Florian Weimer wrote: On 07/22/2013 12:31 PM, T.C. Hollingsworth wrote: On Mon, Jul 22, 2013, Florian Weimer fwei...@redhat.com wrote: Can we please use a different name, like webdata? The term asset seems to scare some people. Huh? It's a pretty common industry term for static bits used as dependencies for websites. I've never heard of anyone being scared of it. The term has a completely different meaning in the fields of law and accounting. Fortunately we're making an operating system, not prosecuting a case or auditing anyone's accounts, so that does not seem to present a problem. Indeed. Also you'll notice that upthread we agreed to change the directory to /usr/share/web-assets just to reduce any potential confusion here. -T.C. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: Web Assets
On Tue, Jul 16, 2013 at 12:54 PM, Jaroslav Reznik jrez...@redhat.com wrote: = Proposed System Wide Change: Web Assets = https://fedoraproject.org/wiki/Changes/Web_Assets Change owner(s): T.C. Hollingsworth tchollingswo...@gmail.com == Detailed description == A standard directory (/usr/share/assets) for static bits that are intended to be delivered to web browsers, such as CSS Frameworks, UI libraries, etc. will be introduced. HTTP daemons in the distribution should make this directory available publicly as /assets. Minor comment: This copy of the text uses /assets ; the wiki page and the proposed policy uses both /assets and /_assets ; this should be cleared up. More importantly, is it OK to just take over a part of the server's URI namespace like this? If we do so, users won't be able to remap the directory to something else without potentially breaking Fedora-packaged applications. Are we satisfied enough that (presumably) /_assets will not collide with existing applications or installations? (Yes, this is already written in the proposal. I still thought it is worth highlighting to make absolutely sure we have this discussion, because changing the path would be very painful with the current proposal.) Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: Web Assets
On Fri, Jul 19, 2013 at 9:51 PM, T.C. Hollingsworth tchollingswo...@gmail.com wrote: More importantly, is it OK to just take over a part of the server's URI namespace like this? snip But _assets/ does have the potential to clash a lot too. So how about _sysassets/? I'm afraid I don't have enough relevant experience in this area to say whether any particular choice is good. I was just trying to attract attention of other people, more knowledgeable than me. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: Web Assets
On Fri, Jul 19, 2013 at 11:56 AM, Miloslav Trmač m...@volny.cz wrote: Minor comment: This copy of the text uses /assets ; the wiki page and the proposed policy uses both /assets and /_assets ; this should be cleared up. More importantly, is it OK to just take over a part of the server's URI namespace like this? If we do so, users won't be able to remap the directory to something else without potentially breaking Fedora-packaged applications. Are we satisfied enough that (presumably) /_assets will not collide with existing applications or installations? (Yes, this is already written in the proposal. I still thought it is worth highlighting to make absolutely sure we have this discussion, because changing the path would be very painful with the current proposal.) I added the underscore based on the suggestion of the httpd maintainer (in the discussion on the packaging list), who suggested /.assets/ or /_packaged_assets/ or so. (And sorry, I missed a couple spots when changing it.) I didn't like the latter because I would really prefer to keep it short. One of the things *I* really want from this is the ability to just type /_assets/jquery/jquery.min.js while developing instead of having to wget it every time or use an evil CDN that logs everything. Us programmers are lazy and shouldn't be forced to type gigantic URLs. ;-) But _assets/ does have the potential to clash a lot too. So how about _sysassets/? It reinforces the point of the directory, it's still pretty short, and seems to used nowhere else [1]. Note that most web apps that ship httpd configs already claim a chunk of the URI namespace, so that part isn't anything new, and prior JavaScript proposals actually called for keeping this tradition and giving every JS library it's own directory. -T.C. [1] https://www.google.com/search?q=inurl%3A%22_sysassets%22 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: Web Assets
On 07/16/2013 06:24 AM, Jaroslav Reznik wrote: ... Additionally the following symlinks will be provided: * /usr/share/javascript - /usr/share/assets/javascript * /usr/share/fonts - /usr/share/assets/fonts (so any Fedora font package can be used as a web font) Not all fonts installed had the same licensing requirement, people install fonts from other places that are not as careful as Fedora with the licenses. It is problematic if someone install a non free font to be used on their desktop application and automatically the font is shared on the network because he installed a web application on their machine If some web applications needs a font it must create the symlink of that font on that package -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: Web Assets
On Thu, Jul 18, 2013 at 1:13 PM, Robert Marcano rob...@marcanoonline.com wrote: Not all fonts installed had the same licensing requirement, people install fonts from other places that are not as careful as Fedora with the licenses. It is problematic if someone install a non free font to be used on their desktop application and automatically the font is shared on the network because he installed a web application on their machine Good point! That's something I hadn't considered. If some web applications needs a font it must create the symlink of that font on that package First of all, regardless of whether or not the shared directory exists web applications are permitted by the draft guidelines to use symlinks or Apache's Alias directive to make web assets available in their namespace. This makes migration a lot easier in many cases. But we don't have to kill of the shared directory just to work around this. We can just whitelist fonts installed from the Fedora package collection and blacklist the rest unless the sysadmin specifically enables them. -T.C. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: Web Assets
I think it's good to establish saner ways to package Javascript and stuff, but this part puzzles me: Additionally the following symlinks will be provided: * /usr/share/javascript - /usr/share/assets/javascript * /usr/share/fonts - /usr/share/assets/fonts (so any Fedora font package can be used as a web font) So all the fonts would be moved from /usr/share/fonts to /usr/share/assets/fonts, and /usr/share/fonts would be replaced with a link? Or did you mean that /usr/share/assets/fonts would be a link, that is, /usr/share/assets/fonts - /usr/share/fonts? Björn Persson signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: Web Assets
On 16/07/13 13:21, Björn Persson wrote: Additionally the following symlinks will be provided: * /usr/share/javascript - /usr/share/assets/javascript * /usr/share/fonts - /usr/share/assets/fonts (so any Fedora font package can be used as a web font) So all the fonts would be moved from /usr/share/fonts to /usr/share/assets/fonts, and /usr/share/fonts would be replaced with a link? Or did you mean that /usr/share/assets/fonts would be a link, that is, /usr/share/assets/fonts - /usr/share/fonts? I believe the second one is what is meant, that is to say: /usr/share/assets/fonts is a link to /usr/share/fonts /usr/share/assets/javascript is a link to /usr/share/javascript I agree that the way it's written makes it sound like the links are the other way, but that wouldn't make any sense. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: Web Assets
On 7/16/13, Tom Hughes t...@compton.nu wrote: On 16/07/13 13:21, Björn Persson wrote: Additionally the following symlinks will be provided: * /usr/share/javascript - /usr/share/assets/javascript * /usr/share/fonts - /usr/share/assets/fonts (so any Fedora font package can be used as a web font) So all the fonts would be moved from /usr/share/fonts to /usr/share/assets/fonts, and /usr/share/fonts would be replaced with a link? Or did you mean that /usr/share/assets/fonts would be a link, that is, /usr/share/assets/fonts - /usr/share/fonts? I believe the second one is what is meant, that is to say: /usr/share/assets/fonts is a link to /usr/share/fonts /usr/share/assets/javascript is a link to /usr/share/javascript Indeed. I agree that the way it's written makes it sound like the links are the other way, but that wouldn't make any sense. I believe I had the order you pass them to `ln` in mind when I wrote that, but now I see that it looks a lot more like the output of `ls`, where it would be reversed. I fixed the wiki to make it clear: https://fedoraproject.org/w/index.php?title=Changes%2FWeb_Assetsdiff=345171oldid=345152 Thanks! -T.C. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
