Re: Expanding the list of Hardened Packages

[Jim Meyering]

Steve Grubb wrote:
 On Monday, April 15, 2013 09:12:57 AM Richard W.M. Jones wrote:
 which I interpret to mean that after using -fstack-protector-all and
 removing prelink, SELinux would become obsolete because no executable
 can be exploited.

 I would say there is a place for SE Linux even if we compiled everything with
 all because FORTIFY_SOURCE coverage is not absolute. For example, about a
 month ago i ran the following test:

 procs=`ls /proc | grep '^[0-9]' | sort -n`
 for p in $procs
 do
   res=`cat /proc/$p/maps 2/dev/null |  awk '$2 ~ wx { print $2 }'`
   if [ x$res != x ] ; then
   cat /proc/$p/cmdline | awk '{ printf %-35s\t, $1 }'
   printf %s\n $p
   fi
 done

Neat.
I saved that in a script, then realized I could simplify it.
This is nearly equivalent:

  $ grep -lE '^[0-9a-f-]+ .wx' /proc/*/maps 2/dev/null \
  |perl -ne 'm!^(/proc/(\d+))/.*! and printf qq(%5d %s\n), $2, `cat $1/cmdline`'

Sample output on an F18 system running the awesome window manager:
1836 /usr/lib/firefox/firefox-no-remote-Pdefault

Notice that the NUL-separated arguments aren't shown properly,
so filter the result through e.g., | tr '\0' ' '

Adjusted output:
1836 /usr/lib/firefox/firefox -no-remote -P default

 What this does is display the programs with Writable and Executable memory.
 All Fedora desktops except Mate have WX memory. (I checked KDE, Gnome,
 Cinnamon, and Mate.) WX memory is dangerous because the normal exploit pattern
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Rawhide boot problems

[Jim Meyering]

Jerry James wrote:
 I've got two Rawhide VMs, one x86_64, one i686, both otherwise
 identical.  I last booted them yesterday and did a yum repo-sync.
 Today, neither of them will boot.

 First, systemd complained about being unable to find
 systemd-journal-flush.service.  Sure enough, it wasn't in the
 initramfs.  So I added
 $systemdsystemunitdir/systemd-journal-flush.service to
 /usr/lib/dracut/modules.d/98systemd/module-setup.sh, and regenerated
 the initramfs.  Now the boot gets past that point, but starts doing
 this over and over, apparently forever, even in emergency mode:

Thank you for posting about this, and to everyone who has been
working on http://bugzilla.redhat.com/847418.  I hit the same bug
when my rawhide VM updated to the latest kernel, and you've saved
me the trouble of investigating.  For now, I get by using the
preceding kernel.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

make distcheck is exploitable: get a fixed automake

[Jim Meyering]

If you run make distcheck (the rule generated by automake),
be sure that it is safe.  Until a few days ago, running that
rule in a directory readable by others would put you at risk
from a local attacker.  It can be exploited reliably.
It's fixed in the latest, automake-12.2

http://bugzilla.redhat.com/CVE-2012-3386
http://savannah.gnu.org/forum/forum.php?forum_id=7294

One work-around is to ensure that your build directory
is not readable by the potential attacker.  A more general
(but more onerous) approach is to use a restrictive umask,
e.g. by adding umask 077 to some shell start-up file.
But don't do that lightly, since there are still plenty of
tools that are unprepared for that.  Personally, I've had
a umask of 077 for the last few years because I'm rather
paranoid, but it has also caused trouble, and I've had to
learn when to invoke tools in a subshell like this

(umask 022; run some tool)

especially as root.

To see if you have a vulnerable Makefile.in file, run this:

find . -name Makefile.in|xargs grep chmod.a+w

it usually finds problems in the top-level Makefile.in.
If you see any matching line, say like this,

./Makefile.in:  chmod -R a-w $(distdir); chmod a+w $(distdir)

then that rule is vulnerable: install a patched automake
and/or just change a+w to u+w on that line.

Note that just installing a fixed automake is not enough.
You must also rerun it, in order to regenerate each offending
Makefile.in.  This means that if you ever unpack an old tarball
and run make distcheck using that, you may be vulnerable.

If you're about to make a release, be sure to regenerate your
Makefile.in files with a fixed automake before doing that so
that people who use your release tarball are not vulnerable.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

fix common misspellings -- mostly mechanically

[Jim Meyering]

Even in mature projects full of nit-picky reviewers, it seems there
are always a few misspelled words in comments, documentation, etc.

Here's a recipe for correcting those.  Hook this up as a
make check dependent rule to prevent recurrence.

First, get this http://github.com/lyda/misspell-check
and install its misspellings script.

Then, (presuming you use git for VC), run this to
see what you might want to change[*]:

  git ls-files|misspellings -f -|perl -nl \
-e '/^(.*?)\[(\d+)\]: (\w+) - (.*?)$/ or next;' \
-e '($file,$n,$l,$r)=($1,$2,$3,$4); $q='\''; $r=~s/$q/$q\\$q$q/g;'\
-e 'print sed -i $q${n}s!$l!$r!$q $file'

It massages the misspellings output into sed -i invocations.
Here are the ones from autoconf/master:

sed -i '104s!Stange!Strange!' AUTHORS
sed -i '175s!Propogate!Propagate!' ChangeLog.1
sed -i '673s!occurences!occurrences!' ChangeLog.2
sed -i '6973s!Accomodate!Accommodate!' ChangeLog.3

If you look at the AUTHORS file, you see that the first is a false
positive: we don't want to change the name of a contributor.
However, the three remaining commands fix legitimate spelling errors,
albeit only in ChangeLog files.

Remember that this is a naive tool.  Be sure to review each
change carefully, and *in context*.  It has no clue about the
boundaries between code and comments.  For example, you must
be careful that it does not change grammar tokens or variable
names like THRU or UPTO to THROUGH or UP TO.

Jim

[*] The misspellings script appears to be intended to do some
of this itself, but so far, it hasn't worked for me.
Note that for a typo like cant, you'll be presented with this
sed command:

  sed -i '16s!cant!cannot,can not,can'\''t!' m4/nullsort.m4

While the perl filter was careful to escape the single quote in the RHS
of the substitution, it will not choose which of those three
alternatives to use.  Search for , in the list of sed commands
to identify ones with more than one alternative spelling.
For each of those, you must manually select the word that you prefer.

Once you've done that, you can save the sed commands to a file, say
K, and apply their changes with bash K.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

MALLOC_PERTURB_: everyone should set this envvar

[Jim Meyering]

I posted about MALLOC_PERTURB_ about a year ago,

http://thread.gmane.org/gmane.linux.redhat.fedora.devel/132690

but it is clear that not everyone is setting the variable, so for those
who didn't take the time last year, or who are new to the subject,
do yourself a favor and set MALLOC_PERTURB_ to a value in 1..255
everywhere.

For those who can't be bothered to click the link, here's that post:


If you are into development on glibc-based systems
and do not set MALLOC_PERTURB_ to a nonzero value, then you
are missing an easy opportunity to detect subtle bugs early.

Sure, you can use valgrind, and it will detect whatever a
MALLOC_PERTURB_ setting would have caught, and more, but it's
far more expensive and takes some effort, however minimal.

If you use zsh or bash, put this in one of your startup files:

# http://udrepper.livejournal.com/11429.html
export MALLOC_PERTURB_=$(($RANDOM % 255 + 1))

and remember that when you find surprising bugs, that others
who are also running tests (but without MALLOC_PERTURB_)
will not see the same failures.

This is useful enough that it is worth considering for inclusion
in /etc/profile.


Why do I insist?

Here's a nice example: a month or so ago I was investigating
a build problem in libvirt and as part of that, ran make check
from the cloned source tree.  Imagine my surprise when one of
the tests failed.  Obviously, while it was failing for me, it
was not failing for the many people who build libvirt regularly,
so what was different here?  I had MALLOC_PERTURB_ set in my
environment and they did not.

The bug I uncovered was a heap corruptor that dated back to
libvirt-0.9.5:

http://thread.gmane.org/gmane.comp.emulators.libvirt/56605

TL;DR: Add these lines to your ~/.bash_profile or ~/.zshenv:

# http://udrepper.livejournal.com/11429.html
export MALLOC_PERTURB_=$(($RANDOM % 255 + 1))

One caveat: this does induce a small performance penalty (usually
negligible), so when you're measuring performance, you may want
to turn it off.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: MALLOC_PERTURB_: everyone should set this envvar

[Jim Meyering]

John Reiser wrote:
 # http://udrepper.livejournal.com/11429.html
 export MALLOC_PERTURB_=$(($RANDOM % 255 + 1))

 For supportability (and to help remind you to turn it off before
 performance tests), then also consider adding a line such as:
  echo 12 MALLOC_PERTURB_=$MALLOC_PERTURB_   # $HOME/.bash_profile

Good idea.  Or have a weekly cron job send clue-bat mail to
yourself reminding you that you do have this envvar set.

For the first year or so during which I had this enabled,
when I'd hit a memory-related problem, I didn't immediately think,
Oh! that may be because I've enabled MALLOC_PERTURB_, so the
above might well help, initially.

If you do add something like that, be sure to use a guard so
that it is printed only for interactive sessions, e.g.,

test -n $PS1  echo 12 MALLOC_PERTURB_=$MALLOC_PERTURB_

Once you've been graced with enough MALLOC_PERTURB_-induced
failures, you get used to it, always remember to include it in
bug reports,... then you can turn that off ;-)
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: sys/sysctl.h and bits/sysctl.h in rawhide/f18?

[Jim Meyering]

Kaleb Keithley wrote:
 About a week ago I did a scratch build of one of my packages that
 includes sys/sysctl.h and it built successfully.

 Today I did another scratch build and it broke with:

 ...
 Making all in src
   CC fuse-helpers.lo
   CC fuse-resolve.lo
   CC fuse-bridge.lo
   CC misc.lo
 In file included from fuse-helpers.c:24:0:
 /usr/include/sys/sysctl.h:63:25: fatal error: bits/sysctl.h: No such
 file or directory
 compilation terminated.
 ...

I noticed that today and reported it:

http://bugzilla.redhat.com/827040
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Please add GNU id-utils to Fedora

[Jim Meyering]

Michal Schmidt wrote:
 On 05/14/2012 10:11 AM, Jim Meyering wrote:
 Miloslav Trmač wrote:
 I'm pretty sure that naming conflicts in /usr/bin have happened before
 in Fedora, I'm not sure how they were resolved.

 Even in a relatively minimal system, I see many programs installed
 in both /sbin and /bin, though none seem to conflict:
 [...]
 Odd that some point from /bin to /sbin, and others from /sbin to /bin.
 Some use relative symlinks, others use absolute.

 These are not comparable to the lid situation. They are either:
  - programs using consolehelper, the legacy privilege escalation
mechanism, which depends on one of the names being a symlink to
consolehelper and the other name being the program itself,
or
  - cases where the program historically lived in one directory, then
was moved to the other and a symlink in the old directory was added
for backwards compat. But it is the same program.

 They're not comparable to the lid name conflict between two different 
 programs.

Thanks for confirming my none seem to conflict comment.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Please add GNU id-utils to Fedora

[Jim Meyering]

Miloslav Trmač wrote:
 On Fri, May 11, 2012 at 10:14 AM, Jim Meyering j...@meyering.net wrote:
 Miloslav Trmač wrote:
 On Thu, May 10, 2012 at 9:49 PM, Greg McGary greg.mcg...@gmail.com wrote:
 Minor conflict: the name of one of id-utils main commands lid is also the
 same as an existing command, though installed in a different place.  
 id-utils
 has /usr/bin/lid, while libuser has /usr/sbin/lid.

 Yeah, that's come up before.  There's no great solution I'm afraid,
 one or the other will have to change

 Technically there is no need to change a name.
 In Debian, one can have two lid programs installed, one in /usr/bin
 and the other in /usr/sbin[*], so why not in Fedora?

 Apart from being confusing, it effectively overrides libuser's use of lid.

 Sure, a different solution would be better, but renaming a command like
 idutils' lid (in use by some for 15 years) does not seem reasonable.
 Right.

 Any opinions on whether this issue is big enough to NAK
 a review request or addition of the package to Fedora?
 I'm pretty sure that naming conflicts in /usr/bin have happened before
 in Fedora, I'm not sure how they were resolved.

Even in a relatively minimal system, I see many programs installed
in both /sbin and /bin, though none seem to conflict:

  $ comm -12 (cd /sbin;env ls -1) (cd /bin;env ls -1)
  authconfig
  authconfig-gtk
  authconfig-tui
  dracut
  eject
  halt
  hddtemp
  makemap
  mock
  ping6
  poweroff
  preupgrade
  preupgrade-cli
  rdistd
  reboot
  setup
  system-config-authentication
  system-config-keyboard
  system-config-network
  system-config-network-cmd
  tmpwatch
  tracepath
  tracepath6
  udevadm

Odd that some point from /bin to /sbin, and others from /sbin to /bin.
Some use relative symlinks, others use absolute.

Compare the output of these commands:
  cd /sbin; ls -og $(comm -12 (cd /bin;env ls -1) (cd /sbin;env ls -1))
  cd /bin;  ls -og $(comm -12 (cd /bin;env ls -1) (cd /sbin;env ls -1))

...
 Anyway, we can't please both sets of users at the same time.  If the
 above-mentioned reference to previous naming conflicts in Fedora does
 not result in a generally-acceptable solution, what about the
 following?

 lid is renamed in both packages to lid-libuser and lid-idutils (or
 something), respectively.  Both packages ship an alias script
 somewhere in /etc.  A new package is created, providing a /usr/bin/lid
 script, that instructs the user to add the alias to their ~/.bashrc,
 and fails.[1]
 Mirek

If cohabitation is not acceptable, that is a fine compromise that
would let us move forward.  However, it should suggest more than an
alias/function addition, because those are not desirable/useful for
non-command-line use e.g., via other scripts that invoke lid.  Instead,
suggesting to install a lid wrapper via one of these commands:

f=~/bin/lid
printf '#!/bin/sh\nexec lid-idutils $@\n'  $f  chmod a+x $f
printf '#!/bin/sh\nexec lid-libuser $@\n'  $f  chmod a+x $f

[ or use f=/usr/local/bin/lid for a system-wide choice. ]

I would also request that users who encounter the failing lid script
write to e.g., bug-idut...@gnu.org to inform us of their choice (either way),
so that eventually, if we get stats to support a move and everyone agrees
it's ok, we could phase out the always-failing lid script.

 [1] The script could also automatically run one of the lid's, if there
 were only one installed - but then merely installing a new package
 could break user's workflow, which I think is undesirable.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rawhide ext4/virtio FS performance hit (10x slower) ?

[Jim Meyering]

Josh Boyer wrote:

 On Mon, May 7, 2012 at 8:43 AM, Jim Meyering j...@meyering.net wrote:
 Today I noticed that some tests from coreutils' test suite
 were taking far longer than they used to on rawhide.
 For example, run this command in an empty directory:

  seq 20|env time xargs touch

 it takes  5s on F17 3.3.4-1.fc17.x86_64 ext4/sdb8/SSD, yet
 it takes 47s on rawhide 3.4.0-0.rc5.git5.1.fc18.x86_64 ext4/vda1/SSD

 10x performance hit... ouch.

 Does anyone know why?

 Rawhide has all the kernel debug options turned on.  It isn't
 worthwhile doing a comparison when those are enabled.  You could try
 again with the first -rc6 build that shows up, as that will have the
 options disabled.

Hi Josh,

I've just rerun the test with 3.4.0-0.rc6.git1.1.fc18.x86_64,
and it takes just as long, so the hit is *not* due to debug options:

$ seq 20|env time xargs touch
0.17user 41.98system 0:48.22elapsed 87%CPU (0avgtext+0avgdata 1424maxresident)k
88inputs+0outputs (0major+4502minor)pagefaults 0swaps
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Please add GNU id-utils to Fedora

[Jim Meyering]

Miloslav Trmač wrote:
 On Thu, May 10, 2012 at 9:49 PM, Greg McGary greg.mcg...@gmail.com wrote:
 Minor conflict: the name of one of id-utils main commands lid is also the
 same as an existing command, though installed in a different place.  id-utils
 has /usr/bin/lid, while libuser has /usr/sbin/lid.

 Yeah, that's come up before.  There's no great solution I'm afraid,
 one or the other will have to change

Technically there is no need to change a name.
In Debian, one can have two lid programs installed, one in /usr/bin
and the other in /usr/sbin[*], so why not in Fedora?

Sure, a different solution would be better, but renaming a command like
idutils' lid (in use by some for 15 years) does not seem reasonable.

Any opinions on whether this issue is big enough to NAK
a review request or addition of the package to Fedora?

 and the only data I've seen is
 debian's popcon, which indicated that libuser is used more widely.

That counts how often the package is installed.  Note that libuser
is installed primarily for its library, whereas idutils is installed
solely for the use of its programs.

Of course, popcon says little about how much libuser's
rarely-useful-to-non-root lid program is actually run.

 This conflict is exceedingly minor since /usr/sbin/lid is only usable by 
 root.
 Ordinary users who try it get this:

    $ lid foo
    Error initializing libuser: could not open configuration file
 /etc/default/useradd': Permission denied.

 Ordinary users can set up a different configuration to run
 unprivileged (in particular, to manage a LDAP user database).

My guess is that unprivileged use of libuser's lid is unusual.

Jim

[*] Confirmed: libuser and idutils packages coexist just fine on Debian:

  debian# type -a lid
  lid is /usr/sbin/lid
  lid is /usr/bin/lid
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Please add GNU id-utils to Fedora

[Jim Meyering]

Pádraig Brady wrote:
 On 05/11/2012 09:14 AM, Jim Meyering wrote:
 Miloslav Trmač wrote:
 On Thu, May 10, 2012 at 9:49 PM, Greg McGary greg.mcg...@gmail.com wrote:
 Minor conflict: the name of one of id-utils main commands lid is also the
 same as an existing command, though installed in a different place.  
 id-utils
 has /usr/bin/lid, while libuser has /usr/sbin/lid.

 Yeah, that's come up before.  There's no great solution I'm afraid,
 one or the other will have to change

 Technically there is no need to change a name.
 In Debian, one can have two lid programs installed, one in /usr/bin
 and the other in /usr/sbin[*], so why not in Fedora?

 Sure, a different solution would be better, but renaming a command like
 idutils' lid (in use by some for 15 years) does not seem reasonable.

 Any opinions on whether this issue is big enough to NAK
 a review request or addition of the package to Fedora?

 Well /usr/sbin is proposed to be merged with /usr/bin in Fedora 18

I note that it's not yet on the approved feature list:

http://fedoraproject.org/wiki/Releases/18/FeatureList

 Anyway I think having the same name in different paths is too problematic.

I agree that it is sub-optimal, but it seems slightly better than a renaming.

 id-utils (1996) seems to predate libuser (2001), so it's
 unfortunate that libuser picked the clashing name.

It goes back pretty far.  From idutils.texi's history node:

First posted to comp.sources.unix in September 1987 under the name id.
mkid version 2 was posted to alt.sources in 1990.
Renamed to id-utils in 1996.

 I'm not sure what to suggest though.
 The simplest is to rename the id-utils lid on fedora,
 which will not break anything, but does introduce awkwardness

I'm reluctant to make such a change (be it upstream or just for Fedora)
because it would break any existing script/alias that invokes lid,
introducing a Fedora-specific incompatibility with upstream and with
all other existing installations.

For those who use idutils, I suspect lid is second in use-frequency
only to gid, so muscle memory is an issue, too.

 in future script portability, needing something like:
   lid-utils  /dev/null  LID=lid-utils || LID=lid
 /etc/alternatives probably isn't appropriate as I'm
 assuming the commands do not overlap in functionality.

Right.  Regarding functionality, they do not overlap at all.

Put it this way: in the package review process,
*must* the name conflict be cause for rejection?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

rawhide ext4/virtio FS performance hit (10x slower) ?

[Jim Meyering]

Today I noticed that some tests from coreutils' test suite
were taking far longer than they used to on rawhide.
For example, run this command in an empty directory:

  seq 20|env time xargs touch

it takes  5s on F17 3.3.4-1.fc17.x86_64 ext4/sdb8/SSD, yet
it takes 47s on rawhide 3.4.0-0.rc5.git5.1.fc18.x86_64 ext4/vda1/SSD

10x performance hit... ouch.

Does anyone know why?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rawhide ext4/virtio FS performance hit (10x slower) ?

[Jim Meyering]

Josh Boyer wrote:
 On Mon, May 7, 2012 at 8:43 AM, Jim Meyering j...@meyering.net wrote:
 Today I noticed that some tests from coreutils' test suite
 were taking far longer than they used to on rawhide.
 For example, run this command in an empty directory:

  seq 20|env time xargs touch

 it takes  5s on F17 3.3.4-1.fc17.x86_64 ext4/sdb8/SSD, yet
 it takes 47s on rawhide 3.4.0-0.rc5.git5.1.fc18.x86_64 ext4/vda1/SSD

 10x performance hit... ouch.

 Does anyone know why?

 Rawhide has all the kernel debug options turned on.  It isn't
 worthwhile doing a comparison when those are enabled.  You could try
 again with the first -rc6 build that shows up, as that will have the
 options disabled.

Thanks.  Will do.

I knew about the kernel debug options, but didn't realize they
could make such a large difference.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

F17: gcc not usable without glibc-devel.x86_64 -- %{?_isa}, again?

[Jim Meyering]

I built another x86_64 rawhide VM yesterday and was surprised
to find that its gcc was unusable:

$ printf 'int main(){return 0;}'  k.c; gcc k.c
/usr/bin/ld: skipping incompatible 
/usr/lib/gcc/x86_64-redhat-linux/4.7.0/../../../libc.so when searching for -lc
/usr/bin/ld: skipping incompatible /lib/libc.so when searching for -lc
/usr/bin/ld: skipping incompatible /usr/lib/libc.so when searching for -lc
/usr/bin/ld: cannot find -lc
collect2: error: ld returned 1 exit status
[Exit 1]

How strange.
strace (after enabling that) showed that since there was no
/lib64/libc.{so,a}, it was finding/rejecting the i686 libraries.

That led me to the realization that gcc is usable only
after you've also installed the glibc-devel package, since
that's the one that provides /lib64/libc.so.

Yet there is a dependency problem, because I'd managed to install
gcc without its dependent, glibc-devel.  Oddly, this shows no deps:

$ repoquery whatrequires glibc-devel
glibc-devel-0:2.15-32.fc17.i686
glibc-devel-0:2.15-32.fc17.x86_64

(hmm... but using s/whatrequires/--whatrequires/ does show the gcc connection)

The same thing happens on F17.
To demonstrate, I manually removed the x86_64 version of glibc-devel,
(remember, nothing depends on it, so this should be safe)

yum remove glibc-devel.x86_64

And then reran the above test:

printf 'int main(){return 0;}'  k.c; gcc k.c

It failed just as on rawhide, which means
gcc on F17/x86_64 is useless, too.

Is this simply a missing dependency?
No.  gcc.spec does list the dependency:

$ grep 'Req.*bc-d' gcc.spec
BuildRequires: glibc-devel = 2.4.90-13
Requires: glibc-devel = 2.2.90-12

Then how did I manage to install gcc without also installing glibc-devel?

For the record, I installed F17-beta-RC3 (or maybe it was 4),
installed a bunch of essential-to-me packages, and then upgraded
to rawhide.

I guess this comes down to %{?_isa}, again?

-Requires: glibc-devel = 2.2.90-12
+Requires: glibc-devel%{?_isa} = 2.2.90-12

It would sure save trouble to fix this once and for all.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?

[Jim Meyering]

Mark Wielaard wrote:
 On Mon, Apr 09, 2012 at 10:58:43AM -0400, Daniel J Walsh wrote:
 I thought I made this clear in my blogs and the feature page that I wanted
 this on deny_ptrace on by default.
 [...]
 We did have a bug in Alpha where it was turned off.  Now that people are
 actually seeing it turned on in Fedora 17 Beta, they are reacting.

 My apologies I seem to react to this change so late. Now that I have seen
 your other blog postings I see that was your intention. But I did see the
 initial proposal and, like others, and FESCO, read it as making it an
 option that could be turned on. But not by default. Because that creates
 this situation that a normal users/developer needs to ask their admin to
 fix their machine even though they can write, compile and run their own
 programs, but suddenly aren't allowed to debug, profile or trace them.
 If I had thought it would be turned on by default, I would have spoken
 up sooner to try and help figure out something that wouldn't create such
 a disruption.

Not being able to get an strace from du or df (or several other
programs in coreutils) would be a problem for me as coreutils maintainer.
If someone is reporting strange behavior from those tools, it is
common that the easiest way for us to diagnose the failure is by
getting them to strace the program in their somehow-unusual environment.

This situation arises once or twice a month, and the user reporting
the problem might well not have root access to the system with the
unusual file system or kernel.  Admittedly, it hasn't happened much
with Fedora recently, but with combinations of virtual machines and
new file system types, we're far from seeing the last of those.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

rawhide vs. protected multilib versions

[Jim Meyering]

I installed x86_64 F17 from the netinst.iso yesterday, selected
a minimal install, and immediately upgraded to rawhide.
Worked like a charm.

However, now that I try to use the resulting system and need a
few packages, I find that installing them is um, ... challenging.

For example, yesterday I couldn't even install gcc due to this:

Error: Protected multilib versions: \
  libgomp-4.7.0-0.20.fc17.i686 != \
  libgomp-4.7.0-1.fc17.x86_64

Could part of the problem be that gcc requires a specific version of libgomp?
As seen in gcc.spec:

  Requires: libgomp = %{version}-%{release}

(i.e., =, not =), yet the x86_64 libgomp installed in rawhide was too
new to meet that criterion.  The = caused the matching i686 version to
be pulled in, and that triggered the protected multilib warning.

I was able to kludge around this by removing libgomp-4.7.0-1.fc17.x86_64
and all packages that depend on it (luckily only 2 or 3).

Then, installing gcc worked fine.

--

However, today when I try to install g++, something similar is
happening (symptom: yum wants to install i686 packages to meet
version constraints) but this time, my work-around is not an option.

root$ yum install --skip-broken gcc-c++ 
:
Loaded plugins: etckeeper, fastestmirror
Loading mirror speeds from cached hostfile
 * rawhide: fedora.mirrors.ovh.net
Resolving Dependencies
-- Running transaction check
--- Package gcc-c++.x86_64 0:4.7.0-0.20.fc17 will be installed
-- Processing Dependency: libstdc++-devel = 4.7.0-0.20.fc17 for package: 
gcc-c++-4.7.0-0.20.fc17.x86_64
-- Processing Dependency: libstdc++ = 4.7.0-0.20.fc17 for package: 
gcc-c++-4.7.0-0.20.fc17.x86_64
-- Running transaction check
--- Package libstdc++.i686 0:4.7.0-0.20.fc17 will be installed
-- Processing Dependency: libm.so.6(GLIBC_2.0) for package: 
libstdc++-4.7.0-0.20.fc17.i686
-- Processing Dependency: libm.so.6 for package: 
libstdc++-4.7.0-0.20.fc17.i686
-- Processing Dependency: libgcc_s.so.1(GLIBC_2.0) for package: 
libstdc++-4.7.0-0.20.fc17.i686
-- Processing Dependency: libgcc_s.so.1(GCC_4.2.0) for package: 
libstdc++-4.7.0-0.20.fc17.i686
-- Processing Dependency: libgcc_s.so.1(GCC_3.3) for package: 
libstdc++-4.7.0-0.20.fc17.i686
-- Processing Dependency: libgcc_s.so.1(GCC_3.0) for package: 
libstdc++-4.7.0-0.20.fc17.i686
-- Processing Dependency: libgcc_s.so.1 for package: 
libstdc++-4.7.0-0.20.fc17.i686
-- Processing Dependency: libc.so.6(GLIBC_2.4) for package: 
libstdc++-4.7.0-0.20.fc17.i686
-- Processing Dependency: ld-linux.so.2(GLIBC_2.3) for package: 
libstdc++-4.7.0-0.20.fc17.i686
-- Processing Dependency: ld-linux.so.2 for package: 
libstdc++-4.7.0-0.20.fc17.i686
--- Package libstdc++-devel.x86_64 0:4.7.0-0.20.fc17 will be installed
-- Processing Dependency: libstdc++(x86-64) = 4.7.0-0.20.fc17 for package: 
libstdc++-devel-4.7.0-0.20.fc17.x86_64
-- Running transaction check
--- Package glibc.i686 0:2.15-32.fc18 will be installed
-- Processing Dependency: libfreebl3.so(NSSRAWHASH_3.12.3) for package: 
glibc-2.15-32.fc18.i686
-- Processing Dependency: libfreebl3.so for package: 
glibc-2.15-32.fc18.i686
--- Package libgcc.i686 0:4.7.0-0.20.fc17 will be installed
--- Package libstdc++-devel.x86_64 0:4.7.0-0.20.fc17 will be installed
-- Processing Dependency: libstdc++(x86-64) = 4.7.0-0.20.fc17 for package: 
libstdc++-devel-4.7.0-0.20.fc17.x86_64
-- Running transaction check
--- Package libstdc++-devel.x86_64 0:4.7.0-0.20.fc17 will be installed
-- Processing Dependency: libstdc++(x86-64) = 4.7.0-0.20.fc17 for package: 
libstdc++-devel-4.7.0-0.20.fc17.x86_64
--- Package nss-softokn-freebl.i686 0:3.13.4-0.1.fc18.beta1.1 will be 
installed

Packages skipped because of dependency problems:
gcc-c++-4.7.0-0.20.fc17.x86_64 from rawhide
glibc-2.15-32.fc18.i686 from rawhide
libgcc-4.7.0-0.20.fc17.i686 from rawhide
libstdc++-4.7.0-0.20.fc17.i686 from rawhide
libstdc++-devel-4.7.0-0.20.fc17.x86_64 from rawhide
nss-softokn-freebl-3.13.4-0.1.fc18.beta1.1.i686 from rawhide

Any suggestions?

Removing libstdc++ is not an option because it would remove far too
many things, including yum itself.

--
I guess this can be seen as my own damn fault ;-) for choosing
the netinst+minimal installation options rather than the more
mainstream install-from-liveCD approach...
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rawhide vs. protected multilib versions

[Jim Meyering]

Colin Walters wrote:
 On Thu, 2012-04-05 at 14:40 +0200, Jim Meyering wrote:
 I installed x86_64 F17 from the netinst.iso yesterday, selected
 a minimal install, and immediately upgraded to rawhide.
 Worked like a charm.

 However, now that I try to use the resulting system and need a
 few packages, I find that installing them is um, ... challenging.

 For example, yesterday I couldn't even install gcc due to this:

 Error: Protected multilib versions: \
   libgomp-4.7.0-0.20.fc17.i686 != \
   libgomp-4.7.0-1.fc17.x86_64

 I believe it needs a patch like this to the spec:

 There may be other subpackages that need patching here too; I didn't
 have a chance to test the patch yet.  Tried running it by Jakub but
 he was away.
...
 Subject: [PATCH] Use isa for libgomp

 Fixes multilib versioning issues.
 ---
  gcc.spec |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

 diff --git a/gcc.spec b/gcc.spec
 index fc7e476..1928326 100644
 --- a/gcc.spec
 +++ b/gcc.spec
 @@ -146,7 +146,7 @@ Requires: glibc-devel = 2.2.90-12
  Requires: glibc = 2.3.90-35
  %endif
  Requires: libgcc = %{version}-%{release}
 -Requires: libgomp = %{version}-%{release}
 +Requires: libgomp%{?_isa} = %{version}-%{release}

Thanks.
Can anyone explain why appending that %{?_isa} notation is necessary?
Shouldn't dependency-tracking tools already know that libgomp is
an arch-dependent binary, and that of course if gcc.x86_64 is depending
on libgomp, it really wants the x86_64 version and not the i686 one,
at least by default?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rawhide vs. protected multilib versions

[Jim Meyering]

James Antill wrote:
 On Thu, 2012-04-05 at 14:40 +0200, Jim Meyering wrote:
 I installed x86_64 F17 from the netinst.iso yesterday, selected
 a minimal install, and immediately upgraded to rawhide.
 Worked like a charm.
 [...]
 Packages skipped because of dependency problems:
 gcc-c++-4.7.0-0.20.fc17.x86_64 from rawhide
 glibc-2.15-32.fc18.i686 from rawhide
 libgcc-4.7.0-0.20.fc17.i686 from rawhide
 libstdc++-4.7.0-0.20.fc17.i686 from rawhide
 libstdc++-devel-4.7.0-0.20.fc17.x86_64 from rawhide
 nss-softokn-freebl-3.13.4-0.1.fc18.beta1.1.i686 from rawhide

 Any suggestions?

  You can probably work around the repo. problems by using something
 like:

 yum shell
 downgrade libstdc++
 install gcc-c++
 run

Perfect!
That did just what I wanted.  Thank you!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: /tmp on tmpfs

[Jim Meyering]

Daniel J Walsh wrote:
...
 I have been running with a tmpfs /tmp for years, without a problem.  I have
 found the having /tmp be anything else that a tmpfs has caused me pain over
 the years with mislabeled files or files with the wrong UID.

 Change to use a confined user or change the UID of a user suddenly X will not
 allow you to login, reboot does not fix the problem.

 With tmpfs I get a nice clean /tmp on every boot.

I too have been pointing TMPDIR at a tmpfs directory (per-shell-distinct, even).
The per-shell-distinct bit has exposed a few problems, where tools have
expected $TMPDIR in one shell to be the same as $TMPDIR in another one,
but nothing insurmountable.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [Help Wanted]Build error on aplus-fsf

[Jim Meyering]

Jochen Schmitt wrote:

 Hallo,

 I have some issues to build aplus-fsf via mock for the master branch.

 Because I don't have any idea to selve the existing issues, I have uploaded
 the build.log, the SPEC file and a patch to

 http://www.herr-schmitt.de/pub/aplus-fsf/

 It will be nice, if anyone can get a look on it to give me a hint to
 solve the build errors.

 Best Regards:

 Jochen Schmitt

I see one error: in the log:

In file included from ../MSTypes/MSObjectTypeVector.H:96:0,
 from ../MSTypes/MSTypeVector.H:13,
 from ../MSTypes/MSBoolVector.H:13,
 from MSBoolVector.C:9:
../MSTypes/MSObjectTypeVectorInlines.C: In instantiation of 
'MSObjectVectorType MSObjectVectorType::operator[](const MSBinaryVector) 
const [with Type = MSBool]':
MSBoolVector.C:41:16:   required from here
../MSTypes/MSObjectTypeVectorInlines.C:90:33: error: 'compress' was not 
declared in this scope, and no declarations were found by argument-dependent 
lookup at the point of instantiation [-fpermissive]
../MSTypes/MSObjectTypeVectorInlines.C:90:33: note: declarations in dependent 
base 'MSBaseVectorMSBool, MSVectorModelAllocatorMSBool ' are not found by 
unqualified lookup
../MSTypes/MSObjectTypeVectorInlines.C:90:33: note: use 'this-compress' instead

Have you tried following its advice?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Possible to access Koji build directory?

[Jim Meyering]

Richard W.M. Jones wrote:
 On Tue, Mar 13, 2012 at 10:00:59AM +0100, Jan Kratochvil wrote:
 On Tue, 13 Mar 2012 09:45:22 +0100, Richard W.M. Jones wrote:
 
  I suspect the answer is 'no', but is is possible to access or download
  the build directory of a failed build, on the Fedora Koji servers?

 GDB (and GCC) tar and uuencode their testsuite results into build.log:
 * Mon Jun 21 2004 Andrew Cagney cag...@redhat.com1.200400607.4
 - Tar/uuencode both the .sum and .log test results.

 It is a bit hack, providing back also other files besides rpms would be great
 but in fact it works well enough this way.

 Using then a simple extraction script build.log - files (*.{sum,log}):
  
 http://git.jankratochvil.net/?p=nethome.git;a=blob_plain;f=bin/gdbunpack;hb=master

 Neat trick, thanks :-)

Thanks to both of you.
That works very well.  However, the base64 output in my first log was
corrupt, due to some asynchronous output (stderr about job completion)
that was emitted in the middle of the big base64 block.
Adding the sync; sleep 10 part below should avoid that in the future:

Instead of the usual %check rule,

  make %{?_smp_mflags} check

I now use this, when needed:

  # After a failed make check, tar up, compress and base64-encode all results
  # The sync; sleep 10 should ensure that no async output is printed
  # in the middle of the big base64 block.
  make %{?_smp_mflags} check \
|| { st=$?; tar cf - . | xz -9 | base64; sync; sleep 10; exit $st; }
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Possible to access Koji build directory?

[Jim Meyering]

Jim Meyering wrote:
 Richard W.M. Jones wrote:
 On Tue, Mar 13, 2012 at 10:00:59AM +0100, Jan Kratochvil wrote:
 On Tue, 13 Mar 2012 09:45:22 +0100, Richard W.M. Jones wrote:
 
  I suspect the answer is 'no', but is is possible to access or download
  the build directory of a failed build, on the Fedora Koji servers?

 GDB (and GCC) tar and uuencode their testsuite results into build.log:
 * Mon Jun 21 2004 Andrew Cagney cag...@redhat.com1.200400607.4
 - Tar/uuencode both the .sum and .log test results.

 It is a bit hack, providing back also other files besides rpms would be 
 great
 but in fact it works well enough this way.

 Using then a simple extraction script build.log - files (*.{sum,log}):
 
 http://git.jankratochvil.net/?p=nethome.git;a=blob_plain;f=bin/gdbunpack;hb=master

 Neat trick, thanks :-)

 Thanks to both of you.
 That works very well.  However, the base64 output in my first log was
 corrupt, due to some asynchronous output (stderr about job completion)
 that was emitted in the middle of the big base64 block.
 Adding the sync; sleep 10 part below should avoid that in the future:

 Instead of the usual %check rule,

   make %{?_smp_mflags} check

 I now use this, when needed:

   # After a failed make check, tar up, compress and base64-encode all results
   # The sync; sleep 10 should ensure that no async output is printed
   # in the middle of the big base64 block.
   make %{?_smp_mflags} check \
 || { st=$?; tar cf - . | xz -9 | base64; sync; sleep 10; exit $st; }

In retrospect, the sync should not be needed.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Possible to access Koji build directory?

[Jim Meyering]

Jan Kratochvil wrote:
 On Fri, 16 Mar 2012 11:16:51 +0100, Jim Meyering wrote:
 That works very well.  However, the base64 output in my first log was
 corrupt, due to some asynchronous output (stderr about job completion)
 that was emitted in the middle of the big base64 block.
 Adding the sync; sleep 10 part below should avoid that in the future:

 FYI using automatic killer of leftover processes as some of them never 
 finished
 and blocked builds, in other cases they kept running busy on build boxes etc.

 # Cleanup any leftover testsuite processes as it may stuck mock(1) builds.
 #
 http://pkgs.fedoraproject.org/gitweb/?p=gdb.git;a=blob_plain;f=gdb-orphanripper.c;hb=master
 Source2: gdb-orphanripper.c
 gcc -o ./orphanripper %{SOURCE2} -Wall -lutil -ggdb2
 ./orphanripper make %{?_smp_mflags} -k $CHECK || :

Hi Jan,

Nice program.  Thanks for sharing.
However, I would suggest that any make check-spawned process that
does not terminate is a test script bug that should be fixed upstream,
e.g., by prefixing the command with timeout $n_seconds for some
reasonable number of seconds.

Even though some systems lack timeout (introduced in coreutils-7.0 2008-10-05)
I still use it (e.g., in grep) along with an invocation of this function:

  require_timeout_()
  {
( timeout 10s true )  /dev/null 21 \
  || skip_ your system lacks the timeout program
timeout 10s false; test $? = 1 \
  || skip_ your system has a non-GNU timeout program
  }

Then, the test is simply skipped on a system without timeout.

Of course, if upstream cannot be bothered to correct the tests,
it's sure good to have your orphanripper program.  Just don't
let it serve as an excuse to write sloppy tests.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

FAT and HFS/HFS+ file system resizing restored in parted-3.1

[Jim Meyering]

FYI, I released parted-3.1 yesterday,

http://thread.gmane.org/gmane.comp.gnu.parted.bugs/10790

In addition to pretty many bug fixes,

This is to announce parted-3.1, a bug fix release that also reintroduces
a minimal subset of the file system resizing capability that was removed
in 3.0.  It adds a new, separate library, libparted-fs-resize, that
provides for resizing of FAT and HFS/HFS+ file systems.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Some fedora projects are still not using transifex (properly)

[Jim Meyering]

Kévin Raymond wrote:
 I've managed to get the whole list of transifex.net projects who appears
 dead, here they are:
...
 [D] iwhd

I deliberately switched iwhd from transifex to http://translationproject.org
because the latter provides anonymous rsync access, while transifex requires
that one register and use an account merely to download translations:

http://trac.transifex.org/ticket/740

If you're used to version-controlling your project's .po files, you may
not see the point, since then, downloading .po files is usually done only
by the maintainer.  However, if you do not VC the .po files, but rather
pull them via a bootstrap script, as done by upstream coreutils, grep,
diffutils, parted, etc., then everyone who builds from a just-cloned
directory must download the .po files.  I don't want to impose the
burden of registering on those folks.

http://thread.gmane.org/gmane.comp.lib.iwhd.devel/1047
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: /usrmove? - about the future

[Jim Meyering]

Matthew Garrett wrote:
 On Wed, Feb 15, 2012 at 07:23:24PM -0500, Steve Clark wrote:
 On 02/15/2012 05:19 PM, mike cloaked wrote:
 I use bash completion all the time every single day - I guess I have
 become a corner case!
 
 No you haven't. All the developers I have worked with since the
 early nineties use it all the
 time every day. We would be lost without it.

 You may have been working with them since the earliy nineties, but the
 feature was only introduced in 2.04 in 2000. Programmable completion
 is fairly modern compared to the rest of bash...

That was one of the reasons I switched to zsh.
It had far superior completion back then.
Bash has closed the gap, since.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: /usrmove and path ordering

[Jim Meyering]

Reindl Harald wrote:
 Am 15.02.2012 13:43, schrieb Martin Langhoff:
 On Feb 15, 2012 6:16 AM, Reindl Harald h.rei...@thelounge.net
 mailto:h.rei...@thelounge.net wrote:
 there is no single reason for a feature like /usrmove which
 in fact nobody NEEDS at all and definitly not now to press
 it into the next release with pressure

 You are wrong. The /usr move has a very clear impact in being able
 to snapshot your OS install partition. Add
 btrfs, yum hooks and the already-implemented stateless
 configuration and you have a really major feature: a fully
 upgrade/test/rollback setup for Fedora.

 only one out of a million installations have /usr seperated
 from / and the default is NOT do this - so no there is no
 impact on any normal setup

Prior to F17, I've always put /usr on a partition separate from /.

$ df -hT / /usr
Filesystem Type  Size  Used Avail Use% Mounted on
/dev/sda4  ext4   11G  7.3G  3.2G  70% /
/dev/sda6  ext4   10G  7.3G  2.3G  77% /usr

I know I'm special ;-), but *that* special?  I doubt it.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: /usrmove and path ordering

[Jim Meyering]

Simo Sorce wrote:
 On Thu, 2012-02-16 at 13:22 +0100, Jim Meyering wrote:
...
 Prior to F17, I've always put /usr on a partition separate from /.

 $ df -hT / /usr
 Filesystem Type  Size  Used Avail Use% Mounted on
 /dev/sda4  ext4   11G  7.3G  3.2G  70% /
 /dev/sda6  ext4   10G  7.3G  2.3G  77% /usr

 I know I'm special ;-), but *that* special?  I doubt it.

 I guess it is time to change habits, what's the point of a separate /usr
 these days ?

I like to keep / very small, separate and mostly read-only, so that
when something goes wrong with the disk it's less likely to affect
the root partition, so I'm all for the implicit writable/read-only
segregation this implies.

/usrmove is a clear win.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Does anyone still need to create legacy HFS filesystems?

[Jim Meyering]

Matthew Garrett wrote:
 There's various issues with the hfsplus utilities we ship at the moment,
 including the fact that fsck.hfsplus crashes on 64-bit. I'd like to

Glad you're looking at this.  I noticed that recently, too.
I wanted to use fsck.hfsplus in a test to verify that parted's
newly-revived FS-resizing code produces something reasonable,
but fsck.hfsplus itself segfaults.

Can you point me to the latest upstream sources?

I started with the fedora spec file from hfsplus-tools (since that
provides /sbin/fsck.hfs), but its URL is now invalid:

Source0: 
http://darwinsource.opendarwin.org/tarballs/apsl/diskdev_cmds-%{version}.tar.gz

Searching around, I ended up at this hg repo:
  https://bitbucket.org/jtotz/hfsprogs
but have my doubts...
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Does anyone still need to create legacy HFS filesystems?

[Jim Meyering]

Matthew Garrett wrote:
 On Fri, Feb 03, 2012 at 02:56:51PM +0100, Jim Meyering wrote:

 Can you point me to the latest upstream sources?

 git://cavan.codon.org.uk/hfsplus-tools.git - it needs clang to build.

Thanks.
I built it, and when using that version of fsck.hfs,
my new parted test passes.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Does anyone still need to create legacy HFS filesystems?

[Jim Meyering]

Chris Murphy wrote:

 On Feb 3, 2012, at 6:56 AM, Jim Meyering wrote:

 Matthew Garrett wrote:
 There's various issues with the hfsplus utilities we ship at the moment,
 including the fact that fsck.hfsplus crashes on 64-bit. I'd like to

 Glad you're looking at this.  I noticed that recently, too.
 I wanted to use fsck.hfsplus in a test to verify that parted's
 newly-revived FS-resizing code produces something reasonable,
 but fsck.hfsplus itself segfaults.

 On the issue of HFSJ resizing, I may have found a major discrepancy
 between reality and Apple's documentation. I'm skeptical that the
 current resizing code is going to work on large disks at all until
 it's updated to handle a jhdr_size of 4096 bytes for disks with a 512
 byte sector size. Presently the code interprets jhdr_size as the
 disk's sector size. A difference between the two causes resizing to
 fail. I'm seeing resizing fail with virtual and real disks of 2TB or
 greater in size. I do not know what the failure threshold is in terms
 of volume or disk size, but it appears jhdr_size depends on the size
 of the volume, not the size of the disk sectors, contrary to Apple's
 documentation.


 http://developer.apple.com/legacy/mac/library/#technotes/tn/tn1150.html

 jhdr_size - The size of the journal header, in bytes. The journal
 header always occupies exactly one sector so that it can be updated
 atomically. Therefore, this value is equal to the sector size (for
 example, 2048 on many types of optical media).

Right.  The code explicitly rejects any attempt to resize a partition
on a disk with sector size != 512.  Due to this confusion with
jhdr_size, at least for now, I do not plan to change that bit.

Maybe someone who is motivated and capable will submit a patch,
once the resizing code is back on parted's master branch.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: SELinux-related Rawhide breakage today

[Jim Meyering]

Daniel J Walsh wrote:

 On 01/31/2012 12:07 PM, Jerry James wrote:
 After installing today's Rawhide updates on an x86_64 VM, I
 started having troubles running programs.  Nothing linked with
 libselinux.so.1 could actually open that library; the programs were
 getting EACCESS on the attempt.  I figured I needed to do a
 relabel, but since restorecon is linked with libselinux.so.1,
 .

 I touched /.autorelabel and rebooted.  The system couldn't even
 shut down, so I had to do a sync and a forced shutoff.  When the
 system came back up, it immediately started complaining about lots
 of programs that were unable to load libcrypt.  So I forced it off
 again and rebooted with enforcing=0.  That worked, but skipped the
 relabeling step!  I got a root shell and ran restorecon by hand to
 relabel.  The only file that got relabeled was this, which looks
 wrong:

 restorecon reset /lib64/libproc-3.2.8.so context
 system_u:object_r:lib_t:s0-system_u:object_r:default_t:s0

 Is something broken in SELinux land today?

 Yes we have shipped a policy that requires the usrmove functionality.

 If you add

 /lib64 /lib

 to

 /etc/selinux/targeted/contexts/files/file_contexts.subs_dist

 Then run restorecon -R -v /lib64

Thanks for the heads up.
I had just pulled the latest updates and found that I couldn't
ssh to that box at all -- console didn't work, either.
Luckily I still had the root ssh session from which I'd done the update.

In it, I confirmed the /lib64 /lib line is already present in that
file, presumably since I've just updated, and did this to recover:

setenforce 0
  restorecon -R -v /lib64
setenforce 1

Without the setenforce 0, restorecon would fail due to this:

# restorecon -R -v /lib64
restorecon: error while loading shared libraries: libselinux.so.1: cannot 
open shared object file: No such file or directory
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

FYI: new rawhide boot failure

[Jim Meyering]

Just a heads up.
I usually update a rawhide VM daily and reboot at least once or twice
a week.  Today space was getting a little low on the parent partition,
so I stopped the VM in order to run virt-sparsify on its image.
Nice: that saved 3GB.  Booting again, however, there were numerous
service-start failures and it never reached a point where I could get
into it.  I tried again, using the original image, just in case, but
it failed the same way.  Finally, I resorted to adding enforcing=0
on the boot command line.  With that, it started.

There are a bunch of AVCs in /var/log/audit/audit.log.
The first three were these:

type=AVC msg=audit(1326440396.499:393): avc:  denied  { syslog_mod } for  
pid=415 comm=systemd-journal scontext=system_u:system_r:init_t:s0 
tcontext=system_u:system_r:kernel_t:s0 tclass=system
type=AVC msg=audit(1326440397.097:394): avc:  denied  { sendto } for  pid=1146 
comm=dbus-daemon path=/dev/log 
scontext=system_u:system_r:xdm_dbusd_t:s0-s0:c0.c1023 
tcontext=system_u:system_r:init_t:s0 tclass=unix_dgram_socket
type=AVC msg=audit(1326440397.097:395): avc:  denied  { sendto } for  pid=939 
comm=dbus-daemon path=/dev/log 
scontext=system_u:system_r:xdm_dbusd_t:s0-s0:c0.c1023 
tcontext=system_u:system_r:init_t:s0 tclass=unix_dgram_socket

followed by 14 like this:

type=AVC msg=audit(1326444676.387:32): avc:  denied  { setuid } for  pid=382 
comm=systemd-journal capability=7  scontext=system_u:system_r:syslogd_t:s0 
tcontext=system_u:system_r:syslogd_t:s0 tclass=capability
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: FYI: new rawhide boot failure

[Jim Meyering]

Daniel J Walsh wrote:
 On 01/13/2012 11:42 AM, Daniel J Walsh wrote:
 On 01/13/2012 06:59 AM, Frank Murphy wrote:
 On 13/01/12 11:46, Jim Meyering wrote:
 Just a heads up.

 Ran into it yesterday:
 https://lists.fedoraproject.org/pipermail/test/2012-January/105084.html

  Thought it was systemd update from day before, but maybe it's
 the selinux\policy update.


 It is caused by the systemd update, we are building an SELinux
 policy to fix the problems.
 selinux-policy-3.10.0-74.2.fc17 is in Koji if anyone wants to try it
 out and see if they can successfully boot in enforcing mode.

Hi Dan,
Thanks for the quick work.
I've just done the following in an empty directory:

koji download-build selinux-policy-3.10.0-74.2.fc17
yum install *.rpm

I like the Complete! message at the end, but wonder if I should
worry about the intermediate /usr/sbin/semodule: Failed! message.

Here's the complete output:

-
Loaded plugins: auto-update-debuginfo, langpacks, presto, refresh-packagekit
Setting up Install Process
Examining selinux-policy-3.10.0-74.2.fc17.noarch.rpm: 
selinux-policy-3.10.0-74.2.fc17.noarch
Marking selinux-policy-3.10.0-74.2.fc17.noarch.rpm as an update to 
selinux-policy-3.10.0-74.fc17.noarch
Examining selinux-policy-3.10.0-74.2.fc17.src.rpm: 
selinux-policy-3.10.0-74.2.fc17.src
Cannot add package selinux-policy-3.10.0-74.2.fc17.src.rpm to transaction. Not 
a compatible architecture: src
Examining selinux-policy-doc-3.10.0-74.2.fc17.noarch.rpm: 
selinux-policy-doc-3.10.0-74.2.fc17.noarch
Marking selinux-policy-doc-3.10.0-74.2.fc17.noarch.rpm to be installed
Examining selinux-policy-minimum-3.10.0-74.2.fc17.noarch.rpm: 
selinux-policy-minimum-3.10.0-74.2.fc17.noarch
Marking selinux-policy-minimum-3.10.0-74.2.fc17.noarch.rpm to be installed
Examining selinux-policy-mls-3.10.0-74.2.fc17.noarch.rpm: 
selinux-policy-mls-3.10.0-74.2.fc17.noarch
Marking selinux-policy-mls-3.10.0-74.2.fc17.noarch.rpm to be installed
Examining selinux-policy-targeted-3.10.0-74.2.fc17.noarch.rpm: 
selinux-policy-targeted-3.10.0-74.2.fc17.noarch
Marking selinux-policy-targeted-3.10.0-74.2.fc17.noarch.rpm as an update to 
selinux-policy-targeted-3.10.0-74.fc17.noarch
Resolving Dependencies
-- Running transaction check
--- Package selinux-policy.noarch 0:3.10.0-74.fc17 will be updated
--- Package selinux-policy.noarch 0:3.10.0-74.2.fc17 will be an update
--- Package selinux-policy-doc.noarch 0:3.10.0-74.2.fc17 will be installed
--- Package selinux-policy-minimum.noarch 0:3.10.0-74.2.fc17 will be installed
--- Package selinux-policy-mls.noarch 0:3.10.0-74.2.fc17 will be installed
-- Processing Dependency: policycoreutils-newrole = 2.1.9-4 for package: 
selinux-policy-mls-3.10.0-74.2.fc17.noarch
-- Processing Dependency: setransd for package: 
selinux-policy-mls-3.10.0-74.2.fc17.noarch
--- Package selinux-policy-targeted.noarch 0:3.10.0-74.fc17 will be updated
--- Package selinux-policy-targeted.noarch 0:3.10.0-74.2.fc17 will be an update
-- Running transaction check
--- Package mcstrans.x86_64 0:0.3.2-1.fc15 will be installed
--- Package policycoreutils-newrole.x86_64 0:2.1.10-5.fc17 will be installed
-- Finished Dependency Resolution

Dependencies Resolved

=
 Package Arch   Version  Repository Size
=
Installing:
 selinux-policy-doc  noarch 3.10.0-74.2.fc17 
/selinux-policy-doc-3.10.0-74.2.fc17.noarch
14 M
 selinux-policy-minimum  noarch 3.10.0-74.2.fc17 
/selinux-policy-minimum-3.10.0-74.2.fc17.noarch
   8.1 M
 selinux-policy-mls  noarch 3.10.0-74.2.fc17 
/selinux-policy-mls-3.10.0-74.2.fc17.noarch
   7.8 M
Updating:
 selinux-policy  noarch 3.10.0-74.2.fc17 
/selinux-policy-3.10.0-74.2.fc17.noarch
   8.9 M
 selinux-policy-targeted noarch 3.10.0-74.2.fc17 
/selinux-policy-targeted-3.10.0-74.2.fc17.noarch
   8.1 M
Installing for dependencies:
 mcstransx86_64 0.3.2-1.fc15 rawhide98 k
 policycoreutils-newrole x86_64 2.1.10-5.fc17rawhide   122 k

Transaction Summary
=
Install  3 Packages (+2 Dependent packages)
Upgrade  2 Packages

Total size: 47 M
Total download size: 220 k
Is this ok [y/N]: y
Downloading Packages:
(1/2): mcstrans-0.3.2-1.fc15.x86_64.rpm   |  98 kB 00:00
(2/2): policycoreutils-newrole-2.1.10-5.fc17.x86_64.rpm   | 122 kB 00:00

Re: FYI: new rawhide boot failure

[Jim Meyering]

Daniel J Walsh wrote:
 On 01/13/2012 01:17 PM, Jim Meyering wrote:
 Daniel J Walsh wrote:
 On 01/13/2012 11:42 AM, Daniel J Walsh wrote:
 On 01/13/2012 06:59 AM, Frank Murphy wrote:
 On 13/01/12 11:46, Jim Meyering wrote:
 Just a heads up.

 Ran into it yesterday:
 https://lists.fedoraproject.org/pipermail/test/2012-January/105084.html



 Thought it was systemd update from day before, but maybe it's
 the selinux\policy update.


 It is caused by the systemd update, we are building an SELinux
 policy to fix the problems.
 selinux-policy-3.10.0-74.2.fc17 is in Koji if anyone wants to try
 it out and see if they can successfully boot in enforcing mode.

 Hi Dan, Thanks for the quick work. I've just done the following in
 an empty directory:

 koji download-build selinux-policy-3.10.0-74.2.fc17 yum install
 *.rpm

 I like the Complete! message at the end, but wonder if I should
 worry about the intermediate /usr/sbin/semodule: Failed!
 message.

I went ahead and rebooted.
It worked like a charm.

Thanks again.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-4.7.0-0.1.fc17

[Jim Meyering]

Jakub Jelinek wrote:
 On Mon, Jan 02, 2012 at 07:03:44PM +0100, Jim Meyering wrote:

 I have just tried to build iwhd on F16 using a pretty recent gcc-4.7.x
 (built manually: 4.7.0 20111202), and it worked fine, so I'm not quite
 sure why iwhd is on the list.  Maybe the gcc-4.7.x that Jakub used
 lacks something that's in my Dec 2 snapshot, or maybe it's simply a
 problem in a dependent that has been fixed in the interim.

 iwhd was in the totally non-analyzed lists, which built normally
 in rawhide x86_64 mock and failed to build with
 that plus my gcc 4.7.0 + libtool repo.
 The failure was:
 checking gc.h presence... yes
 checking for gc.h... yes
 checking for mongo/client/dbclient.h... no
 configure: error: Missing Mongo DB client development library: mongodb-devel
 error: Bad exit status from /var/tmp/rpm-tmp.ndPEGn (%build)
 Bad exit status from /var/tmp/rpm-tmp.ndPEGn (%build)
 RPM build errors:
 Child returncode was: 1

Hi Jakub,

Thanks for the details.
Sorry if my post made it look like a request for
more information from you.  At first, it was -- sort of --
but then I realized and explained that it was my own problem
for not putting the latest iwhd in rawhide.

 Given the huge amount of packages, I really don't have time to look
 at every one, the mass rebuild was performed mainly to determine
 gcc 4.7 readiness and find out most common porting issues when porting
 from 4.6 to 4.7.  The rebuilds were all done using mock, while with the
 same set of package NVRs (taken from 23rd SRPMS list), the rawhide distro
 could very well be slightly changing even over the period of the few
 days it took to rebuild everything.

 BTW, the stdbool configury problem I wrote about is solved on the
 gcc side, we optimize again the (not strictly valid) test and thus
 the standard autoconf 2.6[0-7] stdbool detection should work again.

Thanks for all the work.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-4.7.0-0.1.fc17

[Jim Meyering]

Denis Arnaud wrote:
 Hi Jim,

 2012/1/3 devel-requ...@lists.fedoraproject.org

 Is there some sort of reminder service that could be configured to nag the
 maintainers of a package in a situation like this? Personally, I would
 appreciate it, and I think Fedora would benefit if we could do something 
 to
 minimize reverse-version skew between Fedora-latest and rawhide.

 Hmmm. Would something like that: http://autoqa.fedoraproject.org/results/
 247409-autotest/qa01.qa.fedoraproject.org/upgradepath/results/
 iwhd-1.2-1.fc16.html* do the job for you? The associated explanations are 
 quite

Hi Denis,

That looks perfect.

 clear: https://fedoraproject.org/wiki/AutoQA_tests/Upgradepath
 To play devil's advocate, the first time I received such an email from the
 AutoQA bot, I did not fully understand what it meant...

 Regards

 Denis

 *: simply found by looking within the package update page (https://
 admin.fedoraproject.org/updates/FEDORA-2011-16933/iwhd-1.2-1.fc16), and for
 which you should have received a mail with a few explanations

Thanks for the pointers.

By running this command, I have signed up for iwhd-related
notifications in F-16 and rawhide:

ssh fedorapeople.org autoqa-optin iwhd devel F-16
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-4.7.0-0.1.fc17

[Jim Meyering]

Nils Philippsen wrote:
...
 I've attached a list of packages and (co)maintainers, to easily find if
 one of your packages is affected or not.
...
 iwhd: meyering - clalance,zaitcev

Thank you for the list.

I have just tried to build iwhd on F16 using a pretty recent gcc-4.7.x
(built manually: 4.7.0 20111202), and it worked fine, so I'm not quite
sure why iwhd is on the list.  Maybe the gcc-4.7.x that Jakub used
lacks something that's in my Dec 2 snapshot, or maybe it's simply a
problem in a dependent that has been fixed in the interim.

Oh!!! I see it.
The tested version (the one in rawhide) is iwhd-1.1,
while the latest is 1.2 (which is in F16).  Shame on me
for not putting the latest also in rawhide.

Is there some sort of reminder service that could be configured
to nag the maintainers of a package in a situation like this?
Personally, I would appreciate it, and I think Fedora would
benefit if we could do something to minimize reverse-version
skew between Fedora-latest and rawhide.

Even if it's just a weekly posting of offenders to fedora-devel,
so people know it's an issue...
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: epel 6 fedpkg build or koji scratch builds failing — I'm stumped

[Jim Meyering]

Richard W.M. Jones wrote:
 On Thu, Nov 24, 2011 at 03:01:03PM +, Paul Howarth wrote:
 http://marc.info/?l=pptpclient-develm=132102054518031

 This is indeed rather unexpected behaviour of make!

 BTW I think your patch is incomplete, since it will create an
 incomplete config.h if the disk runs out of space.  I think this would
 be better, and should also avoid the parallel make problem:

 config.h:
   echo /* text added by Makefile target config.h */  $@-t
   echo #define PPTP_LINUX_VERSION \$(VERSION)$(RELEASE)\  $@-t
   echo #define PPPD_BINARY \$(PPPD)\  $@-t
   echo #define IP_BINARY \$(IP)\  $@-t
   mv $@-t $@

