Fedora 中文組郵件列表 July 2010

chinese@lists.fedoraproject.org

51 participants
35 discussions

[FZH] 有关gtk对话框的文本布局
by Yu Chen 28 Jul '10

28 Jul '10

请问 gtk（gtkmm）的标准对话框的文本排版布局是没办法控制的吗？如下面的链接，可以看到，如果那个secondary text 的 “3 seconds ” 可以放在第一排，这样会比较美观。 http://library.gnome.org/devel/hig-book/2.30/images/windows-alert-save.png.… 谢谢。 -- Yu

2 1

[FZH] The late Fedora Summer coder
by Liang Suilong 26 Jul '10

26 Jul '10

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

1 0

[FZH] Fwd: [HEADS-UP] systemd is now the default init system in rawhide
by Liang Suilong 25 Jul '10

25 Jul '10

暂时 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

2 1

[FZH] Fedora 13中运行VMware时报signal 6错误退出后键盘shift键失效（完全退出虚拟机后用键盘输入字符时shift键不起作用其它键正常）
by Bill Buchanan 20 Jul '10

20 Jul '10

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

3 3

[FZH] #T Z Depth
by Yu Chen 19 Jul '10

19 Jul '10

正在翻译一个动画软件，里面有个术语 Z Depth，用来定义物件在镜头中出现的前后位置的，有点类似一般绘图软件（如gimp，inkscape）中的图层的顺序，前面的可以遮住后面的。我在“纵深”，“景深” 这两个翻译中徘徊，请问大家有什么好建议？ -- Yu

5 12

[FZH] JAVA标签里的中文无法显示
by Y L 16 Jul '10

16 Jul '10

我的系统是64位fedora 13，JAVA程序中有许多汉字无法显示，都是一个个的方框。不知大家的JAVA程序能否正常运行？

2 1

[FZH] 不在其位不謀其政之包包大放生。
by Caius Chance 15 Jul '10

15 Jul '10

我離職了，因此放生大量包包：有 stardict, cjkuni-fonts, baekmuk-fonts, liberation-fonts, ibus 的等等。請有興趣認養牠們的，隨意挑選帶回家好好照顧。我會參加週五聚會的，以非理事身份。 -- Caius 'kaio' Chance / かいお

9 20

[FZH] Package Review of ibus-table-{chinese,others}
by Caius Chance 14 Jul '10

14 Jul '10

Hey liangsuilong or supercyper or others, 我之前有兩個 Package Review，你們誰要繼承下去的，請請。不然的話，那兩個 ticket 之後應該會被某些做 review 的回收吧。以上。 kaio -- Caius 'kaio' Chance / かいお

1 0

[FZH] Fwd: [HEADS-UP] systemd for F14 - the next steps
by Chen Lei 14 Jul '10

14 Jul '10

---------- 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

1 0

Re: [FZH] Help! the Fedora ISO image can not be download.
by Yuan Yijun 14 Jul '10

14 Jul '10

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 ^_^

3 2

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Fedora 中文組郵件列表 July 2010