hawkey replaced by libhif, DNF into C initiative started
by Honza Silhan
TL;DR
Hawkey project [1] is being obsoleted, use libhif [2] instead. For hawkey Python API consumers,
the transition should be painless.
Why we have done that?
Nowadays there are three major consumers of hawkey - DNF, PackageKit and rpm-ostree. The hawkey
API was not in final form yet and was changed constantly based on demands from these package
managers. We have merged hawkey project inside libhif and hidden some of not yet stable API.
Merging hawkey into libhif was another step to move more code base of DNF into C. DNF will reuse
some of the existing code of libhif. Having this shared library can eliminate inconsistencies
about installed packages when DNF and PackageKit is used alternately. Moreover we would like to
reuse the same metadata for all package managers to save your bandwidth.
Libhif should contain the common functionality for all package managers. So far libhif is
providing high level API by taking care of fetching metadata from mirrors, doing dependency
solving and executing RPM transaction. In the future it will support repository configuration
parsing, GPG checking and so on. At this time, this is handled by all package managers
separately.
Facts for Hawkey consumers:
* libhif-0.7.0 will obsolete hawkey package
* some of the C hawkey API from libhif will not be exposed anymore, please use libhif functions
instead
* python bindings will not change and the libhif package will still provide `python2-hawkey` and
`python3-hawkey`
* API in libhif is still not considered as fully stable yet
* first release of libhif with hawkey inside is targeted for Fedora 25
Please watch libhif project on github [2] and participate in PR discussions so you can influence
the development. Do not hesitate to respond with your concerns / opinions.
Honza
[0] https://dnf.baseurl.org/2016/02/24/dnf-into-c-initiative-started/
[1] https://github.com/rpm-software-management/hawkey
[2] https://github.com/rpm-software-management/libhif
8 years, 1 month
erlang-p1_zlib license change: GPLv2 --> ASL 2.0
by Randy Barlow
erlang-p1_zlib-1.0.1 has changed the license from GPLv2 to ASL 2.0. I'm
making the change in the spec file as needed, but thought I'd mention
here just in case there's something more I should do.
--
Randy Barlow
xmpp: bowlofeggs(a)electronsweatshop.com
irc: bowlofeggs on Freenode
8 years, 1 month
Branched Compose Report 20160225
by Dennis Gilmore
Hi all,
As we work to change things I am manually emailing the new compose report
OLD: Fedora-24-20160224.n.0
NEW: Fedora-24-20160225.n.0
===== SUMMARY =====
Added packages: 8
Dropped packages: 0
Upgraded packages: 81
Downgraded packages: 0
Size of added packages: 837.52 KiB
Size of dropped packages: 0.00 B
Size of upgraded packages: 3.92 GiB
Size of downgraded packages: 0.00 B
Size change of upgraded packages: -59317432.00 B
Size change of downgraded packages: 0.00 B
===== ADDED PACKAGES =====
Package: fedora-motd-0.1-1.fc24
Summary: Fedora MOTD
RPMs: fedora-motd
Size: 19262 bytes
Package: lz4-java-1.3.0-1.fc24
Summary: LZ4 compression for Java
RPMs: lz4-java lz4-java-javadoc
Size: 402788 bytes
Package: mkdocs-basic-theme-1.0.1-2.fc24
Summary: MkDocs Basic Theme
RPMs: mkdocs-basic-theme
Size: 15814 bytes
Package: nodejs-number-is-nan-1.0.0-2.fc24
Summary: ES6 Number.isNaN() ponyfill
RPMs: nodejs-number-is-nan
Size: 10042 bytes
Package: nodejs-secure-random-1.1.1-1.fc24
Summary: Normalize the creation of cryptographically strong random values
RPMs: nodejs-secure-random
Size: 12050 bytes
Package: python-editorconfig-0.12.0-3.fc24
Summary: A Python Based distribution of EditorConfig
RPMs: python2-editorconfig python3-editorconfig
Size: 84408 bytes
Package: python-epub-0.5.2-3.fc24
Summary: Python library for reading EPUB files
RPMs: python-epub-doc python2-epub python3-epub
Size: 278518 bytes
Package: python-pika_pool-0.1.3-3.fc24
Summary: Pools for pikas
RPMs: python2-pika_pool python3-pika_pool
Size: 34740 bytes
===== DROPPED PACKAGES =====
===== UPGRADED PACKAGES =====
Package: ColPack-1.0.10-1.fc24
Old package: ColPack-1.0.9-6.fc23
Summary: Algorithms for specialized vertex coloring problems
RPMs: ColPack ColPack-cli ColPack-devel ColPack-doc
Size: 1126188 bytes
Size change: -11088 bytes
Changelog:
* Wed Feb 03 2016 Fedora Release Engineering <releng(a)fedoraproject.org> - 1.0.9-7
- Rebuilt for https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild
* Wed Feb 24 2016 Björn Esser <fedora(a)besser82.io> - 1.0.9-8
- fix build with gcc 6 (#1307272)
* Thu Feb 25 2016 Björn Esser <fedora(a)besser82.io> - 1.0.10-1
- new upstream release
Package: appstream-0.9.1-1.fc24
8 years, 1 month
update mercurial to 3.7.1 in rawhide and F24
by Neal Becker
I'd like to update to latest mercurial. I built 3.7.1 in rawhide, and
AFAICT there's no problem using it with tortoisehg-3.7.1-fc24.
I'd like to update mercurial in F24 - AFAIK there should not be any
compatibility issues.
Any objections?
8 years, 1 month
Linux Presentation
by Jules Octave
Hi Guyz of Devel !
I am to present Linux to Intellectual lecturers and students at University
, i am looking for good material where to write my slide from .
My aim in this presentation will be to demistify Linux Operating System
and encourage more people to use the OS .
If by any means , you know any material i can use from or any idea please
send it to me .
Thanks,
Irenge B. Jules
MSC student @ Liverpool University
email : jbi.octave(a)gmail.com
Tel No 07405834974
U.K.
8 years, 1 month
sqlite and sqlite-devel broken dependencies in F23
by Reartes Guillermo
Hi,
today i noticed that sqlite and sqlite-devel have both broken
dependencies as reported by dnf.
Reported at:
https://bugzilla.redhat.com/show_bug.cgi?id=1312014
Cheers.
~~~~
[...TRUNCATED...]
qca x86_64
2.1.1-4.fc23 updates
454 k
qca-qt5 x86_64
2.1.1-4.fc23 updates
454 k
qca-qt5-ossl x86_64
2.1.1-4.fc23 updates
105 k
Saltando paquetes con dependencias rotas.:
sqlite x86_64
3.11.0-1.fc23 updates
484 k
sqlite-devel x86_64
3.11.0-1.fc23 updates
129 k
Resumen de la transacción
========================================================================================================================================================================
Instalar 1 Package
Actualizar 22 Packages
Skip 2 Packages
[...TRUNCATED...]
8 years, 1 month
Re: More prominent link to verification hashes
by Ralf Senderek
On Tue, 23 Feb 2016, Till Maas wrote:
> You can already get the keys at various places:
>
> - Fedora website
> - physical DVDs
> - fedora-repos git repository
> - fedora-repos RPM on kojipkgs
> - fedora-repos RPM Fedora mirrors
> - Fedora ISO images on Fedora mirrors
> - Eventually DNSSEC protected from DNS
I was very clear in saying fingerprint not keys. The original key file from the
website contains only self-signed keys. The only way to know if these are valid
is to check the fingerprint.
> Also all recent Fedora keys were signed by me. So how many different
> places do we need to make it secure? I am also very interested in making
> this secure, but adding more random places to look does not help unless
> people a actually looking there.
Printing the fingerprint in prominent places makes faking the key
nearly impossible, even if the ordinary user doesn't look there.
> And since you did not notice that I
> signed the GPG keys, I guess you did not look much as well.
You didn't sign it in the download file from the verify page.
Signing a key only helps if it is an assurance that the signer has checked
the fingerprint. I could have signed the keys as well, but I didn't
because I don't know anything about the fingerprint from first-hand.
If you have a valid means of checking the fingerprint with the creator
of the key and publicly confirm the fingerprint on the mailing list,
this would be a step forward.
> Btw before suggesting what to provide, maybe think of the instructions
> for users that would explain how to verify the keys
They are already asking the user on the verify page to run a gpg command,
displaying the fingerprint is as easy as that.
If you think you can improve things by signing keys, then take Gregory's
advice and create a long-term signing key and add it's signature to new
fedora release keys. AND print the fingerprint of this one key in
many prominent places.
8 years, 1 month
Self Introduction: Ramesh Nachimuthu
by Ramesh Nachimuthu
Hi,
I am Ramesh working in Red Hat for Gluster. I have contributed to oVrit project for Gluster and Ovirt Integration and Gluster Nagios monitoring project. I was actively involved in packaging the nagios addons for RHEL. I would like to provide the gluster nagios addons in Fedora.
Regards,
Ramesh
8 years, 1 month