Re: Stuck maxima builds on aarch64

2017-03-24 Thread Jeffrey Bastian 
On Tue, Mar 21, 2017 at 11:35:55AM -0500, Jeremy Linton wrote:
> Hi,
> 
> On 03/21/2017 07:33 AM, Jerry James wrote:
> > On Tue, Feb 28, 2017 at 2:05 PM, Jerry James  wrote:
> > > I'm really not sure what to check next.  If an aarch64 box for
> > > packagers will be available in the not too distant future, I will try
> > > to debug this.  Thanks for the information, Kevin.
> > 
> > This issue is now blocking a large update of sagemath and many of its
> > dependencies.  Sagemath invokes maxima during its build.  That
> > currently fails because the maxima in both F26 and Rawhide was built
> > with the pre-mass-rebuild version of ecl.  If this issue is not
> > resolved, we will ship a nonfunctional sagemath with F26.
> > 
> > I either need access to an aarch64 box so I can try to figure out the
> > problem, or I need somebody with access to the aarch64 koji builders
> > to figure it out.  I would file a bug, except I don't know which
> > component to file it against.  Probably rpm, but I don't know that for
> > sure.
> 
> I started a local build of this and it appears to be hanging like this:
> 
> make  check-TESTS
> make[2]: Entering directory '/root/maxima/maxima-5.39.0/tests'
> make[3]: Entering directory '/root/maxima/maxima-5.39.0/tests'
> sed <"test.sh.in" >"gcl-test.sh"  \
>   -e 's#!LOCAL_MAXIMA!#/bin/sh ../maxima-local#'   \
>   -e 's#!LISPNAME!#gcl#' \
>   -e 's#!OUTPUT_LOG!#../tests/gcl.log#'
> chmod a+x "gcl-test.sh"
> FAIL: gcl-test.sh
> sed <"test.sh.in" >"ecl-test.sh"  \
>   -e 's#!LOCAL_MAXIMA!#/bin/sh ../maxima-local#'   \
>   -e 's#!LISPNAME!#ecl#' \
>   -e 's#!OUTPUT_LOG!#../tests/ecl.log#'
> chmod a+x "ecl-test.sh"

I got to this point with a plain rpmbuild (i.e., without mock) and
noticed an SELinux AVC:

time->Thu Mar 23 17:06:04 2017 type=AVC msg=audit(1490303164.568:291): avc:  
denied  { execheap } for pid=25435 comm="maxima" 
scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 
tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process 
permissive=0

Rebuilding the src rpm with SELinux in permissive mode (setenforce 0)
fixes this problem and allows rpmbuild to finish.

~]$ rpmbuild --rebuild maxima-5.39.0-4.fc26.src.rpm
...
Wrote: /home/rpmbuild/rpmbuild/RPMS/aarch64/maxima-5.39.0-4.fc25.aarch64.rpm
Wrote: /home/rpmbuild/rpmbuild/RPMS/aarch64/maxima-gui-5.39.0-4.fc25.aarch64.rpm
Wrote: /home/rpmbuild/rpmbuild/RPMS/aarch64/maxima-src-5.39.0-4.fc25.aarch64.rpm
Wrote: 
/home/rpmbuild/rpmbuild/RPMS/aarch64/maxima-runtime-gcl-5.39.0-4.fc25.aarch64.rpm
Wrote: 
/home/rpmbuild/rpmbuild/RPMS/aarch64/maxima-runtime-ecl-5.39.0-4.fc25.aarch64.rpm
...
+ exit 0

Note: it took a *long* time running the self-tests, but it did finish
eventually.  (Maybe it was never hanging in the first place and we were
just impatient?  It's possible the AVC is a red-herring.)


In any case, changing SELinux to permissive does not fix the original
problem where mock hangs setting up the buildroot environment...

-- 
Jeff Bastian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: How risky is lm_sensors's sensors-detect nowadays?

2017-03-24 Thread Jeffrey Bastian 
On Fri, Mar 24, 2017 at 03:43:09AM -, Andrew Toskin wrote:
> I've used both Freon and lm_sensors without blowing up my computer,
> and it since `sensors-detect` is mandatory for Freon to work, it seems
> like it should be included in a %post scriptlet. But I don't want to
> damage unsuspecting users' hardware... 

I've never suffered any damage from sensors-detect (/me crosses
fingers), but I have seen it cause kernel panics even on recent hardware
(particularly when probing the ISA bus on a 64-bit ARM system which does
not have an ISA bus), so running sensors-detect from an rpm %post
scriptlet is probably a bad idea.  If it does cause a kernel panic, it's
going to cause a user panic, and it'll probably corrupt the rpm/yum/dnf
databases since it crashed in the middle of a transaction.

