Closed Bug 546835 Opened 10 years ago Closed 1 year ago
'apt-get update' for Mozilla Catalog cannot be verified on Nokia N900
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2) Gecko/20100115 Firefox/3.6 Build Identifier: Perform apt-get update on Mozilla Catalog always produce errors. Reproducible: Always Steps to Reproduce: 1. Open Terminal on Nokia N900 2. Ensure Mozilla Catalog (http://moff.mozilla.com/maemo/multi) is enabled. 3. Run as root the following: apt-get update Actual Results: Mozilla Catalog returns: W: GPG error: http://moff.mozilla.com chinook Release: The following signatures couldn't be verified because the public key is not available. NO_PUBKEY 667387BFFF445C24 W: You may want to run apt-get update to correct these problems Expected Results: Update via apt-get should not produce any errors when updating Mozilla Catalog
Hey there. The public key is available here: http://ftp.mozilla.org/pub/mozilla.org/mobile/mozilla-maemo-gpg-public-key If you download that, you can sudo apt-key add mozilla-maemo-gpg-public-key which should fix this.
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
I'm abit of a newbie here. 1. Where exactly do I download this to on the N900? Root? 2. How should I save it as? mozilla-maemo-gpg-public-key.key? Many thanks
Ok I figured it out. Save it just as 'mozilla' into /home/user/.ssh Then I did: apt-key add /home/user/.ssh/mozilla I got a return message as OK I then performed apt-get update again but this time introduces new error, the exact error message is: W: Conflicting distribution: http://moff.mozilla.com chinook Release (expected chinook but got ) W: Failed to fetched http://moff.mozilla.com/maemo/multi/dists/chinook/Release Unable to find expected entry release/binary-armel/Packages in Meta-index file (malformed Release file?) E: Some index files fialed to download, they have been ignored, or old ones used instead. As doing apt-get update for Mozilla Catalog still produces error, hence I am reopening this bug.
Status: RESOLVED → UNCONFIRMED
Resolution: FIXED → ---
Hm, I'm also seeing this. After some digging, I found https://lists.ubuntu.com/archives/ubuntu-devel/2007-August/024174.html Is anyone able to install from mozilla.com/m ?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Aha -- luckily the Release check only triggers if you apt-key add. So adding the key breaks our current catalog. I guess the workaround for now is apt-key del "Mozilla Release Engineering <email@example.com>" which triggers the original bug; we do need to fix this but this shouldn't be affecting the general public.
Whiteboard: apt-ftparchive needs to write Release to an external directory during repo creation
As mentioned in comment 4, writing the output of apt-ftparchive to a file inside the directory tree is problematic because we then get a false checksum inside the file. The workaround is to write the output to a temp file, then copy that file into the directory. Also, I wrote some stuff in to be able to keep a history of old debs in the repo (rsync, optionally clobber just this section). Turns out we don't particularly care about old debs in the repo; we only want to serve the latest and historical debs are available on ftp. So I'm just nuking dists/ and populating an empty repository now.
Attachment #432047 - Flags: review?(nrthomas)
Oh -- ran this, downloaded fennec from the repo, then tried apt-get update with and without the key and didn't get any errors.
Attachment #432047 - Flags: review?(nrthomas) → review+
Comment on attachment 432047 [details] [diff] [review] Fix apt-ftparchive command >diff --git a/release/signing/signdebs.mk b/release/signing/signdebs.mk >-clean-install-file: >- rm -f $(WORKDIR)/$(INSTALL_FILENAME) r+, assuming something else does this for you, eg starting from an empty WORKDIR or adding it to the setup: target
Comment on attachment 432047 [details] [diff] [review] Fix apt-ftparchive command (In reply to comment #8) > (From update of attachment 432047 [details] [diff] [review]) > >diff --git a/release/signing/signdebs.mk b/release/signing/signdebs.mk > >-clean-install-file: > >- rm -f $(WORKDIR)/$(INSTALL_FILENAME) > > r+, assuming something else does this for you, eg starting from an empty > WORKDIR or adding it to the setup: target Yup, the rm -rf in the setup: target. Checked in: http://hg.mozilla.org/build/tools/rev/0c8546fc9b83
Venomrush: This should be fixed during our next release; you shouldn't have to wait too long.
Status: NEW → RESOLVED
Closed: 10 years ago → 10 years ago
Resolution: --- → FIXED
(In reply to comment #9) > Yup, the rm -rf in the setup: target. Looks like that's removing $(WORKDIR)/dists and will miss $(WORKDIR)/$(INSTALL_FILENAME).
If it's a matter of me overlooking a small crucial detail, or you overlooking a small crucial detail, I shoulda known where the smart money goes. Attaching two possible fixes... feel free to choose whichever seems cleaner. This one adds $(INSTALL_FILEPATH) to the rm -rf in setup.
Attachment #432879 - Flags: review?(nrthomas)
Attachment #432879 - Flags: review?(nrthomas) → review+
Comment on attachment 432879 [details] [diff] [review] add $(INSTALL_FILEPATH) to rm -rf http://hg.mozilla.org/build/tools/rev/029103f576bb
Reopening; I'm seeing this in nightlies that should already have this fix.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Hm, I've tried Packages.gz -> Packages and having both, but that only changed error messages. I'm going to try using http://repository.maemo.org/extras/dists/chinook/ as a model.
It's looking like the maemo repos above don't use Release.gpg. When I remove the Release.gpg it clears up the apt-get update errors for me. Should we skip the gpg signing?
(In reply to comment #17) > It's looking like the maemo repos above don't use Release.gpg. > When I remove the Release.gpg it clears up the apt-get update errors for me. > > Should we skip the gpg signing? Stuart: is there someone from Nokia who can provide some insight into this?
Stuart, afaict this is the remaining blocker for 1.0.1. Not sure if you want to make a call here, wait til you hear back, or remove this from the blocker list. Over to you; let me know what you want to do.
Assignee: aki → pavlov
This shouldn't block 1.0.1, since we have the same problem with 1.0 -- working on resolving though
(In reply to comment #16) > I'm going to try using http://repository.maemo.org/extras/dists/chinook/ as a > model. Maemo repository  contains Release.gpg file as of today. Maybe you can recheck your fix? http://repository.maemo.org/extras/dists/fremantle-1.2/Release
Adding the GPG key at http://ftp.mozilla.org/pub/mozilla.org/mobile/mozilla-maemo-gpg-public-key still triggers this bug on PR1.3. With the key added ------- W: Conflicting distribution: http://moff.mozilla.com fremantle Release (expected fremantle but got ) W: Failed to fetch http://moff.mozilla.com/latest-beta/maemo/multi/dists/fremantle/Release Unable to find expected entry release/binary-armel/Packages in Meta-index file (malformed Release file?) E: Some index files failed to download, they have been ignored, or old ones used instead. Without the key added: ------- W: GPG error: http://moff.mozilla.com fremantle Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 667387BFFF445C24
Confirming what acabre said. I actually removed fennec weeks (>month?) ago, thinking I'll do a manual purge of fennec and the repos, and wasn't able to reinstall rennec since! Kept getting horrible errors when I re-added the Mozilla repo. All this time, I figured a huge problem like this would be fixed in hours so didn't bother looking into it. Well it finally drove me crazy enough to investigate, so found this bug report and removed the key. Hate the workaround - very insecure. I prey your repos don't get cracked since mobile devices won't be able to verify what they are installing is considered trustworthy.
This problem still exists for Fennec 4 final. It was really hard to find the workaround (no, for me it's no real solution!).
Maemo is now tier3, and we're no longer shipping/building it. I recommend a RESO INCOMPLETE.
Aki, can you explain the «tier3» expression, please?
https://developer.mozilla.org/en/Supported_build_configurations "Tier-3 platforms have a maintainer or community which attempt to keep the platform working. These platforms may or may not work at any time, and often have little test coverage" Effectively, it means that Mozilla Corporation is not supporting Maemo, but will accept patches from people who do want to support it.
Status: REOPENED → RESOLVED
Closed: 10 years ago → 1 year ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.