Building and exporting libgbm from the mesa package
by Ilyes Gouta
Hi,
Any reasons on why libgbm isn't being built and packaged in the
current mesa SPEC file? libgbm is a dependency for wayland-demos.
The --enable-gbm configure option depends on --enable-shared-glapi. Is
there any constraint?
-Ilyes
12 years, 1 month
F16 Linux 3.1 soft lockups
by Michał Piotrowski
Hi,
I've noticed some strange soft lockup behaviour on my system (please
see the attachment). Soft lockup appears to be caused by kswapd0
process. It seems to me that in both cases this error occured when I
used "git fsck --full" or "git gc" commands.
--
Best regards,
Michal
http://eventhorizon.pl/
12 years, 1 month
Improvements Eclipse Installation
by sami wagiaalla
Hi,
The way we currently install Eclipse plugins in Fedora is incorrect and
somewhat fragile.
RPM places all the plugin artifacts in the proper directories. However
that does not update the eclipse metadata. This means that until the
next time eclipse starts it is unaware of the newly installed plugins.
Because the user would normally run Eclipse not as root Eclipse does not
have permission to write to the meta data files located in the
installation directory. It therefore creates a parallel version in the
user's home directory ~/.eclipse. This creates a fragile installation
and leads to a whole host of problems.
To improve this I have written apatch which runs the Eclipse reconciler
during rpm installation. The Eclipse reconciler is an Eclipse
application which goes through and checks the installation directories
and updates the eclipse metadata with any newly installed plugins.
To add support for this in your eclipse package you have to add the
following line to your rpm spec file:
%_eclipse_pkg [package name]
Here is an example from the eclipse-rse spec file for the
eclipse-rse-sdk rpm:
%package sdk
[...]
%_eclipse_pkg sdk
The above macro expands to the following:
%post sdk
touch /var/run/eclipse/run-reconciler
%postun sdk
touch /var/run/eclipse/run-reconciler
if [ $1 == 0 ]; then
eclipse-reconciler.sh
fi
%posttrans sdk
eclipse-reconciler.sh
I apologize if you have experienced instability in Eclipse installations
on rawhide, it is probably due to these changes. Please let me know if
you have any comments questions or suggestions.
I will be filing a request to update the Eclipse packaging guidelines.
If you are interested in the details of the work, here is a summary in
the form of a patch: http://fpaste.org/pPEC/
Cheers,
Sami
12 years, 2 months
gsmartcontrol, gparted problems with userhelper and X credentials?
by Eric Smith
Recently my package for gsmartcontrol was approved, and it is now in
Fedora 16.
I was using Fedora 14 on my desktop system when I did the packaging
work. I did test it on a Fedora 16 system before submission. Since
then I've done a fresh install of Fedora 16 on my desktop. Now if I try
to launch gsmartcontrol from the Gnome Shell, I get the prompt from
userhelper for my password, but it fails to run. From the command line,
the same thing happens, but at least it shows the error message
"Gtk-WARNING **: cannot open display: :0".
Doesn't userhelper pass the X credentials? I'm sure this was working
for me on Fedora 14, and I don't remember configuring anything special.
I thought I'd see how gparted deals with the same issue, and find that
on my system gparted gives exactly the same behavior.
Is there something else I need to put into the gsmartcontrol spec to
make this work properly in F16?
Thanks!
Eric
12 years, 2 months
new comps group proposal: Virtualization Host
by Alan Pevec
Hi all,
I'd like to add a new group in comps.xml to make it easier to install
minimal hypervisor based on Fedora.
It would include only basic virtualization software (libvirt and
qemu-kvm) and it would serve as a base to install virtualization
management stack on top of it.
Initial use-cases are:
- Fedora oVirt host where vdsm agent is installed on top of proposed
Virtualization Host group
Also oVirt Node livecd kickstart would use that group instead of the
current list of packages:
http://gerrit.ovirt.org/gitweb?p=ovirt-node.git;a=blob;f=recipe/common-pk...
- Openstack nova nodes where various openstack-* packages are
installed, depending on the node configuration (compute, controller,
images or object store service)
Since comps groups can't be extended, flow is to choose Minimal on the
initial Anaconda screen, then Customize Now:
* http://apevec.fedorapeople.org/virtmin1.png
In the next step, under Base System category, new "Virtualization
Host" group is choosen.
* http://apevec.fedorapeople.org/virtmin2.png
This should produce a working hypervisor with networking where
additional packages can be installed using yum.
Questions for this list are:
- do you think there's value to have this "Virtualization Host" option
in the first Anaconda screen, among Graphical Desktop/Software
Development/Web Server and Minimal, to avoid the second step?
This list of options is defined in anaconda and each option maps to
a list of actual comps groups
- any better suggestions for the name of the group, maybe
"Virtualization Minimal", "Minimal Hypervisor", "Virtualization Node"
?
Thanks,
Alan
12 years, 2 months
Fedora 17’s unified filesystem (/usr-move)
by Harald Hoyer
Hello Testers and rawhide Users,
Fedora 17 will locate the entire base operating system in /usr. The directories
/bin, /sbin, /lib, /lib64 will only be symlinks:
/bin → /usr/bin
/sbin → /usr/sbin
/lib → /usr/lib
/lib64 → /usr/lib64
Some reasoning behind this change is outlined here:
http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge
The official Fedora 17 feature page is here:
https://fedoraproject.org/wiki/Features/UsrMove
The needed changes to implement the unified filesystem are about to land in
rawhide soon. New installations of rawhide/Fedora 17 will install the symlinks
right away, and no special care needs to be taken
Currently installed systems need some manual steps to convert the current system
to match the layout of rawhide/Fedora 17. After that, the system can continue to
be updated with YUM as usual.
Some RPM packages in rawhide/Fedora 17 will carry a RPM dependency guard, which
will make sure, they can only be installed when /bin, /sbin, /lib, /lib64 are
symlinks and not directories like in Fedora 16 and older.
The installed system’s base filesystem layout can not be safely altered, while
the system itself is running on top of it. Dracut, the initramfs used to find
and mount the root filesystem, can be instructed to convert the filesystem to
match rawhide/Fedora 17’s expectations.
A screenshot of a successful conversion process is here:
http://people.freedesktop.org/~kay/usrmove-convert-log.png
The packages, which are about to land in rawhide, are at this moment available
via the ‘f17-usrmove’ koji tag. They are ready for testing now. Any tests,
preferably in virtual machines or snapshots, where failures are acceptable, are
more than welcome, and any feedback is greatly appreciated.
Keep in mind, that this still needs wider testing and a possible bug in the
conversion logic might break an installed system. Please be careful with your
data, do not try this on a production system, and always have a backup of your data.
If your system has a split-off /usr, a separate mount point, the dracut /usr
mount conversion logic for /usr on NFS is not yet supported; we are working on
it. /usr on iSCSI, FCoE, NBD although is supported, as long as “netroot=...” is
specified on the kernel command line for these disks (see man dracut.kernel(7)).
Please report any issues regarding the /usr-move test (not general rawhide bugs)
by replying to this email, by sending an email to the fedora-test list
<test(a)lists.fedoraproject.org>, or by grabbing ‘haraldh’ or ‘kay’ on IRC
#fedora-devel on freenode, or contact us by email directly.
The final guard in RPM is not yet enabled in the ‘f17-usrmove’ koji tag version
of the packages. Make sure you never install any of the packages below this tag
on an unconverted system, it will not be able to bootup. Before the packages hit
rawhide, the guard will be enabled and safely prevent these packages to be
installed on unconverted systems.
At the moment, we are still waiting for an updated RPM in the koji buildsystem,
which provides the runtime check for the filesystem guard. After this is
resolved by Fedora Release Engineering, we can go ahead and enable the needed
guard and move the packages from the ‘f17-usrmove’ koji tag to ‘rawhide’:
https://fedorahosted.org/rel-eng/ticket/5034
This is the screen log of a full conversion and update process:
http://people.freedesktop.org/~kay/usrmove-convert-log.txt
Here are the steps to prepare your system, to convert it, and to be able to
continue updating your installed system with YUM:
Download and install the most recent dracut package from rawhide:
# yum --enablerepo=rawhide update dracut
Update the installed initramfs image for your current kernel, and instruct
dracut to include the dracut module to convert your current filesystem:
# dracut --force --add usrmove
If dracut detects ‘rd.usrmove’ on the kernel command line at bootup, it starts
the filesystem conversion of the root filesystem.
Change the following kernel commandline parameter directly in the bootloader
menu, which is shown during bootup, or edit the line in /etc/grub*.cfg.
- remove “ro”
- append “rw” to let dracut mount your root filesystem writeable
- remove “rhgb” to hide the graphical bootsplash
- append “rd.info” to get a more verbose output from dracut
- append “rd.usrmove” to enable the /usr-move conversion script in dracut
- append “selinux=0” for now, because the relabeling in a converted F16 system
does not seem to work properly at this moment
During bootup, dracut will now convert your filesystem, and /lib, /lib64, /bin
and /sbin should then all be symbolic links to the corresponding directories in
/usr.
After the conversion, the system needs to be immediately updated to rawhide. No
packages from F16 or F15, or older rawhide packages must be installed anymore.
Make sure to disable any F15 and F16 repositories in yum!
Any files with conflicting names, which the conversion could not resolve, will
be backed up to files named *.usrmove~ residing in /usr/lib, /usr/lib64,
/usr/bin and /usr/sbin.
The log messages, which dracut has generated during bootup, can be retrieved with:
# dmesg | grep dracut
After a successful conversion, revert the changes made to the kernel command
line in the bootloader config file /etc/grub*.cfg.
SELinux relabelling should take effect after you rebooted your updated system
and can take a long time (at least in a VM it takes insanely long and is still
not finished). We are currently investigating, what seem to take so long, so you
might consider to test with SELinux disabled for now.
Until the rawhide repository gets all the converted rpms, use the f17-usrmove
repository to update the system after the filesystem conversion and disable
rawhide in the file /etc/yum.repos.d/fedora-rawhide.repo
Add f17-usrmove in the file /etc/yum.repos.d/f17-usrmove.repo
[f17-usrmove]
name=Fedora $releasever - $basearch
failovermethod=priority
baseurl=http://koji.fedoraproject.org/repos/f17-usrmove/latest/$basearch
enabled=1
metadata_expire=1d
gpgcheck=0
# yum clean all
# yum upgrade
After upgrading, all should be set and done.
Have fun with your system and say “Good bye” to /bin, /sbin, /lib, /lib64 and
meet them in /usr.
:-)
12 years, 2 months
Unity For Fedora (As in OpenSUSE or Arch)
by Manuel Escudero
I don't know if you're aware of this or not, but a user managed to
port Ubuntu's Unity to OpenSUSE 12.1 as you can see here:
http://en.opensuse.org/openSUSE:GNOME_Ayatana
And also I've been told this desktop is available for
ArchLinux now as well... As for this facts I was wondering
how feasible is to port Unity to Fedora as well (Now that
we have OpenSUSE RPM packages of the Unity sources and deps
available to play with) and if someone is interested in trying
to bring the Unity Desktop to Fedora....
If no one is, I was wondering where is a good place to start
trying to do it so I can try it myself and then maybe I gather some
other interested ones...
--
Manuel Escudero
Linux User #509052
Twitter: @Jmlevick <http://twitter.com/Jmlevick>
Blogger: Blog Xenode <http://xenodesystems.blogspot.com/>
PGP/GnuPG: E2F5 12FA E1C3 FA58 CF15 8481 B77B 00CA C1E1 0FA7
Xenode Systems - xenodesystems.com <http://www.xenodesystems.com/> - "Conéctate
a Tu Mundo"
12 years, 2 months
New gcc 4.7 c++ error
by Orion Poplawski
I am getting the following error building paraview with gcc 4.7:
In file included from
/builddir/build/BUILD/ParaView-3.12.0/Qt/Core/pqAnimationScene.cxx:57:0:
/builddir/build/BUILD/ParaView-3.12.0/Qt/Core/pqServerManagerSelectionModel.h:75:30:
error: calls to overloaded operators cannot appear in a constant-expression
code snippet:
class PQCORE_EXPORT pqServerManagerSelectionModel : public QObject
{
Q_OBJECT
public:
/// Supported selections flags. These are a subset of
/// QItemSelectionModel::SelectionFlags.
enum SelectionFlag {
NoUpdate = QItemSelectionModel::NoUpdate,
Clear = QItemSelectionModel::Clear,
Select = QItemSelectionModel::Select,
Deselect = QItemSelectionModel::Deselect,
ClearAndSelect = Clear | Select
};
Q_DECLARE_FLAGS(SelectionFlags, SelectionFlag)
It's the ClearAndSelect line that generates the error. Any thoughts or
suggestions would be appreciated.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
12 years, 2 months
SELinux-related Rawhide breakage today
by Jerry James
After installing today's Rawhide updates on an x86_64 VM, I started
having troubles running programs. Nothing linked with libselinux.so.1
could actually open that library; the programs were getting EACCESS on
the attempt. I figured I needed to do a relabel, but since restorecon
is linked with libselinux.so.1, .....
I touched /.autorelabel and rebooted. The system couldn't even shut
down, so I had to do a sync and a forced shutoff. When the system
came back up, it immediately started complaining about lots of
programs that were unable to load libcrypt. So I forced it off again
and rebooted with enforcing=0. That worked, but skipped the
relabeling step! I got a root shell and ran restorecon by hand to
relabel. The only file that got relabeled was this, which looks
wrong:
restorecon reset /lib64/libproc-3.2.8.so context
system_u:object_r:lib_t:s0->system_u:object_r:default_t:s0
Is something broken in SELinux land today?
--
Jerry James
http://www.jamezone.org/
12 years, 2 months