[SOLVED] Dependency problems after ~2 years with no updates

mailson · 2018-05-03 15:44:51

Hello all,

Although I'm an arch user for several years now, this is probably my first post on the forum.

I've been postponing updates to my arch machine for a while (I think it's been almost 2 years since I last run `pacman -Syu`). The system obviously is having a hard time upgrading.

I tried to look for someone that had a similar problem, but although the answers seem to work for those who's been updating the system every once in a while, it doesn't work for my case.

Here's the deal:

Pacman asks if I want to replace some packages for its new counterparts. I answer yes to all

$ sudo pacman -Syu
:: Synchronizing package databases...
 core is up to date
 extra is up to date
 community is up to date
 multilib is up to date
:: Starting full system upgrade...
:: Replace attica-qt5 with extra/attica? [Y/n] 
:: Replace compositeproto with extra/xorgproto? [Y/n] 
:: Replace damageproto with extra/xorgproto? [Y/n] 
:: Replace fixesproto with extra/xorgproto? [Y/n] 
:: Replace fontsproto with extra/xorgproto? [Y/n] 
:: Replace grantlee-qt5 with extra/grantlee? [Y/n] 
:: Replace inputproto with extra/xorgproto? [Y/n] 
:: Replace kbproto with extra/xorgproto? [Y/n] 
:: Replace kde-meta-kdegraphics with extra/kdegraphics-meta? [Y/n] 
:: Replace kde-meta-kdeutils with extra/kdeutils-meta? [Y/n] 
:: Replace kdeaccessibility-kmag with extra/kmag? [Y/n] 
:: Replace kdebase-kdialog with extra/kdialog? [Y/n] 
:: Replace kdegraphics-kolourpaint with extra/kolourpaint? [Y/n] 
:: Replace kdegraphics-okular with extra/okular? [Y/n] 
:: Replace kdegraphics-svgpart with extra/svgpart? [Y/n] 
:: Replace kdeutils-kdf with extra/kdf? [Y/n] 
:: Replace kdeutils-kgpg with extra/kgpg? [Y/n] 
:: Replace kdeutils-sweeper with extra/sweeper? [Y/n] 
:: Replace lib32-elfutils with multilib/lib32-libelf? [Y/n] 
:: Replace lib32-libdbus with multilib/lib32-dbus? [Y/n] 
:: Replace lib32-mesa-libgl with multilib/lib32-mesa? [Y/n] 
:: Replace libdbus with core/dbus? [Y/n] 
:: Replace mesa-libgl with extra/mesa? [Y/n] 
:: Replace python-docker-py with community/python-docker? [Y/n] 
:: Replace python2-docker-py with community/python2-docker? [Y/n] 
:: Replace randrproto with extra/xorgproto? [Y/n] 
:: Replace recordproto with extra/xorgproto? [Y/n] 
:: Replace renderproto with extra/xorgproto? [Y/n] 
:: Replace rfkill with core/util-linux? [Y/n] 
:: Replace scrnsaverproto with extra/xorgproto? [Y/n] 
:: Replace videoproto with extra/xorgproto? [Y/n] 
:: Replace xextproto with extra/xorgproto? [Y/n] 
:: Replace xf86dgaproto with extra/xorgproto? [Y/n] 
:: Replace xf86vidmodeproto with extra/xorgproto? [Y/n] 
:: Replace xineramaproto with extra/xorgproto? [Y/n] 
:: Replace xproto with extra/xorgproto? [Y/n] 
resolving dependencies...
looking for conflicting packages...
:: qt5-base and qtchooser are in conflict. Remove qtchooser? [y/N] y
:: poppler and poppler-qt4 are in conflict. Remove poppler-qt4? [y/N] y
:: libqaccessibilityclient and libkdeaccessibilityclient are in conflict. Remove libkdeaccessibilityclient? [y/N] y
error: failed to prepare transaction (could not satisfy dependencies)
:: libxfont: removing fontsproto breaks dependency 'fontsproto>=2.1.3'

As you can see on the last line, there's a dependency issue with libxfont (which I think it's no longer used in favor of libxfont2). I tried removing that package as instructed here, but libxfont itself has its own dependencies, which I'd rather not force a removal

Here's the pactree

