Re: [aur-general] IntelliJ IDEA Ultimate's
Reto Kaiser reto at retokaiser.com (Sun Feb 5 12:17:00 UTC 2017) > Det nimetonmaili at gmail.com (Sat Feb 4 15:57:20 UTC 2017) > > I personally prefer the flag thing > [...] > > The "-meta" thing is a little... > [...] > > The cleanest solution may very well be what we have now. > > Agree, the thing with the meta packages is a bit overcomplicated. > How about a single PKGFILE, which creates two packages with the "split > package" mechanism (one with, one without JRE). > @uwolfer wdyt? I can prepare the code. All suggestions so far have been about a single PKGBUILD, so I'm assuming you mean a single source (the larger one), and then removing the jre/ folder from the other. That kind of takes the advantage away of the smaller download (503M vs. 572M), and will always create a conflict after build. Det
Re: [aur-general] Intellij IDEA Ultimate's
Reto Kaiser reto at retokaiser.com (Thu Feb 2 19:38:33 UTC 2017)
(Mailing list didn't accept my message, sorry for sending it again)
I've created the "-bundled-jre" version of the IDEA package after
discussion with the maintainer of the "-ultimate-edition" version
("uwolfer").
Some people want to have the bundled JRE, others would like to use a
system-wide installed JRE. The extra package "intellij-jdk" is not
guaranteed to be the same version than was shipped with the specific IDE.
Together with "pschichtel" we came up with yet another approach using
split- and meta-packages: The main package is
"intellij-idea-ultimate-edition" and depends on
"intellij-idea-ultimate-edition-jre-meta". This JRE meta package is not a
real package, but it is provided by two other packages:
- intellij-idea-ultimate-edition-jre-bundled: The JRE bundled with the
Jetbrains download.
- intellij-idea-ultimate-edition-jre-system: The default "java-environment"
package.
Code can be found here:
> https://github.com/njam/intellij-idea-ultimate-edition
<https://github.com/njam/intellij-idea-ultimate-edition>
I think it would be best to use this to create a single package
"intellij-idea-ultimate-edition". What do you think?
Regards
Reto
I personally prefer the flag thing mentioned by Leonidas (also, what I use in e.g.
nvidia-full-beta-all:
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=nvidia-full-beta-all). The
"-meta" thing is a little...
I'd make the -no-jdk tarball the default, and whenever you change the _IntelliJ_JRE flag to
"1", you would automatically get the one with the bundled JRE (e.g. [[ -d
/usr/share/intellij-idea-ultimate-edition/jre/ ]]), until you'd set _(force_)system_JRE=1 (default
"0", which you'd otherwise never need to touch).
But that's also a little..."manual"... The cleanest solution may very well be
what we have now.
Det
Re: [aur-general] Intellij IDEA Ultimate's
Det said on Thu Feb 2 06:25:58 UTC 2017: Sup, Currently we have 3 non-split IntelliJ IDEA Ultimate's in the AUR (there are other ones too, but they're not duplicates): -https://aur.archlinux.org/packages/intellij-idea-ultimate-edition/ (most popular one, no bundled JRE) -https://aur.archlinux.org/packages/intellij-idea-ue-bundled-jre/ (same, but with bundled JRE) -https://aur.archlinux.org/packages/intellij-jdk/ (just the bundled JRE) We probably don't need all 3, so I wonder we could trim one of these? Det Correction. The "intellij-jdk" is obviously indeed JDK... Det
[aur-general] Intellij IDEA Ultimate's
Sup, Currently we have 3 non-split IntelliJ IDEA Ultimate's in the AUR (there are other ones too, but they're not duplicates): - https://aur.archlinux.org/packages/intellij-idea-ultimate-edition/ (most popular one, no bundled JRE) - https://aur.archlinux.org/packages/intellij-idea-ue-bundled-jre/ (same, but with bundled JRE) - https://aur.archlinux.org/packages/intellij-jdk/ (just the bundled JRE) We probably don't need all 3, so I wonder we could trim one of these? Det
Re: [aur-general] Upstream version numbers that break pacman version comparison
On Tue Nov 22 08:07:20 UTC 2016 Bennett Piater bennett at piater.name wrote: > On 11/22/2016 08:58 AM, brent timothy saner via aur-general wrote: > > what i'd recommend is instead use 8.5 -> 8.5.1 -> 8.5.2 > > > > and then have a _pkgver= variable with the actual string, if it's needed > > later in the build. i.e.: > > It's ugly, but I guess bumping epoch is the only solution here. > > Cheers, > Bennett Dear god no. In this case, the project maintainers themselves luckily stepped in, [1] but bumping epoch on every major release *is* the ugliest thing you could do. Once you add it, that "13:9.4pl3-3" will follow and you'll never get rid of it. You'll have to start a new package. It's one of only *two* variables with a red warning on the Wiki: https://wiki.archlinux.org/index.php/PKGBUILD#Version The "8.5.pl3-1" would have been a very standard way of solving this, and the suggested more plain "8.5.3-1" is fine as well. With JDK/JRE, [2][3] I personally do (or get to do) 8u0 -> 8u1 -> 8u2, etc., as you only get that inconsistent "u0" with one release, but the thing will go on for 3-4 years. [4] [1] = https://coq.inria.fr/bugs/show_bug.cgi?id=5221 [2] = https://aur.archlinux.org/packages/jdk/ [3] = https://aur.archlinux.org/packages/jre/ [4] = http://www.oracle.com/technetwork/java/eol-135779.html Det
Re: [aur-general] "pepper-flash" naming?
On Tue, Nov 15, 2016 at 6:47 AM, Eli Schwartz via aur-general
wrote:
> ...
Eli, if you have things to tell me that you feel you need to get off
your chest, do so privately.
Ranting on this thing back and forth in [aur-general] is useless,
stupid and futile.
My email is right there.
Det
Re: [aur-general] "pepper-flash" naming?
After all this unclarity (especially concerning issues 2 years ago), I think some things might need some clarity. I mean, I guess this really needs summing up... :D (also, sorry about the garbled plain text replies. Just now realized/remembered (hope so) how to do that right in Gmail) On 2016-11-13 21:12, Eli Schwartz via aur-general wrote: > Well, you initially complained about it on 2016-09-14, started nudging > again on 2016-11-02 and 2016-11-12, and on the last occasion proceeded > to get into an internet fight over it (once your nudnik behavior finally > agitated a response to go away) then attempted to appeal to peer > pressure by raising support for your position on the mailing list, using > a stratagem that includes accusations such as "the maintainer is > throwing his tantrum"... I'm sorry but that's bogus. Not only did I ask repeatedly because I wanted to get an answer, but since he gave me _none_, I asked the mailing list instead. That thing about "fighting" and "peeling pressure", I'm sorry, is simply over-sensitive and ridiculous. On 2016-11-13 21:12, Eli Schwartz via aur-general wrote: > At least two people insinuated that you may have a "collecting mania" > and/or a "control mania" for AUR packages (cf. "[aur-general] Should TUs > tolarate inapropiate behavior in the AUR?", Feb. 2016)[1] which would > lend weight to the idea that your irrational investment in this is not > my imagination. First of all, many people seem to _appreciate_ the fact that I keep their package up-to-date in a very consistent manner (of which I have a lot, as you implied) and every now and then they thank me. Makes me happyface. Yes, I maintain 107 packages, most of which are split or -git, so in essence require no extra work. But... if the argument is that I care too much about the general health of AUR... yes, I just don't know at which point does this become a such a major concern, if those apparent quote-unquote-toxic comments of mine are the worst that can happen (see 2nd reply on that). And about that vuze thing you decided to dig up..., well, quick story, over 2 years ago, I flagged the then "vuze-plugin-i2p" out-of-date, because the project was no longer maintained. I posted 3 comments about it to try and give the direct link to the new one (you couldn't edit comments back then, of which by the way, due to my control mania, I finally created a feature request back in April 2013 [1]). This "mildly p*ssed" the maintainer, causing him to create a bug report [2] where falconindy also joined in (apparently still angry at me over a comment that he never admits his mistakes), and the two concluded that I'm 1) "not a very well-socialized individual", and 2) "need a thourough[sic] dusting in public". Asked both in private, but apparently silence had landed in. Second time, slightly over a year ago (July 2015), I suggested a fix of the broken homepage URL in "vuze" to the maintainer (same guy). [3] Well, again, he was incredibly upset by it, calling me an "antisocial self" and actually claiming that I "insulted" him in the past. He then spammed 5 comments of a message beginning with "Hahahaha!" and was never heard from again. (By me, until the apparent mailing list thread this year.) The other person you linked unfortunately didn't (AFAIK) give any names of packages that I had apparently been flagging so can't comment on that. On Mon, Nov 14, 2016 at 9:32 AM, Bartłomiej Piotrowski wrote: > Det, TLDR, a rename is not going to happen. Almost every message or > comment from you is toxic in some way and you can be sure that implying > that member of the project is "throwing a tantrum" after your pointless > AUR comments is not going to bring you anywhere. Thank-you very much, but not only do I see zero "toxicity" or "pointlessness" in my comments, but I'll just conclude this thing suggesting that maybe, possibly you guys may simply need a slightly thicker skin. Really, no offense, no intent to hurt anyone's feelings, but how long have you guys been using the internet? And, you are probably going to stamp this piece as "entirely toxic", but what's important is that the message is out there... but I'm glad I asked, for now I finally got some real arguments about what I was originally asking. :D Thanks for everyone's contributions. [1] = https://bugs.archlinux.org/task/34690 [2] = https://bugs.archlinux.org/task/42481 [3] = https://aur.archlinux.org/packages/vuze/?comments=all Det (_that_ maniac)
Re: [aur-general] "pepper-flash" naming?
On Sun, Nov 13, 2016 at 3:50 PM, Eli Schwartz via aur-general < aur-general@archlinux.org> wrote: > > So, in the mailing list you give your actual reasoning, *after* giving a > cryptic comment in the AUR comments and being rejected, and rightly so, > as a crank. That reasoning is pretty obvious. I have no opinion about the package itself (I certainly do not see the > apparent obviousness of your position) I don't understand what didn't you understand? I'll repeat. In [extra] we have "flashplugin". In AUR we have "pepper-flash". The difference is that of only NPAPI/PPAPI. The source name of the thing is "flash_player_ppapi_linux_..tar.gz", which would be more in line with the "official" "flashplugin" naming. but purely regarding your > behavior, I desperately want you to remain unhappy. > Funny. To my mind it was Scimmia giving the "behavior" (which has actually been going on for quite a good while), but we are in fact allowed to have completely different opinions. For instance, if you don't want to have it renamed, as per disagreeing with my arguments or otherwise, that's fine, but an AUR package not even maintained by me will have zero to do with happiness in my life. :) Det
Re: [aur-general] "pepper-flash" naming?
On Sun, Nov 13, 2016 at 11:42 AM, DJ Lucas wrote: > > No. That has historically been the name. Anyone who is already familiar > with flash on Liunx is likely to use "pepper" as a search term. > Yes, but that's a non-issue because the default is to search by "Name, Description". Same with (Oracle) JDK. Coincidentally, searching for "chromium-pepper-flash" (provides) using a > keyword search in AUR Web does not give any results. I would have suggested > requesting another provides as a compromise, but it seems that doesn't work > as expected. Should it? I thought this was fixed way back in 4.1.0?: https://bugs.archlinux.org/task/43157 Regression? Det
[aur-general] "pepper-flash" naming?
Why hell,
Since the maintainer is throwing his tantrum, I decided it would be good
to ask the mailing list directly, should "pepper-flash" [1] be renamed
to e.g. "flashplugin-ppapi"?
This would be more in line with the official package extra/flashplugin
[2] and also the source URL of the thing itself.
What do you think?
[1] = https://aur.archlinux.org/packages/pepper-flash/
[2] = https://www.archlinux.org/packages/extra/x86_64/flashplugin/
Det
[aur-general] Renaming 'chromium-browser-bin' and 'chromium-nightly'
Hell, and happy April Fools, folks! As you know, we have a long history with a package called 'chromium-browser-bin', [1] which provides the Chromium Continuous builds that are essentially (to some degree) automatically tested Chromium Snapshot builds [2] [3]. It has now come under my maintainership, and undergone some major changes, but the final obstacle remains the most important piece: the very name of the package. This concerns 'chromium-nightly' [4] as well, which provides the aforementioned Chromium Snapshots. My personal pool of suggestions is as follows: - chromium-continuous - chromium-continuous-bin - chromium-nightly - chromium-nightly-bin (only 3 packages follow this scheme [5]) - chromium-snapshot - chromium-snapshot-bin I would preferer omitting the '-bin', but I understand, if people feel that it's important to point out. [1] = https://aur.archlinux.org/packages/chromium-browser-bin/ [2] = http://build.chromium.org/p/chromium [3] = https://groups.google.com/a/chromium.org/d/topic/chromium-discuss/9AK9NME1rIc/discussion [4] = https://aur.archlinux.org/packages/chromium-nightly/ [5] = https://aur.archlinux.org/packages/?K=nightly-bin Thanks for your time, Det
Re: [aur-general] Java name guideliness
On Fri Sep 19 00:02:27 EDT 2014, Pablo Lezaeta Reyes wrote: > but upstream name not necesary mean the name that the encapsulate that > contain the package need to be named. > > There ar a handfull either throw arch and aur history and actual named > packages that not follow the name. > > but too looking to the other packages in aur the version is alwas separate > from the name of the package so in the end - will be > used. > Upstream not give a version or give a "-" or a plain space for versions if > ou are going to follow uptream. I'm sorry, but I didn't understand any of this. Also, please don't top-post, as already stated. Det
Re: [aur-general] Java name guideliness
On Thu Sep 11 14:02:41 EDT 2014, Pablo Lezaeta Reyes wrote: > If look to the pther packages (not java) the fewers who need a version they > apend the versión at the endm so for consistency whit the all others > packages I think is better keep the version at the end: > --: oracle/openjdk-jre-7/8 We can't do that, because our own upstream (the OpenJDK packager) alredy decided on it. To change it you're going to have to start a bug report/feature request on our own packages. If you can change _his_ mind, then we can talk about implementing that in the AUR as well. On Thu Sep 11 18:13:11 EDT 2014, Justin Dray wrote: > The fact that one naming convention or the other being chosen is still not > the issue, it's the fact that in the interim there are *both* packages in > there. Yes, I get that you're eager to get whatever parties out of there ASAP, and sort it out later. Unfortunately, that's not how it's going to play out and this discussion so far has prevented the proper way from happening as well, as I was already pointed out some time ago. Therefore, I'm taking this and my suggestions back directly to the respective maintainers, and only if they want to continue it here, we will. Det
Re: [aur-general] Java name guideliness
More input. On 09/09/14 23:08, Justin Dray wrote: > Part of the issue here however is that now there are both jre7 and > jre7-oracle and so on duplicate packages in the AUR. Yes, but why are you bringing that up as an "issue", as we are trying to decide exactly which one to keep before just removing the other. I think you know neither I nor the maintainers were never for leaving both - we just don't, at this point, know which one. I mean, isn't that like saying: A: We need to figure out the right type of fuel for this car. B: Yes, but the issue is the car doesn't move. A: Well. Yeah.. On 10/09/14 01:20, Pablo Lezaeta Reyes wrote: > Refusal is what happend when two or more not agree in something I never > mention who is refusing who cause both side from the vewpoint of the other > is refusing the other side of view. Who is refusing whom? > One not want use the other guidelines, so using the bare meaning of refusal > that mean not accdept the other. But you see you hit the problem right there. We don't _have_ a guideline for the naming. That's what the debate is about: we are trying to establish one. >> or "this is sick". > Maybe you are overreacting (or I not expresed it corretly), I mean that is > no sane (synonimous of ill synonimos of sick) Ok. Just use "makes no sense". > I thing that is bvous that all are java. so why not something like > -: openjdk-9 or oraclejdk-7. The names in the official repos are "jre/jdk8-openjdk", so that's why the previous suggestion was "jre/jdk8-oracle". However, I believe it should be pretty obvious which one you're dealing with, if a package is named just "jre" or "jdk" (isn't that the ultimate "KISS"?). The "java-" prefix is used for "archlinux-java" (extra/java-common), and already decided upstream. That I would refuse to divert from. On 10/09/14 08:38, P. A. López-Valencia wrote: > My opinion is that the AUR should follow the example set by the Arch > Linux developers in the extra repository and everything else must go, > starting with the jdk/jre pair as clarity trumps over brevity in naming Explained above. As far as I know in all the years I maintained these things, nobody ever confused them with OpenJDK, because that's always mentioned. On 10/09/14 07:43, Rafael Ferreira wrote: > +1 for 'java-8-jdk' and 'java-8-jre' is a good name. Just would be > nice to have the word "Oracle" in the description, so a "yaourt -Ss > oracle" could easily track your package. I agree. Added. Again, to summarize the Java "guidelines": Package name: -<"vendor"> (e.g. jdk8-openjdk, jre7-openjdk) "archlinux-java" name: java--<"vendor">(/jre) (e.g. java-8-openjdk, java-7-openjdk/jre) And what I support for AUR (same as what we had before): Package name: () (e.g. jdk, jre7) "archlinux-java" name: java--(/jre) (e.g. java-8-jdk, java-7-jre/jre) (just java-7-jre unsupported by "archlinux-java") Det
Re: [aur-general] Java name guideliness
On Wed, Sep 10, 2014 at 8:18 AM, Pablo Lezaeta Reyes wrote: > Since the new java-common come to the repo Is now possible have multiple > java, but this bring and open another issue, java naming scheme the guy in > jre/jdk[1] and jre-devel and jdk-devel refuse to follow a convention non > generic name and the other maintaining jre7/jdk7 [2] and > jre7-oracle/jdk7-oracle that do the same [3] refuse to accept or merge > jre7-oracle into jre7 for the same reason even if the jre-oracle was merged > into jre, this is a chaos. > Many packages doing the same in different verion having different name > conventions and ALL arguin bein correct. > > There is need to a conventional standar name scheme or this will be worst, > instead to be kiss this is sick. > There is a name scheme or name convention to follow? First of all, I really *really* urge you to stop using phrases like "refusal" or "this is sick". If that really was the case, it would only split all parties further. It's not "refusal" to talk something through before doing it. In fact, _nowhere_ do I see anybody refusing to do _anything_. The talk in jdk7[1] is discussion on the appropriate name, and what I told everybody both in there and jdk[2] was my view on things and why I did what I had done (use jdk/java-8-jdk as the name, rather than jdk8-oracle/java-8-oracle). You realise how unbelievably easy it is for me to revert to the "jdk8-oracle" approach, if that winds up being the consensus? Or if I somehow wouldn't, then how easy would it be to kick me off from maintaining that thing? 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--". 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. I really didn't like the following at all: $ man java-openjdk8 $ man java8-oracle [1] = https://aur.archlinux.org/packages/jdk7/ [2] = https://aur.archlinux.org/packages/jdk/ [3] = http://openjdk.java.net/projects/jdk8/ Det
[aur-general] Leftover cleanups of February 2014
ged upstream in 'ubuntu-themes' (AUR).
- https://aur.archlinux.org/packages/light-themes/
33) lxpanel-git: Replaced by Gtk+ v3 and Qt versions
('lxpanel2-git'/'lxqt-panel-git' (AUR):
https://en.wikipedia.org/wiki/LXDE#Qt_port).
- https://aur.archlinux.org/packages/lxpanel-git/
34) madx: The uploader (an actual CERN employee) recommends moving to
'madx-svn' (AUR).
- https://aur.archlinux.org/packages/madx/
35) madx-dev: Same thing.
- https://aur.archlinux.org/packages/madx-dev/
36) nct677x: Merged upstream in linux 3.10.
- https://aur.archlinux.org/packages/nct677x/
37) odtwriter: Merged upstream in 'community/python(2)-docutils'.
- https://aur.archlinux.org/packages/odtwriter/
38) ogre-1.7.2: Deprecated version of 'ogre' (AUR).
- https://aur.archlinux.org/packages/ogre-1.7.2/
39) ogre-branch-1.4: Go.
- https://aur.archlinux.org/packages/ogre-branch-1.4/
40) ogre-branch-1.6: To.
- https://aur.archlinux.org/packages/ogre-branch-1.6/
41) ogre-branch-1.6-free: Hell.
- https://aur.archlinux.org/packages/ogre-branch-1.6-free/
42) open-sasc-ng: Merged upstream in 'ffdecsawrapper-git' (AUR).
- https://aur.archlinux.org/packages/open-sasc-ng/
43) openscad-bin: Provided by 'community/openscad'.
- https://aur.archlinux.org/packages/openscad-bin/
44) openscad-bin-amd64: OMG.
- https://aur.archlinux.org/packages/openscad-bin-amd64/
45) openssh-dnssec: Superseded by 'core/dnssec-anchors'.
- https://aur.archlinux.org/packages/openssh-dnssec/
46) pcsclite-libudev: 'community/pcslite' long built with libudev.
- https://aur.archlinux.org/packages/pcsclite-libudev/
47) perl-net-smtp-server: Duplicate of'perl-smtp-server' (correct
naming) (AUR).
- https://aur.archlinux.org/packages/perl-net-smtp-server/
48) perl-net-smtp-tls: Superseded by 'perl-net-smtp-tls-butmaintained'
(an actual naming) (AUR).
- https://aur.archlinux.org/packages/perl-net-smtp-tls/
49) perl-net-smtp-tls-butmaintained: A recommendation for moving to
Net::SMTPS included in Git.
- https://aur.archlinux.org/packages/perl-net-smtp-tls-butmaintained/
50) php-gtk-git: Project finally seems dead, and isn't compatible with
latest PHP.
- https://aur.archlinux.org/packages/php-gtk-git/
51) python-cython: Provided by 'community/cython(2)'.
- https://aur.archlinux.org/packages/python-cython/
52) python-pbldr: Dead.
- https://aur.archlinux.org/packages/python-pbldr/
53) python2-chrome: Merged upstream in 'extra/python(2)'.
- https://aur.archlinux.org/packages/python2-chrome/
54) python2-reddit-git: Duplicate of 'python2-praw-git' (AUR).
- https://aur.archlinux.org/packages/python2-reddit-git/
55) python2-setupdocs: "No longer needed by ETS." ~maintainer
- https://aur.archlinux.org/packages/python2-setupdocs/
56) python2-sumatra-hg: "This should be deleted, I uploaded an old
non-working PKGBUILD." ~maintainer
- https://aur.archlinux.org/packages/python2-sumatra-hg/
57) python3-xlrd: Duplicate of 'python-xlrd' (correct naming) (AUR).
- https://aur.archlinux.org/packages/python3-xlrd/
58) raknet2: Dead.
- https://aur.archlinux.org/packages/raknet2/
59) runbench-bzr: 'Please delete. This package is useless', believes the
maintainer.
- https://aur.archlinux.org/packages/runbench-bzr/
60) scim-thai: Maintainer no longer uses the package and it doesn't have
a single vote.
- https://aur.archlinux.org/packages/scim-thai/
61) texlive-biolinum-type1: Obsolete.
- https://aur.archlinux.org/packages/texlive-biolinum-type1/
62) texlive-libertine-type1: Also obsolete.
- https://aur.archlinux.org/packages/texlive-libertine-type1/
63) vim-pkgbuild: Merged upstream in pacman 4.1.2-4;FS#37036.
- https://aur.archlinux.org/packages/vim-pkgbuild/
64) virtualbox_bin-1: Let.
- https://aur.archlinux.org/packages/virtualbox_bin-1/
65) virtualbox_bin-2: Them.
- https://aur.archlinux.org/packages/virtualbox_bin-2/
66) virtualbox_bin-3: Go already.
- https://aur.archlinux.org/packages/virtualbox_bin-3/
67) vxworks-gcc-toolchain-bin: 'It has been replaced', says the maintainer.
- https://aur.archlinux.org/packages/vxworks-gcc-toolchain-bin/
68) wireshark-plugin-openflow: Merged upstream in
'community/wireshark-(cli|gtk)'.
- https://aur.archlinux.org/packages/wireshark-plugin-openflow/
69) xecjk: "Since tex-* has already included xecjk, this package is no
longer necessary."~maintainer
- https://aur.archlinux.org/packages/xecjk/
70) xf86-video-fbdev-for-displaylink: Merged upstream in
'extra/xf86-video-fbdev'.
- https://aur.archlinux.org/packages/xf86-video-fbdev-for-displaylink/
71) xfswitch-plugin: Obsolete leftover.
- https://aur.archlinux.org/packages/xfswitch-plugin/
72) xnoise-plugins-core: Merged upstream in 'community/xnoise'.
- https://aur.archlinux.org/packages/xnoise-plugins-core/
73) zfs-fuse-git: ' I think this package is obsolete for two reasons:
because kernel zfs support has improved (archzfs) and zfs-fuse package
is more uptodate.'~maintainer
- https://aur.archlinux.org/packages/zfs-fuse-git/
Let's make the AUR a better place,
Det
Re: [aur-general] Renaming: lastpass -> lastpass-pocket / lastpass-universal -> lastpass
On Saturday, June 02, 2013 02:55:20 Felix Yan wrote: > As jomasti adopted lastpass-pocket, I merged lastpass into lastpass-pocket. > > @Det > Now please upload a working "lastpass" package, so I could do the remaining merge. > > (BTW, I dunno what you mean in your other e-mail :x > > Regards, > Felix Yan It was a joke. I figured no one was gonna respond to me unless I bumped the conversation. Anyway, there we go: - lastpass: https://aur.archlinux.org/packages/lastpass/ - lastpass-universal: https://aur.archlinux.org/packages/lastpass-universal/ Det
[aur-general] Renaming: lastpass -> lastpass-pocket / lastpass-universal -> lastpass
On Monday, May 27, 19:43:37 Det wrote: > On Thursday, May 23, 2013 22:08:55 Felix Yan wrote: > > To rename a package, please first submit a new package under the desired new name, then send a merge request to the list. > > > > In your case, please first submit package 'lastpass-pocket', then I or someone else could do the two merges for you, thanks! > Mm, right. Here's the setup again: > > - merge lastpass[1] "info" with lastpass-pocket[2] > - move lastpass-universal[3] to lastpass[1] > > [1] = https://aur.archlinux.org/packages/lastpass/ > [2] = https://aur.archlinux.org/packages/lastpass-pocket/ > [3] = https://aur.archlinux.org/packages/lastpass-universal/ Why are you so mean? Det
[aur-general] Renaming: lastpass -> lastpass-pocket / lastpass-universal -> lastpass
On Thursday, May 23, 2013 22:08:55 Felix Yan wrote: To rename a package, please first submit a new package under the desired new name, then send a merge request to the list. In your case, please first submit package 'lastpass-pocket', then I or someone else could do the two merges for you, thanks! Regards, Felix Yan Mm, right. Here's the setup again: - merge lastpass[1] "info" with lastpass-pocket[2] - move lastpass-universal[3] to lastpass[1] [1] = https://aur.archlinux.org/packages/lastpass/ [2] = https://aur.archlinux.org/packages/lastpass-pocket/ [3] = https://aur.archlinux.org/packages/lastpass-universal/ Det
[aur-general] Renaming: lastpass -> lastpass-pocket / lastpass-universal -> lastpass
Hello, As per the kind suggestions in [1] I'd like to request two things: - renaming lastpass[1] to "lastpass-pocket" - renaming lastpass-universal[2] to "lastpass" [1] = https://aur.archlinux.org/packages/lastpass/ [2] = https://aur.archlinux.org/packages/lastpass-universal/ thanksthanksthanksthanks Det
[aur-general] Removal request - devmon-git
Maintenance of devmon-git[1] has been moved to udevil-git[2]. [1] devmon-git = https://aur.archlinux.org/packages.php?ID=57682 [2] udevil-git = https://aur.archlinux.org/packages.php?ID=59463 Det
Re: [aur-general] Removal request: virtualbox-sun
No responses in a week. Trust me, -bin[1] covers everything that -sun[2]
does. In addition it's the original one and it has more votes.
We don't need both.
[1] virtualbox-bin = https://aur.archlinux.org/packages.php?ID=51727
[2] virtualbox-sun = https://aur.archlinux.org/packages.php?ID=31996
Det
Re: [aur-general] Removal request: google-chrome-mini
On 03/27/2012 11:53 AM, Stefan Mark wrote: On 25.03.2012 01:32, Det wrote: On 24 March 2012 13:41, Det wrote: Thanks Det, I've removed the google-chrome-mini. Lukas The maintainer doesn't seem to get the message. He re-uploaded it as "google-chrome-no-gconf", even though I already explained the user can just install "no-gconf" beforehand: https://aur.archlinux.org/packages.php?ID=57899 Det Installing no-gconf will just replace gconf with nothing (doesnt that break every normal package that needs gconf?). People might want to have gconf, but also a chrome which does not use gconf (actually, i have an emacs package that does the same thing). Yeah it does: └┌(%:~/Desktop/nvidia-beta-all)┌- ldd /opt/google/chrome/chrome | grep gconf libgconf-2.so.4 => /usr/lib/libgconf-2.so.4 (0x7fcbbbd45000) But true, some applications do break when they can't use gconf: └┌(%:~/Desktop/nvidia-beta-all)┌- gucharmap gucharmap: symbol lookup error: gucharmap: undefined symbol: gconf_client_get_default Det
Re: [aur-general] Removal request: virtualbox-sun
On 27.3.2012 0:39, Seblu wrote: On Mon, Mar 26, 2012 at 5:21 PM, Det wrote: While it's true that -sun is the original one it's also the one with the incorrect naming If i remember correctly first was virtualbox_bin[1] (which was renammed into virtualbox-bin last year). Even better. Even if -sun was to stay here the "better" stuff in -bin would have to be implemented there first before the removal and the renaming. I don't understand your sentence. Is there something missing in -bin that you need? No, I mean that if -bin was removed, then the missing "-bin stuff" should be implemented in -sun, before -bin was removed and -sun renamed to -bin. But this was when I still thought that -sun was the original one. Since it's not, there's no reason anymore for keeping it. I remind everyone is encouraged to use the version in the official repositories[2]. [1] https://aur.archlinux.org/packages.php?O=0&K=virtualbox_bin [2] https://www.archlinux.org/packages/community/x86_64/virtualbox/ Actually, yeah. I forgot the "PUEL" stuff is nowadays available through the extension pack. But this should, of course, still be taken care of. Det
Re: [aur-general] Removal request: google-chrome-mini
On 26.3.2012 21:47, Tai-Lin Chu wrote: @Alexander Rødseth that's "how it should work", but unfortunately none of these work well in reality. my reason of cloning is that "the time when these packages will update or fit your need is known". god knows when these packages will update; it could be weeks or months(or never). i either have to keep my own version of pkgbuild or change the pkgbuild every time i install. that's not efficient. google-chrome* packages are updated in an extraordinarily fast manner. Often within the first hour of the new release. If a package isn't being updated at all you should at first contact the maintainer. If you get no response, you should make an orphan request and start maintaining it yourself. 2. i want to have "no-gconf" explicitly. many users are not aware that they have to install no-gconf first, then install chrome. Uh. They don't. See, I can be wrong too. 3. as i said, aur is meant to a mess if you want it to be actually useful. if your logic applies, then we should remove all "mplayer-*", "vlc-*" ..., because we already have mplayer, vlc in [extra]. these "families" of packages are just adding or removing some flags and dependencies(some are even incorrect). having "mutations" gives convenience for users. users dont care about mess really; they care about time as they dont want to manually edit pkgbuild. Nooo, if _my_ logic applies (and it does, by the way), then we should just remove packages that don't have any meaningful changes in them. vlc-* and mplayer-* packages are _source_ packages. When they change the dependencies they actually change the features of the package coming out. It's a different story when this can be done any time you like anyway (eg. by installing no-gconf). And no, AUR isn't meant to be messy. Not a way in _hell_ would that make it more useful anyway. Finding what you like is gonna be _extremely_ hard if there's a zillion packages providing the same thing - all with their own silly little modifications. And how an earth would that help with keeping packages up-to-date? Is your solution for the maintenance system that we need to have 10 clones of every single package so that there's always gonna be an up-to-date one to choose from? Because filling up the AUR with "updated" packages just creates more problems than it resolves. If there's a redundant package in the AUR, then say it so it can be removed. Don't just join the fight against the system we already know isn't perfect. Det
Re: [aur-general] Removal request: google-chrome-mini
On 26.3.2012 20:27, Tai-Lin Chu wrote: @ngoonee my point is that if a user can edit depends=, he could also as well edit build flags. From what I remember your dependency section was wrong anyway, so the user's not even supposed to edit that. In addition 'no-gconf' provides 'gconf' so I don't understand why would anybody need a separate package to install it. @Det i dont think this is a good idea to ban users like this. someone mentioned that creating too many similar packages will create confusion. I dont think this applies to me. i already renamed the package to "google-chrome-no-gconf"; this is really clear and distinguishable from 3 other google-chrome packages. Yes. It's distinguishable. The problem is that there's nothing to actually distinguish from. Your package doesn't even install the man page or the .desktop file. Just remove those, if they bother you so much. @everyone for people who read my last post, i just searched mplayer: mplayer-fribidi-pulse and mplayer-fribidi. you might think "why does these guys create new pkgbuild while mplayer in extra has all these features?" the reason is that "he feels he needs to", and i think this is enough. Those should be removed then. [extra]'s mplayer didn't use to support fribidi back when the two were uploaded: http://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/mplayer&id=d73ff6beb888f8b2f45e19cd2a0deb9b0b8ca60e btw, there are many pkgbuild that are "out-of-date for a long time", "does not compile", "orphaned for years", or "has dead upstream". I think you should put effort on these packages. picking on the packages that are similar should be the last thing to work on. Right. Would you imagine the mess your logic would create? Every single package in the AUR could be cloned with not only -no-gconf alternatives but just about any kind as long as there was just the tiniest difference from the original one (eg. the description included a dot (.)). Also it's much harder to actually start building an uncompilable package and fix whatever is wrong with it than to just remove a redundant one. If there's a maintainer out there willing to do the work for us, then so be it. But we can't _know_ that, and _that's_ why so many packages exist in the AUR that don't even compile. Because nobody cares enough to make them. Det
Re: [aur-general] Removal request: virtualbox-sun
On 26.3.2012 19:06, rafael ff1 wrote: 2012/3/26 Det: I guess this is a good summary of all the talk in virtualbox-sun's comment section[1]. The reality here is that virtualbox-bin[2] has evolved into something _at least_ as good as virtualbox-sun. While it's true that -sun is the original one it's also the one with the incorrect naming, a bit slower updates (by a day or so) and less votes (229 vs -bin's 3430). Because we can't justify keeping duplicated work around just to make everybody happy, one of them has to go. Even if -sun was to stay here the "better" stuff in -bin would have to be implemented there first before the removal and the renaming. When put together with the comment/vote merge it's starting to sound a bit pointless (taken how we can just remove that one). I know what I'd do but it's not my decision: it's yours. [1] virtualbox-sun = https://aur.archlinux.org/packages.php?ID=31996 [2] virtualbox-bin = https://aur.archlinux.org/packages.php?ID=51727 Det It is interesting how both provide the same version of the same softwaer, but have totally different depedency listed. For example, "kernel26-headers" for virtualbox-sun. Yeah. -sun is a bit outdated there too.
[aur-general] Removal request: virtualbox-sun
I guess this is a good summary of all the talk in virtualbox-sun's comment section[1]. The reality here is that virtualbox-bin[2] has evolved into something _at least_ as good as virtualbox-sun. While it's true that -sun is the original one it's also the one with the incorrect naming, a bit slower updates (by a day or so) and less votes (229 vs -bin's 3430). Because we can't justify keeping duplicated work around just to make everybody happy, one of them has to go. Even if -sun was to stay here the "better" stuff in -bin would have to be implemented there first before the removal and the renaming. When put together with the comment/vote merge it's starting to sound a bit pointless (taken how we can just remove that one). I know what I'd do but it's not my decision: it's yours. [1] virtualbox-sun = https://aur.archlinux.org/packages.php?ID=31996 [2] virtualbox-bin = https://aur.archlinux.org/packages.php?ID=51727 Det
Re: [aur-general] Removal request: google-chrome-mini
Just came here to say I had a good laugh from all this. But the thing is that if we banned this guy all his other 12 packages[1] would need new maintainers (they don't seem to be anything special, though. His most voted package with 17 votes (no-gconf[2]) doesn't even require maintenance). [1] = https://aur.archlinux.org/packages.php?K=taylorchu&SeB=m [2] = https://aur.archlinux.org/packages.php?ID=36554 Det
Re: [aur-general] Removal request: google-chrome-mini
On 24 March 2012 13:41, Det wrote: > Thanks Det, I've removed the google-chrome-mini. > > Lukas The maintainer doesn't seem to get the message. He re-uploaded it as "google-chrome-no-gconf", even though I already explained the user can just install "no-gconf" beforehand: https://aur.archlinux.org/packages.php?ID=57899 Det
Re: [aur-general] Removal request: google-chrome-mini
On 18 March 2012 09:23, Lukáš Jirkovský wrote: > On 18 March 2012 09:22, Lukáš Jirkovský wrote: > > > > I'll remove google-chrome-mini when the google-chrome-dev get's > > updated with the changes you mentioned. > > > > Lukas > > BTW: it would be nice if someone pings me when it gets updated, I > notoriously forget things. It's done now. Here's the link to google-chrome-mini again: https://aur.archlinux.org/packages.php?ID=57611 Det
Re: [aur-general] Removal request: google-chrome-mini
On Mar 16, 2012 14:55, "Alexander Rødseth" wrote: > Hi, > > The current maintainer, taylorchu, replied: > > 1. it uses no gconf, so you dont need gtk3. > > 2. it does not try to move and symlink. it is vanilla as provided by google. > > Do you still request the package to be deleted? Well, the symlinks can be removed as they are unnecessary nowadays (the man page and the .desktop _should_ still be installed), while 'no-gconf' could just as well be manually installed from the AUR beforehand, as it replaces 'gconf'. Building 'openssl098' is the only thing that might bother some people. It could be moved to optional dependencies, since not everybody uses the built-in Pepper Flash anyway (which requires it). At the _very least_, if this package was to be kept in the AUR (which I disagree with) the name should be changed to something like 'google-chrome-dev-no-gconf'. But using the same logic every single package in the AUR depending on 'gconf' could be cloned with '-no-gconf' alternatives. Is _this_ what we want? Det
[aur-general] Removal request: google-chrome-mini
This is not even funny: https://aur.archlinux.org/packages.php?ID=57611
- A clone of 'google-chrome-dev'
- Otherwise the same but the build and dependencies somehow more 'minimal'
- In practice completely useless
Det
[aur-general] 2 orphan requests: "xf86-input-evdev-git" and "git-git"
Hey, The following packages should be orphaned: xf86-input-evdev-git: https://aur.archlinux.org/packages.php?ID=41665 - out-of-date - contains several mistakes - doesn't build - maintainer unresponsive to mail and comments - last updated 29 May 2011 git-git: https://aur.archlinux.org/packages.php?ID=17896 - out-of-date - contains several mistakes - maintainer (sirmacik ) claimed almost a month ago having stopped using Arch (all his other packages should probably be orphaned too. Not going to maintain _them_, though) - last updated 13 Jan 2010
[aur-general] Removal request: bin32-google-earth
Hey, Google now offers 64-bit binaries for Google Earth so the outdated/deprecated 'bin32-google-earth' can finally be removed: https://aur.archlinux.org/packages.php?ID=12890 Det
[aur-general] Orphan request: google-earth & delete request: google-earth-deb
Hey, So the story is that, since '458italia' (the maintainer of 'google-earth' [1]) has been unresponsive for over a month another maintainer called 'kiodo1981' decided to almost 3 weeks ago to create an updated Google Earth package of his own, 'google-earth-deb' [2]. The problem is that this is not the right way to do things and the PKGBUILD has some serious errors. I talked with kiodo1981 and my current stance is that I'd like to take over 'google-earth' (to begin with). And after I've combined the two PKGBUILDs (meaning: replaced the source URL with the other package's url) and maintained it for a while, I'd be willing to let kiodo1981 take over. I just want to make sure that he's ready for it (and that I get the most voted packages in the AUR). So, again, this is what I'm requesting: Orphan: google-earth - [1]=https://aur.archlinux.org/packages.php?ID=15270 Remove: google-earth-deb - [2]=https://aur.archlinux.org/packages.php?ID=53869 Have a nice dayy! Det
Re: [aur-general] Please rename "virtualbox_bin_beta" to "virtualbox-beta-bin"
On 10/28/2011 07:16 PM, Florian Pritz wrote: On 28.10.2011 17:53, Det wrote: Please rename "virtualbox_bin_beta" to "virtualbox-beta-bin": https://aur.archlinux.org/packages.php?ID=27339 Tell the maintainer to upload the new one and then request merging. Ok, can you do it now?: https://aur.archlinux.org/packages.php?ID=53494
[aur-general] Please rename "virtualbox_bin_beta" to "virtualbox-beta-bin"
Please rename "virtualbox_bin_beta" to "virtualbox-beta-bin": https://aur.archlinux.org/packages.php?ID=27339
Re: [aur-general] Flash 10.1 and kernel26 packages
On 12.8.2011 19:12, Det wrote: Hi all you electronic mail readers, There was some talk some time ago I think concerning the removal of the Flash10.1 packages. I thought I'd bring it back up. Here are the links: flashplugin-10.1: http://aur.archlinux.org/packages.php?ID=47029 lib32-flashplugin10.1: http://aur.archlinux.org/packages.php?ID=49982 Then another thing is those kernel26- packages (all 59 of 'em). Is there some deadline until all the ones that hasn't been updated or converted into linux- alternatives should be removed?: http://aur.archlinux.org/packages.php?K=kernel26&SeB=n&PP=100 Thanks, byyye Det End of electronic guru mail. This is a tricky one I know. What about just the Flash10.1 packages?
[aur-general] Flash 10.1 and kernel26 packages
Hi all you electronic mail readers, There was some talk some time ago I think concerning the removal of the Flash10.1 packages. I thought I'd bring it back up. Here are the links: flashplugin-10.1: http://aur.archlinux.org/packages.php?ID=47029 lib32-flashplugin10.1: http://aur.archlinux.org/packages.php?ID=49982 Then another thing is those kernel26- packages (all 59 of 'em). Is there some deadline until all the ones that hasn't been updated or converted into linux- alternatives should be removed?: http://aur.archlinux.org/packages.php?K=kernel26&SeB=n&PP=100 Thanks, byyye Det End of electronic guru mail.
Re: [aur-general] Removal Request
On 08/01/2011 01:50 PM, Luca Bennati wrote: Where? I couldn't find it in kde-looks 2011/8/1 Lukáš Jirkovský Apparently the page isn't but the sources are. Doesn't work: http://kde-look.org/content/show.php/Nitrogen-style?content=112652 Works: http://kde-look.org/CONTENT/content-files/112652-kde4-kstyle-nitrogen-1.0.5-Source.tar.gz I suppose it has been deleted and the sources will remain there for some time.
Re: [aur-general] Deletion Request
On 22.7.2011 12:10, Allan McRae wrote: On 22/07/11 17:33, Evangelos Foutras wrote: On 22 July 2011 10:18, Kwpolska wrote: Please, don't act like AN ASSHOLE. This is really annoying. Just say `removed'. I didn't know that posting a tongue-in-cheek reply every once in a while translates to acting like an asshole. *shrugs* In my opinion, your bashing was totally uncalled for. But thanks anyway for ruining my otherwise lovely morning. You deserved it. (I made a funny! No you didn't! :p) Stop it. You are killing me.
Re: [aur-general] The songbird mess
On 7/20/11, Xyne wrote: > That really was a mess. > > Removed: > * songbird (it was an SVN package) > * songbird-auto-beta (redundant, plus the PKGBUILD contained insults > directed > at the songbird devs) > * songbird-auto-nightly (package included unused archives, a poorly written > PKGBUID with several mistakes, and the same insults as songbird-auto-beta) > * songbird-nightly (should be songbird-nightly-bin) > > I've cursorily cleaned up the songbird-auto-nightly package (removed > insults, > added missing quotation marks, replaced old "$startdir" variables) and > re-uploaded it as songbird-nightly-bin, which I have left orphaned. The > PKGBUILD is still kludgy imo, but someone else can adopt it and improve it. > > I've left bin32-songbird-nightly alone. > > Regards, > Xyne Wow, thanks. Didn't expect you'd be doing that good a job. Yeah, and thanks for clearing out the osd-lyrics too.
[aur-general] The songbird mess
Hey, This one (I hope) even has the links correctly defined. songbird: http://aur.archlinux.org/packages.php?ID=7286 * A binary package, wrong naming (there's songbird-bin in the AUR too) songbird-nightly-bin: http://aur.archlinux.org/packages.php?ID=32932 * Maintained, but severly out-of-date * Wrong naming * Replaced by songbird-auto-nightly songbird-auto-nightly: http://aur.archlinux.org/packages.php?ID=39911 * Wrong naming * The contents of this one should replace that of songbird-nightly - this should be removed afterwards songbird-nightly: http://aur.archlinux.org/packages.php?ID=13193 * Actually has the correct naming * Out-of-date * The contents of songbird-auto-nightly should replace this package's So to some up what I think is best: Replace: * songbird-auto-nightly -> songbird-nightly Remove: * songbird * songbird-nightly-bin * songbird-auto-nightly Thanks for your time, Det
[aur-general] The osd-lyrics mess
Hey, There's currently 6 osd-lyrics packages in AUR, 4 of which are redundant. <http://aur.archlinux.org/packages.php?ID=30489> osd-lyrics: <http://aur.archlinux.org/packages.php?ID=30489>http://aur.archlinux.org/packages.php?ID=30489 * Should be left and updated since it has the correct naming osdlyrics: http://aur.archlinux.org/packages.php?ID=29787 * The project's name is "osd-lyrics" - not "osdlyrics" * Maintained, but severly out-of-date osd-lyrics-stable: <http://aur.archlinux.org/packages.php?ID=50725>http://aur.archlinux.org/packages.php?ID=50725 * Wrong naming * Sadly, currently the only one up-to-date (decluding the -git package) osd-lyrics-stsable: http://aur.archlinux.org/packages.php?ID=50724 * A typoed upload that the maintainer decided to leave in the AUR osd-lyrics-svn: http://aur.archlinux.org/packages.php?ID=30488 * Upstream moved to git ( http://aur.archlinux.org/packages.php?ID=29787) Thanks for your time, Det
Re: [aur-general] The license of flashplugin(-prerelease) requires a download?
On 7/14/11, Thomas Dziedzic wrote: > On Thu, Jul 14, 2011 at 1:06 PM, Sven-Hendrik Haase wrote: > >> Can't the PDF be extracted to plain text? >> > > I like this solution if it is possible. > In that case the easiest way would probably be to just copy-paste the latest Flash Player EULA from here to a text file (as "LICENSE" or something alike) every time there is a major version bump: http://labs.adobe.com/technologies/eula/flashplayer11.html I'd guess just linking to this page is not sufficient (at least if you definitely want to avoid the cliché of poking the ice). This generally feels like a good idea and it's definitely better than downloading a stupid PDF. More ideas are still welcome, though.
Re: [aur-general] [AUR] Orphan all old packages flagged as out-of-date
On 6/8/11, Martti Kühne wrote: >>> +1 for the notification idea > -1 from me. I thought we agreed that the aur was passive by not > bugging its users about stuff. Yes! Stop sending me those damn "out-of-date" notifications!
[aur-general] Got 2 remove these
Hey, So I figured these packages should be wiped out from the face of the AUR while we still have time. google-chrome-fix: http://aur.archlinux.org/packages.php?ID=42507 - Chromium based browsers (Iron, Chrome, Chromium) have moved onto libjpeg-turbo so this libjpeg6 fix is not needed anymore kernel26-autogroup: http://aur.archlinux.org/packages.php?ID=43689 - Autogrouping has been added to the official Arch kernel (this one is old and unmaintained anyway) nvidia-autogroup: http://aur.archlinux.org/packages.php?ID=43777 - Same thing nvidia173-autogroup: http://aur.archlinux.org/packages.php?ID=43952 - Still the same Thanks for your time, Det
[aur-general] Removal request of xorg-server-compositing-fix
Hellooo, Please dematerialize xorg-server-compositing-fix [1]. The maintainer already requested for its destruction when 1.9.3 would hit the repo but apparently TUs forgot about it or something. [1] = http://aur.archlinux.org/packages.php?ID=41438 Thanks for your time, Det
Re: [aur-general] Please remove python32-opengl
On 5/13/11, merp boop wrote: > Whoops! Do your thang, guys. Thanks in advance! > > -Max And the link is: http://aur.archlinux.org/packages.php?ID=48975
Re: [aur-general] Should nvidia(-beta)-all replace all the other nvidia-* packages in the AUR?
Not to keep bugging your mailboxes but I suppose the only real reasons for keeping all those nvidia-specific-kernel packages in the AUR boils down to these: 1) The user wants to install an Nvidia driver for a non-booted kernel, yet he doesn't want to install the driver for any the other kernels since the rest (or at least 1 of them) use Nouveau or similar. 2) The maintainer wants to show a link to his unofficial repository containing a precompiled version of his package. If these are enough to keep all that nvidia* stuff in the AUR then I don't mind. It'd just be nice, if somebody came up with a PKGBUILD that would ask the user which of the installed kernels he wanted the nvidia driver to be installed to. In addition the package could hold a simple text file listing all the unofficial repositories for using the precompiled packages instead or something ^^. Det
Re: [aur-general] Google-earth and bin32-google-earth
On 3/27/11, Thorsten Töpper wrote: > A solution would be to implement the support for multiple package names > into AUR, the AUR-Team surely loves to get support by people who send > them useful patches. ;-) Don't look at me :-).
Re: [aur-general] Please remove firefox-bin
On 3/27/11, Ionuț Bîru wrote: > i do prefer to have them in aur, but the maintainer should follow > firefox-bin as stable, firebox-beta-bin as beta. > > now there isn't any beta version available and it should be updated to > stable. Firefox-beta-bin has actually already been updated to 4.0. > is fine like it is now. The only difference between 'firefox-bin' and [extra]'s 'firefox' is that 'firefox-bin' is built by the Mozilla guys. But if you think that's enough, then I'm fine with it. Det
Re: [aur-general] Should nvidia(-beta)-all replace all the other nvidia-* packages in the AUR?
On 3/26/11, Oon-Ee Ng wrote: > I can assure you that nvidia-beta-all (and nvidia-all which Det > maintains) builds the modules for all installed kernels. I do? I didn't even know that. The "Maintainer: None" phrase was a little confusing to me ^^. Anyway, I posted an updated PKGBUILD for the maintainer who adopted the package while I was doing it. Det
Re: [aur-general] Should nvidia(-beta)-all replace all the other nvidia-* packages in the AUR?
On 3/19/11, Ike Devolder wrote: > For me its all the same, you can remove the nvidia-bede package > from aur > > i'll keep it in my own source tree because the nvidia-all package > assumes the kernel version as the running version > > most of the time i build for a kernen which is not running at the time > > Ike (aka BlackEagle) I would really like people to hand out more oppinions about this. This is implicating a lot of packages. Det
[aur-general] Google-earth and bin32-google-earth
Hey, There's been some discussion between me and the maintainer/submitter of 'bin32-google-earth' (srabd) as to whether 'google-earth' should finally replace 'bin32-google-earth'. He disagrees. In his oppinion the "bin32-" prefix should always be used when the package being offered is a "32-bit only" one. I in turn think that the package should be removed in the favor of 'google-earth' that you can install for both archs and where you could say eg. in the 'pkgdesc' that the package provides 32-bit binaries (for both archs). It is not as much of a problem for me to have 'bin32-google-earth' existing in the AUR as long as the other one didn't. It's redundant to provide otherwise the same application but the other package provides it for i686 only. So what should be done? I'm not a TU and neither is srabd - but you are. Let the discussion begin (please, let it). Thanks for your time, Det
[aur-general] Should nvidia(-beta)-all replace all the other nvidia-* packages in the AUR?
Hell, So I've been thinking about this for some time now and I finally decided to ask the ones who know the best: would it be enough to only have 'nvidia-beta-all' and 'nvidia-all' in the AUR to replace all those nvidia-ice, nvidia-bfs, eg. packages? (Decluding nvidia-utils*, of course.) As far as I can think of, I can't see any downside(s) (whatsoever) of using those *-all packages instead of those 'specifc-kernel' packages, since they do in fact auto-detect all the kernels on the system. Now to the important part: what do you think? Det
Re: [aur-general] How should *-devel packages generally be handled?
On 3/16/11, Ng Oon-Ee wrote: > Package foo exists in [extra], and foo-devel in the AUR. > > foo-devel is obviously based off unstable tarball releases (otherwise it > would be foo-git, foo-svn, foo-hg or similar). > > So let's say foo is at version 4.0 (stable), should foo-devel stay at > 3.9 (the last beta/rc/unstable release) or update to 4.0? > > Just a general question. My gnucash-devel package is currently pretty > much identical to the one in [extra], and it does seem a bit unnecessary > because the project itself does not currently have unstable releases. At least when I'm using -dev(el) packages I do so to get the most bleeding edge releases of that specific software (decluding svn/hg/git versions - unless recommended by upstream). I don't even understand how could anybody cope with just having unstable releases :). I myself quickly get annoyed by the crashes/lagginess/whatever. But as Jan said, it's a preference question decided by the maintainer (you). Det
Re: [aur-general] AUR 1.8.1 - Can No Longer Upload Packages
On 3/14/11, Tony C wrote: > Here is the build. I really do not see any reason why the build is being > rejected, I would have to agree that this is a bogus error. > > -- > Tony I tried test uploading this by changing the pkgname, replacing with one of my packages that nobody uses anyway - and it worked. So what comes to mind is that either the pkgname of yours is too short for AUR 1.8.x (3 letters) or there's something wrong with the tarball itself. Could you upload the tarball somewhere for others to review? Det
Re: [aur-general] development version for gnome dependencies in aur
On 3/12/11, Ionuț Bîru wrote: > It was just a simple announcement that i would start deleting -dev stuff > and inform the users to start switching to gnome-unstable repo instead. > > I believe there is a miss-communication between me and you. Every time i > send you my feedback regarding your packaging/actions, you get all > personal, like i have something against you. > > Stop doing it. I just want what is best for our users and for arch in > general. > > -- > Ionuț Ah, never mind that. It's just my way of speaking (which, btw people have misunderstood before too) and not some I-hate-you-and-the-rest-of-the-world grumbling (in fact, I even tried to not sound like that - but it's hard to change once you get used in something). I completely understand how you want what's best for Arch in general and so do I. And in this subject you know better than me anyway, so I really don't want to step in the way of your decisions. Det
Re: [aur-general] development version for gnome dependencies in aur
On 03/12/2011 11:18 PM, Ionuț Bîru wrote: > > On 03/12/2011 11:15 PM, Ionuț Bîru wrote: >> >> Hi, >> >> i've seen a lot of _new_ builds submitted in aur mostly related to >> gnome-shell 2.91. This is duplicating my work and makes in the same time >> is hard for users to test the future gnome 3 version and updating to >> gnome-unstable/testing/extra at some point. >> >> I would start deleting _all_ builds related to gnome3/gnome-shell >> tomorrow. STOP uploading it. >> > > also, Det, if you really want to help improving gnome packaging, you should > start using gnome-unstable repo. It's better for you, it's better for me and > for gnome 3.0 in general. Using all modules rather than gnome-shell is a > better experience. > Sure, but I'm not actually using the packages myself. I find Gnome too bloated. Also I don't quite understand why did you first send a personal message to me and then additionally to the mailing list.
Re: [aur-general] Alternative Links
On 3/10/11, Lukas Fleischer wrote: > The other links work fine for me. Please do not open a new thread for > things like that. Yeah, I screwed up there. Gmail timed out or something and when I logged back in and sent the mail it was not sent as a reply anymore.
[aur-general] Alternative Links
On 3/10/11, Det wrote: > References: when logged in [1] and when not [2]. > > [1] http://www.image-upload.net/images/0ixc5luiei3xkrvp3gft.jpg > [2] http://www.image-upload.net/images/41665a4m8wfr066itbyi.jpg Image-upload.net doesn't seem to be a good host (started getting redirect loops). I re-uploaded the two in ImageShack in case somebody else is having problems too: Logged In: http://img812.imageshack.us/img812/9056/logged.jpg Not-Logged In: http://img809.imageshack.us/img809/2908/anonymousl.jpg
Re: [aur-general] Upgraded AUR to 1.8.1
On 3/10/11, Lukas Fleischer wrote: > The official Arch Linux AUR setup has been upgraded to 1.8.1. For a > short list of changes, read [1]. > > Please report any issues on the AUR bug tracker [2]. > > [1] http://mailman.archlinux.org/pipermail/aur-dev/2011-March/001456.html > [2] https://bugs.archlinux.org/index.php?project=2 By the way, why is there (since 1.8.0) two/three empty rows in between the 'pkgdesc' and the 'Category' sections when viewing your own packages when logged in? References: when logged in [1] and when not [2]. [1] http://www.image-upload.net/images/0ixc5luiei3xkrvp3gft.jpg [2] http://www.image-upload.net/images/41665a4m8wfr066itbyi.jpg
Re: [aur-general] TU application (Kyle Keen)
On 3/3/11, keenerd wrote: > I want to be a TU now for the same reasons I wanted to be a TU then. > Arch sucks and it could really use any help it can get ;-) I don't think the phrasing here is really for your benefit. Det
Re: [aur-general] Please help create package lib32-gobject-introspection
On 2/8/11, rafael ff1 wrote:
> Hi all,
And hello to you too
> I'm trying to build gobject-introspection for lib32 version for my Arch64,
> but it is failing in the "configure" command saying that Python headers were
> not found. This 32 bit library package seems to be dependecy (not sure,
> though) for some lib32 packages (afaik "at-spi", "gconf", "polkit",
> "gstreamer0.10").
The 32-bit gobject-introspection would be a _make_ dependency
("makedepends=()"). That's why you won't see it in the regular
"depends=()" sections.
> ( Sorry for the size of the email. I thought it would be good to add some
> log messages and didn't know if attachment is allowed. PLEASE remove some
> lines when reply!)
Yeah, that's why we got pastebin: http://aur.pastebin.com/ - please
use that one in the future :).
> checking for headers required to compile python extensions... not found
> configure: error: Python headers not found
> Aborting...
> [...]
> | #include
> configure:13361: result: not found
> configure:13363: error: Python headers not found
> (...)
You need 32-bit versions of gobject-introspection's dependencies too (lib32-):
depends=('libffi>=3.0.9' 'glib2>=2.27.93' 'python2')
makedepends=('cairo')
..and it seems "lib32-python2" doesn't even exist.
[aur-general] libxkbcommon-git & libxkbcommon(-git) - wooot?
Hellh, Please wipe out either libxkbcommon [1] or libxkbcommon-git [2] from the face of the AUR. These things are essentially the same package (since they both use git), which makes the other one redundant. 'libxkbcommon' was there first but it has the wrong naming scheme and not that many votes for it to really matter if it somehow was suddenly dematerialized(!). [1] http://aur.archlinux.org/packages.php?ID=40796 [2] http://aur.archlinux.org/packages.php?ID=42556 Thaaanks, Det
Re: [aur-general] aur.archlinux.org down?
Not that anybody's gonna download it in the meantime ^^. On 12/22/10, Det wrote: > Yeah. Can't update my package until they get it back up and running again. > > On 12/22/10, Seblu wrote: >> $ ping aur.archlinux.org >> PING aur.archlinux.org (208.92.232.29) 56(84) bytes of data. >> From 67.69.228.37 icmp_seq=1 Time to live exceeded >> From 67.69.228.37 icmp_seq=2 Time to live exceeded >> ^C >> --- aur.archlinux.org ping statistics --- >> 2 packets transmitted, 0 received, +2 errors, 100% packet loss, time >> 1001ms >> >> $ wget aur.archlinux.org >> --2010-12-22 22:02:14-- http://aur.archlinux.org/ >> Resolving aur.archlinux.org... 208.92.232.29 >> Connecting to aur.archlinux.org|208.92.232.29|:80... failed: No route to >> host. >> >> Regards, >> -- >> Sébastien Luttringer >> www.seblu.net >
Re: [aur-general] aur.archlinux.org down?
Yeah. Can't update my package until they get it back up and running again. On 12/22/10, Seblu wrote: > $ ping aur.archlinux.org > PING aur.archlinux.org (208.92.232.29) 56(84) bytes of data. > From 67.69.228.37 icmp_seq=1 Time to live exceeded > From 67.69.228.37 icmp_seq=2 Time to live exceeded > ^C > --- aur.archlinux.org ping statistics --- > 2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1001ms > > $ wget aur.archlinux.org > --2010-12-22 22:02:14-- http://aur.archlinux.org/ > Resolving aur.archlinux.org... 208.92.232.29 > Connecting to aur.archlinux.org|208.92.232.29|:80... failed: No route to > host. > > Regards, > -- > Sébastien Luttringer > www.seblu.net
Re: [aur-general] wine-wow-hardware-cursor and bin32-wine-wow-hardware-cursor removal request
On 10/16/10, Przemek Aksamit wrote: > wine-wow-hardware-cursor and bin32-wine-wow-hardware-cursor are not > needed any more and should be removed. > World of Warcraft got opengl hardware cursor in last path (4.0.1). > > extcake Well this is amusing. It seems you were 2 minutes and 1 sec faster than I was. Should've checked if somebody had already sent a request of the WoW Wine stuff: http://mailman.archlinux.org/pipermail/aur-general/2010-October/011354.html Thanks for your time, Det
[aur-general] Wine removal requests
Heyeyeh, So here's some unnecessary/obsolete wine packages that should be wiped out from the face of AUR Ò_Ó: bin32-wine-wow-hardware-cursor: http://aur.archlinux.org/packages.php?ID=33975 wine-stable-wc: http://aur.archlinux.org/packages.php?ID=33231 wine-wc: http://aur.archlinux.org/packages.php?ID=27298 wine-wow-hardware-cursor: http://aur.archlinux.org/packages.php?ID=33974 (users claiming that WoW patch v4.0.1 allows the usage of [community]/[multilib]'s vanilla wine without issues - so all those WoW Wine packages have become obsolete) wine-key: http://aur.archlinux.org/packages.php?ID=30473 (maintainer claims that "the key repeat bug has been fixed a lng time ago") Thanks for your time, Det
Re: [aur-general] chromium-beta and related mess
On 9/25/10, member kittykatt wrote: >Seriously. Can we just get this issue resolved and stop being at one >another's throats? It seems like all you do is reply to instigate something. I agree with you but this build issue doesn't exist with the correct upstream version (to which chromium-beta has already been updated to). (Also please reply _under_ the quoted text. That's just some standard people here do.) Thanks for your time, Det
Re: [aur-general] chromium-beta and related mess
On 9/24/10, JerichoKru wrote:
> Google's way of versioning things is weird...both the stable and beta
> are the same version? I'm so confused.
>
> Oh well, I'll update it with what link says.
There should be nothing to get/be confused about. Virtually with all
software a stable version will sometimes go ahead the beta one, which
in turn brings mixed opinions with certain packages in AUR between the
maintainer and others whether the package should be updated or not.
It's happened a few times when the maintainer has claimed that his
package should only follow beta releases - which is not correct unless
specifically mentioned in the pkgdesc or the pkgname. Well anyways,
the dev(/canary) channel(s) will always be newer than beta/stable
channels.
Also, no need to cover you being wrong by saying you are confused or anything.
Thanks for your time,
Det
Re: [aur-general] Orphaning request - chromium-beta and clamav-devel
Great, So back to the basics: 1) My intentions were _never_ to send an orphan request of a package that hasn't been updated in 2 to 3 hours. The person who came up with that is at least as silly as I was. 2) Funny. I'm not going to send an orhpan request to an official package after I see it's out of date. Perhaps I would also call the president of USA every time a flu has been spotted in my country in case it possibly spread to USA and killed every people there? 3) Yes, for chrissake, I _do_ realize that when I disowned the package I "gave up my rights" or in whatever way you wanna phrase it. No need to say that on every other mail. And I should've never sent the first mail in the first place. 4) As it turns out, JerichoKru was not the kinda maintainer I thought he might be so this whole talk about the correct orhpan/maintenance philosophy no longer necessary. I really don't think there's anything here that hasn't or needs to be mentioned. I don't even use the package so I don't really care about its future anymore. It's up to JerichoKru and its future maintainers Thanks for your time, Det
Re: [aur-general] chromium-beta and related mess
On 9/24/10, Jericho Draken wrote: > As the email suggests, I am JerichoKru Hi! > 1.) I had figured that 6.0.496.0 would be the beta because it is the > latest of the v6's and the v7's are the in dev tree. Det listed what is > now the latest stable as the beta...which is obviously not right. "Obviously wrong" :). Have a look: http://googlechromereleases.blogspot.com/ > 2.) This version apparently doesn't need/incompatible with the gyp > patch listed. It stated that the patch was filled with "garbage". > > 3.) Skipping the patch causes a build error farther down in the compile > process. Unfortunately, I forgot to save the output. I'll try again > tomorrow as it is 11PM in my timezone. > > Any input for this would be helpful. Use the correct version, 6.0.472.63 and it builds fine. > On a somewhat related note: I had typed a rather long response to > Det's...rant but, I tried to sent it with my other email and thus > didn't get posted. When thinking about it, that reply would have just > fed to the fire. Oh no, I love people disagreeing with me and comparing me to whatever funny stuff their mind comes up with. Thanks for your time, Det
Re: [aur-general] Orphaning request - chromium-beta and clamav-devel
On 9/23/10, Heiko Baums wrote: > I didn't say that you're asking everybody adopting it And I didn't say you did. > but you ask to orphaning it if someone else already has adopted it >because it was orphaned. No, I only asked a maintainer who wasn't so fast with updating the package as I was. > And "bumping" the package is the maintainer's job. So if you orphan it > you tell the people: "Please take it if you want." If someone else > takes it he usually wants to maintain it and does it. And if he doesn't > update it fast enough in your opinion then you should have kept the > package and should have maintained it by yourself. That's the point. And it's a good point except for the part where this is the first time this thing happened. Of course, I'm not going to maintain the package as an actual _maintainer_ - so that doesn't really matter. > And the maintainer sometimes could have to do something else than just > updating the package every second day, just because you are too > impatient. Sure, but not with all maintainers. Some do have the time but still won't update their packages. I hope this is not one of those cases. > Otherwise I would suggest you to download the package to /var/abs/local > and maintain it by yourself locally on your system. Then you can update > it as often as possible. Actually I don't even use the package. I just like to update it to others. > And why did you orphan this package if you want to maintain it by > yourself after all? I do and I don't :). > Regularly updating a package is that which is called maintaining a > package. You have orphaned the package, so you don't want to maintain > it, so you don't want to regularly update the package, so live with it. > You had the chance to maintain it, because you didn't need to orphan > the package. It was your choice. Actually, in AUR I did a 4 months stretch of doing exactly this with my packages. Why? So that anybody could update my package when I would was unable to. It never meant I would not want to maintain my packages. That wasn't exactly what I was doing with this package but still, when _I_ just bump a package it does _not_ necessarily mean I don't want to regularly update it since I disowned as soon as I did it. Good thing, if the users don't care about having the latest versions all the time. They are the ones who need to "live with" it. > It means both. It says clearly to either using Pastebin or to send it > to the maintainer by e-mail. Which doesn't mean only e-mail and Pastebin can be used. They don't need to list and think of every possible option to upload the PKGBUILD. It's enough when people get the main idea. > I wouldn't download and review such a package if someone would > send me such a link in my comments. Are _you_ the maintainer of this package :)? > And you shouldn't always upload a new, updated package somewhere and > put the link to it to the AUR comments. You can assume that the > maintainer knows how to update his package. Sure. I just like making things easy. > You really should decide whether you want to maintain a package or not. Not in the sense you are thinking of. Something we both agree on :). > And you should only send an orphan request if you really want to > maintain a package and keep maintaining it. That's a little ambiguous but generally speaking you are right. So to wrap this all up, I would just like to have an active maintainer for that package but it's not something I really "need" since I don't even use the package. Thanks for your time, Det
Re: [aur-general] Orphaning request - chromium-beta and clamav-devel
On 9/23/10, Heiko Baums wrote: > You always should contact the maintainer before you send an orphan > request to the mailing list. I know that. I just didn't remember it so can you let it go already? Are you obsessed about being right or something :)? > Regularly "bumping" if there's an update means maintaining a package. > Either you want to maintain a package or not. But you shouldn't > regularly send orphan request, update a package once, orphan it by > yourself, and send an orphan request again if someone else has adopted > a package. > > Either you adopt a package and maintain it or you should leave it alone. You are missing the point here. What I was _not_ doing was bumping chromium-beta and asking everybody adopting it in the meantime to give the package back to me. What I _was_ doing was to bump it as soon as there is an update but keep the package orphaned until an active maintainer would choose to adopt the package so that my job would obviously not be needed - unlike in this case where the maintainer hasn't updated the package for 8 days (a long time for _me_ - no, I'm not saying it's a long time to your or anybody else) and I have reasons to believe that he will not be that fast in updating the package in the future either. This is now the third time I'm saying the same thing. > Btw., chrome-beta was first commited on 20 Aug 2010, only one month > ago. So the maintainer probably hasn't been inactive and the package > was not that outdated. Flagging the package as out-of-date and > contacting the maintainer could have been sufficient. I'm not sure what you mean here. If you meant that JerichoKru was the original maintainer of chromium-beta then it's wrong. Simply checking the PKGBUILD or putting a thought on checking the comments section shows that "Markus Golser" (or "elmargol") was the original maintainer. > And why is JerichoKru the maintainer and not you? And if you really had > adopted the package, updated it and orphaned it at once, why are you > now asking for orphaning this package again? Uh, so that it could be updated? So that it would keep on being updated? > It has a maintainer - I don't know if he's the original one - and it is > not that outdated if at all. And if you regularly want to update an > orphaned package then adopt it and keep it and don't always orphan it. Same thing here. > You put several times a link to a tarball at Rapidshare. You can't put > a Rapidshare link into the source array of a PKGBUILD. Ehm... :). > In case this tarball was your updated PKGBUILD, you know Pastebin? And > you've read what's written on the package site? > On every package site you find this note written in a big font size: > "Please use a pastebin or email to post PKGBUILDs, patches, or scripts." Heiko, perhaps you need to start putting a thought when reading other people's writings. This text here does _not_ mean "put every single PKGBUILD, patch and/or script in Pastebin" but rather "please do not bloat the comments section by pasting PKGBUILDs, patches and/or scripts in the _comments section_". If you actually think that anything else than Pastebin shouldn't be used based on that comment then perhaps you could please leave this conversation here, as it is. I've already told you why I want the package to be orphaned and if you just refuse to believe it should be done, then OK: that's your opinion and you've already made it clear. Thanks for your time, Det
Re: [aur-general] Orphaning request - chromium-beta and clamav-devel
On 9/23/10, Heiko Baums wrote:
>Did you send a private e-mail to the maintainer?
Not before now.
>And you should only ask for orphaning if you really want to adopt and
>maintain this package as you told the current maintainer to do so in
>the AUR comments.
Well, I wasn't thinking of adopting anything but bumping at least
chrome-beta when there's an update available until an active
maintainer would take my place.
> Btw., last update of chromium-beta was 15 Sep 2010, one week ago.
> So the maintainer seems to be active.
No, it was me who did that.
> And what do you want with a Rapidshare download in a PKGBUILD?
In a PKGBUILD? If you meant that why did I upload a single PKGBUILD to
Rapidshare, you should know that I uploaded the whole tarball
(including the .install file, desktop file, etc.)
Thanks for your time,
Det
Re: [aur-general] AUR - 'kernel26' search results
On 9/22/10, Jakob Gruber wrote: > On 09/22/2010 09:31 PM, PyroPeter wrote: >> Hey, I am the maintainer (and developer) of otrtool-git. >> What's wrong about it? >> >> Regards, PyroPeter > > I guess Det searched aur.archlinux.org for the word 'obsolete' :) Yeah, correct (Google). Figured the TU to remove(/orphan) these packages would be more pedantic than I could've been. Luckily in these kinda cases things can be reverted so no harm done in my or anybody else's part anyway. Thanks for your time, Det
[aur-general] Orphaning request - chromium-beta and clamav-devel
Hi,
Please orphan:
clamav-devel - http://aur.archlinux.org/packages.php?ID=16460 and
chromium-beta - http://aur.archlinux.org/packages.php?ID=40059
..the maintainer hasn't updated the first one for over a year and the
seccond one never - I used to update it as soon a new version came up
but kept it orphaned in case an _active_ maintainer would like to
adopt it.
Thanks for your time,
Det
Re: [aur-general] AUR - 'kernel26' search results
Greetings, fellow all of you, Great talk about this subject but could a TU check the package list I handed out? All those packages still exist in AUR. Thanks for your time, Det
Re: [aur-general] AUR - 'kernel26' search results
And maybe the kinda 'last modification'/'history' logic the official packages' svn repo trunk thingy uses? The one where you can see the lines that were changed with the package, e.g. kernel26: http://repos.archlinux.org/wsvn/packages?op=comp&compare[]=/kernel26/tr...@89612&compare[]=/kernel26/tr...@90844 Thanks for your time, (sorry, if this mail went where it shouldn't have) Det
Re: [aur-general] AUR - 'kernel26' search results
Well, well, well, hello to you too! On 9/19/10, Peter Lewis wrote: > On Sunday 19 September 2010 at 08:20 Det wrote: >> [...] Maybe there just should be a simple *remove* button: > > I agree, and I've been working on this - sent a few patches to aur-dev and I > plan to do more too. Hey, that's great! Stuff like 'online' PKGBUILD editor, auto clean of AUR from obsolete/old packages (e.g. over year old packages that don't have many votes, have no maintainers and have been flagged out of date (if even that)), a little faster updation of the downloadable package tarballs after a change has done to the package, some well designed *vote orphan* button that'd reduce the "please orphan" requests to TUs and other stuff like that? It'd be _very_ nice, if that stuff got implemented! >> akonadi-caldav-svn: http://aur.archlinux.org/packages.php?ID=34613 > > This code has recently been merged into the main SVN and is no longer in > playground: > > http://lists.kde.org/?l=kde-pim&m=127047028903012&w=2 > > http://websvn.kde.org/trunk/KDE/kdepim/runtime/resources/ > > I'm not sure what release it will make it into though, but I doubt it can be > built without the rest of KDE-PIM from trunk. Those not using trunk can > always use KCalDAV instead: http://aur.archlinux.org/packages.php?ID=35055 Hmm, I think that's what this 'arojas' person actually said on the last comment there ( http://aur.archlinux.org/packages.php?ID=34613 ). Thanks for your time, Det
[aur-general] AUR - 'kernel26' search results
Hi, all of you nice people right there! Just paddled through 'kernel26' search results in AUR and obsolete/delete results with google and here's what I found (there's a lot more left, though) - all this stuff is left by people asking for the removal of the package in either the comment section or the pkgdesc, unaware of the AUR Mailing List or the IRC channel. Maybe there just should be a simple *remove* button: akonadi-caldav-svn: http://aur.archlinux.org/packages.php?ID=34613 gpacman-git: http://aur.archlinux.org/packages.php?ID=34987 gstreamer0.10-farsight: http://aur.archlinux.org/packages.php?ID=19750 haskell-bindings-common: http://aur.archlinux.org/packages.php?ID=27532 kdevelop-extra-plugins-git-git: http://aur.archlinux.org/packages.php?ID=37520 kpdf2: http://aur.archlinux.org/packages.php?ID=12299 (though, maybe not?) kernel26-ck1: http://aur.archlinux.org/packages.php?ID=39490 kernel26-vanilla-git: http://aur.archlinux.org/packages.php?ID=40266 network-manager-applet-notify-osd: http://aur.archlinux.org/packages.php?ID=34282 nvidia-173xx-ice: http://aur.archlinux.org/packages.php?ID=21059 nvidia-173xx-utils-xorg17: http://aur.archlinux.org/packages.php?ID=38504 nvidia-173xx-utils-xorg18: http://aur.archlinux.org/packages.php?ID=39101 nvidia-173xx-xorg17: http://aur.archlinux.org/packages.php?ID=38505 nvidia-173xx-xorg18: http://aur.archlinux.org/packages.php?ID=39191 nvidia-96xx-utils-xorg18: http://aur.archlinux.org/packages.php?ID=39005 nvidia-96xx-xorg18: http://aur.archlinux.org/packages.php?ID=39006 nvidia-opencl: http://aur.archlinux.org/packages.php?ID=31413 notify-osd-clickthrough-patch: http://aur.archlinux.org/packages.php?ID=36178 otrtool-git: http://aur.archlinux.org/packages.php?ID=40775 pcsxr-alsa: http://aur.archlinux.org/packages.php?ID=30663 rxvt-url-yank: http://aur.archlinux.org/packages.php?ID=17263 sopcast-player64: http://aur.archlinux.org/packages.php?ID=35480 ttf-anonymous: http://aur.archlinux.org/packages.php?ID=13389 There's also quite huge amount of all that other old kernel26/nvidia/etc. stuff but I guess they are going to stay.. :/. Thanks for your time, Det
[aur-general] Delete chromium-nogconf
Helllooo, Please delete chromium-nogconf: http://aur.archlinux.org/packages.php?ID=35972 - the previous maintainer recommends to "install no-gconf and chromium from extra instead".
Re: [aur-general] Please delete a lot of packages
On 9/12/10, Lukáš Jirkovský wrote: > On 12 September 2010 00:39, Philipp Überbacher > wrote: >> >> I know little about it, but if I'm not wrong, songbird for linux isn't >> developed anymore? So what does it matter? Actually it is, but only in the SVN from which they also release those (these days only i686) precompiled nightly builds. > It seems you're right. It should be replaced by Nightingale > (http://getnightingale.com/), Songbird's fork. Great, but as they say on their front page no releases are available yet. Until then it would be a good thing to clean up the search results for "songbird".
Re: [aur-general] Please delete a lot of packages
On 9/10/10, Lukáš Jirkovský wrote: > On 10 September 2010 13:09, Evangelos Foutras wrote: >> >> Sorry, I'm having a hard time deciding what goes and what stays. >> >> If another TU wants to jump in and handle this request, please do. > > Wow, what a mess. > > For now I would certainly leave the songbird-svn. It has correct name > and it seems to be quite good PKGBUILD. > > I'd prefer if the songbird-auto-nightly was renamed to the > songbird-nightly-bin and then removed. > > I think songbird should be removed, because it's in fact the same as > songbird-svn. I don't see any reason to keep it because it seems that > they do not release any source tarballs. However it has just too much > votes to remove it. > > Lukas > Jesus, well the nicest thing to do then would be to first replace "songbird-nightly" with "songbird-auto-nightly" and _then_ delete: "songbird", "songbird-auto-nightly" and "songbird-nightly-bin". "Songbird" does indeed have a lot of votes, which is just too bad, but if "the binary version of Songbird" has to be "songbird-bin", then "the SVN version of Songbird" has to also be "songbird-svn"... unless that logic would need the developers to release a versioned source too... which they don't. Chrissake, Det
Re: [aur-general] Please delete a lot of packages
On 9/9/10, Evangelos Foutras wrote: > On Thu, Sep 9, 2010 at 10:52 PM, Evangelos Foutras > wrote: >> Deleted xorg-server-gentoo; will go through the songbird mess now. > > I've only deleted songbird-nightly-latest, the rest seem fine to keep > (i.e.: they have maintainers, were updated within a year and have > enough votes). > Ok, thank you but 'songbird' and 'songbird-svn' are the same package so the other one should be removed - with the addition that 'songbird-svn's PKGBUILD works better. 'songbird-nightly' and 'songbird-nightly-bin' are also the same package - with the addition that 'songbird-auto-nightly' is always up to date as it automatically checks for the latest nightly version. Sure, they do have a lot of votes but that's just because they've been around for so long, while 'songbird-auto-nightly' was created less than a month ago. Det
[aur-general] Please delete a lot of packages
Hi, please do such a thing.
1) xorg-server-gentoo (delete; unnecessary (the patches that were
originally used with this package have all been pulled upstream over the
years) and not being updated):
http://aur.archlinux.org/packages.php?ID=15089
2) songbird-nightly (delete; unnecessary ('songbird-auto-nightly' actually
works as it should) and not being updated):
http://aur.archlinux.org/packages.php?ID=13193
3) songbird-nightly-bin (delete; unnecessary ('songbird-auto-nightly'
actually works as it should and uses precompiled binaries) and not being
updated): http://aur.archlinux.org/packages.php?ID=32932
4) songbird-nightly-latest (delete; unnecessary ('songbird-auto-nightly'
actually works as it should) and not being updated):
http://aur.archlinux.org/packages.php?ID=28885
5) songbird-svn (delete; should replace songbird with its PKGBUILD (of
course after changing the pkgname to just 'songbird')):
http://aur.archlinux.org/packages.php?ID=23968
6) songbird (orphan/replace with 'songbird-svn'; doesn't work -
'songbird-svn' does. Both aren't needed since there is a separate
'songbird-bin' package using the precompiled binaries. This can of course be
done the other way around too so that 'songbird' would be removed but maybe
that shouldn't be done.. I don't know, that's why you are doing this - not
me): http://aur.archlinux.org/packages.php?ID=7286
Thanks for deleting a lot of packages,
'Det'
Re: [aur-general] Deletion/Orphan requests
On 9/4/10, Nathan O wrote: > Have you contacted the Maintainers to try and correct the issues, such as > out of date and not working? Well, I don't think any of these packages are just out of date/not working. They've also become unnecessary over the years. - Sorry if this mail didn't get where it should've either...
Re: [aur-general] Deletion/Orphan requests
Forgot xorg-server-gentoo - it's also unnecessary and not being updated: http://aur.archlinux.org/packages.php?ID=15089
[aur-general] Deletion/Orphan requests
Hi (again) TUs and... other people(?),
My earlier, rather long, mail was pretty much ignored so here's another try:
xorg-server-antidesktop (delete; unnecessary and not being updated):
http://aur.archlinux.org/packages.php?ID=23750
xorg-server-catalyst (delete; unnecessary
("xorg-server{,-1.7,-1.8}-catalyst-maximize-fix" exist in AUR) and not
being updated): http://aur.archlinux.org/packages.php?ID=26728
xorg-server-xephyr (delete; unnecessary and not being updated):
http://aur.archlinux.org/packages.php?ID=15438
songbird (orphan; the maintainer decided to replace the PKGBUILD with
a non-working version of songbird-svn - should be replaced with this
one: http://www.mediafire.com/?q59or5x23kr54r6):
http://aur.archlinux.org/packages.php?ID=7286
songbird-bin (delete; unnecessary (unnecessary naming and identical to
songbird-stable-bin)): http://aur.archlinux.org/packages.php?ID=24586
songbird-stable-bin (delete; unnecessary (unnecessary naming and
identical to songbird-bin)):
http://aur.archlinux.org/packages.php?ID=33050
inputproto-newest (delete; unnecessary (identical to [extra]'s
inputproto, which is actually even updated faster)).
Thanks for your time,
"Det"
