Re: [aur-general] Package Removal Request: yajl-ruby, redcloth

[Pierre Chapuis]

On Wed, 20 Apr 2011 20:57:55 +0800, talki walki wrote:


But wait... I double checked: ruby-sqlite3 is actually different from
${ruby-,}sqlite3-ruby:

ruby-sqlite3: http://rubygems.org/gems/sqlite3
sqlite3-ruby: http://rubygems.org/gems/sqlite3-ruby


That's the same gem, and a duplicate on RubyGems.

Moreover you require "yajl" or "sqlite3", not "yajl-ruby" or 
"sqlite3-ruby".

So I'm for "ruby-yajl".

--
Pierre 'catwell' Chapuis

Re: [aur-general] Upgraded AUR to 1.8.0

[Pierre Chapuis]

On Mon, 21 Feb 2011 14:46:24 -0500, Loui Chang wrote:


Functionality needs to be moved to the
clients for the better future of the AUR. Let's not think of the AUR 
as

a mere webapp.


Couldn't you think of the webapp as just another client? In which case
it could use JavaScript to uncompress the files on the user's
workstation and display them.

--
Pierre 'catwell' Chapuis

Re: [aur-general] Upgraded AUR to 1.8.0

[Pierre Chapuis]

On Mon, 21 Feb 2011 12:19:08 +0100, Lukas Fleischer wrote:


How often do you do that? Why don't you just download the tarball and
check its contents? I also can't imagine a lot of cases where the
PKGBUILD preview doesn't give you an idea of what a package does.


At least all the cases where there's a .install script.

That said I'm fine with leaving the verification job to AUR helpers.

--
Pierre 'catwell' Chapuis

Re: [aur-general] AUR & Copyright

[Pierre Chapuis]

On Thu, 10 Feb 2011 13:17:29 +, Michael Schubert 
 wrote:
As long as the maintainer (aka copyright holder) are allowed to 
specify

their

own license then I'd be fine with it, though.


Copyright holders are always allowed to publish their work under any
additional license. No issue there.


Well, except when you adopt a package. Then there are two copyright
holders and things get ugly.

I think this discussion is pointless anyway: PKGBUILDs are build 
recipes,
not code. They usually do not contain enough information to be 
license-able.
So even if someone stuck a copy of the GPL at the top of a PKGBUILD I 
would
simply ignore it, because he had no right to put a license on 
"./configure;

make; make install" or something similar in the first place.

--
Pierre 'catwell' Chapuis

Re: [aur-general] [Announcement] First public git repo of the complete AUR.

[Pierre Chapuis]

On Sun, 6 Feb 2011 17:43:59 -0500, Loui Chang  
wrote:



You probably want to grab the tarballs, and extract what's in those.
The next release of the AUR will only have tarballs and PKGBUILDs.
The other files won't be extracted.


Would it be possible to also extract .install scripts? I usually
read those before installing AUR packages since they don't come
from a trusted source.

--
Pierre 'catwell' Chapuis

Re: [aur-general] [arch-general] Please settle 'base' in 'depends' for all

[Pierre Chapuis]

On Thu, 20 Jan 2011 00:25:15 +1000, Allan McRae  
wrote:


The problem is that the transitive closure can not be assumed to be 
correct.


e.g.  At the time A is built:

A -> B,C,D,E
B -> C,D,E
C -> D,E

Then B is updated and

B -> C,D,E,F.

Now the assuming a transitive closure for the dependency list for A
is incorrect.  Installing the listed dependencies of A with the
equivalent of -Sd would result in F not being installed which would
break A through broken B.

So either:
1) we require a largely unnecessary rebuild of A
2) we always check the dependencies of uninstalled dependencies.

Note #2 is less burden on packagers and is more efficient in the
examples given above if both B and D are installed (two checks vs
four), and that will be the case for most system updates.  When none
of A - E are installed, they are probably equally efficient.


Yes, I agree with that: dependencies will always have to be checked
at package install time. That means that any approach based on a
"transitive closure" at packaging time is useless.

What could also happen is that C is updated and no longer needs E.
Then, with a "transitive closure", A would still install E, which
would be useless for the user. So the only way to be safe is not to
be clever and to specify real dependencies, eg:

Real deps
-
A -> B,D
B -> C
C -> D,E

Transitive closure
--
A -> B,C,D,E
B -> C,D,E
C -> D,E

Current Arch way

A -> B
B -> C
C -> D,E

What should be done
---
A -> B,D
B -> C
C -> D,E

--
Pierre 'catwell' Chapuis