$ pactree -r libxfont
libxfont
└─xorg-bdftopcf
  └─xorg-font-utils
    ├─gsfonts
    ├─ttf-liberation
    │ ├─chromium
    │ ├─mplayer
    │ │ └─kdemultimedia-mplayerthumbs
    │ └─steam
    ├─ttf-oxygen
    │ ├─chromium
    │ ├─mplayer
    │ ├─plasma-integration
    │ │ └─plasma-workspace
    │ │   ├─kdeplasma-addons
    │ │   ├─khotkeys
    │ │   │ └─kmenuedit
    │ │   │   └─plasma-desktop
    │ │   ├─plasma-mediacenter
    │ │   ├─plasma-nm
    │ │   └─powerdevil
    │ └─steam
    └─xorg-fonts-misc
      └─xorg-server-common
        └─xorg-server
          └─nvidia-utils

PS: libxfont was also required by xorg-server but I was able to force update xorg-server in an attempt to remove this dependency but there's this other package (xorg-bdftopcf) which also depends on libxfont. Should I try to force update this package as well (pacman -S --force xorg-bdftopcf)?

PS2: It's not showing now, but there's also a similar issue with the package poppler-qt4

If you need more info, please ask.

Last edited by mailson (2018-05-03 21:23:35)

Scimmia · 2018-05-03 15:48:39

first off, STOP USING --force! It does not do what you think it does, and if you have to use it, you'd better know why.

You're really better off just removing libxfont with -Rdd then updating. Since there's only 1 package that needs it and we know that the newer version doesn't need it anymore, it should be safe.

mailson · 2018-05-03 16:00:09

You're really better off just removing libxfont with -Rdd then updating. Since there's only 1 package that needs it and we know that the newer version doesn't need it anymore, it should be safe.

Absolutely! I tried that and it's updating now. Thanks a lot!

I'll keep the topic open while the system is been updated just in case something new comes up.

PS: About the --force, I did it because there was a file conflict with libmesa. Since this would also be updated anyway, I just used it. But you're right, better to avoid it.

Scimmia · 2018-05-03 16:02:50

More likely it just screwed things up totally. You then have 2 packages owning the same files, so when mesa is updated and the files are no longer part of that package, they're removed from the filesystem breaking whatever else owned the files now. Have fun with that.

mailson · 2018-05-03 16:10:54

Oh, damn

when mesa is updated and the files are no longer part of that package, they're removed from the filesystem

I thought mesa wouldn't be able to remove files owned by another package unless I --force them as well.

Anyway, fingers crossed here. If that happens I guess I'll have something to spend my weekend on.

mailson · 2018-05-03 18:17:45

