Re: [aur-general] Resignation as Trusted User
On Mon, 2020-09-07 at 15:50 -0400, Santiago Torres-Arias via aur-general wrote: > Thank you for all your work Giancarlo. > > I'm relieved to open this email and see that you are sticking around. I > think you're a fundamental part of what keeps Arch not only going, but > improving. > > I think I did the thing, and you are now a normal user in the AUR > system. > > Cheers! > -Santiago > > On Mon, Sep 07, 2020 at 04:27:31PM -0300, Giancarlo Razzolini via aur-general > wrote: > > 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 I think he should be set as 'Developer', not normal user. Like so: https://aur.archlinux.org/account/allan Only devs can do this IIRC. Cheers, Filipe Laíns signature.asc Description: This is a digitally signed message part
Re: [aur-general] [arch-dev-public] AUR migration
On Mon, 2020-07-27 at 14:43 -1000, Gaetan Bisson via arch-dev-public wrote: > [2020-07-27 21:10:23 -0300] Giancarlo Razzolini: > > Em julho 27, 2020 21:03 Gaetan Bisson escreveu: > > > It's quite unsettling that we seem to be rushing to write a news post > > > while this very reasonable suggestion remains completely ignored. > > > > > > > It wasn't ignored. They keys were deliberately changed in the process. > > Why? Baptiste rightly points out "it's the same service as before and > (presumably) the host private keys were not compromised, so there is no > reason to change keys." Yet his message remains unanswered... If one machine gets compromised the keys are also compromised. If we can just use different keys on each machine to mitigate this, why wouldn't we? I think the short term bothers of changing the key do not warrant at all compromising security like this. But your experience might be different, is there anything in specific you are worried about or find annoying? I have been trying to figure what would possibly justify this but I can't, please let me know. Baptiste's answer was presumably under the assumption that the full machine would be migrated, but he would have to confirm. On which case, his request would be perfectly reasonable IMO. > > I think the issue you refer to happened on the orion -> gemini migration and > > You are correct. > > > I personally think that everything that runs as a service on Arch servers > > should > > be properly tracked on ansible, even if it's a user service. > > That is certainly a worthy goal but it does not imply that we must kill > everything that is not tracked by ansible at every migration. Copying > home directories over to the new host used to be standard practice for > any administrator of a system which serves multiple users... None of this happened, when it did hapen in soyuz everyone got properly notified and had plenty time to get their stuff out, on top of that, the system was backed up in case someone forgot. I don't understand what issue you are trying to get on here, Grazzolini already explained this did not happen. I agree with what you said, no machine should be killed without a proper handling of the user data, but what is the issue right now? Cheers, Filipe Laíns signature.asc Description: This is a digitally signed message part
Re: [aur-general] Question regarding orphan requests
On Thu, 2020-06-25 at 07:57 +0200, Tobias Witek wrote: > Hello, > > I filed an orphan request for a package (bumblebee-status-git) 3 > weeks ago - I am the upstream developer and would be willing to take > over the package ( I already maintain the bumblebee-status AUR) > > Unfortunately, I have been unable to establish contact with glaxxx, > the current maintainer, and the package is currently broken. > > How long does it typically take for an orphan request to be > processed? > > I am aware that you all are busy and the project is one of the > tiniest on AUR, so I do my best to be patient and I am grateful for > the great work you all are doing! > > Kind regards, > > tobi-wan Hi Tobias, Orphan requests get locked for 2 weeks to give time for the current maintainer to respond, after that they need to be manually approved by a TU. Approving requests is a manual action, and as such depends on the free time of the team members, so unfortunately from time to time the pending requests clog up. I have approved your request. Cheers, Filipe Laíns signature.asc Description: This is a digitally signed message part
Re: [aur-general] TU resignation - Lukas Jirkovsky (stativ)
Sorry to see you leaving :( On Fri, 2019-10-11 at 18:32 +0200, Morten Linderud via aur-general wrote: > log4cpp Adopted Thanks, Filipe Laíns signature.asc Description: This is a digitally signed message part
Re: [aur-general] TU application: kpcyrd
On Mon, 2019-10-07 at 11:10 -0400, Eli Schwartz via aur-general wrote: > On 10/7/19 10:59 AM, Levente Polyak via aur-general wrote: > > On 10/4/19 9:29 PM, Santiago Torres-Arias via aur-general wrote: > > > Hi, > > > > > > It's been 15 days (and a couple of hours as I'm aware) since, so > > > the > > > vote starts now: > > > > > > https://aur.archlinux.org/tu/?id=119 > > > > > > > Reminder, only 4 days left (aur vote notifications seem to be > > broken > > right now). > > Nah, notifications only get sent once every 12 hours, and only for > votes > that are ending in the next 48 hours. > > It seems a bit overkill to send notifications every 12 hours for the > majority of the voting period (3 days in, 4 left to go?) Perhaps we could send a initial notification to everyone? Some people don't check the mailing lists that often. -- Filipe Laíns signature.asc Description: This is a digitally signed message part
Re: [aur-general] Spam report - user: messytyagi
On Sat, 2019-05-18 at 12:53 +0200, Oscar Morante wrote: > And... another spammer here: > https://aur.archlinux.org/account/digidata I suspended the account. Thanks for letting us know. Filipe Laíns 3DCE 51D6 0930 EBA4 7858 BA41 46F6 33CB B0EB 4BF2 signature.asc Description: This is a digitally signed message part
Re: [aur-general] Spring cleaning (moving orphaned packages from [community] to AUR)
On Fri, 2019-03-22 at 15:02 +0100, Alexander F Rødseth via aur-general wrote: > monica - Monitor calibration tool > pathological - A puzzle game with the same feel as frozen bubble Adopted. Filipe Laíns 3DCE 51D6 0930 EBA4 7858 BA41 46F6 33CB B0EB 4BF2 signature.asc Description: This is a digitally signed message part
Re: [aur-general] How do I show a AUR Rebuild as a newer build?
Hey, On Sat, 2018-10-20 at 08:59 +0800, hagar wrote: > Good morning All, > > I understand that there are 3 version control tags in the PKGBUILD > file. > > > pkgver - The Actual Package version Yes. This is the main control version. > pkgrel - The Arch modification/release count - for changes to the > patches, install file's. This is an extra control version. 1.5.0-2 will be marked as a newer version over 1.5.0-1 and will show up in the updates. That's what you should be bumping if you need to rebuild the package. It will provide a the same version but in a new iteration/build of the package. > epoch - Special version control number. This is only used if you need to do rollbacks. Here's the version hierarchy: epoch > pkgver > pkgrel The version 2:1.4.0 will be higher in the hierarchy than 1:1.5.0, so pacman will remove 1:1.5.0 and install 2:1.4.0 on system updates. > If I need to rebuild a package due to dependancy rebuilds/changes how > do > I mark the new package as newer? Bump the pkgrel. > Do I increase the epoch? No. You never touch the epoch unless you need to rollback a package. > Or is there another way? No. Thanks, Filipe Laíns 3DCE 51D6 0930 EBA4 7858 BA41 46F6 33CB B0EB 4BF2 signature.asc Description: This is a digitally signed message part
Re: [aur-general] Questions about some of my packages being adopted in [community]
On Sat, 2018-09-29 at 20:57 +0100, Konstantin Gizdov wrote:
> Hi all,
>
> I'm writing to hopefully get some clarity on some packages that I
> maintained in AUR (python-awkward-array, unuran), but have been
> overtaken
> now in [community]. Also one other package that I have not maintained
> 'libafterimage', but dear to me.
>
> Firstly, thanks to Felix Yan for picking them up and sorry if the
> following
> questions have been asked before and obvious to everyone.
>
> This is what I know:
>
> 1. Nothing in the core repos depends on them and they are libraries.
> I've
> not seen requests to add them before.
That is not required.
> 2. 'libafterimage' includes a bug that has been reported to AUR, but
> has
> not been fixed. I've had to include a patch in my local chain.
> 3. The packages do not provide the same functionality as before, but
> conflict with the AUR ones.
Check my comments below.
> 4. I wasn't told anything - my AUR package was deleted with a 'thanks
> for
> maintaining it' message.
I try to ask before moving packages but that isn't always that easy. It
ends up delaying releases of a few packages. Besides, not everyone had
the same free time I do, so it's very reasonable that felix didn't
contact you first.
> 5. I've reported a few bugs FS#6024{6,7,8}, but have been denied
> resolution.
Regarding FS#60246
What did you do to reproduce this? Did you build in a clean chroot?
Right now the header files are being packaged and this should be
reproducible. If you can't reproduce this inside a clean chroot, then
open a bug report.
Regarding FS#60247
I left a comment there - https://bugs.archlinux.org/task/60247
Regarding FS#60248
Just release the python2 version of the package in the AUR.
> The reason I'm asking is because over the years I've added and been
> maintaining some professional software and these packages are part of
> that
> chain. Colleagues in the field have become accustomed to me for
> packaging
> with care and updating with new features. But now, obviously that is
> changing and people are going to flock if something doesn't work as
> expected. So this is sort of me getting ahead of the wind and
> basically
> asking the question:
>
> - Why?
Why what? Why were they moved? I don't know for sure but if they're
moderately popular, there's your reason.
> - How many & which will be put into [community]?
Popular packages could be moved to community if a TU wants to maintain
them.
> - How can I effectively communicate the nuts & bolts to the new
> maintenaners so to say, to make sure users still get what's expected?
The maintainers should be able to properly package the software on
their own. What users expect might not be the proper way to do it. If
you have a problem, you open a bug report or you send a mail to the
mailing list like you did, depending on the nature of the problem.
> - Is there anything I can do if new packages do not meet what the
> original
> intention was - apart from making a conflicting AUR package?
What original intention? Packages don't need to meet any intention.
They should be packaged acording to the guidelines
Thanks,
Filipe Laíns
3DCE 51D6 0930 EBA4 7858 BA41 46F6 33CB B0EB 4BF2
signature.asc
Description: This is a digitally signed message part
Re: [aur-general] Request to delete AUR package vim-tetris
On Fri, 2018-08-24 at 12:08 -0700, crt via aur-general wrote: > The project has not had an upstream update in just about a decade. > Instead of making this package an orphan I'd like to request to > remove > it from AUR. > > https://aur.archlinux.org/packages/vim-tetris/ > > Cheers Hello, You can submit a proper request in the package page by clicking in "Submit Request" > "Deletion". Thank you, Filipe Laíns 3DCE 51D6 0930 EBA4 7858 BA41 46F6 33CB B0EB 4BF2 signature.asc Description: This is a digitally signed message part
Re: [aur-general] Request to delete AUR package vim-tetris
On Fri, 2018-08-24 at 12:08 -0700, crt via aur-general wrote: > The project has not had an upstream update in just about a decade. > Instead of making this package an orphan I'd like to request to > remove > it from AUR. > > https://aur.archlinux.org/packages/vim-tetris/ > > Cheers Hello, You can submit a proper request on the package page by clicking in "Submit Request" > "Deletion". Thank you, Filipe Laíns 3DCE 51D6 0930 EBA4 7858 BA41 46F6 33CB B0EB 4BF2 signature.asc Description: This is a digitally signed message part
Re: [aur-general] python traceback on git push
Hey Georg,
This is a known issue[1]. Eli tried to fix it but the patch doesn't
seem to be working.
[1] https://bugs.archlinux.org/task/59278
Thank you,
Filipe Laíns
3DCE 51D6 0930 EBA4 7858 BA41 46F6 33CB B0EB 4BF2
On Thu, 2018-07-19 at 18:11 +0200, Georg wrote:
> Hi,
>
> I just updated a few packages and ran into an issue with the AUR:
>
> $ git push
> [&]
> remote: Traceback (most recent call last):
> remote: File "/usr/bin/aurweb-notify", line 11, in
> remote: load_entry_point('aurweb==4.7.0', 'console_scripts',
> 'aurweb-notify')()
> remote: File
> "/usr/lib/python3.6/site-packages/aurweb-4.7.0-
> py3.6.egg/aurweb/scripts/notify.py",
> line 541, in main
> remote: File
> "/usr/lib/python3.6/site-packages/aurweb-4.7.0-
> py3.6.egg/aurweb/scripts/notify.py",
> line 69, in send
> remote: File
> "/usr/lib/python3.6/site-packages/aurweb-4.7.0-
> py3.6.egg/aurweb/scripts/notify.py",
> line 56, in get_body_fmt
> remote: File
> "/usr/lib/python3.6/site-packages/aurweb-4.7.0-
> py3.6.egg/aurweb/scripts/notify.py",
> line 192, in get_body
> remote: File
> "/usr/lib/python3.6/site-packages/aurweb-4.7.0-
> py3.6.egg/aurweb/l10n.py",
> line 14, in translate
> remote: File "/usr/lib/python3.6/gettext.py", line 514, in
> translation
> remote: raise OSError(ENOENT, 'No translation file found for
> domain', domain)
> remote: FileNotFoundError: [Errno 2] No translation file found for
> domain: 'aurweb'
> [&]
>
> the push succeeded nonetheless.
>
> Georg
Sent via Migadu.com, world's easiest email hosting
Re: [aur-general] TU Application - Filipe Laíns
Hey, On Fri, Jul 13, 2018 at 3:20 PM, Michael Straube via aur-general wrote: >-DCAMKE_INSTALL_LIBDIR=lib ? Thank you! I will use that. I am more of a meson guy and this kind of isn't usually a problem. Now that I see, the solution is really simple and I feel a bit silly, ahah. >All the best and good luck for you application, Thank you! Filipe Laíns :) signature.asc Description: OpenPGP digital signature
Re: [aur-general] TU Application - Filipe Laíns
Hey, On Fri, Jul 13, 2018 at 3:45 PM, Eli Schwartz via aur-general wrote: >Very few people are "good enough" when I really get on a roll... I >generally consider it sufficient that people learn from my critiques, >fix them promptly, and incorporate that feedback into further efforts. > >The only thing that really startled me, actually, were the packages >which build ELF binaries but were marked as "any" packages. I understand. To be fair in AUR we only build the package for our architecture, so that never seemed like a red flag until you pointed it out. But now I see how important it is to have a proper arch field :) >As with the other unquoted variables issues... it may have been >committed 11 days ago but my git pull from when I started my review did >not have that yet, perhaps you never pushed it? > >I did say some of those issues were already fixed before I sent off my >email -- I did not go back to re-analyze the packages I'd already looked >at based on the fixed versions. ;) That was probably it, sorry. >Then I would guard this by > >if [[ $CARCH = x86_64 ]]; then >do_64_bit_things >else >do_32_bit_things >fi > >Don't ignore unexpected errors, if there's no lib64 folder on x86_64 >builds then something went wrong and either should be fixed, or old >workarounds should be removed -- either way using || true, means you'll >never know. I'll use Michael's approach but thanks for pointing this out, it will probably be useful in similar situations that can't be resolved in cmake. >nodejs packaging confuses me incredibly. I've only got one package which >uses nodejs, and this is what I do: >https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=rapydscript-ng-git#n38 > >I build it in build() and then I manually cp things to $pkgdir and write >my own symlink for /usr/bin scripts. It seems to work okay... I agree. That's a good approach but I think mine is a bit cleaner, ahah :) >For your three electron apps, you get to have fun, because electron is >fun! Haha, I lied, it's not fun at all. > >They're basically always bin packages because electron. Debundling is >complicatedly weird, but I've successfully done so for e.g. >community/keybase-gui. When I get around to it I need to create a new >wiki page documenting how to handle this correctly... > >I definitely understand if you've got no will to make proper non-bin >packages, that being said it would be neat if you could do so anyway >since having dozens of outdated, insecure copies of prebuilt electron >(thanks, electron devs!) is pretty dreary and also wasteful of disk >space. That is something I'll keep in mind this summer. I really dislike electron because I don't see the point of packaging a full runtime with each app (!!) so I am not really motivated to maintain non-bin electron packages. I might try to do it if I have spare time, that could turn out to be a fun puzzle. Thanks, Filipe Laíns signature.asc Description: OpenPGP digital signature
Re: [aur-general] TU Application - Filipe Laíns
Hey, First of all I just want to say that I have 58 packages on AUR and most of the PKGBUILDs (written by me) were written before I knew some of this. I tried to update most of them but as it's a really monotonous task, I missed some things. Eli, thanks for pointing them out. Also, most of these packages were orphan and I adopted them, I did not fix some of the mistakes right away because I didn't know these were indeed mistakes. With the time I learned about them but I didn't fix some of the packages because I have a lot of them. I have been fixing them as people point it out or when the PKGBUILD needs to be manually updated. Lately I have been making an effort to fix everything but apparently it wasn't enough. On Thu, Jul 12, 2018 at 11:04 PM, Eli Schwartz via aur-general wrote: > It's always nice to see people eager to contribute more, good luck! Thank you! > We'll need permission from them for binary redistribution with > all-rights-reserved software... they pretty specifically only offer > single-user personal licenses to download, install, and run one copy > from them alone. Like most proprietary EULA'ed software. Sure. > antlr3: > - you updated the source to HTTPS on my advice, but forgot the url Fixed. > babl-git: > - !libtool is not needed to build, and comes as default anyway these > days > - ./autogen.sh should be moved to prepare, and moved to autoreconf -fi > if at all possible. In this case, it's a wrapper for autoreconf > already :) Fixed. > cellular-network-configs-git: > - unquoted srcdir/pkgdirThis was fixed in commit 4a4273f72a93824a16a2c1e86308986b26d9df54[1] This was fixed by commit 4a4273f72a93824a16a2c1e86308986b26d9df54[1] which is dated to 11 days ago so I don't understand. [1] https://aur.archlinux.org/cgit/aur.git/commit/?h=cellular-network-configs-git=4a4273f72a93824a16a2c1e86308986b26d9df54 > cm256cc: > - are the mv commands needed or not? > - depends on boost but may only need that as makedepends, see if runtime > depends could get away with only boost-libs The package installs the 64bit libraries in 'lib64' and 32bit ones in 'lib'. I am not comfortable enough to edit the CMakeLists file but if anyone wants to submit a patch, I would be happy to accept it :) > dump1090-mutability-git: > - unquoted srcdir/pkgdir That was fixed in commit e28ca199c321913aec5295650fa34e0b3c4d81cc[2] which, again, dates to 11 days ago. > - source should clone over git+https:// for TLS certificate checking Fixed. > - install script should switch to using systemd-sysusers > - install script should not delete users on uninstall as this can be a > security risk: https://www.archlinux.org/todo/usergroup-management/ > - consider just using systemd DynamicUsers to run the service I will fix this in one of the next few days. [2] https://aur.archlinux.org/cgit/aur.git/commit/?h=dump1090-mutability-git=e28ca199c321913aec5295650fa34e0b3c4d81cc > evernote-sdk-python: > - patching should be done in prepare not build > - should run python setup.py build in build before running install in > package Sorry about that. Fixed. > franz: > - electron apps should use the system electron if possible > - architecture-dependent binaries should go in /usr/lib not /usr/share > - try to get desktop file into upstream project > - should not conflict the bin package -- that is the bin package's job This package is broken and needs to be fixed in the upstream repository. I haven't fixed any of this issues because that. Once we are able to properly built the project, I will fix the whole PKGBUILD. > gdc1-bin: > - sources should use HTTPS > > gdc-bin: > - unquoted srcdir/pkgdir > - sources should use HTTPS > > gdc-git: > - unquoted srcdir/pkgdir > - sources should use HTTPS > - binutils is in base-devel and should not be a makedepends Fixed. Same story, e9488cd4afbe1eb2356a2ab32d85ba5f58f41049[3] [3] https://aur.archlinux.org/cgit/aur.git/commit/?h=gdc-bin=e9488cd4afbe1eb2356a2ab32d85ba5f58f41049 > gegl-git: > - autogen.sh in build should be moved to autoreconf -fi in prepare Done. > gimp-git: > - url should be HTTPS > - move sed'ing of configure.ac, autogen, to prepare and use autoreconf Done. > gr-limesdr-git: > gr-limesdr: > - MIT license must be installed in package Fixed. > inspectrum: > - style: license array sticks out like a sore thumb by not being quoted > like the surrounding variables > - pkg-config is in base-devel and should not be a makedepends Fixed. > cellular-network-configs-git: > evernote-sdk-python: > gr-limesdr-git: > gr-limesdr: > limesuite: > lime-tools-git: > lms7002m-driver-git: > - style: arch array sticks out like a sore thumb by not being quoted > like the surrounding variables Already fixed that. > me-edit: > - should build from source > - don't use specific sourceforge mirror to download > - wrapper script does not need to popd right before exiting a script > - wrapper script would be better off symlinking to /usr/bin/ if possible I will fix this later. >
Re: [aur-general] TU Application - Filipe Laíns
Hey, First of all I just want to say that I have 58 packages on AUR and most of the PKGBUILDs (written by me) were written before I knew some of this. I tried to update most of them but as it's a really monotonous task, I missed some things. Eli, thanks for pointing them out. Also, most of these packages were orphan and I adopted them, I did not fix some of the mistakes right away because I didn't know these were indeed mistakes. With the time I learned about them but I didn't fix some of the packages because I have a lot of them. I have been fixing them as people point it out or when the PKGBUILD needs to be manually updated. Lately I have been making an effort to fix everything but apparently it wasn't enough. On Thu, Jul 12, 2018 at 11:04 PM, Eli Schwartz via aur-general wrote: > It's always nice to see people eager to contribute more, good luck! Thank you! > We'll need permission from them for binary redistribution with > all-rights-reserved software... they pretty specifically only offer > single-user personal licenses to download, install, and run one copy > from them alone. Like most proprietary EULA'ed software. Sure. > antlr3: > - you updated the source to HTTPS on my advice, but forgot the url Fixed. > babl-git: > - !libtool is not needed to build, and comes as default anyway these > days > - ./autogen.sh should be moved to prepare, and moved to autoreconf -fi > if at all possible. In this case, it's a wrapper for autoreconf > already :) Fixed. > cellular-network-configs-git: > - unquoted srcdir/pkgdirThis was fixed in commit 4a4273f72a93824a16a2c1e86308986b26d9df54[1] This was fixed by commit 4a4273f72a93824a16a2c1e86308986b26d9df54[1] which is dated to 11 days ago so I don't understand. [1] https://aur.archlinux.org/cgit/aur.git/commit/?h=cellular-network-configs-git=4a4273f72a93824a16a2c1e86308986b26d9df54 > cm256cc: > - are the mv commands needed or not? > - depends on boost but may only need that as makedepends, see if runtime > depends could get away with only boost-libs The package installs the 64bit libraries in 'lib64' and 32bit ones in 'lib'. I am not comfortable enough to edit the CMakeLists file but if anyone wants to submit a patch, I would be happy to accept it :) > dump1090-mutability-git: > - unquoted srcdir/pkgdir That was fixed in commit e28ca199c321913aec5295650fa34e0b3c4d81cc[2] which, again, dates to 11 days ago. > - source should clone over git+https:// for TLS certificate checking Fixed. > - install script should switch to using systemd-sysusers > - install script should not delete users on uninstall as this can be a > security risk: https://www.archlinux.org/todo/usergroup-management/ > - consider just using systemd DynamicUsers to run the service I will fix this in one of the next few days. [2] https://aur.archlinux.org/cgit/aur.git/commit/?h=dump1090-mutability-git=e28ca199c321913aec5295650fa34e0b3c4d81cc > evernote-sdk-python: > - patching should be done in prepare not build > - should run python setup.py build in build before running install in > package Sorry about that. Fixed. > franz: > - electron apps should use the system electron if possible > - architecture-dependent binaries should go in /usr/lib not /usr/share > - try to get desktop file into upstream project > - should not conflict the bin package -- that is the bin package's job This package is broken and needs to be fixed in the upstream repository. I haven't fixed any of this issues because that. Once we are able to properly built the project, I will fix the whole PKGBUILD. > gdc1-bin: > - sources should use HTTPS > > gdc-bin: > - unquoted srcdir/pkgdir > - sources should use HTTPS > > gdc-git: > - unquoted srcdir/pkgdir > - sources should use HTTPS > - binutils is in base-devel and should not be a makedepends Fixed. Same story, e9488cd4afbe1eb2356a2ab32d85ba5f58f41049[3] [3] https://aur.archlinux.org/cgit/aur.git/commit/?h=gdc-bin=e9488cd4afbe1eb2356a2ab32d85ba5f58f41049 > gegl-git: > - autogen.sh in build should be moved to autoreconf -fi in prepare Done. > gimp-git: > - url should be HTTPS > - move sed'ing of configure.ac, autogen, to prepare and use autoreconf Done. > gr-limesdr-git: > gr-limesdr: > - MIT license must be installed in package Fixed. > inspectrum: > - style: license array sticks out like a sore thumb by not being quoted > like the surrounding variables > - pkg-config is in base-devel and should not be a makedepends Fixed. > cellular-network-configs-git: > evernote-sdk-python: > gr-limesdr-git: > gr-limesdr: > limesuite: > lime-tools-git: > lms7002m-driver-git: > - style: arch array sticks out like a sore thumb by not being quoted > like the surrounding variables Already fixed that. > me-edit: > - should build from source > - don't use specific sourceforge mirror to download > - wrapper script does not need to popd right before exiting a script > - wrapper script would be better off symlinking to /usr/bin/ if possible I will fix this later. >
[aur-general] aur-general Digest, Vol 165, Issue 7
Hey, First of all I just want to say that I have 58 packages on AUR and most of the PKGBUILDs (written by me) were written before I knew some of this. I tried to update most of them but as it's a really monotonous task, I missed some things. Eli, thanks for pointing them out. Also, most of these packages were orphan and I adopted them, I did not fix some of the mistakes right away because I didn't know these were indeed mistakes. With the time I learned about them but I didn't fix some of the packages because I have a lot of them. I have been fixing them as people point it out or when the PKGBUILD needs to be manually updated. Lately I have been making an effort to fix everything but apparently it wasn't enough. On Thu, Jul 12, 2018 at 11:04 PM, Eli Schwartz via aur-general wrote: > It's always nice to see people eager to contribute more, good luck! Thank you! > We'll need permission from them for binary redistribution with > all-rights-reserved software... they pretty specifically only offer > single-user personal licenses to download, install, and run one copy > from them alone. Like most proprietary EULA'ed software.Sure. > antlr3: > - you updated the source to HTTPS on my advice, but forgot the url Fixed. > babl-git: > - !libtool is not needed to build, and comes as default anyway these > days > - ./autogen.sh should be moved to prepare, and moved to autoreconf -fi > if at all possible. In this case, it's a wrapper for autoreconf > already :) Fixed. > cellular-network-configs-git: > - unquoted srcdir/pkgdirThis was fixed in commit > 4a4273f72a93824a16a2c1e86308986b26d9df54[1] This was fixed by commit 4a4273f72a93824a16a2c1e86308986b26d9df54[1] which is dated to 11 days ago so I don't understand. [1] https://aur.archlinux.org/cgit/aur.git/commit/?h=cellular-network-configs-git=4a4273f72a93824a16a2c1e86308986b26d9df54 > cm256cc: > - are the mv commands needed or not? > - depends on boost but may only need that as makedepends, see if runtime > depends could get away with only boost-libs The package installs the 64bit libraries in 'lib64' and 32bit ones in 'lib'. I am not comfortable enough to edit the CMakeLists file but if anyone wants to submit a patch, I would be happy to accept it :) > dump1090-mutability-git: > - unquoted srcdir/pkgdir That was fixed in commit e28ca199c321913aec5295650fa34e0b3c4d81cc[2] which, again, dates to 11 days ago. > - source should clone over git+https:// for TLS certificate checking Fixed. > - install script should switch to using systemd-sysusers > - install script should not delete users on uninstall as this can be a > security risk: https://www.archlinux.org/todo/usergroup-management/ > - consider just using systemd DynamicUsers to run the service I will fix this in one of the next few days. [2] https://aur.archlinux.org/cgit/aur.git/commit/?h=dump1090-mutability-git=e28ca199c321913aec5295650fa34e0b3c4d81cc > evernote-sdk-python: > - patching should be done in prepare not build > - should run python setup.py build in build before running install in > package Sorry about that. Fixed. > franz: > - electron apps should use the system electron if possible > - architecture-dependent binaries should go in /usr/lib not /usr/share > - try to get desktop file into upstream project > - should not conflict the bin package -- that is the bin package's job This package is broken and needs to be fixed in the upstream repository. I haven't fixed any of this issues because that. Once we are able to properly built the project, I will fix the whole PKGBUILD. > gdc1-bin: > - sources should use HTTPS > > gdc-bin: > - unquoted srcdir/pkgdir > - sources should use HTTPS > > gdc-git: > - unquoted srcdir/pkgdir > - sources should use HTTPS > - binutils is in base-devel and should not be a makedepends Fixed. Same story, e9488cd4afbe1eb2356a2ab32d85ba5f58f41049[3] [3] https://aur.archlinux.org/cgit/aur.git/commit/?h=gdc-bin=e9488cd4afbe1eb2356a2ab32d85ba5f58f41049 > gegl-git: > - autogen.sh in build should be moved to autoreconf -fi in prepare Done. > gimp-git: > - url should be HTTPS > - move sed'ing of configure.ac, autogen, to prepare and use autoreconf Done. > gr-limesdr-git: > gr-limesdr: > - MIT license must be installed in package Fixed. > inspectrum: > - style: license array sticks out like a sore thumb by not being quoted > like the surrounding variables > - pkg-config is in base-devel and should not be a makedepends Fixed. > cellular-network-configs-git: > evernote-sdk-python: > gr-limesdr-git: > gr-limesdr: > limesuite: > lime-tools-git: > lms7002m-driver-git: > - style: arch array sticks out like a sore thumb by not being quoted > like the surrounding variables Already fixed that. > me-edit: > - should build from source > - don't use specific sourceforge mirror to download > - wrapper script does not need to popd right before exiting a script > - wrapper script would be better off symlinking to /usr/bin/ if possible I will fix this later. >
[aur-general] TU Application - Filipe Laíns
Hello, My name is Filipe Laíns. You might also know me by my alias, FFY00. I am applying to be a Trusted User with Dan Printzell's (Wild) sponsorship. Let's get to the part where you get to know me a bit more I am a Portuguese student and I use Linux as my main operating system since 2013. I gave Arch a try last year and I've been in love with it's ecosystem ever since. Since then, I started contributing to AUR and I've been maintaining quite a few packages. I am also fairly active in the Open Source community as you can see in my Github profile[1]. I love to help people and that is my main motivation to become a TU. If I do become a Trusted User, one thing I would like to do is to improve the usability of Arch for SDR (software defined raio) development. I think Arch is a great system for this and it's a bit of a shame that one of the most relevant packages (soapysdr) isn't in any official repo. Most of the work to improve the SDR support in Arch has been done by Kyle Keen, and I thank him for that, but I still think we could do a bit more. I don't plan to only maintain SDR related packages. I would like to maintain anything that I use, or anything that is relevant to anyone, really. If it makes someone's life easier it's a win. With that being said, here's a list of packages that I plan to move to community: - soapysdr - soapyrtlsdr - libratbag - piper - tribler - qspectrumanalyzer - pulseaudio-equalizer-ladspa - synology-cloud-station-drive Some comments on the packages, (soapysdr and soapyrtlsdr) soapysdr is a vendor neutral SDR driver[2] and soapyrtlsdr is the rtlsdr plugin for it. The non -git versions of the packages are quite recent so they don't have much votes yet. Their correspondent -git variants have enough votes. (libratbag and piper) libratbag is a DBus daemon to configure gaming mice[3] and piper is a GTK+ app to interface with it. I do not maintain this packages but I contribute to the upstream development. It would be helpful for the project if they were moved to an official repo as we are thinking about changing our CI's base distribution from Fedora to Arch. (tribler) Tribler is a popular torrent client with P2P content discovery[4]. (qspectrumanalyzer) This is a popular spectrum analyser for SDR devices[5]. It uses soapysdr as its default driver so it supports a wide range of SDR devices. (pulseaudio-equalizer-ladspa) This is a pulseaudio equalizer based on a ladspa plugin. It has a nice GTK+ based front-end to configure it. (synology-cloud-station-drive) This is a drive client for Synology devices[6]. I am also interested in adopting the following packages in community: - netcf - znc (packages bellow - probably, depending on my free time) - python2-caja - python2-cheetah - python2-exiv2 - python2-fastimport - python2-ipaddr I think that's it, thanks for bearing with me until the end. Best regards, Filipe Laíns ^.^ [1] https://github.com/FFY00 [2] https://github.com/pothosware/SoapySDR/wiki#features [3] https://github.com/libratbag/libratbag#libratbag [4] https://github.com/Tribler/tribler#tribler [5] https://github.com/xmikos/qspectrumanalyzer#qspectrumanalyzer [6] https://www.synology.com/en-global/releaseNote/CloudStationDrive signature.asc Description: OpenPGP digital signature
