- Aur-general - lists.archlinux.org

Re: [aur-general] Discussion period - Moving [community] to use same system as main repos
by Loui Chang 09 Jan '09

09 Jan '09

On Sat, Jan 10, 2009 at 04:42:30AM +1000, Allan McRae wrote: > Just throwing this out there.... do we need votes once a package is in > [community]? I'd say yeah. It can help if we're doing a package clean up for instance. I'm only a bit wary of pkgstats because I can't seem to find the source for the server side.

1 0

Re: [aur-general] Discussion period - Moving [community] to use same system as main repos
by Loui Chang 09 Jan '09

09 Jan '09

On Sat, Jan 10, 2009 at 03:33:38AM +1000, Allan McRae wrote: > Hi all, > > To get this moving along, I would like to start the official discussion > period. Standard rules, 5 days discussion, 7 days voting, 75% quorum. If > discussion raises some points which really need to be addressed before a > vote then it can be delayed. > > Abhishek has mad a good summary with some additions by Loui at > http://wiki.archlinux.org/index.php/Community_move_to_devtools . > > > I am very much in favour of this move as it will allow use to use [testing] > for community packages, which remove the current problems we have during big > rebuilds. It also means that any other changes made to the repos (e.g. > arch=any packages, delta support to name my favourites) only needs to be > made in one place. I also like the idea of the AUR being just unsupported > packages and (despite not actually contributing code to the AUR) I have the > feeling that this separation would make AUR development cleaner. > > Loosing the ability for users to leave comments about a package on the AUR > is not a big deal for me as I think most of these should probably go to the > bug tracker where they will not get lost. The concern about autonomy of the > TUs is difficult for me to judge being a dev too, but given ~1/3 TUs are > devs... Well, what we lose or gain depends on how the change is implemented. We could still track votes via AUR until a better system is implemented. We just need to be able to get a checkout of everything in community and modify tupkgupdate.

3 2

[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