[aur-general] shotwell...
Hello, shotwell is here: http://www.archlinux.org/packages/community/i686/shotwell/ and it's marked out of date. And shotwell also is here: http://aur.archlinux.org/packages.php?ID=48503 Here I don't know if it's up to date... But it uses git,.. can this just be rebuilt from git, even the package itsels is old? Also it confuses me that shotwell is on http://www.archlinux.org as well as http://aur.archlinux.org Can you explain me this? And: can the package maintainers be reminded to update? Shotwell 0.12.1 is out since a whiole and maybe even a newer verison (0.13.x) is underway... Ciao, Oliver
On Sun, 08 Apr 2012 18:13:24 +0200, oliver <oliver@first.in-berlin.de> wrote:
Also it confuses me that shotwell is on http://www.archlinux.org as well as http://aur.archlinux.org
You can put any package in the AUR as long as it doesn't use the exact same name as some package from the official repos. shotwell v. shotwell-git is fine. There are tons of such packages. There's usually just one version of a package in the official repos but the AUR can have multiple ones: -git, -light, -no-foo etc.
On 08/04/12 18:15, Karol Błażewicz wrote:
On Sun, 08 Apr 2012 18:13:24 +0200, oliver <oliver@first.in-berlin.de> wrote:
Also it confuses me that shotwell is on http://www.archlinux.org as well as http://aur.archlinux.org
You can put any package in the AUR as long as it doesn't use the exact same name as some package from the official repos. shotwell v. shotwell-git is fine.
There are tons of such packages. There's usually just one version of a package in the official repos but the AUR can have multiple ones: -git, -light, -no-foo etc.
Sergej is inactive atm, i will look into updating it -- Jelle van der Waa
On Sun, 08 Apr 2012 21:36:10 +0200, Jelle van der Waa <jelle@vdwaa.nl> wrote:
Sergej is inactive atm, i will look into updating it
Indeed he is http://mailman.archlinux.org/pipermail/aur-general/2012-March/018196.html but I don't see the status change https://wiki.archlinux.org/index.php/Trusted_Users#Inactive_Trusted_Users neither for him nor for Alexander Rødseth http://mailman.archlinux.org/pipermail/aur-general/2012-April/018382.html I know this wiki page is still used by some TUs. Sorry for off-topic / little ol' rant.
On Sun, Apr 08, 2012 at 09:36:10PM +0200, Jelle van der Waa wrote:
On 08/04/12 18:15, Karol Błażewicz wrote:
On Sun, 08 Apr 2012 18:13:24 +0200, oliver <oliver@first.in-berlin.de> wrote:
Also it confuses me that shotwell is on http://www.archlinux.org as well as http://aur.archlinux.org
You can put any package in the AUR as long as it doesn't use the exact same name as some package from the official repos. shotwell v. shotwell-git is fine.
There are tons of such packages. There's usually just one version of a package in the official repos but the AUR can have multiple ones: -git, -light, -no-foo etc.
Sergej is inactive atm, i will look into updating it [...]
Yes, would be fine to have a newer shotwell. When I tried to build shotwell from the AUR package http://aur.archlinux.org/packages.php?ID=48503 it tried to load "libgexiv2-git". But that package does not exist. There only is the package "libgexiv2-git 20110430-1". So either libgexiv2-git 20110430-1 must be used in the shotwell package, or maybe the "libgexiv2-git 20110430-1" will not work togehter with that shotwell version. Or maybe only "libgexiv2" should be given as dependency, which is avaialable via pacman. But I don't know if that version of "libgexiv2" might give problems. Any ideas on this? Or would you like to update the shotwell stuff soon? This would be fine. Ciao, Oliver
On Mon, Apr 09, 2012 at 03:53:27PM +0200, oliver wrote:
On Sun, Apr 08, 2012 at 09:36:10PM +0200, Jelle van der Waa wrote:
On 08/04/12 18:15, Karol Błażewicz wrote:
On Sun, 08 Apr 2012 18:13:24 +0200, oliver <oliver@first.in-berlin.de> wrote:
Also it confuses me that shotwell is on http://www.archlinux.org as well as http://aur.archlinux.org
You can put any package in the AUR as long as it doesn't use the exact same name as some package from the official repos. shotwell v. shotwell-git is fine.
There are tons of such packages. There's usually just one version of a package in the official repos but the AUR can have multiple ones: -git, -light, -no-foo etc.
Sergej is inactive atm, i will look into updating it [...]
Yes, would be fine to have a newer shotwell.
When I tried to build shotwell from the AUR package http://aur.archlinux.org/packages.php?ID=48503 it tried to load "libgexiv2-git". [...]
When I just change "libgexiv2-git" to "libgexiv2" in the dependency list, then again package build fails, because there is no vala >= 0.15.2. So, here are some more probllems... Ciao, Oliver
You should write that into the comments section of the package. oliver <oliver@first.in-berlin.de> wrote: On Mon, Apr 09, 2012 at 03:53:27PM +0200, oliver wrote:
On Sun, Apr 08, 2012 at 09:36:10PM +0200, Jelle van der Waa wrote:
On 08/04/12 18:15, Karol Błażewicz wrote:
On Sun, 08 Apr 2012 18:13:24 +0200, oliver <oliver@first.in-berlin.de> wrote:
Also it confuses me that shotwell is on http://www.archlinux.org as well as http://aur.archlinux.org
You can put any package in the AUR as long as it doesn't use the exact same name as some package from the official repos. shotwell v. shotwell-git is fine.
There are tons of such packages. There's usually just one version of a package in the official repos but the AUR can have multiple ones: -git, -light, -no-foo etc.
Sergej is inactive atm, i will look into updating it [...]
Yes, would be fine to have a newer shotwell.
When I tried to build shotwell from the AUR package http://aur.archlinux.org/packages.php?ID=48503 it tried to load "libgexiv2-git". [...]
When I just change "libgexiv2-git" to "libgexiv2" in the dependency list, then again package build fails, because there is no vala >= 0.15.2. So, here are some more probllems... Ciao, Oliver
On Mon, Apr 09, 2012 at 04:23:23PM +0200, Markus Unterwaditzer wrote:
You should write that into the comments section of the package. [...]
OK, yes, good idea. Done. Ciao, Oliver
On 09/04/12 16:53, oliver wrote:
On Mon, Apr 09, 2012 at 04:23:23PM +0200, Markus Unterwaditzer wrote:
You should write that into the comments section of the package. [...]
OK, yes, good idea.
Done.
Ciao, Oliver Shotwell requires vala > 0.15, we have vala 0.16 in [testing] so the new shotwell is now in [community-testing] along with the updated libgevix. As soon as vala will move, shotwell will move too.
-- Jelle van der Waa
On Mon, Apr 09, 2012 at 05:18:08PM +0200, Jelle van der Waa wrote:
On 09/04/12 16:53, oliver wrote:
On Mon, Apr 09, 2012 at 04:23:23PM +0200, Markus Unterwaditzer wrote:
You should write that into the comments section of the package. [...]
OK, yes, good idea.
Done.
Ciao, Oliver Shotwell requires vala > 0.15, we have vala 0.16 in [testing] so the new shotwell is now in [community-testing] along with the updated libgevix. As soon as vala will move, shotwell will move too. [...]
When I use http://aur.archlinux.org/packages.php?ID=31429 to create vala, it builds vala 0.16.0, but the package says it provides "vala=0.14.2". Not sure how such a PKGBUILD must be handled. If it says it provides "vala=0.14.2" but just downloads the current version via git, then the provides-entrx is not correct. It willö then provide always the newest version. How to handle this in a package? Is the PKGBUILD http://aur.archlinux.org/packages/va/vala-git/PKGBUILD correct, or not? Does a provides-entry make any sense, if there always is the current stuff that is downloaded? If the package PKGBUILD says, that it provides vala=0.14.2, then it should only clone the git sources for that certain vala version. So I rather think the PKGBUILD is wrong here. Are there general rules how to handle this correctly? Ciao, Oliver
On Mon, Apr 9, 2012 at 5:44 PM, oliver <oliver@first.in-berlin.de> wrote:
On Mon, Apr 09, 2012 at 05:18:08PM +0200, Jelle van der Waa wrote:
On 09/04/12 16:53, oliver wrote:
On Mon, Apr 09, 2012 at 04:23:23PM +0200, Markus Unterwaditzer wrote:
You should write that into the comments section of the package. [...]
OK, yes, good idea.
Done.
Ciao, Oliver Shotwell requires vala > 0.15, we have vala 0.16 in [testing] so the new shotwell is now in [community-testing] along with the updated libgevix. As soon as vala will move, shotwell will move too. [...]
When I use http://aur.archlinux.org/packages.php?ID=31429 to create vala, it builds vala 0.16.0, but the package says it provides "vala=0.14.2".
Not sure how such a PKGBUILD must be handled. If it says it provides "vala=0.14.2" but just downloads the current version via git, then the provides-entrx is not correct.
It willö then provide always the newest version.
How to handle this in a package? Is the PKGBUILD http://aur.archlinux.org/packages/va/vala-git/PKGBUILD correct, or not?
Does a provides-entry make any sense, if there always is the current stuff that is downloaded?
If the package PKGBUILD says, that it provides vala=0.14.2, then it should only clone the git sources for that certain vala version.
So I rather think the PKGBUILD is wrong here.
Are there general rules how to handle this correctly?
Ciao, Oliver
During package(), extract the current version from "configure" using something like _providesver="$(awk -F\' '/^PACKAGE_VERSION=/{print $2}' <configure)" provides=("vala=$_providesver")
On Mon, Apr 09, 2012 at 06:37:46PM +0200, Jan Steffens wrote:
On Mon, Apr 9, 2012 at 5:44 PM, oliver <oliver@first.in-berlin.de> wrote:
On Mon, Apr 09, 2012 at 05:18:08PM +0200, Jelle van der Waa wrote:
On 09/04/12 16:53, oliver wrote:
On Mon, Apr 09, 2012 at 04:23:23PM +0200, Markus Unterwaditzer wrote:
You should write that into the comments section of the package. [...]
OK, yes, good idea.
Done.
Ciao, Oliver Shotwell requires vala > 0.15, we have vala 0.16 in [testing] so the new shotwell is now in [community-testing] along with the updated libgevix. As soon as vala will move, shotwell will move too. [...]
When I use http://aur.archlinux.org/packages.php?ID=31429 to create vala, it builds vala 0.16.0, but the package says it provides "vala=0.14.2".
Not sure how such a PKGBUILD must be handled. If it says it provides "vala=0.14.2" but just downloads the current version via git, then the provides-entrx is not correct.
It willö then provide always the newest version.
How to handle this in a package? Is the PKGBUILD http://aur.archlinux.org/packages/va/vala-git/PKGBUILD correct, or not?
Does a provides-entry make any sense, if there always is the current stuff that is downloaded?
If the package PKGBUILD says, that it provides vala=0.14.2, then it should only clone the git sources for that certain vala version.
So I rather think the PKGBUILD is wrong here.
Are there general rules how to handle this correctly?
Ciao, Oliver
During package(), extract the current version from "configure" using something like _providesver="$(awk -F\' '/^PACKAGE_VERSION=/{print $2}' <configure)" provides=("vala=$_providesver")
Aha, nice. But then in AUR the package number could not be looked up before the package is built.... Do you see, what problem I address? Ciao, Oliver
On Mon, Apr 9, 2012 at 5:44 PM, oliver <oliver@first.in-berlin.de> wrote:
When I use http://aur.archlinux.org/packages.php?ID=31429 to create vala, it builds vala 0.16.0, but the package says it provides "vala=0.14.2".
Not sure how such a PKGBUILD must be handled. If it says it provides "vala=0.14.2" but just downloads the current version via git, then the provides-entrx is not correct.
It willö then provide always the newest version.
How to handle this in a package? Is the PKGBUILD http://aur.archlinux.org/packages/va/vala-git/PKGBUILD correct, or not?
Does a provides-entry make any sense, if there always is the current stuff that is downloaded?
If the package PKGBUILD says, that it provides vala=0.14.2, then it should only clone the git sources for that certain vala version.
So I rather think the PKGBUILD is wrong here.
This provides is wrong. I would put provides vala=0.18 and update it whenever upstream bump version. I think the current provides has been put to work "nicely" with packages having a dependency on specific vala version. Does not seem a good idea though, versionned dependencies are usually put there for a reason. -- Cédric Girard
participants (6)
-
Cédric Girard
-
Jan Steffens
-
Jelle van der Waa
-
Karol Błażewicz
-
Markus Unterwaditzer
-
oliver