Re: [aur-general] changing the status of the maintainer field
2009/5/22 Gerardo Exequiel Pozzi vmlinuz...@yahoo.com.ar: 1) Technical purposes: Having a # Maintainer comment line can provide a simple way to shell scripts to identify the maintainer, that in many cases the maintainer != packager. (pacman -Qi) This help in many cases, for example reporting a mass change/rebuild/bug/feature/etc/random. 2) Ethical: While many of the PKGBUILD are trivial changes to the PKGBUILD.proto, beyond this, which made this PKGBUILD took some maintenance time of work, and giving a kind of support for it. So, I think it is important that this be retained. I started the thread to revive the idea of having a separate maintainer field for the official repositories which could be parsed by scripts to update the web interface, instead of using the web interface to change the maintainer as is done currently. This of course does not apply to the AUR and the question of Maintainer vs Contributor tag (already discussed before many times) is irrelevant here. Currently a dev/TU has to go to the package page and click Adopt. Also he/she has to update the Maintainer tag accordingly to match it with the web interface which is often not done. If the maintainer tag was a proper field like maintainer=(username) then to adopt the package, all one would need to do is change the value of the maintainer variable and commit to trunk. The web interface would pick the changes from trunk and update itself. This would make the maintainer tag more relevant and easier to parse by scripts. This does not apply to the AUR since everything depends on the web interface there. IMO, the official repositories should have their metadata independent of the web interface, in the PKGBUILDs if possible. If this change is implemented, then one would not need to visit the web interface for such a common task. -- Abhishek
Re: [aur-general] changing the status of the maintainer field
The problem is, most people don't get the following part: This does not apply to the AUR It has been evident over and over again that the issue was mainly repository- and interface-related, but it has been overhyped into being something that concerns the New World Order.
Re: [aur-general] changing the status of the maintainer field
On Fri, 2009-05-22 at 06:47 +0200, Xyne wrote: Baho Utot baho-u...@columbus.rr.com wrote: What if I use abs to fetch the entire core/extra and then build and maintain that tree? Am I now the maintainer and everyone else contributors? I'll be honest: I rolled my eyes when I read that. Then I accomplished what I set out to do, That is those tags really are not that important. I compile all my packages used for the system cpu, I start with the install cd and compile base then on to the ones I need for a working system. If you began to independently maintain all of those packages (update them yourself, modify the PKGBUILDs, etc) then you would be the maintainer to anyone retrieving them from you and you would be expected to deal with any errors arising from what you changed. If you do not distribute them, then maintainer makes no sense at all. If you simply copy the PKBUILDs from abs occasionally without adding your own modifications, then you're not really a maintainer of the PKGBUILD, but if you decide to distribute binary versions yourself then you would be the maintainer of those.
Re: [aur-general] changing the status of the maintainer field
Am Fri, 22 May 2009 14:55:43 +1000 schrieb Allan McRae al...@archlinux.org: BAH! ...and again, BAH! It is a comment people... just a comment. makepkg and pacman don't care about it and nor should anyone else! On the one hand I somehow agree with people, who don't care too much about these tags, on the other hand I agree with people, who think, they are quite important. Even if I've somehow mistaken both tags in the past and put me as a contributor instead of a maintainer in my PKGBUILDs - I will change this some time -, I agree, that Maintainer should contain the current maintainer, and that Contributor should contain the previous Maintainers or people, who sent patches for the PKGBUILD to the maintainer. I think these tags - at least the Maintainer tag - are quite important, because a user should be able to easily find out, who has written the PKGBUILD and whom to contact, if there's an issue with the PKGBUILD. I'm not sure, if this should be realised as an obligatory field or a comment. With a field the maintainer is forced to add his name and e-mail address to the PKGBUILD, and this is checked by makepkg or pacman. Comments are more flexible, so that more maintainers and contributors can be added to the PKGBUILD. In this case the PKGBUILD can be parsed by AUR - it's already done anyway - when a package is uploaded to AUR. If the Maintainer tag is missing the package will be rejected and the maintainer, who tries to upload it, gets a corresponding message. Nevertheless I think, there's another point. Aren't the PKGBUILDs licensed under the GPL? As far as I know, this would mean, that every current and previous Maintainer has to be mentioned in the PKGBUILD anyway. Heiko
Re: [aur-general] changing the status of the maintainer field
2009/5/22 Heiko Baums li...@baums-on-web.de: Comments are more flexible, so that more maintainers and contributors can be added to the PKGBUILD.In this case the PKGBUILD can be parsed by AUR - it's already done anyway - when a package is uploaded to AUR. No, it isn't; no script parses the Maintainer or Contributor tags since they are just comments and in quite a few cases have incorrect maintainers listed. Nevertheless I think, there's another point. Aren't the PKGBUILDs licensed under the GPL? I've no idea about this. -- Abhishek
Re: [aur-general] changing the status of the maintainer field
Yeah, can we get back to Abhishek's topic please? I think I agree with his thinking: - Make the maintainer a proper singular bash variable string - Make the contributors a praper bash array - Let the web interface hold onto its own metadata (I don't think anyone wants the web interface editing PKGBUILDs) - Possibly rename maintainer to owner and keep contributors contributors - Or if more clear, rename maintainer to current_maintainer and contributors to past_maintainers That should clear everything up and prevent further discussion. -AT
Re: [aur-general] changing the status of the maintainer field
Andrei Thorp wrote: Yeah, can we get back to Abhishek's topic please? I think I agree with his thinking: - Make the maintainer a proper singular bash variable string - Make the contributors a praper bash array - Let the web interface hold onto its own metadata (I don't think anyone wants the web interface editing PKGBUILDs) - Possibly rename maintainer to owner and keep contributors contributors - Or if more clear, rename maintainer to current_maintainer and contributors to past_maintainers That should clear everything up and prevent further discussion. I am very much against adding _unnecessary_ fields to PKGBUILDs... If these are not needed by makepkg or pacman, they should only be comments. It is going to take a lot of convincing for me to think otherwise. Allan
[aur-general] [sauerbraten] Trooper edition
I've made an updated PKGBUILD for Sauerbraten Trooper edition with a modified sauerbraten-client script that saves user configuration in .config/sauerbraten Thanks to the maintainer to update AUR package. PKGBUILD Description: Binary data sauerbraten-client Description: Binary data
Re: [aur-general] changing the status of the maintainer field
2009/5/22 Allan McRae al...@archlinux.org: I am very much against adding _unnecessary_ fields to PKGBUILDs... If these are not needed by makepkg or pacman, they should only be comments. It is going to take a lot of convincing for me to think otherwise. As long as the information in # Maintainer tags and the web interface is the *same*, there is no problem. What is required is an easily accessible database of current maintainers for each package. It's always best to have as much information available in easily downloadable form. One way (and there can be numerous different ways of doing this) is to put this in the PKGBUILD in a parseable form -- the reason for a bash array with the username: - makes it easily parseable by bash scripts - putting only the username and no other extraneous information as email etc can change. - ignored by makepkg as it does not recognise it (and doesn't need to) - has no effect on the binary As an example consider the *files.db.tar.gz stuff. Before that if one wanted to check the filelist of a particular package, one would need to download that particular package and check out its contents. Now, the files database is put in an easily accessible location which enables programs like pkgfile to access and make use of that information. While this information could have been put as a kind of API (like the AUR JSON interface) that would have reduced usability for users who would like to view a filelist offline. Currently there is no _simple_ way for scripts of finding the maintainer of a given package in the official repositories. The only way is to parse the webpage which is hackish and certainly not KISS. An abs (or even svn) checkout does not help since there is no necessity that the Maintainer tag in the PKGBUILD and the maintainer listed in the web interface is the same; which just makes the Maintainer tag in the PKGBUILD totally irrelevant since one has to check the web interface anyway. All this was discussed in the arch-dev-public thread I mentioned a few posts back. At that time, most people seemed to agree that this was a good idea but nothing came of it. -- Abhishek
Re: [aur-general] changing the status of the maintainer field
Abhishek Dasgupta wrote: 2009/5/22 Allan McRae al...@archlinux.org: I am very much against adding _unnecessary_ fields to PKGBUILDs... If these are not needed by makepkg or pacman, they should only be comments. It is going to take a lot of convincing for me to think otherwise. As long as the information in # Maintainer tags and the web interface is the *same*, there is no problem. What is required is an easily accessible database of current maintainers for each package. It's always best to have as much information available in easily downloadable form. One way (and there can be numerous different ways of doing this) is to put this in the PKGBUILD in a parseable form -- the reason for a bash array with the username: - makes it easily parseable by bash scripts - putting only the username and no other extraneous information as email etc can change. - ignored by makepkg as it does not recognise it (and doesn't need to) - has no effect on the binary As an example consider the *files.db.tar.gz stuff. Before that if one wanted to check the filelist of a particular package, one would need to download that particular package and check out its contents. Now, the files database is put in an easily accessible location which enables programs like pkgfile to access and make use of that information. While this information could have been put as a kind of API (like the AUR JSON interface) that would have reduced usability for users who would like to view a filelist offline. Currently there is no _simple_ way for scripts of finding the maintainer of a given package in the official repositories. The only way is to parse the webpage which is hackish and certainly not KISS. An abs (or even svn) checkout does not help since there is no necessity that the Maintainer tag in the PKGBUILD and the maintainer listed in the web interface is the same; which just makes the Maintainer tag in the PKGBUILD totally irrelevant since one has to check the web interface anyway. All this was discussed in the arch-dev-public thread I mentioned a few posts back. At that time, most people seemed to agree that this was a good idea but nothing came of it. So, to disown a package from the official repos would no longer require just clicking orphan but unsetting the maintainer flag in SVN/CVS. And adopting would require adding to the maintainer flag rather than just clicking adopt. Given the majority of packages don't even have the motivation to add ChangeLogs, this extra layer of annoyance to take over the maintaining of a package just does not seem appealing. This is why I see no point in discussing this because in practice people will not change the maintainer package until they do an update/rebuild at which point they should change the maintainer line anyway... Allan
Re: [aur-general] changing the status of the maintainer field
Andrei Thorp wrote: Another thing that you guys probably don't care too much about is the fact that -Qi -ing a package that you have installed will not list the Maintainer for packages from AUR. Actually, -Qi'ing or -Si'ing a package doesn't list the maintainer at all! The Packager: field in the output is the name + email of the person who last built the package, and this is not necessarily the maintainer. Case in point: pacman -Si curlftpfs. Don't rely on Packager: from -Qi or -Si. Yes, a Maintainer: field in -Qi or -Si output would be nice. Also, isn't there something kind of terrible about the fact that CVS/SVN, AUR web, and comments all track a bit of information separately and in different ways? It is bad, but unfortunately, I think that every distro has this problem to a certain extent. Not sure what the solution is. Regards, -- Chris PS. This thread is at least convincing me to *think about* updating the # Maintainer comment in my adopted packages!
Re: [aur-general] changing the status of the maintainer field
On Fri, May 22, 2009 at 12:34 PM, Chris Brannon cmbran...@cox.net wrote: Andrei Thorp wrote: Another thing that you guys probably don't care too much about is the fact that -Qi -ing a package that you have installed will not list the Maintainer for packages from AUR. Actually, -Qi'ing or -Si'ing a package doesn't list the maintainer at all! The Packager: field in the output is the name + email of the person who last built the package, and this is not necessarily the maintainer. Case in point: pacman -Si curlftpfs. Don't rely on Packager: from -Qi or -Si. Yes, a Maintainer: field in -Qi or -Si output would be nice. Ah, okay, thanks. -AT
Re: [aur-general] changing the status of the maintainer field
Am Fri, 22 May 2009 17:16:31 +0530 schrieb Abhishek Dasgupta abh...@gmail.com: 2009/5/22 Heiko Baums li...@baums-on-web.de: Comments are more flexible, so that more maintainers and contributors can be added to the PKGBUILD.In this case the PKGBUILD can be parsed by AUR - it's already done anyway - when a package is uploaded to AUR. No, it isn't; no script parses the Maintainer or Contributor tags since they are just comments and in quite a few cases have incorrect maintainers listed. Well, the Maintainer and Contributor tags are not parsed yet, but the PKGBUILD is parsed, because the package name, the description, sources, etc. are read from the PKGBUILD by AUR. So this could also be done with the Maintainer and Contributor tags. Heiko
Re: [aur-general] changing the status of the maintainer field
Am Fri, 22 May 2009 11:34:38 -0500 schrieb Chris Brannon cmbran...@cox.net: Actually, -Qi'ing or -Si'ing a package doesn't list the maintainer at all! The Packager: field in the output is the name + email of the person who last built the package, But only, if the packager has set the PACKAGER variable in his /etc/makepkg.conf. And I think I can remember, that not every packager (dev or TU) has set this correctly. Heiko
Re: [aur-general] Inactivity - 21st-25th May
Found an Internet point =P 2009/5/21 Xyne x...@archlinux.ca: I've just tried building rss-glx on x86_64 and received a segfault as well. Ah, great. I just reported what djgera wrote in the mentioned bug report (he also attached a successful build log). Anyway, enjoy your holiday! Thanks, that's exactly what I am doing =D Corrado
[aur-general] Integrity Check community i686 22-05-2009
= = Integrity Check i686 of community = = Performing integrity checks... == parsing pkgbuilds == checking mismatches == checking archs == checking dependencies == checking makedepends == checking for circular dependencies Missing PKGBUILDs --- /srv/abs/rsync/i686//community/CVS /srv/abs/rsync/i686//community/daemons/CVS /srv/abs/rsync/i686//community/devel/CVS /srv/abs/rsync/i686//community/editors/CVS /srv/abs/rsync/i686//community/emulators/CVS /srv/abs/rsync/i686//community/games/CVS /srv/abs/rsync/i686//community/gnome/CVS /srv/abs/rsync/i686//community/i18n/CVS /srv/abs/rsync/i686//community/kde/CVS /srv/abs/rsync/i686//community/lib/CVS /srv/abs/rsync/i686//community/modules/CVS /srv/abs/rsync/i686//community/multimedia/CVS /srv/abs/rsync/i686//community/network/CVS /srv/abs/rsync/i686//community/office/CVS /srv/abs/rsync/i686//community/science/CVS /srv/abs/rsync/i686//community/system/CVS /srv/abs/rsync/i686//community/x11/CVS /srv/abs/rsync/i686//community/xfce/CVS Missing Dependencies -- listen -- 'pywebkitgtk' listen -- 'pyinotify' flumotion -- 'twisted-web' open-vm-tools-modules -- 'kernel262.6.28' qc-usb -- 'kernel262.6.29' qc-usb-messenger -- 'kernel262.6.28' eclipse-ve -- 'eclipse3.3' libphobos -- 'dmd=1.043' cdfs -- 'kernel262.6.28' Missing Makedepends - classpath -- 'jikes' Summary - Missing PKGBUILDs: 18 Invalid PKGBUILDs: 0 Mismatching PKGBUILD names:0 Duplicate PKGBUILDs: 0 Invalid archs: 0 Missing (make)dependencies:10 Repo hierarchy problems: 0 Circular dependencies: 0
[aur-general] Integrity Check community x86_64 22-05-2009
=== = Integrity Check x86_64 of community = === Performing integrity checks... == parsing pkgbuilds == checking mismatches == checking archs == checking dependencies == checking makedepends == checking for circular dependencies Missing PKGBUILDs --- /srv/abs/rsync/x86_64//community/CVS /srv/abs/rsync/x86_64//community/daemons/CVS /srv/abs/rsync/x86_64//community/devel/CVS /srv/abs/rsync/x86_64//community/editors/CVS /srv/abs/rsync/x86_64//community/emulators/CVS /srv/abs/rsync/x86_64//community/games/CVS /srv/abs/rsync/x86_64//community/gnome/CVS /srv/abs/rsync/x86_64//community/i18n/CVS /srv/abs/rsync/x86_64//community/kde/CVS /srv/abs/rsync/x86_64//community/lib/CVS /srv/abs/rsync/x86_64//community/lib32/CVS /srv/abs/rsync/x86_64//community/modules/CVS /srv/abs/rsync/x86_64//community/multimedia/CVS /srv/abs/rsync/x86_64//community/network/CVS /srv/abs/rsync/x86_64//community/office/CVS /srv/abs/rsync/x86_64//community/science/CVS /srv/abs/rsync/x86_64//community/system/CVS /srv/abs/rsync/x86_64//community/x11/CVS /srv/abs/rsync/x86_64//community/xfce/CVS Mismatched Pkgnames - freeimage-legacy vs. /srv/abs/rsync/x86_64//community/lib/freeimage Missing Dependencies -- flumotion -- 'twisted-web' open-vm-tools-modules -- 'kernel262.6.28' qc-usb -- 'kernel262.6.29' qc-usb-messenger -- 'kernel262.6.28' eclipse-ve -- 'eclipse3.3' cdfs -- 'kernel262.6.28' Missing Makedepends - classpath -- 'jikes' Summary - Missing PKGBUILDs: 19 Invalid PKGBUILDs: 0 Mismatching PKGBUILD names:1 Duplicate PKGBUILDs: 0 Invalid archs: 0 Missing (make)dependencies:7 Repo hierarchy problems: 0 Circular dependencies: 0
Re: [aur-general] changing the status of the maintainer field
2009/5/22 Angel Velásquez an...@archlinux.com.ve: Actually, you can export an env var with the value of that.. i.e: PACKAGER=Angel 'angvp' Velasquez makepkg But now talking about the topic, you can also set the Maintainer flag with an env var and adding it to the .PKGINFO (I thought Andrei Thorp suggested this anyway) and past maintainers can be parsed in another .PKGINFO Field. This will need modifications of the makepkg script (and adding this to pacman in the -i option), but I think this is a good solution, for having the *actual* maintainer with -Qi or -Si. In code the thing will be like: MAINTAINER=Angel 'angvp' Velasquez makepkg And then the makepkg will do these new jobs: 1.- Add the value of the env var MAINTAINER as the current maintainer 2.- Add the value of the env var MAINTAINER (if the value isn't in the array) to an array of pasts_maintaners to the .PKGINFO .. Note 1: If the MAINTAINER var wasn't set it will use the value of PACKAGER if isn't empty, or the classical None in case both vars are empty Note 2: Because is annoying to set the name everytime you will build a package that you maintain, you can add this var in something like .bashrc or on a script, BUT if you are building a package from another tu/dev (cause he asked the favour to you or something like), you should have to set it with the value of the *actual* maintainer with the ugly way: MAINTAINER=John Doe f...@bar.com makepkg Note 3: to see past maintainers you should have the unpack the packages and see it on the .PKGINFO file, (because in my opinion, adding this information to -i is too much) Note 4: there are a web interface which actually parse the value of PACKAGER on the .PKGINFO [1] This Isn't something hard to do at all .. but I know that many people wouldn't like it this idea :/, actually I have to say, for me will be the same to implement or not this solution. [1] http://www.archlinux.de/?page=Packagers -- Angel Velásquez angvp @ irc.freenode.net Linux Counter: #359909 Noone is going to do this if it were implemented, which I really don't think it needs to be.
Re: [aur-general] changing the status of the maintainer field
Noone is going to do this if it were implemented, which I really don't think it needs to be. Dude, two things: 1.- Instead of say no one is going to do this ... try to implement something better for the requirement of Abhishek, if you are not agree with the requirement is other subject, but if you are agree with the requirement, then instead of not aproving other solutions, try to think in one and propose it. 2.- You don't have to quote the entire mail that I sent (with the signature included). Have you ever used mailing lists before? -- Angel Velásquez angvp @ irc.freenode.net Linux Counter: #359909
Re: [aur-general] changing the status of the maintainer field
On Fri, 2009-05-22 at 19:35 +0530, Abhishek Dasgupta wrote: 2009/5/22 Allan McRae al...@archlinux.org: I am very much against adding _unnecessary_ fields to PKGBUILDs... If these are not needed by makepkg or pacman, they should only be comments. It is going to take a lot of convincing for me to think otherwise. As long as the information in # Maintainer tags and the web interface is the *same*, there is no problem. What is required is an easily accessible database of current maintainers for each package. It's always best to have as much information available in easily downloadable form. One way (and there can be numerous different ways of doing this) is to put this in the PKGBUILD in a parseable form -- the reason for a bash array with the username: - makes it easily parseable by bash scripts - putting only the username and no other extraneous information as email etc can change. - ignored by makepkg as it does not recognise it (and doesn't need to) - has no effect on the binary As an example consider the *files.db.tar.gz stuff. Before that if one wanted to check the filelist of a particular package, one would need to download that particular package and check out its contents. Now, the files database is put in an easily accessible location which enables programs like pkgfile to access and make use of that information. While this information could have been put as a kind of API (like the AUR JSON interface) that would have reduced usability for users who would like to view a filelist offline. Currently there is no _simple_ way for scripts of finding the maintainer of a given package in the official repositories. The only way is to parse the webpage which is hackish and certainly not KISS. An abs (or even svn) checkout does not help since there is no necessity that the Maintainer tag in the PKGBUILD and the maintainer listed in the web interface is the same; which just makes the Maintainer tag in the PKGBUILD totally irrelevant since one has to check the web interface anyway. All this was discussed in the arch-dev-public thread I mentioned a few posts back. At that time, most people seemed to agree that this was a good idea but nothing came of it. If those fields were a bash variable.. A utility could be written to find PKGBUILDs maintained by people no longer active/verify that all PKGBUILDS in core/extra have a active maintainer.
Re: [aur-general] changing the status of the maintainer field
2009/5/23 Angel Velásquez an...@archlinux.com.ve: But now talking about the topic, you can also set the Maintainer flag with an env var and adding it to the .PKGINFO (I thought Andrei Thorp suggested this anyway) and past maintainers can be parsed in another .PKGINFO Field. This will need modifications of the makepkg script (and adding this to pacman in the -i option), but I think this is a good solution, for having the *actual* maintainer with -Qi or -Si. Adding the Maintainer field to .PKGINFO has a few problems: - This makes this quite complicated, needing changes to both makepkg and pacman. - The information gets outdated and there should be only _one_ easily accessible information source about the current maintainer which is retrievable by scripts. For example, if you build a package which is not updated often; and after a few months you orphan it and it's picked up by someone else, it will not be visible to the user when the user does a pacman -Qi; that's why it's better IMO to keep this sort of information only in the PKGBUILDs. Of course, as Allan said, there might not be enough motivation to change the maintainer field in the PKGBUILD if one wishes to adopt a new package. I suppose though, that it would be easy to write a script to do such things automatically. Assuming we have one maintainer for each package, this script (not fully fleshed out, but you get the idea) should work: #!/bin/sh # adopt: adopt a package from the repositories # Change this to wherever you keep your full/partial SVN checkout. if [! -f /etc/makepkg.conf ]; then echo adopt: no makepkg.conf found! exit 1 fi source /etc/makepkg.conf if [ -z $MAINTAINER ]; then echo adopt: Please set the MAINTAINER variable in /etc/makepkg.conf exit 1 fi if [ -z $SVNROOT ]; then echo adopt: Please set the SVNROOT variable in /etc/makepkg.conf exit 1 fi if [ -z $1 ]; then echo Syntax: adopt pkgname exit 1 fi pkgname=$1 if [ ! -d $SVNROOT/$pkgname ] echo adopt: no package $pkgname in $SVNROOT exit 1 fi pushd $SVNROOT/$pkgname /dev/null if [ ! -f PKGBUILD ]; then echo adopt: $pkgname exists, but no PKGBUILD. fi sed -i /^maintainer.*/d PKGBUILD echo maintainer=($MAINTAINER) PKGBUILD svn commit -m changed maintainer to $MAINTAINER # probably give a check to see if uname of svn user same as $MAINTAINER echo adopted $pkgname popd /dev/null # EOF A small note: I'm using makepkg.conf here but MAINTAINER and SVNROOT could be put in some other configuration file as well. Finally after setting all this up; adopting should become as easy as: $ adopt pkg pkg adopted That's it! All the manual work is hidden away in this script. Of course, all that is really needed is an easy way of getting the current maintainers. I'll work on adding some kind of API to the web interface to output the maintainer name given an URI like this: http://archlinux.org/packages/core/i686/bash/maintainer -- Abhishek
