Re: [aur-general] AUR and unsuported architectures
On 31/05/12 01:58, Hugo Osvaldo Barrera wrote: > Hi, > > I've recently seen some comments in AUR, where a user points out that X > package works well on powerpc/arm. > > I was wondering what's the general approach given to these architectures > on AUR; since AUR is unsupported, is it ok to add these architectures to > the PKGBUILD's arch array? > > If it is ok, is it *advised* to do so when apropriate? > Supported architectures should see absolutely no change regarding these > packages, and unsupported one will benefit from it. > > Again, being AUR unsupported anyway, I see nothing bad out of this, but > I'd like to know the TU's stance on this, especially since I'm about to > install archlinuxppc on one of my laptops. :) > > Cheers, thanks, > When I first though about it, I wanted to say "why not", it doesn't hurt the functioning of the normal i686,x86_64 packages. Except there might be a few drawbacks: * Become a place where ARM/PPC/* will look for support * ARM/PPC/* Folks might want to add patches specific for their architecture to AUR packages. -- Jelle van der Waa
[aur-general] Signoff report for [community-testing]
=== Signoff report for [community-testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 1 new package in last 24 hours * 0 known bad packages * 0 packages not accepting signoffs * 0 fully signed off packages * 143 packages missing signoffs * 0 packages older than 14 days (Note: the word 'package' as used here refers to packages as grouped by pkgbase, architecture, and repository; e.g., one PKGBUILD produces one package per architecture, even if it is a split package.) == New packages in [community-testing] in last 24 hours (1 total) == * systemd-arch-units-20120528-3 (any) == Incomplete signoffs for [community] (141 total) == * systemd-arch-units-20120528-3 (any) 0/2 signoffs * collectd-5.1.0-2 (i686) 0/2 signoffs * conntrack-tools-1.2.0-1 (i686) 0/2 signoffs * courier-mta-0.68.0-2 (i686) 0/2 signoffs * eeze-svn-69825-2 (i686) 0/2 signoffs * ekg2-0.3.1-4 (i686) 0/2 signoffs * flightgear-2.6.0-5 (i686) 0/2 signoffs * freeradius-2.1.12-6 (i686) 0/2 signoffs * inn-2.5.2-10 (i686) 0/2 signoffs * kvirc-4.0.4-5 (i686) 0/2 signoffs * libcec-1.6.3-1 (i686) 0/2 signoffs * libvirt-0.9.12-8 (i686) 0/2 signoffs * linux-tools-3.4-2 (i686) 0/2 signoffs * multipath-tools-0.4.9-8 (i686) 0/2 signoffs * ndiswrapper-1.57-12 (i686) 0/2 signoffs * pcsc-perl-1.4.12-3 (i686) 0/2 signoffs * pcsclite-1.8.3-3 (i686) 0/2 signoffs * perl-berkeleydb-0.50-3 (i686) 0/2 signoffs * perl-class-methodmaker-2.18-6 (i686) 0/2 signoffs * perl-clone-0.31-5 (i686) 0/2 signoffs * perl-crypt-blowfish-2.12-5 (i686) 0/2 signoffs * perl-crypt-des-2.05-5 (i686) 0/2 signoffs * perl-curses-1.28-5 (i686) 0/2 signoffs * perl-data-structure-util-0.15-6 (i686) 0/2 signoffs * perl-datetime-0.72-2 (i686) 0/2 signoffs * perl-dbd-odbc-1.37-2 (i686) 0/2 signoffs * perl-dbd-pg-2.19.2-2 (i686) 0/2 signoffs * perl-dbd-sqlite2-0.33-9 (i686) 0/2 signoffs * perl-dbd-sybase-1.14-2 (i686) 0/2 signoffs * perl-device-serialport-1.04-4 (i686) 0/2 signoffs * perl-file-rsyncp-0.70-2 (i686) 0/2 signoffs * perl-fuse-0.14-2 (i686) 0/2 signoffs * perl-gd-2.46-3 (i686) 0/2 signoffs * perl-gnome2-wnck-0.16-6 (i686) 0/2 signoffs * perl-gssapi-0.28-6 (i686) 0/2 signoffs * perl-gstreamer-0.17-1 (i686) 0/2 signoffs * perl-gstreamer-interfaces-0.06-5 (i686) 0/2 signoffs * perl-gtk2-sexy-0.05-7 (i686) 0/2 signoffs * perl-gtk2-trayicon-0.06-9 (i686) 0/2 signoffs * perl-gtk2-webkit-0.09-3 (i686) 0/2 signoffs * perl-html-strip-1.06-8 (i686) 0/2 signoffs * perl-inline-java-0.53-4 (i686) 0/2 signoffs * perl-io-dirent-0.05-2 (i686) 0/2 signoffs * perl-io-tty-1.10-2 (i686) 0/2 signoffs * perl-json-xs-2.32-2 (i686) 0/2 signoffs * perl-libapreq2-2.13-3 (i686) 0/2 signoffs * perl-linux-pid-0.04-2 (i686) 0/2 signoffs * perl-mail-box-parser-c-3.006-8 (i686) 0/2 signoffs * perl-mail-transport-dbx-0.07-8 (i686) 0/2 signoffs * perl-net-dbus-1.0.0-2 (i686) 0/2 signoffs * perl-net-libidn-0.12-6 (i686) 0/2 signoffs * perl-package-stash-xs-0.25-2 (i686) 0/2 signoffs * perl-params-classify-0.013-2 (i686) 0/2 signoffs * perl-params-util-1.04-2 (i686) 0/2 signoffs * perl-params-validate-1.06-3 (i686) 0/2 signoffs * perl-string-crc32-1.4-8 (i686) 0/2 signoffs * perl-text-charwidth-0.04-8 (i686) 0/2 signoffs * perl-text-kakasi-2.04-9 (i686) 0/2 signoffs * perl-tie-hash-indexed-0.05-8 (i686) 0/2 signoffs * perl-tk-tablematrix-1.23-9 (i686) 0/2 signoffs * perl-www-curl-4.15-3 (i686) 0/2 signoffs * perl-xml-libxml-1.98-1 (i686) 0/2 signoffs * perl-xml-libxslt-1.77-1 (i686) 0/2 signoffs * perl-xmms-0.12-8 (i686) 0/2 signoffs * pork-0.99.8.1-6 (i686) 0/2 signoffs * rxvt-unicode-9.15-3 (i686) 0/2 signoffs * spacefm-0.7.6-3 (i686) 0/2 signoffs * vhba-module-20120422-1 (i686) 0/2 signoffs * virtualbox-modules-4.1.16-2 (i686) 0/2 signoffs * xbmc-11.0-4 (i686) 0/2 signoffs * znc-0.206-2 (i686) 0/2 signoffs * collectd-5.1.0-2 (x86_64) 0/2 signoffs * conntrack-tools-1.2.0-1 (x86_64) 0/2 signoffs * courier-mta-0.68.0-2 (x86_64) 0/2 signoffs * eeze-svn-69825-2 (x86_64) 0/2 signoffs * ekg2-0.3.1-4 (x86_64) 0/2 signoffs * flightgear-2.6.0-5 (x86_64) 0/2 signoffs * freeradius-2.1.12-6 (x86_64) 0/2 signoffs * inn-2.5.2-10 (x86_64) 0/2 signoffs * kvirc-4.0.4-5 (x86_64) 0/2 signoffs * libcec-1.6.3-1 (x86_64) 0/2 signoffs * libvirt-0.9.12-8 (x86_64) 0/2 signoffs * linux-tools-3.4-2 (x86_64) 0/2 signoffs * multipath-tools-0.4.9-8 (x86_64) 0/2 signoffs * ndiswrapper-1.57-12 (x86_64) 0/2 signoffs * pcsc-perl-1.4.12-3 (x86_64) 0/2 signoffs * pcsclite-1.8.3-3 (x86_64) 0/2 signoffs * perl-berkeleydb-0.50-3 (x86_64) 0/2 signoffs * perl-class-methodmaker-2.18-6 (x86_64) 0/2 signoffs * perl-clone-0.31-5 (x86_64) 0/2 signoffs * perl-crypt-blowfish-2.12-
[aur-general] Byobu has been orphaned
Hello all, AnotherZero, the maintainer for byobu, has orphaned the package. I'm afraid that I'm in the same boat as him, I don't really have time to do it (in my case learn how to) myself. Is anyone else up for maintaining it? If not, I will attempt to learn the skills necessary to get it packaged, however with my current schedule that will take a while. Any takers? PS anotherZero, if you're reading this, thanks so much for taking the time to maintain it for as long as you did!
Re: [aur-general] Byobu has been orphaned
I would like to start getting into maintaning but I've never done it before, that's why I'm here watching the conversations and watching the builds progress. Federico Cinelli @ 213.985.9643 CINELLI Motorsports LLC CINELLI Thoughts @ http://www.CINELLIthoughts.com/ Stay true. On 05/31/2012 01:16 AM, Alishams Hassam wrote: Hello all, AnotherZero, the maintainer for byobu, has orphaned the package. I'm afraid that I'm in the same boat as him, I don't really have time to do it (in my case learn how to) myself. Is anyone else up for maintaining it? If not, I will attempt to learn the skills necessary to get it packaged, however with my current schedule that will take a while. Any takers? PS anotherZero, if you're reading this, thanks so much for taking the time to maintain it for as long as you did!
Re: [aur-general] AUR and unsuported architectures
And could it potentially lead to AUR packages uploaded without either 'i686' or 'x86_64' set? On Thu, May 31, 2012 at 09:38:05AM +0200, Jelle van der Waa wrote: > On 31/05/12 01:58, Hugo Osvaldo Barrera wrote: >> Hi, >> >> I've recently seen some comments in AUR, where a user points out that X >> package works well on powerpc/arm. >> >> I was wondering what's the general approach given to these architectures >> on AUR; since AUR is unsupported, is it ok to add these architectures to >> the PKGBUILD's arch array? >> >> If it is ok, is it *advised* to do so when apropriate? >> Supported architectures should see absolutely no change regarding these >> packages, and unsupported one will benefit from it. >> >> Again, being AUR unsupported anyway, I see nothing bad out of this, but >> I'd like to know the TU's stance on this, especially since I'm about to >> install archlinuxppc on one of my laptops. :) >> >> Cheers, thanks, >> > When I first though about it, I wanted to say "why not", it doesn't hurt > the functioning of the normal i686,x86_64 packages. > > Except there might be a few drawbacks: > * Become a place where ARM/PPC/* will look for support > * ARM/PPC/* Folks might want to add patches specific for their > architecture to AUR packages. > > > -- > Jelle van der Waa
Re: [aur-general] AUR and unsuported architectures
On 31 May 2012 17:38, Jelle van der Waa wrote: > When I first though about it, I wanted to say "why not", it doesn't hurt > the functioning of the normal i686,x86_64 packages. I thought the same, but after thinking more... While AUR is "unsupported", the project/site is still an official item. In my mind, it doesn't make sense to include unofficial platforms in official infrastructure, supported or not. We don't encourage documentation of other platforms in our wiki (do we?)
Re: [aur-general] AUR and unsuported architectures
On Thu, May 31, 2012 at 1:10 PM, Phillip Smith wrote: > I thought the same, but after thinking more... While AUR is > "unsupported", the project/site is still an official item. > > In my mind, it doesn't make sense to include unofficial platforms in > official infrastructure, supported or not. I agree. -- Sébastien Luttringer www.seblu.net
Re: [aur-general] AUR and unsuported architectures
On 2012-05-31 08:10, Phillip Smith wrote: > On 31 May 2012 17:38, Jelle van der Waa wrote: >> When I first though about it, I wanted to say "why not", it doesn't hurt >> the functioning of the normal i686,x86_64 packages. > > I thought the same, but after thinking more... While AUR is > "unsupported", the project/site is still an official item. > > In my mind, it doesn't make sense to include unofficial platforms in > official infrastructure, supported or not. > > We don't encourage documentation of other platforms in our wiki (do we?) While I'd wish this weren't true, your argument does make perfect sense, so I guess it's best to keep AUR clear of these architectures. It may be a bit of chicken-and-egg, though. The ppc/arm userbase might grow if arch is seen stable enough and seems to have sufficient packages, possibly making it worth being supported, but the lack of infrastructure won't make that so possible. In any case, it's good to know the official stance so I know what to do in these sort of cases. Thanks, -- Hugo Osvaldo Barrera
[aur-general] Two Frozen Synapse packages
Hello, I messed up looking if the package already existed before uploading a package I'd made, so now there's 2 packages for the game Frozen Synapse. gadget3000's package [1] has 25 votes, has been around since last September and has been flagged out of date for about a week. I haven't contacted him. My packages [2] was just now uploaded using the new release of the game. It makes sense for mine to be deleted. However gadget3000's PKGBUILD uses either a local file as the game package or downloads it from humble bundle, where the source package will never be updated. Is it simply the case that my package should be deleted and gadget3000's package should be updated to not using humble bundle any more? 1: https://aur.archlinux.org/packages.php?ID=52758 2: https://aur.archlinux.org/packages.php?ID=59663 Thanks, Sid signature.asc Description: OpenPGP digital signature
Re: [aur-general] Not the way to go: teamviewer and teamviewer-stable
Dinsdag 29 Mei 2012 om 04:30 (CEST +0200) schreef Federico Cinelli: Have you guys been in touch with him yet? I'm sure someone else will gladly take over the package if he's no longer interested Federico Cinelli @ 213.985.9643 CINELLI Motorsports LLC CINELLI Thoughts @ http://www.CINELLIthoughts.com/ Stay true. On 05/28/2012 06:03 PM, José Valecillos wrote: Is stupid, he is just eagerness for take over the package. I use teamviewer and the current maintainer update the package very often (more than I'd like). 2012/5/28 Christian Stadegaart : Maandag 28 Mei 2012 om 21:41 (CEST +0200) schreef Andrea Scarpino: On Monday 28 May 2012 20:57:58 Christian Stadegaart wrote: In my opinion, if Hilinus isn't maintaining properly, the package should be orphaned and then maintained by someone else, perhaps tlm. There probably is a standard protocol for these kind of issues. Someone flagged the package as out-of-date at 13:34 GMT[1], and 20 minutes later tlm uploaded the new one. We should probably delete tlm's package[2] instead. [1] "This package has been flagged out of date. (Mon, 28 May 2012 13:34:02 +)" https://aur.archlinux.org/packages.php?ID=36481 [2] https://aur.archlinux.org/packages.php?ID=59577 I agree, the older package is version 7.0.9348-1, the newer one by tlm is 7.0.9350-3, which is just slightly newer. -- Christian Stadegaart Guys / gals, Can someone with administrative power either merge these two packages or delete tlm's package instead? These two packages will confuse (new) AUR/Teamviewer users and Hilinus' package was always and is updated just fine. Thanks! -- Christian Stadegaart
Re: [aur-general] Two Frozen Synapse packages
On Thu, May 31, 2012 at 5:56 PM, Sid Karunaratne wrote: > Hello, > I messed up looking if the package already existed before uploading a > package I'd made, so now there's 2 packages for the game Frozen Synapse. > > gadget3000's package [1] has 25 votes, has been around since last > September and has been flagged out of date for about a week. I haven't > contacted him. Contact him if you want fix PKGBUILD issues and take maintainership. Your package was removed. -- Sébastien Luttringer www.seblu.net
Re: [aur-general] Not the way to go: teamviewer and teamviewer-stable
On Mon, May 28, 2012 at 8:57 PM, Christian Stadegaart wrote: > I noticed that tlm created teamviewer-stable package since, in his opinion > Hilinus, the current maintainer of Teamviewer isn't doing a good job. > I removed tlm package. Everyone seems happy with the current maintainer. -- Sébastien Luttringer www.seblu.net
Re: [aur-general] Not the way to go: teamviewer and teamviewer-stable
Donderdag 31 Mei 2012 om 22:45 (CEST +0200) schreef Seblu: On Mon, May 28, 2012 at 8:57 PM, Christian Stadegaart wrote: I noticed that tlm created teamviewer-stable package since, in his opinion Hilinus, the current maintainer of Teamviewer isn't doing a good job. I removed tlm package. Everyone seems happy with the current maintainer. Thank you! -- Christian Stadegaart
[aur-general] deletion request: codelite-x86_64
good day, please remove codelite-x86_64 [4] from aur (redundant). details below from my chat with the maintainer. regards, nem [4] http://aur.archlinux.org/packages.php?ID=56102 - Forwarded message from Richard Didier - Date: Fri, 01 Jun 2012 00:49:56 +0200 From: Richard Didier To: n...@ikitten.co.uk Subject: Re: codelite x86_64 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 ok, i disown package. regards, zeph Le 01/06/2012 00:33, n...@ikitten.co.uk a écrit : > hej, > > thanks for your reply. > disowning will be ok. i will send a deletion request to the aur-general > mailinglist with our mails attatched. you can't delete it yourself. > > if you want the latest development version of codelite, then use > codelite-svn [3]. even though it states an old revision in the title it > will download the latest version from svn and build it. i don't know if > there are issues compiling it though. > the codelite [1] package is the stable version and will get updated as > soon as a new stable version is released. > > regards, > nem > > > [3] http://aur.archlinux.org/packages.php?ID=32119 > > On Fri, Jun 01, 2012 at 12:17:01AM +0200, Richard Didier wrote: >> Hello, >> I can Disown Package, but i can not delete (or i do not know how !) >> I tested your package it works (now, when i create other package i >> have build error ...) >> but now when i lauch codelite, he say a new version is available. >> >> regards, >> zeph >> >> Excuse for my bad english ... >> >> Le 31/05/2012 20:30, n...@ikitten.co.uk a écrit : >>> hi there. >>> >>> i saw you duplicated the codelite package to add another 64bit package >>> [2]. this is not necessary because the stable package provided [1] does >>> work perfectly on 64bit machines with wxgtk from the official extra >>> repository. please remove the package as it is redunant and confusing >>> for new users. >>> >>> regards, >>> nem >>> >>> >>> [1] https://aur.archlinux.org/packages.php?ID=18809 >>> [2] https://aur.archlinux.org/packages.php?ID=56102 - End forwarded message -
Re: [aur-general] deletion request: codelite-x86_64
On Fri, 1 Jun 2012 01:03:51 +0200 n...@ikitten.co.uk wrote: > good day, > > please remove codelite-x86_64 [4] from aur (redundant). details below > from my chat with the maintainer. > > regards, > nem Merged into codelite-bin [1] instead, as it is assimilable in purpose. codelite-bin is unmaintained, outdated and probably unnecessary, though. I'll delete it if no one choose to adopt and update it. Thanks. [1] https://aur.archlinux.org/packages.php?ID=40558 - speps - pgpfnm2ktHHT0.pgp Description: PGP signature
Re: [aur-general] AUR and unsuported architectures
On Thu 31 May 2012 09:56 -0300, Hugo Osvaldo Barrera wrote: > On 2012-05-31 08:10, Phillip Smith wrote: > > On 31 May 2012 17:38, Jelle van der Waa wrote: > >> When I first though about it, I wanted to say "why not", it doesn't hurt > >> the functioning of the normal i686,x86_64 packages. > > > > I thought the same, but after thinking more... While AUR is > > "unsupported", the project/site is still an official item. > > > > In my mind, it doesn't make sense to include unofficial platforms in > > official infrastructure, supported or not. > > > > We don't encourage documentation of other platforms in our wiki (do we?) > > While I'd wish this weren't true, your argument does make perfect sense, > so I guess it's best to keep AUR clear of these architectures. I'm not a TU, but I actually think allowing other architectures in the PKGBUILDs is a Good Thing. The AUR is supposed be be a place of less-restricted user contribution - where packages (and/or architectures?) that developers are not interested in can be submitted. > It may be a bit of chicken-and-egg, though. The ppc/arm userbase might > grow if arch is seen stable enough and seems to have sufficient > packages, possibly making it worth being supported, but the lack of > infrastructure won't make that so possible. Yes, I also see it as a way of welcoming the ppc/arm/etc userbase into the main Arch collective, and adding their technological distinctiveness to our own.
Re: [aur-general] AUR and unsuported architectures
On 01/06/12 02:31, Loui Chang wrote: > On Thu 31 May 2012 09:56 -0300, Hugo Osvaldo Barrera wrote: >> On 2012-05-31 08:10, Phillip Smith wrote: >>> On 31 May 2012 17:38, Jelle van der Waa wrote: When I first though about it, I wanted to say "why not", it doesn't hurt the functioning of the normal i686,x86_64 packages. >>> >>> I thought the same, but after thinking more... While AUR is >>> "unsupported", the project/site is still an official item. >>> >>> In my mind, it doesn't make sense to include unofficial platforms in >>> official infrastructure, supported or not. >>> >>> We don't encourage documentation of other platforms in our wiki (do we?) >> >> While I'd wish this weren't true, your argument does make perfect sense, >> so I guess it's best to keep AUR clear of these architectures. > > I'm not a TU, but I actually think allowing other architectures in the > PKGBUILDs is a Good Thing. The AUR is supposed be be a place of > less-restricted user contribution - where packages (and/or > architectures?) that developers are not interested in can be submitted. > Sure it's not a problem or against the rules. I'm just afraid that ARM users will use the AUR and then complain that stuff doesn't work. As I have seen with for example archbang and archlinuxarm questions on #archlinux. >> It may be a bit of chicken-and-egg, though. The ppc/arm userbase might >> grow if arch is seen stable enough and seems to have sufficient >> packages, possibly making it worth being supported, but the lack of >> infrastructure won't make that so possible. > > Yes, I also see it as a way of welcoming the ppc/arm/etc userbase into > the main Arch collective, and adding their technological distinctiveness > to our own. > -- Jelle van der Waa
