You are not logged in.

#1 2017-12-21 20:56:09

Cody Learner
Banned
Registered: 2017-12-06
Posts: 54
Website

aurora version number

I'm working on a script that's checking AUR package versions for updates without using git. It compares version numbers reported by cower and pacman.  When running tests on random AUR packages, it failed on aurora due to the PKGBUILD containing:

pkgver=${PKGVER:-autogenerated}
pkgrel=${PKGREL:-1}

PKGBUILD: https://aur.archlinux.org/cgit/aur.git/ … D?h=aurora

Part of my script that's choking:

[[ $(pacman -Q ${2} | cut -d " " -f2) != $(cower -i ${2} --format %v) ]]

cower reports:

$ cower -i aurora --format %v
autogenerated-1

$ cower -i aurora 
Repository     : aur
Name           : aurora
Version        : autogenerated-1
URL            : (null)
AUR Page       : https://aur.archlinux.org/packages/aurora
Makedepends    : go  git  
License        : GPL  
Votes          : 1
Popularity     : 0.01
Out of Date    : No
Maintainer     : kovetskiy
Submitted      : Mon 29 Aug 2016 05:00:08 AM PDT
Last Modified  : Mon 29 Aug 2016 05:00:08 AM PDT
Description    : todo

Would it be OK to consider this a one off PKGBUILD problem, error, etc, or should I expect more of the same? If more to be expected, a bug in cower or problem in my script / method?

Last edited by Cody Learner (2017-12-21 20:58:42)


Self designated Linux and Bash mechanic.....
I fix and build stuff hands on. I'm not opposed to creating a mess in obtaining a goal.

Offline

#2 2017-12-21 21:03:14

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,442
Website

Re: aurora version number

The "autogenerated" and variable expansion is a bit new to me, but you will face a related problem on every single -dev/-vcs package there is: the pkgver function must be run.  The pkgver variable is virtually meaningless in vcs PKGBUILDS.

