Re: [aur-general] Somebody using freetype2-infinality, too?

[Justin Dray]

I believe infinality is dead now. I saw someone posted the other week about
this new fonts meta package [1] that allows similar things, but all my
remaining arch systems are headless these days, but I would give it a go
rather than infinality now.

[1] https://aur.archlinux.org/packages/fonts-meta-base/

Re: [aur-general] [review-request] python-intelhex

[Justin Dray]

This would probably be best posted to the package page for the
python2-intelhex package. The mailing list isn't really for issues with
individual packages.

FYI, removing the bin on python2 will be so that you can install both
packages side-by-side without conflicts, but the python3 will be the
default one used as a binary on the path.

On Tue, 24 Jan 2017 at 11:49 Quentin Bourgeois  wrote:

> Hi,
>
> I am currently looking for building python2-intelhex[0] from
> AUR. Unfortunately the build failed, while I am using aursync[1] and
> require build into a clean (created for this build) chroot:
>
> $ aursync -c python2-intelhex
> [...]
> ==> Starting package_python-intelhex()...
> /startdir/PKGBUILD: line 17: python: command not found
> ==> ERROR: A failure occurred in package_python-intelhex().
> Aborting...
> ==> ERROR: Build failed, check /var/lib/aurbuild/x86_64/user/build
>
> Note that with the python3 package version I come up with the same
> bug.
> Thus, I decide to have a look at the PKGBUILD and suggest some
> modifications I guess the maintainer will be glad to merge any
> proposal, but did the community see any thing more to change ?
> Basically I made use a lot more of its internal variable __pkgname,
> define python{,2}-setuptools as makedepends and add the license file
> to the package.
>
> In another way I don't really understand the rm on the bin directory?
> The problem I saw is that only installing python2-intelhex wont allow
> the use of the provided scripts[2]. However, I conducted small
> tests and they seems to works even with python2. So my guess is to
> create an other AUR PKGBUILD that will perform pretty the same things
> but only packaging the provided scripts, let call this package
> python-intelhex-scripts. Then, one need to enforce a dependencies of
> python{,2}-intelhex with python-intelhex-script at the same upstream
> release version.
>
> I propose some modification in the python-intelhex[3] PKGBUILD and a
> new PKGBUILD for python-intelhex-scripts[4].
>
> What do you think ?
>
> Thanks in advance for your feedback!
>
> [0] https://aur.archlinux.org/packages/python2-intelhex/
> [1] https://github.com/AladW/aurutils
> [2] https://github.com/bialix/intelhex/tree/master/scripts
> [3]
> https://git.bourgeois.eu/aur_python_intelhex.git/tree/PKGBUILD?id=e6187787c3743e63c5830f78dd18d58f5bc40f79
> [4]
> https://git.bourgeois.eu/aur_python_intelhex_scripts.git/tree/PKGBUILD?id=b346e34509a53cd0ed094f686f635d7e3873a372
>

Re: [aur-general] PKGBUILD for GnuSocialShell

[Justin Dray]

Still no attachment

Re: [aur-general] PKGBUILDs for monkeysphere feedback

[Justin Dray]

For creating users, there is now sysusers.d which makes system user
creation a bit more standardised, take a look here:
https://www.freedesktop.org/software/systemd/man/sysusers.d.html

Regards,
Justin

Re: [aur-general] PKGBUILD review request: understand-bin

[Justin Dray]

You can specify a general source array as well as architecture specific
ones, it adds them together. So you should put desktop and the /usr/bin
binary file in there instead of repeating it.

Otherwise it looks good to me now.

Regards,
Justin

Re: [aur-general] My first PKGBUILD

[Justin Dray]

You'll need to post a link, attachments are stripped from the mailing list.

Regards,
Justin

Re: [aur-general] afraiddns-git PKGBUILD: review and criticism welcome

[Justin Dray]

You can add an empty file in the package for the key, and set it in the
backup array, that way it won't overwrite existing files and will work
without doing it via a shell script and not tracking the file in pacman.

Your pkgver function should probably be below the list of static variables
at the top, not in the middle of them.

The license should be 'custom' unless it's a more standard one. See [1] for
more info on that.

If you don't use a build function, just don't include it. No point making a
no-op one in there.

Otherwise it looks good to me

[1] https://wiki.archlinux.org/index.php/PKGBUILD#license

Regards,
Justin

Re: [aur-general] Can someone get from old version of AUR4 repo a package removed?

[Justin Dray]

Just use git to clone it. Packages don't get removed from the repo, just
hidden from the web interface.

Re: [aur-general] pkgbuild - suggestion

[Justin Dray]

Sometimes there may be a new version out, but the maintainer needs to test
and make sure it's working as expected. It may need a patch to work
correctly, or it may have a major flaw and every other distro is also
avoiding updating to the latest version. The flagging system, I feel at
least, is more so there for users to nudge a maintainer if they haven't
updated it. Often people can wait a few days after the upstream release for
the new version, and if they can't, they should be using the -git version
anyway.

Re: [aur-general] Continuous integration of AUR packages

[Justin Dray]

I was using the chroot tools for a year and a half or so before that, but
had some issues occasionally with things like updating it, or using package
caches inside the chroot, or other various things. I do still have the
shell script I used at the time, it was called by jenkins and cloned a
chroot based off a clean copy and numbered by the jenkins executor to
support multiple builds at once. But I managed a few tens of  thousands of
docker containers for work, and figured I could use a similar build system
for the arch packages, and it's been reliable for me since then.

As Doug said, you need to add the packages you build to a repository for
the next build to be able to install them, but that part is pretty simple
and explained on the arch wiki already.

