I'm working with F20 and CentOS 7 to create some live booted images. I'm not looking to do live USB/CD media, but rather boot a server over the network with a kernel, initramfs, and squashfs. It's working well so far, but I have a filesystem issue that I can't seem to fix.
My build scripts create a 10GB sparse file and I fill that with an ext4 filesystem. I package that up into a squashfs as specified in the docs. That boots just fine.
However, if I attempt to fill the filesystem, it fills and becomes corrupt much earlier than I'd expect. I've put some log info into a gist.
My expectation is that if I create a 10GB live filesystem and and the system has > 10GB of RAM available, I'd expect that I could store somewhere around 10GB of data in the live filesystem before I run into a full filesystem. Is that expectation incorrect? Am I configuring something incorrectly?
Thanks for taking the time to read this far. :)
At the moment dhcp package contains dhcpd (dhcp server) and dhcrelay
(dhcp relay agent).
I'd like to move dhcrelay into separate subpackage and rename the
(sub)package with dhcpd to something better then 'dhcp'.
Now the question is how to call the new subpackages.
Given that package with dhcp client is called dhclient and not
dhcp-client my first idea has been just 'dhcpd' and 'dhcrelay'.
Other possibilities would be dhcp-server and dhcp-relay-agent
or dhcp-dhcpd and dhcp-dhcrelay.
dhcpd (or dhcp-server or dhcp-dhcpd)
dhcrelay (or dhcp-relay or dhcp-dhcrelay)
> On Tue, 2014-07-29 at 22:40 -0400, Adam Goode wrote:
>> I know this is old news, but Ghostscript switched to AGPL with version
>> 9.07 (Feb 2013). I was not able to find any announcement of this on
>> the Fedora lists.
> Here's the discussion from this list at the time:
Thanks for the background! I'm not sure how I missed it.
I know this is old news, but Ghostscript switched to AGPL with version
9.07 (Feb 2013). I was not able to find any announcement of this on
the Fedora lists.
Fedora 18 was the last release with the non-AGPL Ghostscript.
This is a surprise, because since Fedora 19 we've possibly introduced
a fairly large end-user burden on AGPL compliance, with ghostscript
being rather deep in the dependency tree. Here are just a few of the
affected packages by way of "repoquery --whatrequires --recursive
Is seems like a problem that these packages depend on an AGPL package.
This list suggests to me that running a print server (cups) or XMPP
server (ejabberd) would put a burden on me to comply with AGPL. Am I
My first reaction would be to fork ghostscript at a pre-AGPL version
at this point. Does this seem remotely feasible? Is there a better
(Also, there is another AGPL package, libquvi, which notably has
nautilus and other packages as depending on it. But that's a separate
I'm going to update evolution packages (evolution-data-server,
evolution, evolution-ews and evolution-mapi) in rawhide to their
3.13.4 versions during today, which brings soname version bumps in
evolution-data-server and evolution. I'll take care of rebuilds where
needed (and I have commit rights for).
There are also large changes in 3.13.4, in evolution-data-server are
used subprocesses for backends and evolution uses webkit-based
composer. Please use GNOME's bugzilla  for any issue you might find
Thanks and bye,
We're trying to retire package eclipse-wtp-common on F21 and Rawhide. My
understanding is that this should be done F21 first, then Rawhide. F21
has proven problematic so far.
Bug is here: https://bugzilla.redhat.com/show_bug.cgi?id=1117475
1. Package eclipse-wtp-common is obsoleted/provided by eclipse-webtools
2. A package "administrator" (note: not owner), tries to use fedpkg to
retire, but it fails: Performs dead.package commit, then can't change
point of contact to orphan in the second part of that process.
3. Proven packager comes to help; tries to retire, gets message "You are
not allowed to retire this package."
4. Package owner comes along, tries to retire. Get's a little further in
that the package is now orphan for that branch, but then gets message:
"You are not allowed to retire the package: eclipse-wtp-common on branch
Is there something additional that we need to do, or is there something
in the above sequence of events that has screwed things up? Or is F21 in
some state that is preventing package retirement? Or is it something else?
Thanks in advance for any help that any of you can provide!