[pacman-dev] The real deal - pacman 3.0.0 RC1
Hey guys, We are really close to releasing pacman 3 to testing, but Aaron and I wanted to get you guys to do some serious testing for a few days before we do that. Both of us are now running pacman 3 exclusively, so have no fears. :) PLEASE read this first. This is no longer a side-by-side install, this will REPLACE pacman on your system. It is perfectly safe, but realize that you are upgrading, not simply installing another version. In addition, if you have pacman-rc installed currently, it is easiest to run a 'pacman -R pacman-rc' first to prevent weird things from happening. Here is the package: <http://www.archlinux.org/~dan/pacman/pacman-3.0.0-1-i686.pkg.tar.gz> And for those of you that want to build it on your own, I put the PKGBUILD and install file up as well. I recommend a bootstrap build- use your existing makepkg to build, upgrade, and then makepkg and upgrade again. However, you should have no problems along the way, so let us know of any. Here is that link: <http://www.archlinux.org/~dan/pacman/> Please report anything to us here on the list that you may find. We may not respond instantly but we will take a look at any possible bugs you guys point out. -Dan
On 3/4/07, Dan McGee <dpmcgee@gmail.com> wrote:
PLEASE read this first. This is no longer a side-by-side install, this will REPLACE pacman on your system. It is perfectly safe, but realize that you are upgrading, not simply installing another version. In addition, if you have pacman-rc installed currently, it is easiest to run a 'pacman -R pacman-rc' first to prevent weird things from happening. Here is the package: <http://www.archlinux.org/~dan/pacman/pacman-3.0.0-1-i686.pkg.tar.gz>
I cannot remember if upgrade requires the old style package name like sync did, but if the above link does not work directly for you, you may need to download the package, mv it to a name without the "-i686" part, and try again. Can someone let me know if this step needs to be done? I don't have pacman2 around to test anymore. -Dan
On Sun, 4 Mar 2007 14:50:21 -0500 "Dan McGee" <dpmcgee@gmail.com> wrote:
I cannot remember if upgrade requires the old style package name like sync did, but if the above link does not work directly for you, you may need to download the package, mv it to a name without the "-i686" part, and try again. Can someone let me know if this step needs to be done? I don't have pacman2 around to test anymore.
Update went just fine without removing the "-686" part. Alex
Am Sonntag, 4. März 2007 20:27:02 schrieb Dan McGee:
And for those of you that want to build it on your own, I put the PKGBUILD and install file up as well. I recommend a bootstrap build- use your existing makepkg to build, upgrade, and then makepkg and upgrade again. However, you should have no problems along the way, so let us know of any. Here is that link: <http://www.archlinux.org/~dan/pacman/>
You should add the following to set the correct tag on arch64: if [ "$CARCH" = "x86_64" ]; then sed -i "s|CURRENT|CURRENT-64|g" \ $startdir/pkg/etc/abs/supfile{arch,extra,community,unstable} sed -i "s|TESTING|TESTING-64|g" $startdir/pkg/etc/abs/supfile.testing fi In addition to this: is it right that chost ist set to "x86_64-unknown-linux-gnu" and not "x86_64-pc-linux-gnu" like on i686? -- http://www.archlinux.de
On 3/4/07, Pierre Schmitz <pierre@archlinux.de> wrote:
You should add the following to set the correct tag on arch64:
Done, thanks for that.
In addition to this: is it right that chost ist set to "x86_64-unknown-linux-gnu" and not "x86_64-pc-linux-gnu" like on i686?
This is the chost determined by configure, so I would guess it is right. However, I do not know much about how that works, so you may want to read up on it more if you think it is wrong. -Dan
Am Montag, 5. März 2007 00:34:15 schrieb Dan McGee:
This is the chost determined by configure, so I would guess it is right. However, I do not know much about how that works, so you may want to read up on it more if you think it is wrong.
Well, other distros are using x86_64-pc-linux-gnu (e.g.: http://gentoo-wiki.com/Safe_Cflags#Athlon_64_.28AMD.29) So I think the current chost is wrong. -- http://www.archlinux.de
On 3/5/07, Pierre Schmitz <pierre@archlinux.de> wrote:
Am Montag, 5. März 2007 00:34:15 schrieb Dan McGee:
This is the chost determined by configure, so I would guess it is right. However, I do not know much about how that works, so you may want to read up on it more if you think it is wrong.
Well, other distros are using x86_64-pc-linux-gnu (e.g.: http://gentoo-wiki.com/Safe_Cflags#Athlon_64_.28AMD.29) So I think the current chost is wrong.
No one is questioning what is correct. The problem is that the autotooled configure script is what generates this value. Not us. if you look at the configure.ac script, it does: CHOST="$host" The host variable comes from configure.
On 3/5/07, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On 3/5/07, Pierre Schmitz <pierre@archlinux.de> wrote:
Am Montag, 5. März 2007 00:34:15 schrieb Dan McGee:
This is the chost determined by configure, so I would guess it is right. However, I do not know much about how that works, so you may want to read up on it more if you think it is wrong.
Well, other distros are using x86_64-pc-linux-gnu (e.g.: http://gentoo-wiki.com/Safe_Cflags#Athlon_64_.28AMD.29) So I think the current chost is wrong.
No one is questioning what is correct. The problem is that the autotooled configure script is what generates this value. Not us. if you look at the configure.ac script, it does: CHOST="$host"
The host variable comes from configure.
If you have the time, please look into AC_CANONICAL_HOST, which is the standard for determining the host type. In addition, try downloading the most recent config.guess at <http://cvs.savannah.gnu.org/viewcvs/*checkout*/config/config/config.guess> and seeing what that produces for you. We may be using an outdated one pulled from somewhere on the system. -Dan
Am Montag, 5. März 2007 16:25:09 schrieb Dan McGee:
On 3/5/07, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On 3/5/07, Pierre Schmitz <pierre@archlinux.de> wrote:
Am Montag, 5. März 2007 00:34:15 schrieb Dan McGee:
This is the chost determined by configure, so I would guess it is right. However, I do not know much about how that works, so you may want to read up on it more if you think it is wrong.
Well, other distros are using x86_64-pc-linux-gnu (e.g.: http://gentoo-wiki.com/Safe_Cflags#Athlon_64_.28AMD.29) So I think the current chost is wrong.
No one is questioning what is correct. The problem is that the autotooled configure script is what generates this value. Not us. if you look at the configure.ac script, it does: CHOST="$host"
The host variable comes from configure.
yes, but i think this is initially hardcoded.
If you have the time, please look into AC_CANONICAL_HOST, which is the standard for determining the host type. In addition, try downloading the most recent config.guess at <http://cvs.savannah.gnu.org/viewcvs/*checkout*/config/config/config.guess> and seeing what that produces for you. We may be using an outdated one pulled from somewhere on the system.
-Dan
I talked to andyrtr about this and he said "unknown" was chosen because older versions of autotools could not hanlde "pc". I have looked into http://cvs.savannah.gnu.org/viewcvs/*checkout*/config/config/config.sub and there you`ll finde the following comment: # We use `pc' rather than `unknown' # because (1) that's what they normally are, and # (2) the word "unknown" tends to confuse beginning users. i*86 | x86_64) basic_machine=$basic_machine-pc ;; Well I do not know how important this chost variable is. ;-) But after some research I would say that "x86_64-pc-linux-gnu" would be corrent nowadays. And btw: do you know any x86_64 machine which is not a pc? -- http://www.archlinux.de
Well I do not know how important this chost variable is. ;-) But after some research I would say that "x86_64-pc-linux-gnu" would be corrent nowadays. And btw: do you know any x86_64 machine which is not a pc?
Is PC's definition personal computer? I know of some x86 boxes which aren't really "personal", but I think they're still called PCs. I think the x86 part of x86_64 therefore makes the same apply here. Yes, there are 64bit machines that aren't called PCs, but generally I think PC refers to Intel compatible machines. Dale
On 3/5/07, Pierre Schmitz <pierre@archlinux.de> wrote:
Am Montag, 5. März 2007 16:25:09 schrieb Dan McGee:
On 3/5/07, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On 3/5/07, Pierre Schmitz <pierre@archlinux.de> wrote:
Am Montag, 5. März 2007 00:34:15 schrieb Dan McGee:
This is the chost determined by configure, so I would guess it is right. However, I do not know much about how that works, so you may want to read up on it more if you think it is wrong.
Well, other distros are using x86_64-pc-linux-gnu (e.g.: http://gentoo-wiki.com/Safe_Cflags#Athlon_64_.28AMD.29) So I think the current chost is wrong.
No one is questioning what is correct. The problem is that the autotooled configure script is what generates this value. Not us. if you look at the configure.ac script, it does: CHOST="$host"
The host variable comes from configure.
yes, but i think this is initially hardcoded.
Hardcoded WHERE? You seem to be missing the point here. The reason I told you to look into this, and then did it for you, is that config.guess is the program that is generating the value of CHOST for us. We do not hardcode it anywhere. Sorry for sounding angry here, but the point is we have no control over it- it is your version of autotools/libtool, which we should try to ensure are updated if that is the case. If that doesn't work, then we will just include config.guess right in our repository.
If you have the time, please look into AC_CANONICAL_HOST, which is the standard for determining the host type. In addition, try downloading the most recent config.guess at <http://cvs.savannah.gnu.org/viewcvs/*checkout*/config/config/config.guess> and seeing what that produces for you. We may be using an outdated one pulled from somewhere on the system.
-Dan
I talked to andyrtr about this and he said "unknown" was chosen because older versions of autotools could not hanlde "pc". I have looked into http://cvs.savannah.gnu.org/viewcvs/*checkout*/config/config/config.sub and there you`ll finde the following comment:
# We use `pc' rather than `unknown' # because (1) that's what they normally are, and # (2) the word "unknown" tends to confuse beginning users. i*86 | x86_64) basic_machine=$basic_machine-pc ;;
Well I do not know how important this chost variable is. ;-) But after some research I would say that "x86_64-pc-linux-gnu" would be corrent nowadays. And btw: do you know any x86_64 machine which is not a pc?
config.sub is not used in this situation, unless you provide a --host=x86_64 flag (or something along those lines) on the command line. config.guess is used when no --host flag is provided. You can try doing this now and -pc- will probably be in there instead of -unknown-. This is really an issue that should be brought up on the autotools/autoconf ML, I'm sure someone there can answer this whole thing a lot quicker than we have been able to. -Dan
On 3/5/07, Pierre Schmitz <pierre@archlinux.de> wrote:
Am Montag, 5. März 2007 16:25:09 schrieb Dan McGee:
On 3/5/07, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On 3/5/07, Pierre Schmitz <pierre@archlinux.de> wrote:
Am Montag, 5. März 2007 00:34:15 schrieb Dan McGee:
This is the chost determined by configure, so I would guess it is right. However, I do not know much about how that works, so you may want to read up on it more if you think it is wrong.
Well, other distros are using x86_64-pc-linux-gnu (e.g.: http://gentoo-wiki.com/Safe_Cflags#Athlon_64_.28AMD.29) So I think the current chost is wrong.
No one is questioning what is correct. The problem is that the autotooled configure script is what generates this value. Not us. if you look at the configure.ac script, it does: CHOST="$host"
The host variable comes from configure.
Can you do a cvs update on the sources and try running ./config.guess in the root directory? We just added it to CVS, so we are not using a version from 2005 or earlier anymore. Make sure you are using the CVS copy and not one that was locally created (grep "^timestamp" config.guess, you should see a date in 2007). Let us know what this spits out. -Dan
Am Dienstag, 6. März 2007 17:33:49 schrieb Dan McGee: ...
Can you do a cvs update on the sources and try running ./config.guess in the root directory? We just added it to CVS, so we are not using a version from 2005 or earlier anymore. Make sure you are using the CVS copy and not one that was locally created (grep "^timestamp" config.guess, you should see a date in 2007). Let us know what this spits out.
-Dan
[pierre@athlon64 pacman-lib]$ ./config.guess x86_64-unknown-linux-gnu [pierre@athlon64 pacman-lib]$ grep "^timestamp" config.guess timestamp='2007-03-06' -- http://www.archlinux.de
On 3/5/07, Pierre Schmitz <pierre@archlinux.de> wrote:
Am Montag, 5. März 2007 00:34:15 schrieb Dan McGee:
This is the chost determined by configure, so I would guess it is right. However, I do not know much about how that works, so you may want to read up on it more if you think it is wrong.
Well, other distros are using x86_64-pc-linux-gnu (e.g.: http://gentoo-wiki.com/Safe_Cflags#Athlon_64_.28AMD.29) So I think the current chost is wrong.
OK, here is what I've found and learned about this whole thing. CLFS (Cross Linux From Scratch) recommends using the following build triplet for its builds, and I would assume they have thought this out fairly well: export CLFS_TARGET="x86_64-unknown-linux-gnu" AndyRTR also says that 'unknown' works much better than 'pc', which they were using in the early days of Arch64. Unless you are manually overriding this value in every other package you build, the chost with 'unknown' will be the same one used to build other packages. -Dan
Am Montag, 5. März 2007 00:34:15 schrieb Dan McGee:
You should add the following to set the correct tag on arch64:
Done, thanks for that.
Sorry, I missed the dot "." in "$startdir/pkg/etc/abs/supfile.{arch,extra,community,unstable}" ^ -- http://www.archlinux.de
Well, i thought it might be good testing this release candidate. Though, i think i found an error.... [n501931@n501931pc:~]$ sudo pacman -Syu :: Synchronisiere Paketdatenbanken... --09:51:40-- ftp://ftp.gigabit.nu/current/os/i686/current.db.tar.gz/current.db.tar.gz => `current.db.tar.gz.part' Auflösen des Hostnamen »proxyserver«.... internalip Verbindungsaufbau zu proxyserver|internalip|:8080... verbunden. Proxy Anforderung gesendet, warte auf Antwort... 404 Not Found 09:51:40 FEHLER 404: Not Found. I don't think the db path really is ftp://ftp.gigabit.nu/current/os/i686/current.db.tar.gz/current.db.tar.gz -> one time to often? I've replaced the proxy url ind ip, since it's the proxy of our company, and i don't think i should post internal ips into a public list. Kind regards, Georg On 3/5/07, Pierre Schmitz <pierre@archlinux.de> wrote:
Am Montag, 5. März 2007 00:34:15 schrieb Dan McGee:
You should add the following to set the correct tag on arch64:
Done, thanks for that.
Sorry, I missed the dot "." in "$startdir/pkg/etc/abs/supfile.{arch,extra,community,unstable}" ^
_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://www.archlinux.org/mailman/listinfo/pacman-dev
Before i forget about it, of course the same when downloading packages: :: Empfange Pakete von extra... --14:21:02-- ftp://ftp.gigabit.nu/extra/os/i686/rpmextract-0-1.pkg.tar.gz/rpmextract-0-1.pkg.tar.gz => `rpmextract-0-1.pkg.tar.gz.part' Auflösen des Hostnamen »proxy«.... proxyip Verbindungsaufbau zu proxy|proxyip|:8080... verbunden. Proxy Anforderung gesendet, warte auf Antwort... 404 Not Found 14:21:03 FEHLER 404: Not Found. On 3/5/07, Georg Grabler <ggrabler@gmail.com> wrote:
Well, i thought it might be good testing this release candidate. Though, i think i found an error....
[n501931@n501931pc:~]$ sudo pacman -Syu :: Synchronisiere Paketdatenbanken... --09:51:40-- ftp://ftp.gigabit.nu/current/os/i686/current.db.tar.gz/current.db.tar.gz => `current.db.tar.gz.part' Auflösen des Hostnamen »proxyserver«.... internalip Verbindungsaufbau zu proxyserver|internalip|:8080... verbunden. Proxy Anforderung gesendet, warte auf Antwort... 404 Not Found 09:51:40 FEHLER 404: Not Found.
I don't think the db path really is ftp://ftp.gigabit.nu/current/os/i686/current.db.tar.gz/current.db.tar.gz -> one time to often?
I've replaced the proxy url ind ip, since it's the proxy of our company, and i don't think i should post internal ips into a public list.
Kind regards, Georg
On 3/5/07, Pierre Schmitz <pierre@archlinux.de> wrote:
Am Montag, 5. März 2007 00:34:15 schrieb Dan McGee:
You should add the following to set the correct tag on arch64:
Done, thanks for that.
Sorry, I missed the dot "." in "$startdir/pkg/etc/abs/supfile.{arch,extra,community,unstable}" ^
_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://www.archlinux.org/mailman/listinfo/pacman-dev
On 3/5/07, Georg Grabler <ggrabler@gmail.com> wrote:
Well, i thought it might be good testing this release candidate. Though, i think i found an error....
[n501931@n501931pc:~]$ sudo pacman -Syu :: Synchronisiere Paketdatenbanken... --09:51:40-- ftp://ftp.gigabit.nu/current/os/i686/current.db.tar.gz/current.db.tar.gz => `current.db.tar.gz.part' Auflösen des Hostnamen »proxyserver«.... internalip Verbindungsaufbau zu proxyserver|internalip|:8080... verbunden. Proxy Anforderung gesendet, warte auf Antwort... 404 Not Found 09:51:40 FEHLER 404: Not Found.
I don't think the db path really is ftp://ftp.gigabit.nu/current/os/i686/current.db.tar.gz/current.db.tar.gz -> one time to often?
I've replaced the proxy url ind ip, since it's the proxy of our company, and i don't think i should post internal ips into a public list.
First off, it looks like you're using an XferCommand. pacman 3 has native proxy support, now, using the fairly standard ftp_proxy/http_proxy/*_proxy environment variables. Could you try with that? I'd like to pretty much stop people from using an XferCommand, as it's a little hackish. Still, I'll look into that one.
In this case yes, i do. But also when i disable the XferCommand, the files and dbs fail to download. Kind regards, Georg On 3/5/07, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On 3/5/07, Georg Grabler <ggrabler@gmail.com> wrote:
Well, i thought it might be good testing this release candidate. Though, i think i found an error....
[n501931@n501931pc:~]$ sudo pacman -Syu :: Synchronisiere Paketdatenbanken... --09:51:40-- ftp://ftp.gigabit.nu/current/os/i686/current.db.tar.gz/current.db.tar.gz => `current.db.tar.gz.part' Auflösen des Hostnamen »proxyserver«.... internalip Verbindungsaufbau zu proxyserver|internalip|:8080... verbunden. Proxy Anforderung gesendet, warte auf Antwort... 404 Not Found 09:51:40 FEHLER 404: Not Found.
I don't think the db path really is ftp://ftp.gigabit.nu/current/os/i686/current.db.tar.gz/current.db.tar.gz -> one time to often?
I've replaced the proxy url ind ip, since it's the proxy of our company, and i don't think i should post internal ips into a public list.
First off, it looks like you're using an XferCommand. pacman 3 has native proxy support, now, using the fairly standard ftp_proxy/http_proxy/*_proxy environment variables. Could you try with that? I'd like to pretty much stop people from using an XferCommand, as it's a little hackish. Still, I'll look into that one. _______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://www.archlinux.org/mailman/listinfo/pacman-dev
On 3/4/07, Dan McGee <dpmcgee@gmail.com> wrote:
Hey guys,
We are really close to releasing pacman 3 to testing, but Aaron and I wanted to get you guys to do some serious testing for a few days before we do that. Both of us are now running pacman 3 exclusively, so have no fears. :)
PLEASE read this first. This is no longer a side-by-side install, this will REPLACE pacman on your system. It is perfectly safe, but realize that you are upgrading, not simply installing another version. In addition, if you have pacman-rc installed currently, it is easiest to run a 'pacman -R pacman-rc' first to prevent weird things from happening. Here is the package: <http://www.archlinux.org/~dan/pacman/pacman-3.0.0-1-i686.pkg.tar.gz>
And for those of you that want to build it on your own, I put the PKGBUILD and install file up as well. I recommend a bootstrap build- use your existing makepkg to build, upgrade, and then makepkg and upgrade again. However, you should have no problems along the way, so let us know of any. Here is that link: <http://www.archlinux.org/~dan/pacman/>
Please report anything to us here on the list that you may find. We may not respond instantly but we will take a look at any possible bugs you guys point out.
-Dan
Just a note for package maintainers. Packages built with the new makepkg *should* be backwards compatible with the current repos. (vim-buftabs was just added to the repos, built with makepkg 3.0). Just make sure you rename the files and remove the -$ARCH at the end.
Am Montag, 5. März 2007 07:40:39 schrieb Aaron Griffin:
Just a note for package maintainers. Packages built with the new makepkg *should* be backwards compatible with the current repos. (vim-buftabs was just added to the repos, built with makepkg 3.0). Just make sure you rename the files and remove the -$ARCH at the end.
So you think it is safe to build (and distribute) our packages with pacman3? -- http://www.archlinux.de
On 3/4/07, Dan McGee <dpmcgee@gmail.com> wrote:
Hey guys,
We are really close to releasing pacman 3 to testing, but Aaron and I wanted to get you guys to do some serious testing for a few days before we do that. Both of us are now running pacman 3 exclusively, so have no fears. :)
PLEASE read this first. This is no longer a side-by-side install, this will REPLACE pacman on your system. It is perfectly safe, but realize that you are upgrading, not simply installing another version. In addition, if you have pacman-rc installed currently, it is easiest to run a 'pacman -R pacman-rc' first to prevent weird things from happening. Here is the package: <http://www.archlinux.org/~dan/pacman/pacman-3.0.0-1-i686.pkg.tar.gz>
And for those of you that want to build it on your own, I put the PKGBUILD and install file up as well. I recommend a bootstrap build- use your existing makepkg to build, upgrade, and then makepkg and upgrade again. However, you should have no problems along the way, so let us know of any. Here is that link: <http://www.archlinux.org/~dan/pacman/>
Please report anything to us here on the list that you may find. We may not respond instantly but we will take a look at any possible bugs you guys point out.
Ok, so we've been cranking away fixing the bugs that are reported. What I'm looking for now is a "works ok for me" or even "works except <bug I reported already>" type stuff. I'm really looking for an "OK" from the testers out there to push this stuff more to the public test (i.e. a real NEWS announcement). I also CC'd this mail to the arch-dev ML, as I have no idea if everyone is on the pacman-dev list. Please read the instructions from Dan.
Am Dienstag, 6. März 2007 17:03:29 schrieb Aaron Griffin:
Ok, so we've been cranking away fixing the bugs that are reported. What I'm looking for now is a "works ok for me" or even "works except <bug I reported already>" type stuff.
I'm really looking for an "OK" from the testers out there to push this stuff more to the public test (i.e. a real NEWS announcement).
I also CC'd this mail to the arch-dev ML, as I have no idea if everyone is on the pacman-dev list. Please read the instructions from Dan.
Till now it did not break anything; I am using it on two machnies now. But as usual: you`all allways find the big bugs after a release. ;-) -- http://www.archlinux.de
On Tue, 6 Mar 2007 10:03:29 -0600 "Aaron Griffin" <aaronmgriffin@gmail.com> wrote:
Ok, so we've been cranking away fixing the bugs that are reported. What I'm looking for now is a "works ok for me" or even "works except <bug I reported already>" type stuff.
I'm really looking for an "OK" from the testers out there to push this stuff more to the public test (i.e. a real NEWS announcement).
Works except for... something I haven't reported 'cause I just noticed, but fishy nonetheless: $ makepkg -c ==> Entering fakeroot environment ==> Making package: audacious-plugins 1.3.0-1 (Tue Mar 6 21:52:22 EST 2007) ==> Checking Runtime Dependencies... ==> Missing Dependencies: -> audacious-player>=1.3.0 -> libmpcdec>=1.2.5 ==> Checking Buildtime Dependencies... ==> ERROR: could not resolve all dependencies. -[travis@Cerebral]-[~/archlinux/extra/multimedia/audacious-plugins]- 09:52pm $ pacman -Q audacious-player audacious-player 1.3.0-1 -[travis@Cerebral]-[~/archlinux/extra/multimedia/audacious-plugins]- 09:52pm $ pacman -Q libmpcdec libmpcdec 1.2.5-1 -[travis@Cerebral]-[~/archlinux/extra/multimedia/audacious-plugins]- 09:52pm $ pacman -Q pacman pacman 3.0.0-1 I do indeed have the deps, as you can see. -- Travis
On 3/6/07, Travis Willard <travisw@wmpub.ca> wrote:
$ makepkg -c ==> Entering fakeroot environment ==> Making package: audacious-plugins 1.3.0-1 (Tue Mar 6 21:52:22 EST 2007) ==> Checking Runtime Dependencies...
==> Missing Dependencies: -> audacious-player>=1.3.0 -> libmpcdec>=1.2.5 ==> Checking Buildtime Dependencies... ==> ERROR: could not resolve all dependencies. -[travis@Cerebral]-[~/archlinux/extra/multimedia/audacious-plugins]- 09:52pm $ pacman -Q audacious-player audacious-player 1.3.0-1 -[travis@Cerebral]-[~/archlinux/extra/multimedia/audacious-plugins]- 09:52pm $ pacman -Q libmpcdec libmpcdec 1.2.5-1 -[travis@Cerebral]-[~/archlinux/extra/multimedia/audacious-plugins]- 09:52pm $ pacman -Q pacman pacman 3.0.0-1
I do indeed have the deps, as you can see.
This should be fixed in CVS. The deptesting wasn't splitting the comparators out, so "foo>=1.2" was taken literally. That is, you don't have a package named "foo>=1.2" installed. 8) Expect this fixed when the next push comes around.
On 3/4/07, Dan McGee <dpmcgee@gmail.com> wrote:
Hey guys,
We are really close to releasing pacman 3 to testing, but Aaron and I wanted to get you guys to do some serious testing for a few days before we do that. Both of us are now running pacman 3 exclusively, so have no fears. :)
PLEASE read this first. This is no longer a side-by-side install, this will REPLACE pacman on your system. It is perfectly safe, but realize that you are upgrading, not simply installing another version. In addition, if you have pacman-rc installed currently, it is easiest to run a 'pacman -R pacman-rc' first to prevent weird things from happening. Here is the package: <http://www.archlinux.org/~dan/pacman/pacman-3.0.0-1-i686.pkg.tar.gz>
And for those of you that want to build it on your own, I put the PKGBUILD and install file up as well. I recommend a bootstrap build- use your existing makepkg to build, upgrade, and then makepkg and upgrade again. However, you should have no problems along the way, so let us know of any. Here is that link: <http://www.archlinux.org/~dan/pacman/>
Please report anything to us here on the list that you may find. We may not respond instantly but we will take a look at any possible bugs you guys point out.
-Dan
Anyone here have anything to say about pacman3? Maybe even a "great job guys, I've had no problems at all?" Even you list-lurkers out there, feel free to speak up. We'd really like to get all the input we can so we are not scared as hell when we push it to testing and current soon after. -Dan
Em Quarta 07 Março 2007, Dan McGee escreveu:
On 3/4/07, Dan McGee <dpmcgee@gmail.com> wrote:
Hey guys,
We are really close to releasing pacman 3 to testing, but Aaron and I wanted to get you guys to do some serious testing for a few days before we do that. Both of us are now running pacman 3 exclusively, so have no fears. :)
PLEASE read this first. This is no longer a side-by-side install, this will REPLACE pacman on your system. It is perfectly safe, but realize that you are upgrading, not simply installing another version. In addition, if you have pacman-rc installed currently, it is easiest to run a 'pacman -R pacman-rc' first to prevent weird things from happening. Here is the package: <http://www.archlinux.org/~dan/pacman/pacman-3.0.0-1-i686.pkg.tar.gz>
And for those of you that want to build it on your own, I put the PKGBUILD and install file up as well. I recommend a bootstrap build- use your existing makepkg to build, upgrade, and then makepkg and upgrade again. However, you should have no problems along the way, so let us know of any. Here is that link: <http://www.archlinux.org/~dan/pacman/>
Please report anything to us here on the list that you may find. We may not respond instantly but we will take a look at any possible bugs you guys point out.
-Dan
Anyone here have anything to say about pacman3? Maybe even a "great job guys, I've had no problems at all?" Even you list-lurkers out there, feel free to speak up. We'd really like to get all the input we can so we are not scared as hell when we push it to testing and current soon after.
Hi Dan, It is everything great, except for: * I tried to install kdemod and pacman3 gave me a segfault. (Sorry cant see a way to replicate) * In this same installation, pacman3 is saying that there are file conflicts and pacman2 just replaces the files. (Sorry, i cant explain exactly the problem... The best way to see it, is a kde user try to install kdemod with pacman3) Except for that, im not having major problems.
-Dan
_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://www.archlinux.org/mailman/listinfo/pacman-dev
2007/3/7, Dan McGee <dpmcgee@gmail.com>:
On 3/4/07, Dan McGee <dpmcgee@gmail.com> wrote:
Hey guys,
We are really close to releasing pacman 3 to testing, but Aaron and I wanted to get you guys to do some serious testing for a few days before we do that. Both of us are now running pacman 3 exclusively, so have no fears. :)
PLEASE read this first. This is no longer a side-by-side install, this will REPLACE pacman on your system. It is perfectly safe, but realize that you are upgrading, not simply installing another version. In addition, if you have pacman-rc installed currently, it is easiest to run a 'pacman -R pacman-rc' first to prevent weird things from happening. Here is the package: <http://www.archlinux.org/~dan/pacman/pacman-3.0.0-1-i686.pkg.tar.gz>
And for those of you that want to build it on your own, I put the PKGBUILD and install file up as well. I recommend a bootstrap build- use your existing makepkg to build, upgrade, and then makepkg and upgrade again. However, you should have no problems along the way, so let us know of any. Here is that link: <http://www.archlinux.org/~dan/pacman/>
Please report anything to us here on the list that you may find. We may not respond instantly but we will take a look at any possible bugs you guys point out.
-Dan
Anyone here have anything to say about pacman3? Maybe even a "great job guys, I've had no problems at all?" Even you list-lurkers out there, feel free to speak up. We'd really like to get all the input we can so we are not scared as hell when we push it to testing and current soon after.
Sorry, Dan. I didn't test it since my departure and wasn't able to get back to Arch things yet. :-( I can only say I haven't seen significant issues with the latest build I used, and all of them are fixed now (according to CVS). GREAT WORK, guys! Hope to see Pacman 3.0 final on Voodoo 0.8 final! ;-) P.S.: What about that dependency bug in makepkg reported by Travis? -- Roman Kyrylych (Роман Кирилич)
On Wed, 7 Mar 2007 20:56:24 +0200 "Roman Kyrylych" <roman.kyrylych@gmail.com> wrote:
P.S.: What about that dependency bug in makepkg reported by Travis?
Seems to be fixed in CVS. ;) -- Travis
On Wed, 07 Mar 2007 19:20:20 +0200, Dan McGee <dpmcgee@gmail.com> wrote:
Anyone here have anything to say about pacman3?
It works. Haven't seen any problems. Just for kicks, I ran it through valgrind's memory checker with few options (like -Suy, -Ss, -Qi). Didn't see any leaks. Perhaps someone in the team did that already, or that you're too good to make such silly mistakes :P Great job, guys :) --vk
On 3/7/07, Vesa Kaihlavirta <vegai@iki.fi> wrote:
On Wed, 07 Mar 2007 19:20:20 +0200, Dan McGee <dpmcgee@gmail.com> wrote: Just for kicks, I ran it through valgrind's memory checker with few options (like -Suy, -Ss, -Qi). Didn't see any leaks. Perhaps someone in the team did that already, or that you're too good to make such silly mistakes :P
Yeah, actually, I think I leaked a total of 22 bytes somewhere on a full -S operation...
On Wed, 7 Mar 2007 12:20:20 -0500 "Dan McGee" <dpmcgee@gmail.com> wrote:
Anyone here have anything to say about pacman3? Maybe even a "great job guys, I've had no problems at all?" Even you list-lurkers out there, feel free to speak up. We'd really like to get all the input we can so we are not scared as hell when we push it to testing and current soon after.
It's working fine here. Two small things I have noticed: $ pacman -V ... Copyright (C) 2002-2006 Judd Vinet <jvinet@zeroflux.org> ... -> 2006 should be changed to 2007 $ pacman -h ... pacman {-R --remove} [options] <package> pacman {-S --sync} [options] [package] ... -> inconsistent use of brackets around package Alex
Am Mittwoch, 7. März 2007 21:02:39 schrieb Alexander Fehr:
$ pacman -h ... pacman {-R --remove} [options] <package> pacman {-S --sync} [options] [package] ... -> inconsistent use of brackets around package
No, because [..] indicates that the parameter is optional. -- http://www.archlinux.de
On Wed, 7 Mar 2007 21:07:12 +0100 Pierre Schmitz <pierre@archlinux.de> wrote:
Am Mittwoch, 7. März 2007 21:02:39 schrieb Alexander Fehr:
$ pacman -h ... pacman {-R --remove} [options] <package> pacman {-S --sync} [options] [package] ... -> inconsistent use of brackets around package
No, because [..] indicates that the parameter is optional.
You are right. Next time I should thing more about it. Alex
On 3/7/07, Alexander Fehr <pizzapunk@gmail.com> wrote:
It's working fine here. Two small things I have noticed:
$ pacman -V ... Copyright (C) 2002-2006 Judd Vinet <jvinet@zeroflux.org> ... -> 2006 should be changed to 2007
Fixed in CVS, thanks
On Sun, 4 Mar 2007 14:27:02 -0500 "Dan McGee" <dpmcgee@gmail.com> wrote:
Please report anything to us here on the list that you may find. We may not respond instantly but we will take a look at any possible bugs you guys point out.
Something odd going on with depends checking. Logfile attached - basically multiple depends entries are getting put in there for the same package. -- Travis
On Sun, 4 Mar 2007 14:27:02 -0500 "Dan McGee" <dpmcgee@gmail.com> wrote:
Please report anything to us here on the list that you may find. We may not respond instantly but we will take a look at any possible bugs you guys point out.
Something odd going on with depends checking. Logfile attached - basically multiple depends entries are getting put in there for the same package.
-- Travis
Uhhhh, yes. This seems to be a new bug (from dates of the broken depends files). Some of them contains an entry 5 times...
The bug is in package.c/_alpm_pkg_update_requiredby: if(strcmp(dep->name, alpm_pkg_get_name(pkg)) == 0) { _alpm_log(PM_LOG_DEBUG, _("adding '%s' in requiredby field for '%s'"), cachepkg->name, pkg->name); alpm_list_t *reqs = alpm_pkg_get_requiredby(pkg); reqs = alpm_list_add(reqs, strdup(alpm_pkg_get_name(cachepkg))); pkg->requiredby = reqs; } So we don't check if that packagename which we add is in reqs or not. An other (much smaller) bug I realized, that in this function we don't check before adding foo to REQUIREDBY of pkg that pkg really satisfies foo's dependency, just checks if foo's dependency name is pkg. However we can break dependencies by -d switch, so absolutely not guaranteed that pkg is needed by foo. I think REQUIREDBY means by definition that pkg satisfies one of foo's dependencies and we don't ensure about this. Bye, Nagy Gabor
Hi! And the same for _alpm_trans_update_depends <- this is the main problem, because _alpm_pkg_update_requiredby is called for empty packages as I see (but it should be fixed too...) Bye
On 3/11/07, Nagy Gabor <ngaba@petra.hos.u-szeged.hu> wrote:
Hi! And the same for _alpm_trans_update_depends <- this is the main problem, because _alpm_pkg_update_requiredby is called for empty packages as I see (but it should be fixed too...) Bye
Why on earth is this stuff done in multiple places? I'm trying to fix the problem but noticing there is a much bigger problem. /me ponders -Dan
On 3/11/07, Nagy Gabor <ngaba@petra.hos.u-szeged.hu> wrote:
The bug is in package.c/_alpm_pkg_update_requiredby:
if(strcmp(dep->name, alpm_pkg_get_name(pkg)) == 0) { _alpm_log(PM_LOG_DEBUG, _("adding '%s' in requiredby field for '%s'"), cachepkg->name, pkg->name); alpm_list_t *reqs = alpm_pkg_get_requiredby(pkg); reqs = alpm_list_add(reqs, strdup(alpm_pkg_get_name(cachepkg))); pkg->requiredby = reqs; }
So we don't check if that packagename which we add is in reqs or not.
An other (much smaller) bug I realized, that in this function we don't check before adding foo to REQUIREDBY of pkg that pkg really satisfies foo's dependency, just checks if foo's dependency name is pkg. However we can break dependencies by -d switch, so absolutely not guaranteed that pkg is needed by foo. I think REQUIREDBY means by definition that pkg satisfies one of foo's dependencies and we don't ensure about this.
Bye, Nagy Gabor
Hopefully the easy part of this is now fixed in CVS. Of course, while fixing it I found perhaps another big issue, and I haven't really looked over what Nagy said above yet. -Dan
On Mon, 12 Mar 2007 00:48:41 -0400 "Dan McGee" <dpmcgee@gmail.com> wrote:
Hopefully the easy part of this is now fixed in CVS. Of course, while fixing it I found perhaps another big issue, and I haven't really looked over what Nagy said above yet.
In the meantime, what would you suggest to fix our local db's? I suppose it's not critical, but it is kind of annoying to see the same thing appearing in depends many times over. -- Travis
On 3/12/07, Travis Willard <travisw@wmpub.ca> wrote:
In the meantime, what would you suggest to fix our local db's? I suppose it's not critical, but it is kind of annoying to see the same thing appearing in depends many times over.
A remove-then-add seemed to fix all the issues I had in mine (I had the same flac/audicious-plugins duplicates). -Dan
participants (11)
-
Aaron Griffin
-
Alexander Fehr
-
Dale Blount
-
Dan McGee
-
Douglas Soares de Andrade
-
Georg Grabler
-
Nagy Gabor
-
Pierre Schmitz
-
Roman Kyrylych
-
Travis Willard
-
Vesa Kaihlavirta