Yep, damn me (although these conflicts don't seem related to xorg-server or mesa)

(838/838) checking for file conflicts                                                                                          [############################################################################] 100%
error: failed to commit transaction (conflicting files)
gpgme: /usr/include/gpgme++/configuration.h exists in filesystem
gpgme: /usr/include/gpgme++/context.h exists in filesystem
gpgme: /usr/include/gpgme++/data.h exists in filesystem
gpgme: /usr/include/gpgme++/decryptionresult.h exists in filesystem
gpgme: /usr/include/gpgme++/defaultassuantransaction.h exists in filesystem
gpgme: /usr/include/gpgme++/editinteractor.h exists in filesystem
gpgme: /usr/include/gpgme++/encryptionresult.h exists in filesystem
gpgme: /usr/include/gpgme++/engineinfo.h exists in filesystem
gpgme: /usr/include/gpgme++/error.h exists in filesystem
gpgme: /usr/include/gpgme++/eventloopinteractor.h exists in filesystem
gpgme: /usr/include/gpgme++/exception.h exists in filesystem
gpgme: /usr/include/gpgme++/global.h exists in filesystem
gpgme: /usr/include/gpgme++/gpgadduserideditinteractor.h exists in filesystem
gpgme: /usr/include/gpgme++/gpgagentgetinfoassuantransaction.h exists in filesystem
gpgme: /usr/include/gpgme++/gpgmefw.h exists in filesystem
gpgme: /usr/include/gpgme++/gpgsetexpirytimeeditinteractor.h exists in filesystem
gpgme: /usr/include/gpgme++/gpgsetownertrusteditinteractor.h exists in filesystem
gpgme: /usr/include/gpgme++/gpgsignkeyeditinteractor.h exists in filesystem
gpgme: /usr/include/gpgme++/importresult.h exists in filesystem
gpgme: /usr/include/gpgme++/interfaces/assuantransaction.h exists in filesystem
gpgme: /usr/include/gpgme++/interfaces/dataprovider.h exists in filesystem
gpgme: /usr/include/gpgme++/interfaces/passphraseprovider.h exists in filesystem
gpgme: /usr/include/gpgme++/interfaces/progressprovider.h exists in filesystem
gpgme: /usr/include/gpgme++/key.h exists in filesystem
gpgme: /usr/include/gpgme++/keygenerationresult.h exists in filesystem
gpgme: /usr/include/gpgme++/keylistresult.h exists in filesystem
gpgme: /usr/include/gpgme++/notation.h exists in filesystem
gpgme: /usr/include/gpgme++/result.h exists in filesystem
gpgme: /usr/include/gpgme++/scdgetinfoassuantransaction.h exists in filesystem
gpgme: /usr/include/gpgme++/signingresult.h exists in filesystem
gpgme: /usr/include/gpgme++/trustitem.h exists in filesystem
gpgme: /usr/include/gpgme++/verificationresult.h exists in filesystem
gpgme: /usr/include/gpgme++/vfsmountresult.h exists in filesystem
ca-certificates-utils: /etc/ssl/certs/ca-certificates.crt exists in filesystem
ttf-dejavu: /etc/fonts/conf.d/20-unhint-small-dejavu-sans-mono.conf exists in filesystem
ttf-dejavu: /etc/fonts/conf.d/20-unhint-small-dejavu-sans.conf exists in filesystem
ttf-dejavu: /etc/fonts/conf.d/20-unhint-small-dejavu-serif.conf exists in filesystem
ttf-dejavu: /etc/fonts/conf.d/57-dejavu-sans-mono.conf exists in filesystem
ttf-dejavu: /etc/fonts/conf.d/57-dejavu-sans.conf exists in filesystem
ttf-dejavu: /etc/fonts/conf.d/57-dejavu-serif.conf exists in filesystem
geoclue2: /usr/share/gtk-doc/html/geoclue/geoclue.devhelp2 exists in filesystem
geoclue2: /usr/share/gtk-doc/html/geoclue/home.png exists in filesystem
geoclue2: /usr/share/gtk-doc/html/geoclue/index.html exists in filesystem
geoclue2: /usr/share/gtk-doc/html/geoclue/left.png exists in filesystem
geoclue2: /usr/share/gtk-doc/html/geoclue/right.png exists in filesystem
geoclue2: /usr/share/gtk-doc/html/geoclue/style.css exists in filesystem
geoclue2: /usr/share/gtk-doc/html/geoclue/up.png exists in filesystem
prison: /usr/include/KF5/prison_version.h exists in filesystem
prison: /usr/lib/cmake/KF5Prison/KF5PrisonConfig.cmake exists in filesystem
prison: /usr/lib/cmake/KF5Prison/KF5PrisonConfigVersion.cmake exists in filesystem
prison: /usr/lib/cmake/KF5Prison/KF5PrisonTargets.cmake exists in filesystem
prison: /usr/lib/libKF5Prison.so exists in filesystem
prison: /usr/lib/qt/mkspecs/modules/qt_Prison.pri exists in filesystem
python-qrcode: /usr/bin/qr exists in filesystem
python-qrcode: /usr/share/man/man1/qr.1.gz exists in filesystem
Errors occurred, no packages were upgraded.

Although, it doesn't seem related to xorg-server.

I've `pacman -Qo` some of them but couldn't find any references to xorg-server

Eg:

$ pacman -Qo /usr/share/man/man1/qr.1.gz
/usr/share/man/man1/qr.1.gz is owned by python-qrcode-bin 5.2.2-1

$ pactree -r python-qrcode-bin
python-qrcode-bin

$ pacman -Qi python-qrcode-bin
Name            : python-qrcode-bin
Version         : 5.2.2-1
Description     : QR Code image generator
Architecture    : any
URL             : https://pypi.python.org/pypi/qrcode
Licenses        : BSD
Groups          : None
Provides        : None
Depends On      : python>=3.5  python-setuptools  python-qrcode  python-colorama
Optional Deps   : None
Required By     : None
Optional For    : None
Conflicts With  : python2-qrcode
Replaces        : None
Installed Size  : 4.00 KiB
Packager        : Unknown Packager
Build Date      : qua 23 mar 2016 23:59:56 BRT
Install Date    : qua 23 mar 2016 23:59:57 BRT
Install Reason  : Explicitly installed
Install Script  : No
Validated By    : None

Another example:

gpgme: /usr/include/gpgme++/configuration.h exists in filesystem

$ pacman -Qo /usr/include/gpgme++/configuration.h
/usr/include/gpgme++/configuration.h is owned by kdepimlibs4 4.14.10-9

$ pactree -r kdepimlibs4
kdepimlibs4
└─kdebase-runtime
  ├─kdeaccessibility-kmag
  ├─kdebase-kdepasswd
  ├─kdebase-kdialog
  ├─kdegraphics-kolourpaint
  │ └─kde-meta-kdegraphics
  ├─kdegraphics-okular
  │ └─kde-meta-kdegraphics
  ├─kdemultimedia-mplayerthumbs
  ├─kdeutils-kdf
  │ └─kde-meta-kdeutils
  ├─kdeutils-kgpg
  │ └─kde-meta-kdeutils
  ├─kdeutils-kremotecontrol
  │ └─kde-meta-kdeutils
  ├─kdeutils-superkaramba
  ├─kdeutils-sweeper
  │ └─kde-meta-kdeutils
  └─konsolepart4

Also, those are the packages that were modified when I ran --force xorg-server

[2018-05-03 12:09] [PACMAN] Running 'pacman -S --force xorg-server'
[2018-05-03 12:09] [ALPM] transaction started
[2018-05-03 12:09] [ALPM] removed xf86-video-intel (1:2.99.917+691+ga77397a-1)
[2018-05-03 12:09] [ALPM] removed xf86-input-evdev (2.10.3-1)
[2018-05-03 12:09] [ALPM] installed libxfont2 (2.0.3-1)
[2018-05-03 12:09] [ALPM] installed xf86-input-libinput (0.27.1-1)
[2018-05-03 12:09] [ALPM] upgraded xorg-server (1.18.4-1 -> 1.19.6+13+gd0d1a694f-2)
[2018-05-03 12:09] [ALPM] transaction completed
[2018-05-03 12:09] [ALPM] running 'man-db.hook'...

When I look up for solutions to this conflicting files issue, I only get this: https://wiki.archlinux.org/index.php/Pa … 9.22_error, which tells me to --force anyway

I'll keep looking. If you have something in mind, please share :)

WorMzy · 2018-05-03 18:43:17

When I look up for solutions to this conflicting files issue, I only get this: https://wiki.archlinux.org/index.php/Pa … 9.22_error, which tells me to --force anyway

No, it doesn't. What it tells you is that, under very specific circumstances, --force can be appropriate. But the examples you've shared with us show that it is not appropriate to use --force for those packages.

You have python-qrcode-bin installed, and because it was a poorly written PKGBUILD, it doesn't conflict with, or provide, the python-qrcode package. If you want to install the latter, you should remove the former first.

If 'pacman -Qo <problem file>' reports any package, then you shouldn't use --force.

You're updating a very old installation. You've made life exceedingly difficult for yourself from the start, and made the situation worse by updating individual packages, and even more so by using --force. At this point, I would just recommend that you reinstall. But if you're only planning on updating your Arch installation once every two years, and you have no idea what you're doing, then I strongly recommend that you don't reinstall Arch. Arch is a rolling distro, it isn't designed to be static for long periods of time.

mailson · 2018-05-03 19:30:39

At this point, I would just recommend that you reinstall

I'd do that as a last resort (eg: only after breaking the system). So I'd just chroot and reinstall my explicitly installed packages.

if you're only planning on updating your Arch installation once every two years...

No, I'm not :)

No, it doesn't. What it tells you is that, under very specific circumstances, --force can be appropriate. But the examples you've shared with us show that it is not appropriate to use --force for those packages.

You're right. Haven't read carefully enough the first time.

My plan now is to look up every conflicting file and see if they're orphans or whatever is happening to its owners

I have a question about that, btw: what if the current owner of the package is marked to be removed (ie, they're not even in arch's package db anymore)? Is it still dangerous to --force?

eg: gpgme can't update because it adds a file that already exists in filesystem

gpgme: /usr/include/gpgme++/configuration.h exists in filesystem

This file, however, is owned by another package

$ pacman -Qo /usr/include/gpgme++/configuration.h
/usr/include/gpgme++/configuration.h is owned by kdepimlibs4 4.14.10-9

I've looked up for this package and it's not in arch's package database anymore:

$ pacman -Si kdepimlibs4
error: package 'kdepimlibs4' was not found
$ pacman -Ss kdepimlibs
$ echo $?
1

So I can safely assume it will be removed in this system update.

My questions are:

Can I `pacman -S --force gpgme`?
What will happen to /usr/include/gpgme++/configuration.h when kdepimlibs4 gets uninstalled? It will be removed even though another package owns it?

Sorry for the long post.

And thanks for the help so far :)

Trilby · 2018-05-03 19:39:56

No, yet again, don't use --force. Several experienced memebers have already told you this, yet you keep suggesting you want to do it anyways. This is not a productive way to seek advice.

Forcing the install of gpgme will not remove kdepimlibs4, it will only break your package database. If you want to remove kdepimlibs4, then just remove it (pacman -R kdepimlibs4).

As for your second question, that is a moot point as long as you don't intentionally break your package/files database by using --force. If you do intentionally break your database(s), then there's really little point in pondering the details of the breakage: you'll have bigger issues to worry about.

mailson · 2018-05-03 20:38:48

No, yet again, don't use --force. Several experienced memebers have already told you this, yet you keep suggesting you want to do it anyways. This is not a productive way to seek advice.

Sorry, I didn't mean to look down on their advice. I just wanted to evaluate what risks I'd be taking and understand what could go wrong so I could decide whether or not I'd able to circumvent it.

Forcing the install of gpgme will not remove kdepimlibs4

Yes, I understand that. I just thought it would mark that conflicting file as having 2 owners, and once kdepimlibs4 was removed, it would go back as to having only 1 owner (in that case, gpgme). But apparently, it does not behave like that.

If you want to remove kdepimlibs4, then just remove it (pacman -R kdepimlibs4)

That's what I'm going to do now: `pacman -R` (actually `-Rd` since some are required by other packages) those conflicting packages (making sure what's being installed is something related).

NoSuck · 2018-05-03 21:14:22

WorMzy wrote:

If 'pacman -Qo <problem file>' reports any package, then you shouldn't use --force.

I thought this was a great rule of thumb and decided to add it to the wiki page linked by mailson, but it was already there.

mailson · 2018-05-03 21:23:14

Solved

Removing those packages did it. I'll write down some information that may be helpful for another user.

Ok, so I've checked each of the conflicting files below to figure out why they were conflicting (pacman -Qo <package_name>)

error: failed to commit transaction (conflicting files)
gpgme: /usr/include/gpgme++/configuration.h exists in filesystem
gpgme: /usr/include/gpgme++/context.h exists in filesystem
gpgme: /usr/include/gpgme++/data.h exists in filesystem
gpgme: /usr/include/gpgme++/decryptionresult.h exists in filesystem
gpgme: /usr/include/gpgme++/defaultassuantransaction.h exists in filesystem
gpgme: /usr/include/gpgme++/editinteractor.h exists in filesystem
gpgme: /usr/include/gpgme++/encryptionresult.h exists in filesystem
gpgme: /usr/include/gpgme++/engineinfo.h exists in filesystem
gpgme: /usr/include/gpgme++/error.h exists in filesystem
gpgme: /usr/include/gpgme++/eventloopinteractor.h exists in filesystem
gpgme: /usr/include/gpgme++/exception.h exists in filesystem
gpgme: /usr/include/gpgme++/global.h exists in filesystem
gpgme: /usr/include/gpgme++/gpgadduserideditinteractor.h exists in filesystem
gpgme: /usr/include/gpgme++/gpgagentgetinfoassuantransaction.h exists in filesystem
gpgme: /usr/include/gpgme++/gpgmefw.h exists in filesystem
gpgme: /usr/include/gpgme++/gpgsetexpirytimeeditinteractor.h exists in filesystem
gpgme: /usr/include/gpgme++/gpgsetownertrusteditinteractor.h exists in filesystem
gpgme: /usr/include/gpgme++/gpgsignkeyeditinteractor.h exists in filesystem
gpgme: /usr/include/gpgme++/importresult.h exists in filesystem
gpgme: /usr/include/gpgme++/interfaces/assuantransaction.h exists in filesystem
gpgme: /usr/include/gpgme++/interfaces/dataprovider.h exists in filesystem
gpgme: /usr/include/gpgme++/interfaces/passphraseprovider.h exists in filesystem
gpgme: /usr/include/gpgme++/interfaces/progressprovider.h exists in filesystem
gpgme: /usr/include/gpgme++/key.h exists in filesystem
gpgme: /usr/include/gpgme++/keygenerationresult.h exists in filesystem
gpgme: /usr/include/gpgme++/keylistresult.h exists in filesystem
gpgme: /usr/include/gpgme++/notation.h exists in filesystem
gpgme: /usr/include/gpgme++/result.h exists in filesystem
gpgme: /usr/include/gpgme++/scdgetinfoassuantransaction.h exists in filesystem
gpgme: /usr/include/gpgme++/signingresult.h exists in filesystem
gpgme: /usr/include/gpgme++/trustitem.h exists in filesystem
gpgme: /usr/include/gpgme++/verificationresult.h exists in filesystem
gpgme: /usr/include/gpgme++/vfsmountresult.h exists in filesystem
ca-certificates-utils: /etc/ssl/certs/ca-certificates.crt exists in filesystem
ttf-dejavu: /etc/fonts/conf.d/20-unhint-small-dejavu-sans-mono.conf exists in filesystem
ttf-dejavu: /etc/fonts/conf.d/20-unhint-small-dejavu-sans.conf exists in filesystem
ttf-dejavu: /etc/fonts/conf.d/20-unhint-small-dejavu-serif.conf exists in filesystem
ttf-dejavu: /etc/fonts/conf.d/57-dejavu-sans-mono.conf exists in filesystem
ttf-dejavu: /etc/fonts/conf.d/57-dejavu-sans.conf exists in filesystem
ttf-dejavu: /etc/fonts/conf.d/57-dejavu-serif.conf exists in filesystem
geoclue2: /usr/share/gtk-doc/html/geoclue/geoclue.devhelp2 exists in filesystem
geoclue2: /usr/share/gtk-doc/html/geoclue/home.png exists in filesystem
geoclue2: /usr/share/gtk-doc/html/geoclue/index.html exists in filesystem
geoclue2: /usr/share/gtk-doc/html/geoclue/left.png exists in filesystem
geoclue2: /usr/share/gtk-doc/html/geoclue/right.png exists in filesystem
geoclue2: /usr/share/gtk-doc/html/geoclue/style.css exists in filesystem
geoclue2: /usr/share/gtk-doc/html/geoclue/up.png exists in filesystem
prison: /usr/include/KF5/prison_version.h exists in filesystem
prison: /usr/lib/cmake/KF5Prison/KF5PrisonConfig.cmake exists in filesystem
prison: /usr/lib/cmake/KF5Prison/KF5PrisonConfigVersion.cmake exists in filesystem
prison: /usr/lib/cmake/KF5Prison/KF5PrisonTargets.cmake exists in filesystem
prison: /usr/lib/libKF5Prison.so exists in filesystem
prison: /usr/lib/qt/mkspecs/modules/qt_Prison.pri exists in filesystem
python-qrcode: /usr/bin/qr exists in filesystem
python-qrcode: /usr/share/man/man1/qr.1.gz exists in filesystem
Errors occurred, no packages were upgraded.

Some of them were being used by a soon to be removed package

$ pacman -Qo /usr/include/gpgme++/configuration.h
/usr/include/gpgme++/configuration.h is owned by kdepimlibs4 4.14.10-9
$ pacman -Si kdepimlibs4
error: package 'kdepimlibs4' was not found

So I just removed them from the system (skipping dependency check)

eg:

$ pacman -Sdd kdepimlibs4

Some files weren't owned by any package, so I just removed them from the system.

I also got some issues with pgp signatures not being recognized, but a simple `pacman-key --refresh-keys` fixed that.

So that's all. System updated, up and running. No need to reinstall. That's why I keep using Arch.

Thanks for everyone. I wouldn't be able to do that without your help

Arch Linux

#1 2018-05-03 15:44:51

[SOLVED] Dependency problems after ~2 years with no updates

#2 2018-05-03 15:48:39

Re: [SOLVED] Dependency problems after ~2 years with no updates

#3 2018-05-03 16:00:09

Re: [SOLVED] Dependency problems after ~2 years with no updates

#4 2018-05-03 16:02:50

Re: [SOLVED] Dependency problems after ~2 years with no updates

#5 2018-05-03 16:10:54

Re: [SOLVED] Dependency problems after ~2 years with no updates

#6 2018-05-03 18:17:45

Re: [SOLVED] Dependency problems after ~2 years with no updates

#7 2018-05-03 18:43:17

Re: [SOLVED] Dependency problems after ~2 years with no updates

#8 2018-05-03 19:30:39

Re: [SOLVED] Dependency problems after ~2 years with no updates

#9 2018-05-03 19:39:56

Re: [SOLVED] Dependency problems after ~2 years with no updates

#10 2018-05-03 20:38:48

Re: [SOLVED] Dependency problems after ~2 years with no updates

#11 2018-05-03 21:14:22

Re: [SOLVED] Dependency problems after ~2 years with no updates

#12 2018-05-03 21:23:14

Re: [SOLVED] Dependency problems after ~2 years with no updates

Solved

Board footer