Packagers: incomplete Obsoletes and undead packages
by Michael Schwendt
This is about Rawhide.
The list for F21 is similar, which is especially strange with regard to
any packages that should be marked as dead in dist git already then.
"Dead" = a dead.package file in dist git exists, but builds of the package
are still found in the repo(s). Package has not been retired fully yet.
"Undead" = no dead.package file in dist git found.
"Only obsolete subpackages" = non-trivial, but for some of those cases
there are really some missing Obsoletes tags and an incomplete set of
builds is left in the repo (e.g. a -devel subpkg but its base pkg is
obsoleted).
[...]
Dead and all builds obsoleted:
------------------------------
drwright
obsoleted by: gnome-settings-daemon
python-twisted-conch
obsoleted by: python-twisted
python-twisted-lore
obsoleted by: python-twisted
python-twisted-mail
obsoleted by: python-twisted
python-twisted-names
obsoleted by: python-twisted
python-twisted-news
obsoleted by: python-twisted
python-twisted-runner
obsoleted by: python-twisted
python-twisted-web2
obsoleted by: python-twisted
python-twisted-words
obsoleted by: python-twisted
qca2
obsoleted by: qca
Undead and all builds obsoleted:
--------------------------------
golang-launchpad-gocheck
obsoleted by: golang-gopkg-check
kopete-cryptography
obsoleted by: kopete
kwallet
obsoleted by: kwalletmanager
lxshortcut
obsoleted by: libfm
mate-dialogs
obsoleted by: mate-desktop
min-metadata-service
obsoleted by: min-cloud-agent
openstack-marconi
obsoleted by: openstack-zaqar
php-channel-deepend
obsoleted by: php-deepend-Mockery
php-channel-symfony2
obsoleted by: php-symfony
php-symfony-icu
obsoleted by: php-symfony
python-XStatic-Angular-Cookies
obsoleted by: python-XStatic-Angular
superiotool
obsoleted by: coreboot-utils
xorg-x11-glamor
obsoleted by: xorg-x11-server
zeroinstall-injector
obsoleted by: 0install
Only obsolete subpackage(s):
----------------------------
kactivities ['kactivities'] 4 left
obsoleted by: kf5-kactivities
left: kactivities-devel
left: kactivities-libs
left: kactivities-nepomuk
left: kactivities-nepomuk-devel
mmdb ['mmdb'] 1 left
obsoleted by: mmdb2
left: mmdb-devel
python-twisted-core ['python-twisted-core'] 1 left
obsoleted by: python-twisted
left: python-twisted-core-doc
razorqt ['razorqt-notifications'] 22 left
obsoleted by: lxqt-notificationd
left: lightdm-razorqt
left: razorqt
left: razorqt-about
left: razorqt-appswitcher
left: razorqt-autosuspend
left: razorqt-config
left: razorqt-data
left: razorqt-desktop
left: razorqt-globalkeyshortcuts
left: razorqt-libs
left: razorqt-libs-devel
left: razorqt-openssh-askpass
left: razorqt-panel
left: razorqt-policykit-agent
left: razorqt-power
left: razorqt-runner
left: razorqt-session
left: razorqt-theme-ambiance
left: razorqt-theme-amego
left: razorqt-theme-green
left: razorqt-theme-light
left: razorqt-themes
ruby-gnome2 ['ruby-gtksourceview2', 'ruby-gtksourceview2-devel'] 24 left
obsoleted by: rubygem-gtksourceview2
left: ruby-bonobo2
left: ruby-bonobo2-devel
left: ruby-bonoboui2
left: ruby-bonoboui2-devel
left: ruby-gconf2
left: ruby-gconf2-devel
left: ruby-gnome2
left: ruby-gnome2-devel
left: ruby-gnomecanvas2
left: ruby-gnomecanvas2-devel
left: ruby-gnomeprint2
left: ruby-gnomeprint2-devel
left: ruby-gnomeprintui2
left: ruby-gnomeprintui2-devel
left: ruby-gnomevfs
left: ruby-gnomevfs-devel
left: ruby-gtkglext
left: ruby-gtkglext-devel
left: ruby-gtksourceview
left: ruby-gtksourceview-devel
left: ruby-libart2
left: ruby-libart2-devel
left: ruby-libglade2
left: ruby-libglade2-devel
9 years, 2 months
Un-retiring ice and mumble?
by Carlos O'Donell
Devel,
I would like to un-retire mumble, but that requires ice.
I've just fixed ice to compile on f21 without much effort.
So I think I'll un-retire ice and mumble and maintain them
unless anyone objects.
Is there any reason ice was orphaned and retired other than
lack of interest?
Cheers,
Carlos.
9 years, 2 months
F22 System Wide Change: Django 1.8
by Jaroslav Reznik
= Proposed System Wide Change: Django 1.8 =
https://fedoraproject.org/wiki/Changes/Django18
Change owner(s): Matthias Runge <mrunge(a)fedoraproject.org>
Update python-django to version 1.8.
== Detailed Description ==
Update python-django to version 1.8. Fedora 21 contains version 1.6, which
will become deprecated by upstream, once Django-1.8 is out. This is a change,
impacting many of python-django-* packages.
Django upstream is transparent and announces deprecation far in advance.
== Scope ==
* Proposal owners:
** update python-django to version 1.8. To support maintainers of dependent
packages, a copr repo containing latest Django-1.8 is here: [1]
** A build containing latest Django will be pushed to f22 branch late in dev
cycle. If we decide not to push Django-1.8, nothing will be broken.
** Django 1.8 final release is expected around April 1st, 2015: [2]
* Other developers: update dependent packages to work with Django-1.8
* Release engineering: N/A
* Policies and guidelines: N/A
== Contingency Plan ==
* Contingency mechanism: If we can not make it, we'll keep Django-1.7 from
rawhide.
* Contingency deadline: Fedora 22 Beta release.
* Blocks release? No
* Blocks product? doesn't block a product.
[1] https://copr.fedoraproject.org/coprs/mrunge/django-1.8/
[2] https://code.djangoproject.com/wiki/Version1.8Roadmap#schedule
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
9 years, 2 months
ninja/ninja-build
by Adrian Reber
I am planning to orphan the IRC client ninja. One of the reasons to
orphan it is that there is a build system[1] which has the same name.
In Fedora the ninja build system is called ninja-build which makes it
incompatible with most other Linux distributions[2]. In addition the
current release is from 2002 and upstream does not exist anymore.
Most of the other Linux distributions do not even ship it, although
there are other packages which are called ninja. It seems the name ninja
is already taken multiple times and maybe not a good idea for future
projects.
Adrian
[1] http://martine.github.io/ninja/
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1166135
9 years, 2 months
Taking ownership of html2text on EPEL6
by Troy Dawson
Hi,
I will be taking ownership of html2text on EPEL6.
I am already the maintainer for EPEL7, but I missed the notification
that the EPEL6 version was being orphaned because of filters.
Troy Dawson
9 years, 2 months
amending the new package process
by Nikos Mavrogiannopoulos
Hi,
I've added few packages last year using the new package process:
https://fedoraproject.org/wiki/New_package_process_for_existing_contributors
I'm not sure which fedora body (FPC or FESCO) is responsible for this
document, that's why that mail is sent here. In all cases, I'm
interested on other's feedback on that issue.
My experience with the new package process is that the review process in
Step 6 doesn't work. For some of my packages it took 3 months for a
reviewer to appear, some others more, some where reviewed faster. My
understanding is that it depends on how interesting the package is, how
many packagers you know, or whether you enter the review swap market.
In the first case I speculate it would be easier to review popular
end-user applications, in the second we make reviews possible only for
people who can ask other packagers for the review, and the latter
requires someone who brings a new package to do extra work. I've tried
all of these, and don't like any of them.
I don't have a solution to bring extra resources to reviewing (which
will be the ideal), but I'd like to propose an amendment to allow
bringing packages even if no reviewers are available (the typical case).
Step 6: ... If the proposed package is not reviewed for 2 months, the
package must be reviewed by the submitter, and a git module with the
master branch will be approved.
That is packages which are self reviewed will be added in the next
fedora release, but not the current or previous ones.
I don't like it, as it still sucks, but sucks much less from having a
list a long list such as:
http://fedoraproject.org/PackageReviewStatus/NEW.html
regards,
Nikos
9 years, 2 months
F22 System Wide Change: Change xorg input stack to use libinput
by Jaroslav Reznik
= Proposed System Wide Change: Change xorg input stack to use libinput =
https://fedoraproject.org/wiki/Changes/LibinputForXorg
Change owner(s): Hans de Goede <hdegoede(a)redhat.com>
Replace the current (low-level) input xorg drivers with libinput using the
xorg-x11-drv-libinput wrapper.
== Detailed Description ==
Currently xorg uses different input drivers depending on the device type. This
makes it impossible to do things like middle button scrolling on the
trackpoint on laptops where the trackpoint buttons are software-emulated
buttons on the touchpad. Besides this the xf86-input-synaptics driver was
never really designed for multi-touch touchpads and this causes various
issues.
For Wayland we've been working on a new improved input stack, which is to be
shared by all compositors and lives inside libinput. We plan to replace the
current (low-level) input xorg drivers with libinput using the xorg-x11-drv-
libinput wrapper.
== Scope ==
Besides xorg changes, this will also require changes to the control panel
applets for mouse / touchpad configuration in the various desktop environments,
as those all are hardcoded to use the xorg-x11-drv-synaptics specific
interfaces.
* Proposal owners:
Package libinput and xorg-drv-input-libinput (done), make sure that xorg-drv-
input-libinput has the necessary config interfaces for control panel
mouse/touchpad config applets (wip). Write patches for gnome-control-center
mouse/touchpad capplet. Coordinate with other desktop environments.
* Other developers:
GNOME: merge the gnome-control-center patches. KDE: limits itself to standard
X11 mouse config interfaces, no changes needed. Other Desktop Environments:
adjust control-panel code to deal with xorg-x11-drv-libinput, merge these
changes.
* Release engineering: N/A
* Policies and guidelines: N/A
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
9 years, 2 months
Configurable version of suexec in Debian but not Fedora?!
by Neal Gompa
So a friend of mine has been wrangling with suexec trying to configure it
for his needs, and he has become quite furious over the fact that suexec
isn't configurable.
Then he finds out that Debian actually has a version of suexec[1] that lets
you use a conf file to configure suexec. My question is, why the heck isn't
this in Fedora? How is it that Debian can offer both versions[1][2], but
Fedora cannot?
I'm honestly surprised that Fedora doesn't offer this little piece of
flexibility. I would think that this would be in Fedora and RHEL, because
of how useful this would be. So what's going on here?
[1]: https://packages.debian.org/sid/apache2-suexec-custom
[2]: https://packages.debian.org/sid/apache2-suexec-pristine
--
真実はいつも一つ!/ Always, there's only one truth!
9 years, 2 months
NowpPublishing fedora developer PGP keys in DNSSEC
by Paul Wouters
Hi,
Fedora is probably the First to use OPENPGPKEY at a large scale.
https://tools.ietf.org/html/draft-ietf-dane-openpgpkey-01
Everyone[*] who added a GPG keyid in FAS has their key published now
using the OPENPGPKEY specification. You can obtain a key using the
openpgpkey command of the hash-slinger package:
paul@bofh:~$ openpgpkey --fetch pwouters(a)fedoraproject.org
-----BEGIN PGP PUBLIC KEY BLOCK-----
Comment: pwouters(a)fedoraproject.org key obtained from DNS
Comment: key transfer was protected by DNSSEC
Version: GnuPG v1
[blob]
Note that during FAS processing I found out that:
1) there are many nonsense values instead of keyid's in the fas field
(some put in their fingerprint, which is not useful without a key,
some had multiple keyids, and one person managed to unicode kill
python-gnupg by putting their name in there)
2) most people don't have their fedoraproject.org as uid on their key
3) a LOT of keys were expired - I still put these in the zone
4) the gpg/python-gnupg minimal export still caused some keys to be too
big for dns. I simple removed those keys from the zone data.
5) almost all these keys are old keys of which I could forge a fake
matching keyid and upload it to public key servers.
This last item is important because we sadly did not store the actual
public keys in FAS, but only their keyid. We should really change that.
Updating your key in fas does not yet automatically update the
OPENPGPKEY record in DNS.
If you are brave, you can install openpgpkey-milter on your mail server,
and it will start to automatically encrypt email to those
fedoraproject.org email addresses that have keys associated with them.
If you want to run this yourself in other domains, you can use the openpgpkey
command to generate these records for keys in your local gnupg keyring:
openpgpkey --create paul(a)nohats.ca
See further man openpgpkey
Paul
ps. thunderbird/enigmail support anyone? GSoC? :)
9 years, 2 months
RFC: xserver update strategy in F21+
by Adam Jackson
Since the modular X repackaging in FC5, we have limited X server updates
such that the ABI does not change. F20 shipped with xserver 1.14.4, for
example, so we might update it to 1.14.7 but not to 1.15.0. With the
reduced driver set in F21 it's now much more reasonable to push updates
to older releases as well.
With that in mind, I ask for feedback on how we'd actually like that to
work. The kernel rebase policy seems like a pretty reasonable model:
F21 would stay on 1.16.x until there's an upstream 1.17.1 release, and
(if F20 were to be affected by this policy) F20 would wait until 1.17.1
had been tested in F21.
One thing we might have to play by ear is the interaction with binary
drivers. The nvidia legacy driver, for instance, does not always have
builds available for arbitrarily new servers, which means updating the X
server might change you to an nvidia driver that no longer supports your
hardware. Depending on how severe that cutoff is, it might be cause to
pin a particular Fedora release at a given server version. I don't
think this is presently a problem, but it could be in the future.
This would also want some coordination with the various desktop
environments; the version of KDE in F21 might have latent bugs only
exposed by switching to F22's X, for example. I have a reasonable idea
of how to test Gnome for that kind of thing, but for the others I'd need
some pointers.
So what do we think? Good idea? Bad idea? Other things to watch for?
- ajax
9 years, 2 months