Yes, that is better and does solve the problem.

Here's a good rule I've been following since I was first burned by this:
never redirect directly to a Makefile target. (where target means $@
or any literal that is equivalent).  That means redirect output to a
temporary file like Rich did above, and only when that process is known
to have succeeded do you rename the temporary file to $@.

However, I would volunteer some additional suggestions:

  - use a {...} group (cheaper than a (...) subshell) so we redirect only once;
that reduces the duplication of the $@-t, and eliminates the dichotomy
of the initial  $@-t, while all subsequent ones are  $@-t.

  - use outer single quotes so you don't have to backslash-escape the
inner double quote chars.  less syntax is more maintainable.

  - make the file read-only, so it is clearer that it is generated,
and thus harder to change accidentally.  The only down-side to
this part is that you then have to be careful to remove any
preexisting $@ or $@-t, since redirecting onto a read-only file
will often fail.

config.h:
rm -f $@ $@-t;  \
{   \
  echo '/* text added by Makefile target config.h */';  \
  echo '#define PPTP_LINUX_VERSION $(VERSION)$(RELEASE)'; \
  echo '#define PPPD_BINARY $(PPPD)'; \
  echo '#define IP_BINARY $(IP)'; \
}  $@-t  chmod a-w $@-t  mv $@-t $@
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: epel 6 fedpkg build or koji scratch builds failing — I'm stumped