Can Freon check if sensors-detect has been run before, and if not, pop
up a dialog box asking to run it and warn about the risks?

-- 
Jeff Bastian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Stuck maxima builds on aarch64

2017-03-23 Thread Jeffrey Bastian 
On Wed, Mar 22, 2017 at 01:10:22PM -0600, Kevin Fenzi wrote:
> So, if someone could try on a fedora 25 host to setup a rawhide/f26 mock
> chroot and try and build maxima in it, and see if it hangs installing
> the buildsys packages (in particular the 'time' package) that would be
> great.


I tried this: I installed Fedora 25 + updates (kernel
4.9.14-200.fc25.aarch64) on an AMD Seattle system, then used fedpkg to
build a src rpm for maxima, and finally tried to build it with mock.
But, mock is failing on rpm gpg keys:


$ mock -r fedora-26-aarch64 --resultdir=/home/rpmbuild/mock \
   fedpkg/maxima/maxima-5.39.0-4.fc26.src.rpm
...
warning: 
/var/lib/mock/fedora-26-aarch64/root/var/cache/dnf/fedora-f88a95d51c1e4379/packages/info-6.3-2.fc26.aarch64.rpm:
 Header V3 RSA/SHA256 Signature, key ID 64dab85d: NOKEY
Importing GPG key 0x3B921D09:
 Userid : "Fedora 26 Secondary (26) "
 Fingerprint: 19AA 0442 2491 9109 8B3D 8035 4560 FD4D 3B92 1D09
 From   : 
/usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-26-secondary
Key imported successfully
Import of key(s) didn't help, wrong key(s)?
Error: 


Public key for info-6.3-2.fc26.aarch64.rpm is not installedFailing package is: 
info-6.3-2.fc26.aarch64
 GPG Keys are configured as: 
file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-26-secondary


If I try it again, it fails the same way with public keys, but for a
different package each time (info, bash, tar, etc.)

'mock -r fedora-26-aarch64 --init' fails the same way.

So I switched from F26 to rawhide
  mock -r fedora-rawhide-aarch64 ...

And now I can reproduce the hang right after it installs the last of the
build requirements.  strace on the dnf child process of mock shows it's
just waiting on a futex() call:
  ~]# strace -f -p 11494
  strace: Process 11494 attached
  futex(0x8c0836c0, FUTEX_WAIT, 2, NULL

It seems mock has issues with both F26 and rawhide!


Finally, I noticed that my system has mock-1.3.4 installed, but Koji
builders are running mock-1.3.3.  Can the Koji builders get the newer
mock installed?  Maybe that would help?

-- 
Jeff Bastian


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: hawaii

2016-01-22 Thread Jeffrey Bastian 
On Fri, Jan 22, 2016 at 11:08:31AM -0800, Adam Williamson wrote:
> On Fri, 2016-01-22 at 18:32 +,  mastaiza wrote:
> > Hi
> > wanted to know why doesn't work command install @hawaii
> 
> it's a magical place...

I thought that was Tahiti...
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Flash plugin 0-day vulnerability in the wild

2015-01-23 Thread Jeffrey Bastian 
On Fri, Jan 23, 2015 at 04:59:31PM +0100, drago01 wrote:
 On Fri, Jan 23, 2015 at 4:29 PM, Daniel J Walsh dwa...@redhat.com wrote:
  libflashplayer.so runs within the Mozilla-plugin I believe. If so it
  would be confined
  if you have not turned on the unconfined_mozilla_plugin_transition boolean.
 
 
 # getsebool unconfined_mozilla_plugin_transition
 unconfined_mozilla_plugin_transition -- on
 
 I can't recall ever turning that on ... what is it set to by default?


It is on by default according to the mozilla_plugin_selinux(8) man page:

   If  you  want  to  allow  unconfined users to transition to the
   Mozilla plugin domain when running xulrunner  plugin-container,
   you must turn on the unconfined_mozilla_plugin_transition bool‐
   ean. Enabled by default.

   setsebool -P unconfined_mozilla_plugin_transition 1



Jeff
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Can we have better ssh fingerprint collision messages?

2013-11-13 Thread Jeffrey Bastian 
On Wed, Nov 13, 2013 at 01:29:34PM -0500, Przemek Klosowski wrote:
 On 11/12/2013 07:47 AM, Miroslav Suchý wrote:
2) if you know that some machines change fingerprint and you *trust it* 
  you