The only meaning it can have (and this isn't even reliable, nor meaningful) is it was the version last built by the maintainer before submitting the PKGBUILD.


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#3 2017-12-23 20:21:59

Cody Learner
Banned
Registered: 2017-12-06
Posts: 54
Website

Re: aurora version number

If version numbers are not going to be a reliable method for checking for updates, what then? Currently looking into trying by "last modified date vs today's date".

Looking into how different AUR helpers do things, I found xyne's python3-aur package https://xyne.archlinux.ca/projects/python3-aur/ specifically aurquery.
Using aurquery as a test to:

if		[[ $(aurquery -i ${2} --by=name --full-info | grep LastModified | cut -d ' ' -f12) > $(date '+%Y-%m-%d') ]]; then
		echo $ec = "update available"
		else
		echo $ec = "up to date"
fi

Gets this:

$ aurt-gitless -Cu modprobed-db

Last Modified | Today's Date 
[[ 2016-11-26 > 2017-12-23 ]] exit code 1

1 = up to date


Now trying to figure out how to get the info directly from the aurweb RPC interface. I've got this so far:

$ curl -s "https://aur.archlinux.org/rpc/?v=5&type=info&arg[]=modprobed-db" | jshon
{
 "version": 5,
 "type": "multiinfo",
 "resultcount": 1,
 "results": [
  {
   "ID": 360103,
   "Name": "modprobed-db",
   "PackageBaseID": 75413,
   "PackageBase": "modprobed-db",
   "Version": "2.37-1",
   "Description": "Keeps track of EVERY kernel module ever used - useful for those of us who make localmodconfig :)",
   "URL": "https:\/\/wiki.archlinux.org\/index.php\/Modprobed-db",
   "NumVotes": 200,
   "Popularity": 2.0925220000000002,
   "OutOfDate": null,
   "Maintainer": "graysky",
   "FirstSubmitted": 1384554087,
   "LastModified": 1480163504,
   "URLPath": "\/cgit\/aur.git\/snapshot\/modprobed-db.tar.gz",
   "Depends": [
    "kmod"
   ],
   "OptDepends": [
    "sudo"
   ],
   "Conflicts": [
    "modprobed_db"
   ],
   "Replaces": [
    "modprobed_db"
   ],
   "License": [
    "MIT"
   ],
   "Keywords": []
  }
 ]
}

I've read the jshon man page, https://bbs.archlinux.org/viewtopic.php?id=113619, and http://kmkeen.com/jshon/. Still clueless how to proceed to get a date from "LastModified": 1480163504, to use in a script.


Self designated Linux and Bash mechanic.....
I fix and build stuff hands on. I'm not opposed to creating a mess in obtaining a goal.

Offline

#4 2017-12-23 20:46:14

Scimmia
Fellow
Registered: 2012-09-01
Posts: 11,463

Re: aurora version number

The only reliable way of checking for updates on vcs packages is going to be to run makepkg -o, then check the pkgver. The pkgver in the AUR and the last modified time mean nothing.

Offline

#5 2017-12-24 21:46:39

Cody Learner
Banned
Registered: 2017-12-06
Posts: 54
Website

Re: aurora version number

Not sure to post this as a reply here or as a new topic in Programming & Scripting.

The following results are from the following code:

$ makepkg-test x aurora
20160907.16_f78867f-1
mkdir -p /tmp/aurt/"${2}" && cd /tmp/aurt/"${2}"
curl -s https://aur.archlinux.org/cgit/aur.git/plain/PKGBUILD?h="${2}" > /tmp/aurt/"${2}"/PKGBUILD
avaver=$(makepkg -do |& grep '==> Updated version: aurora' | cut -d ' ' -f5)
echo $avaver

Now I'm trying to take it to the next step with using variables rather than creating and using files. Having issues capturing the output. Pretty sure it's a redirect thing, but I can't seem to find a solution after trying many variations of below. Get "Fetching origin", nothing, or everything except what I need in the variable. This line would be a good start: "==> Making package: aurora 20160907.16_f78867f-1 (Sun Dec 24 13:30:36 PST 2017)"
Goal is to set makepkg output after filtering for the date, in a variable, as above.

The following code results in the following results.

PKGBUILD=$(curl -s https://aur.archlinux.org/cgit/aur.git/plain/PKGBUILD?h="${2}")
# echo "${PKGBUILD}"

{ avaver=$(makepkg -do 1&2>1) && echo "${PKGBUILD}" ; }

echo $avaver
$ makepkg-test x aurora
==> Making package: aurora 20160907.16_f78867f-1 (Sun Dec 24 13:30:36 PST 2017)
==> WARNING: Skipping dependency checks.
==> Retrieving sources...
  -> Updating aurora git repo...
==> Validating source files with md5sums...
    aurora ... Skipped
==> Extracting sources...
  -> Creating working copy of aurora git repo...
Reset branch 'makepkg'
==> Starting pkgver()...
==> Sources are ready.
# Maintainer: Egor Kovetskiy <e.kovetskiy@office.ngs.ru>
pkgname=aurora
pkgver=${PKGVER:-autogenerated}
pkgrel=${PKGREL:-1}
pkgdesc="todo"
arch=('i686' 'x86_64')
license=('GPL')
depends=(
)
makedepends=(
	'go'
	'git'
)

source=(
	"aurora::git://github.com/kovetskiy/aurora.git#branch=${BRANCH:-master}"
)

md5sums=(
	'SKIP'
)

backup=(
)

pkgver() {
	if [[ "$PKGVER" ]]; then
		echo "$PKGVER"
		return
	fi

	cd "$srcdir/$pkgname"
	local date=$(git log -1 --format="%cd" --date=short | sed s/-//g)
	local count=$(git rev-list --count HEAD)
	local commit=$(git rev-parse --short HEAD)
	echo "$date.${count}_$commit"
}

build() {
	cd "$srcdir/$pkgname"

	if [ -L "$srcdir/$pkgname" ]; then
		rm "$srcdir/$pkgname" -rf
		mv "$srcdir/.go/src/$pkgname/" "$srcdir/$pkgname"
	fi

	rm -rf "$srcdir/.go/src"

	mkdir -p "$srcdir/.go/src"

	export GOPATH="$srcdir/.go"

	mv "$srcdir/$pkgname" "$srcdir/.go/src/"

	cd "$srcdir/.go/src/$pkgname/"
	ln -sf "$srcdir/.go/src/$pkgname/" "$srcdir/$pkgname"

	git submodule update --init

	go get -v \
		-gcflags "-trimpath $GOPATH/src" \
		-ldflags="-X main.version=$pkgver-$pkgrel"
}

package() {
	find "$srcdir/.go/bin/" -type f -executable | while read filename; do
		install -DT "$filename" "$pkgdir/usr/bin/$(basename $filename)"
	done

    install -DT \
        "$srcdir/$pkgname/systemd/aurora.service" \
        "$pkgdir/usr/lib/systemd/system/aurora.service"

    install -DT \
        "$srcdir/$pkgname/systemd/aurora-web.service" \
        "$pkgdir/usr/lib/systemd/system/aurora-web.service"

    mkdir -p "$pkgdir/etc/aurora"
    cp -r "$srcdir/$pkgname/conf.d" "$pkgdir/etc/aurora/container"
}
Fetching origin

Last edited by Cody Learner (2017-12-24 21:47:03)


Self designated Linux and Bash mechanic.....
I fix and build stuff hands on. I'm not opposed to creating a mess in obtaining a goal.

Offline

#6 2017-12-24 21:52:52

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,442
Website

Re: aurora version number

That seems needlessly complex.  Why are you using curl instead of git - curl just getting the PKGBUILD will not work in cases where there are patches or associated files?  There's also no need for the subshell and the pipes:

git clone https://aur.archlinux.org/${pkgname}.git
cd ${pkgname}
makepkg -od

At that point the pkgver variable in the PKGBUILD will be current.


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#7 2017-12-24 21:56:39

jasonwryan
Anarchist
From: .nz
Registered: 2009-05-09
Posts: 30,424
Website

Re: aurora version number

Some basics.

  • $_ is the previous directory, so you can use that instead of repeating yourself with mkdir && cd

  • curl has an -o option to write to a file, so no redirect is necessary

  • awk is a better choice for processing a file line by line, and then quitting when you capture your match (it also replaces grep and cut, saving you processes)

As to what you are actually trying to do, is it just capture the pkgver from makepkg's output and store it in a variable?


Arch + dwm   •   Mercurial repos  •   Surfraw

Registered Linux User #482438

Offline

#8 2017-12-24 22:38:20

Cody Learner
Banned
Registered: 2017-12-06
Posts: 54
Website

Re: aurora version number

Thanks for quick replies!

As to what you are actually trying to do, is it just capture the pkgver from makepkg's output and store it in a variable?

Yes exactly, along with the priories below.

I should have given more info .... I'm working on a git-less version of aurt now. Working on a "check for" update availability of AUR packages.

Started by trying to use cower, which gave mixed results per above. Then I did eventually finish up with using the Last Updated: "date", which per post above, is not a good direction.

Now I'm trying to continue on with a method to reliably "check for" AUR update availability, not necessarily do a git clone and test build just to determine IF there's an update available. Might as well just blindly update all the packages unless I'm mistaken.

I am using makepkg -do. I need to further investigate the options with using it. I didn't want to download all the patches, etc to just check for update availability. The only reason for this is to do "just enough" to obtain an accurate current package version availability.

Some priories:

1) Do not rely on git
2) Do not download any unnecessary data
3) Do not create any files, etc.

