Package Details: gstreamer0.10-base 0.10.36-9

Git Clone URL: (read-only)
Package Base: gstreamer0.10-base
Description: GStreamer Multimedia Framework Base plugin libraries
Upstream URL:
Licenses: LGPL
Submitter: yurikoles
Maintainer: nicepack
Last Packager: yurikoles
Votes: 64
Popularity: 12.826551
First Submitted: 2017-01-26 13:45
Last Updated: 2017-02-20 13:18

Sources (7)

Latest Comments

Popolon commented on 2017-09-20 17:40

.SRCINFO does not march PKGBUILD !
.SRCINFO : pkgrel=9
PKGBUILD : pkgrel=10

claudiodangelis commented on 2017-09-18 17:05

I'll just leave it here for pacaur users like me who are unable to install this package:

git clone --depth=1
cd gstreamer0.10-base
sudo pacman -U gstreamer0.10-base-0.10.36-10-x86_64.pkg.tar.xz gstreamer0.10-base-plugins-0.10.36-10-x86_64.pkg.tar.xz

Eschwartz commented on 2017-09-03 01:57


Yes, requests to update the package are valid, for some minor value of valid. Mismatched AUR RPC data kind of sucks because it is difficult to know just from reading the AUR, what version a package is at.

That is only relevant to aurweb. Once a person downloads a package, possibly through an AUR helper, and attempts to interact with it, the .SRCINFO's job is long since done.
Can we be clear about one thing here? The one and only singular reason for .SRCINFO to exist is in order for aurweb, and others, to know about package metadata without risking the execution of arbitrary and potentially malicious bash scripts.

In the specific case of this package, it doesn't matter as the only valid pkgrel bump was -4 and therefore it doesn't matter if users aren't able to detect updates through the RPC.

Your helper is buggy, and turns molehills into mountains. Please stop feeding lies to your users and turning yourself and your project into a source of misinformed, clueless users.

"Check .SRCINFO for mismatching data with PKGBUILD" is not a valid reason for pacaur to abort a pacman transaction. The fact that you think you need a .SRCINFO only shows that you don't understand makepkg as well as you think you do.

@all, please stop conflating two issues.

The fact that pacaur fails to install this package is due to a pacaur bug that the pacaur developer refuses to admit is a bug, and *not* due to the unrelated issue that this package does not properly register *on the RPC interface* as having an available update.

Scimmia commented on 2017-09-02 17:38

The alternative is to not do stupid crap. You're trying to do too much. Stop.

Yes, the .SRCINFO should be updated, but it's extremely minor, to the point of being nearly a non-issue.

Spyhawk commented on 2017-09-02 10:08

@Scimmia> I don't want to go into the details of the implementation here (because this is not the place among other things) but the alternatives are basically shipping a patched makepkg or trusting the info provided by the maintainer. Feel free to ask details in the forums.

The info provided by the .SRCINFO is *wrong*, pure and simple, and it should be updated. This is the very reason why the version displayed on top of this present AUR page is also *wrong* (0.10.36-9 instead of 0.10.36-10).

All requests to update this package are valid.

Scimmia commented on 2017-09-02 04:15

Aborting because of that is idiotic behavior, plain and simple.

Spyhawk commented on 2017-09-01 20:20

"Idiotic helpers" have a problem because they expect maintainers not to forget to update the .SRCINFO file. Otherwise, the version read through the secure RPC interface is wrong.

This has nothing to do with the -git extension, as this package refers to a specific commit.

Scimmia commented on 2017-08-28 16:56

It's installable just fine, it's only idiotic helpers that have a problem

swalladge commented on 2017-08-28 03:22

Please update the .SRCINFO file for this package - it is currently not installable.

abryrath commented on 2017-07-28 01:00

I had to update pkgrel = 10 in .SRCINFO to get this package to install without error.

All comments