can do:
 
~/.ssh/config:
Host 192.168.1.1
UserKnownHostsFile /dev/null
 
 
 It always bugged me that the choice was to either disable or manually edit an
 obscure file, so I was happy to find that you can delete stale entries from
 commandline:
 
 ssh-keygen -R hostname


I work on some lab systems that get kickstarted frequently and thus
change ssh keys quite often, so I wrote the script below to update my
known_hosts file with the new key.

Note that I use the format hostname,ip-address so that I don't get two
entries in my known_hosts file (which causes its own set of problems if the
system gets a new IP address due to DHCP changes).

~~~
#!/bin/sh

KNOWN_HOSTS=~/.ssh/known_hosts
NEW_HOST=$1
IP_ADDR=$(host $NEW_HOST | awk '/has address/{print $NF}')

if ! grep -q $NEW_HOST $KNOWN_HOSTS ; then
echo Could not find $NEW_HOST in $KNOWN_HOSTS
exit
fi
ssh-keygen -R $NEW_HOST
[ -n $IP_ADDR ]  NEW_HOST=$NEW_HOST,$IP_ADDR
ssh-keyscan $NEW_HOST  $KNOWN_HOSTS
~~~

Jeff
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: various mishandlings of corrupt GPT

2013-11-04 Thread Jeffrey Bastian 
On Thu, Oct 24, 2013 at 12:46:17PM -0600, Chris Murphy wrote:
 On Oct 24, 2013, at 9:40 AM, Jeffrey Bastian jbast...@redhat.com wrote:
  I have a system that corrupts the backup GPT on every reboot.
 
 Certain RAID implementations write metadata at the end of the disk and
 step on the backup GPT in this manner. But that was on computers with
 BIOS firmware that weren't GPT aware. UEFI firmware obviously should
 be GPT aware so it'd be quite a bungling if its firmware RAID were
 writing metadata where the backup GPT goes. But it's worth seeing if
 the firmware is up to date.


Reartes Guillermo mentioned the same thing with RAID in BZ 951244, so I
checked my system UEFI settings and indeed it was configured for RAID.
I switched it to AHCI and that solved the problem!  No more backup GPT
corruption!

I switched it back to RAID just to be sure and the backup GPT was
corrupt again.

I guess I'll leave it in AHCI since I wasn't using the hardware RAID
anyway.

Thank you!
Jeff
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: various mishandlings of corrupt GPT

2013-10-24 Thread Jeffrey Bastian 
On Wed, Oct 23, 2013 at 10:49:35PM -0600, Chris Murphy wrote:
 The bottom line question is, would it be useful to have an fsck_gpt
 run by systemd at either startup or shutdown time? 

I have a system that corrupts the backup GPT on every reboot: the CRC32
in the backup GPT is always 0.  I run parted or gdisk to fix it, verify
that everything is good (even by dd'ing the backup GPT and manually
inspecting it), then reboot and bam, it's corrupt again (i.e., set to
0).  I don't know if it's an OS bug, a firmware bug, or something with
the actual disk.

This was causing some headaches for me with anaconda:
https://bugzilla.redhat.com/show_bug.cgi?id=950145
https://bugzilla.redhat.com/show_bug.cgi?id=951244  -- especially this

So fsck_gpt would indeed be useful.  (Although it would probably force
me to switch from UEFI back to legacy BIOS emulation and back to MBR
partitioning on this one system.)

