Package Details: downgrade 5.3.1-1

Git Clone URL: https://aur.archlinux.org/downgrade.git (read-only)
Package Base: downgrade
Description: Bash script for downgrading one or more packages to a version in your cache or the A.R.M.
Upstream URL: https://github.com/pbrisbin/downgrade
Licenses: GPL
Submitter: brisbin33
Maintainer: brisbin33
Last Packager: brisbin33
Votes: 404
Popularity: 5.734805
First Submitted: 2009-11-12 01:48
Last Updated: 2016-11-19 21:23

Dependencies (1)

Required by (2)

Sources (1)

Latest Comments

brisbin33 commented on 2016-10-18 21:57

I just tested and everything seems to be working here. I've never seen that message and don't know anything about it unfortunately. If this persists, please open an Issue on GitHub with the full output of

bash -x downgrade ...

Thanks.

maclinuxfree commented on 2016-10-17 14:19

hi I´m getting this error

"A.L.A. disabled see https://wiki.archlinux.org/index.php/downgrading_packages for more details"

downgrader is working

brisbin33 commented on 2016-02-01 15:45

FadeMind, I'm a little unclear: is there something here I need to fix?

I just did `pacman -Rsn downgrade && aurget -S downgrade` and did not receive any warnings.

FadeMind commented on 2016-02-01 13:54

warning: could not get file information for foo/bar.mo just mean:

FILE foo/bar.mo is included in package foobar-12.01-2 BUT pacman can't find it during upgrading proccess.

tl;dr:

IF You using bleachbit for removing not needed language files, then this will show up as warning.

quite commented on 2016-02-01 13:49

Getting this warning on installation:

(1/1) checking available disk space [#####################################################] 100%
warning: could not get file information for usr/share/locale/fr/LC_MESSAGES/downgrade.mo
warning: could not get file information for usr/share/locale/lt/LC_MESSAGES/downgrade.mo
warning: could not get file information for usr/share/locale/nb/LC_MESSAGES/downgrade.mo
warning: could not get file information for usr/share/locale/nn/LC_MESSAGES/downgrade.mo
warning: could not get file information for usr/share/locale/pt_BR/LC_MESSAGES/downgrade.mo
warning: could not get file information for usr/share/locale/zh_CN/LC_MESSAGES/downgrade.mo
:: Processing package changes...

brisbin33 commented on 2014-09-17 18:57

Seems reasonable. I'll put this on my list of TODOs.

If you're feeling particularly generous, opening such a change as a PR on GitHub would be wonderful :)

TrialnError commented on 2014-09-17 18:33

In the "AUR-Wikipage"[0] and "Arch Packaging Standards"[1] they describe what a tarball should contain.
And there were on AUR-General ML some topics on that (over the years)[2][3][4] (I point to posts, where they try to describe the term binary in case of interpreted languages).
And since it's more or less the whole project in there I suppose it's too much.

What would it mean for your PKGBuild? Just minor changes:
https://gist.github.com/Narrat/b7dd7fd0658e6e13f208#file-downgrade-pkgbuild

One minor notice to your makefile.
Instead of the "sed'ing + makepkg --geninteg" you could use "updpkgsums" (comes with pacman) and is doing the same.
______
[0] https://wiki.archlinux.org/index.php/AUR#Sharing_and_maintaining_packages
[1] https://wiki.archlinux.org/index.php/Arch_packaging_standards
[2] https://mailman.archlinux.org/pipermail/aur-general/2010-December/012342.html
[3] https://mailman.archlinux.org/pipermail/aur-general/2012-December/021380.html
[4] https://mailman.archlinux.org/pipermail/aur-general/2012-December/021290.html

_____
Edit: gist-url not working

TrialnError commented on 2014-09-17 18:23

In the "AUR-Wikipage"[0] and "Arch Packaging Standards"[1] they describe what a tarball should contain.
And there were on AUR-General ML some topics on that (over the years)[2][3][4] (I point to posts, where they try to describe the term binary in case of interpreted languages).
And since it's more or less the whole project in there I suppose it's too much.

What would it mean for your PKGBuild? Just minor changes:
https://gist.github.com/Narrat/b7dd7fd0658e6e13f208

One minor notice to your makefile.
Instead of the "sed'ing + makepkg --geninteg" you could use "updpkgsums" (comes with pacman) and is doing the same.
______
[0] https://wiki.archlinux.org/index.php/AUR#Sharing_and_maintaining_packages
[1] https://wiki.archlinux.org/index.php/Arch_packaging_standards
[2] https://mailman.archlinux.org/pipermail/aur-general/2010-December/012342.html
[3] https://mailman.archlinux.org/pipermail/aur-general/2012-December/021380.html
[4] https://mailman.archlinux.org/pipermail/aur-general/2012-December/021290.html

brisbin33 commented on 2014-09-17 15:27

TrialnError,

I had not heard that discussion or that it's a best practice to not include sources in the taurball anymore. Do you have a link?

It's easy enough to change things to work the other way if there's a compelling reason to do so.

As a sidenote - tagging releases in a VCS and what does or does not go into the taurball are orthogonal in my mind; I'll always tag releases in git regardless of how I'm packaging things.

TrialnError commented on 2014-09-17 09:20

I'm just wondering
You have a git-repo with tagged releases, still you put everything into the tarball, which should be avoided as far as I know (altough there were enough discussions in case of: "Oh, it's just bash-scripts, so that should be ok").

brisbin33 commented on 2014-06-17 14:38

I don't follow. Root permissions are required to install packages. Downgrade escalates for only this step via sudo or su.

What are you expecting?

barton commented on 2014-06-17 08:12

Seems to run with root permissions from my user account. Anyone else see that?

brisbin33 commented on 2014-05-31 12:26

FYI: if you know the time and package, you can easily get the version out of pacman.log.

neverfox commented on 2014-05-31 06:36

Seriously, @SanskritFritz? The only feedback should come from other package maintainers? So if someone maintained all the packages, the ultimate pinnacle of Arch dedication, they could give feedback to themselves?

neverfox commented on 2014-05-31 06:31

I agree with nonerd. I don't keep that close of a tab on version numbers, but I can determine with pretty decent accuracy when I last had a working package.

nonerd commented on 2014-05-17 15:13

When an application is broken after several system updates (pacman -Syu) you typically know _when_ it was working, but not which library versions you had then.
So without downgrade(r) one browses the A.R.M. and looks at the package timestamps - yes they are there.

Anyway thanks for the package! Maybe I'll have a use case in the future...

brisbin33 commented on 2014-05-17 12:55

> Would be more useful when listing package dates and supporting a --date option.

Sorry, I don't think I'll implement this. I'm not sure the info's available and this tool is meant to stay as simple as possible. If it can be done in an extremely simple way, I would certainly review a PR though.

Also, when you research a problem and decide downgrading is the solution, you'll typically know to what version you have to downgrade. I don't see the usefulness of dates here.

nonerd commented on 2014-05-17 11:40

@SanskritFritz: Suggestions for improvement are not meant as troll food.

SanskritFritz commented on 2014-05-17 10:27

@nonerd: Would be useful if you actually did maintain at least one package for reference we all could learn from.

nonerd commented on 2014-05-17 06:01

Would be more useful when listing package dates and supporting a --date option.

brisbin33 commented on 2014-01-13 20:44

I think it's fixed. Sorry!

brisbin33 commented on 2014-01-13 20:34

Ah crap, I do less testing on the bash-completion since I'm a zsh user. Let me see if I can figure it out...

dhaines commented on 2014-01-13 20:32

I'm getting this with the newest version:

-bash: /etc/bash_completion.d/downgrade: line 5: syntax error near unexpected token `;;'
-bash: /etc/bash_completion.d/downgrade: line 5: ` COMPREPLY=($(compgen -W "$(pacman -Qqs "^$cur")")) ;;'

brisbin33 commented on 2014-01-13 19:06

Dropped v5 -- greatly simplified and thus changed usage. See man downgrade for details.

brisbin33 commented on 2013-09-25 13:37

WovenTales,

I'd love to give downgrade some sort of --provider option or maybe just use an ARM_SOURCE environment variable, but the alternate sources would have to offer the same interface as the current source.

Do you know what kind of interface/API iprimus is offering?

WovenTales commented on 2013-09-25 02:38

I'm not sure how easy it would be to adapt the program for (and not sure it has a built-in search function), but mirror.iprimus.com.au/archlinux/ seems to have a good selection of old packages, which a lot of the newer ARM clones are still lacking.

raining commented on 2013-09-23 05:08

@brisbin33
Issue : downgrade does not work when multiple dirs is used in CacheDir in pacman.conf. Also reported on github.

brisbin33 commented on 2013-08-27 13:27

P67 (and everyone),

My understanding is the old ARM site went dark unexpectedly and no one has been able to get access to the older packages that were there. I would assume the new site will only ever have packages as old as when it was started (which is recent).

If you're really stuck, you might be able to checkout old revisions of the git PKGBUILDs to build/install what you need (and its deps ofcourse).

Good luck.

P67 commented on 2013-08-27 10:20

brisbin33: Is the new A.R.M also going to contain the old packages the old A.R.M. had in it? I feel a need to go back to a 3.6 kernel to test some things out.. But the A.R.M does not contain them.

brisbin33 commented on 2013-08-25 03:50

scorici, well thanks to phoenixlzx we have a new A.R.M. site and downgrade's already been updated to access it for non-local packages.

Hope it works for you.

scorici commented on 2013-08-25 03:31

Now downgrade is able to find local packages even if cachedir is a symlink.
Thank you for the fix.
This fix is really necessary for me since the Arch Rollback Machine has closed on 2013-08-18 and we rely only on local packages =(

brisbin33 commented on 2013-08-25 00:50

xpixelz, implemented in 4.1-1.

This may or may not also fix your issue scorici, let me know.

Thanks,
Pat

xpixelz commented on 2013-08-21 10:26

CacheDir is not taken into account when set manually in pacman.conf please.

scorici commented on 2013-04-18 08:26

If /var/cache/pacman/pkg is a symlink then downgrade won't find local packages unless at line 81 you add a slash at the end of cache directory:
"find /var/cache/pacman/pkg" ==> "find /var/cache/pacman/pkg/"
I have symlinked /var/cache/pacman/pkg to a folder in my /home partition to not fill the small system partition.

brisbin33 commented on 2013-01-17 14:55

HolyTux,

Do you truly want customization or would you just prefer i swapped the hardcoded wget with a hardcoded curl?

I'll consider the former, but will probably be doing the latter soon anyway.

HolyTux commented on 2013-01-13 21:56

Please add an option to use another download-manager or if it's possible tell me how to do it! (i'd be very happy :D)

brisbin33 commented on 2012-11-14 22:03

[opt]depends updated in 3.2-2. thanks.

tonyskn commented on 2012-11-11 13:30

Please add wget to dependencies

paalsteek commented on 2012-09-13 07:06

Please add wget as a dependency.

SanskritFritz commented on 2012-07-25 05:36

Request filed on github.

donvla commented on 2012-05-14 18:02

Hello brisbin33,

I added support for other repositories to pkgman.
However, one has to select the repository for the given package by hand.
An automated search is not so easy - you have to retrieve each repository site and grep for the package.
That's too much overhead.
It would be nice if kumyco adds direct search through the search site.

brisbin33 commented on 2012-05-14 12:27

downgrade will respect your enabled repos from pacman.conf and pass them along to the ARM search. However, the ARM search itself does not seem to support those repos in its search tool.

You'll notice that multilib/flashplugin is visible in the repo listing[1] but doesn't show up in search[2]. It seems only those repos shows on the "GUI" search tool[3] are supported.

1: http://arm.konnichi.com/multilib/os/x86_64/
2: http://arm.konnichi.com/search/raw.php?a=64&q=^flashplugin$&multilib=1
3: http://arm.konnichi.com/search/

If kumyco sees this, perhaps he can comment on adding that support. I'm not sure I want to work around it.

donvla commented on 2012-05-12 12:02

Hello Brisbin33,
is it possible to search in the "multilib" repo?

brisbin33 commented on 2012-04-21 19:04

yeah, it's a tab-separated issue. would you mind playing with the rewrite branch on github[1]?

a) i'd like a second tester and b) it's using printf and should be real easy to tweak the format string[2] to something better.

