Status of libX11 / libxcb
by Paulo Cavalcanti
Hi,
I would like to know what is the current status of libX11 / libxcb,
specifically related to
Bugzilla Bug #254144 (not thread-safe?).
I had to downgrade libX11 to the F7 version in F8,
because of this bug.
Although jre from sun (necessary
for accessing some secure web sites) can be
made to work without downgrading libX11,
some other applications cannot, such as xvidcap.
It is not clear to me whether the applications should be
fixed, or if libX11 is really buggy, as it seems.
Thanks.
--
Paulo Roma Cavalcanti
LCG - UFRJ
16 years, 2 months
Fedora Rel-Eng Meeting Recap 2008-FEB-04
by John Poelstra
Recap and full IRC transcript found here:
http://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2008-feb-04
Please make corrections and clarifications to the wiki page.
== Alpha ==
* Tuesday the bit gets flipped
* http://fedoraproject.org/wiki/QA/9/AlphaTreeTesting is the test
status page
== Reversing the netapp streams ==
* scheduled for today--we're working on pushing it back after the alpha
* change setup so that the content we generate in PHX can be put on a
netapp in PHX
* instead of rsynced to RDU to be put on a netapp in RDU, and then
mirrored by netapp back out to PHX
* this will result in shorter times between compose and visible to the
world for things like rawhide and updates
* may delay the rawhide/updates for a bit
== gcc 4.3 ==
* gcc4.3 is in the buildroots for dist-f9 now, and some fallout has
happened, namely kernel.
* striving to complete a mass rebuild before beta release
== perl-5.10.0 ==
* Feature page: http://fedoraproject.org/wiki/Features/Perl510
* 300 perl dependent packages as a sample set
* these packages were the base for which virtually all of the other
perl dependent packages depend on
* out of those 300 about 60 more to build
* once complete the plan is to merge the new perl and the rebuilt
bits into rawhide
* Fedora is the place where perl-5.10 was really first tested/used and
the development ground for getting all the upstreams ported to the new perl
== IRC Transcript ==
16 years, 2 months
PackageKit, localisation and koji
by Richard Hughes
RPM spec files are rarely localised. This doesn't matter much if you
speak English, but really sucks if you don't. We can't add all
translations to all the packages in the world, but we can do our best to
be clever:
http://people.freedesktop.org/~hughsient/temp/pk-application-extra.png
This is with my locale set to "en_GB" and the libpackagekit results
hardcoded to "fr" - the two will match up eventually of course.
There's new functionality in libpackagekit that lets you query (as a
user) a small cached sqlite repository containing all the localisations
and icon names. The data from this is populated per system
(as root) from a few information sources:
* All the installed desktop files in /usr/share/applications (this works
now)
* Metadata from the online desktop project (to get things like
popularity, WIP)
* Information about non-installed packages generated from the distro
builder (WIP)
I don't think caching the installed icons and shipping them separately
is a good idea, just from a size point of view.
The sqlite database is currently at 200kb in size with over 200
applications installed (i.e. things that ship desktop files) so I'm
guessing it would be few Mb with the entire distro repository of
information in and the online desktop stuff.
Updating the offline repo would be left to the distro packager, as of
course, this stuff is all per-distribution.
Now, for the difficult request. Would it be possible for koji (or some
other tool) to copy the all the compiled .desktop files into a random
directory somewhere after a successful build? In this way PackageKit
will get translations for applications that are not yet installed, and
PackageKit can have the sqlite database populated by an extra
sub-package.
The information has to come from koji, rather than operate on .srpm
files directly, as many applications have to merge a .desktop.in file
with a .po file into a .desktop file. Something like this is what is
going to be done for conary on foresight linux.
I appreciate this would be a pretty giant hack, but there's no way I
could do an "everything" install on every package in fedora just to get
at the desktop files. Ideas welcome.
Richard.
16 years, 2 months
gnome-build: soname bump
by Debarshi Ray
I just built gnome-build-0.2.1 for Rawhide and submitted it as updates
for F-7 and F-8. With this comes a soname bump and although repoquery
shows that all the affected packages are owned by me, I just thought I
would let you all know.
$ repoquery --repoid development --alldeps --whatrequires gnome-build
anjuta-1:2.2.0-4.fc9.x86_64
gnome-build-0:0.2.1-2.fc9.x86_64
gnome-build-0:0.2.1-2.fc9.i386
anjuta-1:2.2.0-4.fc9.i386
gnome-build-devel-0:0.2.1-2.fc9.x86_64
gnome-build-devel-0:0.2.1-2.fc9.i386
Happy hacking,
Debarshi
--
Free software for the Indian community:
* ftp://fedora.glug-nith.org/ (Fedora)
* http://gnu.glug-nith.org/ (GNU)
* http://mirror.wbut.ac.in/ (CRAN, Fedora, Mozilla, TLDP)
16 years, 2 months
Re: rpms/exim/devel exim.spec,1.47,1.48
by Jason L Tibbitts III
>>>>> "DG" == Dennis Gilmore (ausil) <fedora-extras-commits(a)redhat.com> writes:
DG> Log Message: sparc needs -fPIE not -fpie
I recall asking someone about this at the last fudcon and I seem to
recall hearing that some platforms require -fPIE and the other
platforms don't care, so you can just use -fPIE everywhere. Is that
really the case or am I merely confused?
- J<
16 years, 2 months
no debuginfo built - why?
by Neal Becker
I'm putting together a new srpm. It builds fine, but no debuginfo package.
Why not? What triggers building debuginfo?
The word 'debug' does not even occur in the stdout output of the rpmbuild
process. How do I debug this?
16 years, 2 months
.xauth security context
by Jerry James
After a recent selinux-policy update, I ran "/sbin/restorecon -r -v ."
in a terminal where I had done a "su -" for some system administration
tasks to see if anything had changed for root, and got something like
this:
/sbin/restorecon reset ./.xauthUoeNyf context
unconfined_u:object_r:user_home_t:s0->system_u:object_r:user_xauth_home_t:s0
This is repeatable. Login, open a terminal, "su -", "/sbin/restorecon
-r -v ." and you'll get this every time (on F8, anyway). So is
whatever is creating the /root/.xauthGIBBERISH file giving it the
wrong security context on creation, or is restorecon incorrect?
--
Jerry James
http://loganjerry.googlepages.com/
16 years, 2 months