Summary: | sys-devel/crossdev-20160602-r1 should check overlay presence in when -oO is set and report nicer error | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | R030t1 |
Component: | Current packages | Assignee: | Gentoo Crossdev team <crossdev> |
Status: | UNCONFIRMED --- | ||
Severity: | normal | CC: | embedded, slyfox, tsmksubc, vapier |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
cross-aarch64-unknown-linux-gnu-info.log
cross-aarch64-unknown-linux-gnu-binutils.log |
Description
R030t1
2017-09-25 04:49:16 UTC
crossdev tells you to attach log files to help investigation. Can you do that? Created attachment 496784 [details] cross-aarch64-unknown-linux-gnu-info.log (In reply to Sergei Trofimovich from comment #1) > crossdev tells you to attach log files to help investigation. > Can you do that? For the problem in the title, no logs are produced. When a profile is not set logs are produced, but the only error states that a profile is not set. When a profile is set again, no logs are produced, crossdev immediately exits. I have attached the informational log containing environment settings. Created attachment 496786 [details]
cross-aarch64-unknown-linux-gnu-binutils.log
I have made some very invasive changes to the crossdev script without much luck. Forcefully setting the values used in the test relevant to the last message (https://gitweb.gentoo.org/proj/crossdev.git/tree/crossdev#n722) to presumed good values produces the notice that no ebuilds satisfy $CTARGET/binutils. At this point I can no longer continue using crossdev, which is stalling my progress on my SBC projects. I don't know how to continue from here. It looks like too many things are conflated here. For example cross-aarch64-unknown-linux-gnu-info.log output does not match output in #comment1. What does fail for you? Building initial cross-toolchain or using it? My apologies if I am conflating anything. I listed 3 issues in series. I believe the root of the issue, if there is one, is whatever problem is causing crossdev to leave PORTAGE_CONFIGROOT unset when invoked (`crossdev -t aarch64-unknown-linux-gnu`). As I was not able to troubleshoot that issue directly, I detailed some of my attempts to work around it. The things I have detailed indicate to me that the automatic detection of various variables that crossdev does has been broken in some way. I have recently tried to invoke crossdev on what was a working installation and it now fails in the exact same way as detailed in the bug report's topic. This leads me to believe there has been a major regression in the script. If the original comment is not clear: simply invoking crossdev produces the quoted input and no other action is taken. (In reply to R030t1 from comment #7) > If the original comment is not clear: simply invoking crossdev produces the > quoted input and no other action is taken. "Quoted output," my apologies. (In reply to Sergei Trofimovich from comment #5) > It looks like too many things are conflated here. > For example cross-aarch64-unknown-linux-gnu-info.log output does not match > output in #comment1. > > What does fail for you? Building initial cross-toolchain or using it? Apologies again, I did not directly answer the question. Building the initial toolchain fails. 'crossdev -t aarch64-unknown-linux-gnu' should not set PORTAGE_CONFIGROOT variable. The toolchain is built on host system as a normal package (it runs on host and is tracked as host's ebuild in package database) The main difference of cross-aarch64-unknown-linux-gnu/gcc from sys-devel/gcc if the --target= (and sysroot, and other tweaks) flag. But it's still a package that is supposed to run on host, not target. It uses /etc/portage for PORTAGE_CONFIGROOT, not /usr/$CHOST. Why do you need to set PORTAGE_CONFIGROOT? Can you show how things fail for you when you don't set PORTAGE_CONFIGROOT? (In reply to R030t1 from comment #2) > Created attachment 496784 [details] > cross-aarch64-unknown-linux-gnu-info.log > > (In reply to Sergei Trofimovich from comment #1) > > crossdev tells you to attach log files to help investigation. > > Can you do that? > > For the problem in the title, no logs are produced. When a profile is not > set logs are produced, but the only error states that a profile is not set. > When a profile is set again, no logs are produced, crossdev immediately > exits. > > I have attached the informational log containing environment settings. From your command crossdev -oO /usr/local/portage/odroid-c2 -t aarch64-unknown-linux-gnu The cross ebuilds are saved in your /usr/local/portage/odroid-c2 overlay. From your logs Repositories: gentoo location: /usr/portage sync-type: rsync sync-uri: rsync://rsync.gentoo.org/gentoo-portage priority: -1000 There are no settings for your /usr/local/portage/odroid-c2 overlay, so portage will not search there for the cross- ebuilds. Add your /usr/local/portage/odroid-c2 overlay to /etc/portage/repos.conf/ (In reply to Sergei Trofimovich from comment #10) > 'crossdev -t aarch64-unknown-linux-gnu' should not set PORTAGE_CONFIGROOT > variable. The toolchain is built on host system as a normal package (it runs > on host and is tracked as host's ebuild in package database) > > The main difference of cross-aarch64-unknown-linux-gnu/gcc from sys-devel/gcc > if the --target= (and sysroot, and other tweaks) flag. But it's still a > package > that is supposed to run on host, not target. It uses /etc/portage for > PORTAGE_CONFIGROOT, not /usr/$CHOST. > > Why do you need to set PORTAGE_CONFIGROOT? Can you show how things fail for > you when you don't set PORTAGE_CONFIGROOT? I did show how things fail for me if I do not set PORTAGE_CONFIGROOT: crossdev prints its initial configuration banner and then immediately exits. There was a Wiki page that showed sample output that had PORTAGE_CONFIGROOT set automatically. Sadly, I can't find it. If I set it manually crossdev will continue. The files in PORTAGE_CONFIGROOT, typically /usr/$TARGET, configure the packages installed to that location (from memory). Mr. Bamford, this is in reply to you, but quoting your message makes my browser unusable. I have a file /etc/portage/repos.conf/odroid-c2.conf. There is a directory /usr/local/portage/odroid-c2/cross-aarch64-unknown-gnu that was presumably created by crossdev and populated with ebuilds for a select number of packages (binutils, gcc, gdb, glibc, and linux-headers). Also important is that a previously configured system can no longer produce cross toolchains using newer versions of crossdev. It did successfully produce some before. Thank you both for the help. (In reply to R030t1 from comment #13) > Mr. Bamford, this is in reply to you, but quoting your message makes my > browser unusable. > > I have a file /etc/portage/repos.conf/odroid-c2.conf. There is a directory > /usr/local/portage/odroid-c2/cross-aarch64-unknown-gnu that was presumably > created by crossdev and populated with ebuilds for a select number of > packages (binutils, gcc, gdb, glibc, and linux-headers). > > Also important is that a previously configured system can no longer produce > cross toolchains using newer versions of crossdev. It did successfully > produce some before. > > Thank you both for the help. It should be /etc/portage/repos.conf.d/odroid-c2.conf, not /etc/portage/repos.conf.d/odroid-c2.conf. (In reply to Sergei Trofimovich from comment #14) > (In reply to R030t1 from comment #13) [trying again] It should be /etc/portage/repos.conf.d/odroid-c2.conf, not /etc/portage/repos.conf/odroid-c2.conf. Lets leave crossdev out of it meanwhile. I'll come back to that. There are two steps to setting up a local overlay. 1. Creating the overlay directory structures and adding zero or more ebuilds. 2. Telling portage about the overlay, so it uses it for dependency resolution. These separate steps apply to any overlay. When you use crossdev --ov-output it will create new overlay for the cross ebuilds but not perform step 2, so portage will not use the overlay. When step 2 has been performed, the overlay will be listed in emerge --info. I have. Repositories: gentoo location: /usr/portage sync-type: rsync sync-uri: rsync://192.168.10.119/gentoo-portage priority: -1000 sync-rsync-extra-opts: --exclude=metadata/cache gentoo_static location: /usr/local/gentoo-static masters: gentoo priority: 0 gentoo is the normal repository, gentoo_static is crossdev and everything else needed to install gentoo with a static /dev. That second entry was missing in your emerge --info output above. Nothing works until the overlay used by crossdev appears here. Even then, if the overlay directory structure is not correct, portage will silently fail to find anything. Having an empty overlay for whatever reason, is not an error. As a further test, after the cross ebuilds are in place, emerge -pv cross-aarch64-unknown-linux-gnu/gcc should at least find the ebuild, (put your own tuple there). (In reply to Sergei Trofimovich from comment #15) > (In reply to Sergei Trofimovich from comment #14) > > (In reply to R030t1 from comment #13) > > [trying again] > It should be /etc/portage/repos.conf.d/odroid-c2.conf, not > /etc/portage/repos.conf/odroid-c2.conf. Thank you both, and sorry Mr. Bamford. I forgot to put into practice Mr. Trofimovich's advice. I moved /etc/portage/repos.conf/ to /etc/portage/repos.conf.d/ and crossdev proceeded to complete up to stage 2 with the usual arguments. Unfortunately, it did not finish and produce a C++ compiler. I attempted to merge @system in the crossroot and somehow /usr/bin/emerge was deleted. I am attempting to fix my system now. Shall I open a new bug for the lack of C++ compiler generation? > Unfortunately, it did not finish and produce a C++ compiler. I don't understand that sentence. Did crossdev fail? When crossdev fails it asks to attach the logs. > Shall I open a new bug for the lack of C++ compiler generation? I think this bug is good enough to get you a cross-compiler. (In reply to Sergei Trofimovich from comment #18) > > Unfortunately, it did not finish and produce a C++ compiler. > I don't understand that sentence. Did crossdev fail? When crossdev fails it > asks to attach the logs. > > > Shall I open a new bug for the lack of C++ compiler generation? > I think this bug is good enough to get you a cross-compiler. Yes, I think I misunderstood what was happening. A C++ compiler exists after crossdev completes. Thank you for the help! There was actually a bug here, or maybe two: no place to my knowledge states that /etc/portage/repos.conf.d/ is needed over /etc/portage/repos.conf/, and crossdev fails messily instead of recognizing that configuration does not exist and warning the user about it. I apologize for marking this bug as resolved, that was premature. (In reply to R030t1 from comment #20) > There was actually a bug here, or maybe two: no place to my knowledge states > that /etc/portage/repos.conf.d/ is needed over /etc/portage/repos.conf/ Where and how would you like to see that documented? 'man portage'? > crossdev fails messily instead of recognizing that configuration does not > exist and warning the user about it. emerge log reports quite a concise error of missing ebuild: """emerge: there are no ebuilds to satisfy "cross-s390-unknown-linux-gnu/binutils.""" And another log reports list of known repositories. Is it a messy failure? What would you like to see instead? (In reply to Sergei Trofimovich from comment #21) > (In reply to R030t1 from comment #20) > > There was actually a bug here, or maybe two: no place to my knowledge states > > that /etc/portage/repos.conf.d/ is needed over /etc/portage/repos.conf/ > > Where and how would you like to see that documented? 'man portage'? > I've read large sections of the man pages at some time or another, but I still keep coming across new information that I need for my day to day use of my system. I am not sure what a good solution is. > > crossdev fails messily instead of recognizing that configuration does not > > exist and warning the user about it. > > emerge log reports quite a concise error of missing ebuild: > """emerge: there are no ebuilds to satisfy > "cross-s390-unknown-linux-gnu/binutils.""" > > And another log reports list of known repositories. > > Is it a messy failure? What would you like to see instead? Stating possible causes is usually a good idea. Before I understood what crossdev was doing, I had no idea that that message meant the configuration was incorrect in the way that it was. Perhaps it was right but there was no ebuild? Cheers! I'm not sure where this "repos.conf.d" idea came from; portage looks at /etc/portage/repos.conf/, not /etc/portage/repos.conf.d/. (In reply to Mike Gilbert from comment #23) > I'm not sure where this "repos.conf.d" idea came from; portage looks at > /etc/portage/repos.conf/, not /etc/portage/repos.conf.d/. I'm glad you mentioned this, I saw portage "ignoring" my settings in repos.conf to use webrsync-gpg and was about to file bugs against portage and/or eix. I have seen name.conf.d when the configuration file has been turned into a directory, but I didn't see anything else mention it (I even looked through crossdev itself). (In reply to Mike Gilbert from comment #23) > I'm not sure where this "repos.conf.d" idea came from; portage looks at > /etc/portage/repos.conf/, not /etc/portage/repos.conf.d/. All is my fault. I've conflated things up. My apologies. The only thing left in this bug is to make crossdev error message nicer when overlay path is not known to emerge and a few hints on how to add it, right? |