Hi, During a rebuild of all packages in sid, your package failed to build on i386. This rebuild was done with gcc 4.3 instead of gcc 4.2, because gcc 4.3 is now the default on most architectures (even if it's not the case on i386 yet). Consequently, many failures are caused by the switch to gcc 4.3. If you determine that this failure is caused by gcc 4.3, feel free to downgrade this bug to 'important' if your package is only built on i386, and this bug is specific to gcc 4.3 (i.e the package builds fine with gcc 4.2). Relevant part: http://people.debian.org/~lucas/logs/2008/05/06 A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! About the archive rebuild: The rebuild was done on about 50 AMD64 nodes of the Grid'5000 platform, using a clean chroot containing a sid i386 environment. Internet was not accessible from the build systems.
reassign 479944 schroot severity 479944 normal thanks Hi, perl failed to build using sbuild+schroot: It seems that this is caused by the fact that schroot logs in the user with $HOME set to the host's pwent, not the guest. My config is: host: user's home: /home/user chroot: user's home in /etc/passwd: /nonexistent (which doesn't exist)
Hi Lucas, it looks like '/nonexistent' comes from $HOME and '/home/user' from /etc/passwd, does that describe your setup? If the problem is due to this discrepancy, should this really 'serious'? Cheers,
This actually happened on the armel buildd ALL6500 with 5.0.10-9.1: http://buildd.debian.org/fetch.cgi?pkg=perl;ver=5.10.0-9.1;arch=armel;stamp=1210164842 lib/Module/Build/t/tilde......................................# Failed test at ../lib/Module/Build/t/tilde.t line 49. # got: '/nonexistent' # expected: '/home/buildd' 5.0.10-9 built OK on arcadelt. Cc'ing the armel buildd maintainers; I suppose the setup on ALL6500 should be changed. Cheers,
Lucas Nussbaum <lucas@lucas-nussbaum.net> writes: Interesting. Currently, we do make the assumption that the passwd database is the same both inside and outside (and /etc/schroot/setup.d/20copyfiles takes pains to make sure that this is the case, though the defaults only work in a basic setup without NIS or LDAP). I could alter this to reread the information after we have chroot()ed, though I will need to check that - libc doesn't cache struct passwd records - it doesn't cause a lot of breakage for non-standard setups where getpwent fails inside the chroot. I would also be interested to know /why/ this fails in your case. AFAIK it is perfectly legal to set $HOME to a value other than that found in passwd.pw_dir; this should not cause breakage. Should this testcase really be expecting the two to match perfectly in all situations? Regards, Roger
This appears to be the case here as well. ALL6500 uses schroot while other buildd's use sudo. As a workaround I can change buildd's $HOME to match inside schroot to the one outside (/home/buildd) and reschedule perl. I believe /nonexistent is used to catch packages trying to write to $HOME during builds.
Riku Voipio <riku.voipio@iki.fi> writes: Wow, I didn't realise anyone was using it in a real buildd environment yet! Does this mean you're using buildd-tools sbuild as well? If so, have you come across any issues with it? (I have no knowledge of anyone else using it in this way, so I am really interested to know of any testing as a buildd). Does this not lead to problems for packages which attempt to read files from $HOME during a build? Are there any cases where this is a problem? Regards, Roger
This buildd was set up before armel was taken as part of debian buildd network, and I was new at the nuances of setting up buildds.. Your versions of sbuild/schroot have been working fine (this is the first issue so far) so I haven't bothered reconfiguring them. For later buildd's managed under the debian.org system administration I used older versions just in case. Well it would quite clearly be a bug if a tool failed to work if it can't read a file from $HOME during build.. notice that /nonexistent passwd entry is created from the buildd-make-chroot script from buildd package. So this is a very old practice, and has rarely caused problems. I think qmake used to be problematic in this matter.
Roger Leigh <rleigh@whinlatter.ukfsn.org> writes: already do this: schroot is run on the host system. It uses the host libc, and hence also the host NSS modules (/lib/libnss*.so). These are loaded with dlopen on startup by the libc startup code. Once we chroot(), we still have those NSS modules open. If the NSS configuration inside the chroot is different (or we aren't using GNU libc), then there will be problems. i.e. getpw* can't work reliably. We can't even exec() ourselves inside the chroot due to being located outside. My thoughts on how to fix this are to chroot(), then fork and exec "getent passwd $user" and read the record in the parent process. The only problem then is how to split up that text record into a "struct passwd". I can see a libc routine for reading them from a FILE*, so perhaps we can read them directly from the child. Otherwise, we might need to write out a temporary file and read that. If you have any ideas about how to read a passwd entry inside the chroot, I would be very interested! Regards, Roger