- Aur-general - lists.archlinux.org

[aur-general] Removal of x86_64-specific and opera flashplugin packages
by Evangelos Foutras 14 Jan '09

14 Jan '09

Hello fellow TUs, I have come across people who picked a flashplugin package from the AUR over the one in [extra]. I feel that x86_64 flashplugin packages should be removed from the AUR now that the official one supports both architectures. Furthermore, Opera seems to get along just fine with flashplugin from [extra] so we don't need Opera-specific packages either. Packages in question are: http://aur.archlinux.org/packages.php?ID=18096 (flashplayer-opera64) http://aur.archlinux.org/packages.php?ID=21601 (flashplugin-alpha-64) http://aur.archlinux.org/packages.php?ID=17442 (flashplugin-beta-opera) http://aur.archlinux.org/packages.php?ID=18695 (flashplugin-mozilla, maintainer believes this should stay because "the official plugin doesn't have mms.cfg" - not sure what this is :>) http://aur.archlinux.org/packages.php?ID=14074 (flashplugin-opera) http://aur.archlinux.org/packages.php?ID=21607 (flashplugin-x86_64) From the above, I'd say that the following can be safely deleted: flashplayer-opera64 flashplugin-alpha-64 flashplugin-beta-opera flashplugin-opera flashplugin-x86_64 Any opinions on this? Do you think we should proceed with the removal of these packages in order to avoid confusion between them and flashplugin from [extra]?

2 2

[aur-general] opencv-cvs removing request
by Артем Смирнов 14 Jan '09

14 Jan '09

Hi, please remove package opencv-cvs http://aur.archlinux.org/packages.php?ID=1749, its replaced by opencv-svn. Thanks. -- Artyom

2 1

[aur-general] package removal request
by joyfulgirl＠archlinux.us 14 Jan '09

14 Jan '09

Hey all, Could someone remove cl-ppcre-clisp and stumpwm-clisp-git from the AUR? I've recently adopted the SBCL versions of both packages and made the PKGBUILDs able to work with both lisps. I've also given any users of the original packages about a month's notice of the pending deletion in the comments. Much appreciated! -- If I Ever Become An Evil Villainess... 224. I will build machines which simply fail when overloaded, rather than wiping out all nearby henchpeople in an explosion or setting off a chain reaction. I will do this by using devices known as "surge protectors."

2 2

[aur-general] packages to update
by Thomas SARBONI 13 Jan '09

13 Jan '09

Hello all. Can somedody update these packages: -haxe -neko -editra -eclipse-pydev They are all flagged out to date from days (weeks ?) Thanks a lot. -- Thomas SARBONI April -promouvoir et défendre le logiciel libre- Aujourd'hui, Lundi 12 Janvier 2009, il y a 3968 adhérents à l'April. Et vous, où en êtes vous ? http://www.april.org/adherer?referent=Thomas%20SARBONI+(tsarboni)

4 4

[aur-general] Removal of f2c
by Michele Mocciola 13 Jan '09

13 Jan '09

