We've run into a very strange problem that only started literally in
the last few days. Koji builds in F20 and Rawhide branches are
After a mammoth debugging exercise, it appears to come down to various
programs failing (in %check) because they try to create files under
In Koji, $HOME/.config is /builddir/.config which is now owned by
root. I added some debugging to my Koji build to see more clearly
+ echo HOME=/builddir
+ ls -al /builddir
drwx------. 5 mockbuild mockbuild 4096 Sep 1 22:35 .
dr-xr-xr-x. 18 root root 4096 Sep 1 22:23 ..
-rwxr-xr-x. 1 mockbuild mockbuild 18 Aug 9 12:08 .bash_logout
-rwxr-xr-x. 1 mockbuild mockbuild 193 Aug 9 12:08 .bash_profile
-rwxr-xr-x. 1 mockbuild mockbuild 231 Aug 9 12:08 .bashrc
drwxr-xr-x. 3 mockbuild mockbuild 4096 Sep 1 22:35 .cache
drwxr-xr-x. 3 root root 4096 Sep 1 22:24 .config
-rw-rw-r--. 1 mockbuild mockbuild 211 Sep 1 22:23 .rpmmacros
drwxr-xr-x. 9 mockbuild mockbuild 4096 Sep 1 22:23 build
+ ls -al /builddir/.config
drwxr-xr-x. 3 root root 4096 Sep 1 22:24 .
drwx------. 5 mockbuild mockbuild 4096 Sep 1 22:35 ..
drwxr-xr-x. 2 root root 4096 Sep 1 22:24 fontconfig
So I guess fontconfig has something to do with this, although I'm not
sure exactly what.
But anyhow, this isn't right is it?
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
that's the truth behind the theory and no i can not help
to debug this because i spent the last month in dbmail
upstream debugging until find out that the last issues
are simply caused by the *non*-drop-in-replacement and
i have to return to my daily job for now
-------- Original-Nachricht --------
Betreff: Fwd: [Dbmail] MariaDB and dbmail
Datum: Sun, 01 Sep 2013 23:37:13 +0200
Von: Reindl Harald <h.reindl(a)thelounge.net>
An: Mailing-List dbmail <dbmail(a)dbmail.org>, Mailing-List mariadb <"maria-discuss"@lists.launchpad.net>
please can someone from the MariaDB developers
MariaDB 5.5.32 is running here on test-machines
this is todays feedback of the dbmail core-developer and beause
more and more distributions including Fedora/OpenSuSE and AFAIK
even RHEL7 switch to MariaDB this is a *serious* problem which is
not what a "drop-in replacement" should do and a show-stopper
rollout Fedora 19 at all in the near future
> Anyway, MariaDB doesn't even pass the basic unit-tests
> Looks like this maybe libzdb related. The ordering of the query
> retrieving mime parts is ok on the console, but *not* when looping
> over the result in libzdb.
> MariaDB is *no-go* at this moment. Just what I experienced a year
> ago or so. I'm sorry, but I don't think I'll hold 3.1.4 for that
> not a regression at all.
-------- Original-Nachricht --------
Betreff: Re: [Dbmail] MariaDB and dbmail
Datum: Tue, 02 Apr 2013 19:47:15 +0400
Von: Sergej Pupykin <ml(a)sergej.pp.ru>
An: DBMail mailinglist <dbmail(a)dbmail.org>
At Thu, 20 Sep 2012 10:46:52 +0800,
zamri <myzamri(a)gmail.com> wrote:
> MariaDB is fully compatible with MySQL. Migration is done. So far so good. Phewww!...
> Now I need to do some research on tuning mariadb if needed.
I found that after migration following SQL returns wrong sorted data:
JOIN dbmail_partlists l ON p.id = l.part_id
JOIN dbmail_physmessage ph ON ph.id = l.physmessage_id
WHERE l.physmessage_id = <ID>
ORDER BY l.part_key,l.part_order ASC;
however when I run it from command line it works well.
Probably it does not fail always because of not all emails damaged.
Not sure if it caused by migration to mariadb, but problem appeared
near same time
I would announce, that I want to unretiring open-cobol for F20+.
This package was retiering due FTBFS issues during the last releases
of Fedora. Due my effort, I was able to fix the issues which caused
I would ask, if there an official policy about unretiring an package.
The background of my question is, that a package which is maintained by me
was retiered due FTBFS issue. Now I was able to fix this issues and want
to unretiring it.
I have done a google search and found a ticket with the statement, that
a review request will been not required when the package was not retired
for more then two weeks.
But because i'M not sure, I would like to ask for any clarification.
Not 100% sure this is the right mailing list, in case this is the wronte
list please direct me to the right place.
Looks like F20 is gonna get Qt 5.1.1 packages and I was wondering if you
could build qtbase enabling GLESv2 support.
This would allow building qtwayland with the official Qt 5.x packages and
don't wait for the next Fedora iteration.
Do you think it is possible?
Out of the box experience