thanks.

1: https://github.com/pbrisbin/downgrade/tree/rewrite
2: https://github.com/pbrisbin/downgrade/blob/rewrite/downgrade#L98

karol_007 commented on 2012-04-21 18:58

Thanks again, brisbin :-)

Do you know how to print it in pretty columns?

The following packages are available from the A.R.M.:
1 extra___erlang-R14B-2-i686.pkg.tar.xz
2 extra___erlang-R14B-1-i686.pkg.tar.xz
3 extra___erlang-R14B04-2-i686.pkg.tar.xz
4 extra___erlang-R14B04-1-i686.pkg.tar.xz
5 extra___erlang-R13B-2-i686.pkg.tar.gz
6 extra___erlang-R13B04-3-i686.pkg.tar.xz
7 extra___erlang-R13B04-2-i686.pkg.tar.gz
8 extra___erlang-R13B04-1-i686.pkg.tar.gz
9 extra___erlang-R13B03-1-i686.pkg.tar.gz
10 extra___erlang-R13B02.1-1-i686.pkg.tar.gz
11 community_______erlang-R14B04-2-i686.pkg.tar.xz
12 community-testing_______erlang-R15B01-1-i686.pkg.tar.xz

I've used underscores instead of spaces because AUR strips whitespace.

karol_007 commented on 2012-04-21 18:56

