[Bug 581706] MLDonkey is outdated and need update
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=581706 Peter Lemenkov lemen...@gmail.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Resolution||NEXTRELEASE --- Comment #2 from Peter Lemenkov lemen...@gmail.com 2010-04-20 09:16:49 EDT --- New mldonkey package is submitted to F-11, F-12 and F-13 stable. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ ocaml-devel mailing list ocaml-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ocaml-devel
Re: Shell commands like to OS/2 shell (or MS PowerShell)
On 19/04/10 23:51, Slava Zanko wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi folk, I want to propose new idea about names of command line utilites... For example, all present utilites have sence just for guru's (ls, rm, fsck etc), but for novies it's hard to use. Bookmark this: http://ss64.com/bash/ Less typing, less for novices to forget. -- Regards, Frank Murphy UTF_8 Encoded, Fedora.x86 64-32 Hybrid -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Shell commands like to OS/2 shell (or MS PowerShell)
On Tue, Apr 20, 2010 at 12:51 AM, Slava Zanko slavaza...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi folk, I want to propose new idea about names of command line utilites... For example, all present utilites have sence just for guru's (ls, rm, fsck etc), but for novies it's hard to use. Is good idea to symlink'ing (shell aliasing) these and much more utilz to another names? Like to: ls - filesystem.list rm - filesystem.remove fsck.* - filesystem.check.* mkfs.* - filesystem.make.* convert - media.convert.image mencoder - media.convert.video oggenc - media.convert.audio.ogg mplayer - media.player.* etc Sounds like a waste of time ... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Shell commands like to OS/2 shell (or MS PowerShell)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Frank Murphy wrote: Bookmark this: http://ss64.com/bash/ I know about :) This idea just try for standartization of command names... I know about posix and LSB, but these standards don't make logic in the names of commands. Okay, as I see, this idea don't have interest for most... To All: in any case, thanks for attention. - -- WBR, Slavaz. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFLzVDzb3oGR6aVLpoRAuIcAJ4qqkjvdiJrI/HugEK9igYKMrdFFACePVrB XpjNndoiHl0fgk44C/SGIK8= =tyjV -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Query about usb_modeswitch and how to handle its packaging
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi All, I maintain usb-modeswitch in fedora. Recently upstream divided the main tar ball into two parts, the code which builds into the usb_modeswitch binary and the data part which contains the udev rules. Initially there was just one tar ball with both, and my spec builds two rpms out of that namely usb_modeswitch and usb_modeswitch-data. Now upstream says that his intention of making two tar balls was to enable updating the data part more frequently then the code, which makes sense. Now i have two options: 1. Have just one srpm, which builds from the two tar balls, if that is done, the upstream purpose of updating the data more frequently is lost. Also upstream says usb_modeswitch has to depend on usb_modeswitch-data and vice versa. 2. Have two srpms one for data and one for binary, with both depending on each other. Which one do you think is the best option. Thanks in advance. - -- Regards, Huzaifa Sidhpurwala, RHCE, CCNA (IRC: huzaifas) GnuPG Fingerprint: 3A0F DAFB 9279 02ED 273B FFE9 CC70 DCF2 DA5B DAE5 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org/ iD8DBQFLzV31zHDc8tpb2uURAjVxAJ40ie5HVcrADk5qaSmsS6687dhWUwCgjdHO mdulXkdmkcHt/l4emO+L0JY= =y/O9 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Query about usb_modeswitch and how to handle its packaging
Am 20.04.2010 09:55, schrieb Huzaifa Sidhpurwala: 2. Have two srpms one for data and one for binary, with both depending on each other. This is the way to go. It also makes it easier for you to maintain it in the future. However, you must create a new review request for the data package then. Felix -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Query about usb_modeswitch and how to handle its packaging
On Tue, Apr 20, 2010 at 8:55 AM, Huzaifa Sidhpurwala huzai...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi All, I maintain usb-modeswitch in fedora. Recently upstream divided the main tar ball into two parts, the code which builds into the usb_modeswitch binary and the data part which contains the udev rules. Initially there was just one tar ball with both, and my spec builds two rpms out of that namely usb_modeswitch and usb_modeswitch-data. Now upstream says that his intention of making two tar balls was to enable updating the data part more frequently then the code, which makes sense. Now i have two options: 1. Have just one srpm, which builds from the two tar balls, if that is done, the upstream purpose of updating the data more frequently is lost. Also upstream says usb_modeswitch has to depend on usb_modeswitch-data and vice versa. 2. Have two srpms one for data and one for binary, with both depending on each other. Which one do you think is the best option. Thanks in advance. 2 is definitely the best option as it allows to push updates to the data package without the binary component. You might want to look at how hal and hal-info does the deps cross check. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Configuration infrastructure (system configs replacement, maintainers please read)
Hi! We've been working for some time on improving current system configuration tools (system-config-* cleanup), some of these tools are going to be removed completely as there's no need for them now (autoconfiguration, obsoleted), some are really very outdated and unmaintained for some time. And of course - we have PolicyKit 1 now. What does this mean? Now we have nice opportunity to split user interface from actual backendn (and usually has to be runned under root account). And it would be nice to have some common interface sitting on DBus - it's where we aim with fmci - Fedora Management and Configuration Infrastructure (infrastructure as we already have a lot of services on DBus - so we'd like also to document these. It's more than just some interface). So the plan: first we want to collect input from user/devs - we don't want to do project for project because we like projects but useful one... We don't want to replace or change the current way - configuration files. Just high level access, not covering all functionality, to core system to be used by new GUIs, scripts etc. Next is to document the current state - for examples for network configuration there's NetworkManager, desktop team is working on user management tool and there are more projects, usually not connected etc. This is what has to be done first. Summary: * high level interface? * documentation of existing interfaces on one place * UI/backend splits (current s-c-* tools maintainers input needed) * coding the most important interfaces for F-14 So if you are interested in this project - suggestions, ideas, you'd like to participate in other ways (coding, etc...) - you're welcome on fmci-devel list! Reply here, ping me, kill me - (nearly) everything allowed! This projects needs interaction from more teams - base os, destkop, design etc... Thanks Jaroslav -- Jaroslav Řezník jrez...@redhat.com Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 602 797 774 Red Hat, Inc. http://cz.redhat.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Shell commands like to OS/2 shell (or MS PowerShell)
20.04.2010 03:29, Ryan Rix пишет: On Mon 19 April 2010 3:51:23 pm Slava Zanko wrote: Hi folk, I want to propose new idea about names of command line utilites... For example, all present utilites have sence just for guru's (ls, rm, fsck etc), but for novies it's hard to use. Is good idea to symlink'ing (shell aliasing) these and much more utilz to another names? Like to: ls - filesystem.list rm - filesystem.remove fsck.* - filesystem.check.* mkfs.* - filesystem.make.* convert - media.convert.image mencoder - media.convert.video oggenc - media.convert.audio.ogg mplayer - media.player.* etc This idea will be easy to realize (need to make at first time one rpm package with lot of symlinks... and then long-time work in all present rpm-packages for respect this technology). But we need for standartization of alias names... in ideal case, standartization must touch all distros (new standard?) P.S. This not my idea. Originally from: http://translate.google.com/translate?js=yprev=_thl=enie=UTF-8layout=2; eotf=1u=http%3A%2F%2Fwww.linux.org.ru%2Fforum%2Ftalks%2F4797323sl=rutl=e n Thanks for attention. I'm against making a mess of PATH with a crapload of symlinks. If this were to happen, it should happen at a bashrc alias level, and even then I'm still against it. I also against making it global by default. But this can be done in separate folder, not to standard /usr/bin, and then added for users who want it just add it into PATH. I not sure what I want it, but sometimes really hard understand by name what do command and from which area it is. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Shell commands like to OS/2 shell (or MS PowerShell)
On Tue, Apr 20, 2010 at 2:55 PM, Pavel Alexeev (aka Pahan-Hubbitus) fo...@hubbitus.com.ru wrote: 20.04.2010 03:29, Ryan Rix пишет: On Mon 19 April 2010 3:51:23 pm Slava Zanko wrote: Hi folk, I want to propose new idea about names of command line utilites... For example, all present utilites have sence just for guru's (ls, rm, fsck etc), but for novies it's hard to use. Is good idea to symlink'ing (shell aliasing) these and much more utilz to another names? Like to: ls - filesystem.list rm - filesystem.remove fsck.* - filesystem.check.* mkfs.* - filesystem.make.* convert - media.convert.image mencoder - media.convert.video oggenc - media.convert.audio.ogg mplayer - media.player.* etc This idea will be easy to realize (need to make at first time one rpm package with lot of symlinks... and then long-time work in all present rpm-packages for respect this technology). But we need for standartization of alias names... in ideal case, standartization must touch all distros (new standard?) P.S. This not my idea. Originally from: http://translate.google.com/translate?js=yprev=_thl=enie=UTF-8layout=2; eotf=1u=http%3A%2F%2Fwww.linux.org.ru%2Fforum%2Ftalks%2F4797323sl=rutl=e n Thanks for attention. I'm against making a mess of PATH with a crapload of symlinks. If this were to happen, it should happen at a bashrc alias level, and even then I'm still against it. I also against making it global by default. But this can be done in separate folder, not to standard /usr/bin, and then added for users who want it just add it into PATH. I not sure what I want it, but sometimes really hard understand by name what do command and from which area it is. That is what man command is for ... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Shell commands like to OS/2 shell (or MS PowerShell)
On Tue, Apr 20, 2010 at 1:39 AM, Athmane Madjoudj athma...@gmail.com wrote: I'm against making a mess of PATH with a crapload of symlinks. If this were to happen, it should happen at a bashrc alias level, and even then I'm still against it. i agree, also the proposed commands are too long to be typed in the terminal. they look like name-spaces in a programming language Agreed. Plus a command like: filesystem.remove would confuse and scare novices. Ugh, that removes my filesystem -- LG Thomas Dubium sapientiae initium -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Shell commands like to OS/2 shell (or MS PowerShell)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 drago01 wrote: I also against making it global by default. But this can be done in separate folder, not to standard /usr/bin, and then added for users who want it just add it into PATH. Yep, of course. This idea unobtrusive and don't hard for realization, but much harder for standartization between people (and distros) :) I not sure what I want it, but sometimes really hard understand by name what do command and from which area it is. That is what man command is for ... Sometime I know what I want, but I don't know is standart utility present for this. For example, I need for grep'ing some user from users list on my host. How do it with 'man' utility? How I should guess about 'getent passwd'? and what records more readable: test $(getent passwd| grep -c '^someuser:') -eq 0 useradd someuser or test $(system.user.list| grep -c '^someuser:') -eq 0 system.user.add someuser getent group | grep '^somegroup:' or system.group.list | grep '^someuser:' For guru's of course much readable first variant :) Or in additional we may have aliases for: editor.txt = your preferred editor editor.txt.sed = /usr/bin/sed editor.txt.vim = /usr/bin/vim editor.txt.joe = ... editor.txt.gedit editor.txt.kwrite editor.img.gimp editor.sound.guitar-newbie etc what happens after edittab? You'll see 'editor'. Type 't' and press tab. Press enter key for start preferred editor or just press tab key again and you'll see editors (and only editors). Of course, some utilities may present in few categories... And of course, my names of programs just for example. - -- WBR, Slavaz. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFLzat7b3oGR6aVLpoRAvtbAJ0dMLqtmIk0RujlCRYirDldui5s8wCggl5m +FxH9JZo7L03ByFaEkWknGc= =+Bfp -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
C++ help needed
Sadly, I am facing a task which exceeds my very meager C++ skills. I own a package called esperanza, which is a QT4 xmms2 client written in C++. With the latest xmms2 update (0.7DrNo, not yet built or pushed to any branch, but checked into rawhide CVS), the esperanza client no longer works (it builds, but never launches). Please note that xmms2 clients use a script launcher to ensure that xmms2 is running, see the esperanza.desktop file. I've updated the esperanza code to the latest set of git fixes in rawhide CVS (necessary to build), but I really could use the help of someone with C++ skills to get it working again. I emailed upstream, but never got a response. The other xmms2 clients are held up on this, and I'd rather not simply dead.package this unless I absolutely have to. I would be happy to return the favor with work that is in my skillset, licensing, packaging, reviewing, triage, etc, etc. Thanks in advance, ~spot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FWD: orphaning curlftpfs , mod_auth_shadow
I'm forwarding this for David Anderson: From: David Anderson fedora-packag...@dw-perspective.org.uk To: fedora-devel-l...@redhat.com Subject: Orphaning curlftpfs , mod_auth_shadow Date: Mon, 11 Jan 2010 11:22:25 + User-Agent: KMail/1.12.4 (Linux/2.6.31.6-166.fc12.x86_64; KDE/4.3.4; x86_64; ;) Greetings, Due to a slow African Internet connection and ever-growing responsibilities, I regret that I have to and am orphanning these two packages: curlftpfs - mount FTP filesystems via FUSE and curl mod_auth_shadow - Apache authentication via /etc/shadow mod_auth_shadow - going to take this as I'm using it. Jan Klepek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
gnome-icon-theme in rawhide
Hey, I am working with the artists to clean up our gnome-icon-theme package. As part of that effort, I have split off a -legacy subpackage that contains all the legacy symlinks, leaving only standard icon names and symlinks for GTK+ stock icons in the main package. This is in rawhide. If you notice missing icons in applications, please a) File a bug against the application b) Install gnome-icon-theme-legacy if you want your icons backc Matthias -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Shell commands like to OS/2 shell (or MS PowerShell)
tis 2010-04-20 klockan 01:51 +0300 skrev Slava Zanko: For example, all present utilites have sence just for guru's (ls, rm, fsck etc), but for novies it's hard to use. Is good idea to symlink'ing (shell aliasing) these and much more utilz to another names? The present utilities makes sense for gurus because they understand the history behind them and why the utilities have become what they are. But to create something that's easy for new users and that might be attractive to those of us that already know our way around the shell it wouldn't be enough to rename the commands. You'd need to dig deeper. For example you still have lots of obscure switches and options to consider. (Why is media.convert.video nothing at all like media.convert.audio.ogg?) And you have fun things like string quoting, forking processes, vectors (say, the difference between $* and $@), $IFS, error handling (did you know about set -e?) and so on... /Alexander -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Module-Manifest-0.07.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Module-Manifest: 84354a53992aad3d77d19ac8cf239d2e Module-Manifest-0.07.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: C++ help needed
On Tue, 2010-04-20 at 09:50 -0400, Tom spot Callaway wrote: Sadly, I am facing a task which exceeds my very meager C++ skills. I own a package called esperanza, which is a QT4 xmms2 client written in C++. With the latest xmms2 update (0.7DrNo, not yet built or pushed to any branch, but checked into rawhide CVS), the esperanza client no longer works (it builds, but never launches). Please note that xmms2 clients use a script launcher to ensure that xmms2 is running, see the esperanza.desktop file. I've updated the esperanza code to the latest set of git fixes in rawhide CVS (necessary to build), but I really could use the help of someone with C++ skills to get it working again. I emailed upstream, but never got a response. Can you give me a link? I'll take a look, see if there is anything I can do. Bernd The other xmms2 clients are held up on this, and I'd rather not simply dead.package this unless I absolutely have to. I would be happy to return the favor with work that is in my skillset, licensing, packaging, reviewing, triage, etc, etc. Thanks in advance, ~spot -- Bernd Stramm bernd.str...@gmail.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: urgent testing call: F13 kernel-2.6.33.1-24.fc13
Hi, sorry for the very late test - kernel is unusable for me, appears to be the same issue as described here for F12: https://bugzilla.redhat.com/show_bug.cgi?id=581605 It is one of the typical netbooks - did anyone recently test the Intel graphic on some of those devices? It is likely that the whole class of devices will be broken. Further datapoints, while 2.6.32.8-kernel.org works fine for me the Fedora-2.6.32.11 does not so it might be some of the Fedora patches. Same may be true for the 2.6.33 kernels. I am trying to back out the Fedora pacthes now.. will report. Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20100420 changes
Compose started at Tue Apr 20 08:15:05 UTC 2010 Broken deps for i386 -- evolution-couchdb-0.3.2-2.fc13.i686 requires libcouchdb-glib-1.0.so.1 paperbox-0.4.4-2.fc12.i686 requires libtrackerclient.so.0 rubygem-right_aws-1.10.0-3.fc14.noarch requires rubygem(right-http_connection) = 0:1.2.4 Broken deps for x86_64 -- evolution-couchdb-0.3.2-2.fc13.x86_64 requires libcouchdb-glib-1.0.so.1()(64bit) paperbox-0.4.4-2.fc12.x86_64 requires libtrackerclient.so.0()(64bit) rubygem-right_aws-1.10.0-3.fc14.noarch requires rubygem(right-http_connection) = 0:1.2.4 New package libqxt Qt extension library Removed package zikula-module-menutree Updated Packages: GConf2-2.31.1-1.fc14 * Mon Apr 19 2010 Matthias Clasen mcla...@redhat.com - 2.23.1-1 - Update to 2.31.1 - Include introspection data PyQwt-5.2.0-6.fc14 -- * Mon Apr 19 2010 Tadej Janež tadej.ja...@tadej.hicsalta.si - 5.2.0-6 - rebuild (for qwt-5.2.1, f11+) RBTools-0.2-4.fc14 -- * Mon Apr 19 2010 Stephen Gallagher sgall...@redhat.com - 0.2-4 - Update to 0.2 final release - Restore git-patchset patch, as it is now approved upstream ReviewBoard-1.5-7.beta1.fc14 * Sat Apr 17 2010 Stephen Gallagher sgall...@redhat.com - 1.5-7.beta1 - Remove previous patch. It was actually already in the source tree SIBsim4-0.20-1.fc14 --- * Mon Apr 19 2010 Christian Iseli christian.is...@licr.org 0.20-1 - Version 0.20. adjtimex-1.29-1.fc14 * Mon Apr 19 2010 Miroslav Lichvar mlich...@redhat.com 1.29-1 - update to 1.29 avahi-0.6.25-7.fc14 --- * Mon Apr 19 2010 Bastien Nocera bnoc...@redhat.com 0.6.25-7 - Split avahi libraries in -libs b43-fwcutter-013-1.fc14 --- * Mon Apr 19 2010 John W. Linville linvi...@redhat.com 013-1 - Update for b43-fwcutter-013 bareftp-0.3.2-1.fc14 * Mon Apr 19 2010 Itamar Reis Peixoto ita...@ispbrasil.com.br - 0.3.2-1 - New Version 0.3.2 culmus-fonts-0.104-3.fc14 - * Mon Apr 19 2010 Pravin Satpute psatp...@redhat.com - 0.104-3 - fixed bug 578018 .conf file curl-7.20.1-1.fc14 -- * Mon Apr 19 2010 Kamil Dudka kdu...@redhat.com 7.20.1-1 - new upstream release dhcp-4.1.1-17.fc14 -- * Mon Apr 19 2010 Jiri Popelka jpope...@redhat.com - 12:4.1.1-17 - Fill in Elapsed Time Option in Release/Decline messages (#582939) dropbear-0.52-1.fc14 * Mon Apr 19 2010 Itamar Reis Peixoto ita...@ispbrasil.com.br - 0.52-1 - New version 0.5.2 filesystem-2.4.35-1.fc14 * Mon Apr 19 2010 Ondrej Vasik ova...@redhat.com 2.4.35-1 - change permissions on /var/lock from 775 root:lock to 755 root:root (#581884) freedroidrpg-0.13-1.fc14 * Mon Apr 19 2010 Wart w...@kobold.org - 0.13-1 - Update to 0.13 fwfstab-0.04-0.1.rc1.fc14 - * Sun Apr 18 2010 Stewart Adam s.adam at diffingo.com - 0.04-0.1.20100418git - Update to git 20100418 (0.04 pre-release) - Remove kudzu dependency gdb-7.1-13.fc13 --- * Fri Apr 16 2010 Jan Kratochvil jan.kratoch...@redhat.com - 7.1-13.fc13 - archer-jankratochvil-fedora13 commit: 39998c496988faaa1509cc6ab76b5c4777659bf4 - [vla] Fix boundaries for arrays on -O2 -g (support bound-ref-var-loclist). - [vla] Fix copy_type_recursive for unavailable variables (Joost van der Sluis). gimp-2.6.8-7.fc14 - * Mon Apr 19 2010 Nils Philippsen n...@redhat.com - 2:2.6.8-7 - add --stack-trace-mode=never to desktop file gir-repository-0.6.5-9.fc14 --- * Mon Apr 19 2010 Matthias Clasen mcla...@redhat.com 0.6.5-9 - Drop GConf data, moved to GConf2 package glib2-2.25.1-2.fc14 --- * Mon Apr 19 2010 Matthias Clasen mcla...@redhat.com - 2.25.1-2 - Add a multilib wrapper for gio-querymodules * Mon Apr 19 2010 Matthias Clasen mcla...@redhat.com - 2.25.1-1 - Update to 2.25.1 groovy-1.7.2-1.fc14 --- * Tue Apr 20 2010 Lubomir Rintel lkund...@v3.sk - 1.7.2-1 - Bump version gvfs-1.6.0-2.fc14 - * Mon Apr 19 2010 Matthias Clasen mcla...@redhat.com - 1.6.0-2 - Use update-gio-modules hunspell-pl-0.20100419-1.fc14 - * Mon Apr 19 2010 Caolan McNamara caol...@redhat.com - 0.20100419-1 - latest version iproute-2.6.33-2.fc14 - * Tue Apr 20 2010 Marcela Mašláňová mmasl...@redhat.com - 2.6.33-2 - 578729 6rd tunnel correctly 3979ef91de9ed17d21672aaaefd6c228485135a2 - change BR texlive to tex according to guidelines jfreechart-1.0.13-1.fc14 * Mon Apr 19 2010 Lubomir Rintel lkund...@v3.sk - 1.0.13-1 - Update to a later release - Cosmetic fixes * Mon Apr 19 2010 Lubomir Rintel lkund...@v3.sk - 1.0.10-4 -
Re: Shell commands like to OS/2 shell (or MS PowerShell)
On Tue, 2010-04-20 at 16:56 +0200, Alexander Boström wrote: tis 2010-04-20 klockan 01:51 +0300 skrev Slava Zanko: For example, all present utilites have sence just for guru's (ls, rm, fsck etc), but for novies it's hard to use. Is good idea to symlink'ing (shell aliasing) these and much more utilz to another names? The present utilities makes sense for gurus because they understand the history behind them and why the utilities have become what they are. But to create something that's easy for new users and that might be attractive to those of us that already know our way around the shell it wouldn't be enough to rename the commands. You'd need to dig deeper. For example you still have lots of obscure switches and options to consider. (Why is media.convert.video nothing at all like media.convert.audio.ogg?) And you have fun things like string quoting, forking processes, vectors (say, the difference between $* and $@), $IFS, error handling (did you know about set -e?) and so on... /Alexander In addition to all that, I wouldn't say that these composite names are all that memorable. You would get people add a layer of translation to polish, chinese and to australian english. Then you would get shell scripts relying on translation layers being present. Romanian and French language purists would insist that filesystem.do.this.and.that should be that.and.this.do.filesystem, nothing else will do. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re:rawhide report: 20100420 changes
PyQwt-5.2.0-6.fc14 -- * Mon Apr 19 2010 Tadej Janež tadej.ja...@tadej.hicsalta.si - 5.2.0-6 - rebuild (for qwt-5.2.1, f11+) I wonder why PyQwt should be rebuilt for qwt 5.2.1 ,since qwt 5.2.0 and 5.2.1 are ABI compatible as I known.-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Gnome Games Clutter/OpenGL issues
I have been dealing with this issue in the context of Ubuntu Lucid, however since it can be reproduced under F13 Beta I thought it would be wise to raise it here. In some cases, gnome-games do not properly fall back to software rendering and fail to start. This bug happens reliably with KVM and VirtualBox but has been reported on real HW. The bugs are: https://bugzilla.gnome.org/show_bug.cgi?id=615630 https://bugs.launchpad.net/bugs/561734 -- Mark Bidewell http://www.linkedin.com/in/markbidewell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Gnome Games Clutter/OpenGL issues
On Tue, Apr 20, 2010 at 9:18 AM, Mark Bidewell mbide...@gmail.com wrote: I have been dealing with this issue in the context of Ubuntu Lucid, however since it can be reproduced under F13 Beta I thought it would be wise to raise it here. In some cases, gnome-games do not properly fall back to software rendering and fail to start. This bug happens reliably with KVM and VirtualBox but has been reported on real HW. The bugs are: Yep i ran into this as well, when I was forced to fall back to the vesa driver (long story..not important) Once I moved to a driver with accelerated graphics support problem went away. If my experience is right, anyone should be able to reproduce this on any hardware by using the vesa driver and turning off modesetting. I just haven't gotten around to filing it against Fedora Beta yet...sorry -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Gnome Games Clutter/OpenGL issues
On Tue, Apr 20, 2010 at 7:28 PM, Jeff Spaleta jspal...@gmail.com wrote: On Tue, Apr 20, 2010 at 9:18 AM, Mark Bidewell mbide...@gmail.com wrote: I have been dealing with this issue in the context of Ubuntu Lucid, however since it can be reproduced under F13 Beta I thought it would be wise to raise it here. In some cases, gnome-games do not properly fall back to software rendering and fail to start. This bug happens reliably with KVM and VirtualBox but has been reported on real HW. The bugs are: Yep i ran into this as well, when I was forced to fall back to the vesa driver (long story..not important) Once I moved to a driver with accelerated graphics support problem went away. If my experience is right, anyone should be able to reproduce this on any hardware by using the vesa driver and turning off modesetting. Clutter is not targeting mesa's software rastersizer ... so clutter upstream do not really care if it works without any hardware support or not. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Gnome Games Clutter/OpenGL issues
On Tue, Apr 20, 2010 at 9:32 AM, drago01 drag...@gmail.com wrote: Clutter is not targeting mesa's software rastersizer ... so clutter upstream do not really care if it works without any hardware support or not. Which is all fine for an optional component gnome-shell which explicitly states it targets hardware accelerated graphics only. But should be be putting clutter based apps into the default packageset for the desktop in F13 if they don't fallback gracefully for unaccelerated graphics? We haven't stated that accelerated hardware will be a minimum requirement in F13 have we? I know its coming, but we haven't actually crossed that line yet. If we can't get this working with software rendering as a fallback...perhaps we jettison this game from the default packageset and move it over to gnome-games-extra. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Gnome Games Clutter/OpenGL issues
On Tue, Apr 20, 2010 at 1:52 PM, Jeff Spaleta jspal...@gmail.com wrote: On Tue, Apr 20, 2010 at 9:32 AM, drago01 drag...@gmail.com wrote: Clutter is not targeting mesa's software rastersizer ... so clutter upstream do not really care if it works without any hardware support or not. Which is all fine for an optional component gnome-shell which explicitly states it targets hardware accelerated graphics only. But should be be putting clutter based apps into the default packageset for the desktop in F13 if they don't fallback gracefully for unaccelerated graphics? We haven't stated that accelerated hardware will be a minimum requirement in F13 have we? I know its coming, but we haven't actually crossed that line yet. If we can't get this working with software rendering as a fallback...perhaps we jettison this game from the default packageset and move it over to gnome-games-extra. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Quadrapassel is in gnome-games-extra. One interesting note I will try to get more details on. is that some are reporting the bug when using nouveau (which I assumed was accelerated). -- Mark Bidewell http://www.linkedin.com/in/markbidewell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Gnome Games Clutter/OpenGL issues
On Tue, Apr 20, 2010 at 7:52 PM, Jeff Spaleta jspal...@gmail.com wrote: On Tue, Apr 20, 2010 at 9:32 AM, drago01 drag...@gmail.com wrote: Clutter is not targeting mesa's software rastersizer ... so clutter upstream do not really care if it works without any hardware support or not. Which is all fine for an optional component gnome-shell which explicitly states it targets hardware accelerated graphics only. But should be be putting clutter based apps into the default packageset for the desktop in F13 if they don't fallback gracefully for unaccelerated graphics? It is just a game ... We haven't stated that accelerated hardware will be a minimum requirement in F13 have we? No, because it isn't F-13 does work fine without any hardware opengl support, I know its coming, but we haven't actually crossed that line yet. If we can't get this working with software rendering as a fallback... It isn't impossible but it won't be very effizent anyway ... resources should be spent on make 3D work not run away from it. perhaps we jettison this game from the default packageset and move it over to gnome-games-extra. Well again it is just a game so I don't really care but it does not make much sense ... since when was needs 3D a reason to exclude anything from the livecd ? Ever tried to run compiz on software? (hint: desktop effects will tell you to come back once you are using a 3D driver). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Gnome Games Clutter/OpenGL issues
On Tue, Apr 20, 2010 at 8:00 PM, Mark Bidewell mbide...@gmail.com wrote: [...] Quadrapassel is in gnome-games-extra. One interesting note I will try to get more details on. is that some are reporting the bug when using nouveau (which I assumed was accelerated). You need to install mesa-dri-drivers-experimental for it to work. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gnome-icon-theme in rawhide
On Tue, 2010-04-20 at 18:00 +0100, Mat Booth wrote: Is this what has caused this bug in the F13 Beta? https://bugzilla.redhat.com/show_bug.cgi?id=573809 No. A package split I have built in rawhide this morning can not break an F13 release that went to the mirrors a week ago... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Gnome Games Clutter/OpenGL issues
On Tue, Apr 20, 2010 at 10:02 AM, drago01 drag...@gmail.com wrote: It is just a game ... Ever tried to run compiz on software? (hint: desktop effects will tell you to come back once you are using a 3D driver). Ah...see here's the thing... this application doesn't actually tell you anything...its just fails silently. You only see the error if you run it from a terminal. But since its already in the gnome-games-extra package, (apologizes for mis remembering that), its not as big a deal for me. if we can get it to fail less silently and tell the user they need accelerated hardware to run the game then that would prevent some amount of unneeded head scratching. -jefis going through blackjack withdrawsspaleta -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Minutes/Summary for todays FESCo meeting (2010-04-20)
=== #fedora-meeting: FESCO (2010-04-20) === Meeting started by nirik at 19:00:02 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2010-04-20/fesco.2010-04-20-19.00.log.html Meeting summary --- * init process (nirik, 19:00:02) * #351 Create a policy for updates (nirik, 19:03:29) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=579256#c7 (Kevin_Kofler, 19:10:26) * #365 fesco list management questions (nirik, 19:13:52) * AGREED: The fesco list will only have the current fesco + FPL on it. Members will be urged to post publicly if at all possible. (nirik, 19:28:50) * ACTION: nirik will update the fesco web page on this. (nirik, 19:29:03) * FES Tickets (nirik, 19:29:15) * LINK: https://fedorahosted.org/fedora-engineering-services/report/6 (nirik, 19:29:18) * AGREED: will drop voting, and look at most cc'ed bugs and most comments in previous timeperiod instead. (nirik, 19:39:27) * Open Floor (nirik, 19:40:27) * LINK: https://fedoraproject.org/wiki/Elections (nirik, 19:42:50) Meeting ended at 19:44:21 UTC. 19:00:02 nirik #startmeeting FESCO (2010-04-20) 19:00:02 nirik #meetingname fesco 19:00:02 nirik #chair dgilmore notting nirik skvidal Kevin_Kofler ajax pjones cwickert mjg59 19:00:02 nirik #topic init process 19:00:03 zodbot Meeting started Tue Apr 20 19:00:02 2010 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:04 zodbot Useful Commands: #action #agreed #halp #info #idea #link #topic. 19:00:06 zodbot The meeting name has been set to 'fesco' 19:00:07 zodbot Current chairs: Kevin_Kofler ajax cwickert dgilmore mjg59 nirik notting pjones skvidal 19:00:22 * dgilmore is here 19:00:25 * pjones is too 19:01:02 * nirik thinks he's here. 19:01:09 * notting is here 19:01:51 Kevin_Kofler Present. 19:02:24 * cwickert is here 19:03:08 ajax howdy 19:03:21 nirik ok, lets go ahead then... 19:03:29 nirik #topic #351 Create a policy for updates 19:03:44 nirik I left this on the agenda for any status updates on implementation. 19:03:52 Kevin_Kofler I have some evidence that the critical path process, on which this new process is being based on, just plain does not work. 19:03:54 nirik I'm afraid I didn't have much time to work on it last week. 19:04:26 Kevin_Kofler This HAL freeze override: https://admin.fedoraproject.org/updates/hal-0.5.14-3.fc13 causes a big regression in KDE (which should be obvious even from the description). 19:04:28 nirik next steps would be: propose comp group changes for other de's and applications. 19:04:48 mjg59 Kevin_Kofler: And the KDE maintainer was notified ahead of time 19:04:57 Kevin_Kofler It got fixed by a kdebase-runtime freeze override, pushed directly to stable (which is thankfully still possible). 19:04:59 Kevin_Kofler mjg59: No. 19:05:04 Kevin_Kofler You only talked about Rawhide. 19:05:16 Kevin_Kofler At no point did you ever tell us that you were pushing this to F13. 19:05:43 Kevin_Kofler And it should have been obvious to you that this was only possible in a coordinated grouped push, not the way you did it. 19:05:44 * nirik doesn't think this has anything to do with the updates infrastructure... more communication needed/helpful. 19:05:46 pjones so, now that we've instantly delved as far as he said, she said, ... 19:05:57 cwickert I agree there was a communication breakdown, but for me this doesn't have to do anything with the update policy 19:06:00 Kevin_Kofler pjones: Except I have evidence. 19:06:01 mjg59 #fedora-kde.29.log:29-03-2010 19:23:15 mjg59: rdieter_work: Ok, I just committed that to F13 19:06:16 mjg59 #fedora-kde.29.log:29-03-2010 19:26:03 mjg59: Hal's critpath, though 19:06:16 mjg59 #fedora-kde.29.log:29-03-2010 19:26:18 mjg59: So it'll take a little while to get through 19:06:22 * EvilBob gets more popcorn out 19:06:52 Kevin_Kofler Oh, so you told us on IRC, fun. I wasn't even online when you posted that. 19:07:00 mjg59 rdieter said he would deal with it 19:07:00 cwickert mjg59: 2009-03-29 is 6 days after beta freeze 19:07:21 mjg59 cwickert: Yes. That's why I didn't attempt to move it through the process any faster. 19:07:29 Kevin_Kofler Your e-mail announcement was only about Rawhide, as a look to the archives will confirm. 19:08:01 mjg59 So, yes, there are questions here 19:08:06 cwickert mjg59: changes like this are not supposed to happen after beta freeze. Xfce and LXDE are affected to and you never notified us, did you? 19:08:07 nirik so, from this I think we learn that we need more communication and announcements about such changes. 19:08:08 pjones ... which presumably explains why he felt the need to tell somebody about F13 as well. 19:08:13 Kevin_Kofler Anyway, the thing is that this should never have been pushed as a non-grouped update, and the critpath process failed to catch the regression. 19:08:36 Kevin_Kofler I also
Re: Gnome Games Clutter/OpenGL issues
On Tue, Apr 20, 2010 at 8:30 PM, Jeff Spaleta jspal...@gmail.com wrote: On Tue, Apr 20, 2010 at 10:02 AM, drago01 drag...@gmail.com wrote: It is just a game ... Ever tried to run compiz on software? (hint: desktop effects will tell you to come back once you are using a 3D driver). Ah...see here's the thing... this application doesn't actually tell you anything...its just fails silently. You only see the error if you run it from a terminal. But since its already in the gnome-games-extra package, (apologizes for mis remembering that), its not as big a deal for me. if we can get it to fail less silently and tell the user they need accelerated hardware to run the game then that would prevent some amount of unneeded head scratching. We do have opengl-game-utils for exactly this ... it should just use it (like we do for any other games). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Gnome Games Clutter/OpenGL issues
On Tue, 2010-04-20 at 22:52 +0200, drago01 wrote: On Tue, Apr 20, 2010 at 8:30 PM, Jeff Spaleta jspal...@gmail.com wrote: On Tue, Apr 20, 2010 at 10:02 AM, drago01 drag...@gmail.com wrote: It is just a game ... Ever tried to run compiz on software? (hint: desktop effects will tell you to come back once you are using a 3D driver). Ah...see here's the thing... this application doesn't actually tell you anything...its just fails silently. You only see the error if you run it from a terminal. But since its already in the gnome-games-extra package, (apologizes for mis remembering that), its not as big a deal for me. if we can get it to fail less silently and tell the user they need accelerated hardware to run the game then that would prevent some amount of unneeded head scratching. We do have opengl-game-utils for exactly this ... it should just use it (like we do for any other games). Any pointers for what that involves ? I hadn't heard of opengl-game-utils before... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Gnome Games Clutter/OpenGL issues
On Tue, Apr 20, 2010 at 11:40 PM, Matthias Clasen mcla...@redhat.com wrote: On Tue, 2010-04-20 at 22:52 +0200, drago01 wrote: On Tue, Apr 20, 2010 at 8:30 PM, Jeff Spaleta jspal...@gmail.com wrote: On Tue, Apr 20, 2010 at 10:02 AM, drago01 drag...@gmail.com wrote: It is just a game ... Ever tried to run compiz on software? (hint: desktop effects will tell you to come back once you are using a 3D driver). Ah...see here's the thing... this application doesn't actually tell you anything...its just fails silently. You only see the error if you run it from a terminal. But since its already in the gnome-games-extra package, (apologizes for mis remembering that), its not as big a deal for me. if we can get it to fail less silently and tell the user they need accelerated hardware to run the game then that would prevent some amount of unneeded head scratching. We do have opengl-game-utils for exactly this ... it should just use it (like we do for any other games). Any pointers for what that involves ? I hadn't heard of opengl-game-utils before... http://fedoraproject.org/wiki/SIGs/Games/Packaging See the OpenGL Wrapper section at the bottom. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reverting kaddressbook back to previous version?
Juha Tuomala wrote: I recall, that the earlier version had some level of Akonadi support as well, so in theory, would it be possible to revert the codebase back to the one that can actually be used? And what to do with the already migrated data? And the data users added after migration? I don't think reverting is feasible at this point (and I agree our kde ML would be a better place to discuss this). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
2010-04-13 to 2010-04-15 Graphics Test Week recap
The insanity that is Graphics Test Week is now over, so it's time for the recap! https://fedoraproject.org/wiki/Test_Day:2010-04-13_Nouveau https://fedoraproject.org/wiki/Test_Day:2010-04-14_Radeon https://fedoraproject.org/wiki/Test_Day:2010-04-15_Intel We had a great turnout again; thanks to everyone for testing. Here's some interesting numbers I just pulled out... f11 nouveau: 104 tests, 42 bugs - ratio 0.40 f12 nouveau: 53 tests, 34 bugs - ratio 0.64 f13 nouveau: 78 tests, 26 bugs - ratio 0.33 f11 radeon: 55 tests, 46 bugs - ratio 0.84 f12 radeon: 61 tests, 81 bugs - ratio 1.33 f13 radeon: 48 tests, 33 bugs - ratio 0.69 f11 intel: 23 tests, 21 bugs - ratio 0.91 f12 intel: 29 tests, 31 bugs - ratio 1.07 f13 intel: 38 tests, 38 bugs - ratio 1.00 The 'ratio' is the number of bugs per test. Obviously there's wiggle room here; different people report different bugs, and some of the drivers implement features the others don't (and hence have more 'surface area' for bugs). But I think they're quite fun anyway. Nouveau and Radeon both regressed from f11 to f12, according to the numbers, and got better than either previous release for f13 (at Test Day time). Intel has stayed fairly steady. According to this analysis, Nouveau wins the 'least buggy driver' contest by a fair margin, which is interesting! For F13, it has half as many bugs per test as Radeon, and a third as many as Intel. (Of course, I'm sure some of our erstwhile devs would argue it could fairly be renamed the 'least crack-addled hardware manufacturer contest'...) The F11 Test Days happened in March 2009, the F12 Test Days in September 2009, and the F13 last week; these are pretty comparable points in the respective cycles. In terms of participation, we had the largest number of testers for F11, with the nouveau number accounting for most of that; I suspect this is because nouveau was very new and shiny in F11 and impossible to use on most distros, so people were very interested in trying it out for the first time. F12 had the fewest tests run, and F13 pretty much splits the difference. Since I'm getting up a head of steam, let's look at fixes! f11 nouveau: 42 bugs, 4 open, 8 closeddupe, 24 closedfixed, 6 closedunfixed - 70.59% f12 nouveau: 34 bugs, 11 open, 8 closeddupe, 14 closedfixed, 1 closedunfixed - 53.85% f11 radeon: 46 bugs, 14 open, 10 closeddupe, 19 closedfixed, 3 closedunfixed - 52.78% f12 radeon: 81 bugs, 19 open, 32 closeddupe, 28 closedfixed, 2 closedunfixed - 57.14% f11 intel: 21 bugs, 7 open, 1 closeddupe, 12 closedfixed, 1 closedunfixed - 60% f12 intel: 31 bugs, 7 open, 12 closeddupe, 12 closedfixed, 0 closedunfixed - 63.16% I counted CANTFIX, WONTFIX and INSUFFICIENT_DATA as 'unfixed', ERRATA, RAWHIDE, CURRENTRELEASE and NEXTRELEASE as 'fixed'. NOTABUG I lumped in with DUPLICATE as the 'closeddupe' number (these are reports that should be discarded from consideration entirely). The percentage is calculated as: closedfixed / (bugs - closeddupe) * 100 i.e. it roughly indicates the percentage of genuine unique bugs reported that have been fixed so far. These numbers are pretty close, both across drivers and across releases; we've fixed just over half the bugs reported. I think the outlying high nouveau result is probably a consequence of 'low-hanging fruit' - the driver was in a pretty initial state at that point, so the bugs exposed are likely to have been, on the whole, easier to fix. Obviously I've left F13 out as the maintainers have had only half a week to work on the bugs! The raw lists of bugs reported from the F13 Test Days follow. Thanks very much to all testers, and to the wonderful Fedora X.org developers and triagers: Adam Jackson Dave Airlie Jerome Glisse Ben Skeggs Matej Cepl François Cami Chris Campbell for helping to organize the events, set up the test cases, man the IRC channel and triage - and of course fix! - all the bugs. Nouveau --- 573096 NEW - F13 Beta - Garbled Display. NV18 chipset. Both DVI-D and VGA outputs 579897 NEW - Xorg uses 100% cpu with nouveau and GeForce 8400 GS 581769 NEW - nVidia Corporation GeForce 6150SE nForce 430 (rev a2) fails with compiz 581934 NEW - When booting the test day live image machine is very slow and various services crash. 581945 NEW - Screen corruption occurs when turning on desktop effects 581956 NEW - Doesn't detect secondary display (connected via DVI cable) on GeForce 6150SE nForce 430 582070 NEW - Screen Flicker Playing Totem Video - Testcase nouveau xvideo 582168 NEW - testday case: XVideo FAILED, on 8400 GS 582271 NEW - Fails to boot and display only shows thin white lines and dots with a blinking cursor 582272 NEW - Suspend fails on nVidia Corporation G84M [Quadro NVS 140M] 582379 NEW - compiz fails on GeForce 7050 PV 582489 NEW - Garbage when swithing from plymouth to gdm 582606 NEW - starting X server from runlevel 3 does not work - black screen 582617 NEW - [dualhead] when leaving fulscreen with changed resolution,
Re: Shell commands like to OS/2 shell (or MS PowerShell)
On Tue, Apr 20, 2010 at 4:37 PM, Frank Murphy frankl...@gmail.com wrote: On 19/04/10 23:51, Slava Zanko wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi folk, I want to propose new idea about names of command line utilites... For example, all present utilites have sence just for guru's (ls, rm, fsck etc), but for novies it's hard to use. Bookmark this: http://ss64.com/bash/ Less typing, less for novices to forget. -- Regards, Frank Murphy UTF_8 Encoded, Fedora.x86 64-32 Hybrid I'm against any change. It makes perfect sense the way it is now. And it's great for those who use both Linux and Unix because most commands are interoperable between the two platforms. And beyond that, it's fast as a result of keeping commands short and easy to remember. I haven't met a newbie yet that is even interested in learning how to interact with the command-line. They all seem to be some new breed migrating from Windows and expecting *nix to operate in a 1:1 manner. And for those who do want to learn it, do exactly that--learn it. It just takes time. Be patient. I think there's more important things to focus on regarding Linux development. -- Chris Jones Photographic Imaging Professional and Graphic Designer ABN: 98 317 740 240 Photo Resolutions Web: http://photoresolutions.freehostia.com Email: chrisjo...@comcen.com.au -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Shell commands like to OS/2 shell (or MS PowerShell)
On Tue, 2010-04-20 at 10:00 +0300, Slava Zanko wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Frank Murphy wrote: Bookmark this: http://ss64.com/bash/ I know about :) This idea just try for standartization of command names... I know about posix and LSB, but these standards don't make logic in the names of commands. Okay, as I see, this idea don't have interest for most... To All: in any case, thanks for attention. Honestly it doesn't effect me since my brain has long since been molded into the unix way, but what about this as an alternative idea: In addition to dumping out options when --help is specified, perhaps an option like --helpxml could be added (maybe even generated from the gnu getopts data) to dump out information about how the program is used as well as the options. Then a gui tool or other front end could parse that XML and generate an interface for the end users. AIX (I think) used to have that for some of the more esoteric sysadmin tools, but they were one-off wrappers. It might make it easier for some people to build complex command lines that use lots of piping...say for parsing logs or something: gunzip -fc /www/logs/access* | grep GET /status | cut -f 1 -d\ | sort | uniq -c | sort -n Or, even as a worst case, perhaps man pages could be parsed, but that is probably a road to madness. Brian - -- WBR, Slavaz. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFLzVDzb3oGR6aVLpoRAuIcAJ4qqkjvdiJrI/HugEK9igYKMrdFFACePVrB XpjNndoiHl0fgk44C/SGIK8= =tyjV -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Thoughts on using Lernid in Fedora meetings classroom sessions.
I'm assuming everyone here has heard of Lernid, the little classroom ui that Jono Bacon original put together. I got lernid trunk up and running on Fedora 13. All the prerequisites are in place. it connects to the Ubuntu events. My understanding is that lernid just needs a hardcoded url from which to grab a set of event definitions. Here is what lernid is currently using: http://www.jonobacon.org/files/lernid/ubuntu.lernid Event items are really simple at the moment. its using freenode as a hardcoded irc server. One channel for speaking one channel for chatting. Its the same model we use in our town hall meetings. I'd like to see if Fedora contributors think lernid is a useful tool and then to help extend it further as a general purpose remote classroom tool. The best way to know is to dig in and try to use it. What I want to do is submit lernid into the Fedora repositories with a new Fedora specific classroom/meeting event url hardcoded, until such time that lernid gains the ability to register and handle multiple event services via configuration data. I can imagine this being something upstream projects could use to run general training once lernid is general purpose enough. The only real question I have is what should the Fedora event url be and who should ultimately be responsible for filling it with events? I've no problem shoving the event url into my fedora project disk space for now and managing event requests. In fact that's probably what I'm going to do for initial package review. But it really feels like something that we could tie into infrastructure and have be a self servicing sort of thing for contributors to register events with. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: HAL status
Ben Boeckel wrote: With X no longer using HAL for device configuration, what the status of completely replacing HAL? For KDE, according to upstream, we need to wait for at least 4.5, but more likely 4.6. (Hopefully it will not end up being even longer, like for Akonadi which will only finally be fully used in 4.5 after having initially been planned for 4.0.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Shell commands like to OS/2 shell (or MS PowerShell)
Thomas Janssen wrote: Agreed. Plus a command like: filesystem.remove would confuse and scare novices. Ugh, that removes my filesystem Well, if it scares them enough not to abuse rm -rf, that's a good thing. ;-) IMHO file deletions should always be performed through a graphical file manager with confirmation prompts. The GUI also reduces the risk of typos by a lot. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rpms/perl-Debug-Client/devel - New directory
Author: kevin Update of /cvs/pkgs/rpms/perl-Debug-Client/devel In directory cvs01.phx2.fedoraproject.org:/home/fedora/kevin/CVSROOT/admin/tmpcvsj15965/rpms/perl-Debug-Client/devel Log Message: Directory /cvs/pkgs/rpms/perl-Debug-Client/devel added to the repository -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-Debug-Client Makefile,NONE,1.1
Author: kevin
Update of /cvs/pkgs/rpms/perl-Debug-Client
In directory
cvs01.phx2.fedoraproject.org:/home/fedora/kevin/CVSROOT/admin/tmpcvsj15965/rpms/perl-Debug-Client
Added Files:
Makefile
Log Message:
Setup of module perl-Debug-Client
--- NEW FILE Makefile ---
# Top level Makefile for module perl-Debug-Client
all : CVS/Root common-update
@cvs update
common-update : common
@cd common cvs update
common : CVS/Root
@cvs checkout common
CVS/Root :
@echo ERROR: This does not look like a CVS checkout exit 1
clean :
@find . -type f -name *~ -exec rm -fv {} \;
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
