Ebuild of net-ftp/vsftpd-2.3.4 fails when compiling the file sysdeputil.c at line 1334 with an undeclared reference to __NR_getpid.
Created attachment 303233 [details] emerge --info ... output
Created attachment 303235 [details] emerge -pqv ... output
Created attachment 303237 [details] Environment file
Created attachment 303239 [details] Build log
Not our problem. Seems like this syscall is missing from Alpha kernel headers. If I am correct, we need to drop the alpha keywords
alpha/~alpha keywords dropped
(In reply to comment #6) > alpha/~alpha keywords dropped I did an emerge-webrsync followed by an emerge vsftpd which resulted in a different failure early in the source compile (i.e., emake CFLAGS="${CFLAGS}" CC="$(tc-getCC)" || die fails). Is this related to this bug or should I open a new bug report?
(In reply to comment #7) > (In reply to comment #6) > > alpha/~alpha keywords dropped > > I did an emerge-webrsync followed by an emerge vsftpd which resulted in a > different failure early in the source compile (i.e., emake > CFLAGS="${CFLAGS}" CC="$(tc-getCC)" || die fails). Is this related to this > bug or should I open a new bug report? How should I know? I need a build.log to see what the problem is. If you think this is not related to this bug, please open a new one
Created attachment 308767 [details] Build log for new failure Here is the build log for the new build failure. I'm just a user, you are better equipped to evaluate whether this is related to the fix to the original failure. If you need additional information, just ask politely. If this is a new issue, just say so and I will submit a new, complete bug report.
It is the same problem sysdeputil.c:1334:18: error: '__NR_getpid' undeclared (first use in this function) sysdeputil.c:1334:18: note: each undeclared identifier is reported only once for each function it appears in However, this bug seems to be fixed in debian so it would be possible to use their patch
Could you please try this patch? http://patch-tracker.debian.org/patch/series/view/vsftpd/2.3.5-3/11-alpha.patch
(In reply to comment #11) > Could you please try this patch? > > http://patch-tracker.debian.org/patch/series/view/vsftpd/2.3.5-3/11-alpha. > patch I downloaded the patch but I don't know how to get it applied. I tried the user patch mechanism described in the installation documentation with no success. I tried to just add the patch file to the protage tree with the other patches but emerge complains about the extra file. How do I get the patch applied?
(In reply to comment #12) > (In reply to comment #11) > > Could you please try this patch? > > > > http://patch-tracker.debian.org/patch/series/view/vsftpd/2.3.5-3/11-alpha. > > patch > > I downloaded the patch but I don't know how to get it applied. I tried the > user patch mechanism described in the installation documentation with no > success. I tried to just add the patch file to the protage tree with the > other patches but emerge complains about the extra file. How do I get the > patch applied? Ehm, put that file in /usr/portage/net-ftp/vsftpd/files/ and adjust the vsftd-2.3.5.ebuild to apply this patch as well. Have a look at the ebuild to see how to apply patches.
(In reply to comment #13) > (In reply to comment #12) > > (In reply to comment #11) > > > Could you please try this patch? > > > > > > http://patch-tracker.debian.org/patch/series/view/vsftpd/2.3.5-3/11-alpha. > > > patch > > > > I downloaded the patch but I don't know how to get it applied. I tried the > > user patch mechanism described in the installation documentation with no > > success. I tried to just add the patch file to the protage tree with the > > other patches but emerge complains about the extra file. How do I get the > > patch applied? > > Ehm, put that file in /usr/portage/net-ftp/vsftpd/files/ and adjust the > vsftd-2.3.5.ebuild to apply this patch as well. Have a look at the ebuild to > see how to apply patches. I have done as instructed, but the emerge fails complaining that the ebuild file length does not match the expected length. How do I tell emerge to skip this and any other related consistency checks (like the presence of the extra new patch file)? I read the man page for emerge, but saw nothing that seemed applicable. If there is no way to make emerge ignore the checks, how can I rebuild whatever files (Manifest, etc.?) contain the information used in these checks?
(In reply to comment #14) > (In reply to comment #13) > > (In reply to comment #12) > > > (In reply to comment #11) > > > > Could you please try this patch? > > > > > > > > http://patch-tracker.debian.org/patch/series/view/vsftpd/2.3.5-3/11-alpha. > > > > patch > > > > > > I downloaded the patch but I don't know how to get it applied. I tried the > > > user patch mechanism described in the installation documentation with no > > > success. I tried to just add the patch file to the protage tree with the > > > other patches but emerge complains about the extra file. How do I get the > > > patch applied? > > > > Ehm, put that file in /usr/portage/net-ftp/vsftpd/files/ and adjust the > > vsftd-2.3.5.ebuild to apply this patch as well. Have a look at the ebuild to > > see how to apply patches. > > I have done as instructed, but the emerge fails complaining that the ebuild > file length does not match the expected length. How do I tell emerge to skip > this and any other related consistency checks (like the presence of the > extra new patch file)? I read the man page for emerge, but saw nothing that > seemed applicable. If there is no way to make emerge ignore the checks, how > can I rebuild whatever files (Manifest, etc.?) contain the information used > in these checks? "cd" to /usr/portage/net-ftp/vsftpd and run "repoman manifest". Then try to emerge vsftpd again
(In reply to comment #11) > Could you please try this patch? > > http://patch-tracker.debian.org/patch/series/view/vsftpd/2.3.5-3/11-alpha. > patch I applied the patch. The emerge now succeeds. The server runs, but does not allow connections. All connection requests produce the following response: 500 OOPS: not session leader I don't know if this is related to the patch (the problem had something to do getting the process ID and thus might be related to the patch) or is just a configuration problem. I am using a vsftpd.conf file that is essentially the same as that used on a debian installation where the server works fine. I will continue to try other things.
It seems plausible that alpha's getxpid syscall hasn't been kept in sync with the other architectures' recently. See http://marc.info/?l=linux-alpha&m=128547570428943&w=2 http://marc.info/?l=linux-alpha&m=128551378724908&w=2 http://marc.info/?l=linux-alpha&m=128551399625123&w=2 If you want, you can try applying those patches to your kernel. I'll ping the appropriate people upstream and see if we can get getxpid fixed. Thanks a lot for the report. It seems you've discovered a kernel bug. :)
I just tested vsftpd-2.3.5 with the patch from Debian (no kernel patches) and it seems to work. I at least can't reproduce the error the original reporter had.
Ping?
I'm not sure what comment 19 means. For my part, I concur the Debian bug fix solves the original build problem, but the running server still does not allow any connections (see comment 16). If you want me to file a separate bug report for this just let me know.
(In reply to comment #20) > I'm not sure what comment 19 means. For my part, I concur the Debian bug fix > solves the original build problem, but the running server still does not > allow any connections (see comment 16). If you want me to file a separate > bug report for this just let me know. Probably means that the patch is not correct. Have you tried any later version of vsftpd, say 3.0.2 (and the latest kernel)?
Please test the latest one along with the latest kernel headers and report back. Otherwise I will have to drop the alpha keywords because I need to get rid off all the 2.X releases
(In reply to comment #22) > Please test the latest one along with the latest kernel headers and report > back. Otherwise I will have to drop the alpha keywords because I need to get > rid off all the 2.X releases I am working on it. I am having trouble getting gdm to run under the latest version of the kernel--it doesn't accept any input (mouse or keyboard). I had this problem once before, but I don't remember all the details about how I finally fixed it. When I solve this problem I'll try the newest version of vsftpd.
Sounds like you updated your X server, but not your drivers. Rebuild your xf86-{input,video}-* packages.
(In reply to comment #24) > Sounds like you updated your X server, but not your drivers. Rebuild your > xf86-{input,video}-* packages. All I have done is build and boot the 3.3.8 kernel. Making no alterations at all (just the SRM boot command line) I can boot the 3.2.1 kernel and X runs just fine. I don't want to touch anything else, if at all possible, for fear of breaking the older version configuration (I still need to get daily work done on the machine) before getting the new version running. If I have to step off the cliff, I will, but I'm a bit nervous.
(In reply to comment #25) > (In reply to comment #24) > > Sounds like you updated your X server, but not your drivers. Rebuild your > > xf86-{input,video}-* packages. > > All I have done is build and boot the 3.3.8 kernel. In that case, diff the 3.3.8 .config with your previous .config. Perhaps evdev got turned off or something like that.
(In reply to comment #22) > Please test the latest one along with the latest kernel headers and report > back. Otherwise I will have to drop the alpha keywords because I need to get > rid off all the 2.X releases I have been able to build vsftpd-3.0.2 under 3.3.8 of the kernel and it seems to work. I did need to add the debian patch to get the build to succeed.
Right. Thanks. I am wondering why this bug is not fixed upstream then...
Thanks. Fixed on 3.0.2
