I am running rawhide for fun and since a few days ago a few seconds
after starting gdm the whole system freezes. I am sorry that I can't
really pinpoint the exact update as I suspend and this only manifested
after a reboot.
The problem is that I don't get any logs and running startx with
"exec gnome-session" in .xinitrc leads to the exactly same problem.
Interestingly, if I run just "gnome-terminal" from my .xinitrc,
close it and then re-run with full gnome-session, I get the shell
and everything seems to work. Well, except it is somewhat sluggish,
suggesting some hidden breakage.
python-markdown has been updated in rawhide to the latest version 2.3,
please check whether your package still works as expected.
There are a some backward-incompatible changes, see
Thomas Moschny <thomas.moschny(a)gmail.com>
On Mon, 18 Mar 2013 14:42:46 -0600
Kevin Fenzi <kfenzi(a)redhat.com> wrote:
> On Mon, 18 Mar 2013 12:31:41 -0400 (EDT)
> Jaroslav Reznik <jreznik(a)redhat.com> wrote:
> > Good point at #fedora-devel right now - we are after branching, so
> > Branch Freeze and Bodhi should be required now. Kevin, Dennis -
> > what's the correct handling of Branch Freeze and when it should get
> > in effect?
> We are not frozen.
> We have branched f19 off rawhide.
> At the alpha change deadline:
> 2013-04-02 Alpha Change Deadline
> is when we go into freeze for alpha and start using bodhi.
> We did the same thing last cycle, although the time between branching
> and alpha change might have been shorter.
On 14. 3. 2013 at 04:58:51, Dan Mashal wrote:
> On Thu, Mar 14, 2013 at 4:56 AM, Jan Zelený <jzeleny(a)redhat.com> wrote:
> > On 14. 3. 2013 at 04:48:33, Dan Mashal wrote:
> >> On Tue, Mar 12, 2013 at 1:46 AM, Jan Zelený <jzeleny(a)redhat.com> wrote:
> >> > Hi guys,
> >> > as per , I'd like to propose some patches for F19 comps. These
> >> > patches
> >> > are splitting group called Development Tools into several smaller
> >> > groups.
> >> > The purpose of this email is to find out if there is something
> >> > fundamentally wrong with the change (except for the fact that it is
> >> > change).
> >> >
> >> > These are key points about the patch set:
> >> > 1. There should be only small visible impact to users. Currently the
> >> > only
> >> > tool that is commonly using comps is anaconda and that uses the
> >> > "Developer workstation" environment. This group will contain all groups
> >> > that were created by the split to ensure maximal similarity to the old
> >> > state of things.
> >> >
> >> > 2. All in all, the Development Tools group needed a huge cleanup, as it
> >> > contained a lot of different tools and/or devel packages but many times
> >> > these were only fractions of development environments necessary for the
> >> > particular purpose. These tools are mostly still avaiable in other
> >> > groups, like C development, Electronic Lab, ...
> >> >
> >> > 3. The current idea for Developer Tools group is to contain just tools
> >> > that
> >> > are common/usable for development of most programming languages
> >> >
> >> > 4. This should bring only the "big picture change". No need to discuss
> >> > what
> >> > particular packages should be in which group. That can be tuned any
> >> > time
> >> > later.
> >> >
> >> > 5. More groups targeted at specific areas should be created and/or
> >> > reviewed
> >> > soon-ish. Among them:
> >> > Perl Development
> >> > Python Development
> >> > Ruby Development
> >> > feel free to suggest more development-related areas that you would like
> >> > to
> >> > improve.
> >> >
> >> > The goal of this effort is to start a process which would lead to more
> >> > usable comps, so users will be able (and more importantly encouraged)
> >> > to
> >> > simply use for example yum to install these environments. By that time,
> >> > these environments should be cleaned up, in case user wants to install
> >> > just specific type of devel env, not the entire "Developer Workstation"
> >> >
> >> > 
> >> > https://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_packag
> >> > e_g
> >> > roups
> >> >
> >> > Thanks
> >> > Jan
> >> > --
> >> > devel mailing list
> >> > devel(a)lists.fedoraproject.org
> >> > https://admin.fedoraproject.org/mailman/listinfo/devel
> >> Please undo this change immediately and wait more than 2 days before
> >> you split such a massive group of important packages.
> > Dan,
> > thanks for your input. Did it break something for you? As I indicated
> > above, the split itself should have no effect for vast majority of users.
> > The only thing that might have some impact is the cleanup of packages.
> > However that impact will not be major, as many of these packages are in
> > different developer- focused groups anyway.
> > Thanks
> > Jan
> I haven't been able to find out yet because my rawhide machine is
> broken but, intltool definitely needs to stay there.
Well, feel free to re-add it if you think that it is common tool that
developers regularly use. I don't share that thought but I certainly welcome
your input and I won't be angry at all if you put it back there.
> We already have too many groups.
I see your point. Yet, at the same time, the bigger problem I observe is that
we have groups that either have way too broad scope or have misc optional
packages that are borderline non-qualified to be in those groups. Such groups
partially loose their purpose to make things more structured and lucid.
-----BEGIN PGP SIGNED MESSAGE-----
F19 has been branched, please be sure to do a git pull --rebase to pick
up the new branch, additionally rawhide/f20 has had inheritance cut off
from previous releases, so this means that anything you do for f19 you
also have to do in the master branch and do a build there.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
-----END PGP SIGNATURE-----
devel-announce mailing list
The python-manuel and python3-manuel packages are changing from
ZPLv2.1 to ASL 2.0 with the release of version 1.7.2. This will
affect Rawhide and F-19 only. I don't expect the license change to
affect any other packages, since manuel is used only to build
documentation, but let me know of any trouble.
Hi Gnome users, developers and friends!
We continue our Test Days ride . You are invited to join Gnome 3.8
Test Day  on this Thursday. Gnome 3.8 final will be released on
2013-03-27. You can test new Gnome 3.8  features  running from
Fedora 19 Live test images and help to make this release better.
List of some features:
* Gnome Classic mode replaces Fallback mode
* new applications: Clocks, Photos
* ownCloud integration
* Initial Setup
* changes in shell: Activities Overview, Message Tray and Integrated
* Privacy Settings and Sharing Settings
* changes in applications: Boxes, Web, Documents
Join IRC #fedora-test-day on FreeNode and ask QA or developers for help,
if you get into trouble. We can try to find workarounds and help you
with debugging. Please report all bugs under appropriate component
preferably at upstream bugzilla https://bugzilla.gnome.org/ regarding
common Gnome 3.8 issues or Red Hat bugzilla http://bugzilla.redhat.com/
if you have problems with Fedora distribution integration. You can also
report other Fedora bugs not related to this Test Day. Feel free to ask
on IRC, if you don't know against which component or on what bugzilla
you should fill the report.
See you in Bugzilla!
Desktop QE, Red Hat Brno
Freenode nick: Martix
I don't think users would expect that install of dnf would without asking (or
control) automatically run dnf-makecache.
At least, this should be controllable via /etc/sysconfig. Further, I think it's
not consistent with Fedora practice to enable this on default by installing the
Since switching to Fedora I've been noticing most Fedora stable updates
are released with a short, helpful description of the update, possibly
including a list of bugs fixed, just like in other major distros. But
unlike other major distros, other updates have less helpful
* "Update to latest upstream version"
* "No update information available"
* "Here is where you give an explanation of your update. Here is where
you give an explanation of your update."
Perhaps the update policy should have a guideline on the minimum amount
of information required in this description. E.g. "update to latest
upstream version" might be a perfectly acceptable description for Fedora
given the fast pace of updates, but I don't think users should ever be
seeing "no update information available" and especially not "here is
where you give an explanation of your update." (And I've seen this one
multiple times within the past couple of weeks.)
I'm not suggesting essays, but at least a unique sentence fragment would
be good for each update. Please? :-)