[aur-general] mksrcinfo bug: PKGBUILD stdout appears in mksrcinfo
mksrcinfo will include anything the PKGBUILD writes to stdout in the body
of the PKGBUILD (i.e. not in any prepare/build/package/etc. functions when
being sourced, for example:
pkgname=example
pkgver=1
echo Hello world.
prepare() {}
build() {}
package() {}
... which will generate an .SRCINFO file with Hello world. as the first
line. This .SRCINFO file is then not parseable by AUR4 when trying to push
it to the package's git repository, which will end up with an error that
looks like this:
$ git push -u origin master:master
Counting objects: 4, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 4.38 KiB | 0 bytes/s, done.
Total 4 (delta 0), reused 0 (delta 0)
remote: Traceback (most recent call last):
remote: File /srv/http/vhosts/
aur.archlinux.org/public/git-interface/aurinfo.py, line 127, in
ParseAurinfoFromIterable
remote: key, value = map(str.strip, line.split('=', 1))
remote: ValueError: need more than 1 value to unpack
remote:
remote: During handling of the above exception, another exception occurred:
remote:
remote: Traceback (most recent call last):
remote: File hooks/update, line 239, in module
remote: srcinfo = aurinfo.ParseAurinfoFromIterable(srcinfo_raw,
ecatcher)
remote: File /srv/http/vhosts/
aur.archlinux.org/public/git-interface/aurinfo.py, line 130, in
ParseAurinfoFromIterable
remote: current_package['pkgname']))
remote: TypeError: 'NoneType' object is not subscriptable
remote: error: hook declined to update refs/heads/master
To ^aur:/matlab.git
! [remote rejected] master - master (hook declined)
error: failed to push some refs to '^aur:/matlab.git'
The fix should prevent the PKGBUILD's stdout output from appearing in the
.SRCINFO that mksrcinfo generates.
Re: [aur-general] AUR4 keywords in PKGBUILD?
On Mon, Jul 13, 2015 at 3:45 PM, Johannes Löthberg
johan...@kyriasis.com wrote:
On 12/07, Lukas Fleischer wrote:
On Sun, 12 Jul 2015 at 18:07:37, Ido Rosen wrote:
Is it possible currently to set the keywords/tags in the PKGBUILD
itself instead of on the website? (Previously, we had to set
categories on the AUR website, but that felt suboptimal.) e.g. a
keywords=('cats' 'dogs' ...); variable?
No.
I wonder if it would be useful to support having keywords in the .SRCINFO
file. A couple of people have requested it, though I'm still unsure about
the idea.
What do you think?
Definitely worthwhile.
Or, alternatively, would people be amenable to adding an ssh command
in the AUR git-shell to add/remove/set keywords?
Sounds like a nice suggestion to me. Could you please file a FR on the
bug tracker?
--
Sincerely,
Johannes Löthberg
PGP Key ID: 0x50FB9B273A9D0BB5
https://theos.kyriasis.com/~kyrias/
Re: [aur-general] We've got a spam issue in our AUR
On Sun, Jul 12, 2015 at 2:24 PM, Lukas Fleischer lfleisc...@archlinux.org wrote: On Sun, 12 Jul 2015 at 18:25:47, Andrejs Mivreņiks wrote: Hi, Suspending the account is good, though what about messages? Are they going to be removed? Also there is totally no spam protection that I know of at this moment in AUR, at some point it might turn out to be a bigger problem than that today. [...] I deleted all 15 comments the user posted. Given that only a very low number of packages were affected, I suspect that he copy-pasted the message manually. There is really nothing we can do about that (apart from disabling comments)... I'm not sure if this is worthwhile, but: http://bogofilter.sourceforge.net/ https://pypi.python.org/pypi/django-bogofilter/0.1 (example of integrating bogofilter to forum comments in Django/Python) We could add this email-style spam filtering (using bogofilter or any similar package), and make comments that fail it have to use a CAPTCHA? Or just make all comments require a CAPTCHA. Or a report spam link for comments. Another thought for improving comments might be to implement reddit-style upvoting/downvoting.
[aur-general] AUR4 keywords in PKGBUILD?
Is it possible currently to set the keywords/tags in the PKGBUILD
itself instead of on the website? (Previously, we had to set
categories on the AUR website, but that felt suboptimal.) e.g. a
keywords=('cats' 'dogs' ...); variable?
Or, alternatively, would people be amenable to adding an ssh command
in the AUR git-shell to add/remove/set keywords?
Re: [aur-general] AUR4 feature request
On Sat, Jun 13, 2015 at 11:41 PM, Eli Schwartz eschwart...@gmail.com wrote:
On Sat, Jun 13, 2015 at 1:52 AM, Ralf Mardorf info.mard...@rocketmail.com
wrote:
Thank you Justin,
I wasn't aware of https://aur.archlinux.org/packages/aur-git/ and I
agree, it should be available for AUR 4 too.
Regards,
Ralf
Rather than cloning the whole AUR history (lots of unneeded disk space) I
suggest you use the following to pull the last version in the aur-mirror:
wget -e robots=off --reject index.html -np -r -nH --cut-dirs 3
pkgbuild.com/git/aur-mirror.git/plain/{package-name}
robots=off because otherwise recursive download fails, don't download the
index page, just the files it links to, and cull the extra folders in the
path to the packagedir.
-- Eli Schwartz
If the goal of this is to create a mirror of AUR4, then the
superproject repo functionality would probably be the most
appropriate. As far as I know, the AUR devs are working on this
functionality. This is part of a series of feature requests I made a
while ago during the alpha/beta testing of aur-dev:
https://bugs.archlinux.org/task/43292
The idea is to make it possible to clone a superproject git repo
that has all of your packages (or all packages in general if so
desired) from AUR4.
This would eliminate the need for third party tools like the one you
linked to, since all you'd need to achieve the /var/aur mirror is to
git clone superproject url...
Re: [aur-general] [AUR4] Single binary package for different architectures
On Sat, Jun 13, 2015 at 2:31 PM, Rudy Matela r...@matela.com.br wrote:
Hello,
I am importing a PKGBUILD for something that has only a binary release.
More specifically, a binary release for i686 and another for x86_64.
In the old AUR, I was packaging it using an if clause to choose which
release to download depending on the architecture -- this way, I can
have a single package for both architectures. More or less like this:
if [ ${CARCH} = 'x86_64' ]; then
source=(http://example.com/release-${pkgver}-x86_64.tar.gz;)
md5sums=('00112233445566778899aabbccddeeff')
else
source=(http://example.com/release-${pkgver}-i386.tar.gz;)
md5sums=('ffeeddccbbaa99887766554433221100')
fi
Running mksrcinfo fails with the error:
/path/PKGBUILD: line XX: [: =: unary operator expected
line XX points to the line containing the if.
Are there some guildelines for packaging something like this?
How could I make mksrcinfo work?
Is there any way to generate the .SRCINFO file manually to conform to
the dual-binary release described above?
(or... should I not be doing this at all?)
pacman 4.2 introduces source_${CARCH} and *sum_${CARCH} variables.
See also:
https://wiki.archlinux.org/index.php/PKGBUILD#source
--
Rudy
Re: [aur-general] AUR4, git, subtrees ELI5?
On Thu, Jun 11, 2015 at 10:03 PM, Eli Schwartz eschwart...@gmail.com wrote: On Thu, Jun 11, 2015 at 8:44 PM, David Kaylor dpkay...@gmail.com wrote: I have so few packages to maintain, the burden to me is very low. And I'm just taking it as oppurtunity to finally learn to use Git. But a tool for submitting a tarball and having AUR4 do the conversion is a good one. Might help prrevent a massive pile of orphans after July 8th. Maintainers are going to have to jump through the hoops, though, one way or the other. Well, sure, git is fun. :) But tarball uploads means maintainers wouldn't have to go through any more hoops than they do already. Primarily, I am wondering what people who refuse to learn git *just* to contribute to the AUR might think. Any local abstraction tool would have to be fairly robust to deal with e.g. authentication, first-time updating a package that already exists, and in combination with transferring to another computer. vs. providing a compatibility layer over the old tarball interface, since aurweb already has everything else. -- Eli Schwartz I was surprised that the AUR devs didn't include an easy press a button on the website or ssh aur4 setup-repos-seed-with-aur-mirror way to import a package from the http://pkgbuild.com/git/aur-mirror.git/ git repository... It's unofficial, but it has the daily history. Perhaps an easy solution is to offer such a service on the AUR4 website from a local clone of that aur-mirror git repository to seed the repository, and then also offer a tarball upload ssh command (e.g. cat example.1.src.tar.gz | ssh aur4 process-tarball, where process-tarball is just a script that untars, commits, and pushes the contents on the server side as-if it was the user)?
Re: [aur-general] [AUR4] remove commits in aur4. how?
I'm guessing, but AUR4 probably does not allow rewriting history (non-fast-forward merges), or forced pushes. On Wed, Jun 10, 2015 at 2:02 PM, SpinFlo sl1pk...@gmail.com wrote: 2015-06-10 19:26 GMT+02:00 Marcel Korpel marcel.kor...@gmail.com: * Marcel Korpel marcel.kor...@gmail.com (Wed, 10 Jun 2015 19:25:30 +0200): $ git rebase -i HEAD~2 This opens an editor with the last two commits, where you can squash a previous revision into a later one. My bad, talked too soon: you actually squash a revision into a *previous* one. Hi @marcel nope, not work, or I not understand how works :S when I edit with git rebase -i HEAD~5, and changing pick with squash (only one leave with pick) and editing the message commit, say all is ok. but when try to push the changes in [aur4] get the same fail like a message OP any help? greetings
Re: [aur-general] AUR4 migration of orphan packages
I didn't know that existed! Cool.
Maybe this should be front and center next to any links/buttons to
disown a package? E.g. Are you sure you want to disown this package?
Remember, you can always add co-maintainers rather than disowning and
readopting later...
On Tue, Jun 9, 2015 at 11:59 AM, Bruno Pagani bruno.pag...@ens-lyon.org wrote:
You mean that:
https://aur4.archlinux.org/pkgbase/${pkgname}/comaintainers/ ?
Le 09/06/2015 17:53, Ido Rosen a écrit :
I think some of the orphans on AUR are just maintained by multiple
people. The usage pattern is:
Person A adopts, updates, and disowns.
Person B some time later notices it's out of date, adopts, updates, disowns.
It seems perfectly reasonable to have multiple people maintain a
package over time this way. Maybe we just need better support for
this style of non-maintainership that isn't quite orphaned? Support
for multiple maintainers/collaborators like on GitHub repos?
(Outright owning a package in AUR prevents anyone else from updating
it.)
I do something in between outright maintainership and this adopt,
update, disown non-maintainership: I have a git repo with my AUR
packages, and accept pull requests on GitHub -- if someone wants to
update a package faster than I can get to it (since I only have time
on weekends), they submit a pull request and I merge it in, test, and
submit to AUR (which takes 2 min to verify submit the package, vs.
the a-priori-unknown time commitment of doing it all myself). It
would be nice if there were an official way to make AUR support
collaborative maintainership like this.
On Tue, Jun 9, 2015 at 11:10 AM, Giancarlo Razzolini
grazzol...@gmail.com wrote:
On 09-06-2015 08:17, Jesse McClure wrote:
Agreed. All the packages that no one carries over to aur4 will still be
archived for some time, so if anyone*actually* wants them in aur4, they
can
adopt them. One can keep their own store of PKGBUILDs, but the aur is for
packages that it is likely multiple users will want. If not even*one*
person
wants a package enough to maintain it in the aur, then it doesn't need to
be
there.
I have adopted some packages, created a few more, but I think that this
migration should serve the purpose of cleansing the database. We already
have orphans on aur4 and that is unacceptable. Migrate a package and then
orphan it is not ideal and we will end up having the same number of orphans
as we already have.
Cheers,
Giancarlo Razzolini
Re: [aur-general] AUR4 migration of orphan packages
On Tue, Jun 9, 2015 at 12:14 PM, Chris Warrick kwpol...@gmail.com wrote: On Tue, Jun 9, 2015 at 5:53 PM, Ido Rosen i...@kernel.org wrote: I think some of the orphans on AUR are just maintained by multiple people. The usage pattern is: Person A adopts, updates, and disowns. Person B some time later notices it's out of date, adopts, updates, disowns. It seems perfectly reasonable to have multiple people maintain a package over time this way. Maybe we just need better support for this style of non-maintainership that isn't quite orphaned? Support for multiple maintainers/collaborators like on GitHub repos? (Outright owning a package in AUR prevents anyone else from updating it.) It also prevents a third party (Mallory) from taking it over and: (a) replacing it with something else (malware?); (b) preventing Alice and Bob from updating it; (c) requesting deletion; (d) [insert other harmful actions here]. Yes, that's right, and these are all good reasons why we should continue to have ownership, which is why I suggested we support something in-between as well (before I knew about co-maintainership capabilities in AUR, which basically resolve this). if someone wants to update a package faster than I can get to it […] You should use some service that would tell you about package updates, for example requires.io for Python, or RSS feeds. Will take 5 minutes to do it in many cases (to update pkgver and the checkums) Thanks for the suggestion, but these services don't work for some (or most) of the packages I maintain, and some of the packages are academic in nature. For updates that are just updating the pkgver updpkgsums, I do those myself, but there are cases (major version changes, new feature requests, upstream breaks something, dependent packages break something, etc.) where debugging/more time is needed. That's when it may take me a week or more to get around to updating the package, in which case if someone else with more time gets to it sooner, I encourage them to submit a pull request and add them as a Contributor: (and thank them for helping!). :-) Another thing that having the pull request workflow I use allows is for the users of the package to add things to the package (e.g. optdepends as they come out) and fix bugs. It makes my work after initially creating the package basically just QA to make sure their PRs don't break anything in many cases, which I like. -- Chris Warrick https://chriswarrick.com/ PGP: 5EAAEA16
Re: [aur-general] AUR4 migration of orphan packages
I think some of the orphans on AUR are just maintained by multiple people. The usage pattern is: Person A adopts, updates, and disowns. Person B some time later notices it's out of date, adopts, updates, disowns. It seems perfectly reasonable to have multiple people maintain a package over time this way. Maybe we just need better support for this style of non-maintainership that isn't quite orphaned? Support for multiple maintainers/collaborators like on GitHub repos? (Outright owning a package in AUR prevents anyone else from updating it.) I do something in between outright maintainership and this adopt, update, disown non-maintainership: I have a git repo with my AUR packages, and accept pull requests on GitHub -- if someone wants to update a package faster than I can get to it (since I only have time on weekends), they submit a pull request and I merge it in, test, and submit to AUR (which takes 2 min to verify submit the package, vs. the a-priori-unknown time commitment of doing it all myself). It would be nice if there were an official way to make AUR support collaborative maintainership like this. On Tue, Jun 9, 2015 at 11:10 AM, Giancarlo Razzolini grazzol...@gmail.com wrote: On 09-06-2015 08:17, Jesse McClure wrote: Agreed. All the packages that no one carries over to aur4 will still be archived for some time, so if anyone*actually* wants them in aur4, they can adopt them. One can keep their own store of PKGBUILDs, but the aur is for packages that it is likely multiple users will want. If not even*one* person wants a package enough to maintain it in the aur, then it doesn't need to be there. I have adopted some packages, created a few more, but I think that this migration should serve the purpose of cleansing the database. We already have orphans on aur4 and that is unacceptable. Migrate a package and then orphan it is not ideal and we will end up having the same number of orphans as we already have. Cheers, Giancarlo Razzolini
Re: [aur-general] Adding a git package to AUR4
On Tue, Jun 9, 2015 at 5:00 PM, Harley W harl...@hotmail.com wrote: Hello,I'm having a lot of trouble transferring my package to AUR4. It is a git package, so after trying for about an hour to get it to work the way that is described on the wiki page, I thought I could try to push it to a separate remote repository (the aur4 repository). Is there a way to do this? I tried $ git add remote aur4 aur4.archlinux.org/savant-git.git$ git add *$ git commit -m Initial upload to aur4$ git push aur4 master Which said, as I expected, that aur4.archlinux.org/savant-git.git does not appear to be a git repository. Is there a way to accomplish it this way? If not, the issue I was having in the method described in the wiki was that it would keep telling me:remote: error: missing .SRCINFOEven though I committed it and I copied it into pretty much every directory, I don't understand this at all. Sorry about this question, I am still quite new to git and I've never dealt with SSH before.Thanks for any help. Try: pacman -Sy pkgbuild-introspection git filter-branch -f --tree-filter test -f .SRCINFO || mksrcinfo This will go through the current branch and, if no .SRCINFO exists in a commit, create one and edit the commit (rewriting history). This is part of what my script[1] does. Ido [1] https://github.com/ido/packages-archlinux/blob/master/bin/import-to-aur4.sh
Re: [aur-general] [RFC] Draft of the AUR 4.0.0 migration notification
Hi, Just a reminder that I wrote this script when this first came up to help maintainers who already maintain *multiple* packages in one git repo to split them into separate git repos, upload them individually to AUR4, etc. https://github.com/ido/packages-archlinux/blob/master/bin/import-to-aur4.sh Also, the link in your notification email is broken: Arch_User_Repository#Submitting_packages_to_aur-dev.archlinux.org should be Arch_User_Repository#Submitting_packages_to_aur4.archlinux.org Cheers, Ido On Sat, May 23, 2015 at 8:00 AM, Alexandre Ferrando alfer...@gmail.com wrote: On 23 May 2015 at 11:53, Florian Bruhin m...@the-compiler.org wrote: I think the wiki should contain some information/hints on how to convert existing git repos (which might be without .SRCINFO) so they can be pushed to aur4. I think some while ago there was a script for that here on the ML? At least I remember this post [ 0 ] and several more around those days containing scripts and discussions about the subject. For example this thread if you're already storing your packages in a git repo [ 1 ] Most of the discussion in this ML was focused IIRC late December 2014 to early January 2015. [ 0 ] https://lists.archlinux.org/pipermail/aur-general/2014-December/030051.html [ 1 ] https://lists.archlinux.org/pipermail/aur-general/2014-December/030021.html
Re: [aur-general] Linux packaging
Some options: yaourt -G linux https://projects.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/linux git clone packages.git with --depth 1 (shallow clone) On Tue, Mar 24, 2015 at 2:25 PM, Javier Domingo Cansino javier...@gmail.com wrote: Hi, I am looking to package rtai, which was already packaged some years ago. I want to make it easily updatable, and I have a problem. RTAI is a kernel patch and some other stuff. I am now trying to obtain the linux config for an specific arch kernel. I was trying to extract it from packages.git, but it's a monstrous repo and not a good way to obtain the needed object without downloading it all . The svn version is also quite hacky , but more affordable, I would svn log, search for the most close version bump commit and extract that config file (along with the patch). Is there any recommended method to build a linux kernel of X version without having to package the config files? Or maybe a git tree that is smaller and reasonable to clone. Cheers,
Re: [aur-general] [arch-dev-public] Dropping mplayer-vaapi
Are you dropping support for it because it has been forked replaced upstream, or because of time constraints on your end? Or have you migrated away from nvidia graphics? If the former, could you recommend an [extra] or [community] / officially supported mplayer-based or mplayer-like package other than mplayer-vaapi that is accelerated on machines that use nvidia drivers? Non-VAAPI mplayer seems to have terrible performance for me compared to mplayer-vaapi. This is an important media-playing package that should not be dropped, IMO. I'm not a TU, but is it possible someone else would pick it up, if there is no supported VAAPI-enabled mplayer fork? On Sat, Mar 7, 2015 at 9:12 PM, Zack Buhman z...@buhman.org wrote: On Sat, Mar 07, 2015 at 08:34:01PM +0200, Evangelos Foutras wrote: I'll be moving mplayer-vaapi to the AUR in a few days. That's most unfortunate.
Re: [aur-general] How do you deal with pkgver() version controlled PKGBUILDs?
Since this is a git question, it probably belongs on that project's mailing list. Anyhow, what I do is use git smudge/clean filters to ignore the line. Here's an example from a different application of smudge/clean filters of how to ignore specific lines in a file: http://stackoverflow.com/questions/16244969/how-to-tell-git-to-ignore-individual-lines-i-e-gitignore-for-specific-lines-of On Thu, Feb 12, 2015 at 10:11 PM, Jashandeep Sohi jashandeep.s.s...@gmail.com wrote: Hi, I'm using git to version control my PKGBUILDs. Most of them build stable versions of packages using a static pkgver; however, some of them build unstable versions (from git, hg, etc.), and make use of the pkgver() function to compute a pkgver on build time. The problem that I'm having is that whenever I build one of the unstable packages, the value of pkgver in the PKGBUILD get updated by pkgver(), which causes Git to think that the file has changed. If I ever want to commit changes to the PKGBUILD, I first have to change pkgver back to what it was to prevent spurious changes to pkgver to committed as well. I know I'm being pedantic, but if someone has already thought of a solution/fix, that would appreciated. Thanks, Jashandeep Sohi
Re: [aur-general] AUR 4 = Migrating 1 git to git-per-package
On Sun, Jan 18, 2015 at 5:26 PM, Hugo Osvaldo Barrera h...@barrera.io wrote: On 2014-12-29 23:41, Ido Rosen wrote: On Mon, Dec 29, 2014 at 11:38 PM, Ido Rosen i...@kernel.org wrote: Hi all, TL;DR: https://github.com/ido/packages-archlinux/blob/master/bin/import-to-aur4.sh This is how I invoke it: bin/import-to-aur4.sh https://github.com/ido/packages-archlinux aur (replace ido/packages-archlinux and aur with what's appropriate for you, if you replace aur with . then it will work in the root of the git repo. It checks for existence of a PKGBUILD file, so it should do the right thing most of the time.) I would have gone with `git branch --orphan` and `git cherry-pick`, but this looks like an interesting alternative I had not thought of. Thanks for the script! You're welcome, and I'm totally open to improvements/changes to the script if you want to send a pull request! :-) -- Hugo Osvaldo Barrera A: Because we read from top to bottom, left to right. Q: Why should I start my reply below the quoted text?
Re: [aur-general] Trusted User application
Hi, On Wed, Dec 31, 2014 at 1:20 PM, Jerome Leclanche adys...@gmail.com wrote: [reposted to the correct list, oops] Hi list My name is Jerome Leclanche and this is my application for becoming an Arch Linux TU. Both Balló György and Sven-Hendrik Haase have encouraged me to apply, and Sven-Hendrik has agreed to sponsor me for the occasion. Just wanted to put in a good word, I've interacted a bit with Jerome. He's very friendly and knowledgeable. For what it's worth, I think he'll make a good TU. Cheers, Ido
Re: [aur-general] AUR 4.0.0 pre-alpha
Will all existing AUR packages automatically get their own git repositories or will we have to resubmit all packages? On Mon, Dec 29, 2014 at 4:01 PM, Lukas Fleischer archli...@cryptocrack.de wrote: The 4.0.0 release brings Git repositories to AUR packages. You can test a pre-alpha version at aur-dev.archlinux.org [1]. In order to submit packages, you can follow these steps: 1. Create a new SSH key pair for the AUR. While this step is not strictly necessary (you can use any existing SSH key), it is recommended to do this: $ ssh-keygen -f ~/.ssh/id_rsa-aur 2. Log into the AUR web interface at [1], go to My Account and copy the content of ~/.ssh/id_rsa-aur.pub (or any other key you want to use) into the SSH Public Key field. Click Update to save the key. 3. The SSH daemon for the AUR uses a custom user and a custom port. It is recommended to add the following lines to your ~/.ssh/config so you don't need to specify user and port each time you connect to the AUR SSH interface: Host aur-dev.archlinux.org IdentityFile ~/.ssh/id_rsa-aur User aur Port 4. To create a new (empty) package base foobar, run the following command: $ ssh aur-dev.archlinux.org setup-repo foobar 5. If you want to submit changes to a package base, you need to clone the package repository via SSH: $ git clone ssh+git://aur-dev.archlinux.org/foobar.git/ When making changes to the repository, make sure you always include the PKGBUILD and .SRCINFO in the top-level directory. You can submit new versions of a package base to the AUR by committing the new PKGBUILD and .SRCINFO and running `git push`. If you spot any major flaws or have suggestions for the new interface, please let me know. Regards, Lukas [1] https://aur-dev.archlinux.org/
Re: [aur-general] AUR 4 = Migrating 1 git to git-per-package
git help subtree. On Mon, Dec 29, 2014 at 7:53 PM, Phillip Smith fuka...@gmail.com wrote: For those of us already storing our packages in git[0], has anyone got some documentation/pointers for how to handle migrating from having 1 big git repository to dozens of individual git repositories? Do we just blat away our current repository and re-initialize each package as it's own repository or is there a smarter way? [0] https://github.com/fukawi2/aur-packages
Re: [aur-general] AUR 4 = Migrating 1 git to git-per-package
On Mon, Dec 29, 2014 at 7:54 PM, Ido Rosen i...@kernel.org wrote: git help subtree. On Mon, Dec 29, 2014 at 7:53 PM, Phillip Smith fuka...@gmail.com wrote: For those of us already storing our packages in git[0], has anyone got some documentation/pointers for how to handle migrating from having 1 big git repository to dozens of individual git repositories? Do we just blat away our current repository and re-initialize each package as it's own repository or is there a smarter way? git help subtree, but to clarify further: I do this right now in https://github.com/ido/packages-archlinux ...I have a script prepared using git subtree and a filter-branch command to split out the /aur directory in that repo into multiple packages. I'm testing it locally. The best part is that I can still maintain the individual package repos separately from the main one, and keep a separate git repository with all my individual repos as submodules, then just use git submodule foreach git subtree pull --squash (or similar) to update all the packages at once and only if those subfolders were changed in the one-big-repository (ido/packages-archlinux.git) [0] https://github.com/fukawi2/aur-packages
Re: [aur-general] AUR 4 = Migrating 1 git to git-per-package
On Mon, Dec 29, 2014 at 7:58 PM, Ido Rosen i...@kernel.org wrote: On Mon, Dec 29, 2014 at 7:54 PM, Ido Rosen i...@kernel.org wrote: git help subtree. On Mon, Dec 29, 2014 at 7:53 PM, Phillip Smith fuka...@gmail.com wrote: For those of us already storing our packages in git[0], has anyone got some documentation/pointers for how to handle migrating from having 1 big git repository to dozens of individual git repositories? Do we just blat away our current repository and re-initialize each package as it's own repository or is there a smarter way? git help subtree, but to clarify further: I do this right now in https://github.com/ido/packages-archlinux ...I have a script prepared using git subtree and a filter-branch command to split out the /aur directory in that repo into multiple packages. I'm testing it locally. The best part is that I can still maintain the individual package repos separately from the main one, and keep a separate git repository with all my individual repos as submodules, then just use git submodule foreach git subtree pull --squash (or similar) to update all the packages at once and only if those subfolders were changed in the one-big-repository (ido/packages-archlinux.git) (...which can be done as a post-commit or post-receive hook in the master repo.) [0] https://github.com/fukawi2/aur-packages
Re: [aur-general] AUR 4 = Migrating 1 git to git-per-package
If you follow the pattern I do, of having a directory within your git repository (I call mine aur) that contains directories named after each package's $pkgbase (or $pkgname if not a split package), then I should be able to post my script here (after I've tested it a little more on aur-dev) later tonight. On Mon, Dec 29, 2014 at 8:04 PM, Phillip Smith fuka...@gmail.com wrote: On 30 December 2014 at 11:54, Ido Rosen i...@kernel.org wrote: git help subtree. My git-fu is weak beyond add/commit/push/pull. Looks a little complex: http://makingsoftware.wordpress.com/2013/02/16/using-git-subtrees-for-repository-separation/ Perhaps we should develop some kind of migration script to assist?
Re: [aur-general] AUR 4.0.0 pre-alpha
Is there currently a script to just create a .SRCINFO from a PKGBUILD? I don't want any side effects like downloading src packages (i.e. I don't want to run makepkg or mkaurball), etc. since this is for use in git filter-branch --tree-filter.
Re: [aur-general] AUR 4.0.0 pre-alpha
On Mon, Dec 29, 2014 at 11:00 PM, Dave Reisner d...@falconindy.com wrote: On Mon, Dec 29, 2014 at 10:21:17PM -0500, Dave Reisner wrote: On Mon, Dec 29, 2014 at 09:49:24PM -0500, Ido Rosen wrote: Is there currently a script to just create a .SRCINFO from a PKGBUILD? I don't want any side effects like downloading src packages (i.e. I don't want to run makepkg or mkaurball), etc. since this is for use in git filter-branch --tree-filter. There exists a tool in the pkgbuild-introspection git repo[1] which will write a .SRCINFO to standard output when given a PKGBUILD. Pull requests welcome to give it a better name (mksrcinfo?) and some UI. dR [1] https://github.com/falconindy/pkgbuild-introspection/blob/master/introspect Nevermind, this (mksrcinfo) now exists in pkgbuild-introspection-git. Bug reports welcome. dR Thanks. For now, I'm just copying and pasting this into my script rather than depending on pkgbuild-introspection-git. :-) See other thread (one git - AUR4 per package git repos) in a minute for the script contents.
Re: [aur-general] AUR 4 = Migrating 1 git to git-per-package
Hi all, TL;DR: https://github.com/ido/packages-archlinux/blob/master/bin/import-to-aur4.sh I maintain my AUR packages in https://github.com/ido/packages-archlinux, under a subdirectory called aur, with each PKGBUILD in its own folder under that aur folder. So, for example, ceph-git is in $WORKDIR/aur/ceph-git/PKGBUILD... To migrate this to AUR 4.0 per-package git repositories, I used git subtree and git filter-branch (to get around that pesky server-side update hook that looks for a valid .SRCINFO). 0) It does all of its work in a temp dir (/tmp/importaur4.X by default; export TMPDIR=$HOME/ to do it in your $HOME for example). It clones a fresh copy of the upstream one-big-git-repository (use file:/// if you want to do this from a local repo). It accepts two arguments: $1 = URL to repo to git clone, $2 = subdirectory relative path from workdir root. Warning: Use ssh-add/ssh-agent to add your AUR ssh key otherwise you will have to do a lot of typing! 1) It uses git subtree split to split out packages into their own branches (this works much like git filter-branch --subdirectory-filter). 2) It uses the code from pkgbuild-introspection to create a SRCINFO file. 3) It uses git filter-branch --tree-filter to copy in the .SRCINFO it generated for any commits on the per-package branches that do not already have a .SRCINFO file in them. 4) It uses git push to push the per-package branches (aur4/$pkgbase) to the master branch on the aur-dev server. 5) It creates a superproject git repository for you in /tmp/importaur4./ to track all of your per-package repos in one place, which has git submodules for each per-package repository. This is for convenience and is located in /tmp/importaur4./aur4-superproject. Please send pull requests for any improvements you make; I wrote this quickly with the intent of using it for my own packages. It fails on some repositories, mostly due to the server-side update hook in AUR4 right now. Example failures shown below. The script is located at: https://github.com/ido/packages-archlinux/blob/master/bin/import-to-aur4.sh Enjoy! Ido Problem 1: blobs larger than 100kB are rejected by aur-dev...so they don't get imported by this script. This is problematic for kernel packages with inline patches. + git push ssh+git://a...@aur-dev.archlinux.org:/linux-lts-tresor.git/ aur4/linux-lts-tresor:master Counting objects: 33, done. Delta compression using up to 8 threads. Compressing objects: 100% (32/32), done. Writing objects: 100% (33/33), 53.36 KiB | 0 bytes/s, done. Total 33 (delta 16), reused 6 (delta 1) remote: error: The following error occurred when parsing commit remote: error: 22828bff8f2c9890b386e8584a927e64507fe6c1: remote: error: maximum blob size (100kB) exceeded remote: error: hook declined to update refs/heads/master To ssh+git://a...@aur-dev.archlinux.org:/linux-lts-tresor.git/ ! [remote rejected] aur4/linux-lts-tresor - master (hook declined) --- Problem 2: The AUR4 update hook is poorly written, it compares a string to an int when looking at the pkginfo['epoch'], so packages with an epoch set fail to pass the update hook. Failed to setup-repo ceph-git ... maybe it already exists? + git push ssh+git://a...@aur-dev.archlinux.org:/ceph-git.git/ aur4/ceph-git:master Counting objects: 35, done. Delta compression using up to 8 threads. Compressing objects: 100% (25/25), done. Writing objects: 100% (35/35), 7.48 KiB | 0 bytes/s, done. Total 35 (delta 17), reused 14 (delta 10) remote: Traceback (most recent call last): remote: File hooks/update, line 212, in module remote: save_srcinfo(srcinfo, db, cur, user) remote: File hooks/update, line 45, in save_srcinfo remote: if 'epoch' in pkginfo and pkginfo['epoch'] 0: remote: TypeError: unorderable types: str() int() remote: error: hook declined to update refs/heads/master To ssh+git://a...@aur-dev.archlinux.org:/ceph-git.git/ ! [remote rejected] aur4/ceph-git - master (hook declined) On Mon, Dec 29, 2014 at 8:12 PM, Ido Rosen i...@kernel.org wrote: If you follow the pattern I do, of having a directory within your git repository (I call mine aur) that contains directories named after each package's $pkgbase (or $pkgname if not a split package), then I should be able to post my script here (after I've tested it a little more on aur-dev) later tonight. On Mon, Dec 29, 2014 at 8:04 PM, Phillip Smith fuka...@gmail.com wrote: On 30 December 2014 at 11:54, Ido Rosen i...@kernel.org wrote: git help subtree. My git-fu is weak beyond add/commit/push/pull. Looks a little complex: http://makingsoftware.wordpress.com/2013/02/16/using-git-subtrees-for-repository-separation/ Perhaps we should develop some kind of migration script to assist?
Re: [aur-general] AUR 4.0.0 pre-alpha
Posted in other thread, but: The AUR4 update hook compares an str to an int when looking at the pkginfo['epoch'], so packages with an epoch set fail to pass the update hook. Probably should check that the string pkginfo['epoch'] contains only numbers, then do an int(pkginfo['epoch']) in the comparison line there... line 45 of save_srcinfo. Failed to setup-repo ceph-git ... maybe it already exists? + git push ssh+git://a...@aur-dev.archlinux.org:/ceph-git.git/ aur4/ceph-git:master Counting objects: 35, done. Delta compression using up to 8 threads. Compressing objects: 100% (25/25), done. Writing objects: 100% (35/35), 7.48 KiB | 0 bytes/s, done. Total 35 (delta 17), reused 14 (delta 10) remote: Traceback (most recent call last): remote: File hooks/update, line 212, in module remote: save_srcinfo(srcinfo, db, cur, user) remote: File hooks/update, line 45, in save_srcinfo remote: if 'epoch' in pkginfo and pkginfo['epoch'] 0: remote: TypeError: unorderable types: str() int() remote: error: hook declined to update refs/heads/master To ssh+git://a...@aur-dev.archlinux.org:/ceph-git.git/ ! [remote rejected] aur4/ceph-git - master (hook declined) On Mon, Dec 29, 2014 at 11:15 PM, Ido Rosen i...@kernel.org wrote: On Mon, Dec 29, 2014 at 11:00 PM, Dave Reisner d...@falconindy.com wrote: On Mon, Dec 29, 2014 at 10:21:17PM -0500, Dave Reisner wrote: On Mon, Dec 29, 2014 at 09:49:24PM -0500, Ido Rosen wrote: Is there currently a script to just create a .SRCINFO from a PKGBUILD? I don't want any side effects like downloading src packages (i.e. I don't want to run makepkg or mkaurball), etc. since this is for use in git filter-branch --tree-filter. There exists a tool in the pkgbuild-introspection git repo[1] which will write a .SRCINFO to standard output when given a PKGBUILD. Pull requests welcome to give it a better name (mksrcinfo?) and some UI. dR [1] https://github.com/falconindy/pkgbuild-introspection/blob/master/introspect Nevermind, this (mksrcinfo) now exists in pkgbuild-introspection-git. Bug reports welcome. dR Thanks. For now, I'm just copying and pasting this into my script rather than depending on pkgbuild-introspection-git. :-) See other thread (one git - AUR4 per package git repos) in a minute for the script contents.
Re: [aur-general] AUR 4 = Migrating 1 git to git-per-package
On Mon, Dec 29, 2014 at 11:38 PM, Ido Rosen i...@kernel.org wrote: Hi all, TL;DR: https://github.com/ido/packages-archlinux/blob/master/bin/import-to-aur4.sh This is how I invoke it: bin/import-to-aur4.sh https://github.com/ido/packages-archlinux aur (replace ido/packages-archlinux and aur with what's appropriate for you, if you replace aur with . then it will work in the root of the git repo. It checks for existence of a PKGBUILD file, so it should do the right thing most of the time.)
Re: [aur-general] Should we recommend removing comments from the AUR?
This seems like a hack, why not just use a real issue tracker? For example, I use GitHub Issues to track issues related to my AUR packages, and then the AUR comments become something more like a News page for that package. I thought there was a plan for AUR to move to something more VCS-oriented for tracking changes in PKGBUILDs (i.e. AUR git hosting), and that might come with issue-tracker-like capabilities, but I'm not sure what the state of that is currently or who is working on it. Maybe TUs/devs can chime in as that may solve this use case for comments on its own? (NB: If the intention would be to make maintainers able to remove comments, then there are many packages without maintainers where people adopt, update, orphan when there's an update - it'd be important to protect those packages against automated mass-comment-removals by malicious third party.) On Mon, Dec 1, 2014 at 12:15 PM, Karol Blazewicz karol.blazew...@gmail.com wrote: AUR Comment for tmux-mem-cpu-load-git from https://aur.archlinux.org//pkgbase/tmux-mem-cpu-load-git/ dlin wrote: Please remove old comment or fixed issues to keep AUR clean. 2014/12/01 2.2.1.r3 remove 'v' in version and depends 2013/08/18 v2.2.1-1 use pacman 4.1 method to pull git source, added pkgver() What is your take on this idea?
Re: [aur-general] Should we recommend removing comments from the AUR?
Sorry for top posting accidentally.
Re: [aur-general] mkinitcpio/mdadm/mdadm_udev fail to start raid10
On Mon, Nov 24, 2014 at 8:06 PM, Doug Newgard scim...@archlinux.info wrote: On Mon, 24 Nov 2014 17:27:09 -0500 Ido Rosen i...@kernel.org wrote: The the default configuration under ArchLinux and DEVICE partitions in mdadm.conf, mdadm and the mdadm mkinitcpio hook fail to load the raid10 kernel module automatically, and as a result raid10 arrays fail to load on boot in Arch. My temporary workaround is to include the raid10 kernel module in the mkinitcpio.conf MODULES= list, it could also be included in /etc/modules-load.d/*.conf, but this should not be necessary, and is currently not necessary for raid1 arrays. I do not think this is an upstream problem since my LFS and Gentoo boxes do load the correct (raid10) kernel module without any specific configuration to do so. Has anyone else replicated this behavior? Suggestions: - Preferred: Make the initcpio hook/mdadm udev rules/whatever loads raid1.ko normally also detect raid10 (and raid5, raid6, ...) arrays properly. - Alternatively: Add a section to the SW RAID wiki page describing how to make the module load persist on boot (https://wiki.archlinux.org/index.php/Software_RAID_and_LVM#Load_kernel_modules) Ido Did you mean to send this to arch-general instead? Yes, sorry.
[aur-general] promote bmon to community?
Hi, Would anyone be willing to bring bmon into [community]? It's a particularly nice ncurses bandwidth monitor, currently maintained by dragonl...@aur.archlinux.org (main package) and me (git package). It has 79 votes. I've seen packages with fewer votes go into [community] but would understand either way. Ido
[aur-general] linux-lts-tresor?
Hi, I wasn't contacted and apparently linux-lts-tresor has been disowned/taken over without my consent or any notice. Please explain... Ido
Re: [aur-general] linux-lts-tresor?
Daniel, I think you orphaned that package for me originally over a year ago. I don't know who took it from me though. The issue isn't that I want it back, I just don't think this is an isolated incident - there's at least one TU disowning packages manually without following procedures. On Tue, Sep 30, 2014 at 11:16 PM, Daniel Micay danielmi...@gmail.com wrote: I don't see anything on the requests list or on this one. Do you remember how this request was made? I don't remember who made the orphan / delection requests for the tresor packages, but I do remember that they were very neglected. The remaining packages are now well-maintained and gets promptly updated to the new kernel point releases. There have been dozens (or more) of kernel point releases since I dealt with the orphan request. I think the maintainer was sent an email, but if they weren't we still would have heard about this many months ago if they were actively maintaining the package.
Re: [aur-general] chromium-libpdf
Yes, that is my point. It did up until recently, it was integrated into chromium recently. On Sun, Aug 31, 2014 at 6:09 PM, Timothy Redaelli tredae...@archlinux.info wrote: Il 31/08/2014 03:23, Ido Rosen ha scritto: Hi, Would it be possible to add a replaces= and/or conflicts= to the chromium Arch package for chromium-libpdf, since it integrates that (formerly very popular) AUR package and causes a file conflict on attempted upgrade otherwise?(Given the popularity of both packages, seems like a good idea?) chromium-libpdf does NOT exists in aur...
[aur-general] chromium-libpdf
Hi, Would it be possible to add a replaces= and/or conflicts= to the chromium Arch package for chromium-libpdf, since it integrates that (formerly very popular) AUR package and causes a file conflict on attempted upgrade otherwise?(Given the popularity of both packages, seems like a good idea?) Thanks, Ido
Re: [aur-general] AUR GIT and Bug Tracker
On Sun, Aug 17, 2014 at 11:42 AM, Doug Newgard scim...@archlinux.info wrote: On 2014-08-17 15:26, SpinFlo wrote: 2014-08-17 17:25 GMT+02:00 mrle...@gmail.com: Hi everyone, i heard that something like a bug tracker/GIT for the packages in AUR is planned, and i've become curious how the state of it is like this? http://pkgbuild.com/git/aur-mirror.git/tree/ No, he means like this: https://mailman.archlinux.org/pipermail/aur-dev/2014-June/002770.html https://mailman.archlinux.org/pipermail/aur-dev/2014-June/002789.html Seeing the discussion about using info/alternates to store git objects for all repos in one place, it sounds a lot like they're reinventing the wheel... Git integration would be fantastic, but I'd strongly suggest that AUR devs not reinvent the wheel - let GitHub or BitBucket or Gitorious, etc. do the Git hosting for you, and do actions based on web-hooks[1], which most git hosts support. [1] https://developer.github.com/webhooks/ PS: I already maintain all of my PKGBUILDs in one git repository on GitHub (https://github.com/ido/packages-archlinux). If the git integration supports GitHub (or even if not), I would then switch to adding each of the packages as git submodules to my master project (which would include a vagrantfile and my build environment)...making my package build environment reproducible for any other packagers/AUR users.
Re: [aur-general] AUR GIT and Bug Tracker
On Sun, Aug 17, 2014 at 12:31 PM, Lukas Fleischer archli...@cryptocrack.de wrote: On Sun, 17 Aug 2014 at 17:50:54, Ido Rosen wrote: [...] Seeing the discussion about using info/alternates to store git objects for all repos in one place, it sounds a lot like they're reinventing the wheel... Git integration would be fantastic, but I'd strongly suggest that AUR devs not reinvent the wheel - let GitHub or BitBucket or Gitorious, etc. do the Git hosting for you, and do actions based on web-hooks[1], which most git hosts support. It is not only about parsing package data. We need a centralized place where people can submit and discuss packages. That centralized place must allow for easily changing the maintainer (disown/adopt) and we (the Trusted Users) need full control (permissions to delete, merge, remove comments, ...) of every repository. A first idea was to using existing services for hosting but then there are only two options: * Statically connect each AUR package to a repository that is hosted somewhere else. Means we do not have full control over the repositories since we do not host them and we cannot simply switch to another repository if the maintainer becomes inactive/irresponsible. * Dynamically connect each AUR package to a repository, so that it is easy to switch to a new repository if someone maintains a fork of the same package somewhere. Means we are going to lose all comments, bug tickets, ... Why would you lose all comments/bugs/tickets? Why do those have to be in the same repository as the packages themselves? So we cannot use any features the Git hosting services provide, apart from hosting the repositories themselves which is trivial (apart from authentication stuff that has already been implemented, though). As a byproduct of setting up our own SSH/Git infrastructure, you will also be able to perform several basic AUR operations (create a new package, adopt a package, ...) via the command line which is a nice feature on its own. You can still collaborate using a decentralized work flow, put your stuff on GitHub, let people issue pull requests etc. but the main repositories will be hosted on aur.archlinux.org. I don't personally mind if I end up using GitHub or some other Git hosting like AUR's homegrown solution - the interface is the same to me for the most part. I was just suggesting that you use existing ones because you will probably encounter the same issues existing ones have on the backend and it may be a waste of resources to create yet another git hosting service...even a special-purpose one. I hope whichever way you go succeeds. I agree that it's a good approach overall to store the PKGBUILDs and associated files in a version controlled repository rather than ephemeral tarballs. [1] https://developer.github.com/webhooks/ PS: I already maintain all of my PKGBUILDs in one git repository on GitHub (https://github.com/ido/packages-archlinux). If the git integration supports GitHub (or even if not), I would then switch to adding each of the packages as git submodules to my master project (which would include a vagrantfile and my build environment)...making my package build environment reproducible for any other packagers/AUR users. Think about workflows when designing this thing. I hope there is documentation centered around packaging workflows when you release the new features, the use case I'm especially interested in is to be able to submodule/subtree whatever packages I want from AUR into a new ArchLinux-based sub-distro and build them all... Also, it'd be very nice if the interface were the same for ABS/packages.git as it were for AUR, for example, you could consider ABS a subset of AUR... This line of discussion is probably worth a separate thread, and I'm not sure which the best mailing list to discuss it would be.
Re: [aur-general] no LLDP tools in [extra] or [community] :-/
On Tue, Aug 5, 2014 at 8:28 PM, Sébastien Luttringer se...@seblu.net wrote: On 04/08/2014 17:39, Ido Rosen wrote: On Mon, Aug 4, 2014 at 11:31 AM, Sébastien Luttringer se...@seblu.net wrote: On 23/07/2014 23:35, Sébastien Luttringer wrote: On 23/07/2014 15:59, Ido Rosen wrote: That's fair, thank you for packaging lldpd! I noticed RedHat no longer seems to package ladvd, and has switched to lldpad. Maybe we should package lldpad (aka Open-LLDP) from http://www.open-lldp.org/ ? Thoughts? Background: - Last release one year ago (not so RERO) - Last commit un May 2014 (good) - The software is not in AUR. (nobody seems to have interest) I get all LLDP info (even proprietary protocols) with lldpd and the soft is well maintained. Although I would be happy to see him in community, I do not feel the need to maintain both. Do you see a technical reason to get both? Well put. I see no technical reason other than RHEL compatibility, which isn't enough on its own. Lldpd is working great, btw. :) Regards, -- Sébastien Seblu Luttringer https://seblu.net | Twitter: @seblu42 GPG: 0x2072D77A
Re: [aur-general] no LLDP tools in [extra] or [community] :-/
On Mon, Aug 4, 2014 at 11:31 AM, Sébastien Luttringer se...@seblu.net wrote: On 23/07/2014 23:35, Sébastien Luttringer wrote: On 23/07/2014 15:59, Ido Rosen wrote: There's a PKGBUILD for ladvd and lldpd in AUR currently, these are important networking tools in data center environments. Can someone please promote at least one of them to [community] or ideally [extra]? They're not high on votes, but I think this should be an exception since not many people are using Arch in data center environments anyhow that would need them and would thus vote on them. They both implement LLDP daemons. I agree. I will move them. Cheers, lldpd is now in community. Looking deeper in lldp servers/agents capabilities, I came to the conclusion that including ladvd seems unnecessary. With this in mind: http://www.kempgen.net/voip/lldp-agents.html ladvd has no release since Feb 2012 and less features than lldpd. That's fair, thank you for packaging lldpd! I noticed RedHat no longer seems to package ladvd, and has switched to lldpad. Maybe we should package lldpad (aka Open-LLDP) from http://www.open-lldp.org/ ? Thoughts? Cheers, -- Sébastien Seblu Luttringer https://seblu.net GPG: 0x2072D77A
Re: [aur-general] Moving noip from [community] to AUR
On Sun, Aug 3, 2014 at 2:48 PM, Alexander Rødseth rods...@gmail.com wrote: Hi Ido, 2014-08-02 17:41 GMT+02:00 Ido Rosen i...@kernel.org: The noip client is GPL licensed F/OSS software (it's right there in the COPYING file in the tarball). Just because it connects to a commercial service does not mean it deserves to be removed from the official package repository. Take, for example, various GMail clients, Chromium (re:Google Sync and various google services), various AWS/EC2/S3 clients/libraries in [extra]/[community], etc. There were many reasons for moving noip from [community] to AUR. Not being open source was just one of many reasons, while you here present it as the sole reason, which is incorrect. Also keep in mind that TUs are not bound by rules regarding open source / commercial software, so ultimately, this does not matter. I addressed all of the reasons you listed in the order that you listed them in the email you're responding to... Additionally, while I don't use noip, some users want choices. The same users can still install noip from AUR or from the downloads provided by upstream. Would you remove vim just because emacs exists? You should not remove it on the grounds that there are alternatives. (Let's not make judgments on which is better - you wouldn't want to start a vim vs emacs debate here.) I think both vim and emacs qualifies, as opposed to noip. They are both popular (would result in many votes on AUR if they were not official packages), they are open source (which is not a requirement, but a plus) and they do not exist only to direct a stream of users and money toward a single company (also not a requirement, but a plus). They also offer pretty unique approaches to text editing (or did, when they were first released), as opposed to noip that does not offer a unique approach to dynamic IP adresses. (Having a unique or groundbreaking approach is also not a requirement, but a plus in my book). In addition to this, just by being a client that needs to connect to a commercial service (even though there is a repeatable 30 day free trial), it is not at all comparable to a standalone application like an editor. The first part of my reply addressed F/OSS packages that benefit a single company, such as those which interact with gmail, AWS/ec2, etc. Keeping these in the official repos is good, because it makes Arch more usable to a wider audience (i.e. users of that service). You're conflating the two lines of reasoning here. The paragraph you're responding to addresses your notion that just because there are better (by your judgment) alternatives to the package in question, it should be demoted to AUR. If that were sufficient reasoning to demote a package to AUR, you should demote emacs to AUR because vim exists, or ruby to AUR because python exists, or bash to AUR because zsh exists, etc. The point I'm trying to make is that your taste in what's a better alternative may differ from others', so if it doesn't cost much to support multiple alternatives for a certain service, doing so will make Arch more usable to a wider audience. If you are looking for a single official reason for why noip was moved from [community] to AUR, the answer is because an Arch Linux TU/dev did it. If you are interested in how I personally judged this particular situation, you may ask me why (as has been done in personal emails) and I may be kind enough to try to give a lengthy and honest answer (as I did), but I am not required to do so. And don't write do not do this. How about please do not do this? ;-) Let's not resort to because I said so just yet... If the real reason you want to move something to AUR is that you just don't want to maintain it / have better things to do with your time, that's perfectly okay! FWIW, I don't particularly care about noip, but your reasoning of because it benefits a single company rubbed me the wrong way, considering it is F/OSS software. Cheers, -Ido
Re: [aur-general] Moving noip from [community] to AUR
Do not do this. The noip client is GPL licensed F/OSS software (it's right there in the COPYING file in the tarball). Just because it connects to a commercial service does not mean it deserves to be removed from the official package repository. Take, for example, various GMail clients, Chromium (re:Google Sync and various google services), various AWS/EC2/S3 clients/libraries in [extra]/[community], etc. Additionally, while I don't use noip, some users want choices. Would you remove vim just because emacs exists? You should not remove it on the grounds that there are alternatives. (Let's not make judgments on which is better - you wouldn't want to start a vim vs emacs debate here.) Ido On Fri, Aug 1, 2014 at 5:26 AM, Alexander Rødseth rods...@gmail.com wrote: Hi, Some time ago I adopted the noip package. It's a GPL client that connects to what seems to be a commercial service offered by no-ip.com. The free service offered by them has a hostname that expires every 30 days. I am a bit surprised that this was an official package in the first place. When asking for opinions on IRC, there was support for moving the noip package to AUR. In addition to this, there seems to be several alternative clients, with slightly different versioning schemes. Both here: http://www.noip.com/download?page=linux and here: http://onevista.com/noip2.html. This confusion generated a low volume of out-of-date flags. It just smells bad. Moving it. -- Best regards, Alexander Rødseth / xyproto
[aur-general] Fwd: [Server/distributed Arch] nagios/nrpe - [community]
Hi all, I'd like to amend my previous request for lldpd and/or ladvd to be moved to [community] or [extra], and add these packages: nagios nagios-nrpe nagios-nrpe-plugin (?) nagios-nsca Again, there are not many people using Arch in data center environments, so the vote counts on these packages may be disproportionately smaller relative to their actual importance to the Arch community in terms of installed machines. We have a lot of work to do in order to make ArchLinux more friendly to administrate in large, distributed deployments such as globally distributed data centers out of the box in a supported/official. I'm looking forward to the day Arch can compete with RHEL/Fedora. Ido
[aur-general] no LLDP tools in [extra] or [community] :-/
There's a PKGBUILD for ladvd and lldpd in AUR currently, these are important networking tools in data center environments. Can someone please promote at least one of them to [community] or ideally [extra]? They're not high on votes, but I think this should be an exception since not many people are using Arch in data center environments anyhow that would need them and would thus vote on them. They both implement LLDP daemons.
Re: [aur-general] move sc and python2-mrjob to [community]
On Tue, Jul 22, 2014 at 4:09 PM, David Phillips dbphillip...@gmail.com wrote: but it's a problem if it has indeed not been updated since 2002 Simple question: why? I second David's point! Not all software needs updating. This is a simple, straightforward tool built on top of libraries that haven't changed much in the last decade.
[aur-general] move sc and python2-mrjob to [community]
Would it be possible to request that sc be promoted to [community] by one of you fine TUs? It doesn't change very often at all and it's a pretty handy tool. Additionally, while we're at it, an unrelated but very cool package, python2-mrjob? :-) I am not a TU, otherwise I would do it myself. Thanks, Ido On Sun, Jul 20, 2014 at 5:09 PM, Alexander Rødseth rods...@gmail.com wrote: Hi, No packages depends on iat (a utility for converting CD images). Upstream is gone and I could not find any forks of the project on the web. Removed. -- Best regards, Alexander Rødseth / xyproto
Re: [aur-general] move sc and python2-mrjob to [community]
While that is the latest year it was released, AFAIK, it doesn't seem to need maintenance, and is stable after several years of development. Either way, it's a good go-to CLI spreadsheet program and is included in several other distros. On Sun, Jul 20, 2014 at 5:34 PM, Sam Stuewe halosgh...@archlinux.info wrote: On 2014-07-20 16:31, Ido Rosen wrote: Would it be possible to request that sc be promoted to [community] by one of you fine TUs? It doesn't change very often at all and it's a pretty handy tool. Additionally, while we're at it, an unrelated but very cool package, python2-mrjob? :-) Is sc maintained anymore? I was under the impression that it actually hadn't been updated since 2002[1]. [1] http://ibiblio.org/pub/linux/apps/financial/spreadsheet/!INDEX.html -- All the best, Sam Stuewe (HalosGhost)
[aur-general] Move vagrant to [community]?
Hi, I maintain vagrant package in AUR. I believe vagrant is a very useful tool for ArchLinux users. I am happy to continue maintaining it in AUR; however, for the good of the community, it would be great if one of you TUs could move vagrant into [community] as soon as possible so it could get wider exposure. It currently has ~147 votes. Releases are infrequent, so it has been very easy to maintain overall. AUR package: https://aur.archlinux.org/packages/vagrant/ Upstream distribution website: http://www.vagrantup.com/ Also, if you'd like to make changes to the PKGBUILD in AUR, you can submit a pull request on GitHub: https://github.com/ido/packages-archlinux (under the aur/vagrant directory). Ido
Re: [aur-general] Move vagrant to [community]?
The official distribution is the RPM/DEB/binary distribution. The ruby-vagrant package is different - I don't believe it is based on vagrant-installers. If we wanted to not use the RPMs (which are very self-contained) but still have a low-maintenance way of packaging this, we could start here: https://github.com/mitchellh/vagrant-installers Ido On Fri, Feb 21, 2014 at 12:59 PM, Anatol Pomozov anatol.pomo...@gmail.comwrote: Hi On Fri, Feb 21, 2014 at 9:51 AM, Ido Rosen i...@kernel.org wrote: Hi, I maintain vagrant package in AUR. I believe vagrant is a very useful tool for ArchLinux users. I am happy to continue maintaining it in AUR; however, for the good of the community, it would be great if one of you TUs could move vagrant into [community] as soon as possible so it could get wider exposure. It currently has ~147 votes. Releases are infrequent, so it has been very easy to maintain overall. AUR package: https://aur.archlinux.org/packages/vagrant/ Upstream distribution website: http://www.vagrantup.com/ Also, if you'd like to make changes to the PKGBUILD in AUR, you can submit a pull request on GitHub: https://github.com/ido/packages-archlinux (under the aur/vagrant directory). I see that it uses *.rpm file as a source. Does this project have source repo? Is ruby-vagrant aur package (built from sources) the same as your package?
Re: [aur-general] Move vagrant to [community]?
Also, the source repo for vagrant itself is https://github.com/mitchellh/vagrant ... but I think the RPMs and other packaging is generated by https://github.com/mitchellh/vagrant-installers On Fri, Feb 21, 2014 at 1:32 PM, Ido Rosen i...@kernel.org wrote: The official distribution is the RPM/DEB/binary distribution. The ruby-vagrant package is different - I don't believe it is based on vagrant-installers. If we wanted to not use the RPMs (which are very self-contained) but still have a low-maintenance way of packaging this, we could start here: https://github.com/mitchellh/vagrant-installers Ido On Fri, Feb 21, 2014 at 12:59 PM, Anatol Pomozov anatol.pomo...@gmail.com wrote: Hi On Fri, Feb 21, 2014 at 9:51 AM, Ido Rosen i...@kernel.org wrote: Hi, I maintain vagrant package in AUR. I believe vagrant is a very useful tool for ArchLinux users. I am happy to continue maintaining it in AUR; however, for the good of the community, it would be great if one of you TUs could move vagrant into [community] as soon as possible so it could get wider exposure. It currently has ~147 votes. Releases are infrequent, so it has been very easy to maintain overall. AUR package: https://aur.archlinux.org/packages/vagrant/ Upstream distribution website: http://www.vagrantup.com/ Also, if you'd like to make changes to the PKGBUILD in AUR, you can submit a pull request on GitHub: https://github.com/ido/packages-archlinux (under the aur/vagrant directory). I see that it uses *.rpm file as a source. Does this project have source repo? Is ruby-vagrant aur package (built from sources) the same as your package?
[aur-general] delete lxc-docker
I maintain all of these deletion requested packages: Please delete lxc-docker [1], since docker is now in [community]. If it is possible to repoint lxc-docker-git to docker-git, please do that as well. Otherwise, please delete lxc-docker-git [2] or merge it into docker-git, which supersedes it. [1] https://aur.archlinux.org/packages/lxc-docker/ [2] https://aur.archlinux.org/packages/lxc-docker-git/ docker-git (latest, do not delete!): https://aur.archlinux.org/packages/docker-git/ Thanks, Ido
Re: [aur-general] Fwd: gnupg-largekeys in AUR
On Thu, Nov 28, 2013 at 10:49 AM, Jerome Leclanche adys...@gmail.comwrote: What's the outcome on this? I'm interested in large keys in default gnupg. That said, is there a reason why the patch isnt upstream yet? J. Leclanche It was rejected upstream previously a few times. If we want it, it has to be a patch on upstream in our gpg version. I believe the reasoning that allowing larger key sizes are a performance issue for mobile does not really apply here. Even gpg 2.1. dev is still limited to 4096: Line 1943, max=4096: http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=g10/keygen.c;h=4bb8bbaed4b27a977b3c2b543dafd335acb538df;hb=refs/heads/master#l6 Ido On Mon, Nov 4, 2013 at 3:12 AM, Ido Rosen i...@kernel.org wrote: Hi, I've added gnupg-largekeys, which is the gnupg from Core, but patched to extend the maximum key size to 65535 bits. Please note that unpatched versions of gnupg can only import/encrypt to/verify signatures of key sizes up to 16384 bits large, so you could keep your key sizes less than or equal to that size for compatibility. https://aur.archlinux.org/packages/gnupg-largekeys I think gnupg2-large-keys.patch would be a great addition into the Arch Core gnupg package, if not in its current form then at least modifying it to increase the max key size to 16384 instead of 65535. For some interesting numbers, take a look at http://www.ecrypt.eu.org/documents/D.SPA.20.pdf (especially Table 7.2, see 15424 bit RSA keys). Basically, it'd be nice for users to be able to create keys larger than 4096 bits. Cheers, Ido
Re: [aur-general] Fwd: gnupg-largekeys in AUR
On Thu, Nov 28, 2013 at 2:04 PM, Jerome Leclanche adys...@gmail.com wrote: On Thu, Nov 28, 2013 at 5:48 PM, Ido Rosen i...@kernel.org wrote: On Thu, Nov 28, 2013 at 10:49 AM, Jerome Leclanche adys...@gmail.com wrote: What's the outcome on this? I'm interested in large keys in default gnupg. That said, is there a reason why the patch isnt upstream yet? J. Leclanche It was rejected upstream previously a few times. If we want it, it has to be a patch on upstream in our gpg version. I believe the reasoning that allowing larger key sizes are a performance issue for mobile does not really apply here. That sounds like the kind of perfect use case for a compile-time option. J. Leclanche If you mean an upstream compile-time option (i.e. not in the PKGBUILD), I agree wholeheartedly. Now all we have to do is convince Werner Koch, which means emailing gnupg-users/gnupg-devel, or submitting a bug report with a patch (and a copyright assignment). Closed bugs related to this are: https://bugs.g10code.com/gnupg/issue1441 https://bugs.g10code.com/gnupg/issue1460 FWIW, the pattern in upstream seems to be that anyone who suggests a larger max key size gets told no for a few years, and then it happens anyway. That is, if you can call 2 data points (2048, then 4096) a pattern...
Re: [aur-general] Fwd: gnupg-largekeys in AUR
Patch submitted. I hope it gets accepted... :-/ https://bugs.g10code.com/gnupg/issue1573 On Thu, Nov 28, 2013 at 3:09 PM, Ido Rosen i...@kernel.org wrote: On Thu, Nov 28, 2013 at 2:04 PM, Jerome Leclanche adys...@gmail.com wrote: On Thu, Nov 28, 2013 at 5:48 PM, Ido Rosen i...@kernel.org wrote: On Thu, Nov 28, 2013 at 10:49 AM, Jerome Leclanche adys...@gmail.comwrote: What's the outcome on this? I'm interested in large keys in default gnupg. That said, is there a reason why the patch isnt upstream yet? J. Leclanche It was rejected upstream previously a few times. If we want it, it has to be a patch on upstream in our gpg version. I believe the reasoning that allowing larger key sizes are a performance issue for mobile does not really apply here. That sounds like the kind of perfect use case for a compile-time option. J. Leclanche If you mean an upstream compile-time option (i.e. not in the PKGBUILD), I agree wholeheartedly. Now all we have to do is convince Werner Koch, which means emailing gnupg-users/gnupg-devel, or submitting a bug report with a patch (and a copyright assignment). Closed bugs related to this are: https://bugs.g10code.com/gnupg/issue1441 https://bugs.g10code.com/gnupg/issue1460 FWIW, the pattern in upstream seems to be that anyone who suggests a larger max key size gets told no for a few years, and then it happens anyway. That is, if you can call 2 data points (2048, then 4096) a pattern...
Re: [aur-general] docker v. docker
Hi, I'm the maintainer of lxc-docker and lxc-docker-git in AUR. I'd love to rename it to docker! The current extra/docker can be renamed to docker-tray or something similar? On Tue, Nov 26, 2013 at 10:00 AM, Jerome Leclanche adys...@gmail.comwrote: extra/docker is currently a very old system tray app for openbox2, kde3 and gnome2. It hasn't been updated in a very, very long time. docker (https://www.docker.io/) on the other hand, is a widely used and current container solution. As of 0.7, it's now available on all distributions (previously was only available on ubuntu). There will be a naming conflict between the two very soon. I would be in favour of renaming extra/docker preemptively since it hasn't been updated in a decade. J. Leclanche
Re: [aur-general] docker v. docker
I really don't care either way, but (a) lxc-docker is more descriptive of what docker actually is than docker-io; and (b) the Docker website/installation documentation for ArchLinux already points to lxc-docker and lxc-docker-git... It's not worth changing names unless it's for plain old docker. :-) Either way, version 0.7.0 was just released and I've updated lxc-docker to it. As of this version, lxc-docker no longer needs a custom aufs-friendly kernel and should have no AUR dependencies. If you so desire, it can now be fast-tracked into [community] or [extra] if possible, and while you're add it put vagrant in there as well. :-) PKGBUILDs, etc. are maintained in my git repo: https://github.com/ido/packages-archlinux in the aur directory. If there are any changes that need to be made to it, let me know or send a pull request. In AUR, lxc-docker-git now points to the master branch installation from source/git, and lxc-docker points to the binary (recommended) installation mechanism from the website. lxc-docker-git needs further work to comply with the recommended docker build instructions (which are to build docker inside of docker), but it builds a working binary at the moment. On Tue, Nov 26, 2013 at 10:07 AM, Joseph Hall perlho...@gmail.com wrote: FWIW, Red Hat calls their package docker-io. If renaming the old system tray app isn't an option, then perhaps docker-io is an option. On Tue, Nov 26, 2013 at 8:00 AM, Jerome Leclanche adys...@gmail.com wrote: extra/docker is currently a very old system tray app for openbox2, kde3 and gnome2. It hasn't been updated in a very, very long time. docker (https://www.docker.io/) on the other hand, is a widely used and current container solution. As of 0.7, it's now available on all distributions (previously was only available on ubuntu). There will be a naming conflict between the two very soon. I would be in favour of renaming extra/docker preemptively since it hasn't been updated in a decade. J. Leclanche -- In order to create, you have to have the willingness, the desire to be challenged, to be learning. -- Ferran Adria (speaking at Harvard, 2011)
[aur-general] Fwd: deletion request: vagrant-bin
Hi, please remove vagrant-bin, it's a duplicate of vagrant. https://aur.archlinux.org/packages/vagrant-bin
Re: [aur-general] Backslash to split lines in `depends` array
This is a bug in aura's array parsing logic, which is in Bash/Parser.hs
line :
array :: Parser [BashString]
array = concat . catMaybes $ array' ? valid array
where array' = char '(' * spaces * manyTill single' (char ')')
single' = (Nothing $ comment * spaces) | (Just $ single)
...and is missing backslash ('\\') support and is overly simplistic.
See for comparison the command parser in the same file (which has
backslash support):
command :: Parser Field
command = spaces * (Command $ many1 commandChar * option [] (try args))
where commandChar = alphaNum | oneOf ./
args = char ' ' unwords $ line = \ls -
case parse (many1 single) (command) ls of
Left _ - fail Failed parsing strings in a command
Right bs - return $ concat bs
line = (:) $ many (noneOf \n\\) * next
next = ([] $ char '\n') | (char '\\' * spaces * line)
On Sun, Nov 3, 2013 at 8:09 AM, Frederik Freso S. Olesen
freso...@gmail.com wrote:
Den 03-11-2013 13:29, Fabien Dubosson skrev:
[...] So before filling a
bug request to `aura`, I wanted to be sure that it is allowed/common to
use
`\` to split lines in the `depends` array?
For some more in-depth information than Rafael's commanding comment:
1) the \ character followed by a newline is used for breaking up long
lines in (ba)sh code. The $depends array is thus perfectly valid bash, and
I would file a bug report against aura to either make it not error - or at
least change it to a warning, since:
2) there's no need to escape the newline in the $depends array, as
newlines will just be treated like other whitespace until the array
definition is ended by the ) character, thus I would *also* do as Rafael
suggested and ask the octave-hg to remove the backslash.
--
Frederik Freso S. Olesen http://freso.dk/
[aur-general] Fwd: gnupg-largekeys in AUR
Hi, I've added gnupg-largekeys, which is the gnupg from Core, but patched to extend the maximum key size to 65535 bits. Please note that unpatched versions of gnupg can only import/encrypt to/verify signatures of key sizes up to 16384 bits large, so you could keep your key sizes less than or equal to that size for compatibility. https://aur.archlinux.org/packages/gnupg-largekeys I think gnupg2-large-keys.patch would be a great addition into the Arch Core gnupg package, if not in its current form then at least modifying it to increase the max key size to 16384 instead of 65535. For some interesting numbers, take a look at http://www.ecrypt.eu.org/documents/D.SPA.20.pdf (especially Table 7.2, see 15424 bit RSA keys). Basically, it'd be nice for users to be able to create keys larger than 4096 bits. Cheers, Ido
Re: [aur-general] Support for source mirror lists in PKGBUILD
On Fri, Nov 1, 2013 at 3:27 PM, alexande...@gmx.com wrote: On Fri, Nov 01, 2013 at 12:14:25PM -0400, Ido Rosen wrote: If metalinks/some external file are the only way to do this, you would need a local source entry for the metalink / mirrors file AND a reference to each file to pull from that metalink/mirrors file in the source array This is obviously incorrect. Please re-read your message, so that no one has to waste more breath. I've submitted a patch for the mirror idea that follows Jerome's way of doing it, which Florian modified and sent over to pacman-dev. If you want it done differently, submit a patch to help make pacman better rather than making toxic comments, you'll alienate less peers that way. :-) The point that perhaps I wasn't making clearly (or verbosely) enough was that in the current implementation of makepkg, adding the metalink/.mirrors file to the source array then downloading it in prepare() as you yourself suggested does involve having those files as local files (download_local() in makepkg.sh.in) in the PKGBUILD and then referring to them again in the PKGBUILD, on top of having to understand the metalink format or a new .mirrors format (as opposed to a simple additional array entry as was Jerome's suggestion). The result is that the reader must understand those extra file formats and must go somewhere outside of the PKGBUILD to understand where downloaded files are coming from. This would be the case if metalinks/a separate file were the only or primary mechanism for supporting mirroring. For the common case I brought up, where there are 2 or 3 mirrors for the primary source file(s), metalinks/a new .mirrors file format seems overly complex to me. It also is less KISS than just having multiple source array entries for a mirrored file, since the packager and the person reading the package now need to understand another file format to parse out where the file is coming from. I'm not opposed to adding metalink, torrent, carrier pigeon, and sneakernet support to DLAGENTS by default You are the one, who wants metalink, torrent, carrier pigeon, and sneakernet support to be implemented in pure Bash as part of makepkg. With numerous mirrors and Nice straw man. You were the one who suggested metalinks; I said I don't care either way if they're implemented or not (i.e. it is not a vote for or against their implementation... What I said in the paragraphs you misquoted is that I'm neutral to whether the extra DLAGENTs like metalinks, torrents, etc. are implemented or not, and that this is a separate issue. Jerome's proposal is a simpler and more KISS way of solving the common use case / problem that I was trying to solve: mirror A is down for a file may be downloaded from mirrors A or B. sofisticated source arrays, cluttering PKGBUILD source, nobody would indeed be able to understand, what's going on in it's prepare() or build() functions. Obviously, fell free to do something like that yourself; all you need is to re-define prepare() to do whatever you want. Just don't advertise that as something, great enough to become the standard. I did like Jerome's suggestion, which was different and simpler than my original suggestion of supporting sources as an associative array. That's why I implemented it and sent it to Florian. The only change that patch makes is that now makepkg aborts at the end of trying to download all the files rather than after the first failed download, and treats source entries with duplicate filenames as equivalents/interchangeable/mirrors. To put it more simply: source=(http://a.com/file.tar.gz; http://b.com/file.tar.gz;) ^ now makepkg recognizes these as mirrors of file.tar.gz, and will only abort if *both* (rather than either) fail to download file.tar.gz. Cheers, Ido -- My AUR packages - https://aur.archlinux.org/packages.php?SeB=mK=AlexanderR
Re: [aur-general] Support for source mirror lists in PKGBUILD
On Fri, Nov 1, 2013 at 7:21 AM, Rashif Ray Rahman sc...@archlinux.orgwrote: On 1 November 2013 18:58, alexande...@gmx.com wrote: Are you trying tio re-implement Metalinks? They have become standartized way to do what you want ages ago. They are even supported by curl! Add metalink file to package (or reference one from upstream), redefine DLAGENTS to something like 'metalink::/usr/bin/curl --metalink %u' and, if possible, convince makepkg developers to add that DLAGENT to default makepkg.conf. Voilà, no one's KISS principles violated. IMHO, this sounds better than a buildscript full of hyperlinks. Alternative mirrors should be an optional feature. I'd even go as far as to suggest just having a .mirrors file (lowercase to differentiate it from pacman files) with a list of optional locations for each source, while adding a bit of code to makepkg to go through the list if the primary source locations fail for whatever reason. But that's my uninformed opinion. -- GPG/PGP ID: C0711BF1 If metalinks/some external file are the only way to do this, you would need a local source entry for the metalink / mirrors file AND a reference to each file to pull from that metalink/mirrors file in the source array: (1) This breaks something conceptually to me, since the PKGBUILD is no longer the self-contained descriptor of where to get everything and how to put it all together into the package, now you need this other file or that other file at download-time (rather than just at prepare()/build()/package() time). (2) It also is less KISS than just having multiple source array entries for a mirrored file, since the packager and the person reading the package now need to understand another file format to parse out where the file is coming from. (3) Since there are extra files you're carrying along and it's not clear that those files are only needed at prepare() or build() time, now they're needed at initial download time, and the ordering of the source array becomes important, since you need the metalink/mirrors local file before the metalink link itself... I'm not opposed to adding metalink, torrent, carrier pigeon, and sneakernet support to DLAGENTS by default, but the simple mirror case that solves this 99% of the time (file A can come from locations X or Y) is trivially and more KISS-ably solved by having two entries for file A in the source array...
[aur-general] lxc-docker-git / maci
Hi y'all, I can't seem to reach AUR user maci who maintains lxc-docker-git: his email domain (satgnu.org) has an MX record that points to satgnu.org as the mail server, but satgnu.org has no A record. This is the second message I've tried sending over the last couple of weeks. Please disown lxc-docker-git so I can adopt it. If he wants it back later, he can email me and I'll disown it and let him adopt it again. Thanks, Ido -- Forwarded message -- From: Mail Delivery Subsystem mailer-dae...@googlemail.com Date: Thu, Oct 31, 2013 at 3:32 AM Subject: Delivery Status Notification (Delay) To: iro...@gmail.com This is an automatically generated Delivery Status Notification THIS IS A WARNING MESSAGE ONLY. YOU DO NOT NEED TO RESEND YOUR MESSAGE. Delivery to the following recipient has been delayed: m...@satgnu.org Message will be retried for 2 more day(s) Technical details of temporary failure: DNS Error: DNS server returned answer with no data
[aur-general] Support for source mirror lists in PKGBUILD
Hi everyone,
What's the current recommended way to support multiple mirrors for the
same source file in a PKGBUILD? For example, I have xyz-123.tar.gz that
can be downloaded from any of http://a.example.com/xyz-123.tar.gz;
http://b.example.com/xyz-123.tar.gz;
http://c.example.com/xyz-123.tar.gz...but
one of these may be down at any given time.
If there's no support for this in the sources array itself, we should
strongly consider adding it. For example, an ad-hoc way:
_pick_source_mirror() {
# ... do something smart in here
}
source=(
xyz-123::$(_pick_source_mirror(
http://a.example.com/xyz-123.tar.gz
http://b.example.com/xyz-123.tar.gz
http://c.example.com/xyz-123.tar.gz
))
)
A less ad-hoc way:
source() {
#...some code that returns a list of URLs/files
}
Another way:
source=(...files without mirrors as usual...)
sourcemirrored=( xyz-123::($mirroraURL $mirrorbURL $mirrorcURL) )
Mirrored sources seem like a common enough phenomenon that it's worth
special treatment to make the source PKGBUILD variable more versatile if
they're not currently supported. Thoughts?
Ido
Re: [aur-general] lxc-docker-git / maci
Please disown python2-sphinxcontrib-httpdomain2 for the same reason: https://aur.archlinux.org/packages/python2-sphinxcontrib-httpdomain2/ On Thu, Oct 31, 2013 at 12:21 PM, Felix Yan felixonm...@gmail.com wrote: On Thursday, October 31, 2013 11:48:47 Ido Rosen wrote: Hi y'all, I can't seem to reach AUR user maci who maintains lxc-docker-git: his email domain (satgnu.org) has an MX record that points to satgnu.org as the mail server, but satgnu.org has no A record. This is the second message I've tried sending over the last couple of weeks. Please disown lxc-docker-git so I can adopt it. If he wants it back later, he can email me and I'll disown it and let him adopt it again. Thanks, Ido Disowned. Please include a link to package next time, thanks. Regards, Felix Yan
Re: [aur-general] Support for source mirror lists in PKGBUILD
That would be good too, don't know why I didn't think about that simple
solution. :-)
On Thu, Oct 31, 2013 at 4:32 PM, Jerome Leclanche adys...@gmail.com wrote:
On Thu, Oct 31, 2013 at 5:46 PM, Ido Rosen i...@kernel.org wrote:
Hi everyone,
What's the current recommended way to support multiple mirrors for the
same source file in a PKGBUILD? For example, I have xyz-123.tar.gz that
can be downloaded from any of http://a.example.com/xyz-123.tar.gz;
http://b.example.com/xyz-123.tar.gz;
http://c.example.com/xyz-123.tar.gz...but
one of these may be down at any given time.
If there's no support for this in the sources array itself, we should
strongly consider adding it. For example, an ad-hoc way:
_pick_source_mirror() {
# ... do something smart in here
}
source=(
xyz-123::$(_pick_source_mirror(
http://a.example.com/xyz-123.tar.gz
http://b.example.com/xyz-123.tar.gz
http://c.example.com/xyz-123.tar.gz
))
)
A less ad-hoc way:
source() {
#...some code that returns a list of URLs/files
}
Another way:
source=(...files without mirrors as usual...)
sourcemirrored=( xyz-123::($mirroraURL $mirrorbURL $mirrorcURL) )
Mirrored sources seem like a common enough phenomenon that it's worth
special treatment to make the source PKGBUILD variable more versatile if
they're not currently supported. Thoughts?
Ido
What about reusing the filename feature; if it sees multiple times
the same files it treats it as a mirror, eg.
file.tar.gz::http://example.com/file.tar.gz;
file.tar.gz::http://mirror.example.com/file.tar.gz;
J. Leclanche
Re: [aur-general] Support for source mirror lists in PKGBUILD
On Thu, Oct 31, 2013 at 4:45 PM, Dave Reisner d...@falconindy.com wrote: On Thu, Oct 31, 2013 at 08:32:49PM +, Jerome Leclanche wrote: What about reusing the filename feature; if it sees multiple times the same files it treats it as a mirror, eg. file.tar.gz::http://example.com/file.tar.gz; file.tar.gz::http://mirror.example.com/file.tar.gz; J. Leclanche This can't work. If the first source fails to download, makepkg will abort. What about just detecting if source is an array/list (keep current behavior), or a dictionary/lookup table (new fancy mirror behavior)? If it's a dictionary/lookup table, then try all mirrors before failing a source download. For examples of how to create lookup tables in bash, see http://stackoverflow.com/questions/1494178/how-to-define-hash-tables-in-bash...
Re: [aur-general] Support for source mirror lists in PKGBUILD
On Thu, Oct 31, 2013 at 4:51 PM, Ido Rosen i...@kernel.org wrote: On Thu, Oct 31, 2013 at 4:45 PM, Dave Reisner d...@falconindy.com wrote: On Thu, Oct 31, 2013 at 08:32:49PM +, Jerome Leclanche wrote: What about reusing the filename feature; if it sees multiple times the same files it treats it as a mirror, eg. file.tar.gz::http://example.com/file.tar.gz; file.tar.gz::http://mirror.example.com/file.tar.gz; J. Leclanche This can't work. If the first source fails to download, makepkg will abort. What about just detecting if source is an array/list (keep current behavior), or a dictionary/lookup table (new fancy mirror behavior)? If it's a dictionary/lookup table, then try all mirrors before failing a source download. For examples of how to create lookup tables in bash, see http://stackoverflow.com/questions/1494178/how-to-define-hash-tables-in-bash... Just to be clear, I meant a dictionary/lookup table of strings or list values, e.g.: source=( [file.tar.gz]=(http://a.com/file.tar.gz; http://b.com/file.tar.gz;) ) # would indicate file.tar.gz has 2 mirror URLs.
Re: [aur-general] Support for source mirror lists in PKGBUILD
On Thu, Oct 31, 2013 at 6:18 PM, Florian Pritz bluew...@xinu.at wrote:
On 31.10.2013 22:12, Ido Rosen wrote:
Okay, that leaves either Jerome's suggestion (if duplicate filenames are
detected, treat them as mirrors and don't fail/abort as long as one of
them
works);
I'd go with that. Doesn't add any new syntax and can be created easily
enough like this:
source=($pkgname-$pkgver.tar.gz::{http://foo.com/blub/,;
http://somewhere.com/}$pkgname-$pkgver.tar.gz;)
Should be as simple as looping of the sources array after a fail and
checking if there is another matching filename:: element.
Care to submit a patch to pacman-dev?
It looks like a major structural change, since the exit 1 is deep inside
each download_{file,git,bzr,...} function definition in makepkg.sh.in in
the pacman git repo: For example the one for download_file() in
makepkg.sh.in line 379 would probably move up to the download_sources()
function, and return 1 instead of exit 1, then the return code would be
checked, etc...
If my first pacman patch is going to be this big of a change to
makepkg.sh.in I'd feel a lot more comfortable if an existing pacman/makepkg
dev were available off-list via email or IM for some brain-picking. Any
volunteers?
Ido
Re: [aur-general] Support for source mirror lists in PKGBUILD
Here is my POC. It should work for remote files (URLs), local files, VCS repos, and across different types (e.g. if you want to offer git and hg mirrors of a repo). Totally untested. Feel free to change it if it's broken and take all the credit and submit to pacman-dev. :) Ido On Thu, Oct 31, 2013 at 7:20 PM, Florian Pritz bluew...@xinu.at wrote: On 31.10.2013 23:30, Ido Rosen wrote: If my first pacman patch is going to be this big of a change to makepkg.sh.in I'd feel a lot more comfortable if an existing pacman/makepkg dev were available off-list via email or IM for some brain-picking. Any volunteers? Got a poc for a rather simple way of implementing it, not sure if it's going to be pretty enough. I'll take a closer look tomorrow. Feel free to ping me via irc, mail or jabber [1]. [1]: https://www.archlinux.org/developers/#bluewind
Re: [aur-general] Support for source mirror lists in PKGBUILD
Oops, looks like the attachment didn't make it. Here's the patch pasted:
From bf4b5a6b531e2e9ec629907426ddf854735c649e Mon Sep 17 00:00:00 2001
From: Ido Rosen c...@idorosen.com
Date: Thu, 31 Oct 2013 19:50:46 -0400
Subject: [PATCH] Added mirror support to makepkg's source array.
To specify multiple mirrors, simply add multiple files to the source array
that have the same downloaded filename, e.g.:
source=(file.tar.gz::http://mirror1.example.com/file.tar.gz;
file.tar.gz::http://mirror2.example.com/file.tar.gz;)
...makepkg will try them all, and if all fail, will abort. This also
applies
to VCS repositories and local files references in the source array, so for
example:
source=(git+
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git;
git+
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git;)
...will allow cloning the git repository from GitHub if kernel.org is down
or
fails.
---
scripts/makepkg.sh.in | 73
+++
1 file changed, 45 insertions(+), 28 deletions(-)
diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in
index 4cb8173..2fe43cf 100644
--- a/scripts/makepkg.sh.in
+++ b/scripts/makepkg.sh.in
@@ -326,7 +326,7 @@ download_local() {
else
local filename=$(get_filename $netfile)
error $(gettext %s was not found in the build directory and is not a
URL.) $filename
- exit 1 # $E_MISSING_FILE
+ return 1 # $E_MISSING_FILE
fi
}
@@ -375,8 +375,7 @@ download_file() {
if (( ret )); then
[[ ! -s $dlfile ]] rm -f -- $dlfile
error $(gettext Failure while downloading %s) $filename
- plain $(gettext Aborting...)
- exit 1
+ return 1
fi
# rename the temporary download file to the final destination
@@ -460,8 +459,7 @@ download_bzr() {
msg2 $(gettext Branching %s ...) ${displaylocation}
if ! bzr branch $url $dir --no-tree --use-existing-dir; then
error $(gettext Failure while branching %s) ${displaylocation}
- plain $(gettext Aborting...)
- exit 1
+ return 1
fi
elif (( ! HOLDVER )); then
# Make sure we are fetching the right repo
@@ -470,15 +468,13 @@ download_bzr() {
if [[ -n $distant_url ]]; then
if [[ $distant_url != $local_url ]]; then
error $(gettext %s is not a branch of %s) $dir $url
- plain $(gettext Aborting...)
- exit 1
+ return 1
fi
else
if [[ $url != $local_url ]] ; then
error $(gettext %s is not a branch of %s) $dir $url
error $(gettext The local URL is %s) $local_url
- plain $(gettext Aborting...)
- exit 1
+ return 1
fi
fi
msg2 $(gettext Pulling %s ...) ${displaylocation}
@@ -545,16 +541,14 @@ download_git() {
msg2 $(gettext Cloning %s %s repo...) ${repo} git
if ! git clone --mirror $url $dir; then
error $(gettext Failure while downloading %s %s repo) ${repo} git
- plain $(gettext Aborting...)
- exit 1
+ return 1
fi
elif (( ! HOLDVER )); then
cd_safe $dir
# Make sure we are fetching the right repo
if [[ $url != $(git config --get remote.origin.url) ]] ; then
error $(gettext %s is not a clone of %s) $dir $url
- plain $(gettext Aborting...)
- exit 1
+ return 1
fi
msg2 $(gettext Updating %s %s repo...) ${repo} git
if ! git fetch --all -p; then
@@ -634,8 +628,7 @@ download_hg() {
msg2 $(gettext Cloning %s %s repo...) ${repo} hg
if ! hg clone -U $url $dir; then
error $(gettext Failure while downloading %s %s repo) ${repo} hg
- plain $(gettext Aborting...)
- exit 1
+ return 1
fi
elif (( ! HOLDVER )); then
msg2 $(gettext Updating %s %s repo...) ${repo} hg
@@ -673,15 +666,13 @@ extract_hg() {
;;
*)
error $(gettext Unrecognized reference: %s) ${fragment}
- plain $(gettext Aborting...)
- exit 1
+ return 1
esac
fi
if ! hg clone ${ref[@]} $dir ${dir##*/}; then
error $(gettext Failure while creating working copy of %s %s repo)
${repo} hg
- plain $(gettext Aborting...)
- exit 1
+ return 1
fi
popd /dev/null
@@ -711,8 +702,7 @@ download_svn() {
mkdir -p $dir/.makepkg
if ! svn checkout --config-dir $dir/.makepkg $url $dir; then
error $(gettext Failure while downloading %s %s repo) ${repo} svn
- plain $(gettext Aborting...)
- exit 1
+ return 1
fi
elif (( ! HOLDVER )); then
msg2 $(gettext Updating %s %s repo...) ${repo} svn
@@ -776,34 +766,61 @@ download_sources() {
GET_VCS=0
fi
+ declare -A downloaded # local since no -g supplied to declare.
+ declare -A expected # local since no -g supplied to declare.
local netfile
for netfile in ${source[@]}; do
pushd $SRCDEST /dev/null
+ local filepath=$(get_filepath ${netfile})
+ expected[${filepath}]=1
+ if [[ ${downloaded[${filepath}]} ]]; then
+ msg $(gettext Skipping mirror: %s) $netfile
+ continue # file already downloaded, current mirror is redundant.
+ fi
local proto=$(get_protocol $netfile)
case $proto in
local)
- download_local $netfile
+ download_local $netfile \
+ downloaded[${filepath}]=1
;;
bzr*)
- (( GET_VCS )) download_bzr $netfile
+ (( GET_VCS )) download_bzr $netfile \
+ downloaded[${filepath}]=1
;;
git
Re: [aur-general] Revise VCS packages versioning
Anatol, Doug, I do not propose to remove pkgver(). What I say is that vcs version generator becomes non-trivial and many people use different and inconsistent VCS versions. It indicates that there should be some standard way to generate version. If you don't want to use the standard generator you can use your own command to generate the version. But at least the standard generator will show how version should look like (e.g. r prefix or not, what delimiter should be used, etc) If you want the r, add it. If not, don't. I don't see the problem. To be very blunt, if you can't figure out basic scripting enough to write a coherent pkgver function, you don't really have any business maintaining PKGBUILDs. Please more respect, this is a public discussion. I'm well aware that it's a public discussion, but I'm not going to sugar coat things to protect other's feelings. Bash can be complex, but basic scripting isn't difficult. If you're going to be maintain PKGBUILDs without a grasp of the basics, you're being set up to fail from the get go. My reading of Anatol's post does not convey any lack of understanding of the basics of shell scriptings. I think you are misreading his original post, and responding ad hominem as a result of that misunderstanding. I read Anatol's original post as please consider adding an optional convenience function that will handle the git describe / bzr revno / etc. for the packager and provide a sane default, while still allowing people to not use that function if they don't want to use it or if the git tag format doesn't play nicely with it. This seems like a reasonable suggestion: 99% of VCS packages have a simple pattern: strip the preceding letters up to the first number of some git describe or bzr branch name/revno string, then add the # of commits in this branch, then add the hash. Why not provide a convenience function to cover that? I agree with Doug that it's not a good idea, and here is the reasoning: (1) It's a write-once convenience function. If some developer changes the function upstream, it has the potential to break MANY VCS packages all at once, which would be very bad, so it is better for each VCS PKGBUILD to write its pkgver() specific to its own repository's organization/versioning (strong argument). (2) It's just extra baggage to carry for what is, for the most part, a one-liner in VCS packages right now (weak argument). (3) It encourages lazy VCS packagers (weak argument). Anatol, even though I disagree with you, it was a worthwhile suggestion. Thanks, Ido
Re: [aur-general] disown request: haskell-platform
Also, the maintainer's (weox) email is bouncing - that AUR account should probably be inactive/disabled as well. Delivery to the following recipient failed permanently: weox...@gmail.com Technical details of permanent failure: The email account that you tried to reach does not exist. Please try double-checking the recipient's email address for typos or unnecessary spaces. Learn more at http://support.google.com/mail/bin/answer.py?answer=6596 On Wed, Oct 23, 2013 at 8:20 PM, Daniel Spies daniel.sp...@fuceekay.comwrote: Hi, please disown haskell-platform: https://aur.archlinux.org/**packages/haskell-platform/https://aur.archlinux.org/packages/haskell-platform/ The package has been flagged out-of-date on 2012-11-06 and has not been updated by the maintainer since. Thanks, Daniel
Re: [aur-general] Support for remote sums in PKGBUILDs
s/possible/possibly/ s/checksum in there/checksum in the PKGBUILD as usual/ On Mon, Oct 21, 2013 at 10:19 PM, Ido Rosen i...@kernel.org wrote: - Do PKGBUILDs support signing the PKGBUILD and verifying that signature? (This seems like a good feature for yaourt or possible makepkg if it isn't one already.) It seems like if you want safety from MITM attacks, PGP sigs are the way to go, either sign the PKGBUILD and put the checksum in there, or include the signature of the source file in the tarball/pkg. (This is already provided for binary pkgs, but not source ones, correct? Seems easy enough to add a PKGBUILD signature and teach makepkg to use it.) On Mon, Oct 21, 2013 at 10:13 PM, Doug Newgard scimmi...@outlook.comwrote: From: adys...@gmail.com Date: Tue, 22 Oct 2013 01:56:16 +0100 To: aur-general@archlinux.org Subject: [aur-general] Support for remote sums in PKGBUILDs Breaking away from an IRC convo from this morning; has support for remote sums been considered for pacman? It's currently possible to do this for .sig files (through the source array), but not available for simple sha/md5 hashes. This would let packagers do something like: source=(http://example.com/downloads/$pkgname-$pkgver.tar.xz;) sha1sums=(http://example.com/downloads/$pkgname-$pkgver.tar.xz.sha1;) (Of course, only for servers that generate a programmatically discoverable hash of some sort; but it's not actually uncommon) J. Leclanche Couldn't you just do: sha1sums=($(curl http://example.com/downloads/$pkgname-$pkgver.tar.xz.sha1)) It kind of defeats the purpose, though. If the server is hacked or someone does a MitM, they can easily replace the checksum file as well.
Re: [aur-general] Support for remote sums in PKGBUILDs
It'd be nice to have as an option - especially since the key fingerprint is easy to look up on the AUR website. Then tools like yaourt or makepkg can alert you when the keyID of the sig, for example, differs from the one that signed the currently installed version during an upgrade, as a means of allowing for integrity continuity. (There are other things that could be done with this feature, but this is a useful one from a MITM standpoint, so at least you know the new PKGBUILD is from the same author as the old PKGBUILD your pkg was generated from, for example.) On Mon, Oct 21, 2013 at 10:40 PM, Doug Newgard scimmi...@outlook.comwrote: Date: Mon, 21 Oct 2013 22:19:32 -0400 From: i...@kernel.org To: aur-general@archlinux.org Subject: Re: [aur-general] Support for remote sums in PKGBUILDs - Do PKGBUILDs support signing the PKGBUILD and verifying that signature? (This seems like a good feature for yaourt or possible makepkg if it isn't one already.) It seems like if you want safety from MITM attacks, PGP sigs are the way to go, either sign the PKGBUILD and put the checksum in there, or include the signature of the source file in the tarball/pkg. (This is already provided for binary pkgs, but not source ones, correct? Seems easy enough to add a PKGBUILD signature and teach makepkg to use it.) On Mon, Oct 21, 2013 at 10:13 PM, Doug Newgard scimmi...@outlook.com wrote: From: adys...@gmail.com Date: Tue, 22 Oct 2013 01:56:16 +0100 To: aur-general@archlinux.org Subject: [aur-general] Support for remote sums in PKGBUILDs Breaking away from an IRC convo from this morning; has support for remote sums been considered for pacman? It's currently possible to do this for .sig files (through the source array), but not available for simple sha/md5 hashes. This would let packagers do something like: source=(http://example.com/downloads/$pkgname-$pkgver.tar.xz;) sha1sums=(http://example.com/downloads/$pkgname-$pkgver.tar.xz.sha1;) (Of course, only for servers that generate a programmatically discoverable hash of some sort; but it's not actually uncommon) J. Leclanche Couldn't you just do: sha1sums=($(curl http://example.com/downloads/$pkgname-$pkgver.tar.xz.sha1)) It kind of defeats the purpose, though. If the server is hacked or someone does a MitM, they can easily replace the checksum file as well. Let's be realistic here, you're not going to get all of the PKGBUILDs in the AUR signed with PGP.
Re: [aur-general] Support for remote sums in PKGBUILDs
(Just an additional implementation detail, but this would mean the verified keyID/fingerprint on the PKGBUILD that generated the pkg gets included in the pkg somehow, not that the pkg needs to be signed by the same key as the PKGBUILD was.) On Mon, Oct 21, 2013 at 10:44 PM, Ido Rosen i...@kernel.org wrote: It'd be nice to have as an option - especially since the key fingerprint is easy to look up on the AUR website. Then tools like yaourt or makepkg can alert you when the keyID of the sig, for example, differs from the one that signed the currently installed version during an upgrade, as a means of allowing for integrity continuity. (There are other things that could be done with this feature, but this is a useful one from a MITM standpoint, so at least you know the new PKGBUILD is from the same author as the old PKGBUILD your pkg was generated from, for example.) On Mon, Oct 21, 2013 at 10:40 PM, Doug Newgard scimmi...@outlook.comwrote: Date: Mon, 21 Oct 2013 22:19:32 -0400 From: i...@kernel.org To: aur-general@archlinux.org Subject: Re: [aur-general] Support for remote sums in PKGBUILDs - Do PKGBUILDs support signing the PKGBUILD and verifying that signature? (This seems like a good feature for yaourt or possible makepkg if it isn't one already.) It seems like if you want safety from MITM attacks, PGP sigs are the way to go, either sign the PKGBUILD and put the checksum in there, or include the signature of the source file in the tarball/pkg. (This is already provided for binary pkgs, but not source ones, correct? Seems easy enough to add a PKGBUILD signature and teach makepkg to use it.) On Mon, Oct 21, 2013 at 10:13 PM, Doug Newgard scimmi...@outlook.com wrote: From: adys...@gmail.com Date: Tue, 22 Oct 2013 01:56:16 +0100 To: aur-general@archlinux.org Subject: [aur-general] Support for remote sums in PKGBUILDs Breaking away from an IRC convo from this morning; has support for remote sums been considered for pacman? It's currently possible to do this for .sig files (through the source array), but not available for simple sha/md5 hashes. This would let packagers do something like: source=(http://example.com/downloads/$pkgname-$pkgver.tar.xz;) sha1sums=(http://example.com/downloads/$pkgname-$pkgver.tar.xz.sha1 ) (Of course, only for servers that generate a programmatically discoverable hash of some sort; but it's not actually uncommon) J. Leclanche Couldn't you just do: sha1sums=($(curl http://example.com/downloads/$pkgname-$pkgver.tar.xz.sha1)) It kind of defeats the purpose, though. If the server is hacked or someone does a MitM, they can easily replace the checksum file as well. Let's be realistic here, you're not going to get all of the PKGBUILDs in the AUR signed with PGP.
Re: [aur-general] Support for remote sums in PKGBUILDs
This idea is a little bit more impractical, but: Handoff could be done cryptographically as well - a signed PKGBUILD could carry a source file that has a transfer-of-maintainership signature (e.g. a clearsigned message with the date and name of the package/base) by the old key signing the new key's key fingerprint + packagename + date, to allow people to transfer maintainership to a new key without raising the alarm, if desired. On Mon, Oct 21, 2013 at 10:53 PM, Ido Rosen i...@kernel.org wrote: (Just an additional implementation detail, but this would mean the verified keyID/fingerprint on the PKGBUILD that generated the pkg gets included in the pkg somehow, not that the pkg needs to be signed by the same key as the PKGBUILD was.) On Mon, Oct 21, 2013 at 10:44 PM, Ido Rosen i...@kernel.org wrote: It'd be nice to have as an option - especially since the key fingerprint is easy to look up on the AUR website. Then tools like yaourt or makepkg can alert you when the keyID of the sig, for example, differs from the one that signed the currently installed version during an upgrade, as a means of allowing for integrity continuity. (There are other things that could be done with this feature, but this is a useful one from a MITM standpoint, so at least you know the new PKGBUILD is from the same author as the old PKGBUILD your pkg was generated from, for example.) On Mon, Oct 21, 2013 at 10:40 PM, Doug Newgard scimmi...@outlook.comwrote: Date: Mon, 21 Oct 2013 22:19:32 -0400 From: i...@kernel.org To: aur-general@archlinux.org Subject: Re: [aur-general] Support for remote sums in PKGBUILDs - Do PKGBUILDs support signing the PKGBUILD and verifying that signature? (This seems like a good feature for yaourt or possible makepkg if it isn't one already.) It seems like if you want safety from MITM attacks, PGP sigs are the way to go, either sign the PKGBUILD and put the checksum in there, or include the signature of the source file in the tarball/pkg. (This is already provided for binary pkgs, but not source ones, correct? Seems easy enough to add a PKGBUILD signature and teach makepkg to use it.) On Mon, Oct 21, 2013 at 10:13 PM, Doug Newgard scimmi...@outlook.com wrote: From: adys...@gmail.com Date: Tue, 22 Oct 2013 01:56:16 +0100 To: aur-general@archlinux.org Subject: [aur-general] Support for remote sums in PKGBUILDs Breaking away from an IRC convo from this morning; has support for remote sums been considered for pacman? It's currently possible to do this for .sig files (through the source array), but not available for simple sha/md5 hashes. This would let packagers do something like: source=(http://example.com/downloads/$pkgname-$pkgver.tar.xz;) sha1sums=(http://example.com/downloads/$pkgname-$pkgver.tar.xz.sha1 ) (Of course, only for servers that generate a programmatically discoverable hash of some sort; but it's not actually uncommon) J. Leclanche Couldn't you just do: sha1sums=($(curl http://example.com/downloads/$pkgname-$pkgver.tar.xz.sha1)) It kind of defeats the purpose, though. If the server is hacked or someone does a MitM, they can easily replace the checksum file as well. Let's be realistic here, you're not going to get all of the PKGBUILDs in the AUR signed with PGP.
Re: [aur-general] CSDP and Mosek in AUR :-)
Hi,
I just submitted two packages to AUR, these are my first packages so
comments are welcome:
coinor-csdp
mosek
(Note that mosek's source is dependent on the target architecture,
so it only shows the 32 bit one on the AUR package website.)
* CSDP is a C library for Semidefinite Programming, an optimization
technique used in machine learning and other areas. It's released
under the Common Public License 1.0.
* Mosek is a linear, quadratic, conic, and mixed integer programming
solver. (Mosek is commercial, but you can get trial or academic
licenses for free to use it.)
Both packages install their matlab toolboxes into
/usr/share/doc/${pkgname}/matlab, for Matlab/Octave users.
Both AUR uploads grab the sources from the upstream vendor.
I'm maintaining these packages on GitHub, so if you want any changes
made to them please submit a pull request or an issue on the GitHub
repository located at:
https://github.com/ido/packages-archlinux
I'd love to see coinor-csdp reach the AUR community repository, since
it's CPL licensed and a useful tool, but it's pretty niche software so
I'm not holding my breath. :-)
Cheers,
Ido
PS: I am unsubscribing from aur-general now so please CC my email address
on replies meant for me.