So, in Jenkins I use the build generator plugin, and created a
parameterized job (config.xml here: http://hastebin.com/oyuqiwokem.xml)
that basically just calls `dmakepkg` on the git checkout for the aur
package; you just give the build an aur package name and it will generate
the job to track that package and any changes pushed to the AUR and build
it. (it polls git once an hour).

`dmakepkg` is in the AUR ( https://aur.archlinux.org/packages/dmakepkg-git/
) and is what I ended up making to build the packages inside a docker
container. It supports the same flags as makepkg (just passes them through)
but defaults to '--force --syncdeps --noconfirm' unless other flags are
specified (no point removing packages since the container is destroyed
after use). Uses a slightly modified version of the official docker arch
image, and is updated much more often (monthly at least instead of the 3-6
months they take). It auto-detects makepkg configs like SRCDEST/etc and
copies it in to the instance and bind mounts the folders specified, as well
as the pacman package cache, so all the builds follow the makepkg config on
the host, but using everything else from a clean environment. If you make
your own repo and add it to your host, you can use `-x` flag to use the
host's pacman.conf inside the container.

Re: [aur-general] Continuous integration of AUR packages

[Justin Dray]

I actually have a Jenkins setup for my packages that does almost exactly
that, I have a job generator build that I give an AUR package name to and
that's all the config for new packages, and it builds them in a docker
container.

You can obviously set up dependencies between the jobs to build in order,
but that part isn't automatic yet. Its been pretty reliable for me over the
past year or so since I last really changed anything.

If you're interested, let me know and I can share the scripts and stuff.
Just on my phone at the moment or I would link them here.

Cheers,
Justin

On Thu, Feb 18, 2016, 9:51 PM Baptiste Jonglez 
wrote:

> Hi,
>
> I would like to run some kind of continuous integration of my AUR
> packages.  The goal is to know when a package I maintain fails to build
> because either:
>
> 1/ its dependencies have been updated (new API, new incompatible version
>of GCC, ...)
>
> 2/ for -git packages, changes made upstream broke something (new
>dependency needed, new build system...)
>
> The scripts in devtools [1] look like they should work just fine to
> automate these kind of builds.  After all, they are used to build the
> official Archlinux packages.
>
> However, I found that the build scripts do not really handle dependencies.
> When building a given package, they just install deps and makedeps from
> the existing Archlinux repositories.  This is an issue when AUR packages
> depend on each other, because then dependencies cannot be installed from
> the Archlinux repositories...
>
> It *is* possible to manually pass packages to install in the chroot before
> building, but this is far from convenient.  For instance, ring-daemon
> depends on opendht, so I would need to do this:
>
> cd opendht
> extra-x86_64-build
> cd ../ring-daemon
> extra-x86_64-build -- -I ../opendht/opendht-0.5.1-1-x86_64.pkg.tar.xz
>
> When there are multiple dependencies, it quickly becomes a nightmare to
> automate (especially because dependencies need to be passed in the right
> order).
>
> Is there any script that automates dependency handling when building?
> Basically, it would probably need to perform a topological sort, build
> packages in this order, and push them to a local repository to be able to
> build later packages.
> Or did I take the wrong approach entirely?
>
> Thanks,
> Baptiste
>
> [1] https://projects.archlinux.org/devtools.git/
>
> PS : Some existing efforts I found about CI with Arch:
>
> -
> https://lists.archlinux.org/pipermail/arch-dev-public/2014-November/026757.html
>   https://jenkins.arch-ci.org/
>   No script provided, site appears to be down
>
> - http://openbuildservice.org/2012/09/10/arch-linux-support/
>   Source code is unreadable (enormous Perl scripts, no modularity)
>
>

Re: [aur-general] PKGBUILD review

[Justin Dray]

You've still got references to OS X and windows installs

Also instead of

if test _arch == '32'; then
scons -j $cores platform=server target=release_debug tools=no bits=32
else
scons -j $cores platform=server target=release_debug tools=no bits=64
fi

you can just do

scons -j $cores platform=server target=release_debug tools=no bits=$_arch

You're setting _arch in 3 places even though it can only have 2 values;
it's also in an array for no apparent reason, you can shorten it to
_arch=32
[[ $CARCH == x86_64 ]] && _arch=64

Or some such variation.

The same goes in the install, you have a bunch of 'if _arch == 32' and then
using 32 twice in a string; just substitute that with the variable.

Regards,
Justin

Re: [aur-general] [aur-dev] [PRQ#4382] Deletion Request for b43-firmware

[Justin Dray]

I didn't want to reply all, but good job :)

- Justin

Re: [aur-general] [aur-dev] [PRQ#4382] Deletion Request for b43-firmware

[Justin Dray]

Can we just make a poll or something and post it on the feature request for
this? There is a lot of noise and talk and generally shitty behaviour all
around; I (and I assume many others) are signed up to the mailing list for
AUR related news; not petty arguments over english semantics.

- Justin

Re: [aur-general] [aur-dev] [PRQ#4382] Deletion Request for b43-firmware

[Justin Dray]

I can understand someone getting confused when they first click on it; and
any of the suggested name changes sound pretty logical. But, how does
someone click on that, then select deletion or merge to some other request
type, enter text and then click submit without realizing 'This probably
wasn't a download link'

- Justin

Re: [aur-general] Out-of-date notifications

[Justin Dray]

FYI, you can use things like IFTTT and Zapier; github allows you to get
atom RSS feeds for things like tags and commits. I have a check that sends
me an email when a new tag is pushed to a project I package on the AUR.
It's super helpful.

- Justin

Re: [aur-general] namcap - games group & non-standard directory

[Justin Dray]

On Tue, 22 Sep 2015 at 21:16 respiranto <respira...@icloud.com> wrote:

> Hi,
> I have just finished packaging freesweep, a minesweeper-game, after
> having had many problems to do so.
>
> Anyways, the current problem is, that namcap complains about:
> /var/games/freesweep/{,sweeptimes} being owned by root:games (E) and
> /var/games/{,freesweep/{,sweeptimes}} existing in a non-standard
> directory (W)
>
> The point is, that freesweep needs a file, that any user can write to.
> The way this would be done by `make install' is exactly how I did it in
> the PKGBUILD - make the file (sweeptimes) and its directory owned by
> root:games and give the games group write permissions.
>
> Some days ago, Justin Dray proposed to do exactly this to solve a more
> or less identical problem [1], however I would like to avoid pushing a
> PKGBUILD whose package does not pass namcap.
> So is there any better way to achieve what I want to?
>
> Furthermore I don't know, how strict the policy to only use standard
> directories, as listed here [2], is.
> And why does the /var/games directory exist if a package may not use it?
> May it only be populated by installed programs?
>
> [1]
>
> https://lists.archlinux.org/pipermail/aur-general/2015-September/031535.html
> [2]
> https://wiki.archlinux.org/index.php/Arch_packaging_standards#Directories


/var/lib/freesweep would probably be the right path and why it is
complaining. (see man file-hierarchy for more info, which does not list
/var/games at all). I'm not sure why it would complain though, since
/var/games is created by the filesystem package, and as you said, that
sounds like an endorsement for it's existence to me.

Ownership I'm not sure on, but someone else on this list should be able to
advise.

Cheers,
Justin

Re: [aur-general] How to grant all users permission to write to a subdirectory of /opt?

[Justin Dray]

On Sat, 19 Sep 2015 at 04:05 Storm Dragon  wrote:

> Howdy,
> I'm working on a package. The package will need to download sounds to a
> subdirectory of itself. I have placed the package in /opt.
> The package is /opt/tintin-alteraeon. It downloads the msp sounds from the
> Alter Aeon mud as it encounters them. But my current setup gives me, for
> example:
> sounds/spell//tensor.opus: Permission denied
> So, how can I give normal users permission to write to the sounds
> directory? Also, is that a bad thing to do? If so, I'll have to come up
> with a different way to handle sounds.
> --
> Powered by Arch Linux! I am registered Linux user number 508465:
> https://linuxcounter.net/user/508465.html
> My blog, Thoughts of a Dragon: http://www.stormdragon.tk/
> get my public PGP key: gpg --keyserver wwwkeys.pgp.net --recv-key 43DDC193
> Twitter and Facebook are so ... yesteryear. Get your 2MB Social account
> TODAY! http://2mb.social/main/register
> The great thing about Object Oriented code is that it can make small,
> simple problems look like large, complex ones.
> "As the moon is rising, give us the sign. Now let us rise up in awe, rock
> 'n' roll angels bring thy hard rock hallelujah, demons and angels all in
> one have arrived."
> Lordi - Hard Rock Hallelujah
>

Ideally you would either download the files beforehand, or per-user. But if
you want a shared folder, create a group for your application, and put in
the post_install a message to add users who want to use the application to
that group. There is a built in games group that you could probably just
use for this? If you set the directory to g+s it will inherit group
ownership when a user creates a new file; but you need ACLs to inherit
actual group write permissions, and 99% of systems will have a umask of
022; so no group writes.

- Justin

Re: [aur-general] Registering, misspelling email, losing account

[Justin Dray]

On Tue, 25 Aug 2015 at 01:42 Bruno Pagani bruno.pag...@ens-lyon.org wrote:

 Le 26/07/2015 22:29, Daniel Micay a écrit :
  On 26/07/15 04:01 PM, Igor Morozov wrote:
  That's right, I messed up. Instead of typing fastmail.com, I typed
  fastmai.com. And now there is no way I can access my account. The only
  option is to send an email to this mailing list describing my problem
  and hope that somebody will help me out. Basically, that's what I'm
  doing right now.
  Okay, so it can ask the user to provide the same email in two fields.
 
  It could treat an unconfirmed account as a temporary placeholder and
  replace it if registration is done again for the same username.
 
  It shouldn't be possible to log in without confirming the email unless
  all of the actions (voting, submitting packages, commenting, etc.)
  beyond editing account information are gated on whether the account is
  registered.
 
  People tend to make mistakes. I'm not the only one who messed up during
  registration. And there is no easy way to get our account back. Mailing
  list is not the best option for account recovery. What if the misspelled
  email exists and the owner decides to proceed and register? What if the
  owner decides to do nasty things using my username, full name and email
  that looks alike? That would affect my reputation in the community since
  it's difficult to prove that I was not the bad guy.
  The usual account activation prevents this stuff. A lot of web sites
  do not automatically log user in after account confirmation, so it kind
  of prevents malicious activity (the bad guy doesn't know the password,
  you see).
  Someone could have just created a fake account before you did, so it's
  really not an issue related to the confirmation design.
 
  And by the way, the fact that you can use an unused (not registered)
  email in account recovery and not get any errors is frustrating. Took me
  8 hours to realize that it says okay, even though the email is not in
  use. Please, do something about it!
  Emails aren't received instantly, so there's no error to report during
  registration.
 

 Sorry to respond so late, but I had a little idea (but maybe it’s not a
 good one) to enhance things here.

 OP was concerned about the owner of the false adress being capable to do
 nasty things. Since it seems we ask for PGP key, would it be possible
 for the server to encrypt the account confirmation mail ? And check that
 (one of) the email(s) on the key correspond to the one provided during
 registration (to help once again avoiding typos, but see also below)?

 Thus, even if the malicious bad guy registers a false account using your
 nickname and your full name, they are two possibilities:

 – he registers with an email he owns, using a false GPG key. You may
 then prove this and show it wasn’t you (which was the concern).
 – he registers with your key, but then the email verification step
 blocks him.

 Any thoughts?


Why don't we do what every other site does and have a confirm email field?
Or a way to change passwords over ssh, since putting in a public key is a
field on registration as well?

- Justin

Re: [aur-general] AUR activity log?

[Justin Dray]

On Thu, 13 Aug 2015 at 04:20 Doug Newgard scim...@archlinux.info wrote:

 On Wed, 12 Aug 2015 15:07:57 -0300
 Giancarlo Razzolini grazzol...@gmail.com wrote:

  Em 12-08-2015 15:01, Doug Newgard escreveu:
   On the contrary, this is exactly the mechanism for that. You disown a
 package
   so that someone else can adopt it. Why else would you disown a package?
 
  Let me rephrase it. Disowning a package isn't the mechanism for allowing
  others to maintain a package, if you still need/use/care for it.
  Co-maintainer functionality is for that. There were people on the old
  AUR that would disown a package so that someone else could update it,
  and then disown it again, and so on. This should end.

 You aren't getting it. If you don't want to maintain a package and want to
 make
 it available to others, you disown it. This doesn't mean you want it
 deleted,
 it simply means you want someone else to maintain it. If someone
 approaches you
 and want to help, you make them a co-maintainer. Two completely different
 things.

 
   Sure they can, why wouldn't they be?
 
  If someone adopt it. When they are in orphaned status, they can't. But,
  then again, if someone adopt it, then it wouldn't be deleted, and we
  wouldn't be having this discussion.

 Anyone can push to the repo of an orphaned package. That person then
 automatically becomes the maintainer, but will often simply disown it
 again.

 Doug


There's definitely some discrepancies in how we're all thinking about how
it should work (for the record I'm totally aligned with Doug in this
regard), but I have to say:

 The metric here should be based on relevance (actual PKGBUILD
 downloads) and time since it become orphan.

Sounds perfect. But we currently don't have a way (or not that I'm aware of
anyway) to do this without opening each package manually. Having even a
weekly/monthly script run through that data and present a list of
old/possible unused orphans would be pretty helpful.

- Justin

Re: [aur-general] Deletion of orphaned packages on AUR4

[Justin Dray]

On Thu, 13 Aug 2015 14:01 Sam S. sml...@gmail.com wrote:

  Note that we do keep the Git repositories of deleted packages,
  so if anybody wants to maintain the package later, he can always clone
  the repository of the deleted package, fix the package and simply push
  it afterwards

 Can you give some details on that?

 For example the libtiff4 package (which one of my packages depends on)
 was deleted, but when I do

 git clone ssh://a...@aur.archlinux.org/libtiff4.git

 all I get is an empty repository.

I cloned one I had deleted and it was still there, I made a comment change,
committed and repushed, it lost the comments and votes but the package was
there. I'm not sure why yours might have failed.

- Justin

Re: [aur-general] AUR activity log?

[Justin Dray]

On Thu, 13 Aug 2015 at 03:17 Giancarlo Razzolini grazzol...@gmail.com
wrote:

 Em 12-08-2015 14:10, Jens Adam escreveu:
  That wasn't what happened. Read the thread(s) again - a single TU went
  around and deleted a bunch of freshly orphaned packages, nothing to do
  with the migration.

 I really don't see the issue here, even if is this that happened. They
 were orphaned, weren't they? And, they aren't deleted, they are
 hidden. Unless the TU also removed the git repository, which I believe
 didn't happened. Truth is, the disown functionality has been misused and
 you can't really complain if you orphaned a package and it was deleted.
 Even more now that AUR has a co-maintainer functionality.

 Cheers,
 Giancarlo Razzolini


But by 'hidden' it also deletes all comments and votes, and stops people
being able to search for the package, see that it isn't maintained and
picking it up. Almost all of my packages have become mine by trying to
install something, finding it useful, and when it became an orphan, just
taking it over and fixing it up.

If we wanted to delete packages we would have asked for deletion, not
orphaned it. What is the point of orphaning packages if they are just going
to get deleted anyway?

- Justin

Re: [aur-general] AUR activity log?

[Justin Dray]

On Thu, 13 Aug 2015 03:36 Giancarlo Razzolini grazzol...@gmail.com wrote:

Em 12-08-2015 14:21, Justin Dray escreveu:
 But by 'hidden' it also deletes all comments and votes, and stops
 people being able to search for the package, see that it isn't
 maintained and picking it up.

Well, the TU could have waited, I give you that.

 Almost all of my packages have become mine by trying to install
 something, finding it useful, and when it became an orphan, just
 taking it over and fixing it up.

This is how I ended up maintaining quite a few packages. But I didn't
waited for them to become orphan, in most cases.


 If we wanted to delete packages we would have asked for deletion, not
 orphaned it. What is the point of orphaning packages if they are just
 going to get deleted anyway?

Now this is were I fail to see the point. If you still wanted/needed the
package, why orphan it? I'm perfectly happy with the way AUR works
today. But, if you guys really want orphaned packages to stay around for
some time, I suggest you guys implement it and send a diff. Perhaps
something that prevents even a TU from deleting (hiding) a orphaned
package that isn't orphan long enough, lets say, a couple of months.

Cheers,
Giancarlo Razzolini


Perhaps seeing active comments or that the packages had to have been
updated within month since everything was cleared for AUR4?

We already have a mechanism for disowning a package and allowing others to
maintain it without deleting it. It's called orphaning. The problem here is
that how they are treated has apparently changed with no community
involvement or even a warning that orphan packages will be deleted at
random.

Perhaps if TUs are able to view the last updated time from a search fable,
they could see an orphaned package with no updates for X months. But as has
been said  before, orphaned does not mean useless or broken.

- Justin

Re: [aur-general] Deletion of orphaned packages on AUR4

[Justin Dray]

On Tue, 11 Aug 2015 17:09 Antonio Rojas aro...@archlinux.org wrote:

 Rob McCathie korr...@gmail.com
  Wrote in message:

 
 
  Just a query: Why were packages i added to AUR4, ensured were in good
  working order (and made an enhancement to one of the packages compared
  to the last release on AUR3), know are used by at least some users,
  and then orphaned so some other interested party can take over
  maintenance, were deleted from AUR4?
 
  compiz-gtk-standalone was actually the ONLY package on AUR4 that
  provided the Compiz 0.8 series core component.
  Since it's deletion there is now at least one package on AUR4 that has
  unresolvable dependencies.
  (eg. https://aur.archlinux.org/packages/ccsm/ )
 
  Regards,
  Rob McCathie
 
 

 I was wondering the same thing... Many of the kde-applications git
  packages that I uploaded to AUR4 and then disowned ( but were
  working fine) have been deleted, and I can't find any related
  request.
 --

I also disowned an LSI raid card utility a few days ago, and it got deleted
within 2 hours. What's going on with this?

- Justin

Re: [aur-general] Deletion of orphaned packages on AUR4

[Justin Dray]

On Wed, 12 Aug 2015 at 15:37 Rob McCathie korr...@gmail.com wrote:

 On 12/08/15 13:49, Doug Newgard wrote:
  In my case, I have some that I'm actively trying to get maintainers
  for; in the mean time, I'm looking after them even though they are
  listed as being orphaned. Is this not to be allowed now? Should all
  orphan packages in the official repos be deleted, just assume nobody
  is looking after them? I updated one package just a few days before it
  was randomly deleted. There's other stories further up in this thread
  about them being deleted after only a few hours, all with no notice.
  If a time limit is to be implemented, it needs to be limit long enough
  that the package is both unlikely to be being used and unlikely to
  work anymore. A month or two wouldn't cut it. A notice should also be
  sent out to anyone set to get notifications for that package with
  enough lead time for someone to pick it up. Doug

 Same here. I was still monitoring the couple of packages i'd orphaned, i
 was hoping someone would take over maintenance. For a time at least, i'd
 have addressed any issues with them.

 Anyways, i've re-added the packages and will stay maintainer of them
 until things settle down a bit.

 --
 Regards,

 Rob McCathie


I've had to do the same thing. The problem is, if it isn't orphaned, and
you try to update it when you get a chance it is hard to find a new
maintainer. I've never seen someone ask for maintainership of a maintained
and up-to-date package before. From the reports I'm seeing as well it's a
single TU deleting them all.

- Justin

Re: [aur-general] Deletion of orphaned packages on AUR4

[Justin Dray]

On Wed, 12 Aug 2015 07:24 David Phillips dbphillip...@gmail.com wrote:

 I suppose some may subscribe to the view that if someone wants it
 badly enough, they'll submit, maintain and stick with it.

In my case, I uploaded a perfectly working package for LSI raid
controllers, but someone commented that a newer version was available, I no
longer use any LSI controllers and can't test that it is working correctly
with the new version, I said as such, and orphaned the package only for it
to be deleted within a couple hours.

If orphaned packages are going to be deleted straight away I would have
hung on to it. But then what is the point of their being an orphan button?
There's already a delete one. It's seems really poor form to be just
deleting any random orphaned packages off the AUR. Perhaps TUs that are
doing this should no longer be TUs since they are clearly abusing that
privilege to do things however they want instead of within the guidelines
set by the community.

- Justin

Re: [aur-general] Can't upload packages to aur now

[Justin Dray]

On Sun, 9 Aug 2015 08:33 Pablo Lezaeta Reyes prfl...@gmail.com wrote:

2015-08-08 19:14 GMT-03:00 Simon Hanna simon.ha...@serve-me.info:

 On Sat, Aug 08, 2015 at 06:59:48PM -0300, Pablo Lezaeta Reyes wrote:
  I have 51 packages with the user Jristz but I decide change the
 .git/config
  and change sed s|aur4.|aur.|g but now I can't upload packages and
 fixes.
 
  I attempt changing my ssh-key and I test everyone
  (ecdsa,ed25519,rsa1,dsa,rsa) but without succes, then I attempt to
 reclone
  a package for test but aur refuse to allow me to do it.
 
  so far my .ssh/config is
  Host aur.archlinux.org aur4.archlinux.org
  Hostname aur.archlinux.org
  IdentityFile ~/.ssh/id_rsa.pub
  User aur
  Port 22
  and I have aur.archlinux.org in the know hosts list, so What could
 happened
  that I cant even clone my packages??
  --
  *Pablo Lezaeta*
 AFAIK IdentityFile should be the private key not the public key.
 Regardless, it's hard to help when you don't provide exact commands and
 their output.
 give us the clone command you use and the output you get.
 You can try ssh aur.archlinux.org help just to check if you can reach
 aur.
 next stop would be the urls you use for cloning/pulling/pushing


the aur article, the last time I check not have info about the config file,
so is need add.
but you are right the .pub was the problem.

thanks and I hope this will be not repeat; but the lack of info about the
propper config of the config file could has prevented this because I first
check wiki/AUR
--
*Pablo Lezaeta*


But that's in the man page for ssh config, its not really an AUR issue, I
feel it would be out of place to explain ssh config on the AUR wiki page.

- Justin

[aur-general] Update notifications

[Justin Dray]

Hi,

I was thinking it could be useful to show in comments when a new version is
pushed by the maintainer of a package; just a line break and maybe v1 - v2
or the git commit message or something. It would be easier to make sense of
comments on many of the packages I've seen and allow us to see if comments
pertain to the current version or not without losing comment history.

Cheers,
Justin

Re: [aur-general] Update notifications

[Justin Dray]

 Why not just check the last updated date?

-- Eli Schwartz


Because that would only work for the current version, and back one, this
way you could see the relevant change happening after an issue is reported
and such. It seems like a much easier way to view the differences to me at
least.

- Justin

[aur-general] Git over HTTPS

[Justin Dray]

If your network admins don't know the difference between incoming and
outgoing ports, or not opening things like ssh ports to the internet that
really isn't an Arch problem...

- Justin


-- 
Regards,
Justin Dray
E: jus...@dray.be
M: 0433348284

Re: [aur-general] AUR4 feature request

[Justin Dray]

I

t's neither provided by the old, nor by the new AUR. I never

downloaded the PKGBUILD, since I build with yaourt.



The old git  mirror for AUR 3 never removed old packages, so you can still
retrieve it from there. But it would be good to maintain access to old
packages on the new AUR as well.

- Justin

Re: [aur-general] [AUR4] Is there a tool for using a single git repo for several packages?

[Justin Dray]

How will that work for new packages you take maintainership of? I'm not a
git wizard, but taking a look at the stuff I can't see any way it merges in
an external git repo in to yours when you take over an existing orphaned
package. I tried the submodule thing as well and found it horrible
inadequate. I was going to just query the AUR to find my package list and
clone down/update all the returned repositories, and just keep the scripts
in a repo by itself.

- Justin Dray

Re: [aur-general] [AUR4] Is there a tool for using a single git repo for several packages?

[Justin Dray]

Ah, sounds good! Thanks for that.

 - Justin

Re: [aur-general] Ho to update .SRCINFO without creating a tarball?

[Justin Dray]

 Generating such a file manually is error-prone, using mksrcinfo ensures
 that the file is exactly what AURweb needs.

I believe that is what he is saying should be in the wiki. And since there
are so many questions around it this past week on the mailing list, it
might be a good idea to have it on record for new maintainers when they go
to submit their first packages as well.

- Justin

[aur-general] Duplicate packages

[Justin Dray]

Hi,

I was just wondering what the process is when someone finds duplicate
pacakges? Assuming I'm not the owner of either package, but someone has
uploaded foo and foobar and both provide the same thing, what would be the
best we to get that resolved? It's quite annoying to have to read 2+
pkgbuilds to see which one is actually decent when all I want to be able to
do is install the package.

Regards,
Justin

Re: [aur-general] Duplicate packages

[Justin Dray]

Thanks for that.

Re: [aur-general] Cannot push to aur-dev, was: Re: [aur-dev] AUR 4.0.0 pre-alpha

[Justin Dray]

If you just cloned a repo; master will have upstream set to origin/master.
You should only have to set upstream when you create a new local branch.
and if you do, you can use 'git push -u origin branch-name' to set it and
push in one go.

Regards,
Justin Dray
E: jus...@dray.be
M: 0433348284

Re: [aur-general] AUR 4.0.0 pre-alpha

[Justin Dray]

On Tue, Dec 30, 2014 at 11:19 AM, Pablo Lezaeta Reyes prfl...@gmail.com
wrote:

 but what if the file not contain any extention? or if a different file is
 need (like a .svg or a .sh or a .webm? We will ended adding all the
 posibilities for images? or there will be an alternat8but is need to
 installive if a user need update a package with anything that is not in the
 whitelist withut ended renaming it at makepkg time.
 Maybe if a user need add a exeption they can contact the mailist for ask
 about an exception to they blacklist in they git-sub-tree-whatever.

 2014-12-29 22:14 GMT-03:00 SpinFlo sl1pk...@gmail.com:

  2014-12-30 0:57 GMT+01:00 SpinFlo sl1pk...@gmail.com:
 
   2014-12-30 0:52 GMT+01:00 SpinFlo sl1pk...@gmail.com:
  
   or exist a method to use white list (only files/directory allowed)
   instead of blacklist (list of exclude dirs/files)
  
   greetings
  
  
   oh, i fount it:
  
 
 http://stackoverflow.com/questions/15288712/gitignore-whitelist-on-directory-and-its-contents
  
   greetings
  
 
 
  ok i tried test with a .gitignore (do'h, 'git add *' don't work again.
 but
  use 'git add .gitignore' works :/) with this content:
 
 
  *
  !.gitignore
  !.SRCINFO
  !PKGBUILD
  !somefile.desktop
  !somefile.patch
  !someimage.png
  !sometextfile.ext
 
 
  then added the package sources and dozens of files. 'git add *' says that
  files are ignored, included the src/pkg dirs(and contents)
 
  i'm sure this is a best chice to avoid the duplicate local repos (one to
  work, and other to clean push)
 
  greetings
 



 --
 *Pablo Lezaeta*


You can still force add them with 'git add -f foo.bar' But most smart shell
auto completions won't work with it either which is a bit annoying. I use a
blacklist, and it works for all of my packages, but I don't have anything
pulling things like .deb sources or a million other possibilities; I think
using a whitelist instead of a blacklist may be the way to go.

Regards,
Justin Dray
E: jus...@dray.be
M: 0433348284

Re: [aur-general] Delete ipycli-git

[Justin Dray]

On Mon, Dec 29, 2014 at 12:26 PM, Ralf Mardorf info.mard...@rocketmail.com
wrote:

 On Mon, 29 Dec 2014 13:37:20 +1300, David Phillips wrote:
  From https://aur.archlinux.org/ :
 
   Package orphan requests, merge requests, and deletion requests
   should be filed in the Package Actions box.
 
 
  This point has also been brought up at least twice a week for the last
  six months on this list.

 The last two mails sent before the OP's mail, are exactly about this
 issue too. They came through the list 12 hours, before the OP's mail was
 sent.


Whatever happened to the idea of sending a once off email to everyone who
has a valid email on the AUR?
These constant emails are getting to be quite annoying, but I don't want to
unsubscribe from the mailing lists to get rid of them.

Regards,
Justin Dray
E: jus...@dray.be
M: 0433348284

Re: [aur-general] Email Notifications of new AUR orphaning/deletion/merging method

[Justin Dray]

I would very much like to get one more email, instead of 2-5 a week.

Regards,
Justin Dray
E: jus...@dray.be
M: 0433348284

On Sun, Dec 7, 2014 at 5:57 PM, Ralf Mardorf info.mard...@rocketmail.com
wrote:

 On Sat, 6 Dec 2014 17:44:03 -0500, Brent Saner wrote:
  On Dec 6, 2014 5:36 PM, Ralf Mardorf wrote:
   On Sun, 7 Dec 2014 11:25:59 +1300, David Phillips wrote:
What do you all think?
   I guess your idea is very good
  +1

 Perhaps it's better to repeat sending this information at the
 end or beginning of each month for the next quarter.

Re: [aur-general] Unsupported architectures in the AUR

[Justin Dray]

Good question. One of my packages got deleted last year because it was arm
only. I no longer used any arm systems, and was just maintaining it, so I
didn't bother chasing it up. But I'm also interested in the answer to that.

Regards,
Justin Dray
E: jus...@dray.be
M: 0433348284

Re: [aur-general] AUR Best Practice for New Package Upload

[Justin Dray]

That sounds like the most reasonable way to build it. I would also like to
suggest that Florian should read the man page for file-hierarchy as it is
quite helpful if you are unsure of where files should be going.

Regards,
Justin Dray
E: jus...@dray.be
M: 0433348284

Re: [aur-general] Requests

[Justin Dray]

Perhaps just the package name without a link? To be honest, the package
name alone would satisfy me.

Regards,
Justin Dray
E: jus...@dray.be
M: 0433348284

[aur-general] Requests

[Justin Dray]

Hi everyone,

I think it would be a good idea to link to the package for a request when
it has been fulfilled. The messages do not show up in the same thread and
there is no link, just 'request #1234 accepted' and which TU has accepted
it. I then have to go and search for that number to find out what the
request was for. Thoughts?

Regards,
Justin Dray
E: jus...@dray.be
M: 0433348284

Re: [aur-general] Java name guideliness

[Justin Dray]

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. There should only be duplicates of the same package for as long as
it takes for a merge request to be processed. This is clearly not the case,
and I think one of the more annoying points that has been brought up in
this thread. In fact it probably never would have come up on this mailing
list if there weren't 2 subtly divergent jdk/jre packages in the aur
simultaneously.

Regards,
Justin Dray
E: jus...@dray.be
M: 0433348284

On Fri, Sep 12, 2014 at 4:02 AM, Pablo Lezaeta Reyes prfl...@gmail.com
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:
 vendor-jre/jdk-version: oracle/openjdk-jre-7/8

 2014-09-11 13:41 GMT-03:00 Det nimetonma...@gmail.com:

  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
   providerjre/jdk-version: 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: project nameversion-vendor (e.g. jdk8-openjdk,
  jre7-openjdk)
 
  archlinux-java name: java-version-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: project name(version) (e.g. jdk, jre7)
 
  archlinux-java name: java-version-project name(/jre) (e.g.
  java-8-jdk, java-7-jre/jre) (just java-7-jre unsupported by
  archlinux-java)
 
 
  Det
 



 --
 *Pablo Lezaeta*

Re: [aur-general] Java name guideliness

[Justin Dray]

Agreed, someone complained on one of my java packages that it was using the
incorrect path for oracle java from the aur, and upon inspection I noticed
these multiple packages providing the same thing, none of which work as
they should be. I assumed they would have fixed it since that was only a
short time after the new java common stuff, but it appears that they may
need some assistance with that task.

Regards,
Justin Dray
E: jus...@dray.be
M: 0433348284

On Wed, Sep 10, 2014 at 8:18 AM, Pablo Lezaeta Reyes prfl...@gmail.com
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?

 [1] https://aur.archlinux.org/packages/jdk/
 [2] https://aur.archlinux.org/packages/jdk7/
 [3] https://aur.archlinux.org/packages/jdk7-oracle/
 There is also a jdk5-compat.
 Also mergins as ben posponed until name convention come.

 --
 *Pablo Lezaeta*

Re: [aur-general] Java name guideliness

[Justin Dray]

Part of the issue here however is that now there are both jre7 and
jre7-oracle and so on duplicate packages in the AUR. If someone says 'oh, i
need oracle jdk, I can search on the AUR for that.' Well now they have to
go and read all of the comments and look around on the wiki/mailing
lists/forums to figure out which one they actually want. And it's not even
a dispute between different maintainers, 'joschi' is the maintainer for
both packages and are seemingly totally different; different groups,
different upstream urls, different dependencies, different
provides/conflicts. It also appears that jre8-oracle was merged in to jre
package recently, so there is another discrepancy in the naming there.

I'm not fussed one way or another on the naming, but by having both, I've
really got to agree with Pablo; it's far from KISS.

Regards,
Justin Dray
E: jus...@dray.be
M: 0433348284

On Wed, Sep 10, 2014 at 12:22 PM, Det nimetonma...@gmail.com wrote:

 On Wed, Sep 10, 2014 at 8:18 AM, Pablo Lezaeta Reyes prflr88 at gmail.com
 
 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-major
 version-project name. 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] Package maintenance

[Justin Dray]

Hi,

The issue I've got at the moment is in regards to a poorly packaged package
that is also providing files made by other packages? The one in question
I've also suggested the fixes to the maintainer, and requested it be
orphaned when it was not updated for several months. Within a day the
maintainer bumped the version up but didn't fix any other issues. I'm not
fussed about being the maintainer or not, I just want the packages that I
use to work correctly.

Regards,
Justin Dray
E: jus...@dray.be
M: 0433348284

Re: [aur-general] Package maintenance

[Justin Dray]

Sure, it was the google-cloud-sdk. It includes all of the appengine SDKs as
well, which are already in google-appengine-* packages, making it several
hundred MB instead of 21MB, and it doesn't link a single binary to
/usr/bin, so you may as well have just untar'd the source in /opt.
https://aur.archlinux.org/packages/google-cloud-sdk/

Regards,
Justin Dray
E: jus...@dray.be
M: 0433348284


On Wed, Aug 6, 2014 at 10:00 PM, Johannes Löthberg johan...@kyriasis.com
wrote:

 Might help if you actually name the package in question.

 --
 Sincerely,
  Johannes Löthberg
  PGP Key ID: 3A9D0BB5

Re: [aur-general] virtualbox-extension-pack vs. virtualbox-ext-oracle

[Justin Dray]

Even if the script is the recommended way, shouldn't the package be
designed so that it will track all of its files? Having a post install
script that places files through your filesystem feels like a dirty hack at
the best of times.

Regards,
Justin Dray
E: jus...@dray.be
M: 0433348284
On 05/08/2014 7:13 am, Laurent Carlier lordhea...@gmail.com wrote:

 Le lundi 4 août 2014, 18:15:32 Christian Hesse a écrit :
  Hello everybody,
 
  following a lengthy discussion sublu just deleted my package
  virtualbox-extension-pack from AUR. This is what his package
  (virtualbox-ext-oracle) does:
 
  * Install an archive file.
  * Use install script to copy a number of files to /usr without pacman
  knowing about it.
 
  I think this is the wrong way, so I created my own package
  (virtualbox-extension-pack) that tries to get it right:
 
  * Just install the files required, ready to use for virtualbox.
  * No crappy install script required!
 
  My package had about 75 votes IIRC, probably there would have been more
 if
  more people knew about the details. The discussing had a number of
 comments
  that agreed about my opinion regarding installing/coping files to /usr
 with
  pacman or the install script.
 
  Although I think it is wrong seblu is free to provide his package via
 AUR.
  But is there any good reason mine is not allowed to reside there?

 I've checked both packages, then i've also checked virtualbox
 documentation.
 Documentation is available at http://www.virtualbox.org/manual/
 * Ch8.36. VBoxManage extpack *
 The extpack command allows you to add or remove VirtualBox extension
 packs, as described in Section 1.5, “Installing VirtualBox and extension
 packs”.
 In regards of VirtualBox docs, Seblu is installing extension pack the
 proper
 way.

 Your package isn't following upstream way to install extension package and
 you
 are not sure it will keep working, you are just lucky.

 Your package is only a duplicated package of seblu's one, only differing
 on the
 way to install extension pack files isn't a good reason enough. Seblu was
 right
 to remove your package, there was an explanation before suppressing, rules
 were followed.

 Nothing more to say.
 --
 Laurent Carlier
 http://www.archlinux.org

Re: [aur-general] Dependancies and Split Packages

[Justin Dray]

On Tue, Jun 24, 2014 at 8:31 AM, Storm Dragon stormdragon2...@gmail.com
wrote:

 Hi,
 I'm back again lol.
 Ok, so when I made p-git depend on the package pypump2-git that I made,
 and when I installed python2-click after modifying the python-click
 PKGBUILD everything works as expected.
 When, however, I make p-git require python2-click and python2-pypump-git
 it fails to build. It installs the package, for example python2-click, then
 at the end, I get something like installing python-click 100%
 Then it fails to install p-git saying dependancies are not met, missing
 python2-click and now also same error with python2-pypump-git.
 So, how can I fix it? I really want to do this stuff the right way, but I
 also want it to work at the end of the day. There's nothing worse than
 finding a nice shiny new package in the AUR and trying to build it only to
 have it fail. Should I switch back to the old way? Or, should I just put
 python setup.py and python2 setup.py in the same package() function? But,
 even if I do put them in the same function, it still won't fix my problems
 with python2-click.
 Thanks for the help
 Storm
 --

 --
 Registered Linux user number 508465: https://linuxcounter.net/user/
 508465.html
 My blog, Thoughts of a Dragon: http://www.stormdragon.us/
 get my public PGP key: gpg --keyserver wwwkeys.pgp.net --recv-key 43DDC193
 How many Internet mail list subscribers does it take to change a
 lightbulb? http://goo.gl/eO4PJ
 One more time we stare into the blackened sky, for tonight, in our hearts
 now we feel. One last time see our destiny reveal.
 DragonForce - The Last Journey Home


Definitely don't put both in the same pacakge. Make seperate python 2/3
packages, otherwise if someone only has python3 installed, they will be
pulling in python2 dependencies as well when they don't need it.

Regards,
Justin Dray
E: jus...@dray.be
M: 0433348284

Re: [aur-general] Merges

[Justin Dray]

No, but the original email asking about cleaning them up was 10 days ago.
Which the other maintainers responded to. I also said this in my original
email to the AUR mailing list:  (this was only around 10 days ago however.
I'm not sure if that means this will still need to wait the full 14 days to
be able to merge these or not though). I thought leaving it up to a TU to
decide would be enough? If you want the packages you can have ownership of
them, I just found it frustrating to have to read 7 pkgbuilds to figure out
which one actually worked, when it should have been 2 packages.

Regards,
Justin Dray
E: jus...@dray.be
M: 0433348284


On Fri, Jun 13, 2014 at 11:41 PM, Timothy Redaelli tredae...@archlinux.info
 wrote:

 On Thursday 12 June 2014 23:11:18 Justin Dray wrote:
  Hey,
  I've recently cleaned up the big pile of skype4pidgin packages in the
 AUR.
 
  Of the previous maintainers I could contact, they have orphaned the
  packages and I have taken them up prior to deletion/merging or have
 agreed
  to the merge. The maintainer for skype4pidgin-svn-dbus has not responded
 to
  my any attempts to sort out these packages so far (this was only around
 10
  days ago however. I'm not sure if that means this will still need to wait
  the full 14 days to be able to merge these or not though)
 
  Anyway, as a result, can someone please merge the following:
 
  skype4empathy-svn [1] - skype4pidgin-svn [3]
  skype4pidgin-svn-dbus [2] - skype4pidgin-svn [3]
  skype4empathy [4] - skype4pidgin [6]
  skype4finch [5] - skype4pidgin [6]

 I'm the maintainer of skype4pidgin-svn-dbus, you last mail was from 3 days
 ago
 and you wrote: Hi again everyone,

 If there is no response in the next 14 days regarding this stuff, I'll ask
 for
 orphanage on the packages in question so that I can fix it up.

 3 days are NOT 14 days...

 --
 Timothy M. Redaelli
 Arch Linux Trusted User

[aur-general] Merges

[Justin Dray]

Hey,
I've recently cleaned up the big pile of skype4pidgin packages in the AUR.

Of the previous maintainers I could contact, they have orphaned the
packages and I have taken them up prior to deletion/merging or have agreed
to the merge. The maintainer for skype4pidgin-svn-dbus has not responded to
my any attempts to sort out these packages so far (this was only around 10
days ago however. I'm not sure if that means this will still need to wait
the full 14 days to be able to merge these or not though)

Anyway, as a result, can someone please merge the following:

skype4empathy-svn [1] - skype4pidgin-svn [3]
skype4pidgin-svn-dbus [2] - skype4pidgin-svn [3]
skype4empathy [4] - skype4pidgin [6]
skype4finch [5] - skype4pidgin [6]

[1] https://aur.archlinux.org/packages/skype4empathy-svn/
[2] https://aur.archlinux.org/packages/skype4pidgin-svn-dbus/
[3] https://aur.archlinux.org/packages/skype4pidgin-svn/
[4] https://aur.archlinux.org/packages/skype4empathy/
[5] https://aur.archlinux.org/packages/skype4finch/
[6] https://aur.archlinux.org/packages/skype4pidgin/

Regards,
Justin Dray
E: jus...@dray.be
M: 0433348284

[aur-general] Deletion request

[Justin Dray]

Please remove the following pkgbuild:
https://aur.archlinux.org/packages/xf86-input-evtouch/

Upstream is dead, package hasn't been able to be built in *years* and the
maintainer has said as much on the package comments, and someone has also
put this on the archwiki touchscreen page.

Regards,
Justin Dray
E: jus...@dray.be
M: 0433348284

Re: [aur-general] ttf-droid-sans duplicate of community/ttf-droid?

[Justin Dray]

I thought he was being sarcastic, and was implying that we should delete
it, because what is the point of saving a couple MB on removing a small
portion of a font at the expense of more packages to maintain.

Regards,
Justin Dray
E: jus...@dray.be
M: 0433348284


On Thu, May 29, 2014 at 9:43 AM, Pedro Alejandro López-Valencia 
palop...@gmail.com wrote:

 El may 28, 2014 4:47 PM, Bartłomiej Piotrowski b...@bpiotrowski.pl
 escribió:
 
  On Wed, 28 May 2014 16:19:16 -0500
  Pedro Alejandro López-Valencia palop...@gmail.com wrote:
   El may 28, 2014 1:31 PM, Bartłomiej Piotrowski b...@bpiotrowski.pl
   escribió:
   
On Sun, 25 May 2014 12:57:43 +0200
SanskritFritz sanskritfr...@gmail.com wrote:
 On Sat, May 24, 2014 at 9:35 AM, Jerome Leclanche
 adys...@gmail.com wrote:
  I don't really understand the difference between
  community/ttf-droid and any of these:
  https://aur.archlinux.org/packages/?O=0K=ttf-droid
 
  Any idea about duplicates in there?

 ttf-droid-sans
 Comment by graysky 2012-10-16 21:14
 This is only the sans version; the package in [community] contains
 more flavors.
   
I'm a bit unsure if it's worth a standalone package. Unwanted files
can be ignored via NoExtract in pacman.conf…
  
   Not in this case. The packege in community should really be split into
   several different ones that reflect the style and width variants,
   namely normal vs codensed and sans vs serif.
 
  This way we should also split ttf-bitstream-vera, ttf-dejavu,
  ttf-freefont, ttf-liberation and ttf-ubuntu-family. Why limit ourselves
  to only normal, condensed and so on? Let's split bold and monoscape
  variants too, because it can save 15MB of our incredibly small hard
  drives.
 
  I'll wait a week with any further actions to see if fellow TUs
  have different opinion.

 I can do it, if you don't mind having someone give you a hand with the
 task. I'm not a TU, obviusly.

[aur-general] Merge request

[Justin Dray]

Hi,

Can I please get [1] 'sickbeard-tvrage-git' merged in to [2]
'sickrage-git'. Upstream changed names, just following suit.

[1] https://aur.archlinux.org/packages/sickbeard-tvrage-git/
[2] https://aur.archlinux.org/packages/sickrage-git/

Regards,
Justin Dray
E: jus...@dray.be
M: 0433348284

[aur-general] Disown request

[Justin Dray]

Hi,

Can I please get shellcheck disowned? I would like to take over for it, and
have gotten no response from the current maintainer.

https://aur.archlinux.org/packages/shellcheck/

Regards,
Justin Dray
E: jus...@dray.be
M: 0433348284

[aur-general] feed the beast

[Justin Dray]

Hey everyone,

[1] has been out of date for many years and provided the same application
as [2]. Please merge [1] in to [2].

Please merge [3] in to [4] as I have renamed the package to be more
accurate.

[1] https://aur.archlinux.org/packages/ftb-launcher/
[2] https://aur.archlinux.org/packages/feedthebeast/
[3] https://aur.archlinux.org/packages/feedthebeast-server/
[4] https://aur.archlinux.org/packages/ftb-ultimate-server/

Regards,
Justin Dray
E: jus...@dray.be
M: 0433348284

Re: [aur-general] Code review request: new PKGBUILD omodoro

[Justin Dray]

 For the git pkgver functions, you're best off checking the wiki:
https://wiki.archlinux.org/index.php/VCS_PKGBUILD_Guidelines

The first one you posted is the only one listed there. The function you are
using at the moment will return a random version as it's just the
fingerprint of the latest commit; That means it may or may not get seen as
an update when people go to build the next version. You need to make sure
it is something that makes sense and increments as new commits are made.
You should rarely have to deviate from what is on that VCS PKGBUILD
guidelines page.

Regards,
Justin Dray

Re: [aur-general] Promoting use of .AURINFO

[Justin Dray]

On Mon, Jan 13, 2014 at 6:17 AM, Jerome Leclanche adys...@gmail.com wrote:

 On Sun, Jan 12, 2014 at 3:11 PM, Lukas Fleischer
 archli...@cryptocrack.de wrote:
  On Sun, 12 Jan 2014 at 15:51:48, Anton Larionov wrote:
  Hello,
 
  I was under the impression that .AURINFO was introduced to override some
  fields in PKGBUILD when they are written in format which can't be
 properly
  displayed by AUR (or maybe I've missed something). But why do you want
 to
  force it's usage for all packages? In most cases AURINFO will just
  duplicate same fields from PKGBUILD.
 
  The long-term plan is to use it for all AUR packages, improve the format
  and finally make it an official feature of makepkg(8) (the file will
  probably be called .SRCINFO then but we're far from there). See my other
  reply to Sebastien for some reasons on why it should be used.
 

 So the official goal is to have it generated as part of makepkg -S?
 Because I see that as the only way the format will get popular: if
 it's nobody's problem.

 J. Leclanche

 
  Also I have some questions about it's format:
 
  1) If package has different dependencies for 86_64 and 686, what should
 I
 put in depend array?
 
  Good question. This cannot be answered properly, though, since
  dependencies actually are a property of the binary package and not a
  property of the source package. Maybe we should loosen the format for
  dependencies of source packages and allow optdep-like comments?
  Something like:
 
  depends = foo
  depends = bar
  depends = foobar: x86_64 only
 
  Just an idea. Comments welcome.
 
 
  2) Which 'pkgname' will be unique - from PKGBUILD or AURINFO? E.g if I
 upload package with name 'foo' and overriden name 'bar' will someone
 be able to upload new package with name 'foo'? Or 'bar'?
 
  Only the information from .AURINFO will be used. You can already trick
  the AUR into reading a completely different name from the PKGBUILD than
  it actually produces (and that problem is unavoidable), so that isn't a
  (new) issue.
 
 
  --
 
  Regards,
  Anton Larionov


It might also be a good idea to write out what fields are available and
their purpose on the wiki similar to the PKGBUILD page (
https://wiki.archlinux.org/index.php/PKGBUILD) and perhaps link to it from
the AUR user guidelines page? It will be forgotten by most packagers if the
only information about it is a commit message and a mailing list thread.

Regards,
Justin Dray
E: jus...@dray.be
M: 0433348284

[aur-general] linux-bcache-git

[Justin Dray]

Hey everyone,

Can we get linux-bcache-git package removed? All the changes have been
merged upstream several kernel versions ago and even it's maintainer has
said as much in the comments.

https://aur.archlinux.org/packages/linux-bcache-git/

Regards,
Justin Dray
E: jus...@dray.be
M: 0433348284

[aur-general] Removal of repo-update

[Justin Dray]

Hey,

the repo-update package is out of date, hasn't been updated in several
years and upstream source is gone, can we get this one deleted? Thanks.

https://aur.archlinux.org/packages/repo-update/

Regards,
Justin Dray
E: jus...@dray.be
M: 0433348284

Re: [aur-general] 'provides' info in AUR

[Justin Dray]

On Thu, Dec 12, 2013 at 7:11 AM, Dave Reisner d...@falconindy.com wrote:

 On Wed, Dec 11, 2013 at 08:21:44PM +, Jerome Leclanche wrote:
  On Wed, Dec 11, 2013 at 6:42 PM, Dave Reisner d...@falconindy.com wrote:
   On Wed, Dec 11, 2013 at 06:12:59PM +, Jerome Leclanche wrote:
   On Wed, Dec 11, 2013 at 5:52 PM, Sam S. sml...@gmail.com wrote:
On Tue, Dec 10, 2013 at 4:21 PM, Jerome Leclanche 
 adys...@gmail.com wrote:
   
I don't understand why makepkg -S
doesn't include the .PKGINFO file from makepkg (and subsequently
 the
AUR would use that if present instead of the grep system which
 fails
as soon as variables/expansions are involved which is every other
package). All the implementation is there.
   
   
It would probably be better then what we have now, but a perfect
 solution
would also account for PKGBUILDs that use Bash conditionals to set
different variables on i386 systems than on x86_64 systems (which
 is pretty
common among AUR packages that package upstream binaries rather than
compiling from source).
   
Reading values from .PKGINFO would populate the AUR with the values
 for
whichever architecture the package uploader happened to use. (So if
 the
maintainer changes, or the same maintainer works on different
 computers, a
simple re-upload of an AUR package could suddenly change the
 package's
meta-info, i.e. the AUR would become more fragile.)
   
Of course, the perfect solution would be pretty difficult to
 implement.
Gentoo had a GSoC project last year [1], to implement an efficient
 and safe
(side-effect free) limited Bash parser / pseudo-interpreter in C++,
sufficient to extract all necessary values from Genoo's equivalent
 of
PKGBUILDs. Surely, this could have been useful for the AUR as well.
 But I
can find no evidence of continued project activity after the GSoC
 period
ended, so it appears they have given up... :(
   
---
[1] http://dev.gentoo.org/~qiaomuf/libbash.html
  
   I love the fact someone could be working on a bash parser but that
   solution is *insane*.
  
   It's designed to be incomplete, and the project appears very dead.
  
   This is a solved problem: use a metafile compiled by whatever tools
   you use in your distro/domain that can be parsed safely and easily.
   For Arch, those are PKGINFOs.
  
   No, go see historical conversations about a mythical .SRCINFO -- this
 is
   what .AURINFO is based on. .SRCINFO is vaporware right now, and I again
   refer you to unresolved discussions about how it would handle split
   packages and package-specific overrides.
  
   Good point on the differences per arch. I guess the obvious solution
   that comes to mind here is to have makepkg -S generate the source
   files for each arch value (eg. PKGINFO.x86_64, etc) but that's not
   necessarily good and is the subject of another discussion imo.
  
   To be clear, .PKGINFO is not the solution here. This file describes a
   built package (something the AUR explicitly does not support).
  
   d
 
  Care to explain the reasoning? I'm looking at a few example PKGINFOs
  and they contain nothing that can exclusively be generated at
  package() or build() time (other than pkgver but that's already the
  case currently).
 
  J. Leclanche

 Here's a few reasons that come to mind:

 1) As you've already discovered, you'd need a .PKGINFO file for every
 potential architecture, rather than just a .SRCINFO which might describe
 what architectures are known available. A .SRCINFO could express all
 package and architecture specific overrides. The fact that an override
 exists might be a useful bit of information to convey.

 2) .PKGINFO doesn't contain things that are useful for source packages,
 like, say... the source URL? checksums?

 3) You can't possibly express split packages well. Having pkgname fields
 in a .SRCINFO would mean you could describe all packages created by a
 PKGBUILD rather than having some loose association between a PKGBUILD
 and some possible .PKGINFO files which it might have generated.

 This is about *source* packages. The metadata needs for source packages
 are not the same as the needs for binary packages.


What is to stop us using both? I don't think anyone has said we should stop
parsing the PKGBUILD for the AUR and exclusively parse a .PKGINFO instead.
It would just provide some supplementary information that isn't currently
available in an easy to parse method from the PKGBUILD without running
arbitrary code on the server side. Reading both files would solve that,
right?

Regards,
Justin Dray
E: jus...@dray.be
M: 0433348284

[aur-general] Multiple removals

[Justin Dray]

Hey,

There are a ton of zeromq packages on the AUR even though there is zeromq
v4.xx in community

[1] zeromq-pgm (OpenPGM support is already compiled in to the one in
community)
[2] zeromq3-git
[3] zeromq-dev (there is already a zeromq-git (which is also out of date)
but this 'dev' version is based on a beta of version 3...)

I'm not sure about zeromq2 as it is a dependency for zeromqgw, so maybe it
should be left alone for now.

[1] https://aur.archlinux.org/packages/zeromq-pgm/
[2] https://aur.archlinux.org/packages/zeromq3-git/
[3] https://aur.archlinux.org/packages/zeromq-dev/

Regards,
Justin Dray
E: jus...@dray.be
M: 0433348284

[aur-general] Deletion Request

[Justin Dray]

Hi,

Can I please get unrar4[1] removed? Unrar5 is in extra already; v4 was kept
until pyunrar2 was updated to support the new version, which it was the
other day.

[1] https://aur.archlinux.org/packages/unrar4/

Regards,
Justin Dray
E: jus...@dray.be
M: 0433348284

[aur-general] Remove gmailreader

[Justin Dray]

Hi,

The gmailreader [1] package hasn't been updated in 5 years. It uses an
unmaintained library that is incompatible with gmail and has been for a
long time. Can we please remove this package from the AUR?

[1] https://aur.archlinux.org/packages/gmailreader/

Regards,
Justin Dray
E: jus...@dray.be
M: 0433348284

[aur-general] Delete sixpair-bluez

[Justin Dray]

Can we please get sixpair-bluez removed:
https://aur.archlinux.org/packages/sixpair-bluez/

It has been out of date for many years and there is already a sixpair
package that is updated.

Regards,
Justin Dray
E: jus...@dray.be
M: 0433348284

[aur-general] Deletion request ffmpeg-full-git-fixed

[Justin Dray]

Trying to navigate the pile of different versions of ffmpeg on AUR is quite
a hassle currently.

Please either delete ffmpeg-full-git-fixed or merge it in to
ffmpeg-full-git. It appears to have only been made due to the original
maintainer of ffmpeg-full-git not responding quickly, and the maintainer of
ffmpeg-full-git-fixed has stated in the comments that he no longer
maintains it. It has also been marked as out of date for 2+ months.

https://aur.archlinux.org/packages/ffmpeg-full-git-fixed/

Regards,
Justin Dray
E: jus...@dray.be
M: 0433348284

Re: [aur-general] Deletion Request - rEFIt

[Justin Dray]

Slim had a decent sized update about 2 weeks ago, it started supporting the
normal xsession methods rather than a specific list and a variety of other
things, the version before that was less than a week old. It's stable, but
certainly not dead.

Regards,
Justin Dray
E: jus...@dray.be
M: 0433348284


On Wed, Oct 16, 2013 at 11:31 AM, Sam Stuewe halosgh...@archlinux.infowrote:

 On 2013-10-15 13:56, Keshav Padram Amburay wrote:

 Hi,
  rEFIt is no longer maintained upstream and its author recommends
 everyone to switch to rEFInd instead, at http://refit.sourceforge.net/ .
 So
 please delete AUR refit 
 https://aur.archlinux.org/**packages/refit/https://aur.archlinux.org/packages/refit/package.

 With Best Regards,

 Keshav


 I am not a TU, so this is not an official set of logic, but if the sources
 still exist (even if it has been deprecated or is no longer maintained), I
 see no reason for the package to be removed unless there is a specific and
 blatant security flaw. For example, SLiM is still in the official repos
 despite maintenance largely being dead and many other packages being
 considered preferable.

 If people would like to continue using rEFIt, despite rEFInd's
 superiority, I don't see the inherent issue.

 All the best,

 -Sam

[aur-general] Orphan request: lsiutil

[Justin Dray]

I've tried emailing the current maintainer of lsiutil as it is out-of-date
and have not had any response. I'd like to update it/maintain it.


Regards,
Justin Dray
E: jus...@dray.be
M: 0433348284