how to speed up mock?
by Farkas Levente
hi,
we use mock for local package build, but it's very slow. now we install
a new host just for mock with 8core, ram disks etc. it seems it still
slow. first of all most of the time mock use only one 1 core of the cpu.
is there any way to speed up different part of the mock build process?
thanks in advance.
ps. anyway is there any better place to discuss it?
--
Levente "Si vis pacem para bellum!"
13 years
Delayed encrypted partition mount
by Gilboa Davara
Hello all,
I routinely encrypt all important partitions on my laptops /
workstations / servers using LUKS both at home and at work.
However, due to the above, I can no longer remotely reboot the machines
(at least the ones that doesn't have a serial console attached) as I'm
required to baby-sit the machine until the password prompt appears.
My question is simple: Given the fact that I rarely encrypt the root,
can I somehow delay the encrypted partition mount to right-before-gdm,
so all the essential services (samba, nfs, cups) - especially network
and sshd, will be up, so I can remotely type the password required to
mount the encrypted partitions?
I could delete the entries from /etc/cryptab, create a service that will
mount the partitions late in the boot process, but AFAIK, this will not
display the graphical password prompt making it less than ideal...
- Gilboa
13 years
net-tools must die
by Xose Vazquez Perez
hi,
net-tools ( http://net-tools.berlios.de/ ) is deprecated since time ago.
iproute is the way to go.
net-tools future http://lists.debian.org/debian-devel/2009/03/thrd2.html#00780
================
-------- Original Message --------
Subject: net-tools future
Date: Sun, 15 Mar 2009 17:30:18
From: Martín Ferrari <tincho(a)debian.org>
To: debian-devel@(a)lists.debian.org
Hi,
Luk Claes and me, as the current maintainers of net-tools, we've been
thinking about it's future. Net-tools has been a core part of Debian and
any other linux based distro for many years, but it's showing its age.
It doesnt support many of the modern features of the linux kernel, the
interface is far from optimal and difficult to use in automatisation,
and also, it hasn't got much love in the last years.
On the other side, the iproute suite, introduced around the 2.2 kernel
line, has both a much better and consistent interface, is more powerful,
and is almost ten years old, so nobody would say it's untested.
Hence, our plans are to replace net-tools completely with iproute, maybe
leading the route for other distributions to follow. Of course, most
people and tools use and remember the venerable old interface, so the
first step would be to write wrappers, trying to be compatible with
net-tools.
At the same time, we believe that most packages using net-tools should
be patched to use iproute instead, while others can continue using the
wrappers for some time. The ifupdown package is obviously the first
candidate, but it seems that a version using iproute has been available
in experimental since 2007.
So, the roadmap would be:
- Send patches to net-tools using packages to use iproute instead
- Development of the wrapper scripts
- Uploading to experimental a net-tools-compat package, to allow wider
testing.
- Upload to unstable
About the wrapper scripts:
* ipconfig, route: the most difficult ones, both can be replaced by
calls to "ip", maybe except for some obscure options.
* netstat : sstat provides almost the same information, just some
formatting changes and parsing the command line
* rarp should be dropped, as the linux kernel doesn't support it
anymore, since the 2.3 series. The replacement, arpd, is already
included in iproute.
* ipmaddr works exactly as "ip maddr", in fact, the code is from the
iproute sources. Same for iptunnel and "ip tunnel". In both cases,
they're just replaced by a symlinkm, as the ip command recognises that.
* nameif: can be replaced by "ip link", not sure if it's worth the
effort (does anybody actually use it?)
Problematic tools:
* mii-tool: it could be dropped and replaced by a pointer to ethtool as
it's not meant to be used automatically by scripts. On the other hand,
it's distributed as a stand-alone tool [0] and we could do the same.
* plipsetup, slattach: we don't know of any replacement for those, but
could be distributed separately too. Also, it's dubious if anyone still
uses them.
0: http://freshmeat.net/projects/mii-tool/
--
Martín Ferrari <tincho(a)debian.org>
--
To UNSUBSCRIBE, email to debian-devel-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
---end---
It's still required by:
bontmia
bwm-ng
dracut
egd
firehol
globus-common
initscripts
libguestfs
netdump-server
nmbscan
ocfs2-tools
ocsinventory-agent
olpc-netutils
openvpn
openwsman
rkhunter
smokeping
wicd
wifi-radar
wlassistant
https://bugzilla.redhat.com/show_bug.cgi?id=687920
--
«Allá muevan feroz guerra, ciegos reyes por un palmo más de tierra;
que yo aquí tengo por mío cuanto abarca el mar bravío, a quien nadie
impuso leyes. Y no hay playa, sea cualquiera, ni bandera de esplendor,
que no sienta mi derecho y dé pecho a mi valor.»
13 years
Fwd: rpmguard: PASSED; 0 warnings for netcdf-4.1.2-1.fc16
by Orion Poplawski
This doesn't seem right. Can't compare across releases?
-------- Original Message --------
Subject: rpmguard: PASSED; 0 warnings for netcdf-4.1.2-1.fc16
Date: Thu, 31 Mar 2011 19:14:27 +0000 (UTC)
From: autoqa(a)fedoraproject.org
To: autoqa-results(a)lists.fedorahosted.org, netcdf-owner(a)fedoraproject.org
Stored logs available at
<http://autoqa.fedoraproject.org/results/76250-autotest/qa03.c.fedoraproje...>
----------------------------------------------------------------------
========================================
netcdf-4.1.2-1.fc16
========================================
N: There is no previous build of netcdf-4.1.2-1.fc16 in dist-f16 tag (or its
parents).
N: ----
13 years
What's this /run directory doing on my system and where does it come from?
by Lennart Poettering
Heya,
I just uploaded a new version of systemd into F15, which establishes a
directory /run in the root directory. Most likely you'll sooner or later
stumble over it, so here's an explanation what this is and why this is.
It's a fairly minor technical change, though presumably people consider
this a bigger political change, so I guess this deserves an
explanation:
For quite a while programs involved with early boot used to place
runtime data in /dev under numerous hidden dot directories. /dev/.udev
was the first one, but over time this grew to at least /dev/.mdadm,
/dev/.systemd, /dev/.mount, dracut, initscripts and more tools. (Other
distros have even more) The reason they used directories there is that
/dev was known to be a tmpfs and available from the first instant the
machine was booted. /var/run otoh is only available very late at
boot, since /var might reside on a separate file system.
However, /dev always has been an inappropriate and ugly place for
runtime data: runtime data is not a device node, and thus simply does
not belong there. Also, hiding the existance of directories from the
administator is a bad idea. Then, the fact that some runtime data was
placed in /var/run/xxx, and other in /dev/.yyy is often not
understandable to ther user, and especially when tools originally
intended to be used only after boot are needed during early boot a
complicated move between these directories needed to take place.
Over time different distributions experimented with different broken
solutions for the early-runtime-dir problem: on Debian /lib/init/rw was
introduced, a tmpfs fs mounted during early boot. On Ubuntu /var/run was
mounted as tmpfs even before /var itself was mounted, with some really
ugly bind mount magic. Most software however just sidestepped the issue
and used /dev/.xxx.
In the past weeks key people from the Debian, Suse, Ubuntu and Fedora
camps (and others, too) discussed the whole issue forth and back, to
find a solution to stop the misuse of /dev before it becomes even more
widespread. Various solutions have been suggested, but in the end it all
boiled down to the fact that /var/run does not belong beneath /var and
what we really want is a top-level directory /run, and that that is the
only really clean solution. The only reason why nobody dared to actually
implement such a directory was unwillingness to deal with the political
backlash, especially messy discussions on mailing lists like this one.
Understanding this, we came to the conclusion that we should rather
implement what everybody thinks is the right technical solution, instead
of evading the political backlash for it. And so we implemented this.
With this upload Fedora and Suse have already adopted /run now. Debian
folks will suggest this for their coming release. Ubuntu has agreed with
introducing /run as well.
Dracut, udev and systemd have already been updated upstream to make use
of /run. We expect mdadm and mount to follow suit quickly.
A few years back Debian folks already suggested introduction of /run,
and even pinged LSB folks about this, and back then there even was a vaguely
positive response from them.
So, what is implemented in F15 precisely?
/run is now a tmpfs, and /var/run is bind mounted to it. /var/lock is
bind mounted to /run/lock. Applications can use /run the same way as
/var/run. Since the latter is FHS/LSB most apps should just use the
latter, only early boot stuff should use /run, for now. The folks who
have packages where this applies already have been informed. If you
haven't heard from any of us, then this doesn't apply to you.
So, what's the benefit of this again?
- There's only one tmpfs used, backing /run, /var/lock and /var/run,
reducing a bit the ever increasing amount of tmpfs' used on a default
system.
- All runtime data at the same place. systemd's, udev's, dracut's data
are all beneath /run and /var/run now. Easily discoverable to the
admin. For the first time you can see the data all these important
tools used on your system store just like any other by doing "ls
/var/run".
- Nothing is hidden anymore. The admin can see everything beneath
/var/run and /run, no hidden dot-files anymore.
- We have standardized the early-runtime-dir solution across all major
distributions
- The people involved feel much better since they don't have to misuse
/dev anymore
- The lifecycle properties of directories are clear from the top-level
directory name. Lifecycle properties do no longer change the further
you go down your tree. i.e. /var is "persistant runtime data" and /run
is "volatile runtime data", and /etc is "persistant system config
data", and so on. The ugliness that /var/run abd /var/lock had
completely different liftime guarantees than /var where they both
reside in is gone.
So, this is what is implemented for F15 now. For F16 we will make a
minor change on top of this: /var/run and /var/lock will become symlinks
to /run (resp /run/lock), so that we don't have to use bind mounts
anymore which are not the most beautiful thing to use by default, and
confusing to the admin. Due to the implications of symlinks and RPM we
didn't want to make that change in F15.
The actual code changes we needed to implement this scheme were trivial
(basically, just bind mount /var/run and /var/lock instead of mounting two
new tmpfs' to them.), which is why we opted to do this so late in the F15
cycle. However, the political implications are much bigger I guess, so
let's see what a fantastic flamewar we can start with this on
fedora-devel now. Flame away!
Lennart
--
Lennart Poettering - Red Hat, Inc.
13 years
Fedora says Thank You
by Tom Callaway
First of all, I do not want to take any credit for this idea, it belongs
to John Rose, and has been bouncing around, trying to come to life,
since July 2010. I am just happy to help it finally hatch!
John, Jared, Paul, Max, and I all want to thank Fedora users and
contributors for everything that they do in our rich and diverse
community. As a small token of our appreciation, we're giving away free
Fedora stickers and case badges to any community member who sends us a
Self-Addressed Stamped Envelope (SASE). It is our little way of saying
thank you for all that you do.
Here is a short FAQ:
Q: What is a Self-Addressed Stamped Envelope?
A: A Self-Addressed Stamped Envelope (SASE) is an envelope with the
sender's name and address on it, with affixed paid postage. In the UK,
this is also known as a "Stamped Addressed Envelope (SAE)".
Q: Where do I send my SASE?
A:
Red Hat
c/o Tom Callaway
314 Littleton Road
Westford, MA
01886-4105
Q: How long is this offer good?
A: We will return any SASEs that I receive on or before May 31, 2011.
Q: How does this work?
A: Basically, you write your mailing address on an unsealed envelope and
attach paid US postage to that envelope (enough to send a letter to that
address from the US). This is your SASE.
Next, you put your SASE in another envelope, which you then mail to me
at the above address.
When I receive it, I will open your envelope, put in some nifty Fedora
stickers and case badges, seal it up and drop it back in the mail to you.
Q: Is there a limit on how many SASEs I can send you?
A: Please, one SASE per person. If you have some sort of complicated
situation, feel free to email me directly and we'll work something out
(spot(a)fedoraproject.org).
Q: Is this offer open to contributors outside the US?
A: Of course! We realize that it may not be possible or simple for our
international contributors to get their hands on US postage, so you are
more than welcome to include an International Reply Coupon instead.
(More info about International Reply Coupons can be found here:
http://en.wikipedia.org/wiki/International_reply_coupon) If you choose
this option, please do not forget to include the self-addressed envelope!
Q: I can't find an International Reply Coupon!
A: Just email me (spot(a)fedoraproject.org) and let me know, we'll work
something out.
Q: Can I decorate my SASE?
A: Sure. Just remember that it will be coming right back to you.
Q: Do I need to prove that I am a Fedora User or Contributor?
A: Nope. If you go to the trouble of sending us the SASE, we'll send you
stickers and case badges.
Q: Can I tweet/dent/facebook/IRC/email/tell my friends about this offer?
A: Absolutely.
Q: Can I just put some money in the envelope and have you buy postage
with it for me?
A: No. Any money found in the envelope will go into my 1 year old son's
college fund. If postage is a problem, please send me an email
(spot(a)fedoraproject.org).
Q: Will Fedora or Red Hat keep a record of my mailing address?
A: Nope. All we'll do is put stickers and case badges in the envelope,
seal it up, and drop it back in the mail.
Q: How many stickers and case badges do I get?
A: One large Fedora Logo laptop sticker (3 inch) and four small foil
"Powered by Fedora" case badges.
Q: What do the stickers look like?
A: http://spot.fedorapeople.org/sticker-pic.jpg
Q: Is this an April Fools Day joke?
A: Nope. This is serious.
Q: What if I don't use Fedora?
A: You can still get stickers. There is no OS check involved.
Q: I want more stickers than you normally give out! Can I ask for a few
more?
A: If you have a special situation, feel free to email me
(spot(a)fedoraproject.org), and we'll see what can be done.
Q: Is this information on the Fedora website somewhere?
A: Yes: https://fedoraproject.org/wiki/Thank_You
Q: I have a question that isn't answered here, where can I ask it?
A: Email spot(a)fedoraproject.org.
Thanks again,
~tom
==
Fedora Project
13 years
firefox/xulrunner-bin confusion
by Orion Poplawski
Fired up top on my F-15 system and saw a big application called
"xulrunner-bin" running. This is firefox 4 of course, but I'm wondering if it
would be worth doing something to try to ease possible confusion. At the
moment thunderbird shows up as thunderbird-bin but I could imagine someday it
looking like the current firefox process (and other xulrunner apps).
Thoughts?
Full process:
/usr/lib64/xulrunner-2/xulrunner-bin /usr/lib64/firefox-4/application.ini
--sm-config-prefix /xulrunner-bin-VuWa5A/ --sm-client-id
10626f6e61000129173856600000016250044 --screen 0
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
13 years
Review swap for hotot micro blogging client
by Rahul Sundaram
Hi
I can do a review in exchange for hotot
https://bugzilla.redhat.com/show_bug.cgi?id=692281
---
Description:
Hotot, is a lightweight & open source micro blogging client, coding using
Python language and designed for Linux. It depends less but supports more.
Features:
* OAuth and Basic Auth is supported.
* Socks Proxy and Http Proxy.
* Support API Proxy.
* Support Twitter Search and content filter.
* Keyboard shortcuts.
* Extension System.
* Native notify system. it supports Gnome & KDE SC.
---
Rahul
13 years