I can see that thunderbird 24 had been built successfully and then
reverted on the fc18 branch (and others). The git commit log and the
spec changelog say
Revert to 17.0.8
and nothing else. I do understand that more than a "successful build" is
necessary for a package to be pushed, but can we please agree on putting
some substantial information on "why" (not just "what") into the git log
or change log?
As a guidance, in many git based project, the following standard for git
messages has proven useful:
1st line: short description of "what"
1st paragraph: long description of "what" along the lines of:
So far, "foo" does "bar". Change "froz" so that it does "baz".
2nd paragraph (or mixed in with 2nd): answer "why"
The problem with "bar" is this. "baz" solves the problem by doing that.
This information could also be in bugzilla and linked to from the git
log or changelog, of course. All of this is easier than answering
e-mails or posts, and better for record keeping anyways.
I realize it's been a while since F19 was released but I finally got
around to do a server install. Since there have been a few negative
reviews here of the installation process I thought it might be nice to
have a mostly positive one. Here are my observations:
VLAN setup for installing! Yay! However, after rebooting,
NetworkManager wasn't able to bring it up, something about not knowing
the "virtual interface name". Turned out to be the ethernet interface
name changed from what it was at install time.
Didn't detect my timezone. Not a big deal, but I was hoping it would
since there's been some discussion here about it working.
I'm reinstalling an existing server, so used the custom partitioning.
The only problem I had here was that I clicked on the existing /home
partition to add it to the new install but then couldn't figure out what
to do. All I saw on the right was lots of disabled form items.
Eventually I read the instructions carefully and then looked at the
mount point entry again and saw that it wasn't disabled. I wonder if
there is some way to make it more obvious...
After starting the install, I went to enter the root password. As I was
doing so, the interface appeared to freeze. I switched through the
consoles and when I got back the interface was working again and the
keys that I had typed had shown up. One odd thing I noticed while
cycling through the consoles was that console 6 had a login prompt on
it. I didn't actually try logging in.
The progress bar is strange. All the package installing barely made it
past a quarter of the way.
Other than the ethernet interface naming issue, just minor cosmetic
issues. Thanks to everybody involved in getting the installer in such
Dear bodhi/koji specialists,
perhaps, this is a dumb question:
sometimes after having filed a BZ, I get some email like
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing xxxxx-18.104.22.168-4.beta1.fc19'
as soon as you are able to.
Please go to the following url:
*My question:* if xxxxx consists of a lot of packages, and I'm only
needing some few of them (libreoffice is a good example), how then can I
automatically download only those packages installed on my site?
The usage of "bodhi -D xxxxx....." will download *all* and not only the
locally installed pkgs.
Fedora release 19 (Schrödinger’s Cat): Kernel-3.9.4-302.fc19.x86_64
Joachim Backes <joachim.backes(a)rhrk.uni-kl.de>
On bugzilla there was a brief discussion on how to reduce the number of
blkid calls during udev rules processing:
The general idea was to rely on earlier calls to blkid instead of having
later rules calling blkid themselves. Specifically for bcache this meant
relying on 13-dm-disk.rules and 60-persistent-storage-rules, which all
worked fine until...
...until I tested stacking bcache on top of raid (md). In that situation
61-bcache.rules was out of luck, because there was no prior call to
blkid so bcache was not detected. The straight forward solution appears
to be te call blkid from 61-bcache.rules, this works any way. An
alternative solution might be to move 61-bcache.rules to 65-bcache.rules
so it is run after 64-md-raid.rules, that might work.
In general I'm a little uncomfortable with this: relying that other
rules to call blkid may work most of the time, but not always. If rules
should rely on prior calls to blkid, wouldn't it be better to call blkid
as rule 00-blk.rules or so? In that case no other rule would ever have
to call blkid ever. And yes, it may happen that blkid is sometimes
called without the output actually being used.
Any advice is appreciated,
OCaml 4.01.0 is a new major release of the language.
I'm not expecting any incompatibilities, but it will require a mass
rebuild of the 100 or so Fedora OCaml packages in Rawhide, which I
will do this weekend.
I'm also planning to:
- update the ARM code generator
- enable debuginfo generation, since the OCaml compiler has generated
useful debuginfo for a while now
- tidy up the spec files and try to come up with a modern set of
packaging guidelines, since the de-facto packaging rules have
diverged a little from the guidelines published back in 2008
For people not using OCaml (or even those that are) there shouldn't be
any significant disruption.
More about the new release here:
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
Hi, I need help with an error of clang in mock.
I have this package review:
That builds OK in mock in a x86_64 machine.
A scratch build in koji fails for x86_64 (and probably others)
with the following error (
error: unknown target CPU 'pentium-m'
ERROR:root:Command '['clang', '-O3', '-march=native', '-c',
'mathcode.c', '-S', '-emit-llvm', '-o',
returned non-zero exit status 1
Traceback (most recent call last):
File "setup.py", line 103, in <module>
File "/builddir/build/BUILD/llvmmath-0.1.1/llvmmath/build.py", line
97, in build_targets
File "/builddir/build/BUILD/llvmmath-0.1.1/llvmmath/build.py", line
46, in build_llvm
File "/usr/lib64/python2.7/subprocess.py", line 542, in check_call
raise CalledProcessError(retcode, cmd)
I imaging that -march=native is returning the arch of the builder, that is
not supported. How can I make this work?
Atlas in rawhide is rebased to 3.10.1. It now builds monolithic shared
libraries libsatlas.so and libtatlas.so (serial and threaded, otherwise
identical) which include former lapack, blas and atlas libraries.
Dependent packages need to link -lsatlas or -ltatlas instead of -latlas
I am sorry, have a nice day and happy rebuilding.
-----BEGIN PGP SIGNED MESSAGE-----
Are the dbh package (http://pkgs.fedoraproject.org/cgit/dbh.git/) and
the DBH from http://sourceforge.net/projects/dbh/files/dbh/5.0.7/ same
If yes, why the first is released as 1.0.24 and not as 5.0.7 ?
GPG Key: D400D6C4
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
-----END PGP SIGNATURE-----
What functionality is expected for anaconda's Device Type LVM Thin Provisioning? Right now when I choose this device type for, e.g. home, I still can't choose a Desired Capacity that's larger than free space in the VG. Ergo, I can't create a virtual size LV. Is this expected? And is the main idea in this roll out just to support the better faster thinp snapshots? Or am I missing something?