You are not logged in.
Pages: 1
OK, I've successfully reinstalled, this time without producing an "updating module dependencies" failure message and all this with the stock, unedited /etc/rc.sysinit! I build everything in, no modules. So we're up and running, this time having added nano (my favorite editor) and wget to the base packages. I next ran pacman -Syu then the following to set up a base system source rebuild:
pacman -S cvsup
abs
mkdir /home/sourcepackages
cd /usr/abs
makeworld -bc /home/sourcepackages base
As the various builds went ahead I noticed that one of them, bin86, produced an error 404. Does this error refer to a incorrect url?
jlowell
Offline
a while ago when i tried a makeworld i had problems getting the source for a lot of packages. if you download the source and put it in the correct dir in abs then you can use that instead of having makepkg wget (or just edit the PKGBUILD to point to a good url)
Nkawtg...n!
Offline
So Error 404 does relate to a bad url?
Yes, editing PKGBUILD seems the easiest. Locating a correct url is simple enough. I noticed first time around the makeworld wasn't able to build about ten of the base packages. I'm not sure of the reason in each case, however.
jlowell
Offline
check /usr/abs/makepkg.log
Nkawtg...n!
Offline
yeah sounds like a bum url to me. you can use freshmeat to find the correct path. if it indeed ends out being a faulty url please submit a bug so it may be corrected ASAP (and that goes for any bum url).
FWIW i have been noticing alot of url changes for package source these days in packages i maintain. in the winter months they were rare but this summer there have been quite a few. i expect this will change when summer ends.
AKA uknowme
I am not your friend
Offline
Hi Sarah!
I just finished makeworld -bc /home/sourcepackages base. Looking at /usr/abs/makepkg.log at Jagged's suggestion, it would seem that 11 packages went off the rails, 7 of which because they didn't download and 4 of which because of build failures which the log doesn't identify. Two other packages weren't attempted although they are legitimate base packages, lilo & jfsutils.
I'll look up the correct urls for the 7 packages that need them and submit a report. If there's a more detailed compile log that will give more insight into the 4 that failed, I'll submit bug reports on them too but I'll need to know what to look for to be helpful. As to the packages that weren't requested at all, I'll try them individually.
Out of curiosity how long after a report would it typically take for a url change to be made in an ABS package?
jlowell
Offline
you could do a makepkg on the 4 that failed with the following tacked on:
> out.log 2> out.err to log output. you can then grep -C 6 -E "Err|err" out.log and out.err
this will grep and print 6 lines of context for each instance of Err or err found
Nkawtg...n!
Offline
Also, before submitting bug reports, check the bug tracker. For your problems check
[url]http://www.archlinux.org/phpbt/query.php?op=doquery&status[]=3[/url]
and most specifically ...
Offline
OK, I'd like to clarify some things, this being my first attempt to get a mass "fix" done so as to make a success of my attempt to use makeworld for what amounts to a source rebuild of my base system.
I've reported two bugs so far, dhcpcd and groff, which PKGBUILD couldn't complete because the urls on the source line were inaccurate, ineffective or otherwise unusable. In these cases I've gotten and reported working urls and have done the editing, and made and installed the packages. There are some others, however, that raise questions. For example, sed, shadow, libtool, have very recent versions available but not quite as advanced as our base binary package. If I look for code for sed-4.0.7-1 the closest I can get is sed-4.0.7. All of which begs the question how in heavens name did Arch make a binary package sed-4.0.7-1 available if the source code for it was not made available at the same time. In cases like this abs will forever be ahead of itself and condemn makeworld to offering an incomplete result. Is that not true or is there something I don't understand here?
jlowell
Offline
the "-1" at the end of sed is arch's relation number. for example if there was an error in the original build the next build would be numbered 4.0.7-2 thus differentiating it from the first package when you sync with the arch package database. sed would then be updated because it's "version" has changed.
AKA uknowme
I am not your friend
Offline
Sarah,
So this number is not a real version change, its simply a mechanism to trigger an update? My goodness, I certainly have misunderstood this. I thought it was a revision number of some kind.
jlowell
Offline
well it is a revision number arch linux wise but not as to the actual source.
take j2sdk for example the actual version is 1.4.1 but i, and others have made revision to the arch package five time now. thus the "-5" at the end.
occasionally the source version may have a dash in it such as some.verison.0-pre1, but dashes in the version line are not accepted by makepkg so we usually have to make minor PKGBUILD changes so that we can drop the dash.
so the arch revision/relation number serves two purposes: to notify the user of an arch linux revision and provide a means of "automatically" upgrading a package.
hth
AKA uknowme
I am not your friend
Offline
Pages: 1