Re: [aur-general] [arch-general] Please settle 'base' in 'depends' for all

[Pierre Chapuis]

On Wed, 19 Jan 2011 23:59:55 +1000, Allan McRae  
wrote:



Huh?  How is no dependency checks (-Sd) equivalent to complete
dependency checking (-S with a transitive closure of dependencies)?
They are polar opposites.


What I mean is that if a transitive closure of dependencies is
performed at packaging time, then there is no need to check for
dependencies when installing the original package.

Here is an example:

A depends on B and D
B depends on C
C depends on D and E

Currently the deps will be:

A -> B,D
B -> C
C -> D,E

When installing A, Pacman will:

1) check deps for A, start installing B and D
2) check deps for B and D, start installing C
3) check deps for C, start installing E

With a transitive closure scheme at packaging time, the
deps would be:

A -> B,C,D,E
B -> C,D,E
C -> D,E

When installing A, Pacman could simply install B, C, D and E
*without* checking their deps (-Sd) because these deps are
necessarily already included in those for A.

--
Pierre 'catwell' Chapuis

Re: [aur-general] [arch-general] Please settle 'base' in 'depends' for all

[Pierre Chapuis]

On Wed, 19 Jan 2011 23:19:33 +1000, Allan McRae  
wrote:



Ah...  OK. then I don't understand this:

On 19/01/11 22:49, Magnus Therning wrote:

Well, if the creation of the transitive closure of dependencies is
created at package build time, then it can be removed from pacman,
that should give a bit of a speed-up I suspect.


When pacman does dependency checks, it checks if the package listed
in the dependencies is installed.  It does not check if all its
dependencies are installed too (as it is assumed that was done at the
time the dependency was installed).  If we list the transitive 
closure

of dependencies, then pacman has to perform extra checks and so will
not give a speed-up.


Well, except if you assume that all packages do this perfectly.
Then when installing a package with '-S' Pacman can install its
dependencies with the equivalent of '-Sd', which will be faster.

I find that approach dangerous though...

--
Pierre 'catwell' Chapuis

Re: [aur-general] TU Application: Lukas Fleischer

[Pierre Chapuis]

On Mon, 11 Oct 2010 16:45:01 +0200, Lukas Fleischer 
 wrote:


It's still quite easy to build custom packages that are in 
[community],

e.g. using the ABS [1]. You could use something like the following
command to sync PKGBUILDs from the repositories, edit your "config.h"
and build a new package (assuming that abs/sudo packages are 
installed,

"$HOME/builds" is an existing directory and the EDITOR environment
variable is set correctly):

`pkgname=surf; sudo abs community/$pkgname && cp -r
/var/abs/community/$pkgname/ $HOME/builds && cd $HOME/builds/$pkgname 
&&

$EDITOR config.h; makepkg -is`

Of course, you can also do this step-by-step or write a wrapper 
script
if that looks too complicated to you... If you ever used the dwm 
package

from [community], the same thing is done there :)


Your suggestion works for me, so I will be happy to let you take over
the package. Good luck with your application!

--
Pierre 'catwell' Chapuis

Re: [aur-general] TU Application: Lukas Fleischer

[Pierre Chapuis]

"Lukas Fleischer"  a écrit :

> optionally surf

How would you deal with config.h? To me surf should stay in AUR because of that.
-- 
Pierre 'catwell' Chapuis

Re: [aur-general] openmpi, mpich2: provides 'mpi'

[Pierre Chapuis]

On Mon, 23 Aug 2010 12:14:30 +0200, Marco  wrote:
> Hi people,
> 
> should we define a provides=("mpi") or something like that in openmpi
> and mpich2, and eventually also other possible mpi implementations?
> That way a number of mpi-dependent packages will be made undependent
> of the chosen mpi implementation one wants to install.

Not that my voice matters much but I agree on that. It's the same kind
of thing than depending on java-runtime vs. JRE, especially since MPI
was specifically designed as a specification that could have multiple
implementations.

Packagers will have to be careful though since some functions do not
work exactly the same way in every implementation...

-- 
Pierre 'catwell' Chapuis

Re: [aur-general] [orphan request] mlmmj

[Pierre Chapuis]

On Sat, 27 Feb 2010 14:16:51 +0100, Giovanni Scafora
 wrote:
> 2010/2/27, Pierre Chapuis :
>>  Package link: http://aur.archlinux.org/packages.php?ID=12175
> 
> It's orphan.

Adopted, thanks!

[aur-general] [orphan request] mlmmj

[Pierre Chapuis]

Hello,

