Re: F23 Self Contained Change: io.js Technology Preview
On Wed, Jul 1, 2015 at 12:41 PM, Stephen Gallagher sgall...@redhat.com wrote: So this was discussed at today's FESCo meeting[1]. Basically, we're not sure that it makes sense to have both interpreters in the distribution, particularly since they are merging back together in the future. Would you be willing to consider just packaging io.js *as* node.js in Fedora 23? Among other things, this would avoid the need to go through additional package reviews, rebuild nodejs-* packages to work with io.js, etc. My limited understanding of io.js is that it is essentially a superset of node.js functionality, This is correct. It has additional features but is broadly compatible with the ecosystem of packages available via npm. so it seems like just moving to this instead of node.js 0.12.0 would make sense. I'm fine with moving the default engine in Fedora 23 to io.js. I'm not so fine with still calling the package we ship io.js in nodejs, since it's not node.js, and we can't be entirely sure the next version of node.js will be greater than the current version of io.js (although I believe that is the plan). Otherwise, will this Change require building NPM packages for iojs -module rather than (or in addition to) nodejs-module? Can this be avoided by running them with an alternatives-provided /usr/bin/node? No. Only binary modules would require special iojs-foo cousins due to the different binary compatibility surface of the two engines. These would be built from the SRPMS that already exist. While binary module SRPMs would require changes, none would be necessary for pure-JavaScript modules. npm does not offer any ability to ship different code when different node.js/io.js versions are used, so it really isn't necessary for us to either. The vast majority of all code in the ecosystem will either Just Work or detect and do the right thing at runtime. We also don't really have the resources to maintain two separate stacks of JavaScript applications, as you're rightly concerned about. Therefore, we do not intend to support shipping different versions of pure-JavaScript nodejs software for different engines, though it of course will be possible to express that a particular package only works/doesn't work with a particular engine via Requires/Conflicts. Note that all of the above is a concern for the SIG even if we only ship io.js in Fedora, as I'd eventually like to get 0.12 into EPEL without leaving 0.10 users in the dust. My intention was to design the binary SRPM build logic such that the same SRPM would build nodejs-foo and iojs-foo cousins on Fedora and nodejs0.10-foo and nodejs0.12-foo cousins on EPEL with no spec changes. So remember that some big changes are coming to nodejs-packaging and binary module SRPMs anyway, the only question is which branches they're landing in. ;-) -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: F23 System Wide Change: jQuery
On Mon, Jun 29, 2015 at 7:37 AM, Vít Ondruch vondr...@redhat.com wrote: If web client had a chance to say hey, i have a /jquery.js in the cache from application A with checksum 'bla', I can reuse it for application B, since it request /jquery.js with the same checksum. Actually just checking checksums could be enough. But nobody implemented it yet I guess. There have been several proposals to add an attribute to script, link, etc. containing a SHA1 hash or so of the file pointed to by the tag. The primary usecase was for browsers to be able to detect if a third-party CDN may be attempting to hijack the site by changing the JavaScript, etc. But, the ability to cache the same files across domains was also touted as a benefit. None of them seem to have gotten very far, though. :-( -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: F23 System Wide Change: jQuery
On Mon, Jun 29, 2015 at 4:18 AM, Stef Walter st...@redhat.com wrote: I think that as described, this change will cause more harm than good. As both an upstream and a packager of Cockpit I am against it in its current form. Please note that this Change has already been implemented as approved by FESCo for a previous Fedora release. It has only been submitted now for final announcement, since it was not complete by the Change Freeze. Turning back now would require blocking packages from the distribution and reverting patches to packages that already depend on js-jquery*. This cannot be done by FESCo merely rejecting this feature. With significant extra work (such as CI) perhaps the change could be less harmful, see below. 1. How will compatibility issues be handled? In the case of Cockpit, jQuery forms part of our future plugin API guarantees. The web application loses control of its dependencies, which normally form a intimate part of the app. How much bandwidth do you have to handle such bug reports? If you depend on a particular release of jQuery, you are free to package it in Fedora. While I am only committing to maintaining the latest 1.x and 2.x versions, it does not stop anyone else from packaging older versions where necessary. The general packaging guidelines permit this and the JavaScript packaging guidelines contain some extra considerations to make this easy. 2. Will Fedora have continuous integration running for all applications it modifies in this way so it can detect breakage? Or should upstream ignore bug reports from Fedora versions where their code has been patched, with regards to jQuery? Fedora Quality Assurance is currently working on a continuous integration system for the distribution and I assure you that I am just as eager to use it as the next person. But yes, right now we don't even currently have the CI resources to check if the kernel we're going to ship in rawhide tomorrow even boots! I'm not sure why this would make upstream ignore bug reports. Does Mozilla ignore bug reports for Firefox on Fedora because we unbundle libraries that they bundle in their upstream build and we don't have CI? I don't think so... 3. Most modern web applications compress and bundle their resources. For example in Cockpit, we: * Gzip jQuery and all other javascript resources. This is a matter for your web application/web server configuration and is not affected by this change. * Bundle them together with other resources and load them together with other scripts in one HTTP response. This is still allowed, though the new guidelines require these be compiled using Fedora-provided sources and not bundled ones. You'll find this going on throughout most applications that care about load time or module loading. 4. Many web applications load jQuery from CDN (although not Cockpit, since it can be used with a non-internet connected server). Do you plan to patch these as well? If not, then why are these left out of the scope of the change? This has always been forbidden, long before the new JavaScript guidelines: Software which downloads code bundles from the internet in order to be functional or useful is not acceptable for inclusion in Fedora (regardless of whether the downloaded code would be acceptable to be packaged in Fedora as a proper dependency). [1] So presumably these are already patched, and this Change just makes that quite a bit easier. :-) -T.C. [1] http://fedoraproject.org/wiki/Packaging:Guidelines#Packages_which_are_not_useful_without_external_bits -- 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: F23 System Wide Change: jQuery
On Mon, Jun 29, 2015 at 6:58 AM, Stephen Gallagher sgall...@redhat.com wrote: That doesn't really help, since the main advantage to this Change Proposal is having a single package to update when fixes are needed, but nearly all web applications take pieces of jQuery out and minify them (taking only the parts they need in order to reduce download and processing time to speed up execution). By making this change, it means that the size of the jQuery files that the user will have to download will be larger, resulting in performance issues. (Since the minification and zipping will happen in the jQuery package and be carrying the complete set of instructions). jQuery really doesn't support being split up like this. It is a common practice with other JS libraries, though, like Modernizr. As I mentioned in my reply to Stef, this is still allowed by the new guidelines, you just have to use Fedora sources not bundled sources when you do it. It also needs to be tracked just like any other static library in the distribution. -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: F23 Self Contained Change: io.js Technology Preview
On Wed, Jun 24, 2015 at 12:56 PM, T.C. Hollingsworth tchollingswo...@gmail.com wrote: On Wed, Jun 24, 2015 at 1:21 AM, Peter Robinson pbrobin...@gmail.com wrote: Why are we even bothering with this when io.js is merging back into node.js so from what I can see is that io.js won't really be around for much longer That's exactly why we're bothering with it. Everything in it will be in the nodejs package someday. Why not get ready now? For the benefit of those not reading the other thread, I might add that io.js also adds support for the PowerPC architecture. That will make it the only provider of /usr/bin/node on that platform. -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: F23 Self Contained Change: Node.js 0.12
On Wed, Jun 24, 2015 at 1:16 AM, Peter Robinson pbrobin...@gmail.com wrote: On Wed, Jun 24, 2015 at 9:05 AM, Vít Ondruch vondr...@redhat.com wrote: Dne 24.6.2015 v 01:37 Jan Kurik napsal(a): -- Update v8 What the version of v8 will be? I am asking, since rubygem-therubyracer is using system version of v8 and I am bit afraid what impact it will have. How is Chromium compatible with the updated Node.js (not user of Chromium though, neither it is in Fedora AFAIK). The other one is mongodb which is very dependent on v8 I think we may be able to port mongodb now, it's been ported to 3.25 at least. If not it can still limp along with v8 3.14 for a couple years. And since the two questions above, I am not sure it should not be system wide change (not mentioning all the nodejs- packages which depends on Node.js). Agreed, this has a much wider impact. I'm looking forward to the upgrade of v8 because the last time I looked the required version for nodejs greatly enhances support for some of the secondary arches. node.js 0.12 is the first to use a v8 that supports aarch64, but io.js will probably work a lot better there. Also, io.js supports PPC upstream now, node.js won't until the codebases are merged. Oh, and I'm also going to turn on MIPS now that there's a budding secondary arch effort, but v8 has supported that forever... -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: F23 Self Contained Change: npm 2
On Jun 24, 2015 2:21 PM, Mat Booth fed...@matbooth.co.uk wrote: On 24 June 2015 at 00:48, Jan Kurik jku...@redhat.com wrote: While npm 2 is a major version number update, it contains little in the way of major changes. Why is this worth more than a sentence or two in the release note beats? You must enjoy the extra bureaucracy :-) I thought this _was_ how you got a sentence or two in the release notes. If I'm mistaken I'll be glad to not waste FESCo's time. ;-) -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: F23 Self Contained Change: io.js Technology Preview
On Wed, Jun 24, 2015 at 1:21 AM, Peter Robinson pbrobin...@gmail.com wrote: Why are we even bothering with this when io.js is merging back into node.js so from what I can see is that io.js won't really be around for much longer That's exactly why we're bothering with it. Everything in it will be in the nodejs package someday. Why not get ready now? Also, the packaging infrastructure needed to build binary modules against iojs and nodejs will also make nodejs010/nodejs012 split packaging possible in EPEL, so a lot of the work needed to get this done is going to be done sooner or later 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: F23 Self Contained Change: io.js Technology Preview
On Wed, Jun 24, 2015 at 6:16 AM, Josef Stribny jstri...@redhat.com wrote: Exactly my thoughts. Plus also introducing another v8 package because of that? Having io.js' v8 as well should actually be a good thing for the distribution. Unlike node.js, which sticks with the same v8 released with a particular version of Chrome forever, io.js only cares about API/ABI compatbility and will accept updates from future Chrome releases as long as they don't break that compatibility. People have been complaining about our ancient v8 for years now, so with this there will a much faster-moving one that will still retain binary compatibility for the life of a Fedora release. -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: F23 Self Contained Change: Node.js 0.12
On Wed, Jun 24, 2015 at 1:05 AM, Vít Ondruch vondr...@redhat.com wrote: What the version of v8 will be? I am asking, since rubygem-therubyracer is using system version of v8 and I am bit afraid what impact it will have. 3.28.73 for nodejs 0.12, 4.2.77.13 for iojs. Looks like rubygem-therubyracer is still on 3.16. :-( I don't mind doing a v8-3.14 compat package for a few Fedora releases, since I'm still going to be maintaining it in EPEL for the forseeable future anyway... How is Chromium compatible with the updated Node.js (not user of Chromium though, neither it is in Fedora AFAIK). Not at all, nor has it been ever, nor will it be ever. Last time I checked spot didn't even bother separating v8 from chromium anymore, it's gotten so bad. :-/ And since the two questions above, I am not sure it should not be system wide change (not mentioning all the nodejs- packages which depends on Node.js). Well the nodejs-* packages are clearly within our SIG, which the Change policy says is okay for Self-Contained Change. The v8 changes do affect two other packages, though. I could adjust the category of the wiki page, or split out the v8 changes from io.js/nodejs012 into a v8 systemwide one. But the change deadline was yesterday, is this still okay? -T.C. On Wed, Jun 24, 2015 at 1:05 AM, Vít Ondruch vondr...@redhat.com wrote: Dne 24.6.2015 v 01:37 Jan Kurik napsal(a): -- Update v8 What the version of v8 will be? I am asking, since rubygem-therubyracer is using system version of v8 and I am bit afraid what impact it will have. How is Chromium compatible with the updated Node.js (not user of Chromium though, neither it is in Fedora AFAIK). And since the two questions above, I am not sure it should not be system wide change (not mentioning all the nodejs- packages which depends on Node.js). Vít -- 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: DNF vs YUM, $pkg, $pkg-mpi, $pkg-openmpi having same provides
On Fri, Jun 19, 2015 at 2:43 AM, Dominik 'Rathann' Mierzejewski
domi...@greysector.net wrote:
On Friday, 19 June 2015 at 01:10, T.C. Hollingsworth wrote:
# a regular expression that paths in an RPM
# must match to trigger the generator
%__openmpi_path ^%{_prefix}/lib(64)/(openmpi|mpich)/.*$
Isn't the '.*$' part at the end of the RE above redundant?
That regular expression matches on the entire path and filename, so
the .* is necessary to match the libwhatever.so.0 at the end of
the path. Without it, the generator would only trigger on the RPM
that owns the directory, which presumably is only the main openmpi
package.
-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: DNF vs YUM, $pkg, $pkg-mpi, $pkg-openmpi having same provides
On Sun, Jun 14, 2015 at 7:28 AM, Sandro Mani manisan...@gmail.com wrote:
Having had a go at this: if bar{-openmpi} requires foo-{openmpi}, filtering
the provides from foo-openmpi and adding an explicit requires to bar-openmpi
on foo-openmpi, this all will result in bar-openmpi depending both on
foo-openmpi as well as foo. Obviously the requires could be filtered as
well, but then things would start really getting cluttered with syntax
overhead...
I was rather thinking, is there an obvious disadvantage in having a
{mpich,openmpi}-find-requires.sh script which encodes the mpi flavour in the
provides/requires? I.e.
libfoo.so.0()(64bit)(openmpi)
Rules to generate such requires/provides:
* Provides: if the path of the library starts with $MPI_LIB, append the
(openmpi) resp (mpich) to the provides string
* Requires: if the path of the scanned object starts with $MPI_LIB and the
required library exists in $MPI_LIB, add (openmpi) resp (mpich) to the
requires string
Overriding the find-requires.sh could be done with a
%{?openmpi_package_header}.
You don't have to override the internal dependency generator. In
fact, you really shouldn't because overriding it also overrides
portions of rpm's multilib handling. :-(
Patching find-(requires|provides) in /usr/lib/rpm is also useless, as
modern versions of rpm use an internal dependency generator instead.
(I think these scripts only still exist in modern Fedora because some
old external srpms hardcode it, overriding the internal dependency
generator.)
You should instead use the new depdendency generator hooks, which are
also quite a bit nicer to work with. All you have to do is create a
file %{_rpmconfigdir}/fileattrs/openmpi.attrs with something like:
# the path to your provides generating script
%__openmpi_provides %{_rpmconfigdir}/openmpi.prov
# the path to your requires generating script
%__openmpi_requires %{_rpmconfigdir}/openmpi.req
# a regular expression that paths in an RPM
# must match to trigger the generator
%__openmpi_path ^%{_prefix}/lib(64)/(openmpi|mpich)/.*$
When this file is present and any file is packaged during rpmbuild
that matches the regular expression in the last entry, the scripts
listed in the first two entries are executed. Just as with
find-(provides|requires) a newline-seperated list of files in the
package is provided on the standard input (but in this case only those
which match the regular expression!) and you provide the Requires or
Provides to add on the standard output.
You can look in your /usr/lib/rpm/fileattrs directory for some hints. :-)
Once you've got it working, you could propose a patch to
redhat-rpm-config to add it universally for all packages. Or, if you
don't want to block on rpm changes and have more freedom to update it
in the future, you could create a new package for it and add it as a
dependency of both openmpi and mpich.
-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: JavaScript SIG?
On Jun 14, 2015 1:54 PM, Pierre-Yves Chibon pin...@pingoured.fr wrote: On Sun, Jun 14, 2015 at 01:45:53PM -0700, T.C. Hollingsworth wrote: On Thu, Jun 11, 2015 at 4:19 PM, Dominik 'Rathann' Mierzejewski domi...@greysector.net wrote: Hello, is there a JavaScript SIG or a mailing list? I've been forced to package several JavaScript code/libraries and I have some questions. However, I couldn't find any trace of a JavaScript SIG or a mailing list. Is there anyone interested in creating/joining one? I think I'd prefer a web-devel list or so. We package CSS frameworks and such too. :-) I requested one in this infra ticket; please chime in if needed: https://fedorahosted.org/fedora-infrastructure/ticket/4790 I like the idea but if there are no more than a hand full of people interested maybe the packaging list would be better suited. But if only a handful of people are interested is it really better to spam the other hundreds who don't care? :-) I don't mind answering questions on any of our lists. But, if some people feel more comfortable asking questions on a smaller topical list, I'm all for that too! -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: JavaScript SIG?
On Thu, Jun 11, 2015 at 4:19 PM, Dominik 'Rathann' Mierzejewski domi...@greysector.net wrote: Hello, is there a JavaScript SIG or a mailing list? I've been forced to package several JavaScript code/libraries and I have some questions. There is now: https://lists.fedoraproject.org/mailman/listinfo/web-devel Please ask your questions! -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: JavaScript SIG?
On Sun, Jun 14, 2015 at 11:48 PM, Matthias Runge mru...@redhat.com wrote: There are quite a few programs out there, solely made for fetching tarballs, zips, git snapshots to place those to a location in file system. A different program for a different target language[...] ...even programs for whole operating systems. Included by default in recent versions of Fedora: http://www.freedesktop.org/software/systemd/man/machinectl.html :-) Thinking of rpm, all those should go away. rpm doesn't solve the same problems these other programs do (and vice versa!) Like allowing easy access to static web packages that really shouldn't require root. If there's going to be one package manager to rule them all, we're going to need something a little better... -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: JavaScript SIG?
On Thu, Jun 11, 2015 at 4:19 PM, Dominik 'Rathann' Mierzejewski domi...@greysector.net wrote: Hello, is there a JavaScript SIG or a mailing list? I've been forced to package several JavaScript code/libraries and I have some questions. However, I couldn't find any trace of a JavaScript SIG or a mailing list. Is there anyone interested in creating/joining one? I think I'd prefer a web-devel list or so. We package CSS frameworks and such too. :-) I requested one in this infra ticket; please chime in if needed: https://fedorahosted.org/fedora-infrastructure/ticket/4790 Thanks! -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: [EPEL-devel] cut off for el6?
On May 11, 2015 12:00 PM, ToddAndMargo toddandma...@zoho.com wrote: Hi All, Just out of curiosity, is the cut off date for EPEL 6 support the same as the cut off date for Red Hat support of EL6? It is the same as the cut off for RHEL Production support, which is currently scheduled on November 30, 2020 for EL6. After that date there will be no new builds for EPEL6. However, the repository will remain available indefinitely without further updates. -T.C. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
libuv soname bump
I have just updated libuv in F22 and rawhide to the 1.x series (1.4.0 to be exact) which introduces a proper soname upstream that is bumped from the previous Fedora package. libuv currently only has two dependencies in Fedora. One dependent, moarvm, has already been rebuilt. The other, nodejs, will use the newly introduced compat-libuv010 package for the life of the Fedora 22 release. It will be updated to the new 0.12 release for F23, which can use the new libuv. This compat package will then be retired. No new packages in Fedora should depend on compat-libuv010. Please instead use the main libuv package, as many changes released in the v1.x series were focused on making the library more useful to consumers besides nodejs. Thanks, -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: [EPEL-devel] Source tarball not found?
On Thu, Jan 29, 2015 at 9:30 PM, Dave Johansen davejohan...@gmail.com wrote:
I'm trying to build llvm after applying a patch and I keep getting an error
about lldb-3.4.src.tar.gz not being found, but that file has been there for
previous builds and fedpkg says it has already been uploaded. Any ideas on
what's wrong?
The build.log can be found at:
https://kojipkgs.fedoraproject.org//work/tasks/8365/8778365/build.log
It's probably because you have:
%if %{with lldb}
Source3:%{downloadurl_base}/lldb-%{version_base}%{?prerel}.src.tar.gz
%endif
and %{with lldb} evaluates to false during SRPM creation time, so the
tarball is not included in the SRPM and therefore isn't available to
the binary build later on.
Just remove this conditional. You should always include all sources
in the SRPM regardless of what's actually enabled in the build, so
other people who just have the SRPM can turn on options if they want
without having to download extra sources.
-T.C.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: Koji build failure: noarch vs. arch?
On Thu, Jan 29, 2015 at 8:43 PM, Jerry James loganje...@gmail.com wrote:
I have been assured that %__isa_bits is always defined, except for
noarch builds:
https://lists.fedoraproject.org/pipermail/devel/2014-October/203331.html
That's what this problem looks like to me: something has erroneously
concluded that this is a noarch build. I just don't know what that
something is, or why it reached such a conclusion. Thanks,
createSRPMfromSCM operations are always noarch and can performed on
any primary architecture.
In general, you should always use %{?foo} syntax for anything that
will be parsed at createSRPMfromSCM time (e.g. in %if conditionals and
anything above %prep), unless of course it is defined with %global in
your spec file. There's a lot of stuff that's missing during SRPM
creation time...
-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
EPEL Testing documentation
Somebody asked me about one of my updates sitting in epel-testing today, and I noticed that we didn't have a nice page like we do for Fedora [1] that explains how the testing repository and bodhi, etc. work to point them to. So I forked the Fedora documentation and modified it to apply to EPEL instead: https://fedoraproject.org/wiki/EPEL/testing Hopefully others will find this useful. If I missed anything or you have anything useful to add, please use your wiki powers! Thanks, -T.C. [1] https://fedoraproject.org/wiki/QA:Updates_Testing ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL [epel7] mongodb depency is broken as v8 package is not available on epel7
On Thu, Aug 7, 2014 at 9:20 PM, Zhiwei Zhu z_...@wargaming.net wrote: I failed in installing monodb on CentOS 7 with following error: “v8-3.14.5.10-11.el7.x86_64.rpm FAILED http://yum/epel/7/x86_64/v8-3.14.5.10-11.el7.x86_64.rpm: [Errno 14] HTTP Error 404 - Not Found0% [ ] 0.0 B/s |0 B --:--:-- ETA Trying other mirror. Error downloading packages: 1:v8-3.14.5.10-11.el7.x86_64: [Errno 256] No more mirrors to try. ” It seems only these package of v8 are available on the epel downloading site: v8-3.14.5.10-8.el7.x86_64.rpm and v8-3.14.5.10-9.el7.x86_64.rpm. No v8-3.14.5.10-11.el7.x86_64.rpm is available. The current version of of v8 on the Fedora master mirror is indeed 3.14.5.10-11: https://dl.fedoraproject.org/pub/epel/beta/7/x86_64/repoview/v8.html Judging by the URL from your error, you seem to be using a local mirror that is not properly synced, since it has metadata for the updated v8 package but is missing the RPM itself. Please contact the administrator of the mirror so that they can fix the issue. In the meantime, you can work around the issue by manually installing the v8 RPM from the above URL. -T.C. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
mock error in koji: No such file or directory: '%{buildroot}/etc/mtab'
A koji rawhide build [1] just failed with: INFO: Mock Version: 1.1.39 Start: chroot ['fedpkg', 'sources'] Start: device setup Finish: device setup Finish: chroot ['fedpkg', 'sources'] ERROR: [Errno 2] No such file or directory: '/var/lib/mock/f21-build-2179813-398918/root/etc/mtab' Traceback (most recent call last): File /usr/sbin/mock, line 306, in module def do_buildsrpm(config_opts, chroot, options, args): File /usr/sbin/mock, line 579, in main chroot.chroot(args, options) File /usr/lib/python2.7/site-packages/mockbuild/backend.py, line 832, in chroot self._setupFiles() File peak.util.decorators.rewrap wrapping mockbuild.backend._setupFiles at 0x01FED050, line 3, in _setupFiles def _setupFiles(self): return __decorated(self) File /usr/lib/python2.7/site-packages/mockbuild/trace_decorator.py, line 70, in trace result = func(*args, **kw) File /usr/lib/python2.7/site-packages/mockbuild/backend.py, line 552, in _setupFiles mockbuild.util.touch(item) File peak.util.decorators.rewrap wrapping mockbuild.util.touch at 0x01FA7B18, line 3, in touch def touch(fileName): return __decorated(fileName) File /usr/lib/python2.7/site-packages/mockbuild/trace_decorator.py, line 70, in trace result = func(*args, **kw) File /usr/lib/python2.7/site-packages/mockbuild/util.py, line 77, in touch fo = open(fileName, 'w') IOError: [Errno 2] No such file or directory: '/var/lib/mock/f21-build-2179813-398918/root/etc/mtab' It might have something to do with yesterday's util-linux update in rawhide? [2] But /etc/mtab still shows up on that build's filelist in koji, so I'm not sure why it's missing in the buildroot. Thanks! -T.C. [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=7105815 [2] http://koji.fedoraproject.org/koji/buildinfo?buildID=541536 -- 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: EPEL RHEL 7 Workstation optional channel in Fedora's Koji
On Tue, Jun 3, 2014 at 1:29 AM, Simone Caronni negativ...@gmail.com wrote: On 2 June 2014 16:46, T.C. Hollingsworth tchollingswo...@gmail.com wrote: I'd suggest filing a bug in bugzilla first, explaining the pain this causes downstream addon repositories like EPEL. For all we know the -devel subpackage is only missing in Server due to some oversight. Opened this one, hope it's correct: https://fedorahosted.org/rel-eng/ticket/5915 Well actually I meant to ask RHEL release engineering to add jansson-devel to the Server repository along with the main jansson package. It seems kind of silly to have the main package in Server and the -devel package in Workstation. You can file a bug with RHEL rel-eng here: https://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%20Enterprise%20Linux%207component=relengversion=7.0 Of course, supporting Workstation in general would be very nice, so your other ticket is warranted, but I think getting this particular problem fixed on the RHEL side would still be a good idea regardless of the outcome of that. -T.C. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL RHEL 7 Workstation optional channel in Fedora's Koji
On Mon, Jun 2, 2014 at 1:59 AM, Simone Caronni negativ...@gmail.com wrote: Hello, I was looking to build a package on epel7 that is relying on jansson-devel. The -devel subpackage is generated as normally from the main jansson package, but in case of epel7 the resulting rpm is included in the Workstation-optional channel: http://ftp.redhat.com/redhat/rhel/rc/7/Workstation-optional/x86_64/os/Packages/ Have these packages being left out intentionally or not? Is there any chance to see these packages added in Koji? Otherwise building for epel7 can get really complicated. I'd suggest filing a bug in bugzilla first, explaining the pain this causes downstream addon repositories like EPEL. For all we know the -devel subpackage is only missing in Server due to some oversight. -T.C. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: Correct way to unpush an update?
On Thu, May 29, 2014 at 5:35 PM, Richard Shaw hobbes1...@gmail.com wrote: Ok, so I don't get bit again by bodhi letting me do something I shouldn't... Do I just unpush the update but NOT delete it? I have a newpackge update and one of the three packages has a problem so obviously I don't want to push it to stable. Once I get the email that's it's been successfully unpushed, so I just create a new update with the two packages that are fine and a new build of the problem package? You can just edit the bodhi update and replace the broken build with the fixed one. Then bodhi will unpush the bad one and push the good one at the same time in the next compose, and the other two packages won't be affected at all. -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: F21 System Wide Change: Web Assets
On Fri, May 16, 2014 at 3:39 AM, Vít Ondruch vondr...@redhat.com wrote: Is it true actually? Last time I was checking the Ruby packages contained different/modified version of upstream JS files. AFAICT they're both fine. rubygem-uglifier includes the main uglify-js via git submodules: https://github.com/lautis/uglifier/tree/master/vendor And rubygem-coffee-script-source is just a browser build of coffee-script. The main coffee-script package will be providing such a build soon. I'll file bugs with concrete patches when everything's ready. -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: F21 System Wide Change: Web Assets
On Wed, May 14, 2014 at 6:45 AM, Miloslav Trmač m...@volny.cz wrote: This is usefully detailed, but it’s not always clear what parts need to be done by “other developers” (to use the template wording), particularly the two “will need to be modified” references to Ruby/Java/Node.js . The known affected packages are listed in the Dependencies section of the change wiki, but for some more detail: These are issues have been prioritized since they're cases of JavaScript running locally on Fedora systems, not just being transmitted over HTTP. The FPC is much more concerned about bundling in these cases, and our guidelines have never actually permitted JS to be bundled in these instances. I think all the nodejs packages are all already taken care of by Jamie Nguyen and/or me at this point, except for coffee-script. (Will look at that one soon.) This just involved making sure there were pure JavaScript packages available so e.g. rubygem-uglifier can use a copy of uglify-js that doesn't require nodejs. There are only two ruby packages affected: rubygem-uglifier and rubygem-coffee-script. All that's required for them is dropping the .js files they bundle and replacing them by a symlink to the copy in the new js-* packages. I'll file bugs for them with patches once I've fixed coffee-script. Haven't really looked at Java too hard. I need to go through all the packages that depend on rhino and unpack their .jar files and see what wonders lie within... Unfortunately you can't symlink within a .jar file so these will likely need the static exception in the new guidelines. :-( Fixing them doesn't win us very much until we have some better tracking there, so these are kind of low priority. Will try and do more poking and update the wiki page over the weekend. (Also, I think we have everything we need for jQuery now, so I should be able to finish that up this weekend too. :-) Thanks, -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: Need instructions with packaging
On Sat, May 3, 2014 at 4:35 PM, Adrian Soliard asoli...@fedoraproject.org wrote: I really don't understand the situations of the packages Fedora has a policy prohibiting the inclusion of emulators in the package collection: Most emulators (applications which emulate another platform) are not permitted for inclusion in Fedora. The rule of thumb to follow is: If it requires ROMs (or image files in any format) of copyrighted or patented material to be useful (and the owners of those copyrights and patents have not given their express written permission), then it's not permitted. [1] Operating systems like Windows and Fedora have licenses that permit them to be run using virtualization software such as KVM/QEMU, therefore it's okay to ship such emulator software in Fedora. On the other hand, the license for Mac OS X expressly forbids virtualization on other platforms, therefore it would *not* be okay to ship an Mac emulator in Fedora. So, is there an operating system whose license permits it to be run using dynamips? If so, contact Fedora Legal [2] and provide evidence so they can reconsider whether it's okay to include. If not, it's simply not suitable [3] for Fedora. -T.C. [1] https://fedoraproject.org/wiki/Packaging:LicensingGuidelines#Emulators [2] https://lists.fedoraproject.org/mailman/listinfo/legal [3] https://fedoraproject.org/en/about-fedora#freedom -- 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: JavaScript bundling (was Re: F21 System Wide Change: Cockpit Management Console)
On Fri, Apr 11, 2014 at 8:19 AM, Peter MacKinnon pmack...@redhat.com wrote: Is there circumstances whereby new reviews can be approved without FPC exception if those assets have not yet been packaged under the new web asset packaging guidelines and layout? There's currently a blanket exception for jQuery: https://fedorahosted.org/fpc/ticket/408#comment:9 To my knowledge, there is no such exception for any other libraries. Feel free to request one though; FPC will likely approve and I'll add my support just as I did with jQuery. :-) -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: F21 System Wide Change: Ruby193 in SCL
On Mon, Apr 14, 2014 at 7:16 AM, Jaroslav Reznik jrez...@redhat.com wrote: Rails depends on exact v8 version, which means v8 3.14 must have also their own SCL as part of the SCL. Stupid question: what in rails depends on v8 exactly? The only thing that Requires v8 in Fedora besides nodejs and mongodb is rubygem-therubyracer, and that FTBFS for the F20 mass rebuild and my recent v8/libicu mini-mass rebuild: http://koji.fedoraproject.org/koji/packageinfo?packageID=14305 I'm in touch with someone from IBM to get PPC support for v8/nodejs (which means no more random failures when nodejs packages get sent to EPEL PPC builders, yay!), which requires finally switching to gyp from scons (which has been deprecated for years now), and so far I've been ignoring ruby in my preliminary work [1] on this since it has been broken for other reasons. If you're going to continue to need rubygem-therubyracer, please fix it so I can make sure we don't break it. (Or at least rebuild it when the time comes. It probably still works in F20 since nothing changed v8-wise since F18, but I wouldn't be surprised if it's completely busted in rawhide right now.) Thanks, -T.C. [1] http://copr.fedoraproject.org/coprs/patches/v8-gyp/ -- 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: Five Things in Fedora This Week (2014-03-18)
On Tue, Mar 18, 2014 at 1:50 PM, Matthew Miller mat...@fedoraproject.org wrote: Reposting from http://fedoramagazine.org/?p=1231, for those of you who prefer email to the web. :) Perhaps these should be syndicated to Planet Fedora, for those of us who don't mind the web? Actually, I swear I've seen Fedora Magazine posts there before, but this post definitely isn't there. :-( -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
fedpkg new-sources not working
Something seems to be wrong with 'fedpkg new-sources' here. :-( % fedpkg new-sources libuv-v0.10.25.tar.gz Uploading: 329a61fa3c30acf46efef1a9221b2054 libuv-v0.10.25.tar.gz Could not execute new_sources: Lookaside failure: (60, Peer's certificate issuer has been marked as not trusted by the user.) I tried running 'fedora-cert -n' to get a new cert and even 'rm -rf ~/.fedora* fedora-packager-setup' to make sure nothing local was messed up but it still failed. % rpm -q fedpkg fedpkg-1.15-1.fc20.noarch Thanks! -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: fedpkg new-sources not working
On Wed, Feb 19, 2014 at 8:37 PM, Kevin Fenzi ke...@scrye.com wrote: I've seen this a few times and it was something wacky in ~/.pki/ can you try a 'mv ~/.pki ~/.pki.sav' and see if it works? That did the trick. Thanks for the _very_ quick help. :-) -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: yum upgrade creates /var/run/nologin
On Tue, Feb 18, 2014 at 6:15 PM, Andrew Lutomirski l...@mit.edu wrote: This has happened twice now. I run 'yum upgrade' and, all of a sudden, /var/run/nologin exists. It contains a message telling me that my system is still booting. This is, of course, a lie -- the system has been up for quite a while, *and I'm logged in with the screen locked*. This is rather impolite. /var/run/nologin isn't owned by any package, so I have no clue where to file the bug. This is: https://bugzilla.redhat.com/show_bug.cgi?id=1043212 It's supposed to be fixed by the latest systemd update in updates-testing. -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: web-assets-httpd stuck in limbo?
Sorry, left the list out when I sent this before. Here it is for everyone, with updates... On Wed, Jan 15, 2014 at 10:59 PM, T.C. Hollingsworth tchollingswo...@gmail.com wrote: Sorry, I kind of dropped the ball on this. :-( On Wed, Jan 15, 2014 at 8:27 PM, Adam Williamson awill...@redhat.com wrote: I've been looking at more webapp unbundling stuff over the last couple of days (as anyone following my G+ feed probably noticed...) and I just noticed that web-assets-httpd is still not being built. The last note was back in August: * Fri Aug 16 2013 T.C. Hollingsworth tchollingswo...@gmail.com - 4-1 - temporarily disable httpd stuff while we're waiting on sorting out the directory that leads me back to a devel@ thread from around that time which in turn links to a discussion where we were hoping to come up with something compatible with Debian: http://lists.alioth.debian.org/pipermail/pkg-javascript-devel/2013-August/005888.html http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=553173 but both that thread and that bug report seem to have petered out, with no movement. Is there discussion going on about this in some other forum, still? Or is it sort of in limbo? Yeah that went nowhere really fast. For those not willing to sift through the old threads , the responses from the Debian folks were: * One suggestion to use http://localhost/usr/share/javascript/ instead. (Umm, no.) * Insistence that we sit around and wait until the FHS is updated. (Can I get a special badge for submitting a feature for Fedora 40?) * Another individual thought that all web authors are stupid for wanting to use fancy fonts and that I am wasting my time. (He might be right about that last bit... :-P) * A suggestion to use the term libraries instead of assets (This came up on devel also, but I'm really not a fan of calling random JS/CSS/icon spaghetti libraries. I think it's more confusing than it is helpful, but if everyone's really in love with it, whatever.) * A desire to dot-prefix the directory (e.g. http://localhost/.sysassets instead of / _sysassets) it might get implemented as a symlink with some http daemons. (I'm cool with this.) I have unbundling of Roundcube's tiny_mce via an alias to /usr/share/javascript/tiny_mce working fine, but it requires the httpd .conf snippet that allows access to /usr/share/javascript , which is part of web-assets-httpd... Yeah that's blocking a few things. I need to drop into the FPC meeting tommorrow to ask about nodejs stuff anyway so I'll ask if they're okay with just proceeding with the directory dot-prefixed instead or if I need to go through the whole song-and-dance first. (I'm kind of itchy about implementing something different from the approved guidelines even though it's just a period...) Thursday went like the rest of my week and I didn't get a chance to pop in to the FPC meeting. :-( I'm going to just go ahead and file a ticket for a guidelines update, there are a couple of other issues that have come up since they were passed that need to be fixed anyway. I'm double-checking all the past discussions for issues that cropped up for things to fix, if there are others that you want addressed please speak up now. :-) On another track, the web assets change seems to suggest the use of symlinks for unbundling things as a strategy to avoid divergence from upstream in cases where they aren't being nice and providing a proper variable for the path name that we can change or whatever, but I think any attempt to use symlinks to unbundle things that have previously been bundled is going to run head-on into the 'rpm can't convert directories to symlinks' problem. symlinks might be a better approach than Aliases, now I come to think of it, since it's all well and good shipping httpd config files but it doesn't help anyone using another web server...but I can't really use a symlink approach without a good solution to the directory-to-symlink problem, which we still don't seem to have. Grr, I guess I'll look back over that thread and write up a packaging draft for that because we badly need it. So I came up with this: https://fedoraproject.org/wiki/User:Patches/PackagingDrafts/Symlink_Workarounds Suggestions welcome, and please feel free to just edit obvious stuff directly in the wiki. :-) FPC ticket is at: https://fedorahosted.org/fpc/ticket/385 I guess the cleanest approach would be to try and get a patch upstreamed which specifies a variable for the path to the bundled stuff and have our package set that variable accordingly...but that would require web-assets-httpd also. I will comment more on this after I've read everything you wrote in the bug. Though from the bits and pieces I picked up skimming over the bugmail on my phone earlier, I think may need to break into the bottle of whiskey I usually reserve for patching V8 first. ;-) -T.C. -- devel mailing list devel@lists.fedoraproject.org
Re: web-assets-httpd stuck in limbo?
On Wed, Jan 15, 2014 at 10:42 PM, Remi Collet fed...@famillecollet.com wrote: Notice: the current httpd.conf in git is broken because for alias order which need to be fixed. Yeah I believe there are still a couple of things you mentioned in our conversation in August that still need to be fixed. I'll make sure they're all addressed soon. -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: libwebp soname bump
On Wed, Jan 1, 2014 at 4:31 PM, Sandro Mani manisan...@gmail.com wrote: python-webm-0.2.2-2.fc20.src.rpm Fixed in python-webm-0.2.2-5.fc21 http://koji.fedoraproject.org/koji/buildinfo?buildID=487623 Thanks, -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: really stop really commits (really!)
On Wed, Dec 18, 2013 at 2:17 AM, Vít Ondruch vondr...@redhat.com wrote: Sorry, but that is not accidental comment. First of all, we are working with git. I have local clone of git repository and I am free to commit whatever I consider to be committed. And I assume that you know that you can later edit/squash/drop these commits as well. The question is if I push these changes. An actually yes, I push such changes into 'private' branch. For example, I am working on packaging Ruby 2.1.0 for Fedora and I am doing random updates of .spec file to random SVN revisions as time permits. If anybody cares enough to build and try Ruby 2.1.0 from such branch, (s)he is free to do so, but some level of expertise is expected. Missing source tarball in lookaside cache should not be issue in this case. Actually it is good think, because it would be just waste of space. Yeah, topic branches make total sense, and I'd make sure this doesn't bother those. I also use `fedpkg` on repos that don't point to real Fedora packages, so I'd definitely take those into account too. Personally I just think doing it at push time is bad UX. I often push the same change to several branches at once, and I'd rather it yell when I do the commit to rawhide so I can fix it then rather than having to go back and amend the commit and resync all the branches. Also, I prefer to separate the bump version commit from unrelated spec changes (e.g. a simple rebasing of a patch belongs in the same commit as the version bump, fixing something like unversioned docdirs does not), and `fedpkg new-sources` doesn't play well with `git rebase --interactive` so if you forget that and don't get warned till push time, it's either a giant pain to put it in the same commit or you have to just do an annoying bump sources commit. But if people are really in love with having this done at push time instead, I can probably find a way to let packagers pick their poison. -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: really stop really commits (really!)
On Tue, Dec 17, 2013 at 3:41 AM, Lukas Zapletal l...@redhat.com wrote: On Mon, Dec 16, 2013 at 03:10:08AM -0700, T.C. Hollingsworth wrote: I do commit locally although I probably don't want push the snapshot sources, because I update them later, when time comes. +1 The more I think about this argument the more this whole thing bugs me. Pretty much every open source project in the world has as a hard and fast rule that you shouldn't commit stuff that doesn't even compile to master or stable branches. I don't see how Fedora dist-git should be any different. If you commit a spec file to dist-git that does not contain a corresponding source in the lookaside cache, there's no way any other soul in the world can build it. Yeah, you can try and regenerate the source file yourself, but that's a pain. There are very good reasons why we have a lookaside cache and koji does not just use `spectool`... If it's worth pushing the commit where everyone can see it in the git history, somebody else besides you should be able to build the package at that point. Which means that the corresponding source tarball for _every_ commit belongs in the lookaside cache, regardless of whether or not you intend to actually push that build to a Fedora release. So the more I think about it, the more I think Vit's accidental suggestion that this be instead implemented as a git pre-recieve hook, which is enforced on the pkgs.fp.o server side and is *not* optional, is a good idea. We should not allow commits to Fedora dist-git that very obviously will never successfully build in koji. -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: really stop really commits (really!)
On Sun, Dec 15, 2013 at 4:01 AM, Richard W.M. Jones rjo...@redhat.com wrote: It would be nice also to check that the sources file contains the Sources listed in the spec file, since I often bump the version number and forget to upload the new sources. Yeah. I actually have a little shell function that runs `spectool`, a tarball stripping script if one exists, and then `fedpkg new-sources` together because invariably I forget some part of that. ;-) Actually we really should check that both SourceN and PatchN are in one of either git or the lookaside cache. There's valid reason for SourceNs to be in git (.desktop files, systemd units, etc.) and for PatchNs to be in the lookaside cache (software that distributes updates via patches like the kernel or vim). So now the script checks both Sources and Patches and makes sure they're both somewhere koji can find them later. -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: really stop really commits (really!)
On Mon, Dec 16, 2013 at 12:45 AM, Marcin Juszkiewicz mjuszkiew...@redhat.com wrote: Does it handle %autosetup use as well? Now it does. :-) -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: really stop really commits (really!)
On Mon, Dec 16, 2013 at 1:11 AM, Martin Stransky stran...@redhat.com wrote:
There are some cases when we need it (sources taken as a snapshot from
git/cvs)
Huh? The sources have to be either in git or in the lookaside cache
for koji to find them later. I'm not sure how it could get this
wrong?
patches applied by different way.
How else can you apply patches listed on PatchN lines? It already
covers %patchN, %{patches}, and now %autosetup. If there's something
else, I'd really like to know.
-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: really stop really commits (really!)
On Mon, Dec 16, 2013 at 1:59 AM, Mathieu Bridon
boche...@fedoraproject.org wrote:
The kernel package uses a custom-defined ApplyPatch macro, for example.
It still uses %{patches} though, so it would pass.
-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: really stop really commits (really!)
On Mon, Dec 16, 2013 at 2:02 AM, Martin Stransky stran...@redhat.com wrote:
I mean the upstream source check. It may not work if you use generated
source files [1].
No way am I doing an upstream source check in a git pre-commit hook!
I'm not waiting for v8 to be downloaded and hashed every time I commit
to it, and firefox would be no fun either. ;-)
I would very strongly object to any sort of git pre-commit hook that
required network access of any kind. The whole point of git is that
you're supposed to be able to commit offline!
No, this just checks the sources file to make sure you've uploaded to
the lookaside cache.
For instance we use this construction in xulunner:
sed -e 's/__RH_NSPR_VERSION__/%{nspr_version}/' %{P:%%PATCH0}
version.patch
%{__patch} -p2 -b --suffix .nspr --fuzz=0 version.patch
which may confuse the check script.
This is fine, since %PATCH0 is used somewhere. Its regex is
deliberately stupid and broad.
-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: really stop really commits (really!)
On Mon, Dec 16, 2013 at 2:29 AM, Vít Ondruch vondr...@redhat.com wrote:
It prevents even local commits if I am not wrong.
Yeah, to only do it when commits are pushed would mean to do it as a
pre-receive hook on the dist-git server, which makes things
significantly more complicated.
Plus aborting right when you commit so you can just fix it real quick
is much nicer than aborting it after you've already entered your SSH
passphrase and then having to go back and amend the commit, etc.
I do commit locally
although I probably don't want push the snapshot sources, because I update
them later, when time comes.
This should happen rarely enough that having to use `git commit
--no-verify` to bypass it wouldn't be too much trouble?
I think that in general it's reasonable to expect that anything
committed to a dist-git clone is intended to be pushed upstream to
dist-git. If you want to play around, use a topic branch. If it's
really a one-off, just bypass the check that one time.
http://pkgs.fedoraproject.org/cgit/rubygem-activeresource.git/tree/rubygem-activeresource.spec?h=f18#n86
http://pkgs.fedoraproject.org/cgit/rubygem-activerecord.git/tree/rubygem-activerecord.spec?h=f18#n95
These are fine, since they use %{PATCH0}. I guess I should have
mentioned it checks for both uppercase and lowercase forms, sorry.
-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
General fedpkg git hook support [was: Re: really stop really commits (really!)]
On Fri, Dec 13, 2013 at 8:35 PM, Rahul Sundaram methe...@gmail.com wrote: On Fri, Dec 13, 2013 at 8:42 PM, T.C. Hollingsworth wrote: To prevent this from happening in the future, I wrote a little git pre-commit hook to help out, which I figured I'd share with you all: http://patches.fedorapeople.org/patchcheck.py Would it be possible to hook it up with fedpkg by default so that all Fedora packagers get this functionality? Sure. `fedpkg clone` could easily be taught to install hooks. Not sure what to do about existing clones. (I guess we could provide a `fedpkg install-hooks` or just require a new clone if you want the new magic.) If fedpkg (actually I'd say pyrpkg, I suppose RHEL maintainers would find this useful too ;-) were to have hook support, I'd much prefer to add some general support for git hooks to it and include this one as a default one, rather than just this one specifically. So it would just symlink a simple script in each clone that executes everything in some drop-in directory. (/usr/lib/rpkg/hooks/pre-commit or so? If we do it in rpkg do we need a Fedora-specific dir too? Maybe $XDG_CONFIG_DIR/rpkg/hooks/pre-commit also so packagers can add their own stuff easily?) This way rpkg/fedpkg can ship some common obvious ones and there's an easy way for others to add additional ones that aren't of interest to the entire packaging community. Also, I wonder if there are use cases for other hooks. Pre-commit is definitely useful, but some of them ([prepare-]commit-msg, update [which runs prior to a push]) could possibly be relevant. Might be overengineering, but I'd hate to go through all the work to enable pre-commit hooks just for someone to come up with an awesome use-case for another one three months later. Anyway, I'd be happy to cook up a patch for this if it would be something dgilmore is interested in merging. -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: EPEL epel7 planning and processes
On Fri, Dec 13, 2013 at 9:42 AM, Kevin Fenzi ke...@scrye.com wrote:
On Thu, 12 Dec 2013 18:36:48 -0700
T.C. Hollingsworth tchollingswo...@gmail.com wrote:
Any chance an automatic build could be tacked on the end of that?
Seems like it would be pretty easy to add to your wiki script and
would save packagers a little manual effort. Of course, then you have
to worry about build order and such so it might not be worth the
trouble... :-(
Yeah, build order, if they want to adjust the packaging before
building, if they are ready to build then, etc, etc.
So, IMHO, a auto build is not a good idea.
Ack.
(need to decide if the git branch name is el7 or epel7).
el7 please like the existing two? Is there any particular reason
for it to be different?
We might go with epel7. The reason is that some people seem to have
confusion about the branches being 'elN'. Oh, this is rhel6 No, it's
epel6, not rhel.
Overall pretty minor either way.
Yeah, I have some shell functions and little scripts that would have
to be adjusted, but they'd need to be adjusted to {6,7} anyway, so
whatever.
-T.C.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL epel7 planning and processes
On Fri, Dec 13, 2013 at 9:42 AM, Kevin Fenzi ke...@scrye.com wrote: I wouldn't think so no. I would say all epel7 packages MUST use systemd units. I don't know the state of the systemd rpm macros in rhel7, we would need to figure that out. Hopefully they are all there. +1000 from me. Won't be sad to see the death of those things. ;-) Now that you mention it though, I wonder if we should bother with the systemd-sysv-convert stuff [1] for EPEL7? It got dropped from the Fedora guidelines (again, because it's been three years...) and Lennart seemed to think it was a bad idea in general, but the utility is indeed shipped in the RHEL 7 beta. IMHO, we should not allow sysvinit stuff at all. It's just a hassle and everyone should have already migrated anyhow. Well, systemd-sysv-convert is an upgrade thing that lets you transfer enabled/disabled status from your old initscripts to your shiny new systemd units. It's useful even in a mystical initscript-free future. That being said, if you're the type of person who runs RHEL, you're probably a.) paranoid about automatic _anything_ b.) using ansible/puppet/whatever to manage that kind of thing anyway and/or c.) going to want to go over your enabled services with a fine-toothed comb post-upgrade regardless. So it's probably not worth bothering about. In the past, this would have been handwaved away by saying RHEL doesn't support upgrades, but rumor has it that this won't be the case this time around. ;-) Yeah, I worry about that. We may want to say that EPEL doesn't support them. I mean, upgrade path from epel6 is something we could easily check and ask people to keep working, but there's lots of packages I suspect where upgrades are a lot more complex... Perhaps we should say it might work, but if not, sorry If it breaks you get to keep both pieces ought to be Fedora's fifth foundation. :-P I think that EVR upgrade path issues should be fixed, because seriously how hard is it to fix that? We really don't provide any sort of assurance on upgrades beyond that even in Fedora. If something changes config file format or whatever, you're generally expected to deal with it yourself. I don't see how EPEL would be any different. -T.C. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
really stop really commits (really!)
Invariably when adding a patch to a spec, often I forget some detail, whether it be adding the %patchN macro to %prep or `git add`ing the patch. It would seem I'm not alone, either. A Google search for e.g. site:https://lists.fedoraproject.org/pipermail/scm-commits/ really apply patch returns tens of thousands of results! ;-) To prevent this from happening in the future, I wrote a little git pre-commit hook to help out, which I figured I'd share with you all: http://patches.fedorapeople.org/patchcheck.py It verifies that: - all patches are committed to git - all patches are applied in %prep - no unexpanded %patch macros exist in %prep If any of the above checks fail, the commit is aborted. To use it, download it somewhere, make it executable, and symlink $clone/.git/hooks/pre-commit to it. If you already have a pre-commit hook of some sort, you can instead just run that script in it and abort on a non-zero exit code. Hopefully some of you find it useful. -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: EPEL epel7 planning and processes
On Thu, Dec 12, 2013 at 5:07 PM, Kevin Fenzi ke...@scrye.com wrote: Several folks have been asking about epel7 and we should get the ball rolling now that there is a public rhel7 beta. I'd like to propose a similar plan to the one we used for epel6, which the possible exception of branching method. For epel6 we asked maintainers who didn't want to branch their packages from epel5 into epel6 to add a 'dontbranch' file to cvs (at the time) and then we mass branched all the rest of the packages into epel6. This was good for adding in a lot of packages quickly, but resulted in some packages that to this day never got a build (where maintainers decided they didn't want to build/support, etc). Yeah, opt-in sounds like a much better idea. :-) So, I was thinking this time perhaps we could: * Setup a wiki page that contains all packages that are in rhel7beta. (for reference) * Setup another wiki page for epel7 * As soon as there is a group of packages there, Branch them. * Keep the wiki page open until we are out of beta/rawhide mode and folks can mass add packages there for branching, process once a day or something. (this would avoid overloading scmadmins if someone wanted to branch a bunch of packages). Thoughts or better ideas for branching? Any chance an automatic build could be tacked on the end of that? Seems like it would be pretty easy to add to your wiki script and would save packagers a little manual effort. Of course, then you have to worry about build order and such so it might not be worth the trouble... :-( The rest of the process would include: * Setup git scripts to allow epel7 branches. (Default would be branch from f19) Excellent. F19 is exactly what I'd want for all my packages. :-) (need to decide if the git branch name is el7 or epel7). el7 please like the existing two? Is there any particular reason for it to be different? * Create gpg keys and add to signing server/verify pages. * Branch epel-release and add keys, etc. * Add koji tags and build targets, etc. Will the koji tags for EPEL7 be dropping the dist- prefix like Fedora did some time ago? * Add bugzilla version for bugs. * Probibly some wiki help to update things * Setup nightly cron job that composes epel7 in rawhide mode. * Don't depend on packages being signed until we exit rawhide mode. * Move from rawhide - normal mode some time after rhel7 final is out (with 6 it was a few months after). Can anyone think of other things we need to do? Any other general questions or comments ? Thanks for getting the ball rolling on this quickly. :-) -T.C. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: Reopening: Q: webfonts:
On Mon, Dec 2, 2013 at 8:33 AM, Petr Vobornik pvobo...@redhat.com wrote: This solution is much nicer and can be used by other font packages as well. Here's the new package: https://bugzilla.redhat.com/show_bug.cgi?id=1036754 Very awesome, thanks! I'll sponsor you and review. :-) Luckily, I pushed off the web assets stuff for F21, so I can now add embedding to the list of things to check and file bugs for when I do that for the licensing metadata. I'm going to be doing that real soon now, so if there are any other issues that all the fonts in the distro need to be checked for, please speak up soon! I'll also ask FPC to add a mention of this to the font guidelines so future fonts added to the distribution will have this bit set correctly. -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: [pkgdb2] call for testers, bug reports and RFE
On Wed, Nov 13, 2013 at 6:52 AM, Pierre-Yves Chibon pin...@pingoured.fr wrote: - The idea of owner of a package disapear. There are only maintainers on which one of them appears to be the dedicated point of contact for this package (ie: the person that gets the bugs in bugzilla). Koji also has a notion of the owner of a package. It treats owners specially in at least two ways: 1. The owner of a package is sent e-mails for all actions in the buildsystem regarding packages they own, regardless of who initiated them. 2. Only the owner of a package is permitted to tag or untag all builds for that package. Co-maintainers may only tag or untag builds they submitted. #1 can hopefully be fixed by the famed fedmsg-e-mail gateway, so it can probably be safely ignored. #2, not so much. You rarely need to manually mess around with koji tags, but when you do need it, you *really* need it. ;-) Do you all plan to fix koji to permit all comaintainers to perform tag operations on a package as part of enabling SIG maintainership? If not, the point of contact terminology wouldn't be very accurate. -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: [pkgdb2] call for testers, bug reports and RFE
On Fri, Nov 15, 2013 at 6:31 PM, Dennis Gilmore den...@ausil.us wrote: Not at all true. Any one can tag a build into an unlocked tag such as f20-updates-candidate tags such as f20-updates-testing are protected and can only be tagged into by an admin in koji. Koji has no concept of acls, It doesn't know about co-maintainers or treat them any differently. Weird, I couldn't make koji untag a package from rawhide once and had to bug the owner to do so. I thought this was why, but I guess it was just PEBKAC. ;-) Sorry for the noise. -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: PATH has /bin before /usr/bin in upgraded rawhide
On Sat, Oct 26, 2013 at 4:10 PM, Sandro Mani manisan...@gmail.com wrote: Hi, I just noticed that my rawhide installation, which was originally installed when F18 was rawhide in summer 2012 and upgraded since, has PATH=/bin:/usr/bin:/usr/local/bin:/usr/local/sbin:/usr/sbin:/home/sandro/.local/bin:/home/sandro/bin On a fresh rawhide installation, I get PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/home/sandro/.local/bin:/home/sandro/bin So, the order of /bin /usr/bin /usr/local/bin is reversed. Who is screwing up the order? - /etc/profile, /etc/bashrc and /etc/profile.d/* are identical between the old and the new installations - strings /bin/bash | grep /bin gives me the same output in both cases - my .bashrc and .bash_profile are harmless (i.e. PATH=$PATH:$HOME/.local/bin:$HOME/bin) Since it's not coming from /etc/profile or our .bashrc, I wonder if it's coming from our desktop environment setup or something. Let's check locally, then ssh into the same system and see if it's the same. [tc@zathras]~% echo $PATH /usr/lib64/qt-3.3/bin:/usr/lib64/ccache:/bin:/usr/bin:/usr/local/bin:/home/tc/bin:/usr/local/sbin:/usr/sbin [tc@zathras]~% ssh localhost Last login: snipped [tc@zathras]~% echo $PATH /usr/lib64/qt-3.3/bin:/usr/lib64/ccache:/usr/local/bin:/usr/bin:/home/tc/bin:/usr/local/sbin:/usr/sbin Nope, notice that locally /bin is in $PATH, but when I ssh into the same system, it isn't. Where's it coming from? % grep PATH /usr/bin/startkde # in case we have been started with full pathname spec without being in PATH case $PATH in *) PATH=$bindir:$PATH; export PATH; % grep bindir /usr/bin/startkde bindir=`echo $0 | sed -n 's,^\(/.*\)/[^/][^/]*$,\1,p'` if [ -n $bindir ]; then qbindir=`$bindir/kde4-config --qt-binaries` qdbus=$qbindir/qdbus $bindir|$bindir:*|*:$bindir|*:$bindir:*) ;; *) PATH=$bindir:$PATH; export PATH;; Hmm, that looks like it might be it. So I added an `echo $bindir /tmp/bindir` to that script to see if it's not just a red herring. % cat /tmp/bindir /bin Yup, that's it. https://bugzilla.redhat.com/show_bug.cgi?id=1023999 Might want to check your desktop environment's start script too, if it's different. -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: Retiring libeio
On Sat, Sep 7, 2013 at 6:03 PM, T.C. Hollingsworth tchollingswo...@gmail.com wrote: Please shout if you need it for anything and would like to take it over, otherwise I'll retire it in a week or so. Nobody even so much as whispered, except to say not me either!, so libeio is now retired. -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: Review swaps: perl-Parse-DebControl, devscripts, debian-keyring, ubuntu-keyring, jetring + question: where to install keyrings?
On Thu, Sep 19, 2013 at 9:37 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: This has the downside that it'll add the dependency on gnupg, which is not great. Maybe simply create a keyrings-filesystem package with this directory and have whoever installs keyrings depend on it. If gnupg owns the directory, but your package doesn't need gnupg to function, your packages are permitted to co-own the directory with gnupg: https://fedoraproject.org/wiki/Packaging:Guidelines#The_directory_is_owned_by_a_package_which_is_not_required_for_your_package_to_function A -filesystem package is a little cleaner, so it'd be nice to pursue that option if the gnupg maintainers are amenable. But, there's no need to block on either them or FPC to get this done since directory co-ownership is explicitly permitted in this instance. -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: Retiring libeio
What a mess! I sure do seem to be attracted to bundled library issues, like insects are attracted to shiny lights. :-( On Sun, Sep 8, 2013 at 12:48 AM, Michael Schwendt mschwe...@gmail.com wrote: On Sat, 7 Sep 2013 18:03:48 -0700, T.C. Hollingsworth wrote: I adopted libeio back when Node.js still bundled it to aid in the unbundling effort, but upstream fixed the bundling problem here by no longer using libeio for anything. That explains a bit more! libeio is bundled within perl-IO-AIO at Fedora http://search.cpan.org/~mlehmann/IO-AIO-4.18/AIO.pm and is built as a private AIO.so lib. I might add that this Perl module also shares the same author as libeio itself. I've tried to find out why there haven't been any libeio releases to download, although it's at version 4.18 already. The home page says it's Beta. The cvs snapshot contains doc files that refer to libev (that one is at 4.15), which is a separate package (also at Fedora). The source also bundles ecb.h, which refers to libecb from the same author. That's libecb at Fedora. Upstream has never released tarballs that I'm aware of. The libeio package generates tarballs from release tags in CVS. There actually seems to be a 4.19 tag in CVS now, though IO::AIO is still on 4.18. Sorry I never noticed the libecb bundling. I could push a patch to fix it right now, but I have absolutely no way of testing it since nothing uses libeio and it doesn't have a test suite. :-( -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: Retiring libeio
On Mon, Sep 9, 2013 at 6:49 AM, Paul Howarth p...@city-fan.org wrote: I'd be quite happy if someone would take perl-IO-AIO off my hands. My only interest in it is as an (optional) backend and test dependency of perl-AnyEvent, which I co-maintain - I picked it up when a previous maintainer orphaned it. If someone is keen to look after the bundling issue, I'll be happy to hand over the package. Otherwise, it looks like a lot of hassle and I'll probably end up orphaning it and letting nature take its course. I took a look at it, and the perl module does an #include libeio/eio.c (not .h), so there's no way to link it to libeio normally without a lot of work. :-( Probably best to let it die if nobody has any interest in it. -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
Retiring libeio
I adopted libeio back when Node.js still bundled it to aid in the unbundling effort, but upstream fixed the bundling problem here by no longer using libeio for anything. It's now conflicting with a different eio, used by Enlightenment. Since most other distros ship the Enlightenment version as libeio.so.1 instead of this libeio, and nothing in Fedora uses it anymore, I'd like to retire the libeio package so Enlightenment packaging can proceed without gross unnecessary hacks. Please shout if you need it for anything and would like to take it over, otherwise I'll retire it in a week or so. -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 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: Bundled Flash
Thanks for tackling this! On Fri, Aug 23, 2013 at 4:03 AM, Adam Williamson awill...@redhat.com wrote: So, tinymce has a 'media' plugin which lets you embed media in HTML you're editing with it. If it thinks the media might need playing with Flash, it'll generate HTML that tries to use a Flash player - moxieplayer.swf - to play it (sometimes as a fallback from HTML5). Just nuking moxieplayer.swf doesn't stop tinymce generating HTML that looks for it, so that's not really the way to go. But I think I found a way to patch the plugin not to try and use moxieplayer.swf and just to spit out nice clean HTML instead. I also bumped tinymce to the latest upstream release, since it hadn't been bumped since 2011 and was *ancient*. Testing of this is very welcome. I've sent the build to Rawhide and F20 for now. roundcubemail is on this list because it bundles tinymce, basically. I think it should be trivial to replace its bundled tinymce with the system-wide one. I'm going to test installing the updated and de-Flashed tinymce along with a roundcubemail build patched to use a system-wide tinymce on my own server and check that it works okay that way. If it does, I'll submit that combination to all Fedora releases. I suspect many other packages on the list may be there because they're bundling tinymce. In most cases, unbundling it ought to be trivial; it seems like the 3.x series of tinymce maintained compatibility well, so I think it shouldn't be a problem to use system-wide tinymce. But I'll look into it some more tomorrow. askbot is the only package right now using t. he systemwide tinymce. I'm assuming ask.fp.o runs on EL, but I'm not sure. Any infra folks reading this, would you be interested in checking ask.fp.o behaves sensibly with de-Flashed tinymce 3.5.8? I don't think the Flash issue should matter at all because it looks like askbot customizes the tinymce editor widget somewhat and doesn't actually expose the media plugin _at all_. I don't see why it wouldn't work with tinymce 3.5.8 - in fact it ought to work better - but we should probably check. Random note: patching minifed javascript is a giant fucking PITA, and we can't edit the 'source' javascript for tinymce and re-minify it because Fedora doesn't have yuicompressor - https://bugzilla.redhat.com/show_bug.cgi?id=745515 . Sigh. Ideally, we would port dependent applications to TinyMCE 4. It looks like 3.x is ancient; it hasn't had a commit in over a year. Version 4 uses a nodejs- based build system so we can do minification properly according to the shiny new guidelines. The differences don't look too crazy: http://www.tinymce.com/wiki.php/Tutorial:Migration_guide_from_3.x I can package up what's needed (including a new-world compliant tinymce package) if someone can verify that porting is possible. (Or I'll try and find time to look myself sometime soon.) BTW, this is why we want to start requiring minification in %build, so we'll be able to patch JS sanely once again. ;-) -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: Bundled Flash
On Fri, Aug 23, 2013 at 5:40 AM, Adam Williamson awill...@redhat.com wrote:
All the upstream projects I found seemed to consider jumping to tinymce
4 a rather large move. Debian packages 3 and 4 as separate packages. I
rather think we should do the same rather than just pretend they're the
same thing and we'll be easily able to migrate things from one to the
other.
I should have known it couldn't be that easy. :-/
Or, at least let's get a tinymce 3.5.8 built and all things that bundle
3 un-bundled before we start worrying about 4. :)
So, after some teeth gnashing, I've confirmed roundcube can indeed be
relatively easily unbundled to use a system 3.5.8 package. It needs the
spellchecker plugin which is a separate package in Fedora, which tripped
me up for a while.
However, to do this, I run into the fucking
convert-a-directory-to-a-symlink old chestnut, and RPM/yum just isn't
having it. Following the breadcrumbs all over this list and Bugzilla I
came up with this %pretrans:
%pretrans -p lua
-- changed dir to symlink in 0.9.3-1, workaround RPM issues
path = %{roundcubedir}/program/js/tiny_mce
if posix.readlink(path) then
os.remove(path)
end
But yum/rpm just won't wear it. 'yum update mynewroundcubepackage.rpm'
fails with a file conflict just like it does if there's no %pretrans at
all. I was able to test my unbundling simply by manually removing and
reinstalling the roundcube package, but I can't push it out anywhere
unless I can get a %pretrans which yum/rpm will be happy with. Anyone?
https://bugzilla.redhat.com/show_bug.cgi?id=975909 may be involved, I
guess.
I believe that's the code for the symlink-directory direction. The state of
the art for directory-symlink seems to be:
https://bugs.launchpad.net/rpm/+bug/633636/comments/3
as linked to in bug:
https://bugzilla.redhat.com/show_bug.cgi?id=447156
And it's god awful. How much beer do I have to buy Panu to make this work
properly?
You could just say screw anaconda installs and just use `rm -rf`. Though I
tried that once, in *EPEL* even, and it only took a week for someone to
complain. :-(
roundcubemail ships tinymce
as /usr/share/roundcubemail/program/js/tiny_mce and hooks into it rather
untidily; it seems rather cleaner to just do 'ln
-s /usr/share/tinymce/jscripts/tiny_mce
%{buildroot}%{roundcubedir}/program/js/tiny_mce' in the spec rather than
write a messy patch for roundcube to change where it looks for tinymce,
which would probably need constant updating.
Any chance you could just use an Alias in the apache config? Then you can just
delete the directory and not muck around with making yum happy.
-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: Bundled Flash
On Fri, Aug 23, 2013 at 5:44 AM, Adam Williamson awill...@redhat.com wrote:
Just to cover my ass, this kind of symlinking is explicitly allowed by
the draft new JavaScript policy:
Regardless, web applications may want to make subdirectories of
%{_jsdir} available under their own directory via aliases or symlinks
for compatibility purposes or to eliminate needless deviation from
upstream.
https://fedoraproject.org/wiki/User:Patches/PackagingDrafts/JavaScript
so I reckon it's fine to do it, so damnit yum, let me.
Ugh, this bug never crossed my mind when I wrote that. I'll definitely make
sure that section grows a big red box warning about 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: Bundled Flash
On Fri, Aug 23, 2013 at 11:26 AM, Adam Williamson awill...@redhat.com wrote: On Fri, 2013-08-23 at 06:36 -0700, T.C. Hollingsworth wrote: Any chance you could just use an Alias in the apache config? Then you can just delete the directory and not muck around with making yum happy. Doesn't seem to work. Seems like it's just ignored: if I set it and move tiny_mce/ away, no tinymce. If I leave it set but also put the tiny_mce directory in place on the filesystem (by symlink or not), tinymce works. I don't actually have any idea whether PHP is supposed to respect the Apache aliases or whether it's looking at the 'real' filesystem, but it seems to be b). Ugh sorry, I didn't realize PHP had its tentacles in there. The Alias trick only works when it's just a script tag. -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: Bundled Flash
On Fri, Aug 23, 2013 at 2:15 PM, Michael Scherer m...@zarb.org wrote: So what we found on irc : Since rpm first create the files for the new rpm that is installed, then remove the files that should be removed still present from old rpm and not in the new one, we fix the issue by waiting until the directory is removed to create the symlink. Looking at https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Scriptlet_Ordering , we need something after step 10. snip code While we're sharing hacks...did you know that rpm doesn't move symlink targets when they change in some instances, too? I can't make a simple minimal test case reproduce this to save my life, but it sure does blow up in the real world: https://bugzilla.redhat.com/show_bug.cgi?id=997978 Thank $DEITY with nodejs I can divine the correct symlink targets from a json file on the filesystem, so I can fix up ~20 packages in one scriptlet: http://pkgs.fedoraproject.org/cgit/nodejs-inherits.git/tree/nodejs-inherits.spec#n43 If I weren't so lucky I would have had to add scriptlet gunk to ~20 packages instead of just that one. :-( Now, this method has a huge problem, we cannot downgrade the package to the bundled version. There is no script that would remove the symlink in time, ie before step 3 of https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Scriptlet_Ordering Everything that is run is from the new package to install, ie the old rpm that we want to downgrade to. So since we would need to fix the old rpm to have it downgradable, that's a bit hard. The %pretrans hackery previously recommended also suffers from the same flaw. I'm not sure there's anything we can do about it. :-( Another issue is the %ghost, we cannot really check the symlink is still the same. Maybe there is some better syntax for 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: Bundled Flash
On Fri, Aug 23, 2013 at 2:28 PM, Adam Williamson awill...@redhat.com wrote: And, T.C., we probably need the Web Assets policy to set some rules/guidelines on how best to achieve unbundling: should we always try to patch the upstream to find the 'official' location of the shared resource on Fedora? Should we always do it with symlinks or aliases where possible? Should we allow either approach depending on circumstances? I'd like to unbundle tinymce from roundcubemail and moodle, but it's probably best to decide 'best practice' first then do it in line with that. Definitely either approach depending on circumstances. I specifically didn't define a best practice because I didn't think there was going to be one. In some cases there might be a global config file that lets you point the path to the Fedora-y location, so it's easier to patch that one file than to mess around with the directory-symlink madness. In other cases it's hardcoded in nine million places all over the codebase, so the symlink approach starts to look much nicer. :-) That's also the reason why a global httpd path is coming (unfortunately not till Fedora 21 now), because in some instances a server path is easier to config than a filesystem path. Basically, do whatever makes you least likely to pull all your hair out in the process. :-) Sooner or later there's going to be a best practices (emphasis on the plural) document that describes all these techniques nicely, but I wasn't expecting people to jump into unbundling with both feet quite so quickly. ;-) -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
Review swap request: web-assets
Hi! Would someone be willing to trade me a review for: https://bugzilla.redhat.com/show_bug.cgi?id=997678 It's dead simple at the moment: it just provides a couple directories and RPM macros. Later on it will grow some httpd magic but that's on hold until Fedora 21 since we're still sorting that out with Debian and it's past Change Freeze. Thanks! -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: Bundled Flash
On 8/23/13, Adam Williamson awill...@redhat.com wrote: On Fri, 2013-08-23 at 17:12 -0700, Toshio Kuratomi wrote: One further thought here: https://fedoraproject.org/w/index.php?title=Packaging:JavaScript#Static_Inclusion_of_Libraries Taking a static library approach is also allowed. This can save packagers from some of the headaches you mentioned (like some things detecting the absolute path to libraries) but introduces the static libraries headaches (having to rebuild when the library package updates in order to get the changes that occurred there.) Not sure if we want to recommend that just to get around the directory-symlink issue but it is an option. Using the system copy really would be a lot cleaner, in some cases - I'd really hope we can do it and not have to resort to static inclusion :/ +1 That exception is intended mainly for two specific classes of issues: 1. Minified JS libraries that have always bundled other libraries. For instance, jQuery has bundled sizzle.js since time immemorial, and unbundling it and requiring every webapp to add an extra script tag for sizzle.js would be a complete nightmare. 2. Webapps that use only parts of ginormous frameworks like dojo and build and minify their own JS file that only has the stuff they need. At least one of the maintainers of such a package would prefer to have to keep up with updates in a static copy rather than force clients to load gobs of JS that isn't used, and that makes a lot of sense. It's for case #2 that the exception got expanded to be allowed for webapp packages, but it's really not intended to just permit bundling to continue when you can just as easily unbundle. I'll look at tightening I don't consider the rpm symlink bug to be a good enough reason to invoke this exception, however annoying it is. It'll be a lot easier in the long run to just figure out the necessary spec goop to get it converted, and then the maintainers of packages dependent on tinymce will never have to worry about it again. ;-) -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: Bundled Flash
On 8/23/13, T.C. Hollingsworth tchollingswo...@gmail.com wrote: It's for case #2 that the exception got expanded to be allowed for webapp packages, but it's really not intended to just permit bundling to continue when you can just as easily unbundle. I'll look at tightening Bah, that was supposed to say: I'll look at tightening the language there in a future update so this doesn't get used as a blanket excuse to bundle when we really shouldn't be bundling. -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: Bundled Flash
On 8/22/13, Adam Williamson awill...@redhat.com wrote: Looked into this a bit further this afternoon. Both swfupload and plupload are open source projects, but Wordpress ships compiled binaries in its 'source tarball', there is no build system in there for them at all. Wordpress posts the sources for them on its site, though: http://wordpress.org/download/source/ The Debian package includes the sources for them in its source tarball in a 'missing sources' directory - you can grab http://ftp.de.debian.org/debian/pool/main/w/wordpress/wordpress_3.5.2 +dfsg-1.debian.tar.xz and see the 'missing-sources' directory with a README explaining the situation. The package documentation indicates that they possibly actually rebuild the .swfs from this source during package build, but I'm not expert enough at the Debian package format to be able to see where and how exactly this is done. But we should probably harmonize with them on this. That Debian package doesn't build anything. :-( Plupload's flash directory taunts you with a .sh script, but it needs this thing to build: https://flex.apache.org/ And of course that allegedly open source framework is chock full of binary goop from Adobe. Shame on you, Apache. Not sure if Debian's done anything about the Silverlight bits, yet. That's bundled too. Can *we* do anything about Silverlight? Last time I checked Moonlight was no bueno for Fedora (and now I guess it's dead upstream anyway). What were the people who made this thing thinking, anyway? What sort of crazy person has Silverlight installed but not Flash?? There's someone that uses Netflix but not YouTube??? -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: Bundled Flash
On 8/15/13, T.C. Hollingsworth tchollingswo...@gmail.com wrote: It's come to my attention that a number of packages contain Flash (.swf) files, but absolutely none of them have BuildRequires on a free software Flash toolchain, nor do any of them seem to be shipping the source for these files. :-( It has never been permissible to included prebuilt files of this nature in Fedora [1], and FPC unequivocally stated during today's meeting that they have no interest in making an exception for this. Please remove this prohibited content from your packages, or ensure that any included .swf files are built from source using a free software toolchain like `swfc` during the %build phase. A list of affected packages sorted by owner is included below, and I'll be filing bugs for these soon. Bugs are now filed: https://bugzilla.redhat.com/show_bug.cgi?id=WebAssets-BundledBinaries The query ran for this includes Flash files (.swf), Flash source files (.fla), Silverlight files (.xap), and Shockwave Director (.dcr) files. No new packages were surfaced by the expanded query but quite a few that have .swf files turned out to be bundling some of the more exotic kind too. The list of files found is included with the bug, of course. Anyone who has fixed their packages in Rawhide already won't get a bug. If you did get a bug despite having fixed your package please double-check it, as these files still appear as of last night's Rawhide compose. There was at least one I thought someone already said they had fixed. -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
Bundled Flash
It's come to my attention that a number of packages contain Flash (.swf) files, but absolutely none of them have BuildRequires on a free software Flash toolchain, nor do any of them seem to be shipping the source for these files. :-( It has never been permissible to included prebuilt files of this nature in Fedora [1], and FPC unequivocally stated during today's meeting that they have no interest in making an exception for this. Please remove this prohibited content from your packages, or ensure that any included .swf files are built from source using a free software toolchain like `swfc` during the %build phase. A list of affected packages sorted by owner is included below, and I'll be filing bugs for these soon. -T.C. [1] https://fedoraproject.org/wiki/Packaging:Guidelines#No_inclusion_of_pre-built_binaries_or_libraries brummbq owncloud echevemaster python-django-ckeditor hicham gnash iarnell mojomojo itamarjp bugzilla jdetaeye frepple jnovy texlive jsteffan graphite-web ke4qqq php-simplepie lbazan django-typepad limb gallery2 limb moodle limb roundcubemail miminar wt mkrizek yourls ngompa tinymce orion ckeditor remi glpi remi php-ezc-Graph remi wordpress robert phpMyAdmin salimma hop sharkcz wxPython sharkcz zabbix sundaram evas-generic-loaders sundaram lastuser thias python-nevow topdog dojo toshio loggerhead toshio python-docutils yuwang python-django-tinymce -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Bundled Flash
On Fri, Aug 16, 2013 at 6:12 AM, Jon Ciesla limburg...@gmail.com wrote: I just fixed these and gallery3, no need to file BZs, unless you'd like to for tracking. Additional testers welcome! Nah, I'll rerun the query in the script that files BZs later on. Although if one of you ends up crippling your package by doing this (e.g. you just end up with an old-school uploader instead of a fancy HTML5 one), please let me know and I'll set up a tracking bug for that. I'd like to work on getting those fixed upstream eventually. -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
Bundled Flash
It's come to my attention that a number of packages contain Flash (.swf) files, but absolutely none of them have BuildRequires on a free software Flash toolchain, nor do any of them seem to be shipping the source for these files. :-( It has never been permissible to included prebuilt files of this nature in Fedora [1], and FPC unequivocally stated during today's meeting that they have no interest in making an exception for this. Please remove this prohibited content from your packages, or ensure that any included .swf files are built from source using a free software toolchain like `swfc` during the %build phase. A list of affected packages sorted by owner is included below, and I'll be filing bugs for these soon. -T.C. [1] https://fedoraproject.org/wiki/Packaging:Guidelines#No_inclusion_of_pre-built_binaries_or_libraries brummbq owncloud echevemaster python-django-ckeditor hicham gnash iarnell mojomojo itamarjp bugzilla jdetaeye frepple jnovy texlive jsteffan graphite-web ke4qqq php-simplepie lbazan django-typepad limb gallery2 limb moodle limb roundcubemail miminar wt mkrizek yourls ngompa tinymce orion ckeditor remi glpi remi php-ezc-Graph remi wordpress robert phpMyAdmin salimma hop sharkcz wxPython sharkcz zabbix sundaram evas-generic-loaders sundaram lastuser thias python-nevow topdog dojo toshio loggerhead toshio python-docutils yuwang python-django-tinymce -- 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: Bundled Flash
On Thu, Aug 15, 2013 at 2:02 PM, Orion Poplawski or...@cora.nwra.com wrote: Thanks. Turns out ckeditor also had a raw .fla file. I don't know if any package would have a .fla without a .swf, but it might be worth checking for. Thanks for pointing that out! .fla files are source files, so it's not strictly against the guidelines to include them. But, they're pretty useless to end users. ;-) So, here's the list of packages that contain .fla files: brummbq owncloud echevemaster python-django-ckeditor ke4qqq php-simplepie limb gallery3 orion ckeditor sundaram evas-generic-loaders topdog dojo -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: Bundled Flash
On Thu, Aug 15, 2013 at 3:46 PM, Dan Mashal dan.mas...@gmail.com wrote: Forgive me if I sound rude and correct me if I'm wrong, but arent the free versions of Flash pretty useless as well? We're talking about SWF compilers here, not players. There are free compiler tools that work just fine for certain applications. -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 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 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: EPEL libmodplug npm
On Wed, Aug 7, 2013 at 5:09 AM, Stephen Gallagher sgall...@redhat.com wrote: On 08/05/2013 04:25 PM, alexus wrote: I can't update these packages... either I'm doing something wrong or perhaps package is broken? .. Error unpacking rpm package npm-1.3.3-1.el6.noarch error: unpacking of archive failed on file /usr/lib/node_modules/npm/man: cpio: rename This error usually means that the old file it's replacing doesn't match the one that's supposed to be there. Did you manually install a newer copy of npm at some point? Actually, this one is my fault. This went to a symlink to a directory and eventually became unneeded as a result of work on bug 953051 [1], but I guess the symlink slipped back in on a revert. :-( A fixed version is building now. -T.C. [1] https://bugzilla.redhat.com/show_bug.cgi?id=953051 ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL libmodplug npm
On Mon, Aug 5, 2013 at 1:25 PM, alexus ale...@gmail.com wrote: I can't update these packages... either I'm doing something wrong or perhaps package is broken? Definitely the latter. :-) snip --- Package libmodplug.x86_64 0:0.8.7-1.el6.rf will be updated This package is from RPMforge not EPEL, so you'll have to report a bug there. --- Package npm.noarch 0:1.2.17-5.el6 will be updated This one's my fault. It should be fixed in npm-1.3.6-4.el6: https://admin.fedoraproject.org/updates/npm-1.3.6-4.el6 -T.C. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
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 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 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
npm license change
npm, the Node.js package manager, has changed license [1] from a modified version of the MIT [2] to the Artistic 2.0 [3] license effective with version 1.3.6. This version is now in Rawhide and queued for updates-testing in Fedora 19 and 18 as well as EPEL 6. Fedora Legal believes both licenses to be GPL-compatible so this shouldn't cause anyone trouble. On the contrary, using a standard license instead of a custom-written one should only make peoples' lives easier. ;-) -T.C. [1] https://github.com/isaacs/npm/commit/c32391b1efd70a861cebc77e0cc784a46af5de21 [2] https://fedoraproject.org/wiki/Licensing/MITNFA [3] http://www.perlfoundation.org/artistic_license_2_0 -- 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: EPEL Port oat package into
On Jul 29, 2013 8:31 PM, Wei, Gang gang@intel.com wrote: Thanks for the answer, it makes sense to me. No problem. :-) I forgot to mention that the flip side of this is that those are also the only channels that EPEL is forbidden to conflict with. You're free to package the dependencies you need in EPEL if you so desire. I'm not sure if that's possible in your case since JBoss is a behemoth, but I figured I'd mention it anyway. ;-) -T.C. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: Following MPI packaging guidelines
On 7/26/13, Antonio Trande anto.tra...@gmail.com wrote:
'examples' directory contains arch dependent programs, I can't
packaging them in /usr/share.
In that case you could consider shipping them in an -examples
subpackage if most consumers of the main package won't find them
useful. Also, you could use %{_libexecdir} if you want the paths to
these binaries to be the same on 32 and 64 bit systems. Both are
optional though.
This .spec should be fine:
http://sagitter.fedorapeople.org/MUMPS/MUMPS.mod2.spec
The -common subpackage should be BuildArch: noarch but otherwise it
looks good.
-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: Following MPI packaging guidelines
Hi! On Jul 24, 2013 9:04 AM, Antonio Trande anto.tra...@gmail.com wrote: I'm editing .spec file of MUMPS package to conform it to the MPI packaging guidelines (http://fedoraproject.org/wiki/Packaging:MPI). I have a modest experience in this particular case so I need some suggestions. This is initial .spec file of MUMPS: http://pkgs.fedoraproject.org/cgit/MUMPS.git/tree/MUMPS.spec This is that adjusted according to the MPI packaging guidelines: http://sagitter.fedorapeople.org/MUMPS/MUMPS.mod.spec As you see, I have created the packages - - MUMPS-openmpi - - MUMPS-openmpi-devel - - MUMPS-common Upstream provides illustrative test programs showing how MUMPS can be used in examples/ directory; Can I package these programs in 'MUMPS-common' package ? They are located in dedicated directory in /usr/share. Yes, but usually examples are shipped in /usr/share/doc via %doc, not directly in /usr/share. 'MUMPS-openmpi' contains all versioned libraries; I don't know if it's correct or the package must be named 'MUMPS-openmpi-libs' No, a -libs subpackage would only be necessary if the main MUMPS-openmpi package contained more than libraries. Should all .h files be in a '-headers' subpackage ? Now, they are 'MUMPS-openmpi-devel'. No, -devel is the correct location for the headers. This phrase in MPI guidelines is little clear for me: Software that supports MPI MUST be packaged also in serial mode [i.e. no MPI], if it is supported by upstream. What does mean serial mode ? :) -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, 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 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
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
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
