[aur-general] Community Cleanup 2011.
I would like to propose moving all of the orphans in [community] to the aur by this Friday if no one has adopted them by then. If one of your packages needs an orphan as a dependency, you must adopt it. Orphans really deserve a maintainer and I would be more comfortable with the package having a maintainer in the aur then being an orphan in [community]. Community orphans: http://tinyurl.com/29lp5r6 Thanks and let the discussion begin!
I would like to propose moving all of the orphans in [community] to the aur by this Friday if no one has adopted them by then.
If one of your packages needs an orphan as a dependency, you must adopt it.
Orphans really deserve a maintainer and I would be more comfortable with the package having a maintainer in the aur then being an orphan in [community].
Community orphans: http://tinyurl.com/29lp5r6
Thanks and let the discussion begin! Can you provide a final list? I did this job some months ago and I don't think
On Monday 10 January 2011 08:35:30 Thomas Dziedzic wrote: that we have more orphans packages which can be moved. -- Andrea
Le Monday 10 January 2011 08:35:30, Thomas Dziedzic a écrit :
I would like to propose moving all of the orphans in [community] to the aur by this Friday if no one has adopted them by then.
If one of your packages needs an orphan as a dependency, you must adopt it.
Orphans really deserve a maintainer and I would be more comfortable with the package having a maintainer in the aur then being an orphan in [community].
Community orphans: http://tinyurl.com/29lp5r6
Thanks and let the discussion begin!
gdk-pixbuf cannot be moved to aur as it's a dependency of lazarus, maintain by Sergej. I guess Sergej should adopt it. ++
On Mon, Jan 10, 2011 at 9:41 AM, Laurent Carlier <lordheavym@gmail.com>wrote:
gdk-pixbuf cannot be moved to aur as it's a dependency of lazarus, maintain by Sergej.
I guess Sergej should adopt it.
Also let me point out that if you maintain package A and if the only reason package B is in [community] is because package B depends on package A then you should really either compile package A without support for package B or just maintain package B as well. --Kaiting. -- Kiwis and Limes: http://kaitocracy.blogspot.com/
At Mon, 10 Jan 2011 08:35:30 -0600, Thomas Dziedzic <gostrc@gmail.com> wrote:
I would like to propose moving all of the orphans in [community] to the aur by this Friday if no one has adopted them by then.
If one of your packages needs an orphan as a dependency, you must adopt it.
Orphans really deserve a maintainer and I would be more comfortable with the package having a maintainer in the aur then being an orphan in [community].
Community orphans: http://tinyurl.com/29lp5r6
Thanks and let the discussion begin!
There are no out-of-date orphans and there are no unassigned bugs in community section. Is there any reason of this cleanup?
On Monday 10 January 2011 18:47:04 Sergej Pupykin wrote:
There are no out-of-date orphans and there are no unassigned bugs in community section. Is there any reason of this cleanup? Anyway this clean up count ~10 packages.
-- Andrea
On Mon, Jan 10, 2011 at 9:47 AM, Sergej Pupykin <ml@sergej.pp.ru> wrote:
At Mon, 10 Jan 2011 08:35:30 -0600, Thomas Dziedzic <gostrc@gmail.com> wrote:
I would like to propose moving all of the orphans in [community] to the aur by this Friday if no one has adopted them by then.
If one of your packages needs an orphan as a dependency, you must adopt it.
Orphans really deserve a maintainer and I would be more comfortable with the package having a maintainer in the aur then being an orphan in [community].
Community orphans: http://tinyurl.com/29lp5r6
Thanks and let the discussion begin!
There are no out-of-date orphans and there are no unassigned bugs in community section. Is there any reason of this cleanup?
This is more of a assigning responsibility to a package sort of thing, as I said, I would rather have it be in aur and have a maintainer then be in community and be an orphan.
On Mon, Jan 10, 2011 at 11:11 AM, Thomas Dziedzic <gostrc@gmail.com> wrote:
At Mon, 10 Jan 2011 08:35:30 -0600, Thomas Dziedzic <gostrc@gmail.com> wrote:
This is more of a assigning responsibility to a package sort of thing, as I said, I would rather have it be in aur and have a maintainer then be in community and be an orphan.
I took python-gnupginterface. --Kaiting. -- Kiwis and Limes: http://kaitocracy.blogspot.com/
Hi Thomas, don't know what I have started...... I was just trying to report on a few issues I encountered while doing some tests with Grass (building 6.4 through ABS and Grass-svn through AUR). Now I am involved in a whole discussion on orphans, deadlines, responsabilities, assignments etc... Well just get back on the issue: * I managed to build grass 6.4.0-6 with your suggestion with devtools and 'extra-x86_64'. It gives me a packeage. Still don't understand why it does not fonction with the standards ABS-way; * It's clear why grass-svn in AUR is not working since it is not yet adjusted to the python 2.x and python 3.1 environment. I tried to adjust the PKGBUILD for grass-svn with the specific python lines from the PKGBUILD for grass 6.4 that worked (see above). I have attached this PKGBUILD to this message. Trying this in the clean chroot environment gives me an error in line 36 (does not recognize the svn command in the chroot env.) Well that's it. Wanted to post this info on the grass-svn aur page. But apperantly I don't have an account to post on aur pages. Sorry if I have started any annoying business, just wanted to be helpful with my experiences and trying to get stable GIS application under this wonderful distro Cheers, ________________________________ Huub Munstege BPE 2836 Bamako, Rep. du Mali Tel: +223 20226397 Port: +223 78370695 ________________________________ ________________________________ From: Thomas Dziedzic <gostrc@gmail.com> To: Discussion about the Arch User Repository (AUR) <aur-general@archlinux.org> Sent: Mon, January 10, 2011 4:11:32 PM Subject: Re: [aur-general] Community Cleanup 2011. On Mon, Jan 10, 2011 at 9:47 AM, Sergej Pupykin <ml@sergej.pp.ru> wrote:
At Mon, 10 Jan 2011 08:35:30 -0600, Thomas Dziedzic <gostrc@gmail.com> wrote:
I would like to propose moving all of the orphans in [community] to the aur by this Friday if no one has adopted them by then.
If one of your packages needs an orphan as a dependency, you must adopt it.
Orphans really deserve a maintainer and I would be more comfortable with the package having a maintainer in the aur then being an orphan in [community].
Community orphans: http://tinyurl.com/29lp5r6
Thanks and let the discussion begin!
There are no out-of-date orphans and there are no unassigned bugs in community section. Is there any reason of this cleanup?
This is more of a assigning responsibility to a package sort of thing, as I said, I would rather have it be in aur and have a maintainer then be in community and be an orphan. Insert mode
On Monday 10 January 2011 11:26:00 Huub Munstege wrote:
This is more of a assigning responsibility to a package sort of thing, as I said, I would rather have it be in aur and have a maintainer then be in community and be an orphan. Grass is maintained by Thomas and you already reported your problem on flyspray (FS#22379). So tell me what's the goal of this off topic.
-- Andrea
On 10.01.2011 15:35, Thomas Dziedzic wrote:
I would like to propose moving all of the orphans in [community] to the aur by this Friday if no one has adopted them by then.
If one of your packages needs an orphan as a dependency, you must adopt it.
Orphans really deserve a maintainer and I would be more comfortable with the package having a maintainer in the aur then being an orphan in [community].
Community orphans: http://tinyurl.com/29lp5r6
Thanks and let the discussion begin! I adopted silly for cegui.
Adopted fcgiwrap and spawn-fcgi.
On Tue, Jan 11, 2011 at 4:57 AM, Lukas Fleischer <archlinux@cryptocrack.de> wrote:
Adopted fcgiwrap and spawn-fcgi.
54 orphans left. Please try to see if any of your packages depend on an orphan and adopt them, I see plenty of those.
participants (8)
-
Andrea Scarpino
-
Huub Munstege
-
Kaiting Chen
-
Laurent Carlier
-
Lukas Fleischer
-
Sergej Pupykin
-
Sven-Hendrik Haase
-
Thomas Dziedzic