I would like mlmmj to be orphaned so that I can adopt it. It has been
flagged out of date for a long time, I have posted a working PKGBUILD in
the comments 10 days ago and I have emailed its maintainer without an
answer.

Package link: http://aur.archlinux.org/packages.php?ID=12175

Re: [aur-general] orphans in [community] - full list

[Pierre Chapuis]

Le Fri, 05 Feb 2010 02:03:49 -0600,
"Daniel J Griffiths (Ghost1227)"  a écrit :

>  luarocks
>  Depends: lua
>  Required by: none

If nobody wants it I can take it in AUR, but I hope not, it belongs in
community.

Re: [aur-general] TU without [community] maintaining?

[Pierre Chapuis]

Le Wed, 3 Feb 2010 19:55:10 +0100,
Laszlo Papp  a écrit :

> > key management should further be integrated into yoaurt (or the like)
> 
> Yaourt is not supported officially, and it's buggy and abandoned
> program at this momment, and it has got a very bad design concept to
> parse URLs directly, so much people wouldn't like to use it ...

Yaourt is not abandonned, and he did say "and the like", which includes
Bauerbill, Pakthan... Bauerbill already implements a way to trust users
but the names of the users that can be trusted have to be configured
manually.

I used to dislike those wrappers very strongly when they didn't allow
their user to verify PKGBUILDs. Now they all do, and that's their
default behavior. I still don't use them because they wouldn't save me
much time, the most time-consuming part of the installation of AUR
packages being to check the PKGBUILDs. I might switch to bauerbill
though, because although what it does is not enough, at least it allows
me to trust selected users.

-- 
catwell

Re: [aur-general] TU without [community] maintaining?

[Pierre Chapuis]

Le Wed, 3 Feb 2010 19:55:55 +0100,
Heiko Baums  a écrit :

> Am Wed, 03 Feb 2010 20:41:34 +0200
> schrieb Lauri Niskanen :
> 
> > I agree that peer trust network is a nice idea and that pgp keys might
> > be unnecessary. AUR accounts are already authenticated by the web
> > system and user can be easily coupled with the uploaded files.
> > 
> > You should be able to upload packages without any thrust status and
> > also downloading and installing untrusted packages should be
> > possible. There could be packages with trusted status, so the users
> > wouldn't have that must packages to be checked by themselves.
> 
> This was previously implemented in and removed from AUR a long time ago.
> I guess there was a reason for this.

The reason was that only TUs could flag a package as trusted, and this
was done by package and not by user, so it was a lot of work. Actually,
if I remember well, I even think it was done by package *revision*
which means packages had to be checked by TUs every time a new version
was uploaded. It obviously couldn't scale.

If the trust is given at the user level, it makes it much less trouble.
For example, if the average "trusted" user has 20 packages, each of
which has 5 revisions in the user's account's lifetime, it divides the
amount of actions necessary by 100 (although it is more complex to
check that a user can be trusted than that a package is safe). It is
similat to the "give the man a fish" principle Archers should be
familiar with. The drawback is that it is a bit less secure, probably,
because ultimately more people have to be trusted.

A trust network goes even further on both aspects (more scalability,
less security). I'm not sure going that far is needed but it is a neat
idea.

-- 
catwell

Re: [aur-general] TU without [community] maintaining?

[Pierre Chapuis]

Le Wed, 03 Feb 2010 15:41:38 +0100,
Thomas Bächler  a écrit :

> I think it is a good idea. We could create the "AUR moderator" position
> instead of calling it "Semi-TU".
> 
> When I was a TU, I didn't care at all about moderating the AUR, and
> maybe other TUs feel the same and rather do packaging. Conversely, you
> don't seem to care about packaging but about AUR moderation.
> 
> I am forwarding this to arch-dev-public for reference, but I guess
> ultimately the TUs have to decide.

I even think it could be a good idea to have "real" Trusted Users in the
sense that they can be trusted as to which packages they publish on the
AUR, not necessarily in binary form. They would be approved by some
process, and then added to a list which could be used by software like
yaourt / pakthan / bauerbill to let the users install their packages
without checking the PKGBUILDs. The fact that a package on the AUR is
maintained by one of these users (they would include current TUs and
devs) would be accessible in the metadata (through the json RPC for
example).

I know there used to be a flag like that on the AUR and that it didn't
work, but I think it's mainly because it was on a "by package" basis
instead of a "by user" basis, which makes it a lot more work for those
who have to check.

As for what should be checked when users apply for this position, I
would say at least:

  - a sufficient expertise in packaging, proved by the existence of
several good packages maintained by them on the AUR, and
  - a means to contact them efficiently (valid email address).

