TIL that there are around a thousand packages
in Fedora that include a file named jquery.js... [1]
Anyway it is good to see efforts to tackle these kinds of problems
with the Javascript and Web Assets Guidelines. :)
I want to ask if the packaging of grunt and jquery
blocks current package reviews of packages that bundle jquery.js?
Or can they proceed for now until jquery is actually packaged in Fedora?
Jens
ps It is going to be a long cleanup process to fix all those packages with bundled files.
[1] https://fedoraproject.org/wiki/Changes/Web_Assets#Web_application_packagers

Hi
I am working on porting Fedora for AArch64 architecture. This means
patching many packages and during that time I noticed lot of checks for
32/64-bit architectures.
Most common one is:
%global something 32
%ifarch x86_64 ppc64 s390
%global something 64
%endif
Which can be now replaced to simple:
%global something %{__isa_bits}
And this works fine in Fedora 19 and beyond (including RHEL 7). There
are also some other variations of 32/64-bit checks which could be converted.
Can use of %__isa_bits be somehow announced/suggested to developers?
Would cut amount of patching needed for each new architecture.

Hi all,
currently I'm working on Kbarcode, which is under review:
https://bugzilla.redhat.com/show_bug.cgi?id=1001799
The current version is 3.0.0b3. No problem so far, but the next one will
probably be the final 3.0.0. This way I don't get a proper upgrade path. Just
tested with a dummy package versioned as 3.0.0b2 which I tried to update with
3.0.0:
# rpm -Uvh mario-3.0.0-1.fc19.noarch.rpm
Preparing...
################################# [100%]
package mario-3.0.0b3-1.fc19.noarch (which is newer than
mario-3.0.0-1.fc19.noarch) is already installed
What to do in this case? I would add
Obsoletes: %{name} = 3.0.0b3
Is this OK or have to do some other fixes? Maybe I could change the package
version of the current beta release to 2.9.99?
Best Regards,
Mario

Hi,
I've prepared a spec for the CAJUN JSON API - it is a build dependency
for the new reSIProcate with WebRTC support
Nobody has replied to the review request however, have I missed some
detail in the request[1]?
Regards,
Daniel
1. https://bugzilla.redhat.com/show_bug.cgi?id=1012337

This is mostly just me reporting things were decided and things that the FPC
seems to have decided on so I'm going to go forward with the draft assuming
that this is how things are going to be. I'll send out separate emails for
the other things discussed so we can discuss them in isolation.
== Partial approval ==
FPC approved this portion of the draft:
https://fedoraproject.org/wiki/User:Toshio/SCL_Guidelines_(draft)#SCL_App...
minus the SCL Retirement section. The reason for not approving that section
is that it's not finalized yet. That section will likely be voted on at
next week's meeting so if you have comments on improving it, please let me
know (IRC or an {{admon/question|| Comment}} in the draft will assure that
I see your comment. This mailing list will let others participate in
a discussion. I recommend doing both :-)
== Filesystem Location ==
A straw poll was taken about the filesystem location of SCLs. A few FPC
members were willing to use /opt but others were heavily opposed to it.
Everyone was okay with using /usr/scl (or the plural form /usr/scls). So
I think that needs to become the scl root dir (is that the right term?) for
Fedora.
FPC was okay with the idea that third parties might use /usr/scl as well.
I didn't bring this up at the meeting but one thing that influences me on
this is that scls are inherently rpm managed and therefore mixing both our
scls with third party scls does not seem like the same vendor-OS problem
that /opt was designed to fix.
The location does need to include a vendor identifier. at the meeting we
discussed /usr/scl/$vendor/$scl_name/ but if the vendor string made its way
into the $scl_name I don't think people would object to /usr/scl/$scl_name
(scl_name is like fdr-ruby1.9.3).
-Toshio