Just report to the user, an accurate assessment of AUR package update availability, so they may or may not be updated by/at the users discretion.

As a preliminary test, I used /tmp as a "for checking updates" disposable build directory. Eventually if I make this work, won't need a place to make and delete files, etc.

Yea, my shell skills are admittedly weak. Just trying proof of concept at this point, and hope to get better at scripting in the process.

Last edited by Cody Learner (2017-12-24 22:53:09)


Self designated Linux and Bash mechanic.....
I fix and build stuff hands on. I'm not opposed to creating a mess in obtaining a goal.

Offline

#9 2017-12-24 23:20:52

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,442
Website

Re: aurora version number

Cody Learner wrote:

I am using makepkg -do. I need to further investigate the options with using it. I didn't want to download all the patches, etc to just check for update availability. The only reason for this is to do "just enough" to obtain an accurate current package version availability.

Some priories:

1) Do not rely on git
2) Do not download any unnecessary data
3) Do not create any files, etc.

This is simply not possible.  First, you can't determine the new package version of VCS PKGBUILDs without running the pkgver function.  No building needs to be done, but the sources must be retrieved (the upstream source of what is to be packaged).  If you want to do this with makepkg, you must have any of the packaging materials (patches, install files, etc).  If you want to do this without makepkg, you'd end up just reimplementing much of makepkg.

