devel March 2011

devel@lists.fedoraproject.org

247 participants
259 discussions

how to speed up mock?
by Farkas Levente 03 Apr '11

03 Apr '11

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

10 19

Axel Thimm: Unresponsive maintainer?
by Kevin Fenzi 03 Apr '11

03 Apr '11

Greetings. Does anyone have a means to contact Axel Thimm and confirm he's ok and if he wishes to maintain his packages in Fedora moving forward? (I've cc'ed him on this as well). The last commit I see from him was http://lists.fedoraproject.org/pipermail/scm-commits/2010-November/516359.h… Wed Nov 3 2010 I mailed him privately on Feb 20th with no reply. He has 27 packages with owner/commit/approveacls: https://admin.fedoraproject.org/pkgdb/users/packages/athimm?acls=owner&acls… He has 60 bugs assigned: https://bugzilla.redhat.com/buglist.cgi?query_format=advanced&emailtype2=su… I have someone very interested in taking over mediawiki-openid and php-pear-Auth-OpenID, so I will probably approve them for those packages soon since they are both very broken and need love, but I wonder how many of the others are in the same state. :( Hope he's ok and will return to Fedora someday. If someone can get a hold of him, we should at least get co-maintainers for his packages so he doesn't need to worry about them. kevin

6 9

Delayed encrypted partition mount
by Gilboa Davara 02 Apr '11

02 Apr '11

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

7 10

net-tools must die
by Xose Vazquez Perez 01 Apr '11

01 Apr '11

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@@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.»

3 2

Fwd: rpmguard: PASSED; 0 warnings for netcdf-4.1.2-1.fc16
by Orion Poplawski 01 Apr '11

01 Apr '11

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.fedoraproject…> ---------------------------------------------------------------------- ======================================== 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: ----

2 2

What's this /run directory doing on my system and where does it come from?
by Lennart Poettering 01 Apr '11

01 Apr '11

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.

38 98

Fedora says Thank You
by Tom Callaway 31 Mar '11

31 Mar '11

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

1 0

firefox/xulrunner-bin confusion
by Orion Poplawski 31 Mar '11

31 Mar '11

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

2 2

Review swap for hotot micro blogging client
by Rahul Sundaram 31 Mar '11

31 Mar '11

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

2 2

[Test-Announce] ABRT Retrace Server Test Day today (2011-03-31)
by Kamil Paral 31 Mar '11

31 Mar '11

Fedora QA holds Test Day regarding ABRT 2 and Retrace Server on March 31: https://fedoraproject.org/wiki/Test_Day:2011-03-31_ABRT_Retrace_Server This test day will focus on Retrace Server feature [1] in Fedora 15 as well as ABRT 2.0. Refreshed and bright new test cases are prepared for your consumption. Please, join us on IRC [2] on Thursday. You're also welcomed to do the testing later. Use Bugzilla for bugs and upstream Trac [3] for missing features. [1] http://fedoraproject.org/wiki/Features/RetraceServer [2] irc://irc.freenode.net/fedora-test-day [3] https://fedorahosted.org/abrt/report _______________________________________________ test-announce mailing list test-announce(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel March 2011