Bug 1162467 - Generic branded workstation devassistant doesn't search for RPMs
Summary: Generic branded workstation devassistant doesn't search for RPMs
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: devassistant
Version: 21
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Bohuslav "Slavek" Kabrda
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-11-11 06:52 UTC by M. Edward (Ed) Borasky
Modified: 2014-11-13 18:06 UTC (History)
4 users (show)

Fixed In Version: devassistant-0.9.2-8.fc21
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-11-13 18:06:54 UTC


Attachments (Terms of Use)
List of packages installed in the Fedora-branded ISO - the one where devassistant works (153.51 KB, text/plain)
2014-11-11 06:52 UTC, M. Edward (Ed) Borasky
no flags Details
List of packages installed in the Generic-branded ISO - the one where devassistant doesn't work (153.59 KB, text/plain)
2014-11-11 06:53 UTC, M. Edward (Ed) Borasky
no flags Details

Description M. Edward (Ed) Borasky 2014-11-11 06:52:14 UTC
Created attachment 956119 [details]
List of packages installed in the Fedora-branded ISO - the one where devassistant works

Description of problem: I'm building a remix based on Fedora workstation. When I leave the fedora-release-* and fedora-logos* RPMs in the build and open devassistant, when I try to create an application and the needed packages aren't there, devassistant offers to install the missing RPMs. But if I switch to the *generic* branding, devassistant just errors if dependencies are missing.



Version-Release number of selected component (if applicable): devassistant.noarch                0.9.2-5.fc21              @fedora/$releasever
g


Steps to Reproduce:
1. Build a generic-branded version of Fedora Workstation iso
2. Boot it in a virtual machine and start 'devassistant'.
3. Try to create a C project.

Actual results:

Project name will be converted to lowercase letters (sdsdsdsd)
Copying c source tree to project destination
cp -r /usr/share/devassistant/files/crt/c/. "/home/liveuser/sdsdsdsd"
Run autoreconf
autoreconf --install
/bin/sh: autoreconf: command not found
/bin/sh: autoreconf: command not found



Expected results: On a normal workstation system, devassistant does a dependency check and then offers to install the missing RPMs.


Additional info: I think it's "generic-release" that's broken, not 'devassistant'. But I'd expect devassistant to give some kind of error message if it couldn't perform the dependency check. I'm attaching output of 'yum list installed' from the Fedora-branded and generic-branded ISOs.

Comment 1 M. Edward (Ed) Borasky 2014-11-11 06:53:42 UTC
Created attachment 956121 [details]
List of packages installed in the Generic-branded ISO - the one where devassistant doesn't work

Comment 2 M. Edward (Ed) Borasky 2014-11-11 07:53:38 UTC
I just tried this with devassistant 0.9.2-6.fc21 - still fails.

Comment 3 Bohuslav "Slavek" Kabrda 2014-11-11 08:09:54 UTC
Yeah, it's the generic-release that breaks DevAssistant. The problem is that due to the way that DevAssistant dependency installation works, there's no way to reliably tell if the dependencies failed to install or there are no dependencies to install on current platform.
DevAssistant thinks that it's on a platform called "generic" and it doesn't know that it's Fedora. Since "generic" platform doesn't have any system dependency type assigned to it, DevAssistant just passes dep installation and tries to actually run.

Now, there are few ways to solve this:
- We could tell DevAssistant that "generic" is in fact "fedora" and everything would work.
- We could talk to people who designed generic-release. I think that the problem is in fact there, because info in /etc/os-release should contain "NAME=Fedora". not "NAME=Generic". There is no "Generic" distro, this just seems to be wrong.
- Either way, DevAssistant should probably fail if it is run on a platform with unsupported dependency management. OTOH I think we should preserve the current behaviour, since people will want to create multi-platform assistants and these assistants may install some deps on one platform, while installing nothing on a different platform.