Jeff
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Which platforms have GRUB?

2013-06-14 Thread Jeffrey Bastian 
On Fri, Jun 14, 2013 at 02:48:42PM -0400, Eric H. Christensen wrote:
 I'm working on text in the Fedora Security Guide discussing GRUB.
 There is a sentence that reads [Fedora] ships with the GRUB boot
 loader on the x86 platform. and I am curious as to how true that is.
 Do we not use GRUB on any other platform?


Most ARM systems use U-boot. PPC64 uses yaboot.  I don't know what s390x
uses.

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

Re: The official way to upgrade F18 to F19

2013-05-29 Thread Jeffrey Bastian 
On Wed, May 29, 2013 at 06:16:11PM +0200, Dario Lesca wrote:
  The installation repo isn't available.
  You need to specify one with --instrepo.
 
 Some suggest?


I used this command over this past weekend:

fedup --network 19 --debuglog=/var/log/fedupdebug.log \
  --instrepo 
http://dl.fedoraproject.org/pub/fedora/linux/development/19/x86_64/os/

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

Re: when startup delays become bugs

2013-05-15 Thread Jeffrey Bastian 
On Tue, May 14, 2013 at 05:58:42PM -0600, Chris Murphy wrote:
 And avahi doesn't play nice with the localdomain extension anyway.
 Without the extension I ssh into boxes just like I do from Windows or
 OS X:
 
 ssh chris@f19q.local
 
 Whereas if I change the hostname to f19q.localdomain, to ssh into the
 system now I have to use a non-obvious, nonstandard:
 
 ssh chris@f19q.localdomain



Hmm, that doesn't seem right.  I have a .localdomain on all my hostnames
and Avahi and mDNS work just fine with the special .local domain.

  [jbastian@tarantula ~]$ hostname
  tarantula.localdomain

  [jbastian@tarantula ~]$ ip addr show em1 | grep inet | awk '{print $2}'
  192.168.1.75/24
  fe80::f2de:f1ff:fe15:6496/64

From another system:

  [jbastian@gecko ~]$ avahi-resolve-host-name tarantula.local
  tarantula.local   fe80::f2de:f1ff:fe15:6496

  [jbastian@gecko ~]$ ping -n tarantula.local
  PING tarantula.local (192.168.1.75) 56(84) bytes of data.
  64 bytes from 192.168.1.75: icmp_seq=1 ttl=64 time=0.281 ms
  ...

Maybe you have iptables blocking mDNS traffic (tcp port 5353)?

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

Re: when startup delays become bugs

2013-05-14 Thread Jeffrey Bastian 
On Tue, May 14, 2013 at 03:51:44PM -0600, Chris Murphy wrote:
 But firewalld goes from 7 seconds to 18 seconds? Why? avahi-daemon,
 restorecond, all are an order of magnitude longer on F19 than F18.

And it was even faster on F17.  I had F17 cold booting to a usable
Xfce desktop in 3.6 seconds by following Harald Hoyer's guide [1]:
  Startup finished in 1470ms (kernel) + 2130ms (userspace) = 3601ms

But F18 and F19 now take 16 seconds on the same system:
  Startup finished in 1.061s (kernel) + 15.299s (userspace) = 16.361s

The slowest component on F19 is this new wait service:
 10.102s NetworkManager-wait-online.service

This service doesn't seem to do anything other than wait until the
network is fully up.  This really skews unfavorably the boot time
reported by systemd-analyze.  But if I mask that service and reboot,
everthing still appears to work fine and systemd-analyze reports a boot
time of only 6.2 seconds.

I wonder if there are other oddities like this that are skewing the
statistics reported by systemd-analyze.

Jeff

[1] 
http://www.harald-hoyer.de/personal/blog/fedora-17-boot-optimization-from-15-to-3-seconds
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F19 DVD over size - what to drop?

2013-05-02 Thread Jeffrey Bastian 
On Wed, May 01, 2013 at 01:55:29PM -0700, Robert Relyea wrote:
  Thunderbird is new? Drop it.
 
 Hardly new since I've been using it on Fedora for 8 years now.

