[aur-general] [Classroom] RESEND: Introduction to Package Maintenance
All, So I'm terrible at sending emails it would seem, and I need to get everyone on the same page. The class is taking place on Saturday, September the 14th, 2013, at 1700 UTC. See the previous email for information about the class itself. Thanks, -- William Giokas | KaiSforza | http://kaictl.net/ GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF pgpcL7FCYXfM4.pgp Description: PGP signature
[aur-general] Disown request: tmux-git
- Forwarded message from William Giokas - Date: Thu, 19 Sep 2013 06:23:37 -0500 From: William Giokas To: Dmitry Korzhevin Subject: Updating tmux-git to current vcs format User-Agent: Mutt/1.5.21 (2010-09-15) Hello, Do you have plans to update tmux-git to the new vcs pkgver format? Currently it is using a pre-4.1 setup for building. Please update it, or if you no longer want to maintain it, orphan it and let someone else update it. Thanks, -- William Giokas | KaiSforza | http://kaictl.net/ GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF - End forwarded message - Sent this to the maintainer of tmux-git on 2013/09/19 and have not yet recieved a reply yet. Could someone please disown this package so I may adopt it? Thanks, -- William Giokas | KaiSforza | http://kaictl.net/ GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF pgpQZHmhgQPHA.pgp Description: PGP signature
Re: [aur-general] Revise VCS packages versioning
On Wed, Oct 30, 2013 at 09:49:11PM -0700, Anatol Pomozov wrote:
> Hi
>
> On Wed, Oct 30, 2013 at 8:51 PM, Jerome Leclanche wrote:
> > As someone who maintains a lot of git packages, I wish, I really wish
> > there was a *standardized* way of writing a pkgver that would output
> > the appropriate format whether there are tags pushed upstream or not.
>
> That is what I intended to propose next.
>
> As the regexp become more complicated it is better if makepkg will
> take care of generating the package version. I think makepkg should
> have a shell function, something like 'generate_pkgver_vcs()' that
> user can use in pkgver().
>
> e.g.
>
> pkgver() {
> cd repo
> generate_pkgver_vcs()
> }
>
> This function will
> 1) Find what VCS is used
> 2) Generate appropriate VCS version
>
I would urge you to look at one of the newer features of pacman,
makepkg-template. You can do such things as this very easily. I already
maintain a small and probably awful repository[1]/package[2] with a few
VCS pkgver functions that you can use. Mostly they have been taken from
the wiki, though I do have a nice, long sed expression that does the
'r' prefixing (I wrote that talk article).
[1]: http://git.kaictl.net/wgiokas/makepkg-templates.git/
[2]: https://aur.archlinux.org/packages/makepkg-templates-ks-git/
--SNIP--
> >> Another issue is a repo that has no tags. Here is a recommendation
> >> from the wiki page:
> >>
> >> printf "%s.%s" "$(git rev-list --count HEAD)" "$(git rev-parse --short
> >> HEAD)"
> >>
> >> that will use number of commits (a large number e.g. 3000). The
> >> problem arises when the project creates first tag e.g. 0.1. I suggest
> >> to fix this problem by using "0" as a tag version (and add prefix 'r'
> >> like in the previous item). This makes sure that non-tagged version is
> >> always less that a tagged version.
> >>
> >> So pkgver() will look like:
> >>
> >> printf "0.r%s.%s" "$(git rev-list --count HEAD)" "$(git rev-parse --short
> >> HEAD)"
> >>
> >> Let me know if you have any objections. If not then I'll update the wiki
> >> page.
This is not needed at all. If the project starts using tags, use an
epoch= to set all versions from then on to be greater than the original
versions with rev-list.
Thanks,
--
William Giokas | KaiSforza | http://kaictl.net/
GnuPG Key: 0x73CD09CF
Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF
pgpSkJ8stADbS.pgp
Description: PGP signature
Re: [aur-general] Revise VCS packages versioning
On Thu, Oct 31, 2013 at 11:26:27AM -0700, Anatol Pomozov wrote: > Hi > > > The sha1 is useful to people who need to quickly tell developers which > > version they are running when they're from git. Removing it is a bad > > idea. > > You can get the commit from the version number even without the SHA1, > something like: > > git log --oneline $VERSION..$BRANCH | tail -n $REVISION | head -n 1 > > Where $BRANCH is the one used in PKGBUILD (usually it is HEAD). This is not always true. Because of the branched, non-linear nature of git, you could have two 'version' that are the same with different SAH1s. The SHA is important in the version. > > > Anyway VCS-package users suppose to follow HEAD version closely. In > those rare cases when a user sees problem in no-release non-HEAD > version and tries to contact upstream developers I bet the first > question from the developers will be "Could you please update to HEAD > and see if the problem still exists?". Yes, they will, but for bisecting where the problem is, you could really be happy for a SHA. Thanks, -- William Giokas | KaiSforza | http://kaictl.net/ GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF pgpjp50mm5bHP.pgp Description: PGP signature
Re: [aur-general] Revise VCS packages versioning
On Thu, Oct 31, 2013 at 09:17:41PM +0100, Uwe Koloska wrote: > Hello, > > Am 31.10.2013 16:09, schrieb Jerome Leclanche: > > The main issue with -git versioning is the inconsistency. > > I don't think so. I think the main issue with git versioning (regarding > package versions) is its non monotonic trait. Thing is, there are really only two types of -git versioning: * Those with tags * Those without Each increases (or should, if the developer has any sense) as time goes forward, the only real difference is between the two, which can be easily solved by using epochs. And saying they're ugly is no damn excuse. > > I'm not suggesting we drop the pkgver function (nobody is). I'm saying > > we need a standardized pkgver script that outputs consistent, > > compatible results between tagged and non-tagged git repos, and > > recommend that as the proto. > > IMHO what's really missing, are requirements, that describe what the > version number has to be like *and* for what purpose! With this > requirements the developer is able to craft a pkgver function that is > suited for the used repository. And sure, every developer will be happy > about some useful patterns like "if the repository has no tags, use '0' > instead of a tag part". Package versions only need to be comparable to those of the package, not to other packages. Epochs can be used when version styles change. It's what they were intended to be used for. > > AFAIS there are the following requirements for version numbering: > * the version number must be monotone with respect to > ** newer commits > ** newer package number > * the version shall be "short" > > If there are other requirements (like "must follow semantic versioning > scheme" or "must combine package and upstream version (how?)"), they > should be stated clearly and with a reason. The pkgver should not contain any arch-specific information. If you look at the manual page, the pkgver is soleley for the upstream version, the pkgrel is for Arch releases, rebuilds or changes. > > Just my 2 cents. > > Thank you for listening > Uwe Thanks, -- William Giokas | KaiSforza | http://kaictl.net/ GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF pgpQgTcIBHNWT.pgp Description: PGP signature
Re: [aur-general] Long check() function in AUR packages
On Fri, Nov 22, 2013 at 01:00:32PM -0800, Anatol Pomozov wrote: > Hi, > > I am a big proponent of using automation testing. Tests saved me many > times at my $dayjob projects. That is why I strongly believe that > every arch package should have check() function - it is better find a > problem at build time, rather than get a crash while running the > application. > > But some projects have quite large test suites. v8,rethinkdb,tup-git > are examples - their tests take 10 minutes or even more. Some AUR > users complain that it is too long. Even worse - there can be flaky > tests that work fine for me but fail for some users. > > What is the best practices in this situation? I see a few possible answers: > 1) Tell users relax and enjoy running tests. Tests are for their own good. > 2) Tell users to disable (!check) option in /etc/makepkg.conf > 3) Maybe AUR install scripts (like yaourt) should not run tests at > installation time? Or at least make it configurable? > > What do you think is the best option? This is a user issue. If their setup doesn't pass the tests, then there is a very good chance that it won't work. If they're too lazy to run the tests, they can skip them either in the config or with a makepkg option. If they're using an install script like yaourt...I'm not going to touch it. I would keep the tests in your packages. I maintain the git-git package, and it contains quite a long test suite. It's enabled because when using development or unsupported software, you should test the crap out of it, regardless of the length. If a user has it fails, they either risk running likely broken sotware. Thanks, -- William Giokas | KaiSforza | http://kaictl.net/ GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF pgp8lcEI3HUXZ.pgp Description: PGP signature
Re: [aur-general] AUR 3.0.0 released
On Thu, Jun 05, 2014 at 09:28:15AM +0200, Lukas Fleischer wrote: > On Thu, 05 Jun 2014 at 09:08:48, Florian Bruhin wrote: > > * Lukas Fleischer [2014-06-05 09:03:29 +0200]: > > > Note that this issue will vanish soon anyway since the next major AUR > > > release will provide Git repositories for all AUR packages. You will no > > > longer need to create source tarballs. > > > > That sounds intresting! Is there some kind of specification or some > > more notes regarding this? I wonder how permissions/merges/etc. will > > be dealt with. > > > > Check [1] for some of the implementation details. On top of that, looking directly at permissions, git only tracks the executable bit, so the only permissions that git knows of for regular files is 755 and 644. As a demonstration:: $ git ls-files x $ ls -l -rw-r--r-- 1 wgiokas users 0 Jun 5 02:47 x $ chmod u+x x $ ls -l -rwxr--r-- 1 wgiokas users 0 Jun 5 02:47 x $ git diff diff --git a/x b/x old mode 100644 new mode 100755 > > > Florian > > > > -- > > http://www.the-compiler.org | m...@the-compiler.org (Mail/XMPP) > > GPG 0xFD55A072 | http://the-compiler.org/pubkey.asc > > I love long mails! | http://email.is-not-s.ms/ > > [1] https://mailman.archlinux.org/pipermail/aur-dev/2014-June/002770.html -- William Giokas | KaiSforza | http://kaictl.net/ GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF pgpeemF0jzUdR.pgp Description: PGP signature
Re: [aur-general] Compiling emacs lisp files
On Tue, Dec 18, 2012 at 08:37:43PM +0100, Mika Fischer wrote: > Hi, > > I'm currently maintaining the ninja package on the AUR [1]. Recently, > there has been an issue about which I'd like to ask for your advice: > > ninja contains an files for emacs to support edititng the rules files > of ninja. A user suggested that I compile the provided .el file to an > .elc file. I did that, but then other users complained about the > build-dependency on emacs. Now another user suggested that in the > PKGBUILD, I should check whether emacs is installed and only then > compile the .el file. I'm not totally opposed to this, but it feels a > bit strange that the package is different, depending on the system > it's built on. > > What would you do in this situation? I would just simply comment out the emacs stuff and leave a note for users that want to compile that in. Or you can do it the other way and put in the emacs stuff, uncommented, and users have to comment it out themselves. -- William Giokas | KaiSforza GnuPG Key: 0xE99A7F0F Fingerprint: F078 CFF2 45E8 1E72 6D5A 8653 CDF5 E7A5 E99A 7F0F pgp9WDlvlJO4K.pgp Description: PGP signature
Re: [aur-general] Thunderbird Aurora
On Wed, Jan 02, 2013 at 06:53:10AM -0300, Agustin Ferrario wrote:
> Hi Everyone..
> I'm a new user on Arch Linux from Argentina but I want to start
> contributing. I updated the thunderbird-aurora
> <https://aur.archlinux.org/packages/thunderbird-aurora/> PKGBUILD,
> but i don't know what to do. I can adopt the package, since it's
> orphan or make a new aur called thunderbird-earlybird since it's the
> correct name for the package (the channel it's called earlybird).
>
> And a happy 2013 for everyone!
First off, welcome, and a happy new year to you. Just a comment:
> # Manteiner: py_crash
> # Based on kang's thunderbird-aurora
>
> pkgname=thunderbird-earlybird
> pkgver=19.0a2
> pkgrel=latest
> pkgdesc="Standalone Mail/News reader - Earlybird channel"
> arch=('i686' 'x86_64')
> license=('MPL' 'GPL' 'LGPL')
> url="http://www.mozilla.org/thunderbird";
> depends=('alsa-lib' 'cairo' 'dbus-glib' 'desktop-file-utils' 'fontconfig'
> 'freetype2' 'gtk2' 'hicolor-icon-theme' 'hunspell' 'libevent' 'libjpeg'
> 'libmng' 'libpng' 'libvpx' 'libxt' 'mozilla-common' 'nspr' 'nss'
> 'shared-mime-info' 'sqlite3' 'startup-notification')
> optdepends=('libcanberra: for sound support')
> provides=("thunderbird=$pkgver")
> replaces=("thunderbird-aurora")
> install=$pkgname.install
You do not put install files in the source array, so delete the
$pkgname.install from the source array and the corresponding sha512 sum.
(See `man 5 PKGBUILD')
> source=(http://ftp.mozilla.org/pub/thunderbird/nightly/latest-comm-aurora/thunderbird-$pkgver.en-US.linux-$CARCH.tar.bz2
> $pkgname.desktop
> $pkgname.install)
> sha512sums=(`wget ${source/ta*}checksums -qO - | grep bz | grep 512 | cut -d
> " " -f1`
>
> 'a36bb5710b9cd6637cf6f538808e2fba8c99fdd1d486446ff9ee8094ca30b5592c17b3e808cae1da7ff2b28123f54902ed4ee1501585a8dcfc54d581588638d3'
>
> 'a9d557884e3d5fac343124cfc4202425f6d4585527fc035a42c923043d34a628692ea2f3d68144e1c0b5a44b6bccfc000c3b50816abfa10f865fbe5470d05746')
> package() {
> mkdir -p "$pkgdir"/{usr/bin,opt}
> cp -a thunderbird "$pkgdir/opt/$pkgname"
> ln -s /opt/$pkgname/thunderbird "$pkgdir/usr/bin/$pkgname"
> for i in 16x16 22x22 24x24 32x32 48x48 256x256; do
> install -Dm644 thunderbird/chrome/icons/default/default${i/x*/}.png
> "$pkgdir/usr/share/icons/hicolor/${i}/apps/$pkgname.png"
> done
> install -Dm644 $pkgname.desktop
> "$pkgdir/usr/share/applications/$pkgname.desktop"
> rm -rf "$pkgdir/opt/$pkgname/dictionaries"
> ln -sf /usr/share/hunspell "$pkgdir/opt/$pkgname/dictionaries"
> }
>
To me it looks like you just changed the name. I would simply send an
email to arch-general asking for a TU to merge the thunderbird-aurora
package and this one.
Thank you,
--
William Giokas | KaiSforza
GnuPG Key: 0xE99A7F0F
Fingerprint: F078 CFF2 45E8 1E72 6D5A 8653 CDF5 E7A5 E99A 7F0F
pgp99YBGoPrvO.pgp
Description: PGP signature
[aur-general] Delete Request: tp_smapi-builder
This package[0] has been in the AUR for almost a year and a half, and the maintainer posted in the comments that it should be deleted then disowned the package. [0] https://aur.archlinux.org/packages/tp_smapi-builder/ Thank you, -- William Giokas | KaiSforza GnuPG Key: 0xE99A7F0F Fingerprint: F078 CFF2 45E8 1E72 6D5A 8653 CDF5 E7A5 E99A 7F0F pgp3b_Ve8U5BR.pgp Description: PGP signature
Re: [aur-general] Please remove broadcom-sta-dkms
On Fri, Feb 08, 2013 at 04:27:59AM +0100, Armin K. wrote: > On 02/08/2013 04:25 AM, Daniel Micay wrote: > >On Thu, Feb 7, 2013 at 10:17 PM, Armin K. wrote: > >>On 02/08/2013 01:37 AM, Evangelos Foutras wrote: > >>> > >>>On 08/02/13 00:35, Armin K. wrote: > >>>> > >>>>On 02/07/2013 10:36 PM, Evangelos Foutras wrote: > >>>>> > >>>>>On 7 February 2013 23:26, Armin K. wrote: > >>>>>> > >>>>>>Please remove my package [1]. > >>>>>> > >>>>>>https://aur.archlinux.org/packages/broadcom-sta-dkms > >>>>> > >>>>> > >>>>>What's the reason for deletion? > >>>>> > >>>> > >>>>I don't want my package to be there. > >>> > >>> > >>>That isn't sufficient reason for removal. If you're no longer interested > >>>in a package you have the option to disown it. > >>> > >> > >>Wow, I don't have the right to request delete for MY OWN package. > > > >The thing is that it's not *your package*. The maintainer of a package > >doesn't have ownership over it, they're just maintaining it. When you > >contribute to an open-source project you can't just decide to take > >your toys and go home. > > > >There probably is a valid reason to have it removed, but the TU needs > >to know that before they delete it. > > > > Mhm, so by uploading it myself it's not my own package anymore? ... > Seems legit. :D I just want to get it removed, I don't want my work > to be shared with someone who doesn't respect it ... That's all. So disown it, let it be someone elses, hand it off to someone, don't just delete it. -- William Giokas | KaiSforza GnuPG Key: 0xE99A7F0F Fingerprint: F078 CFF2 45E8 1E72 6D5A 8653 CDF5 E7A5 E99A 7F0F pgpifJUUxLktw.pgp Description: PGP signature
Re: [aur-general] Request to remove/orphan the AUR package "aspell-nb"
On Sat, Feb 09, 2013 at 03:33:30AM +0100, Third3ye wrote:
> The AUR package "aspell-nb" doesn't build, is outdated and most likely
> abandoned. I suggest to either remove it or orphan it so that I can replace
> the PKGBUILD with an edited version that actually builds:
>
Alright, time to go on a quick run down of how this pkgbuild is outdated
as heck:
> pkgname=aspell-nb
> _pkgname=aspell-no
> pkgver=0.50
> pkgrel=2
> pkgdesc="Norwegian Bokmål dictionary for aspell"
> url="http://aspell.net/";
> license="GPL"
> depends=('aspell')
> arch=('i686' 'x86_64')
> source=(ftp://ftp.gnu.org/gnu/aspell/dict/nb/${_pkgname}-${pkgver}-${pkgrel}.tar.bz2)
> md5sums=('b24b20ad02ce2a569f71f949b48823cc')
pretty much okay. till here.
>
> build() {
>cd $startdir/src/${_pkgname}-${pkgver}-${pkgrel}
DO NOT USE $startdir. It it outdated and breaks on peoples systems that
have a BUILDDIR specified.
>./configure
>/usr/bin/make || return 1
Don't do this. Makepkg will do this itself. These || return 1 things are
totally unneeded.
>/usr/bin/make DESTDIR=$startdir/pkg install
Again, more startdir. Also, this should be part of a package() function,
nto a build function. And in pacman 4.1, the $pkgdir is made
unread/writeable before the package function is called (Allan, correct
me if this is just your working branch) so calling $pkgdir (or
$startdir/pkg) will just fail if it's called before a `package()`.
> }
Here's what I'd make it look like:
pkgname=aspell-nb
pkgver=0.50.1
pkgrel=2
pkgdesc="Norwegian Bokmål dictionary for aspell"
url="http://aspell.net/";
license="GPL"
depends=('aspell')
arch=('i686' 'x86_64')
source=(ftp://ftp.gnu.org/gnu/aspell/dict/nb/${pkgname}-${pkgver}-0.tar.bz2)
md5sums=('b24b20ad02ce2a569f71f949b48823cc')
build() {
cd $srcdir/${pkgname}-${pkgver}-0
./configure
make
}
package() {
cd $srcdir/${pkgname}-${pkgver}-0
make DESTDIR=$pkgdir install
}
And that builds fine.
ps: next time give us the errors you got when trying to build this.
Thanks,
--
William Giokas | KaiSforza
GnuPG Key: 0xE99A7F0F
Fingerprint: F078 CFF2 45E8 1E72 6D5A 8653 CDF5 E7A5 E99A 7F0F
pgpYzuZau2w89.pgp
Description: PGP signature
Re: [aur-general] Request to remove/orphan the AUR package "aspell-nb"
On Sat, Feb 09, 2013 at 02:13:41PM -0500, Limao Luo wrote:
> On 02/09/2013 06:36 AM, Johannes Löthberg wrote:
> >On 02/09/2013 03:33 AM, Third3ye wrote:
> >>The AUR package "aspell-nb" doesn't build, is outdated and most
> >>likely abandoned. I suggest to either remove it or orphan it so
> >>that I can replace the PKGBUILD with an edited version that
> >>actually builds:
> >>
> >>pkgname=aspell-nb _pkgname=aspell-no pkgver=0.50 pkgrel=2
> >>pkgdesc="Norwegian Bokmål dictionary for aspell"
> >>url="http://aspell.net/"; license="GPL" depends=('aspell')
> >>arch=('i686' 'x86_64')
> >>source=(ftp://ftp.gnu.org/gnu/aspell/dict/nb/${_pkgname}-${pkgver}-${pkgrel}.tar.bz2)
> >>
> >> md5sums=('b24b20ad02ce2a569f71f949b48823cc')
> >>
> >>build() { cd $startdir/src/${_pkgname}-${pkgver}-${pkgrel}
> >>./configure /usr/bin/make || return 1 /usr/bin/make
> >>DESTDIR=$startdir/pkg install }
> >>
> >>Please let advise if this PKGBUILD isn't following AUR guidelines.
> >>
> >>Thank you.
> >Just a small note, pkgrel is the arch specific release number of a
> >package's specific version, so you shouldn't use it in the source URL.
> >What you currently have in the pkgrel (2) actually belong in pkgver
> >(0.50-2)
>
> You can't use hyphens in the pkgver; makepkg won't accept it as valid.
You are also only supposed to use ${foo} when it helps make updating
easier. This could easily work against that. Just make it a number, or
have a _pkgver variable that you use in the URL if you need that.
--
William Giokas | KaiSforza
GnuPG Key: 0xE99A7F0F
Fingerprint: F078 CFF2 45E8 1E72 6D5A 8653 CDF5 E7A5 E99A 7F0F
pgpy_T_T7jZdw.pgp
Description: PGP signature
Re: [aur-general] Making Tor Browser Bundle PKGBUILD
On Sun, Feb 10, 2013 at 08:21:30PM -0300, Agustin Ferrario wrote: > Hi everyone, > I'm making a PKGBUILD for the Tor Browser Bundle > (https://github.com/py-crash/tor-browser) based on the the Russian > version available on aur: > https://aur.archlinux.org/packages/tor-browser-ru. And i have two > questions: > 1. Since I'm making the English version the correct name should be > tor-browser or tor-browser-en? > > 2. In the .install file > (https://github.com/py-crash/tor-browser/blob/master/tor-browser > <https://github.com/py-crash/tor-browser/blob/master/tor-browser.install>.install > <https://github.com/py-crash/tor-browser/blob/master/tor-browser.install>) > there's: > # chown -R 1000:1000 /opt/tor-browser/ > > Since you have to own the files in order to execute them, but i > think this won't work in a multiuser environment (as linux should > be). Anyway to sort it? There's already a tor-browser-en[1] in the AUR. [1]: https://aur.archlinux.org/packages/tor-browser-en -- William Giokas | KaiSforza GnuPG Key: 0xE99A7F0F Fingerprint: F078 CFF2 45E8 1E72 6D5A 8653 CDF5 E7A5 E99A 7F0F pgpwkLvAdx8cl.pgp Description: PGP signature
Re: [aur-general] deletion request
On Sat, Feb 23, 2013 at 11:50:11PM +0100, David Adler wrote: > On Sat, Feb 23, 2013 at 10:40 PM, Johannes Löthberg > wrote: > > On 02/23/2013 10:28 PM, atilla ontas wrote: > >> > >> If i get it right, you want to create directories and copy files. Then why > >> not use "install" command? > >> Like; > >> > >> install -d -m 755 $srcdir/foo-version/src/foo.so > >> $pkgdir/usr/lib/foo/foo.so > >> > >> > >> 2013/2/23 David Adler > >>> > >>> > >>> Just copying. As simple as it sounds, I didn't find a simple solution, > >>> but it's not unlikely that I'm missing the obvious. > >>> > >>> regards > >>> > > > > My thoughts exactly. > > That would be >400 install invocations for >400 files&dirs? > > For a similar case, Stackoverflow comes up with solutions > involving autotools[1], though I think that would not be > worth the effort. > > For users it is about as simple to download the preset and > extract the tarball as it is to first install it and then recursively > copy a directory from /usr/share. > They'll need the preset in a writable location anyway. > > Unless there is a really simple one-liner, I don't feel inclined > to make that preset an installable tarball again. > > From what I read, recursively installing directory trees in > a "don't look and just install everything"-manner is not > recommended anyway, and all non-recursive sulutions > seem to involve some effort to adapt the build system > every time the directory tree changes. > > [1] > http://stackoverflow.com/questions/6395148/install-data-directory-tree-with-massive-number-of-files-using-automake You know, you could just user /usr/bin/cp -r and some chmod magic if you actually need that. -- William Giokas | KaiSforza GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF pgp1FOyEMqYXY.pgp Description: PGP signature
Re: [aur-general] User ban request --- can I get a response, please?
On Tue, Mar 05, 2013 at 11:10:16PM -0500, Daniel Wallace wrote: > On Tue, Mar 05, 2013 at 11:05:07PM -0500, Limao Luo wrote: > > And he's back, with another account [2] with an address on a > > different website (rmqkr.net, which redirects to the disposable > > email site 10minutemail.com). This is a waste of my time. Can > > someone respond to this thread so I know that a TU even knows about > > this? Also, I guess it's really a bot, since the flagging is done > > across congruent intervals (this time it's 1 minute between flags). > > > > [2] https://aur.archlinux.org/account/9Pwrxb1/ > > We are well aware of it. > https://mailman.archlinux.org/pipermail/aur-dev/2013-February/002371.html > > The problem is every time I suspend an account (after a patch that was > applied yesterday) now he gets logged out, the problem is it creates a > new account and starts tagging them out of date again. Captchas, man. Captchas. I know it will very very slightly inconvenience some people that have to flag a few packages out of date at a time, but really, it would only save us from crap like this. -- William Giokas | KaiSforza GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF pgppJiMYhWcrR.pgp Description: PGP signature
Re: [aur-general] TU application from graysky
On Mon, Mar 11, 2013 at 05:58:27PM -0400, member graysky wrote: > Try two using gmail to send an clearsigned message to this list... Still bad. Try using a client, like Thunderbird or Mutt. I can only vouch for Mutt in respect to signing well. > > Hi All. Inspired by Allan's talk @ SINFO XX, I decided to throw my > hat into the ring and formally apply to be a TU. My linux history > started with RH and SUSE over a decade ago. I discovered Debian and > Ubuntu after not caring for either of the aforemened very much. I > found myself wanting more control and up-to-date repos and eventually > stumbled upon Arch. I find it that both its underlying philosophies, > and its community resonated with me, and I have been a happy Arch user > ever since. > > I have an interest in giving back to the Arch Community though > maintaining some packages in [community]. Listed below are a few of > my contributions for those of you who don't recognize me from the bbs > or from other interactions. I reached out to Xyne who kindly agreed > to sponsor my candidacy for TU. > > *Maintains an unofficial repo for >2 years now (http://repo-ck.com) > whose main purpose is hosting linux-ck and related packages. > *Maintains ~50 PKGBUILDs within the AUR; some legacy others of my own > creation. > *Wiki contributions, both original content, and standardizing many > popular pages; member of Wiki Maintenance Team. > *Contributed several open-source utils back to the community. > https://github.com/graysky2/modprobed_db > https://github.com/graysky2/profile-sync-daemon > https://github.com/graysky2/profile-cleaner > https://github.com/graysky2/backdrop-randomizer > *Active contributor to Arch bugs. > *Closely related to several upstream projects including: monitorix and > the ck patchset. > *Active member on the bbs; usually helpful ;p And good luck! I've looked at the CK patches for the kernel, and the only thing that's kept me from using them is the fact that I use mainline kernels as recommended for btrfs. Thanks, -- William Giokas | KaiSforza GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF pgpCqRT9MGK9D.pgp Description: PGP signature
Re: [aur-general] TU application from graysky
On Mon, Mar 11, 2013 at 06:11:50PM -0400, member graysky wrote: > On Mon, Mar 11, 2013 at 6:04 PM, William Giokas <1007...@gmail.com> wrote: > > On Mon, Mar 11, 2013 at 05:58:27PM -0400, member graysky wrote: > >> Try two using gmail to send an clearsigned message to this list... > > > > Still bad. Try using a client, like Thunderbird or Mutt. I can only > > vouch for Mutt in respect to signing well. > > Actually, when I attached the message.txt.asc to the message, it > verified for me on the shell. Is that not the case for you? > > % gpg --verify copy_paste_from_ML.txt > gpg: Signature made Mon 11 Mar 2013 05:56:46 PM EDT using RSA key ID 5EE46C4C > gpg: Good signature from "graysky " Yes, that worked. (Should probably start using an email client...) -- William Giokas | KaiSforza GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF pgpHeoHws5HtX.pgp Description: PGP signature
[aur-general] Using git as a backend for the AUR
All, So in my spare time I was thinking about the AUR and how it could be better. Back in January I commented on a bug[1] about integrating the AUR and git to have a powerful, robust backend for the AUR. I think that the original idea of creating one massive repository was inherently flawed for most users, as it requires that the entire repository be cloned, and that is no trivial task for people with only moderate internet speeds. Were it similar to the way the official repositories git setup is, then it would be okay for fetching, but using single repositories for each project would make access control much less of a nightmare. At the moment I have no experience with PHP or messing with the AUR, but I have been playing around with git and using it to track packages and the like, as well as some minimal experience with access control and git. Currently, this is kind of the roadmap I see in my head: * Set up access controls for the AUR users to access over ssh using keys. While I could see this being somewhat arduous, it shouldn't be terribly hard to automate or set up. Something like gitolite or whatever should make it simpler. * Each repository on the server would contain a single package (if someone decides to do a split package on the AUR it would contain the whole set of packages), allowing for multiple users to have push access and maintain the packages. * The repositories would be limited to 5M, unless given special permission (certain kernel packages with lots of massive configuration files) which should make enough room for the needed files, while helping to enforce the idea of not putting retrievable sources in the source tarball. I did some quick math using the number of packages on the AUR right now, and if every repo used that 5M limit, it would require a bit over 200G. Granted, I doubt that this limit would be reached for most packages. * With the repository set up, give maintainers a week or so to upload history for their packages (in case they already keep their repos in this set up), and new packages would get put directly into a new repo. * Once the week for transition is over, begin moving all of the current packages in the AUR to the git format. This basically concludes setting up the git stuff, which I have done on a local machine on a very small scale (5 packages) in the past. One thing I was thinking of was the use of `makepkg -S` tarballs still being available. cryptocrack came up with a good point, that just simply copying things over could overwrite the .git directory in the designated directory. I don't think that would be too hard to get around, but I'm no expert. I wrote a quick and dirty script that extracts and commits to the respective repository. Currently, almost no packages use a .changelog file, but there could be some minimal parsing done of a packages .changelog file to craft a git commit message from a tarball. Obviously there needs to be some kind of security check, but that could be done by the frontend using the system we have now for source tarballs. At the moment, I am unsure exactly how the AUR parses the PKGBUILDs it receives, but I'm sure that this could easily be adapted to the git system. One major advantage to having the AUR managed this way is that it would allow users to check for updates on the AUR without the need for complex helpers outside of git. Secondly, it would make mirroring the AUR, or just parts of the AUR extremely easy. In case something happens to the AUR, people can still get their packages and maintainers can still update them very easily using git. It would also still allow people to grab tarballs of the current master branch. This way git is not a requirement to use the AUR, it just makes things a butt ton easier. Also, it would allow users to see the entire source of the package, not just the PKGBUILD, similar to how the official repository works, just that things would be in distinct git repositories not branches. I would really like to see this kind of thing come to fruition, and if anyone would be willing to help, then please say so. Pardon my scattered thoughts, -- William Giokas | KaiSforza GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF [1]: https://bugs.archlinux.org/task/23010 pgpRY5pywKHsq.pgp Description: PGP signature
Re: [aur-general] "Registration form is disabled' when updating profile
On Tue, Mar 26, 2013 at 07:12:29AM +0100, Johannes Löthberg wrote: > Hey, > > Not sure if this is the right ML to send this to, but when trying to > update my profile I get a message saying > "The registration form is currently disabled due to a sustained spam > attack. Sorry for the inconvenience -- we hope to be back up soon!" > which seems a bit odd ;) I'll refer you to the ml archives. There's a good reason for this. It should be up in a bit. Thanks, -- William Giokas | KaiSforza GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF pgpj0nLnu9Bi_.pgp Description: PGP signature
Re: [aur-general] pacman 4.1 (makepkg 4.1) git pkgver autobump problem
On Wed, Apr 03, 2013 at 10:21:12AM -0700, Tai-Lin Chu wrote: > The problem: > according to archwiki, to autobump pkgver, pkgver should be empty and > pkgver() is provided. > However, if we package it, the version number is empty, so AUR wont accept it. > > The Question: > 1. is it a bug? > 2. should aur be updated to allow empty pkgver? > > My idea: > if pkgver=AUTO, then pkgver() must be provided and it will be called. > otherwise, pkgver must be valid version number. This would fail miserably though as soon as someone updates their package without getting a new one from the AUR (which is kind of the point of a -git package), and no matter what is in the pkgver field, it will be updated. Also, what wiki page (and revision) did you see this about pkgver needing to be empty? (I just want to correct whatever it is I put in there that is wrong) Thanks, -- William Giokas | KaiSforza GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF pgpqYUrC0Iow1.pgp Description: PGP signature
Re: [aur-general] pacman 4.1 (makepkg 4.1) git pkgver autobump problem
On Wed, Apr 03, 2013 at 02:29:45PM -0500, Doug Newgard wrote: > > > Date: Wed, 3 Apr 2013 15:24:06 -0400 > > From: luoli...@gmail.com > > To: aur-general@archlinux.org > > Subject: Re: [aur-general] pacman 4.1 (makepkg 4.1) git pkgver autobump > > problem > > > Under Guidelines: > > > "As of pacman 4.1, pkgver gets some special treatment. If pkgver is > > > empty, makepkg looks for a pkgver() function. This can be one of many > > > things, outlined below:" > > That's definitely not the case; pacman-git [1], for example, has a > > non--empty pkgver, has a pkgver() provided, and the pkgver variable > > updates just fine when I build it. It doesn't have to be empty (at least > > atm). Yeah. I just wanted to know what to fix. > > > > > > [1] https://aur.archlinux.org/packages/pa/pacman-git/PKGBUILD > > Yes, I'm aware of that. If you read the quote of the previous email, > KaiSforza was asking where the incorrect info is and I was pointing him to > it. Thanks, fixed it. -- William Giokas | KaiSforza GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF pgpLFoBsIz7im.pgp Description: PGP signature
[aur-general] Merge Request: deluge-stable -> deluge-stable-git
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, -- William Giokas | KaiSforza GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF pgprnxDrQ3Tci.pgp Description: PGP signature
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
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
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
Re: [aur-general] Fwd: please add -depth 1 to makepkg git clone
Did any of you read my email? Getting a shallow clone is simply not
possible, unless you want to continue to write this boilerplate code.
These large transactions are a one-time action, and I see no harm.
Thank you,
William Giokas
On Apr 6, 2013 8:47 AM, "Rashif Ray Rahman" wrote:
> On 6 April 2013 15:25, Tai-Lin Chu wrote:
> > yes, i agree with you. But as a person who commits patches and needs
> > to test, I think using --depth 1 makes initial cloning faster and
> > decreases the load of remote git server. Think about this 100 people
> > clones vlc.git with shadow (around 600mb) vs without shadow (around
> > 1mb)... its not just about whether you care it or not; please
> > preserve resources of other projects.
>
> I personally like small checkouts. If I am testing software, I don't
> really need much of its history, and I don't need to be able to commit
> anything. If I'm developing software, I'll have a separate directory
> with full checkouts anyway. VCS differences apply, though.
>
> There is really no pragmatic difference between copying with cp and
> exporting (Subversion) or cloning (Git) a VCS repo, except when you
> don't know what you're doing. If you make changes, a cp may not copy
> what you intend to copy, or vice-versa with export/clone.
>
> IMO, keeping checkouts lean and mean for building experimental
> packages is a good idea. VCS repos take a lot of space, and in the
> event you want to maintain package repos with them, you'd like the
> extra space saved.
>
> However, we need equivalent methods for every VCS we care to support
> ('depth' doesn't mean the same thing in svn, for instance), and we
> need to provide a mechanism to choose to keep depths (so that you may
> choose to reuse repos for your own use with full history and what
> not).
>
>
> --
> GPG/PGP ID: C0711BF1
>
Re: [aur-general] Fwd: please add -depth 1 to makepkg git clone
On Sat, Apr 06, 2013 at 12:25:37AM -0700, Tai-Lin Chu wrote: > >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. > > What is not enough? cp has option to reserve everything. Doesn't matter. cp does nothing with checksums, whereas git will preserve every byte, and it literally can't go bad (or if it does on the extremely off chance, it will simply stop the build). Maybe rsync, you say? That still isn't cryptographically secure. Using git, you can guarantee that the files you are building from are exactly the same as anyone else, which is what we want with makepkg. > > >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. > > Please read document for depth=1 and shallow clone. When we create a > package, we only need the snapshot at that time; we rarely revert any > commit. After we do shallow clone, we can still pull, and remake > package. I really dont understand your reason for " to support the > majority of of users we clone the whole thing" because shallow clone > is sufficient. There's minimal point to this. As I've said numerous times, it does not allow you to clone the shallow bare repo, which is what makepkg gets when it fetches git sources. > > >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... > yes, i agree with you. But as a person who commits patches and needs > to test, I think using --depth 1 makes initial cloning faster and > decreases the load of remote git server. Someone submitting patches and testing should simply link to their development repo in their SRCDEST, seeing as you already have the repo. > Think about this 100 people > clones vlc.git with shadow (around 600mb) vs without shadow (around > 1mb)... its not just about whether you care it or not; please > preserve resources of other projects. > If they're all doing it at the same time, cloning fresh repositories, then yes. that may be an issue on some large projects with very terrible servers. Also, if you're worried about server load, mirror the repository yourself so people can gake the load off of the host server. This is the joy of a DVCS. Once again, you can continue to use the worthless biolerplate code from the old vcs PKGBUILDs, but this is pretty much worthless to be honest, and will only fly in the face of readability. Thank you, -- William Giokas | KaiSforza GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF pgpBrcBtNMe8H.pgp Description: PGP signature
Re: [aur-general] Fwd: please add -depth 1 to makepkg git clone
On Sat, Apr 06, 2013 at 11:10:52AM -0700, Tai-Lin Chu wrote: > >Doesn't matter. cp does nothing with checksums, whereas git will > >preserve every byte, and it literally can't go bad (or if it does on the > >extremely off chance, it will simply stop the build). Maybe rsync, you > >say? That still isn't cryptographically secure. Using git, you can > >guarantee that the files you are building from are exactly the same as > >anyone else, which is what we want with makepkg. > > cp and git clone are exactly the same. see cp source code, and if the > file is corrupted, then you have even bigger problems. > In general very not likely. (i mean if this happen, 1. kernel has > problem 2. your disk goes bad) > stackoverflow confirmed the result. > http://stackoverflow.com/questions/852561/is-it-safe-to-use-a-copied-git-repo > > >There's minimal point to this. As I've said numerous times, it does not > >allow you to clone the shallow bare repo, which is what makepkg gets > >when it fetches git sources. > > aren't we talking about cp? Here, run this quick script and see what you can do with it: #!/bin/bash mkdir -p /tmp/dumb/ pushd /tmp/dumb/ echo "==> Cloning into a bare repository..." git clone --verbose --bare git://github.com/falconindy/cower.git barerepo echo "==> Creating copy of this repo using cp..." cp -r -a /tmp/dumb/barerepo /tmp/dumb/barecp echo "==> Done" echo "==> Creating copy of this repo using git clone..." git clone --verbose /tmp/dumb/barerepo barerepocopy echo "==> Done" If you look at the one generated by the 'cp' command you will see that it is totally missing the actual files, and only contains (duh) the bare repository files. This is utterly worthless for building, and also, if there is disk failure, makepkg will still try to build. Looking into the one generated by the git clone, you'll see that it has all of the correct files and can actually be built. > > >If they're all doing it at the same time, cloning fresh repositories, > >then yes. that may be an issue on some large projects with very terrible > >servers. Also, if you're worried about server load, mirror the > >repository yourself so people can gake the load off of the host server. > >This is the joy of a DVCS. > > I dont have a server, and this is not practical. certainly using git > pkgbuild with shallow clone is far easier than what you mentioned. Not at all. See the script above. !next -- William Giokas | KaiSforza GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF pgpvJVIwKsUPA.pgp Description: PGP signature
Re: [aur-general] Fwd: please add -depth 1 to makepkg git clone
On Sat, Apr 06, 2013 at 12:26:14PM -0700, Tai-Lin Chu wrote: > @dave > I still cannot find any info regarding why we should not use depth 1. > do you mind pasting the link here? > thanks. https://mailman.archlinux.org/pipermail/pacman-dev/2012-March.txt Now curl and grep are your friends... > > On Sat, Apr 6, 2013 at 12:15 PM, Dave Reisner wrote: > > On Sat, Apr 6, 2013 at 3:11 PM, Tai-Lin Chu wrote: > > > >> ...what are you trying to test? > > > > > > Probably trying to replicate what makepkg does to show you why cp doesn't > > work. > > > > > >> mkdir -p /tmp/dumb/ > >> pushd /tmp/dumb/ > >> echo "==> Cloning into a bare repository..." > >> git clone --verbose git://github.com/falconindy/cower.git barerepo > >> echo "==> Creating copy of this repo using cp..." > >> cp -r -a /tmp/dumb/barerepo /tmp/dumb/barecp > >> echo "==> Done" > >> echo "==> Creating copy of this repo using git clone..." > >> git clone --verbose /tmp/dumb/barerepo barerepocopy > >> echo "==> Done" > >> > >> test this. of course --bare will give you different result... > >> > > > > And this is what makepkg uses so that the base repo takes up less space on > > disk and the tree doesn't need to be calculated. > > > > > >> ok here is a normal process that i mentioned: > >> > >> git clone --depth 1 git://github.com/falconindy/cower.git test > >> cp -a -r test test2 > >> // build with test2 > >> rm -rf test2 > > > > > > Please go back and search the pacman-dev list for why we aren't doing this > > -- it's clear that you posted the suggestion here before doing any amount > > of investigation into this. You aren't the first to suggest this, and you > > unfortunately won't be the last. > > > > -- William Giokas | KaiSforza GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF pgpVS54EAgsNJ.pgp Description: PGP signature
Re: [aur-general] Fwd: please add -depth 1 to makepkg git clone
On Sat, Apr 06, 2013 at 05:40:40PM -0700, Tai-Lin Chu wrote: > Thanks William. But I dont think the discussion is deep as what we > have right now. > Apparently allan miscalculates how much we can save on using shallow clone. > I tried linux/master yesterday, it is more like 600mb to 97mb. Okay, if you're going to be doing shallow clones, you may as well just get the dang tarballs. This is totally flying in the face of what the -git packages really are, development packages. Once you download it, you never have to again, just update it. If you've got a problem with the size, then somehow get a physical copy of it, or just take the time to get a revision, then keep it updated gradually. Thanks, -- William Giokas | KaiSforza GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF pgpquudqkKDCX.pgp Description: PGP signature
[aur-general] Merge python3-sphinx-hg into python-sphinx-hg
In order to keep naming consistent, please merge python3-sphinx-hg[0] into python-sphinx-hg[1]. I own both of the packages (the python3 one was disowned by the previous maintainer recently). Thanks, -- William Giokas | KaiSforza GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF pgpWnDpUW5I4A.pgp Description: PGP signature
Re: [aur-general] Confusing over .AURINFO usage
On Sat, May 04, 2013 at 11:29:07AM -0400, member graysky wrote: > On Sat, May 4, 2013 at 11:18 AM, Lukas Fleischer > wrote: > > > > Thanks, I get it. This definitely seems like something makepkg should > > > detect and handle automaticallyAre the .AURINFO files here to stay? > > > > Note that .AURINFO functionality will not be added to pacman/makepkg, > > unless the format is extended to work with split packages and all corner > > cases that we do not care about in the AUR. > > > > The idea is to start with an external tool to post process source > > packages and then extend this tool, as well as the underlying .AURINFO > > format, until we get something that is suitable for integration with > > makepkg. > > > > OK. I haven't tested this with split packages, but the attached patch > works with a non-split one for those too lazy to manually make the modified > src.tar.gz :p No. .AURINFO is for the AUR, not for makepkg or pacman. There is no reason that this should be handled by pacman right now. `makepkg -S` is for making source tarballs, not AUR packages, that is just something that it also works with. If you want .AURINFO in your source tarball, then add it to the source=() array. This was discussed three days ago on this same mailing list. Thanks, -- William Giokas | KaiSforza GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF pgpxECviqibrC.pgp Description: PGP signature
Re: [aur-general] SysV init file in package
On Sun, Jun 02, 2013 at 06:22:58PM +0200, xartii wrote: > Hi, > > I'm the maintainer of the psad [1] package in AUR. The package comes > with to init files, one for systemd and other one for SysV. As some time > has passed since the switch to systemd my question is, is it ok to > remove sysV init file from the package. Or should I keep it for > compatibility reasons. > > [1] https://aur.archlinux.org/packages/psad/ Technically you can just drop it. It may be a good idea to hang onto it in some version control system so people can get it again, but as official Arch packages drop them, I see no reason why AUR packages should keep them. Thanks, -- William Giokas | KaiSforza | http://kaictl.net/ GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF pgpSpA6YQzhs2.pgp Description: PGP signature
[aur-general] Status of the signoff reports?
All, Just wondering where the signoff reports for the [community-testing] repo went? I've noticed that for a few days I've been getting most aur-general emails, but no signoff reports. Thanks, -- William Giokas | KaiSforza | http://kaictl.net/ GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF pgpxDMpFSBMTI.pgp Description: PGP signature
Re: [aur-general] move split2flac-git to split2flac
On Sun, Jun 30, 2013 at 07:44:14AM -0400, graysky wrote: > Upstream has finally started tagging releases. Please replace the git > package with the standard one I just uploaded. Thanks! I see no reason to do this. Set up a good pkgver function using git describe and have it conflict with the non-git package, then they can coexist just fine. Thanks, -- William Giokas | KaiSforza | http://kaictl.net/ GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF pgpXeGcmwuZh_.pgp Description: PGP signature