[Jim Meyering]

Kaleb S. KEITHLEY wrote:
...
 Perhaps there's some extra fedpkg flag I should be using for epel builds?

 Perhaps try without parallel make?

 Yes, that makes it work.

 Thanks for the tip.

When running make from the command line, I always use -j$N, for 1  N.
But of course, I rarely type the -j option.
Not only do builds complete more quickly, but doing that
helps flush out problems like yours.

I run this shell code to create an alias:

  _make_init()
  {
local n=$(nproc 2/dev/null || getconf _NPROCESSORS_ONLN 2/dev/null)
test $n -gt 0 \
  || n=$(grep -c '^processor  :' /proc/cpuinfo 2/dev/null)
case $n in 0) n=1;; esac
local make_j=$((2 * $n + 1))
# Create an alias for make that uses -j$N, where $N is determined
# once at shell start-up.
alias make=make -j$make_j
  }
  _make_init
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [Test-Announce] Announcing the release of Fedora 16.

[Jim Meyering]

Rahul Sundaram wrote:
 On 11/08/2011 10:18 PM, Gerd Hoffmann wrote:
   Hi,

 Fedora 16 is not science fiction. It is here right now:
 http://get.fedoraproject.org

 Hmm, no jigdo downloads any more?

 Yes.  Would be nice to have this back.  It is not a big burden.  Is it?