It's not a new package.  Rather, it's new for the installation DVD.

Fedora 18 did not include thunderbird on the install DVD:
http://dl.fedoraproject.org/pub/fedora/linux/releases/18/Fedora/x86_64/os/Packages/t/

It was available in the Everything set, though:
http://dl.fedoraproject.org/pub/fedora/linux/releases/18/Everything/x86_64/os/Packages/t/

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

Re: UEFI testing of F19 Alpha RC2 requested

2013-04-10 Thread Jeffrey Bastian 
On Wed, Apr 10, 2013 at 10:08:31AM -0700, Adam Williamson wrote:
 process), does it succeed, or do you get an error? And if it
 succeeds, does the installed system boot - at least as far as grub?


I tried RC1 yesterday and it installs, but it gets stuck at the 
Welcome to GRUB! text.  It doesn't even get to the grub prompt.

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

It looks like grub2 is the same version -- 2.00-16.fc19 -- in both RC1
and RC2.

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

Re: what is initramfs-0-rescue in F19?

2013-04-08 Thread Jeffrey Bastian 
On Sun, Apr 07, 2013 at 03:06:51PM +0200, Harald Hoyer wrote:
 install dracut-nohostonly if you don't want that... see the Release
 Notes of http://fedoraproject.org/wiki/Features/DracutHostOnly


I removed my initramfs-0-rescue-* file because I didn't know what it was
and no rpm claimed to own it.  How do I get it back?  I've tried running
dracut with various options and it doesn't regenerate the image.

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

Re: what is initramfs-0-rescue in F19?

2013-04-08 Thread Jeffrey Bastian 
On Mon, Apr 08, 2013 at 04:03:47PM -0500, Jeffrey Bastian wrote:
 I removed my initramfs-0-rescue-* file because I didn't know what it was
 and no rpm claimed to own it.  How do I get it back?  I've tried running
 dracut with various options and it doesn't regenerate the image.

Attempting to answer my own question...  I'm not sure if this is the
correct way, but I tried running this:

  /etc/kernel/postinst.d/51-dracut-rescue-postinst.sh $(uname -r) \
   /boot/initramfs-$(uname -r)*

And now I have rescue files again:

  # ls -latr /boot/*0-rescue*
  -rw---. 1 root root 27496022 Apr  8 16:46 /boot/initramfs-0-rescue-...img
  -rw---. 1 root root  7860871 Apr  8 16:46 /boot/vmlinuz-0-rescue-...


Is dracut supposed to run the /etc/kernel/postinst.d/* scripts
automatically?  I ran dracut through 'bash -x' and strace and it didn't
appear to even look in /etc/kernel/postinst.d


The reason I removed the file in the first place is because grub2-mkconfig
generates a not-very-descriptive entry in the menu.  My grub.cfg now has this:
  menuentry 'Fedora, with Linux 0-rescue-344...c20' ... {

Furthermore, my system is set up to dual boot between Fedora 17 and 19
Alpha, and now grub2-mkconfig has set this rescue image as the default
kernel for F17.
  menuentry 'Fedora release 17 (Beefy Miracle)' ... {
...
linux /vmlinuz-0-rescue-344...
  }

That seems a little strange to me.

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

Self Introduction

2013-03-12 Thread Jeffrey Bastian 
Hello Fedora developers,

I've been a long time Fedora user, and Red Hat Linux before that, going
back to RHL 5.2 (I still have the box set of CDs!).  I've opened many
bug reports over the years, and tried to include patches in a few, but
now I'm venturing into package maintenance.

I recently opened 3 package review requests:

1. python-tftpy - TFTP module for Python
   https://bugzilla.redhat.com/show_bug.cgi?id=919590

2. python-pyipmi - an IPMI module for Python
   https://bugzilla.redhat.com/show_bug.cgi?id=919591

3. cxmanage - a tool to manage Calxeda servers
   https://bugzilla.redhat.com/show_bug.cgi?id=919592

I'll get my feet wet with python-tftpy first because the second two
requests depend on a feature request for ipmitool:
  add cxoem command to ipmitool
  https://bugzilla.redhat.com/show_bug.cgi?id=918296

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