- Aur-general - lists.archlinux.org

[aur-general] Error uploading packages in AUR
by Angel Velásquez 08 Jan '09

08 Jan '09

Hi, I was trying to upload a PKGBUILD into AUR but I got an error, I can't see what is exactly the error (display_errors = Off on the php.ini config, maybe). I just got a blank page and I cannot add a new PKG, can you review?, I will add the tar.gz with the PKGBUILD, thanks -- Angel Velásquez angvp @ irc.freenode.net Linux Counter: #359909 Arch Linux Trusted User

4 4

[aur-general] storming in for no reason with crazy ideas
by eliott 07 Jan '09

07 Jan '09

Hello! Long time reader, first time poster (in quite a while). I was bored today, so I read through some of the mailing list archive. Whew! Anyway, I had one of those crazy ideas that is, well, crazy. As this is the internet and I have some free time, allow me to subject you all to my crazy idea! Hooray! *coughs* Why not move towards separating the duties of the current AUR system from the duties of the TU system. I propose making the TUs 'associate arch devs', and having them use the main arch repository system, but in a reduced security/permission role. Something like TUs getting access to community only, like they have now..but using the same dev tools system as the mainline devs, having community just be 'another repo' in the main site interface (just like extra and core). Sure it will take a bit of effort, but it would streamline some processes for sure! Detriments: - TUs wouldn't be as autonomous as they historically have been. This could be good or bad, but putting it in the 'bad' category, because people fear change..and this is a change. - It would take _some amount_ more than 0 value of effort to get the TUs into the mainline dev system. Benefits: - Less tools to support, as the TUs would then use the same dev tools as devs, but with limited permissions. - Process streamline - Clearer path for migration from 'associate dev' to 'dev'. Just flip a bit in the permissions for the devtools, and they can now move packages to extra or core, etc. - Decouple community from the AUR. The AUR would then 'be its own bag'. Leaving end user voting as a guide for moving packages into community (or not..whatever), then packages in community would disappear from the aur when they were adopted into community. - Greater visibility for community repository. It is already included by default, so it should be treated as such... a vital component to the overall arch ecosystem. - Future AUR rewrites or refactoring would be greatly simplified. - The existing TU toolchain and server daemon can be jettisoned into the abyss, to live with other lovecraftian horrors. So there you have it. Talk amongst yourselves. I will be over here..hiding in the shrubbery. o.O

15 40

Re: [aur-general] storming in for no reason with crazy ideas
by Loui Chang 07 Jan '09

07 Jan '09

On Wed, Jan 07, 2009 at 10:35:49PM +1000, Allan McRae wrote: > Sure. But if according to the overlord this is never going to happen, then > there is not much point discussing this further. True. > > Unless votes are implemented in archweb I think we should keep the AUR > > interface for votes/search at least. The backend can still change. Another issue is importing votes from community to unsupported and vice-versa. > Given you are one of the main AUR contributors, can you give us an idea of > how long it would realistically take to change the AUR to use the SVN style > backend used by the main repos? It'd require: 1. the ability to checkout all PKGBUILDs that are in community 2. a community upload script for devtools (like communitypkg) 3. possibly some minor patching of tupkgupdate. Another issue is that adding another 1800 packages to the SVN will make checkouts that much slower since there's no way to know what's any particular repo from the top level. You would have to scan every package directory. I'm not convinced in the merits of moving to that kind of repo layout. If community is moved to SVN I think I'd prefer if it had its own repo separate from core and extra. That way neither community or official will be at a performance detriment, but migrating packages won't be as easy. Eh, there's always a tradeoff.

1 0

[aur-general] Cleaning up
by Lukáš Jirkovský 07 Jan '09

07 Jan '09

Hi, I've found out that there are some unnecessary wine packages: bit32-wine – orphaned and it's duplicate of bin32-wine http://aur.archlinux.org/packages.php?ID=22866 32bit-wine – duplicate of bin32-wine http://aur.archlinux.org/packages.php?ID=22857

2 3

Re: [aur-general] storming in for no reason with crazy ideas
by Loui Chang 07 Jan '09

07 Jan '09

On Wed, Jan 07, 2009 at 10:10:26PM +1000, Allan McRae wrote: > I would like to hear Aaron's opinion on whether [community] packages should > appear on the main web page rather than the AUR if/when we go for the > single repo-tools route. > The advantage of having the [community] packages shown on the main page is > less maintenance. It also separates the AUR from any repo (which I > personally think is a good thing...) > > The disadvantage, is [community] becomes "overly official". Right. The TUs should be the ones to decide that part. I don't think it would be that hard to hook AUR into the devtools, but we wouldn't get some of the archweb improvements/features. We would keep package votes and comments though which are important I think. Unless votes are implemented in archweb I think we should keep the AUR interface for votes/search at least. The backend can still change.

2 1

Re: [aur-general] removal package
by Jan de Groot 07 Jan '09

07 Jan '09

On Wed, 2009-01-07 at 21:19 +1000, Allan McRae wrote: > Andrea Scarpino wrote: > > 2009/1/7 Alois Nešpor <alois.nespor(a)gmail.com>: > > > >> Please remove. Brasero 0.9.0 has removed GNOME UI, brasero-no-gnome is > >> now the same as brasero in [community]. > >> > >> http://aur.archlinux.org/packages.php?ID=19850 > >> > > Done, thanks > > > > > > Hmmm... I thought the -no-gnome version did not have totemplparser or > gconf usage either. > > Allan AFAIK gconf is required, but I could be wrong. The plparser thing is optional though and pulls in the whole gnome stack due to dependencies on evolution-data-server (I wonder who invented that dependency :X)

