Description of problem: lfp seems to build okay, but stalls trying to install. Version-Release number of selected component (if applicable): lpf-0.1-6.36e5aa0.fc20.noarch How reproducible: Happens always (at least with skype, the only lpf pkg I've tried). Steps to Reproduce: 1. install lpf 2. install lpf-skype 3. add user to pkg-build 4. start lpf-gui 5. build skype Actual results: "Install" phase stalls forever. The following error repeats at high rate : ls: cannot open directory /var/lib/lpf/rpms/skype: Permission denied ls: cannot open directory /var/lib/lpf/rpms/skype: Permission denied ls: cannot open directory /var/lib/lpf/rpms/skype: Permission denied ... Expected results: Additional info: The resulting packages work great, though! Skype seems to work better than pkg from web-site. So glad.
This looks like a a permission problem (sic!)... First question: have you logged out and in again after adding you to the pkg-build group? If not, please do so and report results. Next question: If you still have problems after logging out-in, this might be a sudo issue. Are you using sudo otherwise, and have the overall feeling that your installation is sane? In particular, have you this line at the very end of your /etc/sudoers file? #includedir /etc/sudoers.d Also, please check that your sg(1) utility is sane. What gives the command $ sg pkg-build "echo foo" for results?
(In reply to Alec Leamas from comment #1) > This looks like a a permission problem (sic!)... Yeah, I agree. ;-) > First question: have you logged out and in again after adding you to the > pkg-build group? If not, please do so and report results. Yes. I just rechecked, though, using lpf after logging into another virtual console. > Next question: If you still have problems after logging out-in, this might > be a sudo issue. Are you using sudo otherwise, and have the overall feeling > that your installation is sane? In particular, have you this line at the > very end of your /etc/sudoers file? > > #includedir /etc/sudoers.d Check. It's in there. I *always* use sudo for sysadmin work. > Also, please check that your sg(1) utility is sane. What gives the command > > $ sg pkg-build "echo foo" $ sg pkg-build "echo foo" foo Sorry, I should have said before, but I didn't want to prejudge the situation. The directory /var/lib/lpf/rpms/skype is 600. That's probably the permission problem; I just didn't know for sure what caused it. But I think I do. yum had a long lived bug, now fixed, in which it did not manage permissions properly, assuming umask instead of setting it. This caused 'sudo yum' to break things since it inherits umask, while 'sudo -i yum' worked since is sources root env. This has a suspiciously similar flavor. Could that be what is happening here? Regardless, repeating ls indefinitely is incorrect behavior. This error should be caught. In this respect, lpf is okay, BTW, it's just lpf-gui that doesn't recognize the fatal error and retries indefinitely.
(In reply to Paul DeStefano from comment #2) > (In reply to Alec Leamas from comment #1) [snip] So, the easy parts are checked and OK. > Sorry, I should have said before, but I didn't want to prejudge the > situation. The directory /var/lib/lpf/rpms/skype is 600. That's probably > the permission problem; I just didn't know for sure what caused it. But I > think I do. yum had a long lived bug, now fixed, in which it did not manage > permissions properly, assuming umask instead of setting it. This caused > 'sudo yum' to break things since it inherits umask, while 'sudo -i yum' > worked since is sources root env. This has a suspiciously similar flavor. > Could that be what is happening here? I don't *think* so. These are directories under /var/lib/lpf which by definition are generated by lpf rather than installed by yum. Nevertheless, it's an important clue. My corresponding directories are 755. Might it be that you have a more restrictive umask than most other users (my is 0002)? And what's the pkg-build user's umask on your machine (also 0002 for me)? > Regardless, repeating ls indefinitely is incorrect behavior. This error > should be caught. Agreed. > In this respect, lpf is okay, BTW, it's just lpf-gui that > doesn't recognize the fatal error and retries indefinitely. Yes, we'll certainly need to handle that. Good catch!
Thanks for your help Alec. > > Sorry, I should have said before, but I didn't want to prejudge the > > situation. The directory /var/lib/lpf/rpms/skype is 600. That's probably > > the permission problem; I just didn't know for sure what caused it. But I > > think I do. yum had a long lived bug, now fixed, in which it did not manage > > permissions properly, assuming umask instead of setting it. This caused > > 'sudo yum' to break things since it inherits umask, while 'sudo -i yum' > > worked since is sources root env. This has a suspiciously similar flavor. > > Could that be what is happening here? > > I don't *think* so. These are directories under /var/lib/lpf which by > definition are generated by lpf rather than installed by yum. > Nevertheless, it's an important clue. My corresponding directories are 755. > Might it be that you have a more restrictive umask than most other users (my > is 0002)? Oh, sorry, I wasn't clear. Your thought is what I was suggesting, not that yum was at fault here, too. Yes, In fact my mask is 0077. That's why yum's old behavior failed and required sudo -i. So, I think we are saying that our umask differences match our system differences exactly. > And what's the pkg-build user's umask on your machine (also 0002 > for me)? Hmm, my pkg-build user's home directory doesn't have any user-specific profile files. Does that answer your question? On my system, user pkg-build's shell is 'nologin' and it is impossible, as far as I know, to load that user's profile. I suspect you are running a specific command and want me to do it, too, but you stumped me; I can't figure out what it could be.
OK, this basically seems to be a umask problem. Since you have the test rig: Could you make a test,setting the umask to 0002 the following files, all in /usr/share/lpf/scripts (If you have the proper authorization for that, I guess)? .../scripts/lpf (~ line 225, after the " exec sg pkg-build "$0 $*"" line .../scripts/lpf-pkgbuild (line ~114, after the "exec $SUDO -u pkg-build"line) .../scripts/lpf-sudo-install (in the beginning, ~ line 10) --a
Bingo. It works, as far as I can tell. I added umaks 0002 to the top of all three scripts, yum erased skype, then ran lpf-gui. It complained a couple times about updates and gave an error on install again, but, I tried again and it asked for my password and now the two skype packages are installed like before and skyp works. This is great. I hadn't heard of LPF before; now I'm anxious to try out the flash plugin so I can ditch the thrid party repository I added.
Great! Thanks for help! Now, this seems a little bit like a corner case. There is still another bug under investigation, so I'll hold an update until this is also sorted out. But stay tuned, there *will* be an update based on these findings. Thanks again for reporting this bug and testing support!
lpf-0.1-8.36e5aa0.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/lpf-0.1-8.36e5aa0.fc19
lpf-0.1-8.36e5aa0.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/lpf-0.1-8.36e5aa0.fc20
*** Bug 1118714 has been marked as a duplicate of this bug. ***
Package lpf-0.1-8.36e5aa0.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing lpf-0.1-8.36e5aa0.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-10059/lpf-0.1-8.36e5aa0.fc19 then log in and leave karma (feedback).
lpf-0.1-8.36e5aa0.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/lpf-0.1-8.36e5aa0.fc21
lpf-0.1-8.36e5aa0.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
lpf-0.1-8.36e5aa0.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
Thank you! Gave karma, but still less than 3.
lpf-0.1-8.36e5aa0.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.