I have used them, too.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

low-memory *printf deadlocks with latest glibc in -testing and rawhide

[Jim Meyering]

So far I've only noticed it via a test, but everyone uses *printf,
and malloc is implicated due to recent arena-related changes:

malloc deadlock makes *printf hang
http://bugzilla.redhat.com/753601

With glibc-2.14.90-15.2.x86_64 (f16-testing and rawhide), this hangs:

( ulimit -v 1; env printf %2000f 0 )

Hah!  As I was writing this, I noticed a new glibc commit.

http://sources.redhat.com/git/gitweb.cgi?p=glibc.git;a=commitdiff;h=a5fb313cb7b7e692fd4684916aaa98e03ec7e8b6

Thanks for the quick fix, Andreas!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Differences between koji and mock rawhide environments?

[Jim Meyering]

Richard Shaw wrote:
 On Wed, Nov 9, 2011 at 11:18 AM, Tom Lane t...@redhat.com wrote:
 postgresql is currently failing to rebuild in rawhide:
 http://koji.fedoraproject.org/koji/taskinfo?taskID=3499379
 This seems quite repeatable, in koji, but the package builds fine on my
 workstation under mock's fedora-rawhide-x86_64 and fedora-rawhide-i386
 environments.  Shouldn't this have exactly the same results?  Can anyone
 suggest how I might reproduce the failure someplace where I can debug it?

 I'm having a similar problem with OpenImageIO. I can build against TBB
 in a mock environment but it fails in koji.

I had a similar problem with iwhd.
All tests passed locally(F16), but make check in koji would always fail.
I ended up leaving %check disabled in the spec file.

Need to recheck...
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: BEWARE: a problematic glibc made it to stable (F16)

[Jim Meyering]

Adam Williamson wrote:
 ... The only breakage
 in one which was approved was to do with compiling things - which, sure,
 is a pain in the ass, but it's not the kind of problem critpath was
 introduced to deal with in the first place.

The problem is bigger than it first seemed, and still not fixed.

True, I noticed the problem initially when running a just-built git,
but in fact the distributed /usr/bin/git demonstrates precisely the
same heap corruption as the one I built.  See the further discussion
on http://bugzilla.redhat.com/747377

The underlying bug seems pthread-related.
When I make git grep run without using threads there is no problem.

To demonstrate the problem, run this on a multi-core system, in a
clone of a decent-sized git repository like git's own:

for i in $(seq 100);do echo $i; timeout 1 ./git grep -q stat;done
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: BEWARE: a problematic glibc made it to stable (F16)

[Jim Meyering]

