On 2016-02-03 21:00, Jacco Ligthart wrote:
On 02/03/2016 06:12 AM, Gordan Bobic wrote:
On 2016-02-02 23:31, david wrote:
Folks
After rereading my mail, applying some guesses, I've gotten RedSleeve
7 (on Raspberry Pi 2) off of ground zero. I basically had to toss
the
existing files in /etc/yum.repos.d and replace them with the file
I've
included below. However, I'm getting failures because certain
packages aren't signed, and that prevents yum from doing its job.
They unsigned packages appear in the repos I've named
[updates-testing] and [rpi2_kernels].
Here are two examples of the failure. There were more.
yum -y update
<lots of output snipped>
Package
NetworkManager-libnm-1.0.0-16.git20150121.b4ea599c.el7.armv5tel.rpm
is
not signed
Package
raspberrypi2-firmware-4.1.11-v7+.1.20151021git4047fe2.armv5tel.rpm is
not signed
I can think of some ways to proceed, and I'd like some opinions:
1) Disable the checking by setting the line "gpgcheck=0" into
/etc/yum.conf.
This is pretty much all you can do at the moment. Not all packages
have been signed.
I've been thinking about this. Jacco, how does this sound:
1) You produce a key pair and sign all the packages on your side.
If you put the public key there, then we can have signed packages
working for the testing repositories which will probably make
people feel less concerned about it.
One way to do this could be to have a redsleeve-testing-release
package
corresponding to the testing repository.
2) Once things have been more thoroughly tested, I'll re-sign them
whth the release version key.
Sounds like a good plan. I especially like the
redsleeve-testing-release
package. This should make it easy for people to follow the testing
stream.
Gordon, could you please make the package (after I deliver a public
key).
Sure. Just put the public key in the root directory of your testing
repositories.
Some of my previous work regarding release packages (raspberrypi
package f.i.) didn't turn out that well, after paths on the server were
different then I anticipated.
It happens. But there is nothing to stop you from bumping up the version
number and rebuilding with the repo files that contain the correct
paths.
Since it's not an upstream package you can keep pushing out new versions
until one works. :)
Gordan
_______________________________________________
users mailing list
[email protected]
https://lists.redsleeve.org/mailman/listinfo/users