Thanks again, brisbin :-)

Do you know how to print it in pretty columns?
The following packages are available from the A.R.M.:
1 extra erlang-R14B-2-i686.pkg.tar.xz
2 extra erlang-R14B-1-i686.pkg.tar.xz
3 extra erlang-R14B04-2-i686.pkg.tar.xz
4 extra erlang-R14B04-1-i686.pkg.tar.xz
5 extra erlang-R13B-2-i686.pkg.tar.gz
6 extra erlang-R13B04-3-i686.pkg.tar.xz
7 extra erlang-R13B04-2-i686.pkg.tar.gz
8 extra erlang-R13B04-1-i686.pkg.tar.gz
9 extra erlang-R13B03-1-i686.pkg.tar.gz
10 extra erlang-R13B02.1-1-i686.pkg.tar.gz
11 community erlang-R14B04-2-i686.pkg.tar.xz
12 community-testing erlang-R15B01-1-i686.pkg.tar.xz

brisbin33 commented on 2012-04-21 17:27

I believe I've address all recent concerns in 2.1 :) -- let me know if I broke anything.

karol_007 commented on 2012-04-20 18:12

Sorry for not providing any explanation for my request in the first comment ;P

brisbin33 commented on 2012-04-20 16:26

Thanks karol, now I understand the real problem. I'd propose that we uniq the output based on the package-version. It could get tricky since it might show the testing one and not the core one... But if it can be done, I think that would be the sanest behavior (pkgs that were in both x and testing are not shown duplicated, but pkgs that existed only in testing are available -- assuming you've got it enabled).

karol_007 commented on 2012-04-20 16:13

I have [testing] enabled and when I search the A.R.M. for e.g. 'linux' I get many packages listed both in testing and in core. I'd prefer a listing based on package versions, like this:
The following packages are available from the A.R.M.:
1 core linux-3.3.2-1-i686.pkg.tar.xz [installed]
2 core linux-3.3.1-1-i686.pkg.tar.xz
3 testing linux-3.3-1-i686.pkg.tar.xz
4 core linux-3.2.14-1-i686.pkg.tar.xz
...
instead of

The following packages are available from the A.R.M.:
1 testing linux-3.3.2-1-i686.pkg.tar.xz [installed]
2 testing linux-3.3.1-1-i686.pkg.tar.xz
3 testing linux-3.3-1-i686.pkg.tar.xz
4 testing linux-3.2.11-1-i686.pkg.tar.xz
...
33 core linux-3.3.2-1-i686.pkg.tar.xz [installed]
34 core linux-3.3.1-1-i686.pkg.tar.xz
35 core linux-3.2.14-1-i686.pkg.tar.xz

It's not a big deal and I know I can simply temporarily disable [testing] in pacman.conf if I don't mind losing the availability of certain package versions (e.g. it seems linux-3.3-1 never went to [core]).

brisbin33 commented on 2012-04-20 13:39

karol,

good catch on -V, i've noticed that before but never took the time to fix it when i did. about testing repo, it's not that there's a strong reason for it -- it's that i see no reason to omit it (and it would take more code to take it out). is it causing any problems?

fdservices,

thank you. is this to catch packages with a double-digit major version? if so, we could probably use -[0-9]*.pkg.tar.[gz]x and be safe in all cases -- thoughts?


FYI: to all current/future collaborators -- I'll be moving downgrade to its own repo soon to make it easier for others to submit these sorts of fixes. Thanks for all the help!

fdservices commented on 2012-04-20 09:13

Nice script.
I think that search_local should find "$term-[0-9]*.*.pkg.tar.[gx]z" and not "$term-[0-9].*.pkg.tar.[gx]z" though.

karol_007 commented on 2012-04-19 21:22

Thanks for updating your script, brisbin :-)
I have forked your scripts repo and suggested a small fix (sort -rV instead of sort -r) to get the versions sorted correctly.

I also wanted to ask you if there's a reason to include testing repos in enabled_repos().

brisbin33 commented on 2012-02-27 19:31

Thanks for the suggestions AlexanderR and karol; unfortunately I've been a bit busy lately so I'm not sure when I'll get to these. If you would like to fork my scripts repo and add the fixes yourselves, that's one way to help speed this up. It's a fairly simple script.

AlexanderR commented on 2012-02-11 05:17

