Re: [aur-general] Remove maven-3.1.0 package
In the future, please do not upload packages like this.
On Aug 12, 2013 8:19 AM, "Leonidas Spyropoulos" wrote:
> Please remove the maven-3.1.0 package [1] as the official maven
> package [2] is now updated to 3.1.0 version.
>
> [1]: https://aur.archlinux.org/packages/maven-3.1.0/
> [2]: https://www.archlinux.org/packages/community/any/maven/
>
> Thanks
>
> --
> Caution: breathing may be hazardous to your health.
>
> #include
> int main(){printf("%s","\x4c\x65\x6f\x6e\x69\x64\x61\x73");}
>
Re: [aur-general] Remove maven-3.1.0 package
On Mon, Aug 12, 2013 at 01:40:56PM +0100, Leonidas Spyropoulos wrote: > Hello Dave, > > On Mon, Aug 12, 2013 at 1:22 PM, Dave Reisner wrote: > > In the future, please do not upload packages like this. > Could you please explain me where I actioned wrongly so in the future > I act accordingly? > Guideline #1 from the wiki: https://wiki.archlinux.org/index.php/Arch_Packaging_Standards#Submitting_packages_to_the_AUR Please do not undermine the official repos. No one's stopping you from building the newer version locally, but submitting it to the AUR can and will cause problems. Thanks
Re: [aur-general] aur upload problems
On Sat, Aug 17, 2013 at 05:37:30PM +0200, Rob Til Freedmen wrote: > Hi, > I've tried uploading to the aur (via web) but got an error: > Error - source tarball may not contain nested subdirectories. > > aurploader just returns with an unspecified error. > > I've looked at the source package and everything looks ok. > I've tried an older source package uploaded long time ago > and got the same error. If you create your tarballs using 'makepkg -S', you shouldn't run into such problems.
Re: [aur-general] [Delete] - clean_chroot_manager
On Sun, Aug 18, 2013 at 12:55:20PM -0400, member graysky wrote: > I have renamed the project and updated a new PKGBUILD under the new name. > Please delete the old one: > https://aur.archlinux.org/packages/clean_chroot_manager > > Thanks! I'm more curious what the devtools wrappers like x86_64-extra-build don't offer that caused you to write this.
Re: [aur-general] [tu-bylaws] [PATCH 2/2] Add details on patch submissions
On Wed, Aug 21, 2013 at 05:45:50PM +0200, Lukas Fleischer wrote: > On Wed, Aug 21, 2013 at 12:07:47PM +, Xyne wrote: > > On 2013-08-20 18:14 +0200 > > Lukas Fleischer wrote: > > > > >+SVP is commenced at the time of the motion, with a discussion period of 5 > > >days, > > >+a quorum of 75%, and a voting period of 7 days. > > > > > > Use the same formulation as the "Removal of a TU" section: > > >Following the motion, standard voting procedure commences with a discussion > > >period of 5 days, a quorum of 75%, and a voting period of 7 days. > > > > You can also replace "standard voting procedure" with "SVP" throughout the > > document after its definition. > > Note that I did not touch this sentence apart from formatting changes. > > > > > >+be sent "inline" (i.e. using `git send-email`) so that other TUs can > > >easily > > > > I would change "i.e." to "e.g." as I see no reason to mandate that users > > actually send the message with git directly (as this requires sendmail > > configuration, and some users may only have access to webmail). The > > formatting > > of the message itself is what matters. > > Git does not require sendmail. It requires an MTA but something simple > and lightweight like msmtp(1) does the job. It takes about 5 minutes to > setup. It doesn't even require an MTA. git is able to send directly to an SMTP server via the perl script that manages mail. See the --smtp-* options in 'git-send-email(1)'. Specifically, the --smtp-server option defaults to 'localhost' which means that it defaults to using a locally found MTA. > Around 90% of all patches that are sent by Git rookie without using `git > send-email` are broken in some way. Most common errors are: > > * Wrong patch format. Patches created with diff(1) or something else. > > * Patch is not sent inline. This makes it damn hard to comment on > specific parts. > > * Broken indentation and line wraps. This often happens when patches are > sent using webmail. Webmail should never be used to send patches > unless you know exactly what you are doing. > > When applying your patch, I had to export your proposal mail to an mbox > file, edit that mbox file and remove the parts that do not belong to the > patch, save the resulting file and apply it using `git am`. This is why > I came up with this... If there is a generally accepted format which is > very convenient, why not use it? > > Also, the document says "should be sent" -- not "must be sent". Everyone > who knows what he/she is doing can send the patch using another tool and > hardly anyone will notice. > > > > > To be honest, I don't see the problem with accepting the resulting document > > either. Copying over a single document is no more work than applying a > > patch. > > 1. Most people want to see a diff. Hardly anyone wants to read the whole >document over and over again and scan for minor wording changes every >time. Sending a document means that every TU has to clone the >tu-bylaws Git repository, save the attachment, copy it to the working >directory of the clone and invoke `git diff`. Why? > > 2. Attaching a document makes it a lot harder to comment on specific >parts by using the "quote" function of the mail client, like you did >when replying to my patch :) > > 3. The committer will have to write a commit message and adjust the >author's e-mail address (and maybe also change the author date). > > > > > Perhaps we could also add an additional minor change to this patchset to say > > that the SVP voting period ends either after the designated time OR after > > all > > TUs have voted. With the upcoming changes to the AUR this will be apparent, > > and > > the AUR can stop the vote itself an possibly send an email to the list. > > Ok, I can add this. But I doubt that there will ever be such a > situation. Did we ever have a voting with a participation of 100%? :) > > > > >
Re: [aur-general] Proofreading request
On Tue, Aug 27, 2013 at 10:34:56AM -0500, Doug Newgard wrote: > > > Date: Tue, 27 Aug 2013 10:04:37 +0200 > > From: cju.a...@gmail.com > > To: aur-general@archlinux.org > > Subject: Re: [aur-general] Proofreading request > > > > 2013/8/27 Taylor Lookabaugh > > > >> On 08/27/13 00:35, Clément Junca wrote: > >>> Yes, you're right. Sorry. Here is the good one. > >> You haven't attached anything to this mail. > >> > >> PS: make sure you reply below the quotes in a mailing list, easier to > >> read top to bottom. > >> > > > > That's strange, I see the tar.gz file in my sent mail. Here are the files > > from the archive. > > My notes: > > 1. Get rid of all of the empty variables (groups, provides, etc) > 2. Definitely add the license file to the source array. > 3. The cd .. at the end of the pkgver function is useless. > 4. Applying the patch should be done in a prepare() function, you don't need > a build() function at all in this case. > 5. You don't need || exit 1. The functions are called in a way so it will > already exit if there are errors. > 6. install -D will make the dirs it needs, you don't need to make them > yourself with mkdir -p. > 7. The comment in the pkgver function doesn't match what it's doing, it's not > using a tag. > 8. If you do install the default config file, you should add it to the backup > array so that pacman doesn't overwrite it every time you upgrade. > > I will disagree with the previous posters on a couple of things. > > 1. There's nothing wrong with using ../../LICENSE as long as you know what > dir you're in. Yes. There is. You don't, and you can't know what directories are above you in this case. This PKGBUILD will fail when [[ -n $BUILDDIR ]] is true. More pertinent, not adding the LICENSE file to the source array means that 'makepkg -S' doesn't include this file. That the file is still included is a sign of a manually crafted source tarball and a huge red flag. > 2. There is nothing wrong with cd-ing directly to $_gitname, although I > prefer $srcdir/$_gitname myself
Re: [aur-general] Problem with checksum verification of coreutils-8.21
On Mon, Sep 09, 2013 at 04:31:29PM +0200, Adrien RAFFIN wrote:
> Hi everyone,
>
> I'm currently updating my package ('advcp') and when i use 'makepkg -g'
> the list of checksums is the following:
>
> md5sums=('065ba41828644eca5dd8163446de5d64'
> 'SKIP'
> '5154b45b0e7230e17da802a3db0fd5d5')
>
> How can i get rid of 'SKIP' value and make the original package verified ?
>
> Thank you in advance
>
What's the real problem here? The value of SKIP is intentional and
applied to any source which refers to a VCS resource or gpg signature.
In this case, you're running into the latter. There's no point in
keeping a checksum for the .sig file since it's merely used as an
instrument to further assert the validity of the source tarball.
tl;dr: working as intended.
Re: [aur-general] Source packages in the AUR
On Sat, Sep 14, 2013 at 11:30:28AM +0200, Mort wrote: > This package is useful when one wants to write C/C++ extensions to gawk. > > There's a bunch of header files available only in the source (while there > is one gawkapi.h in the official gawk package, it is not sufficient for > developers who want to build their own extensions). > http://www.gnu.org/software/gawk/manual/html_node/Internal-File-Ops.html > > It works exactly the same way as linux-headers and > https://aur.archlinux.org/packages/ruby-source/ (Correct me if I'm wrong). > They exist mainly not for general users, but for developers who want to > build their own modules from scratch. Even though it is relatively > unpopular to build extensions in gawk, you can't assume the source package > is "useless" in any case. Just let you know what this is intended for. > I think the point is that this package doesn't provide anything that can't already be just as easily obtained via ABS and 'makepkg -o'
Re: [aur-general] Merge request: python2-pyside -> python-pyside
On Mon, Sep 16, 2013 at 03:07:19PM +, Xyne wrote: > Chris “Kwpolska” Warrick wrote: > > >Why not adapt the actual Bash parser (in C) to only read and do stuff > >safely? In most cases, this would be enough. In the others, we > >already have mess in those fields in the AUR. (my C skills are not > >appropriate for this) > That is basically what needs to be done but it is a difficult task. Even if > you > can adapt the Bash source code to return the AST, you would still need to > create an extensive whitelist of executables (both internal and external) that > may be run in order interpolate all of the variables. The code must be able to > detect variable settings nested in the package functions, skip commands that > do > not affect variables (which may require it to work backwards), count loop > cycles to prevent infinite loops, track time to prevent timeouts, etc. And you'd need to do all this work at a level lower than the parser itself to avoid subversion via aliases, functions, and scripts which mask the actual operation's nature... I think I've mentioned this a few times, but I think there's 2 options if you want better parsing on the AUR: 1) Extend .AURINFO, implement it as .SRCINFO in makepkg proper. To date, I think there's been a number of issues which no one has been willing to address to make this a reality. 2) Use a VM (e.g. http://www.vidarholen.net/contents/evalbot/) to evalulate the code. This would require something very similar to the guts of makepkg which understands per-package overrides. The output would be something similar to #1, so really... interested parties should just work on that. > I have thought about this before when I wrote the Bauerbill PKGBUILD parser, > but I gave up trying to find a way to extract the AST using the Bash code. In > the end my code would simply wrap the PKGBUILD in a function, source the file, > spit it out with "set" to homogenize the syntax, and then parse it with > regexes. > > I started writing a Bash parser in Haskell with Parsec but my free time ran > out > and I had to move on to other things. I think that approach would work quite > well if the Bash sources are too tangled to extract the parser, but it is a > huge task for one person (word expansion, string manipulation, all of the > built-ins, etc.). I would be willing to collaborate on that as well, if there > is any interest. You'd probably be interested in shellcheck: http://www.shellcheck.net/ It's written in Haskell, and while it doesn't execute anything, it does understand a large amount of bash syntax. I found an obscure bug in it recently which was quickly fixed by the author (he's a denizen of #bash on freenode).
Re: [aur-general] Merge request: python2-pyside -> python-pyside
On Mon, Sep 16, 2013 at 04:59:03PM +, Xyne wrote:
> Dave Reisner wrote:
>
> >And you'd need to do all this work at a level lower than the parser
> >itself to avoid subversion via aliases, functions, and scripts which
> >mask the actual operation's nature...
> >
> >I think I've mentioned this a few times, but I think there's 2 options
> >if you want better parsing on the AUR:
> >
> >1) Extend .AURINFO, implement it as .SRCINFO in makepkg proper. To date,
> >I think there's been a number of issues which no one has been willing to
> >address to make this a reality.
>
> Wouldn't that need to actually build everything to access the data nested in
> the package functions? That wouldn't necessarily be a bad thing as it would
> require packages to check that the package builds, but in that case you may as
> well just extract the data from .PKGINFO.
>
makepkg doesn't need to build everything to extract this metadata. It's
hacky, but it can do it. Some of the code in makepkg looks like:
for i in pkgver pkgrel epoch; do
local indirect="${i}_override"
eval $(declare -f package_$1 | sed -n
"s/\(^[[:space:]]*$i=\)/${i}_override=/p")
[[ -z ${!indirect} ]] && eval ${indirect}=\"${!i}\"
done
There's other similar stuff for the arch overrides. You can also look at
run_split_packaging() for other magic.
> >2) Use a VM (e.g. http://www.vidarholen.net/contents/evalbot/) to
> >evalulate the code. This would require something very similar to the
> >guts of makepkg which understands per-package overrides. The output
> >would be something similar to #1, so really... interested parties should
> >just work on that.
>
> I honestly think the best approach would be to replace Bash PKGBUILDs with a
> versatile metadata language that can be easily and safely parsed, e.g. JSON
> with
> support for variables and maybe a limited set of custom macros. Build and
> package functions could be moved to external scriptlets, e.g.
> '{"build" : "/path/to/build.sh", ...}'.
>
> Yet another item on my todo list. :P
>
Let's call this PKGBUILD 2.0. We'll throw it in the same camp as AUR
2.0.
>
> >You'd probably be interested in shellcheck:
> >
> >http://www.shellcheck.net/
> >
> >It's written in Haskell, and while it doesn't execute anything, it does
> >understand a large amount of bash syntax. I found an obscure bug in it
> >recently which was quickly fixed by the author (he's a denizen of #bash
> >on freenode).
>
> That is indeed interesting.
Re: [aur-general] RFC: freecad-git
On Sat, Sep 21, 2013 at 10:33:47AM +, Xyne wrote: > Hi, > > Would anyone care to comment on this PKGBUILD? > > AUR: https://aur.archlinux.org/packages/fr/freecad-git/PKGBUILD > Pastebin copy: http://pastebin.com/q3ARNgJ6 > > Is this an acceptable clever workaround or an abomination that should be > purged > with fire? > > Regards, > Xyne > > > p.s. OR statements and other boolean operatores really would be nice sometimes But not needed here. If oce and oce-git provide=(opencascade), freecad-git could simply depends=(opencascade).
Re: [aur-general] Delete package gromacs-4.5.6-complete
On Oct 13, 2013 12:12 PM, "Hector Martinez-Seara" wrote: > > Hi, > I'm the maintainer of gromacs-4.5.6-complete. This package was suppose to > be the last gromacs release for the gromacs 4.5.x family required by some > applications. Another release has appeared gromacs 4.5.7. I have > incorporated these package to AUR. Therefore please delete the previous > package. > > > https://aur.archlinux.org/packages/gromacs-4.5.6-complete/ Why wouldn't you just name it gromacs-4.5-complete? Repeating the full version in the pkgname is rather redundant. > > Thanks in advance, > Hector > > -- > Hector Martínez-Seara Monné > mail: hse...@gmail.com > Tel: +34656271145 > Tel: +358442709253
Re: [aur-general] architecture question
On Thu, Oct 24, 2013 at 03:40:50PM +0200, pon...@creshal.de wrote: > On 10/24/2013 12:27 PM, 徐林 wrote: > > I think you perhaps not to do so. > > https://wiki.archlinux.org/index.php/Pkgbuild#arch ArchLinux ARM > > Edition seems not to use AUR?Or actually ArchLinux ARM also use the > > same AUR as i686/x86_64 ? > > They also use the aur packages afaik. > > 2013/10/24 Kuba Serafinowski > > I recently got several requests to include armv7h in arch() of my > > PKGBUILDs, is it okay to do it even though it's not officially > > supported? > > If you feel uncomfortable with including an unoffical architecture, > you could talk to upstream if they do anything platform specific and > if not just use "any" in the arch() array. Compiling is platform specific. Do not use 'any' for packages which include compiled code. > But I agree with wormzy tykashi and would just include armv*.
Re: [aur-general] Support for source mirror lists in PKGBUILD
On Thu, Oct 31, 2013 at 08:32:49PM +, Jerome Leclanche wrote: > What about reusing the "filename" feature; if it sees multiple times > the same files it treats it as a mirror, eg. > "file.tar.gz::http://example.com/file.tar.gz"; > "file.tar.gz::http://mirror.example.com/file.tar.gz"; > > J. Leclanche This can't work. If the first source fails to download, makepkg will abort.
Re: [aur-general] Support for source mirror lists in PKGBUILD
On Thu, Oct 31, 2013 at 04:51:38PM -0400, Ido Rosen wrote: > On Thu, Oct 31, 2013 at 4:45 PM, Dave Reisner wrote: > > > On Thu, Oct 31, 2013 at 08:32:49PM +, Jerome Leclanche wrote: > > > What about reusing the "filename" feature; if it sees multiple times > > > the same files it treats it as a mirror, eg. > > > "file.tar.gz::http://example.com/file.tar.gz"; > > > "file.tar.gz::http://mirror.example.com/file.tar.gz"; > > > > > > J. Leclanche > > > > This can't work. If the first source fails to download, makepkg will > > abort. > > > > What about just detecting if source is an array/list (keep current > behavior), or a dictionary/lookup table (new fancy mirror behavior)? If > it's a dictionary/lookup table, then try all mirrors before failing a > source download. > > For examples of how to create lookup tables in bash, see > http://stackoverflow.com/questions/1494178/how-to-define-hash-tables-in-bash... bash4's associative arrays define a 1:1 mapping of string to string. You cannot have multiple elements in the "value." Not to mention that we won't be changing the format of the 'source' variable any time soon.
Re: [aur-general] espeakup's service file yet again lol
On Thu, Nov 14, 2013 at 07:27:39AM -0500, Storm Dragon wrote: > Hi, > > The service works as expected, e.g. systemctl start espeakup@en-us.service > starts the US english voice. The problem is, varients do not work. systemctl > start espeakup@en-us+m2.service just uses the default voice, British english, > instead of the selected en-us and varient m2. I have read through the man > page, and from what I gather, it should work. So, am I missing something, or > have I found a bug? > Attached is the service file. > Thanks > Storm > -- Instanced unit files only really make sense when you expect that the service can be spawned multiple times. This isn't the case here. If users want to override the default language, then they can create an entry in /etc/systemd/system/espeakup.service.d to fixup the ExecStart line.
Re: [aur-general] espeakup's service file yet again lol
On Thu, Nov 14, 2013 at 04:25:04PM -0500, Storm Dragon wrote: > Hi, > I created the file /etc/systemd/system/espeakup.service.d and added: > ExecStart=/usr/bin/espeakup --default-voice=en-us+m3 > After reloading espeakup.service, it still uses the default voice. Do I have > the syntax wrong? > I am using the plain espeakup.service file, not espeakup@.service. > Thanks > Storm If you do nothing else today, please convince yourself that top posting is the root of all evil, the destroyer of biblical cities, and the kicker of pets everywhere. 'systemctl status' and 'systemctl show' will both show you the command line systemd used to start the service. If running that yourself from the commandline yields different results, then there's something weird going on.
Re: [aur-general] 'provides' info in AUR
On Tue, Dec 10, 2013 at 10:45:58PM +0800, 郑文辉(Techlive Zheng) wrote: > 2013/12/10 Karol Blazewicz : > > On Tue, Dec 10, 2013 at 2:18 PM, 郑文辉(Techlive Zheng) > > wrote: > >> Hey, I wonder if it is possible to query the `provides` of a package in > >> AUR? > > > > Is e.g. 'cower -ii wine-git' good enough? > > Acctually, I want to know if it is possible to query the AUR through > API to know what packages provide the desired package. e.g. I query > for packages provived 'wine', and get I get 'wine-git' and others. > Does cower do that? No, cower doesn't do this because the AUR's RPC interface doesn't do this.
Re: [aur-general] 'provides' info in AUR
On Tue, Dec 10, 2013 at 10:54:42PM +0800, 郑文辉(Techlive Zheng) wrote: > 2013/12/10 Dave Reisner : > > On Tue, Dec 10, 2013 at 10:45:58PM +0800, 郑文辉(Techlive Zheng) wrote: > >> 2013/12/10 Karol Blazewicz : > >> > On Tue, Dec 10, 2013 at 2:18 PM, 郑文辉(Techlive Zheng) > >> > wrote: > >> >> Hey, I wonder if it is possible to query the `provides` of a package in > >> >> AUR? > >> > > >> > Is e.g. 'cower -ii wine-git' good enough? > >> > >> Acctually, I want to know if it is possible to query the AUR through > >> API to know what packages provide the desired package. e.g. I query > >> for packages provived 'wine', and get I get 'wine-git' and others. > >> Does cower do that? > > > > No, cower doesn't do this because the AUR's RPC interface doesn't do this. > > > Okay, understand, so that's a todo, I guess. Well, sure... but I suspect this will never make it into the AUR, given the current implementation of a lot of things. For a universal solution, you'd need to: 1) Extend the PKGBUILD parser to parse provides. This alone is problematic since people insist on dumping split packages on the AUR. There's also plenty of reasons not to extend the PKGBUILD parser in its current form. 2) Extend the DB schema to store and relate the newly parsed provides. 3) Extend RPC responses to include the provides in info/search responses. 4) Add a flag to the search API to allow searching by providers (because this shouldn't be the default behavior, lest you break existing tools). 5) Reparse every single package in the AUR so that steps 1-4 are actually meaningful. The half-assed solution would be to draw provides data from .AURINFO, but then you rely on submitters to do the right thing. Inevitably, this would leave you with a useless "feature" as only a fraction of applicable packages would have the data. d
Re: [aur-general] 'provides' info in AUR
On Wed, Dec 11, 2013 at 06:12:59PM +, Jerome Leclanche wrote: > On Wed, Dec 11, 2013 at 5:52 PM, Sam S. wrote: > > On Tue, Dec 10, 2013 at 4:21 PM, Jerome Leclanche wrote: > > > >> I don't understand why makepkg -S > >> doesn't include the .PKGINFO file from makepkg (and subsequently the > >> AUR would use that if present instead of the grep system which fails > >> as soon as variables/expansions are involved which is every other > >> package). All the implementation is there. > >> > > > > It would probably be better then what we have now, but a perfect solution > > would also account for PKGBUILDs that use Bash conditionals to set > > different variables on i386 systems than on x86_64 systems (which is pretty > > common among AUR packages that package upstream binaries rather than > > compiling from source). > > > > Reading values from .PKGINFO would populate the AUR with the values for > > whichever architecture the package uploader happened to use. (So if the > > maintainer changes, or the same maintainer works on different computers, a > > simple re-upload of an AUR package could suddenly change the package's > > meta-info, i.e. the AUR would become more "fragile".) > > > > Of course, the "perfect solution" would be pretty difficult to implement. > > Gentoo had a GSoC project last year [1], to implement an efficient and safe > > (side-effect free) limited Bash parser / pseudo-interpreter in C++, > > sufficient to extract all necessary values from Genoo's equivalent of > > PKGBUILDs. Surely, this could have been useful for the AUR as well. But I > > can find no evidence of continued project activity after the GSoC period > > ended, so it appears they have given up... :( > > > > --- > > [1] http://dev.gentoo.org/~qiaomuf/libbash.html > > I love the fact someone could be working on a bash parser but that > solution is *insane*. It's designed to be incomplete, and the project appears very dead. > This is a solved problem: use a metafile compiled by whatever tools > you use in your distro/domain that can be parsed safely and easily. > For Arch, those are PKGINFOs. No, go see historical conversations about a mythical .SRCINFO -- this is what .AURINFO is based on. .SRCINFO is vaporware right now, and I again refer you to unresolved discussions about how it would handle split packages and package-specific overrides. > Good point on the differences per arch. I guess the obvious solution > that comes to mind here is to have makepkg -S generate the source > files for each arch value (eg. PKGINFO.x86_64, etc) but that's not > necessarily good and is the subject of another discussion imo. To be clear, .PKGINFO is not the solution here. This file describes a built package (something the AUR explicitly does not support). d
Re: [aur-general] 'provides' info in AUR
On Wed, Dec 11, 2013 at 08:21:44PM +, Jerome Leclanche wrote: > On Wed, Dec 11, 2013 at 6:42 PM, Dave Reisner wrote: > > On Wed, Dec 11, 2013 at 06:12:59PM +, Jerome Leclanche wrote: > >> On Wed, Dec 11, 2013 at 5:52 PM, Sam S. wrote: > >> > On Tue, Dec 10, 2013 at 4:21 PM, Jerome Leclanche > >> > wrote: > >> > > >> >> I don't understand why makepkg -S > >> >> doesn't include the .PKGINFO file from makepkg (and subsequently the > >> >> AUR would use that if present instead of the grep system which fails > >> >> as soon as variables/expansions are involved which is every other > >> >> package). All the implementation is there. > >> >> > >> > > >> > It would probably be better then what we have now, but a perfect solution > >> > would also account for PKGBUILDs that use Bash conditionals to set > >> > different variables on i386 systems than on x86_64 systems (which is > >> > pretty > >> > common among AUR packages that package upstream binaries rather than > >> > compiling from source). > >> > > >> > Reading values from .PKGINFO would populate the AUR with the values for > >> > whichever architecture the package uploader happened to use. (So if the > >> > maintainer changes, or the same maintainer works on different computers, > >> > a > >> > simple re-upload of an AUR package could suddenly change the package's > >> > meta-info, i.e. the AUR would become more "fragile".) > >> > > >> > Of course, the "perfect solution" would be pretty difficult to implement. > >> > Gentoo had a GSoC project last year [1], to implement an efficient and > >> > safe > >> > (side-effect free) limited Bash parser / pseudo-interpreter in C++, > >> > sufficient to extract all necessary values from Genoo's equivalent of > >> > PKGBUILDs. Surely, this could have been useful for the AUR as well. But I > >> > can find no evidence of continued project activity after the GSoC period > >> > ended, so it appears they have given up... :( > >> > > >> > --- > >> > [1] http://dev.gentoo.org/~qiaomuf/libbash.html > >> > >> I love the fact someone could be working on a bash parser but that > >> solution is *insane*. > > > > It's designed to be incomplete, and the project appears very dead. > > > >> This is a solved problem: use a metafile compiled by whatever tools > >> you use in your distro/domain that can be parsed safely and easily. > >> For Arch, those are PKGINFOs. > > > > No, go see historical conversations about a mythical .SRCINFO -- this is > > what .AURINFO is based on. .SRCINFO is vaporware right now, and I again > > refer you to unresolved discussions about how it would handle split > > packages and package-specific overrides. > > > >> Good point on the differences per arch. I guess the obvious solution > >> that comes to mind here is to have makepkg -S generate the source > >> files for each arch value (eg. PKGINFO.x86_64, etc) but that's not > >> necessarily good and is the subject of another discussion imo. > > > > To be clear, .PKGINFO is not the solution here. This file describes a > > built package (something the AUR explicitly does not support). > > > > d > > Care to explain the reasoning? I'm looking at a few example PKGINFOs > and they contain nothing that can exclusively be generated at > package() or build() time (other than pkgver but that's already the > case currently). > > J. Leclanche Here's a few reasons that come to mind: 1) As you've already discovered, you'd need a .PKGINFO file for every potential architecture, rather than just a .SRCINFO which might describe what architectures are known available. A .SRCINFO could express all package and architecture specific overrides. The fact that an override exists might be a useful bit of information to convey. 2) .PKGINFO doesn't contain things that are useful for source packages, like, say... the source URL? checksums? 3) You can't possibly express split packages well. Having pkgname fields in a .SRCINFO would mean you could describe all packages created by a PKGBUILD rather than having some loose association between a PKGBUILD and some possible .PKGINFO files which it might have generated. This is about *source* packages. The metadata needs for source packages are not the same as the needs for binary packages.
Re: [aur-general] 'provides' info in AUR
On Thu, Dec 12, 2013 at 08:47:49AM +1000, Justin Dray wrote: > What is to stop us using both? I don't think anyone has said we should stop > parsing the PKGBUILD for the AUR and exclusively parse a .PKGINFO instead. We should stop parsing the PKGBUILD for the AUR and exclusively parse a .SRCINFO instead.
Re: [aur-general] JOYOAUTO spam
On Fri, Jan 03, 2014 at 05:00:17PM +0100, Florian Dejonckheere wrote: > On 3 January 2014 16:41, SanskritFritz wrote: > > > Please delete the spam comment by JOYOAUTO here: > > https://aur.archlinux.org/packages/autoaur/ > > > > I don't know of any other occurences in the AUR. > > > > This isn't the first occurrence of spam by the JOYOAUTO account. Isn't it > possible to block/ban the user/IP? The user's account is already suspended. Of course, this doesn't prevent them from creating another account...
Re: [aur-general] Promoting use of .AURINFO
On Sun, Jan 12, 2014 at 02:35:33PM +0100, Lukas Fleischer wrote: > Hi, > > I think we should promote the use of .AURINFO files. Currently, only a > very small fraction of packages use it. A basic description of its > format can be found in the commit message of AUR commit 5a11373 [1]. > Regardless of whether we keep that format or use something entirely > different for metadata later, it is good to have this information stored > somewhere and the format is simple enough to migrate to another format > later. > > I think we should at least come up with a tiny tool to generate this > kind of metadata post-makepkg and put it into the source tarball, then > add some information to the submission section in the official AUR wiki > article [2]. Does anyone have plans to write such a tool? Did anyone > already integrate this functionality into an existing AUR uploader? If > no one steps up, I might attempt to write one on my own in a couple of > days. > > I might also add a deprecation warning for source tarballs without > .AURINFO files in one of the upcoming AUR releases. > > Regards, > Lukas > > [1] > https://projects.archlinux.org/aur.git/commit/?id=5a1137363cb358593a64e0e6d0b0adeb1a9514ff > [2] > https://wiki.archlinux.org/index.php/AUR_User_Guidelines#Submitting_packages This prompted me to resurrect some old code I had written to do data extraction from PKGBUILDs. Sadly, I didn't understand my own code and it quickly proved to be buggy, so I rewrote it from scratch. I think I mostly understand it now ;). It's well structured, but it's still bash with a hefty dose of black magic (I don't believe I'm relying on any undocumented behaviors). What I have now [1] is some generic shell functions which can extract metadata from PKGBUILDs. I suspect that it will handle most of what exists in the official repos. I'm very sure it fails on architecture- specific overrides, and other bizzare corner cases (e.g. see core/linux). Since it *does* execute code, it's success rate is rather high. Of course, you're likely never going to see a 100% solution. The library includes an output format which I've created based on the last discussion from pacman-dev; in particular a post from Allan [1]. This can easily be changed if we forsee undesirable shortcomings. I should note that the format emphasizes split packages as a first class citizen. My hope is that this can be leveraged to introduce proper support for split packages in the AUR eventually. I realize that this probably means work on the AUR side (which I likely won't contribute to) in order to integrate my solution, but I firmly believe it's worthwhile if support for split packages is a desirable goal for the AUR (please tell me it is). Along with this code, I've created two other utilities: - parse_aurinfo.py: A parser implementation for the proposed .AURINFO format written in python. - mkaurball: A shell script which creates a source tarball and appends the generated .AURINFO file to the tarball. There's also a debugging utility which simply imports the lib and dumps an .AURINFO file from a PKGBUILD you point it at. A nice thing to do next might be to create a test harness which compares my extracted data to the pacman DBs and look at the precise failure modes. I know some of the failure modes, but I won't claim to know them all. Cheers, Dave [1] https://www.github.com/falconindy/pkgbuild_reflection [2] https://mailman.archlinux.org/pipermail/pacman-dev/2012-August/015910.html
Re: [aur-general] Promoting use of .AURINFO
On Tue, Jan 14, 2014 at 11:12:17PM +0100, Lukas Fleischer wrote: > On Tue, 14 Jan 2014 at 19:59:28, Dave Reisner wrote: > > [...] > > The library includes an output format which I've created based on the > > last discussion from pacman-dev; in particular a post from Allan [1]. > > This can easily be changed if we forsee undesirable shortcomings. I > > should note that the format emphasizes split packages as a first class > > citizen. My hope is that this can be leveraged to introduce proper > > support for split packages in the AUR eventually. I realize that this > > probably means work on the AUR side (which I likely won't contribute to) > > in order to integrate my solution, but I firmly believe it's worthwhile > > if support for split packages is a desirable goal for the AUR (please > > tell me it is). > > > > Along with this code, I've created two other utilities: > > > > - parse_aurinfo.py: A parser implementation for the proposed .AURINFO > > format written in python. > > - mkaurball: A shell script which creates a source tarball and appends > > the generated .AURINFO file to the tarball. > > > > There's also a debugging utility which simply imports the lib and > > dumps an .AURINFO file from a PKGBUILD you point it at. > > Awesome! I will give it a try soon. Split packages are definitely a > desirable goal for the AUR but that feature requires a lot of work on > the AUR side indeed. I won't be able to do much AUR coding until April > or May, so what I suggest is the following strategy: Naturally. Having the metadata available is only the first step. > * Test your utility. Do some manual tests and automated tests you > described below. Fix common use cases. > > * Create a package that contains mkaurball and put that in [extra] or > [community]. Update all Wiki articles etc., replacing `makepkg > --source` with `mkaurball`. I think you're missing a few steps here. For starters, I don't believe the current .AURINFO parser is capable of consuming the format I'm advertising. Including it without changing the AUR's parser means... Refused uploads? Bad data displayed? It's been suggested a few times in a cousin thread that currently .AURINFO is not widely used. I cloned the AUR to find out how much truth there was to that: 75 out of 56k packages have .AURINFO files (.0001%). So, I think any changes in the AUR to consume a new format should be bothering an inconsequential number of people. > * Add a deprecation warning to the AUR in the upcoming release that is > displayed whenever a source tarball without meta data is submitted. > > * Fix any remaining bugs that are revealed in production use. With the understanding that not *all* bugs will be fixed in the parser itself. Some PKGBUILDs will simply not be supported. I start to wonder if we really shouldn't just bite the bullet and implement PKGBUILDv2 in pacman. I guess that's a much different conversation, though, and we can already make improvements to data richness in the AUR with this approach. Where the data is sourced from should be a simple implementation detail if it changes in the future. > * Add support for split packages in the next major release. At the same > time, try to integrate .SRCINFO support into makepkg (and support both > .AURINFO and .SRCINFO in the AUR, deprecating .AURINFO). > > That way, the format and the meta data generator gets a lot of testing. > The only downside of this approach is that users temporarily need to > switch to `mkaurball` and (probably) switch back to `makepkg --source` > later. This is just herding cats. mkaurball could eventually become a utility that nags you before running 'makepkg --source' on your behalf. At some point, maybe it goes away. > > > > A nice thing to do next might be to create a test harness which compares > > my extracted data to the pacman DBs and look at the precise failure > > modes. I know some of the failure modes, but I won't claim to know them > > all. > > > > Cheers, > > Dave > > > > [1] https://www.github.com/falconindy/pkgbuild_reflection > > [2] > > https://mailman.archlinux.org/pipermail/pacman-dev/2012-August/015910.html
Re: [aur-general] Promoting use of .AURINFO
On Tue, Jan 14, 2014 at 11:12:17PM +0100, Lukas Fleischer wrote: > On Tue, 14 Jan 2014 at 19:59:28, Dave Reisner wrote: > > [...] > > The library includes an output format which I've created based on the > > last discussion from pacman-dev; in particular a post from Allan [1]. > > This can easily be changed if we forsee undesirable shortcomings. I > > should note that the format emphasizes split packages as a first class > > citizen. My hope is that this can be leveraged to introduce proper > > support for split packages in the AUR eventually. I realize that this > > probably means work on the AUR side (which I likely won't contribute to) > > in order to integrate my solution, but I firmly believe it's worthwhile > > if support for split packages is a desirable goal for the AUR (please > > tell me it is). > > > > Along with this code, I've created two other utilities: > > > > - parse_aurinfo.py: A parser implementation for the proposed .AURINFO > > format written in python. > > - mkaurball: A shell script which creates a source tarball and appends > > the generated .AURINFO file to the tarball. > > > > There's also a debugging utility which simply imports the lib and > > dumps an .AURINFO file from a PKGBUILD you point it at. > > Awesome! I will give it a try soon. Split packages are definitely a > desirable goal for the AUR but that feature requires a lot of work on > the AUR side indeed. I won't be able to do much AUR coding until April > or May, so what I suggest is the following strategy: > > * Test your utility. Do some manual tests and automated tests you > described below. Fix common use cases. So this went pretty well. I chose the automated route since I'm a little short on time (traveling tomorrow) and wrote some more python. Basically, it uses my tools to convert PKGBUILD -> .AURINFO -> python, and compares that against the parsed output of 'pacman -Si $repo/$pkg'. PKGBUILDs all come from ABS. As is the nature of ABS, there's bound to be differences between the archived PKGBUILD and the actual PKGBUILD that produced the package currently in the repos. There's bound to be false positives which may vary from day to day. Still, this gives a test bed of ~5000 PKGBUILDs to play with. Out of those, I'm able to fully match the repo 99.1% of the time (including false positives). I can actually boast a 100% strike rate on [extra], as the only differences were caused by out of sync PKGBUILDs which were otherwise correctly parsed. Legitimate problems fell into the expected categories: 1) architecture specifics (examples: core/grub, multilib/dev86) This is obvious, and I knew it would be here. Fixing this requires changes in makepkg. (something like depends_x86_64=(..) or what have you). This cannot reasonably be fixed in any parser. 2) external commands (examples: community/haskell-*, core/perl) I'd suggest that we consider some of these to be false positives or unfixable. The haskell packages all rely on the output of 'pacman -Q ghc' to lock the package to a specific GHC version (I'm not a haskell person). perl just jumps the shark and requires you to be on one of a few Arch servers (it unzips a tarball in a very specific location). 3) core/linux This is an interesting case and gets special mention. The goal of this hackery is to make it easier for folks maintaining custom versions of this PKGBUILD to track and merge changes. I suspect that a legitimate solution to this problem could handled in the PKGBUILD by introducing a new variable, pkgsuffix=, similar to the --with-program-suffix flag that automake offers. The code that I used for all of the above has been pushed, and I'm attaching a tarball of my results from the 4 repos I parsed in case anyone is curious in the gory details. Cheers, Dave parsed_repos.tar.gz Description: Binary data
Re: [aur-general] Promoting use of .AURINFO
On Thu, Jan 16, 2014 at 08:52:46PM +0100, Lukas Fleischer wrote: > On Tue, 14 Jan 2014 at 23:54:28, Dave Reisner wrote: > > On Tue, Jan 14, 2014 at 11:12:17PM +0100, Lukas Fleischer wrote: > > [...] > > > * Test your utility. Do some manual tests and automated tests you > > > described below. Fix common use cases. > > > > > > * Create a package that contains mkaurball and put that in [extra] or > > > [community]. Update all Wiki articles etc., replacing `makepkg > > > --source` with `mkaurball`. > > > > I think you're missing a few steps here. For starters, I don't believe > > the current .AURINFO parser is capable of consuming the format I'm > > advertising. Including it without changing the AUR's parser means... > > Refused uploads? Bad data displayed? > > I didn't read code or test your tool before I wrote the mail, so I > didn't know that you Fair enough... I assumed when I mentioned split packages and referenced Allan's post that it was understood I was going outside of the current .AURINFO format (which is far too simplistic to be of value in the long term). > 1) always add a "pkgbase" section (even to non-split packages), Intentional. > 2) indent some lines using tabs and > > 3) duplicate a lot of stuff in the pkgname section, even if it's >identical to what is listed in the pkgbase section. That shouldn't be the case. What package were you looking at that shows this in the .AURINFO? The goal is that pkgbase section provides the bulk of the metadata -- the individual pkgname sections are only overrides and supplements. The GetMergedPackage def in the python parser illustrates how the base and "overlay" create each output package. > I assumed that the .AURINFO looks as usual for non-split packages and > the pkgbase stuff is just added for split packages. Is there any reason > for having this pkgbase overhead in non-split packages? Because, IMNSHO, this is old fashioned thinking. Everything should be treated as a split package these days, even if the PKGBUILD only produces a single package as output. makepkg's code is moving in this direction as well. It's totally valid to write a PKGBUILD that produces one package, but has a package_$pkgname() function instead of package(). Since we're going to allow human-massaged .AURINFO files, the AUR's parser should probably allow pkgname without pkgbase. This should be simple to handle if you can handle pkgbase + pkgname, as you're essentially just merging your overrides into the empty set. > > > > It's been suggested a few times in a cousin thread that currently > > .AURINFO is not widely used. I cloned the AUR to find out how much truth > > there was to that: 75 out of 56k packages have .AURINFO files (.0001%). > > So, I think any changes in the AUR to consume a new format should be > > bothering an inconsequential number of people. > > Existing packages won't be affected by any .AURINFO change anyway (at > least not on the AUR side). That file is only parsed once when > uploading. > > > > > > * Add a deprecation warning to the AUR in the upcoming release that is > > > displayed whenever a source tarball without meta data is submitted. > > > > > > * Fix any remaining bugs that are revealed in production use. > > > > With the understanding that not *all* bugs will be fixed in the parser > > itself. Some PKGBUILDs will simply not be supported. > > Of course. The good thing is that people can still adjust the meta data > manually if they want, without adding hacks to the PKGBUILD. > > > [...] > > I just did some tests and the results look pretty good indeed. Do you > plan on creating an Arch package for that (as soon as the controversial > points are addressed)? Yep -- sounds good to me. Cheers, Dave
Re: [aur-general] Promoting use of .AURINFO
On Thu, Jan 16, 2014 at 11:46:12PM +, Jerome Leclanche wrote: > On Thu, Jan 16, 2014 at 11:31 PM, Dave Reisner wrote: > > On Thu, Jan 16, 2014 at 08:52:46PM +0100, Lukas Fleischer wrote: > >> On Tue, 14 Jan 2014 at 23:54:28, Dave Reisner wrote: > >> > On Tue, Jan 14, 2014 at 11:12:17PM +0100, Lukas Fleischer wrote: > >> > [...] > >> > > * Test your utility. Do some manual tests and automated tests you > >> > > described below. Fix common use cases. > >> > > > >> > > * Create a package that contains mkaurball and put that in [extra] or > >> > > [community]. Update all Wiki articles etc., replacing `makepkg > >> > > --source` with `mkaurball`. > >> > > >> > I think you're missing a few steps here. For starters, I don't believe > >> > the current .AURINFO parser is capable of consuming the format I'm > >> > advertising. Including it without changing the AUR's parser means... > >> > Refused uploads? Bad data displayed? > >> > >> I didn't read code or test your tool before I wrote the mail, so I > >> didn't know that you > > > > Fair enough... I assumed when I mentioned split packages and referenced > > Allan's post that it was understood I was going outside of the current > > .AURINFO format (which is far too simplistic to be of value in the long > > term). > > Do you have some example .AURINFO files you can post to the list? I've been > dealing with domain-specific packaging a lot the past month and I'm > very interested in a potential solution to all this. Clone my repo and run './reflect /path/to/PKGBUILD'. If you have an ABS tree cloned into /var/abs, you can just run './reflect $repo/$pkg'.
Re: [aur-general] Promoting use of .AURINFO
On Thu, Jan 16, 2014 at 06:31:40PM -0500, Dave Reisner wrote: > On Thu, Jan 16, 2014 at 08:52:46PM +0100, Lukas Fleischer wrote: > > 3) duplicate a lot of stuff in the pkgname section, even if it's > >identical to what is listed in the pkgbase section. > > That shouldn't be the case. What package were you looking at that shows > this in the .AURINFO? The goal is that pkgbase section provides the > bulk of the metadata -- the individual pkgname sections are only > overrides and supplements. The GetMergedPackage def in the python parser > illustrates how the base and "overlay" create each output package. Nevermind this -- I found cases where this happens. Fixed locally, just need to write some regression tests.
Re: [aur-general] Remove a few packages
On Mon, Jan 20, 2014 at 09:30:01PM +0100, Maxime Gauduin wrote: > On Mon, Jan 20, 2014 at 9:22 PM, Maxime Gauduin wrote: > > Except I don't remember ever seeing a python-python-pyfoo in our repos... We would, if python-pyfoo was the name of an upstream project. > > -- > > Maxime > > > > Also we add python in all cases to differentiate python 2 and python 3, > there is no such problem with ruby... No, we add a python- prefix because that's our packaging guidelines for language specific packages. The fact that ruby has no divergent branch which requires separate packaging is irrelevant. The upstream project is called ruby/sdl. The gem is called rubysdl. It seems to me that ruby-rubysdl is the correct name, even if it seems to be redundant. I've merged ruby-sdl into ruby-rubysdl.
Re: [aur-general] Removing stale accounts from the AUR
On Jan 31, 2014 7:17 AM, "Lukas Fleischer" wrote: > > Hi, > > I plan to remove all AUR accounts that have not been used for at least > 500 days (according to the last login time stamp). This affects ~35000 > users, see [1] for a complete list. If your account is on that list and > you think it shouldn't be there, please let me know. > > Side effects: > > * The ~2000 packages maintained by these users will be orphaned. Can we get a list of these packages? If for no other reason than exposure to active people on this list who may want to adopt, but I also suspect that we can probably just purge a bunch of these anyways. > * All ~2 comments written by any of the users will be removed. > * Votes will be retained. > > Regards, > Lukas > > [1] http://sprunge.us/LBSe
Re: [aur-general] Removing stale accounts from the AUR
On Jan 31, 2014 9:18 AM, "Joakim Hernberg" wrote: > > On Fri, 31 Jan 2014 13:17:25 +0100 > Lukas Fleischer wrote: > > > * All ~2 comments written by any of the users will be removed. > > Removing comments might lead to disconnected discussions in the > comments... Can you find an example of a 2 year old comment which is still relevant? > > -- > >Joakim
Re: [aur-general] TU application sponsored by David Reisner
On Mon, Feb 03, 2014 at 11:26:22AM -0800, Anatol Pomozov wrote: > Hi everyone > > I would like to apply for a Arch Trusted User position. It is > sponsored by my co-worker and bright engineer David Reisner. My name is Dave and I approve this message.
Re: [aur-general] TU application sponsored by David Reisner
On Mon, Feb 03, 2014 at 02:49:48PM -0500, Daniel Micay wrote: > On Mon, Feb 3, 2014 at 2:46 PM, Dave Reisner wrote: > > On Mon, Feb 03, 2014 at 11:26:22AM -0800, Anatol Pomozov wrote: > >> Hi everyone > >> > >> I would like to apply for a Arch Trusted User position. It is > >> sponsored by my co-worker and bright engineer David Reisner. > > > > My name is Dave and I approve this message. > > Nice try, David. My GPG signature says you're wrong. pgpiGg0H55Ccv.pgp Description: PGP signature
Re: [aur-general] Removing stale accounts from the AUR
On Wed, Feb 05, 2014 at 07:57:32PM +0100, carstene1ns wrote: > Am 31.01.2014 14:42, schrieb Dave Reisner: > > On Jan 31, 2014 7:17 AM, "Lukas Fleischer" wrote: > [...] > >> Side effects: > >> > >> * The ~2000 packages maintained by these users will be orphaned. > > > > Can we get a list of these packages?[...] > > As nobody with the power to do sql-fu on the AUR server created a list > yet, an ordinary mortal has to step in. > This is the list of packages in alphabetical order: > http://arch.carsten-teibes.de/aur-stuff/aur-cleanup-02-2014/packages_to_orphan.html > > This lists them by Maintainer: > http://arch.carsten-teibes.de/aur-stuff/aur-cleanup-02-2014/packages_to_orphan_by_maintainer.html > > I have queried the AUR RPC interface (yay, 35k requests!) for this list, > ignored all maintainers without packages and give no warranty that it is > correct or complete. I hope that it is useful for someone. > > Btw. I also provide plaintext (s/html/txt/) and Markdown (s/html/md/) > versions of both lists. > > best regards, > carstene1ns > > Actually, I got this list from Lukas a few hours after I mentioned it. But, thanks!
Re: [aur-general] Voting results
On Sun, Feb 16, 2014 at 04:29:12PM -0800, Anatol Pomozov wrote: > Hi > > On 2/16/14, 5:37 AM, Sébastien Luttringer wrote: > > On 16/02/2014 00:54, Lukas Fleischer wrote: > >> On Sat, 08 Feb 2014 at 18:14:21, Lukas Fleischer wrote: > >>> On Mon, 03 Feb 2014 at 20:26:22, Anatol Pomozov wrote: > Hi everyone > > I would like to apply for a Arch Trusted User position. It is > sponsored by my co-worker and bright engineer David Reisner. > [...] > >>> > >>> You can now cast your votes [1]. The voting period ends on 2014-02-15. > >>> Note that intermediate voting results are no longer visible due to a > >>> recent AUR patch. > > > > Welcome. > > Thanks. > > I was following the AUR TODO list [1] and found that it is slightly > out-of-date. Per [2] PGP key signing requires filing a bug to "Keyring" > but I do not see such project at http://bugs.archlinux.org . I believe I > need a special status at bugs website but there is no information in > TODO how I suppose to change the status. > > So my question is who/how to update my status at http://bugs.archlinux.org? I'll take care of filing the bug. It's only visible to current devs and TUs. > > [1] > https://wiki.archlinux.org/index.php/AUR_Trusted_User_Guidelines#TODO_list_for_new_Trusted_Users > [2] > https://mailman.archlinux.org/pipermail/arch-dev-public/2013-September/025456.html > > pgpdHyg2j84nq.pgp Description: PGP signature
Re: [aur-general] Out of date: clasp, gringo
On Wed, Mar 26, 2014 at 10:48:19AM -0400, Zack Buhman wrote: > On Wed, Mar 26, 2014 at 09:52:17AM -0400, Anatol Pomozov wrote: > > On Wed, Mar 26, 2014 at 9:45 AM, Vincent B. wrote: > > > Hi, > > > > > > I am the packager of aspcud and aspcud-svn, an important dependency > > > solver for the OPAM OCaml package manager. > > > > > > Two dependencies, clasp and gringo, have been already packaged in AUR, > > > > Disowned. Adopt and keep improving it! > > This is what package-hijacking looks like. Is it? The previous maintainer has never voted, and their last action on the AUR, as far as I can tell, was June of last year. The only remaining package they have is out of date as of a month ago, in addition to clasp and gringo. I don't think there's any unwarranted "hijacking" happening here. Tangentially related, I think it would make sense to forward the unanswered email (with bounceback, if appropraite) from the current maintainer with any disown request. I think this is a simple measure to try and keep people honest in their requests. Maybe I'm just overly wary of people... d
Re: [aur-general] Out of date: clasp, gringo
On Wed, Mar 26, 2014 at 12:12:41PM -0400, Zack Buhman wrote:
> On Wed, Mar 26, 2014 at 11:00:46AM -0400, Dave Reisner wrote:
> > On Wed, Mar 26, 2014 at 10:48:19AM -0400, Zack Buhman wrote:
> > > On Wed, Mar 26, 2014 at 09:52:17AM -0400, Anatol Pomozov wrote:
> > > > On Wed, Mar 26, 2014 at 9:45 AM, Vincent B. wrote:
> > > > > Hi,
> > > > >
> > > > > I am the packager of aspcud and aspcud-svn, an important dependency
> > > > > solver for the OPAM OCaml package manager.
> > > > >
> > > > > Two dependencies, clasp and gringo, have been already packaged in AUR,
> > > >
> > > > Disowned. Adopt and keep improving it!
> > >
> > > This is what package-hijacking looks like.
> >
> > Is it? The previous maintainer has never voted, and their last action on
> > the AUR, as far as I can tell, was June of last year. The only remaining
> > package they have is out of date as of a month ago, in addition to clasp
> > and gringo. I don't think there's any unwarranted "hijacking" happening
> > here.
>
> Unless I'm completely insane, you're talking about the submitter, not
> the previous maintainer (me, though again I could be delusional)--as
> far as I can tell, there is no (public) mechanism that reveals
> intermediate {orphan,adopt} history.
No, you're not insane. I shouldn't try to sleuth around these things
before I've had coffee. Regardless, Vincent provided evidence that he
contacted the current maintainer (thank you!) some time ago.
Re: [aur-general] Please remove these packages from AUR
On Apr 20, 2014 4:13 PM, "Jesus Alvarez" wrote: > > Please remove the following packages: > > zfs > zfs-utils > spl > spl-utils > > Thanks! > Jesus A. Without any explanation, you want popular, actively maintained packages removed from the AUR? Sounds fishy, care to explain?
Re: [aur-general] AUR 3.0.0-rc1 released
On Wed, Apr 30, 2014 at 06:57:33PM -0500, Doug Newgard wrote:
> On 2014-04-30 17:20, Lukas Fleischer wrote:
> >A first release candidate of the AUR 3.0.0 has been released! You can
> >give it a try at [1]. Note that due to internal changes, the setup at
> >aur-dev.archlinux.org uses a different database than aur.archlinux.org.
> >You should be able login using your regular AUR account, though.
> >
> >The most important changes are:
> >
> >* Full split package support.
> >* Support for {make,check,opt}depends, conflicts, provides, ...
> >* Full support for the new fields in the RPC interface.
> >* Metadata support. Use mkaurball instead of `makepkg --source` to
> > generate source tarballs for the AUR`. You can get it from [2] -- it
> > will eventually be moved to [community].
> >
> >Note that in order to obtain the new fields, you need to request
> >the new
> >version of the RPC API explicitly, like this:
> >
> >https://aur-dev.archlinux.org/rpc.php?type=info&arg=pass&v=2
> >
> >Otherwise, the replies default to the old format for compatibility
> >reasons.
> >
> >Please report any bugs to the AUR bug tracker [3].
> >
> >[1] https://aur-dev.archlinux.org/
> >[2] https://aur.archlinux.org/packages/pkgbuild-introspection-git/
> >[3] https://bugs.archlinux.org/index.php?project=2
>
> It appears that pkgbase is now the important part of a PKGBUILD,
But note that it doesn't need to be included. Same as makepkg, it
defaults to pkgname[0] if it isn't defined.
> that's what people would be requesting deletion or merging on? Makes
> merges a bit tough, since you can't upload a PKGBUILD with a
> different pkgbase but an overlapping pkgname.
You'd be referring to the package by its pkgbase, since that's the
unifying factor. If 'foo' is split into 'python-foo' and 'python2-foo',
you wouldn't ask to merge/delete 'python-foo' or 'python2-foo'. This
doesn't make sense -- you'd just upload a new source tarball with the
modification.
I don't understand your concern over overlapping pkgnames. If you want
to take ownership of existing packages, you should be asking for the
package to be disowned, not merged, same as today.
Re: [aur-general] AUR 3.0.0-rc1 released
On Wed, Apr 30, 2014 at 08:45:16PM -0400, Yichao Yu wrote:
> Hi,
>
> On Wed, Apr 30, 2014 at 8:37 PM, Dave Reisner wrote:
> > On Wed, Apr 30, 2014 at 06:57:33PM -0500, Doug Newgard wrote:
> >> On 2014-04-30 17:20, Lukas Fleischer wrote:
> >> >A first release candidate of the AUR 3.0.0 has been released! You can
> >> >give it a try at [1]. Note that due to internal changes, the setup at
> >> >aur-dev.archlinux.org uses a different database than aur.archlinux.org.
> >> >You should be able login using your regular AUR account, though.
> >> >
> >> >The most important changes are:
> >> >
> >> >* Full split package support.
> >> >* Support for {make,check,opt}depends, conflicts, provides, ...
> >> >* Full support for the new fields in the RPC interface.
> >> >* Metadata support. Use mkaurball instead of `makepkg --source` to
> >> > generate source tarballs for the AUR`. You can get it from [2] -- it
> >> > will eventually be moved to [community].
> >> >
> >> >Note that in order to obtain the new fields, you need to request
> >> >the new
> >> >version of the RPC API explicitly, like this:
> >> >
> >> >https://aur-dev.archlinux.org/rpc.php?type=info&arg=pass&v=2
> >> >
> >> >Otherwise, the replies default to the old format for compatibility
> >> >reasons.
> >> >
> >> >Please report any bugs to the AUR bug tracker [3].
> >> >
> >> >[1] https://aur-dev.archlinux.org/
> >> >[2] https://aur.archlinux.org/packages/pkgbuild-introspection-git/
> >> >[3] https://bugs.archlinux.org/index.php?project=2
> >>
> >> It appears that pkgbase is now the important part of a PKGBUILD,
> >
> > But note that it doesn't need to be included. Same as makepkg, it
> > defaults to pkgname[0] if it isn't defined.
> >
> >> that's what people would be requesting deletion or merging on? Makes
> >> merges a bit tough, since you can't upload a PKGBUILD with a
> >> different pkgbase but an overlapping pkgname.
> >
> > You'd be referring to the package by its pkgbase, since that's the
> > unifying factor. If 'foo' is split into 'python-foo' and 'python2-foo',
> > you wouldn't ask to merge/delete 'python-foo' or 'python2-foo'. This
> > doesn't make sense -- you'd just upload a new source tarball with the
> > modification.
> >
> > I don't understand your concern over overlapping pkgnames. If you want
> > to take ownership of existing packages, you should be asking for the
> > package to be disowned, not merged, same as today.
>
> I'm not sure if this is the original concern but one of my concern
> that might be related is that for example there are two packages
> python-foo and python2-foo which provide the python3 and python2
> versions respectively. What should I do if I want to merge the two
> packages into a split package that provide both. Asking for merge and
> update the package later? AUR won't let me to upload a new version of
> python-foo that provide python2-foo otherwise.
Then you update the package after the merge happens, rather than before
(and perhaps attach your PKGBUILD to the merge request).
Re: [aur-general] AUR 3.0.0-rc1 released
On Thu, May 01, 2014 at 01:04:07PM +0100, WorMzy Tykashi wrote:
> On 1 May 2014 02:30, Doug Newgard wrote:
> >
> >
> > Yep, that was the concern exactly. Nothing insurmountable, just wanting to
> > clarify how it works upfront.
>
> I share this concern. I've just uploaded slim-git [1] to the aur-dev:
>
> pkgbase=slim-git
> pkgname=('slim-git' 'slimlock-git')
>
> If I now wanted to change the pkgbase to something more encompassing, e.g.
>
> pkgbase=slim-git_slimlock-git
>
I don't get it. pkgbase is intended to be no different from what it is
in the binary repositories, e.g.:
linux -> linux linux-headers linux-docs
pacman -> pacman pacman-contrib
What you're proposing here makes no sense.
> I get the following error when I try to upload the aurball
>
> "You are not allowed to overwrite the slim-git package."
>
> I assume this is because my updated PKGBUILD provides slim-git (and
> slimlock-git), but is in essence a completely different package,
> because of the different pkgbase value. In this situation, I cannot
> upload the PKGBUILD and have the old one merged into it, due to the
> conflict.
And if you think about it, this makes sense. If pkgbase 'a' and 'b' both
provide 'libfoo', then what does the URI fragment '/packages/libfoo'
point to? The basic unit of upload and download has essentially changed
to 'pkgbase' rather than 'pkgname', but there's still a uniqueness
constraint between package names.
> As I understand it, my options are to either upload the new PKGBUILD
> with different/temporary pkgnames, request to have the packages
> merged, then undo the rename and upload the updated PKGBUILD again,
> with the original pkgnames.
>
> The other option, as Dave has suggested, is to submit the updated
> PKGBUILD along with the merge request. Is this ideal, or would a patch
> that can be applied directly onto the existing PKGBUILD be a better
> idea? (or in this case, where a patch would be overkill, is it
> preferable to just ask a TU to make the changes directly to the
> PKGBUILD?)
Allowing anyone to edit PKGBUILDs and tarballs on the webserving side as
a matter of procedure should never happen. This isn't secure at all.
> Or alternatively, should pkgbase changes be disallowed completely,
> except where it's really necessary?
Not sure what this accomplishes. If there's no pkgbase, it's just
assumed to be whatever ${pkgname[0]} expands to. This is a carryover
from makepkg.
> Cheers,
>
>
> WorMzy
>
> [1] https://aur-dev.archlinux.org/pkgbase/slim-git/
Re: [aur-general] AUR 3.0.0-rc1 released
On Thu, May 01, 2014 at 02:04:42PM +0100, WorMzy Tykashi wrote:
> On 1 May 2014 13:29, Dave Reisner wrote:
> > On Thu, May 01, 2014 at 01:04:07PM +0100, WorMzy Tykashi wrote:
> >> On 1 May 2014 02:30, Doug Newgard wrote:
> >> >
> >> >
> >> > Yep, that was the concern exactly. Nothing insurmountable, just wanting
> >> > to
> >> > clarify how it works upfront.
> >>
> >> I share this concern. I've just uploaded slim-git [1] to the aur-dev:
> >>
> >> pkgbase=slim-git
> >> pkgname=('slim-git' 'slimlock-git')
> >>
> >> If I now wanted to change the pkgbase to something more encompassing, e.g.
> >>
> >> pkgbase=slim-git_slimlock-git
> >>
> >
> > I don't get it. pkgbase is intended to be no different from what it is
> > in the binary repositories, e.g.:
> >
> > linux -> linux linux-headers linux-docs
> > pacman -> pacman pacman-contrib
> >
> > What you're proposing here makes no sense.
> >
>
> Of course not, I'm an end user. ;)
SSDD. I fully recognize that we're extending the "attack surface" for
users to do really stupid things. I think the benefits will far outweigh
the negatives, and maybe there will be opportunities to automate more,
reducing the reliance on human intervention for day to day operation.
> This is just an example of something someone may try to do for
> whatever reason. It fails, and quite rightly so, you can't have two
> different pkgbases providing the same packages as each other. The
> question remains whether people should be able to alter the pkgbase of
> a split package. If not, that's fine. But if they are, how are they
> supposed to do so? Does it/should it require TU intervention?
Ask for your pkgbase to be deleted, then upload the new one. Or, play
games with the package naming in the new package you upload beforehand,
and have it merged. Afterwards, upload the real PKGBUILD.
> >> I get the following error when I try to upload the aurball
> >>
> >> "You are not allowed to overwrite the slim-git package."
> >>
> >> I assume this is because my updated PKGBUILD provides slim-git (and
> >> slimlock-git), but is in essence a completely different package,
> >> because of the different pkgbase value. In this situation, I cannot
> >> upload the PKGBUILD and have the old one merged into it, due to the
> >> conflict.
> >
> > And if you think about it, this makes sense. If pkgbase 'a' and 'b' both
> > provide 'libfoo', then what does the URI fragment '/packages/libfoo'
> > point to? The basic unit of upload and download has essentially changed
> > to 'pkgbase' rather than 'pkgname', but there's still a uniqueness
> > constraint between package names.
> >
>
> I understand this, and aren't trying to argue against it.
>
Right, this was just an extrapolation.
> >> As I understand it, my options are to either upload the new PKGBUILD
> >> with different/temporary pkgnames, request to have the packages
> >> merged, then undo the rename and upload the updated PKGBUILD again,
> >> with the original pkgnames.
> >>
> >> The other option, as Dave has suggested, is to submit the updated
> >> PKGBUILD along with the merge request. Is this ideal, or would a patch
> >> that can be applied directly onto the existing PKGBUILD be a better
> >> idea? (or in this case, where a patch would be overkill, is it
> >> preferable to just ask a TU to make the changes directly to the
> >> PKGBUILD?)
> >
> > Allowing anyone to edit PKGBUILDs and tarballs on the webserving side as
> > a matter of procedure should never happen. This isn't secure at all.
> >
>
> I must have misinterpreted what you said earlier about sending the
> PKGBUILD with the merger request. I assumed TUs had this capability. I
> agree that it's not secure.
>
> >> Or alternatively, should pkgbase changes be disallowed completely,
> >> except where it's really necessary?
> >
> > Not sure what this accomplishes. If there's no pkgbase, it's just
> > assumed to be whatever ${pkgname[0]} expands to. This is a carryover
> > from makepkg.
> >
>
> I know this. I'm meaning in regards to split packages specifically.
>
Still doesn't make sense. The same rule applies, regardless of whether
or not you split the package.
d
Re: [aur-general] Change email address on AUR
On Sat, May 03, 2014 at 05:21:44PM +0200, Tristelune wrote: > On Sat, May 03, 2014 at 12:11:00AM -0400, Daniel Micay wrote: > > On 02/05/14 07:24 PM, Tristelune wrote: > > > Nobody can tell me, where I have to change my email address or what is > > > wrong ? If I asked at the wrong place, can somebody tells me where I > > > can ask ? > > > > On aur.archlinux.org you can go to the My Account page and edit the > > email address. > > It's what I did and I think it didn't work. To be sure: could somebody > write a comment for the package gscan2pdf ? I will check if I still have > the problem. > > Thanks! > If you changed your email address, then there's nothing more to do on that end. If you aren't receiving emails for that specific package, then make sure you've opted into receiving notifications in the "Package Actions" sidebar of the package page.
[aur-general] [aur-dev] testing burp and AUR 3.0.0
Hi all, If you don't care about beta-testing the new AUR or burp, you can stop reading. I've rewritten burp over the weekend and included support for some minor changes that went into the uploader "interface" with AUR 3.0.0. I'm very interested in beta testers and bug reports before I tag a release. If you'd like to help out, please install burp-git[1], and send bug reports to me at github. If you'd like to test burp against the new AUR, you'll need to use the undocumented --domain flag with a value of aur-dev.archlinux.org. Note that packages uploaded to aur-dev will require that they're made with mkaurball[2]. Cheers, Dave [1] https://aur.archlinux.org/packages/burp-git/ [2] https://aur.archlinux.org/packages/pkgbuild-introspection-git
Re: [aur-general] ttf-droid-sans duplicate of community/ttf-droid?
On May 28, 2014 5:23 PM, "Pedro Alejandro López-Valencia" < palop...@gmail.com> wrote: > > El may 28, 2014 6:50 PM, "Justin Dray" escribió: > > > > I thought he was being sarcastic, and was implying that we should delete > > it, because what is the point of saving a couple MB on removing a small > > portion of a font at the expense of more packages to maintain. > > I am dead serious; that's what split packages are for. We split packages to do things like: - avoid large documentation dumps in otherwise small packages - provide intercompatability with other packages - avoid recursive dependencies Splitting a font package to only provide specific weights or styles when they all come from the same source is really just a waste of time. > > And don't think for a second I missed the obvious sarcasm.
Re: [aur-general] AUR 3.0.0 released
On Sun, Jun 01, 2014 at 10:10:35AM -0500, Doug Newgard wrote: > On 2014-06-01 10:09, Johannes Löthberg wrote: > >On 01/06, Doug Newgard wrote: > >>In the AUR, you specifically build packages to install them. When > >>building for binary repos, you build them to upload them for others to > >>install them. HUGE difference. > > > >The AUR is a repository for hosting PKGBUILDs for packages not in the > >repos. Do not conflate the purpose of the AUR with your use of it. > > For my use? Or for how nearly everyone uses it? Come on now, do you really > believe that they main use of the AUR is to run unofficial repos? Consider the idea that the current use of the AUR is the way it is due to the long time lack of support for split packages. I tend to agree with Johannes here.
Re: [aur-general] package blacklist?
On Mon, Jun 30, 2014 at 12:15:40PM -0500, Mike Hobbs wrote: > Yeah, but AFAIK that's necessary, though, in order to replace xorg-server > with a patched version. At least that's the convention that seen elsewhere > with other AUR packages that contain bug fixes. > > Thanks, > - Mike > No, it isn't necessary. You could specify pkgbase=fooforall and pkgname=xorg-server-ipollutetheaur, and this would be fine to create a single package called xorg-server-ipollutetheaur. The pkgbase is merely an identifier which uniquely identifies a PKGBUILD.
Re: [aur-general] Git version
On Mon, Jun 30, 2014 at 06:57:05PM +, c...@free.fr wrote: > Hi > My PKGBUILD is available at > https://aur.archlinux.org/packages/xf/xfreq-2.0-git/PKGBUILD > where source code comes from git > Whenever I update a piece of code, I would like the version be reflected in > pkgver also, so AUR tools like yaourt can inform the user. Any suggestion ? Simply put, you can't do this. PKGBUILDs uploaded to the AUR are immutable. Nothing is going to magically change the pkgver short of you uploading a new PKGBUILD. Users of VCS packages should be following (via RSS or whatever) the upstream repository so that they know when to update. d
Re: [aur-general] Stumped on python split package
On Mon, Jun 30, 2014 at 03:11:54PM -0400, Storm Dragon wrote:
> Hi,
> I must be missing something. When I install python-pypump-git or
> python2-pypump-git, I get the same package. I have other split packages
> installed and they install correctly. Can someone look at this PKGBUILD and
> let me know what I did wrong?
> Thanks
> Storm
> --
>
> --
> Registered Linux user number 508465: https://linuxcounter.net/user/508465.html
> My blog, Thoughts of a Dragon: http://www.stormdragon.us/
> get my public PGP key: gpg --keyserver wwwkeys.pgp.net --recv-key 43DDC193
> How many Internet mail list subscribers does it take to change a lightbulb?
> http://goo.gl/eO4PJ
> "Serpent's kin, born of sin. Dark within, father of the wolf!"
> Amon Amarth - Father of the Wolf
> # Maintainer: Storm Dragon
>
> pkgbase=python-pypump-git
> pkgname=("python-pypump-git" "python2-pypump-git")
> pkgver=v0.5.r76.gc73e093
> pkgrel=2
> pkgdesc="An interface to the pump.io API's."
> arch=('any')
> url="https://github.com/xray7224/pypump";
> license=('GPL3')
> source=("git+https://github.com/xray7224/pypump.git";)
> md5sums=('SKIP')
>
> pkgver()
> {
> cd "${srcdir}/pypump"
> git describe --long --tags | sed -r 's/([^-]*-g)/r\1/;s/-/./g'
> }
>
> package_python-pypump-git()
> {
> depends=('python' 'python-requests' 'python-requests-oauthlib' 'python-six'
> 'python-dateutil')
> makedepends=('python-setuptools')
makedepends in a package function will never be read. This array belongs
in the global section.
> cd "${srcdir}/pypump"
> python setup.py install --root="${pkgdir}/" --optimize=1
> }
>
> package_python2-pypump-git()
> {
> depends=('python2' 'python2-requests' 'python2-requests-oauthlib'
> 'python2-six' 'python2-dateutil')
> makedepends=('python2-setuptools')
Same. Merge this into a global makedepends.
> cd "${srcdir}/pypump"
> python2 setup.py install --root="${pkgdir}/" --optimize=1
So, does the following work?
makepkg -i --pkg python2-pypump-git
makepkg -i --pkg python-pypump-git
If it does, you need to make a prepare function that makes a copy of the
source tarball so that you aren't reusing the same build directories for
2 different builds.
> }
Re: [aur-general] AUR 3.3.0 released
On Jul 9, 2014 8:59 AM, "Evert Vorster" wrote: > > > I don't see the relevance to the point this seemed to be a response to. > > That package may be hard/impossible to maintain, true - but separate > > flags for 'out of date', 'broken', 'wont compile' wouldn't aid that > > situation any. In fact they might make it worse. > Agreed > > > > If one flag just signifies that something is wrong that requires the > > maintainer's attention, it should be easier for users and for > > maintainers. > Yes, don't get hung up on a name. That button could just as easily > have said: "Needs attention" and then it would cover all the bases. Naming is important. Here's an idea: lets call them "comments". They can be freeform text so that you can explain why the package needs attention, rather than just pressing some weirdly labeled button and hoping the maintainer figures it out. > > -- > Evert Vorster > Chief Observer > WG Cook
Re: [aur-general] AUR 3.3.0 released
On Wed, Jul 09, 2014 at 06:28:21PM +0100, Steven Honeyman wrote: > 1. The man pages are installed in /usr/share/man1 instead of > /usr/share/man/man1 (etc) in the current PKGBUILD. Don't guess based > on something you haven't tried or tested. I'm going by the comments. If there's (still) a problem, you haven't brought it up in the past 4 days since the maintainer updated the package. Orphaning the package in this case isn't reasonable. > 2. I couldn't care less about clang right now. I've never used it. I > aim to support as many configurations as possible though. If it was a > "dick move" then it should have been rejected. You clearly do care, otherwise you wouldn't have: a) tried to hijack the package b) brought it up here Please don't top post.
Re: [aur-general] Lost Password
On Fri, Jul 25, 2014 at 04:59:01PM -0300, yermandu wrote: > I lost my password in aur the passreset doesnt send email with link Not sure what email address you're expecting to receive mail at, but the email in your signature is not associated with any AUR account. You've also neglected to mention what username you're attempting to login as. d
Re: [aur-general] Discussion about AUR packages signing
On Thu, Aug 07, 2014 at 09:57:24PM +0200, Fabien Dubosson wrote: > Hi, > > I want to start a discussion about AUR packages signing. If this debate > already happened, it means that I'm not really good with Google or > unfortunate in the keywords I used in my searches: in these cases > forgive me and just give me some pointers. > > TL;DR I personally "trust" some AUR users who have several good-quality > packages, and an optional way to sign AUR packages would permit me > to know that I can build and update their packages without > worrying too much. I did read your proposal, but my comment can be framed in the context of your tl;dr: You don't really seem to want GPG signatures, just a whitelist of package maintainers by name. Any AUR helper could implement support for this today, with no changes to the AUR. d
Re: [aur-general] Java name guideliness
On Fri, Sep 12, 2014 at 08:13:11AM +1000, Justin Dray wrote: > ... Perhaps you could read over this before you post again: https://mailman.archlinux.org/pipermail/aur-general/2014-August/029294.html Cheers, d
Re: [aur-general] Revised rbspeex PKGBUILD
On Wed, Sep 17, 2014 at 04:39:25PM -0400, Storm Dragon wrote: > Hi, > Attached is the new rbspeex PKGBUILD. This is the version that was unjustly > deleted, without warning or explination. > Thanks > Storm Your package is a clear duplicate[1], which explains why it was deleted. [1] https://aur.archlinux.org/packages/rbspeex-git
Re: [aur-general] Java name guideliness
On Tue, Sep 23, 2014 at 05:22:52PM -0300, Pablo Lezaeta Reyes wrote: > 2014-09-23 13:13 GMT-03:00 Marcel Korpel : > > > On Wed, Sep 10, 2014 at 4:22 AM, Det wrote: > > > Enough of that already. Why I chose the "java-8-jdk" naming comes from > > the > > > fact that "java-8-openjdk" sounds like we're trying to do "java- > > version>-". The project name of JDK is not "Oracle JDK", > > and > > > that's why I chose it. Now, OpenJDK apparently still calls these > > projects by > > > their "base name"[3], but _I_ would still prefer (read: I don't > > "refuse"; I > > > prefer) having packages called "jdk8-openjdk" and "jdk" that install in > > > "/usr/lib/jvm/java-8-openjdk/" and "/usr/lib/jvm/java-8-jdk/", > > respectively. > > > > > > This also means we can currently do: > > > > > > $ man java-openjdk8 > > > $ man java-jdk8 > > > > > > To access the man pages. > > > > For what it's worth, I support this naming scheme. > > > > Kind regards, > > Marcel > > > > I preffer ad a hyphen after the version as all the other arch packages do > when is needed. > so my vote is for : > * java-openjdk-8 > * java-jdk-8 > > -- > *Pablo Lezaeta* All the other arch packages? Really? $ pacman -Ssq | grep -Ec '[^-][0-9]+$' 322 $ pacman -Ssq | grep -Ec -- '-[0-9]+$' 5
Re: [aur-general] Java name guideliness
On Wed, Sep 24, 2014 at 01:29:44AM +0200, Marcel Korpel wrote: > On Tue, Sep 23, 2014 at 10:39 PM, Dave Reisner wrote: > > All the other arch packages? Really? > > > > $ pacman -Ssq | grep -Ec '[^-][0-9]+$' > > 322 > > This is not a *completely* fair search, as this resultset also > includes bin86, libx264, xf86-video-i740 and v8, where the number > parts are not indicating version numbers. ;-) > > Kind regards, > Marcel Unfortunately, this also holds true of the other search. spring-1944 isn't version 1944, but an open source RTS called "Spring: 1944". Similarly, 'gl-177' is a flight simulator called "GL-177". This inflates the number of packages by 60%. Unfair! d
Re: [aur-general] mediawiki skin
On Nov 18, 2014 10:53 AM, "arnaud gaboury" wrote: > > > > > It is not my work, > When I said "your" I was thinking to our arch community > > > but since it's published under GPL2 republish any > > changes should be enough. Additionally you could write something in the > > footer or on an dedicated page and link that in the footer. > > I will be pleased to mention somewhere then Why is any of this relevant to aur-general?
Re: [aur-general] [aur-dev] AUR 3.5.0 released
On Sun, Nov 23, 2014 at 12:07:07AM +0100, Lukas Fleischer wrote: > Hello, > > I am pleased to announce that AUR 3.5.0 has been released. The official > AUR setup [1] has already been updated. > > This release adds support for architecture-specific sources (resp. > provides, conflicts, replaces) and for .SRCINFO, both of which will be > included in the next pacman release. Apart from that, the package list > and package base list are now official and available at [2, 3]. There > have also been a couple of internal changes and bug fixes. > > For a comprehensive list of changes, please consult the Git log [4]. As > usual, bugs should be reported to the AUR bug tracker [5]. > > [1] https://aur.archlinux.org/ > [2] https://aur.archlinux.org/packages.gz > [3] https://aur.archlinux.org/pkgbase.gz > [4] https://projects.archlinux.org/aur.git/log/?id=v3.5.0 > [5] https://bugs.archlinux.org/index.php?project=2 Hi, In addition to this, I'll be releasing a new version of mkaurball today which ceases generation of AURINFO and creates SRCINFO instead. If you're using a recent enough pacman-git[0], mkaurball will just forward on makepkg, offering very little of its own logic. Consider this is the beginning of my efforts to deprecate mkaurball. Of of the pacman 4.2.0, mkaurball will be obsolete and will likely be replaced with a script which just yells at you to use makepkg instead. Cheers, dR [0] https://projects.archlinux.org/pacman.git/commit/?id=6029a77ac
Re: [aur-general] Package promotion process
On Fri, Nov 28, 2014 at 11:29:45AM -0600, Troy Engel wrote: > When a package has hundreds of votes, what keeps it from getting > promoted into Community? I'm talking specifically about cower: > > https://aur.archlinux.org/packages/cower/ > > Bootstrapping AUR on fresh installs is manual, what's the reason cower > hasn't been promoted to Community so it's easy to install with pacman > and have AUR usable out-of-the-box? (apologies if this has been > discussed before and I'm opening some sort of hornet's nest) > > -te Fun fact, cower *was* in [community] for a very short period of time: https://lists.archlinux.org/pipermail/arch-dev-public/2010-December/018893.html It shall never return.
Re: [aur-general] [solved] How to FIX YAOURT after current PACMAN upgrade
On Dec 29, 2014 9:19 AM, "Eugenio M. Vigo" wrote: > > El 29/12/2014 11:48, "Ralf Mardorf" escribió: > > > Hi, > > > > I followed ArthurBorsboom's comment from 2014-12-29 09:31 at > > https://aur.archlinux.org/packages/package-query/. > > > > $ sudo pacman -Rdd package-query > > or > > $ sudo pacman -Rdd package-query-git > > then > > $ wget > > https://aur.archlinux.org/packages/pa/package-query/package-query.tar.gz > > $ tar -xzf package-query.tar.gz ; cd package-query ; makepkg -s > > $ sudo pacman -U package-query-1.5-1-x86_64.pkg.tar.xz > > resp. > > $ wget > > https://aur.archlinux.org/packages/pa/package-query-git/package-query-git.tar.gz > > $ tar -xzf package-query-git.tar.gz ; cd package-query-git ; makepkg -sf > > $ sudo pacman -U package-query-git-1.5-1-x86_64.pkg.tar.xz > > > > IOW recompiling with the new lib is needed. > > > > Hth, > > Ralf > > > > Hi, > I only had to run pacman-db-upgrade, as suggested by yaourt itself, and > everything works fine on my system. > > Cheers, > Eugenio Please don't prolong this thread. libalpm.so changed sonames with pacman 4.2. package-query links to libalpm.so. A rebuild is needed to link to the new libalpm.so.9. Your system is far from fine if package-query still links to libalpm.so.8 and continues to work.
Re: [aur-general] AUR 4.0.0 pre-alpha
On Mon, Dec 29, 2014 at 09:49:24PM -0500, Ido Rosen wrote: > Is there currently a script to just create a .SRCINFO from a PKGBUILD? > I don't want any side effects like downloading src packages (i.e. I > don't want to run makepkg or mkaurball), etc. since this is for use in > git filter-branch --tree-filter. There exists a tool in the pkgbuild-introspection git repo[1] which will write a .SRCINFO to standard output when given a PKGBUILD. Pull requests welcome to give it a better name (mksrcinfo?) and some UI. dR [1] https://github.com/falconindy/pkgbuild-introspection/blob/master/introspect
Re: [aur-general] AUR 4.0.0 pre-alpha
On Mon, Dec 29, 2014 at 10:21:17PM -0500, Dave Reisner wrote: > On Mon, Dec 29, 2014 at 09:49:24PM -0500, Ido Rosen wrote: > > Is there currently a script to just create a .SRCINFO from a PKGBUILD? > > I don't want any side effects like downloading src packages (i.e. I > > don't want to run makepkg or mkaurball), etc. since this is for use in > > git filter-branch --tree-filter. > > There exists a tool in the pkgbuild-introspection git repo[1] which will > write a .SRCINFO to standard output when given a PKGBUILD. Pull requests > welcome to give it a better name (mksrcinfo?) and some UI. > > dR > > [1] > https://github.com/falconindy/pkgbuild-introspection/blob/master/introspect Nevermind, this (mksrcinfo) now exists in pkgbuild-introspection-git. Bug reports welcome. dR
Re: [aur-general] AUR password reset
On Sun, Mar 22, 2015 at 05:51:24PM +, Diego Nieto Cid wrote: > Hi > > I'm trying to reset my AUR password but I'm not getting the email with the > confirmation link. > > Can somebody reset my account? No, we can't. You've not provided anything useful in your request. There's no account associated with your email address or real name, and no user named 'dnietoc'. dR
Re: [aur-general] AUR password reset
On Sun, Mar 22, 2015 at 06:39:11PM +, Diego Nieto Cid wrote: > Oh I'm sorry. I have some emails from aur-not...@archlinux.org dating back > to 2011 and 2009. So I thought this email was linked to my account. > > I haven't logged in for a long time so unfortunately I can't remember the > username either. But in one email from aur-notify, someone's comment > referred to me as 'mnieto'. So that probably was my username. > > I once was the owner of package > perl-html-formattextwithlinksandtables[1]. However, > in the page for that package my comments now appear under the name of > "Anonymous". Your account was identified as stale and deleted about a month and a half ago: https://lists.archlinux.org/pipermail/aur-general/2015-February/030231.html > Did my account expired? Should I create a new one? Please do. > Thanks! > > -- > [1] > https://aur.archlinux.org/packages/perl-html-formattextwithlinksandtables/ > > > El dom., 22 de marzo de 2015 a las 15:18, Dave Reisner () > escribió: > > > On Sun, Mar 22, 2015 at 05:51:24PM +, Diego Nieto Cid wrote: > > > Hi > > > > > > I'm trying to reset my AUR password but I'm not getting the email with > > the > > > confirmation link. > > > > > > Can somebody reset my account? > > > > No, we can't. You've not provided anything useful in your request. > > There's no account associated with your email address or real name, and > > no user named 'dnietoc'. > > > > dR > >
Re: [aur-general] Linux packaging
On Tue, Mar 24, 2015 at 07:25:51PM +0100, Javier Domingo Cansino wrote: > Hi, > > I am looking to package rtai, which was already packaged some years ago. I > want to make it easily updatable, and I have a problem. > > RTAI is a kernel patch and some other stuff. > I am now trying to obtain the linux config for an specific arch kernel. > > I was trying to extract it from packages.git, but it's a monstrous repo > and not a good way to obtain the needed object without downloading it all > . > > The svn version is also quite > hacky > , but more affordable, I would svn log, search for the most close version > bump commit and extract that config file (along with the patch). > > Is there any recommended method to build a linux kernel of X version > without having to package the config files? > > Or maybe a git tree that is smaller and reasonable to clone. You can use asp[0] to do a piecemeal checkout. 'asp checkout linux' will give you a tidy git repo with full history of the package. dR [0] https://aur.archlinux.org/packages/asp-git/
[aur-general] [orphan request] deluge-svn
Package 'deluge-svn' needs to be updated to fix missing dependencies. Maintainer hasn't responded to comments on AUR page, nor my email sent on 11/10. http://aur.archlinux.org/packages.php?ID=18502
[aur-general] package deletion request
Created evince-lite [1] without realizing that evince-gtk was aimed at the same purpose. Serves me right for doing this late at night. Please delete my offending package. [1] http://aur.archlinux.org/packages.php?ID=32879 Thanks, Dave
[aur-general] package deletion request
Please delete the package systemd-initscripts-git, which I was, until recently, the owner of. It backs up onto a git repo (also mine) which is no longer useful. Thanks, dave reisner
[aur-general] deletion request: nickle
Please delete the package 'nickle'. It was pushed to extra less than 24 hours after I posted my package. In related news, beware of JGC: he's magical. d
[aur-general] deletion request: kernel26-systemd
Please delete the kernel26-systemd package. It set some flags that are no longer necessary with Arch's 2.6.36 build. thanks, dave reisner
[aur-general] [deletion request] udev-systemd
Please delete. Systemd support is now in testing/udev. thanks, dave
[aur-general] TU Application: Dave Reisner
Greetings! Please consider this my application to become a Trusted User. My name is Dave Reisner, and I'm 27 years old, currently residing in the New York City area. Ionut Biru has graciously offered to sponsor this application. I'm a self-taught programmer, computer enthusiast, an occasional IT consultant, and I enjoy brutal sarcasm & dry wit. During the daytime, I star as a QA website tester, writing automated test scripts with the Selenium framework. At night, I prefer Bash & C, but I also dabble in Go, Java, Ruby, and Python. Although I've only been using Arch for a little over a year now, I've become very much appreciative and endeared to its simplistic style and offer of freedom in administration. I quickly settled into a CLI setup featuring DWM, mutt, ncmpcpp, tmux, etc and filled in any missing gaps with Bash and C programs of my own design. In particular, I wrote cower and burp, which interface with the AUR to do clean and fast downloading and uploading (respectively) from the AUR. Please feel free to visit my Github repositories [1]. I also consider myself to have been an active contributor to the Arch community. I advocate the testing repo (which I use on all the boxes I maintain), I diligently file and follow up with bug reports, providing patches or other solutions whenever possible, and I've made a few (though somewhat minor) code contributions to pacman. Over the course of the past year, I've picked up a number of packages in the AUR [2]. While many of these aren't very popular, I would like to make an effort to bring Systemd into community to make it more accessible. I believe that while it does not necessarily fall directly in line with the "true spirit" of Arch, it's an excellent project and there are many people interested in its offerings within the Arch community. I've been following its development since a month after Lennart made his initial announcement, and I have been the major provider of Systemd packages on the AUR. In addition, I've spoken with Daniel Griffiths and I offered to relieve him of some of his packaging duties (given his hectic schedule), and we agreed on: asciidoc, html2text, and rsnapshot. Eventually, as I become more comfortable with the role, I would like to take on more packages to help insure that our repos stay fresh and full of useful software. Since the recent cleanup. I'm happy to answer any questions you may have. Thanks for taking the time to consider my application. Dave. [1] http://github.com/falconindy [2] http://aur.archlinux.org/packages.php?SeB=m&K=falconindy
Re: [aur-general] TU Application: Dave Reisner
On Mon, Nov 29, 2010 at 10:24:44PM -0600, Thomas Dziedzic wrote: > On Mon, Nov 29, 2010 at 8:15 PM, Christopher Brannon > wrote: > > Dave Reisner writes: > > > >> Please consider this my application to become a Trusted User. My name is > >> Dave Reisner, and I'm 27 years old, > > > > As far as I can tell, you are strongly self-motivated. I admire that > > quality. You also have name-recognition in the community. > > You would make an excellent addition to the team. > > Good luck! > > > > -- Chris > > > > I also remember his nick from IRC, +1 from me. > > I do have a question out of curiosity though, do you have a specific > path in my you would like to take? or nothing specific in mind? > > P.S. "keep doin' what you're doin'" > > Cheers! Beyond what I outlined in my app, I didn't have anything explicit in mind. I'm extremely curious to take a peek at the infrastructure of the repos and see how they're maintained. Given enough time in an environment, I'm the kind of personality that usually finds a way to streamline tasks or improve the already in place tools. Dave
Re: [aur-general] TU Application: Dave Reisner
On Fri, Dec 03, 2010 at 12:08:07AM +1000, Allan McRae wrote: > On 03/12/10 00:01, Kaiting Chen wrote: > >A little tangent but from this page it seems to me that a '-git' or '-svn' > >suffix should only be applied when there is a version of the package without > >that suffix in the name; this is to differentiate between the 'stable' and > >the 'development' version of the same package. > > I think a -git suffix should be used always when the PKGBUILD is > building from git sources. > > Allan This is the interpretation I've always followed. I am however, guilty of one infraction of this by way of systemd-arch-units. I've meant to tag this and turn it into a straight download, but it hasn't happened yet. dave
Re: [aur-general] TU Application: Dave Reisner
On Thu, Dec 02, 2010 at 05:13:56PM +0100, Cédric Girard wrote: > On Thu, Dec 2, 2010 at 4:59 PM, Xyne wrote: > > > > > Packages that are built from vcs but which are based on some form of > > upstream > > "release" should not include the tag in the package name. > > > > I think the simplest rule of thumb would be that if the same PKGBUILD > > generates > > different binary packages depending on when makepkg was run, then it should > > include the suffix in the name. > > > > > These two rules are not the same. For instance the package xbmc-svn [1] is > based on fixed svn version that does not corresponds to any "release" > upstream. It is just tested svn revisions (by the packager) as not every > revisions are usable. > > [1] http://aur.archlinux.org/packages.php?ID=20156 > So doesn't that just mean that we have some packages currently in existance which break the guideline we're trying to establish? I propose that this particular package is named incorrectly, and would be better off as xbmc-devel. dave
Re: [aur-general] voting period for Dave Reisner
On Sun, Dec 05, 2010 at 01:39:13AM +0100, PyroPeter wrote: > On 12/04/2010 07:29 PM, Ionuț Bîru wrote: > >Hi, > > > >the 5 days discussion period have ended. > > > >http://aur.archlinux.org/tu.php?id=42 > > > > 42! > Yup, that's right. 42. Vote wisely, gentlemen. We may very well unfold the meaning of life here.
Re: [aur-general] Tarball Guidelines
On Sun, Dec 05, 2010 at 10:19:01PM -0500, Slash wrote: > On Sun, Dec 5, 2010 at 9:42 PM, keenerd wrote: > > Thanks for all the input. I'm pushing the posts now and it should be > > done in a few hours. For now it is just doing a single pass, but in > > the future I'll set it up to track the RSS. > > > > There is a lot of fun stuff in the AUR. More stats later. For now, > > here is my favorite: > > > > 472 packages had a single PNG. 1 package had 100 PNGs. > > > > For more fun, try to find the bot. He's tagging 4% of packages, so it > > should not be too hard. > > > > -Kyle > > http://kmkeen.com > > > > I would suggest modifying the bot's comments to point out the fact > it's an automated message and not an actual user, so people aren't > replying to it and expecting a response. > > It may make more sense to include this functionality as part of the > upload process and notify the maintainer at that point, so comment > areas aren't filled with bot spam every time there's a new package > revision for packages with legitimate "binary" file usage. > IMO, the AUR shouldn't even warn you about this. Either your tarball passes a set of criteria (described by the packaging guidelines) and it's accepted to the AUR, or its rejected reason and the user can try again. queue mentions of aur is in 'maintenance mode', etc etc... dave
Re: [aur-general] Tarball Guidelines
On Mon, Dec 06, 2010 at 03:20:06PM +0100, Heiko Baums wrote: > In most cases there's a reason for having binaries, icons and the like > in a package. And whether such a package actually has a bad quality or > its contents are necessary can't be decided by a bot. In _all_ cases, binaries are not permissable as stated by the AUR guidelines [1]. Your opinion doesn't change this. A proposal to amend the guidelines can. > > > > > Btw., the QA in AUR is usually pretty good, because comments for a > package are usually written pretty fast by other users or TUs if a > package doesn't respect some guidelines, has bugs or a bad quality or > isn't trustworthy. My day job is QA. I assure you, based on what Kyle found and in my own personal experience, it's not that good. A lot of things do get caught. A lot of things don't. How many packages still don't have an arch= declaration, or still make reference to $startdir? While less offensive, I could give you a list of packages that have 2777 permissions on the tarballed folder. Kyle hasn't even touched parsing the PKGBUILD itself, but I might be tempted to borrow his database and do such a thing. > > And if a maintainer doesn't respond to such comments or doesn't fix > those issues users usually send an orphan request to the mailing list to > be able to fix these issues themselves. > > So there's usually no need for such a bot. > > > I've also come across a bug in the AUR. In short, the tarball URL > > provided by the RPC interface is different from the tarball taken from > > the html page. The RPC tarball is *exactly* what was uploaded. While > > the html tarball has been sanitized. So let's say someone uploads > > something that is not even a tarball. The AUR fixes this and pushed > > it to the html. The RPC link goes to the original, and Mr Robot > > complains. Human looks at html tarball and sees nothing wrong. > > Confusion abound. I'll remove those comments. > > I don't know how all the AUR scripts like yaourt, aurbuild, clyde etc. > retrieve the tarballs from AUR, whether they get it from the HTML or the > RPC interface. And I don't know how the HTML interface should sanitize > packages and what you actually mean with sanitize. But I had absolutely > no such problems with AUR packages, yet. As an author of one of these abominations, I (cower) make an assumption that the package can be found at /packages/%s/%s.tar.gz, simply because the URLPath provided in the JSON reply is not trustworthy. It seems as though the database is populated on upload, rather than after parsing, which leads to these problems. It's not really a big deal. Frankly, if any change were to be made, I'd vote for URLPath to be removed from the JSON reply. dave [1] https://wiki.archlinux.org/index.php/AUR
Re: [aur-general] Tarball Guidelines
On Tue, Dec 07, 2010 at 03:58:25AM +0800, Ray Rashif wrote: > On 6 December 2010 22:47, Dave Reisner wrote: > > On Mon, Dec 06, 2010 at 03:20:06PM +0100, Heiko Baums wrote: > >> In most cases there's a reason for having binaries, icons and the like > >> in a package. And whether such a package actually has a bad quality or > >> its contents are necessary can't be decided by a bot. > > > > In _all_ cases, binaries are not permissable as stated by the AUR > > guidelines [1]. Your opinion doesn't change this. A proposal to amend the > > guidelines can. > > Binaries here means binary executables. Nobody told us to read between > the lines to pick out technical file types (of which an image file > would be a 'binary file'). Fair enough. I took the strict interpretation of this -- non human readable files, including but not limited to: compiled code, images, tarballs, etc. Limiting to binary executables makes a bit more sense. dave
[aur-general] deletion request: dbus-systemd
Good morning, dbus-systemd is now superfluous with the necessary compile flags being added to testing/dbus-core. Please delete dbus-systemd at your convenience: http://aur.archlinux.org/packages.php?ID=40399 thanks, dave
Re: [aur-general] How were those packages created? [WAS: Tarball Guidelines]
On Wed, Dec 08, 2010 at 08:42:35AM +0800, Ng Oon-Ee wrote: > On Tue, 2010-12-07 at 14:47 -0500, keenerd wrote: > > Here are some of my favorites. And some stats about what is in the AUR. > > > > -Kyle > > http://kmkeen.com > > Point of curiosity, how were the listed packages created? Some things > (like including icons) I can see, but things like .swp etc... doesn't > everybody use makepkg --source? > That was part of the point of the exercise. It'd be nice if everyone did, but it's clearly not the case. d
Re: [aur-general] voting period for Dave Reisner
On Sat, Dec 11, 2010 at 10:05:42PM +0200, Ionuț Bîru wrote: > On 12/05/2010 02:54 AM, Dave Reisner wrote: > >On Sun, Dec 05, 2010 at 01:39:13AM +0100, PyroPeter wrote: > >>On 12/04/2010 07:29 PM, Ionuț Bîru wrote: > >>>Hi, > >>> > >>>the 5 days discussion period have ended. > >>> > >>>http://aur.archlinux.org/tu.php?id=42 > >>> > >> > >>42! > >> > > > >Yup, that's right. 42. Vote wisely, gentlemen. We may very well unfold > >the meaning of life here. > > good news. This is the first time, since i'm a TU, when we reached > 100% quorum. > > yes 29 > no 0 > abstain 1 > > Welcome in our team. > > Todo: > https://wiki.archlinux.org/index.php/AUR_Trusted_User_Guidelines#TODO_list_for_new_Trusted_Users > > > -- > Ionuț Wow! I'm just going to play dumb and assume that the high voter turnout was because of all the discussion regarding reform of SVP. Thanks for this opportunity, I'm really looking forward to being a part of the community. dave
Re: [aur-general] Orphan Request
On Sun, Dec 19, 2010 at 01:27:43AM +0100, speps wrote: > Hi, i've sent an e-mail to osc (farid) on 10/12/05 (two weeks ago) > and i've got no response (also on identi.ca), maybe he's too busy. > > Please orphan: > vmpk ==> https://aur.archlinux.org/packages.php?ID=20321 > supercollider ==> https://aur.archlinux.org/packages.php?ID=14863 > minicomputer ==> https://aur.archlinux.org/packages.php?ID=15304 > pdfshuffler ==> https://aur.archlinux.org/packages.php?ID=25657 > cmyktool ==> https://aur.archlinux.org/packages.php?ID=33923 > pyphat==> https://aur.archlinux.org/packages.php?ID=15521 > > Thanks All sent to the orphanage. Thanks, dave
Re: [aur-general] TU Application
On Mon, Dec 20, 2010 at 05:42:15PM +0100, Jelle van der Waa wrote: > Thanks all, let's start reading ;) > > -- > Jelle van der Waa > > On 12/20/10 at 06:31pm, Ionuț Bîru wrote: > > On 12/13/2010 01:29 PM, Stefan Husmann wrote: > > > Am 13.12.2010 11:03, schrieb Ronald van Haren: > > >> On Mon, Dec 13, 2010 at 10:56 AM, Kaiting Chen > > >> wrote: > > >>> On Sun, Dec 5, 2010 at 4:50 PM, Jelle van der Waa > > >>> wrote: > > >>> > > I would like apply to become a TU! Daenyth has decided to sponsor me > > for > > my TU application > > > > >>> > > >>> Voting period starts today right? --Kaiting. > > >>> > > >>> -- > > >>> Kiwis and Limes: http://kaitocracy.blogspot.com/ > > >>> > > >> > > >> It has been eight days since he applied, so yes it should start. > > >> > > >> Ronald > > >> > > > > > > proposal activated. > > > > the results are: > > yes 22 > > no 0 > > abstain 3 > > > > Welcome in the team dude. Here is what you have to do: > > > > https://wiki.archlinux.org/index.php/AUR_Trusted_User_Guidelines#TODO_list_for_new_Trusted_Users > > > > > > -- > > Ionuț I'm changing my vote. Had I know he was a top poster... Ah well, guess we're stuck now. Welcome! ;P dave
Re: [aur-general] Remove ardour3-svn
On Mon, Dec 20, 2010 at 11:30:55PM +0100, Xyne wrote: > Bernardo Barros wrote: > > > Hi, > > > > I suggest to remove ardour3-svn from AUR. It's not ready for use > > yet. See message from the author below. > > > > http://aur.archlinux.org/packages.php?ID=34433 > > > > -- Forwarded message -- > > From: Paul Davis > > Date: 2010/12/20 > > Subject: Re: [LAU] Ardour3 > > To: Bernardo Barros > > Cc: Fabio , linux-audio-u...@lists.linuxaudio.org > > > > > > On Mon, Dec 20, 2010 at 1:05 PM, Bernardo Barros > > wrote: > > > It's not really a oficial arch binary package, paul.. > > > it's a arch user script that builds from svn. > > > > that doesn't make a whole heap of difference. people who use svn are > > at least 1 step closer to understanding that the first step after a > > crash is "svn update". people using arch build scripts ... not so > > much, i suspect. moreover, people using svn are probably (hopefully!) > > on the commit mailing list and can see that the version they got this > > morning is now 8 commits old by lunchtime. again, people using arch > > build scripts ... not so much > > > I don't agree with him. Any real archer will want to use a PKGBUILD to do > this. > Removing it from the AUR will just force people to recreate the same PKGBUILD > themselves and for no good reason. Admittedly the AUR in combination with the > various AUR helpers makes it easy for a casual user to install the package, > but > I don't think there will be a wave of disinterested users installing the > package. Plus those very same AUR helpers make it trivial to quickly update to > the latest version with a single command. > > I recommend leaving it on the AUR while making it *very* clear that it is > strictly for development and testing, and that users should subscribe to the > upstream mailing list. > > You could do this by including very visible instructions in the post_install > message (along with a once-off post_update message to inform existing users). > > This is only my opinion though. I'm interested in the other TUs' views. > > Regards, > Xyne This was kind of my take on it. Upstream is still alive, and the package has a fair number of votes. It's heavily in development, but this seems like the kind of thing that the AUR should be supporting. +1 for leaving it. d
Re: [aur-general] Request delete of samba4-openchange
On Tue, Dec 21, 2010 at 06:11:44PM +0800, Ng Oon-Ee wrote: > http://aur.archlinux.org/packages.php?ID=41471 > > Reason: a duplicate of samba4 > http://aur.archlinux.org/packages.php?ID=40043 > > Background: > Previous maintainer created samba4-openchange because openchange relies > on a specific version of samba4 but samba4 advanced beyond that version. > This is no longer the case, and in addition there doesn't seem to be > much use of samba4 currently except for openchange (this is also the > case in Debian/Fedora). > Deleted. Thanks, d
Re: [aur-general] Cleanup Suggestions
On Sat, Dec 25, 2010 at 04:59:13PM +0200, kevku wrote: > limewire http://aur.archlinux.org/packages.php?ID=9331 > -killed > aniworld-bzr http://aur.archlinux.org/packages.php?ID=33346 > -zombie > ffmpeg-webm http://aur.archlinux.org/packages.php?ID=37312 > -merged into main branch > squashfs-tools-lzma http://aur.archlinux.org/packages.php?ID=31648 > -same as above > bitlbee-msn http://aur.archlinux.org/packages.php?ID=6203 > -duplicate? > bitlbee-bzr-libpurple http://aur.archlinux.org/packages.php?ID=33889 > -duplicate? > most of the stuff in > http://aur.archlinux.org/packages.php?O=0&K=go-o&do_Search=Go&PP=25&SO=a > as libreoffice and its language packs are in extra but dunno somone > might need those i've nuked limewire, ffmpeg-webm, squashfs-tools and bitlbee-msn. bitlbee-bzr-libpurple isn't technically a duplicate. it's compiled with --purple=1 (which extra/bitlbee doesn't use). aniworld-bzr might be inactive, but it still has an upstream. I don't see a reason to delete it. The go-openoffice stuff looks like cannon fodder, but I don't feel comfortable deleting all of it without a little discussion first. thanks, dave
Re: [aur-general] disown request
On Sat, Dec 25, 2010 at 12:59:27PM -0300, Gonzalo Seguel wrote: > please disown the next package > google-earth > http://aur.archlinux.org/packages.php?ID=15270 > > the user dont respond any request, by message in aur page and email, for at > least a few weeks > and, the package is outdated for a weeks > > pd: merry christmas :D Disowned. Happy packaging. d
Re: [aur-general] faust-cvs / faust-git, remove?
On Sun, Dec 26, 2010 at 12:53:01AM -0200, Bernardo Barros wrote: > there are two packages for faust development. > the team switched to git > > faust-cvs http://aur.archlinux.org/packages.php?ID=37082 > faust-git http://aur.archlinux.org/packages.php?ID=44767 faust-cvs has been nuked from orbit. thanks, d
Re: [aur-general] delete svn packages
On Mon, Dec 27, 2010 at 01:22:58PM +, Joao Cordeiro wrote: > The following packages were moved to GIT upstream and have a corresponding > git package in AUR. > > pan-svn [1] > cwiid-svn [2] > tracker-svn [3] > redmine-mysql-svn [4] > kadu-svn [5] > supercollider-svn [6] > gammu-svn [7] > hostapd-svn [8] > > > Thanks in advance, > João Cordeiro > > > [1] http://aur.archlinux.org/packages.php?ID=15951 > [2] http://aur.archlinux.org/packages.php?ID=9855 > [3] http://aur.archlinux.org/packages.php?ID=9555 > [4] http://aur.archlinux.org/packages.php?ID=31275 > [5] http://aur.archlinux.org/packages.php?ID=3623 > [6] http://aur.archlinux.org/packages.php?ID=14862 > [7] http://aur.archlinux.org/packages.php?ID=26737 > [8] http://aur.archlinux.org/packages.php?ID=19812 All but redmine-mysql-svn have been deleted. there doesn't seem to be any indication of the svn repo being dead -- they just added git access. thanks, d
Re: [aur-general] Deletion request for picviz
On Mon, Dec 27, 2010 at 02:48:51PM +0100, Antoine Lubineau wrote: > Hello, > > I have adopted picviz [1] a few days ago to update it, and I chose > to keep the same splitting as upstream, so I have made packages for > libpicviz [2], picviz-cli [3] and picviz-gui [4]. > > Please remove picviz [1], which is now obsolete. > > Thanks, > > Antoine Lubineau > > [1] http://aur.archlinux.org/packages.php?ID=26983 > [2] http://aur.archlinux.org/packages.php?ID=44717 > [3] http://aur.archlinux.org/packages.php?ID=44718 > [4] http://aur.archlinux.org/packages.php?ID=44719 deleted, thanks, d
Re: [aur-general] [arch-dev-public] Breaking the unspoken rule: AUR helper in [community]
On Wed, Dec 29, 2010 at 9:16 PM, Dan McGee wrote: > http://www.archlinux.org/packages/community/i686/cower/ > > Thoughts? I was under the impression we didn't do this, and definitely > on purpose, otherwise people have *no* idea the AUR is different in a > lot of ways. Making people go the "hard way" to get a helper installed > at least presents some (necessary) barrier. > > -Dan > I suppose it depends on what we want the barrier to be. In lieu of one of Xyne's flowcharts, consider the raw interaction with the AUR to be something like: search -> download -> extract -> makepkg -> pacman cower draws the line after extraction, because I consider the process to be trivial up until that point. A completely uninformed user who learns how to use the AUR website and/or cower is still left in the same position after extraction -- they have some strange text files on their hard drive. A monkey* could get this far. The responsibility still lies with the user to understand what they've downloaded and what needs to be done with those files. makepkg, and the understanding of, is too important to be masked by another program. I do, however, understand the concern that existance of a tool in community to fetch said strange files may make them appear to be more supported than unsupported. dave * a real monkey, not one of our users.
Re: [aur-general] Package deletion request
On Sat, Jan 01, 2011 at 09:01:30PM -0700, Thomas S Hatch wrote: > lwt: > https://aur.archlinux.org/packages.php?ID=33268 > Has been replaced by the properly named: > ocaml-lwt: > http://aur.archlinux.org/packages.php?ID=39089 > > Thanks! > > -Thomas S Hatch Package has been defenestrated. Thanks, d
Re: [aur-general] aur bug let me can not update grub4dos
On Tue, Jan 11, 2011 at 10:48:16AM +0800, Daniel Lin wrote: > I've post the bug near half year. > Recently, I got a user require to renew PKGBUILD. > But, I think this is bug of AUR script paring problem. As I know > AUR's program will not modify. So, the simple method is delete the entry, > let me upload again. > > If you know the admin of AUR, could you help me to delete the entry of > grub4dos. > That let me could easy upload a new grub4dos entry. > > https://bugs.archlinux.org/task/20672 I've posted the solution to this on the thread you revitalized this morning. https://bbs.archlinux.org/viewtopic.php?pid=876661#p876661 thanks, dave
Re: [aur-general] Delete request: pysztaki
On Tue, Jan 11, 2011 at 02:00:34PM +0100, György Balló wrote: > Accidentally, I uploaded this package in wrong name, please delete it. > The correct name is pysztaki-svn. Sorry. > > City-busz Deleted with great vengeance and furious anger. thanks, d
Re: [aur-general] Deletion Request
On Tue, Jan 11, 2011 at 02:12:42PM +0100, notizblock wrote: > hi, > i reuploaded the following packages using a python2-pkgname naming scheme: > -https://aur.archlinux.org/packages.php?ID=37035 > -https://aur.archlinux.org/packages.php?ID=22977 > -https://aur.archlinux.org/packages.php?ID=29765 > -https://aur.archlinux.org/packages.php?ID=19942 > > please delete the above packages. > > thx, > -- > bbs: nblock > aur: notizblock Eradicated. Thanks, d
Re: [aur-general] Package deletion request
On Sat, Jan 15, 2011 at 03:19:18PM -0700, Thomas S Hatch wrote: > https://aur.archlinux.org/packages.php?ID=21687 > > is a duplicate of the correctly named ocaml-ocamlgraph, please delete it. > > -Tom Hatch Deleted. Thanks, dave
Re: [aur-general] deletion request - ocamlgraph-withoutfindlib
On Sun, Jan 16, 2011 at 08:29:31AM -0700, Thomas S Hatch wrote: > There was a triple duplicate package of ocamlgraph, I have been working with > the other 2 maintainers to come to a consensus as to how it should be > packaged. A consensus has been reached, please delete the last duplicate! > > https://aur.archlinux.org/packages.php?ID=31755 > > -Tom Hatch Destroyed. Thanks, dave
