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.
Created attachment 956121 [details] List of packages installed in the Generic-branded ISO - the one where devassistant doesn't work
I just tried this with devassistant 0.9.2-6.fc21 - still fails.
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.
(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.
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).
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
Ed, could you please give the update a try and tell me whether it works fine for you? Thanks!
(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!
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" | grep -q '\w\+@\w\+\.\w\+' DEBUG: 0 DEBUG: git config --global user.email "znmeb" 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.
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
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.
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.