I created f2c package in the last days (http://aur.archlinux.org/packages.php?ID=23047) but after having installed I saw it's not compatible with gfortran (it's fully compatible only with g77 that isn't supported by Archlinux). So I think it can be safely removed. Thanks.

2 1

[aur-general] Orphans packages list
by Andrea Scarpino 12 Jan '09

12 Jan '09

Hi TUs, now that I'm a DEV I'll help Pierre with KDE maintenance, so I prefer to have not packages who needs some Gnome depends to give all myself to KDE. This is the list of packages who I orphaned: * alexandria (if you want you can adopt all ruby-* packages who are required by alexandria) * awn-extras-applets * elisa-base ** elisa-plugins ** pigment ** python-cssutils ** python-pigment ** twisted-web2 ** xdg-user-dirs * gnuconcept ** diacanvas * gtk2_prefs * screenlets * sensors-applet * soundconverter * striim There are others orphans packages in community: * gputils (required by ktechlab [sergej]) * libxml-perl * mhwaveedit * portaudio (required by espeak [partition]) * portaudio_cpp (required by portaudio) * python-jinja (required by python-sphinx [dsa]) * rutilt * shapelib (required by gen2shp and gpsmanshp [dtw]) * vamps * xgl Regards -- Andrea `BaSh` Scarpino Arch Linux Developer

3 3

[aur-general] Removal of Bogus package.
by KalasMannen 12 Jan '09

12 Jan '09

Hi! Can anyone help me remove a bogus package i accidentily uploaded to the AUR? It's located at http://aur.archlinux.org/packages.php?ID=22825, and is basiclly just an upload of the official kernel26 PKGBUILD from svn. Would be greatly appreciated! /Magnus

2 1

[aur-general] [unsupported] Request for Orphaning of Packages Owned by Shinlun
by Ray Rashif 11 Jan '09

11 Jan '09

Hello list As some of you may know, Shinlun has resigned from being a TU due to other commitments and thus is very busy. As such, he currently (as a normal user) is the owner of more than 70 packages in [unsupported], of which quite a number have been flagged out-of-date for some time. He cannot be reached via e-mail as of this date; he may not be having time to check his Linux-related mailboxes. Regardless of the status of the packages, I am willing to adopt the following 10 if a TU could aid us by disowning them on-behalf: ardourvst dssi-vst gigedit libgig liblscp linuxsampler qsampler qtractor traverso wineasio Thanks and regards.

2 1

[aur-general] The search engine needs improvements
by Olivier Duclos 11 Jan '09

11 Jan '09

Hi there, So yesterday I was looking if someone had already made a pkgbuild for the rar archiver. I typed 'rar' in the search engine and got 1224 matches. Since rar wasn't at the top of the results, I thought it didn't exist and created it under the name 'rar-official'. And this morning, I receive a message telling me there is already a pkgbuild for rar. *Sigh* Now, I agree that I could have searched a little longer, but that doesn't change the fact that the search engine is too basic and should at least show the exact match in first position. That said, could someone delete the rar-official package please ? Thank you. -- -OD

6 7

Re: [aur-general] [Fwd: AUR Comment for]
by Loui Chang 11 Jan '09

11 Jan '09

On Sat, Jan 10, 2009 at 03:11:37PM +1000, Allan McRae wrote: > Anybody know what is going on here? I have received five of these so far. > > Allan > > -------- Original Message -------- > Subject: AUR Comment for > Date: Fri, 9 Jan 2009 23:54:04 -0500 (EST) > From: aur-notify(a)archlinux.org > Reply-To: nobody(a)archlinux.org > > > > Author: donvla > > From http://aur.archlinux.org/packages.php?ID= > > test > > --- > If you no longer wish to receive notifications about this package, > please go the the above package page and click the UnNotify button. It's a known bug, but we haven't figured out the cause. I guess we could ask donvla what he/she was up to.

2 1

Re: [aur-general] [Fwd: AUR Comment for]
by solsTiCe d'Hiver 10 Jan '09

10 Jan '09

Le samedi 10 janvier 2009 à 15:11 +1000, Allan McRae a écrit : > I have received five of these so far. me too and 2 more from BaSh.

3 2

[aur-general] Can not upload package to community
by Sergej Pupykin 10 Jan '09

10 Jan '09

Hi, I can not upload package, what happens? $ communitypkg /usr/bin/tupkg:22: DeprecationWarning: the md5 module is deprecated; use hashlib instead import md5 hangs here

3 2

[aur-general] Integrity Check i686 of community
by Xavier 10 Jan '09

10 Jan '09

===================================== = Integrity Check i686 of community = ===================================== Performing integrity checks... ==> parsing pkgbuilds ==> checking mismatches ==> checking archs ==> checking dependencies ==> checking makedepends ==> checking for circular dependencies Missing PKGBUILDs ------------------- community/devel/idutils community/science/mrbayes community/science/primer3 community/x11/twcw Missing Dependencies ---------------------- perl-text-vfile-asdata --> 'perl-class-accessor-chained' perl-pod-coverage --> 'perl-devel-symdump>=2.01' perl-test-base --> 'perl-spiffy>=0.30' eclipse-ve --> 'eclipse<3.3' flumotion --> 'twisted-web' perl-xml-dom --> 'libxml-perl>=0.07' perl-svn-mirror --> 'perl-class-accessor' gg2 --> 'arts' perl-datetime-set --> 'perl-set-infinite>=0.59' shp2svg --> 'perl-math-round' ktechlab --> 'gpsim' perl-test-mockobject --> 'perl-universal-can>=1.11' perl-test-mockobject --> 'perl-universal-isa>=0.06' Missing Makedepends --------------------- arch-wiki-docs --> 'json-xs' perl-text-vfile-asdata --> 'perl-class-accessor-chained' cgmail --> 'python-distutils-extra-bzr' perl-svn-mirror --> 'perl-class-accessor' gensplash --> 'klibc-beyond' Summary --------- Missing PKGBUILDs: 4 Invalid PKGBUILDs: 0 Mismatching PKGBUILD names: 0 Duplicate PKGBUILDs: 0 Invalid archs: 0 Missing (make)dependencies: 18 Repo hierarchy problems: 0 Circular dependencies: 0

3 3

[aur-general] [Fwd: AUR Comment for]
by Allan McRae 10 Jan '09

10 Jan '09

Anybody know what is going on here? I have received five of these so far. Allan -------- Original Message -------- Subject: AUR Comment for Date: Fri, 9 Jan 2009 23:54:04 -0500 (EST) From: aur-notify(a)archlinux.org Reply-To: nobody(a)archlinux.org Author: donvla >From http://aur.archlinux.org/packages.php?ID= test --- If you no longer wish to receive notifications about this package, please go the the above package page and click the UnNotify button.

1 0

Re: [aur-general] Discussion period - Moving [community] to use same system as main repos
by stefan-husmann＠t-online.de 10 Jan '09

10 Jan '09

-----Original Message----- > Date: Fri, 09 Jan 2009 23:09:30 +0100 > Subject: Re: [aur-general] Discussion period - Moving [community] to > use same system as main repos > From: "Aaron Griffin" > To: "AUR general" > On Fri, Jan 9, 2009 at 3:41 PM, stefan-husmann(a)t-online.de > wrote: > > And if the devels decide to switch from cvs to svn the TUs > > would have to alter their tools anyway, regardless of any proposal. > > There are goals behind this first step. > > This is 100% incorrect. We *did* switch to SVN a long time ago and > left community in the dust. Community is still (sadly) CVS-based. No > one cares about the community tools. That's the big thing here. > Everyone just wants to use it. I know *I'm* not going to go out of my > way to fix community issues when I don't even use community on a > regular basis. If community tracked the official tools, you would get > the benefit of work that is done by people who care about the tools. > Okay, if it is only the move from one tool to another then let 's do it. But what I wanted to make clear is that I do not agree with all the reasons on the wiki for doing so. > I always thought that Arch users used Arch because they cared about > things from a technical point of view. Why did this become a political > issue? Can you explain what you see going wrong here? I tried to explain that in my first post. This is a community driven distro, as often mentioned in the forums, and to be that it needs contact between users who want to use makepkg and other users who, trusted or not, have more experience in packaging. It should not be first goal of a TU to become a Developer, but to help people in AUR and to put well written and popular packages to a repo. > Like, let's assume we go through with the proposal. Things are "decoupled" and all > that fun stuff. What do you lose? What do users lose? > Please do not name something "fun stuff" just because you do not agree. It is no fun for me. That is not the way people should discuss things. I think I made clear that I am afraid to loose contact to the users. Loui said something that led me to the conclusion that this fears may be not well founded. Regards Stefan

4 4

Re: [aur-general] Discussion period - Moving [community] to use same system as main repos
by stefan-husmann＠t-online.de 09 Jan '09

09 Jan '09

-----Original Message----- > Date: Fri, 09 Jan 2009 21:25:48 +0100 > Subject: Re: [aur-general] Discussion period - Moving [community] to > use same system as main repos > From: "Aaron Griffin" > To: "stefan-husmann(a)t-online.de" , > "Discussion about the Arch User Repository (AUR)" > > I don't think this one is about "political consistency" - this > proposal is more about technical superiority. It's a technically > better move, so the proposal says "ok, screw the politics" > > > > <* There'll be fewer tools to support, since Trusted Users would > > then use the same tools as Arch developers, but with reduced > > permissions (only permission to write to the [community] repository) > > > > This is a very minor point to me. I do not know how hard it is to > > maintain these tools, but is only a concern of very few people. > > > > This is a very very BIG point. I remember back when pacman added in > new sizes, so that one could easilly see "total unpacked size" from > new packages. The community repo did not have these sizes added in, so > the numbers were treated as 0. You'd get things like: > Total Download Size: 300MB > Total Installed Size: 7MB > And people would yell and complain and file bug reports. This *only* > happened because we have different tools managing the community repo > as compared to the official repos (which stay up-to-date with regard > to pacman changes, as much as possible) > > > <* It'll be easier to migrate from being a Trusted User to a > > developer, since all the repositories would be using the same > > infrastructure. A simple permissions change, and they could be > > uploading packages to [core] or [extra]. > > > > I have absolutely no ambitions to becaome a developer. This point > > leads back to the first point under the "Detriments" section. If a > > TU wants to become a developer, he or she has do move his or her > > packages once, or even leave them in community, so the benefits are > > small. IMHO this point has to be moved to > > the "Detriments" section. > > > > I think the point here was more about the actual _people_, not the > packages. If JoeSchmoe becomes a developer, he has no extra learning > to do and can begin work much easier. > > > <* [community] would naturally become more decoupled from the AUR. > > Packages in [community] would become visible on the main Arch > > website, giving greater visibility to [community]. Also the search > > function on the website would then be able to search across all the > > repositories. > > > > This is clearly a detriment to me. > > > > Wait... can you explain how this is a detriment? > > > < * The AUR code becomes greatly simplified, making code > > refactoring or rewrites easier. > > > > < * The server daemon (tupkgupdate.py) for adding packages to > > [community] and other associated cruft which has been lying around > > for ages can be got rid of. > > > > Cannot comment > > > > This is one of the most important points here. The backend managing > the community repo is, quite frankly, painful. It causes us way more > harm than the official repos ever had. Getting rid of this is the sole > reason I think this entire thing is work it. > > I think we're mixing up a lot of issues here. Arch has always striven > for _technical_ superiority. Recently, we've had way too much talk of > politics and autonomy and all this other cruft and bureaucracy. The > simple fact is: this is a technically superior choice. > > Just my 17 cents. > > Hello, I cannot speak of the technical merits of such a move. Technically spoken it may be useful. But I have strong issues against the goals with which this proposal is underlined and that many people seem to have in mind. Trusted Users are in first line Users and not small developers. I do not want [community] be closer to [extra], I want it as close to AUR as it is now. I want people to comment my packages without having to write a bug report. > I don't think this one is about "political consistency" - this > proposal is more about technical superiority. It's a technically > better move, so the proposal says "ok, screw the politics" You are right regarding the proposal itself -- it is only about introducing a chain of tools replacing another chain of tools. But if that is the only thing that comes up here it would not even be worth a proposal. And if the devels decide to switch from cvs to svn the TUs would have to alter their tools anyway, regardless of any proposal. There are goals behind this first step. <* [community] would naturally become more decoupled from the AUR. > > Packages in [community] would become visible on the main Arch > > website, giving greater visibility to [community]. Also the search > > function on the website would then be able to search across all the > > repositories. > > > > This is clearly a detriment to me. > > > > Wait... can you explain how this is a detriment? > The detriment is in the first sentence of that paragraph. I think I explained my opinion about that. I have nothing against community packages showing up on www.archlinux.org directly. In fact this is already the case on www.archlinux.de. You can even see a complete filelist for each pakage in community there. So I think there is no need to switch to devtools just for that reason. Ask Pierre how he implemented it. Regards Stefan

2 1

Re: [aur-general] Discussion period - Moving [community] to use same system as main repos
by stefan-husmann＠t-online.de 09 Jan '09

09 Jan '09

-----Original Message----- > Date: Fri, 09 Jan 2009 18:33:38 +0100 > Subject: [aur-general] Discussion period - Moving [community] to use > same system as main repos > From: Allan McRae > To: "Discussion about the Arch User Repository (AUR)" > > 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 . > > Hello, I have been thinking about the detriments and benefits and her are my comments: >Detriments >* It might affect the autonomy of Trusted Users. This is a big point to me. One very important reason for me to use Arch Linux is the existence of a great community contributing packages and the possibility to get them to a semi official repo in an easy way. >*and this is a big change from the way we've been used to. That is true but only concerns our, the TU's, comforts. So it is not that important, we are all able to learn. >* The effort to make the transition happen is not trivial. I cannot imagine how complicated it would be. >*You'd lose votes for community packages. Well, we did just have a proposal in which one of the prerequisites for putting a package to [community] was the number of votes. Votes are also an indicator that users want a package to be kept in [community]. Strengthen the rule of votes in one proposal and weaken it in the next one is not an consistent attitude. >* You'd lose package comments and notifications. This is also important to me. It is much easier to write a comment than to use a bugtracker for users. >* Combining community packages with official packages will contribute a performance hit for all repos when dealing with >build files. Cannot comment because i do not get the point. <* There'll be fewer tools to support, since Trusted Users would then use the same tools as Arch developers, but with reduced permissions (only permission to write to the [community] repository) This is a very minor point to me. I do not know how hard it is to maintain these tools, but is only a concern of very few people. <* It'd be much easier to create and maintain a [community-testing] repository (or even the [testing] repository, if it's possible to cleanly separate the relevant permissions). A testing repository for [community] would be a great help in doing rebuilds. I do not see that this is very important. I did not need such a repo up to now and most probably wont use it. <* It'll be easier to migrate from being a Trusted User to a developer, since all the repositories would be using the same infrastructure. A simple permissions change, and they could be uploading packages to [core] or [extra]. I have absolutely no ambitions to becaome a developer. This point leads back to the first point under the "Detriments" section. If a TU wants to become a developer, he or she has do move his or her packages once, or even leave them in community, so the benefits are small. IMHO this point has to be moved to the "Detriments" section. <* [community] would naturally become more decoupled from the AUR. Packages in [community] would become visible on the main Arch website, giving greater visibility to [community]. Also the search function on the website would then be able to search across all the repositories. This is clearly a detriment to me. < * The AUR code becomes greatly simplified, making code refactoring or rewrites easier. < * The server daemon (tupkgupdate.py) for adding packages to [community] and other associated cruft which has been lying around for ages can be got rid of. Cannot comment So in my opinion at now the benefits are small and the goals are not mine. A clear -1 from me. Regards Stefan

3 5

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