Anyway this is just my two cents as an Arch user, but I consider the
lack of any way to trust AUR PKGBUILDs without reading them to be the
thing that annoys me most with Arch as of now.

-- 
catwell

Re: [aur-general] TU Resignation

[Pierre Chapuis]

Le Sun, 31 Jan 2010 18:41:34 -0500,
Jim Pryor  a écrit :

> I'm closely following Lua, and can help out with the luadoc, luafilesystem, 
> and
> lualogging. luajit doesn't yet work on x86_64, which my machines are,
> and I haven't played with it at all, so I won't say I can help with
> that.
> 
> Now I'm not a TU, and don't really have the time to take
> on TU responsibilities even if you trusted me! I'm just offering to
> help out, in case some TU is willing to adopt them but hesitates on account 
> of 
> lack of experience with Lua. Or if these were to go to AUR, then I could
> take them.
> 
> The four Lua packages in AUR are graphics/plotting packages I don't use.
> Hopefully there's someone else who does. But if not, I could be a foster
> parent until someone comes along.

I am also a Lua user, and as I was reading posts by the Arch Haskell
team I thought maybe a project like that should be created for Lua. I
would love to see a better support for it in Arch, and especially to
see all of Kepler packaged (including Xavante).

If other users on this list are interrested, please email me and maybe
we could set up a user repository for lua modules...

-- 
catwell

[aur-general] Orphaning / giving away packages

[Pierre Chapuis]

I have just orphaned a few packages because I don't use them anymore,
so you can adopt them if you want. They are:

gfaim: cooking recipes software in French
lib32-libmad: I probably needed it for a proprietary game someday...
lout: LaTeX alternative
ltsa: a formal verification tool for concurrent systems
spin/xspin: formal verification of distributed software systems and
protocols

I have also kept the following packages but I'm willing to hand them
over if someone else wants to maintain them:

gsi-sshterm: Java SSH application to log in computing grids
mpy-svn-stats: Subversion logs analyzer (generates stats...)
springgraph: alternative to neato (renders graphs)
sig2dot: tool to plot a GPG keyring
python-irclib: Python IRC client library

I have also orphaned globus, a toolkit to build grids, but maybe it
should simply be removed or updated to version 5.0 (which is not
backwards-compatible though, I didn't try to build it at all). The
package gt provides version 4.0 but it looks unmaintained and is
almost impossible to find because its description does not contain
the word "Globus".

Finally, I think the python-decorator package should go to community:
it has 97 votes and is probably one of the most useful Python modules.
If no TU wants to take it I will keep maintaining it in AUR.

Thanks for reading ;)

-- 
catwell

Re: [aur-general] unparseable PKGBUILD

[Pierre Chapuis]

Le Tue, 10 Nov 2009 10:03:04 +0100,
Cilyan Olowen  a écrit :

> By the way, is it possible to upload to AUR PKGBUILDs that builds more
> than one package and where pkgname is an array ?
> This is supported by makepkg, but I don't know if the AUR interface
> and aur helpers like yaourt can handle them ? One official example is
> the mesa PKGBUILD[1] in extra that also produces ati-dri, intel-dri,
> nouveau-dri, ...
> 
> Regards,
> 
> Cilyan
> 
> [1] http://repos.archlinux.org/wsvn/packages/mesa/repos/extra-i686/PKGBUILD

Sadly, not yet.
http://bugs.archlinux.org/task/16394

-- 
catwell

Re: [aur-general] How to make a PKGBUILD for Kepler/Xavante?

[Pierre Chapuis]

Le Sun, 27 Sep 2009 20:57:58 -0400,
Daenyth Blank  a écrit :

> Generally there will be some Makefile (or equivalent) variable that
> can be changed to make that work right. Any non-broken build system
> should support this.

The problem is that the setup method for Kepler is a bit specific and doesn't 
use makefiles or such things. It's a shell script that can take a --prefix 
option, but that directory needs to be writable so it needs to be prefixed by 
$pkgdir/.

[aur-general] How to make a PKGBUILD for Kepler/Xavante?

[Pierre Chapuis]

Hi listmates,

