Re: Missing font information at wiki
by Zbigniew Jędrzejewski-Szmek
On Thu, Nov 23, 2017 at 02:37:56PM +0000, Richard Hughes wrote:
> On Thu, Nov 23, 2017 at 1:55 PM, Zbigniew Jędrzejewski-Szmek
> <zbyszek(a)in.waw.pl> wrote:
> > I attached a screenshot from gnome-software-3.26.1-3.fc27.x86_64 for a
> > random font. This _is_ already pretty good, but it'd be nice to get rid
> > of the "No screenshot provided" thing. Why would gnome-software show that?
>
> We fixed the emoji font generation yesterday by chance:
> https://github.com/hughsie/appstream-glib/commit/7e597065a8024743dde63354...
Oh, cool. And what about the other issue: "no screenshot provided"?
> > Also, most fonts don't have good descriptions in the appdata files.
> > _This_ is something that requires font maintainer input.
>
> Right -- and they're almost never translated either.
Right. But should they be? A font looks the same in any language...
Zbyszek
6 years, 4 months
F27 System Wide Change: NSS Default File Format SQL
by Jaroslav Reznik
= System Wide Change: NSS Default File Format SQL =
https://fedoraproject.org/wiki/Changes/NSSDefaultFileFormatSql
Change owner(s):
* Kai Engert <kaie(a)redhat.com>
Change the NSS library default to use the sqlite based data storage,
when applications don't specify their preferred storage file format.
== Detailed Description ==
Applications that use the NSS library often use a database for storage
of keys, certificates and trust. NSS supports two different file
formats, one called DBM (based on berkeley DB files) and another one
called SQL (based on sqlite DB files).
Today's default file format used by NSS, used when applications omit
the type parameter, is the older DBM file format, which forbids
parallel access to the storage. The suggestion is to change the
default file format to SQL, which allows parallel access to the
storage.
Applications, or users using the NSS command line utilities, often
provide the database storage location using a simple directory path
parameter. Some might not be aware, or forget, that the parameter can
be prefixed with a type modifier, either "dbm:" or "sql:".
As a result, when not providing this parameter, the file format used
will be the fragile DBM file format. This is particuarly problematic,
if a user attempts to modify the NSS storage using command line tools,
while another process, such as a daemon, is running concurrently,
which also accesses the same database in the DBM file format. This
often results in corrupted database storage, which cannot be
recovered.
By changing the default, all applications that currently use the DBM
file format, will automatically be migrated to the SQL file format.
NSS has the ability to discover if a storage location (a directory)
contains the DBM file format. If configured to use the modern SQL
format, NSS will automatically perform a one-time conversion from the
DBM to the SQL format.
The same applies to the NSS command line utilities. If the NSS library
default is changed to SQL, the NSS tools will also trigger the
one-time conversion, or access the already converted files.
== Scope ==
* Proposal owners:
A small downstream patch needs to be applied to the NSS library
package, which changes the library default.
* Other developers:
It's up to developers of NSS applications, if they accept the new
default and an automatic conversion, or if they prefer to continue to
use the classic DBM storage format. Although not recommended,
developers can easily do so, by adding a "dbm:" prefix to the storage
parameter they provide to NSS at NSS library initialization time.
* Release engineering: [1]
No help should be necessary. No mass rebuild necessary.
* Policies and guidelines: N/A
* Trademark approval: N/A
[1] https://pagure.io/releng/issue/6883
Thanks,
Jaroslav
6 years, 4 months
Fwd: Re: Unresponsive Maintainer: eponyme (EDB package)
by Michael Cullen
I got a response to this, but he isn't a list member now so couldn't
respond to the list.
I'll take EDB - most of the other projects seem to be a bit dead
upstream - someone else can take them if they want!
I think you need to do it on
https://src.fedoraproject.org/rpms/edb/settings though I'm sometimes
getting 503 errors from that site right now, so you might need to
wait a while.
Thanks,
Michael
----- Original message -----
* From: Nicoleau Fabien <nicoleau.fabien(a)gmail.com>To: Michael Cullen <mich181189(a)fedoraproject.org>
Cc: devel(a)lists.fedoraproject.org
Subject: Re: Unresponsive Maintainer: eponyme (EDB package)
Date: Thu, 23 Nov 2017 19:51:31 +0100
Hello,
I appologize for being unresponsive. I actually have no more time to
take care of my packages.
If someone want's to take the package, I will give him the ownership
(tbh, I'm now so far prom the project that you will have to remind me
how to do :) )
Again, sorry for the silence,
Regards
Fabien Nicoleau (eponyme)
On Thu, Nov 23, 2017 at 7:30 PM, Michael Cullen <mich181189(a)fedoraproject.org> wrote:> Hi,
>
> I raised a ticket against EDB a while ago since it's quite out
> of date:> https://bugzilla.redhat.com/show_bug.cgi?id=1502328
>
> I also raised a PR to update the package, again with no response:
> https://src.fedoraproject.org/rpms/edb/pull-request/1#commit_list
>
> As per the unresponsive maintainer process, has anyone got a way of
> contacting the maintainer, eponyme (Nicoleau Fabien, also
> copied in on> this email)?
>
> Thanks,
> Michael
6 years, 4 months
Fedora Modular 27 compose report: 20171123.n.1 changes
by Fedora Branched Report
OLD: Fedora-Modular-27-20171123.n.0
NEW: Fedora-Modular-27-20171123.n.1
===== SUMMARY =====
Added images: 0
Dropped images: 0
Added packages: 0
Dropped packages: 8
Upgraded packages: 3
Downgraded packages: 14
Size of added packages: 0.00 B
Size of dropped packages: 7.71 MiB
Size of upgraded packages: 222.11 MiB
Size of downgraded packages: 11.91 MiB
Size change of upgraded packages: -1.91 KiB
Size change of downgraded packages: -268.00 B
===== ADDED IMAGES =====
===== DROPPED IMAGES =====
===== ADDED PACKAGES =====
===== DROPPED PACKAGES =====
Package: bea-stax-1.2.0-15.module_020ac465
Summary: Streaming API for XML
RPMs: bea-stax bea-stax-api bea-stax-javadoc
Size: 339288 bytes
Package: glassfish-jaxb-api-2.2.12-7.module_020ac465
Summary: Java Architecture for XML Binding
RPMs: glassfish-jaxb-api glassfish-jaxb-api-javadoc
Size: 264132 bytes
Package: httpcomponents-client-4.5.3-4.module_020ac465
Summary: HTTP agent implementation based on httpcomponents HttpCore
RPMs: httpcomponents-client httpcomponents-client-cache httpcomponents-client-javadoc
Size: 1696472 bytes
Package: httpcomponents-core-4.4.6-4.module_020ac465
Summary: Set of low level Java HTTP transport components for HTTP services
RPMs: httpcomponents-core httpcomponents-core-javadoc
Size: 1476992 bytes
Package: jackson-1.9.11-12.module_020ac465
Summary: Jackson Java JSON-processor
RPMs: jackson jackson-javadoc
Size: 2541920 bytes
Package: joda-time-2.9.3-4.tzdata2016c.module_020ac465
Summary: Java date and time API
RPMs: joda-time joda-time-javadoc
Size: 1049424 bytes
Package: objectweb-asm3-3.3.1-15.module_020ac465
Summary: Java bytecode manipulation and analysis framework
RPMs: objectweb-asm3 objectweb-asm3-javadoc
Size: 649668 bytes
Package: relaxngDatatype-2011.1-6.module_020ac465
Summary: RELAX NG Datatype API
RPMs: relaxngDatatype relaxngDatatype-javadoc
Size: 66200 bytes
===== UPGRADED PACKAGES =====
Package: nodejs-1:6.12.0-1.module_91d2e14d
Old package: nodejs-1:6.12.0-1.module_8b3978b6
Summary: JavaScript runtime
RPMs: nodejs nodejs-devel nodejs-docs npm
Size: 204335604 bytes
Size change: 160 bytes
Package: ruby-2.4.2-86.module_764b83e5
Old package: ruby-2.4.2-86.module_73a70cf2
Summary: An interpreter of object-oriented scripting language
RPMs: ruby ruby-devel ruby-irb ruby-libs rubygem-bigdecimal rubygem-did_you_mean rubygem-io-console rubygem-json rubygem-minitest rubygem-net-telnet rubygem-openssl rubygem-power_assert rubygem-psych rubygem-rake rubygem-rdoc rubygem-test-unit rubygem-xmlrpc rubygems rubygems-devel
Size: 28272252 bytes
Size change: -2092 bytes
Package: rubygem-bundler-1.13.7-3.module_764b83e5
Old package: rubygem-bundler-1.13.7-3.module_73a70cf2
Summary: Library and utilities to manage a Ruby application's gem dependencies
RPMs: rubygem-bundler
Size: 288044 bytes
Size change: -24 bytes
===== DOWNGRADED PACKAGES =====
Package: glassfish-fastinfoset-1.2.13-7.module_ee1166e3
Old package: glassfish-fastinfoset-1.2.13-7.module_020ac465
Summary: Fast Infoset
RPMs: glassfish-fastinfoset glassfish-fastinfoset-javadoc
Size: 709716 bytes
Size change: 40 bytes
Package: glassfish-jaxb-2.2.11-6.module_ee1166e3
Old package: glassfish-jaxb-2.2.11-6.module_020ac465
Summary: JAXB Reference Implementation
RPMs: glassfish-jaxb glassfish-jaxb-bom glassfish-jaxb-bom-ext glassfish-jaxb-codemodel glassfish-jaxb-codemodel-annotation-compiler glassfish-jaxb-codemodel-parent glassfish-jaxb-core glassfish-jaxb-external-parent glassfish-jaxb-javadoc glassfish-jaxb-jxc glassfish-jaxb-parent glassfish-jaxb-rngom glassfish-jaxb-runtime glassfish-jaxb-runtime-parent glassfish-jaxb-txw-parent glassfish-jaxb-txw2 glassfish-jaxb-txwc2 glassfish-jaxb-xjc glassfish-jaxb1-impl
Size: 4811816 bytes
Size change: 1364 bytes
Package: istack-commons-2.21-6.module_ee1166e3
Old package: istack-commons-2.21-6.module_020ac465
Summary: Common code for some Glassfish projects
RPMs: import-properties-plugin istack-commons istack-commons-buildtools istack-commons-javadoc istack-commons-maven-plugin istack-commons-runtime istack-commons-soimp istack-commons-test istack-commons-tools
Size: 418280 bytes
Size change: 640 bytes
Package: jboss-annotations-1.2-api-1.0.0-3.module_ee1166e3
Old package: jboss-annotations-1.2-api-1.0.0-3.module_020ac465
Summary: Common Annotations 1.2 API
RPMs: jboss-annotations-1.2-api jboss-annotations-1.2-api-javadoc
Size: 91780 bytes
Size change: -72 bytes
Package: jboss-jaxrs-2.0-api-1.0.0-5.module_ee1166e3
Old package: jboss-jaxrs-2.0-api-1.0.0-5.module_020ac465
Summary: JAX-RS 2.0: The Java API for RESTful Web Services
RPMs: jboss-jaxrs-2.0-api jboss-jaxrs-2.0-api-javadoc
Size: 379884 bytes
Size change: -60 bytes
Package: jboss-logging-3.3.0-3.module_ee1166e3
Old package: jboss-logging-3.3.0-3.module_020ac465
Summary: The JBoss Logging Framework
RPMs: jboss-logging jboss-logging-javadoc
Size: 255948 bytes
Size change: 816 bytes
Package: jcip-annotations-1-21.20060626.module_ee1166e3
Old package: jcip-annotations-1-21.20060626.module_020ac465
Summary: Java annotations for multithreaded software
RPMs: jcip-annotations jcip-annotations-javadoc
Size: 37388 bytes
Size change: 124 bytes
Package: jsr-311-1.1.1-14.module_ee1166e3
Old package: jsr-311-1.1.1-14.module_020ac465
Summary: JAX-RS: Java API for RESTful Web Services
RPMs: jsr-311 jsr-311-javadoc
Size: 161020 bytes
Size change: -64 bytes
Package: nodejs-packaging-10-1.module_91d2e14d
Old package: nodejs-packaging-10-1.module_35144853
Summary: RPM Macros and Utilities for Node.js Packaging
RPMs: nodejs-packaging
Size: 32864 bytes
Size change: 44 bytes
Package: resteasy-3.0.19-6.module_ee1166e3
Old package: resteasy-3.0.19-6.module_020ac465
Summary: Framework for RESTful Web services and Java applications
RPMs: resteasy resteasy-atom-provider resteasy-client resteasy-core resteasy-fastinfoset-provider resteasy-jackson-provider resteasy-jackson2-provider resteasy-javadoc resteasy-jaxb-provider resteasy-jettison-provider resteasy-json-p-provider resteasy-multipart-provider resteasy-netty3 resteasy-optional resteasy-test resteasy-validator-provider-11 resteasy-yaml-provider
Size: 4132452 bytes
Size change: -2972 bytes
Package: stax-ex-1.7.7-7.module_ee1166e3
Old package: stax-ex-1.7.7-7.module_020ac465
Summary: StAX API extensions
RPMs: stax-ex stax-ex-javadoc
Size: 122308 bytes
Size change: 84 bytes
Package: stax2-api-4.0.0-3.module_ee1166e3
Old package: stax2-api-4.0.0-3.module_020ac465
Summary: Experimental API extending basic StAX implementation
RPMs: stax2-api stax2-api-javadoc
Size: 445032 bytes
Size change: -56 bytes
Package: xmlstreambuffer-1.5.4-6.module_ee1166e3
Old package: xmlstreambuffer-1.5.4-6.module_020ac465
Summary: XML Stream Buffer
RPMs: xmlstreambuffer xmlstreambuffer-javadoc
Size: 177360 bytes
Size change: -40 bytes
Package: xsom-0-17.20110809svn.module_ee1166e3
Old package: xsom-0-17.20110809svn.module_020ac465
Summary: XML Schema Object Model (XSOM)
RPMs: xsom xsom-javadoc
Size: 712088 bytes
Size change: -116 bytes
6 years, 4 months
F28 Self Contained Change: PHP 7.2
by Jan Kurik
= Proposed Self Contained Change: PHP 7.2 =
https://fedoraproject.org/wiki/Changes/php72
Change owner(s):
* Remi Collet <remi at fedoraproject dot org>
Update the PHP stack in Fedora to latest version 7.2.x
== Detailed Description ==
Update the PHP stack in Fedora to latest version 7.2.x.
* PHP 7.2.0 is planed for end of year, which seems compatible with
Fedora roadmap.
Compatibility for PHP code is very good.
== Scope ==
* Proposal owners:
Check Koschei status. Test with latest version to ensure
compatibility. Work with upstream on bug fixing. Needed mass rebuild
(C extensions) done by change owner.
* Other developers:
N/A (not a System Wide Change)
* Release engineering:
https://pagure.io/releng/issue/6846
* List of deliverables:
N/A (not a System Wide Change)
* Policies and guidelines:
N/A (not a System Wide Change)
* Trademark approval:
N/A (not needed for this Change)
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
6 years, 4 months
GCL and SELinux: help requested
by Jerry James
On Sat, Oct 7, 2017 at 9:34 AM, Jerry James <loganjerry(a)gmail.com> wrote:
> I don't believe that anybody looks at those pull requests on a regular
> basis. Should somebody be doing so? There are 8 pull requests,
> dating back to about the time of the above conversation. Five of
> those don't contain a single comment.
>
> I opened one for gcl on July 29, and added a comment a month later
> asking if somebody was going to look at it. No response. This is a
> bit annoying, considering that I opened a bugzilla request asking for
> the same thing 4 years ago, and no action has ever been taken on it.
> I thought maybe a PR would finally get something to happen.
Nearly a week has gone by, and no answer. I'm really stumped about
what to do. Let me summarize the whole long saga and solicit help.
GCL is a Common Lisp implementation. It is known for its speed
compared to other CL implementations. It has a long lineage,
summarized here: https://en.wikipedia.org/wiki/GNU_Common_Lisp. I
took over maintenance of the package in late 2008 when the previous
maintainer did not have time to continue. At that point, the package
did not build in Rawhide and was slated to be dropped from Fedora
soon. I got it working with help from upstream and Daniel Walsh, who
provided advice on putting together an SELinux policy to account for
the fact that GCL produces executable code on the fly by calling
mprotect on selected pages.
Fast forward to 2013. By that time, the GCL policy also had to
mention maxima executables, since executables built with GCL also use
the GCL memory allocator. I figured that meant it was time to merge
the GCL policy into the system policy, and consequently opened a
bugzilla ticket. In spite of me trying to reboot the conversation a
couple of times, those involved who held the SELinux reins for Fedora,
Just. Could. Not. Stay. On. Topic. We talked about the execheap
permission in general, and its place in the universe. Some of them
sneeringly, condescendingly wondered why upstream and I were both so
incompetent that we didn't just rewrite the allocator to use mmap.
(Hint: it isn't easy, and upstream isn't interested in the exercise.)
After multiple failures on my part to get something to happen, I gave
up in despair.
Fast forward to 2017. Attempts to build maxima with gcl on aarch64
started hanging at package install time. See
https://bugzilla.redhat.com/show_bug.cgi?id=1435395. This was blamed
on gcl, incorrectly I believe. As I pointed out in the bug, nothing
built from gcl sources runs at package install time, so the hang must
be happening inside one of fixfiles, semodule, or restorecon, which
ARE run from the gcl install scripts because GCL has to install its
own SELinux policy, due to that policy not being merged into the
system policy. So, policycoreutils maintainers! Something Is Afoot
on aarch64!
But that's not the end of the fun. GCL failed the mass rebuild this
summer. It built successfully on every architecture but s390x. On
s390x, the build failed due to a failed call to mprotect(), almost
certainly a sign that SELinux was in enforcing mode on the builder.
Was that a known issue with s390x builders? And, if so, has it been
rectified since? If so, I'll try building again.
I still want the system policy to account for GCL, in some way or
another. But, as you can see from the quoted text above, submitting a
pull request to the relevant git repository has resulted in months of
<crickets chirping>. And pointing that out on this list last weekend
has resulted in still more of the crickets.
So ... what is a packager supposed to do???? Why is it so hard to get
any attention for submissions to the system SELinux policy? There
should be a barrier to entry; I understand that. But I can't even get
the gatekeeper to have a conversation with me. Heeeeellllllppppp!!!
Frustratedly yours,
--
Jerry James
http://www.jamezone.org/
6 years, 4 months
FYI: OCaml 4.06 in Fedora 28 will change default mutability of
strings
by Richard W.M. Jones
Since forever ...
# string_of_bool true;;
- : string = "true"
# String.blit "urgh" 0 (string_of_bool true) 0 4;;
- : unit = ()
# string_of_bool true;;
- : string = "urgh"
Since OCaml 4.02 (in 2014) it has been possible to opt in to
‘-safe-string’ to make strings immutable. You have to use the Bytes
type when you want mutable byte arrays.
In OCaml 4.06, coming to Fedora Rawhide soon, this option will be the
default and any code which mutates strings will not compile:
# String.blit "urgh" 0 (string_of_bool true) 0 4;;
Characters 21-42:
String.blit "urgh" 0 (string_of_bool true) 0 4;;
^^^^^^^^^^^^^^^^^^^^^
Error: This expression has type string but an expression was expected of type
bytes
I think most upstream packages should be fixed by now, but if you need
help to fix a particular package then file a bug and CC me on it. As
a last resort you can enable mutable strings again using
‘-unsafe-string’, but please try not to do that.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
6 years, 4 months