- Aur-general - lists.archlinux.org

[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