Re: [aur-general] TU Membership Application
On Wed, Nov 07, 2018 at 11:04:43PM -0500, Eli Schwartz via aur-general wrote: > Because their tarballs used to be insane. And giving you the tarball for > master is a regression they fixed, not an API they dropped. :p It's an API url they dropped. They moved it around and instead of 404'd they just left it broken. True though, probably github is not prone to things like this... > > It should be owned by root unless some process uses something like > install -o username -g groupname. Ah, I'm still not sure if the executable should setuid to update than when run as a user (although it shouldn't be able if it's just a script). > >> Looks like it just copies a couple python modules into a directory and > >> then creates a wrapper script to run them. What would you suggest > >> running in build(), exactly? > > > > I'm not entirely sure, I see that there's a buildscript using > > pyinstaller, although I'm not sure why exactly... > > Most likely in order to create some giant windows executable that ships > the entire python application runtime, plus the gam source code, in > order to spare Windows users the need to install Python. > I think you're right, but I'm still confused as to why there's a linux vaiant of it... https://github.com/jay0lee/GAM/blob/master/src/linux-build.sh Probably for the same reason as you pointed out though... -Santiago signature.asc Description: PGP signature
Re: [aur-general] TU Membership Application
On 11/7/18 10:44 PM, Santiago Torres-Arias via aur-general wrote: > It happened to me with gitlab and their releases url, which started > defaulting to "I don't recognize this branch parameter, so here's the > tarball for master"[1] Yes, gitlab is prone to bugs like this. :p gitlab also includes the version of git(1) inside the patch file, and moved the tarball endpoint for legitimately good reasons in https://gitlab.com/gitlab-org/gitlab-ce/issues/38830 Because their tarballs used to be insane. And giving you the tarball for master is a regression they fixed, not an API they dropped. :p >>> - I'm not sure if this would work when built in a chroot due to >>> those touch calls. >> ... >> Are you referring to the ones in package()? Not sure why upstream code >> needs such weird things but AFAICT it should not break just because of a >> chroot. >> > > Hmm, I see they are named as noupdatecheck and nobrowser. I assume these > are to store the program state and thus need be user read-writeable? > This is just speculation, hence the "I'm not sure". It should be owned by root unless some process uses something like install -o username -g groupname. >> Looks like it just copies a couple python modules into a directory and >> then creates a wrapper script to run them. What would you suggest >> running in build(), exactly? > > I'm not entirely sure, I see that there's a buildscript using > pyinstaller, although I'm not sure why exactly... Most likely in order to create some giant windows executable that ships the entire python application runtime, plus the gam source code, in order to spare Windows users the need to install Python. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [aur-general] TU Membership Application
> > - I noticed that you didn't add a LICENSE file for this package. > > This checks out, Artistic2.0 is a common license. Yes, my bad. For this and the rest of the licenses below I assumed it was the same case as MIT and such. > > - hib-dlagent: > > - I see that you backported a patch on this and ags. I was rather > > surprised to see that neither patches were added to new > > tags/releases. You could, however, cherry pick the commits rather > > than depending on the github api (which can change) to compute the > > diff for you. For this, you could use the git transport on > > makepkg. > > I don't see why you'd need the overhead of git for this, and that url is > not going to change. They "document" it here: > https://blog.github.com/2011-10-21-github-secrets/#diff-patch They are not even using an API stable url here. I hope it doesn't change, but it wouldn't be the first time I get biten by api's like this[1]. > They've provided it for a very long time specifically in order to let > people do this, they're not going to change the scheme and render it > useless for the very purpose it was created for. :p It happened to me with gitlab and their releases url, which started defaulting to "I don't recognize this branch parameter, so here's the tarball for master"[1] > > - I'm not sure if this would work when built in a chroot due to > > those touch calls. > ... > Are you referring to the ones in package()? Not sure why upstream code > needs such weird things but AFAICT it should not break just because of a > chroot. > Hmm, I see they are named as noupdatecheck and nobrowser. I assume these are to store the program state and thus need be user read-writeable? This is just speculation, hence the "I'm not sure". > > - After reviewing the package I doubt this doesn't need a build() > > step. Otherwise I'd label this package a -bin. This is something > > that we should take special consideration of, since we could be > > unwittingly be introducing binaries that aren't hardened when > > building> > Looks like it just copies a couple python modules into a directory and > then creates a wrapper script to run them. What would you suggest > running in build(), exactly? I'm not entirely sure, I see that there's a buildscript using pyinstaller, although I'm not sure why exactly... > > - I'm confused as to why gam.py needs to be put inside > > /usr/share/gam and add a .sh entrypoint for it in /usr/bin. The > > file seems to have a shebang and be executable... > I'm not sure what the script does either. gam.py does do: > > import utils > from var import * > > Which should really be explicit relative imports, but it's actually > legal in python2, and there doesn't seem to be any other reason to want > to cd to the directory, but the script does not cd there anyway. [1] https://gitlab.com/gitlab-org/gitlab-ce/issues/45507 signature.asc Description: PGP signature
Re: [aur-general] TU Membership Application
> >- I marked the package as out-of-date, as there appears to be a new > > version (3.1.4.15) as of almost two months ago. > > Long story short, that was pretty much exactly during the time when I > accidentally clobbered my urlwatch file. Thanks for bringing that up to me. > > >- I noticed that you didn't add a LICENSE file for this package. > > Artistic2.0 is a uncommonly used common license! > (/usr/share/licenses/common/Artistic2.0/license.txt) > > Yes, my bad. I was told about this on MIT, and I assumed this was the case for most licenses... > > - hib-dlagent: > >- I see that you backported a patch on this and ags. I was rather > > surprised to see that neither patches were added to new > > tags/releases. You could, however, cherry pick the commits rather > > than depending on the github api (which can change) to compute the > > diff for you. For this, you could use the git transport on > > makepkg. > > That would bring another dependency on git, though. I can surely do if if > it's more 'correct' but I wouldn't imagine that Github would change that API > anytime soon. > > Or would it be better to just carry the patch locally in the repo? True, I didn't consider the dependency on git. I'd say you could check it in. I do not agree with Eli that you should rely on api's like this to get a simple patch. It has been my experience that api's like this move around and leave you trying to debug weird errors. > > >- I noticed that you didn't add a LICENSE file for this package. > > Yikes, the project doesn't even have a license! I should have checked that > when I inherited it (the packager just slapped a GPL2 on it). Really, I had > just uploaded it so it wouldn't have been lost after the AUR 4 migration. > > I'll bug upstream about it. > > > - gam-git: > > ... > Of all the packages you had to click on that one. :( > > I know it doesn't really excuse it but gam is sort of a "WIP" because > it's... oddly written. I've been meaning to set aside some time to get some > patches in to make it more palatable for packaging. The patch is a complete > hack right now just to make the package "work" (when I inherited it it was > FUBAR). Yes, granted I'm rather confused when I read the repository and see things like build-linux.sh that pulls pyinstaller. I didn't know exactly what of all was happening there... > > > I will probably send more feedback, but I also don't want to overwhelm > > you with this and all the other reviews around. > > I really appreciate the feedback! It always sucks when so many little things > become so glaring after the fact but Lol I've been there, no worries :) -Santiago. signature.asc Description: PGP signature
Re: [aur-general] TU Membership Application
On 11/07/18 09:28pm, Santiago Torres-Arias wrote: Hello Brett. I took some time to randomly sample your PKGBUILDs and give some feedback: - ags: - it appears that you use sed to change CFLAGS in the makefile definition, although it appears that the Makefile itself lets you overwrite them. I'd advice trying to use native tooling as possible, and to try to get familiar with the toolchain of each package as much as possible. I will admit that I didn't think to go through those lines when I inherited it. You're totally right, there's no reason to do it that way. - The optdepends description on wine is a bit confusing in my opinion. I removed it. There's little reason to have it there anyway. The optdepends isn't a good place to inform people about that anyway. - I marked the package as out-of-date, as there appears to be a new version (3.1.4.15) as of almost two months ago. Long story short, that was pretty much exactly during the time when I accidentally clobbered my urlwatch file. Thanks for bringing that up to me. - I noticed that you didn't add a LICENSE file for this package. Artistic2.0 is a uncommonly used common license! (/usr/share/licenses/common/Artistic2.0/license.txt) - hib-dlagent: - I see that you backported a patch on this and ags. I was rather surprised to see that neither patches were added to new tags/releases. You could, however, cherry pick the commits rather than depending on the github api (which can change) to compute the diff for you. For this, you could use the git transport on makepkg. That would bring another dependency on git, though. I can surely do if if it's more 'correct' but I wouldn't imagine that Github would change that API anytime soon. Or would it be better to just carry the patch locally in the repo? - I noticed that you didn't add a LICENSE file for this package. Yikes, the project doesn't even have a license! I should have checked that when I inherited it (the packager just slapped a GPL2 on it). Really, I had just uploaded it so it wouldn't have been lost after the AUR 4 migration. I'll bug upstream about it. - gam-git: - I'm not sure if this would work when built in a chroot due to those touch calls. - After reviewing the package I doubt this doesn't need a build() step. Otherwise I'd label this package a -bin. This is something that we should take special consideration of, since we could be unwittingly be introducing binaries that aren't hardened when building. (I could be wrong on this one, since it for some reason vendors many well-known packages inside of it. Good job for not pulling it those vendored deps :D) - I'm confused as to why gam.py needs to be put inside /usr/share/gam and add a .sh entrypoint for it in /usr/bin. The file seems to have a shebang and be executable... - I see that here you *also* are providing a patch. I also could find that you submitted an issue upstream for said patch (but not the patch itself)[1]. I like your initiative! Do try to keep the number of backported patches to a minimum to keep things manageable. - I noticed that you didn't add a LICENSE file for this package. Of all the packages you had to click on that one. :( I know it doesn't really excuse it but gam is sort of a "WIP" because it's... oddly written. I've been meaning to set aside some time to get some patches in to make it more palatable for packaging. The patch is a complete hack right now just to make the package "work" (when I inherited it it was FUBAR). I will probably send more feedback, but I also don't want to overwhelm you with this and all the other reviews around. I really appreciate the feedback! It always sucks when so many little things become so glaring after the fact but signature.asc Description: PGP signature
Re: [aur-general] TU Membership Application
On 11/7/18 9:28 PM, Santiago Torres-Arias via aur-general wrote: > Hello Brett. > > I took some time to randomly sample your PKGBUILDs and give some > feedback: > > - ags: > - it appears that you use sed to change CFLAGS in the makefile > definition, although it appears that the Makefile itself lets you > overwrite them. I'd advice trying to use native tooling as > possible, and to try to get familiar with the toolchain of each > package as much as possible. > - The optdepends description on wine is a bit confusing in my > opinion. > - I marked the package as out-of-date, as there appears to be a new > version (3.1.4.15) as of almost two months ago. > - I noticed that you didn't add a LICENSE file for this package. This checks out, Artistic2.0 is a common license. > - hib-dlagent: > - I see that you backported a patch on this and ags. I was rather > surprised to see that neither patches were added to new > tags/releases. You could, however, cherry pick the commits rather > than depending on the github api (which can change) to compute the > diff for you. For this, you could use the git transport on > makepkg. I don't see why you'd need the overhead of git for this, and that url is not going to change. They "document" it here: https://blog.github.com/2011-10-21-github-secrets/#diff-patch They've provided it for a very long time specifically in order to let people do this, they're not going to change the scheme and render it useless for the very purpose it was created for. :p ... cgit and gitweb let you download patch files too, GitHub just doesn't expose a visible link for it. > - I noticed that you didn't add a LICENSE file for this package. PKGBUILD claims to be GPL2, which is a common license, but upstream has no licensing information I can find... > - gam-git: Am I missing something? I only see a "gam" package. > - I'm not sure if this would work when built in a chroot due to > those touch calls. Are you referring to the ones in package()? Not sure why upstream code needs such weird things but AFAICT it should not break just because of a chroot. > - After reviewing the package I doubt this doesn't need a build() > step. Otherwise I'd label this package a -bin. This is something > that we should take special consideration of, since we could be > unwittingly be introducing binaries that aren't hardened when > building.> (I could be wrong on this one, since it for some > reason vendors > many well-known packages inside of it. Good job for not pulling it > those vendored deps :D) Looks like it just copies a couple python modules into a directory and then creates a wrapper script to run them. What would you suggest running in build(), exactly? Devendoring looks good to me too, though. > - I'm confused as to why gam.py needs to be put inside > /usr/share/gam and add a .sh entrypoint for it in /usr/bin. The > file seems to have a shebang and be executable... I'm not sure what the script does either. gam.py does do: import utils from var import * Which should really be explicit relative imports, but it's actually legal in python2, and there doesn't seem to be any other reason to want to cd to the directory, but the script does not cd there anyway. > - I see that here you *also* are providing a patch. I also could > find that you submitted an issue upstream for said patch (but not > the patch itself)[1]. I like your initiative! Do try to keep the > number of backported patches to a minimum to keep things > manageable. I see two mostly similar issues, the other one has a diff referenced. https://github.com/jay0lee/GAM/issues/created_by/ainola Worth noting, it's much easier to get upstream projects to accept these if you provide a button they can click on to implement it -- that means pull requests. > - I noticed that you didn't add a LICENSE file for this package. Once again, Apache license is a common license and doesn't need to be installed. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [aur-general] TU Membership Application
Hello Brett. I took some time to randomly sample your PKGBUILDs and give some feedback: - ags: - it appears that you use sed to change CFLAGS in the makefile definition, although it appears that the Makefile itself lets you overwrite them. I'd advice trying to use native tooling as possible, and to try to get familiar with the toolchain of each package as much as possible. - The optdepends description on wine is a bit confusing in my opinion. - I marked the package as out-of-date, as there appears to be a new version (3.1.4.15) as of almost two months ago. - I noticed that you didn't add a LICENSE file for this package. - hib-dlagent: - I see that you backported a patch on this and ags. I was rather surprised to see that neither patches were added to new tags/releases. You could, however, cherry pick the commits rather than depending on the github api (which can change) to compute the diff for you. For this, you could use the git transport on makepkg. - I noticed that you didn't add a LICENSE file for this package. - gam-git: - I'm not sure if this would work when built in a chroot due to those touch calls. - After reviewing the package I doubt this doesn't need a build() step. Otherwise I'd label this package a -bin. This is something that we should take special consideration of, since we could be unwittingly be introducing binaries that aren't hardened when building. (I could be wrong on this one, since it for some reason vendors many well-known packages inside of it. Good job for not pulling it those vendored deps :D) - I'm confused as to why gam.py needs to be put inside /usr/share/gam and add a .sh entrypoint for it in /usr/bin. The file seems to have a shebang and be executable... - I see that here you *also* are providing a patch. I also could find that you submitted an issue upstream for said patch (but not the patch itself)[1]. I like your initiative! Do try to keep the number of backported patches to a minimum to keep things manageable. - I noticed that you didn't add a LICENSE file for this package. I will probably send more feedback, but I also don't want to overwhelm you with this and all the other reviews around. Cheers! -Santiago. [1] https://github.com/jay0lee/GAM/issues/791 signature.asc Description: PGP signature
Re: [aur-general] TU Membership Application
On 07 Nov 2018, at 5:41 pm -0700, Brett Cornwall via aur-general wrote: > On 11/05/18 07:48pm, Levente Polyak via aur-general wrote: > > - don't think pkgdesc should ever end with a dot > The descriptions are often sentences, so would it not reason to end them > with a period? In the case of actual sentences, it's just convention to be consistent with the packages whose descriptions are sentence fragments. It's a bit arbitrary, granted. > > - not a big fan of fiddling with PKGEXT even if its "just the AUR" but > > well > > For a package destined for the repositories I would not fiddle and endeavor > to reverse such fiddling; however, the compression time for large games is > enormous only to decompress right after. Should it, for the sake of > correct-ness, be reversed even for the packages doomed forever to live in > the AUR? It's just not the prerogative of the AUR contributor to make that decision for the end-user who's going to be building the package. They can very easily configure their own makepkg.conf to use uncompressed tarballs if they so desire. Basically, a PKGBUILD shouldn't override makepkg.conf unless there's a very good reason. Cheers, Ivy signature.asc Description: PGP signature
Re: [aur-general] TU Membership Application
On Wed, Nov 07, 2018 at 05:45:01PM -0700, Brett Cornwall via aur-general wrote: > On 11/05/18 07:48pm, Levente Polyak via aur-general wrote: > > creeper-world2 > > I've had two AUR requests queued up for some time now; deleting this package > is one of them. Quick update: I addressed your request of deleting the package. That simplifies everyone's review queue :) Thanks, -Santiago signature.asc Description: PGP signature
Re: [aur-general] TU Membership Application
On 11/05/18 07:48pm, Levente Polyak via aur-general wrote: creeper-world2 I've had two AUR requests queued up for some time now; deleting this package is one of them. signature.asc Description: PGP signature
Re: [aur-general] TU Membership Application
On 11/05/18 07:48pm, Levente Polyak via aur-general wrote: some small questions and hints first: I'm nearly done with following your excellent suggestions but I have responses and questions. It looks like several packages have different issues preventing to build in clean chrooted environments properly. Did you take a look at the devtools package and building packages in clean chroots so far? I must sheepishly apologize. These new tools simplify everything. What software/tool do you using to track all the new ustream releases? urlwatch on a daily timer. You still seem to use `mksrcinfo` for generating SRCINFO files, it was deprecated in favor of native `makepkg --printsrcinfo` you may want to use that in the future. Thank you, switched! I have noticed that mostly all git packages lack sufficient provides/conflicts on the basic non-git name schema and/or makedepends on git itself, would be nice to keep in mind A silly oversight that will be enforced now that I'm learned in the ways of proper tooling. Also i notices there are multiple packages that store a tarball in the AUR source repo that contain things like icons, please don't miss-use the AUR as a storage for tarball artifacts. I should have known better and - at the very least - removed them before submitting my application. I've taken care of nearly all of them and have bowed my head in shame. - don't think pkgdesc should ever end with a dot The descriptions are often sentences, so would it not reason to end them with a period? - not a big fan of fiddling with PKGEXT even if its "just the AUR" but well For a package destined for the repositories I would not fiddle and endeavor to reverse such fiddling; however, the compression time for large games is enormous only to decompress right after. Should it, for the sake of correct-ness, be reversed even for the packages doomed forever to live in the AUR? interception-ctrl2esc-git - is there a reason to have interception- prefix? imo ctrl2esc-git would be the better naming here plus provides/conflicts on ctrl2esc I normally agree (and I originally had it named that way), however... - This is an 'interception tools' plugin... not reason enough to have the package name change, but.. - caps2esc is an older X program, so interception's variant had to be named 'interception-caps2esc'. Naming this 'interception-ctrl2esc' follows the pattern for consistency/less confusion. With that said, should it still be named ctrl2esc? signature.asc Description: PGP signature
Re: [aur-general] [some information] PKGBUILD git remote branch issue
Hi, some information regarding the release: https://lists.claws-mail.org/pipermail/users/2018-November/023180.html FWIW the PKGBUILD: https://lists.claws-mail.org/pipermail/users/attachments/20181107/1525d5fe/attachment-0003.obj It's more or less copied from https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=claws-mail-git. Regards, Ralf
[aur-general] [solved] PKGBUILD git remote branch issue
On Wed, 2018-11-07 at 10:08 -0500, Eli Schwartz via aur-general wrote: > But the PKGBUILD is at least getting the correct version of the gtk3 > branch, unlike you --- in other words, the #branch=gtk3 notation is > designed to accurately do exactly "what it says on the label", whereas > humans are error-prone and sometimes forget to switch from the master > branch to the gtk3 branch. Thank you, so I made two mistakes. I forgot to switch and assumed that development of the gtk3 port is in sync with the gtk2 version of Claws. [rocketmouse@archlinux ~]$ cd /tmp/claws [rocketmouse@archlinux claws]$ git describe --abbrev=0 --tags 3.17.0 [rocketmouse@archlinux claws]$ git rev-parse --short HEAD f4607b4b6 [rocketmouse@archlinux claws]$ git checkout gtk3 Switched to branch 'gtk3' Your branch is up to date with 'origin/gtk3'. [rocketmouse@archlinux claws]$ git describe --abbrev=0 --tags 3.16.0 [rocketmouse@archlinux claws]$ git rev-parse --short HEAD 04185a6e4 Regards, Ralf
Re: [aur-general] PKGBUILD git remote branch issue
On Wed, 2018-11-07 at 15:55 +0100, Ralf Mardorf wrote: > On Wed, 2018-11-07 at 15:49 +0100, Robin Broda via aur-general wrote: > > No, it doesn't work because you're breaking your multiline command > > with the comment line inbetween. > > Good point :D! I must be missing something else. [rocketmouse@archlinux claws-mail-gtk3-git]$ grep HOST /usr/src/claws-mail-gtk3-git/PKGBUILD -B1 -A14 ./configure \ --build=$HOSTTYPE-arch-linux-gnu \ --prefix=/usr \ --disable-jpilot \ --disable-maintainer-mode \ --disable-manual \ --disable-static \ --enable-bogofilter-plugin \ --enable-crash-dialog \ --enable-enchant \ --enable-gnutls \ --enable-ldap \ --enable-pgpmime-plugin \ --enable-silent-rules \ --enable-spamassassin-plugin #--enable-gtk3 \ [rocketmouse@archlinux claws-mail-gtk3-git]$ makepkg -s ==> Making package: claws-mail-gtk3-git 3.17.0-1 (Wed 07 Nov 2018 03:57:57 PM CET) ==> Starting prepare()... ==> Starting pkgver()... ==> Updated version: claws-mail-gtk3-git 3.16.0.r463.g04185a6e4-1 ==> Starting build()... Now it builds, but seemingly the wrong version. make: *** [Makefile:558: all] Interrupt ==> ERROR: Aborted by user! Exiting... [rocketmouse@archlinux claws-mail-gtk3-git]$ cd claws-mail/ [rocketmouse@archlinux claws-mail]$ git describe --abbrev=0 --tags 3.17.0 [rocketmouse@archlinux claws-mail]$ git rev-parse --short HEAD f4607b4b6 [rocketmouse@archlinux claws-mail]$ cd .. [rocketmouse@archlinux claws-mail-gtk3-git]$ sudo rm -Ir claws-mail/ pkg/ src/ [sudo] password for rocketmouse: rm: remove 3 arguments recursively? y [rocketmouse@archlinux claws-mail-gtk3-git]$ ls PKGBUILD [rocketmouse@archlinux claws-mail-gtk3-git]$ makepkg -s [snip] config.status: creating po/Makefile claws-mail 3.16.0git463 Using Address Book : Original stable interface JPilot : no LDAP : yes gnuTLS : yes iconv : yes compface : yes IPv6 : yes enchant: yes IMAP4 : yes NNTP : yes Crash dialog : yes LibSM : yes DBUS : yes NetworkManager : yes Manual : no Generic UMPC code : no SVG support: yes Config dir : .claws-mail Password crypto: gnutls Unit tests : no [snip] ==> Finished making: claws-mail-gtk3-git 3.16.0.r463.g04185a6e4-1 (Wed 07 Nov 2018 04:07:39 PM CET)
Re: [aur-general] PKGBUILD git remote branch issue
On 11/7/18 9:16 AM, Ralf Mardorf wrote: > However, this way it tries to build 3.16.0.r463.g04185a6e4-1, let alone > that it fails with ^^ > > "Configure finished, type 'make' to build. > /usr/src/claws-mail-gtk3-git/PKGBUILD: line 85: --enable-ldap: command > not found > ==> ERROR: A failure occurred in build(). > Aborting..." Failure is unrelated and comes from bash attempting to run the line: "--enable-ldap" as a command instead of an option to the configure command. Please don't confused errors running the build() function, for errors checking out the sources. > Without a PKGBUILD it does build 3.17.0-153-gf4607b with all the > ^^ > configure options used by the PKGBUILD. > > ./configure --build=$HOSTTYPE-arch-linux-gnu --prefix=/usr --disable-jpilot > --disable-maintainer-mode --disable-manual --disable-static > --enable-bogofilter-plugin --enable-crash-dialog --enable-enchant > --enable-gnutls --enable-pgpmime-plugin --enable-silent-rules > --enable-spamassassin-plugin --enable-ldap > > ^ > > IOW this way, the PKGBUILD doesn't get the correct version of the GTK3 branch. But the PKGBUILD is at least getting the correct version of the gtk3 branch, unlike you --- in other words, the #branch=gtk3 notation is designed to accurately do exactly "what it says on the label", whereas humans are error-prone and sometimes forget to switch from the master branch to the gtk3 branch. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [aur-general] PKGBUILD git remote branch issue
On 11/7/18 9:38 AM, Ralf Mardorf wrote:
> On Wed, 2018-11-07 at 08:38 -0500, Eli Schwartz via aur-general wrote:
>> As per the PKGBUILD(5) man page, use:
>>
>> source=("git://example.com/reponame.git#FOO=BAR")
>>
>> where FOO is either:
>> - tag
>> - branch
>> - commit
>>
>> and BAR is the corresponding revision you wish to check out (in this
>> case the branch name is "gtk3")
>>
>> So, #FOO=BAR would be #branch=gtk3
>
> Thank you,
>
> unfortunately it doesn't work.
>
> [rocketmouse@archlinux claws-mail-gtk3-git]$ ls
> PKGBUILD
> [rocketmouse@archlinux claws-mail-gtk3-git]$ makepkg -s
> ==> Making package: claws-mail-gtk3-git 3.17.0-1 (Wed 07 Nov 2018 03:27:22 PM
> CET)
> [snip]
> ==> Starting prepare()...
> ==> Starting pkgver()...
> ==> Updated version: claws-mail-gtk3-git 3.16.0.r463.g04185a6e4-1
> ==> Starting build()...
> ^C
>
> [rocketmouse@archlinux tmp]$ git clone git://git.claws-mail.org/claws.git
> [snip]
> [rocketmouse@archlinux tmp]$ cd claws/
> [rocketmouse@archlinux claws]$ git fetch origin
> [rocketmouse@archlinux claws]$ git branch --track gtk3 origin/gtk3
> Branch 'gtk3' set up to track remote branch 'gtk3' from 'origin'.
> [rocketmouse@archlinux claws]$ ./autogen.sh
> [snip]
> claws-mail 3.17.0git153
> [snip]
That output is entirely correct.
When you use my command, you checkout "gtk3" during the clone.
When you use your command, you create a gtk3 branch that you never use,
because you stayed on master. If you'd switched to the gtk3 branch you
created, using "git checkout gtk3", you'd see that it tells you
"Switched to branch 'gtk3'"
...
This is why I recommended you use a proper git clone in the first place.
...
Other fun tricks:
$ git clone git://git.claws-mail.org/claws.git
Cloning into 'claws'...
[...]
$ git checkout gtk3
Branch 'gtk3' set up to track remote branch 'gtk3' from 'origin'.
Switched to a new branch 'gtk3'
No need to do crazy stuff with manual branching either -- git is super
smart and knows what you mean. It also tells you when it's doing it, so
you can verify that it happened.
--
Eli Schwartz
Bug Wrangler and Trusted User
signature.asc
Description: OpenPGP digital signature
Re: [aur-general] PKGBUILD git remote branch issue
On Wed, 2018-11-07 at 15:49 +0100, Robin Broda via aur-general wrote: > No, it doesn't work because you're breaking your multiline command > with the comment line inbetween. Good point :D!
Re: [aur-general] PKGBUILD git remote branch issue
On Wed, 07 Nov 2018 15:47:59 +0100 Ralf Mardorf wrote: > On Wed, 2018-11-07 at 08:40 -0600, Doug Newgard via aur-general wrote: > > On Wed, 07 Nov 2018 15:16:22 +0100 > > Ralf Mardorf wrote: > > > > > "Configure finished, type 'make' to build. > > > /usr/src/claws-mail-gtk3-git/PKGBUILD: line 85: --enable-ldap: command > > > not found > > > ==> ERROR: A failure occurred in build(). > > > Aborting..." > > > > That error is a mistake in the PKGBUILD, nothing to do with the checkout. > > The PKGBUILD tries to build an outdated release, that is why it fails. > When building the latest release, it works with "--enable-ldap". No, it fails because you have a return before --enable-ldap
Re: [aur-general] PKGBUILD git remote branch issue
On 11/7/18 3:47 PM, Ralf Mardorf wrote: > On Wed, 2018-11-07 at 08:40 -0600, Doug Newgard via aur-general wrote: >> On Wed, 07 Nov 2018 15:16:22 +0100 >> Ralf Mardorf wrote: >> >>> "Configure finished, type 'make' to build. >>> /usr/src/claws-mail-gtk3-git/PKGBUILD: line 85: --enable-ldap: command >>> not found >>> ==> ERROR: A failure occurred in build(). >>> Aborting..." >> >> That error is a mistake in the PKGBUILD, nothing to do with the checkout. > > The PKGBUILD tries to build an outdated release, that is why it fails. > When building the latest release, it works with "--enable-ldap". > No, it doesn't work because you're breaking your multiline command with the comment line inbetween. -- Rob (coderobe) O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
Re: [aur-general] PKGBUILD git remote branch issue
On Wed, 2018-11-07 at 08:40 -0600, Doug Newgard via aur-general wrote: > On Wed, 07 Nov 2018 15:16:22 +0100 > Ralf Mardorf wrote: > > > "Configure finished, type 'make' to build. > > /usr/src/claws-mail-gtk3-git/PKGBUILD: line 85: --enable-ldap: command > > not found > > ==> ERROR: A failure occurred in build(). > > Aborting..." > > That error is a mistake in the PKGBUILD, nothing to do with the checkout. The PKGBUILD tries to build an outdated release, that is why it fails. When building the latest release, it works with "--enable-ldap".
Re: [aur-general] PKGBUILD git remote branch issue
On Wed, 07 Nov 2018 15:16:22 +0100 Ralf Mardorf wrote: > "Configure finished, type 'make' to build. > /usr/src/claws-mail-gtk3-git/PKGBUILD: line 85: --enable-ldap: command > not found > ==> ERROR: A failure occurred in build(). > Aborting..." That error is a mistake in the PKGBUILD, nothing to do with the checkout.
Re: [aur-general] PKGBUILD git remote branch issue
On Wed, 2018-11-07 at 08:38 -0500, Eli Schwartz via aur-general wrote:
> As per the PKGBUILD(5) man page, use:
>
> source=("git://example.com/reponame.git#FOO=BAR")
>
> where FOO is either:
> - tag
> - branch
> - commit
>
> and BAR is the corresponding revision you wish to check out (in this
> case the branch name is "gtk3")
>
> So, #FOO=BAR would be #branch=gtk3
Thank you,
unfortunately it doesn't work.
[rocketmouse@archlinux claws-mail-gtk3-git]$ ls
PKGBUILD
[rocketmouse@archlinux claws-mail-gtk3-git]$ makepkg -s
==> Making package: claws-mail-gtk3-git 3.17.0-1 (Wed 07 Nov 2018 03:27:22 PM
CET)
[snip]
==> Starting prepare()...
==> Starting pkgver()...
==> Updated version: claws-mail-gtk3-git 3.16.0.r463.g04185a6e4-1
==> Starting build()...
^C
[rocketmouse@archlinux tmp]$ git clone git://git.claws-mail.org/claws.git
[snip]
[rocketmouse@archlinux tmp]$ cd claws/
[rocketmouse@archlinux claws]$ git fetch origin
[rocketmouse@archlinux claws]$ git branch --track gtk3 origin/gtk3
Branch 'gtk3' set up to track remote branch 'gtk3' from 'origin'.
[rocketmouse@archlinux claws]$ ./autogen.sh
[snip]
claws-mail 3.17.0git153
[snip]
Regards,
Ralf
pkgname=claws-mail-gtk3-git
pkgver=3.17.0
pkgrel=1
pkgdesc='A GTK3 based e-mail client - git checkout'
arch=('i686' 'x86_64')
license=('GPL3')
url='https://www.claws-mail.org/'
depends=('gtk3' 'gnutls' 'startup-notification' 'enchant' 'gpgme' 'libetpan'
'compface'
'libsm' 'dbus-glib' 'hicolor-icon-theme' 'desktop-file-utils')
makedepends=('git' 'spamassassin' 'bogofilter' 'valgrind'
# dependencies for plugins
'libgdata' 'libnotify' 'libcanberra' 'poppler-glib' 'pygtk' 'dillo'
# deps to build the docs
'docbook-utils' 'texlive-core')
optdepends=('python2: needed for some tools and python plugin'
'perl: needed for some tools and perl plugin'
'spamassassin: adds support for spamfiltering'
'bogofilter:adds support for spamfiltering'
'libnotify: for notification plugin'
'libcanberra: for notification plugin'
'dbus: for notification plugin'
'libxml2: for rssyl plugins'
'curl: for vcalendar, rssyl and spamreport plugins'
'libarchive:for archive plugin and various other plugins'
'libytnef: for tnef_parse plugin'
'libgdata: for gdata plugin'
'poppler-glib: for pdf viewer plugin'
'ghostscript: for pdf viewer plugin'
'dillo: for html viewer plugin')
replaces=('sylpheed-claws' 'claws-mail-extra-plugins')
conflicts=('claws-mail-extra-plugins' 'claws-mail')
provides=('claws' 'claws-mail')
source=('claws-mail::git://git.claws-mail.org/claws.git#branch=gtk3')
sha256sums=('SKIP')
pkgver() {
cd claws-mail/
if GITTAG="$(git describe --abbrev=0 --tags 2>/dev/null)"; then
printf '%s.r%s.g%s' \
"$(sed -e "s/^${pkgname%%-git}//" -e
's/^[-_/a-zA-Z]\+//' -e 's/[-_+]/./g' <<< ${GITTAG})" \
"$(git rev-list --count ${GITTAG}..)" \
"$(git rev-parse --short HEAD)"
else
printf '0.r%s.g%s' \
"$(git rev-list --count master)" \
"$(git rev-parse --short HEAD)"
fi
}
prepare() {
cd claws-mail/
# fixes for python2
sed -i 's@^#!.*python.*@#!/usr/bin/python2@' tools/*.py
git update-index --assume-unchanged tools/*.py
}
build() {
cd claws-mail/
# run autogen without options - it runs ./configure for us, but we need
to fix python first
NOCONFIGURE=1 ./autogen.sh
# fixes for python2
export PYTHON="/usr/bin/python2"
sed -i 's:python -c:python2 -c:g' configure
# add --enable-alternate-addressbook to the options to use the
# new/alternate address book
# do not forget to add claws-contacts to the dependencies then
./configure \
--build=$HOSTTYPE-arch-linux-gnu \
--prefix=/usr \
--disable-jpilot \
--disable-maintainer-mode \
--disable-manual \
--disable-static \
--enable-bogofilter-plugin \
--enable-crash-dialog \
--enable-enchant \
--enable-gnutls \
#--enable-gtk3 \
--enable-ldap \
--enable-pgpmime-plugin \
--enable-silent-rules \
--enable-spamassassin-plugin
#--help
make
# build extra tools
cd tools/
make
}
package() {
cd claws-mail/
make DESTDIR="${pkgdir}" install
# install extra tools
# all executables and .conf files ; only top directory
cd tools
for FILE in $(find -maxdepth 1 -type f -and
Re: [aur-general] PKGBUILD git remote branch issue
On Wed, 2018-11-07 at 14:27 +0100, stefan-husm...@t-online.de wrote:
> source=('claws-mail::git://git.claws-mail.org/#branch=gtk3')
Thank you,
unfortunately I tried already with
source=('claws-mail::git://git.claws-mail.org/claws.git#branch=gtk3')
^
My bad, I didn't notice
that I deleted "claws.git", when I added already "#branch=gtk3" before.
However, this way it tries to build 3.16.0.r463.g04185a6e4-1, let alone
that it fails with ^^
"Configure finished, type 'make' to build.
/usr/src/claws-mail-gtk3-git/PKGBUILD: line 85: --enable-ldap: command
not found
==> ERROR: A failure occurred in build().
Aborting..."
Without a PKGBUILD it does build 3.17.0-153-gf4607b with all the
^^
configure options used by the PKGBUILD.
./configure --build=$HOSTTYPE-arch-linux-gnu --prefix=/usr --disable-jpilot
--disable-maintainer-mode --disable-manual --disable-static
--enable-bogofilter-plugin --enable-crash-dialog --enable-enchant
--enable-gnutls --enable-pgpmime-plugin --enable-silent-rules
--enable-spamassassin-plugin --enable-ldap
^
IOW this way, the PKGBUILD doesn't get the correct version of the GTK3 branch.
Regards,
Ralf
Re: [aur-general] mate-common-dev missing Source File
On 11/7/18 8:52 AM, Dan Sommers wrote: > Greetings, > > I tried to install mate-common-dev¹ this morning, but it fails to > download its source file²: > > -> Downloading mate-common-1.21.0.tar.xz... > [... curl progress meter skipped ...] > curl: (22) The requested URL returned error: 404 Not Found > ==> ERROR: Failure while downloading > http://pub.mate-desktop.or/releases/1.21/mate-common-1.21.0.tar.xz > Aborting... > > I checked the source directory,³ and sure enough, there is no > mate-common tarball there. > > A lot of other mate-*-dev packages depend on mate-common-dev; what's the > easiest path forward to a mate-desktop-dev installation? There is no mate-common 1.21 release, and this is broken because the incompetent person who maintains these packages has uploaded it on a cronjob which does not check to make sure the packages work. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
[aur-general] mate-common-dev missing Source File
Greetings, I tried to install mate-common-dev¹ this morning, but it fails to download its source file²: -> Downloading mate-common-1.21.0.tar.xz... [... curl progress meter skipped ...] curl: (22) The requested URL returned error: 404 Not Found ==> ERROR: Failure while downloading http://pub.mate-desktop.or/releases/1.21/mate-common-1.21.0.tar.xz Aborting... I checked the source directory,³ and sure enough, there is no mate-common tarball there. A lot of other mate-*-dev packages depend on mate-common-dev; what's the easiest path forward to a mate-desktop-dev installation? Thanks, Dan ¹ https://aur.archlinux.org/packages/mate-desktop-dev/ ² http://pub.mate-desktop.org/releases/1.21/mate-desktop-1.21.3.tar.xz ³ http://pub.mate-desktop.org/releases/1.21/
Re: [aur-general] PKGBUILD git remote branch issue
On 11/7/18 8:17 AM, Ralf Mardorf wrote:
> Hi,
>
> building the Claws GTK3 port works, if I build from the branch like
> this:
>
>
> [rocketmouse@archlinux tmp]$ git clone git://git.claws-mail.org/claws.git
> [snip]
> [rocketmouse@archlinux tmp]$ cd claws
> [rocketmouse@archlinux claws]$ git fetch origin
> [rocketmouse@archlinux claws]$ git branch --track gtk3 origin/gtk3
> Branch 'gtk3' set up to track remote branch 'gtk3' from 'origin'.
More convenient to use the following:
git clone --branch=gtk3 git://git.claws-mail.org/claws.git
> A developer mentions that I should build from the gtk3 branch:
> https://lists.claws-mail.org/pipermail/users/2018-November/023176.html
> ...but don't know what "foo bar" to add to the source or how else to
> handle this by a PKGBUILD:
>
> [rocketmouse@archlinux claws]$ grep source
> /usr/src/claws-mail-gtk3-git/PKGBUILD
> source=('claws-mail::git://git.claws-mail.org/#FOO=BAR')
>
>
>
> Is there an easy way to do it?
As per the PKGBUILD(5) man page, use:
source=("git://example.com/reponame.git#FOO=BAR")
where FOO is either:
- tag
- branch
- commit
and BAR is the corresponding revision you wish to check out (in this
case the branch name is "gtk3")
So, #FOO=BAR would be #branch=gtk3
--
Eli Schwartz
Bug Wrangler and Trusted User
signature.asc
Description: OpenPGP digital signature
Re: [aur-general] PKGBUILD git remote branch issue
>Is there an easy way to do it?
>Regards,
>Ralf
source=('claws-mail::git://git.claws-mail.org/#branch=gtk3')
[aur-general] PKGBUILD git remote branch issue
Hi,
building the Claws GTK3 port works, if I build from the branch like
this:
[rocketmouse@archlinux tmp]$ git clone git://git.claws-mail.org/claws.git
[snip]
[rocketmouse@archlinux tmp]$ cd claws
[rocketmouse@archlinux claws]$ git fetch origin
[rocketmouse@archlinux claws]$ git branch --track gtk3 origin/gtk3
Branch 'gtk3' set up to track remote branch 'gtk3' from 'origin'.
[rocketmouse@archlinux claws]$ ./autogen.sh
[snip]
[rocketmouse@archlinux claws]$ ./configure --build=$HOSTTYPE-arch-linux-gnu
--prefix=/usr --disable-static --enable-enchant --enable-gnutls --enable-ldap
--enable-crash-dialog --enable-pgpmime-plugin --enable-spamassassin-plugin
--enable-bogofilter-plugin
[rocketmouse@archlinux claws]$ sh version
3.17.0-153-gf4607b
[rocketmouse@archlinux claws]$ make
[snip]
Done.
[snip]
If I try to build from the master with "--enable-gtk3" it fails, see:
https://lists.claws-mail.org/pipermail/users/2018-November/023174.html
A developer mentions that I should build from the gtk3 branch:
https://lists.claws-mail.org/pipermail/users/2018-November/023176.html
I commented out "#--enable-gtk3"...
[rocketmouse@archlinux claws]$ grep HOST /usr/src/claws-mail-gtk3-git/PKGBUILD
-B1 -A14
./configure \
--build=$HOSTTYPE-arch-linux-gnu \
--prefix=/usr \
--disable-jpilot \
--disable-maintainer-mode \
--disable-manual \
--disable-static \
--enable-bogofilter-plugin \
--enable-crash-dialog \
--enable-enchant \
--enable-gnutls \
#--enable-gtk3 \
--enable-ldap \
--enable-pgpmime-plugin \
--enable-silent-rules \
--enable-spamassassin-plugin
...but don't know what "foo bar" to add to the source or how else to
handle this by a PKGBUILD:
[rocketmouse@archlinux claws]$ grep source /usr/src/claws-mail-gtk3-git/PKGBUILD
source=('claws-mail::git://git.claws-mail.org/#FOO=BAR')
Is there an easy way to do it?
Regards,
Ralf