as I said in an earlier email in another thread, I always try to make a 
PKGBUILD for every piece of software I install. There's an exception though: 
the Lua webserver Xavante, which is part of the Kepler distribution 
(http://www.keplerproject.org/xavante/).

I can set it up without Pacman that way: 
ftp://catwell.info/misc/arch/xavante/howto-setup.txt but I haven't found a way 
to make it work properly with makepkg.

The problem is that the setup process run in a fakeroot leaves the string 
corresponding to $pkgdir in a lot of places in the resulting files, including 
binary files. I have tried to use sed on the resulting files but I didn't 
manage to get rid of it everywhere, neither to get a working package.

Has somebody already given a try at packaging such an application, and are 
there examples of packages that deal with this kind of problem?

Thanks,

-- 
catwell

Re: [aur-general] advice wanted on "surf" package

[Pierre Chapuis]

Le Sun, 27 Sep 2009 18:08:45 -0400,
Ray Kohler  a écrit :

> Disowned. It's all yours. Given that you actually use it, and I don't,
> that would be enough all by itself.

Adopted, although I hadn't noticed there was another package than the one I 
used, which was surf-hg. But I was thinking of switching to the stable branch 
anyway.

-- 
catwell

Re: [aur-general] advice wanted on "surf" package

[Pierre Chapuis]

Le Sun, 27 Sep 2009 17:21:23 -0400,
Ray Kohler  a écrit :

> Back on topic, I think I'll wait and see if anybody else has any
> surprising suggestions that disagree with this one, and if none are
> forthcoming, I'll disown the surf package. Having a pacman developer
> tell me not to use pacman for a given purpose is rather convincing, in
> which case, I should let someone who _isn't_ convinced take on the
> package and worry about the problem, instead of me. ;)

Well, I am not since I use surf with the stock configuration :)

Even if I weren't, I don't use Yaourt or any automatic upgrade tool (but I do 
have a script that checks and warns me if my packages are outdated) so the way 
it works now is OK for me.

I always install everything with Pacman when I can because it can track the 
files in my system tree for me. I create custom PKGBUILDs if I need to, even if 
they have to be ugly.

Anyway, I think surf should stay in AUR and be maintained so I'm ready to take 
ownership of the package if you choose to disown it.

-- 
catwell

Re: [aur-general] Adding a .deb packaged application to the AUR

[Pierre Chapuis]

Le Fri, 18 Sep 2009 12:15:36 -0700,
Smartboy  a écrit :

