Package Details: downgrade 11.2.1-1

Git Clone URL: https://aur.archlinux.org/downgrade.git (read-only, click to copy)
Package Base: downgrade
Description: Bash script for downgrading one or more packages to a version in your cache or the A.L.A.
Upstream URL: https://github.com/archlinux-downgrade/downgrade
Licenses: GPL
Submitter: brisbin33
Maintainer: brisbin33 (atreyasha)
Last Packager: atreyasha
Votes: 661
Popularity: 7.84
First Submitted: 2009-11-12 01:48 (UTC)
Last Updated: 2022-06-13 14:33 (UTC)

Required by (0)

Sources (1)

Latest Comments

brisbin33 commented on 2022-03-02 13:41 (UTC)

Yup, I've reported the Issue here. Please follow if you would like to know when it's fixed.

Archanfel80HUN commented on 2022-03-02 12:47 (UTC)

The x86-64-v3 level enables AVX, AVX2, BMI2, MOVBE, XSAVE, and other instructions found on Intel and AMD processors of the past several years. Its basically packages builds optimized for newer processors, instead of the generic one which is for compatibility. Using v3 builds could provide 5-10% percformance gain especially in kernels and dkms modules.

Archanfel80HUN commented on 2022-03-02 11:53 (UTC)

@brisbin33: yes, print only the firt result should work: $(pacman-conf Architecture | grep -m1 '')

or maybe a nicer alternative, but something like this :)

brisbin33 commented on 2022-03-02 11:48 (UTC)

there was no + in the package name. its the 'mc'.

Oh, sorry about that. I saw Unable to downgrade mc+ echo in that log.

results with two option in my system: "x86_64 x86_64_v3" because i have repo's with different arch. This not handled well i think

Indeed! Good catch,

+ DOWNGRADE_ARCH='x86_64
x86_64_v3'

instead of "pacman-conf Architecture" use "uname -m".

That's what we used to do, but there are reasons it doesn't work in other cases.

i have repo's with different arch

I don't know the purpose of this, or how downgrade should behave in such a case, but would taking the first result (x86_64) always be the most correct thing we can do? That's an easy fix.

Archanfel80HUN commented on 2022-03-01 23:08 (UTC) (edited on 2022-03-01 23:10 (UTC) by Archanfel80HUN)

Or maybe this: instead of "pacman-conf Architecture" use "uname -m". The second one only shows system arch, not shown the custom arch's. It did show only x86_64 correctly for me.

P

Archanfel80HUN commented on 2022-03-01 23:02 (UTC)

Find the issue: @@ -462,13 +462,13 @@ # Set script defaults PACMAN="pacman" PACMAN_CONF="/etc/pacman.conf" -DOWNGRADE_ARCH="x86_64" +DOWNGRADE_ARCH="$(pacman-conf Architecture)" DOWNGRADE_ALA_URL="https://archive.archlinux.org" DOWNGRADE_FROM_ALA=1 DOWNGRADE_FROM_CACHE=1 DOWNGRADE_MAXDEPTH=1 DOWNGRADE_CONF="/etc/xdg/downgrade/downgrade.conf" -DOWNGRADE_VERSION="10.1.0" +DOWNGRADE_VERSION="10.1.1"

# Main code execution if ((!LIB)); then

This command 'pacman-conf Architecture' results with two option in my system: "x86_64 x86_64_v3" because i have repo's with different arch. This not handled well i think.

Workaround is change the DOWNGRADE ARCH to static "x86_64" and its works.

P

Archanfel80HUN commented on 2022-03-01 22:50 (UTC)

@brisbin33 there was no + in the package name. its the 'mc'. i pick a simple one. It didnt work neither.

brisbin33 commented on 2022-02-28 16:31 (UTC)

Thanks, the + in the package name is confusing it. Please report it on GitHub, otherwise I can, but it may take me a little while to get to it.

Archanfel80HUN commented on 2022-02-28 15:26 (UTC)

Here is the full log: https://pastebin.com/7RD6Tx2X

brisbin33 commented on 2022-02-27 19:14 (UTC)

Hi Archanfel,

Can you please include the full command you're running? Prefixing with bash -x downgrade ... can be useful too.

Also, if you would like faster response, please report issues on GitHub.

Thanks, Pat

Archanfel80HUN commented on 2022-02-25 14:25 (UTC) (edited on 2022-02-25 14:30 (UTC) by Archanfel80HUN)

I have an issue, nothing works: sed: -e expression #1, character 49: invalid regexp

version: 11.0.0

downgraded to 10.0.0, works fine again

vinibali commented on 2021-03-15 20:10 (UTC)

Oh, sorry... I missed the target, I was talking about the localepurge :)

brisbin33 commented on 2021-03-15 14:31 (UTC)

vinibali,

Hmm, are you sure?

% curl -L -I https://github.com/pbrisbin/downgrade/archive/v9.0.0.tar.gz
HTTP/2 302 
{snip}

HTTP/2 200 
access-control-allow-origin: https://render.githubusercontent.com
content-disposition: attachment; filename=downgrade-9.0.0.tar.gz
content-security-policy: default-src 'none'; style-src 'unsafe-inline'; sandbox
content-type: application/x-gzip
etag: "b3209e65e127f05cce875595397fee88d4ffbaaaadaee336e9c6f8faf72eb223"
strict-transport-security: max-age=31536000
vary: Authorization,Accept-Encoding
x-content-type-options: nosniff
x-frame-options: deny
x-xss-protection: 1; mode=block
date: Mon, 15 Mar 2021 14:30:36 GMT
x-github-request-id: A724:1C49:ED889:265F28:604F6F8B

vinibali commented on 2021-03-14 18:44 (UTC)

Hello! The URL is not available, 7.3.{4,5,10} is only available. Can you please fix it?

brisbin33 commented on 2020-02-14 20:00 (UTC)

Done.

haawda commented on 2020-02-14 19:38 (UTC) (edited on 2020-02-14 19:41 (UTC) by haawda)

Can you please do what phillid suggested? Also, please use positive integers for pkgrel, not 0.

yrlf commented on 2020-01-12 12:12 (UTC) (edited on 2020-01-12 13:15 (UTC) by yrlf)

The downgrade script does not yet have support for the new .zst package compression. It just doesn't find packages with that extension.

EDIT: fixed by my PR, will be merged on monday according to pbrisbin

merlock commented on 2019-10-11 22:11 (UTC) (edited on 2019-10-11 22:11 (UTC) by merlock)

Hi @brisbin33...

Both pacman -Qi and which showed gettext installed.

Re-installed gettext, that seemed to fix the problem.

Don't know if the recent changes to base had anything to do with it.

Thanks for the quick reply!

brisbin33 commented on 2019-10-11 20:12 (UTC)

Hi merlock,

gettext is a package in the base and base-devel groups, which AUR package can assume is installed (i.e. it need not be in dependencies). Somehow you seem to either have lost that package, or something is off with your environment variables?

What does pacman -Qi gettext say? How about which gettext?

merlock commented on 2019-10-11 16:18 (UTC) (edited on 2019-10-11 16:19 (UTC) by merlock)

Haven't used it for a while, but this happened today:

 downgrade pkgfile
/usr/bin/downgrade: line 3: gettext.sh: No such file or directory
/usr/bin/downgrade: line 36: gettext: command not found


/usr/bin/downgrade: line 142: gettext: command not found
/usr/bin/downgrade: line 140: gettext: command not found
/usr/bin/downgrade: line 142: gettext: command not found
/usr/bin/downgrade: line 140: gettext: command not found
/usr/bin/downgrade: line 142: gettext: command not found
/usr/bin/downgrade: line 140: gettext: command not found
-  1)  pkgfile    19  1  x86_64  ()
-  2)  pkgfile    19  1  x86_64  ()
-  3)  pkgfile    20  1  x86_64  ()
-  4)  pkgfile    20  1  x86_64  ()
+  5)  pkgfile    20  2  x86_64  ()
+  6)  pkgfile    20  2  x86_64  ()

/usr/bin/downgrade: line 46: gettext: command not found

eniac commented on 2019-10-10 16:53 (UTC)

Suddenly I have the same issue as reported by hotice, but my pacman.conf hasn't changed for months.

brisbin33 commented on 2019-08-19 13:00 (UTC)

Huh, that's weird and unexpected. I thought I was using curl -O (which downloads using the basename of the URL), which would be the full package-version-arch. Do you mind opening this as an Issue on the repository?

https://github.com/pbrisbin/downgrade/issues

phillid commented on 2019-08-18 00:12 (UTC)

Would recommend setting a local download name for the source tarball [1]. v6.2.1.tar.gz in't very unique, and collides when makepkg is configured to use a downloads directory that is shared with other packages. Cheers

[1] https://wiki.archlinux.org/index.php/PKGBUILD#source

jarch.io commented on 2019-03-18 03:23 (UTC)

@nhw install pacman-contrib

hotice commented on 2018-07-14 15:04 (UTC)

oops, my bad. For some reason pacman.conf had its sections repeated 3 times! After deleting triplicates seems fine now, sorry!

brisbin33 commented on 2018-07-14 14:20 (UTC)

Hmm, doesn't look like an error in the command. Seems like it can't read your Pacman log. There could be a few reasons for this:

  • New Pacman is putting the file elsewhere
  • New Pacman is now storing the file 600
  • New Pacman is storing the file 640 and you're not in whatever group it is

(Or you're configured Pacman to do these things.)

What does sudo ls -l /var/log/pacman.log and sudo cat /etc/pacman.conf say?

Feel free to open an Issue in the project GitHub if you prefer interacting there.

hotice commented on 2018-07-14 13:50 (UTC) (edited on 2018-07-14 13:54 (UTC) by hotice)

is there an argument error in sed call?
$ downgrade firefox
sed: can't read /var/log/pacman.log
/var/log/pacman.log
/var/log/pacman.log: No such file or directory
Available packages:

1) firefox-61.0.1-1-x86_64.pkg.tar.xz (remote)
2) firefox-61.0.1-1-x86_64.pkg.tar.xz (local)
...

brisbin33 commented on 2018-06-01 01:19 (UTC)

FWIW, I also maintain the AUR helper aurget, which was able to install downgrade for me :)

diekstra commented on 2018-06-01 01:14 (UTC)

@johnwallaby I got the same error when trying to install downgrade for the first time. I didn't have pacman-contrib installed. It worked when I manually installed pacman-contrib and tried again. I'm using pacaur, which is probably the issue (been meaning to switch to something else for a long time). If you're also using pacaur, this may be your issue. 

==> Sources are ready.
:: Building downgrade package(s)...
==> Making package: downgrade 6.0.0-2 (Thu 31 May 2018 07:53:35 PM CDT)
==> Checking runtime dependencies...
==> Installing missing dependencies...
/usr/bin/pacman: unrecognized option '--color never'
==> ERROR: 'pacman' failed to install missing dependencies.
:: failed to build downgrade package(s)

johnwallaby commented on 2018-05-29 16:35 (UTC)

@brisbin33, after a reboot (and installing pacman-contrib) everything works again as expected. as i can't reproduce the behaviour either, just ignore the msg please. thx for maintaining this nice piece of software btw!

brisbin33 commented on 2018-05-29 12:41 (UTC)

Hmm. I can't reproduce that here, can you please tell me the full command-line you're running? Also, the full output of bash -x downgrade <whatever you run> (please use a paste site of some kind).

FWIW, the script doesn't pass any pacman args itself, though it does accept them like downgrade -- <pacman args> and pass them along. So, if you're running downgrade <package> -- --color never and getting this error, you should... stop doing that :)

For everyone else: I did have to go through a minor update dance because of how old and new pacman provide and/or conflict with pacman-contrib:

  • pacman -Rsn downgrade
  • pacman -Syu
  • auget downgrade (installs pacman-contrib)

johnwallaby commented on 2018-05-29 12:02 (UTC) (edited on 2018-05-29 12:02 (UTC) by johnwallaby)

hi @brisbin33, i get the following error when trying to upgrade to the latest version:

/usr/bin/pacman: unknown option »--color never«

pacman was upgraded to 5.1.0.

brisbin33 commented on 2018-05-29 11:31 (UTC)

Thanks for letting me know, depends added.

nwg commented on 2018-05-29 07:15 (UTC)

Same error here (/usr/bin/downgrade: line 124: pacsort: command not found) after upgrading pacman to 5.1.0-1.

SibrenVasse commented on 2018-05-29 05:43 (UTC)

Running this script currently gives the following error: /usr/bin/downgrade: line 124: pacsort: command not found

Package should depend on 'pacman-contrib', as pacsort has been moved.

brisbin33 commented on 2017-09-28 21:45 (UTC)

Thanks for the report JohnRobson. Unfortunately, this has nothing to do with downgrade. It's an error coming from pacman directly, and is likely caused by repo.archlinux.fr having an outage. You can confirm this with # pacman -U http://repo.archlinux.fr/x86_64/downgrade-5.4.1-1-any.pkg.tar.xz IIRC installing from repo.archlinux.fr was some weird Yaourt thing that's not recommend. Please see https://wiki.archlinux.org/index.php/Arch_User_Repository#Installing_packages for the correct way to install downgrade.

JohnRobson commented on 2017-09-28 18:11 (UTC)

09/28 14:09:54 [ERROR] CUID#7 - Download aborted. URI=http://repo.archlinux.fr/x86_64/downgrade-5.4.1-1-any.pkg.tar.xz Exception: [HttpSkipResponseCommand.cc:222] errorCode=3 Resource not found 09/28 14:09:54 [NOTICE] Download GID#6ca6f0bb1f328562 not complete: //var/cache/pacman/pkg/downgrade-5.4.1-1-any.pkg.tar.xz.part Download Results: gid |stat|avg speed |path/URI ======+====+===========+======================================================= 6ca6f0|ERR | 0B/s|//var/cache/pacman/pkg/downgrade-5.4.1-1-any.pkg.tar.xz.part Status Legend: (ERR):error occurred. aria2 will resume download if the transfer is restarted. If there are any errors, then see the log file. See '-l' option in help/man page for details. warning: failed to retrieve some files error: failed to commit transaction (error invoking external downloader) Errors occurred, no packages were upgraded.

