archlinux-downgrade / downgrade Goto Github PK

Currently, the only way of passing multiple pacman cache directories would be to concatenate them into a space-separated string, such as:

downgrade --pacman-cache "/var/cache/pacman /my/thing/somewhere" foo

This issue proposes a modified feature where pacman caches can be aggregated, such that a user can specify multiple locations with ease:

downgrade
  --pacman-cache /var/cache/pacman \
  --pacman-cache ~/my/thing/somewhere \
  foo

Arch Linux Rollback Machine(A.R.M) is now known as Arch Linux Archive(A.L.A), run a find & replace on the keyword to reflect this please. README.md being an obvious one.

How can I downgrade Linux to 3.16?
When I start downgrade linux, I see the minimum version 4.20

 » downgrade linux                                             1 ↵ andrey@asus
Available packages:

     1)  linux    4.20.1.arch1   1  x86_64  (remote)
     2)  linux    4.20.2.arch1   1  x86_64  (remote)
     3)  linux    4.20.3.arch1   1  x86_64  (remote)
     .....

I using Arch. Downgrade installing from aur

It's not possible to downgrade all mesa packages at once. downgrade tries to downgrade these packages one by one, which is not going to succeed.
downgrade mesa lib32-mesa mesa-libgl lib32-mesa-libgl ati-dri lib32-ati-dri

130 nowaker@nwkr-desktop ~ % sudo downgrade mesa lib32-mesa mesa-libgl lib32-mesa-libgl ati-dri lib32-ati-dri
Available packages:

   1) mesa-10.2.4-1-x86_64.pkg.tar.xz (local)
(...)
  30) mesa-9.1.6-1-x86_64.pkg.tar.xz (remote)

select a package by number: 8

loading packages...
warning: downgrading package mesa (10.2.4-1 => 10.2.1-1)
resolving dependencies...
looking for inter-conflicts...
error: failed to prepare transaction (could not satisfy dependencies)
:: ati-dri: requires mesa=10.2.4
:: mesa-libgl: requires mesa=10.2.4
Available packages:

   1) lib32-mesa-10.2.4-1-x86_64.pkg.tar.xz (local)
(...)

It's not related to #19. I don't want downgrade to perform any dependency resolution. I just want all the packages to be downgraded at once. (As if pacman -U file1 file2 file3)

sed: -e expression #1, char 2: missing command

Hello,
Im currently facing this issue with package installed from the AUR repository (yay -S.

[I] ➜ DOWNGRADE_FROM_ALA=1 downgrade neovim-nightly

Downgrading from A.L.A. is disabled on the stable branch. To override this behavior, set DOWNGRADE_FROM_ALA to 1 .
See https://wiki.manjaro.org/index.php?title=Using_Downgrade  for more details.

Kernel: x86_64 Linux 5.2.11-1-MANJARO
Shell: zsh 5.7.1 (It doesnt work with bash either)

Default used ARM_URL http://repo-arm.archlinuxcn.org site is offline.
Is It available any mirror?
Debug: https://pastebin.com/raw/3idnpvuE

It seems this tool only allow downgrading packages from the default local pacman repo.
However, if the user created a custom repo for say all the AUR packages, downgrade will not find the different package versions.

I'd like an option like downgrade --repo <repo-name>

EDIT: It seems you can use --pacman-conf but it will only work if you have the repo configured in a separate pacman.d file, and it's not very convenient to use.

As issue #119 has gotten very long, I am just copying over the relevant discussion points that we could use to improve downgrade further.

1. Modify local and remote to something more specific like local (core), local (community) etc. Could be problematic when dealing with AUR packages, which require a wrapper to verify if they are indeed AUR packages.

   Comment from @pbrisbin:

   SGTM, though if the option is there to pass arbitrary cache directories, don't we need to show that (and deal with long lines)? We can't know the cache name all the time.

   SGTM as well to just include the package database along with the package, such as local (core), local (aur), local (community) etc. I agree about not including the cache paths, it would get too long and cumbersome.

2. Look into include's in /etc/pacman.conf and how we pick up other cache directories.

   Comment from @pbrisbin:

   seems not worth the complexity. If someone were very serious about this feature, I'd encourage them to contribute a stand alone exe to pacman that reuses its own config code to resolve includes and print values (this could very well exist), then we could use that here

   Agree, this does seem too complex, and IMO the benefits might not justify the costs/effort

3. Consider making a downgrade-specific configuration file to set defaults.

   Comment from @pbrisbin:

   since every option has an env var, some export lines in bashrc is meant to be the config file. If one really wanted, they could put exports into a specific file and make a wrapper to source it and call downgrade to achieve the same.

   a. I have two perspectives on this. Firstly: yes, the idea of setting environmental variables sounds nice. If we go with this idea, it would be nice if we could include instructions on customizing environmental variables for modifying default behaviours -> perhaps we could include this in the readme or better so, in a GitHub wiki page. PS: I think it will be good to eventually have a wiki page in this repo since we will eventually have diverse functionality in downgrade given version filtering and other cool features.

   b. Alternatively, we could instead get rid of reading environmental variables (from outside downgrade) and only have them as proxies inside downgrade. By doing this, the only way to modify behaviour would be with CLI options, which just makes things IMO tighter and more controlled. A natural extension of this behaviour would be to create configuration files, eg.~/.config/downgrade/downgrade.conf, which would allow the user to set some default behaviours; which would in turn be the sole action that changes environmental variables.

   Personally, I really like (b) because it conforms to the general workflows of many other successful tools out there, and would make downgrade overall more intuitive to customize (based on experiences from others tools).

4. Maybe we add a --debug command-line option to downgrade which would be much more verbose with variable and array-printing. We could request users to run problematic commands with --debug to identify locations of bugs.

   We found a non-intrusive way to solve this by running bash -x downgrade. Perhaps this instruction could be added to an issue template regarding bugs in downgrade.

WDYT about these points? If we have an agreement, I would be happy to start working on these first because they seem generally easier than #83 and #118, and also somehow a bit more fundamental to the workflow of downgrade.

I think adding packages to IgnorePkg needs to be reworked. As it is now, downgrade will add these packages to the existing IgnorePkg lines, uncommenting them if needed. It's not a problem when you have just empty '#IgnorePkg = ' line, but that's not necessarily the case:

#IgnorePkg    = foo
#IgnorePkg    = bar
#IgnorePkg    = baz

After downgrading vim and vim-runtime to various versions I ended up with

IgnorePkg    = foo vim vim-runtime
IgnorePkg    = bar vim vim-runtime
IgnorePkg    = baz vim vim-runtime
IgnorePkg    = vim vim-runtime

test gcc, only one souce returned. I really expect 3.x or 4.1 returns.

Hi,
thanks for this awesome tool. I think it would be great if downgrade would ask if you want to add the downgraded package to the IgnorePkg variable in /etc/pacman.conf. The user could confirm or reject this with a y/n input and downgrade would then do the change if requested.
It may not seem important, but downgrade is a convenience tool anyway, so why not even a bit more convenience?

I personally would even find it useful if it would enable you to enter a comment which is then prepended to the IgnoreConf variable (usually the reason for the downgrade, to which version it applies etc). But that need may be far too specific to be supported ;)

Thanks!

As per #119, there are minor issues which we can address.

1. Create --pacman-log and --pacman-cache command line options which can take space-separated paths to identify single or multiple files. This is consistent with #96 in order to represent environmental variable as command-line options.

2. Investigate whether maxdepth is necessary in downgrade for finding local cached files. Or possibly augmenting maxdepth as a command-line option such as --maxdepth. This could be useful in non-default cache locations.

I wanted to downgrade the package "linux" and it provides me with a selection. Whatever I choose, it says that there is a signature missing.

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!

See my comments from the June of 2017 on the 'downgrade' AUR webpage for more information.

Currrently, downgrade outputs the available versions as (e.g.)

   1) mercurial-4.0-1-x86_64.pkg.tar.xz (remote)
   2) mercurial-4.0-1-x86_64.pkg.tar.xz (local)
   3) mercurial-3.9.2-1-x86_64.pkg.tar.xz (remote)
   4) mercurial-3.9.2-1-x86_64.pkg.tar.xz (local)
   5) mercurial-3.9.1-1-x86_64.pkg.tar.xz (remote)
   6) mercurial-3.9-1-x86_64.pkg.tar.xz (remote)
   7) mercurial-3.8.3-1-x86_64.pkg.tar.xz (remote)
   8) mercurial-3.8.2-1-x86_64.pkg.tar.xz (remote)
   9) mercurial-3.8.1-2-x86_64.pkg.tar.xz (remote)

Note how the differing version lengths make the whole thing slightly tricky to read.

A minor improvement would be to output
$index) $pkgname <TAB> $pkgver <TAB> $pkgrel <TAB> $arch <TAB> ($local_or_remote)

btw its commented in default /etc/pacman.conf

Just a minor usability enhancement suggestion: display the currently installed version, e.g.

Currently installed: x.y.z

Available packages:

   ...

or

Available packages:

   1) ... (local, currently installed)
   ...

(although the second case would fail to cover the case where the currently installed version is locally built and not remotely available).

I've been unable to debug what is wrong here, I used to be able to use downgrade fine but now it seems to silently fall over without checking the ARM for packages. with nothing in my cache it returns directly. I have tried a number of things such as:

NOCACHE=1 NOARM=0 downgrade firefox
NOCACHE=1 downgrade firefox
ARM_URL=http://seblu.net/a/arm downgrade firefox
ARM_URL=ftp://seblu.net/archlinux/arm downgrade firefox

(The ARM URLs are ones I got from here. Have you got any advice for how to begin debugging this?

msgstr "Paquêts disponibles :" should be msgstr "Paquets disponibles :" (no accent on e, see e.g. a few lines below in the same file).

I've a dedicated partition mounted to /var/cache/pacman/pkg that contains a lost-found directory. A leftover from ARM project ending notice.

Find warns of needing permission for lost-found.
I've added -maxdepth 1 to find command downgrade script, line 117.
Seems this addition would not cause any issues for more conventional configurations?

Can you undo a downgrade from the cli?

Following up from #130 (comment), I'd like to see @atreyasha handle the next release.

I added you as co-maintainer in the AUR. For release, I typically do the following:

1. Ensure translation files are all set
2. Ensure CHANGELOG.md is correct
3. Run make release.patch (in this case)

The release task relies on two other pieces of tooling:

• vbump: a very simple package that just bumps a selected component of version numbers
• aur-release: a shell script for pushing to the AUR repository, handling SRCINFO, sha sums, and all the rest

I apologize it's not quite as polished and there are a few desperate parts to this. Please do feel free to use (or create) your own process, I just wanted to make you aware of the tooling I had in case it's useful.

Any questions, let me know!

Calling "$(download_when_remote)" seems to break the progress bar.

#
##
###
####
...

Will have to remove that, possibly replace it with a downloading foo... to prevent re-introducing the "appears frozen" behavior that lead to this originally.

It fails to show package files from my cache for a particular package and I find this:

https://github.com/pbrisbin/downgrade/blob/1f4a7459a0f3593c9b6c4e8c11d41751e2c3f959/downgrade#L91

I have no packages starting with an uppercased R but several of my -git packages start with a lowercased r (there are a few r* in [community] too). Also lshw starts with B, 0ad starts with a, bettercap-caplets starts with v, coxeter starts with git. This pattern seems too restrictive.

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.

See my comments from the June of 2017 on the 'downgrade' AUR webpage for more information.

--force is just an example parameter that I'd want to pass to pacman

Proposed syntax: downgrade package1 package2 package3 - --param1 --param2 -vdd

Hi @pbrisbin,

Making a new issue for a new idea. Besides the current downgrading dependencies idea in #83, I would like to implement an additional command line option for non-interactive functionality, and this option can be called --non-interactive.

Basically, this option will enable lazy users to downgrade package(s) with just some basic instructions and without having to select any option from the table. Since downgrade is by design an interactive tool, this option would be non-default. Some examples of this option's functionality using our staple vim:

1. downgrade vim=8.2 --non-interactive: this will result in the latest version after fuzzy match to be automatically selected and installed.

2. downgrade "vim(<=|>=|<|>)8.2" --non-interactive: this will result in either the latest version before (<|<=) or the latest version after (>|>=) to be automatically selected and installed.

Note: For all of these options, first priority is install via cache, if not via ALA.

I find this option useful because it enables downgrade to be used without any user input, so users who want to write scripts to return their system to a certain state could easily use this non-interactive tool. WDYT?

When an item is added to the ignore list by answering "y" after downgrading, it is placed into /etc/pacman.conf at the bottom of the ignore list (with others commented above it). When this occurs the pamac preference/General is unable to remove the item with the highlight & "-" function. The only way to remove it is to edit /etc/pacman.conf with root privileges & remove it. When an item is added to the ignore list directly in this preference panel it is placed at the TOP of the list as is able to be removed successfully.

Id like to be able to use downgrade to work with a supplied version number on the commandline.
For example i want to downgrade wine to version 4.9 which downgrade shows in the second column.
For example:
downgrade wine-4.9

And also an option like 'pacaur --noconfirm --needed' which will auto install the package

Please add a description about the - and + indicators in the "Available packages" overview to the man page.

Hello @pbrisbin,

Thank you for making this awesome tool, it's really useful! Going back to issue #19, I think it might be really useful to have dependency management while downgrading a package. I understand you mentioned that you don't want to add it, but would it be possible to see how this works if I submit a PR?

If so, it would be great if you could advise me which area of the code you can envision this coming in; that would make it slightly quicker :)

I'm getting this:

error: could not open file /tmp/cairo-dock-3.2.1-3-i686.pkg.tar.xz: Unrecognized archive format
error: '/tmp/cairo-dock-3.2.1-3-i686.pkg.tar.xz': cannot open package file
error: could not install package /tmp/cairo-dock-3.2.1-3-i686.pkg.tar.xz

The reason is that the package is not being downloaded. And the reason for that is that the urls contain the "undefined" architecture instead of, say, "i686". For example:

http://repo-arm-download.archlinuxcn.org/community/os/undefined/cairo-dock-3.3.2-1-i686.pkg.tar.xz

This will return a http 404 error.

My architecture is in fact i686:

[carlos@localhost ~]$ uname -m
i686

I could send you the output of running downgrade with set -x if you prefer.

I do have sudo installed but don't use it to elevate my rights to root. So I want to use su when downgrading. Please add an option to choose.

It would be nice if downloaded packages went to the pacman cache (to avoid repeated downloads when switching back and forth between two versions, e.g. when debugging), or at least to a temporary directory in order to avoid polluting $pwd.

When I issue the command for example
downgrade firefox
the output is just the --help, nothing happens.
version downgrade 4.2.3-1

Please encode the package name containing symbols like '+' to %2B when goes to A.R.M, or it will be trimmed and wont return anything.

Example: query for crypto++ under x86_64 should be:

http://repo-arm.archlinuxcn.org/search?arch=x86_64&pkgname=crypto%2B%2B

@phoenixlzx, I should probably url encode in general right? More characters than just '+' will need escaping.

Would it be possible to use downgrade with packages like mesa that require downgrading intel-dri and mesa-libgl?

archlinuxcn.org is down. Consider using the links in https://wiki.archlinux.org/index.php/Arch_Rollback_Machine as a package source.

Hello :-)

I've added two new APIs using POST method, the old one is deprecated but will remain available.

Exact package search

• Method: POST
• Path: /exact
• Variables:
  • arch : i686 || x86_64
  • pkgname : Exact package name

Similiar package search

• Method: POST
• Path: /find
• Variables:
  • arch : i686 || x86_64
  • pkgname : package name criteria

Example:

curl --data-urlencode "arch=x86_64" --data-urlencode "pkgname=linux" http://repo-arm.archlinuxcn.org/exact

So if there is no package found using /exact, you could prompt user if he want to check there are similiar packages via /find.

I'm finishing up a greatly simplified v5.0 release for downgrade

As part of the changes, I've had to update the messaging such that the existing translations no longer work.

If possible, I'm asking that those who have contributed translations do so again. Please, if you could, see the .po files in the v5.0 branch, add the translations, and adjust the copyright/author/translater entries as needed.

Feel free to open a PR against that branch, or just comment a new po file here and I'll commit it for you.

// @gymka @hauk142 @oxayotl

Because only x86_64 and any architecture types exist in the ALA, we can remove the --arch option and any corresponding logic.

$ downgrade julia
Available packages:

   1) julia-2:0.4.3-1-x86_64.pkg.tar.xz (local)
   2) julia-2%3A0.4.3-1-x86_64.pkg.tar.xz (remote)
   3) julia-2%3A0.4.2-1-x86_64.pkg.tar.xz (remote)
<elided>

I assume "%3A" is ":", i.e. an epoch specifier?

sort -rV doesn't handle epoch correctly (see python-setuptools as an example). Fixing this is non-trivial. I'm not likely to do this as I think the bug is not worth the complexity of fixing it (given the potential fixes I've thought about). I'm opening this Issue to both track it as known and to invite anyone else to attempt a fix.

It took me some time and debugging to find the error for the following input:

$ downgrade freetype
$ echo $?
0

The solution was that freetype is actually called freetype2.

Hello,

arm.konnichi.com is down, and I found nothing left. So we developed a new A.R.M service application. So could you update the downgrade script to make it work again?

The new search pattern is /search?arch=$pkgarch&pkgname=$pkgname, where $pkgarch can be either i686 or x86_64, and $pkgname is exactly the package name(packages under any will be automatically added to results). $pkgarch and $pkgname must be both present.

Server will return result in following format:

pkgrepo|pkgname|pkgarch|pkgver|downloadurl

if multiple versions found, every package entry will take a single line, if no package found, currently return nothing.

Our new site url is http://repo-arm.archlinuxcn.org, so you could query like:

http://repo-arm.archlinuxcn.org/search?arch=x86_64&pkgname=linux

and you will get:

testing|linux|x86_64|3.10.9-1|http://repo-arm-download.archlinuxcn.org/testing/os/x86_64/linux-3.10.9-1-x86_64.pkg.tar.xz
core|linux|x86_64|3.10.7-1|http://repo-arm-download.archlinuxcn.org/core/os/x86_64/linux-3.10.7-1-x86_64.pkg.tar.xz

We are now implementing daily-repo functionality, our community A.R.M service app & configuration is here.

PS. We'll release documentation about how to setup an A.R.M server, so you could make A.R.M site URL as an opinion for end users.

Thank you!

Hi,

I noticed the only file in /usr/bash_completion.d/ is downgrade.

I found this strange, so when I tested bash completion with downgrade, it didn't worked.

However, after copying it to /usr/share/bash-completion/completions/ (where almost all bash completions are on Arch), it worked.

You might want to confirm this yourself first. I'll create a pull request and reference this issue from it.

I have to copy the url and download them with wget.

then I found that the urls were redirected

https://archive.archlinux.org/packages/l/linux-headers/linux-headers-5.5.10.arch1-1-x86_64.pkg.tar.zst
->
https://ia601007.us.archive.org/19/items/archlinux_pkg_linux/linux-5.5.10.arch1-1-x86_64.pkg.tar.zst

The current usage looks like usage: downgrade <pkg>, ... [-- <pacman options>] but one should NOT put in commas when listing multiple package names. Usage should look like:

usage: downgrade <pkg> [<pkg>]... [-- <pacman options>]