> On Fri, Sep 18, 2009 at 12:09 PM, Jeff Horelick  wrote:
> 
> > Hello Listmates,
> >
> > I have a package here i'd really like to add to the AUR. The problem is
> > that
> > its packaged in a .deb. How would i go about packaging this for Arch? Feel
> > free to just point at: "Look at this other package" or "Read this wiki
> > page".
> >
> > In case some of you guys don't know the formmat that a .deb is in:
> >
> > An ar archive, inside there are 2 tarballs, one called control.tar.gz which
> > for our purposes can be mostly ignored and one called data.tar.gz which has
> > the actual application files laid out in the directory structure of the
> > system similar to a Arch final binary package. (usr/bin/stuff,
> > usr/share/stuff and so on).
> >
> > Or would it be easier for me to just setup a GitHub or BitBucket account,
> > drop all the source files on there and simply make a hg or git package?
> > (For
> > the record and all, it's not my project, but it is GPLv2 so)
> >
> Use deb2targz to convert it to a binary suitable for integration with a
> pkgbuild. It would be better to just put the source files in GitHub, though,
> as using sources is preferred over binaries in Arch.
> 
> If you want an example of a PKGBUILD which converts a binary deb package to
> a tar.gz, see my oz-e17-tools
> package


You can also use bsdtar, which is provided by libarchive. It has the advantage 
not to add a builddep to the PKGBUILD. See 
http://aur.archlinux.org/packages/chromium-browser/chromium-browser/PKGBUILD if 
you want an example.

-- 
catwell

Re: [aur-general] AurJson - orphan packages

[Pierre Chapuis]

Le Mon, 14 Sep 2009 22:46:15 +0800,
Gergely Imreh  a écrit :

> I'm CC-ing this to the aur-dev, as I think it belongs there.
> 
> The following patch adds the Orphan field to the aurjson output. For
> username we would need  to hit the database once more (maybe, have to
> think more SQL for that), but the Orphan-ness is quite straightforward
> to evaluate. So let's just do that first.
> 
> This patch, however, might clash with one patch I sent in a few days
> ago [1], since that one hasn't been applied to the repo, yet. Anyway,
> neither of those are hard to see where they should go...
> 
> Any comments?

Looks good enough for me, since it would allow me to do what I wanted (include 
orphan detection in the script I use to watch the AUR packages I use). Thanks 
for the quick response!

-- 
catwell

Re: [aur-general] AurJson - orphan packages

[Pierre Chapuis]

Le Sun, 13 Sep 2009 18:23:02 +0200,
Pierre Chapuis  a écrit :

> Hi,
> 
> I was wondering if there's a way to know if a package is orphan using the 
> AurJson interface.
> 
> If that's not the case, I think I will find a feature request for something 
> like:
> 
> "Uploader":"pseudonym"
> 
> in "info/results", with "pseudonym" set as "orphan" if the package is orphan 
> (I hope nobody has taken the pseudonym "orphan" on AUR...).
> 
> Does that look fine to you?

Of course I meant: "I will file a feature request"...

Another possibility might be to add a boolean like OutOfDate, but the solution 
I proposed would also enable scripts to find the uploader of a package, which 
might be useful later. As far as I'm concerned, I don't really care since I 
only want to know if the package is orphan...

-- 
catwell

[aur-general] AurJson - orphan packages

[Pierre Chapuis]

Hi,

I was wondering if there's a way to know if a package is orphan using the 
AurJson interface.

If that's not the case, I think I will find a feature request for something 
like:

"Uploader":"pseudonym"

in "info/results", with "pseudonym" set as "orphan" if the package is orphan (I 
hope nobody has taken the pseudonym "orphan" on AUR...).

Does that look fine to you?

-- 
catwell

Re: [aur-general] Duplicate package: lua-expat

[Pierre Chapuis]

Le Fri, 28 Aug 2009 12:59:00 -0400,
Scott Smith  a écrit :

> I'd suggest removing luaexpat instead as lua-expat conforms to the AUR
> guidelines.

lua-expat is more recent and orphan, whereas the other one is maintained. Maybe 
its name should be changed to lua-expat for consistence though.

[aur-general] Duplicate package: lua-expat

[Pierre Chapuis]

http://aur.archlinux.org/packages.php?ID=21939 (lua-expat) is a duplicate of 
http://aur.archlinux.org/packages.php?ID=13509 (luaexpat) and should be removed.

-- 
catwell

Re: [aur-general] Extra/AUR duplicates

[Pierre Chapuis]

Le Sun, 23 Aug 2009 14:40:51 +0200,
Stefan Husmann  a écrit :

> Well, words in AUR is different from words in extra. But it does not compile. 
> Has Arch Linux an ada compiler?

Afaik it does not. The best one I found is gcc-ada from AUR.

-- 
catwell

Re: [aur-general] TU dashboard accounts

[Pierre Chapuis]

Le Mon, 10 Aug 2009 14:07:24 -0500,
Aaron Griffin  a écrit :

> We looked into that, but that's not much better than a self signed
> cert. We discussed this at length among the devs, and already made a
> decision. We're well aware of all the options :)

It is also not easy to get a certificate from CACert for anything else than an 
individual, but it can be done.

Anyway, I am a CACert assurer (who doesn't have many points yet, but still...) 
and I know a few others so if you happen to need a certificate you can I can 
try to help.

I also agree with Aaron: a self-signed certificate is good enough if the 
application is to be used by a few identified people only. If they want to 
check the authenticity of the certificate they just need to ask somebody else 
to send them the original...

-- 
catwell

[aur-general] AUR package name change

[Pierre Chapuis]

Somebody asked me to rename my mplayer-nogui-svn [1] package to 
mplayer-minimal-svn.

I think he's right, that would be more logical now that there's no GUI included 
in the mplayer package, but is there a way to do this without losing comments 
and votes?

[1] http://aur.archlinux.org/packages.php?ID=18516

Re: [aur-general] When does a package need -svn?

[Pierre Chapuis]

Le Sun, 26 Apr 2009 22:18:33 +0200,
Xyne  a écrit :

> My interpretation of b is that you don't actually have to host the
> files but you must be able to supply the sources upon request. As the
> PKGBUILD is readily available and is able to retrieve the source files,
> that condition is met.

It is not. If you want to use b), you have to:
- state it explicitely ;
- keep a copy of the sources of every version you distribute in binary form for 
3 years in case it is no longer available at its original location.

I don't think it is a good thing, but that's what the GPL says. That's one of 
the reasons why I avoid its use when I can...

-- 
catwell

Re: [aur-general] How to handle interchangeable dependencies?

[Pierre Chapuis]

Le Tue, 7 Apr 2009 05:16:53 +0800,
Ray Rashif  a écrit :

> Fixing the "+" problem in AUR won't be of much help IMHO (but I recall it
> was in the TODO list). Such a package can come with "p" instead, and when/if
> it gets to a supported repository there'd be nothing to complain about.

It could be a problem for packages in community, which are both in AUR and in a 
repository.

Re: [aur-general] How to handle interchangeable dependencies?

[Pierre Chapuis]

