Call for testing - Firefox 57
by Martin Stransky
Hi folks,
let's have some fun with upcoming Firefox 57 a.k.a Firefox Quantum. This
is a major Firefox update with key - pleasant and unpleasant - changes:
- fastest than ever with Rust, CSS Stylo, Sandbox...
- new "Photon" look
- and disabled XUL extensions
according to the disruptive nature of the update which is planned to
land in *all* Fedoras at Nov 14 I decided to put the update to the
testing as soon as possible, which mean we have Firefox 57 Beta packages
at update-testing right now.
If you don't consume update-testing regularly you can install Firefox
only by:
# dnf update --enablerepo=updates-testing firefox
and also expect new versions there. Please give it a shot and report any
issue to our [1] or Mozilla bugzilla [2].
Thanks!
ma.
[1] https://bugzilla.redhat.com/
[2] https://bugzilla.mozilla.org/
6 years, 4 months
[HEADS-UP] cryptsetup-2.0.0-rc1 - libcryptsetup soname bump
by Ondrej Kozina
We're going to build new cryptsetup-2.0.0-rc1 package in rawhide next
week. The major version increase also brings libcryptsetup soname bump.
Among other things new library will drop few functions.
These API functions will be removed:
crypt_set_password_callback;
crypt_set_timeout;
crypt_set_password_retry;
crypt_set_password_verify;
crypt_set_iterarion_time;
crypt_last_error;
crypt_get_error;
crypt_benchmark_kdf;
For further description and explanation why those calls were removed and
what new functions are available, please see:
https://www.kernel.org/pub/linux/utils/cryptsetup/v2.0/v2.0.0-rc0-Release...
Following packages are listed as having direct runtime dependency on
cryptsetup-libs (arch x86_64 only) and therefore they may break or fail
to build if they use any function listed above:
clevis-udisks2-0:6-3.fc27.x86_64
deo-disks-0:0.5.1-2.fc24.x86_64
libblockdev-crypto-0:2.13-1.fc28.x86_64
libluksmeta-0:8-1.fc28.x86_64
luksmeta-0:8-1.fc28.x86_64
pam_mount-0:2.15-3.fc24.x86_64
python2-volume_key-0:0.3.9-16.fc28.x86_64
systemd-0:235-2.fc28.x86_64
systemd-tests-0:235-2.fc28.x86_64
systemd-udev-0:235-2.fc28.x86_64
volume_key-0:0.3.9-16.fc28.x86_64
volume_key-libs-0:0.3.9-16.fc28.x86_64
zulucrypt-console-0:5.2.0-3.fc27.x86_64
zulucrypt-libs-0:5.2.0-3.fc27.x86_64
Regards
Ondrej
6 years, 4 months
Packages looking for new maintainers
by Ville Skyttä
Hello,
The following packages are looking for new maintainers, ping me if
you're able to help out.
1) No co-maintainers at the moment:
- git-bz
- isrcsubmit
- jing-trang
- kid3
- mbox2eml
- modplugtools
- netmask
- portecle
- python-flake8-import-order
- vdr-epgfixer
- vdr-ttxtsubs
2) Needs new main admin, co-maintainers pinged some time ago but no
reply received/noticed:
- ccache
- libmodplug
- pyflakes
- python-libdiscid
- reptyr
- rpmdevtools
- zopfli
6 years, 4 months
bodhi CLI and USERNAME
by Randy Barlow
Greetings fellow Fedorans,
We're about to release Bodhi 3.0.0[0] upstream, which has a backwards
incompatible CLI change[1] that I am considering backporting to the
stable Fedoras, but I wanted feedback first before I do that.
The Bodhi 2 CLI will use the USERNAME environment variable when
authenticating you, if present, and the Bodhi 3 CLI[3] does not use any
environment variable (yet) for authentication. Here's the reasoning:
* The Bodhi 2 CLI previously didn't have the ability to remember your
username, but it did have the environment variable, which kind of
acted like a bandaid. I believe this variable was in place before I
got involved.
* The CLI got a lot of love earlier this year, and one of the big things
added was the ability for it to remember your username if you've ever
successfully authenticated before. This feature largely removed the
need for the environment variable, but keeping the variable seemed
harmless at the time.
* I recently learned that the variable is painful for some users,
because GDM sets this variable to your local system's login username,
which is not necessarily the same as your FAS username.
* When the username is present, Bodhi will not prompt the user for their
username, which leads to a very poor experience upon first login for
GDM users who have mismatching FAS account names (Bodhi prompts for
their password and then tells them it's wrong). Without the variable,
Bodhi will prompt users to enter their username upon first use.
* Users can currently override the USERNAME environment variable with a
--user flag as a workaround.
* Though it may seem that Kerberos addresses this problem, Bodhi does
not use Kerberos (it uses OpenID) and there are not plans to adjust
Bodhi to use Kerberos because we plan to convert it to use OpenID
Connect instead.
In order to address the above, and in the spirit of working quickly due
to the other pressures to complete 3.0.0, it was easy enough to just
drop support for this environment variable with 3.0.0, since 3.0.0
already needed other backwards incompatible changes. However, I have a
few questions for the list:
0) Do you have a use case for an environment variable to set your
username? If there is sufficient demand for this feature, we can add
it back with a different name in a future Bodhi 3 release (perhaps
BODHI_USER or FAS_USER would suffice).
1) I'd like to make a backwards incompatible patch for the stable
Fedoras so that GDM users get a better experience without having to
wait for Fedora 28, but I don't want to do this if it is too
disruptive. Normally I am quite against backwards incompatible
changes in Fedora, but this can also be viewed as a painful bug and
fixing the bug might alleviate more pain than the change would
cause. Would such a change be a disruption to us developers, or does
the good outweigh the bad?
A few options for F25-27:
0) Do nothing, and let Rawhide be the only place this change happens.
1) Drop USERNAME.
2) s/USERNAME/BODHI_USER/ or similar.
Thoughts?
P.S. The Bodhi 3.0 beta is also deployed to staging[2], though no user
visible changes will be apparent. It's main feature is the ability to
mash modules.
[0] https://bodhi.stg.fedoraproject.org/docs/release_notes.html
[1] https://github.com/fedora-infra/bodhi/issues/1789
[2] https://bodhi.stg.fedoraproject.org/
[3] https://copr.fedorainfracloud.org/coprs/bowlofeggs/bodhi-pre-release
6 years, 4 months
[Rawhide] gawk API changes heads up
by David Kaspar [Dee'Kej]
Hello folks! :)
The new major version of GNU awk (gawk) was released recently, and this
version introduced a new API (version 2.0). I want to give all of you a
heads up that I'm planning to do a rebase in Rawhide next week (probably on
Tuesday, November 7th, if everything goes OK).
If you have any gawk extension (or you somehow depend on gawk internals in
your packages), then you will have to update your packages so they are able
to work properly during runtime (with the new ABI).
On the other hand, I do not think we have so many extensions of gawk in
Fedora. Most of the packages depending on gawk (see below) probably uses
the gawk for its text processing capabilities. :)
In any case, I have recently introduced (in gawk-4.1.4-7) the 'gawk(abi)'
in the gawk's specfile:
> Provides: gawk(abi) = %{gawk_api_major}.%{gawk_api_minor}
If your package requires a specific API version, then you can require that
version in your package's specfile as you need. Once you have this in
place, the users shouldn't be able to update to newer version of gawk, if
it would break the ABI compatibility.
---------------------
Last thing I have in my mind regarding the upcoming rebase - should we
schedule a mass-rebuild for the packages listed below, to see if they build
correctly with the latest version of gawk? If they wouldn't, we could file
the new FTBFS BZs for it. Thoughts? Comments? :)
---------------------
List of packages requiring gawk (it might not be complete, it was extracted
from some quick dnf query):
akmods
am-utils
autoconf213
autofs
calamares
ceph-selinux
checksec
cloud-utils
cloud-utils-growpart
copr-backend
ctdb
dhcp-client-12
dkms
docbook-utils
e2fsprogs-devel
execstack
firehol
gt5
guilt
hylafax+
krb5-libs
latex2rtf
lde
libguestfs
libsmi
linuxdoc-tools
lorax
netdump-server
nfs-utils
pcp
phpPgAdmin
pkgdiff
policycoreutils
quilt
ragel
rarian
R-core
rear
rf
rpm-build
rpmdevtools
screenie
seqan
testssl
translate-shell
tuned
tw
txt2man
unity-gtk-module-common
virt-p2v-maker
virt-v2v
vzctl-core
xfce4-dev-tools
ypserv
-----------------------
Best regards,
David Kaspar [Dee'Kej]
*Associate Software Engineer*
*Brno, Czech Republic*
RED HAT | TRIED. TESTED. TRUSTED.
Every airline in the Fortune 500 relies on Red Hat.
Find out why at Trusted | Red Hat <http://www.redhat.com/en/about/trusted>.
6 years, 4 months
CI projects in Copr
by Miroslav Suchý
Hi,
I am gathering informations about various use of CI with Copr. Do you use Copr for building packages for nightlies? For
building packages before pull request is merged? Do you have your set up described somewhere? What is the name of your
project?
Please let me know. Either here or via private reply.
It will help me to understand your use of Copr and to make Copr better.
Thanks in advance.
Miroslav Suchy
6 years, 4 months
fedpkg failed to retire package
by Zamir SUN
Hi allm
When I try to retire package using the following command, some error
shows up
`fedpkg retire "Renamed to popub"`
> $ fedpkg retire "Renamed to popub"
> /usr/lib/python2.7/site-packages/fedora/client/bodhi.py:48: DeprecationWarning: fedora.client.bodhi has been deprecated. Please use bodhi.client.bindings instead.
> DeprecationWarning)
> rm '.gitignore'
> rm 'README.md'
> rm 'portpub-conf'
> rm 'portpub.spec'
> rm 'sources'
> [f26 9b7905a] Renamed to popub
> 6 files changed, 1 insertion(+), 96 deletions(-)
> delete mode 100644 .gitignore
> delete mode 100644 README.md
> create mode 100644 dead.package
> delete mode 100644 portpub-conf
> delete mode 100644 portpub.spec
> delete mode 100644 sources
> Counting objects: 3, done.
> Delta compression using up to 4 threads.
> Compressing objects: 100% (1/1), done.
> Writing objects: 100% (3/3), 268 bytes | 268.00 KiB/s, done.
> Total 3 (delta 0), reused 0 (delta 0)
> remote: Emitting a message to the fedmsg bus.
> remote: * Publishing information for 1 commits
> remote: * Notifying alternative-arch people
> remote: Sending to redis to send commit notification emails
> To ssh://pkgs.fedoraproject.org/rpms/portpub
> 8ec0602..9b7905a f26 -> f26
> FAS password for user zsun:
> Could not execute retire: Un-expected openid provider asked: https://admin.fedoraproject.org/pkgdb/
Since pkgdb is retired already, I think might be the cause. But I still
want to know if I can ignore the error, or I am using the command in a
wrong way?
Thanks in advance.
--
Ziqian SUN (Zamir)
zsun(a)fedoraproject.org
GPG : 1D86 6D4A 49CE 4BBD 72CF FCF5 D856 6E11 F2A0 525E
Want to know more about Fedora?
Visit https://fedoraproject.org/wiki/
6 years, 4 months