[aur-general] please add -depth 1 to makepkg git clone
1. save bandwidth 2. less wait why not add --depth 1 :)
Re: [aur-general] please add -depth 1 to makepkg git clone
Date: Thu, 4 Apr 2013 23:12:29 -0700 From: tailin...@gmail.com To: aur-general@archlinux.org Subject: [aur-general] please add -depth 1 to makepkg git clone 1. save bandwidth 2. less wait why not add --depth 1 :) Please don't, it will screw up just about every method of updating pkgver.
Re: [aur-general] please add -depth 1 to makepkg git clone
On Fri, Apr 5, 2013 at 2:12 AM, Tai-Lin Chu tailin...@gmail.com wrote: 1. save bandwidth 2. less wait why not add --depth 1 :) If you're using a git package, I assume you're updating it at some frequency and you only have a full clone on the first build.
Re: [aur-general] please add -depth 1 to makepkg git clone
you mean pkgver()? On Thu, Apr 4, 2013 at 11:14 PM, Daniel Micay danielmi...@gmail.com wrote: On Fri, Apr 5, 2013 at 2:12 AM, Tai-Lin Chu tailin...@gmail.com wrote: 1. save bandwidth 2. less wait why not add --depth 1 :) If you're using a git package, I assume you're updating it at some frequency and you only have a full clone on the first build.
Re: [aur-general] please add -depth 1 to makepkg git clone
if add --depth 1, please set to option enable or disable it 2013/4/5 Tai-Lin Chu tailin...@gmail.com: you mean pkgver()? On Thu, Apr 4, 2013 at 11:14 PM, Daniel Micay danielmi...@gmail.com wrote: On Fri, Apr 5, 2013 at 2:12 AM, Tai-Lin Chu tailin...@gmail.com wrote: 1. save bandwidth 2. less wait why not add --depth 1 :) If you're using a git package, I assume you're updating it at some frequency and you only have a full clone on the first build.
Re: [aur-general] pacman 4.1 (makepkg 4.1) bazaar pkgver autobump problem
Am 04.04.2013 20:34, schrieb Maxime GAUDUIN:
On Thu, Apr 4, 2013 at 8:07 PM, Stefan Husmann
stefan-husm...@t-online.dewrote:
Am 04.04.2013 16:06, schrieb Alucryd:
On Thu, 2013-04-04 at 09:52 -0400, Daniel Wallace wrote:
Gary van der Merwe gary...@gmail.com wrote:
On Thu 04 Apr 2013 15:41:27 SAST, Alucryd wrote:
On Thu, 2013-04-04 at 15:26 +0200, Gary van der Merwe wrote:
Hi all.
I'm the one wrote the Bazaar makepkg support, so any bugs are my
fault.
On 04/04/2013 10:24, Stefan Husmann wrote:
== Retrieving sources...
- Branching
http://bzr.savannah.gnu.org/r/**emacs/xwidgethttp://bzr.savannah.gnu.org/r/emacs/xwidget
...
bzr: ERROR: No such file:
u'/home/haawda/paketierung/**maintained_by_me/emacs-**
xwidget-bzr/4.1/xwidget/.bzr':
[Errno 20]
Not a directory:
'/home/haawda/paketierung/**maintained_by_me/emacs-**
xwidget-bzr/4.1/xwidget/.bzr'
== ERROR: Failure while branching
http://bzr.savannah.gnu.org/r/**emacs/xwidgethttp://bzr.savannah.gnu.org/r/emacs/xwidget
Aborting...
This error has happened before pkgver is reached, and so the problem
is
not with your pkgver function.
I'm busy running makepkg on your PKGBUILD to see if I reproduce the
error.
pkgver() {
bzr version-info $srcdir/$_bzrmod | awk '/revno:/ {print $2}'
}
An easier way to do this is by using bzr version-info's built in
templating:
pkgver() {
bzr version-info $srcdir/$_bzrmod --custom
--template={revno}\n
}
(see `bzr help version-info` for a list of fields you can use)
On 04/04/2013 15:04, Alucryd wrote:
FYI, I've settled with this for my bzr PKGBUILDs [1]. Only problem
is, this works well when first installing the package (even the
pkgver bump) and the repo has not been pulled yet, but it fails at
any subsequent attempt, throwing this:
== Making package: pantheon-notify-bzr 24-1 (Thu Apr 4 14:30:31
CEST 2013)
== Checking runtime dependencies...
== Checking buildtime dependencies...
== Retrieving sources...
== ERROR: /home/alucryd/Downloads/**pantheon-notify is not a
branch
of https://code.launchpad.net/~**tombeckmann/pantheon-notify/**
trunk https://code.launchpad.net/~tombeckmann/pantheon-notify/trunk
Aborting...
Makepkg uses 'bzr config parent_location' to determine the upstream
url, which, in this case is
http://bazaar.launchpad.net/~**tombeckmann/pantheon-notify/**trunk/http://bazaar.launchpad.net/~tombeckmann/pantheon-notify/trunk/and
not the url in my source array. I'm not sure this qualifies as a
bug,
but you have to make sure the upstream url is the one reported by
that command. I have prepared a small patch for makepkg to print
the
correct url, I'll open a bug later today and see if the patch can
be
merged.
Just a note on why the url you have provided and the url stored in
the
bzr config are different is because launchpad will return a http
permanent redirect.
My recommendation would be to use the url it redirects to.
However, I agree that this solution is not the greatest. One thing
it
stops you from doing is using bzr's directory service urls (e.g.
lp:)
So I look forward to your patch.
Regards,
Gary
Hi Gary,
Thx for adding support for bzr! I was writing the bug report when I
saw
your mail, it'll probably be quicker if I just attach the git patch
here.
It is not much, but it makes makepkg print the correct http url, so
people know what url they should use. It will not help with lp: urls
though, and right now I have no idea if there's a way to associate
the
output of 'bzr config parent_location' to a lp: url. I'll try to
think
of an alternate solution.
Cheers
--
Maxime
That sounds good.
I think the best place to send you patch is to pacman-dev
https://mailman.archlinux.org/**mailman/listinfo/pacman-devhttps://mailman.archlinux.org/mailman/listinfo/pacman-dev
Regards,
Gary
It is
https://wiki.archlinux.org/**index.php/Super_Quick_Git_**Guidehttps://wiki.archlinux.org/index.php/Super_Quick_Git_Guide
--
Sent from my Android Phone.
Daniel Wallace
Arch Linux Trusted User
GTManfred
Thx, I have sent the patch to pacman-dev.
Cheers
--
Maxime
Thanks for all the persons answering to my mail.
So far, I applied your patch, and my pkgver function now is
pkgver() {
bzr version-info $srcdir/$_bzrmod --custom --template={revno}\n
}
My problem still seems to be the one Martti figured out: The sources are
downloaded to $startdir/$_bzrmod, not to $srcdir/$_bzrmod.
If I fake this by creating a symlink
ln -s src/xwidget xwidget
and run makepkg, I get
[haawda@frege 4.1]$ makepkg
== Making package: emacs-xwidget-bzr 101273-1 (Thu Apr 4 19:58:58
CEST 2013)
== Checking runtime dependencies...
== Checking buildtime dependencies...
== Retrieving sources...
== ERROR:
/home/haawda/paketierung/**maintained_by_me/emacs-**xwidget-bzr/4.1/xwidget
is not a branch of
Re: [aur-general] Merge Request: deluge-stable - deluge-stable-git
On Friday, April 05, 2013 01:32:48 William Giokas wrote: TUs, deluge-stable[0] should be renamed to deluge-stable-git[1]. I have uplodaed the latter, and would just like the comments and votes transferred. [0]: https://aur.archlinux.org/packages/deluge-stable/ [1]: https://aur.archlinux.org/packages/deluge-stable-git/ Thank you, Merged, thanks. Felix Yan Twitter: @felixonmars Wiki: http://felixc.at signature.asc Description: This is a digitally signed message part.
Re: [aur-general] quoting (was: pacman 4.1 (makepkg 4.1) bazaar pkgver autobump problem)
On 05.04.2013 09:12, Stefan Husmann wrote: Am 04.04.2013 20:34, schrieb Maxime GAUDUIN: On Thu, Apr 4, 2013 at 8:07 PM, Stefan Husmann stefan-husm...@t-online.dewrote: Am 04.04.2013 16:06, schrieb Alucryd: On Thu, 2013-04-04 at 09:52 -0400, Daniel Wallace wrote: Gary van der Merwe gary...@gmail.com wrote: On Thu 04 Apr 2013 15:41:27 SAST, Alucryd wrote: On Thu, 2013-04-04 at 15:26 +0200, Gary van der Merwe wrote: Guys, please. Don't full quote 5 layers deep, that's an aweful lot of unnecessary scrolling for each mail which. Try to quote as little as possible while still making sure there is enough context for the reader to understand what you are talking about. If they need more than 1 or 2 (partial) layers, they should really read the original mails. signature.asc Description: OpenPGP digital signature
[aur-general] Signoff report for [community-testing]
=== Signoff report for [community-testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 0 new packages in last 24 hours * 0 known bad packages * 0 packages not accepting signoffs * 0 fully signed off packages * 6 packages missing signoffs * 6 packages older than 14 days (Note: the word 'package' as used here refers to packages as grouped by pkgbase, architecture, and repository; e.g., one PKGBUILD produces one package per architecture, even if it is a split package.) == Incomplete signoffs for [community] (6 total) == * fcron-3.1.2-1 (i686) 0/2 signoffs * oss-4.2_2007-3 (i686) 0/2 signoffs * shapelib-1.3.0-1 (i686) 0/2 signoffs * fcron-3.1.2-1 (x86_64) 0/2 signoffs * oss-4.2_2007-3 (x86_64) 0/2 signoffs * shapelib-1.3.0-1 (x86_64) 0/2 signoffs == All packages in [community-testing] for more than 14 days (6 total) == * shapelib-1.3.0-1 (i686), since 2013-02-24 * shapelib-1.3.0-1 (x86_64), since 2013-02-24 * oss-4.2_2007-3 (i686), since 2013-03-14 * oss-4.2_2007-3 (x86_64), since 2013-03-14 * fcron-3.1.2-1 (i686), since 2013-03-19 * fcron-3.1.2-1 (x86_64), since 2013-03-19 == Top five in signoffs in last 24 hours == 1. foutrelis - 4 signoffs 2. heftig - 2 signoffs 3. allan - 2 signoffs 4. pierre - 1 signoffs
Re: [aur-general] pacman 4.1 (makepkg 4.1) bazaar pkgver autobump problem
On 05/04/2013 09:12, Stefan Husmann wrote:
Hello,
setting the SRCDEST variable seems to do the trick. The package funtion
failed, but that was my
fault, I had some ${_bzrmod}-build references in it.
But I think not working without $SRCDEST set is a bug, at least an
inconsistency.
Thank you for your help and best regards,
Stefan.
Indeed, that is an issues. I will look into fixing that.
Gary
Re: [aur-general] please add -depth 1 to makepkg git clone
I can see this as useful in some cases with large repositories. Though i dont agree '1' should be the default for already stated reasons. --depth 1000 could be considered sane while allowing plenty of history and decreasing the size of clones from 10,000+ commit repos.
Re: [aur-general] quoting
Am 05.04.2013 09:37, schrieb Florian Pritz: Guys, please. Don't full quote 5 layers deep, that's an aweful lot of unnecessary scrolling for each mail which. Try to quote as little as possible while still making sure there is enough context for the reader to understand what you are talking about. If they need more than 1 or 2 (partial) layers, they should really read the original mails. Hello, sorry for that, I will keep that in mind for upcoming mails. Best regards, Stefan
[aur-general] [Merge Request] - 2 Packages
Both -git packages have been replaced by a tagged version of each without the -git suffix. Upstream code as been excepted into linux 3.10 release. Old packages: https://aur.archlinux.org/packages/nct677x-git/ https://aur.archlinux.org/packages/nct677x-ck-git/https://aur.archlinux.org/packages/nct677x-git/ Replaced by: https://aur.archlinux.org/packages/nct677xhttps://aur.archlinux.org/packages/nct677x-ck/ / https://aur.archlinux.org/packages/nct677x-ck/ Thanks!
Re: [aur-general] [Merge Request] - 2 Packages
On Friday, April 05, 2013 05:59:20 member graysky wrote: Both -git packages have been replaced by a tagged version of each without the -git suffix. Upstream code as been excepted into linux 3.10 release. Old packages: https://aur.archlinux.org/packages/nct677x-git/ https://aur.archlinux.org/packages/nct677x-ck-git/https://aur.archlinux.org/packages/nct677x-git/ Replaced by: https://aur.archlinux.org/packages/nct677xhttps://aur.archlinux.org/packages/nct677x-ck/ / https://aur.archlinux.org/packages/nct677x-ck/ Thanks! Both merged, thanks! Felix Yan Twitter: @felixonmars Wiki: http://felixc.at signature.asc Description: This is a digitally signed message part.
[aur-general] Deletion request
lib32-libusb[1] should be deleted in favor of lib32-libusbx[1] as libusbx is in [core]. [1] https://aur.archlinux.org/packages/lib32-libusb/ [2] https://aur.archlinux.org/packages/lib32-libusbx/ Please delete lib32-libusb Thanks, Rafael Ferreira
[aur-general] Deletion request: nvidia-ck-bumblebee and maybe others?
I believe functionality is within repo packages now. I submitted the following a while ago but orphaned when laptop died. Others have maintained but also recently orphaned it: https://aur.archlinux.org/packages/nvidia-ck-bumblebee/ The following are mostly orphaned and are packages that I did not submit: https://aur.archlinux.org/packages/nvidia-ck-pax-bumblebee/ https://aur.archlinux.org/packages/nvidia-ck-corex-bumblebee/ https://aur.archlinux.org/packages/nvidia-bumblebee-pae/ https://aur.archlinux.org/packages/nvidia-bumblebee-beta/ https://aur.archlinux.org/packages/nvidia-bumblebee-310xx/ https://aur.archlinux.org/packages/lib32-nvidia-utils-beta-bumblebee/ Do with them what you will, but please remove my original one. -- Sent from Gmail Mobile
Re: [aur-general] Deletion request: nvidia-ck-bumblebee and maybe others?
And I'm wondering if any TU would like to move nvidia-dkms from AUR to [community]. Just like catalyst-dkms in [community], which would help many people, I think. And dkms-bbswitch( may be should be renamed as bbswitch-dkms) as well. For me the bumblebee stack' s move to [community] is incomplete without these two.
Re: [aur-general] please add -depth 1 to makepkg git clone
Am 05.04.2013 08:12, schrieb Tai-Lin Chu: 1. save bandwidth 2. less wait why not add --depth 1 :) because you can't do nearly anything git related with this clone. You can't clone, can't update, etc. Best workflow is * clone the repo (like downloading a source package) * on all following calls do an update * then do a clone to do the build (even here without '--depth 1' because local clones are cheap) * before the next build only remove the build-clone With this workflow you only need to clone the repo once and then work with your local copy. I don't know exactly what automatic the new makepkg implements for repository sources, but I think it will do the first two steps above. So the PKGBUILD only has to provide the clone for the build (if the sources are not prepared for out-of-source builds). Hope this helps Uwe
[aur-general] VCS PKGBUILD and Pacman 4.1: increase epoch?
Hello, I was wondering, as I am updating my PKGBUILDs to use the new VCS features of pacman, if this specific case need an epoch increase for those packages. Packages version were generated from the date (eg 20130401) and thus will probably be bigger than new versions from the tags (eg 0.3.1.32.gfb4117d). Thus an epoch increase should be needed to have a correct behavior. But it seems most packagers are not increasing the epoch as they are switching to this new versionning scheme. Is there a recommendation on this? -- Cédric Girard
Re: [aur-general] VCS PKGBUILD and Pacman 4.1: increase epoch?
On Fri, Apr 5, 2013 at 4:02 PM, Cédric Girard girard.ced...@gmail.comwrote: Hello, I was wondering, as I am updating my PKGBUILDs to use the new VCS features of pacman, if this specific case need an epoch increase for those packages. Packages version were generated from the date (eg 20130401) and thus will probably be bigger than new versions from the tags (eg 0.3.1.32.gfb4117d). Thus an epoch increase should be needed to have a correct behavior. But it seems most packagers are not increasing the epoch as they are switching to this new versionning scheme. Is there a recommendation on this? -- Cédric Girard Yes, the correct thing to do would be bumping epoch for every new release of the PKGBUILD.
[aur-general] VCS PKGBUILD pacman 4.1: fragment revision on SVN don't work
according to manpage:
fragment
(optional) Allows specifying a revision number or branch
for makepkg to checkout from the VCS. For example, to checkout a given
revision, the source line would have the format
source=(url#revision=123). The available fragments depends
on the VCS being used:
svnrevision
this don't work
when passed:
source=('vapoursynth::svn+http://vapoursynth.googlecode.com/svn/trunk#revision=434')
always get latest commit in repo (in this case r445)
this is a bug?
the packagebuild http://sl1pkn07.no-ip.com/paste/view/242d4608
greetings
Re: [aur-general] please add -depth 1 to makepkg git clone
hmm.. not true sometimes. I will just post the definition here because I feel people dont understand shallow clone well. The --depth 1 option in git clone: Create a shallow clone with a history truncated to the specified number of revisions. A shallow repository has a number of limitations (you cannot clone or fetch from it, nor push from nor into it), but is adequate if you are only interested in the recent history of a large project with a long history, and would want to send in fixes as patches. so, 1. you can also do the pull once use forever 2. you cannot push to that repo anymore (but who really needs to anyway?) the only drawback i can see: 1. the git rev-list count head hack does not work. but should we just clone the whole thing for the pkgver? (notice, for example, tweeter bootstrap: 26mb vs 3mb with shallow clone) On Fri, Apr 5, 2013 at 6:41 AM, Uwe Koloska kol...@koloro.de wrote: Am 05.04.2013 08:12, schrieb Tai-Lin Chu: 1. save bandwidth 2. less wait why not add --depth 1 :) because you can't do nearly anything git related with this clone. You can't clone, can't update, etc. Best workflow is * clone the repo (like downloading a source package) * on all following calls do an update * then do a clone to do the build (even here without '--depth 1' because local clones are cheap) * before the next build only remove the build-clone With this workflow you only need to clone the repo once and then work with your local copy. I don't know exactly what automatic the new makepkg implements for repository sources, but I think it will do the first two steps above. So the PKGBUILD only has to provide the clone for the build (if the sources are not prepared for out-of-source builds). Hope this helps Uwe
[aur-general] Disown request
Could you please disown pyusb [1]. I get a Undelivered Mail Returned to Sender when trying to contact the maintainer. It seems its email is no longer valid. Thanks [1] https://aur.archlinux.org/packages/pyusb/ -- Nuno Araujo nuno.ara...@russo79.com signature.asc Description: This is a digitally signed message part
Re: [aur-general] VCS PKGBUILD and Pacman 4.1: increase epoch?
On 04/05/2013 10:05 AM, Jan Alexander Steffens wrote: On Fri, Apr 5, 2013 at 4:02 PM, Cédric Girard girard.ced...@gmail.comwrote: Hello, I was wondering, as I am updating my PKGBUILDs to use the new VCS features of pacman, if this specific case need an epoch increase for those packages. Packages version were generated from the date (eg 20130401) and thus will probably be bigger than new versions from the tags (eg 0.3.1.32.gfb4117d). Thus an epoch increase should be needed to have a correct behavior. But it seems most packagers are not increasing the epoch as they are switching to this new versionning scheme. Is there a recommendation on this? -- Cédric Girard Yes, the correct thing to do would be bumping epoch for every new release of the PKGBUILD. I think you mean it just needs to be bumped this once, since the tag versions are going to be increasing from here onward... (unless, of course, the pkgver() function is changed in a way that this is not true).
Re: [aur-general] VCS PKGBUILD and Pacman 4.1: increase epoch?
On Fri, 5 Apr 2013 15:11:40 -0400, luoli...@gmail.com wrote: On 04/05/2013 10:05 AM, Jan Alexander Steffens wrote: On Fri, Apr 5, 2013 at 4:02 PM, Cédric Girard girard.ced...@gmail.comwrote: Hello, I was wondering, as I am updating my PKGBUILDs to use the new VCS features of pacman, if this specific case need an epoch increase for those packages. Packages version were generated from the date (eg 20130401) and thus will probably be bigger than new versions from the tags (eg 0.3.1.32.gfb4117d). Thus an epoch increase should be needed to have a correct behavior. But it seems most packagers are not increasing the epoch as they are switching to this new versionning scheme. Is there a recommendation on this? -- Cédric Girard Yes, the correct thing to do would be bumping epoch for every new release of the PKGBUILD. I think you mean it just needs to be bumped this once, since the tag versions are going to be increasing from here onward... (unless, of course, the pkgver() function is changed in a way that this is not true). I'm sure an epoch is the correct way to handle this, but we have to remember this is the AUR, not the official repos. The officially supported way of building from the AUR is using makepkg then install with pacman, in which case the epoch won't make a difference. It will stop pacman from giving you a warning, and in return you're stuck with an epoch for the life of the package. If the maintainer wants to make it easier for AUR helpers, go ahead and add the epoch, but I don't see it as required in this case.
Re: [aur-general] Disown request
Nuno Araujo wrote: Could you please disown pyusb [1]. I get a Undelivered Mail Returned to Sender when trying to contact the maintainer. It seems its email is no longer valid. Thanks [1] https://aur.archlinux.org/packages/pyusb/ -- Nuno Araujo nuno.ara...@russo79.com done
Re: [aur-general] Deletion request
On Fri, 2013-04-05 at 07:35 -0300, Rafael Ferreira wrote: lib32-libusb[1] should be deleted in favor of lib32-libusbx[1] as libusbx is in [core]. [1] https://aur.archlinux.org/packages/lib32-libusb/ [2] https://aur.archlinux.org/packages/lib32-libusbx/ Please delete lib32-libusb Thanks, Rafael Ferreira Hi Rafael, I've deleted lib32-libusb. I see you have some packages depending on it, even if lib32-libusbx provides lib32-libusb, it would be a good idea to update them. Cheers. -- Maxime
Re: [aur-general] Deletion request: nvidia-ck-bumblebee and maybe others?
On Fri, 2013-04-05 at 07:24 -0400, member graysky wrote: I believe functionality is within repo packages now. I submitted the following a while ago but orphaned when laptop died. Others have maintained but also recently orphaned it: https://aur.archlinux.org/packages/nvidia-ck-bumblebee/ The following are mostly orphaned and are packages that I did not submit: https://aur.archlinux.org/packages/nvidia-ck-pax-bumblebee/ https://aur.archlinux.org/packages/nvidia-ck-corex-bumblebee/ https://aur.archlinux.org/packages/nvidia-bumblebee-pae/ https://aur.archlinux.org/packages/nvidia-bumblebee-beta/ https://aur.archlinux.org/packages/nvidia-bumblebee-310xx/ https://aur.archlinux.org/packages/lib32-nvidia-utils-beta-bumblebee/ Do with them what you will, but please remove my original one. Deleted all the orphans, thank you. I've left a message on the remaining bumblebee packages for alternate kernels in AUR, asking them if they could switch to nvidia-dkms instead. This applies to all the other nvidia packages too, using dkms exclusively would help remove some clutter in AUR, but one thing at a time I guess. Cheers. -- Maxime
Re: [aur-general] Deletion request: nvidia-ck-bumblebee and maybe others?
On Fri, 2013-04-05 at 19:49 +0800, GSC wrote: And I'm wondering if any TU would like to move nvidia-dkms from AUR to [community]. Just like catalyst-dkms in [community], which would help many people, I think. And dkms-bbswitch( may be should be renamed as bbswitch-dkms) as well. For me the bumblebee stack' s move to [community] is incomplete without these two. Well the idea of pushing nvidia-dkms in [community] has not come across yet (I'd like it to, I'm maintaining it in AUR :). dkms is still frowned upon because of the untracked files it generates. As for bbswitch, I've asked for a rename of the regular and git package, some uniformity never hurts. I don't know if a TU is willing to push it though. I'd do it if I had an NVIDIA laptop, but mine is AMD. Cheers. -- Maxime
Re: [aur-general] VCS PKGBUILD and Pacman 4.1: increase epoch?
On 5 April 2013 20:17, Doug Newgard scimmi...@outlook.com wrote: On Fri, 5 Apr 2013 15:11:40 -0400, luoli...@gmail.com wrote: On 04/05/2013 10:05 AM, Jan Alexander Steffens wrote: On Fri, Apr 5, 2013 at 4:02 PM, Cédric Girard girard.ced...@gmail.com wrote: Hello, I was wondering, as I am updating my PKGBUILDs to use the new VCS features of pacman, if this specific case need an epoch increase for those packages. Packages version were generated from the date (eg 20130401) and thus will probably be bigger than new versions from the tags (eg 0.3.1.32.gfb4117d). Thus an epoch increase should be needed to have a correct behavior. But it seems most packagers are not increasing the epoch as they are switching to this new versionning scheme. Is there a recommendation on this? -- Cédric Girard Yes, the correct thing to do would be bumping epoch for every new release of the PKGBUILD. I think you mean it just needs to be bumped this once, since the tag versions are going to be increasing from here onward... (unless, of course, the pkgver() function is changed in a way that this is not true). I'm sure an epoch is the correct way to handle this, but we have to remember this is the AUR, not the official repos. The officially supported way of building from the AUR is using makepkg then install with pacman, in which case the epoch won't make a difference. It will stop pacman from giving you a warning, and in return you're stuck with an epoch for the life of the package. If the maintainer wants to make it easier for AUR helpers, go ahead and add the epoch, but I don't see it as required in this case. Is the new way of pkgver-ing VCS packages mandatory? The VCS Guidelines[0] isn't clear, it just says that pkgver is more controllable, and lists a few examples. Would it be wrong for me to continue using the date +%Y%m%d versioning system, or is up to individual maintainers to choose which system is more appropriate?
Re: [aur-general] VCS PKGBUILD and Pacman 4.1: increase epoch?
On 5 April 2013 22:19, WorMzy Tykashi wormzy.tyka...@gmail.com wrote: On 5 April 2013 20:17, Doug Newgard scimmi...@outlook.com wrote: On Fri, 5 Apr 2013 15:11:40 -0400, luoli...@gmail.com wrote: On 04/05/2013 10:05 AM, Jan Alexander Steffens wrote: On Fri, Apr 5, 2013 at 4:02 PM, Cédric Girard girard.ced...@gmail.comwrote: Hello, I was wondering, as I am updating my PKGBUILDs to use the new VCS features of pacman, if this specific case need an epoch increase for those packages. Packages version were generated from the date (eg 20130401) and thus will probably be bigger than new versions from the tags (eg 0.3.1.32.gfb4117d). Thus an epoch increase should be needed to have a correct behavior. But it seems most packagers are not increasing the epoch as they are switching to this new versionning scheme. Is there a recommendation on this? -- Cédric Girard Yes, the correct thing to do would be bumping epoch for every new release of the PKGBUILD. I think you mean it just needs to be bumped this once, since the tag versions are going to be increasing from here onward... (unless, of course, the pkgver() function is changed in a way that this is not true). I'm sure an epoch is the correct way to handle this, but we have to remember this is the AUR, not the official repos. The officially supported way of building from the AUR is using makepkg then install with pacman, in which case the epoch won't make a difference. It will stop pacman from giving you a warning, and in return you're stuck with an epoch for the life of the package. If the maintainer wants to make it easier for AUR helpers, go ahead and add the epoch, but I don't see it as required in this case. Is the new way of pkgver-ing VCS packages mandatory? The VCS Guidelines[0] isn't clear, it just says that pkgver is more controllable, and lists a few examples. Would it be wrong for me to continue using the date +%Y%m%d versioning system, or is up to individual maintainers to choose which system is more appropriate? Oops. Forgot my reference. [0] https://wiki.archlinux.org/index.php/Arch_CVS_%26_SVN_PKGBUILD_guidelines
Re: [aur-general] Disown request
On ven, 2013-04-05 at 20:05 +, Xyne wrote: Nuno Araujo wrote: Could you please disown pyusb [1]. [1] https://aur.archlinux.org/packages/pyusb/ done Is there a race taking place to see who takes ownership of the recently disowned packages or to see who has the most packages maintained in AUR? Less than one hour after the package was disowned, ownership was taken by user luolimao. This user has over 200 packages on AUR! However the fix that I need to see applied to the package was still not applied. I don't care who maintains the package (less work for me if it's someone else), but when someone takes ownership of a given package that needs some work I expect that he has already prepared what needs to be done locally. Could we change the behavior of the disown requests to give ownership to the user who makes the request? Regards -- Nuno Araujo nuno.ara...@russo79.com signature.asc Description: This is a digitally signed message part
Re: [aur-general] VCS PKGBUILD and Pacman 4.1: increase epoch?
On Fri, 2013-04-05 at 22:20 +0100, WorMzy Tykashi wrote: On 5 April 2013 22:19, WorMzy Tykashi wormzy.tyka...@gmail.com wrote: On 5 April 2013 20:17, Doug Newgard scimmi...@outlook.com wrote: On Fri, 5 Apr 2013 15:11:40 -0400, luoli...@gmail.com wrote: On 04/05/2013 10:05 AM, Jan Alexander Steffens wrote: On Fri, Apr 5, 2013 at 4:02 PM, Cédric Girard girard.ced...@gmail.comwrote: Hello, I was wondering, as I am updating my PKGBUILDs to use the new VCS features of pacman, if this specific case need an epoch increase for those packages. Packages version were generated from the date (eg 20130401) and thus will probably be bigger than new versions from the tags (eg 0.3.1.32.gfb4117d). Thus an epoch increase should be needed to have a correct behavior. But it seems most packagers are not increasing the epoch as they are switching to this new versionning scheme. Is there a recommendation on this? -- Cédric Girard Yes, the correct thing to do would be bumping epoch for every new release of the PKGBUILD. I think you mean it just needs to be bumped this once, since the tag versions are going to be increasing from here onward... (unless, of course, the pkgver() function is changed in a way that this is not true). I'm sure an epoch is the correct way to handle this, but we have to remember this is the AUR, not the official repos. The officially supported way of building from the AUR is using makepkg then install with pacman, in which case the epoch won't make a difference. It will stop pacman from giving you a warning, and in return you're stuck with an epoch for the life of the package. If the maintainer wants to make it easier for AUR helpers, go ahead and add the epoch, but I don't see it as required in this case. Is the new way of pkgver-ing VCS packages mandatory? The VCS Guidelines[0] isn't clear, it just says that pkgver is more controllable, and lists a few examples. Would it be wrong for me to continue using the date +%Y%m%d versioning system, or is up to individual maintainers to choose which system is more appropriate? Oops. Forgot my reference. [0] https://wiki.archlinux.org/index.php/Arch_CVS_%26_SVN_PKGBUILD_guidelines The versioning scheme is up to the maintainer, you're free to choose the one which makes more sense, and using the date is perfectly fine. The guidelines only provide examples. About epoch, I chose not to add one in my AUR packages. I believe it is an unnecessary complication, only makepkg is officially supported for AUR, epoch is irrelevant for such installs. Cheers. -- Maxime
Re: [aur-general] Disown request
On Fri, 2013-04-05 at 23:22 +0200, Nuno Araujo wrote: On ven, 2013-04-05 at 20:05 +, Xyne wrote: Nuno Araujo wrote: Could you please disown pyusb [1]. [1] https://aur.archlinux.org/packages/pyusb/ done Is there a race taking place to see who takes ownership of the recently disowned packages or to see who has the most packages maintained in AUR? Less than one hour after the package was disowned, ownership was taken by user luolimao. This user has over 200 packages on AUR! However the fix that I need to see applied to the package was still not applied. I don't care who maintains the package (less work for me if it's someone else), but when someone takes ownership of a given package that needs some work I expect that he has already prepared what needs to be done locally. Could we change the behavior of the disown requests to give ownership to the user who makes the request? Regards I've disowned it again, please feel free to adopt it. Cheers. -- Maxime
Re: [aur-general] VCS PKGBUILD and Pacman 4.1: increase epoch?
On Fri, Apr 5, 2013 at 5:32 PM, Maxime Gauduin aluc...@gmail.com wrote: On Fri, 2013-04-05 at 22:20 +0100, WorMzy Tykashi wrote: On 5 April 2013 22:19, WorMzy Tykashi wormzy.tyka...@gmail.com wrote: Oops. Forgot my reference. [0] https://wiki.archlinux.org/index.php/Arch_CVS_%26_SVN_PKGBUILD_guidelines The versioning scheme is up to the maintainer, you're free to choose the one which makes more sense, and using the date is perfectly fine. The guidelines only provide examples. About epoch, I chose not to add one in my AUR packages. I believe it is an unnecessary complication, only makepkg is officially supported for AUR, epoch is irrelevant for such installs. Cheers. -- Maxime I agree that epoch should not be included in AUR packages just to work around limitations in unsupported AUR helpers. If the AUR helpers cannot properly handle these, then the AUR helpers should be fixed rather than polluting the PKGBUILDs with workarounds. PKGBUILDs in the AUR are frequently sloppy enough as it is. Let's not make the problem any worse. Jason
Re: [aur-general] VCS PKGBUILD and Pacman 4.1: increase epoch?
On Fri, Apr 5, 2013 at 11:41 PM, Jason St. John jstj...@purdue.edu wrote: I agree that epoch should not be included in AUR packages just to work around limitations in unsupported AUR helpers. If the AUR helpers cannot properly handle these, then the AUR helpers should be fixed rather than polluting the PKGBUILDs with workarounds. PKGBUILDs in the AUR are frequently sloppy enough as it is. Let's not make the problem any worse. Jason The problem is that makepkg will update the pkgver of the downloaded PKGBUILD, so there is no reliable way of detecting an update without either bumping the epoch, or storing another copy of the downloaded PKGBUILD.
Re: [aur-general] VCS PKGBUILD and Pacman 4.1: increase epoch?
On Fri, 2013-04-05 at 23:49 +0200, Jan Alexander Steffens wrote: On Fri, Apr 5, 2013 at 11:41 PM, Jason St. John jstj...@purdue.edu wrote: I agree that epoch should not be included in AUR packages just to work around limitations in unsupported AUR helpers. If the AUR helpers cannot properly handle these, then the AUR helpers should be fixed rather than polluting the PKGBUILDs with workarounds. PKGBUILDs in the AUR are frequently sloppy enough as it is. Let's not make the problem any worse. Jason The problem is that makepkg will update the pkgver of the downloaded PKGBUILD, so there is no reliable way of detecting an update without either bumping the epoch, or storing another copy of the downloaded PKGBUILD. Indeed, but wasn't this already true even before pacman 4.1? -- Maxime
[aur-general] removal request
Please remove the package sentinel-ldk https://aur.archlinux.org/packages/sentinel-ldk/ It is no longer available on the source ftp server; aksusb may be used as a replacement.
Re: [aur-general] removal request
On Sat, 2013-04-06 at 00:09 +0200, Andre Bartke wrote: Please remove the package sentinel-ldk https://aur.archlinux.org/packages/sentinel-ldk/ It is no longer available on the source ftp server; aksusb may be used as a replacement. Deleted, thank you. Cheers -- Maxime
Re: [aur-general] VCS PKGBUILD and Pacman 4.1: increase epoch?
On Fri, Apr 5, 2013 at 5:57 PM, Maxime Gauduin aluc...@gmail.com wrote: On Fri, 2013-04-05 at 23:49 +0200, Jan Alexander Steffens wrote: On Fri, Apr 5, 2013 at 11:41 PM, Jason St. John jstj...@purdue.edu wrote: I agree that epoch should not be included in AUR packages just to work around limitations in unsupported AUR helpers. If the AUR helpers cannot properly handle these, then the AUR helpers should be fixed rather than polluting the PKGBUILDs with workarounds. PKGBUILDs in the AUR are frequently sloppy enough as it is. Let's not make the problem any worse. Jason The problem is that makepkg will update the pkgver of the downloaded PKGBUILD, so there is no reliable way of detecting an update without either bumping the epoch, or storing another copy of the downloaded PKGBUILD. Indeed, but wasn't this already true even before pacman 4.1? -- Maxime Yes, previous versions of pacman had makepkg automatically update the pkgver of the PKGBUILD. Jason
[aur-general] Removal request
Hi, Could you please remove mu-kiss [1], please? It's the same as mu [2], only without support for the GUI tools, but with the latest version of mu this isn't needed anymore, since these now depend on webkitgtk3, and won't be built unless this is installed. Thanks. [1] https://aur.archlinux.org/packages/mu-kiss/ [2] https://aur.archlinux.org/packages/mu/ pgpVlnZtaSyHo.pgp Description: PGP signature
Re: [aur-general] Removal request
On Fri, 2013-04-05 at 16:20 -0600, OmeGa wrote: Hi, Could you please remove mu-kiss [1], please? It's the same as mu [2], only without support for the GUI tools, but with the latest version of mu this isn't needed anymore, since these now depend on webkitgtk3, and won't be built unless this is installed. Thanks. [1] https://aur.archlinux.org/packages/mu-kiss/ [2] https://aur.archlinux.org/packages/mu/ Deleted, thx! -- Maxime
Re: [aur-general] please add -depth 1 to makepkg git clone
On Thu, Apr 04, 2013 at 11:12:29PM -0700, Tai-Lin Chu wrote: 1. save bandwidth 2. less wait why not add --depth 1 :) I have tested this out on many repos (including the linux git repository) and the bandwidth saved is so minimal it's not even worth it. -- William Giokas | KaiSforza GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF pgplBmgDaLV3s.pgp Description: PGP signature
Re: [aur-general] please add -depth 1 to makepkg git clone
@William Giokas really? tweeter bootstrap saves 88% vlc saves 87% make sure you dont read the wrong number. On Fri, Apr 5, 2013 at 6:17 PM, William Giokas 1007...@gmail.com wrote: On Thu, Apr 04, 2013 at 11:12:29PM -0700, Tai-Lin Chu wrote: 1. save bandwidth 2. less wait why not add --depth 1 :) I have tested this out on many repos (including the linux git repository) and the bandwidth saved is so minimal it's not even worth it. -- William Giokas | KaiSforza GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF
Re: [aur-general] please add -depth 1 to makepkg git clone
On Fri, Apr 5, 2013 at 8:12 AM, Tai-Lin Chu tailin...@gmail.com wrote: 1. save bandwidth 2. less wait why not add --depth 1 :) Won't work as you can't clone shallow repositories, which makepkg needs to do to create the working copy for the build.
Re: [aur-general] please add -depth 1 to makepkg git clone
makepkg only needs the latest git snapshot there are only 2 cases that wont work: 1. revert git commit 2. count # of revisions On Fri, Apr 5, 2013 at 6:43 PM, Jan Alexander Steffens jan.steff...@gmail.com wrote: On Fri, Apr 5, 2013 at 8:12 AM, Tai-Lin Chu tailin...@gmail.com wrote: 1. save bandwidth 2. less wait why not add --depth 1 :) Won't work as you can't clone shallow repositories, which makepkg needs to do to create the working copy for the build.
Re: [aur-general] please add -depth 1 to makepkg git clone
On Fri, Apr 05, 2013 at 06:40:33PM -0700, Tai-Lin Chu wrote: @William Giokas really? tweeter bootstrap saves 88% vlc saves 87% make sure you dont read the wrong number. Okay, I take that back. The clones are significantly smaller[0], but at the same time, I will argue that these git repositories should be as full as possible, seeing as people using the -git packages should not be just building them for fun, but should have a reason to be using these unstable sources (ie: developing, testing, etc.). If you're using these just for fun, then something is wrong. It's like installing Arch: the first time it's all of the set up, but to keep it up to date is simple. I use linux-mainline, and get the sources from git. The original clone was pretty big, but pulling from git I think it takes ~1M/week. This is still a -1 from me, unless it is configurable, though the vcs urls are already pretty full (vcs+file::url#fragment=xyz), and I think it should be on a per-repo basis, not in the OPTIONS array. [0]: Cloning into bare repository 'shallow'... remote: Counting objects: 1046, done. remote: Compressing objects: 100% (953/953), done. remote: Total 1046 (delta 376), reused 518 (delta 52) Receiving objects: 100% (1046/1046), 2.65 MiB, done. Resolving deltas: 100% (376/376), done. Cloning into bare repository 'full'... remote: Counting objects: 75015, done. remote: Compressing objects: 100% (19022/19022), done. remote: Total 75015 (delta 53683), reused 72896 (delta 51870) Receiving objects: 100% (75015/75015), 15.71 MiB | 10.33 MiB/s, done. Resolving deltas: 100% (53683/53683), done. (I don't know what I was thinking there...probably screwed up the git command when i tested it last.) Thanks, -- William Giokas | KaiSforza GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF pgpN8ePvpSA4z.pgp Description: PGP signature
Re: [aur-general] please add -depth 1 to makepkg git clone
On Fri, Apr 05, 2013 at 06:47:55PM -0700, Tai-Lin Chu wrote: makepkg only needs the latest git snapshot there are only 2 cases that wont work: 1. revert git commit 2. count # of revisions Won't work as you can't clone shallow repositories, which makepkg needs to do to create the working copy for the build. This is also true. makepkg clones a bare repository to the SRCDEST directory. If this is a shallow bare repo, then clones cannot be made of it which is what makepkg does. Thanks, -- William Giokas | KaiSforza GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF pgpbviDmIZVKY.pgp Description: PGP signature
Re: [aur-general] please add -depth 1 to makepkg git clone
1. you can still pull, so it will not be a reason to go against it This is also true. makepkg clones a bare repository to the SRCDEST directory. If this is a shallow bare repo, then clones cannot be made of it which is what makepkg does. 2. ... i dont think why it needs to use git clone. using cp is good enough... On Fri, Apr 5, 2013 at 7:05 PM, William Giokas 1007...@gmail.com wrote: On Fri, Apr 05, 2013 at 06:47:55PM -0700, Tai-Lin Chu wrote: makepkg only needs the latest git snapshot there are only 2 cases that wont work: 1. revert git commit 2. count # of revisions Won't work as you can't clone shallow repositories, which makepkg needs to do to create the working copy for the build. This is also true. makepkg clones a bare repository to the SRCDEST directory. If this is a shallow bare repo, then clones cannot be made of it which is what makepkg does. Thanks, -- William Giokas | KaiSforza GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF
Re: [aur-general] please add -depth 1 to makepkg git clone
On Fri, Apr 05, 2013 at 07:35:15PM -0700, Tai-Lin Chu wrote: 1. you can still pull, so it will not be a reason to go against it Okay, say that I run $ git clone --bare --depth 1 git://some.repo.git foo blah blah clone clone...etc. $ git clone foo foo-local-clone Cloning into 'shallowclone'... fatal: attempt to fetch/clone from a shallow repository fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. And here is what makepkg does with git sources: 1) clones a bare repository into SRCDEST 2) verifies the checksum, which should be 'SKIP' for these kinds of sources 3) clones the SRCDEST repo into the BUILDDIR, $srcdir. If it can't complete this final step, then you have no sources to work with and makepkg is worthless for git sources. This is also true. makepkg clones a bare repository to the SRCDEST directory. If this is a shallow bare repo, then clones cannot be made of it which is what makepkg does. 2. ... i dont think why it needs to use git clone. using cp is good enough... Using git clone preserves every file to the smallest detail. cp makes no such guarantees. -- William Giokas | KaiSforza GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF pgp3B2l9ZqM1N.pgp Description: PGP signature
Re: [aur-general] VCS PKGBUILD pacman 4.1: fragment revision on SVN don't work
On Fri, Apr 05, 2013 at 04:23:03PM +0200, SpinFlo wrote:
according to manpage:
fragment
(optional) Allows specifying a revision number or branch
for makepkg to checkout from the VCS. For example, to checkout a given
revision, the source line would have the format
source=(url#revision=123). The available fragments depends
on the VCS being used:
svnrevision
this don't work
when passed:
source=('vapoursynth::svn+http://vapoursynth.googlecode.com/svn/trunk#revision=434')
always get latest commit in repo (in this case r445)
this is a bug?
the packagebuild http://sl1pkn07.no-ip.com/paste/view/242d4608
I ran this using your PKGBUILD, and it's saying that 434 is checked out.
Updating '.':
At revision 445.
Avapoursynth
Avapoursynth/test
...
...
...
Avapoursynth/installer/vsinstaller.iss
Avapoursynth/installer/template.vpy
Exported revision 434.
Thanks,
--
William Giokas | KaiSforza
GnuPG Key: 0x73CD09CF
Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF
pgp0KH6lOd6aK.pgp
Description: PGP signature
[aur-general] nanoc3 deletion request
I'm requesting the deletion of the AUR package nanoc3. [1] The AUR currently includes two similarly-named packages: nanoc and nanoc3. At one time, nanoc provided v2.x of the gem, and nanoc3 provided v3.x of the gem. [2] However, nanoc has supseded nanoc3. If you look at rubygems.org, you can see that the two development lines merged from 3.2.0 to 3.3.0. After the release of 3.3.0, nanoc3 releases stopped, whereas nanoc releases continued. [3][4] Thus, nanoc3 is no longer being developed, and it has been superseded. One last question: assuming the deletion request is approved, should the nanoc PKGBUILD both replace() and provide() nanoc3? If I understand correctly, the replace() would allow nanoc3 users a clean upgrade path, whereas the provide() would allow programs that depend on nanoc3 to use nanoc. (new package maintainer here, so still fleshing out my understanding of things) [1] https://aur.archlinux.org/packages/ruby-nanoc3/ [2] http://nanoc.ws/wiki-old/Development_3.1_BetterGemAndExecutableNames/ [3] https://rubygems.org/gems/nanoc/versions [4] https://rubygems.org/gems/nanoc3/versions -- Jeremy Ichimonji10 Audet
Re: [aur-general] please add -depth 1 to makepkg git clone
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Tai-Lin Chu tailin...@gmail.com wrote: 1. you can still pull, so it will not be a reason to go against it This is also true. makepkg clones a bare repository to the SRCDEST directory. If this is a shallow bare repo, then clones cannot be made of it which is what makepkg does. 2. ... i dont think why it needs to use git clone. using cp is good enough... On Fri, Apr 5, 2013 at 7:05 PM, William Giokas 1007...@gmail.com wrote: On Fri, Apr 05, 2013 at 06:47:55PM -0700, Tai-Lin Chu wrote: makepkg only needs the latest git snapshot there are only 2 cases that wont work: 1. revert git commit 2. count # of revisions Won't work as you can't clone shallow repositories, which makepkg needs to do to create the working copy for the build. This is also true. makepkg clones a bare repository to the SRCDEST directory. If this is a shallow bare repo, then clones cannot be made of it which is what makepkg does. Thanks, -- William Giokas | KaiSforza GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF This is dumb because using cp is not enough, you should be using git clone because it is git and straight from git, if you goal is to just use the newest you are doing it wrong go write you own pkgbuild. The only reason to use git packages is if you are deving upstream and want to actively test development of upstream packages... Or if up stream is dumb enough to never tag stable releases. Fortunately there are very few of the latter, so to support the majority of of users we clone the whole thing. You are welcome to use the old method if you are so naive to believe that people will actually benefit from a true shallow clone of a git repository though yaourt. Because no one should ever install a git I ask age through yaourt because it is deleted immediately. - -- Sent from my Android Phone. Daniel Wallace Arch Linux Trusted User GTManfred -BEGIN PGP SIGNATURE- Version: APG v1.0.8 iQFUBAEBCAA+BQJRX7PvNxxEYW5pZWwgV2FsbGFjZSAoZ3RtYW5mcmVkKSA8ZGFu aWVsLndhbGxhY2VAZ2F0ZWNoLmVkdT4ACgkQX6XlVE8BDUjm8ggAkOdV8r/bQHy9 mE1XtFAu6T+j83leaRugchsK9sIzKAKjfEHThpfO/nG6MBVPNytjqVhgyqrsHgr9 1ItAl3VrdbjFmQpRplBvYz8dAkid5pq2ZdG9f/ildROkirxCzPkevCjTenmouxY6 oY4vXUFthc7WOtviaQ1U9+pSmgrzTWvCrzlyZG1tPRlxRVYDHTPpVzxhtOrExUhy rAF6MOry5u3tww/mHigNwQPW6kVVh1nB5lWhoJ5PIY7cENKXJP7o+npV2Hb9TCGr djrFOCg+ZaeeX/gK93cI6BigiF5XdAFnPhpiQpoLXvUiD050bOoj5d7tKb+be7Ba FGrXvqNPlg== =EBW2 -END PGP SIGNATURE-
Re: [aur-general] please add -depth 1 to makepkg git clone
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Tai-Lin Chu tailin...@gmail.com wrote: 1. you can still pull, so it will not be a reason to go against it This is also true. makepkg clones a bare repository to the SRCDEST directory. If this is a shallow bare repo, then clones cannot be made of it which is what makepkg does. 2. ... i dont think why it needs to use git clone. using cp is good enough... On Fri, Apr 5, 2013 at 7:05 PM, William Giokas 1007...@gmail.com wrote: On Fri, Apr 05, 2013 at 06:47:55PM -0700, Tai-Lin Chu wrote: makepkg only needs the latest git snapshot there are only 2 cases that wont work: 1. revert git commit 2. count # of revisions Won't work as you can't clone shallow repositories, which makepkg needs to do to create the working copy for the build. This is also true. makepkg clones a bare repository to the SRCDEST directory. If this is a shallow bare repo, then clones cannot be made of it which is what makepkg does. Thanks, -- William Giokas | KaiSforza GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF I truly do not understand why this conversation exists. We discussed this months ago. The conclusion was that you really shouldn't be using these packages unless you are following upstream... What if the current depth=1 is unstable and has a huge bug Then what... Oh those users aren't following upstream and have no idea because instead of the developers of the program monitoring and telling them this a stable (and hopefully bug free release... The use your depth=1 pkgbuild and never update until one of the depends does a soname bump and breaks everything... To save space... In my opinion we should actually remove git packages from the aur... It adds an air of instability to the distribution... People that use -git should really maintain there own pkgbuild... And yes I felt this was so important I interrupted my night out to send... So, unlike you, I hope depth is never supported in package source=() - -- Sent from my Android Phone. Daniel Wallace Arch Linux Trusted User GTManfred -BEGIN PGP SIGNATURE- Version: APG v1.0.8 iQFUBAEBCAA+BQJRX7eRNxxEYW5pZWwgV2FsbGFjZSAoZ3RtYW5mcmVkKSA8ZGFu aWVsLndhbGxhY2VAZ2F0ZWNoLmVkdT4ACgkQX6XlVE8BDUiGAgf/TywmVGiCUD7h gwAa41u43M9v890Suf2Io9x37ptiVJ6vGcwx5iWKJVct8r6TSh0xvavZo3VRW3G3 9mVst9HVSa16tMBXelVMGC2h1dawH2MYi8Jy1/L453133hFTqkIAOKPRX+QF+c5o /8xU3sXog/115n2UiYnn2PymsnYen+xHxdrW4x3nGDJYFFwUlDVq+YmRRFjZrz+/ a2sP5RkK0isv4U3h57bnb2mwQrZscV/IYMUrBmhHhaWZpErBx2EnZlm/PYjrnYEE D+CNmaYoVh7zdKbI+X+1/cY4E2OSSRgwK8IU8gM7mXkw447VjASDf2s/RnyxOPND ENGX7R1V2A== =PNi3 -END PGP SIGNATURE-
