Re: Doc dir related changes coming up
On 07/23/2013 10:22 PM, Ville Skyttä wrote: Hello, Related to the unversioned docdirs F-20 feature [1], some changes with doc packages will be needed in a bunch of packages. More info will follow later, but I've started looking into the list of affected ones. Some related things are still being discussed on the packaging@ mailing list. While assembling the list, I'll check which packages can be easily and cleanly made independent of whether their docs install into versioned or unversioned doc dirs, and will push and build those trivial changes to rawhide already now. [1] https://fedoraproject.org/wiki/Changes/UnversionedDocdirs May I ask what is the decision about %doc macro in rawhide? Is it supposed to work as it is? Then we should fix it. Is it supposed to not use? Then remove it. Or am I missing something? RR -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Doc dir related changes coming up
On 08/05/2013 09:38 AM, Roman Rakus wrote: On 07/23/2013 10:22 PM, Ville Skyttä wrote: Hello, Related to the unversioned docdirs F-20 feature [1], some changes with doc packages will be needed in a bunch of packages. More info will follow later, but I've started looking into the list of affected ones. Some related things are still being discussed on the packaging@ mailing list. While assembling the list, I'll check which packages can be easily and cleanly made independent of whether their docs install into versioned or unversioned doc dirs, and will push and build those trivial changes to rawhide already now. [1] https://fedoraproject.org/wiki/Changes/UnversionedDocdirs May I ask what is the decision about %doc macro in rawhide? Is it supposed to work as it is? Then we should fix it. Is it supposed to not use? Then remove it. Or am I missing something? RR Please, ignore - PEBKAC RR -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Set bash's shell option nullglob by default?
Hi, I have a question about nullglob bash's shell option. I want to hear opinions. The behavior is nicely described in bash reference manual [1] By default, the nullglob is turned off. And it tends people to use bad habits in shell scripting. In my POV the nullglob could be turned on by default. However, i would like to hear opinions from others. It is possible it can break many scripts even in rpm's scriptlets, but as I already said, it's because bad habits. So the main gain will be the people will learn how is the globbing in bash and in the whole environment working. RR [1] http://www.gnu.org/software/bash/manual/bashref.html#Filename-Expansion -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Set bash's shell option nullglob by default?
On 07/13/2012 02:06 PM, Scott Schmit wrote: So ls *.foo should list the entire directory if no files match *.foo? It's a bad habit for me to expect ls *.foo to return nothing in this case? You're going to need to convince me. And if there are directories ending with .foo? Hopefully you are not using such things in scripts. OK, in interactive shells `ls *' is not that wrong. printf '%s\n' *.foo for file in *.foo; do ... done RR -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Set bash's shell option nullglob by default?
On 07/13/2012 02:19 PM, Tomas Mraz wrote: This could cause serious surprising breakages of scripts with strange consequences. I'm strictly against this change. If something at all should be changed in this regard to break bad habits then it should be the failglob option although I am not convinced that it is too good idea either. I was thinking about failglob also, but it is not that useful like it looks. for name in *; do ...; done In the current state, if there isn't any file, the name variable will contain *. With nullglob name will be empty and script continues after the for loop. With failglob it will print error message. I think it is not useful. But you are right, it will cause many breakages (even surprising). RR -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PATH=/usr/local/bin:/bin:/usr/bin considered harmful
On 06/22/2012 05:15 AM, Sam Varshavchik wrote: [root@octopus ~]# strings /bin/bash | grep usr.bin /usr/local/bin:/bin:/usr/bin I think that bash needs to be recompiled, with the last two flipped, in the default shell PATH. The path above is used by bash only if PATH env variable is not set. RR -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F18 feature: MiniDebugInfo
On 05/08/2012 08:15 AM, Alexander Larsson wrote: On Mon, 2012-05-07 at 18:55 +0100, Peter Robinson wrote: On Mon, May 7, 2012 at 2:07 PM, Alexander Larsson al...@redhat.com wrote: I just wrote a new Feature proposal for shipping minimal debug info by default: https://fedoraproject.org/wiki/Features/MiniDebugInfo The feature page lists some of the background and statistics. It also lists some options in how to implement this, which all have various different pros and cons. I'd like to hear what peoples opinions on these are. My personal opinion is that we should go with compressed data, in the original files without the line number information. This means we use minimal space (i.e. an installation increase by only 0.5%) while being completely transparent to users. It does however make the normal packages larger in a non-optional way which some people disagree with. What sort of size impact are we talking about here, there's a lot of devices that people are starting to use Fedora on such as ARM devices that don't have a lot of storage space. One of the most widely deployed devices running Fedora for example is the OLPC XO-1 which only has 1gb of space so every size increase is a hit and Fedora is already starting to have quite a large muffin top to deal with. See the feature page for detail on the space use. On my F17 desktop install with and 8 gigabytes /usr it would add 43 megabytes of data. What about to not install it by default but as optional? RR -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
On 05/31/2012 12:18 PM, Lennart Poettering wrote: On Wed, 30.05.12 19:04, Garrett Holmstrom (gho...@fedoraproject.org) wrote: If you have an explicit /tmp entry in fstab things should continue to work the same as before. If you don't then you will now get a tmpfs on /tmp by default. What does an fstab entry that means, leave /tmp on the / filesystem, look like? See the feature page. To turn this feature off, do: systemctl mask tmp.mount Lennart Is enough to edit /etc/fstab? If not, why? Any benefits to have it directly in systemd? RR -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Apple will use LLVM
On 02/23/2012 05:32 PM, Jakub Jelinek wrote: On Thu, Feb 23, 2012 at 05:26:25PM +0100, Roman Rakus wrote: On 02/22/2012 09:08 AM, Jakub Jelinek wrote: On Wed, Feb 22, 2012 at 08:46:19AM +0100, Roman Rakus wrote: On 02/16/2012 05:33 PM, Jakub Jelinek wrote: For just -O3 or -O2 -ftree-vectorize we could perhaps have some knob in the spec files to request those extra flags, for PGO it really requires some work from the packager (but e.g. bash/grep/awk, perhaps perl/python etc. would definitely improve, gcc itself is already built with PGO). What kind of work? I have tried to build bash with added -O2 -ftree-vectorize -fprofile-generate, but the build fails with many undefined reference to `__gcov_*. That would be probably because -lgcov isn't linked in. When using -fprofile-generate, you need to pass that switch not just during compilation, but also when linking the binaries (or libraries) that contain -fprofile-generate compiled objects. Jakub Thanks. Anyone who wants to try/test such built bash can use my builds which I copied to fedorapeople [1]. It was built using mock. Any comments, test results are welcome. [1] http://rrakus.fedorapeople.org/bash-PGO/ You are compiling with 'CPPFLAGS=-D_GNU_SOURCE -DRECYCLES_PIDS -O2 -ftree-vectorize -fprofile-generate -fprofile-use' That doesn't make sense. You need to build twice. Step 1) build with -fprofile-generate (other flags the same in both builds) Step 2) run the program on some typical workload (make check, some large configure script you want to ptimize for, the closer it is to what people will use it for, the better) Step 3) make clean the *.o file, keep around the *.gcda files step 2) generated, build again, this time with -fprofile-use Jakub Results are at http://rrakus.fedorapeople.org/bash-PGO/ RR -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PyXML package - deprecate it?
On 02/23/2012 04:54 PM, Toshio Kuratomi wrote: On Tue, Feb 21, 2012 at 06:48:11PM +0100, Roman Rakus wrote: Hi all, looks like PyXML package is deprecated since python itself provides xml mechanisms. When you look deeper, python's xml provides: dom, parsers, sax, etree and PyXML provides: 'dom', 'marshal', 'parsers', 'sax', 'schema', 'utils', 'xpath', 'xslt' So, PyXML duplicates dom, parsers and sax (and looks like python's is in better shape). Is any package using marshall, schema or any other not in python itself? Deprecate PyXML or just remove duplicated parts? It's not as simple as saying that a library provides something that has the same names as modules in the stdlib, you also have to figure out compatibility and whether removing it will cause any problems for software that Fedora ships. Looking at the sourceforge page, the authors of PyXML are heavily involved in python core development so it's likely that they worked to merge the useful bits of PyXML into the stdlib before they abandoned it: http://sourceforge.net/projects/pyxml/ However, it also looks like PyXML is a collection of works that the sourceforge authors didn't necessarily originate. With that in mind, they may not have been able to get permission of the various original authors to merge a particular module into the python stdlib. However, there may exist independent upstream versions of those modules that would be better to ship than shipping PyXML in those cases. The best way to proceed is likely similar to how I looked at whether it would be okay to retire python-sqlite2: Take all the packages that depend on PyXML and grep through their sources to find where they use the PyXML modules (rpm -ql PyXML shows that everything in PyXML is in an _xmlplus python package so you'll see things like import _xmlplus.dom and from _xmlplus import dom. grepping for _xmlplus will probably work). In some cass, you'll likely find this was an old dep and the source no longer uses it. Others may be conditionalized: try: from xml import sax except ImportError: from _xmlplus import sax Look at stdlib xml - it tries to import _xmlplus. And it will replace stdlib with nonstd. It's kind of what?. I can try to report bug on it. Testing these packages to know that they behave properly is good but at least you can be confident that the upstream code is intended to work with the stdlib modules instead of the PyXML modules. If you find any code that's using _xmlplus unconditionally, you'll have to write patches to use the stdlib or separate modules. Then test your changes and send the patches upstream. Given the upstream note that PyXML is deprecated and the authors do not intend for people to use it, this category would hopefully be very small. But you won't know until you look. -Toshio Currently I'm going through packages and using pylint on *.py files on %preped sources. And using --deprecated-modules option of pylint. I will post results, report bugs and so on... Anyway, you're right that better is to ask upstream how different are stdlib and _xmlplus. RR -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Apple will use LLVM
On 02/22/2012 09:08 AM, Jakub Jelinek wrote: On Wed, Feb 22, 2012 at 08:46:19AM +0100, Roman Rakus wrote: On 02/16/2012 05:33 PM, Jakub Jelinek wrote: For just -O3 or -O2 -ftree-vectorize we could perhaps have some knob in the spec files to request those extra flags, for PGO it really requires some work from the packager (but e.g. bash/grep/awk, perhaps perl/python etc. would definitely improve, gcc itself is already built with PGO). What kind of work? I have tried to build bash with added -O2 -ftree-vectorize -fprofile-generate, but the build fails with many undefined reference to `__gcov_*. That would be probably because -lgcov isn't linked in. When using -fprofile-generate, you need to pass that switch not just during compilation, but also when linking the binaries (or libraries) that contain -fprofile-generate compiled objects. Jakub Thanks. Anyone who wants to try/test such built bash can use my builds which I copied to fedorapeople [1]. It was built using mock. Any comments, test results are welcome. [1] http://rrakus.fedorapeople.org/bash-PGO/ RR -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Apple will use LLVM
On 02/23/2012 05:32 PM, Jakub Jelinek wrote: On Thu, Feb 23, 2012 at 05:26:25PM +0100, Roman Rakus wrote: On 02/22/2012 09:08 AM, Jakub Jelinek wrote: On Wed, Feb 22, 2012 at 08:46:19AM +0100, Roman Rakus wrote: On 02/16/2012 05:33 PM, Jakub Jelinek wrote: For just -O3 or -O2 -ftree-vectorize we could perhaps have some knob in the spec files to request those extra flags, for PGO it really requires some work from the packager (but e.g. bash/grep/awk, perhaps perl/python etc. would definitely improve, gcc itself is already built with PGO). What kind of work? I have tried to build bash with added -O2 -ftree-vectorize -fprofile-generate, but the build fails with many undefined reference to `__gcov_*. That would be probably because -lgcov isn't linked in. When using -fprofile-generate, you need to pass that switch not just during compilation, but also when linking the binaries (or libraries) that contain -fprofile-generate compiled objects. Jakub Thanks. Anyone who wants to try/test such built bash can use my builds which I copied to fedorapeople [1]. It was built using mock. Any comments, test results are welcome. [1] http://rrakus.fedorapeople.org/bash-PGO/ You are compiling with 'CPPFLAGS=-D_GNU_SOURCE -DRECYCLES_PIDS -O2 -ftree-vectorize -fprofile-generate -fprofile-use' That doesn't make sense. You need to build twice. Step 1) build with -fprofile-generate (other flags the same in both builds) Step 2) run the program on some typical workload (make check, some large configure script you want to ptimize for, the closer it is to what people will use it for, the better) Step 3) make clean the *.o file, keep around the *.gcda files step 2) generated, build again, this time with -fprofile-use Jakub I see. Thanks. Will try. RR -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PyXML package - deprecate it?
On 02/22/2012 11:11 AM, Matej Cepl wrote: On 21.2.2012 18:48, Roman Rakus wrote: So, PyXML duplicates dom, parsers and sax (and looks like python's is in better shape). Is any package using marshall, schema or any other not in python itself? Deprecate PyXML or just remove duplicated parts? What packages require PyXML? Could they be rebuilt just with xml tools in stock Python (I think so)? Did you try? Matěj I guess rebuilding isn't enough. Only running affected scripts can show errors. Packages requiring PyXML in F16 follows: $ repoquery --whatrequires PyXML SOAPpy-0:0.11.6-12.fc16.noarch bkchem-0:0.14.0-3.pre2.fc15.noarch comoonics-cdsl-py-0:0.2-18.noarch comoonics-cluster-py-0:0.1-24.noarch fedora-business-cards-0:0.2.4.3-2.fc15.noarch grc-0:0.70-7.fc15.noarch heartbeat-0:3.0.4-1.fc15.1.x86_64 inksmoto-0:0.7.0-5.fc15.noarch libopensync-plugin-google-calendar-1:0.22-5.fc15.x86_64 openxcap-0:1.1.2-3.fc15.noarch pida-0:0.5.1-13.fc15.x86_64 pypar2-0:1.4-7.fc15.noarch python-MythTV-0:0.24.1-4.fc16.x86_64 python-MythTV-0:0.24.2-1.fc16.x86_64 python-ZSI-0:2.0-9.fc15.noarch python-nova-0:2011.3-4.fc16.noarch python-nova-0:2011.3.1-2.fc16.noarch python-webdav-library-0:0.3.0-1.fc16.noarch salt-0:0.9.6-2.fc16.noarch spacewalk-backend-tools-0:1.4.39-1.fc16.noarch subscription-manager-0:0.99.4-1.fc16.x86_64 synce-sync-engine-0:0.15.1-1.fc16.x86_64 xen-0:4.1.1-8.fc16.x86_64 xen-0:4.1.2-6.fc16.x86_64 zeroinstall-injector-0:1.2-1.fc16.noarch RR -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
PyXML package - deprecate it?
Hi all, looks like PyXML package is deprecated since python itself provides xml mechanisms. When you look deeper, python's xml provides: dom, parsers, sax, etree and PyXML provides: 'dom', 'marshal', 'parsers', 'sax', 'schema', 'utils', 'xpath', 'xslt' So, PyXML duplicates dom, parsers and sax (and looks like python's is in better shape). Is any package using marshall, schema or any other not in python itself? Deprecate PyXML or just remove duplicated parts? RR -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Apple will use LLVM
On 02/16/2012 05:33 PM, Jakub Jelinek wrote: For just -O3 or -O2 -ftree-vectorize we could perhaps have some knob in the spec files to request those extra flags, for PGO it really requires some work from the packager (but e.g. bash/grep/awk, perhaps perl/python etc. would definitely improve, gcc itself is already built with PGO). What kind of work? I have tried to build bash with added -O2 -ftree-vectorize -fprofile-generate, but the build fails with many undefined reference to `__gcov_*. You can see the build log in koji [1]. [1] http://koji.fedoraproject.org/koji/getfile?taskID=3809343name=build.log RR -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: grub2 and setting crashkernel kernel argument
On 11/28/2011 06:20 PM, Frank Ch. Eigler wrote: Roman Rakusrra...@redhat.com writes: How are fedora with grub2 users supposed to set up crashkernel kernel argument? [...] Does GRUB_CMDLINE_LINUX=crashkernel=auto in /etc/default/grub work, followed by grub2-mkconfig? - FChE I thought that `auto' option was never used in Fedora. RR -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: grub2 and setting crashkernel kernel argument
On 11/28/2011 04:30 PM, Roman Rakus wrote: How are fedora with grub2 users supposed to set up crashkernel kernel argument? Or even any argument? Writing own script for it? I'm asking because I'm maintaining system-config-kdump and I'm not sure how to ensure this. RR Thanks all for answers. And I will get back to this point. I will change GRUB_CMDLINE_LINUX variable and run grub2-mkconfig. Hopefully it will not brake anything. RR -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
grub2 and setting crashkernel kernel argument
How are fedora with grub2 users supposed to set up crashkernel kernel argument? Or even any argument? Writing own script for it? I'm asking because I'm maintaining system-config-kdump and I'm not sure how to ensure this. RR -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Changing default setting of bash's hash table?
Maybe the subject is a bit misleading, I will clarify it. Bash is using hash table to remember locations of executed commands. Whenever you try to run a command bash looks in hash table. When the command is found in table then bash will you full path name as it is in the table. However there is a problem when the command moved (or is deleted). Bash by default is not checking if the command is really on the location. But there is bash option that will force bash to check if the command really exists. Man page says: checkhash If set, bash checks that a command found in the hash ta‐ ble exists before trying to execute it. If a hashed command no longer exists, a normal path search is per‐ formed. I have a question, if it is worth to enable this option by default? It will not confuse some people, but can increase disk searching. Comments welcome. RR -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding ~/.local/bin to default PATH
Hi all, from the discussion here, I'm tempted to revert the change. Any objections? RR -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Grubby and Xen
On 07/25/2011 04:38 AM, W. Michael Petullo wrote: I have been working with a few other Fedora contributors on the Fedora 16 feature XenPvopsDom0, http://fedoraproject.org/wiki/Features/XenPvopsDom0. This feature would provide a robust virtualization alternative based on Xen. Xen is a type-1, hypervisor-based platform and therefore has some different properties than KVM, et al. One of the integration points we'd like to improve has to do with grubby. As it is hypervisor-based, Xen requires grub to be configured a little differently than bare-metal Linux. In summary, where bare-metal Linux needs: kernel /boot/vmlinuz-... initrd /boot/initramgs-... Xen requires: kernel /boot/xen.gz module /boot/vmlinuz-... module /boot/initramfs-... There are two bugs in Bugzilla related to this: 658387, Patch to allow mbkernel and mbargs to be read from /etc/sysconfig/kernel 668063, Grubby does not handle template that uses module keyword properly Is anyone who is a grubby contributor interested in adding these features to grubby to support the XenPvopsDom0 feature? I've provided a patch in bug #658387. Thanks, Is it possible to use augeas [1]? There is currently lens for grub.conf [1] http://augeas.net/ RR -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bash evaluation change...
On 03/03/2011 09:03 PM, Nathanael D. Noblet wrote: On 03/03/2011 12:42 PM, Will Woods wrote: On Wed, 2011-03-02 at 22:55 -0800, Toshio Kuratomi wrote: Hi guys. I'd say, report this as a bug and see where it leads. It's certainly not expected behaviour even if it is intentional. Already reported. One-line reproducer: case x in x) echo matches x;; x?) echo matches x? but not x;; esac I notice the bash-4.2 CHANGES file[1] mentions something like this in the changes from alpha to beta: b. Fixed a bug that caused partially-quoted words that were not subject to word splitting to retained quoted NULLs. Maybe that's not as fixed as they thought? Yeah, got the following from the bash-bug list that Roman submitted. Here's a fix. This is very similar to bash42-004. Chet *** ../bash-4.2-patched/subst.c 2011-02-25 12:03:58.0 -0500 --- subst.c 2011-03-03 14:08:23.0 -0500 *** *** 4609,4614 --- 4611,4617 if (ifs_firstc == 0) #endif word-flags |= W_NOSPLIT; + word-flags |= W_NOSPLIT2; result = call_expand_word_internal (word, quoted, 0, (int *)NULL, (int *)NULL); expand_no_split_dollar_star = 0; So I presume it'll make its way into a newer bash eventually?? Not sure on the process but it looks like the powers that be recognize and have a fix for it. Yep, this patch is from upstream. I will apply it soon. You can track the issue in bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=681940 RR -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Unable to build in koji for rawhide
https://koji.fedoraproject.org/koji/taskinfo?taskID=2890468 Any suggestions? RR -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unable to build in koji for rawhide
On 03/07/2011 04:43 PM, Roman Rakus wrote: https://koji.fedoraproject.org/koji/taskinfo?taskID=2890468 Any suggestions? RR I should read more before asking. The answer is: Missing one patch. RR -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora - Cold Boot Attack
On 11/08/2010 03:12 PM, Gregory Maxwell wrote: Here is the attack: Your system is running with nice secure encrypted drives, no console access (or a locked screen on a laptop). The attacker inserts a bootable USB key and hits the power switch. System reboots into the USB key, it retrieves the cryptographic keys for reading your disk from memory, then copies whatever information it likes. Only if the laptop is configured to boot from the USB. But I know, everything here is theoretical. RR -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yet another git problem
On 09/16/2010 04:21 PM, Neal Becker wrote: Updating igraph to 0.5.4. Success for devel and f14. Then for f13 I get: fedpkg switch-branch f13 Branch f13 set up to track remote branch f13/master from origin. git merge master CONFLICT (rename/delete): Rename .cvsignore-.gitignore in HEAD and deleted in master Automatic merge failed; fix conflicts and then commit the result. Strange, that seems to be the same thing I did for f14. How do I fix? What are you trying to do? I guess `git cherry-pick' will work for you. RR -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Hibernation causing many crashes; get a rid of it
On 04/06/2010 06:17 PM, Rahul Sundaram wrote: If you got bugs in your software, fix it. What's wrong with hibernation? That's what I don't know. I know nearly nothing about hibernation. I have mark bugs as duplicates and reassigned it to kernel guys. See https://bugzilla.redhat.com/show_bug.cgi?id=551570. RR -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
bash 4.1.2 and broken regular expression matching conditional operator (=~)
Hi all,
please take a look at bash faq section E - E14. Quoting:
E14) Why does quoting the pattern argument to the regular expression matching
conditional operator (=~) cause regexp matching to stop working?
In versions of bash prior to bash-3.2, the effect of quoting the regular
expression argument to the [[ command's =~ operator was not specified.
The practical effect was that double-quoting the pattern argument required
backslashes to quote special pattern characters, which interfered with the
backslash processing performed by double-quoted word expansion and was
inconsistent with how the == shell pattern matching operator treated
quoted characters.
In bash-3.2, the shell was changed to internally quote characters in single-
and double-quoted string arguments to the =~ operator, which suppresses the
special meaning of the characters special to regular expression processing
(`.', `[', `\', `(', `), `*', `+', `?', `{', `|', `^', and `$') and forces
them to be matched literally. This is consistent with how the `==' pattern
matching operator treats quoted portions of its pattern argument.
Since the treatment of quoted string arguments was changed, several issues
have arisen, chief among them the problem of white space in pattern arguments
and the differing treatment of quoted strings between bash-3.1 and bash-3.2.
Both problems may be solved by using a shell variable to hold the pattern.
Since word splitting is not performed when expanding shell variables in all
operands of the [[ command, this allows users to quote patterns as they wish
when assigning the variable, then expand the values to a single string that
may contain whitespace. The first problem may be solved by using backslashes
or any other quoting mechanism to escape the white space in the patterns.
Please, take a look in your bash scripts and fix them.
RR
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