Comment 4 M. Edward (Ed) Borasky 2014-11-11 08:34:40 UTC
(In reply to Bohuslav "Slavek" Kabrda from comment #3)
> Yeah, it's the generic-release that breaks DevAssistant. The problem is that
> due to the way that DevAssistant dependency installation works, there's no
> way to reliably tell if the dependencies failed to install or there are no
> dependencies to install on current platform.
> DevAssistant thinks that it's on a platform called "generic" and it doesn't
> know that it's Fedora. Since "generic" platform doesn't have any system
> dependency type assigned to it, DevAssistant just passes dep installation
> and tries to actually run.
> 
> Now, there are few ways to solve this:
> - We could tell DevAssistant that "generic" is in fact "fedora" and
> everything would work.
> - We could talk to people who designed generic-release. I think that the
> problem is in fact there, because info in /etc/os-release should contain
> "NAME=Fedora". not "NAME=Generic". There is no "Generic" distro, this just
> seems to be wrong.
> - Either way, DevAssistant should probably fail if it is run on a platform
> with unsupported dependency management. OTOH I think we should preserve the
> current behaviour, since people will want to create multi-platform
> assistants and these assistants may install some deps on one platform, while
> installing nothing on a different platform.

I'm actually shipping my own branding RPMs now, so I *could* set NAME=Fedora if that doesn't arouse the IP lawyers.

Comment 5 Bohuslav "Slavek" Kabrda 2014-11-11 08:56:21 UTC
Hmm, I think we actually unintentionally fixed this upstream :)

The code for getting distro name now uses Python's platform.linux_distribution() with full_distribution_name=0 - that means that the code will actually only check for "/etc/fedora-release" file and if it finds it, it uses "fedora" as a result. I'll backport the fix and we'll see - it should fix the issue (it changes DA behaviour slightly in some cases, but it only breaks behaviour undocumented for 0.9.x, so it should be fine).

Comment 6 Fedora Update System 2014-11-11 11:10:54 UTC
devassistant-0.9.2-7.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/devassistant-0.9.2-7.fc21

Comment 7 Bohuslav "Slavek" Kabrda 2014-11-11 11:15:39 UTC
Ed, could you please give the update a try and tell me whether it works fine for you? Thanks!

