I reported the large memory leak in clock-applet:
(TLDR: clock-applet grows by 1GB/day when reporting weather)
Since clock-applet is a default install on every Fedora, I thought this
would be widely reported---it essentially makes the system unusable
within a day or two if you run into this problem---but that doesn't
seem to be the case. I guess people don't see it because nobody
Anyway, I am looking for a way to debug this: I tried attaching GDB to
the running process but the results are unreliable (see BZ). I couldn't
figure out how to run valgrind on the executable: it has to be run in
the context of the Gnome panel, so how do I tell it to run 'valgrind
/usr/libexec/clock-applet', and how do I get access to the results?
Is there another way?
I co-maintain a package that contains a library that is used as module
for a server.
The 32 bits version of this library is pushed automatically into the 64
bits repositories (i.e. in epel6),
which doesn't make much sense, since the 64 bits version of the server
won't run with the 32 bits
This wouldn't be a big problem, but the pushed 32 bits rpm has a dependency
on the 32 bits server, so then I will get complains (with reason) about
the broken package.
globus-gridftp-server-progs is the server, and dpm-dsi is the module.
So my question is: how should I approach this? I got some suggestions in
Is there any way I can prevent this rpm from being copied into the 64
On 2013-04-23 18:19, Tom Callaway wrote:
> On 04/23/2013 12:05 PM, Alec Leamas wrote:
>> Just a double check: whether I symlink or patch the css files, the
>> system path must be accessible for the web app. Is this really true in
>> general, isn't it depending on the web server configuration?
> Hmm. I think if you couldn't use the system copy for those technical
> reasons... well, there is a nasty way to do it with triggers to handle
> copying, but I'm not sure I can recommend that in good conscience.
> You could simply copy the font in a %post scriptlet, but if it ever got
> updated, you'd be using an old copy. If you copy it from BuildRequires,
> it would only get updated on new builds, but I think that method might
> be the simplest. You'd need to ask for a bundling request, but I'm
> pretty sure I'd support it.
> Fedora Project
Hm... unless there is more input on this I'll go for the BuildRequires +
bundling exception. This will take some time, have some fonts to package.
There will probably be more of this, fedora-review is updated with a new
test looking for bundled font files.My gut feeling is also that there
are some other bundled fonts in existing packages...
we have two kernels build on F18 that fix security problems and in F17
kernel-3.8.8-100.fc17 still in updates-testing and kernel-3.8.8-102.fc17
is not even in updates testing, shouldn't this kernels be push to
stable , due a security fixes ?
Sérgio M. B.
In a large package (openerp7) I have found some bundled .ttf and .otf
font files. One of these (Inconsolata) seems to exist in Fedora as
levien-inconsolata-fonts, the others (see below) I cannot find with a
The fonts are parts of specific addons (a. k. a. plugins). They are
referenced with explicit paths in various .css or css/* files.
The entypo-webfont.ttf seems to have a working upstream
I cannot find an upstream for mnmliconsv21-webfont.ttf, hint is that
it's generated by "Font Squirrel" ?!
There seem to be an upstream for zocial-regular-webfont.ttf, at
https://github.com/adamstac/zocial, providing a woff file.
Now, what should I do with these? Packaging GL tells me to "avoid"
bundling ttf/otf files. What's this in this case?
Utterly confused. Any hint, out there?
For the first time, Fedora release name have non-ascii and pelican
Could we consider change release name from "Schrödinger's Cat" to
"Schrodingers Cat" or other name that not have this additional
Sérgio M. B.