Le Mon, 6 Apr 2009 16:53:16 +0200,
 a écrit :

> For me the case is simple, the yaourt webpage[1] led me to this
> bugtracker or at least made it appeared to be the bugtracker, I just
> reported the bug. If this is wrong then official Arch and yaourt need
> to straighten this out.
> No matter if it's unofficial, it's heavily related and as such both
> projects should talk to each other.
> 
> [1] http://archlinux.fr/yaourt-en

The real bugtracker for Yaourt is the one linked at the bottom of the page, not 
at its top [1]. The people at archlinux.fr should indeed fix that so that no 
more users report bugs for Yaourt on the official bugtracker.

[1] 
http://bugs.archlinux.fr/index.php?tasks=all&project=3&string=&type=&sev=&due=&dev=&cat=&status=all&date=0

-- 
catwell

Re: [aur-general] How about hashtags in package description?

[Pierre Chapuis]

Le Sun, 15 Mar 2009 11:54:12 -0400,
Daenyth Blank  a écrit :

> > What's the practical difference between a tag and a hashtag?
> I think that he means to put tags as comments? I have no clue really

I thought he was talking about something like tags used in Jabber or Identi.ca 
posts. They are inline and begin with a hash, like that:

I think #Arch #Linux is awesome.

-- 
catwell

Re: [aur-general] moreutils in community

[Pierre Chapuis]

Le Thu, 26 Feb 2009 23:50:45 +0100,
Geoffroy Carrier  a écrit :

> Well I love those tools, so I'd say... Let's vote!

I didn't know these tools existed, at least this thread learnt me something 
useful. I've voted for them now, by the way. I hope enough users do so so they 
can stay in community.

-- 
catwell

Re: [aur-general] The search engine needs improvements

[Pierre Chapuis]

Le Sat, 10 Jan 2009 22:55:39 +0100,
Xavier  a écrit :

> But then again, rar is probably a corner case. I have personally never
> ran into that problem in all the searches I did on AUR so it is
> probably not a big deal :)

Ever tried to search vi? :)
+1 from Just Another User on Xavier's suggestion to do the same as in viewvc.

-- 
catwell

Re: [aur-general] Suggestion of resource on AUR.

[Pierre Chapuis]

Le Mon, 05 Jan 2009 18:11:42 -0500,
Ghost1227  a écrit :
 
> I agree that this is generally a good idea, although two weeks does seem 
> a bit short (especially around the holidays). As for instances where a 
> package can't be updated, perhaps a new flag could be implemented for 
> these situations? I've had a few of those situations myself and they can 
> be frustrating, so I suggest the possible addition of a "pending update" 
> flag or similar. Something that could give the maintainer the ability to 
> mark a package in such a way as to notify the community that although 
> the package is not functional, it is being looked into. Additionally, it 
> could potentially lock out the ability to flag the package out-of-date 
> to prevent packages in situations like this from being auto-orphaned if 
> the discussed auto-orphan idea is implemented. Thoughts?

Let's not add too much complexity to the AUR is what I think. I'm for 
auto-orphan after a month, vacations are usally not that long, and even if 
that's the case, one month without an update is too long.

What I would like to see is a "broken" flag and/or the possibility for the 
maintainer of the package to be notified by email of any comment on one of his 
packages (a bit like with flyspray). I often don't see comments on my packages 
saying that they don't build anymore because they were broken by another 
package's update.

-- 
catwell

Re: [aur-general] AUR Upgraded

[Pierre Chapuis]

Le Wed, 17 Dec 2008 23:38:47 +0100,
"Cilyan Olowen"  a écrit :

> Updated french translation. There are some strings that are not seen
> by the translation_tool. Then I missed them. I hope I did not missed
> some more...

I don't know if it's expected but the French translation for AUR looks broken. 
See this screenshot of the home page for an example: 
ftp://catwell.info/tmp/aur.png

-- 
catwell

[aur-general] Duplicates from core and extra in AUR

[Pierre Chapuis]

I wrote a script that can, among other things, find packages in AUR
that have the same name that a package in another repo. I think most of
these packages should be removed from the AUR or at least renamed. For
more information see
http://bbs.archlinux.org/viewtopic.php?pid=468188#p468188.

-- 
catwell

Re: [aur-general] Codeblocks vanished from AUR

[Pierre Chapuis]

Le Mon, 22 Dec 2008 01:52:24 +0100,
"stefan-husm...@t-online.de"  a écrit :