1 0

[aur-general] removal package
by Alois Nešpor 07 Jan '09

07 Jan '09

Please remove. Brasero 0.9.0 has removed GNOME UI, brasero-no-gnome is now the same as brasero in [community]. http://aur.archlinux.org/packages.php?ID=19850 Thanks. Alois

3 2

Re: [aur-general] storming in for no reason with crazy ideas
by Abhishek Dasgupta 07 Jan '09

07 Jan '09

On Wed, Jan 07, 2009 at 01:13:03PM +1000, Allan McRae wrote: > I think holidays happened. > > So here is what I think needs done before this goes ahead: > 1) official TU discussion period/vote > 2) devtools/db-script support for community, ABS update (I can handle > all that) > 3) prepare web stuff for switch (AUR and main Arch site depending on > what is happening with this.). > 3a) actually decide what is happening with web stuff. > 4) do the cvs -> svn migration. There still should be the scripts from > the main repo migration lying around > 5) have a drink to celebrate being finished. > > I'm going to start at #5... Anyone want to go ahead with organizing #1? I've posted an initial draft over at: http://wiki.archlinux.org/index.php/Community_move_to_devtools -- Abhishek Dasgupta <http://abhidg.mine.nu> GPG 67972DOF pgp.mit.edu

1 0

[aur-general] Suggestion of resource on AUR.
by Robson Roberto Souza Peixoto 06 Jan '09

06 Jan '09

When a packages was marked as out-of-date should set a timeout. If the owner don't updated, the package will marked as orphan. Something like two months. What do you think? -- Robson Roberto Souza Peixoto Robinho robsonpeixoto(a)gmail.com Telefone: (19) 8821-0396 Computer Science Master's degree student of University of Campinas (Unicamp), Brazil Archlinux-br Developer Team - http://archlinux-br.org

9 8

Re: [aur-general] e17 build script [was: Problems with PKGBUILD (Also, request for package deletion)]
by Ronald van Haren 05 Jan '09

05 Jan '09

On 1/2/09, Ronald van Haren <pressh(a)gmail.com> wrote: > > > On Fri, Jan 2, 2009 at 3:47 AM, Smartboy <smartboyathome(a)gmail.com> wrote: >> >> On Thu, Jan 1, 2009 at 1:24 PM, Ronald van Haren <pressh(a)gmail.com> wrote: >>> >>> >>> >>> On Thu, Jan 1, 2009 at 9:56 PM, Smartboy <smartboyathome(a)gmail.com> >>> wrote: >>>> >>>> >>>> >>>> On Thu, Jan 1, 2009 at 12:53 PM, Evangelos Foutras <foutrelis(a)gmail.com> >>>> wrote: >>>>> >>>>> Smartboy wrote: >>>>>> >>>>>> Problem is, I forgot to change the maintainer stuff at the top of the >>>>>> script, and when I try to edit it, even changing the pkgrel value >>>>>> doesn't work. I can't get the PKGBUILD on the site to change (I used >>>>>> another package's PKGBUILD to make mine). Can anyone help? >>>>> >>>>> >>>>> Are you sure it's not just your browser's cache showing you the older >>>>> version? I'm currently seeing easy-e17 1.2.2-3. >>>> >>>> >>>> You're right, sorry. [?] >>>>> >>>>> >>>>> >>>>>> Also, I am requesting the make-e17 script be removed. It does >>>>>> basically the same thing as my script, but hasn't worked in a year and >>>>>> has been flagged out of date for a while. >>>>> >>>>> >>>>> I can't find any packages named "make-e17". Unless another TU has >>>>> deleted it already, could you post a link to the package you want >>>>> removed? >>>> >>>> It is make_e17, not make-e17, sorry. :-\ >>>> >>>> Smartboy >>> >>> >>> I don't mind too much, but I don't really see the use of the script. IMO >>> it would be much better to have a script around which uses the ABS >>> PKGBUILDs and alternatively some AUR ones which are not in [community]. >>> >>> I have one laying around which builds the community package, and there is >>> one other on the forums IIRC. With a bit of work we could create a much >>> more usefull arch e17 script. These are just some thoughts so do with it >>> whatever you want :P >>> >>> Ronald >> >> >> I created the script on the forum which tries to get it from SVN using the >> PKGBUILDs you made, but there were too many problems with it. One was >> that, since there really is no "easy" way besides using yaourt-git to get >> community PKGBUILDs, and yaourt-git has many bugs with the -G function >> (like, when I try to get eina-svn, it gets eina instead). I tried fixing >> this, but I would have to have people download PKGBUILDs from my post, >> which is not what a script should require. > > > You can let the script depend on ABS. If people have a full ABS checkout > they have all PKGBUILDs required. In the script you could call abs via sudo, > I don't think that should be too much of a problem. > > Ronald > Last night I took the liberty of throwing together a small python script to build the community e17 packages which should be more suited for general usage than the bash script I used to use to build the communty e17 packages. I linked to the location of the script on the arch e17 wiki page, or you can get it directly from here [1]. Let me know if you think the script needs more functionality than it currently has. Ronald [1] http://www.archlinux.org/~ronald/e17.html

1 0