Second, you can't do this without git for -git packages. Git is what determines the pkgver.  You could do this without git for mercurial packages, but those you couldn't do without hg.  And svn packages couldn't be done without svn.  There is no way around this.

`makepkg -od` will exit with an error if the proper aur packaging files are not present.  `makepkg -od` will also exit with an error if git is not present for a -git package.

You've asked how other aur helpers deal with this.  Every one I know of simply doesn't.  The only reasonable answer to whether or not an update is available for a vcs package can be determined with a very simple command:

/usr/bin/yes

This is not a coding issue: there is simply no agorithmic process to determine this answer other than to obtain the PKGBUILD and associated aur files, retrieve the upstream source, and run the pkgver function.

In any case there is absolutely no reason to filter the output of makepkg that way.  When makepkg is run on a vcs PKGBUILD it modifies the PKGBUILD putting the new version number in the pkgver variable field.  You could grep for that field, or even easier, just source the PKGBUILD and then the pkgver variable will be set.

In other words, after the steps I had in my previous post:

. ./PKGBUILD
echo $pkgver

Last edited by Trilby (2017-12-24 23:27:01)


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#10 2017-12-25 01:11:57

progandy
Member
Registered: 2012-05-17
Posts: 5,184

Re: aurora version number

Trilby wrote:

This is simply not possible.  First, you can't determine the new package version of VCS PKGBUILDs without running the pkgver function.  No building needs to be done, but the sources must be retrieved (the upstream source of what is to be packaged).  If you want to do this with makepkg, you must have any of the packaging materials (patches, install files, etc).  If you want to do this without makepkg, you'd end up just reimplementing much of makepkg.

Well, you probably could get away with comparing the commit id from the local version number with "git ls-remote $repo $branch". That should work as long as the package version includes the (abbreviated) commit id and minimizes the files to download.

I see no reason to do that, though. If you want to build the package, you'll need the sources either way. It is also preferable to retain git sources in a build directory between builds instead of cloning the repository each time, so a quick pull for an update check should not take long.

Edit: makepkg has an internal undocumented library for managing sources (/usr/share/makepkg/source.sh), so you probably could leverage that to extract the git url for ls-remote.

Last edited by progandy (2017-12-25 01:18:51)


| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |

Offline

#11 2017-12-25 01:55:24

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,442
Website

Re: aurora version number

progandy wrote:

you probably could get away with ... "git ls-remote $repo $branch".

That would work with a majority, but not all, -git PKGBUILDs.  But it would not work at all for any other vcs PKGBUILD.  So there'd need to be a different hackish solution to work with -hg packages, and it would similarly work for most but not all -hg packages.  Then there'd be another one for -svn, -bzr, -cvs, -fossil, etc, etc, not to mention having no way at all to deal with unspecified -dev or -nightly packages.  So to reiterate the most relevant part what my post that you quoted:

Trilby wrote:

If you want to do this without makepkg, you'd end up just reimplementing much of makepkg.

Don't make something broken then bit by bit add more and more hacks to fill in the gapping cracks in the initial design: just build something that isn't broken in the first place.

Running the pkgver function will work for all varieties of packages without any need to hunt around in the version string for what may be the commit id.

Last edited by Trilby (2017-12-25 01:59:08)


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#12 2017-12-25 07:44:08

Cody Learner
Banned
Registered: 2017-12-06
Posts: 54
Website

Re: aurora version number

OK, It's late and just got home from a family gathering, dinner, drinks etc... so no offense directed towards anyone with this. Trilby, Alad, and everyone else who has replied to my posts, nothing but respect for all you guys. Thank you! Would I be mistaken to say most of you guys either have BS, Masters, etc in computer science or if not something similar, and the rest fully capable if you wanted it? A compliment so no misunderstanding with that.

At this point I feel like I'm communicating in circles, with just enough cryptic info info being dispensed to lead me on a silly chase and or make me out to be more clueless than I am, which I have no problem admitting on a lot of this stuff. I'm a high school dropout and a much later in life associates degree holder in a field requiring one to get dirty in overalls. Have nothing to prove, but I’d really like to make a useful community contribution.

