[pacman-dev] x86-64 builds?
I know we have been making a lot of changes recently, and I don't know if anyone on the 64-bit side has built and tested pacman3 in a while. Anyone on this list using 64-bit? -Dan
Am Freitag, 2. Februar 2007 18:59:14 schrieb Dan McGee:
I know we have been making a lot of changes recently, and I don't know if anyone on the 64-bit side has built and tested pacman3 in a while. Anyone on this list using 64-bit?
I coulkd test it on Arch64. There are two problems with your PKGBUILD: * You should do an anonymous cvs-checkout * It wants to overwrite the man-pages of the current pacman-version: error: the following file conflicts were found: pacman-rc: /usr/man/man8/makepkg.8.gz: exists in filesystem pacman-rc: /usr/man/man8/pacman.8.gz: exists in filesystem -- http://www.archlinux.de
On 2/3/07, Pierre Schmitz <pierre@archlinux.de> wrote:
Am Freitag, 2. Februar 2007 18:59:14 schrieb Dan McGee:
I know we have been making a lot of changes recently, and I don't know if anyone on the 64-bit side has built and tested pacman3 in a while. Anyone on this list using 64-bit?
I coulkd test it on Arch64. There are two problems with your PKGBUILD: * You should do an anonymous cvs-checkout * It wants to overwrite the man-pages of the current pacman-version:
error: the following file conflicts were found: pacman-rc: /usr/man/man8/makepkg.8.gz: exists in filesystem pacman-rc: /usr/man/man8/pacman.8.gz: exists in filesystem
That would be nice, thanks. That PKGBUILD up there was more than anything just put there by Aaron so other people could see how it was built. The anonymous thing is an easy fix; the man pages I didn't find so important so I just deleted the originals. At some point we are going to have pacman replace pacman anyway, so the PKGBUILD doesn't need to be rock solid. -Dan
On 2/3/07, Dan McGee <dpmcgee@gmail.com> wrote:
That PKGBUILD up there was more than anything just put there by Aaron so other people could see how it was built. The anonymous thing is an easy fix; the man pages I didn't find so important so I just deleted the originals. At some point we are going to have pacman replace pacman anyway, so the PKGBUILD doesn't need to be rock solid.
Yeah, the PKGBUILD is really there because I went through the process of trying to move everything to a *3 version to allow side-by-side tests, and didn't want everyone else to do the same.
Am Samstag, 3. Februar 2007 16:10:12 schrieb Dan McGee:
That would be nice, thanks.
OK, I just compiled it and it seems to work on Arch64. Are there any special test-cases I should try out? Is it save to install and remove packages on a "productive" system? Are there any big changes to makepkg and co or are they still the same (and I do not need testing them)? -- http://www.archlinux.de
On 2/6/07, Pierre Schmitz <pierre@archlinux.de> wrote:
Am Samstag, 3. Februar 2007 16:10:12 schrieb Dan McGee:
That would be nice, thanks.
OK, I just compiled it and it seems to work on Arch64. Are there any special test-cases I should try out? Is it save to install and remove packages on a "productive" system?
I've had no problems. The worst that has happened is a segfault, but never any DB corruption. It is getting more stable by the day.
Are there any big changes to makepkg and co or are they still the same (and I do not need testing them)?
They have changed quite a bit; however, nothing there SHOULD be architecture dependent. You will notice that all PKGBUILDs now require a arch=() array, which right now could contain i686 and/or x86_64. The configuration file for makpkg.conf has also changed. In our actual release, we will find a way to notify users of changes like this.
2007/2/6, Dan McGee <dpmcgee@gmail.com>:
On 2/6/07, Pierre Schmitz <pierre@archlinux.de> wrote:
Am Samstag, 3. Februar 2007 16:10:12 schrieb Dan McGee:
That would be nice, thanks.
OK, I just compiled it and it seems to work on Arch64. Are there any special test-cases I should try out? Is it save to install and remove packages on a "productive" system?
I've had no problems. The worst that has happened is a segfault, but never any DB corruption. It is getting more stable by the day.
Are there any big changes to makepkg and co or are they still the same (and I do not need testing them)?
They have changed quite a bit; however, nothing there SHOULD be architecture dependent. You will notice that all PKGBUILDs now require a arch=() array, which right now could contain i686 and/or x86_64. The configuration file for makpkg.conf has also changed. In our actual release, we will find a way to notify users of changes like this.
Also note that all packages generated with new makepkg have -i686/-x86_64 suffix, so you cannot use old gensync and pacman 2 to install them via your local repo. -- Roman Kyrylych (Роман Кирилич)
On 2/6/07, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
Also note that all packages generated with new makepkg have -i686/-x86_64 suffix, so you cannot use old gensync and pacman 2 to install them via your local repo.
However, you can still use makepkg3 and rename the file without the -ARCH extension, and pacman2 will still install them fine. I wouldn't recommend this course of action on the official repos though.
I know we have been making a lot of changes recently, and I don't know if anyone on the 64-bit side has built and tested pacman3 in a while. Anyone on this list using 64-bit?
-Dan
I'm reading here but don't have much time for playing with it these days. Tell me when the true testing begins so I can switch over using it for daily pkg building. Two small questions: 1) Do you recommend or is it required to mark the arch with "" around as Jan is adding it always - arch=("i686") or simply arch=(i686)? 2) Will we get an option to makepkg.conf to set the desired compression gz/bz2 (+ compression level?). I still think it would make sense to use bzip though it eats more cpu time. AndyRTR
On 2/11/07, Andreas Radke <a.radke@arcor.de> wrote:
I'm reading here but don't have much time for playing with it these days. Tell me when the true testing begins so I can switch over using it for daily pkg building.
Two small questions:
1) Do you recommend or is it required to mark the arch with "" around as Jan is adding it always - arch=("i686") or simply arch=(i686)?
Either works, first of all. But in our documentation we are trying to be pretty consistent with saying arch=('i686').
2) Will we get an option to makepkg.conf to set the desired compression gz/bz2 (+ compression level?). I still think it would make sense to use bzip though it eats more cpu time.
With 3.0, not yet. However, this is quite doable, and it is probably worth implementing even if we don't switch the default. -Dan
On 2/11/07, Andreas Radke <a.radke@arcor.de> wrote:
2) Will we get an option to makepkg.conf to set the desired compression gz/bz2 (+ compression level?). I still think it would make sense to use bzip though it eats more cpu time.
Just a side note. Even if this IS configurable, I don't really think that one architecture should have different compression than another. At this point in time, i686 uses gzip, so other architectures should use the same. A change here should be global, not local to one section.
participants (5)
-
Aaron Griffin
-
Andreas Radke
-
Dan McGee
-
Pierre Schmitz
-
Roman Kyrylych