This tool is great, but could you please make it to use su when sudo is not present (like makepkg does)?

karol_007 commented on 2012-02-11 00:17

The following packages are available from the A.R.M.:
1 testing ffmpeg-26387-1-i686.pkg.tar.xz
2 testing ffmpeg-20120127-2-i686.pkg.tar.xz.sig
3 testing ffmpeg-20120127-2-i686.pkg.tar.xz
4 testing ffmpeg-20111108-1-i686.pkg.tar.xz.sig
5 testing ffmpeg-20111108-1-i686.pkg.tar.xz
6 testing ffmpeg-20111105-1-i686.pkg.tar.xz.sig
7 testing ffmpeg-20111105-1-i686.pkg.tar.xz
...

How to best deal with the signatures? Would
#arms=( $(wget -q -O - "$url" | sort -r) )
arms=( $(wget -q -O - "$url" | grep -v sig$ | sort -r) )
work?

Anonymous comment on 2011-07-04 06:33

Fantastic! Thanks so much for this darn handy utility. It was sure a blessing to me.

archman commented on 2011-02-17 19:07

Thanks for this amazing app!

LeCrayonVert commented on 2011-02-09 23:00

brisbin33 > dunno, I've just noticed it today ;)

brisbin33 commented on 2011-02-09 21:45

Thank you, updated. When did that change?

LeCrayonVert commented on 2011-02-09 20:18

Please replace the url in the downgrade script with :

line 92 url="http://arm.konnichi.com/search/raw.php?a=$arch&q=^$term\$$repos"

Anonymous comment on 2010-12-06 18:36

I am a robot. This is not an official message. AUR guidelines suggest to not include binaries. You have accidentally tarred up some dotfiles. Examples:
..tar.gz
downgrade/..tar.gz
Suggestion: use "makepkg --source". Feel free to disregard this as you would any other comment. This robot will not post here again.

LeCrayonVert commented on 2010-09-03 12:02

Got timeout error when trying to download from 66.30.118.211 (pbrisbin.com).

brisbin33 commented on 2010-05-20 13:34

exiting 0 on no results is a bug in my opinion, i'll change that soon. as for the second part, you need to choose a package to downgrade to. even if there's only one result you still have to type "1" and hit enter. maybe a feature request to default choice to 1 or something...

i will update the script to handle the 'bad array subscript' more kindly though.

brisbin33 commented on 2010-05-20 13:28

exiting 0 on no results is a bug in my opinion, i'll change that soon. as for the second part, you need to choose a package to downgrade two. even if there's only one result you still have to type "1" and hit enter. maybe a feature request to default choice to 1 or something...

i will update the script to handle the 'bad array subscript more kindly' though.

WiZeTeK commented on 2010-05-20 00:11

Fair enough. I appreciate the quick response.

$ downgrade mocp

$ echo $?
0

$ downgrade moc

The following packages are available in your cache:
1 local moc-2.4.4-1-i686.pkg.tar.xz [installed]

please choose a version, type s to [s]earch A.R.M.: <I just hit ENTER>
/usr/bin/downgrade: line 62: LOCALS: bad array subscript
error: invalid choice, quitting...

brisbin33 commented on 2010-05-18 14:20

thanks for the comment MajorTom.

i just uploaded a new version, please update. i tested by downgrading zenity from my cache and ARM and it worked (but it worked for me before too...). let me know if you have issues.

as for the other things, i don't plan on implementing colorized output (you can set PACMAN to pacman-color in the script if you'd like to color that). also, how would single keystroke entry work if you've got a list of available packages > 10?

also, please note that the ARM maintainer is handing that project off to someone else (there's a forum post somewhere...) so i can't guarantee this script won't get rocky throughout the transition.

it is useful though, so once the ARM situation settles, i'll be sure to get this script working (if needed).

WiZeTeK commented on 2010-05-18 03:39

This tool is a really good idea. Any plans to improve it a little, time permitting of course?

I have just tried 'downgrade mocp' and the script simply exited with no errors. It looks like the exit code was 0. Later I realized the package name for mocp was actually "moc".

I was then forced to go back to the latest version of moc, so I thought WTH I'll use 'downgrade' again. I got this:

$ downgrade moc

The following packages are available in your cache:
1 local moc-2.4.4-1-i686.pkg.tar.xz

please choose a version, type s to [s]earch A.R.M.: 1
error: invalid choice, quitting...

Hmmm. Anyway, some other enhancements I wish for: colorized output, single keystroke input (achievable with 'read -n 1 VARNAME')

Thanks Pat.