Hi,
I prefer to use individual ssh public keys on different
machines, but I could register only single key in my profile
on aur4.archlinux.org.
Is there any chance to support multiple ssh public keys like
github[1] or Bitbucket[2]?
[1]
* Joakim Hernberg jhernb...@alchemy.lu [2015-06-11 21:03:50 +0200]:
On Thu, 11 Jun 2015 13:36:54 -0500
Eli Schwartz eschwart...@gmail.com wrote:
On Thu, Jun 11, 2015 at 12:04 AM, David Kaylor dpkay...@gmail.com
wrote:
How about a simpleton who has never pushed, pulled, or committed
Em 11-06-2015 16:18, Yuki Chiba escreveu:
I prefer to use individual ssh public keys on different
machines, but I could register only single key in my profile
on aur4.archlinux.org.
Yes, you can only register one at this moment.
Is there any chance to support multiple ssh public keys like
On Thu, 11 Jun 2015 at 21:18:11, Yuki Chiba wrote:
Hi,
I prefer to use individual ssh public keys on different
machines, but I could register only single key in my profile
on aur4.archlinux.org.
Just out of curiosity: Is there any reason for using different SSH keys
per machine (for the
On Thu, 11 Jun 2015 at 21:39:52, Florian Bruhin wrote:
* Joakim Hernberg jhernb...@alchemy.lu [2015-06-11 21:03:50 +0200]:
On Thu, 11 Jun 2015 13:36:54 -0500
Eli Schwartz eschwart...@gmail.com wrote:
[...]
The suggestion was made that perhaps a tarball upload could be added
which would
On 06/11/2015 10:44 PM, Lukas Fleischer wrote:
Just out of curiosity: Is there any reason for using different SSH keys
per machine (for the same server)? Or is it really just a preference?
I can't speak for Yuki, but I do it in order to be able to revoke only
the related keys if a machine is
Em 11-06-2015 17:56, Remi Gacogne escreveu:
(FDE and strong passphrases only buy you some time to do it).
In the case of stolen/lost, it buy you a lot of time. Or you are aware
of some cryptanalisys development I'm not aware of.
Now, if your machine is compromised, then I think that you might
On Thu, Jun 11, 2015 at 4:01 PM, Lukas Fleischer lfleisc...@archlinux.org
wrote:
I am against adding anything that involves uploading a tarball. I am not
averse to including a set of utilities to help with working with to AUR
to [community], though (as long as there isn't anything similar to a
* Johannes Dewender a...@jonnyjd.net [2015-06-12 02:24:10 +0200]:
Generate .SRCINFO for all packages:
$ while read p; do git -C $p filter-branch -f --tree-filter
test -f .SRCINFO || mksrcinfo; done ../pkgs
Don't do it like that. This creates a .SRCINFO from the first PKGBUILD
of
On Thu, Jun 11, 2015 at 11:24 PM, Florian Bruhin m...@the-compiler.org
wrote:
Hmm. Instinctively I'd have agreed, but I can't reproduce this.
I think git filter-branch actually checks out each vanilla commit
from the original branch to apply the given changes, and doesn't base
them on the
* Eli Schwartz eschwart...@gmail.com [2015-06-11 23:37:25 -0500]:
On Thu, Jun 11, 2015 at 11:24 PM, Florian Bruhin m...@the-compiler.org
wrote:
Hmm. Instinctively I'd have agreed, but I can't reproduce this.
I think git filter-branch actually checks out each vanilla commit
from the
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.
On 11 June 2015 at 14:49, Eli Schwartz eschwart...@gmail.com wrote:
Well, I have explained how I set it up in my personal repo at
https://github.com/eli-schwartz/pkgbuilds/ and in a previous discussion on
this mailing list. [1]
I cannot promise to be simple enough for a 5-year-old, but I can
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
On Thu, Jun 11, 2015 at 10:03 PM, Eli Schwartz eschwart...@gmail.com
wrote:
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
On Thu, Jun 11, 2015 at 9:28 PM, Phillip Smith fuka...@gmail.com wrote:
I have already seen your work (thanks by the way, those hooks look
great), but unless I'm missing something there, there's nothing to
help me understand how to use subtrees etc in this scenario.
I have Googled and read
On Thu, Jun 11, 2015 at 10:54 PM, Eli Schwartz eschwart...@gmail.com
wrote:
Use the `./aurpublish` script. It controls everything. Today I added a
speedup option to save the subtree (it duplicates all those commits
though).
My goal is that *everything* should be abstracted and just leave
On Thu, Jun 11, 2015 at 5:59 PM, Giancarlo Razzolini grazzol...@gmail.com
wrote:
Em 11-06-2015 17:56, Remi Gacogne escreveu:
(FDE and strong passphrases only buy you some time to do it).
In the case of stolen/lost, it buy you a lot of time. Or you are aware of
some cryptanalisys development
Lukas Fleischer lfleisc...@archlinux.org writes:
On Thu, 11 Jun 2015 at 21:18:11, Yuki Chiba wrote:
Hi,
I prefer to use individual ssh public keys on different
machines, but I could register only single key in my profile
on aur4.archlinux.org.
Just out of curiosity: Is there any reason
Generate .SRCINFO for all packages:
$ while read p; do git -C $p filter-branch -f --tree-filter
test -f .SRCINFO || mksrcinfo; done ../pkgs
Don't do it like that. This creates a .SRCINFO from the first PKGBUILD
of the package and doesn't update the file for later commits anymore.
So
On Thu, Jun 11, 2015 at 7:42 PM, Eli Schwartz eschwart...@gmail.com wrote:
That still requires packagers to go through several new hoops.
And I can see the benefit of allowing tarball uploads for the same reason
that the AUR3 included a web interface for adding new packages (rather than
=== Signoff report for [community-testing] ===
https://www.archlinux.org/packages/signoffs/
There are currently:
* 0 new packages in last 24 hours
* 0 known bad packages
* 0 packages not accepting signoffs
* 0 fully signed off packages
* 9 packages missing signoffs
* 4 packages older than 14 days
22 matches
Mail list logo
