On Thu 24 May 2012 08:33:32 AM EDT, Bruno Friedmann wrote:

On Thursday 24 May 2012 06.31:21 Stephan Kulow wrote:

...

Hi,

As we have no real estimate when the build service will be in a working state again, I can't forecast when we will have the first builds to test either.

This is something that I did not expect - our servers really do not like 12.2 to be released ;(

Greetings, Stephan

<joke mode>Next time think twice before giving a bug name to a release :-)</mode>

And 12.2 will be celebrating the 20th anniversary. ;-) -- Cheers! Roman --------------------------------------------------------------- openSUSE -- Get it! Discover it! Share it! --------------------------------------------------------------- http://linuxcounter.net/ #179293 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Monday 28 May 2012 16.12:55 johann Luce wrote:

Le 24/05/2012 17:19, Roman Bysh a écrit :

...

On Thu 24 May 2012 08:33:32 AM EDT, Bruno Friedmann wrote:

...

On Thursday 24 May 2012 06.31:21 Stephan Kulow wrote:

...

Hi,

As we have no real estimate when the build service will be in a working state again, I can't forecast when we will have the first builds to test either.

This is something that I did not expect - our servers really do not like 12.2 to be released ;(

Greetings, Stephan

<joke mode>Next time think twice before giving a bug name to a release :-)</mode>

And 12.2 will be celebrating the 20th anniversary. ;-)

-- Cheers!

Roman --------------------------------------------------------------- openSUSE -- Get it! Discover it! Share it! --------------------------------------------------------------- http://linuxcounter.net/ #179293 hi

is there some news about 12.2 béta version ??

thanks

Johann

Did you see something happening on obs monitor, openqa, fixed the opened bugs. Don't count on other during a long holiday week-end. (Monday off) -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch openSUSE Member & Ambassador GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 28.05.2012 18:51, schrieb Larry Finger:

According to openqa, the Live CDs for Build 0386 boot and run. Installation of Gnome failed on at least one run because package mdadm was not available. Although I could not find a successful KDE Live CD run at openqa, one was just reported here by Dale Richey. My download is in progress.

Unfortunately this is what I'm seeing here too: http://openqa.opensuse.org/viewimg/openqa/testresults/openSUSE-GNOME-LiveCD-... mdadm's scripts seem to be broken, we need to fix that too. But the livecd problem is most horrible: expr(1) segfaults while kiwi tries to calculate how much memory to reserve - and in the end it doesn't give no memory at all, which causes clicfs to return a usage message -> no file system. I'm trying to find out how to fix expr, others may check mdadm. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Jan Engelhardt <jengelh@inai.de> writes:

On Tuesday 2012-05-29 09:48, Stephan Kulow wrote:

...

I don't know why kiwi's initrd calls an external tool for it either :)

haveKByte=`cat /proc/meminfo | grep MemFree | cut -f2 -d:| cut -f1 -dk`

cat has been obsolete for these kind of tasks, you can just use

grep MemFree /proc/meminfo

...

A grep and 2 cut commands? That's asking for awk (assuming that awk is available in your enviroment: awk '/^MemFree:/ {print $2}' /proc/meminfo or awk '/^MemFree:/ {print $2; exit}' /proc/meminfo -- Karl Eichwalder SUSE LINUX Products GmbH R&D / Documentation Maxfeldstraße 5 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 29.05.2012 11:16, schrieb Karl Eichwalder:

A grep and 2 cut commands? That's asking for awk (assuming that awk is available in your enviroment:

awk? which one? I recently got bitten by that one... And (at least g)awk's startup time is almost as bad as perl's. So one grep and two cuts are probably still cheaper. -- Stefan Seyfried "Dispatch war rocket Ajax to bring back his body!" -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Guido Berhoerster <gber@opensuse.org> writes:

If you use a modern shell such as bash or ksh93 with built-in support for regexes neither of them should be ever needed.

Yes, but it takes time to get used to it :) -- Karl Eichwalder SUSE LINUX Products GmbH R&D / Documentation Maxfeldstraße 5 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hello, On Tue, 29 May 2012, Stefan Seyfried wrote:

Am 29.05.2012 12:03, schrieb Guido Berhoerster:

...

Try mawk, it's an order of a magnitude faster than gawk and can be configured as /bin/awk using update-alternatives.

Yeah, and it has incompatible syntax. The following snippet to extract name and version from a debian control file does not work with mawk:

eval $(awk -F":[[:space:]*]" \ ^ are you sure the * belongs there?

'/^Package:/{print "NAME=\""$2"\""}; /^Version:/{print "VERSION=\""$2"\""}' CONTROL/control)

'/^Package:/{printf("NAME=\"%s\"\n", $2);}; /^Version:/{printf("VERSION=\"%s\"\n", $2);}' CONTROL/control)

But that's now going to be seriously offtopic here.

...

...

grep and two cuts are probably still cheaper.

If you use a modern shell such as bash or ksh93 with built-in support for regexes neither of them should be ever needed.

Whenever I see "while read a b c; do some string processing in shell; done < foo" code, I always wonder if a simple grep|cut would have been more efficient. The shell is probably not as optimized for such stuff as the specialized tools are. And often it is more readable, too.

Usually, the "startup-penalty" of _any_ external tool outweighs by far a dozen lines of using var="${var/%foo/}" and similar lines. Oh, and awk is rather fast in startup: $ time awk 'BEGIN{exit;}' real 0m0.066s $ time awk 'BEGIN{exit;}' real 0m0.004s $ time perl -e 1 real 0m0.006s $ time perl -e 1 real 0m0.003s awk varies further on between .005 and .002, perl between .003 and .008. So, let's use a loop: $ time for i in $(seq 1000); do perl -e 1; done real 0m2.210s $ time for i in $(seq 1000); do perl -e 1; done real 0m2.178s $ time for i in $(seq 1000); do awk 'BEGIN{exit;}'; done real 0m1.509s $ time for i in $(seq 1000); do awk 'BEGIN{exit;}'; done real 0m1.517s $ time for i in $(seq 1000); do cut -f1 </dev/null ; done real 0m2.477s $ time for i in $(seq 1000); do cut -f1 </dev/null ; done real 0m2.507s $ time for i in $(seq 1000); do echo a:b | cut -d: -f1 ; done >/dev/null real 0m3.581s $ time for i in $(seq 1000); do echo a:b | cut -d: -f1 ; done >/dev/null real 0m3.549s $ time for i in $(seq 1000); do var=a:b; echo ${var%:*}; done >/dev/null real 0m0.021s $ time for i in $(seq 1000000); do var=a:b; echo ${var%:*}; done >/dev/null real 0m7.077s So, think again about using grep + cut in a pipe sequence ... -dnh PS: for comparison this is a AMD Athlon II X2 250 with 2 * 3.0GHz cores. -- Gib mal Patschehändchen und komm mit dem freundlichen Wokoonkel nach dag. Da brauchen wir noch Leute wie dich. [WoKo in dag°] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fri, Jun 8, 2012 at 4:21 AM, Stefan Seyfried <stefan.seyfried@googlemail.com> wrote:

...

...

       '/^Package:/{print "NAME=\""$2"\""};         /^Version:/{print "VERSION=\""$2"\""}' CONTROL/control)

        '/^Package:/{printf("NAME=\"%s\"\n", $2);};          /^Version:/{printf("VERSION=\"%s\"\n", $2);}' CONTROL/control)

How does that help? $2 was empty. Guido explained this to me (in personal mail, as this topic is offtopic here), debian has an obsolet version of mawk which does not support character classed. The code is now using [\t ]* instead of [[:space:]*]

I don't know why David suggested so, but I can say, at least, that the first form is a security hole. You must NEVER send arbitrary strings as a format string to printf, as that's a quick path into buffer overflow exploits. The second form is safer, since the arbitrary strings aren't passed as format strings, but arguments. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hello, On Fri, 08 Jun 2012, Stefan Seyfried wrote:

Am 07.06.2012 08:28, schrieb David Haller:

...

On Tue, 29 May 2012, Stefan Seyfried wrote:

...

Am 29.05.2012 12:03, schrieb Guido Berhoerster:

...

Try mawk, it's an order of a magnitude faster than gawk and can be configured as /bin/awk using update-alternatives.

Yeah, and it has incompatible syntax. The following snippet to extract name and version from a debian control file does not work with mawk:

eval $(awk -F":[[:space:]*]" \ ^ are you sure the * belongs there?

no, but it works, should the * be behind the second ]?

I think so. If it's nside the outer '[]' the Field seperator is set to the regex "a ':', a space or a '*'". $ echo 'a:b: c: d:*e' | awk -F':[[:space:]*]' '{for(i=1;i<=NF;i++) { print $i; }}' a:b c d e If the '*' is out of the [], then the FS is set to the regex "a ':', any space (or none)". $ echo 'a:b: c: d:*e' | awk -F':[[:space:]]*' '{for(i=1;i<=NF;i++) { print $i; }}' a b c d *e Quite a difference, eh?

...

...

'/^Package:/{print "NAME=\""$2"\""}; /^Version:/{print "VERSION=\""$2"\""}' CONTROL/control)

'/^Package:/{printf("NAME=\"%s\"\n", $2);}; /^Version:/{printf("VERSION=\"%s\"\n", $2);}' CONTROL/control)

How does that help? $2 was empty. Guido explained this to me (in personal mail, as this topic is offtopic here), debian has an obsolet version of mawk which does not support character classed. The code is now using [\t ]* instead of [[:space:]*]

Then above should (have) definitely be(en) ':[[:space:]]*'. I think the "foo=\"%s\"\n", bar is easier to read. than "foo=\""bar"\"".

...

Usually, the "startup-penalty" of _any_ external tool outweighs by far a dozen lines of using var="${var/%foo/}" and similar lines.

and the readability penalty of

val="" while read a b c; do case $a in frob) val=$b; break ;; esac done < /foo/bar/baz

get_field_if() { f=$(( $1 - 1 )) while IFS="${4:-$IFS}" read -a line; do case ${line[$f]} in $2) echo "${line[ $3 ]}"; continue;; esac done } val=$(get_field_if 1 frob 2 < /foo/bar/baz) Sample: get_field_if 6 '*bash' 0 : < /etc/passwd outputs users having bash as shell, and would be in awk awk -F: '$7 ~ /.*bash$/ { print $1; }' </etc/passwd If you do that for a number of key/value pairs and want to avoid 'eval'-ing, above should be fine.

outweighs by far val=$(awk '/^frob /{ print $2 }' /foo/bar/baz)

I'd often write the whole script in awk if there's more than just one call to awk ;-P [..]

This benchmark is like most benchmarks: irrelevant.

It shows how much time the start of a (cached!) program takes in comparison to using shell-builtins. Nothing more, nothing less. Just keeping that fact in mind while scripting is good. Just as it's good to keep in mind that you should always quote your variables ;)

perl loads ~7 MB for doing nothing, awk loads "only" ~4 MB AFAICT. I *guess* (not tested) that as soon as you do anything useful, perl will load even more.

Only if you use extra Modules (not pragmas).

...

PS: for comparison this is a AMD Athlon II X2 250 with 2 * 3.0GHz cores.

CPU is mostly irrelevant for this kind of workload, it's I/O.

That was with warm caches, and it's hard to run a Suse without having bash, cut, grep, awk and perl in the disk-caches.

But this is still offtopic here. And the problem is solved now.

Fine. I'll bugger off then. -dnh -- If only I'd spent some of that effort on chasing girls. But then, it's much easier to understand a polysubstitution cypher than a female. -- Robert Uhl -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tue, May 29, 2012 at 4:44 PM, Brian K. White <brian@aljex.com> wrote:

You don't need awk or anything but the same shell that's already executing the script.

GetVal () {        DONE=false        until $DONE ; do                IFS=: read KEY VAL junk || DONE=:                        [[ "$KEY" == "$1" ]] && { echo $VAL ; DONE=: ; }        done < $2 }

Isn't that bash-specific? Don't spec scripts have to be more generic (sh-compatible)? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tue, May 29, 2012 at 5:33 PM, Jan Engelhardt <jengelh@inai.de> wrote:

This was not inside rpm, if I followed the thread.

Ah, yes, it was kiwi in initrd. All the more reason to avoid bash (with this tendency of late to use dash for init stuff). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 5/29/2012 3:48 PM, Claudio Freire wrote:

On Tue, May 29, 2012 at 4:44 PM, Brian K. White<brian@aljex.com> wrote:

...

You don't need awk or anything but the same shell that's already executing the script.

GetVal () { DONE=false until $DONE ; do IFS=: read KEY VAL junk || DONE=: [[ "$KEY" == "$1" ]] && { echo $VAL ; DONE=: ; } done< $2 }

Isn't that bash-specific? Don't spec scripts have to be more generic (sh-compatible)?

No. That is, this off the cuff example may possibly have some bash-specific syntax, but it does not use or rely on any bash-specific features. This practically identical version works on the stock sco open server /bin/sh which is much cruder than bash or ksh88 let alone ksh93, and works on current bash too, if we cared. Only Linux has /proc anyways (or at least the same /proc contents formatted the same way) but I guess OBS could target ash/busybox environment which would be linux and have /proc yet not bash. GetVal () { DONE=false until $DONE ; do IFS=: read KEY VAL junk || DONE=: [ "$KEY" = "$1" ] && { echo $VAL ; DONE=: ; } done< $2 } I don't know if stuff like this is more or less efficient than calling grep/awk/etc, I just know that it doesn't physically require any external util at all, which is a win in certain ways. If you're scanning many or large files or you need fancy regex matching, then of course the external tools become worth it. Each job really should get it's own evaluation. You can do many of the same jobs with your choice of sed or awk or grep or perl or c or whatever. I always try to minimize just on general principle. Just because grep/awk/whatever is almost always going to be available because surely some other package will require it, is not enough excuse for me to use it if I don't need it. Suppose awk is broken on a machine one day, maybe an update breaks it or something. Either all my zillion scripts built up over years can all break at the same time, or maybe 5 of them can break and maybe only 2 of those are ones any customer even cares about at the moment. Multiply that times every other potential requirement. -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 29.05.2012 11:10, Marcus Schäfer wrote:

Hi,

...

I don't know why kiwi's initrd calls an external tool for it either :)

There is a good reason. When using expr you see that when in shell debug mode (set -x) when using $((...)) you don't see the calculation bits just the result. So it was helpful for debugging for me but I will eliminate the use of expr if it's gone

Just to tell you I don't think it's a good idea to remove old stone linux tools like expr you will break more than just kiwi with it no matter how long you set the "depreciated" bit on it nobody ever will remove ifconfig vs ip and that is set as depreciated for more than two years ;)

expr is still there, it's just crashing in kvm Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 28.05.2012 20:33, Stephan Kulow wrote:

I'm trying to find out how to fix expr, others may check mdadm.

OK, thanks for everyone for adding useless comments about expr and shell programming and ignoring the fact that mdadm is broken too. Anyway, I debugged the issue myself and the problem is that yast mounts /run as tmpfs size=0K (this seems to be an incompat with kernel 3.4 I assume) and as such mdadm fails to install /run/mdadm *as %ghost*. Funny rpm ;( Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 30.05.2012 10:43, Jan Engelhardt wrote:

On Wednesday 2012-05-30 09:37, Stephan Kulow wrote:

...

On 28.05.2012 20:33, Stephan Kulow wrote:

...

I'm trying to find out how to fix expr, others may check mdadm.

OK, thanks for everyone for adding useless comments about expr and shell programming and ignoring the fact that mdadm is broken too.

Anyway, I debugged the issue myself and the problem is that yast mounts /run as tmpfs size=0K (this seems to be an incompat with kernel 3.4 I assume) and as such mdadm fails to install /run/mdadm *as %ghost*. Funny rpm ;(

I'd say it's a known issue:

https://bugzilla.novell.com/show_bug.cgi?id=720150

"the disk space rpm wants increases linearly with the amount of used bytes on the disk [=mountpoint]".

Hmm, no idea how "increases linearly" and size=0 matches :) Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org