wget commented on 2017-08-12 10:39 (UTC)

Could you replace the "A.R.M." mention to "A.L.A." in the description?

Xavion commented on 2017-06-13 21:51 (UTC)

Done.

brisbin33 commented on 2017-06-13 17:05 (UTC)

Thanks Xavion, good points all around. Can you open Issues on the GitHub repo for these two things?

Xavion commented on 2017-06-13 00:02 (UTC)

Regarding my second suggestion, your implementation idea sounds good but would require a fair bit of work. I think it'd be easier for you to just list the dates alongside the packages in the 'downgrade' output. In fact, I think this should be done even if you do decide to create the second tool.

brisbin33 commented on 2017-06-12 15:21 (UTC) (edited on 2017-06-12 15:24 (UTC) by brisbin33)

I Xavlon, For the first one (sort by most-recent-first), I can't reproduce what you're seeing, they sort by recency for me (as intended) % downgrade firefox Available packages: 1) firefox-53.0.3-1-x86_64.pkg.tar.xz (remote) ...snip... 103) firefox-23.0.1-1-x86_64.pkg.tar.xz (remote) 104) firefox-23.0.1-1-x86_64.pkg.tar.xz (local) select a package by number: Can you report this issue on GitHub with more details (exact invocation, exact output, system locale, etc)? --- EDIT: I'm sorry, I misread that you wanted to see most recent sorted *last*. I had never actually considered this, but your reasoning makes sense! I don't know when, but I agree that the other sort would be better and will probably make that change. -- For the second suggestion, this has been requested once or twice and I agree it sounds useful. I wonder if a better solution would be a second tool, one that takes a package name and rough date and parses pacman.log to find out what version of that package you had installed around that time. The output of this tool could be passed directly to downgrade (it accepts {package}-{version}, and will even skip the prompts if there's a single result). Something like: dowgrade $(package-when firefox "last saturday") WDYT?

Xavion commented on 2017-06-12 00:20 (UTC)

I have two requests to make. Firstly, please reverse the order of the list. In other words, the most recent editions of packages should be shown at the bottom of the screen. It makes sense that people looking for earlier versions should have to scroll back further! Secondly, it would be good to have the creation/upload date listed next to each entry in the list. If I want to roll back to a package I know I installed two Saturdays ago (but don't remember the version number), I have to go by its date-stamp.

taorg commented on 2017-05-13 23:48 (UTC)

Great package. It works fine and its well thought. Very easy and intuitive. Elixir was broken with new erlang 20rc-1 and I fixed in a minute with this tool. No other solution suit me as this. Very useful the IgnorePkg? [y/n] option. Thanx

brisbin33 commented on 2016-10-18 21:57 (UTC)

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 (UTC)

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 (UTC) (edited on 2016-02-01 15:46 (UTC) by brisbin33)

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 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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

brisbin33 commented on 2014-09-17 15:27 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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

brisbin33 commented on 2014-05-31 12:26 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

> 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 (UTC)

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

SanskritFritz commented on 2014-05-17 10:27 (UTC)

@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 (UTC)

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

brisbin33 commented on 2014-01-13 20:44 (UTC)

I think it's fixed. Sorry!

brisbin33 commented on 2014-01-13 20:34 (UTC)

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 (UTC)

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 (UTC)

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

brisbin33 commented on 2013-09-25 13:37 (UTC)

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 (UTC)

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 (UTC)

@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 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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

scorici commented on 2013-04-18 08:26 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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

tonyskn commented on 2012-11-11 13:30 (UTC)

Please add wget to dependencies

paalsteek commented on 2012-09-13 07:06 (UTC)

Please add wget as a dependency.

donvla commented on 2012-05-14 18:02 (UTC)

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 (UTC)

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 (UTC)

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

brisbin33 commented on 2012-04-21 19:04 (UTC)

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 (UTC)

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.

brisbin33 commented on 2012-04-21 17:27 (UTC)

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 (UTC)

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

brisbin33 commented on 2012-04-20 16:26 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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?

commented on 2011-07-04 06:33 (UTC)

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

archman commented on 2011-02-17 19:07 (UTC)

Thanks for this amazing app!

LeCrayonVert commented on 2011-02-09 23:00 (UTC)

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

brisbin33 commented on 2011-02-09 21:45 (UTC)

Thank you, updated. When did that change?

LeCrayonVert commented on 2011-02-09 20:18 (UTC)

Please replace the url in the downgrade script with : line 92 url="http://arm.konnichi.com/search/raw.php?a=$arch&q=^$term\$$repos"

commented on 2010-12-06 18:36 (UTC)

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.

brisbin33 commented on 2010-05-20 13:34 (UTC)

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.

wizetek commented on 2010-05-20 00:11 (UTC)

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 (UTC)

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 (UTC)

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.