[FZH] The late Fedora Summer coder
by Liang Suilong
Copr，和早前说的 Kopper 应该是一路东西。作为一个 Fedora 暑期代码项目提了
出来，现在已经有人跟进中。
具体的介绍可以看这里：https://fedoraproject.org/wiki/Category:Copr
Sent to you by liangsuilong via Google Reader: The late Fedora Summer
coder via Fedora People by Oin Maple on 25/07/10
I started my Fedora Summer Coding last week. Although most people
started almost two months ago, I chose (and was allowed to – Yay, FSC!)
a different schedule because I just finished college last week.
This summer I’ll be working on a new project for Fedora – Copr. Fedora
Copr will allow any Fedorian to have their own package repository with
packages built and hosted by Fedora’s Infrastructure. My mentor this
summer will be Toshio, I’ve always enjoyed working with him and this
summer will be no different. Here is my actual FSC proposal. Although
the things written in that proposal are turning out to be a bit
inaccurate, it’s still a good bird’s eye view of what I’m going to do
this summer.
So about the first week. Things started really slow. I did a lot of
orientation, certainly more than I thought I would. I hadn’t used
TurboGears2 before, though I had worked with TurboGears 1.x on Fedora’s
pkgdb. When I started out I had only a TG2 automatically generated
skeleton app – well it’s mostly the same now, though at least I now
know a lot more about what’s in there. The fact that I had to start it
up myself meant I had to learn a lot of things about TG2 that I
would’ve normally just copied from other parts of a fully-functional
project. And that was a great experience. In a way it’s fulfilling to
be able to pioneer things in this way ;). I’m trying to only ask my
mentor questions about designing the actual app and solve my “How do
I … in TurboGears/Python?” questions elsewhere. My mentor has always
given me a lot of independence when working on things and that feels
really good, though at times I feel inexperienced. There’s the thought
that the project I’m working on will be used by a lot of technical
users and I’m really not sure what my decisions’ impact will be on the
whole project.
I’m mostly on time with my mock-up schedule because I had set the first
week for orienteering. I also wrote the DB schema for Coprs, though
that was on the second week. That doesn’t mean I’m ahead of schedule
however, because I’ll probably have a lot to work on the Copr
controllers, and a lot of documenting and designing.
I’m proud that I setup testing after a day of wading through the
scattered documentation of TurboGears2 testing. There’s mostly no
documentation on testing on the TurboGears2.0 docs website. So I went
to the python nose webpage. But they don’t have any info on the
TurboGears2 web helpers which I needed to use. So I went to pylonshq
docs about testing, but they use a slightly different syntax because
they’re using paste.fixture. I finally found the TurboGears2.1 testing
docs which was what I really needed. It turns out that TurboGears 2.x
uses WebTest.
So now I have testing. My project is not supposed to have any web
interface at this point, so writing tests is the easiest way to prove
that things are actually working.
This next week I’ll probably get some work done on Copr controllers.
Implementing the ability to CRUD Coprs and Repos.
Things you can do from here:
- Subscribe to Fedora People using Google Reader
- Get started using Google Reader to easily keep up with all your
favourite sites
13 years, 9 months
[FZH] Fwd: [HEADS-UP] systemd is now the default init system in rawhide
by Liang Suilong
暂时 systemd-sysvinit 和 upstart-sysvinit 两个包冲突。。。
用 --skip-broken 跳过吧。
---------- Forwarded message ----------
From: Lennart Poettering <mzerqung(a)0pointer.de>
Date: Sat, Jul 24, 2010 at 9:26 AM
Subject: [HEADS-UP] systemd is now the default init system in rawhide
To: Fedora Development ML <devel(a)lists.fedoraproject.org>
Heya,
I have just uploaded a new systemd and a new upstart package which make
systemd the default init system for Rawhide. The scheme I followed makes
sure that in case systemd actually breaks systems there is an easy path
back to upstart. And here's how it works:
- "upstart" and "systemd" are now parallel installable. When you upgrade
rawhide you will get both installed. (we'll drop upstart eventually,
but during the testing phase i made sure to explicitly install both,
so that there is a safe backup init system)
- You can boot into either of them by setting the "init=" kernel cmdline
option according to your wishes. If you pass "init=/bin/systemd" you
will boot into systemd, if you pass "init=/sbin/upstart" you will boot
into upstart (note the /sbin vs. /bin!)
- Since there can only be one implementation providing the /sbin/init
file name, I have split off -sysvinit packages from both packages
which symlink this to either /bin/systemd (in the systemd-sysvinit
pkg) or /sbin/upstart (in the upstart-sysvinit pkg). Something similar
is done for /sbin/reboot and the other well-known SysV client
utilities. That basically means you can choose which init system to
use by default simply by installing either of these two packages. By
default systemd-sysvinit will now be installed. As mentioned the
"upstart" and "systemd" packages do not conflict -- but
"upstart-sysvinit" and "systemd-sysvinit" do. The former two packages
include all the actual code, and the latter then install them under
the well-known names via symlinks.
- Note that using the upstart client tools on a systemd system will of
course make certain functionality unavailable. Vice versa it is
similar: using the systemd client tools on an upstart boot will of
course make certain functionality unavailable, too. However, I
carefully made sure that both tool sets work well enough to be able to
at least bring up and reboot the machine.
So, to put this in shorter words:
If systemd does not work for you and you need a temporary fix, pass
"init=/bin/upstart" on the kernel command line.
If systemd does not work for you and you need a non-temporary fix,
install "upstart-sysvinit".
I think this offers a good and soft transition for rawhide.
I have tested all this quite extensibly on my machines, but of course, I
am not sure how this will break on other people's machines. I
sincerly hope I didn't break anything major with this transition. So
please report bugs and don't rip off my head because I might have broken
your boot... I didn't do it on purpose, promised! ;-)
systemd.4-3 is the package version this switch of defaults has taken
place in.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
--
Fedora && Debian User, former Ubuntu User
My Page: http://www.liangsuilong.info
Fedora Project Contributor -- Packager && Ambassador
https://fedoraproject.org/wiki/User:Liangsuilong
13 years, 9 months
[FZH] Fedora 13中运行VMware时报signal 6错误退出后键盘shift键失效（完全退出虚拟机后用键盘输入字符时shift键不起作用其它键正常）
by Bill Buchanan
Jul 20 08:52:47.461: vmx| USBGA: device id: 60002096ea010 disconnected from
host
Jul 20 08:52:47.461: vmx| USB: Disconnecting device 0x60002096ea010
Jul 20 08:52:47.462: vmx| VMXVmdbLoadUsbDevices: New set of 1 USB devices
Jul 20 08:52:47.462: vmx| USB: Found device [name:ChipsBnk\ Integrated\
Camera vid:17ef pid:4810 path:2/5 speed:high family:other,video]
Jul 20 08:52:52.366: mks| Caught signal 6 -- tid 3982
Jul 20 08:52:52.366: mks| SIGNAL: eip 0x852424 esp 0xb6d07980 ebp 0xb6d07998
Jul 20 08:52:52.366: mks| SIGNAL: eax 0x0 ebx 0xf83 ecx 0xf8e edx 0x6 esi
0x6a982f edi 0x6e5ff4
Jul 20 08:52:52.366: mks| SIGNAL: stack B6D07980 : 0xb6d07998 0x00000006
0x00000f8e 0x00588d11
Jul 20 08:52:52.366: mks| SIGNAL: stack B6D07990 : 0x006e5ff4 0xb6d07ab8
0xb6d07ac0 0x0058a5ea
Jul 20 08:52:52.366: mks| SIGNAL: stack B6D079A0 : 0x00000006 0xb6d07a38
0x00000000 0xb4b00010
Jul 20 08:52:52.366: mks| SIGNAL: stack B6D079B0 : 0xb4b00040 0x006e5ff4
0xb4b00010 0x00000000
Jul 20 08:52:52.366: mks| SIGNAL: stack B6D079C0 : 0xb6d079e0 0x005d0e9e
0x005d1a01 0xb4b00010
Jul 20 08:52:52.366: mks| SIGNAL: stack B6D079D0 : 0x00000088 0x006e5ff4
0x00000083 0x00000082
Jul 20 08:52:52.367: mks| SIGNAL: stack B6D079E0 : 0xb6d07aa8 0x005c5938
0x00000000 0xb4b17e18
Jul 20 08:52:52.367: mks| SIGNAL: stack B6D079F0 : 0x00000082 0xb4b17db0
0x00000000 0xfbad8000
Jul 20 08:52:52.367: mks| Backtrace:
Jul 20 08:52:52.367: mks| Backtrace[0] 0xb6d074f8 eip 0x8058370
Jul 20 08:52:52.367: mks| Backtrace[1] 0xb6d075b8 eip 0x80c7ea0
Jul 20 08:52:52.367: mks| Backtrace[2] 0xb6d07998 eip 0x85240c
Jul 20 08:52:52.367: mks| Backtrace[3] 0xb6d07ac0 eip 0x58a5ea
Jul 20 08:52:52.367: mks| Backtrace[4] 0xb6d07b08 eip 0x581d98
Jul 20 08:52:52.367: mks| Backtrace[5] 0xb6d07b78 eip 0x92fab6
Jul 20 08:52:52.367: mks| Backtrace[6] 0xb6d07b98 eip 0x9303e7
Jul 20 08:52:52.367: mks| Backtrace[7] 0xb6d07bc8 eip 0x918988
Jul 20 08:52:52.367: mks| Backtrace[8] 0xb6d07d48 eip 0x82961d5
Jul 20 08:52:52.367: mks| Backtrace[9] 0xb6d07d88 eip 0x811b929
Jul 20 08:52:52.367: mks| Backtrace[10] 0xb6d08218 eip 0x811c09d
Jul 20 08:52:52.367: mks| Backtrace[11] 0xb6d08238 eip 0x82874b9
Jul 20 08:52:52.367: mks| Backtrace[12] 0xb6d08298 eip 0x829455e
Jul 20 08:52:52.367: mks| Backtrace[13] 0xb6d08388 eip 0x80c8c18
Jul 20 08:52:52.367: mks| Backtrace[14] 0xb6d08498 eip 0x6f2919
Jul 20 08:52:52.367: mks| Backtrace[15] 00000000 eip 0x63bcbe
Jul 20 08:52:52.367: mks| SymBacktrace[0] 0xb6d074f8 eip 0x8058370 in
function (null) in object /usr/lib/vmware/bin/vmware-vmx loaded at 0x8048000
Jul 20 08:52:52.367: mks| SymBacktrace[1] 0xb6d075b8 eip 0x80c7ea0 in
function (null) in object /usr/lib/vmware/bin/vmware-vmx loaded at 0x8048000
Jul 20 08:52:52.367: mks| SymBacktrace[2] 0xb6d07998 eip 0x85240c in
function __kernel_rt_sigreturn in object loaded at 0x852000
Jul 20 08:52:52.367: mks| SymBacktrace[3] 0xb6d07ac0 eip 0x58a5ea in
function abort in object /lib/libc.so.6 loaded at 0x55e000
Jul 20 08:52:52.367: mks| SymBacktrace[4] 0xb6d07b08 eip 0x581d98 in
function __assert_fail in object /lib/libc.so.6 loaded at 0x55e000
Jul 20 08:52:52.367: mks| SymBacktrace[5] 0xb6d07b78 eip 0x92fab6 in
function (null) in object /usr/lib/libX11.so.6 loaded at 0x8ed000
Jul 20 08:52:52.367: mks| SymBacktrace[6] 0xb6d07b98 eip 0x9303e7 in
function _XEventsQueued in object /usr/lib/libX11.so.6 loaded at 0x8ed000
Jul 20 08:52:52.367: mks| SymBacktrace[7] 0xb6d07bc8 eip 0x918988 in
function XPending in object /usr/lib/libX11.so.6 loaded at 0x8ed000
Jul 20 08:52:52.367: mks| SymBacktrace[8] 0xb6d07d48 eip 0x82961d5 in
function (null) in object /usr/lib/vmware/bin/vmware-vmx loaded at 0x8048000
Jul 20 08:52:52.368: mks| SymBacktrace[9] 0xb6d07d88 eip 0x811b929 in
function (null) in object /usr/lib/vmware/bin/vmware-vmx loaded at 0x8048000
Jul 20 08:52:52.368: mks| SymBacktrace[10] 0xb6d08218 eip 0x811c09d in
function (null) in object /usr/lib/vmware/bin/vmware-vmx loaded at 0x8048000
Jul 20 08:52:52.368: mks| SymBacktrace[11] 0xb6d08238 eip 0x82874b9 in
function (null) in object /usr/lib/vmware/bin/vmware-vmx loaded at 0x8048000
Jul 20 08:52:52.368: mks| SymBacktrace[12] 0xb6d08298 eip 0x829455e in
function (null) in object /usr/lib/vmware/bin/vmware-vmx loaded at 0x8048000
Jul 20 08:52:52.368: mks| SymBacktrace[13] 0xb6d08388 eip 0x80c8c18 in
function (null) in object /usr/lib/vmware/bin/vmware-vmx loaded at 0x8048000
Jul 20 08:52:52.368: mks| SymBacktrace[14] 0xb6d08498 eip 0x6f2919 in
function (null) in object /lib/libpthread.so.0 loaded at 0x6ec000
Jul 20 08:52:52.368: mks| SymBacktrace[15] 00000000 eip 0x63bcbe in function
clone in object /lib/libc.so.6 loaded at 0x55e000
Jul 20 08:52:52.368: mks| Panic: dropping lock (was bug 49968)
Jul 20 08:52:52.368: mks| Unexpected signal: 6.
Jul 20 08:52:52.368: mks| Core dump limit is 0 KB.
Jul 20 08:52:52.396: mks| Child process 5268 failed to dump core (status
0x6).
Jul 20 08:52:52.396: mks| Backtrace:
Jul 20 08:52:52.396: mks| Backtrace[0] 0xb6d070c8 eip 0x8058370
Jul 20 08:52:52.396: mks| Backtrace[1] 0xb6d074f8 eip 0x812ef20
Jul 20 08:52:52.396: mks| Backtrace[2] 0xb6d075b8 eip 0x80c8095
Jul 20 08:52:52.396: mks| Backtrace[3] 0xb6d07998 eip 0x85240c
Jul 20 08:52:52.396: mks| Backtrace[4] 0xb6d07ac0 eip 0x58a5ea
Jul 20 08:52:52.396: mks| Backtrace[5] 0xb6d07b08 eip 0x581d98
Jul 20 08:52:52.396: mks| Backtrace[6] 0xb6d07b78 eip 0x92fab6
Jul 20 08:52:52.396: mks| Backtrace[7] 0xb6d07b98 eip 0x9303e7
Jul 20 08:52:52.396: mks| Backtrace[8] 0xb6d07bc8 eip 0x918988
Jul 20 08:52:52.396: mks| Backtrace[9] 0xb6d07d48 eip 0x82961d5
Jul 20 08:52:52.396: mks| Backtrace[10] 0xb6d07d88 eip 0x811b929
Jul 20 08:52:52.396: mks| Backtrace[11] 0xb6d08218 eip 0x811c09d
Jul 20 08:52:52.396: mks| Backtrace[12] 0xb6d08238 eip 0x82874b9
Jul 20 08:52:52.397: mks| Backtrace[13] 0xb6d08298 eip 0x829455e
Jul 20 08:52:52.397: mks| Backtrace[14] 0xb6d08388 eip 0x80c8c18
Jul 20 08:52:52.397: mks| Backtrace[15] 0xb6d08498 eip 0x6f2919
Jul 20 08:52:52.397: mks| Backtrace[16] 00000000 eip 0x63bcbe
Jul 20 08:52:52.397: mks| SymBacktrace[0] 0xb6d070c8 eip 0x8058370 in
function (null) in object /usr/lib/vmware/bin/vmware-vmx loaded at 0x8048000
Jul 20 08:52:52.397: mks| SymBacktrace[1] 0xb6d074f8 eip 0x812ef20 in
function (null) in object /usr/lib/vmware/bin/vmware-vmx loaded at 0x8048000
Jul 20 08:52:52.397: mks| SymBacktrace[2] 0xb6d075b8 eip 0x80c8095 in
function (null) in object /usr/lib/vmware/bin/vmware-vmx loaded at 0x8048000
Jul 20 08:52:52.397: mks| SymBacktrace[3] 0xb6d07998 eip 0x85240c in
function __kernel_rt_sigreturn in object loaded at 0x852000
Jul 20 08:52:52.397: mks| SymBacktrace[4] 0xb6d07ac0 eip 0x58a5ea in
function abort in object /lib/libc.so.6 loaded at 0x55e000
Jul 20 08:52:52.397: mks| SymBacktrace[5] 0xb6d07b08 eip 0x581d98 in
function __assert_fail in object /lib/libc.so.6 loaded at 0x55e000
Jul 20 08:52:52.397: mks| SymBacktrace[6] 0xb6d07b78 eip 0x92fab6 in
function (null) in object /usr/lib/libX11.so.6 loaded at 0x8ed000
Jul 20 08:52:52.397: mks| SymBacktrace[7] 0xb6d07b98 eip 0x9303e7 in
function _XEventsQueued in object /usr/lib/libX11.so.6 loaded at 0x8ed000
Jul 20 08:52:52.397: mks| SymBacktrace[8] 0xb6d07bc8 eip 0x918988 in
function XPending in object /usr/lib/libX11.so.6 loaded at 0x8ed000
Jul 20 08:52:52.397: mks| SymBacktrace[9] 0xb6d07d48 eip 0x82961d5 in
function (null) in object /usr/lib/vmware/bin/vmware-vmx loaded at 0x8048000
Jul 20 08:52:52.397: mks| SymBacktrace[10] 0xb6d07d88 eip 0x811b929 in
function (null) in object /usr/lib/vmware/bin/vmware-vmx loaded at 0x8048000
Jul 20 08:52:52.397: mks| SymBacktrace[11] 0xb6d08218 eip 0x811c09d in
function (null) in object /usr/lib/vmware/bin/vmware-vmx loaded at 0x8048000
Jul 20 08:52:52.397: mks| SymBacktrace[12] 0xb6d08238 eip 0x82874b9 in
function (null) in object /usr/lib/vmware/bin/vmware-vmx loaded at 0x8048000
Jul 20 08:52:52.397: mks| SymBacktrace[13] 0xb6d08298 eip 0x829455e in
function (null) in object /usr/lib/vmware/bin/vmware-vmx loaded at 0x8048000
Jul 20 08:52:52.397: mks| SymBacktrace[14] 0xb6d08388 eip 0x80c8c18 in
function (null) in object /usr/lib/vmware/bin/vmware-vmx loaded at 0x8048000
Jul 20 08:52:52.397: mks| SymBacktrace[15] 0xb6d08498 eip 0x6f2919 in
function (null) in object /lib/libpthread.so.0 loaded at 0x6ec000
Jul 20 08:52:52.397: mks| SymBacktrace[16] 00000000 eip 0x63bcbe in function
clone in object /lib/libc.so.6 loaded at 0x55e000
Jul 20 08:52:52.397: mks| Msg_Post: Error
Jul 20 08:52:52.397: mks| [msg.log.error.unrecoverable] VMware Workstation
unrecoverable error: (mks)
Jul 20 08:52:52.397: mks| Unexpected signal: 6.
Jul 20 08:52:52.397: mks| [msg.panic.haveLog] A log file is available in
"/home/bill/vmware/Windows Server 2003 Enterprise Edition/vmware.log".
[msg.panic.requestSupport.withLog] Please request support and include the
contents of the log file. [msg.panic.requestSupport.vmSupport.linux]
Jul 20 08:52:52.397: mks| To collect data to submit to VMware support,
select Help > About and click "Collect Support Data". You can also run the
"vm-support" script in the Workstation folder directly.
Jul 20 08:52:52.397: mks| [msg.panic.response] We will respond on the basis
of your support entitlement.
Jul 20 08:52:52.397: mks| ----------------------------------------
Jul 20 08:52:52.457: mks| XINFO IO fatal error. Exiting ...
Jul 20 08:52:52.457: mks| Detaching from window system.
Jul 20 08:52:52.457: mks| MKS: Base polling period is 1000000us
13 years, 9 months
[FZH] #T Z Depth
by Yu Chen
正在翻译一个动画软件，里面有个术语 Z
Depth，用来定义物件在镜头中出现的前后位置的，有点类似一般绘图软件（如gimp，inkscape）中的图层的顺序，前面的可以遮住后面的。
我在“纵深”，“景深” 这两个翻译中徘徊，请问大家有什么好建议？
--
Yu
13 years, 9 months
[FZH] 不在其位不謀其政 之 包包大放生。
by Caius Chance
我離職了，因此放生大量包包：
有 stardict, cjkuni-fonts, baekmuk-fonts, liberation-fonts, ibus 的等等。
請有興趣認養牠們的，隨意挑選帶回家好好照顧。
我會參加週五聚會的，以非理事身份。
--
Caius 'kaio' Chance / かいお
13 years, 9 months
[FZH] Fwd: [HEADS-UP] systemd for F14 - the next steps
by Chen Lei
---------- Forwarded message ----------
From: Lennart Poettering <mzerqung(a)0pointer.de>
Date: 2010/7/14
Subject: [HEADS-UP] systemd for F14 - the next steps
To: Fedora Development ML <devel(a)lists.fedoraproject.org>
Heya,
as many of you probably know systemd got accepted as feature for F-14 by
FESCO a few weeks back.
https://fedoraproject.org/wiki/Features/systemd
And in case you want to read up what systemd actually is, here's the
blog post that introduced it (only slightly out-of-date, we have however
advanced a bit since then):
http://0pointer.de/blog/projects/systemd.html
Since the acceptance by FESCO it has been added to Rawhide together with
patched or updated versions of a few related packages. However, what has
not been done so far is making it the default in Rawhide. So far it does
not "Obsolete" Upstart yet, just "Conflicts" with it. With this mail I
want to notify everybody that I am planning to do this change very soon
now (tomorrow?). Then, systemd will be pulled in onto your rawhide
system and is used exclusively for booting (so far, you can still choose
between it and upstart in grub, with a default on upstart), and problems
booting should be reported to systemd in rhbz then.
At this point the following packages in rawhide have been updated to
provide socket based activation [Hint: in case you are wondering, socket
activation is one of the amazing things in systemd, see the original
announcement for details]: dbus, udev, avahi, rtkit. Before F14 I want
to at least add rpcbind and rsyslog to this list for socket based
activation, and most likely cups. For rpcbind/rsyslog the patches have
been submitted upstream, and even have partly been merged already).
It would be great if we could ship native unit files (as replacement for
the current sysvinit scripts) for as many packages in Fedora as we can
for F14, and in particular for all those services that are installed by
default. [Hint: unit files is the systemd term for files describing
services (i.e. daemons) and other objects systemd starts and
maintains]. I have prepared native unit files for the majority of
services of the default install, and will now post them on bugzilla
piece by piece for inclusion in the rpms. Ideally, those unit files are
shipped upstream, but they can be added in the rpms too. Unit files are
usually very short for normal services and should be easy to write
(i.e. you don't have to think about dependencies or any complexities
like that at all in most cases, unless you want to do fancy stuff
involving early boot or late shut down). Unit files should be written
for daemons that currently install SysV init scripts and also (and this
matters!) for all services currently started via D-Bus bus
activation. Writing native unit files enables the radical form of
parallelization that systemd employs. Units without native unit files,
i.e. only SysV or D-Bus service files, will only benefit from very
minimal parallelization.
Note that neither patching in socket based activation, nor shipping
native unit files will break services in a non-systemd boot up. In order
to keep our options open to possibly revert things before F14 we
explciitly made sure not to break compatibility with non-systemd
boots. i.e. the socket actviation patches become NOPs if systemd is not
running and the native unit files are ignored, so that only sysv init
scripts matter. Also note that even in the case that we do roll back to
upstart before the release of F14 this work won't be in vain, as work
that has been done has been done and will then becom euseful when we
adopt systemd in the next cycle. I want to stress though that at this
point in time I see no reason to assume that we shouldn't make it for
F14.
So, here's my call for help, in order to make this all a big success:
a) if you maintain a package which includes a daemon/service from the
default install, expect a proposed unit file in bugzilla soon. Would be
awesome if you could check it and add it to your RPM. Even better would
be if you get it merged upstream. I have unit files the majority of
these services. Ping me on irc (#systemd on fdo, I'm 'mezcalero'), if
you wonder whether yours is one of them, and if you have questions.
b) if you maintain a package which includes a daemon/service from
outside the default install, it would be awesome if you could ship
native unit files too, even though I don't have any ready for
you. Writing unit files is not difficult, and should be well documented
in the man pages. In particular have a look daemon(7),
i.e. http://0pointer.de/public/systemd-man/daemon.html and related man
pages. A good example for a systemd-enabled RPM for a D-Bus service is
rtkit. You might want to check it out and its .spec file:
http://cvs.fedoraproject.org/viewvc/devel/rtkit/rtkit.spec?view=markup
A good example for a systemd-enabled RPM for a service that currently
installs a SysV init script, checkout Avahi and its .spec file:
http://cvs.fedoraproject.org/viewvc/devel/avahi/avahi.spec?view=markup
Some package could use the native unit love more than others. For
example, I have seen terrible things done to daemonize
processes and drop privs in pure shell (the bittorrent packages as one
example). Packages like that could really benefit from native unit
files which make this much easier and nicer and cleaner.
c) if you are the developer of a package that could benefit from socket
activation, please consider patching it for it. How that works is
documented in the man pages:
http://0pointer.de/public/systemd-man/daemon.html and
http://0pointer.de/public/systemd-man/sd-daemon.html and related, see
http://0pointer.de/public/systemd-man/ for the full list.
d) There's one thing that is not directly related to systemd but which
I'd really like to see done at the same time: moving /var/lock and
/var/run to tmpfs, like suse and ubuntu already did it. The changes
necessary should be small, but probably in a non-trivial number of
packages: each mention of /var/run in the .spec files needs to be
%ghosted. Also, some minimal changes to rc.sysinit need to be done, so
that the dirs are mounted (this could be done by systemd too, in case we
get the sysinit split hhoyer started to work on done before
F14). Finally, there might be a few packages which start to act confused
if their directories beneath /var/run is go away on reboot. But these
problems should already have been fixed by the Ubuntuans and Suses of
this world for us. It would be really great if somebody would volunteer
for this and go through the packages to add %ghost everywhere and ensure
otherwise this works out. The ubuntu and suse folks might have some
docs around with more ideas about this.
e) play around with systemd, test it!
f) contribute to our work! We always are happy about people contributing
code or docs, or even artwork (we could use a logo... ;-)).
And again, if anybody has a question, many systemd folks are around on
#systemd on fdo, and particularly me, mezcalero. So if you have
questions, ask us there, or right here on this thread.
There are a couple of bugs that still need to be fixed in other
packages than systemd, before F14:
https://bugzilla.redhat.com/show_bug.cgi?id=614245
https://bugzilla.redhat.com/show_bug.cgi?id=612789
https://bugzilla.redhat.com/show_bug.cgi?id=612728
https://bugzilla.redhat.com/show_bug.cgi?id=612712
That said, things should already work really well in rawhide right now,
and you should have no trouble bringing up and down the system with
systemd using its sysv compatibility logic to execute the existing SysV
init scripts. Please try it out and report back. Note that you still
need to pass "init=/bin/systemd" on the kernel command line, until the
point I make the change i mentioned above.
A short FAQ:
1) Q: If I patch my service for systemd socket activation, will this break
things for people not using systemd?
A: No, it won't.
2) Q: If I ship native systemd unit files, will this break things for
people not using systemd?
A: No, it won't.
3) Q: Will things become miraculously fast by booting with systemd?
A: No, it won't. When you boot with only SysV services
(i.e. utilizing the systemd SysV compatiblity logic to its max),
things should become only very little faster, as only very minimal
parallelization is employed then. And even if you have added native
service files for every single service, you won't make a slow
machine a supercomputer. Speeding up the boot requires a lot of
work everyhwere, and it is not sufficient to parallelize only
daemon bootup. i.e. rc.sysinit needs more parallelization too, and
is currently a single linear monolithic script. That said, on SSD
things should be noticably faster (though don't expect too much),
on rotating media things are not as rosy, simply because the Linux
IO scheduler cannot fully
keep up with with the increased parallelization and readahead is not a
solution for this, but more of a kinda futile attempt to fix this
without touching the kernel. Stuff like Jens Axboe's fcache sound
like a better solution, and even a bit like the approaches MS and
Apple took in this area.
Let me stress here however that I would like to see people judge
systemd not by its mere speed. Please see the full set of features
(again, read the initial blog post for details and maybe even the
man pages). It is our main objective to do things right. One part
of "doing it right" is "doing it fast", but it's far from the only
thing.
4) Q: If I don't care about systemd and don't update my packages, will
things stop working for me in F14?
A: No, they will continue to work. Since systemd's SysV compatiblity is quite
extensive things should just continue to work just fine.
5) Q: Why systemd? Isn't Upstart awesome too?
A: Well, opinions on that matter, see my original blog story for
details. Suffice to say that I am not exactly the only one who
thinks this way.
6) Q: LSB/SysV init scripts are standardized in the LSB! Why are you
breaking with that standard?
A: Well, actually we aren't. systemd provides compatibility with SysV
to a very large degree, we even have support for various
distribution extensions. The vast majority of init scripts should
continue to work in systemd just fine, even though they might work
even better with native unit files.
In the long run we actually hope to minimize differences between
distros with this, by establishing common hooks services should
use and asking everybody to use those hooks and ship their service
files in their upstream packages. The idea is that the systemd
unit file is automatically a lot more portable and
distribution-independent then the init scripts ever were.
7) Q: Are the other distros switching too?
A: Well, they are not as fast, but it looks very much like it. I have
been working very closely with Kay Sievers from Suse to integrate
systemd equally well into the OpenSuse semantics, and it will
enter their distro as soon as their development cycle
reopens. Debian, Gentoo, ArchLinux have packages in their
archives, but it's not the default there (yet?). I guess at least
for Debian/Gentoo it is very hard to make decisions about dfaults
like this. Meego has someone working on this, but I have
not followed that closely. And there are some smaller distros
which have adopted it too, and I know at least one (Pardus) that
plans to make it the default in the next release. And regarding
Ubuntu I leave it to you figuring out what is going on (Hint: you
might want to check out for what company the main developer of
Upstart -- which systemd replaces -- works for...). And never
forget that Fedora is of course the leader in development, so it
should be us who lead here... ;-)
And if you have any further questions, talk to us on IRC! Or reply to
this thread!
And also, don't forget to check the (extensive I believe) body of
documentation we now have, it might already answer your question. In
particular the blog story I already mentioned way too often:
http://0pointer.de/blog/projects/systemd.html
It's quite a novel I fear, but full of interesting stuff. And then
there is the set of man pages:
http://0pointer.de/public/systemd-man/
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
13 years, 9 months
Re: [FZH] Help! the Fedora ISO image can not be download.
by Yuan Yijun
2010/7/13 Andy *L <0701andy(a)gmail.com>:
> Dear Sir
>
> I am living on campus and the network is so bad. I tried to download the
> Fedora 13, but no matter what I do I am doomed to fail. So could you please
> give me some advise or help me to get a free Fedora DVD? Your help will be
> very useful to me, and I will appreciate it very much.
>
Hi, Andy
Maybe you can try to find someone near you who has a copy of Fedora
DVD, or download them in an internet cafe. AFAIK there is no active
FreeMedia contributor in China currently, so that may not help you
much, but you can still try that channel. The fastest way, of course,
is to buy it online. For example, http://shop59969330.taobao.com/
provides cheap F13 DVDs.
Please also join chinese(a)lists.fedoraproject.org to ask for help.
Thanks!
--
bbbush ^_^
13 years, 9 months
