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 je...@vdwaa.nl 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
[aur-general] Signoff report for [community-testing]
=== Signoff report for [community-testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 0 new packages 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.) == Incomplete signoffs for [community] (141 total) == * systemd-arch-units-20120528-3 (any) 1/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-5 (x86_64) 0/2 signoffs * perl-crypt-des-2.05-5 (x86_64) 0/2 signoffs * perl-curses-1.28-5 (x86_64)
[aur-general] deletion request: ibus-pinyin-libpinyin-git
ibus-pinyin-libpinyin-git has been replaced by ibus-libpinyin-git signature.asc Description: This is a digitally signed message part
[aur-general] Idea for AUR improvement
Hi there! Few days ago I’ve installed Archlinux on my laptop again. One of the first changes I’ve noticed in my *.archlinux.org accounts was loosing all packages I was maintaining in AUR. It’s completely understandable because I was the one to say in one of my comments that I hope to never use Arch again… but here I am having Arch on the second partition, next to Gentoo. The idea is to add some tracking of AUR package maintainers (I’m not sure if there isn’t some system like this first part already). If they have more than some number of packages out of date and they haven’t been logged in some time lets orphan their packages. This is how it is working now but manually. The next step is retrieval. If our maintainer logged in again and he’s pushing some new packages to AUR lets bring him his packages. But not all, only those which are still orphaned. Such automation will be IMO a big improvement to the whole system. Just an idea, but if anyone is interested in implementing it I’ll be glad to help. -- Regards Marcin 'sirmacik' Karpezo http://sirmacik.net
Re: [aur-general] Idea for AUR improvement
On Jun 1, 2012 10:03 PM, Marcin apos;sirmacikapos; Karpezo mar...@karpezo.pl wrote: Hi there! Few days ago I’ve installed Archlinux on my laptop again. One of the first changes I’ve noticed in my *.archlinux.org accounts was loosing all packages I was maintaining in AUR. It’s completely understandable because I was the one to say in one of my comments that I hope to never use Arch again… but here I am having Arch on the second partition, next to Gentoo. The idea is to add some tracking of AUR package maintainers (I’m not sure if there isn’t some system like this first part already). If they have more than some number of packages out of date and they haven’t been logged in some time lets orphan their packages. This is how it is working now but manually. The next step is retrieval. If our maintainer logged in again and he’s pushing some new packages to AUR lets bring him his packages. But not all, only those which are still orphaned. Such automation will be IMO a big improvement to the whole system. Just an idea, but if anyone is interested in implementing it I’ll be glad to help. -- Regards Marcin 'sirmacik' Karpezo http://sirmacik.net Somehow I don't see the stopped using arch for a long while and now coming back and wanting his packages back demographic to be significantly large...
Re: [aur-general] Idea for AUR improvement
Such tracking is usually done within the MAKEPKG file, e.g. [1]. It is indeed better practice but not mandatory. As long as we can contact the current maintainer, why the need of previous maintainer? Second it doesn't really matter who owns the package. We all contribute to Arch together and benefits from everyone's work as a whole. I understand your willingness to own your baby, but we're a community. As long as I know the package is well maintained, it doesn't make a big difference wether it's him or you. You can always contact the person and deal something with them if it can help you sleep better. Lastly, you can already pick any package orphaned and give it some love. AUR doesn't have (and I don't think it will ever have) any kind of automated system for that. That's why we are here, also it helps keep an eye on what's going on and take the good decisions. Please keep in mind I don't have the truth, I'm nowhere near TU rank here. I'm just speaking common sense. Alex. [1] http://aur.archlinux.org/packages/ac/ace/PKGBUILD On Fri, Jun 1, 2012 at 10:02 AM, Marcin 'sirmacik' Karpezo mar...@karpezo.pl wrote: Hi there! Few days ago I’ve installed Archlinux on my laptop again. One of the first changes I’ve noticed in my *.archlinux.org accounts was loosing all packages I was maintaining in AUR. It’s completely understandable because I was the one to say in one of my comments that I hope to never use Arch again… but here I am having Arch on the second partition, next to Gentoo. The idea is to add some tracking of AUR package maintainers (I’m not sure if there isn’t some system like this first part already). If they have more than some number of packages out of date and they haven’t been logged in some time lets orphan their packages. This is how it is working now but manually. The next step is retrieval. If our maintainer logged in again and he’s pushing some new packages to AUR lets bring him his packages. But not all, only those which are still orphaned. Such automation will be IMO a big improvement to the whole system. Just an idea, but if anyone is interested in implementing it I’ll be glad to help. -- Regards Marcin 'sirmacik' Karpezo http://sirmacik.net
[aur-general] Disown 2gis
Hello, 2gis package is out of date, maintainer does not answer. Please, disown the package. https://aur.archlinux.org/packages.php?ID=25266
Re: [aur-general] Disown 2gis
On Fri, Jun 1, 2012 at 9:04 PM, Mikhail Mikhailov yohan...@ngs.ru wrote: Hello, 2gis package is out of date, maintainer does not answer. Please, disown the package. https://aur.archlinux.org/packages.php?ID=25266 Done, thanks.
Re: [aur-general] Idea for AUR improvement
Dnia 2012-06-01, o godz. 12:11:06 Alex Belanger i.caught@gmail.com napisał(a): Such tracking is usually done within the MAKEPKG file, e.g. [1]. It is indeed better practice but not mandatory. As long as we can contact the current maintainer, why the need of previous maintainer? Second it doesn't really matter who owns the package. We all contribute to Arch together and benefits from everyone's work as a whole. I understand your willingness to own your baby, but we're a community. As long as I know the package is well maintained, it doesn't make a big difference wether it's him or you. You can always contact the person and deal something with them if it can help you sleep better. I think you misunderstood me. It's not about taking packages back if they are maintained. It's about giving orphaned packages back to the previous maintainer if they are still orphaned and he has logged in again and pushed some new packages to AUR or started maintaining some other packages. Lastly, you can already pick any package orphaned and give it some love. AUR doesn't have (and I don't think it will ever have) any kind of automated system for that. That's why we are here, also it helps keep an eye on what's going on and take the good decisions. Please keep in mind I don't have the truth, I'm nowhere near TU rank here. It's about having those orphaned packages maintained and giving them that love that you mentioned by last maintainer. I also don't have the truth but IMO many of those ppl like me (I hope I'm not the only one here who's back to Arch) will gladly continue to maintain old packages but there are times where you just don't remember you've ever had that or some other package under your care. I'm just speaking common sense. I'm really glad I can confront this idea with others and get some valuable response. Second paragraph is also my response to Oon-Ee Ng. Thanks! Alex. [1] http://aur.archlinux.org/packages/ac/ace/PKGBUILD -- Regards Marcin 'sirmacik' Karpezo http://sirmacik.net
Re: [aur-general] Idea for AUR improvement
Am Fri, 1 Jun 2012 20:20:14 +0200 schrieb Marcin 'sirmacik' Karpezo mar...@karpezo.pl: I think you misunderstood me. It's not about taking packages back if they are maintained. It's about giving orphaned packages back to the previous maintainer if they are still orphaned and he has logged in again and pushed some new packages to AUR or started maintaining some other packages. What do you think a maintainer has orphaned a package or a package was orphaned by a TU? Maybe the maintainer isn't interested in maintaining it anymore? So why would you give those packages automatically back to those previous maintainers who are not interested in them? They most likely would feel annoyed by that and will orphan them again. If you are interested in maintaining an orphaned package, feel free to adopt and maintain it yourself. Sorry, but really pointless idea. Heiko
Re: [aur-general] AUR and unsuported architectures
Loui Chang wrote: 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. I think that other architectures should be allowed to peacefully coexist in the AUR. Some of them may gain enough momentum to get official support (which will also require either new devs coming in or existing devs getting currently unsupported hardware). Until that happens, it should be made clear on the site that other architectures are not officially supported and that users cannot expect help with them. They can still seek help in the Other Architectures area of the forum, the existence of which is itself somewhat supportive of allowing other architectures. If we did that then we would have to emphasize that architecture-specific packages are only allowed when the included modification is necessary for full functionality. The rest of this message is mostly a train of thought that I cut out from the preceding part. At first I thought to propose a naming scheme for architecture-specific packages similar to VCS or programming language module packages, but that would be messy. The real problem is that each architecture has a different namespace for packages. It just so happens that i686 and x86_64 packages often require no changes, so we can use the same PGKBUILD for both. I doubt that there is any impetus for it, but the ideal solution would be to separate the namespaces in ABS and AUR. Most PKGBUILDs would remain the same. Packages for multiple architectures would be copied into each namespace (e.g. arch=(i686 x86_64) would be copied to i686 and x86_64). This is what happens with built packages already, but the PKGBUILDs are still jumbled together in ABS and AUR for convenience|laziness|tradition|tacos. The real change would be that instead of having PKGBUILDs with complicated if-then-else blocks to handle architecture, we would have PKGBUILDs for each architecture *in those cases*, i.e. when changes are required for a particular architecture. Or maybe we could just use the current split PKGBUILD framework for doing something similar, with architecture-specific packages named foo-arch in the PKGBUILD. Meh, I'm mostly thinking out loud here. The point was simply that there would be a way to have a namespace for unsupported architectures living side-by-side with the supported ones. Ultimately I still think that it's unfortunate that all of the metadata is locked up in Bash. It difficilitates the creation of many practical metapackaging tools. If anyone wants to play around with this idea, reply in a new thread. I've left this in the old one because I don't expect any real discussion, but it might be interesting.
Re: [aur-general] Idea for AUR improvement
Heiko Baums wrote: Am Fri, 1 Jun 2012 20:20:14 +0200 schrieb Marcin 'sirmacik' Karpezo mar...@karpezo.pl: I think you misunderstood me. It's not about taking packages back if they are maintained. It's about giving orphaned packages back to the previous maintainer if they are still orphaned and he has logged in again and pushed some new packages to AUR or started maintaining some other packages. What do you think a maintainer has orphaned a package or a package was orphaned by a TU? Maybe the maintainer isn't interested in maintaining it anymore? So why would you give those packages automatically back to those previous maintainers who are not interested in them? They most likely would feel annoyed by that and will orphan them again. If you are interested in maintaining an orphaned package, feel free to adopt and maintain it yourself. Sorry, but really pointless idea. Um, I don't think you understood his idea, but at least it didn't stop you from replying with your usual abrasive tone. Simplified version: User Foo maintains x packages in AUR Foo decides to leave Arch for another distro Foo orphans his packages because he does not expect to be able to maintain them Foo later realizes how much better Arch is and returns to Arch as a prodigal son Foo is now ready to resume maintenance of his old packages *if necessary* Foo sees that y packages have been adopted and Foo is happy Foo would like to easily re-adopt the (x-y) packages that are still orphans He's just asking for a way to simplify finding the old packages *that are still orphans*. Now that the request is clear, I will say that I don't think this should be done on the AUR itself. As already mentioned, there are not many users who drop everything in the AUR and then come back (even if they always come back). Such a user could just write a script that: a) compiles a list of currently maintained AUR packages b) re-adopts them if they are orphans The list generation and orphan detection could both be done with python3-aur, but that cannot (yet?) log in and perform user operations.
Re: [aur-general] Idea for AUR improvement
On Fri, Jun 1, 2012 at 10:42 PM, Xyne x...@archlinux.ca wrote: Now that the request is clear, I will say that I don't think this should be done on the AUR itself. As already mentioned, there are not many users who drop everything in the AUR and then come back (even if they always come back). I don't think you should only focus on that particular use case. There may be other problems that could be solved by a more generic approach. What I'm thinking about is having a last maintainer field that would be displayed and searchable for orphans packages. It would not only allow to easily find all packages that were belonging to a specific user but would also give an easy way to reach the last maintainer of an orphan package to get extra informations before adopting it. This is just a random thought and may be pointless... What is your opinion on this? -- Cédric Girard
Re: [aur-general] Idea for AUR improvement
Am Fri, 1 Jun 2012 20:42:47 + schrieb Xyne x...@archlinux.ca: Um, I don't think you understood his idea, I think I did understand his idea. but at least it didn't stop you from replying with your usual abrasive tone. Am I not allowed to answer, particularly if I think the idea is pointless? And, no, it is not an abrasive tone. Those are just facts. And I had the impression that Marcin didn't think about the reasons why a package is usually (in most cases) orphaned. It's peculiar that people get personally if they don't share an opinion. Simplified version: User Foo maintains x packages in AUR Foo decides to leave Arch for another distro Foo orphans his packages because he does not expect to be able to maintain them Foo later realizes how much better Arch is and returns to Arch as a prodigal son Foo is now ready to resume maintenance of his old packages *if necessary* Foo sees that y packages have been adopted and Foo is happy Foo would like to easily re-adopt the (x-y) packages that are still orphans I already understood this. This doesn't change anything. Still no reason for an automation. In those very rare cases I guess the previous maintainer still knows which packages he had maintained, and wants to continue maintaining. So he already can easily search for and adopt those packages. Btw., I read at least one comment in the AUR in which the old maintainer asked to be removed from the #Contributor flag in the PKGBUILD. So I think that not everybody would be happy with such a previous maintainer field in the AUR. Heiko
Re: [aur-general] Idea for AUR improvement
2012/6/2 Heiko Baums li...@baums-on-web.de I already understood this. This doesn't change anything. Still no reason for an automation. In those very rare cases I guess the previous maintainer still knows which packages he had maintained, and wants to continue maintaining. So he already can easily search for and adopt those packages. Btw., I read at least one comment in the AUR in which the old maintainer asked to be removed from the #Contributor flag in the PKGBUILD. So I think that not everybody would be happy with such a previous maintainer field in the AUR. And what about asking to you? Or a field option on the sittings, like to receive a digest or to receive any mail separately, you could choose if you want your #Contributor flag to be removed or not
Re: [aur-general] Idea for AUR improvement
On Sat, Jun 2, 2012 at 1:04 AM, Heiko Baums li...@baums-on-web.de wrote: Btw., I read at least one comment in the AUR in which the old maintainer asked to be removed from the #Contributor flag in the PKGBUILD. So I think that not everybody would be happy with such a previous maintainer field in the AUR. Seems strange. Only real reason I can see for not wanting to appear as previous maintainer would be if the PKGBUILD has deviated too much from previous maintainer vision (and probably in a bad way). But it means the PKGBUILD has a new maintainer which is a different case. -- Cédric Girard
Re: [aur-general] Idea for AUR improvement
Zaterdag 2 Juni 2012 om 01:04 (CEST +0200) schreef Heiko Baums: Am I not allowed to answer, particularly if I think the idea is pointless? And, no, it is not an abrasive tone. Those are just facts. And I had the impression that Marcin didn't think about the reasons why a package is usually (in most cases) orphaned. It's peculiar that people get personally if they don't share an opinion. Heiko, You were not sharing an opinion, you were sharing facts, right? I advise you to be careful with the words you choose. Your facts are based on *your* view and interpretation on the whole and prevent this subject to be discussed any further by stating it's a pointless idea just because the facts (read: the information you found and interpreted as facts) are saying so. That is pointless in my opinion. I think Marcin's idea is not that bad. I wouldn't suggest it to be the way he writes, but some automation might be welcome. I don't have enough knowledge to come with another idea though. Good luck Marcin! -- Christian Stadegaart
Re: [aur-general] Idea for AUR improvement
Am Sat, 2 Jun 2012 01:23:30 +0200 schrieb Cédric Girard girard.ced...@gmail.com: On Sat, Jun 2, 2012 at 1:04 AM, Heiko Baums li...@baums-on-web.de wrote: Btw., I read at least one comment in the AUR in which the old maintainer asked to be removed from the #Contributor flag in the PKGBUILD. So I think that not everybody would be happy with such a previous maintainer field in the AUR. Seems strange. Only real reason I can see for not wanting to appear as previous maintainer would be if the PKGBUILD has deviated too much from previous maintainer vision (and probably in a bad way). But it means the PKGBUILD has a new maintainer which is a different case. Unfortunately I can't remember which package it was, but I remember that the previous maintainer hasn't given a reason for his request. A reason I could also think of are (new) privacy concerns for whatever reason. Heiko
Re: [aur-general] Idea for AUR improvement
Am Sat, 02 Jun 2012 01:23:46 +0200 schrieb Christian Stadegaart e-m...@bewust-leven.nl: You were not sharing an opinion, you were sharing facts, right? I advise you to be careful with the words you choose. Why? Answer my questions, and you will see that it's true. In the most cases you will come to the same conclusion than me. What do you think, why a maintainer has orphaned a package or a package was orphaned by a TU? Maybe the maintainer isn't interested in maintaining it anymore? The reason why someone orphans a package himself is in most cases that he is not interested in this package anymore. This can have several reasons. The most common reasons are: - He switches the distro from Arch to another one. - He doesn't use this package anymore and don't want to maintain it anymore. - He doesn't have time enough to maintaining the package. - There are major issues with the source package, and he doesn't want to spend too much time in patching the package. And many more. In most cases it's pretty unlikely that the previous maintainer wants to get the package back. And in the first case (switching the distro back to Arch Linux), I'm pretty sure that the maintainer still knows which packages he has maintained or he just looks for outdated, and orphaned packages he wants to use, like he was a new user. The reason why a package is orphaned by a TU is: - The package is outdated, the maintainer doesn't update it, and doesn't respond to the out-of-date flag, comments and e-mails within two weeks. You also can be pretty sure that the previous maintainer doesn't want the package back. So why would you give those packages automatically back to those previous maintainers who are not interested in them anymore? If I would orphan a package - and I already did this with a few - I would be pretty annoyed if an AUR automatism would see that those packages are orphaned, and assign them to me again, because there have been reasons why I have orphaned the package before. So, no reason for an automatism. Your facts are based on *your* view and interpretation on the whole and prevent this subject to be discussed any further by stating it's a pointless idea just because the facts (read: the information you found and interpreted as facts) are saying so. Not really an interpretation. See above. I think Marcin's idea is not that bad. I wouldn't suggest it to be the way he writes, but some automation might be welcome. I don't have enough knowledge to come with another idea though. What I think what you mean - and this is indeed an interpretation -, is writing a helper (a search function) for finding packages someone has maintained before, and adding a function (a button or the like) to adopt those packages again. Well, I don't have anything against this. I'm not sure if this is necessary, because, like I said before, I guess that everybody knows which packages he has maintained previously. But why not? For people who maintained about 100 packages this can be helpful. But this has not much to do with an automation, this is rather a search function and a helper. Heiko
[aur-general] Separating PKGBUILDs for architectures - Was: AUR and unsuported architectures
On 2012-06-01 17:28, Xyne wrote: Loui Chang wrote: 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. I think that other architectures should be allowed to peacefully coexist in the AUR. Some of them may gain enough momentum to get official support (which will also require either new devs coming in or existing devs getting currently unsupported hardware). Until that happens, it should be made clear on the site that other architectures are not officially supported and that users cannot expect help with them. They can still seek help in the Other Architectures area of the forum, the existence of which is itself somewhat supportive of allowing other architectures. Yes, if this is ever allowed, this needs to be writen in big neon fonts. Much like AUR in unsupported is written everywhere. If we did that then we would have to emphasize that architecture-specific packages are only allowed when the included modification is necessary for full functionality. The rest of this message is mostly a train of thought that I cut out from the preceding part. At first I thought to propose a naming scheme for architecture-specific packages similar to VCS or programming language module packages, but that would be messy. The real problem is that each architecture has a different namespace for packages. It just so happens that i686 and x86_64 packages often require no changes, so we can use the same PGKBUILD for both. I doubt that there is any impetus for it, but the ideal solution would be to separate the namespaces in ABS and AUR. Most PKGBUILDs would remain the same. Packages for multiple architectures would be copied into each namespace (e.g. arch=(i686 x86_64) would be copied to i686 and x86_64). This is what happens with built packages already, but the PKGBUILDs are still jumbled together in ABS and AUR for convenience|laziness|tradition|tacos. I'm guessing that originally packages could be available or not for amd64, and later on, the if-then-else come to be. I do agree that there's little reason to keep this, though changing it is plenty of work. The real change would be that instead of having PKGBUILDs with complicated if-then-else blocks to handle architecture, we would have PKGBUILDs for each architecture *in those cases*, i.e. when changes are required for a particular architecture. Or maybe we could just use the current split PKGBUILD framework for doing something similar, with architecture-specific packages named foo-arch in the PKGBUILD. This would bring a lots of conviniences. Multiarch packages still have one SINGLE PKGBUILD, and packages with different builds can have multiple PKGBUILD files. A nice idea would be to have PKGBUILD with common data/functions, and PKGBUILD.arch (ie: PKGBUILD.x86) with arch specific stuff. This would add a lot to maintainability, and still clean up lots of issues. In many cases, the specific files just have different source and checksum. Or different files to install in package(). This would, of course, require plenty of changes to makepkg AFAIK. Meh, I'm mostly thinking out loud here. The point was simply that there would be a way to have a namespace for unsupported architectures living side-by-side with the supported ones. Ultimately I still think that it's unfortunate that all of the metadata is locked up in Bash. It difficilitates the creation of many practical metapackaging tools. If anyone wants to play around with this idea, reply in a new thread. I've left this in the old one because I don't expect any real discussion, but it might be interesting. -- Hugo Osvaldo Barrera
Re: [aur-general] Idea for AUR improvement
On 2012-06-01 17:42, Xyne wrote: Heiko Baums wrote: Am Fri, 1 Jun 2012 20:20:14 +0200 schrieb Marcin 'sirmacik' Karpezo mar...@karpezo.pl: snip snip Um, I don't think you understood his idea, but at least it didn't stop you from replying with your usual abrasive tone. Simplified version: User Foo maintains x packages in AUR Foo decides to leave Arch for another distro Foo orphans his packages because he does not expect to be able to maintain them Foo later realizes how much better Arch is and returns to Arch as a prodigal son Foo is now ready to resume maintenance of his old packages *if necessary* Foo sees that y packages have been adopted and Foo is happy Foo would like to easily re-adopt the (x-y) packages that are still orphans He's just asking for a way to simplify finding the old packages *that are still orphans*. Now that the request is clear, I will say that I don't think this should be done on the AUR itself. As already mentioned, there are not many users who drop everything in the AUR and then come back (even if they always come back). Such a user could just write a script that: a) compiles a list of currently maintained AUR packages b) re-adopts them if they are orphans The list generation and orphan detection could both be done with python3-aur, but that cannot (yet?) log in and perform user operations. I think a list of packages I've contributed to (similar to my packages, but also includes packages you've orphaned) in AUR would solve this, and be helpful for other stuff. If a user leaves Arch for some reason, and comes back, IF he's intereseted in re-adopted his orphaned packages, he'll just see that list, and adopt them. Currently, it's pretty hard to know what packages you've contributed to in the past, and it is something nice to have. -- Hugo Osvaldo Barrera
Re: [aur-general] AUR and unsuported architectures
On 2012-06-01 03:17, Jelle van der Waa wrote: 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 je...@vdwaa.nl 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. I agree, this is quite true, and I actually must agree that ppc/arm would be out-of-place because of this. 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?) I don't know if it's allowed, but I should point that this article exists in the wiki: https://wiki.archlinux.org/index.php/Official_Install_Guide_on_a_PowerPC I don't think it should say official. Or it should at least mention it's unsupported by arch, BTW. 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. I've seen people complaining that pacman can't install stuff from AUR too. We can't let out-of-place users become an impediment to move forward. As I have seen with for example archbang and archlinuxarm questions on #archlinux. I've seen Ubuntu and Fedora users asking stuff in #debian. Stupid people will always be stupid, you can't stop that! The other reasons mentioned are valid (and I had actually backed down because of them), but I don't think this one should really have as much weight. 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. Given that this question (is arm/ppc allowed in AUR?) has had a bit of mixed responses, can I expect a bit more of discussion on this, or should I consider the no final? Thanks, -- Hugo Osvaldo Barrera
Re: [aur-general] AUR and unsuported architectures
On 01/06/12 08:17 PM, Hugo Osvaldo Barrera wrote:
Given that this question (is arm/ppc allowed in AUR?) has had a bit
of mixed responses, can I expect a bit more of discussion on this, or
should I consider the no final? Thanks,
I wouldn't consider the no final. If you put a PKGBUILD in the AUR
that says arch=('i686', 'x86_64' 'arm' 'ppc') and someone requests that
it be deleted for that reason, I'm not going to delete it.
signature.asc
Description: OpenPGP digital signature
Re: [aur-general] AUR and unsuported architectures
On 2 June 2012 11:21, Connor Behan connor.be...@gmail.com wrote:
On 01/06/12 08:17 PM, Hugo Osvaldo Barrera wrote:
Given that this question (is arm/ppc allowed in AUR?) has had a bit
of mixed responses, can I expect a bit more of discussion on this, or
should I consider the no final? Thanks,
I wouldn't consider the no final. If you put a PKGBUILD in the AUR
that says arch=('i686', 'x86_64' 'arm' 'ppc') and someone requests that
it be deleted for that reason, I'm not going to delete it.
Look at it this way: why the hell should it matter to me if I'm not an
'arm' or 'ppc' user? The build would go just fine, and if I never look
at the PKGBUILD, then nothing is different to me. So in the end,
there's nothing wrong with that if the same PKGBUILD can be used
across platforms.
--
GPG/PGP ID: C0711BF1