Comment 8 M. Edward (Ed) Borasky 2014-11-11 16:59:26 UTC
(In reply to Bohuslav "Slavek" Kabrda from comment #7)
> Ed, could you please give the update a try and tell me whether it works fine
> for you? Thanks!

Yup - just created a C project and the RPM search is working!

Comment 9 M. Edward (Ed) Borasky 2014-11-11 17:34:23 UTC
It seems to be searching for the RPMs but it doesn't seem to actually install them

INFO: Checking for presence of gcc...
DEBUG: rpm -q --whatprovides "gcc"
DEBUG: gcc-4.9.2-1.fc21.x86_64
DEBUG: 0
INFO: Found gcc-4.9.2-1.fc21.x86_64
INFO: Checking for presence of glibc-devel...
DEBUG: rpm -q --whatprovides "glibc-devel"
DEBUG: glibc-devel-2.20-5.fc21.x86_64
DEBUG: 0
INFO: Found glibc-devel-2.20-5.fc21.x86_64
INFO: Checking for presence of automake...
DEBUG: rpm -q --whatprovides "automake"
DEBUG: no package provides automake
DEBUG: 1
INFO: Not found, will install
INFO: Checking for presence of autoconf...
DEBUG: rpm -q --whatprovides "autoconf"
DEBUG: no package provides autoconf
DEBUG: 1
INFO: Not found, will install
INFO: Checking for presence of valgrind...
DEBUG: rpm -q --whatprovides "valgrind"
DEBUG: no package provides valgrind
DEBUG: 1
INFO: Not found, will install
INFO: Checking for presence of gdb...
DEBUG: rpm -q --whatprovides "gdb"
DEBUG: gdb-7.8.1-30.fc21.x86_64
DEBUG: 0
INFO: Found gdb-7.8.1-30.fc21.x86_64
INFO: Checking for presence of strace...
DEBUG: rpm -q --whatprovides "strace"
DEBUG: no package provides strace
DEBUG: 1
INFO: Not found, will install
INFO: Resolving RPM dependencies ...
DEBUG: Installing/Updating:
DEBUG: 1:valgrind-3.10.0-5.fc21.x86_64
DEBUG: perl-Test-Harness-3.33-1.fc21.noarch
DEBUG: strace-4.9-3.fc21.x86_64
DEBUG: m4-1.4.17-6.fc21.x86_64
DEBUG: autoconf-2.69-15.fc21.noarch
DEBUG: automake-1.14.1-5.fc21.noarch
INFO: Installing dependencies, sit back and relax ...
DEBUG: pkexec /usr/libexec/da_auth << DA_AS_USER_ROOT
yum -y install "1:valgrind-3.10.0-5.fc21.x86_64" "perl-Test-Harness-3.33-1.fc21.noarch" "strace-4.9-3.fc21.x86_64" "m4-1.4.17-6.fc21.x86_64" "autoconf-2.69-15.fc21.noarch" "automake-1.14.1-5.fc21.noarch"
DA_AS_USER_ROOT
DEBUG: 0
INFO: Successfully installed dependencies!
DEBUG: dirname "/home/znmeb/rerer"
DEBUG: /home/znmeb
DEBUG: 0
DEBUG: basename "/home/znmeb/rerer" | tr '[A-Z]' '[a-z]'
DEBUG: rerer
DEBUG: 0
INFO: Project name will be converted to lowercase letters (rerer)
DEBUG: ls "/home/znmeb/rerer"
DEBUG: ls: cannot access /home/znmeb/rerer: No such file or directory
DEBUG: 2
INFO: Copying c source tree to project destination
INFO: cp -r /usr/share/devassistant/files/crt/c/. "/home/znmeb/rerer"
DEBUG: 0
DEBUG: cd "/home/znmeb/rerer"
DEBUG: sed -i "s|CDevelopmentTool|rerer|" configure.ac
DEBUG: 0
DEBUG: mv cdevelopmenttool.spec "rerer.spec"
DEBUG: 0
DEBUG: sed -i "s|cdevelopmenttool|rerer|" "rerer.spec"
DEBUG: 0
DEBUG: git config --global user.name
DEBUG: 1
DEBUG: git config --global user.name "M. Edward (Ed) Borasky"
DEBUG: 0
DEBUG: git config --global user.email
DEBUG: 1
DEBUG: echo "znmeb@znmeb.net" | grep -q '\w\+@\w\+\.\w\+'
DEBUG: 0
DEBUG: git config --global user.email "znmeb@znmeb.net"
DEBUG: 0
DEBUG: git init
DEBUG: Initialized empty Git repository in /home/znmeb/rerer/.git/
DEBUG: 0
DEBUG: git add .
DEBUG: 0
DEBUG: git commit -m "Initial commit"
DEBUG: [master (root-commit) 80d8ab2] Initial commit
DEBUG: 12 files changed, 432 insertions(+)
DEBUG:  create mode 100644 .devassistant
DEBUG:  create mode 100644 AUTHORS
DEBUG:  create mode 100644 ChangeLog
DEBUG:  create mode 100644 Makefile.am
DEBUG:  create mode 100644 NEWS
DEBUG:  create mode 100644 README
DEBUG:  create mode 100644 client.c
DEBUG:  create mode 100644 configure.ac
DEBUG:  create mode 100644 files.c
DEBUG:  create mode 100644 rerer.spec
DEBUG:  create mode 100644 server.c
DEBUG:  create mode 100644 simple_threads.c
DEBUG: 0
INFO: Run autoreconf
INFO: autoreconf --install
INFO: /bin/sh: autoreconf: command not found
DEBUG: 127
ERROR: /bin/sh: autoreconf: command not found

I am in the 'wheel' group and it did ask for a password, but it doesn't seem to have installed the RPMs.

Comment 10 Fedora Update System 2014-11-12 11:14:57 UTC
devassistant-0.9.2-8.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/devassistant-0.9.2-8.fc21

Comment 11 M. Edward (Ed) Borasky 2014-11-12 19:08:26 UTC
devassistant-0.9.2-8.fc21 works!! Just did

da crt -c -n birdbrain

on a generic ISO and it made a project all the way to completion.

Comment 12 Fedora Update System 2014-11-13 18:06:54 UTC
devassistant-0.9.2-8.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.