gcc-c++ and libatomic -- link issues
by Patrick Diehl
Hi,
I maintain the hpx package and it uses std:atomic and when I install
gcc-c++ it seems that libatomic is not a dependency of the gcc-c++
package. My program fails, because it can not link against libatomic. Is
this the supposed behavior to install libatomic or should libatomic
become one of the dependencies of gcc-c++?
Best,
Patrick
5 years, 2 months
signing status
by Kevin Fenzi
Just wanted to update everyone on our current status.
As you know from the other thread:
* The mass rebuild happened and finished.
* The mass rebuild side tag was merged into the f30-pending tag
(to make sure everything was signed).
* In the middle of the night our autosign box stopped processing.
* The next morning this was noticed and a request for a replacement
motherboard was sent.
* Since that was going to take a day, we setup another machine to do
autosigning.
* That machine started processing the backlog, but also stopped
processing a few times (waiting on koji).
* Finally we set back up the normal listening process and I retagged all
the f30-pending builds to it would "see" they needed processing.
Currently it's processing along pretty fast, but it does make sure koji
has the signed rpms written out, which can take a few seconds on larger
packages.
I'm hopeful that it will catch back up today and we can go back to normal.
There will likely be a short outage next week to move back to the now
replaced hardware, but that should be only a few minutes.
kevin
5 years, 2 months
Orphaning workrave
by Yaakov Selkowitz
workrave has yet to gain support for Wayland. While it still works on
X11 desktops, that is no longer the default for Workstation, and hence
users keep filing bugs that it doesn't work, which I then just have to
CLOSED UPSTREAM.
If you want to take it nevertheless, the following F30FTBFS will need
to be fixed first:
https://bugzilla.redhat.com/show_bug.cgi?id=1676218
AFAIK all that's missing is some X11-related BuildRequires which must
have previously been pulled in by gtk*-devel but no longer are.
If it is not taken and fixed by the F30FTBFS deadline, it will be
orphaned automatically, and subsequently retired.
--
Yaakov Selkowitz
Senior Software Engineer - Platform Enablement
Red Hat, Inc.
5 years, 2 months
F30 Self-Contained Change proposal: Ibus-typing-booster default for
Indian languages
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Ibus_typing_booster_default_for_in...
== Summary ==
Make ibus-typing-booster the default input method for Indian languages.
== Owner ==
* Name: [[User:Mfabian|Mike Fabian]]
* Email: <mfabian(a)redhat.com>
== Detailed Description ==
Currently, ibus-m17n is the default input method for Indian languages
in Fedora. ibus-typing-booster uses the same libm17n used by
ibus-m17n to support input for Indian languages and thus it can do
everything ibus-m17n can do. But on top of that, ibus-typing-booster
supports predictive input by remembering user input and by using words
from dictionaries. Therefore, ibus-typing-booster is a more useful input method
for these languages.
== Benefit to Fedora ==
A better input experience for users of Indian languages.
== Scope ==
* Proposal owners:
The langtable package has data about default input methods. Change this data.
But the data in langtable is currently apparently not used by
gnome-initial setup.
The list of default input methods used by gnome-initial-setup us stored in
<pre>
libgnome-desktop/default-input-sources.h
</pre>
Currently there are the following default input methods for the Indian locales:
<pre>
static DefaultInputSource default_input_sources[] =
{
...
{ "as_IN", "ibus", "m17n:as:phonetic" },
...
{ "bn_IN", "ibus", "m17n:bn:inscript" },
...
{ "gu_IN", "ibus", "m17n:gu:inscript" },
...
{ "hi_IN", "ibus", "m17n:hi:inscript" },
...
{ "kn_IN", "ibus", "m17n:kn:kgp" },
...
{ "mai_IN", "ibus", "m17n:mai:inscript" },
...
{ "ml_IN", "ibus", "m17n:ml:inscript" },
...
{ "mr_IN", "ibus", "m17n:mr:inscript" },
...
{ "or_IN", "ibus", "m17n:or:inscript" },
...
{ "pa_IN", "ibus", "m17n:pa:inscript" },
...
{ "sd_IN", "ibus", "m17n:sd:inscript" },
...
{ "ta_IN", "ibus", "m17n:ta:tamil99" },
...
{ "te_IN", "ibus", "m17n:te:inscript" },
...
{ "ur_IN", "ibus", "m17n:ur:phonetic" },
...
</pre>
Here, "m17n:as:phonetic" would need to be replaced with "typing-booster".
And similar for the other Indian languages.
ibus-typing-booster selects the default input method to use
from the locale when it is first started. For the above Indian
locales ibus-typing-booster >= 2.4.2 has the same default
m17n input methods as libgnome-desktop/default-input-sources.h,
except that it always uses inscript2 instead of inscript by default.
* Other developers: 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)
== Upgrade/compatibility impact ==
Nothing should happen when upgrading from a previous version of Fedora.
If a user used ibus-m17n before the upgrade, he will still use it
after the upgrade.
This change proposal only changes the default input method for an
Indian language
for new installs or new user accounts.
== How To Test ==
Do a new installation of Fedora 30 in an Indian language. Log into Gnome.
See what input method is suggested by default by gnome-initial-setup.
== User Experience ==
Easier input of Indian language because of predictive input.
== Dependencies ==
gnome-initial-setup
== Contingency Plan ==
* Contingency mechanism: Leave the default input methods as they are
now and move the change to Fedora 31
* Contingency deadline: Fedora 30 Beta release
* Blocks release? No.
* Blocks product? No.
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
5 years, 2 months
fedpkg push fails
by Neal Becker
I haven't done any fedora packaging work for some time. I tried to fix
https://bugzilla.redhat.com/show_bug.cgi?id=1674789
today, but I get:
fedpkg push
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 4 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 429 bytes | 429.00 KiB/s, done.
Total 3 (delta 2), reused 0 (delta 0)
remote: Denied push for ref 'refs/heads/master' for user 'nbecker'
remote: All changes have been rejected
To ssh://pkgs.fedoraproject.org/rpms/dblatex
! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to
'ssh://nbecker@pkgs.fedoraproject.org/rpms/dblatex'
Could not execute push: Failed to execute command.
5 years, 2 months
