Re: Fedora 15, new and exciting plans
On Tue, Nov 23, 2010 at 09:51:13PM +0100, Kevin Kofler wrote: Well, what's unfortunate is that HAL got deprecated long before replacements for all its parts were ready. KDE already waited for quite some time before implementing the replacements for HAL and was heavily criticized for that out of some circles. And STILL, the replacement isn't ready? It's been repeatedly pointed out that you still need HAL (or a workalike) if you want backlight control. The replacement isn't ready because the upstream kernel maintainer went AWOL for an extended period of time. Surely copyingpasting HAL code into a helper which runs as root as gnome- power-manager does isn't a long-term-viable solution! You're right! It's not! Which is why nobody has claimed it is. Is there a hope that radeon and nouveau get fixed to support XRandR backlight control by F15? (I don't give a darn about Catalyst/fglrx and nvidia.) There is a hope, but it's going to have to happen at the server level rather than the driver level - otherwise we're going to leave behind various other drivers as well. Not all the world is nvidia, intel or radeon despite how much easier that'd make things. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Sat, Nov 20, 2010 at 9:53 PM, Kevin Fenzi ke...@scrye.com wrote: On Sat, 20 Nov 2010 18:32:26 +0100 Michał Piotrowski mkkp...@gmail.com wrote: Hi, 2010/11/12 Kevin Fenzi ke...@scrye.com: Any other exciting work in progress that might land in F15 that people are actively working on? How about removing some old unix crud? (he said this and he saw that some people starts to gather firewood in the stack :)) Anyone uses gopher, uucp? I do use UUCP. ;) So do I. Its quite useful in particular circumstances. I'd have no problem with the uucp package making a user itself tho and dropping the user from base. I think it should be made by the package itself like all other users as per packaging guidelines. I'm also quite happy not to have it installed by default as I (and presumably pretty much everyone that would use it) would know how to yum install it and those that don't would likely get it via PackageKit-command-not-found Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
Bastien Nocera wrote: On Mon, 2010-11-15 at 15:44 +, Matthew Garrett wrote: On Fri, Nov 12, 2010 at 09:35:54AM -0700, Kevin Fenzi wrote: * Can we finally remove hal? (xfce4.8 shouldn't need it anymore with any luck). Not without a pile of X changes, which themselves are blocking on upstream kernel changes that I've submitted but which haven't been merged. For brightness? For GNOME at least, this is worked around in: http://git.gnome.org/browse/gnome-power-manager/tree/src/gpm-backlight- helper.c though a cleaner fix would certainly be appreciated. Huh? KDE trunk (4.6) already uses XRandR backlight setting in PowerDevil: http://websvn.kde.org/trunk/KDE/kdebase/workspace/powerdevil/daemon/backends/upower/xrandrbrightness.cpp?revision=1194096view=markup and it appears to work fine for those who have coded this. It might not to work for proprietary drivers, but that's those drivers' problem. KDE basically requires XRandR since at least 4.0. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Tue, 2010-11-23 at 18:23 +0100, Kevin Kofler wrote: Bastien Nocera wrote: On Mon, 2010-11-15 at 15:44 +, Matthew Garrett wrote: On Fri, Nov 12, 2010 at 09:35:54AM -0700, Kevin Fenzi wrote: * Can we finally remove hal? (xfce4.8 shouldn't need it anymore with any luck). Not without a pile of X changes, which themselves are blocking on upstream kernel changes that I've submitted but which haven't been merged. For brightness? For GNOME at least, this is worked around in: http://git.gnome.org/browse/gnome-power-manager/tree/src/gpm-backlight- helper.c though a cleaner fix would certainly be appreciated. Huh? KDE trunk (4.6) already uses XRandR backlight setting in PowerDevil: http://websvn.kde.org/trunk/KDE/kdebase/workspace/powerdevil/daemon/backends/upower/xrandrbrightness.cpp?revision=1194096view=markup and it appears to work fine for those who have coded this. It might not to work for proprietary drivers, but that's those drivers' problem. KDE basically requires XRandR since at least 4.0. this is a fairly new thing, AIUI: http://mjg59.livejournal.com/127103.html -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
Adam Williamson wrote: On Tue, 2010-11-23 at 18:23 +0100, Kevin Kofler wrote: It might not to work for proprietary drivers, but that's those drivers' problem. KDE basically requires XRandR since at least 4.0. this is a fairly new thing, AIUI: http://mjg59.livejournal.com/127103.html I know it's a fairly recent XRandR feature. But it's also part of KDE's track record to always require the latest XRandR spec. :-) As long as the drivers actually in Fedora support that, I'm fine with it. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Tue, Nov 23, 2010 at 06:23:10PM +0100, Kevin Kofler wrote: Huh? KDE trunk (4.6) already uses XRandR backlight setting in PowerDevil: http://websvn.kde.org/trunk/KDE/kdebase/workspace/powerdevil/daemon/backends/upower/xrandrbrightness.cpp?revision=1194096view=markup and it appears to work fine for those who have coded this. It might not to work for proprietary drivers, but that's those drivers' problem. KDE basically requires XRandR since at least 4.0. Well, that's unfortunate - XRandR backlight control is only implemented on -intel. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
Matthew Garrett wrote: On Tue, Nov 23, 2010 at 06:23:10PM +0100, Kevin Kofler wrote: Huh? KDE trunk (4.6) already uses XRandR backlight setting in PowerDevil: http://websvn.kde.org/trunk/KDE/kdebase/workspace/powerdevil/daemon/backends/upower/xrandrbrightness.cpp?revision=1194096view=markup and it appears to work fine for those who have coded this. It might not to work for proprietary drivers, but that's those drivers' problem. KDE basically requires XRandR since at least 4.0. Well, that's unfortunate - XRandR backlight control is only implemented on -intel. Well, what's unfortunate is that HAL got deprecated long before replacements for all its parts were ready. KDE already waited for quite some time before implementing the replacements for HAL and was heavily criticized for that out of some circles. And STILL, the replacement isn't ready? Surely copyingpasting HAL code into a helper which runs as root as gnome- power-manager does isn't a long-term-viable solution! How about next time the replacements get implemented BEFORE everyone scrambles to replace HAL and those who don't get yelled at for waiting until things actually work?! Is there a hope that radeon and nouveau get fixed to support XRandR backlight control by F15? (I don't give a darn about Catalyst/fglrx and nvidia.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Sat, Nov 20, 2010 at 09:49:42PM -0500, Kyle McMartin wrote: On Sun, Nov 21, 2010 at 03:33:56AM +0100, Kevin Kofler wrote: Me. And I'm already angry at having to manually modprobe floppy in rc.local: https://bugzilla.redhat.com/show_bug.cgi?id=567533 If you're angry about a minor inconvenience then I think you might want to seek counsel, but for what it's worth, I'm sorry I haven't gotten around to poking ACPI to see if there's a floppy connected. Hi Kevin, (and Bruno if you're watching) Please try this: https://koji.fedoraproject.org/koji/taskinfo?taskID=2614153 And let me know what the output is on your machine (it uses ACPI to query the _FDE table in firmware, so hopefully we can only bind to it if a floppy is connected.) Grepping for 'fde' and 'floppies' should give me in the info I need. regards, Kyle -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Mon, 2010-11-15 at 15:44 +, Matthew Garrett wrote: On Fri, Nov 12, 2010 at 09:35:54AM -0700, Kevin Fenzi wrote: * Can we finally remove hal? (xfce4.8 shouldn't need it anymore with any luck). Not without a pile of X changes, which themselves are blocking on upstream kernel changes that I've submitted but which haven't been merged. For brightness? For GNOME at least, this is worked around in: http://git.gnome.org/browse/gnome-power-manager/tree/src/gpm-backlight-helper.c though a cleaner fix would certainly be appreciated. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Mon, 2010-11-15 at 10:23 -0500, Nathaniel McCallum wrote: On 11/15/2010 10:11 AM, Adam Jackson wrote: On Fri, 2010-11-12 at 09:35 -0700, Kevin Fenzi wrote: * Can we finally remove hal? (xfce4.8 shouldn't need it anymore with any luck). Only 30 packages left requiring it, according to repoquery. smolt's probably the most interesting one to fix, if anyone's looking for a project. For the curious, the 30 packages (in rawhide) are: And gnome-lirc-properties as well. Which, it seems, wouldn't have worked if installed from a minimal installation. Oops. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Mon, Nov 22, 2010 at 11:39:29 -0500, Kyle McMartin k...@mcmartin.ca wrote: Hi Kevin, (and Bruno if you're watching) Please try this: https://koji.fedoraproject.org/koji/taskinfo?taskID=2614153 I've been running that kernel for a couple of days on one machine with floppies. (I am go to switch to -62 tonight.) Two other machines I have with floppies are running rawhide. One is essentially the same as the one I with get the info from shortly. The other is significantly different. And let me know what the output is on your machine (it uses ACPI to query the _FDE table in firmware, so hopefully we can only bind to it if a floppy is connected.) Grepping for 'fde' and 'floppies' should give me in the info I need. I'm going to start by assuming you want us to look at dmesg output. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Mon, Nov 22, 2010 at 11:39:29 -0500, Kyle McMartin k...@mcmartin.ca wrote: On Sat, Nov 20, 2010 at 09:49:42PM -0500, Kyle McMartin wrote: And let me know what the output is on your machine (it uses ACPI to query the _FDE table in firmware, so hopefully we can only bind to it if a floppy is connected.) Grepping for 'fde' and 'floppies' should give me in the info I need. I didn't find either string in messages or dmesg output. My machines are all from around 2003, in case more recent ACPI support is needed. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Mon, Nov 22, 2010 at 08:00:55PM -0600, Bruno Wolff III wrote: https://koji.fedoraproject.org/koji/taskinfo?taskID=2614153 I've been running that kernel for a couple of days on one machine with floppies. (I am go to switch to -62 tonight.) Two other machines I have with floppies are running rawhide. One is essentially the same as the one I with get the info from shortly. The other is significantly different. Unlikely, given I only built it on Sunday night... It's a scratch build with a patch included. (Yes, the messages would be in dmesg.) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Mon, Nov 22, 2010 at 21:24:41 -0500, Kyle McMartin k...@mcmartin.ca wrote: On Mon, Nov 22, 2010 at 08:00:55PM -0600, Bruno Wolff III wrote: https://koji.fedoraproject.org/koji/taskinfo?taskID=2614153 I've been running that kernel for a couple of days on one machine with floppies. (I am go to switch to -62 tonight.) Two other machines I have with floppies are running rawhide. One is essentially the same as the one I with get the info from shortly. The other is significantly different. Unlikely, given I only built it on Sunday night... It's a scratch build with a patch included. (Yes, the messages would be in dmesg.) I saw a -61 and assumed it was the same build. I was going to double check. Things are taking me longer to do here as I am having some annoying video problems with rawhide. It takes a long time to switch work spaces and some times raising windows is also takes a long time. Anyway, I'll try it out on one machine in a little bit. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Mon, Nov 22, 2010 at 21:24:41 -0500, Kyle McMartin k...@mcmartin.ca wrote: (Yes, the messages would be in dmesg.) [2.691809] acpi_fde: failed to evaluate _FDE [2.692151] Floppy drive(s): fd0 is 1.44M [2.724514] floppy: loaded /dev/fd0 was created. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Mon, Nov 22, 2010 at 21:16:40 -0600, Bruno Wolff III br...@wolff.to wrote: On Mon, Nov 22, 2010 at 21:24:41 -0500, Kyle McMartin k...@mcmartin.ca wrote: (Yes, the messages would be in dmesg.) [2.691809] acpi_fde: failed to evaluate _FDE [2.692151] Floppy drive(s): fd0 is 1.44M [2.724514] floppy: loaded /dev/fd0 was created. I switched to the -62 kernel and /dev/fd0 was NOT created. (I wanted to make sure I hadn't put something on that machine to make the floppy available at boot.) So the patch looks good from the perspective of people who have floppies. I think I can test it on a machine that doesn't have a floppy drive tomorrow. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Mon, Nov 22, 2010 at 09:32:09PM -0600, Bruno Wolff III wrote: [2.691809] acpi_fde: failed to evaluate _FDE [2.692151] Floppy drive(s): fd0 is 1.44M [2.724514] floppy: loaded /dev/fd0 was created. Yeah, it falls back to the ordinary probing if anything fails. Can you send me (privately if you want, or fpaste) the dmesg of the machine? --Kyle I switched to the -62 kernel and /dev/fd0 was NOT created. (I wanted to make sure I hadn't put something on that machine to make the floppy available at boot.) So the patch looks good from the perspective of people who have floppies. I think I can test it on a machine that doesn't have a floppy drive tomorrow. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
Alasdair G Kergon wrote: An example of the way I see it working is like this: Say you have a Volume Group VG1 across two PVs, PV1 and PV2, containing Logical Volume LV1 containing the root filesystem. You have a trigger rule saying When you see the whole of VG1, activate LV1 inside it and another saying When you see the filesystem with UUID X, mount it. (Default rules can be generic of course, like 'activate any VG when you see it' and 'activate any LV when you see it' and 'mount any filesystem when you see it'.) Nice. You still need a timeout to avoid waiting for ever for the root filesystem to appear when one of the PV has been disconnected from the system. But this lost hope timeout is a lot better than the current wait in any case one. -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
Hi. On Sun, 21 Nov 2010 09:26:58 +0100, Roberto Ragusa wrote You still need a timeout to avoid waiting for ever for the root filesystem to appear when one of the PV has been disconnected from the system. If you cannot assemble the root file system, what is init supposed to do instead of waiting forever? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
Ralf Ertzinger wrote: Hi. On Sun, 21 Nov 2010 09:26:58 +0100, Roberto Ragusa wrote You still need a timeout to avoid waiting for ever for the root filesystem to appear when one of the PV has been disconnected from the system. If you cannot assemble the root file system, what is init supposed to do instead of waiting forever? Print some kind of error unable to find root (UUID=x) and/or reboot or give you some kind of shell if there is enough rescue environment to let a prompt to be in some way useful. -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
Le vendredi 19 novembre 2010 à 21:46 -0800, Adam Williamson a écrit : On Mon, 2010-11-15 at 10:23 -0500, Nathaniel McCallum wrote: libconcord-0:0.21-10.fc14.i686 libconcord-0:0.21-10.fc14.x86_64 I don't know exactly what that is, but I can't imagine it'd be terribly hard to port to udev or something for anyone who does know about it. Libconcord just needs the device to be writeable by the current user (it's kind of hard to program a remote you can't write to) -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Sat, 2010-11-20 at 10:37 +0100, Nicolas Mailhot wrote: Le vendredi 19 novembre 2010 à 21:46 -0800, Adam Williamson a écrit : On Mon, 2010-11-15 at 10:23 -0500, Nathaniel McCallum wrote: libconcord-0:0.21-10.fc14.i686 libconcord-0:0.21-10.fc14.x86_64 I don't know exactly what that is, but I can't imagine it'd be terribly hard to port to udev or something for anyone who does know about it. Libconcord just needs the device to be writeable by the current user (it's kind of hard to program a remote you can't write to) oh, that's right. I think I even reported that bug in the first place :) (I remember only being able to use it as root before). Now I remember, there's a file /usr/share/PolicyKit/policy/org.freedesktop.hal.device-access.libconcord.policy which goes along with it. I'm sure that should be easy to do in udev instead. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Meego and Navit ? Was Re: Fedora 15, new and exciting plans
On Sat, Nov 20, 2010 at 5:22 AM, Adam Williamson awill...@redhat.com wrote: On Thu, 2010-11-18 at 14:15 -0700, Linuxguy123 wrote: I realize that most people on this mailing list are focused on infrastructure and server/desktop usage. But some of us are looking forward to using future Fedora releases on tablets in vehicular infotainment systems. To this end, what are the plans for releasing Meego as part of Fedora in F15 ? It would also be really nice to see Navit make it into Fedora. Its been almost there for a long time (since F10 ?) but somehow it never seems to make it. Any chance someone out there could give it a boost ? https://bugzilla.redhat.com/show_bug.cgi?id=654374 I'm sorry about that - I put in a review request for it shortly after I came to RH as at the time I was poking about with running it on my TinyBook(tm) using my phone as a GPS provider via bluetooth, which was all fun and shiny, but it never had much serious use potential andUVU frankly I got bored with it, which is why I didn't work on the package as hard as I probably should have done. Anyway, someone else has taken it over now, so hopefully it'll finally get done. (Presumably, though, Nokia will come up with something for navigation purposes? They seem fairly big on IVI for Meego and frankly I don't see them relying on Navit. Of course, whatever they come up with may be non-F/OSS, I guess.) They made a maps purchase a while ago which on the n900 is now called ovi maps (don't remember its original name) but its quite good but unfortunately not open source. Presumably it might well be used, but presumably the vendors that use the IVI system are free to user what ever Nav app they choose. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
Hi, 2010/11/12 Kevin Fenzi ke...@scrye.com: Any other exciting work in progress that might land in F15 that people are actively working on? How about removing some old unix crud? (he said this and he saw that some people starts to gather firewood in the stack :)) Anyone uses gopher, uucp? sync:x:5:0:sync:/sbin:/bin/sync shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown halt:x:7:0:halt:/sbin:/sbin/halt mail:x:8:12:mail:/var/spool/mail:/sbin/nologin uucp:x:10:14:uucp:/var/spool/uucp:/sbin/nologin operator:x:11:0:operator:/root:/sbin/nologin games:x:12:100:games:/usr/games:/sbin/nologin gopher:x:13:30:gopher:/var/gopher:/sbin/nologin ftp:x:14:50:FTP User:/var/ftp:/sbin/nologin nobody:x:99:99:Nobody:/:/sbin/nologin Who uses floppy? gopher:x:30: video:x:39: dip:x:40: ftp:x:50: lock:x:54: audio:x:63: nobody:x:99: users:x:100: utmp:x:22: exim:x:93: floppy:x:19: vcsa:x:69: cdrom:x:11: tape:x:33: dialout:x:18: /etc/inittab should not be needed anymore. Other ideas? Kind regards, Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Sat, Nov 20, 2010 at 06:32:26PM +0100, Michał Piotrowski wrote: How about removing some old unix crud? (he said this and he saw that some people starts to gather firewood in the stack :)) Anyone uses gopher, uucp? sync:x:5:0:sync:/sbin:/bin/sync Someone at Red Hat asked me once what the purpose of the sync user was, and I did some research and wrote the reply below. It may be interesting. Rich. quote If you read this old (1988) advisory: http://www.cert.org/advisories/CA-1988-01.html it seems clear the original intent of the 'sync' user was to allow an administrator to log in as 'sync' and have that synchronize the disks, without needing a password. There were apparently other user accounts like 'who' with a similar purpose, and in the current passwd file we can find similar accounts like 'halt' and 'shutdown'. However having a passwordless guest account, even without a shell, is a security hole (because some misconfigured or poorly written services could allow access from one of these users): http://www.cert.org/tech_tips/unix_configuration_guidelines.html#A.1.ii I tried to find out for you when the 'sync' user was added to Unix. It's *not* in Unix v7 (1979): http://unix-tree.huihoo.org/V7/etc/passwd.html It *is* in Fedora Core 1 (2003) and RHL 5.0 (1996?) and Debian 0.9 (1995). All of these have the password field set to '*' to prevent the security problem. After a lot of internet spelunking, I found that MCC Interim Linux (1992?) contained a 'sync' user with no password! So you could have walked up to an MCC Interim Linux box c1992, and logged in as 'sync' / no password, and it would have synchronized the disks. It seems we inherited this tradition from Unix systems dating back to some time in the 1980s. It was carried over to Linux in 1991/1992, but soon afterwards the empty password field was replaced with a '*' because of security concerns, and it's been like that to this day. /quote -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
Hi. On Sat, 20 Nov 2010 17:50:43 +, Richard W.M. Jones wrote /quote Interesting. But the short version of that means that all those users are useless in their current form, and could be removed? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Sat, Nov 20, 2010 at 06:57:16PM +0100, Ralf Ertzinger wrote: Interesting. But the short version of that means that all those users are useless in their current form, and could be removed? An administrator might decide to enable one of these accounts, but I'd say that would be pretty unwise. Maybe if your computer is absolutely never attached to a network :-) The only other things I can think of: - Could there be the odd file that is owned by one of these users? (Likely a bug I would think ...) - It's required by some standard like POSIX or FHS. My google-fu turns up nothing right now, but I could have missed something. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
2010/11/20 Richard W.M. Jones rjo...@redhat.com: On Sat, Nov 20, 2010 at 06:57:16PM +0100, Ralf Ertzinger wrote: Interesting. But the short version of that means that all those users are useless in their current form, and could be removed? An administrator might decide to enable one of these accounts, but I'd say that would be pretty unwise. Maybe if your computer is absolutely never attached to a network :-) The only other things I can think of: - Could there be the odd file that is owned by one of these users? (Likely a bug I would think ...) Is there any rpm error message when you install package with such file and user isn't exist? - It's required by some standard like POSIX or FHS. My google-fu turns up nothing right now, but I could have missed something. Yeah, possible. But to me it means that these standards need to be updated. It seems to me that ancient, obsolete things should be removed (someone may want to create museum page - Antique things that have been removed :)), not preserved for ages. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Best regards, Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans (biosdevname)
On Sun, Nov 14, 2010 at 07:53:40AM -0600, Matt Domsch wrote: biosdevname installed by default, used in the installer and at runtime to rename Dell and HP server onboard NICs from non-deterministic ethX to clearly labeled lomX matching the chassis silkscreen. But why ???lomX??? for all? Isn't Lights-Out-Management available only on first ethernet port and often on dedicated port? This has nothing to do with Lights-Out-Management. LOM also == LAN on Motherboard. Since you're already silkscreening this on the chassis of your systems, clearly this ship is well out of the harbor, but that confusion seems like a completely legitimate concern. Seems like it could easily result in management interfaces getting plugged into the wrong networks. Also, I gotta say, it really shouldn't be LAN on Motherboard, since it's just an adapter, not actually a whole lan. It should clearly be NIC on Motherboard, or nom. And then you could silkscreen lolcats on to the servers, which I think would be a win for everyone. -- Matthew Miller mat...@mattdm.org Senior Systems Architect -- Instructional Research Computing Services Harvard School of Engineering Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Sat, 20 Nov 2010 18:32:26 +0100 Michał Piotrowski mkkp...@gmail.com wrote: Hi, 2010/11/12 Kevin Fenzi ke...@scrye.com: Any other exciting work in progress that might land in F15 that people are actively working on? How about removing some old unix crud? (he said this and he saw that some people starts to gather firewood in the stack :)) Anyone uses gopher, uucp? I do use UUCP. ;) I'd have no problem with the uucp package making a user itself tho and dropping the user from base. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
Adam Williamson wrote: On the positive side, it doesn't do anything terribly complicated, it just ships a single HAL rules file which does this: append key=info.capabilities type=strlistaccess_control/append merge key=access_control.file type=copy_propertylinux.device_file/merge merge key=access_control.type type=stringlibconcord/merge /match for a bunch of different devices (all the various supported remotes). I don't know exactly what that is, but I can't imagine it'd be terribly hard to port to udev or something for anyone who does know about it. That stuff ALREADY doesn't work and hasn't for a couple releases, ACL support has been disabled in Fedora's HAL builds! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
Michał Piotrowski wrote: Anyone uses gopher, uucp? Me. gopher://www.calcforge.org/1/ Web version: http://www.calcforge.org:70/ https://admin.fedoraproject.org/pkgdb/acls/name/kio_gopher (I don't use uucp though, but I see from Kevin Fenzi's reply that there's at least one person using that too. :-p) Who uses floppy? Me. And I'm already angry at having to manually modprobe floppy in rc.local: https://bugzilla.redhat.com/show_bug.cgi?id=567533 Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Sun, Nov 21, 2010 at 03:33:56AM +0100, Kevin Kofler wrote: Me. And I'm already angry at having to manually modprobe floppy in rc.local: https://bugzilla.redhat.com/show_bug.cgi?id=567533 If you're angry about a minor inconvenience then I think you might want to seek counsel, but for what it's worth, I'm sorry I haven't gotten around to poking ACPI to see if there's a floppy connected. regards, Kyle -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Sun, 2010-11-21 at 03:19 +0100, Kevin Kofler wrote: Adam Williamson wrote: On the positive side, it doesn't do anything terribly complicated, it just ships a single HAL rules file which does this: append key=info.capabilities type=strlistaccess_control/append merge key=access_control.file type=copy_propertylinux.device_file/merge merge key=access_control.type type=stringlibconcord/merge /match for a bunch of different devices (all the various supported remotes). I don't know exactly what that is, but I can't imagine it'd be terribly hard to port to udev or something for anyone who does know about it. That stuff ALREADY doesn't work and hasn't for a couple releases, ACL support has been disabled in Fedora's HAL builds! I dunno, I haven't had to re-program my remote for a while, so I haven't used it. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Meego and Navit ? Was Re: Fedora 15, new and exciting plans
On Thu, 2010-11-18 at 14:15 -0700, Linuxguy123 wrote: I realize that most people on this mailing list are focused on infrastructure and server/desktop usage. But some of us are looking forward to using future Fedora releases on tablets in vehicular infotainment systems. To this end, what are the plans for releasing Meego as part of Fedora in F15 ? It would also be really nice to see Navit make it into Fedora. Its been almost there for a long time (since F10 ?) but somehow it never seems to make it. Any chance someone out there could give it a boost ? https://bugzilla.redhat.com/show_bug.cgi?id=654374 I'm sorry about that - I put in a review request for it shortly after I came to RH as at the time I was poking about with running it on my TinyBook(tm) using my phone as a GPS provider via bluetooth, which was all fun and shiny, but it never had much serious use potential and frankly I got bored with it, which is why I didn't work on the package as hard as I probably should have done. Anyway, someone else has taken it over now, so hopefully it'll finally get done. (Presumably, though, Nokia will come up with something for navigation purposes? They seem fairly big on IVI for Meego and frankly I don't see them relying on Navit. Of course, whatever they come up with may be non-F/OSS, I guess.) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Mon, 2010-11-15 at 10:23 -0500, Nathaniel McCallum wrote: libconcord-0:0.21-10.fc14.i686 libconcord-0:0.21-10.fc14.x86_64 This one's a bit tricky, as it does something unique that you can't do any other way (it lets you program Logitech Harmony remote controls - Logitech only provide a tool for Windows, and AFAIK there's no other Linux tool available), and to my knowledge there's no patch to make it not use HAL available. On the positive side, it doesn't do anything terribly complicated, it just ships a single HAL rules file which does this: append key=info.capabilities type=strlistaccess_control/append merge key=access_control.file type=copy_propertylinux.device_file/merge merge key=access_control.type type=stringlibconcord/merge /match for a bunch of different devices (all the various supported remotes). I don't know exactly what that is, but I can't imagine it'd be terribly hard to port to udev or something for anyone who does know about it. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans (biosdevname)
Once upon a time, Jon Masters jonat...@jonmasters.org said: I've had a few off-list conversations with various community members about this. One thing that came up was that the alternative namespace is necessary, I'm not sold on this, but: but also that lom is a sub-optimal choice. One idea that did come up was simply to call them net (net0, etc.) or perhaps net followed by another letter like netm or something. If you are adding a letter, stick with tried-and-true eth. Also, if your intention is to name the motherboard NICs, don't start with 0 - I haven't seen a motherboard that does. If you are trying to distinguish the motherboard NICs and make them easier to ID, follow what the motherboard makers use (1, 2, ..., not 0-based). To avoid bikeshedding this to death though, I think Matt's lom naming is fine for the moment unless we happen to all agree on something else. There are legitimate concerns with lom being an established abbreviation already associated with built-in NICs, so it is hardly bikeshedding to disagree with that. In any case, is this going to be something that can be disabled easily? We have something like 18 years of Linux networking history that says ethernet devices are eth[0-9]+, and I'm not really interested in auditing all the tools and scripts I use to make sure they handle something different at this time. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Monday, 15 November 2010 at 12:29, Richard W.M. Jones wrote: [...] This is a silly straw-man. No one[1] formats external HDs with anything other than MS-DOS FAT. Fedora changing the default for the main hard disk will not make any difference to this case of your contrarian user giving away LVM-formatted USB drives. I'd think NTFS would be much more common, if only for its ability to store files larger than 4GB. Regards, Dominik -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu Faith manages. -- Delenn to Lennier in Babylon 5:Confessions and Lamentations -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On 11/18/2010 8:09, Dominik 'Rathann' Mierzejewski wrote: On Monday, 15 November 2010 at 12:29, Richard W.M. Jones wrote: [...] This is a silly straw-man. No one[1] formats external HDs with anything other than MS-DOS FAT. Fedora changing the default for the main hard disk will not make any difference to this case of your contrarian user giving away LVM-formatted USB drives. I'd think NTFS would be much more common, if only for its ability to store files larger than 4GB. UDF can be a useful alternative since Windows = Vista, RHEL = 5, and Fedora handle it perfectly. Windows XP can read it. OS X can also use it read/write, but you have to manually mount it first. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans (NM bridging !)
On Fri, 2010-11-12 at 09:35 -0700, Kevin Fenzi wrote: * Will NM finally be able to do bridging? :drool: -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Meego and Navit ? Was Re: Fedora 15, new and exciting plans
I realize that most people on this mailing list are focused on infrastructure and server/desktop usage. But some of us are looking forward to using future Fedora releases on tablets in vehicular infotainment systems. To this end, what are the plans for releasing Meego as part of Fedora in F15 ? It would also be really nice to see Navit make it into Fedora. Its been almost there for a long time (since F10 ?) but somehow it never seems to make it. Any chance someone out there could give it a boost ? https://bugzilla.redhat.com/show_bug.cgi?id=654374 Thanks LG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans (biosdevname)
On Tue, Nov 16, 2010 at 09:32:37AM -0500, Jon Masters wrote: I've had a few off-list conversations with various community members about this. One thing that came up was that the alternative namespace is necessary, but also that lom is a sub-optimal choice. One idea that did come up was simply to call them net (net0, etc.) or perhaps net followed by another letter like netm or something. To avoid bikeshedding this to death though, I think Matt's lom naming is fine for the moment unless we happen to all agree on something else. There's an upstream conversation about the naming convention here: http://marc.info/?l=linux-hotplugm=129003163201746w=2 For the record, right now, biosdevname uses: emN_(vf).(vlan) for embedded devices pci(slot)#(port)_(vf).(vlan) for add-in cards. If the device does not support SR-IOV, then the _(vf) part is omitted. If no huge objections on the upstream thread, I'll push this into rawhide ASAP. Thanks, Matt -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans (biosdevname)
On Tue, Nov 16, 2010 at 08:48:09AM -0600, Chris Adams wrote: In any case, is this going to be something that can be disabled easily? We have something like 18 years of Linux networking history that says ethernet devices are eth[0-9]+, and I'm not really interested in auditing all the tools and scripts I use to make sure they handle something different at this time. It can always be disabled at runtime by writing whatever you want into /etc/udev/rules.d/70-persistent-net.rules. Whether or not we'll have a way to disable it in the installer is TBD, right now there won't be. Thanks, Matt -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans (biosdevname)
On Thu, Nov 18, 2010 at 9:16 PM, Matt Domsch matt_dom...@dell.com wrote: On Tue, Nov 16, 2010 at 09:32:37AM -0500, Jon Masters wrote: I've had a few off-list conversations with various community members about this. One thing that came up was that the alternative namespace is necessary, but also that lom is a sub-optimal choice. One idea that did come up was simply to call them net (net0, etc.) or perhaps net followed by another letter like netm or something. To avoid bikeshedding this to death though, I think Matt's lom naming is fine for the moment unless we happen to all agree on something else. There's an upstream conversation about the naming convention here: http://marc.info/?l=linux-hotplugm=129003163201746w=2 For the record, right now, biosdevname uses: emN_(vf).(vlan) for embedded devices pci(slot)#(port)_(vf).(vlan) for add-in cards. If the device does not support SR-IOV, then the _(vf) part is omitted. If no huge objections on the upstream thread, I'll push this into rawhide ASAP. Presumably there will be something in place that won't change this on upgrades so that people don't end up in inoperable networking on the next 'yum upgrade' after it gets installed. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans (biosdevname)
On Tue, Nov 16, 2010 at 09:24:26AM -0500, Matthew Miller wrote: Also, I gotta say, it really shouldn't be LAN on Motherboard, since it's just an adapter, not actually a whole lan. It should clearly be NIC on Motherboard, or nom. And then you could silkscreen lolcats on to the servers, which I think would be a win for everyone. For the bike-shed-painting record, I'm kidding about the above, in case that wasn't clear. I do think lom is a bad choice, and am not convinced of a very compelling reason to not use eth, but I don't think it's worth an argument. (But, c'mon: the first one could be 'nom', the second one 'nomnom', and the third one 'nomnomnom'. Delicious!) -- Matthew Miller mat...@mattdm.org Senior Systems Architect -- Instructional Research Computing Services Harvard School of Engineering Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Meego and Navit ? Was Re: Fedora 15, new and exciting plans
2010/11/19 Linuxguy123 linuxguy...@gmail.com: I realize that most people on this mailing list are focused on infrastructure and server/desktop usage. But some of us are looking forward to using future Fedora releases on tablets in vehicular infotainment systems. To this end, what are the plans for releasing Meego as part of Fedora in F15 ? It would also be really nice to see Navit make it into Fedora. Its been almost there for a long time (since F10 ?) but somehow it never seems to make it. Any chance someone out there could give it a boost ? https://bugzilla.redhat.com/show_bug.cgi?id=654374 Thanks LG Meego haven't officially released any tablet UX plan yet, we still need to wait some time. Regards, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans (biosdevname)
On Thu, Nov 18, 2010 at 10:06:17PM +, Peter Robinson wrote: On Thu, Nov 18, 2010 at 9:16 PM, Matt Domsch matt_dom...@dell.com wrote: On Tue, Nov 16, 2010 at 09:32:37AM -0500, Jon Masters wrote: I've had a few off-list conversations with various community members about this. One thing that came up was that the alternative namespace is necessary, but also that lom is a sub-optimal choice. One idea that did come up was simply to call them net (net0, etc.) or perhaps net followed by another letter like netm or something. To avoid bikeshedding this to death though, I think Matt's lom naming is fine for the moment unless we happen to all agree on something else. There's an upstream conversation about the naming convention here: http://marc.info/?l=linux-hotplugm=129003163201746w=2 For the record, right now, biosdevname uses: ?emN_(vf).(vlan) for embedded devices ?pci(slot)#(port)_(vf).(vlan) for add-in cards. If the device does not support SR-IOV, then the _(vf) part is omitted. If no huge objections on the upstream thread, I'll push this into rawhide ASAP. Presumably there will be something in place that won't change this on upgrades so that people don't end up in inoperable networking on the next 'yum upgrade' after it gets installed. yes, if /etc/udev/rules.d/70-persistent-net.rules is in place, that is used in preference to whatever biosdevname would choose. If a rule for your device isn't in that file though, biosdevname kicks in to ask udev to rename it. -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans (biosdevname)
On Tue, 2010-11-16 at 09:24 -0500, Matthew Miller wrote: On Sun, Nov 14, 2010 at 07:53:40AM -0600, Matt Domsch wrote: biosdevname installed by default, used in the installer and at runtime to rename Dell and HP server onboard NICs from non-deterministic ethX to clearly labeled lomX matching the chassis silkscreen. But why ???lomX??? for all? Isn't Lights-Out-Management available only on first ethernet port and often on dedicated port? This has nothing to do with Lights-Out-Management. LOM also == LAN on Motherboard. Since you're already silkscreening this on the chassis of your systems, clearly this ship is well out of the harbor, but that confusion seems like a completely legitimate concern. Seems like it could easily result in management interfaces getting plugged into the wrong networks. Also, I gotta say, it really shouldn't be LAN on Motherboard, since it's just an adapter, not actually a whole lan. It should clearly be NIC on Motherboard, or nom. And then you could silkscreen lolcats on to the servers, which I think would be a win for everyone. I've had a few off-list conversations with various community members about this. One thing that came up was that the alternative namespace is necessary, but also that lom is a sub-optimal choice. One idea that did come up was simply to call them net (net0, etc.) or perhaps net followed by another letter like netm or something. To avoid bikeshedding this to death though, I think Matt's lom naming is fine for the moment unless we happen to all agree on something else. Meanwhile, there are two other things I'm keeping ticking over: 1). Potential kernel-based solutions to augment this (but not otherwise affect what would be in F-15). More on that another time. 2). Naming of non-network devices. Both DMTF and other groups (ACPI, PCI, etc.) looking at the problem of persistent device to slot mappings have all looked at more than network. While Matt is (rightfully) looking at networking in F-15, we need to remember this problem actually will in future also necessitate work on other non-network devices, too. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
Le Lun 15 novembre 2010 23:51, Karel Klic a écrit : Dne 15.11.2010 23:04, Matthew Garrett napsal(a): On Mon, Nov 15, 2010 at 05:01:30PM -0500, Colin Walters wrote: On Mon, Nov 15, 2010 at 4:13 PM, Matthew Garrettmj...@srcf.ucam.org wrote: Leaving the retracing at the user's end of things means that the user at least has a choice in the matter - I'm unlikely to submit any firefox crashes if I don't have an opportunity to look at what's in the backtrace. We can make symbols available for local tracing without forcing the user to download the entirity of the debuginfo, and that would seem a more reasonable approach. http://fedoraproject.org/wiki/Features/DebuginfoFS Agreed, debuginfofs will be better for many scenarios. Major advantage of the retrace server is that you can get a good backtraces even from unfresh coredumps. And why can't this be done with debuginfofs ? It's the same data. -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
Le Mar 16 novembre 2010 00:15, Jóhann B. Guðmundsson a écrit : On 11/15/2010 09:27 PM, Richard W.M. Jones wrote: Nobody has yet proven that LVM is a problem Well if you don't consider what Lennart mentioned [1] as a con against usage of lvm by default The con was the assumption that LVM init could not be fixed. And this was completely disproved later http://lists.fedoraproject.org/pipermail/devel/2010-November/145554.html LVM can and should be fixed at the init level (brtfs is only going to overlap with a little part of was LVM does, so taking it as an excuse to avoid fixing lvm init is wrong) -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
Dne 16.11.2010 11:04, Nicolas Mailhot napsal(a): Le Lun 15 novembre 2010 23:51, Karel Klic a écrit : Major advantage of the retrace server is that you can get a good backtraces even from unfresh coredumps. And why can't this be done with debuginfofs ? It's the same data. GDB pretty printers (written in Python) need to be in the in the same tree as GDB. They are distributed among packages, so if you want them, you need to install GDB and coredump-related packages (containing the pretty printers, in version which matches the coredump) to some directory, chroot there, and then run the GDB. Then it outputs prettified backtrace. I haven't spent too much time thinking about debuginfofs, so I do not know what would be possible if we'd work on it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Tue, 16 Nov 2010 18:57:19 +0100, Karel Klic wrote: Dne 16.11.2010 11:04, Nicolas Mailhot napsal(a): Le Lun 15 novembre 2010 23:51, Karel Klic a écrit : Major advantage of the retrace server is that you can get a good backtraces even from unfresh coredumps. And why can't this be done with debuginfofs ? It's the same data. GDB pretty printers (written in Python) need to be in the in the same tree as GDB. They are distributed among packages, Maybe not, it would have to be tried. I was discussing it later with the GDB team and the Python Pretty Printers should be both cross-arch compatible and they should work even for other versions - such as using GDB `set sysroot'. /usr/share/gdb/auto-load/usr/lib64/libstdc++.so.6.0.14-gdb.py from libstdc++-4.5.1-4.fc14.x86_64 already contains the version string `6.0.14' so there can be multiple such `host OS' packages installed for supporting various `target OS' versions. Regards, Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On 11/15/2010 02:41 AM, Matthew Garrett wrote: LVM's a fantasically useful tool in a wide range of cases, but I don't think that in the*typical* laptop/desktop install any of that functionality ever gets used. That's the essence of what's being discussed here laptop/desktop/workstation installs default to ext4 and experienced users/sysadmins those that generally know what lvm is with all it's bells and whistles and want to use it will choose it during installation. Those that claim that novice end users have no problem using LVM I want them to perform just this very simple case of two person sharing what ever data between themselves could be family photo music video and what not. Partition an external connected HD that you got laying around with LVM. Hand that drive to the novice end user running GNU/Linux on laptop/desktop/workstation ( if he's not you can just insert a live cd and boot from it ) and ask him to copy a single file to that drive no more no less. Take note on how many obstacle are in the users way from performing this simple yet commonly used test case. Repeate process this time with ext4 only for comparison. After performing this simple test case and you have gathered the necessary data revisit the topic of how easy it is for the novice end user to use LVM and if he will ever use what ever tools we provide him with to take advantage of all the features LVM brings and if it makes sense to default to it. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Mon, Nov 15, 2010 at 08:53:03AM +, Jóhann B. Guðmundsson wrote: On 11/15/2010 02:41 AM, Matthew Garrett wrote: LVM's a fantasically useful tool in a wide range of cases, but I don't think that in the*typical* laptop/desktop install any of that functionality ever gets used. That's the essence of what's being discussed here laptop/desktop/workstation installs default to ext4 and experienced users/sysadmins those that generally know what lvm is with all it's bells and whistles and want to use it will choose it during installation. Those that claim that novice end users have no problem using LVM I want them to perform just this very simple case of two person sharing what ever data between themselves could be family photo music video and what not. Partition an external connected HD that you got laying around with LVM. Hand that drive to the novice end user running GNU/Linux on laptop/desktop/workstation ( if he's not you can just insert a live cd and boot from it ) and ask him to copy a single file to that drive no more no less. Take note on how many obstacle are in the users way from performing this simple yet commonly used test case. Repeate process this time with ext4 only for comparison. After performing this simple test case and you have gathered the necessary data revisit the topic of how easy it is for the novice end user to use LVM and if he will ever use what ever tools we provide him with to take advantage of all the features LVM brings and if it makes sense to default to it. This is a silly straw-man. No one[1] formats external HDs with anything other than MS-DOS FAT. Fedora changing the default for the main hard disk will not make any difference to this case of your contrarian user giving away LVM-formatted USB drives. Rich. [1] for a sufficiently small value -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On 11/14/2010 12:41 AM, Richard W.M. Jones wrote: 1. http://fedoraproject.org/wiki/Features/NoDefaultLVM Info on this page is completely obsolete! | * Certain filesystem features (ext3 barriers) are unavailable when run | on top of LVM. No longer true, barriers (resp. flush) are fully supported with LVM now. | * Software RAID performance is greatly reduced when layered on LVM. Not true. The main performance problem was that sometimes LVM over RAID created misaligned devices with huge performance loss. Because both MD/DM subsystems now respects topology info and also use default 1MB alignment if there is not topology info, this is fixed. Applies to LUKS too for FDE (full disk encryption). Btw LVM over MD RAID is very common configuration. Moreover LVM will not duplicate RAID functionality in kernel but will try to use existing MD code (see dm-devel list track patches and for more info). | * LVM partitions are not automatically assembled by the desktop systems. No idea where this come from? All required volumes are assembled. Moreover, this is not lvm problem but problem in desktop extensions like udisks. (Also image you attach iSCSI device with LVM with hundreds of LVs. You probably do not want to activate everything automatically - this is job for admin to setup such configurations. Counterexample is USB disk - most of users want to activate it automatically.) Also note: - Discard/TRIM is supported for linear mappings and multipath in LVM in 2.6.37. I am not sure if LVM default is good or not for Fedora but please do not use obsolete arguments here - almost everything you are complaining about was fixed or there are known ways how to improve or fix it (like move scanning of devices in lvm to udev responsibility etc.) You can replace some functionality with btrfs, but lvm+luks+raid+artbitrary fs is still very flexible - maybe not for you but definitely for some users. Thanks, Milan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On 11/15/2010 11:29 AM, Richard W.M. Jones wrote: This is a silly straw-man. No one[1] formats external HDs with anything other than MS-DOS FAT. Fedora changing the default for the main hard disk will not make any difference to this case of your contrarian user giving away LVM-formatted USB drives. Agreed kinda bad example on my behalf since I based it on real live scenario in which I had been approached by a not so experienced Linux user which actually had formatting and partition his external drive as LVM ( and was having trouble with it ) and when I asked why he choose to format and partition with LVM he said and I quote I just took look at how it was setup on my desktop so I decided to create the same since I expected it would just work if I plugged it to another Linux box I had setup at home. I'll have it in mind next time I mention a simple test case that it should be targeted against mixed OS environments instead of having it solely focusing on easy of use and interoperability between Linux implementations. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Mon, Nov 15, 2010 at 11:29:06AM +, Richard W.M. Jones wrote: This is a silly straw-man. No one[1] formats external HDs with anything other than MS-DOS FAT. Fedora changing the default for the main hard disk will not make any difference to this case of your contrarian user giving away LVM-formatted USB drives. Rich. [1] for a sufficiently small value there are very good reasons to use anything but DOS-FAT. For example F10 and F12 automount said filesystems with drastically different options by default (filename downcasing), using any other FS avoids this trap and many other issues. Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: External HD fs was: Re: Fedora 15, new and exciting plans
On 11/15/2010 02:03 PM, Frank Murphy wrote: On 15/11/10 13:54, Richard Zidlicky wrote: snip there are very good reasons to use anything but DOS-FAT. For example F10 and F12 automount said filesystems with drastically different options by default (filename downcasing), using any other FS avoids this trap and many other issues. Richard What would you reccomend? That would attched itself nicely to Win=7, and Mac=Leopard out of the box (so to speak) Without being expelled from College. (we're talking Linux is evil incarnate territory) I think you got things backwards which is perhaps because we have gotten so used to chasing other OSes that we have lost focus on the fact we are trying to create good usable desktop on GNU/Linux and we should turn our focus on Linux and start by fixing all interoperability issues and improve the ease of use and sharing between 2 Linux desktops ( and various *DE ) when we have done that we can start looking at interoperability issues with other OSes. To my knowledge there is nothing preventing other OS to support all the LinuxFS out there and until they choose to do so users of such OS will simply have to install tools like ext2read [1] ( Windows 7 ) if they want to access files on devices that have LinuxFS on them. I assume that OS-X has not trouble with mounting various LinuxFS given that it is a *nix breed. JBG 1. http://ext2read.blogspot.com/ 2. http://sourceforge.net/projects/ext2read/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On 11/15/2010 02:15 PM, Matthew Miller wrote: On Mon, Nov 15, 2010 at 08:53:03AM +, Jóhann B. Guðmundsson wrote: That's the essence of what's being discussed here laptop/desktop/workstation installs default to ext4 and experienced users/sysadmins those that generally know what lvm is with all it's bells and whistles and want to use it will choose it during installation. Strongly no to this. We need to have fewer choices during the installation and more flexibility later. LVM provides this. So we agree on disagreeing. Let's go the middle path here what about we default to ext4 but on the partition scene in Anaconda you can choose to partition with LVM and even btrfs for that matter if it is doable that is? ( User still has to select/confirm partitioning adding these option to choose from there should not be a burden to him ) JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On 11/15/2010 10:11 AM, Adam Jackson wrote: On Fri, 2010-11-12 at 09:35 -0700, Kevin Fenzi wrote: * Can we finally remove hal? (xfce4.8 shouldn't need it anymore with any luck). Only 30 packages left requiring it, according to repoquery. smolt's probably the most interesting one to fix, if anyone's looking for a project. For the curious, the 30 packages (in rawhide) are: HAL itself (and its satellite packages): hal-0:0.5.14-6.fc15.x86_64 hal-devel-0:0.5.14-6.fc15.i686 hal-devel-0:0.5.14-6.fc15.x86_64 hal-docs-0:0.5.14-6.fc15.x86_64 hal-info-0:20090716-3.fc12.noarch hal-storage-addon-0:0.5.14-6.fc15.x86_64 Others: beldi-0:0.9.25-2.fc12.x86_64 blueman-0:1.21-6.fc15.x86_64 exaile-0:0.3.2.0-2.fc14.noarch fedora-setup-keyboard-0:0.6-1.fc13.x86_64 gnome-device-manager-libs-0:0.2-6.fc12.i686 gnome-device-manager-libs-0:0.2-6.fc12.x86_64 ifuse-0:1.0.0-1.fc14.x86_64 kdelibs-6:4.5.3-2.fc15.i686 kdelibs-6:4.5.3-2.fc15.x86_64 libconcord-0:0.21-10.fc14.i686 libconcord-0:0.21-10.fc14.x86_64 lxsession-0:0.4.4-1.fc14.x86_64 matahari-0:0.0.5-4.fc15.x86_64 nut-0:2.4.3-8.fc15.x86_64 nut-cgi-0:2.4.3-8.fc15.x86_64 nut-client-0:2.4.3-8.fc15.i686 nut-client-0:2.4.3-8.fc15.x86_64 nut-hal-0:2.4.3-8.fc15.x86_64 ovirt-server-installer-0:0.100-5.fc15.noarch razertool-0:0.0.7-7.fc14.x86_64 smolt-0:1.4.2.2-3.fc15.noarch xfce4-cddrive-plugin-0:0.0.1-3.fc13.x86_64 xfce4-power-manager-0:0.8.5-1.fc15.x86_64 xfce4-volstatus-icon-0:0.1.0-6.fc12.x86_64 I know that at least a few of these are just an upgrade and/or rebuild away. Nathaniel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Fri, Nov 12, 2010 at 09:35:54AM -0700, Kevin Fenzi wrote: * Can we finally remove hal? (xfce4.8 shouldn't need it anymore with any luck). Not without a pile of X changes, which themselves are blocking on upstream kernel changes that I've submitted but which haven't been merged. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: External HD fs was: Re: Fedora 15, new and exciting plans
On 11/15/10 8:39 AM, Jóhann B. Guðmundsson wrote: I assume that OS-X has not trouble with mounting various LinuxFS given that it is a *nix breed. Being unix-ish doesn't really help, you need an actual filesystem driver for the OS. There is an ext2/ext3 driver for osx (based on the bsd driver I think) but that's about as far as it goes. -Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Sun, Nov 14, 2010 at 10:15:20AM +, Richard W.M. Jones wrote: On Sun, Nov 14, 2010 at 01:14:18AM +0100, Lennart Poettering wrote: LVM actually slows down boot considerably. Not primarily because its code was slow or anything, but simply because it isn't really written in the way that things are expected to work these days. Almost - the delays are not any fundamental part of LVM2 itself, but come about from the simplistic way it is called by scripts during startup. Wait a long time for things to settle, then see what storage we can assemble and hope we can see all the bits we need. If instead you defined rules about what to activate and when, you could switch to an event-driven mechanism hooked into udev: When you see the whole of the Volume Group called rootvg, activate it. I once had a discussion about how we would incorporate this into upstart, but it was never a priority and I don't think anything happened about it. The LVM assembly at boot is expected to be run at a time where all disks have been found by the kernel and identified. (Again, that's just a constraint imposed by the current scripts, not anything fundamental to LVM.) The right way how to implement a logic like this is to wait exactly until all disks actually *needed* have shown up and at that time assemble LVM. Absolutely! (On a VG-by-VG basis.) Currently, to make LVM work, we however try to wait until *everything* thinkable is enumerated, not only the disks that are actually needed. A convenience - it makes the scripts simpler - but not a necessity. (And lvm2 can be - and is being slowly - improved to make it easier for such scripts.) I'd really like to hear from an LVM expert or two about this, because I can't believe that it's impossible to make this work better for the common single-disk-is-boot-disk single-PV case. The LVM metadata (which I've written code to read and decode in the past) contains the information needed. It's just about differing priorities not helped by responsibilities being split between developers of different packages. An example of the way I see it working is like this: Say you have a Volume Group VG1 across two PVs, PV1 and PV2, containing Logical Volume LV1 containing the root filesystem. You have a trigger rule saying When you see the whole of VG1, activate LV1 inside it and another saying When you see the filesystem with UUID X, mount it. (Default rules can be generic of course, like 'activate any VG when you see it' and 'activate any LV when you see it' and 'mount any filesystem when you see it'.) Device containing PV1 appears on system. Kernel sends uevent. udev rules ask each storage subsystem in turn Is this yours? - lvm2 subsystem spots the PV signature and claims ownership of it. It caches the LVM metadata from it. - Rule check performed but no rules match. Device containing PV2 appears on system. Kernel sends uevent. udev rules ask each storage subsystem in turn Is this yours? - lvm2 subsystem spots the PV signature and claims ownership of it. It caches the LVM metadata from it. - The rule to activate LV1 when the whole of VG1 is seen is triggered. LV1 is activated. Kernel sends uevent for arrival of the new VG1-LV1 block device on the system. udev rules ask each storage subsystem in turn Is this yours? - lvm2 subsystem finds no signature and answers No. - filesystem subsystem spots the filesystem signature and claims ownership. - The rule to mount the (root) filesystem is triggered. In summary: Each block device on the system has (at most) one owning subsystem recorded in a single database. (perhaps based around libblkid) Storage subsystems may support actions like scan and activate. Udev rules trigger scan. The exact nature of the abstractions used by the triggers would need further exploration. (Storage-subsystem-specific handling - central 'blob' cache, general triggers vs. private caches, private triggers.) Alasdair -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Mon, Nov 15, 2010 at 10:11:52AM -0500, Adam Jackson wrote: * Some kind of packaged wayland to play with, even if it doesn't do much? https://bugzilla.redhat.com/show_bug.cgi?id=652746 Which _really_ won't do much at the moment, since we can't build any of the demo clients yet. I'm still considering what to do about packaging cairo's GL backend, it's not considered ABI stable yet. And yeah, be aware that it's likely to detonate babies for a while yet. If it can at least do a demo, that'd be a pretty good PR win, for whatever that's worth. -- Matthew Miller mat...@mattdm.org Senior Systems Architect -- Instructional Research Computing Services Harvard School of Engineering Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: External HD fs was: Re: Fedora 15, new and exciting plans
On Mon, Nov 15, 2010 at 02:03:03PM +, Frank Murphy wrote: On 15/11/10 13:54, Richard Zidlicky wrote: snip there are very good reasons to use anything but DOS-FAT. For example F10 and F12 automount said filesystems with drastically different options by default (filename downcasing), using any other FS avoids this trap and many other issues. Richard What would you reccomend? That would attched itself nicely to Win =7, and Mac =Leopard out of the box (so to speak) ironically, a few months ago I really needed interoperability with some kind of Windows. So I formatted 2 USB sticks using fdisk and mkdosfs taking special care to make it look as close as possible as the normal USB stick partition table - the other users windows did not read it anyway. So Fedora is definitely evil and perhaps if I had used ext2 the interoperability would have been better - the user would just download the fs driver or one of the userspace windows solutions and it would work. Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On 11/15/2010 05:30 PM, Matthew Miller wrote: On Mon, Nov 15, 2010 at 03:03:28PM +, Jóhann B. Guðmundsson wrote: Strongly no to this. We need to have fewer choices during the installation and more flexibility later. LVM provides this. So we agree on disagreeing. Let's go the middle path here what about we default to ext4 but on the partition scene in Anaconda you can choose to partition with LVM and even btrfs for that matter if it is doable that is? ( User still has to select/confirm partitioning adding these option to choose from there should not be a burden to him ) How is that a middle path? That's doing it exactly wrong. Depends on how you look at it. I mean if users are incapable of actually using the already provided custom partition layout and choose there to use lvm but they are experienced user and would be taking advantage of all the bells and whistle lvm provides there would be an option for them to choose it right in front of them and we still could default to ext4 only install... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans (NoDefaultLVM)
On Mon, 2010-11-15 at 13:02 +0100, Milan Broz wrote: On 11/14/2010 12:41 AM, Richard W.M. Jones wrote: 1. http://fedoraproject.org/wiki/Features/NoDefaultLVM Info on this page is completely obsolete! Yes. Note the prominent line reading: * Last updated: December 17, 2008 The information was current and correct then. It's pretty disappointing that this entire thread happened without anyone bothering to correct the wiki page, or even add comments to the Talk page. Alas. Please use the Talk page to outline requirements, recommendations, reasoning, etc. Rough sketches are OK. Just, jeez, make a little effort. Actually *tell me* what you want/need/think. -w -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
Dne 12.11.2010 17:35, Kevin Fenzi napsal(a): Any other exciting work in progress that might land in F15 that people are actively working on? ABRT with retrace server support, and a retrace server instance up and running. It will improve the quality of backtraces. http://fedoraproject.org/wiki/Features/RetraceServer Design: https://fedorahosted.org/pipermail/crash-catcher/attachments/20101102/f905b572/attachment-0001.xhtml Code: http://git.fedorahosted.org/git/?p=abrt.git;a=shortlog;h=refs/heads/retrace Hopefully I'll cope with ABRT duplicates: backtrace similarity algorithm with a command line Bugzilla processing tool in F15, and a HTTP front-end (service) or Bugzilla plugin for it in F16. Karel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Mon, Nov 15, 2010 at 07:14:53PM +, Jóhann B. Guðmundsson wrote: On 11/15/2010 05:30 PM, Matthew Miller wrote: On Mon, Nov 15, 2010 at 03:03:28PM +, Jóhann B. Guðmundsson wrote: Strongly no to this. We need to have fewer choices during the installation and more flexibility later. LVM provides this. So we agree on disagreeing. Let's go the middle path here what about we default to ext4 but on the partition scene in Anaconda you can choose to partition with LVM and even btrfs for that matter if it is doable that is? ( User still has to select/confirm partitioning adding these option to choose from there should not be a burden to him ) How is that a middle path? That's doing it exactly wrong. Depends on how you look at it. I mean if users are incapable of actually using the already provided custom partition layout and choose there to use lvm but they are experienced user and would be taking advantage of all the bells and whistle lvm provides there would be an option for them to choose it right in front of them and we still could default to ext4 only install... Nobody has yet proven that LVM is a problem, and you just provided some sort of weird case involving USB drives that has nothing to do with the matter at hand. There's no middle path here (yet), just the wrong path. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
Dne 15.11.2010 22:13, Matthew Garrett napsal(a): On Mon, Nov 15, 2010 at 08:43:39PM +0100, Karel Klic wrote: ABRT with retrace server support, and a retrace server instance up and running. It will improve the quality of backtraces. How does the user verify that there are no passwords or other personal information in the core dump? Users only verify the resulting backtrace before sending it to Bugzilla. They need to trust the retrace server administrator when they decide to upload coredumps to the server for retracing (coredumps are kept on the server only during the retracing operation - this should be stated in a privacy policy for the server). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Mon, Nov 15, 2010 at 4:13 PM, Matthew Garrett mj...@srcf.ucam.org wrote: On Mon, Nov 15, 2010 at 08:43:39PM +0100, Karel Klic wrote: Dne 12.11.2010 17:35, Kevin Fenzi napsal(a): Any other exciting work in progress that might land in F15 that people are actively working on? ABRT with retrace server support, and a retrace server instance up and running. It will improve the quality of backtraces. How does the user verify that there are no passwords or other personal information in the core dump? I don't think it really works to ask the user to do that in practice (though I'm not going to go scanning through bugzilla to try to prove the point). It would work out better to: 1) Have crashes be anonymous by default 2) Limited access to crash dump data (for a given package, only allow access by people in the ACLs for those packages?) 3) Still warn the user that it may contain private data, and allow them not to submit (obviously) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Mon, Nov 15, 2010 at 10:01 PM, Colin Walters walt...@verbum.org wrote: On Mon, Nov 15, 2010 at 4:13 PM, Matthew Garrett mj...@srcf.ucam.org wrote: On Mon, Nov 15, 2010 at 08:43:39PM +0100, Karel Klic wrote: Dne 12.11.2010 17:35, Kevin Fenzi napsal(a): Any other exciting work in progress that might land in F15 that people are actively working on? ABRT with retrace server support, and a retrace server instance up and running. It will improve the quality of backtraces. How does the user verify that there are no passwords or other personal information in the core dump? I don't think it really works to ask the user to do that in practice (though I'm not going to go scanning through bugzilla to try to prove the point). It would work out better to: 1) Have crashes be anonymous by default 2) Limited access to crash dump data (for a given package, only allow access by people in the ACLs for those packages?) This would need to also include the QA people. 3) Still warn the user that it may contain private data, and allow them not to submit (obviously) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Mon, Nov 15, 2010 at 05:01:30PM -0500, Colin Walters wrote: On Mon, Nov 15, 2010 at 4:13 PM, Matthew Garrett mj...@srcf.ucam.org wrote: How does the user verify that there are no passwords or other personal information in the core dump? I don't think it really works to ask the user to do that in practice (though I'm not going to go scanning through bugzilla to try to prove the point). It would work out better to: Leaving the retracing at the user's end of things means that the user at least has a choice in the matter - I'm unlikely to submit any firefox crashes if I don't have an opportunity to look at what's in the backtrace. We can make symbols available for local tracing without forcing the user to download the entirity of the debuginfo, and that would seem a more reasonable approach. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
Dne 15.11.2010 22:31, Matthew Garrett napsal(a): On Mon, Nov 15, 2010 at 08:43:39PM +0100, Karel Klic wrote: ABRT with retrace server support, and a retrace server instance up and running. It will improve the quality of backtraces. Further, what's the licensing situation here? If I have an application that (at runtime) is a mixture of GPLed and GPL-incompatible code, does sending this coredump to a remote service count as distribution? Interesting point. I do not know. What is the scope of this question? Can GPLed and GPL-incompatible code end up in the same coredump in Fedora installation without 3rd party software installed? It could happen that a coredump from Firefox contains non-free javascript from pages that were viewed around the time of the crash, but that is a browser-specific issue. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
Matthew Garrett píše v Po 15. 11. 2010 v 22:04 +: On Mon, Nov 15, 2010 at 05:01:30PM -0500, Colin Walters wrote: On Mon, Nov 15, 2010 at 4:13 PM, Matthew Garrett mj...@srcf.ucam.org wrote: How does the user verify that there are no passwords or other personal information in the core dump? I don't think it really works to ask the user to do that in practice (though I'm not going to go scanning through bugzilla to try to prove the point). It would work out better to: Leaving the retracing at the user's end of things means that the user at least has a choice in the matter - I'm unlikely to submit any firefox crashes if I don't have an opportunity to look at what's in the backtrace. We can make symbols available for local tracing without forcing the user to download the entirity of the debuginfo, and that would seem a more reasonable approach. Don't we need the entirety of debuginfo in order to be able to include parameter and local variable values in the backtrace? Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Mon, Nov 15, 2010 at 11:07:11PM +0100, Miloslav Trmač wrote: Don't we need the entirety of debuginfo in order to be able to include parameter and local variable values in the backtrace? The entirity of it needs to be available, but that's not the same as requiring the user install it on local storage. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Mon, Nov 15, 2010 at 11:28:33PM +0100, Karel Klic wrote: Dne 15.11.2010 22:31, Matthew Garrett napsal(a): Further, what's the licensing situation here? If I have an application that (at runtime) is a mixture of GPLed and GPL-incompatible code, does sending this coredump to a remote service count as distribution? Interesting point. I do not know. What is the scope of this question? Can GPLed and GPL-incompatible code end up in the same coredump in Fedora installation without 3rd party software installed? It was reasonably likely in X until Synaptics got relicensed. I think we're fairly safe from a stock install point of view. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
Dne 15.11.2010 23:04, Matthew Garrett napsal(a): On Mon, Nov 15, 2010 at 05:01:30PM -0500, Colin Walters wrote: On Mon, Nov 15, 2010 at 4:13 PM, Matthew Garrettmj...@srcf.ucam.org wrote: Leaving the retracing at the user's end of things means that the user at least has a choice in the matter - I'm unlikely to submit any firefox crashes if I don't have an opportunity to look at what's in the backtrace. We can make symbols available for local tracing without forcing the user to download the entirity of the debuginfo, and that would seem a more reasonable approach. http://fedoraproject.org/wiki/Features/DebuginfoFS Agreed, debuginfofs will be better for many scenarios. Major advantage of the retrace server is that you can get a good backtraces even from unfresh coredumps. GDB needs access to the binary and dynamic libraries that were installed at the time of the crash when generating a backtrace. So if there was an update yesterday that installed new versions of several packages, it can happen that the backtrace can no longer be obtained from the coredump locally (without installing the old packages somewhere else). Retrace server installs packages that were used at the time of the crash, so the backtrace can be obtained. Major disadvantages of RS are that coredump upload takes time, 3rd party packages can't be easily supported, and users must trust the administrator. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On 11/15/2010 09:27 PM, Richard W.M. Jones wrote: Nobody has yet proven that LVM is a problem Well if you don't consider what Lennart mentioned [1] as a con against usage of lvm by default what pros do you see for having lvm by default for the novice end user? JBG 1. http://lists.fedoraproject.org/pipermail/devel/2010-November/145472.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Mon, Nov 15, 2010 at 11:15:38PM +, Jóhann B. Guðmundsson wrote: Well if you don't consider what Lennart mentioned [1] as a con against usage of lvm by default what pros do you see for having lvm by default for the novice end user? When the novice end user realizes that they made some poor storage decisions initially, they can, with a little learning, fix it without much hassle. I have a system which, for silly reasons, I did not use LVM, and then ended up having change a separately-mounted /usr, and now (in a sort of irony, considering this thread) can't shut down cleanly under systemd. Awesome. I'm not particularly attached to LVM as a specific technology, but we need something with equivalent functionality before we ditch it. -- Matthew Miller mat...@mattdm.org Senior Systems Architect -- Instructional Research Computing Services Harvard School of Engineering Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Mon, Nov 15, 2010 at 10:23:37AM -0500, Nathaniel McCallum wrote: On 11/15/2010 10:11 AM, Adam Jackson wrote: On Fri, 2010-11-12 at 09:35 -0700, Kevin Fenzi wrote: * Can we finally remove hal? (xfce4.8 shouldn't need it anymore with any luck). Only 30 packages left requiring it, according to repoquery. smolt's probably the most interesting one to fix, if anyone's looking for a project. For the curious, the 30 packages (in rawhide) are: HAL itself (and its satellite packages): hal-0:0.5.14-6.fc15.x86_64 hal-devel-0:0.5.14-6.fc15.i686 hal-devel-0:0.5.14-6.fc15.x86_64 hal-docs-0:0.5.14-6.fc15.x86_64 hal-info-0:20090716-3.fc12.noarch hal-storage-addon-0:0.5.14-6.fc15.x86_64 Others: beldi-0:0.9.25-2.fc12.x86_64 blueman-0:1.21-6.fc15.x86_64 exaile-0:0.3.2.0-2.fc14.noarch fedora-setup-keyboard-0:0.6-1.fc13.x86_64 whoops, this package was renamed by system-setup-keyboard, which now uses xorg.conf.d snippets instead of hal. package is about to be retired any minute now. Cheers, Peter gnome-device-manager-libs-0:0.2-6.fc12.i686 gnome-device-manager-libs-0:0.2-6.fc12.x86_64 ifuse-0:1.0.0-1.fc14.x86_64 kdelibs-6:4.5.3-2.fc15.i686 kdelibs-6:4.5.3-2.fc15.x86_64 libconcord-0:0.21-10.fc14.i686 libconcord-0:0.21-10.fc14.x86_64 lxsession-0:0.4.4-1.fc14.x86_64 matahari-0:0.0.5-4.fc15.x86_64 nut-0:2.4.3-8.fc15.x86_64 nut-cgi-0:2.4.3-8.fc15.x86_64 nut-client-0:2.4.3-8.fc15.i686 nut-client-0:2.4.3-8.fc15.x86_64 nut-hal-0:2.4.3-8.fc15.x86_64 ovirt-server-installer-0:0.100-5.fc15.noarch razertool-0:0.0.7-7.fc14.x86_64 smolt-0:1.4.2.2-3.fc15.noarch xfce4-cddrive-plugin-0:0.0.1-3.fc13.x86_64 xfce4-power-manager-0:0.8.5-1.fc15.x86_64 xfce4-volstatus-icon-0:0.1.0-6.fc12.x86_64 I know that at least a few of these are just an upgrade and/or rebuild away. Nathaniel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Mon, Nov 15, 2010 at 06:26:27PM -0500, Matthew Miller wrote: On Mon, Nov 15, 2010 at 11:15:38PM +, Jóhann B. Guðmundsson wrote: Well if you don't consider what Lennart mentioned [1] as a con against usage of lvm by default what pros do you see for having lvm by default for the novice end user? When the novice end user realizes that they made some poor storage decisions initially, they can, with a little learning, fix it without much hassle. I have a system which, for silly reasons, I did not use LVM, and then ended up having change a separately-mounted /usr, and now (in a sort of irony, considering this thread) can't shut down cleanly under systemd. Awesome. I'm not particularly attached to LVM as a specific technology, but we need something with equivalent functionality before we ditch it. It also takes a decision out of the mix when a user buys a new drive. They can just dump it in the volume group rather than having to learn how to place it at a mountpoint and migrate data (the actual commands are no big deal. Learning to weigh the costs and benefits of applying your new 1TB disk to /usr vs /home isn't). Its a usecase that matters to an interesting class of user: the petty power user. They help Aunt Tillie with her computer. They built their own computer. They think of themselves as quite tech-savvy. They are also liable to say things like If linux is so great why can't it even run normal programs? LVM is nice in that it accomodates this generally unpleasent sort of person (who is much improved by education and has the potential to become a great contributor once humbled and made willing to learn) though it does this by offering a temporary crutch. --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Mon, Nov 15, 2010 at 10:49:24PM +, Matthew Garrett wrote: On Mon, Nov 15, 2010 at 11:28:33PM +0100, Karel Klic wrote: Dne 15.11.2010 22:31, Matthew Garrett napsal(a): Further, what's the licensing situation here? If I have an application that (at runtime) is a mixture of GPLed and GPL-incompatible code, does sending this coredump to a remote service count as distribution? Interesting point. I do not know. What is the scope of this question? Can GPLed and GPL-incompatible code end up in the same coredump in Fedora installation without 3rd party software installed? It was reasonably likely in X until Synaptics got relicensed. I think we're fairly safe from a stock install point of view. We should probably detect when things we don't ship are linked in and put some measures in place to keep the user from inadvertently breaking copyright law (or worse, putting copyrighted material on our BZ so /we/ end up inadvertently breaking copyright law). --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Sun, Nov 14, 2010 at 01:14:18AM +0100, Lennart Poettering wrote: LVM actually slows down boot considerably. Not primarily because its code was slow or anything, but simply because it isn't really written in the way that things are expected to work these days. The LVM assembly at boot is expected to be run at a time where all disks have been found by the kernel and identified. However, the idea that such a time exists is out-of-date on modern systems. There is simply no point in time where all disks have been enumerated, because they can always come and go and on many busses (for example USB), you never know whether you have enumerated all devices, because the bus doesn't support a notion like that. The right way how to implement a logic like this is to wait exactly until all disks actually *needed* have shown up and at that time assemble LVM. Currently, to make LVM work, we however try to wait until *everything* thinkable is enumerated, not only the disks that are actually needed. The fact that on many busses this point in time doesn't really exist is ignored, and awful hacks such as modprobe scsi_wait_scan are used to work around this out-of-date design on the other busses. To get to a fast system however, you should minimize the time you waste and continue withthe next step of booting the moment you have collected all devices you need for assembly. Thanks for explaining what the assembly issue is all about. I'd really like to hear from an LVM expert or two about this, because I can't believe that it's impossible to make this work better for the common single-disk-is-boot-disk single-PV case. The LVM metadata (which I've written code to read and decode in the past) contains the information needed. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans (biosdevname)
On Sat, Nov 13, 2010 at 08:34:54PM -0600, Matt Domsch wrote: On Fri, Nov 12, 2010 at 09:35:54AM -0700, Kevin Fenzi wrote: Greetings. Fedora 14 was a pretty relaxing and stable release. I'm thinking that Fedora 15 may be much more exciting. ;) biosdevname installed by default, used in the installer and at runtime to rename Dell and HP server onboard NICs from non-deterministic ethX to clearly labeled lomX matching the chassis silkscreen. But why “lomX” for all? Isn't Lights-Out-Management available only on first ethernet port and often on dedicated port? -- Tomasz Torcz Never underestimate the bandwidth of a station xmpp: zdzich...@chrome.plwagon filled with backup tapes. -- Jim Gray -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
Le dimanche 14 novembre 2010 à 01:14 +0100, Lennart Poettering a écrit : Well, there's no doubt that LVM has its uses, but that doesn't mean we should install it by default on every Fedora installation. LVM actually slows down boot considerably. Not primarily because its code was slow or anything, but simply because it isn't really written in the way that things are expected to work these days. But wasnt systemd supposed to fix this kind of problem (dumping things overboard is not fixing) ? LVM may not be very useful on single-hdd laptops, but on desktops it makes adding/changing disks really easy. -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
Return to GRUB2 topic, I wish that GRUB2 landed in Anaconda and become an option for user. Some Linux fans install two Linux distros, one is rpm-based distro, another is deb-based distro. Most of deb-based distros has moved to GRUB2. however, rpm-based distros still stays at GRUB legacy. I can feel there are some problems on compatibility. Does anyone know something about GRUB2 on mapper devices? Half a year ago, I tried to install Debian on my Intel RAID0 but failed. At that time, Debian installer does not support that users directly install GRUB2. You need extra steps to do it manually. I think the maintainers should consider it and find out the best solution for users. The other topic is about Xen. As we know, Xen Dom0 pv_ops are merged into the upstream kernel since 2.6.37. Fedora 15 will use kernel-2.6.38. Should community bring Xen Dom0 to Fedora 15 since Fedora 8 though Red Hat does no longer support Xen? Because Xen Dom0 pv_ops is a part of upstream kernel, Debian has a plan to drop specified kernel for Xen and directly support it in generic kernel. Does Fedora has some plans to do it? I know Xen is still maintained by myong in Fedora. On Sun, Nov 14, 2010 at 10:23 AM, Dennis Jacobfeuerborn denni...@conversis.de wrote: On 11/14/2010 12:41 AM, Richard W.M. Jones wrote: On Fri, Nov 12, 2010 at 06:26:48PM +, Jóhann B. Guðmundsson wrote: *DE could consider switching the default to use EXT4 directly without LVM. [1] 1. http://fedoraproject.org/wiki/Features/NoDefaultLVM The Detailed Description seems contradictory: | LVM provides very little benefit for most Fedora users, at the cost of | performance and complexity: | | * Certain filesystem features (ext3 barriers) are unavailable when run | on top of LVM. Isn't this just a bug which should be fixed? (I actually thought this had been fixed already) | * Software RAID performance is greatly reduced when layered on LVM. But the stated task is to get rid of LVM except for experts in storage administration (from the next section of the same document). Who will presumably be the only ones wanting Software RAID. The non-experts won't know anything about Software RAID, so they won't be affected by this performance problem with LVM. Can someone point to specific details about this? I did some benchmarking a while ago of raid-1 vs. raid-5, raid-1 plain vs. raid-1 with lvm, etc. and LVM didn't really show up as a performance issue at all. | * LVM partitions are not automatically assembled by the desktop systems. I'm not sure what this one means. assembled as in what happens when you spread a VG over multiple block devices? Anyway, I think LVM is jolly useful: I've used plain partitions for a long time because lvm always looked weird to me but then I looked into it and nowadays I don't want to live without it. The ability to have the logical partitioning indepedent of the physical storage is a must-have for me. - You can expand the root filesystem (eg. into spare space or across block devices). - You can live pvmove filesystems from one device to another. That one actually saved my ass once on a 48 disk 30TB storage system because the controller was acting up. It may be that the tooling is not there to make these features available for non-experts, but that's a problem with lack of tools, not with LVM. Partition tables are horrible and inflexible in comparison to LVM. Can we at the very least have some numbers backing up the supposed performance problems? Yeah, in my benchmarking I couldn't really confirm this so if there is a problem I'd like to see some specifics too. Regards, Dennis -- devel mailing list devel@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On 14/11/10 12:18, Liang Suilong wrote: Return to GRUB2 topic, I wish that GRUB2 landed in Anaconda and become an option for user. Some Linux fans install two Linux distros, one is rpm-based distro, another is deb-based distro. Most of deb-based distros has moved to GRUB2. however, rpm-based distros still stays at GRUB legacy. I can feel there are some problems on compatibility. Have been testing on bare and vm's, have been haing trouble with it. with grub1 you edit /boot/grub/menu.lst to get some tweaks set permanently, or enter on the fly during bootup. with grub2, tested both chainloaded with grub1, and with yum erase grub. Though it found updated kernels', it never booted them unless grub2-mkconfig -o /boot/grub2/grub.cfg was run manually. It also requires edits in a number of files, to get permanent tweaks instead of one simple file. -- Regards, Frank Murphy UTF_8 Encoded Friend of Fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans (biosdevname)
On Sat, Nov 13, 2010 at 10:11:11PM -0800, John Reiser wrote:
On 11/13/2010 06:34 PM, Matt Domsch wrote:
biosdevname installed by default, used in the installer and at runtime
to rename Dell and HP server onboard NICs from non-deterministic
ethX to clearly labeled lomX matching the chassis silkscreen.
http://marc.info/?l=linux-hotplugm=128892593821639w=2
In that message I see:
** No rename for all others ethX (no change for NICs in PCI
slots/USB/others)
I'd like an option to assign ethX to NICs in /sys/devices/pci* order.
This matches chassis PCI slot order on many, many motherboards.
I get confused when ethX is assigned in a different order.
You can bind ethX to a specific card [not slot] by using HWADDR= in
/etc/sysconfig/network-scripts/ifcfg-ethX. That's fine, but I prefer
an option to assign ethX by PCI slot, because that's what I can see when
I plug in the cables. My NICs are various brands and models,
but I treat them all as generic because that is much simpler,
especially in the beginning.
For you, biosdevname has alternate naming policies. You'll edit
/etc/udev/rules.d/71-netdevice.rules, changing --policy=loms to
--policy={something else}, with various choices available:
[loms|kernelnames|all_ethN|all_names|embedded_ethN_slots_names|smbios_names]
all_ethN does exactly what you want, embedded devices first, then all
other devices in ascending PCI slot order.
Thanks,
Matt
--
Matt Domsch
Technology Strategist
Dell | Office of the CTO
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans (biosdevname)
On Sun, Nov 14, 2010 at 11:57:59AM +0100, Tomasz Torcz wrote: On Sat, Nov 13, 2010 at 08:34:54PM -0600, Matt Domsch wrote: On Fri, Nov 12, 2010 at 09:35:54AM -0700, Kevin Fenzi wrote: Greetings. Fedora 14 was a pretty relaxing and stable release. I'm thinking that Fedora 15 may be much more exciting. ;) biosdevname installed by default, used in the installer and at runtime to rename Dell and HP server onboard NICs from non-deterministic ethX to clearly labeled lomX matching the chassis silkscreen. But why ???lomX??? for all? Isn't Lights-Out-Management available only on first ethernet port and often on dedicated port? This has nothing to do with Lights-Out-Management. LOM also == LAN on Motherboard. -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Sun, 14.11.10 13:14, Nicolas Mailhot (nicolas.mail...@laposte.net) wrote: Le dimanche 14 novembre 2010 à 01:14 +0100, Lennart Poettering a écrit : Well, there's no doubt that LVM has its uses, but that doesn't mean we should install it by default on every Fedora installation. LVM actually slows down boot considerably. Not primarily because its code was slow or anything, but simply because it isn't really written in the way that things are expected to work these days. But wasnt systemd supposed to fix this kind of problem (dumping things overboard is not fixing) ? LVM may not be very useful on single-hdd laptops, but on desktops it makes adding/changing disks really easy. systemd is definitely not going into the realms of storage assembly. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Sun, Nov 14, 2010 at 12:41 AM, Richard W.M. Jones rjo...@redhat.com wrote: On Fri, Nov 12, 2010 at 06:26:48PM +, Jóhann B. Guðmundsson wrote: *DE could consider switching the default to use EXT4 directly without LVM. [1] 1. http://fedoraproject.org/wiki/Features/NoDefaultLVM The Detailed Description seems contradictory: | LVM provides very little benefit for most Fedora users, at the cost of | performance and complexity: | | * Certain filesystem features (ext3 barriers) are unavailable when run | on top of LVM. Isn't this just a bug which should be fixed? (I actually thought this had been fixed already) | * Software RAID performance is greatly reduced when layered on LVM. But the stated task is to get rid of LVM except for experts in storage administration (from the next section of the same document). Who will presumably be the only ones wanting Software RAID. The non-experts won't know anything about Software RAID, so they won't be affected by this performance problem with LVM. | * LVM partitions are not automatically assembled by the desktop systems. I'm not sure what this one means. assembled as in what happens when you spread a VG over multiple block devices? Anyway, I think LVM is jolly useful: - You can expand the root filesystem (eg. into spare space or across block devices). - You can live pvmove filesystems from one device to another. It may be that the tooling is not there to make these features available for non-experts, but that's a problem with lack of tools, not with LVM. Partition tables are horrible and inflexible in comparison to LVM. Can we at the very least have some numbers backing up the supposed performance problems? Something else to add to the list: Does not support discard (aka TRIM) when using SSDs which hurts performance and lifetime of said drives. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On 11/14/2010 10:42 AM, drago01 wrote: Yes unless something changed recently the filesystem's discard command never reaches the drive. Looks like I'm reformatting and dumping the LVM. Thanks. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Sat, 2010-11-13 at 11:15 -0500, Genes MailLists wrote: On 11/13/2010 10:45 AM, Owen Taylor wrote: On Fri, 2010-11-12 at 18:07 -0500, Sam Varshavchik wrote: Kevin Fenzi writes: * gnome3 / gnome-shell default Does anyone happen to know how to mimic the equivalent of panel applets esp those which are not a part of fedora e.g. I use mathematica all the time and in gnome 2.x I put an icon on the panel. The only way I could see so far from looking at the gnome-3 website is to ALT-F2 to start an application - then right click to add the app to 'favorites' ... Anything installing an application on the system (whether it's part of Fedora or not) really should be installing a desktop file. If there's no desktop file, there's no way for the user to launch the application. In GNOME 3, no desktop file also means that it won't behave properly as an application it won't get the right name and icon in the top panel, etc. Once there is a desktop file, then, yes you would add it to favorites. Favorite are very close in function to a launcher on the panel - you can get to them with a single mouse-click using the hot corner activation of the Activities Overview. (If Mathematica has a desktop file and it's just not being picked up by GNOME 3, then creating a symlink into ~/.local/share/applications will work.) Is there going to be a GUI to create a desktop file for a something that doesn't have a desktop file? (Something like the Add custom launcher dialog for gnome-panel currently.) It's not in our plans currently, and I'm not really sure where it would neatly fit into the user interface. One possibility is the one you mentioned - if someone starts an application that we don't recognize and tries to make it a favorite, we prompt them for the missing information and create a desktop file in ~/.local/share/applications. But really, it's something that ISVs have to get right and anything else is a workaround. - Owen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
Hi. On Sun, 14 Nov 2010 10:44:06 -0600, Michael Cronenworth wrote Looks like I'm reformatting and dumping the LVM. Thanks. Discard aside, btrfs should include all (or most of) the features that LVM and raid0 were giving you, anyway. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans - BTRFS
btfrs providing raid0 functionality. Does BTRFS have the equivalent of raid 5 ? gene/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On 11/13/2010 03:41 PM, Richard W.M. Jones wrote: Anyway, I think LVM is jolly useful: [stated advantages snipped] One design error is that you cannot carve out an ordinary partition from an LVM. Once a portion of the drive is LVM, then that portion of the drive is LVM forever until the LVM is completely gone. This makes LVM a bad neighbor in a consulting environment where flexibility is king: multiple systems per drive, and many of the systems do not understand LVM. -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Sun, 2010-11-14 at 14:07 -0500, Matt McCutchen wrote: On Sun, 2010-11-14 at 10:38 -0800, John Reiser wrote: On 11/13/2010 03:41 PM, Richard W.M. Jones wrote: Anyway, I think LVM is jolly useful: [stated advantages snipped] One design error is that you cannot carve out an ordinary partition from an LVM. Once a portion of the drive is LVM, then that portion of the drive is LVM forever until the LVM is completely gone. That's not true. You can shrink the PV with pvresize and then create any desired partitions in the resulting space. Oops, that's not completely true: pvresize currently is not smart enough to move allocated data out of the area to be freed, according to its man page. But you have other options, e.g., you can attach another disk, create a PV on it, move the data there, rearrange the first disk as desired, and move the data back, all while the system is running. That's what's so fun about LVM. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
Matt McCutchen wrote: On Sun, 2010-11-14 at 14:07 -0500, Matt McCutchen wrote: Oops, that's not completely true: pvresize currently is not smart enough to move allocated data out of the area to be freed, according to its man page. But you have other options, e.g., you can attach another disk, create a PV on it, move the data there, rearrange the first disk as desired, and move the data back, all while the system is running. That's what's so fun about LVM. Even if pvresize doesn't move allocated data, you can do that with pvmove, and you do not need to move everything out of the PV, just the part you are going to truncate (PEs can be specified). I don't remember if pvmove can use the same PV as src and dest; in that case you could avoid the need of an extra disk when your PV is just fragmented. -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On 11/14/2010 05:44 PM, Michael Cronenworth wrote: On 11/14/2010 10:42 AM, drago01 wrote: Yes unless something changed recently the filesystem's discard command never reaches the drive. Looks like I'm reformatting and dumping the LVM. Thanks. You should also file a bug against the tool that told you that discard support is available. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
