scorched3d needs a new owner
Hi, I've not been able to give scorched3d the attention it deserves lately. Specifically it is lagging with upstream for a while now and really needs to be rebased to upstream latest. Is anyone willing to become a new (co)-maintainer for scorched3d and do the rebase? Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The behaviour of systemctl.
On Fri, Jun 17, 2011 at 04:31:08PM -0700, Jesse Keating wrote: The apps that I've seen where they do something special like paging the output by default, will not do that if the output is a non-active tty, such as a pipe. When you pipe it into something it'll react differently. Yes, and this is exactly the problem. When I run 'systemctl --all' on the tty, I get paging and column headers. When I pipe into something, I get no paging and no column headers. The assumption here is apparently that if the output is not going to tty then it is not destined for human eyes, which is an absolutely ridiculous assumption to make. If I output to a file so I can look at things later, I get no headers, and have no option to force them on non-tty output. This alone may seem fairly trivial, but the problem is that there are many of these trivialities, all of which seem to stem from authors who either don't understand UNIX programming, or are actively choosing to ignore convention. Seriously, if anybody suggests that the solution to the above problem is to add a '--force-headers' flag, I think I'm going to start using Windows. We need to start having this discussion before more of this stupid behaviour starts finding its way into other core components of Fedora. /Aaron signature.asc Description: Digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /etc/bash_completion.d/ vs /usr/share/bash-completion/
On 06/17/2011 08:43 PM, Jesse Keating wrote: Both seem to be in use by various packages. Which one is thought to be correct? Should this be in the guidelines somewhere? I'd say at the moment nothing besides bash-completion itself should be installing files to /usr/share/bash-completion, and I'm not aware of any package that does that. Can you point out some? In its current default configuration, bash_completion does not load any completions from that dir, it loads them from /etc/bash_completion.d. bash-completion contains completions for many commands that may not be installed and enables them with rpm triggers by symlinking things to /etc/bash_completion.d to avoid loading stuff that will not be used. Packages that install completions for commands that they ship themselves need not jump through such hoops, they can simply drop their completions to /etc/bash_completion.d. Some of this will quite probably change with the next upstream release, which will also add a pkgconfig file with which packages installing completions can find out the dir to use like pkg-config --variable=completionsdir bash-completion. Loading files from /etc/bash_completion.d will continue to be supported just like it is now for backwards compatibility, but it is possible that some additional rules (naming etc) how to install files to the path pointed to by the pkgconfig snippet will be established. There will be documentation in the bash-completion package how to do things the right way and I'll post a heads up note here when the details have been figured out. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
appletalk+psnap+ipx modules in the kernel-3.0-0.rc3.git5.1.fc16
Dear All I have installed the latest kernel from koji and found out that now I have 3 new modules: appletalk psnap ipx I know what is IPX. But do we really need to have AppleTalk always loaded in the kernel? What is psnap? Thanks -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 / VirtualBox
On Fri, Jun 17, 2011 at 12:06:02PM -0600, Stephen John Smoogen wrote: So my guess would be to make kvm/qemu bigger.. make it work in Windows. Apart from WinKVM already mentioned, you can run straight qemu on Windows. It works like a charm, not very fast, but good enough for testing things. We are even able to cross-compile it using the Fedora Windows cross-compiler project! The story with the higher level management tools is not very good. You can compile libvirt on Windows (in fact, we cross-compile it in Fedora -- see mingw32-libvirt). However this only includes the client side library. Useful for connecting to remote libvirt instances running on real operating systems, but the daemon *cannot* be compiled on Windows meaning you can't control a local qemu.exe. virt-manager would in theory work on Windows (using eg. Active Python). Since we're only interested in cross-compiling things [treating Windows as a weird badly-behaved embedded OS] we can't do that, because Python itself has a broken build system that doesn't understand cross-compilation [Python issues 5404, 1597850]. Cross-compiling any C program that uses libvirt is usually easy. I've also had the OCaml programs like virt-top and guestfs-browser cross-compiled to Windows. The OCaml cross-chain isn't in Fedora, but ironically Debian took that work and ran with it, and they provide a decent OCaml cross-chain now. 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
Queries regarding packaging of static libraries
Hello, I'm working on packaging required software to add to the fedora medical initiative. Of late, I've come across quite a few *tiny* libraries which are build deps for the software. The issue with most of these are that they only provide static libraries. These are generally libraries used by universities in research. I've already submitted two of them for review: https://bugzilla.redhat.com/show_bug.cgi?id=714326 https://bugzilla.redhat.com/show_bug.cgi?id=714327 and now, I've come across two more: http://www.cise.ufl.edu/research/sparse/UFconfig/UFconfig-3.6.1.tar.gz http://www.cise.ufl.edu/research/sparse/amd/AMD-2.2.2.tar.gz All the software that require these maintain a bundled version. I wanted to know if I need to package these, (without any shared libs), or should I just let the bundled versions remain as internal libraries? Someone at #fedora-devel suggested I patch the Makefiles to generate the shared objects. I'm not sure if it's okay to provide shared objects while upstream only provides static libs. This will also increase the work required in packaging since all the Makefiles will need to be heavily patched. I'd like to know what the correct and efficient way to proceed here is. Thanks, Regards, Ankur -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The behaviour of systemctl.
On 06/18/2011 01:06 AM, Aaron Sowry wrote: n Fri, Jun 17, 2011 at 10:41:14PM +0100, Martin Dengler wrote: As you point out, git-log and --help do this too. It's excellent. Make it configurable if you must, but I'd be interested to think why you think it's not always the useful thing to do. The reasons why it's not the useful thing to do were pointed out in my previous email. I don't appreciate the default paging behavior at all either, but at least git gives me an easy global way to get rid of it: export GIT_PAGER=cat in ~/.bash_profile. systemctl does not seem to offer anything comparable (remembering to type --no-pager or setting $PAGER which affects other things do not count), or did I miss something? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Queries regarding packaging of static libraries
On Sat, Jun 18, 2011 at 03:28:01PM +0530, Ankur Sinha wrote: Hello, I'm working on packaging required software to add to the fedora medical initiative. Of late, I've come across quite a few *tiny* libraries which are build deps for the software. The issue with most of these are that they only provide static libraries. These are generally libraries used by universities in research. I've already submitted two of them for review: https://bugzilla.redhat.com/show_bug.cgi?id=714326 https://bugzilla.redhat.com/show_bug.cgi?id=714327 and now, I've come across two more: http://www.cise.ufl.edu/research/sparse/UFconfig/UFconfig-3.6.1.tar.gz http://www.cise.ufl.edu/research/sparse/amd/AMD-2.2.2.tar.gz All the software that require these maintain a bundled version. I wanted to know if I need to package these, (without any shared libs), or should I just let the bundled versions remain as internal libraries? Someone at #fedora-devel suggested I patch the Makefiles to generate the shared objects. I'm not sure if it's okay to provide shared objects while upstream only provides static libs. This will also increase the work required in packaging since all the Makefiles will need to be heavily patched. I'd like to know what the correct and efficient way to proceed here is. The correct way is to patch the Makefiles so they can build shared libraries, to send those patches upstream, and to unbundle any bundled libraries. It's quite a bit of work, but if upstream accept your patches then hopefully it's only a one-off piece of work. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Self Introduction
Khusro Jaleel wrote: I asked Máirín Duffy on twitter what I could do to contribute for packages and she suggested fonts as an easy place to start so here I am :-) She might have been half joking. Although packaging fonts is theoretically easy because of the packaging templates we use, the state of upstream archives is often very poor, with no clear versioning, missing licenses and limited language coverage. Welcome :-) She has suggested some fonts I could package so I'm working through the first one, League Gothic. I'm having some trouble understanding what foundries are and how font packaging works in Fedora in general so any help along those lines is much appreciated. The font packaging lifecycle is here: https://fedoraproject.org/wiki/Font_package_lifecycle League Gothic is already on the wishlist, so its page is here: https://fedoraproject.org/wiki/TLOMT_League_Gothic_fonts A foundry is an organisation or single person who issues fonts. The League of Moveable Type is one such, and our foundry abbreviation for them is tlomt. You'll find some of their other fonts have been packaged already, so taking a look at those src.rpms may give you some pointers. If you look through the wiki pages of fonts that have already been packaged, you'll find the bugzilla numbers of their review requests, and looking through some of the comments in those reviews will help you avoid common mistakes. I would recommend you join the fonts mailing list if you have further questions. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Queries regarding packaging of static libraries
On Sat, 2011-06-18 at 11:17 +0100, Richard W.M. Jones wrote: The correct way is to patch the Makefiles so they can build shared libraries, to send those patches upstream, and to unbundle any bundled libraries. It's quite a bit of work, but if upstream accept your patches then hopefully it's only a one-off piece of work. Rich. Can I not just stick to this[1]. I don't think these libraries will be used in any other packages. They're pretty old, if you look at the links. Thanks, Ankur [1] http://fedoraproject.org/wiki/Packaging/Guidelines#Packaging_Static_Libraries_2 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
release 3.0-0.rc3.git0.3.fc16.x86_64=3.0.0 gives version code 196608 endless loop: microcode: CPU0: family 15 not supported
I upgraded to release 3.0-0.rc3.git0.3.fc16.x86_64=3.0.0 gives version code 196608 Now I get an endless loop error CPU0: family 15 not supported, which has udevd running and putting an extreme load on my CPU. I am including less /proc/cpuinfo and lsmod|sort for help I have a Gateway LT 3103 netbook ! please help also the display becomes very distorted while using firefox I dont know if there is a connection of issues. microcode: CPU0: family 15 not supported less /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 124 model name : AMD Athlon(tm) Processor L110 stepping: 2 cpu MHz : 1196.911 cache size : 512 KB fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow up rep_good nopl extd_apicid pni cx16 lahf_lm svm extapic cr 8_legacy 3dnowprefetch lbrv bogomips: 2393.82 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp tm stc 100mhzsteps ls /etc/udev/rules.d 70-persistent-net.rules 90-hal.rules 99-fuse.rules 90-alsa-tools-firmware.rules 91-drm-modeset.rules lsmod|sort 8021q 24721 0 acerhdf18697 0 acer_wmi 23819 0 arc4 12529 2 ata_generic12899 0 ath23230 2 ath9k,ath9k_hw ath9k 114468 0 ath9k_common 13432 1 ath9k ath9k_hw 300284 2 ath9k,ath9k_common cfg80211 160721 3 ath9k,mac80211,ath drm 201070 4 radeon,ttm,drm_kms_helper drm_kms_helper 36242 1 radeon edac_core 47910 0 edac_mce_amd 18786 0 garp 14592 1 8021q i2c_algo_bit 13246 1 radeon i2c_core 33947 6 videodev,i2c_piix4,radeon,drm_kms_helper,drm,i2c_algo_bit i2c_piix4 17790 0 ip6table_filter12815 1 ip6_tables 23088 1 ip6table_filter ip6t_REJECT12976 2 joydev 17567 0 k8temp 13087 0 llc14197 2 garp,stp mac80211 275703 1 ath9k media 20483 2 uvcvideo,videodev mii13527 1 r8169 Module Size Used by nf_conntrack 77601 3 nf_conntrack_ipv6,nf_conntrack_ipv4,xt_state nf_conntrack_ipv4 14700 1 nf_conntrack_ipv6 14329 1 nf_defrag_ipv4 12673 1 nf_conntrack_ipv4 nf_defrag_ipv6 14195 1 nf_conntrack_ipv6 pata_acpi 13027 0 pata_atiixp13157 0 r8169 48762 0 radeon696879 2 rfkill 21604 2 acer_wmi,cfg80211 serio_raw 13166 0 shpchp 33377 0 snd70580 12 snd_hda_codec_realtek,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_seq,snd_seq_device,snd_pcm,snd_timer snd_hda_codec 90103 2 snd_hda_codec_realtek,snd_hda_intel snd_hda_codec_realtek 326490 1 snd_hda_intel 28948 2 snd_hwdep 13556 1 snd_hda_codec snd_page_alloc 14039 2 snd_hda_intel,snd_pcm snd_pcm85160 2 snd_hda_intel,snd_hda_codec snd_seq57136 0 snd_seq_device 14129 1 snd_seq snd_timer 29082 2 snd_seq,snd_pcm soundcore 14523 1 snd sp5100_tco 13697 0 sparse_keymap 13526 1 acer_wmi stp12946 1 garp sunrpc217364 1 ttm61393 1 radeon uas17887 0 ums_realtek13111 0 usb_storage52228 1 ums_realtek uvcvideo 63505 0 v4l2_compat_ioctl3216677 1 videodev video 19130 0 videodev 76518 1 uvcvideo wmi18697 1 acer_wmi xt_state 12578 2 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: release 3.0-0.rc3.git0.3.fc16.x86_64=3.0.0 gives version code 196608 endless loop: microcode: CPU0: family 15 not supported
On 18/06/11 12:19, Cecil Funderburk wrote: I upgraded to release 3.0-0.rc3.git0.3.fc16.x86_64=3.0.0 gives version code 196608 Try: http://koji.fedoraproject.org/koji/buildinfo?buildID=248428 see if it fixes anything for you. -- Regards, Frank Murphy UTF_8 Encoded Friend of fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The behaviour of systemctl.
On Fri, 17.06.11 22:16, Aaron Sowry (aaron...@aeneby.se) wrote: Hello, Heya, I'd like to discuss the behaviour of systemctl. See RH bug 713567 for context. To summarise: - 'systemctl --all' pages by default when the output is to tty. This consumes 50-60+ lines of potentially bug-prone code, and irks the crap out of me as a system administrator. systemctl's jurisdiction ends at stdout. Well, I think in genreal the autopaging behaviour of git and other tools is very much appreciated. If you hate that behaviour then you are probably in the minority, and we have to agree to disagree on the benefits of this behaviour. Setting alias systemctl='systemctl --no-pager' is not particularly hard though. - The same command outputs column headers on tty, and no headers otherwise. This is inconsistent. If I am outputting to a file, or perhaps a printer, and want headers on my non-tty output, I have to add them myself since there is no flag to force them on non-tty channels. If I don't want them and they are present, I tail. I am pretty sure that if you ask us nicely, we'll add an option to enable headers nonetheless. It's however usually simpler if you pipe something not to have to use tail/head. - Currently, if I run 'systemctl --all' and have no pager (at least no pager that systemctl knows of) available, I get an error message and no output. This is horribly bad form, and forces me to use --no-pager or pipe to cat in order to get output. This issue is acknowledged in RH bug 713707. We generally do not support if people delete arbitrary things from their installation. /bin/more is part of util-linux, and if you delete that then you broke your system, so don't complain to us please. I am not saying we shouldn't make it possible to run without any pager installed. But does this matter? No, not at all. It doesn't have priority in any way. It's probably one of those cases where supplying us with a clean, minimal patch is the most compelling argument to make your point. Complaining on mailing lists not so much. - Another bright idea (RH bug 713567) is that --full should be applied to non-tty output automatically, and not to tty output. Yes, it actually makes sense and has been requested which is why we implemented it. All of these peculiarities stem from poor UNIX programming practise. I think all of these peculiarities stem from actually accepting progress. No other Linux/UNIX tools make this assumption (with perhaps the exception of git-log et. al.), and if you are wanting administrators to feel comfortable with your new soon-to-be-ubiquitous tools, then I suggest you try to be consistent with existing convention. I think you are mixing up administrators with Aaron Sowry. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The behaviour of systemctl.
On Sat, 18.06.11 10:46, Aaron Sowry (aaron...@aeneby.se) wrote: On Fri, Jun 17, 2011 at 04:31:08PM -0700, Jesse Keating wrote: The apps that I've seen where they do something special like paging the output by default, will not do that if the output is a non-active tty, such as a pipe. When you pipe it into something it'll react differently. Yes, and this is exactly the problem. When I run 'systemctl --all' on the tty, I get paging and column headers. When I pipe into something, I get no paging and no column headers. The assumption here is apparently that if the output is not going to tty then it is not destined for human eyes, which is an absolutely ridiculous assumption to make. If I output to a file so I can look at things later, I get no headers, and have no option to force them on non-tty output. This alone may seem fairly trivial, but the problem is that there are many of these trivialities, all of which seem to stem from authors who either don't understand UNIX programming, or are actively choosing to ignore convention. Seriously, if anybody suggests that the solution to the above problem is to add a '--force-headers' flag, I think I'm going to start using Windows. We need to start having this discussion before more of this stupid behaviour starts finding its way into other core components of Fedora. Supposedly non-UNIXy behaviour on Linux causes you to switch to Windows? Yeah, that makes sense! Awesome logic! Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The behaviour of systemctl.
On Sat, 18.06.11 13:02, Ville Skyttä (ville.sky...@iki.fi) wrote: On 06/18/2011 01:06 AM, Aaron Sowry wrote: n Fri, Jun 17, 2011 at 10:41:14PM +0100, Martin Dengler wrote: As you point out, git-log and --help do this too. It's excellent. Make it configurable if you must, but I'd be interested to think why you think it's not always the useful thing to do. The reasons why it's not the useful thing to do were pointed out in my previous email. I don't appreciate the default paging behavior at all either, but at least git gives me an easy global way to get rid of it: export GIT_PAGER=cat in ~/.bash_profile. systemctl does not seem to offer anything comparable (remembering to type --no-pager or setting $PAGER which affects other things do not count), or did I miss something? Ask us nicely and we'll add SYSTEMD_PAGER for you, taking precedence over PAGER. Even more convincing might be prepping a patch for this. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
systemctl F16\Rawhide RFE\Bug\My Ignorance?
In terminal systemctl status plymouth* returns no units. systemctl list-units returns too much What woul I use to list just a subsection, like plymouth* or any other similar services. -- Regards, Frank Murphy UTF_8 Encoded Friend of fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemctl F16\Rawhide RFE\Bug\My Ignorance?
On Sat, Jun 18, 2011 at 1:13 PM, Frank Murphy frankl...@gmail.com wrote: In terminal systemctl status plymouth* returns no units. systemctl list-units returns too much What woul I use to list just a subsection, like plymouth* or any other similar services. How about systemctl list-units| grep plymouth Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: scorched3d needs a new owner
On Sat, Jun 18, 2011 at 08:16:26 +0200, Hans de Goede hdego...@redhat.com wrote: Hi, I've not been able to give scorched3d the attention it deserves lately. Specifically it is lagging with upstream for a while now and really needs to be rebased to upstream latest. Is anyone willing to become a new (co)-maintainer for scorched3d and do the rebase? I signed up to be a co-maintainer. I should be able to work on a rebase over the next week or so. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemctl F16\Rawhide RFE\Bug\My Ignorance?
On 18/06/11 13:22, Peter Robinson wrote: snip How about systemctl list-units| grep plymouth Peter Unfortunatly gives nothing as a return, though there should be at least 4 services. systemctl list-units | grep systemd returns 14 services so grep works. -- Regards, Frank Murphy UTF_8 Encoded Friend of fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: scorched3d needs a new owner
On Sat, Jun 18, 2011 at 08:16:26 +0200, Hans de Goede hdego...@redhat.com wrote: Hi, I've not been able to give scorched3d the attention it deserves lately. Specifically it is lagging with upstream for a while now and really needs to be rebased to upstream latest. Is anyone willing to become a new (co)-maintainer for scorched3d and do the rebase? I see that the latest build is not compatible with previous versions. Probably this is good for playing other people, but bad for previously saved games. How far back do we want to push the update once it's ready? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemctl F16\Rawhide RFE\Bug\My Ignorance?
On 18/06/11 13:41, Ian Chapman wrote: On 18/06/11 20:36, Frank Murphy wrote: Unfortunatly gives nothing as a return, though there should be at least 4 services. What about systemctl --all | grep -i plymouth That did it, thank you. -- Regards, Frank Murphy UTF_8 Encoded Friend of fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The behaviour of systemctl.
On Sat, Jun 18, 2011 at 1:55 PM, Lennart Poettering mzerq...@0pointer.de wrote: I'd like to discuss the behaviour of systemctl. See RH bug 713567 for context. To summarise: - 'systemctl --all' pages by default when the output is to tty. This consumes 50-60+ lines of potentially bug-prone code, and irks the crap out of me as a system administrator. systemctl's jurisdiction ends at stdout. Well, I think in genreal the autopaging behaviour of git and other tools is very much appreciated. If you hate that behaviour then you are probably in the minority, and we have to agree to disagree on the benefits of this behaviour. While much of The UNIX way is folklore, some conventions for the (GNU/)Linux platform actually exist and have been explicitly documented, and they haven't disappeared only because git happens to ignore some of them. (info standards 'Program behavior' 'User Interfaces') Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The behaviour of systemctl.
On 06/18/2011 03:02 PM, Lennart Poettering wrote: Ask us nicely and we'll add SYSTEMD_PAGER for you, taking precedence over PAGER. Even more convincing might be prepping a patch for this. https://bugs.freedesktop.org/show_bug.cgi?id=38439 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GNOME3 and au revoir WAS: systemd: please stop trying to take over the world :)
On 06/17/2011 11:36 PM, Evandro Giovanini wrote: those who are want to rewrite/modify GNOME3. No, I'm not. There are several working extensions *today*, I'm simply suggesting that people not 100% satisfied with the default GNOME 3 experience go out there and experiment with them. It's definitely easier to install an extension even today than to migrate to an entirely different distribution with a completely different desktop environment and default set of applications. I don't agree with this at all - and you don't need to switch distros unless systemd drives you up the wall - its way easier to switch from Gnome 2 to KDE than it is to switch to Gnome 3/Shell + fiddling with extensions. You have no choice but to change DE's now - Gnome 3 is just one choice - the others may offer more functionality and be a simpler transition - as a Gnome user thats what I am finding. I'd say its definitely easier to change to KDE or XFCE than to Gnome 3hell (speaking as an F14 gnome 2 user). 3rd party extension stuff - who is checking the code for privacy/security issues anyway? From my perspective so far changing from Gnome-2 to KDE is an easier and less obstructive change than to Gnome 3hell. I have installed and plan to try LXDE and XFCE as well ... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The behaviour of systemctl.
On Sat, Jun 18, 2011 at 01:55:43PM +0200, Lennart Poettering wrote: - 'systemctl --all' pages by default when the output is to tty. This consumes 50-60+ lines of potentially bug-prone code, and irks the crap out of me as a system administrator. systemctl's jurisdiction ends at stdout. Well, I think in genreal the autopaging behaviour of git and other tools is very much appreciated. If you hate that behaviour then you are probably in the minority, and we have to agree to disagree on the benefits of this behaviour. Setting alias systemctl='systemctl --no-pager' is not particularly hard though. Setting aliases does not remove cruft code, or documentation for flags which don't need to exist. Flags should be used to enable functionality, not disable bloat. - The same command outputs column headers on tty, and no headers otherwise. This is inconsistent. If I am outputting to a file, or perhaps a printer, and want headers on my non-tty output, I have to add them myself since there is no flag to force them on non-tty channels. If I don't want them and they are present, I tail. I am pretty sure that if you ask us nicely, we'll add an option to enable headers nonetheless. It's however usually simpler if you pipe something not to have to use tail/head. Yet another flag to work around inconsistent behaviour is the last thing systemctl needs. Simplicity is not the issue here - you are assuming that output piped to something other than a tty is not destined for human eyes. I shouldn't have to convince you that this is nonsense, and will only get worse if --full is applied automatically to all non-tty output. Shall we add a --no-full flag to work around this, too? - Currently, if I run 'systemctl --all' and have no pager (at least no pager that systemctl knows of) available, I get an error message and no output. This is horribly bad form, and forces me to use --no-pager or pipe to cat in order to get output. This issue is acknowledged in RH bug 713707. We generally do not support if people delete arbitrary things from their installation. /bin/more is part of util-linux, and if you delete that then you broke your system, so don't complain to us please. It is difficult to concieve where systemd might end up in future. Is util-linux a systemd dependency? I am not saying we shouldn't make it possible to run without any pager installed. But does this matter? No, not at all. It doesn't have priority in any way. It may not be a priority, but nor should it even be an issue. - Another bright idea (RH bug 713567) is that --full should be applied to non-tty output automatically, and not to tty output. Yes, it actually makes sense and has been requested which is why we implemented it. This is being implemented now? All of these peculiarities stem from poor UNIX programming practise. I think all of these peculiarities stem from actually accepting progress. Subjective opinion. No other Linux/UNIX tools make this assumption (with perhaps the exception of git-log et. al.), and if you are wanting administrators to feel comfortable with your new soon-to-be-ubiquitous tools, then I suggest you try to be consistent with existing convention. I think you are mixing up administrators with Aaron Sowry. Not really. All other administrators use exactly the same tools I do, very few of which behave like systemctl. Having to deal with command-specific behaviour only makes it more difficult to learn a new tool. /Aaron signature.asc Description: Digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The behaviour of systemctl.
On Sat, 18.06.11 16:39, Aaron Sowry (aaron...@aeneby.se) wrote: - The same command outputs column headers on tty, and no headers otherwise. This is inconsistent. If I am outputting to a file, or perhaps a printer, and want headers on my non-tty output, I have to add them myself since there is no flag to force them on non-tty channels. If I don't want them and they are present, I tail. I am pretty sure that if you ask us nicely, we'll add an option to enable headers nonetheless. It's however usually simpler if you pipe something not to have to use tail/head. Yet another flag to work around inconsistent behaviour is the last thing systemctl needs. Simplicity is not the issue here - you are assuming that output piped to something other than a tty is not destined for human eyes. I shouldn't have to convince you that this is nonsense, and will only get worse if --full is applied automatically to all non-tty output. Shall we add a --no-full flag to work around this, too? You know, I'd prefer if you take up your beef with ls first. Have you ever compared the output of ls and of ls | cat? And that's just the most obvious case. Generating slightly different output on a tty than when used in another way is deeply rooted in Linux heritage. Autopaging is just a small step forward in that area. And a very welcome one. In this regard systemd is just following the evolution of Linux. We are not revolutionizing in this area, and we are not pioneering either. - Currently, if I run 'systemctl --all' and have no pager (at least no pager that systemctl knows of) available, I get an error message and no output. This is horribly bad form, and forces me to use --no-pager or pipe to cat in order to get output. This issue is acknowledged in RH bug 713707. We generally do not support if people delete arbitrary things from their installation. /bin/more is part of util-linux, and if you delete that then you broke your system, so don't complain to us please. It is difficult to concieve where systemd might end up in future. And how does that matter for Fedora? Is util-linux a systemd dependency? Yes, absolutely. systemd depends on util-linux for the gettys, for fsck, for mount, for umount, for swapoff, for swapon -- all these commands are more than just wrappers around kernel functionality and are pretty much the Linux API for the respective functionality. - Another bright idea (RH bug 713567) is that --full should be applied to non-tty output automatically, and not to tty output. Yes, it actually makes sense and has been requested which is why we implemented it. This is being implemented now? Hmm? Implicit --full when using a pager has been the default since quite some time in systemd. No other Linux/UNIX tools make this assumption (with perhaps the exception of git-log et. al.), and if you are wanting administrators to feel comfortable with your new soon-to-be-ubiquitous tools, then I suggest you try to be consistent with existing convention. I think you are mixing up administrators with Aaron Sowry. Not really. All other administrators use exactly the same tools I do, very few of which behave like systemctl. Having to deal with command-specific behaviour only makes it more difficult to learn a new tool. Yupp, as I see it it eases an administrator's life. I guess we just have to agree to disagree on this, and leave it at this. Sorry if that is disappointing. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: scorched3d needs a new owner
Hi, On 06/18/2011 02:23 PM, Bruno Wolff III wrote: On Sat, Jun 18, 2011 at 08:16:26 +0200, Hans de Goedehdego...@redhat.com wrote: Hi, I've not been able to give scorched3d the attention it deserves lately. Specifically it is lagging with upstream for a while now and really needs to be rebased to upstream latest. Is anyone willing to become a new (co)-maintainer for scorched3d and do the rebase? I signed up to be a co-maintainer. I should be able to work on a rebase over the next week or so. Great, thanks! I've granted you commit and approve acl rights. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: scorched3d needs a new owner
Hi, On 06/18/2011 02:34 PM, Bruno Wolff III wrote: On Sat, Jun 18, 2011 at 08:16:26 +0200, Hans de Goedehdego...@redhat.com wrote: Hi, I've not been able to give scorched3d the attention it deserves lately. Specifically it is lagging with upstream for a while now and really needs to be rebased to upstream latest. Is anyone willing to become a new (co)-maintainer for scorched3d and do the rebase? I see that the latest build is not compatible with previous versions. Probably this is good for playing other people, but bad for previously saved games. How far back do we want to push the update once it's ready? I think we want the update just for F-15. So that people who prefer to stick on the conservative side of things, who will likely still be running F-14, won't get it. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GNOME3 and au revoir WAS: systemd: please stop trying to take over the world :)
On Fri, Jun 17, 2011 at 8:29 AM, Adam Williamson awill...@redhat.com wrote: For more 'advanced' users, the keyboard shortcuts are there, and you're probably going to want to use them if you don't want to gnaw your own legs off out of boredom. No, they're not particularly discoverable: it's very difficult to design an interface which makes keyboard shortcuts discoverable without pissing you off once you know them. I mean, when have keyboard shortcuts ever been discoverable? Is alt-tab discoverable? Is alt-f4? No. We just pick them up somewhere and learn them. is everything that gnome shell can do exposed as a non-keyboard interactions? Can you describe to me how I get the screencasting utility to start and stop recording without using a keyboard shortcut? There's no evidence of that functionality is in the discoverable UI. I can forgive the Alt to poweroff because poweroff is still exposed in the login screen as a non-keyboard interaction option...so it's still exposed as a pointing device only feature in the expected interaction model of the overall system. But the screencaster utility isn't exposed a a discoverable pointing device interaction in the UI itself anywhere as far as I can tell..and that makes me marginally grumpy. But not as grumpy as the choice to use a 4 finger salute to activate it via the keyboard. If you want to ensure a 75% occurrence rate of fat-finger execution error...require 4 simultaneous key presses. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: scorched3d needs a new owner
On Sat, Jun 18, 2011 at 18:36:14 +0200, Hans de Goede hdego...@redhat.com wrote: I think we want the update just for F-15. So that people who prefer to stick on the conservative side of things, who will likely still be running F-14, won't get it. I have the easy stuff done already. Now I need to work on updating the syslibs patch. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The behaviour of systemctl.
Hi. On Sat, 18 Jun 2011 17:25:36 +0200, Lennart Poettering wrote another way is deeply rooted in Linux heritage. Autopaging is just a small step forward in that area. And a very welcome one. Do you have anything to back that claim up? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GNOME3 and au revoir WAS: systemd: please stop trying to take over the world :)
On Sat, 2011-06-18 at 08:42 -0800, Jeff Spaleta wrote: On Fri, Jun 17, 2011 at 8:29 AM, Adam Williamson awill...@redhat.com wrote: For more 'advanced' users, the keyboard shortcuts are there, and you're probably going to want to use them if you don't want to gnaw your own legs off out of boredom. No, they're not particularly discoverable: it's very difficult to design an interface which makes keyboard shortcuts discoverable without pissing you off once you know them. I mean, when have keyboard shortcuts ever been discoverable? Is alt-tab discoverable? Is alt-f4? No. We just pick them up somewhere and learn them. is everything that gnome shell can do exposed as a non-keyboard interactions? Can you describe to me how I get the screencasting utility to start and stop recording without using a keyboard shortcut? There's no evidence of that functionality is in the discoverable UI. I can forgive the Alt to poweroff because poweroff is still exposed in the login screen as a non-keyboard interaction option...so it's still exposed as a pointing device only feature in the expected interaction model of the overall system. But the screencaster utility isn't exposed a a discoverable pointing device interaction in the UI itself anywhere as far as I can tell..and that makes me marginally grumpy. But not as grumpy as the choice to use a 4 finger salute to activate it via the keyboard. If you want to ensure a 75% occurrence rate of fat-finger execution error...require 4 simultaneous key presses. That's a pretty unique example. It's really not core desktop functionality; it's an easter egg, really. I think it was initially put in purely for the use of GNOME PR / documentation people, and left in because it wasn't hurting anything, and reviewers might like 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: GNOME3 and au revoir WAS: systemd: please stop trying to take over the world :)
On Sat, Jun 18, 2011 at 9:55 AM, Adam Williamson awill...@redhat.com wrote: That's a pretty unique example. It's really not core desktop functionality; it's an easter egg, really. I think it was initially put in purely for the use of GNOME PR / documentation people, and left in because it wasn't hurting anything, and reviewers might like it. Just to be clear, eould you also consider the binding the Prnt Scrn labeled keyboard key to the screenshot took as non-core easter egg functionality? -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Self Introduction
On 18/06/11 11:20, Paul Flo Williams wrote: She might have been half joking. Although packaging fonts is theoretically easy because of the packaging templates we use, the state of upstream archives is often very poor, with no clear versioning, missing licenses and limited language coverage. Welcome :-) Yes that is what I was thinking as well after looking at a few other fonts on the wishlist. Upstream could be anybody producing and releasing fonts with no set policy for releases or versioning in place. A foundry is an organisation or single person who issues fonts. The League of Moveable Type is one such, and our foundry abbreviation for them is tlomt. You'll find some of their other fonts have been packaged already, so taking a look at those src.rpms may give you some pointers. Thanks, I guessed 'tlomt' as well which I guess was correct then. I didn't know there were some already packaged, looking through those .src.rpms would be hugely helpful. If you look through the wiki pages of fonts that have already been packaged, you'll find the bugzilla numbers of their review requests, and looking through some of the comments in those reviews will help you avoid common mistakes. Yes, that is the other thing I was wondering about and I will look it up. I would recommend you join the fonts mailing list if you have further questions. I have already done so and have joined the 'fonts-bugs' one as well just in case. Thanks for the welcome, Paul. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: appletalk+psnap+ipx modules in the kernel-3.0-0.rc3.git5.1.fc16
On Sat, Jun 18, 2011 at 12:54:14PM +0400, Lucas wrote: Dear All I have installed the latest kernel from koji and found out that now I have 3 new modules: appletalk psnap ipx I know what is IPX. But do we really need to have AppleTalk always loaded in the kernel? Protocols get auto-loaded when something tries to open a socket belonging to that family, or when a packet is recieved from the network. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The behaviour of systemctl.
On Sat, Jun 18, 2011 at 05:25:36PM +0200, Lennart Poettering wrote: You know, I'd prefer if you take up your beef with ls first. Have you ever compared the output of ls and of ls | cat? And that's just the most obvious case. Yes, but the difference here is that ls does not re-implement something that is already available at the command line. Generating slightly different output on a tty than when used in another way is deeply rooted in Linux heritage. Autopaging is just a small step forward in that area. Not sure I agree, but okay. And how does that matter for Fedora? It doesn't I guess, but are you writing systemd for Fedora, or as a general replacement for SysV init? Is util-linux a systemd dependency? Yes, absolutely. systemd depends on util-linux for the gettys, for fsck, for mount, for umount, for swapoff, for swapon -- all these commands are more than just wrappers around kernel functionality and are pretty much the Linux API for the respective functionality. Sure, but as far as I can tell, util-linux is not in the dependency list. Hmm? Implicit --full when using a pager has been the default since quite some time in systemd. Strange - I'm not seeing it in systemd-units-26-3.fc15.x86_64. Not really. All other administrators use exactly the same tools I do, very few of which behave like systemctl. Having to deal with command-specific behaviour only makes it more difficult to learn a new tool. Yupp, as I see it it eases an administrator's life. I guess we just have to agree to disagree on this, and leave it at this. Sorry if that is disappointing. It is disappointing. Specifics aside, my general point is that administrators don't need hand-holding and understand that there are pagers available for use outside of the program itself. Imposing behaviour on users only results in the problems I've pointed out previously - inconsistent output, inconsistent behaviour, additional code, additional dependencies, unnecessary flags, learning curve, non-portability, and so on ad nauseum. I'd love to see it change, I'd even submit a patch but I'm afraid it would fall on deaf ears. Thanks for taking the time to respond, anyway. /Aaron signature.asc Description: Digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The behaviour of systemctl.
On Sat, 18.06.11 21:52, Aaron Sowry (aaron...@aeneby.se) wrote: On Sat, Jun 18, 2011 at 05:25:36PM +0200, Lennart Poettering wrote: You know, I'd prefer if you take up your beef with ls first. Have you ever compared the output of ls and of ls | cat? And that's just the most obvious case. Yes, but the difference here is that ls does not re-implement something that is already available at the command line. Hmm??? And how does that matter for Fedora? It doesn't I guess, but are you writing systemd for Fedora, or as a general replacement for SysV init? But what's the point of discussing this on fedora-devel then? Yes, absolutely. systemd depends on util-linux for the gettys, for fsck, for mount, for umount, for swapoff, for swapon -- all these commands are more than just wrappers around kernel functionality and are pretty much the Linux API for the respective functionality. Sure, but as far as I can tell, util-linux is not in the dependency list. The README of systemd lists it pretty explicitly including a version number. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GNOME3 and au revoir WAS: systemd: please stop trying to take over the world :)
On Sat, 2011-06-18 at 10:00 -0800, Jeff Spaleta wrote: Just to be clear, eould you also consider the binding the Prnt Scrn labeled keyboard key to the screenshot took as non-core easter egg functionality? Probably not, but I wouldn't say they're equivalent. I don't think many people expect their desktop to have a screen recorder built in. I can't think of any other desktop that _does_. When I said Shell was fully mouse accessible I was talking about typical operations, not every single thing it's potentially capable of. I'm really not sure what the point of this side track is; what does anyone gain by you picking very small holes in my generalization? -- 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
[perl-CGI-Application] Update to 4.50, spec clean-up
commit a0f3268585b7dc2d16897540700f15de3fa6fd98
Author: Emmanuel Seyman emmanuel.sey...@club-internet.fr
Date: Sat Jun 18 10:56:31 2011 +0200
Update to 4.50, spec clean-up
.gitignore|1 +
perl-CGI-Application.spec | 13 ++---
sources |2 +-
3 files changed, 8 insertions(+), 8 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 8055382..db28b06 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
CGI-Application-4.31.tar.gz
+/CGI-Application-4.50.tar.gz
diff --git a/perl-CGI-Application.spec b/perl-CGI-Application.spec
index 0f6dad4..6a54e26 100644
--- a/perl-CGI-Application.spec
+++ b/perl-CGI-Application.spec
@@ -1,12 +1,11 @@
Name: perl-CGI-Application
-Version:4.31
-Release:6%{?dist}
+Version:4.50
+Release:1%{?dist}
Summary:Framework for building reusable web-applications
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/CGI-Application/
Source0:
http://search.cpan.org/CPAN/authors/id/M/MA/MARKSTOS/CGI-Application-%{version}.tar.gz
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
BuildRequires: perl(CGI)
BuildRequires: perl(Class::ISA)
@@ -43,16 +42,16 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {}
2/dev/null \;
%check
./Build test
-%clean
-rm -rf $RPM_BUILD_ROOT
-
%files
-%defattr(-,root,root,-)
%doc ARTISTIC Changes GPL README
%{perl_vendorlib}/*
%{_mandir}/man3/*
%changelog
+* Sat Jun 18 2011 Emmanuel Seyman emmanuel.sey...@club-internet.fr - 4.50-1
+- Update to 4.50
+- Spec clean-up
+
* Sat May 14 2011 Iain Arnell iarn...@gmail.com 4.31-6
- Add perl(CGI) to Requires too.
diff --git a/sources b/sources
index ea01910..a9d39e9 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-502cb5785a291ed65869eb663eb01999 CGI-Application-4.31.tar.gz
+356595b6f12373f57243a7e605b9cd43 CGI-Application-4.50.tar.gz
--
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
Broken dependencies: perl-BerkeleyDB
perl-BerkeleyDB has broken dependencies in the rawhide tree: On x86_64: perl-BerkeleyDB-0.43-5.fc15.x86_64 requires libdb = 0:5.1.25 perl-BerkeleyDB-0.43-5.fc15.x86_64 requires libdb-5.1.so()(64bit) On i386: perl-BerkeleyDB-0.43-5.fc15.i686 requires libdb = 0:5.1.25 perl-BerkeleyDB-0.43-5.fc15.i686 requires libdb-5.1.so Please resolve this as soon as possible. -- 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
