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
Cinnamon Spin
by Dan Book
Hello,
I have put together a basic Cinnamon Live spin, and was wondering if this
is something people would like to see become official. It's not ready for
submission quite yet, there is a bit of a hack to change the default
gtk-theme to Zukitwo, as the Adwaita gtk-theme messes up title-bar and
desktop icon colors (something that should probably be fixed upstream, this
happens for any Cinnamon install by default in F21). I'm not a Fedora
packager nor do I have a whole lot of time to put into this, but I am
willing to update and maintain the spin as necessary.
I have the kickstart files in this github repo:
https://github.com/Grinnz/spin-kickstart-cinnamon
And resulting images, which I have briefly tested and installed in a VM:
https://grinnz.com/public/spins-cinnamon/
I added a skeleton wiki page as well:
https://fedoraproject.org/wiki/Cinnamon_Spin
-Dan Book
9 years, 2 months
Re: python-dateutil update
by Zbigniew Jędrzejewski-Szmek
On Mon, Dec 08, 2014 at 09:10:59AM -0700, Pete Travis wrote:
> On Dec 8, 2014 8:51 AM, "Zbigniew Jędrzejewski-Szmek" <zbyszek(a)in.waw.pl>
> wrote:
> >
> > On Sun, Dec 07, 2014 at 04:45:12PM -0700, Pete Travis wrote:
> > > python-dateutil is old[0]. Fedora is carrying version 1.5, and upstream
> > > is up to 2.3 . If you're receiving this mail directly, you are a
> > > maintainer of a package that depends on python-dateutil, and we need
> > > your help.
> > It seems that calibre is fine with the new version. I wanted to update
> > pyton-dateutil to check if calibre works, and it seems that I
> > installed python-dateutil-2.3 with pip --user couple of months ago and
> > calibre didn't seem to mind. There's some dateutil usage in the installer,
> > which I didn't test but which we probably don't care about.
> > https://github.com/dateutil/dateutil/blob/master/NEWS also doesn't seem
> > scary.
> >
> > So I think it's fine it python-dateutil is updated as a calibre dep.
> >
> > Zbyszek
>
> Great, thanks for responding. I'm a *light* calibre user, but I'd be
> happy to help test with a newer dateutil when it becomes available if
> that's the direction you are going.
You can just install the python-dateutil-2.* package and test away ;)
Looking at the list and your annoucement mail again, I wonder if it
might be better to bump python-dateutil to 2.2 again as soon as the
updated python-dateutil15 is available, and simply modify packages
which either explicitly depend on dateutil < 2 or exhibit problems to
depend on python-dateutil15. Proven packagers can do that trivially if
necessary. Otherwise this could drag on for months.
fedocal and python-django-tastypie are the only packages which
explicitly require python-dateutil < 2. If you wish, I can volunteer
file bugs to change the dependency for F21 and rawhide for those two
packages and do it myself after a week if the maintainers don't
respond or are fine with the change (got to use those provenpackager
privs for something :)).
Zbyszek
9 years, 3 months
Best way to use zram in Fedora 21?
by Juan Orti Alcaine
Hi, I know how to manually configure the zram, but what's the best way
to do it?
I've seen the unit zram.service of anaconda-core, and it gets activated
when booting with inst.zram=on, but it looks like very anaconda-centric.
Should something like [1] be packaged and included in the distro? or
maybe we should spin off the anaconda zram.service and do it more
generic.
I think this is a very interesting feature for memory constrained VMs
and other devices.
[1] https://github.com/mystilleef/FedoraZram
9 years, 3 months
5tFTW: Fedora 21, 22, and 19, firewall discussion, and holiday break
by Matthew Miller
Reposted from <http://fedoramagazine.org/5tftw-2014-12-17/>.
Fedora is a big project, and it’s hard to keep up with everything that
goes on. This series highlights interesting happenings in five
different areas every week. It isn’t comprehensive news coverage — just
quick summaries with links to each. Here are the five things for
December 17th, 2014:
Fedora 21 Retrospective: What was awesome? What wasn’t?
-------------------------------------------------------
While Fedora 22 is already rolling into the target zone, we do want to
make sure we look back at this previous cycle and identify things we
can improve — ideally, specific and actionable changes. In the end, we
came out with (another!) great release, but there is always something
to learn. In particular, we ended _yet again_ in a last minute scramble
to get a release we could feel good about signing off on out before the
holidays, and next time around it would be nice to put less stress on
all of our contributors (including the quality assurance team and the
developers needed to make those late fixes.)
There will be more to it than this, but to get started, we have a F21
Retrospective wiki page, to help collect comments and ideas.
* https://fedoraproject.org/wiki/Fedora_21_Retrospective
Fedora 22: Coming up fast!
--------------------------
FESCo (the Fedora Engineering Steering Committee, the elected
organization which oversees technical decisions in the project) has
indicated that we’re back to aiming for the traditional May/October
Fedora release cycle, and although the F22 schedule isn’t finalized yet,
we have a tentative plan calling for a release about 6 months from
now. When you work back from that, it means that there’s really not much
time to think about change proposals for F22, especially if we
subtract out holiday time. So, if you’re thinking of working on
something big, please start getting your proposal formalized — the
tentative deadline is January 20th, 2015.
Fedora 19: End of Life
----------------------
And on the other end of the cycle: it’s time to say farewell to Fedora
19. If you’re running this release, please plan to update before January
6th, 2015, when the last updates will go out. After that, there will be
no further security fixes. The good news is that Fedora 20 was a great
release, and Fedora 21 is *even better*, and I think you’ll be happy
with the upgrade.
* http://fedoramagazine.org/fedora-19-eol-01-06-2015/
Fedora Workstation firewall discussion
--------------------------------------
This week’s big devel-list thread concerned the default firewall
settings in Fedora Workstation. The Fedora Workstation Working Group was
not happy with the user experience offered by blocking incoming “high
ports” by default. Out of the box, nothing is listening on these, but if
one installs software that expects to, it won’t work, and because we
don’t have a good way yet to tie *attempts* to access ports to listening
applications and communicate that to the user, the resulting failure is
invisible.
On the other hand, if you install something and it starts listening and
you didn’t know that, that’s *also* invisible. So, pretty much everyone
recognizes this as a not ideal situation. Everyone involved in the
discussion also is concerned with enhancing user security in practice —
the question is just how to best get there from an imperfect state.
Originally, the Workstation WG asked to disable the firewall entirely.
FESCo asked instead that it be left available, possibly with a
less-restrictive out-of-the-box configuration — the path taken for F21.
If you’re not running Workstation, this doesn’t affect you. If you are,
and would like a different configuration, run the firewall configuration
tool and either edit the Fedora Workstation zone or change the default
zone. (There’s a long list of options, but “public” is a
generally-restrictive choice.)
You can also change the per-network zone. Unfortunately currently wired
networks are all considered as one per interface, but wireless networks
are distinguished individually. This can be done in a number of ways,
but the easiest is to run the network configuration tool (in GNOME
control center — press the overview key and start typing “network”),
select the wifi network in question, press the little gear icon next to
it, go down to Identity (?!), and choose the appropriate firewall zone.
(Again, there’s a long list — go back to the firewall config tool to see
exactly what they all do.)
This is clearly, not the most friendly approach; it’s my understanding
that the desktop designers, network tools team, and security team are
going to work together to develop a better overall solution for Fedora
22 and beyond.
Overall, the mailing list thread stayed relatively positive and
constructive and avoided personal attacks, although there were some
accusations of bad faith actions which do not seem warranted based on
the actual history. It is, however, a case where more transparent
discussion and communication could have helped; that’s something we’re
continually working at making better and might make for a good component
of the F21 retrospective mentioned above.
* https://lists.fedoraproject.org/pipermail/devel/2014-December/205010.html
Christmas break
---------------
Of course things in Fedora never really stop, but it’s vacation time for
many of us. Before I was a Red Hat employee, I was used to seeing
extended days off as ideal for getting in some serious work on Fedora.
Now, things are strangely inverted, and I’m going to use the time to
unplug a bit. I’ll be back in January all recharged, and will catch up
with everything that’s happened in the meantime — FtFTW will resume the
week of January 15th — or possibly the week before, but let’s save the
hard-to-keep resolutions for New Year’s Day. :)
Check out the Fedora vacation calendar to see who else will be away,
and make sure to add yourself if you will be too. (There's even a
Fedora badge for doing so!)
* https://apps.fedoraproject.org/calendar/vacation/
* https://badges.fedoraproject.org/badge/vacation
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Fedora Project Leader mattdm(a)fedoraproject.org <http://fedoraproject.org/>
9 years, 3 months
Firefox Aurora in rawhide
by Alexander Ploumistos
Would it make sense to include Firefox Aurora / Developer Edition in
rawhide?
9 years, 3 months
Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments
by Alexander Ploumistos
I've been meaning to write this for a week, but I wanted to do some
research first. The more I read and thought on it, the issue became
broader, the subject line kept changing and this message starting looking
like an article. I will try to choose my words carefully; I do not intend
to offend anyone nor do I want to appear biased.
I hadn't used any graphical package manager on fedora for almost a decade
(yumex was the last one) because I had been burned too many times and I
don't trust them, but after doing a little work in the AppData area, I
thought I'd take a look at gnome-software. It is one of the most beautiful
UIs I have ever seen. It is elegant, simple yet functional, tidy, gorgeous
to look at and it manages to stand out from all the other "market" or
"store" applications. It incorporates some of the competition's best
features, while avoiding their pitfalls (try living with Ubuntu's software
center for a couple of days). I wholeheartedly agree with Richard Hughes in
that software centers compliant with the AppStream specification help
promote applications and are beneficial to both the users and the
developers.
About a week ago, while wondering why MATE applications do not appear in
gnome-software, Richard was kind enough to point to a blog post from
September 2013:
http://blogs.gnome.org/hughsie/2013/09/19/gnome-software-on-mate-and-xfce/
I thought that developers and users might find it useful, so to quote
Richard:
> *tl;dr:* If you want to run GNOME Software on MATE or XFCE you need to
> set an environment variable like
> GNOME_SOFTWARE_COMPATIBLE_PROJECTS=MATE,GNOME,XFCE
>
This might have gone unnoticed since then, but I think it is an issue worth
(re)visiting.
I can understand and defend the design choices that have been made;
allowing a user to mix and match packages from different DEs with different
aesthetics, compiled against different/incompatible libraries or having
three different applications appear as "Text Editor" or "Dictionary" would
lead to a sub-optimal user experience. From that standpoint it makes sense
to hide from the user packages tied to other DEs, especially if the same
functionality is provided by Gnome packages. Of course, a user might
install an application e.g. compiled against gtk2 and the result would be
the same.
I have not tested this much in other Fedora versions, only in F22 with
GNOME. There, the default value in org.gnome.software compatible-projects
is set to 'GNOME', 'KDE', 'XFCE'.
(see
https://mail.gnome.org/archives/commits-list/2013-November/msg00656.html)
I do not understand this particular choice to include some DEs and exclude
others. Why not enable or disable all of them? LXDE and MATE developers
might be prone to attribute this to malice. Personally, on almost every
machine I use, I have mixed packages from various sources - some due to
personal preference, others because they offer unique functions.
Then again, does gnome-software aspire to be a "universal" package manager
on Fedora? If it does, then why not offer packages from every DE and
metapackages for other environments? If gnome-software aims to be
novice-user-friendly, at least the latter should definitely be an option. Let's
not forget that Gnome is a modern desktop environment, that requires fairly
modern hardware to run on and that is not always available. Also, can
gnome-software be the distro-wide default package manager while adhering to
the HIG?
Allow me to digress a bit. Sometime in 2000, my professor told me that in
order to use some molecular modeling packages and to modify their FORTRAN
source code, I had to get linux, so after some searching, I went to a local
bookstore and bought SuSE 5.3 or 6.0, can't remember any more (on a 56k
analog modem at the time, downloading the iso or doing a network install
was out of the question). The box came with two massive manuals (and some
cute stickers) from which I learned the concept of the window manager or
desktop environment. The choices I had been given got me really excited
(almost as much as when I got my mouse wheel working) and after some weeks
of playing with each DE, I routinely switched from KDE to enlightenment or
to fvwm, according to the requirements of the task at hand, or just my
mood. For years I kept the habit of alternating between almost every
environment that was packaged for my distro, until I did not have the time
to keep up with every change, so I settled with GNOME (mostly). Then came
GNOME 3 and in the ensuing upheaval I gave every other DE another try.
These days I use GNOME on my workstation, MATE on a netbook I take with me
whenever I have field work (which sometimes literally means working in a
field) and on an ancient dual Athlon MP workstation. On some other systems
I manage or have lying around, I run E19, XFCE, MATE and GNOME.
I have converted many friends and acquaintances over to linux, but for the
past 2-3 years I don't think I have pointed anyone to anything but Ubuntu
and I feel some guilt about it. For a number of reasons I can't quite put
my finger on, Fedora does not "feel right" for newcomers. The upgrade
process, software management and support time-frame are certainly among
them. Most of these otherwise bright people have their IQ drop to the value
of its logarithm when they sit in front of a computer screen and they all
seem to suffer from a natural aversion towards the terminal and towards
RTFM. I'm sure you are all well aware of them. When you tell them to go to
fedoraproject.org and download the iso, you can be certain that a phone call
is imminent, asking for step-by-step instructions, even though everything
is well-documented. Explaining to them the difference between linux and
distribution is hard and if you start talking about spins, they lose you.
If they decide to search for a solution to an issue by themselves, they
have no problem executing any commands they may find in a blog post from
2005, ignoring all the error messages that inevitably come along and then
they will look genuinely surprised because something broke. Last week I
upgraded my old workstation to F21. It has a GeForce 6800 that whenever I
had used nouveau instead of nvidia's driver, seriously overheated and the
computer sounded like the vacuum cleaners of yore. After the upgrade, I
couldn't get to gdm, but entering MATE manually worked, so after a little
digging, I found out about an issue with mutter and nvidia's driver. I
tried a newer version of the driver from rpmfusion's build system, that
didn't work, so I switched to lightdm. Now imagine one of those people,
being faced with the same issue right after the adrenaline rush of
upgrading with fedup. Even I have kept my main system on F20 because I need
CUDA and I can't switch to OpenCL.
Many of these people however exhibited an excitement far greater than mine,
when after complaining about Unity for various reasons, I presented them
with the alternatives. They were happy to spend time trying out other DEs,
pointing out what felt right and what wrong. Some of them tried all of KDE,
Cinnamon, MATE, LXDE, XFCE, GNOME and Enlightenment, for weeks even, before
deciding what worked for them and their workflow. To my semi-surprise, some
of those on higher-spec machines ended up on GNOME, which I thought had a
steeper learning curve compared to most of the others (I still had to tell
them about hidden stuff like gnome-session-properties or to get
gnome-tweak-tool and look in extensions.gnome.org for extensions).
Having said all that, I hear a lot of people complaining about losing users
to Ubuntu, Mint and others, or why things like project Sputnik
<http://www.dell.com/learn/us/en/555/campaigns/xps-linux-laptop> don't
involve our community. The biggest issue here is which is the targeted user
base of Fedora, if there is one? And what are the use cases we want fedora
to cover? Can we have "Freedom" and be "First" and still cater to
everyone's needs?
Well, that's it.
Happy holidays everyone!
9 years, 3 months
Blacklisting of Indian xkb layouts
by Anish Patil
Hi,
We have xkb layouts and m17n input methods to type Indian languages and both gets installed on GNOME by default. So it always creates confusion for uses that which are input methods and xkb layouts. However with xkb layouts one can't write conjuncts or complex characters.
So it would be nice to have include m17n based input methods only, we discussed it over IRC and its log can be found on https://fedorahosted.org/i18n/ticket/36
Please let us know if anyone has better thoughts.
Thanks,
Anish P.
9 years, 3 months