I've enjoyed Arch as a user for 8 or 9 years. I consider myself more tenacious than smart. It seems if I want or need to get something done, I always manage to find a way. Computers or life in general. Aurt started out as just an idea sparked by Trilby. I stared playing around with a script after not doing anything script related, other than a few lines here and there, for more than a year.  Found it amazing how simple it would be to implement a tiny script to replace my AUR helper. Posted the script the following day. I’ve learned quite a bit and enjoyed working on this so far.

If I had not posted the script, it honestly would have served my use case just fine after the second version. What happened is I started seeing it as an (enjoyable) challenge to get it right enough to get approval of those active in the Arch community. One for all us little guys using arch from the shadows.

Getting back on track, I thought I WAS running the pkgver function with running makepkg on the PKGBUILD. My bad. See above example with aurora.

I decided to ditch git simply because it's completely overwhelming for me to think about the time investment I'd need to put in to "REALLY" get me head around it. The time investment would likely exceed all the time combined, I've ever invested in computers as a hobby. My opinion is git is a VERY powerful, featureful, complex version control system ….. that has no place in package management. Development yes. Linus and followers are smart enough for git, Not so much myself. I also understand Arch does accommodate the developers feature implementations (ie git), if it is to continue as a viable project.

If git is really needed, or just wanted, come right out and say so. Now I'm thinking the pkgver function has a git requirement. And regarding git, if all you really smart people here cannot come to a consensus on how to implement git (commands to use), how the **** is someone like me supposed to “git” it right? Tell me how to properly implement git (commands), and its a done deal. If it's too high on the "not going to share" due to time investment, I also understand. So I ask just please be forthcoming with info if you already know it, and I'll implement whatever I'm capable of.


1) I don't know shit about version control, any of it. When you mention -dev, -cvs, git, whatever, it might as well be a foreign language I’ve overheard a few times. I know AUR and as a user, never needed to be concerned with version control.

3) I was never out to build THE BEST EVER helper script for AUR. If all AUR helpers have not accomplished proper implementation of cvs or whatever package version checking, I'm not interested it trying to "PROPERLY" solve and implement it... without much assistance. Way smarter people than myself would have done it by now if it was easy.

4) Not necessarily trying to build a BETTER mousetrap, just one that works for my work flow with a huge dose of KISS applied, and be simple in all categories including usage.

5) Of course I want to build it right without huge cracks or whatever in the design. If getting it "RIGHT" requires things way beyond my abilities, I'd honestly rather offer another broken but very useful and KISS AUR helper. The broken ones have served me well and saved me countless hours over the years.

Last edited by Cody Learner (2017-12-25 07:46:54)


Self designated Linux and Bash mechanic.....
I fix and build stuff hands on. I'm not opposed to creating a mess in obtaining a goal.

Offline

#13 2017-12-25 13:35:19

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,442
Website

Re: aurora version number

Hmm, reading this I'm worried I may have communicated poorly, so some inline responses:

Cody Learner wrote:

so no offense directed...

Absolutely none taken ... Frankly I couldn't find anything to be offended by in your posts if I went actively hunting for it.  If my posts have come accross harshly, that is not at all the intent.  I am known for being quite blunt - just as many nerds' tact filters mine is in reverse relative to "normal" people.

But I am quick to ignore anyone who posts here who I don't think is worth my time.  You in contrast seem not only eager to learn about scripting and the AUR, but also quite able to learn about these.  You are very much worth my time in helping!  I'm glad you are here.  I might give critical feedback forcefully If I'm confident the direction you are heading in will be counter-productive, but it is still intended only to be constructive.

Cody Learner wrote:

Would I be mistaken to say most of you guys either have BS, Masters, etc in computer science or if not something similar

I do have an advanced degree in the sciences, but technically the only computer class I've taken was in elementry school where we moved the LOGO turtle around drawing green-on-black shapes on an Apple IIe.  But I have acquired substantial proficiency in computers though.  Much of this has been gained through processes very much like what you are doing with your aur script: you see a problem you want to figure out and make a solution to.

