- Aur-general - lists.archlinux.org

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

[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

[aur-general] Remove package
by Lukáš Jirkovský 05 Jan '09

05 Jan '09

I think package eclipse-kde (http://aur.archlinux.org/packages.php?ID=4493) should be removed because it's abandoned for a long time and it's functionality is already provided by eclipse-qt-integration.

1 0

[aur-general] Proposal: package's votes
by Vitaliy Berdinskikh 05 Jan '09

05 Jan '09

Hi all, I propose to make package's votes equal zero after update. All users vote when they update package. Maintainer has true statistic about package usage. Whan do you think about? -- Sincerely yours, Vitaliy Berdinskikh (Виталий Бердинских) xmpp:vitaliy@berdinskikh.in.ua <xmpp%253Avitaliy(a)berdinskikh.in.ua> skype:skipper.barbossa

7 6

[aur-general] Dependency conflicts in nvidia-utils-beta
by Dan Vratil 04 Jan '09

04 Jan '09

Hi, I'm maintaining nvidia-utils-beta [1] in AUR and tomorrow someone had again problem with the following conflict: nvidia-utils-beta requires xorg-server which requires libgl, but nvidia-utils- beta conflicts with libgl as it provides it's own libgl library. I added ligbl to provides=() array, but if you are installing nvidia-utils- beta on system with installed libgl, pacman does not solve that. I also tried to put 'libgl=180.11' to provides=() in hope, pacman will consider it as update of standart libgl (7.2 currently) but it is also not a solution. The only way is to pacman -Rd libgl and then to install nvidia-utils-beta, but I'd like to make it work without need of manually uninstalling libgl. I don't have any more ideas of solution so I'd like to ask you for some ideas. Thank you Dan [1] http://aur.archlinux.org/packages.php?ID=19224 -- --------------------------------- Dan Vrátil progdan(a)progdansoft.com ICQ 249163429 Jabber progdan(a)jabber.cz Tel. +420 732 326 870

2 1

[aur-general] Please, remove this package
by Robson Roberto Souza Peixoto 04 Jan '09

04 Jan '09

I put the wrong package name. http://aur.archlinux.org/packages.php?ID=8459 Thanks -- 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

2 2

Re: [aur-general] Proposal: package's votes
by stefan-husmann＠t-online.de 04 Jan '09

04 Jan '09

-----Original Message----- > Date: Sun, 04 Jan 2009 11:16:26 +0100 > Subject: Re: [aur-general] Proposal: package's votes > From: Evangelos Foutras > To: "Discussion about the Arch User Repository (AUR)" > > Vitaliy Berdinskikh wrote: > > Hi all, > > > > I propose to make package's votes equal zero after update. All users > > vote when they update package. Maintainer has true statistic about > > package usage. > > > > Whan do you think about? > > > > I don't believe that this is a good idea. People's votes go towards a > package and not a specific version of it. I highly doubt that anyone > (myself included) would bother to vote after each package upgrade. > Hello, I agree with Evangelos. People should and do vote if they want a package to go to or to stay in [community]. This decision is not version number specific. They simply would not vote again. Regards Stefan

1 0

[aur-general] Remove double: tomcat6-native
by Vitaliy Berdinskikh 04 Jan '09

04 Jan '09

Hi all, please remove my package tomcat6-native. -- Sincerely yours, Vitaliy Berdinskikh (Виталий Бердинских) xmpp:vitaliy@berdinskikh.in.ua <xmpp%253Avitaliy(a)berdinskikh.in.ua> skype:skipper.barbossa

2 1