Re: [aur-general] [AUR4] Error when upload a update pkgbuild : remote: error: missing install file: avidemux.install
On Sun, 07 Jun 2015 at 16:03:29, SpinFlo wrote: Hi. y try to update a pkgbuild. but server refuses by: remote: error: The following error occurred when parsing commit remote: error: 8ba6f94497960275d1a78f913163df30b238cf72: remote: error: missing install file: avidemux.install remote: error: hook declined to update refs/heads/master To ssh+git://aur4.archlinux.org/avidemux-git.git/ ! [remote rejected] master - master (hook declined) but in my pkgbuild, the install file is called 'avidemux-git.install' need the rename that file to 'avidemux.install'? or is a AUR4 hook error the last update for this package make a zero problems about this file is a new mandatory? Yes, it is a new check. Are you sure the file is called avidemux-git.install in the PKGBUILD? What about the install field in .SRCINFO? Also make sure you are looking at the right commit (8ba6f94). greetings
Re: [aur-general] Anyone know when aur4.archlinux.org will be back up?
On Mon, 01 Jun 2015 at 13:41:18, Alan Jenkins wrote: Hey guys, I am trying to get my packages sorted for AUR4 while I have access to my Arch computer which is only for a few more hours today but the aur4.archlinux.org site is currently down for maintenance. Anyone know when the site is due to be back online so I can set my SSH public key for my account? The aur4.archlinux.org database will be reset and synced with aur.archlinux.org on June 8th. We disabled the AUR 4 setup to make sure people don't start uploading their packages now (and forget about the actual migration period). If you had set your SSH public key now, you would have to reset it after June 8th anyway. You can, however, start preparing Git repositories for your AUR packages and push them next Monday. Thanks, Alan Jenkins Regards, Lukas
Re: [aur-general] [RFC v2] Draft of the AUR 4.0.0 migration notification
On Sun, 31 May 2015 at 20:55:17, Duru Can Celasun wrote: [...] Not a major concern, but will it be possible to merge comments / votes / flags from the old AUR instance? What do you mean by merge comments? Current package comments and votes can be retained, i.e. merged into the new database on June 8th. Any changes to the aur.archlinux.org database made after June 8th will be lost. That includes user account changes, comments, votes, package requests etc. Please use aur4.archlinux.org for this kind of things.
[aur-general] [RFC v2] Draft of the AUR 4.0.0 migration notification
The original thread is too cluttered already so I decided to submit the second version in a separate thread. The only real change is that we decided to not make aur.archlinux.org a read-only archive such that users still get updates during the transition period (if AUR package maintainers decide to update both aur.archlinux.org and aur4.archlinux.org). Hello, This is an automated email to all AUR package maintainers. Starting from June 8th, 2015, the Arch User Repository is being migrated to a Git-based platform. If you want to continue maintaining your AUR packages, please submit them to aur4.archlinux.org before July 8th, 2015. We reserved all packages you are currently maintaining on aur.archlinux.org, such that nobody else can overwrite them. However, if you choose not to resubmit your package, we will cancel that reservation on July 8th. As of July 8th, you can submit packages that were not taken care of by their maintainers. On August 8th, the archive at aur.archlinux.org will be replaced by aur4.archlinux.org and the former aur.archlinux.org source tarballs will be made available for reference. Keep in mind to submit any package updates made between June 8th and August 8th to aur4.archlinux.org. Anything submitted to aur.archlinux.org during that period of time will be lost. For instructions on the new package submission process, please consult the Arch wiki [1]. If you encounter any bugs, please report them to the aurweb bug tracker [2]. Happy packaging! [1] https://wiki.archlinux.org/index.php/Arch_User_Repository#AUR_4 [2] https://bugs.archlinux.org/index.php?project=2 We are going to notify all AUR package maintainers tomorrow. If you have concerns, please raise them now. Regards, Lukas
Re: [aur-general] [Aur4] translations in transifex
On Thu, 28 May 2015 at 23:13:33, Pablo Lezaeta Reyes wrote: I noticed that aur4 have some new strings but the transifex page has not pudated they string in a whole and also there are new complate and +50% languages. Is planed to update the transifex sometime soon? and the lang selector in home page of aur now will use the native name instead of ca_CA or fo_BA? [...] Yes, it will be done soon, a couple of weeks before the official AUR 4.0.0 release. It might be a good idea to switch to using native language names for all languages in the selector. Thanks for the suggestion, I will look into it soon. Please send anything related to aurweb development to the aur-dev mailing list in the future. Thanks!
Re: [aur-general] How to update .SRCINFO without creating a tarball?
On Thu, 28 May 2015 at 11:49:07, Νῖκος Θεοδώρου wrote: [...] Since you're at it, why don't you make the git push part a bit clearer, since many of us are unfamiliar with git? Ie, you could put the steps like that: 1. Create a new (empty) package base foobar, run the following command: $ ssh aur-dev.archlinux.org setup-repo foobar 2. Clone the (initially empty) package repository via SSH: $ git clone ssh+git://aur-dev.archlinux.org/foobar.git/ 3. Change into the directory: $ cd foobar/ 3. Copy the relevant files from previous AUR folder: $ cp ~/AUR/coolvlviewer/* ./ 4. mksrcinfo from the package blah-blah $ mksrcinfo 5. $ git add . 6. $ git commit -m Initial commit (or whatnot) 7. Push: $ git push -u origin master [...] Added a simplified version of this to the wiki.
Re: [aur-general] Ho to update .SRCINFO without creating a tarball?
On Sat, 23 May 2015 at 11:34:38, Manuel Reimer wrote: Hello, I'm doing my first steps with AUR 4.0 and I'm asked to commit both, PKGBUILD and .SRCINFO. .SRCINFO is automatically created with makepkg --source, but there is no need for a tarball when pushing to GIT. So what I think that would be useful is something like makepkg --upgradesrcinfo or something like that. I something like this already available? You can use mksrcinfo from pkgbuild-introspection. Maybe we should add some tips to the Arch wiki. Manuel
[aur-general] [RFC] Draft of the AUR 4.0.0 migration notification
Hi, I just added a section to the AUR article in the Arch wiki that describes how to submit packages to the new AUR. Here is a draft of the notification that I plan to send to all AUR package maintainers on June 1st: Hello, This is an automated email to all AUR package maintainers. Starting from June 8th, 2015, the official AUR web interface at aur.archlinux.org becomes a read-only archive for two months. During that period of time, you will not be able to submit package updates, comments or package requests. If you want to continue maintaining your AUR packages, please submit them to aur4.archlinux.org until July 7th, 2015. We reserved all packages you are currently maintaining on aur.archlinux.org, such that nobody else can overwrite them. However, if choose not to resubmit your package, we will cancel that reservation on July 8th. This allows anybody to take over the package. On August 8th, the read-only archive at aur.archlinux.org will be replaced by aur4.archlinux.org and the former aur.archlinux.org source tarballs will be made available on some archive. For instructions on the new package submission process, please check the Arch wiki [1]. If you encounter any bugs, please report them to the aurweb bug tracker [2]. Happy packaging! [1] https://wiki.archlinux.org/index.php/Arch_User_Repository#Submitting_packages_to_aur-dev.archlinux.org [2] https://bugs.archlinux.org/index.php?project=2 Note that aur4.archlinux.org does not work yet but will updated to point to the same IP address as aur-dev.archlinux.org soon. Comments welcome. Regards, Lukas
[aur-general] aur-dev no longer uses port 2222 for SSH
Hi, If you are using the AUR 4.0.0 testing environment on aur-dev.archlinux.org, please note that we now use the default SSH port 22 instead of . This means that you can drop the : part from your Git remote URIs or remove the Port line from your local SSH configuration. We are currently preparing the migration to AUR 4.0.0 and we are going to inform all AUR users about the transition in a couple of days. Regards, Lukas
Re: [aur-general] Unable to recover my password
On Sun, 17 May 2015 at 10:40:44, Manuel Reimer wrote: [...] I've disabled everything, that has something to do with filtering, now. Still no success. Is it a big deal to configure the envelope sender? There are 400 AUR users with GMX email addresses. One of them just registered yesterday, so I suspect it is a problem with your local MTA/MDA configuration rather than a GMX issue. Did you already check whether the email appears in the GMX web interface (before retrieving emails via POP3, of course)? Manuel Regards, Lukas
Re: [aur-general] Unable to recover my password
On Sun, 17 May 2015 at 10:55:30, Manuel Reimer wrote: [...] Yes. No mail on the GMX web interface. Is there maybe some minor typo in the mail address in your database? Maybe a space character at the end or beginning? The email address used with the AUR account exactly matches the one you used to send this email. As Evangelos already said, the emails are accepted by the GMX mail server. If they don't appear on the web interface, they are somehow discarded by GMX.
Re: [aur-general] Unable to recover my password
On Sun, 17 May 2015 at 11:05:56, Lukas Fleischer wrote: On Sun, 17 May 2015 at 10:55:30, Manuel Reimer wrote: [...] Yes. No mail on the GMX web interface. Is there maybe some minor typo in the mail address in your database? Maybe a space character at the end or beginning? The email address used with the AUR account exactly matches the one you used to send this email. As Evangelos already said, the emails are accepted by the GMX mail server. If they don't appear on the web interface, they are somehow discarded by GMX. I just tried to create a fresh AUR account using a GMX email address and successfully received a password reset email within 10 seconds. Please double-check your GMX configuration and/or contact the GMX staff.
Re: [aur-general] Unable to recover my password
On Sun, 17 May 2015 at 11:14:43, Manuel Reimer wrote: [...] I was able to register. I received the initial password reset mail and I was able to finish registration. BUT: I'm unable to request password reset with this test account, too. So maybe the interesting question is: Is there *any* difference between the mail, you send on account creation and on password reset? [...] Interesting. Could you please try once again?
Re: [aur-general] Unable to recover my password
On Sun, 17 May 2015 at 11:38:48, Manuel Reimer wrote: On 05/17/2015 11:36 AM, Lukas Fleischer wrote: On Sun, 17 May 2015 at 11:14:43, Manuel Reimer wrote: [...] I was able to register. I received the initial password reset mail and I was able to finish registration. BUT: I'm unable to request password reset with this test account, too. So maybe the interesting question is: Is there *any* difference between the mail, you send on account creation and on password reset? [...] Interesting. Could you please try once again? Worked. Whatever you changed: It did the trick! [...] Check [1]. Due to a regression introduced in March 2013 (!), password reset emails only contained a link. My guess is that GMX considers such emails spam and silently drops them. [1] https://lists.archlinux.org/pipermail/aur-dev/2015-May/003125.html
Re: [aur-general] oxygen-gtk3 not found
On Mon, 30 Mar 2015 at 11:18:59, Bernard Baeyens wrote: oxygen-gtk3 cannot be found in AUR although there is a PKGBUILD at: https://aur.archlinux.org/packages/ox/oxygen-gtk3/PKGBUILD This PKGBUILD is for oxygen-gtk3 1.0.0-1 but the last version in Extra was 1.4.1-1 So is this package orphan in AUR? Why has it disappeared? It was dropped from [extra] because it is not compatible with GTK 3.16, see [1]. As you said, it has not been uploaded to the AUR. The link to the PKGBUILD is a backup we keep when removing packages from the AUR; it is a snapshot of the version we had before the packages was moved to the official repositories. [1] https://projects.archlinux.org/svntogit/packages.git/commit/?id=ca85357
Re: [aur-general] AUR account cleanup 2015
On Thu, 05 Feb 2015 at 19:34:38, Tai-Lin Chu wrote: Good news. Where can I find out more about this aurweb 4.0.0? [...] The email I sent to this list ~2 months ago [1] might be a good starting point. If you are curious about what the transition period will look like, check [2]. [1] https://lists.archlinux.org/pipermail/aur-general/2014-December/029990.html [2] https://lists.archlinux.org/pipermail/aur-general/2014-December/029992.html
Re: [aur-general] AUR account cleanup 2015
On Thu, 05 Feb 2015 at 17:55:27, Tai-Lin Chu wrote: I hope we can have another purge for dead(both orphaned and inactive) packages. [...] The AUR will be recreated from scratch (with zero packages) when aurweb 4.0.0 will be released, so there's no need for such a cleanup now.
Re: [aur-general] AUR account cleanup 2015
On Wed, 04 Feb 2015 at 08:59:41, Florian Bruhin wrote: [...] Is there a list of packages which will be orphaned because of this somewhere? [...] I uploaded a list here [1]. Regards, Lukas [1] http://sprunge.us/CLJf
Re: [aur-general] Forgot AUR Username
On Wed, 04 Feb 2015 at 06:00:18, Zac Audette wrote: I made my AUR account around a year ago. I moved off arch for a period of time and have forgotten my username/password to the AUR account linked to this email. I requested the password for my AUR account via email from the AUR password recovery page but have yet to receive an email. Of course the password won't be of much use since I have forgotten my username. Can someone provide me a link or instructions to obtain my username? Or perhaps can I simply make a new user under the same email? There is no AUR account associated with the email address you used here. Did you use another address by any chance? If you did not log in for a very long time (say, more than ~2.5 years), your account might have been removed during the last account cleanup. In that case, feel free to create a fresh account with the same email address. Thanks, Zac
[aur-general] AUR account cleanup 2015
Hi, Here is a list of ~12000 inactive AUR accounts [1] that I am going to purge soon. I noticed the list includes a fair amount of spam accounts this time but just in case your user name appears on that list and you want to keep it, please re-login within the next couple of days. For more details on the process, please read last year's account cleanup thread [2]. Regards, Lukas [1] http://sprunge.us/hjbT [2] https://lists.archlinux.org/pipermail/aur-general/2014-January/027030.html
Re: [aur-general] Packaging releases from git.kernel.org
On Fri, 30 Jan 2015 at 16:50:13, Troy Engel wrote:
I struggled a bit to package a tagged stable release from
git.kernel.org to complement the -git package, finally figured out a
method that's simple[1] but hidden from the cgit webUI; wanted to add
to the wiki as a FAQ/tip for others. Would this be the right page?
https://wiki.archlinux.org/index.php/Arch_User_Repository
I don't think so. A quick search didn't bring up a page that contains
general packaging tips and I am not sure whether it is worthwhile to add
such a page including tips similar to what you suggested. It might
become cluttered with dozens of tips soon. Opinions?
By the way, is there any reason for not using Git tags to specify the
snapshot tarball? Something along the lines of
source=(http://git.kernel.org/cgit/linux/kernel/git/rostedt/trace-cmd.git/snapshot/trace-cmd-v${pkgver}.tar.gz;)
Otherwise, you need to look up the commit on every pkgver bump.
If not, better idea where to share the method? Not finding anything
that looks right from the category page
https://wiki.archlinux.org/index.php/Category:Package_development
dedicated to git/svn build tips for AUR... ?
-te
[1] https://aur.archlinux.org/packages/tr/trace-cmd/PKGBUILD
Re: [aur-general] Packaging releases from git.kernel.org
On Fri, 30 Jan 2015 at 16:50:13, Troy Engel wrote: I struggled a bit to package a tagged stable release from git.kernel.org to complement the -git package, finally figured out a method that's simple[1] but hidden from the cgit webUI; wanted to add to the wiki as a FAQ/tip for others. Would this be the right page? https://wiki.archlinux.org/index.php/Arch_User_Repository If not, better idea where to share the method? Not finding anything that looks right from the category page https://wiki.archlinux.org/index.php/Category:Package_development dedicated to git/svn build tips for AUR... ? -te [1] https://aur.archlinux.org/packages/tr/trace-cmd/PKGBUILD
Re: [aur-general] Can't update my own PKGBUILD, where to find errors?
On Fri, 23 Jan 2015 at 12:34:40, LoneVVolf wrote:
On 23-01-15 00:23, Lukas Fleischer wrote:
Let me elaborate just a bit: There currently isn't a bcusdk package
base in the AUR, so a new package base is created upon package
submission. That new package base contains a package eibd which is
already part of the package base eibd, though. Since a package base
cannot contain a package that is already provided by another one, you
receive that strange error message. Hope that clarifies it a bit.
Regards, Lukas
The situation is weirder then that, check the PKGBUILD for the current
version :
pkgbase=('bcusdk')
pkgname=('eibd')
pkgver=0.0.5
pkgrel=4
Maybe the problems are caused by uploading a faulty .AURINFO or .SRCINFO
file in the past.
No, the package was last updated on 2014-03-04 20:25 which was before
the AUR supported split packages. During the migration, we automatically
assigned the package base eibd.
Sven, if you do want pkgbase bcusdk and pkgname eidb,
i suggest you upload a dummy bcusdk pacakge, then request eidb to be
merged into bcusdk.
... where dummy bcusdk pacakge means: Use the package base bcusdk
without any additional packages.
Once the merge has completed, you can then upload the correct package.
Agreed.
LVV
Regards,
Lukas
Re: [aur-general] Can't update my own PKGBUILD, where to find errors?
On Fri, 23 Jan 2015 at 00:02:02, Doug Newgard wrote: On Thu, 22 Jan 2015 23:24:24 +0100 Sven Fischer s...@leiderfischer.de wrote: Hello everybody, trying to update small fixes to the eibd package, AUR upload always responses to me with error: failed to upload bcusdk-0.0.5-5.src.tar.gz: You are not allowed to overwrite the eibd package., although I own the package. I am quite a AUR NOOB, but trying to find a hint what could be wrong led me to nothing. Wouldn't it be possible to respond with an error that tells me WHY I am unable to upload (missing permission, wrong version etc)? Regards, Sven Because you're trying to overwrite one pkgbase (eibd) with a different one (bcusdk). Let me elaborate just a bit: There currently isn't a bcusdk package base in the AUR, so a new package base is created upon package submission. That new package base contains a package eibd which is already part of the package base eibd, though. Since a package base cannot contain a package that is already provided by another one, you receive that strange error message. Hope that clarifies it a bit. Regards, Lukas
Re: [aur-general] AUR UTF-8 support?
On Wed, 21 Jan 2015 at 18:05:17, Bartłomiej Piotrowski wrote: On Wed, 21 Jan 2015 12:41:53 -0300 Hugo Osvaldo Barrera h...@barrera.io wrote: Hi, I posted a message ending with the character on the AUR today, but that character got stripped. Does AUR not have UTF-8 support? Have I bumped into a new issue? Thanks, How is that an issue? Do you really think there is a sane project with such character in its name? Do you expect users to search charactar map to install your package? I think he is talking about comments. Issues like this should be discussed on the bug tracker (and maybe on aur-dev), though.
Re: [aur-general] AUR 4.0 and existing git repositories
On Sat, 17 Jan 2015 at 17:03:45, Hugo Osvaldo Barrera wrote: Hi, I've been reading about the upcoming AUR 4.0 with git repositories for each package (which is very much welcome for a variety of reasons!). I'm curious how existing packages will be handled. I already keep git repos for my packages, so it would be nice to be able to import those directly for two reasons: * To share the existing history with everyone else. * If packages are imported as-are into new repositories, then I can't push the existing repos. I'll need to create clone the AUR-generated ones, and work on those, loosing all my history. Has this sort of scenario been given any thought? [...] Yes, please check [1]. [1] https://lists.archlinux.org/pipermail/aur-dev/2014-December/003014.html
Re: [aur-general] Cannot push to aur-dev, was: Re: [aur-dev] AUR 4.0.0 pre-alpha
On Tue, 30 Dec 2014 at 01:50:55, Pablo Lezaeta Reyes wrote: 2014-12-29 21:30 GMT-03:00 SpinFlo sl1pk...@gmail.com: for me need this after clone repository 'git add *' - to add/update files to repo 'git commit -m 'message'' - to add the commit to repo and then push the changes There is a way to preven malicious userd that efectively create and acount and do al the stuf to only pload malware like a PKGBUILD, .SRCPKG and 1G patch x 10 or a giantic commit -sm like copy pasting an entire book?? Yes, we already reject huge files. -- *Pablo Lezaeta*
Re: [aur-general] AUR 4.0.0 pre-alpha
On Tue, 30 Dec 2014 at 02:34:14, Johannes Löthberg wrote: On 29/12, Lukas Fleischer wrote: AUR package maintainers are then asked to upload their packages to aur-dev.archlinux.org and co-maintain them on aur.archlinux.org and the Git repository on aur-dev.archlinux.org for some time (roughly four weeks). Speaking of co-maintainership, any thoughts having multiple users being able to maintain the same package? [...] Yes, that is a feature that will definitely be added before 4.0.0 will be released.
Re: [aur-general] AUR 4.0.0 pre-alpha
On Tue, 30 Dec 2014 at 05:39:28, Ido Rosen wrote: Posted in other thread, but: The AUR4 update hook compares an str to an int when looking at the pkginfo['epoch'], so packages with an epoch set fail to pass the update hook. Probably should check that the string pkginfo['epoch'] contains only numbers, then do an int(pkginfo['epoch']) in the comparison line there... line 45 of save_srcinfo. [...] Fixed. Thanks for reporting!
Re: [aur-general] Cannot push to aur-dev, was: Re: [aur-dev] AUR 4.0.0 pre-alpha
On Tue, 30 Dec 2014 at 12:19:35, Marcel Korpel wrote: * Johannes Löthberg johan...@kyriasis.com (Tue, 30 Dec 2014 01:22:24 +0100): You need to actually specify the remote too, named origin by default when you clone a repo, so `git push origin master` Now it works. Strange, as with other repositories `git push` just works, as 'origin' is the default. `git push` should work. `git push master` does not work, though, because you cannot specify a refspec without specifying a remote repository. Regards, Marcel
Re: [aur-general] Arch Linux Trusted User application Christian Hesse
On Tue, 30 Dec 2014 at 12:17:06, Christian Hesse wrote: Hello Arch Linux community, [...] My main focus is on system administration, but I do have an attitude to programming. A number of open source projects includes changes by me, some just being bug fixes, some introducing new features. I do not want to bore you, so I will not list them here. [...] While listing every single project you contributed to might be boring, knowing that you are willing to contribute to upstream projects is an important point. I came across Christian's name on a lot of Open Source projects I am following; he contributed to archiso, cgit, OpenSSH, pacman and zsh. He submitted patches to Git to make the test suite pass with GnuPG 2.1 and we currently use those patches in our git package. I think he is knowledgeable and would be a good addition to our team. Christian, glad to see you apply!
Re: [aur-general] AUR 4.0.0 pre-alpha
On Tue, 30 Dec 2014 at 15:46:18, SpinFlo wrote: Hi Howto remove a own repo (only make setup) if created with bad name? Don't worry about it now -- I don't care about orphan packages in a testing environment. When AUR 4.0.0 goes live, you can file a package deletion request to delete a package. The Git repositories of deleted packages (and empty repositories that haven't had any commits for a long time) will be wiped periodically. greetings
[aur-general] AUR 3.5.1 released
Hello, I am pleased to announce that AUR 3.5.1 has been released. The official AUR setup [1] has already been updated. Apart from several bug fixes, this release deprecates mkaurball. We now recommend to use `makepkg --source` from pacman 4.2.0. For a comprehensive list of changes, please consult the Git log [2]. As usual, bugs should be reported to the AUR bug tracker [3]. [1] https://aur.archlinux.org/ [2] https://projects.archlinux.org/aur.git/log/?id=v3.5.1 [3] https://bugs.archlinux.org/index.php?project=2
[aur-general] AUR 4.0.0 pre-alpha
The 4.0.0 release brings Git repositories to AUR packages. You can test a pre-alpha version at aur-dev.archlinux.org [1]. In order to submit packages, you can follow these steps: 1. Create a new SSH key pair for the AUR. While this step is not strictly necessary (you can use any existing SSH key), it is recommended to do this: $ ssh-keygen -f ~/.ssh/id_rsa-aur 2. Log into the AUR web interface at [1], go to My Account and copy the content of ~/.ssh/id_rsa-aur.pub (or any other key you want to use) into the SSH Public Key field. Click Update to save the key. 3. The SSH daemon for the AUR uses a custom user and a custom port. It is recommended to add the following lines to your ~/.ssh/config so you don't need to specify user and port each time you connect to the AUR SSH interface: Host aur-dev.archlinux.org IdentityFile ~/.ssh/id_rsa-aur User aur Port 4. To create a new (empty) package base foobar, run the following command: $ ssh aur-dev.archlinux.org setup-repo foobar 5. If you want to submit changes to a package base, you need to clone the package repository via SSH: $ git clone ssh+git://aur-dev.archlinux.org/foobar.git/ When making changes to the repository, make sure you always include the PKGBUILD and .SRCINFO in the top-level directory. You can submit new versions of a package base to the AUR by committing the new PKGBUILD and .SRCINFO and running `git push`. If you spot any major flaws or have suggestions for the new interface, please let me know. Regards, Lukas [1] https://aur-dev.archlinux.org/
Re: [aur-general] AUR 4.0.0 pre-alpha
On Mon, 29 Dec 2014 at 22:16:45, Ido Rosen wrote: Will all existing AUR packages automatically get their own git repositories or will we have to resubmit all packages? [...] Both. The current plan is as follows: A couple of weeks before the official release of 4.0.0, I will reset the setup on aur-dev.archlinux.org and create an empty Git repository for each package that exists in the AUR at that moment. The package maintainer will be retained so that nobody can take over anybody else's package. AUR package maintainers are then asked to upload their packages to aur-dev.archlinux.org and co-maintain them on aur.archlinux.org and the Git repository on aur-dev.archlinux.org for some time (roughly four weeks). Users who have already been using Git for their AUR packages can add .SRCINFO to all commits and import the whole history. At some point in time, I am going to remove all package bases that have not been uploaded to aur-dev.archlinux.org and move everything from aur-dev.archlinux.org to aur.archlinux.org. It is a huge AUR cleanup.
Re: [aur-general] AUR 4.0.0 pre-alpha
On Mon, 29 Dec 2014 at 22:52:18, Νῖκος Θεοδώρου wrote: On Mon, 29 Dec 2014 22:28:04 +0100 Lukas Fleischer archli...@cryptocrack.de wrote: It is a huge AUR cleanup. Which means we should start saving PKGBUILDS of the dependences of our packages too, in case they don't make it, so we can reupload them… [...] Just to clarify: There will be an archive of PKGBUILDs from the old AUR. You can always recover packages if the maintainer doesn't upload them within the four weeks.
Re: [aur-general] AUR 4.0.0 pre-alpha
On Mon, 29 Dec 2014 at 23:26:38, wrote: On Mon, Dec 29, 2014 at 10:01:45PM +0100, Lukas Fleischer wrote: If you spot any major flaws or have suggestions for the new interface, please let me know. I see that the submit button has been removed since uploads are now handled through git. Perhaps a Create Package button could be added in its place, which creates an empty repository and gives instructions on how to upload to it. You can create an empty repository via SSH: $ ssh aur-dev.archlinux.org setup-repo foobar I agree that it is a good idea to add instructions on how to submit packages, though. Anyway, I liked the idea of using git for AUR packages when I first saw that someone had suggested it, and I'm glad its finally coming.
Re: [aur-general] AUR 4.0.0 pre-alpha
Hello Pablo, On Tue, 30 Dec 2014 at 00:01:05, Pablo Lezaeta Reyes wrote: But if someone missed the deadline (something that I'm sure will happend for a few hundeds at least either because lazines, bussyness or not want (or can't) reach aur-dev page) there are a place to take the PKGBUILD that was deleted in the lets break AUR cleanup? As I already mentioned in a reply to Νῖκος, it is possible to recover PKGBUILDs that have been deleted from an archive. Also translations need to be pulled, the last time the translation weren't taken from transfex (as I can noticed) and viceversa, so why not let the submit button there but intead add the instructions on how now upload packages to aur. [...] Are you talking about 3.5.1 or 4.0.0? The setup on aur-dev.archlinux.org is a pre-alpha release and thus, there aren't any translations yet.
Re: [aur-general] AUR 4.0.0 pre-alpha
On Tue, 30 Dec 2014 at 00:12:06, SpinFlo wrote: mmm fails for me refuses upload because remote: error: missing .SRCINFO but that file is include in the root of the repository i missing steps? I use: - git clone ssh+git://aur-dev.archlinux.org/foobar.git/ (change foobar with the package name) - add PKGBUILD. SRCINFO and other files include in the sources array Just to clarify: The file is called .SRCINFO (note the leading dot). If it still fails, could you please push to another public repository and send me a link in a private email so I can investigate the issue? - git add . - git commit -m 'brawbraw' - git push [...]
Re: [aur-general] AUR 4.0.0 pre-alpha
On Tue, 30 Dec 2014 at 00:22:53, David Phillips wrote: I'd like to chime in. I'm in the same boat as SpinFlo. Only thing I did differently is add PKGBUILD in one commit, attempt to push, then added .SRCINFO in another commit. [...] Oh, every commit needs to refer to a tree object that contains a .SRCINFO file. The idea is that every commit corresponds to a revision of the package and must provide meta data for that revision. You can use `git commit --amend` or `git rebase -i` if you forgot to add meta data to any local commit. I am open for suggestions on how to improve this.
[aur-general] AUR 3.5.0 released
Hello, I am pleased to announce that AUR 3.5.0 has been released. The official AUR setup [1] has already been updated. This release adds support for architecture-specific sources (resp. provides, conflicts, replaces) and for .SRCINFO, both of which will be included in the next pacman release. Apart from that, the package list and package base list are now official and available at [2, 3]. There have also been a couple of internal changes and bug fixes. For a comprehensive list of changes, please consult the Git log [4]. As usual, bugs should be reported to the AUR bug tracker [5]. [1] https://aur.archlinux.org/ [2] https://aur.archlinux.org/packages.gz [3] https://aur.archlinux.org/pkgbase.gz [4] https://projects.archlinux.org/aur.git/log/?id=v3.5.0 [5] https://bugs.archlinux.org/index.php?project=2
Re: [aur-general] Regex on search page
On Wed, 05 Nov 2014 at 01:05:48, Ian D. Scott wrote:
On Wed, Nov 05, 2014 at 12:38:24AM +0100, Ralf Mardorf wrote:
Assumed somebody can recommend a good helper to search the AUR, I'm
willing to test it.
I don't know if any AUR helpers support this, but you can just get a
list of all AUR packages with this command and then pipe to grep to
match by regex.
curl http://cryptocrack.de/files/aurpkglist.txt.gz | zcat | awk
'NR1{gsub(%2B,+);print $1}'
This is superseded by the official [1] package list.
[1] https://aur.archlinux.org/packages.gz
Re: [aur-general] Unannounced and unreasonable deletion of python2-vdirsyncer
On Mon, 29 Sep 2014 at 13:57:07, Markus Unterwaditzer wrote: Hello everybody, Today i was notified by the AUR system that somebody called arcanis silently merged the package python2-vdirsyncer into vdirsyncer, leaving other packages with missing dependencies. Vdirsyncer runs under both Python 2 and 3. It can be used as a library, but is more commonly used as a CLI tool. The Python 2 version was required by khal-git, as Khal doesn't work under Python 3. The Python 3 version still resides under the package name vdirsyncer and is there for the sake of completeness, and because Python 3 is technically the most up-to-date version of Python. It can be used independently of khal. khal-git: https://aur.archlinux.org/packages/khal-git/ vdirsyncer: https://aur.archlinux.org/packages/vdirsyncer/ I also couldn't find a mailinglist about this, therefore i assume this is a mistake. Please restore the package python2-vdirsyncer. The mailing list is aur-requests, see [1]. Packages cannot be restored after merging. Packages can be resubmitted at any time, though. You may want to consider renaming it to python-vdirsyncer before doing so. Thanks, Markus [1] https://lists.archlinux.org/pipermail/aur-requests/2014-September/001819.html
Re: [aur-general] Requests
On Mon, 15 Sep 2014 at 00:25:41, Justin Dray wrote: Hi everyone, I think it would be a good idea to link to the package for a request when it has been fulfilled. The messages do not show up in the same thread and there is no link, just 'request #1234 accepted' and which TU has accepted it. I then have to go and search for that number to find out what the request was for. Thoughts? Good idea [1]. Regards, Justin Dray E: jus...@dray.be M: 0433348284 [1] https://bugs.archlinux.org/task/41607
Re: [aur-general] Uploads when it's not necessary
On Thu, 11 Sep 2014 at 13:23:24, Lex Black wrote: Currently there is one package that gets uploaded every minute (and most likely without changes). An automated process that went out of control? Or is such a setup ok? I temporarily suspended Ruslan82's account. Thanks for reporting. Sergei, please get in touch when you fixed that issue. Best regards Lex [1] https://paste.archlinux.de/jcFs/ [2] https://paste.archlinux.de/eKoM9/ [3] https://paste.archlinux.de/VcJXU/
Re: [aur-general] Forgot AUR username
On Wed, 20 Aug 2014 at 18:49:53, Bruno Saraiva wrote: I did already reset my password, AND I thought I knew the right username. Even tried different ones in hopes of hitting the right one before bothering you guys with this. Could you be so kind to send me my username, attached to this email account? Replied off-list. Thanks and have a nice one, -- Bruno Saraiva
Re: [aur-general] AUR request mentality
On Sun, 17 Aug 2014 at 08:47:40, carstene1ns wrote: While the new AUR request functionality is a good thing and widely accepted (over 500 requests yet), it also brings us some problems: (1)inhibition threshold - It is much easier to remove a package now. (2)response time - Requests get accepted before the package maintainer or others have time to explain or react. There may be other problems, but these two bugged me since it was implemented. ## For the tl;dr version, please skip the following remarks. ## [...] tl;dr: What can we do to make things better? Should we (re)write the policy for TUs about accepting AUR requests? They should at least investigate. I think a good start would be to have users provide real reasons for deleting a package and trying to fix them otherwise (themselves or with help from the maintainer). Policies are important but I think it is at least as important to have a user interface that makes it easy (natural) to comply with them. Let me give an example for that: When the package request interface was introduced, all orphan requests were accepted before the expiration of the grace period, even though our package request guidelines were still the same. Why? The new user interface makes it much easier to go through the list and accept requests, while checking whether the request is older than two weeks was just as hard as it had been before. In a minor release, I added a feature that locks new orphan requests for 14 days and now, accepting a locked request is much more work than accepting an unlocked request (requires 4 clicks instead of 1 click). It looks like that worked out pretty well. What I suggest is to introduce such a locking mechanism for deletion requests as well. One might argue that deletion requests are often uncontroversial (upstream has been dead for 3 years, sources are gone, there is no fork) but then again, it doesn't really matter whether the broken package stays in the AUR for another 14 days. It might be a good idea to skip (or shorten) the grace period if the request is filed by the current package maintainer, though. Another point is that a lot of Trusted Users unfortunately don't seem to follow the aur-requests mailing list. And the package request interface is not linked to the mailing list in any way. So, while it is technically more difficult than the simple locking idea, it may also be desirable to have the AUR check the mailing list (or the mailing list archives) and mark a request if there is any discussion, preferably with a link to the archives. best regards, carstene1ns
Re: [aur-general] AUR request mentality
On Sun, 17 Aug 2014 at 14:35:21, LoneVVolf wrote: Perhaps we could treat the aur-requests more like a bug tracker ? a possible flow : request is filed and gets unassigned status TUs review unassigned requests If they feel they are right person to handle it, they assign it to themselves. request status changes to assigned, and the TU is now responsible for handling the request. If they are not, they leave the request unassigned, maybe post something why they are not qualified. Fixing a bug can take a lot of time and might require someone with special knowledge. Accepting a package request literally takes a couple of seconds (read the reason, double-check whether it is valid, click a link) and every Trusted User should be able to decide whether a request is valid or not. If a request is controversial, a TU should sent a short email to the mailing list and the request should be marked in the request list (can be done automatically). Any additional administrative burden is counterproductive. Once a request has assigned status, policy rules for such a type of request are added to the request. Only the assigned TU can accept or deny a request.
Re: [aur-general] AUR request mentality
On Sun, 17 Aug 2014 at 14:43:13, Yamakaky wrote: In fact, AUR misses git and a bug tracker per package. Now, package improvements suggestions need to be written in the comments, it's not very efficient. Another problem : often I see packages where the last comment reports a problem already fixed, because the maintainer didn't replied. A bug tracker would improve the process. These things are already being worked on. However, this is completely off-topic, so let's not discuss it here.
Re: [aur-general] AUR GIT and Bug Tracker
On Sun, 17 Aug 2014 at 17:50:54, Ido Rosen wrote: [...] Seeing the discussion about using info/alternates to store git objects for all repos in one place, it sounds a lot like they're reinventing the wheel... Git integration would be fantastic, but I'd strongly suggest that AUR devs not reinvent the wheel - let GitHub or BitBucket or Gitorious, etc. do the Git hosting for you, and do actions based on web-hooks[1], which most git hosts support. It is not only about parsing package data. We need a centralized place where people can submit and discuss packages. That centralized place must allow for easily changing the maintainer (disown/adopt) and we (the Trusted Users) need full control (permissions to delete, merge, remove comments, ...) of every repository. A first idea was to using existing services for hosting but then there are only two options: * Statically connect each AUR package to a repository that is hosted somewhere else. Means we do not have full control over the repositories since we do not host them and we cannot simply switch to another repository if the maintainer becomes inactive/irresponsible. * Dynamically connect each AUR package to a repository, so that it is easy to switch to a new repository if someone maintains a fork of the same package somewhere. Means we are going to lose all comments, bug tickets, ... So we cannot use any features the Git hosting services provide, apart from hosting the repositories themselves which is trivial (apart from authentication stuff that has already been implemented, though). As a byproduct of setting up our own SSH/Git infrastructure, you will also be able to perform several basic AUR operations (create a new package, adopt a package, ...) via the command line which is a nice feature on its own. You can still collaborate using a decentralized work flow, put your stuff on GitHub, let people issue pull requests etc. but the main repositories will be hosted on aur.archlinux.org. [1] https://developer.github.com/webhooks/ PS: I already maintain all of my PKGBUILDs in one git repository on GitHub (https://github.com/ido/packages-archlinux). If the git integration supports GitHub (or even if not), I would then switch to adding each of the packages as git submodules to my master project (which would include a vagrantfile and my build environment)...making my package build environment reproducible for any other packagers/AUR users.
Re: [aur-general] AUR GIT and Bug Tracker
On Sun, 17 Aug 2014 at 23:56:25, Ido Rosen wrote: On Sun, Aug 17, 2014 at 12:31 PM, Lukas Fleischer archli...@cryptocrack.de wrote: [...] * Dynamically connect each AUR package to a repository, so that it is easy to switch to a new repository if someone maintains a fork of the same package somewhere. Means we are going to lose all comments, bug tickets, ... Why would you lose all comments/bugs/tickets? Why do those have to be in the same repository as the packages themselves? Huh? Why would you want to put them in different repositories? The point of having issue trackers per repository is that * bugs are automatically assigned to the right person, * bugs can be closed automatically when a fix is committed, * you can reference commits and files, * there is no need to filter by project (as in a global tracker). A separate tracker would be very hard to maintain. Tickets need to be assigned, permissions need to be kept in sync with the current repository owner, ... [...] I don't personally mind if I end up using GitHub or some other Git hosting like AUR's homegrown solution - the interface is the same to me for the most part. I was just suggesting that you use existing ones because you will probably encounter the same issues existing ones have on the backend and it may be a waste of resources to create yet another git hosting service...even a special-purpose one. Note that the basic functionality is implemented already. In 500 lines of Python code, so this isn't too hard. One reason is that we do not have support for any of the fancy extra features right now (pull requests, forks, bug trackers, ...) [...] PS: I already maintain all of my PKGBUILDs in one git repository on GitHub (https://github.com/ido/packages-archlinux). If the git integration supports GitHub (or even if not), I would then switch to adding each of the packages as git submodules to my master project (which would include a vagrantfile and my build environment)...making my package build environment reproducible for any other packagers/AUR users. Think about workflows when designing this thing. I hope there is documentation centered around packaging workflows when you release the new features, the use case I'm especially interested in is to be able to submodule/subtree whatever packages I want from AUR into a new ArchLinux-based sub-distro and build them all... Also, it'd be very nice if the interface were the same for ABS/packages.git as it were for AUR, for example, you could consider ABS a subset of AUR... This line of discussion is probably worth a separate thread, and I'm not sure which the best mailing list to discuss it would be. I do not want to recommend any specific workflow. Git gives you a lot of flexibility when it comes to your workflow and I want to keep that flexibility. Of course, there will be basic instructions and tools for newcomers. If you want to use submodules, use submodules. The interface isn't different from the interface to any other Git repository. You can use `git clone`, `git pull`, `git push` and every official Git command to interact with remotes.
Re: [aur-general] AUR GIT and Bug Tracker
On Mon, 18 Aug 2014 at 00:21:41, Ido Rosen wrote: On Sun, Aug 17, 2014 at 6:09 PM, Johannes Löthberg johan...@kyriasis.com wrote: On 17/08, Ido Rosen wrote: On Sun, Aug 17, 2014 at 12:31 PM, Lukas Fleischer archli...@cryptocrack.de wrote: * Dynamically connect each AUR package to a repository, so that it is easy to switch to a new repository if someone maintains a fork of the same package somewhere. Means we are going to lose all comments, bug tickets, ... Why would you lose all comments/bugs/tickets? Why do those have to be in the same repository as the packages themselves? Because then we'd either need two repos per package or one repo that had the bug reports of all the AUR packages, both would be rather bad solutions. Why would comments and bugs need to be managed in Git to begin with? GitHub and other services do sometimes have a handy issues.git repository (e.g. I can clone http://github.com/ido/packages-archlinux.issues.git ), but I don't think the backing store is Git in those cases...? Having a Git interface to that data is handy but does imply having a separate git repo. Using Git as a backing store for comments/bugs might be inelegant/not very KISS. Also, to delete a comment in the comment history if it's maintained in Git would you resort to a non-fast-forward update? Don't interpret my questions as discouragement, just seems like using Git for *everything* is a bit myopic. I never suggested to manage comments or bugs in Git. However, when using a service like GitHub, repositories and tickets are coupled together. If we do not want to make use of GitHub's issue tracker (and pull requests and all the other features) we do not gain anything. You suggested to search for an existing service in order to not reinvent the wheel. What is the point of using such a service if we do not use the wheel at all? -- Sincerely, Johannes Löthberg PGP Key ID: 3A9D0BB5
Re: [aur-general] replacing packages with split packages: how to merge?
On Sat, 16 Aug 2014 at 20:00:48, Xyne wrote: [...] At first I thought that the pkgbase could be uploaded without anything in the pkgnames array as a placeholder for merging, but that would lump all the votes into the pkgbase and not the individual packages. Am I missing something? Votes are always only stored per package base. You cannot vote on a package. Note that it is also possible to merge two packages into another package without having a transition period where the original packages are unavailable [1]. If not then it seems that we need some sort of pending merge queue. Thoughts? Regards, Xyne [1] https://mailman.archlinux.org/pipermail/aur-general/2014-June/028631.html
Re: [aur-general] replacing packages with split packages: how to merge?
On Sat, 16 Aug 2014 at 20:35:10, Xyne wrote:
[...]
Votes are always only stored per package base. You cannot vote on a
package.
Note that it is also possible to merge two packages into another package
without having a transition period where the original packages are
unavailable [1].
[1] https://mailman.archlinux.org/pipermail/aur-general/2014-June/028631.html
According to your reply in another thread [1] there is currently no name
collision between pkgname and pkgbase so I don't understand how that works. If
you change the pkgname to the pkgbase and append -old to the pkgname then it
will be uploaded as a new, separate package/package base with 0 votes, no?
Wouldn't the overall procedure then be:
1) upload all existing packages with pkgbase=$pkgname,
pkgname=(${pkgname}-old)
2) merge old packages into new pkgbase variants
The package base name defaults to the name of the first package, so
uploading with pkgbase=$pkgname, pkgname=(${pkgname}-old) does
automatically merge the old packages into the new pkgbase variants (to
be more specific: the package base stays the same, so votes and comments
are retained, but the packages belonging to that package base change).
3) upload new split package (assuming no pkgbase name collision)
4) merge all placeholder pkgbases
?
[1] https://mailman.archlinux.org/pipermail/aur-dev/2014-August/002934.html
Re: [aur-general] [arch-dev-public] Voting results (was: Inactive TU -- Federico Cinelli)
On Tue, 05 Aug 2014 at 15:05:16, Lukas Fleischer wrote: On Sat, 02 Aug 2014 at 12:44:53, Lukas Fleischer wrote: [...] Let the discussion period begin, the voting period will start on 2014-08-05. [...] The discussion period is over. Please cast your votes [1]. Results: * Yes: 24 * No: 3 * Abstain: 3 In the meantime, I had the chance to talk to Federico and it turned out that he has been MIA due to health reasons. Unfortunately, this was when the voting period had already started. So, Federico, I hope you will get well soon! If you want to regain your TU status, simply write a very short application email to aur-general with a brief explanation of what happened (no details, simply refer to your original application and this thread) and I am sure it will be accepted. [1] https://aur.archlinux.org/tu/?id=76
Re: [aur-general] Discussion about AUR packages signing
On Fri, 08 Aug 2014 at 10:02:30, Daniel Micay wrote: On 08/08/14 03:43 AM, Ralf Mardorf wrote: In the past, what packages provided by AUR needed signing, because after uploading somebody manipulated the packages? AFAIK https for the AUR downloads and checksums for the upstream downloads in the past didn't cause that often serious trouble, IIRC it usually was safe. Is there such a security mechanism, if we build from ABS? The AUR has had SQL injection vulnerabilities in the past. It has also had a fair number of CSRF / XSS vulnerabilities allowing actions to be taken on behalf of package maintainers. Yes, I do remember fixing one SQL injection vulnerability and a couple of CSRF/XSS vulnerabilities. However, if I recall correctly, all of them were discovered during code reviews and I cannot remember any vulnerability that affected aur.archlinux.org (i.e. was exploited). It's being well maintained now, but it's still written in a language with many easy ways to shoot yourself in the foot. AFAIK (too lazy to check) it also doesn't have a captcha or similar mechanism to defend against someone brute forcing the password of a specific user. Assuming that everyone uses good passwords (suppose the set of good passwords has 10^14 elements which is a good lower bound), an attacker doing a request every 10ms still has to wait thousands of years on average. It is likely that we detect the increased server load way earlier. Even if we don't, it is unlikely that the owner of the AUR account still cares about his account in a thousand years time. The checksums are just blindly updated when either a new release is done or upstream decides to fiddle with the last release. The ideal is having a signed package (either binary or source) with signatures for the upstream sources and the new makepkg feature allowing the correct fingerprint to be added in the PKGBUILD. On a side note, with the release of AUR 4.0.0, we are no longer going to use source tarballs. Every source package will have its own Git repository and you can use signed tags or signed commits. So I think it is kind of pointless to discuss signed source tarballs now...
Re: [aur-general] Inactive TU -- Federico Cinelli
On Sat, 02 Aug 2014 at 12:44:53, Lukas Fleischer wrote: [...] Let the discussion period begin, the voting period will start on 2014-08-05. [...] The discussion period is over. Please cast your votes [1]. [1] https://aur.archlinux.org/tu/?id=76
[aur-general] Inactive TU -- Federico Cinelli
Hi, since it was mentioned on IRC: It looks like Federico Cinelli is inactive and should be brought up for special removal according to [1]. We usually try not to be overly pedantic with these rules, but Federico has been MIA for a long time now: * Last SVN commit on 2013-12-04. * Did not send a mail to the mailing lists for ~6 months. * Inactive on the AUR (there are orphan requests for his packages). * Inactive on the bug tracker. * Inactive on IRC. I sent him an email a couple of days ago but didn't receive a reply. Hope he is doing well! Let the discussion period begin, the voting period will start on 2014-08-05. [1] https://aur.archlinux.org/trusted-user/TUbylaws.html#_special_removal_of_an_inactive_tu
[aur-general] AUR 3.4.3 released
Hello, I am pleased to announce that AUR 3.4.3 has been released. The official AUR setup [1] has already been updated. This release includes a bug fix to the user statistics and Trusted User interface, as well as Translation updates. For a comprehensive list of changes, please consult the Git log [2]. As usual, bugs should be reported to the AUR bug tracker [3]. [1] https://aur.archlinux.org/ [2] https://projects.archlinux.org/aur.git/log/?id=v3.4.3 [3] https://bugs.archlinux.org/index.php?project=2
Re: [aur-general] Not able to register with the AUR site
On Tue, 29 Jul 2014 at 13:04:28, Karthik K wrote: I'm trying to register with the AUR site, but every time I fill up the registration form and submit the details, the page just refreshes and just goes back to the original state. Is this a known bug? How can new users register with the AUR site? Should be fixed now. Thanks for reporting.
[aur-general] AUR 3.4.1 released
Hello, I am pleased to announce that AUR 3.4.1 has been released. The official AUR setup [1] has already been updated. This release includes bug fixes regarding the account registration form and translations. For a comprehensive list of changes, please consult the Git log [2]. As usual, bugs should be reported to the AUR bug tracker [3]. [1] https://aur.archlinux.org/ [2] https://projects.archlinux.org/aur.git/log/?id=v3.4.1 [3] https://bugs.archlinux.org/index.php?project=2
[aur-general] AUR 3.4.2 released
Hello, I am pleased to announce that AUR 3.4.2 has been released. The official AUR setup [1] has already been updated. This release includes several bug fixes regarding the requests interface. For a comprehensive list of changes, please consult the Git log [2]. As usual, bugs should be reported to the AUR bug tracker [3]. [1] https://aur.archlinux.org/ [2] https://projects.archlinux.org/aur.git/log/?id=v3.4.2 [3] https://bugs.archlinux.org/index.php?project=2
Re: [aur-general] Not able to register with the AUR site
On Tue, 29 Jul 2014 at 18:33:48, Karthik K wrote: Able to register now. This is the message, I get after the register page The account, *username*, has been successfully created. A password reset key has been sent to your e-mail address. Following the link in the mail takes me to a password reset page, where I can set a new password and am able to login with these credentials now. This whole workflow seems wrong. Why should a person be directed to a password reset page when he is registering a new account? I already have an account at Arch Wiki with the same credentials. Do both AUR and the wiki use the same accounts? Is this why my new account registration request at AUR was actually considered as a password change request? No, the wiki and the AUR use different accounts. The password reset form is used to set an initial password for your AUR account. Maybe we should use a different title when that page is accessed via the link in the welcome email...
[aur-general] AUR 3.4.0 released
Hello, I am pleased to announce that AUR 3.4.0 has been released. The official AUR setup [1] has already been updated. This release includes several improvements to the package request feature and a couple of bug fixes. The PKGBUILD parser has been dropped, you can no longer upload source packages without meta data. Also, a new user group Trusted User Developer was added. I already converted a couple of accounts to the new group; please let me know if I missed anyone. For a comprehensive list of changes, please consult the Git log [2]. As usual, bugs should be reported to the AUR bug tracker [3]. [1] https://aur.archlinux.org/ [2] https://projects.archlinux.org/aur.git/log/?id=v3.4.0 [3] https://bugs.archlinux.org/index.php?project=2
Re: [aur-general] AUR 3.4.0 released
On Mon, 28 Jul 2014 at 21:49:56, Karol Blazewicz wrote: [...] https://bugs.archlinux.org/index.php?project=2do=indexswitch=1 says Note: The AUR is essentially in maintanence mode. No new features are planned. which in light of https://projects.archlinux.org/aur.git/log/?id=v3.4.0 doesn't sound right (and I don't mean the 'maintanence' typo). Should we remove this line? Done.
Re: [aur-general] [HEADS-UP] Meta data and split package support in the AUR
On Sat, 05 Apr 2014 at 14:38:44, Lukas Fleischer wrote: [...] 1. We can drop the PKGBUILD parser from the AUR. The parser will still be available in the upcoming release but it will be marked as deprecated and a warning will be displayed whenever someone tries to upload a source tarball without metadata. Note that this will happen in the next release which will be tagged next week. So if anyone is still using the old PKGBUILD parser, please switch to using .AURINFO now. 2. We can implement other things that were blocked by the AUR PKGBUILD parser being incomplete and inaccurate. Specifically, the next release will support split packages. Things that are on our TODO list: * Test the new AUR code. The split package code is still experimental. * Fix and extend the AUR RPC interface. * Test Dave's pkgbuild-introspection. * Move pkgbuild-introspection (or at least mkaurball) to [community]. It would also be nice to get metadata generation integrated into makepkg so that people no longer need to install mkaurball to generate source tarballs for the AUR. Regards, Lukas [1] https://github.com/falconindy/pkgbuild-introspection
Re: [aur-general] AUR 3.3.0 released
On Wed, 09 Jul 2014 at 09:56:18, Attila Bukor wrote: On 07/08/2014 06:27 PM, Steven Honeyman wrote: The trouble is there are too many people that don't (or can't) think about *why* something might not be working. It's often the users' fault :) Suppose someone sets ld.gold as their default linker because the internet told them it was better... and then tries to compile imagemagick... Steven. What if it would be a vote-like structure and one reporter wouldn't be enough to flag it as not working? Dan suggested something similar some time ago [1] and I quite like that idea. One Mark package broken button and an option to sort package search results by the number of users that marked a package. r1pp3rj4ck [1] http://mailman.archlinux.org/pipermail/aur-dev/2011-June/001698.html
Re: [aur-general] Troll account
On Wed, 09 Jul 2014 at 01:09:05, Rob McCathie wrote: Hello AUR General, I am a Manjaro team member and have been an Arch user for ~5 years. I still run Arch proper on many systems and test my AUR packages on Arch proper (just thought i'd get that out of the way ;-p ) We've had to remove someone from our team recently due to their abusing of their forum account's moderation privileges and some other stuff. This person has gone on to prove just how right we were to get rid of them by launching malicious attacks on our wiki and attempts on some other web services. (There's no doubt it's the same person, he directly threatened us with malicious action.) It appears now he is attacking Manjaro team members with any avenue he can find. This account here: https://aur.archlinux.org/account/kingrobbo Has been made for no reason but to troll (myself and possibly other Manjaro devs with AUR accounts). [...] I closed the deletion request and suspended his account. Thanks for reporting.
[aur-general] AUR 3.3.0 released
Hello, I am pleased to announce that AUR 3.3.0 has just been released. The official AUR setup [1] has already been updated. This release includes several improvements to the package request feature and a couple of bug fixes. For a comprehensive list of changes, please consult the Git log [2]. As usual, bugs should be reported to the AUR bug tracker [3]. [1] https://aur.archlinux.org/ [2] https://projects.archlinux.org/aur.git/log/?id=v3.3.0 [3] https://bugs.archlinux.org/index.php?project=2
[aur-general] AUR 3.2.0 released
Hello, I am pleased to announce that AUR 3.2.0 has just been released. The official AUR setup [1] has already been updated. You can now send deletion, merge and orphan requests by using the File Request link in the package actions box. Please use the web interface instead of manually sending mails to aur-general or aur-requests from now on. Note to all AUR helper maintainers: There also is a new version of the RPC interface (v3) that makes the result values types a bit more consistent. See FS#40963 [2] for details. For a comprehensive list of changes, please consult the Git log [3]. As usual, bugs should be reported to the AUR bug tracker [4]. [1] https://aur.archlinux.org/ [2] https://bugs.archlinux.org/task/40963 [3] https://projects.archlinux.org/aur.git/log/?id=v3.2.0 [4] https://bugs.archlinux.org/index.php?project=2
Re: [aur-general] AUR 3.2.0 released
On Tue, 01 Jul 2014 at 22:03:28, Steven Honeyman wrote: Nice! Does the 14 day rule still apply for orphan requests? [...] Yes, however, there is no need to inform the maintainer manually any longer since maintainers get notified when a request is created. Also, note to Trusted Users: Package requests are highlighted after 14 days, so it is a good idea to only accept highlighted requests in most cases.
Re: [aur-general] Permission-error in AUR-submit
On Tue, 10 Jun 2014 at 16:57:00, Oliver Bandel wrote: Hello, I get an error message about wrong permissions in the AUR-source-file. I had wrong permissions for my PKGBUILD and changed that, created the sourcep-package again. Nevertheless the problem could not be solved. I used mkaurball to create the tarball. After creating the tarball I untared it, to check permissions and anything seemed to be ok. But AUR does not accept it. Please explain what the problem is, and how it can be fixed. Maybe .AURINFO has wrong permissions? What is the output of `tar -tvf $tarball`? Ciao, Oliver
Re: [aur-general] AUR 3.0.0 released
On Thu, 05 Jun 2014 at 08:12:23, Florian Bruhin wrote: * Hector Martinez-Seara hse...@gmail.com [2014-06-05 08:56:00 +0300]: Notice that before AUR 3 just calling makepkg --source was enough. Any good reason for this change? If there any possibility as Philip proposes that this is done in the serve side? [...] But I agree, adjusting the permissions probably should (and AFAIK could be done safely) on the server side. No, we do not (and will never) modify the tarball on the server-side. If that really annoys you, just write a simple wrapper script around mkaurball or patch mkaurball so that it adjusts the permissions. Note that this issue will vanish soon anyway since the next major AUR release will provide Git repositories for all AUR packages. You will no longer need to create source tarballs. Florian -- http://www.the-compiler.org | m...@the-compiler.org (Mail/XMPP) GPG 0xFD55A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/
Re: [aur-general] AUR 3.0.0 released
On Thu, 05 Jun 2014 at 09:08:48, Florian Bruhin wrote: * Lukas Fleischer archli...@cryptocrack.de [2014-06-05 09:03:29 +0200]: Note that this issue will vanish soon anyway since the next major AUR release will provide Git repositories for all AUR packages. You will no longer need to create source tarballs. That sounds intresting! Is there some kind of specification or some more notes regarding this? I wonder how permissions/merges/etc. will be dealt with. Check [1] for some of the implementation details. Florian -- http://www.the-compiler.org | m...@the-compiler.org (Mail/XMPP) GPG 0xFD55A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/ [1] https://mailman.archlinux.org/pipermail/aur-dev/2014-June/002770.html
Re: [aur-general] AUR 3.0.0 released
On Thu, 05 Jun 2014 at 09:52:11, William Giokas wrote: On Thu, Jun 05, 2014 at 09:28:15AM +0200, Lukas Fleischer wrote: On Thu, 05 Jun 2014 at 09:08:48, Florian Bruhin wrote: * Lukas Fleischer archli...@cryptocrack.de [2014-06-05 09:03:29 +0200]: Note that this issue will vanish soon anyway since the next major AUR release will provide Git repositories for all AUR packages. You will no longer need to create source tarballs. That sounds intresting! Is there some kind of specification or some more notes regarding this? I wonder how permissions/merges/etc. will be dealt with. Check [1] for some of the implementation details. On top of that, looking directly at permissions, git only tracks the executable bit, so the only permissions that git knows of for regular files is 755 and 644. [...] Yes, that's exactly what I wanted to suggest when saying that this issue will vanish soon anyway since the next major AUR release will provide Git repositories for all AUR packages. Sorry for being vague.
[aur-general] AUR 3.1.0 released
Hello, I am pleased to announce that AUR 3.1.0 has just been released. The official AUR setup [1] has already been updated. This release includes several bug fixes, the RPC interface now reports package base IDs, long lists of source files are collapsed and a Search wiki link has been added to the package details page. Versioned conflicts (provides, replaces) are now displayed properly. For a comprehensive list of changes, please consult the Git log [2]. As usual, bugs should be reported to the AUR bug tracker [3]. [1] https://aur.archlinux.org/ [2] https://projects.archlinux.org/aur.git/log/?id=v3.1.0 [3] https://bugs.archlinux.org/index.php?project=2
Re: [aur-general] delete request: plaintable
On Sun, 01 Jun 2014 at 09:39:23, Stefan Tatschner wrote: I accidentally forgot the 'python-' prefix in my pkgbuild. So please remove this one here [1]. I'm sorry for this inconvenience. Deleted, thanks! Thanks! Stefan [1]: https://aur.archlinux.org/packages/plaintable/
Re: [aur-general] delete request: split package merge
On Sun, 01 Jun 2014 at 09:19:15, Stefan Tatschner wrote: Hi, yesterday I created new packages for my project pynote. Today I realized that the new AUR 3.0 now has split package support. So please delete: - pynote-docs [1] - pynote-docs-git [2] Both deleted. Thanks for reporting! I will resubmit them as split packages from pynote and pynote-git. Thanks! Stefan [1]: https://aur.archlinux.org/packages/pynote-docs/ [2]: https://aur.archlinux.org/packages/pynote-docs-git/
Re: [aur-general] Merging packages into a split package (was: pkg deletion request)
On Sat, 31 May 2014 at 21:08:34, Yichao Yu wrote: [...] It is a bit unfortunate that this process makes merging a bit more complicated and results in packages being unavailable for a short transition period (see steps 1 to 3). I didn't come up with something better yet. Should we give TUs extra power and allow for uploading PKGBUILDs that automatically overwrite (and merge) packages? The downside is that this would be quite complicated to implement and we would have to ensure that no strange things can happen, e.g. partly overwriting another split package by replacing a subset of its packages. Trusted Users would also have to have a very close look at the packages before merging to ensure that no malicious takeover happens. Any suggestions are welcome. One thing to add is that if you own all the other packages, you can change their pkgname (to sth random) while keeping the same pkgbase. You can then upload the new package with all the pkgnames and let a TU to merge the original (not empty and useless) packages to the new one. This way at least it is not necessary to wait for a TU to make the new package work. Good idea! Actually, that should already work: Just add a pkgbase variable to the PKGBUILDs and change their pkgname, e.g. by appending the string -old. So, another (maybe better) work flow is: 1. Add pkgbase variables to each package using the current package name as package base name. 2. Change the pkgname of each package to something new, e.g. by adding the suffix -old. 3. Upload the new split package. 4. File a request to merge the -old packages (more precisely: the old package bases that only contain one package with the suffix -old) into the new split package. Thanks, artoo
Re: [aur-general] AUR 3.0.0 released
Hi, On Sun, 01 Jun 2014 at 13:36:29, Jerome Leclanche wrote: Hi I'm trying to upload a split package of sddm -qt5-git and -git (attached), but when I upload it, it says: You are not allowed to overwrite the sddm-qt5-git package.. I'm a maintainer of both of course. Is this a bug? If not, what's the correct course of action? [...] No, this isn't a bug. You cannot overwrite a package from a different package base. What you can do is: 1. Rename the sddm-qt5-git package without changing its package base: pkgbase=sddm-qt5-git pkgname=sddm-qt5-git-old This might also require some $pkgname references to be replaced by $pkgbase in order to successfully build a new package. 2. Submit the updated package to the AUR. This will result in the package name changing from sddm-qt5-git to sddm-qt5-git-old. 3. Upload the new split package. 4. Request the old (renamed) package (sddm-qt5-git-old) to be merged into the new one. Please read both [1] and [2] for details. Regards, Lukas [1] https://mailman.archlinux.org/pipermail/aur-general/2014-May/028594.html [2] https://mailman.archlinux.org/pipermail/aur-general/2014-June/028631.html
Re: [aur-general] AUR 3.0.0 released
On Sun, 01 Jun 2014 at 16:16:08, Jerome Leclanche wrote: That's very unfortunate and quite a bit counter-intuitive. Is this final? [...] No, it's not. As I said in the other thread [1] on this topic, I am open for suggestions. [1] https://mailman.archlinux.org/pipermail/aur-general/2014-May/028594.html
Re: [aur-general] AUR 3.0.0 released
On Fri, 30 May 2014 at 03:54:09, Hong Shick Pak wrote: [...] I didn't try changing my AUR username before the update, but I'm trying to it from Hspasta to Hspak and I seem to be getting an irrelevant (generic?) error messages: The username is invalid. It must be between 3 and 16 characters long Start and end with a letter or number Can contain only one period, underscore or hyphen. Should be fixed now. Thanks for reporting. Screeny: http://i.imgur.com/uoSamGs.png (I retyped my password too) Hong
[aur-general] Merging packages into a split package (was: pkg deletion request)
On Fri, 30 May 2014 at 14:03:00, artux wrote: [...] Suppose I want to move/merge a single pkgbuild to a split build, is that possible? Will the pkgbase change, so the single pkgbuld will disappear automatically? Or the other way round, I want to move a pkg from split build to single build? Is there any documentation for this kind of stuff? The logic is as follows: * Package bases can be overwritten by their maintainers and by TUs. * Packages can only be overwritten if they already belong to the package base of the submitted package. That means that you cannot upload a PKGBUILD containing a package which is already part of another package base. So in order to replace several packages with a split package, you will need to: 1. Upload a (basically empty) meta package with the new package base (unless you want to use a package base that already exists, e.g. the name of the first package to merge). 2. File a request to merge every package into the new split package. 3. Upload a proper split package to replace the meta package. It is a bit unfortunate that this process makes merging a bit more complicated and results in packages being unavailable for a short transition period (see steps 1 to 3). I didn't come up with something better yet. Should we give TUs extra power and allow for uploading PKGBUILDs that automatically overwrite (and merge) packages? The downside is that this would be quite complicated to implement and we would have to ensure that no strange things can happen, e.g. partly overwriting another split package by replacing a subset of its packages. Trusted Users would also have to have a very close look at the packages before merging to ensure that no malicious takeover happens. Any suggestions are welcome. Thanks, artoo
Re: [aur-general] AUR 3.0.0 released
On Thu, 29 May 2014 at 10:52:58, Andreas Radke wrote: [...] The RSS feed seems empty. Fixed in maint. Thanks! -Andy
[aur-general] AUR 3.0.0 released
Hello, I am pleased to announce that AUR 3.0.0 has just been released. The official AUR setup [1] has already been updated. Note that in order to build source packages for the AUR, you will now need to use a tool called mkaurball (instead of `makepkg --source`). It is included in the pkgbuild-introspection package [2]. For a comprehensive list of changes, please consult the Git log [3]. As usual, bugs should be reported to the AUR bug tracker [4]. [1] https://aur.archlinux.org/ [2] https://www.archlinux.org/packages/community/any/pkgbuild-introspection/ [3] https://projects.archlinux.org/aur.git/log/?id=v3.0.0 [4] https://bugs.archlinux.org/index.php?project=2
Re: [aur-general] delete request - fwts-efi-runtime-dkms
On Tue, 27 May 2014 at 22:11:55, Mariusz Libera wrote: Hi, please delete fwts-efi-runtime-dkms - https://aur.archlinux.org/packages/fwts-efi-runtime-dkms/ I'm maintainer of this package and I want to make it a split of fwts - https://aur.archlinux.org/packages/fwts/ Deleted, thanks! Thanks, Mariusz Libera
Re: [aur-general] Account deletion request
On Mon, 12 May 2014 at 21:59:53, Xyne wrote: [...] There is no normal way to delete user accounts at the moment. The motivation for this was the preservation of comments in discussions. I think there was some discussion recently about enabling account deletion by transferring comments to a ghost account. Lukas, can you comment on this? My own opinion is that it should always be possible to delete your own account from any service that you join. The absence of this option on the AUR is hopefully only temporary due to technical reasons. There will be support for anonymous comments in the next AUR release, so this shouldn't be hard to implement. Could you please file a feature request on the AUR bug tracker? Regards, Xyne
[aur-general] AUR 3.0.0-rc1 released
A first release candidate of the AUR 3.0.0 has been released! You can
give it a try at [1]. Note that due to internal changes, the setup at
aur-dev.archlinux.org uses a different database than aur.archlinux.org.
You should be able login using your regular AUR account, though.
The most important changes are:
* Full split package support.
* Support for {make,check,opt}depends, conflicts, provides, ...
* Full support for the new fields in the RPC interface.
* Metadata support. Use mkaurball instead of `makepkg --source` to
generate source tarballs for the AUR`. You can get it from [2] -- it
will eventually be moved to [community].
Note that in order to obtain the new fields, you need to request the new
version of the RPC API explicitly, like this:
https://aur-dev.archlinux.org/rpc.php?type=infoarg=passv=2
Otherwise, the replies default to the old format for compatibility
reasons.
Please report any bugs to the AUR bug tracker [3].
[1] https://aur-dev.archlinux.org/
[2] https://aur.archlinux.org/packages/pkgbuild-introspection-git/
[3] https://bugs.archlinux.org/index.php?project=2
Re: [aur-general] Can't upload a new package
On Sat, 19 Apr 2014 at 13:01:33, Ivan Shapovalov wrote:
Hello,
I'm having trouble sending a new package to AUR.
AUR replies Missing arch variable in PKGBUILD.
The PKGBUILD is pasted below; `namcap PKGBUILD` says nothing
(i. e. all OK).
cut here
# Maintainer: Ivan Shapovalov intelfx...@gmail.com
pkgname=power-management
pkgver=11.4722a84
url=https://github.com/intelfx/power-management;
pkgrel=1
pkgdesc=systemd-aware pm-powersave replacement
license=(GPL3)
depends=()
source=(power-management::git://github.com/intelfx/power-management#commit=4722a84)
install=power-management.install
arch=(any)
md5sums=('SKIP')
package() {
cd power-management
DESTDIR=$pkgdir ./install.sh
}
cut here
This is due to a bug in the AUR PKGBUILD parser. As a workaround, move
the arch line before the source line.
The next AUR release will use meta data instead of parsing the PKGBUILD
which fixes all parser issues.
Thanks.
--
Ivan Shapovalov / intelfx /
[aur-general] [HEADS-UP] Meta data and split package support in the AUR
Hello, I plan to do the next major AUR release by late May or June and I thought this might be a good time to let people know what is going on behind the scenes. AUR 3.0.0 will be able to read metadata from source packages. These metadata will be read from a file called .AURINFO (contained in the source tarball). Dave wrote several tools [1], including mkaurball which can be used to automatically build a source tarball with metadata so you don't need to worry about creating this file on your own. Having this information available means that: 1. We can drop the PKGBUILD parser from the AUR. The parser will still be available in the upcoming release but it will be marked as deprecated and a warning will be displayed whenever someone tries to upload a source tarball without metadata. 2. We can implement other things that were blocked by the AUR PKGBUILD parser being incomplete and inaccurate. Specifically, the next release will support split packages. Things that are on our TODO list: * Test the new AUR code. The split package code is still experimental. * Fix and extend the AUR RPC interface. * Test Dave's pkgbuild-introspection. * Move pkgbuild-introspection (or at least mkaurball) to [community]. It would also be nice to get metadata generation integrated into makepkg so that people no longer need to install mkaurball to generate source tarballs for the AUR. Regards, Lukas [1] https://github.com/falconindy/pkgbuild-introspection
Re: [aur-general] Voting results (was: TU application sponsored by David Reisner)
On Sat, 08 Feb 2014 at 18:14:21, Lukas Fleischer wrote: On Mon, 03 Feb 2014 at 20:26:22, Anatol Pomozov wrote: Hi everyone I would like to apply for a Arch Trusted User position. It is sponsored by my co-worker and bright engineer David Reisner. [...] You can now cast your votes [1]. The voting period ends on 2014-02-15. Note that intermediate voting results are no longer visible due to a recent AUR patch. Results: * Yes: 25 * No: 3 * Abstain: 2 We have reached a quorum and the application has been accepted. Congratulations and welcome in our team, Anatol! Please make sure you read the AUR Trusted User Guidelines and follow the TODO list for new Trusted Users. [1] https://aur.archlinux.org/tu/?id=75
Re: [aur-general] Removing stale accounts from the AUR
On Fri, 31 Jan 2014 at 13:17:25, Lukas Fleischer wrote: Hi, I plan to remove all AUR accounts that have not been used for at least 500 days (according to the last login time stamp). This affects ~35000 users, see [1] for a complete list. If your account is on that list and you think it shouldn't be there, please let me know. Just noticed that there are some developer accounts on that list. I will exclude them from the list of accounts being purged. Side effects: * The ~2000 packages maintained by these users will be orphaned. * All ~2 comments written by any of the users will be removed. * Votes will be retained. Regards, Lukas [1] http://sprunge.us/LBSe
Re: [aur-general] Removing stale accounts from the AUR
On Fri, 31 Jan 2014 at 13:17:25, Lukas Fleischer wrote: Hi, I plan to remove all AUR accounts that have not been used for at least 500 days (according to the last login time stamp). This affects ~35000 users, see [1] for a complete list. If your account is on that list and you think it shouldn't be there, please let me know. Side effects: * The ~2000 packages maintained by these users will be orphaned. * All ~2 comments written by any of the users will be removed. * Votes will be retained. [...] After some reconsideration, I think it is better to do this the other way round. Comments will be retained (support for this will be added with a patch I just submitted to aur-dev [1]) and votes will be removed. We can still do comment cleanups later if we want to. Regards, Lukas [1] https://mailman.archlinux.org/pipermail/aur-dev/2014-February/002646.html
Re: [aur-general] TU application sponsored by David Reisner
On Wed, 05 Feb 2014 at 00:12:49, Xyne wrote: Dave Reisner wrote: On Mon, Feb 03, 2014 at 02:49:48PM -0500, Daniel Micay wrote: On Mon, Feb 3, 2014 at 2:46 PM, Dave Reisner d...@falconindy.com wrote: On Mon, Feb 03, 2014 at 11:26:22AM -0800, Anatol Pomozov wrote: Hi everyone I would like to apply for a Arch Trusted User position. It is sponsored by my co-worker and bright engineer David Reisner. My name is Dave and I approve this message. Nice try, David. My GPG signature says you're wrong. Nitpick: the current by-laws require the sponsor to be a TU. Do we override Hal to open the hatch? Technically, that is correct. However, I am sure there are many other TUs volunteering to be the sponsor after having read the application and the discussion (me, for example). So I don't think it is a problem. If it makes feel anyone better, please run sed 's/David Reisner/Lukas Fleischer/g' on your inbox (the misspelling of Dave's name comes in useful here!)
Re: [aur-general] Voting results (was: TU application, sponsored by Lukas Fleischer)
On Mon, 27 Jan 2014 at 19:07:19, Lukas Fleischer wrote: On Tue, 21 Jan 2014 at 00:32:08, Jonas Heinrich wrote: Hi ArchLinux community, I like to apply as TU, sponsored by Lukas Fleischer (aka CryptoCrack), since my passion and work for ArchLinux continues since half a decade and I really would like to get more involved into development and package maintaining. [...] The discussion period is over. Please cast your votes now [1]. Voting is closed. The results are: * Yes: 1 * No: 24 * Abstain: 7 Unfortunately, this means that the application has been rejected. Sorry, Jonas! Some rather general tips from me (to you and to other future applicants): * Check whether your PKGBUILDs are up-to-date and in good shape. Usually, sponsors will have a look at your AUR packages (which I clearly did not do carefully enough in this case) but it is a good idea to have a look at your packages yourself (maybe even ask someone to have a look at them if you are not sure) and polish stuff before asking a TU to sponsor your application. * Heed the advice of your sponsor! If the sponsor recommends doing some preparatory work before submitting the application, do it. There is no point in submitting the application over-hasty. If the sponsor gives you an advice during the application period, don't simply ignore it. If you think you cannot accept the advice for whatever reasons, you should at least reply and say you can't. * Discuss. During the discussion period, it is generally a good idea react to questions and criticism. Not taking part in the discussion usually is a sign of lack of interest and a sign of not being able to take criticism and is likely to have a negative impact on the voting. Jonas, sadly, the TU bylaws prohibit you to reapply for three months. However, you can take advantage of the remaining time and work on your packages. Feel free to resubmit (don't take this literally) your application anytime as of mid-May. Regards, Lukas [1] https://aur.archlinux.org/tu/?id=74
[aur-general] Removing stale accounts from the AUR
Hi, I plan to remove all AUR accounts that have not been used for at least 500 days (according to the last login time stamp). This affects ~35000 users, see [1] for a complete list. If your account is on that list and you think it shouldn't be there, please let me know. Side effects: * The ~2000 packages maintained by these users will be orphaned. * All ~2 comments written by any of the users will be removed. * Votes will be retained. Regards, Lukas [1] http://sprunge.us/LBSe
Re: [aur-general] Removing stale accounts from the AUR
On Fri, 31 Jan 2014 at 13:17:25, Lukas Fleischer wrote: Hi, I plan to remove all AUR accounts that have not been used for at least 500 days (according to the last login time stamp). This affects ~35000 users, see [1] for a complete list. If your account is on that list and you think it shouldn't be there, please let me know. Ok, it seems like this last sentence wasn't clear enough. Please DO NOT send me mails if you haven't logged in for a long time but want to keep your account. In that case, just log in to update the login time stamp. However, please notify me if you actually used your account within the last 500 days and your account is on that list anyway. [...]
Re: [aur-general] TU application, sponsored by Lukas Fleischer
On Tue, 21 Jan 2014 at 00:32:08, Jonas Heinrich wrote: Hi ArchLinux community, I like to apply as TU, sponsored by Lukas Fleischer (aka CryptoCrack), since my passion and work for ArchLinux continues since half a decade and I really would like to get more involved into development and package maintaining. [...] The discussion period is over. Please cast your votes now [1]. [1] https://aur.archlinux.org/tu/?id=74
Re: [aur-general] TU application, sponsored by Lukas Fleischer
On Tue, 21 Jan 2014 at 00:32:08, Jonas Heinrich wrote: Hi ArchLinux community, I like to apply as TU, sponsored by Lukas Fleischer (aka CryptoCrack), since my passion and work for ArchLinux continues since half a decade and I really would like to get more involved into development and package maintaining. [...] I confirm my sponsorship, let the discussion period begin.
Re: [aur-general] TU application, sponsored by Lukas Fleischer
On Tue, 21 Jan 2014 at 09:31:41, Doug Newgard wrote: [...] Ok, so let's look at just that one. I must admit that I only had a look at very few packages before agreeing to the sponsorship. However I did advice Jonas to have a look at his packages and update the one's that are flagged out-of-date before submitting his application which he obviously did not do for some reason... :/ I won't comment on any of the following questions and give Jonas a chance to reply. What are Unconfirmed makedeps? Are they makedeps or aren't they? You set the backup array based on what is installed at build time, which has little to do with what is installed at install/run time. This works (somewhat) in the AUR but not at all in binary repos. Not only that, but you then set a new backup array right after it making the whole thing moot. You pull a bunch of files directly from master of a git repo. Very fragile. Your quoting of paths containing variables is very inconsistent, some are quoted then not quoted in the next line. Your use of curly braces is inconsistent. Sometimes you use mv, sometimes cp, and sometimes install. Why? Again, you're installing things based on what is installed at build time. That's from a cursory reading of your given example, without looking into it in detail or looking at the install file at all. You see what I mean? Many TUs have as many or more packages than you're talking about, and they're all expected to be in good shape. Looking at more packages, I also noticed that some even still use $startdir and some seem to have the return hack in build() that the AUR required ages ago. It would be nice if you could clean those up soon.