> Hello,
> 
> the package codeblocks I maintain in Community vanished. I am quite sure
> this happened not long ago, maybe yesterday ore the day before. The
> x86_64 package still shows up on Pierre's package list on archlinux.de,
> but the i686 package does not. Also the AUR comment page is gone. 
> 
> Now someone uploaded codeblocks again to AUR. What should I do? 
> 
> Regards Stefan

If this can help you, I had already noticed it wasn't in AUR 5 days
ago, when I tested my repo check script on community; see
http://catwell.info/test/community/.

-- 
catwell

Re: [aur-general] 500 Haskell packages now in AUR

[Pierre Chapuis]

Le Wed, 20 Aug 2008 13:24:17 -0300,
Roberto Alsina <[EMAIL PROTECTED]> a écrit :

> On Wednesday 20 August 2008 13:15:29 Loui wrote:
> > On Wed, Aug 20, 2008 at 09:09:48AM -0700, Don Stewart wrote:
> > > 10 weeks after the Arch Haskell group started, there are now 500 Haskell
> > > packages bundled up for Arch.
> > >
> > > I've written about how we automated the construction of Arch packages
> > > from Haskell Cabal format, via the cabal2arch tool, and a small survey
> > > of 10 nice packages from the set, here,
> > >
> > > http://cgi.cse.unsw.edu.au/~dons/blog/2008/08/21#the_500
> > >
> > > Cheers,
> > >   Don
> >
> > Nice. Maybe AUR should be rewritten in Haskell too. Ha Ha.
> 
> Is anyone interested on a similar approach to Python's PyPI? It sounds like a 
> fun project!

If you want to create an Arch Python team, I'm in.

-- 
catwell

Re: [aur-general] [arch-dev-public] Please stop the install message insanity

[Pierre Chapuis]

Le Wed, 30 Jul 2008 03:28:35 +,
"Abhishek Dasgupta" <[EMAIL PROTECTED]> a écrit :

> If a package really has to give an install msg which pertains
> to some other package then it should first check if that
> package exists (pacman -Q ... is it possible to call pacman
> from within the post install scripts?), and then print it out.

A workaround would be to check if a specific file exists, or  if something is 
in PATH. I use something like that in one of my AUR packages (LTSA) :

  which mc > /dev/null 2> /dev/null
  if [ $? -ne 0 ]; then
do_something
  fi

-- 
catwell

Re: [aur-general] TU application

[Pierre Chapuis]

Le Fri, 4 Jul 2008 12:00:30 +0200,
"Ronald van Haren" <[EMAIL PROTECTED]> a écrit :

> I had a quick look too, overall the quality seemed to be fairly good
> from the few packages I checked. I thrust you guys on the rest ;)
> 
> Anyway, what I was wondering (I don't feel like reading the guidelines
> now), is the use of install instead of cp (some people even use mv)
> documented somewhere as it seems to be a quite familiar 'mistake'
> people make?
> 
> Ronald

I'd be interrested by that too. As of now, I see no real reason to use install 
instead of mkdir -p, cp, chmod, except maybe that it's one line instead of 
three.

-- 
catwell

Re: [aur-general] TU Voting On The AUR

[Pierre CHAPUIS]

Le Wed, 7 May 2008 14:03:17 +0200,
Xavier <[EMAIL PROTECTED]> a écrit :

> Hello,
> 
> I am curious why no one is interested in this :
> http://www.archlinux.org/pipermail/tur-users/2008-February/007020.html
> Besides many other advantages like automation and anonymity, it should
> remove noise on this ML and prevent non-TU from voting. But maybe
> that's where the fun is (old school ftw) :)
> Otherwise, if there was a real interest, then finishing that project
> shouldn't be a big problem.

Do you really think anonymity is needed ?

I consider the fact that anybody can see the votes of the TU a good thing, it 
makes their actions more "transparent" to the community.

To prevent non-TU from voting, just precising in the original post that voting 
is for TU only should be OK...

-- 
Pierre 'catwell' Chapuis

Re: [aur-general] AUR Cleanup Day organization

[Pierre CHAPUIS]

Le Fri, 02 May 2008 23:53:51 +1000,
Allan McRae <[EMAIL PROTECTED]> a écrit :

> I suggest we get together in the TU IRC channel on the weekend of 17/18 
> May and go through the list.  I think we should take care not to get too 
> carried away when we remove packages.  While some packages may be 
> orphans, if they are not out of date then the PKGBUILD could still be 
> useful for some people.

I suggest you use a public channel instead of the TU channel, so that other 
Arch users can participate and why not adopt packages live. Not the Arch one 
though, it's too crowded. Maybe you could create a temporary channel for the 
event...

-- 
catwell