Jim Meyering wrote:
 Adam Williamson wrote:
 ... The only breakage
 in one which was approved was to do with compiling things - which, sure,
 is a pain in the ass, but it's not the kind of problem critpath was
 introduced to deal with in the first place.

 The problem is bigger than it first seemed, and still not fixed.

 True, I noticed the problem initially when running a just-built git,
 but in fact the distributed /usr/bin/git demonstrates precisely the
 same heap corruption as the one I built.  See the further discussion
 on http://bugzilla.redhat.com/747377

 The underlying bug seems pthread-related.
 When I make git grep run without using threads there is no problem.

 To demonstrate the problem, run this on a multi-core system, in a
 clone of a decent-sized git repository like git's own:

 for i in $(seq 100);do echo $i; timeout 1 ./git grep -q stat;done

Oops.  Drop the ./, of course, to test /usr/bin/grep:

 for i in $(seq 100);do echo $i; timeout 1 git grep -q stat;done
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

BEWARE: a problematic glibc made it to stable (F16)

[Jim Meyering]

I spent too many hours debugging this today, so feel obliged to warn
about this.  Plus, I feel a little guilty for giving it positive
karma initially.  Today's -1 was too late.

glibc-2.14.90-12.999, which has just made it to stable provokes a
hard-to-diagnose (for me at least) problem.

While most things work, and it fixed two problems that affected me,
it caused me some frustration:

https//bugzilla.redhat.com/747377

TL;DR: while most things worked fine, and gcc even bootstrapped and
passed most of make check (I did that when I was wondering if I had
bad RAM), this version of glibc appears to make it so when you compile
git from cloned sources, the resulting git program evokes double frees,
arbitrary heap corruption, aborts, hangs, weird incomplete read errors,
etc.  But only when you compile with -O2, not with -O1 or less.

Now, you might think that this is all git's fault, and maybe glibc is
merely exposing it.  That may well be true.  Until we find the underlying
cause we won't know for sure.  However, I was surprised to see that
valgrind reported nothing, time after time, while glibc was obviously
detecting heap corruption.

To recover an F16 system that works better, I ran this:

  yum downgrade glibc glibc-static glibc-devel glibc-common glibc-headers \
glibc-utils nscd
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: BEWARE: a problematic glibc made it to stable (F16)

[Jim Meyering]

Simo Sorce wrote:
 On Wed, 2011-10-19 at 20:51 +0200, Jim Meyering wrote:
...
 To recover an F16 system that works better, I ran this:

   yum downgrade glibc glibc-static glibc-devel glibc-common glibc-headers \
 glibc-utils nscd

 What did you downgrade to ?
 AFAIK Several people had to downgrade from -11 because of nsswitch
 issues ... seem glibc is not in good shape :-(

That command brought me back to glibc-2.14.90-10.x86_64
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

openssh: no pre-release sanity check? [Re: ssh-to-rawhide hangs

[Jim Meyering]

darrell pfeifer wrote:
 Fails for me too, with the same error.

Thanks for confirming that.

I don't mean to be rude or inflammatory, but do have to wonder how such
a fundamentally-broken package was released -- even to rawhide.  In the
fedora openssh release process, isn't there some sort of sanity check
that would catch this before inflicting it on all rawhide users?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: openssh: no pre-release sanity check? [Re: ssh-to-rawhide hangs

[Jim Meyering]

Frank Murphy wrote:
 On 11/09/11 09:33, Jim Meyering wrote:
 darrell pfeifer wrote:
 Fails for me too, with the same error.

 Thanks for confirming that.

 I don't mean to be rude or inflammatory, but do have to wonder how such
 a fundamentally-broken package was released -- even to rawhide.  In the
 fedora openssh release process, isn't there some sort of sanity check
 that would catch this before inflicting it on all rawhide users?

 Is not rawhide the sanity check, even if used productively by many?

I was thinking of something more like make check (that would
run a test suite), or maintainer gives it a spin before releasing.
But maybe something about the maintainer's set-up was different
enough that those tests would all pass.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: openssh: no pre-release sanity check? [Re: ssh-to-rawhide hangs

[Jim Meyering]

Rahul Sundaram wrote:
 On 09/11/2011 02:13 PM, Frank Murphy wrote:
 Is not rawhide the sanity check, even if used productively by many?

 Not many and I think the branch being less fragile would certainly
 help.  If I know my system will still boot and I can access the network
 and my browser is enough for me to consider running Rawhide as my main
 system but I don't think we can rely on any of that now.

I run rawhide in a VM, update/reboot daily, and use it to
sanity-check most of the packages that I tend.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

ssh-to-rawhide hangs (uninterruptible) for 2 minutes, then fails

[Jim Meyering]

I cannot ssh to my rawhide VM today:

$ date; ssh r; date
Sat 2011-09-10 19:55:35 +0200
Write failed: Broken pipe
Sat 2011-09-10 19:57:35 +0200

Note the two-minute delay.
I was unable to interrupt it, nor suspend.  Very annoying.

Using the console, I see nothing in /var/log/messages
or /var/log/audit/*.

The above was using an agent.
The same thing happens without, but only after authentication.

If I repeat the above with -v, it always hangs right after
Entering interactive session.:

debug3: sign_and_send_pubkey: ---
debug1: Enabling compression at level 6.
debug1: Authentication succeeded (publickey).
Authenticated to r ([192.168.122.3]:22).
debug1: setting up multiplex master socket
debug2: fd 4 setting O_NONBLOCK
debug3: fd 4 is O_NONBLOCK
debug3: fd 4 is O_NONBLOCK
debug1: channel 0: new [/h/j/.ssh/sockets/22-r]
debug3: muxserver_listen: mux listener channel 0 fd 4
debug1: channel 1: new [client-session]
debug3: ssh_session2_open: channel_new: 1
debug2: channel 1: send open
debug1: Entering interactive session.

Just in case, I turned off compression via the client and retried.
Same result, but without the Enabling compression... line.

Next step was to turn off SELinux enforcing, just in case.
That didn't make a difference.

Then I turned on debugging with LogLevel DEBUG3, restarted sshd and
repeated the experiment.  Nothing obviously suspicious there, at least
not to my untrained eye.

This is with openssh-5.9p1-2.fc17.x86_64 (same for -server).

Filed as http://bugzilla.redhat.com/737295

Is anyone else seeing this?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

rm --no-traverse-mount-points [Re: stop rm at same-dev bind mounts

[Jim Meyering]

Thomas Moschny wrote:
 having a rm command accidentally removing 3/4 of my system yesterday,
 I am starting to wonder whether it is possible to have rm reliably
 stop at bind mounts. I know there is a --one-file-system option, but
 it is not working when the bind mount points to the same device:

 % cd /tmp
 % mkdir -p a/b c/d ; touch c/d/file ; mount --bind c a/b
 % find a
 a
 a/b
 a/b/d
 a/b/d/file
 % rm -rf --one-file-system a
 rm: cannot remove `a/b': Device or resource busy
 % find a
 a
 a/b

 `file' has been removed. Imho the name of the --one-file-system option
 is misleading as it only compares st_dev fields.

Thanks for the example, but I don't see how that option name is
misleading.  A file system is the thing you create with mkfs.
Even though normally there is only one mount point per file system,
the fact that with bind mounts there can be many doesn't change
the name of the thing occupying the underlying device: a file system.

I think you want a new option, say --no-traverse-mount-points.

 Besides filing a
 bug/enhancement ticket for coreutils, does someone know a reliable way
 to stop rm in such cases?

It would tell rm -r not to cross any mount point.  Rm would have to be
able to read at start-up the set of all mount points, or maybe only
the mount points for a given device the first time a new device is
encountered.  Then, it could easily and efficiently test whether each
directory processed is in that set.

I've Cc'd bug-coreutils, so this message will create a ticket in the
issue tracker: http://debbugs.gnu.org/coreutils.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: ssh-to-rawhide hangs (uninterruptible) for 2 minutes, then fails

[Jim Meyering]

Kevin Fenzi wrote:
 See:

 https://bugzilla.redhat.com/show_bug.cgi?id=735970

 Seems to just be broken in the 5.9 series. ;(

Thanks.  I've marked mine as a duplicate of that one.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

FYI, rawhide makes /usr/bin/install (matchpathcon) segfault

[Jim Meyering]

I was getting ready to release coreutils-8.13, after two pre-release snapshots,

http://thread.gmane.org/gmane.comp.gnu.coreutils.general/1554
http://thread.gmane.org/gmane.comp.gnu.coreutils.general/1631

when I went to make sure its tests all pass also on rawhide.
I test that regularly, and they've all been passing (of course), so I
didn't expect any surprises.  I certainly didn't expect 7 failures,
and never something as basic as this:

$ touch a
$ env -i /usr/bin/install a b
zsh: segmentation fault  env -i /usr/bin/install a b
[Exit 139 (SEGV)]

[the env -i  prefix is just to ensure that none of my MALLOC_DEBUG_
 or MALLOC_PERTURB_ settings (or any other envvar) is causing trouble. ]

gdb shows that it's officially a NULL-deref, but says there's a
Corrupted DWARF expression, probably discovered in read_sleb128:

$ env -i gdb -q --args /usr/bin/install a b
Reading symbols from /usr/bin/install...Reading symbols from 
/usr/lib/debug/usr/bin/install.debug...done.
done.
(gdb) r
Starting program: /usr/bin/install a b
[Thread debugging using libthread_db enabled]
Using host libthread_db library /lib64/libthread_db.so.1.

Program received signal SIGSEGV, Segmentation fault.
__strtok_r_1c (__nextp=read_sleb128: Corrupted DWARF expression.
) at /usr/include/bits/string2.h:1179
1179  while (*__s == __sep)
(gdb) p __s
$1 = 0x0
(gdb) bt
#0  __strtok_r_1c (__nextp=read_sleb128: Corrupted DWARF expression.
) at /usr/include/bits/string2.h:1179
#1  init (rec=0x626930, opts=0x77fe2718, n=optimized out)
at label_file.c:440
#2  0x77bc4b3d in selabel_open (backend=0, opts=0x77fe2718,
nopts=5) at label.c:165
#3  0x77bc3e16 in matchpathcon_init_prefix_internal (path=0x0,
subset=0x0) at matchpathcon.c:321
#4  0x77bc40a9 in matchpathcon (path=0x7fffefbf b, mode=33261,
con=0x7fffeb98) at matchpathcon.c:406
#5  0x0040452f in setdefaultfilecon (file=0x7fffefbf b)
at install.c:345
#6  change_attributes (name=0x7fffefbf b) at install.c:471
#7  install_file_in_file (from=optimized out, to=0x7fffefbf b,
x=optimized out) at install.c:672
#8  0x00403cd6 in main (argc=optimized out, argv=optimized out)
at install.c:978
(gdb)

So install is just the messenger, since it's calling libselinux's
matchpathcon function, in which all of this is happening.
Given the dwarf corruption, libselinux may be a messenger, too,
but for now, I've just put all this in a BZ:

  http://bugzilla.redhat.com/736259

This seems so fundamental that I have to wonder if it's
something specific to my own set-up...
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: FYI, rawhide makes /usr/bin/install (matchpathcon) segfault

[Jim Meyering]

Jim Meyering wrote:
...
 $ touch a  $ env -i /usr/bin/install a b
 zsh: segmentation fault  env -i /usr/bin/install a b
 [Exit 139 (SEGV)]

Rich Jones found that updating to libselinux-2.1.5-2.fc17.x86_64
made it so he too sees the above failure.

   http://bugzilla.redhat.com/736259

For any of you who are already affected, you may be wondering how
automated tools will install fixed versions without a working install
program.  At least I was.

There may well be a simpler solution, like using a small install-simulating
script, but I'm inclined to use the real install program, with a
minimal adjustment:
===

Build the latest coreutils from source, but with a small twist
to disable the offending matchpathcon calls:

Get the sources, from a link here:

http://thread.gmane.org/gmane.comp.gnu.coreutils.general/1631

e.g.,

wget http://people.redhat.com/meyering/cu/coreutils-ss.tar.xz
wget http://people.redhat.com/meyering/cu/coreutils-ss.tar.xz.sig

Verify the signature before unpacking:

gpg --verify coreutils-ss.tar.xz.sig

Unpack (as non-root, of course):

tar xf coreutils-ss.tar.xz  cd coreutils-8.12*

Configure and build with one added definition.
This overrides the ginstall_CPPFLAGS = -DENABLE_MATCHPATHCON=1
setting in src/Makefile.am:

./configure  make ginstall_CPPFLAGS=

Verify that the just-built install binary works:
(or also run make check for the whole test suite)

touch a; src/ginstall a b

Install it, replacing your temporarily-broken one:

sudo src/ginstall src/ginstall /usr/bin/install
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: FYI, rawhide makes /usr/bin/install (matchpathcon) segfault

[Jim Meyering]

Richard W.M. Jones wrote:
 On Wed, Sep 07, 2011 at 01:44:36PM +0200, Jim Meyering wrote:
 Jim Meyering wrote:
 ...
  $ touch a  $ env -i /usr/bin/install a b
  zsh: segmentation fault  env -i /usr/bin/install a b
  [Exit 139 (SEGV)]

 Rich Jones found that updating to libselinux-2.1.5-2.fc17.x86_64
 made it so he too sees the above failure.

 [...]

 Instead of this workaround, can we ask rel-eng to untag the
 broken libselinux update?

Good idea.
Done: https://fedorahosted.org/rel-eng/ticket/4914
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: FYI, rawhide makes /usr/bin/install (matchpathcon) segfault

[Jim Meyering]

Daniel J Walsh wrote:
...
 Grab libselinux-2.1.5-3.fc17 out of koji, should fix the problem.

Thanks.  That solved it for me.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [PATCH] macros: Globally add --disable-silent-rules to configure

[Jim Meyering]

Jan Kratochvil wrote:
 On Tue, 09 Aug 2011 19:45:15 +0200, Matthew Garrett wrote:
 If a package fails to build in a mass rebuild because -Werror was enabled
 then that's additional work for several people to fix something that may not
 have ever actually been broken.

 99% of warnings will not lead to user visible bugs.  Finding that remaining
 1% of bugs (warnings) takes more than 100x time than to fix the warnings.

 I base my -Werror recommendation on this assumption, YMMV.

Nice argument.  I agree wholeheartedly with your numbers and with
the recommendation to use -Werror and as many -W___ options as
you/upstream can bear.

However, it does depend on the version of gcc you use, especially if
you use some of the newer warning options.  Not too long ago, coreutils
was getting invalid warning/errors from F15's gcc 4.6.x.  Luckily, the
bug was fixed in gcc-4.7.x, so I opted to use the newer gcc and retain
those rather aggressive warnings.  Besides, they're enabled only when
you configure coreutils with --enable-gcc-warnings.

Whether to invest in enabling -Werror for all packages in a mass rebuild
however is another question.  There will be many build failures, and
some will be unwarranted.  Having non-upstream take time to avoid the
warnings may not be productive, since there are many ways to avoid them,
and the way you choose may not suit upstream.  Also, do you want to
invest in avoiding warnings that affect only test-related code?

That said, if there are thick-skinned volunteers with the expertise and
enough time/energy, enabling -Werror globally (or even in a few selected
packages) and addressing failures would be great.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [PATCH] macros: Globally add --disable-silent-rules to configure

[Jim Meyering]

Ralf Corsepius wrote:
 On 08/13/2011 10:51 AM, Jim Meyering wrote:
 Whether to invest in enabling -Werror for all packages in a mass rebuild
 however is another question.

 Pardon, but this is not a question, this is beyond reason and foolish.

 There will be many build failures, and
 some will be unwarranted.

 Exactly ... and ... depending upon the gcc version, OS and
 architecture being in use, many of them will be bogus.

 That said, if there are thick-skinned volunteers with the expertise and
 enough time/energy, enabling -Werror globally (or even in a few selected
 packages) and addressing failures would be great.
 Well, I don't see any thing great in this proposal - I find is silly
 and not even close to being discussworthy.

Hi Ralf,

Your opinion might carry more weight if you backed up your
abrasive comments with data, code or anything else that might be
construed as constructive.  Toning down the abrasiveness (or, gasp!
even trying to seem pleasant) would also have the advantage of
encouraging people to participate rather than pushing them away.

Whether to use -Werror as proposed really is not a black and white
issue.  It all depends on which warnings are enabled along with -Werror.
Obviously, if you enable no other warning option, then there's no risk
at all.  If we're talking about just a few that are carefully chosen
to minimize false positives, then a large percentage of the resulting
build failures will correspond to real bugs.

I'd start with -O2 -D_FORTIFY_SOURCE=2 and something like
this subset of -Wall:

  -Warray-bounds
  -Wchar-subscripts
  -Wsequence-point

That's just off the top of my head, since those are useful and, IME,
seldom provoke false positives.  Note also that if you choose carefully,
then compiler/glibc versions need not come into play.  It's only if
you choose brand new (or otherwise unstable) warning options that the
version of the compiler matters.

Once you've resolved all of those, start adding ones like -Wformat=2 that,
while still very useful, do evoke more false positives.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

rawhide openssh-server update kills sshd

[Jim Meyering]

FYI, I've just yum-updated my rawhide VM to the latest
(but not from the console) and was surprised to lose the connection
while it was happening.  Again.  It happened to me last week, too.

I got back in via the console and tried to reinstall it via yum
reinstall openssh-server.  That failed (sorry, didn't record the diagnostic).

Just dug a little and found this was reported a week ago:

   http://bugzilla.redhat.com/722625

To fix it, I did this (from a console, of course):

yum -y remove openssh-server 
yum -y install openssh-server 
service ssh restart
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rawhide openssh-server update kills sshd

[Jim Meyering]

Clyde E. Kunkel wrote:
 On 07/26/2011 12:22 PM, Jim Meyering wrote:
 snip
  service ssh restart

 Would that be:

 service sshd restart

Yes, thanks.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Rawhide: selinux: Unable to get valid context for username

[Jim Meyering]

Richard W.M. Jones wrote:
 Anyone seeing this error?  Unless I boot with enforcing=0, I see
 this error when I try to log in as any user:

   Unable to get valid context for username

 It seems like it's just started happening, since I upgraded something
 within the last 1-2 weeks.

Hi Rich,

I'm using 3.0-0.rc3.git5.1.fc16.x86_64 in enforcing mode (of course ;-)
and don't see any problem when logging in via ssh:

h$ ssh r date
Sun Jun 19 18:34:32 CEST 2011
h$ ssh r
Last login: Sun Jun 19 18:33:11 2011 from 192.168.122.1
r$  
:

Everything is up to date, at least wrt whatever mirror I'm using.
My shell on that system is zsh;  but I got the same result when
temporarily switching it to bash.

 Is there any way to debug this error further?

If you're seeing it on a console, strace agetty or whatever
you're using as the server.  If via ssh, strace sshd.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Linux kernel 3.0 + SELinux problem

[Jim Meyering]

Richard W.M. Jones wrote:
 On Wed, Jun 08, 2011 at 09:19:43PM -0500, Bruno Wolff III wrote:
 On Wed, Jun 08, 2011 at 17:01:07 -0600,
   Jerry James loganje...@gmail.com wrote:
  On Wed, Jun 8, 2011 at 4:58 PM, Tom London seli...@gmail.com wrote:
   See https://bugzilla.redhat.com/show_bug.cgi?id=711015
  
   Believe updated systemd is building.
 
  Would you believe I scanned the entire list of bugs against the
  kernel component looking for this, and never thought about looking
  at the systemd component?  Thanks, Tom!  I'll patiently wait for the
  new systemd.

 You should be able to get it out of koji now. I wasn't having much luck
 with the rc2 kernel though.

 This ftrace bug prevents the Rawhide kernel from booting about 20% of
 the time:

 https://bugzilla.redhat.com/show_bug.cgi?id=710921

Nice work, Rich!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

F15's /usr/include/rpc has disappeared; netdb.h uncompilable

[Jim Meyering]

Just a quick FYI:
If you haven't already gotten Fedora 15's latest glibc-headers package,
you may want to wait for 2.13.90-11.  Here's why:

glibc-headers-2.13.90-10.x86_64 no longer includes any of
the /usr/include/rpc/*.h files.

Contrast with glibc-headers-2.13.90-9.x86_64, where there are 18:
$ rpm -ql glibc-headers|grep -cw rpc
18

I noticed because now, anything that includes at least netdb.h
is no longer compilable:

$ echo '#include netdb.h'  k.c  gcc -c k.c
In file included from k.c:1:0:
/usr/include/netdb.h:33:24: fatal error: rpc/netdb.h: No such file or 
directory
compilation terminated.

Reported as http://bugzilla.redhat.com/702366
and http://bugzilla.redhat.com/702354
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: resolved [Re: heads up: new rawhide kernel doesn't boot for me

[Jim Meyering]

Harald Hoyer wrote:
 Am 08.04.2011 12:38, schrieb Jim Meyering:
 So maybe there *is* a bug to report after all:

 With TMPDIR pointing to a directory with context not like /tmp,
 the kernel's initramfs-building code fails and gives a diagnostic
 (calling it Non-fatal), but lets the installation of a losing
 kernel succeed.

 Then again... just don't do that ... root-gun-foot ...

Hi Harald,

That's one way to see it.
However, what are the odds that the offending code ignores
all write failures, and not just AVC-induced ones?

And what if you're unlucky enough to run out of space in /tmp
at just the wrong moment -- or what if someone malicious knows
about this?  Some script kiddies might think it's cool to make
the sysadmin install a broken kernel.  I hope you have
convenient and reliable console access to that server.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

resolved [Re: heads up: new rawhide kernel doesn't boot for me

[Jim Meyering]

Jim Meyering wrote:
 Daniel J Walsh wrote:
 On 04/07/2011 07:46 AM, Jim Meyering wrote:
 I updated my rawhide VM today (on F15 host), but it failed to reboot
 using the new kernel, vmlinuz-2.6.39-0.rc1.git5.0.fc16.x86_64
 I got a failure (VFS diagnostic complaining that the UUID-specified
 root partition was not available), then panic.

 Two subsequent attempts to reboot failed because even though I got
 to the grub kernel-selection menu, I was unable to get a response
 out of the interface, so couldn't select any other kernel or even
 edit a grub stanza.  Luckily for me, on the third attempt, grub's
 UI did respond to down-arrow and ENTER, so I could select
 the preceding kernel, and that one did manage to boot.

 If necessary (i.e., if it's not already fixed), I'll file a BZ.

 kernel-2.6.39-0.rc2.git0.0.fc16 Works for me.

 Good to know.  Thanks, Dan.

That one failed for me, too, in the same way.
I've just noticed that the grub.conf stanzas for the two losing kernels
lack an initrd initramfs-... line, so reinstalled the latest kernel:

# yum reinstall -y kernel
...
Downloading Packages:
kernel-2.6.39-0.rc2.git0.0.fc16.x86_64.rpm|  23 MB 01:38
Running Transaction Check
Running Transaction Test
Transaction Test Succeeded
Running Transaction
etckeeper: pre transaction commit
  Installing : kernel-2.6.39-0.rc2.git0.0.fc16.x86_641/1
Non-fatal POSTTRANS scriptlet failure in rpm package 
kernel-2.6.39-0.rc2.git0.0.fc16.x86_64
etckeeper: post transaction commit

Installed:
  kernel.x86_64 0:2.6.39-0.rc2.git0.0.fc16

Complete!

Still no initramfs.  That's definitely a problem.
I ran it one more time, this time while tailing /var/log/audit/audit.log,
which led me to the culprit: me.

I'm using a separate, memory-backed, private TMPDIR, e.g., /t/jt-3k07S5,
and had indeed set perms of /t, -- and its context via this,
  semanage fcontext -a -t tmp_t '/t(/.*)?
but had forgotten to set its context:
  chcon --ref /tmp /t

Once I fixed that, reinstalling the kernel did create the initramfs.

So maybe there *is* a bug to report after all:

With TMPDIR pointing to a directory with context not like /tmp,
the kernel's initramfs-building code fails and gives a diagnostic
(calling it Non-fatal), but lets the installation of a losing
kernel succeed.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

heads up: new rawhide kernel doesn't boot for me

[Jim Meyering]

I updated my rawhide VM today (on F15 host), but it failed to reboot
using the new kernel, vmlinuz-2.6.39-0.rc1.git5.0.fc16.x86_64
I got a failure (VFS diagnostic complaining that the UUID-specified
root partition was not available), then panic.

Two subsequent attempts to reboot failed because even though I got
to the grub kernel-selection menu, I was unable to get a response
out of the interface, so couldn't select any other kernel or even
edit a grub stanza.  Luckily for me, on the third attempt, grub's
UI did respond to down-arrow and ENTER, so I could select
the preceding kernel, and that one did manage to boot.

If necessary (i.e., if it's not already fixed), I'll file a BZ.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: heads up: new rawhide kernel doesn't boot for me

[Jim Meyering]

Daniel J Walsh wrote:
 On 04/07/2011 07:46 AM, Jim Meyering wrote:
 I updated my rawhide VM today (on F15 host), but it failed to reboot
 using the new kernel, vmlinuz-2.6.39-0.rc1.git5.0.fc16.x86_64
 I got a failure (VFS diagnostic complaining that the UUID-specified
 root partition was not available), then panic.

 Two subsequent attempts to reboot failed because even though I got
 to the grub kernel-selection menu, I was unable to get a response
 out of the interface, so couldn't select any other kernel or even
 edit a grub stanza.  Luckily for me, on the third attempt, grub's
 UI did respond to down-arrow and ENTER, so I could select
 the preceding kernel, and that one did manage to boot.

 If necessary (i.e., if it's not already fixed), I'll file a BZ.

 kernel-2.6.39-0.rc2.git0.0.fc16 Works for me.

Good to know.  Thanks, Dan.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: gcc-4.6.0-0.11.fc15.x86_64 breaks strcmp?

[Jim Meyering]

Richard W.M. Jones wrote:
 Compiling libguestfs using gcc-4.6.0-0.11.fc15.x86_64 gives lots of:

 error: assuming signed overflow does not occur when changing X +- C1 cmp C2 
 to X cmp C1 +- C2 [-Werror=strict-overflow]

 These seem to be associated with code that does 'if (strcmp (s1, s2) == 0)'

 For example:

 dir.c: In function ‘do_rm_rf’:
 dir.c:59:7: error: assuming signed overflow does not occur when changing X +- 
 C1 cmp C2 to X cmp C1 +- C2 [-Werror=strict-overflow]

 --
 int
 do_rm_rf (const char *path)
 {
   int r;
   char *buf, *err;

   if (STREQ (path, /)) {  -- here
 reply_with_error (cannot remove root directory);
 return -1;
   }
 --

 where STREQ is a simple macro:

 #define STREQ(a,b) (strcmp((a),(b)) == 0)

 AFAIK this code should be correct?  I can't find anything at all about
 this specific error from Google.

Hi Rich,

I suspect that there was a problem with .11, perhaps one of these:

* Fri Mar 04 2011 Jakub Jelinek ja...@redhat.com 4.6.0-0.12
- update from trunk
  - PRs c++/46159, c++/46282, c++/47200, c++/47774, c++/47851, c++/47950,
c++/47974, c/47963, libstdc++/47913, middle-end/47283,
rtl-optimization/47925, target/47935, tree-optimization/47890
- rebuilt against ppl 0.11.2, reenable cloog-ppl Requires

because I can't reproduce that with the latest in rawhide,
gcc-4.6.0-0.12.fc15.x86_64:

$ cat k.c  :
#define STREQ(a,b) (strcmp((a),(b)) == 0)

int
do_rm_rf (const char *path)
{
  int r;
  char *buf, *err;

  if (STREQ (path, /))
{
  reply_with_error (cannot remove root directory);
  return -1;
}
}
$ gcc -O3 -c k.c -Werror=strict-overflow   :
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: gcc-4.6.0-0.12.fc15.x86_64 breaks strcmp?

[Jim Meyering]

Adam Jackson wrote:

 On 3/7/11 10:35 AM, Richard W.M. Jones wrote:

 Below is how the failure line expands(!)

 Thanks, I needed a laugh this morning.

 If I do this as a minimal testcase:

 ---

 #include string.h
 #include stdio.h

 int
 do_rm_rf (const char *path)
 {
int r;
char *buf, *err;

if (!strcmp(path, /)) {
  printf (cannot remove root directory);
  return -1;
}

return 0;
 }

Shame on me.
I forgot string.h and -Wall ;-)

With the former and -O3, I do see your warning.
Here's a pared-down test case:

$ cat k.c
#include string.h
void do_rm_rf (const char *p) { if (strcmp (p, /) == 0) return; }
$ gcc -Wall -O3 -c k.c -Werror=strict-overflow
k.c: In function ‘do_rm_rf’:
k.c:2:1678: error: assuming signed overflow does not occur when changing X 
+- C1 cmp C2 to X cmp C1 +- C2 [-Werror=strict-overflow]
cc1: some warnings being treated as errors

[Exit 1]
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: fail to install gcc on fresh rawhide-from-F15

[Jim Meyering]

James Antill wrote:
 On Tue, 2011-02-22 at 22:38 +0100, Jim Meyering wrote:
 With some effort, and help from the guys on #anaconda@freenode (thanks!),
 today I finally installed a bare-metal F15 system (part of the complication
 was my existing partitions).

 Then I updated it to rawhide.  However, the whole point of this was to
 be able to compile and test some things, yet I cannot install gcc:

 # yum install gcc
 [...]
 Error: Package: glibc-2.8.90-11.i686 (rawhide)
Requires: glibc-common = 2.8.90-11
Installed: glibc-common-2.13.90-4.x86_64 (@updates-testing/15)
glibc-common = 2.13.90-4
Available: glibc-common-2.8.90-11.x86_64 (rawhide)
glibc-common = 2.8.90-11

  Newer glibc in F15 than in rawhide, so yum won't go backwards for
 glibc-devel ... it tries to go with the .i686 instead (do you not have
 protected_multilib set?), but that doesn't work out either.

As far as I know, I haven't changed anything about protected_multilib,
so I guess I have the default setting.  How do I check that?
I do recall seeing one warning about that.

  distro-sync glibc* on rawhide ... or get glibc-devel from F-15.

Thanks, James.  Using yum distro-sync cpp worked like a charm.
However, yum distro-sync 'glibc*' had trouble:

Setting up Distribution Synchronization Process
Resolving Dependencies
-- Running transaction check
--- Package glibc.x86_64 0:2.8.90-11 will be a downgrade
--- Package glibc.x86_64 0:2.13.90-4 will be erased
Error: Package: 2:mcelog-1.0-0.3.pre3.fc15.x86_64 (@koji-override-0/$releasever)
   Requires: libc.so.6(GLIBC_2.11)(64bit)
   Removing: glibc-2.13.90-4.x86_64 (@updates-testing/15)
   libc.so.6(GLIBC_2.11)(64bit)
   Downgraded By: glibc-2.8.90-11.x86_64 (rawhide)
   Not found
Error: Package: xorg-x11-xinit-1.0.9-20.fc15.x86_64 
(@koji-override-0/$releasever)
   Requires: libc.so.6(GLIBC_2.11)(64bit)
   Removing: glibc-2.13.90-4.x86_64 (@updates-testing/15)
   libc.so.6(GLIBC_2.11)(64bit)
   Downgraded By: glibc-2.8.90-11.x86_64 (rawhide)
   Not found
Error: Package: sudo-1.7.4p5-3.fc15.x86_64 (@koji-override-0/$releasever)
   Requires: libc.so.6(GLIBC_2.11)(64bit)
   Removing: glibc-2.13.90-4.x86_64 (@updates-testing/15)
   libc.so.6(GLIBC_2.11)(64bit)
   Downgraded By: glibc-2.8.90-11.x86_64 (rawhide)
   Not found
Error: Package: gdb-7.2.50.20110218-24.fc15.x86_64 (@updates-testing/15)
...

Next, I did this:
  koji download-build --arch x86_64 glibc-2.13.90-4
to get these:
  glibc-devel-2.13.90-4.x86_64.rpm
  glibc-common-2.13.90-4.x86_64.rpm
  glibc-utils-2.13.90-4.x86_64.rpm
  glibc-headers-2.13.90-4.x86_64.rpm
  nscd-2.13.90-4.x86_64.rpm
  glibc-static-2.13.90-4.x86_64.rpm
  glibc-2.13.90-4.x86_64.rpm

and installed them with yum install.
No problem, there.

However, install and distro-sync still fail:

$ yum install gcc
Loaded plugins: langpacks, presto, refresh-packagekit
Adding en_US to language list
Setting up Install Process
Resolving Dependencies
-- Running transaction check
--- Package gcc.x86_64 0:4.3.1-6 will be installed
-- Processing Dependency: libgomp = 4.3.1-6 for package: gcc-4.3.1-6.x86_64
-- Running transaction check
--- Package libgomp.i386 0:4.3.1-6 will be installed
-- Processing Dependency: libc.so.6(GLIBC_2.2) for package: 
libgomp-4.3.1-6.i386
-- Processing Dependency: libc.so.6(GLIBC_2.4) for package: 
libgomp-4.3.1-6.i386
-- Processing Dependency: libc.so.6 for package: libgomp-4.3.1-6.i386
-- Processing Dependency: librt.so.1(GLIBC_2.2) for package: 
libgomp-4.3.1-6.i386
-- Processing Dependency: libpthread.so.0(GLIBC_2.1) for package: 
libgomp-4.3.1-6.i386
-- Processing Dependency: libc.so.6(GLIBC_2.1.3) for package: 
libgomp-4.3.1-6.i386
-- Processing Dependency: libpthread.so.0(GLIBC_2.0) for package: 
libgomp-4.3.1-6.i386
-- Processing Dependency: libpthread.so.0(GLIBC_2.3.4) for package: 
libgomp-4.3.1-6.i386
-- Processing Dependency: libc.so.6(GLIBC_2.0) for package: 
libgomp-4.3.1-6.i386
-- Processing Dependency: libpthread.so.0 for package: libgomp-4.3.1-6.i386
-- Processing Dependency: libc.so.6(GLIBC_2.3) for package: 
libgomp-4.3.1-6.i386
-- Processing Dependency: librt.so.1 for package: libgomp-4.3.1-6.i386
-- Processing Dependency: libc.so.6(GLIBC_2.6) for package: 
libgomp-4.3.1-6.i386
-- Running transaction check
--- Package glibc.i686 0:2.8.90-11 will be installed
-- Processing Dependency: glibc-common = 2.8.90-11 for package: 
glibc-2.8.90-11.i686
-- Finished Dependency Resolution
Error: Package: glibc-2.8.90-11.i686 (rawhide)
   Requires: glibc-common = 2.8.90-11
   Installed: glibc-common-2.13.90-4.x86_64 (@updates-testing/15)
   glibc-common = 2.13.90-4
   Available: glibc-common-2.8.90-11.x86_64 (rawhide)
   glibc-common = 2.8.90-11
 You could try using --skip-broken to work around

Re: fail to install gcc on fresh rawhide-from-F15

[Jim Meyering]

Andreas Schwab wrote:
 Jim Meyering j...@meyering.net writes:

 --- Package glibc.x86_64 0:2.8.90-11 will be a downgrade

 Where did you get that ANCIENT package?  It's almost 3 years(!) old.

I have *no* idea.
As I said, I installed F15 (into existing partitions,
but told anaconda to format /, /var and /usr -- perhaps something
went wrong there? -- but even the, the preceding system to use
those partitions was running rawhide, and the box itself is barely
two years old) and then upgraded to rawhide.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

fail to install gcc on fresh rawhide-from-F15

[Jim Meyering]

Hi,

With some effort, and help from the guys on #anaconda@freenode (thanks!),
today I finally installed a bare-metal F15 system (part of the complication
was my existing partitions).

Then I updated it to rawhide.  However, the whole point of this was to
be able to compile and test some things, yet I cannot install gcc:

# yum install gcc
Loaded plugins: langpacks, presto, refresh-packagekit
Adding en_US to language list
Setting up Install Process
Resolving Dependencies
-- Running transaction check
--- Package gcc.x86_64 0:4.3.1-6 will be installed
-- Processing Dependency: cpp = 4.3.1-6 for package: gcc-4.3.1-6.x86_64
-- Processing Dependency: libgomp = 4.3.1-6 for package: gcc-4.3.1-6.x86_64
-- Processing Dependency: glibc-devel = 2.2.90-12 for package: 
gcc-4.3.1-6.x86_64
-- Running transaction check
--- Package gcc.x86_64 0:4.3.1-6 will be installed
-- Processing Dependency: cpp = 4.3.1-6 for package: gcc-4.3.1-6.x86_64
--- Package glibc-devel.x86_64 0:2.8.90-11 will be installed
-- Processing Dependency: glibc = 2.8.90-11 for package: 
glibc-devel-2.8.90-11.x86_64
-- Processing Dependency: glibc-headers = 2.8.90-11 for package: 
glibc-devel-2.8.90-11.x86_64
--- Package libgomp.i386 0:4.3.1-6 will be installed
-- Running transaction check
--- Package gcc.x86_64 0:4.3.1-6 will be installed
-- Processing Dependency: cpp = 4.3.1-6 for package: gcc-4.3.1-6.x86_64
--- Package glibc.i686 0:2.8.90-11 will be installed
-- Processing Dependency: glibc-common = 2.8.90-11 for package: 
glibc-2.8.90-11.i686
--- Package glibc-headers.x86_64 0:2.8.90-11 will be installed
-- Finished Dependency Resolution
Error: Package: glibc-2.8.90-11.i686 (rawhide)
   Requires: glibc-common = 2.8.90-11
   Installed: glibc-common-2.13.90-4.x86_64 (@updates-testing/15)
   glibc-common = 2.13.90-4
   Available: glibc-common-2.8.90-11.x86_64 (rawhide)
   glibc-common = 2.8.90-11
Error: Package: gcc-4.3.1-6.x86_64 (rawhide)
   Requires: cpp = 4.3.1-6
   Installed: cpp-4.6.0-0.7.fc15.x86_64 (@rawhide)
   cpp = 4.6.0-0.7.fc15
   Available: cpp-4.3.1-6.x86_64 (rawhide)
   cpp = 4.3.1-6
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest


Unfortunately, neither of those you could try ... suggestions helps.
Can anyone suggest an easy way out, or should I just wait for a day or two?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Plans for BTRFS in Fedora

[Jim Meyering]

[...btrfs and read-only root,/etc...]

Music to my ears.
Glad you're working on this.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

rawhide woes

[Jim Meyering]

TL;DR if you have a working rawhide system, you may want to refrain
from updating it for a little while.

I have been maintaining a headless rawhide system for more than two years,
updating every 1-4 days.  There have been a few hassles, but nothing
terrible.  Today however, after an update and a yum-complete-transaction
(which killed all connections), it became unbootable.  It could be my
fault for not waiting long enough before power cycling it -- in case the
complete-transaction was still running.  I tried the preceding kernel
with the same result.

I haven't given up, but was motivated to get a working rawhide system:
I'm releasing coreutils-8.10 tomorrow and the only btrfs
that was new enough to pass a failing test was on rawhide, yet
there was one other test that failed even on rawhide, and Josef
Bacik had given me a hint on how to work around it (use filefrag's -s
option).

Thinking it might be easier to install a new system, I first
tried the latest nightly, desktop-x86_64-20110130.16.iso,
but that has its own problem:

  Install to harddrive fails with not a live image
  http://bugzilla.redhat.com/672265

So I installed from an F14 image, updated, then tried to upgrade to
rawhide.  There were lots of package conflicts and my VM was oom-killed,
so I had to rebuild the rpm db (so again could be my fault),
but in the end, with the new kernel, the system fails to boot,
now with this:

[0.021998] NMI watchdog disabled for cpu0: unable to create perf event: -2
[0.035026] NMI watchdog disabled for cpu1: unable to create perf event: -2
[0.047172] NMI watchdog disabled for cpu2: unable to create perf event: -2
[0.059012] NMI watchdog disabled for cpu3: unable to create perf event: -2
[0.737139] Kernel panic - not syncing: UFS: Unable to mount root fs on unXno
wn-block(0,0)
[0.737820] Pid: 1, comm: swapper Not tainted 2.6.38-0.rc3.git0.1.fc15.x86_64
#1
[0.738435] CaII Trace:
[0.738714]  [814673e7_] T panic+0x91/0x19c
[0.739252]  [81b58211_] T mount_block_root+0x250/0x27b
[0.739809]  [81b583c2_] T mount_root+0x53/0x57
[0.740284]  [81b58533_] T prepare_namespace+0x16d/0x1a6
[0.740808]  [81074387_] T put_cred_rcu+0x0/0x8f
[0.741283]  [81b57efd_] T kernel_init+0x29d/0x2a2
[0.741651]  [8100a9e4_] T kernel_thread_heIper+0x4/0x10
[0.741883]  [81b57c60_] T kernel_init+0x0/0x2a2
[0.742109]  [8100a9e0_] T kernel_thread_heIper+0x0/0x10

Next time I'll save a copy of the updated F14 system before
jumping into rawhide.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

use MALLOC_PERTURB_ ... or lose

[Jim Meyering]

If you are into development on glibc-based systems
and do not set MALLOC_PERTURB_ to a nonzero value, then you
are missing an easy opportunity to detect subtle bugs early.

Sure, you can use valgrind, and it will detect whatever a
MALLOC_PERTURB_ setting would have caught, and more, but it's
far more expensive and takes some effort, however minimal.

If you use zsh or bash, put this in one of your startup files:

# http://udrepper.livejournal.com/11429.html
export MALLOC_PERTURB_=$(($RANDOM % 255 + 1))

and remember that when you find surprising bugs, that others
who are also running tests (but without MALLOC_PERTURB_)
will not see the same failures.

This is useful enough that it is worth considering for inclusion
in /etc/profile.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: use MALLOC_PERTURB_ ... or lose

[Jim Meyering]

H. Guémar wrote:
 This is useful enough that it is worth considering for inclusion
 in /etc/profile.

 during development cycle: +1
 for stable/production release: not so much (users would hate us for that)

It's definitely not suitable for everyone.
My suggestion was intended to be provocative ;-)

Eric Sandeen had a nice idea: enable it for rawhide,
say by testing for Rawhide in /etc/redhat-release.

I propose (seriously, now) to add this to /etc/profile,
or to some always-sourced file like /etc/profile.d/glibc.sh:

# Enable glibc's malloc perturbing feature in Rawhide.
# http://udrepper.livejournal.com/11429.html
read _f _r _n _code_name  /etc/redhat-release 
case $_code_name in
*Rawhide*) export MALLOC_PERTURB_=$((RANDOM % 255 + 1)) ;;
esac

Alternatively, if we should handle the case of a missing
/etc/redhat-release, and want to avoid generating a diagnostic about it:

if test -r /etc/redhat-release; then
# Enable glibc's malloc perturbing feature in Rawhide.
# http://udrepper.livejournal.com/11429.html
read _f _r _n _code_name  /etc/redhat-release 
case $_code_name in
*Rawhide*) export MALLOC_PERTURB_=$((RANDOM % 255 + 1)) ;;
esac
fi
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: use MALLOC_PERTURB_ ... or lose

[Jim Meyering]

Michal Schmidt wrote:
 On Wed, 05 May 2010 17:30:29 +0200 Jim Meyering wrote:
 I propose (seriously, now) to add this to /etc/profile,
 or to some always-sourced file like /etc/profile.d/glibc.sh:

 # Enable glibc's malloc perturbing feature in Rawhide.
 # http://udrepper.livejournal.com/11429.html
 read _f _r _n _code_name  /etc/redhat-release 
 case $_code_name in
 *Rawhide*) export MALLOC_PERTURB_=$((RANDOM % 255 + 1)) ;;
 esac

 Would export MALLOC_CHECK_=3 be a useful addition too?

Does that impose much of a performance impact?
I haven't used it or measured it enough to know off hand.

Even using MALLOC_PERTURB_=... imposes *some* cost, both in
space and in time.  I confess that I haven't measured it, either.
Rawhide already has (had?) a reputation for being slightly slower due to
added instrumentation e.g., in the kernel, so there is precedent.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F13/i686: yum update emptied /boot, /bin, /lib, etc.

[Jim Meyering]

James Antill wrote:
 On Fri, 2010-04-23 at 15:52 -0400, Seth Vidal wrote:

 On Fri, 23 Apr 2010, Jim Meyering wrote:

  I've just realized that I had a list of all packages/versions
  that were installed as of a few weeks ago (April 5).
  In case it helps:
 

 Yah - the history sqlite file you uploaded has all that info in there (in
 a round about way) but the problem still is we don't know what
 precipitated all the erasures.

 b/c those erasures  are JUST erasures, they aren't the cleanup step of an
 update.

 which points me at weird plugin behavior.

  Jim, is it possible you were running with LANG=C?

Root's LANG setting was the relatively common default,
but it's overridden by my LC_ALL=C setting:

  $ locale   :
  LANG=en_US.UTF-8
  LC_CTYPE=C
  LC_NUMERIC=C
  LC_TIME=C
  LC_COLLATE=C
  LC_MONETARY=C
  LC_MESSAGES=C
  LC_PAPER=C
  LC_NAME=C
  LC_ADDRESS=C
  LC_TELEPHONE=C
  LC_MEASUREMENT=C
  LC_IDENTIFICATION=C
  LC_ALL=C

  If so I'm 99% sure I've found the bug:

 https://bugzilla.redhat.com/show_bug.cgi?id=585424
 Langpacks goes on crack in LANG=C, for removals _and_ updated,
 removing everything

Nice.  Glad you found the cause/fix.
Thanks!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F13/i686: yum update emptied /boot, /bin, /lib, etc.

[Jim Meyering]

Frank Murphy wrote:
 On 22/04/10 22:01, Jim Meyering wrote:
 There was only one: history-2010-03-08.sqlite
 BZ-attached here:

 http://bugzilla.redhat.com/584997

 Read up on:
 yum-plugin-protect-packages

 if your going on autopilot.

Thanks.  Installed.
IMHO, one should always be able to run yum -y update without fear
of such damage.  Maybe that's naive, but with the exception of
yesterday's run, it's worked for me for more than two years of
rawhide and F10..F13.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F13/i686: yum update emptied /boot, /bin, /lib, etc.

[Jim Meyering]

Seth Vidal wrote:
 On Fri, 23 Apr 2010, Jim Meyering wrote:
 Frank Murphy wrote:
 On 22/04/10 22:01, Jim Meyering wrote:
 There was only one: history-2010-03-08.sqlite
 BZ-attached here:

 http://bugzilla.redhat.com/584997

 Read up on:
 yum-plugin-protect-packages

 if your going on autopilot.

 Thanks.  Installed.
 IMHO, one should always be able to run yum -y update without fear
 of such damage.  Maybe that's naive, but with the exception of
 yesterday's run, it's worked for me for more than two years of
 rawhide and F10..F13.

 except we don't know what happened yesterday.

 You didn't happen to keep the depsolving output on the console did you?

I wish I'd been that prescient.

As mentioned, when I came back after the offending
command had finished, all I could see in all terminal consoles
were little rectangles in place of text.  So while I could
have saved it to file via screen (as long it was still within
the 30k scrollback), I didn't think to do that.

 Also - were there any plugins installed?

I think yum-fastestmirror was installed.
Other than that, no.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F13/i686: yum update emptied /boot, /bin, /lib, etc.

[Jim Meyering]

Seth Vidal wrote:
 On Fri, 23 Apr 2010, Jim Meyering wrote:
 Seth Vidal wrote:
 On Fri, 23 Apr 2010, Jim Meyering wrote:
 Frank Murphy wrote:
 On 22/04/10 22:01, Jim Meyering wrote:
 There was only one: history-2010-03-08.sqlite
 BZ-attached here:

 http://bugzilla.redhat.com/584997

 Read up on:
 yum-plugin-protect-packages

 if your going on autopilot.

 Thanks.  Installed.
 IMHO, one should always be able to run yum -y update without fear
 of such damage.  Maybe that's naive, but with the exception of
 yesterday's run, it's worked for me for more than two years of
 rawhide and F10..F13.

 except we don't know what happened yesterday.

 You didn't happen to keep the depsolving output on the console did you?

 I wish I'd been that prescient.

 As mentioned, when I came back after the offending
 command had finished, all I could see in all terminal consoles
 were little rectangles in place of text.  So while I could
 have saved it to file via screen (as long it was still within
 the 30k scrollback), I didn't think to do that.

 Also - were there any plugins installed?

 I think yum-fastestmirror was installed.
 Other than that, no.

 langpacks was installed, too.
 But given the history db and w/o any other output - I think we're going to
 be hardpressed to figure out what happened.

I've just realized that I had a list of all packages/versions
that were installed as of a few weeks ago (April 5).
In case it helps:

ConsoleKit-0.4.1-5.fc13.i686
ConsoleKit-libs-0.4.1-5.fc13.i686
ConsoleKit-x11-0.4.1-5.fc13.i686
DeviceKit-power-0.9.0-1.fc13.i686
GConf2-2.28.1-1.fc13.i686
GConf2-gtk-2.28.1-1.fc13.i686
GitPython-0.1.6-2.fc13.noarch
ImageMagick-6.5.8.10-6.fc13.i686
ImageMagick-c++-6.5.8.10-6.fc13.i686
ImageMagick-perl-6.5.8.10-6.fc13.i686
MAKEDEV-3.24-4.i686
MagicPoint-1.11b-10.fc12.i686
ModemManager-0.3-6.git20100331.fc13.i686
NetworkManager-0.8.0-4.git20100325.fc13.i686
NetworkManager-glib-0.8.0-4.git20100325.fc13.i686
NetworkManager-gnome-0.8.0-4.git20100325.fc13.i686
NetworkManager-openconnect-0.7.997-1.fc13.i686
NetworkManager-openvpn-0.7.997-1.fc13.i686
NetworkManager-pptp-0.7.997-3.git20100120.fc13.i686
NetworkManager-vpnc-0.7.997-1.fc13.i686
ORBit2-2.14.18-1.fc13.i686
PackageKit-0.6.3-1.fc13.i686
PackageKit-command-not-found-0.6.3-1.fc13.i686
PackageKit-device-rebind-0.6.3-1.fc13.i686
PackageKit-glib-0.6.3-1.fc13.i686
PackageKit-gstreamer-plugin-0.6.3-1.fc13.i686
PackageKit-gtk-module-0.6.3-1.fc13.i686
PackageKit-yum-0.6.3-1.fc13.i686
PackageKit-yum-plugin-0.6.3-1.fc13.i686
SDL-1.2.14-4.fc13.i686
WINGs-libs-0.92.0-20.fc12.i686
WindowMaker-0.92.0-20.fc12.i686
Xaw3d-1.5E-15.fc12.i686
Xaw3d-devel-1.5E-15.fc12.i686
a2ps-4.14-10.fc12.i686
abrt-1.0.8-3.fc13.i686
abrt-addon-ccpp-1.0.8-3.fc13.i686
abrt-addon-kerneloops-1.0.8-3.fc13.i686
abrt-addon-python-1.0.8-3.fc13.i686
abrt-desktop-1.0.8-3.fc13.i686
abrt-gui-1.0.8-3.fc13.i686
abrt-libs-1.0.8-3.fc13.i686
abrt-plugin-bugzilla-1.0.8-3.fc13.i686
abrt-plugin-logger-1.0.8-3.fc13.i686
abrt-plugin-runapp-1.0.8-3.fc13.i686
acl-2.2.49-5.fc13.i686
agrep-0.8.0-1.fc13.i686
alsa-lib-1.0.22-1.fc13.i686
alsa-plugins-pulseaudio-1.0.22-1.fc13.i686
alsa-utils-1.0.22-1.fc13.i686
altermime-0.3.10-3.fc12.i686
amavisd-new-2.6.4-1.fc12.noarch
anaconda-13.37.2-1.fc13.i686
anaconda-yum-plugins-1.0-5.fc12.noarch
anthy-9100h-10.fc13.i686
apr-1.3.9-3.fc13.i686
apr-util-1.3.9-3.fc13.i686
apr-util-ldap-1.3.9-3.fc13.i686
ar9170-firmware-2009.05.28-2.fc13.noarch
arj-3.10.22-11.fc12.i686
arpwatch-2.1a15-13.fc13.i686
asciidoc-8.4.5-4.fc12.noarch
aspell-0.60.6-11.fc13.i686
at-3.1.12-4.fc13.i686
at-spi-1.30.0-1.fc13.i686
at-spi-python-1.30.0-1.fc13.i686
aterm-1.0.1-6.fc12.i686
atk-1.30.0-1.fc13.i686
atk-devel-1.30.0-1.fc13.i686
atlas-3.8.3-15.fc13.i686
atmel-firmware-1.3-7.fc13.noarch
attr-2.4.44-3.fc13.i686
audit-2.0.4-3.fc13.i686
audit-libs-2.0.4-3.fc13.i686
audit-libs-python-2.0.4-3.fc13.i686
augeas-devel-0.7.0-1.fc13.i686
augeas-libs-0.7.0-1.fc13.i686
authconfig-6.1.2-1.fc13.i686
authconfig-gtk-6.1.2-1.fc13.i686
autoconf-2.65-1.fc13.noarch
autocorr-en-3.2.0-12.14.fc13.noarch
autogen-5.9.4-7.fc12.i686
autogen-libopts-5.9.4-7.fc12.i686
automake-1.11.1-1.fc13.noarch
avahi-0.6.25-6.fc13.i686
avahi-autoipd-0.6.25-6.fc13.i686
avahi-devel-0.6.25-6.fc13.i686
avahi-glib-0.6.25-6.fc13.i686
avahi-gobject-0.6.25-6.fc13.i686
avahi-ui-0.6.25-6.fc13.i686
b43-fwcutter-012-2.fc12.i686
b43-openfwwf-5.2-3.fc13.noarch
basesystem-10.0-3.noarch
bash-4.1.2-4.fc13.i686
bc-1.06.95-1.fc12.i686
bea-stax-1.2.0-0.5.rc1.fc12.i686
bea-stax-api-1.2.0-0.5.rc1.fc12.i686
bind-libs-9.7.0-9.P1.fc13.i686
bind-utils-9.7.0-9.P1.fc13.i686
binutils-2.20.51.0.2-15.fc13.i686
bison-2.4.1-4.fc12.i686
bluez-4.63-1.fc13.i686
bluez-cups-4.63-1.fc13.i686
bluez-libs-4.63-1.fc13.i686
bodhi-client-0.7.4-1.fc13.noarch
boost-filesystem-1.41.0-7.fc13.i686
boost-regex-1.41.0-7.fc13.i686
boost-system-1.41.0-7.fc13.i686
brasero-2.30.0-1.fc13.i686
brasero-libs-2.30.0-1.fc13.i686
brasero-nautilus-2.30.0-1.fc13.i686
bridge-utils-1.2-9.fc13.i686
bzip2

Re: F13/i686: yum update emptied /boot, /bin, /lib, etc.

[Jim Meyering]

Seth Vidal wrote:

 On Thu, 22 Apr 2010, Jim Meyering wrote:

 I hope it's just me...
 but I was very dismayed to find that today's F13 update (which pulled
 in a lot of changes) hosed my laptop.  It removed almost everything
 from /boot, and removed or emptied /sbin, /bin, /usr/sbin and /usr/bin.
 It removed nearly everything from /lib and /usr/lib.
 I suspect that it removed everything yum-owned, since the few remaining
 files (at least the shift-jis ones) are ones I put there manually:

 What happened?
 I started the yum -y update, and didn't hang around to watch everything.
 When I came back, the text displayed in all terminals was in a completely
 illegible all-rectangles font, but emacs was ok (I'd installed it myself).
 However, I couldn't start a shell from emacs (no surprise, now that I
 know /bin was removed).  Maybe yum actually told me it was going to
 remove everything and if I'd been watching I could have stopped it.
 I don't know.

 pleae look in /var/lib/yum/history/

 and attach any/all files you find there to a bug report.

 but just going by the log you attached it looks like an update followed by
 cleanup erasures - but the history log will tell us a lot more.

There was only one: history-2010-03-08.sqlite
BZ-attached here:

http://bugzilla.redhat.com/584997
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F-13 Branched report: 20100402 changes

[Jim Meyering]

Branched Report wrote:
...
 Removed package 4ti2
 Removed package bakefile
 Removed package cppi
...

Why has cppi been removed?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F-13 Branched report: 20100402 changes

[Jim Meyering]

Bruno Wolff III wrote:
...
  Removed package cppi
 ...

 Why has cppi been removed?

 Probably the f12 version was being inherited into f13 stable. Currently
 there is an f13 version in f13 testing. The maintainer can push this
 to f13 stable if they want it in the release.

Oh, ok.
Thanks.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: How to become someone's sponsor when they are already sponsored

[Jim Meyering]

Richard W.M. Jones wrote:
 Jim Meyering (FAS username: meyering) was sponsored by Warren Togami.
 It seems that Jim can no longer set the fedora-review flag on packages
 that he's reviewed, and this may be connected with Warren leaving Red
 Hat for new pastures yesterday.  In any case I've agreed with Jim that
 I'll become his sponsor.

 *However* there is a problem ...  I can see no way to change the
 sponsor of an existing packager in FAS.

 How do we go about this?

Thanks Rich,

Background details: this arose because I have reviewed and just
tried to set fedora-review = + on this RR:

http://bugzilla.redhat.com/570627

and now all I get is the big red failure notice:

You tried to grant fedora-review. Only a user with the required
permissions may make this change.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: How to become someone's sponsor when they are already sponsored

[Jim Meyering]

Dan Horák wrote:
 Richard W.M. Jones píše v Čt 18. 03. 2010 v 12:01 +:
 Jim Meyering (FAS username: meyering) was sponsored by Warren Togami.
 It seems that Jim can no longer set the fedora-review flag on packages
 that he's reviewed, and this may be connected with Warren leaving Red
 Hat for new pastures yesterday.  In any case I've agreed with Jim that
 I'll become his sponsor.

 Those 2 events shouldn't be connected. The inability to set flags in
 bugzilla is usually caused by using an email as login in bugzilla that's
 not registered in FAS.

Hi Dan,

Thanks for the quick reply.
I've just changed my email in FAS to match the one in bugzilla,
confirmed it, then tried to set the flag again.  Same failure.

Jim
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: How to become someone's sponsor when they are already sponsored

[Jim Meyering]

Jim Meyering wrote:
 Richard W.M. Jones wrote:
 Jim Meyering (FAS username: meyering) was sponsored by Warren Togami.
 It seems that Jim can no longer set the fedora-review flag on packages
 that he's reviewed, and this may be connected with Warren leaving Red
 Hat for new pastures yesterday.  In any case I've agreed with Jim that
 I'll become his sponsor.

 *However* there is a problem ...  I can see no way to change the
 sponsor of an existing packager in FAS.

 How do we go about this?

 Thanks Rich,

 Background details: this arose because I have reviewed and just
 tried to set fedora-review = + on this RR:

 http://bugzilla.redhat.com/570627

 and now all I get is the big red failure notice:

 You tried to grant fedora-review. Only a user with the required
 permissions may make this change.

FYI, I set it to fedora-review = ?
last week with no trouble.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: How to become someone's sponsor when they are already sponsored

[Jim Meyering]

Mamoru Tasaka wrote:
...
 My recognition is that if you change your email in FAS it may take
 about an hour or so for RH bugzilla database to recognize it.

Thank you.
I will be patient ;-)
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: How to become someone's sponsor when they are already sponsored

[Jim Meyering]

Dan Horák wrote:
 Jim Meyering píše v Čt 18. 03. 2010 v 13:24 +0100:
 Dan Horák wrote:
  Richard W.M. Jones píše v Čt 18. 03. 2010 v 12:01 +:
  Jim Meyering (FAS username: meyering) was sponsored by Warren Togami.
  It seems that Jim can no longer set the fedora-review flag on packages
  that he's reviewed, and this may be connected with Warren leaving Red
  Hat for new pastures yesterday.  In any case I've agreed with Jim that
  I'll become his sponsor.
 
  Those 2 events shouldn't be connected. The inability to set flags in
  bugzilla is usually caused by using an email as login in bugzilla that's
  not registered in FAS.

 Hi Dan,

 Thanks for the quick reply.
 I've just changed my email in FAS to match the one in bugzilla,
 confirmed it, then tried to set the flag again.  Same failure.

 It takes some time to get the change propagated into right places.
 Please try it later, it should work after say 20 minutes.

Confirmed.
Waiting solved the problem.
I didn't time it carefully, but it felt like
more than 30 minutes, and perhaps an hour.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

caution: avoid unpatched automake [CVE-2009-4029]

[Jim Meyering]

There was a nasty flaw in _every_ automake-generated Makefile.in
until recently[*].  When making releases, most of us who maintain
automake-using packages run make dist or make distcheck.
Even if you don't, your users may.  The flaw put all of us at risk.

With a Makefile.in file generated by unpatched automake,
if you run make dist in a potentially hostile environment,
you risk including arbitrary code in a tarball that you may
then sign, thinking it's a faithful copy of your working sources.
Worse, if you run make distcheck you risk immediate arbitrary
code execution.

Even if you are confident you never run those commands
in a vulnerable environment, you have to consider that
someone who downloads your release tarball may run them.

I mention this because some recently released packages
included Makefile.in files generated by unpatched automake.
To check, simply run this against the any compressed tarball, $tgz:
[this command assumes you have GNU Tar 1.22 or newer, so that it
 will work with .xz-compressed files, too]

tar --to-stdout -x -f $tgz '*/Makefile.in' | grep -e '-perm -777 '

If there's a match, you should get a fixed version of automake
and use it to regenerate that file.  If that's too much trouble,
at least correct the Makefile.in file(s), e.g., by running something
like this:

perl -pe 's/perm -777 -exec chmod a\+rwx/perm -755 -exec chmod  755 /'

You can even apply that to an uncompressed tarball, since it is
careful not to change the length of the file.  In any case, there
is a small risk of a false-positive match, so check your work.

A check like the above has been protecting the upload-to-ftp.gnu.org
process for a few weeks now, and has already blocked numerous tainted
uploads.

Jim

[*] Here's the announcement of the make dist CVE fix

http://thread.gmane.org/gmane.comp.sysutils.autotools.announce/131
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: caution: avoid unpatched automake [CVE-2009-4029]

[Jim Meyering]

Jim Meyering wrote:
 There was a nasty flaw in _every_ automake-generated Makefile.in
 until recently[*].  When making releases, most of us who maintain

To clarify, the vulnerability affects the distdir commands
that appear only in so-called top-level Makefile.in files.
Note however, that some packages include sub-packages, so it's not
enough to search the Makefile.in file in the top-level directory.

 automake-using packages run make dist or make distcheck.
 Even if you don't, your users may.  The flaw put all of us at risk.
...

That's why this command searches all Makefile.in files:

 tar --to-stdout -x -f $tgz '*/Makefile.in' | grep -e '-perm -777 '
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: caution: avoid unpatched automake [CVE-2009-4029]

[Jim Meyering]

Jon Masters wrote:
 On Wed, 2010-02-10 at 10:58 +0100, Jim Meyering wrote:
 There was a nasty flaw in _every_ automake-generated Makefile.in
 until recently[*].  When making releases, most of us who maintain
 automake-using packages run make dist or make distcheck.
 Even if you don't, your users may.  The flaw put all of us at risk.

 I disagree that it's as critical as you make out - sure it needs fixing.
 To exploit this, you have to build within a directory path that is going
 to be writeable (i.e. have a world readable home directory and build in
 there directly), and be using a shared system on which you don't trust
 your users. In the latter case, it's often game over anyway.

Hi Jon,

This is definitely not a critical vulnerability.
The CVE now has a cvss2 rating of only 3.7.

However, that you mention build within...writable (ambiguous)
and that you say world readable, not world searchable
suggest that I should clarify.

Anyone running make distcheck with a bad Makefile.in from
a world-_searchable_ build directory is vulnerable.  The build
directory certainly does not have be world-writable.  It need not even
be world-readable.  Just searchable.  The flaw is still exploitable if
an attacker can guess, say, via ps, the name of your build directory.
This is a good argument for running chmod 700 $HOME/ and doing the
same on any other directory beneath which you build things.

Before this excursion, my umask was 022.  Now it's 077.

As for shared systems, while I'm fairly security conscious and maybe
even a little paranoid, I feel I have to treat my desktop system very
carefully.  While it is a well-secured single-user system, if somehow it
does become a shared system, I won't fall to this particular exploit.
Note that on truly shared systems, while I may trust colleagues not to
take advantage of this sort of thing directly, my trust does not extend
to malicious users they may inadvertently invite.

In addition, there's habit to deal with.
Sometimes (portability testing) I would do things like this:

  cd /dev/shm  mkdir foo  cd foo  wget ...
 tar xf FILE  ./configure  ...

Running make dist or make distcheck in the above would make me
vulnerable with a umask of 022.  Of course, now my umask is more
restrictive, so that's ok.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: disk woes: revive w/o-reboot after SATA START_STOP FAILED?

[Jim Meyering]

Jim Meyering wrote:
 Hello,

 I've just returned one relatively new disk drive[*],
 and hope I'm not about to return another...

 [*] It was a 1TB Samsung ecogreen, and some strenuous testing
  would reliably provoke I/O errors which would apparently
  damage the disk enough to force an increase in the SMART
  Reallocated_Sector_Ct metric.  My final test added about 600
  to that count.  Of all my other disks, some over 5 years old,
  only 1 had a single Reallocated_Sector_Ct.  The rest were 0.

 Anyhow, this time it's my newest drive, a 1.5TB Samsung.
 Most of the time it is spun down, but spins up and works fine
 when I need it, which is once a day or so, for backups.
 But today, there was no trace of it at all.
 /dev/sdb had disappeared altogether.  Ominous.
 This is up-to-date F12 w/stock untainted 2.6.31.9-174.fc12.x86_64
 on an Intel Q9450.

 dmesg has clues:

 ...
 usb 1-5.2: new low speed USB device using ehci_hcd and address 40
 usb 1-5.2: New USB device found, idVendor=046d, idProduct=c03e
 usb 1-5.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
 usb 1-5.2: Product: USB-PS/2 Optical Mouse
 usb 1-5.2: Manufacturer: Logitech
 usb 1-5.2: configuration #1 chosen from 1 choice
 input: Logitech USB-PS/2 Optical Mouse as 
 /devices/pci:00/:00:1a.7/usb1/1-5/1-5.2/1-5.2:1.0/input/input29
 generic-usb 0003:046D:C03E.001A: input,hidraw1: USB HID v1.10 Mouse 
 [Logitech USB-PS/2 Optical Mouse] on usb-:00:1a.7-5.2/input0

 [maybe related?
  The above are common events provoked by my turning off/on the
  monitor+hub that my kbd and mouse are usually plugged into. ]

 Here's the bad part:

 ata3.00: exception Emask 0x10 SAct 0x0 SErr 0x400 action 0xe frozen
 ata3.00: irq_stat 0x0040, connection status changed
 ata3: SError: { DevExch }
 ata3.00: cmd ec/00:01:00:00:00/00:00:00:00:00/00 tag 0 pio 512 in
  res 50/00:00:00:00:00/00:00:00:00:00/00 Emask 0x10 (ATA bus 
 error)
 ata3.00: status: { DRDY }
 ata3: hard resetting link
 ata3: SATA link down (SStatus 0 SControl 300)
 ata3: hard resetting link
 ata3: SATA link down (SStatus 0 SControl 300)
 ata3: limiting SATA link speed to 1.5 Gbps
 ata3: hard resetting link
 ata3: SATA link down (SStatus 0 SControl 310)
 ata3.00: disabled
 ata3: EH complete
 ata3.00: detaching (SCSI 2:0:0:0)
 sd 2:0:0:0: [sdb] Synchronizing SCSI cache
 sd 2:0:0:0: [sdb] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
 sd 2:0:0:0: [sdb] Stopping disk
 sd 2:0:0:0: [sdb] START_STOP FAILED
 sd 2:0:0:0: [sdb] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK

FYI, halted, reseated SATA connectors, rebooted, and it's back,
seemingly as good as new.  SMART reports no problem.
Fingers crossed.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel