- Aur-general - lists.archlinux.org

[aur-general] TU application - raster
by Carsten Haitzler 14 Sep '20

14 Sep '20

Hi Everyone. I'm Carsten - or Raster. Sponsors: eschwartz and shibumi agreed to +1 me I'm upstream founder of enlightenment, EFL, terminology and a few other things. I work at Arm in Cambridge, UK (and live here). I've been involved in OSS and releasing software since like 1995/96 or so for Linux (And other Unixen at the time). I've worked on several distributions - RedHat, Debian (made custom variant, not upstream) and Tizen. I pretty much eat, breathe and sleep C, and of course that comes with the requisite "I can drive a shell script off a cliff gracefully" developer skill-set. Linux is my OS. I don't dual boot. All my machines are Linux machines without booting into anything else and that's been the way for me for me since I got my first PC in 1996 after I had to give up on the Amiga. This PC then ran just Linux and nothing else (never saw a DOS or Windows install). In fact all but 2 of my machines are Arch Linux (Rockpro64 dev board (debian SID) and my Ampere Emag aarch64 workstation (Ubuntu), my pinephone has Manjaro for now which is kind-of-close to Arch...). I already maintain the AUR packages for efl-git, enlightenment-git, rage-git, efl-git-asan, enlightenment-git-asan and have for a long while now (also co-maintain terminology-git). You can see that I'm responsive to issues people bring up and fix them pretty fast. I have done some edits to the arch wiki as well over time. I will admit - I haven't really touched the Arch forums... I'm really an IRC/Email person, but I am on #archlinux, #archlinux-offtopic (and #archlinux-arm) most of the time. I've been using arch as my primary/only distro now for maybe about 4-5 years. I like its simplicity and "don't patch/modify things from upstream unless absolutely needed" policy (as an upstream I smile warmly at this direction). It's very developer friendly... and that's who I am. I also run ALARM on my Rapsberry Pis. I do spend most of my effort on the upstream work on these E related projects as those are what I write, release, add features to and fix bugs in. I'm about as googlable as it gets: raster(a)rasterman.com http://www.rasterman.com I know that there are a lot of packages to maintain for a very small number of people, so I'm happy to help out. I'd be best at taking over or being co-maintainer of: * efl * enlightenment * terminology Other packages I can add to community: * rage (https://aur.archlinux.org/packages/rage - i maintain rage-git already) * evisum (https://www.enlightenment.org/news/2020-06-07-evisum-05-release) And in future any others that I think are past the bar of "worth including in Arch community rather than AUR" over time (there are ones brewing or lurking like EDI https://www.enlightenment.org/about-edi, Ephoto https://www.enlightenment.org/about-ephoto, Enventor https://www.enlightenment.org/about-enventor) I'd also be happy to help maintain packages I know I depend on and work with that might be a bit niche like: * packagekit * ddcutil And in general just help attack anything that I know enough about to be a bit better than a bowl of dried up custard at that is in my general sphere of knowledge/use. My PGP key hash: 04F7A0E31E08D3E08D39AFEBD147F94364295E8C http://keys.gnupg.net/pks/lookup?op=get&search=0xD147F94364295E8C Looking forward to pitching in and making Arch better :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - raster(a)rasterman.com

8 11

[aur-general] Deletion of sxiv-cdown-git
by Chris Down 14 Sep '20

14 Sep '20

Hi there, It seems this morning sxiv-cdown-git was deleted. It exists as a (small) fork from sxiv with features geared towards using it as a photo manager which Bert has indicated are different from his goals in mainline, not merely a set of config options or whatever. I assume Eli deleted it because he thought it's a one-person package, but it has multiple users. I assume it was removed on this basis due to the name: > Make sure the package you want to upload is useful. Will anyone else want to > use this package? Is it extremely specialized? If more than a few people > would find this package useful, it is appropriate for submission. ...but it is acutually used by a number of people (I know, because I have others in my photography group who use it). Eli, on that basis, would you kindly consider restoring it? I'm happy to rename it sxiv-photomanager-git, or whatever else. I'm also a bit concerned about the predecent set for other packages which happen to bear my name, if that's the criteria for removal. For example, I have `systemd-cdown-git`, which is what I use when people report systemd problems to me and I write and ask them to try out some patches, so it's definitely used by more than a few people, albeit sporadically. Sure, I could just send PKGBUILDs and .install files around, but this seems reasonable to have on the AUR since it means I can just tell them the package to install, and things Just Work(tm). That strategy has been very successful in the past. If the naming is part of the rationale for removal, any suggestion for that one? Thanks, Chris

3 2

[aur-general] Resignation as Trusted User
by Giancarlo Razzolini 08 Sep '20

08 Sep '20

Hi Guys, TL:DR, stepping down as TU, remaining as developer and devops. I have been dabbling with this for a while now, but I think it's time. I haven't been handling a lot of TU related stuff for a long time now (with exception to voting). Keeping TU rights just for voting isn't the right thing to do, so, I therefore step down as a TU. I'll keep working on mkinitcpio and on devops, and I will continue to be available to *everyone*. Please, one of you remove my TU permissions on aurweb. Thank you all. Regards, Giancarlo Razzolini

5 6

[aur-general] Renaming package `sublime-text-3-imfix`
by joão marcos pereira bezerra 08 Sep '20

08 Sep '20

Hello, I hope that I'm in the right place to ask this. I am the maintainer of `sublime-text-3-imfix` https://aur.archlinux.org/packages/sublime-text-3-imfix/. As the previous maintainer commented before abandoning the package: > Sublime Text 3200 supports fcitx officially, the binary is the same as the original. So, now that the `imfix` suffix is unnecessary (but this package still being the main one), I wanted to rename this package to `sublime-text-3`, should I then delete this and create another one? --- Disclaimer: The package I maintain isn't the main one in popularity IF you compare with `sublime-text-dev` , but it lies about being an dev build, and is actually misleading people into downloading it, just to be the EXACT SAME as the stable version (we can tell about where it downloads the binaries from), so another question: Should I open a request to remove it for being dishonest? If you see the git history, it has always been like that. > commit 42d56cc9d0b082ab82684e5da23424fa296f66a7 > > Downgraded to build 3143, as 3153 can not be used without license. For context, dev builds require an 80$ license. And for some reason `sublime-text-nightly`, on the other hand, does exactly what `sublime-text-dev` description promisses to be doing, up-to-date binaries that require the paid license.

1 0

[aur-general] (no subject)
by khashayar nazari 06 Sep '20

06 Sep '20

۶۷/۷۵۸۰

1 0

[aur-general] PKGBUILD with side-effects outside of build-dir
by Knut Ahlers 06 Sep '20

06 Sep '20

Hey there, Today I received a comment [1] on one of the packages I'm maintaining asking for a change which I'm really not sure about: Basically the requested change is to have the build use an external environment variable (if set) which allows the packager to use an directory outside of the current build directory (the directory `makepkg` was executed in) for build assets. This would on the one hand allow packagers to reuse crates already built and not to build every dependency again within the build process of the package itself. On the other hand this would introduce side-effects to the package building process and also the system of the packager. For builds within isolated environments like Docker containers this would basically not change anything. My personal opinion is strongly biased against allowing side effects outside of the build-dir itself and against letting (developer-)environment-settings, of the systems which execute the build, interfere with the package build. In my opinion the build should stay in a way neither is allowed or at least prevented as far as possible. As I did not find advice / consent on this in the Wiki or AUR-General I'd like to have some opinions of other package maintainers on this: How would you like to have package builds behave? Act as isolated as possible, not reacting to outside influences (like env-vars) though this will never be fully achieved without some wrapper wiping all env-vars from the outside… OR Allow interference of outside influences and allow modifications outside the build directory (for example store the build artefacts outside the build-dir and package them from there)… Cheers, Knut [1] https://aur.archlinux.org/packages/dust/#comment-764039 -- Knut Ahlers Software & Infrastructure Developer Web & Blog: https://ahlers.me/ GPG-Key: 0xD34BE99E

3 2

[aur-general] AUR request notify mails
by Michael Straube 29 Aug '20

29 Aug '20

Hi, in the past, when I filed an AUR request, I got a copy (via CC ?, not sure..) of the request send to my email account. Today I opened https://lists.archlinux.org/pipermail/aur-requests/2020-August/043176.html but was not emailed. Has this behaviour changed? Is it intended? Went something wrong during the AUR migration to a new server? I'm just curious. ;) Michael

7 7

[aur-general] Removing py2 (make-)dependency vs. keeping py2 features ?
by Kr1ss 28 Aug '20

28 Aug '20

Hi, some while ago, @flying-sheep passed on their `pycharm-community-eap` package to me, which I have been co-maintaining for a while at that point. Recently, I got a user request to remove the (make) dependency to `python2-setuptools`- which was used to pre-compile a Python 2 debugger provided from upstream - or make it optional. Since on the one hand I agree that deprecating Python 2 is a good thing, but on the other hand there might be users who still (need to) work with Python 2, I'm wondering if and how to make a compromise would be the best way to go. There's no way to declare optional make-dependecies as far as I'm aware. For the time being I've removed the makedep, but also have implemented a check in the `PKGBUILD` if `python2-setuptools` is installed anyways and under that condition, the precompiled Python 2 debugger is included. I'm not sure about this anyways, especially in regard to the official `pycharm-community-edition` package in the `community` repo, which does still depend on `python2-setuptools` at build time. Hence my query to the mailing list asking for opinions/recommendations how I should handle this. Any thoughts are welcome. Thanks in advance ! - Kr1ss -

4 4

[aur-general] AUR - Best Practices when Package no longer Supported for Linux upstream but LTS fine?
by David C. Rankin 21 Aug '20

21 Aug '20

Aur devs, The virtualbox 5.2 branch is unsupported as of July 2020. Oracle continues to put out testbuilds for 5.2, but currently it does not build with 5.8 (LTS is fine). 5.2.44 was the last release for the 5.2 branch and there will be no further updates to support Linux 5.8. What do I do with the package? Do I mark it LTS only in some way, or just disown it or have it removed? -- David C. Rankin, J.D.,P.E.

2 3

[aur-general] Packaging ruby gems
by Anatoly Bashmakov 10 Aug '20

10 Aug '20

Hello. I need feedback on packaging ruby gems. First, I don't think packaging every gem of the latest version makes a lot of sense. For development there are rvm/rbenv/etc that solve this problem. The only gems need to package (I think) are gems that are required by end-user applications. But such applications may require gems not of the latest versions. So, there are several options here. 1) Bundle dependencies in the application itself. I don't like this approach at all, since the package begins providing a lot of unnecessary gems. Example: ruby-gollum-lib [1]. 2) Package dependency gems only of versions required by the application. For example, gollum-lib gem requires loofah ~2.3 (which means >= 2.3 and < 2.4). The latest version of loofah is 2.6.0. So naming package ruby-loofah of version 2.3.1 for gollum-lib may entails rightly flagging it as out of date. 3) Packaging versioned gems. In previous example the package will be called ruby-loofah-2_3 (or something) and add "provides" in PKGBUILD. It is not forbidden by package guidelines (but not encouraged either) as far as I remember. 4) Not package ruby gems at all. I don't like neither of these options, but I think packaging versioned gems is lesser evil. What are your thoughts? [1]: https://aur.archlinux.org/packages/ruby-gollum-lib/ -- Anatoly

2 2