headup : libzip 0.11 in rawhide (and PHP change)
by Remi Collet
Hi.
I have updated libzip to 0.11.1 in rawhide.
Despite there is no soname change, see:
http://upstream-tracker.org/versions/libzip.html
So I think it is preferable to rebuild dependent packages to ensure all
is ok.
As PHP only work with libzip 0.10 (use lot of private stuff), the zip
extension is become unmaintainable, so have been dropped from php.
So we are going to receive tons of broken deps for pakages requiring
php-zip.
I just submit php-pecl-zip to review [1]
This extension (from the same sources, but updated for libzip 0.11) is
of course absolutely compatible.
It will be really simpler to sync the life cyle of this extension with
the library.
Remi
[1] https://bugzilla.redhat.com/show_bug.cgi?id=999313
10 years, 8 months
Self Introduction
by Frankie
Hi guys,
Following the set of guidelines provided at:
https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#In...
I would like to introduce myself.
My names are Onuonga Frankie.
my page on the fedora system is
:https://fedoraproject.org/wiki/User:Onuonga
I am in my final year at the university.
I am taking a bachelors in computer science and mathematics.
My major is advanced computer architecture which involves: signal
processing, systems programming, parallel programming, simulation and
modeling.
I am joining the list to assist in packaging.
I do not have any specific one yet but would like to get my hands
dirty with what I am given.
my Key fingerprint is :DAA5 8A30 CDF7 E90A 52C2 AF87 3D95 6592 7DB5
43E6
thank you.
--
Frankie Onuonga <frankieonuonga(a)gmail.com>
10 years, 8 months
NOTE: Serf library 1.3.1 will land in f20 and rawhide soon
by Christopher Meng
Hi,
As serf upstream has released 1.3 and 1.3.1 bugfix for a long time, I'm
going to push an update in the next week. Upstream had changed to scon so
there needs some work.
Serf is the default client library of Subversion and Apache OpenOffice.
Subversion has been built with serf support for a while after serf got
approved. Not sure about AOO now.
Please check your package to see if there are any issues affected by the
update.
Thanks.
10 years, 8 months
F20 Self Contained Change: Apache OpenOffice
by Jaroslav Reznik
= Proposed Self Contained Change: Apache OpenOffice =
https://fedoraproject.org/wiki/Changes/ApacheOpenOffice
Change owner(s): Andrea Pescetti <pescetti(a)apache.org>
Add Apache OpenOffice [1], the free productivity suite, to Fedora.
== Detailed description ==
Apache OpenOffice (formerly OpenOffice.org) is an extremely popular free and open-
source office software suite.
Donated by Oracle to the Apache Software Foundation in 2011, it is now
developed and supported by a thriving community; it graduated from the Apache
Incubator in October 2012 and it is now an Apache Top-Level Project.
Apache OpenOffice 4.0, due in the last decade of July 2013, is a major update.
The two new versions (3.4.0 and 3.4.1) released in 2012 under the Apache
guidance totalled 60 million downloads so far, not counting mirrors.
To be clear, this proposal is about merely adding Apache OpenOffice: it doesn't
affect existing office suites included in Fedora and it doesn't require that
Apache OpenOffice is made the default office suite in Fedora.
== Scope ==
Proposal owners:
Packaging is the main issue here. The default OpenOffice build process produces
RPM packages, but there are major changes to be done to obtain a set of RPM
packages and matching SRPMs suitable for inclusion in Fedora.
Version 4.0 produces packages based on the current product name: this allows
to avoid name clashes with older versions of OpenOffice.
The OpenOffice sources have been updated to allow a clean build with the default
tools shipped with Fedora 19.
The change is isolated, except some possible packaging overlap with LibreOffice,
see below.
Other developers:
This issue was widely discussed for Fedora 19 too (the feature was then
postponed to Fedora 20 since OpenOffice 4.0 was rescheduled to be released after
Fedora 19).
The /usr/bin/soffice and /usr/bin/unopkg executables/symlinks are still a
problem since (in the Fedora packages) they would conflict between LibreOffice
and Apache OpenOffice: it is recommended to fix it in the LibreOffice packages too.
As discussed on the mailing lists, applications that programmatically spawn an
OpenOffice/LibreOffice process may benefit of the "soffice" symlink when they need to
locate an OpenOffice/LibreOffice installation. On the other hand, the current
upstream LibreOffice packages do not rely on a "soffice" symlink.
Anyway, some coordination will be needed, as already envisaged by FESCo for
Fedora 19, to ensure a smooth user experience. The impact on the system as a
whole is believed to be limited enough for this change not to be considered a
"system-wide change".
Release engineering: N/A (not a System Wide Change)
Policies and guidelines: N/A (not a System Wide Change)
[1] http://openoffice.org/
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
10 years, 8 months
Rawhide grub messed up
by Jan Synacek
Hi,
I just updated my rawhide machine and it stopped booting. I end up in "grub
rescue>" prompt, stating that there is no '/grub2/i386-pc/normal.mod'.
grub rescue> ls /grub2
./ ../ themes/ grub.cfg
grub rescue> set
prefix=(hd0,msdos1)/grub2
root=hd0,msdos1
Partition seems to be right, why "msdos" escapes me, though. How do I fix this mess?
Cheers,
--
Jan Synacek
Software Engineer, Red Hat
10 years, 8 months
python-django insufficient Obsoletes
by Michael Schwendt
The "Obsoletes" tag for these python-django-foo renames is not high
enough. A systematical error due to not considering the dist tag.
django-extra-form-fields
django-extra-form-fields-0:0.0.1-2.fc17.noarch isn't obsoleted
django-extra-form-fields-0:0.0.1-1.fc16.noarch is oldest
django-extra-form-fields < 0:0.0.1-2 obsoleted by python-django-extra-form-fields-0:0.0.1-7.fc20.noarch
django-followit
django-followit-0:0.0.3-2.fc17.noarch isn't obsoleted
django-followit-0:0.0.2-2.fc16.noarch is oldest
django-followit < 0:0.0.3-2 obsoleted by python-django-followit-0:0.0.3-6.fc20.noarch
django-recaptcha-works
django-recaptcha-works-0:0.3.4-3.fc18.noarch isn't obsoleted
django-recaptcha-works-0:0.3.4-1.fc16.noarch is oldest
django-recaptcha-works < 0:0.3.4-3 obsoleted by python-django-recaptcha-works-0:0.3.4-5.fc20.noarch
django-registration
django-registration-0:0.7-4.fc18.noarch isn't obsoleted
django-registration-0:0.7-2.fc16.noarch is oldest
django-registration < 0:0.7-4 obsoleted by python-django-registration-0:0.8-4.fc20.noarch
10 years, 8 months
Obsoletes, Obsoletes, Obsoletes
by Michael Schwendt
Oh no! Another one of those threads... ;-)
Well, a comment from Thomas Moschny inspired me to examine "Obsoletes"
tags in our package collection a bit.
How to find "Obsoletes" tags, which are not high enough?
For example, it happens regularly that even with Fedora's Package Rename
Process, which requires a package review, incorrect Obsoletes (the $obsver
in the guidelines) manage to slip through because of the dist tag. The
supposed-to-be-obsolete package remains installed and installable. Or
worse, if not retired properly, it might return with a bumped release
after a rebuild:
pexpect-0:2.3-9.fc19.noarch isn't obsoleted
pexpect <= 0:2.3-9 obsoleted by python-pexpect-0:2.5.1-6.fc19.noarch
pexpect-0:2.3-10.fc20.noarch isn't obsoleted
pexpect <= 0:2.3-9 obsoleted by python-pexpect-0:2.5.1-6.fc19.noarch
What has happened? It should have been retired in Fedora 18 already when
it got obsoleted.
So, my first idea has been to look at all packages in the repositories and
search for builds with an EVR that is higher than an existing Obsoletes
tag for that package name. Huge output! A nightmare. A Herculean task to
check them all (until the script may be trusted), but easy enough to
skim over the list and perform a plausibility check:
latte-integrale
4ti2-0:1.5-3.fc18.i686 isn't obsoleted
4ti2 < 0:1.5-1 obsoleted by 4ti2-0:1.5-10.fc20.i686
Indeed. "latte-integrale" is the src.rpm name. It builds a "4ti2"
binary rpm with an EVR higher than the Obsoletes tag. Checking the
spec file in git:
%package -n 4ti2
# This can be removed once Fedora 18 reaches EOL.
Provides: 4ti2 = %{version}-%{release}
Obsoletes: 4ti2 < 1.5-1
And there are many more like that. We're really bad here.
I don't even understand that spec file. _Why_ does it add such
Provides (those are automatic for %name anyway) and self-Obsoletes?
Anyway, enjoy the full list here:
http://mschwendt.fedorapeople.org/dubious_Obsoletes_in_Rawhide_20130821.txt
On to the second experiment. Ancient Obsoletes! Which Obsoletes tags
are too low for any current build in Fedora 16 up to Rawhide?
It's a shorter list:
http://mschwendt.fedorapeople.org/ancient_Obsoletes_in_Rawhide_20130821.txt
But hey, what the heck is stuff like this?
erlang
erlang-0:R14B-04.1.fc16.i686 is oldest
erlang < 0:R13B-04.5 obsoleted by erlang-erl_interface-0:R16B-01.1.fc20.1.i686
erlang < 0:R13B-04.5 obsoleted by erlang-et-0:R16B-01.1.fc20.1.i686
erlang < 0:R13B-04.5 obsoleted by erlang-crypto-0:R16B-01.1.fc20.1.i686
erlang < 0:R13B-04.5 obsoleted by erlang-examples-0:R16B-01.1.fc20.1.i686
erlang < 0:R13B-04.5 obsoleted by erlang-sasl-0:R16B-01.1.fc20.1.i686
erlang < 0:R13B-04.5 obsoleted by erlang-compiler-0:R16B-01.1.fc20.1.i686
erlang < 0:R13B-04.5 obsoleted by erlang-inviso-0:R15B-03.3.fc18.i686
erlang < 0:R13B-04.5 obsoleted by erlang-reltool-0:R16B-01.1.fc20.1.i686
erlang < 0:R13B-04.5 obsoleted by erlang-syntax_tools-0:R16B-01.1.fc20.1.i686
erlang < 0:R13B-04.5 obsoleted by erlang-diameter-0:R16B-01.1.fc20.1.i686
erlang < 0:R13B-04.5 obsoleted by erlang-eldap-0:R16B-01.1.fc20.1.i686
erlang < 0:R13B-04.5 obsoleted by erlang-erts-0:R16B-01.1.fc20.1.i686
erlang < 0:R13B-04.5 obsoleted by erlang-webtool-0:R16B-01.1.fc20.1.i686
erlang < 0:R13B-04.5 obsoleted by erlang-cosNotification-0:R16B-01.1.fc20.1.i686
erlang < 0:R13B-04.5 obsoleted by erlang-parsetools-0:R16B-01.1.fc20.1.i686
erlang < 0:R13B-04.5 obsoleted by erlang-jinterface-0:R16B-01.1.fc20.1.i686
erlang < 0:R13B-04.5 obsoleted by erlang-dialyzer-0:R16B-01.1.fc20.1.i686
erlang < 0:R13B-04.5 obsoleted by erlang-gs-0:R16B-01.1.fc20.1.i686
erlang < 0:R13B-04.5 obsoleted by erlang-cosTime-0:R16B-01.1.fc20.1.i686
erlang < 0:R13B-04.5 obsoleted by erlang-toolbar-0:R16B-01.1.fc20.1.i686
erlang < 0:R13B-04.5 obsoleted by erlang-tools-0:R16B-01.1.fc20.1.i686
erlang < 0:R13B-04.5 obsoleted by erlang-tv-0:R16B-01.1.fc20.1.i686
erlang < 0:R13B-04.5 obsoleted by erlang-megaco-0:R16B-01.1.fc20.1.i686
erlang < 0:R13B-04.5 obsoleted by erlang-eunit-0:R16B-01.1.fc20.1.i686
erlang < 0:R13B-04.5 obsoleted by erlang-percept-0:R16B-01.1.fc20.1.i686
erlang < 0:R13B-04.5 obsoleted by erlang-ssh-0:R16B-01.1.fc20.1.i686
erlang < 0:R13B-04.5 obsoleted by erlang-asn1-0:R16B-01.1.fc20.1.i686
erlang < 0:R13B-04.5 obsoleted by erlang-erl_docgen-0:R16B-01.1.fc20.1.i686
erlang < 0:R13B-04.5 obsoleted by erlang-ic-0:R16B-01.1.fc20.1.i686
erlang < 0:R13B-04.5 obsoleted by erlang-edoc-0:R16B-01.1.fc20.1.i686
erlang < 0:R13B-04.5 obsoleted by erlang-wx-0:R16B-01.1.fc20.1.i686
erlang < 0:R13B-04.5 obsoleted by erlang-appmon-0:R16B-01.1.fc20.1.i686
erlang < 0:R13B-04.5 obsoleted by erlang-runtime_tools-0:R16B-01.1.fc20.1.i686
erlang < 0:R13B-04.5 obsoleted by erlang-orber-0:R16B-01.1.fc20.1.i686
erlang < 0:R13B-04.5 obsoleted by erlang-stdlib-0:R16B-01.1.fc20.1.i686
erlang < 0:R13B-04.5 obsoleted by erlang-cosFileTransfer-0:R16B-01.1.fc20.1.i686
erlang < 0:R13B-04.5 obsoleted by erlang-cosEvent-0:R16B-01.1.fc20.1.i686
erlang < 0:R13B-04.5 obsoleted by erlang-snmp-0:R16B-01.1.fc20.1.i686
erlang < 0:R13B-04.5 obsoleted by erlang-test_server-0:R16B-01.1.fc20.1.i686
erlang < 0:R13B-04.5 obsoleted by erlang-cosEventDomain-0:R16B-01.1.fc20.1.i686
erlang < 0:R13B-04.5 obsoleted by erlang-cosProperty-0:R16B-01.1.fc20.1.i686
erlang < 0:R13B-04.5 obsoleted by erlang-ssl-0:R16B-01.1.fc20.1.i686
erlang < 0:R13B-04.5 obsoleted by erlang-mnesia-0:R16B-01.1.fc20.1.i686
erlang < 0:R13B-04.5 obsoleted by erlang-debugger-0:R16B-01.1.fc20.1.i686
erlang < 0:R13B-04.5 obsoleted by erlang-pman-0:R16B-01.1.fc20.1.i686
erlang < 0:R13B-04.5 obsoleted by erlang-typer-0:R16B-01.1.fc20.1.i686
erlang < 0:R13B-04.5 obsoleted by erlang-otp_mibs-0:R16B-01.1.fc20.1.i686
erlang < 0:R13B-04.5 obsoleted by erlang-xmerl-0:R16B-01.1.fc20.1.i686
erlang < 0:R13B-04.5 obsoleted by erlang-kernel-0:R16B-01.1.fc20.1.i686
erlang < 0:R13B-04.5 obsoleted by erlang-common_test-0:R16B-01.1.fc20.1.i686
erlang < 0:R13B-04.5 obsoleted by erlang-hipe-0:R16B-01.1.fc20.1.i686
erlang < 0:R13B-04.5 obsoleted by erlang-cosTransactions-0:R16B-01.1.fc20.1.i686
erlang < 0:R13B-04.5 obsoleted by erlang-os_mon-0:R16B-01.1.fc20.1.i686
erlang < 0:R13B-04.5 obsoleted by erlang-inets-0:R16B-01.1.fc20.1.i686
erlang < 0:R13B-04.5 obsoleted by erlang-public_key-0:R16B-01.1.fc20.1.i686
erlang < 0:R13B-04.5 obsoleted by erlang-odbc-0:R16B-01.1.fc20.1.i686
erlang < 0:R13B-04.5 obsoleted by erlang-docbuilder-0:R14B-04.1.fc16.i686
erlang < 0:R13B-04.5 obsoleted by erlang-observer-0:R16B-01.1.fc20.1.i686
# repoquery --whatobsoletes erlang|wc -l
112
10 years, 8 months
Re: BlueZ Status in Fedora.
by Rave it
Am Tue, 13 Aug 2013 23:59:15 +0000
schrieb devel-request(a)lists.fedoraproject.org:
> ----- Original Message -----
> > On 08/02/2013 10:15 AM, Jaroslav Reznik wrote:
> > > Let me know - I'd like to have this one as a Change if it's going to F20
> >
> > I have been coordinating with various people and looks like all teams
> > are go. NetworkManager and PulseAudio changes are slightly lagging
> > behind, but it's probably best if we move forward and try to integrate
> > everything together in Rawhide before branching F20.
> >
> > I've cleaned up the feature page and marked it as ready for wrangler:
> >
> > https://fedoraproject.org/wiki/Changes/Bluez5
>
> The page looks good, thanks for coordination. Just could you please extend
> the scope with resolution for mate bt? Also for contingency plan, I'd like
> to see a real deadline - Beta as a point to revert things as a coordination
> would be needed. Once done, pls let me know and I'll announce it and report
> to FESCo to get an exception.
>
I don't see that adding a bluetooth-panel-applet package is easy for mate/xfce/lxde.
First tests shows me that the removed panel code from gnome-bluetooth isn't independent from the the rest of the code.
I quess for this reason the gnome dev didn't remove /usr/lib64/gnome-bluetooth/libgnome-bluetooth-applet.so.0, which is in latest upstream.
Ok, i need really help to create such a package.
But there is also another simple solution........
gnome-bluetooth dev should add the removed (fallback) panel applet code back.
I'm pretty shure that is more easier for someone who knows the code to do that.
If gnome-bluetooth is the only client after the bluez5 switch which is working in fedora, than it should be work for all desktops, imo.
So adding the applet back would be a noble gesture from gnome to other desktops ;)
PS: i think cinnamon is also affected, because so far i know use cinnamon blueman code in the momment. But i'm not shure in this point.
10 years, 8 months
Heads-up: Obsolete but still included packages
by Michael Schwendt
A couple of obsolete packages is still included in Rawhide. Usually
that means a package has not been retired yet or has been retired
incompletely:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
In some cases, the dead package is only missing the koji block request
in Fedora rel-eng trac. In other cases, the package has not even been
marked a "dead.package" in git yet:
Obsolete ('chktex', 'i686', '0', '1.6.4', '12.fc19')
Obsolete ('classads-devel', 'i686', '0', '1.0.8', '7.fc20')
Obsolete ('classads', 'i686', '0', '1.0.8', '7.fc20')
Obsolete ('classads-static', 'i686', '0', '1.0.8', '7.fc20')
Obsolete ('detex', 'i686', '0', '2.8', '6.fc20')
Obsolete ('drupal6-drush', 'noarch', '0', '4.1', '7.fc20')
Obsolete ('ff-utils', 'i686', '0', '2.4.21', '7.fc19')
Obsolete ('gpp4-devel', 'i686', '0', '1.3.1', '5.fc20')
Obsolete ('gpp4', 'i686', '0', '1.3.1', '5.fc20')
Obsolete ('ibus-table-array30', 'noarch', '0', '1.2.0.20090729', '6.fc20')
Obsolete ('jadetex', 'noarch', '0', '3.13', '14.fc19')
Obsolete ('jaxen-bootstrap', 'noarch', '0', '1.1', '8.2.fc20')
Obsolete ('joystick', 'i686', '0', '1.2.15', '30.fc20')
Obsolete ('kdirstat', 'i686', '0', '2.5.3', '17.fc20')
Obsolete ('latexdiff', 'noarch', '0', '1.0.2', '4.fc20')
Obsolete ('lzma', 'i686', '0', '4.32.7', '10.fc20')
Obsolete ('mate-conf-devel', 'i686', '0', '1.4.0', '23.fc20')
Obsolete ('mate-conf-editor', 'i686', '0', '1.4.0', '3.fc19')
Obsolete ('mate-conf-gtk', 'i686', '0', '1.4.0', '23.fc20')
Obsolete ('mate-conf', 'i686', '0', '1.4.0', '23.fc20')
Obsolete ('metapost-metauml', 'noarch', '0', '0.2.5', '12.fc20')
Obsolete ('nss-myhostname', 'i686', '0', '0.3', '5.fc20')
Obsolete ('openswan', 'i686', '0', '2.6.38', '11.fc19')
Obsolete ('pdfbook', 'i686', '0', '20070930', '10.fc20')
Obsolete ('pdfjam', 'noarch', '0', '2.08', '4.fc18')
Obsolete ('ps2eps', 'i686', '0', '1.68', '7.fc20')
Obsolete ('python-cryptsetup', 'i686', '0', '0.1.4', '6.fc20')
Obsolete ('python-lvm', 'i686', '0', '1.9.2', '3.fc20')
Obsolete ('python-quantumclient', 'noarch', '2', '2.2.1', '4.fc20')
Obsolete ('ruby-gtksourceview2-devel', 'i686', '0', '0.90.4', '2.fc20.1')
Obsolete ('ruby-gtksourceview2', 'i686', '0', '0.90.4', '2.fc20.1')
Obsolete ('seahorse-plugins', 'i686', '0', '2.91.6', '0.5.git1e35fd9.fc18')
Obsolete ('tetex-IEEEtran', 'noarch', '0', '1.7.1', '8.fc20')
Obsolete ('xmltex', 'noarch', '0', '20020625', '21.fc20')
Obsolete ('yum-plugin-security', 'noarch', '0', '1.1.31', '17.fc20')
Obsolete ('zeitgeist-datahub', 'i686', '0', '0.9.5', '3.fc20')
10 years, 8 months