Package Details: onedrive-abraunegg 2.4.19-1

Git Clone URL: https://aur.archlinux.org/onedrive-abraunegg.git (read-only, click to copy)
Package Base: onedrive-abraunegg
Description: Free OneDrive client written in D - abraunegg's fork. Follows the releases on https://github.com/abraunegg/onedrive/releases
Upstream URL: https://github.com/abraunegg/onedrive
Keywords: onedrive
Licenses: GPL
Conflicts: onedrive, onedrive-abraunegg-git, onedrive-bin, onedrive-fork-git, onedrive-git
Provides: onedrive
Submitter: Pete
Maintainer: Pete
Last Packager: Pete
Votes: 66
Popularity: 1.35
First Submitted: 2019-03-29 10:46 (UTC)
Last Updated: 2022-06-15 04:01 (UTC)

Pinned Comments

Pete commented on 2019-03-29 10:51 (UTC)

This package can be used as a replacement for onedrive-abraunegg-git. It will be updated on every release from https://github.com/abraunegg/onedrive/releases .

Latest Comments

jtbwatson commented on 2022-04-27 15:54 (UTC)

@Pete

option 1 and 2 referring to the following: :: There are 2 providers available for d-runtime: :: Repositorycommunity 1) liblphobos 2) libphobos

Enter a number (default=1): ==> 1 :: There are 2 providers available for d-compiler: :: Repositorycommunity 1) dmd 2) ldc

the error i was receiving said something along the lines of error in compiling.

i ended up wiping the manjaro vers i had and installed arch. no issues this time around.

Pete commented on 2022-04-25 03:37 (UTC)

@jtbwatson

What specific error are you getting? And what do you mean with "option 1 and 2"?

jtbwatson commented on 2022-04-24 19:13 (UTC) (edited on 2022-04-27 15:53 (UTC) by jtbwatson)

Took a bit to get it to build on Manjaro. Steps to get it working:

yay -S onedrive-abraunegg --> error in compiling with option 1 and 2

pamac build onedrive-abraunegg --> same error

makepkg -si --> same error

makepkg -si (again) --> worked the 2nd time. don't know how or why, but it's working now. go figure.

update: seems to be related to the manjaro version i had. no issues on actual arch.

abraunegg commented on 2022-03-10 19:00 (UTC)

@jnv - I can only suggest that you ask that you ask that question on the 'onedrive' AUR package ... I would rather see consistency for all users across all distributions given that the author of the original client does not want "to spend time to implement and maintain features I don't use. Also I do not want to feel obliged to offer support when things stop working" Ref: https://github.com/skilion/onedrive/issues/518#issuecomment-717604726

jnv commented on 2022-02-09 02:17 (UTC)

I hope I'm not stirring up a hornet's nest or anything, but for the purpose of not being unnecessarily cryptic to new/old users, is there any ongoing movement to rename this package 'onedrive'? I note that there was some heated conversation in 2018 but that was four years ago, is the skilion code even compatible with OneDrive?

Being a SaaS/cloud and not a local server, surely there's no such thing as a "legacy" OneDrive installation?

whenov commented on 2021-11-13 12:40 (UTC)

@Pete Recompiling works great, thanks!

Pete commented on 2021-11-13 06:32 (UTC)

@whenov Normally, this is solved by recompiling the onedrive package. Could you try that when the latest liblphobos is installed? I don't see any problem myself with the latest liblphobos.

whenov commented on 2021-11-13 05:14 (UTC)

Launching onedrive reports missing libphobos2-ldc-shared.so.97. I had to downgrade liblphobos to 3:1.27.1-1 to make it work.

abraunegg commented on 2021-06-20 07:32 (UTC)

@r2re

Please see my prior comment: https://aur.archlinux.org/packages/onedrive-abraunegg/#comment-812279

r2re commented on 2021-06-20 07:26 (UTC)

I'm getting an error on Manjaro while running the 'pamac build onedrive-abraunegg' command. I'm not sure if this is an exclusively Manjaro problem, but any help would be appreciated.

$ pamac build onedrive-abraunegg Preparing... Cloning onedrive-abraunegg build files... Checking onedrive-abraunegg dependencies... Resolving dependencies... Checking inter-conflicts...

To build (1): onedrive-abraunegg 2.4.12-1 AUR

Edit build files : [e] Apply transaction ? [e/y/N] y

Building onedrive-abraunegg... ==> Making package: onedrive-abraunegg 2.4.12-1 (2021-06-20T10:20:13 EEST) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> Retrieving sources... -> Found v2.4.12.tar.gz ==> Validating source files with md5sums... v2.4.12.tar.gz ... Passed ==> Removing existing $srcdir/ directory... ==> Extracting sources... -> Extracting v2.4.12.tar.gz with bsdtar ==> Removing existing $pkgdir/ directory... ==> Starting build()... checking for a BSD-compatible install... /usr/bin/install -c checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking for dmd... dmd checking version of D compiler... 2.097.0 checking for curl... yes checking for sqlite... yes checking for notify... yes configure: creating ./config.status config.status: creating Makefile config.status: creating contrib/pacman/PKGBUILD config.status: creating contrib/spec/onedrive.spec config.status: creating onedrive.1 config.status: creating contrib/systemd/onedrive.service config.status: creating contrib/systemd/onedrive@.service if [ -f .git/HEAD ] ; then \ git describe --tags > version ; \ else \ echo v2.4.12 > version ; \ fi dmd -w -g -O -J. -version=NoPragma -version=NoGdk -version=Notifications -L-lcurl -L-lsqlite3 -L-lnotify -L-lgdk_pixbuf-2.0 -L-lgio-2.0 -L-lgobject-2.0 -L-lglib-2.0 -L-ldl src/config.d src/itemdb.d src/log.d src/main.d src/monitor.d src/onedrive.d src/qxor.d src/selective.d src/sqlite.d src/sync.d src/upload.d src/util.d src/progress.d src/notifications/notify.d src/notifications/dnotify.d -ofonedrive src/notifications/dnotify.d(166): Deprecation: Usage of the body keyword is deprecated. Use do instead. src/log.d(167): Deprecation: module std.exception is not accessible here, perhaps add 'static import std.exception;' src/log.d(167): Deprecation: module std.exception is not accessible here, perhaps add 'static import std.exception;' src/log.d(167): Deprecation: module std.exception is not accessible here, perhaps add 'static import std.exception;' src/log.d(167): Deprecation: module std.exception is not accessible here, perhaps add 'static import std.exception;' src/log.d(167): Deprecation: module std.exception is not accessible here, perhaps add 'static import std.exception;' src/log.d(167): Deprecation: module std.exception is not accessible here, perhaps add 'static import std.exception;' src/log.d(167): Deprecation: module std.exception is not accessible here, perhaps add 'static import std.exception;' src/log.d(167): Deprecation: module std.exception is not accessible here, perhaps add 'static import std.exception;' src/log.d(167): Deprecation: module std.exception is not accessible here, perhaps add 'static import std.exception;' src/log.d(167): Deprecation: module std.exception is not accessible here, perhaps add 'static import std.exception;' src/log.d(167): Deprecation: module std.exception is not accessible here, perhaps add 'static import std.exception;' src/log.d(167): Deprecation: module std.exception is not accessible here, perhaps add 'static import std.exception;' src/log.d(167): Deprecation: module std.exception is not accessible here, perhaps add 'static import std.exception;' src/log.d(167): Deprecation: module std.exception is not accessible here, perhaps add 'static import std.exception;' src/log.d(167): Deprecation: module std.exception is not accessible here, perhaps add 'static import std.exception;' src/log.d(167): Deprecation: module std.exception is not accessible here, perhaps add 'static import std.exception;' src/log.d(167): Deprecation: module std.exception is not accessible here, perhaps add 'static import std.exception;' src/log.d(167): Deprecation: module std.exception is not accessible here, perhaps add 'static import std.exception;' src/log.d(167): Deprecation: module std.exception is not accessible here, perhaps add 'static import std.exception;' src/log.d(167): Deprecation: module std.exception is not accessible here, perhaps add 'static import std.exception;' src/log.d(167): Deprecation: module std.exception is not accessible here, perhaps add 'static import std.exception;' src/log.d(167): Deprecation: module std.exception is not accessible here, perhaps add 'static import std.exception;' src/log.d(167): Deprecation: module std.exception is not accessible here, perhaps add 'static import std.exception;' src/qxor.d(67): Error: need this for lengthInBytes of type immutable(ulong) src/log.d(167): Deprecation: module std.exception is not accessible here, perhaps add 'static import std.exception;' src/log.d(167): Deprecation: module std.exception is not accessible here, perhaps add 'static import std.exception;' src/log.d(167): Deprecation: module std.exception is not accessible here, perhaps add 'static import std.exception;' src/log.d(167): Deprecation: module std.exception is not accessible here, perhaps add 'static import std.exception;' src/log.d(167): Deprecation: module std.exception is not accessible here, perhaps add 'static import std.exception;' src/log.d(167): Deprecation: module std.exception is not accessible here, perhaps add 'static import std.exception;' src/log.d(167): Deprecation: module std.exception is not accessible here, perhaps add 'static import std.exception;' src/log.d(167): Deprecation: module std.exception is not accessible here, perhaps add 'static import std.exception;' src/log.d(167): Deprecation: module std.exception is not accessible here, perhaps add 'static import std.exception;' src/log.d(167): Deprecation: module std.exception is not accessible here, perhaps add 'static import std.exception;' src/sync.d(2738): Deprecation: module std.exception is not accessible here, perhaps add 'static import std.exception;' src/log.d(167): Deprecation: module std.exception is not accessible here, perhaps add 'static import std.exception;' src/log.d(167): Deprecation: module std.exception is not accessible here, perhaps add 'static import std.exception;' src/sync.d(3858): Deprecation: module std.utf is not accessible here, perhaps add 'static import std.utf;' src/log.d(167): Deprecation: module std.exception is not accessible here, perhaps add 'static import std.exception;' src/log.d(167): Deprecation: module std.exception is not accessible here, perhaps add 'static import std.exception;' src/log.d(167): Deprecation: module std.exception is not accessible here, perhaps add 'static import std.exception;' src/sync.d(6522): Deprecation: module core.exception is not accessible here, perhaps add 'static import core.exception;' src/log.d(167): Deprecation: module std.exception is not accessible here, perhaps add 'static import std.exception;' make: *** [Makefile:101: onedrive] Error 1 ==> ERROR: A failure occurred in build(). Aborting...

MikeWalrus commented on 2021-06-19 09:00 (UTC)

@abraunegg Thanks! I'll wait for the next release.

abraunegg commented on 2021-06-10 18:12 (UTC) (edited on 2021-06-10 18:13 (UTC) by abraunegg)

@MikeWalrus

This error is due to DMD 2.097.0. This is already fixed upstream via https://github.com/abraunegg/onedrive/pull/1505

You have the following options:

  1. Use https://aur.archlinux.org/packages/onedrive-abraunegg-git/ to build from 'master'

  2. Build from master yourself

  3. Wait for the next release

  4. Downgrade your compiler to 2.096.1 to not hit this error

  5. Use LDC as your compiler rather than DMD

MikeWalrus commented on 2021-06-10 12:27 (UTC)

I am getting an error while building the binary:

src/qxor.d(67): Error: need `this` for `lengthInBytes` of type `immutable(ulong)`

yogeshm.007 commented on 2021-05-05 07:48 (UTC)

It broke after upgrade of liblphobos (to version 2:1.26.0-1) with the following error: "/usr/bin/onedrive: error while loading shared libraries: libphobos2-ldc-shared.so.95: cannot open shared object file: No such file or directory". I had to rebuild/reinstall for the error to disappear.

Pete commented on 2020-12-24 22:27 (UTC)

@Sgt_Skinner

It seems that you are using Manjaro, and unfortunately I don't have any experience with that. Normally, if a package builds manually, but not with the AUR helper (pamac in this case), it would indicate a bug in the AUR helper.

Manually installed packages can normally be uninstalled with pacman: pacman -R onedrive-abraunegg, but check the Manjaro docs to see if this holds true in Manjaro.

Sgt_Skinner commented on 2020-12-23 23:03 (UTC) (edited on 2020-12-23 23:06 (UTC) by Sgt_Skinner)

@Pete

pamac build onedrive-abraunegg.

The manual way is working, thank you.

Unfortunately I don't know how to 'uninstall' the version I've built from source, so I'll stick with that until I figure out how to do it.

Pete commented on 2020-12-23 22:15 (UTC) (edited on 2020-12-23 22:15 (UTC) by Pete)

@Sgt_Skinner

Could you let us know how you are building the AUR package? Do you use an AUR helper? If so, could you try to install it the "manual" way as described here: https://wiki.archlinux.org/index.php/Arch_User_Repository#Installing_and_upgrading_packages

If the compilation still doesn't succeed, could you post the output of the makepkg -si command? This will allow us to help you debug this issue.

Sgt_Skinner commented on 2020-12-23 21:56 (UTC) (edited on 2020-12-23 21:56 (UTC) by Sgt_Skinner)

@abraunegg

Sorry.

8GB of memory and 8GB of swap. I managed to build it from source, but building this very package gives me a segmentation fault. Might be a pamac issue, but every other AUR package compiles correctly

abraunegg commented on 2020-12-23 19:58 (UTC) (edited on 2020-12-23 19:59 (UTC) by abraunegg)

@Sgt_Skinner

Anyone else getting a segmentation fault when building this package?

As you have not provided any other details (like architecture your attempting to build on) - the main reason you get a segfault when compiling is this:

Build environment must have at least 1GB of memory & 1GB swap space

Please review https://github.com/abraunegg/onedrive/blob/master/docs/INSTALL.md for further details.

Sgt_Skinner commented on 2020-12-23 19:50 (UTC)

Anyone else getting a segmentation fault when building this package?

Pete commented on 2020-09-15 05:04 (UTC)

The package has now directories specified for bash, zsh and fish completion files.

oldherl commented on 2020-09-14 17:21 (UTC)

@Pete No, I am not a fish user and I don't know the right path. I am just trying to keep away from the /usr/local directory to avoid conflicts with non-pacman files.

On my system there are 5 files in /usr/share/fish/vendor_completions.d, 1 file in /usr/share/fish/completions, and 1 in /usr/share/fish/vendor_conf.d. So maybe you are right.

Pete commented on 2020-09-14 05:01 (UTC)

@oldherl Thanks for your suggestions. I'll indeed add the correct zsh completion path.

However, are you certain the fish path is correct? On my machine most fish files are in /usr/share/fish/vendor_completions.d/, not in /usr/share/fish/completions/. Where can I find documentation what is the right path?

oldherl commented on 2020-09-12 12:02 (UTC)

Also with --with-fish-completion-dir=/usr/share/fish/completions

oldherl commented on 2020-09-12 11:54 (UTC)

Please use --with-zsh-completion-dir=/usr/share/zsh/site-functions to avoid putting zsh completion files in /usr/local/share.

Pete commented on 2020-08-08 14:19 (UTC)

With help of @JP-Undercover the package now supports aarch64. Thanks JP-Undercover!

Pete commented on 2020-08-07 17:01 (UTC)

@JP-Undercover I'm happy to make the package aarch64 compatible, but unfortunately I don't have any opportunity to test it.

Could you: - Test if simply adding the architecture is enough - If not, make a patch and send it to me - Help out if later people need support for aarch64?

(If you want to contact me directly, see the email address in my profile)

oUndercover commented on 2020-08-05 11:43 (UTC) (edited on 2020-08-05 11:51 (UTC) by oUndercover)

In the PKGBUILD the architecture aarch64 is not present, however after checking the GDC and the LDC Wiki both seem compatible with this architecture, and using the liblphobos and ldc packages in a Raspberry Pi 4 running Manjaro-ARM (aarch64) i've sucefully installed the package in the system and after a dry run everything seems to be working.

Also in the github page it has specific instructions for this architecture and several others, which means they are officially supported, so I would imagine the PKGBUILD is incomplete?

Also while installing this on Manjaro-ARM and selecting the default packages, it tries to install libgphobos and gdc on the system, while the first conflicts with gcc-libs, so the only way to build this would be to use liblphobos and ldc. This is just a warning as I am aware that the AUR does not provide support for other arch based distros.

dctxmei commented on 2020-07-22 14:33 (UTC)

Through the test, there is no problem.

Pete commented on 2020-07-22 10:39 (UTC)

I have pushed a new version now with this change. Please test, and let me know if there are any problems.

dctxmei commented on 2020-07-22 10:10 (UTC)

I think this is good, thank you very much.

Pete commented on 2020-07-22 10:01 (UTC)

Unfortunately I don't have time to go into depth today, but I think I'll solve this by providing the --with-systemdsystemunitdir=DIR and --with-systemduserunitdir=DIR to the configure script. This will install the systems unit files always, without actually requiring systemd. Looking to other packages (such as e.g. nginx), this is the common thing to do.

What do you think? Would that solve your problem?

dctxmei commented on 2020-07-22 09:43 (UTC)

@Pete If you use extra-x86_64-build to build, because systemd is missing from makedepends=, the built package will not have onedrive.service and onedrive@.service files.

See: https://pastebin.com/1HTHJ1R9

My suggestion is to add systemd to makedepends=, of course, if you want to add it to optdepends= it is also good.

makedepends=('d-compiler' 'systemd')

See: https://pastebin.com/mP1DGrmQ

Pete commented on 2020-07-21 07:09 (UTC) (edited on 2020-07-21 07:10 (UTC) by Pete)

@dctxmei Thanks for your comment. Could you elaborate your request a bit more? Unfortunately I can't parse anymore information from the link you provided.

I'm not completely knowing the situation of "systemd-free" arch, but wouldn't adding systems as a dependency exclude those users? And, if systemd-free arch is not a thing to take into account, doesn't that mean that systemd is always present at build time?

dctxmei commented on 2020-07-20 09:27 (UTC)

Please add systemd to makedepends= so that the .service file will appear.

See: https://github.com/archlinuxcn/repo/issues/1748

fierce_brake commented on 2020-05-25 01:20 (UTC)

@abraunegg

Understood!

I just directly built from the repo. Worked fine.

I will be waiting!

Much appreciated!

abraunegg commented on 2020-05-25 01:13 (UTC)

@fierce_brake

This is due to LDC / DMD introducing a depreciation in the latest DMD version (DMD 2.092 and above).

The fix was commited in 'upstream' (see: https://github.com/abraunegg/onedrive/pull/916)

For the moment use https://aur.archlinux.org/packages/onedrive-abraunegg-git/ until v2.4.2 is released in the next few days.

suger commented on 2020-05-03 09:46 (UTC) (edited on 2020-05-03 09:47 (UTC) by suger)

@Pete, I'm happy to help you support it if needed. FWIW, I've just pulled your new version and it builds and works fine.

Pete commented on 2020-05-03 09:14 (UTC)

@sugar I enabled it now. I can't test it myself, so if it will cause any problems I will revert it.

suger commented on 2020-05-03 07:06 (UTC)

Would you mind adding armv7h to the PKGBUILD arch? It builds and works fine.

jogai commented on 2020-04-14 06:22 (UTC) (edited on 2020-04-14 06:24 (UTC) by jogai)

Thanks, that works.

Pete commented on 2020-04-14 05:14 (UTC)

@jogai Did you try to do a clean build of the package? It seems that it might be compiled with an older version of the library.

jogai commented on 2020-04-13 21:05 (UTC) (edited on 2020-04-14 06:25 (UTC) by jogai)

I was running this for a while without issues, but now, anything I do results in:

onedrive: error while loading shared libraries: libphobos2-ldc-shared.so.89: cannot open shared object file: No such file or directory

Details about my system:

OS: Manjaro Linux x86_64
Kernel: 5.6.2-1-MANJARO

LDC - the LLVM D compiler (1.20.1):

based on DMD v2.090.1 and LLVM 9.0.1

built with LDC - the LLVM D compiler (1.19.0)

Default target: x86_64-pc-linux-gnu

DMD64 D Compiler v2.091.0

pacman -Ss phobos

core/gcc-libs 9.3.0-1 [installed]

community/ldc 2:1.20.1-1 (dlang dlang-ldc) [installed]

community/liblphobos 2:1.20.1-1 (dlang dlang-ldc) [installed]

community/libphobos 1:2.091.0-1 (dlang dlang-dmd) [installed]

What is actually missing?

Pete commented on 2020-03-23 10:21 (UTC)

This package has been updated to 2.4.0. Note that:

"This release will require you to reauthorise your client. This is due to changing the client identifier to assist with resolving the correct handling of 429 error responses (activityLimitReached)" ( from https://github.com/abraunegg/onedrive/releases/tag/v2.4.0 )

Pete commented on 2020-02-21 11:24 (UTC)

d-runtime has been added as dependency

Pete commented on 2020-02-21 10:56 (UTC)

@aasami

I do think your ldc installation is broken. If you have ldc installed, you also should have liblphobos because it is a dependency of ldc ( https://www.archlinux.org/packages/community/x86_64/ldc/ ). It does not make sense to add it as a runtime dependency for this package, as people compiling with dmd don't need it.

That said, I guess it would theoretically correct to add something like d-runtime as a runtime dependency. I'll try to look later today if this is working.

aasami commented on 2020-02-21 10:48 (UTC)

I have compiled it with ldc without any issue. But to run onedrive i had to install liblphobos too. It should be mentioned as dependecy. Isn't it so?

hussam commented on 2020-02-10 22:26 (UTC)

It kept aborting if compiled with ldc. So I eventually compiled it with dmd instead. Sorry for the late reply.

abraunegg commented on 2020-02-09 22:48 (UTC)

@hussam

I am having issues with LDC but finally got 2.3.13 to run correctly

It would be good to get an idea of what issues you were having with LDC

when 2.3.14 is out

v2.3.14 will not be the next release, v2.4.0 will be. Waiting on a bug with Github & Microsoft to be resolved before this can be issued.

hussam commented on 2020-02-09 19:09 (UTC)

I am having issues with LDC but finally got 2.3.13 to run correctly. Would anyone be willing to provide 64bit packages for when 2.3.14 is out? Thank you.

Craigccfl commented on 2020-02-05 21:06 (UTC)

Added this to two computers, took less than 10-minutes each. Copied config and built sync_list. Working much better than other OneDrive packages I've used. Thanks

Pete commented on 2019-11-05 07:25 (UTC)

@florianmw Sure, that seems to work. I have updated it now, please let me know if you come across any issues.

florianmw commented on 2019-11-05 06:58 (UTC)

Can you please set makedepends to 'd-compiler' instead of 'dmd'? This would also work for ppl who have ldmd2 already installed and with 'd-compiler' they are free to choose the compiler. Configure will choose the one installed.

Pete commented on 2019-10-18 04:38 (UTC)

@hussam You are right, I have added this flag and the logrotate and bash-completion configurations are now installed in the right location.

hussam commented on 2019-10-17 23:10 (UTC)

I believe this package installs /usr/etc/logrotate.d/onedrive so perhaps consider adding --sysconfdir=/etc

abraunegg commented on 2019-10-17 21:24 (UTC) (edited on 2019-10-17 21:25 (UTC) by abraunegg)

@thesonu

As per the readme, please follow the directions here for posting issues with the client: https://github.com/abraunegg/onedrive/blob/master/README.md#reporting-issues

thesonu commented on 2019-10-17 21:09 (UTC)

I'm having trouble downloading anything with this package. I can install it and authenticate my account. onedrive --synchronize will start the sync process, but the moment it tries to download something it hangs and ends without any error message. Any ideas why this might be?

luukvbaal commented on 2019-06-14 23:44 (UTC)

@Pete Nope you're totally right, must have uninstalled it by accident. Sorry to bother you.

Pete commented on 2019-06-14 07:08 (UTC)

@luukvbaal pkgconf is part of the base-devel group, which is a pre-requirement for building anything on Arch. Packages in base-devel do not have to be added as a dependency.

See e.g. the notes about base-devel on https://wiki.archlinux.org/index.php/PKGBUILD

Let me know if I have misunderstood this, or if there is another reason that you think it should be added anyway.

luukvbaal commented on 2019-06-13 23:52 (UTC)

Configure fails without pkgconf installed. Should be added as dependency.

Pete commented on 2019-04-16 06:54 (UTC)

Terminal completions are now added for version 2.3.3.

abraunegg commented on 2019-04-11 07:39 (UTC)

Terminal completion supported by passing: COMPLETIONS=1 to make as per readme

Pete commented on 2019-04-11 06:49 (UTC) (edited on 2019-04-11 06:52 (UTC) by Pete)

@Modelmat The current package is built with NOTIFICATIONS=1. Although, my understanding is that NOTIFICATIONS=1 is not related to terminal completions, but allows notifications through libnotify.

Edit: I see now that there will be a COMPLETIONS flag in the next release. Thanks for letting me know, I'll test that flag and enable it if possible.

Modelmat commented on 2019-04-11 06:47 (UTC)

The abraunegg package will now supports terminal completions with NOTIFICATIONS=1 when building via make. Please add this to the PKGBUILD when the next package update is released.

Pete commented on 2019-03-29 10:51 (UTC)

This package can be used as a replacement for onedrive-abraunegg-git. It will be updated on every release from https://github.com/abraunegg/onedrive/releases .