What it takes to be a good hacker is the right mindset (hacker as in ESR's meaning, not the common-usage meaning of a criminal).  This mindset leads some people to pursue academic degrees, so perhaps many archers have higher educations; but the education is a result of the mindset, not a cause of it.  In fact I'm personally growing more and more displeased with our universities: they are starting to breed out this productive problem-solver mindset.  I've also found this hacker mindset leads many people into trades, particularly mechanical or construction related trades where they get to build things or fix problems (while getting dirty in overalls).

Cody Learner wrote:

... just enough cryptic info info being dispensed to lead me on a silly chase and or make me out to be more clueless than I am

The latter is certainly not the intent.  The former may feel frustrating, but some degree of that may be necessary: one doesn't learn something new without stepping out of their comfort zone.  But don't go on silly chases: go on informed chases after you get enough input to point you in the right direction.

Cody Learner wrote:

I’d really like to make a useful community contribution.

We'd love that too.  And I think I can speak for many here in saying we believe you will be able to.  The evidence of this belief is in the activity in your threads.  Your threads have been quite active.  I've said in another of your threads that I doubt anyone other than you is using your AUR tool in it's current form (but some may in the future once it developes nicely).  Yet many highly expereinced members of this community are actively commenting on your threads.  This could only be if they think you're as worth our time as I do.

When I look at your code, I don't say "wow this is great code, it could be really useful", because honestly it's not there yet.  But when I look at the way you are improving your code, I do say "wow, this guy could become a great coder, he could be really useful to our community."

Cody Learner wrote:

I consider myself more tenacious than smart

Experience comes to those tenacious enough to pursue it.

Cody Learner wrote:

It seems if I want or need to get something done, I always manage to find a way.

This may be about the most precise statement of the hacker mentality that I've ever seen smile

Cody Learner wrote:

I decided to ditch git simply because it's completely overwhelming for me

Nothing wrong with that.  And AUR helper can be a great success without bother to do anything at all with vcs PKGBUILD upate checks.  Unless it's hidden behind a flag I never used, cower completely ignores these.  When I would run `cower -u` it would only check for locally installed packages that had a newer version number present on the AUR web interface.  This completely misses any vcs packages, and that's ok!

So even without arriving at any solution to the topic of this thread, your AUR tool could be doing as well as cower.  You are now trying to go beyond what cower was capable of.  And if you don't know the background, cower's author is certainly no slouch.  He's not so active on the forums lately, but I'd aspire to be half as knowledgeable about arch linux and about coding as he is, and while no AUR helper is officially supported, cower was as near to a gold-standard of aur tool as one could get.  And it didn't identify vcs packages with available updates.

You are tackling a very hard problem.  It's relatively easy to do a pretty bad job of it, but frankly, it'd not really be worth doing a bad job of it.  You may get some easy solution patched together to worth with the aurora version number, but then it will fail on the next vcs package you come across.  Then you'll modify it to deal with that package, and it will work for a bit, but then fail on the next one.

Cody Learner wrote:

If git is really needed... come right out and say so. Now I'm thinking the pkgver function has a git requirement.

I'm saying so, for -git packages.  That might be the confusing part.  Git is not necessary for a majority of AUR packages.  There is a subset of aur packages, however, that have names ending in -git, or -bzr, or -hg, or any one of several other suffixes, where the pkgver variable in the PKGBUILD and on the web interface does not indicate the current version.  Each of these has it's only version control tool that would be needed to calculate the current version: git for -git packages, mercurial for -hg packages, fossil for -fossil packages, etc, etc.  But you don't actually need any of these installed before hand, as each PKGBUILD will list those vcs tools as dependencies.  So if you do not have git installed, but you get the qutebrowser-git PKGBUILD then run `makepkg -so` then makepkg will install git, obtain the sources, and update the pkgver variable.  If you want there is even a makepkg flag to remove git after that is done too.

Makepkg does all this for you from one simple command.  And it does it right, every time.

I'm worried that you are going to write a lot of hard-to-write and hard-to-debug code that will be time consuming and frustrating only to result in an outcome that will be right some modest portion of the time.  I suspect such an endeavor may end up stiffling your creativity and interest in learning more about scripting.  While I am all for aiming high, there is such thing as aiming too high too soon.

Cody Learner wrote:

I don't know shit about version control, any of it. When you mention -dev, -cvs, git, whatever, it might as well be a foreign language I’ve overheard a few times. I know AUR and as a user, never needed to be concerned with version control.

Nothing wrong with that.  And as suggested above, you don't need to learn about version control to write a great aur tool.  But if you write an aur tool with the goal of identifying updates in version-control-system packages, then you will need to learn about them.  I'd say stick with writing a great aur helper that doesn't bother detecting these updates.

Cody Learner wrote:

If all AUR helpers have not accomplished proper implementation of cvs or whatever package version checking, I'm not interested it trying to "PROPERLY" solve and implement it.

Would solving improperly be worth while?

I find the idea of signal to noise ratios useful.  Cower, does not tell me anything about vcs packge when I ask it what aur packages have updates.  It will never give me true information about them, but it will also never give me false information.  This is useful.  I know I need to check my vcs packages for updates myself manually.  If you build a tool that trys to give this information, but it doesn't do it properly, then is it useful?  Some portion of the time it will miss packages that have updates, some portion of the time it will say there are updates when there are not.  In the end it will be mostly noise with no discernable signal.  So the output it gives for vcs packages will not be useful.  Writing no code that is not useful is better than writing a lot of code that is not useful smile

Cody Learner wrote:

I'd honestly rather offer another broken but very useful and KISS AUR helper. The broken ones have served me well and saved me countless hours over the years.

Here's another point we may not be communicating well.  Not checking vcs package for updates does not mean an AUR helper is broken, it just means it has a nicely defined scope.  An aur helper that *says* it will check for vcs package updates and frequently fails to do so properly is what I'd call broken.  Define what problems you are solving, and solve them well.  (A corrallary of the unix philosophy for a tool to "do one thing and do it well").

---

Well this is quite a wall of text.  In short: we want you here; keep doing what you're doing.

Last edited by Trilby (2017-12-25 16:01:09)


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#14 2017-12-27 01:15:08

Cody Learner
Banned
Registered: 2017-12-06
Posts: 54
Website

Re: aurora version number

OK. sorry for my long rant. I'm honestly feeling quite embarrassed about posting it now.

Trilby, thank you for the very detailed reply. You've been communicating fine, I just don't always absorb and or get all the details. You sir have went well beyond being patient and very helpful. I feel back on track after reading it, thanks to you.

More importantly, you pointed me to some info that applies to everything in my life. I have always known, but never could put a name on it until now. My "tact filter" is definitely defective, and has an intermittent gaping hole in the filtering media, both directions. The link http://www.mit.edu/~jcb/tact.html was both funny and enlightening for me at the same time. Helped me come to terms with some of my own antisocial tendencies, and how I could mistakenly perceive it coming from others.

You've also motivated me to do some more general testing. I didn't realize the PKGBUILD file actually gets rebuilt, looked into pacman:

++ get_full_version
++ ((  epoch > 0  ))
++ printf '%s\n' 1.5.3-5
+ basever=1.5.3-5

Which led me (the long around to what you guys keep on saying) unless I'm mistaken (again). A bit of raw test code below. Need to figure out how to combine awk, general clean up, option to parsing long string w/ awk, etc, but hoping the end result is in the right direction this time. Was initially getting version from rebuild PKGBUILD, which turned out wrong, -5 was missing. More testing needed.

$ git clone https://aur.archlinux.org/aurutils.git
Cloning into 'aurutils'...
remote: Counting objects: 269, done.
remote: Compressing objects: 100% (181/181), done.
remote: Total 269 (delta 100), reused 243 (delta 88)
Receiving objects: 100% (269/269), 40.50 KiB | 216.00 KiB/s, done.
$ cd aurutils
$ LC_MESSAGES=C var=$(makepkg -o |& awk '/==> Making package:/{print substr($0,20)}' | awk '{print $2}')
$ echo $var
1.5.3-5

I've not yet looked into this, but need to do testing on all types of version control user for ARU packages. Is there a way to filter for this?


Self designated Linux and Bash mechanic.....
I fix and build stuff hands on. I'm not opposed to creating a mess in obtaining a goal.

Offline

#15 2017-12-27 01:19:45

jasonwryan
Anarchist
From: .nz
Registered: 2009-05-09
Posts: 30,424
Website

Re: aurora version number

makepkg -o && var=$(awk -F= '/pkgver/ {print $2}' PKGBUILD)

Arch + dwm   •   Mercurial repos  •   Surfraw

Registered Linux User #482438

Offline

#16 2017-12-27 02:10:21

Cody Learner
Banned
Registered: 2017-12-06
Posts: 54
Website

Re: aurora version number

Thanks Jason,

Wouldn't I need the -5, unless possibly changing to  "< " rather than "!=" in the test line?

$ makepkg -o && var=$(awk -F= '/pkgver/ {print $2}' PKGBUILD)
==> Making package: aurutils 1.5.3-5 (Tue Dec 26 17:54:14 PST 2017)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
  -> Downloading aurutils-1.5.3.tar.gz...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   121    0   121    0     0    121      0 --:--:-- --:--:-- --:--:--   295
100 17869  100 17869    0     0  17869      0  0:00:01 --:--:--  0:00:01 17869
  -> Downloading aurutils-1.5.3.tar.gz.asc...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   606    0   606    0     0    606      0 --:--:-- --:--:-- --:--:--  1481
100   228  100   228    0     0    228      0  0:00:01 --:--:--  0:00:01   228
  -> Found 0001-aurbuild-backport-fix-for-236.patch
  -> Found 0002-aurbuild-disable-verbose-signing.patch
  -> Found 0003-aursync-1-r-is-not-a-default-option.patch
==> Validating source files with sha256sums...
    aurutils-1.5.3.tar.gz ... Passed
    aurutils-1.5.3.tar.gz.asc ... Skipped
    0001-aurbuild-backport-fix-for-236.patch ... Passed
    0002-aurbuild-disable-verbose-signing.patch ... Passed
    0003-aursync-1-r-is-not-a-default-option.patch ... Passed
==> Verifying source file signatures with gpg...
    aurutils-1.5.3.tar.gz ... Passed
==> Extracting sources...
  -> Extracting aurutils-1.5.3.tar.gz with bsdtar
==> Starting prepare()...
patching file bin/aurbuild
patching file bin/aurbuild
patching file man1/aursync.1
==> Sources are ready.
$ echo $var
1.5.3 ("$pkgname-$pkgver.tar.gz::$url/archive/$pkgver.tar.gz"
$ awk -F= '/pkgver/{print $2}' PKGBUILD
1.5.3
("$pkgname-$pkgver.tar.gz::$url/archive/$pkgver.tar.gz"

$ awk -F= '/pkgver=/{print $2}' PKGBUILD
1.5.3
$ LC_MESSAGES=C var=$(makepkg -o |& awk '/==> Making package:/{print substr($0,20)}' | awk '{print $2}')
$ echo $var
1.5.3-5

Last edited by Cody Learner (2017-12-27 02:19:59)


Self designated Linux and Bash mechanic.....
I fix and build stuff hands on. I'm not opposed to creating a mess in obtaining a goal.

Offline

#17 2017-12-27 02:20:48

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,442
Website

Re: aurora version number

The -5 is the pkgrel.  Try this instead:

makepkg -o
. ./PKGBUILD
var="${pkgver}-${pkgrel}"
echo $var

"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#18 2017-12-27 16:34:53

eschwartz
Fellow
Registered: 2014-08-08
Posts: 4,097

Re: aurora version number

Or if you really like awk and/or don't want to source PKGBUILDs into the current shell context (I guess in theory they can contain anything, and possibly overwrite e.g. functions that are part of your script) you could use makepkg --printsrcinfo and use awk to extract information from there. smile

It is certainly more reliable than using awk on the PKGBUILD itself, which is a bash script and can have e.g. pkgname=${_pkgname}-git, or for packages that do not have a pkgver() function,

_commit=72491556de024948b765ff875ffb3c18e255538f
pkgver=1.2.3.r45.g${_commit:0:8}
source=("https://github.com/user/repo/archive/${_commit}.tar.gz")

Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

#19 2017-12-27 16:58:03

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,442
Website

Re: aurora version number

I hadn't thought of using the SRCINFO, that's definitely a better approach.  `makepkg -o` still needs to be run.  Then this would assemble pkgver and pgrel:

makepkg --printsrcinfo | sed -n '/\s*pkg[vr]e[rl]/{s/[^=]*= //;H}; ${x;s/\n//;s/\n/-/p}'

"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

Board footer

Powered by FluxBB